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.

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

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