dictionary attacks, was Re: [Exim] (no subject)

Pàgina inicial
Delete this message
Reply to this message
Autor: Alan J. Flavell
Data:  
A: Dave C.
CC: exim-users@exim.org
Assumptes vells: Re: [Exim] (no subject)
Assumptes nous: [Exim] Re: dictionary attacks
Assumpte: dictionary attacks, was Re: [Exim] (no subject)
On Sun, 6 Oct 2002, Dave C. wrote:

> On Sun, 6 Oct 2002, Nico Erfurth wrote:
>
> the ratelimitijng does that fine.. The problem is that there are
> hundreds of these connections at once, and if they are all stalling they
> are using up resources and process slots...


Well, we haven't seen the particular ones cited on this thread, but
we've seen two kinds of dictionary attack en masse. (See the thread
about "dictionary attack defence" from around July 2002 for some
related discussions, and my mail on 24 Aug, subject "HELO syntax
check").

One group of attacks come from random addresses - many of which are
blacklisted as open proxies - presumably all of them _are_ open
proxies in fact. Often, those present a HELO name of "$domain".
Here's a sample log entry:

2002-09-22 01:16:41 rejected HELO from [210.90.111.97]: syntactically
invalid argument(s): $domain

Those attacks (the ones with "$domain" in them) have gone quiet in the
last couple of weeks, though. (I've seen a number, though smaller, of
otherwise similar looking dictionary attacks with a real domain in the
HELO).

The other lot used to come consistently from 194.198.208.46, but in
the last few days they showed up from 194.198.208.9. Both addresses
are known to Osirusoft, with the text:

se-systemaccess(ripe) Dictionary attacks ongoing for months from
194.198.208.46

> > deny condition = ${if match
> >            {$sender_helo_name}{\N\.optprofessionals\.com$\N}
> >            {${run{/bin/sleep 30}{1}{1}}{0}
> >          }


I tried something based on that at the weekend against the attack from
194.198.208.9, but it didn't really help. The attacker would still
grind through the same list of addresses - they just took that much
longer to do it, but leaving the same total amount of junk in our
rejection logs.

However, blocking them in tcp wrappers seems, so far, to have got rid
of them. Have seen two attempts to connect since then - several hours
apart. I wish I had tried it sooner (of course one would want to
verify that one's backup MX will adopt a similar policy before
deciding to block SMTP calls from particular IPs).

It's odd that although this pattern of attack from them has apparently
been on record for months, nobody seems to have got them cut off the
network yet.