7 ms·

If you're running an ssh server that allows password authentication, make sure you're also running fail2ban.[1] Too many failed login attempts will block the IP

If you're running an ssh server that allows password authentication, make sure you're also running fail2ban.[1] Too many failed login attempts will block the IP (at an iptables level) for a configurable time period. [1]: http://www.fail2ban.org/wiki/index.php/Main_Page http://www.fail2ban.org/wiki/index.php/Main_Page

hoers 12y ago
You also might want to consider changing your SSH Port http://danielmiessler.com/blog/security-and-obscurity-does-changing-your-ssh-port-lower-your-risk/ http://danielmiessler.com/blog/security-and-obscurity-does-c...
- sireat 12y ago
  As the author of that post says it greatly reduces the login attempts. It has been my experience as well. An analogy with a house it would be like making a brick wall behind your front door and making a new door on the side of the house. Sure, it would not change significantly the time for a determined thief wanting your house specifically,. However moving the door would do wonders against some punk with a bunch of keys who runs around trying them on all neighborhood doors. You still have to make sure you have a good lock and door.
ryan-c 12y ago
I like pam_shield, personally. https://github.com/jtniehof/pam_shield https://github.com/jtniehof/pam_shield Back in the day, disabling password auth but leaving keyboard_interactive on would stop a lot of these things, but I don't think that's true any more.
joshavant 12y ago
If you're going for a security plan of obscurity (which, IMO, is what fail2ban is), I'd just change the SSH port, instead.
- darklajid 12y ago
  Now I'm confused. Why do you consider blocking someone that clearly is trying to brute force his way in 'obscure'?
  - hoers 12y ago
    You're right, it's not.
    - deleted 12y ago
      [deleted]
  - joshavant 12y ago
    If you don't improve the 'hardness' of the authentication scheme - that is, if you continue to use a password instead of, say, SSH keys - then, for all intents and purposes, you've just made the system more _obscure_, rather than improving _actual_ security. To be sure, a dedicated brute forcer could still brute force any system using f2b... it just might take a few months/years instead of a few days. (However, as noted by other commenters, there's something to be said about obscurity within a system's overall security scheme. You just have to strike a balance...)
- jlgaddis 12y ago
  It's not obscurity, it's rate limiting.
- SixSigma 12y ago
  Obscurity is a perfectly legitimate and valid security technique. Relying on obscurity alone is the mistake you are alluding to. Why wouldn't you recommend using fail2ban and changing the port?
  - joshavant 12y ago
    >Relying on obscurity alone is the mistake you are alluding to. Ok, sure. >Why wouldn't you recommend using fail2ban and changing the port? IMO, changing the port will have nearly the same overall effect as f2b: minimizing the number of failed password attempts from unknown users. To that end, changing the port is changing one value in a config file, which has the attractive advantage of being far simpler to setup + maintain.
trashcan 12y ago
http://www.cvedetails.com/vulnerability-list/vendor_id-5567/Fail2ban.html http://www.cvedetails.com/vulnerability-list/vendor_id-5567/... Probably best to just whitelist SSH to known IPs.
- colinbartlett 12y ago
  Curious what you are pointing out here? Just the number? 8 security vilnerabities? What's the count at which I am supposed to stop using a product?
  - jlgaddis 12y ago
    I assume that he's pointing out that even better than running something like fail2ban (or "pf", where available) is not allowing SSH connections from 0/0.
jlgaddis 12y ago
On the BSDs, you can use "pf" to do this as well with the (minor) advantage that it doesn't require installing another piece of software.
- CrLf 12y ago
  You can do the same with nothing more than iptables on Linux (using "recent").

hoers 12y ago

You also might want to consider changing your SSH Port http://danielmiessler.com/blog/security-and-obscurity-does-changing-your-ssh-port-lower-your-risk/ http://danielmiessler.com/blog/security-and-obscurity-does-c...

sireat 12y ago
As the author of that post says it greatly reduces the login attempts. It has been my experience as well. An analogy with a house it would be like making a brick wall behind your front door and making a new door on the side of the house. Sure, it would not change significantly the time for a determined thief wanting your house specifically,. However moving the door would do wonders against some punk with a bunch of keys who runs around trying them on all neighborhood doors. You still have to make sure you have a good lock and door.

ryan-c 12y ago

I like pam_shield, personally. https://github.com/jtniehof/pam_shield https://github.com/jtniehof/pam_shield Back in the day, disabling password auth but leaving keyboard_interactive on would stop a lot of these things, but I don't think that's true any more.

joshavant 12y ago

If you're going for a security plan of obscurity (which, IMO, is what fail2ban is), I'd just change the SSH port, instead.

darklajid 12y ago
Now I'm confused. Why do you consider blocking someone that clearly is trying to brute force his way in 'obscure'?
- hoers 12y ago
  You're right, it's not.
  - deleted 12y ago
    [deleted]
- joshavant 12y ago
  If you don't improve the 'hardness' of the authentication scheme - that is, if you continue to use a password instead of, say, SSH keys - then, for all intents and purposes, you've just made the system more _obscure_, rather than improving _actual_ security. To be sure, a dedicated brute forcer could still brute force any system using f2b... it just might take a few months/years instead of a few days. (However, as noted by other commenters, there's something to be said about obscurity within a system's overall security scheme. You just have to strike a balance...)
jlgaddis 12y ago
It's not obscurity, it's rate limiting.
SixSigma 12y ago
Obscurity is a perfectly legitimate and valid security technique. Relying on obscurity alone is the mistake you are alluding to. Why wouldn't you recommend using fail2ban and changing the port?
- joshavant 12y ago
  >Relying on obscurity alone is the mistake you are alluding to. Ok, sure. >Why wouldn't you recommend using fail2ban and changing the port? IMO, changing the port will have nearly the same overall effect as f2b: minimizing the number of failed password attempts from unknown users. To that end, changing the port is changing one value in a config file, which has the attractive advantage of being far simpler to setup + maintain.

trashcan 12y ago

http://www.cvedetails.com/vulnerability-list/vendor_id-5567/Fail2ban.html http://www.cvedetails.com/vulnerability-list/vendor_id-5567/... Probably best to just whitelist SSH to known IPs.

colinbartlett 12y ago
Curious what you are pointing out here? Just the number? 8 security vilnerabities? What's the count at which I am supposed to stop using a product?
- jlgaddis 12y ago
  I assume that he's pointing out that even better than running something like fail2ban (or "pf", where available) is not allowing SSH connections from 0/0.

jlgaddis 12y ago

On the BSDs, you can use "pf" to do this as well with the (minor) advantage that it doesn't require installing another piece of software.

CrLf 12y ago
You can do the same with nothing more than iptables on Linux (using "recent").