Deny-Spammers:Spam Blocking with a Dynamically

Updated Firewall Ruleset

11.06.02

chris tracydeeann m.m. mikula

Motivation for Paper

• Deeann presented a Spam BOF at LISA 2001: – generated a lot of excitement– idea to write the paper came from this– seemed like a novel approach to fighting

spam– share our “good idea”– get feedback to improve the idea

Introduction

• We will:– detail our methods for controlling spam

at a small ISP– discuss initial unsuccessful tactics– discuss the resulting development of our

unique spam blocking system

Introduction

• We will show how our spam blocking system:– classifies hosts as probable spammers– dynamically manages a firewall ruleset– conserves system resources– effectively blocks spam

Theft of Service

• Lost bandwidth• CPU cycles• Disk space• Lost time

– end-users and administrators

• Obviously this is lost money• Apparent escalation in recent years

Spam Horror Stories

Hotmail states that 80% of its almost 2 billion processed email messages are spam.

- Lee Gomes, The Wall Street Journal

“Brightmail...now records 140,000 spam attacks a day, each potentially involving thousands of messages, if not millions.”

- Jennifer Lee, The New York Times

Tools for Coping with Spam

• Simple Mail Filters– Mail::Audit, procmail...– patches for various MTAs

• qmail-uce, rblsmtpd...(lots of these)

– versatile spam filters• spamassassin• sieve• bayespam

Tools for Coping with Spam

• Databases– Relay Blackhole Lists (RBL)

• lists the IPs of known spammers, open relays, dialup/DSL address pools

– Razor– Pyzor– DCC - Distributed Checksum

Clearinghouse • http://www.rhyolite.com/anti-spam

Trouble with Spam Filtering

• Requires:– more CPU power– network bandwidth

• if accessing networked databases• RBL, DCC, Razor, Pyzor...

– a more complicated mail system• administrative overhead

– updates, configuration...

Trouble with Spam Filtering

• False positives (Type I error):– legitimate messages that are marked

as spam– spam filters are getting better and

better, but...– users are more likely to ignore

everything that their spam filter catches

Our Problem

• Spammers were effectively DOS’ing our mail server

• Wanted a way to be able to selectively deny hosts– take away the ability to connect to our

mail server if we detect them as a spammer

– RFC 706 (next slide)

RFC 706 - On the Junk Mail Problem

• In a nutshell:– No mechanism for a mail host to

selectively refuse messages– Lots of unwanted messages by a

misbehaving host would constitute a DoS attack

– Both local users and network communication could suffer

Hardware/Software Platform

• Software:– FreeBSD 2.2.8

• server is just a little behind... :)

– qmail-1.03• patched with qmail-uce checklocal patch

• Hardware:– 1GHz Athlon processor– 640MB of RAM

What We Tried First

• qmail-uce checklocal patch– denys mail for non-existent mailboxes– by default, qmail accepts mail for these

users• this is actually an anti-spam mechanism to

prevent spammers from getting valid addresses

– qmail-smtpd returns a 550 when attempting to send

What We Tried First

• qmail-uce checklocal patch– example:

RCPT TO: abcdefghijklmnop@telerama.com

550 Sorry, no mailbox here by that name. (#5.1.1)

What We Tried First

• qmail-uce checklocal patch– example of logging output:

Oct 10 13:09:24 mail smtpd: 1034269764.717203 7678: DENYMAIL: RCPT_TO:_Filter.NoUser:_ relay unknown [205.201.1.215] FROM <test@telerama.com> ADDR <abcdefghijklmnop@telerama.com>

What We Tried First

• qmail-uce checklocal patch– limitations:

• kept the queue size down, but didn’t prevent spammers from making 50-100 parallel SMTP connections

• sluggish performance when there were many parallel SMTP connections to the server

• as a result, load average still >> 1

What We Tried First

• rblsmtpd (part of ucspi-tcp)– a.k.a. tcpserver– http://cr.yp.to/ucspi-tcp.html– queries any number of RBL sources (and

anti-RBL sources) to catch spammers• open relays, dialup/DSL pools, known

spammers

– temporary (451) or permanent (553)

What We Tried First

• rblsmtpd (part of ucspi-tcp)– toggled on when heavily spammed

• off if queue size < 2000 • on if queue size > 2000• this was done to limit complaints

– on/off method made 451 errors effectively useless

– limitations:• too many false positives• many complaints from customers about mail

delays (451) or bounces (553)

A Decision to Start Coding

• Should we buy more hardware?– more expensive

• Or write software to manage a firewall based on the checklocal logging output?– less expensive– Obviously, this is what we opted to do

Design Goals

