21.9. Auth and identd

Authis a protocol used to identify a remote user that
generated a connection. The protocol is also sometimes referred to as
identd, which is the name of a popular Unix
daemon that implements it. Auth is used with protocols that do not
identify a remote user that is generating a connection. When you make
a connection with one of these protocols, the server you're
talking to makes a connection back to your Authserver to get the information. For instance, HTTP requests
don't include information about the user that made the request,
so HTTP servers may use Auth to try to get that information to make
log files more useful. SMTP and IRC requests do include information
about the user, but that information is directly controlled by the
user, who might be lying, so SMTP and IRC servers often use
Auth to attempt to get more trustworthy
information. Both attackers and network administrators also use Auth
for more general information-gathering purposes.

Auth is really useful only if you can trust the remote server. If the
people who're trying to lie to you control the Authserver, you're not going to get good information out
of it. This means that Auth information may be interesting, but
it's rarely trustworthy.

Furthermore, the information that normal Authservers give out is information that's useful to
attackers. The standard implementations of Authsimply give out usernames, and you don't want
attackers to know what usernames are valid at your site. Some
versions of identd and other Auth servers give
out a unique per-user value that is not the username. This is useful
to HTTP servers (all they want to know is how many different people
are talking to them) and can be useful in tracking back attacks (if
you log the value, an administrator at the attacking site can connect
it to a username). It can be annoying for SMTP and IRC, which will
normally display the value for human beings to look at.

[145]ACK is not set on the first packet of this
type (establishing connection) but will be set on the rest.

We do not recommend discarding packets to port 113. If you choose not
to permit this protocol, we suggest that you reject the packets with
an error response or reset the connection. If you drop packets, you
will experience delays when connecting to sites that insist on
performing Auth lookups, and this may significantly slow down your
electronic mail in particular. See Chapter 8, "Packet Filtering", for
more information about ways of responding to packets that you do not
wish to accept.

21.9.2. Proxying Characteristics of Auth

A number of Auth proxy servers are available, mostly designed to let
people use IRC servers that require Auth without giving away too much
information. They are not traditional proxy servers; instead of
proxying for internal clients, allowing them to make outbound Auth
queries, they proxy for external clients, allowing them to make
inbound Auth queries. Furthermore, they rarely complete the proxying
process by forwarding the queries to the internal host, but reply to
the queries immediately, usually with randomly chosen information.

For instance, Microsoft Proxy Server includes a service called
"Identd Simulation service" that responds to Auth queries
with randomly chosen identifiers. This sort of service is preferable
to genuine proxying of Auth queries, which would leak information you
probably do not want external hosts to have.

21.9.3. Network Address Translation Characteristics of Auth

Auth does not use embedded IP addresses, but it
does contain port numbers. Auth will work transparently through
network address translation systems, as long as they are changing
only the host address and not the port number. On the other hand,
Auth connections usually go in the opposite direction from the
connections that caused them. That is, an outgoing SMTP or IRC
connection will result in an inbound Auth connection; if the network
address translation system is mapping ports instead of entire hosts,
there will be no mapping for that inbound translation. You may
therefore need to do special mappings to get Auth to work. For
instance, you may want to direct all inbound Auth connections,
regardless of their original destination, to an Auth proxy.

21.9.4. Summary of Recommendations for Auth

Do not allow Auth through your firewall, but answer Auth queries with
ICMP errors or TCP resets rather than simply dropping them, in order
to speed up connections to servers that use Auth.

If you decide to run an Auth server, choose one that does not return
valid usernames.