Tom, I was upgrading a remote firewall, when upon restart, shorewall found a rule with a wrong zone and decided to not continue and stop itself. The problem now, is I cannot access that firewall over ssh anymore. One suggestion would be to instead of "shorewall stop" to have a basic emergency rule with only ACCEPT:info all all tcp ssh rule instead with DROP all policy. Shorewall could check for a directory under /etc/shorewall/emergency and if it find it do a shorewall try /etc/shorewall/emergency 360 then a shorewall stop or do a shorewall ermengency which will default to shorewall stop if the directory doesn''t exist. What do you think? Thanks Pascal PS: While I use the shorewall try option, I will still be great to know that whatever happens we can always ssh back in.
That''s what ''shorewall check'' is for ;) On 29 Jan 2003 08:51:19 -0800 Pascal DeMilly <list.shorewall@newgenesys.com> opened up to us and said:> Tom, > > I was upgrading a remote firewall, when upon restart, shorewall found > a rule with a wrong zone and decided to not continue and stop itself. > > The problem now, is I cannot access that firewall over ssh anymore. > One suggestion would be to instead of "shorewall stop" to have a basic > emergency rule with only ACCEPT:info all all tcp ssh rule instead with > DROP all policy. Shorewall could check for a directory under > /etc/shorewall/emergency and if it find it do a shorewall try > /etc/shorewall/emergency 360 then a shorewall stop or do a shorewall > ermengency which will default to shorewall stop if the directory > doesn''t exist. > > What do you think? > > Thanks > > Pascal > > PS: While I use the shorewall try option, I will still be great to > know that whatever happens we can always ssh back in. > > _______________________________________________ > Shorewall-devel mailing list > Shorewall-devel@lists.shorewall.net > http://lists.shorewall.net/mailman/listinfo/shorewall-devel-- Paul "snafu" <snafu@forkbomb.dhs.org> http://forkbomb.dhs.org/bs/
--On Wednesday, January 29, 2003 11:54 AM -0500 Paul <snafu@forkbomb.dhs.org> wrote:> That''s what ''shorewall check'' is for ;)''shorewall check'' will never be complete enough to catch all problems. On the other hand, it DOES catch things like specifying a undefined zone. When administering a Shorewall firewall remotely: a) the FIRST change you should make is to include your own IP address in /etc/shorewall/routestopped. I invented that file largely to handle the problem that Pascal encountered. b) When making a configuration change, ALWAY use ''shorewall try''. Those two measures together ensure that you don''t saw off the tree limb that you are sitting on. Do we really need something more in 2.0? -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ teastep@shorewall.net
--On Wednesday, January 29, 2003 9:21 AM -0800 Tom Eastep <teastep@shorewall.net> wrote: Pascal''s post got me to thinking about Shorewall state transitions -- they are now documented at http://www.shorewall.net/starting_and_stopping_shorewall.htm#StateDiagram. -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ teastep@shorewall.net
--On Wednesday, January 29, 2003 2:10 PM -0800 Tom Eastep <teastep@shorewall.net> wrote:> > > --On Wednesday, January 29, 2003 9:21 AM -0800 Tom Eastep > <teastep@shorewall.net> wrote: > > Pascal''s post got me to thinking about Shorewall state transitions -- > they are now documented at > http://www.shorewall.net/starting_and_stopping_shorewall.htm#StateDiagram. >And BTW -- I''ve fixed the second row of the table at the bottom of the page. Will be fixed at www.shorewall.net at the next rsync... -Tom -- Tom Eastep \ Shorewall - iptables made easy Shoreline, \ http://www.shorewall.net Washington USA \ teastep@shorewall.net
I try to use "shorewall try" and "shorewall check" as much
as I can but
sometimes it is difficult. Let me explain. A typical configuration for
me would be
lan0 <---> fw0 <----------VPN over Internet --------> fw1
<---> lan1
| |
lan2 <----- VPN over wireless link -----+ FRAD +--
lan3
And more crazy links like that. I use the host file quite a bit :-).
So on my screen, I might have an xterm for all the different firewalls
that I am dealing with at once. (not all run shorewall, some are still
ipchains based). Let''s say I want to install a new service. Some are
easy and straightforward and some are a pain, like NFS.
Therefore sometimes I screw up. I might type "shorewall check" in one
xterm but restart it from another one. (Thanks to multi-gnome-terminal
for tabs and HSplit it is now a lot less confusing)
What I would like is a way, that even if I screw up badly in my config
for shorewall, to not prevent me from ssh''ing to it. (I didn''t
think to
use routestopped file for that, it is a good idea).
Kind of /sbin/service iptables save. Before Tom came up with "shorewall
try", I use to do: echo "/sbin/service iptables restart" | at +5
minutes
before every "shorewall restart".
With "shorewall try" I have to make a separate directory, and update
that directory which is a pain, because I more than once forgot to
update my /etc/shorewall directory after I got everything working and
tested.
Then at the next reboot or shorewall restart I am toasted. Well almost,
most of my firewalls are setup to be accessible by modem, but still.
What would be perfect is maybe the following:
When shorewall starts successfully, it could make a copy of the config
files into a separate directory /usr/lib/shorewall/current. Then when
you do a "shorewall try" it tries the /etc/shorewall directory first
but
if it fails goes back to reloading /usr/lib/shorewall/current. As an
added bonus, the copy program from /etc/shorewall to
/usr/lib/shorewall/current could be an external shell, so we can add a
little cvs layer if we wanted to.
What do you think ?
Pascal
On Wed, 2003-01-29 at 09:21, Tom Eastep wrote:> --On Wednesday, January 29, 2003 11:54 AM -0500 Paul
> <snafu@forkbomb.dhs.org> wrote:
>
> > That''s what ''shorewall check'' is for ;)
>
> ''shorewall check'' will never be complete enough to catch
all problems. On
> the other hand, it DOES catch things like specifying a undefined zone.
>
> When administering a Shorewall firewall remotely:
>
> a) the FIRST change you should make is to include your own IP address in
> /etc/shorewall/routestopped. I invented that file largely to handle the
> problem that Pascal encountered.
> b) When making a configuration change, ALWAY use ''shorewall
try''.
>
> Those two measures together ensure that you don''t saw off the tree
limb
> that you are sitting on.
>
> Do we really need something more in 2.0?
>
> -Tom
> --
> Tom Eastep \ Shorewall - iptables made easy
> Shoreline, \ http://www.shorewall.net
> Washington USA \ teastep@shorewall.net
> _______________________________________________
> Shorewall-devel mailing list
> Shorewall-devel@lists.shorewall.net
> http://lists.shorewall.net/mailman/listinfo/shorewall-devel