Unlocking System Security: Mastering Login Logging and Syslog Configuration

Unlocking System Security: Mastering Login Logging and Syslog Configuration

Unlocking System Security: Mastering Login Logging and Syslog Configuration - This chapter covers three main topics:

Firstly, it delves into login logging, focusing on identifying who is accessing the system, when, and from where. It also addresses failed login attempts, whether through 'su' or 'ssh'.

Secondly, it discusses configuring the syslog daemon and testing it using the 'logger' tool.

Lastly, it explores log rotation and introduces commands like 'tail -f' and 'watch' for real-time log monitoring.

login logging

In Linux, login activities are recorded in files such as /var/log/wtmp, /var/log/btmp, /var/run/utmp, and /var/log/lastlog. These files maintain records of user logins, failed login attempts, and system reboots.

/var/run/utmp (who)

Use the who command to see the /var/run/utmp file. This command shows you all the currently logged-in users. Notice that the utmp file is in /var/run and not in /var/log.

[root@rhel4 ~]# who
paul pts/1 Feb 14 18:21 (192.168.1.45)
sandra pts/2 Feb 14 18:11 (192.168.1.42)
inge pts/3 Feb 14 12:01 (192.168.1.33)
els pts/4 Feb 14 14:33 (192.168.1.19)

/var/log/wtmp (last)

The /var/log/wtmp file is updated by the login program. Use last to see the /var/run/wtmp file.

[root@rhel4a ~]# last | head
paul pts/1 192.168.1.45 Wed Feb 14 18:39 still logged in
reboot system boot 2.6.9-42.0.8.ELs Wed Feb 14 18:21 (01:15)
nicolas pts/5 pc-dss.telematic Wed Feb 14 12:32 - 13:06 (00:33)
stefaan pts/3 pc-sde.telematic Wed Feb 14 12:28 - 12:40 (00:12)
nicolas pts/3 pc-nae.telematic Wed Feb 14 11:36 - 12:21 (00:45)
nicolas pts/3 pc-nae.telematic Wed Feb 14 11:34 - 11:36 (00:01)
dirk pts/5 pc-dss.telematic Wed Feb 14 10:03 - 12:31 (02:28)
nicolas pts/3 pc-nae.telematic Wed Feb 14 09:45 - 11:34 (01:48)
dimitri pts/5 rhel4 Wed Feb 14 07:57 - 08:38 (00:40)
stefaan pts/4 pc-sde.telematic Wed Feb 14 07:16 - down (05:50)
[root@rhel4a ~]#

The last command can also be used to get a list of last reboots.

[paul@rekkie ~]$ last reboot
reboot system boot 2.6.16-rekkie Mon Jul 30 05:13 (370+08:42)

wtmp begins Tue May 30 23:11:45 2006
[paul@rekkie ~]

/var/log/lastlog (lastlog)

Use lastlog to see the /var/log/lastlog file.

[root@rhel4a ~]# lastlog | tail
tim pts/5 10.170.1.122 Tue Feb 13 09:36:54 +0100 2007
rm pts/6 rhel4 Tue Feb 13 10:06:56 +0100 2007
henk **Never logged in**
stefaan pts/3 pc-sde.telematic Wed Feb 14 12:28:38 +0100 2007
dirk pts/5 pc-dss.telematic Wed Feb 14 10:03:11 +0100 2007
arsene **Never logged in**
nicolas pts/5 pc-dss.telematic Wed Feb 14 12:32:18 +0100 2007
dimitri pts/5 rhel4 Wed Feb 14 07:57:19 +0100 2007
bashuserrm pts/7 rhel4 Tue Feb 13 10:35:40 +0100 2007
kornuserrm pts/5 rhel4 Tue Feb 13 10:06:17 +0100 2007
[root@rhel4a ~]#

/var/log/btmp (lastb)

There is also the lastb command to display the /var/log/btmp file. This file is updated by the login program when entering the wrong password, so it contains failed login attempts.

Many computers will not have this file, resulting in no logging of failed login attempts.

[root@RHEL4b ~]# lastb
lastb: /var/log/btmp: No such file or directory
Perhaps this file was removed by the operator to prevent logging lastb\
info.
[root@RHEL4b ~]#

The reason given for this is that users sometimes type their password by mistake instead of their login, so this world-readable file poses a security risk. You can enable bad login logging by simply creating the file. Doing a chmod o-r /var/log/btmp improves security.

