How to secure you logs against attack

Posted by Jason Sat, 14 Oct 2006 16:41:00 GMT

If an attacker successfully gains access to a system, he will more than likely leave signs of his actions in various system logs. When performing a system audit, these logs will be essential in finding information regarding the attackers actions. This paper will document how to properly set up your logging system so that in the event that an attacker does gain access to a system, even with root privileges, he is unable to remove the traces of his actions. By properly setting up system logging, you can foil attempts by an attacker to remove log entries related to his activity, providing for a more reliable post attack system audit.


In Linux, it is possible to assign additional attributes to files and directories through use of the 'chattr' command. At the time of this writing, file attributes in Linux are available when using ext2 and ext3 filesystems, and can be extended to XFS and reiserfs filesystems through patching the kernel. The chattr command offers a number of attributes that may be useful, all of which can be found on the man page. Our use of chattr in this case are to make our system logs set with an append only attribute, this will prevent the attacker from removing any entries which could be used as evidence relating to the attack.


We will be applying this to our log found at /var/log/messages. To set the necessary filesystems attributes simply execute the following command as root:


# chattr +a /var/log/messages


After setting the append attribute flag, you will notice that if you attempt to edit your log file, your shell will reply with an "Operation not permitted" error. Since a skilled attacker will most likely realize that file attributes have been applied to the log file, and thus remove them the same way that you put them in place, by using chattr -a. To stop an attacker from removing the append attribute, we must disable this facility through the capabilities mechanism. The Linux capabilities security model divides up the privileges given to the root account and allows you to selectively disable them. To prevent a user from removing the append only attribute, we need to remove the CAP_LINUX_IMMUTABLE capability from the systems runtime environment. This is done using a utility called 'lcap' which allows us to edit which capabilities will be loaded into runtime. After you download and build the source (using make), you will have a lcap binary that can be executed directly. To disallow modification of the append only flag, execute:


# ./lcap CAP_LINUX_IMMUTABLE


which will remove the ability to change the append only flag. While this would stop a direct approach of modifying the file attribute, it would not stop an indirect approach. It would still be possible to edit file attributes through raw I/O, meaning that the attribute could be accessed by accessing the the actual block device that the attributes reside on. Luckily, the capabilities facility also has the ability to secure this as well via the CAP_SYS_RAWIO capability. So tighten things up a little more, we will also remove this capability:


# ./lcap CAP_SYS_RAWIO


This will prohibit an attacker from accessing the block device directly for the append chattr attribute, as well as any other kind of raw I/O. This is a necessary amendment, as it also prevents access to /dev/mem and /dev/kmem which would be a loophole for the attacker to reinstate the attribute capability.


If the system is a front line machine, with security being a prime concern (should security ever not be?) it is good practice to add this process to an init script, so that it will be initialized at boot by default. Also, you should note the timing of these scripts being executed and make sure that they are loaded toward the end of the boot process, so it doesn't interfere with other system processes. Changes made to the Linux capabilities model are permanent for that uptime instance and can only be cleared by rebooting the system.



Composed by Jason K. Jackson


This site completely supported by Google advertising



Posted in  | Tags ,  | no comments