All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lenny Bruzenak <lenny@magitekltd.com>
To: linux-audit@redhat.com
Subject: Re: Key based rate limiter (audit_set_rate_limit)
Date: Tue, 28 Feb 2023 10:03:09 -0700	[thread overview]
Message-ID: <d0c20f21-7064-e199-c052-5d049a681ecf@magitekltd.com> (raw)
In-Reply-To: <CAHC9VhSr3groyZpA34L3swqDoU8_WJWbWsHz7GDR0QqNpSjhyA@mail.gmail.com>

On 2/28/23 09:31, Paul Moore wrote:

> On Tue, Feb 28, 2023 at 10:35 AM Anurag Aggarwal
> <anurag19aggarwal@gmail.com>  wrote:
>> Hello Paul,
>>
>> Thank you for your information.
>>
>>> If you have a particular audit
>>> rule which is too verbose *and* you are willing to lose audit records
>>> from that filter rule (which is what would happen if they were rate
>>> limited), you might want to consider making that audit filter rule
>>> more targeted to the event you are interested in logging.  Generating
>>> more audit records than you want to see can be a sign of an overly
>>> general audit rule.
>> I agree that having rules which are too verbose is not a very good idea.
>>
>> Beside this, is there any other mechanism which we can use to get a similar effect?
> Nothing comes quickly to mind, perhaps others on the mailing list
> might have some ideas ... ?

Not much else to offer above what Paul already replied. Maybe if we saw 
your rule we could offer more.

What we do not know is - do you have any filtering criteria in mind not 
covered by the available auditctl exclusions or do you just want to 
"sample" randomly?

If the latter, why bother auditing this with a rule at all? You might be 
able to remove the rule causing the events and do something in userspace 
to audit only what you really want.

Without a bit more context on the events, rule and intent it is hard to 
suggest alternatives. But in general, it is preferable to exclude as 
much noise as possible in your collection to ensure you get only what is 
required/desired in your audit logs.

LCB

-- 
Lenny Bruzenak
MagitekLTD

--
Linux-audit mailing list
Linux-audit@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-audit

  reply	other threads:[~2023-02-28 17:03 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-28 10:53 Key based rate limiter (audit_set_rate_limit) Anurag Aggarwal
2023-02-28 14:11 ` Paul Moore
2023-02-28 15:35   ` Anurag Aggarwal
2023-02-28 16:31     ` Paul Moore
2023-02-28 17:03       ` Lenny Bruzenak [this message]
2023-03-01 15:31         ` Anurag Aggarwal
2023-03-01 17:05           ` Lenny Bruzenak
2023-03-02  5:13             ` Anurag Aggarwal
2023-03-02 17:24               ` Lenny Bruzenak
2023-03-02 19:11                 ` Paul Moore
2023-03-06  5:48                   ` Anurag Aggarwal
2023-03-08 11:53   ` Anurag Aggarwal
2023-03-08 15:51     ` Steve Grubb
2023-03-08 17:04     ` Paul Moore
2023-03-09  6:16       ` Anurag Aggarwal

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d0c20f21-7064-e199-c052-5d049a681ecf@magitekltd.com \
    --to=lenny@magitekltd.com \
    --cc=linux-audit@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.