1

ECE4112 Internetwork Security Lab 4: Firewalls

Group Number: _________ Member Names: ___________________ _______________________ Date Assigned: February 8, 2012 Date Due: February 16, 2012 Please read the entire lab and any extra materials carefully before starting. Be sure to start early enough so that you will have time to complete the lab. Answer ALL questions in the Answer Sheet and be sure you turn in ALL materials listed in the Turn-in Checklist on or before the Date Due. NOTE: Part 3 of the lab requires you to reserve slots to use the equipment. The signup sheets will be posted on the lab door. The equipment you need to sign up for will not be available at the last minute. PLAN AHEAD. The three sections of this lab may be done in any order.

Goal: This lab will introduce to the concept of Firewalls. You will be experimenting with different kinds of firewalls.

Summary: This lab is divided into three major parts. Part 1 explores the Linux firewall implementation in the form of the iptables program. Part 2 is a small introduction to Real Secure, one of the most popular Windows firewall programs. In Part 3, you will configure a Cisco PIX 515E firewall for a particular network structure. Part 1 and 3 might each take 2 hours or more, to finish. Therefore it is recommended that you start early.

Background: None

Prelab Questions: None

Lab Scenario: NOTE: Part 3 of the lab requires you to reserve slots to use the equipment. The signup sheets will be posted on the lab door. For Part 1 of this lab, you will be setting up two virtual machines on your hard drive. One of the two will represent a protected machine inside a firewall, while the other will represent an attacker. We will use the host machine (WS 4.0) as a router that implements a firewall. The virtual machine network structure is

2

shown below. These machines will be set up with host only networking, meaning any traffic they send or receive goes through the host machine. The host machine will be using the iptables program.

Figure 1-1. Network structure on the Firewall machines System Setup Protected Image on the NAS: This image is a normal Linux virtual machine with IP 192.168.0.10, netmask 255.255.255.0, and gateway 192.168.0.1. The gateway is a virtual interface on the host machine which acts like a router and firewall. This is the machine that is on the inside network and needs to be protected with the firewall. Linux Firewall: Red Hat WS 4.0 base system that is configured to act like a router and runs a firewall with ipchains. It forwards packets received on its two virtual interfaces (vmnet1 and vmnet2) to the intended destinations. You will make firewall rules on this machine to protect the inside network. BlackHat Image on the NAS: Same configuration as the protected machine. IP address is 131.210.231.55 and gateway is 131.210.231.1, which is the virtual interface vmnet2 on the host machine. This is the machine where you will try to attack the protected machine from. Configuring the network Before configuring the firewall on the host machine, we must first setup the network described in Figure 1-1. Two virtual machine images have been placed on the NAS under the Lab 4 Folder for you to use: Protected and BlackHat. Both of these are Red Hat Linux WS 4.0 images. Copy the directories BlackHat and Protected to the folder that you have placed all other vmware images. This may take a few minutes per image. Note: The root passwords for these machines have been set to

3

“password”. Before we create a virtual machine in VMWare, we must first configure both machines for host-only networking. From your WS4 Host machine, run the vmware-config.pl $ /usr/bin/vmware-config.pl Use the following answers: Accept the default directories for the first two questions. Accept the default “yes” for the question about building a vmon module for your system. Again accept the default directory for the location of the C header files. “Would you like to skip networking setup and keep you old settings as they are?” No Do you want networking for your virtual machines? Yes Would you prefer to modify your existing network configuration using the wizard or the editor? Editor Do you wish to make any changes to the current virtual networks settings? Yes Which Virtual network do you wish to configure? (0-99)1 The network vmnet1 has been reserved for a host-only network. You may change it, but it is highly recommended that you use it as a host-only network. Are you sure you want to modify it? (yes/no) [no] Yes What type of virtual network do you wish to set vmnet1? (bridged,hostonly,nat,none) [none] Hostonly Configuring a host-only network for vmnet1. Do you want this program to probe for an unused private subnet? (yes/no/help) [yes] No What will be the IP address of your host on the private network? 192.168.0.10 (see Figure 1-1) What will be the netmask of your private network? 255.255.255.0 The following virtual networks have been defined: . vmnet0 is bridged to eth0 . vmnet1 is a host-only network on private subnet 192.168.0.10 Do you wish to make additional changes to the current virtual networks settings ?(yes/no) [yes]Yes Which Virtual network do you wish to configure? (0-99)2 What type of virtual network do you wish to set vmnet2? (bridged,hostonly,nat,none) [none] Hostonly Configuring a host-only network for vmnet2. Do you want this program to probe for an unused private subnet? (yes/no/help) [yes] No What will be the IP address of your host on the private network? 131.210.231.55 (d is from table on page 2) What will be the netmask of your private network? 255.255.255.0 The following virtual networks have been defined: . vmnet0 is bridged to eth0 . vmnet1 is a host-only network on private subnet 192.168.0.1. . vmnet2 is a host-only network on private subnet 131.210.231.1.

4

Do you wish to make additional changes to the current virtual networks settings ?(yes/no) [yes]No Starting VMware services: Virtual machine monitor [ OK ] Virtual ethernet [ OK ] Bridged networking on /dev/vmnet0 [ OK ] Host-only networking on /dev/vmnet1 (background) [ OK ] Host-only networking on /dev/vmnet2 (background) [ OK ] What this has done is set up two virtual Host-Only Networks on /dev/vmnet1 and /dev/vmnet2. We are using the host-only networks to act like two independent subnetworks. Each virtual machine will act as if we are connecting it to an extra network card in the host. Start VMware by typing vmware &. In another terminal type ifconfig. All of the host-only networks appear along with eth0 and eth1, functioning as if they were physical network cards. Start both your WS4 virtual machines (refer to lab 1 if you forgot how to add a virtual machine). Right click on the tab that lists the name of the machine, and go down to “Settings”. The setting for “Ethernet1” needs to be changed from “Bridged” to “Custom: Specific virtual network”. The drop down box then needs to be set to either /dev/vmnet1 or /dev/vmnet2 depending on the specific virtual machine. Check the network diagram on Figure 1-1. Click on the RedHat Icon on the virtual machines and go to System Settings -> Network. Click on Edit to modify your settings, and change your gateway (see network diagram on Figure 1-1 again). Also uncheck “Bind to MAC address” under the Hardware Devices Tab. Make sure the IP address is correct for each virtual machine. The gateway should be the IP of the host machine for the specific virtual network you are setting up. So for the protected virtual machine, the IP address will be 192.168.0.10 and the gateway will be 192.168.0.1. Click OK. Then, click Deactivate, Activate, Apply. Close to change your settings. Try pinging your host machine from each virtual machine. $ping 192.168.0.1 (from protected terminal) $ping 131.210.231.1 (from BlackHat Terminal) Now that we have bound the virtual machines to our host, it is time to allow for packet forwarding through the host machine so that each virtual machine can communicate. On the host machine: To allow your host to forward or route IP packets, you need to type the following: $echo 1 > /proc/sys/net/ipv4/ip_forward This places a 1 in the file /proc/sys/net/ipv4/ip_forward. Check to make sure this command was successful by typing $cat /proc/sys/net/ipv4/ip_forward (1 should be printed on your screen).

5

This configuration is reset each time your physical machine is rebooted, so you must retype this command every time you reboot! You should be able to ping the Protected machine from the BlackHat machine.

1. Linux Firewalls

In this section of the lab you will explore the Linux firewall iptables. The initial sections give an overview of basic firewall concepts with exercises and examples. In the later sections, you will implement rules in the iptables.firewall file available from the Lab 4 directory on the NAS server. The effects of these rules are to be examined. We will be using the “Protected” and “Blackhat” machines, as shown in Figure 1-1. The host machine will act as the firewall. Setting up routing and iptables Some of the information given in this section will only be clear and useful later on when you actually use iptables.

The executable binary for the iptables application is the /sbin/iptables file. So when you execute iptables this is the file that is executed. RedHat also has an executable script in the /etc/init.d/iptables file so that it can start its default firewall at startup. An easy way to reset the firewall rules is to use this script as

/etc/rc.d/init.d/iptables stop This flushes all the rules in memory and gives you a clean start. You can flush individual rules with iptables –F flushes all chains iptables –X <chain name> deletes a chain iptables –X deletes all chains To check if there are any current rules, type iptables –L It’ll show you a couple of chains, but there won’t be any rules in them. You might have to do /etc/init.d/iptables restart to apply these changes (note: this is a different command than the one you used above).

Obtain the file iptables.firewall from the NAS in the lab4 folder. This file contains all of the firewall rules we will use in this lab. The contents of this file are included in Appendix A so you may follow the lab discussion in that file. You can execute this file to enable all the rules at once by executing it. Don’t execute it yet.

Later in the lab, every time you need to restart the firewall with your rules, you can use the following commands:

/etc/rc.d/init.d/iptables stop ./iptables.firewall (in the directory with your edited iptables.firewall file)

6

Again as a reminder, to enable packet forwarding on the Firewall machine, the line below needs to be executed.

echo “1” > /proc/sys/net/ipv4/ip_forward

This has already been done above, but remember that this command needs to be executed at restart. What this will do is to allow any FORWARD chain rules to be followed. This will make more sense later when we discuss packet forwarding in sections 1.2, 1.5 and 1.6. For now, just make certain that it is enabled by typing cat /proc/sys/net/ipv4/ip_forward

1.1.1. Background Only you can protect your system….. Firewalls have become one of the most popular ways to help secure a network. A firewall is hardware, software, or a combination of the two that prevents unauthorized access to or from a private network. Think of it as Internet customs and immigration. The firewall is the agent that checks each item entering or leaving the network. Each item must pass the right criteria in order to make it through. So a hacker attempting to enter the network of California with a Florida orange would be stopped at the border. Firewalls use one or more of three methods to control traffic flowing in and out of the network: • Packet filtering - Packets (small chunks of data) are analyzed against a set of filters. Packets that

make it through the filters are sent to the requesting system and all others are discarded. • Proxy service - Information from the Internet is retrieved by the firewall and then sent to the

requesting system and vice versa. • Stateful inspection - A newer method that doesn't examine the contents of each packet but instead

compares certain key parts of the packet to a database of trusted information. Information traveling from inside the firewall to the outside is monitored for specific defining characteristics, then incoming information is compared to these characteristics. If the comparison yields a reasonable match, the information is allowed through. Otherwise it is discarded.

Exercise 1 No firewall functionality running

From the BlackHat machine, use nmap to scan the Linux Machine behind the firewall. You can use the graphical interface for nmap with these options: SCAN -> SYN Stealth DISCOVER -> Don’t Ping OPTIONS -> 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:

7

1.1.2. Firewall Configuration Firewalls are customizable. This means that you can add or remove filters based on several conditions. Some of these are:

• IP addresses • Domain names • Protocols -

IP (Internet Protocol) - the main delivery system for information over the Internet TCP (Transport Control Protocol) - used to break apart and rebuild information that

travels over the Internet HTTP (Hyper Text Transfer Protocol) - used for Web pages FTP (File Transfer Protocol) - used to download and upload files UDP (User Datagram Protocol) - used for information that requires no response, such as

streaming audio and video ICMP (Internet Control Message Protocol) - used by a router to exchange the

information with other routers SMTP (Simple Mail Transport Protocol) - used to send text-based information (e-mail) SNMP (Simple Network Management Protocol) - used to collect system information

from a remote computer Telnet - used to perform commands on a remote computer

• Ports • Specific words and phrases - This can be anything. The firewall will sniff (search through) each

packet of information for an exact match of the text listed in the filter. For example, you could instruct the firewall to block any packet with the word "X-rated" in it. The key here is that it has to be an exact match. The "X-rated" filter would not catch "X rated" (no hyphen). But you can include as many words, phrases and variations of them as you need.

A software firewall, such as RealSecure, can be installed on the computer in your home. This computer may be considered a gateway because it may provide the only point of access between your home network and the Internet.

With a hardware firewall, the firewall unit itself is normally the gateway. A good example is the Linksys Cable/DSL router. It has a built-in Ethernet card and hub. Computers in your home network connect to the router, which in turn is connected to either a cable or DSL modem. You configure the router via a Web-based interface that you reach through the browser on your computer. You can then set any filters or additional information.

Hardware firewalls are incredibly secure and not very expensive. Home versions that include a router, firewall, and Ethernet hub for broadband connections can be found for well under $100.

1.1.3. What It Protects You From:

There are many creative ways that unscrupulous people use to access or abuse unprotected computers. The level of security you establish will determine how many of these threats can be stopped by your firewall. The highest level of security would be to simply block everything. Obviously that defeats the purpose of having an Internet connection. But a common rule of thumb is to block everything, and then begin to select what types of traffic you will allow. You can also restrict traffic that travels through the firewall so that only certain types of information, such as e-mail, can get through. This is a good rule for businesses that have an experienced network administrator that understands what the needs are and knows

8

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.

9

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

10

The three circles represent the three chains mentioned above. When a packet reaches a circle in the diagram, that chain is examined to decide the fate of the packet. If the chain says to DROP the packet, it is killed there, but if the chain says to ACCEPT the packet, it continues traversing the diagram.

A chain is a checklist of rules. Each rule says ‘if the packet header looks like this, then here’s what to do with the packet’. If the rule doesn’t match the packet, then the next rule in the chain is consulted. Finally, if there are no more rules to consult, then the kernel looks at the chain policy to decide what to do. In a security-conscious system, this policy usually tells the kernel to DROP the packet.

1. When a packet comes in (say, through the Ethernet card) the kernel first looks at the destination of the packet: this is called ‘routing’.

2. If it’s destined for this box, the packet passes downwards in the diagram, to the INPUT chain. If it passes this, any processes waiting for that packet will receive it.

3. Otherwise, if the kernel does not have forwarding enabled, or it doesn’t know how to forward the packet, the packet is dropped. If forwarding is enabled, and the packet is destined for another network interface (if you have another one), then the packet goes rightwards on our diagram to the FORWARD chain. If it is ACCEPTed, it will be sent out.

4. Finally, a program running on the box can send network packets. These packets pass through the OUTPUT chain immediately: if it says ACCEPT, then the packet continues out to whatever interface it is destined for.

1.3.2. Creating your own rules

The iptables tool inserts and deletes rules form the kernel’s packet filtering table. Initially all chains are set to ACCEPT by default. A detailed description can be obtained from the man pages (man iptables).

Commands to change chains: (Note: Use upper case letters)

1. create a new chain (-N) delete an empty chain (-X) 2. list the rules for a chain (-L) 3. flush a chain (delete all rules in a chain) (-F)

Commands to add/delete rules: 1. Append a new rules to a chain (-A) 2. Delete a rule at some position in a chain, or the first that matches (-D)

Note: The examples in these sections only demonstrate particular rules. They may or may not work for the network setup for the lab.

1.4.0. Iptables Parameters

Parameters specify the type of packet that you are looking to match with your rule.

1.4.1. Specifying jump

If a packet matches one of your rules, you can tell the packet to jump to another chain with the ‘-j’ option

11

Example: #jump all packets in INPUT chain to the DROP chain iptables –A INPUT –j DROP

1.4.2. Specifying protocol

The protocol can be specified with the ‘–p’ option. Protocols can either be the number in the IP header or ‘tcp’, ‘udp’, or ‘icmp’ (case insensitive).

Example: #drop all icmp packets iptables –A INPUT –p icmp –j DROP

1.4.3. Specifying inversion

To invert (negate) any of your rules use the ‘!’ character Example: #drop all packets that are not tcp iptables –A INPUT –p ! tcp

1.4.4. Specifying interface

Interfaces can be specified with the ‘-i’ (input) and ‘-o’ (output) paramaters. Note, a rule in the INPUT chain checking with ‘-o’ will never match any packet and a rule in the OUTPUT chain checking with ‘-i’ will never match any packet.

Example: #check packets coming in from the eth0 interface iptables –A INPUT –i eth0

1.4.5. Specifying source/dest

The source/dest address of the packet can be specified in 4 ways. The source/dest can be specified as a named address ( localhost, www.yahoo.com), by the IP address (e.g. 192.168.1.12), by group using network bits (e.g. 190.35.107.0/24 ), or by using network address/netmask ( e.g. 190.35.107.0/255.255.255.0 ) Although this next example is not in our iptables.firewall take a look at this example:

Example: #allow tcp packets coming from 130.207.232.1/24 machines to 50.60.23.45 machine iptables –A INPUT –s 130.207.232.1/24 –d 50.60.23.45 –p tcp

1.4.6 . State matching

12

If the ‘ip_conntrack’ module is loaded, then connection-tracking analysis can be done on packets. You can check my typing lsmod. The module can be inserted using insmod ip_conntrack.

The states which can be checked are: NEW A packet which creates a new connection ESTABLISHED

A packet which belongs to an existing connection (i.e., a reply packet, or outgoing packet on a connection which has seen replies).

RELATED

A packet which is related to, but not part of, an existing connection, such as an ICMP error, or (with the FTP module inserted), a packet establishing an ftp data connection.

INVALID

A packet which could not be identified for some reason: this includes running out of memory and ICMP errors which don’t correspond to any known connection. Generally these packets should be dropped.

An example of this powerful extension would be:

iptables –A FORWARD –i eth0 –m state ! –state NEW –j DROP

1.4.7 - Limit explanation

This module must be explicitly specified with `-m limit' or `--match limit'. It is used to restrict the rate of matches, such as for suppressing log messages. It will only match a given number of times per second (by default 3 matches per hour, with a burst of 5). It takes two optional arguments:

--limit

Followed by a number; specifies the maximum average number of matches to allow per second. The number can specify units explicitly, using `/second', `/minute', `/hour' or `/day', or parts of them (so `5/second' is the same as `5/s').

