Request for added functionality - tracking and blocking attacks
dougp at medinet.ca
Fri Jun 13 09:37:26 EST 2008
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.
----- 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
> 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
> 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.
> David Mathog
> mathog at caltech.edu
> Manager, Sequence Analysis Facility, Biology Division, Caltech
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
More information about the openssh-unix-dev