Using Static Routes to Block Malware and Spyware

Summary

Blocking IP networks associated with spyware and malware through the use of "null routes" have traditionally been limited to corporations with network administrators. This paper describes an additional tool for a home or small business in the fight against spyware, a script which will "null route" IP networks on the local machine.

Download the script here.

Introduction

There are many options to block or limit access to internet sites which have been associated with malware and spyware.

However, no single spyware prevention or detection method is proving to be completely effective, especially in this age of "0-day" exploits, "drive-by" downloads, etc. For example, one of the more recent trends is to "hijack" a domain or "poison" search engine results. A multi-pronged approach to spyware detection and prevention is needed.

One of the more popular techniques for blocking access to sites associated with malware is with DNS redirection

DNS Redirection

A host file or via a local or internal DNS server. can be used to maps hostnames and domains associated with malware to a different IP address (such as a loopback address, 127.0.0.1). This will prevent connections to those malicious sites from ever occurring. This will help to neuter existing malware infections as it does not allow them to report home or get new code (and thus saving bandwidth). It will also prevent new spyware installs. A comprehensive list of blocklists can be found here

A host file works with individual hosts (such as www.malwaresite.com). An internal DNS server works with entire domains (such as all of *.malwaresite.com).

However, for a host file to work, there needs to be an exact entry in the hosts file for each host/domain combination. Even within the same domain, there must separate host entry. For example, there must be individual entries for www1.malwaresite.com, www2.malwaresite.com, www3.malwaresite.com, www4.malwaresite.com, etc. A host not listed (such as www5.malwaresite.com) will continue to be resolved, and connect, to the malware-associated site. Major malware players may have dozens of hosts per domain. This causes the host file to become quite large.

Blocking domains through the use of a DNS server is better, as there needs to be a single entry to block an entire domain. However, this solution isn't perfect, as all the bad guys need to do is register another domain name and point it to the same server as the original site.

Also, home users and small companies will not be running an internal DNS server, and may not have the resources or ability to block domains on their off-the-shelf firewall appliance or proxy server.

Finally, blocking or limiting access by host and domain will not work when the malware connects via an IP address.

Blocking by IP Address

Another way to block access to a server associated with malware is to block the ip address(es) associated with that server.

The Internet Storm Center recently suggested blocking access to several ip address ranges (netblocks) at the perimeter router or firewall. This is because of the large number of exploits and malware originating from servers within that netblock.

Despite concerns and reservations about blocking entire ip ranges, SANS recommended this is because the large amount of malware associated with those netblocks, and the concern that exploits (such as WMF) may be undetectable by antivirus software and Intrusion Detection Systems until patches and updates are created

IP ranges can be blocked at the perimeter router or firewall.

A range can be blocked on a router through an access list or a "Null Route". A null route is usually perferred because it takes less resources to route a network range than to examine every packet and determine if it should be blocked. The usual convention for blocking a netblock is to route it to nowhere (ie "Null"). For example, the statement "route add a.b.c.d mask 255.255.255.255 NULL would route all packets destinated for address a.b.c.d to a "NULL" interface, ie, nowhere.

Blocking by IP Address: Home Users

However, blocking or limiting access by netblock at the perimeter may not be feasible for home users and small companies. (And home computers are at "high risk" for getting infected due to inadequate patching, and multiple household members sharing a single computer.)

While there are several personal firewalls and applications which can block based on IP addresses, this solution requires the user to install third-party software. Users may disable the software if they deem it "too annoying". Null routing a network requires no additional software and should take a minimal amount of computer resources (basically a routing table entry).

I wanted to find a way to create a script which would "null route" netblocks easily on a local desktop. Unfortunately, on Windows, one cannot seem to route to a null or loopback interface. The only way I can think of adding the equivalent of a null route to a windows box is to add a route pointing back to the machine's local IP address (I don't think this isn't as bad as it first sounds, as that's what local hostfile and domain blocklists do, except they use a loopback interface, 127.0.0.1).

Most end-users do not know their ip address as it is automatically set by an external device (such as a DHCP server, home firewall, or ISP). An even smaller percentage are familiar with the concept of routes and default gateways. (And in corporations, that is preferred!). Therefore, I researched a way to automate this process.

I found a small script called getip.cmd which returns the IP address of a computer's network interface. "Route" commands corresponding to the networks suggested by the Internet Storm Center to be blocked were added, pointing back to the network interface associated with the IP address returned by that getip.cmd script.

The modified script is located here.

Once those routes are added, all traffic to those networks is effectively blocked, as it is "routed" back to the local machine.

Running the Script

Download the script here.

Either double-click on the script or open a DOS prompt and run it manually.

Once the script is downloaded and run on a local machine, any packets which are destined for the IP ranges being "null routed" will simply not leave the local machine. It doesn't matter if the computer is attempting to connect through an ip address or hostname. You can view your routing table by issuing this command from DOS:

The following is the output of that command from a sample machine: In this case, my ip address is 10.1.23.17. All packets NOT on my local network are sent to the default gateway, 10.1.16.1.

In this case, my ip address is 10.1.23.17. All packets NOT on my local network are sent to the default gateway, 10.1.16.1.

The following is the output of that command AFTER I run the script:

Two more lines were added, for the netblocks 69.50.160.0 (which actually includes all ip adresses from 69.50.160.0 to xxxxxx) and 85.255.112.0 (which actually includes all ip addresses from 85.255.112.0 to xxxxxxx. Any packets or requests destined for that ip

Any packets attempted to get to an ip address in that network range will NOT go out the default gateway. Instead it will get routed "back" to 10.1.23.17 and never leave my machine.

I believe this script would be useful for home users, especially one which is shared among many members of the household. Machines with users who are more likely to visit sites which have a higher likelihood of harboring malware (P2P, music, etc) would also benefit.

Next Steps

This script needs to be tested on a dial up connection.

Script won't work on a machine in which the user doesn't have administrative privileges, which is probably a good thing.

Need to find a way to automate updates of ip ranges.

Notes