Thanks to refer to the attached file.
1 CS6262 - Network Security Project 4 1 Introduction - Goal of the assignment The goal of this project is to introduce students to techniques that help to differentiate between malicious and legitimate network traffic. This is a task that threat analysts and network operators are often called to perform. In this project, the students are provided with samples of malicious and legitimate traffic, so that they can observe how each type of traffic looks like. Then they are given a pcap file that contains network traffic that originates from multiple hosts in the same network. This pcap is a mixture of legitimate and malicious traffic. The students are asked to replay the pcap file against a network interface. Finally, the students are asked to use Snort and write their own Snort rules to differentiate between malicious and legitimate traffic. In summary the students are introduced to: • Observing pcap samples of legitimate and malicious network traffic. • Using Snort and writing Snort rules to differentiate legitimate traffic from malicious traffic. Hosts in net 192.168.x.x/16 Figure 1: Network setup for traffic collection. 2 Definitions and Traffic Collection Set-up In this assignment, we have collected traffic from an enterprise network. The hosts are behind a NAT, and their IP addresses belong to a single /16: 192.168.x.x./16. Figure 1 shows a visual representation of the network and of our traffic collection set-up. Each host in the network can only have one out of three distinct roles: Benign host. The host generates normal background traffic (e.g. HTTP). Also, the host may be generating traffic due to social activities, e.g. The host communicates with a server to participate in a chat channel. • 2 Isolated infection. The host is infected and performs a malicious activity e.g. Scanning, DDoS, etc. The host generates normal background traffic (e.g. HTTP) and malicious activity traffic e.g. scanning, DDoS, etc. Bot. The host communicates with a C&C server to receive commands AND it performs a malicious activity (sign of infection) e.g. scanning, DDoS, etc. The host generates normal background traffic (e.g. HTTP), C&C communication traffic and malicious activity traffic. Please read the paper” BotHunter: Detecting Malware Infection Through IDS-Driven Dialog Correlation” which was published by Gu et al. at Usenix Security 2007. Specifically, for a complete discussion about what is a bot (definition) please see Section3. As the authors state: A bot has to exhibit: Evidence of local host infection, AND evidence of outward bot coordination or attack propagation. Reading the entire paper can give you a lot of information and background for this project. The paper can be found here: http://faculty.cs.tamu.edu/guofei/paper/Gu_Security07_botHunter.pdf. Also, please see the reading section below. Samples of traffic. For each type of traffic that is mentioned above, we provide a sample of that category/type of traffic. These samples are only for illustration purposes. These samples are only examples, and they are not the same as the actual traffic that is included in the Spring2019_Evaluation.pcap, which the students will need to label. Legitimate background traffic. For the purpose of this exercise we assume normal traffic to include HTTP, DNS. For an example of normal (attack free) traffic please take a look at the sample file. Sample pcap: SAMPLE_background_legit.pcap Legitimate social activity traffic. This traffic is benign and is generated when a host participates in benign social activities e.g. chat. Sample pcap: SAMPLE_benign_socialchat.pcap • Infection traffic: Scanning. Sample pcap: SAMPLE_bad_scan.pcap C&C communication. The host generates this traffic explicitly to communicate with a C&C server. The host communicates with the C&C server to receive commands, updates, etc. . Sample pcap: SAMPLE_bad_CnC.pcap • For DDoS we do not provide a sample. Please look at the example Snort rules on DDoS at the resources section. The pcap files can be found in https://www.prism.gatech.edu/~pdagostino3/CS6262-Project4/ or if you are using the VM, it can be found in the Project 4 directory. 3 Tasks The goal is to: a) write Snort rules, b) using the Snort rules to label each connection in the Spring2019_Evaluation.pcap file as CnC-communication (communication between the host and a C&C server to receive commands), malicious activity (scanning or ddos), or other (if the connection does not belong to any of the previous two categories), and c) to label each host with a role (one of the distinct roles above). Towards this goal, please follow the tasks below: • Install in your local machine Snort and wireshark. • Download: the pcap files (samples and evaluation) from https://www.prism.gatech.edu/~pdagostino3/CS6262-Project4/. • Optionally you can use the provided VM: – If you don’t want to install snort on your local machine, we have installed Snort at a VM. The VM also has copies of the pcap files. – Import the VM. Login to the VM using: login: student, password: Project4 – Locate the pcap files at the directory: /home/student/CS6262-Project4/. In this directory you will find the sample pcaps. • Make observations on the pcaps: – Observe the sample pcaps to get an idea about how each type of malicious traffic looks like. – You can use wireshark or tshark to isolate some traffic, if you want. For example in wireshark you can apply display filters e.g.tcp (to display only TCP traffic), ip.addr == 10.0.0.1 (to display traffic that originates from or it is destined to this IP address), also you can combine filters using or and and. • Write Snort rules. To write Snort rules, you will need to edit the file: • • • • • http://faculty.cs.tamu.edu/guofei/paper/Gu_Security07_botHunter.pdf https://www.prism.gatech.edu/~pdagostino3/CS6262-Project4/ 3 sudo vim /etc/snort/rules/local.rules Example Snort alert rule based on IP: alert tcp 10.0.0.1 any -> any any (msg:"TCP traffic detected from IP 10.0.0.1"; GID:1; sid:10000001; rev:001;) It creates an alert message: "TCP traffic detected from IP 10.0.0.1" when there is a TCP connection from source IP 10.0.0.1 and any port to any destination IP and any destination port. – The above example Snort rule has been entered for demonstration at the file /etc/snort/rules/local.rules. Please edit this file as needed when you write your solution. – More Snort rules examples are provided here: http://stuff.is-a-geek.net/OnlineDocs/Security/Snort/chap2.html – Test the new Snort configuration. sudo snort -T -i eth0 -u snort -g snort -c /etc/snort/snort.conf Wait for a few seconds until the process finishes. If the configuration is OK, you will see the following: Snort successfully validated the configuration! Snort exiting – Start Snort and feed the Spring2019_Evaluation.pcap. sudo snort -A console -u snort -g snort -c /etc/snort/snort.conf -r Spring2019_Evaluation.pcap – You need to wait a few seconds until snort starts. It will display several messages and then: Commencing packet processing . At that point Snort should proceed to process the traffic you have indicated and print alerts. – Snort should generate alert messages on the screen (the same screen where you started Snort), using your rules. – You can capture Snort’s output by redirecting the output to a file. sudo snort -A console -u snort -g snort -c /etc/snort/snort.conf -r Spring2019_Evaluation.pcap > my_snort_output – You can free space in the VM by deleting snort logs: sudo rm /var/log/snort/* – In your set of Snort rules, include a Snort rule that catches all connections, even these that are legitimate. This will help you to report all connections, both the legitimate and the malicious. – Put appropriate string at the alert message that the Snort rule generates. Choose: • 1) other (to catch all) • 2) infection (to catch ddos or scanning) • 3) cnc (to catch cnc communication). – Snort rules and Snort output. Note that your Snort rules should generate (show up on Snort screen) for each packet an alert that is: other, or infection, or cnc. The rules for other and infection maybe fired for the same packet. The same can happen for other and cnc. But your rules for infection and cnc, should not be triggered for the same connection or the same packet. – Writing Snort rules: You are expected to write your Snort rules that: 1) are not based on artifacts (e.g.block a specific port or IP or a specific protocol) and 2) have potentially long shelf life (e.g.if you were to deploy your rules in a real scenario you would not need to change your rules very frequently). For example, it is not OK to create a Snort rule based exclusively on artifacts of the sample traffic, e.g.a specific port number, or a specific IP address, or specific protocol. It is not OK, to flag a connection as malicious by writing a Snort rule that just flags a connection based on the src or dest IP address, or flags a connection just because it is HTTP, port 80. The reason behind this is that artifacts may change e.g.a port number or a specific IP address may change, Also, artifacts are not enough to capture the attack, the impact of the attack, the logic behind the attack and so on. It will help, if you think as a threat analyst. For example, would you ever create a Snort rule that flags the incoming traffic to a network, based exclusively on a port number or exclusively on an IP address? The answer is no, and this is because, these may easily change, and they may produce lots of false positives. • Generate a connections report based on Snort’s output. – After you write your Snort rules, and you feed the evaluation pcap to Snort, you will see that Snort starts generating alerts for each packet. You can save the output and process it with a script to generate a report with connections and a label for each connection. – What your post-processing script is allowed to do: If a connection shows up with only one type of alerts, then you can just report that. Some connections will show up with other for one