Request for added functionality - tracking and blocking attacks

[Doug Poulin]

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
>