Download Firewalls - Lab 4 | Internetwork Security | ECE 4112 and more Lab Reports Electrical and Electronics Engineering in PDF only on Docsity!
ECE4112 Internetwork Security
Lab 4: Firewalls
Group Number: _________
Member Names: ___________________ _______________________
Date Assigned: February 6, 2007
Date Due: February 13, 2007
Last Edited: April 9, 2007
Please read the entire lab and any extra materials carefully before starting. Be sure to start early
enough so that you will have time to complete the lab. Answer ALL questions in the Answer
Sheet and be sure you turn in ALL materials listed in the Turn-in Checklist on or before the
Date Due.
NOTE: Part 3 of the lab requires you to reserve slots to use the equipment. The signup sheets will be posted on the lab door. The equipment you need to sign up for will not be available at the last minute. PLAN AHEAD. The three sections of this lab may be done in any order.
Goal: This lab will introduce to the concept of Firewalls. You will be experimenting with
different kinds of firewalls.
Summary: This lab is divided into three major parts. Part 1 explores the Linux firewall
implementation in the form of the iptables program. Part 2 is a small introduction to Real Secure, one of the most popular Windows firewall programs. In Part 3, you will configure a Cisco PIX 515E firewall for a particular network structure. Part 1 and 3 might each take 2 hours or more, to finish. Therefore it is recommended that you start early.
Background: None
Prelab Questions: None
Lab Scenario:
NOTE: Part 3 of the lab requires you to reserve slots to use the equipment. The signup sheets will be posted on the lab door. For Part 1 of this lab, you will be setting up two virtual machines on your hard drive. One of the two will represent a protected machine inside a firewall, while the other will represent an attacker. We will use the host machine (WS 4.0) as a router that implements a firewall. The virtual machine network structure is
shown below. These machines will be set up with host only networking, meaning any traffic they send or receive goes through the host machine. The host machine will be using the iptables program. Figure 1-1. Network structure on the Firewall machines System Setup Protected: A normal Linux virtual machine with IP 192.168.0.10, netmask 255.255.255.0, and gateway 192.168.0.1. The gateway is a virtual interface on the host machine which acts like a router and firewall. This is the machine that is on the inside network and needs to be protected with the firewall. Linux Firewall: Red Hat WS 4.0 base system that is configured to act like a router and runs a firewall with ipchains. It forwards packets received on its two virtual interfaces (vmnet1 and vmnet2) to the intended destinations. You will make firewall rules on this machine to protect the inside network. BlackHat: Same configuration as the protected machine. IP address is 131.210.231.55 and gateway is 131.210.231.1, which is the virtual interface vmnet2 on the host machine. This is the machine where you will try to attack the protected machine from. Configuring the network Before configuring the firewall on the host machine, we must first setup the network described in Figure 1-1. Two virtual machine images have been placed on the NAS under the Lab 4 Folder for you to use: Protected and BlackHat. Both of these are Red Hat Linux WS 4.0 images. Copy the directories BlackHat and Protected to the folder that you have placed all other vmware images. This may take a few minutes per image. Note: The root passwords for these machines have been set to “password”.
Do you wish to make additional changes to the current virtual networks settings ?(yes/no)
[yes] No
Starting VMware services: Virtual machine monitor [ OK ] Virtual ethernet [ OK ] Bridged networking on /dev/vmnet0 [ OK ] Host-only networking on /dev/vmnet1 (background) [ OK ] Host-only networking on /dev/vmnet2 (background) [ OK ]
What this has done is set up two virtual Host-Only Networks on /dev/vmnet1 and /dev/vmnet2.
We are using the host-only networks to act like two independent subnetworks. Each virtual
machine will act as if we are connecting it to an extra network card in the host.
Start VMware by typing vmware &. In another terminal type ifconfig. All of the host-only
networks appear along with eth0 and eth1, functioning as if they were physical network cards.
Start both your WS4 virtual machines (refer to lab 1 if you forgot how to add a virtual machine).
Right click on the tab that lists the name of the machine, and go down to “Settings”. The setting
for “Ethernet1” needs to be changed from “Bridged” to “Custom: Specific virtual network”. The
drop down box then needs to be set to either /dev/vmnet1 or /dev/vmnet2 depending on the
specific virtual machine. Check the network diagram on Figure 1-1.
Click on the RedHat Icon on the virtual machines and go to System Settings -> Network. Click on
Edit to modify your settings, and change your gateway (see network diagram on Figure 1-
again). Also uncheck “Bind to MAC address” under the Hardware Devices Tab. Make sure the
IP address is correct for each virtual machine. The gateway should be the IP of the host machine
for the specific virtual network you are setting up. So for the Protected virtual machine, the IP
address will be 192.168.0.10 and the gateway will be 192.168.0.1.
Click OK. Then, click Deactivate, Activate, Apply. Close to change your settings.
Try pinging your host machine from each virtual machine.
$ping 192.168.0.1 (from protected terminal)
$ping 131.210.231.1 (from BlackHat Terminal)
Now that we have bound the virtual machines to our host, it is time to allow for packet forwarding through the host machine so that each virtual machine can communicate.
On the host machine:
To allow your host to forward or route IP packets, you need to type the following:
$echo 1 > /proc/sys/net/ipv4/ip_forward
This places a 1 in the file /proc/sys/net/ipv4/ip_forward. Check to make sure this command was
successful by typing $cat /proc/sys/net/ipv4/ip_forward (1 should be printed on your screen).
When Linux receives a packet, it looks at this file, and forwards if it sees a 1. This configuration
is reset each time your physical machine is rebooted, so you must retype this command every
time you reboot!
You should be able to ping the Protected machine from the BlackHat machine.
1. Linux Firewalls
In this section of the lab you will explore the Linux firewall iptables. The initial sections give an overview of basic firewall concepts with exercises and examples. In the later sections, you will implement all the rules in the iptables.firewall file available from the Lab 4 directory on the NAS server. The effects of these rules are to be examined. To get started, open a terminal on the machine and start VMWare. You’ll see that some virtual machines have already been setup for you. We will be using the “Protected” and “Blackhat” machines, as shown in Figure 1-1. The host machine will act as the firewall. Setting up routing and iptables Some of the information given in this section will only be clear and useful later on when you actually use iptables. The executable binary for the iptables application is the /sbin/iptables file. So when you execute iptables this is the file that is executed. RedHat also has an executable script in the /etc/init.d/iptables file so that it can start its default firewall at startup. An easy way to reset the firewall rules is to use this script as /etc/rc.d/init.d/iptables stop This flushes all the rules in memory and gives you a clean start. You can flush individual rules with iptables –F flushes all chains iptables –X deletes a chain iptables –X deletes all chains To check if there are any current rules, type iptables –L It’ll show you a couple of chains, but there won’t be any rules in them. You might have to do /etc/init.d/iptables restart to apply these changes (note: this is a different command than the one you used above). Obtain the file iptables.firewall from the NAS in the lab6 folder. This file contains all of the firewall rules we will use in this lab. The contents of this file are included in Appendix A so you may follow the lab discussion in that file. You can execute this file to enable all the rules at once by executing it. Don’t execute it yet. Later in the lab, every time you need to restart the firewall with your rules, you can use the following commands: /etc/rc.d/init.d/iptables stop ./iptables.firewall (in the directory with your edited iptables.firewall file)
1.1.2. Firewall Configuration
Firewalls are customizable. This means that you can add or remove filters based on several conditions. Some of these are: IP addresses Domain names Protocols - IP (Internet Protocol) - the main delivery system for information over the Internet TCP (Transport Control Protocol) - used to break apart and rebuild information that travels over the Internet HTTP (Hyper Text Transfer Protocol) - used for Web pages FTP (File Transfer Protocol) - used to download and upload files UDP (User Datagram Protocol) - used for information that requires no response, such as streaming audio and video ICMP (Internet Control Message Protocol) - used by a router to exchange the information with other routers SMTP (Simple Mail Transport Protocol) - used to send text-based information (e-mail) SNMP (Simple Network Management Protocol) - used to collect system information from a remote computer Telnet - used to perform commands on a remote computer Ports Specific words and phrases - This can be anything. The firewall will sniff (search through) each packet of information for an exact match of the text listed in the filter. For example, you could instruct the firewall to block any packet with the word "X-rated" in it. The key here is that it has to be an exact match. The "X-rated" filter would not catch "X rated" (no hyphen). But you can include as many words, phrases and variations of them as you need. A software firewall, such as RealSecure, can be installed on the computer in your home that has an Internet connection. This computer is considered a gateway because it provides the only point of access between your home network and the Internet. With a hardware firewall, the firewall unit itself is normally the gateway. A good example is the Linksys Cable/DSL router. It has a built-in Ethernet card and hub. Computers in your home network connect to the router, which in turn is connected to either a cable or DSL modem. You configure the router via a Web-based interface that you reach through the browser on your computer. You can then set any filters or additional information. Hardware firewalls are incredibly secure and not very expensive. Home versions that include a router, firewall, and Ethernet hub for broadband connections can be found for well under $100.
1.1.3. What It Protects You From:
There are many creative ways that unscrupulous people use to access or abuse unprotected computers. The level of security you establish will determine how many of these threats can be stopped by your firewall. The highest level of security would be to simply block everything. Obviously that defeats the purpose of having an Internet connection. But a common rule of thumb is to block everything, and then begin to select what types of traffic you will allow. You can also restrict traffic that travels through the firewall so that only certain types of information, such as e-mail, can get through. This is a good rule for businesses that have an experienced network administrator that understands what the needs are and knows
exactly what traffic to allow through. For most of us, it is probably better to work with the defaults provided by the firewall developer unless there is a specific reason to change it. One of the best things about a firewall from a security standpoint is that it stops anyone on the outside from logging onto a computer in your private network. While this is a big deal for businesses, most home networks will probably not be threatened in this manner. Still, putting a firewall in place provides some peace of mind.
1.1.4. Demilitarized Zone
DMZ stands for Demilitarized Zone. A DMZ is your frontline when protecting valuables from direct exposure to an untrusted environment. SI Security defines a DMZ as, "A network added between a protected network and an external network in order to provide an additional layer of security." A DMZ is sometimes called a "Perimeter network" or a "Three-homed perimeter network." A DMZ is a step towards defense in depth because it adds an extra layer of security beyond that of a single perimeter. A DMZ separates an external network from directly referencing an internal network. It does this by isolating the machine that is being directly accessed from all other machines. Most of the time the external network is the Internet and what is in the DMZ is the web server but this isn’t the only possible configuration. A DMZ can be used to isolate a particular machine within a network from other machines. This might be done for a branch office that needs its own Internet access but also needs access to the corporate network. In DMZ terminology, an internal connection is generally thought of as having more secret or valuable information than an external network. An easy way to understand which one is the internal network is to ask yourself which network I am protecting. Separation is important. Any system should have its important applications separated. This acts as system of checks and balances to make sure that if any one area goes bad that it cannot corrupt the whole. It is important to separate information so an attacker can’t get to all the systems. It would be bad enough for the attacker to get to the web server but if that attacker can get through the web server to your database then that’s even worse. This is the type of problem that a DMZ is designed to prevent. A DMZ’s separation will degrade performance. If configured correctly the degradation in performance is usually minimal and seldom noticeable. However, it does exist and you need to be aware of it. This effect on performance must be calculated in the total cost of implementing a DMZ. Usually the performance drop is nominal and the security increase is significant. Q1.2. What ports do you think should be left open to allow for normal internet traffic? Explain how your answer differs for say a host versus a server.
1.2.1. - IPtables Introduction
Up until now, we've looked at stateless and stateful firewalls. Remember, stateless firewalls only have the features of a given packet to use as criteria for whether that packet should be passed, blocked, or logged. With a stateful firewall, in addition to the fields in that packet, we also have access to the kernel's table of open connections to use in deciding the fate of this packet.
Figure 1-2 – Routing chains The three circles represent the three chains mentioned above. When a packet reaches a circle in the diagram, that chain is examined to decide the fate of the packet. If the chain says to DROP the packet, it is killed there, but if the chain says to ACCEPT the packet, it continues traversing the diagram. A chain is a checklist of rules. Each rule says ‘if the packet header looks like this, then here’s what to do with the packet’. If the rule doesn’t match the packet, then the next rule in the chain is consulted. Finally, if there are no more rules to consult, then the kernel looks at the chain policy to decide what to do. In a security-conscious system, this policy usually tells the kernel to DROP the packet.
- When a packet comes in (say, through the Ethernet card) the kernel first looks at the destination of the packet: this is called ‘routing’.
- If it’s destined for this box, the packet passes downwards in the diagram, to the INPUT chain. If it passes this, any processes waiting for that packet will receive it.
- Otherwise, if the kernel does not have forwarding enabled, or it doesn’t know how to forward the packet, the packet is dropped. If forwarding is enabled, and the packet is destined for another network interface (if you have another one), then the packet goes rightwards on our diagram to the FORWARD chain. If it is ACCEPTed, it will be sent out.
- Finally, a program running on the box can send network packets. These packets pass through the OUTPUT chain immediately: if it says ACCEPT, then the packet continues out to whatever interface it is destined for.
1.3.2. Creating your own rules
The iptables tool inserts and deletes rules form the kernel’s packet filtering table. Initially all chains are set to ACCEPT by default. A detailed description can be obtained from the man pages (man iptables). Commands to change chains: (Note: Use upper case letters)
- create a new chain (-N) delete an empty chain (-X)
- list the rules for a chain (-L)
- flush a chain (delete all rules in a chain) (-F) Commands to add/delete rules:
- Append a new rules to a chain (-A)
- Delete a rule at some position in a chain, or the first that matches (-D) The sections Note: The examples in these sections only demonstrate particular rules. They may or may not work for the network setup for the lab.
1.4.0. Iptables Parameters
Parameters specify the type of packet that you are looking to match with your rule.
1.4.1. Specifying jump
If a packet matches one of your rules, you can tell the packet to jump to another chain with the ‘-j’ option
Example:
#jump all packets in INPUT chain to the DROP chain
iptables –A INPUT –j DROP
1.4.2. Specifying protocol
The protocol can be specified with the ‘–p’ option. Protocols can either be the number in the IP
header or ‘tcp’, ‘udp’, or ‘icmp’ (case insensitive).
Example:
#drop all icmp packets
iptables –A INPUT –p icmp –j DROP
1.4.3. Specifying inversion
To invert (negate) any of your rules use the ‘!’ character
Example:
#drop all packets that are not tcp iptables –A INPUT –p! tcp
1.4.4. Specifying interface
Interfaces can be specified with the ‘-i’ (input) and ‘-o’ (output) paramaters. Note, a rule in the INPUT chain checking with ‘-o’ will never match any packet and a rule in the OUTPUT chain checking with ‘-i’ will never match any packet.
Example:
#check packets coming in from the eth0 interface iptables –A INPUT –i eth
1.4.5. Specifying source/dest
The source/dest address of the packet can be specified in 4 ways. The source/dest can be specified as a named address ( localhost, www.yahoo.com), by the IP address (e.g. 192.168.1.12), by group using network bits (e.g. 190.35.107.0/24 ), or by using network address/netmask ( e.g. 190.35.107.0/255.255.255.0 ) Although this next example is not in our iptables.firewall take a look at this example:
Example:
#allow tcp packets coming from 130.207.232.1/24 machines to 50.60.23.45 machine
This match can often be used with the LOG target to do rate-limited logging. To understand how it works, let's look at the following rule, which logs packets with the default limit parameters:
iptables -A FORWARD -m limit -j LOG
The first time this rule is reached, the packet will be logged; in fact, since the default burst is 5, the first five packets will be logged. After this, it will be twenty minutes before a packet will be logged from this rule, regardless of how many packets reach it (60 minutes / 3 packets per hour). This value of twenty minutes is because the default limit is 3/hour. Also, every twenty minutes which passes without matching a packet, one of the burst will be regained; if no packets hit the rule for 100 minutes, the burst will be fully recharged to 5 packets (100 minutes / 20mintes per packet); back where we started. Note: you cannot currently create a rule with a recharge time greater than about 59 hours, so if you set an average rate of one per day, then your burst rate must be less than 3. You can also use this module to avoid various denial-of-service attacks (DoS) with a faster rate to increase responsiveness. Syn-flood protection (recall Datapool utility from Lab 3 for DoS using Syn Flood):
iptables -A FORWARD -p tcp --syn -m limit --limit 1/s -j ACCEPT
or
iptables –N SYN-FLOOD
iptables –A SYN-FLOOD –m limit –-limit 20/s –-limit-burst 100 –j
RETURN
iptables –A SYN-FLOOD –j LOG –-log-prefix “SYN-FLOOD: ”
iptables –A INPUT –p tcp –-syn –j SYN-FLOOD
Furtive port scanner:
iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --
limit 1/s -j ACCEPT Ping of death:
iptables -A FORWARD -p icmp --icmp-type echo-request -m limit --limit
1/s -j ACCEPT UDP Attack (from Lab 3):
iptables –N UDP-FLOOD
iptables –A UDP-FLOOD –m limit –-limit 20/s –-limit-burst 100 –j
RETURN
iptables –A UDP-FLOOD –j LOG –-log-prefix “UDP-FLOOD: “
iptables –A UDP-FLOOD –j DROP
iptables –A INPUT –p udp –j UDP-FLOOD
1.5.0. Network Address Translation (NAT)
There are two types of NAT, source NAT and destination NAT.
Source NAT is when you alter the source address of the first packet: i.e. you are changing where the connection is coming from. Source NAT is always done post-routing, just before the packet goes out onto the wire. Masquerading is a specialized form of SNAT. A router might do masquerading for packets going from one of its internal machines to an outside connection. In this case it will change the source address of the machine to its own address. The external machine will see the packets coming from the router. Destination NAT is when you alter the destination address of the first packet: i.e. you are changing where the connection is going to. Destination NAT is always done before routing, when the packet first comes off the wire. Port forwarding, load sharing, and transparent proxying are all forms of DNAT. In the router example, the incoming packets intended for the internal machine are routed to it by changing the destination address to the internal address of the machine.
1.5.1 - NAT in the kernel
You need to create NAT rules which tell the kernel what connections to change, and how to change them. To do this, we use the very versatile iptables tool, and tell it to alter the NAT table by specifying the -t nat' option. The table of NAT rules contains three lists calledchains': each rule is examined in order until one matches. The two chains are called PREROUTING (for Destination NAT, as packets first come in), and POSTROUTING (for Source NAT, as packets leave). The third (OUTPUT) will be ignored here.
The following diagram illustrates this concept:
Figure 1-3 – NAT routing chains
At each of the points above, when a packet passes we look up what connection it is associated with. If it's a new connection, we look up the corresponding chain in the NAT table to see what to do with it. The answer it gives will apply to all future packets on that connection.
DNAT is done in the PREROUTING chain, just as the packet comes in; this means that anything else on the Linux box itself (routing, packet filtering) will see the packet going to its real' destination. It also means that the-i' (incoming interface) option can be used.
1.5.3. Port Forwarding
When running a web server behind your firewall, you want to forward packets destined for that server through the firewall to that box.
Example:
Linux 2.
Append a rule before routing (-A PREROUTING) to the NAT table (-t nat) that
TCP packets (-p tcp) going to 1.2.3.4 (-d 1.2.3.4) port 80 (--dport 80)
have their destination mapped (-j DNAT) to 192.168.1.1, port 80
(--to 192.168.1.1:80).
iptables -A PREROUTING -t nat -p tcp -d 1.2.3.4 --dport 80 -j DNAT --to 192.168.1.1: NOTE: This only changes the destination of the packet, it does not automatically accept it in the forwarding chain. A rule must be made in the forwarding chain also.
1.5.4. Masquerading
There is a specialized case of Source NAT called masquerading: it should only be used for dynamically- assigned IP addresses, such as standard dialups. You don't need to put in the source address explicitly with masquerading: it will use the source address of the interface the packet is going out from. But more importantly, if the link goes down, the connections (which are now lost anyway) are forgotten, meaning fewer glitches when connection comes back up with a new IP address.
Masquerade everything out ppp0.
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
1.6.0. iptables.firewall Script Explanation (See Appendix A)
These rules are already contained in our file iptables.firewall. We do not cover the rules in exactly the same order as they appear in your file. Go through these rules and understand what exactly is being done.
1.6.1. Load the iptables modules and connection tracking for ftp and nat:
modprobe ip_tables modprobe iptable_nat modprobe ip_conntrack_ftp modprobe ip_nat_ftp
Configure default policies (-P), meaning default rule to apply if no more specific rule below is applicable. These rules apply if a more specific rule below is not applicable. Defaults are to DROP anything sent to firewall or internal network, permit anything going out. iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT ACCEPT
1.6.2. Flush (-F) all specific rules:
iptables -F INPUT iptables -F FORWARD iptables -F OUTPUT iptables -F -t nat The rest of this file contains specific rules that are applied in the order listed. If none applies, then the above policy rules are used. Forward all packets from vmnet1 (internal network) to vmnet2 (the internet). iptables -A FORWARD -i vmnet1 -o vmnet2 -j ACCEPT Forward all packets that are part of existing and related connections from vmnet2 to vmnet1. iptables -A FORWARD -i vmnet2 -o vmnet1 -m state --state ESTABLISHED,RELATED -j ACCEPT Permit packets in to firewall itself that are part of existing and related connections. iptables -A INPUT -i vmnet2 -m state --state ESTABLISHED,RELATED -j ACCEPT Note, in the above two rules, a connection becomes ESTABLISHED in the iptables PREROUTING chain upon receipt of a SYNACK packet that is a response to a previously sent SYN packet. The SYNACK packet itself is considered to be part of the established connection, so no special rule is needed to allow the SYNACK packet itself. Allow all inputs to firewall from the internal network and local interfaces iptables -A INPUT -i vmnet1 -s 0/0 -d 0/0 -j ACCEPT iptables -A INPUT -i lo -s 0/0 -d 0/0 -j ACCEPT
1.6.3.Forwarding
access anything. Iptables allows you to specify how many ICMP “echo” packets you want to reply to. This can be done by adding the following: iptables -A INPUT –p icmp –-icmp-type echo-request –m limit -–limit 30/minute –-limit-burst 1 –j ACCEPT
“30/minute’ means accept every other packet. An attacker may still ping flood you, but you
won’t reply to it anyways, and he will give up soon. However, this also allows other people to ping
you, just to test the network connection. The burst is set to 1 packet, so this limit will immediately take effect. Our Linux based firewall is already completely setup since the iptables.firewall file is provided for us, and all of the machines behind the firewall are protected from harmful traffic. We will now run some tests to show the results of the firewall installation.
Exercise 3
Turn on the firewall rules by typing ./iptables.firewall (in the directory where your iptables.firewall is placed) If you have enabled the firewall before, you will need to flush the rules before executing the above command. Now rerun nmap from outside the firewall (BlackHat) on the Linux machine behind the firewall (Protected). Run nmap with these options: SCAN -> SYN Stealth DISCOVER -> Don’t Ping OPTIONS -> Don’t resolve Fast Scan TIMING -> Max RTT 6ms The command is _nmap –sS –P0 –n –F –max_rtt_timeout 6 _ We must add this additional timing option because the firewall does not send a reset packet when nmap scans a closed port, it simply drops it. The RTT value specifies that nmap will not wait longer than 6ms for a response on a port. Note: 6ms is the smallest amount of time that is allowed for this option. In our case, since most packets will be dropped, increasing this value to something even as small as 40ms will cause this scan to take as long as 30 minutes. Q1.3. Write down which ports are open after the firewalls installation:
Exercise 4
Q1.4. What happened differently in the results from exercise three as opposed to exercise one? Can you speculate what firewall rules caused this?
Exercise 5
From BlackHat, we are going to ping the firewall to observe the rule which defends against icmp ping floods. The rule specified in this lab has the limit as 30/minute and a burst of 1. This means that every other packet will be denied and this rule will be enabled with the first packet. From your BlackHat, ping the firewall with these options: ping 131.210.231.1 –c 20 –w 4 Record this output in one window. Now change the rule in the iptables.firewall file to 10/minute and a burst of 5. Restart the firewall with the command /etc/rc.d/init.d/iptables stop ./iptables.firewall In another window from BlackHat ping the firewall with these options: ping 131.210.231.1 –c 20 –w 4 Q1.5. Comment on the differences between the first rule:
Exercise 6
Now run ethereal on the firewall machine. Run with the options capture packets on ‘any’ interface, update packets in real time, and automatic scrolling. From the linux machine behind the firewall, ping BlackHat, outside of the firewall, with the command: ping –c 1 131.210.231. Record the ethereal output and comment on the number of packets observed and their source and destination addresses. Now, edit iptables.firewall and comment out line 31 which reads: iptables -A FORWARD -i vmnet2 -o vmnet1 -m state --state ESTABLISHED,RELATED -j ACCEPT Restart the firewall with the command /etc/rc.d/init.d/iptables stop ./iptables.firewall Repeat the previous ping and record and comment on the differences. Q1.6. Uncomment line 31 and restart the firewall. Explain what you saw and why:
