Changes

==PACKET FILTERING USING IPTABLES and Firewalld==In this lab you will learn how to use iptables and firewalld to build and test a simple Linux firewall on your servers.

You're supposed to find and use documentation to learn how to complete these tasks==OVERVIEW & PREPARATION==In this lab, 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 will learn this yourself. Learning how to find relevant documentation and understand it is just as important as the exact commands youuse '''iptables''' to build a simple '''Linux firewall'''ll finally useon your servers.

Prior You were exposed to beginning this lab verify network connectivity between iptables in your host OPS235 course. You should refer to those notes or find and your VMsuse documentation to learn how to complete these tasks.* Boot up You can also ask your host.* Login with your LearnID.* Find out professor or lab assistant during the MAC address of the virtual network device virbr0 and the IP address assigned to itlab for help when using iptables. Record Some basic iptables commands are provided in this information on your lab log book.* Start your VMs.* On the VMs** Login with your LearnID for reference, but it is also essential that you know how to your VM obtain help (man pages and use "su -" online) in order to become root.** Find out the MAC address of the NIC (usually eth0 or ens3) and the IP address assigned to it. Record this information on your lab log bookself-reliant.

*On {{Admon/important |firewalld|In this lab we will be using ''iptables'', '''<u>not</u>''' ''firewalld''. Although both systems (Host and VMs)** Run can be used at the command "ip neighbour show"same time, extract relevant information from that would be too advantaged that this point of learning Linux network administration.<br>In the outputs first labs, '''Prep for labs''', you should have disabled and record them on your lab log book. Indicate clearly the system on which the information was obtained.** For a brief summary of the output format view stopped the firewalld service: [http://linux-ipzenit.senecac.on.netca/wiki/glindex.php/ipOPS335_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 -cref/node61L''' and noting a high volume of unexpected output (i.e. "a strange result").html online documentation]}}

