Goal:

• Understand firewalls, related seurity policies and security design principles.
• Learn how to use iptables provided in the Linux netfilter to construct a secure perimeter with DMZ hosting servers exposed to Internet.
• Review the basic route commands for setting up the packet routing of the Intranet and DMZ subnet.
• Learn how to set up network interfaces for the virtual machines and how virtual machines communicate with each others and Internet.
• Learn how to enforce a security policy using iptables commands.

Logistics:

We have setup Make sure you suspend the virtual machines each time you finish your experiment.

Configuration of Secure Perimeter Network Testbed:

• We will use vmware virtual machines for homework 5 exercises.
• Make sure you suspend your virtual machines after you finish your exercises and free up main memory for other team. If you use remote desktop connection, make sure you logoff not just disconnect. So that others can connect to these machines.
• We will use two ubuntu v10.10 server virtual machines to form a DMZ firewall, your fc13 virtual machiine as a DMZ web server, and the virtual machines bt4r1 and XPup you have created in hw2 as intranet machines to form our secure perimter network testbed. I have cloned two ubuntu v10.10 virtual machines and put them in the your designated vmware holder. When you acces the vmware server on your designated host, you will see these four folders as you open up your datastore.
• We will use walrus host, CS lab machines (those in EN138/140), or your home machine as a legitimate user or "malicious" machine to test the firewall policy.
• With those four virtual machines, each team will configure the virtual network interfaces to form a secure perimeter network testbed with DMZ, as similar to the system below. bt4r1 was not shown.
  
  
• Each testbed consists of a set of five machines: Two firewalls, one server runs apache web server for external web access; you are welcome to configure DNS server and mail server on the server virtual machines), and one XP client and one bt4r1 in intranet.
• We will use dvPortGroup_20bit switch for the DMZ subnet and dvPortGroup_24 switch for the intranet.
• Your designed VLAN_36n will be used an extranet and connected by the network adpater 1 of fwout.
• You should disconnect the connections you have on fc13, xpup, and bt4r1 that are connected to VLAN_36n by checking off the options with "connected" and "connect at power on".

Configure network interfaces of the virtual machine

• We will configure the virtual machines with two network interfaces. From the summary tab of the vmware server interface, you can see these two NICs are named Network Adapter 1 and Network Adapter 2 If you click on them and select "Edit". You should change the network label of the network adapter to match with the corresponding distributed VLAN switch .
• When the guest OS is started, these two NICs will be detected. You probably will imagine that they will show up from within the machines as eth0 and eth1. But they are not. The reason is as follows:
  • When you start your copy of the vm, the vmware server will detect that it has been moved or copied (very smart!) and it will prompt you to indicate whether it is "copied" or "moved". you will select "copied". Here is the rational behind the choices:
    • Six of you share the same vmware host. If all of you said the copy of the vm is "moved", then vmware will not change the original mac address in the configuration file (.vmx) and the guest OS will detect the same mac address and assigned the same ethernet #. But if two of you make the same "moved" choice, we will have two virtual machines share the same mac address and resulting an address conflict!!
    • Based on the above reason, we will choose "copied" when prompted. The vmware server will then pick a new unique mac address for the new copy of the virtual machine. (how they do that?!! a good test question!!). Now all six copies will run with different mac addresses and no address conflict! Amazing.
    • But by assigning a new mac address to the virtual machine, there is consequence! When the guest OS wakes up, it will detect a new mac address in its interface, and conclude that this is a new NIC card, therefore assigned it with a new ethernet #!!. The original eth0 will become eth3 or eth4.
    • There is a file in the /etc/udev/rules.d/70-persistent-net.rules we can edit to map the mac address to a specific ethernet #. For example, the one on cs591_dqout contains

      # line, and change only the value of the NAME= key.
      
      # PCI device 0x1022:0x2000 (pcnet32)
      SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0c:29:d2:b9:bc", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
      
      # PCI device 0x1022:0x2000 (pcnet32)
      SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0c:29:42:4e:8d", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
      
      # PCI device 0x1022:0x2000 (pcnet32)
      SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0c:29:42:4e:83", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth2"
      
      # PCI device 0x1022:0x2000 (pcnet32)
      SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0c:29:42:4e:97", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth3"
      

      By examining the configuration of network adpator 1 (click Network Aadpator 1 icon on the summary tab of chow_FWout),
      
      , we know that connectin is assigned with 00:0c:29:42:4e:83 mac address by vmware server.
    • we can edit the line with that mac address in from

      # PCI device 0x1022:0x2000 (pcnet32)
      SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0c:29:42:4e:83", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth2"
      
      to 
      # PCI device 0x1022:0x2000 (pcnet32)
      SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0c:29:42:4e:83", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"
      
      
      
      similar we can map mac address of the network adapter 2
       to eth1, and that of network adapter 3 to eth2.
      
      
      once the /etc/udev/rules.d/70-persistent-net.rules is edited, reboot the machine. You should 
      eth0, eth1, and eth2 map properly to network adapter 1, 2, and 3.

