Auditdistd to remote syslog

Hello,

I'm trying to forward my audit trail through auditdistd to a remote syslog server which is running our SIEM environment. Has anyone already managed to forward audit information to syslog using auditdistd? Below configuration in place:

/etc/security/auditdistd.conf
Code:
sender {
        host "syslog" {
                remote "1.2.3.4:514"
        }
}

/etc/security/audit_control

Code:
dir:/var/audit
dist:on
flags:lo,aa,ad,fc,fd,fw,ex
minfree:5
naflags:lo,aa
policy:cnt,argv
filesz:2M
expire-after:10M

/etc/security/audit_user
Code:
root:lo,ad,ex:no
user1:lo,fc,ad,fw,fd,ex:no
user2:lo,fc,ad,fw,fd,ex:no

/etc/rc.conf contains both audit_enable and auditdistd_enable. However I'm never getting any audit trails forwarded to the syslog.

praudit shows a working configuration:
Code:
praudit /var/audit/current
header,56,11,audit startup,0,Wed Jul 16 10:09:06 2014, + 276 msec
text,auditd::Audit startup
return,success,0
trailer,56

Any insights are more than welcome.
 
The auditdistd(8) doesn't send syslog messages because those are insecure. It requires a auditdistd(8) at the listening end.

From auditdistd.conf(5):
Code:
     remote <addr>

           Address of the remote auditdistd daemon.  Format is the same as for
           the listen statement.  When operating in the sender mode this
           address will be used to connect to the receiver.  When operating in
           the receiver mode only connections from this address will be
           accepted.

Note that remote is used to send data to a remote auditdistd(8), not syslog.
 
Do you think it could be achieved using a trick like this:

Code:
praudit /var/audit/current |logger-t audits -p local0.info
 
Sure but you have to realize that syslog is very insecure. It's UDP and quite easily spoofed. That's not something you want to deal with when you rely on audit data.
 
That's the downside I agree but I have no choice, as I have to comply to a security standard that requires all audit trails generated on the information system to be sent to a central logging system. Last but not least IS is heterogenous and I have to deal with BSD, Linux, and Windows environments.

Anyway I tried the logger trick, it works, but it sends me the whole output of praudit each time I run the command. I would like to have only new event, so I keep trying things ;)

If you guys have any ideas on how I can work around this limitation, feel free!
 
spybsd said:
That's the downside I agree but I have no choice, as I have to comply to a security standard that requires all audit trails generated on the information system to be sent to a central logging system. Last but not least IS is heterogenous and I have to deal with BSD, Linux, and Windows environments.

Anyway I tried the logger trick, it works, but it sends me the whole output of praudit each time I run the command. I would like to have only new event, so I keep trying things ;)

If you guys have any ideas on how I can work around this limitation, feel free!

Can you set up a VM or separate physical machine directly connected to your current central logging system? Use the VM or separate system running FreeBSD and auditdistd to receive audit logs securely then redistribute using a less secure means over a directly connected or local interface where the risk are lower. That seems like it might meet the intent of the rule and at least do it mostly securely.
 
I don't have a solution to your problem, but I set my modem/router to send syslog messages to FreeBSD server. I had to add this line in rc.conf in order the server accept messages

Code:
syslogd_flags="-a 1.2.3.0/24:* -b 1.2.3.1"

where the -a flag is the network segment where the router is part of (using the asterisc ':*' is mandatory, don't ask me why, I set it to 514 but it does not work, or I made a mistake) and the -b flag is the FreeBSD server address (binding address not the router address).

Using host names does not work, I invastigated and found that BIND starts after syslog, so if the host names are local names, managed by the DNS on the same machine, they will not be resolved. I hope this help.
 
Thanks for your replies.
Sure I can add a separate machine to gather auditdistd events.
However I would still have the forward to syslog issue.

I'm now looking in a nice way to only forward new audit records from the /var/audit/current.
The output of praudit I sent through the logger trick contains the whole events...

If you have an idea on how this could be achieved?
 
Few more information:

I think i'm quite close to achieve the needed behaviour.
Currently I'm using the following solution to forward newest audit trails to the syslog:

Code:
root@static-host:~ # praudit /dev/auditpipe | logger -t static_host_audits -h 1.2.3.4

Do you guys think this could be easily daemonize ?
 
spybsd said:
Sure I can add a separate machine to gather auditdistd events.
However I would still have the forward to syslog issue.
You could send the events to that server using auditdistd(8) and use the local syslog of that machine to pass the messages on. That way there would be less risk of the audit data being modified before it gets sent to the central server.
 
Hereunder what i finally put in place to solve my issue.
Maybe not the most fashion way to do it, but a tleast it's working as desired.

I have created a simple rc script that can be found below:

/usr/local/etc/rc.d/audit2syslog

Code:
#!/bin/sh

# 
#
# PROVIDE: audit2syslog
# REQUIRE: Kernel AUDIT option 1
# 
# 
#
# Add the following lines to /etc/rc.conf to enable audit2syslog:
#
# audit2syslog_enable="YES"
#
#
# audit2syslog_flags=""
# Value -t (tag) -h (host) -p (facility)

. /etc/rc.subr

name=audit2syslog
rcvar=audit2syslog_enable

load_rc_config $name

command=/usr/sbin/praudit

start_cmd=${name}_start
stop_cmd=${name}_stop

audit2syslog_start()
{
       /usr/sbin/praudit -l /dev/auditpipe | logger ${audit2syslog_flags} &
}

audit2syslog_stop()
{

                PID=`pgrep praudit`
                kill -s HUP $PID
}

run_rc_command "$1"

The following content has been added to /etc/rc.conf

Code:
auditd_enable="YES"
audit2syslog_enable="YES"
audit2syslog_flags="-t your_tag -h your_host -p your facility"

Most of my critical machines are in a non internet facing DMZ, that's why i choose this way.
For web facing server, i will use the solution proposed by SirDice to keep the audit log integrity.
 
Back
Top