On 01/22/2013 10:36 AM, Tom Eastep wrote: > On 01/22/2013 08:13 AM, Tom Eastep wrote: >> On 01/22/2013 05:04 AM, Mr Dash Four wrote: >>> There is another (quite annoying) issue I've discovered with 4.5.12 >>> (maybe valid with 4.5.13 betas, don't know), which I think requires a >>> little attention: >>> >>> shorewall.conf >>> ~~~~~~~~~~~~~~ >>> RELATED_DISPOSITION=ACCEPT >>> >>> blrules >>> ~~~~~~~ >>> WHITELIST fw net:+whitelist >>> <EOF> >>> >>> rules >>> ~~~~~ >>> SECTION RELATED >>> IFLOG(accept,log,nflog1,2,mamas,DROP) $FW net >>> SECTION NEW >>> dropInvalid all all >>> [...] >>> >>> generates these rules: >>> >>> -A fw2net -m conntrack --ctstate NEW,INVALID -m set --match-set >>> whitelist dst -j RETURN >>> -A fw2net -m conntrack --ctstate ESTABLISHED -j ACCEPT >>> -A fw2net -m conntrack --ctstate RELATED -j +fw2net >>> -A fw2net -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT >>> -A fw2net -m conntrack --ctstate INVALID -j DROP >>> >>> 1st rule above: even though it is the only one which exists in "blrules" >>> for this chain (fw2net), it should not have been optimised in this way >>> (RETURN from fw2net will prevent further traversing!). >> >> Yes -- that's a bug. Patch attached. >> >>> >>> Also, why is --cstate INVALID included in that match (I do have >>> BLACKLISTNEWONLY=Yes, but that doesn't explain the INVALID match being >>> there)? >> >> The rationale there is that sending packets in an invalid state should >> not allow someone to bypass the blacklist rules. So I would prefer to >> change the description of the BLACKLISTNEWONLY option rather than the code. >> >>> The correct rule should have been a single "--cstate INVALID -j >>> DROP", if anything (as shown in the last rule listed there). >>> >>> 2nd-to-last rule: where did that come from? I have similar rules >>> generated for all of my other chains (net2fw, local2fw, fw2local ...). >> >> Yes -- with RELATED_DISPOSITION=ACCEPT, simply accepting packets in >> ESTABLISHED state would be enough. That is a left-over from before I >> implemented RELATED_DISPOSITION. I'll clean that up in this release. > > I just took another look at this and I'm not clear where that is coming > from in your case. From my own ruleset: > > -A net-fw -m conntrack --ctstate NEW,INVALID -j net-fw~ > -A net-fw -i eth0 -j eth0_iop > -A net-fw -i eth1 -j eth1_iop > -A net-fw -m conntrack --ctstate ESTABLISHED -j ACCEPT > -A net-fw -m conntrack --ctstate RELATED -j +net-fw > -A net-fw -p tcp --syn -j @net-all > -A net-fw -p udp --dport 1194 -j ACCEPT > ...
I've reproduced the problem and will include a fix 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 \________________________________________________
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
