openssh unix dev - Jun 2008 - Request for added functionality - tracking and blocking attacks

Somebody please forward this, if this is not an appropiate place
to ask the OpenSSH developers for a new feature.

As many of us have seen, any sshd left open on the internet eventually
becomes the target of password guessing attacks.  I am aware of
tools for scanning the security logs, and manipulating iptables to
block ongoing attacks, but I am not aware of a way to configure
sshd itself to detect and deter attacks.

On my systems the logs generally show a series of login attempts from
a single IP address, usually starting with common account names like
"root" or "mysql", then progressing to "diane" and
other common names.
This can go on for hours.

It would be very nice if sshd provided the following functions to help
deter these attacks.  Here is my proposal.

1.  sshd at reload or start loads a list of black listed account names.
 In the sshd_config file one or more lines like this would be placed:

BLACKLIST_USER mysql
BLACKLIST_ISER root
BLACKLIST_USER cups
etc.

2.  sshd also loads a small number of whitelisted IP addresses, which
are allowed to use the BLACKLIST user names:

WHITELIST_IP abc.def.ghi.jkl
WHITELIST_IP bca.fed.hig.klj/24
etc.

3. If a login attempt is made on a blacklisted account, but not from
a whitelisted IP address, it would result in a 

 sshd BLACKLISTED abc.def.ghi.jkl for account_name

message to syslog.  

4.  Additionally, an entry would be placed in an sshd data structure to
retain the IP address and the time of the last attempt from this IP
address.  Normal logins would of course not be placed on this list.

5.  The number of blacklisted IP addresses maintained by sshd would also
be configurable.

BLACKLIST_MAX_IP 10000

Allowing 4 bytes for the IP address plus 4 bytes for the time stamp, a
list of 10000 forbidden machines could be stored in only 80000 bytes.
An attacker might be able to fill the list, but only if they had
access to a network of 10000 machines.

6. After a configurable time

BLACKLIST_EXPIRE seconds

IP addresses which had not tried to login in more than the specified
time would be purged from this blacklist data structure.  The purpose
of this is to prevent the list from filling up when sshd has been up
for months at a time.

7. sshd would continue to "service" login attempts from 
blacklisted IP addresses, but would simply fail them all, even if
a valid username/password pair was sent. This would serve to tie
up the attacker without offering any chance of a break in by a lucky
password guess.  

8.  Lastly, in order to bog down the attacker even further,

MIN_LOGIN_TIME seconds

would set the minimum time for a response to a login attempt.
The default would be 0 seconds.  For remote servers, which only
need to be accessed via ssh for administration on rare occasions, this
might be set to 10, 20, or even 60 seconds.

An argument could be made that most of this blacklist mechanism
should reside in a common location, so that other network daemons
could share this sort of information.  One could imagine a blacklist
daemon which maintains the IP addresses, last access times, and some
measure of how "busy" each IP address is, and provides that
information
through some sort of interprocess communication to any network daemons
which request it.  This would also provide, I think,
an easier way than log file scraping for adding firewall rules 
to block an address which was overly problematic. 

Regards,
 
David Mathog
mathog at caltech.edu
Manager, Sequence Analysis Facility, Biology Division, Caltech

If you're using PAM, there is already a very nice utility called pamabl that
you can use

It does automatic blacklisting based on user configurable parameters.

ie.  If one host gets more than # (10, 20, 100, your choice) failed 
passwords you can blacklist them for
any number of days.  If a user exceeds a set number of login attempts they 
can be blacklisted for a set period of time
as well.   Might be a good open source project for someone not using PAM.

Doug

----- Original Message ----- 
From: "David Mathog" <mathog at caltech.edu>
To: <openssh-unix-dev at mindrot.org>
Sent: Thursday, June 12, 2008 2:45 PM
Subject: Request for added functionality - tracking and blocking attacks

