© SANS Institute 2003, Author retains full rights Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 © SANS Institute 2003, As part of the Information Security Reading Room. Author retains full rights. Passive OS fingerprinting: Details and Techniques (Part 2) Purpose The purpose of this paper is to provide a detailed explanation of passive OS fingerprinting. This paper will briefly cover the current techniques for identifying operating systems, and new techniques in identifying operating systems. The beginning Passive OS fingerprinting is the technique in which people look at packets being sent to them and identify the system it came from. This technique is a few years old and several papers have been written about this technique. If your interested in reading up on passive OS fingerprinting before diving into this paper then check out my article on passive OS fingerprinting. Let’s begin by looking at some packets and performing some passive OS fingerprinting: 17:05:30.773757 192.168.1.5.32770 > 192.168.1.55.telnet: S [tcp sum ok] 2598191518:2598191518(0) win 5840 <mss 1460,sackOK,timestamp 26929 0,nop,wscale 0> (DF) (ttl 64, id 10415, len 60)4500 003c 28af 4000 4006 8e80 c0a8 0105c0a8 0137 8002 0017 9add 419e 0000 0000a002 16d0 e7e3 0000 0204 05b4 0402 080a0000 6931 0000 0000 0103 0300 Figure 1: Packet Trace The first field I typically look at when performing passive OS fingerprinting is the total length field in the IP header. In Figure 1, the total length field is shown to have a value of 3c. In case you don’t have a calculator handy, 3c comes out to 60 bytes in decimal. Ok, what does that tell us? For now, it doesn’t really tell us anything other than there are at least two operating systems that have a total length value of 60 bytes. So now we have to begin looking at the TCP options field in the packet. In Figure 1, we see that this operating system sets a couple of options. It sets the Maximum Segment Size value to 1460. It also sets the Selective Acknowledgement “OK flag” as well as the timestamp and wscale options. And finally, it also uses nop’s to pad the value of the options field. If we had more then one packet, we could look at the IP id field in order to help us identify this operating system. But in this case, that field does not help us at all. So, there are only 2 fields that will help us in making this decision. The first field is the Time-to-Live field, in this case our value is 64; our second field in this case is the Window size field and its value is 5840. Ok, lets perform some passive OS fingerprinting math and see what we come up with: TTL = 64 + Window size = 5840 + TCP Options = 1 nop, MSS, Wscale, timestamp and SackOK + Total Length = 60 = Linux 2.4 operating system. New Techniques© SANS Institute 2003, Author retains full rights Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 © SANS Institute 2003, As part of the Information Security Reading Room. Author retains full rights.Passive OS fingerprinting techniques like I have described above have been around for a couple of years and are used by passive OS fingerprinting tools through out our community. This section of this paper will cover other techniques we can use in order to identify operating systems…passively. How many times have you been monitoring TCPdump or something similar and have seen 3-12 SYN’s coming at you and wondered why? The technique I have began using to perform passive OS fingerprinting will help explain why? Red Hat Linux Let’s begin by looking at a Linux machine first. Hopefully, everyone is familiar with the /proc directory. If your not, the /proc directory is pseudo like file system that allows us to view many different areas of /dev/kmem. The area we are mainly interested in when performing passive OS fingerprinting is /proc/sys/net/ipv4. Lets perform an ls –la and see what we come up with (truncated for space): tcp_abort_on_overflowtcp_adv_win_scaletcp_app_wintcp_dsacktcp_ecntcp_facktcp_fin_timeouttcp_keepalive_intvltcp_keepalive_probestcp_keepalive_timetcp_max_orphanstcp_max_syn_backlogtcp_max_tw_bucketstcp_memtcp_orphan_retriestcp_reorderingtcp_retrans_collapsetcp_retries1tcp_retries2tcp_rfc1337tcp_rmemtcp_sacktcp_stdurgtcp_synack_retriestcp_syncookiestcp_syn_retriestcp_timestampstcp_tw_recycletcp_window_scalingtcp_wmem Figure 2: TCP results from the /proc directory Although I have cut a lot of the ls-la results out of the paper, we can see that there are still many interesting results available to us to look at. The one we want to look at for this paper is the tcp_syn_retries. What is tcp_syn_retries? Well, it’s quite simple, tcp_syn_retries is the number© SANS Institute 2003, Author retains full rights Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 Key fingerprint = AF19 FA27 2F94 998D FDB5 DE3D F8B5 06E4 A169 4E46 © SANS Institute 2003, As part of the Information Security Reading Room. Author retains full rights.of times the operating system will try make a session if the first attempts fails. Lets take a look at a Red Hat machine re-attempting to make a connection: 20:58:36.804058 10.10.10.100.1030 > 10.10.10.25.http: S [tcp sum ok] 287415246:287415246(0) win 5840 <mss 1460,sackOK,timestamp 99459477 0,nop,wscale 0> (DF) (ttl 64, id 14939, len 60)0x0000 4500 003c 3a5b 4000 4006 d7d0 0a0a 0a64 E..<:[@[email protected] 0a0a 0a19 0406 0050 1121 9bce 0000 0000 .......P.!......0x0020 a002 16d0 afde 0000 0204 05b4 0402 080a ................0x0030 05ed a195 0000 0000 0103 0300 ............20:58:39.794283 10.10.10.100.1030 > 10.10.10.25.http: S [tcp sum ok] 287415246:287415246(0) win 5840 <mss 1460,sackOK,timestamp 99459777 0,nop,wscale 0> (DF) (ttl 64, id 14940, len 60)0x0000 4500 003c 3a5c 4000 4006 d7cf 0a0a 0a64 E..<:\@[email protected] 0a0a 0a19 0406 0050 1121 9bce 0000 0000 .......P.!......0x0020 a002 16d0 aeb2 0000 0204 05b4 0402 080a ................0x0030 05ed a2c1 0000 0000 0103 0300 ............20:58:45.794266 10.10.10.100.1030 > 10.10.10.25.http: S [tcp sum ok] 287415246:287415246(0) win 5840 <mss 1460,sackOK,timestamp 99460377 0,nop,wscale 0> (DF) (ttl 64, id 14941, len