[olug] Email a report on SSH

[Christopher Cashell]

On Fri, Apr 20, 2012 at 11:14 AM, David Cannon <medaveduh at gmail.com> wrote:
> Hello,
> I have set up an SSH tunnel into an Ubuntu 10.10 machine.  I disabled
> passwords and only use a private key.  I have been using it to proxy my web
> traffic securely when I travel.  Sometimes you just cant trust any old
> WIFI.    Recently my log files have been a little large.  the
> /var/log/auth.log file is showing multiple attempts to login.  I have
> turned the logging to verbose so I can see what is going on but I am not
> home all of the time.  This brings me to the issue.

If you have a host on the Internet with ssh enabled, you're going to
get hit with random sweeps and ssh brute force attacks.  It's a fact
of life with an Internet accessible host.  My recommendation would be
to make sure that it won't succeed, and then put it out of your head.
It isn't worth spending a lot of time on it.

fail2ban is an excellent piece of software, and well worth checking
into.  It'll block repeated failed logins by monitoring the logs.  It
can also support services beyond ssh.  Port knocking got some
publicity and became trendy a few years ago, but personally I feel
that inconvenience doesn't outweigh the benefit for most applications.

My recommended solution is to block brute force attempts with IPTables.

Add a rule like this:

-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m limit
--limit 1/min --limit-burst 4 -j ACCEPT

And only new connections to TCP Port 22 at a rate slower than 1 per
minute (with a burst of 4, as you sometimes see multiple initial TCP
SYN packets from a single connection attempt) will be allowed through.
 Anyone attempting to brute force login via ssh will find themselves
blocked for as long as they continue trying.  You can tweak the exact
timing settings to whatever works for you, although I wouldn't
recommend dropping the burst below 3, or there's a risk of
(temporarily) locking yourself out.  Note: This assumes that somewhere
following the above rule is a "DENY ALL" rule; not an issue because
you already have that as part of firewall best practices, right?

An alternate way of accomplishing this with IPTables is like this:

-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set
--name abusers --rsource
-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -m recent
--update --seconds 180 --hitcount 6 --name abusers --rsource -j DROP
-A INPUT -p tcp -m tcp --dport 22 -m state --state NEW -j ACCEPT

This one requires an ACCEPT line somewhere following the above, and
works on the reverse principle.  Instead of defaulting to DENY, and
only allowing connections when the rate is low enough, it defaults to
ACCEPT (via the rule following it) and starts denying connections when
the count goes above 6 SYN packets in 3 minutes.

Both accomplish roughly the same end result, but may be more or less
appropriate depending on your circumstances.

If you really want notifications every time this happens, there are
lots of tools out there that can send you a failed login summary
(usually as a daily report, but swatch or some other log monitoring
solution could be set to notify more immediately), but you're going to
get IP and username, not password.  As a general rule, the password
supplied is never going to be stored anywhere, just checked for match
and then thrown away.

> David

-- 
Christopher