[nzlug] Firewall ruleset check...
Daniel Lawson
daniel at meta.net.nz
Thu May 15 10:25:11 NZST 2008
>
> When I see people make remote changes and crossing their fingers I
> think to myself that there is a better way. When I make a remote
> change to a network, for example, I try to have a little script that
> a) moves the current config out of the way, b) runs some 'before'
> commands (eg ping, route, etc), c) makes the change, d) run some
> 'after' commands, e) waits for 30 seconds or so, so that I can run
> some commands from the local end, f) reverses the changes and
> restores the status quo.
>
> Of course it's not perfect (if the script bombs for any reason for
> example. you're in the dung) but it seems the obvious way to protect
> yourself when making changes. But people say to me "Wow, what a good
> idea!" But to me it's simple caution and a bit of foresight.
I'm assuming you're talking about a linux or bsd or similar box at the
other end, and as such there is a nicer way of managing this, which
avoids the problem you mention of if your script bombs out, you're
screwed:
Use the "at" scheduler to issue a restart of your known clean firewall
rules at some point in the future.
You could screen a "sleep n && firewall restart "[1] as well, I guess,
but using at detaches the firewall restart completely from your
running processes.
[1] in a different window to whatever you're running, obviously. As an
aside, any important sysadmin work that might suffer from having its
console detached or killed should be done inside a screen session. DSL
connections in NZ aren't perfect, and I've had one site which, despite
changing both the DSL modem and the linux firewall, would still
randomly drop some port forwards (eg, port 22), thus killing my
current work. Bad, bad bad.
More information about the NZLUG
mailing list