README.wtmp.txt
$Id: README.wtmp,v 1.3 1999/03/25 21:43:55 crowland Exp crowland $ Why Unix login accounting stinks. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Most all Unix systems ship with basic accounting facilities for logins. Usually these take the form of wtmp/utmp files or wtmpx/utmpx files. For the most part these files contain the following information (for utmp/wtmp): Login Name Login TTY Login Time Login Host The problem is that these fields are rarely consistent between platforms. Indeed even if you are running Linux you may find that one version uses an extended format, one version uses the shorter BSD style format, and others may use something altogether strange. The real issue for a tool such as HostSentry is the length of the host field for fully qualified domain names (FQDN). On many systems (particularly BSD variants), the ut_host record in the structure ranges in length from 16-32 bytes. Not a big deal you say? Well there are conflicting indicators of how long the RFC FQDN spec is. If you read RFC 1034 it states that a FQDN is limited to 255 characters[1] but if you read the arpa/nameser.h you'll see that MAXDNAME is defined to contain a max length of 1025 (1024 bytes plus null).[2] So who is right and who is wrong? I simply don't know. The RFC implies one thing but the BIND implementation implies another. One thing is for certain though, a FQDN space of 16-32 characters is grossly inaccurate and certainly wouldn't conform to the RFC spec no matter what interpretation is used. What this means is that, as an attacker, I can come from a host with a very long host name and most *BSD accounting records will truncate the entry. When you log out the admin will have a hard time using these records to deduce where you came from (assuming they don't use the syslog entries). Consider the following: reallyreallyreallreallyreallylonghostname.example.com Is truncated to the following in your audit records: reallyreallyreallyr Now does this make sense for an audit record to do?? Why do some versions of Unix second-guess what the RFC's say is the max allowed domain name length? I can only assume this is a legacy issue, but regardless I feel it is terribly broken and needs to be fixed. The result =-=-=-=-=- The result of this inconsistency for HostSentry is that some records provide enough information for modules such as moduleForeignDomain to work reliably. Other systems (such as most BSD variants) have this entry entirely too short and results may be spotty. Because the records are truncated it also means that an attacker logging into your site with a hostname longer than 16 characters (which is fairly common in todays world of DHCP issued addresses), will have reduced auditing capability. What to fix =-=-=-=-=-= I don't have all the answers, but I have some suggestions. Some OS's like Solaris and SCO use an extended format and call the files utmpx/wtmpx. These extended formats include the correct FQDN length and in some cases other useful data. On some Linux builds they use an extended utmp struct (utmpbits.h) that not only includes a correct FQDN length, but also the IP address of the remote end. This may seem redundant, but with the increased possibility of DNS tampering today it is nice to have the real address of the host along with the fully qualified domain name. So what are my specific recommendations?: 1) ut_host needs to be the RFC spec length. 2) The IP address of the host should be in each record. 3) ut_user needs to be the same length as the allowable username length of the operating system (I haven't checked on this, but it is possible that this is also a problem on some OS's). 4) Login timestamp should always be included. 5) Login TTY should always be included. Most of the criteria are already met with the exception of points 1 and 2. There are some other things I'd like to see to detect tampering and such, but they are outside the scope of this document. -- Craig [1] - RFC 1034 Section 3.1. [2] - Pointed out to me by Theo DeRaadt in private e-mail.