On 26 Jun 2015, at 12:33, Alex Regan wrote:
Hi,
I have one system with greylisting enabled and another that hasn't yet
been enabled. On the system without it, I'm receiving a ton of random
spam that hits bayes99 but pretty much nothing else.
http://pastebin.com/FzUkEvRp
It all seems to be related to the same botnet because it has these
random URLs to .gov sites in them, trying to legitimize its contents.
No botnet, rather a "snowshoe" spammer: one who buys fixed ranges of IPs
typically smaller than /25 from careless or knowingly collaborative
ISPs, and spreads their use across the whole range and often multiple
ranges, sometimes across multiple ISPs simultaneously. This allows them
to keep the flow from any one IP below levels where simplistic trafic
monitoring would catch it.
The CSS component of the Spamhaus BL (also included in their Zen
combined DNSBL) is designed to catch these spammers and it does a very
good job. Within less than a minute of the message you pasted, they were
listing 45.62.178.8 and nearby addresses. Looking at a log for one
system I work with, I see that /25 offered over 100 messages today
starting around 13:45 UTC and because of the CSS, 95% were refused.
Any ideas for a rule or pattern that would block these more generally
than for just this specific version?
I see similarities between the message you posted and some I've seen
recently from 23.245.225.0/24, but I haven't worked up rules for them
yet, as they are not simple: an odd pattern of domains used in the SMTP
envelope, From header, and Message-ID. The MID is the only thing that
seems relatively simple: a long pseudo-TLD (.local and .sender are 2
I've seen) appended to a classical gTLD domain (.com, .org, etc). The
inter-relation between domains in the envelope and headers is probably
not subject to rules per se...
There's also a particular issue with sharing rules for this spam. See
below...
I'm sure it would now be on all the RBLs and be blocked, but I'd like
to know if there's something in the header or something else that can
be done to block all the random versions of this without having to
write body rules for each version.
I can supply other versions if needed...
No doubt...
This stream is the latest iteration of a snowshoe spammer (or related
set of spammers) who have a relatively stable and limited address list,
but have been spamming those poor folks mercilessly for most of a
decade. Less than 10% of addresses on any system where I've seen it over
the years get it at all, but those get hammered: dozens per day if left
unshielded, a steady trickle of a few per week getting through even with
the most diligent protection. This is the spam that makes people abandon
addresses. That is why I have 'trap' addresses on one system that get no
other mail but these streams: their original owners sought refuge in
fresh addresses years ago.
The problem with sharing rules for this spam is that even when the
sharing is not very public (e.g. not posted on this or any other open
list) there has been a history of the spam evolving away from long-good
patterns swiftly after they appear in public use, even if they aren't
well-documented. It seems that this is spam which gets tested against
the SA standard ruleset *and other published rules* and actively evolved
away from being caught. In short: these are the smartest spammers in
active operation when it comes to filter evasion.
So please: write a rule that matches the last element of a MID domain
being longer than 3 characters and the 2nd to last being 3 or shorter
and give it a big fact score, but don't post it here or pass it around
to people who publish rulesets. You may also find persistent
commonalities in structural quirks of the MIME and HTML layers of these
messages (there have been such in the past...) but if you want those to
remain useful, don't tell us about them. Yeah, this sucks.
