4 ms·

I go by the trifecta: * Disable root login. * Change SSH port. * Install fail2ban or denyhosts.

by bryanh 16y ago

fierarul 16y ago
Wow, I didn't know of fail2ban and denyhosts. I actually have a home-made script similar to fail2ban.
- bmelton 16y ago
  Yeah, I've written a number of very long, very gruelling scripts that ultimately were all replaced by denyhosts. On the flip side, denyhosts only works on sshd (to my knowledge) -- so the scripts I wrote to monitor tornado log files and block all the random attack vectors is still worth having around.
  - mkelly 16y ago
    denyhosts is configurable enough that I see no reason why it couldn't also work for other services. You'd probably have to hand-configure it (with a regex for each log type), though. That said, I've only ever used it for ssh.
- X-Istence 16y ago
  I wrote a similar script way before fail2ban was ever created in around 2003 or so. When PF was first introduced. Since then I've just kept using it since it works particularly well for what I want it to do.
getsat 16y ago
You're missing a really important ssh setting: disable password-based authentication! However, this still won't protect you from vulnerabilities in your ssh daemon itself. Optimally, you would use Single Packet Authorization.
chanri 16y ago
What if you can't disable root login (i.e. it's a cloud server)?
- steve19 16y ago
  Restrict root login from a particular IP address AllowUsers root@112.113.114.115 I use AllowUsers to ensure only users I want can login from SSH.
  - spicyj 16y ago
    But what if your IP address changes?
    - cuu508 16y ago
      Root login shouldn't be your normal entrance. For maintenance stuff use sudo-capable regular user account with public key authentication. If there's some software that requires root login and you cannot do anything about it, enable root login and allow it only from the specific IPs.
- Estragon 16y ago
  Why can't you disable root login on a cloud server?
- dedward 16y ago
  This is where firewalls come in handy... Disabling remote root login isn't as big a deal as it used to be - as others have said, if someone gets your administrative account you're pretty screwed anyway - and if they get your password for sudo, it's the same thing. Other than that, it really depends on what you mean by cloud.
- rjbond3rd 16y ago
  There's no reason you can't disable root logins on a cloud server. I do it every time.
SwellJoe 16y ago
Actually, the trifecta would be: 1. Update your software. 2. Use strong passwords, or public keys, for all accounts, regardless of how unimportant they seem. A strong password is one with letters, numbers, and possibly special characters, 8 or more characters in length, and is changed periodically. 3. Don't run unnecessary services or services with a poor recent security history. Disabling the root login is a legit choice, though if someone figures out your sudo-capable account, you're equally screwed, so use strong passwords always. Changing the ssh port only stops the people who aren't targeting you specifically, and even those people aren't always stopped. It is trivial to scan a host to find where ssh is running, regardless of the port you put it on. fail2ban or denyhosts are OK for preventing brute force attacks, but OpenSSH and most security sensitive software already has timeouts, among other measures for preventing brute force attacks. Which makes fail2ban more of a nuisance-prevention measure (i.e. you see fewer brute force attacks show up in your log reports, and thus making it easier to see the more dangerous threats), rather than a core security measure. If you performed your three steps, but ran an insecure version of any service (particularly those that have elevated privileges), you would still be easily exploited. fail2ban or denyhosts would prevent most services from being exploited due to weak passwords, so that's probably not a hole you'd have. And, changing the ssh port does nothing for you if your system hasn't been updated and is running exploitable services. I used to do security cleanup and post-mortems and data recovery as a contractor for folks who'd had systems exploited. 90% of them were due to running old versions of software, and the rest were due to weak passwords (which may or may not have been prevented by fail2ban; in a couple of cases the exploiter used the webmail client to brute force the weak passwords...most people don't include the webmail client logs in their security considerations, and thus wouldn't configure fail2ban to ban attempts on the webmail client). I'm not saying your advice is not useful, just that it's something you do after you get your core processes in order. Edit: Formatting.
- chanri 16y ago
  Great advice! You sound like you have a lot of experience in server security. What is your recommendation on strong passwords? Also, should all passwords on a system be different (login passwords for different servers, email passwords, etc...), and if so, how do you keep track of all of them? Thanks
