10.4. logfile Management

 < Day Day Up > 

logfiles tend to grow quickly, accumulate steadily, and eventually become full of less immediately useful information. Log management practices need to come into play. Fortunately, FreeBSD and OpenBSD provide a tool to help manage logfiles: newsyslog(8). The newsyslog utility provides periodic, automated, logfile rotation and compression.

10.4.1. newsyslog Overview

In a nutshell, newsyslog provides the capability to take existing logfiles, rename and compress them, and create a new file to which syslogd can now write. This logfile rotation can happen based on the passage of time, or the size of the file in question. The behavior of newsyslog is controlled by its configuration file newsyslog.conf.

One important thing to keep in mind when looking over a newsyslog.conf file is that newsyslog is not a daemon. It's typically executed periodically through cron(8). If you set up newsyslog to run once a week, you will never have a log containing less than a week's worth of information regardless of any size or date values in the configuration file. Make sure you configure newsyslog to run frequently enough to deal with the logs you need rotated most frequently. On most systems, running newsyslog every day is not considered out of the ordinary. The newsyslog.conf file in Example 10-5 provides a reasonable configuration for log rotation on a BSD system.

Example 10-5. A sample newsyslog.conf
# logfilename          [owner:group]    mode count size when [ZJB] /var/log/cron                           600  3     100  *      J /var/log/*.log                          600  7     100  *      JG /var/log/lpd-errs                       644  7     100  *      J /var/log/maillog        root:mailadmin  640  7     *    @T00   J /var/log/sendmail.st    root:mailadmin  640  10    *    168     B /var/log/messages                       640  5     100  *      J /var/log/security                       600  10    100  *      J /var/log/wtmp                           600  3     *    @01T05  B

It's important to understand what entries in this file mean to properly configure the servers under your jurisdiction, whether they are loghost systems or merely application servers. newsyslog has unique configuration options in FreeBSD 4.x, 5.x, and in OpenBSD, the details of which are beyond the scope of this book. For complete information about which options are supported, see the manpage for newsyslog on the platform of your choice. However, the basics are the same across platforms and we will endeavor to point out relevant differences.


logfilename

This field holds the name of a file to be rotated. It may also contain a shell wildcard when the G option is specified (FreeBSD only).


owner:group

The optional owner and group specification controls the file ownership of both rotated files and new files created after file rotation. In Example 10-5, both logs relating to mail will have their group set to mailadmin.


mode

This field contains the octal representation of the mode bits of both rotated files and new files created after file rotation. In Example 10-5, both logs relating to mail will be readable by users in the mailadmin group based on the previous field. All files marked 600 will be readable only by root. Files with mode bits set to 640 but without specific owner and group specifications will be readable by root and any other users in the wheel group.


count

The count field specifies the number of rotated logs to retain before replacing the oldest logs. Determining the number of files to retain depends on the conditions under which you are rotating logfiles and any security policies that exist in your organization pertaining to the preservation of logs.


size

When the size field contains a value other than asterisk (*), it will be rotated if it is larger than the specified size in kilobytes when newsyslog runs. Note that logs nevertheless are rotated whenever newsyslog runs through cron and finds the file larger than the specified size. Since newsyslog is not a daemon that constantly runs monitoring files, it cannot rotate them the instant they reach a certain size.


when

The when field specifies exactly what you think it does. The format is fully documented in the manpage for newsyslog, so we will not go into detail here. The same is true of the when field as with the size field: regardless of the date/time or interval specification, the log will only rotate when newsyslog runs and it's due.


flags

The flags field varies among the various BSD platforms, and even varies among versions. The most commonly used flags are Z to compress the log via gzip(1), J to compress the log using bzip2(1), B to inform newsyslog that the file is a binary file (and therefore newsyslog should not add a logfile turned over message), and G to inform newsyslog that the value in the logfilename field is a shell pattern and should be expanded using glob(3) (FreeBSD only). Before using these flags or to learn about additional flags that may be available on your chosen platform, read the newsyslog manpage.

With a solid understanding of the options available in newsyslog, you are well prepared to start managing the collections of logs on your systems.

10.4.2. Configuring Log Rotation

If you have configured Syslog to log both locally and remotely, you now have several collections of logfiles to manage. When making decisions about configuring newsyslog, keep the following general guidelines in mind:


Make it easy on yourself

Log management should be an issue you think about when you develop your logging configuration. Once you have instituted a management system, logfiles should be taken care of automatically barring periodic checks to ensure the system is functioning as intended. Try to avoid making decisions that require manual intervention. You have better things to do than manage logfiles.


Develop a log retention policy

A system administrator cannot develop policy on his own. Work with interested parties in the organization, the information security officer, and representatives of the corporate team to develop a log retention policy if you don't already have one. You should keep a log for at least a month so that you can isolate any reconnaissance activity that may have happened before a security incident was identified. For legal reasons, your organization may also need to ensure logs are not maintained beyond a certain point.


Rotate logs by date

