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

Fri Jul 18 00:18:43 EDT 2014

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"
>>>> <gui at 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 at lists.openwrt.org
>>>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>>>>
>>> _______________________________________________
>>> openwrt-devel mailing list
>>> openwrt-devel at lists.openwrt.org
>>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>> _______________________________________________
>> openwrt-devel mailing list
>> openwrt-devel at lists.openwrt.org
>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel