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].
