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

41–50 of 143 posts

Re: Securing a Linux Server

#41

Post by pbhjpbhj »

tobithiel wrote: post #19
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.

You can just use iptables-apply. It achieves the same thing and is built-in. If you don't confirm the changes after they are applied, because you locked yourself out, they will be rolled back.

This is in the article FWIW.

Re: Securing a Linux Server

#42

Post by riffraff »

asdfs wrote: post #26

Would automated security updates be an appropriate item to include in this?

I thought the same, since the OP has already installed and configured outgoing emails, I think using apticron[0] would make a lot of sense.

[0] https://www.debian-administration.org/articles/491

Re: Securing a Linux Server

#43

Post by XorNot »

Qantourisc wrote: post #13
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..

The answer is don't: use an unique key for each device. But this doesn't solve the problem you have to connect to each host to reject the lost key. (But you have the same problem with 1 key, so no worse.)

I fall on the side of an SSH key identifies a person, not a device. That's what host keys are for.

What's always been missing though is a decent way to keep track of all the places which might be set to authorize a particular key so you can revoke it if you think it's been compromised (which should mean "is under brute force attack to decrypt it's AES encryption").

I suppose with a DynDNS server and a smartphone app, you could setup a web-page which would allow you to request a URL to download your SSH key securely to new devices but this is kind of the problem: there's just nothing out there which lets you keep a proper eye on how your web-of-trust works for this type of thing.

Re: Securing a Linux Server

#44

Post by jacquesm »

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 an egress filter on the machine can be disabled by someone that has compromised that machine.

Re: Securing a Linux Server

#45

Post by oelmekki »

chmike wrote: post #40

What's wrong with passwords ? The info is in your head and in a physical booklet secured at home for backup. Its only weakness is is keylogger. A secret key protected by password doesn't provide you more security. You can only connect from the computers having a copy of the key. If that computer is inaccessible or dead, or the private key is erased you can't log in. It also is exposed to keylogger. So I stay with pas…

Password authentication is prone to bruteforce. With public key auth, even if someone has your passphrase, he also needs the private key to break into your server.

Indeed, there's always the risk to lose your private key. That's why it's useful to have several : I have one on my desktop, one on my laptop and one on my mobile. If any get compromised, I only have to delete one public key in authorized keys and generate a new one. That's still open to some attacks, but way less dangerous than simply allowing anyone from anywhere to log in.

That's also better than allowing only a few IPs on port 22, because you'll never now where you will be and what IP your laptop will have when an emergency occurs.

Re: Securing a Linux Server

#46

Post by oelmekki »

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 on first server, then use it to log on others. But that would be dangerous : if the master server crashes, you can't access other servers anymore. Redundancy is good, in that case.

Re: Securing a Linux Server

#47

Post by spindritf »

chmike wrote: post #40

What's wrong with passwords ? The info is in your head and in a physical booklet secured at home for backup. Its only weakness is is keylogger. A secret key protected by password doesn't provide you more security. You can only connect from the computers having a copy of the key. If that computer is inaccessible or dead, or the private key is erased you can't log in. It also is exposed to keylogger. So I stay with pas…

> A secret key protected by password doesn't provide you more security.

It does. You can encrypt the key and then you have two-factor authentication. You need to have the key and know the password to use it.

Re: Securing a Linux Server

#48

Post by FooBarWidget »

muppetman wrote: post #34

Amazed that "Install grsecurity" isn't one of the key things listed here. Sure, you have to compile your own kernel, but the enhanced memory protections and many other hardening features make it an excellent addition to your security arsenal. http://grsecurity.net

It's not just "you have to compile your own kernel". It's "you have to compile your kernel EVERY TIME there's a kernel update". If you forget one update and you leave an exploit on your system, you're screwed.

Having said that, I'm surprised Debian and Ubuntu don't have better support for grsecurity. If they'd provide up-to-date packages I'd switch over.

Re: Securing a Linux Server

#49

Post by moepstar »

e12e wrote: post #9
aristidb wrote: post #7

Earlier quoted context omitted.

netstat -an shows a lot of stuff. I think here all you need is netstat -ntul (Thanks "child", I did indeed initially not have the -u there. You should.)

Better yet, netstat -nltu (--numeric --listening --tcp --udp). You probably want to shut down anything unwanted that binds an udp-socket too.

I frequently use netstat -tulpen

.. which is a mnemonic trick, "tulpen" is "tulips" in German...

Re: Securing a Linux Server

#50

Post by spindritf »

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 only very recently supports IPv6 (which means the version from your repo may not). You can achieve similar results with something like

    -A INPUT -p tcp -m tcp --dport 22 -m recent --update --seconds 180 --hitcount 4 --rttl --name SSH --rsource -j LOG --log-prefix "ssh brute force: "
    -A INPUT -p tcp -m tcp --dport 22 -m recent --update --seconds 180 --hitcount 4 --rttl --name SSH --rsource -j DROP
    -A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name SSH --rsource -j ACCEPT
but if you disable password logins, no one's going to brute force their way in.

[1] https://help.ubuntu.com/community/AutomaticSecurityUpdates

[2] http://www.ubuntu.com/usn/

Post reply on HN