iuguy 16y ago
That's a terrible trifecta. * Disable root login If you have root login enabled by default, you're using the wrong distribution. This is 2011, not 1996. * Change the SSH port Why are you doing this? What will you achieve by it? In what way does this reduce your overall risk of compromise, and by whom? * Install fail2ban or denyhosts That's the only thing out of your trifecta that should be in there. Aside from that, here's why your trifecta isn't a good move: You're still using password authentication for SSH. Switch to public key authentication. This, combined with fail2ban or denyhosts means bots are not getting in. Period. You aren't addressing your attack surface area - look at what information assets are exposed to the wider world and how. Once you know what your information assets are and how they can be accessed (either legitimately or unscrupulously) from the outside world you know what you have to protect and how people can get to it. That way you can focus on real countermeasures. What about your applications? Have you checked your code to make sure you're validating input correctly? How are you protecting against SQL injection or Cross-Site Scripting? How are you handling state? I put to you an alternative trifecta: * Know your assets * Know your threats * Use appropriate measures to protect your assets from your threats.
- rm-rf 16y ago
  "* Change the SSH port" "Why are you doing this? What will you achieve by it?" Changing the port does not improve security. It does, however: - dramatically reduce the noise associated with the fleet of password guessing bots that hit open SSH server daily. - make it reasonable to assume that a password guess attempt is specifically targeting your serve, and therefor consideration for escalation and follow up. Signal to noise ratio. Less noise make it possible to discover the signal.
  - iuguy 16y ago
    > - dramatically reduce the noise associated with the fleet of password guessing bots that hit open SSH server daily. But if you're already using fail2ban or denyhosts (as suggested in the trifecta) then you won't get that much noise anyway, and if you're only using public key auth then the noise from password guessing bots doesn't matter anyway. > - make it reasonable to assume that a password guess attempt is specifically targeting your serve, and therefor consideration for escalation and follow up. Unfortunately a failed authentication attempt regardless of port isn't enough to conclude that it's a targeted attack. Plenty of bots port scan common ports before running the tools to make sure they're attacking the right service. In fact some bots can do full portscans of hosts (although this is rare as it's quicker to scan for the attacks you have built in, thus you get more attack attempts in less time) - usually this is done to build a database of services, so that they can be exploited later when a new vulnerability comes out. Regardless, as you say it doesn't improve security, there's no reason for it to be in any security-related trifecta.

I go by the trifecta: * Disable root login. * Change SSH port. * Install fail2ban or denyhosts.

by bryanh 16y ago

I go by the trifecta: * Disable root login. * Change SSH port. * Install fail2ban or denyhosts.

fierarul 16y ago

Wow, I didn't know of fail2ban and denyhosts. I actually have a home-made script similar to fail2ban.

bmelton 16y ago
Yeah, I've written a number of very long, very gruelling scripts that ultimately were all replaced by denyhosts. On the flip side, denyhosts only works on sshd (to my knowledge) -- so the scripts I wrote to monitor tornado log files and block all the random attack vectors is still worth having around.
- mkelly 16y ago
  denyhosts is configurable enough that I see no reason why it couldn't also work for other services. You'd probably have to hand-configure it (with a regex for each log type), though. That said, I've only ever used it for ssh.
X-Istence 16y ago
I wrote a similar script way before fail2ban was ever created in around 2003 or so. When PF was first introduced. Since then I've just kept using it since it works particularly well for what I want it to do.

getsat 16y ago

You're missing a really important ssh setting: disable password-based authentication! However, this still won't protect you from vulnerabilities in your ssh daemon itself. Optimally, you would use Single Packet Authorization.

chanri 16y ago

What if you can't disable root login (i.e. it's a cloud server)?

steve19 16y ago
Restrict root login from a particular IP address AllowUsers root@112.113.114.115 I use AllowUsers to ensure only users I want can login from SSH.
- spicyj 16y ago
  But what if your IP address changes?
  - cuu508 16y ago
    Root login shouldn't be your normal entrance. For maintenance stuff use sudo-capable regular user account with public key authentication. If there's some software that requires root login and you cannot do anything about it, enable root login and allow it only from the specific IPs.
Estragon 16y ago
Why can't you disable root login on a cloud server?
dedward 16y ago
This is where firewalls come in handy... Disabling remote root login isn't as big a deal as it used to be - as others have said, if someone gets your administrative account you're pretty screwed anyway - and if they get your password for sudo, it's the same thing. Other than that, it really depends on what you mean by cloud.
rjbond3rd 16y ago
There's no reason you can't disable root logins on a cloud server. I do it every time.

