CSC175 Packet Filtering Assignment 1 This assignment is in two parts. The first part will require you to use iptables to configure your linux server according to a set of specifications, which will be tested by a really nasty hacker. The second part is a paper assignment that asks you to configure a hypothetical router/firewall. The second part should be completed individually. ---------------------------------------------------------------------------- PART I: Lab Exercise PRE-LAB Checklist: 0. First, make sure the routing table of your host can see deepdish as well as other hosts in the "secret" network, such as: 10.1.0.0/16 dev eno1 default via 10.1.0.98 1. Re-establish the "ring" on ens1 quickly : (from scratch) ip link set up enp9s0 ip addr add 10.2.0.x/16 dev enp9s0 ip route change 10.2.0.0/16 via 10.2.0.neighbor Also make sure that 10.1.0.98 is the first nameserver in your /etc/resolv.conf 2. Make sure you've enabled your machine as a router: echo 1 > /proc/sys/net/ipv4/ip_forward 3. Enable your host's web server: service httpd start. Your secure web server runs on TCP server port 443. ************************ 4. Now use iptables to configure your packet filter chains to satisfy the following restrictions (all of them together!). Use iptables-save (see man page) to save your firewall rules into the file /root/myrules. I'll be looking for this file. You can restore your firewall from this file with the iptables-restore command. You may also want to create a script to execute your rules. Read and think carefully, often a rule must be inserted into both the INPUT and FORWARD chains because you want to protect yourself as well as the people that you're a router for. Remember that the order of the rules matter. Be sure to use the -i/-o options wherever possible: these are the options that let you determine the physical origin/destination of packets. ************************************************************************** For each part below, write down both the iptables rules you used AND what you did to TEST if it works. ************************************************************************** By default, your system is "wide open", with the following conditions: A1. Block all icmp packets from 10.2.0.0/16 Block all icmp packets from 10.1.0.3 (thincrust) (but don't block'em from anywhere else!) A2. Block all incoming UDP packets to your host on port 514 (this is the remote shell port, which allows a remote host to execute a command on your machine. It's not encrypted, which is why it's been replaced by ssh). B. Only allow your host to route packets from 10.0.0.0/8 to other hosts on 10.0.0.0/8. That is, do not route ip packets that don't have 10.x.y.z as their destination ip, or packets that didn't originate from the secret network. Note that 10.0.0.0/8 includes both the 10.1 and 10.2 subnets C. Do not allow 10.1.0.3 (thincrust) to connect to your web server. It is rumored that this ip is used by a really nasty hacker. Use the REJECT instead of the DROP target, so you'll get a confirmation that the connection was refused. Warning: the nasty hacker is reportedly capable of trying to spoof you! C2. Use the -m connlimit module to restrict simultaneous connections to your web server from the same ip source address to be at most 2. This option was added to the original iptables: read about it under the link "iptables man page with new extensions." D. In 1988 a famous internet virus originated from Cornell University that used the Unix "finger" utility to break into systems. Disallow finger from anywhere except localhost. Also, don't route any finger packets. (hint: look in /etc/services for port number of finger). The finger program uses TCP. E. You are either on the subnet 10.1.0.0/29 or 10.1.0.8/29. Do not allow any host from the OTHER subnet to ssh into you. Get someone on the other subnet to test your firewall. Make sure you don't end up disabling yourself. (ha ha ha ha - that's me laughing at you because you're trapped inside your own firewall). F. Don't let anyone spoof you by pretending to be localhost (127.0.0.0/8). Localhost packets should only come in from the virtual "lo" interface. This is another reason to use the -i option whenever possible. G. Do not allow, and do not route, any packets that tries to use any host other than 10.1.0.98 or 167.206.112.138 as their DNS nameserver. The DNS server listens for requests on udp port 53. H. Log all connections to your web server, including illegal attempts. You can check logged connections using "dmesg" or by observing changes in the file /var/log/kern.log with the command tail -f /var/log/kern.log (may also find in syslog file) Be aware of how logging works: a packet that matches a -j LOG rule will still be checked against subsequent rules in the chain. Use the --log-prefix option to specify a special string to include in the log. Please be careful: you only want to log the packets that tries to initiate a connection. Logging EVERY packet could eventually overload your system. TCP initial packets can be detected with --syn (equivalent to --tcp-flags FIN,ACT,RST,SYN SYN) or by using -m conntrack --ctstate NEW (obsoletes -m state --state NEW) I. The pattern -p tcp --syn matches all TCP initiation packets. Log all such OUTGOING --syn packets from your host to destinations other than 10.0.0.0/8 EXCEPT for www (tcp dest-port 80) connections. That is, log all attempts to connect to an external tcp server unless it's a www server. J. thincrust (10.1.0.3) is going to try to get to you through some router. What does this mean? It means that you'll get a packet with -s 10.1.0.3, but whose mac address is the address of the router. thincrust should have mac source address 00:e0:4c:68:76:1f (10.1 network) or 00:e0:4c:68:76:20 (10.2 network) - so if you get a packet from thincrust that doesn't have this address, it must have been routed through someone else (thincrust can change its own mac address but not that of a router, presumably). Make sure you understand what I just said, and prevent this from happening. Can you find out who's routing packets to you? K. When a packet is fragmented, only the first fragment contains the tcp/udp/icmp header underneath the ip header, subsequent fragments will only contain the ip header. Nasty hackers can easily flood your host by pinging you with huge packets (this is called a "ping flood attack"). From your previous lab experiment, you should know that the length field in the ip header of the first fragment is only for that fragment, and not the entire ip packet. If a ping is meant for your host, the entire ip packet will be reassembled before it is examined by the INPUT chain, but NOT SO for fragments that are being routed through you. Using iptables, devise a way to protect your network from ping flood attacks. Note that you still need to accept normal pings that should not swamp you. L. At an appropriate time, you will be asked to examine your /var/log/kern.log file and answer a few questions. So stay tuned. NOW PLEASE THINK! Just because there are X conditions above doesn't necessarily mean you'll need exactly X iptables rules. You MUST make sure that your firewall isn't more restrictive than it needs to be. -------------------------------------------------------------------------- PART II: Written Exercise (please type) THIS PART MUST BE COMPLETED INDIVIDUALLY 1. For taking CSC175 and doing everything the prof expected you to, you've been promoted to a network administrator. Assume you are maintaining a Linux router for two small subnets, 10.5.2.0/25 and 10.5.2.128/25, which together form the "super subnet" 10.5.2.0/24. You are part of the larger site 10.5.0.0/16. Assume that the router has the following routing table: 127.0.0.0/8 dev lo 10.5.2.0/25 dev eth0 10.5.2.128/25 dev eth1 10.5.1.0/24 dev eth2 0.0.0.0/0 via 10.5.1.1 Furthermore, there's a web server on 10.5.3.10, port 80. The official DNS servers for the site are on 10.5.3.12 and 10.5.3.13. The official IMAP (email) server is at 10.5.1.14. The administrators of 10.5.0.0/16 are paranoid and they'll go nuts if they find anybody else running other such servers on their network! Write iptables rules to effect the following restrictions *simultaneously*. Use iptables -I (as opposed to -A) to insert the rules in precise positions. YOU ARE ALSO REQUIRED TO CREATE A NEW CHAIN FOR THIS ASSIGNMENT Assume initially the default policy of each of the three built-in chains is ACCEPT, and that each chain is empty. Remember: all conditions must be satisfied simultaneously: 1. Your router is only allowed to route packets *into* 10.5.2.0/24 (which includes both /25 subnets). That is, if a packet comes into eth2 but is not destined for 10.5.2.0/24, you shouldn't route it. Do not use a rule that's more restrictive than it needs to be! Packets from inside 10.5.2.0/24 still needs to get out, because they're using you as their default gateway! 2. Do not route any gre tunnel packets (ip protocol number 47), because we can't look at the packet underneath. 3. no icmp responses are allowed from 10.5.2.128/25 4. No machine can use a DNS server that's not one of the official ones. Furthermore, if a DNS response is found to come from an unofficial server, you should LOG the packet. 5. Connection to any imap or pop3 server other than the official one should be blocked (look in /etc/services for port numbers). These protocols use tcp. 6. You want to run a local web server on 10.5.2.130, but you fear the wrath of the higher-up admins if they found out. This server should only be allowed to serve other hosts on your two subnets (10.5.2.0/24). http is built on top of tcp. 7. You are responsible for limiting the rate of connections to the official web server (10.5.3.10) from your two subnets to 1 every second with a limit-burst of 3. If there are too many connections, they should be dropped. If you don't do this right and the web server crashes, you'll be reassigned to answering phones at the help desk from clueless end users. 8. Your router is also running a DHCP server (uses udp, port 67) that assigns IP addresses to hosts. However, you should only service requests from the two subnets of 10.5.2.0/24. 9. Finally, don't let anyone ssh into your router, except 147.4.150.54. Be careful. Read the numbers. There are a couple of subtle things to watchout for, such as which chain you put the rules in. On paper, mark clearly which condition each rule is associated with. Please submit a typed assignment.