Securing Legacy Systems - JHUISI
This exercise demonstrates how Snort and similar inline intrusion detection / prevention systems can be used to help secure legacy software by walking them through an environment that includes an extremely insecure application.
Depending on their skill level students will be asked to analyze network the network traffic produced by this program, to write Snort rules to protect against known attacks against this program and to create a sample attack against this program which they will be asked to guard against.
The following information may be useful in completing this exercise.
When working in the field of network security it is not always possible to ensure the security of legacy applications. Many businesses and organizations use systems that are known to be highly insecure and will continue to do so for the foreseeable future as it would not be cost effective to replace or modify these programs. As such the best we can do to improve the security of these systems is to place them behind filters that can be controlled.
In this exercise you will be using Snort to help secure a highly insecure application without modifying the application itself. This application functions as a simple password protected file server for plain text documents, and it is up to you to use Snort to help protect this information.
This network is broken into three chunks. The first chunk contains the work environment which houses the legacy server along with a single client machine. This network is protected by the Snort router, which is set not to permit any traffic through at at the start of this exercise. The second network contains a single outsider machine. Finally
the third contains two client computers. All of these networks are connected to each other using a single router.
You should load the supplied topology file into the DETER testbed to create a new experiment. You can load this file directly in DeterLab's by selecting it using the path /share/education/SecuringLegacySystems_JHU/SecuringSystems.ns. Do not modify the topology file but read it through and identify what each directive does. This file includes links to scripts that configure Snort for later use which may prove useful in the future. It will take several minutes for the required configuration to be completed once DeterLabs has finished its initial setup, so please be patient.
Start Snort Without Rules
- Open an SSH client on your computer such as putty and connect to users.deterlab.net
- Login using your Deter username and password
- SSH into snort.[experiment name].[project name]
- Start snort without any rules by entering the command "sudo snort --daq nfq -Q -v". If you receive a warning about Snort not being installed wait two minutes and try again. If you continue to receive this message make sure that you logged into Snort machine rather than another node.
- You should see a large number of packets being reported by Snort.
- Open another terminal and SSH again into users.deterlab.net and then snort.[experiment name].[project name]. In this terminal run tcpdump to capture the data going to and from the client1. This should be on the interface with an IP Address in the 10.1.1.0 / 24 range. You can run tcpdump using the command sudo tcpdump -i [interface] -s 0 -w /tmp/dump.pcap
Allow this to run for 30 seconds and then tcpdump by pressing control + c. Let the Snort process continue running. Now run
sudo /share/education/SecuringLegacySystems_JHU/process.pl /tmp/dump.pcap This will produce a set of x,y coordinates where x is time and y is number of packets in that second.
- What happens to the traffic to client1 when Snort is not running?
- Is this a good thing?
- Based on Snort's output what can you say about the application? What port does it connect to?
- Please attach a graph of the traffic over time to your answers
- What does the "-Q" option do in Snort?
- What does the "--daq nfq" option do in Snort?
Analyze Network Traffic
- Connect to router.[experiment name].[project name]
- Use ifconfig to determine which network interfaces connect to which network.
- Run tcpdump to capture the data going to the server. This should be on the interface with an IP Address in the 10.0.1.0 / 24 range. You can run tcpdump using the command "sudo tcpdump -i [interface] -s 0 -w /tmp/dump.pcap"
- Let this run for around a minute before terminating it by pressing control + c.
- Copy this data to your computer via SCP and open it using Wireshark. You can use a tool like WinSCP to accomplish this.
- The request that the client sends the server is broken into four parts. What are these parts and what order does they appear in? How are these parts seperated in the request?
- Is this is a secure way for the client to send requests to the server? Explain your answer.
- Can you recover one of the files sent by the server to a client? If so attach the file, a pcap the relevant packets and indicate which client this was sent to.
Write Rules to Guard Against Simple Requests
- In that terminal where snort is running stop it by using ctrl + c.
- Use nano to write a configuration file for snort using the command, "nano snort.config"
- Add the following snort rule that prevents .xml files from being sent out,
reject tcp 220.127.116.11/16 ANY -> 18.104.22.168 [Port from Question 3] (msg: "XML Read Attempt Detected"; sid:1; content:".xml";)
- Using this rule as an example write a rule that prevents classified data from being sent to the outsider computer, but does not prevent it from being sent to any other computers.
- Make a directory for snort alerts using the command "mkdir alerts"
- Start snort using your new rule with the command, "sudo snort --daq nfq -Q -c snort.config -l alerts"
- Log onto client1, client2 and outsider to see if these rules worked. If you aren't sure go to the folder /home/test and delete the existing .txt and .xml files then see which ones are recreated. You can also run the program FileClient manually to find out.
- What rule did you use to secure the "classified" file?
- Capture and compare the network traffic for the serverwhen filtering these results using your configuration file and when no file is used. Attach the graph showing packet rate over time for both of these cases to your submission.
- Can you think of any others files or extensions that should be filtered against?
- Make sure you have your filtering rule engaged on Snort
- Using flooder tool on client1 create a packet flood attack against the server from. Set a high rate of 100,000 requests and duration of 100 seconds. Just typing flooder on command line should give you a list of options you can use.
- Create a new Snort configuration that also includes a rate filter rule. These follow the format, rate_filter gen_id 1, sig_id [sid of event], track [by_src, by_dst or by_rule], count [number of events], seconds [number of seconds], new_action drop, timeout [number of seconds]
- You may need to write a new rule for the rate filter to apply to
- Create an event filter for your rate filter. These follow the format, event_filter gen_id 1, sig_id [sid_number], track [by_src, by_dst or by_rule], count [number of events], seconds [number of seconds], type [limit, threshold or both]
- Collect the traffic at the server and the router when there is and is not an attack with rules in place that only guard against the attacks metioned in the basic exercises. Create a graph of this traffic over time.
- Repeat the previous step but now with the rate filtering rules enabled.
- For a DOS attack should rate filtering rules be paired with event filtering rules?
- Try changing the new action in the rate filter to "reject" instead of "drop". What does this do to the traffic and why do you think this is? Is this a good or a bad thing?
- Check which interface Snort connects to the router to using ifconfig. Once you have this information try the above test against while specifying that interface instead of using the default value. This argument will look something like --daq-var device=eth1. Did this change your results. If so attach a graph and explain the change occured.
- Are there any changes you can make outside of Snort to help guard against this attack? If so what are they?
- Try running the FileClient program from client2 while this attack is underway. What happens when you have the various rulesets configured?
Secure Traffic on the Network
- Make sure that Snort is running with all your filtering rules in place
- Review the pcap data you gathered while analyzing network traffic on the router.
- Review the network topology on DeterLab UI. Notice that the internal computer is able to bypass Snort entirely
- Verify this by logging onto the internal computer and checking the contents of the folder /home/test. You should see that it is able to freely download files that your rules do not permit.
- Replace the direct route to the server using the command sudo route add -host server gw snort
- This should cause traffic to the server to be routed through Snort. Perform a trace route to verify this with the command traceroute server
- Based on the traffic you analyzed what changes could be made to the network to enhance the security of communications coming from client1, client2 and outsider?
- What software packages would this require and where should these be installed? Would this cause problems for Snort?
- How should the server be configured to prevent internal attacks?
- Would this require you to change your Snort configuration in any way?
Code Execution Vulnerability
- A vulnerability was found with the FileServer that causes it to execute the contents of the filename field if certain conditions are met.
- Download the file /home/test/FileServer.jar from the server.
- Analyze the file using a Java decompiler such as JD-GUI to find the vulnerability.
- What are the conditions required for this attack to take place?
- Create a Snort rule to defend against this attack. You may want to be use pcre instead of content for this rule.
- What effect does this rule have on legitimate traffic?
Defend Against ASCII Encoding
- An additional "feature" was recently brought to the attention of the security team, the application has a limited ability to before ASCII decoding.
- This decoding is triggered whenever the server encounters a % followed by a number between 0 and 255 at which point the sequence is converted to a single ASCII character.
- Go to the directory /usr/local/snort-22.214.171.124/src/dynamic-examples/dynamic-preprocessor
- This contains an example Snort preprocessor. Snort preprocessors allow for advanced data manipulation to normalize data and perform other functions that normal rules cannot. All Snort preprocessors are coded in C.
- Open up spp_example.c and take a look at the structure. The main function of interest to you in this case is ExampleProcess which is used to process packet data before other rules have a chance to access it.
- Copy the include folder using the command sudo cp /usr/local/snort-126.96.36.199/src/dynamic-preprocessors/include/ ..
- You should now be able to compile and install this preprocessor using the command sudo make && sudo make install.
- Once this has been installed you can use this preprocessor in Snort. To do this edit your configuration file by adding the following lines at the top of the file which tell Snort to auto-generate the decoder rules so you don't have to, the location of the preprocessor library and the preprocessor you wish to use along with all of its arguments (in this case just the port to use):
dynamicpreprocessor directory /usr/local/lib/snort_dynamicpreprocessor/
preprocessor dynamic_example: port [Port from Question 3]
- Once you have made these changes try to run Snort using your configuration file. At this point it should behave exactly as before, but it now has a preprocessor loaded which you can edit to meet your needs as an ASCII decoder.
- Were you able to bypass your existing rules because of this feature? If so what input strings did you use?
- Can you think of a content rule to effectively defend against an attack that uses this feature? Would this affect legitimate traffic?
- Snort includes support for user written preprocessors that can render data for Snort's other rules. How would the use of a preprocessor help with this task?
- Write a preprocessor to help with this task. Please attach all of the functions you used and the snort.config file that called the preprocessor.
What can go wrong
- Experiment cannot be swapped in. First, check the error message you will receive in the email. One possible reason for this is that the NS file was changed from the one listed above. Verify that the file looks exactly like supplied with this exercise. Another reason may be that there is a lack of available nodes in DETER and the error message will say so. This happens occasionally and usually resources become available in a few hours. If you tried several times and could not find enough resources or could not diagnose why the experiment was not swapping in, forward the error message you get from DETER to your TA.
- Server Does Not Process Requests. If the server is rebooted you will need to start the server script manually. This can be found in the folder /home/test.
- Nodes Cannot Communicate with Server If the server or route cannot communicate with each other when Snort running, make sure that the routing table is correct. You can check the routing table with the command "route" on both of the computers.
You should submit a document with the following items (label each section):
- An explanation of how Snort can be used to protect legacy systems
- Screenshots that show how you executed these commands
- The contents of all scripts, commands and Snort rules you wrote to solve these challenges
- Answers the questions found within each section