pam_tally and fail_locktime

[Benjamin Donnachie]

-----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-----