Pascal Volk wrote:
On 07/21/2010 03:06 PM Leonardo Rodrigues wrote:
i was thinking on something like ...
- 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 penaltyto 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
<hoogendyk@bio.umass.edu>
---------------
Erdös 4