On Wednesday, December 07, 2011 05:32:00 AM Ljubomir Ljubojevic wrote:
> There is also use of denyhosts and fail2ban. They allow only few
> attempts from one IP, and all users can share attacking IP's (default is
> every 30 min) so you are automatically protected from known attacking
> IP's. Any downside on this protection?
Botnets. If a 100,000 host botnet hits you with a coordinated brute-force attack, fail2ban and other similar tools won't help you, as every attempt will come from a different host. This may be one way the brute-forcers appear to get in on the first or second try. And some brute-forcers are the so-called 'slow' brute-forcers that try things very slowly and never trigger some of these protections.
And don't let your guard down just because you have disabled password login and have key-based auth; if a remote exec breach is found in a different daemon that can write (or can execute a local root exploit that can then write) to /etc/ssh/sshd_config, it's game over. This is where SELinux in enforcing mode with properly configured contexts and no unconfined users can save the day. Attach access rights to sshd_config to a local console user or similar (that's one thing ConsoleKit and PolicyKit are for) and make certain other files are not writeable remotely as well.
Don't let your guard down because you have things firewalled, either. As RSA found out the hard way, all it takes is one employee opening one excel attachment with an embedded flash exploit, and 'blammo' you're pwned.
And if you think these sorts of contrivances aren't out in the wild, think again.
I have an example from the 'wild' that, once I have all the data in hand and permission to release it, will blow your mind.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
