On 01/27/2013 03:38 PM, Mr Dash Four wrote: > >>> 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. >> > And that makes it impossible to be implemented now/in the future?
It makes it difficult enough that I wont do it. > >>> 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. > That's not the same thing as having a specific section dedicated for > each state where a set of rules for that state could be defined, is it? No. > >> I'm also working on the >> ability to pass arbitrary actions to those macros; again, won't make it >> into 4.5.13 though. >> > I also take it passing arbitrary actions to the various *_DISPOSITION > shorewall.conf variables is also a no-go? Given that you can accomplish the same thing already, it hardly seems worth it. e.g., finish the section with an unconditional action invocation and specify CONTINUE as the _DISPOSITION. > >> I have structured the SECTION implementation to allow that in the >> future; it won't make it into 4.5.13 though. >> > That's fine, thanks. > >>> 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. >> > Which is what exactly? As listed in the release notes and in shorewall-rules(5). Don't you think that is a bit restrictive. I don't think it is restrictive enough to change. > > For example, if I want my ESTABLISHED state to take precedence (by > "precedence" I mean traverse the absolute minimum set of rules), I can't > really control that. I think that the right thing to do there is to redefine FASTACCEPT to only include ESTABLISHED state. Then FASTACCEPT=Yes puts the ESTABLISHED accept rule very early. In fact, I should do that for this release (given the recently discovered issues with RELATED). > Similarly, if I want the INVALID state set of rules > to be dealt with first (thus placing the INVALID section at the top of > "rules"), I have no control of that either? > No. -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
