I am increasingly getting frustrated by the following 2 blacklist/whitelist limitations: 1) they are applied to all zones; and 2) I cannot specify owner/user id (handy where the direction is fw2XX and traffic can be restricted/allowed by owner id). Would it be possible to introduce another option in the "options" column specifying the zone to which the defined address/subnet applies? That, combined with the existing src/dst option should be enough to narrow it down to a specific branch of that zone. Same query with the user id/owner - can there be an additional column in the blacklist file for this? Obviously, that will only be applicable to outgoing traffic. ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1
On Sep 27, 2011, at 3:31 PM, Mr Dash Four wrote:> I am increasingly getting frustrated by the following 2 > blacklist/whitelist limitations: 1) they are applied to all zones; and > 2) I cannot specify owner/user id (handy where the direction is fw2XX > and traffic can be restricted/allowed by owner id). > > Would it be possible to introduce another option in the "options" column > specifying the zone to which the defined address/subnet applies? That, > combined with the existing src/dst option should be enough to narrow it > down to a specific branch of that zone. Same query with the user > id/owner - can there be an additional column in the blacklist file for > this? Obviously, that will only be applicable to outgoing traffic. >Seems to me that we are re-inventing the wheel here. Everything you want can already be done in the rules file. -Tom Tom Eastep \ When I die, I want to go like my Grandfather who Shoreline, \ died peacefully in his sleep. Not screaming like Washington, USA \ all of the passengers in his car http://shorewall.net \________________________________________________ ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1
> Seems to me that we are re-inventing the wheel here. Everything you want can already be done in the rules file. >Not really! blacklist/whitelist entries are usually the first and precede anything else in a given chain - its their most valuable asset and is the reason I''d like these new features implemented in them. I know I could place a bunch of rules in the "rules" file, but they will be useless, because: 1) the blacklist/whitelist will already have been checked; and 2) These rules will be after anything that usually gets processed in a given chain - related/established connection rules, dropInvalid and various other macros as well. ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1
On Sep 27, 2011, at 4:29 PM, Mr Dash Four wrote:> >> Seems to me that we are re-inventing the wheel here. Everything you want can already be done in the rules file. >> > Not really! blacklist/whitelist entries are usually the first and > precede anything else in a given chain - its their most valuable asset > and is the reason I''d like these new features implemented in them.Yes -- and they come before traffic is broken out by zone.> > I know I could place a bunch of rules in the "rules" file, but they will > be useless, because: 1) the blacklist/whitelist will already have been > checked;So, only place entries that are zone-neutral in the blacklist file.> and 2) These rules will be after anything that usually gets > processed in a given chain - related/established connection rules, > dropInvalid and various other macros as well.That depends on which SECTION you put them in and what you put in front of them. Remember that, by default, ESTABLISHED,RELATED packets don''t go through the blacklist at all. -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 \________________________________________________ ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1
>> Not really! blacklist/whitelist entries are usually the first and >> precede anything else in a given chain - its their most valuable asset >> and is the reason I''d like these new features implemented in them. >> > > Yes -- and they come before traffic is broken out by zone. >Currently, they are inserted for each branch of the zone in which the "whitelist" option is used (I am assuming the "worse" case scenario where both src and dst options are used).>> I know I could place a bunch of rules in the "rules" file, but they will >> be useless, because: 1) the blacklist/whitelist will already have been >> checked; >> > > So, only place entries that are zone-neutral in the blacklist file. >I simply can''t. I think its better to illustrate this with a simple example: say I have 3 interfaces: eth0, eth1 and tun0. eth0 and tun0 have the whitelist option defined for them and I have a hefty ipsets containing subnets I don''t want traffic appearing on either interfaces - in both directions, so src and dst are also specified. I want, however, to have access to specific set of iface:subnet:proto tripples also based on userid/owner on tun0 for traffic going out to be allowed on tun0. I can define the iface:subnet:proto tripples as a specific ipset called, say, vpn-out-whitelist[dst,dst], which, if placed properly in the blackout chain of the tun0 interface will punch a hole through that defined blacklist for this particular interface (tun0). This is what I currently do with the "start" shorewall script - a hacking job. Ideally, what I''d like to have is this in the blacklist file: +whitelist - - - src,dst,whitelist # whitelist applicable to all interfaces, including tun0 +vpn-out-whitelist[dst,dst] - - root dst,vpn,whitelist # this to indicate that this ipset will punch a hole in the fw2vpn''s blackout chain, allowing the defined ip:proto pair to pass through for user id=0 (root) - the value of the 3rd column +blacklist - - - src,dst ... If I define vpn-out-whitelist[dst,dst] in my rules file that won''t do because 1) the blacklist will be checked first and traffic going out to the addresses:ports specified in the vpn-out-whitelist will be blocked; and 2) any other macros which are put even before the rules file is processed might - and will - also block such traffic (I also have BLACKLISTNEW=No, so that everything is checked regardless of the connection state - the blacklist chain comes first and that is how it should be really).>> and 2) These rules will be after anything that usually gets >> processed in a given chain - related/established connection rules, >> dropInvalid and various other macros as well. >> > > That depends on which SECTION you put them in and what you put in front of them. Remember that, by default, ESTABLISHED,RELATED packets don''t go through the blacklist at all. >Yes, I am aware of that, but in my case they do as I check everything regardless of the connection state (I know that it slows traffic, but the machine is powerful enough to process it and since it is in my dmz zone I don''t wish anything to slip through, regardless of the connection state, hence why BLACKLISTNEW=No in my case). ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1
On Wed, 2011-09-28 at 01:18 +0100, Mr Dash Four wrote:> >> Not really! blacklist/whitelist entries are usually the first and > >> precede anything else in a given chain - its their most valuable asset > >> and is the reason I''d like these new features implemented in them. > >> > > > > Yes -- and they come before traffic is broken out by zone. > > > Currently, they are inserted for each branch of the zone in which the > "whitelist" option is used (I am assuming the "worse" case scenario > where both src and dst options are used). > > >> I know I could place a bunch of rules in the "rules" file, but they will > >> be useless, because: 1) the blacklist/whitelist will already have been > >> checked; > >> > > > > So, only place entries that are zone-neutral in the blacklist file. > > > I simply can''t. > > I think its better to illustrate this with a simple example: say I have > 3 interfaces: eth0, eth1 and tun0. eth0 and tun0 have the whitelist > option defined for them and I have a hefty ipsets containing subnets I > don''t want traffic appearing on either interfaces - in both directions, > so src and dst are also specified. > > I want, however, to have access to specific set of iface:subnet:proto > tripples also based on userid/owner on tun0 for traffic going out to be > allowed on tun0. I can define the iface:subnet:proto tripples as a > specific ipset called, say, vpn-out-whitelist[dst,dst], which, if placed > properly in the blackout chain of the tun0 interface will punch a hole > through that defined blacklist for this particular interface (tun0). > This is what I currently do with the "start" shorewall script - a > hacking job. > > Ideally, what I''d like to have is this in the blacklist file: > > +whitelist - - - src,dst,whitelist # whitelist applicable to all > interfaces, including tun0 > +vpn-out-whitelist[dst,dst] - - root dst,vpn,whitelist # this to > indicate that this ipset will punch a hole in the fw2vpn''s blackout > chain, allowing the defined ip:proto pair to pass through for user id=0 > (root) - the value of the 3rd column > +blacklist - - - src,dst > ...Adding a USER/GROUP column to the blacklist file is fairly easy, although it requires that there now be three blacklist chains: blacklst, blackfwd and blackout. That feature will be included in the next Beta. -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 \________________________________________________ ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1
>> Ideally, what I''d like to have is this in the blacklist file: >> >> +whitelist - - - src,dst,whitelist # whitelist applicable to all >> interfaces, including tun0 >> +vpn-out-whitelist[dst,dst] - - root dst,vpn,whitelist # this to >> indicate that this ipset will punch a hole in the fw2vpn''s blackout >> chain, allowing the defined ip:proto pair to pass through for user id=0 >> (root) - the value of the 3rd column >> +blacklist - - - src,dst >> ... >> > > Adding a USER/GROUP column to the blacklist file is fairly easy, > although it requires that there now be three blacklist chains: blacklst, > blackfwd and blackout.Yeah, I figured that out yesterday even though I am not using bridges/have forwarded traffic it still makes sense to create such a chain. Can I specify the zone(s) to which that whitelist applies (vpn in my example above) or is it just user id/owner? If so, is this feature only applicable to whitelists or does it include the blacklists now as well (in other words can I specify "+blacklist - - - src,dst,vpn")?> That feature will be included in the next Beta. >OK, I''ll give it a whirl as soon as you release it. Thanks! ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1
On Thu, 2011-09-29 at 17:03 +0100, Mr Dash Four wrote:> > Adding a USER/GROUP column to the blacklist file is fairly easy, > > although it requires that there now be three blacklist chains: blacklst, > > blackfwd and blackout. > Yeah, I figured that out yesterday even though I am not using > bridges/have forwarded traffic it still makes sense to create such a > chain. Can I specify the zone(s) to which that whitelist applies (vpn in > my example above) or is it just user id/owner?Just userid/owner at this point. To allow zone names, the implementation of blacklisting will have to change rather dramatically (no blacklist chains at all with the possible exception of ''blacklog'').> > If so, is this feature only applicable to whitelists or does it include > the blacklists now as well (in other words can I specify "+blacklist - - > - src,dst,vpn")?Again, zones are 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 \________________________________________________ ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1
>> Can I specify the zone(s) to which that whitelist applies (vpn in >> my example above) or is it just user id/owner? >> > > Just userid/owner at this point. To allow zone names, the implementation > of blacklisting will have to change rather dramatically (no blacklist > chains at all with the possible exception of ''blacklog''). >Fair enough, though I am intrigued - what is the cause/obstacle(s) for not implementing it at this stage? What sort of big change in the blacklisting needs to happen in order for this to be implemented? I only used the zone names in my example as I thought together with the specified direction ("src" or "dst") it gives a "unique" reference as to where to include the whitelist (or blacklist for that matter, as this can also be implemented for blacklists as well). For example, "src,vpn,whitelist" uniquely identifies this, I think, as a "RETURN" condition in the blackout chain name (or whatever name you decide to call this) to be included/added in the fw2vpn chain. Similarly, "src,vpn" would identify a "DROP" condition for the blackout chain to be included on the fw2vpn chain - the same principle applies. I am, obviously, simplifying this (and there are probably more complex scenarios than that), but this is to clarify that the inclusion of a zone name is only for the purpose of identifying where this whitelist/blacklist condition goes. If there is another - easier - way, that so be it. ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1
> For example, "src,vpn,whitelist" uniquely identifies this, I think, as > a "RETURN" condition in the blackout chain name (or whatever name you > decide to call this) to be included/added in the fw2vpn chain. > Similarly, "src,vpn" would identify a "DROP" condition for the > blackout chain to be included on the fw2vpn chain - the same principle > applies. I am, obviously, simplifying this (and there are probably > more complex scenarios than that), but this is to clarify that the > inclusion of a zone name is only for the purpose of identifying where > this whitelist/blacklist condition goes. If there is another - easier > - way, that so be it."src" should really be "dst" - I am getting a bit mushy today! ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1
On Thu, 2011-09-29 at 17:30 +0100, Mr Dash Four wrote:> >> Can I specify the zone(s) to which that whitelist applies (vpn in > >> my example above) or is it just user id/owner? > >> > > > > Just userid/owner at this point. To allow zone names, the implementation > > of blacklisting will have to change rather dramatically (no blacklist > > chains at all with the possible exception of ''blacklog''). > > > Fair enough, though I am intrigued - what is the cause/obstacle(s) for > not implementing it at this stage? What sort of big change in the > blacklisting needs to happen in order for this to be implemented? > > I only used the zone names in my example as I thought together with the > specified direction ("src" or "dst") it gives a "unique" reference as to > where to include the whitelist (or blacklist for that matter, as this > can also be implemented for blacklists as well). > > For example, "src,vpn,whitelist" uniquely identifies this, I think, as a > "RETURN" condition in the blackout chain name (or whatever name you > decide to call this) to be included/added in the fw2vpn chain. > Similarly, "src,vpn" would identify a "DROP" condition for the blackout > chain to be included on the fw2vpn chain - the same principle applies. I > am, obviously, simplifying this (and there are probably more complex > scenarios than that), but this is to clarify that the inclusion of a > zone name is only for the purpose of identifying where this > whitelist/blacklist condition goes. If there is another - easier - way, > that so be it.Today, if you don''t specify a zone, then it means ''all zones''. So if my blacklist has three ''all'' entries followed by one for zone ''z'', followed by three more ''all'' entries, I would presume that you would want the 7 entries applied in sequence for zone ''z'', would you not? So, in effect, that means that every zone might need two blacklist chains - one for ''src'' and one for ''dst''. It is way too ugly to generate the code for a zone test inside of the blacklist chains because zones can be rather complicated things. The code to do that is implemented in the function Shorewall::Misc::generate_matrix() and close friends and I want to keep it that way. That means that ''all-zone'' blacklist rules need to be inserted into each appropriate ''zX2zY'' chain with the zone-specific rules interspersed among them. -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 \________________________________________________ ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1
> Today, if you don''t specify a zone, then it means ''all zones''. So if my > blacklist has three ''all'' entries followed by one for zone ''z'', followed > by three more ''all'' entries, I would presume that you would want the 7 > entries applied in sequence for zone ''z'', would you not?Yes, that''s right - I see what you mean now, but see below.> So, in effect, > that means that every zone might need two blacklist chains - one for > ''src'' and one for ''dst''. >Yes, that is correct - would this be a problem for shorewall?> It is way too ugly to generate the code for a zone test inside of the > blacklist chains because zones can be rather complicated things.You are doing this even now - shorewall inserts "blacklst" chain in all zones with the blacklist option and if there is also at least one entry present with the "src" option. Similarly, shorewall inserts a "blackout" chain for each zone with "blacklist" option where there is at least one entry with "dst" option specified, isn''t that the case? Granted, with the new arrangement there may be 2 blacklist chains for each defined zone, but why is that a problem for shorewall? I see it as a benefit, because one could trace blacklisted packets for each individual zone (and do the appropriate accounting, if needed) instead of having them lumped together as is the case now, wouldn''t you agree?> The > code to do that is implemented in the function > Shorewall::Misc::generate_matrix() and close friends and I want to keep > it that way. That means that ''all-zone'' blacklist rules need to be > inserted into each appropriate ''zX2zY'' chain with the zone-specific > rules interspersed among them. >Yes and no. When a zone is specified - either as a column entry (come to think of it, I think this might be a better way, otherwise someone may specify more than one zone by mistake. It will also help if you wish to expand the blacklist to cover inter-zonal blacklisting at a later stage), or in the options section, shorewall then: 1. Does some basic sanity checks to see whether that zone contains the "blacklist" option (either issue a warning and ignore the whole line or an error and stop processing); 2. Parses the "src", "dst" and, optionally the zone options, to figure out which direction - and therefore chain - this entry must go to. In other words, if it is "src,dst,vpn" then there need to be 2 entries generated - one for vpn2fw''s *own* "blacklst" chain (you can call it, say, "vpn_blacklst") and one for fw2vpn''s *own* "blackout" chain (say "vpn_blackout"). Alternatively, there could be a separate column for the zone - this will prevent users from specifying more than one ("src,dst,vpn,net" for example) if this is going to mess up the parsing. If there is no zone specified, then, as you rightly pointed out, "all" is assumed and this entry gets generated for all applicable "<zone>_blacklst" and "<zone>_blackout" chains where the "blacklist" option for those zones is specified. What shorewall does now is it uses a single blacklst and blackout chains where all rules in the blacklist file are generated. I don''t see a problem if each zone has its own blacklst and blackout chains. When shorewall parses the blacklist file it generate rules for each individual chain which has the "blacklist" option specified. 3. Scans for the "whitelist" option to determine the nature of the entry - "DROP" if there isn''t a "whitelist" option specified, "RETURN" if it is. 4. Generates the iptables code needed to be inserted later. One thing I did not account for here is inter-zone blacklists (say vpn2net etc), but to my knowledge this is not currently implemented in shorewall is it? If you do plan implementing that at a later stage, then you may wish to scrap "src" and "dst" options and introduce two separate columns for "SOURCE" and "DESTINATION" so that you determine where this blacklist entry goes to - in a similar fashion as shorewall currently does with the "rules" file. ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1
On Sep 29, 2011, at 3:12 PM, Mr Dash Four wrote:> >> Today, if you don''t specify a zone, then it means ''all zones''. So if my >> blacklist has three ''all'' entries followed by one for zone ''z'', followed >> by three more ''all'' entries, I would presume that you would want the 7 >> entries applied in sequence for zone ''z'', would you not? > Yes, that''s right - I see what you mean now, but see below. > >> So, in effect, >> that means that every zone might need two blacklist chains - one for >> ''src'' and one for ''dst''. >> > Yes, that is correct - would this be a problem for shorewall?Yes. Traditionally, blacklisting has been done ahead of interface filters such as tcpflags, surfs, etc. Given that all ''src'' blacklists are the same currently, a jump to the ''blacklst'' chain can simply be moved to the interface input and forward chains. That isn''t possible when there are multiple such blacklist rulesets.> >> It is way too ugly to generate the code for a zone test inside of the >> blacklist chains because zones can be rather complicated things. > You are doing this even now - shorewall inserts "blacklst" chain in all > zones with the blacklist option and if there is also at least one entry > present with the "src" option. Similarly, shorewall inserts a "blackout" > chain for each zone with "blacklist" option where there is at least one > entry with "dst" option specified, isn''t that the case?Yes -- and it''s all done currently in generate_matrix().> > Granted, with the new arrangement there may be 2 blacklist chains for > each defined zone, but why is that a problem for shorewall? I see it as > a benefit, because one could trace blacklisted packets for each > individual zone (and do the appropriate accounting, if needed) instead > of having them lumped together as is the case now, wouldn''t you agree? > >> The >> code to do that is implemented in the function >> Shorewall::Misc::generate_matrix() and close friends and I want to keep >> it that way. That means that ''all-zone'' blacklist rules need to be >> inserted into each appropriate ''zX2zY'' chain with the zone-specific >> rules interspersed among them. >> > Yes and no. When a zone is specified - either as a column entry (come to > think of it, I think this might be a better way, otherwise someone may > specify more than one zone by mistake. It will also help if you wish to > expand the blacklist to cover inter-zonal blacklisting at a later > stage), or in the options section, shorewall then: > > 1. Does some basic sanity checks to see whether that zone contains the > "blacklist" option (either issue a warning and ignore the whole line or > an error and stop processing); > > 2. Parses the "src", "dst" and, optionally the zone options, to figure > out which direction - and therefore chain - this entry must go to. In > other words, if it is "src,dst,vpn" then there need to be 2 entries > generated - one for vpn2fw''s *own* "blacklst" chain (you can call it, > say, "vpn_blacklst") and one for fw2vpn''s *own* "blackout" chain (say > "vpn_blackout"). > > Alternatively, there could be a separate column for the zone - this will > prevent users from specifying more than one ("src,dst,vpn,net" for > example) if this is going to mess up the parsing. If there is no zone > specified, then, as you rightly pointed out, "all" is assumed and this > entry gets generated for all applicable "<zone>_blacklst" and > "<zone>_blackout" chains where the "blacklist" option for those zones is > specified.All of that makes me think again of the rules file. My problem is that if these rules are placed in the rules file, they will come after tcpflags, surfs, etc.> > What shorewall does now is it uses a single blacklst and blackout chains > where all rules in the blacklist file are generated. I don''t see a > problem if each zone has its own blacklst and blackout chains.That''s because your viewpoint is very restricted.> When > shorewall parses the blacklist file it generate rules for each > individual chain which has the "blacklist" option specified. > > 3. Scans for the "whitelist" option to determine the nature of the entry > - "DROP" if there isn''t a "whitelist" option specified, "RETURN" if it is. > > 4. Generates the iptables code needed to be inserted later. > > One thing I did not account for here is inter-zone blacklists (say > vpn2net etc), but to my knowledge this is not currently implemented in > shorewall is it? If you do plan implementing that at a later stage, then > you may wish to scrap "src" and "dst" options and introduce two separate > columns for "SOURCE" and "DESTINATION" so that you determine where this > blacklist entry goes to - in a similar fashion as shorewall currently > does with the "rules" file.I frankly wish I had taken a different approach when you talked me into the last set of blacklist changes. I don''t want to compound that felony. -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 \________________________________________________ ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1
> Yes. Traditionally, blacklisting has been done ahead of interface filters such as tcpflags, surfs, etc.And this is absolutely right - nothing should come before blacklisting.> Given that all ''src'' blacklists are the same currently, a jump to the ''blacklst'' chain can simply be moved to the interface input and forward chains. That isn''t possible when there are multiple such blacklist rulesets. >Why not? To use my example, the first rule (and jump) in the fw2vpn chain is to a separately-created chain called "blackout". Granted, this chain is "shared" among all fw2XX chains, but I can''t see why would that be any different if that jump is to a separate chain called, say, vpn_blackout? In my "start" file, for that chain I have done exactly that and I have been running this configuration successfully for quite some time.>> Yes and no. When a zone is specified - either as a column entry (come to >> think of it, I think this might be a better way, otherwise someone may >> specify more than one zone by mistake. It will also help if you wish to >> expand the blacklist to cover inter-zonal blacklisting at a later >> stage), or in the options section, shorewall then: >> >> 1. Does some basic sanity checks to see whether that zone contains the >> "blacklist" option (either issue a warning and ignore the whole line or >> an error and stop processing); >> >> 2. Parses the "src", "dst" and, optionally the zone options, to figure >> out which direction - and therefore chain - this entry must go to. In >> other words, if it is "src,dst,vpn" then there need to be 2 entries >> generated - one for vpn2fw''s *own* "blacklst" chain (you can call it, >> say, "vpn_blacklst") and one for fw2vpn''s *own* "blackout" chain (say >> "vpn_blackout"). >> >> Alternatively, there could be a separate column for the zone - this will >> prevent users from specifying more than one ("src,dst,vpn,net" for >> example) if this is going to mess up the parsing. If there is no zone >> specified, then, as you rightly pointed out, "all" is assumed and this >> entry gets generated for all applicable "<zone>_blacklst" and >> "<zone>_blackout" chains where the "blacklist" option for those zones is >> specified. >> > > All of that makes me think again of the rules file. My problem is that if these rules are placed in the rules file, they will come after tcpflags, surfs, etc. >I take it the only reason that blacklist statements/rules may be placed (in iptables) after tcpflags etc is because of the time shorewall processes the "rules" file, right? If that is the case, then I''d leave them in the blacklist file - nothing should come before blacklist processing! I agree though, this "new" format is emerging to be similar to the rules file where the "ACTION" column would consists of either "BLACKLIST" or "WHITELIST", though I am not sure how would you process the "NEW", "ESTABLISHED" and "RELATED" sections if they were to contain blacklist/whitelist statements (that is provided the blacklist statements go into the "rules" file, which I am not sure is wise).>> When >> shorewall parses the blacklist file it generate rules for each >> individual chain which has the "blacklist" option specified. >> >> 3. Scans for the "whitelist" option to determine the nature of the entry >> - "DROP" if there isn''t a "whitelist" option specified, "RETURN" if it is. >> >> 4. Generates the iptables code needed to be inserted later. >> >> One thing I did not account for here is inter-zone blacklists (say >> vpn2net etc), but to my knowledge this is not currently implemented in >> shorewall is it? If you do plan implementing that at a later stage, then >> you may wish to scrap "src" and "dst" options and introduce two separate >> columns for "SOURCE" and "DESTINATION" so that you determine where this >> blacklist entry goes to - in a similar fashion as shorewall currently >> does with the "rules" file. >> > > I frankly wish I had taken a different approach when you talked me into the last set of blacklist changes. I don''t want to compound that felony. >I still can''t see what the problem is? I mean, really, instead of lumping all blacklisted statements into two shorewall-created chains (blacklst and blackout) you will do it in separate, zone-independent ones, and all the jumps to blacklst and blackout would be to <zone>_blacklst and <zone>_blackout instead. Why is that not possible to implement? Am I missing something obvious here? ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2
On Fri, 2011-09-30 at 11:43 +0100, Mr Dash Four wrote:> > Yes. Traditionally, blacklisting has been done ahead of interface filters such as tcpflags, surfs, etc. > And this is absolutely right - nothing should come before blacklisting. > > > Given that all ''src'' blacklists are the same currently, a jump to the ''blacklst'' chain can simply be moved to the interface input and forward chains. That isn''t possible when there are multiple such blacklist rulesets. > > > Why not? To use my example, the first rule (and jump) in the fw2vpn > chain is to a separately-created chain called "blackout". Granted, this > chain is "shared" among all fw2XX chains, but I can''t see why would that > be any different if that jump is to a separate chain called, say, > vpn_blackout? In my "start" file, for that chain I have done exactly > that and I have been running this configuration successfully for quite > some time.I assume, then, that you have no interfaces that support multiple zones. In that case, the jumps for checking tcpflags, smurfs, etc. are in the interface input and forward chains; the jumps to the blacklst chain are promoted from the zone-specific chains to the interface chains. Again, that works now because there is only one blacklst chain.> > >> > > All of that makes me think again of the rules file. My problem is that if these rules are placed in the rules file, they will come after tcpflags, surfs, etc. > > > I take it the only reason that blacklist statements/rules may be placed > (in iptables) after tcpflags etc is because of the time shorewall > processes the "rules" file, right? If that is the case, then I''d leave > them in the blacklist file - nothing should come before blacklist > processing! > > I agree though, this "new" format is emerging to be similar to the rules > file where the "ACTION" column would consists of either "BLACKLIST" or > "WHITELIST", though I am not sure how would you process the "NEW", > "ESTABLISHED" and "RELATED" sections if they were to contain > blacklist/whitelist statements (that is provided the blacklist > statements go into the "rules" file, which I am not sure is wise).The question of what to do about the sections is indeed a stumbling block to adding BLACKLIST and WHITELIST statements to the rules file. Which is what I really prefer to do.> > >> When > >> shorewall parses the blacklist file it generate rules for each > >> individual chain which has the "blacklist" option specified. > >> > >> 3. Scans for the "whitelist" option to determine the nature of the entry > >> - "DROP" if there isn''t a "whitelist" option specified, "RETURN" if it is. > >> > >> 4. Generates the iptables code needed to be inserted later. > >> > >> One thing I did not account for here is inter-zone blacklists (say > >> vpn2net etc), but to my knowledge this is not currently implemented in > >> shorewall is it? If you do plan implementing that at a later stage, then > >> you may wish to scrap "src" and "dst" options and introduce two separate > >> columns for "SOURCE" and "DESTINATION" so that you determine where this > >> blacklist entry goes to - in a similar fashion as shorewall currently > >> does with the "rules" file. > >> > > > > I frankly wish I had taken a different approach when you talked me into the last set of blacklist changes. I don''t want to compound that felony. > > > I still can''t see what the problem is? I mean, really, instead of > lumping all blacklisted statements into two shorewall-created chains > (blacklst and blackout) you will do it in separate, zone-independent > ones, and all the jumps to blacklst and blackout would be to > <zone>_blacklst and <zone>_blackout instead. Why is that not possible to > implement? Am I missing something obvious here?See my first comment above. Do you *really* need a zone name in the blacklist file, or would specifying an interface meet your needs? -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 \________________________________________________ ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2
>> Why not? To use my example, the first rule (and jump) in the fw2vpn >> chain is to a separately-created chain called "blackout". Granted, this >> chain is "shared" among all fw2XX chains, but I can''t see why would that >> be any different if that jump is to a separate chain called, say, >> vpn_blackout? In my "start" file, for that chain I have done exactly >> that and I have been running this configuration successfully for quite >> some time. >> > > I assume, then, that you have no interfaces that support multiple zones. >True (I actually haven''t thought of that).> In that case, the jumps for checking tcpflags, smurfs, etc. are in the > interface input and forward chains; the jumps to the blacklst chain are > promoted from the zone-specific chains to the interface chains. Again, > that works now because there is only one blacklst chain. >What I have is one blacklst and one blackout chains and they are currently "jumped on" by the appropriate fw2XX and XX2fw chains - they are the first statements there before anything else goes, which is what I really wanted. I really don''t know how shorewall organises interfaces with multiple zones, but I presume that for each zone there is fw2<zone> and <zone>2fw chain. If that is so, how are the blacklst and blackout chains referred to (or jumped to in iptables'' terms) currently (genuine question)? Even if we assume that an interface has multiple zones, then what would be the problem of implementing various <zone>_blacklst and <zone>_blackout chains for that? I initially referred to "zones" as, from my own (probably selfish) perspective, the blacklist chains are the first statements where the zone-related iptables instructions are implemented, thus effectively acting as a first defence no matter what else is defined afterwards (in terms of macros, "rules" file statements, actions etc), which is how it should be. If there is a different way, which is easier to implement in shorewall without compromising this "first-line of defence" scenario (in either directions), then so be it.>> I agree though, this "new" format is emerging to be similar to the rules >> file where the "ACTION" column would consists of either "BLACKLIST" or >> "WHITELIST", though I am not sure how would you process the "NEW", >> "ESTABLISHED" and "RELATED" sections if they were to contain >> blacklist/whitelist statements (that is provided the blacklist >> statements go into the "rules" file, which I am not sure is wise). >> > > The question of what to do about the sections is indeed a stumbling > block to adding BLACKLIST and WHITELIST statements to the rules file. > Which is what I really prefer to do. >If you manage to somehow integrate BLACKLIST/WHITELIST statements in the rules file (and that includes the 3 sections mentioned above), then you have to get rid of the BLACKLISTNEWONLY (I think it was called) option in shorewall.conf. It is a bit tricky, because I can see massive duplication of blacklist statements for ESTABLISHED and RELATED (how the hell would I - the average n00b user - know what falls under "RELATED"?), so it is not as clear-cut just adding these two blacklist "ACTIONS" into the rules file. Not to mention that I have no idea how would I have what I currently have in the blacklist chains - every packed is checked regardless of its connection state? I''d rather they were separate - as is now in a "blacklist" file - and if the functionality is the same as in the rules file that would be great.>>> I frankly wish I had taken a different approach when you talked me into the last set of blacklist changes. I don''t want to compound that felony. >>> >>> >> I still can''t see what the problem is? I mean, really, instead of >> lumping all blacklisted statements into two shorewall-created chains >> (blacklst and blackout) you will do it in separate, zone-independent >> ones, and all the jumps to blacklst and blackout would be to >> <zone>_blacklst and <zone>_blackout instead. Why is that not possible to >> implement? Am I missing something obvious here? >> > > See my first comment above. > > Do you *really* need a zone name in the blacklist file, or would > specifying an interface meet your needs? >I am not sure to be honest! Now that you mention it, provided the blacklist chain (in whatever form you decide to change it/implement it to) is the first one to be checked for each interface - in either direction - than I don''t really mind that at all, provided blacklist and whitelist functionality remains the same, that is. Are you thinking of dumping the blacklst and blackout chains in the INPUT, OUTPUT and FORWARD chains, filtering out just the interface? If so, that is what I proposed ages ago if you remember, when shorewall had just one blacklst chain and you declined that and opted to do it in the zones instead. ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2
On Fri, 2011-09-30 at 18:05 +0100, Mr Dash Four wrote:> > Do you *really* need a zone name in the blacklist file, or would > > specifying an interface meet your needs? > > > I am not sure to be honest! > > Now that you mention it, provided the blacklist chain (in whatever form > you decide to change it/implement it to) is the first one to be checked > for each interface - in either direction - than I don''t really mind that > at all, provided blacklist and whitelist functionality remains the same, > that is. > > Are you thinking of dumping the blacklst and blackout chains in the > INPUT, OUTPUT and FORWARD chains, filtering out just the interface?No: I''m merely suggesting that the first column could be of the form <interface>:<network list>. The <interface> would be the source interface in ''src'' entries and the destination interface in ''dst'' entries. -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 \________________________________________________ ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2
>> Are you thinking of dumping the blacklst and blackout chains in the >> INPUT, OUTPUT and FORWARD chains, filtering out just the interface? >> > > No: I''m merely suggesting that the first column could be of the form > <interface>:<network list>. The <interface> would be the source > interface in ''src'' entries and the destination interface in ''dst'' > entries. >Where are you going to place these statements - in the same blacklst/blackout chains shared among all zones or somewhere else? If so, where? ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2
On Sep 30, 2011, at 12:46 PM, Mr Dash Four wrote:> >>> Are you thinking of dumping the blacklst and blackout chains in the >>> INPUT, OUTPUT and FORWARD chains, filtering out just the interface? >>> >> >> No: I''m merely suggesting that the first column could be of the form >> <interface>:<network list>. The <interface> would be the source >> interface in ''src'' entries and the destination interface in ''dst'' >> entries. >> > Where are you going to place these statements - in the same > blacklst/blackout chains shared among all zones or somewhere else? If > so, where?Same chains as today. -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 \________________________________________________ ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2
>>>> Are you thinking of dumping the blacklst and blackout chains in the >>>> INPUT, OUTPUT and FORWARD chains, filtering out just the interface? >>>> >>>> >>> No: I''m merely suggesting that the first column could be of the form >>> <interface>:<network list>. The <interface> would be the source >>> interface in ''src'' entries and the destination interface in ''dst'' >>> entries. >>> >>> >> Where are you going to place these statements - in the same >> blacklst/blackout chains shared among all zones or somewhere else? If >> so, where? >> > Same chains as today. >So, if I place 50 blacklist entries for tun0 and 1 for eth0, then in order to get a packet through eth0 it has to traverse through 51 entries in that same chain? "Square pegs in round holes" comes to mind... Thanks, but no thanks! I''d rather have a separate chain for each interface - that way a given packet will traverse through less entries, much more efficient and less time-consuming. ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2
On Sep 30, 2011, at 3:13 PM, Mr Dash Four wrote:> >>>>> Are you thinking of dumping the blacklst and blackout chains in the >>>>> INPUT, OUTPUT and FORWARD chains, filtering out just the interface? >>>>> >>>>> >>>> No: I''m merely suggesting that the first column could be of the form >>>> <interface>:<network list>. The <interface> would be the source >>>> interface in ''src'' entries and the destination interface in ''dst'' >>>> entries. >>>> >>>> >>> Where are you going to place these statements - in the same >>> blacklst/blackout chains shared among all zones or somewhere else? If >>> so, where? >>> >> Same chains as today. >> > So, if I place 50 blacklist entries for tun0 and 1 for eth0, then in > order to get a packet through eth0 it has to traverse through 51 entries > in that same chain? "Square pegs in round holes" comes to mind... > Thanks, but no thanks! >Why? It doing that now. -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 \________________________________________________ ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2
>>> Same chains as today. >>> >>> >> So, if I place 50 blacklist entries for tun0 and 1 for eth0, then in >> order to get a packet through eth0 it has to traverse through 51 entries >> in that same chain? "Square pegs in round holes" comes to mind... >> Thanks, but no thanks! >> >> > > Why? It doing that now. >No, not really. It is only "doing that now" because blacklist entries are entered for all interfaces - if/when that changes, I would be able to enter blacklist entries for a specific interface. If you are going to lump up all blacklist entries regardless of which interface they are entered for into a single chain (I presume that would be the blacklst/blackout chain again as you already pointed out) and you reference that chain from all interfaces/zones (as is the case now), that means a single packet has to traverse through all entries in the blacklst/blackout chain - including entries which have been entered for a different interface - before it passes through and that is something I am not very keen on doing, quite frankly...Unless I am missing something obvious. ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2
On Sep 30, 2011, at 3:27 PM, Mr Dash Four wrote:> >>>> Same chains as today. >>>> >>>> >>> So, if I place 50 blacklist entries for tun0 and 1 for eth0, then in >>> order to get a packet through eth0 it has to traverse through 51 entries >>> in that same chain? "Square pegs in round holes" comes to mind... >>> Thanks, but no thanks! >>> >>> >> >> Why? It doing that now. >> > No, not really. It is only "doing that now" because blacklist entries > are entered for all interfaces - if/when that changes, I would be able > to enter blacklist entries for a specific interface. > > If you are going to lump up all blacklist entries regardless of which > interface they are entered for into a single chain (I presume that would > be the blacklst/blackout chain again as you already pointed out) and you > reference that chain from all interfaces/zones (as is the case now), > that means a single packet has to traverse through all entries in the > blacklst/blackout chain - including entries which have been entered for > a different interface - before it passes through and that is something I > am not very keen on doing, quite frankly...Unless I am missing something > obvious. >Okay -- then let''s do this: a) Add DropSmurfs and TCPFlags actions that do the same thing as the interface options ''nosmurfs'' and ''TCPFlags'' respectively. b) Simply put your blacklist entries in the ALL section of the rules file. This way, you can have dozens of blacklists and invoke them as appropriate. You would implement each blacklist as an action, so that CONTINUE would work like ''whitelist''. After all blacklist/whitelist processing, you could invoke DropSmurfs and/or TCPFlags if desired. We don''t need a ''maclist'' action since maclist processing can be trivially implemented in rules already. -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 \________________________________________________ ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2
> Okay -- then let''s do this: > > a) Add DropSmurfs and TCPFlags actions that do the same thing as the interface options ''nosmurfs'' and ''TCPFlags'' respectively. > b) Simply put your blacklist entries in the ALL section of the rules file. > > This way, you can have dozens of blacklists and invoke them as appropriate. > > You would implement each blacklist as an action, so that CONTINUE would work like ''whitelist''. > > After all blacklist/whitelist processing, you could invoke DropSmurfs and/or TCPFlags if desired. > > We don''t need a ''maclist'' action since maclist processing can be trivially implemented in rules already. >I don''t see why I should be mixing up blacklist/whitelist entries with what I have implemented in the rules file, let alone messing up with unnecessary actions, CONTINUEs and the like. For what? Who is going to maintain that - you, perhaps? We''ve been through this before, haven''t we - if you can''t be arsed implementing a proper blacklist, then why didn''t you just say so from the beginning (it is perfectly OK!), so that I don''t continue wasting my time making "complex" requests or ask "difficult" questions? ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2
On Sep 30, 2011, at 3:55 PM, Mr Dash Four wrote:> >> Okay -- then let''s do this: >> >> a) Add DropSmurfs and TCPFlags actions that do the same thing as the interface options ''nosmurfs'' and ''TCPFlags'' respectively. >> b) Simply put your blacklist entries in the ALL section of the rules file. >> >> This way, you can have dozens of blacklists and invoke them as appropriate. >> >> You would implement each blacklist as an action, so that CONTINUE would work like ''whitelist''. >> >> After all blacklist/whitelist processing, you could invoke DropSmurfs and/or TCPFlags if desired. >> >> We don''t need a ''maclist'' action since maclist processing can be trivially implemented in rules already. >> > I don''t see why I should be mixing up blacklist/whitelist entries with > what I have implemented in the rules file, let alone messing up with > unnecessary actions, CONTINUEs and the like. For what? Who is going to > maintain that - you, perhaps? > > We''ve been through this before, haven''t we - if you can''t be arsed > implementing a proper blacklist, then why didn''t you just say so from > the beginning (it is perfectly OK!), so that I don''t continue wasting my > time making "complex" requests or ask "difficult" questions?It''s settled then -- blacklisting will remain as it is. -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 \________________________________________________ ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2
> It''s settled then -- blacklisting will remain as it is. >Indeed - if you can''t be arsed then I guess I can''t help you. Fortunately for me, the fraud blacklist implementation which currently exist in shorewall has now been replaced on all my machines. ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2
On Sun, 2011-10-02 at 22:26 +0100, Mr Dash Four wrote:> > It''s settled then -- blacklisting will remain as it is. > > > Indeed - if you can''t be arsed then I guess I can''t help you. > Fortunately for me, the fraud blacklist implementation which currently > exist in shorewall has now been replaced on all my machines.Too bad that you won''t be able to take advantage of the new BLACKLIST section of the rules file that I have currently prototyped and that I plan to release in 4.4.25. -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 \________________________________________________ ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1
On Mon, 2011-10-03 at 10:27 -0700, Tom Eastep wrote:> On Sun, 2011-10-02 at 22:26 +0100, Mr Dash Four wrote: > > > It''s settled then -- blacklisting will remain as it is. > > > > > Indeed - if you can''t be arsed then I guess I can''t help you. > > Fortunately for me, the fraud blacklist implementation which currently > > exist in shorewall has now been replaced on all my machines. > > Too bad that you won''t be able to take advantage of the new BLACKLIST > section of the rules file that I have currently prototyped and that I > plan to release in 4.4.25.Here''s what I''m planning: 1) The original static blacklisting implementation was interface-oriented and only handled blacklisting by source address. In Shorewall 4.4.12, the ability to blacklist by source address was added and blacklisting could be specified as a ZONE option. This change, plus additional changes in subsequent releases has lead to an implementation that is complex and hard to extend. In this release, a new static blacklisting facility has been implemented. This facility is separate from the legacy facility, so existing configurations will continue to work without change. A BLACKLIST section has been added to the rules file. This section is now the first section, having been added ahead of the ALL section. The set of packets that are subject to blacklisting is still governed by the setting of BLACKLISTNEWONLY in shorewall.conf. The settings of BLACKLIST_LOGLEVEL and BLACKLIST_DISPOSITION are not relevant to the new implementation. Most of the actions available in other sections of the rules file are available in the BLACKLIST section and logging is specified on a rule-by-rule basis in the normal way. In addition to the other actions available, a WHITELIST action has been added which exempts matching packets from being passed to the remaining rules in the section. Each "zone2zone" chain (e.g., net2fw) that has blacklist rules has a companion blacklisting chain with the same name but prefaced by "~". For example, ''net2fw'' blacklist rules appear in the chain ~net2fw. There is a likelihood that multiple blacklisting chains will have exactly the same rules. This is especially true when ''all'' is used as the zone name in the SOURCE and/or DEST columns. When optimization level 8 is used, these identical chains are combined into a single chain with the name ~blacklistN, where N is a number (possibly with multiple digits). The ''nosurfs'' and ''tcpflags'' interface options generate rules that will be traversed prior to those in the BLACKLIST section. If you want similar rules to be travered on packets that were not dropped or rejected in the BLACKLIST chain, you can use the new ''DropSmurfs'' and/or ''TCPFlags'' standard actions. The DropSmurfs action has a single parameter whose default value is ''-''. The action silently drops smurfs without auditing. If you want to audit these drops, use DropSmurfs(audit). Logging can be specified in the normal way (e.g., DropSmurfs:info). The TCPFlags action has two parameters whose default values are DROP and -. The first action determines what is to be done with matching packets and can have the values DROP, REJECT or ACCEPT. If you want the action to be audited, pass ''audit'' in the second parameter. Example: TCPFlags(REJECT,audit) Again, logging is specified in the normal way. The ''maclist'' interface option can also generate rules that are traversed prior to those in the BLACKLIST section. If you want them to come after the the blacklist rules, simply recode your maclist rules in the NEW section of the rules file. Comments welcome, -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 \________________________________________________ ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1
> Each "zone2zone" chain (e.g., net2fw) that has blacklist rules has > a companion blacklisting chain with the same name but prefaced by > "~". For example, ''net2fw'' blacklist rules appear in the chain > ~net2fw.Actually, the ''~'' follows the name.> The ''maclist'' interface option can also generate rules that are > traversed prior to those in the BLACKLIST section. If you want them > to come after the the blacklist rules, simply recode your maclist > rules in the NEW section of the rules file.This isn''t a very satisfactory solution. I''ll work on it some more. -Tom ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1
On Wed, 2011-10-05 at 16:34 -0700, Tom Eastep wrote:> > Each "zone2zone" chain (e.g., net2fw) that has blacklist rules > > has > > a companion blacklisting chain with the same name but prefaced by > > "~". For example, ''net2fw'' blacklist rules appear in the chain > > ~net2fw. > > > > > Actually, the ''~'' follows the name. > > > The ''maclist'' interface option can also generate rules that are > > traversed prior to those in the BLACKLIST section. If you want > > them > > to come after the the blacklist rules, simply recode your maclist > > rules in the NEW section of the rules file. > > > > > This isn''t a very satisfactory solution. I''ll work on it some more.Although maybe it is okay, given that we now have macipmap ipsets. Those are ideal for MAC/IP validation. Anyone have an opinion one way of the other? -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 \________________________________________________ ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1
>> >> This isn''t a very satisfactory solution. I''ll work on it some more. > > Although maybe it is okay, given that we now have macipmap ipsets. Those > are ideal for MAC/IP validation. > > Anyone have an opinion one way of the other?I guess not. So I won'' t do anything for now. -Tom ------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2