Hacker News Reader

Comment by tjohns | Hacker News Reader

Between IoT and the deployment of IPv6 (meaning no more automatic NAT firewalling), I feel like we need to take a fresh look at how home routers are designed.

I'd love to see products that provide a user-friendly way to help me audit what my network is doing, and create firewall rules for different classes of devices. For example, if you're running a DVR server, the camera mentioned in this article probably shouldn't have been granted Internet access.

While some routers have basic firewall support, it's really rudimentary and nowhere near sufficient when you have several dozen (or more) relatively unknown devices on your network. And definitely not user-friendly enough for most home users.

View on HN

> help me audit what my network is doing, and create firewall rules

We need be a better solution than this! I already dread having to configure and tweak firewalls every time I add a new device or install a new application.

Even with the most user-friendly firewall in the world, we'll still end up in a world where 99% of users don't do anything and have no security/privacy. And the 1% of technical users will end up breaking basic functionality because they blocked something that the manufacturer of the device or app deemed to be an essential connection.

Thinking out of the box for a moment: If you install a camera, suppose your router automatically encrypted everything coming out of the camera such that it could only be decrypted on your smartphone, or whatever you're using to view the feed from your camera. The encryption, decryption, and keys are completely independent of and outside of the control of camera manufacturer. The encryption is unavoidable; even if they get a secret feed of the video, they cannot decrypt it.

Instead of the router, perhaps it's the device driver that does the encryption. The point is that this is something automatically done whenever you plug in a camera and which the camera manufacturer cannot subvert. (This idea is for cameras and such. For other kinds of IoT devices, this particular idea may or may not help.)

> no more automatic NAT firewalling

NAT != firewall

IPv6 doesn't take away your stateful firewall, and NAT isn't providing ANY security. Your private IP addresses are betrayed all the time by your browser (and TCP option headers). NAT has done an incredible amount of damage to the internet; it prevented the development of true peer-to-peer software and forced everything to centralize.

The solution - even for IoT in the few places IoT isn't a surveillance scam - is to remove NAT by using IPv6.

I don't think anyone was claiming what you seem to be arguing against; the point was merely that even the accidental and minimal security brought on by being unable to externally address internal networks is going away with IPv6. It was never "real" security, but it did make it materially harder to breach into someone's network.

Of course it's also going away with all the IoT things actively reaching out, since every external connection made without care is also an avenue for attack. ("Oh, you want your firmware update little camera? Have I got an unsigned blob for you! You're gonna love this update.")

I am a sysadmin who has been slowly preparing for IPv6 as an eventuality, and have read quite a bit on it, though I admit there is much more to learn. That being said, and knowing that the industry says otherwise, I disagree on the seemingly accepted state that we should get rid of nat for ipv6, for a few key reasons.

1. Yes, browsers and other things will leak your private ip space sometimes, but nat does indeed provide a level of security simply due to complications in routing issues for attackers. Its certainly only a base layer, but it does help.

2. In many situations, we dont want devices on the internet at all, and on private only networks. This is doable with site private, but that brings me to

3. There is a lack of clearly communicated best practices for the industry. To the pont that adoption is almost nill. I recently had a private network setup via ATT, and they said I was the first customer on that network type to request ipv6...

4. Knowing how heavily the NSA was involved in ipv6 (in particular ipv6 ipsec), I have my concerns about the protocol itself, albiet as of yet unverified doubts. The corruption of NIST committees is a very serious thing to me.

5. As the admin, I want to be able to see non encrypted traffic and metdata traversing my exit points. I am having a harder and harder time diagnosing IPv6 because of how often it wants to tunnel to some ipv4 address that I dont trust (read: microsoft).

I know that all these points are fairly weak and suspect to criticism, but what gets me is that I dont hear this discussion. Instead I just hear either how ipv6 is god and you should embrace its loving arms, or I see people just sticking their head in the sand who say, I dont like it so Im going to ignore it and hold on to my ipv4 blocks until they make me.

Im open to conversations on the topic, and my list is larger but Im on mobile and late for fixing some ipv4 networking issues .

> 2. In many situations, we dont want devices on the internet at all, and on private only networks. ...

Unique Local Addressing (RFC 4193) solves this problem and requires no coordination with outside parties. The network admin gets to choose the scope of the ULA prefix, so you can trivially make your ULA traverse multiple LANs if you wish. (This addresses your first point, too.)

> 3. There is a lack of clearly communicated best practices for the industry.

Eh? This is the first hit for "IPv6 BCP": https://www.apnic.net/community/ipv6-program/ipv6-bcp

> 4. Knowing how heavily the NSA was involved in ipv6 (in particular ipv6 ipsec)...

Then -uh- don't use IPSec and block IPSec connection establishment attempts at your border firewalls. Or, because implementation of IPSec is -sadly- not a requirement for IPv6 implementers, use an IPv6 implementation that doesn't implement it.

