Skip to content
AdminKit

Machine protocols

MQTT, Modbus, RDP, VNC and the other protocols your devices and legacy systems speak were mostly designed for trusted local networks, not the open internet — exposing one is a common way in for an attacker.

Tools (3)

All tools →

Guides (30)

All guides →

Glossary (33)

Full glossary →
  • ALPN (Application-Layer Protocol Negotiation) — ALPN (Application-Layer Protocol Negotiation) is a TLS extension, defined in RFC 7301, that lets a client and server agree which application protocol to run over a connection as part of the TLS handshake, before any application data is sent. A client's ClientHello lists the protocols it supports, ordered by preference -- h2 and http/1.1 are the pair that matters most in practice -- and the server picks one from that list, so neither side needs a separate round trip to find out which to use. This is what lets a single HTTPS port, 443, serve both HTTP/2 and plain HTTP/1.1 without guessing: a browser advertising h2 support gets routed to it directly, while an older client falls back to http/1.1 within that same handshake. Negotiation happens inside the same TLS handshake a certificate-and-cipher check like AdminKit's SSL/TLS check already performs, even though its result doesn't surface the negotiated protocol itself.
  • BACnet — BACnet (Building Automation and Control Networking protocol) is a communication standard used to connect and control building-automation equipment: HVAC systems, lighting, access control, fire and life-safety systems, and other building management hardware. BACnet/IP, the version that runs over standard IP networks on UDP port 47808, inherited the same trust assumption as other older industrial protocols -- that the network it runs on is isolated and trusted -- so it has no built-in authentication or encryption. A BACnet device reachable from the internet can typically be queried or commanded by anyone who finds it, which matters for buildings whose automation network wasn't deliberately segmented away from general internet access.
  • Certificate Transparency (CT) log — Certificate Transparency (CT) is a framework, defined in RFC 6962, that requires publicly trusted certificate authorities to publish every TLS certificate they issue into append-only, cryptographically verifiable logs before browsers will treat the certificate as valid. A CT log entry is permanent and publicly searchable, which means a certificate issued for a domain -- whether requested by its owner or mis-issued through a compromised or coerced validation process -- becomes visible to anyone who checks, even well after the fact if nobody was watching at issuance time. CT doesn't prevent mis-issuance or judge whether an issuance was authorized; it only guarantees a record exists, so the security benefit depends on someone actually reviewing a domain's logged certificates, for example through a public log search tool like crt.sh, rather than assuming the absence of an alert means nothing happened.
  • Cipher suite — A cipher suite is the specific combination of cryptographic algorithms a client and server agree to use for a TLS connection. TLS 1.3, defined in RFC 8446, simplified this: a cipher suite now names only an AEAD algorithm for protecting record data, such as AES-128-GCM, paired with a hash function used with HKDF for key derivation and handshake authentication, such as SHA-256, written together as TLS_AES_128_GCM_SHA256. This replaces TLS 1.2's longer names, which bundled a key-exchange and authentication method into the same string, since TLS 1.3 negotiates those separately. During the handshake, a client's ClientHello lists every cipher suite it supports, and the server's ServerHello picks one from that list; a server limited to outdated suites with known weaknesses exposes every connection to that weakness even when its certificate itself is completely valid.
  • CoAP — CoAP (Constrained Application Protocol, RFC 7252) is a lightweight, RESTful protocol built for low-power IoT and sensor devices, modeled on HTTP's GET/PUT/POST methods but running over UDP for a much smaller footprint than a full HTTP/TCP stack. It supports an optional encrypted and authenticated mode, DTLS, but ships and is frequently deployed without it enabled. Because CoAP runs over UDP and a small request to its resource-discovery endpoint can trigger a disproportionately large response, an exposed CoAP service is attractive for DDoS amplification attacks -- an attacker spoofs a victim's IP as the source and lets the amplified responses flood that victim, a pattern researchers have documented at scale since 2019, with hundreds of thousands of exposed devices found in internet-wide scans. The device itself can also be at risk, independent of its use in an attack on someone else.
  • Content-Security-Policy (CSP) — Content-Security-Policy (CSP) is an HTTP response header, specified by the W3C's Content Security Policy standard, that lets a site declare which sources of scripts, styles, images and other resources a browser is allowed to load, enforced by the browser regardless of what a page's own HTML or any injected markup requests. Its main practical use is mitigating content-injection attacks like cross-site scripting: a directive such as script-src 'self' gives granular control over inline script execution and dynamic code execution via eval(), stopping an injected <script> tag from running even if an attacker manages to insert one into the page. A directive is a name -- script-src, default-src as the fallback for unspecified types, frame-ancestors, and others -- followed by a list of allowed sources; the specification is explicit that CSP is not a replacement for careful input validation and output encoding, only an additional layer.
  • CSR (Certificate Signing Request) — A CSR (Certificate Signing Request) is the file a server operator generates and sends to a certificate authority to request a TLS certificate, structured according to RFC 2986's PKCS #10 format. It bundles the public key the certificate will cover, the requested subject details (commonly the domain name), and a signature made with the matching private key, which proves the requester actually holds that private key without ever sending it anywhere. The CA uses the CSR's public key and subject information to build the issued certificate, then separately verifies the requester actually controls the domain before issuing it -- the CSR itself only proves key possession, not domain ownership. Generating a new CSR also generates a new key pair, which is why rotating a certificate's private key means creating and submitting a fresh CSR rather than reusing an old one.
  • Docker Remote API — The Docker Remote API (also called the Docker Engine API) is the HTTP interface the Docker daemon exposes for creating, starting and inspecting containers, documented directly in Docker's own API reference rather than an IETF or ISO standard. IANA registers TCP port 2375 for it in plaintext and 2376 for the TLS-secured version, but the API itself carries no authentication of its own -- Docker's documentation assumes a trusted local Unix socket or a properly configured TLS client-certificate setup, never a bare network port. Because the daemon runs as root and can mount a host's filesystem into any container it starts, a Remote API reachable on port 2375 without TLS gives an unauthenticated caller the equivalent of a root shell on the host, which is why cryptomining campaigns scan for it continuously rather than treating it as a minor misconfiguration.
  • Elasticsearch HTTP API — Elasticsearch exposes its search, indexing and cluster-administration functionality through a RESTful HTTP API rather than a binary wire protocol -- every request and response is plain JSON over HTTP, normally on port 9200, Elastic's own documented default rather than an IANA-assigned port. Before version 8.0, Elastic's security features (authentication, role-based access control, TLS) were part of a separate tier and disabled by default, so a freshly started node answered any HTTP request on that port with no credential required at all. Elastic's own 8.0 release notes confirm security is now enabled by default for self-managed clusters, closing that specific gap for new deployments. The ongoing risk is almost entirely inherited: clusters deployed on an older version, or ones where security was manually disabled during setup for convenience, that were never revisited -- which is how researchers keep finding large, completely open Elasticsearch indices.
  • Honeypot — A honeypot is a deliberately exposed decoy system -- a fake server, service, or device -- set up to attract scanning and attack traffic so defenders can observe attacker behavior, techniques, and targets without putting any real system or data at risk. Because a honeypot has no legitimate business purpose, essentially all traffic that reaches it is unsolicited scanning, probing, or attack activity, which makes honeypot data useful for understanding what's actively being targeted on the internet right now -- which ports, which protocols, which known exploits -- rather than relying on theoretical risk alone. Honeypot and sensor networks are a common way security researchers and vendors gather real-world threat intelligence.
  • HSTS preload list — The HSTS preload list is a hardcoded list baked directly into Chrome's source code -- and, via lists derived from it, into Firefox, Safari and other major browsers -- that forces every connection to a listed domain onto HTTPS from the very first request a browser ever makes to it, with no prior visit required. It exists to close a gap in RFC 6797's HTTP Strict Transport Security (HSTS) header: HSTS only takes effect after a browser has already seen the header once over a successful HTTPS connection, leaving a domain's very first connection unprotected if it happens to start over plain HTTP. A site submits itself for preloading at hstspreload.org, but every current and future subdomain must support HTTPS indefinitely first, since both addition and removal from the list take months to propagate through browser release cycles.
  • LDAP — LDAP (Lightweight Directory Access Protocol, RFC 4511) is used to query and update directory services -- most commonly Active Directory -- that store user accounts, group memberships, and authentication data for an organization. Plain LDAP on port 389 transmits queries and, critically, the bind credentials used to authenticate, without encryption by default, unless the connection is upgraded with STARTTLS or run over the separate LDAPS port (636) with TLS from the start. A directory service reachable from the open internet over unencrypted LDAP exposes authentication traffic to interception and gives an external attacker a direct path to probe an organization's user and group structure, information normally only reachable from inside the corporate network. Directory services are meant to sit behind a firewall or VPN, not be directly internet-facing, regardless of which LDAP variant is in use.
  • Modbus/TCP — Modbus/TCP is the TCP/IP version of Modbus, a decades-old industrial communication protocol used to read and write values -- sensor readings, relay states, setpoints -- on programmable logic controllers (PLCs) and other industrial equipment, typically over port 502. It was designed in an era when industrial networks were assumed to be physically isolated, so the protocol itself has no authentication, authorization, or encryption built in: whoever can reach a Modbus/TCP device on the network can read its registers and, in many configurations, write to them too. Modern industrial networks are increasingly connected to the broader internet, directly or via misconfigured firewalls, which exposes this decades-old assumption as a real risk rather than a theoretical one.
  • MongoDB wire protocol — The MongoDB wire protocol is the message format MongoDB's own drivers and the mongosh shell use to communicate with a mongod or mongos process over TCP, normally on port 27017, which IANA registers for MongoDB. It's MongoDB-specific rather than a shared database standard, documented directly in MongoDB's manual rather than an independent spec body. Before version 3.6, MongoDB's binaries bound to all network interfaces with authentication off by default, so a server stood up with no extra configuration spoke this protocol to anyone who could reach it over the network -- the exposure a wave of 2017 ransom attacks exploited at scale, wiping tens of thousands of unauthenticated instances. Since 3.6, MongoDB binds to localhost by default, so an internet-reachable port 27017 today usually means an administrator deliberately widened net.bindIp, often without also enabling authentication.
  • MQTT — MQTT (Message Queuing Telemetry Transport) is a lightweight publish/subscribe messaging protocol designed for constrained devices and unreliable networks, which is why it became the default choice for a huge range of IoT products -- sensors, smart-home hubs, industrial telemetry. Devices publish messages to named "topics" on a central broker, and other devices subscribe to the topics they care about, without needing to know each other's addresses directly. The default configuration in many consumer and even some industrial products ships with no authentication and no encryption on its standard port, 1883, meaning anyone who can reach the broker can read or inject messages on any topic unless it's been explicitly locked down.
  • NTP (Network Time Protocol) — NTP (Network Time Protocol) is a protocol, defined in RFC 5905, for synchronizing a device's clock against time servers arranged in a hierarchy of strata -- stratum 0 reference clocks, stratum 1 servers attached to them, and successive strata synchronizing from the stratum above. Most operating systems run an NTP client by default, quietly correcting clock drift in the background, which is why accuracy rarely gets a second thought until it's wrong. It matters beyond simply showing the right time: DNSSEC's RRSIG records carry explicit inception and expiration timestamps, and a device whose clock has drifted far enough can reject a valid signature as expired, or accept one that has genuinely expired, purely because its own idea of the current time is wrong. TLS certificate validity checks rest on the same assumption -- an inaccurate clock undermines a check that has nothing else wrong with it.
  • OCSP stapling — OCSP stapling is a way of proving a TLS certificate hasn't been revoked without the connecting client having to contact the certificate authority itself. Normally, checking revocation with the Online Certificate Status Protocol (OCSP) means the client makes a separate request to the certificate authority's responder every time it validates a certificate, which adds latency, leaks which sites a client visits to that authority, and fails unpredictably when the responder is slow or unreachable. With stapling, the server itself periodically fetches a signed, time-stamped OCSP response and attaches ("staples") it directly to the TLS handshake, so the client can verify revocation status from data the server already provided, with no extra round trip or third-party query. It requires server-side support and periodic refreshing of the staple, since a stale one is treated as if no stapling happened at all.
  • PostgreSQL wire protocol — The PostgreSQL wire protocol, documented as the "frontend/backend protocol" in PostgreSQL's own manual, is the message format a client or driver uses to open a connection, authenticate, send queries and receive results over TCP, normally on port 5432, the port IANA registers for PostgreSQL. It's a protocol specific to PostgreSQL rather than an open, cross-database standard, which is why a MySQL or MongoDB driver can't speak to a PostgreSQL server directly. Because the protocol itself doesn't enforce where a server listens, PostgreSQL's security depends on two separate settings working together: listen_addresses, which controls which network interfaces the server binds to, and pg_hba.conf, which controls who may authenticate once a connection reaches it. PostgreSQL defaults to listening on localhost only, so a server reachable on 5432 from the internet means that default was deliberately changed.
  • RDP (Remote Desktop Protocol) — RDP (Remote Desktop Protocol) is Microsoft's protocol for remotely controlling a Windows machine's full graphical desktop over the network, typically on port 3389, letting a user see the remote screen and operate the keyboard and mouse as if sitting at it. Unlike Telnet, RDP does support encryption and authentication, but a weak or reused password, an unpatched vulnerability, or a port left open to the entire internet rather than restricted to a VPN turns it into one of the most consistently targeted services online -- mass scanners and brute-force tools treat an open port 3389 as a standing invitation. Security guidance generally recommends never exposing RDP directly to the internet, instead requiring a VPN or similar gateway before a connection can even reach it.
  • Redis protected mode — Protected mode is a safety feature Redis has enabled by default since version 3.2.0, intended to limit the damage of RESP's lack of built-in authentication. When a Redis instance starts with no password set and a bind address that isn't restricted to loopback, protected mode automatically refuses connections from any client that isn't connecting from localhost, per Redis's own documentation. It is not a substitute for setting a password with Redis's AUTH mechanism or Access Control Lists -- an administrator can disable protected mode explicitly, bind Redis to a public interface deliberately, or change the bind address without realizing the two settings interact, and any of those reintroduce the original no-password exposure. Because protected mode is a configuration default rather than a protocol-level control, whether it's still active on a given instance has to be checked directly, not assumed.
  • Referrer-Policy — Referrer-Policy is an HTTP response header, specified by the W3C's Referrer Policy standard, that controls how much of the current page's URL a browser includes in the Referer header of requests it triggers to other origins -- loading an image, following a link, or submitting a form. Defined values range from no-referrer, which omits the header entirely, through origin, which sends only the scheme, host and port, to same-origin, which sends the full URL only to the page's own origin. Modern browsers default to strict-origin-when-cross-origin when no header is set: it sends the full URL to same-origin destinations, only the origin across origins, and nothing at all when a request would downgrade from HTTPS to plain HTTP. Without an explicit, stricter policy, a page's own URLs -- which can carry session tokens or search terms in the path or query string -- may leak to every third-party resource it loads.
  • RESP (Redis Serialization Protocol) — RESP (REdis Serialization Protocol) is the wire protocol Redis clients and servers use to exchange commands and replies, typically over port 6379. It's a simple, text-based format -- each message type (simple string, error, integer, bulk string, array) starts with a distinct prefix character -- which makes RESP easy for client libraries to parse, and it's defined by Redis's own documentation rather than an IETF RFC the way DNS or SMTP is. RESP itself carries no authentication: Redis's documentation describes it as designed for trusted clients on trusted networks, so anyone who can open a RESP connection can issue any command the server accepts. This is why an internet-reachable Redis port with no password set is an immediately exploitable misconfiguration, not a minor gap -- a 2018 Imperva study found roughly 75% of the open Redis instances it scanned already infected with malware.
  • RTSP — RTSP (Real-Time Streaming Protocol, RFC 7826, originally RFC 2326) is a control protocol IP cameras, NVRs, and video doorbells use to negotiate and manage a live video stream, typically on port 554. RTSP itself defines no mandatory authentication or encryption; whether a stream requires a username and password is up to the device's implementation, and many consumer and budget cameras ship with it disabled or not configured. A camera with port 554 reachable from the public internet and no authentication enabled lets anyone who finds it watch the live feed -- a widely publicized 2014 index of roughly 73,000 unprotected cameras, most exposing a feed over RTSP or a similarly unauthenticated stream, demonstrated how common this exposure is in practice. Checking whether an RTSP port is reachable from outside the network, and enabling the device's authentication, are the two basic fixes.
  • SAN (Subject Alternative Name) — SAN (Subject Alternative Name) is an X.509 certificate extension, defined in RFC 5280, that lists every hostname (and optionally IP address) a certificate is valid for, as one or more DNS name entries attached to the certificate alongside its subject field. Modern browsers and TLS libraries check the SAN list, not the certificate's subject Common Name, to decide whether a certificate matches the hostname being connected to -- the CN field is effectively legacy and ignored for this purpose in current clients, a change the CA/Browser Forum's baseline requirements formalized industry-wide. A single certificate's SAN list can cover multiple distinct hostnames, including a wildcard entry like *.example.com alongside the bare apex domain, which is how one certificate commonly serves both a site and its subdomains. A certificate presented for a hostname absent from its SAN list fails hostname verification even if every other part of the chain is valid.
  • SNMP — SNMP (Simple Network Management Protocol, RFC 1157, with the SNMPv3 security model defined in RFC 3411) is used to monitor and configure network equipment -- routers, switches, printers, and other managed devices -- by reading and writing values from a device's management information base. SNMPv1 and v2c authenticate requests with a plaintext "community string" (often left at the vendor default, commonly "public" for read access), sent unencrypted and with no protection against an attacker guessing or sniffing it; SNMPv3 added real authentication and encryption, but many devices still ship or get deployed with the older, weaker versions enabled for compatibility. A device that answers SNMP queries from the open internet, especially with a default community string, can leak configuration and network-topology details, or in some implementations have its configuration changed by anyone who can reach it.
  • SSDP — SSDP (Simple Service Discovery Protocol) is the discovery mechanism behind UPnP: devices multicast short UDP messages on port 1900 to announce themselves or to ask "who else is here" for things like media servers, smart TVs, printers, and routers on a local network. It is meant to stay inside the local network, since its whole purpose is letting devices find each other without any manual configuration. The security problem appears when a router or device answers SSDP queries from outside the local network as well: because SSDP replies can be considerably larger than the request that triggered them, an internet-reachable SSDP responder can be abused as a UDP amplification source in distributed denial-of-service attacks, and large waves of such abuse involving consumer routers have been documented publicly. Devices should only ever process SSDP traffic from their own local network segment, never from the public internet.
  • Telnet — Telnet (RFC 854) is a protocol for opening a remote terminal session over a network, typically on port 23, letting a user type commands on one machine and run them on another. It predates modern transport security by decades and carries no encryption at all: a username, password, and every subsequent keystroke are sent in plain text, readable by anyone who can observe the traffic. This made Telnet the standard remote-access method for routers, switches, and embedded devices for years, and many of those devices, along with industrial and IoT equipment, still ship with Telnet enabled by default. SSH replaced Telnet for interactive remote access decades ago precisely because it adds encryption and authentication Telnet never had, so a reachable Telnet port today is usually a sign of outdated or neglected configuration rather than an intentional choice.
  • TLS SNI (Server Name Indication) — Server Name Indication (SNI) is a TLS extension, defined in RFC 6066, that lets a client state which hostname it is trying to reach inside the initial ClientHello message, before the TLS handshake completes. It exists because a server hosting multiple HTTPS sites on one IP address otherwise has no way to know which certificate to present until after the encrypted session is already being negotiated; SNI lets it pick the right one up front, which is what makes shared-IP HTTPS hosting practical at scale. Because the ClientHello is sent before encryption is established, a plain SNI value is visible in cleartext to anything observing the connection, revealing which site a client is visiting even though the rest of the session is encrypted -- the gap Encrypted Client Hello (ECH, RFC 9849) is designed to close, though deployment still varies widely by browser and server.
  • TR-069 — TR-069, also called CWMP (CPE WAN Management Protocol), is a standard ISPs use to remotely configure, update firmware on, and diagnose customer-premises equipment like routers and modems, typically listening on port 7547. It's legitimate and widely deployed infrastructure, not inherently a vulnerability -- but a misconfigured or outdated TR-069 implementation reachable from the public internet, rather than restricted to the ISP's own management network, has been the root cause of real, large-scale router-compromise incidents, including Mirai-related attacks in 2016 that exploited exposed TR-069 services to install botnet malware at scale. Whether a device's TR-069 port is reachable only from the ISP's network or from the broader internet is the key distinction for assessing risk.
  • UPnP — UPnP (Universal Plug and Play) is a set of networking protocols that let devices on a local network discover each other and configure services without manual setup, most notably asking the router to open a port-forwarding rule on their behalf. A game console, camera, or video call app can use UPnP's Internet Gateway Device protocol to punch a hole through NAT the moment it needs one, which is convenient but means any device or malware on the local network can request inbound exposure without the owner reviewing or even noticing the new rule. Because UPnP requests are trusted by default and rarely logged, it has repeatedly been implicated in consumer device compromises and in exposing services never meant to be internet-reachable. Routers that support UPnP typically let it be disabled, after which port forwarding has to be configured manually.
  • User-Agent — The User-Agent header is an HTTP request field, defined in RFC 9110 section 10.1.5, that lets a client identify the software making the request -- conventionally a string of product names and versions, such as a browser name, its rendering engine, and the operating system it runs on. Servers and clients both use it informally: RFC 9110 notes that servers often scan the User-Agent value, and clients often scan a server's own Server field, to work around known bugs or poorly chosen defaults in a specific version, rather than as part of any formal negotiation. Because the field is client-supplied, with no fixed schema beyond a list of product tokens and comments, it can be spoofed, omitted, or trimmed, which is why some browsers now send a shorter, less detailed User-Agent string by default for privacy.
  • VNC (Virtual Network Computing) — VNC is a cross-platform protocol for remotely viewing and controlling another computer's graphical desktop, built on the RFB (Remote Framebuffer) protocol (RFC 6143) and typically reachable on port 5900. Like RDP, it sends the full screen image and keyboard/mouse input over the network, letting a user operate a remote machine as if sitting in front of it, with implementations available across Windows, macOS, Linux and embedded systems. VNC's original "classic" authentication scheme has a legacy weakness RFC 6143 itself documents: the password is truncated to 8 characters and used as a DES key, which the RFC calls "known to be cryptographically weak." Modern VNC servers can run over TLS or inside an SSH tunnel instead, but a server left on classic authentication and exposed directly to the internet is a well-documented ransomware entry point, the same risk category as an exposed RDP port.
  • Zero trust — Zero trust is a security model built on the assumption that no device, user, or network segment should be trusted by default, including ones already inside a traditional network perimeter -- every request must be authenticated, authorized, and verified on its own merits, continuously, rather than once at the network's edge. This is a direct response to the failure mode of older "castle and moat" designs, where anything that got past the firewall was then implicitly trusted to reach internal systems. In practice, zero trust shows up as per-request identity verification, least-privilege access scoped narrowly to what's needed, and replacing direct network-level access, like exposing RDP or a VPN to a whole subnet, with brokered, identity-aware connections to individual resources.

Comparisons (1)

All comparisons →

Solutions (1)

All solutions →

Related clusters

AI agents & MCP

The Model Context Protocol lets AI agents call tools and read resources over a network connection, which means an unauthenticated or misconfigured MCP server can hand an agent — or an attacker — more access than intended.

Security basics

TLS certificates, HTTP security headers and open ports are the fundamentals every internet-facing service should get right, independent of which protocol or cloud it runs on.

See all six clusters →

Frequently asked questions

What belongs in the Machine protocols cluster?

MQTT, Modbus, RDP, VNC and the other protocols your devices and legacy systems speak were mostly designed for trusted local networks, not the open internet — exposing one is a common way in for an attacker. This hub lists every AdminKit tool, guide, glossary term, comparison and solution tagged with this cluster.

How does Machine protocols relate to AI agents & MCP and Security basics?

AI agents & MCP — The Model Context Protocol lets AI agents call tools and read resources over a network connection, which means an unauthenticated or misconfigured MCP server can hand an agent — or an attacker — more access than intended. Security basics — TLS certificates, HTTP security headers and open ports are the fundamentals every internet-facing service should get right, independent of which protocol or cloud it runs on.