BSD DevCenter
oreilly.comSafari Books Online.Conferences.


Securing Remote PF Firewall Logs

by Jacek Artymiak

Welcome back!

Last time we learned how to send pf logs over an ssh connection to a remote logging station. Today we'll learn how to improve the security of that connection, and we'll do some math to find out just how much storage space we need to keep a reasonable amount of logs for convenient analysis.

The sendpflog script described in the previous part of this series makes a connection to the monitoring station using ssh and sends pf logs to the pflog fifo pipe created on that station (by the way, it's not the same as the pflog file found in /var/log on the firewall). The pipe is not read by log analysis software directly, but by another script, readpflog, running on the monitoring station. That script works a little like newsyslog, dividing logs into pieces of preset size and archiving them for later analysis. But before we get to that, let's see how we can make the ssh connection more secure.

The ssh connection made as described in part 6 of this series, can be used to do a full login, which is not very wise from the point of view of security. Fortunately, ssh can be configured to restrict activity of the user logging in on the monitoring station. Simply open .ssh/authorized_keys, the one located on the monitoring station, in the home directory of the user scooter, or whoever you chose to receive logs. You should see a line like this one:

09042041894298934725815994839373584 root@firewall 

Now, add the following options in front of the key for root@firewall (or whatever is the hostname or IP number of your firewall), without adding line breaks, the whole entry should be a single line:

command=*cat >> pflog*,from=*firewall*,no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty

These options have the following meaning:

  • command=*cat >> pflog*: the user logging in with that key can only execute *cat >> pflog* and nothing else.

  • from=*firewall*: restricts the use of the key to the specified host (replace firewall to the name of the firewall host on your network or it's IP number, whatever you use, make sure it matches the hostname or the IP number of the firewall listed at the end of the key, after root@).

  • no-port-forwarding: forbids port forwarding.

  • no-X11-forwarding: forbids X11 forwarding.

  • no-agent-forwarding: forbids forwarding of the authentication agent.

  • no-pty: forbids pty allocation.

The entry for root@firewall should now look like this:

command=*cat >> pflog*,from=*firewall*,no-port-forwarding,
no-X11-forwarding,no-agent-forwarding,no-pty 102435823048999354794546
815994839373584 root@firewall 

Save modifications made to authorized_keys and restart sendpflog on the firewall. (You can learn more about key options from man sshd)

Can you make logging even more secure? Yes. It is a very good idea to either create a new disk partition on the monitoring station, solely for the purpose of storing logs. This prevents bringing the monitoring station to a halt when the disk gets filled with log data, either because of incorrect estimates of the space required to store logs, or through a deliberate action by hackers. When logs are stored on a separate partition, filling that partition will not bring the whole system to a halt.

Unfortunately, this requires backing up data and programs currently stored on the monitoring station, reformatting of the whole disk, adding a new partition, and reinstalling the system from scratch, which always takes a lot of time.

It is usually much more convenient to add a separate disk, which can be used to store logs. All you have to do is put a new hard disk into the system, format it, and mount under /home/scooter. If you don't know how to make the new disk visible to the system, read man pages for disklabel, newfs, and mount.

How big should a log partition, or disk, be? That largely depends on the amount of data you want to store. The upper limit can be computed using this formula:

max. speed of the interface (in Mb/s) x the number of hours x 3600 / 8

So, if you wanted to compute the amount of space needed to store logs arriving on a 100Mb/s interface on the monitoring station over a period of 24 hours, you'd need a rather large partition or disk:

100 x 24 x 3600 / 8 = 1080000MB = 1055GB = 1.1TB

Wow! That's a lot of data! You have a problem, because you cannot buy a 1.1 TB disk today, and I wouldn't bet it will be possible to buy them any time soon (although there are news of 200GB disks, so that day may be nearer than we think). But don't worry. In practice, you are unlikely to saturate such link, at least on a small or medium sized network, because (a) the firewall machine probably cannot send data fast enough, (b) the monitoring station cannot receive data at that rate, and (c) the traffic on your network does not reach the 100Mb limit.

But even if it was nearer 600GB, we'd still have a problem. We can solve it in several ways:

  • use a RAID array to store data;
  • keep less data on the disk by moving it to a tape, CD-R or CD-RW;
  • log less data.

Also in Securing Small Networks with OpenBSD:

Changes in pf: Packet Filtering

Changes in pf: More on NAT

NAT with pf

Patching OpenBSD

Downloading Files from Behind the Firewall

The first solution is based on a hardware, simply buy enough disks to hold as much data as you need and configure them in a way that suits your needs (man raidctl is your friend).

The second solution still requires a large disk, but not as large as 1.1TB. If we were really receiving 1.1TB of data in a day, it would require a modest 44GB of data in an hour. A 100GB disk could, therefore, hold the current log plus data from the last hour. That old log ought to be written to an external storage device before the current log closes and is rotated. That should not be a problem, if you own a fast tape streamer capable of recording up to 44GB of data per hour. Other storage media, such as CD-R, CD-RW, DVD-R, or optical disks are just not fast enough or cannot hold enough data. But this is theory and one cannot realistically expect a small or medium sized network to have such resources. And they probably do not have to, because the amount of traffic logged will be much lower. How much? Well, the answer to that question has to be found by the administrator who will watch the amount of traffic on the monitoring station's interface over a period of a few weeks.

A far less expensive, and much saner, solution for those networks that do not need to log all traffic, is optimization of the pf logging setup. Instead of logging all traffic on all interfaces, you can only log traffic entering and leaving the external interface (see part 4 of this series for more information). That should be good enough for catching most of the interesting traffic and will make log analysis and storage more manageable.

To see how much storage space we'll need this time, we'll use our magic formula again, using a fast ADSL modem as an example. Suppose it is a 7 (downlink) / 3 (uplink) Mb/s model:

7 x 24 x 3600 / 8 = 75600MB = 74GB

Now, 74GB of data per day is certainly more manageable than 1.1TB. Furthermore, the external interface is never working at 100% of its maximum transfer rate, and we can safely assume that we need a paltry 40GB (or less) of space to store uncompressed traffic logged over a period of 24 hours. A 100GB disk will hold two days worth of data plus enough space for another 12 hours. That is enough data to get a very good view of suspicious activities. Also, 40GB is well within capacity of inexpensive DDS/DAT streamers.

What's more, if we tell pf to log only incoming packets, we further decrease the amount of space needed to log traffic. Just how much of a saving it will be depends on the patters of usage of our network. If the amount of outbound traffic passing though the external interface is a significant portion of the overall traffic on that interface, the savings might be substantial; otherwise, they might not be noticeable.

Well, that's it for today. Next time we'll get dirty with Perl again and write the readpflog script, which we need in order to make log analysis and management a little easier.

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, writes and teaches about Open Source software and security, and tries to make things happen.

Read more Securing Small Networks with OpenBSD columns.

Return to the BSD DevCenter.

Sponsored by: