Patch to Log SSH Passwords – One Year Results

Re:Patch to Log SSH Passwords – One Year Results by machrider on Wednesday November 19, 2014 @10:34PM (#8634304)

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

[ Parent | on HN ]

Re:Patch to Log SSH Passwords – One Year Results by jlgaddis on Thursday November 20, 2014 @03:32AM (#8634835)

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.

[ Parent | on HN ]

Re:Patch to Log SSH Passwords – One Year Results by CrLf on Thursday November 20, 2014 @04:13AM (#8634919)

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

[ Parent | on HN ]

Re:Patch to Log SSH Passwords – One Year Results by ryan-c on Thursday November 20, 2014 @12:30AM (#8634546)

I like pam_shield, personally.

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.

[ Parent | on HN ]

Re:Patch to Log SSH Passwords – One Year Results by trashcan on Thursday November 20, 2014 @02:15AM (#8634693)

http://www.cvedetails.com/vulnerability-list/vendor_id-5567/...

Probably best to just whitelist SSH to known IPs.

[ Parent | on HN ]

Re:Patch to Log SSH Passwords – One Year Results by colinbartlett on Thursday November 20, 2014 @02:20AM (#8634700)

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?

[ Parent | on HN ]

Re:Patch to Log SSH Passwords – One Year Results by jlgaddis on Thursday November 20, 2014 @03:30AM (#8634826)

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.

[ Parent | on HN ]

Re:Patch to Log SSH Passwords – One Year Results by joshavant on Thursday November 20, 2014 @01:14AM (#8634643)

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

[ Parent | on HN ]

Re:Patch to Log SSH Passwords – One Year Results by darklajid on Thursday November 20, 2014 @03:07AM (#8634788)

Now I'm confused. Why do you consider blocking someone that clearly is trying to brute force his way in 'obscure'?

[ Parent | on HN ]

Re:Patch to Log SSH Passwords – One Year Results by joshavant on Friday November 21, 2014 @02:13AM (#8640174)

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...)

[ Parent | on HN ]

Re:Patch to Log SSH Passwords – One Year Results by hoers on Thursday November 20, 2014 @06:11AM (#8635190)

You're right, it's not.

[ Parent | on HN ]

Re:Patch to Log SSH Passwords – One Year Results by jlgaddis on Thursday November 20, 2014 @03:31AM (#8634831)

It's not obscurity, it's rate limiting.

[ Parent | on HN ]

Re:Patch to Log SSH Passwords – One Year Results by SixSigma on Thursday November 20, 2014 @08:03AM (#8635495)

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?

[ Parent | on HN ]

Re:Patch to Log SSH Passwords – One Year Results by joshavant on Friday November 21, 2014 @02:11AM (#8640171)

>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.

[ Parent | on HN ]

Re:Patch to Log SSH Passwords – One Year Results by SixSigma on Friday November 21, 2014 @01:22PM (#8642502)

I can confirm that changing the port does drastically reduce login attempts but also that it is not to zero, I had 45 yesterday, for instance but here's the kicker - all from the same IP.

Setup and maintenance are virtually zero though, for f2b. I know, I just installed it.

A one liner to install on most systems and updates along with everything else when your package manager does the updates.

[ Parent | on HN ]

Re:Patch to Log SSH Passwords – One Year Results by hoers on Wednesday November 19, 2014 @11:19PM (#8634413)

You also might want to consider changing your SSH Port

http://danielmiessler.com/blog/security-and-obscurity-does-c...

[ Parent | on HN ]

Re:Patch to Log SSH Passwords – One Year Results by sireat on Thursday November 20, 2014 @10:22AM (#8636113)

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.

[ Parent | on HN ]