On 7 December 2011 12:46, Lamar Owen <lo...@pari.edu> wrote: > 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.
For passwords get g0tm1lk's list to check out what you use. http://g0tmi1k.blogspot.com/2011/06/dictionaries-wordlists.html SELinux is great but didn't save Russell Coker from having his play machine owned with the vmsplice exploit. http://etbe.coker.com.au/2008/04/03/trust-and-play-machine/ http://www.coker.com.au/selinux/play.html RSA also showed that social engineering is still an excellent vector. http://www.f-secure.com/weblog/archives/00002226.html -the offending exploit had to be retrieved from the spam folder prior to being opened spear phishing ftw Ultimately you could be running OpenBSD in a datacentre with all manners of precautions yet if the attacker can blag his/her way in then your data is still all gone. It'll cost them a *lot* more money than running autopwn against /8s but the pay off will be higher. Rigorous patching, non-default ports, key based authentication, fail2ban/denyhosts, port knocking, SELinux &c are useful in increasing the cost of breaking into boxen above the (drive-by/skiddie) breakpoint of almost free but from that point onwards you need to balance potential cost of break-in against cost of prevention. mike _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
