Intrusion Detection and Prevention
In this practical activity, you will apply countermeasures to detect intrusion and filter network traffic.
Prerequisite Knowledge: Basic networking knowledge; Linux commands; Network Traffic AnalysisSnort rules are divided into two logical sections, the rule header and the rule options.
rule header (rule options)
Example:alert tcp any any -> 192.168.1.0/24 80 (msg:"Possible web attack"; content:"GET"; nocase; sid:1000001; rev:1;)
Rule Header: The rule header defines the action, protocol, source IP/port, destination IP/port, and direction as shown in the table below:
| Component | Description | Example |
|---|---|---|
| Action | Specifies what Snort should do when the rule matches. Common actions include alert, log, pass, drop. |
alert |
| Protocol | Defines the protocol for matching packets. Supported protocols are TCP, UDP, ICMP, and IP. |
tcp |
| Source IP | Specifies the source IP address or network of the packet. Use any for any IP or specify a subnet with CIDR notation. |
192.168.1.0/24 or any |
| Source Port | Defines the source port of the packet. Use any for any port or specify a range. |
80, any |
| Direction | Indicates the packet flow direction. Use -> for one-way or <-> for bidirectional traffic. |
-> |
| Destination IP | Specifies the destination IP address or network of the packet. | any or 10.0.0.0/8 |
| Destination Port | Defines the destination port. | 80 |
Rule Header Action: Common Actions
| Action | Description |
|---|---|
| alert | Generates an alert when the rule matches and logs the packet details. |
| log | Logs the packet details without generating an alert. |
| pass | Ignores the packet and takes no further action when the rule matches. |
| drop | Drops the packet without sending it to the recipient. Only available in inline mode. |
| reject | Rejects the packet and sends a reset to the sender, indicating the connection is closed. Only for inline mode. |
Rule Options: The rule options specify the conditions under which the rule will trigger. Each option is enclosed in parentheses and separated by a semicolon. Here are some common options:
| Option | Description | Example |
|---|---|---|
| msg | Specifies the message that will appear in the alert when the rule is triggered. | msg:"Possible web attack"; |
| content | Searches for specific data in the packet payload. It can be combined with other modifiers like nocase to make it case-insensitive. |
content:"GET"; nocase; |
| sid | A unique identifier for the rule. Use SIDs above 1000000 for custom rules. | sid:1000001; |
| rev | The revision number for the rule, used for versioning. | rev:1; |
| flags | Checks for specific TCP flags like SYN, ACK, FIN, etc., to filter traffic. | flags:S; |
| depth | Specifies how far into the packet to search for the content keyword. |
depth:4; |
| offset | Sets the starting point in the packet payload to begin the content search. |
offset:10; |
| ttl | Filters packets based on Time To Live (TTL) values. | ttl:64; |
| flow | Indicates the direction of the traffic flow, e.g., to_server or to_client. |
flow:to_server; |
| pcre | Performs a regular expression search on the packet payload, allowing for more complex pattern matching. | pcre:"/^GET\s/"; |
In this activity, you will install and configure Snort IDS.
If you want to avoid using sudo for commands the require root permissions, you can use the sudo su command
gedit is an open-source user-friendly text editor that can make editing configuration files a litte less intimidating
Did you notice that when we used sudo su, there was a delay? This is because I intentionally did not change the hostname in the /etc/hosts file. Let's fix this
Changing hostname is done in two files /etc/hostname and /etc/hosts
Use your network address, not mine!
Snort comes with a set of community rules. However, we want to create our own rules and disable all other rules to be able to observe our rules in action without interference.
Next, we want to configure the output logs:
Log Files
You should receive a message saying that Snort successfully validated the configuration. If not, go back to snort.conf and fix the reported error.
Snort successfully validated the configuration!
Snort exiting
In this activity, you will create your own Snort rules and test these rules by running Snort as an IDS.
Figure: Snort Rules Syntax
On a new line at the end of the local.rules file, we will add the following rules:
The ICMP rule in the local.rules file
Now, let's test rule by running snort and generating ICMP traffic:
To make generating traffic and testing more interesting, let us install some servers on our VM
Let's write more custom rules in the local.rules file. When done, save and test:
While Snort is running, generate the necessary traffic (from Kali) for each rule. Every time you generate the traffic below, go back to HawkEye and observe the console.
Use alternative methods to generate SSH, FTP, and Telnet traffic and show your instructor
All our custom Snort rules
Our custom rules should kick in, and as soon as the relevant packet is detected, Snort should display our custom messages. All the test traffic we generated above was directed to the HawkEye VM where Snort is installed. However, in all our rules, we specified any [IP address] within our local network (HOME_NET). So the question is, will Snort detect rule traffic if directed to Metasploitable? Let's test it.
Our Snort rules should be triggered, but why? Snort IDS can detect traffic going to other machines in the same network, but only under certain conditions. In real life, Snort must be installed on a machine that has access to the traffic of the devices you want to monitor. This typically involves connecting Snort to a network tap, port mirror (SPAN port) on a switch, or using it in a network segment where it can see all traffic. In our virtual lab environment, Snort is operating in Promiscuous Mode, which allows the network interface to capture all packets on the local network segment, not just those addressed to the Snort machine. We enabled Promiscuous Mode when we used the -i (interface option).
| Concept | Description |
|---|---|
| Packet Filtering | iptables inspects packets as they pass through the network stack, deciding whether to allow or block traffic based on predefined rules. |
| Rules and Chains |
Rules: Each rule specifies criteria for matching packets, such as IP, port, and protocol. Chains: Chains are lists of rules that a packet will traverse in a specific order. Common chains include:
|
| Tables |
iptables organizes rules into tables, each serving a different purpose:
|
| Targets |
The target determines what action iptables will take on packets that match a rule. Common targets include:
|
| Option | Description |
|---|---|
| -L | lists all the rules for a specified chain (e.g., INPUT, FORWARD, OUTPUT). If no chain is specified, it lists rules for all chains in the current table. Examples: iptables -L iptables -L INPUT iptables -L | grep policy |
| -A | Appends the iptables rule to the end of the specified chain. Examples: iptables -A INPUT iptables -A OUTPUT |
| -D | Deletes a rule in a particular chain by number |
| -F | Flushes the selected chain, deletes every rule in the the chain |
| -P | Sets the default policy for the specified chain |
| -j | Jumps to the specified target when a packet matches a particular rule |
| -p | Sets the IP protocol for the rule, which can be either icmp, tcp, udp, or all |
| --dport | Sets the destination port for the packet |
| -s | Sets the source for a particular packet |
Common iptables Options
In this activity, you will use Linux's iptables as a firewall to allow, filter, and log network traffic.
Notice that the default for all chains (INPUT | OUTPUT | FORWARD) is ACCEPT. Let's change the INPUT policy to DROP (i.e., DROP all incoming traffic).
Notice that HawkEye was not detected! Why? Because all incoming traffic was blocked. As you can see, although the HawEye machine is on and in the network, we couldn't detect it. If you recall, we learned some countermeasures to trick firewalls. Let's repeat with -sF option
With the -sF option, nmap will be able to detect HawkEye as a 'filtered' host.
The policy we applied to drop all incoming traffic allows to implement what important security principle? Think about it, and if in class, share your answer. Hint: With this strict policy in place, we can then make exceptions, by allowing traffic incoming to a specific service (e.g., HTTP traffic). For now, let's go ahead and reverse the DROP all policy for the INPUT chain, and apply some new rules.
Let's test the rules we defined.
Next, we want to backup the rules, we created in a file. We can then use this file to restore our rules.
Next, we want to delete rules. To delte a rule, we need the -D option along with the chain (INPUT, OUTPUT, etc.) and the rule number (in order)
Next, we want to use the backup file rules.bak to restore what we just deleted.
In the next section, we want to use iptables by following common practice. We will apply the Least Privilege Principle (it was the answer to the question above), and then make exceptions for our HTTP, SSH, and FTP traffic.
In the test above, we performed a TCP scan on 4 ports. The 3 with exceptions, are shown as open. While Telnet (port 23) is shown as filtered. In the future, if you install a new server, the port will be filtered because of our policy rule. A new exception would need to be added.
Least Pivilege Final Outcome