Get a Live Demo

You need to see DPS gear in action. Get a live demo with our engineers.

White Paper Series

Check out our White Paper Series!

A complete library of helpful advice and survival guides for every aspect of system monitoring and control.

DPS is here to help.


Have a specific question? Ask our team of expert engineers and get a specific answer!

Learn the Easy Way

Sign up for the next DPS Factory Training!

DPS Factory Training

Whether you're new to our equipment or you've used it for years, DPS factory training is the best way to get more from your monitoring.

Reserve Your Seat Today

Why You Need To Avoid Using Insecure Communication Protocols

By Morgana Siggins

September 1, 2020


It's safe to say that when you leave your home, you lock your front door. When you park your car on the street or parking lot, you lock it. Even when you mail an envelope, you seal it.

But, what about your mission-critical networks? Do you have efficient protection measurements in place to make sure that the communication between your monitoring system and managed devices are secure?

This is an important question because most networks involve equipment (such as servers, routers, and switches) that support communication protocols that lack security features. Examples of insecure protocols are Telnet and the early versions of SNMP (v1 and v2c).

Insecure protocols allow attackers and hackers to easily have access to your data and even to remote controls. So, it's critical that you can recognize the dangers of insecure communication protocols in your network, and know what to do in order to protect your information.

Let's dive in.

Problems That Can Be Caused By Insecure Protocols

First of all, if you have devices that support Telnet, SNMPv1, or SNMPv2c it doesn't mean that anybody can access your data. These protocols do support login credentials. Also, if your network is private and behind a firewall, it's harder for hackers to access it.

SNMPv1 and SNMPv2c support a security password that equipment needs to use in order to exchange information. This is called community string.

Why do I mean when I say Telnet and SNMPv1/v2c are insecure? These protocols have critical safety weaknesses that can negatively affect your network.

Telnet has a critical flaw in including the passing of login credentials in plain text. This means that anyone running a packet sniffer on your network will be able to detect the information needed to take control of your gear in a few seconds after eavesdropping on your Telnet login session.

A packet sniffer or packet analyzer is a kind of software that is used to intercept and monitor packets as they cross a network.

In addition, since Telnet doesn't have encryption capability, all of your information (not only your login credentials) that is sent back and forth in this protocol can be easily read by unintended people.

Speaking of lack of encryption, that's an issue in the earlier versions of SNMP as well. SNMPv1 and v2c rely on community string names as a login credential. Packets sniffers are able to intercept community strings. Another problem with community string names is that they come set as "public" as default, so as soon as you receive your SNMP device, you need to remember to change its configuration. Otherwise, your network can be easily attacked and exploited.

Due to these security issues and if you can help it, it's not worth the risk of consciously using Telnet or SNMPv1/v2c devices on your network. Of course, simply using these protocols doesn't mean that your network will be attacked but they do make you an easy target.

The Dangers of Insecure Protocols If Your Network Have Internet-Access

To get an idea of how easy it is for ill-intended people to find devices using insecure protocols, check Shodan out. Shodan is a search engine said to be the Google for hackers. On Shodan, you can search for internet-facing machines running Telnet, as well as for machines running on SNMPv1 and v2c.

Shodan is a search engine that lets you find specific types of devices connected to the internet using a variety of filters.

The number of devices that support Telnet and the earlier versions of SNMP protocol is much higher than what is shown on Shodan because many networks are running behind firewalls or on private networks. However, you network administrators should still be on top of the security on those devices. Malicious people can still find a way into your network and take advantage of your company.

