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" <ben...@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@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel -- -Justin justinval...@gmail.com
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
