Lab 10: IDPS - Snort & Cisco IDPS Sensors: 9.1 Details
Lab 10: IDPS - Snort & Cisco IDPS Sensors: 9.1 Details
Lab 10: IDPS - Snort & Cisco IDPS Sensors: 9.1 Details
9.1 Details
Aim: The aim of this lab is to investigate IDPS Sensors, using the open source Snort IDS Sensor
software and the Cisco IPS software running on a ASA firewall device, and centralised
logging and monitoring.
9.2 Activities
9.2.1 Create Virtual Topology
Connect to our vSphere virtual environment at vc2003.napier.ac.uk using a vSphere Client.
Navigate to the Module folder such as VMs & Templates>Production>CSN11111/8. You will be
assigned a group folder to work with which contains the VMs needed for the lab (check Moodle for
the Groups and IP Addressing for each Group). Lab VMs: Windows7 VM running GNS3, a
Windows2003 VM and 2 Linux Ubuntu VMs running network services.
Power on your Windows7-GNS3 VM, open a console window, login to the Windows7-GNS3 VM, and
run the GNS3 network simulator AS ADMINISTRATOR
You can create a new project for Lab10, or a preconfigured starting project should be in the Projects
folder. If you wish to start with that just click Recent Projects button and select lab10_start, then
save as a project called lab10 or suchlike (save as, before you power on devices).
The topology mimics an organisation with an ASA firewall at its perimeter. It is connected via the
untrusted Internet via the 10.1.Y.0/24 network, the inside trusted user network 192.168.X.0/24, and
the DMZ network 192.168.Z.0/24. A Management network 192.168.MGT.0/24 is also attached
directly to the ASA with a logging server.
If using a standalone topology, make sure Snort is installed on your Linux DMZ Server machine,
before you attach it. To install Snort onto a standalone Linux VM, Appendix A can be used as a
guide.
THE CORRECT NETWORKS MUST BE USED BY EACH STUDENT AS WE ARE SHARING VIRTUAL
NETWORKS. ANNOTATE YOUR DIAGRAM/TAKE NOTE OF THE ADDRESS RANGES FOR YOUR GRP.
PLEASE ONLY USE GROUP VMs AND NETWORK IP ADDRESSES ASSIGNED TO YOUR GROUP.
PLEASE DO NOT USE YOUR OWN IP ADDRESSES OR THE LAB DEMO ADDRESSES IN THIS
DOCUMENT!
The following document has a section on setting the Windows IP and default gateway:
www.dcs.napier.ac.uk/~cs342/CSN11111/GNSAddVM.pdf
Set up the inside interface, which is connected to the trusted internal network:
ciscoasa(config)# interface gigabitEthernet 1
ciscoasa(config-if)# nameif inside
INFO: Security level for "inside" set to 100 by default.
ciscoasa(config-if)# security-level 90
ciscoasa(config-if)# ip address 192.168.X.254 255.255.255.0
ciscoasa(config-if)# mac-address 000p.pppp.qq01
ciscoasa(config-if)# no shutdown
Set up the management network interface, which is connected to the trusted internal network:
ciscoasa(config)# interface gigabitEthernet 3
ciscoasa(config-if)# nameif mgt
ciscoasa(config-if)# security-level 100
ciscoasa(config-if)# ip address 192.168.MGT.254 255.255.255.0
ciscoasa(config-if)# mac-address 000p.pppp.qq03
ciscoasa(config-if)# no shutdown
Annotate your diagram/notes with the security trust levels for each interface/connected network.
Review your configuration of the interfaces are configured, using show ip address, show
interface ip brief, and show interface and show run commands.
Remember to save your firewall configuration regularly using copy run start, and file>save
Q: Why did we set the security level on the inside interface differently to the default?
Check connectivity, to all the interfaces on the ASA, from each of the DMZ VM and the Inside
network VM.
For more information on Snort, the manual and FAQ can be found at:
http://www.snort.org/docs
On the DMZ Linux Server VM, review the Snort IDS sensor options:
napier@ubuntu:~$ sudo snort –h | less
Running in this mode, Snort will sniff all traffic and log every packet to the console (std out) just like
a packet sniffer such as tcpdump.
The arguments –d –e –v (-dev) mean Snort output will read and display the IP (Layer3),
TCP/UDP/ICMP (Layer4) headers, and the packets data (Layer7).
(Use CTRL+C to stop the Snort Sensor running)
If using a shared network, we can use capture filters (same as tcpdump format) to only sniff traffic
addressed to our DMZ server:
napier@ubuntu:~$ sudo snort –i eth0 –dev –p host 192.168.Y.10
To generate test traffic for the Snort IDS to report on, ping the DMZ VM from the ASA firewall, and
the ICMP traffic should be displayed, as shown below.
Q: Find a GET packet. Review the L2 and L3 addresses and L4 ports/TCP flags. Which 2 devices are
the L3 addresses from?
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Src MAC Dest MAC
Scroll back up to the Snort output, to the ICMP packets, and complete the following for one of the
packets:
Q. The source IP address?
Q. The protocol?
Q. The first few bytes of the ICMP packets payload (the HEX/ASCII):
Q. Which of these could the ASA firewall NOT filter traffic on? (using ACLs)
Run Snort again and ping the Linux VM from the Inside Network VM.
Scroll back up to the Snort output in the console window, showing the ICMP packets, and complete
the following for one of the packets:
Q. The protocol?
Q. The first few bytes of the ICMP packets payload (HEX values):
Q. What is different from the ping packets sent from the Cisco ASA?
The traffic should be similar to shown below, and the firewall would not be able to determine this
application layer packet payload difference.
Logs
To create some signatures/rules for the Snort sensor to match against network traffic, create a text
file called snort_sigs using a text an editor such as vim or gedit:
napier@ubuntu:~$ sudo vi snort_sigs
And create the following Snort Detection Rule in the file, (Which contains the Detection Signature
“"#$%&'()” for ICMP traffic from/to any Ip address).
alert icmp any any -> any any (content: "#$%&'()"; msg:"ICMP packet from a Linux
System"; sid:1000;)
The signature we have created generates an alert for ICMP traffic containing the payload “abcdef”.
An alarm is raised locally as an entry in an alerts file, and/or sent to a central monitoring console,
when it matches a packet in the traffic being monitored. Snort rules can also perform the log action,
which will not raise an alarm, but only log details to the local sensors log files and/or a central
logging server.
Run the Snort IDS Sensor software to use the detection signatures file detect_sigs as input, and
the log directory snort_logs to write the output to, using a command similar to:
napier@ubuntu:~$ sudo snort –dev –i eth0 –p –K ascii –c snort_sigs –l snort_logs
Snort should now write IDS alerts and log data for packets matching the signatures in the
snort_sigs file, to the snort_logs directory. The alerts are written to the snort_logs/alert file.
Snort is now running as an IDS Sensor, and no longer only as a packet sniffer.
Check the files which have been created in the snort logging directory. In open a second terminal
window on the Linux VM try:
napier@ubuntu:~$ ls –l snort_logs/
To monitor the alerts being generated by the Snort IDS Sensor The output file can be checked for
any lines being appended to it using the tail command, as shown below.
napier@ubuntu:~$ sudo tail -f snort_logs/alert
To test the detection signature, ping the Linux VM from the ASA firewall.
Q. Are any alerts raised? Why?
Now ping the DMZ VM from the Inside VM with 4 ICMP packets.
Q. Are any Linux ICMP packets detected/alerts raised?
The output from the tail command should look something like the following.
Stop the Snort sensor and add a 2nd snort detection rule to the snort_sigs file, to alert for a ping
from a Cisco device. For the 2nd rule use a new Signature ID parameter value such as SID:1001.
The Detection Signature should look for the hex values. In Snort a signature to match Hex values can
be created using content:“|hexvalue|”.
To test the detection signature, first remove the alerts file, to remove alerts raised before:
Then to test, from the ASA firewall ping the Linux VM.
Q. Are any packets detected, and the alerts raised?
Q. Review the Snort rules. Which parts of the packets, with reference to the layers of the OSI
network model do the various parts of the rule apply to?
include /etc/snort/classification.config
alert icmp any any -> any any (content:" #$%&'()"; msg:"ICMP packet from a Linux
System"; sid:1000;)
alert icmp any any -> any any (content:"|ABCDABCD|"; msg:"ICMP packet from a
Cisco Device"; sid:1001;)
include $RULE_DIR/icmp-info.rules
include $RULE_DIR/icmp.rules
This will match traffic against our rules, and also the snort built in rules in the icmp.rules and icmp-
info.rules files. Run the snort sensor the same way as before, and monitor the alerts with the tail
command:
napier@ubuntu:~$ sudo snort –dev –i eth0 –p –K ascii –c snort_sigs –l snort_logs
napier@ubuntu:~$ sudo tail -f snort_logs/alert
To test the ICMP rules, try a traceroute using the Windows tracert tool from the MGT Windows VM
to the DMZ server.
Q. Does the ASA allow the traceroute information back to the Mgt VM?
The built in community Snort rules can be found in the /etc/snort/rules directory:
napier@ubuntu:~$ cd /etc/snort/rules
napier@ubuntu:/etc/snort/rules:~$ ls
To find a specific rule which has produced an alert and its associated detection signature, the grep
command can be used to filter the files, for lines containing the SID of the rule displayed in the alert.
napier@ubuntu:/etc/snort/rules:~$ grep sid:rulesid *
Q. Has the Snort sensor blocked the potential ICMP attack packets? Why?
The IDS Sensor cannot drop the packets, or reset the connection. It only monitors the packets, which
still go on the destination.
The Snort rule files can be customised, and many more rules can be downloaded from the Internet.
Use the grep command to find the rule which was fired to generate the oversized ICMP alert.
Q. Which rule file is it from?
To check Snort is running, list the running processes using the ps command and pipe this to the
grep command to match any lines containing the word snort.
napier@ubuntu:~$ ps -ef | grep snort
To kill the process use the following (making very sure you use the correct process id)
napier@ubuntu:~$ sudo kill -9 processid (4747 in the above example)
Once installed, run the console for the syslog server. It should look something like the following.
The trial version can receive alerts/log messages from up to 5 IP addresses. Configure to receive
messages from the ASA, via File>Setup>Inputs and enter the ASA interface IP address:
Q. How many different logging severity levels are there? Which level did we set the logging to?
Apply the IPS sensor policy to the inside interface on the firewall, using:
ciscoasa(config)# ip audit interface inside INFO_POLICY
The signatures and the number of matched packets can be displayed using:
ciscoasa(config)# show ip audit count
Q. What is the fundamental difference between this and the Snort IDS Sensor used earlier?
On the ASA, check for any IPS signatures matches, using the ip audit count command
Q. Which informational signature match counts have been incremented?
Number Type Description Count
Run your snort IDS sensor, and use tail to monitor the alert file, as described before.
From the Inside VM, use the nmap network scanner to send host discovery packets to the DMZ VM,
mimicking an insider performing reconnaissance on the network (but not any port scanning packets).
nmap –sP –n 192.168.Z.10
Q. Can you see any relevant alerts on the syslog console? Which ASA IPS signature IDs?
Q. Which type of packets go through to the DMZ server and are reported at the Snort console?
The ASA IPS should alert on, and drop the ICMP packets sent by nmap. (The ASA also drops the and
HTTP ACK packet as its not part of a valid TCP session)
From the Mgt VM, try the same nmap host scan to the DMZ server:
nmap –sP –n 192.168.Z.10
Q. Can you see any relevant alerts on the syslog console? Why not?
All of the ICMP-based packets should be reported. None are dropped as the ASA IPS signatures are
only being matched against traffic on the inside interface, not the mgt interface.
Q. Can you see any relevant alerts on the syslog console? Which ASA IPS signature IDs?
Centralised IDPS management and monitoring consoles typically provide advanced statistics,
reporting and even visualisations. Some reporting and statistics can be displayed from our basic
syslog server console using View>View Syslog Statistics:
From the Inside VM Port Scan a range of ports on the DMZ VM, using a NULL Scan, and then a FIN
scan:
sudo nmap –sN –n –p1-100 192.168.Z.254
sudo nmap –sF –n –p1-100 192.168.Z.254
Q. Can you see any relevant alerts on the syslog console? Which ASA IPS signature IDs?
Select VMNet0 which should be auto-bridged, and select the physical network interface, as
shown below.
To check the setting of your host machine use ipconfig /all from a console window as shown below.
This should show the default gateway, and the DNS server.
Then set the DNS server by editing the /etc/resolv.conf file, and adding the DNS server value
found above:
napier@ubuntu:~$ sudo vi /etc/resolv.conf
Check that the IP address has been set correctly, use the ifconfig command.
On the Linux VM, check the interfaces available before you install Snort. In this case the interface we
will configure Snort for, is eth2, as shown below.
napier@ubuntu:~$ ifconfig
eth1 Link encap:Ethernet HWaddr 00:0c:29:0d:50:93
inet addr:192.168.1.3 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::20c:29ff:fe0d:5093/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:3199 errors:0 dropped:0 overruns:0 frame:0
TX packets:1687 errors:0 dropped:0 overruns:0 carrier:0
Enter the correct interface for Snort to listen on, and select OK using the <TAB> key, as shown.
You may have to select an IP Address range for the Home Trusted Network. This should be the GNS
topology home network, as shown below.
Run Snort to check it has been installed correctly, using the following command. ( CTRL+C to exit)