{
"entries": [
{
"port": 1,
"protocol": "tcp",
"service": "TCPMUX",
"oneLiner": "A 1988 service multiplexer: connect, send a service name, and the server hands you that service on the same socket.",
"whatItIs": "TCPMUX lets a host offer many small services behind one port. A client connects to 1, sends a service name terminated by CRLF, and the server replies '+' or '-' before handing the connection to the named service. It shipped as an inetd built-in on several classic UNIX systems and is effectively extinct today. Anything answering on port 1 is either a deliberately exotic setup or a scanner artifact, and the port is a routine early entry in mass port sweeps.",
"exposure": {
"verdict": "never",
"note": "By design it is a directory that dispatches into other local services, so exposing it exposes whatever is registered behind it."
},
"checkCommand": "sudo lsof -nP -iTCP:1 -sTCP:LISTEN",
"links": [
{
"title": "RFC 1078 — TCP Port Service Multiplexer (TCPMUX)",
"url": "https://www.rfc-editor.org/rfc/rfc1078.html",
"kind": "spec"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 3,
"protocol": "tcp",
"service": "Reserved (formerly compressnet)",
"oneLiner": "Reserved at IANA — the old compressnet registration was de-assigned in 2025.",
"whatItIs": "Port 3 carried the 'compressnet' Compression Process registration for decades, alongside port 2 for its management utility. IANA de-assigned both on 2025-02-13 and now marks them Reserved, so no service owns this number. There is no protocol here to speak of and no software in common use that binds it. If a scan shows port 3 open, the service is unidentified and you have to fingerprint it directly.",
"exposure": {
"verdict": "careful",
"note": "Nothing is registered here, so an open port 3 is an unidentified listener — identify what owns the socket before deciding anything."
},
"checkCommand": "nc -vz TARGET 3",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 4,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned at IANA — no registered service, nothing standard listens here.",
"whatItIs": "IANA lists port 4 as Unassigned for both TCP and UDP, with no assignee and no history of a well-known service. No mainstream daemon binds it by default. Anything listening on 4 is custom software or a deliberately unusual configuration, and the only way to know what it is, is to fingerprint the listener and check which process owns the socket locally.",
"exposure": {
"verdict": "careful",
"note": "An unregistered low port that is open is an unidentified service; treat it as unknown until you have named the process."
},
"checkCommand": "sudo lsof -nP -iTCP:4 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 6,
"protocol": "both",
"service": "Unassigned",
"oneLiner": "Unassigned at IANA — no registered service, no common squatter.",
"whatItIs": "IANA lists port 6 as Unassigned on both TCP and UDP. It has no assignee, no reference document, and no daemon that binds it as a default. The number is easy to confuse with IP protocol number 6, which is TCP itself, but that is a different registry entirely. A listener here is bespoke, and identifying the owning process is the only reliable step.",
"exposure": {
"verdict": "careful",
"note": "Unregistered, so an open port 6 tells you nothing on its own; name the process before judging exposure."
},
"checkCommand": "sudo lsof -nP -iTCP:6 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 7,
"protocol": "both",
"service": "Echo",
"oneLiner": "Echo — the server sends back every byte you send it, one of the original inetd debugging services.",
"whatItIs": "Echo is defined in RFC 862: over TCP the server returns the stream unchanged until the client closes, and over UDP it returns each datagram to its sender. It exists as a reachability and round-trip test from the era before ping and traceroute were universal, and it shipped as an inetd or xinetd built-in on classic UNIX. Modern distributions ship it disabled. Its UDP form is a documented reflection and amplification vector, because a spoofed source address gets an equal-sized reply sent to the victim.",
"exposure": {
"verdict": "never",
"note": "The UDP form is a spoofable reflector documented in CISA's amplification-attack alert, and the service has no legitimate internet-facing use."
},
"checkCommand": "printf 'hello\\n' | nc -v TARGET 7",
"links": [
{
"title": "RFC 862 — Echo Protocol",
"url": "https://www.rfc-editor.org/rfc/rfc862.html",
"kind": "spec"
},
{
"title": "CISA Alert — UDP-Based Amplification Attacks",
"url": "https://www.cisa.gov/news-events/alerts/2014/01/17/udp-based-amplification-attacks",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 9,
"protocol": "both",
"service": "Discard",
"oneLiner": "Discard — a black hole that accepts everything you send and replies with nothing.",
"whatItIs": "RFC 863 defines Discard as a service that reads and throws away all data with no response, on TCP and UDP alike. It was built as a throughput and sink test for network stacks, and it shipped alongside echo, daytime and chargen as an inetd built-in. It is disabled by default on modern systems. Port 9 is also the conventional destination for Wake-on-LAN magic packets over UDP, which is why WoL tooling references it even though no discard server is involved.",
"exposure": {
"verdict": "careful",
"note": "Harmless in content since it never replies, but it is an unnecessary listener; there is no reason to expose it deliberately."
},
"checkCommand": "printf 'sink this\\n' | nc -v TARGET 9",
"links": [
{
"title": "RFC 863 — Discard Protocol",
"url": "https://www.rfc-editor.org/rfc/rfc863.html",
"kind": "spec"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 13,
"protocol": "both",
"service": "Daytime",
"oneLiner": "Daytime — connect and the server prints the current date and time as human-readable text, then hangs up.",
"whatItIs": "RFC 867 specifies Daytime as an ASCII time-of-day string returned on connect, with no request format and no defined layout for the string itself. NIST still runs it on time.nist.gov as part of the Internet Time Service, in a fixed format that includes a Modified Julian Date and a UTC timestamp. It was an inetd built-in on classic UNIX and is off by default on modern systems. Because the string is unstructured and unauthenticated, it is a curiosity rather than a way to set a clock — NTP is.",
"exposure": {
"verdict": "careful",
"note": "It leaks nothing worse than the host clock, but the UDP form is a spoofable reflector and the service has no modern purpose outside a deliberate public time service."
},
"checkCommand": "nc -v time.nist.gov 13",
"links": [
{
"title": "RFC 867 — Daytime Protocol",
"url": "https://www.rfc-editor.org/rfc/rfc867.html",
"kind": "spec"
},
{
"title": "NIST Internet Time Service (ITS)",
"url": "https://www.nist.gov/pml/time-and-frequency-division/time-distribution/internet-time-service-its",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 17,
"protocol": "both",
"service": "QOTD (Quote of the Day)",
"oneLiner": "QOTD — connect and get a short quotation, then the connection closes.",
"whatItIs": "RFC 865 defines QOTD as a service that returns a short ASCII quote, capped at 512 characters, with no request syntax. It shipped as an inetd built-in and as a Windows 'Simple TCP/IP Services' component, usually sourced from a local fortune file. It has no operational use and is disabled by default everywhere. Its UDP form is one of the reflection vectors named in CISA's amplification alert, since a small spoofed datagram triggers a larger reply to the victim.",
"exposure": {
"verdict": "never",
"note": "Named as a UDP amplification vector by CISA, and there is no use case that justifies leaving it reachable."
},
"checkCommand": "nc -v TARGET 17",
"links": [
{
"title": "RFC 865 — Quote of the Day Protocol",
"url": "https://www.rfc-editor.org/rfc/rfc865.html",
"kind": "spec"
},
{
"title": "CISA Alert — UDP-Based Amplification Attacks",
"url": "https://www.cisa.gov/news-events/alerts/2014/01/17/udp-based-amplification-attacks",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 19,
"protocol": "both",
"service": "CHARGEN (Character Generator)",
"oneLiner": "CHARGEN — an endless stream of printable characters, and a classic DDoS amplification source.",
"whatItIs": "RFC 864 defines CHARGEN as a test service: over TCP it sends an unending pattern of ASCII characters until the client disconnects, and over UDP it answers each datagram with a random-length payload of up to 512 characters. It was written to exercise packet generation and printer paths, and shipped as an inetd built-in and a Windows Simple TCP/IP Services component. It is disabled by default on modern systems. Its UDP form is one of the most abused reflectors on the internet because a tiny spoofed request produces a much larger reply aimed at the victim.",
"exposure": {
"verdict": "never",
"note": "A documented high-ratio UDP amplification vector in CISA's alert; an internet-reachable CHARGEN server is a weapon pointed at third parties."
},
"checkCommand": "nc -v TARGET 19 | head -c 200",
"links": [
{
"title": "RFC 864 — Character Generator Protocol",
"url": "https://www.rfc-editor.org/rfc/rfc864.html",
"kind": "spec"
},
{
"title": "CISA Alert — UDP-Based Amplification Attacks",
"url": "https://www.cisa.gov/news-events/alerts/2014/01/17/udp-based-amplification-attacks",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 20,
"protocol": "tcp",
"service": "FTP data",
"oneLiner": "The data channel for classic active-mode FTP; the file bytes move here, not on 21.",
"whatItIs": "An active-mode FTP server opens a connection *from* its own port 20 back to a client-chosen port to carry directory listings and file contents, while commands stay on port 21. Passive mode, which most modern clients and NATs use, abandons port 20 entirely for high ephemeral ports. On a scan you rarely see 20 listening; you see it in packet captures or firewall logs next to an FTP server. Seeing it at all means someone is running active-mode FTP, usually an old appliance or a batch file-transfer job.",
"exposure": {
"verdict": "careful",
"note": "Only meaningful alongside port 21, and it inherits FTP's cleartext problem unless the session negotiated TLS per RFC 4217."
},
"checkCommand": "sudo tcpdump -ni any tcp port 20",
"links": [
{
"title": "RFC 959 — File Transfer Protocol (FTP)",
"url": "https://www.rfc-editor.org/rfc/rfc959.html",
"kind": "spec"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "ProFTPD source repository",
"url": "https://github.com/proftpd/proftpd",
"kind": "github"
}
]
},
{
"port": 21,
"protocol": "tcp",
"service": "FTP",
"oneLiner": "FTP's command channel — logins and commands in cleartext, with data moving on a second connection.",
"whatItIs": "A client connects to 21, gets a text banner, and sends commands like USER, PASS, LIST and RETR; the server answers with three-digit codes. Every byte, including the password, is plaintext unless the session upgrades with AUTH TLS (RFC 4217). It appears on scans from vendor appliances, printers, build drops, and legacy anonymous mirrors. Its banner leaks the exact server and version, which is why it is a favorite first target on any scan.",
"exposure": {
"verdict": "careful",
"note": "Acceptable internet-facing only as anonymous read-only or with TLS enforced; authenticated cleartext FTP on a public IP hands over credentials."
},
"checkCommand": "printf 'QUIT\\r\\n' | nc -v ftp.gnu.org 21",
"links": [
{
"title": "RFC 959 — File Transfer Protocol (FTP)",
"url": "https://www.rfc-editor.org/rfc/rfc959.html",
"kind": "spec"
},
{
"title": "RFC 4217 — Securing FTP with TLS",
"url": "https://www.rfc-editor.org/rfc/rfc4217.html",
"kind": "spec"
},
{
"title": "ProFTPD source repository",
"url": "https://github.com/proftpd/proftpd",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 22,
"protocol": "tcp",
"service": "SSH",
"oneLiner": "SSH — encrypted remote login, remote command execution, and the transport under scp/sftp and git-over-ssh.",
"whatItIs": "sshd listens on 22, exchanges a version banner, then runs a key exchange that authenticates the server by host key and the user by public key, password, or keyboard-interactive. On top of that transport ride interactive shells, port forwards, sftp, and `git@host` clones. It is on essentially every Linux and BSD host and on macOS when Remote Login is enabled. On a public IP it gets continuous automated password-guessing traffic, which is noise, not a breach.",
"exposure": {
"verdict": "fine",
"note": "Safe to expose with public-key auth only and PasswordAuthentication disabled; the risk is weak passwords, not the port."
},
"checkCommand": "nc -v github.com 22",
"links": [
{
"title": "RFC 4253 — The Secure Shell (SSH) Transport Layer Protocol",
"url": "https://www.rfc-editor.org/rfc/rfc4253.html",
"kind": "spec"
},
{
"title": "OpenSSH (official project site)",
"url": "https://www.openssh.org/",
"kind": "official-docs"
},
{
"title": "Portable OpenSSH source repository",
"url": "https://github.com/openssh/openssh-portable",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 23,
"protocol": "tcp",
"service": "Telnet",
"oneLiner": "Telnet — unencrypted remote shell, superseded by SSH decades ago.",
"whatItIs": "Telnet gives a raw bidirectional character stream to a login process, with in-band option negotiation for things like terminal type and echo. There is no encryption and no server authentication, so credentials and session content are readable by anyone on the path. It still shows up on switches, PDUs, serial console servers, and embedded devices, and the `telnet` client itself survives as a generic TCP poking tool. Finding 23 open on a scan is normally an unpatched appliance rather than a deliberate choice.",
"exposure": {
"verdict": "never",
"note": "Cleartext credentials with no server authentication; there is no configuration that makes an internet-facing telnet server acceptable."
},
"checkCommand": "sudo lsof -nP -iTCP:23 -sTCP:LISTEN",
"links": [
{
"title": "RFC 854 — Telnet Protocol Specification",
"url": "https://www.rfc-editor.org/rfc/rfc854.html",
"kind": "spec"
},
{
"title": "GNU Inetutils (telnet client and server)",
"url": "https://www.gnu.org/software/inetutils/",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 24,
"protocol": "tcp",
"service": "Any private mail system",
"oneLiner": "Registered to IANA as \"any private mail system\" — a deliberately open-ended slot, not a specific protocol.",
"whatItIs": "IANA's entry for port 24 is literally 'any private mail system', assigned to Rick Adams, meaning the number was set aside for private mail transports rather than any one named protocol. There is no RFC and no reference implementation. In practice almost nothing binds it, and when it appears on a scan it is usually a bespoke or legacy mail relay rather than a standard MTA. Standard mail lives on 25, 465, 587 and 993 instead.",
"exposure": {
"verdict": "careful",
"note": "No defined protocol means no defined security properties; if a private mail transport is really listening here, assume cleartext until proven otherwise."
},
"checkCommand": "nc -vz TARGET 24",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 25,
"protocol": "tcp",
"service": "SMTP",
"oneLiner": "SMTP between mail servers — how mail is delivered host to host, not how your mail client submits it.",
"whatItIs": "A sending MTA looks up the recipient domain's MX record and connects to port 25 there, then runs EHLO / MAIL FROM / RCPT TO / DATA. Modern sessions upgrade to TLS opportunistically with STARTTLS (RFC 3207). Clients should not use 25 for sending their own mail: authenticated submission is port 587 (or 465). Most residential ISPs and cloud providers block outbound 25 by default to limit spam, so a failed connection is often the network, not the server.",
"exposure": {
"verdict": "careful",
"note": "An internet-facing MX on 25 is normal and required, but it must never relay for unauthenticated senders outside its own domains."
},
"checkCommand": "printf 'EHLO test.example\\r\\nQUIT\\r\\n' | nc -v aspmx.l.google.com 25",
"links": [
{
"title": "RFC 5321 — Simple Mail Transfer Protocol",
"url": "https://www.rfc-editor.org/rfc/rfc5321.html",
"kind": "spec"
},
{
"title": "RFC 3207 — SMTP Service Extension for Secure SMTP over TLS",
"url": "https://www.rfc-editor.org/rfc/rfc3207.html",
"kind": "spec"
},
{
"title": "Postfix documentation",
"url": "https://www.postfix.org/documentation.html",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 26,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned at IANA, but widely squatted as an alternate SMTP port when ISPs block 25.",
"whatItIs": "IANA lists port 26 as Unassigned with no registration on TCP or UDP. In practice it is one of the most common squats among shared-hosting providers, which run a second SMTP listener here so customers on residential connections whose ISP blocks outbound 25 can still send mail. It also turns up as an alternate SSH port on hosts that moved sshd off 22 to cut brute-force noise. Neither use is standardised, so what answers on 26 has to be fingerprinted rather than assumed.",
"exposure": {
"verdict": "careful",
"note": "When it is an alternate SMTP listener it usually carries the same cleartext-auth risk as port 25; require STARTTLS or prefer submission on 587."
},
"checkCommand": "nc -vz TARGET 26",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 30,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned at IANA — no registered service and no established squatter.",
"whatItIs": "IANA lists port 30 as Unassigned on TCP and UDP, with no assignee and no reference. No widely deployed daemon binds it by default. It shows up in scan results only as an unidentified listener, and there is no protocol convention to guess from. The useful step is to find the owning process on the host rather than to infer a service from the number.",
"exposure": {
"verdict": "careful",
"note": "Unregistered and unidentified; do not open it without knowing exactly which process is behind it."
},
"checkCommand": "sudo lsof -nP -iTCP:30 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 32,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned at IANA — nothing standard lives here.",
"whatItIs": "IANA lists port 32 as Unassigned on both TCP and UDP, with no assignee and no reference document. No common service binds it as a default. As with the other unassigned low ports, an open 32 is a custom listener and the number itself carries no information. Identify the process holding the socket before drawing any conclusion.",
"exposure": {
"verdict": "careful",
"note": "Unregistered, so exposure depends entirely on the unidentified service behind it."
},
"checkCommand": "sudo lsof -nP -iTCP:32 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 33,
"protocol": "both",
"service": "DSP (Display Support Protocol)",
"oneLiner": "Registered to the Display Support Protocol, a service you will effectively never meet.",
"whatItIs": "IANA registers port 33 as 'dsp — Display Support Protocol', assigned to Ed Cain, on both TCP and UDP. There is no RFC behind the registration and no reference implementation in common use. Nothing on a modern system binds it, so a listener here is almost certainly unrelated software that picked a free low port. Treat the registration as a name in a table, not as a prediction of what you found.",
"exposure": {
"verdict": "careful",
"note": "The registered protocol is effectively extinct, so whatever answers on 33 is unidentified and should be named before it is exposed."
},
"checkCommand": "nc -vz TARGET 33",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 37,
"protocol": "both",
"service": "Time",
"oneLiner": "The Time Protocol — a 32-bit seconds-since-1900 count, returned as four raw bytes.",
"whatItIs": "RFC 868 defines Time as a machine-readable counterpart to Daytime: connect, and the server returns a 32-bit big-endian count of seconds since 1 January 1900 UTC, then closes. NIST still answers on time.nist.gov and reports that only about 2% of its Internet Time Service traffic uses it, while urging users to move to NTP. The protocol has no authentication, no round-trip correction, and one-second resolution, and its 32-bit counter rolls over in 2036. It was an inetd built-in on classic UNIX and is off by default now.",
"exposure": {
"verdict": "careful",
"note": "Only defensible as a deliberate public time service; the UDP form is spoofable and reflectable, and NTP replaces it for actually setting a clock."
},
"checkCommand": "nc -w 5 time.nist.gov 37 | xxd",
"links": [
{
"title": "RFC 868 — Time Protocol",
"url": "https://www.rfc-editor.org/rfc/rfc868.html",
"kind": "spec"
},
{
"title": "NIST Internet Time Service (ITS)",
"url": "https://www.nist.gov/pml/time-and-frequency-division/time-distribution/internet-time-service-its",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 42,
"protocol": "both",
"service": "Host Name Server / WINS replication",
"oneLiner": "Registered as the ARPANET Host Name Server; in practice this is Microsoft WINS replication traffic.",
"whatItIs": "IANA registers 42 under the service names 'name' and 'nameserver' for the Host Name Server, a pre-DNS lookup service that no longer exists in the wild. What actually uses the port today is Windows Internet Name Service replication: WINS servers push and pull NetBIOS name-to-address mappings between each other over TCP 42, and Microsoft's network-port requirements documentation lists the port under WINS. Seeing it open means a Windows Server with the WINS role, which is a deprecated feature kept alive for legacy NetBIOS applications.",
"exposure": {
"verdict": "never",
"note": "Internal Windows name-infrastructure replication with no place on a public interface; keep it inside the network boundary between WINS partners only."
},
"checkCommand": "nmap -Pn -sV -p 42 TARGET",
"links": [
{
"title": "Service overview and network port requirements for Windows",
"url": "https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/service-overview-and-network-port-requirements",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 43,
"protocol": "tcp",
"service": "WHOIS",
"oneLiner": "WHOIS — send a domain, IP or handle as one line of text, get a registration record back.",
"whatItIs": "RFC 3912 describes WHOIS as about as simple as a protocol gets: the client connects, sends a single query terminated by CRLF, and the server writes a free-form text response and closes. There is no encryption, no authentication, and no defined response format, which is exactly why RDAP over HTTPS was built to replace it. Registries, RIRs and the IANA root server all still answer here, and the `whois` command-line client follows referrals between them. Rate limits, not access control, are how operators protect it.",
"exposure": {
"verdict": "fine",
"note": "Public-by-design query service; the only real concerns are bulk-harvesting rate limits and the fact that responses are cleartext and unauthenticated."
},
"checkCommand": "whois -h whois.iana.org example.com",
"links": [
{
"title": "RFC 3912 — WHOIS Protocol Specification",
"url": "https://www.rfc-editor.org/rfc/rfc3912.html",
"kind": "spec"
},
{
"title": "IANA WHOIS Service",
"url": "https://www.iana.org/whois",
"kind": "official-docs"
},
{
"title": "Marco d'Itri's whois client (the Debian/Linux `whois`)",
"url": "https://github.com/rfc1036/whois",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 49,
"protocol": "tcp",
"service": "TACACS+",
"oneLiner": "TACACS+ — the AAA protocol network gear uses to authenticate and authorise every command an admin types.",
"whatItIs": "IANA registers 49 as the Login Host Protocol (TACACS); the protocol actually deployed on it is TACACS+, specified in RFC 8907, which routers, switches and firewalls use to check administrator logins, authorise individual commands, and log accounting records against a central server. Unlike RADIUS it separates authentication, authorisation and accounting and can gate per-command execution, which is why enterprise network teams standardise on it. Its body obfuscation is an MD5-based keyed scheme, not real cryptography, so RFC 8907 states it must run over a secured transport or a trusted network. A listener on 49 means a TACACS+ server such as tac_plus.",
"exposure": {
"verdict": "never",
"note": "This is the authentication and authorisation plane for network infrastructure, protected by a shared secret and weak obfuscation; it belongs on a management network only."
},
"checkCommand": "nc -vz TARGET 49",
"links": [
{
"title": "RFC 8907 — The Terminal Access Controller Access-Control System Plus (TACACS+) Protocol",
"url": "https://www.rfc-editor.org/rfc/rfc8907.html",
"kind": "spec"
},
{
"title": "RFC 1492 — An Access Control Protocol, Sometimes Called TACACS",
"url": "https://www.rfc-editor.org/rfc/rfc1492.html",
"kind": "spec"
},
{
"title": "event-driven-servers (tac_plus / tac_plus-ng) source repository",
"url": "https://github.com/MarcJHuber/event-driven-servers",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 53,
"protocol": "both",
"service": "DNS",
"oneLiner": "DNS — name resolution, on UDP for ordinary queries and TCP for large answers and zone transfers.",
"whatItIs": "Two very different roles share this port: authoritative servers (BIND, NSD, PowerDNS, cloud DNS) that answer for zones they own, and recursive resolvers (Unbound, dnsmasq, systemd-resolved, 1.1.1.1) that answer for clients. UDP is used first; a truncated response sets the TC bit and the client retries over TCP, which also carries AXFR zone transfers. On a laptop you will find something bound to 127.0.0.53 or 127.0.0.1:53 as the local stub resolver. Encrypted variants live elsewhere: DoT on 853, DoH on 443.",
"exposure": {
"verdict": "careful",
"note": "Public authoritative service on 53 is normal; an open recursive resolver is not, because it gets used as a DDoS amplifier."
},
"checkCommand": "dig @1.1.1.1 example.com A +noall +answer",
"links": [
{
"title": "RFC 1035 — Domain Names: Implementation and Specification",
"url": "https://www.rfc-editor.org/rfc/rfc1035.html",
"kind": "spec"
},
{
"title": "Unbound (validating recursive resolver) source repository",
"url": "https://github.com/NLnetLabs/unbound",
"kind": "github"
},
{
"title": "ISC BIND 9",
"url": "https://www.isc.org/bind/",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 70,
"protocol": "tcp",
"service": "Gopher",
"oneLiner": "Gopher — the pre-web menu protocol, still served by a small but real community of hosts.",
"whatItIs": "RFC 1436 defines Gopher as a request/response protocol where the client sends a selector string followed by CRLF and the server returns either a file or a tab-delimited menu, one item per line, each carrying a type character, display string, selector, host and port. It has no cookies, no scripting, and no session state, which is much of its appeal to the people still running it. Floodgap's public server on gopher.floodgap.com has been up since 1999 and is the usual entry point. Servers such as Gophernicus keep the protocol maintained on modern systems.",
"exposure": {
"verdict": "fine",
"note": "A read-only, unauthenticated public publishing protocol with no credentials to leak; the risk is server-side path handling, not the protocol."
},
"checkCommand": "printf '\\r\\n' | nc -v gopher.floodgap.com 70 | head -20",
"links": [
{
"title": "RFC 1436 — The Internet Gopher Protocol",
"url": "https://www.rfc-editor.org/rfc/rfc1436.html",
"kind": "spec"
},
{
"title": "Gophernicus server source repository",
"url": "https://github.com/gophernicus/gophernicus",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 79,
"protocol": "tcp",
"service": "Finger",
"oneLiner": "Finger — ask a host who is logged in, or look up a specific user's details, in cleartext.",
"whatItIs": "RFC 1288 defines Finger as a one-line query protocol: send a username and CRLF to get that user's real name, home directory, shell, login times and the contents of their .plan file, or send an empty line to list everyone currently logged in. That is user enumeration as a service, and the RFC itself devotes a long security section to the fact. It ran as an inetd built-in on nearly every classic UNIX host and was a vector in the 1988 Morris worm through a buffer overflow in fingerd. GNU Inetutils still ships a client and server, but no mainstream system enables it.",
"exposure": {
"verdict": "never",
"note": "It hands out account names, login times and home directories to anyone who asks, unauthenticated and in cleartext — direct reconnaissance material."
},
"checkCommand": "printf '\\r\\n' | nc -v TARGET 79",
"links": [
{
"title": "RFC 1288 — The Finger User Information Protocol",
"url": "https://www.rfc-editor.org/rfc/rfc1288.html",
"kind": "spec"
},
{
"title": "GNU Inetutils (finger client and fingerd)",
"url": "https://www.gnu.org/software/inetutils/",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 80,
"protocol": "tcp",
"service": "HTTP",
"oneLiner": "Plain HTTP — the unencrypted web port, now mostly a redirector to 443 and an ACME challenge endpoint.",
"whatItIs": "A web server (nginx, Apache httpd, Caddy, or an application framework) accepts HTTP/1.1 requests here in cleartext, with the target host chosen by the Host header. In current deployments its main jobs are issuing a 301 to https:// and serving Let's Encrypt HTTP-01 challenges under /.well-known/acme-challenge/. It is also the default listener for dev servers, containers, and load balancer backends behind a TLS terminator. Anything on 80 is readable and modifiable by any network in the path.",
"exposure": {
"verdict": "fine",
"note": "Fine to expose when it only redirects to HTTPS and serves ACME challenges; never serve credentials, cookies, or private content over it."
},
"checkCommand": "curl -sv -o /dev/null http://example.com/",
"links": [
{
"title": "RFC 9110 — HTTP Semantics",
"url": "https://www.rfc-editor.org/rfc/rfc9110.html",
"kind": "spec"
},
{
"title": "RFC 9112 — HTTP/1.1",
"url": "https://www.rfc-editor.org/rfc/rfc9112.html",
"kind": "spec"
},
{
"title": "nginx documentation",
"url": "https://nginx.org/en/docs/",
"kind": "official-docs"
},
{
"title": "Apache HTTP Server 2.4 documentation",
"url": "https://httpd.apache.org/docs/current/",
"kind": "official-docs"
}
]
},
{
"port": 81,
"protocol": "tcp",
"service": "Unassigned (alternate HTTP in practice)",
"oneLiner": "Unassigned at IANA since 2007, and in practice the most common overflow port for a second web server.",
"whatItIs": "IANA de-registered port 81 in 2007 and lists it as Unassigned. What fills it is HTTP: a second web server or virtual host on a box where 80 is already taken, a management interface behind a reverse proxy, and above all the embedded web UIs of IP cameras, DVRs and consumer routers, which frequently expose their admin page here. Because those devices are numerous and often unpatched, port 81 sees heavy untargeted scanning. Anything found on it should be treated as an HTTP service and fingerprinted with a normal HTTP request.",
"exposure": {
"verdict": "careful",
"note": "Usually plain HTTP with no TLS, and very often a device admin interface; put it behind TLS and authentication or do not expose it at all."
},
"checkCommand": "curl -sSI --max-time 5 http://TARGET:81/",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 82,
"protocol": "tcp",
"service": "XFER Utility",
"oneLiner": "Registered to the XFER Utility, a service nobody runs; in practice another spillover HTTP port.",
"whatItIs": "IANA registers port 82 as 'xfer — XFER Utility', assigned to Thomas M. Smith, on TCP and UDP. There is no RFC, no specification anyone cites, and no implementation in general circulation. What actually turns up on 82 is the same thing that turns up on 81 and 83: an additional HTTP listener, an admin panel, or a proxy placed on the next free port after 80. Fingerprint it as HTTP first; the registered name tells you nothing useful.",
"exposure": {
"verdict": "careful",
"note": "Whatever is here is unregistered in practice and usually cleartext HTTP; judge it by the service you actually find, not by the IANA name."
},
"checkCommand": "curl -sSI --max-time 5 http://TARGET:82/",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 83,
"protocol": "tcp",
"service": "MIT ML Device",
"oneLiner": "Registered as 'MIT ML Device' — a 1980s assignment with no surviving protocol behind it.",
"whatItIs": "IANA registers port 83 as 'mit-ml-dev — MIT ML Device', assigned to David Reed, on TCP and UDP. It dates to the early port assignments and has no RFC, no public specification, and no implementation you will encounter. As with 81 and 82, real listeners on 83 are almost always an extra HTTP server, proxy or admin interface parked on a free low port. Identify it by fingerprinting the service rather than by trusting the registry name.",
"exposure": {
"verdict": "careful",
"note": "The registered protocol is a historical artifact; anything answering here is unidentified and typically unencrypted HTTP."
},
"checkCommand": "curl -sSI --max-time 5 http://TARGET:83/",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 84,
"protocol": "tcp",
"service": "Common Trace Facility (CTF)",
"oneLiner": "IANA-registered to Common Trace Facility; effectively never seen in the wild.",
"whatItIs": "Port 84 is registered with IANA as `ctf`, Common Trace Facility, an early tracing/diagnostics service registered by Hugh Thomas. No RFC defines it and no widely deployed implementation uses it, so the registration is the whole of the public record. It still appears in every system `/etc/services` file, which is why scanners label an open 84 as \"ctf\" regardless of what is actually listening. If you find 84 open, treat the name as meaningless and identify the service by its banner.",
"exposure": {
"verdict": "careful",
"note": "Nothing standard runs here, so an open 84 is an unidentified service — fingerprint it before deciding anything."
},
"checkCommand": "nc -vz TARGET 84",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 85,
"protocol": "tcp",
"service": "MIT ML Device",
"oneLiner": "A 1980s MIT registration (`mit-ml-dev`) with no modern use.",
"whatItIs": "IANA lists port 85 as `mit-ml-dev`, \"MIT ML Device\", registered by David Reed in the era when MIT lab machines were handed blocks of the low port range. There is no specification and no current implementation. The name survives only in `/etc/services` and in scanner output. Anything you actually find listening on 85 is a squatter — most often a second HTTP service placed near 80.",
"exposure": {
"verdict": "careful",
"note": "The registration tells you nothing about what is really there; identify the listener before exposing it."
},
"checkCommand": "curl -sv --max-time 5 http://TARGET:85/",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 88,
"protocol": "both",
"service": "Kerberos",
"oneLiner": "The Kerberos KDC — where clients get tickets, and the heartbeat of every Active Directory domain.",
"whatItIs": "A Key Distribution Center listens on 88 and answers AS-REQ and TGS-REQ messages, handing out the ticket-granting ticket and then service tickets that authenticate users without sending passwords. Windows domain controllers, MIT krb5 KDCs, Heimdal, and FreeIPA all listen here; Windows clients try UDP first and fall back to TCP when the ticket exceeds the datagram size. On a scan, an open 88 next to 389 and 445 is a domain controller, full stop. macOS also ships a KDC for local Kerberos realms.",
"exposure": {
"verdict": "never",
"note": "The KDC is the root of trust for the whole realm, and an exposed one invites offline password cracking via AS-REP roasting and pre-auth probing. Keep it internal or behind a VPN."
},
"checkCommand": "nc -vz TARGET 88",
"links": [
{
"title": "RFC 4120 — The Kerberos Network Authentication Service (V5)",
"url": "https://www.rfc-editor.org/rfc/rfc4120.html",
"kind": "spec"
},
{
"title": "MIT Kerberos (official project site)",
"url": "https://web.mit.edu/kerberos/",
"kind": "official-docs"
},
{
"title": "MIT Kerberos source repository",
"url": "https://github.com/krb5/krb5",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 89,
"protocol": "tcp",
"service": "SU/MIT Telnet Gateway",
"oneLiner": "Registered to an ancient Stanford/MIT Telnet gateway; nothing runs it today.",
"whatItIs": "IANA records port 89 as `su-mit-tg`, the SU/MIT Telnet Gateway, registered by Mark Crispin. It was a gateway service between Stanford and MIT networks in the early Internet and has no surviving specification or implementation. Modern scans that report \"su-mit-tg\" are just echoing `/etc/services`. In practice an open 89 is an unrelated service parked one port above 88.",
"exposure": {
"verdict": "careful",
"note": "No standard service claims this port in practice, so an open 89 needs fingerprinting before you trust it."
},
"checkCommand": "nc -vz TARGET 89",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 90,
"protocol": "tcp",
"service": "DNSIX Security Attribute Token Map",
"oneLiner": "Registered to the DoD DNSIX security attribute token map; a legacy defense-network registration.",
"whatItIs": "IANA assigns port 90 to `dnsix`, the DNSIX Security Attribute Token Map, from the US Department of Defense DNSIX (DoD Intelligence Information System Network Security for Information Exchange) work on labeled networking. It is not defined by an RFC and has no general-purpose implementation. Outside classified DoD deployments you will not meet it. An open 90 on an ordinary host is almost always a second web server or admin panel placed near 80.",
"exposure": {
"verdict": "careful",
"note": "Whatever is listening is not DNSIX; identify it and apply that service's rules."
},
"checkCommand": "nc -vz TARGET 90",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 99,
"protocol": "tcp",
"service": "Metagram Relay",
"oneLiner": "IANA-registered as Metagram Relay; historically also squatted by backdoors.",
"whatItIs": "Port 99 is registered as `metagram`, Metagram Relay, an early message-relay service registered by Geoff Goodfellow. There is no published specification and no implementation in current use, so the registration is the only firm fact. Because it sits just under 100 and is normally closed, it has repeatedly been used as a listening port by hobby backdoors and hand-rolled admin shells. Anything open on 99 deserves a banner grab, not an assumption.",
"exposure": {
"verdict": "careful",
"note": "No legitimate modern service claims this port; an unexplained listener on 99 is worth investigating rather than firewalling and forgetting."
},
"checkCommand": "nc -vz TARGET 99",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 100,
"protocol": "tcp",
"service": "Unassigned (historically \"newacct\")",
"oneLiner": "Unassigned by IANA; `/etc/services` still lists it as newacct and flags it as unauthorized use.",
"whatItIs": "IANA marks TCP 100 as Unassigned. Most Unix `/etc/services` files nonetheless carry the line `newacct 100/tcp # [unauthorized use]` — a squatted \"new account\" service that was never registered, and the comment is IANA's own note that the usage is unsanctioned. So a scanner may label an open 100 \"newacct\" while no such protocol is defined. Treat the label as historical trivia and fingerprint whatever is actually listening.",
"exposure": {
"verdict": "careful",
"note": "There is no standard service to reason about here; an open 100 is an unknown listener until you identify it."
},
"checkCommand": "nc -vz TARGET 100",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 106,
"protocol": "tcp",
"service": "poppassd (registered: 3COM-TSMUX)",
"oneLiner": "Registered to 3COM-TSMUX, but in practice this is poppassd — cleartext mail password changes.",
"whatItIs": "IANA assigns 106 to `3com-tsmux`, a long-dead 3Com terminal-server multiplexer. What actually listens on 106 today is poppassd, a password-change daemon spoken by mail servers and control panels: the client sends `user`, `pass`, then `newpass`, and the daemon changes the account password through PAM. Qualcomm Eudora's \"Change Password\" button drove it, and mail hosting stacks kept it for webmail password changes. The exchange is entirely plaintext, which is why its own manual page tells you to bind it to loopback.",
"exposure": {
"verdict": "never",
"note": "poppassd carries the old and the new password in cleartext; the upstream manual page recommends loopback-only access with everything else blocked."
},
"checkCommand": "sudo lsof -nP -iTCP:106 -sTCP:LISTEN",
"links": [
{
"title": "poppassd(8) manual page (Debian)",
"url": "https://manpages.debian.org/testing/poppassd/poppassd.8.en.html",
"kind": "official-docs"
},
{
"title": "poppassd-ceti source repository",
"url": "https://github.com/kravietz/poppassd-ceti",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 109,
"protocol": "tcp",
"service": "POP2",
"oneLiner": "Post Office Protocol version 2 — obsolete since POP3 took 110 in 1988.",
"whatItIs": "POP2, defined in RFC 937, is the second-generation mailbox pickup protocol: a client connects, sends HELO with a username and plaintext password, and retrieves messages with a small command set. POP3 on port 110 replaced it and is not backward compatible, so POP2 has been dead in practice for decades. Some old mail servers still compiled a POP2 listener into inetd, which is the only realistic way you meet it. Like POP3 without TLS, it sends credentials in the clear.",
"exposure": {
"verdict": "never",
"note": "Obsolete protocol with plaintext authentication and no TLS story; if 109 is open, the fix is to turn it off, not to firewall it."
},
"checkCommand": "sudo lsof -nP -iTCP:109 -sTCP:LISTEN",
"links": [
{
"title": "RFC 937 — Post Office Protocol Version 2",
"url": "https://www.rfc-editor.org/rfc/rfc937.html",
"kind": "spec"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 110,
"protocol": "tcp",
"service": "POP3",
"oneLiner": "POP3 — download-and-usually-delete mail retrieval, with no server-side folder state.",
"whatItIs": "A client connects, authenticates with USER/PASS or APOP, lists messages by number, retrieves them with RETR, and typically marks them deleted; the mailbox is a flat list with no folders and no cross-device sync. Port 110 is the cleartext port, upgraded in practice with STLS or replaced by implicit-TLS POP3S on 995. It is still served by Dovecot and by most hosting providers for legacy clients and scripted fetchers. Its appearance on a scan usually means an old mail host or a shared-hosting control panel.",
"exposure": {
"verdict": "careful",
"note": "Only expose 110 when the server requires STLS before accepting credentials; otherwise use POP3S on 995."
},
"checkCommand": "printf 'CAPA\\r\\nQUIT\\r\\n' | nc -v MAIL_HOST 110",
"links": [
{
"title": "RFC 1939 — Post Office Protocol Version 3",
"url": "https://www.rfc-editor.org/rfc/rfc1939.html",
"kind": "spec"
},
{
"title": "Dovecot (IMAP/POP3 server) source repository",
"url": "https://github.com/dovecot/core",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 111,
"protocol": "both",
"service": "sunrpc / rpcbind (portmapper)",
"oneLiner": "The ONC RPC portmapper — ask it which port a given RPC program is on, and it tells you.",
"whatItIs": "rpcbind (formerly portmap) maps ONC RPC program numbers to the ports their servers actually listen on, per RFC 1833. NFS, `mountd`, `statd`, NIS, and quota daemons register with it at startup, and clients query 111 first to find them — which is exactly what `rpcinfo -p` does. It is on by default on most Linux and Solaris NFS servers and answers on both TCP and UDP. Its UDP side has been abused as a DDoS reflector, and its dump reply is a free inventory of a host's RPC services.",
"exposure": {
"verdict": "never",
"note": "An internet-facing rpcbind enumerates your RPC services to anyone and its UDP listener is a known amplification reflector. Keep it on the internal network."
},
"checkCommand": "rpcinfo -p TARGET",
"links": [
{
"title": "RFC 1833 — Binding Protocols for ONC RPC Version 2",
"url": "https://www.rfc-editor.org/rfc/rfc1833.html",
"kind": "spec"
},
{
"title": "rpcbind(8) manual page",
"url": "https://man7.org/linux/man-pages/man8/rpcbind.8.html",
"kind": "official-docs"
},
{
"title": "RFC 4506 — XDR: External Data Representation Standard",
"url": "https://www.rfc-editor.org/rfc/rfc4506.html",
"kind": "spec"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 113,
"protocol": "tcp",
"service": "ident / auth",
"oneLiner": "The Ident protocol — a server asks your host \"who owns this outbound connection?\"",
"whatItIs": "Ident, RFC 1413, answers a query naming a local and remote port pair with the username that owns that TCP connection. IRC servers and some old SMTP and FTP daemons query it when you connect, which is why an IRC connection stalls a few seconds when 113 is filtered rather than refused. The answer is entirely self-reported by the client's host, so it is a hint, not authentication — RFC 1413 says so itself. Modern hosts usually have nothing listening, and oidentd exists for people who want to answer anyway.",
"exposure": {
"verdict": "careful",
"note": "Harmless by design but it leaks local usernames to anyone who asks. If you filter it, REJECT rather than DROP so clients fail fast instead of waiting for a timeout."
},
"checkCommand": "nc -vz TARGET 113",
"links": [
{
"title": "RFC 1413 — Identification Protocol",
"url": "https://www.rfc-editor.org/rfc/rfc1413.html",
"kind": "spec"
},
{
"title": "oidentd source repository",
"url": "https://github.com/solbu/oidentd",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 119,
"protocol": "tcp",
"service": "NNTP",
"oneLiner": "Usenet news transport and reading — NNTP in the clear, with NNTPS on 563.",
"whatItIs": "NNTP, current spec RFC 3977, moves Usenet articles between news servers and serves readers with commands like GROUP, ARTICLE and POST over a line-oriented text session. INN and Diablo are the common server implementations, and commercial Usenet providers still run large farms of them. Port 119 is the cleartext port; TLS-wrapped NNTPS lives on 563 and is what providers push clients toward. Seeing 119 open usually means a real news server or a peering endpoint, not an accident.",
"exposure": {
"verdict": "careful",
"note": "Public read-only news service on 119 is fine by design, but any authenticated feed or posting account should be on 563 so credentials are not sent in the clear."
},
"checkCommand": "printf 'QUIT\\r\\n' | nc -v TARGET 119",
"links": [
{
"title": "RFC 3977 — Network News Transfer Protocol (NNTP)",
"url": "https://www.rfc-editor.org/rfc/rfc3977.html",
"kind": "spec"
},
{
"title": "InterNetNews (INN) source repository",
"url": "https://github.com/InterNetNews/inn",
"kind": "github"
},
{
"title": "INN documentation",
"url": "https://www.eyrie.org/~eagle/software/inn/",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 123,
"protocol": "udp",
"service": "NTP",
"oneLiner": "Network Time Protocol — clock synchronization, UDP 123.",
"whatItIs": "NTP daemons (chrony, ntpd, ntpsec, systemd-timesyncd, Windows w32time) use UDP port 123 to exchange timestamps with upstream time servers. Clients normally only send queries, but a full server binds 123 and answers them. It shows up on a scan because a host is acting as a time server for its network, or because the daemon was left listening on all interfaces rather than just localhost. IANA lists ntp on both TCP and UDP 123, but real traffic is UDP.",
"exposure": {
"verdict": "careful",
"note": "An open NTP server is a classic reflection/amplification source if monlist-style control queries or unrestricted mode 6/7 commands are reachable, so restrict it to the clients that need it."
},
"checkCommand": "sntp -t 5 time.cloudflare.com # or: ntpdig -t 5 time.cloudflare.com",
"links": [
{
"title": "RFC 5905 — Network Time Protocol Version 4",
"url": "https://datatracker.ietf.org/doc/html/rfc5905",
"kind": "spec"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "chrony (GitHub mirror)",
"url": "https://github.com/mlichvar/chrony",
"kind": "github"
},
{
"title": "NTPsec (GitHub mirror)",
"url": "https://github.com/ntpsec/ntpsec",
"kind": "github"
}
]
},
{
"port": 125,
"protocol": "tcp",
"service": "Locus PC-Interface Net Map Server",
"oneLiner": "Registered to the Locus PC-Interface net map server; a dead 1980s product.",
"whatItIs": "IANA lists port 125 as `locus-map`, the Locus PC-Interface Net Map Server, from Locus Computing's PC-Interface product that let DOS PCs use Unix file and print services. The company and the product are long gone and no specification was published. The registration persists in `/etc/services`, so scanners print the name without evidence. Anything listening on 125 today is unrelated to Locus.",
"exposure": {
"verdict": "careful",
"note": "The service name is a fossil; identify the actual listener before making any exposure decision."
},
"checkCommand": "nc -vz TARGET 125",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 135,
"protocol": "both",
"service": "MSRPC endpoint mapper (epmap)",
"oneLiner": "Windows RPC endpoint mapper — ask it where a service lives and it hands back a dynamic port.",
"whatItIs": "Registered as `epmap`, DCE endpoint resolution, this is in practice the Microsoft RPC endpoint mapper. A client that wants an RPC interface asks 135 for its binding and is sent on to a dynamically assigned high port, which is why 135 is inseparable from the 49152–65535 range on Windows. WMI, DCOM, Exchange, the print spooler and countless management tools depend on it. It is open on essentially every Windows host, and it was the port the Blaster worm entered through in 2003.",
"exposure": {
"verdict": "never",
"note": "An internet-facing endpoint mapper enumerates RPC interfaces and is a decades-long source of remote code execution bugs. ISPs commonly block 135 outright."
},
"checkCommand": "nc -vz TARGET 135",
"links": [
{
"title": "MS-RPCE — Remote Procedure Call Protocol Extensions",
"url": "https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-rpce/290c38b1-92fe-4229-91e6-4fc376610c15",
"kind": "official-docs"
},
{
"title": "Service overview and network port requirements for Windows",
"url": "https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/service-overview-and-network-port-requirements",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 139,
"protocol": "tcp",
"service": "NetBIOS Session Service",
"oneLiner": "SMB over NetBIOS — the pre-2000 file sharing path that still lingers next to 445.",
"whatItIs": "Port 139 carries the NetBIOS Session Service from RFC 1001/1002, and on top of it rides SMB for Windows file and printer sharing. Since Windows 2000, SMB prefers direct hosting on TCP 445 and only falls back to 139 for older peers, so a host with 139 open is usually supporting legacy clients or running a Samba server with NetBIOS enabled. It shows up constantly on NAS boxes, print servers, and unpatched Windows machines. Together with 137/138 UDP it also leaks workgroup and machine names to anyone who asks.",
"exposure": {
"verdict": "never",
"note": "File sharing and name-service leakage on a public IP; this is the classic \"my NAS is on the internet\" finding. Keep SMB on the LAN or a VPN."
},
"checkCommand": "sudo lsof -nP -iTCP:139 -sTCP:LISTEN",
"links": [
{
"title": "RFC 1001 — NetBIOS over TCP/UDP: Concepts and Methods",
"url": "https://www.rfc-editor.org/rfc/rfc1001.html",
"kind": "spec"
},
{
"title": "RFC 1002 — NetBIOS over TCP/UDP: Detailed Specifications",
"url": "https://www.rfc-editor.org/rfc/rfc1002.html",
"kind": "spec"
},
{
"title": "Samba source repository",
"url": "https://github.com/samba-team/samba",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 143,
"protocol": "tcp",
"service": "IMAP",
"oneLiner": "IMAP — server-side mailboxes with folders, flags, and search, kept in sync across devices.",
"whatItIs": "Clients issue tagged commands (CAPABILITY, LOGIN, SELECT, FETCH, SEARCH) and the server keeps the authoritative state, so messages, flags, and folders look the same on every device. Port 143 is the cleartext port; the STARTTLS upgrade happens here, while implicit TLS runs on 993, which is what most clients now use. Dovecot and Cyrus are the common self-hosted servers, and 143 is often left open for LAN clients and migration tools. IMAP is retrieval only — sending still goes out over submission on 587.",
"exposure": {
"verdict": "careful",
"note": "Expose only with STARTTLS required before LOGIN; plain 143 sends mailbox credentials in the clear, so prefer 993."
},
"checkCommand": "printf 'a1 CAPABILITY\\r\\na2 LOGOUT\\r\\n' | nc -v MAIL_HOST 143",
"links": [
{
"title": "RFC 9051 — Internet Message Access Protocol (IMAP) Version 4rev2",
"url": "https://www.rfc-editor.org/rfc/rfc9051.html",
"kind": "spec"
},
{
"title": "Dovecot (IMAP/POP3 server) source repository",
"url": "https://github.com/dovecot/core",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 144,
"protocol": "tcp",
"service": "Universal Management Architecture (historically NeWS)",
"oneLiner": "Registered as `uma`; older service files call it `news`, Sun's PostScript window system.",
"whatItIs": "IANA registers port 144 as `uma`, Universal Management Architecture. Older `/etc/services` files instead name it `news` for Sun's NeWS, the PostScript-based window system that lost to X11 — a source of confusion, since it has nothing to do with Usenet news on 119. Neither service has a live implementation today. An open 144 is an unrelated listener, and the scanner label will tell you whichever name that machine's services file happens to carry.",
"exposure": {
"verdict": "careful",
"note": "Two dead names for one port; identify the real service rather than trusting the label."
},
"checkCommand": "nc -vz TARGET 144",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 146,
"protocol": "tcp",
"service": "ISO-TP0",
"oneLiner": "ISO transport class 0; the standard TPKT/TP0-over-TCP port is 102, not this one.",
"whatItIs": "IANA registers 146 as `iso-tp0` (ISO-IP0), part of the family of registrations for running OSI transport over TCP/IP. The one that mattered is port 102, where RFC 1006 puts TPKT and TP0 — the encapsulation that ISO session-layer protocols, and later Siemens S7 industrial gear, actually use. Port 146 carries no deployed implementation. Treat it as a registry artifact and look at 102 if you are chasing real ISO-over-TCP traffic.",
"exposure": {
"verdict": "careful",
"note": "Nothing standard listens here; if something does, fingerprint it — and check whether the OSI service you actually care about is on 102."
},
"checkCommand": "nc -vz TARGET 146",
"links": [
{
"title": "RFC 1006 — ISO Transport Service on top of the TCP",
"url": "https://www.rfc-editor.org/rfc/rfc1006.html",
"kind": "spec"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 161,
"protocol": "udp",
"service": "SNMP",
"oneLiner": "SNMP agent — device monitoring queries, UDP 161.",
"whatItIs": "Routers, switches, printers, UPSes, and servers running an SNMP agent (commonly Net-SNMP's snmpd) listen on UDP 161 and answer GET/GETNEXT requests from monitoring systems. Net-SNMP's default agentaddress is UDP 161 on all IPv4 interfaces. It appears on scans anywhere network monitoring exists, often still configured with SNMPv1/v2c community strings that travel in cleartext. Traps go outbound to port 162, not here.",
"exposure": {
"verdict": "never",
"note": "v1/v2c community strings are cleartext and readable device inventory; keep 161 on a management network and use SNMPv3 with auth and privacy."
},
"checkCommand": "snmpwalk -v2c -c public TARGET system",
"links": [
{
"title": "RFC 3411 — Architecture for SNMP Management Frameworks (STD 62)",
"url": "https://datatracker.ietf.org/doc/html/rfc3411",
"kind": "spec"
},
{
"title": "Net-SNMP (GitHub)",
"url": "https://github.com/net-snmp/net-snmp",
"kind": "github"
},
{
"title": "snmpd.conf manual page",
"url": "https://www.net-snmp.org/docs/man/snmpd.conf.html",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 163,
"protocol": "tcp",
"service": "CMIP/TCP Manager",
"oneLiner": "The manager side of CMOT, the OSI network-management protocol that SNMP beat.",
"whatItIs": "Port 163 is registered as `cmip-man`, the CMIP-over-TCP manager, with 164 as the agent side. CMOT — CMIP over TCP/IP, RFC 1189 — was the OSI-flavored competitor to SNMP for managing IP networks, and it lost decisively; the RFC itself was later reclassified as historic. Telco OSS systems were the only real deployments, and those are gone or isolated. You will not meet this on a general-purpose network.",
"exposure": {
"verdict": "never",
"note": "A network-management plane with no modern security story. If something is genuinely speaking CMIP, it belongs on an isolated management network."
},
"checkCommand": "nc -vz TARGET 163",
"links": [
{
"title": "RFC 1189 — Common Management Information Services and Protocols for the Internet (CMOT and CMIP)",
"url": "https://www.rfc-editor.org/rfc/rfc1189.html",
"kind": "spec"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 179,
"protocol": "tcp",
"service": "BGP",
"oneLiner": "Border Gateway Protocol — the sessions that exchange the internet's routing table.",
"whatItIs": "BGP-4, RFC 4271, runs over a plain TCP session on port 179 between two configured peers that exchange UPDATE messages describing reachable prefixes and their AS paths. Every internet exchange, transit link, and large enterprise edge is built from these sessions, and route servers, FRRouting, BIRD, and vendor routers all listen here. A BGP speaker only accepts sessions from peers you configure, so an open 179 is a router edge, not a public service. Peers commonly authenticate the session with a TCP-MD5 or TCP-AO key.",
"exposure": {
"verdict": "careful",
"note": "179 is necessarily reachable by your peers, but it should be restricted to configured neighbor addresses with session authentication and GTSM (TTL security) — never open to the internet at large."
},
"checkCommand": "nc -vz TARGET 179",
"links": [
{
"title": "RFC 4271 — A Border Gateway Protocol 4 (BGP-4)",
"url": "https://www.rfc-editor.org/rfc/rfc4271.html",
"kind": "spec"
},
{
"title": "RFC 7454 — BGP Operations and Security",
"url": "https://www.rfc-editor.org/rfc/rfc7454.html",
"kind": "spec"
},
{
"title": "FRRouting source repository",
"url": "https://github.com/FRRouting/frr",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 199,
"protocol": "tcp",
"service": "SMUX",
"oneLiner": "SNMP multiplexing — how a subagent attaches its MIB subtree to the main SNMP agent.",
"whatItIs": "SMUX, RFC 1227, lets a separate process register a MIB subtree with the local SNMP agent so queries for that subtree are relayed to it; the agent listens on TCP 199 for those peer connections. Routing daemons like gated and later quagga/zebra used it to expose routing MIBs, and net-snmp can be built with SMUX support. It is an experimental protocol that AgentX (RFC 2741) superseded, so new deployments use AgentX instead. An open 199 next to 161/udp marks an older SNMP stack.",
"exposure": {
"verdict": "never",
"note": "SMUX peers authenticate with a plaintext community-style password and gain control of part of the agent's MIB; it is an internal agent-to-subagent channel, not an internet service."
},
"checkCommand": "sudo lsof -nP -iTCP:199 -sTCP:LISTEN",
"links": [
{
"title": "RFC 1227 — SNMP MUX Protocol and MIB",
"url": "https://www.rfc-editor.org/rfc/rfc1227.html",
"kind": "spec"
},
{
"title": "Net-SNMP source repository",
"url": "https://github.com/net-snmp/net-snmp",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 211,
"protocol": "tcp",
"service": "Texas Instruments 914C/G Terminal",
"oneLiner": "Registered to a Texas Instruments 914C/G terminal; museum-grade, never seen live.",
"whatItIs": "IANA registers port 211 for the Texas Instruments 914C/G Terminal, under both the legacy name `914c/g` and the well-formed replacement `914c-g`. It served a specific TI terminal product and has no specification or implementation in circulation. The entry survives in `/etc/services`, so a scan of an open 211 will print that name with no basis. Identify the real listener; it will be something else entirely.",
"exposure": {
"verdict": "careful",
"note": "The registered service does not exist in practice, so an open 211 is an unidentified listener."
},
"checkCommand": "nc -vz TARGET 211",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 212,
"protocol": "tcp",
"service": "ATEXSSTR (anet)",
"oneLiner": "Registered as `anet`/ATEXSSTR, an Atex publishing-system service with no public spec.",
"whatItIs": "IANA lists port 212 as `anet`, ATEXSSTR, registered by Jim Taylor of Atex, the newspaper publishing-system vendor. No specification was ever published and no general implementation exists, so the registration is the entire public record. It appears in `/etc/services` and therefore in scanner output. Anything found on 212 is unrelated to Atex.",
"exposure": {
"verdict": "careful",
"note": "A vendor registration with no documented protocol; fingerprint whatever is actually listening."
},
"checkCommand": "nc -vz TARGET 212",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 222,
"protocol": "tcp",
"service": "rsh-spx (in practice: relocated SSH)",
"oneLiner": "Registered to Berkeley rshd with SPX authentication; in practice a common alternate SSH port.",
"whatItIs": "IANA registers 222 as `rsh-spx`, Berkeley `rshd` using SPX authentication — a Kerberos-era variant of the rsh remote-shell family that is long dead. What you actually meet on 222 is a relocated SSH daemon: shared hosts and home routers move sshd off 22 to cut log noise from password-guessing bots, and 222 is one of the favored destinations. A banner grab settles it immediately, since SSH announces itself with an `SSH-2.0-...` line. Moving the port reduces noise, not risk.",
"exposure": {
"verdict": "careful",
"note": "If it is SSH, the exposure rules for port 22 apply and the port number changes nothing. If it is genuinely rsh, it is cleartext remote shell and must not be reachable."
},
"checkCommand": "nc -v TARGET 222",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 254,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "No registered service — IANA has never assigned 254, yet scanners still probe it by habit.",
"whatItIs": "The IANA service name and port number registry has no entry for 254 on TCP or UDP; it sits in a gap between 250 and 255 that was never handed out. Nmap's empirical service list labels it plainly \"unknown\" while still ranking it inside the default top-1000 scan set, which is why it appears in scan output at all. Anything actually listening here is a local choice by whoever configured the host, not a protocol you can infer from the number. Treat an open 254 as a prompt to fingerprint the service, never as an identification.",
"exposure": {
"verdict": "careful",
"note": "An open port with no registered protocol tells you nothing about what it is — identify the listener with a service probe before deciding whether it belongs on a public IP."
},
"checkCommand": "nmap -sV -p 254 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 254",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=254",
"kind": "iana"
},
{
"title": "nmap-services — the empirical port frequency list (254/tcp \"unknown\")",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 255,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Another unassigned port in the 250–255 gap, with no protocol behind the number.",
"whatItIs": "IANA lists no assignment for 255 on either transport, and there is no historical registration to point at. Like its neighbour 254 it still carries a measurable open-rate in Nmap's frequency data, so it rides along in default scans and turns up in results as a nameless open port. Any listener is site-specific: an internal service someone parked on a low, memorable number, or a device firmware default that was never registered. There is nothing generic to say about what it does.",
"exposure": {
"verdict": "careful",
"note": "Unregistered does not mean harmless — fingerprint the listener before exposing it, because low-numbered ports usually mean a root-owned process."
},
"checkCommand": "nmap -sV -p 255 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 255",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=255",
"kind": "iana"
},
{
"title": "nmap-services — the empirical port frequency list (255/tcp \"unknown\")",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 256,
"protocol": "tcp",
"service": "Check Point FireWall-1 (IANA: RAP)",
"oneLiner": "Almost always a Check Point firewall or management server, despite the IANA registration reading \"RAP\".",
"whatItIs": "IANA assigned 256 to \"RAP\" in the early 1990s and nothing public ever implemented it. In practice the port belongs to Check Point: the FWD daemon on a Security Gateway and Security Management Server uses TCP 256 for policy and log traffic between gateway and manager, which is why Nmap's service list names it fw1-secureremote. If 256 answers, you have found a Check Point firewall or its management console, and the rest of the low-256-to-265 block usually answers too. This is a management plane, not a user-facing service.",
"exposure": {
"verdict": "never",
"note": "This is the firewall's own control channel between gateway and management server; reaching it from the internet means the device managing your perimeter is itself on the perimeter."
},
"checkCommand": "nmap -sV -p 256,257,259,264 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 256",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=256",
"kind": "iana"
},
{
"title": "nmap-services — 256/tcp fw1-secureremote",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
],
"ianaName": "rap"
},
{
"port": 259,
"protocol": "tcp",
"service": "ESRO (IANA) — in practice Check Point client authentication",
"oneLiner": "Registered to ESRO, but on a real network it is usually Check Point FireWall-1 client authentication.",
"whatItIs": "IANA assigns 259 to esro-gen, Efficient Short Remote Operations, a lightweight RPC-over-UDP scheme specified in RFC 2188 for low-bandwidth links; you will effectively never meet a live ESRO server. What you do meet is Check Point: TCP 259 carries FireWall-1 Client Authentication, where a user telnets to the firewall, logs in, and the firewall then opens rules for that source address. Nmap's list separately marks 259/udp as Check Point's proprietary RDP tunnelling protocol. An open 259 next to 256 and 264 is a Check Point gateway, not ESRO.",
"exposure": {
"verdict": "never",
"note": "Check Point client authentication is an interactive login prompt on the firewall itself — a cleartext credential surface that also grants network access on success."
},
"checkCommand": "nmap -sV -p 259 TARGET",
"links": [
{
"title": "RFC 2188 — AT&T/Neda's Efficient Short Remote Operations (ESRO)",
"url": "https://www.rfc-editor.org/rfc/rfc2188.html",
"kind": "spec"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 259",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=259",
"kind": "iana"
},
{
"title": "nmap-services — 259/udp firewall1-rdp",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
],
"ianaName": "esro-gen"
},
{
"port": 264,
"protocol": "tcp",
"service": "Check Point FW1 topology (IANA: BGMP)",
"oneLiner": "Check Point's SecuRemote topology download — the single most reliable fingerprint for a Check Point gateway.",
"whatItIs": "IANA registered 264 for BGMP, the Border Gateway Multicast Protocol of RFC 3913, which was never deployed. The port's real occupant is Check Point's FW1_topo service: remote-access VPN clients connect here to fetch the gateway's encryption domain and network topology before building a tunnel. Because that exchange historically answered unauthenticated queries, 264 became a standard reconnaissance target — a scanner that gets a response can often read the firewall's hostname and internal network list. Seeing 264 open on a public IP identifies the vendor immediately.",
"exposure": {
"verdict": "never",
"note": "The topology service has leaked gateway hostnames and internal network ranges to unauthenticated clients; if remote-access VPN does not need it, Check Point lets you disable the implied rule that opens it."
},
"checkCommand": "nmap -sV -p 264 TARGET",
"links": [
{
"title": "RFC 3913 — Border Gateway Multicast Protocol (BGMP), the registered use",
"url": "https://www.rfc-editor.org/rfc/rfc3913.html",
"kind": "spec"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 264",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=264",
"kind": "iana"
},
{
"title": "nmap-services — 264/udp fw1-or-bgmp",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
],
"ianaName": "bgmp"
},
{
"port": 280,
"protocol": "tcp",
"service": "http-mgmt",
"oneLiner": "Registered as \"http-mgmt\" with no public specification — in practice just another HTTP admin port.",
"whatItIs": "IANA lists 280 as http-mgmt, assigned to Adrian Pell, but no protocol document was ever published for it and no widely deployed product claims the name. What actually turns up on 280 is ordinary HTTP: a device or appliance whose web management interface was moved off 80, or a proxy or admin console picking a low free port. Treat it as unidentified HTTP and confirm with a request rather than assuming the registration describes the listener.",
"exposure": {
"verdict": "careful",
"note": "If this is a device management UI it is cleartext HTTP with a login form — fine on a management VLAN, never on a public address."
},
"checkCommand": "curl -sSI --max-time 5 http://TARGET:280/",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 280",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=280",
"kind": "iana"
}
],
"ianaName": "http-mgmt"
},
{
"port": 301,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "No IANA assignment and no established convention — an open 301 identifies nothing.",
"whatItIs": "The registry has no entry for 301 on TCP or UDP; the surrounding 301–307 range is likewise blank. Nmap carries it as \"unknown\" with a low but non-zero open rate, which is characteristic of a port used by a handful of appliances or in-house services rather than any standard protocol. There is no banner, no RFC, and no vendor default worth naming here. Fingerprint the listener; the number will not tell you.",
"exposure": {
"verdict": "careful",
"note": "Unknown service on a privileged port — determine what it is and whether it authenticates before it goes anywhere near a public interface."
},
"checkCommand": "nmap -sV -p 301 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 301",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=301",
"kind": "iana"
}
]
},
{
"port": 306,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned by IANA; anything listening is a local or vendor-specific choice.",
"whatItIs": "IANA has no registration for 306, and no public protocol claims it. Nmap lists it as \"unknown\" while still including it in wide scans because a measurable share of hosts answer, which usually points at embedded devices or a niche product rather than anything standardised. Do not read a service into the number — there is not one to read. The only honest answer is the registration status plus a service probe.",
"exposure": {
"verdict": "careful",
"note": "No registered protocol means no assumption of authentication or encryption; probe it and treat it as untrusted until identified."
},
"checkCommand": "nmap -sV -p 306 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 306",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=306",
"kind": "iana"
}
]
},
{
"port": 311,
"protocol": "tcp",
"service": "AppleShare IP WebAdmin",
"oneLiner": "Apple's browser-based server administration port, from AppleShare IP and the old Mac OS X Server admin tools.",
"whatItIs": "IANA still lists 311 as asip-webadmin, registered by Apple for AppleShare IP's web administration interface. Apple carried the port forward into Mac OS X Server, where the Server Admin, Workgroup Manager and Server Monitor tools reached the server over it. Both AppleShare IP and macOS Server are discontinued, and Apple's current port list no longer mentions 311, so a live listener today means an old Mac server that was never retired. If you find one, the machine behind it is by definition running unpatched, end-of-life server software.",
"exposure": {
"verdict": "never",
"note": "A server administration plane on unmaintained, end-of-life software — restrict it to a management network and plan the decommission."
},
"checkCommand": "nmap -sV -p 311 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 311",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=311",
"kind": "iana"
},
{
"title": "Apple — TCP and UDP ports used by Apple software products (311 no longer listed)",
"url": "https://support.apple.com/en-us/103229",
"kind": "official-docs"
}
],
"ianaName": "asip-webadmin"
},
{
"port": 340,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned in the IANA registry, with no protocol or product convention behind it.",
"whatItIs": "There is no IANA entry for 340 on either transport; the block from 334 through 343 is empty. Nmap records it as \"unknown\" on both TCP and UDP with a small open rate, meaning some hosts do answer but no consistent service explains them. Nothing about the number implies a protocol, an encoding, or an authentication model. Probe the listener and identify it on its own evidence.",
"exposure": {
"verdict": "careful",
"note": "Unregistered and unidentified — nothing here justifies internet exposure until you know what process is bound to it."
},
"checkCommand": "nmap -sV -p 340 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 340",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=340",
"kind": "iana"
}
]
},
{
"port": 366,
"protocol": "tcp",
"service": "ODMR (On-Demand Mail Relay)",
"oneLiner": "On-Demand Mail Relay — an intermittently connected mail server pulling its queued mail from an ISP.",
"whatItIs": "ODMR, specified in RFC 2645, exists for domains that are not always online. The client authenticates to its provider with SMTP AUTH, issues the ATRN command, and the two ends then swap roles so the provider delivers the mail it has been queueing over the same connection. It was built for dial-up and intermittent links, which is why it is nearly extinct — always-on connections and POP/IMAP collection replaced it. A live 366 today is usually a small ISP or hosting provider that never turned the service off.",
"exposure": {
"verdict": "careful",
"note": "ODMR requires SMTP AUTH before ATRN, so it is only as safe as the TLS around it; without STARTTLS enforced it hands over mail credentials in the clear."
},
"checkCommand": "printf 'QUIT\\r\\n' | nc -v -w 5 TARGET 366",
"links": [
{
"title": "RFC 2645 — On-Demand Mail Relay (ODMR) SMTP with Dynamic IP Addresses",
"url": "https://www.rfc-editor.org/rfc/rfc2645.html",
"kind": "spec"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 366",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=366",
"kind": "iana"
}
],
"ianaName": "odmr"
},
{
"port": 389,
"protocol": "tcp",
"service": "LDAP",
"oneLiner": "LDAP directory service, cleartext or STARTTLS, TCP 389.",
"whatItIs": "Directory servers — OpenLDAP slapd, Active Directory domain controllers, 389 Directory Server — listen on TCP 389 for bind, search, and modify operations. OpenLDAP's default listener URL is ldap:/// which means LDAP over TCP on all interfaces on port 389. On a scan it usually marks a domain controller or an identity store that applications authenticate against. Port 636 is the separate implicit-TLS listener (ldaps://); 389 itself is cleartext unless the client negotiates STARTTLS.",
"exposure": {
"verdict": "never",
"note": "A simple bind on 389 without STARTTLS sends the username and password in cleartext, and anonymous binds often leak the whole directory tree."
},
"checkCommand": "ldapsearch -x -H ldap://DC_HOST:389 -s base -b \"\" namingContexts",
"links": [
{
"title": "RFC 4511 — LDAP: The Protocol",
"url": "https://datatracker.ietf.org/doc/html/rfc4511",
"kind": "spec"
},
{
"title": "OpenLDAP 2.6 Administrator's Guide — Running slapd",
"url": "https://www.openldap.org/doc/admin26/runningslapd.html",
"kind": "official-docs"
},
{
"title": "OpenLDAP (GitHub mirror)",
"url": "https://github.com/openldap/openldap",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 406,
"protocol": "tcp",
"service": "IMSP (Interactive Mail Support Protocol)",
"oneLiner": "A dead companion protocol to IMAP that stored address books and mailbox subscriptions on the server.",
"whatItIs": "IMSP came out of Carnegie Mellon's Cyrus mail project to hold the things IMAP did not: personal address books, per-user options, and mailbox subscription lists shared across clients. It never became an IETF standard; the working group's successor effort, ACAP (RFC 2244), was published but saw almost no adoption either, and both were eventually made moot by IMAP extensions and by LDAP for directories. IANA still holds 406 for imsp, and a listener there means a surviving Cyrus-era deployment.",
"exposure": {
"verdict": "never",
"note": "IMSP authenticates in cleartext by default and its implementations are unmaintained — there is no version of this that belongs on a public address."
},
"checkCommand": "nc -vz -w 3 TARGET 406",
"links": [
{
"title": "RFC 2244 — ACAP, the standardised successor to IMSP",
"url": "https://www.rfc-editor.org/rfc/rfc2244.html",
"kind": "spec"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 406",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=406",
"kind": "iana"
},
{
"title": "cyrusimap/cyrus-imapd — the Cyrus mail project IMSP came from",
"url": "https://github.com/cyrusimap/cyrus-imapd",
"kind": "github"
}
],
"ianaName": "imsp"
},
{
"port": 407,
"protocol": "tcp",
"service": "Timbuktu",
"oneLiner": "Timbuktu remote control — 1990s cross-platform screen sharing for Mac and Windows, long discontinued.",
"whatItIs": "Timbuktu was Farallon's, later Netopia's and finally Motorola's, remote-control product: view and drive another machine's screen, plus file exchange and chat, across Mac and Windows. IANA holds 407 for it, registered by the vendor. The product was discontinued and receives no updates, so a listener on 407 is an unmaintained remote-control agent with full interactive access to the desktop it runs on. Nmap's frequency data still shows it turning up on UDP as well as TCP.",
"exposure": {
"verdict": "never",
"note": "Unmaintained remote screen control with its own credential store — this is full desktop takeover if the authentication is bypassed, and nobody is shipping fixes."
},
"checkCommand": "nmap -sV -p 407 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 407",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=407",
"kind": "iana"
}
],
"ianaName": "timbuktu"
},
{
"port": 416,
"protocol": "tcp",
"service": "SilverPlatter",
"oneLiner": "Registered to SilverPlatter, a 1990s library database vendor — effectively never seen in the wild.",
"whatItIs": "IANA assigned 416 to \"silverplatter\", registered by an engineer at SilverPlatter Information, a company that sold bibliographic and reference databases to libraries first on CD-ROM and then over a client/server product. The company was absorbed into Ovid, and the protocol has no public specification. Nothing about the port is documented beyond the registration itself. If 416 is open today, identify the process locally rather than trusting the registered name.",
"exposure": {
"verdict": "careful",
"note": "A 1990s client/server database protocol with no published spec and no maintainer — assume no transport security and keep it internal."
},
"checkCommand": "nc -vz -w 3 TARGET 416",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 416",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=416",
"kind": "iana"
}
],
"ianaName": "silverplatter"
},
{
"port": 417,
"protocol": "tcp",
"service": "Onmux",
"oneLiner": "Registered as \"Onmux\"; the only surviving annotation ties it to ON Technology's Meeting Maker calendar server.",
"whatItIs": "IANA lists 417 as onmux with no description beyond the name and no protocol document. The one piece of corroborating information is Nmap's service database, which annotates both 417/tcp and 417/udp as \"Meeting maker\" — ON Technology's cross-platform group calendar server of the same era. That product is long gone and no specification was ever published. Everything else you could say about this port would be invention.",
"exposure": {
"verdict": "careful",
"note": "No published protocol and no maintained implementation; if something answers here, identify it locally and keep it off public interfaces."
},
"checkCommand": "nc -vz -w 3 TARGET 417",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 417",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=417",
"kind": "iana"
},
{
"title": "nmap-services — 417/tcp onmux \"Meeting maker\"",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
],
"ianaName": "onmux"
},
{
"port": 425,
"protocol": "tcp",
"service": "ICAD (icad-el)",
"oneLiner": "Registered to \"ICAD\" decades ago with no surviving specification — one of the registry's dead entries.",
"whatItIs": "IANA holds 425 as icad-el, described only as \"ICAD\" and assigned to an individual registrant. No protocol document, vendor page, or open implementation for it survives, so the registration is the entire public record. The port has a negligible open rate in Nmap's frequency data. If you find something listening on 425, the registered name is not evidence of what it is — probe the service and check the process on the host.",
"exposure": {
"verdict": "careful",
"note": "Effectively an unknown service: no spec, no maintainer, no basis for assuming it authenticates anything."
},
"checkCommand": "nmap -sV -p 425 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 425",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=425",
"kind": "iana"
}
],
"ianaName": "icad-el"
},
{
"port": 427,
"protocol": "both",
"service": "SLP (Service Location Protocol)",
"oneLiner": "Service Location Protocol — VMware ESXi, printers, and SAN gear advertising what they offer, and a serious DDoS reflector.",
"whatItIs": "SLP (RFC 2608) lets user agents discover services without configuration: agents multicast or unicast service requests to 427 and service agents reply with URLs, optionally through a directory agent that aggregates registrations. It shipped enabled by default on VMware ESXi, on network printers, on NetApp's SMI-S provider and on SUSE systems, which is why it still appears on scans of datacenter networks. Two things made it notorious: CVE-2021-21974, the ESXi OpenSLP heap overflow that the ESXiArgs ransomware campaign exploited at scale, and CVE-2023-29552, which lets an attacker register services and then reflect spoofed UDP at up to roughly 2,200x amplification.",
"exposure": {
"verdict": "never",
"note": "CISA added CVE-2023-29552 to its Known Exploited Vulnerabilities catalog and its required action is to disable SLP or block 427/UDP on anything reachable from an untrusted network."
},
"checkCommand": "nmap -sU -p 427 --script srvloc TARGET",
"links": [
{
"title": "RFC 2608 — Service Location Protocol, Version 2",
"url": "https://www.rfc-editor.org/rfc/rfc2608.html",
"kind": "spec"
},
{
"title": "CVE-2023-29552 — SLP reflective denial-of-service amplification",
"url": "https://www.cve.org/CVERecord?id=CVE-2023-29552",
"kind": "official-docs"
},
{
"title": "CVE-2021-21974 — ESXi OpenSLP heap overflow (the ESXiArgs vector)",
"url": "https://www.cve.org/CVERecord?id=CVE-2021-21974",
"kind": "official-docs"
},
{
"title": "openslp-org/openslp — the reference SLP implementation",
"url": "https://github.com/openslp-org/openslp",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 427",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=427",
"kind": "iana"
}
],
"ianaName": "svrloc"
},
{
"port": 443,
"protocol": "both",
"service": "HTTPS",
"oneLiner": "HTTPS — HTTP inside TLS on TCP, and HTTP/3 over QUIC on the UDP side of the same number.",
"whatItIs": "The TLS handshake authenticates the server with an X.509 certificate and names the target host via SNI, then HTTP/1.1 or HTTP/2 runs inside the encrypted channel; HTTP/3 uses the same port number over UDP with QUIC carrying its own TLS 1.3. This is the default port for essentially every public web service and API, and for a lot of non-web traffic tunneled through it because middleboxes let it pass. On a host, whatever holds 443 is the TLS terminator — a web server, a reverse proxy, or a load balancer agent. An open 443 says almost nothing about what is behind it.",
"exposure": {
"verdict": "fine",
"note": "The intended public port; risk lives in the application behind it and in the TLS configuration, not in the port being open."
},
"checkCommand": "openssl s_client -connect example.com:443 -servername example.com /dev/null | head -20",
"links": [
{
"title": "RFC 8446 — The Transport Layer Security (TLS) Protocol Version 1.3",
"url": "https://www.rfc-editor.org/rfc/rfc8446.html",
"kind": "spec"
},
{
"title": "RFC 9110 — HTTP Semantics (defines the https URI scheme)",
"url": "https://www.rfc-editor.org/rfc/rfc9110.html",
"kind": "spec"
},
{
"title": "nginx ngx_http_ssl_module documentation",
"url": "https://nginx.org/en/docs/http/ngx_http_ssl_module.html",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 444,
"protocol": "tcp",
"service": "SNPP (Simple Network Paging Protocol)",
"oneLiner": "The registered home of pager messaging — but in practice usually an alternate HTTPS or admin port.",
"whatItIs": "SNPP (RFC 1861) is a plain-text, SMTP-shaped protocol for delivering messages to pagers: connect, PAGE the recipient ID, MESS the text, SEND. Paging carriers ran it into the 2000s and a few emergency-notification systems still do. Far more often, though, an open 444 is something else entirely — administrators reach for it as a spare HTTPS or management port because it sits just past 443 and is easy to remember. Check whether it speaks TLS before assuming SNPP.",
"exposure": {
"verdict": "careful",
"note": "SNPP itself is unencrypted and historically accepted messages without authentication; if the listener is really an admin web UI on 444, judge it as you would any exposed management plane."
},
"checkCommand": "printf 'QUIT\\r\\n' | nc -v -w 5 TARGET 444",
"links": [
{
"title": "RFC 1861 — Simple Network Paging Protocol Version 3",
"url": "https://www.rfc-editor.org/rfc/rfc1861.html",
"kind": "spec"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 444",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=444",
"kind": "iana"
}
],
"ianaName": "snpp"
},
{
"port": 445,
"protocol": "tcp",
"service": "SMB",
"oneLiner": "SMB file and print sharing, TCP 445.",
"whatItIs": "Windows file servers, Samba, and macOS file sharing serve SMB2/SMB3 directly over TCP 445 — no NetBIOS session layer, unlike the legacy 137-139 ports. It carries file shares, printer shares, and named pipes used by Windows remote administration and domain traffic. It is on nearly every Windows host and any Linux box running smbd, which is why it dominates internal scans. It is also the port behind the best-known remote worm exploits (EternalBlue, WannaCry).",
"exposure": {
"verdict": "never",
"note": "SMB must never face the internet — it exposes credentials-bearing authentication and a long history of pre-auth remote code execution; keep it inside the LAN or behind a VPN."
},
"checkCommand": "smbclient -L //TARGET -N # or: nc -vz TARGET 445",
"links": [
{
"title": "[MS-SMB2]: Server Message Block Protocol Versions 2 and 3",
"url": "https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/5606ad47-5ee0-437a-817e-70c366052962",
"kind": "spec"
},
{
"title": "Samba (GitHub mirror)",
"url": "https://github.com/samba-team/samba",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 458,
"protocol": "tcp",
"service": "Apple QuickTime (appleqtc)",
"oneLiner": "Apple's old QuickTime TV / QuickTime Conferencing port, from products that no longer exist.",
"whatItIs": "IANA holds 458 as appleqtc, \"apple quick time\", registered by Apple for its QuickTime conferencing and streaming products of the late 1990s. Apple's streaming work moved to RTSP on 554 and RTP, QuickTime Streaming Server was discontinued, and QuickTime itself is gone from Windows and folded into AVFoundation on macOS. Apple's current port documentation does not list 458 at all. A listener here means legacy software on an old Mac rather than anything Apple ships now.",
"exposure": {
"verdict": "careful",
"note": "Discontinued media software receiving no security updates — keep it on the LAN if it must run at all."
},
"checkCommand": "nmap -sV -p 458 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 458",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=458",
"kind": "iana"
},
{
"title": "Apple — TCP and UDP ports used by Apple software products",
"url": "https://support.apple.com/en-us/103229",
"kind": "official-docs"
}
],
"ianaName": "appleqtc"
},
{
"port": 464,
"protocol": "both",
"service": "Kerberos kpasswd (password change)",
"oneLiner": "The Kerberos change-password service — on a Windows network, a domain controller sitting next to port 88.",
"whatItIs": "Port 464 carries the Kerberos password change and set protocol: a client presents a ticket obtained from the KDC and submits a new password, over both UDP and TCP. RFC 3244 specifies the Microsoft variant that adds administrative set-password, which is what Active Directory uses. Every AD domain controller listens here, as do MIT krb5 and Heimdal KDCs configured with kadmind. Finding 464 open alongside 88, 389 and 445 is the standard signature of a domain controller.",
"exposure": {
"verdict": "never",
"note": "A domain controller's password-change endpoint is a credential surface and part of the identity plane — it belongs on internal networks reachable only by domain members."
},
"checkCommand": "nmap -p 88,389,445,464 -sV TARGET",
"links": [
{
"title": "RFC 3244 — Microsoft Windows 2000 Kerberos Change Password and Set Password Protocols",
"url": "https://www.rfc-editor.org/rfc/rfc3244.html",
"kind": "spec"
},
{
"title": "MIT Kerberos — kdc.conf reference (kpasswd listener configuration)",
"url": "https://web.mit.edu/kerberos/krb5-latest/doc/admin/conf_files/kdc_conf.html",
"kind": "official-docs"
},
{
"title": "Microsoft — Service overview and network port requirements for Windows",
"url": "https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/service-overview-and-network-port-requirements",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 464",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=464",
"kind": "iana"
}
],
"ianaName": "kpasswd"
},
{
"port": 465,
"protocol": "tcp",
"service": "Submissions (SMTP over implicit TLS)",
"oneLiner": "Mail submission with implicit TLS — the client's outgoing-mail port, TCP 465.",
"whatItIs": "Mail servers (Postfix, Exim, Dovecot's submission proxy, hosted providers) listen on TCP 465 for authenticated message submission where TLS starts immediately on connect, before any SMTP greeting. RFC 8314 registered it as 'submissions' and recommends it over STARTTLS on 587 for new deployments; an earlier 'smtps' registration on this port was revoked, which is why the old name persists in configs. In Postfix it is the master.cf entry running smtpd with smtpd_tls_wrappermode=yes. It appears on a scan for any host that accepts mail from users, as opposed to server-to-server relay on port 25.",
"exposure": {
"verdict": "careful",
"note": "Fine to expose deliberately for remote users since TLS is mandatory from the first byte, but it is an authentication endpoint, so it needs rate limiting and brute-force protection."
},
"checkCommand": "openssl s_client -connect MAIL_HOST:465 -quiet",
"links": [
{
"title": "RFC 8314 — Cleartext Considered Obsolete: TLS for Email Submission and Access",
"url": "https://datatracker.ietf.org/doc/html/rfc8314",
"kind": "spec"
},
{
"title": "Postfix TLS_README",
"url": "https://www.postfix.org/TLS_README.html",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 481,
"protocol": "tcp",
"service": "Ph (CCSO nameserver)",
"oneLiner": "The CCSO Ph directory — the campus phone-book protocol that predated LDAP, now essentially extinct.",
"whatItIs": "Ph is the client protocol for the CCSO nameserver built at the University of Illinois, formalised in RFC 2378: a client sends text commands like \"query smith return email phone\" and the qi server answers with typed field data about people. Universities ran it as the campus directory through the 1990s, and mail clients shipped Ph lookup support before LDAP won. IANA registered 481 as the Ph service to the RFC's author, though many deployments answered on 105 instead. Any listener today is a museum piece.",
"exposure": {
"verdict": "careful",
"note": "A cleartext directory of names, phone numbers and email addresses that answers anonymous queries — exactly the bulk personal data you do not want scraped from a public IP."
},
"checkCommand": "printf 'quit\\r\\n' | nc -v -w 5 TARGET 481",
"links": [
{
"title": "RFC 2378 — The CCSO Nameserver (Ph) Architecture",
"url": "https://www.rfc-editor.org/rfc/rfc2378.html",
"kind": "spec"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 481",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=481",
"kind": "iana"
}
],
"ianaName": "ph"
},
{
"port": 497,
"protocol": "both",
"service": "Retrospect backup",
"oneLiner": "A Retrospect backup client waiting for its backup server to call — still shipping software, common on Macs.",
"whatItIs": "Retrospect is a long-running backup product for macOS, Windows and Linux, and 497 is its IANA-assigned port on both TCP and UDP. The client agent on each protected machine listens here, and the backup server uses the same port — including subnet broadcast and multicast — to discover and reach clients, which is why Retrospect's own firewall guidance says to open 497 TCP and UDP on both ends. On a Mac network it is one of the more common unexpected open ports, because installing the client opens it automatically.",
"exposure": {
"verdict": "never",
"note": "A backup agent reads every file on the machine — anything that can authenticate to it can pull the whole filesystem, so keep it strictly on the backup network."
},
"checkCommand": "nc -vz -w 3 TARGET 497",
"links": [
{
"title": "Retrospect — Opening your network firewall for Retrospect",
"url": "https://docs.retrospect.com/docs/opening-your-network-firewall-for-retrospect",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 497",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=497",
"kind": "iana"
}
],
"ianaName": "retrospect"
},
{
"port": 500,
"protocol": "both",
"service": "ISAKMP / IKE (IPsec key exchange)",
"oneLiner": "IKE — the key negotiation in front of every IPsec VPN, and the port that identifies a VPN concentrator.",
"whatItIs": "IKE runs over UDP 500 to authenticate the two peers and negotiate the keys and security associations that the IPsec ESP tunnel then uses; ISAKMP (RFC 2408) defined the original framework and IKEv2 (RFC 7296) is what current implementations speak. When a NAT sits in the path, peers detect it during the exchange and move to UDP 4500 with UDP encapsulation. IANA registers 500 for TCP as well, but the protocol is UDP in practice. An open 500 on a public address is a firewall, router, or VPN gateway doing exactly its job.",
"exposure": {
"verdict": "fine",
"note": "Public by design for site-to-site and remote-access VPN. Two caveats: IKEv1 aggressive mode with a pre-shared key hands an offline-crackable hash to any prober, and the handshake can be abused for UDP reflection — use IKEv2 with certificates and rate-limit the port."
},
"checkCommand": "nmap -sU -p 500 --script ike-version TARGET",
"links": [
{
"title": "RFC 7296 — Internet Key Exchange Protocol Version 2 (IKEv2)",
"url": "https://www.rfc-editor.org/rfc/rfc7296.html",
"kind": "spec"
},
{
"title": "RFC 2408 — Internet Security Association and Key Management Protocol (ISAKMP)",
"url": "https://www.rfc-editor.org/rfc/rfc2408.html",
"kind": "spec"
},
{
"title": "strongswan/strongswan — IKEv1/IKEv2 daemon",
"url": "https://github.com/strongswan/strongswan",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 500",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=500",
"kind": "iana"
}
],
"ianaName": "isakmp"
},
{
"port": 512,
"protocol": "tcp",
"service": "exec (BSD rexec)",
"oneLiner": "BSD rexec — run a command on a remote host, with the username and password sent in cleartext.",
"whatItIs": "IANA registers TCP 512 as \"exec\": remote process execution with authentication performed using passwords and UNIX login names. A client opens the connection, sends a NUL-separated username, password, and command line, and the rexecd server runs the command and streams back its output. It is the oldest and weakest of the three BSD r-services (512 exec, 513 rlogin, 514 rsh) and virtually every modern distribution ships rexecd disabled or not at all. On UDP the same number is comsat/biff, the local new-mail notifier, which is a different and equally obsolete service.",
"exposure": {
"verdict": "never",
"note": "The password crosses the wire in plaintext on every invocation and the whole session is unencrypted — there is no configuration that makes this safe. Replace it with SSH."
},
"checkCommand": "nc -vz -w 3 TARGET 512",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 512",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=512",
"kind": "iana"
}
]
},
{
"port": 513,
"protocol": "tcp",
"service": "rlogin",
"oneLiner": "BSD rlogin — a remote shell session that trusts the client host instead of asking for a password.",
"whatItIs": "rlogin, documented in RFC 1282, gives a terminal session much like Telnet, but its authentication is host-based: the server trusts a connection from a privileged source port if the client host and user appear in /etc/hosts.equiv or the target user's ~/.rhosts. That trust model is the reason it died — anyone who can spoof an address or compromise one trusted host inherits accounts everywhere. The traffic, including anything typed into the session, is unencrypted. UDP 513 is a different service entirely, rwho, which broadcasts who is logged in and the machine's load average.",
"exposure": {
"verdict": "never",
"note": "Cleartext interactive login with address-based trust — a .rhosts entry plus a spoofed or compromised peer is a remote shell. SSH replaced this in the 1990s."
},
"checkCommand": "nc -vz -w 3 TARGET 513",
"links": [
{
"title": "RFC 1282 — BSD Rlogin",
"url": "https://www.rfc-editor.org/rfc/rfc1282.html",
"kind": "spec"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 513",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=513",
"kind": "iana"
}
]
},
{
"port": 514,
"protocol": "both",
"service": "rsh (TCP) / syslog (UDP)",
"oneLiner": "Two unrelated services share this number: BSD rsh on TCP, and syslog on UDP.",
"whatItIs": "IANA registers TCP 514 as \"shell\" — the BSD rsh service, which runs a single command remotely using the same host-based .rhosts trust as rlogin, and which also opens a second connection back to the client for stderr. UDP 514 is syslog, the log-shipping protocol (RFC 5424 format, RFC 5426 UDP transport), and that is what almost every hit on 514 is today: routers, firewalls, and servers forwarding log lines to a collector. Syslog over TCP has no assigned port at all; RFC 6587 notes that implementations commonly borrow TCP/514 anyway, which is exactly why a TCP listener here is as likely to be a log collector as an rsh daemon.",
"exposure": {
"verdict": "never",
"note": "rsh is cleartext remote command execution with address-based trust. Plain syslog is unauthenticated and unencrypted, so an exposed collector can be flooded with forged log entries and, over UDP, used for spoofed traffic — send logs over TLS (RFC 5425) or a private network instead."
},
"checkCommand": "nmap -Pn -sV -p 514 TARGET",
"links": [
{
"title": "RFC 5424 — The Syslog Protocol",
"url": "https://www.rfc-editor.org/rfc/rfc5424.html",
"kind": "spec"
},
{
"title": "RFC 6587 — Transmission of Syslog Messages over TCP (on the unassigned TCP/514 habit)",
"url": "https://www.rfc-editor.org/rfc/rfc6587.html",
"kind": "spec"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 514",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=514",
"kind": "iana"
}
]
},
{
"port": 515,
"protocol": "tcp",
"service": "LPD (printer spooler)",
"oneLiner": "The Berkeley line printer daemon — a print queue, usually on a printer or an old Unix print server.",
"whatItIs": "LPD, specified in RFC 1179, is the original Unix network printing protocol: a client connects to TCP 515 and sends a one-byte command code plus a queue name to submit a job, list the queue, or remove jobs. The spec also expects the client to bind a source port in the range 721–731, which is its entire notion of authentication — a privileged source port means a trusted host. Most network printers still answer here for backward compatibility even though IPP on 631 is what modern print systems use, and CUPS can serve LPD clients through its cups-lpd helper.",
"exposure": {
"verdict": "never",
"note": "No real authentication — trust is based on source port and hostname — and job submission plus queue control is available to anyone who can reach the port. Keep print queues on the LAN."
},
"checkCommand": "nc -vz -w 3 TARGET 515",
"links": [
{
"title": "RFC 1179 — Line Printer Daemon Protocol",
"url": "https://www.rfc-editor.org/rfc/rfc1179.html",
"kind": "spec"
},
{
"title": "OpenPrinting CUPS (ships cups-lpd for RFC 1179 clients)",
"url": "https://github.com/OpenPrinting/cups",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 515",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=515",
"kind": "iana"
}
]
},
{
"port": 524,
"protocol": "tcp",
"service": "NCP (NetWare Core Protocol)",
"oneLiner": "NetWare Core Protocol — a Novell NetWare or eDirectory server, or something that inherited its stack.",
"whatItIs": "IANA registers 524 on both TCP and UDP as \"ncp\", the NetWare Core Protocol, which Novell used for file, print, and directory access. When NetWare moved off IPX to native IP, NCP settled on TCP 524, and the port carried forward into Novell/Micro Focus eDirectory servers where it is used for directory operations alongside LDAP. Outside of surviving eDirectory deployments you will effectively never see this on a modern scan.",
"exposure": {
"verdict": "never",
"note": "A directory and file-service control port for a legacy stack that no longer receives broad security attention — keep it on an internal segment."
},
"checkCommand": "nc -vz -w 3 TARGET 524",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 524",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=524",
"kind": "iana"
}
]
},
{
"port": 541,
"protocol": "both",
"service": "uucp-rlogin",
"oneLiner": "Registered as uucp-rlogin; essentially never seen in the wild.",
"whatItIs": "IANA registers TCP and UDP 541 as \"uucp-rlogin\", with no description beyond the name — an rlogin-style entry point associated with UUCP, the store-and-forward system that moved mail and files between Unix hosts over dial-up before the internet was ubiquitous. Regular UUCP over TCP lives on port 540. There is no widely deployed software listening on 541 today, so an open port here is almost certainly something unrelated that picked the number, not UUCP.",
"exposure": {
"verdict": "never",
"note": "If something really is answering here, identify it before anything else — an unexplained listener on an abandoned legacy port deserves investigation, not internet exposure."
},
"checkCommand": "nc -vz -w 3 TARGET 541",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 541",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=541",
"kind": "iana"
}
]
},
{
"port": 543,
"protocol": "tcp",
"service": "klogin (Kerberized rlogin)",
"oneLiner": "Kerberized rlogin — the r-services with Kerberos tickets instead of .rhosts trust.",
"whatItIs": "TCP 543 is registered as \"klogin\": rlogin authenticated with Kerberos, so the client presents a ticket rather than relying on host-based .rhosts files, and the session can optionally be encrypted. It was part of the Kerberos-patched application suite that shipped with MIT krb5 and with commercial Unix. MIT split those applications out of the core krb5 distribution in release 1.8 to be maintained separately, and SSH with GSSAPI has taken over the job, so a listener on 543 today means a very old Kerberos realm or an appliance that never updated.",
"exposure": {
"verdict": "never",
"note": "An unmaintained interactive login service; even when the Kerberos authentication holds, the deployment around it is a decade or more past support. Use SSH."
},
"checkCommand": "nc -vz -w 3 TARGET 543",
"links": [
{
"title": "MIT Kerberos 5 Release 1.8 release notes (\"Remove applications to a separate distribution\")",
"url": "https://web.mit.edu/Kerberos/krb5-1.8/README-1.8.txt",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 543",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=543",
"kind": "iana"
}
]
},
{
"port": 544,
"protocol": "tcp",
"service": "kshell (Kerberized rsh)",
"oneLiner": "Kerberized rsh — remote command execution authenticated by Kerberos ticket.",
"whatItIs": "IANA registers TCP 544 as \"kshell\", described simply as krcmd: the Kerberos version of rsh, which runs a single command on a remote host using a Kerberos ticket in place of the .rhosts host trust that plain rsh on 514 uses. Like klogin on 543, it came from the Kerberized application suite that MIT moved out of the krb5 core distribution in release 1.8, and it has been superseded by SSH with GSSAPI authentication. Seeing it open points at a legacy Kerberos realm or an old commercial Unix box.",
"exposure": {
"verdict": "never",
"note": "Remote command execution on an unmaintained service, and the surrounding realm is likely just as old. Nothing about this belongs on a public address."
},
"checkCommand": "nc -vz -w 3 TARGET 544",
"links": [
{
"title": "MIT krb5 source repository",
"url": "https://github.com/krb5/krb5",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 544",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=544",
"kind": "iana"
}
]
},
{
"port": 545,
"protocol": "tcp",
"service": "appleqtcsrvr",
"oneLiner": "Registered to Apple as appleqtcsrvr, from the discontinued QuickTime streaming line; nothing runs here now.",
"whatItIs": "IANA registers TCP and UDP 545 as \"appleqtcsrvr\" with no description beyond the name, and the same entry appears verbatim in the /etc/services file shipped with macOS. It dates from Apple's QuickTime server products, which Apple discontinued years ago — QuickTime Streaming Server and its Darwin Streaming Server sibling are gone, and current Apple media stacks use HTTP Live Streaming over ordinary HTTPS. There is no current software that listens here, so an open 545 is some other application that picked an unused low port.",
"exposure": {
"verdict": "never",
"note": "Whatever is answering is not the registered service, so treat it as unidentified until you have fingerprinted it — an unknown listener in the system port range is not something to publish."
},
"checkCommand": "nc -vz -w 3 TARGET 545",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 545",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=545",
"kind": "iana"
}
]
},
{
"port": 548,
"protocol": "tcp",
"service": "AFP over TCP",
"oneLiner": "Apple Filing Protocol — a Mac file share, a Time Machine target, or a NAS with AFP still switched on.",
"whatItIs": "AFP over TCP is Apple's native file-sharing protocol, and for years it was how Macs mounted volumes from each other, from macOS Server, and from NAS boxes. Apple has since moved to SMB as the default — APFS volumes cannot be shared over AFP at all — and Apple's macOS Sequoia enterprise notes state that the AFP client is deprecated and will be removed in a future macOS release. In practice, 548 open today means a NAS (Synology, QNAP, or a Netatalk server) still offering AFP for older Macs or legacy Time Machine backups.",
"exposure": {
"verdict": "never",
"note": "A file-share service on a deprecated protocol with a shrinking maintenance base, protected only by user passwords — keep it on the LAN or reach it over a VPN."
},
"checkCommand": "nc -vz -w 3 TARGET 548",
"links": [
{
"title": "Apple — What's new for enterprise in macOS Sequoia (AFP client deprecated)",
"url": "https://support.apple.com/en-us/121011",
"kind": "official-docs"
},
{
"title": "Apple — TCP and UDP ports used by Apple software products (548 = AFP over TCP)",
"url": "https://support.apple.com/en-us/103229",
"kind": "official-docs"
},
{
"title": "Netatalk — open source AFP file server",
"url": "https://github.com/Netatalk/netatalk",
"kind": "github"
}
]
},
{
"port": 554,
"protocol": "tcp",
"service": "RTSP",
"oneLiner": "RTSP — almost always an IP camera, NVR, or streaming appliance offering a video feed.",
"whatItIs": "RTSP is the control protocol for streaming media: a client sends OPTIONS/DESCRIBE/SETUP/PLAY over TCP 554 and the actual audio and video flow over RTP, either on separate UDP ports or interleaved back over the same TCP connection. In practice every hit on 554 is an IP camera, a DVR/NVR, or a video encoder, since that is the ecosystem that standardized on it (ONVIF profiles included). Clients like VLC and ffmpeg speak it directly with an rtsp:// URL.",
"exposure": {
"verdict": "never",
"note": "RTSP authentication is Basic or Digest over an unencrypted channel and vendor firmware routinely ships default credentials, which is why internet-facing 554 is the single largest source of publicly viewable private cameras."
},
"checkCommand": "printf 'OPTIONS rtsp://TARGET:554/ RTSP/1.0\\r\\nCSeq: 1\\r\\n\\r\\n' | nc -w 3 TARGET 554",
"links": [
{
"title": "RFC 7826 — Real-Time Streaming Protocol Version 2.0",
"url": "https://datatracker.ietf.org/doc/html/rfc7826",
"kind": "spec"
},
{
"title": "RFC 2326 — Real Time Streaming Protocol (RTSP 1.0, what devices actually implement)",
"url": "https://datatracker.ietf.org/doc/html/rfc2326",
"kind": "spec"
},
{
"title": "IANA port registry — 554",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=554",
"kind": "iana"
},
{
"title": "FFmpeg — RTSP client/server implementation",
"url": "https://github.com/FFmpeg/FFmpeg",
"kind": "github"
}
]
},
{
"port": 555,
"protocol": "tcp",
"service": "dsf",
"oneLiner": "Registered as dsf with no description and no known implementation — an open 555 is unidentified software.",
"whatItIs": "IANA lists TCP and UDP 555 under the service name \"dsf\" and gives no description, no assignee note, and no reference document; macOS ships the same bare entry in /etc/services. No maintained software is known to implement it. The number appears in circulated lists of trojan ports from the late 1990s, but those lists are unsourced folklore rather than documentation, so the only defensible statement is that anything listening on 555 has to be identified by fingerprinting it directly.",
"exposure": {
"verdict": "never",
"note": "An unexplained listener on a registered-but-unused system port is a finding to chase down, not a service to expose."
},
"checkCommand": "nc -vz -w 3 TARGET 555",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 555",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=555",
"kind": "iana"
}
]
},
{
"port": 563,
"protocol": "tcp",
"service": "NNTPS (NNTP over TLS)",
"oneLiner": "Usenet news over TLS — a news server, wrapped in TLS from the first byte.",
"whatItIs": "Port 563 is the implicit-TLS version of NNTP: the client opens the connection, negotiates TLS immediately, and only then starts the normal NNTP conversation of GROUP, ARTICLE, and POST commands. Plain NNTP lives on 119 and can also upgrade in place with the STARTTLS command. RFC 4642 actually discourages the separate-port approach, but 563 stayed in wide use and is what commercial Usenet providers and INN-based servers publish for TLS clients. On a scan it means a news server, which is a narrow and shrinking population.",
"exposure": {
"verdict": "fine",
"note": "A public news service is meant to face the internet and the transport is TLS-encrypted; the exposure to manage is the authentication behind it, not the port."
},
"checkCommand": "openssl s_client -connect TARGET:563 -quiet",
"links": [
{
"title": "RFC 4642 — Using TLS with NNTP",
"url": "https://www.rfc-editor.org/rfc/rfc4642.html",
"kind": "spec"
},
{
"title": "RFC 3977 — Network News Transfer Protocol (NNTP)",
"url": "https://www.rfc-editor.org/rfc/rfc3977.html",
"kind": "spec"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 563",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=563",
"kind": "iana"
}
]
},
{
"port": 587,
"protocol": "tcp",
"service": "Submission (SMTP with STARTTLS)",
"oneLiner": "Mail submission with STARTTLS — authenticated outgoing mail, TCP 587.",
"whatItIs": "RFC 6409 reserves TCP 587 for message submission: mail arriving here is a submission from an authenticated user, not a relay from another mail server, so the server may apply its own rules (rewriting headers, requiring AUTH). The connection starts in cleartext and the client issues STARTTLS to upgrade. Postfix, Exim, and every hosted mail provider run it, and it is the port mail clients are configured with when they are not using 465. On a scan it identifies a mail submission agent.",
"exposure": {
"verdict": "careful",
"note": "Expected to be internet-facing for remote users, but require AUTH and enforce TLS before AUTH — a misconfigured 587 that accepts unauthenticated mail becomes an open relay."
},
"checkCommand": "openssl s_client -starttls smtp -connect MAIL_HOST:587 -quiet",
"links": [
{
"title": "RFC 6409 — Message Submission for Mail",
"url": "https://datatracker.ietf.org/doc/html/rfc6409",
"kind": "spec"
},
{
"title": "RFC 8314 — TLS for Email Submission and Access",
"url": "https://datatracker.ietf.org/doc/html/rfc8314",
"kind": "spec"
},
{
"title": "Postfix TLS_README",
"url": "https://www.postfix.org/TLS_README.html",
"kind": "official-docs"
}
]
},
{
"port": 593,
"protocol": "tcp",
"service": "HTTP RPC endpoint mapper (RPC over HTTP)",
"oneLiner": "Windows RPC tunnelled over HTTP — the endpoint mapper for RPC/HTTP, historically Outlook Anywhere.",
"whatItIs": "IANA registers TCP 593 as \"http-rpc-epmap\": the HTTP RPC endpoint mapper. Microsoft's RPC over HTTP protocol ([MS-RPCH]) tunnels DCE/RPC traffic through an RPC-over-HTTP proxy so it can traverse firewalls, and 593 is the endpoint-mapper counterpart to the plain DCE endpoint mapper on TCP 135. Its best-known consumer was Outlook Anywhere against Exchange; the proxy itself normally publishes over 443, so 593 turning up on a scan is a Windows server exposing the RPC/HTTP plumbing directly.",
"exposure": {
"verdict": "never",
"note": "This is an RPC control plane. Every reason TCP 135 is blocked at the perimeter applies here — clients should reach RPC/HTTP through the HTTPS proxy on 443, never this port."
},
"checkCommand": "nc -vz -w 3 TARGET 593",
"links": [
{
"title": "[MS-RPCH]: Remote Procedure Call over HTTP Protocol",
"url": "https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-rpch/c0f4c9c5-1a61-4d10-b8e2-005378d1d212",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 593",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=593",
"kind": "iana"
}
]
},
{
"port": 616,
"protocol": "both",
"service": "sco-sysmgr",
"oneLiner": "SCO System Administration Server — the admin service of a SCO Unix box, and those are museum pieces.",
"whatItIs": "IANA registers TCP and UDP 616 as \"sco-sysmgr\", the SCO System Administration Server, from the SCO OpenServer and UnixWare line. It is one of a small cluster of SCO administrative ports registered in the same range, alongside sco-dtmgr on 617. SCO Unix has had no meaningful presence for two decades, so a listener here is either genuinely ancient industrial or point-of-sale hardware, or unrelated software that happened to pick 616.",
"exposure": {
"verdict": "never",
"note": "A system administration plane on an operating system that stopped receiving security fixes long ago. If this is real SCO, it should be behind a firewall and on a plan to be retired."
},
"checkCommand": "nc -vz -w 3 TARGET 616",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 616",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=616",
"kind": "iana"
}
]
},
{
"port": 617,
"protocol": "tcp",
"service": "sco-dtmgr",
"oneLiner": "SCO Desktop Administration Server — the companion to 616 on the same extinct Unix line.",
"whatItIs": "IANA registers TCP and UDP 617 as \"sco-dtmgr\", the SCO Desktop Administration Server, part of the same block of SCO administrative services as sco-sysmgr on 616. Like its neighbour it belongs to SCO OpenServer/UnixWare systems that have been out of general use for many years. There is no current documentation for the wire protocol and no maintained client, so an open 617 is worth fingerprinting rather than assuming.",
"exposure": {
"verdict": "never",
"note": "An administrative service on unsupported legacy Unix — internal networks only, and preferably not at all."
},
"checkCommand": "nc -vz -w 3 TARGET 617",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 617",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=617",
"kind": "iana"
}
]
},
{
"port": 625,
"protocol": "tcp",
"service": "dec-dlm / Apple ODProxy",
"oneLiner": "Registered to DEC's distributed lock manager, but on a Mac it is Open Directory Proxy.",
"whatItIs": "IANA registers 625 as dec-dlm (previously spelled dec_dlm), the Digital Equipment Corporation Distributed Lock Manager from the VMS cluster era, which you will not encounter today. The number is widely reported on macOS as Open Directory Proxy — odproxyd, which relays directory lookups for a Mac bound to an Open Directory domain — but Apple publishes no documentation for the port, so treat that as a field observation and confirm it against the running process rather than the registry name.",
"exposure": {
"verdict": "never",
"note": "If this is Open Directory Proxy, it answers questions about your account namespace and belongs on a managed LAN; if it is something else, you do not know what it is until you identify the process."
},
"checkCommand": "nc -vz -w 3 TARGET 625",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 625",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=625",
"kind": "iana"
}
]
},
{
"port": 631,
"protocol": "tcp",
"service": "IPP / CUPS",
"oneLiner": "The Internet Printing Protocol — a printer, or the CUPS print server on a Mac or Linux box.",
"whatItIs": "IPP is HTTP with a binary message body: clients POST operations like Print-Job and Get-Printer-Attributes to an ipp:// URL, and RFC 8010 requires printers to support HTTP on the IANA-assigned well-known port 631. CUPS, the print system on macOS and most Linux distributions, listens here for both printing and its web administration interface at http://localhost:631/. Nearly every AirPrint or IPP Everywhere network printer answers on 631 as well, which makes it one of the most common open ports on an office LAN.",
"exposure": {
"verdict": "careful",
"note": "Fine on a trusted LAN, where it is designed to live. Exposed publicly it leaks the print queue and device details and hands strangers the CUPS admin interface and a print-job submission path — bind CUPS to localhost or the local subnet."
},
"checkCommand": "curl -sI http://TARGET:631/",
"links": [
{
"title": "RFC 8010 — IPP/1.1: Encoding and Transport (well-known port 631)",
"url": "https://www.rfc-editor.org/rfc/rfc8010.html",
"kind": "spec"
},
{
"title": "RFC 8011 — IPP/1.1: Model and Semantics",
"url": "https://www.rfc-editor.org/rfc/rfc8011.html",
"kind": "spec"
},
{
"title": "OpenPrinting CUPS",
"url": "https://github.com/OpenPrinting/cups",
"kind": "github"
}
]
},
{
"port": 636,
"protocol": "tcp",
"service": "LDAPS",
"oneLiner": "LDAP wrapped in TLS from the first byte — usually a domain controller or a directory server.",
"whatItIs": "LDAPS is the implicit-TLS form of LDAP: the client negotiates TLS on connect and then speaks ordinary LDAP inside it, in contrast to plain LDAP on 389 which upgrades in place using the StartTLS extended operation defined in RFC 4513. The separate port predates StartTLS and was never formally standardised by the IETF, but IANA registered it and everyone implements it — Active Directory domain controllers, OpenLDAP, and every appliance that authenticates against a directory. Active Directory also offers a TLS-wrapped global catalog on 3269.",
"exposure": {
"verdict": "careful",
"note": "The transport is encrypted, so this is the right port to use if a directory must be reachable — but the directory holds your entire user and group namespace, so restrict it to known networks or a VPN and never expose plain LDAP on 389 alongside it."
},
"checkCommand": "ldapsearch -H ldaps://TARGET:636 -x -s base -b '' namingContexts",
"links": [
{
"title": "RFC 4513 — LDAP: Authentication Methods and Security Mechanisms (StartTLS)",
"url": "https://www.rfc-editor.org/rfc/rfc4513.html",
"kind": "spec"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 636",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=636",
"kind": "iana"
},
{
"title": "OpenLDAP source repository",
"url": "https://github.com/openldap/openldap",
"kind": "github"
}
]
},
{
"port": 646,
"protocol": "both",
"service": "LDP (MPLS Label Distribution Protocol)",
"oneLiner": "MPLS label distribution between routers — this is carrier and enterprise-core network gear.",
"whatItIs": "LDP, specified in RFC 5036, is how MPLS label switching routers tell each other which labels map to which forwarding equivalence classes. It uses both transports on port 646: UDP 646 carries the periodic Hello discovery messages sent to the \"all routers on this subnet\" multicast group, and TCP 646 carries the session, advertisement, and notification messages once two routers decide to peer. Anything answering here is a router in an MPLS network — Cisco IOS, Juniper Junos, or a Linux router running FRRouting.",
"exposure": {
"verdict": "never",
"note": "A routing control plane. An unauthenticated LDP peer that can reach the port can influence label distribution, so restrict it to known neighbours and protect the sessions (RFC 5036 provides for TCP MD5 authentication)."
},
"checkCommand": "nc -vz -w 3 TARGET 646",
"links": [
{
"title": "RFC 5036 — LDP Specification",
"url": "https://www.rfc-editor.org/rfc/rfc5036.html",
"kind": "spec"
},
{
"title": "FRRouting (implements ldpd)",
"url": "https://github.com/FRRouting/frr",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 646",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=646",
"kind": "iana"
}
]
},
{
"port": 648,
"protocol": "tcp",
"service": "RRP (Registry Registrar Protocol)",
"oneLiner": "The old domain-registrar protocol for .com/.net registries, retired in favour of EPP.",
"whatItIs": "RRP is documented in RFC 2832 as the NSI Registry Registrar Protocol version 1.1.0 — an Informational, not standards-track, specification for a 7-bit US-ASCII text protocol on TCP 648 that let accredited registrars add, delete, and modify second-level domain registrations in a TLD registry. It was Network Solutions' interface for the shared registry system. The industry replaced it with EPP (RFC 5730, STD 69), which registries run on TCP 700, so there is no live RRP service to find today.",
"exposure": {
"verdict": "never",
"note": "A retired registry provisioning interface — it carried the authority to change domain registrations, and nothing should be answering on it now."
},
"checkCommand": "nc -vz -w 3 TARGET 648",
"links": [
{
"title": "RFC 2832 — NSI Registry Registrar Protocol (RRP) Version 1.1.0",
"url": "https://www.rfc-editor.org/rfc/rfc2832.html",
"kind": "spec"
},
{
"title": "RFC 5730 — Extensible Provisioning Protocol (EPP), the replacement",
"url": "https://www.rfc-editor.org/rfc/rfc5730.html",
"kind": "spec"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 648",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=648",
"kind": "iana"
}
]
},
{
"port": 666,
"protocol": "both",
"service": "mdqs / doom",
"oneLiner": "Registered twice — as mdqs, and to id Software for Doom — but neither is what you will find running.",
"whatItIs": "IANA carries two registrations for 666 on both TCP and UDP: \"mdqs\", with no description, and \"doom\", assigned to id Software. The Doom entry is a 1990s artefact from the era when games registered ports; Doom's own multiplayer ran over IPX, and modern source ports such as Chocolate Doom and GZDoom use their own UDP ports rather than 666. Because the number is memorable and unclaimed in practice, it gets picked deliberately by hobby projects and by scanner and malware authors alike, so treat a listener here as unidentified until you fingerprint it.",
"exposure": {
"verdict": "never",
"note": "Nothing standard listens here, so an open 666 is an unknown service you have not accounted for — identify it before deciding anything else about it."
},
"checkCommand": "nc -vz -w 3 TARGET 666",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 666",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=666",
"kind": "iana"
}
]
},
{
"port": 667,
"protocol": "tcp",
"service": "disclose",
"oneLiner": "Registered as \"disclose\" for campaign contribution disclosures; no public implementation exists.",
"whatItIs": "IANA registers TCP and UDP 667 as \"disclose\", described as campaign contribution disclosures for SDR Technologies. It is one of the more specific and less used registrations in the system port range, with no published protocol specification and no software you can point at. Anything listening on 667 in practice is unrelated to the registration.",
"exposure": {
"verdict": "never",
"note": "Effectively an unused system port, so a listener is unaccounted-for software — investigate it rather than expose it."
},
"checkCommand": "nc -vz -w 3 TARGET 667",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 667",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=667",
"kind": "iana"
}
]
},
{
"port": 668,
"protocol": "tcp",
"service": "mecomm",
"oneLiner": "Registered as mecomm, with no description and nothing known to implement it.",
"whatItIs": "IANA lists TCP and UDP 668 under the service name \"mecomm\" with only \"MeComm\" as the description, no reference document, and no assignee note; the same bare entry ships in the /etc/services file on macOS. No maintained software is known to use it. The honest answer for this port is that the registration is all there is, and any open 668 needs to be identified from its banner or process, not from the port number.",
"exposure": {
"verdict": "never",
"note": "An unexplained listener on an otherwise unused system port — find out what it is before it faces anything."
},
"checkCommand": "nc -vz -w 3 TARGET 668",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 668",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=668",
"kind": "iana"
}
]
},
{
"port": 683,
"protocol": "tcp",
"service": "CORBA IIOP",
"oneLiner": "The registered port for CORBA's Internet Inter-ORB Protocol, though most ORBs never actually use it.",
"whatItIs": "IIOP is the on-the-wire mapping of CORBA's GIOP messages onto TCP, used by object request brokers to invoke methods on remote objects. IANA registered 683 for it, but in practice ORBs bind an arbitrary high port and publish it inside the object reference (IOR), so a CORBA deployment rarely has anything listening here. When you do see 683 open it is usually an enterprise Java or C++ middleware stack that was explicitly configured to the registered port. Anything answering it speaks a binary protocol with no authentication of its own.",
"exposure": {
"verdict": "never",
"note": "CORBA method invocation is a remote-code surface with no built-in authentication unless CSIv2/SSL was configured; keep ORBs on internal networks."
},
"checkCommand": "nmap -sV -p 683 TARGET",
"links": [
{
"title": "OMG CORBA specification (GIOP/IIOP)",
"url": "https://www.omg.org/spec/CORBA/",
"kind": "spec"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 687,
"protocol": "tcp",
"service": "asipregistry",
"oneLiner": "An Apple registration from the AppleShare IP era; you will almost never see it live.",
"whatItIs": "IANA lists 687 as \"asipregistry\", registered by Erik Sea of Apple during the AppleShare IP period. It was a registry/lookup companion to AppleShare services, not the file protocol itself — AFP has always run on 548. No public protocol specification was ever published and modern macOS does not open it. On a scan it is effectively noise: either a very old Mac server or an unrelated service squatting on the number.",
"exposure": {
"verdict": "careful",
"note": "Undocumented and unauthenticated by any published spec; if something is listening here, identify what it actually is before leaving it reachable."
},
"checkCommand": "nc -vz TARGET 687",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 691,
"protocol": "tcp",
"service": "MS Exchange Routing",
"oneLiner": "The link state routing channel between Exchange 2000/2003 routing group masters.",
"whatItIs": "Exchange 2000 and 2003 used a link state algorithm to share the health of connectors between routing groups, and the routing group master exchanged that state over TCP 691. Microsoft dropped routing groups in Exchange 2007 in favour of Active Directory sites, so this port disappeared from supported deployments nearly two decades ago. Nmap still labels it \"resvc\" after the Exchange Routing Engine service. Seeing it open today means an unpatched, long-unsupported Exchange server is still running.",
"exposure": {
"verdict": "never",
"note": "It is an internal mail-infrastructure control channel, and its presence implies an end-of-life Exchange server that should not be internet-facing at all."
},
"checkCommand": "nmap -sV -p 691 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 700,
"protocol": "tcp",
"service": "EPP",
"oneLiner": "Extensible Provisioning Protocol — how domain registrars create and update domains at a registry.",
"whatItIs": "EPP (RFC 5730) is the XML request/response protocol registrars use to register, renew, transfer and delete domain names, hosts and contacts at a registry such as Verisign or a ccTLD operator. RFC 5734 defines its TCP transport: each session runs inside TLS on port 700, opens with a greeting, and requires a login command with registrar credentials. Registries restrict it to allowlisted registrar source IPs with client certificates, so it is public-by-design but never open to the world. If you find 700 open, it is a registry, a registrar's test/OT&E endpoint, or an EPP server implementation someone is developing against.",
"exposure": {
"verdict": "careful",
"note": "Legitimately reachable across the internet, but only ever from allowlisted registrar IPs with mutual TLS — an EPP endpoint accepting arbitrary sources is misconfigured."
},
"checkCommand": "openssl s_client -connect TARGET:700",
"links": [
{
"title": "RFC 5730 — Extensible Provisioning Protocol (EPP)",
"url": "https://www.rfc-editor.org/rfc/rfc5730.html",
"kind": "spec"
},
{
"title": "RFC 5734 — EPP Transport over TCP",
"url": "https://www.rfc-editor.org/rfc/rfc5734.html",
"kind": "spec"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 705,
"protocol": "tcp",
"service": "AgentX",
"oneLiner": "Where SNMP subagents plug their MIB subtrees into a master agent.",
"whatItIs": "AgentX (RFC 2741) splits an SNMP agent into a master agent that owns port 161 and subagents that register parts of the MIB tree with it; RFC 2741 assigns TCP 705 for that master/subagent link. Net-SNMP and similar stacks usually prefer a Unix domain socket (/var/agentx/master) and only fall back to TCP 705 when subagents live on another process boundary or host. The protocol has no authentication of its own — whatever connects can register or replace MIB subtrees on the master agent. On a scan it means a managed device or server with AgentX enabled over TCP.",
"exposure": {
"verdict": "never",
"note": "Unauthenticated by design and trusted to serve SNMP data; bind it to loopback or a Unix socket, never a routable interface."
},
"checkCommand": "sudo lsof -nP -iTCP:705 -sTCP:LISTEN",
"links": [
{
"title": "RFC 2741 — Agent Extensibility (AgentX) Protocol Version 1",
"url": "https://www.rfc-editor.org/rfc/rfc2741.html",
"kind": "spec"
},
{
"title": "Net-SNMP source repository",
"url": "https://github.com/net-snmp/net-snmp",
"kind": "github"
}
]
},
{
"port": 711,
"protocol": "both",
"service": "Cisco TDP",
"oneLiner": "Cisco's pre-standard Tag Distribution Protocol, the ancestor of MPLS LDP on 646.",
"whatItIs": "TDP is Cisco's proprietary label distribution protocol from before the IETF standardised LDP. Cisco's MPLS FAQ states plainly that \"LDP uses TCP port 646, and TDP uses TCP port 711\", and that the port only opens on an interface once `mpls ip` is configured; TDP hellos are sent to UDP 711. Routers use the TCP session to advertise label bindings to their TDP peers. Anything still speaking TDP instead of LDP is old IOS running a legacy MPLS core.",
"exposure": {
"verdict": "never",
"note": "This is an MPLS control-plane session between trusted routers; reachable from outside the core it lets an attacker attempt to inject label bindings."
},
"checkCommand": "nmap -p 711 TARGET",
"links": [
{
"title": "Cisco — MPLS FAQ For Beginners",
"url": "https://www.cisco.com/c/en/us/support/docs/multiprotocol-label-switching-mpls/mpls/4649-mpls-faq-4649.html",
"kind": "official-docs"
},
{
"title": "RFC 5036 — LDP Specification (the standardised successor)",
"url": "https://www.rfc-editor.org/rfc/rfc5036.html",
"kind": "spec"
}
]
},
{
"port": 714,
"protocol": "tcp",
"service": "IRIS over XPCS",
"oneLiner": "A dead-end transport for the IRIS registry query protocol; RDAP won instead.",
"whatItIs": "IRIS was the IETF's structured replacement for whois, and RFC 4992 defines running it over XPCS (XML Pipelining with Chunks for SOAP), which uses TCP port 714 with TLS. The design never saw meaningful deployment: registries kept port 43 whois and then moved to RDAP over HTTPS. There is essentially no production software listening here today. A hit on 714 is far more likely to be an unrelated service than an IRIS server.",
"exposure": {
"verdict": "careful",
"note": "IRIS itself was a read-only query service, but an open 714 in practice means an unidentified listener — find out what it really is."
},
"checkCommand": "nc -vz TARGET 714",
"links": [
{
"title": "RFC 4992 — XML Pipelining with Chunks for IRIS",
"url": "https://www.rfc-editor.org/rfc/rfc4992.html",
"kind": "spec"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 720,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Not registered with IANA and not tied to any known protocol.",
"whatItIs": "Port 720 has no entry in the IANA service name and port number registry, and Nmap's service database lists it as \"unknown\" with a very low observed frequency. There is no well-documented application, malware family, or convention that claims it. Anything listening here is a locally chosen port — an internal service, a test harness, or a tunnel endpoint. The only way to know what it is, is to fingerprint it.",
"exposure": {
"verdict": "careful",
"note": "An unregistered port tells you nothing about what is behind it; identify the service before deciding whether it belongs on a public interface."
},
"checkCommand": "nmap -sV -p 720 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 722,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unregistered at IANA; occasionally chosen by hand as an alternate SSH port, nothing more.",
"whatItIs": "IANA has no assignment for 722, and Nmap records it as \"unknown\". Because it sits just above the assigned block around 720 it sometimes gets picked as a hand-configured port for SSH or another admin service by people trying to move off 22. That is a local convention, not a standard, so there is no protocol you can assume from the number alone. Fingerprint whatever answers before treating it as anything in particular.",
"exposure": {
"verdict": "careful",
"note": "Moving a service to an unregistered port hides it from casual scans but not from a service scan; judge the exposure by the service you find, not the number."
},
"checkCommand": "nmap -sV -p 722 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 726,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "No IANA registration and no documented service — a blank number.",
"whatItIs": "726 is absent from the IANA registry and listed as \"unknown\" in Nmap's service database, with one of the lowest observed open-port frequencies in this range. No published protocol, product default, or documented malware uses it. If it is open, it belongs to something configured locally on that host.",
"exposure": {
"verdict": "careful",
"note": "Nothing about the port number justifies exposing it; determine the service first."
},
"checkCommand": "nmap -sV -p 726 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 749,
"protocol": "tcp",
"service": "kerberos-adm",
"oneLiner": "The Kerberos admin plane — kadmind, where principals and keys are created and changed.",
"whatItIs": "IANA registers 749 as \"kerberos administration\", and MIT Kerberos runs kadmind here: the daemon that serves the kadmin protocol for creating principals, changing keys, and editing the KDC database. It authenticates callers with Kerberos itself and enforces an ACL file (kadm5.acl), and it is a different service from the KDC on 88 and from kpasswd on 464. On a scan, 749 next to 88 identifies a KDC — and specifically its administrative interface.",
"exposure": {
"verdict": "never",
"note": "This is the write interface to your realm's identity database; restrict it to admin hosts and keep it off any internet-facing interface."
},
"checkCommand": "nc -vz TARGET 749",
"links": [
{
"title": "MIT Kerberos — kadmind documentation",
"url": "https://web.mit.edu/kerberos/krb5-latest/doc/admin/admin_commands/kadmind.html",
"kind": "official-docs"
},
{
"title": "MIT krb5 source repository",
"url": "https://github.com/krb5/krb5",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 765,
"protocol": "tcp",
"service": "webster",
"oneLiner": "A registration for an early network dictionary service that no longer exists in the wild.",
"whatItIs": "IANA lists 765 as \"webster\", registered by Josyula R. Rao, for a network dictionary-lookup service from the pre-web era. No RFC was published for it, and the role it filled was later taken by DICT (RFC 2229), which is a different protocol on port 2628. There is no maintained webster server today. An open 765 is almost certainly an unrelated locally configured service.",
"exposure": {
"verdict": "careful",
"note": "The registered service is extinct, so anything answering here is unidentified until you fingerprint it."
},
"checkCommand": "nmap -sV -p 765 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "RFC 2229 — A Dictionary Server Protocol (the later DICT protocol, port 2628)",
"url": "https://www.rfc-editor.org/rfc/rfc2229.html",
"kind": "spec"
}
]
},
{
"port": 777,
"protocol": "tcp",
"service": "multiling-http",
"oneLiner": "Registered as \"Multiling HTTP\" with no public specification and effectively no deployment.",
"whatItIs": "IANA assigns 777 to \"multiling-http\", registered by Alejandro Bonet. No RFC, vendor documentation, or open-source implementation of the protocol was ever published, so nothing is known about it beyond the registry entry. Nothing in common use listens here. A memorable number like 777 is more often picked by hand for an internal HTTP service or a proxy than used for its registration.",
"exposure": {
"verdict": "careful",
"note": "Judge by the service you actually fingerprint; the registration carries no security properties worth reasoning about."
},
"checkCommand": "nmap -sV -p 777 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 783,
"protocol": "tcp",
"service": "SpamAssassin spamd",
"oneLiner": "Apache SpamAssassin's scanning daemon, which trusts anything that can reach it.",
"whatItIs": "spamd is the long-running SpamAssassin server that mail systems hand messages to for scoring, avoiding a Perl startup per message; its documented default listening port is 783 and clients such as spamc connect to it. It is not IANA-registered — 783 is SpamAssassin's own convention. The protocol has no authentication: any client that can connect may submit mail for scanning, and where --allow-tell is enabled it can also drive Bayes learn/forget commands. Default configurations bind localhost, so an externally open 783 is a misconfiguration.",
"exposure": {
"verdict": "never",
"note": "Unauthenticated, and it costs real CPU per submitted message; bind it to loopback or a private interface behind the MTA."
},
"checkCommand": "nc -vz 127.0.0.1 783",
"links": [
{
"title": "Apache SpamAssassin — spamd documentation",
"url": "https://spamassassin.apache.org/full/4.0.x/doc/spamd.html",
"kind": "official-docs"
},
{
"title": "Apache SpamAssassin source repository",
"url": "https://github.com/apache/spamassassin",
"kind": "github"
}
]
},
{
"port": 787,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Explicitly unassigned by IANA since 2002, yet it turns up open more often than its neighbours.",
"whatItIs": "The IANA registry carries an explicit \"Unassigned\" row for 787 dated 2002-10-08, meaning a previous assignment was withdrawn. Nmap labels it \"qsc\" and records an open-port frequency roughly an order of magnitude above the surrounding unassigned ports, which suggests some product or appliance uses it by convention without ever registering it. No public specification identifies what that is. Treat a listener here as unidentified until fingerprinted.",
"exposure": {
"verdict": "careful",
"note": "Comparatively common in scan data but with no documented protocol behind it; find out what the process is before leaving it reachable."
},
"checkCommand": "nmap -sV -p 787 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "Nmap service frequency database (nmap-services)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 800,
"protocol": "tcp",
"service": "mdbs-daemon",
"oneLiner": "An old database-daemon registration; in practice a round number people pick for internal HTTP.",
"whatItIs": "IANA assigns 800 to \"mdbs-daemon\" (registered under the older name mdbs_daemon), with no RFC, vendor documentation, or public implementation attached to it. Nothing in current use implements the registered protocol. What you actually find on 800 is usually something chosen by hand: an alternate HTTP listener, an admin console, or a proxy, because it is a memorable number just above the reserved 1-1023 boundary services.",
"exposure": {
"verdict": "careful",
"note": "Almost always an ad-hoc HTTP or admin service rather than the registered protocol; check what it is and whether it has authentication."
},
"checkCommand": "curl -sv -o /dev/null http://TARGET:800/",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 801,
"protocol": "tcp",
"service": "device",
"oneLiner": "Registered under the bare name \"device\" with no description and no known implementation.",
"whatItIs": "The IANA registry entry for 801 is the service name \"device\" with an empty description and no recorded contact or reference. No specification was ever published, and there is no software known to implement it. Nmap lists the same name purely because it mirrors the registry. Anything answering on 801 is a locally chosen listener that has nothing to do with the registration.",
"exposure": {
"verdict": "careful",
"note": "The name tells you nothing; fingerprint the listener and judge its exposure on what it actually is."
},
"checkCommand": "nmap -sV -p 801 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 808,
"protocol": "tcp",
"service": "alternate HTTP / CCProxy / net.tcp",
"oneLiner": "Unregistered but busy: CCProxy's HTTP proxy, .NET net.tcp services, and assorted alternate web ports.",
"whatItIs": "IANA has no assignment for 808, but it is one of the more commonly open ports in this range. Nmap names it \"ccproxy-http\" after CCProxy, a Windows HTTP/FTP/Gopher proxy that uses it by default, and an open 808 on a Windows host is often exactly that. It is also the default port for Microsoft's net.tcp:// WCF endpoints and the Net.TCP Port Sharing Service, and a popular hand-picked alternate HTTP port for internal web apps. Which of these you have is decided entirely by fingerprinting, since the three speak completely different protocols.",
"exposure": {
"verdict": "never",
"note": "An open proxy on 808 will be found and abused for relayed traffic within days; WCF endpoints are internal RPC. Neither belongs on a public IP unauthenticated."
},
"checkCommand": "curl -sv -x TARGET:808 -o /dev/null http://example.com/",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "Nmap service frequency database (nmap-services)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
},
{
"title": "Microsoft — Net.TCP Port Sharing (WCF)",
"url": "https://learn.microsoft.com/en-us/dotnet/framework/wcf/feature-details/net-tcp-port-sharing",
"kind": "official-docs"
}
]
},
{
"port": 843,
"protocol": "tcp",
"service": "Flash socket policy server",
"oneLiner": "Where Adobe Flash asked permission before opening a raw socket — a relic of a dead plugin.",
"whatItIs": "Flash Player 9 and later required a cross-domain policy before a SWF could open a socket to a host: it connected to TCP 843 on that host, sent the literal string `` followed by a NUL byte, and expected an XML policy document in reply. Sites running Flash chat, games or sockets-based apps therefore ran a tiny policy daemon such as flashpolicyd on 843 alongside the real service. The port was never IANA-registered — it was Adobe's convention. Flash reached end of life in December 2020, so a listener here today is a forgotten leftover process.",
"exposure": {
"verdict": "careful",
"note": "The daemon only ever emits a static XML policy, but a permissive `` was a real cross-domain hole; with Flash dead, the right move is to turn it off."
},
"checkCommand": "printf '\\0' | nc TARGET 843",
"links": [
{
"title": "flashpolicyd — Flash socket policy daemon (listens on 843)",
"url": "https://github.com/ripienaar/flashpolicyd",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 873,
"protocol": "tcp",
"service": "rsync daemon",
"oneLiner": "rsync in daemon mode — public mirrors run it on purpose, and so do accidentally exposed backups.",
"whatItIs": "Running `rsync --daemon` opens TCP 873 and serves named modules defined in rsyncd.conf, each mapping to a directory tree with its own read-only, auth-users and hosts-allow settings. This is the native rsync protocol, not rsync-over-SSH, and modules configured without auth-users are readable by anyone who connects — which is exactly how Linux distribution and CPAN mirrors are meant to work. It is also the classic accidental data leak: a backup module left world-readable, or worse, writable. Listing modules requires no credentials, so a connect immediately tells you what is on offer.",
"exposure": {
"verdict": "careful",
"note": "Fine for a deliberate public mirror with read-only modules; anything else needs auth-users, hosts-allow, and a check that no module exports a filesystem root."
},
"checkCommand": "rsync rsync://rsync.samba.org/",
"links": [
{
"title": "rsync project home",
"url": "https://rsync.samba.org/",
"kind": "official-docs"
},
{
"title": "rsyncd.conf(5) manual page",
"url": "https://download.samba.org/pub/rsync/rsyncd.conf.5",
"kind": "official-docs"
},
{
"title": "rsync source repository",
"url": "https://github.com/RsyncProject/rsync",
"kind": "github"
}
]
},
{
"port": 880,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "No IANA registration; when it is open it is nearly always just another web server.",
"whatItIs": "880 has no entry in the IANA registry and Nmap lists it as \"unknown\", though it shows up open somewhat more than neighbouring unregistered ports. There is no protocol associated with the number — its use is entirely ad hoc, most often an alternate HTTP listener or an appliance's management page picked to sit near 80 and 8080. Fingerprint it rather than assuming.",
"exposure": {
"verdict": "careful",
"note": "Usually an HTTP service that was moved off 80 rather than secured; obscurity is not access control, so check its authentication."
},
"checkCommand": "curl -sv -o /dev/null http://TARGET:880/",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 888,
"protocol": "tcp",
"service": "AccessBuilder / CDDB",
"oneLiner": "Registered to 3Com AccessBuilder, remembered for CDDB, and used today as an alternate HTTP port.",
"whatItIs": "IANA's formal assignment for 888 is \"AccessBuilder\", a 3Com remote-access product from the 1990s. The registry carries a second entry for cddbp, the CD Database Protocol, explicitly annotated as recording an unassigned but widespread use: CD players queried CDDB/freedb here for album track listings before that ecosystem moved to HTTP-based services. Neither is meaningfully deployed now. In practice an open 888 is a hand-configured web or admin service, which is why Nmap sees it open relatively often.",
"exposure": {
"verdict": "careful",
"note": "The historical protocols are gone; what is actually listening is typically an alternate HTTP or admin interface, so judge it on that service's authentication."
},
"checkCommand": "nmap -sV -p 888 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 898,
"protocol": "tcp",
"service": "Solaris Management Console",
"oneLiner": "The SMC server on Solaris 8 and 9 — a remote system-administration listener.",
"whatItIs": "Solaris Management Console ran a Java server process on port 898, and Oracle's own troubleshooting documentation shows the status output \"SMC server version 2.1.0 running on port 898\" and the matching \"Shutting down SMC server on port 898\". Administrators used the SMC GUI against it to manage users, filesystems, cron jobs and other host configuration. It is not IANA-registered; 898 is Sun's convention, and Nmap identifies it as the Solaris Management Console Java listener. Finding it open means a Solaris 8 or 9 host, long past support, still exposing its admin plane.",
"exposure": {
"verdict": "never",
"note": "A remote system-administration service on an end-of-life OS; keep it off any routable interface and prefer disabling it entirely."
},
"checkCommand": "nmap -sV -p 898 TARGET",
"links": [
{
"title": "Oracle — Troubleshooting the Solaris Management Console",
"url": "https://docs.oracle.com/cd/E26505_01/html/E29492/smcover-119.html",
"kind": "official-docs"
},
{
"title": "Nmap service frequency database (nmap-services)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 900,
"protocol": "tcp",
"service": "OMG Initial References (CORBA)",
"oneLiner": "Registered to the Object Management Group for CORBA bootstrap references, and almost never actually used.",
"whatItIs": "The IANA registration is omginitialrefs, from CORBA: an ORB could publish its initial object references — NameService, RootPOA and friends — at a fixed well-known port so a client could bootstrap without being handed a corbaloc URL. Real CORBA deployments configure their own ports, so 900 sits empty on essentially every host. Anything you find listening there today picked a round number for itself, usually an internal service or an admin web UI. nmap's frequency data puts 900 far down the list of ports found open, which matches that.",
"exposure": {
"verdict": "careful",
"note": "No standard service runs here, so an open 900 is an unidentified listener — fingerprint it before deciding anything, and treat an unknown service on a public IP as a finding rather than a feature."
},
"checkCommand": "sudo lsof -nP -iTCP:900 -sTCP:LISTEN",
"links": [
{
"title": "IANA port registry — 900",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=900",
"kind": "iana"
},
{
"title": "OMG — CORBA specification",
"url": "https://www.omg.org/spec/CORBA/",
"kind": "official-docs"
},
{
"title": "nmap-services (900/tcp omginitialrefs)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
],
"ianaName": "omginitialrefs"
},
{
"port": 901,
"protocol": "tcp",
"service": "SWAT (Samba Web Administration Tool) — historical",
"oneLiner": "Samba's old SWAT web admin interface; Samba removed it in 4.1.0, so a live 901 today is usually something else.",
"whatItIs": "SWAT was a small CGI web interface for editing smb.conf and starting/stopping Samba, run out of inetd or xinetd on port 901 and protected by HTTP Basic authentication over an unencrypted connection by default. Samba's 4.1.0 release notes list it under removed components, so no current Samba install listens here. IANA's actual registration for 901 is smpnameres, unrelated, and nmap's service table also notes ISS RealSecure using this 901–903 neighbourhood. On a modern scan, 901 is an unidentified service until you look at what it answers.",
"exposure": {
"verdict": "never",
"note": "SWAT accepted the root password over cleartext HTTP and could rewrite smb.conf on submission — if you have found a real one, it is a remote root path, and an unidentified listener here deserves the same suspicion."
},
"checkCommand": "curl -sI --max-time 5 http://TARGET:901/",
"links": [
{
"title": "Samba 4.1.0 release notes — \"The Samba Web Administration Tool (SWAT) has been removed\"",
"url": "https://www.samba.org/samba/history/samba-4.1.0.html",
"kind": "official-docs"
},
{
"title": "Samba 3 HOWTO — SWAT: The Samba Web Administration Tool (port 901)",
"url": "https://www.samba.org/samba/docs/old/Samba3-HOWTO/SWAT.html",
"kind": "official-docs"
},
{
"title": "IANA port registry — 901",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=901",
"kind": "iana"
},
{
"title": "samba-team/samba",
"url": "https://github.com/samba-team/samba",
"kind": "github"
}
],
"ianaName": "smpnameres"
},
{
"port": 902,
"protocol": "tcp",
"service": "VMware host agent / vmware-authd",
"oneLiner": "In practice this is an ESXi host or a VMware Workstation install; IANA's registration (ideafarm-door) has nothing to do with it.",
"whatItIs": "VMware's authentication daemon and host agent listen on TCP 902 for core management traffic between vCenter Server and an ESXi host, for NFC (Network File Copy) used in provisioning, cloning and cold migration, and for the MKS channel that carries a virtual machine's mouse, keyboard and screen to a remote console. ESXi also sends a heartbeat to vCenter on UDP 902. Broadcom's documentation states the MKS port is not configurable, which is why 902 is one of the most reliable ways to identify an ESXi host on a scan. It answers with a plaintext banner naming the VMware Authentication Daemon and its version before requiring SSL.",
"exposure": {
"verdict": "never",
"note": "This is a hypervisor management and console plane — anything that can reach it is one credential away from the screen and keyboard of every VM on the host. It belongs on an isolated management network."
},
"checkCommand": "nc -v -w 3 TARGET 902",
"links": [
{
"title": "Broadcom — Port requirements for VMware vSphere ESXi",
"url": "https://knowledge.broadcom.com/external/article/318895/port-requirements-for-vmware-vsphere-esx.html",
"kind": "official-docs"
},
{
"title": "Broadcom TechDocs — Connecting to the Virtual Machine Console Through a Firewall",
"url": "https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/7-0/vsphere-security/securing-vsphere-networking/securing-the-network-with-firewalls/connecting-to-the-virtual-machine-console-through-a-firewall.html",
"kind": "official-docs"
},
{
"title": "IANA port registry — 902",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=902",
"kind": "iana"
}
],
"ianaName": "ideafarm-door"
},
{
"port": 903,
"protocol": "tcp",
"service": "VMware remote console (legacy) — IANA: ideafarm-panic",
"oneLiner": "The remote-console partner to VMware's 902 on older ESX and GSX/Server hosts; IANA registers it as ideafarm-panic.",
"whatItIs": "Older VMware products — ESX 3.x and 4.x, GSX Server and VMware Server — carried remote console traffic on 903 alongside the authentication daemon on 902. Current vSphere consolidates console and MKS traffic onto 902 and 443, so 903 now shows up mainly on legacy hosts that were never retired. The IANA registration, ideafarm-panic, is an unrelated legacy assignment with no public specification, and nmap's service table additionally labels 903 iss-console-mgr after ISS RealSecure's console manager. Three plausible names, so identify this one by what is next to it on the host.",
"exposure": {
"verdict": "never",
"note": "If it is the VMware console port, it is a virtual-machine console plane on a hypervisor old enough to be out of support — the worst of both problems. Keep it on a management network."
},
"checkCommand": "nc -vz -w 3 TARGET 903",
"links": [
{
"title": "IANA port registry — 903",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=903",
"kind": "iana"
},
{
"title": "nmap-services (903/tcp iss-console-mgr | ideafarm-panic)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
],
"ianaName": "ideafarm-panic"
},
{
"port": 911,
"protocol": "tcp",
"service": "xact-backup",
"oneLiner": "Registered decades ago for a backup product, with no public protocol and essentially no sightings.",
"whatItIs": "IANA lists 911/tcp and 911/udp as xact-backup, assigned to an individual, with no description beyond the name and no specification anywhere. Nothing in common use implements it. nmap's frequency data ranks 911 among the rarest ports to find open at all. If something is listening, a person chose the number — the memorable one, most likely — and the registry will tell you nothing useful about it; the banner will.",
"exposure": {
"verdict": "careful",
"note": "There is no standard service to reason about, so this is an unidentified listener. Find out what it is before leaving it reachable from anywhere."
},
"checkCommand": "sudo lsof -nP -iTCP:911 -sTCP:LISTEN",
"links": [
{
"title": "IANA port registry — 911",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=911",
"kind": "iana"
},
{
"title": "nmap-services (911/tcp xact-backup)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
],
"ianaName": "xact-backup"
},
{
"port": 912,
"protocol": "tcp",
"service": "VMware Authorization Service (Workstation/Player) — IANA: apex-mesh",
"oneLiner": "Registered by RFC 3340 for APEX relay traffic, but what actually listens here is VMware Workstation's authorization service on Windows.",
"whatItIs": "RFC 3340 defines the Application Exchange (APEX) core and registers apex-mesh on 912 for relay-to-relay connections between APEX servers; APEX never saw real deployment, so nothing speaks it. On a Windows desktop, 912 is where vmware-authd — the VMware Authorization Service installed by Workstation and Player — listens to authorize users starting or connecting to virtual machines. Finding 912 open next to 902 on a Windows host is a strong Workstation fingerprint.",
"exposure": {
"verdict": "never",
"note": "It is a virtual-machine authorization and control interface running with high privilege on a desktop; it has no reason to be reachable off the machine, let alone from another network."
},
"checkCommand": "nc -v -w 3 TARGET 912",
"links": [
{
"title": "RFC 3340 — The Application Exchange Core (registers apex-mesh on 912)",
"url": "https://www.rfc-editor.org/rfc/rfc3340.html",
"kind": "spec"
},
{
"title": "IANA port registry — 912",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=912",
"kind": "iana"
},
{
"title": "nmap-services (912/tcp apex-mesh)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
],
"ianaName": "apex-mesh"
},
{
"port": 981,
"protocol": "tcp",
"service": "Unassigned — commonly Check Point embedded HTTPS management",
"oneLiner": "IANA has nothing here; the recurring real-world sighting is a Check Point embedded appliance's HTTPS admin interface.",
"whatItIs": "981 falls inside IANA's unassigned 954–988 block, so there is no registered service name, and nmap's service table lists it as unknown. The use that keeps turning up on scans is remote HTTPS management on Check Point's SofaWare-derived embedded firewalls — the Safe@Office and UTM-1 Edge line — which publish their web administration UI here instead of on 443. Beyond that, 981 is whatever a local admin decided to put on it. A TLS handshake usually settles the question, because the certificate names the device.",
"exposure": {
"verdict": "never",
"note": "If it is the appliance management UI, it is a firewall's administrative interface and must not face the internet. If it is unidentified, treat it as an unknown listener until the certificate says otherwise."
},
"checkCommand": "openssl s_client -connect TARGET:981 /dev/null | openssl x509 -noout -subject -issuer",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry (954–988 unassigned)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "nmap-services (981/tcp unknown)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 987,
"protocol": "tcp",
"service": "Unassigned — commonly Windows SBS \"companyweb\" over HTTPS",
"oneLiner": "Unassigned at IANA; when it is open it is usually a Windows Small Business Server publishing its internal SharePoint site.",
"whatItIs": "IANA leaves 987 unassigned, in the same 954–988 gap as 981, and nmap lists it as unknown. Windows Small Business Server 2008 and 2011 bound the internal SharePoint site — companyweb — to HTTPS on port 987, reusing the certificate from the 443 site, and administrators opened 987 at the perimeter so Remote Web Workplace could link straight to it. SBS is long out of support, so a live 987 is either a surviving SBS box or an unrelated application that took a free port.",
"exposure": {
"verdict": "never",
"note": "An internet-facing SharePoint front end on an out-of-support Windows Small Business Server is an unpatched application on an unpatched operating system, reachable pre-authentication."
},
"checkCommand": "openssl s_client -connect TARGET:987 /dev/null | openssl x509 -noout -subject -issuer",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry (954–988 unassigned)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "nmap-services (987/tcp unknown)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 990,
"protocol": "tcp",
"service": "FTPS (implicit TLS control channel)",
"oneLiner": "Implicit-TLS FTPS: the handshake starts the instant you connect, with no AUTH TLS command first.",
"whatItIs": "A client connecting to 990 negotiates TLS immediately and only then speaks FTP commands, with file data on 989 or on passive high ports. This convention grew up in products rather than in the IETF and was never standardised; RFC 4217 specifies the other approach, explicit FTPS, where a normal session on port 21 issues AUTH TLS to upgrade in place. IANA still carries the ftps registration on 990, and managed-file-transfer servers and appliances keep offering it because older clients only know implicit mode. On a scan it marks a file-transfer server, usually sitting next to 21.",
"exposure": {
"verdict": "careful",
"note": "TLS is mandatory here, so it does not leak credentials the way port 21 does, but it is still an authenticated file-transfer service with awkward data-channel and NAT behaviour. Expose it deliberately with a current TLS configuration, or prefer SFTP over SSH."
},
"checkCommand": "openssl s_client -connect TARGET:990 -quiet",
"links": [
{
"title": "RFC 959 — File Transfer Protocol (FTP)",
"url": "https://www.rfc-editor.org/rfc/rfc959.html",
"kind": "spec"
},
{
"title": "RFC 4217 — Securing FTP with TLS (the explicit alternative)",
"url": "https://www.rfc-editor.org/rfc/rfc4217.html",
"kind": "spec"
},
{
"title": "IANA port registry — 990",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=990",
"kind": "iana"
},
{
"title": "ProFTPD source repository",
"url": "https://github.com/proftpd/proftpd",
"kind": "github"
}
],
"ianaName": "ftps"
},
{
"port": 992,
"protocol": "tcp",
"service": "Telnets (Telnet over TLS)",
"oneLiner": "Telnet wrapped in TLS — registered, sporadically implemented, and still Telnet underneath.",
"whatItIs": "IANA registers 992 as telnets: a Telnet session where TLS is negotiated the moment the connection opens, instead of in-band. No IETF standard defines it — the in-band route, Telnet START_TLS, never got past a draft — so support is vendor-specific and turns up mostly on IBM i systems, terminal servers, and network appliances. It is rare on scans, and much rarer than cleartext Telnet on 23. Encrypted transport or not, what waits at the far end is a login prompt on a device that predates SSH support.",
"exposure": {
"verdict": "careful",
"note": "The session is encrypted, which is the whole point, but this is still interactive administrative access over a legacy protocol with no standard behind this port. Use SSH where the device supports it and keep 992 on a management network otherwise."
},
"checkCommand": "openssl s_client -connect TARGET:992 -quiet",
"links": [
{
"title": "RFC 854 — Telnet Protocol Specification",
"url": "https://www.rfc-editor.org/rfc/rfc854.html",
"kind": "spec"
},
{
"title": "IANA port registry — 992",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=992",
"kind": "iana"
}
],
"ianaName": "telnets"
},
{
"port": 993,
"protocol": "tcp",
"service": "IMAPS (IMAP over implicit TLS)",
"oneLiner": "IMAP mailbox access over TLS, TCP 993.",
"whatItIs": "IMAP servers — Dovecot, Cyrus, Courier, and every hosted mail provider — listen on TCP 993, where the TLS handshake begins immediately on connect. RFC 9051 states an IMAP4rev2 server listens on 143 (cleartext) or 993 (implicit TLS), and RFC 8314 recommends 993 as the preferred access port. Mail clients keep long-lived connections here to sync folders and receive IDLE push notifications. It shows on a scan for any host serving user mailboxes.",
"exposure": {
"verdict": "careful",
"note": "Normal to expose for remote mail clients because TLS is mandatory, but it accepts credentials on every login, so pair it with strong auth and brute-force limits."
},
"checkCommand": "openssl s_client -connect MAIL_HOST:993 -quiet",
"links": [
{
"title": "RFC 9051 — IMAP Version 4rev2",
"url": "https://datatracker.ietf.org/doc/html/rfc9051",
"kind": "spec"
},
{
"title": "RFC 8314 — TLS for Email Submission and Access",
"url": "https://datatracker.ietf.org/doc/html/rfc8314",
"kind": "spec"
},
{
"title": "Dovecot (GitHub)",
"url": "https://github.com/dovecot/core",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 995,
"protocol": "tcp",
"service": "POP3S (POP3 over implicit TLS)",
"oneLiner": "POP3 mail retrieval over TLS, TCP 995.",
"whatItIs": "POP3 servers listen on TCP 995 with TLS negotiated immediately on connect, the encrypted counterpart to cleartext POP3 on 110. RFC 8314 designates it the implicit-TLS access port for POP3. Clients connect, authenticate, download messages, and usually disconnect — POP3 has no server-side folder model, so this is a download-and-delete workflow rather than IMAP's sync. It turns up on scans of mail hosts that still support legacy or low-bandwidth clients.",
"exposure": {
"verdict": "careful",
"note": "Safe to expose in the sense that TLS is required, but it is a credential endpoint on a protocol most deployments no longer need — disable it if nothing uses POP3."
},
"checkCommand": "openssl s_client -connect MAIL_HOST:995 -quiet",
"links": [
{
"title": "RFC 1939 — Post Office Protocol Version 3",
"url": "https://www.rfc-editor.org/rfc/rfc1939.html",
"kind": "spec"
},
{
"title": "RFC 8314 — TLS for Email Submission and Access",
"url": "https://datatracker.ietf.org/doc/html/rfc8314",
"kind": "spec"
},
{
"title": "Dovecot (GitHub)",
"url": "https://github.com/dovecot/core",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 999,
"protocol": "tcp",
"service": "garcon / puprouter (legacy registrations)",
"oneLiner": "Three ancient registrations share this number and none of them is what you actually found.",
"whatItIs": "IANA lists both garcon and puprouter on 999/tcp, plus Applix ac on 999/udp — legacy assignments with no descriptions and no public specifications. Nothing in current use implements any of them. What people actually do with 999 is pick it because it is memorable: alternate HTTP admin interfaces on consumer routers and IP cameras, proxies, and application ports on hosts that wanted something out of the way. Identify it by response, not by name; an HTTP request is the fastest first probe.",
"exposure": {
"verdict": "careful",
"note": "No standard service means no standard security story. If it turns out to be a device's web admin UI — the most common case — that is a management plane and should not be internet-facing."
},
"checkCommand": "curl -sv -o /dev/null --max-time 5 http://TARGET:999/",
"links": [
{
"title": "IANA port registry — 999",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=999",
"kind": "iana"
},
{
"title": "nmap-services (999/tcp garcon | puprouter | applix)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
],
"ianaName": "garcon / puprouter"
},
{
"port": 1000,
"protocol": "tcp",
"service": "cadlock2 (registration) — in practice, a round number",
"oneLiner": "Registered as cadlock2, but open 1000s are almost always something that just wanted a memorable port.",
"whatItIs": "IANA's assignment is cadlock2, an old registration with no description and no published protocol. Whatever is listening on 1000 was placed there on purpose by a local admin or application — proxies, internal application servers and management UIs all like the round number. Note that 1000 is still below 1024, so on a Unix-like host binding it required root, which narrows the field to services started with privilege. nmap's data shows it open more often than its neighbours, and that is squatting rather than cadlock.",
"exposure": {
"verdict": "careful",
"note": "The port name tells you nothing, so judge the service you find. A privileged process listening on a nonstandard port is worth identifying before you allow it through anything."
},
"checkCommand": "curl -sv -o /dev/null --max-time 5 http://TARGET:1000/",
"links": [
{
"title": "IANA port registry — 1000",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=1000",
"kind": "iana"
},
{
"title": "nmap-services (1000/tcp cadlock)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
],
"ianaName": "cadlock2"
},
{
"port": 1001,
"protocol": "tcp",
"service": "webpush (HTTP Web Push registration)",
"oneLiner": "RFC 8030 registered this port for HTTP Web Push, then said the service runs on 443 — so nothing listens here.",
"whatItIs": "RFC 8030, Generic Event Delivery Using HTTP Push, registered the service name webpush on port 1001 in section 9.3, while the same document notes that the push service shares the default 443/TCP with HTTPS. Real push endpoints — the browser vendors' servers behind the Web Push API — are ordinary HTTPS on 443, so the 1001 registration exists on paper only. IANA marks 1001/udp Reserved. An open 1001 is therefore a local application that took a free port, not push.",
"exposure": {
"verdict": "careful",
"note": "Nothing standard is here to reason about, so whatever answers needs identifying on its own merits before it is reachable from outside the host."
},
"checkCommand": "nc -vz -w 3 TARGET 1001",
"links": [
{
"title": "RFC 8030 — Generic Event Delivery Using HTTP Push (§9.3 registers webpush/1001)",
"url": "https://www.rfc-editor.org/rfc/rfc8030.html",
"kind": "spec"
},
{
"title": "IANA port registry — 1001",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=1001",
"kind": "iana"
}
],
"ianaName": "webpush"
},
{
"port": 1002,
"protocol": "tcp",
"service": "Unassigned — nmap labels it windows-icfw",
"oneLiner": "Unassigned at IANA; scanners print \"windows-icfw\" from an old Windows-era name, not from anything running today.",
"whatItIs": "1002 sits in IANA's unassigned 1002–1007 block, so there is no registered service. nmap's service table still carries the historical label windows-icfw, annotated as the Windows Internet Connection Firewall or the Internet Locator Server used by NetMeeting, and that is the name most scan reports repeat. Neither is a live protocol on modern systems. Being under 1024, a listener here was started by a privileged process, so it is deliberate.",
"exposure": {
"verdict": "careful",
"note": "The scanner's label is a historical guess, not evidence. Identify the actual service before you decide anything about exposing it."
},
"checkCommand": "sudo lsof -nP -iTCP:1002 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry (1002–1007 unassigned)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "nmap-services (1002/tcp windows-icfw)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 1007,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned at IANA with no conventional service; whatever is listening picked the number itself.",
"whatItIs": "IANA's registry leaves 1002–1007 unassigned, and nmap lists 1007/tcp as unknown with one of the lowest open-frequency scores in this range. There is no protocol to expect and no scanner label to lean on. What it does tell you: 1007 is inside the system port range defined by RFC 6335, so on a Unix-like host a process needed root to bind it, and something privileged is answering. That is the interesting part, and it is worth chasing down.",
"exposure": {
"verdict": "careful",
"note": "An unnamed, privileged listener is exactly the thing to identify before allowing it through a firewall — the registry gives you no cover here."
},
"checkCommand": "sudo lsof -nP -iTCP:1007 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry (1002–1007 unassigned)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "RFC 6335 — IANA procedures and the System (0–1023) port range",
"url": "https://www.rfc-editor.org/rfc/rfc6335.html",
"kind": "spec"
},
{
"title": "nmap-services (1007/tcp unknown)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 1009,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned at IANA, with no service name and no convention — identify by banner or not at all.",
"whatItIs": "IANA lists 1009 explicitly as Unassigned. Its neighbour is a small piece of registry folklore: 1008/udp carries the comment \"Possibly used by Sun Solaris????\", which is as much certainty as this stretch of the registry offers. nmap has 1009/tcp as unknown and very rarely open. Anything answering is a local choice, and because the port is below 1024 the process that bound it had root.",
"exposure": {
"verdict": "careful",
"note": "No registration and no convention means no assumptions — fingerprint the listener before treating it as benign."
},
"checkCommand": "sudo lsof -nP -iTCP:1009 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry (1009 Unassigned)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "nmap-services (1009/tcp unknown)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 1010,
"protocol": "tcp",
"service": "surf (legacy registration)",
"oneLiner": "Registered as \"surf\" to an individual decades ago, with no published protocol behind the name.",
"whatItIs": "IANA carries 1010/tcp and 1010/udp as surf, assigned to a named individual, with no description beyond the word and no specification anywhere. Nothing in common use implements it, and nmap's frequency data shows 1010 open very rarely. It has nothing to do with suckless.org's surf web browser, which is a desktop client and listens on no port at all. As with its neighbours, a listener here was chosen locally and needs identifying by hand.",
"exposure": {
"verdict": "careful",
"note": "The registration is a name and nothing more, so the port carries no security properties of its own. Judge whatever is actually answering."
},
"checkCommand": "sudo lsof -nP -iTCP:1010 -sTCP:LISTEN",
"links": [
{
"title": "IANA port registry — 1010",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=1010",
"kind": "iana"
},
{
"title": "nmap-services (1010/tcp surf)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
],
"ianaName": "surf"
},
{
"port": 1011,
"protocol": "tcp",
"service": "Reserved (IANA)",
"oneLiner": "Part of IANA's reserved 1011–1020 block — held back deliberately, so no service will ever be registered here.",
"whatItIs": "IANA marks the whole 1011–1020 range Reserved, which is a stronger statement than Unassigned: these numbers are held back and not handed out. No standard service exists or will exist on 1011, and nmap lists it as unknown with a very low open rate. Anything listening is a purely local decision, made by a privileged process since the port is inside the system range.",
"exposure": {
"verdict": "careful",
"note": "A reserved port with a listener on it is by definition something nonstandard running with root privileges. Identify it; there is no registry entry to fall back on."
},
"checkCommand": "sudo lsof -nP -iTCP:1011 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry (1011–1020 Reserved)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "RFC 6335 — IANA procedures for port number assignment",
"url": "https://www.rfc-editor.org/rfc/rfc6335.html",
"kind": "spec"
}
]
},
{
"port": 1021,
"protocol": "tcp",
"service": "exp1 — RFC 3692-style experiment",
"oneLiner": "One of the two port numbers RFC 4727 set aside for experiments, so nothing shipped should ever be here.",
"whatItIs": "RFC 4727 reserves values across several IANA registries for RFC 3692-style experimentation, and 1021 (exp1) with 1022 (exp2) are that pair in the port registry — registered for TCP, UDP, SCTP and DCCP alike. They exist so a lab or an in-progress protocol can be tested without squatting on someone else's assignment, and the RFC is explicit that these values are not for deployed services. In practice 1021 is rarely found open, which suggests the rule is mostly respected.",
"exposure": {
"verdict": "careful",
"note": "Nothing production is supposed to live on an experimental port. If something does, that is a configuration decision to revisit, and it should be identified before it is reachable off the host."
},
"checkCommand": "sudo lsof -nP -iTCP:1021 -sTCP:LISTEN",
"links": [
{
"title": "RFC 4727 — Experimental Values in IPv4, IPv6, ICMP, UDP, TCP headers",
"url": "https://www.rfc-editor.org/rfc/rfc4727.html",
"kind": "spec"
},
{
"title": "IANA port registry — 1021",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=1021",
"kind": "iana"
}
],
"ianaName": "exp1"
},
{
"port": 1022,
"protocol": "tcp",
"service": "exp2 — RFC 3692-style experiment",
"oneLiner": "The second RFC 4727 experiment port, and the one people actually squat on — often with SSH.",
"whatItIs": "1022 is exp2, the partner to 1021 in RFC 4727's pair of ports reserved for RFC 3692-style experimentation across TCP, UDP, SCTP and DCCP. Its registration is identical to 1021's, but nmap's data shows 1022 open several times more often, which reflects services parked on it rather than experiments being run. Moving SSH to a nonstandard low port is a common reason; shared hosting providers in particular have used 1022 and 2222 this way. Confirm by banner: a real SSH server announces itself in cleartext on connect.",
"exposure": {
"verdict": "careful",
"note": "If it is SSH it is still SSH — the odd port buys quieter logs, not security, so key-only authentication still does the actual work. If it is something else, it is a production service on a port reserved for experiments."
},
"checkCommand": "nc -v -w 3 TARGET 1022",
"links": [
{
"title": "RFC 4727 — Experimental Values in IPv4, IPv6, ICMP, UDP, TCP headers",
"url": "https://www.rfc-editor.org/rfc/rfc4727.html",
"kind": "spec"
},
{
"title": "IANA port registry — 1022",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=1022",
"kind": "iana"
},
{
"title": "nmap-services (1022/tcp exp2)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
],
"ianaName": "exp2"
},
{
"port": 1023,
"protocol": "tcp",
"service": "Reserved — top of the system port range",
"oneLiner": "IANA-reserved, and the last port of the privileged 0–1023 range that only root may bind on Unix.",
"whatItIs": "RFC 6335 defines 0–1023 as the System (well-known) ports, which on Unix-like systems only a privileged process may bind, and IANA holds 1023 itself Reserved rather than assigning it. So no standard service lives here. Where 1023 does show up is as a source port: rsh, rlogin and NFS-era clients deliberately chose a reserved source port in 512–1023 as proof the caller was root on a trusted host. A listener on 1023 is a deliberate choice by something running with privilege.",
"exposure": {
"verdict": "careful",
"note": "No assigned service means nothing to allow by default. The privileged-source-port convention it belongs to was host-based trust, which is not a security control on a modern network."
},
"checkCommand": "sudo lsof -nP -iTCP:1023",
"links": [
{
"title": "RFC 6335 — Port ranges: System (0–1023), User, and Dynamic",
"url": "https://www.rfc-editor.org/rfc/rfc6335.html",
"kind": "spec"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry (1023 Reserved)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1024,
"protocol": "tcp",
"service": "Reserved — first port above the privileged range",
"oneLiner": "IANA-reserved, and the boundary: the lowest port an unprivileged process can bind.",
"whatItIs": "RFC 6335 puts 1024–49151 in the User (registered) range, and IANA holds 1024 itself Reserved, so nothing standard is assigned to it. Its real significance is structural — it is the first port a non-root process may bind on a Unix-like system, and older Windows releases (2000, XP, Server 2003) started their dynamic client-port allocation at the low end of 1025–5000, with Vista and Server 2008 moving to 49152–65535. nmap labels 1024 kdm, after KDE's display manager, which is a historical guess rather than a live protocol.",
"exposure": {
"verdict": "careful",
"note": "Anything listening here is unprivileged and locally chosen. That is not automatically dangerous, but it is unidentified until you look, and firewall rules written around the 1024 boundary are about privilege, not trust."
},
"checkCommand": "sudo lsof -nP -iTCP:1024 -sTCP:LISTEN",
"links": [
{
"title": "RFC 6335 — Port ranges: System (0–1023), User, and Dynamic",
"url": "https://www.rfc-editor.org/rfc/rfc6335.html",
"kind": "spec"
},
{
"title": "Microsoft — Service overview and network port requirements (default dynamic port ranges)",
"url": "https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/service-overview-and-network-port-requirements",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry (1024 Reserved)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1025,
"protocol": "tcp",
"service": "Windows dynamic RPC endpoint — IANA: blackjack",
"oneLiner": "Registered as \"network blackjack\", but the reason it is so often open is Windows: the first dynamic RPC port on older releases.",
"whatItIs": "IANA's assignment is blackjack, a joke-grade legacy registration with no specification behind it. The reason 1025 is by far the most frequently open port in this neighbourhood in nmap's data is Microsoft: on Windows 2000, XP and Server 2003 the default dynamic port range ran 1025–5000, so the first service to ask the RPC endpoint mapper for a port landed on 1025 — which is why scanners label it \"NFS-or-IIS\". Windows Vista and Server 2008 moved the range to 49152–65535, so on a current host a listening 1025 is more likely an application that chose it.",
"exposure": {
"verdict": "never",
"note": "As a Windows RPC endpoint this is a broadly-capable interface with a long history of remotely-exploitable bugs, and it is under constant untargeted scanning. RPC does not belong on the internet; reach it over a VPN."
},
"checkCommand": "nc -vz -w 3 TARGET 1025",
"links": [
{
"title": "Microsoft — Service overview and network port requirements (dynamic range 1025–5000 on pre-Vista Windows)",
"url": "https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/service-overview-and-network-port-requirements",
"kind": "official-docs"
},
{
"title": "IANA port registry — 1025",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=1025",
"kind": "iana"
},
{
"title": "nmap-services (1025/tcp NFS-or-IIS | blackjack)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
],
"ianaName": "blackjack"
},
{
"port": 1026,
"protocol": "both",
"service": "CAP (Calendar Access Protocol) / Windows dynamic RPC",
"oneLiner": "Registered to the experimental Calendar Access Protocol, but in practice it is almost always a dynamically assigned Windows RPC endpoint.",
"whatItIs": "IANA assigns 1026 to `cap`, the Calendar Access Protocol, an experimental protocol (RFC 4324, 2005) that carried iCalendar operations over BEEP; the RFC names 1026 as the default port a Calendar Store listens on. CAP was never widely implemented and you will effectively never meet one. What you do meet on 1026 is a Windows box: Windows 2000, XP and Server 2003 allocated dynamic RPC and DCOM endpoints out of a low range starting at 1025, so 1026 is one of the first ports handed to whatever RPC service starts early, and nmap fingerprints it as `msrpc`. Vista and Server 2008 moved that range to 49152-65535, so a modern host answering here is running something else entirely.",
"exposure": {
"verdict": "never",
"note": "The realistic listener is a Windows DCE/RPC endpoint, which has no business on a public IP; and since the binding is dynamic you cannot know what service is behind it without asking the endpoint mapper on 135."
},
"checkCommand": "nmap -Pn -sV -p 1026 TARGET",
"links": [
{
"title": "RFC 4324 — Calendar Access Protocol (CAP)",
"url": "https://www.rfc-editor.org/rfc/rfc4324.html",
"kind": "spec"
},
{
"title": "Microsoft — Service overview and network port requirements (dynamic port ranges)",
"url": "https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/service-overview-and-network-port-requirements",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1027,
"protocol": "both",
"service": "Reserved (TCP) / 6a44 (UDP)",
"oneLiner": "Reserved by IANA on TCP; the UDP side belongs to 6a44, an experimental IPv6-behind-NAT44 mechanism.",
"whatItIs": "IANA marks TCP 1027 simply \"Reserved\" — there is no service name and no assignee, so nothing is entitled to it. UDP 1027 is assigned to `6a44` (RFC 6751, Experimental), a scheme for giving hosts native ISP-prefixed IPv6 addresses from behind IPv4-only CPE by tunnelling IPv6 in UDP/IPv4; it saw essentially no deployment. Anything actually listening on TCP 1027 is therefore unregistered, and on pre-Vista Windows it is most often another dynamically allocated RPC endpoint from the old 1025-5000 range.",
"exposure": {
"verdict": "careful",
"note": "There is no standard service here, so you cannot reason about it from the port number — identify the owning process before deciding whether it should be reachable at all."
},
"checkCommand": "sudo lsof -nP -iTCP:1027 -sTCP:LISTEN",
"links": [
{
"title": "RFC 6751 — Native IPv6 behind IPv4-to-IPv4 NAT CPE (6a44)",
"url": "https://www.rfc-editor.org/rfc/rfc6751.html",
"kind": "spec"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1028,
"protocol": "both",
"service": "Deprecated",
"oneLiner": "A deprecated IANA entry — no service name, no assignee, nothing standard runs here.",
"whatItIs": "IANA's registry carries a single entry for 1028 reading \"Deprecated\", dated 2004-02, with no service name and no owner. That means an earlier assignment was withdrawn and the port was not reissued. In practice it shows up on old Windows hosts as one more dynamically assigned RPC endpoint from the pre-Vista 1025-5000 range, and on anything else as a program that simply picked a free low port.",
"exposure": {
"verdict": "careful",
"note": "Nothing is registered here, so the port tells you nothing — treat an open 1028 as an unidentified service and find the process before exposing it."
},
"checkCommand": "sudo lsof -nP -iTCP:1028 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1029,
"protocol": "both",
"service": "solid-mux (Solid Mux Server)",
"oneLiner": "Registered in 2004 as \"Solid Mux Server\"; on a real scan it is usually a Windows RPC endpoint instead.",
"whatItIs": "IANA assigns 1029 to `solid-mux`, described as \"Solid Mux Server\", registered in November 2004 to an individual assignee. The protocol has no public specification and no open implementation, so the registration is effectively the whole record. What you actually see on 1029 is the same story as its neighbours: on Windows 2000/XP/Server 2003 it falls inside the old 1025-5000 dynamic RPC range and gets handed to whichever DCOM or RPC service starts early, which is why scanners commonly label it `msrpc`.",
"exposure": {
"verdict": "careful",
"note": "No public protocol to reason about; if it turns out to be a Windows RPC endpoint, it should not be internet-facing at all."
},
"checkCommand": "nmap -Pn -sV -p 1029 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1030,
"protocol": "both",
"service": "Reserved",
"oneLiner": "An IANA \"Reserved\" slot left over from an assignment removed in 2013 — nothing standard listens here.",
"whatItIs": "The registry entry for 1030 is a bare \"Reserved\" with no service name and no assignee, annotated with the note that the entry was being removed on 2013-05-24. No protocol has owned this port since. It appears on scans of older Windows hosts because it sits in the pre-Vista dynamic RPC range of 1025-5000, and on anything else because some application grabbed a free low port.",
"exposure": {
"verdict": "careful",
"note": "An unregistered port is an unidentified service — resolve what owns it locally before deciding it is safe to reach."
},
"checkCommand": "sudo lsof -nP -iTCP:1030 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1031,
"protocol": "both",
"service": "Reserved",
"oneLiner": "Reserved at IANA with no owner since the 2013 cleanup; any listener here is non-standard.",
"whatItIs": "IANA lists 1031 as \"Reserved\", with no service name, no assignee, and the same 2013-05-24 removal note as 1030 and 1032. There is no protocol to describe. On scans it turns up as another dynamically allocated endpoint on legacy Windows systems, which used 1025-5000 for RPC and DCOM before Vista moved that range to 49152-65535.",
"exposure": {
"verdict": "careful",
"note": "Nothing is registered here; identify the process behind it rather than inferring anything from the port number."
},
"checkCommand": "nc -vz TARGET 1031",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1032,
"protocol": "both",
"service": "Reserved",
"oneLiner": "The third of the 1030-1032 reserved slots — no assignee, no protocol, no expectation.",
"whatItIs": "Like 1030 and 1031, IANA carries 1032 as a nameless \"Reserved\" entry marked for removal on 2013-05-24, so nothing is entitled to it and nothing is documented for it. Practically it is another low ephemeral port: legacy Windows hosts allocate RPC endpoints here out of the old 1025-5000 range, and ordinary applications on any OS may bind it opportunistically.",
"exposure": {
"verdict": "careful",
"note": "Unregistered, so the port carries no security meaning by itself — find the owning process, then judge."
},
"checkCommand": "sudo lsof -nP -iTCP:1032 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1033,
"protocol": "both",
"service": "netinfo-local",
"oneLiner": "Registered as Apple's local NetInfo port — a directory service Apple removed from macOS years ago.",
"whatItIs": "IANA assigns 1033 to `netinfo-local`, \"local netinfo port\", registered in 2002 by an Apple engineer. NetInfo was the directory and configuration database used by NeXTSTEP and early Mac OS X; Apple replaced it with Open Directory and dropped it entirely, so no current macOS ships a NetInfo daemon. Finding 1033 open today therefore is not NetInfo — on older Windows it is another endpoint from the pre-Vista 1025-5000 dynamic RPC range, and elsewhere it is an application that took a free low port.",
"exposure": {
"verdict": "careful",
"note": "The registered service is extinct, so an open 1033 is an unidentified listener; a directory or RPC service found here should stay on a private network."
},
"checkCommand": "sudo lsof -nP -iTCP:1033 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1034,
"protocol": "both",
"service": "activesync",
"oneLiner": "Registered in 2003 for \"ActiveSync Notifications\" — not the Exchange ActiveSync you sync a phone with.",
"whatItIs": "IANA assigns 1034 to `activesync`, \"ActiveSync Notifications\", registered in 2003. It is easy to confuse with Exchange ActiveSync, the mail and calendar sync protocol phones use, but that runs over HTTPS on 443 and never touches this port. There is no public specification for what 1034 carried, and the registration is the only durable record. On scans it behaves like the rest of this band: a dynamically assigned RPC endpoint on legacy Windows, or an unrelated application on a free low port.",
"exposure": {
"verdict": "careful",
"note": "No documented protocol and no way to reason from the number alone — identify the listener before allowing it through a firewall."
},
"checkCommand": "nmap -Pn -sV -p 1034 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1035,
"protocol": "both",
"service": "mxxrlogin (MX-XR RPC)",
"oneLiner": "Registered as \"MX-XR RPC\" to Valassis — a vendor-private RPC service with no public specification.",
"whatItIs": "IANA assigns 1035 to `mxxrlogin`, described as \"MX-XR RPC\", registered in 2003 by Valassis and last modified in 2015. It is a proprietary remote-procedure-call service; no protocol document, client, or server is publicly available, so the registration is essentially all there is to know. As with its neighbours, an open 1035 on a scan is far more likely to be a dynamically assigned Windows RPC endpoint from the old 1025-5000 range than the registered service.",
"exposure": {
"verdict": "careful",
"note": "A login-bearing RPC service with no public specification cannot be audited from outside — keep anything answering here on a private network until you know what it is."
},
"checkCommand": "nmap -Pn -sV -p 1035 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1036,
"protocol": "both",
"service": "nsstp (Nebula Secure Segment Transfer Protocol)",
"oneLiner": "Registered to the Nebula Secure Segment Transfer Protocol; no public spec, effectively never seen.",
"whatItIs": "IANA assigns 1036 to `nsstp`, the \"Nebula Secure Segment Transfer Protocol\", registered to an individual with no registration date recorded and no reference document. There is no published specification and no known open implementation, which makes this one of the emptier entries in the registry. Anything found listening on 1036 in the wild should be assumed to be something else — commonly a low-range dynamic RPC endpoint on pre-Vista Windows.",
"exposure": {
"verdict": "careful",
"note": "Registered but undocumented; there is nothing here to evaluate, so treat an open 1036 as an unknown service."
},
"checkCommand": "sudo lsof -nP -iTCP:1036 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1037,
"protocol": "both",
"service": "ams",
"oneLiner": "Registered in 2004 as \"AMS\" — an acronym with no expansion, no spec, and no implementation on record.",
"whatItIs": "IANA assigns 1037 to `ams`, described only as \"AMS\", registered in February 2004 to an individual assignee with no reference document. The registry does not expand the acronym and there is no published protocol behind it, so the honest description is that the port is claimed and unused. Open ports at 1037 in the field are almost always unrelated: dynamic RPC endpoints on old Windows systems, or an application that bound the first free port above 1024.",
"exposure": {
"verdict": "careful",
"note": "Nothing documented to reason about — resolve the owning process locally before treating an open 1037 as benign."
},
"checkCommand": "sudo lsof -nP -iTCP:1037 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1038,
"protocol": "both",
"service": "MTQP (Message Tracking Query Protocol)",
"oneLiner": "MTQP, the standards-track protocol for asking a mail server what happened to a message — specified, but barely deployed.",
"whatItIs": "MTQP is defined in RFC 3887 (Standards Track, 2004) and uses TCP 1038. It is a line-oriented text protocol in the style of POP3 and NNTP: a client presents an envelope identifier plus a secret from the SMTP submission, and the server returns the message's tracking history as a MIME body. It was designed to pair with the SMTP message-tracking extension, but almost no mail platform shipped it, so a listener on 1038 in the wild is far more likely to be an unrelated application or a legacy Windows RPC endpoint than a real MTQP server.",
"exposure": {
"verdict": "careful",
"note": "MTQP hands out message routing history to anyone holding the envelope ID and secret, and RFC 3887 expects TLS and authentication; a genuine MTQP server should not sit unprotected on a public IP."
},
"checkCommand": "nc -v TARGET 1038",
"links": [
{
"title": "RFC 3887 — Message Tracking Query Protocol",
"url": "https://www.rfc-editor.org/rfc/rfc3887.html",
"kind": "spec"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1039,
"protocol": "both",
"service": "sbl (Streamlined Blackhole)",
"oneLiner": "Registered in 2004 as \"Streamlined Blackhole\"; no specification was ever published.",
"whatItIs": "IANA assigns 1039 to `sbl`, \"Streamlined Blackhole\", registered in November 2004 to an individual with no reference document attached. Despite the name's resemblance to the Spamhaus SBL blocklist, the registry gives no relationship between the two and no protocol description, so nothing further can be stated honestly. In practice an open 1039 is another low-range dynamic port, commonly an RPC endpoint on Windows systems predating Vista.",
"exposure": {
"verdict": "careful",
"note": "Undocumented registration; the port number gives you no information, so identify the process behind any open 1039."
},
"checkCommand": "nc -vz TARGET 1039",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1040,
"protocol": "both",
"service": "netarx (Netarx Netcare)",
"oneLiner": "Registered in 2008 to Netarx for its \"Netcare\" product — a vendor management service with no public spec.",
"whatItIs": "IANA assigns 1040 to `netarx`, described as \"Netarx Netcare\", registered in April 2008. Netarx was a US network services company and Netcare was its managed-monitoring offering; no protocol documentation or implementation is publicly available. As elsewhere in this band, an open 1040 on a scan is far more likely to be a dynamically assigned endpoint on a legacy Windows host than the registered product.",
"exposure": {
"verdict": "careful",
"note": "A vendor monitoring agent, if that is what is really listening, is an administrative surface — keep it on a management network rather than the internet."
},
"checkCommand": "nmap -Pn -sV -p 1040 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1041,
"protocol": "both",
"service": "danf-ak2 (AK2 Product)",
"oneLiner": "Registered in 2004 as the \"AK2 Product\" port; nothing beyond the registration is public.",
"whatItIs": "IANA assigns 1041 to `danf-ak2`, \"AK2 Product\", registered in November 2004 to an individual assignee with no reference document. There is no published protocol, client, or server, so the registration is the complete public record. Anything listening on 1041 today is almost certainly unrelated to it — most often a dynamic RPC endpoint on Windows XP-era systems, whose low dynamic range ran from 1025 to 5000.",
"exposure": {
"verdict": "careful",
"note": "No documented service; an open 1041 is an unidentified listener until you trace it to a process."
},
"checkCommand": "sudo lsof -nP -iTCP:1041 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1042,
"protocol": "both",
"service": "afrog (Subnet Roaming)",
"oneLiner": "Registered in 2004 as \"Subnet Roaming\" under the name afrog; no specification exists publicly.",
"whatItIs": "IANA assigns 1042 to `afrog`, described as \"Subnet Roaming\", registered in November 2004 to an individual with no reference document. Nothing about the protocol's wire format or purpose beyond that phrase is public. On a scan, 1042 is best read as an unassigned low port: legacy Windows allocates RPC endpoints in this range, and ordinary software binds here opportunistically.",
"exposure": {
"verdict": "careful",
"note": "Undocumented registration, so there is nothing to evaluate — find the process before deciding exposure."
},
"checkCommand": "nc -vz TARGET 1042",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1043,
"protocol": "both",
"service": "boinc-client (BOINC Client Control)",
"oneLiner": "Registered for BOINC client control, but the BOINC client actually listens on 31416 — the registration does not match the shipping software.",
"whatItIs": "IANA assigns 1043 to `boinc-client`, \"BOINC Client Control\", registered in 2004 by BOINC's project lead. BOINC is Berkeley's volunteer distributed-computing platform, and its client exposes a GUI RPC interface that managers such as BOINC Manager connect to — but that interface listens on TCP 31416, not 1043, and can be moved with `--gui_rpc_port`. So the registration is stale relative to the software: seeing 1043 open does not indicate BOINC, while seeing 31416 open does. The GUI RPC port binds to localhost by default and is guarded by a password in `gui_rpc_auth.cfg`.",
"exposure": {
"verdict": "never",
"note": "BOINC's control interface can start, stop, and reconfigure work on the host; keep it on loopback (or a VPN) rather than exposing either 1043 or 31416 to the internet."
},
"checkCommand": "nmap -Pn -sV -p 1043,31416 TARGET",
"links": [
{
"title": "BOINC — client configuration (--gui_rpc_port, gui_rpc_auth.cfg)",
"url": "https://github.com/BOINC/boinc/wiki/Client-configuration",
"kind": "official-docs"
},
{
"title": "BOINC source repository",
"url": "https://github.com/BOINC/boinc",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1044,
"protocol": "both",
"service": "dcutility (Dev Consortium Utility)",
"oneLiner": "Registered in 2004 as \"Dev Consortium Utility\"; the registration is the entire public record.",
"whatItIs": "IANA assigns 1044 to `dcutility`, described as \"Dev Consortium Utility\", registered in November 2004 to an individual assignee with no reference document. No protocol specification or implementation is publicly available. In the field, 1044 behaves like the rest of the 1025-5000 band on older Windows systems — a dynamically allocated RPC endpoint — or simply a free port some application claimed.",
"exposure": {
"verdict": "careful",
"note": "Nothing documented behind the name; treat an open 1044 as unidentified and trace it to a process first."
},
"checkCommand": "sudo lsof -nP -iTCP:1044 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1045,
"protocol": "both",
"service": "fpitp (Fingerprint Image Transfer Protocol)",
"oneLiner": "Registered in 2002 for a Fingerprint Image Transfer Protocol; no specification was ever published.",
"whatItIs": "IANA assigns 1045 to `fpitp`, the \"Fingerprint Image Transfer Protocol\", registered in February 2002 to an individual with no reference document attached. The name suggests biometric image transfer between capture devices and matching systems, but with no published spec that is inference rather than fact. As with the rest of this range, most open 1045 ports belong to something else entirely, typically a dynamic RPC endpoint on a pre-Vista Windows host.",
"exposure": {
"verdict": "never",
"note": "If a service here really is moving biometric images, that is sensitive personal data on an undocumented protocol — it belongs on an isolated network, never on a public IP."
},
"checkCommand": "nmap -Pn -sV -p 1045 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1046,
"protocol": "both",
"service": "wfremotertm (WebFilter Remote Monitor)",
"oneLiner": "Registered in 2004 as \"WebFilter Remote Monitor\" — a vendor remote-monitoring port with no public spec.",
"whatItIs": "IANA assigns 1046 to `wfremotertm`, \"WebFilter Remote Monitor\", registered in November 2004 to an individual assignee. It describes a remote monitoring channel for a web-filtering product; no protocol documentation or implementation is publicly available. Open ports at 1046 on modern scans are usually unrelated, most often dynamically assigned RPC endpoints on legacy Windows systems.",
"exposure": {
"verdict": "never",
"note": "A remote monitoring channel for a filtering appliance is an administrative plane with visibility into user browsing — it belongs on a management network, not the internet."
},
"checkCommand": "nmap -Pn -sV -p 1046 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1047,
"protocol": "both",
"service": "neod1 (Sun NEO Object Request Broker)",
"oneLiner": "The first of two ports registered to Sun's NEO Object Request Broker, a CORBA product long since discontinued.",
"whatItIs": "IANA assigns 1047 to `neod1`, \"Sun's NEO Object Request Broker\", with no registration date and no reference document; 1048 carries the matching `neod2`. NEO was Sun's mid-1990s distributed-object platform built on CORBA, and it has not been a shipping product for decades, so there is no live software to meet here. An open 1047 today is essentially always something else — commonly a low-range dynamic RPC endpoint on an older Windows host.",
"exposure": {
"verdict": "careful",
"note": "The registered ORB is extinct; whatever is listening is unidentified, and an object request broker of any kind is an unauthenticated code-invocation surface you would keep internal."
},
"checkCommand": "nmap -Pn -sV -p 1047,1048 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1048,
"protocol": "both",
"service": "neod2 (Sun NEO Object Request Broker)",
"oneLiner": "The companion port to 1047, registered to the same discontinued Sun NEO ORB.",
"whatItIs": "IANA assigns 1048 to `neod2`, the second \"Sun's NEO Object Request Broker\" entry, registered to an individual with no date and no reference document. Sun's NEO distributed-object product dates from the 1990s and has been gone for many years, so the pair 1047/1048 is a historical registration rather than a live service. As with its neighbours in the 1025-5000 band, anything actually listening on 1048 is more likely a dynamically assigned RPC endpoint or an application that picked a free low port.",
"exposure": {
"verdict": "careful",
"note": "No live protocol behind the registration; identify the owning process before assuming an open 1048 is harmless."
},
"checkCommand": "sudo lsof -nP -iTCP:1048 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1049,
"protocol": "both",
"service": "td-postman (Tobit David)",
"oneLiner": "IANA-registered to Tobit David's Postman messaging component; almost never seen outside German SMB networks.",
"whatItIs": "IANA assigns 1049 to \"td-postman — Tobit David Postman VPMN\", a component of Tobit Software's David groupware suite, a German unified-messaging product that combines email, fax and telephony for small and mid-size businesses. The registration dates from the era when David was widely deployed in German-speaking Europe; outside that market you will effectively never meet the real service. Nmap's frequency data puts 1049 at roughly 0.2% of scanned hosts, and a listener you find there is far more likely to be an unrelated application that grabbed a free port above 1024 than a Tobit server. Identify it by its banner before assuming the registration is what you are talking to.",
"exposure": {
"verdict": "careful",
"note": "A proprietary LAN messaging component with no public security track record — keep it on the internal network, and if you find something listening here, fingerprint it before deciding anything."
},
"checkCommand": "nmap -Pn -sV -p 1049 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "Nmap service frequency database (nmap-services)",
"url": "https://svn.nmap.org/nmap/nmap-services",
"kind": "official-docs"
}
]
},
{
"port": 1050,
"protocol": "tcp",
"service": "CORBA Management Agent / J2EE naming",
"oneLiner": "Registered as CORBA Management Agent; in practice Nmap fingerprints TCP 1050 as a J2EE nameserver.",
"whatItIs": "IANA registers 1050 as \"cma — CORBA Management Agent\", a vendor registration from the CORBA era. Nmap's own service table disagrees about what actually shows up: it labels TCP 1050 `java-or-OTGfileshare`, noting a J2EE nameserver and OTG's Disk/Application Extender as the common occupants, and keeps `cma` only on the UDP side. Either way you are looking at an object-broker or naming service, which is a remote-object endpoint rather than an application protocol. Naming and object-lookup services of this generation typically hand out object references and deserialize what clients send them, which is why they attract attention.",
"exposure": {
"verdict": "never",
"note": "Object brokers and Java naming services generally accept unauthenticated lookups and deserialize client data — a well-worn remote-code-execution path. Bind it to an internal interface only."
},
"checkCommand": "nmap -Pn -sV --script giop-info -p 1050 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "Nmap giop-info NSE script (CORBA/GIOP naming service query)",
"url": "https://nmap.org/nsedoc/scripts/giop-info.html",
"kind": "official-docs"
},
{
"title": "Nmap service frequency database (nmap-services)",
"url": "https://svn.nmap.org/nmap/nmap-services",
"kind": "official-docs"
}
]
},
{
"port": 1051,
"protocol": "both",
"service": "Optima VNET",
"oneLiner": "Registered to \"Optima VNET\" and essentially unseen in the wild — a listener here is almost certainly something else.",
"whatItIs": "The IANA registry assigns 1051 to `optima-vnet`, \"Optima VNET\", a vendor registration with no public protocol specification and no surviving product documentation. Nmap sees it on well under a tenth of a percent of scanned hosts. There is nothing further that is true to say about the registered service. If you find TCP 1051 open, treat the registry name as a coincidence and fingerprint the listener — ports just above 1024 are frequently claimed by application servers, tunnels, and test harnesses that never consulted the registry.",
"exposure": {
"verdict": "careful",
"note": "Unknown service on an unprivileged port: you cannot reason about its exposure until you know what is actually listening. Identify it first."
},
"checkCommand": "nmap -Pn -sV -p 1051 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1052,
"protocol": "both",
"service": "DDT (Dynamic DNS Tools)",
"oneLiner": "Dynamic DNS Tools — a client/server for remote authenticated DNS updates, dormant since 2013.",
"whatItIs": "IANA assigns 1052 to `ddt`, \"Dynamic DNS Tools\", a small C++ client/server project that let clients push authenticated updates into a DNS zone before RFC 2136 dynamic update and `nsupdate` became the standard way to do that. The project shipped as `ddt-client` and `ddt-server` in Debian and was last released in 2013; SourceForge marks it inactive. You will rarely meet a live ddt-server today. A listener on 1052 is more often an unrelated application than this project, so fingerprint before you conclude.",
"exposure": {
"verdict": "never",
"note": "A service whose whole job is writing DNS records, with no upstream maintenance since 2013 — do not put it on a public interface; use RFC 2136 with TSIG instead."
},
"checkCommand": "nmap -Pn -sV -p 1052 TARGET",
"links": [
{
"title": "Dynamic DNS Tools (DDT) project page",
"url": "https://sourceforge.net/projects/ddt/",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1053,
"protocol": "both",
"service": "Remote Assistant (RA)",
"oneLiner": "Registered to a product called Remote Assistant; no public spec, and no relation to Microsoft Remote Assistance.",
"whatItIs": "IANA assigns 1053 to `remote-as`, \"Remote Assistant (RA)\", a vendor registration with no published protocol description. It is not Microsoft's Remote Assistance, which rides RDP on 3389 and does not use this port. There is nothing more that can be established about the registered service beyond the registry entry itself. Because 1053 sits one digit off DNS's 53, it also turns up as an arbitrary local port for DNS forwarders and resolver test setups, which is a naming coincidence rather than a protocol fact.",
"exposure": {
"verdict": "careful",
"note": "A registration name containing \"remote\" is a hint, not evidence. Fingerprint the listener; if it turns out to be a remote-control or admin service, it belongs behind a VPN."
},
"checkCommand": "nmap -Pn -sV -p 1053 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1054,
"protocol": "both",
"service": "BRVREAD",
"oneLiner": "Registered as BRVREAD with no public documentation; the registry entry is the whole story.",
"whatItIs": "IANA lists 1054 as `brvread`, \"BRVREAD\", an early vendor registration for which no protocol specification, product page, or implementation is publicly available. Nmap carries the name in its service table with no description attached. This is a case where the honest answer is short: the port is registered, the registrant's product left no public trace, and anything you find listening on 1054 today should be identified on its own merits rather than by the registry name.",
"exposure": {
"verdict": "careful",
"note": "Unidentified listener on an unprivileged port. Fingerprint it before making an exposure call — the registry name tells you nothing useful here."
},
"checkCommand": "nmap -Pn -sV -p 1054 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1055,
"protocol": "tcp",
"service": "ANSYS License Manager (FlexNet)",
"oneLiner": "ANSYS's FlexNet license server — the lmgrd port that every ANSYS install checks out licenses from.",
"whatItIs": "ANSYS registered 1055 with IANA for FlexNet (and 2325 for its Licensing Interconnect), and its documentation names 1055 as the port `lmgrd` listens on. An ANSYS workstation is pointed at `1055@licenseserver`, contacts lmgrd there, and is then redirected to the `ansyslmd` vendor daemon, whose port is random by default unless an admin pins it with `PORT=` on the VENDOR line. On a scan, 1055 marks an engineering-simulation license server, which usually sits on a well-connected internal host because every CAE seat in the building depends on it. Firewall guidance from ANSYS is to open 1055, 2325, and whatever static vendor-daemon port the license file specifies.",
"exposure": {
"verdict": "never",
"note": "FlexNet license servers have no user authentication and a long CVE history in lmgrd/lmadmin; keep them on the engineering network and reach them over a VPN, never from the internet."
},
"checkCommand": "lmutil lmstat -a -c 1055@TARGET",
"links": [
{
"title": "ANSYS Licensing Guide — Understanding Port Numbers",
"url": "https://ansyshelp.ansys.com/public/Views/Secured/corp/v242/en/ai_elg/aiELG_portnums.html",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1056,
"protocol": "both",
"service": "VFO",
"oneLiner": "Registered as \"VFO\" with no public spec; in practice most often ANSYS's vendor daemon parked next to 1055.",
"whatItIs": "IANA lists 1056 as `vfo`, \"VFO\", a vendor registration with no surviving public documentation. What you actually meet on 1056 is usually unrelated to that name: ANSYS administrators conventionally pin the `ansyslmd` vendor daemon to 1056 with `PORT=1056` on the VENDOR line so it sits beside the lmgrd port on 1055, and ANSYS firewall guidance routinely names 1055, 1056, and 2325 together. So an open 1056 next to an open 1055 is a FlexNet license server, not a VFO service.",
"exposure": {
"verdict": "never",
"note": "When it is the ANSYS vendor daemon, it inherits FlexNet's no-authentication model — internal network only. When it is something unidentified, fingerprint it before exposing anything."
},
"checkCommand": "nmap -Pn -sV -p 1055-1056 TARGET",
"links": [
{
"title": "ANSYS Licensing Guide — Understanding Port Numbers",
"url": "https://ansyshelp.ansys.com/public/Views/Secured/corp/v242/en/ai_elg/aiELG_portnums.html",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1057,
"protocol": "both",
"service": "STARTRON",
"oneLiner": "Registered as STARTRON; no public protocol documentation, and among the rarest ports in this block.",
"whatItIs": "IANA assigns 1057 to `startron`, \"STARTRON\", a vendor registration with no published specification or surviving product documentation. Nmap's frequency data puts it near the bottom of this range, around 0.04% of scanned hosts. There is genuinely nothing further to report about the registered service. Anything listening on 1057 in a modern network should be identified from its banner and the owning process, not from this name.",
"exposure": {
"verdict": "careful",
"note": "Unknown service; the exposure decision belongs to whatever is actually bound there, so fingerprint it first."
},
"checkCommand": "nmap -Pn -sV -p 1057 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1058,
"protocol": "both",
"service": "AIX NIM (nim)",
"oneLiner": "The service port of IBM AIX's Network Installation Management master — where the nimesis daemon takes client requests.",
"whatItIs": "IANA registers 1058 as `nim`, and on IBM AIX this is the well-known service port of Network Installation Management, the framework that installs and maintains AIX systems over the network. The `nimesis` daemon runs on the NIM master, listens on 1058, accepts a client connection, verifies the originator and acknowledges it; NIM clients report installation status back to the master here. IBM's firewall guidance for NIM lists 1058-1059 alongside bootp (67-68), tftp (69), NFS (2049), portmapper (111) and the rsh family. Seeing it open means you have found an AIX NIM master, which by design can push an operating system onto other machines.",
"exposure": {
"verdict": "never",
"note": "A NIM master is an OS-provisioning control plane whose classic trust model is rsh-based host trust; it belongs on a management network, never on a public interface."
},
"checkCommand": "nc -vz TARGET 1058",
"links": [
{
"title": "IBM Support — Network ports used for NIM communication",
"url": "https://www.ibm.com/support/pages/network-ports-used-nim-communication",
"kind": "official-docs"
},
{
"title": "IBM AIX 7.3 docs — Network Installation Management",
"url": "https://www.ibm.com/docs/en/aix/7.3.0?topic=nim-using-network-installation-management",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1059,
"protocol": "both",
"service": "AIX NIM registration (nimreg)",
"oneLiner": "The companion registration port for AIX NIM — how a client adds itself to an existing NIM environment.",
"whatItIs": "IANA registers 1059 as `nimreg`, the registration half of IBM AIX's Network Installation Management pair. Where 1058 carries ongoing master/client service traffic, 1059 is used when a client registers itself into an existing NIM environment: the client obtains a socket via `rcmd()` and connects to the master on this port. It travels with 1058 in every NIM firewall list IBM publishes, so in practice the two are open or closed together. Finding 1059 alone is unusual and worth explaining before you accept it.",
"exposure": {
"verdict": "never",
"note": "Self-registration into an OS-provisioning system, over rcmd-based trust — management network only."
},
"checkCommand": "nc -vz TARGET 1059",
"links": [
{
"title": "IBM Support — Network ports used for NIM communication",
"url": "https://www.ibm.com/support/pages/network-ports-used-nim-communication",
"kind": "official-docs"
},
{
"title": "IBM AIX 7.3 docs — Network Installation Management",
"url": "https://www.ibm.com/docs/en/aix/7.3.0?topic=nim-using-network-installation-management",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1060,
"protocol": "both",
"service": "POLESTAR",
"oneLiner": "Registered as POLESTAR; a vendor name with no public protocol behind it.",
"whatItIs": "IANA assigns 1060 to `polestar`, \"POLESTAR\", a vendor registration from the 1990s with no published specification. No implementation or product documentation for it is publicly available today, and Nmap records the name with no description. That is the complete truthful account of the registration. Treat an open 1060 as an unidentified application port and fingerprint the process that owns it.",
"exposure": {
"verdict": "careful",
"note": "Unknown service; identify what is bound there before deciding whether it may face a network you do not control."
},
"checkCommand": "nmap -Pn -sV -p 1060 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1061,
"protocol": "both",
"service": "KIOSK",
"oneLiner": "Registered as KIOSK with no public specification; rare on scans.",
"whatItIs": "IANA lists 1061 as `kiosk`, \"KIOSK\", a vendor registration with no surviving public documentation of the protocol or the product. nmap-services records it open on 0.038% of scanned hosts, near the floor for this range. Nothing more can be honestly established about the registered service. The generic name occasionally attracts unrelated kiosk-style or point-of-sale applications that pick the port because it matches their domain, which is convention rather than registration.",
"exposure": {
"verdict": "careful",
"note": "Unknown service. If it does turn out to be a kiosk or POS application, those rarely authenticate their management interfaces — keep it off any untrusted network."
},
"checkCommand": "nmap -Pn -sV -p 1061 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "nmap-services — Nmap's port frequency database",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 1062,
"protocol": "both",
"service": "Veracity",
"oneLiner": "Registered to Veracity, a data-integrity product; the protocol was never publicly specified.",
"whatItIs": "IANA assigns 1062 to `veracity`, registered by Ross Williams, whose Rocksoft product line of the period built around content-defined chunking and data-integrity verification. The registration name is all the public record retains — there is no published wire protocol and no current implementation documentation. Nmap carries the name with no description and sees it on well under 0.1% of hosts. A listener on 1062 today should be identified from its own banner rather than from this registration.",
"exposure": {
"verdict": "careful",
"note": "Unknown service on an unprivileged port; fingerprint before deciding. Nothing in the registration justifies public exposure."
},
"checkCommand": "nmap -Pn -sV -p 1062 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1063,
"protocol": "both",
"service": "KyoceraNetDev",
"oneLiner": "Registered by Kyocera for its network-device management traffic — a printer-fleet port, not a print port.",
"whatItIs": "IANA lists 1063 as `kyoceranetdev`, \"KyoceraNetDev\", registered by Kyocera for its network device software. It is a management/discovery channel used by Kyocera's device-administration tooling rather than a printing port — actual jobs go to 9100 (raw), 515 (LPD) or 631 (IPP). Kyocera does not publish the protocol, so what you can say from a scan is limited: 1063 open on a host alongside 9100 and 161 is a strong signal you are looking at a Kyocera MFP or its management server. Kyocera's own discovery documentation describes SNMP, Bonjour and WS-Discovery as the supported discovery mechanisms, which is where the documented behavior lives.",
"exposure": {
"verdict": "never",
"note": "Printer management planes ship with default credentials, expose address books and scan-to-folder settings, and are a standard internal foothold — keep MFPs off the public internet entirely."
},
"checkCommand": "nmap -Pn -sV -p 1063,9100,161 TARGET",
"links": [
{
"title": "Kyocera — Discovery and network",
"url": "https://www.kyoceradocumentsolutions.com/support/mobileprint/data/en/discoveryNetwork.html",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1064,
"protocol": "both",
"service": "JSTEL",
"oneLiner": "Registered as JSTEL; no public protocol documentation survives.",
"whatItIs": "IANA assigns 1064 to `jstel`, \"JSTEL\", a vendor registration with no published specification and no current product documentation. Nmap carries the service name with no description attached. That is the entire verifiable record. Because 1064 sits in the band applications commonly grab for themselves just above 1024, a listener you find here is more likely to be an unregistered local service than JSTEL.",
"exposure": {
"verdict": "careful",
"note": "Unidentified listener; the registry name gives you no basis for an exposure decision. Fingerprint it."
},
"checkCommand": "nmap -Pn -sV -p 1064 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1065,
"protocol": "both",
"service": "SYSCOMLAN",
"oneLiner": "Registered as SYSCOMLAN; a name in the registry with nothing public behind it.",
"whatItIs": "IANA lists 1065 as `syscomlan`, \"SYSCOMLAN\", a vendor registration with no published protocol description and no publicly documented implementation. Nmap records the name without a comment. Nothing further about the registered service can be established honestly. Anything listening on 1065 should be traced to its process locally (`lsof -i :1065` or `ss -ltnp`) rather than assumed from the registry.",
"exposure": {
"verdict": "careful",
"note": "Unknown service; make the exposure call from what is actually bound to the port, not from the registration."
},
"checkCommand": "nmap -Pn -sV -p 1065 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1066,
"protocol": "both",
"service": "FPO-FNS",
"oneLiner": "Registered as FPO-FNS; no public specification, and no reliable modern sighting.",
"whatItIs": "IANA assigns 1066 to `fpo-fns`, \"FPO-FNS\", a vendor registration with no published protocol documentation. Nmap sees it on about 0.19% of scanned hosts, which is typical background for this block and does not imply the registered service is what answered. Older port lists sometimes attach trojan names to ports in the 1000-1100 range; those attributions are undocumented folklore and are not repeated here. Identify the listener directly instead.",
"exposure": {
"verdict": "careful",
"note": "Unknown service. Fingerprint the listener; nothing about this registration argues for exposing it."
},
"checkCommand": "nmap -Pn -sV -p 1066 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1067,
"protocol": "both",
"service": "Installation Bootstrap Protocol Server (instl_boots)",
"oneLiner": "A BOOTP server on a private port pair — HP's Ignite-UX uses it to net-boot HP-UX installs without colliding with DHCP.",
"whatItIs": "IANA registers 1067 as `instl-boots` (formerly `instl_boots`), the Installation Bootstrap Protocol server port. Its best-documented user is HP's Ignite-UX, whose `instl_bootd` daemon speaks BOOTP on 1067/1068 instead of the standard 67/68 precisely so that installing an HP-UX client does not draw answers from the site's regular DHCP servers — only instl_bootd listens on those ports, so only instl_bootd replies. Ignite-UX server setup asks that 1067, 1068, tftp/69 and bootps/67-68 all be free and reachable. Real traffic here is UDP; the TCP registration exists but is not what you see on the wire.",
"exposure": {
"verdict": "never",
"note": "An unauthenticated bootstrap service that hands a machine its operating system image — provisioning VLAN only, never routed to anything untrusted."
},
"checkCommand": "sudo tcpdump -ni any udp port 1067 or udp port 1068",
"links": [
{
"title": "HP Ignite-UX Administration Guide (HP-UX 10.x, 11.0, 11i)",
"url": "https://www.bitsavers.org/pdf/hp/9000_hpux/1991-200x/200303_B2355-90772_Ignite-UX_Administration_Guide_HP_Computers_with_HP-UX_10.x_11.0_or_11i_Ed10.pdf",
"kind": "official-docs"
},
{
"title": "RFC 951 — Bootstrap Protocol (BOOTP)",
"url": "https://www.rfc-editor.org/rfc/rfc951.html",
"kind": "spec"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1068,
"protocol": "both",
"service": "Installation Bootstrap Protocol Client (instl_bootc)",
"oneLiner": "The client half of the private BOOTP pair — where the machine being installed receives its boot reply.",
"whatItIs": "IANA registers 1068 as `instl-bootc` (formerly `instl_bootc`), the client-side counterpart to 1067. In HP's Ignite-UX the booting client sends from and receives on 1068 while the server's `instl_bootd` answers from 1067, mirroring the standard BOOTP 67/68 relationship on a private port pair so installation traffic stays isolated from the site's DHCP. As with 1067, live traffic is UDP; the TCP registration is bookkeeping. On a host scan, seeing 1068 bound is normally a machine mid-provision or an Ignite-UX client daemon left running.",
"exposure": {
"verdict": "never",
"note": "Part of an unauthenticated OS-provisioning exchange — keep the whole 1067/1068 pair inside the provisioning network."
},
"checkCommand": "sudo tcpdump -ni any udp port 1068",
"links": [
{
"title": "HP Ignite-UX Administration Guide (HP-UX 10.x, 11.0, 11i)",
"url": "https://www.bitsavers.org/pdf/hp/9000_hpux/1991-200x/200303_B2355-90772_Ignite-UX_Administration_Guide_HP_Computers_with_HP-UX_10.x_11.0_or_11i_Ed10.pdf",
"kind": "official-docs"
},
{
"title": "RFC 951 — Bootstrap Protocol (BOOTP)",
"url": "https://www.rfc-editor.org/rfc/rfc951.html",
"kind": "spec"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1069,
"protocol": "tcp",
"service": "Cognex In-Sight",
"oneLiner": "Reserved by Cognex for In-Sight machine-vision system communications — a factory-floor port.",
"whatItIs": "IANA registers 1069 as `cognex-insight`, \"COGNEX-INSIGHT\", assigned to Cognex for its In-Sight smart cameras and vision systems. Cognex's In-Sight documentation states that 1069 is reserved for In-Sight communications and therefore cannot be chosen as a custom Telnet port; the Native Mode ASCII control protocol that operators use to drive a camera over Ethernet defaults to Telnet on port 23. So 1069 is an internal reservation of the In-Sight software rather than a protocol you interact with by hand. Finding it open places the host on an industrial network running Cognex vision hardware.",
"exposure": {
"verdict": "never",
"note": "Industrial vision systems sit on OT networks with weak or absent authentication and control physical processes — segment them, and never route this to the internet."
},
"checkCommand": "nmap -Pn -sV -p 1069,23 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "Nmap service frequency database (nmap-services)",
"url": "https://svn.nmap.org/nmap/nmap-services",
"kind": "official-docs"
}
]
},
{
"port": 1070,
"protocol": "both",
"service": "GMRUpdateSERV",
"oneLiner": "Registered as GMRUpdateSERV, an update service with no public documentation.",
"whatItIs": "IANA assigns 1070 to `gmrupdateserv`, \"GMRUpdateSERV\", a vendor registration whose name suggests a software-update server but for which no specification or product documentation is publicly available. Nmap sees it on about 0.04% of scanned hosts. There is nothing further that is true to say about the registered service. If 1070 is open on a machine you own, find the owning process locally rather than trusting the name.",
"exposure": {
"verdict": "careful",
"note": "Unknown service. If it really is an update distribution point, an unauthenticated one is a software-supply-chain risk — identify it before exposing it anywhere."
},
"checkCommand": "nmap -Pn -sV -p 1070 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1071,
"protocol": "both",
"service": "BSQUARE-VOIP",
"oneLiner": "Registered by BSQUARE for a VoIP product; no public protocol details and effectively no modern sightings.",
"whatItIs": "IANA lists 1071 as `bsquare-voip`, \"BSQUARE-VOIP\", registered by BSQUARE Corporation, a company known for Windows CE and embedded-device software. The VoIP product behind the registration was never publicly specified, and no current documentation for it exists. Nmap carries the name with no description. Modern VoIP you actually meet uses SIP on 5060/5061 and RTP in the high ephemeral range, not this port, so a listener on 1071 today is almost certainly something unrelated.",
"exposure": {
"verdict": "careful",
"note": "Unknown service. Fingerprint it; if it is genuinely a signalling or media service, unencrypted VoIP control belongs on a trusted network only."
},
"checkCommand": "nmap -Pn -sV -p 1071 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1072,
"protocol": "tcp",
"service": "CARDAX (Gallagher access control)",
"oneLiner": "Registered to CARDAX, the building access-control system now sold as Gallagher Command Centre.",
"whatItIs": "IANA assigned 1072 to \"CARDAX\" for Charles Oram of Cardax, the New Zealand access-control vendor that became Gallagher Security. In current Gallagher deployments the port carries FTCAPI, the Command Centre API that third-party systems such as video management platforms connect to, so integration guides tell installers to open TCP 1072 on the middleware host. Outside a site running Gallagher or legacy Cardax FT hardware you will effectively never see it.",
"exposure": {
"verdict": "never",
"note": "This is the API into a physical access-control system — doors, cards, alarms. Keep it on the security management VLAN, reachable only from the integration server that needs it."
},
"checkCommand": "nc -vz -w 3 TARGET 1072",
"links": [
{
"title": "IANA port registry — 1072 (cardax)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=1072",
"kind": "iana"
},
{
"title": "Milestone — Gallagher Command Centre VMS integration release note (FTCAPI listens on 1072)",
"url": "https://www.milestonesys.com/globalassets/marketplace/uploaded-assets/0012000000c2pxraaz/milestone-vms-integration---release-note.2.pdf",
"kind": "official-docs"
},
{
"title": "Gallagher Security (successor to Cardax)",
"url": "https://security.gallagher.com/",
"kind": "official-docs"
}
]
},
{
"port": 1073,
"protocol": "tcp",
"service": "Bridge Control",
"oneLiner": "A 1990s IANA registration called \"Bridge Control\" with no public specification.",
"whatItIs": "IANA lists 1073/tcp and 1073/udp as bridgecontrol, \"Bridge Control\", registered to Andy Heron. No protocol document, product page, or open implementation is publicly available, so there is nothing to fingerprint against. A listener you find here is far more likely to be an unrelated application that grabbed a low free port, or a Windows client socket from the old 1025-5000 dynamic range, than the registered protocol.",
"exposure": {
"verdict": "careful",
"note": "Identify what is actually listening before deciding — the registration tells you nothing about the service's authentication or encryption."
},
"checkCommand": "nmap -sV -Pn -p 1073 TARGET",
"links": [
{
"title": "IANA port registry — 1073 (bridgecontrol)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=1073",
"kind": "iana"
}
]
},
{
"port": 1074,
"protocol": "tcp",
"service": "Warmspot Management Protocol",
"oneLiner": "Registered as the Warmspot Management Protocol; no public spec and no known deployments.",
"whatItIs": "IANA records 1074 as warmspotMgmt, \"Warmspot Management Protocol\", registered by Robert C. Henningsgard. Nothing about the protocol has been published — no RFC, no vendor documentation, no open-source implementation. Treat any listener on this port as unidentified until you fingerprint it directly.",
"exposure": {
"verdict": "careful",
"note": "An unknown service on an unknown protocol should not be reachable from anywhere it has not been deliberately allowed."
},
"checkCommand": "nmap -sV -Pn -p 1074 TARGET",
"links": [
{
"title": "IANA port registry — 1074 (warmspotMgmt)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=1074",
"kind": "iana"
}
]
},
{
"port": 1075,
"protocol": "tcp",
"service": "RDRMSHC",
"oneLiner": "An IANA registration whose name, RDRMSHC, has never been publicly expanded.",
"whatItIs": "1075/tcp and 1075/udp are registered to Ericko Shimada under the service name rdrmshc, with the registry giving \"RDRMSHC\" as the description and nothing more. There is no published specification, vendor page, or implementation to match against. In practice the port shows up mostly as a client-side ephemeral socket on older Windows hosts, not as a server.",
"exposure": {
"verdict": "careful",
"note": "Nothing is documented about this protocol's security properties, so a listener here needs to be identified before it is exposed anywhere."
},
"checkCommand": "nmap -sV -Pn -p 1075 TARGET",
"links": [
{
"title": "IANA port registry — 1075 (rdrmshc)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=1075",
"kind": "iana"
}
]
},
{
"port": 1076,
"protocol": "tcp",
"service": "DAB STI-C",
"oneLiner": "The control half of the DAB digital-radio Service Transport Interface, registered by WorldDAB.",
"whatItIs": "The Service Transport Interface (ETSI EN 300 797) carries audio, data, and service information from a service provider to a DAB ensemble provider. It splits into STI-D, the unidirectional data part that carries what gets broadcast, and STI-C, the bidirectional control and monitoring part that is not broadcast; 1076 is registered to WorldDAB for STI-C. You will only see it inside a broadcast contribution network, between playout and multiplexer equipment.",
"exposure": {
"verdict": "never",
"note": "STI-C controls what a DAB multiplex transmits. It belongs on a dedicated contribution link or broadcast VLAN, never on a public interface."
},
"checkCommand": "nc -vz -w 3 TARGET 1076",
"links": [
{
"title": "IANA port registry — 1076 (dab-sti-c, assigned to WorldDAB)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=1076",
"kind": "iana"
},
{
"title": "WorldDAB — the body that holds the DAB STI registrations",
"url": "https://www.worlddab.org/",
"kind": "official-docs"
}
]
},
{
"port": 1077,
"protocol": "tcp",
"service": "IMGames",
"oneLiner": "Registered as IMGames in the 1990s; no surviving public documentation.",
"whatItIs": "IANA lists 1077/tcp and 1077/udp as imgames, \"IMGames\", registered to Jean A. Ames. No protocol description or implementation has been published, and there is no evidence of current deployment. Anything listening here today is almost certainly unrelated to the registration.",
"exposure": {
"verdict": "careful",
"note": "Fingerprint the actual service before making any exposure decision; the registered name tells you nothing useful."
},
"checkCommand": "nmap -sV -Pn -p 1077 TARGET",
"links": [
{
"title": "IANA port registry — 1077 (imgames)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=1077",
"kind": "iana"
}
]
},
{
"port": 1078,
"protocol": "tcp",
"service": "Avocent Proxy Protocol",
"oneLiner": "An Avocent/Vertiv KVM proxy — remote console sessions to serial, KVM, and service-processor targets tunnel through here.",
"whatItIs": "Avocent (now Vertiv) registered 1078 for its proxy protocol, and DSView management software uses it to tunnel KVM video, serial, and service-processor sessions between clients and appliances so that clients never need a direct route to the managed hardware. Finding it open means a DSView server or an Avocent appliance is on the network, sitting in front of the out-of-band consoles of everything it manages. The port is configurable but is left at 1078 in most installs.",
"exposure": {
"verdict": "never",
"note": "This is the front door to out-of-band console access for a whole rack estate. Keep it on the management network and reach it over a VPN, not from the internet."
},
"checkCommand": "nc -vz -w 3 TARGET 1078",
"links": [
{
"title": "IANA port registry — 1078 (avocent-proxy)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=1078",
"kind": "iana"
},
{
"title": "Vertiv — Avocent DSView 4.5 TCP/UDP ports technical note",
"url": "https://www.vertiv.com/globalassets/products/monitoring-control-and-management/software/avocent-dsview-management-software/vertiv-avocent-dsview-4.5-tcp_udp-ports-tech-note.pdf",
"kind": "official-docs"
}
]
},
{
"port": 1079,
"protocol": "tcp",
"service": "ASPROVATalk",
"oneLiner": "Registered as ASPROVATalk; the protocol was never publicly documented.",
"whatItIs": "IANA assigned 1079/tcp and 1079/udp to Chiew Farn Chung under the name asprovatalk, \"ASPROVATalk\". There is no published specification and no open implementation, so the registration is the entire record. As with most of this stretch of the user-port range, a listener here is more likely to be some other application on a convenient low port.",
"exposure": {
"verdict": "careful",
"note": "Undocumented protocol — identify the process behind the socket before exposing it beyond the host."
},
"checkCommand": "nmap -sV -Pn -p 1079 TARGET",
"links": [
{
"title": "IANA port registry — 1079 (asprovatalk)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=1079",
"kind": "iana"
}
]
},
{
"port": 1080,
"protocol": "tcp",
"service": "SOCKS proxy",
"oneLiner": "A SOCKS proxy — a generic TCP/UDP relay that will forward traffic anywhere on behalf of whoever can reach it.",
"whatItIs": "SOCKS is a circuit-level proxy: a client connects, negotiates an authentication method, then asks the proxy to open a connection to some other host and port, after which bytes pass through untouched. SOCKS5 is RFC 1928, with username/password authentication in RFC 1929 and GSSAPI in RFC 1961; \"no authentication required\" is a legal method and a common default. You will find it in front of Dante, 3proxy, or microsocks, on a corporate egress gateway, or as the local end of an ssh -D dynamic forward. It is also one of the most scanned ports on the internet, because an open relay is directly useful to an attacker for spam, credential stuffing, and hiding the origin of other traffic.",
"exposure": {
"verdict": "never",
"note": "An internet-facing SOCKS proxy without authentication is an open relay and will be found and abused within hours. If it must be remote, require credentials, restrict source addresses, and prefer an SSH dynamic forward or a VPN over an exposed listener."
},
"checkCommand": "curl -sS -m 8 --socks5-hostname TARGET:1080 https://example.com/ -o /dev/null -w '%{http_code}\\n'",
"links": [
{
"title": "RFC 1928 — SOCKS Protocol Version 5",
"url": "https://www.rfc-editor.org/rfc/rfc1928.html",
"kind": "spec"
},
{
"title": "RFC 1929 — Username/Password Authentication for SOCKS V5",
"url": "https://www.rfc-editor.org/rfc/rfc1929.html",
"kind": "spec"
},
{
"title": "IANA port registry — 1080 (socks)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=1080",
"kind": "iana"
},
{
"title": "rofl0r/microsocks — small SOCKS5 server",
"url": "https://github.com/rofl0r/microsocks",
"kind": "github"
}
]
},
{
"port": 1081,
"protocol": "tcp",
"service": "PVUNIWIEN",
"oneLiner": "Registered as PVUNIWIEN; nothing beyond the registration was ever published.",
"whatItIs": "IANA lists 1081/tcp and 1081/udp as pvuniwien, registered to Peter Lipp, with no expansion of the name and no referenced document. No implementation is publicly available. In practice the port matters mostly because it sits one above SOCKS, so scanners and misconfigured proxy clients touch it constantly.",
"exposure": {
"verdict": "careful",
"note": "Undocumented registration — treat any listener as unidentified and check whether it is actually a second SOCKS or HTTP proxy instance."
},
"checkCommand": "nmap -sV -Pn -p 1081 TARGET",
"links": [
{
"title": "IANA port registry — 1081 (pvuniwien)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=1081",
"kind": "iana"
}
]
},
{
"port": 1082,
"protocol": "tcp",
"service": "AMT-ESD-PROT",
"oneLiner": "Registered to AMTEC S.p.A. as AMT-ESD-PROT, with no public protocol description.",
"whatItIs": "IANA assigned 1082/tcp and 1082/udp to the Italian engineering firm AMTEC S.p.A. under the name amt-esd-prot. The registry gives the acronym and nothing else, and AMTEC has not published a specification. There is no way to identify the protocol on the wire from public sources, so treat a listener here as unknown until you trace it to a process.",
"exposure": {
"verdict": "careful",
"note": "No documented authentication or encryption properties, so no exposure decision can be justified without first identifying the service."
},
"checkCommand": "nmap -sV -Pn -p 1082 TARGET",
"links": [
{
"title": "IANA port registry — 1082 (amt-esd-prot)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=1082",
"kind": "iana"
}
]
},
{
"port": 1083,
"protocol": "tcp",
"service": "Ansoft License Manager",
"oneLiner": "Half of the old Ansoft (now ANSYS) FLEXlm licence-server pair for EDA and simulation tools.",
"whatItIs": "IANA registered 1083 and 1084 together as ansoft-lm-1 and ansoft-lm-2, the licence manager for Ansoft's electromagnetic simulation tools such as HFSS. Ansoft was acquired by ANSYS in 2008 and its FLEXlm daemon was folded into the ANSYS licence manager, which now uses 1055 for lmgrd and 1056 for the ansyslmd vendor daemon. A listener on 1083 today means an engineering site is still running the legacy Ansoft licence server, or that something else claimed the port.",
"exposure": {
"verdict": "careful",
"note": "FLEXlm licence daemons are unauthenticated and have a long history of parsing bugs; keep them on the engineering LAN and never publish them."
},
"checkCommand": "nc -vz -w 3 TARGET 1083",
"links": [
{
"title": "IANA port registry — 1083 (ansoft-lm-1)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=1083",
"kind": "iana"
},
{
"title": "ANSYS License Management Guide",
"url": "https://ansyshelp.ansys.com/public/Views/Secured/corp/v251/en/pdf/ansys_license_management_guide.pdf",
"kind": "official-docs"
}
]
},
{
"port": 1084,
"protocol": "tcp",
"service": "Ansoft License Manager / ANSYS License Management Center",
"oneLiner": "The second Ansoft licence port, and today the Tomcat port for the ANSYS License Management Center web UI.",
"whatItIs": "1084 was registered alongside 1083 as the second port of the Ansoft (now ANSYS) licence manager. In current ANSYS installations it has a live second life: the licence-manager installer configures a bundled Tomcat on port 1084 to serve the browser-based License Management Center, which admins open at http://localhost:1084/. It is bound to the licence server itself by default, and installs log an explicit check that 1084 is free before starting Tomcat.",
"exposure": {
"verdict": "never",
"note": "It is a licence-administration web console shipped on an embedded Tomcat. Leave it local to the licence server, or reach it over a VPN — do not publish it to get remote admin access."
},
"checkCommand": "curl -sS -m 5 -o /dev/null -w '%{http_code}\\n' http://TARGET:1084/",
"links": [
{
"title": "IANA port registry — 1084 (ansoft-lm-2)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=1084",
"kind": "iana"
},
{
"title": "ANSYS — Modifying the Tomcat Port Number (default 1084)",
"url": "https://ansyshelp.ansys.com/public/Views/Secured/corp/v251/en/ai_elg/modtomcatport.html",
"kind": "official-docs"
}
]
},
{
"port": 1085,
"protocol": "tcp",
"service": "WebObjects (wotaskd)",
"oneLiner": "Apple WebObjects: wotaskd, the daemon that starts, stops, and advertises application instances.",
"whatItIs": "wotaskd is the WebObjects task daemon; it listens on 1085 and is how the web-server adaptor discovers which application instances exist and how JavaMonitor starts and stops them, including via multicast to 239.128.14.2 on the same port. Apple discontinued WebObjects after 5.4.3 in 2008, but deployments survive and the stack lives on through the WOCommunity's Project Wonder. Seeing 1085 open means a Java WebObjects deployment host, usually alongside JavaMonitor on 56789 and application instances on higher ports.",
"exposure": {
"verdict": "never",
"note": "wotaskd controls application lifecycle on the host. It is a deployment control plane on an unmaintained framework — keep it behind the web tier on a private network."
},
"checkCommand": "curl -sS -m 5 -o /dev/null -w '%{http_code}\\n' http://TARGET:1085/",
"links": [
{
"title": "IANA port registry — 1085 (webobjects)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=1085",
"kind": "iana"
},
{
"title": "Apple — Deploying WebObjects Applications (wotaskd)",
"url": "https://developer.apple.com/library/archive/documentation/LegacyTechnologies/WebObjects/WebObjects_5/DeployingWebObjects/DeployingWOApps.pdf",
"kind": "official-docs"
},
{
"title": "wocommunity/wonder — Project Wonder, the community WebObjects frameworks",
"url": "https://github.com/wocommunity/wonder",
"kind": "github"
}
]
},
{
"port": 1086,
"protocol": "tcp",
"service": "CPL Scrambler Logging",
"oneLiner": "Registered as CPL Scrambler Logging; the product behind the name is not publicly documented.",
"whatItIs": "IANA lists 1086, 1087, and 1088 as a set — cplscrambler-lg (logging), cplscrambler-in (internal), and cplscrambler-al (alarm log) — registered to Richard Corn. No specification, manual, or implementation for \"CPL Scrambler\" is publicly available, so the registry entry is all that can be verified. Traffic you see on 1086 in practice is usually an ephemeral client socket or an unrelated application, not this service.",
"exposure": {
"verdict": "careful",
"note": "Nothing is documented about the protocol, so identify what is really listening before allowing it through a firewall."
},
"checkCommand": "nmap -sV -Pn -p 1086 TARGET",
"links": [
{
"title": "IANA port registry — 1086 (cplscrambler-lg)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=1086",
"kind": "iana"
}
]
},
{
"port": 1087,
"protocol": "tcp",
"service": "CPL Scrambler Internal",
"oneLiner": "The middle port of the undocumented CPL Scrambler trio registered at 1086-1088.",
"whatItIs": "1087/tcp and 1087/udp are registered as cplscrambler-in, \"CPL Scrambler Internal\", part of the same three-port registration as 1086 and 1088. As with its siblings there is no public specification and no known implementation to fingerprint. Any listener here should be traced back to a local process rather than assumed to be the registered service.",
"exposure": {
"verdict": "careful",
"note": "An unidentified service with unknown authentication — do not expose it until you know what it is."
},
"checkCommand": "nmap -sV -Pn -p 1087 TARGET",
"links": [
{
"title": "IANA port registry — 1087 (cplscrambler-in)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=1087",
"kind": "iana"
}
]
},
{
"port": 1088,
"protocol": "tcp",
"service": "CPL Scrambler Alarm Log",
"oneLiner": "The alarm-log port of the CPL Scrambler registration; nothing more is publicly known.",
"whatItIs": "IANA records 1088/tcp and 1088/udp as cplscrambler-al, \"CPL Scrambler Alarm Log\", registered to Richard Corn together with 1086 and 1087. No documentation of the protocol or the product exists in public sources. That is the honest extent of what can be said about this port.",
"exposure": {
"verdict": "careful",
"note": "Undocumented protocol; base any firewall decision on what the host is actually running, not on the registered name."
},
"checkCommand": "nmap -sV -Pn -p 1088 TARGET",
"links": [
{
"title": "IANA port registry — 1088 (cplscrambler-al)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=1088",
"kind": "iana"
}
]
},
{
"port": 1089,
"protocol": "tcp",
"service": "FOUNDATION Fieldbus HSE — Annunciation",
"oneLiner": "Industrial control: the annunciation (event/alarm) port of FOUNDATION Fieldbus High Speed Ethernet.",
"whatItIs": "The Fieldbus Foundation, now the FieldComm Group, registered 1089, 1090, and 1091 for FOUNDATION Fieldbus HSE — the 100 Mbit Ethernet layer that connects linking devices, gateways, and controllers in process plants. 1089 carries annunciation, the event and alarm notifications published by field devices. Scanners and ICS asset-inventory tools use the trio 1089-1091 as the signature that a host is process-control equipment rather than IT equipment.",
"exposure": {
"verdict": "never",
"note": "HSE was designed for a closed plant control network with no attacker on it — there is no meaningful transport security. It belongs on an isolated control network behind a firewall or data diode."
},
"checkCommand": "nmap -sV -Pn -p 1089-1091 TARGET",
"links": [
{
"title": "IANA port registry — 1089 (ff-annunc, assigned to the Fieldbus Foundation)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=1089",
"kind": "iana"
},
{
"title": "ITI/ICS-Security-Tools — ICS protocol port list (FOUNDATION Fieldbus HSE, 1089-1091)",
"url": "https://github.com/ITI/ICS-Security-Tools/blob/master/protocols/PORTS.md",
"kind": "github"
}
]
},
{
"port": 1090,
"protocol": "tcp",
"service": "FOUNDATION Fieldbus HSE — FMS",
"oneLiner": "The Fieldbus Message Specification port — the actual read/write messaging of FOUNDATION Fieldbus HSE.",
"whatItIs": "FMS is the application-layer messaging service of FOUNDATION Fieldbus: it is how a host reads and writes the parameters of function blocks living in field devices. On HSE it is registered to the Fieldbus Foundation on port 1090, alongside annunciation on 1089 and system management on 1091. If 1090 is open, you are looking at process-control gear — a linking device, gateway, or controller — not an office server.",
"exposure": {
"verdict": "never",
"note": "FMS is the write path into live process control. Anything that can reach it can attempt to change device parameters; isolate it on the control network."
},
"checkCommand": "nmap -sV -Pn -p 1090 TARGET",
"links": [
{
"title": "IANA port registry — 1090 (ff-fms)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=1090",
"kind": "iana"
},
{
"title": "ITI/ICS-Security-Tools — ICS protocol port list (FOUNDATION Fieldbus HSE, 1089-1091)",
"url": "https://github.com/ITI/ICS-Security-Tools/blob/master/protocols/PORTS.md",
"kind": "github"
}
]
},
{
"port": 1091,
"protocol": "tcp",
"service": "FOUNDATION Fieldbus HSE — System Management",
"oneLiner": "System management for FOUNDATION Fieldbus HSE: device addressing, tags, and schedule synchronisation.",
"whatItIs": "System Management is the FOUNDATION Fieldbus service that assigns device addresses and tags, locates devices by tag, and keeps function-block execution schedules synchronised across a segment. The Fieldbus Foundation registered it on 1091 as the third of the HSE ports. It appears on linking devices and gateways from process-automation vendors, and its presence is a strong indicator of an industrial network segment.",
"exposure": {
"verdict": "never",
"note": "This service can address and re-tag field devices. It must stay inside the plant control network, firewalled from IT and unreachable from the internet."
},
"checkCommand": "nmap -sV -Pn -p 1091 TARGET",
"links": [
{
"title": "IANA port registry — 1091 (ff-sm)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=1091",
"kind": "iana"
},
{
"title": "ITI/ICS-Security-Tools — ICS protocol port list (FOUNDATION Fieldbus HSE, 1089-1091)",
"url": "https://github.com/ITI/ICS-Security-Tools/blob/master/protocols/PORTS.md",
"kind": "github"
}
]
},
{
"port": 1093,
"protocol": "tcp",
"service": "PROOF (proofd / xproofd)",
"oneLiner": "PROOF, the Parallel ROOT Facility — a physics analysis cluster accepting remote compute sessions.",
"whatItIs": "PROOF lets a CERN ROOT user run an analysis across a cluster of worker nodes, and 1093 is its registered port: first for the standalone proofd daemon, and later for xproofd, the XRootD-based replacement that froze proofd's development. It turns up on high-energy-physics and other scientific analysis clusters, usually next to XRootD on 1094. A connection here asks the far side to spawn worker processes and run user code.",
"exposure": {
"verdict": "never",
"note": "The service exists to execute code submitted by remote users. Restrict it to the cluster's own network and trusted submit hosts, with authentication configured — never expose it to the internet."
},
"checkCommand": "nc -vz -w 3 TARGET 1093",
"links": [
{
"title": "IANA port registry — 1093 (proofd)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=1093",
"kind": "iana"
},
{
"title": "proofd(1) manual page — PROOF, The Parallel ROOT Facility",
"url": "https://manpages.ubuntu.com/manpages/xenial/man1/proofd.1.html",
"kind": "official-docs"
},
{
"title": "root-project/root — the CERN ROOT framework",
"url": "https://github.com/root-project/root",
"kind": "github"
}
]
},
{
"port": 1094,
"protocol": "tcp",
"service": "rootd / XRootD",
"oneLiner": "Remote access to ROOT data files — the rootd daemon, and today XRootD, the storage backbone of LHC computing.",
"whatItIs": "IANA assigned 1094 to rootd, the ROOT file server daemon, for Fons Rademakers of the CERN ROOT project. rootd itself is long superseded by XRootD, which keeps 1094 as its default listening port and serves data across worldwide grid infrastructure such as the WLCG. Seeing it open means a scientific data server: a storage element, a redirector fronting a federation of them, or an analysis facility's cache.",
"exposure": {
"verdict": "careful",
"note": "Grid XRootD endpoints are intentionally reachable by remote sites, but only with an authentication plugin (GSI/X.509, tokens) configured and read scopes controlled. An XRootD server exporting paths with unauthenticated access is a data leak."
},
"checkCommand": "nc -vz -w 3 TARGET 1094",
"links": [
{
"title": "IANA port registry — 1094 (rootd)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=1094",
"kind": "iana"
},
{
"title": "rootd(1) manual page — the ROOT file server daemon",
"url": "https://manpages.ubuntu.com/manpages/trusty/man1/rootd.1.html",
"kind": "official-docs"
},
{
"title": "xrootd/xrootd — the XRootD data access framework",
"url": "https://github.com/xrootd/xrootd",
"kind": "github"
}
]
},
{
"port": 1096,
"protocol": "tcp",
"service": "CNRP (Common Name Resolution Protocol)",
"oneLiner": "The default port for CNRP, an IETF attempt at resolving human-friendly \"common names\" that never got deployed.",
"whatItIs": "CNRP was designed to let a client resolve an informal name — a company name, a product, a phrase — into URIs, as a complement to DNS. RFC 2972 set out the goals and RFC 3367 defined the protocol in 2002, requiring every generic CNRP client and server to support the HTTP transport on port 1096. The protocol saw essentially no deployment and there is no maintained implementation, so a listener on 1096 today is far more likely to be an unrelated application than a CNRP server.",
"exposure": {
"verdict": "careful",
"note": "CNRP itself is a read-only lookup service over HTTP, but since nothing runs it any more, identify what is actually bound to 1096 before deciding anything."
},
"checkCommand": "curl -sS -m 5 -o /dev/null -w '%{http_code}\\n' http://TARGET:1096/",
"links": [
{
"title": "RFC 3367 — Common Name Resolution Protocol (CNRP)",
"url": "https://www.rfc-editor.org/rfc/rfc3367.html",
"kind": "spec"
},
{
"title": "RFC 2972 — Context and Goals for Common Name Resolution",
"url": "https://www.rfc-editor.org/rfc/rfc2972.html",
"kind": "spec"
},
{
"title": "IANA port registry — 1096 (cnrprotocol)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=1096",
"kind": "iana"
}
]
},
{
"port": 1097,
"protocol": "tcp",
"service": "Sun Cluster Manager",
"oneLiner": "IANA-registered to Sun Cluster Manager; almost never seen on a modern scan.",
"whatItIs": "IANA lists 1097 as sunclustermgr, registered for Sun Cluster Manager, the management interface that shipped with Sun's clustering products for Solaris. Nmap's service-frequency data puts it near the bottom of the range, so an open 1097 today is far more likely to be an unrelated application that picked a free port above 1024. If you find it listening, identify the process locally rather than assuming the registration is accurate.",
"exposure": {
"verdict": "never",
"note": "The registration is a cluster administration plane; whatever is actually listening, an unidentified service on a management-range port does not belong on a public IP."
},
"checkCommand": "sudo lsof -nP -iTCP:1097 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "nmap-services (port name and frequency data)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 1098,
"protocol": "tcp",
"service": "Java RMI activation (rmid)",
"oneLiner": "The RMI activation daemon's internal registry — a removed Java feature that still shows up on old JBoss and legacy JVM stacks.",
"whatItIs": "Running `rmid` started the Java RMI activation system and, per Oracle's documentation, \"starts the Activator and an internal registry on the default port 1098\" with an ActivationSystem bound into it. RMI Activation was deprecated in Java SE 15 and removed outright in Java SE 17 by JEP 407, so anything listening here is running an old JVM or an old application server. In practice 1098 most often turns up next to 1099 on legacy JBoss deployments, which used it for naming-service RMI callbacks to client proxies.",
"exposure": {
"verdict": "never",
"note": "It is a Java RMI endpoint that deserializes attacker-supplied objects; RMI ports reachable from untrusted networks are a standard remote-code-execution path."
},
"checkCommand": "nmap -Pn -p 1098 --script rmi-dumpregistry TARGET",
"links": [
{
"title": "The rmid Command (Java SE 16 tool specification)",
"url": "https://docs.oracle.com/en/java/javase/16/docs/specs/man/rmid.html",
"kind": "official-docs"
},
{
"title": "JEP 407: Remove RMI Activation",
"url": "https://openjdk.org/jeps/407",
"kind": "spec"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1099,
"protocol": "tcp",
"service": "Java RMI registry",
"oneLiner": "The Java RMI registry — a name-to-remote-object lookup that is one of the best-known remote-code-execution surfaces in Java.",
"whatItIs": "`rmiregistry` is Java's bootstrap naming service: servers bind remote objects to names, clients look them up and then invoke methods on them. Oracle's tool documentation is explicit that \"if the port is omitted, then the registry is started on port 1099.\" It appears on scans wherever Java server software is deployed — JMX-enabled JVMs, legacy JBoss and WebLogic tiers, Jenkins-era build infrastructure, and monitoring agents. Because lookups and invocations carry serialized Java objects, an exposed registry is the classic target for deserialization gadget-chain attacks; `ysoserial` ships an RMIRegistryExploit specifically for it.",
"exposure": {
"verdict": "never",
"note": "An internet-reachable RMI registry is routinely turned into code execution via deserialization gadgets. Bind it to localhost or a management network and reach it over a VPN or SSH tunnel."
},
"checkCommand": "nmap -Pn -p 1099 --script rmi-dumpregistry TARGET",
"links": [
{
"title": "The rmiregistry Command (Java SE 21 tool specification)",
"url": "https://docs.oracle.com/en/java/javase/21/docs/specs/man/rmiregistry.html",
"kind": "official-docs"
},
{
"title": "ysoserial — Java deserialization payload generator (RMIRegistryExploit)",
"url": "https://github.com/frohoff/ysoserial",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1100,
"protocol": "tcp",
"service": "MCTP (IANA) / JBoss HA-JNDI",
"oneLiner": "Registered to MCTP, but in the field this is the clustered JBoss HA-JNDI naming port sitting one above 1099.",
"whatItIs": "IANA registers 1100 as mctp. What actually shows up on scans is JBoss Application Server's clustered naming service: the HA-JNDI configuration guide states that the Port attribute \"to which the HA-JNDI server will bind waiting for JNP clients\" defaults to 1100, with the RMI stub port defaulting to 1101. So finding 1100 open usually means a clustered legacy JBoss/EAP node, and 1098, 1099 and 1101 are typically open alongside it. HA-JNDI lets clients read and write the JNDI tree, which is why it has a long CVE history.",
"exposure": {
"verdict": "never",
"note": "A reachable JNDI naming service lets attackers manipulate bindings and pull in remote objects; keep the whole 1098-1101 cluster range on a private network."
},
"checkCommand": "nmap -Pn -p 1098-1101 -sV TARGET",
"links": [
{
"title": "JBoss Server Configuration Guide — Clustered JNDI (HA-JNDI) configuration",
"url": "https://docs.jboss.org/jbossas/docs/Server_Configuration_Guide/4/html/clustering-jndi-jboss.html",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1104,
"protocol": "tcp",
"service": "XRL",
"oneLiner": "Registered to XRL; effectively unused in the wild, so an open 1104 is something else entirely.",
"whatItIs": "IANA assigns 1104 to a service named xrl for both TCP and UDP, with no public protocol specification behind the registration. Nmap's frequency data records it as open on a vanishingly small fraction of scanned hosts. Treat an open 1104 as an unidentified local application that grabbed a low free port, not as evidence of XRL.",
"exposure": {
"verdict": "careful",
"note": "Nothing standard listens here, so the first job is identifying the process; do not expose a service you cannot name."
},
"checkCommand": "sudo lsof -nP -iTCP:1104 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "nmap-services (port name and frequency data)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 1106,
"protocol": "tcp",
"service": "ISOIPSIGPORT-1",
"oneLiner": "Registered as an ISO IP signalling port; no public spec and essentially never observed.",
"whatItIs": "IANA lists 1106 as isoipsigport-1, paired with isoipsigport-2 on 1107, for ISO-over-IP signalling. There is no published specification tied to the registration and no widely deployed implementation, and Nmap's dataset almost never finds it open. An open 1106 is best explained by an unrelated program choosing the port.",
"exposure": {
"verdict": "careful",
"note": "Identify what is actually listening before deciding anything; the registration tells you nothing useful about the risk."
},
"checkCommand": "sudo lsof -nP -iTCP:1106 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1107,
"protocol": "tcp",
"service": "ISOIPSIGPORT-2",
"oneLiner": "The second of the two registered ISO IP signalling ports, and just as rare as the first.",
"whatItIs": "IANA registers 1107 as isoipsigport-2, the companion to 1106. As with its pair, no public protocol document accompanies the registration and Nmap's service-frequency data shows it open on a negligible share of hosts. If you see it, enumerate the listening process rather than trusting the registry name.",
"exposure": {
"verdict": "careful",
"note": "Unknown service on an unused registered port — identify it locally before it faces any untrusted network."
},
"checkCommand": "sudo lsof -nP -iTCP:1107 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1108,
"protocol": "tcp",
"service": "ratio-adp",
"oneLiner": "A vendor registration (ratio-adp) with no public protocol behind it.",
"whatItIs": "IANA assigns 1108 to ratio-adp on TCP and UDP. The registration is a vendor assignment with no published specification or open implementation, and Nmap sees it open on a tiny fraction of scanned hosts. Any open 1108 on your network should be traced to a process rather than read off the registry.",
"exposure": {
"verdict": "careful",
"note": "Unidentified listener: name the process first, then decide. Vendor application ports rarely have authentication worth exposing."
},
"checkCommand": "sudo lsof -nP -iTCP:1108 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1110,
"protocol": "both",
"service": "nfsd-status / webadmstart",
"oneLiner": "Split registration: TCP is \"start web admin server\", UDP is NFS client status — and Nmap labels the TCP side nfsd-status.",
"whatItIs": "IANA registers 1110/tcp as webadmstart (\"Start web admin server\") and 1110/udp as nfsd-keepalive (\"Client status info\"), which is why Nmap's service list calls the TCP side nfsd-status and carries both names in its comments. It is the most frequently observed port in this block, historically alongside NFS status-monitor traffic on Solaris and other Unix hosts. Both readings of the registration point at infrastructure you would not publish: an administrative bootstrap endpoint or NFS-adjacent status.",
"exposure": {
"verdict": "never",
"note": "Either an admin-server hook or NFS status plumbing — both are internal-only. NFS-family services on a public IP are a long-standing compromise route."
},
"checkCommand": "sudo lsof -nP -iTCP:1110 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "nmap-services (port name and frequency data)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 1111,
"protocol": "both",
"service": "LM Social Server",
"oneLiner": "Registered as LM Social Server, but a memorable number that assorted software squats on.",
"whatItIs": "IANA lists 1111 as lmsocialserver for TCP and UDP. The registration has no public specification, and the port's real-world appearances are mostly unrelated software choosing a memorable four-ones number for a local service or test listener. Nmap still ranks it among the more commonly seen ports in this block, which reflects that squatting rather than any deployment of LM Social Server.",
"exposure": {
"verdict": "careful",
"note": "A convenient round number attracts ad-hoc dev listeners; confirm what is bound and whether it has any authentication before it leaves localhost."
},
"checkCommand": "sudo lsof -nP -iTCP:1111 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "nmap-services (port name and frequency data)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 1112,
"protocol": "tcp",
"service": "ICP / mSQL (legacy)",
"oneLiner": "IANA says Intelligent Communication Protocol; Nmap's TCP entry says msql, from early Mini SQL releases.",
"whatItIs": "IANA registers 1112 as icp, the Intelligent Communication Protocol. Nmap's service list names the TCP side msql and carries \"mini-sql server\" among its alternate names, reflecting early Mini SQL builds that listened here before the database settled on its registered port 1114. Neither service is common today; Nmap's frequency data places 1112 near the bottom of what scans find open.",
"exposure": {
"verdict": "never",
"note": "If the listener is an mSQL database, it is a database port and belongs on localhost or a private network; if it is something else, you need to identify it before exposing it at all."
},
"checkCommand": "nmap -Pn -p 1112 -sV TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "nmap-services (port name and frequency data)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 1114,
"protocol": "tcp",
"service": "Mini SQL (mSQL)",
"oneLiner": "Mini SQL, Hughes Technologies' lightweight SQL engine from the mid-1990s.",
"whatItIs": "IANA registers 1114 to mini-sql, David Hughes' Mini SQL — a small embeddable SQL database first released in 1994 and still sold by Hughes Technologies, which notes it has been built into products from HP, Cisco and others. Clients speak its own wire protocol to the msqld server on this port. It shows up today on old Unix hosts and embedded appliances that bundled mSQL, not on new deployments; Nmap's frequency data ranks it very low.",
"exposure": {
"verdict": "never",
"note": "It is a database listener from an era before transport encryption was assumed — keep it bound to loopback or a private network and reach it over SSH."
},
"checkCommand": "nmap -Pn -p 1114 -sV TARGET",
"links": [
{
"title": "Hughes Technologies — mSQL (Mini SQL) product page",
"url": "https://hughestech.com.au/products/msql/",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1117,
"protocol": "tcp",
"service": "ARDUS Multicast Transfer",
"oneLiner": "Registered to ARDUS multicast file transfer; not seen in general scanning.",
"whatItIs": "IANA assigns 1117 to ardus-mtrns, \"ARDUS Multicast Transfer\", one of a small group of ARDUS registrations for a multicast bulk-transfer product. There is no public protocol document, and Nmap's data shows it open on a negligible share of hosts. An open 1117 almost certainly belongs to unrelated local software.",
"exposure": {
"verdict": "careful",
"note": "Unknown vendor protocol — identify the process; multicast transfer tooling is designed for a controlled LAN, not the internet."
},
"checkCommand": "sudo lsof -nP -iTCP:1117 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1119,
"protocol": "both",
"service": "Battle.net (bnetgame)",
"oneLiner": "Blizzard's Battle.net chat/game protocol — an outbound port your games use, not something that listens on your machine.",
"whatItIs": "IANA registers 1119 as bnetgame, \"Battle.net Chat/Game Protocol\". Blizzard's client stack uses it for the Battle.net connection behind titles like World of Warcraft, StarCraft II, Diablo III and Overwatch, which is why home firewall and router guides list TCP 1119 as one of the outbound ports to permit. On a desktop this is a connection going out to Blizzard's servers; a host listening on 1119 is not a Blizzard client and should be identified.",
"exposure": {
"verdict": "fine",
"note": "Allowing outbound TCP 1119 is normal for a machine that plays Blizzard games. Nothing on a home or server network should be accepting inbound connections on it."
},
"checkCommand": "sudo lsof -nP -iTCP:1119",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1122,
"protocol": "tcp",
"service": "availant-mgr",
"oneLiner": "A vendor management registration (availant-mgr) with no public protocol.",
"whatItIs": "IANA registers 1122 as availant-mgr on TCP and UDP. The name points at a management channel for the registering vendor's software, but no specification is published and Nmap's frequency data shows it open on very few hosts. Because it sits just above the SSH-adjacent numbers people like to remember, an open 1122 is often a relocated SSH or another hand-picked service instead.",
"exposure": {
"verdict": "careful",
"note": "Run a version scan before assuming anything; if it turns out to be a management interface or a moved SSH, judge it on what it actually is, not on the port number."
},
"checkCommand": "nmap -Pn -p 1122 -sV TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1124,
"protocol": "tcp",
"service": "HP VMM Control",
"oneLiner": "Registered to HP's virtual machine manager control channel — an HP-UX-era management port.",
"whatItIs": "IANA lists 1124 as hpvmmcontrol, \"HP VMM Control\", the control channel for HP's virtual machine manager on Integrity/HP-UX systems. It is a hypervisor management interface, not a workload port, so it belongs to a shrinking population of legacy HP servers. Nmap's data confirms it is rarely found open.",
"exposure": {
"verdict": "never",
"note": "A hypervisor control channel gives control over every guest on the host; it belongs on an isolated management network, never a public interface."
},
"checkCommand": "sudo lsof -nP -iTCP:1124 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1131,
"protocol": "tcp",
"service": "CASP SSL (caspssl)",
"oneLiner": "The TLS-wrapped half of the CAC App Service Protocol registration; the cleartext side sits on 1130.",
"whatItIs": "IANA registered 1131 in February 2006 as caspssl, \"CAC App Service Protocol Encripted\" (the misspelling is in the registry), paired with casp on 1130 for the unencrypted form. No public specification accompanies the registration, and Nmap's frequency data shows it open on almost no hosts. If 1131 is listening, identify the application; the registry name only tells you the vendor intended TLS.",
"exposure": {
"verdict": "careful",
"note": "The registration implies TLS, but that guarantees nothing about the process actually bound here — verify with a handshake before treating it as encrypted."
},
"checkCommand": "openssl s_client -connect TARGET:1131 -servername TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1138,
"protocol": "tcp",
"service": "encrypted-admin",
"oneLiner": "Registered in 2007 for \"encrypted admin requests\" — a vendor administration channel, not a public protocol.",
"whatItIs": "IANA carries two names for 1138: the original encrypted_admin and encrypted-admin, which IANA assigned later as the well-formed replacement, both described as \"encrypted admin requests\". There is no published protocol, so the registration tells you only that the vendor intended an administrative channel with transport encryption. Nmap sees it open on a negligible fraction of hosts.",
"exposure": {
"verdict": "never",
"note": "Administration planes do not belong on the internet even when they are encrypted; put it behind a VPN and identify the application while you are there."
},
"checkCommand": "sudo lsof -nP -iTCP:1138 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1148,
"protocol": "tcp",
"service": "Elfiq Replication Service",
"oneLiner": "Registered in 2005 for Elfiq link-balancer appliances to replicate state between units.",
"whatItIs": "IANA assigns 1148 to elfiq-repl, \"Elfiq Replication Service\", registered by Elfiq for its link-balancing appliances. The port carries replication traffic between paired units rather than any client-facing service, so it appears only on networks running that hardware. Nmap's dataset finds it open very rarely.",
"exposure": {
"verdict": "never",
"note": "Appliance-to-appliance replication is a trust channel between cluster members; restrict it to the dedicated link between the units."
},
"checkCommand": "nmap -Pn -p 1148 -sV TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1151,
"protocol": "tcp",
"service": "Unizensus Login Server",
"oneLiner": "A 2005 vendor registration for a login server; effectively absent from real scans.",
"whatItIs": "IANA registers 1151 as unizensus, \"Unizensus Login Server\", assigned in November 2005. No protocol specification is published and Nmap's frequency data shows it open on a tiny share of hosts. Treat an open 1151 as an unidentified application rather than as this product.",
"exposure": {
"verdict": "careful",
"note": "The registration is an authentication endpoint with unknown transport security — confirm what is listening and whether credentials cross the wire in the clear."
},
"checkCommand": "sudo lsof -nP -iTCP:1151 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1152,
"protocol": "tcp",
"service": "Winpopup LAN Messenger",
"oneLiner": "Registered to a Windows LAN chat application designed for a trusted office network.",
"whatItIs": "IANA lists 1152 as winpoplanmess, \"Winpopup LAN Messenger\", registered in November 2005. The application is a small Windows messaging tool in the WinPopup lineage, meant for peer-to-peer chat inside one LAN with no expectation of authentication or encryption. It is rare in Nmap's data, and any sighting is confined to Windows desktops running that class of tool.",
"exposure": {
"verdict": "never",
"note": "A LAN chat daemon with no meaningful authentication should never face the internet; keep it on the local segment or replace it."
},
"checkCommand": "nmap -Pn -p 1152 -sV TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1169,
"protocol": "tcp",
"service": "Tripwire",
"oneLiner": "IANA-registered to Tripwire, the file-integrity monitoring vendor.",
"whatItIs": "IANA assigns 1169 to tripwire on TCP and UDP, registered by Tripwire. The original Open Source Tripwire is a local file-integrity checker that compares the filesystem against a signed baseline and opens no network listener at all, so the registration relates to the company's commercial agent/console products rather than the open-source tool. Nmap's frequency data shows it is rarely found open.",
"exposure": {
"verdict": "careful",
"note": "A security-agent control channel is a high-value target — keep it on the management network and confirm which product actually owns the listener."
},
"checkCommand": "sudo lsof -nP -iTCP:1169 -sTCP:LISTEN",
"links": [
{
"title": "Open Source Tripwire (file integrity checker)",
"url": "https://github.com/Tripwire/tripwire-open-source",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1175,
"protocol": "tcp",
"service": "Dossier Server",
"oneLiner": "A 2004 vendor registration for a \"Dossier Server\"; no public protocol and almost never observed.",
"whatItIs": "IANA registers 1175 as dossier, \"Dossier Server\", assigned in November 2004. No specification is published with the registration and Nmap's frequency data places it among the least-seen ports in this block. An open 1175 should be attributed to whatever process is actually bound, not to this name.",
"exposure": {
"verdict": "careful",
"note": "Unidentified vendor service — enumerate the process locally and keep it off untrusted networks until you know what it is."
},
"checkCommand": "sudo lsof -nP -iTCP:1175 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1183,
"protocol": "tcp",
"service": "llsurfup-http",
"oneLiner": "Registered to \"LL Surfup HTTP\" and effectively never seen in the wild.",
"whatItIs": "IANA lists 1183 for both TCP and UDP under the service name llsurfup-http, described only as \"LL Surfup HTTP\", with no assignee recorded and no public protocol specification. There is no maintained product, RFC, or open-source implementation behind the name that can be pointed at today. If 1183 is listening on a host you administer, the registration tells you nothing useful — identify the process locally rather than trusting the registry name.",
"exposure": {
"verdict": "careful",
"note": "An unexpected listener here is an unidentified service, not a known protocol; find the owning process before deciding anything about exposure."
},
"checkCommand": "sudo lsof -nP -iTCP:1183 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1186,
"protocol": "tcp",
"service": "MySQL NDB Cluster management",
"oneLiner": "The NDB Cluster management server (ndb_mgmd) — the control plane for MySQL Cluster, not a SQL port.",
"whatItIs": "MySQL NDB Cluster splits into management nodes (ndb_mgmd), data nodes (ndbd/ndbmtd), and SQL nodes (mysqld). Data and SQL nodes find the management server at port 1186 by default, and the ndb_mgm admin client connects there to run cluster commands. It is not the MySQL client protocol — that stays on 3306. A host listening on 1186 is a MySQL Cluster management node, so 1186 open on a scan tells you a whole cluster is nearby.",
"exposure": {
"verdict": "never",
"note": "The management protocol is the cluster's admin plane and is designed for a trusted private network; keep it on a cluster-internal interface, never on a public IP."
},
"checkCommand": "ndb_mgm -c TARGET:1186 -e show",
"links": [
{
"title": "MySQL Reference Manual — Quick Test Setup of NDB Cluster (default management port 1186)",
"url": "https://dev.mysql.com/doc/refman/8.4/en/mysql-cluster-quick.html",
"kind": "official-docs"
},
{
"title": "MySQL Reference Manual — ndb_mgmd, the NDB Cluster Management Server Daemon",
"url": "https://dev.mysql.com/doc/refman/8.4/en/mysql-cluster-programs-ndb-mgmd.html",
"kind": "official-docs"
},
{
"title": "MySQL Server (GitHub)",
"url": "https://github.com/mysql/mysql-server",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1199,
"protocol": "tcp",
"service": "DMIDI",
"oneLiner": "Registered for DMIDI, a distributed MIDI transport; almost never seen on real networks.",
"whatItIs": "IANA assigns 1199 on TCP and UDP to the service name dmidi (\"DMIDI\"), registered by Phil Kerr for carrying MIDI messages between machines over IP. It is not one of the transports that current music software defaults to — RTP-MIDI and vendor-specific protocols carry that traffic instead. In practice you will not meet 1199 on a scan of ordinary infrastructure, and a listener there is more likely some unrelated application that picked a free port than a DMIDI implementation.",
"exposure": {
"verdict": "careful",
"note": "Treat an open 1199 as an unidentified local application until you have confirmed the owning process; the registration name is not evidence of what is running."
},
"checkCommand": "sudo lsof -nP -iTCP:1199 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1201,
"protocol": "both",
"service": "Nucleus Sand Database Server",
"oneLiner": "IANA-registered to the Nucleus Sand database server; a historical assignment you will rarely encounter.",
"whatItIs": "Port 1201 is registered on TCP and UDP as nucleus-sand, \"Nucleus Sand Database Server\", assigned to James Marsh. The Sand analytic database (later Sand Technology's Nucleus/SAND CDBMS) is a niche column-store product with no current public protocol documentation at this port. There is nothing else well documented that habitually squats here, so an open 1201 on a modern host is almost certainly an unrelated program that grabbed a free registered port.",
"exposure": {
"verdict": "careful",
"note": "If this really is a database listener it belongs on a private network; if it is not, identify the process before leaving it reachable."
},
"checkCommand": "sudo lsof -nP -iTCP:1201 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1218,
"protocol": "tcp",
"service": "AeroFlight-ADs",
"oneLiner": "Registered as AeroFlight-ADs, with no assignee and no public documentation.",
"whatItIs": "IANA lists 1218 on TCP and UDP under the service name aeroflight-ads (\"AeroFlight-ADs\"), and the registry carries no assignee for it. No specification, vendor page, or open-source implementation of the protocol is publicly available. That is the whole honest picture: the number is reserved, and nothing well-documented uses it. Anything found listening here should be identified from the host itself.",
"exposure": {
"verdict": "careful",
"note": "Unknown service; do not expose a listener you cannot name."
},
"checkCommand": "sudo lsof -nP -iTCP:1218 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1234,
"protocol": "both",
"service": "QEMU gdbstub / VLC streaming (unofficial); Infoseek search-agent (registered)",
"oneLiner": "The classic \"pick a memorable port\" number — QEMU's debug stub and VLC's stream examples both land here.",
"whatItIs": "The IANA registration is search-agent, \"Infoseek Search Agent\", which has no practical presence today. What actually uses 1234 is convention: QEMU's `-s` flag makes the guest's gdbstub listen on TCP 1234 so GDB can attach, and VLC's UDP/RTP streaming examples use 1234 as the destination port. Because it is short and easy to remember, ad-hoc test servers and tutorials pick it constantly, so an open 1234 usually means someone's debugger, stream, or throwaway listener rather than a defined service.",
"exposure": {
"verdict": "never",
"note": "A QEMU gdbstub is unauthenticated full control of the guest, including memory writes — bind it to localhost. Ad-hoc listeners on 1234 are, by nature, not hardened."
},
"checkCommand": "sudo lsof -nP -iTCP:1234 -sTCP:LISTEN",
"links": [
{
"title": "QEMU — GDB usage (`-s` listens for gdb on TCP port 1234)",
"url": "https://www.qemu.org/docs/master/system/gdb.html",
"kind": "official-docs"
},
{
"title": "VLC User Documentation — Stream over UDP",
"url": "https://docs.videolan.me/vlc-user/desktop/3.0/en/advanced/streaming/stream_over_udp.html",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1247,
"protocol": "tcp",
"service": "VisionPyramid",
"oneLiner": "Registered to VisionPyramid; no public protocol documentation exists.",
"whatItIs": "IANA assigns 1247 on TCP and UDP to visionpyramid (\"VisionPyramid\"), registered by Gavin Hutchinson. There is no published specification and no maintained product documentation for it that can be cited. Nothing notable is documented as squatting on 1247 either, so on a scan it is best treated as an unidentified local application rather than a known service.",
"exposure": {
"verdict": "careful",
"note": "Identify the listening process before drawing any conclusion; the registry name is not evidence."
},
"checkCommand": "sudo lsof -nP -iTCP:1247 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1248,
"protocol": "tcp",
"service": "hermes",
"oneLiner": "Registered simply as \"hermes\", with no assignee and no specification.",
"whatItIs": "Port 1248 is listed by IANA on TCP and UDP under the service name hermes, with an empty assignee field and a description that repeats the name. \"Hermes\" is a name reused by many unrelated projects, so the registration does not identify any particular software. There is no protocol document to read and nothing well-documented that habitually listens here.",
"exposure": {
"verdict": "careful",
"note": "Unknown service; find the owning process locally before exposing or allowing it through a firewall."
},
"checkCommand": "sudo lsof -nP -iTCP:1248 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1271,
"protocol": "both",
"service": "eXcW",
"oneLiner": "Registered as eXcW; a legacy assignment with no public documentation.",
"whatItIs": "IANA lists 1271 on TCP and UDP as excw (\"eXcW\"), registered by Norm Freedman. No specification or current product documentation for the protocol is publicly available, and no widely documented software squats on the number. On a scan this is an unidentified listener whose identity has to come from the host, not from the registry.",
"exposure": {
"verdict": "careful",
"note": "Unknown service; do not leave a listener you cannot identify reachable from untrusted networks."
},
"checkCommand": "sudo lsof -nP -iTCP:1271 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1272,
"protocol": "tcp",
"service": "CSPMLockMgr",
"oneLiner": "Registered as CSPMLockMgr, the lock manager of Cisco's long-discontinued Secure Policy Manager.",
"whatItIs": "IANA assigns 1272 on TCP and UDP to cspmlockmgr (\"CSPMLockMgr\"), registered by Ibtsam Mahfouz. The name matches Cisco Secure Policy Manager, a centralised firewall/VPN policy product Cisco retired long ago; its lock-manager component used this port. Cisco no longer ships or documents the product, so a listener on 1272 today is almost certainly unrelated software that took a free registered port.",
"exposure": {
"verdict": "careful",
"note": "Any surviving instance would be an end-of-life management component with no security maintenance; identify what is actually listening and keep it off public networks."
},
"checkCommand": "sudo lsof -nP -iTCP:1272 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1296,
"protocol": "both",
"service": "dproxy",
"oneLiner": "Registered as dproxy, with no assignee and no protocol specification on record.",
"whatItIs": "IANA lists 1296 on TCP and UDP under the service name dproxy, described only as \"dproxy\", with no assignee. The name collides with several unrelated proxy projects, so it does not pin down any particular software, and no specification is published for the registered use. Nothing notable is documented as habitually listening on 1296.",
"exposure": {
"verdict": "careful",
"note": "Any proxy reachable from untrusted networks risks being used as an open relay; identify the process and confirm it is not forwarding for strangers."
},
"checkCommand": "sudo lsof -nP -iTCP:1296 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1310,
"protocol": "tcp",
"service": "Husky",
"oneLiner": "Registered as Husky; a legacy assignment with nothing documented behind it.",
"whatItIs": "Port 1310 is registered on TCP and UDP as husky (\"Husky\"), assigned to Mark Zang. There is no published protocol specification and no current product documentation identifying what spoke on it. \"Husky\" is also the name of an unrelated Fidonet software family and of a popular Git-hooks tool, neither of which listens on a network port — a good reminder that a registry name is not an identification.",
"exposure": {
"verdict": "careful",
"note": "Unknown service; determine the owning process before allowing it through a firewall."
},
"checkCommand": "sudo lsof -nP -iTCP:1310 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 1311,
"protocol": "tcp",
"service": "Dell OpenManage Server Administrator",
"oneLiner": "The HTTPS web console for Dell OpenManage Server Administrator — a server's hardware admin plane.",
"whatItIs": "Dell OpenManage Server Administrator (OMSA) runs an embedded web server on TCP 1311 and serves its console over HTTPS at https://host:1311. Through it an authenticated operator reads hardware health, RAID and firmware state, and performs management actions on a PowerEdge server. The IANA registration for 1311 is the unrelated \"RxMon\", so on a scan of Dell hardware treat 1311 as OMSA. Its presence marks the host as a physical Dell server with the management agent installed.",
"exposure": {
"verdict": "never",
"note": "This is a hardware administration console with credentials in front of it; OMSA has a history of remotely exploitable CVEs and belongs on a management VLAN, never on the internet."
},
"checkCommand": "openssl s_client -connect TARGET:1311 -servername TARGET :1947. It appears on engineering and CAD workstations, license servers, and industrial or lab PCs, usually installed as a silent dependency of some vendor's protected application rather than deliberately.",
"exposure": {
"verdict": "never",
"note": "This is an admin plane: the Admin Control Center exposes license and host configuration over unauthenticated-by-default HTTP, and the run-time environment has a long history of vendor and ICS advisories — keep it on the LAN behind a firewall rule."
},
"checkCommand": "curl -sS -i --max-time 5 http://TARGET:1947/ | head -20",
"links": [
{
"title": "Thales Sentinel LDK — Launching Admin Control Center",
"url": "https://docs.sentinel.thalesgroup.com/ldk/LDKdocs/SPNL/LDK_SLnP_Guide/Distributing/Admin_Control_Center/110-LaunchingAdmin.htm",
"kind": "official-docs"
},
{
"title": "IANA port registry — 1947 (sentinelsrm)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=1947",
"kind": "iana"
}
]
},
{
"port": 1984,
"protocol": "tcp",
"service": "Big Brother / Xymon",
"oneLiner": "The Big Brother monitoring port, still in service as Xymon's server port.",
"whatItIs": "IANA registers 1984 as bb, for the Big Brother monitoring system. Big Brother itself is long dead, but its successor Xymon kept the port: xymond listens on 0.0.0.0:1984 by default and accepts status reports from client machines as well as query and control commands. If you find it open, you are looking at a monitoring server, and its clients are pushing to it from across the network.",
"exposure": {
"verdict": "never",
"note": "The Xymon protocol has no authentication — anyone who can reach the port can inject false status, read the monitoring database, and issue control commands, so keep it inside the monitored network."
},
"checkCommand": "printf 'ping\\n' | nc -w 3 TARGET 1984",
"links": [
{
"title": "xymond(8) manual page — default listen 0.0.0.0:1984",
"url": "https://xymon.sourceforge.io/xymon/help/manpages/man8/xymond.8.html",
"kind": "official-docs"
},
{
"title": "Xymon Monitor project site",
"url": "https://xymon.sourceforge.io/",
"kind": "official-docs"
},
{
"title": "IANA port registry — 1984 (bb)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=1984",
"kind": "iana"
}
]
},
{
"port": 1998,
"protocol": "tcp",
"service": "XOT (X.25 over TCP)",
"oneLiner": "Cisco's X.25-over-TCP tunnel — legacy WAN plumbing that occasionally still answers.",
"whatItIs": "RFC 1613 defines XOT, which carries X.25 packets inside a TCP stream with a four-byte header, and states that all connections MUST be made to TCP port 1998, a port Cisco registered for the purpose. It exists so routers can bridge X.25 links across an IP network, and it survives mostly in banking, telco, and industrial networks that never finished migrating off X.25. An open 1998 almost always means a Cisco or Cisco-compatible router with XOT configured.",
"exposure": {
"verdict": "never",
"note": "XOT has no authentication or encryption and tunnels straight into a legacy WAN through a router — it belongs on a private link between the two routers that need it."
},
"checkCommand": "nc -vz TARGET 1998",
"links": [
{
"title": "RFC 1613 — Cisco Systems X.25 over TCP (XOT)",
"url": "https://www.rfc-editor.org/rfc/rfc1613.html",
"kind": "spec"
},
{
"title": "IANA port registry — 1998 (x25-svc-port)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=1998",
"kind": "iana"
}
]
},
{
"port": 1999,
"protocol": "tcp",
"service": "Cisco identification port",
"oneLiner": "Registered to Cisco as an identification port; rarely seen in the wild.",
"whatItIs": "IANA lists 1999 as tcp-id-port, \"cisco identification port\", registered by Cisco Systems. There is no public protocol specification for it and it is not a service you deliberately turn on. In practice a listener here is either a Cisco device or, more often, an unrelated application that grabbed a round number just below 2000.",
"exposure": {
"verdict": "careful",
"note": "Nothing well documented runs here, so treat an open 1999 as an unidentified listener: fingerprint it before deciding, and do not expose an unknown service to the internet."
},
"checkCommand": "nc -vz TARGET 1999",
"links": [
{
"title": "IANA port registry — 1999 (tcp-id-port)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=1999",
"kind": "iana"
}
]
},
{
"port": 2000,
"protocol": "tcp",
"service": "Cisco SCCP (Skinny)",
"oneLiner": "Cisco SCCP — the \"Skinny\" call-control protocol between IP phones and Unified Communications Manager.",
"whatItIs": "IANA registers 2000 as cisco-sccp, and Cisco's own firewall documentation states that Unified Communications Manager uses TCP port 2000, the default SCCP port, to serve SCCP clients. A Cisco IP phone opens a TCP connection here to register, then receives call setup, keypad, and display instructions over it while the media itself flows separately over RTP. It also shows up on Cisco routers and gateways running SCCP telephony features.",
"exposure": {
"verdict": "never",
"note": "SCCP is a cleartext call-control plane — exposing it invites call-setup abuse, toll fraud, and eavesdropping on who is calling whom; keep voice on its own VLAN."
},
"checkCommand": "nc -vz TARGET 2000",
"links": [
{
"title": "Cisco — Firewall Support of Skinny Client Control Protocol",
"url": "https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_data_zbf/configuration/xe-16-6/sec-data-zbf-xe-16-6-book/sec-data-sccp.html",
"kind": "official-docs"
},
{
"title": "IANA port registry — 2000 (cisco-sccp)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2000",
"kind": "iana"
}
]
},
{
"port": 2001,
"protocol": "tcp",
"service": "dc (IANA) / Cisco reverse-telnet line 1",
"oneLiner": "Registered as dc, but in practice the first reverse-telnet line on a Cisco terminal server.",
"whatItIs": "IANA registers 2001/tcp as dc with no description. What you actually meet on this port is Cisco reverse telnet: on a terminal or comm server the listening port for an async line is 2000 plus the line number, so 2001 is line 1, and connecting drops you onto that line's attached console. Lab racks, out-of-band console servers, and console-server software that imitates the Cisco convention all use this numbering.",
"exposure": {
"verdict": "never",
"note": "A reverse-telnet port is an unencrypted console session on someone else's device, frequently already logged in — this is out-of-band management and belongs on a management network reached over SSH or VPN."
},
"checkCommand": "nc -vz TARGET 2001",
"links": [
{
"title": "Cisco — Configuring a Terminal/Comm Server (reverse telnet port = 2000 + line)",
"url": "https://www.cisco.com/c/en/us/support/docs/dial-access/asynchronous-connections/5466-comm-server.html",
"kind": "official-docs"
},
{
"title": "IANA port registry — 2001 (dc)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2001",
"kind": "iana"
}
]
},
{
"port": 2002,
"protocol": "tcp",
"service": "globe",
"oneLiner": "Registered as globe; in practice a Cisco reverse-telnet line or whatever local app claimed it.",
"whatItIs": "IANA registers 2002/tcp and udp as globe, with no description and no public protocol document. The realistic explanations for an open 2002 are line 2 of a Cisco terminal server, since reverse-telnet ports are 2000 plus the line number, or an application that picked a free port in the 2000s. Treat the registered name as trivia, not as an identification.",
"exposure": {
"verdict": "careful",
"note": "Identify the listener before judging it — if it turns out to be reverse telnet to a device console, that is a management plane and must not face the internet."
},
"checkCommand": "nc -vz TARGET 2002",
"links": [
{
"title": "IANA port registry — 2002 (globe)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2002",
"kind": "iana"
}
]
},
{
"port": 2003,
"protocol": "tcp",
"service": "Graphite carbon (plaintext)",
"oneLiner": "Graphite's plaintext metrics receiver — one metric per line, no authentication at all.",
"whatItIs": "IANA currently registers 2003 as brutus, and older /etc/services files call it cfingerd or GNU finger, but on a modern host this is Graphite: carbon-cache's plaintext line receiver runs on 2003 by default and accepts lines of the form \"metric.path value timestamp\". Anything that ships metrics — collectd, StatsD backends, Diamond, application code — writes here. If 2003 is open on a monitoring box, it is the metrics firehose inlet.",
"exposure": {
"verdict": "never",
"note": "The plaintext protocol has no authentication and no rate limiting, so anyone who can reach it can poison your metrics or fill the disk with new whisper files — bind it to the private network."
},
"checkCommand": "printf 'whatport.test 1 %s\\n' \"$(date +%s)\" | nc -w 2 TARGET 2003",
"links": [
{
"title": "Graphite documentation — Feeding In Your Data (plaintext, port 2003)",
"url": "https://graphite.readthedocs.io/en/latest/feeding-carbon.html",
"kind": "official-docs"
},
{
"title": "graphite-project/carbon",
"url": "https://github.com/graphite-project/carbon",
"kind": "github"
},
{
"title": "IANA port registry — 2003 (brutus)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2003",
"kind": "iana"
}
]
},
{
"port": 2004,
"protocol": "tcp",
"service": "Graphite carbon (pickle)",
"oneLiner": "Graphite's pickle receiver — the batched, binary sibling of 2003.",
"whatItIs": "IANA registers 2004/tcp as mailbox, a name with no live meaning. In practice it is carbon's pickle receiver, which Graphite documents as running on port 2004 by default and which accepts batches of metrics in Python's pickle serialization instead of one line at a time. It is what carbon-relay and high-volume senders use, so it usually appears alongside 2003 on the same monitoring host.",
"exposure": {
"verdict": "never",
"note": "Unauthenticated like 2003, and it deserializes attacker-supplied pickle data — keep it strictly on the private network."
},
"checkCommand": "nc -vz TARGET 2004",
"links": [
{
"title": "Graphite documentation — Feeding In Your Data (pickle, port 2004)",
"url": "https://graphite.readthedocs.io/en/latest/feeding-carbon.html",
"kind": "official-docs"
},
{
"title": "graphite-project/carbon",
"url": "https://github.com/graphite-project/carbon",
"kind": "github"
},
{
"title": "IANA port registry — 2004 (mailbox)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2004",
"kind": "iana"
}
]
},
{
"port": 2005,
"protocol": "tcp",
"service": "berknet / deslogin (legacy)",
"oneLiner": "A legacy registration — berknet at IANA, deslogin in old /etc/services, Cisco line 5 in practice.",
"whatItIs": "IANA registers 2005/tcp as berknet and 2005/udp as oracle; traditional Unix /etc/services files instead call it deslogin, an encrypted symmetric telnet replacement from the early 1990s. None of these are in real use today. A listener on 2005 is realistically line 5 of a Cisco terminal server (reverse telnet uses 2000 plus the line number) or an unrelated local application.",
"exposure": {
"verdict": "careful",
"note": "Fingerprint what is actually there; if it is a device console over reverse telnet, that is cleartext management access and must stay internal."
},
"checkCommand": "nc -vz TARGET 2005",
"links": [
{
"title": "IANA port registry — 2005 (berknet)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2005",
"kind": "iana"
}
]
},
{
"port": 2006,
"protocol": "tcp",
"service": "invokator",
"oneLiner": "Registered as invokator with no description; nothing well known runs here.",
"whatItIs": "IANA registers 2006/tcp as invokator and 2006/udp as raid-cd, both undocumented holdovers from the early registry. There is no public specification and no widely deployed software that claims the port. The plausible cause of an open 2006 is Cisco reverse telnet to line 6, or an application that took a free port in the 2000s range.",
"exposure": {
"verdict": "careful",
"note": "Unidentified listener: fingerprint it and do not publish it until you know what it is."
},
"checkCommand": "nc -vz TARGET 2006",
"links": [
{
"title": "IANA port registry — 2006 (invokator)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2006",
"kind": "iana"
}
]
},
{
"port": 2007,
"protocol": "tcp",
"service": "dectalk",
"oneLiner": "Registered as dectalk, after the DEC speech synthesizer; effectively unused today.",
"whatItIs": "IANA registers 2007/tcp as dectalk, a name inherited from Digital Equipment Corporation's DECtalk speech synthesis product, and 2007/udp as raid-am. Neither corresponds to software you are likely to meet now. In practice an open 2007 is Cisco reverse telnet to line 7 or a locally chosen application port.",
"exposure": {
"verdict": "careful",
"note": "Unidentified listener: fingerprint it before exposing anything on it."
},
"checkCommand": "nc -vz TARGET 2007",
"links": [
{
"title": "IANA port registry — 2007 (dectalk)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2007",
"kind": "iana"
}
]
},
{
"port": 2008,
"protocol": "tcp",
"service": "conf",
"oneLiner": "Registered as conf with no description; no current standard service.",
"whatItIs": "IANA registers 2008/tcp as conf and 2008/udp as terminaldb, two undocumented early registrations. No maintained protocol uses either name. As with its neighbours, an open 2008 in a network-gear context is usually reverse telnet to line 8 on a Cisco terminal server, and elsewhere it is an application that simply picked the port.",
"exposure": {
"verdict": "careful",
"note": "Unidentified listener: fingerprint it before deciding whether it may be reachable."
},
"checkCommand": "nc -vz TARGET 2008",
"links": [
{
"title": "IANA port registry — 2008 (conf)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2008",
"kind": "iana"
}
]
},
{
"port": 2009,
"protocol": "tcp",
"service": "news",
"oneLiner": "Registered as news — unrelated to NNTP, which lives on 119.",
"whatItIs": "IANA registers 2009/tcp as news and 2009/udp as whosockami, with no descriptions. The name is misleading: Usenet news is NNTP on 119, not here, and nothing maintained claims 2009. An open port here is most likely Cisco reverse telnet to line 9 or an arbitrary local service.",
"exposure": {
"verdict": "careful",
"note": "Do not trust the registered name — identify the real listener before exposing it."
},
"checkCommand": "nc -vz TARGET 2009",
"links": [
{
"title": "IANA port registry — 2009 (news)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2009",
"kind": "iana"
}
]
},
{
"port": 2010,
"protocol": "tcp",
"service": "search",
"oneLiner": "Registered as search with no description; no standard service behind the name.",
"whatItIs": "IANA registers 2010/tcp as search and 2010/udp as pipe-server, both undocumented. There is no protocol specification and no common daemon that binds it by default. Realistically it is Cisco reverse telnet to line 10 or an application that chose a round number.",
"exposure": {
"verdict": "careful",
"note": "Unidentified listener: fingerprint it, and assume a console or admin service until proven otherwise."
},
"checkCommand": "nc -vz TARGET 2010",
"links": [
{
"title": "IANA port registry — 2010 (search)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2010",
"kind": "iana"
}
]
},
{
"port": 2013,
"protocol": "tcp",
"service": "raid-am",
"oneLiner": "One of the old \"raid-*\" registrations; almost never seen open.",
"whatItIs": "IANA registers 2013/tcp as raid-am and 2013/udp as raid-cd, part of a block of early raid- names scattered through the 2006 to 2018 range that carry only the description \"raid\" and no public specification. Nothing in current use implements them. On network gear the port falls inside the Cisco reverse-telnet range, where it would be line 13.",
"exposure": {
"verdict": "careful",
"note": "Unidentified listener: fingerprint it before exposing it, and treat any console-like response as management access."
},
"checkCommand": "nc -vz TARGET 2013",
"links": [
{
"title": "IANA port registry — 2013 (raid-am)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2013",
"kind": "iana"
}
]
},
{
"port": 2020,
"protocol": "tcp",
"service": "xinupageserver",
"oneLiner": "Registered to the Xinu teaching operating system; a historical name with no live protocol.",
"whatItIs": "IANA registers 2020 as xinupageserver, from Xinu, Douglas Comer's teaching operating system at Purdue, whose remote page server used this port. It is a museum registration: no shipping software binds it today. An open 2020 is an application that took the port, or reverse telnet to line 20 on a Cisco terminal server.",
"exposure": {
"verdict": "careful",
"note": "Unidentified listener: identify it before allowing it through a firewall."
},
"checkCommand": "nc -vz TARGET 2020",
"links": [
{
"title": "IANA port registry — 2020 (xinupageserver)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2020",
"kind": "iana"
}
]
},
{
"port": 2021,
"protocol": "tcp",
"service": "servexec",
"oneLiner": "Registered as servexec (xinuexpansion1 on UDP); no current standard service.",
"whatItIs": "IANA registers 2021/tcp as servexec and 2021/udp as xinuexpansion1, another pair of undocumented early registrations. Nothing maintained implements them. Because it sits one digit above the FTP control port, 2021 is also a common manual choice for an alternate FTP or SFTP listener, so fingerprint rather than assume.",
"exposure": {
"verdict": "careful",
"note": "If it turns out to be FTP moved off 21, that is cleartext authentication and should be never — replace it with SFTP or FTPS."
},
"checkCommand": "nc -vz TARGET 2021",
"links": [
{
"title": "IANA port registry — 2021 (servexec)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2021",
"kind": "iana"
}
]
},
{
"port": 2022,
"protocol": "tcp",
"service": "down (IANA) / alternate SSH in practice",
"oneLiner": "Registered as down, but in the field it is usually SSH moved off 22.",
"whatItIs": "IANA registers 2022/tcp as down and 2022/udp as xinuexpansion2, neither of which corresponds to real software. The common reason this port is open is a second sshd, or a container or appliance publishing SSH on an alternate port to keep 22 free on the host. Connect and read the banner: a real SSH server announces itself with a line like SSH-2.0-OpenSSH_9.6 before anything else.",
"exposure": {
"verdict": "careful",
"note": "Moving SSH off 22 only quiets the logs, it is not a control — if it is SSH, judge it as SSH (public-key only, passwords disabled); if it is something else, identify it first."
},
"checkCommand": "nc -w 3 TARGET 2022 | head -1",
"links": [
{
"title": "IANA port registry — 2022 (down)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2022",
"kind": "iana"
}
]
},
{
"port": 2030,
"protocol": "tcp",
"service": "device2",
"oneLiner": "Registered as device2 with no description; rarely seen.",
"whatItIs": "IANA registers 2030 as device2 on both TCP and UDP, an undocumented early registration with no public specification and no known current implementation. It shows up in scan data only at very low rates. If it is open, something local chose it — the registered name tells you nothing useful.",
"exposure": {
"verdict": "careful",
"note": "Unidentified listener: fingerprint it and keep it internal until you know what it serves."
},
"checkCommand": "nc -vz TARGET 2030",
"links": [
{
"title": "IANA port registry — 2030 (device2)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2030",
"kind": "iana"
}
]
},
{
"port": 2033,
"protocol": "tcp",
"service": "glogger",
"oneLiner": "Registered as glogger with no description; effectively unused.",
"whatItIs": "IANA registers 2033 as glogger on TCP and UDP. There is no published protocol for it and no widely deployed daemon that binds it by default. An open 2033 is an application that picked the port rather than any standard service.",
"exposure": {
"verdict": "careful",
"note": "Unidentified listener: identify it before allowing inbound traffic."
},
"checkCommand": "nc -vz TARGET 2033",
"links": [
{
"title": "IANA port registry — 2033 (glogger)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2033",
"kind": "iana"
}
]
},
{
"port": 2034,
"protocol": "tcp",
"service": "scoremgr",
"oneLiner": "Registered as scoremgr with no description; effectively unused.",
"whatItIs": "IANA registers 2034 as scoremgr on TCP and UDP, another undocumented early registration. No public specification exists and no common software claims it, so the registry entry is a name and nothing more. Anything answering here is a local choice that needs fingerprinting.",
"exposure": {
"verdict": "careful",
"note": "Unidentified listener: fingerprint it and keep it off the public internet until you know what it is."
},
"checkCommand": "nc -vz TARGET 2034",
"links": [
{
"title": "IANA port registry — 2034 (scoremgr)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2034",
"kind": "iana"
}
]
},
{
"port": 2035,
"protocol": "both",
"service": "imsldoc (registration only)",
"oneLiner": "An IANA name with nothing behind it — no description, no assignee, no published protocol.",
"whatItIs": "IANA registers the service name imsldoc on TCP and UDP 2035 with no description, no assignee and no reference document, which is typical of early bulk port registrations that were never written up. No widely deployed software claims the port, and Nmap's frequency data ranks it among the rarest it tracks (open on roughly 0.02% of scanned hosts). If you find 2035 listening, the registry label tells you nothing useful — identify the process on the host instead.",
"exposure": {
"verdict": "careful",
"note": "The name carries no meaning, so an open 2035 is an unidentified service. Find the owning process before deciding whether it belongs on a public interface."
},
"checkCommand": "sudo lsof -nP -iTCP:2035 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "nmap-services — Nmap port frequency data",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 2038,
"protocol": "both",
"service": "objectmanager (registration only)",
"oneLiner": "Registered as objectmanager with no documentation and no known implementation.",
"whatItIs": "The IANA registry lists objectmanager on TCP and UDP 2038 with an empty description, assignee and reference. Nothing well-known listens here, and Nmap's data shows it open on about 0.02% of scanned hosts. The generic name attracts guesses about CIM/WBEM object managers, but those services register elsewhere (5988/5989); the 2038 entry has no published protocol behind it.",
"exposure": {
"verdict": "careful",
"note": "Treat a listener here as unidentified software. Whatever is answering is not the registry name, so judge exposure by the actual process."
},
"checkCommand": "sudo lsof -nP -iTCP:2038 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "nmap-services — Nmap port frequency data",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 2040,
"protocol": "both",
"service": "lam (registration only)",
"oneLiner": "IANA name \"lam\", undocumented — three letters and nothing else.",
"whatItIs": "TCP and UDP 2040 carry the registered service name lam, with no description, assignee or reference in the IANA registry, and the same bare name appears in /etc/services on most Unix systems. There is no published protocol and no common implementation; Nmap sees it open on roughly 0.03% of hosts. The short name collides with unrelated software people recognise, so do not read a product into it.",
"exposure": {
"verdict": "careful",
"note": "An unnamed service in practice. Identify the listening process before exposing it anywhere."
},
"checkCommand": "sudo lsof -nP -iTCP:2040 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "nmap-services — Nmap port frequency data",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 2041,
"protocol": "both",
"service": "interbase (registration name only)",
"oneLiner": "Named \"interbase\" in the registry, but the InterBase/Firebird database actually lives on 3050.",
"whatItIs": "IANA lists the service name interbase on TCP and UDP 2041 with no description, assignee or reference. The database engine the name suggests does not use it: Borland InterBase and its open-source descendant Firebird use the registered gds-db service on port 3050, which is what their servers bind by default. So 2041 is a historical name with no protocol documented and no common software behind it — Nmap sees it open on about 0.02% of hosts.",
"exposure": {
"verdict": "careful",
"note": "Do not assume a database. A listener here is unidentified; if you are actually looking for InterBase or Firebird, check 3050 instead."
},
"checkCommand": "sudo lsof -nP -iTCP:2041 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "Firebird — the InterBase-derived open source database",
"url": "https://firebirdsql.org/",
"kind": "official-docs"
}
]
},
{
"port": 2042,
"protocol": "both",
"service": "isis (registration only)",
"oneLiner": "Registered as \"isis\" — and it is not the IS-IS routing protocol.",
"whatItIs": "IANA registers the name isis on TCP and UDP 2042, with isis-bcast next door on 2043; the entry carries no description or reference document. The obvious guess is wrong: the IS-IS routing protocol (ISO 10589, extended for IP by RFC 1195) runs directly over the data link layer and has no TCP or UDP port at all, so nothing you see on 2042 is IS-IS. Nmap finds the port open on about 0.02% of scanned hosts, and no common software claims it.",
"exposure": {
"verdict": "careful",
"note": "The name misleads. Identify the actual listener rather than assuming a routing daemon, and expose it only once you know what it is."
},
"checkCommand": "sudo lsof -nP -iTCP:2042 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "RFC 1195 — Use of OSI IS-IS for Routing in TCP/IP and Dual Environments",
"url": "https://www.rfc-editor.org/rfc/rfc1195.html",
"kind": "spec"
}
]
},
{
"port": 2043,
"protocol": "both",
"service": "isis-bcast (registration only)",
"oneLiner": "The companion registration to 2042's \"isis\", equally undocumented.",
"whatItIs": "IANA lists isis-bcast on TCP and UDP 2043, assigned to Ken Chapman, with the service name repeated as its only description and no reference document. It pairs with isis on 2042 and, like it, has nothing to do with the IS-IS routing protocol, which runs over layer 2 and uses no transport port. Nmap sees 2043 open on roughly 0.02% of hosts, so in practice this is a name in a table rather than a protocol you will meet.",
"exposure": {
"verdict": "careful",
"note": "No documented protocol means no defensible default. Identify the process behind an open 2043 before deciding anything about exposure."
},
"checkCommand": "sudo lsof -nP -iTCP:2043 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "nmap-services — Nmap port frequency data",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 2045,
"protocol": "both",
"service": "cdfunc (registration only)",
"oneLiner": "Registered name cdfunc, no description, no assignee, no known software.",
"whatItIs": "TCP and UDP 2045 hold the IANA name cdfunc with every other field blank, and it sits next to sdfunc on 2046 as an obviously paired registration whose meaning was never published. No common implementation binds it; Nmap reports it open on about 0.02% of scanned hosts. This is one of the ports where the honest answer is that the registry entry is the entire body of public knowledge.",
"exposure": {
"verdict": "careful",
"note": "Unidentified by definition — whatever answers here is not documented, so establish what it is before letting anything reach it."
},
"checkCommand": "sudo lsof -nP -iTCP:2045 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "nmap-services — Nmap port frequency data",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 2046,
"protocol": "both",
"service": "sdfunc (registration only)",
"oneLiner": "The sibling of 2045's cdfunc — same blank registration, same absence of software.",
"whatItIs": "IANA registers sdfunc on TCP and UDP 2046 with no description, assignee or reference, and it appears in Unix /etc/services as a bare name for the same reason. Nothing widely deployed listens here, and Nmap's frequency table puts it near the bottom at roughly 0.02% of hosts. There is no protocol to describe because none was ever documented.",
"exposure": {
"verdict": "careful",
"note": "A listener on an undocumented port is an unknown service. Identify the process before exposing it."
},
"checkCommand": "sudo lsof -nP -iTCP:2046 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "nmap-services — Nmap port frequency data",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 2047,
"protocol": "both",
"service": "dls (registration only)",
"oneLiner": "Named dls in the registry, with no description — and not the Directory Location Service, which is port 197.",
"whatItIs": "IANA lists dls on TCP and UDP 2047 with no description, assignee or reference. The same three letters are also registered at port 197 where they do mean something — Directory Location Service — so the 2047 entry is a name collision rather than the same protocol on a second port. It pairs with dls-monitor on 2048, and neither has published documentation; Nmap sees 2047 open on about 0.02% of hosts.",
"exposure": {
"verdict": "careful",
"note": "No documented protocol and a misleading name. Identify the listening process rather than inferring a service from the label."
},
"checkCommand": "sudo lsof -nP -iTCP:2047 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "nmap-services — Nmap port frequency data",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 2048,
"protocol": "both",
"service": "dls-monitor (registration only)",
"oneLiner": "Registered dls-monitor with no documentation; notable mainly for how often UDP scans get a response here.",
"whatItIs": "IANA registers dls-monitor on TCP and UDP 2048 with no description, assignee or reference, paired with dls on 2047. TCP 2048 is as rare as its neighbours, but Nmap's frequency data is an outlier for UDP: 2048/udp responds on roughly 2% of scanned hosts, far above the surrounding ports and without any documented service to explain it. Whatever produces that, the registry name is not a reliable guide to what you have found.",
"exposure": {
"verdict": "careful",
"note": "The label is meaningless and the UDP responses are unexplained; identify the process on the host before treating anything here as benign or exposing it."
},
"checkCommand": "sudo lsof -nP -iTCP:2048 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "nmap-services — Nmap port frequency data",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 2049,
"protocol": "both",
"service": "NFS",
"oneLiner": "The Network File System — whole file systems mounted over the network, on the best-known port in the 2000s.",
"whatItIs": "The NFS server daemon (nfsd) answers here, serving remote file system operations over TCP or UDP; RFC 5665 also registers NFS over SCTP. NFSv2 and v3 (RFC 1813) needed rpcbind on 111 plus separately bound mountd, statd and lockd helpers, while NFSv4 (RFC 8881) dropped that entirely and specifies 2049 as the single well-known port carrying mounting and locking in-band. You will find it on Linux and BSD file servers, NAS appliances, ESXi datastores and macOS, usually alongside 111 if v3 is still enabled. With the default AUTH_SYS flavour the server trusts the client's claimed UID and GID, so the export's access control is really the client's honesty plus your export list.",
"exposure": {
"verdict": "never",
"note": "AUTH_SYS lets anyone who can reach the port assert any UID, so an internet-facing export is readable and often writable by strangers. Keep NFS on a private network or a VPN, and require Kerberos (sec=krb5p) if it must cross untrusted paths."
},
"checkCommand": "showmount -e TARGET",
"links": [
{
"title": "RFC 8881 — Network File System (NFS) Version 4 Minor Version 1 Protocol",
"url": "https://www.rfc-editor.org/rfc/rfc8881.html",
"kind": "spec"
},
{
"title": "RFC 1813 — NFS Version 3 Protocol Specification",
"url": "https://www.rfc-editor.org/rfc/rfc1813.html",
"kind": "spec"
},
{
"title": "RFC 5665 — IANA Considerations for Remote Procedure Call (RPC) Net Identifiers",
"url": "https://www.rfc-editor.org/rfc/rfc5665.html",
"kind": "spec"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 2065,
"protocol": "tcp",
"service": "DLSw read port",
"oneLiner": "Data Link Switching — SNA and NetBIOS traffic tunnelled between routers over TCP.",
"whatItIs": "DLSw carries IBM SNA and NetBIOS frames across an IP backbone by terminating the local link control at each router and tunnelling over TCP. RFC 1795 defines the default socket pair as read port 2065 and write port 2067; DLSw version 2 (RFC 2166) and common vendor implementations settle on a single connection to 2065. If it is open, you are looking at a router or a legacy gateway keeping mainframe-era traffic alive, not a general-purpose server. There is no encryption and no user authentication in the protocol — peers are identified by configuration.",
"exposure": {
"verdict": "never",
"note": "A cleartext, unauthenticated router-to-router tunnel into an internal SNA/NetBIOS network. Keep DLSw peers on private links or inside an IPsec tunnel."
},
"checkCommand": "nc -vz TARGET 2065",
"links": [
{
"title": "RFC 1795 — Data Link Switching: Switch-to-Switch Protocol",
"url": "https://www.rfc-editor.org/rfc/rfc1795.html",
"kind": "spec"
},
{
"title": "RFC 2166 — DLSw version 2 Enhancements",
"url": "https://www.rfc-editor.org/rfc/rfc2166.html",
"kind": "spec"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 2068,
"protocol": "tcp",
"service": "Avocent KVM-over-IP",
"oneLiner": "Keyboard, video and mouse traffic for Avocent (now Vertiv) KVM-over-IP appliances.",
"whatItIs": "IANA registers 2068 as the Avocent AuthSrv Protocol, and Vertiv's own DSView port documentation lists 2068/tcp as the KVM session channel (\"dsr-kbd+mouse\") used by DSR switches, MergePoint and Universal Management Gateway appliances and their UMIQ modules. Nmap labels it avocentkvm for the same reason. Finding it open means a KVM appliance is present, usually next to 22, 443, 3211 and 8192 on the same box. That appliance drives the console of the attached servers — BIOS, boot loader, everything — so the port fronts an out-of-band control plane, not an application.",
"exposure": {
"verdict": "never",
"note": "KVM-over-IP is full pre-boot console access to whatever is plugged in. Keep management appliances on an isolated management network reached over a VPN."
},
"checkCommand": "nc -vz TARGET 2068",
"links": [
{
"title": "Vertiv Avocent DSView 4.5 TCP/UDP Ports Technical Note",
"url": "https://www.vertiv.com/globalassets/products/monitoring-control-and-management/software/avocent-dsview-management-software/vertiv-avocent-dsview-4.5-tcp_udp-ports-tech-note.pdf",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 2100,
"protocol": "tcp",
"service": "Amiga Network Filesystem / Oracle XML DB FTP",
"oneLiner": "Registered to the Amiga Network Filesystem, but in practice usually Oracle XML DB's FTP listener.",
"whatItIs": "IANA assigns 2100 to the Amiga Network Filesystem, which you will essentially never meet. What actually turns up on this port is Oracle XML DB: Oracle's documentation uses 2100 as the FTP port for reaching the XML DB repository, and older database installs shipped it preconfigured alongside HTTP on 8080. Current releases disable it — the ftp-port setting defaults to 0 — so an open 2100 on a database host means someone turned FTP on. Connect and you get an FTP banner naming Oracle, and logins are database accounts.",
"exposure": {
"verdict": "never",
"note": "If it is Oracle XML DB, this is cleartext FTP authenticating with database credentials straight into the repository. Leave ftp-port at 0 and use HTTPS/WebDAV or a tunnel instead."
},
"checkCommand": "printf 'QUIT\\r\\n' | nc -v TARGET 2100",
"links": [
{
"title": "Oracle Database 19c — Repository Access Using Protocols (FTP, HTTP(S), WebDAV)",
"url": "https://docs.oracle.com/en/database/oracle/oracle-database/19/adxdb/repository-access-using-protocols.html",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 2103,
"protocol": "tcp",
"service": "Zephyr serv-hm / MSMQ RPC",
"oneLiner": "Registered to MIT's Zephyr notification service; on Windows hosts it is Microsoft Message Queuing's RPC port.",
"whatItIs": "IANA and /etc/services name 2103 zephyr-clt, the server-to-hostmanager link in MIT Project Athena's Zephyr messaging system, which sits between zephyr-srv on 2102 and zephyr-hm on 2104. In modern scanning the port almost always means something else: MSMQ independent clients and servers listen on 2103 (with 2105) for RPC-based remote reads of public and private queues, after the client asks the endpoint mapper on 135 which ports to use. That is why 2103 shows up far more often than its neighbours — it is a Windows host with Message Queuing installed.",
"exposure": {
"verdict": "never",
"note": "An MSMQ RPC endpoint exposes queue contents to whoever can authenticate, and RPC services on 135/2103/2105 are a standing target. Keep Message Queuing inside the network."
},
"checkCommand": "nc -vz TARGET 2103",
"links": [
{
"title": "Microsoft — ports used by MSMQ (1801, 135, 2103/2105, 2107, 3527)",
"url": "https://learn.microsoft.com/en-us/archive/blogs/johnbreakwell/clear-the-way-msmq-coming-through",
"kind": "official-docs"
},
{
"title": "Zephyr notification system (MIT Project Athena)",
"url": "https://github.com/zephyr-im/zephyr",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 2105,
"protocol": "tcp",
"service": "eklogin / MSMQ RPC (IANA: MiniPay)",
"oneLiner": "Three claimants: IANA says MiniPay, Unix says Kerberos encrypted rlogin, Windows uses it for MSMQ RPC.",
"whatItIs": "IANA registers 2105 as MiniPay, which you will not encounter. Unix /etc/services and Nmap call it eklogin, the encrypted Kerberos rlogin service from the Kerberos v4 and early v5 era; MIT unbundled those application programs from krb5 at release 1.8 into the separate krb5-appl package, so a live eklogin daemon today is very old software. On Windows, 2105 is the second RPC port MSMQ uses for remote queue reads alongside 2103, which accounts for most of what scanners find here.",
"exposure": {
"verdict": "never",
"note": "Either reading is bad on a public interface: an abandoned Kerberized remote-login daemon, or an MSMQ RPC endpoint. Neither belongs outside a private network."
},
"checkCommand": "nc -vz TARGET 2105",
"links": [
{
"title": "Microsoft — ports used by MSMQ (1801, 135, 2103/2105, 2107, 3527)",
"url": "https://learn.microsoft.com/en-us/archive/blogs/johnbreakwell/clear-the-way-msmq-coming-through",
"kind": "official-docs"
},
{
"title": "krb5-appl — the Kerberized telnet/rlogin/ftp applications split out of MIT krb5",
"url": "https://github.com/krb5/krb5-appl",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 2106,
"protocol": "both",
"service": "MZAP / ekshell",
"oneLiner": "MZAP's multicast scope announcements on UDP; historically Kerberos encrypted rshell on TCP.",
"whatItIs": "RFC 2776 defines the Multicast-Scope Zone Announcement Protocol here: routers on a scope boundary send Zone Announcement Messages to UDP 2106 at the local-scope group 239.255.255.252 so hosts can discover administrative scope zones and operators can spot misconfigured boundaries. That traffic is multicast infrastructure, not something a host offers. Unix /etc/services and Nmap also list ekshell on TCP 2106, the encrypted Kerberos remote-shell counterpart to eklogin, which MIT moved out of krb5 along with the rest of the Kerberized applications.",
"exposure": {
"verdict": "careful",
"note": "MZAP is scoped multicast that is not meant to cross a zone boundary at all. A TCP listener here is something else — historically a Kerberized rshell daemon — and should be identified and kept internal."
},
"checkCommand": "sudo tcpdump -ni any udp port 2106",
"links": [
{
"title": "RFC 2776 — Multicast-Scope Zone Announcement Protocol (MZAP)",
"url": "https://www.rfc-editor.org/rfc/rfc2776.html",
"kind": "spec"
},
{
"title": "krb5-appl — the Kerberized telnet/rlogin/ftp applications split out of MIT krb5",
"url": "https://github.com/krb5/krb5-appl",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 2107,
"protocol": "tcp",
"service": "MSMQ management RPC (IANA: BinTec Admin)",
"oneLiner": "MSMQ's remote management RPC endpoint, registered to IANA as BinTec router administration.",
"whatItIs": "IANA assigns 2107 to BinTec Admin, the administration service of BinTec (later Teldat) routers. In practice the port belongs to Windows: from MSMQ 3.0 onwards Message Queuing listens on 2107 for RPC calls to its remote management APIs, which is why Nmap labels it msmq-mgmt and why it appears on Windows servers next to 135, 1801, 2103 and 2105. Both readings describe an administrative interface rather than an application protocol.",
"exposure": {
"verdict": "never",
"note": "This is a management plane in either reading — MSMQ remote administration or a router admin service. Restrict it to a management network."
},
"checkCommand": "nc -vz TARGET 2107",
"links": [
{
"title": "Microsoft — ports used by MSMQ (2107 for remote management APIs)",
"url": "https://learn.microsoft.com/en-us/archive/blogs/johnbreakwell/clear-the-way-msmq-coming-through",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 2111,
"protocol": "tcp",
"service": "kx (X over Kerberos) / OPNET DSATP",
"oneLiner": "IANA registers OPNET's Dynamic Sampling Agent protocol; Unix /etc/services calls it kx, X over Kerberos.",
"whatItIs": "The IANA entry for 2111 is dsatp, the OPNET Dynamic Sampling Agent Transaction Protocol, assigned to OPNET Technologies. Unix service tables and Nmap instead name it kx, \"X over Kerberos\" — the Kerberized X11 forwarding daemon that shipped with the Kerberos application suite before SSH forwarding replaced it. Neither is common: Nmap finds 2111 open on about 0.03% of hosts. If it is answering, treat it as legacy monitoring or legacy Kerberos plumbing and confirm which by looking at the process.",
"exposure": {
"verdict": "never",
"note": "Both candidates are unmaintained: a monitoring agent transaction port or a Kerberized X-forwarding daemon that hands out display access. Keep it off public interfaces."
},
"checkCommand": "sudo lsof -nP -iTCP:2111 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "nmap-services — Nmap port frequency data",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 2119,
"protocol": "tcp",
"service": "Globus GRAM gatekeeper",
"oneLiner": "The Globus gatekeeper — GSI-authenticated job submission on grid computing clusters.",
"whatItIs": "globus-gatekeeper is the front door of Globus GRAM: it authenticates an incoming TCP connection with GSI (X.509 proxy certificates over GSSAPI), maps the client's distinguished name to a local Unix account through the grid-mapfile, and then starts the requested service, normally a job manager that submits work to the site's batch scheduler. Running as root it defaults to port 2119. You find it on academic and national-lab compute clusters, alongside the GRIS information service on 2135. The Globus Toolkit itself is retired; surviving deployments run the community-maintained Grid Community Toolkit.",
"exposure": {
"verdict": "careful",
"note": "It is designed to be reachable between grid sites, but it runs jobs as local users on the strength of your CA trust and grid-mapfile. Only expose it with those maintained and the software patched — an abandoned gatekeeper is remote job execution on unsupported code."
},
"checkCommand": "nc -vz TARGET 2119",
"links": [
{
"title": "Grid Community Toolkit — GRAM5 Administrator's Guide (globus-gatekeeper, default port 2119)",
"url": "https://gridcf.org/gct-docs/latest/gram5/admin/index.html",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 2121,
"protocol": "tcp",
"service": "Alternate FTP / FTP proxy",
"oneLiner": "FTP's unprivileged twin — where an FTP server or FTP proxy lands when it cannot bind port 21.",
"whatItIs": "IANA registers 2121 as SCIENTIA-SSDB, but that is not what runs there. In practice 2121 is the conventional alternate FTP port: it is above 1024, so a daemon can bind it without root, and it is where FTP proxies land — Nmap names the port ccproxy-ftp after CCProxy's FTP proxy service. It is common enough to matter, open on roughly 0.6% of scanned hosts, well ahead of everything around it. A connection returns a normal FTP banner, and the protocol is RFC 959 FTP with all of its properties intact.",
"exposure": {
"verdict": "careful",
"note": "Same rules as port 21: cleartext credentials unless the session negotiates AUTH TLS (RFC 4217), and an open FTP proxy here can be abused to relay traffic. Moving FTP off 21 hides it from nobody."
},
"checkCommand": "printf 'QUIT\\r\\n' | nc -v TARGET 2121",
"links": [
{
"title": "RFC 959 — File Transfer Protocol (FTP)",
"url": "https://www.rfc-editor.org/rfc/rfc959.html",
"kind": "spec"
},
{
"title": "nmap-services — 2121/tcp listed as ccproxy-ftp",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 2126,
"protocol": "tcp",
"service": "PacketCable COPS",
"oneLiner": "COPS signalling between a cable operator's call server and its CMTS to authorize per-call QoS.",
"whatItIs": "IANA registers 2126 as PktCable-COPS, assigned to CableLabs. It carries the Common Open Policy Service protocol (RFC 2748) in PacketCable's Dynamic QoS architecture: the Call Management Server acts as the policy decision point and the CMTS as the policy enforcement point, and the CMTS opens gates that reserve DOCSIS bandwidth for a voice call only when the CMS authorizes it over this connection. This is operator infrastructure — you meet it inside a cable headend, not on a customer network.",
"exposure": {
"verdict": "never",
"note": "Anything that can talk COPS to a CMTS can influence which sessions get authorized bandwidth. Keep it on the operator's internal signalling network."
},
"checkCommand": "nc -vz TARGET 2126",
"links": [
{
"title": "RFC 2748 — The COPS (Common Open Policy Service) Protocol",
"url": "https://www.rfc-editor.org/rfc/rfc2748.html",
"kind": "spec"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 2135,
"protocol": "tcp",
"service": "GRIS (Grid Resource Information Server)",
"oneLiner": "The Globus MDS resource information service — an LDAP-backed description of what a cluster has.",
"whatItIs": "IANA assigns 2135 to the Grid Resource Information Server, registered by Steve Tuecke of the Globus project. GRIS is the resource-level half of the Globus Monitoring and Discovery Service: an LDAP-speaking daemon on a compute resource that publishes what the site has — CPUs, memory, queues, software — which site-level index servers then aggregate for job schedulers. It appears on grid clusters next to the GRAM gatekeeper on 2119. The Globus Toolkit MDS stack is retired, so anything still answering here is old software.",
"exposure": {
"verdict": "careful",
"note": "Read-only by design, but it advertises a detailed inventory of your compute hosts and runs on unmaintained code. Publish it only to the grid peers that need it."
},
"checkCommand": "nc -vz TARGET 2135",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "Grid Community Toolkit documentation (successor to the Globus Toolkit)",
"url": "https://gridcf.org/gct-docs/latest/gram5/user/index.html",
"kind": "official-docs"
}
]
},
{
"port": 2144,
"protocol": "tcp",
"service": "LiveVault Fast Object Transfer",
"oneLiner": "Registered to LiveVault's online-backup agent; effectively extinct in the wild.",
"whatItIs": "IANA registers 2144 as lv-ffx, \"Live Vault Fast Object Transfer\", with the neighbouring 2145 (lv-pici) registered for LiveVault's remote diagnostic console. LiveVault sold a hosted continuous-backup service whose Windows agents pushed changed data to its data centres; the company was acquired by Iron Mountain and the product line is long gone. No current software defaults to this port, so anything listening here today is almost certainly an unrelated program that grabbed a free high port. Treat the registered name as a label, not as identification.",
"exposure": {
"verdict": "careful",
"note": "Nothing supported should be listening here — identify the actual process before deciding anything, and do not trust the IANA name to tell you what it is."
},
"checkCommand": "sudo lsof -nP -iTCP:2144 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 2144 (lv-ffx)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2144",
"kind": "iana"
}
],
"ianaName": "lv-ffx"
},
{
"port": 2160,
"protocol": "tcp",
"service": "APC PowerChute (legacy)",
"oneLiner": "One of three ports IANA hands to APC with no protocol description, and no public document says what ran on it.",
"whatItIs": "IANA registers 2160 to American Power Conversion (now Schneider Electric) as literally \"APC 2160\", the same non-description given to 2161 and 2260. No public specification or vendor document describes what any of the three carried. Schneider's current port documentation lists TCP 6547 for the PowerChute agent web UI and UDP 161 for its SNMP agent, and says nothing about 2160, so a listener here points at an old PowerChute install rather than anything shipping today.",
"exposure": {
"verdict": "never",
"note": "An APC-registered port with no published protocol, most plausibly legacy UPS management software — anything near the machinery that shuts servers down belongs on a management network."
},
"checkCommand": "nc -vz TARGET 2160",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 2160 (apc-2160)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2160",
"kind": "iana"
},
{
"title": "Schneider Electric — TCP and UDP ports used by each component of PowerChute",
"url": "https://www.se.com/us/en/faqs/FA159597/",
"kind": "official-docs"
}
],
"ianaName": "apc-2160"
},
{
"port": 2161,
"protocol": "tcp",
"service": "APC PowerChute agent (legacy)",
"oneLiner": "The APC-registered port most often seen in practice — PowerChute Business Edition agent traffic.",
"whatItIs": "IANA registers 2161 to American Power Conversion (now Schneider Electric) as \"APC 2161\", with no protocol detail. Of APC's three registered ports it is the one that actually turned up on scans: PowerChute Business Edition agents on UPS-attached servers listened here for their management server. Schneider's current PowerChute port list documents TCP 6547 for the agent web UI and UDP 161 for SNMP, so 2161 marks an older install. Note the easy misread — this is not SNMP, which is 161.",
"exposure": {
"verdict": "never",
"note": "Old UPS-shutdown agent software reachable from the network is a power-off control path; restrict it to a management VLAN and prefer a currently supported PowerChute release."
},
"checkCommand": "nc -vz TARGET 2161",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 2161 (apc-2161)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2161",
"kind": "iana"
},
{
"title": "Schneider Electric — TCP and UDP ports used by each component of PowerChute",
"url": "https://www.se.com/us/en/faqs/FA159597/",
"kind": "official-docs"
}
],
"ianaName": "apc-2161"
},
{
"port": 2179,
"protocol": "tcp",
"service": "Hyper-V VMConnect (vmrdp)",
"oneLiner": "The Hyper-V host's virtual machine console listener — RDP to a VM's screen, not to the VM's own network stack.",
"whatItIs": "IANA registers 2179 as vmrdp, \"Microsoft RDP for virtual machines\". The Hyper-V host's Virtual Machine Management Service listens here, and VMConnect (the Connect button in Hyper-V Manager, and the same path used by System Center VMM) uses it to attach to a guest's console. Because the connection terminates at the hypervisor, it works whether the guest is booting, crashed, or has no network configured at all — which is exactly why it is different from plain RDP on 3389. Microsoft's own cluster troubleshooting guidance tells admins to open 2179 for VMConnect, so it shows up on the management NIC of Hyper-V hosts and failover-cluster nodes.",
"exposure": {
"verdict": "never",
"note": "This is console access to every VM on the host, below the guest OS. It belongs on a management network reachable only by Hyper-V administrators."
},
"checkCommand": "nc -vz TARGET 2179",
"links": [
{
"title": "Microsoft Learn — Troubleshoot Hyper-V cluster connectivity and management (open port 2179 for VMConnect)",
"url": "https://learn.microsoft.com/en-us/troubleshoot/windows-server/virtualization/hyper-v-cluster-connectivity-management-configuration",
"kind": "official-docs"
},
{
"title": "mRemoteNG documentation — Connect to a virtual machine on Hyper-V (port 2179)",
"url": "https://mremoteng.readthedocs.io/en/v1.77.3-dev/howtos/vmrdp.html",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 2179 (vmrdp)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2179",
"kind": "iana"
}
],
"ianaName": "vmrdp"
},
{
"port": 2190,
"protocol": "both",
"service": "TiVoConnect Beacon",
"oneLiner": "TiVo boxes announcing themselves to each other on the local network.",
"whatItIs": "IANA registers 2190 as tivoconnect, \"TiVoConnect Beacon\"; TiVo's own documentation calls it the TiVoConnect Discovery Protocol. A DVR broadcasts a short plaintext beacon over UDP 2190 carrying its machine identity, platform, software version, and the services it offers, and peers can also exchange the same records over TCP 2190. It exists so two TiVo units on one LAN find each other without configuration. Wireshark ships a dissector for it, which is the most accessible description of the on-the-wire format.",
"exposure": {
"verdict": "careful",
"note": "Unauthenticated device-identity broadcasts designed for a home LAN — harmless there, but it leaks model and software version to anyone on the same segment and has no reason to cross a router."
},
"checkCommand": "sudo tcpdump -ni any udp port 2190",
"links": [
{
"title": "Wireshark — packet-tivoconnect.c (TiVoConnect Discovery Protocol dissector)",
"url": "https://github.com/wireshark/wireshark/blob/master/epan/dissectors/packet-tivoconnect.c",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 2190 (tivoconnect)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2190",
"kind": "iana"
}
],
"ianaName": "tivoconnect"
},
{
"port": 2191,
"protocol": "tcp",
"service": "TvBus Messaging",
"oneLiner": "Registered as \"TvBus Messaging\" and essentially undocumented in public.",
"whatItIs": "IANA registers 2191 as tvbus, \"TvBus Messaging\". There is no published specification and no widely deployed product that defaults to it, so unlike its neighbour 2190 it carries no recognisable traffic on modern networks. If you find it open, the registration tells you nothing useful — identify the listening process instead.",
"exposure": {
"verdict": "careful",
"note": "An unidentified listener is the finding here; the registered name does not establish what is running or whether it authenticates."
},
"checkCommand": "sudo lsof -nP -iTCP:2191 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 2191 (tvbus)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2191",
"kind": "iana"
}
],
"ianaName": "tvbus"
},
{
"port": 2222,
"protocol": "both",
"service": "EtherNet/IP I/O, SSH alternate, DirectAdmin",
"oneLiner": "Three unrelated things share this number: EtherNet/IP I/O, a moved SSH daemon, and the DirectAdmin control panel.",
"whatItIs": "IANA registers 2222 to ODVA as EtherNet/IP-1 for EtherNet/IP I/O — the cyclic UDP \"implicit messaging\" that carries real-time data between PLCs and devices, with explicit (request/response) messaging on 44818. On IT networks the same number means something else entirely: it is the most common place admins move sshd to, and it is the default port of the DirectAdmin hosting control panel, whose documentation discusses changing it because 2222 cannot be proxied through Cloudflare. Identify the service before drawing any conclusion — an SSH banner, a TLS web login, and industrial I/O look nothing alike.",
"exposure": {
"verdict": "careful",
"note": "Depends entirely on what answers. OpenSSH here is exactly as safe as on 22 (moving it cuts log noise, it is not a control). EtherNet/IP has no authentication and must never leave the plant network, and a hosting control panel is an admin plane worth restricting by source address."
},
"checkCommand": "nc -v TARGET 2222",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 2222 (EtherNet/IP-1)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2222",
"kind": "iana"
},
{
"title": "DirectAdmin Docs — directadmin.conf values (default port 2222)",
"url": "https://docs.directadmin.com/directadmin/general-usage/all-directadmin-conf-values.html",
"kind": "official-docs"
}
],
"ianaName": "EtherNet/IP-1"
},
{
"port": 2251,
"protocol": "tcp",
"service": "Distributed Framework Port",
"oneLiner": "An IANA registration with no public protocol behind it.",
"whatItIs": "IANA registers 2251 as dif-port, \"Distributed Framework Port\". No specification was published with the registration and no commonly deployed software defaults here, so the entry is a reserved name rather than a protocol you will meet on a scan. A listener on 2251 is best identified by process, not by the registry.",
"exposure": {
"verdict": "careful",
"note": "Unknown service: find out what bound the port and whether it authenticates before exposing anything."
},
"checkCommand": "sudo lsof -nP -iTCP:2251 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 2251 (dif-port)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2251",
"kind": "iana"
}
],
"ianaName": "dif-port"
},
{
"port": 2260,
"protocol": "tcp",
"service": "APC PowerChute console (legacy)",
"oneLiner": "The third of APC's undescribed registrations, with no published protocol behind it.",
"whatItIs": "IANA registers 2260 to American Power Conversion (now Schneider Electric) as \"APC 2260\", with no protocol description, exactly like 2160 and 2161. No public document describes the protocol or which PowerChute component used it. Schneider's current PowerChute port documentation lists only TCP 6547 for the agent web UI and UDP 161 for SNMP, so a listener here points at legacy APC software rather than anything shipping today.",
"exposure": {
"verdict": "never",
"note": "An unidentified listener on a port registered to UPS management software; keep it to a management segment and identify the process before allowing any inbound access."
},
"checkCommand": "nc -vz TARGET 2260",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 2260 (apc-2260)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2260",
"kind": "iana"
},
{
"title": "Schneider Electric — TCP and UDP ports used by each component of PowerChute",
"url": "https://www.se.com/us/en/faqs/FA159597/",
"kind": "official-docs"
}
],
"ianaName": "apc-2260"
},
{
"port": 2301,
"protocol": "tcp",
"service": "HP/HPE System Management Homepage (HTTP)",
"oneLiner": "The plain-HTTP front door of HP's server management web UI, which bounces you to HTTPS on 2381.",
"whatItIs": "IANA registers 2301 as cpq-wbem, \"Compaq HTTP\" — the name survives from Compaq's Insight Manager agents, which became HP and then HPE System Management Homepage (SMH). SMH is the local web console on ProLiant servers showing hardware health, firmware, storage, and agent status. Port 2301 exists for backwards compatibility: a browser hitting it is redirected to the real UI on HTTPS 2381. Finding it open identifies the box as a ProLiant (or an HP-UX system) running the SMH agents.",
"exposure": {
"verdict": "never",
"note": "A cleartext HTTP entry point to a server hardware admin console. Even though it redirects, the management plane of a physical server has no business on a public network — keep SMH on the management LAN."
},
"checkCommand": "curl -sI http://TARGET:2301/",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 2301 (cpq-wbem)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2301",
"kind": "iana"
}
],
"ianaName": "cpq-wbem"
},
{
"port": 2323,
"protocol": "tcp",
"service": "Telnet alternate (IoT)",
"oneLiner": "Registered as 3d-nfsd, used in the real world as a second telnet port on embedded devices — and scanned constantly because of it.",
"whatItIs": "IANA registers 2323 as 3d-nfsd, a name you will effectively never see on the wire. What actually listens here is telnet: consumer routers, IP cameras, DVRs, and other embedded gear that either moved telnet off 23 or ran a second instance on 2323. Mirai and its many derivatives scan both 23 and 2323 and try lists of default credentials against whatever answers, which is why 2323 sees continuous unsolicited traffic on any public IP. The leaked Mirai source shows the scanner and its credential list directly.",
"exposure": {
"verdict": "never",
"note": "Cleartext login with no server authentication, on the exact port a decade of IoT botnets brute-force by default. There is no safe internet-facing configuration — disable it and use SSH."
},
"checkCommand": "nc -v TARGET 2323",
"links": [
{
"title": "Mirai source code (bot, scanner, loader, CnC) — research archive",
"url": "https://github.com/jgamblin/Mirai-Source-Code",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 2323 (3d-nfsd)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2323",
"kind": "iana"
}
],
"ianaName": "3d-nfsd"
},
{
"port": 2381,
"protocol": "tcp",
"service": "HP/HPE System Management Homepage (HTTPS)",
"oneLiner": "The actual HP System Management Homepage UI — server hardware health and configuration over HTTPS.",
"whatItIs": "IANA registers 2381 as compaq-https, \"Compaq HTTPS\". This is where HP/HPE System Management Homepage really serves its interface: sign in at https://host:2381/ to see ProLiant hardware status, storage and firmware inventory, and the Insight agents' data. Port 2301 exists only to redirect browsers here. It appears on ProLiant servers and HP-UX systems with the management agents installed, and its login page identifies both the vendor and the SMH version.",
"exposure": {
"verdict": "never",
"note": "A server hardware administration console with a credentialed login and a long CVE history in older SMH releases; restrict it to a management network."
},
"checkCommand": "curl -skI https://TARGET:2381/",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 2381 (compaq-https)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2381",
"kind": "iana"
}
],
"ianaName": "compaq-https"
},
{
"port": 2383,
"protocol": "tcp",
"service": "SQL Server Analysis Services",
"oneLiner": "The default instance of SQL Server Analysis Services — the OLAP/tabular engine behind Excel and Power BI cubes.",
"whatItIs": "Microsoft documents TCP 2383 as the port a default SQL Server Analysis Services instance listens on, and the port a failover-clustered instance always uses regardless of naming. Named instances take a dynamic port instead and rely on SQL Server Browser on TCP 2382 to redirect clients. The listening port comes from the Port setting in msmdsrv.ini (0 means \"use 2383 or a dynamic port\"), and SSAS uses TCP only — no UDP. On a scan it marks a BI server holding aggregated business data.",
"exposure": {
"verdict": "never",
"note": "An analytical database engine with its own security model and no reason to face the internet — keep it behind the firewall and reach it over a VPN or a gateway service."
},
"checkCommand": "nc -vz TARGET 2383",
"links": [
{
"title": "Microsoft Learn — Configure the Windows Firewall to Allow Analysis Services Access",
"url": "https://learn.microsoft.com/en-us/analysis-services/instances/configure-the-windows-firewall-to-allow-analysis-services-access",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 2383 (ms-olap4)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2383",
"kind": "iana"
}
],
"ianaName": "ms-olap4"
},
{
"port": 2393,
"protocol": "tcp",
"service": "Microsoft OLAP (legacy)",
"oneLiner": "A Microsoft OLAP registration from the pre-Analysis-Services era; dormant today.",
"whatItIs": "IANA registers 2393 as ms-olap1, \"MS OLAP 1\", one of a block Microsoft took for its OLAP server work alongside 2394 (ms-olap2), 2382 (ms-olap3) and 2383 (ms-olap4). Current SQL Server Analysis Services documentation only ever names 2383 for the engine and 2382 for the SQL Server Browser redirector, so 2393 is a historical reservation rather than a port modern SQL Server binds. Anything answering here today should be identified by process rather than assumed to be Microsoft OLAP.",
"exposure": {
"verdict": "never",
"note": "If something genuinely OLAP-shaped is listening it is a database engine, and if it is something else you do not know what it is — neither belongs on a public interface."
},
"checkCommand": "sudo lsof -nP -iTCP:2393 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 2393 (ms-olap1)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2393",
"kind": "iana"
},
{
"title": "Microsoft Learn — Configure the Windows Firewall to Allow Analysis Services Access (documents 2382/2383)",
"url": "https://learn.microsoft.com/en-us/analysis-services/instances/configure-the-windows-firewall-to-allow-analysis-services-access",
"kind": "official-docs"
}
],
"ianaName": "ms-olap1"
},
{
"port": 2394,
"protocol": "tcp",
"service": "Microsoft OLAP (legacy)",
"oneLiner": "The second of Microsoft's early OLAP registrations, and just as dormant as the first.",
"whatItIs": "IANA registers 2394 as ms-olap2, \"MS OLAP 2\", registered by Microsoft's Analysis Services team next to ms-olap1 on 2393. Microsoft's current Analysis Services firewall documentation names only TCP 2383 (default instance) and TCP 2382 (SQL Server Browser), so 2394 does not correspond to anything a supported SQL Server installs. Identify any listener here by process; the registry name will not tell you what it is.",
"exposure": {
"verdict": "never",
"note": "Either an unidentified service or a legacy database listener — keep it off public interfaces either way."
},
"checkCommand": "sudo lsof -nP -iTCP:2394 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 2394 (ms-olap2)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2394",
"kind": "iana"
},
{
"title": "Microsoft Learn — Configure the Windows Firewall to Allow Analysis Services Access (documents 2382/2383)",
"url": "https://learn.microsoft.com/en-us/analysis-services/instances/configure-the-windows-firewall-to-allow-analysis-services-access",
"kind": "official-docs"
}
],
"ianaName": "ms-olap2"
},
{
"port": 2399,
"protocol": "tcp",
"service": "FileMaker Server ODBC/JDBC",
"oneLiner": "FileMaker Server's xDBC listener — SQL access to hosted FileMaker databases.",
"whatItIs": "IANA registers 2399 as fmpro-fdal, \"FileMaker, Inc. - Data Access Layer\". Claris documents it as the port that must be open for ODBC and JDBC clients to query hosted FileMaker files, and the JDBC driver's port is fixed at 2399 — it cannot be moved. Access still requires an account whose privilege set carries the fmxdcc extended privilege, and the listener only accepts connections when ODBC/JDBC sharing is enabled on the server. On a scan it identifies a FileMaker Server, usually alongside 443 and 5003.",
"exposure": {
"verdict": "never",
"note": "Direct SQL access to a live database with credentials on the wire; keep it inside the network or behind a VPN rather than opening 2399 to the internet."
},
"checkCommand": "nc -vz TARGET 2399",
"links": [
{
"title": "Claris — Ports used by FileMaker Server",
"url": "https://help.claris.com/en/server-installation-configuration-guide/content/ports-used-by-server.html",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 2399 (fmpro-fdal)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2399",
"kind": "iana"
}
],
"ianaName": "fmpro-fdal"
},
{
"port": 2401,
"protocol": "tcp",
"service": "CVS pserver",
"oneLiner": "CVS's password-authenticating server — version control from before SSH was assumed.",
"whatItIs": "The CVS manual documents 2401 as the default pserver port, historically wired up through inetd or xinetd running `cvs pserver`. A client sends the repository root, username, and password, and gets read/write access to the repository. The manual is blunt about the security: the password is only trivially scrambled, offering no protection against anyone who can sniff packets, and it recommends a separate CVS password file so people do not expose their real account passwords. Today it turns up on legacy source servers and anonymous read-only mirrors of old projects.",
"exposure": {
"verdict": "never",
"note": "The CVS manual itself says the scrambling stops inadvertent compromise and nothing more; authenticated pserver on a public IP hands over credentials. Anonymous read-only mirrors are the only defensible case, and even then prefer ssh transport."
},
"checkCommand": "nc -v TARGET 2401",
"links": [
{
"title": "CVS Manual — Password authentication server (port 2401, inetd/xinetd setup)",
"url": "https://www.gnu.org/software/trans-coord/manual/cvs/html_node/Password-authentication-server.html",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 2401 (cvspserver)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2401",
"kind": "iana"
}
],
"ianaName": "cvspserver"
},
{
"port": 2492,
"protocol": "tcp",
"service": "Groove",
"oneLiner": "Registered for Groove, the peer-to-peer collaboration product Microsoft bought and eventually retired.",
"whatItIs": "IANA registers 2492 as groove, assigned to Ray Ozzie — Groove Networks' peer-to-peer workspace client, which Microsoft acquired and shipped as Office Groove 2007, renamed SharePoint Workspace 2010, and then dropped from Office 2013 in favour of OneDrive for Business. Groove clients used 2492 for direct peer traffic when they could reach each other, falling back to HTTP/HTTPS otherwise. Nothing currently supported listens here, so a live 2492 is either a very old Office install or an unrelated program on a free port.",
"exposure": {
"verdict": "careful",
"note": "The product is out of support and receives no fixes; identify what is actually listening and retire it rather than firewalling around it."
},
"checkCommand": "sudo lsof -nP -iTCP:2492 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 2492 (groove)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2492",
"kind": "iana"
}
],
"ianaName": "groove"
},
{
"port": 2500,
"protocol": "tcp",
"service": "Resource Tracking system server",
"oneLiner": "Registered as the server half of a \"resource tracking system\" with no public specification.",
"whatItIs": "IANA registers 2500 as rtsserv, \"Resource Tracking system server\", paired with rtsclient on 2501. No specification accompanies the registration and no widely deployed product defaults here, so the name identifies almost nothing in practice. Being a round number just above the well-known range, 2500 is also a popular arbitrary choice for ad-hoc services, which makes process identification the only reliable answer.",
"exposure": {
"verdict": "careful",
"note": "Whatever is here was almost certainly chosen by a person, not by a protocol; find the process and judge it on its own authentication and encryption."
},
"checkCommand": "sudo lsof -nP -iTCP:2500 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 2500 (rtsserv)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2500",
"kind": "iana"
}
],
"ianaName": "rtsserv"
},
{
"port": 2522,
"protocol": "tcp",
"service": "WinDb",
"oneLiner": "Registered as \"WinDb\" and otherwise undocumented.",
"whatItIs": "IANA registers 2522 as windb, \"WinDb\". The registration carries no protocol description and no reference document, and there is no commonly deployed software that binds this port by default. It is a name in the registry, not a protocol you will identify from a scan — look at the listening process instead.",
"exposure": {
"verdict": "careful",
"note": "Unknown service; the registration tells you nothing about whether it authenticates or encrypts, so identify it before allowing any traffic to it."
},
"checkCommand": "sudo lsof -nP -iTCP:2522 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 2522 (windb)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2522",
"kind": "iana"
}
],
"ianaName": "windb"
},
{
"port": 2525,
"protocol": "tcp",
"service": "SMTP submission (unofficial alternate)",
"oneLiner": "The unofficial fallback SMTP submission port used when ISPs block 25, 465 and 587.",
"whatItIs": "IANA registers 2525 as ms-v-worlds (\"MS V-Worlds\"), an individual's assignment that nothing uses — the \"ms-\" prefix is part of the service name, not an attribution to Microsoft. What actually listens here is mail submission: email service providers such as SendGrid, Mailgun and Mailjet offer 2525 as a mirror of their port 587 submission endpoint, with the same STARTTLS and SMTP AUTH requirements, because consumer ISPs and cloud providers frequently block the standard ports outbound. It is a convention, not a standard — the IETF's message submission spec (RFC 6409) defines 587, and no RFC blesses 2525.",
"exposure": {
"verdict": "careful",
"note": "Acceptable only as a real submission service that requires STARTTLS and authentication, exactly like 587. Because nothing standardises 2525, verify the server actually enforces both rather than assuming it mirrors 587's policy — and never run an open relay here."
},
"checkCommand": "openssl s_client -starttls smtp -connect TARGET:2525",
"links": [
{
"title": "RFC 6409 — Message Submission for Mail (defines port 587)",
"url": "https://www.rfc-editor.org/rfc/rfc6409.html",
"kind": "spec"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 2525 (ms-v-worlds)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2525",
"kind": "iana"
}
],
"ianaName": "ms-v-worlds"
},
{
"port": 2601,
"protocol": "tcp",
"service": "zebra VTY (FRR / Quagga)",
"oneLiner": "The zebra routing manager's telnet config shell on a Linux router running FRR or Quagga.",
"whatItIs": "FRRouting (and Quagga and GNU Zebra before it) gives each daemon its own VTY — an IOS-like interactive shell reachable over telnet — and zebra's default is 2601, which FRR's setup guide tells you to add to /etc/services. zebra is the daemon that owns the kernel routing table and RIB for the other protocol daemons, so its VTY can inspect and change routing. Most operators use `vtysh` over the local Unix sockets instead, and modern FRR packages bind the VTY to localhost or disable the TCP port. Note that IANA registers 2601 as discp-client, unrelated to zebra.",
"exposure": {
"verdict": "never",
"note": "An unencrypted telnet shell into the daemon that controls the routing table, protected at best by a VTY password. Bind it to localhost or disable the TCP VTY and use vtysh."
},
"checkCommand": "nc -v 127.0.0.1 2601",
"links": [
{
"title": "FRRouting — Basic Setup (zebra 2601/tcp, ripd 2602/tcp, vtysh)",
"url": "https://docs.frrouting.org/en/latest/setup.html",
"kind": "official-docs"
},
{
"title": "FRRouting/frr",
"url": "https://github.com/FRRouting/frr",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 2601 (discp-client)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2601",
"kind": "iana"
}
],
"ianaName": "discp-client"
},
{
"port": 2602,
"protocol": "tcp",
"service": "ripd VTY (FRR / Quagga)",
"oneLiner": "The RIP daemon's telnet config shell, one number up from zebra's.",
"whatItIs": "FRR assigns each routing daemon a VTY port counting up from 2601: zebra 2601, ripd 2602, ripngd 2603, ospfd 2604, bgpd 2605, and so on. So 2602 open means ripd — the RIP/RIPv2 implementation — is running with its TCP VTY enabled, and finding it usually means its siblings are listening too. As with zebra, the supported way in is `vtysh` over local sockets, and the TCP VTY can be bound to localhost or disabled by passing port 0. IANA's registration for 2602 is discp-server, which has nothing to do with routing.",
"exposure": {
"verdict": "never",
"note": "Cleartext telnet into a routing daemon's configuration shell; anyone who reaches it and knows the VTY password can alter what the router advertises."
},
"checkCommand": "nc -v 127.0.0.1 2602",
"links": [
{
"title": "FRRouting — Basic Setup (zebra 2601/tcp, ripd 2602/tcp, vtysh)",
"url": "https://docs.frrouting.org/en/latest/setup.html",
"kind": "official-docs"
},
{
"title": "FRRouting/frr",
"url": "https://github.com/FRRouting/frr",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 2602 (discp-server)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2602",
"kind": "iana"
}
],
"ianaName": "discp-server"
},
{
"port": 2604,
"protocol": "tcp",
"service": "FRRouting/Quagga ospfd vty",
"oneLiner": "The OSPF daemon's command line on a Linux router — one vty port per routing daemon.",
"whatItIs": "FRRouting (and Quagga before it) gives every routing daemon its own telnet-style vty port: zebra 2601, ripd 2602, ripngd 2603, ospfd 2604, bgpd 2605. Connecting to 2604 lands on ospfd's password prompt and, past it, the same CLI that vtysh drives locally. You meet it on Linux routers and on appliances built on FRR — Cumulus Linux, SONiC, VyOS, OPNsense/pfSense with the FRR package. IANA registers 2604 to \"NSC CCS\", which has nothing to do with routing.",
"exposure": {
"verdict": "never",
"note": "A cleartext telnet admin CLI for a routing daemon, protected only by a config-file password — bind it to 127.0.0.1 and reach it through vtysh or SSH."
},
"checkCommand": "nc -v -w 3 TARGET 2604",
"links": [
{
"title": "FRRouting — lib/libfrr.h (OSPF_VTY_PORT 2604 and the other daemon vty ports)",
"url": "https://github.com/FRRouting/frr/blob/master/lib/libfrr.h",
"kind": "github"
},
{
"title": "FRRouting docs — Basic setup and vtysh",
"url": "https://docs.frrouting.org/en/latest/setup.html",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 2604 (nsc-ccs)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2604",
"kind": "iana"
}
],
"ianaName": "nsc-ccs"
},
{
"port": 2605,
"protocol": "tcp",
"service": "FRRouting/Quagga bgpd vty",
"oneLiner": "The BGP daemon's command line — the next port up from ospfd on an FRR router.",
"whatItIs": "2605 is BGP_VTY_PORT in FRRouting: bgpd's own telnet-style management CLI, separate from every other daemon's. Anyone who gets past its password can read the full BGP table and change neighbors, policy, and redistribution on a live router. It shows up on Linux route servers and reflectors, and on FRR-based network appliances. IANA has 2605 registered as \"NSC POSA\", unrelated to routing.",
"exposure": {
"verdict": "never",
"note": "This is the routing control plane over cleartext telnet — internet exposure hands over the router's BGP configuration."
},
"checkCommand": "nc -v -w 3 TARGET 2605",
"links": [
{
"title": "FRRouting — lib/libfrr.h (BGP_VTY_PORT 2605)",
"url": "https://github.com/FRRouting/frr/blob/master/lib/libfrr.h",
"kind": "github"
},
{
"title": "FRRouting docs — BGP",
"url": "https://docs.frrouting.org/en/latest/bgp.html",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 2605 (nsc-posa)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2605",
"kind": "iana"
}
],
"ianaName": "nsc-posa"
},
{
"port": 2607,
"protocol": "tcp",
"service": "FRRouting ospfd OSPF API",
"oneLiner": "Not a vty — this is ospfd's OSPF API, the socket that lets an external program inject LSAs.",
"whatItIs": "FRRouting defines 2607 as OSPF_API_SYNC_PORT: the API server ospfd opens when started with -a/--apiserver, which ospfclient and traffic-engineering or segment-routing controllers use to originate and read opaque LSAs. It is off unless someone enabled it, and it sits one port above the ospf6d vty (2606) rather than belonging to the vty series. IANA registers 2607 as \"Dell Connection\", which is a separate and rarely seen assignment.",
"exposure": {
"verdict": "never",
"note": "The API can originate LSAs into the OSPF domain with no authentication of its own — FRR's own guidance is to bind it to 127.0.0.1 with --apiserver_addr."
},
"checkCommand": "nc -vz -w 3 TARGET 2607",
"links": [
{
"title": "FRRouting — lib/libfrr.h (OSPF_API_SYNC_PORT 2607)",
"url": "https://github.com/FRRouting/frr/blob/master/lib/libfrr.h",
"kind": "github"
},
{
"title": "FRRouting docs — ospfd (-a/--apiserver, --apiserver_addr)",
"url": "https://docs.frrouting.org/en/latest/ospfd.html",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 2607 (connection)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2607",
"kind": "iana"
}
],
"ianaName": "connection (Dell Connection)"
},
{
"port": 2608,
"protocol": "tcp",
"service": "FRRouting isisd vty",
"oneLiner": "The IS-IS daemon's command line on an FRR router.",
"whatItIs": "FRRouting defines 2608 as ISISD_VTY_PORT, the telnet-style CLI for isisd, in the same series as ospfd (2604) and bgpd (2605). A listener here means a box is running IS-IS under FRR, which in practice means a data-center fabric or a service-provider core built on Linux routing. IANA registers 2608 to \"Wag Service\", an assignment you will not meet in the wild.",
"exposure": {
"verdict": "never",
"note": "Same problem as every FRR vty port: cleartext telnet into a routing daemon's configuration — keep it on loopback."
},
"checkCommand": "nc -v -w 3 TARGET 2608",
"links": [
{
"title": "FRRouting — lib/libfrr.h (ISISD_VTY_PORT 2608)",
"url": "https://github.com/FRRouting/frr/blob/master/lib/libfrr.h",
"kind": "github"
},
{
"title": "FRRouting docs — isisd",
"url": "https://docs.frrouting.org/en/latest/isisd.html",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 2608 (wag-service)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2608",
"kind": "iana"
}
],
"ianaName": "wag-service"
},
{
"port": 2638,
"protocol": "both",
"service": "SAP SQL Anywhere (Sybase) database server",
"oneLiner": "A SQL Anywhere database engine — the embedded Sybase database inside a lot of shipped software.",
"whatItIs": "SQL Anywhere's database server binds TCP 2638 by default and also listens on UDP 2638 so clients can find servers by broadcast, including on other subnets. If the port is taken the engine picks another, starting at 49152, so 2638 is the common but not guaranteed case. It usually appears not because someone chose Sybase but because a vendor embedded it — backup products, point-of-sale, MDM and monitoring suites all ship SQL Anywhere underneath.",
"exposure": {
"verdict": "never",
"note": "A database engine reachable from the internet is a credential-guessing target, and the UDP side answers discovery probes that tell a scanner the server and database names."
},
"checkCommand": "nc -vz -w 3 TARGET 2638",
"links": [
{
"title": "SQL Anywhere docs — ServerPort (PORT) protocol option (default 2638)",
"url": "https://infocenter.sybase.com/help/topic/com.sybase.help.sqlanywhere.12.0.1/dbadmin/serverport-network-conparm.html",
"kind": "official-docs"
},
{
"title": "SAP SQL Anywhere 17 — Server Database Administration guide",
"url": "https://help.sap.com/doc/68c565f3ab4f480ea42a59fa2ebd444e/17.0.01/en-US/SQL-Anywhere-Server-Database-Administration-en.pdf",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 2638 (sybaseanywhere)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2638",
"kind": "iana"
}
],
"ianaName": "sybaseanywhere"
},
{
"port": 2701,
"protocol": "tcp",
"service": "SCCM/SMS Remote Control",
"oneLiner": "Microsoft Configuration Manager remote control — an admin can take over this desktop.",
"whatItIs": "Microsoft's own port table for Configuration Manager lists TCP 2701 for \"Remote Control (control)\" from the ConfigMgr console to a client. The listener is CmRcService.exe, the remote control agent installed with the ConfigMgr (formerly SMS) client, and it authenticates the admin with Kerberos, falling back to NTLM. A 2701 on a scan is a reliable marker of a domain-joined, ConfigMgr-managed Windows endpoint.",
"exposure": {
"verdict": "never",
"note": "This is a screen-and-keyboard takeover channel for managed desktops; it belongs on an internal management network, never on a public interface."
},
"checkCommand": "nc -vz -w 3 TARGET 2701",
"links": [
{
"title": "Microsoft Learn — Ports used for connections in Configuration Manager (console → client, Remote Control 2701)",
"url": "https://learn.microsoft.com/en-us/intune/configmgr/core/plan-design/hierarchy/ports",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 2701 (sms-rcinfo)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2701",
"kind": "iana"
}
],
"ianaName": "sms-rcinfo"
},
{
"port": 2702,
"protocol": "tcp",
"service": "SMS/SCCM Remote Control transfer",
"oneLiner": "The companion data channel to 2701, registered by Microsoft as SMS XFER.",
"whatItIs": "IANA holds 2702 for Microsoft as \"SMS XFER\", the transfer side of SMS/SCCM remote tools that sits next to the control channel on 2701. Firewall guidance for remote control has long paired the two, though the current Configuration Manager port table lists only 2701 for remote control. In practice you see 2702 alongside 2701 on ConfigMgr-managed Windows clients and essentially nowhere else.",
"exposure": {
"verdict": "never",
"note": "It only means anything next to 2701, and it inherits the same rule — remote control of managed desktops stays on the internal management network."
},
"checkCommand": "nc -vz -w 3 TARGET 2702",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 2702 (sms-xfer)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2702",
"kind": "iana"
},
{
"title": "Microsoft Learn — Ports used for connections in Configuration Manager",
"url": "https://learn.microsoft.com/en-us/intune/configmgr/core/plan-design/hierarchy/ports",
"kind": "official-docs"
}
],
"ianaName": "sms-xfer"
},
{
"port": 2717,
"protocol": "both",
"service": "pn-requester (registered)",
"oneLiner": "Registered to IANA as PN REQUESTER, with no public protocol documentation behind the name.",
"whatItIs": "IANA lists 2717 for both TCP and UDP as pn-requester, \"PN REQUESTER\", with 2718 registered as pn-requester2. No specification, vendor documentation, or open implementation of the protocol is publicly available. Nmap carries the registered name and gives 2717 an unusually high open-frequency for an obscure port (about 0.33% of scanned hosts), which means something answers there in the wild — but nothing public identifies what. Treat a listener on 2717 as unidentified software until you fingerprint it locally.",
"exposure": {
"verdict": "careful",
"note": "An unidentified listener is the problem, not the port — find the process with lsof or ss before deciding anything about exposing it."
},
"checkCommand": "sudo lsof -nP -iTCP:2717 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 2717 (pn-requester)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2717",
"kind": "iana"
},
{
"title": "nmap/nmap — nmap-services (open-frequency data per port)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
],
"ianaName": "pn-requester"
},
{
"port": 2718,
"protocol": "both",
"service": "pn-requester2 (registered)",
"oneLiner": "The second half of the pn-requester registration, and just as undocumented as the first.",
"whatItIs": "IANA registers 2718 as pn-requester2, \"PN REQUESTER 2\", the companion to 2717. As with 2717 there is no public specification or named implementation; unlike 2717, it is also rare in scan data. If you find it listening, the only honest identification is the local process behind it.",
"exposure": {
"verdict": "careful",
"note": "Nothing well-known should be here, so identify the listener before you decide it is safe to reach from anywhere."
},
"checkCommand": "sudo lsof -nP -iTCP:2718 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 2718 (pn-requester2)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2718",
"kind": "iana"
}
],
"ianaName": "pn-requester2"
},
{
"port": 2725,
"protocol": "tcp",
"service": "Microsoft OLAP (msolap-ptp2)",
"oneLiner": "The port SQL Server 2000 Analysis Services clients connected on, registered by Microsoft as MSOLAP PTP2.",
"whatItIs": "2725 is registered to Microsoft as msolap-ptp2 and is the OLAP client port from the SQL Server 2000 Analysis Services era — Microsoft's Commerce Server documentation tells administrators to open TCP 2725 so Office Web Components can reach the Analysis Services server directly, even when reports are fetched over HTTP. Analysis Services from SQL Server 2005 onward moved to TCP 2383 for the default instance, so 2725 today points at something very old or at a vendor product that kept the legacy setting.",
"exposure": {
"verdict": "never",
"note": "It is a database query port from a long-unsupported product generation — anything still listening here is unpatched by definition and belongs on an internal segment."
},
"checkCommand": "nc -vz -w 3 TARGET 2725",
"links": [
{
"title": "Microsoft Learn — Accessing the Analysis Server over HTTPS (\"you must also open TCP port 2725\")",
"url": "https://learn.microsoft.com/en-us/previous-versions/commerce-server/ee825077(v=cs.20)",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 2725 (msolap-ptp2)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2725",
"kind": "iana"
}
],
"ianaName": "msolap-ptp2"
},
{
"port": 2809,
"protocol": "tcp",
"service": "CORBA corbaloc / IIOP bootstrap",
"oneLiner": "A CORBA bootstrap agent — in practice, usually an IBM WebSphere Application Server.",
"whatItIs": "2809 is the default port for a corbaloc: URL, the CORBA Interoperable Naming Service address a client uses to resolve an initial object reference over IIOP without a full naming lookup. Java EE servers built on IIOP inherit it: WebSphere's default JNDI provider URL is literally corbaloc:iiop:localhost:2809, and the port is the WebSphere bootstrap/RMI-IIOP endpoint. On a scan it says \"Java application server\", and the naming service on it will happily enumerate bound objects to an unauthenticated client.",
"exposure": {
"verdict": "never",
"note": "The bootstrap and naming service usually answer without authentication and it is a Java deserialization path into the application server — keep it behind the perimeter."
},
"checkCommand": "nmap -Pn -p 2809 --script giop-info TARGET",
"links": [
{
"title": "omniORB manual — Interoperable Naming Service (corbaloc, default port 2809)",
"url": "https://omniorb.sourceforge.io/omni43/omniORB/omniORB008.html",
"kind": "official-docs"
},
{
"title": "IBM Documentation — Getting the default initial context (corbaloc:iiop:localhost:2809)",
"url": "https://ibm.com/support/knowledgecenter/SSEQTP_8.5.5/com.ibm.websphere.base.doc/ae/rnam_example_prop1.html",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 2809 (corbaloc)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2809",
"kind": "iana"
}
],
"ianaName": "corbaloc"
},
{
"port": 2811,
"protocol": "tcp",
"service": "GridFTP (GSI FTP)",
"oneLiner": "A GridFTP server's control channel — bulk research data transfer with X.509 authentication.",
"whatItIs": "GridFTP extends FTP with GSI (X.509 proxy certificate) authentication, parallel streams, and third-party transfers, and its server listens on TCP 2811 for the control channel while data moves over a separately configured high port range. It came from the Globus Toolkit, now maintained as the Grid Community Toolkit, and it is the transfer backend behind Globus endpoints at national labs, HPC centres, and university research storage. Commands look like FTP; the credential exchange does not.",
"exposure": {
"verdict": "careful",
"note": "Internet-facing is the normal deployment — the transfers are cross-site by design and authenticated with certificates — but the data-channel port range must be opened deliberately and the server kept patched."
},
"checkCommand": "nc -w 3 TARGET 2811 | head -1",
"links": [
{
"title": "Grid Community Toolkit — GridFTP System Administrator's Guide (control channel on 2811)",
"url": "https://gridcf.org/gct-docs/latest/gridftp/admin/index.html",
"kind": "official-docs"
},
{
"title": "gridcf/gct — Grid Community Toolkit source",
"url": "https://github.com/gridcf/gct",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 2811 (gsiftp)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2811",
"kind": "iana"
}
],
"ianaName": "gsiftp"
},
{
"port": 2869,
"protocol": "tcp",
"service": "Windows UPnP / SSDP event notification (ICSLAP)",
"oneLiner": "A Windows box with UPnP on — the HTTP endpoint that receives SSDP event notifications.",
"whatItIs": "Microsoft's port reference lists TCP 2869 twice: UPnP Device Host, and SSDP event notification for the SSDP Discovery service (which used TCP 5000 before Windows XP SP2). It is an HTTP listener registered in the kernel HTTP stack — an unmatched request typically answers with a Microsoft-HTTPAPI/2.0 header — carrying UPnP eventing and device descriptions on the local network. It pairs with UDP 1900, which does the discovery multicast. IANA's registered name for 2869 is icslap, from Internet Connection Sharing.",
"exposure": {
"verdict": "never",
"note": "UPnP is a link-local trust model with no authentication; on a public interface it advertises the host and exposes the UPnP stack, which has a history of remotely reachable bugs. Stop SSDP Discovery if you do not need it."
},
"checkCommand": "curl -si --max-time 5 http://TARGET:2869/ | head -5",
"links": [
{
"title": "Microsoft Learn — Service overview and network port requirements (UPnP Device Host / SSDP event notification, TCP 2869)",
"url": "https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/service-overview-and-network-port-requirements",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 2869 (icslap)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2869",
"kind": "iana"
}
],
"ianaName": "icslap"
},
{
"port": 2875,
"protocol": "both",
"service": "dxmessagebase2 (registered)",
"oneLiner": "Registered as the DX Message Base Transport Protocol, and almost never seen.",
"whatItIs": "IANA registers 2874 and 2875 to one person as dxmessagebase1 and dxmessagebase2, \"DX Message Base Transport Protocol\" — a message-base (BBS-style message store) transport. There is no public specification and no widely distributed implementation, and scan datasets show essentially nothing answering here. If 2875 is open on a host you run, the listener is some local application that picked a free port, not this registration.",
"exposure": {
"verdict": "careful",
"note": "Nothing standard lives here, so the honest step is to identify the process behind the port before treating it as expected."
},
"checkCommand": "sudo lsof -nP -iTCP:2875 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 2875 (dxmessagebase2)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2875",
"kind": "iana"
}
],
"ianaName": "dxmessagebase2"
},
{
"port": 2909,
"protocol": "both",
"service": "funk-dialout (registered)",
"oneLiner": "An IANA registration from Funk Software, with no public protocol behind the name.",
"whatItIs": "2909 is registered as funk-dialout, \"Funk Dialout\", by Funk Software — the remote-access and RADIUS vendor behind Steel-Belted RADIUS, acquired by Juniper Networks in 2005. No public specification describes the protocol, and it does not appear in modern scan data in any meaningful volume. It is a legacy registration from the dial-up era rather than something you should expect to meet.",
"exposure": {
"verdict": "careful",
"note": "Nothing current is expected on 2909, so a listener means unidentified software — fingerprint it locally rather than assuming the registration explains it."
},
"checkCommand": "sudo lsof -nP -iTCP:2909 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 2909 (funk-dialout)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2909",
"kind": "iana"
}
],
"ianaName": "funk-dialout"
},
{
"port": 2967,
"protocol": "tcp",
"service": "Symantec AntiVirus / SSC agent",
"oneLiner": "Legacy Symantec AntiVirus management agent — the port the \"Big Yellow\" worm hunted.",
"whatItIs": "2967 is registered as ssc-agent and is the port Symantec AntiVirus Corporate Edition and Symantec Client Security used for management communication with rtvscan.exe, the real-time scanner service. In 2006 the Sagevo (\"Big Yellow\") worm scanned the internet for 2967 and installed a bot on unpatched clients by exploiting CVE-2006-2630, a stack-based buffer overflow in Symantec AntiVirus 10.1 and Client Security 3.1; Metasploit's module for it targets exactly this port. Scanning noise on 2967 has never fully died down, and it remains one of the more commonly probed non-obvious ports.",
"exposure": {
"verdict": "never",
"note": "An endpoint-security management agent running with system privileges, with a wormed remote code execution in its history — internal management network only, on supported software."
},
"checkCommand": "nc -vz -w 3 TARGET 2967",
"links": [
{
"title": "CVE-2006-2630 — Symantec AntiVirus / Client Security remote stack overflow",
"url": "https://www.cve.org/CVERecord?id=CVE-2006-2630",
"kind": "official-docs"
},
{
"title": "rapid7/metasploit-framework — symantec_rtvscan exploit module (port 2967)",
"url": "https://github.com/rapid7/metasploit-framework/blob/master/modules/exploits/windows/antivirus/symantec_rtvscan.rb",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 2967 (ssc-agent)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2967",
"kind": "iana"
}
],
"ianaName": "ssc-agent"
},
{
"port": 2998,
"protocol": "both",
"service": "ISS RealSecure",
"oneLiner": "Registered to Internet Security Systems for RealSecure, a discontinued intrusion detection product.",
"whatItIs": "2998 is registered as realsecure, assigned to Internet Security Systems for RealSecure — the network IDS line that ISS sold through the late 1990s and 2000s and that IBM absorbed after acquiring ISS in 2006. Nmap still labels 2998 as the RealSecure remote console admin port. The product line is long gone, so a listener today is far more likely to be unrelated software on a free port than an IDS console.",
"exposure": {
"verdict": "never",
"note": "If it really is a security-appliance console port, that is an admin plane for the sensor and has no business being reachable from outside the management network."
},
"checkCommand": "nc -vz -w 3 TARGET 2998",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 2998 (realsecure)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=2998",
"kind": "iana"
},
{
"title": "nmap/nmap — nmap-services (2998 iss-realsec)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
],
"ianaName": "realsecure"
},
{
"port": 3000,
"protocol": "tcp",
"service": "Node/Express dev server, Grafana",
"oneLiner": "The default port for Node web frameworks in development, and the default port Grafana serves on in production.",
"whatItIs": "Port 3000 is the convention baked into Express's own hello-world example and inherited by most Node-based frameworks and their dev servers. Grafana also binds 3000 by default (http_port), which is the usual reason a 3000 shows up on a server that nobody is developing on. IANA has 3000 registered as hbci and remoteware-cl, neither of which you will meet in practice. On a scan it means either a developer machine or a forgotten dashboard.",
"exposure": {
"verdict": "careful",
"note": "Fine behind a reverse proxy for a real app like Grafana, but a framework dev server on 3000 should never face the internet."
},
"checkCommand": "sudo lsof -nP -iTCP:3000 -sTCP:LISTEN",
"links": [
{
"title": "Express — Hello world example (listens on 3000)",
"url": "https://expressjs.com/en/starter/hello-world.html",
"kind": "official-docs"
},
{
"title": "Grafana — Configure Grafana (http_port defaults to 3000)",
"url": "https://grafana.com/docs/grafana/latest/setup-grafana/configure-grafana/",
"kind": "official-docs"
},
{
"title": "grafana/grafana on GitHub",
"url": "https://github.com/grafana/grafana",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 3000",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=3000",
"kind": "iana"
}
],
"ianaName": "hbci / remoteware-cl"
},
{
"port": 3001,
"protocol": "tcp",
"service": "Second dev server / OrigoDB (registered)",
"oneLiner": "Usually the second app on a developer's machine, after something already took 3000.",
"whatItIs": "3001 has no meaningful standard behind it: it is what a Node, Rails, or Vite process binds when 3000 is occupied, so a full-stack repo commonly runs an API on 3000 and a client on 3001 or the reverse. IANA registers TCP 3001 to OrigoDB's native interface (the UDP side is Reserved), and older scanner databases label it Nessus, from a daemon port that Nessus has not used in decades. On a scan it is nearly always a development or internal HTTP service.",
"exposure": {
"verdict": "careful",
"note": "A production app behind a reverse proxy is fine; a framework dev server on 3001 has debug endpoints and verbose errors and should never face the internet."
},
"checkCommand": "curl -sI --max-time 5 http://TARGET:3001/",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 3001 (origo-native)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=3001",
"kind": "iana"
},
{
"title": "DevrexLabs/OrigoDB — the registrant's project",
"url": "https://github.com/DevrexLabs/OrigoDB",
"kind": "github"
}
],
"ianaName": "origo-native"
},
{
"port": 3003,
"protocol": "both",
"service": "cgms (registered)",
"oneLiner": "Registered to IANA as CGMS, with nothing public describing it.",
"whatItIs": "IANA lists 3003 for TCP and UDP as cgms, \"CGMS\", with an individual assignee and no reference document. No specification, vendor page, or open implementation is publicly identifiable, and the port is rare in scan data. In practice a listener on 3003 is an application that took a free port near 3000, not the registered service.",
"exposure": {
"verdict": "careful",
"note": "Identify the actual process before deciding anything — the registration tells you nothing about what is listening."
},
"checkCommand": "sudo lsof -nP -iTCP:3003 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 3003 (cgms)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=3003",
"kind": "iana"
}
],
"ianaName": "cgms"
},
{
"port": 3005,
"protocol": "both",
"service": "Genius License Manager (registered) / deslogin",
"oneLiner": "Registered to a license manager; still labelled deslogin, a 1990s DES-encrypted remote login tool.",
"whatItIs": "IANA registers 3005 as geniuslm, \"Genius License Manager\". Nmap and older service tables instead call it deslogin, an early encrypted-symmetric replacement for telnet/rlogin from before SSH existed, which is the label most scanners will print. Neither is common today; floating license daemons are the more plausible modern occupant of the 3000-3010 range on a workstation running commercial engineering software.",
"exposure": {
"verdict": "careful",
"note": "If it is a license manager, it should be reachable only from the LAN that needs licenses; if it really is a pre-SSH remote login daemon, treat it as never and remove it."
},
"checkCommand": "nc -vz -w 3 TARGET 3005",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 3005 (geniuslm)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=3005",
"kind": "iana"
},
{
"title": "nmap/nmap — nmap-services (3005 deslogin)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
],
"ianaName": "geniuslm"
},
{
"port": 3006,
"protocol": "both",
"service": "Instant Internet Admin (registered) / deslogind",
"oneLiner": "The admin port of a 1990s Instant Internet appliance, and nmap's deslogind label.",
"whatItIs": "IANA registers 3006 as ii-admin, \"Instant Internet Admin\" — the management port of the Instant Internet branch-office internet appliance line (Performance Technologies, later Bay Networks/Nortel). Nmap labels it deslogind, the daemon side of the deslogin tool sitting one port above 3005. Both are historical; the appliances are decades out of service and nothing current is expected here.",
"exposure": {
"verdict": "never",
"note": "Both candidate identities are unauthenticated-era admin planes on unsupported software — anything genuinely serving them should be off the network, not firewalled."
},
"checkCommand": "nc -vz -w 3 TARGET 3006",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 3006 (ii-admin)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=3006",
"kind": "iana"
},
{
"title": "nmap/nmap — nmap-services (3006 deslogind)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
],
"ianaName": "ii-admin"
},
{
"port": 3011,
"protocol": "both",
"service": "trusted-web (registered)",
"oneLiner": "Registered as Trusted Web, one of a pair with 3012 (Trusted Web Client), and rarely seen.",
"whatItIs": "IANA registers 3011 as trusted-web and 3012 as twsdss, \"Trusted Web Client\" — a server/client pair from a 1990s commercial product of that name. No public specification survives and there is no maintained implementation, so the names outlive the software. A listener on 3011 today is almost certainly an unrelated application that grabbed a free port.",
"exposure": {
"verdict": "careful",
"note": "\"Trusted\" is a product name, not a property of the port — find out what is actually listening before treating it as safe."
},
"checkCommand": "sudo lsof -nP -iTCP:3011 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 3011 (trusted-web)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=3011",
"kind": "iana"
}
],
"ianaName": "trusted-web"
},
{
"port": 3017,
"protocol": "both",
"service": "event-listener (registered)",
"oneLiner": "Registered to IANA as Event Listener, with no public protocol behind the name.",
"whatItIs": "IANA holds 3017 as event-listener — registered originally as \"event_listener\" and later given the well-formed name event-listener, so both appear in service tables. There is no reference document, vendor page, or known open implementation, and the port is uncommon in scan data. The generic name attracts confusion: many unrelated applications describe their own callback socket as an event listener without any connection to this assignment.",
"exposure": {
"verdict": "careful",
"note": "The name says nothing about what is running — identify the process, because an event-callback socket that accepts arbitrary input is worth reviewing before exposure."
},
"checkCommand": "sudo lsof -nP -iTCP:3017 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 3017 (event-listener)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=3017",
"kind": "iana"
}
],
"ianaName": "event-listener"
},
{
"port": 3030,
"protocol": "tcp",
"service": "arepa-cas (in practice: ad-hoc dev server)",
"oneLiner": "Registered to Arepa Cas; in practice a spare development-server port next door to 3000.",
"whatItIs": "IANA registers 3030 as `arepa-cas`, Arepa Cas, registered by Stuart Schaefer, with no RFC, no public specification and no implementation anyone meets today. What actually listens on 3030 is a local development server — a Node, Rails or similar app started on 3030 because 3000 was already taken — so the port carries no protocol guarantee at all. Scanners will still label it `arepa-cas` from /etc/services. Identify whatever is there by its banner or an HTTP request, not by the registered name.",
"exposure": {
"verdict": "careful",
"note": "Nothing standard runs here, so an open 3030 is an unidentified service — usually an unhardened dev server that was never meant to leave localhost."
},
"checkCommand": "curl -sS -D - -o /dev/null http://TARGET:3030/",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 3031,
"protocol": "both",
"service": "Remote AppleEvents (eppc)",
"oneLiner": "macOS Program Linking — remote AppleEvents, meaning remote AppleScript execution.",
"whatItIs": "Port 3031 is IANA-registered as `eppc`, Remote AppleEvents/PPC Toolbox, and macOS still uses it for exactly that: when \"Remote Apple Events\" is enabled in Sharing settings, the Mac accepts AppleEvents from other machines and runs them as an authenticated local user. Apple lists it in its own port reference as TCP and UDP 3031. It is off by default and rare in the wild, so an open 3031 means somebody deliberately turned Program Linking on. The practical effect is scripted remote control of applications on that Mac.",
"exposure": {
"verdict": "never",
"note": "This is remote code execution by design, gated only by an account password — keep it off, or confine it to a trusted LAN behind a VPN."
},
"checkCommand": "nc -vz TARGET 3031",
"links": [
{
"title": "Apple Support — TCP and UDP ports used by Apple software products",
"url": "https://support.apple.com/en-us/103229",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 3052,
"protocol": "both",
"service": "APC PowerChute (apc-3052)",
"oneLiner": "APC's UPS shutdown channel — PowerChute Network Shutdown talking to a UPS Network Management Card.",
"whatItIs": "IANA registers 3052 as `apc-3052` to American Power Conversion, and APC/Schneider use it for PowerChute Network Shutdown: the UPS Network Management Card sends the agent a UDP packet on 3052 roughly every 25 seconds, and the loss of those packets is what triggers a graceful shutdown. Schneider's own port list for PCNS is TCP 80, 443, 3052 and 6547 plus UDP 3052. On a scan, 3052 means a server running the PowerChute agent or an APC management card, usually in a rack somewhere on a facilities network.",
"exposure": {
"verdict": "never",
"note": "It is a power-control signalling path — anything that can forge traffic to it is adjacent to shutting servers down. Keep UPS management and PowerChute agents on a management VLAN."
},
"checkCommand": "nc -vz TARGET 3052",
"links": [
{
"title": "Schneider Electric — What ports are utilized by PowerChute Network Shutdown and how are they secured?",
"url": "https://www.se.com/us/en/faqs/FA373363/",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 3071,
"protocol": "tcp",
"service": "xplat-replicate (NetApp)",
"oneLiner": "Reassigned in 2017 to NetApp's crossplatform replication protocol; older /etc/services files still call it ContinuStor.",
"whatItIs": "The current IANA registration for TCP 3071 is `xplat-replicate`, \"Crossplatform replication protocol\", held by NetApp since 2017-08-24; the UDP side is marked Reserved. Many systems still ship an older services file naming 3071 `csd-mgmt-port`, ContinuStor Manager Port, so scanner output and the registry disagree. There is no public protocol document for either name. In practice you see 3071 only around NetApp storage software, and otherwise not at all.",
"exposure": {
"verdict": "careful",
"note": "If it really is storage replication it belongs on a private replication network; if it is something else entirely, fingerprint it before you decide."
},
"checkCommand": "nc -vz TARGET 3071",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 3077,
"protocol": "tcp",
"service": "Orbix 2000 Locator SSL",
"oneLiner": "The SSL variant of the IONA Orbix 2000 CORBA locator daemon.",
"whatItIs": "IANA registers 3077 as `orbix-loc-ssl`, Orbix 2000 Locator SSL, the TLS-protected counterpart to the plaintext locator on 3075 (with configuration on 3076 and its SSL variant on 3078). Orbix is IONA's CORBA ORB, later a Micro Focus product, and the locator daemon is what CORBA clients ask to resolve object references to a running server. You meet it only inside long-lived enterprise middleware estates — telco, banking, insurance — and essentially nowhere else. An open 3077 says a CORBA infrastructure is still running here.",
"exposure": {
"verdict": "careful",
"note": "It is middleware plumbing, not a public service; keep it on the application network even though this variant is TLS-wrapped."
},
"checkCommand": "openssl s_client -connect TARGET:3077 -brief /dev/null | openssl x509 -noout -subject -issuer",
"links": [
{
"title": "IANA port registry — 4443 (pharos)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=4443",
"kind": "iana"
}
]
},
{
"port": 4444,
"protocol": "tcp",
"service": "krb524 (IANA) / Metasploit handler / I2P HTTP proxy / Galera SST",
"oneLiner": "The internet's favourite memorable port — Metasploit shells, I2P's local proxy, and Galera state transfers all land here.",
"whatItIs": "IANA's registration is krb524, the long-obsolete Kerberos 5-to-4 ticket translator. What matters now is convention. Metasploit payload handlers default to LPORT 4444, which made the number a signature for reverse shells and for the 2003 Blaster worm's backdoor. I2P routers run their HTTP proxy on 127.0.0.1:4444. MariaDB and Percona Galera clusters receive state snapshot transfers (SST) on 4444 by default, next to 4567 for replication. Identity depends entirely on the host: a database cluster member, an anonymity router, or something you did not install.",
"exposure": {
"verdict": "never",
"note": "None of the real users of 4444 want public exposure — the I2P proxy is localhost-only, Galera SST is intra-cluster, and an unexplained listener on 4444 on an internet-facing host should be treated as an incident, not a configuration question."
},
"checkCommand": "nc -vz -w 3 TARGET 4444",
"links": [
{
"title": "I2P FAQ — port 4444 is the router's HTTP proxy",
"url": "https://i2p.net/en/docs/overview/faq",
"kind": "official-docs"
},
{
"title": "MariaDB — Galera cluster address and ports (SST on 4444)",
"url": "https://mariadb.com/docs/galera-cluster/galera-management/configuration/galera-cluster-address",
"kind": "official-docs"
},
{
"title": "rapid7/metasploit-framework",
"url": "https://github.com/rapid7/metasploit-framework",
"kind": "github"
},
{
"title": "IANA port registry — 4444 (krb524)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=4444",
"kind": "iana"
}
]
},
{
"port": 4445,
"protocol": "tcp",
"service": "I2P HTTPS proxy (IANA: upnotifyp)",
"oneLiner": "The companion to 4444 — an I2P router's HTTPS proxy, meant for localhost only.",
"whatItIs": "IANA registers 4445 as UPNOTIFYP, which you will not encounter. In practice the port belongs to I2P: a router's HTTPS proxy tunnel listens on 4445 while the HTTP proxy uses 4444, and browsers are configured to point at both. Both are managed from the router console's i2ptunnel page and listen on the loopback interface by default. Seeing 4445 on a host almost always means an I2P router is running there.",
"exposure": {
"verdict": "never",
"note": "It is a local proxy tunnel — exposing it hands strangers a route through your I2P router and deanonymises nothing but you."
},
"checkCommand": "nc -vz -w 3 TARGET 4445",
"links": [
{
"title": "I2P FAQ — port 4445 is the router's HTTPS proxy",
"url": "https://i2p.net/en/docs/overview/faq",
"kind": "official-docs"
},
{
"title": "IANA port registry — 4445 (upnotifyp)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=4445",
"kind": "iana"
}
]
},
{
"port": 4446,
"protocol": "tcp",
"service": "N1-FWP (IANA registration)",
"oneLiner": "An old Sun N1 registration with no live protocol behind it; treat a listener here as unidentified.",
"whatItIs": "IANA lists 4446 as N1-FWP, a name from Sun Microsystems' N1 provisioning product line, with no reference document or current implementation. Nothing in common use binds 4446 by default and scan frequency is negligible. If it is open, the answer comes from fingerprinting the service, not from the registry.",
"exposure": {
"verdict": "careful",
"note": "No standard service to judge — identify what answers and apply that service's rules."
},
"checkCommand": "nc -vz -w 3 TARGET 4446",
"links": [
{
"title": "IANA port registry — 4446 (n1-fwp)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=4446",
"kind": "iana"
}
]
},
{
"port": 4449,
"protocol": "tcp",
"service": "PrivateWire (IANA registration)",
"oneLiner": "Registered to the PrivateWire VPN product of the 1990s; effectively extinct today.",
"whatItIs": "IANA carries 4449 as PrivateWire, registered by Uri Resnitzky for an early commercial encrypted-tunnel product. The software is long gone from the market and there is no public protocol specification. An open 4449 today is far more likely to be an in-house or bespoke service that took the number than an actual PrivateWire gateway.",
"exposure": {
"verdict": "careful",
"note": "The registration tells you nothing useful — fingerprint the listener before deciding whether it belongs on a public address."
},
"checkCommand": "nc -vz -w 3 TARGET 4449",
"links": [
{
"title": "IANA port registry — 4449 (privatewire)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=4449",
"kind": "iana"
}
]
},
{
"port": 4550,
"protocol": "tcp",
"service": "gds-adppiw-db (IANA registration)",
"oneLiner": "An obscure InterBase-related database registration; almost never seen in the wild.",
"whatItIs": "IANA registers 4550 as gds-adppiw-db, described as Perman I Interbase Server — a vendor-specific database listener from the InterBase family, registered by Leo Lesage. Standard InterBase and Firebird use 3050, not 4550, and no current product documents this port. Treat an open 4550 as an unidentified database or application listener until proven otherwise.",
"exposure": {
"verdict": "never",
"note": "Everything the registration points at is a database server, and database ports do not belong on the public internet regardless of vendor."
},
"checkCommand": "nc -vz -w 3 TARGET 4550",
"links": [
{
"title": "IANA port registry — 4550 (gds-adppiw-db)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=4550",
"kind": "iana"
}
]
},
{
"port": 4567,
"protocol": "tcp",
"service": "Sinatra dev server / Galera replication (IANA: tram)",
"oneLiner": "Two very different things: a Ruby Sinatra app in development, or a Galera cluster's replication channel.",
"whatItIs": "IANA's name for 4567 is TRAM, which you will not meet. In practice it is one of two things. Ruby's Sinatra framework starts its built-in server on 4567, so a plain HTTP response here is usually someone's development app. Alternatively, MariaDB Galera and Percona XtraDB Cluster use 4567 for gcomm group communication — the replication channel between cluster nodes — with 4568 for incremental state transfer and 4444 for full snapshot transfer. An HTTP request distinguishes them in one shot.",
"exposure": {
"verdict": "never",
"note": "A Sinatra dev server runs with development error pages and no hardening; Galera group communication is unencrypted database replication unless TLS is explicitly configured. Neither belongs on a public interface."
},
"checkCommand": "curl -sI --max-time 5 http://TARGET:4567/",
"links": [
{
"title": "sinatra/sinatra — default port 4567",
"url": "https://github.com/sinatra/sinatra",
"kind": "github"
},
{
"title": "MariaDB — Galera cluster address (replication defaults to 4567)",
"url": "https://mariadb.com/docs/galera-cluster/galera-management/configuration/galera-cluster-address",
"kind": "official-docs"
},
{
"title": "IANA port registry — 4567 (tram)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=4567",
"kind": "iana"
}
]
},
{
"port": 4662,
"protocol": "tcp",
"service": "eDonkey2000 / eMule",
"oneLiner": "The classic eDonkey file-sharing port — eMule and aMule clients listening for incoming peers.",
"whatItIs": "4662 TCP, paired with 4672 UDP, was the default listening port of eDonkey2000 and then eMule, the peer-to-peer file-sharing clients that dominated European file sharing in the early 2000s. eMule's own FAQ notes that versions from 0.47c onward pick random ports at first start precisely because the fixed defaults were so widely blocked and fingerprinted, so a modern client may be anywhere. IANA registers the port to an unrelated service, OrbitNet Message Service. Scanners and ISPs alike have treated 4662 as a P2P signature for two decades.",
"exposure": {
"verdict": "careful",
"note": "Inbound connections are how the protocol works, so an open port is not itself a misconfiguration — but it advertises P2P participation to anyone scanning and exposes a legacy, lightly maintained client to the internet."
},
"checkCommand": "nc -vz -w 3 TARGET 4662",
"links": [
{
"title": "eMule FAQ — default ports 4662 TCP / 4672 UDP and their randomisation",
"url": "https://www.emule-project.com/home/perl/help.cgi?l=1&rm=show_topic&topic_id=122",
"kind": "official-docs"
},
{
"title": "IANA port registry — 4662 (oms)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=4662",
"kind": "iana"
}
]
},
{
"port": 4848,
"protocol": "tcp",
"service": "GlassFish / Payara admin console",
"oneLiner": "The administration console of a GlassFish or Payara Java application server — full deployment control.",
"whatItIs": "IANA registers 4848 as appserv-http, App Server Admin HTTP, and that is exactly what it is: the default admin listener of Sun/Oracle GlassFish, its Eclipse successor Eclipse GlassFish, and the Payara fork. The quick-start guide points administrators at http://localhost:4848, and the same port serves the asadmin CLI's remote commands. Whoever reaches it can deploy applications, which on a Java application server means running arbitrary code.",
"exposure": {
"verdict": "never",
"note": "Deploying a WAR through this console is remote code execution by design; keep it on localhost or a management network, and never publish it even with authentication enabled."
},
"checkCommand": "curl -sk -o /dev/null -w '%{http_code}\\n' --max-time 5 https://TARGET:4848/",
"links": [
{
"title": "Eclipse GlassFish Quick Start Guide — Administration Console on port 4848",
"url": "https://glassfish.org/docs/latest/quick-start-guide.html",
"kind": "official-docs"
},
{
"title": "eclipse-ee4j/glassfish",
"url": "https://github.com/eclipse-ee4j/glassfish",
"kind": "github"
},
{
"title": "IANA port registry — 4848 (appserv-http)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=4848",
"kind": "iana"
}
]
},
{
"port": 4899,
"protocol": "both",
"service": "Radmin",
"oneLiner": "Radmin Server — Windows remote control, listening on its registered default port.",
"whatItIs": "IANA has 4899 registered as radmin-port for Famatech's Radmin, and Radmin Server listens here unless an admin unticks \"Use default port\" in its options. Radmin Viewer connects to it for full remote desktop control, file transfer, and shell access on Windows hosts. It shows up on scans of corporate Windows fleets and, historically, on machines where a trojan installed a copy of Radmin as a backdoor.",
"exposure": {
"verdict": "never",
"note": "This is a full remote-control plane for a Windows desktop. Keep it inside the LAN or behind a VPN; an internet-facing 4899 is a credential-guessing target with total-compromise payoff."
},
"checkCommand": "nc -vz TARGET 4899",
"links": [
{
"title": "Radmin Helpdesk — Changing the Radmin port",
"url": "https://helpdesk.radmin.com/kb/faq.php?id=327",
"kind": "official-docs"
},
{
"title": "IANA port registry — 4899 (radmin-port)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=4899",
"kind": "iana"
}
]
},
{
"port": 4900,
"protocol": "both",
"service": "HFSQL Client/Server",
"oneLiner": "HFSQL, the database engine bundled with PC SOFT's WINDEV — its server port.",
"whatItIs": "PC SOFT registered 4900 for HFSQL (formerly HyperFileSQL), the database engine that ships with WINDEV, WEBDEV and WINDEV Mobile. PC SOFT's documentation states the HFSQL server uses TCP 4900 by default, changeable in HFConf.ini; the companion manager service sits on 4999. You only see it around WINDEV-built business applications, which are common in France and rare elsewhere.",
"exposure": {
"verdict": "never",
"note": "It is a database wire port. Keep it on a private network and reach it through the application tier or a VPN, not from the internet."
},
"checkCommand": "nc -vz TARGET 4900",
"links": [
{
"title": "PC SOFT — HFSQL Client/Server: Port management",
"url": "https://help.windev.com/en-US/?3044334=",
"kind": "official-docs"
},
{
"title": "IANA port registry — 4900 (hfcs)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=4900",
"kind": "iana"
}
]
},
{
"port": 4998,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned at IANA — no standard service owns 4998.",
"whatItIs": "4998 has no entry in the IANA service name and port number registry, while its neighbours 4999 (HFSQL manager) and 5000 (commplex-main) do. Nmap's services file lists it as \"maybe-veritas\" with a very low hit frequency, a guess carried from old scan data rather than a confirmed protocol. Anything listening here is application-specific, so identify it by its banner rather than by the number.",
"exposure": {
"verdict": "careful",
"note": "An unregistered port tells you nothing about what is behind it. Find out what process owns the socket before deciding whether it belongs on a public interface."
},
"checkCommand": "sudo lsof -nP -iTCP:4998 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=4998",
"kind": "iana"
}
]
},
{
"port": 5000,
"protocol": "tcp",
"service": "Flask dev server, Docker registry, macOS AirPlay Receiver",
"oneLiner": "Flask's development server port, the Docker registry's container port, and the port macOS quietly took over.",
"whatItIs": "`flask run` serves on 127.0.0.1:5000, and the Docker distribution registry listens on 5000 inside its container. On macOS Monterey and later the AirPlay Receiver service binds 5000 by default, which is why Flask developers on Macs see \"Address already in use\" out of nowhere; the fix is to turn AirPlay Receiver off in System Settings or pick another port. IANA has it registered as commplex-main.",
"exposure": {
"verdict": "never",
"note": "Flask's docs say the dev server is not designed to be secure, and an unauthenticated registry on 5000 lets anyone push and pull images."
},
"checkCommand": "sudo lsof -nP -iTCP:5000 -sTCP:LISTEN",
"links": [
{
"title": "Flask — Development Server (port 5000, macOS AirPlay conflict)",
"url": "https://flask.palletsprojects.com/en/stable/server/",
"kind": "official-docs"
},
{
"title": "Docker Distribution — Deploying a registry server (listens on 5000)",
"url": "https://distribution.github.io/distribution/about/deploying/",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 5000",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5000",
"kind": "iana"
}
],
"ianaName": "commplex-main"
},
{
"port": 5001,
"protocol": "tcp",
"service": "commplex-link / Synology DSM HTTPS / iperf 2",
"oneLiner": "Registered as commplex-link, but in practice Synology DSM over HTTPS or an iperf 2 server.",
"whatItIs": "The IANA name for 5001 is commplex-link, a registration with no public protocol behind it, so what you actually meet on this port is a squatter. On a home or small-office network it is usually a Synology NAS: DSM's web interface answers HTTP on 5000 and HTTPS on 5001 by default. On a lab or transit-test host it is more often an iperf 2 server, whose default listen port is 5001 (iperf3 moved to 5201).",
"exposure": {
"verdict": "careful",
"note": "A DSM login page on the public internet is a brute-force magnet — put it behind a VPN or reverse proxy with MFA. An iperf server accepts traffic from anyone who finds it and should never be left running on a public address."
},
"checkCommand": "curl -sk -o /dev/null -w '%{http_code}\\n' https://TARGET:5001/",
"links": [
{
"title": "Synology Knowledge Center — network ports used by Synology services",
"url": "https://kb.synology.com/en-us/DSM/tutorial/What_network_ports_are_used_by_Synology_services",
"kind": "official-docs"
},
{
"title": "iPerf documentation — server port defaults (5001 for iPerf 2)",
"url": "https://iperf.fr/iperf-doc.php",
"kind": "official-docs"
},
{
"title": "IANA port registry — 5001 (commplex-link)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5001",
"kind": "iana"
}
]
},
{
"port": 5002,
"protocol": "tcp",
"service": "rfe",
"oneLiner": "Registered to \"radio free ethernet\", an old broadcast audio experiment — effectively a free port today.",
"whatItIs": "IANA lists 5002 as rfe, \"radio free ethernet\", one of the early-1990s registrations that never grew a public specification or a surviving implementation. Nothing widely deployed claims it now, so a listener here is almost always an application that picked a round number near 5000. Treat the registered name as trivia and identify the service from its banner.",
"exposure": {
"verdict": "careful",
"note": "The port number carries no security meaning. Judge exposure by whatever process actually owns the socket."
},
"checkCommand": "sudo lsof -nP -iTCP:5002 -sTCP:LISTEN",
"links": [
{
"title": "IANA port registry — 5002 (rfe)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5002",
"kind": "iana"
}
]
},
{
"port": 5003,
"protocol": "tcp",
"service": "FileMaker Server",
"oneLiner": "FileMaker's client-server data port — FileMaker Pro and Go talk to FileMaker Server here.",
"whatItIs": "Claris registered 5003 as fmpro-internal for FileMaker's proprietary transport, and it is the port FileMaker Pro and FileMaker Go use to open hosted databases on FileMaker Server. Claris documents it as required through the firewall alongside 80 and 443, and it is not configurable. A listener on 5003 means a FileMaker Server is hosting solutions for clients somewhere.",
"exposure": {
"verdict": "careful",
"note": "Claris's own deployment model puts this port in front of remote clients, so exposure is defensible — but only with a real TLS certificate installed on the server, strong account passwords, and the admin console (16000) kept off the public internet."
},
"checkCommand": "nc -vz TARGET 5003",
"links": [
{
"title": "Claris — Ports used by FileMaker Server",
"url": "https://help.claris.com/en/server-installation-configuration-guide/content/ports-used-by-server.html",
"kind": "official-docs"
},
{
"title": "IANA port registry — 5003 (fmpro-internal)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5003",
"kind": "iana"
}
]
},
{
"port": 5004,
"protocol": "both",
"service": "RTP (AVP profile)",
"oneLiner": "The default RTP media port — the audio and video of a call, with RTCP next door on 5005.",
"whatItIs": "IANA registers 5004 as avt-profile-1, \"RTP media data\", the default for RTP under the audio/video profile of RFC 3551; the odd port above it carries RTCP. In practice signalling on SIP or RTSP negotiates a dynamic even port for each stream, so 5004 is the textbook default rather than a fixed rendezvous, and it turns up on softphones, IP cameras, and encoders that never changed it. RFC 4571 defines the framing when RTP has to run over TCP instead of UDP.",
"exposure": {
"verdict": "careful",
"note": "Plain RTP is unencrypted media: anyone on the path can record the call. Use SRTP, and keep the media port range reachable only from the signalling peers that need it."
},
"checkCommand": "sudo tcpdump -ni any udp port 5004",
"links": [
{
"title": "RFC 3551 — RTP Profile for Audio and Video Conferences",
"url": "https://www.rfc-editor.org/rfc/rfc3551.html",
"kind": "spec"
},
{
"title": "RFC 4571 — Framing RTP and RTCP Packets over Connection-Oriented Transport",
"url": "https://www.rfc-editor.org/rfc/rfc4571.html",
"kind": "spec"
},
{
"title": "IANA port registry — 5004 (avt-profile-1)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5004",
"kind": "iana"
}
]
},
{
"port": 5009,
"protocol": "tcp",
"service": "AirPort admin (registered as winfs)",
"oneLiner": "Apple AirPort base station administration — the port AirPort Utility configures the router on.",
"whatItIs": "The IANA registration for 5009 is winfs, \"Microsoft Windows Filesystem\", which you will essentially never meet. What actually answers is Apple's base station admin service: AirPort Utility talks to an AirPort Express, Extreme, or Time Capsule on TCP 5009 to read and write its configuration. Apple discontinued the AirPort line in 2018, so a listener today is an old base station still in service — and the port is a reliable fingerprint for one.",
"exposure": {
"verdict": "never",
"note": "This is the router's configuration plane on hardware that stopped receiving firmware updates. It belongs on the LAN only; never enable base-station administration from the WAN side."
},
"checkCommand": "nc -vz TARGET 5009",
"links": [
{
"title": "IANA port registry — 5009 (winfs)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5009",
"kind": "iana"
},
{
"title": "nmap-services — 5009/tcp airport-admin",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 5030,
"protocol": "tcp",
"service": "reserved",
"oneLiner": "Marked Reserved at IANA — an old \"surfpass\" registration that was given back.",
"whatItIs": "The current IANA registry shows 5030 as Reserved with no service name, meaning an earlier assignment was withdrawn rather than replaced. Nmap's services file still carries the historical name surfpass, which is why scanners sometimes print it. There is no live protocol to expect here, so anything listening is a private application choice.",
"exposure": {
"verdict": "careful",
"note": "Nothing standard should be on 5030. Identify the owning process before allowing it through a firewall."
},
"checkCommand": "sudo lsof -nP -iTCP:5030 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5030",
"kind": "iana"
}
]
},
{
"port": 5033,
"protocol": "tcp",
"service": "jtnetd-server",
"oneLiner": "Registered as Janstor Secure Data — a vendor port you are unlikely to meet in the wild.",
"whatItIs": "IANA assigns 5033/tcp to jtnetd-server, \"Janstor Secure Data\"; the UDP side is simply Reserved. There is no public specification and no widely deployed implementation, and scanners record it with a very low hit rate. If you find something on 5033 it is far more likely to be an unrelated application that chose the number than a Janstor deployment.",
"exposure": {
"verdict": "careful",
"note": "Treat it as unknown: fingerprint the listener before exposing it, since the registration tells you nothing about its authentication or encryption."
},
"checkCommand": "sudo lsof -nP -iTCP:5033 -sTCP:LISTEN",
"links": [
{
"title": "IANA port registry — 5033 (jtnetd-server)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5033",
"kind": "iana"
}
]
},
{
"port": 5050,
"protocol": "both",
"service": "Apache Mesos master (registered as mmcc)",
"oneLiner": "Registered to an old conference-control tool, but today it is usually a Mesos master's HTTP API and web UI.",
"whatItIs": "IANA lists 5050 as mmcc, a multimedia conference control tool from the early RTP era; Yahoo Messenger also squatted here for years before the service shut down in 2018. The live occupant now is Apache Mesos, whose master defaults to `--port=5050` for its HTTP endpoints and web UI, with agents on 5051. Hitting `http://host:5050/state` on a Mesos master returns the full cluster state as JSON.",
"exposure": {
"verdict": "never",
"note": "The Mesos master API is a cluster control plane and ships without authentication enabled, so an open 5050 hands over cluster topology and, with framework access, the ability to schedule tasks. Keep it on a management network."
},
"checkCommand": "curl -s http://TARGET:5050/state | head -c 400",
"links": [
{
"title": "Apache Mesos — Master and Agent Options (--port defaults)",
"url": "https://mesos.apache.org/documentation/latest/configuration/master-and-agent/",
"kind": "official-docs"
},
{
"title": "apache/mesos on GitHub",
"url": "https://github.com/apache/mesos",
"kind": "github"
},
{
"title": "IANA port registry — 5050 (mmcc)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5050",
"kind": "iana"
}
]
},
{
"port": 5051,
"protocol": "both",
"service": "Apache Mesos agent (registered as ita-agent)",
"oneLiner": "The Mesos agent port in modern clusters; registered to Symantec's Intruder Alert agent.",
"whatItIs": "IANA registers 5051 as ita-agent, the agent side of Symantec's Intruder Alert host intrusion detection product, which is long discontinued. What you find on 5051 today is normally an Apache Mesos agent, whose default `--port` is 5051 while the master uses 5050. The agent exposes HTTP endpoints describing the tasks and executors running on that host.",
"exposure": {
"verdict": "never",
"note": "A Mesos agent endpoint reveals what is running on the node and is part of the cluster control path; keep it on the internal network alongside the master."
},
"checkCommand": "curl -s http://TARGET:5051/state | head -c 400",
"links": [
{
"title": "Apache Mesos — Master and Agent Options (--port defaults)",
"url": "https://mesos.apache.org/documentation/latest/configuration/master-and-agent/",
"kind": "official-docs"
},
{
"title": "IANA port registry — 5051 (ita-agent)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5051",
"kind": "iana"
}
]
},
{
"port": 5054,
"protocol": "tcp",
"service": "RLM web administration",
"oneLiner": "The Reprise License Manager admin web server — license administration for CAD, EDA and VFX tools.",
"whatItIs": "Reprise Software registered 5054 as rlm-admin, and the rlm daemon starts its embedded web server on that port automatically (override with `-ws NNNNN`). The license server itself answers on 5053, while 5054 is the browser interface used to view checkouts, edit the license file, reread licenses, and shut the server down. Since RLM v16.0 that interface is HTTPS by default with a self-signed certificate.",
"exposure": {
"verdict": "never",
"note": "It is an administrative plane that can stop the license server and rewrite its configuration, and installs commonly keep the shipped default credentials. Bind it to the internal network only."
},
"checkCommand": "curl -sk -o /dev/null -w '%{http_code}\\n' https://TARGET:5054/",
"links": [
{
"title": "Reprise docs — The RLM Web Server",
"url": "https://docs.reprisesoftware.com/docs/admin/rlm-web-server.html",
"kind": "official-docs"
},
{
"title": "IANA port registry — 5054 (rlm-admin)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5054",
"kind": "iana"
}
]
},
{
"port": 5060,
"protocol": "both",
"service": "SIP",
"oneLiner": "SIP signalling in the clear — the port that sets up VoIP calls, and the most scanned VoIP port there is.",
"whatItIs": "RFC 3261 makes 5060 the default port for SIP over UDP and TCP, so IP phones, PBXes such as Asterisk, Kamailio and FreeSWITCH, SIP trunks and ATAs all rendezvous here. The traffic is text: REGISTER, INVITE and OPTIONS requests with headers naming the user agent, extensions and realm. It attracts constant background scanning from tools like SIPVicious that hunt for extensions with weak passwords, because a compromised PBX becomes someone else's toll-fraud gateway.",
"exposure": {
"verdict": "careful",
"note": "Exposing 5060 is normal for a public SIP service but it is unauthenticated cleartext signalling. Restrict by source IP where you can, enforce strong per-extension secrets, rate-limit registrations, and prefer 5061 with TLS for anything crossing the internet."
},
"checkCommand": "sudo nmap -sU -p 5060 --script sip-methods TARGET",
"links": [
{
"title": "RFC 3261 — SIP: Session Initiation Protocol",
"url": "https://www.rfc-editor.org/rfc/rfc3261.html",
"kind": "spec"
},
{
"title": "asterisk/asterisk on GitHub",
"url": "https://github.com/asterisk/asterisk",
"kind": "github"
},
{
"title": "IANA port registry — 5060 (sip)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5060",
"kind": "iana"
}
]
},
{
"port": 5061,
"protocol": "both",
"service": "SIP over TLS",
"oneLiner": "SIPS — the same SIP signalling as 5060, wrapped in TLS.",
"whatItIs": "RFC 3261 assigns 5061 to SIP over TLS, and the sips: URI scheme implies it. The handshake is ordinary TLS, so the server presents a certificate before any SIP message is exchanged, which hides headers, extensions and credentials from the path. Carriers and hosted PBX providers offer it as the secure trunk option, usually paired with SRTP for the media. Signalling encryption does not encrypt the audio: without SRTP the RTP streams are still in the clear.",
"exposure": {
"verdict": "fine",
"note": "This is the port to expose if SIP must face the internet. Use a valid certificate, disable old TLS versions, and still rate-limit registrations — TLS protects the wire, not weak extension passwords."
},
"checkCommand": "openssl s_client -connect TARGET:5061 -servername TARGET /dev/null | head -20",
"links": [
{
"title": "RFC 3261 — SIP: Session Initiation Protocol",
"url": "https://www.rfc-editor.org/rfc/rfc3261.html",
"kind": "spec"
},
{
"title": "IANA port registry — 5061 (sips)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5061",
"kind": "iana"
}
]
},
{
"port": 5080,
"protocol": "tcp",
"service": "FreeSWITCH external SIP profile (registered as onscreen)",
"oneLiner": "The second SIP port — FreeSWITCH's external profile, where carriers and trunks land.",
"whatItIs": "IANA has 5080 registered as onscreen, \"OnScreen Data Collection Service\", which you will not meet in practice. The real occupant is FreeSWITCH: its shipped external profile binds 5080 (the $${external_sip_port} variable) for gateways and SIP trunks, with the internal profile on 5060 for registered handsets. The split exists because the external profile runs with auth-calls disabled — carriers authenticate by IP, not by registration.",
"exposure": {
"verdict": "careful",
"note": "The external profile accepts unauthenticated INVITEs by design, so the only thing between it and toll fraud is a source-IP ACL. Restrict it to your carrier's networks and audit the dialplan reachable from that profile."
},
"checkCommand": "nc -vz TARGET 5080",
"links": [
{
"title": "FreeSWITCH docs — SIP profiles (internal 5060, external 5080)",
"url": "https://developer.signalwire.com/freeswitch/users-and-endpoints/sip-profiles/",
"kind": "official-docs"
},
{
"title": "signalwire/freeswitch on GitHub",
"url": "https://github.com/signalwire/freeswitch",
"kind": "github"
},
{
"title": "IANA port registry — 5080 (onscreen)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5080",
"kind": "iana"
}
]
},
{
"port": 5087,
"protocol": "tcp",
"service": "BIOTIC",
"oneLiner": "Registered to BIOTIC, a binary IoT messaging protocol — rarely seen on real networks.",
"whatItIs": "IANA assigns 5087/tcp to biotic, \"Binary Internet of Things Interoperable Communication\", a protocol proposal from Peter Waher aimed at resource-constrained IoT devices that combines request/response, publish/subscribe, and peer-to-peer patterns in one binary encoding. The UDP side of 5087 is Reserved. Deployment is minimal, so a listener on this port is much more likely to be an unrelated application than a BIOTIC endpoint.",
"exposure": {
"verdict": "careful",
"note": "Identify the actual service before opening it; the registration alone says nothing about whether what is listening authenticates or encrypts."
},
"checkCommand": "sudo lsof -nP -iTCP:5087 -sTCP:LISTEN",
"links": [
{
"title": "BIOTIC — executive summary (Neuro Foundation)",
"url": "https://neuro-foundation.io/Papers/Biotic%20-%20Executive%20Summary.pdf",
"kind": "spec"
},
{
"title": "IANA port registry — 5087 (biotic)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5087",
"kind": "iana"
}
]
},
{
"port": 5100,
"protocol": "tcp",
"service": "socalia",
"oneLiner": "Registered as \"Socalia service mux\"; scanners still print the dead Chili!Soft ASP name admd.",
"whatItIs": "IANA's current entry for 5100 is socalia, a service multiplexer registration with no public specification. Nmap's list carries the older label admd, the administration port of Chili!Soft ASP, a product discontinued long ago, and notes Yahoo pager traffic as another historical squatter. None of those are live software today, so treat 5100 as an unclaimed number in the 5100-5102 block and fingerprint whatever answers.",
"exposure": {
"verdict": "careful",
"note": "No standard service means no default security posture. Find the owning process before allowing it through a firewall."
},
"checkCommand": "sudo lsof -nP -iTCP:5100 -sTCP:LISTEN",
"links": [
{
"title": "IANA port registry — 5100 (socalia)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5100",
"kind": "iana"
}
]
},
{
"port": 5101,
"protocol": "tcp",
"service": "talarian-tcp",
"oneLiner": "Registered to Talarian's messaging middleware; also the old Yahoo Messenger file-transfer port.",
"whatItIs": "IANA lists 5101/tcp as talarian-tcp (5101/udp as talarian-udp), from Talarian's SmartSockets publish/subscribe middleware, a product later absorbed by TIBCO. The port's other well-known historical use was Yahoo Messenger file transfer, and Yahoo Messenger shut down in 2018. Nmap labels it admdog from the same defunct Chili!Soft ASP family as 5100 and 5102. Nothing current owns it.",
"exposure": {
"verdict": "careful",
"note": "Identify what is actually listening. A legacy middleware bus on this port typically predates modern authentication and should stay on an internal segment."
},
"checkCommand": "sudo lsof -nP -iTCP:5101 -sTCP:LISTEN",
"links": [
{
"title": "IANA port registry — 5101 (talarian-tcp)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5101",
"kind": "iana"
}
]
},
{
"port": 5102,
"protocol": "tcp",
"service": "Oracle OMS non-secure",
"oneLiner": "Registered to Oracle's Management Server in its non-secure mode — cleartext management traffic.",
"whatItIs": "IANA registers 5102 as oms-nonsecure, \"Oracle OMS non-secure\", the unencrypted channel for Oracle's Management Server component of Enterprise Manager. The name is explicit about what it is: the same management traffic as the secure variant, without TLS. Modern Enterprise Manager deployments use HTTPS upload and console ports instead, so a listener here suggests an old or misconfigured install.",
"exposure": {
"verdict": "never",
"note": "A cleartext management channel to a database estate. Disable it in favour of the secure port; anything on the path can read the traffic."
},
"checkCommand": "nc -vz TARGET 5102",
"links": [
{
"title": "IANA port registry — 5102 (oms-nonsecure)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5102",
"kind": "iana"
}
]
},
{
"port": 5120,
"protocol": "both",
"service": "Barracuda Backup replication",
"oneLiner": "Barracuda Backup's offsite replication port — outbound from the appliance, never inbound.",
"whatItIs": "IANA registers 5120 as barracuda-bbs, the Barracuda Backup Protocol. Barracuda's documentation puts 5120-5129 in the outbound set a Backup appliance needs, using them to replicate data to Barracuda Cloud Storage or to a second Barracuda Backup device. The vendor is explicit that no inbound ports are required: the appliance always initiates the connection, and these ports cannot be proxied.",
"exposure": {
"verdict": "careful",
"note": "Allow it outbound from the backup appliance only. There is no reason for an inbound firewall rule on 5120, so a listener answering from the internet is not a normal Barracuda deployment."
},
"checkCommand": "nc -vz TARGET 5120",
"links": [
{
"title": "Barracuda Backup — Port Usage",
"url": "https://documentation.campus.barracuda.com/wiki/display/BBSv42/Port+Usage",
"kind": "official-docs"
},
{
"title": "IANA port registry — 5120 (barracuda-bbs)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5120",
"kind": "iana"
}
]
},
{
"port": 5173,
"protocol": "tcp",
"service": "Vite dev server",
"oneLiner": "Vite's default development server port.",
"whatItIs": "Vite picks 5173 for `vite dev` unless server.port says otherwise, and it walks upward (5174, 5175) when the port is taken. Anything built on Vite — modern React, Vue, Svelte and SvelteKit setups — lands here. It is unregistered with IANA, so a listener on 5173 is a frontend developer's machine or a container running a dev build.",
"exposure": {
"verdict": "never",
"note": "A dev server with hot-module reload, source maps and no auth has no business on a public interface."
},
"checkCommand": "curl -sI http://localhost:5173/",
"links": [
{
"title": "Vite — Server Options (server.port default 5173)",
"url": "https://vite.dev/config/server-options",
"kind": "official-docs"
},
{
"title": "Vite — Command Line Interface",
"url": "https://vite.dev/guide/cli.html",
"kind": "official-docs"
},
{
"title": "vitejs/vite on GitHub",
"url": "https://github.com/vitejs/vite",
"kind": "github"
}
]
},
{
"port": 5190,
"protocol": "both",
"service": "AOL / OSCAR (AIM, ICQ)",
"oneLiner": "The AOL instant-messaging port — AIM and ICQ signed on here, and both services are now dead.",
"whatItIs": "IANA registered 5190 to America Online, and it carried the OSCAR protocol used by AIM and ICQ clients to log in and exchange messages. AIM shut down in December 2017 and ICQ in June 2024, so the original services no longer answer. What remains are firewall rules, IDS signatures and old clients that still name the port, plus the occasional third-party OSCAR revival server.",
"exposure": {
"verdict": "careful",
"note": "OSCAR authentication and messages were not encrypted in the classic clients. Nothing legitimate should be listening on 5190 today; investigate anything that is."
},
"checkCommand": "nc -vz TARGET 5190",
"links": [
{
"title": "IANA port registry — 5190 (aol)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5190",
"kind": "iana"
}
]
},
{
"port": 5200,
"protocol": "both",
"service": "targus-getdata",
"oneLiner": "Registered as TARGUS GetData — a vendor assignment with no public protocol behind it.",
"whatItIs": "IANA assigns 5200 (TCP and UDP) to targus-getdata, with 5201-5203 registered to the same family as targus-getdata1 through -getdata3. There is no published specification and no widely deployed implementation, and scan data shows it very rarely. Note that 5201, one number up, is the iperf3 default and is far more likely to be what you actually meet in that range.",
"exposure": {
"verdict": "careful",
"note": "The registration tells you nothing useful about a listener here. Fingerprint the process before exposing the port."
},
"checkCommand": "sudo lsof -nP -iTCP:5200 -sTCP:LISTEN",
"links": [
{
"title": "IANA port registry — 5200 (targus-getdata)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5200",
"kind": "iana"
}
]
},
{
"port": 5214,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Nothing is registered here — a listener on 5214 is some application's own pick.",
"whatItIs": "IANA lists 5210-5214 as unassigned, so there is no service name and no protocol that belongs to this port. No widely deployed product uses it by convention either, which means the port number tells you nothing about what is behind it. If a scan shows it open, identify the process on the host rather than guessing from a port list.",
"exposure": {
"verdict": "careful",
"note": "An unidentified listener is unreviewed by definition — find the owning process before deciding whether it may be reachable at all."
},
"checkCommand": "sudo lsof -nP -iTCP:5214 -sTCP:LISTEN",
"links": [
{
"title": "IANA port registry — 5214 (unassigned)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5214",
"kind": "iana"
}
]
},
{
"port": 5221,
"protocol": "tcp",
"service": "3eTI Extensible Management Protocol (3exmp)",
"oneLiner": "The management channel of 3eTI ruggedized wireless gear — almost nothing else uses it.",
"whatItIs": "IANA registered 5221/tcp in 2010 as 3exmp, the 3eTI Extensible Management Protocol for OAMP (operations, administration, maintenance, provisioning). 3e Technologies International builds hardened wireless and cybersecurity appliances for military and industrial networks, and the protocol carries device management for that equipment. UDP 5221 is reserved, not assigned. Outside a site running 3eTI hardware you will effectively never see this port open.",
"exposure": {
"verdict": "never",
"note": "This is a device management plane; it belongs on a management VLAN, never on an internet-facing interface."
},
"checkCommand": "nc -vz -w 3 TARGET 5221",
"links": [
{
"title": "IANA port registry — 5221 (3exmp)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5221",
"kind": "iana"
}
]
},
{
"port": 5222,
"protocol": "tcp",
"service": "XMPP client connection",
"oneLiner": "An XMPP (Jabber) server accepting client logins — chat, presence, and push behind many apps.",
"whatItIs": "RFC 6120 assigns 5222 to XMPP client-to-server streams: the client opens a TCP connection, exchanges XML stream headers, upgrades to TLS with STARTTLS, then authenticates over SASL. Prosody, ejabberd, and Openfire all listen here by default, and it is still the transport under group chat, IoT messaging, and several game and push backends. A scan hit means a real XMPP server, since the port has no common squatters.",
"exposure": {
"verdict": "fine",
"note": "Public by design — but require STARTTLS (or use the direct-TLS port 5223) so credentials never cross the wire before encryption."
},
"checkCommand": "printf \"\" | nc -w 3 TARGET 5222",
"links": [
{
"title": "RFC 6120 — XMPP: Core",
"url": "https://www.rfc-editor.org/rfc/rfc6120.html",
"kind": "spec"
},
{
"title": "Prosody — ports and network configuration",
"url": "https://prosody.im/doc/ports",
"kind": "official-docs"
},
{
"title": "IANA port registry — 5222 (xmpp-client)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5222",
"kind": "iana"
}
]
},
{
"port": 5225,
"protocol": "both",
"service": "HP Server (hp-server)",
"oneLiner": "Part of HP's printing stack — this port and 5226 travel together on networks with HP printers.",
"whatItIs": "IANA has 5225 registered to Hewlett-Packard as hp-server on both TCP and UDP, with no published protocol description. In practice it is reported next to 5226 (hp-status) on hosts running HP print software and on HP print servers. HP publishes no protocol description and no public HP port list documents either number, so what the pair actually carries is unverified — identify the process rather than reading a purpose into the registry name.",
"exposure": {
"verdict": "careful",
"note": "Printing infrastructure is a LAN service with no authentication story worth relying on — keep it inside the network."
},
"checkCommand": "nc -vz -w 3 TARGET 5225",
"links": [
{
"title": "IANA port registry — 5225 (hp-server)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5225",
"kind": "iana"
}
]
},
{
"port": 5226,
"protocol": "both",
"service": "HP Status (hp-status)",
"oneLiner": "The HP printer status channel — usually open on the workstation, not the printer.",
"whatItIs": "IANA registers 5226 to Hewlett-Packard as hp-status on TCP and UDP. It is the better-known half of the 5225/5226 pair: the HP Universal Print Driver listens on it so printer status can be delivered back to a workstation. Because it opens on ordinary desktops as a side effect of installing a printer driver, it is a frequent source of internal port-scan alerts that turn out to be benign.",
"exposure": {
"verdict": "careful",
"note": "There is no reason for a desktop print-status listener to be reachable from anywhere but the local network."
},
"checkCommand": "nc -vz -w 3 TARGET 5226",
"links": [
{
"title": "IANA port registry — 5226 (hp-status)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5226",
"kind": "iana"
}
]
},
{
"port": 5269,
"protocol": "tcp",
"service": "XMPP server-to-server",
"oneLiner": "The federation port — how one XMPP server talks to another so users on different domains can chat.",
"whatItIs": "RFC 6120 assigns 5269 to XMPP server-to-server streams. When a user on one domain messages a user on another, the sending server looks up the target's _xmpp-server._tcp SRV record and opens a stream here, authenticating with TLS plus either certificates or server dialback. Prosody, ejabberd, and Openfire enable it whenever federation is on. It carries no client logins, so it appears only on actual XMPP servers.",
"exposure": {
"verdict": "fine",
"note": "Federation only works if this is publicly reachable; the risk to manage is spam and abusive peers, not exposure itself."
},
"checkCommand": "dig +short SRV _xmpp-server._tcp.TARGET && nc -vz -w 3 TARGET 5269",
"links": [
{
"title": "RFC 6120 — XMPP: Core",
"url": "https://www.rfc-editor.org/rfc/rfc6120.html",
"kind": "spec"
},
{
"title": "ejabberd — listen modules and default ports",
"url": "https://docs.ejabberd.im/admin/configuration/listen/",
"kind": "official-docs"
},
{
"title": "IANA port registry — 5269 (xmpp-server)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5269",
"kind": "iana"
}
]
},
{
"port": 5280,
"protocol": "tcp",
"service": "XMPP over BOSH / HTTP",
"oneLiner": "An XMPP server's HTTP side — BOSH and WebSocket endpoints for browser-based chat clients.",
"whatItIs": "Registered with IANA in 2009 as xmpp-bosh, this is the HTTP port for Bidirectional-streams Over Synchronous HTTP (XEP-0124), which tunnels an XMPP session through long-polling HTTP requests for clients that cannot hold a raw TCP stream. Prosody uses 5280 as its default plain-HTTP port, serving /http-bind for BOSH and /xmpp-websocket, with 5281 as the HTTPS counterpart. On a scan it responds like a small web server, which is exactly what it is.",
"exposure": {
"verdict": "careful",
"note": "Plain HTTP by default — session credentials and messages are cleartext unless you front it with TLS on 5281 or a reverse proxy."
},
"checkCommand": "curl -sS -o /dev/null -w '%{http_code}\\n' http://TARGET:5280/http-bind/",
"links": [
{
"title": "XEP-0124 — Bidirectional-streams Over Synchronous HTTP (BOSH)",
"url": "https://xmpp.org/extensions/xep-0124.html",
"kind": "spec"
},
{
"title": "Prosody — setting up BOSH",
"url": "https://prosody.im/doc/setting_up_bosh",
"kind": "official-docs"
},
{
"title": "IANA port registry — 5280 (xmpp-bosh)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5280",
"kind": "iana"
}
]
},
{
"port": 5298,
"protocol": "both",
"service": "XMPP link-local messaging (presence)",
"oneLiner": "Serverless XMPP between machines on the same LAN — the old Bonjour/iChat-style chat.",
"whatItIs": "IANA registered 5298 in 2008 as presence, for XMPP link-local messaging: peers advertise _presence._tcp over mDNS and then open a direct XMPP stream to each other with no server in the middle, as described in XEP-0174. Apple's iChat/Messages Bonjour mode popularised it, and Pidgin and Gajim implement the same scheme. Seeing it means a desktop chat client with local discovery turned on, not a chat server.",
"exposure": {
"verdict": "careful",
"note": "Link-local by design and unauthenticated — fine on a trusted LAN, and it has no business being routed or forwarded anywhere."
},
"checkCommand": "dns-sd -B _presence._tcp local.",
"links": [
{
"title": "XEP-0174 — Serverless Messaging",
"url": "https://xmpp.org/extensions/xep-0174.html",
"kind": "spec"
},
{
"title": "IANA port registry — 5298 (presence)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5298",
"kind": "iana"
}
]
},
{
"port": 5353,
"protocol": "udp",
"service": "mDNS (Bonjour / Avahi)",
"oneLiner": "Multicast DNS — how machines find each other by name on a LAN with no DNS server.",
"whatItIs": "mDNS resolves .local names and carries DNS-SD service discovery over multicast to 224.0.0.251 (FF02::FB on IPv6). It is running on essentially every Mac, iPhone, Android device, Linux box with Avahi, printer, and Chromecast on the network — the daemon is mDNSResponder on Apple platforms and avahi-daemon elsewhere. It appears on a scan because the responder binds UDP 5353 and will also answer unicast queries sent to that port.",
"exposure": {
"verdict": "never",
"note": "Reachable from the internet it both leaks a device inventory (hostnames, service records, sometimes usernames) and works as a reflection/amplification source; on a trusted LAN it is normal and expected."
},
"checkCommand": "dig +short @224.0.0.251 -p 5353 -t ptr _services._dns-sd._udp.local",
"links": [
{
"title": "RFC 6762 — Multicast DNS",
"url": "https://datatracker.ietf.org/doc/html/rfc6762",
"kind": "spec"
},
{
"title": "IANA port registry — 5353",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5353",
"kind": "iana"
},
{
"title": "apple-oss-distributions/mDNSResponder",
"url": "https://github.com/apple-oss-distributions/mDNSResponder",
"kind": "github"
},
{
"title": "Apple — TCP and UDP ports used by Apple software products",
"url": "https://support.apple.com/en-us/103229",
"kind": "official-docs"
}
]
},
{
"port": 5357,
"protocol": "tcp",
"service": "WSDAPI (Web Services on Devices)",
"oneLiner": "A Windows box with network discovery on — WSD's HTTP endpoint for printers, scanners, and device metadata.",
"whatItIs": "5357 is Microsoft's wsdapi port: the HTTP transport for Web Services on Devices, the stack behind WSD printing and scanning and behind Windows' Function Discovery Resource Publication service. Devices are found first over WS-Discovery multicast on UDP 3702, then queried for metadata and driven over HTTP here, with 5358 as the HTTPS variant. It opens automatically on Windows hosts and on network printers and NAS boxes whenever the network profile is Private, so it is one of the most common open ports on a Windows LAN.",
"exposure": {
"verdict": "never",
"note": "It is an unauthenticated LAN discovery service that hands out device and host metadata, and WSDAPI has had remotely reachable code-execution bugs — keep it off any public interface."
},
"checkCommand": "curl -sS -o /dev/null -w '%{http_code}\\n' http://TARGET:5357/",
"links": [
{
"title": "Microsoft — Web Services on Devices (WSDAPI)",
"url": "https://learn.microsoft.com/en-us/windows/win32/wsdapi/wsd-portal",
"kind": "official-docs"
},
{
"title": "OASIS — Web Services Dynamic Discovery (WS-Discovery) 1.1",
"url": "https://docs.oasis-open.org/ws-dd/discovery/1.1/os/wsdd-discovery-1.1-spec-os.html",
"kind": "spec"
},
{
"title": "IANA port registry — 5357 (wsdapi)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5357",
"kind": "iana"
}
]
},
{
"port": 5405,
"protocol": "both",
"service": "Corosync cluster messaging (IANA: netsupport)",
"oneLiner": "Almost always Corosync — the heartbeat and membership traffic of a Pacemaker or Proxmox cluster.",
"whatItIs": "IANA has 5405 registered as netsupport, but what you actually meet on this number is Corosync: its default mcastport is 5405, and the totem protocol receives on 5405 and sends on 5404, over UDP. That traffic carries cluster membership and the messages that decide which node runs which resource, so it shows up on every Pacemaker, Proxmox VE, and RHEL High Availability node. TCP 5405 is registered but idle in these deployments.",
"exposure": {
"verdict": "never",
"note": "Anyone who can inject or block totem traffic can split the cluster or trigger fencing — Corosync belongs on a dedicated private cluster network, with its crypto_hash/crypto_cipher key set."
},
"checkCommand": "sudo tcpdump -ni any udp port 5405",
"links": [
{
"title": "corosync.conf(5) — totem mcastport default",
"url": "https://manpages.debian.org/unstable/corosync/corosync.conf.5.en.html",
"kind": "official-docs"
},
{
"title": "corosync/corosync",
"url": "https://github.com/corosync/corosync",
"kind": "github"
},
{
"title": "IANA port registry — 5405 (netsupport)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5405",
"kind": "iana"
}
]
},
{
"port": 5414,
"protocol": "both",
"service": "StatusD (statusd)",
"oneLiner": "Registered to a product called StatusD and essentially never seen in the wild.",
"whatItIs": "IANA lists 5414 on TCP and UDP as statusd, an old registration with no published protocol description and no public documentation of the software behind it. Nothing in common use listens here by default. If it is open on a host, the answer will come from identifying the process, not from the registry entry.",
"exposure": {
"verdict": "careful",
"note": "Unknown service, unknown authentication — identify the listener before allowing it past the host firewall."
},
"checkCommand": "sudo lsof -nP -iTCP:5414 -sTCP:LISTEN",
"links": [
{
"title": "IANA port registry — 5414 (statusd)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5414",
"kind": "iana"
}
]
},
{
"port": 5431,
"protocol": "both",
"service": "PARK AGENT (park-agent)",
"oneLiner": "Registered as PARK AGENT, but when it turns up it is usually a consumer router's own service.",
"whatItIs": "IANA has 5431 registered as park-agent on TCP and UDP, an old entry with no published protocol description. The registered service is effectively extinct. What people do report finding on 5431 is a listener on consumer broadband routers — Broadcom-based Belkin, Linksys, and D-Link gateways — that disappears when UPnP is switched off, which points at the gateway's UPnP IGD control service; no vendor documentation confirms the port, so treat that as a field observation.",
"exposure": {
"verdict": "never",
"note": "If this is your router answering, it is a device control surface — it must not be reachable from the WAN side."
},
"checkCommand": "curl -sS -o /dev/null -w '%{http_code}\\n' http://TARGET:5431/",
"links": [
{
"title": "IANA port registry — 5431 (park-agent)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5431",
"kind": "iana"
}
]
},
{
"port": 5432,
"protocol": "tcp",
"service": "PostgreSQL",
"oneLiner": "PostgreSQL client protocol, TCP 5432.",
"whatItIs": "The postgres server listens on TCP 5432 by default (the `port` parameter), and listen_addresses defaults to localhost, so an out-of-the-box install accepts only loopback TCP plus Unix-domain sockets. Seeing it on a scan means someone set listen_addresses to '*' or a real interface — common for containerized deploys, managed database endpoints, and pgbouncer front-ends. Who may connect from where is then decided by pg_hba.conf, which is a separate gate from the listener.",
"exposure": {
"verdict": "never",
"note": "Keep it on localhost or a private network; if it must cross a network, require hostssl plus scram-sha-256 in pg_hba.conf rather than relying on the port being obscure."
},
"checkCommand": "psql -h DB_HOST -p 5432 -U postgres -c 'SELECT version();'",
"links": [
{
"title": "PostgreSQL docs — Connection Settings (port, listen_addresses)",
"url": "https://www.postgresql.org/docs/current/runtime-config-connection.html",
"kind": "official-docs"
},
{
"title": "PostgreSQL docs — The pg_hba.conf File",
"url": "https://www.postgresql.org/docs/current/auth-pg-hba-conf.html",
"kind": "official-docs"
},
{
"title": "PostgreSQL (GitHub mirror)",
"url": "https://github.com/postgres/postgres",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 5440,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned at IANA — no registered service, and nothing standard listens here.",
"whatItIs": "The registry lists 5438-5442 as unassigned, so 5440 has no service name and no owner. Its neighbours are busy — 5432 is PostgreSQL, 5443 is registered to Pearson — but the port itself is claimed only by whatever application an operator points at it. Identify the process rather than reading anything into the number.",
"exposure": {
"verdict": "careful",
"note": "No registration means no assumptions: an open 5440 is an application someone chose, and it should be reviewed on its own terms."
},
"checkCommand": "sudo lsof -nP -iTCP:5440 -sTCP:LISTEN",
"links": [
{
"title": "IANA port registry — 5440 (unassigned)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5440",
"kind": "iana"
}
]
},
{
"port": 5500,
"protocol": "tcp",
"service": "VNC listening viewer (IANA: fcp-addr-srvr1)",
"oneLiner": "Usually a VNC viewer in listening mode, waiting for a remote desktop to connect back to it.",
"whatItIs": "IANA registers 5500 as fcp-addr-srvr1, a name you will essentially never meet. The real-world use is reverse VNC: run vncviewer -listen and the viewer listens on 5500 so a server behind NAT can dial out to the support technician instead of the other way round. That inverts the usual direction of 5900, which is why 5500 shows up on helpdesk workstations rather than on servers. Legacy RSA ACE/Server installations also used UDP 5500 for authentication requests, per their shipped services file.",
"exposure": {
"verdict": "never",
"note": "A listening VNC viewer accepts an inbound desktop session from anyone who reaches it, and classic RFB gives you no transport encryption — restrict it to a VPN or an SSH tunnel."
},
"checkCommand": "sudo lsof -nP -iTCP:5500 -sTCP:LISTEN",
"links": [
{
"title": "TigerVNC — vncviewer(1), listening mode on port 5500",
"url": "https://tigervnc.org/doc/vncviewer.html",
"kind": "official-docs"
},
{
"title": "IANA port registry — 5500 (fcp-addr-srvr1)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5500",
"kind": "iana"
}
]
},
{
"port": 5510,
"protocol": "tcp",
"service": "Legacy RSA ACE/Server replica sync (unassigned at IANA)",
"oneLiner": "Unassigned today; historically part of RSA ACE/Server's replica synchronisation block.",
"whatItIs": "IANA lists 5508-5539 as unassigned, so 5510 has no current registration. Its historical use comes from RSA ACE/Server (later Authentication Manager), whose shipped services file allocated securidprop_00 through securidprop_10 across 5505-5515 for server-to-replica synchronisation, with 5510 serving replica 5. Outside a legacy SecurID deployment, an open 5510 is some application's own choice of port.",
"exposure": {
"verdict": "never",
"note": "If this is SecurID replication, it is authentication-infrastructure traffic between servers and belongs on an internal segment only."
},
"checkCommand": "sudo lsof -nP -iTCP:5510 -sTCP:LISTEN",
"links": [
{
"title": "RSA — annotated example of the ACE/Server services file",
"url": "https://community.rsa.com/t5/securid-knowledge-base/correct-and-annotated-example-of-rsa-ace-server-services-file/ta-p/8600",
"kind": "official-docs"
},
{
"title": "IANA port registry — 5510 (unassigned)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5510",
"kind": "iana"
}
]
},
{
"port": 5544,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned at IANA, with no service that has claimed it in practice.",
"whatItIs": "IANA marks 5544-5549 as unassigned. There is no registered service name, no RFC, and no widely deployed product that defaults here. Anything listening on 5544 was configured that way deliberately, so the process on the host is the only source of truth.",
"exposure": {
"verdict": "careful",
"note": "Treat an unidentified listener as unreviewed until you know which program opened it and what it authenticates with."
},
"checkCommand": "sudo lsof -nP -iTCP:5544 -sTCP:LISTEN",
"links": [
{
"title": "IANA port registry — 5544 (unassigned)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5544",
"kind": "iana"
}
]
},
{
"port": 5550,
"protocol": "tcp",
"service": "CBUS model railway control (formerly RSA sdadmind)",
"oneLiner": "Registered since 2017 to a model-railway control protocol; before that, RSA's remote admin daemon.",
"whatItIs": "IANA reassigned 5550/tcp in 2017 to CBUS, the MERG (Model Electronic Railway Group) message protocol for controlling model railway layouts over a network. The earlier occupant, still present in old services files and firewall rules, is sdadmind, RSA ACE/Server's remote administration daemon. UDP 5550 is reserved. Which one you are looking at depends entirely on the host: a hobby layout controller or a legacy SecurID server.",
"exposure": {
"verdict": "never",
"note": "Both plausible occupants are control planes — layout control or authentication-server administration — and neither should be reachable from the internet."
},
"checkCommand": "nc -vz -w 3 TARGET 5550",
"links": [
{
"title": "MERG — CBUS layout control protocol",
"url": "https://www.merg.org.uk/merg_wiki/doku.php?id=cbus:cbus",
"kind": "official-docs"
},
{
"title": "RSA — annotated example of the ACE/Server services file (sdadmind 5550)",
"url": "https://community.rsa.com/t5/securid-knowledge-base/correct-and-annotated-example-of-rsa-ace-server-services-file/ta-p/8600",
"kind": "official-docs"
},
{
"title": "IANA port registry — 5550 (cbus)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5550",
"kind": "iana"
}
]
},
{
"port": 5555,
"protocol": "tcp",
"service": "Android Debug Bridge over TCP/IP",
"oneLiner": "Nearly always ADB on an Android device — an unauthenticated shell if the device is old enough.",
"whatItIs": "Running adb tcpip 5555 puts an Android device's debug bridge on the network, and 5555 is the classic default that phones, TV boxes, and dev boards land on. On pre-Android-11 devices there is no pairing code and no on-device prompt, so anyone who reaches the port can run adb connect and get a shell, install packages, and pull data; that gap is what the 2018 ADB.Miner worm mass-exploited. IANA registers the port as personal-agent and flags known unauthorised use. HP/HPE Data Protector also used 5555 for its Inet client service before version 10 moved to 5565.",
"exposure": {
"verdict": "never",
"note": "An internet-reachable 5555 on a legacy Android device is a full compromise waiting to happen — no authentication stands between the port and a root-capable shell."
},
"checkCommand": "adb connect TARGET:5555",
"links": [
{
"title": "Android — adb, connecting over Wi-Fi",
"url": "https://developer.android.com/tools/adb",
"kind": "official-docs"
},
{
"title": "Data Protector — port usage (Inet)",
"url": "https://docs.microfocus.com/doc/data_protector/24.1/portusage",
"kind": "official-docs"
},
{
"title": "IANA port registry — 5555 (personal-agent)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5555",
"kind": "iana"
}
]
},
{
"port": 5560,
"protocol": "tcp",
"service": "Oracle iSQL*Plus (unassigned at IANA)",
"oneLiner": "An Oracle 10g database with the browser-based iSQL*Plus console still running.",
"whatItIs": "IANA lists 5558-5564 as unassigned. The use that put 5560 on port lists is Oracle iSQL*Plus, the browser front-end to SQL*Plus, which Oracle 10g served from an OC4J instance at http://host:5560/isqlplus/; the actual port for an installation is recorded in $ORACLE_HOME/install/portlist.ini. Oracle dropped iSQL*Plus after 10g, so a live 5560 means an old database server. Legacy RSA ACE/Server services files also placed sdlockmgr, its lock manager, on this port.",
"exposure": {
"verdict": "never",
"note": "iSQL*Plus is a web login straight into a database over plain HTTP — exposing it publishes both the credentials and the SQL console."
},
"checkCommand": "curl -sS -o /dev/null -w '%{http_code}\\n' http://TARGET:5560/isqlplus/",
"links": [
{
"title": "Oracle Database 10g — Starting SQL*Plus and iSQL*Plus (port 5560)",
"url": "https://docs.oracle.com/cd/B19306_01/server.102/b14357/ch3.htm",
"kind": "official-docs"
},
{
"title": "IANA port registry — 5560 (unassigned)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5560",
"kind": "iana"
}
]
},
{
"port": 5566,
"protocol": "tcp",
"service": "Westec Connect (westec-connect)",
"oneLiner": "Registered in 2009 to a commercial video-surveillance service and rarely seen anywhere else.",
"whatItIs": "IANA registered 5566/tcp in 2009 as westec-connect, for Westec Intelligent Surveillance's managed video product; UDP 5566 is reserved rather than assigned. No protocol description was published, and no common software defaults to this port. Open on a host that is not part of a Westec installation, it is simply an application someone assigned there.",
"exposure": {
"verdict": "careful",
"note": "If it really is surveillance connectivity, video and camera control are sensitive traffic — confirm what is listening before letting it out."
},
"checkCommand": "nc -vz -w 3 TARGET 5566",
"links": [
{
"title": "IANA port registry — 5566 (westec-connect)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5566",
"kind": "iana"
}
]
},
{
"port": 5631,
"protocol": "tcp",
"service": "pcAnywhere data (pcanywheredata)",
"oneLiner": "Symantec pcAnywhere's remote-control data channel — on a modern network, a stranded legacy host.",
"whatItIs": "5631/tcp carries the session data for Symantec pcAnywhere remote control, paired with 5632/udp, which answers host discovery broadcasts and is how scanners enumerate pcAnywhere hosts. Symantec discontinued the product after its source code leaked in 2012, and at the time advised customers to disable it until patched. Anything still answering here is an unmaintained remote-control host, typically on an old Windows server or an industrial machine nobody has touched in years.",
"exposure": {
"verdict": "never",
"note": "Discontinued, unpatched remote-desktop software with a history of weak authentication — an internet-facing 5631 is a standing invitation."
},
"checkCommand": "nc -vz -w 3 TARGET 5631",
"links": [
{
"title": "IANA port registry — 5631 (pcanywheredata)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5631",
"kind": "iana"
}
]
},
{
"port": 5633,
"protocol": "both",
"service": "Backup Exec Operations Request Listener (beorl)",
"oneLiner": "A Veritas Backup Exec server listening for DBA-initiated Oracle and DB2 backup jobs.",
"whatItIs": "IANA registered 5633 in 2006 as beorl, the BE Operations Request Listener, part of Symantec's — now Veritas' — Backup Exec. The media server opens it so database administrators can start Oracle and DB2 backups from the database host rather than from the backup console. On a scan it identifies the machine as a backup server, which is exactly the machine an attacker wants.",
"exposure": {
"verdict": "never",
"note": "Backup infrastructure holds copies of everything; the listener belongs on the internal backup network, reachable only from the database hosts that need it."
},
"checkCommand": "nc -vz -w 3 TARGET 5633",
"links": [
{
"title": "IANA port registry — 5633 (beorl)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5633",
"kind": "iana"
}
]
},
{
"port": 5666,
"protocol": "tcp",
"service": "NRPE (Nagios Remote Plugin Executor)",
"oneLiner": "A monitoring agent — the Nagios server connects here to run checks on this host.",
"whatItIs": "NRPE runs on a monitored machine and executes local plugins (disk, load, process checks) on request from a Nagios, Icinga, or Naemon server, returning the status text and exit code. IANA registered 5666 to Nagios Enterprises in 2017. Access control is a plaintext allowed_hosts list plus, in NRPE 3 and later, TLS — but the default anonymous-DH mode encrypts without authenticating either side. Enabling dont_blame_nrpe so callers may pass arguments has repeatedly turned into remote command execution.",
"exposure": {
"verdict": "never",
"note": "It exists to run commands on the host for whoever asks — restrict it to the monitoring server's address, keep command arguments disabled, and never publish it."
},
"checkCommand": "check_nrpe -H TARGET",
"links": [
{
"title": "NagiosEnterprises/nrpe",
"url": "https://github.com/NagiosEnterprises/nrpe",
"kind": "github"
},
{
"title": "IANA port registry — 5666 (nrpe)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5666",
"kind": "iana"
}
]
},
{
"port": 5678,
"protocol": "tcp",
"service": "n8n (IANA: rrac)",
"oneLiner": "Registered as rrac, but on a modern host an open 5678 is almost always n8n's editor and webhook listener.",
"whatItIs": "IANA assigns 5678 to rrac, \"Remote Replication Agent Connection\", a name you will effectively never meet in the wild. What actually listens there today is n8n, the self-hosted workflow-automation server: N8N_PORT defaults to 5678 and the official Docker image publishes it. That one port serves both the editor UI and the webhook URLs that fire workflows, so it is simultaneously an admin console and a public-facing trigger surface. On a container host, 5678 is n8n until proven otherwise.",
"exposure": {
"verdict": "never",
"note": "The n8n editor runs arbitrary code and holds stored credentials for every service it integrates with, and it speaks plain HTTP. Put it behind a reverse proxy with TLS and authentication rather than on a public IP."
},
"checkCommand": "curl -sS -o /dev/null -w '%{http_code}\\n' http://TARGET:5678/",
"links": [
{
"title": "n8n docs — deployment environment variables (N8N_PORT, default 5678)",
"url": "https://docs.n8n.io/deploy/host-n8n/configure-n8n/basic-configuration/use-environment-variables/deployment",
"kind": "official-docs"
},
{
"title": "n8n-io/n8n",
"url": "https://github.com/n8n-io/n8n",
"kind": "github"
},
{
"title": "IANA port registry — 5678 (rrac)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5678",
"kind": "iana"
}
]
},
{
"port": 5679,
"protocol": "tcp",
"service": "dccm (Direct Cable Connect Manager)",
"oneLiner": "A dead registration — Direct Cable Connect Manager — with nothing in common use behind it.",
"whatItIs": "IANA registers 5679 as dccm, \"Direct Cable Connect Manager\", assigned to an individual and tied to the direct-cable networking era of consumer Windows. No widely deployed software listens here now. If 5679 is open on a machine you own, it belongs to some local application that picked the number, so identify it by process rather than by the registry.",
"exposure": {
"verdict": "careful",
"note": "Nothing well-known claims this port, so an open 5679 is an unidentified service. Find the owning process before deciding whether it may be reachable."
},
"checkCommand": "sudo lsof -nP -iTCP:5679 -sTCP:LISTEN",
"links": [
{
"title": "IANA port registry — 5679 (dccm)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5679",
"kind": "iana"
}
]
},
{
"port": 5718,
"protocol": "tcp",
"service": "Microsoft DPM (backup agent channel)",
"oneLiner": "System Center Data Protection Manager talking to the backup agents on the machines it protects.",
"whatItIs": "IANA registers 5718 as dpm, \"DPM Communication Server\", for Microsoft System Center Data Protection Manager. Microsoft's firewall guidance pairs it with 5719: DPM communicates with the agent coordinator on 5718 and with the protection agent on 5719, and both ends open connections so that synchronization and recovery can run in either direction. You see it only inside a Windows domain running SCDPM — on the DPM server itself and on every protected file server, SQL host, or Hyper-V host.",
"exposure": {
"verdict": "never",
"note": "This is the control channel for a backup system that can read and restore everything on the protected hosts. It belongs entirely inside the domain, never across a perimeter."
},
"checkCommand": "nc -vz -w 3 TARGET 5718",
"links": [
{
"title": "Microsoft — Configuring Firewalls for DPM (5718/5719 data channel)",
"url": "https://learn.microsoft.com/en-us/previous-versions/system-center/data-protection-manager-2010/ff399341(v=technet.10)",
"kind": "official-docs"
},
{
"title": "IANA port registry — 5718 (dpm)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5718",
"kind": "iana"
}
]
},
{
"port": 5730,
"protocol": "tcp",
"service": "unieng (Steltor calendar access)",
"oneLiner": "An old calendar-server registration; nothing in current use listens here.",
"whatItIs": "IANA assigns 5730 to unieng, described in the registry as \"Steltor's calendar access\". Steltor was a calendar-software vendor and the registration dates from that product's lifetime; no widely deployed software uses this port today. An open 5730 in 2026 is an application that chose the number for itself, not the registered service, so confirm it by process.",
"exposure": {
"verdict": "careful",
"note": "An unidentified listener on a port with a defunct registration. Establish what owns it before allowing anything to reach it."
},
"checkCommand": "sudo lsof -nP -iTCP:5730 -sTCP:LISTEN",
"links": [
{
"title": "IANA port registry — 5730 (unieng)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5730",
"kind": "iana"
}
]
},
{
"port": 5800,
"protocol": "tcp",
"service": "VNC over HTTP (display :0)",
"oneLiner": "A VNC server's built-in web server, handing a browser the Java applet viewer for display :0.",
"whatItIs": "Classic VNC servers — RealVNC, TightVNC, UltraVNC, x11vnc — embed a small HTTP server at 5800 plus the display number, so display :0 answers on 5800. Fetch it and you get an HTML page plus a Java applet that then opens its own RFB connection to 5900. The applet half is dead in practice since browsers removed NPAPI Java, but the listener survives in older installs and is a dependable fingerprint that a VNC server is running next door. IANA has never assigned 5800; the whole convention comes from the VNC implementations.",
"exposure": {
"verdict": "never",
"note": "It advertises a VNC server to anyone who loads the page, and the RFB service it fronts authenticates with a DES challenge over a key truncated to 8 characters, with no transport encryption. Reach VNC over SSH or a VPN instead."
},
"checkCommand": "curl -sS -o /dev/null -w '%{http_code}\\n' http://TARGET:5800/",
"links": [
{
"title": "x11vnc — -http option, \"port 5800 and allow the Java vncviewer to be downloaded\"",
"url": "https://github.com/LibVNC/x11vnc/blob/master/src/help.c",
"kind": "github"
},
{
"title": "RFC 6143 — The Remote Framebuffer Protocol",
"url": "https://datatracker.ietf.org/doc/html/rfc6143",
"kind": "spec"
},
{
"title": "IANA port registry — 5800 (unassigned)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5800",
"kind": "iana"
}
]
},
{
"port": 5801,
"protocol": "tcp",
"service": "VNC over HTTP (display :1)",
"oneLiner": "The same VNC web-viewer port as 5800, one display up: display :1.",
"whatItIs": "VNC servers place their HTTP viewer listener at 5800 plus the display number, so 5801 is display :1 — the first display a Linux `vncserver` normally creates for a user. The page it serves is a Java applet that connects onward to the matching RFB port, 5901. IANA has never assigned 5801; seeing it open means a VNC server with a per-user display is running, and 5901 is almost certainly open too.",
"exposure": {
"verdict": "never",
"note": "Same problem as 5800: it publicly identifies a VNC server whose RFB authentication is weak and unencrypted. Keep both this and 5901 on the loopback or behind an SSH tunnel."
},
"checkCommand": "curl -sS -o /dev/null -w '%{http_code}\\n' http://TARGET:5801/",
"links": [
{
"title": "x11vnc — -http option, Java vncviewer download on the 5800+display port",
"url": "https://github.com/LibVNC/x11vnc/blob/master/src/help.c",
"kind": "github"
},
{
"title": "TigerVNC — the VNC/RFB server most Linux distributions ship",
"url": "https://github.com/TigerVNC/tigervnc",
"kind": "github"
},
{
"title": "IANA port registry — 5801 (unassigned)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5801",
"kind": "iana"
}
]
},
{
"port": 5802,
"protocol": "tcp",
"service": "VNC over HTTP (display :2)",
"oneLiner": "VNC's web-viewer port for display :2 — the second per-user desktop on a shared host.",
"whatItIs": "5802 is 5800 plus display 2, the HTTP listener a VNC server opens alongside RFB on 5902. It shows up on multi-user Linux boxes where several people each run their own `vncserver` session, so displays climb :1, :2, :3 and the HTTP and RFB ports climb with them. The port is unassigned at IANA and exists purely by VNC convention.",
"exposure": {
"verdict": "never",
"note": "A second exposed desktop is not safer than the first. Bind VNC to localhost and reach it over SSH."
},
"checkCommand": "curl -sS -o /dev/null -w '%{http_code}\\n' http://TARGET:5802/",
"links": [
{
"title": "x11vnc — -http option, Java vncviewer download on the 5800+display port",
"url": "https://github.com/LibVNC/x11vnc/blob/master/src/help.c",
"kind": "github"
},
{
"title": "IANA port registry — 5802 (unassigned)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5802",
"kind": "iana"
}
]
},
{
"port": 5810,
"protocol": "tcp",
"service": "Unassigned (VNC HTTP display :10 by convention)",
"oneLiner": "Unassigned at IANA; by VNC's 5800+display arithmetic it would be the web viewer for display :10.",
"whatItIs": "IANA has no registration for 5810 and no widely deployed product claims it. The only systematic reason it appears is VNC's convention of putting the HTTP viewer at 5800 plus the display number, which makes 5810 display :10 with RFB on 5910. Display numbers that high are uncommon, so an open 5810 is at least as likely to be an unrelated in-house or vendor application. Identify it by process or by what it answers, not by the number.",
"exposure": {
"verdict": "careful",
"note": "Unregistered and unidentified. If it turns out to be a VNC HTTP listener, treat it as never-expose; otherwise find the owning process before allowing it through a firewall."
},
"checkCommand": "sudo lsof -nP -iTCP:5810 -sTCP:LISTEN",
"links": [
{
"title": "IANA port registry — 5810 (unassigned)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5810",
"kind": "iana"
}
]
},
{
"port": 5811,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "No IANA registration and no common service — an open 5811 is whatever local application claimed it.",
"whatItIs": "5811 sits in a gap of the IANA registry: 5813 (icmpd) and 5814 (spt-automation) are registered, but 5811 is not, and no mainstream product defaults to it. Under VNC's 5800+display convention it would correspond to display :11, which is rare in practice. Treat a hit here as an unknown service and identify it directly.",
"exposure": {
"verdict": "careful",
"note": "An unknown listener deserves no default trust. Confirm the process and its authentication before exposing it anywhere."
},
"checkCommand": "sudo lsof -nP -iTCP:5811 -sTCP:LISTEN",
"links": [
{
"title": "IANA port registry — 5811 (unassigned)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5811",
"kind": "iana"
}
]
},
{
"port": 5815,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned at IANA, immediately above the icmpd and Support Automation registrations, with nothing standard on it.",
"whatItIs": "The registry assigns 5813 to icmpd and 5814 to spt-automation, and then stops — 5815 has no entry and no widely deployed default. Nothing about the number implies a protocol, so an open 5815 tells you only that some application on the host chose it. VNC's 5800+display rule would make it display :15, which is unusual enough not to be a safe assumption.",
"exposure": {
"verdict": "careful",
"note": "Unregistered and therefore unidentified from the port alone. Establish what is listening before deciding on exposure."
},
"checkCommand": "sudo lsof -nP -iTCP:5815 -sTCP:LISTEN",
"links": [
{
"title": "IANA port registry — 5815 (unassigned)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5815",
"kind": "iana"
}
]
},
{
"port": 5822,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "No registration, no standard service — the number is free real estate that local software sometimes takes.",
"whatItIs": "IANA lists no service for 5822; its neighbours 5820 (autopassdaemon, OpenText licensing) and 5825 are the nearest activity, and neither implies anything about 5822. No mainstream server defaults here. If your scan finds it, the answer lives in the process table of the host, not in any registry.",
"exposure": {
"verdict": "careful",
"note": "Unknown service. Identify it, then judge exposure on what it actually does rather than on the port number."
},
"checkCommand": "sudo lsof -nP -iTCP:5822 -sTCP:LISTEN",
"links": [
{
"title": "IANA port registry — 5822 (unassigned)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5822",
"kind": "iana"
}
]
},
{
"port": 5825,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unregistered with IANA and not the default for any widely used software.",
"whatItIs": "There is no IANA assignment for 5825 and no common product that binds to it out of the box. Ports in this stretch of the registered range are sparsely allocated, so gaps like this get picked up ad hoc by internal tools, test harnesses, and vendor agents. The only honest identification method is to look at the process holding the socket or to see what the service says when you connect.",
"exposure": {
"verdict": "careful",
"note": "No known protocol means no known authentication story. Do not open it at a firewall until you know what answers."
},
"checkCommand": "sudo lsof -nP -iTCP:5825 -sTCP:LISTEN",
"links": [
{
"title": "IANA port registry — 5825 (unassigned)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5825",
"kind": "iana"
}
]
},
{
"port": 5850,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "No IANA registration and no established service; a round number that ad hoc software likes.",
"whatItIs": "5850 has no entry in the IANA service registry and no widely deployed default. Round numbers like this get chosen by hand for internal services, staging deployments, and one-off proxies, which is the usual explanation for finding one open. Nothing about the port number itself tells you the protocol, so probe the service or check the process.",
"exposure": {
"verdict": "careful",
"note": "An unidentified listener, most likely something internal that was never designed to face the internet. Confirm before exposing."
},
"checkCommand": "sudo lsof -nP -iTCP:5850 -sTCP:LISTEN",
"links": [
{
"title": "IANA port registry — 5850 (unassigned)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5850",
"kind": "iana"
}
]
},
{
"port": 5859,
"protocol": "tcp",
"service": "wherehoo (WHEREHOO)",
"oneLiner": "Registered to WHEREHOO, a location-service project from the early 2000s that no longer exists in the wild.",
"whatItIs": "IANA assigns 5859 to wherehoo, \"WHEREHOO\", registered by Jim Youll for a location-oriented service of that name. The project is long defunct and there is no deployed base to speak of, so the registration is history rather than a description of what runs there. An open 5859 today is some other application that took an unclaimed-looking number.",
"exposure": {
"verdict": "careful",
"note": "The registered service is dead, so anything listening is unidentified. Find the process rather than trusting the registry name."
},
"checkCommand": "sudo lsof -nP -iTCP:5859 -sTCP:LISTEN",
"links": [
{
"title": "IANA port registry — 5859 (wherehoo)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5859",
"kind": "iana"
}
]
},
{
"port": 5862,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned at IANA, sitting one below the PlanetPress Suite Messenger registration on 5863.",
"whatItIs": "IANA registers 5863 to ppsuitemsg (PlanetPress Suite Messenger) but leaves 5862 empty, and no common product defaults to it. Adjacency is not evidence — a service on 5862 has no necessary relationship to its registered neighbour. As with the rest of the unassigned 58xx block, identify the listener directly.",
"exposure": {
"verdict": "careful",
"note": "Unknown service on an unregistered port. Determine what it is before allowing traffic to it."
},
"checkCommand": "sudo lsof -nP -iTCP:5862 -sTCP:LISTEN",
"links": [
{
"title": "IANA port registry — 5862 (unassigned)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5862",
"kind": "iana"
}
]
},
{
"port": 5877,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "No IANA registration and no notable service — an open 5877 is a local choice, not a protocol.",
"whatItIs": "5877 is unassigned in the IANA registry and is not the documented default of any widely used server. The surrounding numbers are thinly allocated, which is exactly why gaps here get taken by internal tooling and vendor agents. The port number carries no information about the protocol, so read it off the process or the service banner.",
"exposure": {
"verdict": "careful",
"note": "Unidentified listener. Establish the owning process and its authentication before deciding it can be reachable."
},
"checkCommand": "sudo lsof -nP -iTCP:5877 -sTCP:LISTEN",
"links": [
{
"title": "IANA port registry — 5877 (unassigned)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5877",
"kind": "iana"
}
]
},
{
"port": 5900,
"protocol": "tcp",
"service": "VNC (RFB)",
"oneLiner": "A VNC server — someone's desktop is available for remote control on display :0.",
"whatItIs": "RFB is the wire protocol behind VNC, and 5900 is display :0 (5901 is :1, and so on up). You will find it on macOS with Screen Sharing enabled, on Linux hosts running TigerVNC, x11vnc, or a Raspberry Pi with RealVNC, and on hypervisor consoles from QEMU/KVM, Proxmox, and ESXi. The server greets every connection with a plaintext version banner such as RFB 003.008 before any authentication happens, which makes it trivial to fingerprint.",
"exposure": {
"verdict": "never",
"note": "Classic VNC authentication is a challenge-response over a DES key truncated to 8 characters with no transport encryption, and many servers permit no auth at all — tunnel it over SSH or a VPN instead."
},
"checkCommand": "nc -w 3 TARGET 5900 | head -c 12; echo",
"links": [
{
"title": "RFC 6143 — The Remote Framebuffer Protocol",
"url": "https://datatracker.ietf.org/doc/html/rfc6143",
"kind": "spec"
},
{
"title": "IANA port registry — 5900 (rfb)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5900",
"kind": "iana"
},
{
"title": "TigerVNC/tigervnc",
"url": "https://github.com/TigerVNC/tigervnc",
"kind": "github"
}
]
},
{
"port": 5901,
"protocol": "tcp",
"service": "VNC (RFB) display :1",
"oneLiner": "A VNC server on display :1 — the standard first per-user desktop on a Linux box.",
"whatItIs": "RFB uses 5900 plus the display number, so 5901 is display :1. On Linux this is the most common VNC port of all, because `vncserver` allocates :1 to the first user who starts a session, ahead of :0 which is usually the physical console. TigerVNC, TightVNC, and x11vnc all land here. The server answers every connection with a plaintext version banner such as `RFB 003.008` before authentication, so it is trivial to identify.",
"exposure": {
"verdict": "never",
"note": "VNC authentication is a challenge-response over a DES key truncated to 8 characters, with the session itself unencrypted, and many servers are configured with no auth at all. Bind it to localhost and forward it over SSH."
},
"checkCommand": "nc -w 3 TARGET 5901 | head -c 12; echo",
"links": [
{
"title": "RFC 6143 — The Remote Framebuffer Protocol",
"url": "https://datatracker.ietf.org/doc/html/rfc6143",
"kind": "spec"
},
{
"title": "TigerVNC/tigervnc",
"url": "https://github.com/TigerVNC/tigervnc",
"kind": "github"
},
{
"title": "IANA port registry — 5901 (unassigned; 5900 is rfb)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5901",
"kind": "iana"
}
]
},
{
"port": 5902,
"protocol": "tcp",
"service": "VNC (RFB) display :2",
"oneLiner": "A second VNC desktop on the same host — display :2.",
"whatItIs": "5902 is 5900 plus display 2. Finding it open means the host is running more than one VNC session at once: a second user on a shared Linux machine, a second virtual machine console on a KVM or Proxmox host, or a second `vncserver` instance for a different desktop environment. The protocol is identical to 5900 and 5901 — a plaintext RFB version banner, then authentication.",
"exposure": {
"verdict": "never",
"note": "Every additional VNC display multiplies the same weak, unencrypted authentication surface. Keep all of them on the loopback interface behind SSH or a VPN."
},
"checkCommand": "nc -w 3 TARGET 5902 | head -c 12; echo",
"links": [
{
"title": "RFC 6143 — The Remote Framebuffer Protocol",
"url": "https://datatracker.ietf.org/doc/html/rfc6143",
"kind": "spec"
},
{
"title": "TigerVNC/tigervnc",
"url": "https://github.com/TigerVNC/tigervnc",
"kind": "github"
},
{
"title": "IANA port registry — 5902 (unassigned; 5900 is rfb)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5902",
"kind": "iana"
}
]
},
{
"port": 5903,
"protocol": "tcp",
"service": "ff-ice (ICAO) / VNC display :3 in practice",
"oneLiner": "Registered to ICAO for flight-information exchange, but on a live host it is VNC display :3.",
"whatItIs": "IANA assigns 5903 to ff-ice, \"Flight & Flow Info for Collaborative Env\", one of a block of ports the International Civil Aviation Organisation registered for aeronautical data services over TCP, UDP, and SCTP. Those systems run on private aviation networks, not on the internet, so you will not meet them on an ordinary scan. What you will meet is VNC: 5900 plus display 3, a third simultaneous remote desktop or hypervisor console on the host.",
"exposure": {
"verdict": "never",
"note": "If it is VNC, it inherits the unencrypted, weakly authenticated RFB session and should stay on the loopback. If it genuinely is an ICAO service, it belongs on a private aeronautical network by definition."
},
"checkCommand": "nc -w 3 TARGET 5903 | head -c 12; echo",
"links": [
{
"title": "IANA port registry — 5903 (ff-ice)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5903",
"kind": "iana"
},
{
"title": "RFC 6143 — The Remote Framebuffer Protocol",
"url": "https://datatracker.ietf.org/doc/html/rfc6143",
"kind": "spec"
}
]
},
{
"port": 5904,
"protocol": "tcp",
"service": "ag-swim (ICAO) / VNC display :4 in practice",
"oneLiner": "IANA calls it Air-Ground SWIM; in the field it is VNC display :4.",
"whatItIs": "The registered service on 5904 is ag-swim, \"Air-Ground SWIM\", part of ICAO's block of aeronautical registrations (5903 through 5914) for System Wide Information Management traffic between aircraft and ground systems. Those run on dedicated aviation networks. On a general-purpose host, 5904 is 5900 plus display 4 — a fourth VNC desktop or VM console, common on hypervisors that allocate one console port per running guest.",
"exposure": {
"verdict": "never",
"note": "Hypervisor VNC consoles hand whoever connects a keyboard and screen attached to the guest, often with no password at all. Restrict them to the management network."
},
"checkCommand": "nc -w 3 TARGET 5904 | head -c 12; echo",
"links": [
{
"title": "IANA port registry — 5904 (ag-swim)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5904",
"kind": "iana"
},
{
"title": "RFC 6143 — The Remote Framebuffer Protocol",
"url": "https://datatracker.ietf.org/doc/html/rfc6143",
"kind": "spec"
}
]
},
{
"port": 5906,
"protocol": "tcp",
"service": "rpas-c2 (ICAO) / VNC display :6 in practice",
"oneLiner": "Registered for remotely piloted aircraft command and control; in practice, VNC display :6.",
"whatItIs": "IANA assigns 5906 to rpas-c2, \"Remotely Piloted Vehicle C&C\", registered by ICAO for the command-and-control link of remotely piloted aircraft systems. That is aviation infrastructure on private networks, not something a scanner meets. On an ordinary server, 5906 is the RFB port for display :6, typically the sixth VM console on a busy KVM or Proxmox host.",
"exposure": {
"verdict": "never",
"note": "Whichever it is, it is a control plane — a guest's console or an aircraft C2 link. Neither belongs on a public interface."
},
"checkCommand": "nc -w 3 TARGET 5906 | head -c 12; echo",
"links": [
{
"title": "IANA port registry — 5906 (rpas-c2)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5906",
"kind": "iana"
},
{
"title": "RFC 6143 — The Remote Framebuffer Protocol",
"url": "https://datatracker.ietf.org/doc/html/rfc6143",
"kind": "spec"
}
]
},
{
"port": 5907,
"protocol": "tcp",
"service": "dsd (ICAO) / VNC display :7 in practice",
"oneLiner": "IANA lists a distress-and-safety data application; on a real host it is VNC display :7.",
"whatItIs": "5907 is registered as dsd, \"Distress and Safety Data App\", another entry in ICAO's aeronautical block. Like its neighbours it lives on aviation networks and does not appear on general internet scans. The realistic explanation for an open 5907 is VNC at 5900 plus display 7 — a seventh remote desktop or virtual machine console.",
"exposure": {
"verdict": "never",
"note": "Treat it as VNC until proven otherwise, which means unencrypted framebuffer traffic and weak authentication that should never leave a trusted network."
},
"checkCommand": "nc -w 3 TARGET 5907 | head -c 12; echo",
"links": [
{
"title": "IANA port registry — 5907 (dsd)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5907",
"kind": "iana"
},
{
"title": "RFC 6143 — The Remote Framebuffer Protocol",
"url": "https://datatracker.ietf.org/doc/html/rfc6143",
"kind": "spec"
}
]
},
{
"port": 5910,
"protocol": "tcp",
"service": "ats-atn (ICAO) / VNC display :10 in practice",
"oneLiner": "Registered for air traffic services over the ATN; in the wild it is VNC display :10.",
"whatItIs": "IANA registers 5910 as ats-atn, \"Air Traffic Services applications using ATN\", over TCP and UDP, with a separate SCTP registration named cm (Context Management). These are aeronautical telecommunication network services on private infrastructure. On a normal host, 5910 is 5900 plus display 10 — a hypervisor that has allocated ten guest consoles, or a machine with a long-lived set of VNC sessions.",
"exposure": {
"verdict": "never",
"note": "A double-digit VNC display usually means a virtualization host handing out guest consoles. That is an administrative surface and should be reachable only from the management network."
},
"checkCommand": "nc -w 3 TARGET 5910 | head -c 12; echo",
"links": [
{
"title": "IANA port registry — 5910 (ats-atn / cm)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5910",
"kind": "iana"
},
{
"title": "RFC 6143 — The Remote Framebuffer Protocol",
"url": "https://datatracker.ietf.org/doc/html/rfc6143",
"kind": "spec"
}
]
},
{
"port": 5911,
"protocol": "tcp",
"service": "ats-acars (IANA) / VNC display :11",
"oneLiner": "Registered to an aeronautical ACARS service you will never meet; in practice it is VNC display :11.",
"whatItIs": "IANA assigns TCP/UDP 5911 to `ats-acars`, \"Air Traffic Services applications using ACARS\" (the SCTP side of the same number is `cpdlc`, Controller Pilot Data Link Communication). Those are ICAO datalink registrations for aviation ground/air networks and they do not appear on the public internet. What actually answers here is a VNC server: RFB maps display :N to port 5900+N, so 5911 is display :11, handed out by QEMU/KVM, VirtualBox VRDE, or a multi-user Linux host running one Xvnc per user.",
"exposure": {
"verdict": "never",
"note": "If it is VNC it inherits VNC's problems — a plaintext RFB version banner before auth, and a legacy DES challenge-response capped at 8 password characters. Reach it over SSH or a VPN, not directly."
},
"checkCommand": "nc -w 3 TARGET 5911 | head -c 12; echo",
"links": [
{
"title": "IANA port registry — 5911 (ats-acars, cpdlc)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5911",
"kind": "iana"
},
{
"title": "RFC 6143 — The Remote Framebuffer Protocol",
"url": "https://datatracker.ietf.org/doc/html/rfc6143",
"kind": "spec"
},
{
"title": "TigerVNC/tigervnc",
"url": "https://github.com/TigerVNC/tigervnc",
"kind": "github"
}
]
},
{
"port": 5915,
"protocol": "tcp",
"service": "Unassigned / VNC display :15",
"oneLiner": "IANA leaves 5915 unassigned; anything listening is almost certainly VNC display :15.",
"whatItIs": "IANA marks the whole block 5915-5962 Unassigned, so no service owns this number. The convention that fills it is RFB: a VNC server on display :N listens on 5900+N, which makes 5915 display :15. Hosts that hand out one display per VM or per user — QEMU/KVM, Proxmox (which documented 5900-5999 as its VNC console range), or a box running several Xvnc instances — climb into this range quickly.",
"exposure": {
"verdict": "never",
"note": "An unregistered port in the VNC block is a remote-desktop session by default assumption; classic VNC auth is weak and unencrypted, so keep it behind SSH or a VPN."
},
"checkCommand": "nmap -Pn -sV -p 5915 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "RFC 6143 — The Remote Framebuffer Protocol",
"url": "https://datatracker.ietf.org/doc/html/rfc6143",
"kind": "spec"
},
{
"title": "Proxmox VE — Ports used by Proxmox VE (VNC Web console 5900-5999)",
"url": "https://pve.proxmox.com/wiki/Ports",
"kind": "official-docs"
}
]
},
{
"port": 5922,
"protocol": "tcp",
"service": "Unassigned / VNC display :22",
"oneLiner": "Unassigned by IANA; in the wild it is VNC display :22.",
"whatItIs": "5922 falls inside IANA's Unassigned 5915-5962 block, so nothing has a claim on it. The realistic listener is an RFB server on display :22, since VNC maps display :N onto 5900+N. The number is memorable enough that people also pick it by hand for a VNC session, the way 2222 gets picked for SSH.",
"exposure": {
"verdict": "never",
"note": "Do not expose a VNC display directly. Tunnel it (ssh -L 5922:localhost:5922 TARGET) so authentication and confidentiality come from SSH rather than from RFB."
},
"checkCommand": "nc -w 3 TARGET 5922 | head -c 12; echo",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "RFC 6143 — The Remote Framebuffer Protocol",
"url": "https://datatracker.ietf.org/doc/html/rfc6143",
"kind": "spec"
}
]
},
{
"port": 5925,
"protocol": "tcp",
"service": "Unassigned / VNC display :25",
"oneLiner": "No IANA assignment; a listener here is VNC display :25.",
"whatItIs": "IANA has 5915-5962 as Unassigned, and 5925 carries no service name. RFB's 5900+display rule makes it display :25, which is the kind of number a hypervisor reaches when it has allocated a couple of dozen guest consoles. Nothing else well-known squats on it.",
"exposure": {
"verdict": "never",
"note": "Unauthenticated or weakly authenticated desktop access is the default failure mode of this port range — keep it on loopback or a management VLAN."
},
"checkCommand": "sudo lsof -nP -iTCP:5925 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "RFC 6143 — The Remote Framebuffer Protocol",
"url": "https://datatracker.ietf.org/doc/html/rfc6143",
"kind": "spec"
}
]
},
{
"port": 5950,
"protocol": "tcp",
"service": "Unassigned / VNC display :50",
"oneLiner": "Unassigned by IANA; conventionally VNC display :50.",
"whatItIs": "5950 is inside IANA's Unassigned 5915-5962 range. By the RFB convention it is display :50, and hosts that allocate VNC consoles per VM or per user session can reach that far. Because the number is round, it is also a common hand-picked port for a single dedicated VNC server.",
"exposure": {
"verdict": "never",
"note": "Assume remote desktop until proven otherwise. RFB offers no transport encryption in its classic security types, so it belongs behind SSH or a VPN."
},
"checkCommand": "nmap -Pn -sV -p 5950 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "RFC 6143 — The Remote Framebuffer Protocol",
"url": "https://datatracker.ietf.org/doc/html/rfc6143",
"kind": "spec"
}
]
},
{
"port": 5952,
"protocol": "tcp",
"service": "Unassigned / VNC display :52",
"oneLiner": "No registration; treat it as VNC display :52.",
"whatItIs": "IANA lists nothing for 5952 — it sits in the Unassigned 5915-5962 block. The only convention that reaches it is RFB display numbering, where 5900+52 is display :52. There is no well-documented malware or scanner association specific to this number; it shows up in scan data at roughly the same low rate as its neighbours.",
"exposure": {
"verdict": "careful",
"note": "Nothing standard owns this port, so identify the process before deciding anything — and if it is VNC, do not let it face the internet."
},
"checkCommand": "sudo lsof -nP -iTCP:5952 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "nmap-services — the port-frequency database",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 5959,
"protocol": "tcp",
"service": "Unassigned / VNC display :59",
"oneLiner": "Unassigned by IANA; the plausible listener is VNC display :59.",
"whatItIs": "5959 has no IANA service name; the registry covers it only as part of the Unassigned 5915-5962 range. Under the RFB 5900+display rule it is display :59. Anything else answering here is a private application that simply picked a free high port.",
"exposure": {
"verdict": "never",
"note": "An unidentified listener in the VNC block should not be reachable from untrusted networks; confirm what owns it locally before opening anything."
},
"checkCommand": "nmap -Pn -sV -p 5959 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "RFC 6143 — The Remote Framebuffer Protocol",
"url": "https://datatracker.ietf.org/doc/html/rfc6143",
"kind": "spec"
}
]
},
{
"port": 5960,
"protocol": "tcp",
"service": "Unassigned / VNC display :60",
"oneLiner": "Unassigned; VNC display :60 by convention, nothing else standard.",
"whatItIs": "IANA leaves 5960 unassigned as part of the 5915-5962 block. RFB display numbering makes it :60, which is deep into the range and only reached by hosts running many simultaneous VNC sessions. Beyond that there is no registered service and no well-documented squatter.",
"exposure": {
"verdict": "never",
"note": "Unregistered plus in the VNC block means you cannot infer safety from the number — keep it internal and check the owning process."
},
"checkCommand": "sudo lsof -nP -iTCP:5960 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "RFC 6143 — The Remote Framebuffer Protocol",
"url": "https://datatracker.ietf.org/doc/html/rfc6143",
"kind": "spec"
}
]
},
{
"port": 5961,
"protocol": "tcp",
"service": "Unassigned / VNC display :61",
"oneLiner": "No IANA assignment; VNC display :61 if anything.",
"whatItIs": "5961 sits in IANA's Unassigned 5915-5962 range with no service name or assignee. The only convention that touches it is RFB's 5900+display mapping, giving display :61. Everything else here is ad-hoc: an application that grabbed a free port, or a forwarded tunnel endpoint.",
"exposure": {
"verdict": "never",
"note": "Treat an unknown listener in this block as a remote-control surface until you have identified it; do not publish it."
},
"checkCommand": "nmap -Pn -sV -p 5961 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "nmap-services — the port-frequency database",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 5962,
"protocol": "tcp",
"service": "Unassigned / VNC display :62",
"oneLiner": "The last unassigned number before 5963; conventionally VNC display :62.",
"whatItIs": "5962 is the top of IANA's Unassigned 5915-5962 block — 5963 immediately after it is registered to `indy`. Under the RFB convention it is VNC display :62. No standard service, malware family, or scanner signature is specifically tied to this number.",
"exposure": {
"verdict": "careful",
"note": "No registration means no expectations: find the process that owns it before allowing any inbound access, and if it turns out to be VNC, tunnel it."
},
"checkCommand": "sudo lsof -nP -iTCP:5962 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "RFC 6143 — The Remote Framebuffer Protocol",
"url": "https://datatracker.ietf.org/doc/html/rfc6143",
"kind": "spec"
}
]
},
{
"port": 5963,
"protocol": "tcp",
"service": "indy (Indy Application Server)",
"oneLiner": "Registered in 2004 to \"Indy Application Server\" and essentially never seen since.",
"whatItIs": "IANA assigns TCP and UDP 5963 to `indy`, \"Indy Application Server\", registered by Bjorn Lantz in November 2004. There is no RFC, no public protocol specification, and no widely deployed implementation attached to that name, so the registration is effectively all there is to say. In practice a listener on 5963 is either something private or — given the neighbourhood — a VNC server on display :63.",
"exposure": {
"verdict": "careful",
"note": "You cannot reason about this port from its number, because the registered service is unknown in practice. Identify the owning process first, then decide."
},
"checkCommand": "nmap -Pn -sV -p 5963 TARGET",
"links": [
{
"title": "IANA port registry — 5963 (indy)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5963",
"kind": "iana"
}
]
},
{
"port": 5985,
"protocol": "tcp",
"service": "WinRM / WS-Management over HTTP",
"oneLiner": "Windows Remote Management — the transport behind PowerShell Remoting and winrs.",
"whatItIs": "IANA registers 5985 as `wsman`, WBEM WS-Management over HTTP, and Microsoft adopted it as WinRM's default HTTP listener from WinRM 2.0 onward (Windows 7 / Server 2008 R2), replacing the older port 80 listener. This is what `Enter-PSSession`, `Invoke-Command`, `winrs`, and most configuration-management tooling for Windows actually talk to. No listener exists until someone runs `winrm quickconfig` or enables PowerShell Remoting, so seeing it open means the host is deliberately set up for remote administration — often a domain member, a CI build agent, or an Ansible/Puppet target.",
"exposure": {
"verdict": "never",
"note": "This is a remote-code-execution plane. Even though WinRM applies message-level encryption when Negotiate/Kerberos is used, `AllowUnencrypted` and Basic auth can be switched on, and the service should be reachable only from a management network."
},
"checkCommand": "curl -s -o /dev/null -w '%{http_code}\\n' -m 5 http://TARGET:5985/wsman",
"links": [
{
"title": "Microsoft — Installation and configuration for Windows Remote Management",
"url": "https://learn.microsoft.com/en-us/windows/win32/winrm/installation-and-configuration-for-windows-remote-management",
"kind": "official-docs"
},
{
"title": "Microsoft — Running remote commands (PowerShell Remoting)",
"url": "https://learn.microsoft.com/en-us/powershell/scripting/security/remoting/running-remote-commands",
"kind": "official-docs"
},
{
"title": "DMTF DSP0226 — Web Services for Management (WS-Management)",
"url": "https://www.dmtf.org/sites/default/files/standards/documents/DSP0226_1.2.0.pdf",
"kind": "spec"
},
{
"title": "IANA port registry — 5985 (wsman)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5985",
"kind": "iana"
}
]
},
{
"port": 5986,
"protocol": "tcp",
"service": "WinRM / WS-Management over HTTPS",
"oneLiner": "The TLS-wrapped WinRM listener — same remote-admin plane as 5985, with a certificate in front of it.",
"whatItIs": "IANA registers 5986 as `wsmans`, WS-Management over TLS, and it is WinRM 2.0's default HTTPS listener port. It is created explicitly with `winrm quickconfig -transport:https`, which requires a server certificate whose CN matches the host, so it is common in workgroup and cross-domain scenarios where Kerberos mutual authentication is not available. Because the transport itself is authenticated and encrypted, this is the listener that Ansible's `winrm` connection plugin and most cloud Windows images prefer.",
"exposure": {
"verdict": "never",
"note": "TLS fixes the wire, not the blast radius: a valid credential here is a shell as that user. Restrict source addresses via IPv4Filter/IPv6Filter and the host firewall rather than relying on the certificate alone."
},
"checkCommand": "openssl s_client -connect TARGET:5986 -servername TARGET /dev/null | openssl x509 -noout -subject -dates",
"links": [
{
"title": "Microsoft — Installation and configuration for Windows Remote Management",
"url": "https://learn.microsoft.com/en-us/windows/win32/winrm/installation-and-configuration-for-windows-remote-management",
"kind": "official-docs"
},
{
"title": "DMTF DSP0226 — Web Services for Management (WS-Management)",
"url": "https://www.dmtf.org/sites/default/files/standards/documents/DSP0226_1.2.0.pdf",
"kind": "spec"
},
{
"title": "IANA port registry — 5986 (wsmans)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5986",
"kind": "iana"
}
]
},
{
"port": 5987,
"protocol": "tcp",
"service": "wbem-rmi (WBEM over Java RMI)",
"oneLiner": "A WBEM-over-RMI registration from the DMTF port block, with no meaningful deployment behind it.",
"whatItIs": "IANA assigns 5987 to `wbem-rmi`, registered by Jim Davis alongside the rest of the WBEM block (5985-5990). It was intended for a Java RMI binding to a CIM object manager — the approach Sun's WBEM Services used — but CIM-XML over HTTP on 5988/5989 and WS-Management on 5985/5986 are what implementations actually settled on. A listener here is unusual; when it appears it is typically a Java management agent that opened the whole DMTF block, or an unrelated application on a free port.",
"exposure": {
"verdict": "never",
"note": "Java RMI endpoints deserialize remote objects and have a long history of remote-code-execution flaws, and this one sits in a hardware-management block — keep it off any untrusted network."
},
"checkCommand": "nmap -Pn -sV -p 5987 TARGET",
"links": [
{
"title": "IANA port registry — 5987 (wbem-rmi)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5987",
"kind": "iana"
}
]
},
{
"port": 5988,
"protocol": "tcp",
"service": "WBEM CIM-XML over HTTP",
"oneLiner": "A CIM object manager's cleartext port — hardware and system management over CIM-XML.",
"whatItIs": "IANA registers 5988 as `wbem-http`, the default port for CIM Operations over HTTP (DMTF DSP0200), where XML-encoded CIM method calls are POSTed to a CIM object manager. Real listeners are SFCB, OpenPegasus, and the CIM providers embedded in server hardware and hypervisors — this is how vendor tools read fan speeds, PSU state, and RAID health. On SUSE's SFCB the HTTP port is disabled by default (`enableHttp` is false) and documented as a debugging aid only, which tells you how the maintainers view it.",
"exposure": {
"verdict": "never",
"note": "CIM-XML over plain HTTP authenticates with HTTP Basic, so credentials for a hardware management interface cross the wire in cleartext. Use 5989 instead, and keep both on a management network."
},
"checkCommand": "curl -si -m 5 http://TARGET:5988/cimom | head -1",
"links": [
{
"title": "DMTF DSP0200 — CIM Operations over HTTP",
"url": "https://www.dmtf.org/sites/default/files/standards/documents/DSP0200_1.4.0.pdf",
"kind": "spec"
},
{
"title": "SUSE Linux Enterprise Server — Web-Based Enterprise Management using SFCB",
"url": "https://documentation.suse.com/sles/15-SP6/html/SLES-all/cha-wbem.html",
"kind": "official-docs"
},
{
"title": "IANA port registry — 5988 (wbem-http)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5988",
"kind": "iana"
}
]
},
{
"port": 5989,
"protocol": "tcp",
"service": "WBEM CIM-XML over HTTPS",
"oneLiner": "The TLS port for CIM-XML — the usual way hardware monitoring tools reach a CIM object manager.",
"whatItIs": "IANA registers 5989 as `wbem-https`, CIM Operations over HTTP carried on TLS. This is the port SFCB listens on by default (SUSE documents 5989 as the default secure port), and the one used by OpenPegasus and by CIM providers baked into server BMCs, storage arrays, and hypervisor management agents. Finding it open usually means a physical server or appliance is publishing its hardware inventory and health model to a monitoring system.",
"exposure": {
"verdict": "never",
"note": "It is an out-of-band-style management interface with Basic auth inside the TLS session and often a self-signed certificate — reachable from the monitoring network only, never the internet."
},
"checkCommand": "openssl s_client -connect TARGET:5989 /dev/null | openssl x509 -noout -subject -issuer",
"links": [
{
"title": "DMTF DSP0200 — CIM Operations over HTTP",
"url": "https://www.dmtf.org/sites/default/files/standards/documents/DSP0200_1.4.0.pdf",
"kind": "spec"
},
{
"title": "SUSE Linux Enterprise Server — Web-Based Enterprise Management using SFCB",
"url": "https://documentation.suse.com/sles/15-SP6/html/SLES-all/cha-wbem.html",
"kind": "official-docs"
},
{
"title": "IANA port registry — 5989 (wbem-https)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5989",
"kind": "iana"
}
]
},
{
"port": 5998,
"protocol": "tcp",
"service": "Unassigned (historically NCD X terminal diagnostics)",
"oneLiner": "Unassigned by IANA; historically the diagnostic telnet port of Network Computing Devices X terminals.",
"whatItIs": "IANA lists 5995-5998 as Unassigned, so there is no current owner. The name that persists in scanner databases is `ncd-diag` — nmap still labels 5997/5998/5999 as the preferences, diagnostic and configuration telnet ports of Network Computing Devices X terminals, thin clients from the late 1980s and 1990s. That hardware is long gone, so a listener today is an unrelated application that picked a free port just below 6000.",
"exposure": {
"verdict": "careful",
"note": "No registered service means the port number tells you nothing — identify the process locally before allowing any access. If it genuinely is a telnet-style diagnostic console, treat it as never."
},
"checkCommand": "nmap -Pn -sV -p 5998 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "nmap-services — the port-frequency database",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 5999,
"protocol": "tcp",
"service": "CVSup (also listed as ncd-conf)",
"oneLiner": "The CVSup file-distribution port — FreeBSD's old way of syncing source trees, now retired.",
"whatItIs": "IANA assigns TCP/UDP 5999 to `cvsup`, and the cvsup(1) man page confirms 5999 as the client's default connect port. CVSup was the Modula-3 rsync-alike that mirrored the FreeBSD source, ports and CVS trees for years before the project moved to Subversion, portsnap and eventually Git, so public cvsupd mirrors have been decommissioned. Scanner databases carry a second historical name for this number, `ncd-conf`, the configuration telnet port of Network Computing Devices X terminals; neither service is something you will meet in 2026.",
"exposure": {
"verdict": "careful",
"note": "A real cvsupd served read-only public mirrors and was fine on the internet by design, but nothing runs one now — so anything answering here is unidentified software and should be checked before it is exposed."
},
"checkCommand": "nmap -Pn -sV -p 5999 TARGET",
"links": [
{
"title": "FreeBSD manual pages — cvsup(1)",
"url": "https://man.freebsd.org/cgi/man.cgi?query=cvsup",
"kind": "official-docs"
},
{
"title": "IANA port registry — 5999 (cvsup)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=5999",
"kind": "iana"
}
]
},
{
"port": 6000,
"protocol": "tcp",
"service": "X11 (display :0)",
"oneLiner": "An X server accepting TCP connections on display :0 — the classic \"your desktop is open\" finding.",
"whatItIs": "IANA assigns 6000-6063 to `x11`, the X Window System, one port per display: 6000 is display :0, 6001 is :1, and so on. An X server that has not been told otherwise listens on TCP as well as its Unix socket, and access is decided by a host list (xhost) or a MIT-MAGIC-COOKIE-1 token in ~/.Xauthority. Modern distributions start the server with `-nolisten tcp`, so an open 6000 means someone explicitly re-enabled TCP — usually to make remote GUI apps work without SSH X forwarding.",
"exposure": {
"verdict": "never",
"note": "An X client can read the whole screen, grab the clipboard, and inject synthetic keystrokes. With `xhost +` there is no authentication at all, and the protocol is cleartext regardless — use `ssh -X` instead."
},
"checkCommand": "xdpyinfo -display TARGET:0",
"links": [
{
"title": "X.Org — Xserver(1) manual page (-nolisten, xhost, authorization)",
"url": "https://xorg.freedesktop.org/archive/current/doc/man/man1/Xserver.1.xhtml",
"kind": "official-docs"
},
{
"title": "IANA port registry — 6000-6063 (x11)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=x11",
"kind": "iana"
},
{
"title": "xorg/xserver",
"url": "https://gitlab.freedesktop.org/xorg/xserver",
"kind": "official-docs"
}
]
},
{
"port": 6001,
"protocol": "tcp",
"service": "X11 (display :1)",
"oneLiner": "The second X display — very often an Xvnc or Xvfb server rather than a physical screen.",
"whatItIs": "6001 is display :1 inside IANA's 6000-6063 x11 range. On a workstation it is the second X server; far more often it belongs to a headless one — Xvfb for CI screenshot jobs, or the X server side of a VNC session started as `vncserver :1`, which pairs it with RFB on 5901. Scan data shows it open slightly more often than 6000, which fits the headless-server pattern.",
"exposure": {
"verdict": "never",
"note": "Same protocol, same problem: a connected client can screenshot and inject input. Bind the X server to localhost and reach it over SSH forwarding or through the VNC layer, not directly."
},
"checkCommand": "xdpyinfo -display TARGET:1",
"links": [
{
"title": "X.Org — Xserver(1) manual page",
"url": "https://xorg.freedesktop.org/archive/current/doc/man/man1/Xserver.1.xhtml",
"kind": "official-docs"
},
{
"title": "IANA port registry — 6000-6063 (x11)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=x11",
"kind": "iana"
},
{
"title": "TigerVNC/tigervnc",
"url": "https://github.com/TigerVNC/tigervnc",
"kind": "github"
}
]
},
{
"port": 6002,
"protocol": "tcp",
"service": "X11 (display :2)",
"oneLiner": "X display :2 — a third X server on the host, physical or virtual.",
"whatItIs": "Within IANA's x11 block, 6002 is display :2. It appears on multi-seat machines, on hosts running several Xvnc or Xvfb instances, and on terminal servers that give each session its own display. Everything true of 6000 applies unchanged: host-list or magic-cookie authorization, no encryption, and `-nolisten tcp` as the modern default that has been overridden if the port is open.",
"exposure": {
"verdict": "never",
"note": "There is no safe way to publish an X display. Keep it on the Unix socket or loopback and forward it over SSH."
},
"checkCommand": "nmap -Pn -p 6002 --script x11-access TARGET",
"links": [
{
"title": "X.Org — Xserver(1) manual page",
"url": "https://xorg.freedesktop.org/archive/current/doc/man/man1/Xserver.1.xhtml",
"kind": "official-docs"
},
{
"title": "IANA port registry — 6000-6063 (x11)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=x11",
"kind": "iana"
}
]
},
{
"port": 6003,
"protocol": "tcp",
"service": "X11 (display :3)",
"oneLiner": "X display :3 — and the one number in the X11 range IANA flags for known unauthorized use.",
"whatItIs": "6003 is display :3 in IANA's 6000-6063 x11 assignment, and the registry attaches an explicit note to it: \"Known Unauthorized Use on port 6003\". That flag reflects backdoors and trojans that historically chose this port precisely because a listener there looks like an ordinary X display to a casual scan. A genuine X server here behaves exactly like 6000; the difference is that you should not assume it is one.",
"exposure": {
"verdict": "never",
"note": "Confirm the listening process rather than trusting the port name — IANA itself records unauthorized use here. A real X display is still never safe to expose."
},
"checkCommand": "sudo lsof -nP -iTCP:6003 -sTCP:LISTEN",
"links": [
{
"title": "IANA port registry — 6000-6063 (x11), incl. the unauthorized-use note",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=x11",
"kind": "iana"
},
{
"title": "X.Org — Xserver(1) manual page",
"url": "https://xorg.freedesktop.org/archive/current/doc/man/man1/Xserver.1.xhtml",
"kind": "official-docs"
}
]
},
{
"port": 6004,
"protocol": "tcp",
"service": "X11 display :4",
"oneLiner": "X display :4 — another slot in the 6000-6063 X Window System range.",
"whatItIs": "IANA covers 6004 under the same `x11` assignment as 6000-6063, making it display :4. Hosts reach it when they run several X servers at once: multi-seat desktops, CI runners spawning Xvfb per job, or a VNC host on its fifth display (paired with RFB 5904). Authorization is still xhost or MIT-MAGIC-COOKIE-1, and the protocol is still cleartext.",
"exposure": {
"verdict": "never",
"note": "A reachable X display hands an attacker the screen contents and the keyboard. Start the server with `-nolisten tcp` and use SSH X forwarding for remote access."
},
"checkCommand": "xdpyinfo -display TARGET:4",
"links": [
{
"title": "X.Org — Xserver(1) manual page",
"url": "https://xorg.freedesktop.org/archive/current/doc/man/man1/Xserver.1.xhtml",
"kind": "official-docs"
},
{
"title": "IANA port registry — 6000-6063 (x11)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=x11",
"kind": "iana"
},
{
"title": "X.Org Server source repository (xorg/xserver)",
"url": "https://gitlab.freedesktop.org/xorg/xserver",
"kind": "official-docs"
}
]
},
{
"port": 6005,
"protocol": "tcp",
"service": "X11 display :5",
"oneLiner": "X Window System display number 5 — inside IANA's 6000-6063 x11 block.",
"whatItIs": "An X server listening for TCP clients uses port 6000 plus its display number, so display :5 is TCP 6005. Modern desktops start the X server with -nolisten tcp (or run Wayland), so nothing binds here unless someone deliberately re-enabled TCP transport. When it is open it is usually a thin client, an X terminal, or a headless Xvfb instance started for CI screenshots. Access is then gated only by whatever xhost/xauth policy the server was started with.",
"exposure": {
"verdict": "never",
"note": "An X server reachable over TCP with xhost + or a leaked MIT-MAGIC-COOKIE-1 lets anyone read the screen, log keystrokes, and inject input; keep X on Unix sockets and forward it over SSH."
},
"checkCommand": "xdpyinfo -display TARGET:5",
"links": [
{
"title": "Xserver(1) — X server options including -nolisten",
"url": "https://xorg.freedesktop.org/archive/X11R7.7/doc/man/man1/Xserver.1.xhtml",
"kind": "official-docs"
},
{
"title": "Xsecurity(7) — X display access control",
"url": "https://xorg.freedesktop.org/archive/X11R7.7/doc/man/man7/Xsecurity.7.xhtml",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 6000-6063 (x11)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=6005",
"kind": "iana"
}
]
},
{
"port": 6006,
"protocol": "tcp",
"service": "TensorBoard (IANA: X11 display :6)",
"oneLiner": "TensorBoard's default HTTP port, squatting inside IANA's X11 range.",
"whatItIs": "IANA registers 6000-6063 to X11, making 6006 display :6, but in practice almost everything you find here is TensorBoard: running `tensorboard --logdir ...` serves its web UI on 6006 and tells you to open http://localhost:6006. It is a plain HTTP server with no authentication and no authorization, reading whatever event files live under the log directory. It shows up on GPU boxes, notebook servers, and ML training containers, often port-forwarded rather than bound publicly.",
"exposure": {
"verdict": "never",
"note": "TensorBoard has no login of any kind — anyone who reaches the port reads your training runs, hyperparameters, and any embedded data. Bind it to localhost and reach it through an SSH tunnel."
},
"checkCommand": "curl -sI http://TARGET:6006/",
"links": [
{
"title": "tensorflow/tensorboard on GitHub",
"url": "https://github.com/tensorflow/tensorboard",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 6000-6063 (x11)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=6006",
"kind": "iana"
}
]
},
{
"port": 6007,
"protocol": "tcp",
"service": "X11 display :7 / second TensorBoard",
"oneLiner": "X11 display :7 by registration; in practice the port a second TensorBoard lands on.",
"whatItIs": "By IANA's 6000-6063 x11 block this is display :7. The common real-world sighting is a second TensorBoard instance: 6006 is the default, so a second instance is commonly started with `--port 6007`. Either way you are looking at a machine running graphical or ML workloads, not a general-purpose service. Confirm which by what answers — an X server speaks the X protocol, TensorBoard answers HTTP.",
"exposure": {
"verdict": "never",
"note": "Both plausible occupants are unauthenticated: an X server here can be driven by anyone who reaches it, and a TensorBoard here exposes training data to anyone who asks."
},
"checkCommand": "curl -sI http://TARGET:6007/",
"links": [
{
"title": "tensorflow/tensorboard on GitHub",
"url": "https://github.com/tensorflow/tensorboard",
"kind": "github"
},
{
"title": "Xsecurity(7) — X display access control",
"url": "https://xorg.freedesktop.org/archive/X11R7.7/doc/man/man7/Xsecurity.7.xhtml",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 6000-6063 (x11)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=6007",
"kind": "iana"
}
]
},
{
"port": 6009,
"protocol": "tcp",
"service": "X11 display :9",
"oneLiner": "X11 display :9 — the last display number below where SSH X11 forwarding starts.",
"whatItIs": "TCP 6009 is X display :9 under IANA's 6000-6063 x11 registration. It is worth knowing because sshd's X11DisplayOffset defaults to 10, so forwarded X sessions begin at :10 (port 6010) precisely to avoid colliding with real local displays like this one. A listener on 6009 therefore means a genuine X server with TCP transport enabled, not an SSH forwarding artifact. That is unusual on a current system, where X normally runs with -nolisten tcp.",
"exposure": {
"verdict": "never",
"note": "Unauthenticated or xhost-permissive X over TCP gives an attacker the display, the keyboard, and the clipboard; tunnel X through SSH instead of opening the port."
},
"checkCommand": "nc -vz TARGET 6009",
"links": [
{
"title": "Xserver(1) — display numbers and -nolisten",
"url": "https://xorg.freedesktop.org/archive/X11R7.7/doc/man/man1/Xserver.1.xhtml",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 6000-6063 (x11)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=6009",
"kind": "iana"
}
]
},
{
"port": 6025,
"protocol": "tcp",
"service": "X11 display :25",
"oneLiner": "X11 display :25 — high display numbers like this usually mean many forwarded or virtual sessions.",
"whatItIs": "IANA assigns the whole 6000-6063 range to X11, so 6025 is display :25. Display numbers this high normally come from a multi-user host: sshd hands each X11-forwarded session the next free display starting at :10, and Xvfb/Xvnc farms allocate them in bulk for headless browsers and test runners. Seeing it listening on a public interface means the X transport was left on TCP rather than confined to the loopback socket sshd normally uses.",
"exposure": {
"verdict": "never",
"note": "Forwarded and virtual displays carry real sessions; exposing them over TCP hands out screen contents and input injection with only a cookie in the way."
},
"checkCommand": "xdpyinfo -display TARGET:25",
"links": [
{
"title": "Xsecurity(7) — X display access control",
"url": "https://xorg.freedesktop.org/archive/X11R7.7/doc/man/man7/Xsecurity.7.xhtml",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 6000-6063 (x11)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=6025",
"kind": "iana"
}
]
},
{
"port": 6059,
"protocol": "tcp",
"service": "X11 display :59",
"oneLiner": "X11 display :59, near the top of IANA's 6000-6063 x11 block.",
"whatItIs": "This is display :59 under the x11 range registration, four short of where the range ends at 6063. Nothing else is registered here, and there is no well-known product that claims it. In practice a listener means a busy X11 host — a terminal server, or a pool of Xvfb/VNC displays — with TCP transport enabled rather than the usual Unix-socket-only configuration.",
"exposure": {
"verdict": "never",
"note": "Same as any X display over TCP: full read and write access to a live session for whoever gets past (or around) the xauth cookie."
},
"checkCommand": "sudo lsof -nP -iTCP:6059 -sTCP:LISTEN",
"links": [
{
"title": "Xserver(1) — display numbers and -nolisten",
"url": "https://xorg.freedesktop.org/archive/X11R7.7/doc/man/man1/Xserver.1.xhtml",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 6000-6063 (x11)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=6059",
"kind": "iana"
}
]
},
{
"port": 6100,
"protocol": "both",
"service": "SynchroNet-db",
"oneLiner": "Registered to SynchroNet-db; rarely seen in the wild.",
"whatItIs": "IANA lists 6100 TCP and UDP as synchronet-db, \"SynchroNet-db\", registered to Arne Haugland, and the same entry is copied into the /etc/services file on most Unix systems. There is no public protocol specification and no widely deployed open-source implementation, so a scanner labelling 6100 as \"SynchroNet-db\" is reading the registry, not fingerprinting the service. If you find it listening, identify the process on the host rather than trusting the name — this is a plausible port for an in-house or vendor application to squat on.",
"exposure": {
"verdict": "careful",
"note": "You cannot make a defensible call on a port whose actual occupant is unidentified; find the process, then decide. Treat an unknown listener on a public interface as something to close until it is explained."
},
"checkCommand": "sudo lsof -nP -iTCP:6100 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 6100 (synchronet-db)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=6100",
"kind": "iana"
}
]
},
{
"port": 6101,
"protocol": "tcp",
"service": "Backup Exec Agent Browser (IANA: SynchroNet-rtc)",
"oneLiner": "Registered as SynchroNet-rtc, but on Windows networks it is the Backup Exec Agent Browser.",
"whatItIs": "IANA has 6101 as synchronet-rtc, and that is the name /etc/services reports, but the service you actually meet on this port is the Backup Exec Agent Browser: remote agents advertise their resources to the media server over TCP 6101 so backup selections can be browsed. The port is not covered by any public protocol document, so the identification rests on the software's own behaviour rather than a specification. A listener marks a machine inside someone's backup infrastructure.",
"exposure": {
"verdict": "never",
"note": "Backup infrastructure sees every file on every protected host — keep the agent ports on the backup VLAN, never on an internet-facing interface."
},
"checkCommand": "sudo lsof -nP -iTCP:6101 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 6101 (synchronet-rtc)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=6101",
"kind": "iana"
}
]
},
{
"port": 6106,
"protocol": "both",
"service": "MPS Server",
"oneLiner": "Registered to Prima Designs Systems as \"MPS Server\"; effectively never seen.",
"whatItIs": "IANA registers 6106 TCP and UDP as mpsserver, \"MPS Server\", assigned to Prima Designs Systems, and Unix /etc/services carries the same line. No public specification, client, or server implementation is available, so the registration is essentially the whole story. Anything listening here today is far more likely to be an unrelated application that picked a free port than an actual MPS Server.",
"exposure": {
"verdict": "careful",
"note": "Identify the process before judging it; an unattributed listener reachable from outside should be closed until someone can name it."
},
"checkCommand": "sudo lsof -nP -iTCP:6106 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 6106 (mpsserver)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=6106",
"kind": "iana"
}
]
},
{
"port": 6112,
"protocol": "both",
"service": "CDE dtspcd / Blizzard games",
"oneLiner": "CDE's subprocess control daemon — and the port classic Blizzard games host on.",
"whatItIs": "IANA registers 6112 as dtspcd, the Common Desktop Environment Subprocess Control Daemon, which accepts client requests to launch commands and applications and historically ran from inetd as root on commercial Unix. CERT VU#172583 (2002) documented a remotely exploitable buffer overflow in dtspcd giving root, and it was scanned heavily for years afterward. The same port number is separately used by Blizzard's older titles — Warcraft II and III, StarCraft, Diablo II — whose clients bind 6112 to host games, which is why home routers carry 6112 forwarding rules. Which one you have depends entirely on the host: a Solaris/AIX/HP-UX box means dtspcd, a Windows desktop means a game.",
"exposure": {
"verdict": "never",
"note": "dtspcd is a root-privileged remote command-execution daemon with a history of pre-auth overflows; disable it in inetd.conf and block the port. Game hosting on 6112 is a deliberate inbound forward, and should be scoped to that one host."
},
"checkCommand": "sudo lsof -nP -iTCP:6112 -sTCP:LISTEN",
"links": [
{
"title": "CERT VU#172583 — CDE dtspcd buffer overflow",
"url": "https://www.kb.cert.org/vuls/id/172583",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 6112 (dtspcd)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=6112",
"kind": "iana"
}
]
},
{
"port": 6123,
"protocol": "tcp",
"service": "Apache Flink JobManager RPC (IANA: Backup Express)",
"oneLiner": "Apache Flink's JobManager RPC port — registered to Backup Express, but Flink is what you find.",
"whatItIs": "IANA assigns 6123 to backup-express, Catalogic Software's Backup Express. In practice the occupant today is Apache Flink: jobmanager.rpc.port defaults to 6123, and TaskManagers connect to the JobManager on it, so every standalone, YARN, and Kubernetes Flink deployment exposes it internally. It is an RPC channel, not a web UI — Flink's dashboard is 8081. Seeing 6123 on a scan almost always means a stream-processing cluster.",
"exposure": {
"verdict": "never",
"note": "Flink ships with no authentication on its RPC endpoints, and submitting a job is arbitrary code execution on the cluster; keep 6123 inside the cluster network."
},
"checkCommand": "nc -vz TARGET 6123",
"links": [
{
"title": "Apache Flink — Configuration (jobmanager.rpc.port)",
"url": "https://nightlies.apache.org/flink/flink-docs-stable/docs/deployment/config/",
"kind": "official-docs"
},
{
"title": "apache/flink on GitHub",
"url": "https://github.com/apache/flink",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 6123 (backup-express)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=6123",
"kind": "iana"
}
]
},
{
"port": 6129,
"protocol": "tcp",
"service": "DameWare Mini Remote Control",
"oneLiner": "DameWare Mini Remote Control's default port — famously scanned after its pre-auth overflows.",
"whatItIs": "IANA leaves 6125-6129 unassigned; 6129 is claimed in practice by DameWare Mini Remote Control, a Windows remote-administration tool whose client service listens here by default. A pre-authentication buffer overflow made it a mass-scan target: CERT VU#909678, where a crafted packet mimicking a client compromises the server. Moving the service off the default port is common advice precisely because the number is so well known. A listener here means a managed Windows fleet, and a lot of internet background noise still probes it.",
"exposure": {
"verdict": "never",
"note": "A remote-control agent with a history of pre-auth remote code execution has no business on a public IP; reach it over a VPN and keep the version current."
},
"checkCommand": "sudo lsof -nP -iTCP:6129 -sTCP:LISTEN",
"links": [
{
"title": "CERT VU#909678 — DameWare Mini Remote Control buffer overflow (port 6129/TCP)",
"url": "https://www.kb.cert.org/vuls/id/909678",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 6125-6129 unassigned",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=6129",
"kind": "iana"
}
]
},
{
"port": 6156,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned by IANA — 6150-6158 is an empty block with no known occupant.",
"whatItIs": "IANA's registry marks the range 6150-6158 unassigned, so 6156 has no service name, no assignee, and no reference. There is no documented product, malware family, or convention that uses it. Anything listening here was chosen arbitrarily by whatever software opened it, which makes host-side process identification the only reliable way to name it.",
"exposure": {
"verdict": "careful",
"note": "No registration means no expectations — find the owning process before deciding whether it belongs on the network at all."
},
"checkCommand": "sudo lsof -nP -iTCP:6156 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 6150-6158 unassigned",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=6156",
"kind": "iana"
}
]
},
{
"port": 6247,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned by IANA — sits in the 6245-6250 gap next to JEOL's instrument ports.",
"whatItIs": "The registry shows 6245-6250 as unassigned. Its only notable neighbours are 6241-6244, registered to JEOL for their Network Services data transport and discovery protocols used by scientific instruments. Nothing is documented as using 6247 itself. A listener here is an application that picked a free high port, so identify it by process rather than by port number.",
"exposure": {
"verdict": "careful",
"note": "An unregistered, unidentified listener gets no verdict until you know what it is; do not expose it externally in the meantime."
},
"checkCommand": "sudo lsof -nP -iTCP:6247 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 6245-6250 unassigned",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=6247",
"kind": "iana"
}
]
},
{
"port": 6346,
"protocol": "both",
"service": "Gnutella",
"oneLiner": "The Gnutella peer-to-peer network's default port, TCP and UDP 6346.",
"whatItIs": "IANA registers 6346 as gnutella-svc for both TCP and UDP, and it is the default listening port for Gnutella servents — historically LimeWire, BearShare and Shareaza, still gtk-gnutella today. TCP carries peer connections and file transfers; UDP carries out-of-band query replies and host-cache pings in the modern protocol. Because peers must accept inbound connections to be useful, this port is deliberately opened or UPnP-forwarded, and it lit up firewall logs constantly during the file-sharing era. Finding it on a corporate network is normally a policy question about P2P clients rather than a compromise.",
"exposure": {
"verdict": "careful",
"note": "Gnutella is designed to be internet-facing — an unreachable peer is a degraded peer — so exposing it can be deliberate. The exposure is what the client shares and the fact that an open 6346 advertises this host as a P2P node: audit the shared folders, and expose it only where that is fine."
},
"checkCommand": "sudo lsof -nP -iTCP:6346 -sTCP:LISTEN",
"links": [
{
"title": "gtk-gnutella on GitHub",
"url": "https://github.com/gtk-gnutella/gtk-gnutella",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 6346 (gnutella-svc)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=6346",
"kind": "iana"
}
]
},
{
"port": 6379,
"protocol": "tcp",
"service": "Redis",
"oneLiner": "Redis, registered with IANA and running with no password unless you set one.",
"whatItIs": "Port 6379 is the registered Redis port and the default for every Redis and Redis-compatible server. Redis is designed for trusted networks: authentication is off unless you configure ACLs or requirepass. Since 3.2 it starts in protected mode, replying only to loopback when it binds all interfaces with no password set, but plenty of deployments disable that or bind explicitly and end up open.",
"exposure": {
"verdict": "never",
"note": "Redis's own docs say do not expose the port to the internet — one FLUSHALL wipes the dataset, and CONFIG-based file writes can lead to code execution."
},
"checkCommand": "redis-cli -h 127.0.0.1 -p 6379 PING",
"links": [
{
"title": "Redis — Security (protected mode, network security, ACLs)",
"url": "https://redis.io/docs/latest/operate/oss_and_stack/management/security/",
"kind": "official-docs"
},
{
"title": "redis/redis on GitHub",
"url": "https://github.com/redis/redis",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 6379 (redis)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=6379",
"kind": "iana"
}
]
},
{
"port": 6389,
"protocol": "both",
"service": "clariion-evr01",
"oneLiner": "Registered to EMC for CLARiiON storage arrays; seen only around SAN management networks.",
"whatItIs": "IANA lists 6389 TCP and UDP as clariion-evr01, registered by Dave DesRoches of EMC, and it belongs to the management side of the CLARiiON storage array line (later VNX, now Dell). There is no public protocol specification, so scanners label it from the registry rather than from a fingerprint. In practice you meet it on a storage management VLAN alongside the array's other administrative services, not on a general-purpose server.",
"exposure": {
"verdict": "never",
"note": "Storage-array control planes reach every LUN in the environment; keep them on an isolated management network with no route from the internet."
},
"checkCommand": "nc -vz TARGET 6389",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 6389 (clariion-evr01)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=6389",
"kind": "iana"
}
]
},
{
"port": 6481,
"protocol": "both",
"service": "Sun Service Tags",
"oneLiner": "Sun/Oracle Service Tags agent — answers with the machine's serial number and hardware inventory.",
"whatItIs": "IANA registers 6481 as servicetags, assigned to Peter Schow at Sun. The Service Tags agent shipped with Solaris and several Sun/Oracle products to support asset discovery, and it answers unauthenticated queries with system details: OS release, hostname, architecture, platform, manufacturer, serial number, hostid, RAM, and CPU counts. Nmap ships a servicetags NSE script that does exactly this over UDP 6481. Finding it open means an older Solaris or Sun-derived stack that still has the discovery listener enabled.",
"exposure": {
"verdict": "never",
"note": "It hands out serial numbers, hostids, and a full hardware profile with no authentication — precise inventory data for an attacker planning the next step. Disable the agent or firewall it to the asset-management server."
},
"checkCommand": "nmap -sU -p 6481 --script=servicetags TARGET",
"links": [
{
"title": "Nmap NSE — servicetags (Sun Service Tags, UDP 6481)",
"url": "https://nmap.org/nsedoc/scripts/servicetags.html",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 6481 (servicetags)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=6481",
"kind": "iana"
}
]
},
{
"port": 6500,
"protocol": "tcp",
"service": "BoKS Master",
"oneLiner": "The master daemon of BoKS, the Unix access-control product — and the base of its four-port block.",
"whatItIs": "IANA registers 6500 as boks, \"BoKS Master\", for the access-control and privileged-access product originally from Fox Technologies (now Fortra). 6500 is the configurable base port: the master daemon listens here to maintain the master database and drive replication to replica servers, with the following ports in the block carrying the other daemons. Every BoKS server agent in a domain must use the same base port, so where you find one you find the whole 6500-6503 cluster. A listener means a host inside a centrally managed Unix authentication domain.",
"exposure": {
"verdict": "never",
"note": "This is the control plane for who may log in to every managed Unix host; it belongs on a management network reachable only by BoKS masters, replicas, and agents."
},
"checkCommand": "sudo lsof -nP -iTCP:6500 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 6500 (boks)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=6500",
"kind": "iana"
}
]
},
{
"port": 6502,
"protocol": "tcp",
"service": "BoKS Servm",
"oneLiner": "BoKS's servm daemon, two above the 6500 base port.",
"whatItIs": "IANA registers 6502 as boks-servm (with the older boks_servm name kept as an alias), part of the same Fox Technologies/Fortra BoKS block that starts at 6500. It carries the servm daemon's traffic within a BoKS domain, so it appears only alongside 6500 and its siblings on managed Unix hosts. As with the rest of the block the base port is configurable, so a BoKS deployment can sit somewhere else entirely and something unrelated can occupy 6502 instead — check the process, not just the number.",
"exposure": {
"verdict": "never",
"note": "Part of an authentication and privileged-access control plane; expose it only between BoKS masters, replicas, and agents on a management network."
},
"checkCommand": "sudo lsof -nP -iTCP:6502 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 6502 (boks-servm)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=6502",
"kind": "iana"
}
]
},
{
"port": 6504,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned by IANA, immediately above the registered BoKS block.",
"whatItIs": "The registry shows 6504 as unassigned. Its only context is the neighbourhood: 6500-6503 carry the BoKS access-control daemons, and a BoKS domain configured with a base port a few numbers higher would land traffic here. Nothing is registered or documented as owning 6504 itself, so a listener is either a shifted BoKS block or unrelated software that grabbed a free port.",
"exposure": {
"verdict": "careful",
"note": "No registration to reason from — identify the process first. If it turns out to be a BoKS daemon, treat it as a control plane and keep it internal."
},
"checkCommand": "sudo lsof -nP -iTCP:6504 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 6504 unassigned",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=6504",
"kind": "iana"
}
]
},
{
"port": 6510,
"protocol": "both",
"service": "MCER Port",
"oneLiner": "Registered as \"MCER Port\"; no public documentation and effectively never seen.",
"whatItIs": "IANA registers 6510 TCP and UDP as mcer-port, \"MCER Port\", assigned to Portnoy Boxman, and Unix /etc/services repeats the entry. No protocol specification, product page, or implementation is publicly available, so the registration is the entire documented record. Scanners naming 6510 \"mcer-port\" are quoting the registry rather than recognising a service.",
"exposure": {
"verdict": "careful",
"note": "Nothing is known about what would answer here, so no verdict is defensible without identifying the local process first."
},
"checkCommand": "sudo lsof -nP -iTCP:6510 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 6510 (mcer-port)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=6510",
"kind": "iana"
}
]
},
{
"port": 6520,
"protocol": "tcp",
"service": "Cuttlefish ADB (unassigned at IANA)",
"oneLiner": "Unassigned by IANA; in practice the ADB socket for the first Cuttlefish virtual Android device.",
"whatItIs": "IANA leaves 6516-6542 unassigned. The concrete use of 6520 is Android's Cuttlefish virtual device platform: each instance exposes an ADB connection on a TCP server socket, 6520 for instance 1, 6521 for the second, and upward, so `adb connect 127.0.0.1:6520` reaches the first VM. You meet it on Android build and CTS machines running emulated devices. ADB over TCP has no authentication once a host is authorised, which is why Cuttlefish binds it locally.",
"exposure": {
"verdict": "never",
"note": "A reachable ADB endpoint is a root-capable shell on the device plus arbitrary file push and pull; keep it on loopback and reach it over an SSH tunnel."
},
"checkCommand": "adb connect 127.0.0.1:6520",
"links": [
{
"title": "Android Open Source Project — Cuttlefish multi-tenancy (ADB port 6520)",
"url": "https://source.android.com/docs/devices/cuttlefish/multi-tenancy",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 6516-6542 unassigned",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=6520",
"kind": "iana"
}
]
},
{
"port": 6543,
"protocol": "tcp",
"service": "Pyramid development server (IANA: lds-distrib)",
"oneLiner": "The Pyramid/Waitress development server's default port, registered to IANA as lds_distrib.",
"whatItIs": "IANA registers 6543 as lds-distrib, assigned to Jack Baker, but the occupant you will actually meet is a Python web app: a Pyramid project created from the standard cookiecutter ships development.ini with `listen = localhost:6543`, so `pserve development.ini` serves on 6543 through Waitress. That configuration also enables the pyramid_debugtoolbar, which exposes tracebacks and, historically, an interactive debugger console. Seeing it open means a developer's machine or a container that shipped its dev config into an environment it should not have.",
"exposure": {
"verdict": "never",
"note": "A development server with the debug toolbar enabled leaks source, settings, and stack frames; the default config binds localhost for exactly this reason. Production uses a real WSGI deployment behind a reverse proxy, not 6543."
},
"checkCommand": "curl -sI http://TARGET:6543/",
"links": [
{
"title": "Pyramid — Creating a Pyramid Project (development.ini, port 6543)",
"url": "https://docs.pylonsproject.org/projects/pyramid/en/latest/narr/project.html",
"kind": "official-docs"
},
{
"title": "Pylons/pyramid on GitHub",
"url": "https://github.com/Pylons/pyramid",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 6543 (lds-distrib)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=6543",
"kind": "iana"
}
]
},
{
"port": 6547,
"protocol": "tcp",
"service": "APC PowerChute agent UI",
"oneLiner": "The web UI of APC's PowerChute UPS shutdown agent, registered to APC as apc-6547.",
"whatItIs": "IANA registers 6547 to American Power Conversion as apc-6547. In practice it is the agent web interface of PowerChute Business Edition v10.x and PowerChute Serial Shutdown v1.x, served over HTTPS on the machine attached to the UPS. Schneider Electric's own FAQ says the port must be open in the host firewall to reach the agent UI, and that blocking it in the firewall is the supported way to restrict access to local only. It shows up on scans of server rooms, small-business file servers, and anything with a USB or serial UPS cable hanging off it.",
"exposure": {
"verdict": "never",
"note": "This is the console that can shut a machine down on command. Schneider's own guidance is that PowerChute should not sit on a public-facing network segment."
},
"checkCommand": "curl -skI https://TARGET:6547/",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 6547 (apc-6547)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=6547",
"kind": "iana"
},
{
"title": "Schneider Electric — TCP and UDP ports used by each component of PowerChute",
"url": "https://www.se.com/us/en/faqs/FA159597/",
"kind": "official-docs"
}
]
},
{
"port": 6550,
"protocol": "tcp",
"service": "fg-sysupdate (registered)",
"oneLiner": "Registered at IANA as fg-sysupdate, with no public protocol behind the name.",
"whatItIs": "IANA lists 6550/tcp and 6550/udp as fg-sysupdate, assigned to an individual registrant with no reference document, no specification, and no dated registration record. There is no published protocol to describe and no widely deployed product known to bind it. If you find 6550 listening, the registry will not tell you what it is — identify the process on the host instead of trusting the service name your scanner printed.",
"exposure": {
"verdict": "careful",
"note": "An unidentified listener is an unknown attack surface. Find out what process owns it before deciding whether it belongs on the network at all."
},
"checkCommand": "sudo lsof -nP -iTCP:6550 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 6550 (fg-sysupdate)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=6550",
"kind": "iana"
}
]
},
{
"port": 6565,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned at IANA — nothing standard claims it.",
"whatItIs": "IANA lists the whole 6559-6565 block as Unassigned, and nmap's service database has no name for 6565 either. There is no registered protocol, no well-known product default, and no notable malware association documented for it. An open 6565 is an application that picked a free high port, so the only way to know what it is, is to look on the host.",
"exposure": {
"verdict": "careful",
"note": "Unassigned does not mean harmless — whatever bound it is unidentified, so treat it as unknown software until you name the process."
},
"checkCommand": "sudo lsof -nP -iTCP:6565 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 6565",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=6565",
"kind": "iana"
},
{
"title": "nmap-services (Nmap's port/service frequency database)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 6566,
"protocol": "tcp",
"service": "SANE (saned)",
"oneLiner": "SANE's network scanner daemon — remote access to a scanner, in cleartext.",
"whatItIs": "IANA registered 6566 as sane-port, the SANE Control Port, in 2002. saned is the daemon from the SANE project that lets other machines drive a locally attached scanner over the network; a client connects, names a backend and device, and pulls image data back. Access control is by host list plus an optional user list, and the protocol itself is unencrypted. You see it on Linux print/scan servers and on multifunction-device host machines.",
"exposure": {
"verdict": "never",
"note": "Cleartext protocol with host-list access control and a long history of parsing bugs in the backends it fronts. Keep it on a trusted LAN segment, never on a public IP."
},
"checkCommand": "nc -vz TARGET 6566",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 6566 (sane-port)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=6566",
"kind": "iana"
},
{
"title": "SANE Project — backends source repository",
"url": "https://gitlab.com/sane-project/backends",
"kind": "official-docs"
}
]
},
{
"port": 6567,
"protocol": "tcp",
"service": "reserved (formerly esp)",
"oneLiner": "Reserved at IANA; older service tables still call it esp, the eSilo Storage Protocol.",
"whatItIs": "The current IANA registry marks 6567 as Reserved, with no service name and no assignee. Legacy service tables, including nmap-services, still print it as esp, \"eSilo Storage Protocol\" — a name that outlived its vendor and now survives mostly as a scanner label. Nothing in common use listens here, so a scanner reporting \"esp\" on 6567 is guessing from a name table, not from a probe response.",
"exposure": {
"verdict": "careful",
"note": "Do not trust the service name your scanner prints for this one; identify the actual process before deciding what the exposure is."
},
"checkCommand": "sudo lsof -nP -iTCP:6567 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 6567",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=6567",
"kind": "iana"
},
{
"title": "nmap-services (Nmap's port/service frequency database)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 6580,
"protocol": "tcp",
"service": "Parsec master server",
"oneLiner": "Registered as the master server port for Parsec, a 1990s space-combat game.",
"whatItIs": "IANA lists 6580/tcp and 6580/udp as parsec-master, \"Parsec Masterserver\", assigned to the game's author. A master server is the directory a multiplayer client queries for the list of live game servers. The game has had no meaningful deployment for two decades, so an open 6580 today is almost certainly unrelated software that happened to take the port — note that it is not the modern Parsec remote-desktop product, which is a different company with different ports.",
"exposure": {
"verdict": "careful",
"note": "The registration is effectively historical, so whatever answers on 6580 now is unidentified until you check the host."
},
"checkCommand": "sudo lsof -nP -iTCP:6580 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 6580 (parsec-master)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=6580",
"kind": "iana"
}
]
},
{
"port": 6600,
"protocol": "tcp",
"service": "MPD / Hyper-V Live Migration",
"oneLiner": "Music Player Daemon's control port in practice; registered to Microsoft for Hyper-V Live Migration.",
"whatItIs": "IANA registered 6600/tcp in 2009 as mshvlm, Microsoft Hyper-V Live Migration — the channel that carries a running VM's memory between cluster hosts. On Linux and macOS boxes, though, an open 6600 is almost always MPD, the Music Player Daemon: its documentation states that if no port is specified the default is 6600. MPD speaks a simple line-based text protocol that greets you with \"OK MPD \" and then accepts library and playback commands, with a password being optional.",
"exposure": {
"verdict": "never",
"note": "MPD's protocol is cleartext and unauthenticated unless you configure a password, and it exposes your library paths and playback control. Hyper-V live migration traffic is cluster-internal by design. Neither belongs on a public IP."
},
"checkCommand": "printf 'status\\nclose\\n' | nc TARGET 6600",
"links": [
{
"title": "MPD User Manual — configuration and the default port",
"url": "https://mpd.readthedocs.io/en/latest/user.html",
"kind": "official-docs"
},
{
"title": "Music Player Daemon source repository",
"url": "https://github.com/MusicPlayerDaemon/MPD",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 6600 (mshvlm)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=6600",
"kind": "iana"
}
]
},
{
"port": 6646,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned at IANA, but seen open more often than its neighbours in Nmap's scan data.",
"whatItIs": "IANA lists the block 6641-6652 as Unassigned, so 6646 has no registered service. Nmap's service database gives it no name either, yet records it with an open-frequency an order of magnitude above the surrounding unnamed ports — meaning real software binds it in the field without any registration behind it. Endpoint-security agents are the usual suspects on Windows hosts, but no vendor documentation pins the port down, so identify the owning process rather than guessing from a name table.",
"exposure": {
"verdict": "careful",
"note": "An unregistered port that is nevertheless commonly open is exactly the kind of listener worth naming before you leave it reachable."
},
"checkCommand": "sudo lsof -nP -iTCP:6646 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 6646",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=6646",
"kind": "iana"
},
{
"title": "nmap-services (Nmap's port/service frequency database)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 6666,
"protocol": "tcp",
"service": "IRC (alternate)",
"oneLiner": "One of the five IRC ports in IANA's 6665-6669 ircu range — an alternate to 6667.",
"whatItIs": "IANA assigns 6665-6669/tcp as a single block named ircu, after the Undernet IRC daemon, and RFC 7194 confirms plaintext IRC is covered by that assignment. Most networks listen on all five so clients have a fallback when one is blocked, and 6666 is the most commonly offered alternate. Its memorable digits also made it a long-standing favourite for command-and-control channels of IRC-controlled bots, which is why some corporate filters block the whole range outright.",
"exposure": {
"verdict": "careful",
"note": "Plaintext IRC — nick, credentials sent to services, and every message travel unencrypted. Prefer 6697 with TLS (RFC 7194) for anything you care about."
},
"checkCommand": "printf 'QUIT\\r\\n' | nc -v TARGET 6666",
"links": [
{
"title": "RFC 7194 — Default Port for Internet Relay Chat (IRC) via TLS/SSL",
"url": "https://www.rfc-editor.org/rfc/rfc7194.html",
"kind": "spec"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 6665-6669 (ircu)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=6666",
"kind": "iana"
},
{
"title": "ircu2 — Undernet IRC Daemon",
"url": "https://github.com/UndernetIRC/ircu2",
"kind": "github"
}
]
},
{
"port": 6667,
"protocol": "tcp",
"service": "IRC",
"oneLiner": "The default plaintext IRC port — where clients connect to chat networks without TLS.",
"whatItIs": "An IRC client opens 6667, sends NICK and USER, and the server answers with a numeric welcome burst and the MOTD; from there everything is line-based text terminated by CRLF, as defined in RFC 1459 and its successors. It is the default port in essentially every IRC client, inside IANA's 6665-6669 ircu block, and RFC 7194 names 6697 as its TLS counterpart. It still shows up on scans of chat networks, of bouncers, and of IRC-controlled malware that never moved off the classic port.",
"exposure": {
"verdict": "careful",
"note": "Everything is cleartext, including the password you send to NickServ. Fine for a public chat server that offers TLS on 6697 alongside; never the right choice for anything private."
},
"checkCommand": "printf 'QUIT\\r\\n' | nc -v -w 5 TARGET 6667",
"links": [
{
"title": "RFC 1459 — Internet Relay Chat Protocol",
"url": "https://www.rfc-editor.org/rfc/rfc1459.html",
"kind": "spec"
},
{
"title": "RFC 7194 — Default Port for Internet Relay Chat (IRC) via TLS/SSL",
"url": "https://www.rfc-editor.org/rfc/rfc7194.html",
"kind": "spec"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 6665-6669 (ircu)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=6667",
"kind": "iana"
},
{
"title": "ircu2 — Undernet IRC Daemon",
"url": "https://github.com/UndernetIRC/ircu2",
"kind": "github"
}
]
},
{
"port": 6668,
"protocol": "tcp",
"service": "IRC (alternate)",
"oneLiner": "Another plaintext IRC port from IANA's 6665-6669 ircu block.",
"whatItIs": "6668 carries exactly the same IRC protocol as 6667 and exists because IANA assigned the whole 6665-6669 range to ircu, letting a server offer several entry points. Networks bind it so clients behind a filter that blocks 6667 can still get in, and some run separate listeners per port for load or policy reasons. On a scan it means an IRC daemon, not a distinct protocol.",
"exposure": {
"verdict": "careful",
"note": "Same cleartext exposure as 6667; the TLS port is 6697 per RFC 7194."
},
"checkCommand": "printf 'QUIT\\r\\n' | nc -v TARGET 6668",
"links": [
{
"title": "RFC 1459 — Internet Relay Chat Protocol",
"url": "https://www.rfc-editor.org/rfc/rfc1459.html",
"kind": "spec"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 6665-6669 (ircu)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=6668",
"kind": "iana"
}
]
},
{
"port": 6669,
"protocol": "tcp",
"service": "IRC (alternate)",
"oneLiner": "The top of IANA's 6665-6669 IRC range — a plaintext alternate to 6667.",
"whatItIs": "6669 is the last port in the ircu block IANA assigned for IRC, and servers that listen across the range include it so clients have a fifth fallback. The protocol is identical to 6667: CRLF-terminated text commands, numeric replies, no encryption. Nothing else of note is registered here, so an open 6669 is an IRC daemon or an application squatting on a free port.",
"exposure": {
"verdict": "careful",
"note": "Plaintext like the rest of the range. Offer 6697 with TLS alongside it if the server is public."
},
"checkCommand": "printf 'QUIT\\r\\n' | nc -v TARGET 6669",
"links": [
{
"title": "RFC 1459 — Internet Relay Chat Protocol",
"url": "https://www.rfc-editor.org/rfc/rfc1459.html",
"kind": "spec"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 6665-6669 (ircu)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=6669",
"kind": "iana"
}
]
},
{
"port": 6689,
"protocol": "tcp",
"service": "Tofino Security Appliance",
"oneLiner": "Registered in 2009 for the Tofino industrial security appliance used on SCADA networks.",
"whatItIs": "IANA lists 6689/tcp and 6689/udp as tsa, \"Tofino Security Appliance\", registered in October 2009. Tofino is an industrial firewall dropped inline in front of PLCs and other control-system gear, and the port carries its management and configuration traffic rather than plant process data. You would only see it inside an operational-technology network, next to the device it protects.",
"exposure": {
"verdict": "never",
"note": "This is the management plane of a control-system firewall. It belongs on an isolated OT management segment with no path from the internet."
},
"checkCommand": "nc -vz TARGET 6689",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 6689 (tsa)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=6689",
"kind": "iana"
}
]
},
{
"port": 6692,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned at IANA, with no known service behind it.",
"whatItIs": "IANA lists 6691-6695 as Unassigned, and nmap's database has no name for 6692. There is no registered protocol and no documented product default. If it is open, some local application chose it; the port number itself tells you nothing.",
"exposure": {
"verdict": "careful",
"note": "Nothing standard should be listening. Name the process before you decide whether the listener is wanted."
},
"checkCommand": "sudo lsof -nP -iTCP:6692 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 6692",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=6692",
"kind": "iana"
}
]
},
{
"port": 6699,
"protocol": "tcp",
"service": "reserved (peer-to-peer file sharing, historically)",
"oneLiner": "Reserved at IANA on TCP; remembered as the Napster and WinMX file-sharing port.",
"whatItIs": "IANA marks 6699/tcp as Reserved with no assignee, while 6699/udp was registered in 2020 for the Babel routing protocol over DTLS (RFC 8968). The TCP side is famous for something else entirely: nmap's service table still names it napster, from the era when Napster-style and WinMX clients defaulted to this port for peer connections. Those networks are gone, so an open 6699/tcp today is either a long-abandoned client or unrelated software on a free port.",
"exposure": {
"verdict": "careful",
"note": "A live listener here is worth investigating — either an unmaintained file-sharing client or something you have not identified. It is not a service you should be deliberately publishing."
},
"checkCommand": "sudo lsof -nP -iTCP:6699 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 6699",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=6699",
"kind": "iana"
},
{
"title": "RFC 8968 — Babel Routing Protocol over Datagram Transport Layer Security",
"url": "https://www.rfc-editor.org/rfc/rfc8968.html",
"kind": "spec"
},
{
"title": "nmap-services (Nmap's port/service frequency database)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 6711,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned at IANA; a port that lives mostly in old intrusion-detection signature lists.",
"whatItIs": "IANA lists 6707-6713 as Unassigned, and nmap's service database records no name for 6711. It has no registered protocol and no current product default. Its reputation comes from late-1990s Windows backdoor lore, where ports just above 6700 appear in old firewall and IDS rule sets, but there is no authoritative registration or vendor documentation to point at — so treat any listener here as unidentified software rather than as a confirmed anything.",
"exposure": {
"verdict": "careful",
"note": "Nothing legitimate is expected here. An open 6711 on a Windows host is worth running down to a named process."
},
"checkCommand": "sudo lsof -nP -iTCP:6711 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 6711",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=6711",
"kind": "iana"
},
{
"title": "nmap-services (Nmap's port/service frequency database)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 6732,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned at IANA — no registered service, no common squatter.",
"whatItIs": "6732 falls inside IANA's Unassigned block 6717-6766, and nmap's table has no name for it. There is no protocol, no default, and no documented malware association to report. That is the entire truth of this port: if it is open, a local application picked it, and only the host can tell you which one.",
"exposure": {
"verdict": "careful",
"note": "Unknown listener, unknown surface. Identify the process rather than reasoning from the port number."
},
"checkCommand": "sudo lsof -nP -iTCP:6732 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 6732",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=6732",
"kind": "iana"
}
]
},
{
"port": 6779,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned at IANA, at the start of the 6779-6783 free block.",
"whatItIs": "IANA lists 6779-6783 as Unassigned, and nmap's service database gives 6779 no name. No standard protocol, no vendor default, nothing documented squatting here. A listener on 6779 is an application that took a free high port, and the port number carries no information about it.",
"exposure": {
"verdict": "careful",
"note": "Treat as unidentified software until you match it to a process on the host."
},
"checkCommand": "sudo lsof -nP -iTCP:6779 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 6779",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=6779",
"kind": "iana"
}
]
},
{
"port": 6788,
"protocol": "tcp",
"service": "SMC-HTTP",
"oneLiner": "Registered in 2002 by Sun as smc-http — the cleartext sibling of the management console on 6789.",
"whatItIs": "IANA lists 6788/tcp and 6788/udp as smc-http, registered in November 2002 by a Sun Microsystems engineer. It is the HTTP half of the pair whose HTTPS half sits on 6789, the port Oracle's Solaris administration console still uses. There is no public protocol document for the registration itself, so on a modern network an open 6788 is either legacy Sun-derived management tooling or unrelated software using a free port.",
"exposure": {
"verdict": "never",
"note": "A management console reached over plain HTTP hands its session and credentials to anyone on the path. If the tooling still exists, use its TLS listener and firewall this one off."
},
"checkCommand": "curl -sI http://TARGET:6788/",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 6788 (smc-http)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=6788",
"kind": "iana"
}
]
},
{
"port": 6789,
"protocol": "tcp",
"service": "Oracle Solaris admin console (radg / smc-https)",
"oneLiner": "The Oracle/Sun Java Web Console over HTTPS; registered at IANA today as radg.",
"whatItIs": "IANA's current entry for 6789/tcp is radg, \"GSS-API for the Oracle Remote Administration Daemon\", registered in 2002 and updated in 2016; older service tables, including nmap's, still print the earlier names smc-https and ibm-db2-admin. In practice this is the port of the Oracle Java Web Console on Solaris, reached as https://hostname:6789, and Oracle's documentation notes the console ships configured to refuse remote connections unless the tcp_listen property is turned on. An open 6789 therefore usually means a Solaris box with its administration console deliberately opened up.",
"exposure": {
"verdict": "never",
"note": "A root-capable system administration console. Oracle's default is local-only for a reason; if it must be remote, reach it over a VPN rather than from the internet."
},
"checkCommand": "curl -skI https://TARGET:6789/",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 6789 (radg)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=6789",
"kind": "iana"
},
{
"title": "Oracle Java Web Console Reference Information — Oracle Solaris Administration: Basic Administration",
"url": "https://docs.oracle.com/cd/E26505_01/html/E29492/ewpoy.html",
"kind": "official-docs"
}
]
},
{
"port": 6792,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned at IANA, in the free 6792-6800 block.",
"whatItIs": "IANA lists 6792-6800 as Unassigned, and nmap has no service name for 6792. No registered protocol, no product default, no documented abuse. The honest answer is that the port number tells you nothing and the host has to.",
"exposure": {
"verdict": "careful",
"note": "Unknown listener. Identify the owning process before leaving it reachable from anywhere."
},
"checkCommand": "sudo lsof -nP -iTCP:6792 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 6792",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=6792",
"kind": "iana"
}
]
},
{
"port": 6839,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned at IANA, inside the 6832-6840 free block.",
"whatItIs": "IANA lists 6832-6840 as Unassigned, so 6839 has no registered service on TCP or UDP, and nmap's table records it only as unknown. There is no standard software that defaults here and no notable malware association to report. Whatever is listening chose the number arbitrarily.",
"exposure": {
"verdict": "careful",
"note": "No expected service means no expected exposure — find the process, then judge it."
},
"checkCommand": "sudo lsof -nP -iTCP:6839 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 6839",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=6839",
"kind": "iana"
}
]
},
{
"port": 6881,
"protocol": "tcp",
"service": "BitTorrent peer",
"oneLiner": "The classic BitTorrent peer-listening port — first in the 6881-6889 range clients try.",
"whatItIs": "BEP 3, the BitTorrent protocol specification, describes the convention directly: \"Common behavior is for a downloader to try to listen on port 6881 and if that port is taken try 6882, then 6883, etc. and give up after 6889.\" The port carries peer-to-peer connections in the swarm, not tracker traffic, and it is an inbound listener so other peers can reach you. IANA never registered it — the whole 6869-6887 block is Unassigned — and most modern clients now randomise the port or take it from a UPnP mapping, so 6881 mainly turns up on older or default-configured clients.",
"exposure": {
"verdict": "careful",
"note": "The port is meant to be reachable, and a working swarm needs it, but an open 6881 publicly advertises that this host runs BitTorrent and is routinely logged by swarm monitors. Expose it deliberately, on a host where that is fine."
},
"checkCommand": "nc -vz TARGET 6881",
"links": [
{
"title": "BEP 3 — The BitTorrent Protocol Specification",
"url": "https://www.bittorrent.org/beps/bep_0003.html",
"kind": "spec"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 6881",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=6881",
"kind": "iana"
}
]
},
{
"port": 6896,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Not registered with IANA and not tied to any well-known service — whatever answers here is site-specific.",
"whatItIs": "6896 has no entry in the IANA service name and port number registry, in either transport. Nmap's services file lists it as \"unknown\" with an open-frequency of 0.000152, which puts it among the ports it almost never sees open in internet-wide scans. There is no established software, protocol, or malware family that claims it. If it is listening on your host, the answer comes from the process table, not from a port list.",
"exposure": {
"verdict": "careful",
"note": "An unregistered port tells you nothing about its risk; identify the owning process with lsof or ss before deciding whether it should be reachable."
},
"checkCommand": "sudo lsof -nP -iTCP:6896 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 6896",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=6896",
"kind": "iana"
}
]
},
{
"port": 6901,
"protocol": "tcp",
"service": "KasmVNC (IANA: jetstream)",
"oneLiner": "In practice a KasmVNC browser desktop; on paper, Novell's Jetstream messaging protocol.",
"whatItIs": "IANA registered 6901/tcp as \"jetstream\" (Novell Jetstream messaging protocol) in 2010, but that is not what you find on a modern scan. KasmVNC and the Kasm Workspaces container images publish their web desktop on 6901 — the documented run line is `docker run -p 6901:6901 kasmweb/firefox` and the desktop is then reachable at https://host:6901 with a container user such as kasm_user. Kasm's own fixed-infrastructure docs use the same port when registering a standalone KasmVNC server. Seeing it open means someone is running a browser-accessible remote desktop.",
"exposure": {
"verdict": "never",
"note": "It is a full remote desktop, and the stock container images ship with well-known default credentials; publish it through the Kasm gateway or a reverse proxy with real authentication, not directly."
},
"checkCommand": "curl -kI https://TARGET:6901/",
"links": [
{
"title": "KasmVNC source repository",
"url": "https://github.com/kasmtech/KasmVNC",
"kind": "github"
},
{
"title": "Kasm workspaces-images — manual container deployment on 6901",
"url": "https://github.com/kasmtech/workspaces-images",
"kind": "github"
},
{
"title": "Kasm Workspaces — Fixed Infrastructure (KasmVNC on port 6901)",
"url": "https://www.kasmweb.com/docs/latest/how_to/fixed_infrastructure.html",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 6901",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=6901",
"kind": "iana"
}
]
},
{
"port": 6969,
"protocol": "both",
"service": "BitTorrent tracker (IANA: acmsoda)",
"oneLiner": "The customary BitTorrent tracker port — announce and scrape traffic from torrent clients.",
"whatItIs": "IANA has 6969 registered as \"acmsoda\" on both TCP and UDP, a registration with no public protocol behind it. What actually runs there is BitTorrent tracker software: opentracker binds 0.0.0.0:6969 and [::1]:6969 with no configuration options given, and countless `http://tracker.example:6969/announce` and `udp://tracker.example:6969/announce` URLs in torrent files follow that convention. A tracker only brokers peer lists — it does not carry file content — so an open 6969 means someone is coordinating swarms, not serving data.",
"exposure": {
"verdict": "fine",
"note": "Public trackers are public by design; the exposure question is policy and bandwidth (open trackers attract heavy unsolicited announce traffic), not confidentiality."
},
"checkCommand": "curl -sI http://TARGET:6969/announce",
"links": [
{
"title": "opentracker — open and free BitTorrent tracker (binds 6969 by default)",
"url": "https://erdgeist.org/arts/software/opentracker/",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 6969",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=6969",
"kind": "iana"
}
]
},
{
"port": 7000,
"protocol": "tcp",
"service": "AirPlay receiver",
"oneLiner": "An AirPlay receiver: an Apple TV, HomePod, AirPlay-capable TV, or a Mac with AirPlay Receiver turned on.",
"whatItIs": "Apple's AirPlay control channel listens on TCP 7000; the device advertises itself over mDNS (_airplay._tcp) and clients then talk HTTP-ish RTSP to this port to negotiate screen mirroring and audio streaming. It turns up on home-network scans from Apple TVs, HomePods, and third-party TVs with AirPlay 2, and on Macs since macOS Monterey where AirPlay Receiver is a Sharing toggle. Note that IANA registers 7000 to afs3-fileserver, not to Apple, so the registry name on your scanner output is usually wrong here.",
"exposure": {
"verdict": "never",
"note": "AirPlay is a LAN protocol with weak-to-optional pairing and has had a run of remote code execution bugs (the 2025 AirBorne set), so it has no business being reachable from the internet."
},
"checkCommand": "curl -s -m 3 http://TARGET:7000/info | head -c 200",
"links": [
{
"title": "Apple — TCP and UDP ports used by Apple software products (7000 = AirPlay)",
"url": "https://support.apple.com/en-us/103229",
"kind": "official-docs"
},
{
"title": "openairplay/airplay-spec — unofficial AirPlay protocol specification",
"url": "https://github.com/openairplay/airplay-spec",
"kind": "github"
},
{
"title": "IANA port registry — 7000 (registered as afs3-fileserver)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=7000",
"kind": "iana"
}
],
"ianaName": "afs3-fileserver"
},
{
"port": 7001,
"protocol": "both",
"service": "Oracle WebLogic admin listen / AFS callback",
"oneLiner": "Almost always Oracle WebLogic's default listen port; the registration belongs to AFS callbacks.",
"whatItIs": "IANA assigns 7001 to afs3-callback, the port an AFS cache manager listens on so file servers can call back and invalidate cached data — AFS carries that over UDP via the Rx protocol. On TCP, what you find in practice is Oracle WebLogic Server: Oracle's Fusion Middleware port table lists 7001 as the default listen port for the Administration Server. That console and the T3 protocol behind it have been the subject of a long run of deserialization remote-code-execution advisories, which is why 7001 draws constant internet-wide scanning. Apache Cassandra also defaults its encrypted internode port (ssl_storage_port) to 7001.",
"exposure": {
"verdict": "never",
"note": "A WebLogic admin listener on a public IP is an administrative plane with a long RCE history; keep it on a management network behind a proxy that terminates authentication."
},
"checkCommand": "curl -sI http://TARGET:7001/console",
"links": [
{
"title": "Oracle Fusion Middleware — Default Port Numbers (WebLogic Admin Server 7001)",
"url": "https://docs.oracle.com/en/middleware/fusion-middleware/12.2.1.4/asadm/port-numbers.html",
"kind": "official-docs"
},
{
"title": "OpenAFS Administration Guide",
"url": "https://docs.openafs.org/AdminGuide/index.html",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 7001",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=7001",
"kind": "iana"
}
]
},
{
"port": 7002,
"protocol": "both",
"service": "Oracle WebLogic SSL listen / AFS Protection Server",
"oneLiner": "WebLogic's default SSL listen port on TCP; AFS's users-and-groups database in the registration.",
"whatItIs": "The IANA name is afs3-prserver, the AFS Protection Server that holds the cell's user and group database and hands out protection-database IDs; like the rest of AFS it speaks Rx over UDP. On TCP, Oracle's Fusion Middleware port table gives 7002 as the default SSL listen port for the WebLogic Administration Server, the TLS twin of 7001. A host with both 7001 and 7002 open is nearly always a WebLogic domain, not an AFS cell.",
"exposure": {
"verdict": "never",
"note": "TLS does not change what it is — a WebLogic administration endpoint. Keep it on a management network; internet-facing WebLogic admin ports are routinely mass-exploited."
},
"checkCommand": "curl -kI https://TARGET:7002/console",
"links": [
{
"title": "Oracle Fusion Middleware — Default Port Numbers (WebLogic SSL listen 7002)",
"url": "https://docs.oracle.com/en/middleware/fusion-middleware/12.2.1.4/asadm/port-numbers.html",
"kind": "official-docs"
},
{
"title": "OpenAFS Administration Guide",
"url": "https://docs.openafs.org/AdminGuide/index.html",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 7002",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=7002",
"kind": "iana"
}
]
},
{
"port": 7004,
"protocol": "both",
"service": "AFS Authentication Server (kaserver)",
"oneLiner": "AFS's legacy built-in Kerberos v4 authentication server — long deprecated in OpenAFS.",
"whatItIs": "IANA registers 7004 as afs3-kaserver, the AFS/Kerberos authentication service. The kaserver was AFS's own Kerberos v4 key distribution centre, issuing the tokens an AFS client needs before a file server will serve it. OpenAFS deprecated it in favour of a real Kerberos 5 KDC (MIT or Heimdal), so a live 7004 usually means an old, unmigrated AFS cell rather than a current deployment. AFS traffic here is Rx over UDP, so a TCP-only scan will typically show nothing even when the service is running.",
"exposure": {
"verdict": "never",
"note": "Kerberos v4 is obsolete and its key exchange is not considered sound; a reachable kaserver is an authentication service that should have been retired, not firewalled."
},
"checkCommand": "sudo nmap -sU -p 7004 TARGET",
"links": [
{
"title": "OpenAFS Administration Guide",
"url": "https://docs.openafs.org/AdminGuide/index.html",
"kind": "official-docs"
},
{
"title": "OpenAFS source repository",
"url": "https://github.com/openafs/openafs",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 7004",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=7004",
"kind": "iana"
}
]
},
{
"port": 7007,
"protocol": "both",
"service": "AFS Basic OverSeer Server (bosserver)",
"oneLiner": "The AFS BOS Server — the process that starts, stops, and restarts every other AFS server daemon.",
"whatItIs": "IANA registers 7007 as afs3-bos, the basic overseer process. bosserver runs on every AFS file and database server, reads BosConfig to know which daemons to keep alive, and answers `bos` commands to start, stop, restart, and salvage them. It is the control plane of an AFS cell: whoever can issue authenticated bos commands controls what runs on the server. Like the rest of AFS it uses Rx over UDP.",
"exposure": {
"verdict": "never",
"note": "This is remote process control for the whole cell; restrict it to the AFS server network and rely on Kerberos-authenticated admin principals, never on reachability alone."
},
"checkCommand": "bos status TARGET -noauth",
"links": [
{
"title": "OpenAFS Reference — bosserver(8)",
"url": "https://docs.openafs.org/Reference/8/bosserver.html",
"kind": "official-docs"
},
{
"title": "OpenAFS source repository",
"url": "https://github.com/openafs/openafs",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 7007",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=7007",
"kind": "iana"
}
]
},
{
"port": 7019,
"protocol": "tcp",
"service": "Doceri drawing service control",
"oneLiner": "Registered to Doceri's screencasting/whiteboard product — a control channel for a tool that is effectively gone.",
"whatItIs": "IANA registered 7019 in April 2011 as doceri-ctl on TCP (\"doceri drawing service control\") and doceri-view on UDP (\"doceri drawing service screen view\"). Doceri was an iPad interactive-whiteboard and screencasting product with a companion desktop agent, so the TCP side carried tablet-to-desktop control and the UDP side the screen feed. The vendor's site no longer answers, and the product appears defunct, so a listener on 7019 today is far more likely to be an unrelated application that picked the number than a Doceri install.",
"exposure": {
"verdict": "careful",
"note": "Remote screen control on an abandoned, unpatched product is not something to expose; confirm what is actually listening before treating this as Doceri at all."
},
"checkCommand": "nc -vz TARGET 7019",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 7019",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=7019",
"kind": "iana"
}
]
},
{
"port": 7024,
"protocol": "both",
"service": "Vormetric service (vmsvc)",
"oneLiner": "Registered in 2005 to Vormetric's data-security platform, now part of Thales CipherTrust.",
"whatItIs": "IANA lists 7024 as vmsvc, \"Vormetric service\", registered in mid-2005. Vormetric's transparent-encryption agents on protected hosts talk back to a central Data Security Manager for policy and key material; this port and its sibling 7025 belong to that agent-to-manager channel. Vormetric was acquired by Thales and the platform is now sold as CipherTrust, so the port survives mainly in older Vormetric Data Security Platform deployments. It is rare on public scans.",
"exposure": {
"verdict": "never",
"note": "It is the channel between an encryption agent and the key/policy manager; keep it inside the datacentre network with mutual TLS as the vendor documents, never on a public interface."
},
"checkCommand": "nc -vz TARGET 7024",
"links": [
{
"title": "Thales — Vormetric Data Security Platform",
"url": "https://cpl.thalesgroup.com/encryption/vormetric-data-security-platform",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 7024",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=7024",
"kind": "iana"
}
]
},
{
"port": 7025,
"protocol": "both",
"service": "Vormetric Service II (vmsvc-2)",
"oneLiner": "The second Vormetric agent port on paper; in mail environments, Zimbra's LMTP listener in practice.",
"whatItIs": "IANA registers 7025 as vmsvc-2, \"Vormetric Service II\", from the same 2005 assignment as 7024, serving the same agent-to-Data-Security-Manager role in what is now the Thales CipherTrust line. The other common occupant is Zimbra Collaboration, whose mailbox server accepts LMTP delivery from its MTA on 7025 (zimbraLmtpBindPort) — so on a mail host, 7025 open next to 25 and 7071 means Zimbra, not Vormetric. Neither service belongs on a public interface.",
"exposure": {
"verdict": "never",
"note": "LMTP has no authentication and accepts mail for local delivery; the Vormetric reading is a key-management channel. Either way this is an internal-only port."
},
"checkCommand": "nc -vz TARGET 7025",
"links": [
{
"title": "Thales — Vormetric Data Security Platform",
"url": "https://cpl.thalesgroup.com/encryption/vormetric-data-security-platform",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 7025",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=7025",
"kind": "iana"
}
]
},
{
"port": 7050,
"protocol": "tcp",
"service": "Hyperledger Fabric orderer",
"oneLiner": "The default gRPC listen port for a Hyperledger Fabric ordering node.",
"whatItIs": "7050 is not registered with IANA. It is the Hyperledger Fabric convention: an orderer's General.ListenPort defaults to 7050, and Fabric's production ordering-node checklist documents it as the port the orderer listens on for client and peer gRPC traffic. Peers submit endorsed transactions here and pull blocks from it, so on a Fabric network it is the busiest single endpoint. If you see 7050 open it is almost certainly a blockchain node, usually in a Docker Compose or Kubernetes deployment alongside peers on 7051.",
"exposure": {
"verdict": "careful",
"note": "Fabric expects mutual TLS on this endpoint; exposing it without client-certificate enforcement puts channel membership and block delivery in reach of anyone who can connect."
},
"checkCommand": "nc -vz TARGET 7050",
"links": [
{
"title": "Hyperledger Fabric — Checklist for a production ordering node (ListenPort 7050)",
"url": "https://hyperledger-fabric.readthedocs.io/en/latest/deployorderer/ordererchecklist.html",
"kind": "official-docs"
},
{
"title": "Hyperledger Fabric source repository",
"url": "https://github.com/hyperledger/fabric",
"kind": "github"
}
]
},
{
"port": 7051,
"protocol": "tcp",
"service": "Hyperledger Fabric peer",
"oneLiner": "The default gRPC listen port for a Hyperledger Fabric peer node.",
"whatItIs": "Like 7050, this port has no IANA assignment; it is Fabric's default. A peer's listen address is 7051, where it receives endorsement proposals from client SDKs, gossips with other peers, and serves the event delivery service (older releases split events onto 7053, and chaincode containers dial back on 7052). Fabric's sample networks map it straight through in Docker, so a scan of a blockchain host commonly shows 7051 on each peer with 7050 on the orderer.",
"exposure": {
"verdict": "careful",
"note": "Peers hold the ledger and the chaincode endpoints; run with TLS and client-certificate authentication and restrict it to the network's own organizations rather than the open internet."
},
"checkCommand": "nc -vz TARGET 7051",
"links": [
{
"title": "Hyperledger Fabric source repository",
"url": "https://github.com/hyperledger/fabric",
"kind": "github"
},
{
"title": "Hyperledger Fabric documentation",
"url": "https://hyperledger-fabric.readthedocs.io/en/latest/",
"kind": "official-docs"
}
]
},
{
"port": 7070,
"protocol": "tcp",
"service": "ARCP / RealServer RTSP / Openfire HTTP-bind",
"oneLiner": "Historically RealServer's alternate RTSP port; today most often Openfire's unencrypted BOSH and WebSocket endpoint.",
"whatItIs": "IANA registers 7070 as arcp, a name with no public specification behind it; Nmap labels the port realserver because RealNetworks' RealServer used it as an alternate RTSP listener, and it is one of the more frequently open ports in that range. The current common occupant is Openfire, the XMPP server, whose install guide names 7070 as the unencrypted HTTP-bind (BOSH) and WebSocket port and 7443 as its TLS equivalent, with the explicit recommendation to use only 7443. So a live 7070 is usually a chat server offering a plaintext web-client transport.",
"exposure": {
"verdict": "never",
"note": "Openfire's own documentation recommends encrypted connections on 7443 only — 7070 carries XMPP authentication and messages in cleartext HTTP."
},
"checkCommand": "curl -sI http://TARGET:7070/http-bind/",
"links": [
{
"title": "Openfire Installation Guide — 7070 unencrypted BOSH/WebSocket, 7443 encrypted",
"url": "https://download.igniterealtime.org/openfire/docs/5.0.0/documentation/install-guide.html",
"kind": "official-docs"
},
{
"title": "Openfire source repository",
"url": "https://github.com/igniterealtime/Openfire",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 7070",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=7070",
"kind": "iana"
}
]
},
{
"port": 7080,
"protocol": "tcp",
"service": "LiteSpeed WebAdmin (IANA: empowerid)",
"oneLiner": "The LiteSpeed / OpenLiteSpeed WebAdmin console — a web server's administration GUI.",
"whatItIs": "IANA registered 7080 in 2008 as empowerid, \"EmpowerID Communication\", which you will effectively never meet. What actually listens on 7080 is the LiteSpeed Web Server and OpenLiteSpeed WebAdmin console: its default admin listener is `*:7080`, reached over HTTPS with a self-signed certificate, and LiteSpeed's troubleshooting docs tell you to check that value when the console is unreachable. From that console you can restart the server, reload configuration, manage virtual hosts, and read logs. 7080 also turns up generally as an alternate HTTP port on hosts that already use 80 and 8080.",
"exposure": {
"verdict": "never",
"note": "It is full administrative control of a web server, historically shipped with a default admin password; bind it to localhost or a management network and reach it over a tunnel."
},
"checkCommand": "curl -kI https://TARGET:7080/",
"links": [
{
"title": "LiteSpeed docs — WebAdmin Console troubleshooting (default admin listener *:7080)",
"url": "https://docs.litespeedtech.com/lsws/ts-webadmin/",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 7080",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=7080",
"kind": "iana"
}
]
},
{
"port": 7100,
"protocol": "both",
"service": "X Font Service (xfs)",
"oneLiner": "The X font server — a legacy daemon that hands rasterized fonts to X11 clients over the network.",
"whatItIs": "IANA registers 7100 as font-service, and the xfs man page confirms the daemon's default port number is 7100. In the X11 model an X server or client with `FontPath` set to `tcp/host:7100` fetches font metrics and glyphs from xfs rather than from local files. Modern desktops render fonts client-side through fontconfig and Xft, so xfs is effectively obsolete; distributions that still ship it default to a local socket or `-nolisten tcp`. An open 7100 today is either a very old X installation or an unrelated application on the number.",
"exposure": {
"verdict": "never",
"note": "xfs has no meaningful authentication and is unmaintained legacy code with a history of remote overflow bugs; there is no reason to have it reachable off the host."
},
"checkCommand": "fslsfonts -server TARGET:7100",
"links": [
{
"title": "xfs(1) — X font server manual page (default port 7100)",
"url": "https://xorg.freedesktop.org/archive/X11R7.5/doc/man/man1/xfs.1.html",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 7100",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=7100",
"kind": "iana"
}
]
},
{
"port": 7103,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "No IANA registration and no established service — an application-specific listener if you find it open.",
"whatItIs": "7103 is absent from the IANA registry on both TCP and UDP; the neighbouring assignments are 7100 (X Font Service) and 7101 (Embedded Light Control Network). Nmap carries it as \"unknown\" with an open-frequency of 0.000304, so it is seen occasionally in wide scans but with no consistent service behind it. Treat it as an arbitrary high port chosen by whatever software is running.",
"exposure": {
"verdict": "careful",
"note": "Nothing about the number tells you the risk; identify the listening process first, then apply that service's rules."
},
"checkCommand": "sudo lsof -nP -iTCP:7103 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 7103",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=7103",
"kind": "iana"
}
]
},
{
"port": 7106,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unregistered with IANA; no well-known protocol claims it.",
"whatItIs": "There is no IANA assignment for 7106 in either transport — the closest entries are 7107 (reserved on TCP, AES-X170 on UDP). Nmap lists it as \"unknown\" with an open-frequency of 0.000380, low but not zero, which is what you would expect from assorted in-house and vendor services picking a free number. No documented software defaults to it.",
"exposure": {
"verdict": "careful",
"note": "Unknown port, unknown service: enumerate the process and its authentication before deciding what may reach it."
},
"checkCommand": "sudo lsof -nP -iTCP:7106 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 7106",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=7106",
"kind": "iana"
}
]
},
{
"port": 7123,
"protocol": "tcp",
"service": "SNIF relay control",
"oneLiner": "Control connection for SNIF, an SNI-based end-to-end TLS forwarding relay.",
"whatItIs": "IANA assigned 7123 to VESvault Corp in December 2021 as snif, referencing draft-zubov-snif section 4.3: the TCP port is the SNIF end-to-end TLS relay control connection, and the UDP registration covers the same relay over QUIC. SNIF lets a device behind NAT allocate a public hostname, obtain a publicly trusted certificate for it, and accept inbound TLS connections through a relay that forwards by SNI without ever holding the private key. A connector on the device keeps the control connection to the relay open; the relay is the side that listens on 7123.",
"exposure": {
"verdict": "fine",
"note": "A SNIF relay is meant to be publicly reachable, and the design keeps the TLS private key on the end device so the relay only forwards ciphertext."
},
"checkCommand": "nc -vz TARGET 7123",
"links": [
{
"title": "draft-zubov-snif — SNIF: SNI-based End-to-End TLS Forwarding",
"url": "https://datatracker.ietf.org/doc/draft-zubov-snif/",
"kind": "spec"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 7123",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=7123",
"kind": "iana"
}
]
},
{
"port": 7200,
"protocol": "both",
"service": "FODMS FLIP",
"oneLiner": "An old IANA assignment for \"FODMS FLIP\" with no public specification behind it.",
"whatItIs": "IANA registers 7200 on TCP and UDP as fodms, \"FODMS FLIP\", an assignment old enough to carry no registration date and only an individual contact name. No public protocol document, implementation, or vendor page for it is findable, which is common for assignments made in the early registry. Nmap still ships the fodms name for the port. In practice a listener on 7200 is far more likely to be an unrelated modern application choosing a round number than anything FLIP-related.",
"exposure": {
"verdict": "careful",
"note": "The registration tells you nothing useful; identify the actual process before treating the port as safe or sensitive."
},
"checkCommand": "nc -vz TARGET 7200",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 7200",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=7200",
"kind": "iana"
}
]
},
{
"port": 7201,
"protocol": "both",
"service": "DLIP",
"oneLiner": "Registered to IANA as \"DLIP\" — an undated legacy assignment with no published protocol.",
"whatItIs": "IANA lists 7201/tcp and 7201/udp as dlip, \"DLIP\", with an individual assignee and no reference document, registration date, or assignment notes. There is no public specification or known implementation to point at. Nmap carries the same name with a very low open-frequency. Like its neighbour 7200, an open 7201 in the wild should be identified from the host, not inferred from the registry name.",
"exposure": {
"verdict": "careful",
"note": "An opaque legacy name is not a risk assessment; find the owning process and judge that."
},
"checkCommand": "nc -vz TARGET 7201",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 7201",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=7201",
"kind": "iana"
}
]
},
{
"port": 7241,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "No IANA registration; nothing well-known runs here.",
"whatItIs": "7241 has no entry in the IANA service name and port number registry — the nearest assignment is 7244 (FrontRow Calypso Human Interface Control Protocol). Nmap lists it as \"unknown\" with an open-frequency of 0.000152, effectively the floor of its dataset. No documented product defaults to it, so anything listening is site-specific.",
"exposure": {
"verdict": "careful",
"note": "Unregistered and undocumented: enumerate the process, then decide. Don't assume an unnamed port is harmless."
},
"checkCommand": "sudo lsof -nP -iTCP:7241 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 7241",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=7241",
"kind": "iana"
}
]
},
{
"port": 7272,
"protocol": "both",
"service": "WatchMe Monitoring",
"oneLiner": "Registered in 2005 for WatchMe Monitoring; rare on scans and with no public protocol documentation.",
"whatItIs": "IANA registers 7272 on TCP and UDP as watchme-7272, \"WatchMe Monitoring 7272\", assigned in August 2005 to an individual contact. It is one of a small family of WatchMe registrations in the 727x range. No public specification or current product page for the protocol is findable, and Nmap's open-frequency for it sits at the bottom of its scale. Anything listening on 7272 today should be identified locally rather than assumed to be WatchMe.",
"exposure": {
"verdict": "careful",
"note": "Monitoring agents typically expose host state and sometimes remote actions; without documentation, treat it as internal-only until you know what it is."
},
"checkCommand": "nc -vz TARGET 7272",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 7272",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=7272",
"kind": "iana"
}
]
},
{
"port": 7278,
"protocol": "both",
"service": "OMA Dynamic Content Delivery over CBS",
"oneLiner": "An Open Mobile Alliance registration for Dynamic Content Delivery over Cell Broadcast Service.",
"whatItIs": "IANA registered 7278 in January 2008 as oma-dcdocbs, \"OMA Dynamic Content Delivery over CBS\". DCD was an Open Mobile Alliance enabler for pushing channel-based content to handsets, and this assignment covers the variant carried over the cellular Cell Broadcast Service. It belongs to operator-side mobile infrastructure of that era, not to general-purpose servers, and it is close to unseen in internet-wide scanning. If it is open on a host you administer, the listener is almost certainly something unrelated that picked the number.",
"exposure": {
"verdict": "careful",
"note": "Nothing generic runs here, so an open 7278 is an unidentified service; find the process before deciding anything about it."
},
"checkCommand": "nc -vz TARGET 7278",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 7278",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=7278",
"kind": "iana"
}
]
},
{
"port": 7281,
"protocol": "tcp",
"service": "itactionserver2",
"oneLiner": "An IANA name reservation for ITACTIONSERVER 2 and almost nothing else — a listener here is host-specific.",
"whatItIs": "IANA registers 7280 as itactionserver1 and 7281 as itactionserver2, both to an individual assignee (Brian Taylor) with no public specification attached. There is no open protocol document, no reference implementation, and no widely deployed product that advertises this port. Nmap's service-frequency data puts it at roughly 0.015% of open TCP ports, which is registry noise rather than real deployment. If you find it listening, the registration tells you nothing useful — identify the process locally instead.",
"exposure": {
"verdict": "careful",
"note": "You cannot rate a port whose service you have not identified; find the owning process with lsof or ss before deciding whether it belongs on a public interface."
},
"checkCommand": "nmap -Pn -sV -p 7281 TARGET",
"links": [
{
"title": "IANA port registry — 7281 (itactionserver2)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=7281",
"kind": "iana"
}
]
},
{
"port": 7402,
"protocol": "both",
"service": "RTPS data-distribution meta-traffic",
"oneLiner": "Registered to the RTPS discovery family behind DDS — but real DDS nodes compute their ports from the domain ID, so 7402 itself is rarely the listener.",
"whatItIs": "IANA reserves 7400-7402 for RTPS, the Real-Time Publish-Subscribe wire protocol that DDS implementations use: rtps-discovery, rtps-dd-ut (user traffic) and rtps-dd-mt (meta-traffic, this port). In practice implementations such as eProsima Fast DDS — the default middleware under ROS 2 — and RTI Connext derive their actual UDP ports from a base plus an offset for the DDS domain ID and participant index, so a scan of a live robotics or industrial fleet shows a spread of ports in the 7400 range rather than exactly 7402. Discovery traffic is mostly UDP, including multicast, so a TCP listener on 7402 is more likely something unrelated squatting the number.",
"exposure": {
"verdict": "never",
"note": "DDS discovery is unauthenticated unless the DDS Security plugins are explicitly enabled; anything reachable on the RTPS ports can enumerate participants, topics and data. Keep it on a trusted segment or a VPN."
},
"checkCommand": "sudo tcpdump -ni any 'udp portrange 7400-7500'",
"links": [
{
"title": "IANA port registry — 7402 (rtps-dd-mt)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=7402",
"kind": "iana"
},
{
"title": "eProsima Fast DDS — RTPS/DDS implementation used by ROS 2",
"url": "https://github.com/eProsima/Fast-DDS",
"kind": "github"
}
]
},
{
"port": 7435,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned at IANA — no standard service, so whatever answers here is local to that host.",
"whatItIs": "IANA lists 7432-7436 as an unassigned block; the nearest registration is 7437 (faximum). Nmap's services file carries no name for it and scores it at about 0.03% open-port frequency, so it is not a port that any common product claims by default. Listeners here are private applications, an admin-chosen port, or a container publishing something arbitrary.",
"exposure": {
"verdict": "careful",
"note": "An unassigned port is not automatically safe or unsafe — identify the process, then judge that service. Do not open it on a public interface until you know what answers."
},
"checkCommand": "sudo lsof -nP -iTCP:7435 -sTCP:LISTEN",
"links": [
{
"title": "IANA port registry — 7435 (unassigned)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=7435",
"kind": "iana"
},
{
"title": "nmap-services — the port/frequency database Nmap ships",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 7438,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "The first port of IANA's unassigned 7438-7442 block — no registered service at all.",
"whatItIs": "IANA marks 7438 through 7442 unassigned, and Nmap's database has no service name for it either, with an open-port frequency around 0.015%. There is no protocol to expect and no banner to recognise. Anything listening was configured by hand or picked by an application that wanted a free port above 1024.",
"exposure": {
"verdict": "careful",
"note": "Judge the service, not the number: resolve the owning process first, since an unregistered port often hides an admin or debug interface someone assumed nobody would find."
},
"checkCommand": "nmap -Pn -sV -p 7438 TARGET",
"links": [
{
"title": "IANA port registry — 7438 (unassigned)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=7438",
"kind": "iana"
}
]
},
{
"port": 7443,
"protocol": "tcp",
"service": "HTTPS alternate (oracleas-https)",
"oneLiner": "Registered to Oracle Application Server HTTPS, and in practice a general-purpose \"HTTPS when 443 is taken\" port.",
"whatItIs": "IANA's name for 7443 is oracleas-https, from the Oracle Application Server era. What you actually meet on a scan is a TLS listener that some appliance, Java application server, or reverse proxy was pointed at because 443 was already in use or because the process runs unprivileged. The port carries no protocol meaning of its own: the useful information is in the TLS handshake and the certificate, which will name the real service. Treat it exactly as you would 8443.",
"exposure": {
"verdict": "careful",
"note": "TLS on the wire says nothing about what is behind it — non-standard HTTPS ports very often front an admin console that was never meant to be reachable from the internet."
},
"checkCommand": "openssl s_client -connect TARGET:7443 -servername TARGET /dev/null | openssl x509 -noout -subject -issuer -dates",
"links": [
{
"title": "IANA port registry — 7443 (oracleas-https)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=7443",
"kind": "iana"
}
]
},
{
"port": 7496,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Inside IANA's unassigned 7492-7499 block — nothing is registered here.",
"whatItIs": "The whole 7492-7499 range is unassigned in the IANA registry, and Nmap has no service name for 7496, listing it at roughly 0.02% open-port frequency. No standard protocol claims it. A listener is either a bespoke application or a port chosen at random by whoever deployed the host.",
"exposure": {
"verdict": "careful",
"note": "Unknown service, unknown authentication: identify the process before allowing it through a firewall."
},
"checkCommand": "sudo lsof -nP -iTCP:7496 -sTCP:LISTEN",
"links": [
{
"title": "IANA port registry — 7496 (unassigned)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=7496",
"kind": "iana"
}
]
},
{
"port": 7512,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "The start of IANA's unassigned 7512-7541 block, just above HP OpenView's 7510.",
"whatItIs": "IANA registers 7510 (ovhpas, HP OpenView Application Server) and 7511 (pafec-lm), then leaves everything from 7512 to 7541 unassigned. Nmap carries no name for 7512 and scores it at about 0.03% of open TCP ports. Nothing standard listens here; on a host running old HP management software the neighbouring ports are worth checking, but 7512 itself has no defined role.",
"exposure": {
"verdict": "careful",
"note": "No registration means no assumptions — resolve the process and rate that, rather than the port number."
},
"checkCommand": "nmap -Pn -sV -p 7512 TARGET",
"links": [
{
"title": "IANA port registry — 7512 (unassigned)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=7512",
"kind": "iana"
}
]
},
{
"port": 7625,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "A single unassigned port wedged between INDI on 7624 and SIMCO on 7626.",
"whatItIs": "IANA assigns 7624 to indi (Instrument Neutral Distributed Interface, the astronomy device-control protocol) and 7626 to simco, but leaves 7625 unassigned. Nmap gives it no service name and an open-port frequency near 0.04%. If you find 7625 open on an observatory or astrophotography box, the interesting neighbour is 7624, not this port; on anything else it is a locally chosen number.",
"exposure": {
"verdict": "careful",
"note": "Unregistered and unidentified. Find the listening process first; adjacent INDI on 7624 is itself an unauthenticated device-control protocol that should stay on the LAN."
},
"checkCommand": "sudo lsof -nP -iTCP:7625 -sTCP:LISTEN",
"links": [
{
"title": "IANA port registry — 7625 (unassigned)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=7625",
"kind": "iana"
}
]
},
{
"port": 7627,
"protocol": "tcp",
"service": "soap-http",
"oneLiner": "IANA's \"SOAP Service Port\" — a name reservation, not a protocol anyone standardised on.",
"whatItIs": "7627 is registered as soap-http, \"SOAP Service Port\", to an individual assignee with no accompanying specification. SOAP itself is a W3C messaging format carried over ordinary HTTP, so real SOAP endpoints live on 80, 443, 8080 or whatever port their application server uses — almost never here. Nmap sees 7627 open on about 0.04% of scanned hosts. Treat a listener as an HTTP service until proven otherwise and read its response.",
"exposure": {
"verdict": "careful",
"note": "SOAP endpoints commonly expose a WSDL that enumerates every operation, and enterprise SOAP APIs often authenticate weakly or not at all; keep them behind a gateway."
},
"checkCommand": "curl -sI http://TARGET:7627/",
"links": [
{
"title": "IANA port registry — 7627 (soap-http)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=7627",
"kind": "iana"
}
]
},
{
"port": 7676,
"protocol": "tcp",
"service": "imqbrokerd (OpenMQ Port Mapper)",
"oneLiner": "The Open Message Queue broker's Port Mapper — connect and it tells you which ports its JMS services really use.",
"whatItIs": "Open Message Queue (formerly Sun/Oracle Message Queue, now Eclipse OpenMQ, the JMS provider bundled with GlassFish) starts its broker with imq.portmapper.port=7676 by default. The Port Mapper is a rendezvous service: a client connects to 7676, receives the broker's version and a table of its dynamically allocated service ports (jms, ssljms, admin, cluster), then connects to the one it needs. So finding 7676 open means a Java message broker is running, and the port itself hands you a map of the rest of it.",
"exposure": {
"verdict": "never",
"note": "The Port Mapper answers before authentication and enumerates the broker's services; a message broker is backend infrastructure and belongs on a private network, not a public IP."
},
"checkCommand": "nc -w 3 TARGET 7676 | head -c 200; echo",
"links": [
{
"title": "Eclipse OpenMQ — broker source and default.properties (imq.portmapper.port=7676)",
"url": "https://github.com/eclipse-ee4j/openmq",
"kind": "github"
},
{
"title": "IANA port registry — 7676 (imqbrokerd)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=7676",
"kind": "iana"
}
]
},
{
"port": 7725,
"protocol": "tcp",
"service": "nitrogen",
"oneLiner": "Registered as \"Nitrogen Service\" to an individual, with no public protocol behind the name.",
"whatItIs": "IANA lists 7725 as nitrogen, Nitrogen Service, assigned to Randy Lomnes. There is no published specification, RFC, or open implementation tied to that registration, and Nmap sees the port open on roughly 0.015% of hosts. The name is not the Nitrogen Erlang web framework, which serves ordinary HTTP. In practice a listener on 7725 is a private application and the registration will not identify it for you.",
"exposure": {
"verdict": "careful",
"note": "A registered name with no specification tells you nothing about authentication or encryption; identify the service before exposing it."
},
"checkCommand": "nmap -Pn -sV -p 7725 TARGET",
"links": [
{
"title": "IANA port registry — 7725 (nitrogen)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=7725",
"kind": "iana"
}
]
},
{
"port": 7741,
"protocol": "tcp",
"service": "scriptview",
"oneLiner": "IANA's \"ScriptView Network\" registration — an old vendor reservation you will rarely meet in the wild.",
"whatItIs": "7741 is registered as scriptview, ScriptView Network, to an individual assignee (Reinhard Wolf), with no public protocol document. Nmap carries the same name from the registry and puts the port at about 0.04% open-port frequency. Nothing in common server software binds it by default, so a listener is either that legacy product or an unrelated application that picked a free port.",
"exposure": {
"verdict": "careful",
"note": "No specification means no way to reason about its authentication; treat an unknown listener as internal-only until you have identified it."
},
"checkCommand": "nmap -Pn -sV -p 7741 TARGET",
"links": [
{
"title": "IANA port registry — 7741 (scriptview)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=7741",
"kind": "iana"
}
]
},
{
"port": 7744,
"protocol": "tcp",
"service": "RAQMON PDU",
"oneLiner": "The registered TCP port for RAQMON reports — real-time application QoS measurements shipped from endpoints to a collector.",
"whatItIs": "RFC 4712 defines RAQMON, an extension of the RMON family in which RAQMON Data Sources (endpoints such as IP phones or streaming clients) send session-quality reports to a RAQMON Report Collector. The RFC states that \"port number 7744 is registered with IANA for use as the default port for RAQMON PDUs over TCP\", and recommends TCP over the alternative SNMP-notification transport because TCP brings congestion control. Deployment is thin: Nmap sees the port open on about 0.015% of hosts, so most sightings are something else on a convenient number.",
"exposure": {
"verdict": "careful",
"note": "RAQMON reports carry endpoint identities and session metadata; RFC 4712 leaves confidentiality to TLS or IPsec, so an unwrapped collector on a public IP leaks telemetry and accepts forged reports."
},
"checkCommand": "nc -vz TARGET 7744",
"links": [
{
"title": "RFC 4712 — Transport Mappings for RAQMON PDU",
"url": "https://www.rfc-editor.org/rfc/rfc4712.html",
"kind": "spec"
},
{
"title": "IANA port registry — 7744 (raqmon-pdu)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=7744",
"kind": "iana"
}
]
},
{
"port": 7749,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned — it sits in the long empty 7748-7776 gap below the game-server crowd on 7777.",
"whatItIs": "IANA's last registration before this gap is 7747 (prgp, Put/Run/Get Protocol); 7748 through 7776 are unassigned, 7749 among them. Nmap has no service name for it and scores it near 0.015% open frequency. Nothing standard claims it, so treat any listener as application-specific and identify it locally.",
"exposure": {
"verdict": "careful",
"note": "Unregistered port, unknown service — resolve the owning process before making a firewall decision."
},
"checkCommand": "sudo lsof -nP -iTCP:7749 -sTCP:LISTEN",
"links": [
{
"title": "IANA port registry — 7749 (unassigned)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=7749",
"kind": "iana"
}
]
},
{
"port": 7770,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Also unassigned, seven ports below 7777 — no registered service, no default product.",
"whatItIs": "7770 falls inside IANA's unassigned 7748-7776 range and has no service name in Nmap's database, which puts it at roughly 0.015% open-port frequency. Its only notable feature is proximity: hosts running game or application servers around 7777 sometimes have neighbours in this range because an operator assigned a block by hand.",
"exposure": {
"verdict": "careful",
"note": "Nothing about the number implies safety; identify the listener, and if it belongs to a game or application server cluster, rate that service instead."
},
"checkCommand": "nmap -Pn -sV -p 7770 TARGET",
"links": [
{
"title": "IANA port registry — 7770 (unassigned)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=7770",
"kind": "iana"
}
]
},
{
"port": 7777,
"protocol": "both",
"service": "game server / cbt",
"oneLiner": "IANA calls it cbt, but everyone else knows 7777 as the default game-server port — Unreal Engine dedicated servers start here.",
"whatItIs": "Epic's documentation states that an Unreal Engine dedicated server \"listens on the localhost IP address (127.0.0.1) at port 7777\" by default, and the convention spread across the games built on it and its contemporaries, which is why 7777 is the number people reach for when standing up any self-hosted multiplayer server. Game traffic is normally UDP; a TCP listener on 7777 is more often an application server, an RCON or query interface, or something unrelated that liked the digits. The IANA registration (cbt, Core Based Trees multicast routing) has no bearing on any of this.",
"exposure": {
"verdict": "careful",
"note": "A public game server is exposed on purpose, but it is unauthenticated by design and mod or plugin layers are a repeated source of remote code execution — run it isolated, patched, and never on a machine that hosts anything else."
},
"checkCommand": "nmap -Pn -sU -sV -p 7777 TARGET",
"links": [
{
"title": "Unreal Engine — Setting Up Dedicated Servers (default port 7777)",
"url": "https://dev.epicgames.com/documentation/en-us/unreal-engine/setting-up-dedicated-servers-in-unreal-engine",
"kind": "official-docs"
},
{
"title": "IANA port registry — 7777 (cbt)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=7777",
"kind": "iana"
}
]
},
{
"port": 7778,
"protocol": "tcp",
"service": "interwise",
"oneLiner": "Registered to Interwise, but in the field it is mostly \"the port next to 7777\".",
"whatItIs": "IANA assigns 7778 to interwise, a corporate e-learning and conferencing product, with no public protocol specification. What actually shows up on scans is the sequential neighbour effect: a host already using 7777 for a game or application server takes 7778 for a second instance, a query port, or an admin channel. The registration is not a reliable identification, so read the banner and the owning process rather than the name.",
"exposure": {
"verdict": "careful",
"note": "Identify it before opening it — when 7778 is the companion of a 7777 service it is frequently the query or admin side, which is the half you least want reachable."
},
"checkCommand": "nmap -Pn -sV -p 7777-7778 TARGET",
"links": [
{
"title": "IANA port registry — 7778 (interwise)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=7778",
"kind": "iana"
}
]
},
{
"port": 7800,
"protocol": "tcp",
"service": "Apple Software Restore / JGroups cluster transport",
"oneLiner": "IANA's Apple Software Restore port, and the default bind port for JGroups clustering under Infinispan, WildFly and Keycloak.",
"whatItIs": "Two unrelated things answer here. IANA registers 7800 as asr, Apple Software Restore, the multicast disk-imaging service used to push macOS images across a lab network. Far more commonly on a server, 7800 is the JGroups TCP transport: Keycloak's documentation notes that for the embedded Infinispan cluster \"by default, port 7800 is used\" for unicast data between nodes, with failure detection at an offset of 50000 (57800). So an open 7800 on a Java application host usually means cluster members are talking to each other.",
"exposure": {
"verdict": "never",
"note": "JGroups cluster transport is not authenticated in a default configuration — a host that can reach it can attempt to join the cluster and read replicated cache contents, including sessions. Bind it to a private interface."
},
"checkCommand": "nc -vz TARGET 7800",
"links": [
{
"title": "Keycloak — Configuring distributed caches (JGroups bind port 7800)",
"url": "https://www.keycloak.org/server/caching",
"kind": "official-docs"
},
{
"title": "IANA port registry — 7800 (asr)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=7800",
"kind": "iana"
}
]
},
{
"port": 7878,
"protocol": "tcp",
"service": "Radarr",
"oneLiner": "Radarr's web UI — the movie half of a home media automation stack.",
"whatItIs": "Radarr, the movie collection manager for Usenet and BitTorrent, defaults its web server to port 7878 (its configuration provider falls back to 7878 when no port is set), which places it beside its siblings Sonarr on 8989 and Prowlarr on 9696. IANA's registration for 7878 is owms, Stonebranch's Opswise Message Service, but on a home server or NAS the overwhelmingly likely occupant is Radarr. The UI is plain HTTP unless the operator configures TLS, and the same port serves the REST API used by the rest of the stack.",
"exposure": {
"verdict": "never",
"note": "The web UI is a full admin plane — it drives downloaders and writes to the filesystem — guarded by a single API key over cleartext HTTP by default. Reach it through a VPN or an authenticating reverse proxy, never directly from the internet."
},
"checkCommand": "curl -sI http://127.0.0.1:7878/",
"links": [
{
"title": "Radarr — source repository (default port 7878 in ConfigFileProvider)",
"url": "https://github.com/Radarr/Radarr",
"kind": "github"
},
{
"title": "IANA port registry — 7878 (owms)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=7878",
"kind": "iana"
}
]
},
{
"port": 7900,
"protocol": "tcp",
"service": "noVNC (Selenium containers)",
"oneLiner": "On any CI or Selenium host this is noVNC — a browser-viewable live view into a container's desktop.",
"whatItIs": "The official Selenium Docker images publish 7900 for noVNC, so you can watch a test run by opening http://localhost:7900/?autoconnect=1&resize=scale&password=secret. It is an HTTP endpoint that proxies the container's VNC server into a web page. IANA registers 7900 as mevent, Multicast Event, but that assignment carries no implementation you are likely to meet. If 7900 is open on a build agent or a Kubernetes node, look for selenium/standalone-* or selenium/node-* containers.",
"exposure": {
"verdict": "never",
"note": "The documented default password is literally \"secret\", and access grants full interactive control of a real browser session — including whatever it is logged into. Keep it on localhost or a private network."
},
"checkCommand": "curl -sI http://127.0.0.1:7900/",
"links": [
{
"title": "SeleniumHQ/docker-selenium — noVNC on port 7900",
"url": "https://github.com/SeleniumHQ/docker-selenium",
"kind": "github"
},
{
"title": "IANA port registry — 7900 (mevent)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=7900",
"kind": "iana"
}
]
},
{
"port": 7911,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned at IANA, inside the empty 7904-7912 block — no standard service claims it.",
"whatItIs": "IANA leaves 7904 through 7912 unassigned, so 7911 has no registered name; Nmap likewise records it as unknown, open on roughly 0.04% of scanned hosts. The next registration up is 7913 (qo-secure). Nothing common binds 7911 by default, so a listener is a local choice.",
"exposure": {
"verdict": "careful",
"note": "No registration, no expectations — find the process behind it and rate that service rather than the number."
},
"checkCommand": "sudo lsof -nP -iTCP:7911 -sTCP:LISTEN",
"links": [
{
"title": "IANA port registry — 7911 (unassigned)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=7911",
"kind": "iana"
}
]
},
{
"port": 7913,
"protocol": "tcp",
"service": "qo-secure",
"oneLiner": "IANA's \"QuickObjects secure port\" — a vendor name reservation with no public protocol.",
"whatItIs": "7913 is registered as qo-secure, QuickObjects secure port, to an individual assignee (Jonas Bovin); 7914-7931 above it are unassigned. No specification or open implementation accompanies the registration, and Nmap sees the port open on about 0.015% of hosts. \"Secure\" in the registered name refers to that product's own scheme, not to any standard TLS behaviour you can rely on.",
"exposure": {
"verdict": "careful",
"note": "Do not infer encryption from the name — probe the handshake and identify the service before treating the port as safe to expose."
},
"checkCommand": "openssl s_client -connect TARGET:7913 &1 | head -20",
"links": [
{
"title": "IANA port registry — 7913 (qo-secure)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=7913",
"kind": "iana"
}
]
},
{
"port": 7920,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned — part of IANA's empty 7914-7931 block above QuickObjects.",
"whatItIs": "IANA lists 7914 through 7931 as unassigned, so 7920 has no registered service, and Nmap carries no name for it either, at roughly 0.02% open-port frequency on TCP. There is no protocol to expect. Whatever answers was configured locally or picked automatically by an application looking for a free high port.",
"exposure": {
"verdict": "careful",
"note": "Unknown service: identify the listening process, then decide. An unregistered port is a common hiding place for debug and management interfaces."
},
"checkCommand": "nmap -Pn -sV -p 7920 TARGET",
"links": [
{
"title": "IANA port registry — 7920 (unassigned)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=7920",
"kind": "iana"
}
]
},
{
"port": 7921,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "IANA has never assigned this port, and no common service is known to squat it.",
"whatItIs": "7921 falls inside the block IANA lists as 7914-7931 Unassigned, so there is no registered service name to look up. Nmap's service database has no name for it either and files it as `unknown`, seen on roughly two hundredths of a percent of scanned hosts. In practice that means anything listening here is some application's private choice of port, not a standard protocol. Identify it by its banner rather than by the number.",
"exposure": {
"verdict": "careful",
"note": "An unregistered port tells you nothing about safety — find out what the listener actually is before deciding, and treat an unidentified internet-facing service as untrusted."
},
"checkCommand": "nmap -sV -Pn -p 7921 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 7921",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=7921",
"kind": "iana"
},
{
"title": "nmap/nmap — nmap-services (port frequency database)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 7929,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned by IANA and unnamed in Nmap's database — a genuinely empty port number.",
"whatItIs": "Like its neighbours, 7929 sits in IANA's 7914-7931 Unassigned block. Nmap records it as `unknown` with an open-port frequency of about 0.00015, which puts it among the rarest ports it tracks. Nothing well-documented — no product default, no malware family — is associated with the number itself. If you find it open, the service is application-specific and must be fingerprinted.",
"exposure": {
"verdict": "careful",
"note": "There is no protocol here to judge; judge the listener. An unknown service on a public IP is a finding, not a configuration."
},
"checkCommand": "nmap -sV -Pn -p 7929 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 7929",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=7929",
"kind": "iana"
},
{
"title": "nmap/nmap — nmap-services (port frequency database)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 7937,
"protocol": "tcp",
"service": "NetWorker nsrexecd",
"oneLiner": "The backup agent daemon for Legato/EMC/Dell NetWorker — the entry point to a backup client.",
"whatItIs": "IANA leaves 7937 unassigned, but in the field it is nsrexecd, the client-side execution service of NetWorker (originally Legato, then EMC, now Dell). Every protected host runs it so the backup server can start save and recover jobs remotely, and it anchors NetWorker's service port range. Nmap names it `nsrexecd` and it is one of the more commonly seen ports in the 7900s on enterprise networks. Finding it means you found a backup client, and by extension a backup server that talks to it.",
"exposure": {
"verdict": "never",
"note": "This is a remote job-execution daemon wired into a backup fabric that can read every file on the host. It belongs on a segmented backup network, never on anything internet-facing."
},
"checkCommand": "nmap -sV -Pn -p 7937 TARGET",
"links": [
{
"title": "nmap/nmap — nmap-services (7937/tcp nsrexecd, Legato NetWorker)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 7937",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=7937",
"kind": "iana"
}
]
},
{
"port": 7938,
"protocol": "tcp",
"service": "NetWorker portmapper (lgtomapper)",
"oneLiner": "NetWorker's own portmapper, sitting next to nsrexecd on a backup client.",
"whatItIs": "7938 carries what Nmap calls `lgtomapper`, the Legato/NetWorker portmapper that tells callers which dynamic port each NetWorker service is on — the same job Sun RPC's portmapper does on 111. It is unassigned at IANA and appears almost exclusively alongside 7937 on hosts running the NetWorker client. A scan showing 7937 and 7938 together is a reliable NetWorker fingerprint.",
"exposure": {
"verdict": "never",
"note": "A portmapper enumerates the rest of the backup stack for whoever asks. Keep it inside the backup segment with the client daemon it serves."
},
"checkCommand": "nmap -sV -Pn -p 7937,7938 TARGET",
"links": [
{
"title": "nmap/nmap — nmap-services (7938/tcp lgtomapper, Legato portmapper)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 7938",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=7938",
"kind": "iana"
}
]
},
{
"port": 7999,
"protocol": "tcp",
"service": "Bitbucket SSH (IANA: irdmi2)",
"oneLiner": "Git over SSH for Bitbucket Data Center — the port in every `ssh://git@host:7999/` clone URL.",
"whatItIs": "IANA registers 7999 as irdmi2, a name almost nobody uses. What actually listens here is Bitbucket's embedded SSH server: Atlassian's own Helm chart and Docker instructions default `bitbucket.ports.ssh` to 7999, which is why Bitbucket clone URLs carry the port explicitly while the web UI sits on 7990. It is a normal SSH server implemented in Java, speaking only the Git commands, not a shell.",
"exposure": {
"verdict": "fine",
"note": "Public Git-over-SSH is the intended deployment: it is public-key only, and the SSH server exposes Git upload/receive-pack rather than a login shell. Pair it with the usual SSH hygiene and keep the 7990 web port behind whatever fronts it."
},
"checkCommand": "ssh -p 7999 -o BatchMode=yes git@TARGET",
"links": [
{
"title": "Atlassian data-center-helm-charts — Bitbucket chart (bitbucket.ports.ssh defaults to 7999)",
"url": "https://github.com/atlassian/data-center-helm-charts/blob/main/src/main/charts/bitbucket/README.md",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 7999",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=7999",
"kind": "iana"
}
],
"ianaName": "irdmi2"
},
{
"port": 8000,
"protocol": "tcp",
"service": "Python http.server, Django runserver",
"oneLiner": "The default port for ad-hoc Python HTTP servers and Django's development server.",
"whatItIs": "`python -m http.server` binds 8000 with no arguments, and `django-admin runserver` defaults to 127.0.0.1:8000. It is also a generic second-choice HTTP port for app servers behind a proxy. IANA registers 8000 as irdmi, which has nothing to do with any of this.",
"exposure": {
"verdict": "careful",
"note": "A real app server behind a reverse proxy is fine on 8000; a development server is not. Python's own docs say `http.server` is not for production, and Django prints a do-not-use-in-production warning at startup — an exposed 8000 is usually one of those two, with a directory listing or a debug page open to anyone."
},
"checkCommand": "curl -sI http://localhost:8000/",
"links": [
{
"title": "Python docs — http.server (default port 8000, security notes)",
"url": "https://docs.python.org/3/library/http.server.html",
"kind": "official-docs"
},
{
"title": "Django — django-admin runserver",
"url": "https://docs.djangoproject.com/en/stable/ref/django-admin/",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 8000",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=8000",
"kind": "iana"
}
],
"ianaName": "irdmi"
},
{
"port": 8001,
"protocol": "tcp",
"service": "kubectl proxy, HTTP alternate",
"oneLiner": "The default port for `kubectl proxy`, and the next HTTP port people grab after 8000.",
"whatItIs": "IANA registers 8001 as vcom-tunnel, which you will essentially never meet. What you do meet is `kubectl proxy`, whose `--port` flag defaults to 8001 — it opens an authenticated channel to the Kubernetes API server and serves it locally. The rest of the time 8001 is simply the second HTTP port on a box that already used 8000, common in Docker Compose files and multi-service dev setups.",
"exposure": {
"verdict": "never",
"note": "`kubectl proxy` authenticates to the cluster on your behalf and applies no authentication of its own, so anyone who reaches it inherits your cluster credentials. It binds 127.0.0.1 by default — leave it there."
},
"checkCommand": "curl -sI http://127.0.0.1:8001/api/",
"links": [
{
"title": "Kubernetes — kubectl proxy (--port default 8001)",
"url": "https://kubernetes.io/docs/reference/kubectl/generated/kubectl_proxy/",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 8001",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=8001",
"kind": "iana"
}
],
"ianaName": "vcom-tunnel"
},
{
"port": 8002,
"protocol": "tcp",
"service": "Teradata ORDBMS (IANA), HTTP alternate",
"oneLiner": "Registered to Teradata, used in practice as yet another alternate HTTP port.",
"whatItIs": "IANA assigns 8002/tcp and /udp to teradataordbms, the Teradata database. Outside Teradata shops the registration means little: 8002 is part of the 8000-8100 band that application servers, containers and dev tooling occupy when 8000 and 8001 are taken, so a scan hit is usually plain HTTP. Nmap's data ranks it as uncommon but not rare. Read the banner before assuming either answer.",
"exposure": {
"verdict": "careful",
"note": "Both plausible occupants argue for caution: a database listener should never face the internet, and an HTTP service parked on a high port is often something that assumed a proxy would protect it."
},
"checkCommand": "curl -sI http://TARGET:8002/",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 8002 (teradataordbms)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=8002",
"kind": "iana"
},
{
"title": "nmap/nmap — nmap-services (8002/tcp teradataordbms)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
],
"ianaName": "teradataordbms"
},
{
"port": 8007,
"protocol": "tcp",
"service": "AJP 1.2 (legacy), IANA: warppipe",
"oneLiner": "The old Apache JServ Protocol port — the ancestor of Tomcat's AJP connector on 8009.",
"whatItIs": "IANA registers 8007 as warppipe, an I/O-oriented cluster computing product. Nmap names it `ajp12`, after the first version of the Apache JServ Protocol that Tomcat and JServ once served here before AJP/1.3 settled on 8009. Modern Tomcat has no AJP 1.2 connector, so a live 8007 is either something very old in a Java stack or an unrelated application that picked a free port near 8000.",
"exposure": {
"verdict": "never",
"note": "AJP in any version is a trusted back-channel between a web server and a servlet container, with no authentication of its own — the Ghostcat class of bug (CVE-2020-1938 on 8009) is what an exposed AJP connector costs."
},
"checkCommand": "nmap -sV -Pn -p 8007 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 8007 (warppipe)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=8007",
"kind": "iana"
},
{
"title": "Apache Tomcat 9 — The AJP Connector",
"url": "https://tomcat.apache.org/tomcat-9.0-doc/config/ajp.html",
"kind": "official-docs"
},
{
"title": "nmap/nmap — nmap-services (8007/tcp ajp12)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
],
"ianaName": "warppipe"
},
{
"port": 8008,
"protocol": "tcp",
"service": "HTTP alternate; Google Cast device HTTP",
"oneLiner": "A registered HTTP alternate port, and the plaintext HTTP interface of every Chromecast.",
"whatItIs": "IANA registers 8008 as http-alt, the same designation 8080 carries, so it is a legitimate second home for web servers — IBM HTTP Server and many appliances use it. On a home network the far more likely answer is a Google Cast device: pychromecast's DIAL client builds its device URLs as `http://:8008`, and that endpoint returns the device's `eureka_info` — name, model, firmware, Wi-Fi details — alongside the TLS control channel on 8009. Nmap sees 8008 open on roughly 0.7% of scanned hosts, making it one of the busier alternate HTTP ports.",
"exposure": {
"verdict": "careful",
"note": "As a web port it is as safe as the app behind it. As a Cast device it is not: the 8008 interface answers device-information and setup requests without authentication, so it must stay on the LAN."
},
"checkCommand": "curl -s http://TARGET:8008/setup/eureka_info",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 8008 (http-alt)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=8008",
"kind": "iana"
},
{
"title": "home-assistant-libs/pychromecast — dial.py (FORMAT_BASE_URL_HTTP = \"http://{}:8008\")",
"url": "https://github.com/home-assistant-libs/pychromecast/blob/master/pychromecast/dial.py",
"kind": "github"
}
],
"ianaName": "http-alt"
},
{
"port": 8009,
"protocol": "tcp",
"service": "Google Cast (Chromecast) control — or Tomcat AJP",
"oneLiner": "On a home network this is a Chromecast's TLS control channel; in a datacenter it is far more likely Tomcat's AJP connector.",
"whatItIs": "Chromecast and Google Cast-enabled devices (Nest Hub, Android TV, cast-capable TVs) listen on TCP 8009 for the CASTV2 protocol — protobuf messages inside TLS, with the device presenting a Google-issued client certificate. The same port number is the conventional default for Apache Tomcat's AJP connector, which fronts Tomcat from httpd or nginx, so context decides which one you found. IANA itself assigns 8009/tcp to nvme-disc (NVMe over Fabrics Discovery), which is a third possibility on storage networks.",
"exposure": {
"verdict": "never",
"note": "The Cast control channel does no user authentication — anyone who can reach it can launch and control playback — and exposed Tomcat AJP is how CVE-2020-1938 (Ghostcat) reads files out of the webapp."
},
"checkCommand": "openssl s_client -connect TARGET:8009 /dev/null | openssl x509 -noout -subject -issuer",
"links": [
{
"title": "IANA port registry — 8009",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=8009",
"kind": "iana"
},
{
"title": "home-assistant-libs/pychromecast — CASTV2 client (shows port=8009)",
"url": "https://github.com/home-assistant-libs/pychromecast",
"kind": "github"
},
{
"title": "Apache Tomcat 9 — The AJP Connector",
"url": "https://tomcat.apache.org/tomcat-9.0-doc/config/ajp.html",
"kind": "official-docs"
},
{
"title": "Chromium — media_sink_internal.h (\"Default Cast control port\", kCastControlPort = 8009)",
"url": "https://chromium.googlesource.com/chromium/src/+/HEAD/components/media_router/common/discovery/media_sink_internal.h",
"kind": "official-docs"
}
],
"ianaName": "nvme-disc"
},
{
"port": 8010,
"protocol": "tcp",
"service": "Buildbot web UI (IANA: Reserved)",
"oneLiner": "Reserved at IANA; in practice the Buildbot master's web interface.",
"whatItIs": "IANA marks 8010 Reserved rather than assigning it, which leaves the number to convention. Buildbot's own tutorial has you open `http://localhost:8010/` after starting a master, so a CI host with 8010 open is very often a Buildbot. Nmap's database labels it `xmpp` for XMPP file transfer, another historical use. Both are guesses until you read the response.",
"exposure": {
"verdict": "careful",
"note": "A Buildbot web UI shows build logs, worker names and configuration to anonymous visitors unless authentication is configured, and build output routinely contains internal hostnames and secrets."
},
"checkCommand": "curl -sI http://TARGET:8010/",
"links": [
{
"title": "Buildbot — First Run tutorial (web status on port 8010)",
"url": "https://docs.buildbot.net/current/tutorial/firstrun.html",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 8010 (Reserved)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=8010",
"kind": "iana"
}
]
},
{
"port": 8011,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned by IANA — an overflow HTTP port and nothing more standardised than that.",
"whatItIs": "IANA lists 8011-8014 as Unassigned, and Nmap has no service name for 8011 either. Its only real characteristic is its neighbourhood: it sits in the 8000-8100 band that people work through when they need one more HTTP listener, so a hit is most often an application's Nth web port rather than a defined protocol. Fingerprint it; the number carries no meaning.",
"exposure": {
"verdict": "careful",
"note": "Unassigned means no protocol-level judgement is possible. If it answers HTTP, treat it like any other unproxied app port and check whether it expected to be private."
},
"checkCommand": "curl -sI http://TARGET:8011/",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 8011",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=8011",
"kind": "iana"
}
]
},
{
"port": 8015,
"protocol": "tcp",
"service": "cfg-cloud (Configuration Cloud Service)",
"oneLiner": "Registered to a Configuration Cloud Service, and almost never seen in the wild.",
"whatItIs": "IANA assigns 8015/tcp the name cfg-cloud, \"Configuration Cloud Service\"; the matching UDP port is merely Reserved. Nmap carries the same name and ranks it among its least frequently observed ports. There is no widely deployed software known for this port, so an open 8015 is nearly always an ordinary application that chose a free number near 8000.",
"exposure": {
"verdict": "careful",
"note": "The registration tells you nothing useful about what is really listening. Identify the service before deciding whether it should be reachable."
},
"checkCommand": "nmap -sV -Pn -p 8015 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 8015 (cfg-cloud)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=8015",
"kind": "iana"
}
],
"ianaName": "cfg-cloud"
},
{
"port": 8016,
"protocol": "tcp",
"service": "Beckhoff Secure ADS (ads-s)",
"oneLiner": "Beckhoff's secure ADS channel — an industrial control protocol, on an industrial network.",
"whatItIs": "IANA assigned 8016/tcp to Beckhoff Automation in 2019 as ads-s, for the Automation Device Specification protocol that TwinCAT devices use to talk to each other and to engineering workstations. ADS is the control plane of a Beckhoff PLC: reading and writing process variables, and starting and stopping the runtime. The 8016 registration specifically covers the secure, certificate-authenticated variant; routine ADS traffic uses a different, unregistered port, so 8016 appears where Secure ADS has been turned on.",
"exposure": {
"verdict": "never",
"note": "This is a PLC command channel. Even in its secure form it belongs on a segmented OT network behind a firewall, reached through a jump host — an exposed ADS endpoint is physical-process risk, not just data risk."
},
"checkCommand": "nmap -sV -Pn -p 8016 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 8016 (ads-s, Beckhoff)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=8016",
"kind": "iana"
}
],
"ianaName": "ads-s"
},
{
"port": 8019,
"protocol": "tcp",
"service": "QuickBooks Database (qbdb)",
"oneLiner": "Registered to Intuit as the QuickBooks database dynamic port.",
"whatItIs": "IANA lists 8019 as qbdb, \"QB DB Dynamic Port\", part of the block Intuit registered for QuickBooks Desktop. In a multi-user QuickBooks installation the Database Server Manager on the file-hosting PC uses this port so workstations can open the company file. Outside a Windows LAN running QuickBooks it is a rare port with no other well-known occupant.",
"exposure": {
"verdict": "never",
"note": "It is a file-hosted accounting database service designed for a trusted local network. Nothing about it is built to survive the open internet."
},
"checkCommand": "nmap -sV -Pn -p 8019 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 8019 (qbdb)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=8019",
"kind": "iana"
}
],
"ianaName": "qbdb"
},
{
"port": 8021,
"protocol": "tcp",
"service": "FreeSWITCH event socket; FTP proxy",
"oneLiner": "FreeSWITCH's Event Socket — a text console that controls the whole telephony switch.",
"whatItIs": "IANA registers 8021 to Intuit as intu-ec-client, but the port's real fame is FreeSWITCH: the stock `event_socket.conf.xml` sets `listen-port` to 8021, and mod_event_socket is how dialplan applications, click-to-call scripts and monitoring tools drive the switch. Nmap also records 8021 as a common FTP proxy port, a much older convention that pairs it with 21. On a VoIP host, assume FreeSWITCH.",
"exposure": {
"verdict": "never",
"note": "The Event Socket is full administrative control of the PBX — originate calls, read channel variables, reload configuration — behind a single password. It is meant for loopback or a tightly ACLed management network."
},
"checkCommand": "nc -vz -w 3 TARGET 8021",
"links": [
{
"title": "signalwire/freeswitch — conf/vanilla/autoload_configs/event_socket.conf.xml (listen-port 8021)",
"url": "https://github.com/signalwire/freeswitch/blob/master/conf/vanilla/autoload_configs/event_socket.conf.xml",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 8021 (intu-ec-client)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=8021",
"kind": "iana"
}
],
"ianaName": "intu-ec-client"
},
{
"port": 8022,
"protocol": "tcp",
"service": "SSH alternate; Termux sshd",
"oneLiner": "SSH moved off 22 — and specifically the default for Termux's sshd on Android.",
"whatItIs": "IANA registers 8022 as oa-system, which you will rarely encounter. The number's practical life is as an SSH alternate: Termux patches OpenSSH so its `sshd` defaults to 8022, since an unprivileged Android app cannot bind 22, and plenty of appliances and containers do the same thing for the same reason. An open 8022 that answers with an `SSH-2.0-` banner is exactly that, and moving the port changes nothing about the protocol's security.",
"exposure": {
"verdict": "careful",
"note": "SSH itself is fine to expose when it is key-only with passwords disabled. The caveat is what tends to sit here — phones and small devices running sshd with a weak or default password — and that a non-standard port is obscurity, not defence."
},
"checkCommand": "nc -w 3 TARGET 8022 | head -1",
"links": [
{
"title": "termux/termux-packages — openssh servconf.c.patch (default port 8022)",
"url": "https://github.com/termux/termux-packages/blob/master/packages/openssh/servconf.c.patch",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 8022 (oa-system)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=8022",
"kind": "iana"
}
],
"ianaName": "oa-system"
},
{
"port": 8031,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned by IANA, yet turns up in scan data more often than its registered neighbours.",
"whatItIs": "IANA lists 8028-8031 as Unassigned and Nmap has no service name for 8031, but Nmap's frequency data still ranks it above many named ports nearby — roughly a quarter of a percent of scanned hosts. That combination usually means a widely deployed product picked the number without registering it, rather than one standard protocol. Nothing well-documented pins it down, so treat the number as a hint and fingerprint the service.",
"exposure": {
"verdict": "careful",
"note": "No registration means no protocol-level verdict. Identify what answers before you decide whether it belongs on a public address."
},
"checkCommand": "nmap -sV -Pn -p 8031 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 8031",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=8031",
"kind": "iana"
},
{
"title": "nmap/nmap — nmap-services (port frequency database)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 8042,
"protocol": "tcp",
"service": "Hadoop YARN NodeManager UI; Orthanc DICOM HTTP",
"oneLiner": "Two well-known defaults share it: YARN's NodeManager web UI and the Orthanc DICOM server's REST API.",
"whatItIs": "IANA assigns 8042 to FireScope Agent, which is not what you will find. In a Hadoop cluster, `yarn.nodemanager.webapp.address` defaults to `${yarn.nodemanager.hostname}:8042`, so every NodeManager serves its web UI here. In medical imaging, Orthanc's default configuration \"creates a HTTP server for the REST API that listens on the port 8042\", which is also its web interface. Context — a datacentre cluster versus a hospital or research network — tells you which one you found.",
"exposure": {
"verdict": "never",
"note": "The YARN NodeManager UI exposes cluster topology, running containers and application logs with no authentication in a default install. Orthanc on 8042 fronts a store of patient DICOM images. Neither should be reachable from the internet."
},
"checkCommand": "curl -sI http://TARGET:8042/",
"links": [
{
"title": "Apache Hadoop — yarn-default.xml (yarn.nodemanager.webapp.address, :8042)",
"url": "https://hadoop.apache.org/docs/stable/hadoop-yarn/hadoop-yarn-common/yarn-default.xml",
"kind": "official-docs"
},
{
"title": "Orthanc Book — Configuration (HTTP server on port 8042)",
"url": "https://orthanc.uclouvain.be/book/users/configuration.html",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 8042 (fs-agent)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=8042",
"kind": "iana"
}
],
"ianaName": "fs-agent"
},
{
"port": 8045,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Inside IANA's 8045-8050 Unassigned block, with no known standard occupant.",
"whatItIs": "IANA lists 8045 through 8050 as Unassigned, and Nmap files 8045 as `unknown`. The registered ports on either side belong to FireScope (8042-8044) and Rocrail (8051), neither of which spills into this gap. Anything listening on 8045 is an application-specific choice, most often one more HTTP port on a busy host.",
"exposure": {
"verdict": "careful",
"note": "Judge the listener, not the number — an unregistered port gives you no protocol to reason about."
},
"checkCommand": "nmap -sV -Pn -p 8045 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 8045",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=8045",
"kind": "iana"
}
]
},
{
"port": 8050,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "The last port in IANA's 8045-8050 Unassigned block; nothing standard lives here.",
"whatItIs": "8050 is unassigned at IANA and unnamed in Nmap's service database, where it sits near the bottom of the observed-frequency list. No widely documented product default claims it. As with the rest of the 8000-8100 band, an open 8050 is a private choice by whatever software is running, and only a banner or version scan will tell you what.",
"exposure": {
"verdict": "careful",
"note": "No registration, no protocol, no default verdict. Fingerprint the service and judge that instead."
},
"checkCommand": "nmap -sV -Pn -p 8050 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 8050",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=8050",
"kind": "iana"
}
]
},
{
"port": 8080,
"protocol": "tcp",
"service": "HTTP alternate",
"oneLiner": "The registered HTTP alternate port — what web software uses when it cannot have 80.",
"whatItIs": "IANA registers 8080 as http-alt, \"HTTP Alternate (see port 80)\". It is what unprivileged processes bind because ports below 1024 need root: Tomcat, Jenkins, Spring Boot apps, proxies, and thousands of container images. On a scan it is almost always a real HTTP service sitting behind (or waiting for) a reverse proxy.",
"exposure": {
"verdict": "careful",
"note": "The port is legitimate, but what is behind it is often an admin console or an unauthenticated app that assumed a proxy would guard it."
},
"checkCommand": "curl -sI http://127.0.0.1:8080/",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 8080 (http-alt)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=8080",
"kind": "iana"
},
{
"title": "Jenkins — Installing Jenkins on Linux (listens on 8080)",
"url": "https://www.jenkins.io/doc/book/installing/linux/",
"kind": "official-docs"
},
{
"title": "Apache Tomcat 11 — HTTP Connector configuration",
"url": "https://tomcat.apache.org/tomcat-11.0-doc/config/http.html",
"kind": "official-docs"
}
]
},
{
"port": 8081,
"protocol": "tcp",
"service": "HTTP alternate; Sonatype Nexus Repository",
"oneLiner": "The port you use when 8080 is taken — and Nexus Repository Manager's default.",
"whatItIs": "IANA registers 8081 as sunproxyadmin, Sun's old proxy admin service, and Nmap still labels it `blackice-icecap` after a long-dead IDS console. Neither matters today: 8081 is the standard second HTTP port, and its most recognisable occupant is Sonatype Nexus Repository, whose documentation has you browse to `http://localhost:8081/` after install. Artifact proxies, second app instances and container sidecars fill in the rest.",
"exposure": {
"verdict": "careful",
"note": "A Nexus instance on 8081 is an admin console plus your build artifacts, and it ships with a well-known default admin account that must be changed at first login. Public artifact mirroring can be deliberate; the console being public rarely is."
},
"checkCommand": "curl -sI http://TARGET:8081/",
"links": [
{
"title": "Sonatype — Nexus Repository installation (UI on port 8081)",
"url": "https://help.sonatype.com/en/installation-methods.html",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 8081 (sunproxyadmin)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=8081",
"kind": "iana"
}
],
"ianaName": "sunproxyadmin"
},
{
"port": 8082,
"protocol": "tcp",
"service": "HTTP alternate (IANA: us-cli)",
"oneLiner": "The third HTTP port in the 8080 series, with a registration nobody uses.",
"whatItIs": "IANA assigns 8082 to Utilistor (Client) as us-cli, and Nmap's older name for it, `blackice-alerts`, refers to an IDS product retired long ago. In current practice 8082 is simply what a host binds after 8080 and 8081 are spoken for — a second web app, an admin interface split off from the main port, or a container publishing another service. Nothing about the number identifies the software.",
"exposure": {
"verdict": "careful",
"note": "High HTTP ports collect the things that were never meant to be public: management UIs, metrics endpoints and services that assumed a reverse proxy would authenticate for them."
},
"checkCommand": "curl -sI http://TARGET:8082/",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 8082 (us-cli)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=8082",
"kind": "iana"
},
{
"title": "nmap/nmap — nmap-services (8082/tcp)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
],
"ianaName": "us-cli"
},
{
"port": 8083,
"protocol": "tcp",
"service": "HTTP alternate (IANA: us-srv)",
"oneLiner": "Registered as Utilistor Server; in the field, one more alternate HTTP port.",
"whatItIs": "IANA lists 8083/tcp and /udp as us-srv, the server half of the Utilistor pair that owns 8082. Nmap keeps the same name and records it as uncommon. Like its neighbours it is used generically: an extra HTTP listener, a management interface, or a service published from a container. Fingerprint it rather than trusting the registered name.",
"exposure": {
"verdict": "careful",
"note": "Whether this is safe depends entirely on the application answering. Check whether it requires authentication and whether it was ever supposed to be reachable from outside."
},
"checkCommand": "curl -sI http://TARGET:8083/",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 8083 (us-srv)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=8083",
"kind": "iana"
},
{
"title": "nmap/nmap — nmap-services (8083/tcp us-srv)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
],
"ianaName": "us-srv"
},
{
"port": 8084,
"protocol": "tcp",
"service": "websnp (Snarl over HTTP) / HTTP alternate",
"oneLiner": "Registered to the Snarl notification protocol, but in practice just another spare HTTP port.",
"whatItIs": "IANA assigns 8084/tcp to websnp, \"Snarl Network Protocol over HTTP\" — the network transport for the Snarl desktop notification system, which is long since discontinued. What you actually meet on 8084 is the fourth or fifth HTTP listener on a busy host: a second app instance, a metrics endpoint, or a container that took the next free port after 8080 through 8083. The port tells you nothing about the protocol, so identify the listener rather than trusting the registration.",
"exposure": {
"verdict": "careful",
"note": "Whatever is here is an unlabelled HTTP service someone chose by counting upward; check what it serves and whether it authenticates before letting it out of the host."
},
"checkCommand": "curl -sI --max-time 5 http://TARGET:8084/",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 8084",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=8084",
"kind": "iana"
}
],
"ianaName": "websnp"
},
{
"port": 8085,
"protocol": "tcp",
"service": "Unregistered HTTP alternate",
"oneLiner": "Unassigned at IANA; in practice a spare HTTP port next to 8080.",
"whatItIs": "IANA lists 8085 as Unassigned for both TCP and UDP, so nothing owns it. It shows up when a machine already has something on 8080 through 8084 and the next process takes the next number — a second web app, an admin UI, or a container port mapping. Anything you find here has to be identified from its banner or response, not from the port.",
"exposure": {
"verdict": "careful",
"note": "An unregistered HTTP port is usually something a developer or a compose file bound without thinking about the network it landed on."
},
"checkCommand": "curl -sI --max-time 5 http://TARGET:8085/",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 8085",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=8085",
"kind": "iana"
}
],
"ianaName": "Unassigned"
},
{
"port": 8086,
"protocol": "tcp",
"service": "InfluxDB HTTP API",
"oneLiner": "InfluxDB's HTTP API and UI — the default for every InfluxDB version.",
"whatItIs": "InfluxDB's http-bind-address defaults to :8086, which serves both the write/query API and, since 2.x, the browser UI. Because the default binds all interfaces rather than loopback, a stock install on a cloud VM is reachable from anywhere the firewall allows. IANA has 8086 registered to d-s-n, a SCADA rendezvous port, which you will essentially never meet; a listener on 8086 is a time-series database. Telegraf agents, Grafana data sources and Kubernetes monitoring stacks are the usual clients.",
"exposure": {
"verdict": "never",
"note": "It is a database API speaking plain HTTP by default, with API tokens sent in the clear; keep it on a private network or behind a TLS-terminating proxy."
},
"checkCommand": "curl -s --max-time 5 http://TARGET:8086/health",
"links": [
{
"title": "InfluxDB — Configuration options (http-bind-address defaults to :8086)",
"url": "https://docs.influxdata.com/influxdb/v2/reference/config-options/",
"kind": "official-docs"
},
{
"title": "influxdata/influxdb on GitHub",
"url": "https://github.com/influxdata/influxdb",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 8086",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=8086",
"kind": "iana"
}
],
"ianaName": "d-s-n"
},
{
"port": 8087,
"protocol": "tcp",
"service": "Riak KV Protocol Buffers API",
"oneLiner": "Riak's binary client interface — the Protocol Buffers half of the pair with 8098.",
"whatItIs": "Riak KV exposes two client interfaces, and its own security guide states that clients must reach the cluster on TCP 8098 for HTTP and TCP 8087 for Protocol Buffers. 8087 is the faster binary path that the official Riak client libraries use. IANA registers 8087 to simplifymedia, a defunct music-sharing product, so a listener here is almost certainly a Riak node. Riak's authentication and TLS are opt-in via `riak-admin security`, off by default.",
"exposure": {
"verdict": "never",
"note": "With security disabled — the default — anyone who can reach 8087 can read and write every bucket in the cluster."
},
"checkCommand": "nc -vz TARGET 8087",
"links": [
{
"title": "Riak KV — Security (client ports 8098 HTTP and 8087 Protocol Buffers)",
"url": "https://docs.riak.com/riak/kv/latest/using/security/index.html",
"kind": "official-docs"
},
{
"title": "basho/riak on GitHub",
"url": "https://github.com/basho/riak",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 8087",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=8087",
"kind": "iana"
}
],
"ianaName": "simplifymedia"
},
{
"port": 8088,
"protocol": "tcp",
"service": "Hadoop YARN ResourceManager UI, Asterisk HTTP",
"oneLiner": "The Hadoop YARN ResourceManager web UI, and Asterisk's built-in HTTP server.",
"whatItIs": "Hadoop's yarn.resourcemanager.webapp.address defaults to ${yarn.resourcemanager.hostname}:8088, so every stock YARN cluster serves its ResourceManager UI and REST API there. Asterisk's built-in mini HTTP server also defaults to bindport 8088, which is how ARI and the WebSocket transports are reached. IANA has 8088 registered as radan-http. On an internet scan a 8088 is overwhelmingly a Hadoop cluster: the ResourceManager REST API accepts application submissions, and with the default open ACLs anyone who can reach it can run code on the cluster, which is why the port is scanned constantly.",
"exposure": {
"verdict": "never",
"note": "An unauthenticated ResourceManager on a public IP is remote code execution by design; put Kerberos in front of it or keep it off the internet entirely."
},
"checkCommand": "curl -s --max-time 5 http://TARGET:8088/ws/v1/cluster/info",
"links": [
{
"title": "Apache Hadoop — yarn-default.xml (yarn.resourcemanager.webapp.address)",
"url": "https://hadoop.apache.org/docs/stable/hadoop-yarn/hadoop-yarn-common/yarn-default.xml",
"kind": "official-docs"
},
{
"title": "Asterisk — Built-in mini-HTTP server (bindport default 8088)",
"url": "https://docs.asterisk.org/Configuration/Core-Configuration/Asterisk-Builtin-mini-HTTP-Server/",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 8088",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=8088",
"kind": "iana"
}
],
"ianaName": "radan-http"
},
{
"port": 8089,
"protocol": "tcp",
"service": "Splunk management port (splunkd)",
"oneLiner": "Splunk's management and REST port — the admin plane, not the web UI.",
"whatItIs": "splunkd listens on 8089 for the Splunk REST API and for management traffic between Splunk instances: deployment servers pushing apps, search heads talking to indexers, forwarders being managed. Splunk's own documentation gives 8089 as the default management/administration port. It speaks HTTPS with a self-signed certificate out of the box, and it is a separate port from Splunk Web on 8000 and from receiving on 9997. IANA leaves 8089 Unassigned.",
"exposure": {
"verdict": "never",
"note": "This is the administrative API for the whole Splunk deployment; restrict it to management networks and replace the shipped default certificates."
},
"checkCommand": "curl -sk --max-time 5 https://TARGET:8089/services/server/info",
"links": [
{
"title": "splunk-ansible — SPLUNK_SVC_PORT, Splunk management port (default 8089)",
"url": "https://splunk.github.io/splunk-ansible/ADVANCED.html",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 8089",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=8089",
"kind": "iana"
}
]
},
{
"port": 8090,
"protocol": "tcp",
"service": "Atlassian Confluence",
"oneLiner": "Confluence's default HTTP port.",
"whatItIs": "Atlassian's installation guide states that Confluence runs on port 8090 by default and that the installer prompts for another port if it is taken. The listener is the bundled Tomcat, so a 8090 on a server with Java processes is usually a wiki. IANA registers 8090/tcp to opsmessaging, a vehicle-to-station messaging assignment you will not encounter. Confluence is normally fronted by a reverse proxy on 80/443, with 8090 left bound to all interfaces underneath.",
"exposure": {
"verdict": "careful",
"note": "Confluence has a long history of critical pre-auth vulnerabilities; expose it only through a proxy on a patched version, never as a bare 8090."
},
"checkCommand": "curl -sI --max-time 5 http://TARGET:8090/",
"links": [
{
"title": "Atlassian — Installing Confluence on Linux (default port 8090)",
"url": "https://confluence.atlassian.com/doc/installing-confluence-on-linux-143556824.html",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 8090",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=8090",
"kind": "iana"
}
],
"ianaName": "opsmessaging"
},
{
"port": 8093,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned at IANA, with no widely used default service.",
"whatItIs": "IANA lists 8092 through 8096 as one Unassigned block, so 8093 belongs to nobody. There is no common product default here; when it appears it is a locally chosen port, typically another HTTP or application listener picked because it was free. Identify it from the service itself rather than assuming anything from the number.",
"exposure": {
"verdict": "careful",
"note": "An unregistered listener is an unknown one until you fingerprint it — treat it as an unaudited service, not as benign because it is obscure."
},
"checkCommand": "sudo lsof -nP -iTCP:8093 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 8093",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=8093",
"kind": "iana"
}
],
"ianaName": "Unassigned"
},
{
"port": 8095,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned at IANA, with no widely used default service.",
"whatItIs": "8095 sits inside the Unassigned 8092–8096 block in the IANA registry, so no protocol owns it. In the wild it is a locally chosen port for an application, test instance or container mapping, most often HTTP. The port number carries no information; the banner does.",
"exposure": {
"verdict": "careful",
"note": "Nothing is defined here, so anything listening is a local choice that has not been reviewed by anyone but the person who picked it."
},
"checkCommand": "sudo lsof -nP -iTCP:8095 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 8095",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=8095",
"kind": "iana"
}
],
"ianaName": "Unassigned"
},
{
"port": 8097,
"protocol": "tcp",
"service": "sac (SAC Port Id)",
"oneLiner": "Registered in 2006 as \"SAC Port Id\" and effectively unused since.",
"whatItIs": "IANA assigns 8097 on both TCP and UDP to the service name sac, described only as \"SAC Port Id\", registered in April 2006. The registration carries no specification and no public implementation, so the name tells you nothing operationally. A listener on 8097 in practice is a locally chosen port, usually one more HTTP or application service in the 80xx range.",
"exposure": {
"verdict": "careful",
"note": "Do not read the registration as an identification; fingerprint the listener before deciding whether it belongs on the network it is on."
},
"checkCommand": "nc -vz TARGET 8097",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 8097",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=8097",
"kind": "iana"
}
],
"ianaName": "sac"
},
{
"port": 8098,
"protocol": "tcp",
"service": "Riak KV HTTP API",
"oneLiner": "Riak's HTTP client interface, the counterpart to Protocol Buffers on 8087.",
"whatItIs": "Riak KV's security guide lists TCP 8098 as the HTTP client port that every client must be able to reach, alongside 8087 for the Protocol Buffers interface. The HTTP API answers REST-shaped requests for buckets, keys and cluster status, which makes it easy to identify with curl. IANA leaves 8098 Unassigned, so a listener here that answers HTTP with Riak JSON is a Riak node. Authentication and TLS are opt-in and disabled by default.",
"exposure": {
"verdict": "never",
"note": "A default Riak node grants full read and write access over cleartext HTTP to anyone who can open the socket."
},
"checkCommand": "curl -s --max-time 5 http://TARGET:8098/stats",
"links": [
{
"title": "Riak KV — Security (client ports 8098 HTTP and 8087 Protocol Buffers)",
"url": "https://docs.riak.com/riak/kv/latest/using/security/index.html",
"kind": "official-docs"
},
{
"title": "basho/riak on GitHub",
"url": "https://github.com/basho/riak",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 8098",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=8098",
"kind": "iana"
}
],
"ianaName": "Unassigned"
},
{
"port": 8099,
"protocol": "tcp",
"service": "Unregistered HTTP alternate",
"oneLiner": "Unassigned at IANA; a round-number spare HTTP port people pick by hand.",
"whatItIs": "IANA lists 8098 and 8099 together as Unassigned, so nothing is registered here. 8099 gets chosen the way 8080 and 8888 do — it is memorable and usually free — which makes it a common manual pick for a second web app, an internal tool, or a test server. There is no protocol implied by the number.",
"exposure": {
"verdict": "careful",
"note": "Hand-picked ports are usually hand-configured services; confirm it authenticates before treating it as safe to reach."
},
"checkCommand": "curl -sI --max-time 5 http://TARGET:8099/",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 8099",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=8099",
"kind": "iana"
}
]
},
{
"port": 8100,
"protocol": "tcp",
"service": "Xprint Server",
"oneLiner": "Registered to the X.Org print server, a subsystem that no longer ships.",
"whatItIs": "IANA assigns 8100 on TCP and UDP to xprint-server, the Xprint printing extension that shipped with XFree86 and Solaris and was removed from X.Org years ago. You will not meet a live Xprint server today. What you find on 8100 now is a locally chosen listener — it is a round number in the 80xx band, so applications and containers take it as an alternate HTTP or service port.",
"exposure": {
"verdict": "careful",
"note": "The registration is dead history; identify the actual service before deciding anything about it."
},
"checkCommand": "nc -vz TARGET 8100",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 8100",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=8100",
"kind": "iana"
}
],
"ianaName": "xprint-server"
},
{
"port": 8123,
"protocol": "tcp",
"service": "Home Assistant (or ClickHouse HTTP)",
"oneLiner": "Home Assistant's web UI and REST API — or, on a database host, the ClickHouse HTTP interface.",
"whatItIs": "Home Assistant serves its frontend, REST API, and WebSocket API over HTTP on 8123 by default; container and Core installs still use it, while Home Assistant OS moved its default to port 80 in the 2026.8 release. It shows up on scans of home LANs from a Raspberry Pi, NUC, or NAS running HA. Unrelated but common in server fleets: clickhouse-server listens on 8123 for its HTTP interface, and a bare GET / there returns the string \"Ok.\".",
"exposure": {
"verdict": "careful",
"note": "Home Assistant has real user authentication but ships plain HTTP by default and controls locks and cameras — put it behind a reverse proxy with TLS or a VPN rather than forwarding 8123."
},
"checkCommand": "curl -s -m 3 -o /dev/null -w '%{http_code} %{content_type}\\n' http://TARGET:8123/",
"links": [
{
"title": "Home Assistant — HTTP integration (server_port, default 8123)",
"url": "https://www.home-assistant.io/integrations/http/",
"kind": "official-docs"
},
{
"title": "Home Assistant — REST API developer documentation",
"url": "https://developers.home-assistant.io/docs/api/rest/",
"kind": "official-docs"
},
{
"title": "home-assistant/core",
"url": "https://github.com/home-assistant/core",
"kind": "github"
},
{
"title": "ClickHouse — HTTP interface (port 8123)",
"url": "https://clickhouse.com/docs/interfaces/http",
"kind": "official-docs"
}
]
},
{
"port": 8180,
"protocol": "tcp",
"service": "Tomcat / HTTP alternate",
"oneLiner": "Unassigned at IANA; a conventional second Tomcat port when 8080 is taken.",
"whatItIs": "IANA lists the whole 8163–8180 block as Unassigned, so 8180 is unregistered. It is a common offset choice for a Java servlet container that cannot have 8080 — a second Tomcat instance, or one packaged to sit behind Apache httpd. It is also the port the widely used Metasploitable 2 training image leaves open, which is why 8180 turns up in so many teaching materials and scan write-ups.",
"exposure": {
"verdict": "careful",
"note": "Application servers on alternate ports commonly still have the manager or admin webapp deployed; check /manager and /host-manager before exposing it."
},
"checkCommand": "curl -sI --max-time 5 http://TARGET:8180/",
"links": [
{
"title": "Rapid7 — Metasploitable 2 exploitability guide (8180/tcp open)",
"url": "https://docs.rapid7.com/metasploit/metasploitable-2-exploitability-guide/",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 8180",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=8180",
"kind": "iana"
}
],
"ianaName": "Unassigned"
},
{
"port": 8181,
"protocol": "tcp",
"service": "GlassFish HTTPS listener, Intermapper",
"oneLiner": "The default HTTPS listener for GlassFish and Payara, and IANA's Intermapper port.",
"whatItIs": "Eclipse GlassFish ships an HTTPS listener on 8181 next to its HTTP listener on 8080 and the admin console on 4848; Payara inherits the same defaults. IANA registers 8181/tcp to intermapper, HelpSystems' network management system. In practice 8181 is also a common second HTTP port for OSGi containers and Java web stacks generally, so a listener here may speak TLS or plain HTTP depending on what put it there. Probe it both ways before concluding.",
"exposure": {
"verdict": "careful",
"note": "If it is GlassFish, the interesting target is the admin console on 4848 next door; a default-certificate 8181 also gives you no identity assurance."
},
"checkCommand": "openssl s_client -connect TARGET:8181 /dev/null | openssl x509 -noout -subject -dates",
"links": [
{
"title": "Eclipse GlassFish Administration Guide (default HTTPS port 8181)",
"url": "https://glassfish.org/docs/latest/administration-guide.html",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 8181",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=8181",
"kind": "iana"
}
],
"ianaName": "intermapper"
},
{
"port": 8189,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned at IANA, with no widely used default service.",
"whatItIs": "IANA lists 8185 through 8189 as one Unassigned block, so nothing is registered on 8189. There is no common product default here; a listener is a local choice, most often an application or web service on an arbitrary free port. Fingerprint it rather than inferring a protocol from the number.",
"exposure": {
"verdict": "careful",
"note": "Unregistered and unidentified is not the same as harmless — find out what answers before you decide."
},
"checkCommand": "sudo lsof -nP -iTCP:8189 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 8189",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=8189",
"kind": "iana"
}
]
},
{
"port": 8192,
"protocol": "tcp",
"service": "spytechphone (SpyTech Phone Service)",
"oneLiner": "Registered in 2006 to SpyTech Phone Service; rarely what you are actually looking at.",
"whatItIs": "IANA assigns 8192 on TCP and UDP to spytechphone, \"SpyTech Phone Service\", a 2006 registration with no public specification. The name shows up in port lookup tables far more often than the service shows up on networks. 8192 is also a familiar number for other reasons — it is 2^13, so it gets chosen by hand for local services and test harnesses. Treat the registration as trivia and identify the listener directly.",
"exposure": {
"verdict": "careful",
"note": "The registration gives you no basis for a judgement; the judgement has to come from what the service actually is."
},
"checkCommand": "nc -vz TARGET 8192",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 8192",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=8192",
"kind": "iana"
}
],
"ianaName": "spytechphone"
},
{
"port": 8193,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned at IANA — a gap between the SpyTech and Bloomberg registrations.",
"whatItIs": "The IANA registry marks 8193 Unassigned, sitting between spytechphone on 8192 and Bloomberg's blp1 on 8194. Nothing standard listens here. In practice it is a locally chosen port, and its neighbours are a better clue than the number itself: a 8193 next to an active 8194 on a finance workstation is worth checking against the Bloomberg software on that machine.",
"exposure": {
"verdict": "careful",
"note": "Nothing is defined for this port, so a listener is an unreviewed local decision until you identify it."
},
"checkCommand": "sudo lsof -nP -iTCP:8193 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 8193",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=8193",
"kind": "iana"
}
],
"ianaName": "Unassigned"
},
{
"port": 8194,
"protocol": "tcp",
"service": "Bloomberg data API (blp1)",
"oneLiner": "The Bloomberg API port — where blpapi clients connect for market data.",
"whatItIs": "IANA registers 8194 on TCP and UDP as blp1, \"Bloomberg data API\", assigned to Bloomberg in 2006. Applications using the Bloomberg API library open a session to this port, either against the local Bloomberg Terminal process on the same workstation or against a B-PIPE/Server API appliance inside the firm. On a scan it identifies a finance desktop or a market-data server, not a general-purpose service. Access is bound to Bloomberg's own licensing and entitlement, so an open socket is not by itself usable data.",
"exposure": {
"verdict": "never",
"note": "This is an entitled market-data feed inside a licensed environment; it belongs on the internal network and never on a public interface."
},
"checkCommand": "nc -vz TARGET 8194",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 8194",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=8194",
"kind": "iana"
}
],
"ianaName": "blp1"
},
{
"port": 8200,
"protocol": "tcp",
"service": "HashiCorp Vault API",
"oneLiner": "Vault's HTTP API and UI — the door to a secrets store.",
"whatItIs": "Vault's TCP listener documentation gives 127.0.0.1:8200 as the default address, so a stock single-node Vault is loopback-only and a 8200 visible on the network means someone bound it wider on purpose. The same port serves the REST API, the CLI (VAULT_ADDR), and the browser UI; cluster replication traffic uses 8201 next door. IANA has 8200 registered as trivnet1, which you will not meet in practice. The /v1/sys/health endpoint answers unauthenticated and reveals seal and initialization state.",
"exposure": {
"verdict": "never",
"note": "Everything valuable in an organisation is behind this API; require TLS, keep it on a private network, and audit who can reach it."
},
"checkCommand": "curl -s --max-time 5 http://TARGET:8200/v1/sys/health",
"links": [
{
"title": "Vault — TCP listener (default address 127.0.0.1:8200)",
"url": "https://developer.hashicorp.com/vault/docs/configuration/listener/tcp",
"kind": "official-docs"
},
{
"title": "hashicorp/vault on GitHub",
"url": "https://github.com/hashicorp/vault",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 8200",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=8200",
"kind": "iana"
}
],
"ianaName": "trivnet1"
},
{
"port": 8222,
"protocol": "tcp",
"service": "NATS HTTP monitoring",
"oneLiner": "The conventional HTTP monitoring port for a NATS server.",
"whatItIs": "nats-server exposes monitoring endpoints — /varz, /connz, /routez, /jsz — over HTTP when you set http_port or pass -m, and 8222 is the conventional choice in NATS' own documentation. It is off until enabled, and it is separate from the client port on 4222. The endpoints are read-only but detailed: server configuration, every connected client, route topology and JetStream state. IANA leaves 8222 unregistered.",
"exposure": {
"verdict": "never",
"note": "The monitoring endpoints have no authentication and enumerate your entire messaging topology; NATS' own hardening guidance is to keep this port off the internet."
},
"checkCommand": "curl -s --max-time 5 http://TARGET:8222/varz",
"links": [
{
"title": "NATS — Monitoring (http_port 8222, /varz and friends)",
"url": "https://docs.nats.io/running-a-nats-service/nats_admin/monitoring",
"kind": "official-docs"
},
{
"title": "nats-io/nats-server on GitHub",
"url": "https://github.com/nats-io/nats-server",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 8222",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=8222",
"kind": "iana"
}
],
"ianaName": "Unassigned"
},
{
"port": 8254,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned at IANA, with no widely used default service.",
"whatItIs": "The IANA registry has no assignment for 8254 on TCP or UDP. No mainstream product defaults to it, so a listener here was configured by hand or handed out by a local convention. The only honest reading of a 8254 on a scan is that something is listening and you have to identify it yourself.",
"exposure": {
"verdict": "careful",
"note": "Unregistered means unlabelled, not unimportant; fingerprint it and find the owning process."
},
"checkCommand": "sudo lsof -nP -iTCP:8254 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 8254",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=8254",
"kind": "iana"
}
]
},
{
"port": 8290,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned at IANA, with no widely used default service.",
"whatItIs": "IANA has no registration for 8290 on either transport. Nothing common defaults to it, and a listener here is a local choice. It is worth not confusing with 8291 one number away, which MikroTik RouterOS uses for WinBox management — also unregistered, but genuinely common on network gear.",
"exposure": {
"verdict": "careful",
"note": "Identify the process behind it; if you are scanning network equipment, check whether 8291 is open alongside it."
},
"checkCommand": "sudo lsof -nP -iTCP:8290 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 8290",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=8290",
"kind": "iana"
}
],
"ianaName": "Unassigned"
},
{
"port": 8291,
"protocol": "tcp",
"service": "MikroTik WinBox",
"oneLiner": "The management port for MikroTik RouterOS — WinBox, the vendor's GUI admin tool.",
"whatItIs": "RouterOS exposes a set of management services under /ip service, and the winbox service defaults to TCP 8291; the WinBox application connects there to configure the router. MikroTik's own docs list the default as 8291 and note the port is changeable in the services menu. An open 8291 on a public IP is a router admin plane, and it has been mass-exploited: CVE-2018-14847 let an attacker connected to the WinBox port read the system user database, and MikroTik's advisory tells operators to assume compromise if the port faced untrusted networks. Internet scans still find large numbers of these, which is why 8291 is a standard sweep target.",
"exposure": {
"verdict": "never",
"note": "This is a router's administrative interface with a history of pre-auth file disclosure. Firewall it to a management network or VPN; MikroTik's own guidance is to block it from public interfaces."
},
"checkCommand": "nc -vz TARGET 8291",
"links": [
{
"title": "MikroTik RouterOS — Services (default ports incl. winbox 8291)",
"url": "https://help.mikrotik.com/docs/spaces/ROS/pages/103841820/Services",
"kind": "official-docs"
},
{
"title": "MikroTik RouterOS — WinBox",
"url": "https://help.mikrotik.com/docs/spaces/ROS/pages/328129/WinBox",
"kind": "official-docs"
},
{
"title": "MikroTik security advisory — Winbox vulnerability (CVE-2018-14847)",
"url": "https://mikrotik.com/supportsec/winbox-vulnerability/",
"kind": "official-docs"
}
]
},
{
"port": 8292,
"protocol": "both",
"service": "blp3 — Bloomberg professional",
"oneLiner": "Registered to Bloomberg for the Bloomberg Professional service; no public protocol documentation.",
"whatItIs": "IANA assigns the service name blp3 on TCP and UDP 8292 to Bloomberg, described only as \"Bloomberg professional\", registered in May 2006. Bloomberg's terminal software is a proprietary client that reaches out to Bloomberg's network, so this normally appears as an outbound flow on a trading-floor workstation rather than as a listener you can scan. The wire protocol is not published. Nmap sees the port open on roughly 0.02% of hosts, which is registry noise more than deployment.",
"exposure": {
"verdict": "careful",
"note": "If something is actually listening here it is not the Bloomberg client, which is an outbound connector. Identify the process before deciding anything about exposure."
},
"checkCommand": "sudo lsof -nP -iTCP:8292 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "nmap-services — Nmap port frequency data",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 8293,
"protocol": "tcp",
"service": "hiperscan-id",
"oneLiner": "IANA-registered to Hiperscan for an \"Identification Service\"; the UDP side is Reserved.",
"whatItIs": "TCP 8293 carries the registered name hiperscan-id, \"Hiperscan Identification Service\", registered in December 2009 by Hiperscan GmbH, a maker of handheld near-infrared spectrometers used to identify substances. UDP 8293 is marked Reserved rather than assigned. No protocol specification is published and no widely deployed software claims the port; Nmap sees it open on about 0.015% of scanned hosts. If you find it listening, the registry name almost certainly does not describe what is there.",
"exposure": {
"verdict": "careful",
"note": "An unidentified listener in practice. Find the owning process before exposing it beyond a local network."
},
"checkCommand": "sudo lsof -nP -iTCP:8293 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "nmap-services — Nmap port frequency data",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 8294,
"protocol": "both",
"service": "blp4 — Bloomberg intelligent client",
"oneLiner": "Bloomberg's second registration in this block, for the \"intelligent client\"; undocumented publicly.",
"whatItIs": "IANA lists blp4 on TCP and UDP 8294, \"Bloomberg intelligent client\", registered by Bloomberg in May 2006 alongside blp3 on 8292. As with the rest of the Bloomberg port registrations, the protocol is proprietary and unpublished, and terminal deployments show up as outbound connections from workstations rather than as services you can probe. Nmap's data puts it open on roughly 0.015% of hosts on TCP.",
"exposure": {
"verdict": "careful",
"note": "The registration describes client software, not a server you would publish. Treat a listener here as unidentified until you name the process."
},
"checkCommand": "sudo lsof -nP -iTCP:8294 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "nmap-services — Nmap port frequency data",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 8300,
"protocol": "tcp",
"service": "HashiCorp Consul server RPC (IANA: tmi)",
"oneLiner": "Consul's server RPC port — how agents and servers talk to the cluster leader.",
"whatItIs": "IANA registers 8300 as tmi, \"Transport Management Interface\", from 2006, but in practice a listener here is HashiCorp Consul: 8300/tcp is the server RPC port that Consul documents as \"Consul internal communication with servers\", used for client-to-server and server-to-server RPC and Raft traffic. It appears on Consul server nodes, which usually also show 8301/8302 (Serf LAN/WAN), 8500 (HTTP API) and 8600 (DNS). Seeing 8300 without those neighbours means you are probably not looking at Consul.",
"exposure": {
"verdict": "never",
"note": "This is the cluster's internal control channel. Reachable from the internet it is a path to the Raft log and the whole catalog; keep it on a private network with TLS and gossip encryption enabled."
},
"checkCommand": "sudo lsof -nP -iTCP:8300 -sTCP:LISTEN",
"links": [
{
"title": "Consul — Required ports",
"url": "https://developer.hashicorp.com/consul/docs/reference/architecture/ports",
"kind": "official-docs"
},
{
"title": "HashiCorp Consul source repository",
"url": "https://github.com/hashicorp/consul",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 8333,
"protocol": "tcp",
"service": "Bitcoin P2P (mainnet)",
"oneLiner": "The Bitcoin peer-to-peer network port — full nodes gossip blocks and transactions here.",
"whatItIs": "Bitcoin Core listens on TCP 8333 for mainnet peer connections; bitcoin.org's full-node guide states the port and notes that supporting the network requires allowing inbound connections through your router and firewall. A node makes outbound peer connections on its own, so an open 8333 specifically means the host is willing to accept peers. Testnet and other networks use different ports, and the protocol is unauthenticated and public by design — anyone may connect and request blocks.",
"exposure": {
"verdict": "fine",
"note": "Public exposure is the point: an inbound-reachable node is what serves blocks to other peers. The RPC port (8332) is the one that must never be public."
},
"checkCommand": "nc -vz TARGET 8333",
"links": [
{
"title": "Bitcoin.org — Running A Full Node",
"url": "https://bitcoin.org/en/full-node",
"kind": "official-docs"
},
{
"title": "Bitcoin Core source repository",
"url": "https://github.com/bitcoin/bitcoin",
"kind": "github"
}
]
},
{
"port": 8383,
"protocol": "both",
"service": "m2mservices",
"oneLiner": "Registered in 2004 as \"M2m Services\" with no published protocol behind the name.",
"whatItIs": "IANA assigns m2mservices to TCP and UDP 8383, described only as \"M2m Services\", registered in November 2004. There is no specification, no reference document, and no widely deployed implementation tied to the registration. In practice 8383 is one of the generic high HTTP-alternate ports that application stacks and admin consoles grab because it is memorable, so what answers there is whatever the local software chose. Nmap sees it open on about 0.02% of hosts.",
"exposure": {
"verdict": "careful",
"note": "The registry name tells you nothing about what is listening. Identify the service — if it turns out to be an admin console or a dev server, judge it by that, not by the port."
},
"checkCommand": "sudo lsof -nP -iTCP:8383 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "nmap-services — Nmap port frequency data",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 8385,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "No IANA assignment and no well-known software — an unidentified listener if you find it.",
"whatItIs": "IANA has no entry for 8385 on TCP or UDP; the neighbouring 8384 is Reserved on TCP and assigned to marathontp on UDP, which tells you nothing about this port. Nmap carries it as \"unknown\" with an open rate near 0.015%, among the rarest it tracks. Anything answering here is a locally chosen port — a second instance of a web UI, a container mapping, or a homegrown service.",
"exposure": {
"verdict": "careful",
"note": "Unregistered means unidentified. Name the process on the host, then decide; do not assume an unregistered port is harmless."
},
"checkCommand": "sudo lsof -nP -iTCP:8385 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "nmap-services — Nmap port frequency data",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 8400,
"protocol": "tcp",
"service": "Commvault CVD",
"oneLiner": "Commvault's core communications service — the backup platform's control channel.",
"whatItIs": "IANA registers the bare name cvd on 8400 with no description, and the software behind it is Commvault: its firewall documentation lists \"TCP 8400 — CVD services\" as required between the CommServe, MediaAgents and clients, with 8401 (Server Event Manager) and 8402/8403/8405 alongside it. Every Commvault-managed machine runs the CVD service, so on an enterprise network 8400 usually marks a backup client or media agent. Outside that product the port is rare — Nmap sees it open on about 0.04% of hosts.",
"exposure": {
"verdict": "never",
"note": "This is the control channel of a backup platform that holds copies of everything. Keep it inside the backup network or behind Commvault's own network-gateway/tunnel configuration, never on a public interface."
},
"checkCommand": "sudo lsof -nP -iTCP:8400 -sTCP:LISTEN",
"links": [
{
"title": "Commvault — Firewall port requirements",
"url": "https://documentation.commvault.com/11.41/software/firewall_port_requirements.html",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 8402,
"protocol": "tcp",
"service": "abarsd (Commvault services)",
"oneLiner": "Part of Commvault's 8400-8405 service block; IANA lists only the bare name abarsd.",
"whatItIs": "The IANA registry gives 8402 the name abarsd with no description and no reference, from the same undated bulk registration as cvd on 8400. Commvault's firewall documentation lists \"TCP 8402 — Commvault services\" in the block it requires open between CommServe, MediaAgent and clients, together with 8400 (CVD), 8401 (Server Event Manager), 8403 (Commvault Firewall) and 8405. So a listener here almost always travels with 8400 on the same host; on its own it is unidentified.",
"exposure": {
"verdict": "never",
"note": "Backup-infrastructure plumbing with no reason to face the internet. Restrict it to the backup network alongside 8400."
},
"checkCommand": "sudo lsof -nP -iTCP:8402 -sTCP:LISTEN",
"links": [
{
"title": "Commvault — Firewall port requirements",
"url": "https://documentation.commvault.com/11.41/software/firewall_port_requirements.html",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 8443,
"protocol": "tcp",
"service": "HTTPS alternate",
"oneLiner": "The TLS counterpart to 8080: HTTPS on an unprivileged port.",
"whatItIs": "IANA has 8443 registered as pcsync-https, but in practice it is the conventional alternate HTTPS port. Tomcat's shipped SSL connector example uses 8443, and appliance web UIs, Kubernetes-adjacent services and admin consoles commonly serve TLS there. A listener on 8443 speaks TLS, so a plain HTTP request to it will fail.",
"exposure": {
"verdict": "careful",
"note": "TLS on the wire is not authentication — check the certificate and what the service behind it lets an anonymous caller do."
},
"checkCommand": "openssl s_client -connect 127.0.0.1:8443 -servername localhost /dev/null | openssl x509 -noout -subject -issuer -dates",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 8443",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=8443",
"kind": "iana"
},
{
"title": "Apache Tomcat 11 — SSL/TLS Configuration HOW-TO (connector on 8443)",
"url": "https://tomcat.apache.org/tomcat-11.0-doc/ssl-howto.html",
"kind": "official-docs"
}
],
"ianaName": "pcsync-https"
},
{
"port": 8481,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Not in the IANA registry and not claimed by any well-known service.",
"whatItIs": "There is no IANA assignment for 8481 on TCP or UDP, and Nmap lists it as \"unknown\" with an open rate around 0.015%. No mainstream software documents it as a default. If it is listening, the port was picked by whoever configured the host — the number itself carries no meaning you can look up.",
"exposure": {
"verdict": "careful",
"note": "Identify the listening process first. An unregistered port is not a safe port, it is an unlabelled one."
},
"checkCommand": "sudo lsof -nP -iTCP:8481 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "nmap-services — Nmap port frequency data",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 8500,
"protocol": "tcp",
"service": "HashiCorp Consul HTTP API (IANA: fmtp)",
"oneLiner": "Consul's HTTP API and web UI — the port most people mean when they say \"Consul\".",
"whatItIs": "IANA registers 8500 as fmtp, EUROCONTROL's Flight Message Transfer Protocol, from 2003; almost every listener you will actually meet is Consul, whose documentation lists 8500 as \"The HTTP API\". That API serves the service catalog, the key/value store, health checks and the built-in web UI, and it is unauthenticated unless ACLs are explicitly enabled. It travels with 8300, 8301/8302 and 8600 on a Consul server. A quick GET of /v1/status/leader identifies it in one request.",
"exposure": {
"verdict": "never",
"note": "With default (ACL-less) configuration this API hands out the whole catalog and KV store, and accepts writes. Bind it to a private address, turn on ACLs and TLS, and reach it over a VPN."
},
"checkCommand": "curl -s http://TARGET:8500/v1/status/leader",
"links": [
{
"title": "Consul — Required ports",
"url": "https://developer.hashicorp.com/consul/docs/reference/architecture/ports",
"kind": "official-docs"
},
{
"title": "HashiCorp Consul source repository",
"url": "https://github.com/hashicorp/consul",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 8540,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "No registration, no documented default — whatever is here was chosen locally.",
"whatItIs": "IANA has no assignment for 8540 on either transport, and Nmap tracks it as \"unknown\" with an open rate near 0.015%. Nothing widely deployed documents it as a default port. As with the rest of the unregistered 8xxx range, an open 8540 tells you only that some process bound it.",
"exposure": {
"verdict": "careful",
"note": "Treat it as an unidentified service and judge exposure by what the process actually is."
},
"checkCommand": "sudo lsof -nP -iTCP:8540 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "nmap-services — Nmap port frequency data",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 8600,
"protocol": "both",
"service": "Consul DNS (IANA: asterix)",
"oneLiner": "Consul's DNS interface for service discovery; IANA registered it to EUROCONTROL's ASTERIX.",
"whatItIs": "The IANA name for 8600 is asterix, EUROCONTROL's \"Surveillance Data\" format for exchanging radar and other ATM surveillance information, registered in 2005. What you meet on a normal network is Consul: its docs list 8600 as \"The DNS server\", answering queries like .service.consul over both UDP and TCP. It runs on every Consul agent, so it usually appears next to 8500 on the same host. Because it is a DNS responder on a non-standard port, resolvers reach it only via a forwarding rule.",
"exposure": {
"verdict": "careful",
"note": "It answers unauthenticated queries that enumerate your internal services and their addresses. Keep it on a private interface and forward to it from your own resolver rather than publishing it."
},
"checkCommand": "dig @TARGET -p 8600 consul.service.consul",
"links": [
{
"title": "Consul — Required ports",
"url": "https://developer.hashicorp.com/consul/docs/reference/architecture/ports",
"kind": "official-docs"
},
{
"title": "EUROCONTROL — ASTERIX surveillance data format",
"url": "https://www.eurocontrol.int/asterix",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 8648,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unregistered, and one below Ganglia's 8649 — which is the only reason it gets noticed.",
"whatItIs": "IANA has no assignment for 8648. Its neighbour 8649 is the Ganglia monitoring daemon's default port, and Ganglia deployments often spread extra channels across nearby numbers, but nothing documents 8648 specifically as a default. Nmap lists it as \"unknown\" at roughly 0.015% open. Read a listener here as an unidentified service that happens to sit next to a known one.",
"exposure": {
"verdict": "careful",
"note": "Do not infer Ganglia from adjacency. Identify the process, and if it does turn out to be a monitoring channel, keep it internal."
},
"checkCommand": "sudo lsof -nP -iTCP:8648 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "nmap-services — Nmap port frequency data",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 8649,
"protocol": "both",
"service": "Ganglia gmond",
"oneLiner": "Ganglia's node monitoring daemon — UDP for the metric channel, TCP to dump cluster state as XML.",
"whatItIs": "gmond, the Ganglia monitoring daemon, defaults to 8649 on both transports: a udp_recv_channel (usually multicast) collects metrics from other nodes, and a tcp_accept_channel serves the accumulated cluster state as XML to anything that connects. Both defaults are 8649 in the shipped configuration documentation. The port has no IANA assignment; it is a convention of the Ganglia project, common on HPC clusters and older Linux fleets. Connecting to it with netcat returns the full XML inventory with no authentication.",
"exposure": {
"verdict": "never",
"note": "An open TCP 8649 hands out hostnames, OS versions, load, and the shape of your whole cluster to anyone who connects. Ganglia's only control is an optional ACL — keep it on the management network."
},
"checkCommand": "nc TARGET 8649 | head -40",
"links": [
{
"title": "Ganglia gmond configuration reference (conf.pod)",
"url": "https://github.com/ganglia/monitor-core/blob/master/gmond/conf.pod",
"kind": "github"
},
{
"title": "Ganglia monitor-core source repository",
"url": "https://github.com/ganglia/monitor-core",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 8651,
"protocol": "tcp",
"service": "Ganglia gmetad XML port",
"oneLiner": "gmetad's XML port — the aggregated view of every cluster it polls, on request.",
"whatItIs": "gmetad is the Ganglia component that polls gmond nodes and aggregates them into a grid. Its configuration file documents xml_port with \"default: 8651\", the port on which it answers requests for the full XML summary; the Ganglia web frontend reads from it. There is no IANA assignment for 8651 — the number is a project convention. Like gmond, gmetad has no authentication, only an optional trusted-hosts list.",
"exposure": {
"verdict": "never",
"note": "It returns the aggregated inventory of every cluster gmetad knows about. Restrict it to the monitoring host and the web frontend; there is no auth to fall back on."
},
"checkCommand": "nc TARGET 8651 | head -40",
"links": [
{
"title": "Ganglia gmetad.conf (xml_port default 8651)",
"url": "https://github.com/ganglia/monitor-core/blob/master/gmetad/gmetad.conf.in",
"kind": "official-docs"
},
{
"title": "Ganglia monitor-core source repository",
"url": "https://github.com/ganglia/monitor-core",
"kind": "github"
}
]
},
{
"port": 8652,
"protocol": "tcp",
"service": "Ganglia gmetad interactive port",
"oneLiner": "gmetad's interactive query port — ask for one cluster or host instead of the whole XML dump.",
"whatItIs": "gmetad.conf documents interactive_port with \"default: 8652\". Where 8651 returns the entire XML tree, the interactive port takes a path-style query (for example /cluster/host) and returns just that subtree, which is what the Ganglia web frontend uses to avoid transferring everything on each page load. It is unregistered with IANA and unauthenticated, and it appears only on hosts running gmetad — normally alongside 8651.",
"exposure": {
"verdict": "never",
"note": "Same data as 8651, retrieved piecemeal, and equally unauthenticated. Bind gmetad to the monitoring network."
},
"checkCommand": "printf '/\\n' | nc TARGET 8652 | head -40",
"links": [
{
"title": "Ganglia gmetad.conf (interactive_port default 8652)",
"url": "https://github.com/ganglia/monitor-core/blob/master/gmetad/gmetad.conf.in",
"kind": "official-docs"
},
{
"title": "Ganglia monitor-core source repository",
"url": "https://github.com/ganglia/monitor-core",
"kind": "github"
}
]
},
{
"port": 8654,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "No IANA entry; sits in the range Ganglia deployments borrow, but is not a documented default.",
"whatItIs": "8654 has no IANA assignment. It falls inside the loose 8649-8655 band that Ganglia installations use for extra gmond channels and additional data sources — the shipped gmetad.conf example even points at ports like 8655 — but no Ganglia default lands on 8654 itself. Nmap tracks it as \"unknown\" at about 0.03% open. In other words: plausible neighbourhood, no documented occupant.",
"exposure": {
"verdict": "careful",
"note": "Unidentified until you name the process. If it is a Ganglia channel, treat it like 8649 and keep it off public interfaces."
},
"checkCommand": "sudo lsof -nP -iTCP:8654 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "nmap-services — Nmap port frequency data",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 8675,
"protocol": "both",
"service": "msi-cps-rm",
"oneLiner": "Motorola Solutions' Customer Programming Software for Radio Management — TCP service, UDP discovery.",
"whatItIs": "IANA assigned 8675 to Motorola Solutions in March 2012: msi-cps-rm on TCP for \"Customer Programming Software for Radio Management\", and msi-cps-rm-disc on UDP for its discovery counterpart. CPS is the Windows tool technicians use to read and write codeplugs on two-way radios, and Radio Management is its fleet-scale server version. The protocol is proprietary and undocumented publicly. You would see this on a radio-shop workstation or an RM server, not on general infrastructure; Nmap rates it open on about 0.015% of hosts.",
"exposure": {
"verdict": "careful",
"note": "This programs radio fleets — encryption keys and talkgroup configuration included. Keep it on the radio management LAN; nothing about the protocol is public enough to defend it on an open network."
},
"checkCommand": "sudo lsof -nP -iTCP:8675 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "nmap-services — Nmap port frequency data",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 8676,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unregistered; the neighbouring 8675 belongs to Motorola, this one to nobody.",
"whatItIs": "IANA has no assignment for 8676 on TCP or UDP. Nmap carries it as \"unknown\" with an open rate near 0.015%, and no widely deployed software documents it as a default. The adjacent Motorola registration on 8675 says nothing about this port.",
"exposure": {
"verdict": "careful",
"note": "No registry meaning at all. Identify the process before deciding whether it belongs on a reachable interface."
},
"checkCommand": "sudo lsof -nP -iTCP:8676 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "nmap-services — Nmap port frequency data",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 8686,
"protocol": "tcp",
"service": "GlassFish JMX/RMI (sun-as-jmxrmi)",
"oneLiner": "The JMX remote management connector for GlassFish and its Sun Application Server ancestors.",
"whatItIs": "IANA registers sun-as-jmxrmi on 8686, \"Sun App Server - JMX/RMI\", from 2005. GlassFish still uses it: the administration guide lists 8686 as the \"Pure JMX Clients Port\" and shows the domain creation output naming it JMX_ADMIN, with JConsole connecting to service:jmx:rmi://host:8686/jndi/rmi://host:8686/jmxrmi. It appears on Java application servers of that lineage — GlassFish, Payara, and older Sun/Oracle Application Server installs. A JMX connector exposes MBeans that can read and change server configuration at runtime.",
"exposure": {
"verdict": "never",
"note": "Remote JMX/RMI is a management plane, and unauthenticated JMX endpoints are a well-worn route to code execution on the JVM. Bind it to localhost and tunnel, or require authentication and TLS on the connector."
},
"checkCommand": "nc -vz TARGET 8686",
"links": [
{
"title": "Eclipse GlassFish Administration Guide (JMX port 8686)",
"url": "https://glassfish.org/docs/latest/administration-guide.html",
"kind": "official-docs"
},
{
"title": "Eclipse GlassFish source repository",
"url": "https://github.com/eclipse-ee4j/glassfish",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 8701,
"protocol": "both",
"service": "Unassigned",
"oneLiner": "No IANA assignment on either transport, and no documented default service.",
"whatItIs": "8701 is absent from the IANA registry for both TCP and UDP. Nmap lists it as \"unknown\", open on roughly 0.08% of scanned TCP hosts and 0.03% of UDP hosts — low, but a little higher than most of its unregistered neighbours, which usually means a handful of products picked it independently rather than one well-known service. Nothing mainstream documents it as a default.",
"exposure": {
"verdict": "careful",
"note": "An unlabelled port with no registry meaning. Find the owning process and judge exposure on that, not on the number."
},
"checkCommand": "sudo lsof -nP -iTCP:8701 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "nmap-services — Nmap port frequency data",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 8765,
"protocol": "tcp",
"service": "Ultraseek HTTP (registered)",
"oneLiner": "Registered to a search appliance nobody runs any more, so a listener here today is almost always someone's own app.",
"whatItIs": "IANA registers 8765 as ultraseek-http, the HTTP interface of the Ultraseek enterprise search server (Infoseek, later Verity and Autonomy). That product has been out of circulation for years, so the registration is history rather than a prediction. What you actually find on 8765 is usually an unrelated service that picked a memorable four-digit port. Identify the process before assuming anything about the protocol.",
"exposure": {
"verdict": "careful",
"note": "The verdict depends entirely on what is really bound there; treat an unidentified HTTP-ish listener as unauthenticated until you have checked."
},
"checkCommand": "sudo lsof -nP -iTCP:8765 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 8765",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=8765",
"kind": "iana"
}
],
"ianaName": "ultraseek-http"
},
{
"port": 8766,
"protocol": "both",
"service": "Agilent Connectivity Service (registered)",
"oneLiner": "IANA-registered to Agilent's Connectivity Service; you meet it on lab instrument workstations, nowhere else.",
"whatItIs": "IANA lists 8766 on TCP and UDP as amcs, the Agilent Connectivity Service. It belongs to Agilent's instrument-control software stack, so it shows up on scientific and manufacturing workstations that talk to lab hardware. Outside that niche the port has no common squatter, and a listener on a general-purpose server is worth identifying by process rather than by the registry name.",
"exposure": {
"verdict": "careful",
"note": "Instrument-control services belong on a lab network, not a routable one; there is no reason for this to answer from the internet."
},
"checkCommand": "sudo lsof -nP -iTCP:8766 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 8766",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=8766",
"kind": "iana"
}
],
"ianaName": "amcs"
},
{
"port": 8800,
"protocol": "tcp",
"service": "Sun Web Server admin (registered)",
"oneLiner": "The registered admin port of Sun's web server line — an administration plane, whatever ends up using it.",
"whatItIs": "IANA registers 8800 as sunwebadmin, the Sun Web Server administration service, later carried into Oracle iPlanet Web Server. That product line is end-of-life, so the registration mostly survives as a label. In practice the number gets reused as a round HTTP-alt port by appliances and self-hosted software, so confirm what is listening instead of trusting the registry name.",
"exposure": {
"verdict": "never",
"note": "As registered it is a server administration console; admin planes do not belong on a public interface regardless of which vendor's console it turns out to be."
},
"checkCommand": "curl -skI https://TARGET:8800/",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 8800",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=8800",
"kind": "iana"
}
],
"ianaName": "sunwebadmin"
},
{
"port": 8873,
"protocol": "tcp",
"service": "DXSpider linking protocol",
"oneLiner": "Registered for DXSpider, the amateur-radio DX cluster software, to link one node to another.",
"whatItIs": "IANA registers 8873 tcp and udp as dxspider, \"dxspider linking protocol\". DXSpider (Dirk Koopman, G1TLH) is the DX cluster server that amateur radio operators run to share spots, and cluster nodes interlink over TCP. Seeing it means a ham-radio cluster node, not a general-purpose service; note it is not rsync, which is 873.",
"exposure": {
"verdict": "careful",
"note": "Cluster nodes are meant to link across the internet, but the protocol is cleartext and node-to-node trust is by configured callsign, so restrict it to the peers you actually link with."
},
"checkCommand": "nc -vz TARGET 8873",
"links": [
{
"title": "DXSpider — official site and manuals",
"url": "https://www.dxcluster.org/",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 8873",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=8873",
"kind": "iana"
}
],
"ianaName": "dxspider"
},
{
"port": 8877,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "No IANA assignment at all — 8877 sits inside the unassigned 8874–8879 block.",
"whatItIs": "IANA lists the 8874–8879 range as Unassigned, so nothing has a claim on 8877 and no standard protocol answers there. Ports in the 88xx band get picked freely by individual products for alternate HTTP, admin, and diagnostic endpoints, which means the only reliable identification is local: find the process that owns the socket. Do not infer a service from the number.",
"exposure": {
"verdict": "careful",
"note": "An unassigned port is not a safe port; whatever chose it is often an admin or diagnostics endpoint that assumed nobody would reach it."
},
"checkCommand": "sudo lsof -nP -iTCP:8877 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 8877",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=8877",
"kind": "iana"
}
]
},
{
"port": 8888,
"protocol": "tcp",
"service": "Jupyter Notebook, HTTP alternate",
"oneLiner": "Jupyter's default port, and the second-most-common \"just give me an HTTP port\" number after 8080.",
"whatItIs": "Starting a Jupyter notebook or JupyterLab server opens a browser at http://127.0.0.1:8888 by default, which is why 8888 turns up on data-science laptops and GPU boxes. IANA's registration is ddi-tcp-1 (NewsEDGE server), which you will never meet. Otherwise 8888 is a generic HTTP alternate chosen by proxies, container images, and hand-rolled services. A notebook server is the case that matters: it executes arbitrary code as the user who started it.",
"exposure": {
"verdict": "never",
"note": "A reachable Jupyter server is remote code execution by design — token or password auth is the only thing between a visitor and your shell, so keep it on loopback or behind an authenticated proxy or SSH tunnel."
},
"checkCommand": "curl -sI http://127.0.0.1:8888/",
"links": [
{
"title": "Jupyter Notebook docs — running the notebook (defaults to 127.0.0.1:8888)",
"url": "https://jupyter-notebook.readthedocs.io/en/stable/notebook.html",
"kind": "official-docs"
},
{
"title": "jupyter/notebook on GitHub",
"url": "https://github.com/jupyter/notebook",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 8888",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=8888",
"kind": "iana"
}
],
"ianaName": "ddi-tcp-1"
},
{
"port": 8889,
"protocol": "tcp",
"service": "Jupyter (second instance), HTTP alternate",
"oneLiner": "Where the second Jupyter server lands when 8888 is already taken.",
"whatItIs": "Jupyter servers try their configured port and then walk upward to the next free one, so a machine already running a notebook on 8888 puts the next on 8889. The same happens with any tool that retries the next port. IANA registers 8889 as ddi-tcp-2 (Desktop Data), which is not something you will encounter. Treat it exactly as you would 8888: identify the process, and assume a notebook until proven otherwise.",
"exposure": {
"verdict": "never",
"note": "Same reasoning as 8888 — if this is a notebook server it is arbitrary code execution for anyone who can reach it and get past the token."
},
"checkCommand": "curl -sI http://127.0.0.1:8889/",
"links": [
{
"title": "Jupyter Notebook docs — running the notebook",
"url": "https://jupyter-notebook.readthedocs.io/en/stable/notebook.html",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 8889",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=8889",
"kind": "iana"
}
],
"ianaName": "ddi-tcp-2"
},
{
"port": 8899,
"protocol": "both",
"service": "ospf-lite (registered)",
"oneLiner": "Registered as ospf-lite; in practice a round number people grab for their own services.",
"whatItIs": "IANA registers 8899 on TCP and UDP as ospf-lite. Real OSPF is not a TCP service at all — it runs directly over IP protocol 89 — so this registration is for a specific product's lightweight variant rather than the routing protocol you know. Nothing widespread listens here, which leaves 8899 as another memorable HTTP-alt number that applications and proxies choose for themselves.",
"exposure": {
"verdict": "careful",
"note": "Identify the owning process first; the registry name tells you nothing useful about what is answering."
},
"checkCommand": "sudo lsof -nP -iTCP:8899 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 8899",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=8899",
"kind": "iana"
}
],
"ianaName": "ospf-lite"
},
{
"port": 8987,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned by IANA, with no service that commonly claims it.",
"whatItIs": "IANA lists 8982–8988 as Unassigned, so 8987 has no registration and no protocol you can assume from the number alone. It is close enough to 8983 — Apache Solr's default — that it turns up on the same hosts as an extra or second-instance port, but that is a local choice, not a convention. Look at the process, not the number.",
"exposure": {
"verdict": "careful",
"note": "Unregistered does not mean harmless; whatever bound it may be a search index or admin endpoint that expected to be private."
},
"checkCommand": "sudo lsof -nP -iTCP:8987 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 8987",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=8987",
"kind": "iana"
}
]
},
{
"port": 8994,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned by IANA and rarely seen — if it is open, something on the host chose it deliberately.",
"whatItIs": "IANA lists 8992–8996 as Unassigned, so 8994 carries no service name and no expectations. There is no well-documented application or malware family that habitually uses it. The only way to know what is there is to find the listening process locally or fingerprint the service on the wire.",
"exposure": {
"verdict": "careful",
"note": "Nothing about the port number justifies exposure; decide after you know what answers on it."
},
"checkCommand": "sudo lsof -nP -iTCP:8994 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 8994",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=8994",
"kind": "iana"
}
]
},
{
"port": 8996,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "The top of IANA's unassigned 8992–8996 block; no standard service lives here.",
"whatItIs": "IANA lists 8992–8996 as Unassigned, so 8996 has no registration. No widely deployed product defaults to it, so an open 8996 is a locally chosen port for an application, a test listener, or a tunnel endpoint. Identify it by process rather than guessing from the neighbourhood.",
"exposure": {
"verdict": "careful",
"note": "Unassigned ports get used for ad-hoc tunnels and debug listeners, which are exactly the things you do not want reachable."
},
"checkCommand": "sudo lsof -nP -iTCP:8996 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 8996",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=8996",
"kind": "iana"
}
]
},
{
"port": 9000,
"protocol": "tcp",
"service": "PHP-FPM, ClickHouse native protocol",
"oneLiner": "A heavily overloaded port: PHP-FPM's FastCGI socket, ClickHouse's native protocol, and several self-hosted consoles.",
"whatItIs": "IANA registers 9000 as cslistener, but you will meet it as PHP-FPM listening for FastCGI (`listen = 127.0.0.1:9000`) or as ClickHouse's native client/server protocol. Several self-hosted tools also default here, so identify the service before assuming. PHP-FPM is the dangerous case: the protocol is FastCGI, not HTTP, so a browser gets nothing while an attacker gets code execution.",
"exposure": {
"verdict": "never",
"note": "PHP's own manual states an exposed FastCGI endpoint allows arbitrary code execution, and listen.allowed_clients is unset by default."
},
"checkCommand": "sudo lsof -nP -iTCP:9000 -sTCP:LISTEN",
"links": [
{
"title": "PHP Manual — FPM configuration (listen, listen.allowed_clients warning)",
"url": "https://www.php.net/manual/en/install.fpm.configuration.php",
"kind": "official-docs"
},
{
"title": "ClickHouse — Network ports (9000 native protocol)",
"url": "https://clickhouse.com/docs/guides/sre/network-ports",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 9000",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=9000",
"kind": "iana"
}
],
"ianaName": "cslistener"
},
{
"port": 9002,
"protocol": "tcp",
"service": "DynamID authentication (registered)",
"oneLiner": "Registered as dynamid; in practice just the port after 9001 that an app happened to take.",
"whatItIs": "IANA registers 9002 tcp and udp as dynamid, \"DynamID authentication\". That product has no meaningful presence today, so the registration does not predict what you will find. What 9002 actually hosts is usually the second port of some multi-port application — a sidecar, a metrics endpoint, or a second instance of whatever runs on 9000 or 9001 on the same host.",
"exposure": {
"verdict": "careful",
"note": "Check what owns it, and check its neighbours: a service on 9000/9001 often explains 9002, and inherits that service's exposure rules."
},
"checkCommand": "sudo lsof -nP -iTCP:9002 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 9002",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=9002",
"kind": "iana"
}
],
"ianaName": "dynamid"
},
{
"port": 9003,
"protocol": "tcp",
"service": "Xdebug (DBGp)",
"oneLiner": "Xdebug 3's default debug port — the IDE listens, PHP connects back to it.",
"whatItIs": "Xdebug 3 changed its default from 9000 (which collided with PHP-FPM) to 9003 for xdebug.client_port, and the DBGp command-line client uses the same number. The direction surprises people: the debugged PHP process is the client, and your editor or IDE is the thing listening on 9003. So a listener here is almost always a developer's IDE, and IANA has 9003–9004 marked Unassigned.",
"exposure": {
"verdict": "never",
"note": "A DBGp listener accepts a debug session from anyone who can reach it and lets that session evaluate code in the debugger's context; bind it to loopback and reach remote hosts over an SSH tunnel."
},
"checkCommand": "sudo lsof -nP -iTCP:9003 -sTCP:LISTEN",
"links": [
{
"title": "Xdebug — settings (xdebug.client_port, default 9003)",
"url": "https://xdebug.org/docs/all_settings",
"kind": "official-docs"
},
{
"title": "xdebug/xdebug on GitHub",
"url": "https://github.com/xdebug/xdebug",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 9003",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=9003",
"kind": "iana"
}
]
},
{
"port": 9009,
"protocol": "tcp",
"service": "ClickHouse interserver replication",
"oneLiner": "ClickHouse's server-to-server port: replicas fetch data parts from each other here.",
"whatItIs": "ClickHouse uses 9009 for inter-server communication — replication and data exchange between replicas at the low-level data access layer — separate from the 9000 native client protocol and the 8123 HTTP interface. On a ClickHouse cluster every node has it open to its peers. IANA registers 9009 as pichat, which you will not meet in practice.",
"exposure": {
"verdict": "never",
"note": "This is an internal cluster path that moves raw data parts between replicas; keep it on the cluster network and never route it from the internet."
},
"checkCommand": "sudo lsof -nP -iTCP:9009 -sTCP:LISTEN",
"links": [
{
"title": "ClickHouse — network ports (9009 inter-server communication)",
"url": "https://clickhouse.com/docs/guides/sre/network-ports",
"kind": "official-docs"
},
{
"title": "ClickHouse/ClickHouse on GitHub",
"url": "https://github.com/ClickHouse/ClickHouse",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 9009",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=9009",
"kind": "iana"
}
],
"ianaName": "pichat"
},
{
"port": 9010,
"protocol": "tcp",
"service": "Secure Data Replicator Protocol (registered)",
"oneLiner": "Registered as sdr on TCP and Reserved on UDP; day to day it is an anonymous application port.",
"whatItIs": "IANA registers 9010/tcp as sdr, the Secure Data Replicator Protocol, and marks 9010/udp Reserved. Neither shows up much. Because it sits in the 90xx band that Java and JVM tooling likes for management and debug endpoints, a listener on 9010 is most often a locally configured application port rather than the registered protocol. Confirm by process before drawing conclusions.",
"exposure": {
"verdict": "careful",
"note": "If this turns out to be a JVM management or debug endpoint, treat it as never — those grant code execution to anyone who can connect."
},
"checkCommand": "sudo lsof -nP -iTCP:9010 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 9010",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=9010",
"kind": "iana"
}
],
"ianaName": "sdr"
},
{
"port": 9011,
"protocol": "tcp",
"service": "Reserved (TCP); D-Star routing (UDP)",
"oneLiner": "IANA reserves 9011/tcp and assigns 9011/udp to amateur-radio D-Star routing.",
"whatItIs": "The registry marks 9011/tcp as Reserved — deliberately held back, not available for assignment — while 9011/udp is d-star, \"D-Star Routing digital voice+data for amateur radio\". So the interesting traffic on this number is UDP and belongs to ham radio gateways. A TCP listener on 9011 is therefore something local and unregistered; find the process.",
"exposure": {
"verdict": "careful",
"note": "For a D-Star gateway the UDP side is meant to reach other gateways; a TCP listener here is unexplained until you identify it."
},
"checkCommand": "sudo lsof -nP -iTCP:9011 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 9011",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=9011",
"kind": "iana"
}
]
},
{
"port": 9040,
"protocol": "tcp",
"service": "Tor TransPort (convention)",
"oneLiner": "The number Tor transparent-proxy setups conventionally use for TransPort — not an IANA assignment and not a Tor default.",
"whatItIs": "Tor's TransPort option accepts TCP connections that a firewall has transparently redirected, so traffic gets torified without the application knowing about SOCKS. Tor ships it disabled (the default is 0) and does not pick a port for you; 9040 is simply the number that torrc examples and Tor-routing gateway configurations settled on, which is why iptables/pf rules everywhere redirect to it. IANA lists 9027–9049 as Unassigned. A listener on 9040 means a Tor transparent proxy is configured on that host or gateway.",
"exposure": {
"verdict": "never",
"note": "A reachable TransPort is an open proxy into the Tor network for anyone who can send it a redirected connection; bind it to the internal interface it is meant to serve."
},
"checkCommand": "sudo lsof -nP -iTCP:9040 -sTCP:LISTEN",
"links": [
{
"title": "tor(1) manual — TransPort",
"url": "https://manpages.debian.org/unstable/tor/tor.1.en.html",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 9040",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=9040",
"kind": "iana"
}
]
},
{
"port": 9050,
"protocol": "tcp",
"service": "Tor SOCKS proxy",
"oneLiner": "Tor's default SocksPort — the local SOCKS5 endpoint applications use to route through Tor.",
"whatItIs": "The tor daemon listens on 9050 by default for connections from SOCKS-speaking applications, which is how curl, SSH, and everything else gets onto the Tor network. It is a per-machine local service: seeing it means the tor daemon is installed and running, not that the host is a relay. Tor Browser bundles its own tor on 9150 instead, so 9050 usually means a system tor package. IANA registers 9050/tcp to something unrelated (versiera).",
"exposure": {
"verdict": "never",
"note": "An externally reachable SocksPort is an open proxy — strangers relay traffic through your Tor client and your IP; keep it on 127.0.0.1."
},
"checkCommand": "curl -s --socks5-hostname 127.0.0.1:9050 https://check.torproject.org/api/ip",
"links": [
{
"title": "tor(1) manual — SocksPort (default 9050)",
"url": "https://manpages.debian.org/unstable/tor/tor.1.en.html",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 9050",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=9050",
"kind": "iana"
}
],
"ianaName": "versiera"
},
{
"port": 9071,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned by IANA, inside the empty 9061–9079 block, with no service that commonly claims it.",
"whatItIs": "IANA lists 9061–9079 as Unassigned, so 9071 has no service name and no protocol you can assume. No widely deployed product defaults here. If it is open, an application or an operator chose the number, and the only honest identification is finding the process that owns the socket.",
"exposure": {
"verdict": "careful",
"note": "Decide after identification; an unregistered port carries no implied safety."
},
"checkCommand": "sudo lsof -nP -iTCP:9071 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 9071",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=9071",
"kind": "iana"
}
]
},
{
"port": 9080,
"protocol": "tcp",
"service": "Open Liberty / WebSphere Liberty HTTP",
"oneLiner": "The default HTTP port for Open Liberty and WebSphere Liberty Java application servers.",
"whatItIs": "Open Liberty and IBM WebSphere Liberty ship with HTTP on 9080 and HTTPS on 9443, so a Java shop's application servers, and the sample apps in their tutorials, all answer here. Anything else that needs a second HTTP-alt port also reaches for 9080 because it reads as \"80, but higher\". IANA registers the port as glrpc (Groove GLRPC), a Microsoft Groove component you will not encounter now.",
"exposure": {
"verdict": "careful",
"note": "Legitimate as an application listener, but it is plain HTTP — put TLS termination and access control in front of it rather than publishing 9080 directly."
},
"checkCommand": "curl -sI http://TARGET:9080/",
"links": [
{
"title": "Open Liberty — default port numbers (HTTP 9080, HTTPS 9443)",
"url": "https://openliberty.io/docs/latest/reference/default-port-numbers.html",
"kind": "official-docs"
},
{
"title": "OpenLiberty/open-liberty on GitHub",
"url": "https://github.com/OpenLiberty/open-liberty",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 9080",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=9080",
"kind": "iana"
}
],
"ianaName": "glrpc"
},
{
"port": 9081,
"protocol": "tcp",
"service": "Reserved (TCP)",
"oneLiner": "IANA holds 9081/tcp Reserved, so in practice it is the port the second app server got.",
"whatItIs": "The registry marks 9081/tcp Reserved and assigns 9081/udp to cisco-aqos. With no TCP assignment, what you find is a local choice — most often the next HTTP port after 9080 when two Java application-server instances share a host, or a sidecar or metrics endpoint of whatever runs on 9080. Its meaning is entirely inherited from its neighbour, so look at 9080 on the same host first.",
"exposure": {
"verdict": "careful",
"note": "Same treatment as the 9080 service it usually accompanies: plain HTTP behind a proxy, never published raw."
},
"checkCommand": "curl -sI http://TARGET:9081/",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 9081",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=9081",
"kind": "iana"
}
]
},
{
"port": 9090,
"protocol": "tcp",
"service": "Prometheus, Cockpit",
"oneLiner": "Prometheus's web UI and API by default, and Cockpit's web console on Linux servers — two very different things on one number.",
"whatItIs": "A fresh Prometheus serves its status page and HTTP API on 9090, so on a monitoring host that is almost certainly what it is. On a Linux server it is at least as likely to be Cockpit, whose web console is reached at https://host:9090 and which logs you in with system credentials. IANA registers 9090 as websm (IBM Web-based System Manager). Tell them apart by whether the port speaks TLS and what the root path returns.",
"exposure": {
"verdict": "careful",
"note": "Cockpit is designed to be reached over HTTPS with real logins; Prometheus is not — it has no authentication out of the box and its API exposes every metric you collect, so put it behind a proxy or Prometheus's own web config."
},
"checkCommand": "curl -sI http://TARGET:9090/",
"links": [
{
"title": "Prometheus — getting started (status page on localhost:9090)",
"url": "https://prometheus.io/docs/prometheus/latest/getting_started/",
"kind": "official-docs"
},
{
"title": "Cockpit — running Cockpit (https://ip:9090)",
"url": "https://cockpit-project.org/running.html",
"kind": "official-docs"
},
{
"title": "prometheus/prometheus on GitHub",
"url": "https://github.com/prometheus/prometheus",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 9090",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=9090",
"kind": "iana"
}
],
"ianaName": "websm"
},
{
"port": 9091,
"protocol": "tcp",
"service": "Transmission RPC / Prometheus Pushgateway",
"oneLiner": "Usually a Transmission BitTorrent web UI or a Prometheus Pushgateway — both default here.",
"whatItIs": "IANA has 9091 registered to a private assignment called xmltec-xmlmail that you will essentially never meet. In practice the port belongs to two popular pieces of software: Transmission's RPC and web interface (the /transmission/web/ UI behind transmission-daemon), and the Prometheus Pushgateway, which listens on 9091 by default for metrics pushed by batch jobs. On a home or lab network a listener here is almost always Transmission on a NAS or seedbox; in a monitoring stack it is the Pushgateway.",
"exposure": {
"verdict": "never",
"note": "Transmission's RPC lets a caller add torrents and set the download directory, and older builds shipped with weak or absent authentication; the Pushgateway accepts unauthenticated metric writes and deletes. Keep both on the LAN or behind an authenticating reverse proxy."
},
"checkCommand": "curl -sS -m 5 -o /dev/null -w '%{http_code}\\n' http://TARGET:9091/",
"links": [
{
"title": "transmission/transmission",
"url": "https://github.com/transmission/transmission",
"kind": "github"
},
{
"title": "prometheus/pushgateway (default listen port 9091)",
"url": "https://github.com/prometheus/pushgateway",
"kind": "github"
},
{
"title": "IANA port registry — 9091 (xmltec-xmlmail)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=9091",
"kind": "iana"
}
]
},
{
"port": 9098,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "No IANA registration and no common software — an open 9098 is whatever someone put there.",
"whatItIs": "9098 is unassigned in the IANA service name and port number registry, and nmap's services file lists it as unknown with a very low observed frequency. There is no standard protocol, no default daemon, and no well-documented malware association to report. If you find it open, the answer comes from the host itself: a service-version scan or the process listening on the box.",
"exposure": {
"verdict": "careful",
"note": "The verdict depends entirely on what is actually bound there; identify the service before deciding, and do not assume an unregistered high port is harmless."
},
"checkCommand": "nmap -sV -Pn -p 9098 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "nmap-services (port frequency and name table)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 9099,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unregistered and uncommon — no standard service claims 9099.",
"whatItIs": "Like its neighbour 9098, port 9099 carries no IANA registration and appears in nmap's services table only as unknown. Applications occasionally pick it as an arbitrary secondary listener, but there is no protocol you can assume from the number alone. Fingerprint the listener rather than guessing.",
"exposure": {
"verdict": "careful",
"note": "Judge it by the service you find behind it; an unregistered port is not evidence of either safety or danger."
},
"checkCommand": "nmap -sV -Pn -p 9099 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "nmap-services (port frequency and name table)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 9100,
"protocol": "tcp",
"service": "Raw printing (AppSocket / JetDirect, PDL data stream)",
"oneLiner": "A network printer: send bytes, they print — no protocol, no login.",
"whatItIs": "Registered with IANA as pdl-datastream / hp-pdl-datastr, this is the AppSocket protocol, better known as JetDirect after the HP print servers that popularised it. There is no handshake and no authentication: the client opens the socket, writes a page description stream such as PostScript, PCL, or ZPL, and closes it. CUPS drives it with the socket backend (socket://host:9100), and it is one of the most commonly open ports on any office network. Label printers, MFPs, and print server appliances all sit here.",
"exposure": {
"verdict": "never",
"note": "Anyone who can reach the port can print, waste consumables, and on many devices push firmware or PJL commands that change settings — there is no authentication in the protocol at all."
},
"checkCommand": "nc -vz -w 3 TARGET 9100",
"links": [
{
"title": "CUPS — Network printing (AppSocket/JetDirect on port 9100)",
"url": "https://www.cups.org/doc/network.html",
"kind": "official-docs"
},
{
"title": "IANA port registry — 9100 (pdl-datastream)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=9100",
"kind": "iana"
}
]
},
{
"port": 9101,
"protocol": "tcp",
"service": "Bacula Director / JetDirect port 2",
"oneLiner": "Either a Bacula backup Director or the second raw-print port on a multi-port print server.",
"whatItIs": "IANA registers 9101 to the Bacula Director, the daemon that schedules backup jobs and that bconsole and the Bareos fork's console connect to. The same port is also the second AppSocket/JetDirect print channel on multi-port HP print servers, so nmap labels it both ways. Which one you have is usually obvious from the host: a backup server or a printer.",
"exposure": {
"verdict": "never",
"note": "The Director is the control plane for every backup and restore in the estate; it authenticates with shared secrets from the config files and belongs on a management network, not the internet."
},
"checkCommand": "nc -vz -w 3 TARGET 9101",
"links": [
{
"title": "IANA port registry — 9101 (bacula-dir)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=9101",
"kind": "iana"
},
{
"title": "Bacula documentation",
"url": "https://www.bacula.org/documentation/",
"kind": "official-docs"
},
{
"title": "bareos/bareos (Bareos, the widely packaged Bacula-derived backup suite)",
"url": "https://github.com/bareos/bareos",
"kind": "github"
}
]
},
{
"port": 9102,
"protocol": "tcp",
"service": "Bacula File Daemon / JetDirect port 3",
"oneLiner": "The Bacula/Bareos client agent on a backed-up machine — or a printer's third raw-print port.",
"whatItIs": "The Bacula File Daemon runs on every machine that gets backed up; the Director contacts it on 9102 to enumerate and read files, and the daemon then streams data to the Storage Daemon. Bareos uses the same port for its file daemon. HP multi-port print servers also expose a third AppSocket channel here, which is why scanners report both names.",
"exposure": {
"verdict": "never",
"note": "The file daemon reads arbitrary paths on the host on behalf of whoever authenticates to it — this is a whole-filesystem read primitive and must stay on an internal backup network."
},
"checkCommand": "nc -vz -w 3 TARGET 9102",
"links": [
{
"title": "IANA port registry — 9102 (bacula-fd)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=9102",
"kind": "iana"
},
{
"title": "Bacula documentation",
"url": "https://www.bacula.org/documentation/",
"kind": "official-docs"
},
{
"title": "bareos/bareos",
"url": "https://github.com/bareos/bareos",
"kind": "github"
}
]
},
{
"port": 9103,
"protocol": "tcp",
"service": "Bacula Storage Daemon",
"oneLiner": "Where Bacula/Bareos backup data actually lands: the storage daemon.",
"whatItIs": "The Storage Daemon owns the tapes, disk volumes, and autochangers, and both the Director and the file daemons connect to it on 9103 to write and read backup volumes. It is the third of Bacula's three daemons, completing the 9101/9102/9103 set, and Bareos inherits the same layout. Some HP print servers also use 9103 as a further raw-print channel.",
"exposure": {
"verdict": "never",
"note": "Reaching the storage daemon means reaching the backup data itself; keep it inside the backup network and rely on Bacula's TLS options for any link that leaves a trusted segment."
},
"checkCommand": "nc -vz -w 3 TARGET 9103",
"links": [
{
"title": "IANA port registry — 9103 (bacula-sd)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=9103",
"kind": "iana"
},
{
"title": "Bacula documentation",
"url": "https://www.bacula.org/documentation/",
"kind": "official-docs"
},
{
"title": "bareos/bareos",
"url": "https://github.com/bareos/bareos",
"kind": "github"
}
]
},
{
"port": 9110,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "No IANA registration; nothing standard listens here.",
"whatItIs": "9110 has no entry in the IANA registry and appears in nmap's services table only as unknown. It sits next to the JetDirect and Bacula cluster in the low 9100s, so an open 9110 on a printer or backup host is worth checking against that vendor's own port list, but the number itself implies nothing. Identify the process on the host before drawing conclusions.",
"exposure": {
"verdict": "careful",
"note": "Unregistered does not mean unimportant — fingerprint the listener and apply the verdict that service deserves."
},
"checkCommand": "nmap -sV -Pn -p 9110 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "nmap-services (port frequency and name table)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 9111,
"protocol": "tcp",
"service": "hexxorecore (historically Dragon IDS console)",
"oneLiner": "Registered in 2018 to a message bus called hexxorecore; older tools still label it Dragon IDS Console.",
"whatItIs": "IANA assigned 9111 to Hexxore in July 2018 for hexxorecore, described as a multiple-purpose distributed message bus. Before that registration, nmap's services file named the port DragonIDSConsole after the Enterasys Dragon intrusion-detection console, and that older label still shows up in scan output today. Neither is common on a modern network, so treat a listener here as something to fingerprint rather than something you already know.",
"exposure": {
"verdict": "careful",
"note": "An IDS management console or a message bus is an internal control-plane service; if that is what you find, it should not be reachable from outside the management network."
},
"checkCommand": "nmap -sV -Pn -p 9111 TARGET",
"links": [
{
"title": "IANA port registry — 9111 (hexxorecore)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=9111",
"kind": "iana"
},
{
"title": "nmap-services (records the older DragonIDSConsole label)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 9191,
"protocol": "tcp",
"service": "PaperCut admin UI (registered as Sun AppSvr JPDA)",
"oneLiner": "Almost always the PaperCut print-management web console, despite the Java-debugger registration.",
"whatItIs": "IANA registered 9191 in 2005 as sun-as-jpda, the Java Platform Debugger Architecture port for Sun's application server, and scanners still print that name. In the field the port belongs to PaperCut NG/MF, whose Application Server serves its admin and end-user web interface on 9191 over HTTP with 9192 as the HTTPS counterpart; print servers and workstation clients also talk to it. A listener on 9191 in an office almost always means a PaperCut server.",
"exposure": {
"verdict": "never",
"note": "It is a cleartext HTTP admin console for print accounting, user balances, and server configuration. Use the 9192 HTTPS port and keep both off the public internet; a JPDA debug port would be even worse, since JDWP grants code execution with no authentication."
},
"checkCommand": "curl -sS -m 5 -o /dev/null -w '%{http_code}\\n' http://TARGET:9191/",
"links": [
{
"title": "IANA port registry — 9191 (sun-as-jpda)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=9191",
"kind": "iana"
},
{
"title": "PaperCut NG/MF — Change the Application Server ports",
"url": "https://www.papercut.com/help/manuals/ng-mf/common/sys-security-options-change-ports/",
"kind": "official-docs"
}
]
},
{
"port": 9197,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unregistered; no standard service and no reliable reputation.",
"whatItIs": "9197 carries no IANA assignment and is listed as unknown in nmap's services file. Vendor software sometimes chooses it for a private listener, but nothing about the number tells you which. Determine the service from the host itself.",
"exposure": {
"verdict": "careful",
"note": "Assess the actual listener; there is no default to inherit a verdict from."
},
"checkCommand": "nmap -sV -Pn -p 9197 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "nmap-services (port frequency and name table)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 9198,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unregistered and rarely seen — identify the listener, the number tells you nothing.",
"whatItIs": "There is no IANA registration for 9198 and nmap's table records it as unknown with a very low hit rate. It is close enough to PaperCut's 9191/9192 pair that an office host may have a related private listener, but that is a guess, not a fact. A version scan or a look at the host's own listening sockets is the only honest answer.",
"exposure": {
"verdict": "careful",
"note": "No default service means no default verdict; classify it once you know what answers there."
},
"checkCommand": "nmap -sV -Pn -p 9198 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "nmap-services (port frequency and name table)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 9200,
"protocol": "tcp",
"service": "Elasticsearch / OpenSearch REST API",
"oneLiner": "A search cluster's HTTP API — hit / and it hands you its name, version, and cluster.",
"whatItIs": "Elasticsearch binds its REST API to the first free port in 9200-9300, which in practice is 9200 (node-to-node transport uses 9300); OpenSearch, the fork, keeps the same default. A plain GET of the root returns a JSON banner with the cluster name and version, and every index, document, and admin operation is available over the same interface. IANA's registration for the port is the long-obsolete WAP connectionless session service, which you will never actually meet.",
"exposure": {
"verdict": "never",
"note": "Exposed clusters with no authentication are a standing cause of mass data leaks and ransom-note indices — the API can read, rewrite, and delete every document. Enable security and put it behind a proxy or a private network."
},
"checkCommand": "curl -sS -m 5 http://TARGET:9200/",
"links": [
{
"title": "Elasticsearch — Networking (http.port defaults to 9200-9300)",
"url": "https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-network.html",
"kind": "official-docs"
},
{
"title": "elastic/elasticsearch",
"url": "https://github.com/elastic/elasticsearch",
"kind": "github"
},
{
"title": "IANA port registry — 9200 (wap-wsp)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=9200",
"kind": "iana"
}
]
},
{
"port": 9207,
"protocol": "tcp",
"service": "WAP vCal Secure",
"oneLiner": "A dead WAP Forum registration for secure calendar push — effectively never seen today.",
"whatItIs": "9207 is registered to the WAP Forum as wap-vcal-s, the secure variant of the WAP vCal calendar service from the mobile WAP stack of the late 1990s and early 2000s. That stack was retired once phones got real IP browsers, and the block of WAP ports around 9200-9210 is now historical. If 9207 is open on a modern host it is far more likely to be an arbitrary application than anything WAP-related.",
"exposure": {
"verdict": "careful",
"note": "Nothing legitimate should be serving WAP here; treat an open 9207 as an unidentified service and fingerprint it."
},
"checkCommand": "nmap -sV -Pn -p 9207 TARGET",
"links": [
{
"title": "IANA port registry — 9207 (wap-vcal-s)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=9207",
"kind": "iana"
}
]
},
{
"port": 9220,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "No IANA registration — commonly a vendor-private listener, often on printers.",
"whatItIs": "9220 is unassigned in the IANA registry and unknown to nmap's services file. It turns up on multifunction office devices and other appliances as a vendor-chosen management or scan-related port, so the device's own documentation is the authority, not the port number. Confirm with a version scan against the actual host.",
"exposure": {
"verdict": "careful",
"note": "Appliance-private ports are usually unauthenticated management surfaces; keep them on the device VLAN until you know exactly what answers."
},
"checkCommand": "nmap -sV -Pn -p 9220 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "nmap-services (port frequency and name table)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 9290,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unregistered and uncommon; nothing standard claims 9290.",
"whatItIs": "The IANA registry has no assignment for 9290 and nmap lists it as unknown. Like the rest of the sparsely used 9200-9400 range it shows up as an application's arbitrary choice rather than as a protocol. Fingerprint the listener rather than reading meaning into the number.",
"exposure": {
"verdict": "careful",
"note": "The verdict belongs to whatever service is bound there; establish that first."
},
"checkCommand": "nmap -sV -Pn -p 9290 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "nmap-services (port frequency and name table)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 9409,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "No registration, no default service — an open 9409 is entirely site-specific.",
"whatItIs": "9409 has no IANA assignment and appears as unknown in nmap's services table with a negligible observed frequency. There is no protocol, product default, or documented malware family to attach to it. Whatever is listening was configured by hand or chosen by an application at random.",
"exposure": {
"verdict": "careful",
"note": "Judge it on the service behind it; nothing about the number argues either way."
},
"checkCommand": "nmap -sV -Pn -p 9409 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "nmap-services (port frequency and name table)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 9415,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unregistered; scanners see it occasionally but with no consistent service behind it.",
"whatItIs": "There is no IANA registration for 9415, and nmap's services file records it as unknown, appearing slightly more often than its neighbours but without a name attached. That pattern is typical of a port picked by one or two products rather than by a standard. Only a version scan of the specific host will tell you what it is.",
"exposure": {
"verdict": "careful",
"note": "Identify the listener before exposing or trusting it; an unnamed port is an unaudited one."
},
"checkCommand": "nmap -sV -Pn -p 9415 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "nmap-services (port frequency and name table)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 9418,
"protocol": "tcp",
"service": "Git protocol (git daemon)",
"oneLiner": "git:// — anonymous, unauthenticated, unencrypted Git clones.",
"whatItIs": "git daemon serves the Git pack transfer protocol on 9418, the transport behind git:// URLs; the registration is Linus Torvalds' own, from 2005. It is the fastest way to publish read-only repositories because it does no authentication and no encryption at all, and by default it will only export repositories explicitly marked with git-daemon-export-ok. GitHub disabled git:// entirely in 2022 because an unauthenticated transport gives a network attacker the ability to alter the code you clone.",
"exposure": {
"verdict": "careful",
"note": "Read-only public mirrors are the design intent, but there is no integrity protection on the wire — prefer HTTPS or SSH, and never enable the receive-pack (push) service, which would let anyone write to your repositories."
},
"checkCommand": "git -c protocol.version=1 ls-remote git://TARGET/repo.git",
"links": [
{
"title": "git-daemon documentation (default port 9418)",
"url": "https://git-scm.com/docs/git-daemon",
"kind": "official-docs"
},
{
"title": "git/git",
"url": "https://github.com/git/git",
"kind": "github"
},
{
"title": "IANA port registry — 9418 (git)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=9418",
"kind": "iana"
}
]
},
{
"port": 9443,
"protocol": "tcp",
"service": "HTTPS alternate (Portainer, WSO2, appliance consoles)",
"oneLiner": "The default second HTTPS port — usually a management UI in a Java or container stack.",
"whatItIs": "IANA registered 9443 to WSO2 as tungsten-https, and WSO2 products still serve their management console over it. The port became the generic \"HTTPS on a non-privileged port\" convention: Portainer publishes its UI on 9443, Tomcat and other Java servers commonly pair 9443 with 9080/8080, and a long list of network appliances use it for their web admin. Expect TLS and an administrative login page.",
"exposure": {
"verdict": "careful",
"note": "The transport is encrypted, but what sits behind it is usually a full administrative console — often with a default certificate and, on appliances, default credentials. Restrict it to a management network."
},
"checkCommand": "curl -skI --max-time 5 https://TARGET:9443/",
"links": [
{
"title": "IANA port registry — 9443 (tungsten-https)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=9443",
"kind": "iana"
},
{
"title": "Portainer — install Portainer Server (UI on 9443)",
"url": "https://docs.portainer.io/start/install-ce/server/docker/linux",
"kind": "official-docs"
}
]
},
{
"port": 9444,
"protocol": "tcp",
"service": "WSO2 ESB administration console (HTTPS)",
"oneLiner": "The next HTTPS admin port after 9443 — typically a second WSO2 node with a port offset.",
"whatItIs": "IANA registered 9444 in 2008 for the WSO2 ESB administration console over HTTPS. WSO2 servers apply a numeric port offset when several run on one host, so a second instance lands its console on 9444 while the first uses 9443; other products copy the same 9443/9444 pairing for a spare TLS listener. In practice, treat it as another admin web interface until proven otherwise.",
"exposure": {
"verdict": "careful",
"note": "An integration-bus admin console can deploy code and read credentials for every connected system — TLS does not make it safe to publish."
},
"checkCommand": "curl -skI --max-time 5 https://TARGET:9444/",
"links": [
{
"title": "IANA port registry — 9444 (wso2esb-console)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=9444",
"kind": "iana"
}
]
},
{
"port": 9485,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unregistered; no standard service, no documented reputation.",
"whatItIs": "9485 has no IANA assignment and nmap's services table lists it as unknown. Nothing in the registry or the common service databases claims it, so an open 9485 is whatever a local application chose. Fingerprint it on the host.",
"exposure": {
"verdict": "careful",
"note": "Classify it by the service you find; an unregistered port inherits no default verdict."
},
"checkCommand": "nmap -sV -Pn -p 9485 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "nmap-services (port frequency and name table)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 9500,
"protocol": "tcp",
"service": "ismserver",
"oneLiner": "Registered as ismserver, a private assignment with no public specification.",
"whatItIs": "IANA lists 9500 for both TCP and UDP as ismserver, an individual registration with no published protocol description, and nmap carries the same bare name. There is no open specification to read and no widely deployed open-source daemon that defaults here, so the registration tells you little. Being a round number just below the ephemeral range, 9500 is also a popular arbitrary choice for internal application listeners.",
"exposure": {
"verdict": "careful",
"note": "Without a known protocol there is no reason to trust it; identify the process and apply that service's rules."
},
"checkCommand": "nmap -sV -Pn -p 9500 TARGET",
"links": [
{
"title": "IANA port registry — 9500 (ismserver)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=9500",
"kind": "iana"
},
{
"title": "nmap-services (port frequency and name table)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 9501,
"protocol": "tcp",
"service": "Swoole application server (unregistered)",
"oneLiner": "Unassigned at IANA, but the port every Swoole PHP example listens on — so a PHP coroutine app server is the usual answer.",
"whatItIs": "IANA has no assignment for 9501. In practice it is the number baked into Swoole's own documentation and README examples: `new Swoole\\Http\\Server('127.0.0.1', 9501)` and the matching WebSocket server. Swoole is a PHP extension that turns PHP into a long-running event-driven server, so a listener here is usually a Laravel Octane, Hyperf, or hand-rolled Swoole process that a copy-pasted example never renamed. Anything else on 9501 is an application picking a free high port.",
"exposure": {
"verdict": "careful",
"note": "An app server, not a proxy — it usually has no TLS, no request-size limits, and no access logging of its own. Put it behind nginx or a load balancer and bind it to localhost."
},
"checkCommand": "curl -sI http://TARGET:9501/",
"links": [
{
"title": "Swoole source repository (server examples use 9501)",
"url": "https://github.com/swoole/swoole-src",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 9502,
"protocol": "tcp",
"service": "Swoole secondary listener (unregistered)",
"oneLiner": "Unassigned at IANA; in practice the second port in Swoole's multi-protocol server example, right next to 9501.",
"whatItIs": "There is no IANA registration for 9502. Swoole's README shows a mixed server that serves HTTP/WebSocket on 9501 and adds a raw TCP listener on 9502, which is why the pair shows up together on hosts running PHP coroutine servers. Outside that, 9502 is an ordinary unclaimed high port that an application may have chosen for itself. Identify it by what answers, not by the number.",
"exposure": {
"verdict": "careful",
"note": "Typically a raw TCP application port with whatever authentication the app implements — which is often none. Keep it on a private interface until you know what protocol it speaks."
},
"checkCommand": "sudo lsof -nP -iTCP:9502 -sTCP:LISTEN",
"links": [
{
"title": "Swoole source repository (mixed server example uses 9502)",
"url": "https://github.com/swoole/swoole-src",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 9503,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "No IANA assignment and no well-established service — whatever is listening chose the number itself.",
"whatItIs": "9503 is unassigned in the IANA service name and port number registry, and Nmap's service database lists it as `unknown` with a very low observed frequency. It sits just above the ports Swoole's documentation uses for its example servers, so it sometimes appears on the same hosts as an extra application listener, but nothing standard claims it. Treat a listener here as an unidentified local application and fingerprint it directly.",
"exposure": {
"verdict": "careful",
"note": "An unidentified service is an unassessed service. Find out what it is before deciding, and do not assume an obscure port number is protection."
},
"checkCommand": "sudo lsof -nP -iTCP:9503 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 9535,
"protocol": "both",
"service": "mngsuite — Management Suite Remote Control",
"oneLiner": "Registered to LANDesk (now Ivanti) Management Suite for remote control of managed desktops.",
"whatItIs": "IANA registered 9535 as `mngsuite`, \"Management Suite Remote Control\", in 2010 on behalf of LANDesk. It belongs to the endpoint-management agent that ships with LANDesk / Ivanti Endpoint Manager, alongside the agent's other ports in the 9593-9595 range. Nmap's service table still calls it `man`, an older name for the same listener. On a scan it means a managed Windows desktop or server with the vendor agent installed, not a general-purpose service you can talk to.",
"exposure": {
"verdict": "never",
"note": "This is a remote-control plane for whole workstations. It belongs on a management VLAN reachable only from the management server, never on a public interface."
},
"checkCommand": "sudo lsof -nP -iTCP:9535 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 9575,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned at IANA and effectively unseen in the wild — no standard service lives here.",
"whatItIs": "The IANA registry has no entry for 9575 on TCP or UDP, and Nmap's service database records it as `unknown` with one of the lowest observed frequencies in the 9000s. There is no documented protocol, product default, or malware association worth repeating. If something is listening, it is a local application that picked a free high port; identify it by process rather than by number.",
"exposure": {
"verdict": "careful",
"note": "Nothing here is known-safe or known-bad. Determine the owning process before exposing it anywhere."
},
"checkCommand": "sudo lsof -nP -iTCP:9575 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 9593,
"protocol": "both",
"service": "cba8 — LANDesk/Ivanti Management Agent",
"oneLiner": "The LANDesk (Ivanti Endpoint Manager) CBA8 agent listener, first of the 9593-9595 trio on managed endpoints.",
"whatItIs": "IANA registered 9593 as `cba8`, \"LANDesk Management Agent (cba8)\", in 2010. CBA8 is the common base agent that the LANDesk / Ivanti Endpoint Manager core server talks to for inventory, software distribution, and policy. It is almost always seen together with 9594 and 9595, which are registered to the same product family, so the three appearing side by side is a reliable fingerprint for a managed Windows estate. A single open 9593 with nothing else usually means a leftover agent on a decommissioned machine.",
"exposure": {
"verdict": "never",
"note": "A management agent accepts instructions from a core server, which makes it a software-deployment channel. Restrict it to the management network."
},
"checkCommand": "sudo lsof -nP -iTCP:9593 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 9594,
"protocol": "both",
"service": "msgsys — Message System",
"oneLiner": "Registered as \"Message System\"; in practice the middle port of the LANDesk/Ivanti agent's 9593-9595 group.",
"whatItIs": "IANA lists 9594 as `msgsys`, \"Message System\", with no referenced specification, which is as much as the registry says. It is bracketed by two ports registered to LANDesk's management agent and is observed at the same frequency as them in Nmap's service data, so the practical reading of an open 9594 is the same endpoint-management agent rather than an independent messaging product. There is no public protocol document to point at.",
"exposure": {
"verdict": "never",
"note": "Treat it as part of the management agent it travels with: internal management network only."
},
"checkCommand": "sudo lsof -nP -iTCP:9594 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 9595,
"protocol": "both",
"service": "pds — Ping Discovery Service",
"oneLiner": "Registered as the Ping Discovery Service, the discovery half of the LANDesk/Ivanti agent port group.",
"whatItIs": "IANA registers 9595 as `pds`, \"Ping Discovery Service\". It is the port a management core server probes to decide whether a host is alive and carrying the agent, which is why it appears alongside 9593 (cba8) and 9594 on managed Windows machines. Nmap's database records it under the same name with the alternate spelling \"Ping Discovery System\". Like the rest of the group, there is no public wire specification.",
"exposure": {
"verdict": "never",
"note": "A discovery responder tells anyone who asks that a managed agent is present and reachable. Keep it off untrusted networks."
},
"checkCommand": "sudo lsof -nP -iTCP:9595 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 9600,
"protocol": "both",
"service": "Logstash monitoring API, OMRON FINS",
"oneLiner": "Registered to Micromuse, but in the wild it is either Logstash's monitoring API or an OMRON PLC speaking FINS.",
"whatItIs": "IANA's assignment is `micromuse-ncpw`, from the Micromuse/Netcool product line. Two unrelated modern uses dominate what you actually find. Logstash binds its HTTP monitoring API to tcp:9600 by default, serving unauthenticated JSON about pipelines, plugins, and JVM state. On industrial networks, OMRON PLCs speak the FINS protocol on 9600 over both TCP and UDP — Nmap ships an `omron-info` script that queries controller details there. A banner grab tells the two apart immediately: JSON means Logstash, binary means a PLC.",
"exposure": {
"verdict": "never",
"note": "Both realistic occupants are bad news exposed. The Logstash API is unauthenticated introspection of your pipeline, and FINS is an unauthenticated industrial control protocol that should not touch a routable network at all."
},
"checkCommand": "curl -s http://TARGET:9600/",
"links": [
{
"title": "Monitoring Logstash with APIs (default binding tcp:9600)",
"url": "https://www.elastic.co/guide/en/logstash/current/monitoring-logstash.html",
"kind": "official-docs"
},
{
"title": "Nmap NSE omron-info — OMRON FINS on port 9600",
"url": "https://nmap.org/nsedoc/scripts/omron-info.html",
"kind": "official-docs"
},
{
"title": "Logstash source repository",
"url": "https://github.com/elastic/logstash",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 9618,
"protocol": "both",
"service": "HTCondor collector",
"oneLiner": "The HTCondor collector daemon — the directory every machine and job scheduler in a batch-computing pool reports to.",
"whatItIs": "HTCondor is the distributed high-throughput computing system from UW-Madison, used to run batch workloads across university and lab clusters. Port 9618 is registered to `condor` and is the default port for `condor_collector`, the daemon that every startd, schedd, and negotiator in the pool contacts to advertise and look up ClassAds. Optionally an installation enables `condor_shared_port`, in which case daemons share a different single listener and the collector moves with it. An open 9618 means a machine is acting as a pool central manager.",
"exposure": {
"verdict": "never",
"note": "The collector is the control plane for job placement across a whole cluster. Reachable only from pool members, with HTCondor's own authentication and authorization configured — the defaults are permissive."
},
"checkCommand": "condor_status -pool TARGET:9618",
"links": [
{
"title": "HTCondor networking documentation (default collector port 9618)",
"url": "https://htcondor.readthedocs.io/en/latest/admin-manual/networking.html",
"kind": "official-docs"
},
{
"title": "HTCondor source repository",
"url": "https://github.com/htcondor/htcondor",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 9621,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "No IANA assignment, no documented service — an unclaimed high port.",
"whatItIs": "IANA has no registration for 9621 on TCP or UDP, and Nmap records it as `unknown` at a very low frequency. Nothing standard, no product default, and no well-documented malware claims it. A listener here is an application that picked an arbitrary free port, so the useful move is to find the owning process rather than look the number up.",
"exposure": {
"verdict": "careful",
"note": "Unknown service, unknown risk. Identify the process first; an unlabelled high port is frequently something that was never meant to leave localhost."
},
"checkCommand": "sudo lsof -nP -iTCP:9621 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 9643,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned at IANA with no established occupant — identify it locally, not from a port list.",
"whatItIs": "There is no IANA service registration for 9643, and Nmap's frequency data puts it among the rarely-observed ports. No widely deployed product uses it as a default and there is no notable published malware association. Anything found here is application-specific.",
"exposure": {
"verdict": "careful",
"note": "With no known protocol there is nothing to vouch for. Determine what answers before allowing it through a firewall."
},
"checkCommand": "sudo lsof -nP -iTCP:9643 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 9666,
"protocol": "tcp",
"service": "zoomcp — Zoom Control Panel game server management",
"oneLiner": "Registered in 2014 to Zoom Control Panel, a game-server hosting panel — nothing to do with Zoom video conferencing.",
"whatItIs": "IANA assigned 9666/tcp the service name `zoomcp`, \"Zoom Control Panel Game Server Management\"; the UDP side is marked Reserved. It belongs to a game-server hosting control panel that lets customers start, stop, and configure dedicated game servers. The name collision with the video-conferencing product is coincidental and a frequent source of confusion in port lookups. The registration is the substantial fact here — public protocol documentation is not available.",
"exposure": {
"verdict": "never",
"note": "A hosting control panel is an administrative interface that starts and stops processes. If it must be reachable, put it behind a VPN or an authenticating reverse proxy with TLS."
},
"checkCommand": "sudo lsof -nP -iTCP:9666 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 9673,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned at IANA and not associated with any documented service.",
"whatItIs": "The IANA registry contains no entry for 9673, and Nmap classifies it as `unknown` with a low observation rate. No standard protocol, vendor default, or well-attested malware uses it. The honest answer to \"what runs on 9673\" is: whatever you installed. Find the process and work from there.",
"exposure": {
"verdict": "careful",
"note": "No known service means no known security posture. Identify it before exposing it."
},
"checkCommand": "sudo lsof -nP -iTCP:9673 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 9815,
"protocol": "both",
"service": "Unassigned",
"oneLiner": "No IANA assignment on TCP or UDP; nothing standard listens here.",
"whatItIs": "IANA has no service registered on 9815 in either transport. Nmap's service database lists it as `unknown` on both TCP and UDP at low frequency, which reflects occasional application use rather than any particular product. There is no protocol document to consult and no notable security folklore attached to the number.",
"exposure": {
"verdict": "careful",
"note": "Unidentified service. Establish what it is locally, then decide — the port number carries no information either way."
},
"checkCommand": "sudo lsof -nP -iTCP:9815 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 9876,
"protocol": "tcp",
"service": "Karma test runner; sd (Session Director)",
"oneLiner": "IANA says Session Director, but on a developer's machine this is almost always the Karma browser test runner.",
"whatItIs": "The registration is `sd`, \"Session Director\", from Van Jacobson's MBone-era session-announcement work, which you will effectively never meet today. What you will meet is Karma: its default `port` config value is 9876, and it runs a web server that browsers connect to in order to execute a project's unit tests. Karma was deprecated by its maintainers in favour of Web Test Runner, Jest, and Vitest, but it is still present in many Angular and older JavaScript projects, so a listener on 9876 usually means a test run in progress or a CI container that did not shut down.",
"exposure": {
"verdict": "never",
"note": "Karma exists to load arbitrary project JavaScript into a connected browser. Exposing it hands strangers a code-execution surface in whatever browser reaches it; keep it bound to localhost."
},
"checkCommand": "curl -sI http://localhost:9876/",
"links": [
{
"title": "Karma configuration file reference (port default 9876)",
"url": "https://karma-runner.github.io/latest/config/configuration-file.html",
"kind": "official-docs"
},
{
"title": "Karma source repository (deprecated)",
"url": "https://github.com/karma-runner/karma",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 9877,
"protocol": "tcp",
"service": "x510 — X.510 wrapper protocol",
"oneLiner": "The ITU-T X.510 wrapper protocol for secure directory operations — registered in 2019, seldom seen outside PKI and directory products.",
"whatItIs": "IANA registered 9877/tcp as `x510` in 2019 on behalf of ITU-T Study Group 17, referencing ITU-T X.510 / ISO/IEC 9584-11, \"Protocol specifications for secure operations\" in the OSI Directory series. The wrapper protocol carries authenticated and integrity-protected directory operations, and shows up in X.500-lineage directory and PKI implementations rather than general infrastructure. UDP 9877 is Reserved. On a typical network this port is empty.",
"exposure": {
"verdict": "careful",
"note": "The protocol is designed with its own authentication and integrity protection, but a directory service is still directory data. Expose it only if you have deliberately deployed X.510 and configured its trust anchors."
},
"checkCommand": "nc -vz TARGET 9877",
"links": [
{
"title": "ITU-T Recommendation X.510 — Protocol specifications for secure operations",
"url": "https://www.itu.int/rec/T-REC-X.510/en",
"kind": "spec"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 9878,
"protocol": "udp",
"service": "kca-service — KX509 certificate issuance",
"oneLiner": "KX509, which trades a Kerberos ticket for a short-lived X.509 certificate — UDP only; TCP 9878 is Reserved.",
"whatItIs": "RFC 6717 documents kx509 as deployed in 2012: a client sends a single UDP request containing a Kerberos service ticket and a public key, and a Kerberized certificate authority replies with a matching X.509 certificate. IANA registers UDP 9878 as `kca-service` and explicitly marks TCP 9878 as Reserved, so a TCP listener here is not KX509. Deployment was largely university campuses bridging Kerberos realms to PKI-based services; clients can also find the KCA through `_kca._udp.REALM` SRV records.",
"exposure": {
"verdict": "never",
"note": "This is a certificate authority endpoint. It authenticates callers with Kerberos, but a CA's issuance interface belongs inside the realm it serves, not on a public address."
},
"checkCommand": "nc -vzu TARGET 9878",
"links": [
{
"title": "RFC 6717 — kx509 Kerberized Certificate Issuance Protocol in Use in 2012",
"url": "https://www.rfc-editor.org/rfc/rfc6717.html",
"kind": "spec"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 9898,
"protocol": "both",
"service": "monkeycom",
"oneLiner": "Registered as MonkeyCom with no published specification — in practice an unidentified high port.",
"whatItIs": "IANA lists 9898 on both TCP and UDP as `monkeycom`, registered by an individual with no referenced document, and Nmap carries the same name forward. There is no public protocol description, no maintained implementation to point at, and no reason to expect the registered service on a modern network. A listener on 9898 is almost certainly an unrelated application that chose the number; fingerprint it rather than trusting the registry name.",
"exposure": {
"verdict": "careful",
"note": "The registry name tells you nothing about what is actually answering. Identify the process before making an exposure decision."
},
"checkCommand": "sudo lsof -nP -iTCP:9898 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 9900,
"protocol": "both",
"service": "IUA — ISDN Q.921 User Adaptation",
"oneLiner": "IUA, the SIGTRAN protocol that backhauls ISDN Q.921 signalling over IP — normally SCTP, with TCP and UDP registered too.",
"whatItIs": "RFC 4233 defines IUA, which carries ISDN Q.921-user messages such as Q.931 call signalling between a Signaling Gateway and a Media Gateway Controller over IP. The RFC states the registered port for IUA is 9900, and IANA lists it on SCTP, TCP, and UDP; SCTP is the intended transport, so a TCP listener on 9900 is often something else entirely. You meet IUA inside telecom cores and in softswitch stacks bridging legacy ISDN to VoIP, not on general-purpose servers.",
"exposure": {
"verdict": "never",
"note": "Telephony signalling between gateway elements, with no authentication of its own — it assumes a trusted operator network. Keep it on the signalling network."
},
"checkCommand": "sudo lsof -nP -iTCP:9900 -sTCP:LISTEN",
"links": [
{
"title": "RFC 4233 — ISDN Q.921-User Adaptation Layer",
"url": "https://www.rfc-editor.org/rfc/rfc4233.html",
"kind": "spec"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 9914,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned at IANA with no documented service — the number tells you nothing.",
"whatItIs": "IANA has no registration for 9914, and Nmap's service data lists it as `unknown` at low frequency. No standard protocol, product default, or well-documented malware claims it. If it is open, some locally installed application bound it; the process table is the only reliable source of truth.",
"exposure": {
"verdict": "careful",
"note": "No known service, so no defensible verdict from the number alone. Identify the listener first."
},
"checkCommand": "sudo lsof -nP -iTCP:9914 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 9917,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "No IANA assignment and no established occupant — an application-chosen high port.",
"whatItIs": "There is no IANA service registration for 9917 on TCP or UDP. Nmap records it as `unknown`, seen rarely enough that no pattern emerges. Nothing standard, nothing vendor-default, nothing notable in published malware writeups. Find the owning process rather than reading meaning into the number.",
"exposure": {
"verdict": "careful",
"note": "An unidentified listener deserves scrutiny, not a default allow. Establish what it is, then decide."
},
"checkCommand": "sudo lsof -nP -iTCP:9917 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 9929,
"protocol": "tcp",
"service": "Nping echo server",
"oneLiner": "Nmap's Nping echo server — it shows you exactly how NAT and firewalls rewrote your packets in transit.",
"whatItIs": "Nping's echo mode splits into a server and a client: the client sends crafted probe packets to the server, the server captures them off the wire and sends verbatim copies back over a separate encrypted TCP side channel using the Nping Echo Protocol. Comparing sent and echoed packets makes NAT rewrites, traffic shapers, and firewalls that strip TCP options immediately visible, and distinguishes \"the request was dropped\" from \"the reply was dropped\". The documented default for `--echo-server` is port 9929. It is unassigned at IANA; Nmap's own service database lists it as `nping-echo`, and Nmap's public scanme.nmap.org host has long run one, which is where most people first encounter the port.",
"exposure": {
"verdict": "careful",
"note": "The channel is encrypted and requires a shared passphrase, and running a public echo server is a deliberate choice Nmap supports. It still lets clients drive packet capture on your host, so run it only when you mean to and shut it down afterwards."
},
"checkCommand": "nping --echo-client \"public\" TARGET --tcp -p 80",
"links": [
{
"title": "Nping Reference Guide — Echo Mode (default port 9929)",
"url": "https://nmap.org/book/nping-man.html",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 9941,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "No IANA registration and no well-known service — whatever answers here is somebody's own application.",
"whatItIs": "IANA has no service name assigned to 9941 in the service-name and port-number registry, and Nmap's service database lists it as unknown, open on roughly 0.015% of scanned hosts. That leaves no protocol you can assume from the number alone. In practice a listener on a port like this is an internal agent, a container port mapping, or an app that grabbed a free high number. Fingerprint the service instead of trusting the port.",
"exposure": {
"verdict": "careful",
"note": "An unidentified listener is an unidentified authentication story. Find the process that owns the socket before deciding whether it belongs on a public interface."
},
"checkCommand": "sudo lsof -nP -iTCP:9941 -sTCP:LISTEN",
"links": [
{
"title": "IANA port registry — 9941 (no assignment)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=9941",
"kind": "iana"
},
{
"title": "nmap-services — Nmap's port frequency database",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 9943,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unregistered with IANA; nothing well-known claims it, despite sitting next to Substrate's 9944.",
"whatItIs": "IANA lists no assignment for 9943, and Nmap's service database calls it unknown, open on about 0.03% of scanned hosts. Its neighbour 9944 is the Substrate/Polkadot JSON-RPC default, but that does not extend to 9943 — no published project defaults here. Treat anything listening as a custom or ad-hoc service and identify it by banner rather than by number.",
"exposure": {
"verdict": "careful",
"note": "No registration means no assumptions. Determine what the listener actually is, and whether it authenticates, before exposing it."
},
"checkCommand": "nmap -sV -p 9943 TARGET",
"links": [
{
"title": "IANA port registry — 9943 (no assignment)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=9943",
"kind": "iana"
},
{
"title": "nmap-services — Nmap's port frequency database",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 9944,
"protocol": "tcp",
"service": "Substrate / Polkadot JSON-RPC",
"oneLiner": "A blockchain node built on Parity's Substrate — its JSON-RPC endpoint, serving HTTP and WebSocket on the same port.",
"whatItIs": "Substrate hardcodes RPC_DEFAULT_PORT = 9944 in substrate/client/cli/src/config.rs, so every node built on the framework — Polkadot, Kusama, parachains, and any `--dev` chain a developer starts locally — listens here by default. Older releases split the endpoint (9944 WebSocket, 9933 HTTP); current ones serve both on 9944. The port carries no IANA registration. Seeing it open means someone is running a node, and a JSON-RPC call like system_chain will tell you which network.",
"exposure": {
"verdict": "never",
"note": "Started with --rpc-external or --rpc-methods=unsafe, the endpoint exposes author_* and system_* methods that can insert keys and reconfigure the node. Keep it bound to localhost and put a method-filtering reverse proxy in front if it must be reachable."
},
"checkCommand": "curl -sS -H 'Content-Type: application/json' -d '{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"system_chain\",\"params\":[]}' http://TARGET:9944",
"links": [
{
"title": "polkadot-sdk — substrate/client/cli/src/config.rs (RPC_DEFAULT_PORT)",
"url": "https://github.com/paritytech/polkadot-sdk/blob/master/substrate/client/cli/src/config.rs",
"kind": "github"
},
{
"title": "IANA port registry — 9944 (no assignment)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=9944",
"kind": "iana"
}
]
},
{
"port": 9968,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "No IANA assignment, no well-known service — an unremarkable high port.",
"whatItIs": "IANA has nothing registered on 9968, and Nmap's database lists it as unknown, open on about 0.04% of scanned hosts. The nearest registration in the range is 9966 (odnsp, OKI Data's network setting protocol), which has no bearing on 9968. Anything answering here is application-specific and needs to be identified from its banner.",
"exposure": {
"verdict": "careful",
"note": "Unknown protocol, unknown auth. Identify the owning process before treating the port as safe to expose."
},
"checkCommand": "nmap -sV -p 9968 TARGET",
"links": [
{
"title": "IANA port registry — 9968 (no assignment)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=9968",
"kind": "iana"
},
{
"title": "nmap-services — Nmap's port frequency database",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 9988,
"protocol": "tcp",
"service": "nsesrvr",
"oneLiner": "Registered to a long-discontinued IDS product; in practice a free high port applications squat on.",
"whatItIs": "IANA assigns 9988/tcp the service name nsesrvr, described as the \"Software Essentials Secure HTTP server\" — a component of the SecureNet Pro intrusion-detection product, which has not been a going concern for many years. The matching UDP entry is simply Reserved. Nmap sees 9988/tcp open on roughly 0.015% of hosts, and vanishingly few of those are SecureNet. Read an open 9988 as an unidentified application, not as the registered service.",
"exposure": {
"verdict": "careful",
"note": "The registration tells you nothing about what is actually listening, so it tells you nothing about whether it authenticates. Fingerprint before exposing."
},
"checkCommand": "nmap -sV -p 9988 TARGET",
"links": [
{
"title": "IANA port registry — 9988 (nsesrvr)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=9988",
"kind": "iana"
},
{
"title": "nmap-services — Nmap's port frequency database",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 9998,
"protocol": "both",
"service": "distinct32",
"oneLiner": "Registered to Distinct Corporation's Distinct32 toolkit; almost always something else in practice.",
"whatItIs": "IANA registers 9998 on both TCP and UDP as distinct32, assigned to Distinct Corporation alongside 9999 (distinct) — a pairing from their Windows TCP/IP developer toolkit. You will essentially never meet the registered service. What turns up on 9998 today is an alternate HTTP or admin port an application chose, frequently as the sibling of a service on 9999. Nmap sees it open on about 0.03% of hosts.",
"exposure": {
"verdict": "careful",
"note": "Treat it as an unidentified application port; the registration gives you no security properties to rely on."
},
"checkCommand": "nmap -sV -p 9998 TARGET",
"links": [
{
"title": "IANA port registry — 9998 (distinct32)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=9998",
"kind": "iana"
},
{
"title": "nmap-services — Nmap's port frequency database",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 9999,
"protocol": "both",
"service": "distinct / alternate HTTP",
"oneLiner": "Registered as \"distinct\", but in practice the most common ad-hoc admin or alternate-HTTP port above 9000.",
"whatItIs": "IANA registers 9999 as distinct, assigned to Distinct Corporation, with 9998 as distinct32 — a registration you will not meet in the field. What actually answers on 9999 is an HTTP service someone parked on a memorable number: Nmap's database labels it abyss, the Abyss Web Server's remote management console, and the port is a perennial favourite for debug endpoints, appliance UIs, and second web servers. At roughly 0.44% of scanned hosts, it is by far the busiest port in this range.",
"exposure": {
"verdict": "careful",
"note": "Because it is almost always an ad-hoc HTTP surface rather than a standard protocol, assume it is a management interface until proven otherwise — and a management interface on a public IP is a never."
},
"checkCommand": "curl -sSI http://TARGET:9999/",
"links": [
{
"title": "IANA port registry — 9999 (distinct)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=9999",
"kind": "iana"
},
{
"title": "nmap-services — Nmap's port frequency database",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 10000,
"protocol": "both",
"service": "NDMP / Webmin",
"oneLiner": "Registered to NDMP backup traffic, but on a Linux box it is nearly always Webmin's root-level web console.",
"whatItIs": "IANA assigns 10000 to NDMP, the Network Data Management Protocol that backup software uses to drive NAS filers and tape libraries. The listener you far more often meet is Webmin: its installer writes `listen=10000` into miniserv.conf and serves the administration UI over HTTPS there. Older macOS used 10000 for AirPort admin, which is why Nmap's database carries three names for it at once. At about 1.2% of scanned hosts open, it is one of the most commonly found ports above 9000.",
"exposure": {
"verdict": "never",
"note": "Webmin is a root-equivalent web console with a history of pre-auth remote code execution (CVE-2019-15107 among others), and NDMP's base authentication is cleartext. Put either behind a VPN, not a public IP."
},
"checkCommand": "curl -skI https://TARGET:10000/",
"links": [
{
"title": "webmin/webmin — setup.sh sets the default listen port to 10000",
"url": "https://github.com/webmin/webmin",
"kind": "github"
},
{
"title": "IANA port registry — 10000 (ndmp)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=10000",
"kind": "iana"
}
]
},
{
"port": 10001,
"protocol": "both",
"service": "scp-config / Ubiquiti discovery",
"oneLiner": "Registered as scp-config; on UDP it is Ubiquiti's device-discovery responder, a known amplification reflector.",
"whatItIs": "IANA registers 10001 on both transports as scp-config (\"SCP Configuration\"), which you will rarely encounter. The listener that matters is on UDP: Ubiquiti's discovery protocol, which UniFi and airMAX devices answer with their model, firmware, MAC, and hostname. It is a documented DDoS reflector at roughly 7x amplification, with about 127,000 exposed reflectors counted in 2020. On TCP, 10001 shows up mostly as a raw serial-over-Ethernet port on device servers and as a generic alternate application port; Nmap sees TCP 10001 open on about 0.13% of hosts.",
"exposure": {
"verdict": "never",
"note": "The UDP responder both enumerates your hardware and hands attackers an amplifier — firewall it at the edge. Raw serial redirectors on TCP 10001 typically have no authentication at all."
},
"checkCommand": "sudo nmap -sU -sV -p 10001 TARGET",
"links": [
{
"title": "IANA port registry — 10001 (scp-config)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=10001",
"kind": "iana"
},
{
"title": "AMP-Research — UDP 10001 Ubiquiti discovery amplification",
"url": "https://github.com/Phenomite/AMP-Research/blob/master/Port%2010001%20-%20Ubiquiti/README.md",
"kind": "github"
}
]
},
{
"port": 10002,
"protocol": "both",
"service": "documentum",
"oneLiner": "Registered to the EMC (now OpenText) Documentum Content Server; rare on a scan.",
"whatItIs": "IANA assigns 10002 on TCP and UDP to \"EMC-Documentum Content Server Product\", registered by Documentum's engineering. The port most Documentum deployments actually depend on is 1489 (dmdocbroker, the connection broker), so 10002 is a secondary registration you seldom meet. Nmap sees it open on about 0.04% of hosts, and there is no way to tell from the number whether a real Content Server or an unrelated application is behind it.",
"exposure": {
"verdict": "careful",
"note": "An enterprise content repository plane belongs on an internal network. Identify the listener first; a Documentum tier should not be reachable from the internet."
},
"checkCommand": "nmap -sV -p 10002 TARGET",
"links": [
{
"title": "IANA port registry — 10002 (documentum)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=10002",
"kind": "iana"
},
{
"title": "nmap-services — Nmap's port frequency database",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 10003,
"protocol": "both",
"service": "documentum_s",
"oneLiner": "The secure sibling of 10002 in Documentum's IANA registration; equally rare in the wild.",
"whatItIs": "IANA carries 10003 as documentum_s (with documentum-s as the well-formed replacement name), the secure counterpart to 10002 for the EMC Documentum Content Server product. Like 10002 it is a registration far more often cited than observed — Nmap sees it open on about 0.02% of scanned hosts. Documentum clients normally reach a repository through the connection broker on 1489.",
"exposure": {
"verdict": "careful",
"note": "Content-repository ports are internal infrastructure. Confirm what is actually listening rather than relying on the registered name."
},
"checkCommand": "nmap -sV -p 10003 TARGET",
"links": [
{
"title": "IANA port registry — 10003 (documentum_s)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=10003",
"kind": "iana"
},
{
"title": "nmap-services — Nmap's port frequency database",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 10004,
"protocol": "tcp",
"service": "emcrmirccd",
"oneLiner": "Registered to the EMC Replication Manager client agent; the UDP side is Reserved.",
"whatItIs": "IANA assigns 10004/tcp to emcrmirccd, the EMC Replication Manager Client — the agent installed on application hosts so the Replication Manager server can coordinate array-based snapshots and clones. The corresponding UDP entry is Reserved rather than assigned. It is a storage-management agent, so it belongs to a managed data-center estate; Nmap sees the port open on about 0.03% of scanned hosts.",
"exposure": {
"verdict": "never",
"note": "A storage-replication control agent can quiesce applications and manipulate array copies. It should only be reachable from its management server on an internal network."
},
"checkCommand": "nc -vz TARGET 10004",
"links": [
{
"title": "IANA port registry — 10004 (emcrmirccd)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=10004",
"kind": "iana"
},
{
"title": "nmap-services — Nmap's port frequency database",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 10009,
"protocol": "both",
"service": "swdtp-sv / lnd gRPC",
"oneLiner": "Registered to Fujitsu Systemwalker, but today it is most often lnd's Lightning Network gRPC API.",
"whatItIs": "IANA assigns 10009 to swdtp-sv, the server side of Fujitsu's Systemwalker Desktop Patrol asset-management product. The listener you are more likely to meet is lnd, the Lightning Network daemon, whose shipped sample configuration sets `rpclisten=localhost:10009` for its gRPC interface (its REST API sits on 8080). Nmap sees 10009/tcp open on about 0.02% of hosts. A TLS handshake that presents a self-signed lnd certificate is the giveaway.",
"exposure": {
"verdict": "never",
"note": "lnd's gRPC controls a Bitcoin wallet and its channel funds. It is macaroon-authenticated over TLS, but macaroons leak and there is no reason to expose it — keep it on localhost or behind a VPN."
},
"checkCommand": "nc -vz TARGET 10009",
"links": [
{
"title": "lnd — sample-lnd.conf (rpclisten default localhost:10009)",
"url": "https://github.com/lightningnetwork/lnd/blob/master/sample-lnd.conf",
"kind": "github"
},
{
"title": "IANA port registry — 10009 (swdtp-sv)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=10009",
"kind": "iana"
}
]
},
{
"port": 10010,
"protocol": "tcp",
"service": "rxapi",
"oneLiner": "ooRexx's rxapi daemon — a local IPC broker that starts itself and quietly holds a socket open.",
"whatItIs": "IANA assigns 10010/tcp to rxapi, the Open Object Rexx API daemon. It brokers queues, the macrospace, and registered external functions for ooRexx programs, and the interpreter starts it automatically the first time a script needs it — which is why it appears on machines nobody thinks of as ooRexx hosts. The matching UDP entry is Reserved. Nmap sees the port open on about 0.29% of scanned hosts, unusually high for a niche runtime service.",
"exposure": {
"verdict": "never",
"note": "rxapi is designed as a local IPC broker between processes on one machine, not as a network service. If it is answering from off-box, bind it back to the loopback interface."
},
"checkCommand": "sudo lsof -nP -iTCP:10010 -sTCP:LISTEN",
"links": [
{
"title": "Open Object Rexx (ooRexx) — project site",
"url": "https://www.oorexx.org/",
"kind": "official-docs"
},
{
"title": "IANA port registry — 10010 (rxapi)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=10010",
"kind": "iana"
}
]
},
{
"port": 10012,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "No IANA registration; a plain unclaimed high port.",
"whatItIs": "IANA has no assignment for 10012, and Nmap's service database lists it as unknown, open on about 0.04% of scanned hosts. Nothing widely deployed defaults here. A listener is an application, agent, or published container port that took the next free number, so identify it by probing rather than by the number.",
"exposure": {
"verdict": "careful",
"note": "No registration, no assumed protocol, no assumed authentication. Establish what owns the socket before exposing it."
},
"checkCommand": "sudo lsof -nP -iTCP:10012 -sTCP:LISTEN",
"links": [
{
"title": "IANA port registry — 10012 (no assignment)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=10012",
"kind": "iana"
},
{
"title": "nmap-services — Nmap's port frequency database",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 10024,
"protocol": "tcp",
"service": "amavisd-new content filter",
"oneLiner": "The SMTP port amavis listens on so the MTA can hand mail over for virus and spam scanning.",
"whatItIs": "Not registered with IANA, but a de-facto standard: amavis's own Postfix documentation sets `$inet_socket_port = 10024` and has Postfix hand mail off with `content_filter=amavisfeed:[127.0.0.1]:10024`. Connecting gets you an ESMTP greeting — \"220 [127.0.0.1] ESMTP amavisd-new service ready\" — so on a scan it reads as a mail server. It always pairs with 10025, the reinjection port amavis sends scanned mail back to.",
"exposure": {
"verdict": "never",
"note": "This is an unauthenticated SMTP sink that accepts mail for onward delivery. Reachable from outside, it is an open relay into your own queue. The documented configuration binds it to 127.0.0.1."
},
"checkCommand": "printf 'QUIT\\r\\n' | nc -w 3 127.0.0.1 10024",
"links": [
{
"title": "amavis — README.postfix ($inet_socket_port = 10024)",
"url": "https://www.amavis.org/README.postfix.html",
"kind": "official-docs"
},
{
"title": "IANA port registry — 10024 (no assignment)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=10024",
"kind": "iana"
}
]
},
{
"port": 10025,
"protocol": "tcp",
"service": "MTA reinjection (post-filter SMTP)",
"oneLiner": "The stripped-down SMTP listener a content filter reinjects already-scanned mail into.",
"whatItIs": "Also unregistered with IANA. In the standard amavis setup, master.cf runs a second Postfix smtpd on 127.0.0.1:10025 with most checks disabled, and amavis returns clean mail to it via `$forward_method='smtp:[127.0.0.1]:10025'`. Postfix's own FILTER_README documents the same sandwich with a 10025/10026 pair. A probe sees an ordinary Postfix ESMTP banner, which makes the port easy to mistake for a legitimate public MTA.",
"exposure": {
"verdict": "never",
"note": "This listener deliberately runs with relay restrictions and receive overrides removed so that filtered mail passes unchallenged. Reachable from the internet, it is a literal open relay — bind it to the loopback interface."
},
"checkCommand": "printf 'QUIT\\r\\n' | nc -w 3 127.0.0.1 10025",
"links": [
{
"title": "Postfix — FILTER_README (SMTP-based content filter port sandwich)",
"url": "https://www.postfix.org/FILTER_README.html",
"kind": "official-docs"
},
{
"title": "amavis — README.postfix (reinjection on 127.0.0.1:10025)",
"url": "https://www.amavis.org/README.postfix.html",
"kind": "official-docs"
}
]
},
{
"port": 10082,
"protocol": "tcp",
"service": "amandaidx (Amanda index server)",
"oneLiner": "The Amanda backup server's index service, used by amrecover to browse what was backed up.",
"whatItIs": "IANA registers 10080 as amanda but not 10082; the number comes from Amanda's own source, which sets INDEX_PORT=10082 and TAPE_PORT=10083. The index server lets an amrecover client list the contents of past backups and select files, then 10083 (amidxtape) streams the data back off the media. You find it on Amanda backup servers, normally alongside 10080. Nmap sees it open on about 0.02% of scanned hosts.",
"exposure": {
"verdict": "never",
"note": "Amanda's recovery services authenticate largely by host and, once reached, expose a catalog of everything backed up plus the ability to restore from it. Keep them on a dedicated backup network."
},
"checkCommand": "nc -vz TARGET 10082",
"links": [
{
"title": "zmanda/amanda — INDEX_PORT=10082, TAPE_PORT=10083",
"url": "https://github.com/zmanda/amanda/blob/master/client-src/patch-system.sh",
"kind": "github"
},
{
"title": "IANA port registry — 10080 (amanda)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=10080",
"kind": "iana"
}
]
},
{
"port": 10180,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unregistered with IANA and unclaimed by any widely deployed software.",
"whatItIs": "There is no IANA assignment for 10180, and Nmap's service database lists it as unknown, open on roughly 0.02% of scanned hosts. No mainstream project defaults to it. That makes the port itself uninformative: a listener here has to be identified from its banner or from the process that owns the socket.",
"exposure": {
"verdict": "careful",
"note": "Unknown service, unknown authentication. Work out what it is locally before deciding whether it should face a network at all."
},
"checkCommand": "sudo lsof -nP -iTCP:10180 -sTCP:LISTEN",
"links": [
{
"title": "IANA port registry — 10180 (no assignment)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=10180",
"kind": "iana"
},
{
"title": "nmap-services — Nmap's port frequency database",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 10215,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "No IANA registration and no known default service.",
"whatItIs": "IANA lists nothing for 10215, and Nmap's database records it as unknown, open on about 0.02% of scanned hosts. No published software claims it as a default. Whatever answers is a custom application or a mapped container port, and its protocol has to be determined by probing.",
"exposure": {
"verdict": "careful",
"note": "The number carries no information about the service, so it carries none about its security. Identify the listener first."
},
"checkCommand": "nmap -sV -p 10215 TARGET",
"links": [
{
"title": "IANA port registry — 10215 (no assignment)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=10215",
"kind": "iana"
},
{
"title": "nmap-services — Nmap's port frequency database",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 10243,
"protocol": "tcp",
"service": "Windows Media Player Network Sharing (HTTP)",
"oneLiner": "A Windows machine with media streaming enabled — HTTP.sys serving the WMPNSSv4 endpoint.",
"whatItIs": "Not registered with IANA, but on Windows it is entirely predictable: the Windows Media Player Network Sharing Service reserves the URL http://+:10243/WMPNSSv4/ with HTTP.sys under the NT SERVICE\\WMPNetworkSvc account, so the port opens whenever media streaming or DLNA sharing is turned on — often by a setup wizard rather than a deliberate choice. It is the HTTP half of the UPnP AV media server, advertised over SSDP on UDP 1900. Nmap sees it open on about 0.07% of scanned hosts, essentially all Windows.",
"exposure": {
"verdict": "never",
"note": "A LAN media-sharing surface with no business on a public IP: it exposes the library to anyone who can reach it and puts HTTP.sys, historically a source of remote vulnerabilities, on the wire. Turn media streaming off if you are not using it."
},
"checkCommand": "curl -sSI http://TARGET:10243/WMPNSSv4/",
"links": [
{
"title": "IANA port registry — 10243 (no assignment)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=10243",
"kind": "iana"
},
{
"title": "nmap-services — Nmap's port frequency database",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 10566,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "No IANA assignment; nothing well-known listens here by default.",
"whatItIs": "IANA has no entry for 10566, and Nmap's service database lists it as unknown, open on about 0.04% of scanned hosts. No widely deployed project uses it as a default. Treat an open 10566 as an unidentified application port and fingerprint it directly.",
"exposure": {
"verdict": "careful",
"note": "An unidentified listener should not be assumed safe. Find the owning process, then decide."
},
"checkCommand": "nmap -sV -p 10566 TARGET",
"links": [
{
"title": "IANA port registry — 10566 (no assignment)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=10566",
"kind": "iana"
},
{
"title": "nmap-services — Nmap's port frequency database",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 10616,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unregistered with IANA and not the default for any well-known software.",
"whatItIs": "IANA lists no service for 10616, and Nmap's database calls it unknown, open on about 0.04% of scanned hosts. There is no protocol the number implies. Anything answering is application-specific, so identify it from the process or the banner rather than from a port list.",
"exposure": {
"verdict": "careful",
"note": "No registration means no assumptions about what the service does or whether it authenticates. Identify it before exposing it."
},
"checkCommand": "sudo lsof -nP -iTCP:10616 -sTCP:LISTEN",
"links": [
{
"title": "IANA port registry — 10616 (no assignment)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=10616",
"kind": "iana"
},
{
"title": "nmap-services — Nmap's port frequency database",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 10617,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "IANA leaves 10617 unassigned and no convention has claimed it; a listener here was configured on purpose.",
"whatItIs": "IANA has nothing registered on 10617 — the registry jumps from `serverdocs` (10548, Apple Document Sharing) straight to `printopia` (10631), leaving this whole stretch empty. Nmap's service database also carries it as `unknown`, seen on roughly 0.04% of scanned hosts, which is background noise rather than a fingerprint of any product. It also sits well below the Linux ephemeral range (32768 and up), so a process bound here was told to bind here by a config file or a container port mapping. Identify it by its banner, not by the number.",
"exposure": {
"verdict": "careful",
"note": "An unregistered high port tells you nothing about what is behind it. Fingerprint the listener before deciding whether it belongs on a public interface."
},
"checkCommand": "nmap -Pn -sV -p 10617 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 10621,
"protocol": "both",
"service": "Unassigned",
"oneLiner": "Unassigned by IANA, no known squatter — whatever answers here is site-local.",
"whatItIs": "10621 falls inside the unassigned gap between Apple's `serverdocs` at 10548 and `printopia` at 10631, and Nmap's service list records it as `unknown` on both TCP and UDP. There is no product convention, malware family, or scanner signature publicly tied to this number. In practice ports in the 10000-11000 band get picked by hand for internal services because the famous neighbours — Webmin and NDMP on 10000, Zabbix on 10050/10051 — made the range familiar to admins. Treat the number as meaningless and read the banner.",
"exposure": {
"verdict": "careful",
"note": "Unknown service, unknown auth. Check what is actually listening (`ss -ltnp` on the host) before you open a firewall rule for it."
},
"checkCommand": "nmap -Pn -sV -p 10621 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 10626,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "No IANA assignment and no established use; the honest answer is that nobody owns this port.",
"whatItIs": "IANA lists 10626 as unassigned, and Nmap's `nmap-services` — which is built from real internet scan data — has it as `unknown` at a very low hit rate. No documented application, appliance, or backdoor defaults to it. If you found it on a scan, the source is a locally chosen port: an application config, a Docker `-p` mapping, or a service that increments off a base port and landed here.",
"exposure": {
"verdict": "careful",
"note": "Nothing about the number makes it safe or unsafe. The verdict belongs to whatever service you find bound to it."
},
"checkCommand": "nmap -Pn -sV -p 10626 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 10628,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned by IANA; Nmap sees marginally more UDP than TCP activity here, and neither maps to a known service.",
"whatItIs": "IANA has no registration for 10628 on any transport. Nmap's service frequencies list it as `unknown` for both TCP and UDP, with the UDP figure slightly the higher of the two — a hint that some of what touches this number is scan or backscatter traffic rather than a TCP service anyone runs. No public product documentation defaults to it. A TCP listener here is a deliberate local choice.",
"exposure": {
"verdict": "careful",
"note": "Identify the process first. An unregistered port is often where someone parked an admin or debug endpoint precisely because it looked anonymous."
},
"checkCommand": "nmap -Pn -sV -p 10628 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 10629,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "The last unassigned number before Printopia's 10631 — no registration, no convention.",
"whatItIs": "10629 sits two below `printopia` (10631, Printopia Serve — the Mac AirPrint bridge), which is the next assignment IANA makes after 10548. The port itself has no registration and Nmap records it as `unknown`. Adjacency to a registered port means nothing: products claim single numbers, not neighbourhoods, so being next door to Printopia does not imply a Printopia install. Fingerprint the service to learn anything real.",
"exposure": {
"verdict": "careful",
"note": "Unknown listener. Decide exposure from the service you identify, not from the port number."
},
"checkCommand": "nmap -Pn -sV -p 10629 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 10778,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned; IANA's registry runs empty from 10631 to 10800, and 10778 is in that gap.",
"whatItIs": "Between `printopia` (10631) and `gap` (10800, Gestor de Acaparamiento para Pocket PCs) IANA assigns nothing, and 10778 is inside that empty stretch. Nmap's scan-derived service list carries it as `unknown` at a very low frequency. There is no documented application default, no known trojan, and no scanner signature attached to it. Anything answering is a locally configured service.",
"exposure": {
"verdict": "careful",
"note": "No registration means no assumptions. Grab the banner and judge the actual protocol."
},
"checkCommand": "nmap -Pn -sV -p 10778 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 11110,
"protocol": "tcp",
"service": "sgi-soap (DMF SOAP)",
"oneLiner": "SGI's Data Migration Facility SOAP interface — a remote-management API for a tape/HSM archive.",
"whatItIs": "IANA registered 11110/TCP as `sgi-soap` to SGI in January 2013, described as \"Data migration facility (DMF) SOAP is a web server protocol to support remote access to DMF\". DMF is SGI's hierarchical storage manager, which migrates files between disk and tape or object storage on large IRIX and Linux compute sites; the SOAP endpoint exists so management tooling can drive it over the network. SGI was acquired by HPE in 2016 and the product line continued as HPE Data Management Framework, so a listener here means a research or HPC storage cluster, not a general-purpose server. The UDP side of 11110 is marked Reserved.",
"exposure": {
"verdict": "never",
"note": "This is a storage-administration API for an archive tier. Keep it on the management network; there is no reason for it to face the internet."
},
"checkCommand": "curl -sv --max-time 5 http://TARGET:11110/",
"links": [
{
"title": "IANA port registry — 11110 (sgi-soap)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=11110",
"kind": "iana"
}
]
},
{
"port": 11111,
"protocol": "both",
"service": "vce (IANA) / ricci in practice",
"oneLiner": "Registered to the Viral Computing Environment; in real deployments it is Red Hat's `ricci` cluster agent, or a hand-picked repdigit port.",
"whatItIs": "IANA assigns 11111 on TCP and UDP to `vce`, the Viral Computing Environment, an old distributed-computing research project of Fred Cohen's that you will not meet on a modern network. It is widely reported as the port of `ricci`, the node-side agent of Red Hat's long-retired `luci`/`ricci` cluster management stack, which the `luci` console used to manage cluster nodes; no current vendor documentation covers it, so treat that as received wisdom rather than a specification. Beyond that, 11111 is one of the repdigit numbers people reach for when they need an arbitrary port for a proxy, a test listener, or a container mapping, so a match here often means nothing more than someone typed five ones.",
"exposure": {
"verdict": "never",
"note": "If it is `ricci`, it is a node-configuration channel for a cluster — management network only. If it is an ad-hoc listener, you still do not know what it is until you fingerprint it."
},
"checkCommand": "nmap -Pn -sV -p 11111 TARGET",
"links": [
{
"title": "IANA port registry — 11111 (vce)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=11111",
"kind": "iana"
}
]
},
{
"port": 11967,
"protocol": "both",
"service": "sysinfo-sp",
"oneLiner": "\"SysInfo Service Protocol\", registered in 2003 and essentially never seen since.",
"whatItIs": "IANA holds 11967 on TCP and UDP as `sysinfo-sp`, \"SysInfo Service Protocol\", registered in March 2003 by Mike Cooper. The registry entry is all there is: no public specification, no maintained implementation, and no vendor documentation that describes the wire format. Nmap carries the name from IANA but records essentially no observed traffic. If something is listening on 11967 on your network, assume it is an unrelated local service that picked the number, not SysInfo.",
"exposure": {
"verdict": "careful",
"note": "An effectively dead registration gives you no security properties to reason about. Identify the real listener before exposing it."
},
"checkCommand": "nmap -Pn -sV -p 11967 TARGET",
"links": [
{
"title": "IANA port registry — 11967 (sysinfo-sp)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=11967",
"kind": "iana"
}
]
},
{
"port": 12000,
"protocol": "both",
"service": "entextxid (IBM Enterprise Extender)",
"oneLiner": "IBM Enterprise Extender's SNA XID exchange — the first of the 12000-12004 block that carries SNA traffic over IP.",
"whatItIs": "IANA registers 12000 as `entextxid`, \"IBM Enterprise Extender SNA XID Exchange\", the head of a five-port block: 12001 `entextnetwk`, 12002 `entexthigh`, 12003 `entextmed` and 12004 `entextlow` carry the four SNA classes of service. Enterprise Extender tunnels SNA/APPN over UDP so mainframes and their peers keep talking after the SNA network itself is retired, which is why the live traffic is UDP on 12000-12004 rather than a TCP listener. Nmap's database also carries the legacy alias `cce4x` for ClearCommerce Engine 4.x, a long-defunct payments product. Separately, 12000 is a round number that developers pick constantly for application and API listeners, so on a non-mainframe host it is far more likely to be someone's app server than SNA.",
"exposure": {
"verdict": "never",
"note": "Enterprise Extender is a datacenter-to-datacenter transport for mainframe traffic and belongs on private links or a VPN. If instead it is an app server that happened to pick 12000, judge that app on its own terms."
},
"checkCommand": "nmap -Pn -sV -p 12000 TARGET",
"links": [
{
"title": "IANA port registry — 12000-12004 (entextxid and the SNA COS ports)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=entext",
"kind": "iana"
}
]
},
{
"port": 12174,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned by IANA — the registry has `hivep` at 12172 and then nothing until 12300.",
"whatItIs": "12174 has no IANA registration; the nearest assignments are `hivep` (12172, HiveP) below it and `linogridengine` (12300, LinoGrid Engine) above. Nmap records the port as `unknown` with a very low observed frequency. No documented product default and no known malware family uses it, so a listener here is a locally chosen port and the only way to identify it is to look at what answers.",
"exposure": {
"verdict": "careful",
"note": "Unregistered and unfingerprinted. Determine the service before treating the port as safe to expose."
},
"checkCommand": "nmap -Pn -sV -p 12174 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 12265,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "No IANA assignment and no established convention; the port number tells you nothing.",
"whatItIs": "IANA leaves 12265 unassigned, inside the same empty stretch between 12172 and 12300 that swallows most of the 12200s. Nmap's scan-derived list has it as `unknown` at a low rate. There is no public documentation of any application, appliance, or backdoor defaulting here. Anything you find is a service someone configured onto this number by hand or via a container port mapping.",
"exposure": {
"verdict": "careful",
"note": "The exposure verdict belongs to the service you identify, not to the number. Fingerprint it first."
},
"checkCommand": "nmap -Pn -sV -p 12265 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 12345,
"protocol": "tcp",
"service": "NetBus (in practice) / italk (IANA)",
"oneLiner": "The most-typed port number there is: registered to italk, famous as the NetBus backdoor, and used daily as a throwaway test port.",
"whatItIs": "IANA registers 12345 to `italk`, the Italk Chat System, which nobody runs. The number's reputation comes from NetBus, a Windows remote-control backdoor from 1998 that listened on 12345 with a second channel on 12346, and which is well enough documented that Nmap ships a `netbus-info` NSE script and Nmap's service table names the port `netbus`. Trend Micro's OfficeScan agent also used 12345, which produced a long history of false-positive backdoor alerts on corporate desktops. In modern practice most sightings are neither: 12345 is the reflexive choice for a scratch listener, a debug server, or a container port mapping.",
"exposure": {
"verdict": "never",
"note": "Either it is a remote-control backdoor, or it is a hastily configured test service that nobody hardened. Neither belongs on a public IP."
},
"checkCommand": "nmap -Pn -p 12345 --script netbus-info TARGET",
"links": [
{
"title": "Nmap NSE — netbus-info",
"url": "https://nmap.org/nsedoc/scripts/netbus-info.html",
"kind": "official-docs"
},
{
"title": "IANA port registry — 12345 (italk)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=12345",
"kind": "iana"
}
]
},
{
"port": 13456,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned by IANA; like 12345 it is a keyboard-run number, which is the only reason it ever shows up.",
"whatItIs": "IANA has no registration for 13456 — the registry goes from `doip-data` (13400, ISO 13400 Diagnostics over IP for vehicles) to `bprd` (13720, Veritas NetBackup) with nothing in between. Nmap lists the port as `unknown`. Its only claim to appearing at all is that consecutive digits are easy to type, so it turns up as a scratch or test listener in the same way 12345 does. There is no documented product or malware default.",
"exposure": {
"verdict": "careful",
"note": "A memorable number usually means a hand-started service rather than a managed one. Find out what it is before leaving it reachable."
},
"checkCommand": "nmap -Pn -sV -p 13456 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 13722,
"protocol": "both",
"service": "bpjava-msvc (NetBackup)",
"oneLiner": "Veritas NetBackup's Java administration service — the port the NetBackup admin console connects to.",
"whatItIs": "IANA registers 13722 as `bpjava-msvc`, \"BP Java MSVC Protocol\", part of the Veritas NetBackup block that also holds `bprd` (13720), `bpdbm` (13721), `vnetd` (13724), `bpcd` (13782) and `vopied` (13783). `bpjava-msvc` is the service the NetBackup Java administration console and remote-admin clients authenticate to, after which it hands the session to a per-user application service on the master or media server. Seeing it means you have found enterprise backup infrastructure, which is high-value: a backup master has credentialed reach into every client it protects.",
"exposure": {
"verdict": "never",
"note": "This is the administration plane of a backup system with agents on every server. Restrict it to the backup management network."
},
"checkCommand": "nmap -Pn -sV -p 13722 TARGET",
"links": [
{
"title": "IANA port registry — 13722 (bpjava-msvc)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=13722",
"kind": "iana"
}
]
},
{
"port": 13782,
"protocol": "both",
"service": "bpcd (NetBackup client daemon)",
"oneLiner": "The NetBackup client daemon — the agent on every protected host that the backup master tells to run a backup or restore.",
"whatItIs": "IANA registers 13782 as `bpcd`, \"VERITAS NetBackup\". `bpcd` runs on NetBackup clients and accepts connections from the master or media server to start backups, restores and file listings, which means it has privileged access to the client's filesystem by design. It is the single most commonly seen NetBackup port on a scan because it is installed on every protected machine rather than just the servers, and its long history of remote buffer-overflow advisories made it a standing item on internal pentest checklists.",
"exposure": {
"verdict": "never",
"note": "A daemon that reads and writes arbitrary files on behalf of a remote server should only accept connections from your backup servers. Restrict by source address, never expose it externally."
},
"checkCommand": "nmap -Pn -sV -p 13782 TARGET",
"links": [
{
"title": "IANA port registry — 13782 (bpcd)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=13782",
"kind": "iana"
}
]
},
{
"port": 13783,
"protocol": "both",
"service": "vopied (NetBackup)",
"oneLiner": "NetBackup's VOPIE one-time-password authentication daemon, sitting directly above `bpcd`.",
"whatItIs": "IANA registers 13783 as `vopied`, the \"VOPIED Protocol\", assigned alongside the rest of the Veritas NetBackup ports. VOPIE is NetBackup's legacy challenge-response scheme for authenticating a server to a client, a variation on the S/KEY style of one-time password, and `vopied` is the daemon that answers those exchanges on the client. It is almost always found next to `bpcd` on 13782 on the same host, because both ship with the NetBackup client. Newer NetBackup deployments moved authentication onto the `vnetd` (13724) and PBX paths, so a live `vopied` usually indicates an older client generation.",
"exposure": {
"verdict": "never",
"note": "An authentication daemon for backup agents, and a legacy one at that. Backup management network only."
},
"checkCommand": "nmap -Pn -sV -p 13783 TARGET",
"links": [
{
"title": "IANA port registry — 13783 (vopied)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=13783",
"kind": "iana"
}
]
},
{
"port": 14000,
"protocol": "tcp",
"service": "Hadoop HttpFS (in practice) / scotty-ft (IANA)",
"oneLiner": "Registered to a SCOTTY file transfer nobody runs; in practice it is Hadoop HttpFS, a REST gateway into HDFS.",
"whatItIs": "IANA holds 14000 as `scotty-ft`, \"SCOTTY High-Speed Filetransfer\", registered in 2007. What you actually meet on this port is Apache Hadoop's HttpFS: a Tomcat-hosted server that exposes the full WebHDFS REST API — read and write — so clients outside the cluster can reach HDFS through one host instead of talking to every DataNode. Its documented default is `http://httpfs-host:14000/webhdfs/v1/...`, and it is deployed as the file-access front door for clusters behind a firewall. On a Hadoop node, 14000 means HDFS is reachable over HTTP.",
"exposure": {
"verdict": "never",
"note": "HttpFS is filesystem access to the cluster. Without Kerberos it accepts a `user.name` query parameter as identity, which is not authentication. Keep it internal and enable secure mode."
},
"checkCommand": "curl -s -o /dev/null -w '%{http_code}\\n' \"http://TARGET:14000/webhdfs/v1/?op=LISTSTATUS\"",
"links": [
{
"title": "Apache Hadoop — HttpFS",
"url": "https://hadoop.apache.org/docs/stable/hadoop-hdfs-httpfs/index.html",
"kind": "official-docs"
},
{
"title": "IANA port registry — 14000 (scotty-ft)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=14000",
"kind": "iana"
}
]
},
{
"port": 14238,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned by IANA, in a gap flanked by two Veritas cluster registrations.",
"whatItIs": "IANA has no assignment for 14238. The neighbours are `vad` (14154, Veritas Application Director) below and `cps` (14250, the VCS Coordination Point / fencing server) above, but neither implies anything about 14238 itself — vendors register individual numbers, not ranges. Nmap records the port as `unknown` at a low observed frequency. A listener here is site-local configuration and must be fingerprinted to be identified.",
"exposure": {
"verdict": "careful",
"note": "No registration, no convention. Judge it by the service you find, and check whether it was meant to be bound to localhost."
},
"checkCommand": "nmap -Pn -sV -p 14238 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 14441,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned; IANA registers nothing between 14414 and 14500, and 14441 sits in that hole.",
"whatItIs": "IANA leaves 14441 unassigned — the surrounding registrations are `ca-web-update` (14414, CA eTrust Web Update Service) and `xpra` (14500, the xpra network protocol). Nmap's service table lists it as `unknown`. No published product default, malware family, or scanner signature is tied to it. Note that 14441 and 14442 are frequently seen together, which usually means one application claimed a small consecutive block for a control and a data channel rather than that either number is registered.",
"exposure": {
"verdict": "careful",
"note": "Unknown listener. If it appears alongside 14442, identify both — a paired control/data channel is often an internal-only protocol."
},
"checkCommand": "nmap -Pn -sV -p 14441-14442 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 14442,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Also unassigned, and usually found as the second half of a pair with 14441.",
"whatItIs": "Like its neighbour, 14442 has no IANA registration; the registry jumps from `ca-web-update` at 14414 to `xpra` at 14500. Nmap carries it as `unknown`. What makes it worth a note is the pairing: applications that need two ports commonly grab consecutive numbers, so 14441/14442 open together points at one program with two listeners rather than two unrelated services. The identity still has to come from a banner grab or from `ss -ltnp` on the host.",
"exposure": {
"verdict": "careful",
"note": "No registration to reason from. Find the owning process; consecutive-port protocols are usually designed for a trusted network."
},
"checkCommand": "nmap -Pn -sV -p 14442 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 15000,
"protocol": "tcp",
"service": "Envoy admin (in practice) / hydap (IANA)",
"oneLiner": "Registered to HYPACK survey software; on any Kubernetes node it is the Envoy sidecar's admin interface.",
"whatItIs": "IANA assigns 15000 to `hydap`, \"Hypack Data Aquisition\", used by HYPACK's hydrographic survey packages. Far more common today is Envoy: Istio documents 15000 as the \"Envoy admin port (commands/diagnostics)\" on every injected sidecar, alongside 15001 outbound, 15006 inbound, 15021 health and 15090 telemetry. The admin interface is a plain HTTP endpoint that dumps the proxy's full configuration and stats and can change log levels or drain listeners, which is why Istio marks it pod-internal only. Outside a mesh, 15000 is also a popular round number for application listeners.",
"exposure": {
"verdict": "never",
"note": "Envoy's own documentation warns the admin endpoint must not be exposed: `/config_dump` can reveal secrets and its handlers can modify or shut down the proxy. Bind it to localhost."
},
"checkCommand": "curl -s http://TARGET:15000/server_info",
"links": [
{
"title": "Envoy — administration interface",
"url": "https://www.envoyproxy.io/docs/envoy/latest/operations/admin",
"kind": "official-docs"
},
{
"title": "Istio — ports used by Istio",
"url": "https://istio.io/latest/docs/ops/deployment/application-requirements/",
"kind": "official-docs"
},
{
"title": "IANA port registry — 15000 (hydap)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=15000",
"kind": "iana"
}
]
},
{
"port": 15002,
"protocol": "tcp",
"service": "onep-tls (Cisco) / Istio failure detection",
"oneLiner": "Cisco's Open Network Environment TLS port by registration; inside a service mesh it is the sidecar's failure-detection listener.",
"whatItIs": "IANA registered 15002/TCP in January 2014 to Cisco as `onep-tls`, \"Open Network Environment TLS\" — the TLS transport for onePK, Cisco's programmability SDK for IOS/IOS-XE, which has since been superseded by NETCONF/RESTCONF and gNMI and is no longer a live product. The UDP side is Reserved. The number's current relevance is Istio, which lists 15002 among its sidecar ports as the \"listen port for failure detection\" and marks it pod-internal only, sitting in the same 15000-15099 block as the Envoy admin (15000), outbound (15001) and inbound (15006) listeners.",
"exposure": {
"verdict": "never",
"note": "Both readings are internal control paths — a network-device programmability channel or a mesh-internal probe port. Neither should be reachable from outside the pod or the management network."
},
"checkCommand": "nmap -Pn -sV -p 15002 TARGET",
"links": [
{
"title": "Istio — ports used by Istio",
"url": "https://istio.io/latest/docs/ops/deployment/application-requirements/",
"kind": "official-docs"
},
{
"title": "IANA port registry — 15002 (onep-tls)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=15002",
"kind": "iana"
}
]
},
{
"port": 15003,
"protocol": "both",
"service": "PBS/TORQUE pbs_resmom",
"oneLiner": "The resource-manager port of a PBS or TORQUE compute node's MOM daemon.",
"whatItIs": "TORQUE and its PBS ancestors hard-code a block of ports for the batch system: 15001 for pbs_server, 15002 for the MOM's server channel, 15003 for MOM resource-management requests (PBS_MANAGER_SERVICE_PORT, service name pbs_resmom), and 15004 for the scheduler. A listener on 15003 means the machine is a compute node in an HPC cluster running pbs_mom. IANA has never assigned 15003, so the convention lives in the source and in the /etc/services block the packages install.",
"exposure": {
"verdict": "never",
"note": "Batch-system RPC between nodes that trust each other on a private cluster network; there is no authentication story that makes it safe to reach from the internet."
},
"checkCommand": "nc -vz -w 3 TARGET 15003",
"links": [
{
"title": "TORQUE — pbs_ifl.h (PBS_MANAGER_SERVICE_PORT 15003)",
"url": "https://github.com/adaptivecomputing/torque",
"kind": "github"
},
{
"title": "OpenPBS source repository",
"url": "https://github.com/openpbs/openpbs",
"kind": "github"
}
]
},
{
"port": 15004,
"protocol": "both",
"service": "PBS/TORQUE pbs_sched",
"oneLiner": "Where a PBS or TORQUE batch server contacts its scheduler.",
"whatItIs": "pbs_server looks for the scheduler on the loopback address at port 15004 unless started with -S; pbs_sched binds it. It completes the 15001-15005 block that TORQUE and PBS use (server, MOM, MOM resource manager, scheduler, trqauthd). Seeing it open means an HPC head node. The port is unassigned at IANA — the number comes from the PBS source, not a registration.",
"exposure": {
"verdict": "never",
"note": "Normally a loopback-only conversation between two daemons on the head node; a scheduler port answering from outside the cluster is a misconfiguration."
},
"checkCommand": "sudo lsof -nP -iTCP:15004 -sTCP:LISTEN",
"links": [
{
"title": "TORQUE — pbs_server(8) man page (scheduler on port 15004)",
"url": "https://github.com/adaptivecomputing/torque",
"kind": "github"
},
{
"title": "OpenPBS source repository",
"url": "https://github.com/openpbs/openpbs",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 15660,
"protocol": "tcp",
"service": "Backup Express restore server",
"oneLiner": "IANA-registered to Syncsort/Catalogic Backup Express as its restore server port.",
"whatItIs": "IANA assigns 15660 as bex-xr, \"Backup Express Restore Server\", to Catalogic Software (the product line that began as Syncsort Backup Express and is now DPX). It appears on hosts running that backup agent or server, alongside the product's other ports. Outside that product the number has no widely documented use, and it is rare on internet-wide scans.",
"exposure": {
"verdict": "never",
"note": "A backup control channel reaches every file on the protected host; keep it on the backup network and never on a public interface."
},
"checkCommand": "nc -vz -w 3 TARGET 15660",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 15660 (bex-xr)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=15660",
"kind": "iana"
},
{
"title": "Catalogic DPX (formerly Backup Express)",
"url": "https://www.catalogicsoftware.com/products/dpx/",
"kind": "official-docs"
}
]
},
{
"port": 15742,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "No IANA assignment and no documented default service — an open 15742 is something you have to identify yourself.",
"whatItIs": "15742 is unassigned in the IANA registry and carries no service name in Nmap's services database. It is in Nmap's default top-1000 TCP set purely because empirical scan data shows it open often enough to be worth probing, not because any known software claims it. Nearby 15740 is registered as PTP (Picture Transfer Protocol over TCP/IP), but that says nothing about 15742. In practice a listener here is an application-chosen high port: a container publish, a proxy, or an internal service someone numbered arbitrarily.",
"exposure": {
"verdict": "careful",
"note": "The finding is the unknown listener itself. Identify the process before deciding anything — an unrecognized high port on a public interface is worth treating as suspicious until it is named."
},
"checkCommand": "sudo lsof -nP -iTCP:15742 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "Nmap services frequency database",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 16000,
"protocol": "tcp",
"service": "FileMaker Server admin (fmsas)",
"oneLiner": "Registered to FileMaker as its Administration Server access port.",
"whatItIs": "IANA lists 16000 as fmsas, \"Administration Server Access\", registered by FileMaker (now Claris), which pairs it with 16001 (fmsascon) and the 16020/16021 Java Web Publishing ports. Historically the FileMaker Server Admin Console was reached at https://host:16000; current versions front the console on 443 and keep 16001 for local access. Because the number is convenient and unpoliced, other software squats it too, so confirm what answers before assuming FileMaker.",
"exposure": {
"verdict": "never",
"note": "An administration plane for a database server. If it is really FileMaker's admin service, it belongs on a management network, not on a public IP."
},
"checkCommand": "curl -skI --max-time 5 https://TARGET:16000/",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 16000 (fmsas)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=16000",
"kind": "iana"
},
{
"title": "Claris — Starting FileMaker Server Admin Console",
"url": "https://help.claris.com/en/server-help/content/start-admin-console.html",
"kind": "official-docs"
}
]
},
{
"port": 16001,
"protocol": "tcp",
"service": "FileMaker Server admin connector (fmsascon)",
"oneLiner": "FileMaker Server's local-only Admin Console URL: http://localhost:16001/admin-console.",
"whatItIs": "IANA registers 16001 as fmsascon, \"Administration Server Connector\", to FileMaker. Claris documents it as the way to open the Admin Console on the primary machine itself — http://localhost:16001/admin-console — and states plainly that port 16001 is only available on the local host, not from a remote machine. Remote administrators use the HTTPS console on the server's normal web port instead.",
"exposure": {
"verdict": "never",
"note": "Documented as loopback-only. If 16001 answers from another host, either the binding was changed or something other than FileMaker Server is listening."
},
"checkCommand": "curl -sI --max-time 5 http://localhost:16001/admin-console",
"links": [
{
"title": "Claris — Starting FileMaker Server Admin Console (localhost:16001)",
"url": "https://help.claris.com/en/server-help/content/start-admin-console.html",
"kind": "official-docs"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 16001 (fmsascon)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=16001",
"kind": "iana"
}
]
},
{
"port": 16012,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unregistered and unnamed — Nmap scans it on frequency data alone.",
"whatItIs": "There is no IANA assignment for 16012 and no service name in Nmap's database; it earns its place in Nmap's default top-1000 TCP list only because scans find it open with measurable frequency. The neighbouring 16020 and 16021 are registered to FileMaker's Java Web Publishing Core, but nothing extends that block down to 16012. Treat an open 16012 as an unidentified application port.",
"exposure": {
"verdict": "careful",
"note": "Nothing is known about what is behind it, which is exactly the problem: identify the listener before leaving it reachable from anywhere untrusted."
},
"checkCommand": "nmap -Pn -sV -p 16012 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "Nmap services frequency database",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 16016,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "No registration, no known default service — an open 16016 identifies nothing on its own.",
"whatItIs": "16016 is unassigned at IANA and unnamed in Nmap's services file, yet it sits inside Nmap's default top-1000 TCP ports because real-world scans see it open often enough to be worth a probe. No widely deployed product documents it as a default. A listener here is almost always an application or container that picked a memorable number.",
"exposure": {
"verdict": "careful",
"note": "Judge it by what answers, not by the number. Run a version probe; an unknown service on a public interface deserves the same suspicion as any unexplained daemon."
},
"checkCommand": "nmap -Pn -sV -p 16016 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "Nmap services frequency database",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 16018,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Another unregistered number in Nmap's top-1000 list with no documented owner.",
"whatItIs": "IANA has no assignment for 16018, and Nmap records it as unknown while still scanning it by default because of its observed open-port frequency. No mainstream software documents 16018 as a default listener. If you find it open, the only honest description is \"an unidentified TCP service\" until you fingerprint it.",
"exposure": {
"verdict": "careful",
"note": "An unattributed listener is the finding. Trace it to a process locally rather than reasoning from the port number."
},
"checkCommand": "sudo lsof -nP -iTCP:16018 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "Nmap services frequency database",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 16080,
"protocol": "tcp",
"service": "macOS Server web performance cache",
"oneLiner": "Where Apache actually listened on Mac OS X Server when the Performance Cache sat in front of it on port 80.",
"whatItIs": "Mac OS X Server is widely reported to have run a performance cache on port 80 with the Apache web server itself moved to TCP 16080, so requests that missed the cache went to 16080. Apple's documentation for that arrangement is no longer published, so the architecture is recorded here as received wisdom rather than a citable fact. Nmap still carries the port as osxwebadmin. Apple retired that architecture with the old Server web stack, so today an open 16080 is more often a generic alternate HTTP port than a Mac.",
"exposure": {
"verdict": "careful",
"note": "It is a plain HTTP backend that expects a cache or proxy in front of it. Exposed directly it bypasses whatever the front end was doing, and any HTTP app behind it is served in cleartext."
},
"checkCommand": "curl -sI --max-time 5 http://TARGET:16080/",
"links": [
{
"title": "Nmap services database (16080 osxwebadmin)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 16113,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unregistered, unnamed, and not claimed by any documented product.",
"whatItIs": "16113 has no IANA assignment and no Nmap service name. It is in Nmap's default scan set on frequency evidence only. Searching public source code for it turns up nothing but coincidental matches, which is itself the answer: there is no default service here to describe.",
"exposure": {
"verdict": "careful",
"note": "No verdict can be inherited from the number. Fingerprint the listener; whatever it is, it is not something a firewall rule can be written for blind."
},
"checkCommand": "nmap -Pn -sV -p 16113 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "Nmap services frequency database",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 16992,
"protocol": "tcp",
"service": "Intel AMT SOAP/HTTP",
"oneLiner": "The cleartext web and SOAP interface of Intel Active Management Technology — out-of-band control of the machine itself.",
"whatItIs": "IANA registers 16992 to Intel as amt-soap-http. It is served by the Management Engine, not the operating system, so it answers while the machine is asleep, unprovisioned or freshly reinstalled, and it exposes power control, boot device selection, serial-over-LAN and (with 16994/16995) KVM redirection. Nmap fingerprints it easily because the HTTP response identifies Intel AMT. Its most famous appearance is CVE-2017-5689 (INTEL-SA-00075), an authentication bypass that let anyone who could reach 16992 take over the box.",
"exposure": {
"verdict": "never",
"note": "Cleartext HTTP with Digest auth in front of full out-of-band hardware control. Firmware-level management belongs on an isolated management VLAN; internet-facing AMT is a takeover waiting for a firmware CVE."
},
"checkCommand": "curl -sI --max-time 5 http://TARGET:16992/",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 16992 (amt-soap-http)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=16992",
"kind": "iana"
},
{
"title": "INTEL-SA-00075 — AMT/ISM/SBT escalation of privilege (CVE-2017-5689)",
"url": "https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00075.html",
"kind": "official-docs"
},
{
"title": "Intel Open AMT Cloud Toolkit",
"url": "https://github.com/open-amt-cloud-toolkit/open-amt-cloud-toolkit",
"kind": "github"
}
]
},
{
"port": 16993,
"protocol": "tcp",
"service": "Intel AMT SOAP/HTTPS",
"oneLiner": "The TLS version of the Intel AMT management interface, available once AMT has a certificate.",
"whatItIs": "IANA registers 16993 to Intel as amt-soap-https. It carries the same SOAP/WS-Management interface as 16992 with TLS, and is the port AMT uses once it is provisioned in TLS mode; 16995 is the matching encrypted redirection port. Like 16992 it is answered by the Management Engine independently of the installed OS, so it survives reinstalls and appears on machines whose owners do not know AMT is enabled.",
"exposure": {
"verdict": "never",
"note": "TLS fixes the eavesdropping problem, not the exposure problem: this is out-of-band control of the hardware, historically vulnerable to firmware-level auth bypass. Keep it on a management network."
},
"checkCommand": "openssl s_client -connect TARGET:16993 -servername TARGET /dev/null | openssl x509 -noout -subject -issuer -dates",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 16993 (amt-soap-https)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=16993",
"kind": "iana"
},
{
"title": "INTEL-SA-00075 — AMT/ISM/SBT escalation of privilege (CVE-2017-5689)",
"url": "https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00075.html",
"kind": "official-docs"
},
{
"title": "Device Management Toolkit — deployment (formerly Intel Open AMT Cloud Toolkit)",
"url": "https://github.com/device-management-toolkit/deployment",
"kind": "github"
}
]
},
{
"port": 17877,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unregistered with no documented service; it is in Nmap's default scan set on frequency data alone.",
"whatItIs": "IANA has no assignment for 17877 and Nmap carries no name for it, yet it ranks inside Nmap's default top-1000 TCP ports because scans encounter it open. No mainstream product documents it as a default listener, and nearby ports in the 17870-17890 range are unassigned as well. An open 17877 tells you a process chose that number, nothing more.",
"exposure": {
"verdict": "careful",
"note": "Unknown service, so no defensible verdict from the port alone. Version-scan it and attribute it to a process before deciding whether it should be reachable."
},
"checkCommand": "nmap -Pn -sV -p 17877 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "Nmap services frequency database",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 17988,
"protocol": "tcp",
"service": "HPE iLO Virtual Media",
"oneLiner": "The default Virtual Media port on HPE iLO baseboard management controllers — a reliable way to spot a ProLiant's management processor.",
"whatItIs": "HPE's Integrated Lights-Out management processor exposes Virtual Media on TCP 17988 by default, alongside KVMIP on 17990 and HTTPS on 443; the linked Redfish emulator's NetworkProtocol mockup carries the same VirtualMedia port. Administrators have long scanned for 17988 to inventory iLOs on a subnet. The port is unassigned at IANA — the number is HPE's convention, changeable in the iLO settings.",
"exposure": {
"verdict": "never",
"note": "A BMC is a second computer with full control of the first: virtual media can boot arbitrary images. iLO belongs on an isolated management network, and an internet-reachable 17988 is a finding, not a configuration."
},
"checkCommand": "nc -vz -w 3 TARGET 17988",
"links": [
{
"title": "HPE iLO Redfish emulator — NetworkProtocol mockup (VirtualMedia port 17988)",
"url": "https://github.com/HewlettPackard/ilo-redfish-emulator",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 18040,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "No IANA registration and no documented default — an unidentified high port that scanners probe by habit.",
"whatItIs": "18040 is unassigned in the IANA registry and unnamed in Nmap's services database, but it is inside Nmap's default top-1000 TCP set because of observed open-port frequency. The registered ports nearby (18000 biimenu, 18104 radpdf) have no relationship to it. Whatever listens on 18040 chose the number itself.",
"exposure": {
"verdict": "careful",
"note": "Identify the process first. An unknown listener reachable from the internet is worth closing until someone can name it."
},
"checkCommand": "sudo lsof -nP -iTCP:18040 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "Nmap services frequency database",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 18101,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unregistered; the only true statement about a listener here is that something picked the number.",
"whatItIs": "IANA does not assign 18101 — the closest registration in the range is 18104 (radpdf, RAD PDF Service), which is a different port. Nmap has no service name for 18101 and scans it by default only because its measured open-port frequency puts it in the top 1000. No widely deployed software documents it as a default.",
"exposure": {
"verdict": "careful",
"note": "No known protocol means no known authentication or encryption story. Fingerprint before you decide, and default to closed at the perimeter."
},
"checkCommand": "nmap -Pn -sV -p 18101 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "Nmap services frequency database",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 18988,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unregistered and undocumented — present in default scans purely on frequency data.",
"whatItIs": "18988 has no IANA assignment and no Nmap service name. It sits in Nmap's default top-1000 TCP list because internet-wide scanning found it open often enough to be worth including. There is no known product default behind it, so any description of an open 18988 has to come from probing the host, not from a registry.",
"exposure": {
"verdict": "careful",
"note": "Unknown listener. Attribute it locally, then apply the verdict its actual protocol deserves."
},
"checkCommand": "nmap -Pn -sV -p 18988 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "Nmap services frequency database",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 19101,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "No registration and no documented service; the 19090-19110 range is empty at IANA.",
"whatItIs": "IANA assigns nothing between 19090 and 19110, 19101 included, and Nmap records the port as unknown while still scanning it by default on frequency grounds. Applications sometimes number an internal service 19101 as part of a self-chosen block, but there is no convention to point at. An open 19101 is an unattributed service.",
"exposure": {
"verdict": "careful",
"note": "Nothing about the number justifies exposure. Find the owning process and judge that."
},
"checkCommand": "sudo lsof -nP -iTCP:19101 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "Nmap services frequency database",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 19283,
"protocol": "both",
"service": "Sassafras KeyServer (keysrvr)",
"oneLiner": "The license-management port of Sassafras KeyServer, used by its KeyAccess clients.",
"whatItIs": "IANA registers 19283 as keysrvr, \"Key Server for SASSAFRAS\", to Sassafras Software, whose KeyServer product does software-license metering and computer-inventory tracking on university and enterprise fleets. Managed machines run a KeyAccess client that talks to the server on this port, which is why it shows up across a whole lab or campus subnet at once. Nmap sees it more often on UDP than TCP.",
"exposure": {
"verdict": "never",
"note": "An internal asset- and license-management service that every managed endpoint trusts. There is no reason for it to answer outside the organization's network."
},
"checkCommand": "nc -vz -w 3 TARGET 19283",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 19283 (keysrvr)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=19283",
"kind": "iana"
}
]
},
{
"port": 19315,
"protocol": "both",
"service": "Sassafras KeyServer shadow (keyshadow)",
"oneLiner": "The companion \"key shadow\" port of Sassafras KeyServer, registered alongside 19283.",
"whatItIs": "IANA registers 19315 as keyshadow, \"Key Shadow for SASSAFRAS\", to the same assignee as 19283 (keysrvr). It belongs to the Sassafras KeyServer license-management system and appears on the same hosts, so finding one usually means finding the other. Outside that product the number has no documented use.",
"exposure": {
"verdict": "never",
"note": "Same reasoning as 19283: part of an internal license-management fabric that managed clients trust implicitly. Keep it inside."
},
"checkCommand": "nc -vz -w 3 TARGET 19315",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 19315 (keyshadow)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=19315",
"kind": "iana"
}
]
},
{
"port": 19350,
"protocol": "tcp",
"service": "Adobe Flash/Adobe Media Server core",
"oneLiner": "The internal core-process port of Adobe Flash Media Server, unregistered but reliably fingerprinted.",
"whatItIs": "Nmap's service-probe database matches a distinctive binary banner on 19350 as \"Adobe Flash Media Server core\" — the internal channel between the server's admin/edge processes and its core processes, separate from the RTMP port 1935 and the admin port 1111. IANA has no assignment for 19350. Adobe Media Server is end-of-life, so an open 19350 today usually indicates a long-lived legacy streaming host.",
"exposure": {
"verdict": "never",
"note": "An internal inter-process channel of a discontinued, unpatched media server. It should not be reachable off the host, let alone from the internet."
},
"checkCommand": "nmap -Pn -sV -p 19350 TARGET",
"links": [
{
"title": "Nmap service fingerprint database (fms-core match on 19350)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-service-probes",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
}
]
},
{
"port": 19780,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unregistered with no documented default service; the nearest assignment is FairCom's 19790.",
"whatItIs": "IANA does not assign 19780 — 19788 is reserved and 19790 is faircom-db, neither of which covers it. Nmap has no name for the port but scans it by default because measured frequency puts it in the top 1000 TCP ports. Nothing widely deployed documents 19780 as a default listener.",
"exposure": {
"verdict": "careful",
"note": "Unknown service on a high port. Name the process before you decide what it deserves; unexplained listeners on public interfaces should be closed in the meantime."
},
"checkCommand": "nmap -Pn -sV -p 19780 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "Nmap services frequency database",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 19801,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned by IANA, no known service — it is in Nmap's default scan list only because hosts answer there.",
"whatItIs": "IANA lists 19801 inside the unassigned block 19791-19997, so no vendor has ever claimed it. Nmap's service table carries it with an open-frequency but the label 'unknown', which is why it lands in the default top-1000 TCP scan and shows up in reports. In practice anything listening here is a private application, a container port mapping, or a service someone moved off its normal port. Identify the listener before you assume anything about it.",
"exposure": {
"verdict": "careful",
"note": "The verdict belongs to whatever is actually bound here, not to the number. Fingerprint it first; an unidentified listener on a public IP is a finding, not a service."
},
"checkCommand": "nmap -Pn -sV -p 19801 --reason TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "Nmap nmap-services frequency table",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 19842,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned by IANA and unnamed in Nmap's table — a top-1000 scan port with no service behind it.",
"whatItIs": "19842 sits in the same unassigned IANA block as 19801 (19791-19997) and has no registration of any kind. Nmap records a nonzero open-frequency for it from internet-wide scanning, so it is included in the default 1000-port scan, but the service column reads 'unknown'. Anything found open here is site-specific: an in-house daemon, a relocated service, or a mapped container port. There is no protocol to describe.",
"exposure": {
"verdict": "careful",
"note": "Judge the listener, not the port number. Run a version scan and decide from what actually answers."
},
"checkCommand": "nmap -Pn -sV -p 19842 --reason TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "Nmap nmap-services frequency table",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 20000,
"protocol": "both",
"service": "DNP3 / Usermin",
"oneLiner": "Two unrelated things share this port: DNP3, the electric-utility SCADA protocol, and Usermin's HTTPS admin interface.",
"whatItIs": "IANA registers 20000 as 'dnp' for DNP3, the master/outstation protocol used between substation computers, RTUs and IEDs in electric utilities, water systems, and oil and gas; it is standardised as IEEE 1815 and DNP3-over-IP runs on TCP 20000. Independently, Usermin — the end-user companion to Webmin — defaults to HTTPS on 20000, so a scan hit is very often a Unix box offering webmail and password changes rather than a substation. The two are trivially told apart: Usermin answers a TLS handshake and serves HTML, DNP3 does not. On a general-purpose server assume Usermin; on an OT network assume DNP3.",
"exposure": {
"verdict": "never",
"note": "DNP3 has no authentication or encryption in its base form and speaks directly to physical plant. Usermin is a user-facing admin plane. Neither belongs on a public IP — put both behind a VPN."
},
"checkCommand": "nmap -Pn -sV -p 20000 --reason TARGET",
"links": [
{
"title": "DNP Users Group — Overview of DNP3",
"url": "https://www.dnp.org/About/Overview-of-DNP3-Protocol",
"kind": "official-docs"
},
{
"title": "IEEE Std 1815 — Electric Power Systems Communications (DNP3)",
"url": "https://standards.ieee.org/ieee/1815/5414/",
"kind": "spec"
},
{
"title": "Usermin — official documentation",
"url": "https://webmin.com/usermin/",
"kind": "official-docs"
},
{
"title": "Usermin source repository",
"url": "https://github.com/webmin/usermin",
"kind": "github"
}
]
},
{
"port": 20005,
"protocol": "both",
"service": "OpenWebNet",
"oneLiner": "IANA's registration for OpenWebNet, the BTicino/Legrand MyHOME home-automation protocol.",
"whatItIs": "OpenWebNet is the ASCII command protocol BTicino and Legrand use to drive MyHOME BUS/SCS installations — lights, shutters, thermostats, alarm — through an IP gateway. IANA assigned 20005 to BTicino for it, but shipping gateways and the client libraries that talk to them default to TCP 20000, so 20005 is the registered number rather than the one you usually meet. Nmap's table additionally carries the historical name 'btx' on 20005/tcp for German Telekom's CEPT videotex service, long dead. A hit here in a building or residential network is almost always a MyHOME gateway.",
"exposure": {
"verdict": "never",
"note": "OpenWebNet is cleartext and gateway authentication is a short numeric password at best. Exposing it hands out control of the building's lighting, HVAC and alarm."
},
"checkCommand": "nmap -Pn -sV -p 20005 --reason TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "openHAB OpenWebNet binding documentation",
"url": "https://www.openhab.org/addons/bindings/openwebnet/",
"kind": "official-docs"
},
{
"title": "Legrand Developer portal",
"url": "https://developer.legrand.com/",
"kind": "official-docs"
}
]
},
{
"port": 20031,
"protocol": "tcp",
"service": "Unassigned (NetVault on UDP)",
"oneLiner": "Unassigned on TCP; Nmap names the UDP side as BakBone NetVault's backup communications port.",
"whatItIs": "IANA has 20031 inside the unassigned range 20015-20033, so there is no TCP registration. Nmap's service table labels 20031/udp 'bakbonenetvault — BakBone NetVault primary communications port', with a comparatively high open-frequency, and NetVault (BakBone, later Quest) is the only widely documented user of this number. On TCP the entry is 'unknown'. If you find it open on a server that also runs backup agents, NetVault is the first thing to check; otherwise treat it as an unidentified listener.",
"exposure": {
"verdict": "never",
"note": "A backup control channel reaches every file on every protected host. Whether or not it is NetVault, this stays on a management network."
},
"checkCommand": "nmap -Pn -sV -p 20031 --reason TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "Nmap nmap-services frequency table",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 20221,
"protocol": "both",
"service": "Unassigned",
"oneLiner": "The last number in an unassigned IANA block, sitting directly below the registered 20222.",
"whatItIs": "IANA's unassigned range 20203-20221 ends here, and the very next port, 20222, is registered as iPulse-ICS — so 20221 is often scanned as the low half of a presumed pair even though nothing is assigned to it. Nmap carries it as 'unknown' on both TCP and UDP with a small open-frequency, which is enough to put it in the default top-1000 scan. There is no documented protocol for this number.",
"exposure": {
"verdict": "careful",
"note": "Nothing standard listens here, so an open port is an unknown application. Fingerprint it and judge that, not the number."
},
"checkCommand": "nmap -Pn -sV -p 20221 --reason TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "Nmap nmap-services frequency table",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 20222,
"protocol": "both",
"service": "iPulse-ICS",
"oneLiner": "Registered with IANA as iPulse-ICS on TCP and UDP; almost nothing public documents it beyond the registration.",
"whatItIs": "IANA assigns 20222 the service name 'ipulse-ics' on both TCP and UDP, registered to an individual assignee rather than a named standard or open project. Nmap inherits that name in its service table with a low open-frequency. Beyond the registry entry there is no published protocol description, no reference implementation, and no widely deployed product that documents using it, so a hit here is far more likely to be an unrelated in-house service than iPulse-ICS itself.",
"exposure": {
"verdict": "careful",
"note": "With no public protocol to reason about, the safe reading is 'unknown listener'. Identify what actually answers before leaving it reachable."
},
"checkCommand": "nmap -Pn -sV -p 20222 --reason TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "Nmap nmap-services frequency table",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 20828,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned, unnamed, but scanned often enough to rank high in Nmap's frequency table.",
"whatItIs": "IANA places 20828 in the unassigned block 20811-20998. Nmap lists it as 'unknown' yet with one of the higher open-frequencies among unnamed ports in this range, meaning internet-wide scans found it open on a measurable number of hosts without ever identifying what answered. No public protocol, product default, or RFC claims it. Treat an open 20828 as an unidentified application until a version scan says otherwise.",
"exposure": {
"verdict": "careful",
"note": "Unnamed but commonly-open ports attract opportunistic probing. Fingerprint the listener and apply that service's rules."
},
"checkCommand": "nmap -Pn -sV -p 20828 --reason TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "Nmap nmap-services frequency table",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 21571,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned by IANA with no documented service — present in default scans on frequency alone.",
"whatItIs": "21571 falls in IANA's unassigned range 21555-21589 and has no registration. Nmap's table names it 'unknown' with a small but nonzero open-frequency, which is the only reason it appears in the default top-1000 TCP scan. Nothing in the public record ties it to a product, protocol, or malware family. Whatever you find open here was put there by someone locally.",
"exposure": {
"verdict": "careful",
"note": "No standard service means no default guidance. Identify the listener and inherit that service's exposure rules."
},
"checkCommand": "nc -vz TARGET 21571",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "Nmap nmap-services frequency table",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 22939,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned on both TCP and UDP, with no service name anywhere in the public record.",
"whatItIs": "IANA has 22939 inside the unassigned block 22801-22950; no vendor or protocol has claimed it. Nmap carries 'unknown' entries for both 22939/tcp and 22939/udp with low open-frequencies, enough to include the TCP side in the default scan set. There is no documented default that uses this number, so an open port means a locally chosen listener — a custom service, a tunnel endpoint, or a remapped container port.",
"exposure": {
"verdict": "careful",
"note": "Decide from the fingerprint. An unnamed port carrying a real service still carries that service's risk."
},
"checkCommand": "nmap -Pn -sV -p 22939 --reason TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "Nmap nmap-services frequency table",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 23502,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned, unnamed, and one of the more frequently-open unregistered ports in Nmap's data.",
"whatItIs": "IANA lists 23502 in the unassigned range 23458-23545. Nmap labels it 'unknown' but gives it a relatively high open-frequency for an unregistered port, so scans find something answering on a noticeable share of hosts without any identification. No public documentation associates it with a product or protocol. As with the rest of this block, the port number tells you nothing; the banner does.",
"exposure": {
"verdict": "careful",
"note": "A commonly-open but unidentified port is worth investigating on your own hosts before it is worth exposing on anyone's."
},
"checkCommand": "nmap -Pn -sV -p 23502 --reason TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "Nmap nmap-services frequency table",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 24444,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned by IANA — a memorable repeated-digit number that developers pick by hand, not a registered service.",
"whatItIs": "24444 sits in IANA's unassigned block 24387-24464 with no registration on TCP or UDP. Nmap records it as 'unknown' on both, which puts the TCP side in the default top-1000 list. Repeated-digit ports like this get chosen ad hoc for local daemons, test harnesses, and debug listeners because they are easy to remember, so an open 24444 is usually somebody's own service rather than a product default. Nothing standard is defined here.",
"exposure": {
"verdict": "careful",
"note": "Hand-picked development ports are the ones most often left bound to 0.0.0.0 by accident. Check what it is and whether it should be listening at all."
},
"checkCommand": "nmap -Pn -sV -p 24444 --reason TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "Nmap nmap-services frequency table",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 24800,
"protocol": "tcp",
"service": "Deskflow / Synergy / Barrier",
"oneLiner": "The keyboard-and-mouse sharing port — one machine's input driving the screens of several others.",
"whatItIs": "Deskflow, and the Synergy, Barrier and Input Leap family it descends from, lets one keyboard and mouse control several computers by moving the pointer off the edge of a screen. The server listens on TCP 24800 and clients connect to it; the protocol carries mouse motion, key events and clipboard contents, and version 1.4 and later can wrap the connection in TLS. The default is hard-coded across the codebase and documentation, so an open 24800 on a desktop is almost always this. It is a workstation port, not a server one.",
"exposure": {
"verdict": "never",
"note": "This is a remote input channel into a live desktop session, including the clipboard. Keep it on the LAN or inside a VPN — never reachable from the internet."
},
"checkCommand": "nmap -Pn -sV -p 24800 --reason TARGET",
"links": [
{
"title": "Deskflow source repository",
"url": "https://github.com/deskflow/deskflow",
"kind": "github"
},
{
"title": "Deskflow protocol reference",
"url": "https://github.com/deskflow/deskflow/blob/master/docs/dev/protocol_reference.md",
"kind": "official-docs"
},
{
"title": "Deskflow project site",
"url": "https://deskflow.org/",
"kind": "official-docs"
}
]
},
{
"port": 25734,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned, unnamed, and usually seen next to 25735 — a pair with no documented owner.",
"whatItIs": "IANA has 25734 inside the unassigned range 25605-25792. Nmap lists it as 'unknown' with a small open-frequency, and the adjacent 25735 carries a separate 'unknown' entry, so the two are commonly reported together. No public documentation names a product that binds either. The pairing is suggestive of a single application using consecutive ports, but nothing verifiable identifies it.",
"exposure": {
"verdict": "careful",
"note": "Unknown listener. Fingerprint it, and if it turns out to be part of an application's control pair, apply that application's rules."
},
"checkCommand": "nmap -Pn -sV -p 25734,25735 --reason TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "Nmap nmap-services frequency table",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 25735,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "The upper half of the 25734/25735 pair — also unassigned, also unnamed.",
"whatItIs": "Like its neighbour, 25735 falls in IANA's unassigned block 25605-25792 with no registration on TCP or UDP. Nmap carries 'unknown' entries for both transports at a low open-frequency. No published product default, RFC, or malware report claims it. Anything found here is site-specific and needs to be identified from its banner rather than its number.",
"exposure": {
"verdict": "careful",
"note": "No standard service, so no default verdict. Version-scan it and judge the answer."
},
"checkCommand": "nmap -Pn -sV -p 25735 --reason TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "Nmap nmap-services frequency table",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 26214,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned, but Nmap aims its plain-text line probe here — whatever answers tends to be line-oriented.",
"whatItIs": "IANA lists 26214 in the unassigned range 26209-26256, so there is no registered service. It is more interesting than most unnamed ports for one reason: Nmap's service-probe file includes 26214 in the port list for the GenericLines probe, the one that sends bare CRLFs to elicit a banner from text protocols. That means Nmap's authors saw enough line-based services on this port to target it, without ever pinning down a name. Expect a text-speaking daemon of some kind, not a specific product.",
"exposure": {
"verdict": "careful",
"note": "A line-oriented service that answers a bare CRLF is usually cleartext. Confirm what it is before letting anything but the LAN reach it."
},
"checkCommand": "nmap -Pn -sV -p 26214 --reason TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "Nmap nmap-service-probes (GenericLines probe)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-service-probes",
"kind": "github"
}
]
},
{
"port": 27000,
"protocol": "both",
"service": "FlexNet Publisher (FlexLM)",
"oneLiner": "The first of FlexNet Publisher's license-manager ports — the daemon that decides whether your CAD or EDA seat starts.",
"whatItIs": "IANA reserves 27000-27009 for Flexera as 'flex-lm'. The FlexNet Publisher license server, lmgrd or lmadmin, binds the first free port in that range, which in practice is nearly always 27000, and vendor daemons listen on separate ports alongside it. Clients are configured with 27000@server and check out floating licenses over it, which is why this port turns up on engineering networks running MATLAB, Cadence, Synopsys, Autodesk and similar tools. The `lmutil lmstat` client queries it directly.",
"exposure": {
"verdict": "never",
"note": "The license daemon is unauthenticated by design and has a long history of remote vulnerabilities. Keep it inside the engineering network; never publish it, and firewall the vendor-daemon port too."
},
"checkCommand": "lmutil lmstat -a -c 27000@TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "Revenera FlexNet Licensing (FlexNet Publisher)",
"url": "https://www.revenera.com/software-monetization/products/software-licensing/flexnet-licensing",
"kind": "official-docs"
}
]
},
{
"port": 27017,
"protocol": "tcp",
"service": "MongoDB",
"oneLiner": "MongoDB's default port, registered to MongoDB, Inc. since 2019.",
"whatItIs": "27017 is the default listening port for `mongod` and `mongos`; sharded and config servers use 27018 and 27019. Access control is not enabled by default, so a server started without --auth and bound beyond localhost hands full read/write to anyone who connects. Point a browser at it and MongoDB answers over HTTP with a note that you are hitting the native driver port, which makes it easy to fingerprint.",
"exposure": {
"verdict": "never",
"note": "MongoDB's security checklist calls for enabling access control and restricting net.bindIp to trusted clients — an exposed 27017 is the classic ransomed-database scan hit."
},
"checkCommand": "curl -s http://127.0.0.1:27017/",
"links": [
{
"title": "MongoDB — Default MongoDB Ports",
"url": "https://www.mongodb.com/docs/manual/reference/default-mongodb-port/",
"kind": "official-docs"
},
{
"title": "MongoDB — Security Checklist",
"url": "https://www.mongodb.com/docs/manual/administration/security-checklist/",
"kind": "official-docs"
},
{
"title": "mongodb/mongo on GitHub",
"url": "https://github.com/mongodb/mongo",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 27017 (mongodb)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=27017",
"kind": "iana"
}
]
},
{
"port": 27352,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned, and one of four nearby ports in the same block that scanners keep finding open.",
"whatItIs": "27352 sits in IANA's unassigned range 27346-27441, alongside 27353, 27355 and 27356 — all four carry 'unknown' entries with similar open-frequencies in Nmap's table, which is why they tend to appear together in scan output. The same block also contains 27374, the port historically associated with the SubSeven Windows backdoor, but that association belongs to 27374 alone and does not extend to its neighbours. Nothing is registered or documented for 27352 itself.",
"exposure": {
"verdict": "careful",
"note": "Unidentified listener in a block with a scanning history. Find out what answers before deciding anything."
},
"checkCommand": "nmap -Pn -sV -p 27352,27353,27355,27356 --reason TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "Nmap nmap-services frequency table",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 27353,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned by IANA; unnamed in Nmap's table and usually reported next to 27352.",
"whatItIs": "IANA places 27353 in the unassigned block 27346-27441. Nmap lists it as 'unknown' with an open-frequency close to that of 27352, 27355 and 27356, so the four show up as a cluster in scan results without any of them being identified. No product default, protocol, or documented malware family claims this number. Read the banner, not the port.",
"exposure": {
"verdict": "careful",
"note": "Nothing standard listens here. Fingerprint the service and apply its rules rather than the port's."
},
"checkCommand": "nmap -Pn -sV -p 27353 --reason TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "Nmap nmap-services frequency table",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 27355,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned on TCP and UDP, part of the 27352-27356 cluster of unnamed scan hits.",
"whatItIs": "27355 is inside IANA's unassigned range 27346-27441 and has no registration. Nmap carries 'unknown' entries for it on both TCP and UDP. Its open-frequency matches its neighbours 27352, 27353 and 27356 closely enough that the four are effectively one scanning artefact rather than four distinct services. Nothing verifiable identifies what answers.",
"exposure": {
"verdict": "careful",
"note": "Treat as an unknown listener. A version scan is the only thing that turns this into a real verdict."
},
"checkCommand": "nmap -Pn -sV -p 27355 --reason TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "Nmap nmap-services frequency table",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 27356,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "The last of the unnamed 27352-27356 group; unassigned, with no documented service.",
"whatItIs": "IANA has 27356 in the unassigned block 27346-27441, so there is no registration to cite. Nmap lists it as 'unknown', with the lowest open-frequency of the four nearby ports it is usually reported with. There is no public record of a product, protocol or malware family that binds it. Anything open here has to be identified directly.",
"exposure": {
"verdict": "careful",
"note": "No standard service and no default guidance. Identify the listener, then decide."
},
"checkCommand": "nc -vz TARGET 27356",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "Nmap nmap-services frequency table",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 27715,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned by IANA on TCP and UDP, with no service name in any public source.",
"whatItIs": "27715 falls in IANA's large unassigned range 27505-27781. Nmap records 'unknown' entries on both TCP and UDP with small open-frequencies, and the TCP side makes the default top-1000 scan on that basis alone. No vendor documentation, RFC, or threat report ties this number to anything. Whatever is listening was configured locally.",
"exposure": {
"verdict": "careful",
"note": "The port carries no meaning of its own. Version-scan it and inherit the exposure rules of whatever answers."
},
"checkCommand": "nmap -Pn -sV -p 27715 --reason TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "Nmap nmap-services frequency table",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 28201,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "The first number in an unassigned IANA block, unnamed in Nmap and unclaimed by any product.",
"whatItIs": "IANA's unassigned range 28201-28239 begins at this port, so 28201 is registered to nobody. Nmap lists it as 'unknown' with a small open-frequency, enough to include it in the default 1000-port TCP scan. Nothing in the public record — vendor docs, RFCs, or malware reporting — associates it with a service. An open 28201 is a local decision someone made, and the banner is the only way to find out whose.",
"exposure": {
"verdict": "careful",
"note": "Unknown by default. Identify the listener; an unexplained open port on a public IP deserves closing rather than documenting."
},
"checkCommand": "nmap -Pn -sV -p 28201 --reason TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml",
"kind": "iana"
},
{
"title": "Nmap nmap-services frequency table",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 30000,
"protocol": "tcp",
"service": "ndmps (IANA) / Kubernetes NodePort",
"oneLiner": "Registered to a data-management protocol nobody deploys; in practice it is the first Kubernetes NodePort.",
"whatItIs": "IANA registers 30000/tcp as ndmps, \"Secure Network Data Management Protocol\", with an assignee but no reference document and no widely deployed implementation. The realistic reason you find 30000 open is that it is the bottom of Kubernetes' default NodePort range, 30000–32767, set by the kube-apiserver flag --service-node-port-range, so the first Service of type NodePort on a cluster often lands exactly here. Application dev servers and self-hosted tools also pick 30000 as a round number well clear of the privileged range. Fingerprint what answers rather than trusting the registry name.",
"exposure": {
"verdict": "careful",
"note": "If this is a Kubernetes NodePort, every node in the cluster answers on it and the Service behind it may not expect internet traffic; bind it behind an ingress or a firewall rather than exposing node IPs."
},
"checkCommand": "nc -vz -w 3 TARGET 30000",
"links": [
{
"title": "IANA port registry — 30000 (ndmps)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=30000",
"kind": "iana"
},
{
"title": "Kubernetes documentation — Service type: NodePort",
"url": "https://kubernetes.io/docs/concepts/services-networking/service/",
"kind": "official-docs"
}
]
},
{
"port": 30718,
"protocol": "both",
"service": "Lantronix 77FEh configuration port",
"oneLiner": "The remote-configuration port on Lantronix serial-to-Ethernet device servers — read/write access to the whole device config.",
"whatItIs": "Lantronix device servers such as the XPort and UDS families listen on 30718, which the vendor documentation writes as hex 77FEh, so that DeviceInstaller, the embedded Web Manager, and custom programs can read and write the unit's setup records remotely. The XPort user guide lists it among the reserved ports, ships it enabled by default, and defaults its access mode to Read & Write. IANA has 30718 inside an unassigned block, so nothing else claims the number; a scan hit here is almost always an embedded serial console or industrial gateway. Nmap sees it far more often on UDP than on most high ports, which matches a discovery protocol that answers broadcasts.",
"exposure": {
"verdict": "never",
"note": "This is an unauthenticated-by-default configuration plane for an embedded device; disable it (Security Settings > Disable Port 77FEh) or keep it strictly on a management segment, never on a public IP."
},
"checkCommand": "nc -vz -w 3 TARGET 30718",
"links": [
{
"title": "Lantronix XPort Device Server User Guide (port 77FEh / 30718)",
"url": "https://www.lantronix.com/wp-content/uploads/pdf/XPort_UG.pdf",
"kind": "official-docs"
},
{
"title": "IANA port registry — 30718 (unassigned)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=30718",
"kind": "iana"
}
]
},
{
"port": 30951,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "No registration and no known default service — but it sits inside the Kubernetes NodePort range.",
"whatItIs": "IANA leaves 30951 unassigned; it falls in the 30940–30998 unassigned block. No well-known software binds it by default and Nmap's frequency table lists it as unknown with a very low hit rate. The one systematic reason it appears is Kubernetes: the default NodePort range is 30000–32767, and the apiserver allocates ports from it more or less arbitrarily, so any NodePort Service can land here. Otherwise an open 30951 is an application that was handed a free port.",
"exposure": {
"verdict": "careful",
"note": "Nothing standard lives here, so the verdict belongs to whatever answers — fingerprint it before deciding, and treat a NodePort as an unintentionally public path to a cluster Service."
},
"checkCommand": "nc -vz -w 3 TARGET 30951",
"links": [
{
"title": "IANA port registry — 30951 (unassigned)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=30951",
"kind": "iana"
},
{
"title": "Kubernetes documentation — Service type: NodePort",
"url": "https://kubernetes.io/docs/concepts/services-networking/service/",
"kind": "official-docs"
}
]
},
{
"port": 31038,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unregistered, no default service, and inside the Kubernetes NodePort range.",
"whatItIs": "31038 is in IANA's unassigned 31030–31336 block, with no service name, contact, or reference. Nmap's table carries it only as an unknown TCP port with a low observed frequency and has no UDP entry for it at all. Like the rest of 30000–32767 it can be handed out as a Kubernetes NodePort, which is the most common structural explanation for finding it open. Beyond that there is no software known to choose it as a default.",
"exposure": {
"verdict": "careful",
"note": "An unidentified listener — fingerprint the banner and judge the service, not the port number."
},
"checkCommand": "nc -vz -w 3 TARGET 31038",
"links": [
{
"title": "IANA port registry — 31038 (unassigned)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=31038",
"kind": "iana"
},
{
"title": "Kubernetes documentation — Service type: NodePort",
"url": "https://kubernetes.io/docs/concepts/services-networking/service/",
"kind": "official-docs"
}
]
},
{
"port": 31337,
"protocol": "both",
"service": "eldim (IANA) / \"elite\" backdoor port",
"oneLiner": "Leetspeak for \"eleet\" — the traditional backdoor port, and since registered to the eldim upload proxy.",
"whatItIs": "31337 spells ELEET in leetspeak, which is why a generation of backdoors and joke services chose it; Nmap still names 31337/udp BackOrifice after the Cult of the Dead Cow remote-administration tool and names 31337/tcp \"Elite\". IANA has since registered both the TCP and UDP entries to eldim, an open-source file-upload proxy that encrypts uploads before pushing them to object storage. The number also lands inside Kubernetes' default NodePort range, so clusters allocate it by accident. In short: nothing legitimate listens here by convention, and an unexplained 31337 is worth identifying rather than assuming.",
"exposure": {
"verdict": "careful",
"note": "eldim is designed to face the internet over HTTPS, so the port itself is not the problem — but an unexpected 31337 on a host you did not configure is an incident-response question, not a firewall question."
},
"checkCommand": "nc -vz -w 3 TARGET 31337",
"links": [
{
"title": "IANA port registry — 31337 (eldim)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=31337",
"kind": "iana"
},
{
"title": "eldim — a secure file upload proxy",
"url": "https://github.com/daknob/eldim",
"kind": "github"
},
{
"title": "nmap-services — Nmap's port frequency and name table",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 32400,
"protocol": "tcp",
"service": "Plex Media Server",
"oneLiner": "Plex Media Server's web UI and API — someone on the network is running a media library.",
"whatItIs": "Plex Media Server binds TCP 32400 for its web app (/web), its HTTP API, and all media streaming; the port is formally registered to Plex Inc. with IANA. It appears on scans of NAS boxes, home servers, and desktops, and Plex's remote-access feature deliberately maps it through the router via UPnP or a manual forward. An unauthenticated GET /identity returns the server's machineIdentifier and version, which is how you fingerprint one.",
"exposure": {
"verdict": "careful",
"note": "Plex is designed for internet exposure with account-based auth and relays, but it has shipped pre-auth vulnerabilities (CVE-2020-5741 among them), so expose it only on a current version with remote access managed by Plex rather than a hand-rolled forward."
},
"checkCommand": "curl -s -m 3 http://TARGET:32400/identity",
"links": [
{
"title": "IANA port registry — 32400 (Plex multimedia, registered by Plex Inc.)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=32400",
"kind": "iana"
},
{
"title": "Plex Inc. on GitHub (plexinc)",
"url": "https://github.com/plexinc",
"kind": "github"
}
]
},
{
"port": 32768,
"protocol": "both",
"service": "filenet-tms (IANA) / first ephemeral port on Linux",
"oneLiner": "IANA says FileNet TMS; Linux says this is where the ephemeral port range starts.",
"whatItIs": "IANA registers 32768 to FileNet TMS, part of an IBM FileNet block running from 32768 to 32777, and that software is rare. The far more common reason the port is busy is that 32768 is the bottom of the Linux default ephemeral range — the kernel documents ip_local_port_range as 32768 to 60999 — so it is the first port the kernel hands to an outbound socket, a `docker run -P` publish, or any program that asked for port 0. Solaris historically started its RPC dynamic range here too. A listener on 32768 is therefore usually anonymous rather than FileNet.",
"exposure": {
"verdict": "careful",
"note": "Whatever bound this asked the OS for \"any free port\", which means nobody chose to publish it — identify the process before allowing it through a firewall."
},
"checkCommand": "sudo lsof -nP -iTCP:32768 -sTCP:LISTEN",
"links": [
{
"title": "IANA port registry — 32768 (filenet-tms)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=32768",
"kind": "iana"
},
{
"title": "Linux kernel documentation — ip-sysctl (ip_local_port_range)",
"url": "https://www.kernel.org/doc/html/latest/networking/ip-sysctl.html",
"kind": "official-docs"
}
]
},
{
"port": 32769,
"protocol": "both",
"service": "filenet-rpc (IANA) / ephemeral or RPC service",
"oneLiner": "Registered to FileNet RPC, in practice the second port out of the Linux ephemeral pool.",
"whatItIs": "IANA lists 32769 as filenet-rpc for IBM FileNet, one of the 32768–32777 block, and deployments of it are uncommon. Sitting one above the start of the Linux ephemeral range (32768–60999), it is far more often a socket that asked for any free port — an outbound connection, a container port publish, or a dynamically bound RPC program registered with rpcbind. Nmap sees it as a low-frequency open port with no reliable fingerprint.",
"exposure": {
"verdict": "careful",
"note": "Treat as an unidentified dynamically assigned service; ask rpcbind or the host's own socket table what it is before exposing it."
},
"checkCommand": "rpcinfo -p TARGET",
"links": [
{
"title": "IANA port registry — 32769 (filenet-rpc)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=32769",
"kind": "iana"
},
{
"title": "Linux kernel documentation — ip-sysctl (ip_local_port_range)",
"url": "https://www.kernel.org/doc/html/latest/networking/ip-sysctl.html",
"kind": "official-docs"
},
{
"title": "rpcbind(8) manual page",
"url": "https://man7.org/linux/man-pages/man8/rpcbind.8.html",
"kind": "official-docs"
}
]
},
{
"port": 32770,
"protocol": "both",
"service": "filenet-nch (IANA) / dynamic ONC RPC",
"oneLiner": "Registered to FileNet NCH; in the wild it is a dynamically assigned ONC RPC program, not that product.",
"whatItIs": "IANA assigns 32770 to FileNet NCH, part of the FileNet block spanning 32768–32777, and that product is rarely what you find. Historically this range is where Solaris and other System V hosts handed out ports to ONC RPC programs that registered with rpcbind, which is why Nmap names the port sometimes-rpc3. Nmap's own comment for it is \"Sometimes an RPC port on my Solaris box\" — no specific program named. On Linux the same number falls inside the default ephemeral range (32768–60999), so it can equally be a container publish or an outbound socket. The only way to know is to ask rpcbind or fingerprint the listener.",
"exposure": {
"verdict": "careful",
"note": "Legacy ONC RPC services here (statd, rusersd, rquotad, sprayd, walld) authenticate weakly or not at all and have a long CVE history; keep them off the internet and reachable only from trusted NFS clients."
},
"checkCommand": "rpcinfo -p TARGET",
"links": [
{
"title": "IANA port registry — 32770 (filenet-nch)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=32770",
"kind": "iana"
},
{
"title": "RFC 1833 — Binding Protocols for ONC RPC Version 2",
"url": "https://www.rfc-editor.org/rfc/rfc1833.html",
"kind": "spec"
},
{
"title": "rpcbind(8) manual page",
"url": "https://man7.org/linux/man-pages/man8/rpcbind.8.html",
"kind": "official-docs"
},
{
"title": "nmap-services — Nmap's port frequency and name table",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 32771,
"protocol": "both",
"service": "filenet-rmi (IANA) / dynamic ONC RPC",
"oneLiner": "Registered to FileNET RMI; in the wild it is a dynamically assigned ONC RPC program, not that product.",
"whatItIs": "IANA assigns 32771 to FileNET RMI, part of the FileNet block spanning 32768–32777, and that product is rarely what you find. Historically this range is where Solaris and other System V hosts handed out ports to ONC RPC programs that registered with rpcbind, which is why Nmap names the port sometimes-rpc5. Nmap's comment records it as an RPC port on Solaris, most often rusersd. On Linux the same number falls inside the default ephemeral range (32768–60999), so it can equally be a container publish or an outbound socket. The only way to know is to ask rpcbind or fingerprint the listener.",
"exposure": {
"verdict": "careful",
"note": "Legacy ONC RPC services here (statd, rusersd, rquotad, sprayd, walld) authenticate weakly or not at all and have a long CVE history; keep them off the internet and reachable only from trusted NFS clients."
},
"checkCommand": "rpcinfo -p TARGET",
"links": [
{
"title": "IANA port registry — 32771 (filenet-rmi)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=32771",
"kind": "iana"
},
{
"title": "RFC 1833 — Binding Protocols for ONC RPC Version 2",
"url": "https://www.rfc-editor.org/rfc/rfc1833.html",
"kind": "spec"
},
{
"title": "rpcbind(8) manual page",
"url": "https://man7.org/linux/man-pages/man8/rpcbind.8.html",
"kind": "official-docs"
},
{
"title": "nmap-services — Nmap's port frequency and name table",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 32772,
"protocol": "both",
"service": "filenet-pa (IANA) / dynamic ONC RPC",
"oneLiner": "Registered to FileNET Process Analyzer; in the wild it is a dynamically assigned ONC RPC program, not that product.",
"whatItIs": "IANA assigns 32772 to FileNET Process Analyzer, part of the FileNet block spanning 32768–32777, and that product is rarely what you find. Historically this range is where Solaris and other System V hosts handed out ports to ONC RPC programs that registered with rpcbind, which is why Nmap names the port sometimes-rpc7. Nmap's comment records it as an RPC port on Solaris, most often the status (rpc.statd) program. On Linux the same number falls inside the default ephemeral range (32768–60999), so it can equally be a container publish or an outbound socket. The only way to know is to ask rpcbind or fingerprint the listener.",
"exposure": {
"verdict": "careful",
"note": "Legacy ONC RPC services here (statd, rusersd, rquotad, sprayd, walld) authenticate weakly or not at all and have a long CVE history; keep them off the internet and reachable only from trusted NFS clients."
},
"checkCommand": "rpcinfo -p TARGET",
"links": [
{
"title": "IANA port registry — 32772 (filenet-pa)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=32772",
"kind": "iana"
},
{
"title": "RFC 1833 — Binding Protocols for ONC RPC Version 2",
"url": "https://www.rfc-editor.org/rfc/rfc1833.html",
"kind": "spec"
},
{
"title": "rpcbind(8) manual page",
"url": "https://man7.org/linux/man-pages/man8/rpcbind.8.html",
"kind": "official-docs"
},
{
"title": "nmap-services — Nmap's port frequency and name table",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 32773,
"protocol": "both",
"service": "filenet-cm (IANA) / dynamic ONC RPC",
"oneLiner": "Registered to FileNET Component Manager; in the wild it is a dynamically assigned ONC RPC program, not that product.",
"whatItIs": "IANA assigns 32773 to FileNET Component Manager, part of the FileNet block spanning 32768–32777, and that product is rarely what you find. Historically this range is where Solaris and other System V hosts handed out ports to ONC RPC programs that registered with rpcbind, which is why Nmap names the port sometimes-rpc9. Nmap's comment records it as an RPC port on Solaris, most often rquotad. On Linux the same number falls inside the default ephemeral range (32768–60999), so it can equally be a container publish or an outbound socket. The only way to know is to ask rpcbind or fingerprint the listener.",
"exposure": {
"verdict": "careful",
"note": "Legacy ONC RPC services here (statd, rusersd, rquotad, sprayd, walld) authenticate weakly or not at all and have a long CVE history; keep them off the internet and reachable only from trusted NFS clients."
},
"checkCommand": "rpcinfo -p TARGET",
"links": [
{
"title": "IANA port registry — 32773 (filenet-cm)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=32773",
"kind": "iana"
},
{
"title": "RFC 1833 — Binding Protocols for ONC RPC Version 2",
"url": "https://www.rfc-editor.org/rfc/rfc1833.html",
"kind": "spec"
},
{
"title": "rpcbind(8) manual page",
"url": "https://man7.org/linux/man-pages/man8/rpcbind.8.html",
"kind": "official-docs"
},
{
"title": "nmap-services — Nmap's port frequency and name table",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 32774,
"protocol": "both",
"service": "filenet-re (IANA) / dynamic ONC RPC",
"oneLiner": "Registered to FileNET Rules Engine; in the wild it is a dynamically assigned ONC RPC program, not that product.",
"whatItIs": "IANA assigns 32774 to FileNET Rules Engine, part of the FileNet block spanning 32768–32777, and that product is rarely what you find. Historically this range is where Solaris and other System V hosts handed out ports to ONC RPC programs that registered with rpcbind, which is why Nmap names the port sometimes-rpc11. Nmap's comment records it as an RPC port on Solaris, most often rusersd. On Linux the same number falls inside the default ephemeral range (32768–60999), so it can equally be a container publish or an outbound socket. The only way to know is to ask rpcbind or fingerprint the listener.",
"exposure": {
"verdict": "careful",
"note": "Legacy ONC RPC services here (statd, rusersd, rquotad, sprayd, walld) authenticate weakly or not at all and have a long CVE history; keep them off the internet and reachable only from trusted NFS clients."
},
"checkCommand": "rpcinfo -p TARGET",
"links": [
{
"title": "IANA port registry — 32774 (filenet-re)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=32774",
"kind": "iana"
},
{
"title": "RFC 1833 — Binding Protocols for ONC RPC Version 2",
"url": "https://www.rfc-editor.org/rfc/rfc1833.html",
"kind": "spec"
},
{
"title": "rpcbind(8) manual page",
"url": "https://man7.org/linux/man-pages/man8/rpcbind.8.html",
"kind": "official-docs"
},
{
"title": "nmap-services — Nmap's port frequency and name table",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 32775,
"protocol": "both",
"service": "filenet-pch (IANA) / dynamic ONC RPC",
"oneLiner": "Registered to Performance Clearinghouse; in the wild it is a dynamically assigned ONC RPC program, not that product.",
"whatItIs": "IANA assigns 32775 to Performance Clearinghouse, part of the FileNet block spanning 32768–32777, and that product is rarely what you find. Historically this range is where Solaris and other System V hosts handed out ports to ONC RPC programs that registered with rpcbind, which is why Nmap names the port sometimes-rpc13. Nmap's comment records it as an RPC port on Solaris, most often the status (rpc.statd) program. On Linux the same number falls inside the default ephemeral range (32768–60999), so it can equally be a container publish or an outbound socket. The only way to know is to ask rpcbind or fingerprint the listener.",
"exposure": {
"verdict": "careful",
"note": "Legacy ONC RPC services here (statd, rusersd, rquotad, sprayd, walld) authenticate weakly or not at all and have a long CVE history; keep them off the internet and reachable only from trusted NFS clients."
},
"checkCommand": "rpcinfo -p TARGET",
"links": [
{
"title": "IANA port registry — 32775 (filenet-pch)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=32775",
"kind": "iana"
},
{
"title": "RFC 1833 — Binding Protocols for ONC RPC Version 2",
"url": "https://www.rfc-editor.org/rfc/rfc1833.html",
"kind": "spec"
},
{
"title": "rpcbind(8) manual page",
"url": "https://man7.org/linux/man-pages/man8/rpcbind.8.html",
"kind": "official-docs"
},
{
"title": "nmap-services — Nmap's port frequency and name table",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 32776,
"protocol": "both",
"service": "filenet-peior (IANA) / dynamic ONC RPC",
"oneLiner": "Registered to FileNET BPM IOR; in the wild it is a dynamically assigned ONC RPC program, not that product.",
"whatItIs": "IANA assigns 32776 to FileNET BPM IOR, part of the FileNet block spanning 32768–32777, and that product is rarely what you find. Historically this range is where Solaris and other System V hosts handed out ports to ONC RPC programs that registered with rpcbind, which is why Nmap names the port sometimes-rpc15. Nmap's comment records it as an RPC port on Solaris, most often sprayd. On Linux the same number falls inside the default ephemeral range (32768–60999), so it can equally be a container publish or an outbound socket. The only way to know is to ask rpcbind or fingerprint the listener.",
"exposure": {
"verdict": "careful",
"note": "Legacy ONC RPC services here (statd, rusersd, rquotad, sprayd, walld) authenticate weakly or not at all and have a long CVE history; keep them off the internet and reachable only from trusted NFS clients."
},
"checkCommand": "rpcinfo -p TARGET",
"links": [
{
"title": "IANA port registry — 32776 (filenet-peior)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=32776",
"kind": "iana"
},
{
"title": "RFC 1833 — Binding Protocols for ONC RPC Version 2",
"url": "https://www.rfc-editor.org/rfc/rfc1833.html",
"kind": "spec"
},
{
"title": "rpcbind(8) manual page",
"url": "https://man7.org/linux/man-pages/man8/rpcbind.8.html",
"kind": "official-docs"
},
{
"title": "nmap-services — Nmap's port frequency and name table",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 32777,
"protocol": "both",
"service": "filenet-obrok (IANA) / dynamic ONC RPC",
"oneLiner": "Registered to FileNet BPM CORBA; in the wild it is a dynamically assigned ONC RPC program, not that product.",
"whatItIs": "IANA assigns 32777 to FileNet BPM CORBA, part of the FileNet block spanning 32768–32777, and that product is rarely what you find. Historically this range is where Solaris and other System V hosts handed out ports to ONC RPC programs that registered with rpcbind, which is why Nmap names the port sometimes-rpc17. Nmap's comment records it as an RPC port on Solaris, most often walld. On Linux the same number falls inside the default ephemeral range (32768–60999), so it can equally be a container publish or an outbound socket. The only way to know is to ask rpcbind or fingerprint the listener.",
"exposure": {
"verdict": "careful",
"note": "Legacy ONC RPC services here (statd, rusersd, rquotad, sprayd, walld) authenticate weakly or not at all and have a long CVE history; keep them off the internet and reachable only from trusted NFS clients."
},
"checkCommand": "rpcinfo -p TARGET",
"links": [
{
"title": "IANA port registry — 32777 (filenet-obrok)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=32777",
"kind": "iana"
},
{
"title": "RFC 1833 — Binding Protocols for ONC RPC Version 2",
"url": "https://www.rfc-editor.org/rfc/rfc1833.html",
"kind": "spec"
},
{
"title": "rpcbind(8) manual page",
"url": "https://man7.org/linux/man-pages/man8/rpcbind.8.html",
"kind": "official-docs"
},
{
"title": "nmap-services — Nmap's port frequency and name table",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 32778,
"protocol": "both",
"service": "Unassigned / dynamic ONC RPC",
"oneLiner": "Past the end of the registered FileNet block — unassigned, and typically a dynamically bound RPC program.",
"whatItIs": "IANA's registrations stop at 32777; 32778 begins the unassigned 32778–32800 block, so there is no official service name. Nmap calls it sometimes-rpc19 with the comment \"Sometimes an RPC port on my Solaris box (rstatd)\", reflecting the same dynamic ONC RPC allocation that fills 32770 upward. On Linux it is inside the default ephemeral range (32768–60999) and is just as likely to be an outbound socket or a published container port. Identify the listener; the number carries no meaning of its own.",
"exposure": {
"verdict": "careful",
"note": "rstatd and its neighbours hand out host telemetry with no authentication, and anything else here is unidentified — both argue for keeping the range internal."
},
"checkCommand": "rpcinfo -p TARGET",
"links": [
{
"title": "IANA port registry — 32778 (unassigned)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=32778",
"kind": "iana"
},
{
"title": "RFC 1833 — Binding Protocols for ONC RPC Version 2",
"url": "https://www.rfc-editor.org/rfc/rfc1833.html",
"kind": "spec"
},
{
"title": "rpcbind(8) manual page",
"url": "https://man7.org/linux/man-pages/man8/rpcbind.8.html",
"kind": "official-docs"
},
{
"title": "nmap-services — Nmap's port frequency and name table",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 32779,
"protocol": "both",
"service": "Unassigned / dynamic ONC RPC",
"oneLiner": "Unregistered; Nmap knows it only as another slot in the Solaris RPC dynamic range.",
"whatItIs": "32779 falls in IANA's unassigned 32778–32800 block with no service name or reference. Nmap lists it as sometimes-rpc21 with the generic comment \"Sometimes an RPC port on my Solaris box\", meaning it observed RPC programs there often enough to name it but could not tie it to one program. It is also inside the Linux default ephemeral range (32768–60999). An open 32779 tells you a process bound a dynamic port, nothing more.",
"exposure": {
"verdict": "careful",
"note": "Unidentified dynamic service — query rpcbind or the host's socket table before you decide anything about exposure."
},
"checkCommand": "rpcinfo -p TARGET",
"links": [
{
"title": "IANA port registry — 32779 (unassigned)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=32779",
"kind": "iana"
},
{
"title": "RFC 1833 — Binding Protocols for ONC RPC Version 2",
"url": "https://www.rfc-editor.org/rfc/rfc1833.html",
"kind": "spec"
},
{
"title": "nmap-services — Nmap's port frequency and name table",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 32780,
"protocol": "both",
"service": "Unassigned / dynamic ONC RPC",
"oneLiner": "The last port Nmap still labels as a Solaris RPC slot; unregistered at IANA.",
"whatItIs": "Like its neighbours, 32780 sits in IANA's unassigned 32778–32800 block. Nmap names it sometimes-rpc23 — \"Sometimes an RPC port on my Solaris box\" — and above this point its RPC naming becomes sparse. On Linux the port is ordinary ephemeral space (32768–60999), routinely used by outbound connections and by `docker run -P` publishes. Nothing chooses 32780 deliberately.",
"exposure": {
"verdict": "careful",
"note": "The exposure question belongs to whichever program grabbed the port; nothing about the number itself makes it safe or unsafe."
},
"checkCommand": "rpcinfo -p TARGET",
"links": [
{
"title": "IANA port registry — 32780 (unassigned)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=32780",
"kind": "iana"
},
{
"title": "RFC 1833 — Binding Protocols for ONC RPC Version 2",
"url": "https://www.rfc-editor.org/rfc/rfc1833.html",
"kind": "spec"
},
{
"title": "nmap-services — Nmap's port frequency and name table",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 32781,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "No IANA registration and no default service — ordinary Linux ephemeral space.",
"whatItIs": "32781 is inside IANA's unassigned 32778–32800 block: no service name, no assignee, no reference. Nmap carries it only as an unknown TCP port. Its practical identity is that it is part of the Linux default ephemeral port range, documented as 32768–60999, so the kernel hands it out to outbound sockets, to programs that bind port 0, and to Docker when publishing a container port without a fixed host port. Finding it open means a process took a free port, not that a known service is running.",
"exposure": {
"verdict": "careful",
"note": "An anonymous dynamically assigned port — identify the owning process locally; do not firewall-allow the number on the assumption it means something."
},
"checkCommand": "sudo lsof -nP -iTCP:32781 -sTCP:LISTEN",
"links": [
{
"title": "IANA port registry — 32781 (unassigned)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=32781",
"kind": "iana"
},
{
"title": "Linux kernel documentation — ip-sysctl (ip_local_port_range)",
"url": "https://www.kernel.org/doc/html/latest/networking/ip-sysctl.html",
"kind": "official-docs"
}
]
},
{
"port": 32782,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "No IANA registration and no default service — ordinary Linux ephemeral space.",
"whatItIs": "32782 is inside IANA's unassigned 32778–32800 block: no service name, no assignee, no reference. Nmap carries it only as an unknown TCP port, at the same low frequency as 32781. Its practical identity is that it is part of the Linux default ephemeral port range, documented as 32768–60999, so the kernel hands it out to outbound sockets, to programs that bind port 0, and to Docker when publishing a container port without a fixed host port. Finding it open means a process took a free port, not that a known service is running.",
"exposure": {
"verdict": "careful",
"note": "An anonymous dynamically assigned port — identify the owning process locally; do not firewall-allow the number on the assumption it means something."
},
"checkCommand": "sudo lsof -nP -iTCP:32782 -sTCP:LISTEN",
"links": [
{
"title": "IANA port registry — 32782 (unassigned)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=32782",
"kind": "iana"
},
{
"title": "Linux kernel documentation — ip-sysctl (ip_local_port_range)",
"url": "https://www.kernel.org/doc/html/latest/networking/ip-sysctl.html",
"kind": "official-docs"
}
]
},
{
"port": 32783,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "No IANA registration and no default service — ordinary Linux ephemeral space.",
"whatItIs": "32783 is inside IANA's unassigned 32778–32800 block: no service name, no assignee, no reference. Nmap carries it only as an unknown TCP port, at a lower frequency than the RPC-named ports below it. Its practical identity is that it is part of the Linux default ephemeral port range, documented as 32768–60999, so the kernel hands it out to outbound sockets, to programs that bind port 0, and to Docker when publishing a container port without a fixed host port. Finding it open means a process took a free port, not that a known service is running.",
"exposure": {
"verdict": "careful",
"note": "An anonymous dynamically assigned port — identify the owning process locally; do not firewall-allow the number on the assumption it means something."
},
"checkCommand": "sudo lsof -nP -iTCP:32783 -sTCP:LISTEN",
"links": [
{
"title": "IANA port registry — 32783 (unassigned)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=32783",
"kind": "iana"
},
{
"title": "Linux kernel documentation — ip-sysctl (ip_local_port_range)",
"url": "https://www.kernel.org/doc/html/latest/networking/ip-sysctl.html",
"kind": "official-docs"
}
]
},
{
"port": 32784,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "No IANA registration and no default service — ordinary Linux ephemeral space.",
"whatItIs": "32784 is inside IANA's unassigned 32778–32800 block: no service name, no assignee, no reference. Nmap carries it only as an unknown TCP port. Its practical identity is that it is part of the Linux default ephemeral port range, documented as 32768–60999, so the kernel hands it out to outbound sockets, to programs that bind port 0, and to Docker when publishing a container port without a fixed host port. Finding it open means a process took a free port, not that a known service is running.",
"exposure": {
"verdict": "careful",
"note": "An anonymous dynamically assigned port — identify the owning process locally; do not firewall-allow the number on the assumption it means something."
},
"checkCommand": "sudo lsof -nP -iTCP:32784 -sTCP:LISTEN",
"links": [
{
"title": "IANA port registry — 32784 (unassigned)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=32784",
"kind": "iana"
},
{
"title": "Linux kernel documentation — ip-sysctl (ip_local_port_range)",
"url": "https://www.kernel.org/doc/html/latest/networking/ip-sysctl.html",
"kind": "official-docs"
}
]
},
{
"port": 32785,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "No IANA registration and no default service — ordinary Linux ephemeral space.",
"whatItIs": "32785 is inside IANA's unassigned 32778–32800 block: no service name, no assignee, no reference. Nmap carries it only as an unknown TCP port; the next port up, 32786, is where Nmap resumes RPC naming (mountd). Its practical identity is that it is part of the Linux default ephemeral port range, documented as 32768–60999, so the kernel hands it out to outbound sockets, to programs that bind port 0, and to Docker when publishing a container port without a fixed host port. Finding it open means a process took a free port, not that a known service is running.",
"exposure": {
"verdict": "careful",
"note": "An anonymous dynamically assigned port — identify the owning process locally; do not firewall-allow the number on the assumption it means something."
},
"checkCommand": "sudo lsof -nP -iTCP:32785 -sTCP:LISTEN",
"links": [
{
"title": "IANA port registry — 32785 (unassigned)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=32785",
"kind": "iana"
},
{
"title": "Linux kernel documentation — ip-sysctl (ip_local_port_range)",
"url": "https://www.kernel.org/doc/html/latest/networking/ip-sysctl.html",
"kind": "official-docs"
}
]
},
{
"port": 33354,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "No registered service — whatever answers here is a local choice, or a Linux ephemeral port caught mid-connection.",
"whatItIs": "IANA lists 33354 as unassigned, and Nmap's service database has no name for it either, recording it open on roughly 0.08% of hosts in its internet-wide research scans. It also falls inside the Linux default ephemeral range (32768-60999), so a socket seen here is frequently the client end of an outbound connection rather than a server. There is no protocol you can assume from the number alone.",
"exposure": {
"verdict": "careful",
"note": "An unidentified listener on an unregistered high port is a fingerprinting job before it is a firewall decision — find out what process owns it, then decide."
},
"checkCommand": "nmap -sV -Pn -p 33354 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 33354",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=33354",
"kind": "iana"
},
{
"title": "nmap/nmap — nmap-services (port frequency database)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
},
{
"title": "Linux kernel — ip-sysctl (ip_local_port_range defaults 32768-60999)",
"url": "https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt",
"kind": "official-docs"
}
]
},
{
"port": 33899,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unregistered and unnamed in scanner databases; open on well under a tenth of a percent of hosts.",
"whatItIs": "33899 has no IANA assignment and no service name in Nmap's database, which records it open on about 0.04% of scanned hosts. Like everything between 32768 and 60999 it doubles as a Linux ephemeral port, so an open socket here is as likely to be an outbound connection as a service. Identify it by the process, not by the number.",
"exposure": {
"verdict": "careful",
"note": "Nothing about the port number tells you whether it is safe; run a version scan or check the owning process before allowing it through a firewall."
},
"checkCommand": "nc -vz -w 3 TARGET 33899",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 33899",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=33899",
"kind": "iana"
},
{
"title": "nmap/nmap — nmap-services (port frequency database)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 34571,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned by IANA — the first of the 34571-34573 block that scanners list with no name attached.",
"whatItIs": "IANA has no registration for 34571, and Nmap carries it as unknown with an open frequency near 0.04%. Its two neighbours, 34572 and 34573, are equally unregistered, which is why the three tend to appear together in port lists rather than because any documented protocol claims them. On a Linux host the number is also inside the default ephemeral range, so transient sockets show up here routinely.",
"exposure": {
"verdict": "careful",
"note": "Treat it as an unknown service: fingerprint the listener and confirm what owns it before exposing anything on it."
},
"checkCommand": "nmap -sV -Pn -p 34571 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 34571",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=34571",
"kind": "iana"
},
{
"title": "nmap/nmap — nmap-services (port frequency database)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 34572,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned; the middle port of the unnamed 34571-34573 run.",
"whatItIs": "There is no IANA assignment for 34572 and no service name in Nmap's database, which measures it open on about 0.04% of scanned hosts. Anything answering here was configured by hand or picked by an application at runtime. It also sits inside the Linux ephemeral range, so short-lived client sockets land on it by chance.",
"exposure": {
"verdict": "careful",
"note": "Unknown service: get a version banner and the owning process before you decide anything about exposure."
},
"checkCommand": "sudo lsof -nP -iTCP:34572 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 34572",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=34572",
"kind": "iana"
},
{
"title": "nmap/nmap — nmap-services (port frequency database)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 34573,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned; the last of the 34571-34573 run and just as anonymous as the other two.",
"whatItIs": "34573 carries no IANA registration and no name in Nmap's service database, with a measured open frequency around 0.04%. Unlike 34571 and 34572 it has no UDP counterpart in Nmap's data at all, which is a fair sign that sightings are incidental rather than a protocol. As with the rest of the 32768-60999 band on Linux, an open socket here may simply be an outbound connection.",
"exposure": {
"verdict": "careful",
"note": "Nothing is known to run here by convention, so an open port means an unidentified service — fingerprint first."
},
"checkCommand": "nmap -sV -Pn -p 34573 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 34573",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=34573",
"kind": "iana"
},
{
"title": "nmap/nmap — nmap-services (port frequency database)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 35500,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "A round, memorable number with no registration behind it — pure convention when you find it in use.",
"whatItIs": "IANA does not assign 35500, and Nmap has no service name for it, recording it open on roughly 0.08% of scanned hosts. Round numbers like this get picked by hand for internal services precisely because they are easy to remember, which is the usual reason one is listening. The number is also inside Linux's default ephemeral range, so not every open socket here is a server.",
"exposure": {
"verdict": "careful",
"note": "A hand-picked port often means a hand-rolled service; confirm what it is and whether it authenticates before it faces anything untrusted."
},
"checkCommand": "nmap -sV -Pn -p 35500 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 35500",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=35500",
"kind": "iana"
},
{
"title": "nmap/nmap — nmap-services (port frequency database)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 38292,
"protocol": "tcp",
"service": "LANDesk Common Base Agent (landesk-cba)",
"oneLiner": "Nmap names this landesk-cba — the management agent from LANDesk, now Ivanti Endpoint Manager.",
"whatItIs": "IANA has no assignment for 38292, but Nmap's service database labels it landesk-cba, the Common Base Agent that LANDesk Management Suite (later Ivanti Endpoint Manager) installs on managed endpoints to take remote-management traffic. On a corporate network an open 38292 usually means the host is enrolled in that management platform. Measured open frequency is low, about 0.03%, which matches a product-specific agent rather than a general protocol.",
"exposure": {
"verdict": "never",
"note": "This is an endpoint-management control channel — reaching it means reaching a remote-administration agent, so it belongs on a management network, never on a public IP."
},
"checkCommand": "nmap -sV -Pn -p 38292 TARGET",
"links": [
{
"title": "nmap/nmap — nmap-services (38292/tcp landesk-cba)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 38292 (unassigned)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=38292",
"kind": "iana"
}
]
},
{
"port": 40193,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "No registration, no scanner name — an anonymous high port.",
"whatItIs": "40193 is unassigned at IANA and unnamed in Nmap's service database, which records it open on about 0.04% of scanned hosts. It sits well inside the Linux ephemeral range, so plenty of sightings are ordinary outbound connections rather than services. Whatever listens here was chosen locally.",
"exposure": {
"verdict": "careful",
"note": "No known protocol to reason about — identify the process and its authentication before allowing inbound traffic."
},
"checkCommand": "nmap -sV -Pn -p 40193 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 40193",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=40193",
"kind": "iana"
},
{
"title": "nmap/nmap — nmap-services (port frequency database)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 40911,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unregistered and rare — Nmap finds it open on roughly two hosts in ten thousand.",
"whatItIs": "There is no IANA registration for 40911 and no service name in Nmap's database, which measures its open frequency at about 0.02%, near the bottom of the ports Nmap bothers to scan by default. Nothing conventional runs here, so an open port is either a bespoke service or an ephemeral socket in the Linux 32768-60999 range. The number itself tells you nothing.",
"exposure": {
"verdict": "careful",
"note": "Rare and unidentified is not the same as harmless; fingerprint the listener before making any exposure decision."
},
"checkCommand": "nc -vz -w 3 TARGET 40911",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 40911",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=40911",
"kind": "iana"
},
{
"title": "nmap/nmap — nmap-services (port frequency database)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 41511,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "Unassigned by IANA and unnamed by scanners; one of the quietest ports in Nmap's default set.",
"whatItIs": "41511 has no IANA assignment and no entry name in Nmap's service database beyond \"unknown\", with an open frequency around 0.02%. Anything found listening was configured deliberately by whoever runs the host. It is also inside the Linux default ephemeral range, so transient client sockets appear on it by chance.",
"exposure": {
"verdict": "careful",
"note": "Unknown service on an unregistered port — get a banner and the owning process before deciding what it deserves."
},
"checkCommand": "nmap -sV -Pn -p 41511 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 41511",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=41511",
"kind": "iana"
},
{
"title": "nmap/nmap — nmap-services (port frequency database)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 42510,
"protocol": "both",
"service": "CA eTrust RPC (caerpc)",
"oneLiner": "Registered in 2005 as caerpc, the RPC channel for Computer Associates' eTrust security products.",
"whatItIs": "42510 is one of the few ports in this range with a real IANA assignment: caerpc, \"CA eTrust RPC\", registered on both TCP and UDP in August 2005 by Computer Associates. eTrust was CA's security product line — antivirus and access control — and the port carried its RPC management traffic between agents and servers. That branding is long retired (CA became part of Broadcom), so a modern open 42510 is more often an unrelated listener or an ephemeral socket than a genuine eTrust deployment; Nmap still sees it open on about 0.1% of hosts.",
"exposure": {
"verdict": "never",
"note": "An RPC control channel for security agents is a management plane — keep it inside the management network, and if the software is genuinely still running, treat its age as the bigger problem."
},
"checkCommand": "nmap -sV -Pn -p 42510 TARGET",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 42510 (caerpc, CA eTrust RPC)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=42510",
"kind": "iana"
},
{
"title": "nmap/nmap — nmap-services (42510 caerpc)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 44176,
"protocol": "tcp",
"service": "Unassigned",
"oneLiner": "No registration and no known convention — an arbitrary high port.",
"whatItIs": "IANA does not assign 44176, and Nmap lists it as unknown with an open frequency near 0.02%. There is no documented product or protocol that claims it, so a listener here is entirely a local decision. The number is inside Linux's default ephemeral range as well, so many sightings are client-side sockets.",
"exposure": {
"verdict": "careful",
"note": "Identify the process first; an unregistered port gives you no basis to judge whether the service behind it authenticates."
},
"checkCommand": "sudo lsof -nP -iTCP:44176 -sTCP:LISTEN",
"links": [
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 44176",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=44176",
"kind": "iana"
},
{
"title": "nmap/nmap — nmap-services (port frequency database)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
}
]
},
{
"port": 44442,
"protocol": "tcp",
"service": "ColdFusion Advanced Security (coldfusion-auth)",
"oneLiner": "Nmap calls it coldfusion-auth — the authentication port from Allaire ColdFusion's Advanced Security, paired with 44443.",
"whatItIs": "IANA has no assignment for 44442, but Nmap's service database names it coldfusion-auth, from the Advanced Security feature Allaire built into ColdFusion using Netegrity SiteMinder; 44442 and 44443 were its pair of authentication ports. That feature was dropped from ColdFusion long ago, so an open 44442 today is more likely to be an unrelated service than a live ColdFusion security server. Nmap's measured open frequency is about 0.016%, among the lowest in its default scan set.",
"exposure": {
"verdict": "never",
"note": "It is an authentication back-channel between application-server components, not a public interface — and if it really is the Allaire-era service, it is two decades unpatched."
},
"checkCommand": "nmap -sV -Pn -p 44442 TARGET",
"links": [
{
"title": "nmap/nmap — nmap-services (44442/tcp coldfusion-auth)",
"url": "https://github.com/nmap/nmap/blob/master/nmap-services",
"kind": "github"
},
{
"title": "IANA Service Name and Transport Protocol Port Number Registry — 44442 (unassigned)",
"url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=44442",
"kind": "iana"
}
]
},
{
"port": 44443,
"protocol": "tcp",
"service": "ColdFusion Advanced Security (coldfusion-auth)",
"oneLiner": "The second coldfusion-auth port in Nmap's database, and otherwise an unregistered number that reads like an alternate HTTPS.",
"whatItIs": "44443 has no IANA assignment; Nmap names it coldfusion-auth alongside 44442, from the Allaire/Netegrity Advanced Security component of old ColdFusion releases. Because the digits echo 443, it also gets picked by hand as an alternate HTTPS port, so a TLS handshake succeeding here does not make it ColdFusion. Open frequency in Nmap's data is about 0.02%.",
"exposure": {
"verdict": "careful",
"note": "Two very different things answer on this number, so identify which before deciding — a legacy ColdFusion auth service should never be reachable, while a properly configured alternate HTTPS listener is a normal thing to expose."
},
"checkCommand": "openssl s_client -connect TARGET:44443 -brief