5 ms·

What's better - Fail2ban or change port?

TallGuyShort 9y ago
Why not both? Changing the port is so trivially easy and just moves you out of the way of the majority of low-sophistication automated scans.
- teddyh 9y ago
  (I repeat my comment from 3 years ago¹:) I think nobody argues that it adds security. The problem is that: 1. It adds very little security: 16 bits is not much, and the result is not 256 bits (say) of SSH key plus 16 bits equals 272 bits, but instead effectively still 256 bits, or 256+8×10⁻⁷³ bits. 2. The security it adds is itself bad (sent in cleartext, easily brute-forced) 3. These problems stand against the many drawbacks of this previously discussed (complexity, confusion, etc.). And the final argument: If increased security is what you want, simply increase your key lengths and/or password lengths, and you will get much more than 8×10⁻⁷³ bits of security, without any of the above problems. ① https://news.ycombinator.com/item?id=6617312 https://news.ycombinator.com/item?id=6617312
  - TallGuyShort 9y ago
    Did you reply to the right comment? Feels like you might have been addressing a different issue. There's more to security than information theory. Bits of security aside, if you're not listening on port 22 the majority of wide-scale automated scans miss you entirely. If there were some zero day being actively exploited in the wild, admins occasionally having to remember '2222' instead of '22' is pretty a pretty trivial issue and just sidesteps a lot to buy you some time to patch.
    - teddyh 9y ago
      Again I feel the need to repeat myself¹: I am not in a position where I feel I need to worry about remotely exploitable 0-days in my SSH daemon. If you are, then your situation is, I feel, exceptional. That said, perhaps those people should sponsor a project to fix this for real. This could be accomplished by having not one program, but two, one after the other, both with realistic keysizes and security. The password/key to get log in would be then be the combination of two separate keys, one for each program. But what I have described is more or less the same as having a key/password-protected tunnel on top of SSH, so they could just use that. A 0-day in the tunnel/VPN would not allow access through SSH, and a 0-day in SSH would not matter since SSH can’t be accessed directly in the first place. This way, both the tunnel and SSH would need a 0-day at the same time for the security to fail. Like a RAID-1 array. If even this is not sufficiently secure, just increase the number of layers. ① https://news.ycombinator.com/item?id=6619451 https://news.ycombinator.com/item?id=6619451
arca_vorago 9y ago
Why not both? Really, first thing is to be on top of your pure iptables config. Even better, is to realize iptables is being deprecated and it's time to learn nftables. No, don't use nice little gui's or menus that abstract the data entry away for you, you need to understand how the firewall actually works. Then port change, SSH hardening in general (key + pass, google pam auth module, etc), then fail2ban, denyhosts, sshguard, tallow, etc. And all that doesn't matter if you don't see any alerts. Need a hids (I like OSSEC) and a good logging system for syslog etc alerts. Number one issue I see with servers (besides badly secured in the first place), is a bunch of logs no one ever actually looked at.
developer2 9y ago
If I understand correctly, fail2ban has no effect if you disable the use of passwords. If you force the use of ssh keys, fail2ban becomes completely superfluous. That leaves port change, which is better than nothing. But even better than that is proper firewalling with whitelisted IPs.
grogenaut 9y ago
Why is your ssh even open to the Internet?
- derefr 9y ago
  Why shouldn't it be? Tunnelling connections through an SSH jump-box is no more or less secure than tunnelling through IPSec VPN.
  - grogenaut 9y ago
    It depends on how that jump box is configured, audited, etc. Do you know that your users aren't leaving their keys on laptops that don't have drive encryption, don't have passwords on the keys, etc? Are you forcing 2fa? A lot of these other solutions offer many more deeper enforced protections with better auditing than just an ssh jump box. I'm also not really a fan of leaving things with a shell connection on the net, again part of configuration. If you can root the ssh server, you could likely root a vpn box. Also, I guess, I'm sorry, you're not allowed to ask questions on HN anymore. Thanks for the drive by down vote.
