CERIAS - Center for Education and Research in Information Assurance and Security

Skip Navigation
Purdue University - Discovery Park
Center for Education and Research in Information Assurance and Security


Page Content

Using DNS for first-level spam filtering


We have had some success using domain name system lookups to block incoming mail messages that are likely to be junk mail.  While many people (including us) use DNS real-time black lists, the checks below are done against values returned by regular forward and reverse lookups on the connecting IP address.  We’ve stopped a large amount of traffic based on the name of the connecting host or due to “poorly” configured DNS without many complaints.  The number of false positives, while non-zero, have so far been at levels acceptable to us.

The first test is a sanity check of sorts on the name of the connecting host.  If no reverse lookup can be done on the IP address of the host, the message is blocked.  A forward lookup is then done on the just-returned host name.  If the forward and reverse lookups do not match, the message is blocked.

Then the hostname is checked against a regex that tries to match dial-up or home cable/DSL addresses.  If it matches that, the message is blocked.  The expectation is that this will help block the spam zombies on less than ideally maintained home machines out there.

These checks do generate false positives.  There are some domains where outgoing mail comes from hosts with no name in DNS or all hosts of the domain have names of the form ip-NNN-NNN-NNN-NNN.domain.  Some smaller companies or individuals are given addresses from their net providers of that form and are unable to change them.  Apparently many net providers think it’s a good idea to do a reverse lookup on an IP address but then not have a valid forward lookup for the just returned name.  To help with these cases, the SMTP rejection message includes a URL where one can request that their addresses be added to an exception list.

Now to numbers.  During the average day last week our SMTP server got 8719 connection requests.  The previously mentioned DNS tests resulted in the blocking of 4463 messages, or about 51% of all our incoming traffic.  Since this happens before any virus scanning or spam scanning on the content of the messages, it saves quite a bit of CPU and IO time on the server.  While this system isn’t perfect, it is so effective as a first pass filter that we put up with the few false positives that have been reported so far.

Didn’t we learn anything from WarGames?


My s.o. and I watched WarGames last night, and I enjoyed it not only for the kitschy nostalgia of an 8-inch floppy disk, but for some of the lessons of good information security practices that we still have trouble remembering:

  1. Don’t write down your password.  Matthew Broderick’s character is able to break into his high school’s computer system and alter his grades because he reads the password off the secretary’s desk every couple weeks.
  2. Don’t make high-security systems publicly accessible.  The W.O.P.R. computer (wasn’t that a great name?) that controls the launch of the US nuclear arsenal is accessed over a public phone line.  Firewalls, anyone?  Bueller?

It does seem like folks are generally getting a lot better with #2, but #1 seems to be a tougher nut to crack.  It’s understandable, because it’s much more of a human behavior issue, but sometimes you just wonder, have we learned nothing in 20 years? smile


Surveillance Society


This morning, wamu.org : The Diane Rehm Show featured guests Robert O’Harrow, author of “No Place to Hide,” Bruce Schneier, security expert and blogger, and Joe Whitley, the former general counsel of the Department of Homeland Security.  The show outlined the current tensions between security and privacy and highlighted the threats to privacy brought about by advances in infomation technology, data minining and even medical technology.  While some of these issues may seem a bit tiresome for those who study security and privacy, the guests emphasized an important point: Threats to privacy are not well-understood by the public, which may be a reason for the general lack of concern over the overextension of the NSA’s surveillance powers.

Mambo worm highlights security problems in web app dev


Christopher Kunz reports on the existence of another web app worm, this time exploiting in the widely used Mambo portal/CMS system.  Like the Santy worm that attacked phpBB, Elxbot identifies vulnerable installs via Google, but goes way beyond simple site defacement.

Jeff Moore discusses this as a good example of why web apps need better installation/update systems.  He’s absolutely right.  Wordpress, one of the most popular open-source web apps, has a fairly decent installer, but is a nightmare to upgrade.  The developers don’t even release “upgrades” per se, but give users some minimal instructions on what files to overwrite and what to skip.  Even though the XML-RPC vulnerability that hit Wordpress and many other PHP-based apps a few months ago was patched immediately, it seems likely that there are large numbers of Wordpress users that are unaware of the problem and have not installed (it’s difficult to find sources for stats on this, though).

Beyond that, this underlines the need for both educating developers on secure coding practices, and developing freely available tools to help developers audit their applications.  This is particularly important for the open-source web applications that drive a large portion (a majority?) of dynamic web sites.  An Information Week article from a couple weeks ago that discusses how malicious coders are now targeting applications (including web apps) quotes Howard Schmidt:

In an e-mail, Howard Schmidt, a noted cyber-security expert and former CSO for both Microsoft and eBay, said the SANS report highlights the utility of hardening the presentation and application layers as a means to reduce cyber security events. “The first stop on the way to fix this is through secure coding and better QA of development processes, penetration testing on compiled code as well as vulnerability testing of integrated deployed applications via Web front ends,” he wrote.

Hopefully more people will start to realize this before the problem gets worse.

CIRDB 3.06 released


In this version, the CIRDB has been updated to import XML data from the National Vulnerability Database, and a few bug fixes were made (a library file was missing in the previous distribution to support RSS feeds of the status of each domain over SSL).