• Step 0. Start Virtual Machines
  • Use web interface or vcenter client to access vsphere server on eas-vcenter.uccs.edu.
  • Configure network adapter 1 to connect to your designated VLAN36n distributed switch and network adapter 2 to connect to dvPortGroup_20bit switch.
    
  • start <yourlogin>_fwout.
  • Next we will assign new static IP addresses to ufw1's three network interfaces.
  • Note that due to selection of creating of new idenifier to avoid conflict with other copies of the same ubuntu virtual machine, all two ethernets of the virtual machine are now assigned with new MAC address. When the vitual machine reboot, the guest OS will detect two new network interfaces and they could be assigned them with eth2 and eth3. Use the procedure mentioned above to change them back to eth0 and eth1.
    • Use "sudo bash" to obtain a bash with root
    • Type "ifconfig -a " to see the network interface recognized by the OS.
      

      csnet@beta:~$ sudo bash
      [sudo] password for csnet: 
      root@beta:~# ifconfig -a
      eth0      Link encap:Ethernet  HWaddr 00:0c:29:1a:45:34  
                BROADCAST MULTICAST  MTU:1500  Metric:1
                RX packets:117 errors:0 dropped:0 overruns:0 frame:0
                TX packets:79 errors:0 dropped:0 overruns:0 carrier:0
                collisions:0 txqueuelen:1000 
                RX bytes:15202 (14.8 KB)  TX bytes:8988 (8.7 KB)
                Interrupt:16 Base address:0x1400 
      
      eth1      Link encap:Ethernet  HWaddr 00:0c:29:1a:45:34  
                BROADCAST MULTICAST  MTU:1500  Metric:1
                RX packets:0 errors:0 dropped:0 overruns:0 frame:0
                TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
                collisions:0 txqueuelen:1000 
                RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
                Interrupt:18 Base address:0x1800 
      
      lo        Link encap:Local Loopback  
                inet addr:127.0.0.1  Mask:255.0.0.0
                inet6 addr: ::1/128 Scope:Host
                UP LOOPBACK RUNNING  MTU:16436  Metric:1
                RX packets:90 errors:0 dropped:0 overruns:0 frame:0
                TX packets:90 errors:0 dropped:0 overruns:0 carrier:0
                collisions:0 txqueuelen:0 
                RX bytes:10260 (10.0 KB)  TX bytes:10260 (10.0 KB)
      
                      

    • It shows that we have two network interface eth0 and eth1, and one loop back interface 127.0.0.1.
    • Assign eth0 with the first your designated IP address, eth1 with 172.16.<last byte of your first designated IP address>.1, and add a defaut gateway routing entry to allow outside access. Here for cs591 the designated IP address is 128.198.161.212. Therefore eth1 is assigned with 172.16.212.1 . The third byte in cs591case is 212 and is used to distinguish the different teams. Make sure you replace the following code with your own designated number.
      

      root@beta:~# ifconfig eth1  172.16.212.1 netmask 255.255.255.0
      root@beta:~# ifconfig eth0 128.198.161.212 netmask 255.255.255.224
      root@beta:~# ifconfig eth0:1 128.198.161.213/27
      root@beta:~# route add default gw 128.198.161.193
      root@beta:~# netstat -rn
      Kernel IP routing table
      Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
      128.198.161.192 0.0.0.0         255.255.255.224 U         0 0          0 eth0
      172.16.212.0    0.0.0.0         255.255.255.0   U         0 0          0 eth1
      0.0.0.0         128.198.161.193    0.0.0.0      UG        0 0          0 eth0
      
                      

    • Now you can use SSH secure shell client to access this virtual machine and capture the session dialog more easily.
    • Edit /etc/hostname to change the hostname from beta to <login>_ufw1
    • Edit /etc/networking/interfaces to include the network interfave configuration:
      

      # The loopback network interface
      auto lo
      iface lo inet loopback
      
      # The primary network interface
      #iface eth0 inet dhcp
      auto eth0
      iface eth0 inet static
      address 128.198.161.212
      netmask 255.255.255.224
      gateway 128.198.161.193
      
      auto eth0:1
      iface eth0:1 inet static
      address 128.198.161.213
      netmask 255.255.255.224
      
      # eth1
      auto eth1
      iface eth1 inet static
      address 172.16.212.1
      netmask 255.255.255.0
                      

    • Run "echo "1" > /proc/sys/net/ipv4/ip_forward" to allow packets to be forwared between the two NICs.
    • Run "iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE" to allow packets initial from DMZ or Intranet LAN to go out.
    • Note that if each iptables command with -A
    • After configure fwout, we will add "root@cs591_fwout:~# route add -net 10.0.0.0 netmask 255.0.0.0 gw 172.16.212.3" to allow intranet xpup/bt4r1 to ping ufw1 and send packet to Internet.
