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
<hoogen...@bio.umass.edu>
---------------
Erdös 4
