Nmap Development mailing list archives
Advices request for new fingerprints
From: 赵雷 <zhaolei () gmail com>
Date: Wed, 10 Aug 2005 23:30:48 +0800
Hi there, I am now working on creating next generation of OS detection, one of Nmap-Soc projects. We want to find more fingerprints to add into nmap, thus let nmap provide more granular and accurate results. In the past few days, Fyodor and I made an investigation on the RFCs, other OS detecting tools and suggestions from Michal Zalewski (p0f's author) and found something worth to add. The draft list of these fingerprints is below. We want to hear your advices. If there are any other fingerprints worth to add, if you think some on the list is not worth to add, or if you have any opinion on any fingerprints on the list, please let us know. Any advices from you would be appreciated. Best Regards, Zhao Lei List of fingerprints: 1) Initial TTL 2) IPid Field pattern (two more patterns) 3) TCP SACK Option 4) Results in different combinations/orderings of options probe 5) TCP Window Scale Option *value* 6) ECN Support 7) Data payload in RST+ packet 8) Invalid Second timestamp value 9) Invalid ACK flag, ACK value and SEQ value in RST replies 10) URG pointer value when URG flag not set 11) "Unused" field not zero And also I am now testing 2 other fingerprints to check whether they are worth to add (I hope I'll get a good result in tomorrow morning): - IP options - ICMP echo reply 1) Initial TTL # Description: Time To Live field in IP head. Different OS uses different TTL when creating a IP packet. 2) IPid Field pattern # Description: IP identification field is a bit used to make packets unique for fragment reassembly. Different OS use it in different way. In addition to the patterns that nmap already checks (you can check them at the "IPID sampling" paragraph of Fyodor's article: http://www.insecure.org/nmap/nmap-fingerprinting-article.html), there exist two other patterns according to some articles: o "Some versions of Solaris use separate counters for each <source, destination, protocol> triple." (from "A Technique for Counting NATted Hosts") o "Linux - The host sets the IPID to zero on SYNACK segments, and then uses a per-connection incremental IPID for data packets with a randomized start." (from "syscan") 3) TCP SACK Option # Description: There are many current OSes that implement TCP Selective Acknowledgment Options (RFC2018, RFC2883). It's a nugget in the gold mine. Whether the option is set or not and its position in the all options in the reply packet give much information about the OS. 4) Results in different combinations/orderings of options probe # Description: Use different combinations/orderings of options for each of the probes. Destination hosts may expose differences based on how they pack responses to different option combinations. 5) Window Scale Option *value* # Description: Nmap already uses this option, but doesn't check its value. Since initial WSCALE value is also OS related, we will check its value too. 6) ECN Support # Description: RFC3168 (The Addition of Explicit Congestion Notification (ECN) to IP) defines a mechanism to let the routers have another way (other than drop packets) to notify endpoints about the congestion in the network. To use ECN, transport protocol implementions of endpoints must first exchange information about their willingness to use ECN. For TCP (the only transport protocol this rfc addresses), this is done in TCP connection setup phase using two bits in TCP header. The rfc gives a new definition of bytes 13 and 14 of the TCP Header: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | | | C | E | U | A | P | R | S | F | | Header Length | Reserved | W | C | R | C | S | S | Y | I | | | | R | E | G | K | H | T | N | N | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ CWR: Congestion Window Reduced ECE: ECN-Echo The ECN-setup process for TCP is as following: o A (sender) sends an ECN-setup SYN packet (ECE and CWR flags set) to B (receiver); o B sends an ECN-setup SYN-ACK packet (only the ECE flag set but the CWR flag not set) to A. According to the RFC, "there exists at least one faulty TCP implementation in which TCP receivers set the Reserved field of the TCP header in ACK packets (and hence the SYN-ACK) simply to reflect the Reserved field of the TCP header in the received data packet", and "There exist some middleboxes (firewalls, load balancers, or intrusion detection systems) in the Internet that either drop a TCP SYN packet configured to negotiate ECN, or respond with a RST". Furthermore, since ECN has remained for a long period (nearly 3 years) in Experimental status (RFC2481), some OSes support the specification in RFC2481. One of the differences between the two RFC is that the ECN-setup SYN in RFC2481 only needs to set the ECE flag. And this causes differences too. There are about 7 possible responses to our two ECN-setup SYN packets (only ECE set, both ECE and CWR set) to an open port. And the difference is what we can use in OS detection. 7) Data payload in RST+ packet # Description: "Data past headers on RST/RST+ACK packets is a very valuable source of OS information, particularly for Solaris, MacOS, HP/UX. Those systems reply with a textual description of the reason RST+ACK is being sent in the payload of the packet." (p0f) We will check the payload we get from RST+ packet: if there is payload, the detail of the payload. 8) Invalid Second timestamp value # Description: Check if the second timestamp (the reply one) is set to zero correctly in various responses. "The RFC specifies when the second timestamp should be zero and when not, and most people get confused about it." 9) Invalid ACK flag, ACK value and SEQ value in RST replies # Description: " The RFC says there are two types of RST responses acceptable: Plain RST in response to packets with no ACK flag. SEQ set to the ACK number from the original packet, ACK value unspecified. This is a valid "connection refused" response. The ACK field is zeroed on some systems (like Linux), is not one some others. RST+ACK in response to packets with ACK flag. SEQ must be zero, ACK set to the SEQ number of the original packet plus its size. This is the usual "unexpected traffic" response. Both can be triggered on machines with no open ports. A number of systems, including Windows, FreeBSD and Linux, tends to reply with invalid combinations in certain conditions (some even reply with RST+ACK to packets with ACK set). " Nmap now check flag and ACK value in TCP RST+ packet, but doesn't check SEQ. Since "There is a total of 10 possible combinations of ACK flag, ACK value and SEQ value", it is worthwhile to include this one. 10) URG pointer value when URG flag not set # Description: Check if URG pointer is not zero when URG flag is not set. "Certain boxes, particularly some firewalls, have it set to a fixed value such as 0xcccc (URG), whereas other machines tend to leak memory there (Windows, for example, see my recent BUGTRAQ post)." 11) "Unused" field not zero # Description: Check if any "unused" field. There are two kind of packets in nmap have "unused" field: the "unused" field in ICMP type 3 (we get this when send a UDP packet to a closed port) and the "Reserved" field in TCP. _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev
Current thread:
- Advices request for new fingerprints 赵雷 (Aug 10)