When you choose to rotate logfiles based on a size, it's often hard to track down log entries. When logfiles consist of entries during a known date span, tracking down specific events is much easier.


Keep smaller logs

This sounds easy, but it can be a challenge on systems that generate a lot of messages. A wealth of log entries leads to large logfiles and increases the temptation to rotate based on size. Instead, either use the program specification in syslog.conf to split the logfiles into application specific files or rotate the logs more frequently. When logging both locally and to a centralized loghost, the local logs can be kept small by rotating them often while the logs on the loghost can be much larger if you don't plan to use them frequently.


Delete nonessential logs

When a loghost exists on your network, logs on other systems can be considered nonessential. Configure these non-loghost systems to rotate appropriately and retain only as many compressed logfiles as is necessary to provide for local 30-day review.


Maintain redundant logs

Consider creating two identical loghost servers and maintaining independent replicas of logs on both systems. Access to one of these systems can be restricted even more than to the other.

Following these guidelines will help ensure that you have access to the information you need when tracking down problems and will also facilitate handling security incidents. Although most log rotation functionality can be handled by newsyslog, one minor problem remains: when logs are rotated and new files are created, archived files either remain in the directory with the original logs, or in another directory as specified as the argument to the -a parameter for newsyslog. Example 10-6 shows a script created to organize and manage these rotated logfiles.

Example 10-6. Example script to organize rotated logfiles
## Change these to suit your environment ## base_syslog_dir="/var/log/syslogs" rotated_dir="rotated" all_msg_dir="logcheck" ## Date processing ## if [ `date +%m` = "01" ] ; then    # If this is January, then   thisyear=`date +%Y`              # this is the current year,   year=`expr $thisyear - 1`;       # but we want last year. else                               # Otherwise,   year=`date +%Y`                  # we want this year fi month=`date -v-1m +%m`             # Last month # First, create a directory for rotated logfiles if it doesn't # already exist dest_dir="$base_syslog_dir/$rotated_dir/$year/$month" if [ ! -d $dest_dir ] ; then   mkdir -p $dest_dir;   chmod 700 $dest_dir; fi ## Now move logfiles into the just-created directory ## mv $base_syslog_dir/*.gz $dest_dir

This script, when run from cron immediately after newsyslog completes at the start of every month, will copy the compressed logfiles newsyslog created and move them into a rotated subdirectory structure. In this example, if $base_syslog_dir is /var/logs/syslogs and $rotated_dir is rotated, then logs for any given month are located in /var/logs/syslogs/rotated/yyyy/mm, where mm represents the month and yyyy represents the year.

10.4.3. Securing logfiles

Although we have already explored some of the aspects of logfile security during newsyslog configuration, we revisit the topic here just as you should revisit the topic after configuring logfile rotation in your environment. With system logs, the need-to-know rule applies: only those who need access to system logs should be granted access. Whether this is granted through standard filesystem permissions or using ACLs will depend on your specific requirements and chosen operating system. The following guidelines should be applied:

Although tempting, remember that the sappnd flag cannot be used on logfiles that will eventually be rotated. See Chapter 2 for more details.



Remove world permissions

In almost all cases, logfiles should not be world readable or writable. If possible, remove the world-execute bit so that nonprivileged users are kept out of the directory altogether. Any logfiles that require that they be world readable may be stored elsewhere.


Protect nonessential logfiles

Whether or not logfiles are essential (stored on a loghost), they contain sensitive information. Limit access as much as possible. Certain groups of users may require access to certain logfiles, but the need-to-know rule should apply.


Lock down on rotate

When logfiles are rotated, newsyslog creates new files with permissions you specify and enforces the same permissions on the rotated logfiles. Consider locking down permissions further so that only root is able to look at rotated logfiles. If your log rotation script is creating new directories for rotated logs and your system is in a kernel securelevel greater than 0, these new directories may be made immutable (via the schg filesystem flag) after the directory is created. Any parent directories (other than the log directory itself) may also have the sappnd flag set so that files and directories, once created, cannot be removed.

Although logfiles cannot easily be secured using filesystem flags, file-monitoring programs like Tripwire can ensure logfiles never shrink except at specific times when they are rotated.



Restrict access to the loghost

Limit the number of administrators with access to the loghost(s). The logfiles administrators need should be made available on individual systems. Grant loghost access to incident response teams on a per-request basis. In the case of redundant loghost systems, one may be chosen as the "high-security" loghost with very limited access and draconian filesystem flags.

At this point, you know how to capture, consolidate logs, manage, and secure logfiles. Hopefully, with the steps you've taken, incident response teams will have an easier time correlating events and determining how a security incident occurred. Of course, something must prompt their investigation. It would certainly be preferable that an unusual event trigger this investigation rather than the head of your organization calling your department and asking why the external web site now reads "Hax0red 4 U."

     < Day Day Up > 


    Mastering FreeBSD and OpenBSD Security
    Practical Guide to Software Quality Management (Artech House Computing Library)
    ISBN: 596006268
    EAN: 2147483647
    Year: 2003
    Pages: 142
    Authors: John W. Horch

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net