Port 514 – Syslog/RSH (System Logging Protocol / Remote Shell)

Port 514 is used by two different services: syslog (UDP) for system logging and rsh (TCP) for remote shell. They share a number but nothing else — UDP 514 is where devices ship their logs to a central server, and TCP 514 is where the Berkeley rshd daemon runs commands on a remote host. Both are cleartext and both are unauthenticated in the ways that matter, so an open port 514 is worth pinning down on sight: check the transport first, because the service — and the risk — is completely different depending on whether you hit UDP or TCP.

On TCP 514, rsh (remote shell) is the third Berkeley r-service, alongside rexec (512) and rlogin (513), all replaced by SSH on port 22. Like rlogin it leans on host-based .rhosts / hosts.equiv trust — a trusted host gets a shell or an rcp file copy with no password at all. On UDP 514, syslog is the classic connectionless log-transport protocol: unauthenticated, unencrypted, and trivially spoofable, which makes it a target for log forgery and eavesdropping rather than direct shell access. This page covers both.

Why It’s Open

UDP 514 (syslog) is still the default for centralized logging. Routers, switches, firewalls, hypervisors, Unix/Linux hosts, and appliances of every kind ship their logs to a collector — a syslog server, a SIEM, or a log relay — over UDP 514, and the receiver (syslogd, rsyslog, or syslog-ng) listens there by default. It’s everywhere precisely because it’s simple and every OS speaks it; the trade-off is that plain UDP syslog has no authentication and no encryption.

TCP 514 (rsh) is legacy. Before SSH, rsh was the standard way to run a one-off command on another UNIX box without an interactive login. It still turns up on old Solaris, AIX, and HP-UX systems, on appliances and industrial gear running ancient firmware, and in lab images like Metasploitable 2 that ship the r-services on by default. Where TCP 514 is still listening it usually means an inetd/xinetd entry nobody cleaned up — and its siblings rexec (512) and rlogin (513) are usually one scan away.

Common Risks

Syslog (UDP 514):

• Log injection and forgery. Syslog over UDP has no authentication, so anyone who can reach the port can send forged messages. An attacker can poison the SIEM, bury real activity under noise, fabricate events to frame another host, or inject content that breaks a downstream log parser.
• Spoofing. UDP is connectionless and the source IP is trivial to spoof, so forged messages can be made to look like they came from a trusted device — defeating source-based trust in the logging pipeline.
• Information disclosure. Log messages routinely carry sensitive data — usernames, internal hostnames, IPs, session details, occasionally secrets. In cleartext on the wire, all of it is sniffable with tcpdump or Wireshark.
• Denial of service / log flooding. A flood of messages can overwhelm the collector, fill disks, or drop the legitimate logs an incident responder needs — and because it’s UDP, there’s no handshake to slow the attacker down.
• Open relays. A syslog server that accepts and forwards from anyone can be abused to relay junk into other systems.

rsh (TCP 514):

• Passwordless shell via host trust. The defining rsh weakness: a ~/.rhosts or /etc/hosts.equiv entry that trusts a host (worst case, a wildcard + + line) lets a matching user run commands with no password. Find a trusted or overly-broad entry and rshd hands you command execution outright.
• Host and IP/DNS spoofing. Because the trust is keyed on the source host, spoofing the IP or poisoning name resolution of a trusted machine can satisfy the check and bypass authentication entirely.
• Cleartext everything. Commands, output, and any data moved with rcp cross the wire unencrypted and can be sniffed or hijacked by an on-path attacker.
• Remote command execution by design. rsh exists to run the command you send. A satisfied trust check is immediate code execution — there’s no extra step to exploit.
• Sibling trust abuse. rsh ships alongside rexec (512) and rlogin (513); finding TCP 514 open almost always means the other two — and their .rhosts trust — are worth checking.

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

Book a Demo

Enumeration & Testing

Detect the service on both transports

nmap -sU -sT -p 514 -sV <target>

-sU -sT scans UDP and TCP together; -sV tries to tell syslog (UDP) apart from the rsh shell (TCP).

