-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Philip Yarra wrote: > I was thinking in terms of making your changes settable through configuration, > so people who need to do non-root auth can change the behaviour through > config, with default behaviour to be root-only. Does that sound like a useful > thing to other people? At the moment it just dies quietly if it's not running as root - I think I'd prefer to change the default behaviour so it at least gives you a warning. >>Thinking about it, have you considered public/private key authentication? > Yep, I use key authentication only, and I also restrict users by AllowUsers > directive in sshd_config. All dropped SSH connects get logged, and my > ~/.bash_profile runs a script to show me who has been trying to log in. > > I don't want to risk losing my membership of the Tinfoil Hat Brigade, you > know. I don't think there's any danger of that... :-) > Yes, that's one of the drawbacks. The main advantage I can see is to deal with > the four brazilian (obligatory George Bush joke) brute force attempts that I > get from China and Korea (mainly) when I open up SSH ports to the whole > world. I managed to stop those quite easily - just change to a non-standard port number! :-) > Security is hard, I guess. :-) I've been playing with pam_abl and pam in general and so far have discovered the following: pam_abl doesn't work properly with authentication with the likes of php and apache - it incorrectly detects correct logins as failures. Unsurprisingly, you can't setuid library modules. To access shadow passwords pam_unix uses a setuid helper application. I'm not sure how this would work with pam_abl (or similar) at the moment as passing data to be written to the database could be vulnerable to use by a malicious user... Unless it's passed encrypted... Or the file's encrypted, or maybe both... I shall think about this a little more in the morning... It appears that httpd and php authentication use both auth and account in pam - so I'm still in favour of having a module which functions similarly to pam_tally; tentatively increasing the fail count with auth and decreasing it with a successful account. This would have the side effect of temporarily denying concurrent authentication phases that exceed your fail count... but that sounds like a feature to me! >>I was initially attracted to the idea of combining pam_abl with blocking at >>the network level, but I now feel that I would prefer the attacks to get >>through to pam_abl - at least then the attacker will have no idea that they >>are blocked and if they stumble upon the right password it will just >>(hopefully) be refused by pam_abl and they will continue searching! > Yeah, good point, though from what I've seen most of these attacks are done by > automated tools, so while I do approve of inconveniencing real live people, > in terms of slowing down an attack tool, I'm not sure if letting them try a > bunch of doomed login attempts would take more or less time than waiting for > a SYN/ACK that will never arrive. ... and then restart their attack where they left off once they're unblocked? I'd rather it continued completely oblivious! :-) > I guess it's really six of one, half a dozen of the other anyway. Yup - 'fraid so! Ben -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQ0Wa0ugNmph0Y1E2AQLnfA//abEuc0mfknouPxVfJ4cNt8buSPesPj1F zIX8TMDu99jX75Y5N3qQCUjxJ0iBD0+b1eW3dRiM3+2wYf6OK/MI9eocBijYpi6T FBq3YA810BfeMVK7md7GYzgZqwewxA0ViWErrBvXDWjutaaWl7CBm+d8XCszSFch cK7xTVi7NPpvepSZubj3RZcDZvZA2r7WTFV7lU2mDgq64bNfhpPq6GBXLpKD6P4W NA5fs0iaRCNogCBqlhEYmd2Pqjn74H5arqnUtTHZFVml6JtiW46tMdrU1j+ax0Xz D78eZbD/HG6fmhdM9qJ3V/zYsrcPARdQPmwm6Q6s2f0j3d6kEHu6aC0FXyrtRQm9 P6m5MIQil9D761msVHWBfn4CwiGuFmOrzjJRa0o5OXM6TUt7BViSuj9jp48Bga9w h80RcoPtHY+0vlZpkaWObs1GCpb5TaTeRdUANoE9NhuLF6puntP882P1U1CGEc7N U2ejDSdK6BClSwSNhQr88BlKcCsXyP/tbWnShptPa21D6tLZrM8QdLhA9uk+se03 qmfKKrTkzw6fsU0WcDzjbWcox6gYtioIiMtb0PkHjSMI9w3Zru7JsTlotV0g0oSF HhDNQZzh5X8koV/lzVCAAe7UFiSn8zW76kI/dTdT1TFTzi2LTsHNdkzKEaDsLH7u zpnRh4HvYZs= =Y1J2 -----END PGP SIGNATURE----- _______________________________________________ Pam-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/pam-list