The Plaintext Problem: Why FTP, Telnet, and SNMP v1 Should Be Gone by Now

The protocols that refuse to die

Every few years, somebody in the security community declares plaintext protocols dead. And every few years, the next penetration test proves otherwise. FTP on ports 20-21. Telnet on port 23. SNMP v1 and v2c on ports 161-162. HTTP on port 80. TFTP on port 69. The r-services family on ports 512-514. These protocols were designed in an era when the network itself was trusted, and they have never been updated to question that assumption.

The protocols themselves are not the problem. The problem is that they transmit credentials, commands, and data in cleartext, meaning anyone with access to the network path between source and destination can read everything. Not "could theoretically read" in some academic sense. Read, as in capture the packet, open it in Wireshark, and see the password in plain English.

If you run a packet capture on a network segment where FTP is in use, you will see USER and PASS commands in the clear within seconds. That is not a sophisticated attack. It is the equivalent of reading a postcard as it passes through the sorting office.

Why they are still everywhere

You would think that after three decades of warnings, plaintext protocols would have been replaced. They have not, and the reasons are surprisingly consistent across organisations of every size.

Legacy systems that cannot be upgraded. Manufacturing floor controllers running software from 2004. Medical devices with embedded Telnet interfaces that the vendor refuses to update. Mainframe systems where the FTP server is baked into the operating system and "SFTP is on the roadmap." These systems exist in every large enterprise, and they create pockets of plaintext traffic that persist for years because the cost of replacement is enormous and the risk feels theoretical.

The "it works" mentality. FTP transfers files. Telnet connects to devices. SNMP v1 collects metrics. They all do their jobs reliably. When an operations team is under pressure to keep systems running, replacing a working protocol with its encrypted equivalent feels like introducing risk rather than reducing it. The configuration is different. The authentication model changes. SSH keys need to be managed. There is real operational friction in the migration, and the benefit is invisible until something goes wrong.

Vendor requirements. Some vendors explicitly document FTP or Telnet as the supported method for firmware updates, log collection, or configuration backup. When your firewall vendor says "upload the firmware via TFTP," you either comply or void your support agreement. This creates a dependency chain where even security-conscious organisations are forced to maintain plaintext protocols because their security appliances require them.

The "it's only internal" argument. This is the most dangerous justification. The reasoning goes: plaintext is fine because the traffic never leaves the internal network, and the internal network is trusted. This argument ignores the reality that most breaches involve lateral movement through the internal network. An attacker who has compromised a single workstation can sniff traffic on the local segment. If that segment carries Telnet or FTP traffic, they now have credentials for every system that uses those protocols. "Internal only" is not a security boundary. It is a line on a diagram.

What actually happens on the wire

To understand why plaintext protocols are dangerous, you need to understand what an attacker actually sees. This is not theoretical. These are the literal packet contents.

FTP authentication. When a user connects to an FTP server, the client sends two commands in sequence: USER admin followed by PASS Summer2026!. These are transmitted as plain ASCII text in TCP packets. Any device on the network path, a compromised switch, a mirrored port, a rogue device on the same VLAN, captures these packets and reads them instantly. There is no encoding, no obfuscation, no hashing. The password travels the wire exactly as the user typed it.

Telnet sessions. Telnet is worse than FTP because it transmits everything, not just credentials. Every command typed, every response received, every password prompt and its answer. If you are using Telnet to manage network switches, an attacker watching the traffic sees not just your password but every configuration change you make. They learn your network topology, your VLAN assignments, your ACL structure, all from passively observing a single Telnet session. Each character is typically sent in its own packet as you type, which makes it trivially easy to reconstruct the entire session.

SNMP v1 and v2c community strings. SNMP v1 and v2c use "community strings" for authentication. These are, in practice, passwords sent in cleartext with every single SNMP request and response. The default community string on most devices is "public" for read access and "private" for write access. Even when organisations change these defaults, the new strings still travel the wire in plaintext. A captured SNMP community string with write access gives an attacker the ability to modify device configurations remotely. A read community string exposes your entire network topology, interface statistics, routing tables, and ARP caches. That is a complete map of your infrastructure, handed over in one protocol.

The r-services family. Rlogin, rsh, and rexec on ports 512-514 are perhaps the most alarming of the group. These protocols were designed for a time when network trust was based on IP addresses. The .rhosts and hosts.equiv files allow passwordless authentication based solely on the source IP. In modern terms, these are backdoors. An attacker who can spoof or occupy a trusted IP address gets shell access without any credential exchange at all. The traffic itself is unencrypted, so even the commands executed via rsh are visible to anyone on the path.

TFTP. TFTP on port 69 has no authentication mechanism whatsoever. It is a file transfer protocol that allows any client to read or write files without providing any credentials. It was designed for bootstrapping diskless workstations and downloading firmware. In practice, it is often used to transfer configuration files that contain credentials, SNMP community strings, and other sensitive data. A network device backing up its configuration via TFTP is broadcasting its secrets to anyone listening.

The migration path everyone already knows

The alternatives to every one of these protocols have existed for years. In most cases, for over two decades.

None of these alternatives are new or experimental. SSH has been available since 1995. SNMPv3 was standardised in 2004. HTTPS has been the default for web traffic for over a decade. The technical barriers to migration are low. The organisational barriers are where things stall.