--limit-burst

Followed by a number, indicating the maximum burst before the above limit kicks in.

This match can often be used with the LOG target to do rate-limited logging. To understand how it works, let's look at the following rule, which logs packets with the default limit parameters:

# iptables -A FORWARD -m limit -j LOG

13

The first time this rule is reached, the packet will be logged; in fact, since the default burst is 5, the first five packets will be logged. After this, it will be twenty minutes before a packet will be logged from this rule, regardless of how many packets reach it (60 minutes / 3 packets per hour). This value of twenty minutes is because the default limit is 3/hour. Also, every twenty minutes which passes without matching a packet, one of the burst will be regained; if no packets hit the rule for 100 minutes, the burst will be fully recharged to 5 packets (100 minutes / 20mintes per packet); back where we started.

Note: you cannot currently create a rule with a recharge time greater than about 59 hours, so if you set an average rate of one per day, then your burst rate must be less than 3.

You can also use this module to avoid various denial-of-service attacks (DoS) with a faster rate to increase responsiveness.

Syn-flood protection (recall Datapool utility from Lab 3 for DoS using Syn Flood):

# iptables -A FORWARD -p tcp --syn -m limit --limit 1/s -j ACCEPT or # iptables –N SYN-FLOOD # iptables –A SYN-FLOOD –m limit –-limit 20/s –-limit-burst 100 –j RETURN # iptables –A SYN-FLOOD –j LOG –-log-prefix “SYN-FLOOD: ” # iptables –A INPUT –p tcp –-syn –j SYN-FLOOD

Furtive port scanner:

# iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 1/s -j ACCEPT

Ping of death:

# iptables -A FORWARD -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT UDP Attack (from Lab 3): # iptables –N UDP-FLOOD # iptables –A UDP-FLOOD –m limit –-limit 20/s –-limit-burst 100 –j RETURN # iptables –A UDP-FLOOD –j LOG –-log-prefix “UDP-FLOOD: “ # iptables –A UDP-FLOOD –j DROP # iptables –A INPUT –p udp –j UDP-FLOOD

1.5.0. Network Address Translation (NAT)

There are two types of NAT, source NAT and destination NAT.

Source NAT is when you alter the source address of the first packet: i.e. you are changing where the connection is coming from. Source NAT is always done post-routing, just before the packet goes out onto the wire. Masquerading is a specialized form of SNAT. A router might do masquerading for packets going from one of its internal machines to an outside connection. In this case it will change the source

14

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.

15

1.5.2. Iptables and NAT

Figure 1-4 – NAT with Iptables

In order to explain the iptables.firewall commands in the next section, (see iptables.firewall in Appendix A now) you need the following details:

The most important option for the iptables command is the table selection option, `-t'. For all NAT operations, you will want to use `-t nat' for the NAT table. The second most important option to use is `-A' to append a new rule at the end of the chain (e.g. `-A POSTROUTING'), or `-I' to insert one at the beginning (e.g. `-I PREROUTING').

You can specify the source (`-s' or `--source') and destination (`-d' or `--destination') of the packets you want to NAT. These options can be followed by a single IP address (e.g. 192.168.1.1), a name (e.g. www.gnumonks.org), or a network address (e.g. 192.168.1.0/24 or 192.168.1.0/255.255.255.0).

You can specify the incoming (`-i' or `--in-interface') or outgoing (`-o' or `--out-interface') interface to match, but which you can specify depends on which chain you are putting the rule into: at PREROUTING you can only select incoming interface, and at POSTROUTING you can only select outgoing interface. If you use the wrong one, iptables will give an error.

You want to do Source NAT; change the source address of connections to something different. This is done in the POSTROUTING chain, just before it is finally sent out; this is an important detail, since it means that anything else on the Linux box itself (routing, packet filtering) will see the packet unchanged. It also means that the `-o' (outgoing interface) option can be used.

DNAT is done in the PREROUTING chain, just as the packet comes in; this means that anything else on the Linux box itself (routing, packet filtering) will see the packet going to its `real' destination. It also means that the `-i' (incoming interface) option can be used.

1.5.3. Port Forwarding

16

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 A)

These rules are already contained in our file iptables.firewall. We do not cover the rules in exactly the same order as they appear in your file. Go through these rules and understand what exactly is being done.

1.6.1. Load the iptables modules and connection tracking for ftp and nat:

modprobe ip_tables modprobe iptable_nat modprobe ip_conntrack_ftp modprobe ip_nat_ftp

Configure default policies (-P), meaning default rule to apply if no more specific rule below is applicable. These rules apply if a more specific rule below is not applicable. Defaults are to DROP anything sent to firewall or internal network, permit anything going out.

iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT ACCEPT

17

1.6.2. Flush (-F) all specific rules:

iptables -F INPUT iptables -F FORWARD iptables -F OUTPUT iptables -F -t nat

The rest of this file contains specific rules that are applied in the order listed. If none applies, then the above policy rules are used.

Forward all packets from vmnet1 (internal network) to vmnet2 (the internet).

iptables -A FORWARD -i vmnet1 -o vmnet2 -j ACCEPT

Forward all packets that are part of existing and related connections from vmnet2 to vmnet1.

iptables -A FORWARD -i vmnet2 -o vmnet1 -m state --state ESTABLISHED,RELATED -j ACCEPT

Permit packets in to firewall itself that are part of existing and related connections.

iptables -A INPUT -i vmnet2 -m state --state ESTABLISHED,RELATED -j ACCEPT

Note, in the above two rules, a connection becomes ESTABLISHED in the iptables PREROUTING chain upon receipt of a SYNACK packet that is a response to a previously sent SYN packet. The SYNACK packet itself is considered to be part of the established connection, so no special rule is needed to allow the SYNACK packet itself. Allow all inputs to firewall from the internal network and local interfaces iptables -A INPUT -i vmnet1 -s 0/0 -d 0/0 -j ACCEPT iptables -A INPUT -i lo -s 0/0 -d 0/0 -j ACCEPT

1.6.3.Forwarding

Forward all http packets (port 80) to the internal VMware machine

iptables -A PREROUTING -t nat –d 131.210.231.1 -p tcp --dport 80 -j DNAT --to 192.168.0.10:80 iptables –A FORWARD –i vmnet2 –p tcp -–dport 80 –j ACCEPT

Forward all ssh packets (port 22) to the inside machine

iptables -A PREROUTING -t nat –d 131.210.231.1 -p tcp --dport 22 -j DNAT

18

--to 192.168.0.10:22 iptables –A FORWARD –i vmnet2 –p tcp -–dport 22 –j ACCEPT

Turn on ip forwarding in case it wasn't already enabled

echo "1" > /proc/sys/net/ipv4/ip_forward

1.6.4. Alternative to SNAT -- MASQUERADE

If your firewall has a dynamic IP number (most cable/DSL providers, such as ATT and Bellsouth, and all dial-up connections only offer dynamic IPs) because it connects to the internet itself via DHCP, then you probably cannot predict what the IP number is of your firewall's interface connected to the internet. In this case, you need a rule like the following that assigns the (an) IP number associated with vmnet2 to outgoing connections without you needing to know in advance (at time of writing this rule) what that IP number is: iptables -A POSTROUTING -t nat -o vmnet2 -j MASQUERADE Deny any packet coming in on the public internet interface vmnet2 which has a spoofed source address from our local networks: iptables -A INPUT -i vmnet2 -s 192.168.0.0/24 -j DROP iptables -A INPUT -i vmnet2 -s 127.0.0.0/8 -j DROP If you query a particular remote DNS server, permit UDP responses from it.

iptables -A INPUT -p udp -s <remote DNS server IP> --source-port 53 -d 0/0 -j ACCEPT

1.6.5. Defending against ICMP Ping Floods

ICMP ping floods are commonly used attacks, especially by “script kiddies.” The attack is really simple, the attacker ping floods you and if he has more upstream than your downstream, you won’t be able to access anything. Iptables allows you to specify how many ICMP “echo” packets you want to reply to. This can be done by adding the following:

iptables -A INPUT –p icmp –-icmp-type echo-request –m limit \ -–limit 30/minute –-limit-burst 1 –j ACCEPT

“30/minute’ means accept every other packet. An attacker may still ping flood you, but you won’t reply to it anyways, and he will give up soon. However, this also allows other people to ping you, just to test the network connection. The burst is set to 1 packet, so this limit will immediately take effect.

19

Our Linux based firewall is already completely setup since the iptables.firewall file is provided for us, and all of the machines behind the firewall are protected from harmful traffic. We will now run some tests to show the results of the firewall installation.

Exercise 3

Turn on the firewall rules by typing ./iptables.firewall (in the directory where your iptables.firewall is placed) If you have enabled the firewall before, you will need to flush the rules before executing the above command.

Now rerun nmap from outside the firewall (BlackHat) on the Linux machine behind the firewall (Protected).

Run nmap with these options:

SCAN -> SYN Stealth DISCOVER -> Don’t Ping OPTIONS -> Don’t resolve

Fast Scan TIMING -> Max RTT 6ms

The command is nmap –sS –P0 –n –F –max_rtt_timeout 6 <Protected Linux machine IP> We must add this additional timing option because the firewall does not send a reset packet when nmap scans a closed port, it simply drops it. The RTT value specifies that nmap will not wait longer than 6ms for a response on a port. Note: 6ms is the smallest amount of time that is allowed for this option. In our case, since most packets will be dropped, increasing this value to something even as small as 40ms will cause this scan to take as long as 30 minutes. Q1.3. Write down which ports are open after the firewalls installation:

Exercise 4

Q1.4. What happened differently in the results from exercise three as opposed to exercise one? Can you speculate what firewall rules caused this?

Exercise 5

From BlackHat, we are going to ping the firewall to observe the rule which defends against icmp ping floods. The rule specified in this lab has the limit as 30/minute and a burst of 1. This means that every other packet will be denied and this rule will be enabled with the first packet.

From your BlackHat, ping the firewall with these options:

ping 131.210.231.1 –c 20 –w 4

20

Record this output in one window.

Now change the rule in the iptables.firewall file to 10/minute and a burst of 5. Restart the firewall with the command

/etc/rc.d/init.d/iptables stop ./iptables.firewall

In another window from BlackHat ping the firewall with these options:

ping 131.210.231.1 –c 20 –w 4

Q1.5. Comment on the differences now as opposed to the first rule used above:

Exercise 6

Now run ethereal on the firewall machine. Run with the options capture packets on ‘any’ interface, update packets in real time, and automatic scrolling.

From the linux machine behind the firewall, ping BlackHat, outside of the firewall, with the command:

ping –c 1 131.210.231.55

Record the ethereal output and comment on the number of packets observed and their source and destination addresses.

Now, edit iptables.firewall and comment out line 31 which reads:

iptables -A FORWARD -i vmnet2 -o vmnet1 -m state --state ESTABLISHED,RELATED -j ACCEPT

Restart the firewall with the command

/etc/rc.d/init.d/iptables stop ./iptables.firewall

Repeat the previous ping and record and comment on the differences.

Q1.6. Uncomment line 31 and restart the firewall. Explain what you saw and why:

Exercise 7

Restart ethereal on the firewall machine. Run with the options capture packets on ‘any’ interface, update packets in real time, and automatic scrolling.

From BlackHat, ssh to 131.210.231.1

Q1.7. Record these output in ethereal and comment on what you saw happen:

21

Exercise 8

Now we are going to log any packets attempting to telnet to the firewall using the LOG chain.

iptables –A INPUT –d 131.210.231.1 –p tcp --dport 23 –j LOG --log-prefix ‘TELNET ATTEMPT: ‘

Attempt to telnet from Black Hat to the firewall. Check /var/log/messages for these telnet attemps and record the output from the messages file. type tail /var/log/messages to see the end of the /var/log/messages file.

Q1.8. What did you see:

Exercise 9

Q1.9. Write down three rules that you think might be useful and explain what they do.

You are now done with the Firewall Machine. Move the backup of the iptables file which you had created back into the /root/fresh_iptables directory to reset the firewall. Now that you have set up a Firewall to filter unwanted traffic and block ports, we are going to explore a way to get around firewalls. One such way is through tunneling. Tunneling is wrapping one protocol within another one, the protocol you are wrapping is one that would not get by the firewall and the protocol you wrap it with is something that would get through the firewall. For example, you could hide shell commands inside of an http get tcp command. If you are allowing users to use the web in your DMZ, port 80s will be open and those packets will not be filtered. SSH Bouncing through a Firewall Using Netcat

Say you have a firewall and have multiple computers behind it that you want to access remotely using SSH. Intuitive options include either:

• SSH to the firewall and then SSH to the target computer; however, this is a pain if you

need to transfer files because you will have to transfer them to the firewall first. • Forward ports to different computers to login remotely using non standard SSH ports.

This will require you to know which computer is at which port. This will also create public key conflicts.

However, with the help of netcat, you can create some scripts that will let you connect to

any computer behind the firewall as if it there where no hops in between.

We are going to do this by using the firewall setup in the lab. Again this is how the firewall is setup.

22

Figure 1-1: Netwrok structure on the Firewall machines

Perform the following steps in the BlackHat machine:

• Create a file named config in /root/.ssh

vi /root/.ssh/config

• Write the following information in this file:

Host protected Hostname 192.168.0.10 HostKeyAlias protected ProxyCommand netcat-proxy-command 131.210.231.1 %h

Here Hostname is the computer behind the firewall, netcat-proxy-command is a script which we will create in the next step and %h is the local host name (linux replaces it automatically).

• Now make a script in /usr/local/sbin named netcat-proxy-command

vi /usr/local/sbin/netcat-proxy-command

• Write the following in the file:

#!/bin/sh bouncehost=$1 target=$2

ssh $bouncehost nc -w 1 $target 22

This script will create a proxy that will connect to the target computer behind the firewall after getting to the Firewall computer. Now make this script executable:

chmod +x /usr/local/sbin/netcat-proxy-command

23

On your host machine:

• You will now need to comment out the line your iptables.firewall script that forwards port 22 (SSH).

• Restart the iptables.firewall script with the command:

/etc/rc.d/init.d/iptables stop ./iptables.firewall Now you can SSH from BlackHat to any computer behind the firewall defined in the

.ssh/configure file by typing the following command: ssh <HostKeyAlias> For example, you can SSH to the protected computer by running the following command: ssh protected The shell will ask for the password of firewall and then the password of Protected. Your

window should look like the following screen shot.

24

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.

25

NOTE: In order to access the NAS in the next section, you will need to either shutdown iptables or add a rule to allow all packets on the eth0 interface.

1.6.6 Reverse WWW Shell

Reverse WWW Shell is a tunneling program that uses an interesting approach to tunneling. Instead of having the server listening on a port that can easily be detected, it has the server connect to the client to get instructions the client has left in a certain directory. The shell commands in the Reverse WWW Shell look like http get calls and go through port 80. Because they look like innocuous web traffic, even proxy firewalls will have a hard time determining if the packets are malicious. It also has a random time frame for accessing the client so that it doesn't appear to be automated, to make detection even more difficult. Another program that works in the same manner is HTun, which can be found at http://htun.runslinux.net This section will be done using your Red Hat 4.0 base machine as the master machine and the slave is the Red Hat 7.2 VM. Download the source from the NAS. We originally got this from http://www.thc.org/releases/rwwwshell-2.0.pl.gz Use the following commands to unzip and make executable: $ gunzip rwwwshell-2.0.pl.gz $ chmod +x rwwwshell-2.0.pl This is a shell script. So open it up in your favorite text editor and go to these lines # # MASTER CONFIG (specific for the MASTER) # $LISTEN_PORT=8080; # on which port to listen (80 [needs root] or 8080) $SERVER="127.0.0.1"; # the host to run on (ip/dns) (the SLAVE needs this!) We need to change the listen port to 80, since we have root on our master machine this is no problem, now enter the IP address of your machine that the slave will access. Now look at some of the options for the slave, we are going to need to change the timing of the system in order to get immediate feedback from our system, choose a time within the next 20 minutes for your SLAVE to check for commands. Also set the DEBUG field to no. You can also set eh delay between executing commands. Now that we have the slave set up we need to install it on our slave system. Open your Redhat 7.2 Virtual machine and transfer the perl file to it. You may use sftp or scp to do so. Now run: $ ./rwwwshell-2.0.pl slave now on the master run $ ./rwwwshell-2.0.pl master If you were successful the slave will connect to the master at the time entered in the code and allow you to type in root commands that will be executed on the slave system.

26

If you have your firewall running you can check to see whether the packets were filtered or not, they shouldn't be with the standard 80 port open. Q1.10 Open ethereal and capture a few of the shell packets, what is their format?

Q1.11 Why does the format of the protocol make it especially hard to catch with a firewall?

Q1.12 A common way network administrators check for backdoors running on their system is to do a “netstat -na” Do this on your slave system, do you see an open port for the reverse www shell? Why not?

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 from the NAS, the installation of RSDP requires a little preparation. Now double click EmployeeRSDP.exe. This will preform a silent, non-interactive, install. Now reboot your computer. A RSDP icon should appear in your task tray as in figure 1.

Figure 1. RSDP task tray icon. Now lets configure RSDP. Single click the icon in the task tray. This should open up to a window which looks like figure 2.

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 affected by it and how to resolve it. In this case the information is trivial; we caused the event by rebooting after install. Right now we have a default configuration of RSDP, let’s see what it does. On your Red Hat WS 4.0 machine, ping your windows box. #ping <windows XP IP> Stop the ping after a few seconds with ctrl-c You should see an output similar to figure 4.

