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