Changes

==INVESTIGATION 1: IPTABLES RULES AS A SCRIPT== As an alternative to editing the configuration file, you can place iptables commands in a script to be executed any time the machine boots (or any other time to you need to refresh your rules). On your VM1: # First, issue an ''iptables command'' to set the policy to disable '''all forwarding traffic''', and remove the rule that is rejecting it.# Next, set the default policy to drop '''all inbound traffic''', and remove the rule that is rejecting traffic.# Issue an iptables command to list rules for verification.<br /><br />The remaining tasks will relate to that same '''inbound''' traffic chain.<br /><br /># Issue an ''iptables command'' to delete the default ssh rule.# Issue an ''iptables command'' to add a rule that allows ssh traffic (i.e. tcp packets with destination port 22) that originates from any machine within your virtual network.# Issue an ''iptables command'' to delete the default icmp rule.# Issue an ''iptables command'' to allow icmp traffic from addresses in your virtual network.# Test that your machines can still use ping and ssh to communicate with each other.# Store the commands you used to modify the iptables into a shell script called: '''firewall_restore.bash'''# Set up a cron entry so that your rules are automatically applied every time the machine boots.# Now copy the script to your other VMs and make it apply to them when they boot as well.# Reboot each machine and make sure this works before you move on. ==INVESTIGATION 2: IPTABLES TROUBLESHOOTING CHECKLIST==

<tr> <th>3</th><td>'''Verify Network Connectivity by Deleting iptables Rules'''</td><td>If you have no idea what's going on and need to confirm that you're still sane - clear all the iptables rules and check your configuration then. Keep in mind that the '''iptables -F''' command will delete all your rules but will not set the deafult policies to ACCEPT. This will tell you for sure whether your problem was (or was not) caused by iptables.<br><br>If you do this - have a ready way to restore the rules you just deleted. Restarting the iptables service is usually a good start and a '''shell script''' to add your custom rules is a reasonable next step.</td></tr><tr> <th>4</th><td>'''List your iptables Rules &amp; Perform a "Walk-Thru"'''</td><td>For many decades, when troubleshooting programs that don't run properly, programmers will resort to reading their "source-code" line-by-line and pretend they are the computer to perform the operation. The programmer "walks-through" the code to force them to think like a computer in order to spot and fix subtle problems.<br><br>Therefore, you can follow a packet's path as you understand it should follow. Keep in mind [http://zenit.senecac.on.ca/wiki/index.php/OPS335_Lab_2#How_Firewalls_.28iptables.29_Relate_to_the_Labs_in_this_Course the diagram from the lecture last week]. What chain applies first on which machine? What's the first rule that matches the packet? What happens if no rules match the packet?<br><br>Don't forget that even if you're tracing the path of outgoing traffic - the INPUT chain on your mahchine machine still applies (for the response that comes back to your request).</td></tr><tr> <th>4</th><td>'''Use the log target to list unexpected traffic'''</td><td>Add a final rule to your input chain to log all traffic. Any traffic you are allowing will have already been accepted and will not reach this rule, so you will start a log of all the packets you are not allowing. Observing the logs while you attempt to use the service that is not being allowed will show you the type of traffic you need to allow.</td></tr><tr> <th>5</th><td>'''Verify Network Connectivity by Deleting iptables Rules'''</td><td>As a last resort, if you have no idea what's going on and need to confirm that you're still sane - clear all the iptables rules and check your configuration then. Keep in mind that the '''iptables -F''' command will delete all your rules but will not set the default policies to ACCEPT. This will tell you for sure whether your problem was (or was not) caused by iptables.<br><br>If you do this - have a ready way to restore the rules you just deleted. Restarting the iptables service is usually a good start and a '''shell script''' to add your custom rules is a reasonable next step.</td></tr></table>

'''Record the troubleshooting checklist for INVESTIGATION 1 in your OPS335 lab log-book'''

==INVESTIGATION 23: HANDS-ON IPTABLES TROUBLESHOOTING==

'''Record steps, commands, and your observations in INVESTIGATION 2 3 in your OPS335 lab log-book'''

#Without booking looking at the table above, list the 4 tips for troubleshooting iptables (in order).<br><br>