BSD DevCenter
oreilly.comSafari Books Online.Conferences.

advertisement


Securing Small Networks with OpenBSD, Part 5
Pages: 1, 2

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.






Sponsored by: