10 Ways to Protect Protocols That Aren't DNS
Here's how to safeguard three other network foundation protocols so they don't become weapons or critical vulnerabilities.
July 16, 2018
![](https://eu-images.contentstack.com/v3/assets/blt6d90778a997de1cd/blt665aeb5f5c5b3dcf/64f0d55e19d32729aa672507/Image_1.jpg?width=700&auto=webp&quality=80&disable=upscale)
When an attack using a basic Internet protocol makes the news, it tends to focus on the Web, with either HTTP or DNS in a starring role. But history shows us that other protocols can be used as both weapons and doors for attacking vulnerable organizations.
Three different protocols — BGP, NTP, and FTP — are especially useful to threat actors looking to disrupt operations or steal assets from individuals and organizations. Recent incidents around cryptocurrency wallets show just how effective Border Gateway Protocol (BGP) hijacking can be as part of an attack plan. BGP's mystery, from most users' points of view, stems from its complexity and adds to the danger because most organizations only begin to work directly with BGP when their networks pass into the "very large" category.
Network Time Protocol (NTP) might seem like the sort of protocol that is merely convenient, allowing users to avoid listening for time announcements on the radio and typing the results into their systems, but everything from cryptography to file transfer depends on computers and network components getting authoritative time from a canonical server. This requirement makes NTP ubiquitous and valuable when it comes to wreaking havoc on a victim.
And while users tend to use HTTP far more than File Transfer Protocol (FTP) for moving files between systems, many applications and systems still use FTP as an essential mechanism. Because FTP is often used for transferring very large files, it becomes a powerful weapon when criminals are able to use it against a target.
"Stop using these protocols" isn't practical advice for most organizations; far too many applications and users depend on them to make abandonment anything but a very long-term solution — and in the case of BGP and NTP, no replacement is on the horizon. So it becomes necessary for companies to figure out how to protect the protocols so that they remain tools while not becoming weapons or critical vulnerabilities.
There are, of course, many ways to protect network foundation protocols, but a handful of suggestions may help spur thought and provide inspiration for moving defense forward. This list is intended to provide a jumping-off point for discussions on how an organization can protect itself and its Internet neighbors from harm through one of these protocols.
What steps has your organization taken to protect these essential protocols? If you have found a suggestion not on this list to be especially helpful, let us know in the comments, below. The online community is waiting to become more secure!
(Image: Tatiana Popova)
Black Hat USA returns to Las Vegas with hands-on technical Trainings, cutting-edge Briefings, Arsenal open-source tool demonstrations, top-tier security solutions and service providers in the Business Hall. Click for information on the conference and to register.
BGP is a way for routers to let other routers know where they are and for the routers, as a group, to establish the best way to send packets from one address to another. Part of the process is establishing that a router is still on the Internet: This is done via the speaker, which sends a TCP message on port 179 every 60 seconds to keep the connection to its neighbor alive. If the speaker is taken down, it not only disrupts the router's presence on the Internet, it also opens the door for a substitute, illegitimate router to be inserted in its place.
Obviously, a critical network link that communicates regularly on a known port is vulnerable, so network owners need to take special precautions to protect it. As a first step, the IETF recommends an access control list (ACL) that rejects traffic from any router not explicitly a neighbor.
Next, the network admin should instigate rate limiting on both the control and data planes so that a packet flood can't take the speaker off the network. Rate limiting should be put in place to protect against both attacks and an excessive volume of legitimate traffic that could take the network off the Internet.
Because BGP uses TCP as a transport, protecting BGP sessions means protecting TCP sessions, and most of the same mechanisms used for protecting general TCP can be used in BGP. This protection starts with blocking obviously spoofed packets at the network boundary using the recommendations in RFC 2827 and RFC 3704.
With packet blocking in place, MD-5 or the preferred TCP Authentication Option (TCP-AO) can provide positive protection.
All of these session protections carry costs in terms of deployment and maintenance. Individual network owners will need to weigh the security benefits against those costs. But the result of all four of these steps will be BGP functionality that is far more secure than it would be otherwise.
When securing NTP is important, there's an obvious first step: Replace "classic" NTP with NTPsec. A more secure NTP, NTPsec is directly compatible with the classic code and should provide no clue to users that anything has changed. It simply makes the foundation service much less vulnerable to exploitation by hackers. Among the goals of NTPsec is to make NTP less available to hackers as a tool in amplification DDoS attacks. There is wide consensus that it does that, as well as cleaning up code and adding basic management and reporting tools.
It must be noted that both NTP and NTPsec are open source projects. As such, they have attracted volunteers and proponents with strong opinions and emotions. It is not hard to find online opinions both for and against NTPsec, but on balance it seems that the basic functions of this protocol make it worthy of serious consideration in the enterprise.
NTP's main value as a weapon is that a specific query can return many times more data than was sent from the original attacking system. NTP is one of the protocols that is frequently deployed at system generation and then never touched again, leaving older versions of the server vulnerable and in place.
Every version of the NTP server software, ntpd server, prior to 4.2.7 is vulnerable to being used for this type of attack by default. More recent versions may still be vulnerable, but only through positive configuration, not by default. To enhance security, make sure that ntpd is up to date.
The command that makes ntpd such a powerful amplification is monlist, which returns the details of the last 600 clients to have attached to the NTP server.
Preventing NTP from becoming a weapon must include restricting execution of monlist. This restriction is in place by default on versions of ntpd after 4.2.7; if an installation must continue to use an earlier version, then the explicit instructions for the restriction must be added to ntp.conf.
FTP performs a task, but in its basic form is an archaic, blunt instrument. The most basic problem with the protocol is that nothing, from authentication to file transfer, happens with any encryption at all. If file transfer is required by an application or workflow, alternatives can provide the same function with much greater security.
The two most common alternatives to FTP are FTPS and SFTP. The two accomplish the same task: They send files (and the credentials pre-transfer) via encrypted tunnels. How they get there, though, is very different.
SFTP is FTP within SSH (Security Shell). FTPS is FTP with SSL (Secure Socket Layer). One is not inherently more secure than the other, so the decision to implement one instead of the other might well rest on the security of the presentation and transport that surrounds the need for FTP. Or developers could do what many teams have decided to do: implement both.
In many cases, FTP is implemented to allow partners, suppliers, or customers to transfer files to and from an organization. That means the FTP server must face the Internet, often in a demilitarized zone (DMZ) within the network architecture.
Servers of any sort that face the Internet are far more vulnerable than those that don't. That's why an FTP gateway that protects the FTP server is important if FTP functionality must be preserved. In most cases, the gateway is a variation on a reverse proxy in which the external client will initiate a session with the gateway, which will then establish a secure tunnel from the server to the external client.
There are many different options for an FTP gateway: AWS, IBM, Barracuda, and Ipswitch are just four of the companies that have different ways to provide the function.
In earlier, more innocent times, organizations would sometimes have a specific subdirectory assigned for sending and receiving files via FTP. Anonymous FTP would be allowed for both sending and receiving files that might stay in the subdirectory for extended periods, with full read-write privileges allowed.
A number of steps should be taken to protect the server and files that are involved in FTP: Limit rights to the subdirectory, limit permissions to the files that are placed in the subdirectory, and limit the contents of the subdirectory to those files that have just been uploaded or are needed for immediate downloading.
There is risk in any activity that happens on the public Internet. But by using available technology and appropriate policies, organizations can make many of those activities much safer.
In earlier, more innocent times, organizations would sometimes have a specific subdirectory assigned for sending and receiving files via FTP. Anonymous FTP would be allowed for both sending and receiving files that might stay in the subdirectory for extended periods, with full read-write privileges allowed.
A number of steps should be taken to protect the server and files that are involved in FTP: Limit rights to the subdirectory, limit permissions to the files that are placed in the subdirectory, and limit the contents of the subdirectory to those files that have just been uploaded or are needed for immediate downloading.
There is risk in any activity that happens on the public Internet. But by using available technology and appropriate policies, organizations can make many of those activities much safer.
When an attack using a basic Internet protocol makes the news, it tends to focus on the Web, with either HTTP or DNS in a starring role. But history shows us that other protocols can be used as both weapons and doors for attacking vulnerable organizations.
Three different protocols — BGP, NTP, and FTP — are especially useful to threat actors looking to disrupt operations or steal assets from individuals and organizations. Recent incidents around cryptocurrency wallets show just how effective Border Gateway Protocol (BGP) hijacking can be as part of an attack plan. BGP's mystery, from most users' points of view, stems from its complexity and adds to the danger because most organizations only begin to work directly with BGP when their networks pass into the "very large" category.
Network Time Protocol (NTP) might seem like the sort of protocol that is merely convenient, allowing users to avoid listening for time announcements on the radio and typing the results into their systems, but everything from cryptography to file transfer depends on computers and network components getting authoritative time from a canonical server. This requirement makes NTP ubiquitous and valuable when it comes to wreaking havoc on a victim.
And while users tend to use HTTP far more than File Transfer Protocol (FTP) for moving files between systems, many applications and systems still use FTP as an essential mechanism. Because FTP is often used for transferring very large files, it becomes a powerful weapon when criminals are able to use it against a target.
"Stop using these protocols" isn't practical advice for most organizations; far too many applications and users depend on them to make abandonment anything but a very long-term solution — and in the case of BGP and NTP, no replacement is on the horizon. So it becomes necessary for companies to figure out how to protect the protocols so that they remain tools while not becoming weapons or critical vulnerabilities.
There are, of course, many ways to protect network foundation protocols, but a handful of suggestions may help spur thought and provide inspiration for moving defense forward. This list is intended to provide a jumping-off point for discussions on how an organization can protect itself and its Internet neighbors from harm through one of these protocols.
What steps has your organization taken to protect these essential protocols? If you have found a suggestion not on this list to be especially helpful, let us know in the comments, below. The online community is waiting to become more secure!
(Image: Tatiana Popova)
Black Hat USA returns to Las Vegas with hands-on technical Trainings, cutting-edge Briefings, Arsenal open-source tool demonstrations, top-tier security solutions and service providers in the Business Hall. Click for information on the conference and to register.
About the Author(s)
You May Also Like
CISO Perspectives: How to make AI an Accelerator, Not a Blocker
August 20, 2024Securing Your Cloud Assets
August 27, 2024