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?
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.
reload command for options.
reload cancel cancels the reload after you have made you changes and are not locked out.
Feb 25, 2010 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.
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!
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.
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.
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.
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.
To be more precise than some of the other answers here. I ended up doing the following:
I backup up my current iptables rules:
sudo iptables-save > original-iptables.save
I created a new session using tmux:
tmux
I split the tmux session into two panes using:
<C>-b %
In the first pane I executed: (run this as root user sudo su)
sleep 5m && sudo iptables-restore original-iptables.save
This will reset your iptables rules after 5 minutes. This command actually ensures that you cannot lock yourself out of your server by accident.
You can use the other pane in order to try out any new rules. (switch panes using <C>-b o) If the new rules work you can always cancel the original command using -c to ensure that the new rules stay active and are not reset.
You can find a nice & simple cheatsheet about tmux here.
In this case I like to use CSF which is an iptables manager but much simplier, there you can specify inbound and outbound ports as well as ip ranges. It also has a testing festure where it enabled the rules for 5 minutes, after that the rules are gone, that way you can make sure that even if you get locked out, after 5 mins you will be able to get in again.
Hope this helps!
Run in screen or tmux
Save the current tables:
iptables-save > iptables.conf
Edit the file, add/remove to your heart's content
Load the file into the kernel using iptables-apply
iptables-apply -t 300 iptables.conf
Check that you can open a connection to the server. If so, answer "y" to the question.
If something bad happens, just wait 300 seconds and the tables will be reverted. (Or shorten the wait to maybe 1 minute -t 60)
