This lab uses a modification of the VMware virtual machine from internetsecurityguru, an image of CentOS linux containing a preconfigured copy of the snort intrusion detection system. Your lab machines already have VMware. They may already have this VM installed, appearing in VMware's inventory as "Centos 4.3 min". If so, skip the next paragraph.

If not, to use the new virtual machine we have to copy it onto your hard drive and tell VMware to open it. Obtain it as directed by your lab assistant. (Don't use the original from the internet, the modifications I applied are needed so you require the modified one.) This VM consists of a set of about 10 files, to be co-located in a folder. One of the files has filename extension "vmx." You run VMware console, from whose File menu please browse to that file and open it. Your VMware inventory list is now populated with a new choice. Start this new virtual machine. When it asks you about a key, tell it to "create" one. Now you're up and running. (Within VMware, use ctrl-alt-del to expand a virtual machine to full screen, and ctrl-alt to restore it to a containing window of the host OS.)

[ You have instructions how to use ssh to log in to your VM for this exercise. Do it twice, resulting in two terminal windows onto the machine. ]

Find out the IP addresses of your Windows XP host [ use 192.168.1.132 ] and linux guest operating systems [this one you know, or use ifconfig eth0 to observe ]. Both are determined when the machines boot, via dhcp (address service) automatically. For Windows, in a command box:

Boot the snort/Centos virtual machine. Log in as user root with password "password." Find out the virtual machine's IP address:

We'll call this address "linuxIP." (Should there be no IP address, ask for one by triggering the dhcp client "dhclient eth0".)

On the linux machine enter a second virtual terminal and log in there as root a second time. [ You accomplished this paragraph already by your double login. Identify one of your terminal windows as the "first," and the other as "second." Use the first when these instructions talk about virtual terminal 1 and the second when they talk about virtual terminal two. ] (You can enter a second terminal by keystroke or command. The keystroke is ctrl-alt-F2; the equivalent command is "chvt 2".) Return to the original virtual terminal (ctrl-alt-F1 or "chvt 1"). You can switch your monitor back and forth between them with this way as needed. We will employ several virtual terminals.

Snort can operate as a sniffer. Sniffing is after all an essential prerequisite to intrusion detection-- you must be able to see intrusions in order to be able to detect them! To run snort as a sniffer we want to give it something to sniff. So let's sniff with snort in virtual terminal 1 while launching a quick ping to the Windows host from virtual terminal 2. First, in virtual terminal 1, start sniffing:

The "host <linuxIP>" phrase is a filter. It will eliminate confusing, noisy display of busy activity on the network, confining it to stuff with the virtual machine as IP source or destination. snort will keep running indefinitely. Now switch to virtual terminal 2 and ping:

This says send a single ping (icmp) message containing 4-bytes of payload consisting of ABCD ("41424344" are their ascii codes in hex), for easy visual identifiability in snort. Go back to snort in virtual terminal 1. Terminate it by pressing ctrl-C. (Be patient, I found it to take an inexplicably long time when duplicating these instructions. Or be impatient, ctrl-Z puts snort in the background then "killall -9 snort" termintates it.) Look at what snort captured. At the end snort prints some packet statistics which may scroll the packets off the screen. If so, press shift-PageUp to scroll backward in the screen buffer and view the packets.

There are two other snort command options of interest, -d and -e. From the man page:

-v Be verbose. Prints packets out to the console.

-e Display/log the link layer packet headers.

-d Dump the application layer data when displaying packets in verbose...mode.

in succession, re-pinging from virtual terminal 2 each time (use up arrow to recall the ping command instead of retyping it). snort with -v, -ev, and -dev gives as output different combinations of ethernet frame header, IP packet header, icmp message header, and icmp message data. (Review the SANS Institute "TCP/IP and tcpdump Pocket Reference Guide" to make sure you know what these are and can identify them in snort's output when you see them).

Snort can save and later re-read what it captures, much as tcpdump does. In fact, snort saves in the same file format. Snort, tcpdump, wireshark, and a number of other programs can thus all share and cross read each other's files. By default snort generates its own names for capture files, you don't have to name them. But it wants to put them in a directory and if you want other than the default ( /var/log/snort/ ) you must create the receiving directory and identify it to snort. Create it:

(In this exercise we make our own log file. More generally snort uses /var/log/snort/ by default.) Then log some stuff:

Wait a while to let traffic accumulate then interrupt with ctrl-C. (If you want to generate some traffic, from the other terminal window you can browse a website using the character mode browser lynx, e.g., "lynx www.usc.edu". After the page has loaded get out by pressing q then y.) Check that snort deposited a capture file in the receiving directory:

Its name is snort.log.tttttt where tttttt represents the time of capture. Use the "file" command to find out what kind of content it has:

When merely sniffing and logging, snort is passive. It doesn't do anything about it. But it is capable of reacting, if only you define what to react to and how to react. That's what rules do. You convey rules to snort by putting them in files and pointing snort to the files. Run snort now, pointing it to configuration file snort.conf which in turn tells it to pay attention to the rules in a series of about 40 rules files found in /etc/snort/rules:

snort -dev -l ./log -L bigping -h 192.168.1.0/24 -c /etc/snort/snort.conf host <linuxIP>

This also takes control of the name of the logfile, specifying "bigping". Again lauch a ping from virtual terminal 2 but make the ping packet abnormally huge:

Now, after terminating snort, examine results in the log directory. First, of course, the large ping should have been logged. Replay it:

There's the fat echo request, and its fat echo reply. More interesting, note there's a file named "alert" in the log directory. Check what's at the bottom of that file:

[**] [1:499:4] ICMP Large ICMP Packet [**]
[Classification: Potentially Bad Traffic] [Priority: 2]
10/16-21:02:19.445399 0:3:25:28:52:C4 -> 0:C:29:1B:AE:7B type:0x800 len:0xFCA
192.168.1.140 -> 192.168.1.114 ICMP TTL:128 TOS:0x0 ID:58836 IpLen:20 DgmLen:4028
Type:0 Code:0 ID:16 Seq:0 ECHO REPLY
[Xref => http://www.whitehats.com/info/IDS246]

which was written in response to seeing the huge ping. This alert's presence in the file is in reaction to the ping. There's no reaction to a regular ping though; the ping has to be big in order to get a rise out of snort. How big? Who says? This must be the product of a rule somewhere that says so. We said above that we think the rules come from files in /etc/snort/rules. Here's an attempt to find the rule that operated above:

Here, grep is searching for a fragment of the text seen in our alert message, embedded somewhere among the rules files. grep's output is like this:

/etc/snort/rules/icmp.rules:alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"ICMP Large ICMP Packet"; dsize:>800; reference:arachnids,246; classtype:bad-unknown; sid:499; rev:4;)
/etc/snort/rules/sid-msg.map:499 || ICMP Large ICMP Packet || arachnids,246

Looks like there's a relevant rule in file icmp.rules. What threshold size defines what's alertable and what's not? Test your answer by firing pings, while snort is running, at your hypothetical threshold size and one more or one less. Each tiime look in the ./log/alert file afterward to see if there's a resulting alert there or not. Find the ping "-s <size>" option value that is the boundary condition for alterting.

Now let's do something more normally considered intrusive behavior, a port scan. In virtual terminal 1:

snort -dev -l ./log -h 192.168.1.0/24 -c /etc/snort/snort.conf host <linuxIP> and not port ssh

Now let's write a customized rule of our own. We've been slinging a lot of ping packets containing "ABCD." How about a rule that will raise an alert about them for that reason (not because they be huge or tiny, just because of ABCD)? We must write our own rule and put it in the "my customized rules" file. That file is /etc/snort/rules/local.rules. To that file, append the following:

then restart snort (so that it will re-read its config files and implement the new rule):

snort -dev -l ./log -L abcd -h 192.168.1.0/24 -c /etc/snort/snort.conf host <linuxIP> and not port ssh

Find the alerts at the bottom of ./log/alert that indicate "ABCD embedded" for both the ping (echo) request and the ping reply.

Alerts are supposed to get attention. One that just inserts text into a file silently may seem no alert at all. Can't we email the administrator when a port scan occurs, for instance? Well no, snort doesn't do email, but yes, other programs can. swatch (simple watchdog) is such a program. It can dynamically watch any file and take arbitrary action whenever some preconfigured text appears in it. Sending some email could be that resulting action. While swatch won't watch for port scans and snort won't email, swatch will email when a "port scan occurred" message appears in a file and snort can provide that message whenever there's a port scan. Voila. They are complementary.

Send yourself an email whenever the above ping-provoked event occurs (namely, "ABCD embedded" shows up in ./log/alert). Let's use 4 virtual terminals:

virtual terminal 1 - for running snort
virtual terminal 2 - for executing ping
virtual terminal 3 - for running swatch
virtual terminal 4 - for running tcpdump on port 25 (email)

(By the way, when working with lots of virtual terminals you could get confused which one you're working in. The "tty" command will tell you.)

snort -dev -l ./log -L alpha -h 192.168.1.0/24 -c /etc/snort/snort.conf host <linuxIP> and not port ssh

In virtual terminal 3, configure and get swatch running. To configure, create a file in your home directory (/root) named swatchconfig with these contents:

watchfor /ABCD embedded/
exec /bin/echo "ABCD appeared" | /bin/mail -s "ABCD again!" <your account>@<your mail provider>

This says, "Continuously observe the content of /root/log/alert. Per instructions in ~/swatchconfig, perform what it tells me to do whenever I see what it tells me to watch for." In this case, ~/swatchconfig tells swatch to watch for the magic phrase "ABCD embedded" and to send off an email message in response.

It will reveal activity if mail is being sent, since mail sending is done via port 25. So you can measure whether your arrangement appears to work this way.

Afterwards, flip over to virtual terminal 4 and look for a flurry of mail packets. Then check your mail.

"ABCD" isn't very meaningful but you could use the technique for more meaningful and focused targets. A snort article from RedHat Magazine points out, "Close analysis of the protocol in use can turn up signature events. For example, a user logging into an ftp server may pass the string "user root". A rule can be written to look for that specific string on FTP's port."

Clean up - please remove the swatchconfig file from your home directory, and use an editor to delete your custom rule about ABCD from /etc/snort/rules/local.rules.

After you have performed the above lab components, answer the following questions.

1. What was the result of your test to determine the ping threshold size in the "Snort in ids mode" section above? That is, what's the smallest value for ping's "-s <size>" that triggers an alert?

2. In the /var/log/snort directory I find one file named alert and several files whose names begin with snort.log. What is the difference between their contents and purposes?

Visit the nessus URL contained in this alert. What is the purpose of an "Xref" in an alert?

alert tcp $HOME_NET 23 -> $EXTERNAL_NET any (msg:"TELNET login incorrect"; content:"Login incorrect";)

Explain it. Under the circumstances the rule represents, who is doing what? where? State precisely to which packets the rule applies, and what is the resulting action when such packets are seen. Explain the difference between the roles played by the two embedded strings "TELNET login incorrect" (what's that? why is it there? what does it do?) versus "Login incorrect" (why is it there? what does it do?).

The University of Southern California does not screen or control the content on this website and thus does not guarantee the accuracy, integrity, or quality of such content. All content on this website is provided by and is the sole responsibility of the person from which such content originated, and such content does not necessarily reflect the opinions of the University administration or the Board of Trustees