× Introducing the Orbi 970 Series Mesh System with WiFi 7 technology. For more information visit the NETGEAR Press Room.
Orbi WiFi 7 RBE973
Reply

Re: GS810EMX address leak

JB-NS
Aspirant

GS810EMX address leak

I have a Nighthawk SX10 Switch (GS810EMX - firmware 1.7.1.1) with multiple VLANs set up.

 

I am getting a pretty regular arp leak from one vlan (Advanced 802.1Q) to another, where the switch management address is sending arps out ports that I don't want the management addresses leaked onto.

 

I cannot seem to find any way to have the management ports only respond (and arp) on either a manangement vlan - or some way to filter out addresses from ports that I don't want to have access to the management pages.

 

From a security standpoint, being able to limit management page access to either a set of port, and/or vlan, and not exposing the addresses (via arp) on unintended vlans would be an important thing to have. The ability to limit the management connections to an IP/range is good (which it has), but if you expose what that range is and what the management address is to every connected VLAN via arp, then someone on the network gains a way to access the device where you may not intend it (by setting their ip address to what the arp request is trying to reach).

 

If anyone has found a solution to this security hole, I would be extremely happy. With this exception, so far I have found the switch to be quite amazing in both features and performance.

 

Thanks!

 

J

Model: GS810EMX|10 Port Nighthawk 10-Multigigabit Uplinks Ethernet Plus Switch
Message 1 of 6
schumaku
Guru

Re: GS810EMX address leak

Not much we can do - this is the disadvantage of all Smart Managed Plus switch architecture (and their derivations like the Nighthawk Switches, Lifestyle Switches, or Web Managed Click Switches), except of the XS724EM: There is no way to properly isolate the tiny management processor by limiting it to a management VLAN (or a specific port).

Message 2 of 6
JB-NS
Aspirant

Re: GS810EMX address leak

I can understand that. If the management processor just can't set it's own traffic by port or vlan, it makes sense. But it would also seem that since it can already direct or block layer 3 traffic (both multicast and broadcast addresses) to destinations based on vlan and port, it would be logical to assume that the management ip range would at least be possible to include/exclude with the same functionality the processor is already using. As an alternative to controlling it's traffic based on port or vlan frame. Or even just a flat ip address range ban on certain ports or vlans to protect a management ip range. It just seems that there are already very similar capabilities to what would be needed which are already in use. Maybe there are other options available that aren't in the base web interface pages that could accomplish it? Thanks! J
Message 3 of 6
schumaku
Guru

Re: GS810EMX address leak

It's a resource shortage on the very tiny MCS-51 ("Intel 8051") class based controller - same limitations don't allow integrating a https Web server.

Message 4 of 6
JB-NS
Aspirant

Re: GS810EMX address leak

By resources you mean flash memory, or eeprom, cpu cycles, gpios? It seems with everything that's already in there there should be the capacity to use existing code already being used elsewhere that would accomplish the same thing with minimal increase in resource cost.

 

It can already forward multicast IPs only to vlan groups learned in igmp snooping. It can already perform port based blocking, limiting, and priority. Even if the management processor can't handle these itself, it should still be capable of telling the high-speed backend what to do just like it's apparently already doing in these other cases, right?

 

It just seems that if it can keep multicast packets in specific vlans/ports based on snooping and multicast IP address, adding a specific address/net to the same list shouldn't be more than just using what's already there.

 

I understand that it must not be something that is possible right now with the current firmware, due to resources? But the ingenuity of the folks behind Netgear products makes me think they can figure out a way.

 

It should be possible that it can be secured so someone on a vlan not intended for management can just set their ip to something they gleam in a separate vlan packet capture in order to gain access to the management interface. And ideally not broadcast every switch port with arps for computers not part of those networks.

 

I hope in the future that there's a secure solution to this, because in every other way I find the switch to be a very excellent product. I am not bothered by https being missing if I can keep management and/or it's addresses on their own vlan or port.

 

Thanks!

 

J

 

Message 5 of 6
schumaku
Guru

Re: GS810EMX address leak


@JB-NS wrote:

By resources you mean flash memory, or eeprom, cpu cycles, gpios?


Almost everything, and then some more. 8-/

 

There are two components: A switch core, which does allow some basic configuration operations using some I/O or GPIO taking care, and a tiny management processor.

 


@JB-NS wrote:

It seems with everything that's already in there there should be the capacity to use existing code already being used elsewhere that would accomplish the same thing with minimal increase in resource cost.


All the "heavy" L2+ stuff is done on the switch core. The management is done by this tiny MCS-51-type chip, but here we face the limitations that the management port and it's IP stack implementation is very basic - and here would these limitations (e.g. to only allow a management VLAN) would require a basic VLAN implementation - which I guess does not even exist on that simple OS).

When you look around on the Smart Managed Plus product line, you find some switch models which don't have the ability to restrict the management access to an IP subnet, or a defined IP.

 

Regards,

-Kurt

 

PS. I'm neither Netgear nor involved with the switch development - just one of these Beta testers nagging about these features and limitations for a while, too 8-)

Message 6 of 6
Discussion stats
  • 5 replies
  • 2167 views
  • 1 kudo
  • 2 in conversation
Announcements

Orbi WiFi 7