On 4/11/13 4:07 PM, "Mr Dash Four" <mr.dash.f...@googlemail.com> wrote:
>Mr Dash Four wrote: >> All good. I'll have more time later when I get home and will be able >> to give it a more thorough testing this time. >So far (much better results this time!)... > > >1. >rules >~~~~~ >INLINE $FW net ; -j SECCTX --name test2 > >produces what was expected, but it is worth noting that I do *not* have >"SECCTX builtin" in my "actions" (not that I am complaining, of course - >I like it!) I have fixed that but my tree has advanced to the point that the patch won't apply to Beta 3. > >2. >rules >~~~~~ >INLINE $FW net ; -m mickey-mouse --name test2 > >produces > >-A fw2net -m mickey -mouse --name test2 > >Note the space between "mickey" and "-mouse" - I expected either "-A >fw2net -m mickey-mouse --name test2" or an error if match names in >iptables cannot have a dash (-) Patch attached. > >3. >rules >~~~~~ >INLINE $FW:10.1.1.1 net:+mickey-mouse ; -m mouse --name test2 > >produces > >-A fw2net -s 10.1.1.1 -m mouse --name test2 -m set --match-set >mickey-mouse dst > >Now, I would like to have the bit after ";" appear last (in other words, >appended to the "normal" shorewall statement) and not, as it is in the >above example, slammed in the middle. > >Why is this important? Because some matches (nfacct "match" being a >prime example of that "technique") are not really "matches" (they always >return true) and therefore, if I have a similar match to the nfacct >"match" (I do use 2 such "custom" matches here), then the whole rule >logic is going to be screwed up. In other words: > >INLINE $FW:10.1.1.1 net:+mickey-mouse ; -m mouse --name test2 > >should produce > >-A fw2net -s 10.1.1.1 -m set --match-set mickey-mouse dst -m mouse >--name test2 (correct, as "-m mouse" executes only if "-s 10.1.1.1" >*and* "-m set --match-set mickey-mouse dst" return true) > >and not produce > >-A fw2net -s 10.1.1.1 -m mouse --name test2 -m set --match-set >mickey-mouse dst (incorrect, as "-m mouse --name test2" executes when >"-s 10.1.1.1" is satisfied, but the ipset match has not been checked yet). This is going to be surprisingly difficult. I'll need some time to determine what (if anything) is possible. > >4. >rules >~~~~~ >INLINE $FW net tcp - 2345 ; -j SSS --dport 1234 -m mouse --name test2 > >produces > >-A fw2net -p 6 --dport 1234 --sport 2345 -m mouse --name test2 -j SSS > >Shouldn't the above raise an error as after the "-j" everything should >be considered parameters to the target specified - SSS in the above >example? > >Not that I am complaining, because "-m" normally indicates the start of >a match and "--dport" is also a "standard" match as well, so I suspect >shorewall parses everything after ";" (and does that pretty well, it >seems), which is illustrated by this test case: > >rules >~~~~~ >INLINE $FW net tcp - 2345 ; -j SSS --test2 1234 -m mouse --name test2 > >produces > >-A fw2net -p 6 --sport 2345 -m mouse --name test2 -j SSS --test2 1234 I think that I'll leave this as it is. Shorewall understands --dport which is why this works the way it does. -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice.
DASH.patch
Description: Binary data
------------------------------------------------------------------------------ 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
_______________________________________________ Shorewall-devel mailing list Shorewall-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-devel
