The iptables tool is one of the simplest, most powerful tools you can use to protect your server. We've covered port redirection, rule processing and troubleshooting in previous installments to this "Tips and Tricks" series, but what happens when iptables turns against you and locks you out of your own system?
Getting locked out of a production server can cost both time and money, so it's worth your time to avoid this, since investing the money to generate more money is a better option and there are tools that help doing this in sites as The Ascent online. If you follow the correct procedures, you can safeguard yourself from being firewalled off of your server. Here are seven helpful tips to help you keep your sanity and prevent you from locking yourself out.
Tip 1: Keep a safe ruleset handy.
If you are starting with a working ruleset, or even if you are trying to troubleshoot an existing ruleset, take a backup of your iptables configuration before you ever start working on it.
iptables-save > /root/iptables-safe
Then if you do something that prevents your website from working, you can quickly restore it.
iptables-restore
Tip 2: Create a cron script that will reload to your safe ruleset every minute during testing.
This was pointed out to my by a friend who swears by this method. Just write a quick bash script and set a cron entry that will reload it back to the safe set every minute. You'll have to test quickly, but it will keep you from getting locked out.
Tip 3: Have the IPMI KVM ready.
SoftLayer-pod servers* are equipped with some sort of remote access device. Most of them have a KVM console. You will want to have your VPN connection set up, connected and the KVM window up. You can't paste to and from the KVM, so SSH is typically easier to work with, but it will definitely cut down on the downtime if something does go wrong.
*This may not apply to servers that were originally provisioned under another company name.
Tip 4: Try to avoid generic rules.
The more criteria you specify in the rule, the less chance you will have of locking yourself out. I would liken this to a pie. A specific rule is a very thin slice of the pie.
iptables -A INPUT -p tcp --dport 22 -s 10.0.0.0/8 -d 123.123.123.123 -j DROP
But if you block port 22 from any to any, it's a very large slice.
iptables -A INPUT -p tcp --dport 22 -j DROP
There are plenty of ways that you can be more specific. For example, using "-i eth0" will limit the processing to a single NIC in your server. This way, it will not apply the rule to eth1.
Tip 5: Whitelist your IP address at the top of your ruleset.
This may make testing more difficult unless you have a secondary offsite test server, but this is a very effective method of not getting locked out.
iptables -I INPUT -s <your IP> -j ACCEPT
You need to put this as the FIRST rule in order for it to work properly ("-I" inserts it as the first rule, whereas "-A" appends it to the end of the list).
Tip 6: Know and understand all of the rules in your current configuration.
Not making the mistake in the first place is half the battle. If you understand the inner workings behind your iptables ruleset, it will make your life easier. Draw a flow chart if you must.
Tip 7: Understand the way that iptables processes rules.
Remember, the rules start at the top of the chain and go down, unless specified otherwise. Crack open the iptables man page and learn about the options you are using.
Comments