[Dovecot] Feature request: usernames and passwords

[Chris Hoogendyk]

Pascal Volk wrote:
> On 07/21/2010 03:06 PM Leonardo Rodrigues wrote:
>   
>>      i was thinking on something like ...
>>
>> 1) after N tries (lets say 10 for example) of wrong username/password 
>> combinations, dovecot could start delaying the answers for wrong 
>> authentications coming from that specific IP address or IP/username, 
>> thus slowing down the brute-force attacks;
>> 1.1) or even, after some M (lets say 20 for example) wrong 
>> username/password combinations, dovecot could ban that IP address (or IP 
>> address/username combination to avoid problem with big networks with NAT 
>> access) for XX seconds/minutes, also slowing down the brute-force attack 
>> tries
>> 1.2) this could probably be implemented using some in-memory internal 
>> backend, so it would be absolutely independent on passdb schema and 
>> would require no modifications on passdb schema.
>>
>>     
>
> Install dovecot 2.0.rc3 and try to 'break in'. You will see how dovecot
> slows down your 'attack'. When you test it with your botnet ( ;-) ), use
> `doveadm penalty` to see current penalties.

I should note that the patterns of attack we are seeing are extremely 
sophisticated. They are going out of their way to be "stealth" with 
respect to detection strategies. We do still see the focused brute force 
attacks where one IP futilely hammers at root (never allowed anyway), 
and where an IP tries all the various default system and application 
accounts. However, it seems that attacks are now going to distributed 
against distributed. That is to say, a large botnet (I recently 
identified 1235 IPs in one day cooperating in an attack) has a large 
list of hosts it wants to hit, and they randomize the hits across botnet 
IPs, across hosts, and across accounts being hit, with time delays 
between hits for any one host. You see this by looking across multiple 
servers and seeing the same IP trying different accounts across 
different servers, or the same account being tried by different IPs 
across different servers, and the accounts incrementing alphabetically, 
even though the IP trying them is changing.

I have only been able to tag these manually in a text oriented editor 
with multiple grep patterns to remove legitimate entries before I 
compile the list of IPs to be blocked. Then those are run through 
another script that does NS lookups and checks against already blocked 
IPs. What is left, I scan with my own eyes and remove things that could 
possibly be our own users.

Not an easy thing to deal with.

The odds of their getting into any particular server are slim, but 
that's multiplied by the huge number of servers they are hitting.

After blocking those, I continue to see steady streams of access denied 
in my auth logs, even weeks later.

These attempts are typically preceded with similarly distributed port 
scans and will hit whatever ports and protocols are available. I see 
mostly ssh, but also a significant number of attacks on pop3.


-- 
---------------

Chris Hoogendyk

-
   O__  ---- Systems Administrator
  c/ /'_ --- Biology & Geology Departments
 (*) \(*) -- 140 Morrill Science Center
~~~~~~~~~~ - University of Massachusetts, Amherst 

<hoogendyk at bio.umass.edu>

--------------- 

Erdös 4