RBR850 Massive Security Fail - Many ports responding to requests

[tantrum]

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.

[tantrum]

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

[FURRYe38]

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.

---

[FURRYe38]

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.

---

[tantrum]

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.

[warpdag]

@FURRYe38 I invite you to read more about how sessions work. It’s not because sessions are ongoing on a specific port that random traffic should be able to insert itself into the flow. Otherwise, for instance, your ports 80 and 443 would always show open (web traffic). Real life example: I’m currently using port 443 to post this, so the forum server sees me on that port, yet GRC gets no response from that port.

[FURRYe38]

Yes, I think were done. FW has been updated and seems it was finally fixed. Thank you NG. 

I recommend users update there FW if there concerned about Orbi security. 

Good Luck and enjoy. 

[dglsmcd_USMC]

Using Shields Up from the grc website with the current firmware available (not available for manual download) I received a "passed" having achieved true stealth analysis for all service ports. We are indeed done with this thread.

[FURRYe38]

Thanks for letting know what you see as well. 

Enjoy.