When you go to work, do you lock your front door? When you leave your car parked on a city street, do you take your keys out of the ignition? When you mail an envelope, do you seal it?
We’re pretty sure the answers to these questions are yes, yes, and yes. Even if you live in a safe neighborhood, park on a quiet street, or think your personal life isn’t interesting enough for someone to want to read your mail, it would be silly not to take the minimum steps required to discourage theft or eavesdropping.
But can you say the same about the networks you manage? Are you taking at least basic precautions to ensure logins and communications between the devices you manage are secure?
The evidence suggests the answers to those last two questions is no. That’s because hundreds of thousands of servers, routers, and switches are running fundamentally insecure services—namely, Telnet and SNMP versions 1 and 2—that make it much easier than it needs to be for attackers to brute-force login credentials or sniff your data.
The problem with insecure protocols
“Fundamentally insecure” is a powerful term, so let’s explain what we mean.
To be sure, running Telnet or SNMPv1/2 on a device doesn’t mean hackers can necessarily walk right in. You’re still protected by login credentials. Plus, if your devices are behind firewalls or on private networks, they’ll be harder for attackers to find.
That said, Telnet and SNMPv1/2 both have deep flaws.
In the case of Telnet, these include the passing of login credentials in plain text. That means anyone running a sniffer on your network can find the information he needs to take control of a device in a few seconds by eavesdropping on a Telnet login session.
That’s not all. Because Telnet doesn’t encrypt sessions, all of the data passed through the protocol—not just login information—can be read pretty easily by third parties.
Lack of encryption is also a problem in SNMPv1/2, which relies on community names as a login credential. These can often be intercepted using a packet sniffer. Even if they can’t, the fact that SNMPv1/2 uses default community names unless an admin changes the configuration makes it trivially easy for attackers to try to guess their way into a system.
Given these security problems—and the fact that, as we explain below, better alternatives are readily available—it’s simply not worth the risk to be running Telnet or SNMPv1/2 on your network if you can help it at all.
The presence of these protocols doesn’t guarantee you’ll be hacked, but—like unlocked doors or unsealed envelopes—they make you an easy target for reasons you could easily avoid.
Insecure protocols in the wild
Just how serious is the problem of insecure services in the wild? To get a real-time sense of how popular these protocols remain—and how remarkably easy it is for people up to no good to find devices using them—run a quick query on Shodan, the search engine billed as “Google for hackers.”
Right now, Shodan shows more than 260,000 Internet-facing machines running Telnet, which the site reports as the sixth most popular network service overall. Instances of SNMPv1/2 total only about 7,000—a less striking figure, but one that still makes a pretty fat target for malicious hackers.
Keep in mind that much larger numbers of devices with Telnet and SNMP services are probably running behind firewalls or on private networks, which Shodan can’t see. But that doesn’t mean those devices are no cause for concern. Hackers could still exploit them by finding a door into your network from the outside.
Worse, someone like a former employee who retains network access he shouldn’t have, and who probably knows exactly where to find insecure devices on your organization’s network, might use services with weak security to wreak all manner of havoc.
The protocols that just won’t die
If it were 1995, we wouldn’t be so critical of Telnet and SNMPv1/2. Two decades ago, when more secure alternatives to these services didn’t yet exist, they were among the best tools admins had.
Flash forward to the present, however, and there are much better resources at our disposal. SSH-2 allows you to manage devices remotely in pretty much the same way as Telnet, but without the plain-text authentication and lack of data encryption.
As for SNMP, more modern versions of the protocol—specifically, SNMPv3 and higher—offer better cryptography than SNMPv1/2, among other security improvements.
To a large extent, the fact that more secure protocols haven’t entirely replaced older ones is not the fault of network administrators.
In many cases, moving on from Telnet and SNMPv1/2 remains tough because vendors continue to ship devices designed to use these insecure services, often because they’re easier to configure and deploy than the more secure alternatives. And users who don’t fully appreciate security risks are more interested in ease-of-use than in rock-solid security.
The problem will continue to grow as the expansion of the Internet of Things places more and more devices on the network that require an easy means of logging in.
What network administrators can do
There are two main steps admins can take to mitigate the security risks associated with insecure communication protocols.
The first and most obvious is to find devices running services like Telnet and SNMPv1/2, and to replace them with a more secure option. Locating devices like these is easy with a network operations system that keeps track of which ports and services are running on which devices.
Once you’ve identified the insecure devices, replace Telnet with SSH-2, and upgrade installations of SNMPv1 and SNMPv2 with SNMPv3, which is much more secure than its predecessors.
Of course, in some cases it’s not possible to switch to a more secure protocol. You might have legacy devices that don’t support SSH-2 (though that seems very unlikely, as SSH-2 has been around for decades) or SNMPv3. Or your organization might demand older protocols for reasons you can’t change.
In those situations, you should still do what you can to ensure your services are configured as securely as possible.
For Telnet, that means setting up complex passwords that attackers can’t brute-force. Similarly, if you absolutely have to use SNMPv1/2, make sure to change the default login credentials.
You can also deploy IPsec or a similar solution on your network to encrypt data over all connections. That will make it harder for attackers to sniff login credentials and private information, even if information is exchanged over Telnet and SNMP.
Last but not least, be sure you know which devices need patching and that you apply updates regularly. Even protocols as robust as SSH-2 can become a security disaster if you’re running an outdated version with known code flaws, as the infamous Debian SSH fiasco of 2008 made clear.
Finally, if there is a breach, remember to change your security keys.
To test Auvik’s remote management features for yourself, sign up for a free 14-day trial and get full access to your network from the comfort of your desk.
Your Guide to Selling Managed Network Services
Get templates for network assessment reports, presentations, pricing & more—designed just for MSPs.