SwellJoe 16y ago

Actually, the trifecta would be: 1. Update your software. 2. Use strong passwords, or public keys, for all accounts, regardless of how unimportant they seem. A strong password is one with letters, numbers, and possibly special characters, 8 or more characters in length, and is changed periodically. 3. Don't run unnecessary services or services with a poor recent security history. Disabling the root login is a legit choice, though if someone figures out your sudo-capable account, you're equally screwed, so use strong passwords always. Changing the ssh port only stops the people who aren't targeting you specifically, and even those people aren't always stopped. It is trivial to scan a host to find where ssh is running, regardless of the port you put it on. fail2ban or denyhosts are OK for preventing brute force attacks, but OpenSSH and most security sensitive software already has timeouts, among other measures for preventing brute force attacks. Which makes fail2ban more of a nuisance-prevention measure (i.e. you see fewer brute force attacks show up in your log reports, and thus making it easier to see the more dangerous threats), rather than a core security measure. If you performed your three steps, but ran an insecure version of any service (particularly those that have elevated privileges), you would still be easily exploited. fail2ban or denyhosts would prevent most services from being exploited due to weak passwords, so that's probably not a hole you'd have. And, changing the ssh port does nothing for you if your system hasn't been updated and is running exploitable services. I used to do security cleanup and post-mortems and data recovery as a contractor for folks who'd had systems exploited. 90% of them were due to running old versions of software, and the rest were due to weak passwords (which may or may not have been prevented by fail2ban; in a couple of cases the exploiter used the webmail client to brute force the weak passwords...most people don't include the webmail client logs in their security considerations, and thus wouldn't configure fail2ban to ban attempts on the webmail client). I'm not saying your advice is not useful, just that it's something you do after you get your core processes in order. Edit: Formatting.

chanri 16y ago
Great advice! You sound like you have a lot of experience in server security. What is your recommendation on strong passwords? Also, should all passwords on a system be different (login passwords for different servers, email passwords, etc...), and if so, how do you keep track of all of them? Thanks

iuguy 16y ago

That's a terrible trifecta. * Disable root login If you have root login enabled by default, you're using the wrong distribution. This is 2011, not 1996. * Change the SSH port Why are you doing this? What will you achieve by it? In what way does this reduce your overall risk of compromise, and by whom? * Install fail2ban or denyhosts That's the only thing out of your trifecta that should be in there. Aside from that, here's why your trifecta isn't a good move: You're still using password authentication for SSH. Switch to public key authentication. This, combined with fail2ban or denyhosts means bots are not getting in. Period. You aren't addressing your attack surface area - look at what information assets are exposed to the wider world and how. Once you know what your information assets are and how they can be accessed (either legitimately or unscrupulously) from the outside world you know what you have to protect and how people can get to it. That way you can focus on real countermeasures. What about your applications? Have you checked your code to make sure you're validating input correctly? How are you protecting against SQL injection or Cross-Site Scripting? How are you handling state? I put to you an alternative trifecta: * Know your assets * Know your threats * Use appropriate measures to protect your assets from your threats.

rm-rf 16y ago
"* Change the SSH port" "Why are you doing this? What will you achieve by it?" Changing the port does not improve security. It does, however: - dramatically reduce the noise associated with the fleet of password guessing bots that hit open SSH server daily. - make it reasonable to assume that a password guess attempt is specifically targeting your serve, and therefor consideration for escalation and follow up. Signal to noise ratio. Less noise make it possible to discover the signal.
- iuguy 16y ago
  > - dramatically reduce the noise associated with the fleet of password guessing bots that hit open SSH server daily. But if you're already using fail2ban or denyhosts (as suggested in the trifecta) then you won't get that much noise anyway, and if you're only using public key auth then the noise from password guessing bots doesn't matter anyway. > - make it reasonable to assume that a password guess attempt is specifically targeting your serve, and therefor consideration for escalation and follow up. Unfortunately a failed authentication attempt regardless of port isn't enough to conclude that it's a targeted attack. Plenty of bots port scan common ports before running the tools to make sure they're attacking the right service. In fact some bots can do full portscans of hosts (although this is rare as it's quicker to scan for the attacks you have built in, thus you get more attack attempts in less time) - usually this is done to build a database of services, so that they can be exploited later when a new vulnerability comes out. Regardless, as you say it doesn't improve security, there's no reason for it to be in any security-related trifecta.