ONLamp.com    
 Published on ONLamp.com (http://www.onlamp.com/)
 See this if you're having trouble printing code examples


Securing Small Networks with OpenBSD, Part 5

by Jacek Artymiak
06/20/2002

Welcome back.

Today we are going to continue our adventures with pf logs. Last time I wrote about how to log on and read log files with tcpdump. I also mentioned how to filter packets using tcpdump expressions.

So, if all went well, you should have now a steady flow of packet data to plow through. OK, but how do you manage that flood of information? The answer to that is automation. Watching pf logs can be exciting for the first few hours, but it soon becomes a boring activity best left to the machines. But first we need to know how OpenBSD manages pf logs.

The Secret Life of Logs

The pf packet logging mechanism uses the standard system logger daemon syslogd to store packet information in /var/log/pflog. The /var/log directory is the place where the system stores most of the important system logs: authlog, daemon, maillog, messages, secure, or wtmp. One important group of logs missing from that directory are HTTP server logs, which are usually stored somewhere else in the directory tree.

Just like maillog or messages, pflog is rotated to make sure that the logs don't bring the system to its knees by filling the filesystem. Log rotation is the job of the newsyslog command that runs every hour by cron.

You can check this with crontab -l -u root, which should display the crontab entry for the user root (you need to be logged in as root, or the system won't let you do this). Somewhere at the top of the list you should see these lines:
# rotate log files every hour, if necessary
0 * * * * /usr/bin/newsyslog

When newsyslog is run it will check pflog size and, if necessary, rename it, create an empty pflog, and compress the old pflog using the gzip command. The name of the archived log begins with the original log filename and ends with the 0.gz suffix. So, pflog becomes pflog.0.gz and syslogd can begin filling up pflog again. The whole cycle repeats every hour, and when newsyslog decides that pflog is ready to be archived again, it will rename pflog.0.gz to pflog.1.gz and repeat the steps described earlier.

Network Security with OpenSSL

Related Reading

Network Security with OpenSSL
Cryptography for Secure Communications
By John Viega, Matt Messier, Pravir Chandra

At any given point in time, your firewall will store up to four pflog archives. When a new archive is created, the archive with the highest number (pflog.3.gz) is overwritten with the younger archive, (pflog.2.gz). You can check the times when they were created in the following way:

# ls -l pflog*

-rw------- 1 root wheel 268582 May 27 11:37 pflog
-rw------- 1 root wheel 1993502 May 27 10:59 pflog.0.gz
-rw------- 1 root wheel 1220902 May 27 10:00 pflog.1.gz
-rw------- 1 root wheel 1625010 May 27 08:58 pflog.2.gz
-rw------- 1 root wheel 1334018 May 27 08:00 pflog.3.gz

On firewalls servicing busy networks, the best we can hope for is a four-hour snapshot of the traffic. If we want to extend that time, we have two choices: either modify the newsyslog entry in crontab, or edit the /etc/newsyslog.conf entry for pflog.

Editing crontab allows us to only change the delay between consecutive newsyslog runs; the longer the delay, the larger the logs and their archives will be. The procedure is quite simple. Do (as root):

# crontab -e -u root

and change

# rotate log files every hour, if necessary
0 * * * * /usr/bin/newsyslog

to

# rotate log files every two hours, if necessary
0 0-23/2 * * * /usr/bin/newsyslog

Then press Esc and type :x followed by a hit on the Return (or Enter) key on your keyboard. Now, cron will run newsyslog every two hours, keeping an eight-hour snapshot of the traffic. (Changing the value of the hour field to 0-23/6 would give us a 24-hour snapshot of the traffic. For additional information on cron read man cron, man crontab, and man 5 crontab.) The files will be larger, but there will still be a limit on the number of pflog archives kept in /var/log.

If you want to change the number of archives newsyslog keeps in /var/log, or increase their size without affecting all other logs, you need to get familiar with /etc/newsyslog.conf, the configuration file for newsyslog. Open /etc/newsyslog.conf in a text editor (vi will do nicely) and find the following lines:

# logfilename owner.group mode ngen size time [ZB]
/var/log/pflog 600 3 250 * ZB /var/run/pflogd.pid

As you can see, the owner.group field is empty, which means that the archives of pflog will be owned by the user running newsyslog (typically root). You could consider changing the owner and the group to a different user, if you have plans to automate the downloading of pflogs to another workstation for later analysis. Why not just log in as root and download the archives? Because you cannot be sure that your network is internally secure unless you have control over all machines on it. And even then, there is (however remote) a possibility that you may download rogue code that snoops on your network. But it is better to leave that setting alone and write a script that copies the archives to another place, changing its owner and permissions. More on that later, in the next installment of this series.

Related Articles:

Securing Small Networks with OpenBSD, Part 1 -- Small networks are often more vulnerable than large ones because they lack the money to implement good security. Artymiak Jacek explains how to secure a small network on a tight budget.

Securing Small Networks With OpenBSD, Part 2 -- OpenBSD switched from using IPFilter as its default firewall to PF, or Packet Filter, as the new default. Jacek Artymiak explains how to make a smooth transition from ipf to pf.

Securing Small Networks With OpenBSD, Part 3 -- In the third installment of our series on OpenBSD networking, Jacek Artymiak examines pf rules and potential sendmail problems.

Securing Small Networks with OpenBSD, Part 4 -- Jacek Artymiak covers pf log file analysis.

The mode field specifies the write, read, and execute privileges. The default 600 (owner can read and write) is a good choice and should be left alone. The highest number a log archive can have is set in the ngen field. The default value is 3, which tells newsyslog to keep 4 (0 - 3) pflog archives. If you wanted to keep more, say 24 archives, you'd need to set it to 23. This increases the time required to complete the whole procedure of log rotation, so do not go overboard.

The size field defines the minimum size (in kilobytes) of the log file that qualifies it for archiving. The default setting is 250 kilobytes. Increasing its value will result in longer delays between log rotations; decreasing it will result in more frequent rotation of logs, quite possibly at every newsyslog run. Next we encounter the time field, set by default to *, which tells newsyslog to ignore it. Should you set it to 1, it will rotate pflog if the last log rotation was done one or more hours ago. This setting overrides the size setting. The [ZB] flags field and the pid file options should be left alone (you can learn more about them from man newsyslog).

OK. So now you know how the operating system keeps an eye on the logs so they don't cause trouble. What if you want to archive them for longer than newsyslog settings allow? There are two solutions: one is to write a cron script that runs 10-15 minutes after newsyslog and checks to see if the scripts have been rotated, then stores them in a safe place (possibly on another machine); the other is to set up a log monitoring station, connected to the firewall with a serial cable, but not connected to any network. It will act as a dumb terminal with a hard disk that collects the logs and stores them for later, or for real-time analysis.

Why go to such lengths? Well, if you are running a network where you store or process highly valuable information, or you run a site that may become a target of an attack because of the content it serves, you should not take chances. If you store logs on the firewall or on another machine on the network protected by that firewall and your defenses are compromised, malicious hackers will want to cover their steps and remove the information about their visit from the system and pf logs. The machine that is not connected to a network is, by definition, not "hackable". O'Reilly has an excellent article on that subject written by Simon Garfinkel. Read it, even if you are not running the kind of network he describes!

In the next article, we'll learn how to set up a log monitoring station and how to automate transfers of logs to another machines on the internal network.

Until next time.

Jacek Artymiak started his adventure with computers in 1986 with Sinclair ZX Spectrum. He's been using various commercial and Open Source Unix systems since 1991. Today, Jacek runs devGuide.net, writes and teaches about Open Source software and security, and tries to make things happen.


Return to the BSD DevCenter.


Copyright © 2009 O'Reilly Media, Inc.