RBR850 Massive Security Fail - Many ports responding to requests

[warpdag]

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 closed, but still, the safe behavior should be no response at all, i.e. stealth. Try for yourself: https://www.grc.com/x/ne.dll?bh0bkyd2

This is really basic security stuff... just saying.

[FURRYe38]

Thanks for letting us know. I and others have already seen this and reported it to NG. No responce as of yet. Hopefully someone will check in to this. 

[warpdag]

Added a screenshot just in case. Firmware is obviously far from being ready for prime time.

[FURRYe38]

Thanks. 

[tantrum]

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.

[warpdag]

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.

[FURRYe38]

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.

---

[FURRYe38]

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 Tested

Ports 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. 

[FURRYe38]

Ok I found my test results from January with a modem only:

CM1100>RBR850><Wired Windows 10x64 PC connected to RBR only. No other devices connected. 
Browser: IE11x32

Site is reporting stealth mode for a few ports:
GRC Port Authority Report created on UTC: 2020-01-20 at 23:34:26
Results from scan of ports: 0-1055 0
Ports Open 1048
Ports Closed 8
Ports Stealth --------------------- 1056
Ports Tested NO PORTS were found to be OPEN.
Ports found to be STEALTH were: 53, 80, 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 presume this probably hasn't chanced since I tested this on v3.2.9.x.

I'll check this again with most current version of FW. 

[tantrum]

My firmware version says it is the latest (I guess official/public) release.

V3.2.10.11_1.2.12

Putting the faux DMZ up is to protect my network; it does nothing except make more 'blue' (exposed) ports to 'green' (stealthed) with the goal being to stealth all ports as it just sends the incoming traffic off a cliff.

I already had the other settings in place per the information I provided (re: wan ping and ddos), other than I can't just unplug and disrupt my network as requested, so there are many wired and wireless devices connected to the router.  Why would this matter?

The only UPNP requests are from the PCs setting up network / home sharing on the LAN side.  There's no business or justification for having ports open for that or anything else on the WAN side as well given the port forwarding and related configuration.

With this setup, the port scan gives the same sort of pattern as the OP already posted in their screenshot (although I tend to only get 3 blues instead of 4 in a row, per row).

The router also doesn't even realize a port scan is taking place.  The logging option to report "known" DDoS and port scans is checked, and yet it captures nothing.

[tantrum]

I replied with further info and see the thread message count has gone up, but guess/suspect it's in a moderation queue or something.  So will wait and see.

[FURRYe38]

Do you have a router or modem/gateway in front of the RBR850? 

What is the Mfr and model# of your ISP modem/ONT? 

DMZ doesn't protect networks from other networks. It's a on the front lines of the internet and doesn't do any kind of firewall/security or protection. Be careful what you place in any DMZ. 

There is no moderation queue on NG forums. Only things that have to wait to be moderated is pictures included in posts. 

---

@tantrum wrote:

I replied with further info and see the thread message count has gone up, but guess/suspect it's in a moderation queue or something.  So will wait and see.

---

[tantrum]

You are not understanding the setup I think; the DMZ default IP is being set to 192.168.1.252

There is NO DEVICE ON THE NETWORK with an ip address of 192.168.1.252

Ergo all traffic goes to a port that does not exist.  It is not open and cannot be open.  It is not closed and cannot be closed.  Hence why I get far better results than you do (e.g. most ports stealth for me, most ports closed for you).

It is 100% safe setup this way, and I know how the DMZ works.  The only way I could make this safer is to fabricate a MAC address and add an IP reservation for 192.168.1.252 to it, then it wouldn't even accidentally get assigned via dhcp.

There was a picture in the post that did not appear in the forum.  So I guess it is being moderated.  It was a screenshot of the shields up results.  Very similar to the OP's with mostly stealthed ports but a stepped pattern of a few closed ones on every 2/3 rows.

The modem is branded by Spectrum, model E31u2v1.  It's just a docsis 3.1 modem, not a router.

My router is the RBR850, plugged into the modem.

So here's the thing.  What can _you_ do to make all but your explicitly open (forwarded) ports go "green" (stealthed or not present) instead of "blue" (closed but present)?