Figure 4. Result of pinging windows machine. Now look at your windows machine, you should not see a new event in your RSDP window. This is due to the default behavior of the firewall. You may, or may not, want ICMP messages to be able to reach your computer. We will change this behavior in a moment. But while it is still in the default configuration lets use nmap to scan our windows machine. #nmapfe & This will open the graphical version of nmap. Now enter your windows XP machine's IP address and run nmap with the default entries, SYN stealth, TCP&ICMP, and OS detection should be selected. Click scan and see what it finds, this might take a while to finish. You should get the list that is in figure 5.

Figure 5. Nmap scan output.

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. Let’s try and harden our firewall. Click tools, and then edit settings, then select the firewall tab. Uncheck the boxes labeled allow NetBIOS neighborhood and allow Internet file sharing. We are not sharing files on our network, therefore these are merely security risks. If you are sharing files on your network then this action will cause you trouble. The packet log and evidence log tabs do just what they say. They allow you to log information from your firewall. This is typically a very good idea, but we won't check the logs in this lab section. Let’s go to the advanced rules section. Click tools, then advanced firewall settings. You should see a list of ports such as in figure 7.

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. Let’s remove it. Click ok. Click tools, and then edit settings, the select the management tab. Uncheck the box labeled Reporting enabled, and click yes on the pop up window. Click ok and go back to the advanced settings. Now we have disabled reporting, but we cannot edit the settings of these ports. These open ports are for the firewall software. Let’s leave them alone and add some rules to prevent nmap from scanning our computer. Click add and a window should pop up. In the name field enter ICMP blocker. Select IP type from the drop down menu and click the all addresses box. From the value drag down box select ICMP. Select both for the direction and forever as the time. Your window should now look like figure 8.

32

Figure 8. Firewall rule.

Now click Add. Go back to your Red Hat WS 4.0 machine and try to ping your windows machine. It should fail as in figure 9.

Figure 9. Ping results.

Ok, now we are part way to our goal. Now click on the rule for TCP port 135, this was one of the ports that nmap found open. Click modify and check the box to reject this traffic. Now click ok. Rerun nmap and look at its output, shown in figure 10. Success, not only are no ports open, but the OS fingerprinting failed. This exercise should show you how it is possible to create firewall rules to either allow, or block certain traffic. If, for example, you wanted to allow access to a web server hosted on this machine, you could easily add a rule to allow connections to port 80 from either a particular IP address, or from all addresses. This exercise should also show you that a default setup of a firewall may not be as secure as you would like and that testing a firewall once in place is required.

33

Figure 10. Nmap scan again. Windows Built-in Firewall Turn off your RealSecure Firewall. Check your process list for blackd.exe and if it is running end it. Now go back to the Red Hat WS 4.0 machine and run this command: nmap -sS -P0 -n -F -max_rtt_timeout 40 <Windows XP's IP> (or use nmapfe) Q2.1. List the open ports on the Windows XP machine. Now go to the Windows XP Virtual machine. 1. Click Start-->Settings -->Control Panels-->Network Connections-->Local Area Connections. 2. Click the Properties button. 3. Click the Advanced Tab. 4. Check the box next to “Protect my computer and network by limiting or preventing access to

this computer from the Internet”. This enables Windows' Internet Connection Firewall. 5. Now click the “Settings...” button. This allows you to configure the firewall. 6. Open the Security Logging Tab, and check the two check boxes next to “Log dropped

packets” and “Log Successful connections”. 7. Now click “Ok” 8. Click “Ok” 9. Click Close. Q2.2. Now that the firewall is configured and activated, list the open ports on the Windows XP machine. Q2.3. As far as personal firewall software goes, how does windows XP's ICF compared to Linux's iptables?

34

Sources:

1. Copied and pasted for firewall introduction and explanation Tyson, Jeff, “How Firewalls Work” http://computer.howstuffworks.com/firewall.htm/

2. Copied and pasted for IP Tables introduction

Steams, William “Adaptive Firewalls with IP Tables” http://www.ists.dartmouth.edu/IRIA/knowledge_base/adaptive_firewalls.htm

3. Copied and pasted for iptables chains and certain rules

Russell, Rusty, “Linux 2.4 Packet Filtering HOWTO” http://www.netfilter.org/documentation/HOWTO//packet-filtering-HOWTO.html

4. Startup script and basis for rules

Stephens, James C. http://www.sns.ias.edu/~jns/security/iptables/

5. Designing a DMZ

Scott Young March 26, 2001 http://www.sans.org/rr/firewall/DMZ.php

35

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

36

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

37

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 D.

Mode Prompt Unprivileged mode pixfirewall> Privileged mode pixfirewall# Configuration mode pixfirewall(config)# Monitor mode monitor>

38

ASA Security Levels.

The security level designates whether an interface is inside (trusted) or outside (untrusted) relative to another interface. An interface is considered inside in relation to another interface if its security level is higher than the other interface's security level and is considered outside in relation to another interface if its security level is lower than the other interface's security level. The primary rule for security levels is this:

Once the PIX is configured with the six basic commands, data may enter the PIX through an interface with a higher security level, pass through the PIX, and exit via an interface with a lower security level. Conversely, data that enters an interface with a lower security level cannot pass through the PIX and exit via an interface with a higher security level without a conduit or an access list (which is discussed later).

Security levels range from 0 to 100, and the following are more specific rules for these security levels:

• Security level l00 – This is the highest security level for an interface. It is used for the inside interface of the PIX Firewall. This is the default setting for the PIX Firewall and cannot be changed. Because 100 is the most trusted interface security level, the organization's network should be set up behind that interface.

• Security level 0 – This is the lowest security level. This security level is used for the outside interface of the PIX Firewall. This is the default setting for the PIX Firewall and cannot be changed. Because 0 is the least trusted interface security level, the most untrusted network should be behind this interface.

• Security levels 1-99 – These security levels can be assigned to the perimeter interfaces connected to the PIX Firewall. It is common to connect one of these perimeter interfaces to a network that acts as a demilitarized zone (DMZ). A DMZ is a device or network that is (usually) accessible to users from the untrusted environment. The DMZ is an isolated area, separate from the internal, trusted environment. Figure 3-2 is an example of a three-interface PIX Firewall.

Figure 3-2 – PIX Security levels.

. Source: Chapman, D. W. and Fox, A., Cisco Secure PIX Firewalls, Cisco Press. 2002

39

PIX interface

The basic commands to be used in the PIX command interface are shown in Appendix D. Go over these commands at this time and keep them in mind when you are doing the lab exercises. You will need most of them at that time. For example, the enable command will be used to get started with the firewall. It provides entrance to the privileged access modes. The configure terminal command is used to move from the privileged mode to the configuration mode. The command prompt in the mode is (config)# .You can also use the hostname command to change the hostname label on the prompts (e.g. hostname newname ). Now let’s try to configure the firewall for the network setup in the lab. Network setup You will need to understand the structure of the Mini-net in the lab, to complete this lab. The diagram describing the Mini-net should be posted on the back wall of the lab and is included latr in this lab. Figure 3.3 below shows more details. There are six autonomous systems – 4 Tier 2 systems and 2 Tier 1 systems. The firewall is located in the Enterprise – Cisco system. It is marked as the “Edge-fwall” in the diagram. You should be able to figure out the network and host address of the routers and interfaces from the diagram. If you’re having trouble reading the diagram, you can ask a TA for help. NOTE: It is important that you access the firewall only during your reserved slot. Accessing the firewall, while some other group is doing their lab, will mess up the configuration and both of you will have to start over. Connection to the Firewall On your host machine, use the following command: ifconfig eth0:0 192.168.254.x where x is the last octet of the first ip address you were assigned. Now ssh into the playstation1 setup using the following command: ssh playstation1@192.168.254.2 The password is “playstation1” Once you enter the password, you’ll see a port access menu. This menu lists all the ports the console manager is connected to. The port for firewall is 12. So press 12 and then Enter. Press Enter a couple of times and you’ll see the prompt for the Cisco firewall. Initial Configuration We’ll be starting from scratch so let’s first reset the firewall and put it back into its original factory settings. The current configuration is stored in the flash memory. The write erase

40

command erases this configuration in the memory. Next, you have to type the reload command. Since there is no configuration in memory, the firewall reverts to its original settings. Initially you’ll see the hostname set by the previous group, and the “>” prompt. In the commands given below, the “>” and the “#” sign refer to the prompts. Type them in to configure the firewall. Step 1 To enter the privileged mode, type > enable

Password: <Press ENTER> The prompt changes to # # write erase Erase PIX configuration in flash memory? [confirm]: <Press ENTER> # reload Proceed with reload? [confirm] : <Press ENTER> The firewall will reboot. Once it reboots, you’ll see the following question, Pre-configure PIX Firewall now through interactive prompts [yes]? <Type no and ENTER> Now you’ll see the default firewall prompt pixfirewall> You’ll be typing all the commands at this prompt now. Go over the configuration commands given in Appendix E at this time. You’ll be using them in this section. Step 2 Now, type in the commands given below. pixfirewall> enable Password: <ENTER> pixfirewall#

pixfirewall# configure terminal 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 In this step, we will use the nameif command to configure interface 2 as the dmz interface. Remember, interface 0 is defined as outside by default and interface 1 is inside by default. Go over the nameif command in appendix E to know how to use it. Now type the following

41

pixGxx(config)# nameif e2 dmz security50 pixGxx(config)# show nameif nameif ethernet0 outside security0 nameif ethernet1 inside security100 nameif ethernet2 dmz security50

Step 4 The interfaces will be enabled in this step to bring them up. They will be set for auto sensing 10/100 communications. Use the show interface command to display information about the interfaces. pixGxx(config)# interface e0 auto pixGxx(config)# interface e1 auto pixGxx(config)# interface e2 auto pixGxx(config)# show interface There will be configuration information printed out about each interface. The important things to note here is the first line about each interface. interface ethernet0 “outside” is up, line protocol is up interface ethernet1 “inside” is up, line protocol is up interface ethernet2 “dmz” is up, line protocol is up Step 5 It’s time now to assign IP address to the three interfaces. If you look closely at the firewall in the Mini-net diagram, you’ll see the IP address for the three interfaces.

42

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-dnsDell 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.0 pixGxx(config)# ip address inside <IP ADDRESS> 255.255.255.0 pixGxx(config)# ip address dmz <IP ADDRESS> 255.255.255.0

List the addresses that you assigned to the interfaces, below. Check to make sure you assigned the right address by using the following command. pixGxx(config)# show ip address

43

It’ll list the current IP addresses for the three interfaces. Step 6 If everything looked fine in the last step, you should save the configuration into the flash memory. You won’t have to do this part again for the rest of the lab. pixGxx(config)# write memory Building configuration… Cryptochecksum: 7af5c680 748b5ada 2eee0daa ab8fd68f [OK] pixGxx(config)# At this point you have correctly setup the network. There are some concepts and commands that have to be explained before you can proceed further. Network Address Translation Network Address Translation (NAT) enables the user to keep internal IP addresses (those behind the PIX Firewall) unknown to external networks. NAT accomplishes this by translating the internal, unregistered IP addresses, which are not globally unique, into registered, globally accepted IP addresses before packets are forwarded to the external network. NAT is implemented in the PIX Firewall with the nat and global commands. When an outbound IP packet that is sent from a device on the inside network reaches the PIX Firewall, the source address is extracted and compared to an internal table of existing translations. If the device’s address is not already in the table, it is then translated. A new entry is created for that device and it is assigned a global IP address from a pool of global IP addresses. This global pool can be configured with the global command. After this translation occurs, the table is updated and the translated IP packet is forwarded. After a user-configurable timeout period ( or the default of 3 hours), during which there have been no translated packets for that particular IP address, the entry is removed from the table and the global address is freed from use by another inside device. The global is used to assign a registered or public IP address to an internal host when accessing the outside network through the firewall. It can also be used to assign a pool of global IP addresses. The basic syntax of the command is given below. A more complete description can be found in Appendix E. Go over it once you’ve read this section to understand the command properly. global [(if_name)] nat_id {global_ip [-global_ip] [netmask global_mask]} Here, the nat_id is used to identify the particular pool of global IP addresses that are assigned. This nat_id should correspond to the nat_id used in the nat command, shown below.

44

The nat command can specify translation for a single host or a range of hosts. The basic syntax of the command is given below. A more complete description can be found in Appendix E. Go over it once you’ve read this section to understand the command properly. nat [(if_name)] nat_id address [netmask] The nat_id in this command should be the same as the one defined in the global command. As shown in the example, below, you can also enable translation for all inside hosts making outbound connections with the nat 1 0.0.0.0 0.0.0.0 command. This can be shortened to nat 1 0 0. Example: pixGxx(config)# nat (inside) 1 0.0.0.0 0.0.0.0 This command translates all the internal IP addresses into the global pool of addresses with nat_id 1 (defined in the global command). The route command can be used to setup a default route for packets going through the firewall. So, packets going to the outside interface can be set to go through a default router on the outside. The IP address of one of the PIX Firewall’s interfaces can also be used as a gateway router. So, for the internal network, the address of the inside interface can be set as the default gateway. In the lab, we use the OSPF protocol to configure the routers. Therefore, we will use the router command to have the firewall advertise its interface as the default gateway. It will configure the firewall interfaces to act like routers using the OSPF protocol. Now that you’ve had an overview of the configuration commands to be used, let’s go ahead and configure the firewall. Configure Global Addresses, NAT, and Routing for Inside and Outside Interfaces Follow the steps below to configure the firewall. Step 7 Assign a pool of registered IP address for use by the outbound connections. If you look at the Mini-net diagram, you can see that these addresses will be in the network 212.43.0.0/24. Let’s choose the range 212.43.0.100 – 212.43.0.199. The nat ID is 1. On the dmz the global IP range is 192.168.0.200-192.168.0.250. The nat ID is again 1. Because both the dmz and outside use a nat ID of 1, the internal IP’s can be translated to those in either global pool. pixGxx(config)# global (outside) 1 212.43.0.100–212.43.0.199 netmask 255.255.255.0 pixGxx(config)# global (dmz) 1 192.168.0.200-192.168.0.250 netmask 255.255.255.0 pixGxx(config)# show global global (outside) 1 212.43.0.100–212.43.0.199 netmask 255.255.255.0 global (dmz) 1 192.168.0.200-192.168.0.250 netmask 255.255.255.0

45

Step 8 Let’s assign these pools of addresses to a nat for internal addresses. pixGxx(config)# nat (inside) 1 0 0 This will allow all inside hosts to use NAT for outside and dmz access. Display this configuration with pixGxx(config)# show nat nat (inside) 1 0.0.0.0 0.0.0.0 0 0 Make sure that the nat ID, in the global and nat commands, matches. That allows you to have multiple nat pools. So, nat pool 1 could be used for hosts from subnet A, and nat pool 2 could be used for hosts from subnet B. Step 9 In order to direct traffic to other networks, you need to configure the router functionality. pixGxx(config)# router ospf 1 pixGxx(config-router)# network 212.43.0.0 255.255.255.0 area 0 pixGxx(config-router)# log-adj-changes pixGxx(config-router)# exit pixGxx(config)# router ospf 2 pixGxx(config-router)# network 172.16.2.0 255.255.255.0 area 0 pixGxx(config-router)# log-adj-changes pixGxx(config-router)# default-information originate always pixGxx(config-router)# exit pixGxx(config)# show router router ospf 1 network 212.43.0.0 255.255.255.0 area 0 log-adj-changes router ospf 2 network 172.16.2.0 255.255.255.0 area 0 log-adj-changes default-information originate always pixGxx(config)# These commands configured the firewall to act as an OSPF based router for the inside and outside interfaces. Step 10 Now let’s save the configuration to memory. pixGxx(config)# write memory At this time you can check that you entered the right command by typing

46

pixGxx(config)# show history You can also check the current configuration by typing pixGxx(config)# write terminal This will show you complete configuration in memory. It will have a lot of additional settings that you can look at. Step 11 First check that you have proper connectivity by pinging each of the interfaces of the firewall from the firewall. pixGxx(config)# ping <INSIDE INTERFACE IP> pixGxx(config)# ping <OUTSIDE INTERFACE IP> pixGxx(config)# ping <DMZ INTERFACE IP> Q3.1. Can you ping each of these? Now, ping hosts in the inside, dmz and outside domains. A machine called R2 has been setup on the inside network. It can be seen on the Mini-net diagram. The address for this machine is 172.16.2.99. The IP for the web server in the dmz zone is 192.168.0.10. For the outside zone, you can choose any of the routers. Can you ping each of these? Now type the command below. The meaning of this command will be explained in the next section. pixGxx(config) # access-list DMZ permit icmp any any pixGxx(config) # access-group DMZ in interface dmz It’s time to check your configuration to see if allows access from the inside. Do this from R2. You can access the R2 machine by using the server terminal in the server rack. R2 machine is located on switch number 2 on the KVM machine behind the terminal screen. Answer the following questions as you perform the tests. Q3.2. Can you ping the address of the server (192.168.0.10) ? Start the web browser and see if you can access the web server in the dmz zone. Type in the IP address of the server as http://192.168.0.10 . Can you see the default web site? This is the same as telneting to port 80 of this machine. Go back to the firewall terminal and type pixGxx(config)# show xlate (or show xlate detail) Q3.3. What does this command show? What does it mean?

47

