Slashdot Mirror


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?

20 of 72 comments (clear)

  1. I don't understand the problem by PD · · Score: 2, Funny

    I think I've been blacklisted from AOL and Earthlink.

    You're complaining about this?

    In all seriousness, if you're getting blacklisted because of Sobig mails, then you're really better off without dealing with those people.

  2. Do not use Outlook, etc. by PeteyG · · Score: 2, Interesting

    My friend was complaining about getting spam and viruses yesterday, so I told him where to get Thunderbird. He wasn't very tech-savvy, but with a few words of help from me he was up and running in a matter of minutes.

    Seriously. Pushing non Microsoft email clients on your users (politely, anyways) is the way to go.

    --
    no thanks
    1. Re:Do not use Outlook, etc. by questionlp · · Score: 4, Informative

      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.

    2. Re:Do not use Outlook, etc. by Matts · · Score: 5, Insightful

      This is a common misconception by geeks who are smug because they didn't get infected with Sobig.

      Sobig didn't use any exploits. It was just a plain old .EXE attached to an email. Outlook prompted the user when they tried to run it telling them that exes often contain viruses. But they still ran it.

      This behaviour is the same in Thunderbird and other windows mail clients. It's even the same in Apple's Mail.app.

      Don't be a bigot and assume you're immune because you don't run Outlook.

      --

      Matt. Want XML + Apache + Stylesheets? Get AxKit.
  3. Sobig - 50% of our mail traffic. by MightyTribble · · Score: 2, Interesting


    We're a small (100 person) company that averages about 4,000 internet emails a week (excluding spam, which adds another 1,500 - 2,500 / wk). Since SoBig we've seen our traffic levels increase 50%. I've had 5,700 + SoBig mails since the start of the outbreak.

    This isn't a problem for us (aside from annoying antivirus messages) as our bandwidth and mailservers can easily handle it, but I know some big companies had to shut down their internet-facing mail gateways due to the increase in volume. I suspect the more well-known your domain is, the worse it is.

    However, for AOL and Earthlink to blacklist you based on false 'From:' entries is just stupid. Are you sure they've blacklisted you?

    1. Re:Sobig - 50% of our mail traffic. by aridhol · · Score: 4, Interesting
      However, for AOL and Earthlink to blacklist you based on false 'From:' entries is just stupid
      Amen. The way I'd configure it:
      • Get a virus scanner, set to auto-update
      • Scan all incoming emails
      • When a server passes a certain threshold of incoming, virus-laden emails, block it
      • When a netblock passes a certain threshold of blocked hosts, block the netblock. This should block the ISP's mail server if their customers are sending out directly due to the virus.
      • After a specific amount of time, but hosts and netblocks into a greylist. When you're on the greylist, one offence gets you back into the blacklist.
      • After a specific amount of time on the greylist, remove them from the blocks entirely
      --
      I can't say that I don't give a fuck. I've just run out of fuck to give.
  4. Best fix so far.... by hawkbug · · Score: 4, Informative

    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.

    1. Re:Best fix so far.... by shamino0 · · Score: 5, Interesting
      In the case of SoBig, you've got an advantage that you don't necessarily get from other worms.

      According to Symantec, SoBig uses its own SMTP engine to propagate. And according to my analyses of the headers, it appears that it attempts direct-to-MX sending.

      This gives you two advantages.

      First off, it means that the first Received: header in the mail will contain the IP address of the infected machine. This will give you enough information to inform the ISP (who can then inform his customer) if you're so inclined. Or at minimum, you have an address you can temporarily block until the storm dies down.

      The second advantage is that you can keep it from spreading beyond your own network if you block your customers from port 25 (and force them to send all mail through your mail server.) While this may annoy a few customers, most probably won't even notice, and it will keep any infected customers from spreading the virus to the rest of the world.

      Unfortunately, there's nothing you can do about all the bounces caused by other people that are spewing the virus with forged headers. I found that (for myself, anyway), the easiest way is to mark the bounces as spam with Mozilla, and let the Baysian filtering move them out of my way. But this doesn't do much good if you're looking to protect a mail server.

  5. Fucking Spammers by Goo.cc · · Score: 3, Insightful

    The usefulness of E-Mail is slowly being destroyed by Spammers. There has been a few times now that I couldn't either send or receive an e-mail because of blackholes and I get more spam everyday. Is there anything new on the horizon to prevent spam? Laws, Filters, Blackholes, and Whitelists seem unable to do anything about this problem.

    Maybe we should just start suing the companies that use Spammers. (Some will deny knowledge of any spamming but ignorance of who is doing your advertising is no excuse IMO.)

  6. Block non-FQDN HELO by linuxwrangler · · Score: 2, Informative

    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.

    --

    ~~~~~~~
    "You are not remembered for doing what is expected of you." - Atul Chitnis
    1. Re:Block non-FQDN HELO by mrex · · Score: 2, Informative

      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.

    2. Re:Block non-FQDN HELO by linuxwrangler · · Score: 2, Informative

      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.

      --

      ~~~~~~~
      "You are not remembered for doing what is expected of you." - Atul Chitnis
    3. Re:Block non-FQDN HELO by walt-sjc · · Score: 3, Informative

      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.

  7. I've got the same problem - can't fix from my end by ajrs · · Score: 2, Informative

    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.

  8. Use Message-ID? by anthony_dipierro · · Score: 2, Interesting

    Can't sendmail be set up to check the Message-ID and make sure that it is an ID which was actually sent? Alternatively, just block "Message Undeliverable" messages.

    1. Re:Use Message-ID? by Chester+K · · Score: 2, Informative

      No. I don't. I block bounces.

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

      --

      NO CARRIER
  9. Re:Filters! - A Solution by Hyperbolix · · Score: 2, Insightful
    There is actually a way to block this kind of thing using procmail and a copy of a valid message sent by the user or some information from their mail program settings. Here is why:

    - The bounce back messages will always contain an SMTP status code like 5.1.1 (for user unknown).

    - If the message that caused the bounce back really originated from the user, then the bounce back message will contain the user's Display Name as set in his or her email program (often Outlook Express). The display name can also be found in the "From" line next to the real email address, if you only have a legit message from the user and don't have access to information from his or her settings.

    - If the message that caused the bounceback did not originate from the user, then that Display Name will not be present in the bounce back message.

    Therefore, if a user's Display Name is "Foo Bar", and their email address is not the same as the Display Name (for example farboo@some.place), the following procmail script will stop most bounce back messages triggered by messages that did not originate from the user's computer, and should allow those that did:

    :0 HB
    * ^FROM_MAILER
    * Status: 5.1.1
    * ! Foo Bar
    /home/farboo/mail/viruses

    This would be placed in a .procmailrc file in the user's home directory and would only work if your mail server uses procmail for delivery. Also, I must mention that no content based filtering (such as this) can be 100% accurate.

    Am I good? Am I good? I'm good. (Does a little dance).

    - J. B.

  10. Email Virus: Get it right by cmowire · · Score: 4, Informative

    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.

  11. What I do ... by Abm0raz · · Score: 2, Interesting

    I work for a medium sized Engineering & Telecommunications firm (>500 employees all over the east coast). I have a mail filter set up on an intermediate MTA to catch all executable files. This includes .PIF, .BAT, .SCR, .EXE, .COM, etc. When a file of this type comes in, it is parked in a holding folder for 7 days. A notification message is sent to the recipient and back to the sender (I, know this sucks, but bear with me a second) with instructions on how to send another email back with a release code in the subject. When the message with the release code is received by the MTA, it continues delivering the original email to our actual mail server. If no message is received in 7 days, the original mail is deleted.

    Now, once the SoBig hit, I made a seperate rule to catch just those files. No notifications were sent. It parked them for 4 days then deleted them. In that time, I've written a small script** that parses the header of all parked files every morning at 7:45am. It grabs the IP# of the originating computer and tosses it into a spreadsheet. Once it has done all parked messages, it tally's them up and sorts them by the most common appearing numbers. Then, when I get in at 8am, I do a WhoIs lookup on the IP as well as an nslookup. I try and contact the owner of the netblock and notify them that they have a computer infected with SoBig on their network and it is attacking us. I have yet to have anyone that hasn't co-operated fully (though, Comcast took a bit of prodding). My worst case was a 3 day period where a single cable modem user in Philadelphia on Comcast.net sent us ~13,000 Sobigs a day. Just this morning I had to contact an ISP/Network Security company in NYC to have a machine there cleaned.

    I know it's not my responsibility to see that other people clean their machines, but it is affecting our productivity at work. At the height of the infestation, we were receiving over 28,000 SoBig viruses a day. At ~100Kb each, it was causing massive delays in the mail queue. Keep in mind that most people don't even realize they are infected with it, so they need to be notified so that they can clean it.

    -Ab

    ps. The script is fairly simple because the built in mail transfer agent in the SoBig is basic (Though I was impressed at the spoofed header-field, X-MailScanner: Found to be clean, that says it's been checked by SpamAssasin(?) and is not Spam. If anyone is interested in the script (it is a VB executable, but I can send the source code or psuedo-code so it can be recreated in perl/python) let me know.

    --
    Nothing fails quite like prayer.
  12. Make your mail server robust by Thoron · · Score: 2, Interesting