Lab 10: IDPS – Snort & Cisco IDPS Sensors

Rich Macfarlane 2015

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.

Lab Starting Topology

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.

Network Security IDPS – Rich Macfarlane 1

You will be assigned networks to address the hosts and ASA gateway interfaces to – from Moodle:
10.1.Y.0/24, 192.168.X.0/24, 192.168.Z.0/24, and 192.168.MGT.0/24

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!

9.2.2 Configure the Hosts

Power on your Linux Ubuntu_205/202 VMs and Windows2003_205 VM. Configure the network IP
Addresses, and set the Default Gateways to the ASA interface addresses at.254.
To configure the Linux system for IP Address and Default Gateway:
https://help.ubuntu.com/community/NetworkConfigurationCommandLine/Automatic

The following document has a section on setting the Windows IP and default gateway:
www.dcs.napier.ac.uk/~cs342/CSN11111/GNSAddVM.pdf

(Section: Windows-Setting Static IP Address and Default Gateway)

9.2.3 Basic ASA Configuration & Connectivity

Configure the Interfaces
Certain attributes must be set on the interfaces, and then the default security behaviour can be
observed.
Set up the outside interface, which is connected to the internet, using the following commands.
ciscoasa(config)# interface gigabitEthernet 0
ciscoasa(config-if)# nameif outside
INFO: Security level for "outside" set to 0 by default.
ciscoasa(config-if)# ip address 10.1.Y.254 255.255.255.0
Additionally configure the MAC Address on the interfaces with the following command, using
the format <ca0 module code grpno 0 intno> such as the following for module csn11118
group 99:
ciscoasa(config-if)# mac-address 0001.1118.9900
ciscoasa(config-if)# no shutdown

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 DMZ interface, which is connected to the DMZ network:

ciscoasa(config)# interface gigaEthernet 2
ciscoasa(config-if)# nameif dmz
ciscoasa(config-if)# security-level 50
ciscoasa(config-if)# ip address 192.168.Z.254 255.255.255.0

Network Security IDPS – Rich Macfarlane 2

 ciscoasa(config-if)# mac-address 000p.pppp.qq02
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.

Q: Which command best allows us to review our nameif configuration?

Q: Which command best allows us to review our mac-address configurations?

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?

9.2.4 Test connectivity

From the firewall, ping each local interface, and each of the attached VM’s interfaces in turn to test
the interfaces are up and connectivity to the VMs:

Network Security IDPS – Rich Macfarlane 3

Questions

Q: Where the pings to the firewall interfaces successful?

Q: Where the pings to the directly connected VM’s successful?

If not, troubleshoot the configuration, until connectivity is achieved.

Check connectivity, to all the interfaces on the ASA, from each of the DMZ VM and the Inside
network VM.

Q: Where all the pings to the firewall interfaces successful?

If not, troubleshoot the configuration, until connectivity is achieved.

9.2.5 Snort IDS Sensor running on the DMZ Host

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

Snort IDS Sensors can be run in various modes:

1. Basic Packet Sniffer (similar to tshark or tcpdump)
2. Network Intrusion Detection System (NIDS)
3. Network Intrusion Prevention System (NIPS)
Run the Snort IDS Sensor as a basic packet sniffer, reading packets from the DMZ server’s Ethernet
interface (eth0 in the example below) using a command such as the below.
napier@ubuntu:~$ sudo snort –i eth0 –dev -p

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.

Network Security IDPS – Rich Macfarlane 4

Try connecting to the web server on the DMZ from the inside host. Stop the capture with CTRL+C
and scroll up through the Snort output in the console window to find the web traffic.
Q: Can you see the web traffic?

Q: Find a GET packet. Review the L2 and L3 addresses and L4 ports/TCP flags. Which 2 devices are
the L3 addresses from?

Q: Which two systems/devices do the L2 addresses belong to?

Q: Which other part of the packet does the HEX/ASCII?

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Src MAC Dest MAC

01/12-11:11:07.410133 0:15:0:34:2:F0 -> 0:C:41:F5:23:D5 type:0x800 len:0x19A

