Tuesday, June 06, 2006

Safe, Remote Firewall Management

One of the hazards of remote firewall administration is the possibility of locking yourself out after an erroneous rulebase change. It can happen with any firewall. There are various ways around this, I'm going to go over a few of them.

Traditionally what I've used when making major (or first-time) firewall policy changes via a remote SSH session or remote GUI (e.g., fwbuilder or Check Point's "Smart" Dashboard) is a rather ugly hack where I enter a cron job that unloads or clears the firewall policy every five minutes. If I retain remote access after a policy update, I just disable the cron entry. If I accidentally lock myself out, I can just wait a few minutes and establish an SSH session again. This is insecure, but presumably the "open" firewall policy would be corrected after a few minutes anyway. The cron entry (in root's crontab, of course) looks like this:

*/5 * * * * /usr/local/bin/fw-unload.sh
If we are using iptables, fw-unload.sh is something like this:

#!/bin/sh # # fw-unload.sh # Clears an iptables firewall and allows all traffic # IPT="/sbin/iptables" # You may want to disable forwarding until the firewall # policy is fixed # /bin/echo "0" > /proc/sys/net/ipv4/ip_forward # Clear the builtin chains and # delete any user-defined chains $IPT -F $IPT -X # Flush the nat and mangle tables for table in nat mangle do $IPT -t $table -F $IPT -t $table -X done # Default ACCEPT policies $IPT -P INPUT ACCEPT $IPT -P OUTPUT ACCEPT $IPT -P FORWARD ACCEPT
It can also strictly allow SSH from a single host to the firewall, which is obviously a much more secure fallback policy:

#!/bin/sh # # fw-unload.sh # Clears an iptables firewall and allows only SSH # from a single host to the firewall itself # IPT="/sbin/iptables" MGMT_IP="" # Clear the builtin chains and # delete any user-defined chains $IPT -F $IPT -X # Flush the nat and mangle tables for table in nat mangle do $IPT -t $table -F $IPT -t $table -X done # Default drop policies $IPT -P INPUT DROP $IPT -P OUTPUT DROP $IPT -P FORWARD DROP # Allow SSH to the firewall $IPT -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT $IPT -A INPUT -p tcp --dport 22 -s $MGMT_IP -m state --state NEW -j ACCEPT
You could also modify it slightly to be a known-good policy that allows not only SSH inbound to the firewall, but also allows outbound traffic and NAT from a protected network, just to keep your users happy. In fact, it would be ideal if the fallback policy was our previous one...read on to see how we can do that. In any case, given that fw-reload.sh enables a firewall ruleset in itself, you should test it to make sure you can rely on it in an emergency.

For a Check Point firewall on Linux or Nokia IPSO, this would work as a cron entry by itself:

*/5 * * * * $FWDIR/bin/fw unloadlocal
If you use fwbuilder, it has a very nice feature where you can choose to always allow SSH access from a single host, regardless of the rulebase that has been applied. From the fwbuilder GUI, highlight the firewall object in question, right-click and choose Edit from the context menu, then click on Firewall Settings... (setting highlighted below):

Ensuring Firewall SSH access
Finally, here is what I think is the best solution for those using iptables-save/restore. Martin Krafft (author of the excellent book The Debian System) has posted a script that solves this problem quite nicely. I like it because it is so simple - you take a firewall ruleset in iptables-save (8) format, and feed it to the iptables-apply.sh script. It prompts you after applying the new ruleset - if you cannot reply at the prompt (within 10 seconds by default), it reverts to your old ruleset:

root@stealth:~# ./iptables-apply.sh firewall-rules.txt Applying new ruleset... done. Ruleset applied; are you seeing this message? apparently not... Timeout. Something happened (or did not). Better play it safe... Reverting to old ruleset... done. root@stealth:~#
Technorati Tags: , , , ,

No comments: