chun

SMTP DOS attacks with malformed email addresses

1

We have the following setup: Redhat kernel 2.4.16 Sendmail 8.11.6 This is a very old, ~7 years, cobalt RaQ server and is not easily upgradeable. Currently, we are being hit by multiple IP addresses from Latin America, Russia, Pakistan and others that open SMTP connections to our mail server and attempt to send emails from malformed addresses. Always missing the top level domain and similar in format to: losingm7@mysterious kingleirr5@pc etc Our sendmail responds with:  sendmail[6973]: n8JABr406973: ruleset=check_mail, arg1=<evangelinaii2@mysterious>, relay=wtl.worldcall.net.pk [115.186.114.184] (may be forged), reject=553 5.1.8 <evangelinaii2@mysterious>... Domain of sender address evangelinaii2@mysterious does not exist At this point, the attacker sends a RSET command and trys another similar but different email address. We are getting ~2 attempts every second from each IP address. The reason I think this may be a DOS attack is that as soon as I kill a connection, within seconds a new IP address starts up another attack from a completely new geography. For example, I kill a connection from Chile and another connection from Columbia starts 1 second later. Obviously, this is causing unnecessary load on our mail server and I would like to stop these connections at the gateway if possible. Does anyone have ideas on how to fix this? I realize our mail server is badly in need of replacement, and that is in the works, but not complete yet. What I am looking for is a band-aid on this issue. Thanks. emailserver sendmail dos ddos flag asked Sep 19 '09 at 18:55 Scott Lundberg 1,5171110 100% accept rate

5 Answers

oldest newest votes

1

Are the messages sent to valid addresses in your domain? If not, this sounds like a pretty typical experience for a mail domain that's been around for at least 7 years -- we see tens of thousands of directory harvesting messages to accounts that don't exist on our domain every day. Your smtp gateway should be gracefully dropping these connections rather than sending NDRs or processing the message, which limits the impact a good deal. I'm not familiar enough with sendmail to know if it's behaving this way from the log line you've included, but if the sending server is the one issuing the RSET rather than your mail server, I suspect not. Is this something that you've noticed begun only recently or that has changed? Even for our relatively small organization, if I watch the inbound connections I'll definitely see dozens of connections or more every minute, and if I kill one off another will undoubtedly pop up, and yes, they're from all over the world. 98-99.9% is Spam. Sadly, that's the nature of having an email server these days. link|flag answered Sep 19 '09 at 19:24 nedm 1,418615

@Nedm: From a sniff I have run, our mail server sends the 553 message immediately after the attacker sends MAIL FROM:<malformed address>. The attacker never gets to send the RCPT TO:, so I don't know if it is trying to send to a current user. The attacker then sends a RSET command to our mailserver, which then resets the SMTP state and the whole things starts over, but the TCP connection is never dropped...which you have correctly identified as a problem (I just don't know how to solve it). This is recently (past 2 days) – Scott Lundberg Sep 19 '09 at 19:57

1

You might check out fail2ban. It'd take some configuration, but you could set up a box to act as a bridging firewall between your mail server and the outside connection, then use fail2ban on the bridge to scan your smtp logs on the mail server. When it detects an anomaly in the mail server logs it blocks the ip address for a period of time. This link could give you a start. This is just an off the cuff answer that might or might not be a good way of doing this. But the benefit is requires minimal reconfiguration of your mail server. link|flag answered Sep 19 '09 at 21:20 emgee 57918

1

I have a solution! This is specific to a Sonicwall firewall using the Application Firewall, but here are the steps to prevent this attack: Create a new Application Object with the following settings: Create a new Application Policy with the following settings: Note the link to the Application Object created in step 1 (553 response in SMTP) and the Action Reset/Drop (which is a built in Action) After implementing this policy, I was able to verify with sniffs that a TCP RST was sent to the mail server and the SMTP connection was immediately dropped and closed, so there are no open ports on the mail server and the attacker goes away. link|flag edited Sep 19 '09 at 21:58 answered Sep 19 '09 at 21:50 Scott Lundberg 1,5171110

So if the firewall sees an SMTP 553 from your server, it drops the connection? That seems like it will do the job of killing the session, still though it doesn't prevent the connection in the first place, but if it works then it works I guess. – joeqwerty Sep 19 '09 at 22:16 Nice find, BTW. – joeqwerty Sep 19 '09 at 22:17 Thanks Joe! I spent the better part of two hours messing with it... Yes, you are correct, the firewall RSTs the connection if it sees a 553 5.1.8 response from our mailserver. This response indicates that the mailserver will not deliver the message anyways, so dropping the connection should not affect real messages... I hope. I don't see a way to prevent the connection in the first place since there is no way to tell what the attacker is going to use for a sending mail address... – Scott Lundberg Sep 19 '09 at 22:33 YW. It's always nice to get that sense of accomplishment when you find a solution to a problem. – joeqwerty Sep 19 '09 at 22:37 Very nice solution -- looks about as elegant as can be working with what you've got. If the IPs keep changing there's no way to prevent the connection in the first place, and this looks like it nips it in the bud pretty well. – nedm Sep 20 '09 at 4:46