lab 10: idps – snort & cisco idps sensors - napier40001507/csn11111/lab10.pdf · network...

Network Security IDPS – Rich Macfarlane 1

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

Create Virtual Topology 9.2.1

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.


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!

Configure the Hosts 9.2.2

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)

Basic ASA Configuration & Connectivity 9.2.3

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-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


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)# ip address 192.168.Z.254 255.255.255.0

http://www.dcs.napier.ac.uk/~cs342/CSN11111/GNSAddVM.pdf




Set up the management network interface, which is connected to the trusted internal network:


ciscoasa(config-if)# nameif mgt


ciscoasa(config-if)# ip address 192.168.MGT.254 255.255.255.0



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?

Test connectivity 9.2.4

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:


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.

Snort IDS Sensor running on the DMZ Host 9.2.5

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.

http://www.snort.org/docs


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?

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 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 47 45 54 20 2F 68 6F 6D 65 5F 6E 65 77 2F 69 6D GET /home_new/im 61 67 65 73 2F 70 72 6F 67 5F 66 32 2E 67 69 66 ages/prog_f2.gif 20 48 54 54 50 2F 31 2E 31 0D 0A 41 63 63 65 70 HTTP/1.1..Accep 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 67 75 61 67 65 3A 20 65 6E 2D 67 t-Language: en-g 62 0D 0A 41 63 63 65 70 74 2D 45 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)

Dest MAC

Src TCP Port

Port

Dest TCP

Port Port

Src IP

Dest IP

Src MAC

HTTP

Payload

Dest IP


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.

Create Snort IDS Signatures 9.2.6

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 Traffic

Decoder &

PreprocessorsDetection

EngineLogging &

Alerting

Logs

Snort Sensor

AlertsRules

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?


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:


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?

Using Snorts built in Signatures 9.2.7

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?


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:


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.


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)

ASA Firewall Device – Logging to Central Syslog Server 9.2.1

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:


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.


IPS Sensor on the ASA Firewall Device 9.2.2

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:


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)


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.


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



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?


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




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


Appendix A – Installing Snort on Standalone Linux VM

Attach the Virtual Machine to the Internet 9.2.3

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.


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


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


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

Installing Snort on Ubuntu 9.2.4

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)


sudo snort –i eth1 -dev

You should now see Snort capturing all network packets.

lab 10: idps – snort & cisco idps sensors - napier40001507/csn11111/lab10.pdf · network...

Documents