by PaulKeeble
1 subcomments
- What I wish routers did was make UPNP a pending request something I could go and approve. Limit it to the device making it, let it switch it on and off but fundamentally I want to control if I want that hole made or not. OpenWRT comes without UPNP in its base images for a reason, its a major security hole. But I think there is a middle ground here where UPNP isn't just no or yes but rather authorised which will reduce the problem and provide autoconfiguration but without automated firewall holes.
by petiepooo
2 subcomments
- People still use UPnP? That's the first thing I disable on a new router.
by jasongill
1 subcomments
- Ignoring concerns about the security of UPnP, and the fact that this is somewhat of a "solved" problem considering there are things like libupnp and miniupnpc, I am wondering if this is really the cleanest way to solve the problem in C++ with Qt?
I'm most curious about the fact that this program has ~30,000 lines of included headers to simply generate a static string (the XML output).
Obviously if you were generating large XML payloads repeatedly, then including a dependency would be a good idea, but this implementation is using "inja.hpp" which in turn requires "json.hpp" to output what is effectively a concatenated string.
Why not just use Qt's built in QStringLiteral and feed it the (short) bit of XML to it along with your 4 variables, similar to a sprintf?
- I'm torn on UPnP in general. If there's something malicious running on my network that could send a UPnP request to my router to open a port, then it could also open a persistent connection to some command-and-control server somewhere and achieve a similar result (and I'd possibly even be less likely to notice this). Sure, it's more taxing on a central server to have to maintain all these connections than to be able to make short-lived outgoing connections at will, but I don't think that's that much of a concern these days.
Having said that, I still disable UPnP on my routers if it's enabled by default... just feels safer that way. Even if the intended use of the port forward is legitimate, other non-legitimate folks on the public internet could presumably use that port forward as well to exploit a vulnerability in the software in my network that's on the other end of that port.
I'm also not sure how relevant UPnP is these days, with many people on the internet behind CGNAT, not even getting a publicly-addressable IPv4 at their home router. I suppose many of those people have routable IPv6 addresses, though, assuming UPnP port forwarding supports IPv6.
- Not the topic of the article, but security of opening anything up in my network is always super concerning. I really want a zero-advertise way to find and connect to my network. So, for instance, there could be a trusted server that I advertise my IP to so that I can find it when I am off my local network. Not dynamic dns, something that requires me to send them a key so that only my devices can get the IP. Then, some form of port knocking could hide the connection port actually used like I send a sequence of knocks based on my key encoding the port I will use to actually try to connect my VPN so that I can rotate that around. A bit overkill but I am paranoid now. It is a jungle out there and security is hard for experts much less people like me.
- Great, but what is the license? The GitHub has it as none.
- For anyone using Windows I made a simple command line tool: https://community.chocolatey.org/packages/portopen
Source: https://github.com/lostmsu/PortForwarding/blob/lost/PortOpen... (uses a custom fork of Mono.Nat).
- -
- Who is stupid enough to use Qt in 2026 when you have React Native?
Hacker News