A while ago, I became unsatisfied with pidentd, the RFC 1413 daemon that ships with many Linux distributions. My objections stemmed mainly from what I see as the incredible level of overengineering and unnecessary "feature"-led complexity that has been built into what should (IMO) be a very simple piece of software. I was also unhappy with the level of information that is given out by the standard configuration of pidentd. As such, I decided to write my own.
Ident (RFC 1413) is a protocol which can be used to discover or reveal which user owns a specific tcp port connection. For example: if I (user "sean") connect from port 1099 on a.mx.uncarved.com to port 25 at a.mx.example.org to send mail, that host may make an ident request back to a.mx.uncarved.com to ask which user owns the connection from a.mx.uncarved.com:1099 to a.mx.example.org:25. Because the sysadmin of a.mx.uncarved.com is a cooperative guy, he runs an ident daemon that volunteers that user "sean" is the owner of the connnection. This information is then logged.
If the sysadmin at a.mx.example.org discovered that the connection had been used in an attempt to exploit a security hole in their mail daemon, they could ask the sysadmin at a.mx.uncarved.com to take action against that user.
The ident protocol is not intended as a means of authentication, but rather as a tool by means of which systems administrators of good will are able to cooperate to resolve network abuse issues. The protocol itself is not able to provide strong evidence of the perpetrator of abuse, however, it can back up other evidence, or be used as a clue to track down problems caused by local users attacking remote sites. Difficulties arise because the level of disclosure of sensitive local information that forms part of this transaction is usually higher than the security-conscious sysadmin would like to disclose. By pointing judicious ident requests at many sites, black hat is able to discover local user names, operating system and distribution version clues and other information, as well as (often) finding which services are running with root privileges, and are thus the best targets for exploitation. As such, many sysadmins blackhole ident requests and/or simply disable ident altogether.
There is a way, however, to have the ident protocol work well enough to perform its intended function but still not disclose any useful information to an attacker. It works as follows: In the example above, instead of the ident daemon volunteering that user "sean" owns the connection, it simply sends back a random token. This token is logged on the ident server along with the actual user id who owns the connection. When chasing up the abuse issue, the sysadmin at a.mx.example.org looks in his mail server logs and finds the token that was returned as a result of the ident request. She then contacts the sysadmin at a.mx.uncarved.com about the issue, quoting the token. The uncarved sysadmin can then grep the logs for the token, revealing the user id that owned the connection, and take appropriate action.
A remote attacker , however, gains absolutely no useful information from knowing that the a.mx.uncarved.com mailserver is run by user "c31b817a59d340be4885dce01007723581484496", because obviously, the token does not represent a valid user id, and thus cannot be used as the basis for any kind of attack.
Debian packages of slidentd are available from http://packages.debian.org/slidentd courtesy of Christian Kurz. rpm and srpm packages are also available. Note that to build the rpm you need dietlibc and libowfat installed, but the rpm contains binaries that are statically linked, so you don't need these packages if you simply want to install the rpm. You will need to set up tcpserver, inetd or xinetd by copying one of the sample scripts in the doc directory though.
The first step is to download the current version of slidentd. The latest is version 1.0.0. Next you need to download diet libc and libowfat from www.fefe.de. Actually you don't 100% need diet libc, but its good for you. :)
After building first diet libc and then libowfat, you're ready to configure and build slidentd. First edit 'slid_config.h' and change any settings in there that you don't like. Next, edit the Makefile, making sure your paths for diet libc and libowfat are correct. If you want to use diet libc, make sure that your version of libowfat is built with diet libc as well. Conversely, if your version of libowfat is built with diet libc, you need to build slidentd with diet libc too. In the slidentd makefile, I specify seperate directories for libowfat depending on whether we're attempting a diet libc or a normal libc build. I have a diet libc version of libowfat in /opt/libowfat/lib and a glibc version in /opt/libowfat-glibc/lib. This is very easy to do with a minor change to the libowfat Makefile.
To build normally, do "make". To build a diet libc version, do "make build_mode=diet". There are also shellscripts provided to simplify a normal or a dietlibc build. Simply ensure that the paths in the shellscripts are correct. This will produce a small (less than 20k) statically-linked binary. You then need to do "make install" (probably as root).
To convert to slidentd, you need to first stop your existing ident
daemon, then enable the new one. If you're using tcpserver, a sample "run"
script is supplied. Just edit it and install it as normal. If you're using
inetd or xinetd, you'll need to edit your respective configuration files.
Slidentd doesn't support "wait" mode or anything fancy, so a simple xinetd
configuration might look like this:
...and the corresponding inetd config might be:
socket_type = stream
wait = no
nice = 10
user = nobody
server = /usr/local/sbin/slidentd
instances = 4
auth stream tcp nowait.60 nobody /usr/local/sbin/slidentd slidentd
I don't however, use either of these, so please treat them as indicative suggestions only. Some versions of inetd allow you to specify a particular interface to bind the service too, and a group as well as a user. Use one of these if you can.
If you're paranoid (like me), you probably want to add a user to run
slidentd as. If you run it as root, it will chroot() to /usr/share/empty,
which is an empty directory included by some distros specifically for this sort
of thing, and attempt to run as an unprivileged user. If your distribution
doesn't include this directory, you can just create it. If its not there,
slidentd will create a directory under /var/run, chroot into it and delete it,
so it can't be found by other processes. I don't recommend running
slidentd as root, however. If you run slidentd as a non-privileged
user, and you use xinetd or inetd, and you don't use syslog, you will need to
create the logfile for slidentd to use. Do
touch /var/log/slidentd &&
chown nobody.nobody /var/log/slidentd as root
I recommend looking into the iprange-, resource- and rate-limiting features of xinetd and tcpserver if you use them, and be as restrictive as you can. Slidentd answers requests in less than 2 hundredths of a second here (a dual pentium 3), but that doesn't mean that I don't rate-limit connections just in case.
If you use slidentd, please consider joining the slidentd mailing list by sending a message to firstname.lastname@example.org
Slidentd is in use on various sites around the world, including Linux hosts running RedHat, SuSE, and (my favourite) Debian, and has been tested on intel and alpha machines. If you try slidentd, please join the mailing list and let me know how you get on.
This page was written by Sean Hunter
Last modified: Thu Sep 4 07:27:10 UTC 2003