|
|
| (58 intermediate revisions by one other user not shown) |
| Line 1: |
Line 1: |
| − | [[Category:OPS335]][[Category:OPS335 Labs]]
| + | #REDIRECT [[OPS335_Lab_2]] |
| − | = PACKET FILTERING USING IPTABLES =
| |
| − | | |
| − | ==OVERVIEW & PREPARATION==
| |
| − | In this lab, you will learn how to use '''iptables''' to build a simple '''Linux firewall''' on your servers.
| |
| − | | |
| − | iptables is a <u>very complex</u> topic. Fortunately, you are not required to become an "iptables expert", but by the end of the course, you should be able to use iptables to properly secure your servers.
| |
| − | | |
| − | You were exposed to iptables in your OPS235 course. You should refer to those notes or find and use documentation to learn how to complete these tasks. You can also ask your professor or lab assistant during the lab for help when using iptables. Some basic iptables commands are provided in this lab for reference, but it is also essential that you know how to obtain help (man pages and online) in order to become self-reliant.
| |
| − | | |
| − | | |
| − | {{Admon/important |firewalld|In this lab we will be using ''iptables'', '''<u>not</u>''' ''firewalld''. Although both can be used at the same time, that would be too advantaged that this point of learning Linux network administration.<br><br>In the first labs, '''Prep for labs''', you should have disabled and stopped the firewalld service: [http://zenit.senecac.on.ca/wiki/index.php/OPS335_Installation_Lab#Using_iptables Prep for Labs].<br><br>You can also check the status of the firewalld service by issuing the '''systemctl''' command. You can also check if the firewalld service is running by issuing '''iptables -L''' and noting a high volume of unexpected output (i.e. "a strange result").
| |
| − | }}
| |
| − | | |
| − | | |
| − | ===iptables Resources===
| |
| − | | |
| − | | |
| − | Some documentation to get started with (you'll need to find more):
| |
| − | * [https://prezi.com/akyqt4h40oel/iptables-packet-filtering/ Week 3 Notes] Recommended to review and understand prior to performing this lab.
| |
| − | * [https://en.wikipedia.org/wiki/Iptables#Overview Overview] A excellent concise overview of iptables (ignore diagram).
| |
| − | * [https://wiki.centos.org/HowTos/Network/IPTables CentOS Wiki] Listing of basic commands (not all required to know).
| |
| − | | |
| − | | |
| − | ===The Minimum Essentials of iptables===
| |
| − | | |
| − | We will use an example of setting up a firewall to secure a web server. You will be installing, configuring, protecting, and maintaining a web-server of one of your VMs in a later lab.
| |
| − | | |
| − | | |
| − | '''The diagram displayed below basically applies to every service that you learn how to work with in this course:
| |
| − | | |
| − | | |
| − | [[Image:iptables.png]] | |
| − | | |
| − | | |
| − | '''There are some important point to note regarding iptables from the above diagram:'''
| |
| − | | |
| − | :*There are '''<u>two sets</u> of IPtables rules (chains) that apply:''' '''OUTPUT/INPUT on the client''' and '''INPUT/OUTPUT on the server'''.<br>It is important to think about from the perspective from the client as well as the server.
| |
| − | | |
| − | :* '''Outbound traffic''' from a server (like a response to the Firefox web-browser from the web-server) '''is rarely blocked <u>unless</u> there is a security policy to <u>prevent</u> some kind of traffic'''.<br>Even in that case, that security policy is usually performed on a router (this is a topic which will be discussed later in this course).
| |
| − | | |
| − | :* '''Inbound traffic is of two distinct types'''. Our diagram shows:
| |
| − | ::# '''New incoming connections''' (what you normally think of as '''inbound traffic'''): the web server receives a new incoming connection.
| |
| − | ::# '''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 is safe to assume 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:<br>
| |
| − | ::::<pre>ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED</pre>
| |
| − | | |
| − | :* Rules are applied to: '''chains''' (e.g. ''input/output''), '''protocols''' (e.g. ''tcp/udp/icmp''), and '''ports''' (e.g. ''22, 80, 443'').
| |
| − | ::# For the request the source port (sport) is 40112 and the destination port (dport) is 80
| |
| − | ::# 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 on the server, which in our example on the server is INPUT TCP destination port 80.
| |
| − | | |
| − | | |
| − | === What you need to learn ===
| |
| − | | |
| − | We don't expect you to become firewall experts but there are some basics you need to become familiar with this week:
| |
| − | * What is a '''chain'''
| |
| − | * '''Which chain''' applies to which traffic
| |
| − | * What's the '''default action''' for a chain and when that applies
| |
| − | * What '''order the rules are executed in'''
| |
| − | * '''Reading and/or creating a rule''' for a specific service. That includes a basic understanding of:
| |
| − | ** '''Ports'''
| |
| − | ** '''Protocols'''
| |
| − | | |
| − | The best way to learn that is to practice.
| |
| − | | |
| − | '''Record steps, commands, and your observations from this section in your OPS335 lab log-book'''
| |
| − | | |
| − | | |
| − | ==INVESTIGATION 1: IPTABLES BASICS==
| |
| − | | |
| − | === Setup ===
| |
| − | | |
| − | Prior to beginning this lab verify network connectivity between your host and your VMs and record some numbers:
| |
| − | # 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.
| |
| − | # Start your VMs.
| |
| − | # 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.
| |
| − | # Back on your host open a terminal window and perform the following connectivity tests to each vm:
| |
| − | #* ping -c 1 [ip-of-vm]
| |
| − | #* ssh [ip-of-vm]
| |
| − | | |
| − | === Performing 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:
| |
| − | # Run '''iptables -L''' and redirect the output to a text file, so you can refer to it later.
| |
| − | # Shutdown your VMs
| |
| − | # Stop the libvirtd service
| |
| − | # Restart the iptables service
| |
| − | # Rerun '''iptables -L''' to get a listing of the new state of the firewall and redirect the output to a second text file.
| |
| − | # 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
| |
| − | # 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.
| |
| − | | |
| − | # Disable all inbound traffic...
| |
| − | # Delete the default ssh rule
| |
| − | # Insert the SSH rule in the beginning, delete it
| |
| − | # Append the SSH rule to the end, delete it
| |
| − | # Delete related,established rule, try to do anything
| |
| − | # Restore defaults
| |
| − | | |
| − | '''Record steps, commands, and your observations in INVESTIGATION 1 in your OPS335 lab log-book'''
| |
| − | | |
| − | ==INVESTIGATION 2: SETTING FIREWALL POLICIES ON YOUR VMs==
| |
| − | | |
| − | = 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.
| |
| − | {{Admon/important |Disconnected from VMs|Some of the traffic between your host and VirtManager goes through IPtables. When you mess with IPtables rules on the host - you may end up losing the console connection to the virtual machines. Don't worry, they're still running and you can still use them.}}
| |
| − | * 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 (you can also do that at the beginning of your shell script).
| |
| − | ** Then run your script with all the working iptables commands that you already finished.
| |
| − | ** Go back to writing the rule that didn't work.
| |
| − | | |
| − | Perform the following steps:
| |
| − | | |
| − | # Remove the rules in your INPUT chain that are allowing all icmp and ssh traffic.
| |
| − | # Change the default policy on the INPUT and FORWARD chains in the filter table to DROP.
| |
| − | # Remove the rules from the INPUT and FORWARD chains that are rejecting all traffic (we are now better protected by the default policy).
| |
| − | # Create a new chain named MYSSH in the filter table.
| |
| − | # 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.
| |
| − | #* Use --jump not --goto for that.
| |
| − | # Add a rule to your MYSSH chain to accpept all traffic on your virtual interface from 192.168.X.0/24 (i.e. your internal network).
| |
| − | # Add rules to the end of the MYSSH chain to drop all remaining ssh connections, but to log these denied packets with log level 'info' and log prefix "DENIED BY MYSSH" before doing so.
| |
| − | # Make a new chain named MYICMP.
| |
| − | # Add a rule to the beginning of the INPUT chain to send ICMP ping packets to your MYICMP chain.
| |
| − | # Find a partner and get the ipaddress and MAC address of their external facing interface. If you don't have a partner - use a virtual machine.
| |
| − | # Add a rule to your MYICMP chain that allows ICMP packets coming in on your virtual interface from 192.168.X.0/24 (i.e. your internal network).
| |
| − | # Add a rule to your MYICMP chain that denies ICMP pings originating with MAC address of your partner's machine.
| |
| − | # Add a rule to your MYICMP chain that denies ICMP pings originating with IP address of your partner's machine.
| |
| − | | |
| − | Once you're happy with how your firewall works - make a backup of the original default rules:
| |
| − | <source lang='bash'>cp /etc/sysconfig/iptables /etc/sysconfig/iptables.original</source>
| |
| − | And then overwrite the defaults with the current state of the firewall:
| |
| − | <source lang='bash'>/usr/libexec/iptables/iptables.init save</source>
| |
| − | | |
| − | '''Record steps, commands, and your observations in INVESTIGATION 2 in your OPS335 lab log-book'''
| |
| − | | |
| − | | |
| − | = Completing the Lab =
| |
| − | | |
| − | Upon completion of this lab each of your machines has a firewall protecting them from unexpected traffic. You should now have a basic understanding of the commands necessary to modify firewalls using iptables. You will be building on these rules for the rest of the course.
| |
| − | | |
| − | Record the URLs of the websites you've used to figure out how to do the work.
| |
| − | | |
| − | Exploration questions
| |
| − | #View your firewall rules using the output of the 'iptables -L -n -v' command. Also save the output to a text file.
| |
| − | #How could you display the log records generated by your invalid ssh attempts without including any unrelated entries.
| |
| − | #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?
| |
| − | #Which rule in the MYICMP chain is actually responsible for denying icmp packets from your partner? Why?
| |
| − | #Which optional module could be used to work with packets based on whether they are new connections or not?
| |
| − | | |
| − | {{Admon/tip|Time for a new backup!|Once have successfully completed this lab, make a new backup of your virtual machines.}}
| |