[root@RHEL4b ~]# touch /var/log/btmp
[root@RHEL4b ~]# ll /var/log/btmp
-rw-r--r-- 1 root root 0 Jul 30 06:12 /var/log/btmp
[root@RHEL4b ~]# chmod o-r /var/log/btmp
[root@RHEL4b ~]# lastb
btmp begins Mon Jul 30 06:12:19 2007
[root@RHEL4b ~]#

Failed logins via ssh, rlogin, or su are not registered in /var/log/btmp. Failed logins via tty are.

[root@RHEL4b ~]# lastb
HalvarFl tty3 Mon Jul 30 07:10 - 07:10 (00:00
Maria tty1 Mon Jul 30 07:09 - 07:09 (00:00)
Roberto tty1 Mon Jul 30 07:09 - 07:09 (00:00)
btmp begins Mon Jul 30 07:09:32 2007
[root@RHEL4b ~]#

su and ssh logins

Depending on the distribution, you may also have the /var/log/secure file being filled with messages from the auth and/or authpriv Syslog facilities. This log will include su and/or ssh failed login attempts. Some distributions put this in /var/log/auth.log, and verify the syslog configuration.

[root@RHEL4b ~]# cat /var/log/secure
Jul 30 07:09:03 sshd[4387]: Accepted publickey for paul from ::ffff:19\
2.168.1.52 port 33188 ssh2
Jul 30 05:09:03 sshd[4388]: Accepted publickey for paul from ::ffff:19\
2.168.1.52 port 33188 ssh2
Jul 30 07:22:27 sshd[4655]: Failed password for Hermione from ::ffff:1\
92.168.1.52 port 38752 ssh2
Jul 30 05:22:27 sshd[4656]: Failed password for Hermione from ::ffff:1\
92.168.1.52 port 38752 ssh2
Jul 30 07:22:30 sshd[4655]: Failed password for Hermione from ::ffff:1\
92.168.1.52 port 38752 ssh2
Jul 30 05:22:30 sshd[4656]: Failed password for Hermione from ::ffff:1\
92.168.1.52 port 38752 ssh2
Jul 30 07:22:33 sshd[4655]: Failed password for Hermione from ::ffff:1\
92.168.1.52 port 38752 ssh2
Jul 30 05:22:33 sshd[4656]: Failed password for Hermione from ::ffff:1\
92.168.1.52 port 38752 ssh2
Jul 30 08:27:33 sshd[5018]: Invalid user roberto from ::ffff:192.168.1\
.52
Jul 30 06:27:33 sshd[5019]: input_userauth_request: invalid user rober\
to
Jul 30 06:27:33 sshd[5019]: Failed none for invalid user roberto from \
::ffff:192.168.1.52 port 41064 ssh2
Jul 30 06:27:33 sshd[5019]: Failed publickey for invalid user roberto \
from ::ffff:192.168.1.52 port 41064 ssh2
Jul 30 08:27:36 sshd[5018]: Failed password for invalid user roberto f\
rom ::ffff:192.168.1.52 port 41064 ssh2
Jul 30 06:27:36 sshd[5019]: Failed password for invalid user roberto f\
rom ::ffff:192.168.1.52 port 41064 ssh2
[root@RHEL4b ~]#

You can enable this yourself, with a custom log file by adding the following line tot syslog.conf.

auth.*,authpriv.* /var/log/customsec.log

syslogd

about syslog

The standard method of logging on Linux was through the syslogd daemon. Syslog was developed by Eric Allman for sendmail, but quickly became a standard among many Unix applications and was much later written as RFC 3164. The syslog daemon can receive messages on UDP port 514 from many applications (and appliances) and can append to log files, print, display messages on terminals, and forward logs to other syslogd daemons on other machines. The syslogd daemon is configured in /etc/syslog.conf.

about rsyslog

The new method is called reliable and extended syslogd and uses the rsyslogd daemon and the /etc/rsyslogd.conf configuration file. The syntax is backward compatible.

Each line in the configuration file uses a facility to determine where the message is coming from. It also contains a priority for the severity of the message, and an action to decide on what to do with the message.

modules

The new rsyslog has many more features that can be expanded by using modules. Modules allow for example exporting of syslog logging to a database. 

See the manuals for more information (when you are done with this chapter).

root@rhel65:/etc# man rsyslog.conf
root@rhel65:/etc# man rsyslogd
root@rhel65:/etc#

facilities

The man rsyslog.conf command will explain the different default facilities for certain daemons, such as mail, lpr, news, and kern(el) messages. The local0 to local7 facility can be used for appliances (or any networked device that supports syslog). Here is a list of all facilities for rsyslog.conf version 1.3. The security keyword is deprecated.

auth (security)
authpriv
cron
daemon
ftp
kern
lpr mail
mark (internal use only)
news
syslog
user
uucp
local0-7

priorities

The worst severity a message can have is emerg followed by alert and crit. The lowest priority should go to info and debug messages. Specifying a severity will also log all messages with a higher severity. You can prefix the severity with = to obtain only messages that match that severity. You can also specify .none to prevent a specific action from any message from a certain facility.

Here is a list of all priorities, in ascending order. The keywords warn, error, and panic are deprecated.

debug
info
notice
warning (warn)
err (error)
crit
alert
emerg (panic)

actions

The default action is to send a message to the username listed as action. When the action is prefixed with a / then rsyslog will send the message to the file (which can be a regular file, but also a printer or terminal). The @ sign prefix will send the message to another syslog server. Here is a list of all possible actions.

root,user1 list of users, separated by comma's
* message to all logged on users
/ file (can be a printer, a console, a tty, ...)
-/ file, but don't sync after every write
| named pipe
@ other syslog hostname

In addition, you can prefix actions with a - to omit syncing the file after every logging.

configuration

Below is a sample configuration of custom local4 messages in /etc/rsyslog.conf.

local4.crit /var/log/critandabove
local4.=crit /var/log/onlycrit
local4.* /var/log/alllocal4

restarting rsyslogd

Don't forget to restart the server after changing its configuration.

root@rhel65:/etc# service rsyslog restart
Shutting down system logger: [ OK ]
Starting system logger: [ OK ]
root@rhel65:/etc#

logger

The 'logger' command generates syslog test messages, useful for testing syslog configurations or incorporating into scripts for logging purposes.

You can also use it in scripts. An example of testing syslogd with the logger tool.

[root@rhel4a ~]# logger -p local4.debug "l4 debug"
[root@rhel4a ~]# logger -p local4.crit "l4 crit"
[root@rhel4a ~]# logger -p local4.emerg "l4 emerg"
[root@rhel4a ~]#

The results of the tests with logger.

[root@rhel4a ~]# cat /var/log/critandabove
Feb 14 19:55:19 rhel4a paul: l4 crit
Feb 14 19:55:28 rhel4a paul: l4 emerg
[root@rhel4a ~]# cat /var/log/onlycrit
Feb 14 19:55:19 rhel4a paul: l4 crit
[root@rhel4a ~]# cat /var/log/alllocal4
Feb 14 19:55:11 rhel4a paul: l4 debug
Feb 14 19:55:19 rhel4a paul: l4 crit
Feb 14 19:55:28 rhel4a paul: l4 emerg
[root@rhel4a ~]#

watching logs

You might want to use the tail -f command to look at the last lines of a log file. The -f option will dynamically display lines that are appended to the log.

Commands like 'tail -f' allow users to monitor log files in real-time, displaying appended lines as they are written. The 'watch' command automates repetitive tasks, such as periodically executing commands like 'who' to monitor user activity.

paul@ubu1010:~$ tail -f /var/log/udev
SEQNUM=1741
SOUND_INITIALIZED=1
ID_VENDOR_FROM_DATABASE=nVidia Corporation
ID_MODEL_FROM_DATABASE=MCP79 High Definition Audio
ID_BUS=pci
ID_VENDOR_ID=0x10de
ID_MODEL_ID=0x0ac0
ID_PATH=pci-0000:00:08.0
SOUND_FORM_FACTOR=internal

You can automatically repeat commands by preceding them with the watch command. When executing the following:

[root@rhel6 ~]# watch who

Something similar to this, repeating the output of the who command every two seconds, will appear on the screen.

Every 2.0s: who Sun Jul 17 15:31:03 2011
root tty1 2011-07-17 13:28
paul pts/0 2011-07-17 13:31 (192.168.1.30)
paul pts/1 2011-07-17 15:19 (192.168.1.30)

rotating logs

To manage log file sizes, log rotation is essential. The 'logrotate' utility facilitates this task by compressing, removing, and archiving log files. Configuration for log rotation is specified in files like logrotate.conf and individual configurations can be found in the /etc/logrotate.d/ directory.

Below a screenshot of the default Red Hat logrotate.conf file.

root@rhel65:/etc# cat logrotate.conf
# see "man logrotate" for details
# rotate log files weekly
weekly

# keep 4 weeks worth of backlogs
rotate 4

# create new (empty) log files after rotating old ones
create

# use date as a suffix of the rotated file
dateext

# uncomment this if you want your log files compressed
#compress

# RPM packages drop log rotation information into this directory
include /etc/logrotate.d

# no packages own wtmp and btmp -- we'll rotate them here
/var/log/wtmp {
     monthly
     create 0664 root utmp
         minsize 1M
     rotate 1
}

/var/log/btmp {
     missingok
     monthly
     create 0600 root utmp
     rotate 1
}

# system-specific logs may be also be configured here.
root@rhel65:/etc#

practice : logging

1. Display the /var/run/utmp file with the proper command (not with cat or vi).
2. Display the /var/log/wtmp file.
3. Use the lastlog and lastb commands, understand the difference.
4. Examine syslog to find the location of the log file containing ssh failed logins.
5. Configure syslog to put local4.error and above messages in /var/log/l4e.log and local4.info only .info in /var/log/l4i.log. Test that it works with the logger tool!
6. Configure /var/log/Mysu.log, all the su to root messages should go in that log. Test that it works!
7. Send the local5 messages to the syslog server of your neighbour. Test that it works.
8. Write a script that executes logger to local4 every 15 seconds (different message). Use tail -f and watch on your local4 log files.

solution : logging

1. Display the /var/run/utmp file.

who

2. Display the /var/log/wtmp file.

last

3. Use the lastlog and lastb commands, understand the difference.

lastlog : when users last logged on

lastb: failed (bad) login attempts

4. Examine syslog to find the location of the log file containing ssh failed logins.

Answer depends on whether you machine uses syslog or rsyslog (newer).

[root@rhel53 ~]# grep authpriv /etc/syslog.conf
authpriv.* /var/log/secure

[root@rhel71 ~]# grep ^authpriv /etc/rsyslog.conf
authpriv.* /var/log/secure

paul@debian8:~$ grep ^auth /etc/rsyslog.conf
auth,authpriv.* /var/log/auth.log

5. Configure syslog to put local4.error and above messages in /var/log/l4e.log and local4.info only .info in /var/log/l4i.log. Test that it works with the logger tool!

With syslog:

echo local4.error /var/log/l4e.log >> /etc/syslog.conf
echo local4.=info /var/log/l4i.log >> /etc/syslog.conf
service syslog restart

With rsyslog:

echo local4.error /var/log/l4e.log >> /etc/rsyslog.conf
echo local4.=info /var/log/l4i.log >> /etc/rsyslog.conf
service rsyslog restart

On both:

logger -p local4.error "l4 error test"
logger -p local4.alert "l4 alert test"
logger -p local4.info "l4 info test"
cat /var/log/l4e.log
cat /var/log/l4i.log

6. Configure /var/log/Mysu.log, all the su to root messages should go in that log. Test that it works!

echo authpriv.* /var/log/Mysu.log >> /etc/syslog.conf

This will log more than just the su usage.

7. Send the local5 messages to the syslog server of your neighbour. Test that it works.

On RHEL5, edit /etc/sysconfig/syslog to enable remote listening on the server.

On RHEL7, uncomment these two lines in /etc/rsyslog.conf to enable 'UDP syslog

reception'.

# Provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514

On Debian/Ubuntu edit /etc/default/syslog or /etc/default/rsyslog.

on the client: logger -p local5.info "test local5 to neighbour"

8. Write a script that executes logger to local4 every 15 seconds (different message). Use tail -f and watch on your local4 log files.

root@rhel53 scripts# cat logloop
#!/bin/bash

for i in `seq 1 10`
do
logger -p local4.info "local4.info test number $i"
sleep 15
done

root@rhel53 scripts# chmod +x logloop
root@rhel53 scripts# ./logloop &
[1] 8264
root@rhel53 scripts# tail -f /var/log/local4.all.log
Mar 28 13:13:36 rhel53 root: local4.info test number 1
Mar 28 13:13:51 rhel53 root: local4.info test number 2

Conclusion

In summary, this chapter covers essential aspects of logging in Linux systems, including monitoring user activities, configuring syslog, managing log files, testing configurations, and monitoring logs in real-time.