Beta 5 is now available for testing.
Problems Corrected:
1) Previously, when a device number was explicitly specified in
/etc/shorewall/tcdevices, all unused numbers less than the one
specified were unavailable for allocation to following entries that
did not specify a number. Now, the compiler selects the lowest
unallocated number when no device number is explicitly allocated.
2) Network developers have discovered an exploit that allows hosts to
poke holes in a firewall under some circumstances. The known ways
to protect against the exploit are:
a) rt_filter (Shorewall''s routefilter). Only applicable to IPv4
and can''t be used with some multi-ISP configurations.
b) Insert a DROP rule that prevents hairpinning (routeback). The
rule must be inserted before any ESTABLISHED,RELATED firewall
rules. This approach is not appropriate for bridges and other
cases where the ''routeback'' option is specified or
implied.
For non-routeback interfaces, Shorewall and Shorewall6 will insert
a hairpin rule, provided that the routefilter option is not
specified. The rule will dispose of hairpins according to the
setting of two new options in shorewall.conf and shorewall6.conf:
FILTER_LOG_LEVEL
Specifies the logging level; default is ''info''. To omit
logging, specify FILTER_LOG_LEVEL=none.
FILTER_DISPOSITION
Specifies the disposition. Default is DROP and the possible
values are DROP, A_DROP, REJECT and A_REJECT.
To deal with bridges and other routeback interfaces , there is now
a ''filter'' option in /shorewall/interfaces and
/etc/shorewall6/interfaces.
The value of the ''filter'' option is a list of network
addresses
enclosed in in parentheses. Where only a single address is listed,
the parentheses may be omitted. When a packet from a filtered
address is received on the interface, it is disposed of based on
the new FILTER_ options described above.
For a bridge or other routeback interface, you should list all of
your other local networks (those networks not attached to the
bridge) in the bridge''s filter list.
Example:
My DMZ is 2001:470:b:227::40/124
My local interface (br1) is a bridge.
In /etc/shorewall6/interfaces, I have:
#ZONE INTERFACE BROADCAST OPTIONS
loc br1 - filter=2001:470:b:227::40/124
3) A defect introduced in Beta 3 that resulted in Internal Errors in
the compiler has been corrected.
New Features:
1) The new auditing actions and macros introduced in Beta 4 have been
renamed by adding an underscore (''_'') after the leading A.
For
example, ADrop is now A_Drop.
2) Shorewall and Shorewall6 no longer depend on ''make''.
3) A ''-T'' (trace) option has been added to the
''check'' and ''compile''
commands. When a warning or error message is generated, a Perl
stack trace is included to aid in isolating the source of the
message.
Thank you for testing,
-Tom
--
Tom Eastep \ When I die, I want to go like my Grandfather who
Shoreline, \ died peacefully in his sleep. Not screaming like
Washington, USA \ all of the passengers in his car
http://shorewall.net \________________________________________________
------------------------------------------------------------------------------
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery,
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now.
http://p.sf.net/sfu/quest-d2dcopy1
> 1) Previously, when a device number was explicitly specified in > /etc/shorewall/tcdevices, all unused numbers less than the one > specified were unavailable for allocation to following entries that > did not specify a number. Now, the compiler selects the lowest > unallocated number when no device number is explicitly allocated. >That works.> 2) Network developers have discovered an exploit that allows hosts to > poke holes in a firewall under some circumstances. The known ways > to protect against the exploit are: >How do I know if I am "affected" by this? I have various "routefilter" options in my interfaces file (ranging from routefilter to routefilter=2). Regardless of whether I have "routefilter" or "routefilter=2" shorewall creates a "filter" chain with 0 references in it. Don''t know why that is or if it is supposed to be this way?> FILTER_LOG_LEVEL > Specifies the logging level; default is ''info''. To omit > logging, specify FILTER_LOG_LEVEL=none. >Have this set as the default (=info)> FILTER_DISPOSITION > Specifies the disposition. Default is DROP and the possible > values are DROP, A_DROP, REJECT and A_REJECT. >Have this set as A_DROP.> 1) The new auditing actions and macros introduced in Beta 4 have been > renamed by adding an underscore (''_'') after the leading A. For > example, ADrop is now A_Drop. >That works with the new names. I also found the following: 1. USE_ACTIONS is not present in the "default" shorewall.conf (the one supplied with either the source or the rpm file) - it needs to be added. 2. There is a syntax error in man shorewall.conf (LEGACY_FASTSTART section) - "/etc/shorewall are compare with " should be "/etc/shorewall are compared with " 3. The following problem which I reported in Beta4 is still there - A_ACCEPT, A_DROP and/or A_REJECT assume comments from the first action (normally in Drop and Reject) which calls them, which is wrong. Example: If I have A_AllowICMPs, Auth(A_REJECT) and A_DropUPnP in my Drop action the following chains are produced by shorewall: Chain A_ACCEPT (4 references) pkts bytes target prot opt in out source destination 0 0 AUDIT all -- * * 0.0.0.0/0 0.0.0.0/0 /* Needed ICMP types */ AUDIT accept 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 /* Needed ICMP types */ Chain A_DROP (9 references) pkts bytes target prot opt in out source destination 0 0 AUDIT all -- * * 0.0.0.0/0 0.0.0.0/0 /* UPnP */ AUDIT drop 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 /* UPnP */ Chain A_REJECT (2 references) pkts bytes target prot opt in out source destination 0 0 AUDIT all -- * * 0.0.0.0/0 0.0.0.0/0 /* Auth */ AUDIT reject 0 0 reject all -- * * 0.0.0.0/0 0.0.0.0/0 [goto] /* Auth */ The comments of which are, of course, utter nonsense! These should not be there at all! 4. Not a bug, but a suggestion. Every time I upgrade shorewall I am spending time executing diff and peeling my eyes out to see what new options have been introduced and what options, if any, have been deprecated. This exercise is very much prone to errors and I believe there is a simpler and better solution to this, which could be done "automagically" without much fuss. - Create (and distribute) shorewall.conf.default, which contains all shorewall.conf options with their default values for the current shorewall version being distributed; - Create (and distribute) shorewall.conf.template which also contains all available options for the shorewall version being distributed, but lists their "values" in the following manner: USE_ACTIONS=$USE_ACTIONS LEGACY_FASTSTART=$LEGACY_FASTSTART ... - Create a shell script which: 1). simply reads shorewall.conf.default as a shell source, so that all "variables" listed there are "defined" and have their values loaded up. 2). check to see if shorewall.conf exists (from a previous shorewall version perhaps) and if that is the case read this file also as a shell source, so that the variables previously "defined" in shorewall.conf.default get overwritten from the existing shorewall.conf 3). use shorewall.conf.template to output all shorewall.conf variables with their values and redirect this output to shorewall.conf - Job done and I don''t have to spend any more time diff-ing old and new shorewall configs ever! ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1
On 5/27/11 7:51 PM, Tom Eastep wrote:> On 5/27/11 6:11 PM, Mr Dash Four wrote: > >> That works. >> >>> 2) Network developers have discovered an exploit that allows hosts to >>> poke holes in a firewall under some circumstances. The known ways >>> to protect against the exploit are: >>> >> How do I know if I am "affected" by this? I have various "routefilter" >> options in my interfaces file (ranging from routefilter to >> routefilter=2).If you have neither IPv6 nor routeback interfaces, then you are not affected.>> Regardless of whether I have "routefilter" or >> "routefilter=2" shorewall creates a "filter" chain with 0 references in >> it. Don''t know why that is or if it is supposed to be this way?It would be deleted if you had specified a sufficient value for OPTIMIZE in shorewall.conf. But in RC1, I will add code to delete it if it isn''t referenced, regardless of optimization level.>> I also found the following: >> >> 1. USE_ACTIONS is not present in the "default" shorewall.conf (the one >> supplied with either the source or the rpm file) - it needs to be added.That''s good since the option was obsoleted with the release of Shorewall-perl> >> 2. There is a syntax error in man shorewall.conf (LEGACY_FASTSTART >> section) - "/etc/shorewall are compare with " should be "/etc/shorewall >> are compared with "Your two quoted strings are identical, AFAICS. But if you are complaining about the use of the plural ''are'', there are multiple modification times associated with a directory (the directory and each of its subordinate directories and files).>> 3. The following problem which I reported in Beta4 is still there - >> A_ACCEPT, A_DROP and/or A_REJECT assume comments from the first action >> (normally in Drop and Reject) which calls them, which is wrong. Example: >> >> If I have A_AllowICMPs, Auth(A_REJECT) and A_DropUPnP in my Drop action >> the following chains are produced by shorewall: >> >> Chain A_ACCEPT (4 references) >> pkts bytes target prot opt in out source destination >> 0 0 AUDIT all -- * * 0.0.0.0/0 0.0.0.0/0 /* Needed ICMP types */ AUDIT >> accept >> 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 /* Needed ICMP types */ >> >> Chain A_DROP (9 references) >> pkts bytes target prot opt in out source destination >> 0 0 AUDIT all -- * * 0.0.0.0/0 0.0.0.0/0 /* UPnP */ AUDIT drop >> 0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 /* UPnP */ >> >> Chain A_REJECT (2 references) >> pkts bytes target prot opt in out source destination >> 0 0 AUDIT all -- * * 0.0.0.0/0 0.0.0.0/0 /* Auth */ AUDIT reject >> 0 0 reject all -- * * 0.0.0.0/0 0.0.0.0/0 [goto] /* Auth */ >> >> The comments of which are, of course, utter nonsense! These should not >> be there at all! >Give that you were eager to test and I have a full-time job unrelated to networking, I released the beta without the attached patch.> >> >> 4. Not a bug, but a suggestion. >> >> Every time I upgrade shorewall I am spending time executing diff and >> peeling my eyes out to see what new options have been introduced and >> what options, if any, have been deprecated. This exercise is very much >> prone to errors and I believe there is a simpler and better solution to >> this, which could be done "automagically" without much fuss. >> >> - Create (and distribute) shorewall.conf.default, which contains all >> shorewall.conf options with their default values for the current >> shorewall version being distributed; >> >> - Create (and distribute) shorewall.conf.template which also contains >> all available options for the shorewall version being distributed, but >> lists their "values" in the following manner: >> USE_ACTIONS=$USE_ACTIONS >> LEGACY_FASTSTART=$LEGACY_FASTSTART >> ... >> >> - Create a shell script which: >> 1). simply reads shorewall.conf.default as a shell source, so that all >> "variables" listed there are "defined" and have their values loaded up. >> 2). check to see if shorewall.conf exists (from a previous shorewall >> version perhaps) and if that is the case read this file also as a shell >> source, so that the variables previously "defined" in >> shorewall.conf.default get overwritten from the existing shorewall.conf >> 3). use shorewall.conf.template to output all shorewall.conf variables >> with their values and redirect this output to shorewall.conf >> >> - Job done and I don''t have to spend any more time diff-ing old and new >> shorewall configs ever!Contributions cheerfully accepted. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1
On 05/27/2011 08:11 PM, Tom Eastep wrote:> On 5/27/11 7:51 PM, Tom Eastep wrote: >> On 5/27/11 6:11 PM, Mr Dash Four wrote: >>> 4. Not a bug, but a suggestion. >>> >>> Every time I upgrade shorewall I am spending time executing diff and >>> peeling my eyes out to see what new options have been introduced and >>> what options, if any, have been deprecated. This exercise is very much >>> prone to errors and I believe there is a simpler and better solution to >>> this, which could be done "automagically" without much fuss.I think this topic warrents further discussion. The philosophy of shorewall.conf has always been that if you don''t change it during an upgrade, then the behavior of your firewall won''t change (fully backward compatible). So the default (value assigned when the option does not appear in the file or is supplied with an empty value) is chosen to achieve backward compatibility. I used to assign a different value in shorewall.conf when I wanted new users to experience behavior different from the default. I gave that up, however, because people seem bound and determined to do what you are apparently doing and add every new option to your existing shorewall.conf with the value defined in mine. This lead to many laments of "I upgraded and you broke my firewall". So now, new options in shorewall.conf always get their compiler-defaulted values and I only assign a different value in the sample configurations.>>> - Create (and distribute) shorewall.conf.default, which contains all >>> shorewall.conf options with their default values for the current >>> shorewall version being distributed;The shorewall.conf in the tarball is presumably this file.>>> >>> - Create (and distribute) shorewall.conf.template which also contains >>> all available options for the shorewall version being distributed, but >>> lists their "values" in the following manner: >>> USE_ACTIONS=$USE_ACTIONS >>> LEGACY_FASTSTART=$LEGACY_FASTSTART >>> ... >>> >>> - Create a shell script which: >>> 1). simply reads shorewall.conf.default as a shell source, so that all >>> "variables" listed there are "defined" and have their values loaded up. >>> 2). check to see if shorewall.conf exists (from a previous shorewall >>> version perhaps) and if that is the case read this file also as a shell >>> source, so that the variables previously "defined" in >>> shorewall.conf.default get overwritten from the existing shorewall.conf >>> 3). use shorewall.conf.template to output all shorewall.conf variables >>> with their values and redirect this output to shorewall.conf >>> >>> - Job done and I don''t have to spend any more time diff-ing old and new >>> shorewall configs ever!Again, I question why this is necessary. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1
> The philosophy of shorewall.conf has always been that if you don''t > change it during an upgrade, then the behavior of your firewall won''t > change (fully backward compatible). So the default (value assigned when > the option does not appear in the file or is supplied with an empty > value) is chosen to achieve backward compatibility. >I agree with that. There is a difference, however, between "default value assigned in shorewall.conf" and "using default value" and that difference is that unless I see it in shorewall.conf for me this option does not exist and if it does not exist I wouldn''t know about it (a bit like your FAKE_AUDIT option really - unless I read that post from you on this list, I wouldn''t have known about this option, which I don''t think is right - that''s a bit Microsoft like!).> So now, new options in shorewall.conf always get their > compiler-defaulted values and I only assign a different value in the > sample configurations. >What do you mean - that the sample shorewall.conf provided with the shorewall package does not contain the "default" values?>>>> - Create (and distribute) shorewall.conf.default, which contains all >>>> shorewall.conf options with their default values for the current >>>> shorewall version being distributed; >>>> > > The shorewall.conf in the tarball is presumably this file. >Yep! I have, however, changed that as of today.>>>> - Create (and distribute) shorewall.conf.template which also contains >>>> all available options for the shorewall version being distributed, but >>>> lists their "values" in the following manner: >>>> USE_ACTIONS=$USE_ACTIONS >>>> LEGACY_FASTSTART=$LEGACY_FASTSTART >>>> ... >>>> >>>> - Create a shell script which: >>>> 1). simply reads shorewall.conf.default as a shell source, so that all >>>> "variables" listed there are "defined" and have their values loaded up. >>>> 2). check to see if shorewall.conf exists (from a previous shorewall >>>> version perhaps) and if that is the case read this file also as a shell >>>> source, so that the variables previously "defined" in >>>> shorewall.conf.default get overwritten from the existing shorewall.conf >>>> 3). use shorewall.conf.template to output all shorewall.conf variables >>>> with their values and redirect this output to shorewall.conf >>>> >>>> - Job done and I don''t have to spend any more time diff-ing old and new >>>> shorewall configs ever! >>>> > > Again, I question why this is necessary. >My view is that all available options should be listed in shorewall.conf and visible to users, like myself, so that I know what I have - both in terms of capabilities, as well as functionality (old and new). The old settings should be respected, the new ones should also be present, so that when I go through the config file and see an option I don''t know about I look at its value, check the manual and alter it, if necessary. If I can''t see that option I cannot do that and I am not that smart to remember *all* options listed in the shorewall.conf man page as well as those in my shorewall.conf file so that I could compare and see what is missing - that ain''t happening. So, what I did a couple of hours ago is discarded the notion of "shorewall.conf" completely and replaced it with "shorewall.default", introduced "shorewall.template", devised a small %postun script, which merges "shorewall.default" with my existing shorewall.conf (if it exists from the previous installation), thus honouring my old settings, while "piping" this through "shorewall.template" creating final version of shorewall.conf, while preserving the old as shorewall.conf.org - just in case. I also devised a separate shell script, which is installed as part of that package and it serves a similar purpose to my %postun routine in that it provides additional functionality for those occasions where shorewall.conf is not in its "standard" location (i.e. /etc/shorewall) so that it could be run separately by the user merging both old and new configs respecting the old values. It works a treat, so I am more than happy to continue using it. ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1
On 5/28/11 8:16 AM, Mr Dash Four wrote:> >> The philosophy of shorewall.conf has always been that if you don''t >> change it during an upgrade, then the behavior of your firewall won''t >> change (fully backward compatible). So the default (value assigned when >> the option does not appear in the file or is supplied with an empty >> value) is chosen to achieve backward compatibility. >> > I agree with that. There is a difference, however, between "default > value assigned in shorewall.conf" and "using default value" and that > difference is that unless I see it in shorewall.conf for me this option > does not exist and if it does not exist I wouldn''t know about it (a bit > like your FAKE_AUDIT option really - unless I read that post from you on > this list, I wouldn''t have known about this option, which I don''t think > is right - that''s a bit Microsoft like!). > >> So now, new options in shorewall.conf always get their >> compiler-defaulted values and I only assign a different value in the >> sample configurations. >> > What do you mean - that the sample shorewall.conf provided with the > shorewall package does not contain the "default" values?Those in the Samples directory do not contain the "default" values. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1
> Those in the Samples directory do not contain the "default" values. >Whatever. ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1
On 5/28/11 8:16 AM, Mr Dash Four wrote:>> > My view is that all available options should be listed in shorewall.conf > and visible to users, like myself, so that I know what I have - both in > terms of capabilities, as well as functionality (old and new). The old > settings should be respected, the new ones should also be present, so > that when I go through the config file and see an option I don''t know > about I look at its value, check the manual and alter it, if necessary. > > If I can''t see that option I cannot do that and I am not that smart to > remember *all* options listed in the shorewall.conf man page as well as > those in my shorewall.conf file so that I could compare and see what is > missing - that ain''t happening. > > So, what I did a couple of hours ago is discarded the notion of > "shorewall.conf" completely and replaced it with "shorewall.default", > introduced "shorewall.template", devised a small %postun script, which > merges "shorewall.default" with my existing shorewall.conf (if it exists > from the previous installation), thus honouring my old settings, while > "piping" this through "shorewall.template" creating final version of > shorewall.conf, while preserving the old as shorewall.conf.org - just in > case. > > I also devised a separate shell script, which is installed as part of > that package and it serves a similar purpose to my %postun routine in > that it provides additional functionality for those occasions where > shorewall.conf is not in its "standard" location (i.e. /etc/shorewall) > so that it could be run separately by the user merging both old and new > configs respecting the old values. It works a treat, so I am more than > happy to continue using it.Okay -- I''ve been doing a little scripting today too. The result of that scripting is that: a) shorewall.conf and shorewall6.conf must have the same options or my build fails. b) shorewall.conf is annotated with the manpage text (see attached). There is also a shorewall.conf.default in the tarball for those who prefer to not have the manpage merged with the config file. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1
On 5/28/11 4:00 PM, Tom Eastep wrote:> Okay -- I''ve been doing a little scripting today too. The result of that > scripting is that: > > a) shorewall.conf and shorewall6.conf must have the same options or my > build fails.That should have been shorewall.conf and ''man shorewall.conf''. I''ve completed the work now and the Samples are annotated in the same way as the main shorewall.conf file. All of the .conf files have exactly the same entries as their associated manpage and are annotated with the manpage in the style of the early preview that I posted earlier. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1
On 5/28/11 9:51 PM, Tom Eastep wrote:> On 5/28/11 4:00 PM, Tom Eastep wrote: > >> Okay -- I''ve been doing a little scripting today too. The result of that >> scripting is that: >> >> a) shorewall.conf and shorewall6.conf must have the same options or my >> build fails. > > That should have been shorewall.conf and ''man shorewall.conf''. > I''ve completed the work now and the Samples are annotated in > the same way as the main shorewall.conf file. > > All of the .conf files have exactly the same entries as their > associated manpage and are annotated with the manpage in the > style of the early preview that I posted earlier.Here''s the final file. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1
Tom Using kernel 2.6.39, iptables 1.4.10 and xtables-addons 1.35 The following rules file entry: ACCEPT $FW lan tcp 22 - - - !root:root produces the following iptables rule: -A fw2lan -p 6 --dport 22 -m owner ! --uid-owner root ! --gid-owner root -j ACCEPT Which works. After upgrading iptables to 1.4.11 the following iptables-restore error is produced: iptables-restore v1.4.11: owner: option "--uid-owner" cannot be inverted. The following tcrules file entry: IPMARK(dst,-1,-64) $FW eth1 tcp 888 produces the following iptables rule: -A OUTPUT -p 6 --dport 888 -o eth1 -j IPMARK --addr dst --and-mask -1 --or-mask -64 --shift 0 Which works. After upgrading to iptables 1.4.11 the following iptables-restore error is produced: iptables-restore v1.4.11: IPMARK: Bad value for "and-mask" option: "-1" Steven. ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1
Tom Using kernel 2.6.39, iptables 1.4.11 and xtables-addons 1.35 If the config. does not have a capabilities file, the following policy works: all all DROP:audit warn If a capabilities file is created, the following error message is produced: ERROR: :audit requires AUDIT Target in your kernel and iptables : /etc/shorewallBBB/policy (line 13) A copy of the capabilities file is attached. I have manually entered the following iptables rule to confirm that the audit feature is working: iptables -A INPUT -j AUDIT --type drop Steven. ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1
On 5/29/11 7:01 AM, Steven Jan Springl wrote:> Using kernel 2.6.39, iptables 1.4.10 and xtables-addons 1.35 > > The following rules file entry: > > ACCEPT $FW lan tcp 22 - - - !root:root > > produces the following iptables rule: > > -A fw2lan -p 6 --dport 22 -m owner ! --uid-owner root ! --gid-owner root -j > ACCEPT > > Which works. > After upgrading iptables to 1.4.11 the following iptables-restore error is > produced: > > iptables-restore v1.4.11: owner: option "--uid-owner" cannot be inverted.Jan Engelhardt (Netfilter developer) has confirmed that this is an iptables 1.4.11 bug.> > > The following tcrules file entry: > > IPMARK(dst,-1,-64) $FW eth1 tcp 888 > > produces the following iptables rule: > > -A OUTPUT -p 6 --dport 888 -o eth1 -j IPMARK --addr > dst --and-mask -1 --or-mask -64 --shift 0 > > Which works. > After upgrading to iptables 1.4.11 the following iptables-restore error is > produced: > > iptables-restore v1.4.11: IPMARK: Bad value for "and-mask" option: "-1"The attached patch should catch this one. Thanks, Steven -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1
On 5/29/11 7:54 AM, Tom Eastep wrote:> On 5/29/11 7:01 AM, Steven Jan Springl wrote: > >> Using kernel 2.6.39, iptables 1.4.10 and xtables-addons 1.35 >> >> The following rules file entry: >> >> ACCEPT $FW lan tcp 22 - - - !root:root >> >> produces the following iptables rule: >> >> -A fw2lan -p 6 --dport 22 -m owner ! --uid-owner root ! --gid-owner root -j >> ACCEPT >> >> Which works. >> After upgrading iptables to 1.4.11 the following iptables-restore error is >> produced: >> >> iptables-restore v1.4.11: owner: option "--uid-owner" cannot be inverted. > > Jan Engelhardt (Netfilter developer) has confirmed that this is an > iptables 1.4.11 bug. > >> >> >> The following tcrules file entry: >> >> IPMARK(dst,-1,-64) $FW eth1 tcp 888 >> >> produces the following iptables rule: >> >> -A OUTPUT -p 6 --dport 888 -o eth1 -j IPMARK --addr >> dst --and-mask -1 --or-mask -64 --shift 0 >> >> Which works. >> After upgrading to iptables 1.4.11 the following iptables-restore error is >> produced: >> >> iptables-restore v1.4.11: IPMARK: Bad value for "and-mask" option: "-1" > > The attached patch should catch this one.I actually prefer this patch. It allows you to specify negative numbers for the masks (which may be helpful) and converts them into 32-bit hex numbers. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1
On 5/29/11 8:03 AM, Tom Eastep wrote:> I actually prefer this patch. It allows you to specify negative numbers > for the masks (which may be helpful) and converts them into 32-bit hex > numbers.Three''s the charm, I guess. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1
On Sunday 29 May 2011 16:26:11 Tom Eastep wrote:> On 5/29/11 8:03 AM, Tom Eastep wrote: > > I actually prefer this patch. It allows you to specify negative numbers > > for the masks (which may be helpful) and converts them into 32-bit hex > > numbers. > > Three''s the charm, I guess. > > -TomTom Sorry for the delay in getting back to you. It''s been a bit chaotic here today. I can confirm the patch works. I can also confirm the UID patch works. Thanks. Steven. ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1
On Sunday 29 May 2011 21:46:09 Steven Jan Springl wrote:> On Sunday 29 May 2011 16:26:11 Tom Eastep wrote: > > On 5/29/11 8:03 AM, Tom Eastep wrote: > > > I actually prefer this patch. It allows you to specify negative numbers > > > for the masks (which may be helpful) and converts them into 32-bit hex > > > numbers. > > > > Three''s the charm, I guess. > > > > -Tom > > Tom > > Sorry for the delay in getting back to you. It''s been a bit chaotic here > today. > > I can confirm the patch works. I can also confirm the UID patch works. > Thanks. > > Steven. >Tom When tcrules file contains: IPMARK(dst,0X880,0xcc00,124) $FW eth1 the following messages are produced: Argument "0X880" isn''t numeric in bitwise and (&) at /usr/share/shorewall/Shorewall/Tc.pm line 334, <$currentfile> line 15. Argument "0xcc00" isn''t numeric in bitwise and (&) at /usr/share/shorewall/Shorewall/Tc.pm line 340, <$currentfile> line 15. Steven. ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1
> Here''s the final file. >OK, I am attaching quite a few files to this post, so hopefully the mailing list daemon won''t moan too much. If it does, then I am going to have to attach these again in a private email. I have created the following files, which I have used to install and configure my shorewall yesterday: 1. shorewall.default - contains shorewall.conf''s "default" options as per the file you enclosed in your previous post. These are used to construct the final shorewall.conf (see below); 2. shorewall.template - template to be used to "transform" the values and produce the final shorewall.conf; 3. shorewall-terse.template - another template, which does not contain any comments at all (may be suitable to "experts" who think they know what they are doing); 4. update-shorewall-config - a shell script, which does the donkey work of transforming shorewall.conf options (whether from an old shorewall.conf, "shorewal.default", or both, giving preference to the values present in the old shorewall.conf - in other words, if option is specified in both the existing "shorewall.conf" and "shorewall.default" then the value of that option specified in the old "shorewall.conf" takes precedence) and produces a final "shorewall.conf", based on one of the two templates specified above ("shorewall.template" or "shorewall-terse.template"). From the shell script''s heading: PURPOSE: Combines all values from /etc/shorewall/shorewall.default with <old_shorewall_conf> (if specified) and then uses /etc/shorewall/shorewall[-terse].template to dump the output to <old_shorewall_conf>, renaming <old_shorewall_conf> to <old_shorewall_conf>.org, if applicable. Preference is given to the values specified in <old_shorewall_conf>. "Deprecated" options (i.e. options used in <old_shorewall_conf>, but not present in /etc/shorewall/shorewall.default) are ignored. If no <old_shorewall_conf> is specified /etc/shorewall/shorewall.conf is assumed. If /etc/shorewall/shorewall.conf does not exist, then a new /etc/shorewall/shorewall.conf is created based on values in /etc/shorewall/shorewall.default. SYNTAX: $0 [-teastep] [<old_shorewall_conf>] REQUIRES: /etc/shorewall/shorewall.default - containing all "default" values applicable to the distributed version of Shorewall; /etc/shorewall/shorewall[-terse].template - containing the template to be used during transformation; IN: "-teastep" - use the "terse" shorewall template (/etc/shorewall/shorewall-terse.template). Optional, defaults to using /etc/shorewall/shorewall.template <old_shorewall_conf> - old shorewall.conf to use. If <old_shorewall_conf> is not specified: 1) /etc/shorewall/shorewall.conf is checked and if it exists, this is then used; 2) if /etc/shorewall/shorewall.conf does not exists, then it is created based on the values in /etc/shorewall/shorewall.default, using the preselected template - /etc/shorewall/shorewal[-terse].template OUT: One of: - modified /etc/shorewall/shorewall.conf if "/etc/shorewall/shorewall.conf" exists or no <old_shorewall_conf> was specified - modified <old_shorewall_conf> For this to really work the following needs to be done: 1. The existing shorewall.conf from the distribution (configfiles/shorewall.conf) needs to be wiped out and the attached shorewall.default needs to be used instead. All references of "shorewall.conf" in install.sh need to be replaced with "shorewall.default": sed -i "s/shorewall\.conf/shorewall\.default/" install.sh 2. The two templates need to be copied where they belong - in the configfiles/ directory so that they could be used. These need to be installed in /etc/shorewall at least so that they could be used by the update-shorewall-config script. 3. The update shorewall.conf script needs to be copied to a path where it can be executed (preferably /usr/sbin - this is what I''ve done anyway) and its attributes properly set (0755 and owner as root:root for example). All of the above is done in my shorewall.spec file "automagically" when I use it to build my shorewall rpm. There is a little script in the %post section: %post if [ $1 = 1 ]; then /sbin/chkconfig --add shorewall if [ -f /etc/shorewall/shorewall.conf ]; then /usr/sbin/update-shorewall-config /etc/shorewall/shorewall.conf &> /dev/null else /usr/sbin/update-shorewall-config &> /dev/null fi fi What that does, among other things, is, it checks if there is old shorewall.conf present and if that is so, it runs the update-shorewall-config script to convert the options based on the "normal" template ("shorewall.template"). If "shorewall.conf" does *not* exists (new installation perhaps) it creates one based on "shorewall.default" and "shorewall.template". In that way there won''t be any more daft messages like "shorewall.conf has been saved as shorewall.conf.rpmnew" from the RPM engine as the file is created/modified (the old file, if exists, is still saved as shorewall.conf.org!). By adopting this, there isn''t any danger of carrying "deprecated" options (I had about 9 when I first used this) or missing on new ones released with each shorewall version. ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1
On 5/29/11 2:37 PM, Steven Jan Springl wrote:>> I can confirm the patch works. I can also confirm the UID patch works. >> Thanks. >Thanks.> > When tcrules file contains: > > IPMARK(dst,0X880,0xcc00,124) $FW eth1 > > the following messages are produced: > > Argument "0X880" isn''t numeric in bitwise and (&) > at /usr/share/shorewall/Shorewall/Tc.pm line 334, <$currentfile> line 15. > > Argument "0xcc00" isn''t numeric in bitwise and (&) > at /usr/share/shorewall/Shorewall/Tc.pm line 340, <$currentfile> line 15.For such a simple fix, I seem to be having an unusually hard time with it :-( This should eliminate the problem you''re seeing -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1
On Sunday 29 May 2011 22:51:47 Tom Eastep wrote:> On 5/29/11 2:37 PM, Steven Jan Springl wrote: > >> I can confirm the patch works. I can also confirm the UID patch works. > >> Thanks. > > Thanks. > > > When tcrules file contains: > > > > IPMARK(dst,0X880,0xcc00,124) $FW eth1 > > > > the following messages are produced: > > > > Argument "0X880" isn''t numeric in bitwise and (&) > > at /usr/share/shorewall/Shorewall/Tc.pm line 334, <$currentfile> line 15. > > > > Argument "0xcc00" isn''t numeric in bitwise and (&) > > at /usr/share/shorewall/Shorewall/Tc.pm line 340, <$currentfile> line 15. > > For such a simple fix, I seem to be having an unusually hard time with > it :-( > > This should eliminate the problem you''re seeing > > -TomTom Confirmed, that has fixed the problem. Thanks. Steven. ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1
> > Confirmed, that has fixed the problem. Thanks. >Thanks, Steven -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1
On 5/29/11 2:42 PM, Mr Dash Four wrote:> >> Here''s the final file. >> > OK, I am attaching quite a few files to this post, so hopefully the > mailing list daemon won''t moan too much. If it does, then I am going to > have to attach these again in a private email. > > I have created the following files, which I have used to install and > configure my shorewall yesterday:Thanks! I think that it is a little late in the 4.4.20 cycle to try to integrate this into that release. So I''ll hold it until I release 4.4.20 and make it the first thing that I add for 4.4.21 Beta 1. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1
> I think that it is a little late in the 4.4.20 cycle to try to integrate > this into that release. So I''ll hold it until I release 4.4.20 and make > it the first thing that I add for 4.4.21 Beta 1. >That makes no difference to me as I already use these and "reap the benefits", so to speak (I had quite a few "deprecated" options, apparently left from when I first started using shorewall and I have been carrying them since!). If/when you decide to use any of this new functionality you have to remember to change shorewall.default and the two templates if you are going to deprecate options or introduce new ones. ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1
Tom I have an action extension script that tests the variable $family to determine if IPv4 or IPv6 is being used. The script worked with shorewall(6) 4.4.19. I believe it stopped working shorewall(6) 4.4.20 Beta4. I now get the following messages: Compiling /etc/shorewall1/action.Extns for chain %Extns... Use of uninitialized value $Shorewall::Rules::family in numeric eq (==) at (eval 9) line 28, <$currentfile> line 18. Is there anything I need to do to be able reference $family within the script. I have attached a copy of the script. Thanks. Steven. ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1
On 5/29/11 4:16 PM, Steven Jan Springl wrote:> Tom > > I have an action extension script that tests the variable $family to determine > if IPv4 or IPv6 is being used. > > The script worked with shorewall(6) 4.4.19. I believe it stopped working > shorewall(6) 4.4.20 Beta4. > > I now get the following messages: > > Compiling /etc/shorewall1/action.Extns for chain %Extns... > > Use of uninitialized value $Shorewall::Rules::family in numeric eq (==) at > (eval 9) line 28, <$currentfile> line 18. > > Is there anything I need to do to be able reference $family within the script.Rather than ''our $family;'' ... if ( $family == ...) Try my $family = $Shorewall::Chains::$family; ... if ( $family == ...) -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1
On 5/29/11 4:13 PM, Mr Dash Four wrote:> >> I think that it is a little late in the 4.4.20 cycle to try to integrate >> this into that release. So I''ll hold it until I release 4.4.20 and make >> it the first thing that I add for 4.4.21 Beta 1. >> > That makes no difference to me as I already use these and "reap the > benefits", so to speak (I had quite a few "deprecated" options, > apparently left from when I first started using shorewall and I have > been carrying them since!). > > If/when you decide to use any of this new functionality you have to > remember to change shorewall.default and the two templates if you are > going to deprecate options or introduce new ones.The annotated template will be machine-generated from the ''terse'' one and the related manpage (the .conf file is currently generated that way). So I only have to keep the plain one updated. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1
On 5/29/11 4:16 PM, Steven Jan Springl wrote:> Tom > > I have an action extension script that tests the variable $family to determine > if IPv4 or IPv6 is being used. > > The script worked with shorewall(6) 4.4.19. I believe it stopped working > shorewall(6) 4.4.20 Beta4. > > I now get the following messages: > > Compiling /etc/shorewall1/action.Extns for chain %Extns... > > Use of uninitialized value $Shorewall::Rules::family in numeric eq (==) at > (eval 9) line 28, <$currentfile> line 18. > > Is there anything I need to do to be able reference $family within the script. > > I have attached a copy of the script.And here is a patch that will restore your ability to simple declare ''our $family''. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1
On Monday 30 May 2011 01:14:38 Tom Eastep wrote:> On 5/29/11 4:16 PM, Steven Jan Springl wrote: > > Tom > > > > I have an action extension script that tests the variable $family to > > determine if IPv4 or IPv6 is being used. > > > > The script worked with shorewall(6) 4.4.19. I believe it stopped working > > shorewall(6) 4.4.20 Beta4. > > > > I now get the following messages: > > > > Compiling /etc/shorewall1/action.Extns for chain %Extns... > > > > Use of uninitialized value $Shorewall::Rules::family in numeric eq (==) > > at (eval 9) line 28, <$currentfile> line 18. > > > > Is there anything I need to do to be able reference $family within the > > script. > > > > I have attached a copy of the script. > > And here is a patch that will restore your ability to simple declare > ''our $family''. > > -TomTom Using your original suggestion with a minor change works: my $family = $Shorewall::Chains::family; Your patch also works. I don''t mind which I use. So if you prefer to leave the patch off, thats okay with me. Thanks. Steven. ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1
Tom In Shorewall6 if maclist is specified on an interface, the following messages are produced: Use of uninitialized value $to in hash element at /usr/share/shorewall/Shorewall/Chains.pm line 1310. Use of uninitialized value $to in pattern match (m//) at /usr/share/shorewall/Shorewall/Chains.pm line 1310. ERROR: Internal error in Shorewall::Chains::find_chain at /usr/share/shorewall/Shorewall/Chains.pm line 1273 I have attached a minimal config. with an example. Steven. ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1
On 5/29/11 5:46 PM, Steven Jan Springl wrote:> In Shorewall6 if maclist is specified on an interface, the following messages > are produced: > > Use of uninitialized value $to in hash element > at /usr/share/shorewall/Shorewall/Chains.pm line 1310. > > Use of uninitialized value $to in pattern match (m//) > at /usr/share/shorewall/Shorewall/Chains.pm line 1310. > > ERROR: Internal error in Shorewall::Chains::find_chain > at /usr/share/shorewall/Shorewall/Chains.pm line 1273 > > I have attached a minimal config. with an example.Steven, This is a defect introduced since 4.4.19 and is not limited to IPv6. It occurs when MACLIST_DISPOSITION is not specified. Patch attached. Thanks, -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1
On Monday 30 May 2011 15:49:49 Tom Eastep wrote:> On 5/29/11 5:46 PM, Steven Jan Springl wrote: > > In Shorewall6 if maclist is specified on an interface, the following > > messages are produced: > > > > Use of uninitialized value $to in hash element > > at /usr/share/shorewall/Shorewall/Chains.pm line 1310. > > > > Use of uninitialized value $to in pattern match (m//) > > at /usr/share/shorewall/Shorewall/Chains.pm line 1310. > > > > ERROR: Internal error in Shorewall::Chains::find_chain > > at /usr/share/shorewall/Shorewall/Chains.pm line 1273 > > > > I have attached a minimal config. with an example. > > Steven, > > This is a defect introduced since 4.4.19 and is not limited to IPv6. It > occurs when MACLIST_DISPOSITION is not specified. > > Patch attached. > > Thanks, > -TomTom I confirm the patch has fixed the issue. The following message is now being produced from the config.: Use of uninitialized value $disposition in pattern match (m//) at /usr/share/shorewall/Shorewall/Misc.pm line 802. Steven. ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1
On 5/30/11 8:17 AM, Steven Jan Springl wrote:> > I confirm the patch has fixed the issue. > > The following message is now being produced from the config.: > > Use of uninitialized value $disposition in pattern match (m//) > at /usr/share/shorewall/Shorewall/Misc.pm line 802.I managed to overlook that in the output when I tested. The attached removes this second defect. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1
On Monday 30 May 2011 16:49:05 Tom Eastep wrote:> On 5/30/11 8:17 AM, Steven Jan Springl wrote: > > I confirm the patch has fixed the issue. > > > > The following message is now being produced from the config.: > > > > Use of uninitialized value $disposition in pattern match (m//) > > at /usr/share/shorewall/Shorewall/Misc.pm line 802. > > I managed to overlook that in the output when I tested. The attached > removes this second defect. > > -TomTom Confirmed, that''s fixed it. Thanks. Steven. ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1
On 5/30/11 8:55 AM, Steven Jan Springl wrote:> > Confirmed, that''s fixed it. Thanks. >Thanks, Steven -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1
On Sunday 29 May 2011 15:32:53 Steven Jan Springl wrote:> Tom > > Using kernel 2.6.39, iptables 1.4.11 and xtables-addons 1.35 > > If the config. does not have a capabilities file, the following policy > works: > > all all DROP:audit warn > > If a capabilities file is created, the following error message is produced: > > ERROR: :audit requires AUDIT Target in your kernel and > iptables : /etc/shorewallBBB/policy (line 13) > > A copy of the capabilities file is attached. > > I have manually entered the following iptables rule to confirm that the > audit feature is working: > > iptables -A INPUT -j AUDIT --type drop > > Steven.Tom Have you had an opportunity to look at the above problem yet? Steven ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1
I''ll look at it after breakfast. Tom Sent from my iPad On May 30, 2011, at 9:08 AM, Steven Jan Springl <steven@springl.ukfsn.org> wrote:> On Sunday 29 May 2011 15:32:53 Steven Jan Springl wrote: >> Tom >> >> Using kernel 2.6.39, iptables 1.4.11 and xtables-addons 1.35 >> >> If the config. does not have a capabilities file, the following policy >> works: >> >> all all DROP:audit warn >> >> If a capabilities file is created, the following error message is produced: >> >> ERROR: :audit requires AUDIT Target in your kernel and >> iptables : /etc/shorewallBBB/policy (line 13) >> >> A copy of the capabilities file is attached. >> >> I have manually entered the following iptables rule to confirm that the >> audit feature is working: >> >> iptables -A INPUT -j AUDIT --type drop >> >> Steven. > > Tom > > Have you had an opportunity to look at the above problem yet? > > Steven > > ------------------------------------------------------------------------------ > vRanger cuts backup time in half-while increasing security. > With the market-leading solution for virtual backup and recovery, > you get blazing-fast, flexible, and affordable data protection. > Download your free trial now. > http://p.sf.net/sfu/quest-d2dcopy1 > _______________________________________________ > Shorewall-devel mailing list > Shorewall-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/shorewall-devel------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1
On 5/30/11 9:20 AM, Tom Eastep wrote:> On May 30, 2011, at 9:08 AM, Steven Jan Springl <steven@springl.ukfsn.org> wrote: >> On Sunday 29 May 2011 15:32:53 Steven Jan Springl wrote: >>> Using kernel 2.6.39, iptables 1.4.11 and xtables-addons 1.35 >>> >>> If the config. does not have a capabilities file, the following policy >>> works: >>> >>> all all DROP:audit warn >>> >>> If a capabilities file is created, the following error message is produced: >>> >>> ERROR: :audit requires AUDIT Target in your kernel and >>> iptables : /etc/shorewallBBB/policy (line 13) >>> >>> A copy of the capabilities file is attached. >>> >>> I have manually entered the following iptables rule to confirm that the >>> audit feature is working: >>> >>> iptables -A INPUT -j AUDIT --type drop > >> Have you had an opportunity to look at the above problem yet?The attached patch corrects the problem. You will need to recreate the capabilities file after applying the patch. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1
On Monday 30 May 2011 17:47:34 Tom Eastep wrote:> On 5/30/11 9:20 AM, Tom Eastep wrote: > > On May 30, 2011, at 9:08 AM, Steven Jan Springl <steven@springl.ukfsn.org>wrote:> >> On Sunday 29 May 2011 15:32:53 Steven Jan Springl wrote: > >>> Using kernel 2.6.39, iptables 1.4.11 and xtables-addons 1.35 > >>> > >>> If the config. does not have a capabilities file, the following policy > >>> works: > >>> > >>> all all DROP:audit warn > >>> > >>> If a capabilities file is created, the following error message is > >>> produced: > >>> > >>> ERROR: :audit requires AUDIT Target in your kernel and > >>> iptables : /etc/shorewallBBB/policy (line 13) > >>> > >>> A copy of the capabilities file is attached. > >>> > >>> I have manually entered the following iptables rule to confirm that the > >>> audit feature is working: > >>> > >>> iptables -A INPUT -j AUDIT --type drop > >> > >> Have you had an opportunity to look at the above problem yet? > > The attached patch corrects the problem. You will need to recreate the > capabilities file after applying the patch. > > -TomTom Confirmed, the patch has fixed the problem. Thanks. Steven. ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1
Tom The attached minimal config. produces the following message: Can''t use an undefined value as a HASH reference at /usr/share/shorewall/Shorewall/Zones.pm line 1736, <$currentfile> line 11. Steven. ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1
On 5/30/11 11:20 AM, Steven Jan Springl wrote:> The attached minimal config. produces the following message: > > Can''t use an undefined value as a HASH reference > at /usr/share/shorewall/Shorewall/Zones.pm line 1736, <$currentfile> line 11.Steven, This seems to correct that problem. Thanks, -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1
On Monday 30 May 2011 19:37:32 Tom Eastep wrote:> On 5/30/11 11:20 AM, Steven Jan Springl wrote: > > The attached minimal config. produces the following message: > > > > Can''t use an undefined value as a HASH reference > > at /usr/share/shorewall/Shorewall/Zones.pm line 1736, <$currentfile> line > > 11. > > Steven, > > This seems to correct that problem. > > Thanks, > -TomTom I can confirm that it fixes the issue. Thanks. Steven. ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1
On 05/30/2011 12:22 PM, Steven Jan Springl wrote:> I can confirm that it fixes the issue. Thanks.Thanks, Steven Please let me know when you are finished testing Beta 5; once you do, I''ll upload RC 1. -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1
Tom The attached config: produces the following error messages: Use of uninitialized value in numeric gt (>) at /usr/share/shorewall/Shorewall/Chains.pm line 815. ERROR: Internal error in Shorewall::Chains::decrement_reference_count at /usr/share/shorewall/Shorewall/Chains.pm line 815 Steven. ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1
On 5/30/11 2:16 PM, Steven Jan Springl wrote:> The attached config: produces the following error messages: > > Use of uninitialized value in numeric gt (>) > at /usr/share/shorewall/Shorewall/Chains.pm line 815. > > ERROR: Internal error in Shorewall::Chains::decrement_reference_count > at /usr/share/shorewall/Shorewall/Chains.pm line 815Steven, That one took a while; bugs that show up in the optimizer with a large and complex configuration are harder to find. Thanks, -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1
On 5/30/11 3:10 PM, Tom Eastep wrote:> That one took a while; bugs that show up in the optimizer with a large > and complex configuration are harder to find.-Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1
On Monday 30 May 2011 23:12:54 Tom Eastep wrote:> On 5/30/11 3:10 PM, Tom Eastep wrote: > > That one took a while; bugs that show up in the optimizer with a large > > and complex configuration are harder to find. > > -TomTom Confirmed, that''s fixed it. I''m not surprised it took a while to find. Every time my "swiss army knife config." finds a bug like that I cringe. It can take a considerable amount of time removing bits from it until I''m left with something that I can send to you. On the other hand it finds a large number of the bugs I report to you. So I am reluctant to get rid of it. Using the same config. the following iptables-restore error is produced: iptables-restore v1.4.11: Bad action type value "blacklog" Error occurred at line: 3137 Line 3137 is: -A ~excl0 -j AUDIT --type blacklog Steven. ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1
On 5/30/11 3:54 PM, Steven Jan Springl wrote:> Confirmed, that''s fixed it. I''m not surprised it took a while to find. Every > time my "swiss army knife config." finds a bug like that I cringe. It can > take a considerable amount of time removing bits from it until I''m left with > something that I can send to you. On the other hand it finds a large number > of the bugs I report to you. So I am reluctant to get rid of it.I agree that is a valuable tool.> > Using the same config. the following iptables-restore error is produced: > > iptables-restore v1.4.11: Bad action type value "blacklog" > Error occurred at line: 3137 > > Line 3137 is: > > -A ~excl0 -j AUDIT --type blacklogThis seems to fix it. Thanks, -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1
On Tuesday 31 May 2011 00:20:05 Tom Eastep wrote:> On 5/30/11 3:54 PM, Steven Jan Springl wrote: > > Confirmed, that''s fixed it. I''m not surprised it took a while to find. > > Every time my "swiss army knife config." finds a bug like that I cringe. > > It can take a considerable amount of time removing bits from it until I''m > > left with something that I can send to you. On the other hand it finds a > > large number of the bugs I report to you. So I am reluctant to get rid of > > it. > > I agree that is a valuable tool. > > > Using the same config. the following iptables-restore error is produced: > > > > iptables-restore v1.4.11: Bad action type value "blacklog" > > Error occurred at line: 3137 > > > > Line 3137 is: > > > > -A ~excl0 -j AUDIT --type blacklog > > This seems to fix it. > > Thanks, > -TomTom Confirmed, that''s fixed it. Thanks. I have now finished testing Beta 5. Steven. ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1
On 5/30/11 4:37 PM, Steven Jan Springl wrote:> Confirmed, that''s fixed it. Thanks. > > I have now finished testing Beta 5.Thanks for all of your help, Steven -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1
On 5/29/11 2:42 PM, Mr Dash Four wrote:> >> Here''s the final file. >> > OK, I am attaching quite a few files to this post, so hopefully the > mailing list daemon won''t moan too much. If it does, then I am going to > have to attach these again in a private email. > > I have created the following files, which I have used to install and > configure my shorewall yesterday: > > 1. shorewall.default - contains shorewall.conf''s "default" options as > per the file you enclosed in your previous post. These are used to > construct the final shorewall.conf (see below); > 2. shorewall.template - template to be used to "transform" the values > and produce the final shorewall.conf; > 3. shorewall-terse.template - another template, which does not contain > any comments at all (may be suitable to "experts" who think they know > what they are doing); > 4. update-shorewall-config - a shell script, which does the donkey work > of transforming shorewall.conf options (whether from an old > shorewall.conf, "shorewal.default", or both, giving preference to the > values present in the old shorewall.conf - in other words, if option is > specified in both the existing "shorewall.conf" and "shorewall.default" > then the value of that option specified in the old "shorewall.conf" > takes precedence) and produces a final "shorewall.conf", based on one of > the two templates specified above ("shorewall.template" or > "shorewall-terse.template").Unfortunately, life isn''t quite this simple. - As I have already mentioned on the user''s list, the ''update-shorewall-config'' script doesn''t take the params file into account. In my own configuration, I have this in /etc/shorewall/params: LOG=ULOG Then, in /etc/shorewall/shorewall.conf, I have: MACLIST_LOG_LEVEL="$LOG" TCP_FLAGS_LOG_LEVEL="$LOG" SMURF_LOG_LEVEL="$LOG" This is fairly simple to correct: load the relevant libraries (remember, /etc/shorewall/params can use a number of shorewall-supplied functions) and source the params file before sourcing the .conf file. - On a fresh installation, it is preferable to omit the deprecated options. During an upgrade, however, we want to keep those options - especially if they have a non-default value. Today, I modified both the 4.4.20 and 4.4.21 branches to omit the deprecated options from the .conf files (Shorewall, Shorewall6 and their samples). - I''m particularly uncomfortable with the idea of modifying users'' configurations during an upgrade. I prefer to make it an optional post-installation step initiated by the user. - Doesn''t handle Shorewall6 (although it would be easy to adapt). - The sarcastic name of the option (-teastep) won''t do. So, I''m thinking that: - The ''upgrade-shorewall-config'' script will not be invoked automatically during install/upgrade. It may or may not be invoked in my product build (I will have to think some more about that). - It will be documented as an optional post-installation step. Adventurous package maintainers may choose to use it. I will maintain and include the necessary support files. - It will also be included in Shorewall6. - Deprecated options with non-default values will be retained with a warning message. These options will be tacked onto the end of the file with a suitable comment. - The -teastep option will become -a (annotated). The default will be non-annotated .conf files (which is consistent with the install.sh scripts). The template files will be renamed accordingly. - It is likely that none of this will be in 4.4.21 Beta 1 -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ EditLive Enterprise is the world''s most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev
On Sun, Jun 12, 2011 at 06:02:19PM -0700, Tom Eastep wrote:> > - On a fresh installation, it is preferable to omit the deprecated > options. During an upgrade, however, we want to keep those options - > especially if they have a non-default value. > > Today, I modified both the 4.4.20 and 4.4.21 branches to omit the > deprecated options from the .conf files (Shorewall, Shorewall6 and > their samples). > > - I''m particularly uncomfortable with the idea of modifying users'' > configurations during an upgrade. I prefer to make it an optional > post-installation step initiated by the user. >Tom, This fits with my idea of a sensible way of handling this. From the Debian packaging side, if shorewall.conf contains local modifications, any changes in the shorewall.conf shipped with the package must be dealt with by the admin on upgrade. In the event that there is no interactive terminal attached, the default is to keep the old configuration unmodified and save the packages new default configuration file alongside. Incidentally, for users of unstable, these sorts of things tend to come along in bite-sized pieces. However, when doing a dist-upgrade from one stable release to another there are lots of changes. For that reason I try to avoid gratiutious changes to configuration files. What I plan to do, though, is to ship the config file without the deprecated options. The Debian package upgrade process will make it relatively painless for the admin to deal with the change. If the admin chooses to do nothing then things should continue to work with the older configuration file. Regards, -Roberto -- Roberto C. Sánchez http://people.connexer.com/~roberto http://www.connexer.com ------------------------------------------------------------------------------ EditLive Enterprise is the world''s most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev
On 6/12/11 6:15 PM, Roberto C. Sánchez wrote:> On Sun, Jun 12, 2011 at 06:02:19PM -0700, Tom Eastep wrote: >> >> - On a fresh installation, it is preferable to omit the deprecated >> options. During an upgrade, however, we want to keep those options - >> especially if they have a non-default value. >> >> Today, I modified both the 4.4.20 and 4.4.21 branches to omit the >> deprecated options from the .conf files (Shorewall, Shorewall6 and >> their samples). >> >> - I''m particularly uncomfortable with the idea of modifying users'' >> configurations during an upgrade. I prefer to make it an optional >> post-installation step initiated by the user. > > This fits with my idea of a sensible way of handling this. From the > Debian packaging side, if shorewall.conf contains local modifications, > any changes in the shorewall.conf shipped with the package must be > dealt with by the admin on upgrade. In the event that there is no > interactive terminal attached, the default is to keep the old > configuration unmodified and save the packages new default configuration > file alongside.Agreed. And the environment where there is no interactive terminal attached makes me nervous about modifying the user''s configuration.> > Incidentally, for users of unstable, these sorts of things tend to come > along in bite-sized pieces.Also agreed. I suspect that if Mr Dash Four ran Debian, he would not have developed these scripts since the Debian upgrade process would have made the differences between his config and the new one explicit (if he chose to examine those differences).> However, when doing a dist-upgrade from one stable release to another > there are lots of changes. For that reason I try to avoid > gratiutious changes to configuration files.The dist-upgrade scenario is the one that makes me most nervous about modifying the user''s configuration. Because the user''s configuration can be several years out of date with respect to the version being installed.> > What I plan to do, though, is to ship the config file without the > deprecated options. The Debian package upgrade process will make it > relatively painless for the admin to deal with the change. If the admin > chooses to do nothing then things should continue to work with the older > configuration file.Exactly. Thanks, Roberto -Tom -- Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ EditLive Enterprise is the world''s most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev
In case it helps, From my perspective as fedora and epel package of shorewall, I totally concur with Roberto. sent from my phone. ------------------------------------------------------------------------------ EditLive Enterprise is the world''s most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev