slidentd(8)
NAME
slidentd - a minimal RFC 1413 auth server
SYNOPSIS
slidentd
DESCRIPTION
slidentd was designed as a lightweight alternative to the more conventional pidentd. It does not give out any usernames or ids or system
information to the caller, but simply returns a random token. This
token corresponds with a log entry which logs the actual UID that owns
the port in the request. It handles a single connection and terminates, doing no pre-forking and not implementing any configurable behaviour. It is designed to run without root privilege, and does not
need it. However, if it has root privilege, it chroot's to
/usr/share/empty, and sets its uid to an unprivileged user.
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:
- /usr/local/bin/tcpserver -Rl0 -u ident -g ident 0 auth /usr/sbin/slidentd
- To run it under xinetd, copy run/xinetd to /etc/xinetd.d/auth and restart xinetd , or copy the following:
- service auth
{ - 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:
auth stream tcp nowait.60 indent /usr/sbin/slidentd slidentd- 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.
CONFIGURATION
At present, configuration possibilities are minimal to say the least.
However, what do you want to configure in an ident server? :) All configuration options are available by editing slid_config.h.
LOGGING
- A sample log snippet might look like this:
- 2001-02-23 20:56:07.341935500 Q [XXX.XXX.XXX.XX] - [33140, 25]
- 2001-02-23 20:56:07.348684500 A [XXX.XXX.XXX.XX] [e4fa32661e74cb140c36b4f9/3a96ce67/551ac] for [33140, 25] UID [506]
- "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:
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, slidentd returns a simple:
0, 0: ERROR: UNKNOWN-ERROR- ...back to the client and logs the real error. This is also fully RFCcompliant, and ensures that an attacker can't get any sensitive information out of errors.
ARGUMENTS FOR AND AGAINST RFC 1413 SERVICES
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.
DENIAL OF SERVICE
The server is designed to be small and correct, and to have as few features as possible. A malicious user could attempt to carry out a
denial of service attack by making large numbers of connections or by
getting slidentd to log large and spurious requests. While some effort
has been made to reduce the likelihood of this, some care should be
taken in the configuration of the service using xinetd or tcpserver to
rate limit connections. Unix has excellent facilities for imposing
resource limits on processes, and I recommend running this daemon using
resource limits.
NOTE ABOUT RFC COMPLIANCE
This server is strictly RFC 1413-compliant except that it does not disclose security-sensitive information by default and it is not possible
to configure it such that it does this. If this is a problem for you,
please use a more conventional identd (such as honest_identd)
NOTE ABOUT INSECURE NETWORK SERVICES
If you need to access broken hosts or services which authenticate based
on a clear-text username, honest_identd is now provided for that purpose. It returns cleartext usernames, and is thus insecure. However,
by running it, you are doing system crackers a _big_ favour.
SEE ALSO
honest_identd (8)
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
AUTHOR
slidentd is free software written by Sean Hunter <sean@uncarved.com>
- 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?