SSHD: Limit login attempt rate

I'm running an sshd on Fedora 8, and have recently been getting
swamped with people trying to log in (i.e., break in). It's configured
to only allow three authentication attempts per connection, but they
just keep reconnecting: probably some script kiddies with port
sniffers and password testers. Is there a way to configure it so that
there's a timeout after failed attempts? For example, if a particular
address tries and fails three times to authenticate, that address is
blocked for three hours, or something similar?

Thanks,
-Brian

On 2008-07-24, bmearns <(E-Mail Removed)> wrote:
>
>
> I'm running an sshd on Fedora 8, and have recently been getting
> swamped with people trying to log in (i.e., break in). It's configured
> to only allow three authentication attempts per connection, but they
> just keep reconnecting: probably some script kiddies with port
> sniffers and password testers. Is there a way to configure it so that
> there's a timeout after failed attempts? For example, if a particular
> address tries and fails three times to authenticate, that address is
> blocked for three hours, or something similar?
>
fail2ban

bmearns <(E-Mail Removed)> writes:

>I'm running an sshd on Fedora 8, and have recently been getting
>swamped with people trying to log in (i.e., break in). It's configured
>to only allow three authentication attempts per connection, but they
>just keep reconnecting: probably some script kiddies with port
>sniffers and password testers. Is there a way to configure it so that
>there's a timeout after failed attempts? For example, if a particular
>address tries and fails three times to authenticate, that address is
>blocked for three hours, or something similar?


I have a script which looks at the logs and if it finds too many failed
login attempts from the same machine it puts the address into
/etc/hosts.allow with a deny flag

sshd: your.special.machine otehr.good.machine 192.168.0 :allow
sshd: bad.machine.com other.bad.machine 10.9.8.1 :deny
sshd: ALL :allow

sshd read through the table from teh top and the first rule applies. Thus
special machines are allowed from that first line. bad machines are denied
as is 10.9.8.1
and everything else is allowed. The script looks for bad logins and if
there are to many in say a week it puts the address into the deny line. I
just leave the addresses in there. I donot trust people who let their
machines be hijacked.

The first allow line is to make sure that you do not lock yourself out by
way getting the password wrong too often.

"bmearns" <(E-Mail Removed)> wrote in message
news:103d250f-85a7-4240-aa96-(E-Mail Removed)...
> I'm running an sshd on Fedora 8, and have recently been getting
> swamped with people trying to log in (i.e., break in). It's configured
> to only allow three authentication attempts per connection, but they
> just keep reconnecting: probably some script kiddies with port
> sniffers and password testers. Is there a way to configure it so that
> there's a timeout after failed attempts? For example, if a particular
> address tries and fails three times to authenticate, that address is
> blocked for three hours, or something similar?

Firewall rules are usually the most effective. Consider this:

1) If your access is ONLY from static addresses, then restrict access to
only those addresses.
2) If your access is dynamic but always through the same provider (e.g.
residential DSL, cable modem, etc.), ask your provider for the DHCP ranges
that they will assign - and restrict access to those ranges.
3) If you must open access to the rest of the world (usually due to
travel), consider banning addresses from parts of the world you never travel
to.
a) Ban all IPv4 ranges assigned to the 4 RIRs other than the one that
covers where (your users and) you live.
b) Use limiting and connection limiting to rate limit connection
attempts. With iptables:
... -j ACCEPT -s [your-usual-IP-or-range]
... -j REJECT -s [foreign-IP-ranges] --reject-with
icmp-net-prohibited
...
... -j ACCEPT -m state --state ESTABLISHED,RELATED
... -j REJECT -m connlimit --connlimit-above 1 --connlimit-mask 24
... -j ACCEPT -m limit --limit 1/minute --limit-burst 1
... -j REJECT
or if you really want to be obnoxious, instead of the last reject, use:
... -j REJECT -m limit --limit 1/hour --limit-burst 1
... -j TARPIT

Limit and connlimit are in the Linux kernel but need to be enabled (disabled
by default). The TARPIT target is in netfilter.org's patch-o-matic-ng code
addition. I wish tarpit were made part of the standard kernel....

What does that do?
- Those already connected continue.
- Those seeking a connection can do so ONLY if there is at most one other
(TCP) connection of ANY type from the same class-C subnet, may seek a new
connection only once per minute, and if they exceed that, they get an ICMP
rejection. Should the "obnoxious option" be chosen, they get their
rejection, and if they try again within the same minute, they get tarpitted.
Note that the tarpit may count as a connection - it's not necessarily exempt
from the connection tracking code.
- Those who successfully connect then get to try to enter a password
(default is 3 attempts per connection, but in sshd_config, that can be
changed). Legitimate users will usually enter a correct password on the
first or second try, so they should be unaffected. Others will usually
exceed the limits and be locked out or tarpitted by the limits.

I put my ssh specific firewall rules into their own ruleset list. That
makes it convenient to check just those rules for snooping from banned areas
of the world. I also log all attempts that make it to the accept line with
limits. Do not log the accept state=established, else EVERY ssh packet will
be recorded.

