Lab 10: IDPS Snort & Cisco IDPS Sensors

Transcription

1 Lab 10: IDPS Snort & Cisco IDPS Sensors 9.1 Details Aim: Rich Macfarlane 2015 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.1Create 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 X.0/24, and the DMZ network Z.0/24. A Management network 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

2 You will be assigned networks to address the hosts and ASA gateway interfaces to from Moodle: 10.1.Y.0/24, X.0/24, Z.0/24, and 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.2Configure 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: The following document has a section on setting the Windows IP and default gateway: (Section: Windows-Setting Static IP Address and Default Gateway) 9.2.3Basic 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 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 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 X 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 Z Network Security IDPS Rich Macfarlane 2

3 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 MGT 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.4Test 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

4 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 For more information on Snort, the manual and FAQ can be found at: 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 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

5 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: :15:0:34:2:F0 -> 0:C:41:F5:23:D5 type:0x800 len:0x19a :2735 -> :80 TCP TTL:128 TOS:0x0 ID:13141 IpLen:20 D Len:396 DF ***AP*** Seq: 0xCEDC79A8 Ack: 0xE2431ED3 Win: 0x4037 TcpLen: 20 Src 47 IP Src 20 TCP 2F Port 68 6F 6D 65 5F 6E F 69 6D GET /home_new/im HTTP F F 67 5F E ages/prog_f2.gif F 31 2E 31 0D 0A HTTP/1.1..Accep Payload 74 3A 20 2A 2F 2A 0D 0A A t: */*..Referer: A 2F 2F E 6E E E 75 6B 2F 0D 0A er.ac.uk/..accep 74 2D 4C 61 6E 67 Dest 75 IP Dest 3A TCP E 2D Dest 67 IP t-language: en-g 62 0D 0A D 45 6E 63 6F b..accept-encodi 6E 67 3A A C C ng: gzip, deflat 65 0D 0A D E 74 3A 20 4D e..user-agent: M 6F 7A 69 6C 6C 61 2F 34 2E F 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

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

7 Network Traffic Snort Sensor Logs Rules Decoder & Preprocessors Detection Engine Logging & Alerting Alerts 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

8 Check if any alerts have been raised: 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. 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 2 nd snort detection rule to the snort_sigs file, to alert for a ping from a Cisco device. For the 2 nd 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

9 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.7Using 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 icmpinfo.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

10 The alerts should look similar to the following: The built in community Snort rules can be found in the /etc/snort/rules directory: cd /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

11 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

12 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 :28? 00:00:00 snort -D -ieth2 -c detect_sigs -dev napier :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 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: 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

13 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 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 Z.254 from the DMZ VM. The syslog server should receive and display messages such as the following. Network Security IDPS Rich Macfarlane 13

14 9.2.2IPS 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 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

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

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

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

18 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 p Z.254 sudo nmap sf n p 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

19 Try a Window scan with OS detection, and fragment the packets to attempt to avoid detection:: sudo nmap -sw -O -f 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

20 Appendix A Installing Snort on Standalone Linux VM 9.2.3Attach 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

21 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 , and the default gateway and DNS Server will be your wireless router such as ). 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

22 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 eth netmask OR napier@ubuntu:~$ sudo ifconfig eth netmask Then set the Default Gateway to be the routers interface: napier@ubuntu: ~$ sudo route add default gw OR napier@ubuntu: ~$ sudo route add default gw 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: Bcast: Mask: 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

23 collisions:0 txqueuelen:1000 RX bytes: (4.5 MB) TX bytes: (124.9 KB) Interrupt:19 Base address:0x Installing Snort on Ubuntu Install Snort using the command: 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

24 sudo snort i eth1 -dev You should now see Snort capturing all network packets. Network Security IDPS Rich Macfarlane 24