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...
Well Netgear's support response is mostly incorrect. Security issues remain with FW v6.10.10.
1. If Telnet & SSH are disabled in the WebGUI, the SSH & Telnet ports are still ACTIVE and are not disabled. Found this info from performing a port scan on the GS728TPv2 switch.
RESULT:
PORT STATE SERVICE RESULT
22/tcp filtered ssh very bad
23/tcp filtered telnet very bad
443/tcp open https ok
So it appears the "filtered" ports can be opened via a magic packet. These ports should have been "closed"! If this is Netgear's way of implementing CALEA compliance. .. no wonder soooo many systems are being compromised by bad actors.
2. Still CANNOT harden SSH using Access Control. The SSH service is still missing from the list!!! Telnet should be provided for ACLing as well
Conclusion: Netgear does not provide business class secure firmware. The security in FW v6.10.10 is very suspect. This switch will remain out of service as we have been using a much better and secure brand now in our production environment.
Q: Did the Netgear responder even TEST your solution?... as most of it has found to be Vapor-ware and incorrect.
1. If Telnet & SSH are disabled in the WebGUI, the SSH & Telnet ports are still ACTIVE and are not disabled. Found this info from performing a port scan on the GS728TPv2 switch.
RESULT:
PORT STATE SERVICE RESULT
22/tcp filtered ssh very bad
23/tcp filtered telnet very bad
443/tcp open https ok
So it appears the "filtered" ports can be opened via a magic packet. These ports should have been "closed"! If this is Netgear's way of implementing CALEA compliance. .. no wonder soooo many systems are being compromised by bad actors.
2. Still CANNOT harden SSH using Access Control. The SSH service is still missing from the list!!! Telnet should be provided for ACLing as well
Conclusion: Netgear does not provide business class secure firmware. The security in FW v6.10.10 is very suspect. This switch will remain out of service as we have been using a much better and secure brand now in our production environment.
Q: Did the Netgear responder even TEST your solution?... as most of it has found to be Vapor-ware and incorrect.
dread99a wrote:
So it appears the "filtered" ports can be opened via a magic packet.From which Grimm's tales book is this coming from? I'll tell you later why ...
dread99a wrote:
These ports should have been "closed"! If this is Netgear's way of implementing CALEA compliance. .. no wonder soooo many systems are being compromised by bad actors.Which area of CALEA are you referring to, please? Have potentially the CALEA SSI requirements in mind? So where does it say that a device is not allowed to report a port closed instead of doing a simple connection reset?
dread99a wrote:
2. Still CANNOT harden SSH using Access Control. The SSH service is still missing from the list!!! Telnet should be provided for ACLing as wellOne item I can't disagree, because it's indeed missing.
However: Once you implement a filter, ACL, firewall, ... with the telnetd or sshd started, you will see nmap stating "filtered" ... because "closed" would be the IP stack dropping the connection, while "filtered" is what it is: The stack will report port closed and return the related ICMP blurb. We can dispute if the ACLs are fully closed - this is what Netgear has implemented the (misleading) telnet resp. ssh disabled.
dread99a wrote:
Conclusion: Netgear does not provide business class secure firmware. The security in FW v6.10.10 is very suspect. This switch will remain out of service as we have been using a much better and secure brand now in our production environment.Try to understand the difference between a service not active and the related IP stack answer (RST) vs. the behavior if a port is ACLed as per your desire: 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. Depending on a firewall implementation, a firewall can show this "filtered" even of the service behind the router isn't fully down. Said that, "filtered" is not evil - it's just that nmap et all can't tell fore sure what is there.
Reminds me to the adventurous time where people requested a firewall "stealth" implementation -not- answering in either way (no RST, no iCMP port is not available. Mind yo: This is not RFC compliant then.
- "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.No worries, probably two decades longer in this business, praying the same things you do.
And I said the behavior of the disabled service is wrong. Have just explained that enabling the service and applying ACL will lead to the same effect on NMAP (and when monitoring the effective traffic). probably I was not clear either ... disadvantage of age and by not being a English language native - sorry for the confusion in case, this was not intended.
And yes, there is a lot of legacy Netgear - for whatever historic compatibility - should be removed from the code.
Just to add another example from my reports: While I like Netgear Insight, i still can't see any reason why the related daemons are still kept running in pure Web management mode. Just for the case somebody does attempt to add a device to the Insight cloud one day.
So you see, we share very similar views and concerns 8-)
YeZ please create some more awareness with the switch engineering on these reports!
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
