[OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)

Justin Vallon justinvallon at gmail.com
Tue Jul 15 17:43:45 EDT 2014


I don't think turning off the firewall is a sane default.  Your
arguments based on "global addressability" are false because IPv4 can be
globally addressable, if you want.  You can get static ip addresses (or
a subnet), turn off NAT, and turn off the firewall - every "internal"
network device will be on the public internet.

You say:  "A general principle is that a service should not be bound on
a globally reachable address if it is not meant to be globally
accessible."  If my desktop is given an IPv6 address, are all of my
services now globally addressable?  If yes, I have opened up all local
services (oops).  If no, do I need a "locally addressable" and "globally
addressable" IPv6 space for each device & service, so that I can choose
which services I consider internal (my printer, my smb share) vs
external (my web server)?  That is pushing the security problem to the
"terminal" devices.

> I do not understand what the principle of least privilege has to do
here. “Forbidden by default” is not about privileges.

Privilege here is the right to do something; with respect to networking:
open a connection to any host, open a connection to a specific host,
allow incoming connections from any host.  Principle of least privilege
means that you only allow what is required - default is to restrict, not
allow.  Privileges are granted where necessary, instead of taken away
when abused.  Here, incoming connections represent a security risk
(hackers), and mitigation is that it becomes a privilege (to be
earned).  By default, incoming connections are not allowed, and uPNP
(etc) is used to request (and grant) that privilege.

-Justin


On 7/15/14, 1:43 PM, Benjamin Cama wrote:
> Le mardi 15 juillet 2014 à 11:45 -0400, Aaron Z a écrit :
>> ----- Original Message -----
>> On Monday, July 14, 2014 5:36:09 PM "Benjamin Cama" <benoar at dolka.fr> wrote:
>>> Hi everyone,
>>>
>>> Le lundi 14 juillet 2014 à 22:17 +0900, Baptiste Jonglez a écrit :
>>>> I'd rather have "Don't bother the user": things should generally
>>>> just
>>>> work, without having to configure anything (in this case, port
>>>> forwarding).  But there is an obvious tradeoff with security.
>>> I agree with Baptiste here. There is no equivalent in IPv4 of “global
>>> reachability” by default with the NATs we have today, so we can't
>>> have
>>> the same defaults. Global reachability is how IP in general was meant
>>> to
>>> be; please, do not make it broken again.
>> As I understand it, this is NOT adding NAT, but (by default) blocking
>> unsolicited incoming connections from the outside world to devices on
>> the internal network (which dont necessarily need to be accessible
>> from the outside world).
> This thread is about choosing a sane default. Blocking by default means
> you can't have VoIP or P2P working out of the box. This was tricky with
> IPv4+NAT as it involves some trickery and software support (see UPnP and
> the like), but IPv6 offers the possibility to have it work without any
> supplemental development effort!
>
> When you say that devices don't “necessarily” need to be accessible, you
> already made a choice that is impossible to change back for 99.99% of
> people (which don't know how to tune a firewall).
>
>> That is the whole point in using a firewall is it not? To keep people
>> out of where they shouldn't be.
> Well, you can configure your “firewall” as it pleases you to block
> whatever you want, but the one in OpenWRT is quite “open” by default, as
> much as permit IPv4 (which is, only outbound connections are allowed;
> inbound connections are not possible “by design” by default because of
> NAT).
>
>>>>> Opening up the IPv6 firewall by default would be unexpected and I
>>>>> don't
>>>>> really like the approach for that matter and honestly I don't
>>>>> trust
>>>>> client devices that much.
>>>> At least opening UDP ports > 1024 seems pretty reasonable, and
>>>> covers most
>>>> use-cases regarding VoIP and video.  But it does indeed depart from
>>>> the
>>>> IPv4 case (not sure if it is such a bad idea though).
>>> This looks like a good compromise to me. Knowledgeable users can
>>> disable
>>> the firewall for needed hosts, while for others this “just work”. PCP
>>> may be coming one day, but it's still not there yet, so we need not
>>> to
>>> break the default configuration while waiting for it.
>> Opening access from the outside to the inside as a default rule goes
>> against the "principle of least privilege" on which firewall rules are
>> generally predicated.
> I do not understand what the principle of least privilege has to do
> here. “Forbidden by default” is not about privileges.
>
>> As I understand it, if a device on the inside of the network initiates
>> the connection to a device on the outside (say from a VOIP phone to a
>> VOIP server), return connections from the server are allowed.
> Yes, by looking at it from a very client-inside and server-outside (and
> TCP and state-tracking) view. That is a lot of presuppositions. This
> way, you can call a “server”, but nobody can call you.
>
>> What gets blocked are unsolicited connections from the outside which
>> are generally unneeded (and can be a security risk)
> The “generally unneeded” and “security risk” assumptions are very
> biased, to me. I won't reiterate the general argument about running only
> services that one need, but what we are talking about here is finding a
> compromise between reachability and security. Blocking services bound on
> system ports (<1024, see <http://tools.ietf.org/html/rfc6335#section-6>)
> only seems like a good compromise to me.
>
> A general principle is that a service should not be bound on a globally
> reachable address if it is not meant to be globally accessible. Of
> course two layers of security are better and to apply some global
> network rules, we have firewalls, but this should not hinder the nice
> capability of IP to have global reachability by default by design.
>
>> unless one is running a server (in which case, the users should know
>> how to open ports on their firewall).
> Well, it depends on what is a “server” to you. Is being able to receive
> a phone call directly from your correspondent a “server” use to you?
> Technically, it kind of is (we don't even use the word “server” for it,
> just “peer”). Should user of such a feature (which is just one example
> among many) be savvy enough to be able to open ports on his firewall? I
> don't think so. Same goes for P2P, personal file exchange through
> diverse protocols, general “server” setup without explicit port-opening,
> etc.
>
> Regards,
> --
> benjamin
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


-- 
-Justin
JustinVallon at gmail.com


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4258 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20140715/48cac579/attachment.p7s>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


More information about the openwrt-devel mailing list