The problems associated with operating
an effective anti-spam blocklist system in an
increasingly hostile environment.
Robert Gallagher September 2004
Introduction and Overview
> There is an increasing tendency for spammers to enlist the
services of malware authors.
> Spammers are finding sophisticated ways of sending bulk
email whilst concealing their identity.
> Anti-spam systems are coming under frequent attack.
> This practicum investigated the collaboration between
spammers and malware authors and the threat this poses to
anti-spam systems – specifically blocklists.
Blocklists
> A list of IP addresses.
> All these IP addresses have a common factor, they are
usually associated with spam.
> Criteria
• Exploitable or poorly configured email systems (Open Relays,
Open Proxies)
• Blocks of IP addresses under the control of a known spammer.
> Email servers or anti-spam software can be configured to
query a blocklist upon receipt of a message.
> The most successful blocklists have extensive review
processes for listing an IP address.
Existing Blocklist Systems
> Spamhaus
One of the most successful and well known blocklists. As
evidenced by the frequency with which it gets attacked (next
section).
Provides SBL (blocklist), XBL, ROKSO.
> MAPS (Mail Abuse Prevention System)
Early blocklist – RBL.
Strict and comprehensive guidelines for listing IP addresses.
These guidelines have been held up as an example of how to run
an effective blocklist.
Spam and Malware
> Their success has lead to blocklist systems coming under
attack.
> The frequency and severity of attacks on blocklist
systems has vastly increased in recent times.
> Such attacks have been characterised by the
involvement of machines infected with trojans, viruses or
worms – so-called ‘Zombie’ machines.
> ‘Zombie’ machines act as spam relays, content hosts or
DDoS agents.
Distributed Blocklist
> Spammers have a lot to gain from forcing blocklists to
shut down, for very little effort.
> One approach to protecting blocklists in the future is to
make attacks against them extremely difficult to mount
effectively.
> Simply store blocklist data on ‘peers’. No central point
that can cause failure of the entire system.
Distributed Blocklist - Architecture
> Entities
Peers
Trusted Maintainers
> Peers join the list and store blocklist data. They use the
system and participate in it.
> Trusted maintainers manage the list, allow new peers to
join and push signed updates into the system.
> Data is stored in ‘Netblock Sections’ that represent a
specific portion of the IP space.
Distributed Blocklist - Architecture
> Querying the blocklist
Peer A Query Peer A’s
Cache
Yes – Return
Netblock
Netblock Yes – Return Netblock Section Section
Section
Cached
Peer A’s Location of Peer B No
Netblock Routing
Section Table Relay to
Cached another
peer
Query
Peer B’s Query
No
Cache
Peer B
Relay to
Relay until
another
query expires
peer
Distributed Blocklist - Architecture
> Peer handling of received netblock sections
From Trusted Maintainer
Netblock Maintainers
Update Update
Maintainer Peer Section Public key
verified
Yes No
Discard
Update Add/Replace
Cache Cache entry
Distributed Blocklist - Architecture
> Peer handling of received netblock sections
From another Peer (Answer to Query)
Netblock Netblock
Netblock Maintainers
Section Section
Peer B Peer A Section Public key
verified
Yes No
Netblock Discard and make
Check if IP request again
Section
Is in netblock
Cache section
Distributed Blocklist - Architecture
> Adding a new node to the blocklist
(2) Netblock Section to Store + Location of Peer B + Maintainer’s Public Key
Peer A’s
Maintainer Routing
Peer A
Server (1) Hello Msg. Location of Peer B Table
+ Location
(3) Peer A’s Location + Netblock Section Stored by A
Peer B’s
Location of Peer A Routing
Peer B
Table
Peer N Peer B’s
Message (3) Location of Peer A Routing
Table
Continue
Relaying
(3) Until it
expires
Distributed Blocklist - Attacks
> Resistance to DDoS.
> Trusted maintainers are a highly visible target for attack.
> An attacker with enough resources could shut down
most, or all of them. Having many trusted maintainers
would make this quite difficult however, this could be
achieved by having one in each country for example.
> A DDoS may be successful, but the blocklist is still
accessible.
Conclusions
> It is clear that spammers are employing increasingly
sophisticated techniques and tools.
> Malware has emerged that has the sole purpose of aiding
in the distribution of spam, by creating the means to send
bulk email anonymously and launch attacks against anti-
spam systems such as blocklists.
> Development of the distributed blocklist is one approach
that existing blocklists could take to adapt to these
conditions.
Conclusions – Future Work
> Development of the distributed blocklist.
> Many large-scale distributed systems operate over the
Internet today – distributed.net.
> Existing blocklists could use the distributed blocklist
framework and apply their own review processes to it.
> The system could be implemented as a CGI script or
similar, running on the peer.
> Running the system over an existing, lightweight
protocol such as HTTP would facilitate a large number of
peers since joining would require a minimum amount of
software.