Now check if you can access hosts on the outside interface. Using the mini-net network diagram as a guide, ping one of the edge routers on the 212.43.0.0/16 network (for example, you can ping 212.43.0.1). Let’s see if we can access things from the outside. Do this from your Red Hat WS 4.0 host machine Can you ping the web server (R1) in the dmz zone? Q3.4. Try to access it from a web browser and see if you can do that. You could also telnet to port 80 and check this. Can you do it? Q3.5. Finally, can you ping the R2 terminal machine from the outside? Q3.6. Describe how the firewall is configured at this point. What type of packets does it allow or disallow and from where? You can draw diagrams to explain this better. Configuring access to the DMZ zone from Outside To allow access connections from an interface with a lower security level to an interface with a higher security level, the static and conduit commands can be used. The static command creates static mapping between an inside IP address (in this case it means behind the firewall – inside interface or dmz interface) and a global IP address. Using the static command enables you to set a permanent global IP address for a particular inside IP address. This creates an entrance for the specified interfaces with the lower security level into the specified interface with a higher security level. After creating a static mapping between an inside IP address and a global IP address by using the static command, the connection from the outside interface to the dmz or inside interface is still blocked by the PIX Firewall’s Adaptive Security Algorithm (ASA). The conduit command can be used now to allow traffic to flow between the interfaces. This command creates the exceptions to the PIX Firewall’s ASA. However, the conduit command is obsolete in versions 6.2 and later of the PIX software. A better alternative is the access-list command to create Access Control Lists. The only reason conduit is still supported is to maintain backwards compatibility with previous versions of PIX. In this lab, we will use the access-list command along with the 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.

48

An ACL can be created with the access-list command. It enables you to specify if an IP address is permitted or denied access to a port or protocol. By default, all access in an access list is denied. You must explicitly permit it. The format of the access-list command is shown below access-list acl_IND deny | permit protocol source_addr dource_mask [operator port[port]] destination_addr destination_mask operator port[port] When specifying the IP address of a host as a source or destination, use the host keyword instead of the network mask 255.255.255.255. For example, use the following ACL entry to permit FTP traffic to host 192.168.1.1: access-list SAMPLEACL permit tcp any host 192.168.1.1 eq ftp A more detailed explanation of this format is given in Appendix E. You can also consult Cisco web resources listed, to gain more information. The no access-list command removes an access-list command from the configuration. For example, no access-list SAMPLEACL The access-group command binds the ACL to a specific interface on the Firewall. The ACL is applied to the traffic inbound on that interface. Only one ACL can be bound to an interface using this command. The no access-group command unbinds the acl_ID from the interface. For example, no 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 E. Further information can be obtained from the Cisco web resources, listed in the lab. Type in the following: pixGxx(config)# static (dmz, outside) 212.43.0.x 192.168.0.10

where x is the last octet of the first assigned ip address. Q3.7.Write the address of the web server, for the outside interface, below. Now type

49

pixGxx(config)# show static static (dmz,outside) 212.43.0.x 192.168.0.10 netmask 255.255.255.255 0 0 Create an Access Control List pixGxx(config)# access-list ACLDMZ permit tcp any host 212.43.0.x eq www Now add commands to permit inbound ICMP echo traffic to the server. All other traffic from outside will be denied by the implicit deny. pixGxx(config)# access-list ACLDMZ permit icmp any host 212.43.0.x Let’s bind this ACL to the outside interface. pixGxx(config)# access-group ACLDMZ in interface outside Display the access list and observe the hit counts. pixGxx(config)# show access-list ... access-list cached ACL log flows: total 0, denied 0 (deny-flow-max 1024) alert-interval 300 access-list ACLDMZ; 2 elements access-list ACLDMZ line 1 permit tcp any host 212.43.0.x eq www (hitcnt=3) access-list ACLDMZ line 2 permit icmp any host 212.43.0.x (hitcnt=23) Save your configuration pixGxx(config)# write memory Step 13 Check your configuration now by going to the terminal on the outside interface and accessing the address of the web server on the dmz interface that you defined. So if the address that you mapped the server to was 212.43.0.6, type wget http://212.43.0.6. wget does the same thing a web browser does, just without graphically displaying the index.html file. You can also do the same thing by telnet 212.43.0.x 80 Q3.8.Were you able to connect to the server from the outside? Can you ping this server from the outside? So, that’s it. If you can get access, you were able to configure a Cisco PIX firewall for basic functionality. Again describe the current configuration of the firewall. Q3.9.What kind of traffic does it allow and from where to where? You can draw diagrams to explain this. Turn in a printout of the output of the command, given below, with your lab.

50

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.

“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

PW R

OK

WI C0ACT/ CH0

ACT/CH1

WIC0ACT/ CH0

ACT/CH1

ETHACT

COL

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

.43R7

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

51

Appendix A iptables.firewall

#load the iptables modules and connection tracking for ftp and nat modprobe ip_tables modprobe iptable_nat modprobe ip_conntrack_ftp modprobe ip_nat_ftp # Configure default policies (-P), meaning default rule to apply if no # more specific rule below is applicable. These rules apply if a more specific # rule below is not applicable. Defaults are to DROP anything sent to firewall or # internal network, permit anything going out. iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT ACCEPT # Flush (-F) all specific rules iptables -F INPUT iptables -F FORWARD iptables -F OUTPUT iptables -F -t nat iptables -A INPUT -d 131.210.231.1 -p tcp --dport 23 -j LOG --log-prefix 'TELNET ATTEMPT: ' # The rest of this file contains specific rules that are applied in the order # listed. If none applies, then the above policy rules are used. # Forward all packets from vmnet1 (internal network) to vmnet2 (the internet). iptables -A FORWARD -i vmnet1 -o vmnet2 -j ACCEPT # Forward packets that are part of existing and related connections from # vmnet2 to vmnet1. iptables -A FORWARD -i vmnet2 -o vmnet1 -m state --state ESTABLISHED,RELATED -j ACCEPT # Permit packets in to firewall itself that are part of existing and related # connections. iptables -A INPUT -i vmnet2 -m state --state ESTABLISHED,RELATED -j ACCEPT # Note, in the above two rules, a connection becomes ESTABLISHED in the # iptables PREROUTING chain upon receipt of a SYNACK packet that is a # response to a previously sent SYN packet. The SYNACK packet itself is # considered to be part of the established connection, so no special # rule is needed to allow the SYNACK packet itself. # Allow all inputs to firewall from the internal network and local interfaces iptables -A INPUT -i vmnet1 -s 0/0 -d 0/0 -j ACCEPT iptables -A INPUT -i lo -s 0/0 -d 0/0 -j ACCEPT

52

# Alternative to SNAT -- MASQUERADE # # If your firewall has a dynamic IP number because it connects to the # internet itself via DHCP, then you probably cannot predict what the IP # number is of your firewall's interface connected to the internet. In # this case, you need a rule like the following that assigns the (an) IP # number associated with vmnet2 to outgoing connections without you needing # to know in advance (at time of writing this rule) what that IP number is: # iptables -A POSTROUTING -t nat -o vmnet2 -j MASQUERADE # Deny any packet coming in on the public internet interface vmnet2 # which has a spoofed source address from our local networks: iptables -A INPUT -i vmnet2 -s 192.168.0.0/24 -j DROP iptables -A INPUT -i vmnet2 -s 127.0.0.0/8 -j DROP # If you query a particular remote DNS server, permit UDP responses from it #iptables -A INPUT -p udp -s <remote DNS server IP> --source-port 53 -d 0/0 -j ACCEPT #prevent DoS by icmp flood iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 30/minute --limit-burst 1 -j ACCEPT #prevent DoS by tcp syn flood iptables -A INPUT -p tcp --syn -m limit --limit 1/s --limit-burst 1 -j ACCEPT #forward all http packets (port 80) to internal linux machine iptables -A PREROUTING -t nat -d 0/0 -p tcp --dport 80 -j DNAT --to 192.168.0.10:80 iptables -A FORWARD -i vmnet2 -p tcp --dport 80 -j ACCEPT #forward all ssh packets (port 22) to internal linux machine iptables -t nat -A PREROUTING -d 131.210.231.1 -p tcp --dport 22 -j DNAT --to 192.168.0.10:22 iptables -A FORWARD -i vmnet2 -p tcp --dport 22 -j ACCEPT # turn on ip forwarding in case it wasn't already enabled echo "1" > /proc/sys/net/ipv4/ip_forward

53

Appendix B Troubleshooting installation.

Getting rid of ipchains:

If your iptables script won’t correctly execute, and it gives an error about the device being busy then follow these steps. In order for iptables to work, ipchains must be turned off.

First of all you will need to turn off the ipchains modules so it won't start in the future. To do this, you will need to change some filenames in the /etc/rc.d/ directory-structure. The following command should do it:

chkconfig --level 0123456 ipchains off

To turn the service off immediately however, type the following:

service ipchains stop

54

Appendix C Reference Websites: Differences Between iptables and ipchains:

• http://www.netfilter.org/documentation/HOWTO/packet-filtering-HOWTO-10.html Small History of Filtering Under Linux:

• http://www.geekcomix.com/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 6, one of the reasons we found that companies do not use iptables more often is that it is strictly command line driven and that Cisco offers users an easier to use interface (as well as the traditional Cisco command line). We felt that more users might be willing to use iptables if there was an easier to use interface or a tool that could automate setting the firewall rules. On the website “http://online.securityfocus.com/infocus/1410” we looked at one such tool called AGT. AGT is downloadable from “http://sourceforge.net/projects/agt” and is very easy to install. It is downloaded as a gzipped tarball package that can be extracted by running the command # tar –xvfz agt-1.11.tar.gz Then cd into the agt-1.11 directory and issue a “make” command followed by a “make install” command. Once installed, the program runs from /usr/sbin/agt and the configuration file is at /etc/agt.rules. The program comes with full man pages as well. Due to the fact that the program needs a Linux installation with iptables running on it and it need access to more than one network in order to configure the firewall/gateway settings, this install would have been better suited to install on the iptables lab machine. However we did not have permission to do that so we installed it on our Linux host WS 4.0 workstation. To demonstrate some of it’s functionality we will take a look at a sample agt.rules file and point out some of the useful commands contained within it. The entire age.rules file is attached to this answer sheet as an appendix. In the first section, you can see that by default all incoming packets are dropped and all output and forward packets are accepted, shown by:

55

default input drop default output accept default 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/24 input accept on eth1 from 10.2.0.0/16 # or whatever your network is Since telnet is such a dangerous program to use (as illustrated in previous labs) it is often a good idea not to allow it into your firewall: input mirror on eth0 proto tcp port telnet And follow that up with: input accept on eth+ proto tcp port ssh Other important features of this file are the restriction that it can place during specific times like allowing IRC during lunchtime, CVS access on the weekends, etc. This gives administrators more control on employees and what they can do and when. While the underlying functionality of AGT is still iptables, and the user cannot do anything with AGT that they cannot do with iptables, we feel that this type of program is more intuitive than issuing the standard iptables commands like we did in our lab. This type of configuration is also easier in the sense that everything is contained in a configuration file where you can see all of your rules in one place rather than issuing single commands to iptables. Furthermore, this is just one example of a Linux firewall interface, there are other programs such as Knetfilter [http://expansa.sns.it/knetfilter/] that offer a full GUI interface to iptables that runs in KDE. A full GUI interface to iptables may not be that useful however because most administrators that use Linux for firewalls are doing so because they can run it on a very small machine that probably has limited resources and cannot handle X11 windows and KDE. But the point remains valid that there are alternatives to the traditional iptables command line interface that can make the Linux based firewall more appealing to users that cannot afford Cisco or other brands.

56

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/24 nat from 10.2.0.0/16 # port forward port 80 to 8080 on an internal machine. portfw proto tcp port 80 to 192.168.0.2:8080 # nat these private IP's to real IP's # the gateway has to have the real IP's aliased on an interface. # this is bi-directional. nat from 10.2.0.5 to 123.123.123.5 nat from 10.2.0.6 to 111.222.123.100 # ----------------------------- # create a new chain called 'mynewchain' new mynewchain # be paranoid by default, drop all incoming packets default input drop default output accept default forward accept # forward packets during weekdays, allow 1 machine all of the time forward accept from 10.0.0.0/8 days Mon,Tue,Wed,Thu,Fri forward accept from 10.0.0.20 forward drop

57

# for compatibilty, allow loopback :P input accept on lo # enable stateful packet tracking input accept on eth+ keep state # these networks are trusted, accept all traffic input accept on eth1 from internal/24 input accept on eth1 from 10.2.0.0/16 # only allow root to send packets through eth0 # options include uid/gid/pid/sid output accept on eth0 owner uid root output drop on eth0 # bounce telnet on eth0 back to the sender... # READ THE ADVISORIES BEFORE USING MIRROR TARGETS! # Improper use can lead to certain types of Denial of Service. input mirror on eth0 proto tcp port telnet # drop packets that seem to be invalid input drop invalid # we don't want broadcast packets (types = host/broadcast/multicast) input drop on eth0 pkttype broadcast # match strange looking packets input drop unclean # allow ssh on any interface input accept on eth+ proto tcp port ssh # only allow staff to telnet during office hours # (cp /usr/bin/telnet /home/myname/blah can bypass this) output drop cmd telnet group staff time-start 09:00 time-stop 17:00 days Mon,Tue,Wed,Thu,Fri # allow irc at lunchtime output accept port 6667 time-start 12:00 time-stop 13:00 output drop port 6667 # allow cvs access at the weekend input accept port 2401 days Sat,Sun input drop port 2401 # allow incoming ftp on Monday and Thursday input accept port ftp days Mon,Fri input drop port ftp # stop all connections for 30 minutes on Friday night input drop time-start 22:00 time-stop 22:30 days Fri # match based on packet length >50 but <120 input accept on eth+ proto tcp port 3000 length 50:120 # allow 512000 bytes before dropping input accept on eth+ proto tcp port http quota 512000

58

input drop on eth+ proto tcp port http # only allow 5 active ftp connections at once input drop on eth0 proto tcp port ftp limit 5 flags SYN # match this host's MAC address input accept on eth+ proto tcp port https mac 00:DE:AD:BE:EF:00 # match ftp, note that 'port' is equal to 'dport' input accept on eth+ proto tcp dport ftp # match multiple ports in one rule. input accept on eth+ proto tcp ports imap,imaps # allow connections to port 10000, if coming from port 4300 input accept on eth+ proto tcp port 10000 sport 4300 # allow 1 host to connect to our vpn :P input accept on eth+ proto tcp port pptp from host.somedomain.com # allow gre on any interface input accept on eth+ proto gre # block 50% of incoming pings, randomly. allow other icmp # valid icmp types obtained by running 'iptables -p icmp -h' # icmp-type is an alias for icmptype input drop on eth0 proto icmp icmptype echo-request random 50 input accept on eth+ proto icmp # not matched? close the TCP connection with a RST, others with host unreachable # valid 'with' options obtained by running 'iptables -j REJECT -h' input reject on eth+ proto tcp with tcp-reset input reject on eth+ with host-unreach

59

Appendix D

Commands for maintaining and testing the PIX Firewall.

• enable – If the password is known, the enable command allows a user to enter privileged mode. After entering enable, the PIX Firewall will prompt the user for the privileged mode password. To exit and return to the previous mode, use the disable, exit, or quit command. The command to set this password is enable password password. The password is encrypted within the configuration file.

• configure terminal – It you want to interactively change the configuration of the PIX, issue the configure terminal command. Any added configuration parameters are merged with the existing running configuration. When making a configuration change to the PIX, the change takes effect immediately and is saved in the running configuration in RAM.

• show configure – This displays the configuration that is stored in Flash memory (sometimes called the "startup configuration") on the terminal. Because Flash is 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.

60

Appendix E

Basic configuration commands of the PIX interface nameif Command

The command nameif assigns a name to each interface on the PIX Firewall and specifies its security level (except for the inside and outside PIX Firewall interfaces, which are named by default). NOTE – With the default configuration, Ethernet0 is named “outside” with a security level of 0 and Ethernetl is named “inside” and is assigned a security level of 100. nameif hardware_id if_name security_level hardware_id: Specifies a perimeter interface and its physical location on the PIX Firewall. if-name: Assigns a name to the physical perimeter interface. This name is assigned by the you, and must be used in all future configuration references to the perimeter interface. By default, el is the "inside" and e0 is the "outside." security_level Indicates the security level for the perimeter interface. Enter a security level of 1-99.

interface. Command

The interface command identifies the type of hardware, sets the hardware speed, and enables the interface. When an additional Ethernet interface card is installed on the PIX Firewall, the PIX Firewall automatically recognizes the additional card. interface hardware_id [hardware_speed] [shutdown] [] indicates optional commands hardware_id Specifies an interface and its physical location on the PIX Firewall. This is the same variable that was used with the nameif command. hardware_speed Determines the connection speed. Enter auto so the PIX Firewall can sense the speed needed for the device. shutdown Administratively shuts down the interface.

ip address Command

Each interface on the PIX Firewall must be configured with an IP address. After configuring the IP address and netmask, it is common to use the show ip command to view which addresses are assigned to the network interfaces. If a mistake is found, reenter the command with the correct information. ip address if_name ip_address [netmask]

. Source: Chapman, D. W. and Fox, A., Cisco Secure PIX Firewalls, Cisco Press. 2002

61

if-name Describes the interface. This name is assigned by the user and must be used in all future configuration references to the interface. ip_address The assigned IF address of the interface. netmask If a network mask is not specified, the classful network mask is assumed: Class A: 255.0.0.0 Class B: 255.255.0.0 Class C: 255.255.255.0

