NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Security concerns GS728TPv2 with FW v6.0.10.5
Updated my GS728TPv2 with FW v6.0.10.5 and noticed some serious security issues. 1. Though SSH has now been added to the switch.... SSH is missing in Security -> Access control section. HTTP, HTT...
"Then it won't RST, it will return a port not available. in reality, admins tend to have a shell access open complementing the WebUI."
The reality is IF an Admin decides the services need to be disabled due to security concerns, then they should be able to disabled fully when implemented. Your "in reality" example is misdirection at best and doesn't reflect the security concern stated here.
There are many code implementations available where past Netgear device ports (aka TCP 6000) where terminal sessions can activate telnet on a filtered port via magic packets.... since the service is in a suspended state... not actually disabled. When Netgear is asked as to why, support remains silent. Suspicious behavior indeed.
What's the difficulty here? Will the switch collapse & explode if these services are truly disabled? What's with the push-back? If there is something more to this then communicate it clearly as to why Netgear can't fully disable these services where HPE, Aruba, Cisco and even TP-Link can.
Option #2:
At a security minimum, these 2 services should allow ACLs to confine them to a user defined VLAN only.... then these services are of much less concern for us. Think Ops MGMT internet isolated VLANs. ITIL and security best practices have been recommending
and doing this type of implementation for 20+ years in a business context.
Your response (maybe unintended) is coming off as this concern & request is something new, odd and maybe for you it is. But in the IT Industry, effectively reducing the attack surface on a device has been a best practice for over 2.5 decades.
The reality is IF an Admin decides the services need to be disabled due to security concerns, then they should be able to disabled fully when implemented. Your "in reality" example is misdirection at best and doesn't reflect the security concern stated here.
There are many code implementations available where past Netgear device ports (aka TCP 6000) where terminal sessions can activate telnet on a filtered port via magic packets.... since the service is in a suspended state... not actually disabled. When Netgear is asked as to why, support remains silent. Suspicious behavior indeed.
What's the difficulty here? Will the switch collapse & explode if these services are truly disabled? What's with the push-back? If there is something more to this then communicate it clearly as to why Netgear can't fully disable these services where HPE, Aruba, Cisco and even TP-Link can.
Option #2:
At a security minimum, these 2 services should allow ACLs to confine them to a user defined VLAN only.... then these services are of much less concern for us. Think Ops MGMT internet isolated VLANs. ITIL and security best practices have been recommending
and doing this type of implementation for 20+ years in a business context.
Your response (maybe unintended) is coming off as this concern & request is something new, odd and maybe for you it is. But in the IT Industry, effectively reducing the attack surface on a device has been a best practice for over 2.5 decades.
dread99a wrote:
At a security minimum, these 2 services should allow ACLs to confine them to a user defined VLAN only.... then these services are of much less concern for us. Think Ops MGMT internet isolated VLANs. ITIL and security best practices have been recommending
and doing this type of implementation for 20+ years in a business context.
These services should exist on the management VLAN only anyway. Logically, you might request ACLs to set any service to any random VLAN, too. Overkill?
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
