10.03.2014 Views

LNCS 2820 - Ambiguity Resolution via Passive OS Fingerprinting

LNCS 2820 - Ambiguity Resolution via Passive OS Fingerprinting

LNCS 2820 - Ambiguity Resolution via Passive OS Fingerprinting

SHOW MORE
SHOW LESS

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

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

204 G. Taleck<br />

The “freshness” of the fingerprint database existing on the IDS is also another<br />

potential source of failure. While we do actively maintain our internal<br />

fingerprint database as described in Section 4, our current solution does not automatically<br />

fetch the latest copy on its own. We rely on the IDS administrators<br />

to occasionally refresh the packages .<br />

7.2 Implications<br />

Because there does not exist a one-to-one mapping of operating system ambiguity<br />

resolution to TCP SYN/SYNACK negotiation behavior, this solution is prone<br />

to resolving ambiguities incorrectly. For example, a false negative would result if<br />

an administrator changes the default TCP behavior of his or her Windows 2000<br />

server to match that of FreeBSD 5.0, which is then hit with an ambiguity attack<br />

for Windows 2000. Since the IDS identified the server as FreeBSD, which has<br />

a different ambiguity resolution policy than Windows 2000, the attack would<br />

be missed by the IDS. Similarly, false positives can also be generated in this<br />

scenario if the attacking IP fragments or TCP segments formatted for FreeBSD.<br />

However, note that an attacker is not able to change the IDS’s view of a<br />

server the IDS is trying to protect. They will only be able to change the identity<br />

of the system from they are connecting.<br />

7.3 Comparison to Related Work<br />

8 Future Work<br />

The approach described in this paper can be extended in many other directions,<br />

both to increase the accuracy of identifying end host network stacks and in<br />

resolving protocol ambiguities.<br />

Current passive <strong>OS</strong> fingerprinting works only with the IP and TCP headers,<br />

and even then not to their full extent. Research [21] has shown how web<br />

servers operate differently under congestion. The tcpanoly[20] tool uses many<br />

passive methods that could be integrated into the detection engine by noting<br />

gratuitous ACKing, Reno implementations, and other variations throughout a<br />

TCP conversation.<br />

The sensor has the ability to use temporal knowledge of a particular IPs<br />

passively detected <strong>OS</strong> fingerprint to statistically guess the <strong>OS</strong> type in a NATed<br />

environment.<br />

<strong>Passive</strong> fingerprinting can also be used to detect NATed hosts. Since NAT<br />

typically only rewrites IP addresses, and possibly TCP or UDP ports, and leaves<br />

other fields and options unscathed, the IDS can identify a NAT by counting the<br />

number of unique fingerprints for the same IP. If a fingerprint radically changes<br />

repeatedly in a given amount of time, a NAT can be detected and used more<br />

intelligently by the engine.<br />

We can increase the confidence level of SYNACK fingerprint lookups by<br />

paying closer attention when we cache values. When a SYNACK is cached, its

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!