A CBL false positive reveals a significant issue with the CBL

March 11, 2012

We were notified today that one of our IPs,, had been listed on the CBL (and thus had been pulled in by Spamhaus in their XBL and Zen DNSBLs). There's only one problem with this: there's no machine at that IP address and never has been, and even if there was such a machine it would not have been allowed to do any external traffic by our firewall.

(This subnet is only present on a couple of switches in our machine room and is not exposed outside of it; it's not even carried on our general inside-department backbone.)

However, there is a long standing issue where some people out there in the world are using addresses in 128.100.0.* and 128.100.1.* on their internal networks. These addresses leak into Received: headers and provoke spam complaints when these companies are exploited to send spam. Now they apparently also cause CBL listings.

(Back when I first saw this it was primarily from machines in Europe, but this time it appears to be a bad machine and organization in Brazil.)

Unfortunately, this is very bad. The only way for the CBL to pick up these IP addresses is for CBL feeders to parse the Received: headers in the mail they receive. Let me repeat that: the CBL is listing IP addresses based on parsing Received: headers from untrusted third party machines. And demonstrably this parsing can and has been fooled into false positives, listing machines that are not spam sources.

What we are seeing here is only one demonstration of what can go horribly wrong when you do this. As far as I am concerned, this significantly lowers the trustworthiness of CBL results. It used to be that I could trust that everything in the CBL was listed because CBL honeypots had direct experience with bad behavior from that IP. Now it is clear that for some or perhaps many listed IPs, the CBL has at best indirect 'evidence', evidence that can easily be wrong. Probably the CBL is still mostly correct and this sort of thing is rare, but I had previously thought that this sort of false positive was actively impossible in the CBL.

Written on 11 March 2012.
« Why you do not want to patch your source code in place
Why ZFS log devices aren't likely to help us »

Page tools: View Source, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Mar 11 00:41:23 2012
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.