Watching over non-existent folder to maintain a generic audit.rules file

Watching over non-existent folder to maintain a generic audit.rules file

[Florian Crouzat]

Hello,

I'm a bit new with auditd so excuse me if this question has been already
answered but I failed to find answers.

I'm in the process of replacing a FIM tool by auditd which is by far
more powerful but I wanted to describe all possibles files and folders
(or system calls) that I need to watch over in a generic audit.rules
files that I would deploy on thousands of hosts.
Unfortunately, I do not only watch over system-related files and folders
but also applicative ones (eg custom path where some private keys are
stored, etc) ..
My problem is that these folders do not exists on all hosts thus making
it impossible to write a generic audit.rules files.
As I said, I have thousands of hosts and I can't imagine deploying
different files on every hosts depending on the profile of the host.
I know puppet could help me for this kind of stuff but I don't have it
yet and even though, it would be difficult to configure.

How do you guys usually workaround this issue ? I'm pretty sure I'm not
the first one wanting to deploy a generic hardening across many hosts
(but maybe I'm the only one using auditd to watch over something else
than pure system-related stuff?

Thanks,
Florian

Re: Watching over non-existent folder to maintain a generic audit.rules file

[Steve Grubb]

On Tuesday, July 28, 2015 05:26:18 PM Florian Crouzat wrote:
> Unfortunately, I do not only watch over system-related files and folders
> but also applicative ones (eg custom path where some private keys are
> stored, etc) ..
> My problem is that these folders do not exists on all hosts thus making
> it impossible to write a generic audit.rules files.

What kernel are you using? And user space package?


> As I said, I have thousands of hosts and I can't imagine deploying
> different files on every hosts depending on the profile of the host.
> I know puppet could help me for this kind of stuff but I don't have it
> yet and even though, it would be difficult to configure.

As of the 2.3 user space release, there is a utility, augenrules which takes 
files in /etc/audit/rules.d/ and compiles them into an audit.rules file. So, it 
would be possible for you to package up some rules for bind and install them 
when you install bind and have your package install a 
/etc/audit/rules.d/bind.rules file. You can have a base config, and then one for 
each kind of daemon or role that the machine serves.


> How do you guys usually workaround this issue ? I'm pretty sure I'm not
> the first one wanting to deploy a generic hardening across many hosts
> (but maybe I'm the only one using auditd to watch over something else
> than pure system-related stuff?

Others can chime in here.

-Steve

Re: Watching over non-existent folder to maintain a generic audit.rules file

[Burn Alting]

On Tue, 2015-07-28 at 15:23 -0400, Steve Grubb wrote:
> On Tuesday, July 28, 2015 05:26:18 PM Florian Crouzat wrote:
> > Unfortunately, I do not only watch over system-related files and folders
> > but also applicative ones (eg custom path where some private keys are
> > stored, etc) ..
> > My problem is that these folders do not exists on all hosts thus making
> > it impossible to write a generic audit.rules files.
> 
> What kernel are you using? And user space package?
> 
> 
> > As I said, I have thousands of hosts and I can't imagine deploying
> > different files on every hosts depending on the profile of the host.
> > I know puppet could help me for this kind of stuff but I don't have it
> > yet and even though, it would be difficult to configure.
> 
> As of the 2.3 user space release, there is a utility, augenrules which takes 
> files in /etc/audit/rules.d/ and compiles them into an audit.rules file. So, it 
> would be possible for you to package up some rules for bind and install them 
> when you install bind and have your package install a 
> /etc/audit/rules.d/bind.rules file. You can have a base config, and then one for 
> each kind of daemon or role that the machine serves.
> 
> 
> > How do you guys usually workaround this issue ? I'm pretty sure I'm not
> > the first one wanting to deploy a generic hardening across many hosts
> > (but maybe I'm the only one using auditd to watch over something else
> > than pure system-related stuff?
> 
> Others can chime in here.

As Steve suggests, you should base you efforts around augenrules ...
that why it was written. If you have a project that delivers a new
capability, then part of the security element of it's transition to
operations would be to have the project identify the sensitive files and
have the system administrators deploy project specific .rules files
in /etc/audit/rules.d to monitor them.

If you have pre 2.3 audit user space deployments, then it is not
difficult to deploy your own augenrules setup, but don't deploy it in
the 'production' locations ... it's a bitch to remove when a 2.3 audit
user space upgrade comes ... lots of rpm clashes.

A word to the wise on file watches. If you have a capability who's
'service/process' continually accesses configuration files you will
typically mask this out by having the service start under the init.d
regime at boot time and configure auditd to not monitor the 'unset'
auid. The problem comes when a sustainment staff member, elevates
privilege, and restarts the service. At this, all file accesses by the
service/process will be attributed to the sustainment staff members uid,
not the 'unset' user. This appears to have been addressed by systemd, so
if your Linux release supports systemd, and you configure your
application to use it appropriately, it will not have the problem.
There are workarounds for the init.d based service regime, but that will
have to be a separate post if ane are interested.

Burn

Re: Watching over non-existent folder to maintain a generic audit.rules file

[Florian Crouzat]

On 07/29/2015 12:39 AM, Burn Alting wrote:
> On Tue, 2015-07-28 at 15:23 -0400, Steve Grubb wrote:
>> On Tuesday, July 28, 2015 05:26:18 PM Florian Crouzat wrote:
>>> Unfortunately, I do not only watch over system-related files and folders
>>> but also applicative ones (eg custom path where some private keys are
>>> stored, etc) ..
>>> My problem is that these folders do not exists on all hosts thus making
>>> it impossible to write a generic audit.rules files.
>>
>> What kernel are you using? And user space package?
>>
>>
>>> As I said, I have thousands of hosts and I can't imagine deploying
>>> different files on every hosts depending on the profile of the host.
>>> I know puppet could help me for this kind of stuff but I don't have it
>>> yet and even though, it would be difficult to configure.
>>
>> As of the 2.3 user space release, there is a utility, augenrules which takes 
>> files in /etc/audit/rules.d/ and compiles them into an audit.rules file. So, it 
>> would be possible for you to package up some rules for bind and install them 
>> when you install bind and have your package install a 
>> /etc/audit/rules.d/bind.rules file. You can have a base config, and then one for 
>> each kind of daemon or role that the machine serves.
>>
>>
>>> How do you guys usually workaround this issue ? I'm pretty sure I'm not
>>> the first one wanting to deploy a generic hardening across many hosts
>>> (but maybe I'm the only one using auditd to watch over something else
>>> than pure system-related stuff?
>>
>> Others can chime in here.
> 
> As Steve suggests, you should base you efforts around augenrules ...
> that why it was written. If you have a project that delivers a new
> capability, then part of the security element of it's transition to
> operations would be to have the project identify the sensitive files and
> have the system administrators deploy project specific .rules files
> in /etc/audit/rules.d to monitor them.
> 
> If you have pre 2.3 audit user space deployments, then it is not
> difficult to deploy your own augenrules setup, but don't deploy it in
> the 'production' locations ... it's a bitch to remove when a 2.3 audit
> user space upgrade comes ... lots of rpm clashes.
> 
> A word to the wise on file watches. If you have a capability who's
> 'service/process' continually accesses configuration files you will
> typically mask this out by having the service start under the init.d
> regime at boot time and configure auditd to not monitor the 'unset'
> auid. The problem comes when a sustainment staff member, elevates
> privilege, and restarts the service. At this, all file accesses by the
> service/process will be attributed to the sustainment staff members uid,
> not the 'unset' user. This appears to have been addressed by systemd, so
> if your Linux release supports systemd, and you configure your
> application to use it appropriately, it will not have the problem.
> There are workarounds for the init.d based service regime, but that will
> have to be a separate post if ane are interested.
> 

Hey,

Thanks for the answers.

I have both up-to-date EL6 and EL7 hosts with latests kernel available
in base channel so I think it means I have >=2.3 auditd package.
I'll definitely have a look into augenrules and how to use it.
I'll probably come back at you with mores questions after that.

Florian

Re: Watching over non-existent folder to maintain a generic audit.rules file

[Florian Crouzat]

On 07/29/2015 08:24 AM, Florian Crouzat wrote:
> On 07/29/2015 12:39 AM, Burn Alting wrote:
>> On Tue, 2015-07-28 at 15:23 -0400, Steve Grubb wrote:
>>> On Tuesday, July 28, 2015 05:26:18 PM Florian Crouzat wrote:
>>>> Unfortunately, I do not only watch over system-related files and folders
>>>> but also applicative ones (eg custom path where some private keys are
>>>> stored, etc) ..
>>>> My problem is that these folders do not exists on all hosts thus making
>>>> it impossible to write a generic audit.rules files.
>>>
>>> What kernel are you using? And user space package?
>>>
>>>
>>>> As I said, I have thousands of hosts and I can't imagine deploying
>>>> different files on every hosts depending on the profile of the host.
>>>> I know puppet could help me for this kind of stuff but I don't have it
>>>> yet and even though, it would be difficult to configure.
>>>
>>> As of the 2.3 user space release, there is a utility, augenrules which takes 
>>> files in /etc/audit/rules.d/ and compiles them into an audit.rules file. So, it 
>>> would be possible for you to package up some rules for bind and install them 
>>> when you install bind and have your package install a 
>>> /etc/audit/rules.d/bind.rules file. You can have a base config, and then one for 
>>> each kind of daemon or role that the machine serves.
>>>
>>>
>>>> How do you guys usually workaround this issue ? I'm pretty sure I'm not
>>>> the first one wanting to deploy a generic hardening across many hosts
>>>> (but maybe I'm the only one using auditd to watch over something else
>>>> than pure system-related stuff?
>>>
>>> Others can chime in here.
>>
>> As Steve suggests, you should base you efforts around augenrules ...
>> that why it was written. If you have a project that delivers a new
>> capability, then part of the security element of it's transition to
>> operations would be to have the project identify the sensitive files and
>> have the system administrators deploy project specific .rules files
>> in /etc/audit/rules.d to monitor them.
>>
>> If you have pre 2.3 audit user space deployments, then it is not
>> difficult to deploy your own augenrules setup, but don't deploy it in
>> the 'production' locations ... it's a bitch to remove when a 2.3 audit
>> user space upgrade comes ... lots of rpm clashes.
>>
>> A word to the wise on file watches. If you have a capability who's
>> 'service/process' continually accesses configuration files you will
>> typically mask this out by having the service start under the init.d
>> regime at boot time and configure auditd to not monitor the 'unset'
>> auid. The problem comes when a sustainment staff member, elevates
>> privilege, and restarts the service. At this, all file accesses by the
>> service/process will be attributed to the sustainment staff members uid,
>> not the 'unset' user. This appears to have been addressed by systemd, so
>> if your Linux release supports systemd, and you configure your
>> application to use it appropriately, it will not have the problem.
>> There are workarounds for the init.d based service regime, but that will
>> have to be a separate post if ane are interested.
>>
> 
> Hey,
> 
> Thanks for the answers.
> 
> I have both up-to-date EL6 and EL7 hosts with latests kernel available
> in base channel so I think it means I have >=2.3 auditd package.
> I'll definitely have a look into augenrules and how to use it.
> I'll probably come back at you with mores questions after that.
> 
> Florian

Okay so if I get this straight, I should probably have a default
*generic* audit file for OS/kernel-related stuff and then deploy on
specific hosts a bunch of specific rule files that would be compiled
every now and then by an augenrules cronjob ?

What would be the best practice to be alerted in case the compilation
fails (augenrules) ?

That sounds ... reasonnable. But still, I'll have to maintain these
specific files and find a way to deliver them to these specific hosts.

Florian

Re: Watching over non-existent folder to maintain a generic audit.rules file

[Steve Grubb]

On Tuesday, August 04, 2015 03:57:17 PM Florian Crouzat wrote:
> On 07/29/2015 08:24 AM, Florian Crouzat wrote:
> > On 07/29/2015 12:39 AM, Burn Alting wrote:
> >> On Tue, 2015-07-28 at 15:23 -0400, Steve Grubb wrote:
> >>> On Tuesday, July 28, 2015 05:26:18 PM Florian Crouzat wrote:
> >>>> Unfortunately, I do not only watch over system-related files and
> >>>> folders
> >>>> but also applicative ones (eg custom path where some private keys are
> >>>> stored, etc) ..
> >>>> My problem is that these folders do not exists on all hosts thus making
> >>>> it impossible to write a generic audit.rules files.
> >>> 
> >>> What kernel are you using? And user space package?
> >>> 
> >>>> As I said, I have thousands of hosts and I can't imagine deploying
> >>>> different files on every hosts depending on the profile of the host.
> >>>> I know puppet could help me for this kind of stuff but I don't have it
> >>>> yet and even though, it would be difficult to configure.
> >>> 
> >>> As of the 2.3 user space release, there is a utility, augenrules which
> >>> takes files in /etc/audit/rules.d/ and compiles them into an
> >>> audit.rules file. So, it would be possible for you to package up some
> >>> rules for bind and install them when you install bind and have your
> >>> package install a
> >>> /etc/audit/rules.d/bind.rules file. You can have a base config, and then
> >>> one for each kind of daemon or role that the machine serves.
> >>> 
> >>>> How do you guys usually workaround this issue ? I'm pretty sure I'm not
> >>>> the first one wanting to deploy a generic hardening across many hosts
> >>>> (but maybe I'm the only one using auditd to watch over something else
> >>>> than pure system-related stuff?
> >>> 
> >>> Others can chime in here.
> >> 
> >> As Steve suggests, you should base you efforts around augenrules ...
> >> that why it was written. If you have a project that delivers a new
> >> capability, then part of the security element of it's transition to
> >> operations would be to have the project identify the sensitive files and
> >> have the system administrators deploy project specific .rules files
> >> in /etc/audit/rules.d to monitor them.
> >> 
> >> If you have pre 2.3 audit user space deployments, then it is not
> >> difficult to deploy your own augenrules setup, but don't deploy it in
> >> the 'production' locations ... it's a bitch to remove when a 2.3 audit
> >> user space upgrade comes ... lots of rpm clashes.
> >> 
> >> A word to the wise on file watches. If you have a capability who's
> >> 'service/process' continually accesses configuration files you will
> >> typically mask this out by having the service start under the init.d
> >> regime at boot time and configure auditd to not monitor the 'unset'
> >> auid. The problem comes when a sustainment staff member, elevates
> >> privilege, and restarts the service. At this, all file accesses by the
> >> service/process will be attributed to the sustainment staff members uid,
> >> not the 'unset' user. This appears to have been addressed by systemd, so
> >> if your Linux release supports systemd, and you configure your
> >> application to use it appropriately, it will not have the problem.
> >> There are workarounds for the init.d based service regime, but that will
> >> have to be a separate post if ane are interested.
> > 
> > Hey,
> > 
> > Thanks for the answers.
> > 
> > I have both up-to-date EL6 and EL7 hosts with latests kernel available
> > in base channel so I think it means I have >=2.3 auditd package.
> > I'll definitely have a look into augenrules and how to use it.
> > I'll probably come back at you with mores questions after that.
> > 
> > Florian
> 
> Okay so if I get this straight, I should probably have a default
> *generic* audit file for OS/kernel-related stuff and then deploy on
> specific hosts a bunch of specific rule files that would be compiled
> every now and then by an augenrules cronjob ?

You do not need a cron job. When audit starts, there is a need to load audit 
rules into the kernel. The audit software was changed to use augenrules to do 
that. It checks to see if they have changes since last compilation and if so 
rebuilds them. Otherwise it just loads them through auditctl.


> What would be the best practice to be alerted in case the compilation
> fails (augenrules) ?

I think it returns a failed code of some kind.

-Steve
 
> That sounds ... reasonnable. But still, I'll have to maintain these
> specific files and find a way to deliver them to these specific hosts.
> 
> Florian
> 
> 
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit

Re: Watching over non-existent folder to maintain a generic audit.rules file

[Burn Alting]

On Tue, 2015-08-04 at 15:55 -0400, Steve Grubb wrote:
> On Tuesday, August 04, 2015 03:57:17 PM Florian Crouzat wrote:
> > On 07/29/2015 08:24 AM, Florian Crouzat wrote:
> > > On 07/29/2015 12:39 AM, Burn Alting wrote:
> > >> On Tue, 2015-07-28 at 15:23 -0400, Steve Grubb wrote:
> > >>> On Tuesday, July 28, 2015 05:26:18 PM Florian Crouzat wrote:
> > >>>> Unfortunately, I do not only watch over system-related files and
> > >>>> folders
> > >>>> but also applicative ones (eg custom path where some private keys are
> > >>>> stored, etc) ..
> > >>>> My problem is that these folders do not exists on all hosts thus making
> > >>>> it impossible to write a generic audit.rules files.
> > >>> 
> > >>> What kernel are you using? And user space package?
> > >>> 
> > >>>> As I said, I have thousands of hosts and I can't imagine deploying
> > >>>> different files on every hosts depending on the profile of the host.
> > >>>> I know puppet could help me for this kind of stuff but I don't have it
> > >>>> yet and even though, it would be difficult to configure.
> > >>> 
> > >>> As of the 2.3 user space release, there is a utility, augenrules which
> > >>> takes files in /etc/audit/rules.d/ and compiles them into an
> > >>> audit.rules file. So, it would be possible for you to package up some
> > >>> rules for bind and install them when you install bind and have your
> > >>> package install a
> > >>> /etc/audit/rules.d/bind.rules file. You can have a base config, and then
> > >>> one for each kind of daemon or role that the machine serves.
> > >>> 
> > >>>> How do you guys usually workaround this issue ? I'm pretty sure I'm not
> > >>>> the first one wanting to deploy a generic hardening across many hosts
> > >>>> (but maybe I'm the only one using auditd to watch over something else
> > >>>> than pure system-related stuff?
> > >>> 
> > >>> Others can chime in here.
> > >> 
> > >> As Steve suggests, you should base you efforts around augenrules ...
> > >> that why it was written. If you have a project that delivers a new
> > >> capability, then part of the security element of it's transition to
> > >> operations would be to have the project identify the sensitive files and
> > >> have the system administrators deploy project specific .rules files
> > >> in /etc/audit/rules.d to monitor them.
> > >> 
> > >> If you have pre 2.3 audit user space deployments, then it is not
> > >> difficult to deploy your own augenrules setup, but don't deploy it in
> > >> the 'production' locations ... it's a bitch to remove when a 2.3 audit
> > >> user space upgrade comes ... lots of rpm clashes.
> > >> 
> > >> A word to the wise on file watches. If you have a capability who's
> > >> 'service/process' continually accesses configuration files you will
> > >> typically mask this out by having the service start under the init.d
> > >> regime at boot time and configure auditd to not monitor the 'unset'
> > >> auid. The problem comes when a sustainment staff member, elevates
> > >> privilege, and restarts the service. At this, all file accesses by the
> > >> service/process will be attributed to the sustainment staff members uid,
> > >> not the 'unset' user. This appears to have been addressed by systemd, so
> > >> if your Linux release supports systemd, and you configure your
> > >> application to use it appropriately, it will not have the problem.
> > >> There are workarounds for the init.d based service regime, but that will
> > >> have to be a separate post if ane are interested.
> > > 
> > > Hey,
> > > 
> > > Thanks for the answers.
> > > 
> > > I have both up-to-date EL6 and EL7 hosts with latests kernel available
> > > in base channel so I think it means I have >=2.3 auditd package.
> > > I'll definitely have a look into augenrules and how to use it.
> > > I'll probably come back at you with mores questions after that.
> > > 
> > > Florian
> > 
> > Okay so if I get this straight, I should probably have a default
> > *generic* audit file for OS/kernel-related stuff and then deploy on
> > specific hosts a bunch of specific rule files that would be compiled
> > every now and then by an augenrules cronjob ?
> 
> You do not need a cron job. When audit starts, there is a need to load audit 
> rules into the kernel. The audit software was changed to use augenrules to do 
> that. It checks to see if they have changes since last compilation and if so 
> rebuilds them. Otherwise it just loads them through auditctl.
> 
> 
> > What would be the best practice to be alerted in case the compilation
> > fails (augenrules) ?
> 
> I think it returns a failed code of some kind.

Given a standard working system the exit code is that from the auditctl
utility invoked as per
	auditctl -R ${DestinationFile}
where ${DestinationFile} is the newly created rules file.

Typically, in an enterprise environment, you should note if your rules
file fails to load via an absence of standard audit sent to your
centralised audit repository. Or you could take the direct approach as
part of your system deployment test the execution of /sbin/augenrules
--load.

> 
> -Steve
>  
> > That sounds ... reasonnable. But still, I'll have to maintain these
> > specific files and find a way to deliver them to these specific hosts.

Yes, that is always going to be the case in an enterprise environment.
There are a number of ways of doing this, all centered around either a
directly centralised configuration management system (puppet and
friends) or a manual indirect one.

And to answer your early question. Yes, on all systems deploy a
standard /etc/audit/rules.d/base.rules. Then, for those that require
customisation, add say the file /etc/audit/rules.d/local.rules which has
the localised additional rules. The tough case is where your
localisation needs to change the base.rules files in things other than
the -D, -b, -f and -e directives). Solution ... have a very robust
centralised configuration management system.

Burn

> > 
> > Florian