Lab - Installing the Virtual Machines, Snort and firewall rules

Part 1: Configuring Virtual Machines

Step 1: Download and install VirtualBox.
VMware Player and Oracle VirtualBox are two virtualization programs that you can download and install to
support the image file. In this lab, you will use VirtualBox.
a. Navigate to http://www.oracle.com/technetwork/server-storage/virtualbox/downloads/index.html.
b. Choose and download the appropriate installation file for your operating system.
c. When you have downloaded the VirtualBox installation file, run the installer and accept the default
installation settings.

Step 2: Import the virtual machine file into VirtualBox.

a. Open VirtualBox. Click File > Import Appliance... to import the virtual machine image, The CyberOps
Workstation VM is used in this lab.
b. In the Appliance to import window, specify the location of the .OVA file and click Next.
c. The Appliance window presents the settings suggested in the OVA archive. Review the default settings and
change as necessary. Click Import to continue.
d. When the import process is complete, you will see the new Virtual Machine added to the VirtualBox
inventory in the left panel. The virtual machine is now ready to use.

Step 3: Start the virtual machine and log in.

a. Select and start a newly imported virtual machine.
b. Click the green arrow Start button at the top portion of the VirtualBox application window. If you get a
network adapter error, click Change Network Settings and set your Bridged Adapter. Click the dropdown
list next the Name and choose your network adapter (will vary for each computer).
Note: If your network is not configured with DHCP services, click Change Network Settings and select
NAT in the Attached to dropdown box. The network settings can also be access via Settings in the Oracle
VirtualBox Manager or in the virtual machine menu, select Devices > Network > Network Settings. You
may need to disable and enable the network adaptor for the change to take effect.
c. Click OK. A new window will appear, and the virtual machine boot process will start.
d. When the boot process is complete, the virtual machine will ask for a username and password. Use the
following credentials to log into the virtual machine:
Username: analyst
Password: cyberops
You will be presented with a desktop environment: there is a launcher bar at the bottom, icons on the
desktop, and an application menu at the top.

Step 4: Familiarize yourself with the Virtual Machine.

a. Open the Terminal Emulator application. Type ip address at the prompt to determine the IP address of
your virtual machine.
Question:

What are the IP addresses assigned to your virtual machine? Document the process with
screenshots
 Type your answers here.
Locate and launch the web browser application and verify you can you navigate. Document the
process with screenshots

Part 2: Firewall and IDS

Step 1: Starting Topology

Topology

In a secure production network, network alerts are generated by various types of devices such as security
appliances, firewalls, IPS devices, routers, switches, servers, and more. The problem is that not all alerts are
created equally. For example, alerts generated by a server and alerts generated by a firewall will be different
and vary in content and format. In this part you will get familiar with firewall rules and IDS signatures.
a. In the CyberOps Workstation VM, open a terminal and configure its network by executing the
configure_as_dhcp.sh script.
Because the script requires super-user privileges, provide the password for the user analyst.

[analyst@secOps ~]$ sudo ./lab.support.files/scripts/configure_as_dhcp.sh

[sudo] password for analyst:
[analyst@secOps ~]$

Step 2: Firewall and IDS Logs

Firewalls and Intrusion Detection Systems (IDS) are often deployed to partially automate the traffic monitoring
task. Both firewalls and IDSs match incoming traffic against administrative rules. Firewalls usually compare the
packet header against a rule set while IDSs often use the packet payload for rule set comparison.
 Because firewalls and IDSs apply the pre-defined rules to different portions of the IP packet, IDS and firewall
rules have different structures.

While there is a difference in rule structure, some similarities between the components of the rules remain. For
example, both firewall and IDS rules contain matching components and action components. Actions are taken
after a match is found.
• Matching component - specifies the packet elements of interest, such as: packet source; the packet
destination; transport layer protocols and ports; and data included in the packet payload.
• Action component - specifies what should be done with that packet that matches a component, such as:
accept and forward the packet; drop the packet; or send the packet to a secondary rule set for further
inspection.
A common firewall design is to drop packets by default while manually specifying what traffic should be allowed.
Known as dropping-by-default, this design has the advantage protecting the network from unknown protocols
and attacks. As part of this design, it is common to log the events of dropped packets since these are packets
that were not explicitly allowed and therefore, infringe on the organization’s policies. Such events should be
recorded for future analysis.

Step 3: Real-Time IDS Log Monitoring

a. From the CyberOps Workstation VM, run the script to start mininet.

[analyst@secOps ~]$ sudo ./lab.support.files/scripts/cyberops_extended_topo_no_fw.py

