OPS335 Lab 2 draft

IPTABLES

In this lab you will learn how to use iptables to build a simple Linux firewall on your servers.

You're supposed to find and use documentation to learn how to complete these tasks, and of course you can ask your prof or lab assistant for help. Some introductory commands are provided to help you get started but the important part is that you learn this yourself. Learning how to find relevant documentation and understand it is just as important as the exact commands you'll finally use.

Firewalld

Remember that in this lab we're learning iptables, not firewalld. You can use both at the same time but that's too advanced for us at this point. Before you start doing work on these labs you need to make sure you're using iptables and not firewalld. To determine what you're currently using you can run a systemctl command or two. Also you can see that you're using firewalld if you run iptables -L and see lots and lots of unexpected output.

At this point you'll have iptables services on your host and firewalld on your VMs - look at the state of iptables on both to learn how to see the difference. After you've figured that out - replace firewalld with iptables services (the steps are in the OPS335_Installation_Lab).

Overview

Some documentation to get started with (you'll need to find more):

• Overview section on Wikipedia is a good (short) overview of the system. You don't need to understand that diagram though.
• CentOS Wiki has some basic commands, you won't need to use all of them for the work below.

Iptables is a very complex topic, but if we don't try to do too much we can get started with it with what we know now and by the end of the course you'll at least be able to say you can use iptables, even if you're not an expert at it. To give you a taste of the complexity: see what comes up when you search for simple iptables diagram. So we'll make our own here:

This diagram applies to pretty much every service. Note that:

• In this diagram there are two sets of IPtables rules: OUTPUT/INPUT on the client and INPUT/OUTPUT on the server.
• Outbound traffic (Firefox connecting to the web server) is rarely blocked unless there is a business policy to prevent some kind of traffic, and even then it's usually done on a router (that's a topic for later).
• Inbound traffic is of two distinct types, in our diagram we have both:
  1. New incoming connections (what you normally think of as inbound traffic): the web server receives a new incoming connection.
  2. Incoming data that's a response to a request: the web page that the server sent back in the diagram above.
• We normally don't want to do anything special for the response. It's a safe assumption that a connection that was allowed to be established should be allowed to receive a response. This is accomplished with the following INPUT chain rule that should be there by default on your machines:

ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED

• Rules are applied to chains (e.g. input/output), protocols (e.g. tcp/udp/icmp), and ports (e.g. 22, 80, 443).
  1. For the request the source port (sport) is 40112 and the destination port (dport) is 80
  2. For the response the source port is 80 and the destination port is 40112
• Because we have the RELATED,ESTABLISHED rule we only care about controlling the incoming traffic, which in our example on the server is INPUT TCP destination port 80.

Setup

Prior to beginning this lab verify network connectivity between your host and your VMs.

1. Find the MAC address of the virtual network device on the host and the IP address assigned to it. Record this information on your lab log book.
2. Start your VMs.
3. On each VM:
   • Login as root.
   • Find the MAC address of the virtual NIC and the IP address assigned to it. Record this information on your lab log book.
4. Back on your host open a terminal window and perform the following connectivity tests to each vm:
   • ping -c 2 [ip-of-vm]
   • ssh [LearnID]@[ip-of-vm]

Automatic firewall updates

To preempt some confusion let's start with this: several rules are automatically added for you because of the virtual network. As an exercise we'll figure out what those are exactly:

1. Run iptables -L and redirect the output to a text file, so you can refer to it later.
2. Shutdown your VMs
3. Stop the libvirtd service
4. Restart the iptables service
5. Rerun iptables -L to get a listing of the new state of the firewall and redirect the output to a second text file.
6. Now you have two text files representing the before and after states of your firewall. You can compare the files visually but it's often easier to use a diff tool:
   • The command-line tool diff takes some time to get used to but you'll get used to it eventually, it's used a lot in the industry. Run diff -u before.txt after.txt and figure out how to read the output.
   • You can also install a graphical tool that makes it much easier to see differences: kompare before.txt after.txt
7. You can use these tools to compare any two text files, they often come in handy. For the purpose of this lab notice that some iptables rules are added automatically by the libvirtd service.

Simple rule changes

We'll run some commands to practice and get a basic understanding of how the rules work.

1. Disable all inbound traffic...
2. Delete the default ssh rule
3. Insert the SSH rule in the beginning, delete it
4. Append the SSH rule to the end, delete it
5. Delete related,established rule, try to do anything
6. Restore defaults