laumars 9y ago
fail2ban is easily the better of those two options. However the best solution is to use SSH keys (disable password authentication) and have a small few IPs whitelisted. If password authentication is a must then hopefully you can still go for 2FA (there's a few two factor authentication plugins for PAM). But if you do that then make sure you also stick fail2ban in there as well.

Why not both? Changing the port is so trivially easy and just moves you out of the way of the majority of low-sophistication automated scans.

teddyh 9y ago
(I repeat my comment from 3 years ago¹:) I think nobody argues that it adds security. The problem is that: 1. It adds very little security: 16 bits is not much, and the result is not 256 bits (say) of SSH key plus 16 bits equals 272 bits, but instead effectively still 256 bits, or 256+8×10⁻⁷³ bits. 2. The security it adds is itself bad (sent in cleartext, easily brute-forced) 3. These problems stand against the many drawbacks of this previously discussed (complexity, confusion, etc.). And the final argument: If increased security is what you want, simply increase your key lengths and/or password lengths, and you will get much more than 8×10⁻⁷³ bits of security, without any of the above problems. ① https://news.ycombinator.com/item?id=6617312 https://news.ycombinator.com/item?id=6617312
- TallGuyShort 9y ago
  Did you reply to the right comment? Feels like you might have been addressing a different issue. There's more to security than information theory. Bits of security aside, if you're not listening on port 22 the majority of wide-scale automated scans miss you entirely. If there were some zero day being actively exploited in the wild, admins occasionally having to remember '2222' instead of '22' is pretty a pretty trivial issue and just sidesteps a lot to buy you some time to patch.
  - teddyh 9y ago
    Again I feel the need to repeat myself¹: I am not in a position where I feel I need to worry about remotely exploitable 0-days in my SSH daemon. If you are, then your situation is, I feel, exceptional. That said, perhaps those people should sponsor a project to fix this for real. This could be accomplished by having not one program, but two, one after the other, both with realistic keysizes and security. The password/key to get log in would be then be the combination of two separate keys, one for each program. But what I have described is more or less the same as having a key/password-protected tunnel on top of SSH, so they could just use that. A 0-day in the tunnel/VPN would not allow access through SSH, and a 0-day in SSH would not matter since SSH can’t be accessed directly in the first place. This way, both the tunnel and SSH would need a 0-day at the same time for the security to fail. Like a RAID-1 array. If even this is not sufficiently secure, just increase the number of layers. ① https://news.ycombinator.com/item?id=6619451 https://news.ycombinator.com/item?id=6619451

arca_vorago 9y ago

Why not both? Really, first thing is to be on top of your pure iptables config. Even better, is to realize iptables is being deprecated and it's time to learn nftables. No, don't use nice little gui's or menus that abstract the data entry away for you, you need to understand how the firewall actually works. Then port change, SSH hardening in general (key + pass, google pam auth module, etc), then fail2ban, denyhosts, sshguard, tallow, etc. And all that doesn't matter if you don't see any alerts. Need a hids (I like OSSEC) and a good logging system for syslog etc alerts. Number one issue I see with servers (besides badly secured in the first place), is a bunch of logs no one ever actually looked at.

developer2 9y ago

If I understand correctly, fail2ban has no effect if you disable the use of passwords. If you force the use of ssh keys, fail2ban becomes completely superfluous. That leaves port change, which is better than nothing. But even better than that is proper firewalling with whitelisted IPs.

grogenaut 9y ago

Why is your ssh even open to the Internet?

derefr 9y ago
Why shouldn't it be? Tunnelling connections through an SSH jump-box is no more or less secure than tunnelling through IPSec VPN.
- grogenaut 9y ago
  It depends on how that jump box is configured, audited, etc. Do you know that your users aren't leaving their keys on laptops that don't have drive encryption, don't have passwords on the keys, etc? Are you forcing 2fa? A lot of these other solutions offer many more deeper enforced protections with better auditing than just an ssh jump box. I'm also not really a fan of leaving things with a shell connection on the net, again part of configuration. If you can root the ssh server, you could likely root a vpn box. Also, I guess, I'm sorry, you're not allowed to ask questions on HN anymore. Thanks for the drive by down vote.

laumars 9y ago

fail2ban is easily the better of those two options. However the best solution is to use SSH keys (disable password authentication) and have a small few IPs whitelisted. If password authentication is a must then hopefully you can still go for 2FA (there's a few two factor authentication plugins for PAM). But if you do that then make sure you also stick fail2ban in there as well.