Hi everyone. Ive run into a conundrum - a fresh OpenWrt install with limited packages that shouldnt have UPnP functionality shows a port offering it. All I have are Statistics, MWAN3, SQM, Custom Commands and their dependencies.
Im using the ShieldsUP! UPnP Internet Exposure Test:
This Internet probe sends up to ten (10) UPnP Simple Service Discovery Protocol (SSDP) M-SEARCH UDP packets, one every half-second, to our visitor's current IPv4 address (xxx.xxx.xxx.xxx) in an attempt to solicit a response from any publicly exposed and listening UPnP SSDP service.
Any idea what could be doing this? A device in my home?
My firewall has standard rules. I do have five Windows machines with network discovery enabled which I believe turns on UPnP. Network discovery is also enabled on my controller-only Unifi WLAN. I know those things can do whatever they like...
This site is testing by probing udp/137 and udp/1900. Even if you have reject as wan zone policy, it will still report as closed. The question is: do you have anything like this listening? netstat -lnp | grep 137; netstat -lnp | grep 1900
Ive installed grep, however when i run this command nothing happens. Like it has run and done something, but theres no grep...
What is the powershell equivalent? If i replace grep with select-string nothing happens either, I just get a display of the available netstat quantifiers. Dont see -l in there at all.
Well, this is useful in that it shows your router is not running any services on the ports you are concerned about.
We can take a look at your firewall if you want.
Please copy the output of the following commands and post it here using the "Preformatted text </> " button:
Remember to redact passwords, MAC addresses and any public IP addresses you may have:
There is nothing in the firewall that could allow those ports to be open/exposed. And there is nothing on the router that runs services with those ports. So you probably have a false positive on the port scan.
You can run a scan with your phone (on a cellular connection, not your WiFi) using a port scanner app and pointing at your wan ip. See what that reveals.
Running nmap from a VPN tunnel machine gives me this:
Host is up.
Not shown: 1 filtered tcp port (no-response)
Some closed ports may be reported as filtered due to --defeat-rst-ratelimit
PORT STATE SERVICE
55295/udp open|filtered unknown
Nmap done: 1 IP address (1 host up) scanned in 4.19 seconds
One other thing, which I was going to start a new topic about - I have a torrent client that reports incoming connections on a machine that should only have outgoing access. The client (qbittorent) has UPnP disabled and the firewall has no forward for its port. Its not the port we are talking about.
To be absolutely sure about what is open/exposed on your wan, you should not be using any VPNs that are associated with your home network, and you should not be connected to your wifi at all. Run the scan from a mobile phone on cellular using a port scanner app and pointing at your WAN IP.
I'm not sue what 55295 is, but it could certainly be a related session that was opened by a service on your network.
Im using a windows VPN app on a single PC. The tunnel is not configured for port forwarding. It should not have any effect on others in the network... I thought. Hmm.
Ive run scans over cellular, they report that the port is closed. I cant find a directed UPnP scan like the one ShieldsUP uses though. Is there a nmap command that can do this?
ShieldsUP can cause false positives and is not always the best way of scanning. You don't have upnp installed/running, so you don't have to worry about "directed upnp scan" things -- it's really just ports. If you do a scan of the full range of ports with nmap or a proper port scanner on your phone, you should be covering everything.
Thank you, very informative for a newbie. I will take your assertion as given, though a read of this tells me that I probably shouldnt discount what im seeing.
Maybe its some cache or cookie issue with grc.com... i just hope im using the right app. And its not related to the torrent client getting incoming connections.
Edit:
Hmm. It seems that all UDP ports are found by nmap to be "open|filtered". How can this be?
If you've run a port scan from your own device (i.e. phone) on a remote network (i.e. cellular or any network that's not the one you're testing) against your network's WAN IP, you've basically done the same thing as any of the port scan websites would do... but you're doing it in a way that is generally more accurate.
When scanning from outside, "filtered" ports (in the nmap world) did not get a response, but did not get a reject either. That's fine. It's like calling someone on the phone and not getting an answer... you don't know for sure if they are unable to answer the phone, or if they have just chosen not to answer, but either way, you didn't get to talk to them. They also didn't pick up and say "stop calling me" (which would be the reject). Because UDP is stateless, not getting any response would make it seem open/filtered.
Nmap places ports in this state when it is unable to determine whether a port is open or filtered. This occurs for scan types in which open ports give no response. The lack of response could also mean that a packet filter dropped the probe or any response it elicited. So Nmap does not know for sure whether the port is open or being filtered. The UDP, IP protocol, FIN, NULL, and Xmas scans classify ports this way.
Would a torrent client that hasnt got any ports forwarded report being online if it was connected to a private tracker? Over a random UDP port? Ill probably need to research that.
I'm not exactly sure how torrents function at this level... I've never setup any torrenting and I don't need to worry about them. That said, anytime a network connection is opened, there can be additional sessions that are also opened that are 'established and related' -- for example, when you connect to a website, the responses all fall into the 'established and related' category and will have the ability to send traffic back through the firewall. Obvioulsy this is necessary for a 2-way conversation to occur. It is possible that the torrent networks operate in that same capacity, but I honestly don't know if you need to actively open ports or not.
While torrents may not be the equivalent of opening your firewall entirely, if you're concerned about the potential security implications, you may want to rethink your use of torrents.
