DNS Changer Update
As of Friday morning (August 10, 2012), the IP address blocks used by the DNS Changer – Rove Digital criminal operations have been re-allocated by RIPE-NCC and advertised to the Internet:
As a reminder, the Rove Digital/DNS Changer Crew used the following IP address blocks for their nefarious activities:
From November 9th, 2011 until July 9th, 2012, the DNS Changer Working Group with the FBI hosted clean DNS servers to help victims clean up their systems. On July 9th, 2012, these servers were shut down and the IP blocks were removed from the global routing table.
It was assumed that these blocks would remain in limbo until all the court proceedings were completed. The “assumption” was not correct. Alarms that many service providers and security professionals put in place to watch for miscreant “hijacking” of these IP address block were triggered early on Friday. What was a surprise was that these blocks were not “hijacked,” but re-allocated.
126.96.36.199/20 was previously Promnet Ltd but has now been reallocated to INEVO-NET (see http://bgp.he.net/AS56831)
188.8.131.52/21 was was previously Promnet Ltd but has now been reallocated to LT-HOSTING
Of course this could be a false alarm. When you take the existing INEVO-Net block and look for miscreant activities, we find the following:
- Google Safe Browsing Check for AS56831
- ZeuS Tracker :: AS56831 (INEVO Inevo Labs SRL)
- SpyEye Tracker :: AS56831 (INEVO Inevo Labs SRL)
While not a detailed analysis of AS 56831’s cleanliness, the quick check calms some fears. Still until all the details are in, operators should treat the network with suspicion.
Why is this a problem?
DNS Changer was not the only malicious activities inside these Netfblocks. Who ever controls these netblocks can hijack computers that are still infected with DNS Changer and other malware. The way these netblocks are reallocated and surprise at the speed of the reallocation exacerbates the concern. This move by RIPE surprised many in the security industry, law enforcement, and participants of the DCWG. Given the surprise, network operators should be very cautious with any traffic to/from these netblocks.
What should you do to protect your network and your customers?
First, monitor traffic to and from these netblocks. If you do not have the resources, then consider filtering all traffic to and from these netblocks until you receive the all clear.
How would you filter
- Access – List on your gateway router is perhaps the quickest and most effective way to block traffic.
- “Default Free” Multi-homed Networks can filter incoming prefixes so that traffic from your network cannot reach these netblocks.
- Multi-homed Networks can insert a black hole BGP prefix to insure traffic from your network cannot reach these netblocks.
- The Emerging Threat Open Source Firewall filters still work: http://doc.emergingthreats.net/bin/view/Main/WebSearch?search=DNSChanger
- DNS Resolvers can be set up to block DNS request going to these netblocks. ISC has a Knowledge Bulletin (KB) to explain how to use BIND to create a DNS Firewall: https://kb.isc.org/article/AA-00525/0/Building-DNS-Firewalls-with-Response-Policy-Zones-RPZ.html
- Check with your Firewall vendor. They might have a filter reach to load.
Complements and Kudos to my peers in several security groups who had the alarms set up and watching for any chances to the DNS Changer netblocks. It is hard to hide on the Internet. 🙂
Need Security Advice?
If you find your organization needs help and worry about the FUD from the industry, reach out and ask for help. You can reach me at email@example.com. Start with the Operator’s Security Toolkit. It is the no-nonsense security for all Operators. It provides details to help them build more security resilient networks. In the meantime, stay connected to the Senki Community to get updates on new empowerment and security insights.