[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