[Dshield] Scans occurring in large bursts

Stephane Grobety security at admin.fulgan.com
Thu Feb 12 16:02:41 GMT 2004

>> Well, without knowing your configuration, I would hazard that it could
>> simply be the machine scanned sending back a SYN-ACK packet back to
>> the decoy IP. The ICMP traffic you're seeing is simply the target
>> network telling your machine that it doesn't want your packets.

JRK> The router simply drops all packets -- no feedback to the connecting system.
JRK> Also, the ICMP traffic is usually 10/8 source IPs.

You mean there is no machine at the targeted IP address ?

Maybe there is another possibility here: your attacker is scanning
several IP ranges at the same time and it's using the IP addresses of
it's target in it's decoy list as well. if that's the case, you should
be receiving ICMP traffic from routers that have blocked their access
and a LOT of ICMP from non-routable IPs.

As for why scanning the range, well, I'm not sure. Maybe
the attacker is just digging around for locally routed private IPs on
his provider's network (quite likely if the scanning machine is in
fact a zombie).

>> That being said, the decoy technique is not specific to namp: it's
>> rather trivial to implement it on another scanner.
>> JRK> I was hoping that someone else would say, "yes, I've seen that
>> JRK> and snort says it is...". Unfortunately, we run snort behind the
>> JRK> router so it does us no good in this case.
>> Unfortunately, I can't help you there. The only thing in my logs that
>> could be remotely related to your situation is the strange SMTP
>> connections I see on my mail server: several completely unrelated
>> machines connecting in a very short time frame (10-20 seconds),
>> grabbing the banner and disconnecting. These machine are from
>> different networks all over the planet (well, the networks that aren't
>> automatically denied SMTP connection, that is) and they do complete
>> the 3 way handshake so they are not spoofed.

JRK> This is one that I can easily explain! First, the apparently unrelated
JRK> machines are not unrelated. They are all under the central control of
JRK> a spammer somewhere. (This is one of the techniques we use to backtrack
JRK> and find spammers.) Why grab the banner? Several reasons: To determine
JRK> that a mail server is running on that IP; to determine the mail server
JRK> software and version; and, most importantly, to find out the domain you
JRK> claim to be serving on that IP.

So far so good, but: why use several machines ? If he grabs the banner
once, there is little chance that it will get a different one a second
time... Is it to try to foil static IP blacklisting ?

JRK>  The spammer builds a database of such
JRK> information to use to later exploit the mail server. For example, using
JRK> the domain name the mail server claims to be serving, the spamware
JRK> collects all the email addresses in their database associated with that
JRK> domain, connects directly to that mail server, and attempts to send spam.

?? Why not simply use the MX record for that ? Are you saying that he
might be digging for internal MTAs ?

JRK> Why that approach? To exploit secondary mail servers that may not include
JRK> spam and virus filtering, thus resulting in the successful delivery of
JRK> junk that may otherwise be blocked if the spammer tried to use the mail
JRK> server indicated by the domain's MX records.

Ok... but in that case, why attack the MTA using different hosts ? In
order to avoid RBLs and blacklists ?

JRK> A few other points:
JRK>  -- You will always find that the systems connecting in the manner you
JRK>     describe are either running proxy servers or spamware of some sort.

Possibly, I don't know really. Unlike some "providers", I don't scan
machines that connects to my MTA ;)

JRK>  -- You should always configure your firewall to limit SMTP MTA port
JRK>     connections to only your real incoming mail server; you should block
JRK>     all SMTP MSA port connections that do not originate from your local
JRK>     network.

No problem there. The server that is getting hit most often is
actually sitting outside my firewall in a hosting center (It's an
external point of presence for our company as well as for my own
personal projects).

JRK>  -- If your incoming mail server is not the mail server listed in your
JRK>     MX records, then you should limit connections to that mail server
JRK>     to the authoritative server that first receives your mail.

It is listed as primary MX for about 10 domains and secondary for a
single one.

JRK>  -- You should configure all your MTAs to NOT disclose the version of
JRK>     your MTA and you should disable your MTA's SMTP help file as well.

It has been two years since I changed the banner to "mail.fulgan.com
mail server". But I didn't think of the help command... After
checking, this one is reporting the "brand" of the server as a "bug
reporting address". Thanks for pointing this out to me.

JRK>  -- Finally, if you haven't already done so, disable your MTA's ability
JRK>     to respond to the SMTP VRFY, EXPN, and ETRN commands, and to refuse
JRK>     server return-receipt delivery requests.

Just out of curiosity: why disable ETRN ? EXPN and VRFY no problem,
but ETRN ??

JRK> Hope this helps!


More information about the list mailing list