This server is designed to run from Dan Bernstein's tcpserver. It works with inetd and xinetd as well. It handles a single request and then terminates, does not fork and does not provide any "standalone" or "wait" modes, as these are believed by the author to be unneeded complexity for something as humble as an ident daemon.
To run it under tcpserver, use a command such as:
To run it under xinetd, copy run/xinetd to /etc/xinetd.d/auth and restart xinetd , or copy the following:
socket_type = stream
wait = no
nice = 10
user = ident
server = /usr/sbin/slidentd
instances = 4
To run under inetd, insert the following line (or something similar) into your /etc/inetd.conf:
These assume you will be using a user called "ident" and that user has already been added to your system.
If running under tcpserver, the server logs to stderr because it assumes you're using multilog or something similar to log messages. Otherwise, it logs (by default) to /var/log/slidentd. The location is configurable by editing slid_config.h. Please note that if you aren't running the daemon as root it may not have permissions to create the file. If that is the case, touch the file as root, and chown it to belong to the user slidentd is running as. Since version 0.0.13, slidentd has been able to be configured to use syslog, which avoids this sort of tedium.
"Q" lines are "Questions", and "A" lines are answers. On a "Q" line, the bit after the dash records the auth request in its native form. The ip address just after the Q or A is the remote auth client. This is obscured here to protect the innocent. So here XXX.XXX.XXX.XX is asking who owns the process that is connecting from port 33140 on this server host to his mail port. The "A" line has the response this server sent (e4fa32661e74cb140c36b4f9/3a96ce67/551ac), and the actual data (the connection from port 33140 here to port 25 there 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:
As you can see, it doesn't give any clues about username or os.
In the case of any error, slidentd returns a simple:
...back to the client and logs the real error. This is also fully RFC-compliant, and ensures that an attacker can't get any sensitive information out of errors.
The protocol standard as defined in RFC 1413 is extremely open with sensitive system information. By default, RFC-compliant auth servers are supposed to give out user names, operating system details, and various helpful error messages that can assist a patient attacker in their attempts to gather information about the auth server system. A standard auth request and its response can be used to determine which system daemons are running as root, and therefore where black hat should target his cracking attempts to best effect. User names or ids are also valuable in providing ammunition for password-cracking efforts.
In addition, the information supplied by auth requests is also frequently abused as a means of authentication, in spite of stern warnings in the RFC about the dangers of this practise. Anyone with control over a network-attached computer can fake these credentials and circumvent auth-based access controls.
With this in mind, why would anyone run auth servers or make auth requests? The reason, I run these services is for post-hoc audit purposes. Slidentd works very well for this.
If my ftp server makes auth requests and records the results, and a foreign user tries to abuse my ftp system, I can contact the admin of his or her site and they can use the auth information to track down the user responsible. Similarly, if a foreign admin wishes to complain about one of my users, they can use the information supplied by my auth server to enable me to track the person down.
slidentd performs this function without giving out sensitive information about my site to others.
http://www.faqs.org/rfcs/rfc1413.html for the text of RFC 1413,
http:/cr.yp.to/ucspi-tcp/tcpserver.html for Dan Bernstein's "tcpserver"
http://www.fefe.de for Felix von Leitner's libowfat and dietlibc
It is distributed under the terms of the Gnu Lesser General Public License in the hope that it will be useful to somebody else. The author explicitly disclaims all warrantees expressed or implied, regarding this software package, or any other matter, real or imagined. In fact you didn't even read this, right?