Without UPnP, you specifically have to configure your NAT for this...
Without UPnP, you specifically have to configure your NAT for this...
While I realize that configuring nftables/iptables is beyond most folks, there are many firewalls out there that have a GUI/webui which makes this dead simple.
Not sure why this should be an issue in 2021, except for users' trained-in helplessness.
This phrase is a thing of nightmares now. Stay tuned for a really scary Haunted House full of users trained in helplessness...coming Halloween 2021.
Kids hosting games on random ports (terraria, etc.) benefit from UPnP. I'd rather enable it than manually enter firewall rules for each game or give them admin access to the firewall.
UPnP is only an additional risk if you have malware inside your network already and then it mostly allows malware to host services in a simpler way, but capable malware will be able to use TCP hole punching to establish arbitrary connections between infected networks.
I'm not sure where you get that idea. Once a hole is poked (depending on the perimeter device/software in use), it stays poked and you've expanded your attack surface.
I make sure that there's no dynamically defined external access to my network. Can you guarantee that no software in use on your network is free of vulnerabilities? I'm not talking about malware here, just your run-of-the-mill software bugs.
If you think the answer is no, then why don't you share your network details with us and let's have a go? Then we'll see how much of an extra risk upnp might be.
What's that? You'd prefer not to do so? If there's no risk, then it shouldn't be a problem, right?
My suggestion is (obviously, I hope) an idle one and more intended as food for thought.
>Kids hosting games on random ports (terraria, etc.) benefit from UPnP. I'd rather enable it than manually enter firewall rules for each game or give them admin access to the firewall.
That may be a valid use case for you. However, claiming that it doesn't increase your attack surface/risk profile doesn't magically make it so.
I'm not telling you what you should or shouldn't do, but I do disagree with your rationalizations about why allowing upnp to expose your perimeter doesn't increase your risk profile.
The cheap and fast attacks are DDoS and they're trivial to aim at a cable modem. Avoiding becoming a target is at least 50% of security posture. There were already 4286 ssh login attempts today so I don't really need more attempts than the automated botnet scans provide.
It's a risk/convenience tradeoff. I could probably package up a vpn.exe and force the kids' friends to run it before playing games, or force them to host games remotely. It's just not worth it.
I'm also reasonably sure that there are plenty of 0-days in all networks, given their relatively frequent discovery. So, again, don't be more of a target than necessary, and keep offline backups current and tested.
Once that happens, there will be government action. Not before.
Meanwhile the top agencies distributing IPv4 blocks have ran out of them a decade ago. Recently it was the time for a lower level agency to run out - for Europe.
There's a lot of things that people don't care about until it's too late. Governments are supposed to be able to plan decades in advance. And they do, for things like digital TV. (And I already gave an example of governments acting to push IPv6.)
CGNAT is causing issues in that some protocols simply don't work properly through them. IPv6 also allows for simpler networking, since you don't have to add the extra abstraction layer that is NAT.
We need something that increases consumer demand for IPv6 if we wantbthis to be dealt with now.
Wouldn't making STUN work be a better alternative?
And TURN is one of those relays.
(I host a STUN and TURN relay myself, because I had to for my personal VoIP server for enough people to be able to connect on it. Downside is more use of bandwidth.)
edit: replaced STUN with TURN where appropriate, I did confuse both as they were provided as a single package.
What's also true, and what I think the GP was trying to get at, is that STUN requires an external coordination server. UPnP (I think—I am far less familiar with it) does not, because in UPnP you're negotiating the holepunching with the local router directly, whereas STUN is sort of using a loophole.
(and it turns out that the server software that I use implements TURN and STUN in the same daemon)