Telnet and RTSP: why camera and router admin ports end up exposed

Two old protocols, still everywhere

Telnet and RTSP have nothing in common at the protocol level — one is a remote text shell, the other is a video streaming control protocol — but they show up together constantly on the same class of devices: home routers, IP cameras, DVRs and NVRs. Both were designed decades ago for trusted, closed networks, and both are still commonly shipped turned on by default on cheap embedded hardware, because removing them or replacing them with an authenticated, encrypted alternative costs engineering time that low-margin consumer device manufacturers often don’t spend.

Telnet: a plaintext admin shell on port 23

RFC 854 defines Telnet as exactly what its name suggests — a protocol for remote terminal access. It sends everything, including any password you type, as unencrypted plaintext over the network, and its authentication (where it exists at all) is often a hardcoded or weak default credential set by the manufacturer rather than something the end user is prompted to change. That combination — administrative access, no encryption, predictable credentials — is precisely why Telnet-scanning became the foundation of one of the most consequential botnets in internet history.

The academic analysis of the Mirai botnet presented at USENIX Security 2017 documented the mechanism directly: Mirai “statelessly sent TCP SYN probes to pseudorandom IPv4 addresses… on Telnet TCP ports 23 and 2323,” then attempted logins using a dictionary of 62 common username and password pairs aimed specifically at consumer routers and IoT devices. Every successful login added one more device to the botnet, with no exploit required beyond a default password nobody had changed.

RTSP: an unauthenticated video feed on port 554

RTSP (Real-Time Streaming Protocol, see glossary definition), standardized in RFC 7826, is how a huge share of IP cameras and DVRs negotiate and control a live video stream. The protocol itself has no opinion on authentication or encryption — that’s left to the implementer — and in practice, a large number of camera firmware images expose an RTSP endpoint that streams video to anyone who knows (or guesses) the right URL path, sometimes with no credential check at all. Search engines that index internet-facing devices routinely turn up thousands of such feeds: home camera streams, retail store interiors, parking lots, left reachable because the installer connected the camera to the internet for remote viewing convenience and never locked down who else could view it.

Why these ports end up reachable from the internet in the first place

Three common paths lead to an exposed Telnet or RTSP port:

• The manufacturer’s default configuration binds the service to all network interfaces, not just the local network, so the moment the device gets a routable address it’s reachable.
• A user or installer forwards the port on their router specifically to enable remote camera viewing or remote admin access, without realizing that forwarding also exposes it to the entire internet, not just their own remote device.
• The device sits directly on a public IP with no router or firewall in front of it at all — more common for business or industrial deployments than home ones, but it still happens.

How to check and fix it

1. Confirm your actual public-facing IP. Use AdminKit’s what is my IP tool to see the address your network presents to the internet — this is the starting point for any exposure check, including deciding what to test next.
2. Test whether the ports actually respond from outside. If you expect a camera or router’s Telnet or RTSP port to be internal-only, confirm it from a connection outside your own network — a port that answers when it shouldn’t is the exposure itself, independent of whether anyone has exploited it yet.
3. Disable Telnet entirely if the device offers any alternative. Most modern router and camera firmware includes an SSH-based or web-based admin interface instead; use that and turn Telnet off in settings, not just change its password.
4. Change every default credential, on both the Telnet admin account and the RTSP stream’s viewing credentials if the device supports one — a disabled-by-default feature re-enabled with a default password buys you nothing.
5. Put remote access behind a firewall rule or VPN rather than a direct port forward. If you genuinely need to view a camera remotely, a VPN back into your own network keeps the RTSP stream itself off the public internet entirely, closing the exposure without losing the feature.

A note on whether you’re even reachable to begin with

Whether an open Telnet or RTSP port is actually dangerous also depends on whether your network is reachable from the public internet the way you think it is. If your ISP uses Carrier-Grade NAT, your router may not have a direct, stable public IP at all — see our CGNAT guide for what that means and how to check it. It’s not a substitute for disabling these services properly, but it’s useful context before assuming a given result means what it looks like at first glance.