Lab 04 - IPTables Configuration

There was an old pirate named Bates
Who was learning to rhumba on skates.
        He fell on his cutlass
        Which rendered him nutless
And practically useless on dates.

Overview

The main part of this assignment is to configure your IPTables firewall with a strict default policy to drop all packets in to your machine, and then setup exceptions to that strict policy. I will then be testing your firewall remotely to see if it is functional.

For your reading, you can look at this great page that goes through many different pieces of IPTables options and configurations:
http://iptables-tutorial.frozentux.net/iptables-tutorial.html. In fact, this is all the reference you get for this lab, so learn to know it well.

Remember to take GREAT CARE when setting up these rules! If you set them up in the wrong order, you will lose your remote connection to your machine. Think *carefully* about changing things like your default policy or rules, as the order can drastically affect behavior of your firewall.

There will be no more spoon feeding. I have nae given any commands in the lab for you to type out like a monkey. Hey monkey, you can always email me to ask questions for clarification and other details.

Tasks and Grading

This lab is due at 9:30am, Tuesday February 26th, 2008. You must complete all of the following tasks for this lab. Note that the rules below may not all be in the exact order in which you must add them to your firewall rules. Be smart and think about the logic of your rules!

  1. All of your rules you create below must also exist in your /etc/security/iptables-rules file so they can be loaded on startup. Note: if you did not get lab02 working, I highly recommend that you do otherwise you will be hurting a LOT on this lab.
  2. Your previous SSHDFilter rules remain intact and continue to function.
  3. Create a user-defined chain called 'SSHD-BLACKLIST'.
  4. Add a rule to your 'INPUT' chain to allow all traffic from the loopback interface 'lo'.
  5. Add a rule to your 'INPUT' chain to allow all UDP traffic from source port 53 (which is DNS) from anywhere.
  6. Add a rule to your 'INPUT' chain to allow all currently ESTABLISHED or RELATED connections to continue to function.
  7. Add a rule to your 'INPUT' chain to cause all tcp traffic to port 22 to 'jump' to your newly created 'SSHD-BLACKLIST' chain.
  8. Add a rule to your 'INPUT' chain to allow NEW tcp connections to destination port 22 from anywhere. This rule must come after your 'SSHD' and 'SSHD-BLACKLIST' chain jump rules.
  9. Add a rule to your 'SSHD-BLACKLIST' chain to deny all connection attempts from the machine 128.138.129.12 and log them at loglevel 'info' with prefix 'SSHD-BLACKLIST: ' (note the trailing space) using the logging target.
  10. Add a rule to your 'SSHD-BLACKLIST' chain to deny all connection attempts from the IP address range 128.138.202.192 - 128.138.202.255 (the highest 64 addresses in the CSEL subnet). You MUST create this rule using a CIDR mask that blocks ONLY those 64 addresses.
  11. Create a user-defined chain called 'ICMP'.
  12. Add a rule to your 'INPUT' chain to have all ICMP traffic to 'jump' to your newly created 'ICMP' chain.
  13. Add a rule to your 'ICMP' chain that denies ICMP traffic from 128.138.202.101.
  14. Add a rule to your 'ICMP' chain that allows ICMP traffic from anywhere else.
  15. Add a rule to your 'ICMP' chain that denies ICMP traffic from the MAC address 00:16:3E:44:70:0A (which is elra-04.cs.colorado.edu's eth0 device)
  16. Add a rule to your 'ICMP' chain to rate limit the number of ICMP packets coming from the IP 128.138.202.180 to 30 packets per minute.
  17. Set the default policy on your 'INPUT' chain to 'DROP' all packets.

Clarifications

SSH chain and rule ordering

You will have a few rules for dealing with SSH connections. Here's how I want them to specifically operate:

  1. Incoming SSH traffic first hits your 'SSHD-BLACKLIST' chain.
  2. If the packet passes through that chain without a match, I then want it to go through the 'SSHD' chain for SSHDFilter.
  3. Then, if no rules match, I want the packet to hit the 'allow new incoming SSH connections' rule in the INPUT chain.

Rate limiting

Rate limiting packets is much more difficult than it seems. The intuition would be to say allow or deny X packets that match rule R per Y time unit. However, IPTables does NOT do this. Read VERY carefully about the limit module to figure out how to rate limit packets. To assist you in this part, I will give you the tests I will perform for rate limiting:

  1. Ping once per second, for 60 seconds (60 packets total)
  2. Ping once per half-second, for 60 seconds (120 packets total)
  3. Ping once per second, for 120 seconds (120 packets total)
[20:33:28]schenkc@mroe:~$ ping -c 60 -q grasshopper
PING grasshopper.cs.colorado.edu (128.138.242.231) 56(84) bytes of data.

--- grasshopper.cs.colorado.edu ping statistics ---
60 packets transmitted, 30 received, 50% packet loss, time 59016ms
rtt min/avg/max/mdev = 0.097/0.108/0.153/0.016 ms, pipe 2
[20:34:52]schenkc@mroe:~$ sudo ping -c 120 -i .5 -q grasshopper
PING grasshopper.cs.colorado.edu (128.138.242.231) 56(84) bytes of data.

--- grasshopper.cs.colorado.edu ping statistics ---
120 packets transmitted, 30 received, 75% packet loss, time 59885ms
rtt min/avg/max/mdev = 0.092/0.102/0.134/0.011 ms, pipe 2
[20:36:22]schenkc@mroe:~$ ping -c 120 -q grasshopper
PING grasshopper.cs.colorado.edu (128.138.242.231) 56(84) bytes of data.

--- grasshopper.cs.colorado.edu ping statistics ---
120 packets transmitted, 61 received, 49% packet loss, time 119085ms
rtt min/avg/max/mdev = 0.092/0.106/0.128/0.010 ms, pipe 2

I will allow for a window of +/- 4 packets from the target 30/minute limit. Ping sends one packet per second by default, and if you wish to send at a faster rate, you must have root. Notice that the output of all three allowed 30, 30 and 30.5 packets per minute, respectively.

Logging

Logging shouldn't be too bad, just remember to use the 'LOG' target and options for setting the loglevel properly. Those log entries go to the 'kern' facility. You can see which log file (if any) that the 'kern' facility goes to in syslog by looking at /etc/syslog.conf. Look specifically for the line containing kern.*.

One important thing to remember about the 'LOG' target is that it does NOT stop processing of that packet within iptables! This means even when you log the packet at level 'info', the packet still goes through the whole chain and other chains.

Rules based on MAC addresses

I as you to block all ICMP traffic from a specific MAC address. Well, how can you test this rule if you aren't on the machine with the specific MAC address I'm asking you to block? Simple, use another machine from which you DO have access (like the machine 'elra-04.cs.colorado.edu') and use the MAC address from that machine and use it to test your rule (you can use 'ifconfig' to find a MAC address). Once you're confident that it works, then change the rule back to match the specific MAC address I specify in the lab. Remember the larger fact that MAC address filtering ONLY works on the local area network where you are (in our case 128.138.202.0/24), and nowhere outside.

How to test any of the rules that have IP addresses or MAC addresses that you do not control

Simple, you simply test using a machine that you DO have access to. You have access to elra-01 through elra-04, and you can find out IP addresses and MAC addresses using the 'ifconfig' command on those machines.

Commands Used

  • iptables (man page) - A crazy huge man page with all you ever wanted to do in iptables
  • ifconfig (man page) - Allows you to see current network interfaces as well as configure them