On 01/27/2013 01:57 PM, Mr Dash Four wrote: >> Yesterday (after uploading Beta 3), I committed a change that adds >> UNTRACKED to the states being passed to blrules. It has always been one >> of the states passed to the dynamic blacklisting chain but not for blrules. >> > Should I assume that BLACKLISTNEWONLY covers that state (UNTRACKED)? In > other words when BLACKLISTNEWONLY=Yes, I'll have a jump to the blacklist > chain when states are NEW,INVALID,UNTRACKED or is this different?
You assume correctly. > > The reason I asked this is very simple: currently you have 5 different > sections in "rules", dealing with the 5 possible states of the connection. > > In its present state, "blrules" can only have a single on/off switch - > either have NEW,INVALID,UNTRACKED (BLACKLISTNEWONLY=Yes) or don't > (BLACKLISTNEWONLY=No), in which case the blacklist chain is traversed > for every packet regardless of its state - a bit like having only a > "SECTION ALL". This, provided I have understood you correctly as to the > meaning of that shorewall.conf variable. You understand correctly. > > Why not introduce the same sections you currently have in "rules", in > "blrules"? That way, I could control very precisely what should be > included when, in my blacklist chain. Because the blrules file is still handled internally as a section in the rules file. > I might, for example, want to > blacklist everything in INVALID state, but have different processing > rules for ESTABLISHED, as well as NEW. In the present form of "blrules" > I can't really do that. The Invalid, Related and Untracked actions can be used in the blrules file. I can also add an Established action. I'm also working on the ability to pass arbitrary actions to those macros; again, won't make it into 4.5.13 though. > > Another suggestion in this respect: How easy would it be to implement > the SECTION statement to include multiple states, like "SECTION > NEW,INVALID" for example? That would ease up having to write the same > thing twice (only to have the optimizer combine it later on in some > nondescript chain name). In that way, optimisation should also be easier. I have structured the SECTION implementation to allow that in the future; it won't make it into 4.5.13 though. > >>> 3. In what preference do you place the RELATED, INVALID and UNTRACKED >>> state matches in the chain groups - which one goes 1st, 2nd and 3rd (I >>> presume you have separate sub-chains for those in each a2b chain pair)? >>> >> >> There are separate sub-chains and they are handled in the same order as >> the sections. >> > So, if I have this: > > SECTION ESTABLISHED > [...] > SECTION NEW > [...] > SECTION INVALID > [...] > SECTION RELATED > [...] > SECTION NOTRACK > [...] > Does that mean the way the chains are built, the "ESTABLISHED" state > goes first, followed by NEW, then INVALID, RELATED and finally UNTRACKED > since that is how I ordered these states in my "rules" file? No. The order of the sections is fixed today and will remain so. -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 \________________________________________________
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d
_______________________________________________ Shorewall-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-devel
