21.9. Auth and identdAuth is 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 Auth server 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 Auth server, 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 Auth servers give out is information that's useful to attackers. The standard implementations of Auth simply 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.
21.9.1. Packet Filtering Characteristics of AuthAuth is a TCP-based service. Servers use port 113. Clients use ports above 1023.
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 AuthA 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 AuthAuth 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
Copyright © 2002 O'Reilly & Associates. All rights reserved.