Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Securing a Linux Server

spenserj.com

Post reply on HN
Print view View original

51–60 of 143 posts

Re: Securing a Linux Server

#51

Post by moepstar »

ruttiger wrote: post #10

I made the mistake of accidentally setting the firewall too strict on a remote server, killing my ability to SSH. A neat little trick I found was to setup a scheduled task to kill the firewall in 5 minutes, and then restart it. If it's too restrictive and locks you out, wait 5 minutes. If you did it right, then kill the scheduled task.

APF, which is basically just a simplified way of setting up IPTables rules, does this.

http://www.rfxn.com/projects/advanced-policy-firewall/

or

apt-get install apf-firewall

Re: Securing a Linux Server

#52

Post by sherr »

I used to think that the Redhat security guides were good [1], but would also go through the NSA guide to securing Redhat [2]. Seems a little ironic nowadays.

Recently, we had Bryan Kennedy's "first 5 minutes" [3], linked from Drew Crawford's guide to "NSA proofing" email [4] (pretty good guide to securing a mail server).

[1] https://access.redhat.com/site/documentation/Red_Hat_Enterpr... [2] http://www.nsa.gov/ia/mitigation_guidance/security_configura... [3] http://plusbryan.com/my-first-5-minutes-on-a-server-or-essen... [4] http://sealedabstract.com/code/nsa-proof-your-e-mail-in-2-ho...

Re: Securing a Linux Server

#54

Post by sturadnidge »

jacquesm wrote: post #44
sturadnidge wrote: post #16

I've never understood the compulsion to restrict outbound traffic on an internet facing server that you do not intend to be used by other (untrusted) people. If someone is good enough to own you with everything else locked down, they can change any firewall rules completely if they need to, or just tunnel out over an allowed port. Creating a non-root user then giving them carte blanche sudo rights is similarly odd to…

The most important word in your comment is 'intend'. Unauthorized use is never intended (other than in honeypots, but even there it is somewhat intended...). Egress filtering is important, if you think the chances are large that a user account is compromised a filter table can help. But an even more effective egress filter is one that you run on the router/hardware firewall just upstream from your machines. After all…

Exactly right re: doing it downstream (or in the case of virtual machines, outside of the guest).

I didn't mean 'intend' in the context of unauthorised use, i was trying to differentiate between a 'single user' ( can't think of a better term, but i'm sure you know what i mean) application server and systems where you purposefully give shell access to other users but want to restrict egress.

Re: Securing a Linux Server

#55

Post by slacka »

pacoverdi wrote: post #14

See also http://plusbryan.com/my-first-5-minutes-on-a-server-or-essen... Discussed here: https://news.ycombinator.com/item?id=5316093

Another good guide: http://devo.ps/blog/2013/03/06/troubleshooting-5minutes-on-a...

Discussed here: https://news.ycombinator.com/item?id=5361335

Re: Securing a Linux Server

#56

Post by zokier »

elktea wrote: post #35
zokier wrote: post #24

Earlier quoted context omitted.

> It's to easy to exploit as denial-of-service attack and can be used to lock out legitimate users. Could you explain what's the "easy" way to DoS using fail2ban(or equivalent system)?

There's still a lot of ISPs that don't follow BCP-38 so source address IP spoofing is easy enough

SSH is TCP based, you need two-way handshake to construct the connection. Source address spoofing gets you only half-way there.

Re: Securing a Linux Server

#57

Post by jacquesm »

sturadnidge wrote: post #54
jacquesm wrote: post #44

Earlier quoted context omitted.

The most important word in your comment is 'intend'. Unauthorized use is never intended (other than in honeypots, but even there it is somewhat intended...). Egress filtering is important, if you think the chances are large that a user account is compromised a filter table can help. But an even more effective egress filter is one that you run on the router/hardware firewall just upstream from your machines. After all…

Exactly right re: doing it downstream (or in the case of virtual machines, outside of the guest). I didn't mean 'intend' in the context of unauthorised use, i was trying to differentiate between a 'single user' ( can't think of a better term, but i'm sure you know what i mean) application server and systems where you purposefully give shell access to other users but want to restrict egress.

Systems like that are only a privilege escalation away from being compromised and are much softer targets. Anything with shell access for multiple parties not known intimately to the owner of the box should be monitored with great zeal.

Re: Securing a Linux Server

#58

Post by zokier »

oelmekki wrote: post #46
nl wrote: post #12

I find https://wiki.ubuntu.com/UncomplicatedFirewall to be much friendlier to use when setting up firewalls. The big problem I have is securing my private keys. I use multiple devices, and haven't found a secure and convenient way to share the keys across devices securely. I'd love ideas..

You shouldn't try to share them, imo, and generate a key for each device. Yes, that may be painful to have to copy 5 public keys on each new server, but the day where, say, your laptop get stolen, you don't have to change the private key on each device : simply remove the laptop one. If you want some kind of centralization, you could only add your keys on a single server, then add this server key on others. You log o…

Better way to reduce the need for copying keys around would be setting up a private CA, and signing the individual keys with it. Of course you need to keep the CA key secure, I'd strongly suggest removable media or preferably a real HSM.

Re: Securing a Linux Server

#59

Post by dsr_ »

spindritf wrote: post #50

This falls a bit short. You shouldn't just update, you should update regularly or better yet set up unattended upgrades[1]. Especially for your hobby projects or personal server because odds are that you won't always have the time to act on every security advisory. (Subscribe here[2] to at least hear about them.) Also, if something breaks once in a blue moon, it's not that big a deal. Fail2ban is fairly heavy and onl…

Security is a tradeoff. In this case, unattended upgrades lead to increased downtime.

(Why? Because you didn't read the caution note that upstream sent along to you, that's why. You just woke up to the alert saying that your system is down.)

If you have a reasonable environment, you should have alpha or qa servers that look just like production, except that they aren't visible to the outside. Always test changes there before upgrading on your production machines.

Re: Securing a Linux Server

#60

Post by nl »

oelmekki wrote: post #46
nl wrote: post #12

I find https://wiki.ubuntu.com/UncomplicatedFirewall to be much friendlier to use when setting up firewalls. The big problem I have is securing my private keys. I use multiple devices, and haven't found a secure and convenient way to share the keys across devices securely. I'd love ideas..

You shouldn't try to share them, imo, and generate a key for each device. Yes, that may be painful to have to copy 5 public keys on each new server, but the day where, say, your laptop get stolen, you don't have to change the private key on each device : simply remove the laptop one. If you want some kind of centralization, you could only add your keys on a single server, then add this server key on others. You log o…

I agree that key-for-each-device is probably best practice.

It just doesn't work for me though. I frequently need to log onto servers from new client computers, and the workflow of connect from trusted device, generate new key for new device then use new device just isn't practical.

I've spent a lot of time thinking about this.

I think the biggest threat to security on my servers is brute forcing of ssh passwords. The best solution for that is key based authentication. (I deploy fail2ban as well though)

There is a non-zero threat of my devices being lost/stolen/accessed with my keys on them.

So key based authentication is the way to go, but I just can't get around the practical aspects.

In the end I often rely on long, random passwords kept in a KeePass database I sync (along with Fail2Ban). I've considered keeping my private keys in that too, and to be honest I think that isn't a terrible solution. It is certainly less than ideal, but probably mildly more secure than my current method (ie: really a private key shared across devices is acting as a very long password)

Post reply on HN