nat Command Network Address Translation (NAT) enables the user to keep internal IP addresses (those behind the PIX Firewall) unknown to external networks. As an example, when connecting to the Internet or other foreign network, the nat command accomplishes this by translating the internal, unregistered IP addresses, which do not have to be globally unique, into registered, globally accepted IP addresses before packets are forwarded to the external network. With the exception of nat 0, the nat command is always used with the global command. nat (if_name)nat_id local_ip [netmaskl (if-name) Describes the internal network interface name that will use global addresses. Data will exit the PIX through the interface specified in the global command. nat_id Identifies the global pool and matches it with its respective global command. local_ip The IP address(es) assigned to the devices on the inside network. 0.0.0.0 may be used to allow all outbound connections to translate with IP addresses from the global pool. netmask Network mask for the local IP address. When initially configuring the PIX Firewall, all inside hosts can be enabled to access outbound connections with the nat 1 0.0.0.0 0.0.0.0 command. The nat 1 0.0.0.0 0.0.0.0 command enables NAT and lets all inside hosts (specified as 0.0.0.0) access connections that are bound to the corresponding global command. The nat command can specify a single or range of hosts to make access more selective. When configuring, 0 can be used in place of 0.0.0.0.

global Command When sending data from a trusted network to an untrusted network, the source IP address is often translated. The PIX can do this with two commands. The first command is nat, which defines the trusted source addresses to be translated. The command that is used to define the address or range of addresses that the source address will become is the global command.

global [(if_name)] nat_id {global_ip [-global_ip] [netmask global_mask]}

62

if-name Describes the external network interface name where you will use the global addresses. nat _id Identifies the global pool and matches it with its respective nat command. interface Have the PIX translate alllP addresses specified by the nat command to the interface specified. global_ip Single IP addresses or the beginning IP address for a range of globallP addresses. -global_ip A range of globallP addresses. netmask global The network mask for the globallP. If subnetting is in effect, use the subnet mask.

When an outbound IP packet that is sent from a device on the inside network reaches the PIX Firewall, the source address is extracted and compared to an internal table of existing translations. If the device's address is not already in the table, it is then translated. A new entry is created for that device and it is assigned a global IP address from a pool of global IP addresses. This is called a translation slot. After this translation occurs, the table is updated and the translated IP packet is forwarded.

Figure 3-B-1 – NAT with PIX

route Command

63

The route command defines a static route for an interface. The route statement may have a specific destination, or a default static route may be created. route if_name ip_address netmask gateway_ip if-name Describes the internal or external network interface name. Data will exit from the PIX through this interface. ip_address Describes the destination internal or external network IP address. Use 0.0.0.0 to specify a default route (all destination networks). The 0.0.0.0 IP address can be abbreviated as 0. netmask Specifies a network mask to apply to ip_address. Use 0.0.0.0 to specify a default route. The 0.0.0.0 netmask can be abbreviated as 0. It is common to have one default route. gateway _ip Specifies the IP address of the gateway router (the next-hop address for this route).

static∗ Command

Provides a global IP address on a lower security interface, such as outside, that is mapped to a higher security interface, such as a DMZ server on the DMZ interface.

static (high_interface,low_interface) low_address high_address netmask netmask

high_interface The local or higher security interface

low_interface The global or lower security interface.

low_address The IP address for the machine on the low security interface.

high_address The local IP address for the machine on the high security interface.

netmask The network mask pertains to both low_address and high_address. Use a netmask of 255.255.255.255 when low_address is a host even if subnetting is in place, or specify the correct mask if low_address is a network address

Example static (dmz3,outside) 209.165.201.3 192.168.3.3 netmask 255.255.255.255

Makes up the 209.165.201.3 address on the outside interface that is mapped to the 192.165.201.3 address on the DMZ interface.

∗ Source: http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_sw/v_53/config/

64

access-list∗ Command

The access-list command lets the outside users access the IP address that you provided for mapping to the internal resource.

access-list acl_ID [deny | permit] protocol source_addr source_mask operator port destination_addr destination_mask operator port acl_ID Name of an access list. You can use either a name or number.

deny When used with the access-group command, the deny option does not allow a packet to traverse the PIX Firewall. By default, PIX Firewall denies all inbound or outbound packets unless you specifically permit access.

permit When used with the access-group command, the permit option selects a packet to traverse the PIX Firewall. By default, PIX Firewall denies all inbound or outbound packets unless you specifically permit access.

protocol It can be one of the keywords icmp, ip, tcp, or udp

source_addr A host or network address for on the lower security level interface, such as outside, that need to access the destinations, which is the global IP address provided in the static command. Use any for the source_address to let any host access the destination_address. If you specify a single host, precede the address with host; for example host 192.168.1.2. If you specify a network address, also specify a network mask; for example, 192.168.1.0 255.255.255.0.

source_netmask Netmask of the source address. Use host address as an abbreviation for a mask of 255.255.255.255.

destination_addr A host or network global address that you specified with the static command statement. This is the global IP address on the lower security interface, in the static command that maps to the higher security address. For a host address, precede the address with host; for networks, specify the network address and the appropriate network mask. destination_mask Netmask for the destination address. operator A comparison operand that lets you specify a port or a port range. Use without an operator and port to indicate all ports; for example:

access-list acl_out permit tcp any host 209.165.201.1

∗ Source: http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_sw/v_53/config/

65

port Services you permit or deny access to. Specify services by the port that handles it, such as smtp for port 25, www for port 80, and so on. You can specify ports by either a literal name or a number in the range of 0 to 65535.

After defining an Access list, you need to bind that list to an interface. The access-group command allows you to do that.

access-group∗ Command

The access-group command binds an access list to an interface. The access list is applied to traffic inbound on an interface. If you enter the permit option in an access-list command statement, the PIX Firewall continues to process the packet. If you enter the deny option in an access-list command statement, PIX Firewall discards the packet.

access-group acl_ID in interface interface_name acl_ID The name associated with a given access list. in interface Filter on inbound packets at the given interface.

interface_name The name of the network interface from which the packets are to be permitted or denied.

Example:

static (inside,management) 10.1.1.15 10.1.1.15 netmask 255.255.255.255 access-list from-management-coming-in permit tcp host 10.2.2.2 host 10.1.1.15 eq 8888 access-group from-management-coming-in in interface management

∗ Source: http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_sw/v_53/config/

66

Appendix F

Guarddog is a powerful GUI environment based on iptables which greatly simplifies the use and functionalities of iptables. Installation of the program: 1. Go to this site: http://www.simonzone.com/software/guarddog/ 2. Click on the Download tab 3. Download the RPM file under RedHat 9: 2.2.0 RPM: guarddog-2.2.0-1rh9.i386.rpm 4. To install the program, type: “rpm –Uvh guarddog-2.2.0-1rh9.i386.rpm” 5. Reboot to start the script. To start Guarddog after reboot, type guarddog and a GUI interface will appear. Section 1: Protocols To specify a protocol, click on the protocol tab in the Guarddog GUI and expand Network. Click on the check box beside the desired protocol once to permit the protocol and click again to reject the selected protocol. For example: clicking the check box beside the ‘Ping’ twice rejects all pings.

Figure 1. Ping box checked twice

67

Figure 2. Linux 7.2 tried to ping to workstation and failed. All protocols are listed on the protocols tabs and can be blocked or permitted as desired. Once pings are set to “reject,” a ping attempt from the 7.2 machine is unsuccessful, as shown in Figure 2. Section 2: Port Blocking To block specific ports using guarddog, click on the Advanced tab, and then select New Protocol. Enter a name for the new protocol (eg. “PortBlock”), and enter the port on which it will be active (eg. “1000”). Now go back to the “Protocol” tab and expand the User Defined group. The new protocol that you just created should be visible here, and you will have the freedom to block / permit any activity on that port. Section 3: Creating Zones At one point the lab required the creation of a “De-Militarized Zone”. This can be accomplished using Guarddog by clicking “Zones” and clicking “New Zone”. Name the zone “DMZ” and assign the address range and security protocols as necessary for this zone. This GUI environment greatly simplifies and would hasten progress in many sections of the lab. Therefore, it would be useful to replace all sections of the lab that use iptables, with fresh instructions on the use of Guarddog.

68

Appendix G

1. Linux Firewall exploit Most firewalls do not usually allow any connections except FTP control connections to an FTP server port (TCP port 21 by default) for network security. However, as long as a file is transferred, they accept the data connection temporarily. To do this, a firewall tracks the control connection state and detects the command related to file transfer. This is called stateful inspection. The attack described here will make a firewall allow an illegal connection by deceiving its connection tracking using a forged FTP command. This attack is described in detail in the Phrack article http://www.phrack.org/phrack/63/p63-0x13_Breaking_Through_a_Firewall.txt

An attacker can transmit a PORT command without the character <CR> in the end of the line. The command line has only <LF> in the end. An example is "PORT 192,168,100,100,26,11\n". On the contrary, a standard FTP command has <CRLF> sequence to denote the end of a line. If the module ip_conntrack_ftp receives a nonstandard PORT command of this type, it first detects a command and finds the character <CR> for the parsing. Because it cannot be found, ip_conntrack_ftp regards this as a "partial" command and drops the packet. Just before this action, ip_conntrack_ftp anticipated the sequence number of a packet that contains the next FTP command line and updated the associated information. This number is calculated based on the TCP sequence number and the data length of the "partial" PORT command packet. However, a TCP client, afterwards, usually retransmits the identical PORT command packet since the corresponding reply is not arrived at the client. In this case, ip_conntrack_ftp does NOT consider this retransmitted packet as an FTP command because its sequence number is different from that of the next FTP command anticipated. From the point of view of ip_conntrack_ftp, the packet has a "wrong" sequence number position. The module ip_conntrack_ftp just accepts the packet without analyzing this command. The FTP server can eventually receive the retransmitted packet from the attacker. Although ip_conntrack_ftp regards this "partial" command as INVALID, some FTP servers such as wu-FTP and IIS FTP conversely consider this PORT command without <CR> as VALID. In conclusion, the firewall, in this case, fails to "expect" the FTP data connection. And when the attacker sends a RETR command to download a file from the server, the server initiates to connect to the TCP port number, specified in the partial PORT command, on the attacker's host. Suppose that the TCP port number is 6667(IRC server port), the firewall accepts this connection under the stateless packet filtering rule that allows IRC connections instead of the stateful filtering rule. So the IP connection-tracking module mistakes the connection for IRC.

In conclusion, the attacker is able to illegally connect to any TCP port on the FTP server that the Netfilter firewall box protects. We had to take the following additional steps to make the exploit work on the Redhat 7.2 machine

• Start/Flush iptables /etc/init.d/iptables restart • Setup connection tracking modprobe ip_conntrack_ftp

69

modprobe ip_conntrack_irc • Setup state full filtering

iptables -A FORWARD -m state – state ESTABLISHED, RELATED -j ACCEPT • Create the irc command file irc.txt which contains the DCC command

\1DCC CHAT t 3232236548 6667\1\n • Compile fake_irc.c and run it using the following command

./fake_irc 57.35.6.142 6667 ece4112 password /home/ece4112/irc.txt We have attached the output from the execution of the program. The Phrack article talks about two other exploits that work on the linux 2.4 kernel netfilter module. 2. Firewall spotting

Here is an interesting article that we came across. http://www.phrack.org/phrack/60/p60-0x0c.txt

It describes how to spot a packet filtering firewall is in place. It works on the principle that almost every available firewall does not check for a valid CRC before checking the destination port/address. A complete network stack will drop invalid packets without response. No matter if that port is closed, open or whatever... But Packet Filters aren't so smart and they will reply.If we want to determine if there is a packet filter between us and a target host we must first check if the packet filter is configured to drop the packets or to send back an error. For this we send a valid tcp packet to any port that is supposed to be filtered: # telnet www.oracle.com 31337 Trying 148.87.9.44... telnet: Unable to connect to remote host: Connection refused Good. Either the target host itself or a packet filter sends back a RST. Next step is to check if the RST comes from the target host or from a packet filter: # hping -S -c 1 -p 31337 -b www.oracle.com HPING www.oracle.com (rl0 148.87.9.44): S set, 40 headers + 0 data bytes len=46 ip=148.87.9.44 flags=RA seq=0 ttl=23 id=52897 win=512 rtt=459.8 ms If we get a reply we know that a packet filter is in place. If we dont get a reply we suspect that the packet arrives unfiltered at the destination host and is dropped by the TCP stack (e.g. no packet filter is in place). Another technique to detect the existence of a packet filter is to compare the TTL of a RST and a SYN (which comes directly from the target host). The TTL-technique fails for all packet filters in bridging mode or filters that do not decrease the TTL and are placed directly in front of the target host (normal DMZ setup). The CRC-technique as described above on the other hand detects a packet filtering device in both cases.

3. Windows firewall’s exploits

70

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:

71

Advanced Port Scan:

Exploits Test:

Source: http://www.flexbeta.net/main/printarticle.php?id=76

72

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.

73

Appendix H ZoneAlarm ZoneAlarm is a software firewall for Windows 98SE, ME, 2000, and XP. It is available at http://www.zonelabs.com. You will become familiar with its setup and features. Download zlsSetup.exe to your desktop and double click on the icon. We will use the default directory so click on Next. Uncheck the two boxes about registering and being informed about product news since we have no connect to the internet. Click Next. Accept the License Agreement and click Install. In the user survey just click Finish, and click Yes to start ZoneAlarm. Click on Select ZoneAlarm and then click Next. Click Finish. Click Next at the welcome screen. Choose yes as shown in Figure 1 and click on next.

Figure 1. Internet access configuration.

Click Done to exit the Wizard. Click Ok to restart your virtual machine and complete installation. You will now see ZoneAlarm open to its Overview page. On the left you can see where you can control options for the firewall, the program control, email, and alerts and logs. Minimize ZoneAlarm for now and start the VNC viewer. Enter the IP address of any of your virtual machines and click ok. You should see a screen similar to that of Figure 2.

74

Figure 2. ZoneAlarm Security Alert.

Look at the Security Alert. ZoneAlarm gives the application name, the IP of the machine that the application is trying to access as well as the port of the machine. This is useful if you have a program that you are not familiar with because you can deny access and then research the program to find out whether or not you should be worried. If it is some type of Trojan you have the IP address that it is trying to contact. Go ahead and allow access. You’ll get a message that VNC has failed to connect. Click OK. Now on your Red Hat WS 4.0 machine run the nmap GUI. #nmapfe Enter the address of your XP Pro virtual machine and click scan with the default settings. You should see a screen similar to Figure 3.

Figure 3. Nmap result of XP machine running ZoneAlarm.

75

It looks like we are not there, or we are blocking our ports. On the Red Hat machine ping the XP Pro machine. #ping <XP Pro IP> After a few seconds press Ctrl C. You should see results like that of Figure 4.

Figure 4. Pinging result of XP machine running ZoneAlarm.

Now look at your XP machine’s screen. ZoneAlarm has alerted you of the ping, and it shows the IP of the offending machine as shown in Figure 5. In the real world we could do a WHOIS look up and contact the ISP of this person if this were more than just a ping to our machine.

Figure 5. Security Alert from ZoneAlarm with attacker’s IP and type of attack.

Q. How could an attacker hide the IP of the machine from which he/she is attacking?

76

Ans. If and attacker ssh to an machine and send his packets through that machine there is actually no way that a victim can find out which machine is the packets are being sent from. For this reason every machine should have there own firewall on, even though there is a firewall setup for each network.

77

Appendix I ProcessGuard Since there are some ways to get around the firewalls and attack a machine in the stealth mode, users are recommended to use some kind of task manager kind of application to check and control various other application that might make the machine vulnerable to the outside network. One of the software that can be used is ProcessGuard. It runs under all new windows versions. A free trail version of this software can be found in this following website,

http://www.diamondcs.com.au/?hop=gkweb This software comes with some special features along with the classical task manager application, such as –

• ProcessGuard gives you full control over which programs are allowed to run. • It prevents even the stealthiest rootkit Trojan horses from being able to install malicious

drivers. • Virtually all known code/process-related attacks can be prevented, including keyloggers,

firewall leak tests, process termination, code and DLL injection, thread hijacking, and Windows File Protection attacks. Installation process: 1. Once you download the setup file from the web address give above,

you should execute the file. 2. This would start installation process. 3. Press next for several times in the next few windows. Once you are

done installing you’ll see the icon of the software in your system tray. 4. It is recommended that you reboot your system after installation. 5. After rebooting, double click on the program icon in the system tray. A

window will pop up.

78

Figure 9: Initial view of ProcessGuard 6. As this is trail version, you will won’t have the privilege to manipulate

the machines task in the memory level or globally. 7. Once you go in to the ‘Alert’ option, you’ll see a list of applications

running. Select a application and see the comments shown below for that application.

Figure 10: Alert option in ProcessGuard

8. When you go to the ‘Protection’ option, you’ll again see a list of

programs and there attributes. Here by selecting a program and right clicking on it, you can obtain the options to manipulate various attributes. You can do the same thing by selecting the application and

79

setting the attribute shown below. You can also add new program that is needed to be protected or set preferences.

Figure 11: Protection option in ProcessGuard 1. If you click on the ‘Security’ option you’ll see a list of programs. You can

select each program and right click on it. Then you can set the permission level for each programs as desired.

80

Figure 12: Security option in ProcessGuard Advantages:

The advantages with these software is that they are compatible to each other and they don’t interfere in others tasks. Also these software are user friendly and easy to work with. The best part is that it gives you the freedom to set different priorities to different applications. As these software shows everything in GUIs, users can manipulate everything visually. Conclusion: These software are reliable for the time being. But everyday there are countless bugs and vulnerabilities are found. To protect you machine, it is recommended to use the software that you absolutely need to do a specific task. Unnecessary applications open extra ports that can attract the hacker to get in. So, using these software you should set the permit level for your machine to protect it.

81

Appendix J Firewall Builder This lab explained how to set firewall rules to help secure a network using a few different types of firewalls, including iptables in Linux. Although iptables is a very robust firewall, it can be difficult to configure for someone just learning how it works. We found a program with a GUI that allows a user to create rules for various types of firewalls, including iptables, in an easy to use interface. The program is called Firewall Builder, and it can be found at http://www.fwbuilder.org/. It runs on most operating systems, including Windows, Linux, and Mac OS. The program allows you to build the firewall rules and create a script, then transfer the file to the host running the firewall where it can be run to setup the firewall rules specified in Firewall Builder. It also comes with preconfigured templates to help you get started. To create the firewall rules for iptables we used the Windows version of Firewall Builder on our Windows XP virtual machine. The rules that will be created allow the firewall to respond to pings and to forward SSH traffic to a server on the local side. The script created was then transferred over to our RedHat WS 4.0. The BlackHat and Protected virtual machines set up for the first section of Lab 4 are used so this addition should be place somewhere after those have been set up. The following steps were used to accomplish this:

• Copy the fwbuilder-2010-1.exe file to your Windows XP virtual machine and run the file to install it. Use all the default settings for installation.

• Start the program from the Program Files list in the start menu. • When the “Welcome to Firewall Builder” window comes up click on “Create new project

file”. Select a place to save the file. It is a good idea to create a new folder on the desktop and save it in there. Click Next. Click Finish on the next window that comes up.

• On the left side, right click “Firewalls” and select “New Firewall”.

82

• Enter a name for the firewall, like “iptables_firewall”, select iptables for the software

running, and select Linux 2.4/2.6 for the OS running the firewall. When the window looks like the one below click Next.

• Select “Configure interfaces manually” in the next window and click Next. • In the next window enter the values for Name, Label, Address, and Netmask as shown in

the screenshot below. When you enter the values for one interface click Add, then enter the next set of values and click Add. Finally, click Finish once all the settings are correct.

83

• You should now be back to the main Firewall Builder window. In the right side, find the

Addresses folder, located within the Objects folder. Right click on the Addresses folder and select New Address.

• In the new window that opens, enter “outside_IP” for the Name, and the IP address of the outside interface (131.210.231.1) for the Address. Click Apply Changes then close the address window. You should now see an item for ouside_IP under the Addresses folder.

• Do the same to create a new address for the local server within the firewall. This server will be the Protected virtual machine with an IP address of 192.168.0.10. Give it a name of “local_server”.

• Find the TCP folder under the Services folder on the left side of the main Firewall Builder window. Right click on TCP and select New TCP Service.

• In the TCP window that comes up, type “SSH” for the Name, 0 for Start and End under the Source Port Range, and 22 for the Start and End under the Destination Port Range. Click Apply Changes then close the window.

• Create a new ICMP Service using the default ICMP settings, and name it Ping. • Click on the NAT tab. Right click in the NAT window and select “Insert Rule”. • Find the ouside_IP Address you created in the left side. Left click it and drag it to the

Original Dst section in the NAT rule. Drag the SSH TCP Service you created to the Original Srv section. Drag the local_server Address you created to the Translated Src section. Drag the SSH TCP Service to the Translated Srv section.

• Click on the Policy Tab. Right click in the Policy window and select Insert Rule. • Drag the SSH Service to the Service section. Right click in the Action section and select

Accept. • In the Rules menu at the top select Add Rule Below.

84

• In this new rule, drag the Ping service to the service section and change the action to Accept. The Policy tab should now look similar to the screenshot below.

• Save the settings by clicking the disk icon or selecting File, Save. • To build the iptables file with the settings created select Compile under the Rules menu at

the top, or click the icon for Compile Rules. • Find the newly created file. It will be located in the same place you created the Firewall

Builder project file. It will have the name “iptables_firewall.fw” if you followed the directions given previously. Transfer this file to your RedHat WS 4.0 machine. If you have a shared vmware folder setup already, that is an easy way to copy the file over.

• On the RedHat WS 4.0 machine that is acting as the firewall, run the following command to stop the firewall:

o /etc/rc.d/init.d/iptables stop • Run the following command from the location where the iptables_firewall.fw file is

located to enable the iptables rules created: o ./iptables_firewall.fw

• From the BlackHat virtual machine, try to ping the firewall’s external IP address (131.210.231.55). The firewall should respond to these pings.

• Now try to ssh into the server behind the firewall. Use the following command: o ssh 131.210.231.1

• Log in and try a few commands to see if they work. Type “ifconfig” to see the IP address of the server you are connected to. It should be “192.168.0.10”, the server located inside the firewall.

85

Here are some additional screenshots of Firewall Builder and us demonstrating the rules. The main Firewall Builder window before any firewalls have been created.

The BlackHat machine pinging the firewall after applying the new rules.

86

The BlackHat machine connecting to the server inside the firewall using ssh.

87

Appendix K Firehole This addition is a continuation of the study on the effectiveness of firewalls in their default state. We will launch a very simple program that sends an outbound message and demonstrate that the default settings that are enabled after firewall installation are not strong enough to protect a user from every attack. Then, we will discuss methods of preventing such attacks. [This part would take place before any firewalls are installed.] First, we will prove that the program works. Download the Firehole program from http://keir.net/firehole.html. It is a small executable and requires no installation. Download it to your Windows machine. Ensure that the Windows firewall is off doing the following: Go to Start->My Network Places On the left, click View Network Connections Right click on the Local Area Connection and select Properties Click the Advanced tab Make sure the check box is unchecked. Now, double click on the Firehole.exe program to launch it. It should look like this:

Now, replace the IP with the IP of your Red Hat WS4 machine and leave the port on 80. DO NOT click Start yet. On your Red Hat WS4 machine, start the Apache web server that you installed in one of the previous labs. (This is needed so the program has something to send the message to.) Assuming the path is the same, the command will be:

/home/apache2/bin/apachectl start Now, test that the server is running by trying to connect to it via the web browser on the Windows machine. (Go to http://a.b.c.d/ where a.b.c.d is the IP address of your WS4 machine.) Open Ethereal on the WS4 machine and start capturing packets. Return to the Windows VM and press the Start button in Firehole. It should spawn an IE program and after a few seconds the program should return a success. The author of the program notes that he/she could have easily

88

hidden the IE window, but decided not to just for the proof of concept. It’s worth noting that this kind of program could be wrapped in some other, innocent looking program and launched in the background, as seen in previous labs. Go back to Ethereal, stop capturing packets, and look for the connection between the two machines. If you follow the TCP-stream, you should see something similar to:

Notice the message at the top. We have just sent an outgoing message over a standard port (80). Although in our case, the message contained nothing vital, it could very well have sent logged passwords or files. This is a big problem that can’t simply be fixed by blocking a port, since in this case, the port is 80. (This would block all web browsing from your machine!) [Now continue with the lab until after RealSecure is installed, but not configured.] Now, with the firewall running, attempt to run Firehole again. Question: Where you successful? Why or why not? Yes we were successful because all outbound traffic is allowed as a default for most firewall settings. Now, close Firehole and delete it. It is important that Firehole be removed from your system for this step so that the firewall does not make a rule for it. Within the RealSecure firewall, go to

89

Tools->Edit Settings Application Control Tab Click “Enable Application Protection” The program will now make a baseline for your system. It will take about a minute. Once it is done, select “Ask me what to do” for both options and click Apply and OK. Now, download Firehole again and try to open it. Question: Did anything happen? Yes, RealSecure should have noticed the new program trying to launch and provided options to continue or terminate. Allow it to open (press the Continue button) and attempt to access the Internet. This attempt should be blocked also. Take a screenshot of the Firehole output and submit it.

So what have we done? We have told the firewall to watch for new programs attempting to access the Internet. At this point, the user is aware of all new programs that might try to go online. Ideally, the firewall would be installed right after a fresh OS install, and the baseline could be setup from there. It’s worth noting that if Firehole were already installed before the baseline was run, it wouldn’t be caught because RealSecure just makes a log of all the executables and allows them access to the Internet. Now, every time a new or modified application attempts to run and/or access the Internet, RealSecure will ask the user what to do. This could get very annoying after some time, but that’s the price you pay for security.

90

Appendix L: Deep Packet Inspection Overview “Deep Packet Inspection is a term used to describe the capabilities of a firewall or an Intrusion Detection System (IDS) to look within the application payload of a packet or traffic stream and make decisions on the significance of that data based on the content of that data. The engine that drives deep packet inspection typically includes a combination of signature-matching technology along with heuristic analysis of the data in order to determine the impact of that communication stream. While the concept of deep packet inspection sounds very nice it is not so simple to achieve in practice. The inspection engine must use a combination of signature-based analysis techniques as well as statistical, or anomaly analysis, techniques. Both of these are borrowed directly from intrusion detection technologies.” 1 The Big Picture Deep Packet Inspection is the future in firewall and IDS technologies and is valuable part of the multi-layer security model. As applications and networks become more complicated, the network perimeter must be able to detect potential incoming threats by analyzing more than simply the header of packets. Malicious commands can easily be implanted into normal every day traffic and tunneling non-standard traffic over standard ports is slowly becoming the norm. Packet payload analysis is a crucial element of network perimeter security. The Problem Packet payload analysis is an expensive operation. While packet header sizes are standardized, payload sizes are not which dramatically increases the problems with quickly analyzing them. Many applications today require transfer rates at wire speed and many deep packet inspection techniques simply cannot keep up. Until the wire speed issue is correct, deep packet inspection cannot be fully integrated into network perimeter security solutions. Reality Due to the limitations of deep packet inspection, it is only currently implemented by a few hardware providers for a few protocols (i.e. FTP, SSH, HTTP). Theory “In the early stages of firewalls all traffic had to be explicitly specified whether it was permitted. A good example of a very rudimentary firewall was the original Linux firewall. This firewall (whether manipulated with ipfwadm or ipchains required that all traffic traversing the firewall (regardless of direction) be specified. The firewall did not keep track of the various sessions that may exist at any one time in the firewall. Stateful inspection changed all that. Invented by Check Point Software Technologies in the mid-to-late 1990s stateful inspection quickly became an industry standard. Stateful inspection provides for the analysis of packets at the network layer as well other layers (typically the transport layer in the OSI model but the firewall may look at layers above that as well) in order to assess the overall packet. By combining information from various layers (transport, session, and network) the firewall is better able to understand the protocol it is inspecting. This also

1 http://www.securityfocus.com/infocus/1716

91

provides for the ability to create virtual sessions in order to track connectionless protocols such as UDP-based applications as well as RPC-based applications.”2 Here is how the typical stateful firewall works.

In picture (a), a client and server make a typical 3-way handshake. After the handshake, the firewall stores the connection in its state table and will allow the client to communicate with the server however it wants through that connection. Once the connection is closed, the entry will be removed from the firewall state table.

2 http://www.securityfocus.com/infocus/1716

92

In this deep packet inspection example, in picture (a), the client and server accomplish a three-way handshake much like the last example. After the handshake, the firewall adds an entry in its state table for the connection. Now, however, the firewall will monitor the payloads for all of the traffic between the two machines over the connection and ensure that the packets conform to the given protocol. If for example, a “Address Token Overflow” is sent to the mail serve over the connection, the firewall will know that this is not a standard packet and take appropriate action. Deep Packet Inspection and the Cisco PIX The Cisco PIX used in the lab has some very rudimentary deep packet inspection utilities built in. The fixup command engages the deep packet inspection tools to monitor given protocols for potential attacks. The fixup command is not configurable and has very few runtime optins. > fixup protocol <protocol> References and Images Security Focus: Firewall Evolution

93

http://www.securityfocus.com/infocus/1716 Security Focus: Perils of Deep Packet Inspection http://www.securityfocus.com/infocus/1817 Wikipedia: Deep Packet Inspection http://en.wikipedia.org/wiki/Deep_packet_inspection

94

Appendix M: IPTABLES LOG ANALYSIS Setting up a firewall is only half the battle. As has been shown countless times throughout this course, firewalls are traversable, whether through buffer overflow vulnerabilities in well known applications, or through deceptive tricks like ACK tunneling. Firewalls provide a good method to taper the flow of malicious traffic, but for those who successfully penetrate, methods must be available to identify malicious users, and their method of entry. As everyone is well aware, logs provide such a method of pre and post intrusion analysis. Through the analysis of logs, we can detect scans from a single address and block them. Historical patterns emerge for an attacker systematic enumeration of your perimeter. In the worst case scenario, these logs leave a trail that can be used in the post mortem of a successful hack. In this addition, we provide a brief background into the manual methods of log analysis, followed by a more in-depth look at a GUI based log analysis by an Open Sourced package called IPTables Log Analyzer. From manual grep commands, regular expressions, scripting and onto automated GUI’s. Installing Iptables Log Analyzer

Iptables Log Analyzer is a package that analyzes the log output from your iptables firewall, stores the info in a database and then produces a nice user friendly web interface from where you can monitor your firewall log output at any time. The interface even lets you sort throught the logs and group logs by category. The official site for Iptables Log Analyzer can be found at http://www.gege.org/iptables/.

So let's install it...

The first thing you will need to do is to download the Iptables Log Analyzer package. You can download the latest copy of the package right here: http://www.iptablesrocks.org/downloads/iptables_logger_v0.4.tar.gz

Look here for further instructions for configuring Iptables log analyzer: http://www.iptablesrocks.org/guide/analyze.php

Below is the format used by the netfilter log messages:

The items are explained in sequence: Apr 16 00:30:45 megahard kernel:

syslog prefix. It is not present if you read log messages from the console.

NF: D(I,Priv) Enabled with: --log-prefix 'prefix' An arbitrary, user defined log prefix. Including the spaces. A trailing space is necessary to keep the prefix separate from the next token; this is a bug in netfilter.

IN=eth1 Interface the packet was received from. Empty value for locally generated packets.

95

OUT= Interface the packet was sent to. Empty value for locally received packets. MAC= 00:80:8c:1e:12:60: 00:10:76:00:2f:c2: 08:00

Destination MAC=00:80:8c:1e:12:60, Source MAC=00:10:76:00:2f:c2, Type=08:00 (ethernet frame carried an IPv4 datagram)

SRC=211.251.142.65 Source IP address DST=203.164.4.223 Destination IP address LEN=60 Total length of IP packet in bytes TOS=0x00 Type Of Service, "Type" field.

Increasingly being replaced by DS and ECN. Refer to the IP header info below.

PREC=0x00 Type Of Service, "Precedence" field. Increasingly being replaced by DS and ECN. Refer to the IP header info below.

TTL=44 remaining Time To Live is 44 hops. ID=31526 Unique ID for this IP datagram, shared by all fragments if fragmented. CE Presumably the "ECN CE" flag (Congestion Experienced).

This seems to be wrong because according to RFC2481, the CE bit is located in the TOS field. Refer to the IP header info below.

DF "Don't Fragment" flag. MF "More Fragments following" flag. FRAG=179 Fragment offset in units of "8-bytes". In this case the byte offset for data in

this packet is 179*8=1432 bytes. OPT (0727..A200) Enabled with: --log-ip-options

IP options. This variable length field is rarely used. Certain IP options, f.e. source routing, are often disallowed by netadmins. Even harmless options like "Record Route" may only be allowed if the transport protocol is ICMP, or not at all.

PROTO=TCP Protocol name or number. Netfilter uses names for TCP, UDP, ICMP, AH and ESP. Other protocols are identified by number. A list is in your /etc/protocols. A complete list is in the file protocol-numbers

SPT=4515 Source port (TCP and UDP). A list of port numbers is in your /etc/services. A complete list is in the file port-numbers

DPT=111 Destination port (TCP and UDP). See SPT above. SEQ=1168094040 Enabled with: --log-tcp-sequence

Receive Sequence number. By cleverly chosing this number, a cryptographic "cookie" can be implemented while still satisfying TCP protocol requirements. These "SYN-cookies" defeat some types of SYN-flooding DoS attacks and should be enabled on all systems running public TCP servers. echo 1 > /proc/sys/net/ipv4/tcp_syncookies

96

ACK=0 Same as the Receive Sequence number, but for the other end of the TCP connection.

WINDOW=32120 The TCP Receive Window size. This may be scaled by bit-shifting left by a number of bits specified in the "Window Scale" TCP option. If the host supports ECN, then the TCP Receive Window size will also be controlled by that.

RES=0x03 Reserved bits. The ECN flags "CWR" and "ECNE" will show up in the two least significant bits of this field.

URG Urgent flag. See URGP below. ACK Acknowledgement flag. PSH Push flag. RST RST (Reset) flag. SYN SYN flag, only exchanged at TCP connection establishment. FIN FIN flag, only exchanged at TCP disconnection. URGP=0 The Urgent Pointer allows for urgent, "out of band" data transfer.

Unfortunately not all protocol implementations agree, so this facility is hardly ever used.

OPT (020405...300) Enabled with: --log-tcp-options TCP options. This variable length field gets a lot of use. Important options include: Window Scaling, Selective Acknowledgement and Explicit Congestion Notification.

Unfortunately the rule number in the chain which matched the packet is for architectural reasons not available in netfilter logs. You will have to "cook your own" by using the user-prefix feature.

Below is a snapshot of iptables log analyzer GUI. It has the ability to parse logs by date, IP, interface, host, protocol, etc.

It provides utilization statistics which can identify unusual behavior

1. Number of packets 2. Top Host Statistics 3. Top Port Statistics

97

References:

• IPtables Log Analyzer: http://www.gege.org/iptables/ • Netfilter Format: http://logi.cc/linux/netfilter-log-format.php3

98

Appendix N WIPFW (Win IPTables) WIPFW is a windows-based port of IPFW from the OS FreeBSD. It is a good tool for extra computer security. It is also a free, open-source tool. Some of its functionality is similar Linux’s “iptables”. WIPFW download and information can be found at the website http://wipfw.sourceforge.net/. After downloading and unzipping the folder you should see the following files:

Double-clicking install should take care of everything. As a side note, you can edit the “wipfw.conf” file and then double click “config” to update these settings. The default config file can be seen below:

Comments can be added after a “#” symbol. The commands that can be added are listed within the “README” provided by the author. Commands can also be added simply by using windows command prompt. After opening command prompt type in the command “ipfw”. You will see some of the commands and the base welcome screen. To start fresh with your own commands type in “ipfw –f flush”. This

99

clears all current settings and essentially looks like this program does not exist in regards to network traffic. This can be seen by typing in “ipfw –a show”. If you have done everything right you your screen should look like the following:

A sample command can be added to test the functionality. Type in “ipfw add deny tcp from any to any”. You can then verify that this has been added. Your screen should look like the following:

As of this point you should have completely blocked all tcp traffic. This can be verified simply by trying to access the web. After this you can flush again to clear all added commands. Adding these commands via command prompt is very good for individual testing, but for long term use the config file is the most useful way to add commands. With enough commands WIPFW could do everything that a normal firewall could do and more. Using a user-friendly firewall for basic

100

firewalling is still the most useful. WIPFW can then be used for rules where there are holes in your firewall. The following protocols can have rules done to them:

IP, ICMP, TCP, UDP, EGP, PUP, GGP, HMP, XNS-IDP, RDP, RVD

WIPFW can then be used to do things such as deny, allow, IP forward, etc. It can even detect fragmented packets and reject them, which is a popular way for hackers to enter malicious items through a firewall undetected. A screenshot below from the GUI lets you see many of the possibilities of this software (The GUI is buggy and is shown as an FYI only.

We discovered a pre-made config file that has enough commands to basically completely remove the need to another firewall, plus many other rules (The author or this config file is unknown). We will not advocate only using WIPFW because alerts and easy-to-navigate GUIs help with most of the needs people have with networking. WIPFW will greatly enhance security in the background, and since it is free and open-source there is no fee even for commercial use. The following is the config file we found (“ipfw –a show” can be used to verify that the rules have been added):

101

# First flush the firewall rules -f flush ### allow local traffic, Localhost rules ### add allow all from any to any via lo* ## standard http rules ## add allow tcp from any to any 80 out via eth1 setup keep-state add allow tcp from any to any 80 in via eth1 setup keep-state ## secure https ## add allow tcp from any to any 443 out via eth1 setup keep-state add allow tcp from any to any 443 in via eth1 setup keep-state ## Prevent any traffic to 127.0.0.1, common in localhost spoofing ## add deny log all from any to 127.0.0.0/8 in add deny log all from 127.0.0.0/8 to any in # deny RFC 1918 addresses on the outside , common in localhost spoofing #add deny ip from any to any not verrevpath in add deny ip from 10.0.0.0/8 to any in via eth1 add deny ip from 172.16.0.0/12 to any in via eth1 add deny all from 0.0.0.0/8 to any in via eth1 #loopback add deny all from 169.254.0.0/16 to any in via eth1 #DHCP auto-config add deny all from 192.0.2.0/24 to any in via eth1 #reserved for docs add deny all from 204.152.64.0/23 to any in via eth1 #Sun cluster interconnect ## Deny all fragmented ## add deny all from any to any frag in via eth1 ## ftp with passive ports ## add allow tcp from me to any 21 out via eth1 setup keep-state add allow tcp from me to any 49152-65535 out via eth1 setup keep-state add allow tcp from any to me 21 in via eth1 setup keep-state add allow tcp from any to me 49152-65535 in via eth1 setup keep-state ## pop & smtp ## add allow tcp from any to any 25 out via eth1 setup keep-state add allow tcp from any to any 110 out via eth1 setup keep-state ## ntp ## add allow tcp from any to any 123 out via eth1 setup keep-state add allow udp from any to any 123 out via eth1 keep-state ## imap ## add 00635 allow tcp from any to me 143 in via eth1 setup keep-state #ICMP ###### ICMP ###### ## Allow out & in console traceroot command ## add allow udp from me to any 33435-33500 out via eth1 keep-state add allow log icmp from any to me icmptype 3,11 in via eth1 limit src-addr 2 ## ping out ## add allow icmp from any to any out via eth1 keep-state ## ping in ## add allow log icmp from any to me icmptype 0,8 in via eth1 ## This sends a RESET to all ident packets ## add reset log tcp from any to me 113 in via eth1 limit src-addr 4 ## Stop & log external redirect requests ## add deny log icmp from any to any icmptype 5 in via eth1 ## Stop & log spoofing Attack attempts ## add deny log ip from me to me in via eth1 ## Stop & log ping echo attacks ##

102

add deny log icmp from any to me icmptype 0,8 in via eth1 ## snmp ## add allow udp from any to me 161 in via eth1 keep-state #Multicast add deny ip from 224.0.0.0/3 to any in add deny tcp from any to 224.0.0.0/3 in # DisAllow idents add reset log tcp from any to any 113 in recv eth1 ## deny incoming ssh & Telnet ## add deny tcp from any to me 22,23 # Allow DNS queries and responses (It replaces the above four lines in two lines. Cheers!) ## dns ## add allow tcp from any to any 53 out via eth1 setup keep-state add allow udp from any to any 53 out via eth1 keep-state add allow udp from any to me 53 in via eth1 keep-state add allow tcp from any to me dst-port 53 in via eth1 setup keep-state

103

Appendix O Firewall Tests

1. Leak Testing in Windows

Leak tests are small, non-destructive, programs designed by security experts that deliberately attempt to bypass a firewall's outgoing security measures. The rationale behind them is painfully simple: "If this test can get past your computer's security defenses, then so can a hacker." Explicitly designed to help identify a firewall's security flaws, leak tests provide the invaluable function of informing the user whether or not their firewall is providing adequate protection. The tests pose no real threat to the security of a computer as they are harmless simulations of the attack techniques typically used by spyware and Trojan horse programs. There are many leak-testing programs available - each one designed to exploit a particular flaw and each using a particular attack technique to break a firewall's standard protection mechanisms. We will be testing two firewalls through three leak tests: Black Ice and Comodo. Black Ice was installed in a previous lab.

1. First, we will change one option for Black Ice. Goto Black Ice settings and click the Tools menu. Click “Advanced application protection settings” and enable application protection.

2. Next it’s time to install Comodo. You can find Comodo at http://www.personalfirewall.comodo.com/. It is also located in nas4112/Lab4 as CFP_Setup_English.exe.

3. Load up your Windows machine and install Comodo with the default options. After the install, you will be prompted to restart. Click OK and allow the restart (make sure you saved anything on the Windows machine you want saved first though).

4. After your computer boots up, you’ll notice Comoodo is now in your system tray (bottom right near the clock). Now, you will be running each of these tests with both Black Ice and Comodo and filling in the results in the table below. Only run one firewall at a time.

5. Rather than exiting the programs, I would suggest that you right click on the firewall’s system tray icon you want to disable and then goto the following option:

a. For Comodo, goto Security Level. Click Allow All to disable the firewall, or click Custom when you are testing Comodo.

b. For Black Ice, you have to click two options to stop the firewall and the application protection.

Substitution

This technique tries to present itself as a trusted application. There are a few different possibilities how to achieve this. For example the application can try to rename itself to a commonly known, safe application name such as iexplore.exe. As a result, firewalls that do not verify application signatures or verify too late fail to detect such attempts.

Coat is one method to test substitution. The Coat leak-test rewrites its own memory and tries to establish an Internet connection. It rewrites its image base, image name, command line, Windows title etc. and it also changes the information of the main module in the module list. All

104

these data reside in the address space of its process. All the data are changed to match the image of the default browser. Then, it tries to establish the Internet connection.

Firewalls that are not able to handle this trick could mean that they do not have an internal list of running programs and are unable to obtain this information when it is needed. This gives malicious processes enough time to modify these data before they execute privileged actions. Such firewalls (as well as many other programs - e.g. Process Explorer from Sysinternals) then see the malicious process as something else - e.g. the default browser - and allow the execution of privileged actions without any questions.

1. Grab coat from nas4112/Lab5/coat.zip or at http://www.matousec.com/. 2. Next, unzip the file and put it somewhere you can remember on your Windows machine. 3. Load up the command prompt and goto the coat directory and run lt-coat.exe with each

firewall. If the firewall displays a prompt that wants to block the application, then the test succeeded. An example of a success is seen below running Coat:

. Record your results in the table.

DLL Injection

Being one of the most commonly used techniques by Trojans, this method tries to load a DLL file into the process space of a trusted application. When a DLL is loaded into a trusted process, it acts as the part of that process and consequently gains the same access rights from the firewall as the trusted process itself. Firewalls that do not have an application component monitoring feature fail to detect such attacks.

105

To test DLL injection, Jumper will be used. Jumper attemps to infect Windows Explorer with its own DLL. At first, it tries to modify the registry value AppInit_DLLs and then it terminates Windows Explorer. When the Windows Explorer is run again it loads DLLs specified in AppInit_DLLs to its process. Jumper's DLL running from the Windows Explorer process launches Internet Explorer and controls its behaviour to connect to the Internet server.

1. First, put Jumper on the Windows machine. You can find it in nas4112/Lab4 or you can get it at http://www.firewallleaktester.com/.

2. Next, run the executable after you unzip it. Next click Send. Note that this application can sometimes crash explorer.exe. To load it back up, press ALT+CTRL+DEL and goto File/New Task(run). Now type in explorer.exe and it will reload explorer.

3. Record your results

Process Injection

This technique is the most advanced and difficult to detect penetration case that many personal firewalls still fail to detect although it is used by Trojans in the wild. The attacker program injects its code into process space of a trusted application and becomes a part of it. No DLL or similar component is loaded.

To test process injection, AWFT will be used. AWFT is a set of six tests. However, two of the tests do not work since we do not have an internet connection, so we will only work with tests 1-4.

• Test 1: Attempts to load a copy of the default browser and patch it in memory before it executes. • Test 2: Attempts to create a thread in a loaded copy of the default browser. • Test 3: Attempts to create a thread in Windows Explorer.

• Test 4: Attempts to load a copy of the default browser from within a thread in Windows Explorer and patch it in memory before execution. This attack regularly beats most personal firewalls which require authorization for an application to load another application.

1. First, install the program from the nas4112/Lab4 folder called awft.exe or goto http://www.atelierweb.com/awft/.

2. Next, ensure that your Apache server is still setup. If not, follow instructions from a previous lab to install Apache.

3. After the install, goto Start/Programs/Atelier and load up AWFT. 4. In the URL textbox near the bottom, type in your host computer’s IP address with

Apache set up. 5. To choose a test, you click the appropriate number at the top, in blue letters. Then either

AWFT or the firewall will be given points depending on whether the firewall passes or fails. An AWFT point means that the firewall failed that particular test.

Test name Comodo (Pass/Fail) Black Ice (Pass/Fail) Coat

106

Jumper AWFT 1 AWFT 2 AWFT 3 AWFT 4 As you can see from the results, not all firewalls are the same. Matousec did a rating of the firewalls and found Comodo to be the best firewall in terms of leak test pass rate, while the Windows firewall was the worst, with its lack of leak test protection.

107

Appendix P Getting Around IP tables

This extension demonstrates the capabilities of raw sockets and their ability to circumvent firewalls. While firewalls prevent packets from entering the kernel and stack, raw sockets connect directly to the interface and sniff raw packets. By adding some basic coding and processing, better backdoors can be constructed. This extension uses Libpcap, a platform-independent library that utilizes raw sockets to capture packets before they are “dropped” by the firewall. Code is derived from sniffex.c, obtained from http://www.tcpdump.org/pcap.htm Raw sockets circumvent software firewalls. Countermeasures: Move firewall off the machine to a gateway. Limit root access. Monitor processes vigilantly.

Background For most backdoors, an effective Firewall will minimize the damage they cause. If you can’t access the backdoor from outside the computer, then it’s useless. IPtables is an effective Linux firewall and is heavily relied upon for security. However, one must understand how it really functions. When we talk about “dropping packets,” what do we mean? They don’t simply disappear. They still exist and are “in” your machine. Firewalls simply keep the packet from getting to the TCP/IP stack in the kernel. While this prevents most damage, it is not foolproof. If one can “grab” the packet directly from the interface and process it in user space, iptables would be completely unable to stop it. Libpcap is an open source library that provides just such functionality. Designed to be a platform-independent library for implementing packet sniffing and network monitoring, pcap will create a raw socket that completely bypasses iptables and the kernel stack. Obviously, performance is greatly reduced… but access can be unfettered!

The example The basic code was obtained from http://www.tcpdump.org/pcap.htm . It is included as an example to demonstrate the functionality of Libpcap. It is originally called sniffex.c and our improved version is called bettersniffex.c. Simply, we rearranged code and created functionality for another command line argument and udp packet processing. We also eliminated all output except for packet payload. It now looks much like a udp session of netcat.

108

Because we are handling these packets outside of the kernel, there is NO TCP/IP processing. This program is a receive only implementation. It doesn’t send ACKs, SYN-ACK’s, etc. As a result, it will only work with UDP. Obviously, with more code, it could do more. But, do you really want to re-code the entire TCP/IP stack in user space?

Exercise 1. Download the code and makefile to the /root/tools directory of your host machine. 2. Type ‘make’ at the command prompt to compile the code. 3. Start a netcat listener on the host machine. Make sure it is in UDP mode:

nc -l -u -p 1234 3. Run the code as follows in another terminal: ./bettersniffex eth0 “port 1234” 10. From a virtual machine, run netcat in udp mode and connect to the host machine.

nc -u <a.b.c.d> 1234 a.b.c.d = your IP address. Question 1: Can you see output on the host machine in netcat? Can you see it in the sniffer? Q1: yes End the sniffer with CTRL-C and add a rule to IPTABLES to block udp: iptables -A INPUT -j DROP -p udp 6. Restart the bettersniffex program and netcat on the host machine. 7. Restart netcat on the virtual machine. Reattempt to connect. Question 2: Can you see output on the host machine in netcat? Can you see it in the sniffer? Q2: yes Question 3: If you were to take this output and send it to another netcat session or write additional code for a raw output socket, what kinds of things can you do (give one example)? Q3: create backdoor with netcat, implement “port knocking,” forward packets to other machines, loopback to localhost, etc. Question 4: How can you defend against this vulnerability? Q4: move the firewall to separate machine, limit root processes, closely monitor running processes, remove pcap. Question 5: Why won’t this code work if you attempt to connect to the bettersniffex program with Netcat in TCP mode? Q5: Because bettersniffex.c only monitors for packets and contains no TCP processing, no syn-ack packet will be sent to the remote machine. When it doesn’t receive this packet, the remote connection will time out.

109

/* * * Modified by Stephen Thompson & Scott Durr for ECE 4112, Fall 2007 * All modifications marked, original code commented. * * * sniffex.c * * Sniffer example of TCP/IP packet capture using libpcap. * * Version 0.1.1 (2005-07-05) * Copyright (c) 2005 The Tcpdump Group * * This software is intended to be used as a practical example and * demonstration of the libpcap library; available at: * http://www.tcpdump.org/ * **************************************************************************** * * This software is a modification of Tim Carstens' "sniffer.c" * demonstration source code, released as follows: * * sniffer.c * Copyright (c) 2002 Tim Carstens * 2002-01-07 * Demonstration of using libpcap * timcarst -at- yahoo -dot- com * * "sniffer.c" is distributed under these terms: * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Redistributions of source code must retain the above copyright * notice, this list of conditions and the following disclaimer. * 2. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * 4. The name "Tim Carstens" may not be used to endorse or promote * products derived from this software without prior written permission * * THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE * ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF * SUCH DAMAGE. * <end of "sniffer.c" terms> * * This software, "sniffex.c", is a derivative work of "sniffer.c" and is * covered by the following terms: *

110

* Redistribution and use in source and binary forms, with or without * modification, are permitted provided that the following conditions * are met: * 1. Because this is a derivative work, you must comply with the "sniffer.c" * terms reproduced above. * 2. Redistributions of source code must retain the Tcpdump Group copyright * notice at the top of this source file, this list of conditions and the * following disclaimer. * 3. Redistributions in binary form must reproduce the above copyright * notice, this list of conditions and the following disclaimer in the * documentation and/or other materials provided with the distribution. * 4. The names "tcpdump" or "libpcap" may not be used to endorse or promote * products derived from this software without prior written permission. * * THERE IS ABSOLUTELY NO WARRANTY FOR THIS PROGRAM. * BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY * FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN * OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES * PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED * OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS * TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE * PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, * REPAIR OR CORRECTION. * * IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING * WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR * REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, * INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING * OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED * TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY * YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER * PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE * POSSIBILITY OF SUCH DAMAGES. * <end of "sniffex.c" terms> * **************************************************************************** * * Below is an excerpt from an email from Guy Harris on the tcpdump-workers * mail list when someone asked, "How do I get the length of the TCP * payload?" Guy Harris' slightly snipped response (edited by him to * speak of the IPv4 header length and TCP data offset without referring * to bitfield structure members) is reproduced below: * * The Ethernet size is always 14 bytes. * * <snip>...</snip> * * In fact, you *MUST* assume the Ethernet header is 14 bytes, *and*, if * you're using structures, you must use structures where the members * always have the same size on all platforms, because the sizes of the * fields in Ethernet - and IP, and TCP, and... - headers are defined by * the protocol specification, not by the way a particular platform's C * compiler works.) * * The IP header size, in bytes, is the value of the IP header length,

111

* as extracted from the "ip_vhl" field of "struct sniff_ip" with * the "IP_HL()" macro, times 4 ("times 4" because it's in units of * 4-byte words). If that value is less than 20 - i.e., if the value * extracted with "IP_HL()" is less than 5 - you have a malformed * IP datagram. * * The TCP header size, in bytes, is the value of the TCP data offset, * as extracted from the "th_offx2" field of "struct sniff_tcp" with * the "TH_OFF()" macro, times 4 (for the same reason - 4-byte words). * If that value is less than 20 - i.e., if the value extracted with * "TH_OFF()" is less than 5 - you have a malformed TCP segment. * * So, to find the IP header in an Ethernet packet, look 14 bytes after * the beginning of the packet data. To find the TCP header, look * "IP_HL(ip)*4" bytes after the beginning of the IP header. To find the * TCP payload, look "TH_OFF(tcp)*4" bytes after the beginning of the TCP * header. * * To find out how much payload there is: * * Take the IP *total* length field - "ip_len" in "struct sniff_ip" * - and, first, check whether it's less than "IP_HL(ip)*4" (after * you've checked whether "IP_HL(ip)" is >= 5). If it is, you have * a malformed IP datagram. * * Otherwise, subtract "IP_HL(ip)*4" from it; that gives you the length * of the TCP segment, including the TCP header. If that's less than * "TH_OFF(tcp)*4" (after you've checked whether "TH_OFF(tcp)" is >= 5), * you have a malformed TCP segment. * * Otherwise, subtract "TH_OFF(tcp)*4" from it; that gives you the * length of the TCP payload. * * Note that you also need to make sure that you don't go past the end * of the captured data in the packet - you might, for example, have a * 15-byte Ethernet packet that claims to contain an IP datagram, but if * it's 15 bytes, it has only one byte of Ethernet payload, which is too * small for an IP header. The length of the captured data is given in * the "caplen" field in the "struct pcap_pkthdr"; it might be less than * the length of the packet, if you're capturing with a snapshot length * other than a value >= the maximum packet size. * <end of response> * **************************************************************************** * * Example compiler command-line for GCC: * gcc -Wall -o sniffex sniffex.c -lpcap * **************************************************************************** * * Code Comments * * This section contains additional information and explanations regarding * comments in the source code. It serves as documentaion and rationale * for why the code is written as it is without hindering readability, as it * might if it were placed along with the actual code inline. References in * the code appear as footnote notation (e.g. [1]).

112

* * 1. Ethernet headers are always exactly 14 bytes, so we define this * explicitly with "#define". Since some compilers might pad structures to a * multiple of 4 bytes - some versions of GCC for ARM may do this - * "sizeof (struct sniff_ethernet)" isn't used. * * 2. Check the link-layer type of the device that's being opened to make * sure it's Ethernet, since that's all we handle in this example. Other * link-layer types may have different length headers (see [1]). * * 3. This is the filter expression that tells libpcap which packets we're * interested in (i.e. which packets to capture). Since this source example * focuses on IP and TCP, we use the expression "ip", so we know we'll only * encounter IP packets. The capture filter syntax, along with some * examples, is documented in the tcpdump man page under "expression." * Below are a few simple examples: * * Expression Description * ---------- ----------- * ip Capture all IP packets. * tcp Capture only TCP packets. * tcp port 80 Capture only TCP packets with a port equal to 80. * ip host 10.1.2.3 Capture all IP packets to or from host 10.1.2.3. * **************************************************************************** * */ #define APP_NAME "sniffex" #define APP_DESC "Sniffer example using libpcap" #define APP_COPYRIGHT "Copyright (c) 2005 The Tcpdump Group" #define APP_DISCLAIMER "THERE IS ABSOLUTELY NO WARRANTY FOR THIS PROGRAM." #include <pcap.h> #include <stdio.h> #include <string.h> #include <stdlib.h> #include <ctype.h> #include <errno.h> #include <sys/types.h> #include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> /* default snap length (maximum bytes per packet to capture) */ #define SNAP_LEN 1518 /* ethernet headers are always exactly 14 bytes [1] */ #define SIZE_ETHERNET 14 /* Ethernet addresses are 6 bytes */ #define ETHER_ADDR_LEN 6

113

//global variable added to affect output: /* Ethernet header */ struct sniff_ethernet { u_char ether_dhost[ETHER_ADDR_LEN]; /* destination host address */ u_char ether_shost[ETHER_ADDR_LEN]; /* source host address */ u_short ether_type; /* IP? ARP? RARP? etc */ }; /* IP header */ struct sniff_ip { u_char ip_vhl; /* version << 4 | header length >> 2 */ u_char ip_tos; /* type of service */ u_short ip_len; /* total length */ u_short ip_id; /* identification */ u_short ip_off; /* fragment offset field */ #define IP_RF 0x8000 /* reserved fragment flag */ #define IP_DF 0x4000 /* dont fragment flag */ #define IP_MF 0x2000 /* more fragments flag */ #define IP_OFFMASK 0x1fff /* mask for fragmenting bits */ u_char ip_ttl; /* time to live */ u_char ip_p; /* protocol */ u_short ip_sum; /* checksum */ struct in_addr ip_src,ip_dst; /* source and dest address */ }; #define IP_HL(ip) (((ip)->ip_vhl) & 0x0f) #define IP_V(ip) (((ip)->ip_vhl) >> 4) /* TCP header */ typedef u_int tcp_seq; struct sniff_tcp { u_short th_sport; /* source port */ u_short th_dport; /* destination port */ tcp_seq th_seq; /* sequence number */ tcp_seq th_ack; /* acknowledgement number */ u_char th_offx2; /* data offset, rsvd */ #define TH_OFF(th) (((th)->th_offx2 & 0xf0) >> 4) u_char th_flags; #define TH_FIN 0x01 #define TH_SYN 0x02 #define TH_RST 0x04 #define TH_PUSH 0x08 #define TH_ACK 0x10 #define TH_URG 0x20 #define TH_ECE 0x40 #define TH_CWR 0x80 #define TH_FLAGS (TH_FIN|TH_SYN|TH_RST|TH_ACK|TH_URG|TH_ECE|TH_CWR) u_short th_win; /* window */ u_short th_sum; /* checksum */ u_short th_urp; /* urgent pointer */ };

114

//added a new struct to process UDP packets. sweet. struct sniff_udp{ #define UDP_HDR_SIZE 8 u_short udp_sport; u_short udp_dport; u_short udp_length; u_short udp_chksum; }; void got_packet(u_char *args, const struct pcap_pkthdr *header, const u_char *packet); void print_payload(const u_char *payload, int len); void print_hex_ascii_line(const u_char *payload, int len, int offset); void print_app_banner(void); void print_app_usage(void); /* * app name/banner */ void print_app_banner(void) { printf("%s - %s\n", APP_NAME, APP_DESC); printf("%s\n", APP_COPYRIGHT); printf("%s\n", APP_DISCLAIMER); printf("\n"); return; } /* * print help text */ void print_app_usage(void) { printf("Usage: %s [interface] [filter string]\n", APP_NAME); printf("\n"); printf("Options:\n"); printf(" interface Listen on <interface> for packets with <filter string> applied.\n"); printf("\n"); return; }

115

/* * print data in rows of 16 bytes: offset hex ascii * * 00000 47 45 54 20 2f 20 48 54 54 50 2f 31 2e 31 0d 0a GET / HTTP/1.1.. */ void print_hex_ascii_line(const u_char *payload, int len, int offset) { int i; int gap; const u_char *ch; /* offset */ //printf("%05d ", offset); /* hex */ /*ch = payload; for(i = 0; i < len; i++) { printf("%02x ", *ch); ch++; /* print extra space after 8th byte for visual aid */ // if (i == 7) //printf(" "); // } /* print space to handle line less than 8 bytes */ // if (len < 8) // printf(" "); /* fill hex gap with spaces if not full line */ /* if (len < 16) { gap = 16 - len; for (i = 0; i < gap; i++) { printf(" "); } } printf(" "); */ /* ascii (if printable) */ ch = payload; for(i = 0; i < len; i++) { if (isprint(*ch)) printf("%c",*ch); //else //printf("."); ch++; } printf("\n"); fflush(stdout); return; }

116

/* * print packet payload data (avoid printing binary data) */ void print_payload(const u_char *payload, int len) { int len_rem = len; int line_width = 16; /* number of bytes per line */ int line_len; int offset = 0; /* zero-based offset counter */ const u_char *ch = payload; if (len <= 0) return; /* data fits on one line */ //if (len <= line_width) { print_hex_ascii_line(ch, len, offset); //return; //} /* data spans multiple lines */ //for ( ;; ) { /* compute current line length */ //line_len = line_width % len_rem; /* print line */ //print_hex_ascii_line(ch, line_len, offset); /* compute total remaining */ //len_rem = len_rem - line_len; /* shift pointer to remaining bytes to print */ //ch = ch + line_len; /* add offset */ //offset = offset + line_width; /* check if we have line width chars or less */ //if (len_rem <= line_width) { /* print last line and get out */ //print_hex_ascii_line(ch, len_rem, offset); //break; //} //} return; } /* * dissect/print packet */ void got_packet(u_char *args, const struct pcap_pkthdr *header, const u_char *packet) { static int count = 1; /* packet counter */ /* declare pointers to packet headers */

117

const struct sniff_ethernet *ethernet; /* The ethernet header [1] */ const struct sniff_ip *ip; /* The IP header */ const struct sniff_tcp *tcp; /* The TCP header */ const struct sniff_udp *udp; const char *payload; /* Packet payload */ int size_ip; int size_tcp; int size_udp; int size_payload; //printf("\nPacket number %d:\n", count); count++; /* define ethernet header */ ethernet = (struct sniff_ethernet*)(packet); /* define/compute ip header offset */ ip = (struct sniff_ip*)(packet + SIZE_ETHERNET); size_ip = IP_HL(ip)*4; if (size_ip < 20) { printf(" * Invalid IP header length: %u bytes\n", size_ip); return; } /* print source and destination IP addresses */ //printf(" From: %s\n", inet_ntoa(ip->ip_src)); //printf(" To: %s\n", inet_ntoa(ip->ip_dst)); /* determine protocol */ switch(ip->ip_p) { case IPPROTO_TCP: printf(" Protocol: TCP\n"); // following code moved from outside the switch statement. /* * OK, this packet is TCP. */ /* define/compute tcp header offset */ tcp = (struct sniff_tcp*)(packet + SIZE_ETHERNET + size_ip); size_tcp = TH_OFF(tcp)*4; if (size_tcp < 20) { printf(" * Invalid TCP header length: %u bytes\n", size_tcp); return; } printf(" Src port: %d\n", ntohs(tcp->th_sport)); printf(" Dst port: %d\n", ntohs(tcp->th_dport)); /* define/compute tcp payload (segment) offset */ payload = (u_char *)(packet + SIZE_ETHERNET + size_ip + size_tcp); /* compute tcp payload (segment) size */ size_payload = ntohs(ip->ip_len) - (size_ip + size_tcp);

118

break; case IPPROTO_UDP: //printf(" Protocol: UDP\n"); // following code modified from TCP /* define/compute tcp header offset */ udp = (struct sniff_udp*)(packet + SIZE_ETHERNET + size_ip); size_udp = UDP_HDR_SIZE; //printf(" UDP Src port: %d\n", ntohs(udp->udp_sport)); //printf(" UDP Dst port: %d\n", ntohs(udp->udp_dport)); payload = (u_char *)(packet + SIZE_ETHERNET + size_ip + size_udp); size_payload = ntohs(udp->udp_length); break; case IPPROTO_ICMP: printf(" Protocol: ICMP\n"); return; case IPPROTO_IP: printf(" Protocol: IP\n"); return; default: printf(" Protocol: unknown\n"); return; } /* * Print payload data; it might be binary, so don't just * treat it as a string. */ if (size_payload > 0) { //printf(" Payload (%d bytes):\n", size_payload); print_payload(payload, size_payload); } return; } int main(int argc, char **argv) { char *dev = NULL; /* capture device name */ char errbuf[PCAP_ERRBUF_SIZE]; /* error buffer */ pcap_t *handle; /* packet capture handle */ //oringinal code: //char filter_exp[] = "ip"; /* filter expression [3] */ //new code: char *filter_exp = NULL; /*take as a command line argument*/ struct bpf_program fp; /* compiled filter program (expression) */

119

bpf_u_int32 mask; /* subnet mask */ bpf_u_int32 net; /* ip */ int num_packets = 0; /* number of packets to capture */ //print_app_banner(); /* check for capture device name on command-line */ if (argc == 2) { dev = argv[1]; filter_exp = "port 1234"; } //added some more arguments else if (argc == 3) { dev = argv[1]; filter_exp = argv[2]; } else if (argc > 3) { fprintf(stderr, "error: unrecognized command-line options\n\n"); print_app_usage(); exit(EXIT_FAILURE); } else { filter_exp = "port 1234"; /* find a capture device if not specified on command-line */ dev = pcap_lookupdev(errbuf); if (dev == NULL) { fprintf(stderr, "Couldn't find default device: %s\n", errbuf); exit(EXIT_FAILURE); } } /* get network number and mask associated with capture device */ if (pcap_lookupnet(dev, &net, &mask, errbuf) == -1) { fprintf(stderr, "Couldn't get netmask for device %s: %s\n", dev, errbuf); net = 0; mask = 0; } /* print capture info */ //printf("Device: %s\n", dev); //printf("Number of packets: %d\n", num_packets); //printf("Filter expression: %s\n", filter_exp); /* open capture device */ //original code (promiscuous mode): //handle = pcap_open_live(dev, SNAP_LEN, 1, 1000, errbuf); //new code (NOT promiscuous mode): handle = pcap_open_live(dev, SNAP_LEN, 0, 1000, errbuf); //end new code. if (handle == NULL) { fprintf(stderr, "Couldn't open device %s: %s\n", dev, errbuf); exit(EXIT_FAILURE); }

120

/* make sure we're capturing on an Ethernet device [2] */ if (pcap_datalink(handle) != DLT_EN10MB) { fprintf(stderr, "%s is not an Ethernet\n", dev); exit(EXIT_FAILURE); } /* compile the filter expression */ if (pcap_compile(handle, &fp, filter_exp, 0, net) == -1) { fprintf(stderr, "Couldn't parse filter %s: %s\n", filter_exp, pcap_geterr(handle)); exit(EXIT_FAILURE); } /* apply the compiled filter */ if (pcap_setfilter(handle, &fp) == -1) { fprintf(stderr, "Couldn't install filter %s: %s\n", filter_exp, pcap_geterr(handle)); exit(EXIT_FAILURE); } /* now we can set our callback function */ pcap_loop(handle, num_packets, got_packet, NULL); /* cleanup */ pcap_freecode(&fp); pcap_close(handle); //printf("\nCapture complete.\n"); return 0; }

121

ECE 4112 Internetwork Security

Lab 4: Firewalls

Group Number: _________ Member Names: ___________________ _______________________

Q1.1. Write down which ports are open:

Q1.2. What ports do you think should be left open to allow for normal internet traffic? Explain how your answer differs for say a host versus a server.

Q1.3. Write down which ports are open after the firewalls installation:

Q1.4. What happened differently in the results from exercise three as opposed to exercise one? Can you speculate what firewall rules caused this?

Q1.5. Comment on the differences now as opposed to the first rule used above:

122

Q1.6. Uncomment line 29 and restart the firewall. Explain what you saw and why:

Q1.7. Record these output in ethereal and comment on what you saw happen:

Q1.8. What did you see ?

Q1.9. Write down three rules that you think might be useful and explain what they do.

Q1.10 Open ethereal and capture a few of the shell packets, what is their format?

Q1.12 Why does the format of the protocol make it specially hard to catch with a firewall?

Q1.13 A common way network administrators check for backdoors running on their system is to do a “netstat -na” Do this on your slave system, do you see an open port for the reverse www shell? Why not?

123

Section 2 Q2.1. List the open ports on the Windows XP machine. Q2.2. Now that the firewall is configured and activated, list the open ports on the Windows XP machine. Q2.3. As far as personal firewall software goes, how does windows XP's ICF compared to Linux's iptables? Section 3 Q3.1. Can you ping each of these? Q3.2. Can you ping the address of the server (192.168.0.10) ? Q3.3. What does this command show? What does it mean? Q3.4. Try to access it from a web browser and see if you can do that. You could also telnet to port 80 and check this. Can you do it? Q3.5. Finally, can you ping the R2 terminal machine from the outside?

124

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.

125

General Questions How long did it take you to complete this lab? Was it an appropriate length lab? What corrections and/or improvements do you suggest for this lab? Please be very specific and if you add new material give the exact wording and instructions you would give to future students in the new lab handout. You may cross out and edit the text of the lab on previous pages to make minor corrections/suggestions. General suggestions like add tool xyz to do more capable scanning will not be awarded extras points even if the statement is totally true. Specific text that could be cut and pasted into this lab, completed exercises, and completed solutions may be awarded additional credit. Thus if tool xyz adds a capability or additional or better learning experience for future students here is what you need to do. You should add that tool to the lab by writing new detailed lab instructions on where to get the tool, how to install it, how to run it, what exactly to do with it in our lab, example outputs, etc. You must prove with what you turn in that you actually did the lab improvement yourself. Screen shots and output hardcopy are a good way to demonstrate that you actually completed your suggested enhancements. The lab addition section must start with the form “laboratory Additions Cover Sheet” which may be found on the class web site.

126

Turn-in checklist You need to turn in.

� Printout of the command pixGxx(config)# write terminal � Any corrections or additions to the lab.