Here is a short summary of what this script does:
- section 1: open the
/var/log/sendpflog.logfile to store messages generated by the script itself. They are useful for debugging purposes and this file should be the first to look at when there is something wrong going on with the script itself. The log file is located in the
/var/log directory, but you can change that to another location;
- section 2: define the
logme()function, which will write properly formatted logs to
- section 3: define the
loganddie()function, which logs fatal errors, closes files and removes the
- section 4: defines the
rotatelogs()function which closes and opens
/var/lof/sendpflog.logafter receiving the SIGHUP signal from newsyslog;
- section 5: defines the
open_output()function used to open the connection to the monitoring station. Replace username with the name of the user you wish sendpflog to login as onto the monitoring station, and replace xxx.xxx.xxx.xxx with either the hostname or the IP number of the monitoring station;
- section 6: configure signal handlers to catch most important signals;
- section 7: let the world know the script is getting ready for work;
- section 8: write the PID number of the current process to
/var/run/sendpflog.pid. This file will be used by newsyslog to send the SIGHUP signal;
- section 9: open
- section 10: enter the main loop, read
/var/log/pflogand send it to the monitoring station.
Make sendpflog executable, owned by root and a member of the wheel group with these commands (you need to be logged in as root):
# chmod 0700 sendpflog # chown root sendpflog # chgrp wheel sendpflog
Move sendpflog to
# mv sendpflog /root/sendpflog
/etc/newsyslog.conf and replace the following line
/var/log/pflog 600 3 250 * ZB /var/run/pflogd.pid
with these two lines:
/var/log/pflog 600 3 250 * ZB /var/run/sendpflogd.pid /var/log/sendpflog.log 600 3 250 * ZB /var/run/sendpflogd.pid
The changes will tell newsyslog to monitor
/var/log/sendpflog.log and rotate them when their size meets the preset criteria.
Next we need to generate a key pair used to automatically log into the monitoring station without having to give the password. This is done with the ssh-keygen utility. You can use it to generate three types of keys: rsa1 (for RSA authentication connections made using the SSH1 protocol), rsa (for RSA authenitconnections made using the SSH2 protocol), or dsa (for DSA connections made using the SSH2 protocol). If the monitoring station is running the latest release of OpenSSH, then you can use RSA authentication, older releases of SSH may need to use DSA or RSA1.
Log in as root and run
ssh-keygen as follows
# ssh-keygen -t dsa Generating public/private dsa key pair. Enter file in which to save the key (/root/.ssh/id_dsa):
Hit Enter, the computer responds with
Enter passphrase (empty for no passphrase):
Hit Enter, the computer responds with
Enter same passphrase again:
Hit Enter, the computer responds with
Your identification has been saved in /root/.ssh/id_dsa. Your public key has been saved in /root/.ssh/id_dsa.pub. The key fingerprint is: 6f:38:13:90:04:89:55:e6:50:6f:69:50:5f:77:15:e7 root@localhost
/root/.ssh/id_dsa.pub file is the public key which you will copy to the monitoring station to the home directory of an ordinary user which you will need to create for the sole purpose of collecting, archiving and analyzing pf logs (the name of that user must be given in section 5). Do not use the root or any privileged account for that purpose. Also, create an ordinary group that will have only one member-our unprivileged user.
After you create the new account on the monitoring station, copy
/root/.ssh/id_dsa.pub to the normal user directory on the firewall, e.g. /home/joe. Then, use scp to copy
id_dsa.pub to the monitoring station. Then delete
id_dsa.pub from /home/joe and copy (on the monitoring station)
id_dsa.pub to the log collecting user's .ssh/authorized_keys2 file. For example, if the log collecting user is called scooter, use this command:
$ cat id_dsa.pub >> /home/scooter/.ssh/authorized_keys2
Note that if the monitoring station is running some other implementation of SSH, the authorized_keys2 file may reside in the .ssh2 directory. Also, if you use the RSA key (generated with
ssh-keygen -t rsa), the id_rsa.pub file goes into authorized_keys2 as well, while the RSA1 key, the identity.pub file (generated with
ssh-keygen -t rsa1) goes into .ssh/authorized_keys.
OK, it is now time to test the connection; login on your firewall as root and issue the following command:
# ssh -2 -l username xxx.xxx.xxx.xxx
(Replace username and xxx.xxx.xxx.xxx with real user name on the monitoring station and the station's IP number or host name).
If all goes well, you should see a message similar to this one:
RSA key fingerprint is xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx. Are you sure you want to continue connecting (yes/no)?
Answer yes, and you should be logged in on the monitoring station. Be careful, if ssh asks for the password, then there is something wrong and you cannot log in with the dsa key. To fix it, generate rsa or rsa1 keys and try logging in again (if you use the rsa1 key, make sure you replace -2 in section 5 of sendpflog with -1, this tells ssh to use the SSH1 protocol instead of SSH2). One of them is bound to work (but remember that rsa is more secure than rsa1).
Configuring the monitoring station
While you are logged on the monitoring station, create a named pipe in the log collecting user's directory on the station with this command
$ mkfifo -m 0600 pflog
Notice that the name and the location of that named pipe must be given in section 5, after the
cat >> command.
You are now ready to test the connection between the firewall and the monitoring station. To do that, log on the firewall as root and start sendpflog with
Then, log on the monitoring station as the user receiving logs and type this command
$ cat pflog >> pflog-current
Let the computers do their job for a while, browse a few web sites (to generate traffic), and then press Ctrl+C. Type
$ ls -l pflog-current
and you should see something like this (the user and group names and the file size will be different)
-rw-r----- 1 scooter scooter 1256 Jul 10 23:35 pflog-current
If that is the case, you can congratulate yourself, the logs are being transferred to the monitoring station. But if it doesn't work, you should check ssh parameters in section 5, particularly the username, the host IP number or the name of the log file.
You can now read the logs on the monitoring station with
tcpdump -r ./pflog, but that is not very convenient. What we need to do is write a script that works a little like newsyslog. And this is something we'll deal with in another installment of this series.
The method of automated log transfers described in this article could be used to transfer other logs
/var/log/pflog. This will be left as an exercise to the reader. I will only say that every log will have to be transferred via a separate ssh connection, and the named of the scripts, log files and named pipes should be changed to match the name of a particular log.
The sendpflog script is a part of the OpenBSD Administrator Toolbox project hosted on SourceForge.
Well, that's it for today!
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 BSD DevCenter.