Linux Certif

Toute la documentation sur la certification Linux LPI

slidentd

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 RFC-compliant, 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?