192.168.1.101:2735 -> 146.176.1.188:80 TCP TTL:128 TOS:0x0 ID:13141 IpLen:20 D
Len:396 DF
***AP*** Seq: 0xCEDC79A8 Ack: 0xE2431ED3 Win: 0x4037 TcpLen: 20
Src47
IP 45 54Src
20TCP
2FPort
68 6F 6D 65 5F 6E 65 77 2F 69 6D GET /home_new/im HTTP
61 67 65 73 2F 70 72 6F 67 5F 66 32 2E 67 69 66 ages/prog_f2.gif
20 48 54Port
54 50 2F 31 2E 31 0D 0A 41 63 63 65 70 HTTP/1.1..Accep Payload
74 3A 20 2A 2F 2A 0D 0A 52 65 66 65 72 65 72 3A t: */*..Referer:
20 68 74 74 70 3A 2F 2F 77 77 77 2E 6E 61 70 69 http://www.napi
65 72 2E 61 63 2E 75 6B 2F 0D 0A 41 63 63 65 70 er.ac.uk/..Accep
74 2D 4C 61 6E 67Dest75 IP61 67 65Dest
3ATCP
20 65 6E 2D Dest
67 IPt-Language: en-g
62 0D 0A 41 63 63 65 70 74 2DPort 45Port
6E 63 6F 64 69 b..Accept-Encodi
6E 67 3A 20 67 7A 69 70 2C 20 64 65 66 6C 61 74 ng: gzip, deflat
65 0D 0A 55 73 65 72 2D 41 67 65 6E 74 3A 20 4D e..User-Agent: M
6F 7A 69 6C 6C 61 2F 34 2E 30 20 28 63 6F 6D 70 ozilla/4.0 (comp

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 destination IP address?

Q. The protocol?

Q. The ICMP type?

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)

Network Security IDPS – Rich Macfarlane 5

Scroll back down to the Packets Detected Totals, and complete the following:
Q. Received Packets Total?

Q. IPv4 Packets Total?

Q. ICMP Packets Total?

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 ICMP type?

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?

Q. Could firewall rules be written to detect the difference?

The traffic should be similar to shown below, and the firewall would not be able to determine this
application layer packet payload difference.

9.2.6 Create Snort IDS Signatures

Snort is a signature-based IDS. The signatures are part of ‘snort rules’ which are read by the Snort
sensor and used to match against network traffic and define actions taken by the sensor.

Network Security IDPS – Rich Macfarlane 6

 Network Traffic Snort Sensor

Logs

Decoder & Detection Logging &

Preprocessors Engine Alerting Alerts
Rules

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 format of Snort Detection Rules are as follows:

action protocol src-ip src-port > dest-ip dest-port (packet-payload-params output-msg)

[alert|pass|log] [ip|icmp|tcp|udp] [any|IP] [any|port] > [any|IP] [any|port]

([content:“searchstring”;], [nocase;], [msg:”alert message”;] sid:ruleid;)

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.

Test the Signature

Use the following command to create a directory for the Snort IDS sensor to send its alerts and log
data to.
napier@ubuntu:~$ sudo mkdir snort_logs

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/

Q. Which files have been created? What size are they?

Network Security IDPS – Rich Macfarlane 7

Check if any alerts have been raised:
napier@ubuntu:~$ cat snort_logs/alert

Q. Have any alerts been written to the file?

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?

Q. What are the source IP addresses?

Q. What are the destination IP addresses?

Q. Which ICMP types?

Q. How many alerts have been generated in total?

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:

Network Security IDPS – Rich Macfarlane 8

 napier@ubuntu:~$ sudo rm snort_logs/alert

Then to test, from the ASA firewall ping the Linux VM.
Q. Are any packets detected, and the alerts raised?

Q. What is the detection signature part of the rule?

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?

9.2.7 Using Snorts built in Signatures

To use some of snorts built in rules/signatures, edit your detection rules file snort_sigs, so it is
similar to the file shown below.
var EXTERNAL_NET any
var HOME_NET any
var RULE_DIR /etc/snort/rules/

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?

Q. Are any alerts detected?

Q. What Snort Classifications are reported?

Network Security IDPS – Rich Macfarlane 9

The alerts should look similar to the following:

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 *

Malformed ICMP Packet Attack

Mimic a Ping of Death ‘style’ DoS attack on the DMZ Server (using malformed/oversized ICMP
packet).
While the Snort sensor is running, and you are monitoring the output dir/alerts file, use the
extended ping utility on the ASA firewall to send oversize packets to the Linux Server VM:

Network Security IDPS – Rich Macfarlane 10

Q. Has the Snort IDS sensor generated any alerts?

Q. What is the Snort Classification?

Q. Has the Snort sensor blocked the potential ICMP attack packets? Why?

The alert should look like the following:

The packet logged by Snort should look similar to:

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?

Q. What is the Snort Classification?

Q. What is the revision number?

Running Snort Sensor as a Background Process

The -D option runs snort as a Linux Daemon. This runs the sensor as a background process, which is
useful if you don’t want Snort to log to the console.

Network Security IDPS – Rich Macfarlane 11

 napier@ubuntu:~$ sudo snort –D –dev –i eth0 –p –K ascii –c snort_sigs –l
snort_logs

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

root 4747 1 0 09:28 ? 00:00:00 snort -D -ieth2 -c detect_sigs -dev

napier 4787 4573 0 09:36 pts/0 00:00:00 grep --color=auto snort
napier@ubuntu:~$

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)

9.2.1 ASA Firewall Device – Logging to Central Syslog Server

Setup a Central Syslog server on Mgt Network
A syslog server should be installed on your VM server connected to the management network. This
will be used to log alerts/log data to.
For standalone configurations syslog server software can be downloaded from:
http://www.kiwisyslog.com/free-edition.aspx

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:

Network Security IDPS – Rich Macfarlane 12

In Inputs>UDP and Inputs>TCP, check which protocols/ports are being listened on.
Q. Which Protocol/Ports are the Syslog service listening on?

Check this with the netstat command.

Q. What is the netstat command to display the listener, protocol and the port number?

Configure the ASA for Logging Messages to the Syslog Server

Switch on syslog logging and configure the ASA to log centrally to the syslog server on the
management network, using the following.
ciscoasa(config)# logging enable
ciscoasa(config)# logging host mgt 192.168.MGT.5
ciscoasa(config)# logging trap ?
…
ciscoasa(config)# logging trap informational

Q. How many different logging severity levels are there? Which level did we set the logging to?

Q. Why might this not be appropriate in a production setup?

Test the Syslog Server

Check the syslog server is receiving messages. Ping the ASA DMZ interface address 192.168.Z.254
from the DMZ VM. The syslog server should receive and display messages such as the following.

Network Security IDPS – Rich Macfarlane 13

9.2.2 IPS Sensor on the ASA Firewall Device
Cisco ASA firewall devices can be configured to perform basic IDS and IPS, based on built in
signatures. The ASA has a limited number of these built in signatures, which are a small subset of the
signatures available on the dedicated Cisco IPS devices. The built in signatures can also be
complemented with additional signatures, which can be loaded into the devices flash memory. Cisco
IDPS Signatures are split into two categories:
 Informational Signatures – Identify non-malicious traffic, which the sysadmin may want to be
informed of, such as organisational policy breaches, or some reconnaissance methods.
 Attack Signatures – Identify traffic which could be a direct attack, or could lead to an attack.

Three actions are available when a signature is matched:

 Alarm - Sends an alert to a logging server and management console
 Drop – drops the packet, and does not send to the destination
 Reset – Sends a TCP RST packet to both end of the connection

IPS Sensor - Information Signatures

Create an information signature policy INFO_POLICY on the ASA firewall, to raise an alarm (which
should be sent to the syslog server) and also reset the connection on a signature match, using the
following command.
ciscoasa(config)# ip audit name INFO_POLICY info action alarm reset

Apply the IPS sensor policy to the inside interface on the firewall, using:
ciscoasa(config)# ip audit interface inside INFO_POLICY

Review the policy, checking it has been correctly applied:

ciscoasa(config)# show running-config ip audit interface
ip audit interface inside INFO_POLICY
ciscoasa(config)# show running-config ip audit name
ip audit name INFO_POLICY info action alarm reset

The signatures and the number of matched packets can be displayed using:
ciscoasa(config)# show ip audit count

Test the IPS policy on the inside interface

Clear the syslog server console window, using Edit>Clear Display. Then, Ping the 192.168.X.254
interface from the Inside VM.
Q. Can you see any relevant alerts on the syslog console?

Q. Do the pings succeed? Why?

Q. What is the fundamental difference between this and the Snort IDS Sensor used earlier?

The console should look similar to the following:

Network Security IDPS – Rich Macfarlane 14

Q. Which IDS signatures have been reported? (IDS: sig_id)

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

Host Scanning (Recon) Detection

Clear the syslog server console window, using Edit>Clear Display.
On your DMZ VM, delete your snort_logs/alert file
sudo rm snort_logs/alert

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. Does the nmap scan report that the server is up?

Q. Can you see any relevant alerts on the syslog console? Which ASA IPS signature IDs?

Q. Which type of packets are reported on the syslog server?

On the DMZ server:

Q. Has Snort raised any ICMP alerts? Why?

Q. Where have the ICMP packets been dropped?

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)

Network Security IDPS – Rich Macfarlane 15

You should see only the web packets get through to the DMZ server. Nmap uses these packets as
well as ICMP for host discovery as often ICMP is blocked:

From the Mgt VM, try the same nmap host scan to the DMZ server:
nmap –sP –n 192.168.Z.10

Q. Does the nmap scan report that the server is up?

Q. Can you see any relevant alerts on the syslog console? Why not?

On the DMZ server:

Q. Snort raised any ICMP alerts?

Q. Which type of packets have been alerted by Snort?

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.

Network Security IDPS – Rich Macfarlane 16

Remove the information IPS policy before we move on:
ciscoasa(config)# no ip audit interface inside INFO_POLICY
ciscoasa(config)# no ip audit name INFO_POLICY

IPS Attack Signatures

Create an attack signature policy ATTACK_POLICY, to raise an alarm and reset the connection on a
signature match, using the following command.
ciscoasa(config)# ip audit name ATTACK_POLICY attack action alarm reset

Apply the IPS Attack Sensor to an interface on the firewall, using:

ciscoasa(config)# ip audit interface inside ATTACK_POLICY

Check the policy has been correctly applied:

ciscoasa(config)# show running-config ip audit interface
ip audit interface inside INFO_POLICY

Test the IPS policy on the inside interface.

Clear the syslog server console window.
Ping the DMZ VM from the Inside VM, with an oversized ICMP packet, using a command such as:
ping –n 2 –c 10000 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 are reported on the syslog server?

On the DMZ server:

Q. Has Snort raised any ICMP alerts?

Check the ASA IPS audit count for signature matches:

Q. Which attack signatures have been incremented?

Network Security IDPS – Rich Macfarlane 17

 Number Type Description Count

The syslog console should look like the following:

ASA IPS Signature matches:

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?

Q. Which type of packets are reported on the syslog server?

Network Security IDPS – Rich Macfarlane 18

Try a Window scan with OS detection, and fragment the packets to attempt to avoid detection::
sudo nmap -sW -O -f 192.168.Z.10

The attack IPS sensor policy can be removed using:

ciscoasa(config)# no ip audit interface dmz ATTACK_POLICY
ciscoasa(config-if)# no ip audit name ATTACK_POLICY

Network Security IDPS – Rich Macfarlane 19

Appendix A – Installing Snort on Standalone Linux VM
9.2.3 Attach the Virtual Machine to the Internet
Run the VM you want to bridge to your physical Network Interface.
Configure a Bridged Virtual Network
From VMWare workstation hosting the VM, select the Virtual Network Editor, from the edit
menu.

Select VMNet0 which should be auto-bridged, and select the physical network interface, as
shown below.

Network Security IDPS – Rich Macfarlane 20

Select the VM>Settings menu option, and then click on Network Adapter as shown below. In
the Network Connection pane, select the Custom, and select the VMNet0 virtual network
connection to connect the VM to your local physical network, as shown below.

Configure the Virtual Machines Adapter

We now have to assign an IP Address and Default Gateway, for the physical network, to the VM’s
network adapter. (this will be on the same network as your host machine, and if a home network,
typically will be a private address such as 192.168.1.5, and the default gateway and DNS Server will
be your wireless router such as 192.168.1.1).

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.

Figure 1 - Lab Host settings

Network Security IDPS – Rich Macfarlane 21

Figure 2 - Typical Home Host Settings Q. behind a NAT Router)

Linux - Set IP Address, Default Gateway, and DNS Server

From the Linux command line console window set the IP Address using a command similar to the
following:
napier@ubuntu:~$ sudo ifconfig eth1 146.176.165.64 netmask 255.255.255.0
OR
napier@ubuntu:~$ sudo ifconfig eth1 192.168.1.3 netmask 255.255.255.0

Then set the Default Gateway to be the routers interface:

napier@ubuntu: ~$ sudo route add default gw 192.168.1.1
OR
napier@ubuntu: ~$ sudo route add default gw 146.176.165.254

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

Network Security IDPS – Rich Macfarlane 22

 collisions:0 txqueuelen:1000
RX bytes:4569600 (4.5 MB) TX bytes:124943 (124.9 KB)
Interrupt:19 Base address:0x2024

9.2.4 Installing Snort on Ubuntu

Install Snort using the command:
napier@ubuntu:~$ sudo apt-get install snort

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.

Snort will then be installed, as shown below.

Run Snort to check it has been installed correctly, using the following command. ( CTRL+C to exit)

Network Security IDPS – Rich Macfarlane 23

 sudo snort –i eth1 -dev

You should now see Snort capturing all network packets.

Network Security IDPS – Rich Macfarlane 24