# Security logging on FreeBSD



## getopt (Sep 27, 2014)

"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.


```
# 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

```
# 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()

```
# 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

```
# 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"
> 
> ...


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?


----------



## teo (Sep 27, 2014)

Which version of system. Use FreeBSD server ?.


----------



## junovitch@ (Sep 27, 2014)

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.


----------



## junovitch@ (Sep 30, 2014)

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.


----------



## meteor8488 (May 2, 2019)

Hi *getopt*
Did you fix your issue?
I have the same issue now..


----------

