Re: [Fwbuilder-discussion] Using default outbound and block all rules with pf.
Brought to you by:
mikehorn
From: Vadim K. ✎ <va...@vk...> - 2009-05-14 22:04:29
|
I made the change in v3.0.5 build 933. Build process is going on right now, packages should be on the nightly builds site in an hour or so. Please let me know if this works the way you expected it to. --vk On May 14, 2009, at 2:24 PM, Vadim Kurland ✎ wrote: > > I created bug for this: > > https://sourceforge.net/tracker/?func=detail&aid=2791950&group_id=5314&atid=1070394 > > --vk > > On May 14, 2009, at 10:37 AM, Vadim Kurland wrote: > >> >> Calling out to all PF experts on the list: does this make sense ? I >> can make the change really quickly and have it released in v3.0.5 >> soon, I just want to make sure this won't break anything. >> >> >> Hi Emery, >> >> it sounds like a bug, I think. Basically, if a rule in fwbuilder GUI >> has interface "any" and direction "in" or "out", generated pf.conf >> lines should follow prescribed direction. Such as, if rule has >> interface "any" and direction "out", then it should produce >> >> pass out quick inet from A to B >> >> and if direction is "in", then it should produce >> >> pass in quick inet from A to B >> >> >> Currently compiler for pf always generates both "pass in" and "pass >> out" regardless of the setting of the direction in the GUI if >> interface is set to "any". I agree this is wrong and needs to be >> fixed. >> >> --vk >> >> >> On May 14, 2009, at 7:34 AM, Emery Guévremont wrote: >> >>> -------- Original Message -------- >>> Subject: Re:[Fwbuilder-discussion] Using default outbound and block >>> all >>> rules with pf. >>> From: Vadim Kurland ✎ <va...@vk...> >>> To: Emery Guévremont <eme...@ga...> >>> CC: fwb...@li... >>> Date: Mon May 11 2009 12:33:10 GMT-0400 (Eastern Daylight Time) >>>> >>>> On May 11, 2009, at 8:38 AM, Emery Guévremont wrote: >>>> >>>>> Hello, >>>>> >>>>> I'm not sure if these are bugs or if it was planned like this but >>>>> here goes. >>>>> >>>>> I'm using FWB 3.0.3. A few week ago I tried to upgrade to 3.0.4, >>>>> but >>>>> when I did, I noticed that the checkbox in the firewall setting >>>>> "Pass >>>>> all outgoing" was removed from the interface. I noticed this was >>>>> in your >>>>> changelog, so it's not that bad, even though I found this feature >>>>> useful. But when I tried to create a rule to allow all outgoing >>>>> connections, I wasn't able to create one with "any interface". It >>>>> would >>>>> always create a "pass in" and not a "pass out" rule. >>>> >>>> rule with "any" in the interface column and direction "both" >>>> creates >>>> both "pass in" and "pass out" rules. How did the rule you tried >>>> looked >>>> like if it did not yield "pass out" at all ? >>> The only way I was able to create a pass out rule for all >>> interfaces, >>> was by adding everyone of the firewall's interfaces objects >>> individually. Actually as long as the Interface isn't set to >>> "All", I >>> was able to generate a pass out rule. >>>> >>>> >>>>> It also does this >>>>> in 3.0.3. I had to create one with each firewall interface >>>>> individually >>>>> added. Since I have quite a lot of interfaces and firewalls I >>>>> reverted >>>>> back to 3.0.3. Any reason why this is so? >>>>> >>>> >>>> so does it do this in 3.0.3 or not ? >>> Yes >>>> >>>> Perhaps it will be easier for me to help you if you give me an >>>> example >>>> of a rule you are trying to create, both how it should look like in >>>> generated pf.conf file and how you think it should look like in >>>> fwbuilder GUI. >>> Yes, an example will make things clearer. >>> >>> FWB Gui: >>> Source=Any >>> Destination=Any >>> Service=Any >>> Interface=All >>> Direction=Outbound >>> Action=Pass >>> Options=Log >>> Comment=Default outbound >>> >>> PF produced line: >>> pass in log quick inet from any to any keep state label "RULE >>> 64 >>> -- ACCEPT " >>> >>> I also switched the Direction from Outbound to Inbound and >>> afterwards I >>> changed it again to "Both" and all three settings give the same >>> result. >>> As long as "Interface=All", no "pass out" rule is ever generated and >>> instead wrongly creates a "pass in" rule. >>> >>> Now let me put in a specific interface to the Interface field. >>> >>> Source=Any >>> Destination=Any >>> Service=Any >>> Interface=bge0 >>> Direction=Outbound >>> Action=Pass >>> Options=Log >>> Comment=Default outbound >>> >>> PF produced line: >>> pass out log quick on bge0 inet from any to any keep state >>> label >>> "RULE 64 -- ACCEPT " >>> >>> Notice that once interface bge0 is added, the pf rule changes to >>> pass out. >>> >>> If I set "Direction=both" I get this: >>> pass in log quick on bge0 inet from any to any keep state >>> label >>> "RULE 64 -- ACCEPT " >>> pass out log quick on bge0 inet from any to any keep state >>> label >>> "RULE 64 -- ACCEPT " >>> >>> If I set "Direction=outbound" and set >>> "Interface=bge0,em0,em1,em2,gre0,lo0", I get this: >>> pass out log quick on bge0 inet from any to any keep state >>> label >>> "RULE 64 -- ACCEPT " >>> pass out log quick on em0 inet from any to any keep state label >>> "RULE 64 -- ACCEPT " >>> pass out log quick on em1 inet from any to any keep state label >>> "RULE 64 -- ACCEPT " >>> pass out log quick on em2 inet from any to any keep state label >>> "RULE 64 -- ACCEPT " >>> pass out log quick on gre0 inet from any to any keep state >>> label >>> "RULE 64 -- ACCEPT " >>> pass out log quick on enc0 inet from any to any keep state >>> label >>> "RULE 64 -- ACCEPT " >>> pass out log quick on lo0 inet from any to any keep state label >>> "RULE 64 -- ACCEPT " >>> >>> >>>> >>>> >>>>> Another thing I noticed, except this is 3.0.3 related. Checking >>>>> the "log >>>>> all blocks" also activates the logging for the "pass all >>>>> outgoing". This >>>>> caused me to first deactivate the logging and just create my own >>>>> block >>>>> all rule with logging activated. >>>> >>>> >>>> >>>> where did you check "log all blocks" ? >>> Let me add that the Firewall settings -> Compiler -> "Pass all >>> outgoing" >>> is selected. >>> >>> The place I checked the log all blocks is in Firewall settings -> >>> Logging tab -> Check the "Fallback 'deny all' rule should log >>> blocked >>> packets" checkbox. >>> >>> When the checkbox is checked it generates these rules: >>> pass out log quick inet from any to any keep state label "RULE >>> 10000 >>> -- ACCEPT " >>> block in log quick inet from any to any label "RULE 10001 -- >>> DROP " >>> >>> When the checkbox is unchecked it generates these rules: >>> pass out quick inet from any to any keep state label "RULE 10000 >>> -- >>> ACCEPT " >>> block in quick inet from any to any label "RULE 10001 -- DROP " >>>> >>>> >>>> Vadim Kurland ✍ >>>> va...@vk... >>>> >>>> >>>> >>>> >>>> >>>> >>> Thanks for the quick response and sorry for my slow response. >>> >>> -- >>> Emery Guévremont >>> Administrateur Réseau/ Network Administrator >>> Gameloft - Global Network Service >>> >>> >> >> >> ------------------------------------------------------------------------------ >> The NEW KODAK i700 Series Scanners deliver under ANY circumstances! >> Your >> production scanning environment may not be a perfect world - but >> thanks to >> Kodak, there's a perfect scanner to get the job done! With the NEW >> KODAK i700 >> Series Scanner you'll get full speed at 300 dpi even with all image >> processing features enabled. http://p.sf.net/sfu/kodak-com >> _______________________________________________ >> Fwbuilder-discussion mailing list >> Fwb...@li... >> https://lists.sourceforge.net/lists/listinfo/fwbuilder-discussion > > Vadim Kurland ✍ > va...@vk... > > > > > > > > ------------------------------------------------------------------------------ > Crystal Reports - New Free Runtime and 30 Day Trial > Check out the new simplified licensing option that enables > unlimited royalty-free distribution of the report engine > for externally facing server and web deployment. > http://p.sf.net/sfu/businessobjects > _______________________________________________ > Fwbuilder-discussion mailing list > Fwb...@li... > https://lists.sourceforge.net/lists/listinfo/fwbuilder-discussion Vadim Kurland ✍ va...@vk... |