Edit: You are aware that OpenVPN uses TLS for session authentication and IPSec for transport of tunnelled data? :)

> 5. As the admin, I want to be able to see non encrypted traffic and metdata traversing my exit points. I am having a harder and harder time diagnosing IPv6 because of how often it wants to tunnel to some ipv4 address that I dont trust (read: microsoft).

Are you talking about IPv6 over Teredo tunnels? If you are, then get a packet dump and fire up Wireshark... Teredo doesn't encrypt the traffic that it tunnels. If you aren't, and you're talking about something that's wrapping traffic in TLS, then -well- that doesn't have anything to do with IPv6.

4. Knowing how heavily the NSA was involved in [..] ipv6 ipsec, I have my concerns about the protocol itself

That's not an issue against IPv6. The entire ipsec standards were backported to IPv4, by people from the same organizations. There is no reason to assume IPSECv4 is any less tainted.

I knew I was going to get flak for this, butnit has inspired me to dig into it further and I plan to come back with stronger points... Or perhaps Ill realize I was wrong and change my mind. Thanks for all the responses though, I have some reading and thinking to do.

> IPv6 doesn't take away your stateful firewall, and NAT isn't providing ANY security.

That's not really true. By its nature, stateful/dynamic NAT, which is what the majority of the consumer world is using, means internal services aren't exposed to the Internet. Short of layer 7 stateful packet inspection, or some other IDSy type thing, a consumer-focused 'firewall' isn't going to do any better... they have to be generic and fuss-free. Just go back to the early 00s or mid-90s to see the ramifications that exposing ports from Windows machines to the Internet had, then tell me NAT hasn't had a positive security impact.

What I haven't seen in a home router is proper egress filtering. The use of NAT you're talking about just seems like a really blunt version of that.

I think a router with a smartphone based controller could work well - push notifications when your TV wants to connect to the net for the first time or a friend has dropped by and wants to log on to your guest wifi

Except that on a consumer grade router, UPNP is probably turned on with no authentication. Anything that wants to get out, will.

What's the alternative? Consumers want something they plug in, turn on, and forget about.

The alternative is an easy-to-use router summary page that list every network device and controls what it can contact (eg local-only, manufacturer, wide Internet).

Consumers want things that "just work" because they haven't been shown that they can have control. It's really a matter of selling the value proposition of such administration, and making these devices' communications patterns legible to the average consumer.

> "... router summary page ..."

You've lost probably 95% of the mass-market: users who visit their router's setup page either zero times or one time throughout the devices' stay in their home. Users do not want a list of devices or controls or toggles, or text fields to fill in IP addresses. They want to buy their plastic internet box, plug it in, and go download cat videos. You can try to communicate value proposition until you're blue in the face. People want to plug it in and get on with their lives. Trying to convince users of the value of "administering a computer" is fighting a losing battle.

That's why I think a smartphone app with well calibrated alerts would help. People learn pretty quickly how to administer a router when Xbox Live doesn't work properly.

Exactly. It's not so much that people can't figure out tech, it's that they only do so if necessary to accomplish their immediate task, regardless of possible repercussions down the line.

If a user is really that uninvested in their digital life, then why bother thinking about them? After all, nothing can be done.

I heartily disagree with this defeatist figure of "95%" though, and feel it reflects tech feelings of inferiority more than the actual ability and desires of people using technology.

Most people will apply their brain to overcome straightforward problems and most people seem to be concerned about security. Of course this concern comes from mass-media scaremongering, which also misleads them into thinking that centralized entities will protect them. But it still means there's a demand, and the concern-actualization gap should be able to be bridged with sufficiently-accessible administration.

If plugging in a device makes it just work, then a user is likely to forget the step of modifying the ACL. But if going to the router page is a required part of setting up any new device (because they have previously chosen this mode when setting up the router), then it will just become part of their workflow, the same as entering SSID/passphrase.

> Just go back to the early 00s or mid-90s to see the ramifications that exposing ports from Windows machines to the Internet had, then tell me NAT hasn't had a positive security impact.

NAT has had the same _security_ impact that a default REJECT ingress firewall policy would have. (Coincidentally, this is the default firewall policy for non-Enterprise Windows Firewall configurations.)

If you combine default REJECT with a port opening protocol like uPnP, you have a really nice, reasonably secure, self-maintaining border firewall. (Hyperventilation about security issues with particular implementations of uPnP notwithstanding.)

I'm not saying we need NAT, just that without prior need for NAT, perpetuated by ISPs only giving us one IP, I doubt anybody would have any ingress filtering at the border. It's a lot easier just to block ingress to the whole house than it is to ensure a dozen devices are secure against unwanted incoming connections... this problem will present itself with the IoT sooner or later.

> ...just that without the need for NAT, perpetuated by ISPs only giving us one IP, I doubt anybody would have any ingress filtering at the border.

I disagree. Defaults are a powerful thing. If one's router ships with a default REJECT ingress firewall, a non-technical user is not likely to change it.

