Network World calls on Cisco and other security vendors to fix default settings that leave users vulnerable to attack.
Our first challenge to all vendors mentioned in this column – and Cisco in particular as the 800-pound network gorilla – is to address the dumb security defaults they ship with their products. There are more than a few instances of these dumb defaults, but for the purpose of our discussion, we’ll point to some of the more egregious examples.
Editor’s note: This is the first in a series of Tester’s Challenge columns in which Network World Global Test Alliance members push the industry to remedy pressing issues that confront our readers. In turn, we will allot space in print and online for vendors to respond.
When we tested Blue Coat Systems’ security gateway in the lab last year, the product manager reeled off an impressive list of security features. Great stuff, I thought; the company is serious about access control.
Then we powered up the gateway, and the available management methods – Web and telnet – made me rethink my favorable assessment. Neither of these offers secure authentication or encryption. With these methods enabled by default, it would be easy for an attacker to intercept a password and then change the device’s configuration or even shut it down.
Seen in that light, none of the other features of this “security device” really mattered. How secure is a system that accepts passwords sent in the clear? Just as worrisome, how many network managers will remember to disable these defaults?
Blue Coat says it no longer supports these access methods out of the box, but it is far from the only offending company on this point. Network giant Cisco, security-minded NetScreen Technologies and numerous other equipment makers ship products with weak or nonexistent security defaults. Virtually every product I’ve tested in the last 18 months suffers from this problem.
We’d like to be part of the solution.
Our first challenge to all vendors mentioned in this column – and Cisco in particular as the 800-pound network gorilla – is to address the dumb security defaults they ship with their products.
Your thoughts
Is Newman right? Discuss in our forum.
There are more than a few instances of these dumb defaults, but for the purpose of our discussion, we’ll point to some of the more egregious examples.
SSH: Secure shell (SSH) is supposed to offer secure access to a command-line interface. While it’s better than telnet, not all SSHs are alike. Exploits of SSHv1 have been around since at least 1998.
Incredibly, SSHv1 is the only option available for many of Cisco’s routers. Cisco Catalyst switches support SSHv2, which fixes Version 1’s vulnerabilities, but by default these devices allow SSHv1 access as well.
By some estimates, Cisco makes at least three-quarters of all routers attached to the Internet. Given that attackers can intercept passwords, change configurations and disable devices at will, the lack of proper SSH hygiene is staggering and downright scary. When will Cisco enable SSHv2 (and only SSHv2) on every box it sells?
NetScreen also has a place in the SSH hall of shame. The company’s otherwise-estimable security products support only SSHv1. To further confuse customers, NetScreen refers to SSH as “secure command shell” because of licensing issues. First-rate SSH implementations exist in the open-source world; it wouldn’t hurt NetScreen to use one of these and ship products with only Version 2 support enabled out of the box.
SNMP: Like SSH, multiple versions of SNMP exist. Only the most recent, Version 3, offers strong authentication and encryption. The problem is that relatively few network devices support it.
Extreme Networks and Foundry Networks have added SNMPv3 support to their line of Ethernet switches, but neither vendor supports this secure management method by default. To both vendors’ credit, the earlier, unsecure versions of SNMP aren’t enabled by default either – but once they are, it will take an attacker approximately 1 nanosec to guess default community strings and password.
HTTP: Just about any new network device can be managed through a Web interface. Sometimes, it’s the only management method.
Web management is convenient. But convenience and security often are mutually exclusive, and this is one of those cases. Yes, Web servers can require passwords – but without encryption. And Web server implementations have a long security history of buffer overflows and other exploits.
The bottom line for users is: Don’t use HTTP for management, much less enable it by default. From a security standpoint, losing Web access altogether would be a net gain. The bottom line for vendors is: If you want to offer Web access for management, fine – but don’t use unsecure ports and protocols to do so.
SSL/TLS: Secure Sockets Layer (SSL) and Transport Layer Security (TLS) offers much better security by default, with the devices using certificates for authentication.
But SSL/TLS security can be misleading. How many online shoppers click the browser’s padlock icon to inspect the certificate? How many understand the certification path well enough to say a certificate is valid?
In a recent IDS test, products from Barbedwired Technologies and Lancope used “self-signed” certificates, meaning they vouched for their own authenticity. In effect, this is proof by assertion.
If I told my bank my name was Warren Buffett, I’m pretty sure they’d ask for proof of identity before forking over Buffett’s billions of dollars. Similarly, a trusted third party should vouch for the identity of any “security device.” In this case, that would be a known good certificate authority, not the device itself.
When I discuss these issues with vendors, I’m sometimes told other security mechanisms can mitigate any vulnerability. I agree. For example, a firewall should keep outsiders from exploiting weaknesses on internal systems. But the firewall isn’t a cure-all. It won’t stop internal attacks. More seriously, adding a second security device does nothing to address the root problem of lame security defaults.
Our basic question to Cisco in particular and other network product makers in general: What’s the point of spending millions of dollars developing solid security features and then leave gaping holes in their default configurations? We’ve got 800 words’ worth of space in this magazine to print your answer. Let’s hear it.
Newman is president of Network Test, an independent benchmarking and network design consultancy in Westlake Village, Calif. He can be reached at dnewman@networktest.com. Newman is also a member of the Network World Global Test Alliance.
