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.
Model: GS728TPv2|24-Port Gigabit Ethernet PoE+ Smart Managed Pro Switch with 4 SFP Ports (190W)
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.
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 well
One 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!
@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?
@schumaku Thank you for your understanding. I don't know what influence you have to get the SSH & Telnet ACL request to the FW Devs but I hope you can. In the meantime, our GS728TPv2 will remain shelved until this issue is resolved. We currently are no longer procuring Netgear for our evergreen switch updates.
Note: Depending on the switch, the state Table TTL, at some point, a scan would return either nothing or at minimum closed when the table entry times out and is removed via garbage collection. This ongoing "filtered" port appearance does not happen on a Cisco, HPE, a Server, etc. where, once the state entry has timed out, the device scan reports nothing at all on ports 22 & 23. So I can't agree with your filtered argument unless via the CLI there is a way to see the state of all services running on the switch (similar to what can be performed on Unix/Linux/Cisco, Windows, etc.). I didn't see this mentioned in the Netgear CLI UG for the GS728TPv2 v6.0.10.10.
Dear I have just Limited power, Mainly just yet another community member who can't have his moth shut. From time to time I get the opportunity to test drive new models. But I'll see how much I can archive here.
