###### tags: `finished`
:::success
# SSN Lab 6 - Intrusion Detection Systems / Intrusion Prevention Systems
**Author: Fige Polina**
:::

## Task 1 - Select IDS/IPS & Create topology

:::info
1. Select Snort, Suricata or Zeek as your IDS/IPS of your choice.
2. Create an small network of three VMs. 1 attacker, 1 Server and 1 as IDS/IPS. The remaining part of the topology is of your selection.
:::

<center>

Figure 1 - My topology
</center>

Okay, I found a good instruction for installing Snort and the basic rules, so I partially used it:
[Instruction from Wayne Uni ](http://webpages.eng.wayne.edu/~fy8421/17sp-csc4992/labs/lab8-instruction.pdf)

#### On SNORT Machine:

# Install DAQ archive
mkdir ~/snort_src
cd ~/snort_src
wget https://www.snort.org/downloads/snort/daq-2.0.7.tar.gz
tar -xvzf daq-2.0.7.tar.gz
cd daq-2.0.7
./configure && make && sudo make install

# Install Snort
cd ~/snort_src
wget https://www.snort.org/downloads/snort/snort-2.9.18.1.tar.gz
tar -xvzf snort-2.9.18.1.tar.gz
cd snort-2.9.18.1
./configure --enable-sourcefire && make && sudo make install

After that, we can run Snort:

snort -V

But I had some problems with the launch, so I had to install the necessary packages and check all the updates:

sudo apt update
sudo apt-get install -y libpcap-dev libpcre3-dev libdumbnet-dev bison flex zlib1g-dev build-essential liblzma-dev openssl libnetfilter-queue-dev gcc libluajit-5.1-dev libnghttp2-dev libdnet autoconf libtool libssl-dev make

And this rule configures the forwarding of traffic between the host interfaces, that is, it connects the Attacker and the Server directly:

echo 'net.ipv4.ip_forward = 1' >>/etc/sysctl.conf; sysctl -p

Now we need to create a group and a user:

sudo groupadd snort
sudo useradd snort -r -s /sbin/nologin -c SNORT_IDS -g snort

And create the necessary files and directories with the appropriate access rights and so on ([good example here](http://sublimerobots.com/2017/06/snort-ips-with-nfq-routing-on-ubuntu/)):

# Create the Snort directories:
sudo mkdir /etc/snort
sudo mkdir /etc/snort/rules
sudo mkdir /etc/snort/rules/iplists
sudo mkdir /etc/snort/preproc_rules
sudo mkdir /usr/local/lib/snort_dynamicrules
sudo mkdir /etc/snort/so_rules
 
# Create some files that stores rules and ip lists
sudo touch /etc/snort/rules/iplists/black_list.rules
sudo touch /etc/snort/rules/iplists/white_list.rules
sudo touch /etc/snort/rules/local.rules
sudo touch /etc/snort/sid-msg.map
 
# Create our logging directories:
sudo mkdir /var/log/snort
sudo mkdir /var/log/snort/archived_logs
 
# Adjust permissions:
sudo chmod -R 5775 /etc/snort
sudo chmod -R 5775 /var/log/snort
sudo chmod -R 5775 /var/log/snort/archived_logs
sudo chmod -R 5775 /etc/snort/so_rules
sudo chmod -R 5775 /usr/local/lib/snort_dynamicrules
 
# Change Ownership on folders:
sudo chown -R snort:snort /etc/snort
sudo chown -R snort:snort /var/log/snort
sudo chown -R snort:snort /usr/local/lib/snort_dynamicrules

We now need to move the following files from the extracted Snort tarball to the snort configuration folder:

cd ~/snort_src/snort-2.9.18.1/etc/
sudo cp *.conf* /etc/snort
sudo cp *.map /etc/snort
sudo cp *.dtd /etc/snort
 
cd ~/snort_src/snort-2.9.18.1/src/dynamic-preprocessors/build/usr/local/lib/snort_dynamicpreprocessor/
sudo cp * /usr/local/lib/snort_dynamicpreprocessor/

Disable all rule files:

sudo sed -i 's/include \$RULE\_PATH/#include \$RULE\_PATH/' /etc/snort/snort.conf

##### And now we can proceed to the configuration part:

Configuration file `/etc/snort/snort.conf`:

#Server subnet
ipvar HOME_NET 10.0.0.1/24
#External subnet
ipvar EXTERNAL_NET !$HOME_NET

<center>

Figure 2 - Snort.conf
</center>

Now we will need to give the variables a different form, because the path to them is now relative:

var RULE_PATH /etc/snort/rules              
var SO_RULE_PATH /etc/snort/so_rules
var PREPROC_RULE_PATH /etc/snort/preproc_rules
 
var WHITE_LIST_PATH /etc/snort/rules/iplists
var BLACK_LIST_PATH /etc/snort/rules/iplists

Enable the Local rules file:

include $RULE_PATH/local.rules

Now we need to configure Snort to use the NFQ DAQ an run inline mode, to enable the NFQ DAQ in inline mode we use follow lines:

config daq: nfq
config daq_mode: inline
config daq_var: queue=0

Configure iptables to pass all routed packets to this same numbered queue:

sudo iptables --append FORWARD --jump NFQUEUE --queue-num 0

## Task 2 - Install and configure IDS/IPS

:::info
1. Create a policy/rule to block all incoming ping packets.
:::

Let's open a file in the editor that will contain our local rules:

sudo nano /etc/snort/rules/local.rules

And we will add the following rule to it:

drop icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"PING detected"; sid:7; rev:1;)

This rule describes that we will block and log all **icmp** protocol packets coming from an external address and any port to any port and address of our server. The message displayed in the logs will contain the text "**PING detected**", and the rule ID will be **sid=7** (in fact, it is important only for us to quickly find the rule). The **rev** keyword is used to uniquely identify revisions of Snort rules.

:::info
2. Verify that newly created rule/policy can correclty detect and block incoming ping packets from attacker machine.
:::

To run Snort, use the command:

sudo snort -c /etc/snort/snort.conf -A console -Q

<center>

Figure 3 - ping 10.0.0.2
</center>

:::info
3. Write 5 more rules/policies of your own that can detect different attacks ( possible attacks).
4. Show the new 5 rules and explain how the attacks would work and how the rule/policy would be able to detect it.
5. Describe how you triggered the alert for all newly created rules.
6. Attach the alert itself for each given rule/policy to the report in readable text.
:::

**Rule 1: Detection of a Ping of death attack.**
The ping of death is a form of DoS attack that occurs when an attacker destabilizes servers by targeting them with oversized data packets.

alert ip $EXTERNAL_NET any -> $HOME_NET any (msg: "Ping of death detected";sid:1;dsize:>500;)

We will alert and register packages using the - **alert** action, protocol - **ip**. And we will warn about all packets coming to our server, the size of which exceeds 500 bytes.

To trigger the trigger, enter the command (Snort is already running):

ping 10.0.0.2 -s 1500 -f

We send packets whose size is 1500 bytes.

<center>

Figure 4 - Ping of death
</center>

**Rule 2: NMAP using.**
Nmap is used to discover hosts and services on a computer network by sending packets and analyzing the responses. I would like to prohibit the investigation of my server's ports.

alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"NMAP Port-Scanning"; dsize:0; sid:2;)

Sport will again send warnings and keep a record if it notices that empty packets (the size of which is zero) will come to any port of my host.

To invoke this rule, you must use nmap:

nmap 10.0.0.2

<center>

Figure 5 - NMAP port-scanning
</center>

**Rule 3: Possible DoS Web-Attack**

In order to prevent a DoS attack on a web server (port 80), we use the following rule:

drop tcp $EXTERNAL_NET any -> $HOME_NET 80 (flags: S; msg:"Possible DoS Web-Attack"; flow:stateless; detection_filter:track by_src, count 1700, seconds 30; sid:3;)

In this case, tcp traffic will be blocked and recorded in logs. Flag S means SYN-packets, keyword flow with stateless which means that this rule will apply without considering the state of the TCP, and the direction of the filter is from the source.

sudo hping3 --flood -S -p 80 10.0.0.2

<center>


Figure 6 - Possible DoS Web-Attack
</center>

**Rule 4: SlowLoris DoS attempt**

SlowLoris is a denial-of-service attack program which allows an attacker to overwhelm a targeted server by opening and maintaining many simultaneous HTTP connections between the attacker and the target. And it sends packets very slowly.

In order to implement this attack, I used the following rule:

alert tcp $EXTERNAL_NET any -> $HOME_NET $HTTP_PORTS (msg:"SlowLoris.py DoS attempt"; \
    flow:established,to_server,no_stream; content:"X-a:"; dsize:<15; \
    detection_filter:track by_dst, count 3, seconds 30; \
    classtype:denial-of-service; sid:1; rev:1; )

event_filter gen_id 1, sig_id 1, type limit, track by_src, count 1, seconds 5

SlowLoris establishes several connections up to the specified maximum number of sockets - 150. Each connection is supported by an incomplete HTTP request and adds an X-a header field. In this rule, we write that Snort should not pay attention to the stream itself, but should only check content with X-a headers already known to us, the length of which should be at least 15, since the SlowLoris packet header is about 11 bytes:
> flow:established,to_server,no_stream; content:"X-a:"; dsize:<15

The detection_filter options makes sure to only fire alerts if 3 or more occur from the same source within a 30-second window:
> detection_filter:track by_dst, count 3, seconds 30;

Added an event_filter to limit how many alerts fire once the detection_filter is reached

Let's deploy a small server on our SERVER machine:

sudo python -m http.server 80

And after that, let the hacker launch a SlowLoris attack:

slowloris -p 80 10.0.0.2

<center>

Figure 7 - SlowLoris
</center>

:::info
7. Create one rule/policy which would be triggered if a server vm / IDS/IPS vm would browse to microsoft.com website.
:::

To implement this rule, Snort will check the contents of tcp packets for the content of the form "microsoft.com":

alert tcp $HOME_NET any -> any any (msg:"Microsoft.com site detected"; content:"microsoft.com"; sid:13; rev:1;)

Checking this:

wget microsoft.com

<center>

Figure 8 - Rule for microsoft.com
</center>

## Task 3 - Answer the following questions

:::info
9. What is a zero-day attack?
:::

A zero-day attack is the use of a zero-day exploit to damage or steal data from a system that has a previously undetected vulnerability. One of the features of these attacks is that 0-day threats cannot be detected by classical antivirus technologies, that is, using a dictionary of viruses (signatures).
All new attacks are characterized initially as 0-day attacks.

:::info
10. Can IDS/IPS detect zero-day attack? if yes why? if no why?
:::

In short, my answer is yes. Since 0-day attacks exploit vulnerabilities previously unknown (or not publicly mentioned anywhere) to the creators of software/hardware, proactive protection systems can help identify non-standard activity in the system, regardless of whether it is internal or external. IPS/IDS cannot guarantee 100% protection against such attacks, but they are much more effective than reactive technologies, which are classic antiviruses.

:::info
11. Given a network that has 1 million connections daily where 0.1% are attacks. If the IDS has a true positive rate of 95% what false positive alarm rate do we need to achieve to ensure the probability of an attack, given an alarm is 95%?
:::


## Additional block:

<center>




</center>

### Some commands:

#for nat & nameservers:
sudo iptables -t nat -A POSTROUTING -o ens3 -j MASQUERADE