James Colley

IT443
LAB 6
29APR2018

1. Again I used my own machines for this lab. The laptop on the left is located at IP address
192.168.0.18 and will be acting as the server running Snort. The machine to the right will be
used to generate alarms. It’s IP address is 192.168.0.2. It’s also important to mention that
the server on the left is using a USB wifi adapter named wlx8416f91a27cd, and is not the
typical “eth0” or “eth1”. The network is 192.168.0.1/24:
After installing snort on the server (the one with the Windows XP background), very few
changes were necessary to get Snort to detect according to uncommented rules. The most
important change on snort.conf was defining the $HOME_NET variable. As previously
mentioned this variable is 192.168.0.1/24 and is visible in the highlighted text below:

2
Following the definition of the network address, the $EXTERNAL_NET was defined as “any”.
Besides these entries, no other changes were necessary except for commenting and
uncommenting rule definitions. The following command was issued before starting snort
each time, and was used to validate the configuration mainly in snort.conf:

“sudo snort -T -i wlx8416f91a27cd -c /etc/snort/snort.conf” was successfully validated

before each use (after altering the configuration file).

3
Before starting the rest of the lab, an initial test was performed to ensure snort could catch
ICMP pings from the client machine. First, all predefined rule-sets were commented out
with the exception of two rules for ICMP:

4
After verifying a proper snort configuration, the following command was executed to start
snort and have alerts printed to the console for easier testing:

Then on the client at 192.168.0.2, pings were sent to the server at 192.168.0.18:

Snort successfully alerts to the console that pings were received from 192.168.0.2:

5
2a. Two web attack signatures were used to test snorts capabilities. The snort.conf file was
once again edited on the server. Only one single rule-set was uncommented (Simple
Network Management Protocol):

After saving and validating snort.conf, snort was again restarted on the server. The
following command was issued on the client:

6
Snort successfully identified the port scan and printed the alert to standard-out:

The message is appropriate: “Classification: Attempted Information Leak”. NMAP is most

often used by attackers for reconnaissance (or administrators testing their own network). I
originally tried ICMP rules to register an alert for NMAP with no success. SNMP rules catch
the port-scan because an SNMP process is vulnerable to DDOS attacks via port 705
(Speedguide 1). The particular rule that triggers the alert is as follows:

alert tcp $EXTERNAL_NET any -> $HOME_NET 705 (msg:"SNMP AgentX/tcp request";
flow:stateless; reference:bugtraq,4088; reference:bugtraq,4089; reference:bugtraq,4132;
reference:cve,2002-0012; reference:cve,2002-0013; classtype:attempted-recon; sid:1421;
rev:11;)

The $EXTERNAL_NET is set to “any” and directed towards the $HOME_NET on port 705.
This is visible in the screenshot above. Since my machines $EXTERNAL_NET Is set to any,
alerts will also be triggered by machines that are on the same /24 CIDR/subnet mask of
255.255.255.0.

2b. The next test was an attempt to use a predefined rule to alert for DDOS attempts.
However it was not a community DDOS, DOS, or bad-traffic rule-set that triggered the alert.
Every single rule-set available in the “rules” directory was uncommented on snort.conf. The
“misc.rules” rule-set is the only one that triggered an alert. The following command was
used to start “hping” using spoofed IP addresses from the client:

7
And here are the alerts on the server coming from various spoofed IP addresses:

In order to catch this sort of attack it may be necessary to write a local rule or configure
“iptables” so that the attack is not possible. The main reason that snort cannot alert this
attack is most likely because it is coming from different IP addresses.

Therefore to test this theory, the following rule was defined on “local.rules”

The theory proved to be correct. Snort now alerts “Ping of Death!” as the message when
the attack is run again.

“track by_dst” (destination) as well as the count (set to 30) were necessary to get the rule to
work. The number of pings sent from the client was in the thousands.

8
3. The following rule will alert when a user on the server opens a web browser to any url
containing the word “google”:

In order to user “local.rules”, the following line was uncommented in snort.conf:

9
To confirm that the rule was working as intended, a web browser was opened that didn’t
use Google as a default search engine (to prevent false positive alarms in the address bar).
Several pages were visited and the alert only printed to the console when “google” was
found in the URL:

10
 Works Cited

SpeedGuide. “Port 705 Details.” SpeedGuide, www.speedguide.net/port.php?port=705.

Accessed 30 Apr. 2018.

11