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.
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.
This lab is due at 5:05pm, Thursday February 22nd, 2007. You must complete all of the following tasks for this lab. Each item is worth one (1) point. 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!
/etc/security/iptables-rules file so they can be loaded on startup.SSHD-BLACKLIST'.INPUT' chain to allow all traffic from the loopback interface 'lo'.INPUT' chain to allow all UDP traffic from source port 53 (which is DNS) from anywhere.INPUT' chain to allow all currently ESTABLISHED or RELATED connections to continue to function.INPUT' chain to cause all tcp traffic to port 22 to 'jump' to your newly created 'SSHD-BLACKLIST' chain.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.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.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.ICMP'.INPUT' chain to have all ICMP traffic to 'jump' to your newly created 'ICMP' chain.ICMP' chain that denies ICMP traffic from 128.138.202.101.ICMP' chain that allows ICMP traffic from anywhere else.ICMP' chain that denies ICMP traffic from the MAC address 00:0C:29:E9:3E:3C.ICMP' chain to rate limit the number of ICMP packets coming from the IP 128.138.242.252 to 30 packets per minute.INPUT' chain to 'DROP' all packets.You will have a few rules for dealing with SSH connections. Here's how I want them to specifically operate:
SSHD-BLACKLIST' chain.SSHD' chain for SSHDFilter.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:
[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 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.
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 'csel.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.