Lab 7 Firewalls (MS Word)

7,487 views
7,348 views

Published on

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
7,487
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
100
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Lab 7 Firewalls (MS Word)

  1. 1. ECE4112 Internetwork Security Lab 7: Firewalls Group Number: _________ Member Names: ___________________ _______________________ Date Assigned: October 11, 2005 Date Due: October 20, 2005 (Note this is a Thursday!!!) Last Edited: November 15, 2005 Please read the entire lab and any extra materials carefully before starting. Be sure to start early enough so that you will have time to complete the lab. Answer ALL questions in the Answer Sheet and be sure you turn in ALL materials listed in the Turn-in Checklist on or before the Date Due. Goal: This lab will introduce to the concept of Firewalls. You will be experimenting with different kinds of firewalls. Summary: This lab is divided into three major parts. Part 1 explores the Linux firewall implementation in the form of the iptables program. Part 2 is a small introduction to Real Secure, one of the most popular Windows firewall programs. In Part 3, you will configure a Cisco PIX 515E firewall for a particular network structure. Part 1 and 3 might each take 2 hours or more, to finish. Therefore it is recommended that you start early. Background: None Prelab Questions: None Lab Scenario: NOTE: Part 3 of the lab requires you to reserve slots to use the equipment. The signup sheets will be posted on the lab door. For Part 1 of this lab, you will be setting up two virtual machines on your hard drive. One of the two will represent a protected machine inside a firewall, while the other will represent an attacker. We will use the host machine (WS 4.0) as a router that implements a firewall. The virtual machine network structure is shown below. These machines will be set up with host only networking, meaning any traffic they send or receive goes through the host machine. The host machine will be using the iptables program. 1
  2. 2. Figure 1-1. Network structure on the Firewall machines System Setup Protected: A normal Linux virtual machine with IP 192.168.0.10, netmask 255.255.255.0, and gateway 192.168.0.1. The gateway is a virtual interface on the host machine which acts like a router and firewall. This is the machine that is on the inside network and needs to be protected with the firewall. Linux Firewall: Red Hat WS 4.0 base system that is configured to act like a router and runs a firewall with ipchains. It forwards packets received on its two virtual interfaces (vmnet1 and vmnet2) to the intended destinations. You will make firewall rules on this machine to protect the inside network. BlackHat: Same configuration as the Protected machine. IP address is 131.210.231.55 and gateway is 131.210.231.1, which is the virtual interface vmnet2 on the host machine. This is the machine where you will try to attack the protected machine from. Note: All the root passwords for these machines have been set to “password”. Configuring the network Before configuring the firewall on the host machine, we must first setup the network described in Figure 1-1. Two virtual machine images have been placed on the NAS under the Lab 7 Folder for you to use: Protected and BlackHat. Both of these are Red Hat Linux WS 4.0 images. Copy the directories BlackHat and Portected to the folder that you have placed all other vmware images. This may take a few minutes per image. Before we create a virtual machine in VMWare, we must first configure both machines for host-only networking. 2
  3. 3. 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.10. . vmnet2 is a host-only network on private subnet 131.210.231.55. Do you wish to make additional changes to the current virtual networks settings ?(yes/no) [yes]No 3
  4. 4. Starting VMware services: Virtual machine monitor [ OK ] Virtual ethernet [ OK ] Bridged networking on /dev/vmnet0 [ OK ] Host-only networking on /dev/vmnet1 (background) [ OK ] Host-only networking on /dev/vmnet2 (background) [ OK ] What this has done is set up two virtual Host-Only Networks on /dev/vmnet1 and /dev/vmnet2. We are using the host-only networks to act like two independent subnetworks. Each virtual machine will act as if we are connecting it to an extra network card in the host. Start VMware by typing vmware &. In another terminal type ifconfig. All of the host-only networks appear along with eth0 and eth1, functioning as if they were physical network cards. Start both your WS4 virtual machines (refer to lab 1 if you forgot how to add a virtual machine). Right click on the tab that lists the name of the machine, and go down to “Settings”. The setting for “Ethernet1” needs to be changed from “Bridged” to “Custom: Specific virtual network”. The drop down box then needs to be set to either /dev/vmnet1 or /dev/vmnet2 depending on the specific virtual machine. Check the network diagram on Figure 1-1. Click on the RedHat Icon on the virtual machines and go to System Settings -> Network. Click on Edit to modify your settings, and change your gateway (see network diagram on Figure 1-1 again). Make sure the IP address is correct for each virtual machine. The gateway should be the IP of the host machine for the specific virtual network you are setting up. So for the Protected virtual machine, the IP address will be 192.168.0.10 and the gateway will be 192.168.0.1. Click OK. Then, click Deactivate, Activate, Apply. Close to change your settings. Try pinging your host machine from each virtual machine. $ping 192.168.0.1 $ping 131.210.231..1 Now that we have bound the virtual machines to our host, it is time to allow for packet forwarding through the host machine so that each virtual machine can communicate. On the host machine: To allow your host to forward or route IP packets, you need to type the following: $echo 1 > /proc/sys/net/ipv4/ip_forward <ENTER> This places a 1 in the file /proc/sys/net/ipv4/ip_forward. Check to make sure this command was successful by typing $cat /proc/sys/net/ipv4/ip_forward<ENTER> (1 should be printed on your screen). When Linux receives a packet, it looks at this file, and forwards if it sees a 1. This configuration is reset each time your physical machine is rebooted, so you must retype this command every time you reboot! Now see if you can ping the Protected machine from the BlackHat machine. You should be able to at the moment. 4
  5. 5. 1. Linux Firewalls In this section of the lab you will explore the Linux firewall iptables. The initial sections give an overview of basic firewall concepts with exercises and examples. In the later sections, you will implement all the rules in the iptables.firewall file available from the Lab7 directory on the NAS server. The effects of these rules are to be examined. To get started, open a terminal on the machine and start VMWare. You’ll see that some virtual machines have already been setup for you. We will be using the “Protected” and “Blackhat” machines, as shown in Figure 1-1. The host machine will act as the firewall. Setting up routing and 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 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). The /root/fresh_iptables directory contains a file called iptables.firewall file. This file contains all of the firewall rules we will use in this lab. The contents of this file are included in Appendix 1-A so you may follow the lab discussion in that file. You can execute this file to enable all the rules at once by executing it. Don’t execute it yet. Now go to the root directory (~/) and make a directory with your group name. Copy the iptables.firewall rule file from the /root/fresh_iptables directory into your group’s home directory. Make sure that whenever you edit the file, you are doing it in your own group’s home directory. At this time, also make a backup copy of the current iptables in a directory called fresh_iptables.bak. Once you are done with the lab, make sure to move this backup file back to the original directory so that every group gets the firewall in a similar state. Later in the lab, every time you need to restart the firewall with your rules, you can use the following commands: /etc/rc.d/init.d/iptables stop 5
  6. 6. ./iptables.firewall (in the directory with your edited iptables.firewall file) Again as a reminder, to enable packet forwarding on the Firewall machine, the line below needs to be executed. echo “1” > /proc/sys/net/ipv4/ip_forward This has already been done above, but remember that this command needs to be executed at restart. What this will do is to allow any FORWARD chain rules to be followed. This will make more sense later when we discuss packet forwarding in sections 1.2, 1.5 and 1.6. For now, just make certain that it is enabled by typing cat /proc/sys/net/ipv4/ip_forward 1.1.1. 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: 6
  7. 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 that has an Internet connection. This computer is considered a gateway because it provides the only point of access between your home network and the Internet. With a hardware firewall, the firewall unit itself is normally the gateway. A good example is the Linksys Cable/DSL router. It has a built-in Ethernet card and hub. Computers in your home network connect to the router, which in turn is connected to either a cable or DSL modem. You configure the router via a Web-based interface that you reach through the browser on your computer. You can then set any filters or additional information. Hardware firewalls are incredibly secure and not very expensive. Home versions that include a router, firewall, and Ethernet hub for broadband connections can be found for well under $100. 1.1.3. What It Protects You From: There are many creative ways that unscrupulous people use to access or abuse unprotected computers. The level of security you establish will determine how many of these threats can be stopped by your firewall. The highest level of security would be to simply block everything. Obviously that defeats the purpose of having an Internet connection. But a common rule of thumb is to block everything, and then begin to select what types of traffic you will allow. You can also restrict traffic that travels through the 7
  8. 8. firewall so that only certain types of information, such as e-mail, can get through. This is a good rule for businesses that have an experienced network administrator that understands what the needs are and knows exactly what traffic to allow through. For most of us, it is probably better to work with the defaults provided by the firewall developer unless there is a specific reason to change it. One of the best things about a firewall from a security standpoint is that it stops anyone on the outside from logging onto a computer in your private network. While this is a big deal for businesses, most home networks will probably not be threatened in this manner. Still, putting a firewall in place provides some peace of mind. 1.1.4. Demilitarized Zone DMZ stands for Demilitarized Zone. A DMZ is your frontline when protecting valuables from direct exposure to an untrusted environment. SI Security defines a DMZ as, "A network added between a protected network and an external network in order to provide an additional layer of security." A DMZ is sometimes called a "Perimeter network" or a "Three-homed perimeter network." A DMZ is a step towards defense in depth because it adds an extra layer of security beyond that of a single perimeter. A DMZ separates an external network from directly referencing an internal network. It does this by isolating the machine that is being directly accessed from all other machines. Most of the time the external network is the Internet and what is in the DMZ is the web server but this isn’t the only possible configuration. A DMZ can be used to isolate a particular machine within a network from other machines. This might be done for a branch office that needs its own Internet access but also needs access to the corporate network. In DMZ terminology, an internal connection is generally thought of as having more secret or valuable information than an external network. An easy way to understand which one is the internal network is to ask yourself which network I am protecting. Separation is important. Any system should have its important applications separated. This acts as system of checks and balances to make sure that if any one area goes bad that it cannot corrupt the whole. It is important to separate information so an attacker can’t get to all the systems. It would be bad enough for the attacker to get to the web server but if that attacker can get through the web server to your database then that’s even worse. This is the type of problem that a DMZ is designed to prevent. A DMZ’s separation will degrade performance. If configured correctly the degradation in performance is usually minimal and seldom noticeable. However, it does exist and you need to be aware of it. This effect on performance must be calculated in the total cost of implementing a DMZ. Usually the performance drop is nominal and the security increase is significant. Q1.2. What ports do you think should be left open to allow for normal internet traffic? Explain how your answer differs for say a host versus a server. 1.2.1. - IPtables Introduction Up until now, we've looked at stateless and stateful firewalls. Remember, stateless firewalls only have the features of a given packet to use as criteria for whether that packet should be passed, blocked, or logged. With a stateful firewall, in addition to the fields in that packet, we also have access to the kernel's table of open connections to use in deciding the fate of this packet. 8
  9. 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 9
  10. 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: 1. create a new chain (-N) NOTE: use upper case letters 2. delete an empty chain (-X) 3. list the rules for a chain (-L) 4. flush a chain (delete all rules in a chain) (-F) Commands to add/delete rules: 1. Append a new rules to a chain (-A) 2. Delete a rule at some position in a chain, or the first that matches (-D) The sections Note: The examples in these sections only demonstrate particular rules. They may or may not work for the network setup for the lab. 1.4.0. Iptables Parameters Parameters specify the type of packet that you are looking to match with your rule. 1.4.1. Specifying jump If a packet matches one of your rules, you can tell the packet to jump to another chain with the ‘-j’ option 10
  11. 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 11
  12. 12. iptables –A INPUT –s 130.207.232.1/24 –d 50.60.23.45 –p tcp 1.4.6 . State matching If the ‘ip_conntrack’ module is loaded, then connection-tracking analysis can be done on packets. You can check my typing lsmod. The module can be inserted using insmod ip_conntrack. The states which can be checked are: NEW A packet which creates a new connection ESTABLISHED A packet which belongs to an existing connection (i.e., a reply packet, or outgoing packet on a connection which has seen replies). RELATED A packet which is related to, but not part of, an existing connection, such as an ICMP error, or (with the FTP module inserted), a packet establishing an ftp data connection. INVALID A packet which could not be identified for some reason: this includes running out of memory and ICMP errors which don’t correspond to any known connection. Generally these packets should be dropped. An example of this powerful extension would be: iptables –A FORWARD –i eth0 –m state ! –state NEW –j DROP 1.4.7 - Limit explanation This module must be explicitly specified with `-m limit' or `--match limit'. It is used to restrict the rate of matches, such as for suppressing log messages. It will only match a given number of times per second (by default 3 matches per hour, with a burst of 5). It takes two optional arguments: --limit Followed by a number; specifies the maximum average number of matches to allow per second. The number can specify units explicitly, using `/second', `/minute', `/hour' or `/day', or parts of them (so `5/second' is the same as `5/s'). --limit-burst Followed by a number, indicating the maximum burst before the above limit kicks in. 12
  13. 13. This match can often be used with the LOG target to do rate-limited logging. To understand how it works, let's look at the following rule, which logs packets with the default limit parameters: # iptables -A FORWARD -m limit -j LOG The first time this rule is reached, the packet will be logged; in fact, since the default burst is 5, the first five packets will be logged. After this, it will be twenty minutes before a packet will be logged from this rule, regardless of how many packets reach it (60 minutes / 3 packets per hour). This value of twenty minutes is because the default limit is 3/hour. Also, every twenty minutes which passes without matching a packet, one of the burst will be regained; if no packets hit the rule for 100 minutes, the burst will be fully recharged to 5 packets (100 minutes / 20mintes per packet); back where we started. Note: you cannot currently create a rule with a recharge time greater than about 59 hours, so if you set an average rate of one per day, then your burst rate must be less than 3. You can also use this module to avoid various denial-of-service attacks (DoS) with a faster rate to increase responsiveness. Syn-flood protection (recall Datapool utility from Lab 3 for DoS using Syn Flood): # iptables -A FORWARD -p tcp --syn -m limit --limit 1/s -j ACCEPT or # iptables –N SYN-FLOOD # iptables –A SYN-FLOOD –m limit –-limit 20/s –-limit-burst 100 –j RETURN # iptables –A SYN-FLOOD –j LOG –-log-prefix “SYN-FLOOD: ” # iptables –A INPUT –p tcp –-syn –j SYN-FLOOD Furtive port scanner: # iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST RST -m limit --limit 1/s -j ACCEPT Ping of death: # iptables -A FORWARD -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT UDP Attack (from Lab 3): # iptables –N UDP-FLOOD # iptables –A UDP-FLOOD –m limit –-limit 20/s –-limit-burst 100 –j RETURN # iptables –A UDP-FLOOD –j LOG –-log-prefix “UDP-FLOOD: “ # iptables –A UDP-FLOOD –j DROP # iptables –A INPUT –p udp –j UDP-FLOOD 1.5.0. Network Address Translation (NAT) There are two types of NAT, source NAT and destination NAT. 13
  14. 14. Source NAT is when you alter the source address of the first packet: i.e. you are changing where the connection is coming from. Source NAT is always done post-routing, just before the packet goes out onto the wire. Masquerading is a specialized form of SNAT. A router might do masquerading for packets going from one of its internal machines to an outside connection. In this case it will change the source address of the machine to its own address. The external machine will see the packets coming from the router. Destination NAT is when you alter the destination address of the first packet: i.e. you are changing where the connection is going to. Destination NAT is always done before routing, when the packet first comes off the wire. Port forwarding, load sharing, and transparent proxying are all forms of DNAT. In the router example, the incoming packets intended for the internal machine are routed to it by changing the destination address to the internal address of the machine. 1.5.1 - NAT in the kernel You need to create NAT rules which tell the kernel what connections to change, and how to change them. To do this, we use the very versatile iptables tool, and tell it to alter the NAT table by specifying the `-t nat' option. The table of NAT rules contains three lists called `chains': each rule is examined in order until one matches. The two chains are called PREROUTING (for Destination NAT, as packets first come in), and POSTROUTING (for Source NAT, as packets leave). The third (OUTPUT) will be ignored here. The following diagram illustrates this concept: Figure 1-3 – NAT routing chains At each of the points above, when a packet passes we look up what connection it is associated with. If it's a new connection, we look up the corresponding chain in the NAT table to see what to do with it. The answer it gives will apply to all future packets on that connection. 14
  15. 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 1-A now) you need the following details: The most important option for the iptables command is the table selection option, `-t'. For all NAT operations, you will want to use `-t nat' for the NAT table. The second most important option to use is `- A' to append a new rule at the end of the chain (e.g. `-A POSTROUTING'), or `-I' to insert one at the beginning (e.g. `-I PREROUTING'). You can specify the source (`-s' or `--source') and destination (`-d' or `--destination') of the packets you want to NAT. These options can be followed by a single IP address (e.g. 192.168.1.1), a name (e.g. www.gnumonks.org), or a network address (e.g. 192.168.1.0/24 or 192.168.1.0/255.255.255.0). You can specify the incoming (`-i' or `--in-interface') or outgoing (`-o' or `--out-interface') interface to match, but which you can specify depends on which chain you are putting the rule into: at PREROUTING you can only select incoming interface, and at POSTROUTING you can only select outgoing interface. If you use the wrong one, iptables will give an error. You want to do Source NAT; change the source address of connections to something different. This is done in the POSTROUTING chain, just before it is finally sent out; this is an important detail, since it means that anything else on the Linux box itself (routing, packet filtering) will see the packet unchanged. It also means that the `-o' (outgoing interface) option can be used. 15
  16. 16. DNAT is done in the PREROUTING chain, just as the packet comes in; this means that anything else on the Linux box itself (routing, packet filtering) will see the packet going to its `real' destination. It also means that the `-i' (incoming interface) option can be used. 1.5.3. Port Forwarding When running a web server behind your firewall, you want to forward packets destined for that server through the firewall to that box. Example: # Linux 2.4 # Append a rule before routing (-A PREROUTING) to the NAT table (-t nat) that # TCP packets (-p tcp) going to 1.2.3.4 (-d 1.2.3.4) port 80 (--dport 80) # have their destination mapped (-j DNAT) to 192.168.1.1, port 80 # (--to 192.168.1.1:80). iptables -A PREROUTING -t nat -p tcp -d 1.2.3.4 --dport 80 -j DNAT --to 192.168.1.1:80 NOTE: This only changes the destination of the packet, it does not automatically accept it in the forwarding chain. A rule must be made in the forwarding chain also. 1.5.4. Masquerading There is a specialized case of Source NAT called masquerading: it should only be used for dynamically- assigned IP addresses, such as standard dialups. You don't need to put in the source address explicitly with masquerading: it will use the source address of the interface the packet is going out from. But more importantly, if the link goes down, the connections (which are now lost anyway) are forgotten, meaning fewer glitches when connection comes back up with a new IP address. ## Masquerade everything out ppp0. # iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE 1.6.0. iptables.firewall Script Explanation (See Appendix 1-A) These rules are already contained in our file iptables.firewall. We do not cover the rules in exactly the same order as they appear in your file. Go through these rules and understand what exactly is being done. 1.6.1. Load the iptables modules and connection tracking for ftp and nat: modprobe ip_tables modprobe iptable_nat modprobe ip_conntrack_ftp modprobe ip_nat_ftp 16
  17. 17. Configure default policies (-P), meaning default rule to apply if no more specific rule below is applicable. These rules apply if a more specific rule below is not applicable. Defaults are to DROP anything sent to firewall or internal network, permit anything going out. iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT ACCEPT 1.6.2. Flush (-F) all specific rules: iptables -F INPUT iptables -F FORWARD iptables -F OUTPUT iptables -F -t nat The rest of this file contains specific rules that are applied in the order listed. If none applies, then the above policy rules are used. Forward all packets from vmnet1 (internal network) to vmnet2 (the internet). iptables -A FORWARD -i vmnet1 -o vmnet2 -j ACCEPT Forward all packets that are part of existing and related connections from vmnet2 to vmnet1. iptables -A FORWARD -i vmnet2 -o vmnet1 -m state --state ESTABLISHED,RELATED -j ACCEPT Permit packets in to firewall itself that are part of existing and related connections. iptables -A INPUT -i vmnet2 -m state --state ESTABLISHED,RELATED -j ACCEPT Note, in the above two rules, a connection becomes ESTABLISHED in the iptables PREROUTING chain upon receipt of a SYNACK packet that is a response to a previously sent SYN packet. The SYNACK packet itself is considered to be part of the established connection, so no special rule is needed to allow the SYNACK packet itself. Allow all inputs to firewall from the internal network and local interfaces iptables -A INPUT -i vmnet1 -s 0/0 -d 0/0 -j ACCEPT iptables -A INPUT -i lo -s 0/0 -d 0/0 -j ACCEPT 1.6.3.Forwarding 17
  18. 18. Forward all http packets (port 80) to the internal VMware machine iptables -A PREROUTING -t nat –d 131.210.231.1 -p tcp --dport 80 -j DNAT --to 192.168.0.10:80 iptables –A FORWARD –i vmnet2 –p tcp -–dport 80 –j ACCEPT Forward all ssh packets (port 22) to the inside machine iptables -A PREROUTING -t nat –d 131.210.231.1 -p tcp --dport 22 -j DNAT --to 192.168.0.10:22 iptables –A FORWARD –i vmnet2 –p tcp -–dport 22 –j ACCEPT Turn on ip forwarding in case it wasn't already enabled echo "1" > /proc/sys/net/ipv4/ip_forward 1.6.4. Alternative to SNAT -- MASQUERADE If your firewall has a dynamic IP number (Tech uses static IPs while most cable/DSL providers, such as ATT and Bellsouth, and all dial-up connections only offer dynamic IPs) because it connects to the internet itself via DHCP, then you probably cannot predict what the IP number is of your firewall's interface connected to the internet. In this case, you need a rule like the following that assigns the (an) IP number associated with vmnet2 to outgoing connections without you needing to know in advance (at time of writing this rule) what that IP number is: iptables -A POSTROUTING -t nat -o vmnet2 -j MASQUERADE Deny any packet coming in on the public internet interface vmnet2 which has a spoofed source address from our local networks: iptables -A INPUT -i vmnet2 -s 192.168.0.0/24 -j DROP iptables -A INPUT -i vmnet2 -s 127.0.0.0/8 -j DROP If you query a particular remote DNS server, permit UDP responses from it. iptables -A INPUT -p udp -s <remote DNS server IP> --source-port 53 -d 0/0 -j ACCEPT 1.6.5. Defending against ICMP Ping Floods ICMP ping floods are commonly used attacks, especially by “script kiddies.” The attack is really simple, the attacker ping floods you and if he has more upstream than your downstream, you won’t be able to access anything. Iptables allows you to specify how many ICMP “echo” packets you want to reply to. This can be done by adding the following: 18
  19. 19. iptables -A INPUT –p icmp –-icmp-type echo-request –m limit -–limit 30/minute –-limit-burst 1 –j ACCEPT “30/minute’ means accept every other packet. An attacker may still ping flood you, but you won’t reply to it anyways, and he will give up soon. However, this also allows other people to ping you, just to test the network connection. The burst is set to 1 packet, so this limit will immediately take effect. Our Linux based firewall is already completely setup since the iptables.firewall file is provided for us, and all of the machines behind the firewall are protected from harmful traffic. We will now run some tests to show the results of the firewall installation. Exercise 3 Turn on the firewall rules by typing ./iptables.firewall (in the directory where your iptables.firewall is placed) If you have enabled the firewall before, you will need to flush the rules before executing the above command. Now rerun nmap from outside the firewall (BlackHat) on the Linux machine behind the firewall (Protected). Run nmap with these options: SCAN -> SYN Stealth DISCOVER -> Don’t Ping OPTIONS -> Don’t resolve Fast Scan TIMING -> Max RTT 40ms The command is nmap –sS –P0 –n –F –max_rtt_timeout 6 <Protected Linux machine IP> We must add this additional timing option because the firewall does not send a reset packet when nmap scans a closed port, it simply drops it. The RTT value specifies that nmap will not wait longer than 6ms for a response on a port. Note: 6ms is the smallest amount of time that is allowed for this option. In our case, since most packets will be dropped, increasing this value to something even as small as 40ms will cause this scan to take as long as 30 minutes. Q1.3. Write down which ports are open after the firewalls installation: Exercise 4 Q1.4. What happened differently in the results from exercise three as opposed to exercise one? Can you speculate what firewall rules caused this? Exercise 5 19
  20. 20. From BlackHat, we are going to ping the firewall to observe the rule which defends against icmp ping floods. The rule specified in this lab has the limit as 30/minute and a burst of 1. This means that every other packet will be denied and this rule will be enabled with the first packet. From your BlackHat, ping the firewall with these options: ping 131.210.231.1 –c 20 –w 4 Record this output in one window. Now change the rule in the iptables.firewall file to 10/minute and a burst of 5. Restart the firewall with the command /etc/rc.d/init.d/iptables stop ./iptables.firewall In another window from BlackHat ping the firewall with these options: ping 131.210.231.1 –c 20 –w 4 Q1.5. Comment on the differences between the first rule: Exercise 6 Now run ethereal on the firewall machine. Run with the options capture packets on ‘any’ interface, update packets in real time, and automatic scrolling. From the linux machine behind the firewall, ping BlackHat, outside of the firewall, with the command: ping –c 1 131.210.231.55 Record the ethereal output and comment on the number of packets observed and their source and destination addresses. Now, edit iptables.firewall and comment out line 31 which reads: iptables -A FORWARD -i vmnet2 -o vmnet1 -m state --state ESTABLISHED,RELATED -j ACCEPT Restart the firewall with the command /etc/rc.d/init.d/iptables stop ./iptables.firewall Repeat the previous ping and record and comment on the differences. Q1.6. Uncomment line 29 and restart the firewall. Explain what you saw and why: Exercise 7 20
  21. 21. Restart ethereal on the firewall machine. Run with the options capture packets on ‘any’ interface, update packets in real time, and automatic scrolling. From BlackHat, ssh to 131.210.231.1 Q1.7. Record these output in ethereal and comment on what you saw happen: Exercise 8 Now we are going to log any packets attempting to telnet to the firewall using the LOG chain. iptables –A INPUT –d 131.210.231.1 –p tcp --dport 23 –j LOG --log-prefix ‘TELNET ATTEMPT: ‘ Attempt to telnet from Black Hat to the firewall. Check /var/log/messages for these telnet attemps and record the output from the messages file. type tail /var/log/messages to see the end of the /var/log/messages file. Q1.8. What did you see: Exercise 9 Q1.9. Write down three rules that you think might be useful and explain what they do. You are now done with the Firewall Machine. Move the backup of the iptables file which you had created back into the /root/fresh_iptables directory to reset the firewall. Now that you have set up a Firewall to filter unwanted traffic and block ports we are going to explore a way to get around firewalls. One such way is through tunneling. Tunneling is wrapping one protocol within another one, the protocol you are wrapping is one that would not get by the firewall and the protocol you wrap it with is something that would get through the firewall. For example, you could hide shell commands inside of an http get tcp command. Since you are allowing users to use the internet in your DMZ their port 80s will be open and those packets will not be filtered. 2..0 SSH Bouncing through a Firewall Using Netcat Say you have a firewall and have multiple computers behind it that you want to access remotely using SSH. Intuitive options include either: • SSH to the firewall and then SSH to the target computer; however, this is a pain if you need to transfer files because you will have to transfer them to the firewall first. • Forward ports to different computers to login remotely using non standard SSH ports. This will require you to know which computer is at which port. This will also create public key conflicts. 21
  22. 22. However, with the help of netcat, you can create some scripts that will let you connect to any computer behind the firewall as if it there where not hops in between. We are going to do this by using the firewall setup in the lab. Again this is how the firewall is setup. Figure 1-1: Netwrok structure on the Firewall machines Perform the following steps in the BlackHat machine: • Create a file named config in /root/.ssh vi /root/.ssh/config • Write the following information in this file: Host protected Hostname 192.168.0.10 HostKeyAlias protected ProxyCommand netcat-proxy-command 131.210.231.1 %h Here Hostname is the computer behind the firewall, netcat-proxy-command is a script which we will create in the next step and %h is the local host name (linux replaces it automatically). You can add another • Now make a script in /usr/local/sbin named netcat-proxy-command vi /usr/local/sbin/netcat-proxy-command • Write the following in the file: #!/bin/sh bouncehost=$1 target=$2 22
  23. 23. ssh $bouncehost nc -w 1 $target 22 This script will create a proxy that will connect to the target computer behind the firewall after getting to the Firewall computer. Now make this script executable: chmod +x /usr/local/sbin/netcat-proxy-command • You will now need to comment out the line your iptables.firewall script that forwards port 22 (SSH). • Restart the iptables.firewall script with the command: /etc/rc.d/init.d/iptables stop ./iptables.firewall Now you can SSH from BlackHat to any computer behind the firewall defined in the .ssh/ configure file by typing the following command: ssh <HostKeyAlias> For example, you can SSH to the protected computer by running the following command: ssh protected The shell will ask for the password of firewall and then the password of Protected. Your window should look like the following screen shot. 23
  24. 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. 24
  25. 25. 25
  26. 26. 1.6.6 Reverse WWW Shell Reverse WWW Shell is a tunneling program that uses an interesting approach to tunneling. Instead of having the server listening on a port that can easily be detected it has the server connect to the client to get instructions the client has left in a certain directory. The shell commands in the Reverse WWW Shell look like http get calls and go through port 80. Because they look like innocuous web traffic, even proxy firewalls will have a hard time determining if the packets are malicious. It also has a random time frame for accessing the client so that it doesn't appear to be automated, to help evade sysadmins even more. Another program that works in the same manner is HTun, which can be found at http://htun.runslinux.net This section will be done on your removable hard drive using one of the Mini-Net machines. Download the source from the NAS (http://www.thc.org/releases/rwwwshell-2.0.pl.gz) Use the following commands to unzip and make executable: $ gunzip rwwwshell.pl.gz $ chmod +x rwwwshell.pl This is a shell script. So open it up in your favorite text editor and go to these lines # # MASTER CONFIG (specific for the MASTER) # $LISTEN_PORT=8080; # on which port to listen (80 [needs root] or 8080) $SERVER="127.0.0.1"; # the host to run on (ip/dns) (the SLAVE needs this!) We need to change the listen port to 80, since we have root on our master machine this is no problem, now enter the IP address of your machine that the slave will access. Now look at some of the options for the slave, we are going to need to change the timing of the system in order to get immediate feedback from our system, choose a time within the next 20 minutes for your SLAVE to check for commands. Also set the DEBUG field to no. You can also set eh delay between executing commands. Now that we have the slave set up we need to install it on our slave system. Open your Redhat 7.2 Virtual machine and transfer the perl file to it. You may use sftp or scp to do so. Now run: $ ./rwwwshell.pl slave now on the master run $ ./rwwwshell.pl master If you were successful the slave will connect to the master at the time entered in the code and allow you to type in root commands that will be executed on the slave system. If you have your firewall running you can check to see whether the packets were filtered or not, they shouldn't be with the standard 80 port open. 26
  27. 27. Q1.10 Open ethereal and capture a few of the shell packets, what is their format? Q1.12 Why does the format of the protocol make it specially hard to catch with a firewall? Q1.13 A common way network administrators check for backdoors running on their system is to do a “netstat -na” Do this on your slave system, do you see an open port for the reverse www shell? Why not? 27
  28. 28. 2. Windows Firewalls RealSecure Desktop Protector RSDP is a software firewall provided by OIT for Georgia Tech students. It is available at http://software.oit.gatech.edu/. It is available for download from the NAS. This section will guide you through the installation of this firewall and then show you some of its features. After download, the installation of RSDP requires a little preparation. Now double click EmployeeRSDP.exe. This will preform a silent, non-interactive, install. Now reboot your computer. A RSDP icon should appear in your task tray as in figure 1. Figure 1. RSDP task tray icon. Now lets configure RSDP. Single click the icon in the task tray. This should open up to a window which looks like figure 2. 28
  29. 29. 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
  30. 30. The quick links in this help file will give you more information about this event, such as what is effected by it and how to resolve it. In this case the information is trivial, we caused the event by rebooting after install. Right now we have a default configuration of RSDP, lets see what it does. On your Red Hat WS 4.0 machine, ping your windows box. #ping <windows XP IP> Stop the ping after a few seconds with ctrl-c You should see an output similar to figure 4. Figure 4. Result of pinging windows machine. Now look at your windows machine, you should not see a new event in your RSDP window. This is due to the default behavior of the firewall. You may, or may not, want ICMP messages to be able to reach your computer. We will change this behavior in a moment. But while it is still in the default configuration lets use nmap to scan our windows machine. #nmapfe This will open the graphical version of nmap. Now enter your windows XP machine's IP address and run nmap with the default entries, SYN stealth, TCP&ICMP, and OS detection should be selected. Click scan and see what it finds, this might take a while to finish. You should get the list that is in figure 5. Figure 5. Nmap scan output. 30
  31. 31. This shows that our default firewall setup is not bulletproof, we find information on several aspects of the victim machine. This shows that we even have open ports! This could be a disaster. Now look at the event window in RSDP, you should see a list similar to figure 6. Figure 6. RSDP alerts from nmap scan. Yikes, look at all those alerts. Nmap tries a lot of different methods to scan a computer, even with its default options. You are seeing an event for each different type of “attack”. Click on the Intruders tab, notice that it lists each IP that has accessed our machine. From here we can block the IP for either a specific amount of time, or forever. We don't need to block it since we are the attacker. Go back to the events tab. Notice the count for the TCP port scan. It should number several thousand. It is not possible to open the event info for this alert, since RSDP will attempt to check the ISS website for information. However, we know what caused this event and should be able to deal with it. Lets try and harden our firewall. Click tools, then edit settings, the select the firewall tab. Uncheck the boxes labeled allow NetBIOS neighborhood and allow Internet file sharing. We are not sharing files on our network, therefore these are merely security risks. If you are sharing files on your network then this action will cause you trouble. The packet log and evidence log tabs do just what they sound. They allow you to log information from your firewall. This is typically a very good idea, but we won't check the logs in this lab section. Lets go to the advanced rules section. Click tools, then advanced firewall settings. You should see a list of ports such as in figure 7. 31
  32. 32. Figure 7. Advanced Rules. The green circle means that these ports are open, the blue arrows indicated whether traffic is allowed to be incoming or outgoing in these ports. The top two ports are to allow an administrative interface at a remote location. Lets remove it. Click ok. Click tools, then edit settings, the select the management tab. Uncheck the box labeled Reporting enabled, and click yes on the pop up window. Click ok and go back to the advanced settings. Now we have disabled reporting, but we cannot edit the settings of these ports. These open ports are for the firewall software. Lets leave them alone and add some rules to prevent nmap from scanning our computer. Click add and a window should pop up. In the name field enter ICMP blocker. Select IP type from the drop down menu and click the all addresses box. From the value drag down box select ICMP[1]. Select both for the direction and forever as the time. Your window should now look like figure 8. 32
  33. 33. 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
  34. 34. Figure 10. Nmap scan again. Windows Built-in Firewall Start your Windows XP virtual machine. Now go back to the Red Hat WS 4.0 machine and run this command: nmap -sS -P0 -n -F -max_rtt_timeout 40 <Windows XP's IP> Q2.1. List the open ports on the Windows XP machine. Now go to the Windows XP Virtual machine. 1. Click Start-->Settings -->Control Panels-->Network Connections-->Local Area Connections. 2. Click the Properties button. 3. Click the Advanced Tab. 4. Check the box next to “Protect my computer and network by limiting or preventing access to this computer from the Internet”. This enables Windows' Internet Connection Firewall. 5. Now click the “Settings...” button. This allows you to configure the firewall. 6. Open the Security Logging Tab, and check the two check boxes next to “Log dropped packets” and “Log Successful connections”. 7. Now click “Ok” 8. Click “Ok” 9. Click Close. Q2.2. Now that the firewall is configured and activated, list the open ports on the Windows XP machine. Q2.3. As far as personal firewall software goes, how does windows XP's ICF compared to Linux's iptables? 34
  35. 35. 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
  36. 36. Appendix 1-A iptables.firewall #load the iptables modules and connection tracking for ftp and nat modprobe ip_tables modprobe iptable_nat modprobe ip_conntrack_ftp modprobe ip_nat_ftp # Configure default policies (-P), meaning default rule to apply if no # more specific rule below is applicable. These rules apply if a more specific # rule below is not applicable. Defaults are to DROP anything sent to firewall or # internal network, permit anything going out. iptables -P INPUT DROP iptables -P FORWARD DROP iptables -P OUTPUT ACCEPT # Flush (-F) all specific rules iptables -F INPUT iptables -F FORWARD iptables -F OUTPUT iptables -F -t nat iptables -A INPUT -d 131.210.231.1 -p tcp --dport 23 -j LOG --log-prefix 'TELNET ATTEMPT: ' # The rest of this file contains specific rules that are applied in the order # listed. If none applies, then the above policy rules are used. # Forward all packets from vmnet1 (internal network) to vmnet2 (the internet). iptables -A FORWARD -i vmnet1 -o vmnet2 -j ACCEPT # Forward packets that are part of existing and related connections from # vmnet2 to vmnet1. iptables -A FORWARD -i vmnet2 -o vmnet1 -m state --state ESTABLISHED,RELATED -j ACCEPT # Permit packets in to firewall itself that are part of existing and related # connections. iptables -A INPUT -i vmnet2 -m state --state ESTABLISHED,RELATED -j ACCEPT # Note, in the above two rules, a connection becomes ESTABLISHED in the # iptables PREROUTING chain upon receipt of a SYNACK packet that is a # response to a previously sent SYN packet. The SYNACK packet itself is # considered to be part of the established connection, so no special # rule is needed to allow the SYNACK packet itself. # Allow all inputs to firewall from the internal network and local interfaces iptables -A INPUT -i vmnet1 -s 0/0 -d 0/0 -j ACCEPT iptables -A INPUT -i lo -s 0/0 -d 0/0 -j ACCEPT 36
  37. 37. # Alternative to SNAT -- MASQUERADE # # If your firewall has a dynamic IP number because it connects to the # internet itself via DHCP, then you probably cannot predict what the IP # number is of your firewall's interface connected to the internet. In # this case, you need a rule like the following that assigns the (an) IP # number associated with vmnet2 to outgoing connections without you needing # to know in advance (at time of writing this rule) what that IP number is: # iptables -A POSTROUTING -t nat -o vmnet2 -j MASQUERADE # Deny any packet coming in on the public internet interface vmnet2 # which has a spoofed source address from our local networks: iptables -A INPUT -i vmnet2 -s 192.168.0.0/24 -j DROP iptables -A INPUT -i vmnet2 -s 127.0.0.0/8 -j DROP # If you query a particular remote DNS server, permit UDP responses from it #iptables -A INPUT -p udp -s <remote DNS server IP> --source-port 53 -d 0/0 - j ACCEPT #prevent DoS by icmp flood iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 30/minute --limit-burst 1 -j ACCEPT #prevent DoS by tcp syn flood iptables -A INPUT -p tcp --syn -m limit --limit 1/s --limit-burst 1 -j ACCEPT #forward all http packets (port 80) to internal linux machine iptables -A PREROUTING -t nat -d 0/0 -p tcp --dport 80 -j DNAT --to 192.168.0.10:80 iptables -A FORWARD -i vmnet2 -p tcp --dport 80 -j ACCEPT #forward all ssh packets (port 22) to internal linux machine iptables -t nat -A PREROUTING -d 131.210.231.1 -p tcp --dport 22 -j DNAT --to 192.168.0.10:22 iptables -A FORWARD -i vmnet2 -p tcp --dport 22 -j ACCEPT # turn on ip forwarding in case it wasn't already enabled echo "1" > /proc/sys/net/ipv4/ip_forward 37
  38. 38. Appendix 1-B Troubleshooting installation. Getting rid of ipchains: If your iptables script won’t correctly execute, and it gives an error about the device being busy then follow these steps. In order for iptables to work, ipchains must be turned off. First of all you will need to turn off the ipchains modules so it won't start in the future. To do this, you will need to change some filenames in the /etc/rc.d/ directory-structure. The following command should do it: chkconfig --level 0123456 ipchains off To turn the service off immediately however, type the following: service ipchains stop 38
  39. 39. Appendix 1-C Reference Websites: Differences Between iptables and ipchains: • http://www.netfilter.org/documentation/HOWTO/packet-filtering-HOWTO-10.html Small History of Filtering Under Linux: • http://www.geekcomix.com/cgi-bin/classnotes/wiki.pl? UNIX03/Ipchains_And_Iptables_-_Small_History_Of_Filtering_Under_Linux Packet Filtering with Linux: • http://www.linuxfocus.org/English/May2003/article289.shtml A Comparison of iptables Automation Tools: • http://online.securityfocus.com/infocus/1410 The last website is an article that compares some popular automation tools for iptables. While researching the web for Q3.10 of Lab 7, one of the reasons we found that companies do not use iptables more often is that it is strictly command line driven and that Cisco offers users an easier to use interface (as well as the traditional Cisco command line). We felt that more users might be willing to use iptables if there was an easier to use interface or a tool that could automate setting the firewall rules. On the website “http://online.securityfocus.com/infocus/1410” we looked at one such tool called AGT. AGT is downloadable from “http://sourceforge.net/projects/agt” and is very easy to install. It is downloaded as a gzipped tarball package that can be extracted by running the command # tar –xvfz agt-1.11.tar.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: default input drop 39
  40. 40. 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. 40
  41. 41. 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 41
  42. 42. # 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 42
  43. 43. input accept on eth+ proto tcp port http quota 512000 input drop on eth+ proto tcp port http # only allow 5 active ftp connections at once input drop on eth0 proto tcp port ftp limit 5 flags SYN # match this host's MAC address input accept on eth+ proto tcp port https mac 00:DE:AD:BE:EF:00 # match ftp, note that 'port' is equal to 'dport' input accept on eth+ proto tcp dport ftp # match multiple ports in one rule. input accept on eth+ proto tcp ports imap,imaps # allow connections to port 10000, if coming from port 4300 input accept on eth+ proto tcp port 10000 sport 4300 # allow 1 host to connect to our vpn :P input accept on eth+ proto tcp port pptp from host.somedomain.com # allow gre on any interface input accept on eth+ proto gre # block 50% of incoming pings, randomly. allow other icmp # valid icmp types obtained by running 'iptables -p icmp -h' # icmp-type is an alias for icmptype input drop on eth0 proto icmp icmptype echo-request random 50 input accept on eth+ proto icmp # not matched? close the TCP connection with a RST, others with host unreachable # valid 'with' options obtained by running 'iptables -j REJECT -h' input reject on eth+ proto tcp with tcp-reset input reject on eth+ with host-unreach 43
  44. 44. Appendix 1-D We realized that the first part of the Firewall lab is very technical and as a result, only advanced users may truly avail the benefits of the firewall. However, we were able to locate a powerful GUI environment based on iptables which greatly simplifies the use and functionalities of iptables. The name of the program is Guarddog. Installation of the program: 1. Go to this site: http://www.simonzone.com/software/guarddog/ 2. Click on the Download tab 3. Download the RPM file under RedHat 9: 2.2.0 RPM: guarddog-2.2.0-1rh9.i386.rpm 4. To install the program, type: “rpm –Uvh guarddog-2.2.0-1rh9.i386.rpm” 5. Reboot to start the script. To start Guarddog after reboot, type guarddog and a GUI interface will appear. Section 1: Protocols To specify a protocol, click on the protocol tab in the Guarddog GUI and expand Network. Click on the check box beside the desired protocol once to permit the protocol and click again to reject the selected protocol. For example: clicking the check box beside the ‘Ping’ twice rejects all pings. Figure 1. Ping box checked twice 44
  45. 45. Figure 2. Linux 7.2 tried to ping to workstation and failed. All protocols are listed on the protocols tabs and can be blocked or permitted as desired. Once pings are set to “reject,” a ping attempt from the 7.2 machine is unsuccessful, as shown in Figure 2. Section 2: Port Blocking To block specific ports using guarddog, click on the Advanced tab, and then select New Protocol. Enter a name for the new protocol (eg. “PortBlock”), and enter the port on which it will be active (eg. “1000”). Now go back to the “Protocol” tab and expand the User Defined group. The new protocol that you just created should be visible here, and you will have the freedom to block / permit any activity on that port. Section 3: Creating Zones At one point the lab required the creation of a “De-Militarized Zone”. This can be accomplished using Guarddog by clicking “Zones” and clicking “New Zone”. Name the zone “DMZ” and assign the address range and security protocols as necessary for this zone. This GUI environment greatly simplifies and would hasten progress in many sections of the lab. Therefore, it would be useful to replace all sections of the lab that use iptables, with fresh instructions on the use of Guarddog. 45
  46. 46. Appendix 1-E 1. Linux Firewall exploit Most firewalls do not usually allow any connections except FTP control connections to an FTP server port (TCP port 21 by default) for network security. However, as long as a file is transferred, they accept the data connection temporarily. To do this, a firewall tracks the control connection state and detects the command related to file transfer. This is called stateful inspection. The attack described here will make a firewall allow an illegal connection by deceiving its connection tracking using a forged FTP command. This attack is described in detail in the Phrack article http://www.phrack.org/phrack/63/p63-0x13_Breaking_Through_a_Firewall.txt An attacker can transmit a PORT command without the character <CR> in the end of the line. The command line has only <LF> in the end. An example is "PORT 192,168,100,100,26,11n". On the contrary, a standard FTP command has <CRLF> sequence to denote the end of a line. If the module ip_conntrack_ftp receives a nonstandard PORT command of this type, it first detects a command and finds the character <CR> for the parsing. Because it cannot be found, ip_conntrack_ftp regards this as a "partial" command and drops the packet. Just before this action, ip_conntrack_ftp anticipated the sequence number of a packet that contains the next FTP command line and updated the associated information. This number is calculated based on the TCP sequence number and the data length of the "partial" PORT command packet. However, a TCP client, afterwards, usually retransmits the identical PORT command packet since the corresponding reply is not arrived at the client. In this case, ip_conntrack_ftp does NOT consider this retransmitted packet as an FTP command because its sequence number is different from that of the next FTP command anticipated. From the point of view of ip_conntrack_ftp, the packet has a "wrong" sequence number position. The module ip_conntrack_ftp just accepts the packet without analyzing this command. The FTP server can eventually receive the retransmitted packet from the attacker. Although ip_conntrack_ftp regards this "partial" command as INVALID, some FTP servers such as wu-FTP and IIS FTP conversely consider this PORT command without <CR> as VALID. In conclusion, the firewall, in this case, fails to "expect" the FTP data connection. And when the attacker sends a RETR command to download a file from the server, the server initiates to connect to the TCP port number, specified in the partial PORT command, on the attacker's host. Suppose that the TCP port number is 6667(IRC server port), the firewall accepts this connection under the stateless packet filtering rule that allows IRC connections instead of the stateful filtering rule. So the IP connection-tracking module mistakes the connection for IRC. In conclusion, the attacker is able to illegally connect to any TCP port on the FTP server that the Netfilter firewall box protects. We had to take the following additional steps to make the exploit work on the Redhat 7.2 machine • Start/Flush iptables /etc/init.d/iptables restart • Setup connection tracking modprobe ip_conntrack_ftp 46
  47. 47. 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 66671n • Compile fake_irc.c and run it using the following command ./fake_irc 57.35.6.142 6667 ece4112 password /home/ece4112/irc.txt We have attached the output from the execution of the program. The Phrack article talks about two other exploits that work on the linux 2.4 kernel netfilter module. 2. Firewall spotting Here is an interesting article that we came across. http://www.phrack.org/phrack/60/p60-0x0c.txt It describes how to spot a packet filtering firewall is in place. It works on the principle that almost every available firewall does not check for a valid CRC before checking the destination port/address. A complete network stack will drop invalid packets without response. No matter if that port is closed, open or whatever... But Packet Filters aren't so smart and they will reply.If we want to determine if there is a packet filter between us and a target host we must first check if the packet filter is configured to drop the packets or to send back an error. For this we send a valid tcp packet to any port that is supposed to be filtered: # telnet www.oracle.com 31337 Trying 148.87.9.44... telnet: Unable to connect to remote host: Connection refused Good. Either the target host itself or a packet filter sends back a RST. Next step is to check if the RST comes from the target host or from a packet filter: # hping -S -c 1 -p 31337 -b www.oracle.com HPING www.oracle.com (rl0 148.87.9.44): S set, 40 headers + 0 data bytes len=46 ip=148.87.9.44 flags=RA seq=0 ttl=23 id=52897 win=512 rtt=459.8 ms If we get a reply we know that a packet filter is in place. If we dont get a reply we suspect that the packet arrives unfiltered at the destination host and is dropped by the TCP stack (e.g. no packet filter is in place). Another technique to detect the existence of a packet filter is to compare the TTL of a RST and a SYN (which comes directly from the target host). The TTL-technique fails for all packet filters in bridging mode or filters that do not decrease the TTL and are placed directly in front of the target host (normal DMZ setup). The CRC-technique as described above on the other hand detects a packet filtering device in both cases. 3. Windows firewall’s exploits 47
  48. 48. Windows Firewall is not as secure as MS would want you to believe. Windows Firewall only blocks or patrols incoming traffic and it can be easily turned off by another application, possibly a worm. We will look at how well Windows Firewall does at blocking incoming traffic by pinning it against several tests which scan for open ports and possible exploits. The tests, provided by PCFlank.com, include a Stealth Test, an Advanced Port Scanner test and an Exploit Test. The tests were run on a system running Windows XP with Service Pack 2. Based on their results, windows pass the Stealth Test and possible exploits, but it failed with an Advanced Port Scanner test. The stealth test checks to see if your computer is visible to the outside by sending packets to TCP:1 port on your machine. A good firewall should stealth your system from this connection attempt. The results show windows firewall passes this test. The Advanced Port Scanner tests your system for open ports. This can be used in attacks on your computer. There are two types of port scans which are TCP connect scanning and TCP SYN scanning. TCP connect scanning is the basic for of TCP scanning. TCP SYN scanning is also known as "half-open" scanning, because the scanner doesn't open a full TCP connection. The scanner sends a SYN packet, as if it is going to open a real connection and waits for a response. A good firewall will not report any open ports. According to the results Windows Firewall failed to stealth all of the ports scanned. Ports 135, 137, 138 and 139 were reported as closed when ideally a firewall should stealth all ports. When a port is reported as closed, this means that the port exists, therefore the system exist at that IP. The Exploits Tests will detect how vulnerable your computer is to exploits attacks by sending unexpected packets to the victims PC. The results show that Windows Firewall was able to defend itself from the denial-of-service attacks. Stealth Test: 48
  49. 49. Advanced Port Scan: Exploits Test: Source: http://www.flexbeta.net/main/printarticle.php?id=76 49
  50. 50. 4. Additional question to Section 2, list some recently discovered Windows Firewall Exploits. A weakness has been identified in Microsoft Windows, which could be exploited by local users to hide certain information. This flaw is due to an error in the way that the Windows Firewall User Interface handles malformed entries in the Windows Registry, which could be exploited by attackers or worms, when a system has already been compromised, to create Windows Firewall exception entries that will not be displayed in the Windows firewall graphical user interface. At least one recent exploit in Internet Explorer, there are certain exploits that anti- anything (virus, spyware, pop-ups, etc) products are powerless against. What's your last line of defence to keep one of these exploits from phoning home? Outbound blocking – is a feature that the Windows Firewall lacks. 50
  51. 51. Part 3 – Cisco PIX 515E Introduction A hardware firewall usually has at least three interfaces, although many early implementations had two interfaces. It is still common to install a two-interface firewall. When using a firewall that has three interfaces, at least three networks are created. The three areas that are created by the firewall are described as follows: • Inside – The Inside is the trusted area of the internetwork. The devices on the Inside are the organization's private network (or networks). These devices share a common security policy relative to the Outside (the Internet) network. It is, however, a common practice to have a firewall to segment the trusted environment. If one department, such as Human Resources, needs to be protected from the rest of the trusted users, a firewall may be used. • Outside – The Outside is the untrusted area of the internetwork. The firewall secures the devices on the Inside and DMZ from the devices on the Outside. In the course of doing business, organizations typically allow access to the DMZ from the Outside. • DMZ (Demilitarized Zone) – The DMZ is an isolated network, or networks, which is usually accessible to the Outside users. The firewall must be configured to allow access from the Outside or Inside to the DMZ. The creation of a DMZ allows an organization to make information and services available to Outside users in a secure and controlled environment. The hosts or servers that reside on the DMZ are commonly referred to as bastion hosts. In this case, a bastion host is a host that is current with regard to its operating system and patches to that operating system. The action of being current will usually make it less vulnerable to attack because the vendor has fixed or "patched" any known security flaws. The bastion host is a host that is running only those services necessary to make it perform its application duties. Unnecessary (and sometimes more vulnerable) services are turned off or removed from the host. Figure 3-1 illustrates this general network design. . . Source: Chapman, D. W. and Fox, A., Cisco Secure PIX Firewalls, Cisco Press. 2002 51
  52. 52. Figure 3-1 – General Network Design Using a Firewall The baseline perspective for a firewall is to perform the following functions: • Permit no access from the Outside to the Inside. • Permit limited access from the Outside to the DMZ • Permit all access from the Inside to the Outside. • Permit limited access from the Inside to the DMZ. The PIX Command-Line Interface. The PIX Firewall contains a command set similar but not identical in syntax to the Cisco . Source: Chapman, D. W. and Fox, A., Cisco Secure PIX Firewalls, Cisco Press. 2002 52
  53. 53. IOS command set. When accessing a specific command, you must be in the proper mode (for that particular command) to access that particular command. The PIX provides four administrative access modes: • Unprivileged Mode – This mode is available when first accessing the PIX Firewall. This mode is frequently referred to as user EXEC mode. The> prompt is displayed. This mode lets you view a subset of all commands available. A user cannot make configuration changes if unprivileged mode is the only mode accessible. • Privileged Mode – This mode displays the # prompt and enables you to change the current settings. Any unprivileged command also works in privileged mode. Once you have access to privileged mode, you have access to configuration mode. • Configuration Mode – This mode displays the (config)# prompt and enables you to change system configurations. All privileged, unprivileged, and configuration commands work in this mode. • Monitor Mode – PIX Firewalls have a special mode called the monitor mode that permits you to perform special tasks that could otherwise not be performed like updating an image over the network. Table 1 – Distinctive PIX Prompt for Administrative Modes Mode Prompt Unprivileged mode pixfirewall> Privileged mode pixfirewall# Configuration mode pixfirewall(config)# Monitor mode monitor> Within each access mode, you can abbreviate most commands down to the minimum length needed to make them unique. For example, you can enter wr t to view the configuration instead of entering the full command, write terminal. Additional examples are to enter en instead of enable to start privileged mode and co t instead of configuration terminal to start configuration mode. Help information is available from the PIX Firewall command line by entering help or ? to list all commands. If you enter help or ? after a command (for example, route?), the command syntax is listed. The number of commands listed when using the help (?) command differs by access mode. In addition, you can enter any command by itself on the command line and then press Enter to view the command syntax. Note – A configuration file may be created offline using a text editor. A user may then copy and paste it into the PIX configuration. The PIX allows entire configuration to be input this way or one line at a time. 53
  54. 54. A list of useful commands, while using the PIX user interface is given in Appendix A. 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. . Source: Chapman, D. W. and Fox, A., Cisco Secure PIX Firewalls, Cisco Press. 2002 54
  55. 55. Figure 3-2 – PIX Security levels. PIX interface The basic commands to be used in the PIX command interface are shown in Appendix A. Go over these commands at this time and keep them in mind when you are doing the lab exercises. You will need most of them at that time. For example, the enable command will be used to get started with the firewall. It provides entrance to the privileged access modes. The configure terminal command is used to move from the privileged mode to the configuration mode. The command prompt in the mode is (config)# .You can also use the hostname command to change the hostname label on the prompts (e.g. hostname newname ). Now let’s try to configure the firewall for the network setup in the lab. Network setup You will need to understand the structure of the Mini-net in the lab, to complete this lab. The diagram describing the Mini-net should be attached to the lab handout. There are six autonomous systems – 4 Tier 2 systems and 2 Tier 1 systems. The firewall is located in the Enterprise – Cisco system. It is marked as the “Edge-fwall” in the diagram. You should be able to figure out the network and host address of the routers and interfaces from the diagram. If you’re having trouble reading the diagram, you can ask a TA for help. For security reasons, the network is configured such that you cannot access the firewall interface from the mini-net in the lab. To access the firewall, you’ll have to use the ECE computers on the right side of the lab. These computers need an ECE UNIX account. If you don’t have one, go to the UA station in Rm 310, across the corridor, and ask for an UNIX account. It shouldn’t take long for the UA to set it up. In addition to this machine, you will need access to the R2 terminal, to test the firewall from the inside network. You will also need to access the terminal machine to test the firewall from the outside network. 55
  56. 56. NOTE: It is important that you access the firewall only during your reserved slot. Accessing the firewall, while some other group is doing their lab, will mess up the configuration and both of you will have to start over. Connection to the Firewall On your host machine, use the following command: ifconfig eth0:0 192.168.254.x where x is the last octet of the first ip address you were assigned. Now ssh into the playstation1 setup using the following command: ssh playstation1@192.168.254.2 The password is “playstation1” Once you enter the password, you’ll see a port access menu. This menu lists all the ports the console manager is connected to. The port for firewall is 12. So press 12 and then Enter. Press Enter a couple of times and you’ll see the prompt for the Cisco firewall. Initial Configuration We’ll be starting from scratch so let’s first reset the firewall and put it back into its original factory settings. The current configuration is stored in the flash memory. The write erase command erases this configuration in the memory. Next, you have to type the reload command. Since there is no configuration in memory, the firewall reverts to its original settings. Initially you’ll see the hostname set by the previous group, and the “>” prompt. In the commands given below, the “>” and the “#” sign refer to the prompts. Type them in to configure the firewall. Step 1 To enter the privileged mode, type > enable Password: <Press ENTER> The prompt changes to # Enter the following commands in front of the TA. # write erase Erase PIX configuration in flash memory? [confirm]: <Press ENTER> # reload Proceed with reload? [confirm] : <Press ENTER> The firewall will reboot. Once it reboots, you’ll see the following question, Pre-configure PIX Firewall now through interactive prompts [yes]? <Type no and ENTER> Now you’ll see the default firewall prompt pixfirewall> 56

×