[Dshield] Scans occurring in large bursts
Jon R. Kibler
Jon.Kibler at aset.com
Thu Feb 12 14:00:19 GMT 2004
Stephane Grobety wrote:
> JRK> I thought about a decoy nmap scan, but it left me without an
> JRK> explanation for the ICMP 3/31 traffic that seems related. Also,
> JRK> it appears to be scans more oriented towards finding open proxy
> JRK> servers (except for the 53/tcp and 111/tcp probes).
> 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.
The router simply drops all packets -- no feedback to the connecting system.
Also, the ICMP traffic is usually 10/8 source IPs.
> 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.
This is one that I can easily explain! First, the apparently unrelated
machines are not unrelated. They are all under the central control of
a spammer somewhere. (This is one of the techniques we use to backtrack
and find spammers.) Why grab the banner? Several reasons: To determine
that a mail server is running on that IP; to determine the mail server
software and version; and, most importantly, to find out the domain you
claim to be serving on that IP. The spammer builds a database of such
information to use to later exploit the mail server. For example, using
the domain name the mail server claims to be serving, the spamware
collects all the email addresses in their database associated with that
domain, connects directly to that mail server, and attempts to send spam.
Why that approach? To exploit secondary mail servers that may not include
spam and virus filtering, thus resulting in the successful delivery of
junk that may otherwise be blocked if the spammer tried to use the mail
server indicated by the domain's MX records.
A few other points:
-- You will always find that the systems connecting in the manner you
describe are either running proxy servers or spamware of some sort.
-- You should always configure your firewall to limit SMTP MTA port
connections to only your real incoming mail server; you should block
all SMTP MSA port connections that do not originate from your local
-- If your incoming mail server is not the mail server listed in your
MX records, then you should limit connections to that mail server
to the authoritative server that first receives your mail.
-- You should configure all your MTAs to NOT disclose the version of
your MTA and you should disable your MTA's SMTP help file as well.
-- Finally, if you haven't already done so, disable your MTA's ability
to respond to the SMTP VRFY, EXPN, and ETRN commands, and to refuse
server return-receipt delivery requests.
Hope this helps!
Jon R. Kibler
Chief Technical Officer
Charleston, SC USA
Filtered by: TRUSTEM.COM's Email Filtering Service
No Spam. No Viruses. Just Good Clean Email.
More information about the list