Empirical Analysis of Denial of Service Attack Against SMTP Servers Boldizsár BENCSÁTH, Laboratory of Cryptography and System Security (CrySyS) Budapest.

Empirical Analysis of Denial of Service Attack Against SMTP Servers

Boldizsár BENCSÁTH, Laboratory of Cryptography and System Security (CrySyS)

Budapest University of Technology and Economicshttp://www.crysys.hu/

this is joint work with Miklós Aurél RÓNAI

2www.crysys.huLaboratory of Cryptography and System Security

Spam is a REAL problem today

blue: SPAM green: Normal e-mails (ham)

timeAs of 03/27/2007

~10-fold increase in number of spam

3www.crysys.huLaboratory of Cryptography and System Security

Why to measure performance?

Many e-mail servers are overloaded Sometimes they even stop to respond or just restart (DoS

situation) We don’t know the performance of the server As more and more spam arrives, we should expect more

problems (DoS, etc.) Can we deploy a successful DoS attack against the server

easily? Can we protect our server against DoS attacks? How does the content filtering (virus- and spam filtering)

affects the server?

4www.crysys.huLaboratory of Cryptography and System Security

Related work

Some information is available on performance, but it is not enough (sometimes no data on content filtering, or no real comparison, etc.)

Microsoft has a more complex test to calculate performance need in their Exchange architecture, but it is too complex. (we don’t want to analyze the performance of e.g. the calendar and address book)

Some information is available on the spam traffic and also some on DoS situations in SMTP servers, but not very informative

We tried to make some standard measurements to support our other research activity, e.g. DoS protection

5www.crysys.huLaboratory of Cryptography and System Security

The performance testing of SMTP is complicated

It’s hard to send e-mails (complicated application, network connectivity can hang, resource consumption is high for random emails (needed for testing spam engine))

It’s hard to coordinate the sending (starting the same time) It’s hard to measure successful transfers SMTP delivery it a multi-step process (explained later) Too much overload can cause server to hang Different SMTP servers can work in very different ways

6www.crysys.huLaboratory of Cryptography and System Security

SMTP delivery

The SMTP server gets a new message The server puts it into a temporary queue -Sometimes it delivers without the temporary queue The server sometimes/always/immediately/later checks the

temporary queue and finds the e-mail-If the target server (or e.g. content filtering) is not responding,

retry and retry timeout can occour-If the server is overloaded, the delivery process can be

delayed The server tries to deliver the message (or start content

filtering)-Sometimes content filtering results in a new email (dual smtp

setup)

7www.crysys.huLaboratory of Cryptography and System Security

Phases of delivery during the test

Phase 1: SMTP server receives and delivers messages Phase 2: SMTP server receives into temporary queue, no or

low speed delivery Phase 3: no SMTP mails received, just delivery from the

queue

Our test server: 2800MHz, 1GB RAM

8www.crysys.huLaboratory of Cryptography and System Security

What was our approach

Load the server fully, but not to overload too much Messages generated on multiple computers to avoid

problems by resource problems on the tester computers Coordination by IRC based ‘botnet’ architecture Sending a large number of emails and measuring the

delivery time (and ensuring that the server runs under full load by delivery parameters)

Tried to measure performance in the different phases of delivery

Standard SMTP servers with standard content filtering QMAIL, Postfix, Sendmail, Exim, MS Exchange Amavisd-new, ClamAV-daemon, Spamassassin

9www.crysys.huLaboratory of Cryptography and System Security

Botnet

10www.crysys.huLaboratory of Cryptography and System Security

First results, no content filtering

11www.crysys.huLaboratory of Cryptography and System Security

Some data on delivery process

12www.crysys.huLaboratory of Cryptography and System Security

Delivery rate, without content filtering

13www.crysys.huLaboratory of Cryptography and System Security

Exim and queue_only_load

Queue_only_load parameter stops delivering e-mails if the load average is too much

Without this paramter, delivery is continuous throughout the test

Results show that for the performance, this behaviour is not very important

Of course the parameter is important, e.g. to avoid DoS

14www.crysys.huLaboratory of Cryptography and System Security

Exim with content filtering

Clamscan is not daemonized, Clamd is daemonized == always in memoryClamd is clearly fasterPerformance is down from 30 to 6.81/4.03 e-mails/sec

15www.crysys.huLaboratory of Cryptography and System Security

Exim, virus+spam filtering

Performance is down from 30->6->1.58 messages/sec

16www.crysys.huLaboratory of Cryptography and System Security

DoS? DoS!

Test messages: body size of 4kb, random textExim, virus+spam filtering = 1.58 e-mails/sec1.58e-mails/sec*4kb=6.32 kb/sec payload, ~50kbps, with

overhead ~64kbps

Using only 64kbps we can overload an SMTP server with content filtering!

17www.crysys.huLaboratory of Cryptography and System Security

Future work

Our tests can be easily extended-other SMTP servers (e.g. kerio, mailgate etc.)-other content filtering tools (mailscanner, milters, COTS tools

and products)-other spam engines (dspam, commercial products)-different parameter settings (e.g. spamassassin tests)-test e-mail parameters (attachments, size) (now random text

4kb)-other test approach (testing under heavy/low load etc.)-testing ‘appliance’ solutions.

The main goal is completed: some basic information is now available about the possibility of overloading (DoS) and the performance of the server

18www.crysys.huLaboratory of Cryptography and System Security

Thanks

Thank You!

http://[email protected]