• Configure fwin.
  • Repeat the process similar above and configure internal firewall win.
  • Configure network adapter 1 to connect to dvPortGroup_20bit switch distributed switch and network adapter 2 to connect to dvPortGroup_24bit distributed switch.
  • We will assign eth0 with 172.16.212.3 and eth1 with 10.0.212.1.
  • Run "echo "1" > /proc/sys/net/ipv4/ip_forward" to allow packets to be forwared between the two NICs.
    

    
    root@c591_fwin:~# cat /proc/sys/net/ipv4/ip_forward
    1
    root@cs591_ufw2:~# netstat -rn
    Kernel IP routing table
    Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
    172.16.212.0    0.0.0.0         255.255.255.0     U         0 0          0 eth0
    10.0.212.0      0.0.0.0         255.255.255.0     U         0 0          0 eth1
    0.0.0.0         172.16.212.1     0.0.0.0          UG        0 0          0 eth0
    
    
                          

  • ping 172.16.212.1 after configuring the IP addresses.
    
• Configure FC13 server virtual machine.
• Follow the same steps as aboveto setup FC13.
• Configure network adapter 1 to connect to dvPortGroup_20bit switch.
• Click start this virtual machine.
• Enter root as username and the password distributed in class (same as that used in hw2p5 virtual machine).
• To bring up a shell terminal window on FC13, you select "Application | Accessories | Terminal" menuitem.
• set eth0 with IP address 172.16.212.2 and its gateway as 172.16.212.1, so that it can connect to Internet
• set a routing entry with 10.0.212.0/24 subnet so that all responses to intranet can be routed to inside firewall fwin.
• set up a default web page /var/www/html/index.html "<h2>This is cs591 secure site created by <your name></h2>" so that we can test the availability of web server inside DMZ from anywhere in Internet. The other network service we can test with DNAT is SSHD (port 22) on DMZ server.
• Edit /etc/sysconfig/network to add the hostname <login>_fc13.
• Edit /etc/sysconfig/network-scripts/ifcfg-eth0, replace the content with
  

  # Advanced Micro Devices [AMD] 79c970 [PCnet32 LANCE]
  DEVICE=eth0
  #BOOTPROTO=dhcp
  ONBOOT=yes
  NM_CONTROLLED=no
  BOOTPROTO=static
  NETMASK=255.255.255.0
  IPADDR=172.16.212.2
  GATEWAY=172.16.212.1
  TYPE=Ethernet
  USERCTL=no
  PEERDNS=yes
  IPV6INIT=no

• You need to change 212 to your designated number (the last byte of the IP address you used for external firewall.
• Run "service network restart". Double check the network configuration with ifconfig and route commands.
• Apache web server setup:
  • The recent version of Apache httpd web server starts to do self identity check, if cannot reliably determine the full qualifed domain name through DNS search, it will fail.
  • Normal DNS search sequence as specified in /etc/nsswitch.conf, is
    file dns
    Here the file is referred to /etc/hosts file.
    By modifying the /etc/hosts as follows, (commenting out 127.0.0.1 and add 172.16.77.2)

    # Do not remove the following line, or various programs
    # that require network functionality will fail.
    #127.0.0.1      fc22.csnet.uccs.edu fc11  localhost.localdomain localhost localhost
    172.16.212.2    cs591.csnet.uccs.edu cs591 localhost.localdomain localhost localhost
    
    ::1             localhost6.localdomain6 localhost6

    You should satisfy the httpd.

  • After modifying /etc/hsots, start apache httpd with "service httpd restart"
    

    root@rwhite2_fc9 ~]# service httpd restart
    Stopping httpd:                                            [FAILED]
    Starting httpd:                                            [  OK  ]

• Create a default web page with heading "<h1>CS591 secure testbed created by <your name>. </h1>" as /var/www/html/index.html on the server. This allows users to test the DNAT set up later on external firewall from outside browser.
• Setup intra1 XP client.
• use xpup. Set up the network connection (the biggest number in the set) with 10.0.212.2 and default gateway 10.0.212.1.
• For Window XP, Use Start | Settings | Control Panel | Network Connections | Local Area Network 6| Properties | Internet Protocol (TCP/IP)
  to set static IP address, Subnet mask, default gateway and DNS servers IP addresses (128.198.60.194 and 128.198.1.250) for the Intra1 window XP.
  

