NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
RBR850 Massive Security Fail - Many ports responding to requests
Just bought the thing, using the latest firmware V3.2.9.2_1.2.4. Did not Disable Port Scan and DoS Protection. WAN ports respond to unsollicited requests, instead of ignoring. They do respond clo...
Added a screenshot just in case. Firmware is obviously far from being ready for prime time.
Thanks.
This still seems to be ongoing.
I even created a fake default dmz (ip address that is in my subnet but not assigned to any device on my lan) to act as a black hole; that actually stopped a lot of the ports from just showing closed but present into stealth, but I can't block all. Invariably a "common port scan" shows 1025-1030 inclusive responding as closed.
Horribly, if I don't do the dmz trick, ALL common ports except ping, http (80), and upnp (5000) show as closed with those 3 as stealthed.
I thought maybe this is my modem or something; but the Orbi router's logs show that it was the one accepting the request to forward it to a non-existent device, but only on the ports that are not showing stealthed in the scan (i.e. if it logs the forwarding of the port, it seems to also acknowledge back to the remote host that it exists as a host); e.g.:
[LAN access from remote] from 4.79.142.206 port 35873 to 192.168.1.252 port 1025 Sunday, May 17,2020 07:58:53 [LAN access from remote] from 4.79.142.206 port 35873 to 192.168.1.252 port 1026 Sunday, May 17,2020 07:58:53 [LAN access from remote] from 4.79.142.206 port 35873 to 192.168.1.252 port 1027 Sunday, May 17,2020 07:58:52 [LAN access from remote] from 4.79.142.206 port 35873 to 192.168.1.252 port 1028 Sunday, May 17,2020 07:58:52 [LAN access from remote] from 4.79.142.206 port 35873 to 192.168.1.252 port 1029 Sunday, May 17,2020 07:58:52 [LAN access from remote] from 4.79.142.206 port 35873 to 192.168.1.252 port 1030 Sunday, May 17,2020 07:58:52 [LAN access from remote] from 4.79.142.206 port 35873 to 192.168.1.252 port 1025 Sunday, May 17,2020 07:58:52 [LAN access from remote] from 4.79.142.206 port 35873 to 192.168.1.252 port 1026 Sunday, May 17,2020 07:58:52 [LAN access from remote] from 4.79.142.206 port 35873 to 192.168.1.252 port 1027 Sunday, May 17,2020 07:58:52 [LAN access from remote] from 4.79.142.206 port 35873 to 192.168.1.252 port 1028 Sunday, May 17,2020 07:58:52
There's no device on my network with .252 as the IP, and none showing in the attached devices list in the .2xx range at all. Without the faux dmz host many more ports seem to be exposed but without any logging.
I have:
- NOT turned off the port scan / DDoS prevention (i.e. the box to disable it is unchecked as default)
- left the disable wan pings option turned on (i.e. the box is checked as default)
- tried explicitly forwarding ranges of ports to a black hole, e.g. and including 1025-1030, to no avail; generally it just means other ports (including 5000!) start responding to the GRC Shields Up! common scan as being "closed" (but present) instead.
- Yes, this thing forwards requests to the internal LAN without sanitizing them. Really basic security stuff, the proper behavior should be to check whether a session has been established by a LAN device on that port before accepting random packets from random IPs on random ports, but for some reason, the router tries to process them anyway (and of course it leads to a closed port response, which, I’m sorry, isn’t an acceptable behavior in 2020). Interestingly, the previous Orbi generation didn’t behave that way.
I tried to disclose the issue to netgear in a responsible way. They did not acknowledge. I eventually bought a separate router to shield the Orbi, and put it in AP mode. That fixed the firewall issues, but opened another can of worms, as Orbi has major DHCP and backhaul issues when running in AP mode.
So I moved on. Can you post your Shields up results with Respond to WAN Ping DISABLE and Port Scan and DDOS Protection Enabled and the Orbi 850 in router mode directy connected to your ISP modem. No DMZ configurations. Be sure only 1 wired PC is connected to the RBR, turn OFF ALL other wired and wireless devices including ALL RBS.
tantrum wrote:This still seems to be ongoing.
I even created a fake default dmz (ip address that is in my subnet but not assigned to any device on my lan) to act as a black hole; that actually stopped a lot of the ports from just showing closed but present into stealth, but I can't block all. Invariably a "common port scan" shows 1025-1030 inclusive responding as closed.
Horribly, if I don't do the dmz trick, ALL common ports except ping, http (80), and upnp (5000) show as closed with those 3 as stealthed.
I thought maybe this is my modem or something; but the Orbi router's logs show that it was the one accepting the request to forward it to a non-existent device, but only on the ports that are not showing stealthed in the scan (i.e. if it logs the forwarding of the port, it seems to also acknowledge back to the remote host that it exists as a host); e.g.:
[LAN access from remote] from 4.79.142.206 port 35873 to 192.168.1.252 port 1025 Sunday, May 17,2020 07:58:53 [LAN access from remote] from 4.79.142.206 port 35873 to 192.168.1.252 port 1026 Sunday, May 17,2020 07:58:53 [LAN access from remote] from 4.79.142.206 port 35873 to 192.168.1.252 port 1027 Sunday, May 17,2020 07:58:52 [LAN access from remote] from 4.79.142.206 port 35873 to 192.168.1.252 port 1028 Sunday, May 17,2020 07:58:52 [LAN access from remote] from 4.79.142.206 port 35873 to 192.168.1.252 port 1029 Sunday, May 17,2020 07:58:52 [LAN access from remote] from 4.79.142.206 port 35873 to 192.168.1.252 port 1030 Sunday, May 17,2020 07:58:52 [LAN access from remote] from 4.79.142.206 port 35873 to 192.168.1.252 port 1025 Sunday, May 17,2020 07:58:52 [LAN access from remote] from 4.79.142.206 port 35873 to 192.168.1.252 port 1026 Sunday, May 17,2020 07:58:52 [LAN access from remote] from 4.79.142.206 port 35873 to 192.168.1.252 port 1027 Sunday, May 17,2020 07:58:52 [LAN access from remote] from 4.79.142.206 port 35873 to 192.168.1.252 port 1028 Sunday, May 17,2020 07:58:52
There's no device on my network with .252 as the IP, and none showing in the attached devices list in the .2xx range at all. Without the faux dmz host many more ports seem to be exposed but without any logging.
I have:
- NOT turned off the port scan / DDoS prevention (i.e. the box to disable it is unchecked as default)
- left the disable wan pings option turned on (i.e. the box is checked as default)
- tried explicitly forwarding ranges of ports to a black hole, e.g. and including 1025-1030, to no avail; generally it just means other ports (including 5000!) start responding to the GRC Shields Up! common scan as being "closed" (but present) instead.
Ok, I tested mine. RBR850 in router mode behind a host router in the host routers DMZ to be sure the host router isn't interferring.
uPnP test passes:
I also see ports open and stealthed:
----------------------------------------------------------------------
GRC Port Authority Report created on UTC: 2020-05-17 at 18:56:05
Results from scan of ports: 0-1055
3 Ports Open
1046 Ports Closed
7 Ports Stealth
---------------------
1056 Ports TestedPorts found to be OPEN were: 80, 443, 554
Ports found to be STEALTH were: 53, 135, 136, 137, 138, 139, 445
Other than what is listed above, all ports are CLOSED.
TruStealth: FAILED - NOT all tested ports were STEALTH,
- NO unsolicited packets were received,
- NO Ping reply (ICMP Echo) was received.----------------------------------------------------------------------
I see an earlier test from January is a bit different:
I'm going to have to restest this, I think the test reports on what is first NAT processor, so either the gateway modem if there is a router built in there or at the 1st NAT router after a modem with out a built in router. I'm getting same results with the host router that my RBR850 is connected too so this test is not valid:
I'll try and find some time to retest this again when I can kick everyone off line for a few minutes to test the RBR directly with my modem.
So be sure when your testing the RBR, be sure it's connected to a modem only source with no NAT and be sure ALL devices are disconnected from the RBR including RBS. Change the SSID name temporarily to something else that your devices won't connect too. Once testing is done, change the SSID name back. Also be sure to close any and ALL back ground running apps on your test PC aswell as these apps can have open ports giving false positives in the test.