[Dshield] Scans occurring in large bursts
Jon R. Kibler
Jon.Kibler at aset.com
Thu Feb 12 19:03:46 GMT 2004
Stephane Grobety wrote:
> >> 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 ?
There may be a machine, but not serving the port that was probed. We allow access only on a per-port per-IP basis.
> 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 10.0.0.0/8 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).
I am not seeing scanning from 10/8 addresses, rather I am getting "Administrative prohibited" ICMP hits. (We block all bogus source addresses at the border router.)
> >> 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 ?
NANAE Rule #1 -- All spammers are stupid. I agree, it doesn't make sense to get the banner multiple times, but that is the way the spamware works. And, I suspect that it is to see which machines get past firewalls and blacklists.
> 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 ?
Exactly. Spammers are trying to bypass your normal MTA in hopes that internal systems are not using DNSBLs, virus scanners, and other email security techniques.
> 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 ?
Yep. Haven't you ever gotten the same spam item from 4 or 5 sources almost simultaneously? That is why. The more hosts they use to try to spam you, the more likely they will find one that is not blocked. (Our internal list of known spam sources that are not in any public DNSBL is currently over 100,000 domain names and IP addresses and growing by the hour.)
> 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 ;)
If nothing else, you should run a job every hour that collects the IPs for all MTA connections, and then runs a proxy checker on the set of IPs. Then, internally blacklist each open proxy. Anything that is not an open proxy, you should submit to ORDB.ORG for open relay testing. Also, you need a white-list of IPs to never check... and don't forget to include 127.0.0.1 in that list (school of hard knocks).
> 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 ??
ETRN for several reasons... the biggest being DOS attacks. If you have secondary mail servers that need to force a queue run, you should be able to configure your system to just recognize those hosts (If you are running sendmail, I can give you some rules for this.)
ETRN also allows a system to probe for virtual domain names that may be served by the MTA.
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