• Step1. Physical Layer Connection:
• In real network we will connect the ethernet cables from the PCs to the designed switch.
• If you are using VMWare server 2.0 at home, you need to specify the connection type (Bridged; NAT; Host-only; Customize) of each network interface.
  • By specifying bridged connection type, we use an external IP address and share the host's ethernet interface (similar to configure an network interface card (NIC) with multiple IP addresses using alias eth0:0).
  • By specifying NAT, the virutal network interface of our virtual machine is connected to an emulated switch VMNET-8 that provides NAT service. We can share the host ethernet connection. From the virtual machine, we typically use DHCP to request a private LAN IP address. It is typically 192.168.x.0/24. You can use ipconfig or ifconfig command on the host machine to find out what is the IP address of VMNET-8 assigned to the host. This is the same gateway address returns to the virtual machine by the DHCP protocol.
  • By specifying Host-Only, the virutal network interface of our virtual machine is connected to an emulated switch VMNET-1 that provides DHCP service. You are not allow to connect to outside world. You do have network connection to the host machine though.
  • By specifying customized, the virutal network interface of our virtual machine is connected to one of the 10 emulated switches (VMNET-1 to VMNET-9). You can assign different subnet addresses for those emulated switches from the virtual network setting menu.
• Step2. Test the network connectivities.
  • Once you configure the IP address, you want to verify you have connectivity among machines within the subnet.
  • For example, from fwout,
    • "ping 128.198.161.193" (default gateway), "ping 172.16.212.2" (dmzserver), and "ping 172.16.212.3" (fwin);
    • from xpup, "ping 10.0.212.1" (fwin).
    • from fc13, "ping 172.16.212.1" (default gateway) and "ping 172.16.212.3" (inner firewall).
  • Note that at this point, from xpup, "ping 172.16.121.1" will not get response, since we did not have a routing table entry for 10.0.212.0/24 set up on fwout and we did not turn on ip_forwarding on inner firewall.
• Step3. Configure the routing tables
  • Use "route add defaut gw <gatewayIPAddress>" and "route add -net <subnetAddress> -gw <gatewayTotheSubnet>" to configure routing table properly in the firewalls and DMZ server.
  • For example, on fwout, we use "route add default gw 128.198.161.193" and
    "route add -net 10.0.212.0/24 -gw 172.16.212.3".
  • With the first route commands, fwout should be able to ping 128.198.161.193 and Internet, including ping 128.198.1.250.
  • You now can bring in any scripts you have prepare from outside to fwout and then to fwin.
  • The 2nd "route add -net" command allow it send responses back to intranet.
  • Note that here in this testbed, the default gateway for fwout is csnet gatway with IP address128.198.161.193.
  • The default gateway for any DMZ machine, including dmzserver and fwin, is fwout and the related gateway IP adress to them to use in their "route add default gw" command is 172.16.212.1.
  • You need run "route add -net" command to allow intranet machine to talk to dmzserver, says for uploading web page to the DMZ web server.
  • The default gatway for any intranet machines including intra1 (XP) will be fwin. I will let you figure out what it is right gateway IP address to be used by intra1.
  • Use Start | Settings | Control Panel | Network Connections | Local Area Network | Properties | Internet Protocol (TCP/IP) to set static IP address, Subnet mask, and default gateway for the Intra1 window XP.
  • After setting up the above routing tables, if you still cannot ping outside machine from dmzserver, fwin, and intra1. The reason is the two firewall machines are not allowed packets to be forwarded between its two ports.
• Forwarding Packets
  • To allow that, we run 'echo "1" > /proc/sys/net/ipv4/ip_forward' command on both fwout and fwin. make sure you have " around 1 in the echo command. check if the ip_forward flag is set, by the command "cat /proc/sys/net/ipv4/ip_forward" to see if the memory resident file content is 1.
  • Now try ping 172.16.212.1 (fwout) from intra1. You will get response because the ICMP messages are forwarded by fwin. Same when you ping 10.0.212.2 from the DMZ server.
  • But you will find that you can not ping 128.198.1.250 (Internet; UCCS DNS server) from any machine except fwout.
  • Why this that? The reason is all the ICMP message from those machines will have private LAN address in their source IP address and their responses can not be routed back . To solve that, we need SNAT service on fwout. See Step4.
