Two weeks ago I was fortunate enough to attend Cisco Live (previously networkers).
Part of my goal there was to get clued up on IPv6 transition methods, addressing and all related matter. One of the breakout sessions I attended was on IPv6 security threats and mitigation. All in all very informative, but the major advice for networks not currently running IPv6 was to monitor your IPv6 flows to see what applications and operating systems were doing. Technologies like ISATAP are bound to break security boundaries by tunneling via IPv4 and this is something you should be aware of on your network.
Today I started this quest just by running a regular wireshark session filtering via IPv6. Without a tap or a port span I could only observe multicast traffic, but I picked up on the below packets.
My immediate thought was a users PC was infected with a virus that was acting as part of a botnet and that this PC was using IPv6 to perform its DNS lookups. I went searching for 10 character IPv6 DNS lookups. Luckily what I found meant it wasn’t part of a botnet but I definitely wasn’t expecting what I found. This case has been documented before, so this is definitely nothing new and the fact that this happens in both IPv4 and IPv6 isn’t a suprise. Here are the references I found:
As the reports suggest it’s a feature of Chrome to perform fake DNS lookups to determine if your ISP is performing DNS hijacking. In my case our DNS suffix provided by our DHCP server did not get appended, nor was the request a truncation of a proper URL nor was it over IPv4 – but it is most definitely the cause of the events I saw on the network.
As the quest for IPv6 and related security problems goes on I’m sure to throw more stuff up here.