Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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
add comment

7 Answers

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
add comment

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
add comment

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
add comment

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
add comment

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
add comment

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
add comment

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
add comment

Your Answer

 
discard

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.