A CBL false positive reveals a significant issue with the CBL
March 11, 2012
We were notified today that one of our IPs, 22.214.171.124, 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
(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
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.
Comments on this page:
* * *
Atom feeds are available; see the bottom of most pages.