• Step4. Configure firewalls on FWout with proper firewall rules to provide DNAT/SNAT services.
  • Setup net alias on outer firewall fwout:
    • ifconfig eth0:1 128.198.161.213
      eth0:n is called alias for eth0; an ethernet interface can listen to multiple IP addresses
      
  • Use "iptables -L" and "iptables -t nat -L" to list the firewall rules.
  • To be safe, let us flush the firewall rules so that we start fresh. Same commands to use if iptables -L or iptables -t nat -L indicates the firewall rule set are garbled.
    • iptabels -F
    • iptables -t nat -F
    • If you find you can ping from intranet or DMZ machines but can not retrieve web page or SSH to internet machines, you can try to flush the rule set and reset your firewall.
  • The simplest DNAT and SNAT rules for testbed 2 are
    iptables -t nat -A PREROUTING -p TCP -i eth0 -d 128.198.161.212 --dport 80 -j DNAT --to-destination 172.16.212.2
    iptables -t nat -A PREROUTING -p TCP -i eth0 -d 128.198.161.213 --dport 22 -j DNAT --to-destination 172.16.212.2
    iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
    Here I assume 128.198.161.212 (213) is external IP address of the web server/ssh server. Internally the web server is run on dmzserver machine with 172.16.212.2.
  • With the first DNAT rule, outside (internet) machines can access the web page on our web server.
    • Try http://cs591.csnet.uccs.edu/ with the browser of windom or a home PC to verify the web server access. You should substitute the cs591 with the designate dns name associated with the IP address for the web server you specified in the DNAT service. For greg william he will use 128.198.161.220 as the web server IP address in the iptables command. Therefore he should use http://gwilla5.csnet.uccs.edu/ as url to verify the web access.
    • You can also use lynx, a text browser on -->walrus or use wget command to retrieve web page when you do not have access to the desktop environement for gui based browser.
    • Note that due to the default inclusion of the modsec module with apache on FC9, it will not allow http request with IP address in url. Therefore use the the domain name.
      Here is the log in modsec_audit.log where we access fc9 with IP address.
      

      Message: Access denied with code 400 (phase 2). Pattern match "^[\\d\\.]+$" at REQUEST_HEADERS:Host. [id "960017"] [msg "Host header is a numeric IP address"] [severity "CRITICAL"]
      Action: Intercepted (phase 2)
      Stopwatch: 1227281695740933 1332 (685 1003 -)
      Producer: ModSecurity v2.1.6 (Apache 2.x)
      Server: Apache/2.2.8 (Fedora)
  • With the 2nd SNAT rule, we should be able to access web pages of Internet web sites from any of the machines in the testbed and ping 128.198.1.250.
  • Also if you login to blanca, say using "ssh -l <yourlogin> blanca.uccs.edu" and type "lynx 128.198.161.212" you should be able to get a web page with heading "CS591 secure testbed created by <your name>. ". If you did not get web page, try check if the apache web server is running on dmzserver. Use "service httpd restart" to start it.
  • Email me the browser result such as lynx 128.198.161.212 as a proof that the DNAT is set up correctly.
    
  • For more complete and secure firewall rules, use the DMZ firewall shell script as a template. Replace with our network IP address and network info.
    http://iptables-tutorial.frozentux.net/scripts/rc.DMZ.firewall.txt
  • Verify DNAT by login to -->walrus and issue the http request to your DMZ web server. You can use lynx a text-based browser or wget command for such test. Capture the http response from the web server as a proof and deliverable.
  • Verify SNAT by accessing web site in Internet from intra1. Capture the http response from web server (screendump) as a proof and deliverable.
  • Another Experiment: Add firewall rules that follows fail-safe default principle by setting up the following default Policies. These drop rules will by default drip packets from other connections (those not specifies as ACCEPT) to and from the site. You may want to use iptables -F (to flush existing tables and get a clean start). The add these three commands. Followed by explicitly accepting specific machines or subnet such as iptables -A INPUT -s 128.198.60.197 -j ACCEPT. to accept connections from walrus, or iptables -A INPUT -s 128.198.0.0/16 -j ACCEPT to accpet connections from any machine in UCCS network.

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

• Step5. Check on the /var/log/messages or /var/log/secure on FWout. Examine who are trying to break in using ssh with root.
  • Note that we have set "PermitRootLogin no" in /etc/ssh/sshd_config therefore the firewall by default will not accept root user access from Internet.
  • Add firewall rules to drop packets from those intruders.
  • If there is no such attack, find out the IP addresses of walrus; add firewall rule to block its access to the DMZ web server; verify indeed the access is blocked on that specific machine; make sure others still able to access.
  • Observe if any more log occurs after the above firewall rules are inserted.
  • Provide the firwall rules and the log that prove successful blocking of specific machines as deliverable.
• Option Step6. start bt4r1 as intra2 machine in intranet and add firewall rules to disallow intra2 to connect to Internet.
  • To enable bt4r1 to accept SSH connection, you need to setup sshd server.
    • first create rsa and dsk keys:
      ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key
      ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key
      
    • start sshd with /etc/init.d/ssh start
    • set root password of bt4r1.
    • Note that the /etc/ssh/sshd_config of bt4r1 permit root login
  • Learn to create firewall rules as a shell script, similar to those examples in iptables-tutorials. http://www.frozentux.net/iptables-tutorial/iptables-tutorial.html.
    http://www.frozentux.net/iptables-tutorial/scripts/rc.DMZ.firewall.txt
  • Save the firewall rules and network configurations (ifconfig, netstat -rn) as a file for submission.
  • When you are done with your secure perimeter testbed, email me to examine it.