Until you can get results close to or better than mine, I'm not sure there's much merit in this information being requested.  Right now your own results are appallingly bad (not your fault, it's the router).

I am used to having a fully stealthed setup, prior to this router and for every ISP/router/modem before it.

[tantrum]

This (if it posts this time) is approximately what you are trying to beat, but with no blue squares and only reds where you have explicitly opened a port (in my case 443 for an https service):

[FURRYe38]

Well to get the best and accurate results, yes, your modem is just a modem, DMZ is and should not be used when running that Sheilds up test. The test is testing the ports at the router thru the modem on the WANtoLan side. DMZ should not be used as this may cause accurate results. Also need to ensure that only 1 testing device, i.e. wired PC with only 1 browser app running with the test site be online. If other devices and apps are running, these will use ports and result in false positives. Just wanting to be sure your testing with that site accurately is all. 

Ah, your test results are far worse then mine. The test needs to see BLUE over green. ShieldsUP is looking for BLUE=CLOSED ports. They fail results with GREEN=Stealthed ports or open ports. 

From what posters have said about Orbi AC, seems like there is alot going on behind the scenes with Orbi system data out going from there system to NG cloud services. There was a long discussion about Orbi AC having out bound system traffic going out to NG servers. Some users have been blocking this traffic. This maybe the same with Orbi AX. 

At anyrate. Yes there is problems and I did already submit a bug report about this with NG. Unfortuneately it hasn't been touched or anyone responded to date. 

I'll I can recommend is users open a support ticked with NG support. The more we complain about this, hopefully NG will respond. 

@Christian_R 

@ErnestTheGreat 

@ChristineT 

[tantrum]

Strong disagree; I could have a thousand devices on the LAN and it should not influence a single port to be open on the WAN side unless configured to do so at the router.

This also has nothing to do with outbound connections to cloud services and only to do with ports for inbound traffic from some unsolicited host (in this case solicited because we are deliberately using the GRC port scan services, but otherwise the router should be behaving like it is requested traffic from an unsolicited host).  For you to mention this suggests a misunderstanding of what is happening in the port scan results.  I could block all the outbound traffic to NG and close all the browsers (or have 200 of them open) and it won't change the result a single bit.

The "stealth" results are equal to 100% packet loss, which is (again) what my fake DMZ assignment is doing, it's sending the packets to a place of no return - because that's the ONLY way the router behaves correctly for SOME of the ports.  It is a router not a reverse proxy, and should not be opening or closing connections to a remote host by itself.

For over 15 years I've been using GRC and shields up to test the ports on my network, with multiple ISPs, properties, and networking hardware, and never before have I seen such behavior from a router or the strange insistences you keep having about it, many of which are incorrect.

You tested it yourself, including (if I'm not mistaken) with the "1 wired device, 1 Orbi router, 1 modem", and you got no better results than we did - they were in fact worse, agreed?  So I don't know why you keep championing other causes of the problem when you can't resolve it either when excluding them.

[FURRYe38]

My test methods are more actual and simple then using DMZ. DMZ should not be use period for these kinds of tests. In most home use cases, users will not be using or configuring DMZ. Especially on a single NAT system. Again, trying to accurately test and test configuration is criticial. 

II believe CLOSE ports is what GRC is looking for and reports stealthed ports as failures;

https://www.grc.com/faq-shieldsup.htm#STEALTH

https://www.grc.com/faq-shieldsup.htm#005

https://regmedia.co.uk/media/661.htm

I recommend you contact GRC and ask them directly what they are testing for and what they deem as passing and what is failing for there test. I don't see an example of what they deem as passing or failing. That would be helpful to see on there site. 

I'll I can recommend is users open a support ticked with NG support. The more we complain about this, hopefully NG will respond. 

[warpdag]

Closed is the default behavior if you go back to the original RFC, but that’s like 30+ years ago when security was literally an afterthought.

It is not considered proper behavior by today’s standards, as it discloses the presence a device or multiple devices behind a specific IP address. The more info is disclosed, the easier it gets to find vectors for intrusion.

The GRC test shows passed when all the ports respond as stealth and ancillary stuff like ICMP remains quiet. Even most sub-$50 routers get it right.

[FURRYe38]

Well Orbi is doing what it's doing currently. We can talk alday about it until were blue in the face. NG needs to address this and let us know what the deal is. Again, users needs to file a support ticket and voice your concerns about it. There nothing we can do here in the forums about it. 

[Blanca_O]

Hi @warpdag and @tantrum

Our support team is looking into this issue and would like to work with you. I will PM you requesting for more information.
 

Thanks @FURRYe38 for alerting us to this post.

Regards,
Blanca
Community Team

[FURRYe38]

OK so I finally got some time to test this again now that v15.25 was released.

ISP modem only>RBR850 (with no devices attached accept for 1 wired Mac Book Pro 2018 OSX 10.14.6, No DMZ) and Firefox browser:

---

Seem the GRC is looking for ALL ports to be stealthed to get a PASSING result. The RBR850 is doing what it supposed to. I presume if other ports are seen as closed or open, then this means other devices and apps are connected to these ports. This reason why I wanted to try this again with just 1 wired PC running, no RBS, wifi devices or apps connected. 

@Blanca_O 

---

[tantrum]

It's not just GRC looking for this, it's me and anyone else wanting a more secure network too.

I get it that it may be responding to the request to open ports by things on the LAN side, but it should only open them ON the LAN side, they should not be automatically allowed to punch through and be visible on the WAN side, and there should not be a way this cannot be blocked.

Even with UPnP disabled on the router it still opens those ports to allow things through, that is an issue for a device designed to act on the network edge.  Why do you think it is that with the same devices in the home and on the network, and only swapping out a prior router for an Orbi, that this difference should occur and not be controllable/configurable; even if I map forward those ports to a specific device that has them firewalled (so the packets should be dropped and ergo stealthed in GRC), it's still giving priority to "something else" to use that port assignment - that would be wrong / bad.

I've responded to Blanca's PM.

[warpdag]

Amen, brother. It’s refreshing to see some people who understand basic security around here. The router should only show open or closed ports to sessions already initiated by the ***LAN side***, and not simply respond to random requests from the WAN side (and no, tracking sessions is not rocket science).

UPnP is another can of worms, I personally believe it should be disabled by default, allowing devices to poke holes in a firewall without user consent is ludicrous (and quite frankly, unless all you do is downloading torrents 24/7, the need for UPnP is highly debatable).

[FURRYe38]

Well seems the RBR is doing something. Wheather GRC is correct or Orbi isn't. Those are the results I got. Again when in normal operation and other devices online and connected, there will be ports being OPEN and in use and seen as such by GRC.  

 For all the years i've been uPnP I have had not 1 problem with it or anyone trying nefarious things with uPnP what so ever. 

If your not happy or satisfied with Orbi AX and it's security, return it and find something that is to your satisfaction. 

[warpdag]

And I did just that, I bought into Ubiquiti (see attached photo, with UPnP enabled just to make a point, but note that a cheap/old TP-Link AP I had lying around worked just as well).

Also note that what you’re describing is incorrect, GRC shouldn’t see open ports, period. The router should track sessions and behave accordingly, i.e. if an IP knocks at a certain port but there’s no ongoing session with this IP, the response should be drop (no response), even if the port is open to service ongoing, valid sessions.