Category: Security

Prodigy Infinitum, SMTP through port 25, botnets and such

dsl.jpgAfter pulling my hair for a couple of days I just realized that my DSL provider is blocking all outgoing connections to port 25 with an ICMP Unreachable packet, which translates as a totally bogus “no route to host” message (An ICMP RST would be more kosher, BTW). The only explanation that comes to my mind is that Telmex has finally realized that it has become one of the largest botnet hosts in the world and decided to do something about it. This is a terrible inconvenience for me, because I run a backup MX at my home office and all the email I write while I’m at home is relayed through it. And now it believes that it has been cut out from the Internet, and is suffering from Internet withdrawal syndrome. Oh, and all attempts to use an external relay -like my primary MTA or the office’s- through port 25 fail as well, so I have had to set up an elaborate workaround *just to send email*.
*Argh!* I hate to pay up for those ignorant Windows home users.
Add to that the fact that i get 800KBps tops in a 2GBps line, and recurrent reports of arbitrary bandwidth capping and Infinitum stops looking like a good alternative for home broadband. I’ll have to look for a cost-effective alternative, but after experiencing 20MBps/20EUR in Europe I’m afraid that I’ve been spoiled for life.
In the meantime, if you were expecting a mail from me in the last five days or so, I’m sorry to say that it is either on its way or lost forever.
Anyway… Merry Christmas!
Update 20080104: AJ Gibson points out in a comment that Telmex is willing to remove the block from your account if you are willing to jump through a few hoops. Just go to http://www.telmex.com/mx/asistencia/correoelectronico/faq_puerto_25.html and follow the instructions there. I registered yesterday and today I can connect back to external SMTP servers again. As mentioned in the comments, YMMV.

Mitigate the .WMF vulnerability with Exim, Squid and SquidGuard

Unless you’ve been on holiday leave you’ve probably heard about the WMF vulnerability by now. Everything seems to indicate that Microsoft won’t take action to patch this gaping hole before January 9th, so here are a few measures to be on the safe side.

1. Before you do anything else, go ahead an unregister SHIMGVW.DLL

C:\> regsvr32 -u %windir%\system32\shimgvw.dll

Put this in a login script, and just for good measure go ahead an run it in every Windows box you’re responsible for. Heck, run it even in those you’re *not* responsible for as well.

2. I already got quite a few .WMF attachments on the spamtraps. F-Secure has a very interesting specimen and a lot to say about it. So the next step is to block them in exim.conf. Enable the acl_check_content ACL and make sure that you have a rule like this one:

  deny  message = This message contains an unwanted file extension ($found_extension)
        demime = scr:vb:vbs:vbe:js:jse:reg:bat:lnk:pif:hlp:dll:com:rar:wmf

3. SquidGuard can filter URLs that match a given regular expression. Add these regexes to a local-blocks/expressions or similar file:

http://.*\.(scr|vb|vbs|vbe|jse|reg|bat|lnk|pif|hlp|com|rar|wmf)($|\?)
ftp://.*\.(scr|vb|vbs|vbe|jse|reg|bat|lnk|pif|hlp|com|rar|dll|js|wmf)($|\?)

Note that the .dll and .js extensions aren’t blocked for HTTP. That’s because the lovely IIS uses the .dll suffix for its extensions, and you can’t block JavaScript for HTTP either unless you want to break 90% of the Internet for all your local clients. I firmly belive that blocking them for FTP is just fine, tough.
Update 20060102 125530: Jeremy Gaddis shares a squid recipe.

Of course, this only applies if you use exim and Squid+SquidGuard -which by the way are all excellent Open Source products- but the same principle applies to any other mail and proxy servers. If you implement all three recommendations you should be fine. User should not get .WMF files through email or the Web. Even if a clueless user catches it though some other means (IM, external e-mail account, a *ack!* floppy disk/CD-ROM/flash drive, a helpful colleage, etc.) the REGSVR32 workaround should keep the exploit at bay. If you definitely need to work with WMFs, there are other alternatives as outlined by Richard Bejtlich. Just don’t hold your breath for a Microsoft-backed patch.

<rant>And about Microsoft’s “swift” response to this issue: The next time that someone gives me the line about not using Open Source because there’s nobody to take responsibility for problems, I’ll puch him in the face without further warning.</rant>