12.7. Log Security

I want to conclude the system-message logging topic with a section about their security. Even though the original purpose of logs was to monitor the system and detect attacks, they can also be used to break in to the system.

Consider a classical break-in example using logs. As you know, when a failed authorization attempt is logged, the password, albeit an incorrect one, is not saved, so as not to give hackers a starting point in figuring it out. But suppose that the user accidentally enters the password instead of the login. This happens often, especially in the mornings, and especially on Monday mornings. Logins, unlike passwords, are recorded in log messages; thus, the password will become available to hackers who obtain access to the message log file.

Therefore, it is important to make logs inaccessible to unauthorized people. Check the access permissions of the log files by executing the following command:

 1s -al /var/log

The results produced by the command look similar to the following:

 drwxr-xr-x    9 root     root         4096 Jan 12 13:18 . drwxr-xr-x   21 root     root         4096 Jan 24 23:00 .. drwx------    2 root     root         4096 Jan 12 11:14 bclsecurity -rw-r-----    1 root     root        83307 Jan 12 13:18 boot.log -rw-r-----    1 root     root        89697 Jan  6 09:01 boot.log.1 -rw-r-----    1 root     root        48922 Jan 30 11:45 boot.log.2 -rw-r-----    1 root     root        64540 Jan 23 19:55 boot.log.3 -rw-r-----    1 root     root        36769 Jan 16 12:36 boot.log.4 -rw-r-----    1 root     root         8453 Jan 12 13:18 cron -rw-r-----    1 root     root         8507 Jan  6 09:06 cron.1 -rw-r-----    1 root     root         7189 Jan 30 11:50 cron.2 -rw-r-----    1 root     root         6935 Jan 23 20:01 cron.3 -rw-r-----    1 root     root         4176 Jan 16 12:41 cron.4 ... ...

The owner of all files should be root. Also, make sure that only the administrator has full access rights, with the rest of the users unable to work with the files.

By default, the read rights for most files belong to the owners and the members of the owner group. The logs most often belong to the root group. If in your system only the administrator belongs to this group, you have no cause for alarm. But if this group comprises several users, which I am against, a special group with minimal rights has to be created and all logs must be switched to this group .

The following sequence of commands creates a new group, named logsgroup , and changes the group membership of all log files to this group:

 groupadd logsgroup cd /var/log chgrp -R logsgroup .

Only the administrator should have the read and write rights to the files in the /var/log directory. The group users should only have the read rights, with the others having no rights. To set these permissions to all log files, execute the following sequence of commands:

 cd /var/log find . -type f  xargs chmod 640

The first line consists of two commands. The first command find . -type f searches the current directory for all f -type objects, that is, for all files. The second command xargs chmod 640 changes the access permissions of all objects found by the first command to 640. These permissions can even be lowered to 600 to give the read and write rights to the administrator only.

Moreover, no user should have read rights to the /var/log/ directory, so as to prevent unauthorized deletion of the log files. If hackers cannot modify log records, they may settle for the second best: deleting the logs themselves . True, deleted logs are a strong indication that someone unauthorized visited your system. But it's a small consolation, because without the log information you will not be able to learn how the break-in was perpetrated and find the culprit.

Remember, if hackers can read the logs, they can use the information recorded in them accidentally to raise their rights in the system. If hackers can modify the logs, they can cover their tracks by deleting all entries pertaining to their activities.

But it is not enough to provide maximum protection. The essence of logging is that the operating system only adds new entries to the log files; it neither deletes the files nor modifies the entries already logged in them. Thus, log files can be further protected from being deleted or modified with the help of file attributes. File attributes in the Ext2 and Ext3 files systems can be expanded with the help of the chattr command. One such expanded attribute is that the file can be only added to. It is set by executing the chattr command with the +a option. For example, the following command sets this attribute to the /var/log/boot.log file:

 chattr +a /var/log/boot.log

Now, trying to delete or modify the file will be unsuccessful . The only shortcoming of this attribute is that you will not be able to clean the file. Log files have a tendency to grow constantly and rather rapidly , but usually it is not necessary to save a record of events that took place a month or even a year ago. To clean up, remove the add-only attribute as follows :

 chattr -a /var/log/boot.log

Just don't forget to set it again after you are done.

In addition to protecting logs, programs used for analyzing them have to be protected. After all, what's the use of protecting log files from reading if they can be viewed using these programs? Log-analyzing programs are protected from unauthorized users by making sure that their SUID and SGID bits are not set.