Profiling an operating system part II
We left off in part one having seen just what a computer will send back once you sent it a SYN packet. Much as we saw that return packet of a SYN/ACK can be rather revealing. That is assuming that you are able to find an open port on a computer that you are trying to do this to. In the case of the computer in article one, we sent a packet to TCP port 135. Typically, this port would be firewalled off in a corporate environment, or in reality simply closed on the border router.
What we shall now do is carry on with sending some packets to this computer. We will now vary the ones that we send, to see if there is anything else of interest in the response or lack thereof. The two packets we will send shall be an RST and an ACK packet. On that note let's get back to the task at hand.
Sending unexpected stimulus
The whole point of sending the computer, in this case Windows 2000 Professional, some unexpected stimulus is to see how it reacts. Syntax used for Hping in this case is as follows.
Hping -R 192.168.1.105 -p 135 -c 1
The above syntax usage for Hping will send only one RST packet to the TCP port of 135 on the test Windows 2000 Professional box. What did this packet elicit in return? Let's see below.
18:14:44.140625 IP (tos 0x0, ttl 64, id 484, offset 0, flags [none], proto: TCP(6), length: 40) 192.168.1.101.2210 > 192.168.1.105.135: R, cksum 0x5a49 (correct), 1691534017:1691534017(0) win 512
0x0000: 4500 0028 01e4 0000 4006 f4cd c0a8 0165 E..(....@......e
0x0010: c0a8 0169 08a2 0087 64d2 c2c1 6fa7 2f14 ...i....d...o./.
0x0020: 5004 0200 5a49 0000 0000 0000 0000 P...ZI........
Well as we can see my laptop with Hping on it (IP 192.168.1.101) sent the RST packet to 192.168.1.105 on its TCP port 135. There was however no response at all from the Windows 2000 Professional box. In essence the computer simply ignored it. Interesting. So we now know that W2K Pro will simply ignore any RST packets sent to it on a listening service port. Alright then, now that is something to work with. Let's now try and send an ACK packet to a listening port. Syntax used for Hping follows.
Hping -A 192.168.1.105 -p 135 -c 1
We can see from the below noted two packets that the W2K Pro box did indeed respond this time.
18:21:27.906250 IP (tos 0x0, ttl 64, id 24642, offset 0, flags [none], proto: TCP (6), length: 40) 192.168.1.101.1455 > 192.168.1.105.135: ., cksum 0x8a42 (correct), ack 1793737102 win 512
0x0000: 4500 0028 6042 0000 4006 966f c0a8 0165 E..(`B..@..o...e
0x0010: c0a8 0169 05af 0087 20d5 cbef 6aea 418e ...i........j.A.
0x0020: 5010 0200 8a42 0000 0000 0000 0000 P....B........
18:21:27.906250 IP (tos 0x0, ttl 128, id 682, offset 0, flags [none], proto: TCP
(6), length: 40) 192.168.1.105.135 > 192.168.1.101.1455: R, cksum 0xcc9a (correct), 1793737102:1793737102(0) win 0
0x0000: 4500 0028 02aa 0000 8006 b407 c0a8 0169 E..(...........i
0x0010: c0a8 0165 0087 05af 6aea 418e 6aea 418e ...e....j.A.j.A.
0x0020: 5004 0000 cc9a 0000 P.......
Now in the top most packet we see my laptop (IP 192.168.1.101) sending the ACK packet to the W2K Pro box on its TCP port 135. I have underlined the "ack" as well as the "10" seeing as this hex value represents the ACK flag being set in the TCP header flags field. In the packet directly above us we see the W2K Pro box respond to the ACK packet that was sent to it. In this case it sends back an RST packet. Not a RST/ACK but simply an RST. In other words it is resetting (RST) the connection, killing it if you will. Not that it was set up in the first place via a proper TCP three way handshake, but an RST was issued none the less. That is how the W2K Pro boxes TCP/IP stack was configured to work.
This simple RST is another nugget of info to tuck away as it helps us in profiling a W2K Pro box. You will also notice that I underlined the "win 0" portion. This indicates that the W2K Pro is telling the other computer (my laptop) not to send any information as it has a 0 byte size for its receive buffer aka: win size. So it is good to know also that the W2K Pro TCP/IP stack behaves as it should. Again, this is another nugget of info to tuck away.
On to Windows XP Pro
So we have thus far been able to get some results for W2K Pro and how it reacts to an SYN, RST and an ACK packet sent to a listening service. What we will now do is the send the same set of packets to a Windows XP Pro box. The goal of doing this is to see if the TCP/IP stack of XP Pro behaves any differently than that of the W2K Pro one. If it does that will be a helpful way to differentiate between W2K Pro and XP Pro.
In the interests of brevity I will not include the packets sent and received from my laptop and XP Pro box. Suffice it to say that the XP Pro box acted in exactly the same way as the W2K Pro one. To whit, it responded with an SYN/ACK to the SYN, ignored the RST packet sent to it, and sent an RST when it received an ACK. So there was no difference at all between the W2K Pro and the XP Pro TCP/IP stacks responses that would help us differentiate between the two using this set of testing criteria.
What we have so far is a pretty good indication that we are dealing with two Windows boxes due to the ttl of 128. The win size was not helpful as it did conform to previously noted norms as seen in the hyperlink I provided in part one. Though I don't know it definitively, the large win size is likely due to the fact that both boxes are on the same network segment. Without Googling for a while I simply set up a quick test scenario. I sent an SYN packet to my website (www.bridonsecurity.com) on port 80. The website responded back with a win size of 5840. Now that makes a lot more sense and falls into line with what we know of Windows. My website is hosted by a company on an external network.
I will now break off the article at this point and pick up in part three with sending the same test criteria to Windows 2003 Standard to see how it responds. Following that we will look at profiling host information via nbtstat. Though many people have heard of it, there are still quite a few in the dark about what information it can provide and how it does it. That will be covered in part three. See you then!
If you would like to read the other parts in this article series please go to:
- Profiling an Operating System (Part 1)
- Profiling an Operating System (Part 3)
- Profiling an Operating System (Part 4)