When you receive external reports (e.g.: from myNetWatchman) identifying malicious activity being emitted by your firewall or NAT IP address it can be extremely difficult to identify the internal host that is generating it. This is especially true when the malicious activity is occuring on a destination port associated with a popular application. For example, HTTP worm traffic on tcp/80 is often lost in a sea of expected HTTP traffic.
One technique to isolate malicous traffic is to look for outgoing packets to "bogon" destinations IP addresses. Bogons are the subset of IP address space which is unallocated and/or reserved. For example, 0.0.0.0/8 and 1.0.0.0/8 are currently bogon. In fact almost 40% of the total possible address space is bogon. Many pieces of malware chose at least some of their target IP addresses randomly, therefore, they will often choose bogon IPs. Since malware often attemp to propagate at rates of tens, hundreds, or even thousands of IPs per second, it doesn't take long to identify a pattern of bogon targetting.
Be advised, not all bogon flows are malicious. Peer to peer fire-sharing applications (P2P) will often generate bogon flows as they do a poor job of detecting peer endpoints that are behind NAT or firewalls. Additionally, if someone incorrectly defines the authoritative DNS server for a domain as a bogon IP and your DNS server attempts to do a lookup, you'll generate a bogon flow. Lastly, all private addresses are a subset of bogons (e.g. 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16). I have purposesly removed these networks from the bogon lists used below as you may expect one or more of these to be used on your own network. If you want a more accurate bogon list you may want to selectively add these back in. I have also removed the "Autoconfigure" network 169.254.0.0/16 as it is very common for Windows PCs which fail to obtain an IP address via DHCP to begin generating broadcasts to this network (e.g. Netbios broadcasts) and that certainly isn't any indication of malicious activity.
Connect a packet analyzer, such as Ethereal or tcpdump on the internal network (e.g.: where traffic can be monitored prior to any address translation). Start a packet capture and specify a capture filter including current bogon networks:
(dst net 0 or dst net 1 or dst net 2 or dst net 5 or dst net 7 or dst net 23 or dst net 27 or dst net 31 or dst net 36 or dst net 37 or dst net 39 or dst net 42 or dst net 49 or dst net 50 or dst net 77 or dst net 78 or dst net 79 or dst net 89 or dst net 90 or dst net 91 or dst net 92 or dst net 93 or dst net 94 or dst net 95 or dst net 96 or dst net 97 or dst net 98 or dst net 99 or dst net 100 or dst net 101 or dst net 102 or dst net 103 or dst net 104 or dst net 105 or dst net 106 or dst net 107 or dst net 108 or dst net 109 or dst net 110 or dst net 111 or dst net 112 or dst net 113 or dst net 114 or dst net 115 or dst net 116 or dst net 117 or dst net 118 or dst net 119 or dst net 120 or dst net 121 or dst net 122 or dst net 123 or dst net 127 or dst net 173 or dst net 174 or dst net 175 or dst net 176 or dst net 177 or dst net 178 or dst net 179 or dst net 180 or dst net 181 or dst net 182 or dst net 183 or dst net 184 or dst net 185 or dst net 186 or dst net 187 or dst net 197)
The above will capture ALL bogon traffic. If you only care about bogon traffic to a specific destination port, then add a port filter after the closing parenthesis:
...) and dst port 80
Note: Above bogons are accurate as of 2005-06-22...please verify current bogon list at Cymru Bogon list
In cases where it is technically difficult to monitor traffic with a packet analyzer, utilizing Netflow data from supported network infrastructure hardware (e.g. routers and switches) may be an easier to implement. Netflow initially was a Cisco-centric feature, but now many third-party network equipment manufactures support some form of it (e.g. Juniper). For a list of supported Cisco devices and some detailed background on Netflow, see: Cisco Netflow Compatibility Matrix. However, even if you don't have equipment that natively supports Netflow, you can generate your own Netflow through the use of inexpensive hardware and/or software Netflow probes (see: nBox and nProbe, respectively.)
Once you have a source of Netflow data, you need a server running a Netflow collector to archive and analyze flow data. The flow-tools provides a collector (flow-capture) and a variety of tools to analyze, filter and produce flow report.
The following documents how to do bogon analyze using Netflow data collected by flow-tools. First create a text file called 'bogon.flt' describing the current bogon networks, as follows:
# more bogon.flt
filter-definition bogondst
match ip-destination-address bogon
filter-primitive bogon
type ip-address-prefix
permit 0.0.0.0/8
permit 1.0.0.0/8
permit 2.0.0.0/8
permit 5.0.0.0/8
permit 7.0.0.0/8
permit 23.0.0.0/8
permit 27.0.0.0/8
permit 31.0.0.0/8
permit 36.0.0.0/8
permit 37.0.0.0/8
permit 39.0.0.0/8
permit 42.0.0.0/8
permit 49.0.0.0/8
permit 50.0.0.0/8
permit 77.0.0.0/8
permit 78.0.0.0/8
permit 79.0.0.0/8
permit 89.0.0.0/8
permit 90.0.0.0/8
permit 91.0.0.0/8
permit 92.0.0.0/8
permit 93.0.0.0/8
permit 94.0.0.0/8
permit 95.0.0.0/8
permit 96.0.0.0/8
permit 97.0.0.0/8
permit 98.0.0.0/8
permit 99.0.0.0/8
permit 100.0.0.0/8
permit 101.0.0.0/8
permit 102.0.0.0/8
permit 103.0.0.0/8
permit 104.0.0.0/8
permit 105.0.0.0/8
permit 106.0.0.0/8
permit 107.0.0.0/8
permit 108.0.0.0/8
permit 109.0.0.0/8
permit 110.0.0.0/8
permit 111.0.0.0/8
permit 112.0.0.0/8
permit 113.0.0.0/8
permit 114.0.0.0/8
permit 115.0.0.0/8
permit 116.0.0.0/8
permit 117.0.0.0/8
permit 118.0.0.0/8
permit 119.0.0.0/8
permit 120.0.0.0/8
permit 121.0.0.0/8
permit 122.0.0.0/8
permit 123.0.0.0/8
permit 127.0.0.0/8
permit 173.0.0.0/8
permit 174.0.0.0/8
permit 175.0.0.0/8
permit 176.0.0.0/8
permit 177.0.0.0/8
permit 178.0.0.0/8
permit 179.0.0.0/8
permit 180.0.0.0/8
permit 181.0.0.0/8
permit 182.0.0.0/8
permit 183.0.0.0/8
permit 184.0.0.0/8
permit 185.0.0.0/8
permit 186.0.0.0/8
permit 187.0.0.0/8
permit 192.0.2.0/24
permit 197.0.0.0/8
permit 198.18.0.0/15
permit 223.0.0.0/8
Next, create a shell script to pull bogon flow data from the main flow archive files to a seperate file:
# more flowfiltbogon.sh
flow-cat /var/netflow/2005/2005-06/2005-06-09/* | flow-nfilter -fbogon.flt -Fbogondst > bogon2005-06-09.dat
Now run the shell script and dump the contents of the bogon flows:
# sh flowfiltbogon.sh # flow-cat bogon2005-06-09.dat | flow-print | more srcIP dstIP prot srcPort dstPort octets packets 66.110.x.x 98.108.205.152 17 3491 1434 404 1 66.110.x.x 98.117.101.245 17 3491 1434 404 1 66.110.x.x 186.221.230.159 17 3491 1434 404 1 66.110.x.x 94.3.118.244 17 3491 1434 404 1 66.110.x.x 178.24.192.243 17 3491 1434 404 1 66.110.x.x 190.150.130.123 17 3491 1434 404 1 66.110.x.x 122.91.9.77 17 3491 1434 404 1 66.110.x.x 106.150.34.220 17 3491 1434 404 1 66.110.x.x 50.106.207.23 17 3491 1434 404 1 66.110.x.x 118.13.158.238 17 3491 1434 404 1 66.110.x.x 110.86.92.72 17 3491 1434 404 1 66.110.x.x 98.78.142.223 17 3491 1434 404 1 66.110.x.x 186.126.126.15 17 3491 1434 404 1 66.110.x.x 94.48.156.58 17 3491 1434 404 1 66.110.x.x 182.33.55.23 17 3491 1434 404 1 66.110.x.x 174.12.248.20 17 3491 1434 404 1 66.110.x.x 102.15.85.100 17 3491 1434 404 1 66.110.x.x 42.43.107.33 17 3491 1434 404 1 66.110.x.x 50.51.199.138 17 3491 1434 404 1 66.110.x.x 118.66.158.39 17 3491 1434 404 1 66.110.x.x 110.51.230.138 17 3491 1434 404 1 66.110.x.x 98.39.42.133 17 3491 1434 404 1 66.110.x.x 122.39.156.127 17 3491 1434 404 1 66.110.x.x 106.223.44.108 17 3491 1434 404 1 66.110.x.x 2.216.220.119 17 3491 1434 404 1 66.110.x.x 90.85.170.107 17 3491 1434 404 1 66.110.x.x 78.41.220.131 17 3491 1434 404 1 66.110.x.x 114.125.111.243 17 3491 1434 404 1 66.110.x.x 74.166.71.33 17 3491 1434 404 1 66.110.x.x 182.199.76.145 17 3491 1434 404 1
The above bogon flows identify an obviously Slammer infected host 66.110.x.x (IP masked for privacy).. note the outbound udp/1434 activity to bogon destination networks.
You should be particularly concerned with flows to contrived looking bogon destinations, for example:
srcIP dstIP prot srcPort dstPort octets packets 66.216.x.x 1.1.1.1 6 32610 44444 5904 123 66.216.x.x 1.1.1.1 6 34118 44444 5904 123
The above flow likely identifies attempted command and control traffic from and infected bot to a domain name that has been suspended by the DNS hosting provider....it is common practice to repoint such abusive domains to a private or bogon IP rather than to not resolve it at all, for example:
> update.dhcp.biz Name: update.dhcp.biz Address: 1.1.1.1
In the above example, 66.216.x.x is likely infected with an trojan trying to call home...though the command and control has been disabled, the system is nevertheless infected and secondary command and control channels may still be functional.