Gang,
For months now, we're all seeing repeated bruteforce attempts on SSH.
I've configured my pf install to ratelimit TCP connections to port 22
and to automatically add IP-addresses that connect too fast to a table
that's filtered:
table <lamers> { }
block quick from <lamers> to any
pass in quick on $ext_if inet proto tcp from any to ($ext_if) port 22
modulate state (source-track rule max-src-nodes 8 max-src-conn 8
max-src-conn-rate 3/60 overload <lamers> flush global)
This works as expected, IP-addresses are added to the 'lamers'-table
every once in a while.
However, there apparently are SSH bruteforcers that simply use one
connection to perform a brute-force attack:
Aug 18 00:00:01 aberdeen sshd[87989]: Invalid user serwis from 83.19.113.122
Aug 18 00:00:03 aberdeen sshd[88010]: Invalid user serwis from 83.19.113.122
Aug 18 00:00:05 aberdeen sshd[88012]: Invalid user serwis from 83.19.113.122
Aug 18 00:00:10 aberdeen sshd[88014]: Invalid user serwis from 83.19.113.122
Aug 18 00:00:13 aberdeen sshd[88019]: Invalid user serwis from 83.19.113.122
Aug 18 00:00:14 aberdeen sshd[88021]: Invalid user serwis from 83.19.113.122
My theory was/is that this particular scanner simply multiplexes
multiple authentication attempts over a single connection. I 'used the
source luke' of OpenSSH to find support for this theory, but found the
source a bit too wealthy for my brain to find such support.
So, my question is: Does anyone know how this particular attack works
and if there's a way to stop this? If my theory is sound and OpenSSH
does not have provisions to limit the authentication requests per TCP
session, I'd find that an inadequacy in OpenSSH, but I'm probably
missing something here :)
Regards,
Pieter
On 8/19/06, Pieter de Boer <pieter@thedarkside.nl> wrote:> This works as expected, IP-addresses are added to the 'lamers'-table > every once in a while. > > However, there apparently are SSH bruteforcers that simply use one > connection to perform a brute-force attack: > > Aug 18 00:00:01 aberdeen sshd[87989]: Invalid user serwis from 83.19.113.122 > Aug 18 00:00:03 aberdeen sshd[88010]: Invalid user serwis from 83.19.113.122 > Aug 18 00:00:05 aberdeen sshd[88012]: Invalid user serwis from 83.19.113.122 > Aug 18 00:00:10 aberdeen sshd[88014]: Invalid user serwis from 83.19.113.122 > Aug 18 00:00:13 aberdeen sshd[88019]: Invalid user serwis from 83.19.113.122 > Aug 18 00:00:14 aberdeen sshd[88021]: Invalid user serwis from 83.19.113.122 > >It looks as though you need to lower 'MaxAuthTries' in your sshd_config file, as the default is set to allow six authentication attempts per connection. You'll find this in the sshd_config(5) man page. Scot -- DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, 19 Aug 2006, Pieter de Boer wrote:> Gang, > > For months now, we're all seeing repeated bruteforce attempts on SSH. I've > configured my pf install to ratelimit TCP connections to port 22 and to > automatically add IP-addresses that connect too fast to a table that's > filtered: > > table <lamers> { } > > block quick from <lamers> to any > > pass in quick on $ext_if inet proto tcp from any to ($ext_if) port 22 > modulate state (source-track rule max-src-nodes 8 max-src-conn 8 > max-src-conn-rate 3/60 overload <lamers> flush global) > > > This works as expected, IP-addresses are added to the 'lamers'-table every > once in a while. > > However, there apparently are SSH bruteforcers that simply use one connection > to perform a brute-force attack: > > Aug 18 00:00:01 aberdeen sshd[87989]: Invalid user serwis from 83.19.113.122 > Aug 18 00:00:03 aberdeen sshd[88010]: Invalid user serwis from 83.19.113.122 > Aug 18 00:00:05 aberdeen sshd[88012]: Invalid user serwis from 83.19.113.122 > Aug 18 00:00:10 aberdeen sshd[88014]: Invalid user serwis from 83.19.113.122 > Aug 18 00:00:13 aberdeen sshd[88019]: Invalid user serwis from 83.19.113.122 > Aug 18 00:00:14 aberdeen sshd[88021]: Invalid user serwis from 83.19.113.122 > > > My theory was/is that this particular scanner simply multiplexes multiple > authentication attempts over a single connection. I 'used the source luke' of > OpenSSH to find support for this theory, but found the source a bit too > wealthy for my brain to find such support. > > So, my question is: Does anyone know how this particular attack works and if > there's a way to stop this? If my theory is sound and OpenSSH does not have > provisions to limit the authentication requests per TCP session, I'd find > that an inadequacy in OpenSSH, but I'm probably missing something here :)Isn't it the "MaxAuthTries" option for sshd which provides such functionality? Please look for "MaxAuthTries" in the sshd_config(5) manpage for details. regards Joerg - -- The beginning is the most important part of the work. -Plato -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (FreeBSD) iD8DBQFE54MNSPOsGF+KA+MRAh0GAJ45v4C9+xJ5vy+4BPltXwBxpKzzIwCePWa8 o/XSdoB2tFdMXQv1Yo1rwFU=dHjL -----END PGP SIGNATURE-----
Take a look at /usr/ports/security/bruteforceblocker. It monitors the system log for failed ssh logins, and blocks the sites via pf. It's reasonably configurable, and works very well. I've been running it for months without trouble. Note that it lets you whitelist specific hosts to prevent against someone DOSing you by forging your IP address. --lyndon
Hello Pieter, Saturday, August 19, 2006, 9:48:49 PM, you wrote:> Gang,> For months now, we're all seeing repeated bruteforce attempts on SSH. > I've configured my pf install to ratelimit TCP connections to port 22 > and to automatically add IP-addresses that connect too fast to a table > that's filtered:> table <lamers> { }> block quick from <lamers> to any> pass in quick on $ext_if inet proto tcp from any to ($ext_if) port 22 > modulate state (source-track rule max-src-nodes 8 max-src-conn 8 > max-src-conn-rate 3/60 overload <lamers> flush global)> This works as expected, IP-addresses are added to the 'lamers'-table > every once in a while.> However, there apparently are SSH bruteforcers that simply use one > connection to perform a brute-force attack:> Aug 18 00:00:01 aberdeen sshd[87989]: Invalid user serwis from 83.19.113.122 > Aug 18 00:00:03 aberdeen sshd[88010]: Invalid user serwis from 83.19.113.122 > Aug 18 00:00:05 aberdeen sshd[88012]: Invalid user serwis from 83.19.113.122 > Aug 18 00:00:10 aberdeen sshd[88014]: Invalid user serwis from 83.19.113.122 > Aug 18 00:00:13 aberdeen sshd[88019]: Invalid user serwis from 83.19.113.122 > Aug 18 00:00:14 aberdeen sshd[88021]: Invalid user serwis from 83.19.113.122> My theory was/is that this particular scanner simply multiplexes > multiple authentication attempts over a single connection. I 'used the > source luke' of OpenSSH to find support for this theory, but found the > source a bit too wealthy for my brain to find such support.> So, my question is: Does anyone know how this particular attack works > and if there's a way to stop this? If my theory is sound and OpenSSH > does not have provisions to limit the authentication requests per TCP > session, I'd find that an inadequacy in OpenSSH, but I'm probably > missing something here :)try http://legonet.org/~griffin/openbsd/block_ssh_bruteforce.html or my pet project http://danger.rulez.sk/projects/bruteforceblocker/> Regards, > Pieter-- Best regards, Daniel mailto:danger@FreeBSD.org
On 19/08/06, Pieter de Boer <pieter@thedarkside.nl> wrote:> Gang, > > For months now, we're all seeing repeated bruteforce attempts on SSH. > I've configured my pf install to ratelimit TCP connections to port 22 > and to automatically add IP-addresses that connect too fast to a table > that's filtered: > > table <lamers> { } > > block quick from <lamers> to any > > pass in quick on $ext_if inet proto tcp from any to ($ext_if) port 22 > modulate state (source-track rule max-src-nodes 8 max-src-conn 8 > max-src-conn-rate 3/60 overload <lamers> flush global) > > > This works as expected, IP-addresses are added to the 'lamers'-table > every once in a while. > > However, there apparently are SSH bruteforcers that simply use one > connection to perform a brute-force attack: > > Aug 18 00:00:01 aberdeen sshd[87989]: Invalid user serwis from 83.19.113.122 > Aug 18 00:00:03 aberdeen sshd[88010]: Invalid user serwis from 83.19.113.122 > Aug 18 00:00:05 aberdeen sshd[88012]: Invalid user serwis from 83.19.113.122 > Aug 18 00:00:10 aberdeen sshd[88014]: Invalid user serwis from 83.19.113.122 > Aug 18 00:00:13 aberdeen sshd[88019]: Invalid user serwis from 83.19.113.122 > Aug 18 00:00:14 aberdeen sshd[88021]: Invalid user serwis from 83.19.113.122 > > > My theory was/is that this particular scanner simply multiplexes > multiple authentication attempts over a single connection. I 'used the > source luke' of OpenSSH to find support for this theory, but found the > source a bit too wealthy for my brain to find such support. > > So, my question is: Does anyone know how this particular attack works > and if there's a way to stop this? If my theory is sound and OpenSSH > does not have provisions to limit the authentication requests per TCP > session, I'd find that an inadequacy in OpenSSH, but I'm probably > missing something here :)There were tons of discussions on this topic on misc@OpenBSD mailing list, so you can try searching the archives for some more ideas. This is just one thread that I've found now, called "is there a way to block sshd trolling?": http://arkiv.openbsd.nu/?ml=openbsd-misc&a=0&t=1325006. Most of these attacks come from compromised Linux hosts, so if you use pf(4), you could easily block access to ssh port from any Linux machine, and then you're mostly covered. :) See http://arkiv.openbsd.nu/?ml=openbsd-misc&a=0&m=1332409. Cheers, Constantine.
Hello! On Sat, 19 Aug 2006, Pieter de Boer wrote:> For months now, we're all seeing repeated bruteforce attempts on SSH. I've > configured my pf install to ratelimit TCP connections to port 22 and toI wonder why OpenSSH still doesn't support simple and nice feature of SSH.COM's sshd2_config: LoginGraceTime 60 AuthInteractiveFailureTimeout 10 These settings effectively cause robots to stop the scan for me. Every scan attempt gives only 1..N failed attempts (where N=number of externally-reachable and SSH-served IPs on machine if robot is capable of simultaneous scan of several IPs), so I can just ignore them. Sincerely, Dmitry -- Atlantis ISP, System Administrator e-mail: dmitry@atlantis.dp.ua nic-hdl: LYNX-RIPE
Personally I have solved the problem in a different way.
I let sshd listen on port 22 as well as a different port
(e.g. 322). In the packet filter configuration (IPFW in
my case) the alternate port is open from anywhere, but
port 22 is restricted to a few well-known IPs.
Most of those automated SSH scans only scan networks on
port 22 (for efficiency, I assume), so they never hit the
alternate port. If they scan port 22, they're dropped
silently.
The result is that I get zero scans in my logs and the
nightly reports. I can log into the machines normally
from my usual workstations. And if I'm somewhere where
port 22 isn't allowed, I can still log in using the
alternate port number.
In fact, I could get rid of port 22 altogether. You can
set the default port number per host in ~/.ssh/config,
so you don't have to type the port number every time.
Note that this is _not_ a security measure (it would only
be "security by obscurity" anyway). It's only to get rid
of the annoying scans. You still have to use good pass-
words (or use other authentication, such as ssh keys),
and make sure that you do not allow root (or other pseudo
users) login via ssh passwords.
Best regards
Oliver
PS: I try to avoid things like automatic blocking of IP
addresses. They can be dangerous, because such automatisms
can be used to run DoS attacks against you, by spoofing
source IPs. Whitelists can help a bit, but you still have
to be extremely careful.
I know one case where someone had a similar setup, blocking
IPs completely (not just port 22) if there have been too
many connection attempts. He whitelisted the IP addresses
of the workstations from which he was usually connecting
with ssh, and so he assumed he was save. Well, until a
"friend" of him ran an SSH scan against the machine,
spoofing the IP addresses of his DNS servers, in effect
putting the machine offline. :-)
--
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
I suggested holding a "Python Object Oriented Programming Seminar",
but the acronym was unpopular.
-- Joseph Strout
> -----Original Message----- > From: owner-freebsd-security@freebsd.org > [mailto:owner-freebsd-security@freebsd.org] On Behalf Of Uwe Doering > Sent: Tuesday, August 22, 2006 4:09 AM > To: freebsd-security@FreeBSD.ORG > Subject: Re: SSH scans vs connection ratelimiting > > that someone could fake a complete exchange like this from the remote > via a TCP connection while using source IP address spoofing. My > understanding so far is that source IP address spoofing from > the remote > works only with connectionless protocols like UDP and ICMP, > or TCP SYN > packets as a special case. Please correct me if I'm wrong.You are more or less correct. For all practical purposes, spoofing a three way tcp connection is impossible. (for all practical purposes) There is man in the middle attacks, routing hijacking, and possibly tcp connection id spoofing, but if you are using a modern os that does not suffer from connecting id guessing, its so hard to do that that only someone specifically trying to break into your network, who has the ability to sniff your traffic, might even have a ghost of a chance of doing this. (and if you already have the *keys from known_hosts, ssh will complain about it if it even gets that far) -- Michael Scheidell, CTO 561-999-5000, ext 1131 SECNAP Network Security Corporation Keep up to date with latest information on IT security: Real time security alerts: http://www.secnap.com/news
Just to put an end to this sillyness :) A few days ago, I wrote:> For months now, we're all seeing repeated bruteforce attempts on SSH. > I've configured my pf install to ratelimit TCP connections to port 22 > and to automatically add IP-addresses that connect too fast to a table > that's filtered:<snip>> This works as expected, IP-addresses are added to the 'lamers'-table > every once in a while. > > However, there apparently are SSH bruteforcers that simply use one > connection to perform a brute-force attack:As mysteries go, this one was a PEBKAC, too. My pf config had a 'deny all'-statement, but only for the external interface. A tunnel interface wasn't filtered in any way and no ratelimiting was taking place for the SSH daemon bound on that tunnel interface's address, hence the succeeding scans. Sorry for the confusion, Pieter