Home / server / Questions / 787516
Accepted
IAmJulianAcosta
Asked: 2016-07-02 20:19:51 +0800 CST

Is /var/log/auth.log incomplete a symptom of unauthorized access?

  • 772

Today I found that /var/log/auth.log file only has records from latest week, and I'm suspecting that I was hacked by using an insecure SSH password, and the attacker deleted access logs to avoid detection.

Here are the first lines in the log:

Jun 26 06:44:58 server CRON[14297]: pam_unix(cron:session): session closed for user root Jun 26 06:47:01 server CRON[14484]: pam_unix(cron:session): session opened for user root by (uid=0) Jun 26 06:47:02 server CRON[14484]: pam_unix(cron:session): session closed for user root Jun 26 07:17:01 server CRON[14515]: pam_unix(cron:session): session opened for user root by (uid=0) Jun 26 07:17:01 server CRON[14515]: pam_unix(cron:session): session closed for user root Jun 26 08:17:01 server CRON[14518]: pam_unix(cron:session): session opened for user root by (uid=0) Jun 26 08:17:01 server CRON[14518]: pam_unix(cron:session): session closed for user root Jun 26 09:17:01 server CRON[14521]: pam_unix(cron:session): session opened for user root by (uid=0) Jun 26 09:17:01 server CRON[14521]: pam_unix(cron:session): session closed for user root Jun 26 10:17:01 server CRON[14524]: pam_unix(cron:session): session opened for user root by (uid=0) Jun 26 10:17:01 server CRON[14524]: pam_unix(cron:session): session closed for user root Jun 26 11:17:01 server CRON[14527]: pam_unix(cron:session): session opened for user root by (uid=0) Jun 26 11:17:01 server CRON[14527]: pam_unix(cron:session): session closed for user root Jun 26 12:17:01 server CRON[14530]: pam_unix(cron:session): session opened for user root by (uid=0) Jun 26 12:17:01 server CRON[14530]: pam_unix(cron:session): session closed for user root Jun 26 13:16:29 server login[1022]: pam_unix(login:auth): check pass; user unknown Jun 26 13:16:29 server login[1022]: pam_unix(login:auth): authentication failure; logname=LOGIN uid=0 euid=0 tty=/dev/tty1 ruser= rhost= Jun 26 13:16:32 server login[1022]: FAILED LOGIN (1) on '/dev/tty1' FOR 'UNKNOWN', Authentication failure Jun 26 13:17:01 server CRON[14533]: pam_unix(cron:session): session opened for user root by (uid=0) Jun 26 13:17:01 server CRON[14533]: pam_unix(cron:session): session closed for user root Jun 26 13:17:09 server login[1022]: pam_unix(login:auth): authentication failure; logname=LOGIN uid=0 euid=0 tty=/dev/tty1 ruser= rhost= user=root Jun 26 13:17:13 server login[1022]: FAILED LOGIN (2) on '/dev/tty1' FOR 'root', Authentication failure Jun 26 13:17:18 server login[1022]: FAILED LOGIN (3) on '/dev/tty1' FOR 'root', Authentication failure Jun 26 13:17:23 server login[1022]: pam_unix(login:auth): authentication failure; logname=LOGIN uid=0 euid=0 tty=/dev/tty1 ruser= rhost= user=vagrant Jun 26 13:17:34 server login[14536]: pam_unix(login:auth): authentication failure; logname=LOGIN uid=0 euid=0 tty=/dev/tty1 ruser= rhost= user=vagrant Jun 26 13:17:36 server login[14536]: FAILED LOGIN (1) on '/dev/tty1' FOR 'vagrant', Authentication failure

Is this normal? Should this be complete?

ubuntu logging ssh

1 Answers

  1. Best Answer

    The answer to your question depends on the log rotation you have configured. By default Ubuntu is configured to rotate the log files, so you should see files resembling the following in /var/log

    auth.log
auth.log.1
auth.log.2.gz
auth.log.3.gz
auth.log.4.gz

    The first file (auth.log) is the current log, with auth.log.1 being the older entries and auth.log.2.gz being even older entries compressed with gz. The larger the number the further in the past the log entries are.

    You can check your log rotation settings by viewing /etc/logrotate.d/rsyslog, which on Ubuntu 14.04 contains a section like this:

    /var/log/mail.info
...
/var/log/kern.log
/var/log/auth.log
/var/log/user.log
...
/var/log/messages
{
        rotate 4
        weekly
        missingok
        notifempty
        compress
        delaycompress
        sharedscripts
        postrotate
                reload rsyslog >/dev/null 2>&1 || true
        endscript
}

    Where the first line indicates 4 old versions should be kept, and the next sets them to be rotated weekly.

    If your log rotation is the same, you can expect the auth.log file to be rotated (renamed to auth.log.1) every week. Have a look at the auth.log.1 log and be sure it's most recent entries follow the oldest entries in auth.log. If this is the case you appear to have a continuous log and things are operating in a "normal" manner (with logs being rotated as expected).

    Regarding the security of the logs, the modified date of the log files should not be newer than the most recent log entry in that file, or the date it was compressed. If you see logs from weeks or months ago having been modified in the past few days this is a warning sign.

    Mainly, do the contents of the logs make sense? Do the login times match those used by administrators or other users who have access? For someone who had root login disabled, your logs would be quite troubling - but this activity may be normal for your system.

    Note: Having "continuous" log entries from auth.log to auth.log.1 (and so on) does not mean your server is secure. The attacker would likely only removed entries related to their activities - not remove a big section making their intrusion obvious. If you have concerns about security you should check for rootkits and other malicious software and unusual activities.

    • 1