"NAT isn't providing ANY security" - except for the fact that there's no way for a host outside your NAT to initiate contact with any host inside your NAT. That sounds quite a lot like security. As for "your private addresses are betrayed all the time by your browser", I'm not sure what an internet host is going to do after discovering my IP address is 192.168.something that they couldn't already do.

> except for the fact that there's no way for a host outside your NAT to initiate contact with any host inside your NAT

Not true. Someone on the Internet can mark your router's external IP as the gateway for your internal network range and send packets to your internal devices fine.

(In practice most NAT devices also do firewalling to prevent this, but the two functions are independent)

That's a characterization of a network gateway, not a NAT - there's no reason for a NAT router to accept and gateway packets addressed to its internal network since there's no reason for external hosts to be using those addresses in the first place. I would be astonished to find a NAT which also enabled routing to its private address space for external-origin packets.

You might be astonished to find such a NAT gateway without the functionality you describe, but what you're describing is a firewall.

I would not describe having two different routing domains as a firewall. It's not a fence set up by a firewall that only lets correct packets through. It's a gaping chasm that only the NAT process crosses; packets are transformed as they cross and only some packets are possible to transform.

In general, if you're intentionally dropping packets it's a firewall. NAT is just an address translator.

> only the NAT process crosses

Nope, a router that doesn't have a firewall but supports NAT will route a packet if it has the proper destination address. That is, if a packet is received that has a destination address of e.g. 192.156.1.2, it will be routed onto the LAN. However, this is a very rare configuration, as most routers (including ~all home routers) also include a firewall that does packet filtering.

>will route a packet if it has the proper destination address

Iff the ports are logically connected. Nothing forces routing to be global.

If they're separate, it doesn't have to intentionally drop packets. An example configuration: You're NATing 15.x.x.x to 10.x.x.x, with a 1:1 mapping. It's wide open. But it simply doesn't understand what to do with a packet addressed to 10.x.x.x on the external port. No destinations in the external port routing table contain 10.x.x.x, so it gives up.

Filtering packets that don't match a criteria (such as a destination port) is done by a firewall, in addition to the NAT. These are typically used together, such as in the "full-cone" situation you described.

Yes, I'm making a pedantic argument about terminology, but it's an important one because IPv6 means we can remove just the NAT part - all of the other filtering/etc features can remain. The goal is to make all devices addressable globally[1], which some people assume is a change in security. That isn't a correct assumption, as an IPv6 router (with a stateful firewall) should drop the same types of packets as their current IPv4-with-NAT router.

[1] NAT badly damages the network by imposing an imprimatur[2] on the hosts behind the NAT.

[2] https://www.fourmilab.ch/documents/digital-imprimatur/

But filtering packets because you don't have a routing destination is not done by a firewall. If I send a packet destined for 253.7.7.7 to a pure router, it will get dropped.

The routing engine on the outside port has a destination for 15.x.x.x. Those packets go into the NAT engine. It does not have a destination for 10.x.x.x. Those packets suffer the same fate they would if you gave them to any router in the middle of the internet. Nowhere to send, abort.

What does that router do with packets a local program (running on the router) sends to 10.x.x.x? By default it would likely do the same with an external packet addressed to 10.x.x.x, and that would not be to drop the packet.

When I've seen a "NAT" box configuration it's literally been two iptables rules: one to do NAT, and one to default drop packets from outside.

When you say "someone on the Internet", you mean "someone who has a device on the same network segment as your router's external connection", right?

While that is still a serious risk, IP packets support a source routing header option header.

http://www.networksorcery.com/enp/protocol/ip/option003.htm

http://www.networksorcery.com/enp/protocol/ip/option009.htm

I have no idea how well supported these headers are on the modern internet, but they are still part of the protocol.

This line stood out to me (especially after reading the protocol explanation points from a manufacturer just above): "I’m baffled as to why such a well-known brand as Foscam would enable P2P communications on a product that is primarily used to monitor and secure homes and offices."

Well the first answer that came to mind for me was NAT. There's a reason you'll see both botnets and (commodity, cheap) security cameras generating P2P traffic: NAT.

NAT+IPV4 is a problem that adds complexity and less usability at the cost of security. It's a clear bolt-on design that consumers have tolerated probably for longer than we should have. I think ISPs have mostly created this problem in being slow to adopt something else.

I would also agree that we have a basic usability problem in home routers and pretty much the entire concept of firewalls when it comes to normal users. How do you explain egress traffic filtering to someone who just wants to control their thermostat from their phone and stuff?

The Turris Omnia router project has the Majordomo component, which sounds somewhat similar to what you have in mind.

Even if we get a user-friendly way to authorize outbound network access, users will still just click "Allow" and "Accept" to make the notifications go away.

I am wholeheartedly open to maintaining a whitelist for all of what's trying to reach out of my home network, but the sheer magnitude of domains being queried makes it unfeasible.

Reply on news.ycombinator.com