• Step7. Enforce the security policy that servers on DMZ can not initiate connections to intranet.
  • Hint: Apply the stateful firewall rules using -m state option to match connection state, similar to the rules below:

    iptables -A FORWARD -i ____ -m state --state NEW -j LOG --log-prefix "DMZ-intra Violation 
    iptables -A FORWARD -i ____ -m state --state NEW -j DROP
      
    Find what the option -i means and what should be its value in this case.      
                

  • Save the firewall rules and network configurations (ifconfig, netstat -rn) as a file for submission.
    Use command "iptables-save > ufw<name>rules.txt
    For example, it generates the following content, which correspnds to the set of iptables commands executed. The file can be read in using iptables-restore. It is faster then executing the scripts with ipables commands.
    
    # Generated by iptables-save v1.3.8 on Mon Nov 24 04:39:43 2008
    *nat
    :PREROUTING ACCEPT [20190:2778370]
    :POSTROUTING ACCEPT [162:12290]
    :OUTPUT ACCEPT [324:23761]
    -A PREROUTING -d 128.198.62.73 -i eth3 -p tcp -m tcp --dport 80 -j DNAT --to-destination 172.16.73.2
    -A PREROUTING -d 128.198.62.73 -i eth3 -p tcp -m tcp --dport 22 -j DNAT --to-destination 172.16.73.2
    -A POSTROUTING -o eth3 -j MASQUERADE
    COMMIT
    # Completed on Mon Nov 24 04:39:43 2008
    # Generated by iptables-save v1.3.8 on Mon Nov 24 04:39:43 2008
    *filter
    :INPUT ACCEPT [259:38777]
    :FORWARD ACCEPT [442:52183]
    :OUTPUT ACCEPT [114:11099]
    -A INPUT -s 128.198.162.60 -j LOG --log-prefix "BLANCA BLOCK"
    -A INPUT -s 128.198.162.60 -j DROP
    -A FORWARD -s 128.198.162.60 -j LOG --log-prefix "BLANCA BLOCK"
    -A FORWARD -s 128.198.162.60 -j DROP
    -A OUTPUT -s 128.198.162.60 -j LOG --log-prefix "BLANCA BLOCK"
    -A OUTPUT -s 128.198.162.60 -j DROP
    COMMIT
    # Completed on Mon Nov 24 04:39:43 2008
    
    
  • When you are done with your secure perimeter testbed, email me to examine it.

Questions:

• Q1. In Step 5, we indicate that the remote ssh root access is turned off to disallow intruders from guessing the password and login as root.
  • What is the benefit of adding firewall rules to drop packets from those intruders?
  • What rules you would like to add?
  • To what chains you add those rules?
• Q2. Similar to the DMZ firewall example in iptables tutorial http://www.frozentux.net/iptables-tutorial/scripts/rc.DMZ.firewall.txt.  The Sonic Firewall has three ports: one connects to Internet; one connects to DMZ subnet; and the last connects to the intranet. Their network topology is different from that of the above testbed, which has two firewall machines connecting through the DMZ LAN.
  Discuss what are the trade-off of these two different configurations based on the design principles mentioned in the firewall powerpoint presentation.
• Q3. Critic on the resource/machine assignments for this exercise: Suggest any improvement on the resource assignment.

Q&A:

From: CS 591 class email list [mailto:cs591-l@uccs.edu] On Behalf Of Edward Chow
Sent: Sunday, December 05, 2010 3:47 AM
To: CS 591 class email list
Subject: [CS591-l] Re: CS591 HW #5 problem (SOLVED!)

Rod,

From the attached screendump of your fwout,
You have ACCEPT 128.198.60.197 in INPUT chain which allow walrus packet to comes in.
But you forgot to also ACCEPT 128.198.60.197 in OUTPUT chain which allow the “response” of the session from walrus to return back to walrus.
That is the reason you can ping or ssh from walrus

Appear that you are trying to use the laptop at home with 192.168.0.196 as an IP address to test the iptables command with –j REJECT.
It does not work because 192.168.0.0/24 is not a routable IP address. When it goes out from your home gateway, it was changed to an external IP address assigned by your ISP to your internet connection, similar to our DNAT service.   Therefore, you should not use 192.168.0.196.

You need to add

Iptables –I  OUTPUT 1 –d 128.198.60.197 –j ACCEPT

Note that in the above command, we specifies –d  (not –s) since this chain governs the packet from fwout to walrus (the destination IP address contains 128.198.60.197)
I first use –s 128.198.60.197 and was not able to get ping or ssh connected. It is tricky!

