If these are the only chains that are impacted by this problem then it
sounds good. Will give us the flexibility we need.
Thanks
David
On Mon, Jul 16, 2012 at 6:30 PM, Lonnie Abelbeck
<[email protected]>wrote:
> Hi David,
>
> Well, I wouldn't necessarily call it a "dumb idea" :-) and I explained
> Arno's reasoning years ago.
>
> I have commit privileges to the AIF SVN, so with Arno's approval we and
> implement any great idea we can come up with.
>
> One idea Arno and I had was to add 3 new variables to AIF:
> --
> # (1=DROP, 0=ACCEPT, (undefined) ""=AUTO)
> LAN_INET_DEFAULT_POLICY_DROP=""
> DMZ_INET_DEFAULT_POLICY_DROP=""
> LAN_DEFAULT_POLICY_DROP=""
> --
> In AUTO mode it operates exactly as it does now, but either "0" or "1"
> short-circuits the current method and sets the default policy accordingly.
>
> Then in AstLinux we could automatically set:
>
> LAN_INET_DEFAULT_POLICY_DROP="0"
> DMZ_INET_DEFAULT_POLICY_DROP="0"
>
> That would make 'Pass LAN->EXT' rules redundant unless there were 'Deny
> LAN->EXT' rules that intersected.
>
> Does that sound good, or other suggestions... ASAP
>
> Lonnie
>
>
> On Jul 16, 2012, at 3:37 PM, David Kerr wrote:
>
> > Oh dear, I opened a can of worms. I have to say that changing default
> behavior as a side effect of adding an allow rule feels like a dumb idea.
> >
> > How hard would it be for iptables to be modified such that a final
> default chain rule can be specified -- which could override a hard coded
> default rule for a chain?
> >
> > Right now, based on what Lonnie told me yesterday, the firewall sorts
> the chain to have all allows before deny. So you can't add an "allow
> everything" to the chain because that would match before any of the blocks.
> What is needed is a way to add a rule that will always, always, be placed
> at the end of a chain and not be sorted like everything else. This could
> be implemented without affecting existing applications because the default
> final rule could be what it always has been... unless a firewall admin
> comes in and specifically sets what the final rule should be.
> >
> > David
> >
> >
> > On Mon, Jul 16, 2012 at 3:42 PM, Lonnie Abelbeck <
> [email protected]> wrote:
> > Sigh, now I remember why we didn't previously support "Pass LAN->EXT"
> and "Pass DMZ->EXT" in the Firewall tab...
> >
> > First, my suggestion to David in this thread for using
> LAN_INET_HOST_OPEN_UDP does what you expect *but* has the side effect of
> changing the LAN->EXT default policy from ALLOW to DROP, probably not what
> you wanted David!
> >
> > Actually Arno (great guy BTW) and I had a conversation about this early
> this year about possibly changing this automatic default policy, but due to
> the history of AIF (over 10 years old!) we deferred making any changes.
> >
> > We are open to ideas, please. :-)
> >
> > Arno's original motivation was if a person set...
> >
> > LAN_INET_HOST_OPEN_TCP="0/0>0/0~80,443"
> >
> > This would allow HTTP and HTTPS (LAN to internet), but would also drop
> all other outbound LAN traffic, thinking the rule would be meaningless
> otherwise with a default ALLOW policy. Seems reasonable.
> >
> > But, now thinking about David Kerr's case here with OpenDNS... the "Deny
> LAN->EXT" works as expected, no problem. The issue is when an exception to
> allow a different DNS for a particular box, for example:
> >
> > LAN_INET_HOST_OPEN_UDP="192.168.1.99>0/0~53"
> >
> > to fix this David would have to add:
> >
> > LAN_INET_HOST_OPEN_UDP="192.168.1.99>0/0~53 0/0>0/0~0-52,54-65535"
> > LAN_INET_HOST_OPEN_TCP="192.168.1.99>0/0~53 0/0>0/0~0-52,54-65535"
> > (and add any protocols if needed for PPTP or IPsec outbound with
> LAN_INET_HOST_OPEN_IP)
> >
> > But, with the above settings the "Deny LAN->EXT" is not required since
> the the default policy is now DROP.
> >
> > So, to recap, back to David's quest to block DNS for LAN boxes, he can:
> >
> > 1) With no DNS exceptions, (works now from the Firewall tab):
> >
> > "Deny LAN->EXT" TCP/UDP 0/0 0/0 53
> >
> >
> > 2) Support DNS exceptions for certain LAN boxes (if we added support for
> "Pass LAN->EXT" in the Firewall tab in the web interface):
> >
> > "Pass LAN->EXT" TCP/UDP 192.168.1.99 0/0 53
> > "Pass LAN->EXT" TCP/UDP 0/0 0/0 0-52,54-65535
> >
> > Note: no "Deny LAN->EXT" rule is necessary.
> >
> >
> > Hmmm, maybe this is not so confusing after all...
> >
> > Lonnie
> >
> >
> >
> >
> > On Jul 16, 2012, at 8:58 AM, Lonnie Abelbeck wrote:
> >
> > >
> > > On Jul 16, 2012, at 2:53 AM, Michael Keuter wrote:
> > >
> > >>
> > >> Am 16.07.2012 um 01:39 schrieb Lonnie Abelbeck:
> > >>
> > >>> David,
> > >>>
> > >>> With the general DNS block in place...
> > >>>
> > >>> LAN_INET_HOST_OPEN_UDP="192.168.1.99>0/0~53"
> > >>>
> > >>> will allow the internal 192.168.1.99 device to access any external
> DNS server.
> > >>>
> > >>> Lonnie
> > >>>
> > >>> PS: In the web interface we don't support "Pass LAN->EXT" rules,
> since that is the default policy and would seem confusing, but coupled
> with "Deny LAN->EXT" it can be useful it seems.
> > >>
> > >>
> > >> Yes, in some situations "Pass LAN->EXT" would be quite handy.
> > >>
> > >> Michael
> > >>
> > >> http://www.mksolutions.info
> > >
> > > Yes, it makes sense.
> > >
> > > I'll add both "Pass LAN->EXT" and "Pass DMZ->EXT" to the Firewall tab
> action menu in the web interface.
> > >
> > > If we place them toward the bottom, after the Deny actions, it might
> make more sense why they are useful and possibly be less confusing to new
> users.
> > >
> > > Lonnie
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > Live Security Virtual Conference
> > Exclusive live event will cover all the ways today's security and
> > threat landscape has changed and how IT managers can respond. Discussions
> > will include endpoint security, mobile security and the latest in malware
> > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> > _______________________________________________
> > Astlinux-users mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/astlinux-users
> >
> > Donations to support AstLinux are graciously accepted via PayPal to
> [email protected].
> >
> >
> ------------------------------------------------------------------------------
> > Live Security Virtual Conference
> > Exclusive live event will cover all the ways today's security and
> > threat landscape has changed and how IT managers can respond. Discussions
> > will include endpoint security, mobile security and the latest in malware
> > threats.
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
> > Astlinux-users mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/astlinux-users
> >
> > Donations to support AstLinux are graciously accepted via PayPal to
> [email protected].
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Astlinux-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/astlinux-users
>
> Donations to support AstLinux are graciously accepted via PayPal to
> [email protected].
>
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Astlinux-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/astlinux-users
Donations to support AstLinux are graciously accepted via PayPal to
[email protected].
