NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
warpdag
Jan 25, 2020Apprentice
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...
Blanca_O
May 19, 2020NETGEAR Employee Retired
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
May 23, 2020Guru - Experienced User
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.
- tantrumMay 23, 2020Apprentice
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.
- warpdagMay 23, 2020ApprenticeAmen, 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). - FURRYe38May 24, 2020Guru - Experienced User
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.
- tantrumMay 24, 2020Apprentice
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.
- tantrumMay 24, 2020Apprentice
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.
- FURRYe38May 24, 2020Guru - Experienced User
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.
- FURRYe38May 24, 2020Guru - Experienced User
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. - tantrumMay 24, 2020Apprentice
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.