Olf, Now I'm confused about what you're trying to accomplish. (Which OS X are you on, by the way?) Is sshd not logging to secure.log? If so, then denyhosts will see the attempts--whenever the daemon wakes up. I run my DH (denyhosts) daemon every thirty seconds (it's just a short python script). Yes, sshd forks with every log in attempt and the kernel does not repeat process ids except upon restart, but those processes have a very short life span (only as long as the connection lives). The fact that you're running into 10s of thousands of pids isn't cause for concern, but you can reboot the machine if you don't like seeing them.
Neither sshd nor denyhosts can do anything about disallowing connection attempts before the user is identified (bear in mind that if the user name isn't passed with the connection, like in your first example, then PAMd responds asking for a username), unless of course you simply turn off the sshd daemon. Programs like Snort (IPS/IDS) try to do this however. Out of curiosity, did you build denyhosts yourself or are you using the one from the fink project? --Robert Olaf Klinke wrote: > Thanks for your response. > My configuration of sshd is the same in this respect. I never need > root to log in remotely. My issue is more of a DoS nature, since > during an attack my launchd fires up dozens of instances of sshd, > each dealing with a limited number of connections. > But thinking more about how I believe the DH daemon works, it > seems unavoidable that the average resonse time to an attack is > half of the DAEMON_SLEEP value. > > Another solution specific to launchd might be the following: > As far as I know, on OS X the launchd does not start the > sshd binary directly, but some wrapper script. Therefore it > might be possible (though not very wise) to tweak the wrapper > script in such a way that it wakes up the DH daeman and have > it inspect what the sshd instance just started is logging. > > Olf > >> You can set your denyhosts configuration to disallow all sshd logins >> to the root account with a short daemon sleep period. I do this and >> it works just fine. (I can do this because I have absolutely no >> reason to login in remotely with the root account, you might not be >> so fortunate.) --Robert >> >> Olaf Klinke wrote: >>> Hi all, >>> Being very satisfied with my freshly installed denyhosts, I am >>> already becoming greedy. As Lars Behrens pointed out to this list >>> in 2008, a typical attack looks like this: >>> Aug 29 18:42:14 kuratowski sshd[36849]: Did not receive >>> identification string from 219.140.165.74 >>> Aug 29 18:47:00 kuratowski sshd[36856]: User root from >>> 219.140.165.74 not allowed because not listed in AllowUsers >>> After this the usual attack goes on using a dictionary of user names >>> until the denyhosts daemon wakes up and puts an end to this. >>> Note the 5 minute gap between the first connect which I read as a >>> verification of an actual sshd listening on port 22, and the attack >>> itself. >>> Therfore my guess is that denyhosts should be easily capable to >>> respond to such an attack early even with a quite liberal >>> DAEMON_SLEEP value. Any ideas? Shouldn't the DH daemon when waking >>> up during an attack notice the fist connect and include it in the >>> DENY_THRESHOLD_* count? >>> Am I right that the first and second connect above are handled >>> differently by DH because the first one does not yield a user name? >>> Thanks, >>> Olf > ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Denyhosts-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/denyhosts-user
