Portaudit Central

Portaudit is intended to run daily against your ports directory identifying known vulnerabilities against a central database. Each night it produce an email that gets sent out and requires inspection.

The problem with this is with many FreeBSD hosts the emails can just be too many and I tend not to look at them.

Portaudit Central provides a means for delivering portaudit output to a central email box which will then produce a simple HTML based report of all machines.

This package consists of 3 scripts written in perl: portaudit-receive.pl, portaudit-report.pl and portaudit-send.pl there is also a simple configuration file, just a bit of perl declaring variables.

The latest version can always be found at http://www.devco.net/code/portauditcentral-current.tgz

The server side script will call logger(1) with some useful diagnostic messages but the lines being logged will include some variables from the environment. I developed this under exim and the environment variables it logs are set by exim.

This will still work under another MTA, the worst that will happen is you'd have some logging entries thats missing details like the sender and message id.

Security

I've taken some steps to prevent man-in-the-middle attacks. An attacker can in theory produce a report that says you have no vulnerabilities on a host when in fact you do have some. In order to combat this a few things are done:

1. Only 1 report per host per day, any reports after the first one will result in errors being logged, this should be a clear indication that you've either configured multiple clients with the same $hostname or someone is up to no good.
2. Each email being sent has a very simple crypto signature, the signature is basically a MD5 hash of the body of the message and a passphrase:

This means as long as your passphrases are secure - they aren't being sent along in the email so no-one can sniff them - someone else should not be able to produce a report that will pass this check regardless of report content. Even if your passphrase gets compromised you should be alerted about tampering by the log entries produced by the duplicate checking mechanism above. As long as you monitor youre log files.

Both client and server will require the p5-File-Temp and p5-Digest-MD5 ports installed, before this will work.

All incoming reports gets saved in an archive directory, this archive directory gets read to produce the final html report. You can choose to put these files anywhere but your MTA must be able to write to the directory.

# mkdir /var/db/portauditcentral
# chown mailnull:mailnull /var/db/portauditcentral

Copy the scripts and sample config dir to locations of your choice, by default it expects the config in /usr/local/etc/portaudit-receive.cfg.

Incoming mail should be piped to STDIN of the portaudit-receive.pl script, using exim you'd put a entry in your alias file that resembles this:

portaudit   |/usr/local/sbin/portaudit-receive.pl

Edit the portaudit-receive.cfg file and set values as follows:

If you wish you can create a cron entry that will run portaudit-report.pl once a day to generate the days report. If you still would like an emailed report showing the summary I suggest using links in a cronjob, something like:

     links -dump http://example.com/portaudit.html | mail you@example.com

Install p5-File-Temp, p5-Digest-MD5 and of course portaudit from ports. Verify that you can use portaudit from the command line first, refer to its man page for more information.

Copy portaudit-send.pl to the client machine, edit the script and set the following:

Arrange for this to be run every night from cron, a sample crontab entry below:

15 1 * * * root /usr/local/bin/portaudit-send.pl >/dev/null 2>&1

You can run the script by hand as root, verify in your mail server logs that a report got sent, verify on the server side it got received by your mail server, if it got delivered to the portaudit-receive.pl script succesfully you should have a file in your $savedir from this host. Assuming your MTA passed it to this script succesfully you'll have some log entries in your syslog files too that might help narrow down any issues.