| 
  • If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • Stop wasting time looking for files and revisions. Connect your Gmail, DriveDropbox, and Slack accounts and in less than 2 minutes, Dokkio will automatically organize all your file attachments. Learn more and claim your free account.

View
 

Assignment 4: Intrusion Detection

Page history last edited by Patrick 4 months, 4 weeks ago

Assignment 4

Implementing an Intrusion Detection System

CIS4360

 

Scenario

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.

 

Procedure:

 

  1. Install Snort in Mint
    1. sudo aptitude install snort
  2. Download the PCAP File
  3. Create/Modify snort.conf Configuration File
  4. Create the rules based on the policies below 
  5. Run Snort using your rules against the PCAP

 

 

Changes to snort.conf (Important)

 

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: 

 

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

 

Don't worry!

When you run snort after changing the configuration file, you're going to get a lot of this 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.

 

 

Files You'll Need

 

 

Rules To Make

 

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."

 

 

 

Testing Your Rules

 

  1. Create one rule
  2. Test and Log that Rule
    1. Did you get at least one hit?
    2. Confident in your results?
  3. Comment out the rule
  4. Create a new rule and repeat

 

 

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

 

 

Hints

 

  1. Most of the above rules are targeting a specific protocol, i.e., TCP, UDP, ICMP
  2. If a service isn't mentioned, then the port doesn't matter
  3. If a service is mentioned, then the port does matter
    1. Do not use 'any' if a service is stated
    2. Hint: ftp normally runs on 21, telnet on 23, etc, and are TCP while DNS uses UDP

 

 

Deliverable

 

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.

 

 

 

Hints to Check Your Work Via WireShark

 

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]"

Comments (0)

You don't have permission to comment on this page.