Your tasks

• Start with the default settings. When you install Iptables in CentOS it already has some rules predefined. You will get the default rules if you restart the iptables service.
• Save your rule in a bash script (.sh file) so you don't lose it and can rerun it easily.
• If your command didn't work - the easiest thing to do is:
  • Reload the default rules. You can do that by restarting the iptables service.
  • Then run your script with all the working iptables commands that you already finished.
  • Go back to writing the rule that didn't work.

On your Host build a custom firewall by performing the following steps:

1. Remove the rules in your input chain that are allowing all icmp and ssh traffic.
2. Add a rule to the INPUT chain of the filter table to allow all UDP traffic coming from port 53. i.e. source port is 53.
3. Change the default policy on the INPUT and FORWARD chains in the filter table to DROP.
4. Remove the rules from the INPUT and FORWARD chains that are rejecting all traffic (we are now better protected by the default policy).
5. Create a new chain named MYSSH in the filter table.
6. Add a rule to the beginning of the INPUT chain of your filter table that sends all ssh traffic (tcp packets with destination port 22) to your MYSSH chain.
7. Add a rule to your MYSSH chain to accpept all traffic on your virbr0 interface from 192.168.X.0/24 (i.e. your internal network).
8. Add rules to the end of the MYSSH chain to drops all remaining ssh connections, but to log these denied packets with log level 'info' and log prefix "DENIED BY MYSSH" before doing so.
9. Make a new chain named MYICMP in the filter table.
10. Add a rule to the beginning of the INPUT chain of the filter table to send ICMP ping packets to your MYICMP chain.
11. find a partner and get the ipaddress and MAC address of their external facing interface.
12. Add a rule to your MYICMP chain that allows ICMP packets coming in on your virbr0 interface from 192.168.X.0/24 (i.e. your internal network).
13. Add a rule to your MYICMP chain that denies ICMP pings originating with MAC address of your partner's machine.
14. Add a rule to your MYICMP chain that denies ICMP pings originating with ip address of your partner's machine.

• Save your rules and list them.
• start the libvirtd service.
  • Note how this adds a number of rules to your tables. In the future, if you save your iptables rules with these rules in your tables, you will notice them start to duplicate.

Building a Firewall With Firewalld on VMs

On your VMs we will build a firewall using the newer standard firewalld.

• Start VM1, become root, and make the following changes:
• Move your active interface into the zone 'work'.
• Remove all services except ssh from the work zone (effectively blocking all incoming traffic except ssh).
• Use the firewall-cmd rich rules to make the following changes:
  • Block all ssh attempts from your host's ip address, adding a log entry with the message 'DENIED BY MYSSH' every time it attempts to connect.
  • Block all pings expect for those that come from your internal network.
• Make sure your changes are permanent.
• Repeat these changes on your other VMs.

Testing your custom firewall

• On your host use nmap to scan your firewall on your VMs and observe the output.
  • If you don't have nmap on your host then install it. Install it on your VMs as well.
• Use ping and ssh between your host and VMs to verify your firewall is working properly. Be sure to check the log file on the host for your unsuccessful ssh attempts.
• Save your firewall rules.
• Turn the firewall on your VM off, then try scanning again. Note how the output is different.
  • Make sure you turn the firewall back on when you are done.
• Double check that the all VMs can still ping and SSH each other.

Completing the Lab

Upon completion of this lab each of your machines has a firewall protecting them from unexpected traffic. Reboot your machines and ensure that this protection remains in place after they are shut down. You will be building on these rules for the rest of the course.

You should now have a basic understanding of the commands necessary to modify firewalls using iptables and firewalld. Scan each of your machines with nmap. Observe how the results differ depending on which machine you scanned from.

Record the URLs of the websites you've used to figure out how to do the work.

Exploration questions

1. View your firewall rules using the output of the 'iptables -L -n -v' command. Also save the output to a text file.
2. How could you display the log records generated by your invalid ssh attempts without including any unrelated entries.
3. What iptables rule would you need to add to your firewall to allow a maximum of 3 concurrent ssh connections from your host to your VM1?
4. Which rule in the MYICMP chain is actually responsible for denying icmp packets from your partner? Why?
5. Which optional module could be used to work with packets based on whether they are new connections or not?

Time for a new backup!
Once have successfully completed this lab, make a new backup of your virtual machines.