To be honest I dont see why UPNP should ever be enabled on the WAN side on a home router, yes it can be needed on the local lan side. Does sound like your router f/w has fixed this. I do also wonder if your ZyXEL in bridge mode has something to do with this? I wonder what you might see if the ASUS was running as a single box?

To be honest I dont see why UPNP should ever be enabled on the WAN side on a home router, yes it can be needed on the local lan side. Does sound like your router f/w has fixed this. I do also wonder if your ZyXEL in bridge mode has something to do with this? I wonder what you might see if the ASUS was running as a single box?

Stuart

Good point it had ocurred to me that many router may still be running with old firmware and not behind a bridge modem router. I am happy that stealth is indicated as I have two spare DSL-N55U's just in case the original goes pop wasn't looking forward to replacing them although I do have a ZyXel 3925 which would do the trick.

Ronski implications are is any port forwarding has to be done manual, something I have always done anyway.

Agreed, I also always disable UPnP over port forwarding concerns. If port forwarding were needed I’d want know about it, and configure it manually. Actually though I go further... if an application,game or gadget requires port forwarding, I simply refuse to use that application,game or gadget. There may come a day when I need to give in, but so far so good - no port forwarding at all.

Perfectly happy to use UPNP. No excuse for it to be exposed on WAN side. Presents minimal risk other than that. Plenty of ways for malware or a bad actor to get a bidirectional link without it once on the LAN.

Do you guys that disable it as a matter of routine have static rules for your packet filtering or do you use a stateful firewall?

Perfectly happy to use UPNP. No excuse for it to be exposed on WAN side. Presents minimal risk other than that. Plenty of ways for malware or a bad actor to get a bidirectional link without it once on the LAN.

Do you guys that disable it as a matter of routine have static rules for your packet filtering or do you use a stateful firewall?

My take is...

All software has bugs and vulnerabilities, and that includes the protocol parsing software that processes incoming traffic. Often, that parsing is performed in OS kernel, making that software especially vulnerable. Maliciously crafted packets could take advantage of such bugs, and get to do very bad things on the destination.

Even without port forwarding it is still possible, of course, to be in receipt of a malicious data packets but generally, you need to have started the conversation. With port forwarding, the bad guys can very precisely target their malicious traffic at a personal level, right through to your OS (or your games console, or webcam, or whatever) anytime they like, just by sending it unsolicited to your IP.

It's not supposed to be exposed on the WAN side. As long as the producers of the device aren't outstandingly incompetent it should be fine.

If the people who write the software are incompetent enough that they have random services listening on the WAN side UPNP is probably the least of the concerns. Unsolicited attacks as you describe require knowledge of the devices on the LAN side anyway. If the gateway is doing its job properly these should not be exposed.

Regardless forwarding any ports at all carries a risk, whether static or dynamic.

That is why I'm fine with UPNP. It's a very useful application that reduces the need for manual configuration for each device behind the NAT.

Obviously if you're the kind of person that has static IPs or IP reservations for every device on your network it's a natural extension of that, but working with this stuff I try and keep my configuration at home to a minimum of complexity, which means UPNP gets to play. So far I've not noted any compromise

Incidentally I do appreciate what you're saying about UPNP.

Quote

MiniUPnP < 1.4 Multiple Vulnerabilities

Description

According to its banner, the version of MiniUPnP running on the remote host is prior to 1.4. It is, therefore, affected by the following vulnerabilities :

- An out-of-bounds read error exists in the ProcessSSDPRequest() function in file minissdp.c that allows an unauthenticated, remote attacker to cause a denial of service condition via a specially crafted M-SEARCH request. (CVE-2013-0229)

- A stack-based buffer overflow condition exists in the ExecuteSoapAction() function in the SOAPAction handler, due to improper validation of user-supplied input. An unauthenticated, remote attacker can exploit this, via a long quoted method, to cause a denial of service condition or the execution of arbitrary code.(CVE-2013-0230)