Is there a possibility to include ''raw'' iptables statements
directly
(the stuff which goes after "-A <chain>") by shorewall? For
example,
specifying something like INLINE(''-m <match 1> <match 1
parameters> -m
<match 2> <match 2 parameters> [...] -j ACCEPT''), which
shorewall takes
and inserts after the appropriate "-A" and chain arguments without any
modification. Obviously, I understand that optimisation of such
statements will be non-existent, but I am willing to take that hit.
The reason I ask for this is because I have quite a lot of new features
which by the looks of things and also judging by the snail-pace with
which these are adopted (or not) by netfilter ''core'' team it
takes
absolute ages to get mainline. In the meantime I need these for my own
machines and need to be able to deploy them as quickly as possible.
Currently, I have only your postcompile feature to work with Tom, but
that isn''t always the most easy thing to do or the most
practical/straight forward. Thanks.
------------------------------------------------------------------------------
Minimize network downtime and maximize team effectiveness.
Reduce network management and security costs.Learn how to hire
the most talented Cisco Certified professionals. Visit the
Employer Resources Portal
http://www.cisco.com/web/learning/employer_resources/index.html
On 4/7/13 4:21 PM, "Mr Dash Four" <mr.dash.four@googlemail.com> wrote:>Is there a possibility to include ''raw'' iptables statements directly >(the stuff which goes after "-A <chain>") by shorewall? For example, >specifying something like INLINE(''-m <match 1> <match 1 parameters> -m ><match 2> <match 2 parameters> [...] -j ACCEPT''), which shorewall takes >and inserts after the appropriate "-A" and chain arguments without any >modification. Obviously, I understand that optimisation of such >statements will be non-existent, but I am willing to take that hit. > >The reason I ask for this is because I have quite a lot of new features >which by the looks of things and also judging by the snail-pace with >which these are adopted (or not) by netfilter ''core'' team it takes >absolute ages to get mainline. In the meantime I need these for my own >machines and need to be able to deploy them as quickly as possible. > >Currently, I have only your postcompile feature to work with Tom, but >that isn''t always the most easy thing to do or the most >practical/straight forward. Thanks.Are there particular Shorewall configuration files that you require this feature in? -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html
> Are there particular Shorewall configuration files that you require this > feature in? >The most pressing need, at least for the time being, is ''rules'' and ''blrules''. Later on, ''masq'' and probably ''conntrack''. The last bit (which currently is in my ''nice-to-have'' list) is the whole range of traffic-shaping, but that is way off (we are talking probably a couple of months). I need to take advantage of the state and chain auto-naming in shorewall. In other words, to let shorewall determine which chain (and in which state since that can be specified in ''rules'' and ''blrules'') to place this inline statement in and for me to just write it out. Again though, I am not really bothered if I don''t have any optimisation/error-checking as such - if there is a screw-up in that inline statement, I am going to accept that. Is this doable? ------------------------------------------------------------------------------ Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html
On 4/7/13 6:54 PM, "Mr Dash Four" <mr.dash.four@googlemail.com> wrote:> >> Are there particular Shorewall configuration files that you require this >> feature in? >> >The most pressing need, at least for the time being, is ''rules'' and >''blrules''. Later on, ''masq'' and probably ''conntrack''. The last bit >(which currently is in my ''nice-to-have'' list) is the whole range of >traffic-shaping, but that is way off (we are talking probably a couple >of months). > >I need to take advantage of the state and chain auto-naming in >shorewall. In other words, to let shorewall determine which chain (and >in which state since that can be specified in ''rules'' and ''blrules'') to >place this inline statement in and for me to just write it out. Again >though, I am not really bothered if I don''t have any >optimisation/error-checking as such - if there is a screw-up in that >inline statement, I am going to accept that. Is this doable?It is doable, and optimization will happen automatically. The biggest effort will be in parsing. Because of the tabular format of the Shorewall files, the rules compiler doesn''t have a LR lexical analyzer. It rather splits the line on whitespace and then analyzes each ''column''. So embedded whitespace in the contents of a column is problematic. The code already has to deal with a similar problem when parsing the parameters to a action where it is splitting the parameters on commas, so no new algorithm should be needed. -Tom You do not need a parachute to skydive. You only need a parachute to skydive twice. ------------------------------------------------------------------------------ Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html
> It is doable, and optimization will happen automatically. The biggest > effort will be in parsing. > > Because of the tabular format of the Shorewall files, the rules compiler > doesn''t have a LR lexical analyzer. It rather splits the line on > whitespace and then analyzes each ''column''. So embedded whitespace in the > contents of a column is problematic.I don''t know much about perl (as you know), but is there a notion for a "quoted string" in it? In other words, only consider spaces if they are not quoted (allowing for escaping, in other words "something else", as well as "\"and so on"). If there isn''t such functionality built-in, then you can devise it as a separate function so that every bit of "string" during the parsing process is passed through that function first and then you can break it into tokens. At least that is how I will do it in C.> The code already has to deal with a > similar problem when parsing the parameters to a action where it is > splitting the parameters on commas, so no new algorithm should be needed. >Indeed. "one,two,three and more" should be passed on as one argument, but one,two,three and more should produce 3 parameters (based on a comma separation) or 3 arguments based on space separation. ------------------------------------------------------------------------------ Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html
> I don''t know much about perl (as you know), but is there a notion for > a "quoted string" in it? In other words, only consider spaces if they > are not quoted (allowing for escaping, in other words "something > else", as well as "\"and so on"). If there isn''t such functionality > built-in, then you can devise it as a separate function so that every > bit of "string" during the parsing process is passed through that > function first and then you can break it into tokens. At least that is > how I will do it in C.Alternatively (if the above is a bit difficult to do), you may consider the following, which may be less difficult to process: INLINE <src> <dst> # -m <match 1> -m <match 2> ... -j ACCEPT That way, you just parse the src and dst to determine the chain in which to insert the inline statement (''src'' or ''dst'' should not contain anything other that a zone, mind!) and then take whatever is after the ''#'' character and include it after the ''-A <chain>'' statement. Would that be easier? ------------------------------------------------------------------------------ Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html
On 04/08/2013 07:41 AM, Mr Dash Four wrote:> >> I don''t know much about perl (as you know), but is there a notion for >> a "quoted string" in it? In other words, only consider spaces if they >> are not quoted (allowing for escaping, in other words "something >> else", as well as "\"and so on"). If there isn''t such functionality >> built-in, then you can devise it as a separate function so that every >> bit of "string" during the parsing process is passed through that >> function first and then you can break it into tokens. At least that is >> how I will do it in C. > Alternatively (if the above is a bit difficult to do), you may consider > the following, which may be less difficult to process: > > INLINE <src> <dst> # -m <match 1> -m <match 2> ... -j ACCEPT > > That way, you just parse the src and dst to determine the chain in which > to insert the inline statement (''src'' or ''dst'' should not contain > anything other that a zone, mind!) and then take whatever is after the > ''#'' character and include it after the ''-A <chain>'' statement. Would > that be easier?I was thinking about that as well, and it would indeed be easier. How about this: ACCEPT <src> <dst> ; MATCH -m <match 1> -m <match 2> ... The preprocessor already looks for '';'' and the MATCH keyword would trigger the new interpretation of the text that follows. I would prefer to keep the rule target (the ''-j ...'' part) in the ACTION column if possible. -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 \________________________________________________ ------------------------------------------------------------------------------ Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html
> I was thinking about that as well, and it would indeed be easier. > > How about this: > > ACCEPT <src> <dst> ; MATCH -m <match 1> -m <match 2> ... > > The preprocessor already looks for '';'' and the MATCH keyword would > trigger the new interpretation of the text that follows. >Yep, I agree, though the ''MATCH'' word may not be present at all, so the trigger, if you like, could be the ''INLINE'' keyword, i.e.: INLINE <src> <dst> ; ... (see my next comment).> I would prefer to keep the rule target (the ''-j ...'' part) in the ACTION > column if possible. >Nope, that would prevent me from using custom-made targets (something like ''-j SECCTX --name <name>'' for example). ------------------------------------------------------------------------------ Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html
On 4/8/13 8:01 AM, "Mr Dash Four" <mr.dash.four@googlemail.com> wrote:> >> I was thinking about that as well, and it would indeed be easier. >> >> How about this: >> >> ACCEPT <src> <dst> ; MATCH -m <match 1> -m <match 2> ... >> >> The preprocessor already looks for '';'' and the MATCH keyword would >> trigger the new interpretation of the text that follows. >> >Yep, I agree, though the ''MATCH'' word may not be present at all, so the >trigger, if you like, could be the ''INLINE'' keyword, i.e.: > >INLINE <src> <dst> ; ... (see my next comment). > >> I would prefer to keep the rule target (the ''-j ...'' part) in the ACTION >> column if possible. >> >Nope, that would prevent me from using custom-made targets (something >like ''-j SECCTX --name <name>'' for example).Okay -- I''ve implemented the following: 3) 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> Example: INLINE $FW all tcp 1234 ; -j SETCTX --name foo As part of this change, a new ''builtin'' action type has been added. ip[6]tables actions not supported by Shorewall (such as ''SETCTX'' in the example above), must be defined in your /etc/shorewall[6]/actions file. Example: SETCTX builtin Is this what you had in mind? -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/8/13 5:48 PM, "Tom Eastep" <teastep@shorewall.net> wrote:>On 4/8/13 8:01 AM, "Mr Dash Four" <mr.dash.four@googlemail.com> wrote: > >> >>> I was thinking about that as well, and it would indeed be easier. >>> >>> How about this: >>> >>> ACCEPT <src> <dst> ; MATCH -m <match 1> -m <match 2> ... >>> >>> The preprocessor already looks for '';'' and the MATCH keyword would >>> trigger the new interpretation of the text that follows. >>> >>Yep, I agree, though the ''MATCH'' word may not be present at all, so the >>trigger, if you like, could be the ''INLINE'' keyword, i.e.: >> >>INLINE <src> <dst> ; ... (see my next comment). >> >>> I would prefer to keep the rule target (the ''-j ...'' part) in the >>>ACTION >>> column if possible. >>> >>Nope, that would prevent me from using custom-made targets (something >>like ''-j SECCTX --name <name>'' for example). > >Okay -- I''ve implemented the following: > >3) 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> > > Example: > > INLINE $FW all tcp 1234 ; -j SETCTX --name foo > > As part of this change, a new ''builtin'' action type has been added. > ip[6]tables actions not supported by Shorewall (such as ''SETCTX'' in > the example above), must be defined in your > /etc/shorewall[6]/actions file. > > Example: > > SETCTX builtin > > >Is this what you had in mind?BTW, with OPTIMIZE=31, the following rules are generated in my configuration: -A fw-dmz -p 6 --dport 1234 -j SETCTX --name foo -A fw-loc -p 6 --dport 1234 -j SETCTX --name foo -A fw-net -p 6 --dport 1234 -j SETCTX --name foo -A fw-smc -p 6 --dport 1234 -j SETCTX --name foo -A fw-vpn -p 6 --dport 1234 -j SETCTX --name foo -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
>>> Nope, that would prevent me from using custom-made targets (something >>> like ''-j SECCTX --name <name>'' for example). >>> >> Okay -- I''ve implemented the following: >> >> 3) 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> >> >> Example: >> >> INLINE $FW all tcp 1234 ; -j SETCTX --name foo >> >> As part of this change, a new ''builtin'' action type has been added. >> ip[6]tables actions not supported by Shorewall (such as ''SETCTX'' in >> the example above), must be defined in your >> /etc/shorewall[6]/actions file. >> >> Example: >> >> SETCTX builtin >> >> >> Is this what you had in mind? >> > > BTW, with OPTIMIZE=31, the following rules are generated in my > configuration: > > -A fw-dmz -p 6 --dport 1234 -j SETCTX --name foo > -A fw-loc -p 6 --dport 1234 -j SETCTX --name foo > -A fw-net -p 6 --dport 1234 -j SETCTX --name foo > -A fw-smc -p 6 --dport 1234 -j SETCTX --name foo > -A fw-vpn -p 6 --dport 1234 -j SETCTX --name foo >OK, I have a couple of queries: was there a reason for including the protocol and port number columns? That adds an unnecessary complexity to me in my view - what if I want to use ipsets as protocol & port numbers? I am also assuming that this is a destination port - what happens if a source port is needed instead? Could you not just leave the syntax as "INLINE <src> <dst> ; <the_rest_of_the_statement>"? As for the built-in actions - yes, I don''t mind that at all, that''s pretty reasonable, though with this requirement I am assuming that shorewall must parse the bit after ";" and I am curious as to what is the reason for this? Optimisation or something else? ------------------------------------------------------------------------------ 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/09/2013 05:51 AM, Mr Dash Four wrote:> >>>> Nope, that would prevent me from using custom-made targets (something >>>> like ''-j SECCTX --name <name>'' for example). >>>> >>> Okay -- I''ve implemented the following: >>> >>> 3) 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> >>> >>> Example: >>> >>> INLINE $FW all tcp 1234 ; -j SETCTX --name foo >>> >>> As part of this change, a new ''builtin'' action type has been added. >>> ip[6]tables actions not supported by Shorewall (such as ''SETCTX'' in >>> the example above), must be defined in your >>> /etc/shorewall[6]/actions file. >>> >>> Example: >>> >>> SETCTX builtin >>> >>> >>> Is this what you had in mind? >>> >> >> BTW, with OPTIMIZE=31, the following rules are generated in my >> configuration: >> >> -A fw-dmz -p 6 --dport 1234 -j SETCTX --name foo >> -A fw-loc -p 6 --dport 1234 -j SETCTX --name foo >> -A fw-net -p 6 --dport 1234 -j SETCTX --name foo >> -A fw-smc -p 6 --dport 1234 -j SETCTX --name foo >> -A fw-vpn -p 6 --dport 1234 -j SETCTX --name foo >> > OK, I have a couple of queries: was there a reason for including the > protocol and port number columns? That adds an unnecessary complexity to > me in my view - what if I want to use ipsets as protocol & port numbers? > I am also assuming that this is a destination port - what happens if a > source port is needed instead? > > Could you not just leave the syntax as "INLINE <src> <dst> ; > <the_rest_of_the_statement>"?I''m *requiring* protocol and port numbers; but you can specify them if you want. In fact, you can specify *any* of the existing columns but the only columns that are required are SOURCE and DEST. -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/09/2013 05:51 AM, Mr Dash Four wrote:> > As for the built-in actions - yes, I don''t mind that at all, that''s > pretty reasonable, though with this requirement I am assuming that > shorewall must parse the bit after ";" and I am curious as to what is > the reason for this? Optimisation or something else? >It is for optimization. -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
>> OK, I have a couple of queries: was there a reason for including the >> protocol and port number columns? That adds an unnecessary complexity to >> me in my view - what if I want to use ipsets as protocol & port numbers? >> I am also assuming that this is a destination port - what happens if a >> source port is needed instead? >> >> Could you not just leave the syntax as "INLINE <src> <dst> ; >> <the_rest_of_the_statement>"? >> > > I''m *requiring* protocol and port numbers; but you can specify them if > you want. In fact, you can specify *any* of the existing columns but the > only columns that are required are SOURCE and DEST. >Erm, you''ve lost me. On one hand you are "requiring protocol and port numbers", but on the other "the only columns that are required are SOURCE and DEST" - that''s a bit contradictory. So to just make it clear - if I specify "INLINE $FW net ; -p tcp --dport 1234 -m mickey-mouse --name foo -j SECCTX --name foo2" or "INLINE $FW net ; -j SECCTX --name foo2", would that be OK with shorewall (provided I''ve included "SECCTX builtin" in my "actions", of course)? ------------------------------------------------------------------------------ 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
>> As for the built-in actions - yes, I don''t mind that at all, that''s >> pretty reasonable, though with this requirement I am assuming that >> shorewall must parse the bit after ";" and I am curious as to what is >> the reason for this? Optimisation or something else? >> >> > > It is for optimization. >Thought as much, thanks. One additional check you need to implement though (I haven''t had the chance to get my hands on the above changes, so can''t test this yet) is the use of built-in actions outside the INLINE statements - I don''t think that should be allowed. ------------------------------------------------------------------------------ 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/09/2013 08:46 AM, Mr Dash Four wrote:> >>> OK, I have a couple of queries: was there a reason for including the >>> protocol and port number columns? That adds an unnecessary complexity to >>> me in my view - what if I want to use ipsets as protocol & port numbers? >>> I am also assuming that this is a destination port - what happens if a >>> source port is needed instead? >>> >>> Could you not just leave the syntax as "INLINE <src> <dst> ; >>> <the_rest_of_the_statement>"? >>> >> >> I''m *requiring* protocol and port numbers; but you can specify them if >> you want. In fact, you can specify *any* of the existing columns but the >> only columns that are required are SOURCE and DEST. >> > Erm, you''ve lost me. > > On one hand you are "requiring protocol and port numbers", but on the > other "the only columns that are required are SOURCE and DEST" - that''s > a bit contradictory. So to just make it clear - if I specify "INLINE $FW > net ; -p tcp --dport 1234 -m mickey-mouse --name foo -j SECCTX --name > foo2" or "INLINE $FW net ; -j SECCTX --name foo2", would that be OK with > shorewall (provided I''ve included "SECCTX builtin" in my "actions", of > course)? >Sorry -- I''m trying to do 12 things at once. I am *not* requiring any columns except SOURCE and DEST. Your examples would work fine. -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
>> Erm, you''ve lost me. >> >> On one hand you are "requiring protocol and port numbers", but on the >> other "the only columns that are required are SOURCE and DEST" - that''s >> a bit contradictory. So to just make it clear - if I specify "INLINE $FW >> net ; -p tcp --dport 1234 -m mickey-mouse --name foo -j SECCTX --name >> foo2" or "INLINE $FW net ; -j SECCTX --name foo2", would that be OK with >> shorewall (provided I''ve included "SECCTX builtin" in my "actions", of >> course)? >> >> > > Sorry -- I''m trying to do 12 things at once. I am *not* requiring any > columns except SOURCE and DEST. Your examples would work fine. >Got it. You are not the only one with that particular problem though and I sympathise with you completely. I have one last query for you: if I specify "INLINE $FW net tcp 1234 ; -p udp --dport 1235 -j SECCTX --name foo" what would happen? Would shorewall issue an error, or would shorewall process one statement over the other (which one?) and issue a warning? ------------------------------------------------------------------------------ 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/09/2013 09:10 AM, Mr Dash Four wrote:> >>> Erm, you''ve lost me. >>> >>> On one hand you are "requiring protocol and port numbers", but on the >>> other "the only columns that are required are SOURCE and DEST" - that''s >>> a bit contradictory. So to just make it clear - if I specify "INLINE $FW >>> net ; -p tcp --dport 1234 -m mickey-mouse --name foo -j SECCTX --name >>> foo2" or "INLINE $FW net ; -j SECCTX --name foo2", would that be OK with >>> shorewall (provided I''ve included "SECCTX builtin" in my "actions", of >>> course)? >>> >>> >> >> Sorry -- I''m trying to do 12 things at once. I am *not* requiring any >> columns except SOURCE and DEST. Your examples would work fine. >> > Got it. You are not the only one with that particular problem though and > I sympathise with you completely. > > I have one last query for you: if I specify "INLINE $FW net tcp 1234 ; > -p udp --dport 1235 -j SECCTX --name foo" what would happen? Would > shorewall issue an error, or would shorewall process one statement over > the other (which one?) and issue a warning?That will generate an error. -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
>> I have one last query for you: if I specify "INLINE $FW net tcp 1234 ; >> -p udp --dport 1235 -j SECCTX --name foo" what would happen? Would >> shorewall issue an error, or would shorewall process one statement over >> the other (which one?) and issue a warning? >> > > That will generate an error. >Good! I presume the outcome would be the same if I "duplicate" other parts of the iptables statement (source port, user id and so on), 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/9/13 9:47 AM, "Mr Dash Four" <mr.dash.four@googlemail.com> wrote:> >>> I have one last query for you: if I specify "INLINE $FW net tcp 1234 ; >>> -p udp --dport 1235 -j SECCTX --name foo" what would happen? Would >>> shorewall issue an error, or would shorewall process one statement >>>over >>> the other (which one?) and issue a warning? >>> >> >> That will generate an error. >> >Good! I presume the outcome would be the same if I "duplicate" other >parts of the iptables statement (source port, user id and so on), correct?For those that can''t be duplicated, yes. But I wouldn''t guarantee that the logic there is perfect, because it was created to catch screwups in Shorewall''s rule generation and not user-supplied input. I''m sure that there will be cases where Shorewall will be silent but iptables will complain. -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
>> Good! I presume the outcome would be the same if I "duplicate" other >> parts of the iptables statement (source port, user id and so on), correct? >> > > For those that can''t be duplicated, yes. But I wouldn''t guarantee that the > logic there is perfect, because it was created to catch screwups in > Shorewall''s rule generation and not user-supplied input. I''m sure that > there will be cases where Shorewall will be silent but iptables will > complain. >No problem, nobody expects that to be, particularly given the "raw" nature of the INLINE statement. As I said before, my thinking is that if INLINE is used, then in such case the responsibility lies solely on the user not to make any screw-ups. In such scenario, all bets are off so to speak, so anything that shorewall checks and indicates as possible error is a bonus really. When I test this, I''ll just highlight potential omissions (of possible checks), but nothing more. ------------------------------------------------------------------------------ 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