Effectiveness of DNSBLs declining?
Matthias Leisi
I already asked the same question in german in de.admin.net-abuse.mail,
but I would like to get a more international feedback here in nanabl:
In a corporate mail environment, I notice a decline in the effectiveness
of DNSBLs, especially Spamhaus SBL+XBL (which I use to reject), but also
others (which I for scoring in SpamAssassin and is thus a bit harder to
measure).
The reject rate by SBL+XBL has gone down from around 30 to 25% (August
to October 2005), while at the same time the overall rate of spam has
not changed significantly. [NB: the amount of viruses/worms and bounces
is neglectable, since it's usually well below 1% of the overall traffic
on that specific domain.]
Obviously, that's all a lot lower than what is eg shown in [1], but that
is also influenced by the usage pattern of my users (they are business
users, where most of them have never used the mail address in public).
However, it's the decline that's worrying me. Do you have similar data /
experience?
Thanks,
-- Matthias
[1] http://www.spamhaus.org/effective_filtering.html
--
Comments posted to news.admin.net-abuse.blocklisting
are solely the responsibility of their author. Please
read the news.admin.net-abuse.blocklisting FAQ at
http://www.blocklisting.com/faq.html before posting.
Bill Cole
Matthias Leisi <matt...@leisi.net> wrote:
> Hi all,
>
> I already asked the same question in german in de.admin.net-abuse.mail,
> but I would like to get a more international feedback here in nanabl:
>
> In a corporate mail environment, I notice a decline in the effectiveness
> of DNSBLs, especially Spamhaus SBL+XBL (which I use to reject), but also
> others (which I for scoring in SpamAssassin and is thus a bit harder to
> measure).
>
> The reject rate by SBL+XBL has gone down from around 30 to 25% (August
> to October 2005), while at the same time the overall rate of spam has
> not changed significantly. [NB: the amount of viruses/worms and bounces
> is neglectable, since it's usually well below 1% of the overall traffic
> on that specific domain.]
>
> Obviously, that's all a lot lower than what is eg shown in [1], but that
> is also influenced by the usage pattern of my users (they are business
> users, where most of them have never used the mail address in public).
>
> However, it's the decline that's worrying me. Do you have similar data /
> experience?
My data agrees on SBL+XBL, but not all DNSBL's. SBL effectiveness along
is very noisy with time, because every long-term major success involving
SBL spammers (e.g. indicting Ralsky) triggers flux, and it takes time
for the SBL to adjust. I also suspect that after a long run of spammers
ignoring the CBL (major source of the XBL) they have finally started to
adjust their behavior a little to it, moving off of CBL-listed machines
once they appear in the XBL. My data is statistically weaker than I'd
like, but it seems that the gap between CBL+OPM and XBL (which now also
has some NJABL data) has grown in the past 6 months. There has also
been a slight drop in CBL effectiveness over that time.
My theories:
1. Spammers are figuring out that when a machine reaches the SBL+XBL,
its usefulness declines sharply.
2. The somewhat obscure detection mechanisms used by the CBL and other
recent tools are becoming somewhat less mysterious to spammers, and a
minority of them are adapting by actually modifying the core behaviors
that trigger identification.
--
Clues for the blacklisted: <http://www.scconsult.com/bill/dnsblhelp.html>
Current Peeve: "This page was written to render correctly in any standards
compliant browser" on pages with hundreds of HTML errors.
Cameron L. Spitzer
news.admin.net-abuse.blocklisting), Matthias Leisi wrote:
> Hi all,
>
> I already asked the same question in german in de.admin.net-abuse.mail,
> but I would like to get a more international feedback here in nanabl:
>
> In a corporate mail environment, I notice a decline in the effectiveness
> of DNSBLs, especially Spamhaus SBL+XBL (which I use to reject), but also
> others (which I for scoring in SpamAssassin and is thus a bit harder to
> measure).
It would be a big, expensive job to answer that question
scientifically. My spam stream is a lot different than others
I know about, perhaps because most of my domains end in org or us.
The stream seen by corporate coms will be quite different, and the
one seen by big consumer domains different still.
Anecdotally, I'm seeing a shift. Activity in the cable TV zombie
farms seems to have leveled off, and the growth is in servers at
colo places with minimal management. My guess is the pharmacy
and "enlargement" spammers aren't getting the delivery rates they
used to from cable TV, because those farms have been mapped out
and widely blocked. And the next wave is just plain server break-ins.
This corresponds with a jump in cracking attempts seen here.
DNSBLs have a hard time keeping up with the incessant breakins at
places like Theplanet.com and Ev1servers.net. And they can't stop
all that fraud spam pouring out of Hotmail/MSN.
Let this be a warning to Linux-Apache-MySQL-PHP ("LAMP") operators.
If you let your users "just drop in" any CMS whose Web site catches
their eye, on any popular distro's default install (i.e. everything
in one partition), you're gonna get cracked and send spam.
They don't need root. They don't even have to smash the stack.
The most popular BBS/Blog/CMS stuff has
holes that let them create executables in /tmp or /var/tmp and run them.
They're not cracking Linux or Apache, they're exploiting Mambo
and PHP Nuke and phpBB.
Make a separate partition, or a file system in a file you can mount
loopback, and mount it noexec. Make sure every directory your
Web server uid can write in is noexec. If that BBS/Blog/CMS
monster can't install its modules or gallery files any more, then
it's hopelessly broken. Remove it before it gets you block listed.
If it uses a database, it should put everything in there.
I'm seeing a lot of spam from badly written CMSes these days.
(Mounting /tmp noexec breaks Debian's apt-get install/upgrade.
Write a wrapper to remount it during the apt-get. Use apt-get -d
to download the upgrades ahead of time and shorten the window.
The download doesn't need exec in /tmp.)
--
Cameron
David Cary Hart
>
> The reject rate by SBL+XBL has gone down from around 30 to 25% (August
> to October 2005), while at the same time the overall rate of spam has
> not changed significantly. [NB: the amount of viruses/worms and
> bounces is neglectable, since it's usually well below 1% of the
> overall traffic on that specific domain.]
>
>
> [1] http://www.spamhaus.org/effective_filtering.html
>
While I agree with your observation, I would disagree with the Spamhaus
model. Changing the staging order might improve overall efficacy to
address the issue that you raise.
According to our data (which may or may not be representative) 25% of
total spam originates in South Korea and the PRC. If you are not doing
business in those areas, they are easy to block with a local DNSBL.
There is the potential to eliminate much more as well, such as Brazil -
depending upon where the organization needs to communicate.
Another 20% to 25% is generated by zombies in dynamic space. Much of
that spew, too, is easy to block with RegEx and/or a local DNSBL
installation.
Then there is a large percentage of spam which should be blocked by
"signature" using RegEx. HELO attributes come immediately to mind but
there are other tell-tale signs as well.
Then there is spam that is unique to the organization due to the
behaviors of users, the corporate culture, location and other internal
factors. Of these sources are not listed by external DNSBLs. This UCE
can be experience blocked through ACLs or a local DNSBL.
Therefore, I have embraced the notion of using the external DNSBLs as
the final stage. It improves efficiency and - probably - reduces
overhead.
Some would also suggest that stage 1 should be the firewall. I don't do
that but it makes perfect sense.
--
Displayed Email Address is a SPAM TRAP
Our DNSRBL - Eliminate Spam: http://www.TQMcube.com/spam_trap.htm
RBLDNSD HowTo: http://www.TQMcube.com/rbldnsd.htm
Multi-RBL Check: http://www.TQMcube.com/rblcheck.htm
Tired of spam? Do YOUR part: http://www.BoulderPledge.org
Hal Murray
by which lists if you look for spammy URLs inside message bodies?
--
The suespammers.org mail server is located in California. So are all my
other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's. I hate spam.
Buss Error
@msgid.astrum.ch:
> However, it's the decline that's worrying me. Do you have similar data /
> experience?
Yes, I do. I have found that using SpamHaus to reject based on URIs in
email is quite effective and low false positive. I use a milter to reject
during SMTP chat. I have one user that I cite as a bellweather. This user
gets, on average, about 60 spam emails per hour. On average, only two get
past the filter per day, and that's because I won't allow Yahoo redirectors
to be bounced.
However, I'm going to change that policy and treat the Yahoo redirector
site as the spam sign it is fast becoming.
V
news:b4d143-...@msgid.astrum.ch...
> Hi all,
>
> I already asked the same question in german in
> de.admin.net-abuse.mail, but I would like to get a more international
> feedback here in nanabl:
>
> In a corporate mail environment, I notice a decline in the
> effectiveness of DNSBLs, especially Spamhaus SBL+XBL (which I use to
> reject), but also others (which I for scoring in SpamAssassin and is
> thus a bit harder to measure).
>
> The reject rate by SBL+XBL has gone down from around 30 to 25% (August
> to October 2005), while at the same time the overall rate of spam has
> not changed significantly. [NB: the amount of viruses/worms and
> bounces is neglectable, since it's usually well below 1% of the
> overall traffic on that specific domain.]
>
> Obviously, that's all a lot lower than what is eg shown in [1], but
> that is also influenced by the usage pattern of my users (they are
> business users, where most of them have never used the mail address in
> public).
>
> However, it's the decline that's worrying me. Do you have similar data
> / experience?
Yes. I do as well.
I have got a strong impression that the spammers have opened a can of
fresh zombies. The number of spam that manages to get through my first
line of defense, the firewall, has multiplied by 5 over the last two
weeks. That firewall currently contains about 1700 network ranges for
which SMTP and DNS access is denied. This list was built based upon
excessive and repeated abuse detected from those network ranges towards
my mail servers in the past.
Much of the spam during the last two weeks originated from unlisted
network ranges. While spammers in the past, probably just randomly
selected their zombie proxies, they now use a probably more selective
approach, with possibly some DNSBL data, maybe Spamhaus' SBL-XBL as
input.
--
V
Matthias Leisi
First, I would like to thank for the replies to the group and by e-mail.
Your input was very much appreciated for my further digging through
the piles of data, and Cameron L. Spitzer's warning message seems very
much needed in light of the exploits circulating.
I've written a more detailed paper (see [1]), but I'll give a summary here.
Bill Cole wrote:
> My theories:
>
> 1. Spammers are figuring out that when a machine reaches the SBL+XBL,
> its usefulness declines sharply.
> 2. The somewhat obscure detection mechanisms used by the CBL and other
> recent tools are becoming somewhat less mysterious to spammers, and a
> minority of them are adapting by actually modifying the core behaviors
> that trigger identification.
In order to understand why the effectiveness seems(!) to decrease, I
started by looking at spam sending patterns. Data was gathered from one
particular spam run ("The Ultimate Online Pharmacy" which may be
familiar to some of you...), collected over an observation period of
five days.
* Time-to-live of delivering proxies has become extremely short, in that
spam run to 4.3 minutes on average. During it's lifetime, a proxy
delivered 25.9 messages on average.
* Well over 50% of proxies lasted for less than 10 minutes, 95% were
under 25 minutes (see chart [2]).
* The spammer did not make mistakes with HELO or MAIL FROM domains.
* At the fifth day, I checked all IP addresses against SBL, XBL and the
components of the XBL (CBL, OPM, NJABL). Of all the 852 unique IP
addresses, 750 (88%) were listed on SBL and/or XBL (or it's components,
respectively).
* Also on the fifth day, a random sample of 30 addresses was picked for
closer inspection (rDNS, whois, ICMP ping, nmap). Of these 30, only 6
were still reachable.
* The nameservers of the spamvertized domains remained remarkably
stable, with only a slow shift noticeable over the five days.
* All spamvertized domains were registered at most a few days ago.
Some interpretation on these data points (with the usual caveats on
generalizing too much out of a single analysis):
* DNSBLs are too slow to add, given the short TTL.
* When addresses are added to DNSBLs, the listing will often be
superfluous, since the machine has already been disconnected.
* As a result, connection-oriented spam identification has become less
effective, exactly the pattern I observed in my original posting.
David Cary Hart wrote:
> Then there is spam that is unique to the organization due to the
> behaviors of users, the corporate culture, location and other internal
> factors. Of these sources are not listed by external DNSBLs. This UCE
> can be experience blocked through ACLs or a local DNSBL.
My current understanding is:
* DNSBLs remain a very important first line of defense (since it greatly
limits the "time of usefulness" for a given address or block of addresses).
* Checking HELO/MAIL FROM is still important to catch primitive
forgeries. These checks may be more effective when combined by
rule-based analysis (in the context of Received: headers) or with the
help of SPF/DomainKeys/ProposedStandardDuJour
* DNSBLs become _more_ important when it comes to checking the
reputation of domains:
** Bad network neighborhood for the A record of the spamvertized host.
** Bad network neighborhood for the NS record of the domain of the
spamvertized host
** Determine the age of a domain (which should be a new service
to deal with and hide the complexities of whois queries)
* Keyword/Regex-based filtering also has it's place, but has it's limits
(eg poor scaling).
* Depending on the various items David mentioned above, additional rules
will certainly be possible or necessary.
* Avoiding false positives through adaptive whitelisting may become more
important as well. [Yes, that's very important for me, since our current
false positive-rate of 0.02% is still too dangerous...]
-- Matthias
[1]
http://matthias.leisi.net/archives/126-A-day-in-the-life-of-a-spammer.html
[2] http://matthias.leisi.net/uploads/chart-ttl-distribution.gif
E-Mail Sent to this address will be added to the BlackLists
...
>> 1. Spammers are figuring out that when a machine reaches
>> the SBL+XBL, its usefulness declines sharply.
>> 2. The somewhat obscure detection mechanisms used by the
>> CBL and other recent tools are becoming somewhat less
>> mysterious to spammers, and a minority of them are
>> adapting by actually modifying the core behaviors that
>> trigger identification.
> * Time-to-live of delivering proxies has become extremely
> short, in that spam run to 4.3 minutes on average.
> During it's lifetime, a proxy delivered 25.9 messages on
> average.
> * Well over 50% of proxies lasted for less than 10 minutes,
> 95% were under 25 minutes (see chart [2]).
> * At the fifth day, I checked all IP addresses against SBL,
> XBL and the components of the XBL (CBL, OPM, NJABL).
> Of all the 852 unique IP addresses, 750 (88%) were
> listed on SBL and/or XBL (or it's components, respectively).
>
> * Also on the fifth day, a random sample of 30 addresses
> was picked for closer inspection (rDNS, whois, ICMP ping,
> nmap). Of these 30, only 6 were still reachable.
> Some interpretation on these data points (with the usual
> caveats on generalizing too much out of a single analysis):
> * DNSBLs are too slow to add, given the short TTL.
> * When addresses are added to DNSBLs, the listing will
> often be superfluous, since the machine has already been
> disconnected.
> * As a result, connection-oriented spam identification has
> become less effective, exactly the pattern I observed
> in my original posting.
How many of those IPs were (are) already covered by other DNSbl
of the expanding / escalating types? or Dynamic / Generic Types?
--
E-Mail Sent to this address <Blac...@Griffin-Technologies.net>
will be added to the BlackLists.
DevilsPGD
<matt...@leisi.net> wrote:
>* Time-to-live of delivering proxies has become extremely short, in that
>spam run to 4.3 minutes on average. During it's lifetime, a proxy
>delivered 25.9 messages on average.
Nothing a 5 minute greylisting won't solve.
>* Well over 50% of proxies lasted for less than 10 minutes, 95% were
>under 25 minutes (see chart [2]).
Okay, maybe 30 minutes of greylisting.
>* The spammer did not make mistakes with HELO or MAIL FROM domains.
Wow, odd. Define "mistakes"? While I realize you're looking at a
specific class of spam, I'm still seeing tons of mail rejected at the
HELO/EHLO (by claiming to be me) and/or MAIL FROM (by claiming to be
from a nonexistent domain, or occasionally a SPF -ALL) phase
>* DNSBLs remain a very important first line of defense (since it greatly
>limits the "time of usefulness" for a given address or block of addresses).
And when combined with greylisting (which limits the start of the
usefulness period until after DNSBLs have time to catch up), DNSbls are
even more important if spammers really are learning how to follow the
protocol and are avoiding idiotic mistakes like "HELO <recipient's MX>
>* Avoiding false positives through adaptive whitelisting may become more
>important as well. [Yes, that's very important for me, since our current
>false positive-rate of 0.02% is still too dangerous...]
As long as there is a quick and easy way for recipients to whitelist,
this becomes a solvable problem too.
The issue of false positives in person to person correspondence can be
significantly reduced by whitelisting recipients (in other words, if I
send you mail, you're whitelisted so that I can receive mail from you
too) -- The neat thing about this is that even stupid people can
whitelist.
For many moons now I've been including an email address in my DNSbl
reject messages which automatically whitelists the sender's IP when they
send mail to the reject address -- This has been used rather
successfully by slightly clued senders.
Mailing lists are tougher, but luckily the clue level is a barrier to
entry, and these users can usually remember to add the appropriate
sending address to the whitelist, or contact support for assistance.
I'm not sure how to measure false positives effectively since they
aren't always reported, but it has been years since I've had a confirmed
false positive report from an individual sender.
--
Going to church doesn't make you a christian any more than
standing in a garage makes you a car.
Matthias Leisi
E-Mail Sent to this address will be added to the BlackLists wrote:
> [..]
> How many of those IPs were (are) already covered by other DNSbl
> of the expanding / escalating types? or Dynamic / Generic Types?
I use the regular SpamAssassin collection of DNSBLs (that particular
server was running version 2.64 at the time of receipt):
RCVD_IN_DSBL 1434 6.8%
RCVD_IN_SORBS_MISC 409 1.9%
RCVD_IN_SORBS_DUL 9302 44.3%
RCVD_IN_SORBS_WEB 272 1.3%
RCVD_IN_NJABL_PROXY 831 4.0%
RCVD_IN_NJABL_DUL 6920 33.0%
RCVD_IN_BL_SPAMCOP_NET 1110 5.3%
Special End-User Space 2471 11.8%
2 hits 5683 27.0%
3 or more hits 1394 6.6%
The "Special End-User Space" contains a bit of netspace having earned
bonus points (eg. pool-*.verizon.net, *.cable.wanadoo.*,
*.dhcp.charter.com etc).
The last two lines measure the "overlap" between the RCVD_IN_*. It has
proven pretty effective to give bonus points for hits on multiple DNSBL.
Btw., I wrote an experimental DNS server to query the age of a domain
[1]. Comments welcome :)
-- Matthias
[1]
http://matthias.leisi.net/archives/127-DNS-based-query-of-domain-age.html