After adding the above command, I was able to ping or ssh from walrus to rlykins.csnet.
See the following session data.

[cs591@walrus network-scripts]$ ping  rlykins.csnet.uccs.edu
PING rlykins.csnet.uccs.edu (128.198.161.170) 56(84) bytes of data.
^C
--- rlykins.csnet.uccs.edu ping statistics ---
8 packets transmitted, 0 received, 100% packet loss, time 7250ms

You have new mail in /var/spool/mail/cs591
[cs591@walrus network-scripts]$ ssh -l csnet 128.198.161.170
ssh: connect to host 128.198.161.170 port 22: Connection timed out
[cs591@walrus network-scripts]$ ping  rlykins.csnet.uccs.edu
PING rlykins.csnet.uccs.edu (128.198.161.170) 56(84) bytes of data.
64 bytes from 128.198.161.170: icmp_seq=1 ttl=62 time=0.969 ms
64 bytes from 128.198.161.170: icmp_seq=2 ttl=62 time=0.506 ms
^C
--- rlykins.csnet.uccs.edu ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1758ms
rtt min/avg/max/mdev = 0.506/0.737/0.969/0.233 ms
[cs591@walrus network-scripts]$ ssh -l csnet 128.198.161.170
The authenticity of host '128.198.161.170 (128.198.161.170)' can't be established.
RSA key fingerprint is 21:47:18:a6:3b:81:c0:3c:fa:ab:08:71:1d:ab:f7:e6.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '128.198.161.170' (RSA) to the list of known hosts.
csnet@128.198.161.170's password:
Linux (none) 2.6.35-22-generic-pae #33-Ubuntu SMP Sun Sep 19 22:14:14 UTC 2010 i686 GNU/Linux
Ubuntu 10.10

Welcome to Ubuntu!
* Documentation:  https://help.ubuntu.com/
Last login: Tue Nov 30 20:57:58 2010
csnet@(none):~$

To make it easier for you and your classmates to debug, I just created accounts on chow.csnet.uccs.edu (128.198.161.214) running FC14.
Same password as walrus. #a followed by SID without dash.  Note that  walrus and chow.csnet does not share file content.

You can add –j LOG command to log, then use –j DROP command to drop those from chow.csnet.

After adding iptables –I INPUT  3    ! –s 128.198.0.0/16 –j LOG –log-prefix ‘from HOME?’ to rlykins_fwout,  I ping it from home .
I did not receive any response (tell me why?)   but I did see it left the following log records on /var/log/messages of your fwout:

Dec  1 08:59:59 (none) kernel: [43344.794700] from HOME?IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:50:56:9b:01:80:08:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=328 TOS=0x10 PREC=0x00 TTL=128 ID=0 PROTO=UDP SPT=68 DPT=67 LEN=308
Dec  1 09:00:07 (none) kernel: [43352.791089] from HOME?IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:50:56:9b:01:80:08:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=328 TOS=0x10 PREC=0x00 TTL=128 ID=0 PROTO=UDP SPT=68 DPT=67 LEN=308
Dec  1 09:00:07 (none) kernel: [43352.791106] from HOME?IN=eth1 OUT= MAC=ff:ff:ff:ff:ff:ff:00:50:56:9b:01:80:08:00 SRC=0.0.0.0 DST=255.255.255.255 LEN=328 TOS=0x10 PREC=0x00 TTL=128 ID=0 PROTO=UDP SPT=68 DPT=67 LEN=308

For the bt4r1 problem,  you did not change network adapter 1 or 2 to 24-bit block dswitch and turn on “connected” or “connect at power on”.

