Greetings.
I'd like to try stopping auditd and having selinux audit messages go to rsyslog (and thus be captured over on log02). This way we can have epylog process those logs, they can be remote so we can have a remote copy of them.
This may result in some noise, but I think we can improve the epylog selinux module and fix things, and it gives us another audit trail of things happening on the machines where selinux is enabled.
I think this should do it (in such a way we can easily back it out):
diff --git a/modules/audit/manifests/init.pp b/modules/audit/manifests/init.pp index 30f19c7..ced28a1 100644 --- a/modules/audit/manifests/init.pp +++ b/modules/audit/manifests/init.pp @@ -6,8 +6,8 @@ class audit::auditd { include audit::package
service { auditd: - ensure => running, - enable => true, + ensure => stopped, + enable => false, require => Package['audit'] }
Thoughts? downsides? Alternate plans?
kevin
On Tue, 2011-10-11 at 13:56 -0600, Kevin Fenzi wrote:
Greetings.
I'd like to try stopping auditd and having selinux audit messages go to rsyslog (and thus be captured over on log02). This way we can have epylog process those logs, they can be remote so we can have a remote copy of them.
This may result in some noise, but I think we can improve the epylog selinux module and fix things, and it gives us another audit trail of things happening on the machines where selinux is enabled.
I think this should do it (in such a way we can easily back it out):
diff --git a/modules/audit/manifests/init.pp b/modules/audit/manifests/init.pp index 30f19c7..ced28a1 100644 --- a/modules/audit/manifests/init.pp +++ b/modules/audit/manifests/init.pp @@ -6,8 +6,8 @@ class audit::auditd { include audit::package
service { auditd:
ensure => running,enable => true,
ensure => stopped,enable => false, require => Package['audit']Thoughts? downsides? Alternate plans?
Downsides:
it is A LOT of traffic.
We should keep a close eye on how much noise it generates.
-sv
Technically there shouldn't be lots of denial messages in audit log, unless there is a *repeated* message with one of services or whatever, which should be solved. is there any host with a heavy audit.log right now? I guess we can start with those hosts with selinux enforcing (if it's possible to do it partially) cause they probably have less messages. btw: we cant save them for a long time, like few months at most I think. (then it may probably exceed 2 or 3 hundred megabytes, I'm not sure how much space is available)
On Tue, Oct 11, 2011 at 1:13 PM, seth vidal skvidal@fedoraproject.orgwrote:
On Tue, 2011-10-11 at 13:56 -0600, Kevin Fenzi wrote:
Greetings.
I'd like to try stopping auditd and having selinux audit messages go to rsyslog (and thus be captured over on log02). This way we can have epylog process those logs, they can be remote so we can have a remote copy of them.
This may result in some noise, but I think we can improve the epylog selinux module and fix things, and it gives us another audit trail of things happening on the machines where selinux is enabled.
I think this should do it (in such a way we can easily back it out):
diff --git a/modules/audit/manifests/init.pp b/modules/audit/manifests/init.pp index 30f19c7..ced28a1 100644 --- a/modules/audit/manifests/init.pp +++ b/modules/audit/manifests/init.pp @@ -6,8 +6,8 @@ class audit::auditd { include audit::package
service { auditd:
ensure => running,enable => true,
ensure => stopped,enable => false, require => Package['audit']Thoughts? downsides? Alternate plans?
Downsides:
it is A LOT of traffic.
We should keep a close eye on how much noise it generates.
-sv
infrastructure mailing list infrastructure@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/infrastructure
On Tue, Oct 11, 2011 at 01:56:04PM -0600, Kevin Fenzi wrote:
I'd like to try stopping auditd and having selinux audit messages go to rsyslog (and thus be captured over on log02). This way we can have epylog process those logs, they can be remote so we can have a remote copy of them.
<snip>
Thoughts? downsides? Alternate plans?
Auditd supports both logging to syslog (ref: /etc/audisp/plugins.d/syslog.conf) and to remote audit servers trough audispd-plugins (/etc/audisp/plugins.d/au-remote.conf).
Would it not be better to use one of those ?
-jf
On Wed, 12 Oct 2011 09:46:17 +0200 Jan-Frode Myklebust janfrode@tanso.net wrote:
Thoughts? downsides? Alternate plans?
Auditd supports both logging to syslog (ref: /etc/audisp/plugins.d/syslog.conf) and to remote audit servers trough audispd-plugins (/etc/audisp/plugins.d/au-remote.conf).
Would it not be better to use one of those ?
Perhaps? What does that get us? Ability to filter? What do we want to filter out?
kevin
On Wed, Oct 12, 2011 at 01:09:28PM -0600, Kevin Fenzi wrote:
Thoughts? downsides? Alternate plans?
Auditd supports both logging to syslog (ref: /etc/audisp/plugins.d/syslog.conf) and to remote audit servers trough audispd-plugins (/etc/audisp/plugins.d/au-remote.conf).
Would it not be better to use one of those ?
Perhaps? What does that get us? Ability to filter?
I was thinking more about keeping the logs to be able to do data mining on them using aureport/ausearch, and that auditd is a powerfull facility that should be used more -- not less. By turning off auditd you probably have the same data in the syslogs, but it will be harder to read and report on.
"aureport --avc" -- selinux denials "aureport -l --failed" -- failed logins "aureport --auth --failed" -- failed authentication attempts
What do we want to filter out?
Not filter out, rather filter in. F.ex add a watcher on /etc to log when anything changes there:
echo "-w /etc/ -p wa -k infrakey" >> /etc/audit/audit.rules
Send this to a central auditd-server (or syslog server), and fire off alerts/notices whenever "ausearch -k infrakey" finds something.
-jf
On Thu, 13 Oct 2011 10:16:38 +0200 Jan-Frode Myklebust janfrode@tanso.net wrote:
On Wed, Oct 12, 2011 at 01:09:28PM -0600, Kevin Fenzi wrote:
Thoughts? downsides? Alternate plans?
Auditd supports both logging to syslog (ref: /etc/audisp/plugins.d/syslog.conf) and to remote audit servers trough audispd-plugins (/etc/audisp/plugins.d/au-remote.conf).
Would it not be better to use one of those ?
Perhaps? What does that get us? Ability to filter?
I was thinking more about keeping the logs to be able to do data mining on them using aureport/ausearch, and that auditd is a powerfull facility that should be used more -- not less. By turning off auditd you probably have the same data in the syslogs, but it will be harder to read and report on.
"aureport --avc" -- selinux denials "aureport -l --failed" -- failed logins "aureport --auth --failed" -- failed authentication attempts
Sure, true... but I was hoping to use our existing epylog setup to also report on them and give us 2x daily reports on them. ;)
I suppose it could be made to operate on the audit files as well.
We would need to setup a new server/port/firewall rule however? I didn't find any good/easy/simple doc on setting up a central audit server. Do you know of any? Otherwise I can set one up here at home and play around with it.
Dumping to syslog is pretty easy to try too however....
What do we want to filter out?
Not filter out, rather filter in. F.ex add a watcher on /etc to log when anything changes there:
echo "-w /etc/ -p wa -k infrakey" >> /etc/audit/audit.rules
Send this to a central auditd-server (or syslog server), and fire off alerts/notices whenever "ausearch -k infrakey" finds something.
Sure. Could be very handy in some cases...
kevin
On Sat, Oct 15, 2011 at 7:13 PM, Kevin Fenzi kevin@scrye.com wrote:
We would need to setup a new server/port/firewall rule however? I didn't find any good/easy/simple doc on setting up a central audit server. Do you know of any? Otherwise I can set one up here at home and play around with it.
I don´t remember seeing much documentation for it, but AFAIK it´s just a matter of defining a tcp_listen_port in /etc/audit/auditd.conf to have it listen and collect.
tcp_listen_port This is a numeric value in the range 1..65535 which, if speci- fied, causes auditd to listen on the corresponding TCP port for audit records from remote systems. The audit daemon may be linked with tcp_wrappers. You may want to controll access with an entry in the hosts.allow and deny files.
-jf
infrastructure@lists.fedoraproject.org
-
Jan-Frode Myklebust -
Kevin Fenzi -
Mahrud S -
Seth Vidal