Implementing an Intrusion Detection System
CIS4360
Now that you have created a script which can be deployed at Reynholm to better filter traffic, Mr. Avenal would like to turn his attention. Moss mentioned real-time alerting with something called an Intrusion Detection System and Avenal would like to try this out on the network traffic provided earlier. That traffic contained port scans, user logins over FTP and telnet, SSH communication, transferring of restricted files, and more; you're going to create IDS rules which will alert on some of this behavior.
Rename the snort.conf file to snort.conf.old. Create a new snort.conf file, open it in an editor such as nano, and add the following lines of text:
ipvar HOME_NET 192.168.253.0/24
ipvar SERVER 192.168.253.129
ipvar VICTIM 192.168.253.130
ipvar BADGUY 192.168.253.128
var RULE_PATH /etc/snort/rules
include $RULE_PATH/nameOfYourRulesFileGoesHere
When you run snort after changing the configuration file, you're going to get a lot of this warning each time:
WARNING: No preprocessors configured for policy 0.
This is normal. We're bypassing all of snorts preprocessors by creating our own stripped down configuration file.
Create a file called '<firstname.lastname>.rules' located in the /etc/snort/rules directory. In that file, create the following rules:
1. Alert on any traffic with the RST flag set to the server from .128. Your message should indicate: ".128 Possible SYN Scan."
2. Alert on any FTP traffic with the SYN flag set from .128 to the victim. Message should read: ".128 attempt to FTP to victim."
3. Alert on any telnet traffic with the SYN flag set, from .128 to the victim. Message should read: ".128 attempt to telnet to victim."
4. Alert on any ssh traffic containing the keyword "SSH-2", from .128 to the server. Message should read: ".128 attempt to SSH to server."
5. Alert on any http traffic from .128 with the SYN flag set, from .128 to the server. Message should read: .128 attempt to the web server."
6. Alert on any http traffic from .128 containing "apache2.conf" sent from .128 to the server. Message should read "Found apache2.conf."
7. Alert on any packets from .128 to the victim containing "passwd". Message should read: "Found passwd."
8. Alert on any packets from .128 to the victim containing "shadow". Message should say "Found shadow"
9. Alert on any ftp traffic from the .128 to the victim that contains "jgarrett" . Message should read "jgarrett over ftp".
10. Alert on any ssh traffic from .128 to the server with the FIN and ACK flags set. Message should read "F/A for SSH teardown."
Run Snort:
sudo snort -d -l /var/log/snort -c /etc/snort/snort.conf -r nameOfPcapFile -A console > RULE1
This command assumes you are running the command from the current location of the pcap file. Don't move the pcap file to the snort/ directory otherwise you're going to have a bad time trying to redirect output to RULE files.
Keep the pcap file somewhere like your home directory and work from that location to prevent permission errors with creating RULE files by redirecting output.
If there are any bugs in your rules that will be shown at the bottom of the screen. Debug your rules then rerun them.
The RULE1 file will contain the alerts for the first IDS rule
Open the RULE1 file and count the number of rules. Every policy will have at least one hit so if your file is empty, something is likely wrong with the rule.
If you're confident your first rule is correct, save that RULE# file, open your rules file, comment out that first rule. Create your second rule, save the file, and run snort again.
sudo snort -d -l /var/log/snort -c /etc/snort/snort.conf -r nameOfPcapFile -A console > RULE2
The RULE2 file will contain the alerts for the second IDS rule
Open the RULE2 file and count the number of rules. Every policy will have at least one hit so if your file is empty, something is likely wrong with the rule.
If you're confident your second rule is correct, save that RULE# file, open your rules file, comment out that second rule. Create your third rule, save the file, and run snort again.
Repeat this process until you have a rule file with ten rules and log files RULES1 through RULES10
1. Your <firstname.lastname>.rules file. At the top of the rules file, you should list the rules and your count such as:
.128 attempt to FTP to victim NUMBER times
.128 attempt to telnet to victim NUMBER times
.128 attempt to SSH to server NUMBER times
etc
2. Your ten separate RULES# files that contain the alerts. These RULES files shouldn't contain unnecessary alerts.
3. 1/2 page management summary back to Avenal, written in non-technical language, that provides an overview of what you were requested and what you did. Don't worry, this is the last one of those for this class!
Copy your rules file, your ten RULE# files, and your management summary to its own directory, zip that directory, and that's your assignment submission.
You aren't using Wireshark for this assignment specifically, but you can use it to compare what you find with Snort against what's in the packet capture.
Filter hints from: Top 10 Wireshark Filters
Also now as a Video
"The filtering capabilities of Wireshark are very comprehensive. You can filter on just about any field of any protocol, even down to the HEX values in a data stream. Sometimes though, the hardest part about setting a filter in Wireshark is remembering the syntax! So below are the top 10 display filters that I use in Wireshark.
1. ip.addr == 10.0.0.1 [Sets a filter for any packet with 10.0.0.1, as either the source or dest]
2. ip.addr==10.0.0.1 && ip.addr==10.0.0.2 [sets a conversation filter between the two defined IP addresses]
3. http or dns [sets a filter to display all http and dns]
4. tcp.port==4000 [sets a filter for any TCP packet with 4000 as a source or dest port]
5. tcp.flags.reset==1 [displays all TCP resets]
6. http.request [displays all HTTP GET requests]
7. tcp contains traffic [displays all TCP packets that contain the word ‘traffic’. Excellent when searching on a specific string or user ID]
8. !(arp or icmp or dns) [masks out arp, icmp, dns, or whatever other protocols may be background noise. Allowing you to focus on the traffic of interest]
9. udp contains 33:27:58 [sets a filter for the HEX values of 0x33 0x27 0x58 at any offset]
10. tcp.analysis.retransmission [displays all retransmissions in the trace. Helps when tracking down slow application performance and packet loss]"