This is the README file for the slidentd package.

To build slidentd at the moment, you just type "make" and "make install".  It
only works on linux at the moment, as the tcptable guts are system specific.
They could (and should) be reasonably ported to other unix systems and I'll
happily consider patches which do this, especially to the BSD family of
systems.  To build using dietlibc, do "make build_mode=diet all install" or
similar.

Join the slidentd list by sending mail to slidentd-subscribe@uncarved.com

slidentd is a minimal ident (RFC1413) daemon.  It is similar in purpose to
pidentd, which is installed with most linux systems, however its design goals
are somewhat different.  I wrote slidentd because I wanted a very small, simple
daemon that would not give out any sensitive information.  In this regard it is
not RFC compliant (RFC 1413 requires the daemon to be insecure by default).

I assume that if you want to give out the names of users on your system to all
and sundry, you will use pidentd (or some other package).  This is a bad idea,
because crackers will use this information to ascertain which daemons are
running as root so as to concentrate resources at them.

Note that any sensible person will have grave reservations about the usefulness
of the information provided by the ident protocol.  In particular, if you use
it for authorisation, you are guilty of serious error.  I feel that the ident
protocol is somewhat more useful in providing forensic data, although again, it
is not strongly authenticated and can easily be spoofed.  If you can no longer
use an insecure network app after installing slidentd, consider running
honest_identd (part of this package) or pidentd instead.  Note that this means
you will be giving out usernames, which is a serious security compromise.

This quote from the RFC bears repeating:

   "The Identification Protocol is not intended as an authorization or
   access control protocol.  At best, it provides some additional
   auditing information with respect to TCP connections.  At worst, it
   can provide misleading, incorrect, or maliciously incorrect
   information.
     
   The use of the information returned by this protocol for other than
   auditing is strongly discouraged.  Specifically, using Identification
   Protocol information to make access control decisions - either as the
   primary method (i.e., no other checks) or as an adjunct to other
   methods may result in a weakening of normal host security."

The rfc is supplied in its entirety with this package for your convenience.

The process used in slidentd is that the daemon returns an obscure cookie,
while logging the real data.  This means that the sysadmin can follow up
requests from remote sites by grepping through the logs for the cookie.  As
long as the logs are secure (users cannot write to them), you should be able to
see which user id owned any port connection that resulted in a remote site
issuing an ident query.  This should be enough for audit purposes.

I run slidentd under Dan Bernstein's daemontools, and suggest that, if you are
happy with the terms of Dan's software licensing, you consider doing the same.
slidentd also runs under xinetd and inetd.  I've heard good rumours about g2s,
though.

A sample run script is supplied for those who would like to try running slidentd
under tcpserver.  A suitable xinetd configuration is also supplied.

To run slidentd (or honest_identd) under inetd, add a line like this to your
/etc/inetd.conf and HUP the daemon:

auth    stream  tcp     nowait.60       nobody /usr/sbin/slidentd slidentd

If run as root, slidentd drops user privilege, and chroots to
"/usr/share/empty", which is an empty directory that is for this sort of thing.
(If this directory is not supplied with your distribution, just create it with
root ownership and mode 555.)  Alternatively, edit the path in slid_config.h.
If /usr/share/empty is not available, slidentd creates an empty directory,
chroots to it, then deletes it.  It also sets itself to a non-privileged user.
Having said that, it doesn't need root privaleges, and you shouldn't run it as
root anyway.

"slid_config.h" contains all user-servicable tweakables.

slidentd will log to syslog if SLIDENT_USE_SYSLOG is defined in slid_config.h.
I have made an effort to ensure that the syslog logging is safe from format
problems but this still requires auditing.  I do not use openlog(3) or
syslog(3), but basically directly open the syslog device, and use write(2).
Otherwise, if running under tcpserver, it logs to stderr because it assumes
you're doing the whole Bernstein thing and will be using multilog. If neither
of these two methods works, it logs to /var/log/slidentd (path configurable in
slid_config.h, of course).

A snippet from my log looks like this:

2001-02-23 20:56:07.341935500 Q [192.168.147.30] - [33140, 25]
2001-02-23 20:56:07.348684500 A [192.168.147.30] - [e4fa32661e74cb140c36b4f9/3a96ce67/551ac] for [33140, 25] UID [506]

"Q" lines are "Questions". "A" lines are answers. On a "Q" line, the bit after
the dash records the auth request in its native form (see how complex this
protocol is?  I'll bet you're glad I wrote the daemon for you!). The ip address
just after the Q or A is the remote auth client. So here 192.168.147.30 is
asking who owns the process that is connecting from port 33140 on my host to
his mail port. The "A" line has the response I sent
(e4fa32661e74cb140c36b4f9/3a96ce67/551ac), and the actual data (the connection
from me:33140 to 192.168.147.30:25 was owned by UID 507. Note that although I
have done nothing to try to speed up the daemon, the request took about 7
thousandths of a second to process. :)

The response is fully RFC-compliant, and thus the full response that the
client actually got would be:

33140, 25: USERID: OTHER: e4fa32661e74cb140c36b4f9/3a96ce67/551ac

As you can see, it doesn't give any clues about username or os.

In the case of any error, I give a simple:

0, 0: ERROR: UNKNOWN-ERROR

...back to the client and log the real error. This is also fully
RFC-compliant, and ensures that they can't get any info out of errors.

The log might look like this:

....

2001-06-07 09:55:15.371057500 Q [127.0.0.1] - [40558, 113]
2001-06-07 09:55:15.383126500 A [127.0.0.1] - [35c7a178cefe4e98f34687fe/3b1f4173/5ca12] for [40558, 113] UID [500]
2001-06-07 09:56:09.396631500 Q [127.0.0.1] - [1234, 113]
2001-06-07 09:56:09.407642500 A [127.0.0.1] ERROR - Unable to match port pair
2001-06-07 10:05:07.194450500 A [127.0.0.1] ERROR - Invalid char 0x72 detected in input stream.

In certain error cases, I don't log the request, because they might be trying
to do a buffer overflow etc. This is why there is no apparent "Q" line
corresponding to the last "A".  This is configurable by changing the
SLID_LOG_BADINPUT value in slid_config.h

honest_identd works in much the same way except that it returns the actual
username instead of the random cookie.  The less said about that, the better.

The source code is intended to be easily reusable, and contains various bits
that might be happily nicked by people interested in parsing the kernel
tcptable, reading the random devices, and other stuff.  I'd be interested to
know if it comes in handy to anyone in this way.

Finally, the server is very fast, and I don't do any rate limiting. If this
worries you, you should connection limit in your tcpserver or xinetd config to
prevent DoS. I use some iptables rules to back this rate limiting up.  I
have never seen this sort of DoS attempted, although I have seen many
others.  Remember that just because you're paranoid doesn't mean they aren't
actually out to get you.

Please note that although I have been using slidentd on my sites for some time
without any problems this is no guarantee that it will work for you.  This is
all part of life's rich tapestry, and absolutely definitely not my fault.

Please let me know how you get on.

Sean Hunter <sean@uncarved.com>

P.S.  This ident daemon was previously known as "midentd".  It was renamed to
avoid clashes with another ident daemon called "midentd"