== IPTABLES =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.* Start with [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).  ===How Firewalls (iptables) Relate to the default settingsLabs in this Course=== We will use an example of setting up a firewall to secure a web server. When you install Iptables You will be installing, configuring, protecting, and maintaining a web-server of one of your VMs in CentOS it already has some rules predefineda later lab.   '''The instructions diagram displayed below assume you have those default shows how iptables can be used with a web-server:'''  [[Image:iptables.png]]  '''There are some important things to be aware of in terms of this 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. :* Add one rule at '''Outbound traffic from a time using server (in our case the appropriate iptables command 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 <u>connections</u>''' (what younormally think of as '''<u>inbound traffic</u>'''ll figure out yourself): the web server receives a '''new incoming connection'''.::# '''Incoming <u>data</u> 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. Then check It is safe to assume that '''a connection that was allowed to be established should be allowed to make sure receive a response'''. This is accomplished with the following '''INPUT chain rule''' that should be there by default on your command worked 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'''::# Since the '''RELATED,ESTABLISHED''' rule already exists, we are only concerned about controlling the '''incoming traffic on the server''', which in our example, the '''chain is: INPUT''', the '''protocol is: tcp''', and the '''destination is: port 80'''. :* Basically all other services that you learn to install, configure, and maintain will required the same knowledge just discussed.  ===Critical iptables Elements=== This may seem like another task to perform, but it is an essential task! You need to "become one" with basic iptables and focus on these important elements on this section, since you will be troubleshooting MANY connection issues with MANY VMs for labs and assignments! You need to become comfortable when usingiptables to not only set policy, but troubleshoot and fix mistakes when you set your firewall policies! ''... the more you practice and get comfortable with iptables, the quicker you will be able to isolate and fix connection issues...'' '''We don't expect you to become firewall experts, but there are some basics you need to become familiar for this and future labs:'''* 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 <codeu>'''practice'''</u>.  '''Record steps, commands, and your observations from this section in your OPS335 lab log-book'''  ==INVESTIGATION 1: PREPARATION &amp; GETTING TO KNOW IPTABLES COMMANDS== === Confirming Existing Network Connections === Before proceeding with iptables , we should first verify that your host machine and vms can connect with one another. We can also take the opportunity to record some observations which could be used for future labs.<br><br>'''Perform the Following Steps:''' # Find the ''MAC address'' of the virtual network device on the host and the ''IP address'' assigned to it. Record this information in your lab log book.# Launch all three of your VMs.# For 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.# Change to your host machine, open a terminal window, and perform the following connectivity tests for each vm:<br><br><source lang="bash">ping -Lc 1 [ip-of-vm]ssh [ip-of-vm]</codesource> or  ===Default vs Updated Firewall Rules for VMs=== You should have learned in OPS235 how to view existing iptables rules with the command: iptables -L.Although you may assume that this listing of rules should be empty, they may not be!<codebr>There might be default rules that already exist, or that exist when the firewall is reset to default (i.e. iptables -F). In fact, several rules were '''automatically added''' to your chains because you are using a '''virtual network'''. As an exercise, we will determine which of those rules when running a virtual network were added. '''Perform the Following Steps:'''# Run '''iptables -L ''' but redirect the output to a text file called '''before.txt''' (you will be using this file later).# Shutdown all of your VMs.# Stop the '''libvirtd''' service# Restart the '''iptables''' service# Re-issue '''iptables -nL''' commands making certain to redirect output to a second file ('''after.txt'''). This should provide a listing of the new state of your firewall settings.# You now should have two text files representing the <u>before</u> and <u>after</codeu> states of your firewall. Compare differences between these two files using the diff command (You should have used this tool in '''ULI101''').#Run '''diff -u before.txt after.txt''' and figure out how to read the output.<br> if you<br>'''TIP:'''d like You can also install a graphical tool that makes it much easier to see numeric port numbersdifferences: '''kompare before.txt after.txt'''<br><br># You can use these tools to compare any two text files, they often come in handy. Note in your lab logbook the iptables rules that were added automatically by the '''libvirtd''' service. === Simple Rule Changes === We will run some iptables commands to practice and get a basic understanding of how to set rules. # First, issue an iptables command to set the policy to disable all '''inbound''' traffic. Issue the iptables command to list rules for verification. The remaining tasks will relate to that same '''inbound''' traffic chain.# Issue an iptables command to delete the default ssh rule, and issue another iptables command to verify.** If possible - test # Issue an iptables command to insert the SSH rule in the beginning instead of appending to the bottom. Issue a command to verify, then delete that rule (by number), and verify that it with was deleted.# Issue an iptables command to append the SSH rule to the end of that chain, verify, delete that same rule, and verify.# Issue an application (eiptables command to delete the related,established rule. Test your network connectivity between your hosts and vms.gWhat happened? # Issue an iptables command to restore your firewall to its default settings. if SSH access is disabled/enabled  '''Record steps, commands, and your observations in INVESTIGATION 1 in your OPS335 lab log- test book'''  ==INVESTIGATION 2: CREATING CUSTOMIZED CHAINS &amp; USING SHELL SCRIPTS== In this investigation, we will use shell scripting to help automate our firewalls, and create our own customized chains for packet filtering. ===Best Practices=== #'''Always start with ssh)the default iptables settings'''::*When you install Iptables in CentOS it already has some rules predefined.:* Save You will always get the default rules if you restart the iptables service.  <ol><li value="2">'''Place your rule in iptables commands (i.e. Rules) within a bash script ''' (.sh filebash) so you don't lose it and can rerun it easily.<br><br></li><li>'''If you are disconnected from a VM:''' Some of the traffic between your host and VirtManager goes through IPtables.<br> 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'''.</li></ol>*  <ol><li value="4">'''If your command didn't work - the easiest thing to do is:** '''<ul><li>'''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).** </li><li>Then '''run your script with all the working iptables commands ''' that you already finished.** Go back </li><li>'''Return to writing work on creating the rule that didn't work'''.</li></ul></li></ol>  ===Creating Customized Chains=== You have the ability to create your own customized chains - you can actually name them!

'''On your Host build a custom firewall by performing the following steps:'''#Remove the rules in your input INPUT chain that are allowing all icmp and ssh traffic.#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.#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 virbr0 virtual interface from 192.168.X.0/24 (i.e. your internal network).#Add rules to the end of the MYSSH chain to drops 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 in the filter table.#Add a rule to the beginning of the INPUT chain of the filter table to send ICMP ping packets to your MYICMP chain.#find 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 virbr0 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 IP address of your partner's machine.

*Save Once you're happy with how your firewall works - make a backup of the original default rules and list them:<source lang='bash'>cp /etc/sysconfig/iptables /etc/sysconfig/iptables.original</source>*start And then overwrite the defaults with the libvirtd service.**Note how this adds a number current state of rules to your tables. In the future, if you save your firewall:<source lang='bash'>/usr/libexec/iptables/iptables rules with these rules in your tables, you will notice them start to duplicate.init save</source>

==Building a Firewall With Firewalld on VMs==On your VMs we will build a firewall using the newer standard firewalld.*Start VM1'''Record steps, become rootcommands, 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 firewallobservations in INVESTIGATION 2 in your OPS335 lab log-cmd rich rules to make the following changes:**Block all ssh attempts from your hostbook'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.

== 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.

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 and firewalld. Scan each You will be building on these rules for the rest of your machines with nmap. Observe how the results differ depending on which machine you scanned fromcourse.

{{Admon/importanttip|Time for a new backup!|Once have successfully completed this lab, make a new backup of your virtual machines.}}