Monday, June 25, 2007

Thursday, April 19, 2007

IT Pro Townhall Meeting in Redmond

This week I've had the opportunity to take part in an IT Pro Townhall meeting up here in Redmond, which gave me the opportunity to "voice my concerns" about the Vista copy protection problem to other IT pros and even a couple of Microsoft folks. We'll see what happens from it.

In any case, I've had a great time meeting a number of people: Jeff Hicks from scriptinganswers.com (Sapien), Jeffrey Snover (Windows PowerShell team), Darren Mar-Elia (gpoguy.com), Mark Minasi (minasi.com), Susan Bradley (sbsdiva.com), Mark Burnett (the LogParser book guy), and last (but not least) Karen Forster, editorial and strategy director for Windows IT Pro magazine (she's the one that recommended me to go to the event). Our last session of the day was a short sit-down with Steve Ballmer, and a few people were able to ask him some questions. It was an interesting and informative event.

Not surprisingly, licensing seemed to be a recurrent pain for us all. One participant made the suggestion that if Microsoft, internally, had to deal with their own licensing schemes that the rest of us are forced to put up with, the problem would go away...

Friday, April 13, 2007

How smart is your spam filter? (Part 2)

Back in February, I wrote about how GFI MailEssentials (a widely-used anti-spam software) can't reject invalid recipients at the SMTP level. It's funny, because I pointed out to them in their product support forum how this has the potential to exploit their software to send backscatter spam. It appears that they don't take input seriously, or they don't understand the problem, because I exploited one of their own servers to send backscatter to myself. Before I explain how I did this, though, I need to provide a bit of detail about the MailEssentials software.

The MailEssentials software has a Bayesian statistical filter that you can "train" to detect legitimate mail versus spam. One way to do this is to forward a message to rcommands@mailessentials.com and include a command at the top of the message. The program detects this outgoing e-mail address, checks the message for the command, and updates the Bayesian database accordingly.

Apparently, the mailessentials.com domain name is protected by MailEssentials, because recently I started getting bogus NDRs (non-delivery reports) when updating my Bayesian database. First, I looked up the MX record for this domain name. Next, I opened a telnet session on port 25 to the highest-priority server. I then entered some SMTP commands to see if I could send backscatter:

HELO myhostname
MAIL FROM: bogus_address
RCPT TO: rcommands@mailessentials.com
DATA
Subject: Bogus NDR test

For bogus_address, I used a gmail.com address. Sure enough, the server accepted my mail, and sure enough, the bogus NDR was sent to the gmail.com address. In other words, I just exploited an anti-spam vendor's server to send backscatter.

This would be funny if it wasn't so frustrating. I've pointed out an exploitable flaw in their product's design, and not only do they not listen, they misconfigure their own server to allow the exploit...

(Update for April 16th: Apparently they finally figured this out and disabled bogus NDRs on their server.)

Wednesday, February 28, 2007

How smart is your spam filter?

Managing an anti-spam solution is an unglamorous job for any e-mail administrator, but it's less enjoyable when your software is broken. Case in point: My company uses GFI's MailEssentials, which in some respects does a decent job filtering spam. It offers a feature common to many spam filters: Directory harvesting protection. Directory harvesting protection is a countermeasure designed to prevent spammers from figuring out the names of legitimate recipients.

However, MailEssentials' directory harvesting feature appears to have been an afterthought, because the program only checks recipient validity after it accepts a message. The program does offer a "Generate a Non Delivery Report (NDR)" option, but this is a fake NDR (aka a delivery status notification, or DSN) because it's only sent after your server has accepted transmission of a misaddressed message.

Why is this behavior a bad thing? First, if the NDR option is disabled (the default), a sender that misspells an e-mail address is never notified that the recipient name is not valid. This is good for spammers (you don't want them to know your valid addresses), but it's not good for valid senders (they're never notified that the address doesn't exist). So, you decide to enable the fake NDR feature. This is even worse, because it lets spammers exploit your server to send backscatter.

What's backscatter? Backscatter is spamming via DSNs. Imagine this scenario:
  1. Spammer sends a message to your server. The "from" address is the address he's spamming, and the "to" address is a non-existent recipient on your server.
  2. MailEssentials accepts the message, then determines that the recipient doesn't exist.
  3. MailEssentials generates an NDR to the fake "from" address.
The spammer has just successfully exploited MailEssentials to send backscatter--ironic because MailEssentials is a product designed to fight spam. Not very smart. It's also frustrating because I've explained this to GFI and they have not been responsive to the problem.

The right way to reject invalid recipients is to do it during the SMTP conversation, before the message even gets transmitted. This way, the sending server is forced to deal with the failure. This way of doing things has two good side effects:
  1. Your server spends a lot less time dealing with mail sent to invalid recipients.
  2. Legitimate users that misspell an e-mail address will get an NDR from their own server (not yours).
Some mail servers have this functionality built-in: Exchange 2003 and later, for example. (Earlier versions of Exchange are not as smart.) However, this means that your Exchange server must sit directly on the network perimeter, a configuration that's generally considered a bad security practice.

The point is that you should not rely on GFI MailEssentials to be your only spam filtering solution. I opted for a smarter product: Vamsoft's Open Relay Filter Enterprise Edition (ORFEE). Like MailEssentials, it uses Microsoft's SMTP server, but unlike MailEssentials, it lets you filter mail during the SMTP conversation. It can do address lookups in an Active Directory domain and reject recipients before the e-mail gets sent. ORFEE can also delay server response on invalid recipients (sometimes called tarpitting), discouraging spammers that are attempting to harvest your directory. You get all the benefits: Legitimate senders are notified if they send to a non-existent recipient, the spammers will most likely not tolerate the delays when they attempt to gather valid addresses, and they can't use your server to send backscatter.

Monday, January 29, 2007

What's in a Name?

The Altair is sometimes regarded as the first personal computer. It was sold by MITS in Albuquerque, NM, USA, and Microsoft designed the first BASIC language for it. I never owned an Altair, but since its creation set in motion a chain of events that now provides my employment I thought it was suitable to pay homage.