up vote 1 down vote favorite
share [g+] share [fb]

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.

link|improve this question
100% accept rate
feedback

5 Answers

up vote 1 down vote

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|improve this answer
@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
feedback
up vote 1 down vote

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|improve this answer
feedback
up vote 1 down vote accepted

I have a solution! This is specific to a Sonicwall firewall using the Application Firewall, but here are the steps to prevent this attack:

  1. Create a new Application Object with the following settings: alt text
  2. Create a new Application Policy with the following settings: alt text
    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|improve this answer
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
feedback
up vote 0 down vote

Have looked into blocking the ip addresses in question at your firewall? What type of firewall are you using? Does it have this ability? You can also send an abuse report to the netblock owner.

link|improve this answer
Yes, but with so many IP addresses changing every time a connection is killed, its an exercise in futility. Our deny list was up to 100 plus addresses in a matter of 30 minutes. We are using a Sonicwall firewall. – Scott Lundberg Sep 19 '09 at 19:58
1  
Are the incoming connections from the same or similar netblocks? If so you could try to block the netblocks at your firewall instead of blocking individual addresses. Also, does your email server or firewall support tarpitting? If so, you might want to look into enabling it. – joeqwerty Sep 19 '09 at 20:15
Sadly, no they are across many different IP blocks... We do not have tarpitting capability right now. Any suggestions on good tools for tarpitting? – Scott Lundberg Sep 19 '09 at 20:47
No. The only thing I can think of at this point is to look at implementing an SMTP proxy that has antispam, tarpitting, SBL, etc. capability. – joeqwerty Sep 19 '09 at 21:23
feedback
up vote 0 down vote

I hope fuzzy filter to iptables would be helpful.

link|improve this answer
If I understand it correctly, it only limits based on packets per second? If so, not sure that will help since the number of packets per IP is low. It's the number of IPs x 2 attempts per second that is the issue in my mind... Maybe I am missing something? – Scott Lundberg Sep 19 '09 at 20:00
feedback

Your Answer

 
or
required, but never shown
discard

Not the answer you're looking for? Browse other questions tagged or ask your own question.