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

61–70 of 143 posts

Re: Securing a Linux Server

#61

Post by nl »

zokier wrote: post #58
oelmekki wrote: post #46

Earlier quoted context omitted.

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.

Can you explain how this would work?

How do I use a private CA to generate(?) keys for ssh authentication?

Re: Securing a Linux Server

#62

Post by dpweb »

What is the purpose of creating a new user and not using root, assuming ssh password auth is disabled, and only I have the key. Making a new user that has sudo an attacker geting that user as opposed to root all they have to do is sudo anyway?

Re: Securing a Linux Server

#64

Post by nl »

dsr_ wrote: post #59
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 ther…

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

Agreed. Indeed, the parent explicitly shows one possible trade-off:

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.

Re: Securing a Linux Server

#65

Post by chmike »

oelmekki wrote: post #45
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…

Fail2ban prevents brute force connection attempts. One can also chose a password resistent to brute force by using a long string. A psalm verse, or a sentence from some peoetry which is easy to remember. Or pick a password made of the first letter of each word of this long sentence.

Re: Securing a Linux Server

#66

Post by chmike »

spindritf wrote: post #47
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.

I don't want to be picky but this isn't two factor authentication in its usual sense. Two factor authentication uses two independent means/media to authenticate. Protecting the private key with a password is required to protect it of beeing exposed when stolen. But if it's stolen then brute force password guessing is for free. Brute force attack against a login password can be detected and impaired, not with stolen private key.

Re: Securing a Linux Server

#67

Post by nly »

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…

Even an unprivileged compromised PHP script can open sockets and send email. Is it your intent that your server be able to send spam?

Re: Securing a Linux Server

#68

Post by nly »

txutxu wrote: post #38
ChuckMcM wrote: post #2

This is a good start, netstat -an to see what ports are open, to shut down things that open ports. Turn of xinetd if it is on, etc. There was a much more complete best practices document that came through here earlier.

And then realize you left all ipv6 traffic open (?)

Having separate iptables for IPv6 is painful. Are there any means to address this?

Re: Securing a Linux Server

#69

Post by pepve »

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…

Your private key should be encrypted with a strong password.

If you follow that best practice, you can stop worrying about your laptop being stolen, and start worrying about five dollar wrenches. (http://xkcd.com/538/)

Re: Securing a Linux Server

#70

Post by nly »

FooBarWidget wrote: post #48
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.

My dedicated server provider ships grsec enabled kernels by default. Admittedly, they tend to be a bit stale.
Post reply on HN