5 ms·

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/
  - jrabone 14y ago
    Simple 3 attempts per minute rate-limiter: echo " (eth0 - SSH rate check)" iptables -N SSH_CHECK iptables -A SSH_CHECK -m recent --set --name SSH iptables -A SSH_CHECK -m recent --update --seconds 60 --hitcount 3 --name SSH -j DROP
    - ohboyacomment 14y ago
      Well, that's omitting the rules required to get an SSH packet to that chain. I also hope you've already ACCEPTed ESTABLISHED,RELATED so we're only considering these rules on new connections, otherwise you've entirely locked out SSH after the third packet. Assuming that's true, now guess what happens when you do this during a crisis: for i in backup-file-{0..999}; do scp $i that-machine:/var/db/ done Unless you're muxing in your local SSH config, you will cause the firewall to intervene on you during the absolute worst time, and you will have no idea why. Promise. I really wish we could reverse the trend of fiddling with iptables when it comes to SSH. Everybody does it and nobody thinks about the ramifications.
      - jrabone 14y ago
        OP didn't ask for a complete firewall script, and besides they should be writing their own rather than copy-pasting the whole thing. Of course there's more to it. The global limit on scp is fine; this is an internet-facing server with minimum user data for which I have a cold spare - there's nothing to back up. You're coming over like you're the only person in the world who knows what they're doing; might want to rethink that.

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/
- jrabone 14y ago
  Simple 3 attempts per minute rate-limiter: echo " (eth0 - SSH rate check)" iptables -N SSH_CHECK iptables -A SSH_CHECK -m recent --set --name SSH iptables -A SSH_CHECK -m recent --update --seconds 60 --hitcount 3 --name SSH -j DROP
  - ohboyacomment 14y ago
    Well, that's omitting the rules required to get an SSH packet to that chain. I also hope you've already ACCEPTed ESTABLISHED,RELATED so we're only considering these rules on new connections, otherwise you've entirely locked out SSH after the third packet. Assuming that's true, now guess what happens when you do this during a crisis: for i in backup-file-{0..999}; do scp $i that-machine:/var/db/ done Unless you're muxing in your local SSH config, you will cause the firewall to intervene on you during the absolute worst time, and you will have no idea why. Promise. I really wish we could reverse the trend of fiddling with iptables when it comes to SSH. Everybody does it and nobody thinks about the ramifications.
    - jrabone 14y ago
      OP didn't ask for a complete firewall script, and besides they should be writing their own rather than copy-pasting the whole thing. Of course there's more to it. The global limit on scp is fine; this is an internet-facing server with minimum user data for which I have a cold spare - there's nothing to back up. You're coming over like you're the only person in the world who knows what they're doing; might want to rethink that.