| Port | 9100 |
|---|---|
| Transport | TCP |
| Service | JetDirect / node_exporter — Raw printing, Prometheus node exporter |
| Category | Monitoring and logging |
| Range | registered (1024–49151) |
| Encrypted | No, plaintext |
| Exposure | Private network or VPN only |
Port 9100 JetDirect / node_exporter · TCP
Two very different things: HP JetDirect raw printing, which nearly every network printer accepts (send a PostScript or PCL file to port 9100 and it prints), and the Prometheus node_exporter, which serves host metrics at /metrics.
What runs on port 9100
Two very different things: HP JetDirect raw printing, which nearly every network printer accepts (send a PostScript or PCL file to port 9100 and it prints), and the Prometheus node_exporter, which serves host metrics at /metrics. Printers on 9100 reachable from the internet have been used for mass "print-bombing"; node_exporter leaks hostnames, kernel versions and disk layout.
Software that uses it: Network printers (JetDirect / AppSocket) · CUPS socket backend · Prometheus node_exporter
Should port 9100 be open?
Private network or VPN only. Nothing good comes from this port being reachable from the internet. Keep it on an internal network, reach it over a VPN or an SSH tunnel, and firewall it from everything that does not need it.
- Printer: nc printer 9100 < file.ps prints it; that is also why the port must stay internal.
- node_exporter: curl -s host:9100/metrics | head; front it with TLS and basic auth via its web.config.yml if it must cross networks.
Check port 9100
# on the host: is anything listening, and which process? ss -ltnp 'sport = :9100' sudo lsof -i :9100 # from another machine: is it reachable? nc -zv host 9100 nmap -p 9100 host curl -v telnet://host:9100 # raw TCP connect test, Ctrl-C to leave
A port that answers from the internet when it should not is the finding; nmap from a machine outside your network (or a VPS) is the honest test, because scans from inside the LAN pass the firewall you are trying to verify.
Allow or block port 9100
# ufw (Ubuntu/Debian) sudo ufw allow from 10.0.0.0/8 to any port 9100 proto tcp sudo ufw deny 9100/tcp # nftables nft add rule inet filter input ip saddr 10.0.0.0/8 tcp dport 9100 accept nft add rule inet filter input tcp dport 9100 drop # iptables (legacy) iptables -A INPUT -p tcp --dport 9100 -s 10.0.0.0/8 -j ACCEPT iptables -A INPUT -p tcp --dport 9100 -j DROP # firewalld sudo firewall-cmd --permanent --add-rich-rule='rule family=ipv4 source address=10.0.0.0/8 port port=9100 protocol=tcp accept'
Replace 10.0.0.0/8 with the networks that need access. Allowing by source address is the rule that matters; "allow 9100" with no source is just "open".
Related ports
Part of the port number reference. Ports are 16-bit numbers; see also the subnet calculator and the packet decoder, which shows ports inside TCP and UDP headers.
Questions
Is port 9100 TCP or UDP?
TCP. JetDirect / node_exporter is a connection-oriented protocol; there is no UDP service on 9100 by default (a scanner reporting UDP 9100 open is usually seeing a filtered port).
Is port 9100 encrypted?
No, plaintext. Anything sent over it can be read by whoever is on the path, so it belongs on a trusted network or inside a VPN or SSH tunnel.
How do I check whether port 9100 is open?
On the server, ss -ltnp (or -lunp for UDP) shows whether something listens on 9100 and which process. From another machine, nc -zv host 9100 or nmap -p 9100 host tests reachability. "Open" in a scan means something answered; a firewall usually makes the port filtered (no answer) rather than closed (RST).
Can JetDirect / node_exporter run on a different port?
Yes; the number is a convention, not a requirement. Changing it reduces log noise from scanners but does not add security, and every client, firewall rule and monitoring check then needs the new number. Keep the default unless you have a concrete reason.