David Mathog
2008-Jun-12 21:45 UTC
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
Doug Poulin
2008-Jun-12 23:37 UTC
Request for added functionality - tracking and blocking attacks
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 > lists.mindrot.org/mailman/listinfo/openssh-unix-dev >
Jim Knoble
2008-Jun-13 07:13 UTC
Request for added functionality - tracking and blocking attacks
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: 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 | pobox.com/~jmknoble (GnuPG key ID: 6F39C2CC >>>>>> 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| +----------------------------------------------------------------------+
Reasonably Related Threads
- Calculating Portfolio Standard deviation
- Very simple traffic shaping script for H.323
- [PATCH 0/7] Various fixes for Ceph drives and parsing libvirt XML.
- Counting the occurences of a charater within a string
- [PATCH] hivex: python: value_value no longer generates Unicode strings