Re: [Exim] dictionary attack

Góra strony
Delete this message
Reply to this message
Autor: Alan J. Flavell
Data:  
Dla: George Szekely
CC: Exim users list
Temat: Re: [Exim] dictionary attack
On Thu, 6 Mar 2003, George Szekely wrote:

> I've tried the following condition which seems to work only on
> request coming in at the same time.
>
> ${if = {${eval:$rcpt_fail_count}}{1}{yes}{no}}
>
> But I get hit every 5 to 10 seconds from the same IP (even the IP
> changes regularly after a while) for a different user address. Is it
> possible to insert a delay, like 3 minutes to hosts that just tried
> to hit a nonexistent user (Unrouteable address)


Well, you can, but when I tried it, it didn't seem to make much
difference to the aggregate number of rcpt to's which the dictionary
scanners were presenting to us. At that time, they were trying
something between two- and three-dozen addresses per smtp call, at
intervals of about 20 minutes. If I put in enough delays to spin
things out for, say, 30 minutes, then they'd just start up another
call after 20 minutes anyway, and the overall rate of rcpt to's was
much the same.

However, if, after having recognised the pattern of attack, we ran a
timer of > 5 minutes, they would disconnect. And would not try
again till ~ 20 minutes later, and so on. So that actually quietened
things down. That was with 4.10 - with 4.12 you could explicitly drop
the call, I gather, so no need to play with long timeouts.

Note that exim seems to time-out run commands after a minute, so we
created the long timeouts in the ACL with a series of

       condition = ${run{/bin/sleep 59}{1}{0}}
       condition = ${run{/bin/sleep 59}{1}{0}}
       condition = ${run{/bin/sleep 59}{1}{0}}


However, on some subsequent attacks they seemed to be hassling us
with retries after we've timed them out. On balance I think we're
getting some benefit out of taking action, but the rejection log is a
dreadful mess while this kind of attack is in progress.

> Or anyone has a suggestion on how to get rid of them?


I think denying the tcp connection (i.e with host_reject_connection in
the main config, or the corresponding libwrap entry) would be the only
sure way. But then, if bona fide senders are accidentally caught,
they'd have no way to even get in touch with the postmaster to get
themselves out again.

At the moment I'm letting IPs which have already written themselves
into this special local blacklist for dictionary scanning, get one
further chance (per smtp call) to present a valid rcpt to, before
timing them out as above.

hth