Security logging on FreeBSD

G

getopt

␢
"Read your log files. Internalize this!" Some were told this and some fewer do it. And how brilliant is this, to have a file /var/log/security just ready to read.

Code: 
# ls -l /var/log/security
-rw-------  1 root  wheel  63 27 Apr 01:11 security

# cat /var/log/security
Apr 27 01:11:54 mybox newsyslog[564]: logfile first created
How cool is this! No security issues on mybox since I set up the box. FreeBSD is likely the most secure OS on earth.
Now getting nosy how this all works I look up /etc/syslog.conf
Code: 
# grep security /etc/syslog.conf
security.*                                      /var/log/security
Again cool! Really all security events should be collected in a single file. So I start reading syslog.conf()
Code: 
# man syslog.conf | grep -B1 -A2 security
     The facility describes the part of the system generating the message, and is one of the following keywords:
     auth, authpriv, console, cron, daemon, ftp, kern, lpr, mail, mark, news, ntp, security, syslog, user, uucp, and local0 through local7.  These keywords (with the exception of mark) correspond to similar ``LOG_'' values specified to the openlog(3) and syslog(3) library routines.
--
     # Log all security messages to a separate file.
     security.*                                              /var/log/security
Exploring openlog() one can read
Code: 
# man openlog | grep SECURITY
     LOG_SECURITY  Security subsystems, such as ipfw(4).
Hmm, ok? Just an example for programmers. Not much more can be read in syslog(). Unfortunately I do not run Ipfw, but Packet Filter. Doesn’t it contribute to Syslog?
Ok, let’s look what we find in The Book of PF (Hansteen, 2007):
On FreeBSD and NetBSD, you change the pflog_logfile= line in rc.conf
in a similar way, so it ends up looking like this:
pflog_logfile="/dev/null"

Setting up your syslogd to process the data is straightforward: Choose your
log facility, log level, and action2 and put the resulting line in your /etc/syslog
.conf file. Assuming you have already set up the system logger at loghost
.example.com to receive your data and chosen log facility local2 with log level
info, the correct line is
local2.info @loghost.example.com
Click to expand...
There logging ends in a info file, not security. A matter of taste?

So what is the purpose of the file/var/log/security?
It does show that syslogd can create logging entries from its security facility and with the creation and its first entry it documented that it is functional. Hey! This is so cool. Did you ever expect this when reading /var/log/security and realizing that its size stays relaxing unchanged?

But wait! I could be terribly wrong and there are important sensors that could actually feed /var/log/security in a tremendous helpfully way? But luckily they never were triggered?

But how do I know what they are?
 
For one, I'll preface this with the fact that security is a holistic process. There's no one log to read, one product to install, or one button to push that makes you secure.

The file you mentioned, /var/log/security, will log security relates stuff from programs that tag their logs with "security". The command service auditd onestart will trigger some logs in that file when the daemon starts and rotates audit logs while further audit logs are under /var/audit.
 
Take a look at "17.3.1. Event Selection Expressions" in the Handbook for the event classes you can use for file system events. They aren't the default because auditing everything produces a lot of data. Additionally, audit_user() shows examples of per-user type audit configs. Even after a su to root, the audit system still traces actions back to the UID that triggered it. Check out all of the audit related pages, apropos audit will show a handful, for more information.
 
You must log in or register to reply here.
Back
Top