Bug#333081: libpam-abl ITP (update)
On Wed, Mar 22, 2006 at 09:06:03AM -0600, Chad Walstrom muttered these words: [ ... ] > Eric, if you could sponsor the package, that would be great. I > personally have no time to take on more packages. Will do Chad, thanks. Nicolai, good to see your still interested in libpam-abl. I'll grab your package from mentors and get back to you after I've had a chance to look it over. Thanks, -- Eric Evans [EMAIL PROTECTED] signature.asc Description: Digital signature
Bug#333081: libpam-abl ITP (update)
Nicolai Ehemann <[EMAIL PROTECTED]> wrote: > The recording of failed attempts on hosts and users definetly _is_ > working, but as many failed login attempts are made to non-existing > users, _these_ attempts are not recorderded in any way (not in hosts > nor in users), because the libpam_abl module is simply not reached > in the chain. This was not my experience. We should definitely examine your sshd_config setup as well as the order of your pam stack. -- Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#333081: libpam-abl ITP (update)
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 Hi, > Regarding libpam_abl's shortcommings, I'm surprised that an autopurge > isn't implemented, and I'm equally surprised that it doesn't track > failed attempts on known users. I had ran some tests, albeit not > extensive, on this and I believe it recorded failed attempts for known > users. It would be relatively useless if it didn't. I was also under > the impression that it has two types of blocking, host level and user > level. By your account, host level blocking isn't working? Again, > this would be a very large detriment to the package, making it less > than useful. I feared that my explanations would be confusing :-/. From what i perceived, only the autopurge isnt't implemented / working. The recording of failed attempts on hosts and users definetly _is_ working, but as many failed login attempts are made to non-existing users, _these_ attempts are not recorderded in any way (not in hosts nor in users), because the libpam_abl module is simply not reached in the chain. But, when rethinking, this could also have other reasons on my hosts, 1) the sshd having a list of AllowedLogin users (which might be checked before pam), and 2) maybe also the order in the pam chain. In any case, my problems with the new pam_abl package should be investigated before upload :). Yours, Nico -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) iD8DBQFEIWraYm+MkvsfJ58RAzrxAKCLEJCA1nT2w8CXOlwQOgCqq6nGIgCfeMuF nfQBDAwDuXfEcQXl1kyUAzM= =dTcl -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#333081: libpam-abl ITP (update)
Hey, Nicolai. Good to hear that you've got a package up. I packaged my own a while back using CDBS, but didn't go to the extent that you had. I cannot get to mentors for some reason right now to check it out. Regarding libpam_abl's shortcommings, I'm surprised that an autopurge isn't implemented, and I'm equally surprised that it doesn't track failed attempts on known users. I had ran some tests, albeit not extensive, on this and I believe it recorded failed attempts for known users. It would be relatively useless if it didn't. I was also under the impression that it has two types of blocking, host level and user level. By your account, host level blocking isn't working? Again, this would be a very large detriment to the package, making it less than useful. With respect to some of the DD's responses toward blocking failed login attempts, there is some wisdom in using sane parameters when implementing this type of security. However, I do believe it has a place in the stack of tools used to discourage inappropriate behavior. "Defense in Depth" is a phrase uttered repeatedly at any security courses I've taken. You have at least two DD's now that believe it has a place in the Debian archive. Eric, if you could sponsor the package, that would be great. I personally have no time to take on more packages. -- Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#333081: libpam-abl ITP (update)
OK. Note the debug output for pam_abl on my amd64 system: DEBUG: /etc/security/pam_abl.conf: host_db=/var/lib/libpam-abl/hosts.db DEBUG: /etc/security/pam_abl.conf: host_purge=2d DEBUG: /etc/security/pam_abl.conf: host_rule=*:10/1h,30/1d DEBUG: /etc/security/pam_abl.conf: user_db=/var/lib/libpam-abl/users.db DEBUG: /etc/security/pam_abl.conf: user_purge=2d DEBUG: /etc/security/pam_abl.conf: user_rule=!root:10/1h,30/1d Failed users: admin (1) DEBUG: matchperiod(0x50a380, 1, '10/1h,30/1d') DEBUG: count is 10, **rp='/' DEBUG: period is 3600, **rp=',' DEBUG: Checking 10/3600 DEBUG: howmany(3600) = 0 DEBUG: matchperiod(0x50a380, 1, '30/1d') DEBUG: count is 30, **rp='/' DEBUG: period is 86400, **rp='' DEBUG: Checking 30/86400 DEBUG: howmany(86400) = 0 Not blocking root (34) DEBUG: matchperiod(0x50a400, 34, '10/1h,30/1d') DEBUG: count is 10, **rp='/' DEBUG: period is 3600, **rp=',' DEBUG: Checking 10/3600 DEBUG: howmany(3600) = 0 DEBUG: matchperiod(0x50a400, 34, '30/1d') DEBUG: count is 30, **rp='/' DEBUG: period is 86400, **rp='' DEBUG: Checking 30/86400 DEBUG: howmany(86400) = 0 Not blocking Failed hosts: 221.0.185.126 (35) DEBUG: matchperiod(0x50a380, 35, '10/1h,30/1d') DEBUG: count is 10, **rp='/' DEBUG: period is 3600, **rp=',' DEBUG: Checking 10/3600 DEBUG: howmany(3600) = 0 DEBUG: matchperiod(0x50a380, 35, '30/1d') DEBUG: count is 30, **rp='/' DEBUG: period is 86400, **rp='' DEBUG: Checking 30/86400 DEBUG: howmany(86400) = 0 Not blocking So, it lookes like host 221.0.185.126 attempted to break in with 35 attempts, one to admin and 34 to root. My limits are actually quite high given the attack pattern. It's possible that this host spaced the attack out over a few days. I'll have to check the auth logs to verify. Note, though, that "admin" was accounted for, even though it doesn't exist on the system. $ id admin id: admin: No such user My sshd_config file has "UsePAM yes" in the last stack, but doesn't have any AllowedUsers or AllowedGroupsspecified and "PasswordAuthentication no" is set. My pam stack for ssh is: # Standard Un*x authentication. authrequiredpam_abl.so config=/etc/security/pam_abl.conf @include common-auth (Oh, and I take it back. I actually did write up a manpage for the command-line utility, transliterating it from the HTML page provided by upstream. I hadn't gotten to the point of making the pam_abl.so.5 page.) As far as purging is concerned, a cron job can be created to perform the purge on a daily or sub-daily basis. Autopurge isn't necessarily needed. For performance reasons, I wouldn't care to have it do so anyway. A unix-socket daemon that accepts events from the pam_abl.so module might be a good way to add this functionality without incurring a performance/latency hit during authentication. -- Chad Walstrom <[EMAIL PROTECTED]> http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
