Tools of the Trade revisited (Part 2)

by Don Parker [Published on 18 Oct. 2006 / Last Updated on 18 Oct. 2006]

The first part of this article series looked at how an IDS could possibly detect certain security tools. Covered was a packet sniffer and network scanner. This article continues with the analysis.

If you missed the other articles please read:

We left off in part one having generated a series of packets via the network scanner nmap. This network scanner in turn triggered certain alerts as noted in the “alert.ids” file in Snort’s log directory. That was the result of scanning the ports on the computer which we had Snort running on. So we now know that nmap will trigger an IDS. That is all well and good, but what exactly did nmap do which made Snort aware of its presence? That is a good question indeed, and one which we shall now cover. First off let us take a look again at the “alert.ids” file.


Figure 1

We shall now deal with each alert individually in a certain fashion. First off we shall look at the alert itself. Following that we shall track down the actual Snort rule that nmap triggered by its series of packets sent during the scanning of the computer hosting Snort. Lastly, we shall look at the actual packet as sent by nmap to round out our analysis. On that note let’s begin our analysis!

The first alert we have to look at is “ICMP PING NMAP”. A lot of information can be gleaned simply by reading what the alert has to say. We know that Snort classifies it as an “attempted information leakage”. Well that is true to a certain extent as an ICMP echo packet is generally used to see if a computer is active at a certain IP address. That would be true if an ICMP echo reply was sent back in response to the echo request. Should the information listed there not be enough then you should look in the /rules directory in Snort for the exact rule itself. Listed there will be the SID number which you can use on Snort’s homepage to get a better explanation of the rule in question. Take a peek below for what I mean.


Figure 2

Once you have then found and opened up the icmp ruleset in wordpad, or some such viewer, you will quickly find the rule called “ICMP PING NMAP” there as seen below.


Figure 3

Now click on the rule and read the entire line dedicated to it. On that line you will notice a SID number. That is the number that you will need to enter on the Snort homepage under the rules tab. This page will give you a better description of the rule in question. It is very important that you understand how and why the rule will be triggered. It is not good enough to simply say it is that alert, you must understand exactly why it was triggered. With that knowledge you will be able to wean out the false/positives and deal with the true alerts. Well let’s now take a look at the exact packet that was sent by nmap. Please see the packet below.

10:14:46.687500 IP (tos 0x0, ttl  48, id 28060, offset 0, flags [none], proto: ICMP (1), length: 28) 192.168.1.104 > 192.168.1.107: ICMP echo request seq 45131, length 8
0x0000:  4500 001c 6d9c 0000 3001 9921 c0a8 0168       E...m...0..!...h
0x0010:  c0a8 016b 0800 ed7c 5a37 b04b                         ...k...|Z7.K

Well in case you have not gone to the Snort homepage and checked out the rules section to get an exact breakdown of this rule here is a quote from it.

“Nmap's ICMP ping, by default, sends zero data as part of the ping. Nmap typically pings the host via icmp if the user has root privileges and uses a tcp-ping otherwise.” 

Well it seems the defining feature of this rule is that Nmap does not send any data as part of the ping packet. Quite a few network management utilities send data in the ICMP echo packet. That said, our packet as seen above has nothing in the “payload” as it were. So it appears to be a genuine Nmap packet after all. Please remember that the underlined portion of the packet above is the actual ICMP message itself. The rest of it is the IP header required for routing of this message. Excellent then! We are making some real progress here. Don’t underestimate the skill required to track down alerts to this level. Should you be lucky enough to work in the computer security industry then this type of knowledge will pay off for you time and again.

Now let’s take a look at the next alert from our “alert.ids” file. This one is called “TCP port scan”. Strangely enough I could not for the life of me find the category in the rules directory where this specific rule resided. Should one of you find it please email me as I would be most curious to find out. Either way this alert fires when a port scan is detected. The one anomaly of this is the “DgmLen: 162” as seen in the alert.ids picture above. That is strange for a port scan as typically a port scan would be a simple TCP/IP packet or a UDP/IP one. Certainly a scan would not normally contain any data in it. That plus the IP PROTO of 255 and a TTL of 0 would certainly set off some alarm bells.

Now here is the strange part. I went to my packet file as captured via tcpdump.exe and did not find any such packet. There was nothing with a packet size of 162, and the other matching characteristics. Well one of two things happened here. The first is tcpdump.exe simply did not log the packet as it was sent out the interface, and two that Snort misinterpreted what was sent. I would say it is more likely that tcpdump.exe simply did not log the packet. That has happened before to me and seemingly has again. At this point I would simply shrug off this anomaly and move on to the last alert.

SCAN nmap XMAS is a packet in which only the URG/PSH/FIN flags are set. This is an old and ineffective scan now, but is still used by some people. The snort rule for this is as seen below.

alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"SCAN nmap XMAS"; flow:stateless; flags:FPU,12; reference:arachnids,30; classtype:attempted-recon; sid:1228; rev:7;)

Well our packet below certainly seems to fit this rule perfectly. Please note the underlined portions of the packet. We see the flags present via the “FP” and “urg”. Definitively we know these flags are set by the value of “29” (this is 0x29 or 29 in hex) in the TCP flags field. Perfect then!

10:14:47.109375 IP (tos 0x0, ttl  53, id 24630, offset 0, flags [none], proto: TCP (6), length: 60) 192.168.1.104.47824 > 192.168.1.107.53: FP, cksum 0xd1e3 (correct), 1815364556:1815364556(0) win 2048 urg 0 <wscale 10,nop,mss 265,timestamp 1061109567 0,eol>
0x0000:  4500 003c 6036 0000 3506 a162 c0a8 0168  E..<`6..5..b...h
0x0010:  c0a8 016b bad0 0035 6c34 43cc 0000 0000  ...k...5l4C.....
0x0020:  a029 0800 d1e3 0000 0303 0a01 0204 0109  .)..............
0x0030:  080a 3f3f 3f3f 0000 0000 0000            ..????......

With the exception of dropped packets we were able to account for the nmap alerts that Snort generated upon detecting nmap port scanning the computer it was on. We can then say with certainty that nmap leaves a residue that an IDS will indeed detect. On that note I will break the article series here. We shall carry on with the future parts looking at other tools and their possible footprints. Till then!

If you missed the other articles please read:

See Also


The Author — Don Parker

Don Parker specializes in matters of intrusion detection, and incident handling. He has also enjoyed a role as guest speaker at various network security conferences, and writing for various online and print media on matters of computer security.