DDoS attack on SMTP

Question

I am not sure whether this is the right place to ask this. But now I am in a great difficult situation. Our server is undergoing SMTP DDoS attack. The mail service has been totally down. We have checked with the datacenter team and they updated us to purchase a new firewall module, which I cant afford now. When we try to change the Port the attack can be stopped but the mail service goes down. Is there any possible way to stop this attack ?

OS: CentOS 
Mail service : exim 
SMTP port used : 25

Current mail log is shown as below:

2013-10-16 00:35:10 SMTP syntax error in "\223\032\020F\324\247\315f\200]\236m2\025\305sL\313\300y\377}\306\177]\246V\204\272n3\2115\031\335\215\240\247[\222\340*\340\230]\263\221\235\323=n\242\315\\260\2473\021q\255o\232a\263\262\306\016\2705A\261\2744\230`\302r\361\343=\376     \260\315\356-s\322\236C\255\327\353;\253\334h\304\207\341\276\201\324^\207\231\212\354\273"L\362:zNn\205\362\253r\240\032\235x\027u\211\006`\377\224\vR\204\360\020\265@k\025\301Y\212\033\204\346j!?9\026&\206)\215*:LP/[\006\3704\263W\206:P\340<@\360f\276D\365\3544I6\334\017O\242\377gT\277O\340Y\003B\330]\205\3103cj\201\333h\247|\264n]\366Bsr\260\352xXmH~\031]\210\203OG\351\207O&T\216b\276\273\221\fkY\230}\007G\024\271\351'\2422\r\367\246\366\352^#\203\b ):        \244\266\311\272\304\273\221\344\016\301|\236R\305\027\354]\314\266\246\206\321,5\313\325\305X?\333Mx\377\337me\304\346\205\341\230\352@<\217\357:\277\003\365\\370\331o\251\017\005\377V\365\004\005\275\200\324\200\231\241\026\206\260^N\023\304IB\031\020\230j\036\277\270\254#R\323!\250\2037h,\262^]>\371\3437DQ\374qI\355\362oNr?wSV\234\216X\244\212\204]\213lpc\302\264\252\334O\274\354\341C\333@r'\224\350w\306\254"}\220=\007\202\336+\375\206\351\r\351\214l\270\273\006" H=[181.67.204.178]:36043 I=[64.31.38.66]:25 NULL character(s) present (shown as '?')
2013-10-16 00:35:10 SMTP syntax error in "Q\356\226J\226\244\021y\033;\027\320W$\246\244\b\304\253\3444\020\260o#\006\265A6\275\273DF%7\201\205\265;4\246\016\312\244{"E\277P\312<\266\374\312\332\\272\365\336@\031\216\343\211 \005\350\304\352o\356\rkl\363\261%\225\370\344\262O\376\327z\003\002a\257\~\026(\266\204+\333H\022\307\3006\027\361S\234\033L5\007"\372,)\235\377kWJ\314\242\3270\216\334\203\254\364\223\233\262I5R\270\273W,F\365\341\211J?\322?O\241\345\267U\036n\224Z\373b\021`L\2478e\3549vi,\027\177\346\376Xa\3547\277\235\360$\213[\366\300\250\310\002\314s\274\b\2423\374\004H\341u\223\253\235\037\230\203\360\255\235u\017o\243\fd~\250\211\354Z\255\371\016\036\262\252/`\267[P\242\274\374\330~\301\227_\332\306\354\265j\313\353:E\321MZ\006\327fH\374\333\343\320\330\340\253\020v\Rd\004b\335fl\360@#\026\365\372\227\b\373\322\260\321u\037\215t\204\032\033d\202\232"\361\017Y\201\211\024>hw\031\327\233\312\225\215\246\336#\263\323\306(\243C/\245\344\017r\251\373\034\232\257t\265 \266\302FFB\264e\007H\326#l\303\374\332XRyc5WQV\301\334\232\246:a\027/\027f\026\264\361k\233\373urs\201Tz\325=\376~\2437\375\372\020\245(\212\016\322\020\217\304n\335\vy\226    \020R\356\373\241[J\023\247Li\324\254\210\3631\261=\243P\267\320h\2752\351\271\220\301\244t\272\306Xa.\314\241Q\245\3208\246\264\3257+\217\333\232\3478\340" H=[181.67.204.178]:36043 I=[64.31.38.66]:25 NULL character(s) present (shown as '?')
2013-10-16 00:35:10 SMTP syntax error in "" H=[181.67.204.178]:36043 I=[64.31.38.66]:25 unrecognized command

Again my sincere apologies if this is not the right place to ask this.

Regards, Arun Kurian

Solution

Judging from the output above, this seems more or less the same botnet that is attacking one of our servers too ... our logs showed something just shy of 30k unique IPs, with junk binary data sent from the moment the TCP session is up ... in such a situation, greylisting doesn't help any, as the problem is caused by the concurrent connections (at one point we counted around 2000 active/wait connections in the netstat output), which either runs the MTA into its process limit, or kills the CPU (if the limit of MTA processes is high enough). For now we activated a firewall policy to block any incoming SMTP that's not originated from our networks (/16, /19), hoping those f@cking script kiddies will lose interest soon and stop the bot attack. What we'd have to set up here is some sort of low-impact transparent tool that takes care of the TCP handshake, check's for a valid connection, in which case it spoofs the handshake and initial data and lets the rest of the session flow through without any interaction ... Yes, I know there are commercial solutions that do that, but they are well in the 5-digit range ...

Comments

[David Schwartz]

How is the attack hurting you? Be as precise as possible. Is it maxing out your inbound bandwidth? Your outbound bandwidth? Your CPU? Or what?

[Paul]

How have you established that there is a DDoS taking place?

[Arun Kurian]

Checking the mail log (/var/log/exim_mainlog) we could see attempts for establishing connection from different IP's and different nations. This is been ongoing for the last couple of days

[Keltari]

Your ISP should be able to help, contact them