Creating an IPS with Snort & iptables to Detect & Block Buffer Overflow Attacks, Lab Reports of Electrical and Electronics Engineering

Download Creating an IPS with Snort & iptables to Detect & Block Buffer Overflow Attacks and more Lab Reports Electrical and Electronics Engineering in PDF only on Docsity! ECE4112 Internetwork Security Intrusion prevention system Group Number: _________ Member Names: ___________________ _______________________ Date Assigned: Date Due: Last Edited: Lab Authored by Mu-Hsin Wei, Renaud Moussounda (Group 6) Goal: Learn Intrusion Prevention System (IPS) through hands-on implementation of an IPS. Summary: We will be building an IPS using snort and iptables. This IPS will detect and block potential buffer overflow attacks. Requirements: Need three machines setup in Lab 4 (firewall lab), namely: Protected (192.168.0.10) Linux firewall (Red Hat WS 4.0) Blackhat (131.210.231.55) We also need the imapd package used in Lab 6: imapd_exploit.tgz need snort_inline that does not come with the snort we currently have: snort_inline-2.1.0-1.i386.rpm and configuration files for iptables and snort_inline: IPS_lab.tar.gz Background: An Intrusion Prevention System (IPS) is a system that controls network access to protect a network. The major difference between an IPS and traditional firewalls is that IPS makes decisions based on the application content of a packet, rather than just the header information in a packet. Most traditional firewalls (e.g. iptables) filter Internet packets by inspecting only the packet header. Filtering decisions are made based on the header information. However, valuable information could well reside in the payload of a packet (i.e. the data). Inspection against the payload could bring much benefit in securing a network by having more knowledge about the traffic. Deep Packet Inspection (DPI) describes this type of packet inspection. 1 It is true that DPI can provide more information and strengthen security, but it does so at a high cost of computing resources (e.g. CPU and RAM). Clearly, it is expensive to examine the payload of every packet because the payload size maybe large and they vary, and matching pattern in a not-fixed data section requires a lot of resources. For this reason, DPI systems are usually implemented on a separated piece of dedicated hardware. In this lab, we will simply get an experience with how IPS works by performing DPI using snort_inline and basic firewall operation using iptables. IPS can prevent many different kinds of attacks. In this lab, we will specifically look at how buffer overflow attacks can be prevented. Other countermeasures work similarly. In Lab 4 we learned how buffer overflow attacks over the network are performed, and how networking application programmers can avoid this kind of attack by properly restricting the data being stored into the memory. This defense is the most ideal way of preventing buffer overflow attack. However, the responsibility completely lies on the program developer. Another way to effectively reduce buffer overflow attack is to filter out any "buffer overflow traffic" which can be easily identified by the large number of NOP commands (see Lab 4 for details about NOP). Clearly, we need DPI to detect this signature in the payload. We will implement an IPS that first detect buffer overflow packets and then block the traffic. Lab Scenario: This lab adopts the network configuration used in Lab 4 where we had three machines: Blackhat, Protected, and firewall. It’s a perfect setting to test our IPS. On the other hand, we will use the imapd vulnerable service to introduce the attack and defense. Recall that in Lab 6 that imapd was vulnerable to remote buffer overflow attack. imapd-ex is used to generate an exploit string to obtain a shell on the vulnerable server running imapd. You did these two labs previously and this section should be straightforward since there are no major changes. The combined machine setup is illustrated below: 2 Procedures: Now we have everything that we need to perform the attack and the IPS defense. The firewall is setup so that ALL traffics are allowed. We only want to show that a buffer overflow attack can be blocked. See iptables.firewall (extracted from IPS_lab.tar.gz) for firewall configuration. Start iptables (firewall): 1. /etc/init.d/iptables start 2. cd IPS_lab where you extracted the IPS_lab.tar.gz 3. ./iptables.firewall setup firewall Now the firewall is up. You should be able to ping each other from Protected and Blackhat. snort_bof.rules contains two rules where the first (<alert>) one only detects the attack but does not block it. The second rule detects and blocks the attack. The second rule (<reject>) is commented out by default. Leave the rules file as it is. We will first perform an attack without blocking. Look into snort_bof.rules, the first rule is: alert 131.210.231.0/24 any -> any any \ (msg: “buffer overflow detected”; content |90 90 90 90 90 90 90 90|;) This means that snort_inline will search for the pattern “90 90 90 90 90..” (the buffer overflow signature) in the payload of all packets coming from the outside network (vmnet2). If the pattern is found, the packet is logged. (Recall that a buffer overflow has a lot of NOP’s, represented by long sequence of 0x90 on our machine. Refer to Lab6 for detailed explanations). Section 1 - Detect buffer overflow attack Start DPI on WS 4.0 (still in the directory where you extract IPS_lab.tar.gz): 1. snort_inline -Qvdc snort_bof.config -l /var/log/snort_inline/ This starts the DPI process. -Q means to get packets from iptables -vd means to display full packet info on screen -c specifies the configuration file -l specifies the where the log files are store On Blackhat, attack Protected: 2. (./imapd-ex 3500 ; cat) | nc 192.168.0.10 143 You should get a shell from the attack. Try some commands (ls, whoami, netstat…). You may need to try other offsets other than 3500. Use the offset you got in Lab 6. Now let’s check if snort_inline catch this attack. Look into the log file on WS4.0: 3. cat /var/log/snort_inline/snort_inline-fast You should see a line containing “buffer overflow detected”. Q1. Were you able to get a shell from the attack? Q2. Record the full “buffer overflow detected” message in snort_inline-fast. 5 Q3. How does snort_inline recognize the buffer overflow attack? Now we see that our IPS is able to detect the harmful packet. However, Blackhat is still able to successfully born a shell on Protected because IPS takes no action on the packet besides logging. Now we are going to enable the full capacity of our IPS. Section 2 - Detect AND block buffer overflow attack Modify snort_bof.config (WS4.0): 0. Stop snort_inline using ctr+c. Use your favorite editor to, 1. comment out first rule (alert) 2. uncomment the second rule (reject) 3. save the file Understand that the rule we are using now is: reject 131.210.231.0/24 any -> any any \ (msg: “buffer overflow detected and blocked”; content |90 90 90 90 90 90 90 90|;) which means any packet coming from outside network (vmnet2) will be logged and rejected if it contains a long sequence of NOPs (0x90). Start snort_inline again: 1. snort_inline -Qvdc snort_bof.config -l /var/log/snort_inline/ On Blackhat, attack Protected: 2. (./imapd-ex 3500 ; cat) | nc 192.168.0.10 143 The attack should fail because IPS blocked buffer overflow packets. No shell is obtained. Now let’s check the log file on WS4.0: 3. cat /var/log/snort_inline/snort_inline-fast You should see a line containing “buffer overflow detected”. Q4. Were you able to get a shell from the attack? Explain why or why not. Q5. Record the full “buffer overflow detected and blocked” message in snort_inline- fast. Notice that our vulnerable imapd server seemed to be immune to the attack now even though nothing was changed on the imapd server! Protected is still running the same vulnerable program. However, IPS was able to secure Protected by blocking attacks traffic before it reaches the machine. IPS does not need to know if a machine in its network is vulnerable; it can block all potential attacks with out any assumption. By having IPS, a network’s security is less dependent on the server applications. That is, even if a service is vulnerable, IPS is able to secure a network providing that service by blocking attacks against that vulnerable service. The implication is huge. Say, IPS can be a quick fix to networks running many old-vulnerable servers (though shouldn’t be a 6 permanent solution.) This lab demonstrates only how buffer overflow attacks can be prevented, but other counter measures can be realized with the same concept. Q6. Discuss how IPS could be used other than blocking buffer overflow attacks. Q7. Can iptables by itself perform the same operation that you just did (i.e. block buffer overflow attack)? Explain. Q8. What’s the main difference between traditional firewall and IPS? Short answer: Q9. Why an IPS is usually implemented as hardware? 7