[sudo] password for analyst:
*** Adding controller
*** Add switches
*** Add hosts
*** Add links
*** Starting network
*** Configuring hosts
R1 R4 H1 H2 H3 H4 H5 H6 H7 H8 H9 H10 H11
*** Starting controllers
*** Starting switches
*** Add routes
*** Post configure switches and hosts
*** Starting CLI:
mininet>

The mininet prompt should be displayed, indicating mininet is ready for commands.

b. From the mininet prompt, open a shell on R1 using the command below:
mininet> xterm R1
mininet>
Question:

The R1 shell opens in a terminal window with black text and white background. You are logged as root
user. This is indicated by the # sign after the prompt.
c. From R1’s shell, start the Linux-based IDS, Snort.
[root@secOps analyst]# ./lab.support.files/scripts/start_snort.sh
Running in IDS mode
--== Initializing Snort ==--
Initializing Output Plugins!
Initializing Preprocessors!
Initializing Plug-ins!
Parsing Rules file "/etc/snort/snort.conf"
<output omitted>

Note: You will not see a prompt as Snort is now running in this window. If for any reason, Snort stops
running and the [root@secOps analysts]# prompt is displayed, rerun the script to launch Snort. Snort
must be running to capture alerts later in the lab.

d. From the CyberOps Workstation VM mininet prompt, open shells for hosts H5 and H10.
mininet> xterm H5
mininet> xterm H10
mininet>

e. H10 will simulate a server on the Internet that is hosting malware. On H10, run the mal_server_start.sh
script to start the server.
[root@secOps analyst]# ./lab.support.files/scripts/mal_server_start.sh
[root@secOps analyst]#

f. On H10, use netstat with the -tunpa options to verify that the web server is running. When used as shown
below, netstat lists all ports currently assigned to services:

[root@secOps analyst]# netstat -tunpa

Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program
name
tcp 0 0 0.0.0.0:6666 0.0.0.0:* LISTEN 1839/nginx:
master
[root@secOps analyst]#
As seen by the output above, the lightweight webserver nginx is running and listening to connections on
port TCP 6666.

g. In the R1 terminal window, an instance of Snort is running. To enter more commands on R1, open another
R1 terminal by entering the xterm R1 again in the CyberOps Workstation VM terminal window. You may
also want to arrange the terminal windows so that you can see and interact with each device.

h. In the new R1 terminal tab, run the tail command with the -f option to monitor the /var/log/snort/alert file
in real-time. This file is where snort is configured to record alerts.
[root@sec0ps analyst]# tail -f /var/log/snort/alert
 Because no alerts were yet recorded, the log should be empty. However, if you have run this lab before,
old alert entries may be shown. In either case, you will not receive a prompt after typing this command. This
window will display alerts as they happen.

i. From H5, use the wget command to download a file named W32.Nimda.Amm.exe. Designed to download
content via HTTP, wget is a great tool for downloading files from web servers directly from the command
line.
[root@secOps analyst]# wget 209.165.202.133:6666/W32.Nimda.Amm.exe
Question:

What port is used when communicating with the malware web server? What is the indicator?
Document the process with screenshots
Type your answers her
Was the file completely downloaded?
Type your answers he
Did the IDS generate any alerts related to the file download?
Type your answers he

j. As the malicious file was transiting R1, the IDS, Snort, was able to inspect its payload. The payload matched
at least one of the signatures configured in Snort and triggered an alert on the second R1 terminal window
(the tab where tail -f is running). Show the alert entry, document the process with screenshots:

Based on the alert shown above, what was the source and destination IPv4 addresses used in the
transaction?
Type your answers here.
Based on the alert shown above, what was the source and destination ports used in the transaction?
Type your answers here.
Based on the alert shown above, when did the download take place?
Type your answers here.
Based on the alert shown above, what was the message recorded by the IDS signature?
Type your answers here.
On H5, use the tcpdump command to capture the event and download the malware file again so you can
capture the transaction. Issue the following command below start the packet capture:
[root@secOps analyst]# tcpdump –i H5-eth0 –w nimda.download.pcap &
[1] 5633
[root@secOps analyst]# tcpdump: listening on H5-eth0, link-type EN10MB (Ethernet),
capture size 262144 bytes

The command above instructs tcpdump to capture packets on interface H5-eth0 and save the capture to a
file named nimda.download.pcap.
The & symbol at the end tells the shell to execute tcpdump in the background. Without this symbol,
tcpdump would make the terminal unusable while it was running. Notice the [1] 5633; it indicates one
process was sent to background and its process ID (PID) is 5366. Your PID will most likely be different.
 k. Press ENTER a few times to regain control of the shell while tcpdump runs in background.

