When analyzing network traffic it’s typically not as important to look at the contents of the packets; rather the information about them, where they are going and how they got there. This “network metadata” (often referred to as NetFlow data) can reveal interesting information about your network and often uncover misconfigurations, policy abuses and security incidents. I relate it to the movie "The Matrix". In the movie there is a scene where the characters are looking at computer screens displaying “the matrix”. Those who are not accustomed to looking at the matrix will not see "The Blonde" or the "Brunette", but will just see a bunch of green characters.
Fortunately, there are tools available to network security analysts that help decipher the vast amount of network metadata. The Tenable Network Monitor (TNM) is a small process that works with the Log Correlation Engine (LCE) and runs on a system that is connected to a network span port. It listens to all the traffic seen on the network interface and reports on the connections. Typically the network interface is connected to a SPAN port on the switch, allowing it to see more than just its own traffic.
Tenable LCE customers can install TNM on any supported Operating System: Red Hat, Debian, and FreeBSD. Once installed you can use the “interface” directive in the TNM configuration file ("/opt/network_monitor/tnm.conf") to select the appropriate network interface:
| interface "eth1"; |
TNM also needs to know which LCE server to send the data to, in addition to a shared secret to use for encrypting the data in transit:
| lce-server 10.10.10.20 { client-auth auth-secret-key "areallylongrandomstring"; } |
Finally you can specify the networks to include or exclude from monitoring:
| include-networks { "192.168.0.0/16"; "10.0.0.0/8"; "127.0.0.1"; } exclude-networks { |
Once TNM has been configured, it will send the network traffic information to LCE, and LCE reports it to Tenable’s Security Center console. For example, one of the reports built-in to Security Center is an alert that identifies TCP sessions that have carried more than 1 gigabyte of traffic. A traffic pattern at a Tenable research site was identified by TNM as shown below:
The entries themselves represent a TCP connection between the internal host (10.200.80.54) and a host on the Internet (207.176.6.65) over port 80 that transferred more than 1 GB in a single session.
| Detailed Flow Information
TNM provides information about each "flow", or TCP/IP conversation between two hosts. The fields in the log entries above are represented as follows: Date/Time of event: Thur Sep 24 09:56:56 |
Typically, web browsing traffic would not generate this amount of traffic. A typical HTTP transaction is short and transfers much less than 1 GB of data, especially with HTTP 1.1. In addition, even if a large file was being downloaded, chances are it would not be a gigabyte or more; files of that size are usually distributed via a Peer-To-Peer networking protocol, such as BitTorrent. To gather more information about this traffic, further research was done to identify the host 207.176.6.65. A simple DNS reverse lookup did not return anything very interesting about this IP address:
| Non-authoritative answer: 65.6.176.207.in-addr.arpa name = 207-176-6-65.static.pccwglobal.net. |
One of the sites, www.puritan.com, sells a variety of herbal and vitamin supplements. Transferring over 1 gigabyte of traffic from this site seemed unlikely, (unless you were really into B-12 and Acidophilus). The other site was a bit more interesting. Browsing to "free103.http-tunnel.com/ConnectionTest.htm", displayed the following message:
Connection test succeeded, HTTP-Tunnel should work fine
Interesting! It seems that HTTP tunnel is self-explanatory, providing an HTTP tunnel for users to proxy through. This scenario is more likely to be true, if the user was browsing to multiple sites through one connection to a proxy, the download size could easily exceed 1 gigabyte. Searching for the homepage of the makers of this HTTP tunnel technology brought the investigation to www.http-tunnel.com, which had the following reasons for using HTTP tunnel posted to their web site:
* Need to bypass any firewall * Need secure internet browsing * Need to use favorite programs with out being monitored by work, school, ISP or gov. * Extra security for online transactions * Encrypt all your Internet traffic * Need play online games * Visit sites that you are previously blocked * Prevent 3rd party monitoring or regulation of your Internet browsing and download * Use your favorite applications previously blocked * Hide your IP address * Make it next to impossible for you to identify online * Free unlimited data transfer * Compatible with most major Internet applications * Secure and virus-free servers * 99% uptime * No spam, pop-ups, or banners
It seems that HTTP Tunnel allows you to make an encrypted connection to their proxy server and then the connection to your destination is made by one of their servers where it can be proxied back to you. All the outgoing gateways and traffic monitoring software sees is a single outgoing HTTP connection, which is typically allowed on most networks. However, the end user can proxy several different applications, such as the web browser, Instant Message client and Voice-Over-IP services.
Conclusion
Analyzing the layer 3 information (referred to above as the "network metadata"), identifies interesting patterns in the traffic. TNM, coupled with the LCE and the Security Center, can aid in this process and allows you to easily collect and analyze the data. While much of this process is automated for us, it takes some investigative thinking to uncover what may really be happening on the network. In this case, it takes the form of a policy violation, but proves that analyzing the network traffic patterns, and not just the content, can be a worth while endeavor.
