I have sshd set to drop after 2 failed attempts. I have blockhosts set for a trigger of 5. Now, with the script running for each connection (and no lag seems to be caused by this setup), why do ssh attacks still go into the 100's? The sshd daemon is linked with libwrap, so I know that's not the problem. Help? Perhaps I just need to modify the script so it's run as a daemon, too? Have it sit there and process log entries as they are made? Seems that would add a bit of overhead, but would that be the only way to block these attacks in under 100 attempts?
Travel Travel reports, it is all about food
Montreal: Schwartz's, Le Petit Alep
Albums: Pictures and some notes
ITRANS Song Book Hindi, Urdu, Marathi song lyrics
Online ITRANS Web Interface
BlockHosts block hosts
BlockHosts FAQ
BlockHosts Forum
CD Inserts & Envelopes Web Interface
Nisha Ganatra's Films
Cake: starring Heather Graham
Email: avinash@aczoom.com
Copyright © 1995-2016 Avinash Chopde, avinash@aczoom.com
probably not being invoked?
The script is pretty small, so there shouldn't be much delay - certainly not enough to allow 100s of connections.
blockhosts.py should be able to disable the sshd access within a few seconds - so if you have set blockcount to 5, it should certainly not allow more than 7-9 logins, before entering a blocked line in hosts file.
So, you should look at your log files - add
--echo "%c-%s"
to your blockhosts.py invocation, and look at the appropriate syslog files, matching sshd attempts and blockhosts.py action.
Most likely the tcpd wrappers are not working, or sshd is not dropping the connection after 2 attempts as per your setting, or the configuration of blockhosts.py is causing this problem.
I've been using
I've been using "/usr/bin/blockhosts.py --verbose --echo "%c-%s" >> /var/log/blockhosts.log" to run the script. The logs show multiple copies of the script trying to run (not too often, though), but that shouldn't be the reason for 100's of attempts to get through. If I didn't know better, I'd say that the 4th parameter (the " : deny" part) is preventing OpenSSH, and likely xinetd, from properly responding to the entries. Maybe it sees that as a error and ignores the line?
openssh should be fine
OpenSSH should work fine - most likely SSHD is not being wrapped by the tcp wrappers, or the the hosts.allow order of sections is not correct (as described in the INSTALL file).
The : deny value should be the third (not fourth) parameter in hosts.allow, for example, here's a currently blocked IP address in my hosts.allow:
ALL: 10.43.135.254 : deny
...
#bh: ip: 10.43.135.254 : 10 : 2006-09-10-04-29
The second line shows count - threshold is 7, and within 10 attempts, all future attempts are blocked.
I mis-counted. It is the
I mis-counted. It is the 3rd parameter in the file (and I'm using hosts.deny for the script, just to keep them seperate). Perhaps the problem is that the libwrap that OpenSSH is linked with only looks at hosts.allow. I might try changing things around for a week and see if that makes the difference. I -know- the hosts.allow file is being looked at as I made a typo in there and blocked all ftp/ssh traffic for about 8 hours. Luckily, I also have webmin on that server and was able to fix my goof without waiting for my next day off of work to swing by where the server is located.
Also, from what I'd seen online from my own checks, I ended up making a patch to vsftpd (it comes with the Fedora Core distributions, or has for the last 3 versions, anyway) to have a configurable max authorization tries before it drops the link. Seems a connected system could run -thousands- of attempts on the same connection (after my patch, that dropped into the 100-150 range, too). I need to clean up the changes a little, make an official patch file, and make it available if anyone wants it.
more on vsftpd in another thread
Yes, vsftpd is not well suited to blocking based on tcpd wrappers.
This thread has more info: vsftpd not well suited to tcpd wrappers
As for hosts.deny vs hosts.allow, I have not seen any case where only one of the files is being used.... only thing to watch for is the order of processing - once a host is matched, the system stops looking for other rules, or moving to the next file.
As far as vsftpd goes,
As far as vsftpd goes, that's why it's not being run in daemon mode. ;) Still, is was supposed to use the wrappers and didn't seem to, so I I turned off that support. xinetd is looking at the hosts.allow/hosts.deny files, however, and thus should be denying further access to the FTP port. And for the order of things, hosts.deny is -supposed- to be the first thing checked, from what I've read, and the blockhosts.py data is all that was in there. As of now, I moved that to hosts.allow and placed it at the top of the file. The processing order of these files is well doumented, and this isn't my first time running a unix system (been doing so for over 10 years).
And, in case it was missed before, I have made a patch to the vsftpd source that DOES drop the connection after a configurable limit of failed attempts. The patch sets a default of 5, but that can be changed with the configuration file (I didn't bother making it a command line parameter).
I should have looked for new source
The vsftpd source was updated 2 months ago and already has a max login failure setting added in. That version was released 2 months ago (and I last check about 4 months ago).
d'oh!
I think I found where it was slacking in response time. I had a typo (more like a brain fart) that basically skipped the hosts.deny file. When you want 1 specific port open, no matter what (because it's controlled by a fake process to catch would-be hackers), it helps to specifiy the daemon and not use ALL for the daemon list. Just caught that when I was adding something else to my hosts.allow file. While the hosts.deny should work now, I'll just leave it all in hosts.allow to keep it all in 1 file. This isn't my first goof when editing the system config after 8 hours of work, and I doubt it'll be my last.