NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: bin/42540: /usr/bin/login does not log normal logins, does not log IP addresses

The following reply was made to PR bin/42540; it has been noted by GNATS.

From: Ed Ravin <>
Subject: Re: bin/42540: /usr/bin/login does not log normal logins, does not
        log IP addresses
Date: Tue, 29 Dec 2009 11:30:25 -0500

 On Tue, Dec 29, 2009 at 03:45:03PM +0000, Christos Zoulas wrote:
 >  | 1.  /usr/bin/login does not seem to generate syslog messages for
 >  | normal, successful logins.  syslog messages are only produced in
 >  | case of error, in case of root login, and a few other special cases.
 >  Yes, that is the historical behavior.
 Indeed it is, but modern operating systems need to keep audit trails.
 And some shops won't even allow deployments of operating systems that
 can't be audited for login/logout events.
 >  | 2. When /usr/bin/login does generate syslog messages regarding
 >  | remote connections, it uses the looked-up hostname, not the IP
 >  | address. The IP address is needed since the results of DNS lookups
 >  | can change over time and are not a reliable way to audit which
 >  | hosts are connecting to you,
 >  Yes, because it is only being passed in the hostname; it does not
 >  lookup anything. Even the hostname passed can be bogus (although
 >  one presumes that the daemon that forks login is trusted).
 The daemon is trusted, but the DNS is not - a malicious network
 operator could create a false DNS entry, telnet to the NetBSD
 host, then change it back.  When the operator of the NetBSD system
 reviews the logs, the hostname found in the log will not point to
 the IP address that originated the telnet session.  There are also
 non-malicious cases where DNS could change after the telnet session
 is over.
 >  So your desired behavior is to use getpeername(2) to determine if
 >  the login is remote and always syslog(LOG_INFO the infomation?
 My desired behavior is to have a reliable audit trail of logins that
 include the username and, for remote logins, the IP address they logged
 in from.
 I believe the same issue occurs when rlogind calls /usr/bin/login.
 Also, I see there's a "-a IP-address" option to /usr/bin/login that
 might be useful if telnetd/rlogind used it when invoking login.
        -- Ed

Home | Main Index | Thread Index | Old Index