pam_tally and fail_locktime

[Philip Yarra]

On Thu, 6 Oct 2005 02:21 am, Benjamin Donnachie wrote:
> >Have you considered contributing it as a patch?
>
> I can do - it's really nothing as I only commented three or so lines out.

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?

> 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 really prefer to block access at the network level, so I've been looking
> >at what would be involved in using a libipq app to look up allowed dynamic
> >DNS host names 
>
> Could that be vulnerable to password attacks on no-ip or even DNS
> poisoning?

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. 

Most of the time when people ask on the iptables list "How can I let in only 
the dynamic DNS hosts I want?" they get an answer telling them to create 
their iptables scripts with the dynamic host names in them, and re-run it 
from cron every x minutes. That approach makes me really nervous.

A lot of iptables scripts seem to use host names anyway, and rely on the 
resolver to figure out the IP address, so they're already prone to DNS 
poisoning attacks. 

Security is hard, I guess. :-)

> 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. I guess it's really six of one, half a 
dozen of the other anyway.

Regards, Philip.