Hi! I have decent experience with self-maded iptables script for my 3-legged firewall. Now I''m trying shorewall (3.2.6 on Debian stable) for my web-server in DMZ and I have these questions. 1. How iptables default policy of built-in chains (iptables -P) affect shorewall behaviour? 2. Why default policy of built-in chains for stopped state is ACCEPT insteed of DROP/REJECT for extra security and hardcoded in shorewall? Can I configure default policy of built-in chains for running and stopped shorewall states respectively? "start" sript with iptables -P INPUT DROP iptables -P OUTPUT DROP iptables -P FORWARD DROP lines work well, but "stopped" script with same lines don''t work for me (policies is still ACCEPT after "shorewall stop"). Thanks! ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
sftf wrote:> Hi! > I have decent experience with self-maded iptables script for my > 3-legged firewall. > > Now I''m trying shorewall (3.2.6 on Debian stable) for my web-server in DMZ and I have these > questions. > > 1. How iptables default policy of built-in chains (iptables -P) affect shorewall > behaviour?For the raw, mangle and nat tables, Shorewall won''t work unless the default policy is ACCEPT. That''s because any packet that falls off the end of such a chain is assumed to be accepted. The filter table policies don''t matter but shorewall sets them to DROP anyway.> > 2. Why default policy of built-in chains for stopped state is ACCEPT insteed of > DROP/REJECT for extra security and hardcoded in shorewall?The default policy of the built-in filter chains is NOT ACCEPT when shorewall is stopped. gateway:~ # shorewall stop Stopping Shorewall... done. gateway:~ # shorewall show Shorewall 4.0.5 filter Table at gateway - Fri Oct 5 15:37:56 PDT 2007 Counters reset Fri Oct 5 15:37:02 PDT 2007 Chain INPUT (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 50 6474 ACCEPT 0 -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 0 0 ACCEPT 0 -- br0 * 192.168.0.0/22 0.0.0.0/0 0 0 ACCEPT 0 -- lo * 0.0.0.0/0 0.0.0.0/0 Chain FORWARD (policy DROP 2 packets, 126 bytes) pkts bytes target prot opt in out source destination 81 8100 ACCEPT 0 -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 0 0 ACCEPT 0 -- br0 * 192.168.0.0/22 0.0.0.0/0 0 0 ACCEPT 0 -- * br0 0.0.0.0/0 192.168.0.0/22 Chain OUTPUT (policy ACCEPT 36 packets, 6234 bytes) pkts bytes target prot opt in out source destination gateway:~ # In that system, OUTPUT has policy ACCEPT because ADMINISABSENTMINDED is set to Yes in shorewall.conf.> Can I configure default policy of built-in chains for running and > stopped shorewall states respectively? > > "start" sript with > iptables -P INPUT DROP > iptables -P OUTPUT DROP > iptables -P FORWARD DROP > lines work well, but "stopped" script with same lines don''t work for > me (policies is still ACCEPT after "shorewall stop").If you are seeing the reported behavior, it must be something that the Debian maintainer is changing. No version of Shorewall ever released from shorewall.net has had default policies of ACCEPT for INPUT and FORWARD after ''shorewall stop''. Please check the SVN repository under shorewall/tags/3.2.6 -- you will see that the code in stop_firewall() in the ''firewall'' script sets the policies for the nat, raw and mangle chains to ACCEPT. But it sets the others based on the setting of ADMINISABSENTMINDED. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Tom Eastep wrote:> > If you are seeing the reported behavior, it must be something that the > Debian maintainer is changing. No version of Shorewall ever released > from shorewall.net has had default policies of ACCEPT for INPUT and > FORWARD after ''shorewall stop''.See this from the Debian .diff. +# stop the firewall +shorewall_stop () { + echo -n "Stopping \"Shorewall firewall\": " + $SRWL clear >> $INITLOG 2>&1 && echo "done." || echo_notdone ----- + return 0 +} + So if you use the Debian init scripts and run "/etc/init.d/shorewall stop", what you really get is "shorewall clear". If you follow the Shorewall documentation and run "shorewall stop" instead, you get the behavior you (and we) wanted in the first place. Lesson: If you don''t get your Shorewall packages from shorewall.net, you can''t be sure that they do what the developers intended. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Roberto C. Sánchez
2007-Oct-06 01:28 UTC
Re: Default policy for iptables built-in chains...
On Fri, Oct 05, 2007 at 06:12:02PM -0700, Tom Eastep wrote:> > See this from the Debian .diff. > > +# stop the firewall > +shorewall_stop () { > + echo -n "Stopping \"Shorewall firewall\": " > + $SRWL clear >> $INITLOG 2>&1 && echo "done." || echo_notdone > ----- > + return 0 > +} > + > > So if you use the Debian init scripts and run "/etc/init.d/shorewall > stop", what you really get is "shorewall clear". > > If you follow the Shorewall documentation and run "shorewall stop" > instead, you get the behavior you (and we) wanted in the first place. > > Lesson: > > If you don''t get your Shorewall packages from shorewall.net, you can''t > be sure that they do what the developers intended. >This might merit a bug report against the Debian package. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
On Fri, Oct 05, 2007 at 09:28:47PM -0400, Roberto C. S?nchez wrote:> On Fri, Oct 05, 2007 at 06:12:02PM -0700, Tom Eastep wrote: > > > > See this from the Debian .diff. > > > > +# stop the firewall > > +shorewall_stop () { > > + echo -n "Stopping \"Shorewall firewall\": " > > + $SRWL clear >> $INITLOG 2>&1 && echo "done." || echo_notdone > > ----- > > + return 0 > > +} > > + > > > > So if you use the Debian init scripts and run "/etc/init.d/shorewall > > stop", what you really get is "shorewall clear". > > > > If you follow the Shorewall documentation and run "shorewall stop" > > instead, you get the behavior you (and we) wanted in the first place. > > > > Lesson: > > > > If you don''t get your Shorewall packages from shorewall.net, you can''t > > be sure that they do what the developers intended. > > > This might merit a bug report against the Debian package.It''s the fix to #342609. The problem is that the required behaviour from "/etc/init.d/foo stop" on a Debian host is not the same thing as the expected behaviour from "shorewall stop". shorewall interprets "stop" as meaning "stop the firewall, so no traffic moves", while Debian interprets it as "stop the package, so my system behaves as if it wasn''t installed". It''s a question of whether you''re thinking of the host as being a firewall, or as being a platform for various packages to run on. There is no solution other than user education. Don''t use the init script if you meant to say "shorewall stop". The word just doesn''t mean the same thing in different contexts. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Andrew Suffield wrote:> On Fri, Oct 05, 2007 at 09:28:47PM -0400, Roberto C. S?nchez wrote: >> On Fri, Oct 05, 2007 at 06:12:02PM -0700, Tom Eastep wrote: >>> Lesson: >>> >>> If you don''t get your Shorewall packages from shorewall.net, you can''t >>> be sure that they do what the developers intended. >>> >> This might merit a bug report against the Debian package. > > It''s the fix to #342609. The problem is that the required behaviour > from "/etc/init.d/foo stop" on a Debian host is not the same thing as > the expected behaviour from "shorewall stop". shorewall interprets > "stop" as meaning "stop the firewall, so no traffic moves", while > Debian interprets it as "stop the package, so my system behaves as if > it wasn''t installed". It''s a question of whether you''re thinking of > the host as being a firewall, or as being a platform for various > packages to run on. > > There is no solution other than user education. Don''t use the init > script if you meant to say "shorewall stop". The word just doesn''t > mean the same thing in different contexts.Roberto This might be another point to make on your "Shorewall on Debian" article on the Wiki. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Tom Eastep wrote:> > Roberto > > This might be another point to make on your "Shorewall on Debian" > article on the Wiki. >Because I think that anyone who is serious about running a firewall (like the OP) believes that the Shorewall interpretation of "stop" is more appropriate. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
On Fri, Oct 05, 2007 at 07:36:16PM -0700, Tom Eastep wrote:> Tom Eastep wrote: > > > > Roberto > > > > This might be another point to make on your "Shorewall on Debian" > > article on the Wiki. > > > > Because I think that anyone who is serious about running a firewall > (like the OP) believes that the Shorewall interpretation of "stop" is > more appropriate.And it probably is. Debian init scripts have their functionality mandated by the boot and package management system; they have to behave in a certain way for those things to work like they are supposed to. They are not intended primarily as a user interface. Sometimes it''s convinient to run them by hand, and sometimes it isn''t. This would probably be one of those times when it''s best to leave the init script to handling the boot/install/upgrade/uninstall processes that it was designed for, and do any unusual stuff by running shorewall directly. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Tom Eastep wrote:> Andrew Suffield wrote: >> There is no solution other than user education. Don''t use the init >> script if you meant to say "shorewall stop". The word just doesn''t >> mean the same thing in different contexts. > > Roberto > > This might be another point to make on your "Shorewall on Debian" > article on the Wiki.I''ve also added a section to the ''Starting and Stopping'' article. http://www1.shorewall.net/starting_and_stopping_shorewall.htm#Init -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Paul Gear
2007-Oct-07 01:32 UTC
Re: [shorewall-users] Default policy for iptables built-in chains...
Roberto C. Sánchez wrote:> ... >> See this from the Debian .diff. >> >> +# stop the firewall >> +shorewall_stop () { >> + echo -n "Stopping \"Shorewall firewall\": " >> + $SRWL clear >> $INITLOG 2>&1 && echo "done." || echo_notdone >> ----- >> + return 0 >> +} >> + >> >> So if you use the Debian init scripts and run "/etc/init.d/shorewall >> stop", what you really get is "shorewall clear". >> >> If you follow the Shorewall documentation and run "shorewall stop" >> instead, you get the behavior you (and we) wanted in the first place. >> >> Lesson: >> >> If you don''t get your Shorewall packages from shorewall.net, you can''t >> be sure that they do what the developers intended. >> > This might merit a bug report against the Debian package.Given that Shorewall''s most popular distribution as of our last survey (http://shorewall.net/survey-200603.html) was Debian, i think it would make sense to make it easy for Debian/Ubuntu users to use more recent versions of Shorewall that behave like Shorewall users expect. As Andrew has mentioned, i don''t think we''re likely to get far with getting Debian to change the behaviour of the package. So one thing on my mind lately is to provide a deb/apt repository that people could use to supplement their Debian/Ubuntu system and override the Debian packages with more recent Shorewall packages. I have a few of my own packages that i maintain in a personal repository, and i don''t think it would be too hard to extend my scripts to build Shorewall from release tarballs and SVN. These could then be mirrored onto the main web site and provided for public use. (I think it would also be great if users of SUSE and Fedora/CentOS could do something similar to make it easy to keep Shorewall up-to-date with YaST and yum.) Paul <http://paul.gear.dyndns.org> P.S. I''d also like to run another survey soon (maybe mid-November when my study load decreases), but i don''t want to limit it to 100 responses (which is Zoomerang''s limit on free surveys). I''ve been looking at UCCASS (http://www.bigredspark.com/survey.html), and it seems quite good, but it will be a while before i get a chance to implement and test it fully. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Andrew Suffield
2007-Oct-07 07:47 UTC
Re: [shorewall-users] Default policy for iptables built-in chains...
On Sun, Oct 07, 2007 at 11:32:23AM +1000, Paul Gear wrote:> Given that Shorewall''s most popular distribution as of our last survey > (http://shorewall.net/survey-200603.html) was Debian, i think it would > make sense to make it easy for Debian/Ubuntu users to use more recent > versions of Shorewall that behave like Shorewall users expect. As > Andrew has mentioned, i don''t think we''re likely to get far with getting > Debian to change the behaviour of the package.Changing it will just mean that the behaviour of other parts of the system behave unexpectedly (or maybe break entirely). Best to leave the init script alone, and just not use it as a user interface. Getting stuff like that right is probably why Debian is the most popular platform. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Andrew Suffield wrote:> On Sun, Oct 07, 2007 at 11:32:23AM +1000, Paul Gear wrote: >> Given that Shorewall''s most popular distribution as of our last survey >> (http://shorewall.net/survey-200603.html) was Debian, i think it would >> make sense to make it easy for Debian/Ubuntu users to use more recent >> versions of Shorewall that behave like Shorewall users expect. As >> Andrew has mentioned, i don''t think we''re likely to get far with getting >> Debian to change the behaviour of the package. > > Changing it will just mean that the behaviour of other parts of the > system behave unexpectedly (or maybe break entirely). Best to leave > the init script alone, and just not use it as a user interface. > Getting stuff like that right is probably why Debian is the most > popular platform.I think most of the opinions voiced in that thread indicated that the behaviour was very much *not* right for Shorewall users, despite the fact that it might be "right" in the Debian sense. -- Paul <http://paul.gear.dyndns.org> -- Did you know? Email is not private and can be viewed by your ISP, the recipient''s ISP, and possibly other parties. You can make sure your emails are private by using GNU Privacy Guard <http://www.gnupg.org> and an email plug-in like Enigmail <http://enigmail.mozdev.org>. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
On Sun, Oct 07, 2007 at 06:49:16PM +1000, Paul Gear wrote:> Andrew Suffield wrote: > > On Sun, Oct 07, 2007 at 11:32:23AM +1000, Paul Gear wrote: > >> Given that Shorewall''s most popular distribution as of our last survey > >> (http://shorewall.net/survey-200603.html) was Debian, i think it would > >> make sense to make it easy for Debian/Ubuntu users to use more recent > >> versions of Shorewall that behave like Shorewall users expect. As > >> Andrew has mentioned, i don''t think we''re likely to get far with getting > >> Debian to change the behaviour of the package. > > > > Changing it will just mean that the behaviour of other parts of the > > system behave unexpectedly (or maybe break entirely). Best to leave > > the init script alone, and just not use it as a user interface. > > Getting stuff like that right is probably why Debian is the most > > popular platform. > > I think most of the opinions voiced in that thread indicated that the > behaviour was very much *not* right for Shorewall users, despite the > fact that it might be "right" in the Debian sense.How many of those users would be willing to sacrifice a well-behaved package manager in order to have an alternative to running the shorewall command directly? The opinion of a user who doesn''t understand the system is not automatically valid, and is frequently misguided. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Andrew Suffield wrote:> On Sun, Oct 07, 2007 at 06:49:16PM +1000, Paul Gear wrote: >> Andrew Suffield wrote: >>> On Sun, Oct 07, 2007 at 11:32:23AM +1000, Paul Gear wrote: >>>> Given that Shorewall''s most popular distribution as of our last survey >>>> (http://shorewall.net/survey-200603.html) was Debian, i think it would >>>> make sense to make it easy for Debian/Ubuntu users to use more recent >>>> versions of Shorewall that behave like Shorewall users expect. As >>>> Andrew has mentioned, i don''t think we''re likely to get far with getting >>>> Debian to change the behaviour of the package. >>> Changing it will just mean that the behaviour of other parts of the >>> system behave unexpectedly (or maybe break entirely). Best to leave >>> the init script alone, and just not use it as a user interface. >>> Getting stuff like that right is probably why Debian is the most >>> popular platform. >> I think most of the opinions voiced in that thread indicated that the >> behaviour was very much *not* right for Shorewall users, despite the >> fact that it might be "right" in the Debian sense. > > How many of those users would be willing to sacrifice a well-behaved > package manager in order to have an alternative to running the > shorewall command directly? The opinion of a user who doesn''t > understand the system is not automatically valid, and is frequently > misguided.Now you''re losing me. Why would having an alternate version of the Shorewall packages for Shorewall users mean that they are sacrificing a well-behaved package manager? I agree with you that we simply discourage the use of the init script as a user interface, but if consensus is that ''/etc/init.d/shorewall stop'' should be equivalent to ''shorewall stop'', i can''t see that that would thereby compromise the whole of the packaging system. -- Paul <http://paul.gear.dyndns.org> -- Did you know? Even when you legally buy Windows Vista, you don''t own it, and by using it you consent to allowing Microsoft to spy on your computer. Find out more at http://badvista.fsf.org/what-s-wrong-with-microsoft-windows-vista ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
On Sun, Oct 07, 2007 at 07:16:58PM +1000, Paul Gear wrote:> >> I think most of the opinions voiced in that thread indicated that the > >> behaviour was very much *not* right for Shorewall users, despite the > >> fact that it might be "right" in the Debian sense. > > > > How many of those users would be willing to sacrifice a well-behaved > > package manager in order to have an alternative to running the > > shorewall command directly? The opinion of a user who doesn''t > > understand the system is not automatically valid, and is frequently > > misguided. > > Now you''re losing me. Why would having an alternate version of the > Shorewall packages for Shorewall users mean that they are sacrificing a > well-behaved package manager? > > I agree with you that we simply discourage the use of the init script as > a user interface, but if consensus is that ''/etc/init.d/shorewall stop'' > should be equivalent to ''shorewall stop'', i can''t see that that would > thereby compromise the whole of the packaging system.The package system is subtle and quite involved; the rules have been carefully worked out through years of experience with thousands of packages. Meddling with them can create all kinds of strange effects. For example, let''s assume you did the following: apt-get install shorewall # ... # (start setting it up) # ... # actually, I wanted the other one... apt-get install shorewall-lite Would you expect the last command to disable your network access? Behind the scenes, apt noted that shorewall-lite conflicts with shorewall, so it scheduled shorewall for removal. As part of the removal process, the shorewall init script was instructed to stop, under the assumption that this would return the system to its pre-shorewall state, ready for installation of shorewall-lite. Unexpected results like this are likely to happen all the time if you have an init script where ''stop'' does not undo ''start''. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Roberto C. Sánchez
2007-Oct-07 12:39 UTC
Re: Default policy for iptables built-in chains...
On Sun, Oct 07, 2007 at 10:43:28AM +0100, Andrew Suffield wrote:> > The package system is subtle and quite involved; the rules have been > carefully worked out through years of experience with thousands of > packages. Meddling with them can create all kinds of strange > effects. For example, let''s assume you did the following: > > apt-get install shorewall > # ... > # (start setting it up) > # ... > # actually, I wanted the other one... > apt-get install shorewall-lite > > Would you expect the last command to disable your network access? > > Behind the scenes, apt noted that shorewall-lite conflicts with > shorewall, so it scheduled shorewall for removal. As part of the > removal process, the shorewall init script was instructed to stop, > under the assumption that this would return the system to its > pre-shorewall state, ready for installation of shorewall-lite. > > Unexpected results like this are likely to happen all the time if you > have an init script where ''stop'' does not undo ''start''. >I''m afraid I must agree with Andrew. This is similar to the situation that was discussed a while back about having something /etc/defaults to enable/disable the firewall instead of having it in shorewall.conf. Additionally, given Debian''s popularity as a hosting platform (e.g., for colo or other remote hosting) it would be very dangerous to advocate that the automated actions of the packaging systems potentially remove network access completely. I have a feeling that some people would be quite irritated with that. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Andrew Suffield wrote:> On Sun, Oct 07, 2007 at 07:16:58PM +1000, Paul Gear wrote: > For example, let''s assume you did the following: > > apt-get install shorewall > # ... > # (start setting it up) > # ... > # actually, I wanted the other one... > apt-get install shorewall-lite > > Would you expect the last command to disable your network access?Given the ubiquitous use of ADMINISABSENTMINDED=Yes, the possibility of ''/etc/init.d/shorewall stop'' disabling network access is remote. Nevertheless, it is a possibility.> > Behind the scenes, apt noted that shorewall-lite conflicts with > shorewall, so it scheduled shorewall for removal. As part of the > removal process, the shorewall init script was instructed to stop, > under the assumption that this would return the system to its > pre-shorewall state, ready for installation of shorewall-lite. > > Unexpected results like this are likely to happen all the time if you > have an init script where ''stop'' does not undo ''start''. >While installing Shorewall from the tarball rather than from the .deb avoids many such problems by placing Shorewall outside of the purview of the package manager, I suppose that there may still be some problems lurking about. But since we implemented ADMINISABSENTMINDED, I haven''t heard of any. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
On Sun, Oct 07, 2007 at 08:09:07AM -0700, Tom Eastep wrote:> While installing Shorewall from the tarball rather than from the .deb avoids > many such problems by placing Shorewall outside of the purview of the > package manager, I suppose that there may still be some problems lurking > about.Most likely not - the problem becomes very simple when you aren''t trying to implement reliable package management. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Roberto C. Sánchez
2007-Oct-07 20:05 UTC
Re: [shorewall-users] Default policy for iptables built-in chains...
On Sun, Oct 07, 2007 at 11:32:23AM +1000, Paul Gear wrote:> > So one thing on my mind lately is to provide a deb/apt repository that > people could use to supplement their Debian/Ubuntu system and override > the Debian packages with more recent Shorewall packages. I have a few > of my own packages that i maintain in a personal repository, and i don''t > think it would be too hard to extend my scripts to build Shorewall from > release tarballs and SVN. These could then be mirrored onto the main > web site and provided for public use. >I think that this could be dangerous. I''d much rather see the official Debian package get "fixed". The reason is that Debian users expect (well, at least most of them do) that packages will strictly adhere to Debian policy. Now, in some cases, this creates a conflict between the "Debian" way and what the upstream developers consider to be right. Personally, having nearly all of my systems installed with Debian, I am more concerned with Debian packages being policy compliant and consistent than I am with some other things. As far as the init script issue, one possibility is to ask the Debian maintainer to include a note in the README.Debian file that there is in fact a difference in behavior between the init script and the shorewall command. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Roberto C. Sánchez
2007-Oct-07 20:32 UTC
Re: Default policy for iptables built-in chains...
On Fri, Oct 05, 2007 at 07:36:16PM -0700, Tom Eastep wrote:> Tom Eastep wrote: > > > > Roberto > > > > This might be another point to make on your "Shorewall on Debian" > > article on the Wiki. > > > > Because I think that anyone who is serious about running a firewall > (like the OP) believes that the Shorewall interpretation of "stop" is > more appropriate. >I''ve added the note, but without taking sides :-) Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
On Sun, Oct 07, 2007 at 04:32:15PM -0400, Roberto C. S?nchez wrote:> On Fri, Oct 05, 2007 at 07:36:16PM -0700, Tom Eastep wrote: > > Tom Eastep wrote: > > > > > > Roberto > > > > > > This might be another point to make on your "Shorewall on Debian" > > > article on the Wiki. > > > > > > > Because I think that anyone who is serious about running a firewall > > (like the OP) believes that the Shorewall interpretation of "stop" is > > more appropriate. > > > I''ve added the note, but without taking sides :-)I hadn''t actually seen that article before. It''s worth noting that since shorewall doesn''t contain any library dependencies, you can usually grab the shorewall package from unstable and install it on a stable system without any trouble. That''s what I do on all my complex firewalls, eliminating the problem of the old packages in stable. (The simple desktop-to-DSL NAT firewalls that go all over the place run quite happily with the stable packages. I think I even still have a couple still running shorewall 2.x, and they probably haven''t even been rebooted since that was current - their function is so trivial that there''s just no reason to bother upgrading them) Uncertain how this will work with shorewall-perl, I can''t tell until Lorenzo gets around to packaging it. But I don''t forsee any particular difficulties in doing the same thing. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Roberto C. Sánchez
2007-Oct-07 21:33 UTC
Re: Default policy for iptables built-in chains...
On Sun, Oct 07, 2007 at 10:13:33PM +0100, Andrew Suffield wrote:> > I hadn''t actually seen that article before. It''s worth noting that > since shorewall doesn''t contain any library dependencies, you can > usually grab the shorewall package from unstable and install it on a > stable system without any trouble. That''s what I do on all my complex > firewalls, eliminating the problem of the old packages in stable. (The > simple desktop-to-DSL NAT firewalls that go all over the place run > quite happily with the stable packages. I think I even still have a > couple still running shorewall 2.x, and they probably haven''t even > been rebooted since that was current - their function is so trivial > that there''s just no reason to bother upgrading them) >Right. I will add a note about pinning to the version in unstable.> Uncertain how this will work with shorewall-perl, I can''t tell until > Lorenzo gets around to packaging it. But I don''t forsee any particular > difficulties in doing the same thing. >I agree. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Roberto C. Sánchez wrote:> On Sun, Oct 07, 2007 at 11:32:23AM +1000, Paul Gear wrote: >> So one thing on my mind lately is to provide a deb/apt repository that >> people could use to supplement their Debian/Ubuntu system and override >> the Debian packages with more recent Shorewall packages. I have a few >> of my own packages that i maintain in a personal repository, and i don''t >> think it would be too hard to extend my scripts to build Shorewall from >> release tarballs and SVN. These could then be mirrored onto the main >> web site and provided for public use. >> > I think that this could be dangerous. I''d much rather see the official > Debian package get "fixed". The reason is that Debian users expect > (well, at least most of them do) that packages will strictly adhere to > Debian policy. Now, in some cases, this creates a conflict between the > "Debian" way and what the upstream developers consider to be right. > > Personally, having nearly all of my systems installed with Debian, I am > more concerned with Debian packages being policy compliant and > consistent than I am with some other things.Let''s put aside the issue of whether the init script should do the same thing as the shorewall command. The thing i''m really concerned about is that Debian users don''t have access to the latest stable versions of Shorewall in a native packaging format. At the moment, if i want to deploy Shorewall on a customer system, i recommend SUSE (openSUSE or SLES) because it''s the platform that works the best with the RPMS. We are not going to "fix" Debian policy about application versions in this respect, because it''s not "broken". Debian''s policy on which versions to include is working as designed - the problem as i see it is that their release schedule doesn''t match Tom''s, and this creates support problems for Shorewall. I personally would prefer to be running the latest stable version of Shorewall on most of my systems (and probably the latest svn version on my home gateway), but because i don''t want the hassle of maintaining tarball-based installs, i stick with the version in etch (3.2.6). (Sarge uses Shorewall 2.2.3!) That''s why i think the best compromise would be to maintain a Debian repository for the project that keeps up to date with Shorewall''s stable version, and ensure that this package is fully Debian-compliant, so that people can smoothly integrate the latest Shorewall versions into their Debian systems. (We should start with the packages that Lorenzo has created to ensure maximum compatibility.) -- Paul <http://paul.gear.dyndns.org> ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Paul Gear wrote:> > That''s why i think the best compromise would be to maintain a Debian > repository for the project that keeps up to date with Shorewall''s stable > version, and ensure that this package is fully Debian-compliant, so that > people can smoothly integrate the latest Shorewall versions into their > Debian systems. (We should start with the packages that Lorenzo has > created to ensure maximum compatibility.) >I think this is the right approach. The differences between the Debian packages and standard Shorewall can be worked around with documentation. Not having current packages to offer Debian users creates problems for those users and for those of us who are trying to support them. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Roberto C. Sánchez
2007-Oct-08 01:18 UTC
Re: Default policy for iptables built-in chains...
On Mon, Oct 08, 2007 at 10:12:53AM +1000, Paul Gear wrote:> > Let''s put aside the issue of whether the init script should do the same > thing as the shorewall command. >Agreed.> The thing i''m really concerned about is that Debian users don''t have > access to the latest stable versions of Shorewall in a native packaging > format. At the moment, if i want to deploy Shorewall on a customer > system, i recommend SUSE (openSUSE or SLES) because it''s the platform > that works the best with the RPMS. >This concerns me as well.> We are not going to "fix" Debian policy about application versions in > this respect, because it''s not "broken". Debian''s policy on which > versions to include is working as designed - the problem as i see it is > that their release schedule doesn''t match Tom''s, and this creates > support problems for Shorewall. >I would have to agree that Tom is a fiend when it comes to releases :-) I don''t know of any other substantial project that releases as often (except maybe Linux).> I personally would prefer to be running the latest stable version of > Shorewall on most of my systems (and probably the latest svn version on > my home gateway), but because i don''t want the hassle of maintaining > tarball-based installs, i stick with the version in etch (3.2.6). > (Sarge uses Shorewall 2.2.3!) >Well, sure. Look at Etch, for instance. It was frozen on 11 December 2006. The first 3.4 release was not made until mid-March 2007. There was no way that a new "major" upstream version was going to make it during the freeze. Now, depending on how "major" the changes were, it may have been possible to continue the releases under the 3.2 line. However, that is sort of allowing the downstream to dictate how the upstream works, which is probably not always right.> That''s why i think the best compromise would be to maintain a Debian > repository for the project that keeps up to date with Shorewall''s stable > version, and ensure that this package is fully Debian-compliant, so that > people can smoothly integrate the latest Shorewall versions into their > Debian systems. (We should start with the packages that Lorenzo has > created to ensure maximum compatibility.) >Please don''t misunderstand me. I am not strictly opposed to this. However, I think that the first step would be to ask Lorenzo to either relinquish the shorewall packages (Andrew and I are both Debian developers and he if is not willing/able to maintain or co-maintain the packages, I certainly would be; I don''t mean to insult you Andrew, I just don''t want to speak for you without knowing). Failing that, perhaps inviting Lorenzo to be more involved in the upstream development would probably result in better packages and also Debian more closely tracking the upstream releases. If we can get that, then it would be possible to just tell people to pin their shorewall packages to unstable. If we have a hand in the packaging, we can always make sure that the unstable version also works in stable. Of course, if Lorenzo does not wish to give up the packages nor to get involved in the upstream development, then I think setting up our own little repository would be acceptable. However, I''d like to try the other two options first. Now, Lorenzo was previously fairly responsive. In fact, I remember prior to the release of Etch helping test his 3.2.6 packages on some of my servers. (Yes, Tom, those are the servers that are still running 3.2.6 :-p). Anyhow, we need to find someone well respected who has been involved in Shorewall development for some amount of time (and who lives near Seattle) to approach Lorenzo. I think that person should be Tom. :-) Lorenzo seemed like a fairly reasonable fellow when I corresponded with him previously. I don''t think he would be greatly opposed to anything which results in better Debian packages. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
On Sun, Oct 07, 2007 at 09:18:19PM -0400, Roberto C. S?nchez wrote:> > That''s why i think the best compromise would be to maintain a Debian > > repository for the project that keeps up to date with Shorewall''s stable > > version, and ensure that this package is fully Debian-compliant, so that > > people can smoothly integrate the latest Shorewall versions into their > > Debian systems. (We should start with the packages that Lorenzo has > > created to ensure maximum compatibility.) > > > Please don''t misunderstand me. I am not strictly opposed to this. > However, I think that the first step would be to ask Lorenzo to either > relinquish the shorewall packages (Andrew and I are both Debian > developers and he if is not willing/able to maintain or co-maintain the > packages, I certainly would be; I don''t mean to insult you Andrew, I > just don''t want to speak for you without knowing).I retired from Debian years ago.> Failing that, perhaps inviting Lorenzo to be more involved in the > upstream development would probably result in better packages and also > Debian more closely tracking the upstream releases. > > If we can get that, then it would be possible to just tell people to pin > their shorewall packages to unstable. If we have a hand in the > packaging, we can always make sure that the unstable version also works > in stable.This is almost certainly a better idea. Debian''s more than just a bunch of rules; you can''t really duplicate what it does in an external effort. More than anything else, having hundreds of highly skilled people looking at things is what really makes Debian work the way it does. There are several measures in place to deal with packages that are both fast-moving and reasonably reliable, they just need to be used; it would be straightforward to include shorewall in volatile-sloppy, for example. The package needs either more manpower or more attention, it should be easy to sort out. The procedure for dealing with these things is detailed here: http://www.debian.org/doc/developers-reference/ch-beyond-pkging.en.html#s-mia-qa Just follow it. These things can usually be sorted out fairly quickly, so long as somebody (preferably within Debian) kicks the process into action - it''s presumed that if nobody is making any noise about it, it cannot possibly be important enough to bother with. Start by hunting down Lorenzo and finding out what''s going on. He''s a relatively new developer and was a student when he signed up; people like that very frequently graduate and then find they lack time to work on Debian stuff. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Roberto C. Sánchez
2007-Oct-08 12:36 UTC
Re: Default policy for iptables built-in chains...
On Mon, Oct 08, 2007 at 01:07:59PM +0100, Andrew Suffield wrote:> > > > > Please don''t misunderstand me. I am not strictly opposed to this. > > However, I think that the first step would be to ask Lorenzo to either > > relinquish the shorewall packages (Andrew and I are both Debian > > developers and he if is not willing/able to maintain or co-maintain the > > packages, I certainly would be; I don''t mean to insult you Andrew, I > > just don''t want to speak for you without knowing). > > I retired from Debian years ago. >My mistake. You are still in db.debian.org and your last seen was fairly recent. I apologize for the misunderstanding.> > Failing that, perhaps inviting Lorenzo to be more involved in the > > upstream development would probably result in better packages and also > > Debian more closely tracking the upstream releases. > > > > If we can get that, then it would be possible to just tell people to pin > > their shorewall packages to unstable. If we have a hand in the > > packaging, we can always make sure that the unstable version also works > > in stable. > > This is almost certainly a better idea. Debian''s more than just a > bunch of rules; you can''t really duplicate what it does in an external > effort. More than anything else, having hundreds of highly skilled > people looking at things is what really makes Debian work the way it > does. There are several measures in place to deal with packages that > are both fast-moving and reasonably reliable, they just need to be > used; it would be straightforward to include shorewall in > volatile-sloppy, for example. > > The package needs either more manpower or more attention, it should be > easy to sort out. The procedure for dealing with these things is > detailed here: > > http://www.debian.org/doc/developers-reference/ch-beyond-pkging.en.html#s-mia-qa > > Just follow it. These things can usually be sorted out fairly quickly, > so long as somebody (preferably within Debian) kicks the process into > action - it''s presumed that if nobody is making any noise about it, it > cannot possibly be important enough to bother with. > > Start by hunting down Lorenzo and finding out what''s going on. He''s a > relatively new developer and was a student when he signed up; people > like that very frequently graduate and then find they lack time to > work on Debian stuff. >OK. I will approach Lorenzo again. My last few mails and bug report follow-ups have been answered, though. So, he may truly be MIA. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Roberto C. Sánchez wrote:>> >> Start by hunting down Lorenzo and finding out what''s going on. He''s a >> relatively new developer and was a student when he signed up; people >> like that very frequently graduate and then find they lack time to >> work on Debian stuff.At the time that Lorenzo did a 3.4 package, he was in Graduate school and was having difficulty finding time for Shorewall.>> > OK. I will approach Lorenzo again. My last few mails and bug report > follow-ups have been answered, though. So, he may truly be MIA. >Did you mean to say, "..have not been answered..."? I also sent a mail to Lorenzo over the weekend; so far, no response. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net PGP Public Key \ https://lists.shorewall.net/teastep.pgp.key ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
Roberto C. Sánchez
2007-Oct-08 14:54 UTC
Re: Default policy for iptables built-in chains...
On Mon, Oct 08, 2007 at 07:28:39AM -0700, Tom Eastep wrote:> Roberto C. Sánchez wrote: > >> > >> Start by hunting down Lorenzo and finding out what''s going on. He''s a > >> relatively new developer and was a student when he signed up; people > >> like that very frequently graduate and then find they lack time to > >> work on Debian stuff. > > At the time that Lorenzo did a 3.4 package, he was in Graduate school and > was having difficulty finding time for Shorewall. >I see.> >> > > OK. I will approach Lorenzo again. My last few mails and bug report > > follow-ups have been answered, though. So, he may truly be MIA. > > > > Did you mean to say, "..have not been answered..."? I also sent a mail to > Lorenzo over the weekend; so far, no response. >Yes. I mistyped. I will email him shortly and see what comes of it. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/