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 pf packet logging mechanism uses the standard system logger daemon syslogd to store packet information in
/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
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.1.gz and repeat the steps described earlier.
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
# rotate log files every hour, if necessary 0 * * * * /usr/bin/newsyslog
# 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
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.
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
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.