Re: [OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)
On Thu, 17 Jul 2014, Gui Iribarren wrote: On 17/07/14 21:03, David Lang wrote: I know that IPv6 designers pine for the good old days of the Internet when no security was needed. But the reality is that hackers and worms have shown that leaving systems exposed to the Internet is just a Bad Idea. As such, the idea that IPv6 would restore the everyone can connect to everyone on any port of the early '80s was wishful thinking at best. link-local addressing isn't a good idea, because the average home will have three separate links (wired plus two bands of wireless), these can get bridged together, but that causes problems as well. There is no answer here that will satisfy everyone. But do you really want to see the news stories about how anyone running openwrt is vulnerable to $lastest_windows_exploit but people running stock firmware aren't? Hello, thanks for joining the conversation, you might have not spotted this email https://lists.openwrt.org/pipermail/openwrt-devel/2014-July/026813.html as it is now, the situation is actually the opposite of what you're describing, it's more like: Hey, my VoIP calls are failing, as well as PopcornTime videos, since I installed OpenWRT. They were working just fine with stock TPLink firmware Have you got any examples of stock firmware that blocks incoming traffic by default? In this discussion I have only seen talk of two that don't. Every IPv4 home router I have seen defaults to 'block all incoming, unless something on the inside opens it' If IPv6 routers end up being wide open, then we are going to start seeing people getting compromized and the analysis being that it was through IPv6 and it will get an (undeserved) reputation of being less secure than IPv4 just because stupid vendors are going to have their stuff exposed. We've seen worms specifically targeting printers in the past, what makes you think we aren't going to see things like that exploiting NAS devices, DNLA servers, thermostats, etc? You would be horrified to see what passes for security in the Internet of Things. A lot of that software makes me think of stuff from the '70s and early '80s. I've seen devices manufactured in 2012 that used 4 bits for the year (with the epoc being Jan 1 2010)!! The horror stories that you have heard about how insecure SCADA and other industrial devices are are not exaggerations, if anything they understate the problems. think about the early Internet protocols (SNMP and tFTP), and think about systems that make them look sane and perfectly reasonable. Exposing these systems to inbound connections from anywhere on the Internet is irresponsible. Now, if these devices make a connection out to phone home, allowing that home to reach back is reasonable, and supporting things like upnp to allow devices to specifically open up inbound connections are reasonable. I'm not saying that it needs to be as hard to configure as getting in through IPv4 NAT, but it should NOT be the 'open end-to-end Internet the way $DIETY intended' look at how easy it is to 'root' phones, where the company involved is at least reasonable competent in writing software. For a lot of the IoT devices, the Internet is a rushed, tacked on addition (they already needed a processor to manage something, so spend a few cents more and now they can advertise this mobile device app). Try using some of these apps and devices and see how horrific the software is. David Lang cheers! Yes, it would be ideal if every host was locked down so that it was safe for them to be exposed. But that's not the world we live in. David Lang On Wed, 16 Jul 2014, Lyme Marionette wrote: - Original Message - On Wednesday, July 16, 2014 2:10:53 PM Gui Iribarren g...@altermundi.net wrote: Benjamin is giving some great examples of real-world scenarios where an default-open firewall simplifies administration, and where a default-closed firewall would be not only unnecessary (provides no benefits), but would indeed complicate setting up things. There have been many good arguments posted on this subject and to throw my opinion in, it a question of effort and expectations. I think everyone can agree that: -It takes equal effort to turn a firewall on, as it does to turn one off. -It takes equal effort to create a specific block list, as it does to create a specific allow list. -UPnP is not included by default for either the ipv4 or ipv6 stacks. I would also go further to suggest that: -Consistency is good, even if it consistent for superficial reasons. We know that, for NAT reasons, that the ipv4 stack by default blocks incoming connections: -Because it doesn't know by default where to route them. -ipv4 end-points have been traditionally insecure. The two ways to get around this (for gaming, etc): -Through setting firewall rules to route the traffic to an end-point. -Through the use of UPnP (which is used by most games to host, and gaming consoles). With the adoption of
Re: [OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)
by the way, link local addresses are not going to be used for these devices, because they will all have some 'cloud' feature that will require they have a way to phone home. David Lang On Fri, 18 Jul 2014, David Lang wrote: Every IPv4 home router I have seen defaults to 'block all incoming, unless something on the inside opens it' If IPv6 routers end up being wide open, then we are going to start seeing people getting compromized and the analysis being that it was through IPv6 and it will get an (undeserved) reputation of being less secure than IPv4 just because stupid vendors are going to have their stuff exposed. We've seen worms specifically targeting printers in the past, what makes you think we aren't going to see things like that exploiting NAS devices, DNLA servers, thermostats, etc? You would be horrified to see what passes for security in the Internet of Things. A lot of that software makes me think of stuff from the '70s and early '80s. I've seen devices manufactured in 2012 that used 4 bits for the year (with the epoc being Jan 1 2010)!! The horror stories that you have heard about how insecure SCADA and other industrial devices are are not exaggerations, if anything they understate the problems. think about the early Internet protocols (SNMP and tFTP), and think about systems that make them look sane and perfectly reasonable. Exposing these systems to inbound connections from anywhere on the Internet is irresponsible. Now, if these devices make a connection out to phone home, allowing that home to reach back is reasonable, and supporting things like upnp to allow devices to specifically open up inbound connections are reasonable. I'm not saying that it needs to be as hard to configure as getting in through IPv4 NAT, but it should NOT be the 'open end-to-end Internet the way $DIETY intended' look at how easy it is to 'root' phones, where the company involved is at least reasonable competent in writing software. For a lot of the IoT devices, the Internet is a rushed, tacked on addition (they already needed a processor to manage something, so spend a few cents more and now they can advertise this mobile device app). Try using some of these apps and devices and see how horrific the software is. David Lang cheers! Yes, it would be ideal if every host was locked down so that it was safe for them to be exposed. But that's not the world we live in. David Lang On Wed, 16 Jul 2014, Lyme Marionette wrote: - Original Message - On Wednesday, July 16, 2014 2:10:53 PM Gui Iribarren g...@altermundi.net wrote: Benjamin is giving some great examples of real-world scenarios where an default-open firewall simplifies administration, and where a default-closed firewall would be not only unnecessary (provides no benefits), but would indeed complicate setting up things. There have been many good arguments posted on this subject and to throw my opinion in, it a question of effort and expectations. I think everyone can agree that: -It takes equal effort to turn a firewall on, as it does to turn one off. -It takes equal effort to create a specific block list, as it does to create a specific allow list. -UPnP is not included by default for either the ipv4 or ipv6 stacks. I would also go further to suggest that: -Consistency is good, even if it consistent for superficial reasons. We know that, for NAT reasons, that the ipv4 stack by default blocks incoming connections: -Because it doesn't know by default where to route them. -ipv4 end-points have been traditionally insecure. The two ways to get around this (for gaming, etc): -Through setting firewall rules to route the traffic to an end-point. -Through the use of UPnP (which is used by most games to host, and gaming consoles). With the adoption of ipv6 there is the opportunity to change this behaviour such that instead of incoming traffic being restricted for technical reasons, that incoming traffic is routed to the correct end-point. However, that begs the questions: A) Is that consistent with what people would expect? B) Are ipv6 end-points secure by design? In regards to A, from the mindset of a non-technical user, would wager that the answer is 'no'. Even though there is a change in technology with ipv6, the ipv6 technology fulfills the same role as ipv4 and this could be seen as opposing direction between the two. This would likely catch many end-users by surprize unless they read the small print regarding this. As for B, given my view of software development, applications, networks, etc (I've been in the IT business for over 25 years now) I would wager that 80% of applications are secure, and that the 0ther 20% make the potential change in policy very risky. IMO, which others may disagree with, would be to include UPnP by default which would/should resolve most of the hosting issues. Thanks. ___ openwrt-devel mailing list
Re: [OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)
Hi Karl, On July 17, 2014 11:40:52 PM CEST, Karl P ka...@tweak.net.au wrote: On 07/17/2014 08:26 PM, Sebastian Moeller wrote: I argue that people unable to change the router settings are better of with all unsolicited inbound traffic disabled. I've tried to avoid weighing in on this, but I'd argue that you're wrong :) Making sure that people can _never_ have services in the future, just because they never had them in the past is a terrible way to live. It seems I was not clear enough: what I meant is: if one can not be added to expose a host IP and port range in one's router than maybe one does not really need the inbound connection to begin with. All that people in my statement need to do is google how to open the ports, not exactly rocket science, is it? People incompetent enough to not being able to open the ports on the router are unlikely to keep all their devices perfectly safe and updated (as if that is enough, given zero-day exploits, but I digress). Really, I do wonder how easy we want to make an attacker's job here ;) Best Regards Sebastian Sincerely, Karl Palsson ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)
Le jeudi 17 juillet 2014 à 17:03 -0700, David Lang a écrit : But the reality is that hackers and worms have shown that leaving systems exposed to the Internet is just a Bad Idea. Do you mean, all the hackers and worms we see today despite all these systems being behind blocking firewalls and NATs? […] link-local addressing isn't a good idea, because the average home will have three separate links (wired plus two bands of wireless), these can get bridged together, but that causes problems as well. For this, you have ULA. It is available in OpenWRT and recommanded by the RFCs cited earlier. […] But do you really want to see the news stories about how anyone running openwrt is vulnerable to $lastest_windows_exploit but people running stock firmware aren't? This is nonsense, this will never happen as nobody cares about OpenWRT. Yes, it would be ideal if every host was locked down so that it was safe for them to be exposed. They are exposed anyway, by other means. -- benjamin ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)
Hi Gui, hi list, Gesendet: Freitag, 18. Juli 2014 um 05:56 Uhr Von: Gui Iribarren g...@altermundi.net An: openwrt-devel@lists.openwrt.org Betreff: Re: [OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1) On 17/07/14 21:59, Fernando Frediani wrote: Perfect and well said. Really don't see why people still think leaving firewalls opened is a good idea. leaving *hosts* firewalls opened is a really bad idea. Agreed. But openwrt doesn't run on hosts, it runs on network equipment I.e. the building blocks of Internet. Carriers don't block traffic, ISP don't block traffic, and back in the day, CPE equipment didn't block traffic either (think of dialup, or dumb cablemodems which would simply act as a bridge) firewall was a software installed in the computer connected to the cablemodem Then, with the ever increasing quantity of devices vs the evident shortage of IPv4, people started to use NAT, or ISPs started to ship CPEs that would do NAT, which made two-way transparent communication impossible. Well, with the growth of the internet also the profitability grew, so malware grew along with the internet. So the need for NAT and the need for more secure home setups co-developed, I would say. I find it difficult to argue that NAT success was driven by a security concern, rather than by IP scarcity. :P [1] Fast-forward a few years, we have a new Internet Protocol being widely deployed that solves the address scarcity, and thus makes NAT unnecessary. Sure, NAT can easily go the way of the Dodo, as long as we keep dropping unsolicited inbound traffic in the router's firewall ;) Now CPEs can work again like transparent devices. ps. RFCs that argue that NAT resulted in a *reduction in security*... Yes, but we are talking not about having openwrt default to ipv6 NAT but what to do with unsolicited inbound traffic, not exactly what is dicussed in the cited rfc... [0]: http://tools.ietf.org/rfc/rfc6092.txt , january/2011 Security Considerations The IPv6 stateful filtering behavior described in this document is intended to be similar in function to the filtering behavior of commonly used IPv4/NAT gateways, which have been widely sold as a security tool for residential and small-office/home-office networks. As noted in the Security Considerations section of [RFC2993], the true impact of these tools may be a reduction in security. It may be generally assumed that the impacts discussed in that document related to filtering (and not translation) are to be expected with the simple IPv6 security mechanisms described here. In particular, it is worth noting that stateful filters create the illusion of a security barrier, but without the managed intent of a firewall. Appropriate security mechanisms implemented in the end What exactly is managed intent of a firewall? nodes, in conjunction with the [RFC4864] local network protection methods, function without reliance on network layer hacks and transport filters that may change over time. Also, defined security barriers assume that threats originate in the exterior, which may lead to practices that result in applications being fully exposed to interior attack and which therefore make breaches much easier. [1]: http://tools.ietf.org/rfc/rfc2993.txt[http://tools.ietf.org/rfc/rfc2993.txt] , november/2000, 11. Summary NAT advantages - no item about security Did you read the last bullet point on opage 8 of rfc 2993? Where NAT is likened with port filtering firewalls in regard to inbound connections, that does not use the word security, but implies it nevertheless. So the RFC explicitly recommends to close all ports by default! And there is a tacked on rant about the 'illusion of security' by an unmanaged firewall is quite funny in thid threads context, as people who can/will not keep the firewall well-configured, surely will manage to keep all their local endpoint machines fully patched, upgraded and securely configured. Your proposal will expose exactly the internaol network nodes of thiose that already have shown not to be too interested in securing their setup... (with the main justification, IIRC, how nice it would be to run open server's on other people's networks). Best Regards Sebastian At the end it will bring more problems than solutions for those using OpenWRT and play against its good reputation. As mentioned before adjusting firewall for specific needs or using UPnP isn't the end of the world. Regards, Fernando On 18/07/2014 01:03, David Lang wrote: I know that IPv6 designers pine for the good old days of the Internet when no security was needed. But the reality is that hackers and worms have shown that leaving systems exposed to the Internet is just a Bad Idea. As such, the idea that IPv6 would restore the everyone can connect to everyone on any port of the early '80s was wishful thinking
Re: [OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)
On Fri, 18 Jul 2014, Benjamin Cama wrote: Le jeudi 17 juillet 2014 à 17:03 -0700, David Lang a écrit : But the reality is that hackers and worms have shown that leaving systems exposed to the Internet is just a Bad Idea. Do you mean, all the hackers and worms we see today despite all these systems being behind blocking firewalls and NATs? Yep, how much worse would they be if more systems were exposed? […] link-local addressing isn't a good idea, because the average home will have three separate links (wired plus two bands of wireless), these can get bridged together, but that causes problems as well. For this, you have ULA. It is available in OpenWRT and recommanded by the RFCs cited earlier. but these low quality devices will not be using local addresses (unless the router implements outbound NAT) because they will need to connect to the cloud […] But do you really want to see the news stories about how anyone running openwrt is vulnerable to $lastest_windows_exploit but people running stock firmware aren't? This is nonsense, this will never happen as nobody cares about OpenWRT. so we should just all go home since nobody cares what we do. Yes, it would be ideal if every host was locked down so that it was safe for them to be exposed. They are exposed anyway, by other means. there are degrees of exposure, and while I agree that perimeter security by itself is not what we really want, throwing away perimeter security on the theory that every device is going to be secure, or that they are exposed anyway is just begging for trouble. David Lang___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)
Le mercredi 16 juillet 2014 à 15:58 -0400, Aaron Z a écrit : IMO, it comes down to trust: Do you trust that the people who made your NAS, blueray player, etc will release patches when exploits are found 3 years down the road? I don't. Do you trust that the people who made the firmware for your networked camera didn't leave any back doors in it to be found down the road (ie: a hardcoded root password, poor security on the webpage, etc)? I don't. Do you trust that Microsoft didn't miss any bugs in the Windows 7 firewall and that none of the software on the computer is leaving a port open? I certainly don't. OK, you prefer to have everything firewalled by default, but what about most people, that will be affected by default settings? (they don't know how to change it and never will touch it; they may even not be allowed if they are not on their “own” network, if that even means something to them) They don't have choice: they _have_ to trust their device/OS. They have no other choice. So the choice is on the manufacturer: either you secure your device and people will trust you, or you build shitty rootable stuff and people will try not to buy your stuff (you see, they may even not have the choice to have trust…). But asking them “patch” the security of their device by mean of some other “magical” device (a firewhat?) is not an option. I would venture to guess that 95% (or more) of the people who install OpenWRT are quite capable of opening ports in a firewall. Yes. But try imagining the impact on the other persons. Now try imagining that this policy is implemented on 90% of home routers. == Perhaps a solution would be to do the following: 1. Have a global setting for the firewall that has three options: 1a. Default open from port 0 on up 1b. Default open from port 1024 on up 1c. Default closed 2. Add/change LUCI interface for opening ports. Add a hyperlink or button next to the list of computers on the network that allows setting the following options (for each computer) in the OpenWRT firewall: 2a. Default to open from port 0 on up 2b. Default open from port 1024 on up 2c. Open port X (or service X) for this computer Yes, this kind of UI would be nice. Factory default could be 1c for the time being (to be consistent with the current IPv4 settings) and it could be re-evaluated down the road as things change. “Down the road” being never, as what sets the “standard” is what is installed in the standard base. Now is time, as this release comes as “IPv6 fully enabled”. -- benjamin ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)
Le mercredi 16 juillet 2014 à 21:12 +0200, Sebastian Moeller a écrit : What is so wonderful about IPv6? Maleware surely will evolve quickly to take advantage of a dropped layer of defense… “Layer of defense”? To most, it will just translate to a brick wall that will have to be worked around by some other mean because nobody except advanced user can configure their firewall. For experts as you and Benjamin the default does not really matter that much you can easily change it to your liking; but think about non-experts. I totally do this for non-experts: non-experts won't ever touch their default configuration. So, basically, they will have no inbound connection possible, so manufacturer will find other mean to do whatever they can to allow for that to happen (as they are doing today with IPv4). It will just be even less controllable by yourself (custom protocols, etc). Even if PCP comes: imagine then that device configured with PCP will be accessible from outside, and… will they be magically immune to anything this way? They will have to be secured anyway. I for one would be quite startled if the switch to IPv6 would expose parts of my device zoo that was never configured with that problem in mind…. Please, cite me any device today that can be dangerously exposed by an IPv6 connectivity. A printer, for example, should be bound (to me) to a link-local address by default. I don't know any manufacturer who does so (well, they don't support IPv6 anyway…). -- benjamin ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)
Le mercredi 16 juillet 2014 à 21:12 +0200, Sebastian Moeller a écrit : What is so wonderful about IPv6? Maleware surely will evolve quickly to take advantage of a dropped layer of defense… “Layer of defense”? To most, it will just translate to a brick wall that will have to be worked around by some other mean because nobody except advanced user can configure their firewall. For experts as you and Benjamin the default does not really matter that much you can easily change it to your liking; but think about non-experts. I totally do this for non-experts: non-experts won't ever touch their default configuration. So, basically, they will have no inbound connection possible, so manufacturer will find other mean to do whatever they can to allow for that to happen (as they are doing today with IPv4). It will just be even less controllable by yourself (custom protocols, etc). Even if PCP comes: imagine then that device configured with PCP will be accessible from outside, and… will they be magically immune to anything this way? They will have to be secured anyway. I for one would be quite startled if the switch to IPv6 would expose parts of my device zoo that was never configured with that problem in mind…. Please, cite me any device today that can be dangerously exposed by an IPv6 connectivity. A printer, for example, should be bound (to me) to a link-local (or ULA) address by default. I don't know any manufacturer who does so (well, they don't support IPv6 anyway…). -- benjamin ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)
Hello Benjamin, On July 17, 2014 7:45:10 PM CEST, Benjamin Cama ben...@dolka.fr wrote: Le mercredi 16 juillet 2014 à 21:12 +0200, Sebastian Moeller a écrit : What is so wonderful about IPv6? Maleware surely will evolve quickly to take advantage of a dropped layer of defense… “Layer of defense”? To most, it will just translate to a brick wall that will have to be worked around by some other mean because nobody except advanced user can configure their firewall. I argue that people unable to change the router settings are better of with all unsolicited inbound traffic disabled. For experts as you and Benjamin the default does not really matter that much you can easily change it to your liking; but think about non-experts. I totally do this for non-experts: non-experts won't ever touch their default configuration. So, basically, they will have no inbound connection possible, so manufacturer will find other mean to do whatever they can to allow for that to happen (as they are doing today with IPv4). It will just be even less controllable by yourself (custom protocols, etc). Even if PCP comes: imagine then that device configured with PCP will be accessible from outside, and… will they be magically immune to anything this way? They will have to be secured anyway. Note that I argue for a per device white list especially since I do not think that an automatic port opening method has the security guarantees I hope for. But note that with your proposal ALL devices need expert configuration. There is no magic immunity by ports closed by default' just a reduced attack surface... I for one would be quite startled if the switch to IPv6 would expose parts of my device zoo that was never configured with that problem in mind…. Please, cite me any device today that can be dangerously exposed by an IPv6 connectivity. While not from today: http://www.kb.cert.org/vuls/id/986425 looks pretty bad... Actually googling for IPv6 cve does seem to find quite a lot. At least enough to make port open by default look like a risky proposition. Now you could argue that all Linux CVEs will also affect the router... But assuming all ipv6 devices will stay safe and secure forever seems a bit to optimistic... A printer, for example, should be bound (to me) to a link-local address by default. I don't know any manufacturer who does so (well, they don't support IPv6 anyway…). -- benjamin -- Sent from my Android device with K-9 Mail. Please excuse my brevity. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)
On 07/17/2014 08:26 PM, Sebastian Moeller wrote: I argue that people unable to change the router settings are better of with all unsolicited inbound traffic disabled. I've tried to avoid weighing in on this, but I'd argue that you're wrong :) Making sure that people can _never_ have services in the future, just because they never had them in the past is a terrible way to live. Sincerely, Karl Palsson ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)
I know that IPv6 designers pine for the good old days of the Internet when no security was needed. But the reality is that hackers and worms have shown that leaving systems exposed to the Internet is just a Bad Idea. As such, the idea that IPv6 would restore the everyone can connect to everyone on any port of the early '80s was wishful thinking at best. link-local addressing isn't a good idea, because the average home will have three separate links (wired plus two bands of wireless), these can get bridged together, but that causes problems as well. There is no answer here that will satisfy everyone. But do you really want to see the news stories about how anyone running openwrt is vulnerable to $lastest_windows_exploit but people running stock firmware aren't? Yes, it would be ideal if every host was locked down so that it was safe for them to be exposed. But that's not the world we live in. David Lang On Wed, 16 Jul 2014, Lyme Marionette wrote: - Original Message - On Wednesday, July 16, 2014 2:10:53 PM Gui Iribarren g...@altermundi.net wrote: Benjamin is giving some great examples of real-world scenarios where an default-open firewall simplifies administration, and where a default-closed firewall would be not only unnecessary (provides no benefits), but would indeed complicate setting up things. There have been many good arguments posted on this subject and to throw my opinion in, it a question of effort and expectations. I think everyone can agree that: -It takes equal effort to turn a firewall on, as it does to turn one off. -It takes equal effort to create a specific block list, as it does to create a specific allow list. -UPnP is not included by default for either the ipv4 or ipv6 stacks. I would also go further to suggest that: -Consistency is good, even if it consistent for superficial reasons. We know that, for NAT reasons, that the ipv4 stack by default blocks incoming connections: -Because it doesn't know by default where to route them. -ipv4 end-points have been traditionally insecure. The two ways to get around this (for gaming, etc): -Through setting firewall rules to route the traffic to an end-point. -Through the use of UPnP (which is used by most games to host, and gaming consoles). With the adoption of ipv6 there is the opportunity to change this behaviour such that instead of incoming traffic being restricted for technical reasons, that incoming traffic is routed to the correct end-point. However, that begs the questions: A) Is that consistent with what people would expect? B) Are ipv6 end-points secure by design? In regards to A, from the mindset of a non-technical user, would wager that the answer is 'no'. Even though there is a change in technology with ipv6, the ipv6 technology fulfills the same role as ipv4 and this could be seen as opposing direction between the two. This would likely catch many end-users by surprize unless they read the small print regarding this. As for B, given my view of software development, applications, networks, etc (I've been in the IT business for over 25 years now) I would wager that 80% of applications are secure, and that the 0ther 20% make the potential change in policy very risky. IMO, which others may disagree with, would be to include UPnP by default which would/should resolve most of the hosting issues. Thanks. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)
Perfect and well said. Really don't see why people still think leaving firewalls opened is a good idea. At the end it will bring more problems than solutions for those using OpenWRT and play against its good reputation. As mentioned before adjusting firewall for specific needs or using UPnP isn't the end of the world. Regards, Fernando On 18/07/2014 01:03, David Lang wrote: I know that IPv6 designers pine for the good old days of the Internet when no security was needed. But the reality is that hackers and worms have shown that leaving systems exposed to the Internet is just a Bad Idea. As such, the idea that IPv6 would restore the everyone can connect to everyone on any port of the early '80s was wishful thinking at best. link-local addressing isn't a good idea, because the average home will have three separate links (wired plus two bands of wireless), these can get bridged together, but that causes problems as well. There is no answer here that will satisfy everyone. But do you really want to see the news stories about how anyone running openwrt is vulnerable to $lastest_windows_exploit but people running stock firmware aren't? Yes, it would be ideal if every host was locked down so that it was safe for them to be exposed. But that's not the world we live in. David Lang On Wed, 16 Jul 2014, Lyme Marionette wrote: - Original Message - On Wednesday, July 16, 2014 2:10:53 PM Gui Iribarren g...@altermundi.net wrote: Benjamin is giving some great examples of real-world scenarios where an default-open firewall simplifies administration, and where a default-closed firewall would be not only unnecessary (provides no benefits), but would indeed complicate setting up things. There have been many good arguments posted on this subject and to throw my opinion in, it a question of effort and expectations. I think everyone can agree that: -It takes equal effort to turn a firewall on, as it does to turn one off. -It takes equal effort to create a specific block list, as it does to create a specific allow list. -UPnP is not included by default for either the ipv4 or ipv6 stacks. I would also go further to suggest that: -Consistency is good, even if it consistent for superficial reasons. We know that, for NAT reasons, that the ipv4 stack by default blocks incoming connections: -Because it doesn't know by default where to route them. -ipv4 end-points have been traditionally insecure. The two ways to get around this (for gaming, etc): -Through setting firewall rules to route the traffic to an end-point. -Through the use of UPnP (which is used by most games to host, and gaming consoles). With the adoption of ipv6 there is the opportunity to change this behaviour such that instead of incoming traffic being restricted for technical reasons, that incoming traffic is routed to the correct end-point. However, that begs the questions: A) Is that consistent with what people would expect? B) Are ipv6 end-points secure by design? In regards to A, from the mindset of a non-technical user, would wager that the answer is 'no'. Even though there is a change in technology with ipv6, the ipv6 technology fulfills the same role as ipv4 and this could be seen as opposing direction between the two. This would likely catch many end-users by surprize unless they read the small print regarding this. As for B, given my view of software development, applications, networks, etc (I've been in the IT business for over 25 years now) I would wager that 80% of applications are secure, and that the 0ther 20% make the potential change in policy very risky. IMO, which others may disagree with, would be to include UPnP by default which would/should resolve most of the hosting issues. Thanks. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)
On 17/07/14 21:03, David Lang wrote: I know that IPv6 designers pine for the good old days of the Internet when no security was needed. But the reality is that hackers and worms have shown that leaving systems exposed to the Internet is just a Bad Idea. As such, the idea that IPv6 would restore the everyone can connect to everyone on any port of the early '80s was wishful thinking at best. link-local addressing isn't a good idea, because the average home will have three separate links (wired plus two bands of wireless), these can get bridged together, but that causes problems as well. There is no answer here that will satisfy everyone. But do you really want to see the news stories about how anyone running openwrt is vulnerable to $lastest_windows_exploit but people running stock firmware aren't? Hello, thanks for joining the conversation, you might have not spotted this email https://lists.openwrt.org/pipermail/openwrt-devel/2014-July/026813.html as it is now, the situation is actually the opposite of what you're describing, it's more like: Hey, my VoIP calls are failing, as well as PopcornTime videos, since I installed OpenWRT. They were working just fine with stock TPLink firmware Have you got any examples of stock firmware that blocks incoming traffic by default? In this discussion I have only seen talk of two that don't. cheers! Yes, it would be ideal if every host was locked down so that it was safe for them to be exposed. But that's not the world we live in. David Lang On Wed, 16 Jul 2014, Lyme Marionette wrote: - Original Message - On Wednesday, July 16, 2014 2:10:53 PM Gui Iribarren g...@altermundi.net wrote: Benjamin is giving some great examples of real-world scenarios where an default-open firewall simplifies administration, and where a default-closed firewall would be not only unnecessary (provides no benefits), but would indeed complicate setting up things. There have been many good arguments posted on this subject and to throw my opinion in, it a question of effort and expectations. I think everyone can agree that: -It takes equal effort to turn a firewall on, as it does to turn one off. -It takes equal effort to create a specific block list, as it does to create a specific allow list. -UPnP is not included by default for either the ipv4 or ipv6 stacks. I would also go further to suggest that: -Consistency is good, even if it consistent for superficial reasons. We know that, for NAT reasons, that the ipv4 stack by default blocks incoming connections: -Because it doesn't know by default where to route them. -ipv4 end-points have been traditionally insecure. The two ways to get around this (for gaming, etc): -Through setting firewall rules to route the traffic to an end-point. -Through the use of UPnP (which is used by most games to host, and gaming consoles). With the adoption of ipv6 there is the opportunity to change this behaviour such that instead of incoming traffic being restricted for technical reasons, that incoming traffic is routed to the correct end-point. However, that begs the questions: A) Is that consistent with what people would expect? B) Are ipv6 end-points secure by design? In regards to A, from the mindset of a non-technical user, would wager that the answer is 'no'. Even though there is a change in technology with ipv6, the ipv6 technology fulfills the same role as ipv4 and this could be seen as opposing direction between the two. This would likely catch many end-users by surprize unless they read the small print regarding this. As for B, given my view of software development, applications, networks, etc (I've been in the IT business for over 25 years now) I would wager that 80% of applications are secure, and that the 0ther 20% make the potential change in policy very risky. IMO, which others may disagree with, would be to include UPnP by default which would/should resolve most of the hosting issues. Thanks. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)
On 17/07/14 21:59, Fernando Frediani wrote: Perfect and well said. Really don't see why people still think leaving firewalls opened is a good idea. leaving *hosts* firewalls opened is a really bad idea. Agreed. But openwrt doesn't run on hosts, it runs on network equipment I.e. the building blocks of Internet. Carriers don't block traffic, ISP don't block traffic, and back in the day, CPE equipment didn't block traffic either (think of dialup, or dumb cablemodems which would simply act as a bridge) firewall was a software installed in the computer connected to the cablemodem Then, with the ever increasing quantity of devices vs the evident shortage of IPv4, people started to use NAT, or ISPs started to ship CPEs that would do NAT, which made two-way transparent communication impossible. I find it difficult to argue that NAT success was driven by a security concern, rather than by IP scarcity. :P [1] Fast-forward a few years, we have a new Internet Protocol being widely deployed that solves the address scarcity, and thus makes NAT unnecessary. Now CPEs can work again like transparent devices. ps. RFCs that argue that NAT resulted in a *reduction in security*... [0]: http://tools.ietf.org/rfc/rfc6092.txt , january/2011 Security Considerations The IPv6 stateful filtering behavior described in this document is intended to be similar in function to the filtering behavior of commonly used IPv4/NAT gateways, which have been widely sold as a security tool for residential and small-office/home-office networks. As noted in the Security Considerations section of [RFC2993], the true impact of these tools may be a reduction in security. It may be generally assumed that the impacts discussed in that document related to filtering (and not translation) are to be expected with the simple IPv6 security mechanisms described here. In particular, it is worth noting that stateful filters create the illusion of a security barrier, but without the managed intent of a firewall. Appropriate security mechanisms implemented in the end nodes, in conjunction with the [RFC4864] local network protection methods, function without reliance on network layer hacks and transport filters that may change over time. Also, defined security barriers assume that threats originate in the exterior, which may lead to practices that result in applications being fully exposed to interior attack and which therefore make breaches much easier. [1]: http://tools.ietf.org/rfc/rfc2993.txt , november/2000, 11. Summary NAT advantages - no item about security At the end it will bring more problems than solutions for those using OpenWRT and play against its good reputation. As mentioned before adjusting firewall for specific needs or using UPnP isn't the end of the world. Regards, Fernando On 18/07/2014 01:03, David Lang wrote: I know that IPv6 designers pine for the good old days of the Internet when no security was needed. But the reality is that hackers and worms have shown that leaving systems exposed to the Internet is just a Bad Idea. As such, the idea that IPv6 would restore the everyone can connect to everyone on any port of the early '80s was wishful thinking at best. link-local addressing isn't a good idea, because the average home will have three separate links (wired plus two bands of wireless), these can get bridged together, but that causes problems as well. There is no answer here that will satisfy everyone. But do you really want to see the news stories about how anyone running openwrt is vulnerable to $lastest_windows_exploit but people running stock firmware aren't? Yes, it would be ideal if every host was locked down so that it was safe for them to be exposed. But that's not the world we live in. David Lang On Wed, 16 Jul 2014, Lyme Marionette wrote: - Original Message - On Wednesday, July 16, 2014 2:10:53 PM Gui Iribarren g...@altermundi.net wrote: Benjamin is giving some great examples of real-world scenarios where an default-open firewall simplifies administration, and where a default-closed firewall would be not only unnecessary (provides no benefits), but would indeed complicate setting up things. There have been many good arguments posted on this subject and to throw my opinion in, it a question of effort and expectations. I think everyone can agree that: -It takes equal effort to turn a firewall on, as it does to turn one off. -It takes equal effort to create a specific block list, as it does to create a specific allow list. -UPnP is not included by default for either the ipv4 or ipv6 stacks. I would also go further to suggest that: -Consistency is good, even if it consistent for superficial reasons. We know that, for NAT reasons, that the ipv4 stack by default blocks incoming connections: -Because it doesn't know by default where to route them. -ipv4 end-points have been
Re: [OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)
Hi, A typical home connection is not an ISP. Also OpenWRT for the majority of the cases isn't just 'a router', but also as a firewall and to protect user's network either on IPv4 or IPv6, not just a dummy bridge device. I guess I see the good intentions of those defending it should be opened, but that is taking in consideration only a specific technical point of view and thinking only how it should be in an ideal world. However the reality that must be taken in consideration are the real-world effects of this which will certainly bring more problems than solutions. If a problem must exist, I prefer it to be that the user have to spend a minute or two to adjust his router's firewall adding the few exceptions that have to be allowed into his network. Regards, Fernando Frediani On 18/07/2014 04:56, Gui Iribarren wrote: On 17/07/14 21:59, Fernando Frediani wrote: Perfect and well said. Really don't see why people still think leaving firewalls opened is a good idea. leaving *hosts* firewalls opened is a really bad idea. Agreed. But openwrt doesn't run on hosts, it runs on network equipment I.e. the building blocks of Internet. Carriers don't block traffic, ISP don't block traffic, and back in the day, CPE equipment didn't block traffic either (think of dialup, or dumb cablemodems which would simply act as a bridge) firewall was a software installed in the computer connected to the cablemodem Then, with the ever increasing quantity of devices vs the evident shortage of IPv4, people started to use NAT, or ISPs started to ship CPEs that would do NAT, which made two-way transparent communication impossible. I find it difficult to argue that NAT success was driven by a security concern, rather than by IP scarcity. :P [1] Fast-forward a few years, we have a new Internet Protocol being widely deployed that solves the address scarcity, and thus makes NAT unnecessary. Now CPEs can work again like transparent devices. ps. RFCs that argue that NAT resulted in a *reduction in security*... [0]: http://tools.ietf.org/rfc/rfc6092.txt , january/2011 Security Considerations The IPv6 stateful filtering behavior described in this document is intended to be similar in function to the filtering behavior of commonly used IPv4/NAT gateways, which have been widely sold as a security tool for residential and small-office/home-office networks. As noted in the Security Considerations section of [RFC2993], the true impact of these tools may be a reduction in security. It may be generally assumed that the impacts discussed in that document related to filtering (and not translation) are to be expected with the simple IPv6 security mechanisms described here. In particular, it is worth noting that stateful filters create the illusion of a security barrier, but without the managed intent of a firewall. Appropriate security mechanisms implemented in the end nodes, in conjunction with the [RFC4864] local network protection methods, function without reliance on network layer hacks and transport filters that may change over time. Also, defined security barriers assume that threats originate in the exterior, which may lead to practices that result in applications being fully exposed to interior attack and which therefore make breaches much easier. [1]: http://tools.ietf.org/rfc/rfc2993.txt , november/2000, 11. Summary NAT advantages - no item about security At the end it will bring more problems than solutions for those using OpenWRT and play against its good reputation. As mentioned before adjusting firewall for specific needs or using UPnP isn't the end of the world. Regards, Fernando On 18/07/2014 01:03, David Lang wrote: I know that IPv6 designers pine for the good old days of the Internet when no security was needed. But the reality is that hackers and worms have shown that leaving systems exposed to the Internet is just a Bad Idea. As such, the idea that IPv6 would restore the everyone can connect to everyone on any port of the early '80s was wishful thinking at best. link-local addressing isn't a good idea, because the average home will have three separate links (wired plus two bands of wireless), these can get bridged together, but that causes problems as well. There is no answer here that will satisfy everyone. But do you really want to see the news stories about how anyone running openwrt is vulnerable to $lastest_windows_exploit but people running stock firmware aren't? Yes, it would be ideal if every host was locked down so that it was safe for them to be exposed. But that's not the world we live in. David Lang On Wed, 16 Jul 2014, Lyme Marionette wrote: - Original Message - On Wednesday, July 16, 2014 2:10:53 PM Gui Iribarren g...@altermundi.net wrote: Benjamin is giving some great examples of real-world scenarios where an default-open firewall simplifies administration, and where a
Re: [OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)
Le mardi 15 juillet 2014 à 17:43 -0400, Justin Vallon a écrit : I don't think turning off the firewall is a sane default. I don't advise to turn it off for everything. I am trying to find a good compromise. 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. Yes (even if I don't understand why you are talking about static addressing; it could work with DHCP the same) but you are talking about people who are able to be routed a public IPv4 prefix, which is very few people today, and will be almost nobody in the future because of IPv4 address space depletion. I assume almost every user of OpenWRT is a “home” user and I believe none of them are offered such a possibility by there ISP (well, I happen to have this possibility with my ISP, but it is a very tiny exception, and I don't even use it). 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? Yes. If yes, I have opened up all local services (oops). Well, if you didn't want them to be accessible, you have many possibilities: bind it on some non-global address (LL, ULA), restrict it locally (/etc/hosts.deny when appropriate, custom configuration that limit access to some range, etc), use some authentication, configure your firewall appropriately (on the targeted machine or on your router), … The thing here, is to find a _default_: you are imagining a case where every service should be blocked from outside access by default. But I would like my telephony programs, my P2P clients, my local daemons that I run for friends (local git repos, experimental web apps,…), my different servers that listen on different addresses, etc, to be accessible by default. It seems to me that there are far more use cases for allowed access by default than forbidden access. The thing is, these use cases are not very common today because there is no equivalent in IPv4 (practically): you cannot have “accessible by default” in today NATed IPv4. 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)? Yes, this is one possibility. OpenWRT even have by default an ULA prefix configured for delegation on the local network! (BTW, there is a bug that make it configure the /60 on the lan by default, I couldn't trace its origin) Or you could use one of the means I listed. Comprising configuring OpenWRT's firewall. But what should be the default? Is your use case representing what would be globally the right solution? Of course, a lot of people on this ML are thinking in terms of “I can configure my firewall myself”, but this is not the case of the casual users. And I think that in the end, there are far more casual users of OpenWRT that one think if you take into account people that will use your router to access the Internet: these are the ones that will be blocked to run whatever software they want. That is pushing the security problem to the terminal devices. And this is exactly what the end-to-end argument is about! http://en.wikipedia.org/wiki/End-to-end_principle But I don't want to remove the possibility to secure you network at the edge; I just want to say that by default, we could block only a small portion of traffic and let the less security-problematic one flow. Everyone has the possibility to forbid some traffic at the edge by configuring its firewall. By the way, when we talk about restrict the use of some port, we automatically forbid IPsec (RFC 4301 http://tools.ietf.org/html/rfc4301) and Mobile IPv6 (RFC 6275 http://tools.ietf.org/html/rfc6275), which are layer 3 protocols that don't bother about ports. It is a bit sad when we are forbidding some traffic for “security”. 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. Why would you immediately talk about abuses? When one is talking about connecting to someone, that means that your correspondent has allowed traffic to flow in. Was your correspondent abused? No, he willingly bound some software to some address, and offered a service. Should this “privilege” be granted only to a few? I don't think so. This is
Re: [OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)
On Tue, Jul 15, 2014 at 11:45:27AM -0400, Aaron Z wrote: 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, this is exactly the role of a stateful firewall. I assume your VoIP example is about SIP. This is an interesting example, because actual voice traffic (RTP) will flow *directly* between endpoints, without going through the server. Obviously, this will fail if your firewall blocks all unsolicited inbound traffic. See: http://blog.lithiumblue.com/2007/07/understanding-relationship-between-sip.html What gets blocked are unsolicited connections from the outside which are generally unneeded (and can be a security risk) unless one is running a server (in which case, the users should know how to open ports on their firewall). You have a client/server model in mind. These is not the only kind of applications out there (see my previous examples: voice or video chat, P2P file sharing, network games, etc). This is all about end-to-end reachability, and the end-to-end argument: http://coreinternetvalues.org/?page_id=1415 http://tools.ietf.org/html/rfc3724 http://en.wikipedia.org/wiki/End-to-end_principle End-to-end reachability has been mostly lost with the IPv4 NAT. We have invested tremendous efforts into ugly workarounds for this lack of end-to-end reachability: ICE, TURN, STUN, UPnP, many ALG, etc. So, really, IPv4 should not be the model and these ugly workarounds should not be seen as natural. IPv6 brings back end-to-end reachability, with all its virtues. Now back to practical issues. My favourite use case is video over XMPP (since I ran into this issue). Let's say you want to establish a video conversation with somebody, using XMPP (Jingle). Assume that the stateful firewall of your home router discards all unsolicited inbound traffic, and does not implement any firewall control protocol (for instance, it is running a default installation of OpenWRT). Then, video will just fail: you won't receive any video from your friend, because it is sent directly to you, and your firewall drops it. The same applies if you want to run a game server, use a P2P file sharing system, or more generally any system based on peer-to-peer communication. Note that I'm only talking about IPv6, so NAT is out of scope: in any case, this is really a matter of stateful firewall, not NAT. You have three general classes of solutions to solve the above problem: 1/ Modify the applications to use intermediate servers for communicating between peers. This is very complicated, inefficient network-wise (since you add an extra intermediary instead of sending traffic directly), and completely misses the point: it basically introduces a client-server model where it's neither needed nor desired. 2/ Allow inbound traffic in the home gateway's firewall. In an ideal world, this is the best solution, since it leaves all the intelligence to end nodes (in accordance with the end-to-end principle). In practice, it is generally frowned upon for home networks, as people don't have any control on their own end-devices nowadays. This is quite sad, but that's a different story. Note that it is not a all-or-nothing solution: the initial proposition was to only allow UDP ports 1024 by default, not *any* traffic. 3/ Use a firewall control protocol, so that end devices can request port forwarding. There are several protocols for this: UPnP, NAT-PMP, PCP. This is not ideal from an end-to-end perspective, since a state must be maintained in the home router. If the router reboots, all mappings are lost. Note that PCP deals with this in a mostly reasonable way [1], so it should not matter a lot in practice (not sure about UPnP and NAT-PMP). Additionally, it requires a modification to the applications, but it's not a big modification (we've been doing with IPv4 for years, using UPnP and NAT-PMP). Currently, OpenWRT implements none of these methods (2/ or 3/), since miniupnpd is not included by default. If we want to fix this, I have a personal preference for (a limited version of) 2/, but 3/ is also fine. Note that both approaches are not incompatible, and it could actually be a good idea to do both. Regards, Baptiste [1] http://tools.ietf.org/html/rfc6887#section-14 pgpLxlbzIO2Xs.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)
+1 to all benjamin arguments, default openwrt ipv4 firewall basically does: * deny all unsolicited traffic coming from WAN to the router (i.e. it's own host) * masquerade the LAN hosts behind a single, scarce, ipv4 address, on outgoing traffic. * allow *any possible traffic* that involves LAN hosts (LAN-LAN, LAN-Router, Router-LAN, LAN-WAN) There's *no* way to allow incoming unsolicited traffic coming from WAN to LAN hosts, since they have no public ips that can address them. So there hasn't been a decision or a policy so far regarding inbound traffic for LAN hosts, there was simply no such scenario. now, default openwrt ipv6 firewall basically does: * deny all unsolicited traffic coming from WAN to the router (i.e. it's own host) * allow *some* traffic involving LAN hosts (LAN-LAN, LAN-Router, Router-LAN, LAN-WAN) * in addition, deny all unsolicited traffic coming from WAN to any LAN host (i.e. taking a decision on behalf of other hosts) it is an error to consider this last point/decision in line with the ipv4 policy, since as stated, there's no such scenario in SOHO ipv4 nets in other words, i'd say the principle of least privilege has not been applied so far in ipv4 world to LAN hosts, (they were allowed to do everything they could possibly do) so if there was any principle so far, was something along full trust for LAN hosts. Now LAN hosts gained a new freedom, getting inbound traffic addressed at themselves. Following the full trust principle, why block that? (and worst: while at it, break ipv6 main 'selling point' - end-to-end internet!) cheers! gui On 16/07/14 05:53, Benjamin Cama wrote: Le mardi 15 juillet 2014 à 17:43 -0400, Justin Vallon a écrit : I don't think turning off the firewall is a sane default. I don't advise to turn it off for everything. I am trying to find a good compromise. 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. Yes (even if I don't understand why you are talking about static addressing; it could work with DHCP the same) but you are talking about people who are able to be routed a public IPv4 prefix, which is very few people today, and will be almost nobody in the future because of IPv4 address space depletion. I assume almost every user of OpenWRT is a “home” user and I believe none of them are offered such a possibility by there ISP (well, I happen to have this possibility with my ISP, but it is a very tiny exception, and I don't even use it). 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? Yes. If yes, I have opened up all local services (oops). Well, if you didn't want them to be accessible, you have many possibilities: bind it on some non-global address (LL, ULA), restrict it locally (/etc/hosts.deny when appropriate, custom configuration that limit access to some range, etc), use some authentication, configure your firewall appropriately (on the targeted machine or on your router), … The thing here, is to find a _default_: you are imagining a case where every service should be blocked from outside access by default. But I would like my telephony programs, my P2P clients, my local daemons that I run for friends (local git repos, experimental web apps,…), my different servers that listen on different addresses, etc, to be accessible by default. It seems to me that there are far more use cases for allowed access by default than forbidden access. The thing is, these use cases are not very common today because there is no equivalent in IPv4 (practically): you cannot have “accessible by default” in today NATed IPv4. 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)? Yes, this is one possibility. OpenWRT even have by default an ULA prefix configured for delegation on the local network! (BTW, there is a bug that make it configure the /60 on the lan by default, I couldn't trace its origin) Or you could use one of the means I listed. Comprising configuring OpenWRT's firewall. But what should be the default? Is your use case representing what would be globally the right solution? Of course, a lot of people on this ML are thinking in terms of “I can configure my firewall myself”, but this is not the case of the casual users. And I think that in the end, there are far more casual users of OpenWRT that one think if you take into account people that will use your router to access the Internet: these are the ones that will be blocked to
Re: [OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)
adding more wood to baptiste fire... :) On 16/07/14 06:15, Baptiste Jonglez wrote: 2/ Allow inbound traffic in the home gateway's firewall. In an ideal world, this is the best solution, since it leaves all the intelligence to end nodes (in accordance with the end-to-end principle). In practice, it is generally frowned upon for home networks, as people don't have any control on their own end-devices nowadays. This is quite sad, but that's a different story. Note that it is not a all-or-nothing solution: the initial proposition was to only allow UDP ports 1024 by default, not *any* traffic. What if we put it the other way around: enterprises who built end-devices have neglected investing in security measures, comforted by the fact that all these years the de-facto scenario was that inbound connections were technically impossible unless explicit rules were put in place. (port forwards) then, what happens when those devices are deployed in a myriad of real-world scenarios? hackers rejoice! http://www.networkworld.com/article/2223785/microsoft-subnet/unpatched-trendnet-ip-cameras-still-provide-a-real-time-peeping-tom-paradise.html http://www.forbes.com/sites/kashmirhill/2013/07/26/smart-homes-hack/ if we wanna do something good for the people that don't have any control on their own end-devices, that'd be: leveraging openwrt position to shift the de-facto landscape of SOHO networks, implementing open-by-default ipv6, and thus push the people who *do* have control of those end-devices (manufacturers) implement proper security. 3/ Use a firewall control protocol, so that end devices can request port forwarding. There are several protocols for this: UPnP, NAT-PMP, PCP. This is not ideal from an end-to-end perspective, since a state must be maintained in the home router. If the router reboots, all mappings are lost. Note that PCP deals with this in a mostly reasonable way [1], so it should not matter a lot in practice (not sure about UPnP and NAT-PMP). Additionally, it requires a modification to the applications, but it's not a big modification (we've been doing with IPv4 for years, using UPnP and NAT-PMP). to me, the logic is flawed here: why break existing functionality (free native flow of ipv6 traffic), then implement a control protocol to make it work again on the firewall side, and in the end modify applications to use that protocol? If you're going to modify applications in the first place, then simply bind the services to the correctly scoped ipv6 address. If the concern is about an hypothetic legacy application that assumes the local network is private and trusted, and is suddenly exposed by global ipv6 connectivity... i have yet to find such a case ;) all potentially vulnerable software i come across was a) either written from an ipv4-only perspective and doesn't actually bind to ipv6 addresses at all; or b) evolved to support both protocols but binds to ipv4-only by default ...just my end-2-end-cents, Cheers! gui ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)
Hi, On Wed, Jul 16, 2014 at 08:41:50AM -0300, Gui Iribarren wrote: then, what happens when those devices are deployed in a myriad of real-world scenarios? hackers rejoice! This actually is a somewhat moot arguments. Devices travel today, and while your home network and office network might be behind a firewall, the hotspot you're using while waiting for your train might not be. So with todays devices, every device needs to be able to protect itself (i.e.: host firewall, services only accepting connection from local network, etc. - windows 7 doing a fairly good job with this today). The old model strong firewall, weak devices behind it is just a thing not matching reality anymore... gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany g...@greenie.muc.de fax: +49-89-35655025g...@net.informatik.tu-muenchen.de pgp1z1dVC3e9u.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)
Le mercredi 16 juillet 2014 à 10:53 +0200, Benjamin Cama a écrit : Well, if you didn't want them to be accessible, you have many possibilities: bind it on some non-global address (LL, ULA), restrict it locally (/etc/hosts.deny when appropriate, custom configuration that limit access to some range, etc), use some authentication, configure your firewall appropriately (on the targeted machine or on your router), … I will give some example of this kind of protection, as I have been operating an open IPv6 home network for more than four years: * My NFS server has a DNS wildcard rule in /etc/exports to limit who can connect * One of my webserver (running nginx), which is not public (contrary to another one) is restricted with some allow/deny rule (à la Apache); I put my local /56. As I have separated LAN from wireless access (different /64), I could even choose not to authorize from wifi but let Ethernet through. Or VPN. Or whatever. * Same for rsync * Local SMTP who don't have to receive mail from outside are just bound to ::1… * My munin on several hosts also have some filters * My SSH is configured with public key only authentication (no password), but accept connections from everywhere Even then, a lot of these services are below 1024, so they would be “protected” by the proposed compromise. On the other hand, I had to do nothing appart from starting the service to offer web access, SMTP, ssh, imap, pop, XMPP, DNS, bittorrent (to several clients), git server, and I even do mobile IPv6. On several hosts; and every guest in my house can do the same. I wish anyone could try this at home, as this gives really a different feeling of what a real “inter-network” access can be. Of course, on the bad side, you have to adapt to the configuration of every software that you want to restrict access to. I wish more of them offered the tcp-wrappers common restriction ability. If you don't want to adapt, then you can go to your firewall config and do the same here. Well, you could even do everything I told from your firewall configuration if you wanted. I totally want people to be able to do that. But forbidding every inbound flow *by default* is to me a bad idea. The advantage I have over other people, maybe, is that I control all the end points I have (they all run free software), so I may be more confident than others. But this is no real reasons to me: as Gert said, every device should be configured in a way that it must be quite resistant to most attacks. This is how the Internet is going to be anyway; you will always find yourself one day on some network you don't know, and your device should be prepared. If you want to be paranoid and block everything on your own network, fine, do it. But the principle of a remote communication through a network is to be reachable, so better be reachable by default ;-) BTW, if you fear being scanned, the IPv6 address space is so big that host that are not publicly known don't risk much. Of course, we are not immune to absolutely every risk, but so is any device, being protected by a firewall or not. -- benjamin ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)
On 14-07-16 08:09 AM, Gert Doering wrote: Hi, This actually is a somewhat moot arguments. Devices travel today, and while your home network and office network might be behind a firewall, the hotspot you're using while waiting for your train might not be. So with todays devices, every device needs to be able to protect itself (i.e.: host firewall, services only accepting connection from local network, etc. - windows 7 doing a fairly good job with this today). The old model strong firewall, weak devices behind it is just a thing not matching reality anymore... While it may be a good idea for your devices to be designed with this principle in mind, I don't necessarily trust all of the IPv6 enabled widgets on my LAN to have been robustly designed with strong local firewalls and free from bugs that remote attackers could exploit. Furthermore, It is not true that every service which can be put on a network, should be put out on the public internet for all to see (ie: SAMBA/NFS). If someone really wants to expose an NFS share to the internet, then they should have the know-how to configure their firewall to do so. Exposing everyones network shares to the public internet by default is a very bad idea. Cheers, Owen ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)
On 16/07/14 12:09, Gert Doering wrote: Hi, On Wed, Jul 16, 2014 at 08:41:50AM -0300, Gui Iribarren wrote: then, what happens when those devices are deployed in a myriad of real-world scenarios? hackers rejoice! This actually is a somewhat moot arguments. Devices travel today, and while your home network and office network might be behind a firewall, the hotspot you're using while waiting for your train might not be. So with todays devices, every device needs to be able to protect itself (i.e.: host firewall, services only accepting connection from local network, etc. - windows 7 doing a fairly good job with this today). The old model strong firewall, weak devices behind it is just a thing not matching reality anymore... Ah, sorry if irony blurred my position: your point, Gert, is exactly my point :) in other words, we're both on the same side: my arguments are in favour of openwrt having an open ipv6 firewall by default, so to put the policy back into end-devices hands (where it always should have been) Benjamin is giving some great examples of real-world scenarios where an default-open firewall simplifies administration, and where a default-closed firewall would be not only unnecessary (provides no benefits), but would indeed complicate setting up things. proprietary-software personal devices are a special case - granted. putting that aside, i think it's insightful to consider that a person that has admin access to all her mobile devices config (which carries every day), so to publish (or restrict) services at her own will, if and only if the network devices upstream (to which might have no control over) have a default-open firewall. in ipv4 world, there was no discussion: a default-open inbound policy in routers that would let end-hosts decide, was simply not possible. why carry that legacy restriction into the wonderful ipv6 world? chee::rs! gui gert ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)
Hi Gui, On Jul 16, 2014, at 20:10 , Gui Iribarren g...@altermundi.net wrote: On 16/07/14 12:09, Gert Doering wrote: Hi, On Wed, Jul 16, 2014 at 08:41:50AM -0300, Gui Iribarren wrote: then, what happens when those devices are deployed in a myriad of real-world scenarios? hackers rejoice! This actually is a somewhat moot arguments. Devices travel today, and while your home network and office network might be behind a firewall, the hotspot you're using while waiting for your train might not be. So with todays devices, every device needs to be able to protect itself (i.e.: host firewall, services only accepting connection from local network, etc. - windows 7 doing a fairly good job with this today). The old model strong firewall, weak devices behind it is just a thing not matching reality anymore... Ah, sorry if irony blurred my position: your point, Gert, is exactly my point :) in other words, we're both on the same side: my arguments are in favour of openwrt having an open ipv6 firewall by default, so to put the policy back into end-devices hands (where it always should have been) ??? The part in parenthesis is debatable... Benjamin is giving some great examples of real-world scenarios where an default-open firewall simplifies administration, and where a default-closed firewall would be not only unnecessary (provides no benefits), but would indeed complicate setting up things. My interpretation of his examples is that putting the MAC/IPv6-addresses into a router-managed whitelist would have not significantly increased the amount of work involved... proprietary-software personal devices are a special case - granted. putting that aside, i think it's insightful to consider that a person that has admin access to all her mobile devices config (which carries every day), so to publish (or restrict) services at her own will, if and only if the network devices upstream (to which might have no control over) have a default-open firewall. But in your home you have control over the router’s setting, so explicitly managing the access rights is an easy way deal with the quite common case you just put aside? Or what is your idea about the proprietary-software personal devices. I could envision two “networks” a secured default-closed and on optimistic default-open network managed by the same router (sort of like a guest network with default-open, while the main network is default-closed or vice versa). in ipv4 world, there was no discussion: a default-open inbound policy in routers that would let end-hosts decide, was simply not possible. ? The default could have been to direct everything to one internal host (say lowest MAC or first discovered device). why carry that legacy restriction into the wonderful ipv6 world? What is so wonderful about IPv6? Maleware surely will evolve quickly to take advantage of a dropped layer of defense… For experts as you and Benjamin the default does not really matter that much you can easily change it to your liking; but think about non-experts. I for one would be quite startled if the switch to IPv6 would expose parts of my device zoo that was never configured with that problem in mind…. Best Regards Sebastian chee::rs! gui gert ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)
- Original Message - On Wednesday, July 16, 2014 2:10:53 PM Gui Iribarren g...@altermundi.net wrote: Benjamin is giving some great examples of real-world scenarios where an default-open firewall simplifies administration, and where a default-closed firewall would be not only unnecessary (provides no benefits), but would indeed complicate setting up things. On the other hand, how many devices realistically need to be accessible from the outside by default in a typical setting (ie: in a home/small office)? On a network you have several classes of devices: 1. Devices that frequently need to run an server or peer to peer connection that requires outside access (ie: servers, some computers, tablets, phones, gaming consoles, VOIP phones, etc) 2. Devices which might need to be accessible from the outside in a few cases, but generally speaking have no need to be accessible from the outside (ie: most computers 3. Devices which generally have no need to be accessible from the outside (ie: NAS, network printer, security camera, security system, phone system, etc) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)
Sorry for the earlier email, apparently I accidentally hit send rather than save... - Original Message - On Wednesday, July 16, 2014 2:10:53 PM Gui Iribarren g...@altermundi.net wrote: Benjamin is giving some great examples of real-world scenarios where an default-open firewall simplifies administration, and where a default-closed firewall would be not only unnecessary (provides no benefits), but would indeed complicate setting up things. On the other hand, how many devices realistically need to be accessible from the outside by default in a typical setting (ie: in a home/small office)? On a network you have several classes of devices: 1. Devices that frequently need to run an server or peer to peer connection that requires outside access (ie: servers, some computers VOIP phones, etc) 2. Devices which might need to be accessible from the outside in a few cases, but generally speaking have no need to be accessible from the outside (ie: most computers, media players, phones, tablets, gaming consoles, etc) 3. Devices which have no need to be accessible from the outside except in special circumstances and in fact could be a security risk if exposed to the outside world (ie: NAS, network printer, security camera, security system, phone system, etc) On 16/07/14 12:09, Gert Doering wrote: This actually is a somewhat moot arguments. Devices travel today, and while your home network and office network might be behind a firewall, the hotspot you're using while waiting for your train might not be. That I think is the point. The open everything above port 1024 model is a good idea for some systems (ie: hotspots, hotel networks, etc) but in the typical home or office setting, the great majority of the devices have no need to be accessible from the outside and in fact, making them available from the outside creates a security risk if there is any kind of security flaw on the device. IMO, it comes down to trust: Do you trust that the people who made your NAS, blueray player, etc will release patches when exploits are found 3 years down the road? I don't. Do you trust that the people who made the firmware for your networked camera didn't leave any back doors in it to be found down the road (ie: a hardcoded root password, poor security on the webpage, etc)? I don't. Do you trust that Microsoft didn't miss any bugs in the Windows 7 firewall and that none of the software on the computer is leaving a port open? I certainly don't. I would venture to guess that 95% (or more) of the people who install OpenWRT are quite capable of opening ports in a firewall. == Perhaps a solution would be to do the following: 1. Have a global setting for the firewall that has three options: 1a. Default open from port 0 on up 1b. Default open from port 1024 on up 1c. Default closed 2. Add/change LUCI interface for opening ports. Add a hyperlink or button next to the list of computers on the network that allows setting the following options (for each computer) in the OpenWRT firewall: 2a. Default to open from port 0 on up 2b. Default open from port 1024 on up 2c. Open port X (or service X) for this computer Factory default could be 1c for the time being (to be consistent with the current IPv4 settings) and it could be re-evaluated down the road as things change. == My $0.02. Aaron Z ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)
- Original Message - On Wednesday, July 16, 2014 2:10:53 PM Gui Iribarren g...@altermundi.net wrote: Benjamin is giving some great examples of real-world scenarios where an default-open firewall simplifies administration, and where a default-closed firewall would be not only unnecessary (provides no benefits), but would indeed complicate setting up things. There have been many good arguments posted on this subject and to throw my opinion in, it a question of effort and expectations. I think everyone can agree that: -It takes equal effort to turn a firewall on, as it does to turn one off. -It takes equal effort to create a specific block list, as it does to create a specific allow list. -UPnP is not included by default for either the ipv4 or ipv6 stacks. I would also go further to suggest that: -Consistency is good, even if it consistent for superficial reasons. We know that, for NAT reasons, that the ipv4 stack by default blocks incoming connections: -Because it doesn't know by default where to route them. -ipv4 end-points have been traditionally insecure. The two ways to get around this (for gaming, etc): -Through setting firewall rules to route the traffic to an end-point. -Through the use of UPnP (which is used by most games to host, and gaming consoles). With the adoption of ipv6 there is the opportunity to change this behaviour such that instead of incoming traffic being restricted for technical reasons, that incoming traffic is routed to the correct end-point. However, that begs the questions: A) Is that consistent with what people would expect? B) Are ipv6 end-points secure by design? In regards to A, from the mindset of a non-technical user, would wager that the answer is 'no'. Even though there is a change in technology with ipv6, the ipv6 technology fulfills the same role as ipv4 and this could be seen as opposing direction between the two. This would likely catch many end-users by surprize unless they read the small print regarding this. As for B, given my view of software development, applications, networks, etc (I've been in the IT business for over 25 years now) I would wager that 80% of applications are secure, and that the 0ther 20% make the potential change in policy very risky. IMO, which others may disagree with, would be to include UPnP by default which would/should resolve most of the hosting issues. Thanks. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)
- 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 : On Mon, Jul 14, 2014 at 02:38:16PM +0200, Steven Barth wrote: Hi Baptiste, in general our current firewalling approach is to keep defaults for IPv4 and IPv6 relatively close (not considering NAT here of course). Could you detail the reasoning behind this approach? Don't confuse the user? 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). That is the whole point in using a firewall is it not? To keep people out of where they shouldn't be. 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. 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. What gets blocked are unsolicited connections from the outside which are generally unneeded (and can be a security risk) unless one is running a server (in which case, the users should know how to open ports on their firewall). Aaron Z ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)
Fully agree with Aaron's comments below. Regards, Fernando On 15/07/2014 16:45, Aaron Z wrote: - 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 : On Mon, Jul 14, 2014 at 02:38:16PM +0200, Steven Barth wrote: Hi Baptiste, in general our current firewalling approach is to keep defaults for IPv4 and IPv6 relatively close (not considering NAT here of course). Could you detail the reasoning behind this approach? Don't confuse the user? 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). That is the whole point in using a firewall is it not? To keep people out of where they shouldn't be. 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. 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. What gets blocked are unsolicited connections from the outside which are generally unneeded (and can be a security risk) unless one is running a server (in which case, the users should know how to open ports on their firewall). Aaron Z ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)
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
Re: [OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)
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
[OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)
On Mon, Jul 14, 2014 at 11:12:01AM +0200, John Crispin wrote: The OpenWrt developers are proud to announce the first release candidate of OpenWrt Barrier Breaker. Excellent news, thanks! * Native IPv6-support - RA DHCPv6+PD client and server - Local prefix allocation source-restricted routes (multihoming) * Extended IPv6-support - Added DS-Lite support and improved 6to4, 6in4 and 6rd-support - Experimental support for Lightweight 4over6, MAP-E and MAP-T - Draft-support for self-managing home networks (HNCP) The default configuration of the IPv6 firewall seems to take the mostly closed approach. That is, it doesn't forward any inbound packets (except for ICMPv6 and, of course, return traffic). This is a perfectly valid approach, although one could argue about end-to-end reachability. But without a firewall control protocol such as PCP [1], applications cannot be reached from the outside (which might be desirable for P2P, VoIP, gaming, etc). Interesting, people from Swisscom take the opposite approach, and deployed a mostly open IPv6 firewall in their CPEs: http://tools.ietf.org/html/draft-ietf-v6ops-balanced-ipv6-security-01 http://www.internetsociety.org/deploy360/blog/2014/06/video-balancing-end-user-ipv6-security-and-end-to-end-connectivity-ripe-68/ Which brings me to the question: is supporting PCP [1] a planned feature? Not that many clients support it yet, but well... It seems that MiniUPnPd has recently gained support for PCP: http://www.ietf.org/proceedings/87/slides/slides-87-pcp-13.pdf But since server-side PCP is closely related to the firewall, it probably needs some proper integration for OpenWRT (unless this is already implemented?) Thanks, Baptiste [1] http://en.wikipedia.org/wiki/Port_Control_Protocol pgp_4pZJKrYEj.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)
Hi Baptiste, in general our current firewalling approach is to keep defaults for IPv4 and IPv6 relatively close (not considering NAT here of course). 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. However the packaged version of miniupnpd does indeed support both UPNP WANIPv6FirewallControl and PCP. One of my colleague recently ran a test with PCP and said miniupnpd and it works fine. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)
Hi Steven, On Mon, Jul 14, 2014 at 02:38:16PM +0200, Steven Barth wrote: Hi Baptiste, in general our current firewalling approach is to keep defaults for IPv4 and IPv6 relatively close (not considering NAT here of course). Could you detail the reasoning behind this approach? Don't confuse the user? 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. 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). However the packaged version of miniupnpd does indeed support both UPNP WANIPv6FirewallControl and PCP. One of my colleague recently ran a test with PCP and said miniupnpd and it works fine. Good news, thanks! PCP doesn't show up in the config file, so I guess PCP is controlled by the NAT-PMP-related options. Cheers, Steven Thank you, Baptiste pgpLyuqgFHLrc.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] IPv6 firewall and Port Control Protocol (Was: Barrier Breaker 14.07-rc1)
Hi everyone, Le lundi 14 juillet 2014 à 22:17 +0900, Baptiste Jonglez a écrit : On Mon, Jul 14, 2014 at 02:38:16PM +0200, Steven Barth wrote: Hi Baptiste, in general our current firewalling approach is to keep defaults for IPv4 and IPv6 relatively close (not considering NAT here of course). Could you detail the reasoning behind this approach? Don't confuse the user? 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. 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. Regards, -- benjamin ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
