Wandering Thoughts: Recent Entries For 2010/04/11

The comedy potential inherent in people reusing your address space

For my non-sins, I used to be one of the people who saw email complaints about UofT-wide spam issues (as opposed to spam issues for the specific subdomains that I was responsible for). As part of this, every so often we would get a complaint saying that a UofT IP address (usually but not always in 128.100.0.*) had spammed people, with Received: headers included so that we could see this ourselves.

There were two problems with these complaints. First, invariably the IP address was not in use (and to make it sure the 128.100.0.* subnet has never been assigned or routed on the campus backbone). Second, the Received: header with our IP address in it was never the most recent Received: header; there was always another machine that had touched the message after it.

(Normally this is the sign of a compromised machine that is forging Received: headers, although not in these cases.)

Eventually we worked out what was going on. Somewhere (apparently in Europe), sometime, some people writing documentation for a firewall or a 'how to plan your network' or something had decided to use 128.100/16 as the example internal network that they were configuring things for. Naturally, people using the documentation had decided to imitate this example and had set up their 'inside the company' network using 128.100.* addresses, often very low in the address space (hence 128.100.0.* addresses).

Equally naturally, people who do this sort of thing often have vulnerable mailers, so they got exploited for spam. The spam email went through their internal machines, picking up their internal 128.100.* IP addresses in the Received: headers, got relayed through their outbound gateways, and was delivered to unhappy people. Some of those people looked at the Received: headers, found our IPs, and sent complaints. Confusing comedy then ensued.

(Of course we couldn't send grumpy complaints to the companies at fault, since their routing and firewalls didn't permit them to talk to us. In fact this was one of the signs we used to figure out the problem; machines in 128.100.* couldn't talk to their external mail servers, but other on-campus machines in a different subnet could.)