sshguard: Protection for OpenSSH (Linux.com)

Posted Mar 6, 2007 21:48 UTC (Tue) by HappyCamp (subscriber, #29230) [Link]

I just started using Fail2Ban (http://www.fail2ban.org/) Seems to work well and is fairly simple to install.

Posted Mar 7, 2007 0:49 UTC (Wed) by Erich_J_Ritzmann (guest, #39670) [Link]

I do my graduate studies at a mid-sized school which has us logging into Novell in the clear,
across the public 'net using a web form... they don't support https even if you know enough to
alter the URL. They won't listen to people like us because we won't do Windows (corollary: real
smart computer guys know windoze inside out, right?!). Picture it, someone will someday tell
them that ssh with a password isn't considered secure any more, at which point they will address
the problem by turning to a well-known company from Redmond who doesn't include ssh
(therefore, it is more secure!). This world is full of strange ironies and paradoxes even while we
fret over passphrases and our ssh.

On a more practical note, in the past I've relied on iptables to restrict the IPs accessing my
machine. However, the other day I used the Fedora Core 6 graphical firewall interface, and it
wiped out all of the rules I'd added previously with vi. It leaves one with feeling that the
graphical firewall tool is a tad lame, in case someone is looking for a project.

Posted Mar 7, 2007 5:47 UTC (Wed) by k8to (subscriber, #15413) [Link]

Reading logfiles to find authentication failures is somewhat problematic. Logfiles may have different formats, so it's necessary to customize the parser. It's not easy to create a parser that will correctly parse a logfile when the 'attacker' can create arbitrary substrings. Only logging ip addresses are trustworthy, logged resolved hostnames create an attack opportunity where the revese and forward resolution cycle changes the adddress.

In short, all tools of this ilk would be improved if they could acquire unambiguously the parameters of failed logins. What host at what time tried to log in with what public credentials (obviously the password shouldn't be passed). Has anyone looked into that?

Posted Mar 7, 2007 13:49 UTC (Wed) by ahoogerhuis (subscriber, #4041) [Link]

It would be tempting to call /. on this and refer to this article a while back: http://lwn.net/Articles/222201/

It had a few good comments on ssh dictionary attacks, and also asks the question, why deal with complex software when it can be dealt with very easily in iptables, shown in comments such as these:

http://lwn.net/Articles/222243/ (yours truly also had a comment there)

And for those wanting it simple, using ferm:

# allow SSH connections and tarpit them
proto tcp dport ssh {
mod state state NEW mod recent update seconds 180 hitcount 4 DROP;
mod state state NEW mod recent set ACCEPT;
}

ferm is a very nice way of writing iptables rules:

http://max.kellermann.name/projects/ferm/

-A :)

Posted Mar 7, 2007 20:22 UTC (Wed) by konstantin (subscriber, #37126) [Link]

on redhat/fedora systems, add lines below to /etc/sysconfig/iptables, at the beginning of lines that start with '-A RH-Firewall-1-INPUT'

### if you have 4 unsuccessful logins in one minute, your IP will be banned
### for 60 seconds.
-A RH-Firewall-1-INPUT -p tcp -m tcp --dport 22 --tcp-flags FIN,SYN,RST,ACK SYN -m recent --set --name radiator --rsource
-A RH-Firewall-1-INPUT -p tcp -m tcp --dport 22 --tcp-flags FIN,SYN,RST,ACK SYN -m recent --update --seconds 60 --hitcount 4 --name radiator --rsource -j DROP

This can be extended for other protocol as well. For SSH the above throttles login rate to 12 attempts per minute. (3 attempts per new session, 4 sessions per min)

No need to any additional scripts, software, etc. Works like a charm for all ssh dictionary attack scripts

-Konstantin