[XCSSA] Strategies to combat brute password break-in attempts

[xcssa@xcssa.org]

> Message: 1
> Date: Thu, 25 Oct 2007 11:49:29 -0500
> To: xcssa@xcssa.org
> Subject: Re: [XCSSA] Logging & dynamic firewall program(s)
> From: xcssa-admin@xcssa.org
> Reply-To: xcssa@xcssa.org
> 
> Why not just something like http://www.rickk.com/sslwrap/ ?
> 
> On 10/24/07, xcssa-admin@xcssa.org <xcssa-admin@xcssa.org> wrote:
>> On Wednesday 24 October 2007 01:39:06 xcssa-admin@xcssa.org wrote:
>>>     You can see if dovecot is compiled to use tcpwrappers using ldd.  If
>>> you see it linking against libwrap then it is just a matter of sorting out
>>> what the programs name needs to be for the config file.
>>> 
>>>     Nate
>>> 
>>> 
>>> 
>>> Whew!  Thanks for the suggestion Nate - but that's way above my head.
>>> I'm not a coder, just a builder/administrator.
>> 
>> A bit harder anyway since dovecot is a modular system.
>> 
>> Chuck..
>> Another fix for watching multiple daemons (more securely than
>> allwoing/denying
>> them via xinetd IMHO) is something like swatch:
>>         http://www.trustix.org/wiki/index.php/Swatch
>>         http://swatch.sourceforge.net/
>> 
>> It does the same as DenyHosts but does many many server side protos via log
>> file groking and blocks via iptables (better than using allow/deny files)...
>> 
>> Can easily be set up for pop3, IMAP, sshd, and more.
>> 
>> Tweeks


That's cool, Tweeks, I haven't seen that before. I want to review that for
my use.

I would like to recommend another package that works with PAM built into
most Linux systems today (if not all). PAM, Pluggable Authentication
Modules, offers more compatibility than TCP Wrappers (dovecot, for example,
isn't compiled against it) and offers a line of defense at the time of the
attacker's login attempt versus catching log entries on the backside. In
addition, if PAM is unavailable no one can login, so attacks won't succeed
just because some external daemon is not running.

I like using pam_abl. The main reason, besides being a PAM module
(redundant, I know!), is that it blocks login attempts matching the attack
profile QUIETLY. After a threshold is reached of maximum allowed failures in
a given timeframe, an attacker is silently "denied" access in a way that
looks exactly like a regular password (or other credential) failure -- even
if the attacker guess the right password during the period that the attacker
is blocked. Sometimes when an attacker "knows" they are blocked they act
like breaking in is a game and try harder. In any case I don't like to give
attackers information.

Now, I make one change to the default configuration of pam_abl: I disable
"user" checking/blocking. By default pam_abl checkes hosts (IP addresses)
and users. But the pattern that attackers use these days is to iteratively
check well-known, popular and random user names. Checking
"robert@domain.tld" is not something I want blocked just because some idiot
tried guessing my password. In fact, that could be a way to perform a denial
of service. The configuration of pam_abl does allow on to set certain users
and hosts as "non-blockable", so I could just add "robert" to the default
"root" never block line, but after considering it for a while I realized I
don't care about blocking users, only hosts.

I have an article on my parsely-populated blog/wiki about pam_abl:

http://robotterror.com/site/wiki/mitigating_brute_force_password_attacks_wit
h_pam_abl

Or, if that super-long URL wraps, use this:
http://preview.tinyurl.com/yux7x3

At the end of the article I reference another technique I use to stop common
attacks, namely, using the Spamhaus list of known spammer/hacker netblocks
(the DROP list) as a source of IP ranges to always block.

I hope these are helpful, and welcome corrections, additions, suggestions
and improvements!

Robert Taylor, (A.K.A., Robot Terror)