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.
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:
1024358230489993547945463877302684489938435094536799377526237815906923 8346571441231054785084500274372573994038533220943216901966231766310185 1362676488696898502309227231929637769105487294380073461038245801883934 5449733684359927750287417981136783100354768935618929176482286490372389 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
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 387730268448993843509453679937752623781590692383465714412310547850845 002743725739940385332209432169019662317663101851362676488696898502309 227231929637769105487294380073461038245801883934544973368435992775028 741798113678310035476893561892917648228649037238909042041894298934725 815994839373584 root@firewall
Save modifications made to
authorized_keys and restart
sendpflog on the firewall. (You can learn more about key options from
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
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:
Also in Securing Small Networks with OpenBSD:
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 devGuide.net, 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.
Copyright © 2009 O'Reilly Media, Inc.