Passive Network Analysis P2

This has some advantages over active scanning solutions. Passive techniques introduce zero traffic on the monitored network, which can be important in high-availability situations, or where the network is not resilient enough to handle large volumes of scanning traffic. Passive techniques do not generate IDS alerts or log entries in the hosts and servers on the monitored network, reducing the overall analytical burden. In some circumstances, passive techniques can actually identify the presence of firewalls, routers, and switches performing NAT, and potentially characterize the hosts behind them.

In spite of all the advantages associated with the technique, there are limitations as well. Passive analysis always requires the ability to insert a sensor somewhere in the monitored network, either in hardware or software. Sensors also have to be placed in a topological location that allows them to see the traffic of interest, a non-trivial task in modern switched enterprises. Finally, the toolkit for passive analysis is much less mature than traditional active techniques, forcing a higher level of effort on the analyst during sensor deployment, data fusion, and analysis.

To better explain, let's examine a sample capture using Ethereal [6]. You can accomplish the same thing using tcpdump, provided you know how to write good BPF expressions (Berkley Packet Filters). Ethereal provides a lot of tools to save time for the lazy man, including a more rich filtering language and the ability to rapidly sort collected packets on pretty much any data field. Of course, before we start collecting traffic and writing filter code, it's useful to have an idea of what we're looking for – specifically, services running inside our network. Fortunately, there are a couple of rules of thumb that make this a bit easier. First, most services are associated with an assigned port number. These "standard" ports are assigned by the IANA (Internet Assigned Numbers Authority) [7] and are incorporated in the RFCs for standard TCP/IP services and protocols. Less common or malicious source ports can be researched using the Internet Storm Center [8] provided by the SANS Institute [9]. Both also provide excellent reading material on network analysis in general, as well as a snapshot of what other network defenders are seeing on their networks.

Another rule of thumb in analyzing traffic helps us differentiate clients from servers. Generally speaking, servers issue packets on the port number associated with the service. So to find a Web server, you look for TCP Source Port 80 emanating from inside your network. To demonstrate this, I captured some traffic off my home network using Ethereal and sorted it based on TCP Source Port. Sure enough, TCP 80 was there, and when I validated it using simple banner grabbing, the service on 192.168.254.2 was in fact a Web server. Note that our sensor did not have to initiate traffic in order to make this deduction – the data was sniffed off the wire; I could have accomplished the same thing with nmap, but that would have required the introduction of traffic on the network. One other note of caution – not all TCP protocols obey this rule of thumb, so study your copy of TCP/IP Illustrated!

Figure 2 – Capture of Web Sessions Using Ethereal