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, HTTPS, SNMP, etc is listed BUT SSH is missing! How can I add SSH to my Access Control list as I did for HTTP, HTTPS, SNMP, etc. so only specific IPs have access?
2. In the GS728TPv2 CLI manual, there is mention of how to access the CLI via TELNET but there is no mention on how to disable Telnet on the switch!!! Cannot find any way of disabling TELNET. This is a huge SECURITY HOLE. How do I disable TELNET on the switch?
Why is Netgear adding potential backdoors to our business switches??!!
Please advise.
9 Replies
Welcome to the community! :)
1. Though SSH has now been added to the switch.... SSH is missing in Security -> Access control section. HTTP, HTTPS, SNMP, etc is listed BUT SSH is missing! How can I add SSH to my Access Control list as I did for HTTP, HTTPS, SNMP, etc. so only specific IPs have access?
Can you try to update the firmware to the latest version which is v6.0.10.10 then check if the same problem will occur. Be sure to clear the cache of your browser or try Incognito Mode (or In-Private Browsing) then access the web-GUI again and double-check it.
You can download the GS728TPv2 firmware v6.0.10.10 here.
2. In the GS728TPv2 CLI manual, there is mention of how to access the CLI via TELNET but there is no mention on how to disable Telnet on the switch!!! Cannot find any way of disabling TELNET. This is a huge SECURITY HOLE. How do I disable TELNET on the switch?
Telnet access can be disabled via the web-GUI of the GS728TPv2. On the web-GUI, go to Maintenance > Troubleshooting > Remote Diagnostics. When it is set to disable, the Telnet access will be disabled as well.
Regards,
DaneA
NETGEAR Community Team
- 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.
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.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
