Content Control - How to Ward Off Zombies Without Undue Collateral Damage
EFF has been studying various methods for content control (censorship, spam blocking, detecting copyright infringement, etc.). There are two main challenges: identifying content reliably, and avoiding collateral damage.
Randal Schwartz of Perl fame shows off a nifty trick you can do with everyone's favorite operating system (OS), OpenBSD: "Mail coming from windows boxes (all flavors) compete for my virtual 56K line. All other mail can come in the fat pipe. Already a huge difference in my load. Bwa ha ha." This means Schwartz has configured his firewall to "rate-limit" traffic on TCP port 25 from computers running Windows, on the assumption that such machines are more likely to be infected by malware used for email spamming. (These kind of infected machines are known as spam "zombies.")
In general, rate limiting (or "traffic shaping") is a better policy than blocking, because it is much less likely to cause incurable collateral damage. Collateral damage is when a policy adversely affects innocent parties -- that is, when they find that their traffic has been wrongly blocked, filtered, or mangled. But there's a problem with Schwartz's particular policy: identification. "Os 'Windows,'" as the PF rule states, is just an indirect means of identifying potentially naughty host computers.
The result is that Windows users will discover that their port 25 traffic* is preemptively rate-limited before there is evidence that their machine is a spam zombie, while users of other operating systems will have unlimited access to port 25 -- even if their machines are spam zombies. Or to put it another way, people or oganizations using Windows operating systems will get filtered out or rate-limited whether or not their machine is sending spam or other unwanted traffic, while those using other operating systems will get a free pass. Legions of unpatched Red Hat computers are standing ready to be 0wned...
Needless to say: (a) there are ways to exploit other operating systems, and if you create a profile for attackers to avoid, they will do so; and (b) OpenBSD's passive OS fingerprinting is almost certainly not perfect (it will wrongly identify some host computers some of the time).
A better alternative would be to use something like an intrusion detection system (IDS) to scan for truly bad traffic, regardless of the port it's on or what software the host is using, and then re-prioritize/shape/block it as necessary.
* A further complication is that port 25 is only an indirect means of identifying SMTP, which itself is only an indirect means of identifying unwanted content...