Comment goes here
You should log in and post some comments! The link is up there in the toolbar. Go nuts!
 

General tips for working with iptables

Need to make some changes to your iptables rules running on one of your servers? Don't worry. While iptables can be a bit risky in that it'll let you add rules without checking your logic there are a few steps that can make your life much easier. Also, as just a general tip: Whenever you are working with modifying network access to a machine or just managing a server in general it pays to have local and/or remote console access to the machine.

  • Use iptables-save and iptables-restore to load your rules unless you are using some custom shell script to load your iptables rules. Even if you are using a custom script to manage your iptables rules knowing and using these commands can be very useful.
  • Before tinkering with rules always find out where the current rule set in use is saved or save a copy yourself. It gives you a safe place to fall back to if your new rules crash and burn in a fiery ball of death.
  • To save out the current rules just run 
    iptables-save > {filename}
     and tada! You now have a safe restore point should your editing go awry.
  • Edit a copy of the save file. This gives you a point of reference if you end up in the unenviable position of trying to figure out why your rule changes didn’t work as expected. diff {saved rules} {new rules} is also your friend when trying to spot what went wrong with your edits. Aren't you glad you have a copy of the new and the original rules?
  • Load your new rule set with 
    iptables-restore < {filename}
     If things go belly up don't lose your cool. Just hit the remote console (I did tell you to make sure you have console access right?) and use iptables-restore to reload the saved copy of your known good rule set. You DID save a copy of the previous rule set like you were supposed to right?

    • Other things to remember:
  • If iptables-restore doesn't like your syntax it'll let you know without implementing the changes and breaking the current rules. See why this is better than hacking at the live rules?
  • Always remember to check the default behavior for your rule chains! This is important because a default DENY (different than having a deny statement as your last rule) will block all traffic through a chain if you run an 
    iptables -F
     to flush all the active rules leaving you without access to your machine and forced to use the console in shame.
  • When adding rules order is VERY important. If you block or allow access to something and then later reverse your decision it won't matter. First come, first served. Everyone else gets sent home hungry.
  • When troubleshooting your rules, or in general if it won't impact performance on your machine, it is usually a good idea to have a rule for logging rejected packets such as 
    -A INPUT -j LOG --log-level 6
     so that you can see when your rules are denying traffic by checking /var/log/messages or wherever your OS flavor prefers to dump iptables info.
  • ALWAYS save your rules out to wherever the OS expects to load rules from on boot if you want your current rule changes to survive a reboot. Iptables isn't magic. If your rules aren't in the start up scripts they won't get loaded properly at boot time.

    • If you have improvements, corrections or suggestions of what has worked well for you please share.