Request for added functionality - tracking and blocking attacks

[Jim Knoble]

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