Now, imagine that a person like a former employee still has access to the network (even though he shouldn't have), and probably knows exactly where to find the insecurities in your company's network. They can use these weaknesses to cause any many problems as they please.

But Why Many Networks Still Use Insecure Protocols?

Decades ago, Telnet and SNMPv1/v2c were some of the best protocols you could deploy in a network. Note that there were no other more secure alternatives to these tools.

However, nowadays there is better technology that can be deployed to ensure the safety of data. SSH-2, for example, makes it possible for you to manage your equipment remotely in almost the exact same way as Telnet, but it doesn't use the plain-text authentication and it doesn't lack data encryption.

The SSH-2 protocol provides a secure way to connect devices over an insecure network. SSH-2 provides you with powerful features that facilitate secure connections.

Now, for SNMP, the latest version of this protocol - the SNMPv3 - offers the authentication and cryptography capabilities. This avoids your data from being intercepted, but if it does this protocol is able to make the information unreadable so the unintended person can't exploit it.

SNMPv3 is the latest and most secure version of SNMP. It is able to authenticate and encrypt data packets over the network.

Although today you can find more secure communication protocol options, the older ones are still largely in use. However, the fact that insecure protocols haven't been replaced is most of the times not the fault of network technicians.

Replacing devices that run on Telnet or on the earlier versions of SNMP is most of the time tough because most vendors still ship equipment that supports these insecure protocols. This is because it's easier for them to continue to manufacture and ship these devices than the more secure alternatives. Also, companies that are not very safety-conscious are more interested in maintaining a known system than changing it.

The problem with all that is that as technology continues to evolve, and you will miss on newer capabilities that can enhance your network efficiency. Also, you'll become an easier target as other networks will have way better security strategies in place.

What Can You Do

There are two main ways network administrators can avoid security risks involving insecure communication protocols and protect their mission-critical data.

1. Replacing Equipment

This first option is very obvious. To avoid the dangers of having equipment running on insecure protocols, simply replace that equipment with more secure devices. Replace Telnet gear with SSH-2, and upgrade SNMPv1 and SNMPv2c with SNMPv3.

The problem with this solution is that replacing all of the equipment at the same time can come at huge costs.

2. Deploying a Mediation Solution

The problem with the first option is that, in most cases, it's not possible to replace all the equipment to devices running on a more secure protocol.

A modern remote monitoring system would, of course, solve security problems you might be experiencing, but for most companies, it's not possible to simply throw out your current gear and purchase new devices for all your remote sites. Imagine about how much money that would cost and all the engineering force needed simply to replace equipment that is still useful.

In these situations, you have two different options to ensure the safety of your network:

  • You can deploy a centralized master station to convert your existing protocol into SNMPv3 or SSH-2.
    This means that a central master station will be used to convert SNMPv1 or v2c messages into SNMPv3 or Telnet into SSH-2. Your existing devices will exchange information with this central master station, which will convert all information to more secure protocols as it receives it.
    Unless you have a very small network, this is the cheapest way to upgrade to SNMPv3 or SSH-2. But, you'd still be using unprotected messages until they reach the central master.
    SNMP conversion
    A SNMPv3 mediation device brings the benefit of modern, encrypted SNMP to your legacy equipment. You can avoid having to buy all new equipment at once.
    If you think this is the solution for you, it's important to deploy a competent master station. The T/Mon LNX is one of the best multiprotocol master stations that can be used as the SNMP mediator. With it, you can avoid buying all new equipment at once and you'll also get important capabilities, such as user-friendly web interface, multi-user LAN connectivity, nuisance alarm filtering, automatic notifications, and many others.
    T/Mon LNX has support for more than 25 protocols and hundreds of different devices. It will support all the monitored equipment in your network.
  • Or, you can deploy a fleet of RTUs that can be used as converter devices at your remote sites.
    Let's say you have devices running on SNMPv1 or SNMPv2c. In this option, individual RTUs convert these versions of SNMP to encrypted SNMPv3 at each of your individual remote sites. This way, the protocol conversion happens before the data leaves each site.
    This might not be the cheapest option, but with this decentralized alternative, you won't have unencrypted SNMP messages traveling across the major areas of your network. Also, these RTUs will be able to take care of other monitoring and control functions that you might need.
    SNMP RTU mediator
    Another option to convert SNMPv1/v2c to SNMPv3 is to use a fleet of RTUs. This solution entirely solves the security problem and you won't have a single point of potential failure.
    If you decide to go with this option, the NetGuardian Voice 16 is a compact but efficient RTU that will allow you to mediate SNMPv1 and SNMPv2c to encrypted SNMPv3. Your older SNMP gear will send unprotected messages only as far as your local Voice 16 (not across the wider network). It will convert trap messages to SNMPv3 and forward it to your central SNMP manager.
    Also, because the NetGuardian V16 is also a fully capable RTU that can be used to remote monitor non-SNMP equipment. You can, for example, convert contact closures to SNMPv3. But, if you network doesn't require an RTU, then you can order the V16 without alarming capabilities to reduce costs.
If none of these solutions make sense to your scenario, you should still do what you can to make sure your network is secured. For Telnet, set up complex passwords. For SNMPv1 and SNMPv2c, make sure to change the community string default login credentials.

Work With Us To Protect Your Network

Avoiding the deployment of devices that run on insecure communication protocols is the best practice. But, if you can't replace all your devices at once, you need a steady migration solution. Unfortunately, not every monitoring device will be able to offer you mediation capabilities. Especially, if we are talking about off-the-shelf products.

As an experienced remote monitoring solution provider, we know that every network is unique. You can't expect that an off-the-shelf device will meet all your needs perfectly. That's why we specialize in designing and building custom remote monitoring solutions.

Our vertically integrated business model allows us to perform all the manufacturing steps in-house. From designing, production, and shipping - all is done here at our headquarters in Fresno, CA. This means that it doesn't matter how unique your perfect-fit solution looks like, you can treat us as your own engineering department because we will build it for you.

Call us and schedule your customization consultation with our experts.

Morgana Siggins

Morgana Siggins

Morgana Siggins is a marketing writer, content creator, and documentation specialist at DPS Telecom. She has created over 200 blog articles and videos sharing her years of experience in the remote monitoring industry.