Defending Your Mail Server?

soren42 asks: "I've been a casualty of war in the latest round of SoBig battles. Apparently, some of my user's e-mail addresses were in the address books of infected Outlook clients, and spam is now being circulated appearing to come from my domain. I'm getting almost 50 'Message Undeliverable' errors per hour, and I think I've been blacklisted from AOL and Earthlink. I know there are plenty of you are having this problem - how are you dealing with it?" Email viruses, once urban legends, have now become a real threat to certain people. What active measures can users (both vulnerable and non-vulnerable to such things) take to lower the propagation rate of such viruses across the internet?

Comments

Best fix so far....

[hawkbug]

The best fix I have found so far is to analyze all those "fake" messages, appearing to come from you to other people, and even the messages flooding into some of your user's inboxes. I found that that I was getting about 200+ messages an hour, to several mailboxes. The good thing I discovered about these is that they call came from the same cable modem-based ip address. So, the easy and obvious solution - add the ip to /etc/hosts.deny. Also, add the ip to your firewall to get denied, and to /etc/mail/access. Even if you don't use Linux (sendmail more specifically) for your mail server, you can also block incoming traffic in Exchange 2K. We did that as well. Soon after I did that, the generic bounce back messages stopped, and all was well again.

Block non-FQDN HELO

[linuxwrangler]

RFC2821 requires the HELO/EHLO to be fully qualified. Most (all??) sobig EHLO with the Windows netbios name.

Sure, the next virus might be more RFC compliant but it stops this one. We already require FQDN EHLO to reduce spam so sobig didn't make it past our mail server.

As a bonus, sobig seems to connect directly to the recepients MX so simply rejecting the message (as opposed to accepting a message and generating a bounce) reduces the overall impact on the network.

If you don't HELO with a FQDN then you aren't "speaking" SMTP so don't expect my SMTP server to communicate with you.

If you are running a corporate network where users shouldn't be making direct SMTP connections, filter outbound port 25 and use an IDS/log checking to see if someone inside has gotten infected.

Re:Block non-FQDN HELO

[mrex]

Unfortunately, also according to RFC 2821, a mail server must not reject a message based on the contents of the HELO/EHLO. I break RFC and reject the message only when the user tries to HELO as the IP/hostname of our mail server as this is naught but a spammer tactic to try and get messages whitelisted. (Older SpamAssassins will whitelist based on HELO...)

It could indeed be a very bad thing to block mail when the user doesn't HELO with an FQDN, as many mail clients including, I believe, Outlook, HELO as other things such as the SMB name. If you're OK with not accepting mail from Outlook users, more power to you. I wish I had that luxury.

Re:Block non-FQDN HELO

[linuxwrangler]

Um, not exactly. It actually says that you must not reject a message just because the EHLO doesn't resolve to the connecting IP. You can't even get that far if you violate section 3.6:

3.6 Domains ...
The domain name given in the EHLO command MUST BE either a primary host name (a domain name that resolves to an A RR) or, if the host has no name, an address literal as described in section 4.1.1.1

Unless your computer's netbios name is something like [12.34.56.78] then it probably fails to meet every possible allowed EHLO name format.

Note also section 7.7:

7.7 Scope of Operation of SMTP Servers

It is a well-established principle that an SMTP server may refuse to accept mail for any operational or technical reason that makes sense to the site providing the server.

This section goes on to say that interoperability is what makes email the powerful tool it has become so use this power carefully. I consider killing spam, preventing the spread of viruses, and protecting my mailserver so that it remains available to the users it is meant to serve are all completely valid and necessary reasons for refusing mail. I don't think I'm alone.

Re:Block non-FQDN HELO

[walt-sjc]

What you are not supposed to do is reject AT the HELO. It's perfectly fine to reject at RCPT (which is the best spot since it universally works with all MTA's.)

As for Outlook or any other mail CLIENT, you should be using SMTP AUTH. If they are NOT authenticated, don't come from the local network, then you shouldn't have any problem blocking bad HELO's that are not FQDN. I use exim rules to do this, but I also maintain a whitelist just in case I run into a moronic company / ISP that refuses to fix their system. Most will.

I also block all HELO's that use an IP address of the hostname. So far this year I have not had any false positives. Most is spam that actually uses MY IP address in the HELO (Of all the nerve!) The RFC's allow IP addresses, reality is that nobody but spammers use them as the HELO hostname.

I've got the same problem - can't fix from my end

[ajrs]

nobody in my network (me and my wife) use outlook, and we're tucked safely behind a firewall. I've added about 10 DSL ips to my blacklist, but there is nothing I can do to prevent the spoofed outgoing messages from some other network. I'm still getting bounced email 'returned' to me that I never sent.

Re:Do not use Outlook, etc.

[questionlp]

Don't forget that there are mail clients (iirc - Eudora is one) that use the HTML rendering component used by IE. Which means that the mail client is just as vulnerable as Outlook Express or Outlook if the user's IE install is not up to date.

Re:Use Message-ID?

[Chester K]

No. I don't. I block bounces.

Ah, the communications equivalent of Plug-and-Pray.

Email Virus: Get it right

[cmowire]

Actually, it's an email virus, not an Outlook virus.

It uses a efficent multi-threaded internal mail engine that uses any available mail addresses it can find on your system (browser cache, address book -- which Domino will register itself as too, etc).

It spreads because people are generally stupid and will open up attachments.

Outlook is not needed. It can even spread if you are using webmail.