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 <mearns.b@gmail.com> 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 <mearns.b@gmail.com> 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.

On Thu, 24 Jul 2008 17:59:09 GMT, Unruh <unruh-spam@physics.ubc.ca> wrote:
>bmearns <mearns.b@gmail.com> 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

check out denyhosts

It is also distributed. If somebody trys to break in to several denyhosts
protected systems, the word will go out and everybody will pre-emptively block
the attacker.

"bmearns" <mearns.b@gmail.com> wrote in message
news:103d250f-85a7-4240-aa96-81c1a8f2a85d@26g2000hsk.googlegroups.com...
> 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.

On Thu, 24 Jul 2008, in the Usenet newsgroup comp.os.linux.networking, in
article <103d250f-85a7-4240-aa96-81c1a8f2a85d@26g2000hsk.googlegroups.com>,
bmearns wrote:

NOTE: Posting from groups.google.com (or some web-forums) dramatically
reduces the chance of your post being seen. Find a real news server.

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

This question comes up constantly, and has been answered many times.

Are you a world traveler, or do you have users authorized to log into
your system from every IP address in the world? You'll find you will
waste less CPU cycles by configuring your firewall to only allow
connections to your SSH server from IP addresses you actually expect
may have a legitimate reason to connect. For me, that means allowing
just 1536 IP addresses (a /22 and two /24s) out of the 2676890800 IPv4
addresses in current use in the entire world.

What you are seeing is skript kiddiez and bots - and one thing they are
sure of is that you must only run an SSH server on port 22. A very
common solution that defeats this knowledge is to move your server to
a "high" port. Your Linux distribution comes with a network exploration
tool called 'nmap' - look at the documentation that comes with this
tool, and locate a file named 'nmap-services' which will show port
numbers to avoid. Before you think "SECURITY THROUGH OBSCURITY!"
remember that moving the server location in no way changes the
authentication mechanisms you have in place - you still need a valid
username and authentication token to get in.

Seeing as how you are posting from a search engine, you might also
try searching for 'port knocking' - a technique that requires a valid
user to first attempt to connect to some unusual port number which is
closed on your end. The port knocker daemon is listening for such
connection attempts, and can then open what-ever port you have hidden
the SSH server to that address ONLY, and only for a short time needed
to get the connection running. This is useful in cases where your
remote system is otherwise restricted from making connections to
non-standard ports/services. Again, this isn't 'Security Through
Obscurity' because you still require the authentication mechanism
as above.

>For example, if a particular address tries and fails three times to
>authenticate, that address is blocked for three hours, or something
>similar?

There are a number of such tools available - everything from fail2ban
to PortSentry and others. While blocking for a "short time" such as
three hours is better than inserting a permanent block, it is still a
good way to shoot yourself in the wobbly bits - Self Denial Of Service'
is far from unknown.

Another technique is available in the iptables firewall - rate limits.
See http://www.netfilter.org/documentation/HOWTO/ for a number of
documents that discuss the technique and rules.

Old guy

-----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, in the Usenet newsgroup comp.os.linux.networking, in
article <c115e89f-027d-4865-aaa3-9f9c7941f2d4@z6g2000pre.googlegroups.com>,
bmearns wrote:

NOTE: Posting from groups.google.com (or some web-forums) dramatically
reduces the chance of your post being seen. Find a real news server.

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

Mmmmm... not the greatest selection, but given those three ports ONLY
to work with, I'd put the SSH server on port 80, and have the knocker
daemon listening on 8080 (although these numbers are FAR from the
optimum selection). Idea is that 8080 is closed on this server. The
good guy out there uses any network application (web browser, telnet,
ftp, ssh - ANYTHING that can be told to try to connect to a specified
port) and tries to connect to 8080. Give it a couple of seconds (to
resolve the address, get it's head out of where-ever, and send a SYN
packet to that port) then kill it. On the server end, the knocking
daemon notes the (failed/incomplete) connection attempt to 8080 that
came from IP address $FOO. It then opens (via temporary firewall rule)
the server port (in this example, 80) to address $FOO - for one
minute only, and then it removes that rule. On the remote, you
then tell your SSH client to connect to the server on port 80. You
have one minute for the firewall on the server to see this connection,
and let it get ESTABLISHED (look that keyword up in the HOWTO), and
away you go.

Now I say that '80', '8080', and '22' is far from the optimum set of
ports to use - obviously because 80 and 8080 are commonly used for
web services, and these are likely to be scanned, probed, inspected,
folded, and mutilated by common port scanning tools. '443' is also
likely, but would be better than 80 by a small amount. You have to
know what ports are available and likely to be allowed past firewalls
(outbound to remote 25 is often blocked except from the mail server
in an effort to control zombie spam), verses the ports that skript
kiddiez and bots will be scanning. Not easy task to find something
that will work everywhere.

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

Yeah, it's really bad when you are using a shotgun. None the less, I
would strongly recommend that you look at address ranges. You will see
that some ranges have no real need to connect to your server.

>As of last night, I implemented PKA-only access to ssh and have
>whitelisted just a few users who are actually allowed to connect

That _alone_ goes a long way to protect your systems.

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

<cringe>

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

<CRINGE!!!>

>I've disabled that service now, but I guess it all worked out for the
>best, since it got me thinking about security.

And that also is a major help. (I hope that laptop was never leaving
the building - auto-connects with hard coded passwords are a massive
security hole.)

Old guy