Yeah, I know.
But I like to change my audit rules when I add new services/items that need
to be audited.
Anywhere that's actually paying you money to keep their servers up isn't
going to be thrilled with you rebooting them....ever.
If you're actually auditing your audit rules and offloading your logs,
you'll see someone changing them and thus can react to the change.
-e 2 makes your system *less* secure in many SLA settings (since you can't
actually audit as much as you should be given system changes) and should be
in the realm of 'ideal'.
Trevor
On Sat, Oct 5, 2013 at 11:33 PM, <fcaviggi(a)redhat.com> wrote:
Trevor,
The -e 2 setting ensures that the audit rules are immutable until the next
reboot. It ensures the configuration can't be changed by doing someone
doing something nefarious to the system.
Regards,
Frank
On 10/05/2013 09:27 PM, Trevor Vaughan wrote:
Personally, I'm massively opposed to '-e 2'.
I really like the ability to audit new things as I add them without
rebooting my systems.
Trevor
On Fri, Oct 4, 2013 at 8:06 AM, Josh Kayse <Joshua.Kayse(a)gtri.gatech.edu>wrote:
> On 10/04/2013 07:40 AM, Trevor Vaughan wrote:
>
>> Is Augeas an option?
>>
>> This seems like the perfect opportunity to solidify the Augeas lenses
>> regarding security settings while making life easier for everyone.
>>
>> Trevor
>>
>>
>> On Thu, Oct 3, 2013 at 9:42 PM, Shawn Wells <shawn(a)redhat.com
>> <mailto:shawn@redhat.com>> wrote:
>>
>> On 10/3/13 3:11 PM, fcaviggi(a)redhat.com <mailto:fcaviggi@redhat.com>
>> wrote:
>>
>>> All,
>>>
>>> As a starting point for writing remediation fixes in the SSG - so,
>>> I did the following:
>>>
>>> $ ls ~//scap-security-guide/RHEL6/input/checks//*.xml | awk '{
>>>
>>> print $1 }' | sed s/\.[^\.]*$// > ~/checks
>>> $ ls ~//scap-security-guide/RHEL6/input/fixes//*.sh | awk '{
>>>
>>> print $1 }' | sed s/\.[^\.]*$// > ~/fixes
>>> $ sdiff ~/fixes ~/checks | less
>>>
>>> There's fair a bit of work to be done for the fix remediations...
>>>
>>> Since I'm new to the project, I was wondering if there was any
>>> ideas or standards to how the SSG should distribute some of these
>>> fixes - for example - a wholesale replacement of the audit.rules
>>> and auditd.conf might be preferable than doing piecemeal sed's.
>>>
>>
>> It'd be omgz easier to `cp /usr/share/doc/audit-*/stig.rules
>> /etc/audit.rules`, and that likely is the right choice during an
>> initial provisioning process. But then SysAdmins tailor audit rules,
>> the system evolves, and we need to evaluate the audit.rules file
>> against specific auditing guidance items after the pristine
>> audit.rules template is manipulated.
>>
>> So, if a single rule must be remediated, we can't blow away the
>> whole audit.rules file. Super fun sed scripts it is =/
>>
>> <snip>
>>
>
> I think that augeas is a good idea. We need to be careful that rules
> that are inserted in to audit.rules happen before any '-e 2' line (if one
> exists). Otherwise they will fail to be inserted because the audit rules
> become locked.
>
> -josh
>
> --
> 404.407.6630
>
>
> _______________________________________________
> scap-security-guide mailing list
> scap-security-guide(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
>
>
--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvaughan(a)onyxpoint.com
-- This account not approved for unencrypted proprietary information --
_______________________________________________
scap-security-guide mailing
listscap-security-guide@lists.fedorahosted.orghttps://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
--
Frank Caviggia
Consultant, Public Sectorfcaviggi(a)redhat.com
(M) (571) 295-4560
_______________________________________________
scap-security-guide mailing list
scap-security-guide(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvaughan(a)onyxpoint.com
-- This account not approved for unencrypted proprietary information --