Recently my brother contacted me via IM to ask about some strange network behavior on his machine. He was using sysinternals tcpview, and noticed that svchost.exe was opening connections to two IP addresses; one on 80.66.x.x subnet, and another somewhere beneath a different 80.x.x.x subnet. He was concerned because the IP addresses in question showed up as “unassigned EU block” in the RIPE database. The closest assigned block to one of the addresses showed up as being assigned to a company in the Netherlands, and the other to a company in Germany (and GeoIP returned the same information using the original IP addresses).
More interesting was the traceroute. The address that GeoIP reported being in Germany routed to Hurricane Electric in Fremont, California; with the last hop before 80.x.x.x being a 64.x.x.x router in Fremont. Could someone in Germany actually be within one hop of a router in Fremont?
After more investigation, we found a google news posting pointing the finger at Windows Update; and particularly to Akamai servers in the 80.x.x.x range. With a bit more coaxing, we were able to get the RIPE database to reveal that some small subnets within the unassigned blocks were actually assigned to Akamai. I knew that Windows Update and many other MSFT sites contract to Akamai for edge-caching services, so this was a very plausible resolution. However, I am left with a few nagging questions:
- Are there any better tools or techniques to find out exactly what chunk of code is accessing the network? Knowing that svchost.exe is initiating the connection is not very useful. More useful would be the exact DLL.
- Akamai works by configuring DNS to resolve differently depending on geographic location (ping download.windowsupdate.com to see this in action). This is a common architecture for our large globally distributed customers’ sites who use routing products like Cisco Global Director and F5 3DNS to accomplish this. However, it leads to a problem — using reverse DNS from an IP addressis rather unlikely to return the same FQDN that was used to resolve the address in the first place. So starting with an IP address like 188.8.131.52, you have no way of finding out if that was initiated by a call to download122.windowsupdate.com or spywareupload22.gator.com. And considering the way that Akamai provides services to spyware vendors as well as to MSFT, you can’t necessarily trust a network connection just because it is connecting to a block owned by Akamai. It would be ideal if Akamai offered an IP address lookup service that could be used to verify which of Akamai customers was being serviced by a particular IP.
Without at least one of the two above requests, the only way to verify that the connections were indeed made on behalf of Windows Update was to bounce the service and watch the connections die (and assume Windows Update DLL hadn’t been hacked of course).
When I first heard that McDonald’s was planning to launch a new ad campaign themed “Lovin’ It”, I immediately got visions of the horribly tacky “Mentos, the Freshmaker!” commercials. I envisioned some German ad agency telling hapless McDonald’s executives, “We know how to make more teens go to McDonald’s; we’ll use some real groovy stuff and say the words Lovin’ It because then kids will think you are cool!” So today I saw one of the new ads for the first time, and it wasn’t all that bad. Actually it was kind of nice. It’s kind of a feel-good, “happy memories of carefree times” theme, kind of like the Pepsi spots a few years back.