View Single Post
  #1   (View Single Post)  
Old 14th June 2008
anomie's Avatar
anomie anomie is offline
Join Date: Apr 2008
Location: Texas
Posts: 445
Default Modify host-level firewall rules (without getting locked out)

This guide is geared toward sysadmins who manage remote servers running host-level firewalls. The theory should apply to any *nix OS with packet filtering firewall capabilities. The specific examples provided are for FreeBSD 6.3. (General approach was inspired by advice found in the book Mastering FreeBSD and OpenBSD Security.)


You apply packet filtering rule changes to your remote server's host-level firewall, only to discover you are now locked out. Whoops. Time to get on the phone to ask someone to physically access the console so that you can talk him through the steps needed to let you in again. Let's avoid all that...

Firewall bailout idea
The approach goes something like this:
  1. You schedule an at job to run 15 minutes from now. Its only purpose is to save you from yourself (in the event of a packet filtering rule mishap).
  2. You modify your packet filtering ruleset, and apply the new rules.
  3. If all goes well, you just cancel the at job. If all goes unwell (and your goof eliminated your ssh access to the server), the at job ensures that you'll be able to get in again in 15 minutes or so. Diagnose where you went wrong with your ruleset, and start over from step 1...

Bailout at job expanded
What does this at job actually do? This is where things are very flexible -- it can do different things for different people, based on need. One option is to have it shut off / open up your firewall completely. If this is impractical (or dangerous), another option is to have it lock down your firewall to the outside world, except for a rule that allows you ssh access in. If that doesn't sit well in your situation, yet another option is to have it roll back to a previous iteration of a "known good" ruleset.

Bailout example
[ written for FreeBSD 6.3 using pf ]

Consider the following script,

/sbin/pfctl -d

exit 0
What does this do? Quite simply, when run it disables pf, allowing all traffic to pass.

Given, let's put the "Firewall bailout idea" to work.
  1. Schedule the at job.
    # at -f /root/ +15 minutes
    Job 31 will be executed using /bin/sh
  2. Busily change your packet filtering ruleset. Apply the changes...
  3. Were you successful? Then cancel the at job!
    # atq
    Date                            Owner           Queue   Job#
    Fri Jun 13 22:00:00 CDT 2008    mmff            c       31
    # atrm 31
    Did you get locked out? Not a serious issue, thanks to your planning. Count down the time until the at job runs, ssh in again, identify the ruleset problem, and start over from step 1.


And there it is. A simple, (hopefully) straightforward approach to modifying your packet filtering rules without getting locked out. Be sure to tailor the at job to suit your specific needs, and be especially sure to test it while you or someone you trust has console access. Happy administering.
Kill your t.v.
Reply With Quote