On Sun, 16 Feb 2003, Greg A. Woods wrote:
> I'm not intimately familiar with Exim's smtp_ratelimit_* capabilities,
It's in the exim manual, and seems to do what it says on the tin...
http://www.exim.org/exim-html-4.10/doc/html/spec_13.html#IX979 etc. -
but in the "dictionary scanner" stakes, I concluded, after various
false starts, that it needed a different solution.
> but I will note that in a generic way controlling the speed at which an
> undesirable client can get anything done can indeed often help prevent
> that same client from re-connecting again and trying the same stupid
> error over again right away.
Yup. That is approaching the Teergrube philosophy, although with
4.10 you can't quite make the full Teergrube response i.e with
individual continuation lines sent at appropriate delays.
> This doesn't help with multiple connects from the same client of course,
[..]
Indeed, and this is where it failed in the dictionary-scanner stakes.
Typical scenario was, the attacker connected, tried about three dozen
RCPT TOs for random usernames, and disconnected. Some 20-30mins later
he'd be back and try the same with a fresh bunch of random usernames.
And so on.
I used the rate-limiting to spin the three dozen attempts out over
hours, but the attacker still opened a fresh call after 20-30 minutes,
so that eventually we had several of these probe series going in
parallel, and the total number of addresses probed per day seemed no
different than before. Since the attacker kept switching to different
open proxies, we could only deduce that it was the same attacker by
the modus operandi and the pattern of names being probed.
Mostly the only answer he got from us was that his IP was blacklisted
for being an open proxy, but just occasionally he'd strike lucky and
we would confirm or deny the existence of a couple of user addresses
via our reply to his RCPT TO.
What I'm doing now, when the situation is detected, the ACL goes to
sleep for more than 5 minutes, resulting in the attacker dropping the
call. So they only get a few shots at their random addresses before
the call drops. It also writes the IP to a file.
> or send DNS update requests to a suitable private DNS blacklist zone...
Indeed. Writing the IPs to a plain file is a bit crude.
When a call comes in from an IP already in the file, they get just one
shot at presenting a valid address (expected to be postmaster or abuse
;-) just in case they are a bona fide sender who had an accident with
their mailing list or whatever; if they fail at that, then they get
the >5 minute sleep as above. This seems to be quite effective.
They don't try again until their usual 20-30 minute delay lapses, so
the total number of address probes per day has been distinctly
reduced. (Wonder whether the attacker is reading this...)
Sure, they could change their strategy any time: this is a very
heuristic response, made up as we went along.
Be cautious with the above kind of approach, however: one of our
funding agencies tried to send us a circular via an email bureau,
using an old mailing list which started with several defunct
addresses. We mis-identified them as the dictionary scanner, and
their IP went into the file, cutting off not just the funding agency
but all the other customers of that bureau, until the problem was
spotted and corrected, which was rather embarrassing.
all the best