Some people suggest using a port other than 22 for ssh. I'll leave that for
others to discuss. However, if you do this, let anyone that tries port 22
to get a rejection a couple of times before tarpitting them.

In the past 15 hours via IPv4, I got 11 attempts from other regions, plus 2
IPs in my region that tried. One tried 5 times, and he got 3 packets that
were accepted (and therefore got a password prompt), the 4th was rejected,
and the 5th would have been tarpitted if I had that enabled, whereby the
hacker gave up. I see no hack attempts via IPv6.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

bmearns escribió:

| I'm running an sshd on Fedora 8, and have recently been getting
| swamped with people trying to log in (i.e., break in). It's configured
| to only allow three authentication attempts per connection, but they
| just keep reconnecting: probably some script kiddies with port
| sniffers and password testers. Is there a way to configure it so that
| there's a timeout after failed attempts? For example, if a particular
| address tries and fails three times to authenticate, that address is
| blocked for three hours, or something similar?

What is DenyHosts?
DenyHosts is a script intended to be run by Linux system administrators
to help thwart SSH server attacks (also known as dictionary based
attacks and brute force attacks).

http://denyhosts.sourceforge.net/

- --
Un saludo
Alo [alo(@)uk2.net]
PGP en http://pgp.eteo.mondragon.edu [Get "0xF6695A61 "]
Usuario registrado Linux #276144 [http://counter.li.org]

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkiJpN4ACgkQvzPPcPZpWmHzDwCffF28uXIZBO iGx5/TAi/TodMu
uWEAn2/0bzi9hnM1rPIU4K0DXDQZ2y9S
=aULR
-----END PGP SIGNATURE-----

Thanks for all the great recommendations. I'm especially interested in
iptable rate-limiting and port-knocking, which I will be looking more
into. Moe Trin mentioned that port-knocking doesn't block out remote
hosts who can't connect on obscure ports, but I don't see how? This is
also my main reason for not moving the server to another port: I need
to be able to access it from a handful of networks that lock down all
but standard ports (i.e., from within these networks, you can't
connect to remote hosts on ports other than, say, 80, 8080, 22, and
maybe a few others), so I'm not clear on how port knocking would be
any different in this aspect?

White-listing the addresses is similarly not a very practical option
for me. I wouldn't exactly call my self a "world traveler", but I do
have a tendency to connect back home from a wide variety of locations,
so I'd like to not blow off my "wobbly bits" as Moe Trin put it so
beautifully =).

As of last night, I implemented PKA-only access to ssh and have
whitelisted just a few users who are actually allowed to connect, all
of which have fairly obscure usernames that aren't likely to be
guessed by random strangers. Seems to me like a pretty good set of
authentication options, but if anyone has feedback, I'd love to hear
it. I will still be looking into some of the other options mentioned
above for black-listing attackers, as well.

Finally, just so we can all have a good laugh: The specific incident
that triggered all this was that my logwatch reported 1300 attempts to
login with my username (again, not exactly a common "oh this is
probably a username" guess that most script kiddies are likely to
try), and what's more, the source IP was my wireless router (which has
loopback). To paraphrase a well known horror movie: The call was
coming from inside the network, leading me to believe that someone in
the building had hacked my wireless network and was now trying to hack
the systems behind it. But here's the funny part: I had apparently
setup a myentunnel service on my windows laptop, set to open a tunnel
back home whenever the system started. I vaguely recall doing this
now, but totally forgot about it in the meantime. So after changing my
ssh password, this service was no longer able to connect, but boy did
it try. Hence the 1300 failed authentication attempts from inside the
network. I've disabled that service now, but I guess it all worked out
for the best, since it got me thinking about security.

-Brian

bmearns wrote:
> Thanks for all the great recommendations. I'm especially interested in
> iptable rate-limiting and port-knocking, which I will be looking more
> into.

With SuSE Linux iptables. Change the line numbers (21 and 22) to your needs:

# iptables --insert input_ext 21 -p tcp -m state --syn --state NEW
--dport 22 -m limit --limit 1/minute --limit-burst 2 -j ACCEPT
# iptables --insert input_ext 22 -p tcp -m state --syn --state NEW
--dport 22 -j DROP

Works here.

Günther

On Fri, 25 Jul 2008 05:45:08 -0700, bmearns wrote:

> This is
> also my main reason for not moving the server to another port: I need to
> be able to access it from a handful of networks that lock down all but
> standard ports (i.e., from within these networks, you can't connect to
> remote hosts on ports other than, say, 80, 8080, 22, and maybe a few
> others), so I'm not clear on how port knocking would be any different in
> this aspect?

There are some fun variations on port knocking. For example, what about
a login-protected https:// URL? A connection there causes the iptables
entry that opens the port to the transmitting URL. The down side is that
a forced web proxy can mess with this, esp. if the sender is in RFC1918
address space.

Another is eavesdropping (via logging to syslog which is directed to a
pipe that a daemon is reading) on the query stream of a DNS server. The
proper query from a given IP opens SSH access to that IP. This only
works if the sending computer is permitted to make DNS requests directly
(as opposed to via separate resolvers).

- Andrew