Port 113 – Ident (Identification Protocol)

Port 113 is the default port for Ident, the Identification Protocol defined in RFC 1413 — also called the auth service or identd. When a server receives a TCP connection, it can open a connection back to port 113 on the machine that just connected and ask “which local user owns the connection coming from your port X to my port Y?” A running identd looks up that connection and answers with the OS username behind it. It was built so multi-user Unix hosts could tell a server who had connected, back when one IP address meant dozens of shared-login users. RFC 1413 itself warned in 1993 that the reply is only as honest as the machine giving it — so to a pentester, ident is a recon and auditing signal, never a real authentication check.

Why It’s Open

You still meet identd on IRC servers, some mail servers (MTAs like sendmail), and legacy Unix/Linux hosts that expect ident lookups — the same generation of cleartext service as Finger on port 79. Almost nothing modern runs it on purpose; where it answers, the host is usually old, and old hosts tend to have a stale stack worth a closer look. The twist on port 113 is that you’ll far more often see it reported as 113/tcp closed ident than open: firewalls and appliances deliberately reset it (see the Real-World Example) so that mail and IRC servers doing an ident callback fail instantly instead of hanging. Closed here means “reachable, ident just isn’t running” — which is a different signal from a silently filtered port and worth noting in your scan results.

Common Risks

• Service-owner disclosure. This is the real finding. Point nmap --script auth-owners at an open 113 and it maps every other open port to the OS user running it. Spotting that a listener is owned by root versus an unprivileged service account tells an attacker exactly which process is worth attacking first — a free privilege map with no credentials.
• Username and OS enumeration. A successful reply is literally USERID : UNIX : username, leaking both a valid account name and an OS token. Those usernames feed straight into password spraying against SSH, SMTP, or any other login on the box.
• Blindly trusting ident is a weakness. Any host can run a fake identd that returns whatever username it likes — oidentd has a spoof mode built for exactly this. Anything that makes access decisions from an ident reply (older PostgreSQL ident auth, IRC operator checks) can be lied to, which is why RFC 1413 says never to use it for authorization.
• Exploitable legacy daemons. Several third-party identd implementations carry remote memory-corruption bugs — TinyIdentD, Fake Identd, and ident2 all have overflows that give remote code execution (see below), and even current enterprise gear isn’t immune, with a Cisco IOS ident handler crash as recent as 2019.
• Reverse attack on the client. Because the querying server connects back to your identd, a malicious identd can attack the thing that queries it — the cfingerd RFC 1413 client overflow (CVE-2013-1049) is triggered just by a server fingering an attacker who answers ident with an over-long string.

Want to save time on reporting?

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

Book a Demo

Enumeration & Testing

Detect the service and grab the banner

nmap -sV -p 113 <target>

A live service shows as 113/tcp open ident; a reset shows 113/tcp closed ident.

Map open ports to their owning users

nmap -sV -p 113 --script auth-owners <target>

auth-owners is in nmap’s default/safe set, so -sC or -A runs it automatically. For each other open port it prints the OS user that owns the listener — the fastest way to find services running as root.

Check for a spoofing identd

nmap -p 113 --script auth-spoof <target>

If the daemon replies before it’s even asked, auth-spoof flags it — a sign the identd is returning canned usernames (sometimes a malware indicator, sometimes a privacy tweak). Either way, treat its answers as untrustworthy.

Enumerate connection owners across ports

ident-user-enum <target> 22 25 80 139 445

pentestmonkey’s ident-user-enum (shipped in Kali) queries port 113 for each listed service port and prints the owning user — the same idea as auth-owners, handy when you already have a port list.

Query it by hand

Ident only answers about a TCP connection that actually exists between you and the target, keyed on the full source/destination pair. Open one and hold it, then ask about it — server-port first, then your client port:

nc <target> 22          # hold this connection open
ss -tnp | grep :22      # note your local (client) source port, e.g. 54012
printf '22, 54012\r\n' | nc <target> 113

An invented port pair with no matching live connection just returns ERROR : NO-USER. Record every username and service-owner you confirm so it lands in the final pentest report rather than a scratch file.

What to Look For

Known CVEs and Exploits

