1. The problems associated with operating an effective anti-spam blocklist system in an increasingly hostile environment. Robert Gallagher September 2004

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.

7. 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.

8. Distributed Blocklist - Architecture > Querying the blocklist Peer A Peer A’s Cache Query Netblock Section Cached Yes – Return Netblock Section Relay to another peer No Peer A’s Routing Table Location of Peer B Peer B Query Peer B’s Cache Netblock Section Cached Relay to another peer Relay until query expires Query Yes – Return Netblock Section No

9. Distributed Blocklist - Architecture > Peer handling of received netblock sections  From Trusted Maintainer MaintainerPeer Netblock Section verified Maintainers Public key Discard Add/Replace Cache entry Cache Update No Yes Update

10. Distributed Blocklist - Architecture > Peer handling of received netblock sections  From another Peer (Answer to Query) Peer BPeer A Netblock Section verified Maintainers Public key Discard and make request again Check if IP Is in netblock section Cache Netblock Section No Yes Netblock Section Netblock Section

11. Distributed Blocklist - Architecture > Adding a new node to the blocklist Maintainer Server Peer B’s Routing Table Peer A Peer A’s Routing Table Peer B Peer B’s Routing Table Peer N (1) Hello Msg. + Location (2) Netblock Section to Store + Location of Peer B + Maintainer’s Public Key Location of Peer B (3) Peer A’s Location + Netblock Section Stored by A Location of Peer A Message (3)Location of Peer A Continue Relaying (3) Until it expires

12. 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.

13. 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.

14. 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.