> Somebody please forward this, if this is not an appropiate place
> to ask the OpenSSH developers for a new feature.
>
> As many of us have seen, any sshd left open on the internet eventually
> becomes the target of password guessing attacks.  I am aware of
> tools for scanning the security logs, and manipulating iptables to
> block ongoing attacks, but I am not aware of a way to configure
> sshd itself to detect and deter attacks.
>
> On my systems the logs generally show a series of login attempts from
> a single IP address, usually starting with common account names like
> "root" or "mysql", then progressing to
"diane" and other common names.
> This can go on for hours.
>
> It would be very nice if sshd provided the following functions to help
> deter these attacks.  Here is my proposal.
>
> 1.  sshd at reload or start loads a list of black listed account names.
> In the sshd_config file one or more lines like this would be placed:
>
> BLACKLIST_USER mysql
> BLACKLIST_ISER root
> BLACKLIST_USER cups
> etc.
>
> 2.  sshd also loads a small number of whitelisted IP addresses, which
> are allowed to use the BLACKLIST user names:
>
> WHITELIST_IP abc.def.ghi.jkl
> WHITELIST_IP bca.fed.hig.klj/24
> etc.
>
> 3. If a login attempt is made on a blacklisted account, but not from
> a whitelisted IP address, it would result in a
>
> sshd BLACKLISTED abc.def.ghi.jkl for account_name
>
> message to syslog.
>
> 4.  Additionally, an entry would be placed in an sshd data structure to
> retain the IP address and the time of the last attempt from this IP
> address.  Normal logins would of course not be placed on this list.
>
> 5.  The number of blacklisted IP addresses maintained by sshd would also
> be configurable.
>
> BLACKLIST_MAX_IP 10000
>
> Allowing 4 bytes for the IP address plus 4 bytes for the time stamp, a
> list of 10000 forbidden machines could be stored in only 80000 bytes.
> An attacker might be able to fill the list, but only if they had
> access to a network of 10000 machines.
>
> 6. After a configurable time
>
> BLACKLIST_EXPIRE seconds
>
> IP addresses which had not tried to login in more than the specified
> time would be purged from this blacklist data structure.  The purpose
> of this is to prevent the list from filling up when sshd has been up
> for months at a time.
>
> 7. sshd would continue to "service" login attempts from
> blacklisted IP addresses, but would simply fail them all, even if
> a valid username/password pair was sent. This would serve to tie
> up the attacker without offering any chance of a break in by a lucky
> password guess.
>
> 8.  Lastly, in order to bog down the attacker even further,
>
> MIN_LOGIN_TIME seconds
>
> would set the minimum time for a response to a login attempt.
> The default would be 0 seconds.  For remote servers, which only
> need to be accessed via ssh for administration on rare occasions, this
> might be set to 10, 20, or even 60 seconds.
>
> An argument could be made that most of this blacklist mechanism
> should reside in a common location, so that other network daemons
> could share this sort of information.  One could imagine a blacklist
> daemon which maintains the IP addresses, last access times, and some
> measure of how "busy" each IP address is, and provides that
information
> through some sort of interprocess communication to any network daemons
> which request it.  This would also provide, I think,
> an easier way than log file scraping for adding firewall rules
> to block an address which was overly problematic.
>
> Regards,
>
> David Mathog
> mathog at caltech.edu
> Manager, Sequence Analysis Facility, Biology Division, Caltech
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>

Circa 2008-06-12 17:45 dixit David Mathog:

: Somebody please forward this, if this is not an appropiate place
: to ask the OpenSSH developers for a new feature.

This is an appropriate place.  The OpenSSH Bugzilla is another
appropriate place.  I am not an OpenSSH developer, just a user and an
erstwhile contributor.

  [...]

: It would be very nice if sshd provided the following functions to help
: deter these attacks.  Here is my proposal.
: 
: 1.  sshd at reload or start loads a list of black listed account names.
:  In the sshd_config file one or more lines like this would be placed:
: 
: BLACKLIST_USER mysql
  [...]
: 
: 2.  sshd also loads a small number of whitelisted IP addresses, which
: are allowed to use the BLACKLIST user names:
: 
: WHITELIST_IP abc.def.ghi.jkl

