If you missed the previous article series please read:

• Tools of the Trade (Part 1)
• Tools of the Trade (Part 2)
• Tools of the Trade (Part 3)
• Tools of the Trade revisited (Part 2)
• Tools of the Trade revisited (Part 3)

Over the course of three articles back in March, I described what some of the tools are that every network security professional should use, and by extension become aware of. A broad selection of tools were installed, looked at, and used during the span of that series. We went over such staples as packet sniffers, network scanners, packet crafters and finished up with an HTTP proxy. The goal of that series was to become familiar with not only those tools, but also to understand how they are used by malicious hackers to gain access to computer networks, both from within and without.

With the above in mind, we shall now push this in a different direction. That being, how would these tools appear to an Intrusion Detection System (IDS)? Having an IDS as part of the computer network landscape is really no longer the stuff of paranoid system administrators. These devices, be they hardware based or software, are now common place. If anything, not having an IDS residing somewhere on your network would nowadays raise eyebrows. You could consider IDS’s as being part of your early warning system.

Of NIDS, HIDS, and everything in between

Often, when an IDS is mentioned in conversation, people are confused as to where the appliance (if hardware based) or program (if software based) actually resides. This is where you begin to get into the various types of IDS’s there are. There is the Host Intrusion Detection System (HIDS), and the Network Intrusion Detection System (NIDS). The HIDS will reside right on the client computer itself, while the NIDS will generally be plugged in via a SPAN port on a switch. Each of these IDS varieties has its advantages and disadvantages. Covering them is beyond the scope of this article, but to understand the difference between them I encourage you to read this article written by Ricky M. Magalhaes.

Let’s get set up

So far I have provided a bit of background information for this article series and touched a bit on HIDS and NIDS. It is now time to get the party started and to that end I shall now detail what I am using to create this article series. Please see below for the list of software tools that I used.

• VMware
• Snort
• W2K Pro, Win XP Pro (service packs or patches of no importance for either)
• Tools covered in "Tools of the Trade Part I, II, III"

If you have a copy of VMware then I greatly encourage you to use it and follow along with me as I replay these tools against an IDS, Snort in this case. Furthermore, to make sure we are on the same page, the exact build of Snort that I am using is:

Figure 1

I won’t delve into the installation of Snort as this has been covered by me several times before. Simply download it and install it at the root of your C drive. Should you wish you can also download the latest rules as well for it. Don’t forget to install the appropriate version of winpcap for the Snort build you are going to install.

Packet sniffers and Snort

The first tool that we had looked at in the “Tools of the Trade” article series was a packet sniffer. You will recall that a packet sniffer is one of the tools that you really must learn how to use and become comfortable with. The Question is: will the use of a packet sniffer trigger an IDS rule? Well I don’t think you will be surprised to hear that an IDS will not really detect a NIC card going over to promiscuous mode. For that type of detection there are other methods and tools for the job. Snort however is not really one of those tools. Well that was short and sweet. Let’s move on to the next tool that we covered in the above noted series.

nmap and Snort

Nmap is without doubt the best known network scanner in existence today. It is a formidable weapon and has only grown stronger with the passing years. Due to nmap’s popularity and the way that it implements some of it’s scans, IDS signatures have now been written for it. Whenever you do something in a unique fashion you can or will become known for it. This is no different then a famous painter and their unique interpretation of certain landscapes for instance, or in nmap’s case, packet generation. Well as someone once said “seeing is believing” so let’s do just that shall we.

To set the stage for this upcoming experiment let’s go over a few things. You will need to have snort running on a computer or VM image. On another computer you will need to have the Windows port of nmap installed. Right then! Now go ahead and invoke your Snort program as I did below.

Figure 2

This will get Snort up and running and parsing those evil packets as they flow to the computer. Next we need to send Snort some packets from nmap to see if using nmap will indeed trigger any alerts from Snort’s ruleset. So to that end please invoke nmap on another computer as seen below. Please note you will need to substitute IP addresses for the ones in use in your lab.

Figure 3

The above noted switches for nmap and its subsequent generation of packets to do the job leave behind residue on the targeted computer. Snort does recognizes nmap for what it is. This is due to rulesets being created for the way that nmap does business. Remember that I said nmap does things in a particular fashion. Once you become predictable, you become recognizable. Please note that you will have some output as generated by Snort once you stop it. Now that we have some input that Snort was able to generate something on, let’s go take a look at it. You will now need to go to your /log directory and view the “alert.ids” log found there.

Figure 4

I will break the article at this point and pick up in part two by analyzing what is in the “alert.ids” file. We will then carry on by equating this to the Snort rule itself, as well as by looking at the actual packets themselves that were sent by nmap. By doing this we will be able to definitively understand why nmap was picked up by Snort as we will have followed the whole process from start to finish. Though some of you may find it tedious, or even redundant, let me assure you that it is the only way to actually understand the nuts and bolts of why nmap is actually picked up by Snort. Much as I have expounded upon before, there is an ocean of understanding between only reading about something and actually doing it yourself. On that note, have fun and I will see you in part II.