Send a test syslog message (UDP)

logger -n <target> -P 514 -d "pentest syslog test"

-d sends over UDP and -P 514 sets the port. If the message lands in the collector, the server is accepting unauthenticated syslog from you — which is exactly the log-injection path.

Forge a raw syslog packet with netcat

printf '<34>pentest: forged message' | nc -u -w1 <target> 514

The <34> is a syslog PRI value. A message with a spoofed hostname arriving in the SIEM confirms forgery is possible.

Capture syslog traffic on the wire

tcpdump -n -A -i any udp port 514

Cleartext log lines in the capture confirm the information-disclosure risk.

Run a command over rsh (TCP)

rsh -l <user> <target> id

If <user> is trusted via .rhosts / hosts.equiv, this returns the output of id with no password prompt — direct remote command execution.

Metasploit rsh login scanner

msfconsole -q
use auxiliary/scanner/rservices/rsh_login
set RHOSTS <target>
set USERPASS_FILE userpass.txt
set STOP_ON_SUCCESS true
run

rsh_login enumerates trusted username combinations; it must bind a privileged local port below 1024, so run Metasploit as root. Hydra also ships an rsh module for the same job.

Log every open port 514 — on which transport — plus every forged message that lands and every trust relationship you find, so the evidence goes straight into the pentest report instead of a scratch terminal you’ll lose.

What to Look For

Known CVEs and Exploits

Port 514’s real exposure is design, not a single patchable bug — plain UDP syslog is unauthenticated and spoofable by specification, and rsh’s host-based trust is a bypass by nature. Neither has a fix short of encryption/authentication or turning the service off. That said, several genuine service-specific CVEs are worth citing, split by service.

Syslog (rsyslog / sysklogd):

• CVE-2022-24903 — Heap buffer overflow in rsyslog’s TCP syslog reception modules (imtcp, imptcp, imgssapi, imhttp) when octet-counted framing is enabled — the default on receivers. Digits are written past the buffer when the octet count exceeds the maximum, causing crashes on rsyslog before 8.2204.1 (CVSS v3.1 8.1 HIGH; RCE considered unlikely by the vendor).
• CVE-2014-3634 — Out-of-bounds array access in rsyslog before 7.6.6 / 8.x before 8.4.1 and sysklogd 1.5 and earlier, reachable remotely via a crafted priority (PRI) value in a syslog message. Denial of service and possibly code execution (CVSS v2 7.5 HIGH). The follow-up CVE-2014-3683 is an integer overflow from the same incomplete PRI fix (large PRI value → crash, CVSS v2 5.0).

rsh (rshd / in.rshd):

• CVE-1999-0180 — in.rshd allows a login with a NULL username and executes commands, a genuine remote command-execution flaw in the rsh daemon on affected legacy builds (CVSS v2 7.5 HIGH).
• CVE-1999-0651 — “The rsh/rlogin service is running.” The legacy scanner finding that flags the r-services as present at all, precisely because a trust-based, plaintext shell daemon is a risk by its nature (CVSS v2 7.5 HIGH).

In practice the rsh “exploit” is usually the trust model itself: find a permissive .rhosts / hosts.equiv entry (or spoof a trusted host), then rsh <target> <command> for passwordless code execution — Metasploit’s rsh_login automates finding the trusted usernames. Treat any open rsh as compromised-by-design, and treat any open UDP 514 as a logging pipeline that can be forged into.

Mitigation

For rsh (TCP 514):

• Disable rsh, rlogin, and rexec entirely. There is no modern reason to run the r-services. Remove or comment out the shell, login, and exec entries in /etc/inetd.conf (or the matching xinetd files) and restart the super-server.
• Remove .rhosts and /etc/hosts.equiv. Hunt down and delete every stray trust file — they grant passwordless command execution even after you think the service is locked down, and a single + + line is a full bypass.
• Migrate to SSH. Move remote command execution to SSH on port 22, which encrypts the session and supports key-based auth. ssh user@host command is the direct replacement for rsh, and scp/sftp replace rcp.
• Block TCP 512–514 at the host and network firewall so nothing outside a trusted management range can reach the r-services.