The compliance angle you cannot ignore

Every major security framework explicitly calls out plaintext protocols. This is not a grey area or an interpretation question. The frameworks are direct.

PCI DSS requires encryption of cardholder data in transit. If any system in your cardholder data environment uses FTP, Telnet, or HTTP to transmit data, you are non-compliant. Full stop. Auditors will flag it, and "we have compensating controls" is an increasingly difficult argument to sustain when the encrypted alternatives are free and widely available.

CIS Controls include specific benchmarks for eliminating unencrypted protocols. The guidance is not "consider replacing" but "ensure that all remotely accessible services are using encrypted channels." Organisations benchmarking against CIS and still running Telnet for network device management are failing a foundational control.

NIST SP 800-53 addresses unencrypted protocols under multiple control families. The SC (System and Communications Protection) controls require confidentiality of transmitted information. Running SNMP v1 across your management network while claiming compliance with NIST is a contradiction that auditors will find.

The compliance risk alone should be enough to prioritise migration. But in many organisations, compliance is treated as a periodic exercise rather than a continuous state. The Telnet access that gets flagged in the audit gets disabled for the audit period and quietly re-enabled when the auditor leaves. This cycle continues until something breaks.

The real cost of "we'll get to it later"

Plaintext protocol risk compounds over time. Every month that FTP remains active is another month of credentials traversing the wire in cleartext. Every password change transmitted via Telnet is visible to anyone who has positioned themselves on the network. The exposure is continuous and cumulative.

Consider a mid-sized organisation with 200 network devices managed via Telnet and SNMP v2c. Each device is accessed by operations staff an average of twice per week. That is 400 Telnet sessions per week, each one transmitting administrative credentials in cleartext. The SNMP polling runs every 5 minutes, which means community strings cross the wire 57,600 times per day. If a single one of those sessions is captured by an attacker who has gained a foothold anywhere on the management network, they have credentials for every device.

The remediation cost after a breach involving plaintext credential capture is orders of magnitude higher than the migration cost. An emergency credential rotation across 200 devices, an incident response engagement, forensic analysis to determine what was accessed, regulatory notification if customer data was exposed, all of this because the migration to SSH and SNMPv3 was "on the backlog."

Where to start when you cannot replace everything at once

Most organisations cannot eliminate plaintext protocols overnight. Legacy systems, vendor dependencies, and operational constraints mean the migration will take months or years. That does not mean you should do nothing in the interim.

Inventory first. You cannot replace what you have not found. Run a port scan of your internal network looking for ports 20-23, 69, 80, 161-162, and 512-514. The results will almost certainly surprise you. Systems you forgot about, devices that predate your tenure, vendor appliances that default to Telnet. Build the list before you build the plan.

Segment and isolate. If a legacy system must use FTP or Telnet, put it on its own network segment with strict access controls. Limit which hosts can reach it. Monitor the traffic. This does not eliminate the risk, but it reduces the blast radius from "anyone on the network" to "anyone on this specific VLAN." That is a meaningful reduction.

Set firewall rules to block what you can. For protocols that have no business being on your network, create deny rules and log the hits. You may discover traffic you did not know existed. Tools like netbobr can help here. When you are validating firewall rules against security frameworks, netbobr flags rules that permit traffic to known insecure protocol ports, including FTP (PCI-NET-010), Telnet (PCI-NET-011), HTTP where HTTPS should be used (PCI-NET-012), SNMP v1/v2c (PCI-NET-014), TFTP (PCI-NET-018), and r-services (PCI-NET-019). On the framework side, CIS-NET-001 covers unencrypted protocols broadly, and NIST-NET-020 flags unencrypted protocol usage. Having these checks automated means plaintext protocol permissions do not slip through during rule reviews.

Prioritise by exposure. Not all plaintext protocol usage carries equal risk. SNMP v2c on a management VLAN with 5 hosts is a different risk profile than FTP exposed to 500 users across multiple sites. Rank your plaintext protocol instances by the number of credentials at risk, the sensitivity of the data in transit, and the breadth of network exposure. Migrate the highest-risk instances first.

Set a deadline and enforce it. Migration projects without deadlines become permanent backlog items. Pick a date. Communicate it. When the date arrives, disable the plaintext protocol even if migration is not complete for every system. The systems that have not migrated will break, and that will finally create the urgency that years of security recommendations could not. This sounds aggressive, but it is how every successful plaintext protocol elimination programme has worked in practice.

The conversation that needs to happen

The technical case for eliminating plaintext protocols has been settled for over twenty years. The alternatives exist. They are mature. They are free. The only thing keeping FTP, Telnet, and SNMP v1/v2c alive in your network is organisational inertia.

That inertia is not cost-free. Every day these protocols remain active, credentials are exposed on the wire. Every packet capture on a segment with plaintext traffic is a potential credential harvest. Every compliance audit that finds Telnet in the cardholder data environment is a finding that erodes trust with your assessors.

The question is not whether to migrate. It is whether you migrate on your own timeline or on the timeline an attacker sets for you. Running your firewall rules through netbobr is one way to find out where these protocols are still permitted in your ruleset before someone else does. But however you find them, the answer is the same: replace them, segment them, or accept the risk in writing. "We'll get to it later" is not a security strategy. It is a bet that nobody is watching the wire. And that is a bet you will eventually lose.