Your #1 and #2 are available using the current capabilities in OpenSSH
combined with judicious use of stateful firewall rules:

    (1) Configure your default sshd listening on TCP port 22 with either
        AllowUsers or AllowGroups directives to only allow access by
        certain users.  Preferably, configure those users to require
        public-key authentication, so that password dictionary attacks
        will never succeed.  Allow access to TCP port 22 from all the IP
        addresses you wish to using your stateful firewall.

    (2) Configure a second sshd listening on an alternate TCP port (i
        often prefer port 992) which allows your "blacklisted" users
to
        log in.  Using your stateful firewall, deny access to this
        alternate TCP port from all but your "whitelisted" IP
addresses.

: 3. If a login attempt is made on a blacklisted account, but not from
: a whitelisted IP address, it would result in a 
: 
:  sshd BLACKLISTED abc.def.ghi.jkl for account_name
: 
: message to syslog.  

Configure your stateful firewall rules to log attempts by
non-whitelisted IP addresses to contact the alternate port in my #2
above.

: 4.  Additionally, an entry would be placed in an sshd data structure to
: retain the IP address and the time of the last attempt from this IP
: address.  Normal logins would of course not be placed on this list.
: 
: 5.  The number of blacklisted IP addresses maintained by sshd would also
: be configurable.
  [...]
: An attacker might be able to fill the list, but only if they had
: access to a network of 10000 machines.

And you think that no attackers these days have that capability?  Some
botnets exceed that number by at least an order of magnitude:

http://searchsecurity.techtarget.com.au/articles/24069--Kraken-botnet-gathers-1-new-members

: 6. After a configurable time
  [...]
: IP addresses which had not tried to login in more than the specified
: time would be purged from this blacklist data structure.  The purpose
: of this is to prevent the list from filling up when sshd has been up
: for months at a time.

Your #4, #5, and #6 are not the job of sshd.  You need to inject these
entries into your firewall ruleset, with an external scrubber process.

: 7. sshd would continue to "service" login attempts from 
: blacklisted IP addresses, but would simply fail them all, even if
: a valid username/password pair was sent. This would serve to tie
: up the attacker without offering any chance of a break in by a lucky
: password guess.  

Oh, you want a honeypot.  Use one.  Configure an sshd on an IP address
or port that should never get used.  Deny all logins (using 'DenyUsers
*', or using 'AllowGroups' with a group that has no members).  Use
your
firewall to add source IPs that access that sshd to a blocklist for
every other sshd (but allow them to continue accessing the
not-really-an-sshd).

: 8.  Lastly, in order to bog down the attacker even further,
: would set the minimum time for a response to a login attempt.
: The default would be 0 seconds.  For remote servers, which only
: need to be accessed via ssh for administration on rare occasions, this
: might be set to 10, 20, or even 60 seconds.

This should probably be done using PAM, or equivalent mechanisms on
other platforms.  You could even allow valid accounts to log in
normally, but keep failed attempts taking longer by using Darren
Tucker's 'pam_faildelay.so' module in your sshd's PAM stack.

: An argument could be made that most of this blacklist mechanism
: should reside in a common location,

(such as a firewall?)

: so that other network daemons could share this sort of information.
: One could imagine a blacklist daemon which maintains the IP addresses,

(such as a firewall, with some scripting around it?)

: last access times, and some measure of how "busy" each IP address
is,
: and provides that information through some sort of interprocess
: communication to any network daemons which request it.  This would
: also provide, I think, an easier way than log file scraping for adding
: firewall rules to block an address which was overly problematic. 

What you propose can already be done, more generally and more
efficiently, using existing tools, rather than by making OpenSSH's
codebase unnecessarily more complex, brittle, and prone to failure.

Good luck,
jim

-- 
jim knoble  |  jmknoble at pobox.com  |  http://www.pobox.com/~jmknoble/
(GnuPG key ID: 6F39C2CC  >>>>>> 
http://www.pobox.com/~jmknoble/keys/ )
(GnuPG fingerprint: 5024:D578:7CF4:5660:7269::F6F3:B919:9307:6F39:C2CC)
+----------------------------------------------------------------------+
|[L]iberty, as we all know, cannot flourish in a country that is perma-|
| nently on a war footing, or even a near-war footing.  --Aldous Huxley|
+----------------------------------------------------------------------+