For syslog (UDP 514):

• Move to encrypted, reliable syslog. Use syslog over TLS (TCP 6514) or RELP (reliable event logging) so log traffic is encrypted and authenticated end to end, instead of forgeable cleartext UDP.
• Authenticate and restrict senders. Configure the collector to accept messages only from known source IPs (and validate them via TLS certificates where supported), so arbitrary hosts can’t inject.
• Firewall UDP 514 to the specific devices that legitimately ship logs — never expose it to untrusted networks or the internet.
• Validate and rate-limit. Sanity-check and rate-limit incoming messages at the collector to blunt log injection, malformed-PRI bugs, and flooding, and keep rsyslog/syslog-ng patched against the CVEs above.

Real-World Example

The r-services are a fixture of the Metasploitable 2 training VM, which leaves rexec (512), rlogin (513), and rsh (514) open with a wide-open /etc/hosts.equiv that trusts every host. Point auxiliary/scanner/rservices/rsh_login at TCP 514, or simply run rsh -l root <target> id — and because the trust file accepts anyone, rshd runs the command and returns a root-level result with no password at all. The same blind host trust drove the 1990s trust-relationship attacks, where spoofing the IP of a trusted machine was enough to walk into every host that trusted it.

The syslog side fails differently. Because UDP 514 accepts unauthenticated, spoofable messages, an attacker who can reach the collector can forge log entries: fabricate a “login succeeded” from a decoy host to mislead responders, or bury the real trail under a flood of noise so the events that matter never make it to disk. Nothing is “exploited” in the memory-corruption sense — the protocol simply trusts whatever arrives, which is exactly why encrypted, authenticated syslog exists.

FAQ

What is port 514 used for?

Port 514 hosts two unrelated services on different transports. UDP 514 is syslog, the standard protocol for sending system and device logs to a central collector. TCP 514 is rsh (remote shell), a Berkeley r-service that runs commands on a remote UNIX host over host-based trust. Check the transport to know which one you’re dealing with.

Is port 514 dangerous?

Both sides carry risk on an untrusted network. UDP syslog is unauthenticated and spoofable, so logs can be forged, sniffed, or flooded. TCP rsh can hand over passwordless command execution through .rhosts / hosts.equiv trust, in cleartext. Treat an exposed port 514 as something to lock down or replace, not to harden in place.

What’s the difference between TCP 514 and UDP 514?

UDP 514 is syslog (system logging) — connectionless, unauthenticated log transport. TCP 514 is rsh (remote shell) — a legacy r-service for remote command execution. Same port number, entirely different protocols and threats: log forgery on the UDP side, trust-based shell access on the TCP side. (Reliable syslog can also run over TCP 514 or, encrypted, over TLS on 6514.)

What service runs on port 514?

On UDP, the syslog daemon (syslogd, rsyslog, or syslog-ng). On TCP, the rsh daemon (rshd / in.rshd), one of the Berkeley r-services alongside rexec (512) and rlogin (513) — all replaced by SSH on port 22.

How do I secure or close port 514?

For rsh: disable the shell entry in inetd/xinetd, remove .rhosts / hosts.equiv, migrate to SSH, and firewall TCP 512–514. For syslog: move to encrypted syslog over TLS (6514) or RELP, accept messages only from known senders, and firewall UDP 514 to the devices that need it. Rescan with nmap -sU -sT -p 514 <target> to confirm.

TL;DR

• Two services, one port: syslog (system logging) on UDP 514; rsh (remote shell) on TCP 514
• Syslog risk: unauthenticated, spoofable, cleartext — log injection/forgery, disclosure, and flooding
• rsh risk: passwordless command execution via spoofable .rhosts / hosts.equiv trust, all in cleartext — a Berkeley r-service replaced by SSH
• Mitigation: disable rsh (remove .rhosts/hosts.equiv, move to SSH, firewall 512–514); move syslog to TLS (6514)/RELP, restrict senders, firewall UDP 514