On 7 December 2011 12:46, Lamar Owen <lowen@xxxxxxxx> 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@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