• CVE-2007-2711 — Stack-based buffer overflow in TinyIdentD 2.2 and earlier: a long string sent to TCP port 113 gives remote code execution (CVSS 10.0). The single most on-topic port 113 bug, with a public PoC at Exploit-DB 3925 and the Metasploit module exploit/windows/misc/tiny_identd_overflow.
• CVE-2002-1792 — Remote buffer overflow in Fake Identd 0.9 through 1.4, giving code execution as root (CVSS 10.0) — ironic in a daemon deployed specifically to be the “safe” identd. PoC at Exploit-DB 21663.
• CVE-2004-0408 — Buffer overflow in the child_service routine of the ident2 daemon, exploitable for remote code execution (Debian DSA-494).
• CVE-2019-12647 — NULL-pointer dereference in the Ident protocol handler of Cisco IOS and IOS XE: a crafted request reloads the device, an unauthenticated remote DoS (CVSS 7.5). Proof that an open ident handler isn’t purely a historical problem.
• CVE-2001-0196 — The built-in ident server in FreeBSD 4.x inetd runs with the wrong group, letting a remote attacker read the first 16 bytes of any wheel-readable file (CVSS 5.0). A genuine file-read primitive out of port 113, not just a username leak.
• CVE-1999-0629 — The canonical finding: “the ident/identd service is running.” Rated informational by design, this is the entry scanners like Nessus and OpenVAS emit whenever ident answers, and the correct reference for the username and OS disclosure risk itself.

Mitigation

• Turn it off. There’s no encrypted or hardened version of ident to move to — disable and uninstall identd / oidentd / in.identd, and remove it from inetd/xinetd or its systemd unit. The correct state for port 113 on almost any modern host is closed.
• Reject, don’t drop. If something legitimate still does ident callbacks, configure the firewall to reject port 113 with a TCP RST rather than silently drop it, so a remote MTA or IRC server fails instantly instead of hanging on a timeout. On a FortiGate that’s set ident-accept disable on the interface.
• Never trust ident for authentication. For PostgreSQL, use peer (kernel-verified, local sockets) or a real auth method — never the network ident method that trusts a remote host’s identd. Apply the same rule anywhere ident is used to gate access.
• Restrict it if it must stay. Firewall port 113 to trusted hosts only, and use TCP wrappers (hosts.allow / hosts.deny) or a HIDDEN-USER configuration so the daemon returns minimal information.
• Rescan to confirm. After the change, nmap -p 113 <target> should show the port closed and auth-owners should return nothing.

Real-World Example

The clearest lesson in why port 113 can’t be trusted comes from PostgreSQL. For years it offered an ident authentication method that, over TCP, asked the client’s own identd which user was connecting — and then logged them in as that name. PostgreSQL’s own documentation spells out the flaw: “if the client machine is untrusted or compromised, an attacker could run just about any program on port 113 and return any user name they choose.” Because a user can trivially run a spoofing identd — oidentd has a spoof capability for exactly this — the reply is worthless as proof of identity. In PostgreSQL 9.1 (2011) the project renamed the trustworthy local-socket variant to peer authentication (which reads the user from the kernel, not from an ident reply) precisely to stop people confusing it with the network ident method. It’s the textbook demonstration of RFC 1413’s 1993 warning: ident tells you what a host claims, not what’s true.

FAQ

What is port 113 used for?

Port 113 runs the Ident (Identification Protocol / auth) service defined in RFC 1413. It lets a server ask the machine connecting to it which local OS user owns that TCP connection, originally so multi-user Unix hosts could give servers an audit trail. It runs in cleartext over TCP and is considered obsolete — and unsafe to trust — on modern networks.

Why does nmap show 113/tcp closed ident?

Because many firewalls and appliances deliberately answer port 113 with a TCP reset instead of silently dropping it. That reset is what nmap reports as closed. Vendors do this so that remote mail and IRC servers, which open an ident callback to the connecting client, get an immediate refusal rather than waiting out a 30–60 second timeout. Closed here means the host is reachable and simply isn’t running ident.

Is port 113 dangerous?

Open, it leaks information — valid usernames, the OS name, and which service runs as which user, all of which help an attacker plan the next step. It should also never be used to authenticate anything, since a connecting host can return any username it likes. Some legacy identd builds (TinyIdentD, Fake Identd, ident2) additionally carry remotely exploitable overflows. Treat an exposed port 113 as something to close.

Should I block port 113?

Yes — disable the ident daemon so nothing listens, and have your firewall reject port 113 with a TCP RST rather than drop it, so outbound mail and IRC aren’t delayed by ident callbacks. Then rescan with nmap -p 113 <target> to confirm the port is closed.

TL;DR

• Service: Ident / auth (identd, RFC 1413) — reports which OS user owns a TCP connection
• Default port: 113/TCP, cleartext
• Biggest risk: username and service-owner disclosure that feeds later attacks, no trustworthiness for authentication, and exploitable legacy daemons (TinyIdentD / Fake Identd RCE)
• Mitigation: disable identd, and reject (RST) rather than drop port 113 at the firewall so mail and IRC don’t hang