Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question

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.

share|improve this answer
Awesome! I never thought to even check out the reload command for options. – MikeyB Feb 25 '10 at 4:15
+1 for the delayed reload option. :) – einstiien Feb 25 '10 at 6:04
reload cancel cancels the reload after you have made you changes and are not locked out. – Kyle Brandt Feb 25 '10 at 12:19

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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!

share|improve this answer

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.

share|improve this answer
Always run in screen! Your script will never die mid-execution. – MikeyB Feb 25 '10 at 4:16
I do, but there is more than one way your script can die, maybe I'm just paranoid :) – Frenchie Feb 25 '10 at 5:13

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.