RBR850 Massive Security Fail - Many ports responding to requests

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.

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.

---

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.

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):

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 

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.

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 STEALTH ports is what GRC is looking for and reports closed 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. 

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. :smileyfrustrated:

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

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 

---

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.

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. 

I tried replying twice yesterday and my posts didn't get through - images again I suspect.

Bottom-line, the reason you are seeing the difference now is because of the 15.25 version has fixed the issue we were raising.

After updating that, I also get the ports showing stealthed properly now even with several devices connected.

It had *nothing* to do with you running an isolated test with just 1 wired device this time.

Blanca_O - I don't know if this fix came about at all from this thread, I suspect the coding and testing was already underway for this before I started posting on it at least.  Either way I'm very thankful to see this improvement, and if you would pass my thanks on to engineering please, I would appreciate it.

Try selecting the Choose File button at the bottom to attach posts. 

So the new FW is working for you then? 

This was reported way back in January FYI...

---

tantrum wrote:

I tried replying twice yesterday and my posts didn't get through - images again I suspect.

 

Bottom-line, the reason you are seeing the difference now is because of the 15.25 version has fixed the issue we were raising.

 

After updating that, I also get the ports showing stealthed properly now even with several devices connected.

 

It had *nothing* to do with you running an isolated test with just 1 wired device this time.

---

Well if there is a valid app or device accessing the port, then the port would be open at the time if GRC was being tested.

Here is my GRC results with everything conneted and working normally:

Well, seems like this new version of FW is helping or chaning what had been seeing in prior versions of FW. Users will be encouraged to update. 

---

warpdag wrote:
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.

---

Just because a port is open doesn't mean packets won't or can't be filtered and dropped because they are coming from another session, as warpdag described, thus appearing to a 3rd party like GRC like the port is still stealthed even if the network is actively communicating over it.

I think we're done here.  Again, glad to see this be fixed by NG.