Beta 4 is now available for testing.
Problems corrected since Beta 3:
1) A_ACCEPT! is now recognized as a rules ACTION. Previously, it was
documented in shorewall[6]-rules(5) but was not implemented.
New Features:
The INLINE facility has been enhanced. Here is the entire description:
1) A new INLINE action has been added. This action allows defining
arbitrary iptables rules in the blrules and rules files, as well as
in action and macro bodies.
The basic form of an INLINE rule is as follows:
INLINE <src> <dst> <proto> ... ; <iptables matches and
jump>
The <iptables matches and jump> are added to the rule generated by
the contents of the other supplied columns. Given the
''raw'' nature
of this action, you should examine the rule generated by the entry
(e.g., ''shorewall check -r'') prior to attempting a
''start'' or
''restart'' operation.
Example:
INLINE $FW net tcp 1234 ; -j SECCTX --name foo
This entry generates the following:
-A fw2net -p 6 --dport 1234 -j SECCTX --name foo
When multiple matches are specified, the compiler will keep them in
the order in which they appear, but they will not necessarily be at
the end of the generated rule. For example, if addresses are
specified in the SOURCE and/or DEST columns, their generated matches
will appear after those specified using '';''.
As part of this change, a new ''builtin'' action type has
been added.
ip[6]tables targets not supported by Shorewall (such as
''SECCTX'' in
the example above), must be defined in your
/etc/shorewall[6]/actions file:
Example:
SECCTX builtin
Such builtin actions may only be used in INLINE action invocations;
they may not appear in the ACTION column of a rule.
If you want to use a standard Shorewall-supported action, you can
pass it as a parameter to INLINE.
Example:
INLINE(ACCEPT) $FW net ; -m foo --bar baz
Note that if you include a log level with INLINE and do not pass a
parameter, Shorewall will automatically assume that the parameter
is LOG. That means that you must not specify a log level if you
specify your own rule target with ''-j''.
The alternate input format may be used with INLINE, provided that
the {....} form of alternate input is used.
Example:
INLINE $FW net { owner=teastep } ; -j FOO --bar
--
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 \________________________________________________
------------------------------------------------------------------------------
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis & visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter
> When multiple matches are specified, the compiler will keep them in > the order in which they appear, but they will not necessarily be at > the end of the generated rule. For example, if addresses are > specified in the SOURCE and/or DEST columns, their generated matches > will appear after those specified using '';''. >rules ~~~~~ INLINE $FW net ; -m mickey-mouse --name test -p 6 -m set --match-set set1 src -m mickey-mouse --name test2 -j SECCTX --name test3 generates -A fw2net -p 6 -m mickey-mouse --name test -m mickey-mouse --name test2 -m set --match-set set1 -j SECCTX --name test3> As part of this change, a new ''builtin'' action type has been added. > ip[6]tables targets not supported by Shorewall (such as ''SECCTX'' in > the example above), must be defined in your > /etc/shorewall[6]/actions file: > > Example: > > SECCTX builtin >That now works and error is issued when "SECCTX" is not in actions. ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter
On 04/16/2013 03:13 PM, Dash Four wrote:> >> When multiple matches are specified, the compiler will keep them in >> the order in which they appear, but they will not necessarily be at >> the end of the generated rule. For example, if addresses are >> specified in the SOURCE and/or DEST columns, their generated matches >> will appear after those specified using '';''. >> > rules > ~~~~~ > INLINE $FW net ; -m mickey-mouse --name test -p 6 -m set --match-set > set1 src -m mickey-mouse --name test2 -j SECCTX --name test3 > > generates > > -A fw2net -p 6 -m mickey-mouse --name test -m mickey-mouse --name test2 > -m set --match-set set1 -j SECCTX --name test3That needs a documentation change. Some background: Keeping the rule in textual form is problematic for optimization. So the compiler defines an internal form for rules based on a Perl hash (associative array). Parts of the compiler generate the internal form natively, but most of the code that parses user-defined files generates the rule textually before converting it to the native form. When the iptables-restore input is being generated, each of the rules must be converted back into text. To provide a degree of predictability and to localize cache references at runtime, internal->text conversion handles some matches explicitly in this order: p dport sport icmp-type icmpv6-type s d i o policy state or conntrack --ctstate So those options, if they are present, are always in the above fixed order. The remainder are now output in the order in which they were added to the rule.> >> As part of this change, a new ''builtin'' action type has been added. >> ip[6]tables targets not supported by Shorewall (such as ''SECCTX'' in >> the example above), must be defined in your >> /etc/shorewall[6]/actions file: >> >> Example: >> >> SECCTX builtin >> > That now works and error is issued when "SECCTX" is not in actions. >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 \________________________________________________ ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter
Tom Eastep wrote:> On 04/16/2013 03:13 PM, Dash Four wrote: > >>> When multiple matches are specified, the compiler will keep them in >>> the order in which they appear, but they will not necessarily be at >>> the end of the generated rule. For example, if addresses are >>> specified in the SOURCE and/or DEST columns, their generated matches >>> will appear after those specified using '';''. >>> >>> >> rules >> ~~~~~ >> INLINE $FW net ; -m mickey-mouse --name test -p 6 -m set --match-set >> set1 src -m mickey-mouse --name test2 -j SECCTX --name test3 >> >> generates >> >> -A fw2net -p 6 -m mickey-mouse --name test -m mickey-mouse --name test2 >> -m set --match-set set1 -j SECCTX --name test3 >> > > That needs a documentation change. > > Some background: > > Keeping the rule in textual form is problematic for optimization. So the > compiler defines an internal form for rules based on a Perl hash > (associative array). Parts of the compiler generate the internal form > natively, but most of the code that parses user-defined files generates > the rule textually before converting it to the native form. > > When the iptables-restore input is being generated, each of the rules > must be converted back into text. To provide a degree of predictability > and to localize cache references at runtime, internal->text conversion > handles some matches explicitly in this order: > > p > dport > sport > icmp-type > icmpv6-type > s > d > i > o > policy > state or conntrack --ctstate > > So those options, if they are present, are always in the above fixed order. > > The remainder are now output in the order in which they were added to > the rule. >Even if I do this: INLINE $FW net ; -p 6 -m mickey-mouse --name test -m set --match-set set1 src -m mickey-mouse --name test2 -j SECCTX --name test3 that still generates -A fw2net -p 6 -m mickey-mouse --name test -m mickey-mouse --name test2 -m set --match-set set1 -j SECCTX --name test3 Note the "displacement" of the "set" match - position 2 in "rules", position 3 in the generated iptables rules. ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter
On 4/16/13 3:37 PM, "Dash Four" <mr.dash.four@googlemail.com> wrote:>Even if I do this: > >INLINE $FW net ; -p 6 -m mickey-mouse --name test -m set --match-set >set1 src -m mickey-mouse --name test2 -j SECCTX --name test3 > >that still generates > >-A fw2net -p 6 -m mickey-mouse --name test -m mickey-mouse --name test2 >-m set --match-set set1 -j SECCTX --name test3 > >Note the "displacement" of the "set" match - position 2 in "rules", >position 3 in the generated iptables rulesYep -- repeated matches (micky-mouse in the above case) will appear together. -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter
> Yep -- repeated matches (micky-mouse in the above case) will appear > together. >Why? ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter
On 4/16/13 4:32 PM, "Dash Four" <mr.dash.four@googlemail.com> wrote:> >> Yep -- repeated matches (micky-mouse in the above case) will appear >> together. >> >Why?Because that is the way that multiple instances of the same match have worked since I added the internal rule representation. -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter
Tom Eastep wrote:> On 4/16/13 4:32 PM, "Dash Four" <mr.dash.four@googlemail.com> wrote: > > >>> Yep -- repeated matches (micky-mouse in the above case) will appear >>> together. >>> >>> >> Why? >> > > Because that is the way that multiple instances of the same match have > worked since I added the internal rule representation. >So much for "When multiple matches are specified, the compiler will keep them in the order in which they appear" then. I take it this cannot be corrected and you can''t leave the order as specified after the ";" bit? If that is indeed the case, then this new feature would be next to useless to me. ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter
On 04/17/2013 01:20 AM, Dash Four wrote: ernal rule representation.>> > So much for "When multiple matches are specified, the compiler will keep > them in the order in which they appear" then. I take it this cannot be > corrected and you can''t leave the order as specified after the ";" bit? > If that is indeed the case, then this new feature would be next to > useless to me.Patch attached. -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 \________________________________________________ ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter
Tom Eastep wrote:> Patch attached. >Better, much better! Three minor issues so far: 1. rules ~~~~~ INLINE $FW net ; -j DROP --name test2 produces -A fw2net -j DROP --name test2 Maybe the optimiser can check that DROP doesn''t have a "name" parameter (this is valid for all targets "known" to shorewall - like NFLOG, LOG and so on). 2. rules ~~~~~ INLINE:NFLOG(1,0,1) $FW net ; -m mickey-mouse --name test produces the old "invalid column/value pair (-m)" error, though INLINE(NFLOG(1,0,1)) $FW net ; -m mickey-mouse --name test" works as expected. 3. How do I specify INLINE in actions (including inline actions)? I tried using something like ''TEST("-j SECCTX --name test",drop) $FW net'', bearing in mind that TEST takes 2 parameters - one the INLINE action parameters (the stuff after ";"); and two - parameter for the AUDIT action, but I''ve got shorewall moaning about my double quotes (without the quotes I also get an error). The TEST action consists of this: ?IF $1 INLINE ; $1 ?ENDIF ?IF $2 AUDIT($2) ?ENDIF ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter
On 4/17/13 2:56 PM, "Dash Four" <mr.dash.four@googlemail.com> wrote:> > >Tom Eastep wrote: >> Patch attached. >> >Better, much better! Three minor issues so far: > >1. >rules >~~~~~ >INLINE $FW net ; -j DROP --name test2 > >produces > >-A fw2net -j DROP --name test2 > >Maybe the optimiser can check that DROP doesn''t have a "name" parameter >(this is valid for all targets "known" to shorewall - like NFLOG, LOG >and so on).Patch TARGETOPTIONS.patch attached.> >2. >rules >~~~~~ >INLINE:NFLOG(1,0,1) $FW net ; -m mickey-mouse --name test > >produces the old "invalid column/value pair (-m)" error, though >INLINE(NFLOG(1,0,1)) $FW net ; -m mickey-mouse --name test" works as >expected.Patch INLINECOLON.patch attached.> >3. How do I specify INLINE in actions (including inline actions)? I >tried using something like ''TEST("-j SECCTX --name test",drop) $FW net'', >bearing in mind that TEST takes 2 parameters - one the INLINE action >parameters (the stuff after ";"); and two - parameter for the AUDIT >action, but I''ve got shorewall moaning about my double quotes (without >the quotes I also get an error). > >The TEST action consists of this: > >?IF $1 >INLINE ; $1 >?ENDIF >?IF $2 >AUDIT($2) >?ENDIFAny use of quoted strings will be a major project to implement. -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter
On 4/17/13 5:02 PM, "Tom Eastep" <teastep@shorewall.net> wrote:>On 4/17/13 2:56 PM, "Dash Four" <mr.dash.four@googlemail.com> wrote: > >> >> >>Tom Eastep wrote: >>> Patch attached. >>> >>Better, much better! Three minor issues so far: >> >>1. >>rules >>~~~~~ >>INLINE $FW net ; -j DROP --name test2 >> >>produces >> >>-A fw2net -j DROP --name test2 >> >>Maybe the optimiser can check that DROP doesn''t have a "name" parameter >>(this is valid for all targets "known" to shorewall - like NFLOG, LOG >>and so on). > >Patch TARGETOPTIONS.patch attached.-Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter
> Patch TARGETOPTIONS.patch attached. >It catches most, but not all "known" targets. "INLINE $FW net ; -j NFLOG --name test" for example passes without warning or error being issued.> Patch INLINECOLON.patch attached. >Works as expected.>> 3. How do I specify INLINE in actions (including inline actions)? I >> tried using something like ''TEST("-j SECCTX --name test",drop) $FW net'', >> bearing in mind that TEST takes 2 parameters - one the INLINE action >> parameters (the stuff after ";"); and two - parameter for the AUDIT >> action, but I''ve got shorewall moaning about my double quotes (without >> the quotes I also get an error). >> >> The TEST action consists of this: >> >> ?IF $1 >> INLINE ; $1 >> ?ENDIF >> ?IF $2 >> AUDIT($2) >> ?ENDIF >> > > Any use of quoted strings will be a major project to implement. >OK, I take it there isn''t a way for me to specify this (short of using parameters without spaces)? On a side note, I''ve implemented my first proper perl hacks in shorewall (Chains.pm, Rules.pm and Accounting.pm all went under the knife) to accommodate the new "options" for the iptables custom-code we''ve been using for the past year or so and I am very proud of myself, bearing in mind that my perl knowledge was close to nil about 2 hours ago. Peculiar language this perl. Another question and I know I asked this earlier, but can''t find any references to this: How do I get rid of my "xt_CT: No such helper XXX" messages appearing in my shorewall startup/restart/reload logs? These are very annoying and I don''t see a way to shut shorewall up! ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter
On 4/17/13 5:26 PM, "Dash Four" <mr.dash.four@googlemail.com> wrote:> >> Patch TARGETOPTIONS.patch attached. >> >It catches most, but not all "known" targets. "INLINE $FW net ; -j NFLOG >--name test" for example passes without warning or error being issued.NFLOG accepts options; I''m not going to parse and validate them.> >> Patch INLINECOLON.patch attached. >> >Works as expected. > >>> 3. How do I specify INLINE in actions (including inline actions)? I >>> tried using something like ''TEST("-j SECCTX --name test",drop) $FW >>>net'', >>> bearing in mind that TEST takes 2 parameters - one the INLINE action >>> parameters (the stuff after ";"); and two - parameter for the AUDIT >>> action, but I''ve got shorewall moaning about my double quotes (without >>> the quotes I also get an error). >>> >>> The TEST action consists of this: >>> >>> ?IF $1 >>> INLINE ; $1 >>> ?ENDIF >>> ?IF $2 >>> AUDIT($2) >>> ?ENDIF >>> >> >> Any use of quoted strings will be a major project to implement. >> >OK, I take it there isn''t a way for me to specify this (short of using >parameters without spaces)?Correct.> >On a side note, I''ve implemented my first proper perl hacks in shorewall >(Chains.pm, Rules.pm and Accounting.pm all went under the knife) to >accommodate the new "options" for the iptables custom-code we''ve been >using for the past year or so and I am very proud of myself, bearing in >mind that my perl knowledge was close to nil about 2 hours ago. Peculiar >language this perl.You''re not the first to make that observation :-)> >Another question and I know I asked this earlier, but can''t find any >references to this: How do I get rid of my "xt_CT: No such helper XXX" >messages appearing in my shorewall startup/restart/reload logs? These >are very annoying and I don''t see a way to shut shorewall up!Use a capabilities file and set WARNOLDCAPSVERSION=No in shorewall.conf. -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter
Tom Eastep wrote:> On 4/17/13 5:26 PM, "Dash Four" <mr.dash.four@googlemail.com> wrote: > > >>> Patch TARGETOPTIONS.patch attached. >>> >>> >> It catches most, but not all "known" targets. "INLINE $FW net ; -j NFLOG >> --name test" for example passes without warning or error being issued. >> > > NFLOG accepts options; I''m not going to parse and validate them. >Fair enough.>> Another question and I know I asked this earlier, but can''t find any >> references to this: How do I get rid of my "xt_CT: No such helper XXX" >> messages appearing in my shorewall startup/restart/reload logs? These >> are very annoying and I don''t see a way to shut shorewall up! >> > > Use a capabilities file and set WARNOLDCAPSVERSION=No in shorewall.conf. >Hmm, I am not sure I like this, simply because every time I do an update, I have to manually sync this file and I don''t need this extra headache. I just looked at your Config.pm, which seems to be the source of these messages - "have_helper", in particular. Am I right in thinking that if "helpers_enabled($helper)" isn''t set, then no check takes place and no annoying messages are issued (and shorewall assumes that such capability does not exist)? If that is so, why not add a couple of shorewall.conf variables (you can call then HELPER_*_ENABLE for example) to set/reset these checks, instead of assuming that they all exists (your %helpers_enable" array members are all enabled by default)? ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter
> If that is so, why not add a couple of shorewall.conf variables (you > can call then HELPER_*_ENABLE for example) to set/reset these checks, > instead of assuming that they all exists (your %helpers_enable" array > members are all enabled by default)?Failing that, and also assuming that the capabilities file is all-or-nothing, then you could alter the implementation which checks this file and import only what is specified (and ask shorewall to check the rest). That way, I could create a partial capabilities file with the relevant helper lines disabled and in such a case shorewall will have to "fill-in" the gaps by performing the extra checks. Would that be better? ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter
On 04/18/2013 10:41 AM, Tom Eastep wrote:>> ... >> >On a side note, I''ve implemented my first proper perl hacks in shorewall >> >(Chains.pm, Rules.pm and Accounting.pm all went under the knife) to >> >accommodate the new "options" for the iptables custom-code we''ve been >> >using for the past year or so and I am very proud of myself, bearing in >> >mind that my perl knowledge was close to nil about 2 hours ago. Peculiar >> >language this perl. > You''re not the first to make that observation:-)Just count yourself lucky that you''re reading Tom''s perl code and not something i wrote. Or worse, a CPAN contributor! ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter
On 4/17/13 5:59 PM, "Dash Four" <mr.dash.four@googlemail.com> wrote:> > >Tom Eastep wrote: >> On 4/17/13 5:26 PM, "Dash Four" <mr.dash.four@googlemail.com> wrote: >> >> >>>> Patch TARGETOPTIONS.patch attached. >>>> >>>> >>> It catches most, but not all "known" targets. "INLINE $FW net ; -j >>>NFLOG >>> --name test" for example passes without warning or error being issued. >>> >> >> NFLOG accepts options; I''m not going to parse and validate them. >> >Fair enough. > >>> Another question and I know I asked this earlier, but can''t find any >>> references to this: How do I get rid of my "xt_CT: No such helper XXX" >>> messages appearing in my shorewall startup/restart/reload logs? These >>> are very annoying and I don''t see a way to shut shorewall up! >>> >> >> Use a capabilities file and set WARNOLDCAPSVERSION=No in shorewall.conf. >> >Hmm, I am not sure I like this, simply because every time I do an >update, I have to manually sync this file and I don''t need this extra >headache.Why? If you don''t change your config, you don''t need new capabilities!> >I just looked at your Config.pm, which seems to be the source of these >messages - "have_helper", in particular. Am I right in thinking that if >"helpers_enabled($helper)" isn''t set, then no check takes place and no >annoying messages are issued (and shorewall assumes that such capability >does not exist)? > >If that is so, why not add a couple of shorewall.conf variables (you can >call then HELPER_*_ENABLE for example) to set/reset these checks, >instead of assuming that they all exists (your %helpers_enable" array >members are all enabled by default)?Have you looked at the HELPERS option? -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter
> Just count yourself lucky that you''re reading Tom''s perl code and not > something i wrote. Or worse, a CPAN contributor! >I consider myself lucky just to be able to look at *any* perl code - some don''t even go that far... ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter
> Have you looked at the HELPERS option? >I have "AUTOHELPERS=No" as well as "HELPERS=" (kernel version is 3.7.x) and I am getting about 15 lines of this "No such helper" crap each time I (re)start or (re)load shorewall. ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter
>> Hmm, I am not sure I like this, simply because every time I do an >> update, I have to manually sync this file and I don''t need this extra >> headache. >> > > Why? If you don''t change your config, you don''t need new capabilities! >Sorry, missed that. The problem is that when I compile a new kernel, I also tweak with the options (particularly with the Netfilter section), so some "capability" may be activated/deactivated (new iptables targets for example). \that is why I don''t want to use a fixed capabilities file as some of the options there may be used in the new version, or removed if I previously used them. ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter
On 4/17/13 6:47 PM, "Dash Four" <mr.dash.four@googlemail.com> wrote:> >>> Hmm, I am not sure I like this, simply because every time I do an >>> update, I have to manually sync this file and I don''t need this extra >>> headache. >>> >> >> Why? If you don''t change your config, you don''t need new capabilities! >> >Sorry, missed that. The problem is that when I compile a new kernel, I >also tweak with the options (particularly with the Netfilter section), >so some "capability" may be activated/deactivated (new iptables targets >for example). \that is why I don''t want to use a fixed capabilities file >as some of the options there may be used in the new version, or removed >if I previously used them.Then make a habit of generating a new capabilities file when you compile a new kernel. -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter
On 4/17/13 6:44 PM, "Dash Four" <mr.dash.four@googlemail.com> wrote:> >> Have you looked at the HELPERS option? >> >I have "AUTOHELPERS=No" as well as "HELPERS=" (kernel version is 3.7.x) >and I am getting about 15 lines of this "No such helper" crap each time >I (re)start or (re)load shorewall.How about I implement a HELPERS=none that assumes no helpers? -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter
Tom Eastep wrote:> On 4/17/13 6:44 PM, "Dash Four" <mr.dash.four@googlemail.com> wrote: > > >>> Have you looked at the HELPERS option? >>> >>> >> I have "AUTOHELPERS=No" as well as "HELPERS=" (kernel version is 3.7.x) >> and I am getting about 15 lines of this "No such helper" crap each time >> I (re)start or (re)load shorewall. >> > > How about I implement a HELPERS=none that assumes no helpers? >Sound! I thought that an empty HELPERS option meant just that (that no helpers of any kind are enabled), but if that was not the case, then yes, makes perfect sense. I am also assuming that if I have, say, "HELPERS=amanda" for example, only that helper is enabled (amanda), correct? ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter
On 4/17/13 7:17 PM, "Dash Four" <mr.dash.four@googlemail.com> wrote:> > >Tom Eastep wrote: >> On 4/17/13 6:44 PM, "Dash Four" <mr.dash.four@googlemail.com> wrote: >> >> >>>> Have you looked at the HELPERS option? >>>> >>>> >>> I have "AUTOHELPERS=No" as well as "HELPERS=" (kernel version is 3.7.x) >>> and I am getting about 15 lines of this "No such helper" crap each time >>> I (re)start or (re)load shorewall. >>> >> >> How about I implement a HELPERS=none that assumes no helpers? >> >Sound! I thought that an empty HELPERS option meant just that (that no >helpers of any kind are enabled), but if that was not the case, then >yes, makes perfect sense. I am also assuming that if I have, say, >"HELPERS=amanda" for example, only that helper is enabled (amanda), >correct?Yes. -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter
On 04/17/2013 07:37 PM, Tom Eastep wrote:> On 4/17/13 7:17 PM, "Dash Four" <mr.dash.four@googlemail.com> wrote: > >> >> >> Tom Eastep wrote: >>> On 4/17/13 6:44 PM, "Dash Four" <mr.dash.four@googlemail.com> wrote: >>> >>> >>>>> Have you looked at the HELPERS option? >>>>> >>>>> >>>> I have "AUTOHELPERS=No" as well as "HELPERS=" (kernel version is 3.7.x) >>>> and I am getting about 15 lines of this "No such helper" crap each time >>>> I (re)start or (re)load shorewall. >>>> >>> >>> How about I implement a HELPERS=none that assumes no helpers? >>> >> Sound! I thought that an empty HELPERS option meant just that (that no >> helpers of any kind are enabled), but if that was not the case, then >> yes, makes perfect sense. I am also assuming that if I have, say, >> "HELPERS=amanda" for example, only that helper is enabled (amanda), >> correct?Here''s a 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 \________________________________________________ ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter
On 04/18/2013 11:06 AM, Tom Eastep wrote:> > Here''s a patch. >And here is a patchlet to be applied on top of that patch. This one makes ''shorewall update'' work correctly. -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 \________________________________________________ ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter
> Here''s a patch. >OK, this worked (well, sort of!), but not the way I expected it. Although all the annoying messages are now gone (thank god!), I still have some of the modules loaded, like nf_conntrack_ftp (and various other nf_conntrack_* kernel modules), as well as nf_nat_ftp etc. Further investigation revealed that there are hard-coded "loadmodule" statements in the "helpers" file, which I think is responsible for this. If I remove these lines (I commented them out), then everything is clear. So, is there any way to "synchronise" both things as the way I see it, one doesn''t make sense without the other? In other words, if I have chosen not to have the tftp helper, what is the sense in loading nf_conntrack_tftp for example? Also, in that "helpers" file I see quite a few ipset modules (ip_set_iphash, ip_set_ipmap etc) - these are not helpers and, anyway, they appear to be in "modules.ipset" so I think it is safe to delete them from there. While I am at it, one further question: am I right in assuming that if iptables match/target kernel module is needed in a specific rule, then that kernel module is loaded automatically by iptables anyway, so do we need any of the "modules.xtables" or "modules.extensions"? ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter
On 04/18/2013 01:22 PM, Dash Four wrote:> >> Here''s a patch. >> > OK, this worked (well, sort of!), but not the way I expected it. > > Although all the annoying messages are now gone (thank god!), I still > have some of the modules loaded, like nf_conntrack_ftp (and various > other nf_conntrack_* kernel modules), as well as nf_nat_ftp etc. Further > investigation revealed that there are hard-coded "loadmodule" statements > in the "helpers" file, which I think is responsible for this.Yes.> > If I remove these lines (I commented them out), then everything is > clear. So, is there any way to "synchronise" both things as the way I > see it, one doesn''t make sense without the other? In other words, if I > have chosen not to have the tftp helper, what is the sense in loading > nf_conntrack_tftp for example?The modules files are also read by the CLI and by the shorecap programs; so that can''t have ?if .... ?endif like other Shorewall configuration files. But you can certainly copy helpers to /etc/shorewall/ and modify it in any way that you see fit.> > Also, in that "helpers" file I see quite a few ipset modules > (ip_set_iphash, ip_set_ipmap etc) - these are not helpers and, anyway, > they appear to be in "modules.ipset" so I think it is safe to delete > them from there.Yes -- that''s certainly a bug. I''ve removed them for the next Beta.> While I am at it, one further question: am I right in > assuming that if iptables match/target kernel module is needed in a > specific rule, then that kernel module is loaded automatically by > iptables anyway, so do we need any of the "modules.xtables" or > "modules.extensions"?They are loaded by Shorewall only if LOAD_HELPERS_ONLY=No. If LOAD_HELPERS_ONLY=Yes, only the helpers file is loaded. They will be loaded if the kernel is configured for module autoloading. That is rare in embedded systems but is the norm for desktop and server distributions. -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 \________________________________________________ ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter
Dash Four wrote:>> Here''s a patch. >> > OK, this worked (well, sort of!), but not the way I expected it. > > Although all the annoying messages are now gone (thank god!), I still > have some of the modules loaded, like nf_conntrack_ftp (and various > other nf_conntrack_* kernel modules), as well as nf_nat_ftp etc. > Further investigation revealed that there are hard-coded "loadmodule" > statements in the "helpers" file, which I think is responsible for this. > > If I remove these lines (I commented them out), then everything is > clear. So, is there any way to "synchronise" both things as the way I > see it, one doesn''t make sense without the other? In other words, if I > have chosen not to have the tftp helper, what is the sense in loading > nf_conntrack_tftp for example? > > Also, in that "helpers" file I see quite a few ipset modules > (ip_set_iphash, ip_set_ipmap etc) - these are not helpers and, anyway, > they appear to be in "modules.ipset" so I think it is safe to delete > them from there. While I am at it, one further question: am I right in > assuming that if iptables match/target kernel module is needed in a > specific rule, then that kernel module is loaded automatically by > iptables anyway, so do we need any of the "modules.xtables" or > "modules.extensions"?On a completely unrelated note to this discussion, I''ve just found a bug, which, I think is quite major: accounting ~~~~~~~~~~ SECTION INPUT NFACCT(test) - +test-set produces -A accountin -m nfacct --nfacct-name test -m set --match-set test src The above rule will *not* work as expected, simply because the nfacct match always returns true (i.e. always "matches") and since we all know that iptables matches are evaluated from left to right, packets/bytes will *always* be counted regardless since the set match follows after that nfacct match. The right thing to do is to have the nfacct match *last* regardless of what else is specified. ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter
Tom Eastep wrote:>> If I remove these lines (I commented them out), then everything is >> clear. So, is there any way to "synchronise" both things as the way I >> see it, one doesn''t make sense without the other? In other words, if I >> have chosen not to have the tftp helper, what is the sense in loading >> nf_conntrack_tftp for example? >> > > The modules files are also read by the CLI and by the shorecap programs; > so that can''t have ?if .... ?endif like other Shorewall configuration files. >Erm, you''ve lost me. What does that mean?> But you can certainly copy helpers to /etc/shorewall/ and modify it in > any way that you see fit. >Am I right in assuming that if I don''t need any of the helpers, I could also delete these lines too? I also take it there isn''t a way to sync the "HELPERS" config option with this then?>> Also, in that "helpers" file I see quite a few ipset modules >> (ip_set_iphash, ip_set_ipmap etc) - these are not helpers and, anyway, >> they appear to be in "modules.ipset" so I think it is safe to delete >> them from there. >> > > Yes -- that''s certainly a bug. I''ve removed them for the next Beta. >Thanks.>> While I am at it, one further question: am I right in >> assuming that if iptables match/target kernel module is needed in a >> specific rule, then that kernel module is loaded automatically by >> iptables anyway, so do we need any of the "modules.xtables" or >> "modules.extensions"? >> > > They are loaded by Shorewall only if LOAD_HELPERS_ONLY=No. If > LOAD_HELPERS_ONLY=Yes, only the helpers file is loaded. > > They will be loaded if the kernel is configured for module autoloading. > That is rare in embedded systems but is the norm for desktop and server > distributions. >OK, so if I use iptables targets (which appear as kernel modules) and don''t need any "helpers" loaded, in order to prevent shorewall from loading anything else (well, anything apart from the "essential" modules - not sure if iptables would load these automatically!) while starting my firewall successfully, all I have to do is: HELPERS=none LOAD_HELPERS_ONLY=Yes Correct, or am I going to have my fingers burned? ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter
On 04/18/2013 01:40 PM, Dash Four wrote:> > On a completely unrelated note to this discussion, I''ve just found a > bug, which, I think is quite major: > > accounting > ~~~~~~~~~~ > SECTION INPUT > NFACCT(test) - +test-set > > produces > > -A accountin -m nfacct --nfacct-name test -m set --match-set test src > > The above rule will *not* work as expected, simply because the nfacct > match always returns true (i.e. always "matches") and since we all know > that iptables matches are evaluated from left to right, packets/bytes > will *always* be counted regardless since the set match follows after > that nfacct match. > > The right thing to do is to have the nfacct match *last* regardless of > what else is specified.Patch attached. -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 \________________________________________________ ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter
On 04/18/2013 01:49 PM, Dash Four wrote:> > Tom Eastep wrote: >>> If I remove these lines (I commented them out), then everything is >>> clear. So, is there any way to "synchronise" both things as the way I >>> see it, one doesn''t make sense without the other? In other words, if I >>> have chosen not to have the tftp helper, what is the sense in loading >>> nf_conntrack_tftp for example? >>> >> >> The modules files are also read by the CLI and by the shorecap programs; >> so that can''t have ?if .... ?endif like other Shorewall configuration files. >> > Erm, you''ve lost me. What does that mean?It means that it is not really feasible to sync the loaded helper modules with the HELPERS option.> >> But you can certainly copy helpers to /etc/shorewall/ and modify it in >> any way that you see fit. >> > Am I right in assuming that if I don''t need any of the helpers, I could > also delete these lines too?Yes.> I also take it there isn''t a way to sync > the "HELPERS" config option with this then? >No, there isn''t.>>> Also, in that "helpers" file I see quite a few ipset modules >>> (ip_set_iphash, ip_set_ipmap etc) - these are not helpers and, anyway, >>> they appear to be in "modules.ipset" so I think it is safe to delete >>> them from there. >>> >> >> Yes -- that''s certainly a bug. I''ve removed them for the next Beta. >> > Thanks. > >>> While I am at it, one further question: am I right in >>> assuming that if iptables match/target kernel module is needed in a >>> specific rule, then that kernel module is loaded automatically by >>> iptables anyway, so do we need any of the "modules.xtables" or >>> "modules.extensions"? >>> >> >> They are loaded by Shorewall only if LOAD_HELPERS_ONLY=No. If >> LOAD_HELPERS_ONLY=Yes, only the helpers file is loaded. >> >> They will be loaded if the kernel is configured for module autoloading. >> That is rare in embedded systems but is the norm for desktop and server >> distributions. >> > OK, so if I use iptables targets (which appear as kernel modules) and > don''t need any "helpers" loaded, in order to prevent shorewall from > loading anything else (well, anything apart from the "essential" modules > - not sure if iptables would load these automatically!) while starting > my firewall successfully, all I have to do is: > > HELPERS=none > LOAD_HELPERS_ONLY=Yes > > Correct, or am I going to have my fingers burned?That will work, provided that you have module autoloading enabled in your kernel and you have an empty ''modules'' file in /etc/shorewall/; in that case, Shorewall won''t load a thing. -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 \________________________________________________ ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter
> Patch attached. >Wow, that was pretty quick and it works to perfection, thanks Tom. ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter
Tom Eastep wrote:>> Erm, you''ve lost me. What does that mean? >> > > It means that it is not really feasible to sync the loaded helper > modules with the HELPERS option. >Got it, thanks.>> OK, so if I use iptables targets (which appear as kernel modules) and >> don''t need any "helpers" loaded, in order to prevent shorewall from >> loading anything else (well, anything apart from the "essential" modules >> - not sure if iptables would load these automatically!) while starting >> my firewall successfully, all I have to do is: >> >> HELPERS=none >> LOAD_HELPERS_ONLY=Yes >> >> Correct, or am I going to have my fingers burned? >> > > That will work, provided that you have module autoloading enabled in > your kernel and you have an empty ''modules'' file in /etc/shorewall/; in > that case, Shorewall won''t load a thing. >And my firewall will start successfully, right? ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter
On 04/18/2013 02:12 PM, Dash Four wrote:> > > Tom Eastep wrote: >>> Erm, you''ve lost me. What does that mean? >>> >> >> It means that it is not really feasible to sync the loaded helper >> modules with the HELPERS option. >> > Got it, thanks. > > > >>> OK, so if I use iptables targets (which appear as kernel modules) and >>> don''t need any "helpers" loaded, in order to prevent shorewall from >>> loading anything else (well, anything apart from the "essential" modules >>> - not sure if iptables would load these automatically!) while starting >>> my firewall successfully, all I have to do is: >>> >>> HELPERS=none >>> LOAD_HELPERS_ONLY=Yes >>> >>> Correct, or am I going to have my fingers burned? >>> >> >> That will work, provided that you have module autoloading enabled in >> your kernel and you have an empty ''modules'' file in /etc/shorewall/; in >> that case, Shorewall won''t load a thing. >> > And my firewall will start successfully, right? >Yep. -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 \________________________________________________ ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter
Dash Four wrote:> >> Patch attached. >> > Wow, that was pretty quick and it works to perfection, thanks Tom.One suggestion with regards to this: due to the nature of that nfacct match, would it be possible to "combine" nfacct targets in single rules? One example to illustrate a use-case: Suppose I need to have 4 nfacct matches called "all_in", "all_out", "all_fwd" and "all". With the current structure of "accounting", I have to do the following: SECTION INPUT NFACCT(all) NFACCT(all_in) SECTION OUTPUT NFACCT(all) NFACCT(all_out) SECTION FORWARD NFACCT(all) NFACCT(all_fwd) The above will produce 6 different rules, which will be traversed one after the other, like so: -A accountin -m nfacct --nfacct-name all -A accountin -m nfacct --nfacct-name all_in -A accountout -m nfacct --nfacct-name all -A accountout -m nfacct --nfacct-name all_out -A accountfwd -m nfacct --nfacct-name all -A accountfwd -m nfacct --nfacct-name all_fwd It would be much more efficient if I could have these combined into 3 rules producing the same effect, like so: -A accountin -m nfacct --nfacct-name all -m nfacct --nfacct-name all_in -A accountout -m nfacct --nfacct-name all -m nfacct --nfacct-name all_out accountin -A accountfwd -m nfacct --nfacct-name all -m nfacct --nfacct-name all_fwd That way I won''t get penalised unnecessary (for having to traverse 3 extra rules) and my throughput will be more. Another very good example of where "stacked-up" nfacct matches can be useful is with the following example: Suppose I need to have 4 nfacct matches: "dmz_in", "dmz_out", "dmz_fwd" (for all traffic to/from/forwarded from/to my dmz subnet) and another match called "all" counting all traffic. In its current form, the "accounting" will look like this: SECTION INPUT NFACCT(all) NFACCT(dmz_in) - +dmz-net SECTION OUTPUT NFACCT(all) NFACCT(dmz_out) - - +dmz-net SECTION FORWARD NFACCT(all) NFACCT(dmz_fwd) - +dmz-net NFACCT(dmz_fwd) - - +dmz-net The above will produce 7 different rules as follows: -A accountin -m nfacct --nfacct-name all -A accountin -m set --match-set dmz-net src -m nfacct --nfacct-name dmz_in -A accountout -m nfacct --nfacct-name all -A accountout -m set --match-set dmz-net dst -m nfacct --nfacct-name dmz_out -A accountfwd -m nfacct --nfacct-name all -A accountfwd -m set --match-set dmz-net src -m nfacct --nfacct-name dmz_fwd -A accountfwd -m set --match-set dmz-net dst -m nfacct --nfacct-name dmz_fwd The above can be "squeezed" into 4 rules, like so: -A accountin -m nfacct --nfacct-name all -m set --match-set dmz-net src -m nfacct --nfacct-name dmz_in -A accountout -m nfacct --nfacct-name all -m set --match-set dmz-net dst -m nfacct --nfacct-name dmz_out -A accountfwd -m nfacct --nfacct-name all -m set --match-set dmz-net src -m nfacct --nfacct-name dmz_fwd -A accountfwd -m set --match-set dmz-net dst -m nfacct --nfacct-name dmz_fwd making it much more efficient. If you decide to do this, it won''t be a walk in the park though, so I would suggest to leave it to the user to implement the order in which the matches are created. ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter
On 04/18/2013 02:45 PM, Dash Four wrote:> > > Dash Four wrote: >> >>> Patch attached. >>> >> Wow, that was pretty quick and it works to perfection, thanks Tom. > One suggestion with regards to this: due to the nature of that nfacct > match, would it be possible to "combine" nfacct targets in single rules? > One example to illustrate a use-case: > > Suppose I need to have 4 nfacct matches called "all_in", "all_out", > "all_fwd" and "all". With the current structure of "accounting", I have > to do the following: > > SECTION INPUT > NFACCT(all) > NFACCT(all_in) > > SECTION OUTPUT > NFACCT(all) > NFACCT(all_out) > > SECTION FORWARD > NFACCT(all) > NFACCT(all_fwd) > > The above will produce 6 different rules, which will be traversed one > after the other, like so: > > -A accountin -m nfacct --nfacct-name all > -A accountin -m nfacct --nfacct-name all_in > -A accountout -m nfacct --nfacct-name all > -A accountout -m nfacct --nfacct-name all_out > -A accountfwd -m nfacct --nfacct-name all > -A accountfwd -m nfacct --nfacct-name all_fwd > > It would be much more efficient if I could have these combined into 3 > rules producing the same effect, like so: > > -A accountin -m nfacct --nfacct-name all -m nfacct --nfacct-name all_in > -A accountout -m nfacct --nfacct-name all -m nfacct --nfacct-name > all_out accountin > -A accountfwd -m nfacct --nfacct-name all -m nfacct --nfacct-name all_fwd > > That way I won''t get penalised unnecessary (for having to traverse 3 > extra rules) and my throughput will be more.Patch attached. You would specify the above as: SECTION INPUT NFACCT(all,all_in) SECTION OUTPUT NFACCT(all,all_out) SECTION FORWARD NFACCT(all,all_fwd)> Another very good example of where "stacked-up" nfacct matches can be > useful is with the following example: > > Suppose I need to have 4 nfacct matches: "dmz_in", "dmz_out", "dmz_fwd" > (for all traffic to/from/forwarded from/to my dmz subnet) and another > match called "all" counting all traffic. In its current form, the > "accounting" will look like this: > > SECTION INPUT > NFACCT(all) > NFACCT(dmz_in) - +dmz-net > > SECTION OUTPUT > NFACCT(all) > NFACCT(dmz_out) - - +dmz-net > > SECTION FORWARD > NFACCT(all) > NFACCT(dmz_fwd) - +dmz-net > NFACCT(dmz_fwd) - - +dmz-net > > The above will produce 7 different rules as follows: > > -A accountin -m nfacct --nfacct-name all > -A accountin -m set --match-set dmz-net src -m nfacct --nfacct-name dmz_in > -A accountout -m nfacct --nfacct-name all > -A accountout -m set --match-set dmz-net dst -m nfacct --nfacct-name dmz_out > -A accountfwd -m nfacct --nfacct-name all > -A accountfwd -m set --match-set dmz-net src -m nfacct --nfacct-name dmz_fwd > -A accountfwd -m set --match-set dmz-net dst -m nfacct --nfacct-name dmz_fwd > > The above can be "squeezed" into 4 rules, like so: > > -A accountin -m nfacct --nfacct-name all -m set --match-set dmz-net src > -m nfacct --nfacct-name dmz_in > -A accountout -m nfacct --nfacct-name all -m set --match-set dmz-net dst > -m nfacct --nfacct-name dmz_out > -A accountfwd -m nfacct --nfacct-name all -m set --match-set dmz-net src > -m nfacct --nfacct-name dmz_fwd > -A accountfwd -m set --match-set dmz-net dst -m nfacct --nfacct-name dmz_fwd > > making it much more efficient. If you decide to do this, it won''t be a > walk in the park though, so I would suggest to leave it to the user to > implement the order in which the matches are created.You can''t have it both ways. You cannot have nfacct always last and nfacct interspersed in the order specified. -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 \________________________________________________ ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter
Tom Eastep wrote:> On 04/18/2013 02:45 PM, Dash Four wrote: > >> Dash Four wrote: >> >>>> Patch attached. >>>> >>>> >>> Wow, that was pretty quick and it works to perfection, thanks Tom. >>> >> One suggestion with regards to this: due to the nature of that nfacct >> match, would it be possible to "combine" nfacct targets in single rules? >> One example to illustrate a use-case: >> >> Suppose I need to have 4 nfacct matches called "all_in", "all_out", >> "all_fwd" and "all". With the current structure of "accounting", I have >> to do the following: >> >> SECTION INPUT >> NFACCT(all) >> NFACCT(all_in) >> >> SECTION OUTPUT >> NFACCT(all) >> NFACCT(all_out) >> >> SECTION FORWARD >> NFACCT(all) >> NFACCT(all_fwd) >> >> The above will produce 6 different rules, which will be traversed one >> after the other, like so: >> >> -A accountin -m nfacct --nfacct-name all >> -A accountin -m nfacct --nfacct-name all_in >> -A accountout -m nfacct --nfacct-name all >> -A accountout -m nfacct --nfacct-name all_out >> -A accountfwd -m nfacct --nfacct-name all >> -A accountfwd -m nfacct --nfacct-name all_fwd >> >> It would be much more efficient if I could have these combined into 3 >> rules producing the same effect, like so: >> >> -A accountin -m nfacct --nfacct-name all -m nfacct --nfacct-name all_in >> -A accountout -m nfacct --nfacct-name all -m nfacct --nfacct-name >> all_out accountin >> -A accountfwd -m nfacct --nfacct-name all -m nfacct --nfacct-name all_fwd >> >> That way I won''t get penalised unnecessary (for having to traverse 3 >> extra rules) and my throughput will be more. >> > > Patch attached. You would specify the above as: > > SECTION INPUT > NFACCT(all,all_in) > > SECTION OUTPUT > NFACCT(all,all_out) > > SECTION FORWARD > NFACCT(all,all_fwd) >I presume if I include conditions (like +dmz-net in SOURCE or DEST for example), I would see these preceding the nfacct match right?>> Another very good example of where "stacked-up" nfacct matches can be >> useful is with the following example: >> >> Suppose I need to have 4 nfacct matches: "dmz_in", "dmz_out", "dmz_fwd" >> (for all traffic to/from/forwarded from/to my dmz subnet) and another >> match called "all" counting all traffic. In its current form, the >> "accounting" will look like this: >> >> SECTION INPUT >> NFACCT(all) >> NFACCT(dmz_in) - +dmz-net >> >> SECTION OUTPUT >> NFACCT(all) >> NFACCT(dmz_out) - - +dmz-net >> >> SECTION FORWARD >> NFACCT(all) >> NFACCT(dmz_fwd) - +dmz-net >> NFACCT(dmz_fwd) - - +dmz-net >> >> The above will produce 7 different rules as follows: >> >> -A accountin -m nfacct --nfacct-name all >> -A accountin -m set --match-set dmz-net src -m nfacct --nfacct-name dmz_in >> -A accountout -m nfacct --nfacct-name all >> -A accountout -m set --match-set dmz-net dst -m nfacct --nfacct-name dmz_out >> -A accountfwd -m nfacct --nfacct-name all >> -A accountfwd -m set --match-set dmz-net src -m nfacct --nfacct-name dmz_fwd >> -A accountfwd -m set --match-set dmz-net dst -m nfacct --nfacct-name dmz_fwd >> >> The above can be "squeezed" into 4 rules, like so: >> >> -A accountin -m nfacct --nfacct-name all -m set --match-set dmz-net src >> -m nfacct --nfacct-name dmz_in >> -A accountout -m nfacct --nfacct-name all -m set --match-set dmz-net dst >> -m nfacct --nfacct-name dmz_out >> -A accountfwd -m nfacct --nfacct-name all -m set --match-set dmz-net src >> -m nfacct --nfacct-name dmz_fwd >> -A accountfwd -m set --match-set dmz-net dst -m nfacct --nfacct-name dmz_fwd >> >> making it much more efficient. If you decide to do this, it won''t be a >> walk in the park though, so I would suggest to leave it to the user to >> implement the order in which the matches are created. >> > > You can''t have it both ways. You cannot have nfacct always last and > nfacct interspersed in the order specified. >Of course not, that wasn''t my intention. I was thinking of having a way of "combining" these statements. If I was able to do that, then in the above example I could have something like: SECTION FORWARD NFACCT(all) \ NFACCT(dmz_fwd) - +dmz-net NFACCT(dmz_fwd) - - +dmz-net Note that the use of "\" (or any other "appropriate" symbol) is to indicate to shorewall to "combine" the rules into a single iptables statement. That would translate to: -A accountfwd -m nfacct --nfacct-name all -m set --match-set dmz-net src -m nfacct --nfacct-name dmz_fwd Even if there are conditions for the first NFACCT rule, they will precede these for the second, like so: SECTION FORWARD NFACCT(not_all) - +sub-net \ NFACCT(dmz_fwd) - +dmz-net That would be translated to: -A accountfwd -m set --match-set sub-net src -m nfacct --nfacct-name not_all -m set --match-set dmz-net src -m nfacct --nfacct-name dmz_fwd As I already indicated earlier, this certainly isn''t easy, but if implemented properly, it would be more efficient as there are less rules to traverse - with accounting that is of importance since all packets normally pass through these chains. ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter
On 4/18/13 4:15 PM, "Dash Four" <mr.dash.four@googlemail.com> wrote:> >I presume if I include conditions (like +dmz-net in SOURCE or DEST for >example), I would see these preceding the nfacct match right?Correct. There is a fix for that feature attached.>Of course not, that wasn''t my intention. I was thinking of having a way >of "combining" these statements. If I was able to do that, then in the >above example I could have something like: > >SECTION FORWARD >NFACCT(all) \ >NFACCT(dmz_fwd) - +dmz-net >NFACCT(dmz_fwd) - - +dmz-net > >Note that the use of "\" (or any other "appropriate" symbol) is to >indicate to shorewall to "combine" the rules into a single iptables >statement. That would translate to: > >-A accountfwd -m nfacct --nfacct-name all -m set --match-set dmz-net src >-m nfacct --nfacct-name dmz_fwd > >Even if there are conditions for the first NFACCT rule, they will >precede these for the second, like so: > >SECTION FORWARD >NFACCT(not_all) - +sub-net \ >NFACCT(dmz_fwd) - +dmz-net > >That would be translated to: > >-A accountfwd -m set --match-set sub-net src -m nfacct --nfacct-name >not_all -m set --match-set dmz-net src -m nfacct --nfacct-name dmz_fwd > >As I already indicated earlier, this certainly isn''t easy, but if >implemented properly, it would be more efficient as there are less rules >to traverse - with accounting that is of importance since all packets >normally pass through these chains.Let me think about it a while... -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter
Tom Eastep wrote:> On 4/18/13 4:15 PM, "Dash Four" <mr.dash.four@googlemail.com> wrote: > > >> I presume if I include conditions (like +dmz-net in SOURCE or DEST for >> example), I would see these preceding the nfacct match right? >> > > Correct. There is a fix for that feature attached. >Thanks, though I will hold-on to this for the time being as the solution below is much better (your patch would be "plan B" if you like).>> As I already indicated earlier, this certainly isn''t easy, but if >> implemented properly, it would be more efficient as there are less rules >> to traverse - with accounting that is of importance since all packets >> normally pass through these chains. >> > > Let me think about it a while... >No problem, take your time - I know it isn''t straight-forward, but I think it would be worth it in the end as there is a lot to be gained, certainly from a performance point of view. ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter
On 04/18/2013 04:47 PM, Dash Four wrote:>> Let me think about it a while... >> > No problem, take your time - I know it isn''t straight-forward, but I > think it would be worth it in the end as there is a lot to be gained, > certainly from a performance point of view.The attached small patch allows for incrementing an nfacct counter when an IPSET is match. For some time, the following has been supported: +"["{<set>["["<src-dst-list>"]"]}[,...]"]" where "[" and "]" are square brackets while [ and ] are meta-symbols. The new syntax is: +"["{<set>["["<src-dst-list>"]"][(<nfacct-object-list>)]} [,...]"]" Your original rule list was: SECTION INPUT NFACCT(all) NFACCT(dmz_in) - +dmz-net SECTION OUTPUT NFACCT(all) NFACCT(dmz_out) - - +dmz-net SECTION FORWARD NFACCT(all) NFACCT(dmz_fwd) - +dmz-net NFACCT(dmz_fwd) - - +dmz-net With this patch, you can now have: SECTION INPUT NFACCT(all) - +[dmz-net(dmz_in)] SECTION OUTPUT NFACCT(all) - - +[dmz-net(dmz_out)] SECTION FORWARD NFACCT(all) - +[dmz-net(dmz_fwd)] COUNT - - +[dmz-net(dmz_fwd)] This set of rules produces: -A accountfwd -m nfacct --nfacct-name all -m set --match-set dmz-net \ src -m nfacct --nfacct-name dmz_fwd -A accountfwd -m set --match-set dmz-net(dmz_fwd) dst -A accountin -m nfacct --nfacct-name all \ -m set --match-set dmz-net src -m nfacct --nfacct-name dmz_in -A accountout -m nfacct --nfacct-name all -m set --match-set \ dmz-net(dmz_out) dst One consequence of this patch is that now both ''set'' and ''nfacct'' go to the end of the rule. Another thing to note is that this feature can be used anywhere that ipsets are allowed; it is not restricted to the accounting file. Finally, the +[....] form must be used; +<set>...(<nfacct-object-list>) is not supported. -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 \________________________________________________ ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter
On 04/19/2013 09:51 AM, Tom Eastep wrote:> On 04/18/2013 04:47 PM, Dash Four wrote: > >>> Let me think about it a while... >>> >> No problem, take your time - I know it isn''t straight-forward, but I >> think it would be worth it in the end as there is a lot to be gained, >> certainly from a performance point of view. > > The attached small patch allows for incrementing an nfacct counter when > an IPSET is match. > > For some time, the following has been supported: > > +"["{<set>["["<src-dst-list>"]"]}[,...]"]" > > where "[" and "]" are square brackets while [ and ] are meta-symbols. > > The new syntax is: > > +"["{<set>["["<src-dst-list>"]"][(<nfacct-object-list>)]} > [,...]"]" > > > Your original rule list was: > > SECTION INPUT > NFACCT(all) > NFACCT(dmz_in) - +dmz-net > > SECTION OUTPUT > NFACCT(all) > NFACCT(dmz_out) - - +dmz-net > > SECTION FORWARD > NFACCT(all) > NFACCT(dmz_fwd) - +dmz-net > NFACCT(dmz_fwd) - - +dmz-net > > With this patch, you can now have: > > SECTION INPUT > NFACCT(all) - +[dmz-net(dmz_in)] > > SECTION OUTPUT > NFACCT(all) - - +[dmz-net(dmz_out)] > > SECTION FORWARD > NFACCT(all) - +[dmz-net(dmz_fwd)] > COUNT - - +[dmz-net(dmz_fwd)] > > This set of rules produces: > > -A accountfwd -m nfacct --nfacct-name all -m set --match-set dmz-net \ > src -m nfacct --nfacct-name dmz_fwd > -A accountfwd -m set --match-set dmz-net(dmz_fwd) dst > -A accountin -m nfacct --nfacct-name all \ > -m set --match-set dmz-net src -m nfacct --nfacct-name dmz_in > -A accountout -m nfacct --nfacct-name all -m set --match-set \ > dmz-net(dmz_out) dst > > One consequence of this patch is that now both ''set'' and ''nfacct'' go to > the end of the rule. > > Another thing to note is that this feature can be used anywhere that > ipsets are allowed; it is not restricted to the accounting file. > > Finally, the +[....] form must be used; > +<set>...(<nfacct-object-list>) is not supported.Please hold off on this for a while -- I just realized that it is incomplete. -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 \________________________________________________ ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter
On 4/19/13 10:13 AM, "Tom Eastep" <teastep@shorewall.net> wrote:>On 04/19/2013 09:51 AM, Tom Eastep wrote: >> On 04/18/2013 04:47 PM, Dash Four wrote: >> >>>> Let me think about it a while... >>>> >>> No problem, take your time - I know it isn''t straight-forward, but I >>> think it would be worth it in the end as there is a lot to be gained, >>> certainly from a performance point of view. >> >> The attached small patch allows for incrementing an nfacct counter when >> an IPSET is match. >> >> For some time, the following has been supported: >> >> +"["{<set>["["<src-dst-list>"]"]}[,...]"]" >> >> where "[" and "]" are square brackets while [ and ] are meta-symbols. >> >> The new syntax is: >> >> +"["{<set>["["<src-dst-list>"]"][(<nfacct-object-list>)]} >> [,...]"]" >> >> >> Your original rule list was: >> >> SECTION INPUT >> NFACCT(all) >> NFACCT(dmz_in) - +dmz-net >> >> SECTION OUTPUT >> NFACCT(all) >> NFACCT(dmz_out) - - +dmz-net >> >> SECTION FORWARD >> NFACCT(all) >> NFACCT(dmz_fwd) - +dmz-net >> NFACCT(dmz_fwd) - - +dmz-net >> >> With this patch, you can now have: >> >> SECTION INPUT >> NFACCT(all) - +[dmz-net(dmz_in)] >> >> SECTION OUTPUT >> NFACCT(all) - - +[dmz-net(dmz_out)] >> >> SECTION FORWARD >> NFACCT(all) - +[dmz-net(dmz_fwd)] >> COUNT - - +[dmz-net(dmz_fwd)] >> >> This set of rules produces: >> >> -A accountfwd -m nfacct --nfacct-name all -m set --match-set dmz-net \ >> src -m nfacct --nfacct-name dmz_fwd >> -A accountfwd -m set --match-set dmz-net(dmz_fwd) dst >> -A accountin -m nfacct --nfacct-name all \ >> -m set --match-set dmz-net src -m nfacct --nfacct-name dmz_in >> -A accountout -m nfacct --nfacct-name all -m set --match-set \ >> dmz-net(dmz_out) dst >> >> One consequence of this patch is that now both ''set'' and ''nfacct'' go to >> the end of the rule. >> >> Another thing to note is that this feature can be used anywhere that >> ipsets are allowed; it is not restricted to the accounting file. >> >> Finally, the +[....] form must be used; >> +<set>...(<nfacct-object-list>) is not supported. > > >Please hold off on this for a while -- I just realized that it is >incomplete.Okay -- here is the complete patch. This also allows the simple form: Rules: SECTION INPUT NFACCT(all) - +dmz-net(dmz_in) SECTION OUTPUT NFACCT(all) - - +dmz-net(dmz_out) SECTION FORWARD NFACCT(all) - +dmz-net(dmz_fwd) COUNT - - +dmz-net(dmz_fwd) Which produce: -A accountfwd -m nfacct --nfacct-name all -m set --match-set dmz-net src -m nfacct --nfacct-name dmz_fwd -A accountfwd -m set --match-set dmz-net dst -m nfacct --nfacct-name dmz_fwd -A accountin -m nfacct --nfacct-name all -m set --match-set dmz-net src -m nfacct --nfacct-name dmz_in -A accountout -m nfacct --nfacct-name all -m set --match-set dmz-net dst -m nfacct --nfacct-name dmz_out -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter
On 04/19/2013 10:26 AM, Tom Eastep wrote:> Okay -- here is the complete patch. > > This also allows the simple form: > > Rules: > > SECTION INPUT > NFACCT(all) - +dmz-net(dmz_in) > > SECTION OUTPUT > NFACCT(all) - - +dmz-net(dmz_out) > > SECTION FORWARD > NFACCT(all) - +dmz-net(dmz_fwd) > COUNT - - +dmz-net(dmz_fwd)Note that with this patch, you *must* use the above form rather than: NFACCT(dmz_fwd) - - +dmz-net In this form, the ipset match gets added to the rule *after* the nfacct match. -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 \________________________________________________ ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter
On 04/19/2013 10:34 AM, Tom Eastep wrote:> On 04/19/2013 10:26 AM, Tom Eastep wrote: > >> Okay -- here is the complete patch. >> >> This also allows the simple form: >> >> Rules: >> >> SECTION INPUT >> NFACCT(all) - +dmz-net(dmz_in) >> >> SECTION OUTPUT >> NFACCT(all) - - +dmz-net(dmz_out) >> >> SECTION FORWARD >> NFACCT(all) - +dmz-net(dmz_fwd) >> COUNT - - +dmz-net(dmz_fwd) > > Note that with this patch, you *must* use the above form rather than: > > NFACCT(dmz_fwd) - - +dmz-net > > In this form, the ipset match gets added to the rule *after* the nfacct > match. >That is corrected in this additional 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 \________________________________________________ ------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter