3 ms·

Not having to deal with a NAT is a godsend. I know. I've had a block of publicly routable IPv6 addresses for five or eight years now. I notice that you haven't

Not having to deal with a NAT is a godsend. I know. I've had a block of publicly routable IPv6 addresses for five or eight years now. I notice that you haven't addressed the question I asked in the first comment of mine that you responded to, and again in the second comment. I effectively asked "How is uPnP more insecure than giving the machines on your LAN publicly routable IP addresses?". I've heard people say that uPnP is insecure, but I haven't heard anyone back up that assertion with any information. Even something as weak as anecdata! I asked the question that I did in order to understand the reasoning behind that assertion. > You can close ports with a firewall, by not running services on that port or via NAT. I know which one I'd rather deal with. I don't. I'm curious, which one you'd rather deal with, and why?

voltagex_ 13y ago
> I've heard people say that uPnP is insecure, but I haven't heard anyone back up that assertion with any information. uPnP as a spec doesn't seem to have any security (authentication/authorization) baked in. I'd find you a reference from upnp.org but they're making it difficult to search. As an implementation - have you had a look at any firmware from consumer-level routers recently? Sorry, more anecdata. The only flaw I can remember is http://upnp.org/news/documents/UPnPForum_IGDSecurity_PressRelease_Feb2013.pdf http://upnp.org/news/documents/UPnPForum_IGDSecurity_PressRe... Even with a good implementation, if I can execute code from any device on your network, your phone, your Smart TV/fridge, your PC, then I can forward ports to wherever I like. I know, I've accepted the risk too by keeping uPnP turned on in my network. > You can close ports with a firewall, by not running services on that port or via NAT. I know which one I'd rather deal with. I don't want to deal with any more NAT implementations. It wasn't so long ago that the size of the tables on consumer-grade routers were small enough that BitTorrent et-al would fill the NAT & TCP tables and cause disconnections or router crashes. NAT is a hack and we should be moving away from it.
- simoncion 13y ago
  Thanks for providing some information. I'm aware that uPnP is a large standard. Frankly, the only parts of the spec that I or any software that I run cares about are Service Discovery and IGDP. > ...if I can execute code from any device on your network, your phone, your Smart TV/fridge, your PC, then I can forward ports to wherever I like. Yes and no. The uPnP daemons that I've worked with are based on miniupnp. They all have a setting that only allows a machine to forward ports to itself. Other uPnP daemons might not have such a setting. > I know, I've accepted the risk... What risk? I'll ask yet again. :) How is having an automated port forwarder (even one that will forward any port to any machine on your LAN for any reason) more risky than having a publicly routable IP address assigned to each and every machine on your LAN? If you've already answered this, I apologize for not catching on. > NAT is a hack... So you'd rather manage firewalls and/or running services? That's the path that I like best. EDIT: I've read Rapid7's report on the miniupnp & etc. vulnerabilities that they found. The fun thing there is that they found implementation bugs. The issues that they raised have nothing to do with uPnP itself.

voltagex_ 13y ago

> I've heard people say that uPnP is insecure, but I haven't heard anyone back up that assertion with any information. uPnP as a spec doesn't seem to have any security (authentication/authorization) baked in. I'd find you a reference from upnp.org but they're making it difficult to search. As an implementation - have you had a look at any firmware from consumer-level routers recently? Sorry, more anecdata. The only flaw I can remember is http://upnp.org/news/documents/UPnPForum_IGDSecurity_PressRelease_Feb2013.pdf http://upnp.org/news/documents/UPnPForum_IGDSecurity_PressRe... Even with a good implementation, if I can execute code from any device on your network, your phone, your Smart TV/fridge, your PC, then I can forward ports to wherever I like. I know, I've accepted the risk too by keeping uPnP turned on in my network. > You can close ports with a firewall, by not running services on that port or via NAT. I know which one I'd rather deal with. I don't want to deal with any more NAT implementations. It wasn't so long ago that the size of the tables on consumer-grade routers were small enough that BitTorrent et-al would fill the NAT & TCP tables and cause disconnections or router crashes. NAT is a hack and we should be moving away from it.

simoncion 13y ago
Thanks for providing some information. I'm aware that uPnP is a large standard. Frankly, the only parts of the spec that I or any software that I run cares about are Service Discovery and IGDP. > ...if I can execute code from any device on your network, your phone, your Smart TV/fridge, your PC, then I can forward ports to wherever I like. Yes and no. The uPnP daemons that I've worked with are based on miniupnp. They all have a setting that only allows a machine to forward ports to itself. Other uPnP daemons might not have such a setting. > I know, I've accepted the risk... What risk? I'll ask yet again. :) How is having an automated port forwarder (even one that will forward any port to any machine on your LAN for any reason) more risky than having a publicly routable IP address assigned to each and every machine on your LAN? If you've already answered this, I apologize for not catching on. > NAT is a hack... So you'd rather manage firewalls and/or running services? That's the path that I like best. EDIT: I've read Rapid7's report on the miniupnp & etc. vulnerabilities that they found. The fun thing there is that they found implementation bugs. The issues that they raised have nothing to do with uPnP itself.