l. Now that tcpdump is capturing packets, download the malware again. On H5, re-run the command or use
the up arrow to recall it from the command history facility.
[root@secOps analyst]# wget 209.165.202.133:6666/W32.Nimda.Amm.exe

Show the entry, document the process with screenshots:

m. Stop the capture by bringing tcpdump to foreground with the fg command. Because tcpdump was the
only process sent to background, there is no need to specify the PID. Stop the tcpdump process with
Ctrl+C. The tcpdump process stops and displays a summary of the capture. Show the capture,
document the process with screenshots

[root@secOps analyst]# fg

n. On H5, Use the ls command to verify the pcap file was in fact saved to disk and has size greater than zero:
Show the capture, document the process with screenshots
[root@secOps analyst]# ls -l

Question:

How can be this PCAP file be useful to the security analyst?

Step 4: Tuning Firewall Rules Based on IDS Alerts

In Step 3, you started an internet-based malicious server. To keep other users from reaching that server, it is
recommended to block it in the edge firewall.
In this lab’s topology, R1 is not only running an IDS but also a very popular Linux-based firewall called iptables.
In this step, you will block traffic to the malicious server identified in Step 1 by editing the firewall rules currently
present in R1.
Note: While a comprehensive study of iptables is beyond the scope of this course, iptables basic logic and
rule structure is fairly straight-forward.
The firewall iptables uses the concepts of chains and rules to filter traffic.
Traffic entering the firewall and destined to the firewall device itself is handled by the INPUT chain. Examples
of this traffic are ping packets coming from any other device on any networks and sent to any one of the firewall’s
interfaces.
Traffic originated in the firewall device itself and destined to somewhere else, is handled by the OUTPUT chain.
Examples of this traffic are ping responses generated by the firewall device itself.
Traffic originated somewhere else and passing through the firewall device is handled by the FORWARD chain.
Examples of this traffic are packets being routed by the firewall.
Each chain can have its own set of independent rules specifying how traffic is to be filtered for that chain. A
chain can have practically any number of rules, including no rule at all.
Rules are created to check specific characteristics of packets, allowing administrators to create very
comprehensive filters. If a packet doesn’t match a rule, the firewall moves on to the next rule and checks again.
If a match is found, the firewall takes the action defined in the matching rule. If all rules in a chain have been
checked and yet no match was found, the firewall takes the action specified in the chain’s policy, usually allow
the packet to flow through or deny it.
a. In the CyberOps Workstation VM, start a third R1 terminal window.
mininet > xterm R1
b. In the new R1 terminal window, use the iptables command to list the chains and their rules currently in
use:
[root@secOps ~]# iptables -L -v
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain FORWARD (policy ACCEPT 6 packets, 504 bytes)

pkts bytes target prot opt in out source destination

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)

pkts bytes target prot opt in out source destination

[root@secOps ~]#
Question:

What chains are currently in use by R1?

Type your answers here.
c. Connections to the malicious server generate packets that must transverse the iptables firewall on R1.
Packets traversing the firewall are handled by the FORWARD rule and therefore, that is the chain that will
receive the blocking rule. To keep user computers from connecting to the malicious server identified in Step
3, add the following rule to the FORWARD chain on R1:
[root@secOps ~]# iptables -I FORWARD -p tcp -d 209.165.202.133 --dport 6666 -j
DROP
[root@secOps ~]#
Where:
o -I FORWARD: inserts a new rule in the FORWARD chain.
o -p tcp: specifies the TCP protocol.
o -d 209.165.202.133: specifies the packet’s destination
o --dport 6666: specifies the destination port
o -j DROP: set the action to drop.
d. Use the iptables command again to ensure the rule was added to the FORWARD chain. The CyberOps
Workstation VM may take a few seconds to generate the output:
[root@secOps analyst]# iptables -L -v
Show and analyze the output, document the process with screenshots

e. On H5, try to download the file again:

[root@secOps analyst]# wget 209.165.202.133:6666/W32.Nimda.Amm.exe
Enter Ctrl+C to cancel the download, if necessary.
Questions:
 Was the download successful this time? Explain, Show the output, document the process with
screenshots:
Type your answers here.
What would be a more aggressive but also valid approach when blocking the offending server?

Terminate and Clear Mininet Process

f. Navigate to the terminal used to start Mininet. Terminate the Mininet by entering quit in the main CyberOps
VM terminal window.
g. After quitting Mininet, clean up the processes started by Mininet. Enter the password cyberops when
prompted.
[analyst@secOps scripts]$ sudo mn –c
[sudo] password for analyst:
End of document

Note. This lab was adapted from a Cisco Security Course Lab for academic purposes