From mboxrd@z Thu Jan 1 00:00:00 1970 From: Florian Crouzat Subject: Re: Watching over non-existent folder to maintain a generic audit.rules file Date: Tue, 04 Aug 2015 15:57:17 +0200 Message-ID: <55C0C4BD.9070408@floriancrouzat.net> References: <55B79F1A.1040207@floriancrouzat.net> <1795651.WB0YxzRxgh@x2> <1438123148.26354.116.camel@swtf.swtf.dyndns.org> <55B87199.9070803@floriancrouzat.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx1.redhat.com (ext-mx01.extmail.prod.ext.phx2.redhat.com [10.5.110.25]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t74DvOe0032408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 4 Aug 2015 09:57:24 -0400 Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) by mx1.redhat.com (Postfix) with ESMTPS id F41B5ADADC for ; Tue, 4 Aug 2015 13:57:21 +0000 (UTC) Received: from mfilter44-d.gandi.net (mfilter44-d.gandi.net [217.70.178.175]) by relay4-d.mail.gandi.net (Postfix) with ESMTP id 75EA317209F for ; Tue, 4 Aug 2015 15:57:19 +0200 (CEST) Received: from relay4-d.mail.gandi.net ([IPv6:::ffff:217.70.183.196]) by mfilter44-d.gandi.net (mfilter44-d.gandi.net [::ffff:10.0.15.180]) (amavisd-new, port 10024) with ESMTP id W2ddBsWq9Ww6 for ; Tue, 4 Aug 2015 15:57:18 +0200 (CEST) Received: from marvin.lbg.office.lyra (unknown [37.1.253.83]) (Authenticated sender: tech@floriancrouzat.net) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 0780F172090 for ; Tue, 4 Aug 2015 15:57:17 +0200 (CEST) In-Reply-To: <55B87199.9070803@floriancrouzat.net> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: linux-audit@redhat.com List-Id: linux-audit@redhat.com 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