LNCS 2820 - Ambiguity Resolution via Passive OS Fingerprinting

More documents

Recommendations

Info

Ambiguity Resolution via Passive OS Fingerprinting 193 That is, how can the IDS gain more detailed information about the end host in a passive environment? The ambiguity of the Internet Protocol[16] with respect to fragmentation leads to numerous problems. The most serious of these is to accurately determine exactly what a given end host would see in the presence of overlapping fragments, to properly detect network intrusions, when, and only when they actually happen. Implementations of the Transmission Control Protocol[17] also vary with respect to handling TCP segments with overlapping TCP data. The specfication states that segments should be trimmed to only contain new data, but in practice, network stacks handle this condition in different ways. These two problems present two common exploitable conditions for current IDS sensors. We attempt to minimize these opportunities for attackers with the approach described in this paper. The rest of the paper is organized as follows: Section 2 looks at related work and research in this area. Section 3 looks at existing, state-of-the-art fingerprinting technology. In Section 4, we describe how we build the fingerprint databases and show new techniques for accurately identifying host operating systems. Section 5 shows our current implementation and 6 expands on the resource consumption of our implementation, including methods to reduce it. Our results and measurements are presented in Section 7 and other areas of possible research and future work are described in Section 8. 2 Related Work 2.1 Active Mapping Inspiration for this work is drawn mainly from the research done on Active Mapping[1]. This method relies on a separate system, the Mapper, to actively map hosts within a network to determine its ambiguity resolution policies. That is, how does a host interpret ambiguous packets. The Mapper builds a Host Profile Table by sending different combinations of overlapping, fragmented IP packets and overlapping TCP segments. It then feeds that host profile information, or ambiguity resolution policies, to an IDS sensor. When the IDS detects an ambiguity on the wire, it looks up the IP in the Host Profile Table for instruction on how to resolve it. Unfortunately, there are drawbacks to this type of setup for many network installations. By definition, Active Mapping requires that the mapper actively send out anomalous traffic that may be rejected by firewalls or routers within the network. Clients that are dynamically assigned IP addresses via DHCP would fail to be mapped properly, and could potentially be mapped to a different profile of another machine. These handcrafted packets could also potentially harm hosts on a network.
194 G. Taleck 2.2 Traffic Normalization Traffic normalization[5] solves the problem of ambiguity by mostly (or completely) eliminating it. A traffic normalizer acts as a gateway for all ingress, and possibly egress, traffic and removes any ambiguities when it detects them. However, traffic normalization cannot always scale to large networks because of the process overhead per packet, and can also break connectivity between hosts when they rely on un-normalized traffic. Normalizers must also be extremely fault tolerant, as any traffic that is to enter the network must first pass the normalizer. 2.3 nmap, queso, ettercap, p0f, prelude-ids Active and passive OS fingerprinting tools have been around for quite some time. These tools identify hosts by taking advantage of subtle variations in network stack implementations. Mainly ICMP and TCP packets are used to remotely deduce operating system type. Fyodor’s nmap[7] tool, first released in 1997, makes extensive use of variations in reply packets from hosts when sent invalid, unusual, or non-conforming payloads, as does queso[12]. The p0f [13] tool uses the unique variations of TCP SYN Segments to passively identify hosts on a network. Similarly, ettercap [14], a multi-purpose network sniffer, attempts to identify hosts in the same fashion as p0f. Recently, a patch was submitted to the Prelude IDS Development [15] (prelude-devel) mailing list that can extract pertinent fingerprint information from a TCP SYN or SYNACK segment and save it to a database in the ettercap signature style. This allows Prelude-IDS users the ability to attempt to identify either an attacker’s or victim’s host operating system. These tools implement valuable approaches to identifying hosts on a network that have not yet been widely integrated into available IDS solutions. However, the information they provide can only be used to forensically investigate an attack. In other words, these approaches collect data from TCP SYN/SYNACK segments that can then be used later to assess the host. 3 OS Fingerprinting Two methods exist for remotely fingerprinting hosts on a network: active and passive. 3.1 Active Fingerprinting Active fingerprinting requires one to send interesting, malformed, and unique payloads to a remote host and examine the values returned by the host. Both the nmap and queso tools do this. The common tests send special combinations of TCP flags, such as FIN—PSH—URG, with a NULL TCP payload to both open and closed ports on the host.
Page 1: Ambiguity Resolution via Passive OS
Page 5 and 6: 196 G. Taleck IDS Client Server SYN
Page 7 and 8: 198 G. Taleck Minimal FTP Client FT
Page 9 and 10: 200 G. Taleck Table 2. Encoding of
Page 11 and 12: 202 G. Taleck that failed (either t
Page 13 and 14: 204 G. Taleck The “freshness” o
Page 15: 206 G. Taleck 7. Fyodor: Remote OS

LNCS 2820 - Ambiguity Resolution via Passive OS Fingerprinting

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?