Secure network protocols

March 22, 2021 by

Kurt Ellzey

For a very long time, having devices just work on a network was a feat in itself. This meant that the protocols involved didn't necessarily need to be secure, they just had to work. Even years after this mentality started to change to support more secure protocols, we still find ourselves in situations where a significant number of devices come out of the box with everything turned on- secure and unsecure- until the users finish their configurations and such down what they don't need.

As a result, this means that some protocols have stayed around a lot longer than they really should have, because there's nothing actively forcing organizations to change other than best practices. Today we're going to be going over a list of unsecured network protocols, and secure network protocols that can be used to replace them.

Learn Network Security Fundamentals

Build your skills with seven hands-on courses covering network models and protocols, wireless and mobile security, network security best practices and more.

Start Learning

Instead of FTP, use… SFTP or FTPS?

FTP (File Transfer Protocol) has been around for 50 years now, and has seen support for it removed from most major browsers. While dedicated command line and GUI based programs still exist and will very likely continue to exist for the foreseeable future, derivatives have long since been available with significantly enhanced security. Unfortunately the main alternatives can be extremely confusing with their naming schemes, despite using radically different security methods.

FTP Secure (FTPS), is a version of FTP that added in support for SSL (Secure Socket Layer), which has since been replaced by TLS (Transport Layer Security). SFTP on the other hand is the SSH File Transfer Protocol, which allows for files to be transferred securely through SSH (Secure Shell). Both options are quite capable of securely transferring files, however they can cause additional concerns. Since FTP transmits its credentials and commands in cleartext on a known port, it can easily be examined by firewalls as requests pass through. FTPS on the other hand uses dynamic secondary ports for transmitting data by default, which can make implementation difficult if not adjusted.

Fortunately some FTPS servers such as IIS have built-in options to be able to restrict the dynamic port range, which can be found in the Further Reading section. Since SFTP uses SSH to create its connection, this is far simpler to allow through a firewall, but support for SFTP servers on non-*nix boxes historically was limited. This has changed since Microsoft officially released a port of OpenSSH for Windows however, among a large number of other Linux subsystems.

Instead of HTTP, use… HTTPS

In the same vein as FTP, HTTP (Hypertext Transfer Protocol) broadcasts its requests in the clear. HTTPS on the other hand goes the same route as FTPS where it is referred to as HTTP over TLS, securing the data through an encrypted channel. There are a multitude of reasons why organizations and companies want to secure data by default, and efforts such as the Electronic Frontier Foundation's (EFF) HTTPS Everywhere browser extension for users and Let's Encrypt for site operators have aided in this significantly.

While it may be difficult to justify the expense to upgrade in-house applications from HTTP to HTTPS, anything facing the web should make the jump as soon as possible.

Instead of SMB v1/v2, use… SMB v3

For internal file sharing, SMB (Server Message Block) has been around since the early 80's and has been made a standard for Windows for a very long time. The Open Source implementation of SMB known as Samba has allowed SMB to also be used across an enormous number of operating systems, making it one of the most important protocols running on our internal networks.

Unfortunately SMB version 1 is considered not secure by today's standards and has been disabled by default as of Windows Server 2016 and above. SMB Version 3 was released with Windows Server 2012, and has been steadily improved upon since then. As such, this is considered the best available version, with end-to-end encryption and integrity checking baked in.

Instead of Telnet, use… SSH

Telnet has been one of the foundations for troubleshooting and remote administration for an incredibly long time, but unfortunately it is also one of the most vulnerable programs still currently in use. It's primary purpose is to initiate a console connection to a remote device, which then allows for configuration modification, basic file transfers and other related functions.

Due to its potential for exploitation however, telnet has been replaced whenever possible by SSH since SSH can do everything that telnet can but through a secure channel.

Instead of SNMP v1/v2, use… SNMP v3

When it comes to getting real-time feedback about the status of devices on our network, SNMP (Simple Network Management Protocol) is exceptionally useful. It allows for regular polling of values from remote devices, which can be just about anything from printers, to cameras to standard servers.

SNMP v1 and v2 both are extremely useful, and SNMP v3 didn't really modify this core functionality much at all. What it did do through was add on authentication protocols and encryption. Support for SNMP v3 can be somewhat hit or miss depending on the age of the hardware involved, but if possible in your environment the upgrade is worth it.

Instead of SSL v1/v2/v3 and TLS 1.0/1.1 use… TLS 1.3

SSL has been replaced en masse by TLS for a significant number of security problems. Since SSL and TLS have been the backbone of security across the Internet and a large amount of the protocols listed above, knowing that this foundation is secure is critical. SSL 3.0 was depreciated in 2015, while TLS 1.0 and 1.1 were both depreciated in 2020. TLS 1.3 was released in 2018 and is the current standard, with 1.2 still available for legacy operations. 1.3 came with significant upgrades across the board along with removal of key aspects of backward compatibility.

Normally this would be a problem, however the main reason for this is to prevent forced downgrading of the protocol to an authentication method that is not considered secure. At the present time it is recommended that support for all versions of SSL be disabled in browsers.

Learn Network Security Fundamentals

Build your skills with seven hands-on courses covering network models and protocols, wireless and mobile security, network security best practices and more.

Start Learning

Conclusion

There are massive benefits to using secure protocols on our networks, but these do come at a potential price. If your environment is using active sniffing on all traffic, the use of secure protocols may require upgrading your monitoring software to support examination of secure traffic but the benefits far outweigh possible costs.

It is strongly recommended however that outside access to protocols such as SSH be restricted as much as possible to prevent further security risks.