dnschanger



Introduction

This page outlines a proof of concept method for a network administrator to turn up a DNSchanger proxy DNS server.  The goal of this server is to keep DNSchanger victims from going off-line when the FBI shuts down the ISC servers on July 9th 2012.  Implementing such a stand-in server may not be a good idea for various reasons, but if keeping infected host online until they can be fixed is a priority, you may need such a stand-in server.

This solution is just a proof of concept (POC).  It is NOT guaranteed to work, work at scale, or be optimal for any environment.  And, it is likely best to let infected host go off-line on July 9th so that they can be properly fixed.

This POC is not meant for novices (it is not step by step), and it is not for experts (they probably have a better way of doing it).  This POC is just one person's findings.

NOTE: I added an iptables destination NAT as an alternate solution

POC Description

  • This POC only uses free software, including:
  • The server is provisioned with the 18,000+ IPv4 addresses associated with DNSchanger.  The ranges are provided in this FBI document :
    • 85.255.112.0 -- 85.255.127.255 
    • 67.210.0.0 -- 67.210.15.255 
    • 93.188.160.0 -- 93.188.167.255 
    • 77.67.83.0 -- 77.67.83.255 
    • 213.109.64.0 -- 213.109.79.255 
    • 64.28.176.0 -- 64.28.191.255 
  • The server listens and properly responds to queries from the above address ranges associated with DNSchanger.  This is the same behavior as the FBI operated DNS servers, where the goal is to keep infected hosts online until they can be fixed.
  • The network statically routes the above IP ranges to the server. These routes should not leave your locally administered ASN.
  • If implemented properly, the local network will have local routes to the DNSchanger IP ranges which reside as loopbacks on the Linux server.  The Linux server will receive DNS queries from infected hosts and properly respond to the DNS query, keeping the user online and maintaining the status quo passed July 9th when the FBI servers are shut down. 
  • THIS IS NOT A *SOLUTION* SINCE USERS STILL ARE INFECTED WITH MALWARE. THE SOLUTION IS HAVING THE USERS REPAIR THEIR SYSTEMS.

Setup Steps

  1. Install a fully patched and up-to-date and secure Linux server
    • Many good guides online how to do this
  2. Provision the IPv4 addresses as loopbacks
    • Here is a simple Python script to provision the addresses, it must be run as root and it takes a few minutes to complete.  You can check status with the "ip addr" command

    • Python to provision IPv4 Addresses

      import socket, struct, os, sys
      def setip (start, end):
        startip = struct.unpack('>L',socket.inet_aton(start))[0]
        endip = struct.unpack('>L',socket.inet_aton(end))[0]
        while startip <= endip:
         ipx =  socket.inet_ntoa(struct.pack('>L',startip)) + "/32"
         command = 'ip -4 addr add ' + ipx + ' dev lo' 
         os.system(command) 
         startip +=1

      setip('85.255.112.0', '85.255.127.255')
      setip('67.210.0.0', '67.210.15.255')
      setip('93.188.160.0', '93.188.167.255')
      setip('77.67.83.0', '77.67.83.255')
      setip('213.109.64.0', '213.109.79.255')
      setip('64.28.176.0', '64.28.191.255')
      And then you end up with something like this:

    • ip addr

      1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
          link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
          inet 127.0.0.1/8 scope host lo
          inet 85.255.112.0/32 scope global lo
          inet 85.255.112.1/32 scope global lo
          inet 85.255.112.2/32 scope global lo
          inet 85.255.112.3/32 scope global lo
          inet 85.255.112.4/32 scope global lo
          inet 85.255.112.5/32 scope global lo
          inet 85.255.112.6/32 scope global lo
          inet 85.255.112.7/32 scope global lo
          inet 85.255.112.8/32 scope global lo
          inet 85.255.112.9/32 scope global lo
          inet 85.255.112.10/32 scope global lo
          inet 85.255.112.11/32 scope global lo
          inet 85.255.112.12/32 scope global lo
          inet 85.255.112.13/32 scope global lo
          inet 85.255.112.14/32 scope global lo
          inet 85.255.112.15/32 scope global lo
          inet 85.255.112.16/32 scope global lo
          inet 85.255.112.17/32 scope global lo
          inet 85.255.112.18/32 scope global lo
          inet 85.255.112.19/32 scope global lo

      .....


          inet 93.188.167.92/32 scope global lo
          inet 93.188.167.93/32 scope global lo

      ....

          inet 64.28.191.253/32 scope global lo
          inet 64.28.191.254/32 scope global lo
          inet 64.28.191.255/32 scope global lo
          inet6 ::1/128 scope host 
  3. Route the DNSchanger IP blocks from your network to the server
    • This can be a simple static route for each of the DNSchanger IP blocks listed above with the DNS server as the next hop
  4. Start the Unbound service
    • Here is a sample unbound.conf file:

    • unbound.conf

      username: unbound
      interface: 0.0.0.0        # need this to listen on all loopbacks
      interface-automatic: yes  # need this to answer loopbacks as source
      outgoing-interface: 192.168.0.105  # change me
      access-control: 192.168.0.0/16 allow  # change me
      forward-zone: 
        name: "."
        forward-addr: 8.8.8.8 # forward all queries to trusted destination 
      Be sure to change the forwarding address to something you trust
    • Be sure to restrict the configuration to only allow your customers to connect, you do not want to run an open relay
  5. Verify it works
    • Few quick digs

    • digs to verify your server is working correctly

      dig @67.210.15.99 www.isc.org +short
      dig @85.255.112.9 www.nanog.org +short
      ....



  6. Repeat the above steps in Anycast topology to gain scale
  7. FOLLOW-UP WITH INFECTED HOSTS TO MAKE SURE THEY GET THE HELP THEY NEED

Alternate Solution with iptables

Instead of creating 18,000+ loopback IP addresses to receive queries, it is also possible to add the following iptables rules for destination NAT.  Just like the above solution, you will route the ip addresses to the server and run a forwarding DNS server, but instead of setting up the many loopback addresses you just setup one loopback address and destination NAT the queries to that loopback.
  1. Add a loopback to listen for DNS queries:  sudo ip -4 addr add 192.168.99.99/32 dev lo
  2. Add the following iptable rules to change the destination IP address of the DNS query from the DNSchanger server range to your loopback

iptables rules

iptables -t nat -A PREROUTING -d 85.255.112.0/20 -j DNAT --to-destination 192.168.99.99
iptables -t nat -A PREROUTING -d 67.210.0.0/20 -j DNAT --to-destination 192.168.99.99
iptables -t nat -A PREROUTING -d 93.188.160.0/21 -j DNAT --to-destination 192.168.99.99
iptables -t nat -A PREROUTING -d 77.67.83.0/24 -j DNAT --to-destination 192.168.99.99
iptables -t nat -A PREROUTING -d 213.109.64.0/20  -j DNAT --to-destination 192.168.99.99
iptables -t nat -A PREROUTING -d 64.28.176.0/20  -j DNAT --to-destination 192.168.99.99

More Information

FAQ

Q: Can you do this with BIND?
I tried, but BIND tried to bind to every IPv4 address instead of running something like "0.0.0.0:53" in netstat. I could not get it to work, somebody else probably can.

Q: Do you have to listen on all those address?
I am told thousands of addresses are being used, so yes.

Q: Is this the best way to solve this problem?
Probably not, but it may be a tool worth having around in case you need it

Q: How do infected hosts get fixed?
There is info here http://www.dcwg.org/fix/, i would suggest Windows Defender from Microsoft http://windows.microsoft.com/en-US/windows/what-is-windows-defender-offline


Subscribe to posts