Safely changing iptables firewall rules?

Question

What do people do when they are changing their firewall rules to make sure they don't accidentally lock themselves out?

For example, is there a way to load firewall rules so that they're only active for some testing period and then have the firewall rules revert back to the previous settings?

Answer 1

Another option would be to have a screen session open on the server, and have a job in the screen session that sleeps for a few minutes and then flushes the tables. After you have made your changes, you can just kill the job. You could also maybe just have the script change the INPUT policy to ACCEPT, or something like that.

Might be a little more convenient than cron, but the same idea. I do a similar thing with routers reload in 10. So if I lock myself out, the router will reboot and restore the config to the state before I made the change.

Answer 2

I use firehol as a front-end to iptables. Firehol has a really nice feature that allows you to safely test a new set of rules.

When you run the command firehol try, Firehol sets itself to ignore HUP, takes a backup of the current rule set, applies the new rule set and then gives the user a prompt asking them if they want to commit to the new set of rules. If you do not respond to within thirty seconds, then firehol restores the previous set of rules.

Answer 3

The ideal thing to do is always have console access, of course, even if it's emulated console access through another interface.

If you're using something that uses an iptables service (like /etc/init.d/iptables) which you can turn on and off, you could set up a simple cronjob to turn it off every 30 minutes. A more general solution would be to run the following at some interval: How to: Linux flush or remove all iptables rules. This can be accomplished by a cronjob, or just running screen and doing a sleep loop in bash to run that little script occasionally.

If you're experimenting with iptables and learning how to use it, though, nothing beats having a monitor plugged in, just in case.

Answer 4

Going off of what rjewell said. You could create a cron job that flushes and reloads all of your rules from a config file every 30 min. Then when you are testing you change the rules directly with commands and only save it to the config file once you are sure that it works.

Answer 5

For our remote servers we use KVM over IP. This allows us to have a remote keyboard/mouse/display that is independent from our iptables rule sets.

Answer 6

I'd either set an at job for a few minutes' time to reload the previous set of rules, although I think a better way would be to make sure you allow access from your IP as one of the very first rules - if not the first rule. That way, you can take it out when you're happy with it.

It's also worth noting that if you're allowing related and established connections (i.e. -m state --state RELATED,ESTABLISHED -j ACCEPT) and you manage to block SSH access, any existing connections should be maintained - so make sure you check you can SSH in again before logging out of your existing session!

Answer 7

As a rule, I never change the policy of my INPUT chain to DENY. I instead add instead add a final rule:

iptables -A INPUT -i <dev> -j REJECT

If your script dies mid execution (say you're running remotely on a bad link and get disconnected) and you've set a DENY policy you may lock yourself out. This way you've raised the odds that you'll have at least have access in the case of failure.

You still need to make sure that your rules grant sufficient access such that the final rule doesn't boot you but I think the other replies cover that well enough.