• What has not worked for us in the past?• Do we have enough resources to allow client-side

filtering options?• Do we have the time and expertise to create our

own spam blocking solutions?• Would it be more effective to purchase faster and

better hardware than to script a custom solution?• How transparent does the spam blocking need to be

to the user base?• Are we concerned with bandwidth consumed by

spam attacks?

Requirements

• Method must conserve system resources.• Method must reduce the amount of bandwidth consumed

by spam attacks.• Method must not add much additional overhead to mail

processing.• Method must prevent spamming sites from getting mail

into the mail queue.• The system must be manageable in a way that allows us

to exempt certain hosts or networks.• Keep our customers happy by minimizing the number of

false positives.• The process must be as transparent as possible to end

users.

Data Flow Diagramchecklo

calDENYMAIL

SMTP

deny-spammers

maillogqmail-smtpd+ checklocal

Internet ipfw

firewall

rules

checklocalDENYMAIL

kernelIPFIREWALL

firewallrules

SMTP

Mail Host

SMTP

Data Flow Diagram

Oct 10 13:09:24 mail smtpd: 1034269764.717203 7678: DENYMAIL: RCPT_TO:_Filter.NoUser:_ relay unknown [205.201.1.215] FROM <test@telerama.com> ADDR <abcdefghijklmnop@telerama.com>

checklo

calDENYMAIL

deny-spammers

maillogqmail-smtpd+ checklocal

checklocalDENYMAIL

Data Flow Diagram

Add rule:ipfw add 1000 unreach filter-prohib tcp from 205.201.1.215 to any 25

Delete rule:ipfw delete 1000

deny-spammers

ipfw

firewall

rules

kernelIPFIREWALL

firewallrules

Data Structures

• 3 hash structures:– Host Tracking: %spammer (hash of lists)

• keys of hash - host IP address• values of hash - lists of timestamps• timestamps - represent times that a host sent a mail to a

nonexistent address

– Banned Hosts: %banned (1-level hash)• keys of hash - host IP address• values of hash - timestamp for when a host was banned

– Exception List: %noban_list (4-level hash)• keys represent octets• first level - first set of octets, etc...• hash structure chosen for performance

Other Configuration Variables

• $MAX_SPAMMER_ENTRIES (default: 50)– number of timestamp entries to keep for each

spammer

• $SPAM_TIMESPAN (default: 3600 seconds)– 5-minute sampling interval– timespan to check for spam attempts

• $SPAM_TRIGGER (default: 10)– number of nonexistent mailbox delivery attempts

required to trigger block

• $BAN_TIME (default: 3 days)– how long a host should stay banned for

Implementation / Pseudo-code

While (true) {

match maillog lines against a regexp for undeliverable messages

to non-existent addresses and parse timestamp and IP address

skip line if host is in the exception list

trim the timestamp list for this host to $MAX_SPAMMER_ENTRIES

add the timestamp to the host's list contained in the %spammer hash

check how many delivery attempts to non-existent address this host has made in the sampling interval $SPAM_TIMESPAN

if (nondeliverable messages count > $SPAM_TRIGGER) { add_firewall_rule(); }

if (time() >= $next_refresh) {

$next_refresh = time() + $REFRESH_INTERVAL;

reload the exception list into %noban_list hash;

prune %banned hash (un-ban hosts who have been banned for $BAN_TIME);

}

}

In P

roduct

ion

Firewall Reset

Quick Historical Statistics

25,284 Dec 2001

46,338 Jan 2002

35,849 Feb 2002

44,652 Mar 2002

25,175 Apr 2002

26,808 May 2002

33,298 Jun 2002

18,787 Jul 2002

24,781 Aug 2002

28,883 Sep 2002

16,935 Oct 2002

Number of hosts banned by month:

Limitations

• CIDR notation not supported in exception list

• only compatible with FreeBSD + checklocal patched qmail

• limited scalability• checklocal exploitable by spammers

to find valid addresses– easy to work around this

Future Plans

• Address scalability issues– add ability to use a separate firewall

• Integration with a 3rd-party app– SpamAssassin, Anomy Sanitizer...– use results from app to ban hosts

• Improve statistics generation– facilitate research– look for interesting patterns

Future Plans

• Develop a better interface...– for unbanning hosts– managing the exception list

• Interoperability with other operating systems and MTAs

• Develop more spam signatures...?– # of concurrent SMTP connections– # of recipients in RCPT TO list

Availability

• Deny-Spammers is freely available• source code and documentation:

– http://deny-spammers.telerama.com

• written in Perl 5• only works with FreeBSD +

checklocal patched qmail

The End

• Thanks!

• Q&A...?