CSG254: Network Security

Practical Systems Security Lab
Lab #6

This week we explore firewalling (and by association, a little routing), intrusion detection, and denial of service (DoS) attacks. The basic DoS attacks discussed will be demonstrative of certain things you may wish to block by establishing firewall rules in this exercise and will also be used to exercise the rules of the IDS that you will configure before the end of the assignment. The goals are to understand the concepts behind different types of firewalls and how to set one up, how to set up, configure, and monitor for malicious behavior using Snort, a free open-source intrusion detection system, and to explore the symptoms associated with denial of service attacks and learn how to prevent certain conditions from arising in your network. In addition, current limitations and modifications for increased effectiveness to these technologies will be examined.

For this assignment each team will be given accounts on Dominus for remote auditing of their subnets (names and passwords will be emailed to you by the TA). As always, any tool mentioned here will be available via ftp from Dastun in the /pub/tools directory. Tools you will need to install for this assignment include:

Just like the last lab there are Optional sections.

  1. Firewalling

    1. Before you can configure a proper firewall you will need to position the existing nodes on your subnet behind a system that will act as your router/firewall. You have been assigned a Cisco router. If it is the former, you will need to do some extra work to explore the intricacies of Cisco’s IOS and CBAC (Hint: use access-lists). You will need the device/system to route between the internal and external networks as well as provide firewall functionality, but you should not hide hosts behind a NAT. IP addresses of your subnetted hosts should not change. Your existing systems should be located off a switch that is on the Firewall system’s internal interface. Please document your setup for this assignment.
    2. Install basic firewall rules (or access-list). Allow only the specific ports that you need for both hosts (22, 80, 443, 20, 21, etc) and leave an unfiltered “hole” for port 8080 (application-testing) as well. Make sure that all traffic that should be able to reach your systems is able to by testing access from your team’s shell account on Dominus. Turn in a listing of your rules and comments for each line explaining what action is being performed.

  2. Optional

    1. What advantages does stateful packet inspection provide you over a basic packet filtering firewall? Which kind of firewall are you running? Are you taking advantage of its capabilities? Discuss, and cite examples.
    2. Modify your basic firewall configuration (write some rules) to prevent IP spoofing if you haven’t already. List the rules you add or modify in order to do this here.
    3. What is the difference between this and an application proxy firewall? In what situation might you want to use the other?

  3. Denial of Service and Prevention:

    1. The SynFlood DoS attack overwhelms the target system with SYN packets. Why does this constitute a denial of service and what techniques can be implemented to prevent a Linux system from being the victim of such an attack?
    2. The Smurf DoS attack relies on certain foreign networks to be “amplifiers” of the attack it generates targeting a third-party network. Describe how this works and what you, as an administrator, can do to keep your networks from being used as amplifiers. List the specific configuration that you perform to prevent this behavior (for instance, the interface configuration command if you are using a Cisco device).
    3. Distributed Denial of Service (DDoS) attacks like TFN2k take the idea of DoS to the next level and are generally much more devastating in nature. Describe the architecture of a TFN2k attack and discuss strategies for preventing as much damage as possible in such an event.

  4. Optional

    1. Decide if your team is going to limit certain types of ICMP traffic. Implement this “policy” that you design in firewall rules, list them, and justify your position on limiting certain types of ICMP traffic. Make sure to test the rules you implement. How did you test them?
    2. Why does this architecture and it’s allowances for decoys and spoofed addresses make tracking the source of an attack such a difficult task?

  5. Network Intrusion Detection:

    1. Install Snort on your existing Linux server machine.
    2. Modify your snort.conf file to include the deleted.rules (which is on dastun.) and then test your IDS installation and analysis console by running the WuFTPD Remote Root Exploit against your internal Linux system from a remote host (Dominus). This will obviously fail since you’re not running a vulnerable version of Wu (you’re not even running Wu for your FTP server) but the IDS should detect the attempt anyway. Send in the output of snort for when you do this attack.
    3. It’s important to tune an IDS system so that it only detects attacks that are relevant to your particular network. Otherwise (among other problems), you may be generating so many false positives that it will be difficult to see any “real” scans or attacks. Tune snort by editing the snort.conf file to reflect your network and concerns (note the rules section in particular) and submit your tuned configuration. Briefly justify your inclusion or exclusion of each stock pre-processor. For now, disable the fragmentation pre-processor (you may re-enable it later).

  6. Optional

    1. Suppose you run a PHP-based website management utility on your IIS system through which an administrator can log in and update web-based content using the page “admin-edit-me.php”. Now suppose that all updating to this page is done from your internal network, except for when a legitimate remote administrator accesses it from his home system, which is over a VPN and will have a fixed address for our purpose. Write a rule that flags any attempt to access the admin-edit-me.php page from outside our network except for the legitimate administrator access. Why would we want to do this?
    2. Consider an inline active-response intrusion detection product (often called ‘Intrusion Prevention Systems’) that reconfigures your firewall rules to automatically block further connections from the attack source address for a certain period of time. Discuss the relative advantages and disadvantages of this approach and where/when it might be beneficial to employ such a technology.

  7. IDS Evasion

    1. Re-run the WuFTP exploit from Dominus (make sure those deleted rules are still in your config). But this time, use FragRouter on Dominus to fragment the traffic before it is sent to the destination host (your IDS). Snort should not detect the attack since the fragmentation pre-processor is currently not enabled. Include any results (FragRouter, etc) and a short description of how you accomplished this. Re-enable fragmentation detection in snort.conf and re-run the test. Again, include any and all output and commentary.
    2. Many NIDS products have difficulty with fragmented traffic due to the severe overheard it requires to reassemble packets in large quantities. If an IDS with a fragmentation pre-processor enabled were deployed inline to perform active inspection as above, and it is overloaded by more fragmented traffic than it can handle, is it more dangerous for the system to fail open or fail closed? Discuss.
    3. Since reassembly for an IDS is so taxing for large amounts of traffic, some IDS in the past have tried to save on reassembly costs by only examining the first fragment of every incoming connection (to obtain protocol header information). Is this a good strategy? Propose a way that an attacker could manipulate this to their advantage.
    4. Another basic method of misuse-based NIDS evasion is to modify existing attack traffic (most often buffer overflow payloads) so that it doesn’t match the unique signature used by the IDS for detection but still achieves the same effect on the end host it is intended for. Consider a web-based attack which exploits a known problem in a PHP script called ‘webxhelper.php’ that is by default installed in a certain web-server’s examples directory. If we know that an IDS has a signature to detect the string ‘examples/webxhelper.php?access=secret&user=default’, suggest three ways that an attacker might modify the exploit payload to bypass detection systems. HINT: one example would be URL-encoding (substituting characters in the URL with their hex-code equivalents). What are three others?

  8. Covert Channels

    1. Hackers often want to retain access to systems they have hacked even as new firewalls are installed to keep them out and vulnerabilities in existing services are patched. To accomplish this they often install backdoors and will try to disguise this traffic. Here we explore usage and detection of covert channels. THC’s Reverse WWW Shell is one example of a tool that could be used to hide shell traffic from firewalls. Install the tool, ssh to your account on Dominus and covertly access your “secret” shell using the tool in master mode. Describe how the tool works (try using a sniffer to examine the data in transit). How could you prevent this sort of traffic?
    2. This should have triggered an alert in your IDS, but it may have been rather non-specific or vague. Write a rule for Snort that is more specific, assuming that the string used in Reverse WWW Shell attempts is always orderform.cgi. Submit this rule as part of your homework, re-run part (a), and submit your detection results as well.

  9. Optional

    1. Discuss why you think it is difficult to write specific rules due to easily modifiable strings in exploit code and discuss other ways to detect the presence of vulnerabilities/ attacks/covert channels using NIDS.
    2. Propose another method of steganography that could be used to disguise shell traffic and discuss its merits in regards to firewall traversal.
Notes:
  1. Snort Needs PCRE.
  2. Snort can put it's data to a mysql DB. This was not done in this lab because of time issues. It is a bit of a bear to install with RedHat 9.0. But if are thinking about using Snort in the Final you may want to look into ACID.
  3. In order to configure the CISCO router you will probly need to use the console. For windows use HyperTerminal for Linux minicom
  4. If your router has a password already set read this in order to reset it
  5. Dominus is a dual booter. It will boot to windows or linux. if it is not on the OS you want then reboot it and choose which OS to run at the boot loader prompt.
  6. If you have a Cisco 2514 then you will need to use this Google cache of the routers info in addition to reset the password this link will help.