Snort project

You are to configure and run Snort on some packet trace files I have provided for you (trace.1 and trace.2 in the yellow menu bar; there maybe a trace.3 too). You are then to do the following:

• Get snort to run, including building a snort.conf file
• Get all the necessary rules files
• Run snort on the tracefiles I provide
• Identify the string (if any) and the packetization for each alert
• Make the rules more sensitive, described below, and see if any more alerts are triggered
• Turn off the stream4 preprocessor, and see what alerts no longer fire
• Decide whether, if two or more alerts match for the same packet, whether both fire or just the first one

You can install and run Snort on your own PC, or use the executable on xenon.cs.luc.edu, from my home directory. You will be running snort in intrusion-detection mode, but you will be reading from a file rather than the network:
     snort -l -c your.snort.conf -r trace.2
You may also want the -m or -u options to avoid weird file-ownership changes.

On xenon.cs.luc.edu, there is a shell script to run snort at
      /homes/users/cs/faculty/pld/bin/snort
Note that due to restrictive directory permissions you can't just browse to find this. But if you copy the above file, you can use it to run snort. It's a short shell script; the real executables and libraries are referred to in it but you don't need to copy those.

You can download rules and configuration files from snort.org or bleedingsnort.com. You will not need the most recent rules.

All the simulated attacks are scans or are directed at the ftp server (port 21). Thus, it is possible (though perhaps not useful) to trim your snort.conf file considerably. Many of the attacks are attempted buffer overflows, which in a real attack would have a form like
     USER NOPslideNOPslideNOPslideNOPslide...NOPslideOVERFLOW_PAYLOAD
The default trigger length for these in the standard-issue snort ftp.rules file is 100 bytes. Try changing that to 50 to increase sensitivity, and see what new alerts file. Also, you should identify the actual strings used to pad out the overflow (NOPslide,etc above), and print them out with packet boundaries indicated:
     here i|s a lon|g str|in|g wit|h bou|ndaries for t|en pac|ket|s marked
You should identify the string for every alert, but you only have to work out the exact packetization for three of the strings that underwent segmentation. That is, two-thirds of the attacks have the entire string in one packet and one-third were sent broken up into multiple packets (but with no other evasion applied); you only have to do three of the latter. Note that snort does the packet reassembly for you; figure out how to get this to be saved somewhere.

Turn in your results, together with a discussion of the points about sensitivity, stream4, and duplicate alerts in the first paragraph above, and also your snort.conf file. I don't need the rules, unless you have edited them (which you shouldn't do anyway, except for the rule sensitivity adjustment from 100 to 50 described above).