I found I have a typo in ssh-keygen instruction for dsa key,
It should be

ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key
                                                                                     ^ a  not k (see the error in the above capture filenames

I am not sure if you have generated the key with protected pass-phrase (we should not do that).
I regenerated the two keys and /etc/init.d/ssh start and  that works.
The following are session captured to illustrate  Step 6 with access from fwin to bt4r1.
Note that we need to add 172.16.170.0/24 and 10.0.170.0/24 into the allowed subnet in INPUT and OUTPUT chains.
I also set the root password on bt4r1 to our typical vm password.

Here we start from a ssh terminal session to fwout.

root@(none):/var/log# ifconfig
eth0      Link encap:Ethernet  HWaddr 00:50:56:9b:01:74 
          inet addr:128.198.161.170  Bcast:128.198.161.191  Mask:255.255.255.224
          inet6 addr: fe80::250:56ff:fe9b:174/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:28015 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1363 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:3547115 (3.5 MB)  TX bytes:155963 (155.9 KB)
          Interrupt:18 Base address:0x2000

eth0:1    Link encap:Ethernet  HWaddr 00:50:56:9b:01:74 
          inet addr:128.198.161.171  Bcast:128.198.161.191  Mask:255.255.255.224
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Interrupt:18 Base address:0x2000

eth1      Link encap:Ethernet  HWaddr 00:50:56:9b:01:75 
          inet addr:172.16.170.1  Bcast:172.16.170.255  Mask:255.255.255.0
          inet6 addr: fe80::250:56ff:fe9b:175/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3702 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1321 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:649145 (649.1 KB)  TX bytes:1510714 (1.5 MB)
          Interrupt:19 Base address:0x2080

lo        Link encap:Local Loopback 
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

root@(none):/var/log# ping 172.16.170.1
PING 172.16.170.1 (172.16.170.1) 56(84) bytes of data.
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted
^C
--- 172.16.170.1 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 4032ms

root@(none):/var/log# iptables -A INPUT -s 172.16.170.0/24 -j ACCEPT
root@(none):/var/log# iptables -A OUTPUT -d 172.16.170.0/24 -j ACCEPT
root@(none):/var/log# iptables -A INPUT -s 10.0.170.0/24 -j ACCEPT
root@(none):/var/log# iptables -A OUTPUT -d 10.0.170.0/24 -j ACCEPT
root@(none):/var/log# netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
128.198.161.160 0.0.0.0         255.255.255.224 U         0 0          0 eth0
172.16.170.0    0.0.0.0         255.255.255.0   U         0 0          0 eth1
10.0.170.0      172.16.170.3    255.255.255.0   UG        0 0          0 eth1
10.0.0.0        172.16.170.3    255.0.0.0       UG        0 0          0 eth1
0.0.0.0         128.198.161.161 0.0.0.0         UG        0 0          0 eth0
0.0.0.0         128.198.161.161 0.0.0.0         UG        0 0          0 eth0
root@(none):/var/log# route del -net 10.0.00 gw 172.16.170.3
SIOCDELRT: Invalid argument
root@(none):/var/log# route del -net 10.0.0.0/8 gw 172.16.170.3
root@(none):/var/log# ping 172.16.170.3
PING 172.16.170.3 (172.16.170.3) 56(84) bytes of data.
64 bytes from 172.16.170.3: icmp_req=1 ttl=64 time=3.53 ms
64 bytes from 172.16.170.3: icmp_req=2 ttl=64 time=0.530 ms
^C
--- 172.16.170.3 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.530/2.033/3.537/1.504 ms
root@(none):/var/log# ssh -l csnet 172.16.170.3
The authenticity of host '172.16.170.3 (172.16.170.3)' can't be established.
RSA key fingerprint is 21:47:18:a6:3b:81:c0:3c:fa:ab:08:71:1d:ab:f7:e6.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '172.16.170.3' (RSA) to the list of known hosts.
csnet@172.16.170.3's password:
Linux (none) 2.6.35-22-generic-pae #33-Ubuntu SMP Sun Sep 19 22:14:14 UTC 2010 i686 GNU/Linux
Ubuntu 10.10

Welcome to Ubuntu!
* Documentation:  https://help.ubuntu.com/
Last login: Tue Nov 30 21:25:08 2010
csnet@(none):~$ sudo hostname fwin
^C

sudo: unable to resolve host (none)
[sudo] password for csnet:
csnet@(none):~$ ping -c 1 10.0.170.4
PING 10.0.170.4 (10.0.170.4) 56(84) bytes of data.
64 bytes from 10.0.170.4: icmp_req=1 ttl=64 time=1.79 ms

--- 10.0.170.4 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.799/1.799/1.799/0.000 ms
csnet@(none):~$ ssh -l csnet 10.0.172.4
ssh: connect to host 10.0.172.4 port 22: Connection timed out
csnet@(none):~$ ssh -l root 10.0.170.4
The authenticity of host '10.0.170.4 (10.0.170.4)' can't be established.
RSA key fingerprint is 23:5c:b4:38:66:68:dd:32:ff:2d:1b:8c:44:05:26:37.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '10.0.170.4' (RSA) to the list of known hosts.
root@10.0.170.4's password:
Connection closed by 10.0.170.4
csnet@(none):~$ ssh -l root 10.0.170.4
root@10.0.170.4's password:
Permission denied, please try again.
root@10.0.170.4's password:
Permission denied, please try again.
root@10.0.170.4's password:
Permission denied (publickey,password).
csnet@(none):~$ ssh -l root 10.0.170.4
root@10.0.170.4's password:
Permission denied, please try again.
root@10.0.170.4's password:
Permission denied, please try again.
root@10.0.170.4's password:
Permission denied (publickey,password).
csnet@(none):~$ ssh -l root 10.0.170.4
root@10.0.170.4's password:
Permission denied, please try again.
root@10.0.170.4's password:

BackTrack 4 R1 (PwnSauce Revolution)

root@bt:~#

Edward