[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: pam_tally and fail_locktime

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

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

Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]