4 ms·

"The successful root login followed only one unsuccessful attempt" Once a system is compromised by a root exploit what makes you think that any information tha

"The successful root login followed only one unsuccessful attempt" Once a system is compromised by a root exploit what makes you think that any information that this system is giving is true? While it may be likely seen the circumstances it is by no way certain. For all we know it may have been a bruteforce attempt which, once in, got disguised as a known-root-password attack. As long as people are going to think that a compromised system is actually giving true information about what happened we'll be in big trouble. Or OP tells us that SSH login and SSH login attemps are logged automatically on another server which hasn't been compromised and then it's a different story...

goodwink 14y ago
The brute force attack would have been disallowed due to fail2ban being enabled.
- martinced 14y ago
  fail2ban only blocks brute-force attacks from similar IPs right? What if a botnet is used to do the brute-force, does fail2ban lock everybody out, effectively making fail2ban a tool that can be used for Denial of Service? All I'd have to do now is to hammer your system with SSH attempts from my botnet and you can't log in anymore...
  - brokentone 14y ago
    If my IP is on your botnet than I've got bigger issues than not getting into my server. Namely you stealing my password and you getting into my server.
    - andybak 14y ago
      I think he means that fail2ban can't be effective against botnets attacks because if it didn't take IPs into account then it becomes a DDOS tool. Therefore it must take IPs into account. Therefore it's not protection against brute-force password guessing from a botnet.
- ohboyacomment 14y ago
  For anybody considering fail2ban here, install keys and disable passwords via SSH (don't remove the password from root as most naïve administrators suggest, since most hosting shops will give you tty1 access; just set PermitRootLogin without-password and PasswordAuthentication no. You keep a back way into the system in the unlikely event that you lose all of your keys and retain physical access to the machine). For an additional layer, you can also remove all terminals except tty1 from securetty. Once you're in that fairly secure state, fail2ban is completely pointless and serves only to reduce noise in your log. Which you should stop caring about. I'm serious. fail2ban is a complete waste of resources and will peg a core tailing your SSH log because it's a resource-intensive piece of software that serves no valuable purpose. If you're worried about the resources of writing a log, redirect the log off the box and prevent your local logger from writing to disk -- which you should be doing for security reasons anyway, as discussed in another comment elsewhere in this thread (how do you trust a box's logs once compromised?). While you're at it, don't move SSH to a separate port. There are interactivity QoS defaults in most networks that expect SSH to be on 22, and the clever bots will find your "cleverly hidden" daemon anyway. And wait until I tell you that in the event of your "cleverly hidden" port 2222 SSH daemon crashing, one of your local users can put up a trojan SSH daemon in its place without your permission (which is why SSH is on 22 in the first place). Just deal with the log noise. We all do on edge boxes exposed to the Internet.
  - tomp 14y ago
    Is there a way to rate-limit ssh password-based logins to your system (i.e. 4 per minute or so)? I mean, across all users, all IPs.
    - ohboyacomment 14y ago
      Locking yourself out of the machine lies that way. Strongly, strongly advise against. But, yes. There's an iptables module called ipt_recent[1] that will do what you're after. It's been built-in for ages and you don't need to install it. You can't use it by itself, though. You will have to design a full iptables ruleset. [1]: http://snowman.net/projects/ipt_recent/ http://snowman.net/projects/ipt_recent/

goodwink 14y ago

The brute force attack would have been disallowed due to fail2ban being enabled.

martinced 14y ago
fail2ban only blocks brute-force attacks from similar IPs right? What if a botnet is used to do the brute-force, does fail2ban lock everybody out, effectively making fail2ban a tool that can be used for Denial of Service? All I'd have to do now is to hammer your system with SSH attempts from my botnet and you can't log in anymore...
- brokentone 14y ago
  If my IP is on your botnet than I've got bigger issues than not getting into my server. Namely you stealing my password and you getting into my server.
  - andybak 14y ago
    I think he means that fail2ban can't be effective against botnets attacks because if it didn't take IPs into account then it becomes a DDOS tool. Therefore it must take IPs into account. Therefore it's not protection against brute-force password guessing from a botnet.
ohboyacomment 14y ago
For anybody considering fail2ban here, install keys and disable passwords via SSH (don't remove the password from root as most naïve administrators suggest, since most hosting shops will give you tty1 access; just set PermitRootLogin without-password and PasswordAuthentication no. You keep a back way into the system in the unlikely event that you lose all of your keys and retain physical access to the machine). For an additional layer, you can also remove all terminals except tty1 from securetty. Once you're in that fairly secure state, fail2ban is completely pointless and serves only to reduce noise in your log. Which you should stop caring about. I'm serious. fail2ban is a complete waste of resources and will peg a core tailing your SSH log because it's a resource-intensive piece of software that serves no valuable purpose. If you're worried about the resources of writing a log, redirect the log off the box and prevent your local logger from writing to disk -- which you should be doing for security reasons anyway, as discussed in another comment elsewhere in this thread (how do you trust a box's logs once compromised?). While you're at it, don't move SSH to a separate port. There are interactivity QoS defaults in most networks that expect SSH to be on 22, and the clever bots will find your "cleverly hidden" daemon anyway. And wait until I tell you that in the event of your "cleverly hidden" port 2222 SSH daemon crashing, one of your local users can put up a trojan SSH daemon in its place without your permission (which is why SSH is on 22 in the first place). Just deal with the log noise. We all do on edge boxes exposed to the Internet.
- tomp 14y ago
  Is there a way to rate-limit ssh password-based logins to your system (i.e. 4 per minute or so)? I mean, across all users, all IPs.
  - ohboyacomment 14y ago
    Locking yourself out of the machine lies that way. Strongly, strongly advise against. But, yes. There's an iptables module called ipt_recent[1] that will do what you're after. It's been built-in for ages and you don't need to install it. You can't use it by itself, though. You will have to design a full iptables ruleset. [1]: http://snowman.net/projects/ipt_recent/ http://snowman.net/projects/ipt_recent/