From: Richard Guy Briggs <rgb@redhat.com>
To: Satish Chandra Kilaru <iam.kilaru@gmail.com>
Cc: "linux-audit@redhat.com" <linux-audit@redhat.com>,
"Viswanath, Logeswari P (MCOU OSTL)" <logeswari.pv@hp.com>
Subject: Re: Linux audit performance impact
Date: Tue, 3 Feb 2015 11:45:31 -0500 [thread overview]
Message-ID: <20150203164531.GZ18752@madcap2.tricolour.ca> (raw)
In-Reply-To: <CAAnai+XxzpQQq_-0=MCr2FBwxA0yfW_Y3ET6QiLBmC4fSrtc8w@mail.gmail.com>
On 15/02/03, Satish Chandra Kilaru wrote:
> How many events can kernel accumulate without I/o ?
The kernel default is 64 *buffers*, but I think Fedora and RHEL set it
to 320. It is now possible to set it to "0" which means limited only by
system resources. See "man auditctl", "-b" option. An event can be
made up of several buffers.
Of course, how long a system lasts before the queue blows up depends on
your rule set...
However, at the moment, it will still write out to klog if auditd isn't
running.
> On Tuesday, February 3, 2015, Viswanath, Logeswari P (MCOU OSTL) <
> logeswari.pv@hp.com> wrote:
>
> > I don't want to disable auditing (i.e. disable audit record collection),
> > but just do not want the records to delivered to user space since I want to
> > remove the I/O overhead while running the performance test.
> > Is there any option for this?
> >
> > -----Original Message-----
> > From: Richard Guy Briggs [mailto:rgb@redhat.com <javascript:;>]
> > Sent: Thursday, January 29, 2015 10:23 PM
> > To: Viswanath, Logeswari P (MCOU OSTL)
> > Cc: Satish Chandra Kilaru; Steve Grubb; linux-audit@redhat.com
> > <javascript:;>
> > Subject: Re: Linux audit performance impact
> >
> > On 15/01/29, Viswanath, Logeswari P (MCOU OSTL) wrote:
> > > Please read my question as “Is there any option to configure kaudit
> > > not to log audit records to syslog? when auditd not running.”
> >
> > Yeah, remove audit=1 from the kernel command line, or set audit=0 in its
> > place. This will stop all but AVCs and if auditd has ever run since boot.
> > If audit=0 is on the kernel boot line, it will be impossible to run auditd.
> >
> > There is a feature request that is likely coming soon that could be
> > useful:
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=1160046
> > "If no audit daemon is running, but an audit multicast subscriber is
> > around, then the kernel shouldn't forward audit data to kmsg"
> >
> > > From: Viswanath, Logeswari P (MCOU OSTL)
> > > Sent: Thursday, January 29, 2015 11:49 AM
> > > To: 'Satish Chandra Kilaru'; Steve Grubb
> > > Cc: linux-audit@redhat.com <javascript:;>
> > > Subject: RE: Linux audit performance impact
> > >
> > > Is there any option to configure kaudit not to log audit records to
> > syslog when auditd is running?
> > > This way we can assess the impact of enabling audit without involving
> > disk I/o overhead.
> > >
> > > From: Satish Chandra Kilaru [mailto:iam.kilaru@gmail.com <javascript:;>]
> > > Sent: Thursday, January 29, 2015 9:12 AM
> > > To: Steve Grubb
> > > Cc: linux-audit@redhat.com <javascript:;><mailto:linux-audit@redhat.com
> > <javascript:;>>; Viswanath,
> > > Logeswari P (MCOU OSTL)
> > > Subject: Re: Linux audit performance impact
> > >
> > > I agree with you... but writing to disk can trigger further events
> > leading spiralling of events...
> > > I brought down my server few times with stupid rules...
> > >
> > > On Wed, Jan 28, 2015 at 10:39 PM, Steve Grubb <sgrubb@redhat.com
> > <javascript:;><mailto:sgrubb@redhat.com <javascript:;>>> wrote:
> > > On Wednesday, January 28, 2015 10:18:47 AM Satish Chandra Kilaru wrote:
> > > > Write your own program to receive audit events directly without
> > > > using auditd...
> > > > That should be faster ....
> > > > Auditd will log the events to disk causing more I/o than u need...
> > >
> > > But even that is configurable in many ways. You can decide if you want
> > > logging to disk or not and what kind of assurance that it made it to
> > > disk and the priority of that audit daemon. Then you also have all the
> > > normal tuning knobs for disk throughput that you would use for any
> > > disk performance critical system.
> > >
> > > -Steve
> > >
> > > > On Wednesday, January 28, 2015, Viswanath, Logeswari P (MCOU OSTL) <
> > > >
> > > > logeswari.pv@hp.com <javascript:;><mailto:logeswari.pv@hp.com
> > <javascript:;>>> wrote:
> > > > > Hi Steve,
> > > > >
> > > > > I am Logeswari working for HP.
> > > > >
> > > > >
> > > > >
> > > > > We want to know audit performance impact on RHEL and Suse linux to
> > > > > help us evaluate linux audit as data source for our host based IDS.
> > > > >
> > > > > When we ran our own performance test with a test audispd plugin,
> > > > > we found if a system can perform 200000 open/close system calls
> > > > > per second without auditing, system can perform only 3000
> > > > > open/close system calls auditing is enabled for open/close system
> > > > > call which is a HUGE impact on the system performance. It would be
> > > > > great if anyone can help us answering the following questions.
> > > > >
> > > > >
> > > > >
> > > > > 1) Is this performance impact expected? If yes, what is the
> > reason
> > > > > behind it and can we fix it?
> > > > >
> > > > > 2) Have anyone done any benchmarking for performance impact? If
> > yes,
> > > > > can you please share the numbers and also the steps/programs used
> > > > > the run the same.
> > > > >
> > > > > 3) Help us validating the performance test we have done in our
> > test
> > > > > setup using the steps mentioned along with the results attached.
> > > > >
> > > > >
> > > > >
> > > > > Attached test program (loader.c) to invoke open and close system
> > calls.
> > > > >
> > > > > Attached idskerndsp is the audispd plugin program.
> > > > >
> > > > > We used time command to determine how much time the system took to
> > > > > complete 50000 open/close system calls without (results attached
> > > > > Without-auditing) and with auditing enabled on the system
> > > > > (With-auditing-NOLOG-audispd-plugin and With-auditing-RAW)
> > > > >
> > > > >
> > > > >
> > > > > System details:
> > > > >
> > > > >
> > > > >
> > > > > 1 CPU machine
> > > > >
> > > > >
> > > > >
> > > > > *OS Version*
> > > > >
> > > > > RHEL 6.5
> > > > >
> > > > >
> > > > >
> > > > > *Kernel Version*
> > > > >
> > > > > uname –r
> > > > >
> > > > > 2.6.32-431.el6.x86_64
> > > > >
> > > > >
> > > > >
> > > > > Note: auditd was occupying 35% of CPU and was sleeping for most of
> > > > > the time whereas kauditd was occupying 20% of the CPU.
> > > > >
> > > > >
> > > > >
> > > > > Thanks & Regards,
> > > > >
> > > > > Logeswari.
> > >
> > >
> > >
> > > --
> > > Please Donate to www.wikipedia.org<http://www.wikipedia.org>
> >
> > > --
> > > Linux-audit mailing list
> > > Linux-audit@redhat.com <javascript:;>
> > > https://www.redhat.com/mailman/listinfo/linux-audit
> >
> >
> > - RGB
> >
> > --
> > Richard Guy Briggs <rbriggs@redhat.com <javascript:;>>
> > Senior Software Engineer, Kernel Security, AMER ENG Base Operating
> > Systems, Red Hat Remote, Ottawa, Canada
> > Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
> >
>
>
> --
> Please Donate to www.wikipedia.org
- RGB
--
Richard Guy Briggs <rbriggs@redhat.com>
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
next prev parent reply other threads:[~2015-02-03 16:45 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-28 14:57 Linux audit performance impact Viswanath, Logeswari P (MCOU OSTL)
2015-01-28 15:16 ` Steve Grubb
2015-01-28 15:52 ` Viswanath, Logeswari P (MCOU OSTL)
2015-01-29 2:59 ` Satish Chandra Kilaru
2015-01-29 13:29 ` Viswanath, Logeswari P (MCOU OSTL)
2015-01-28 15:18 ` Satish Chandra Kilaru
2015-01-28 15:53 ` Viswanath, Logeswari P (MCOU OSTL)
2015-01-29 3:39 ` Steve Grubb
2015-01-29 3:41 ` Satish Chandra Kilaru
2015-01-29 6:18 ` Viswanath, Logeswari P (MCOU OSTL)
2015-01-29 9:20 ` Viswanath, Logeswari P (MCOU OSTL)
2015-01-29 16:52 ` Richard Guy Briggs
2015-01-29 17:13 ` Satish Chandra Kilaru
2015-01-30 13:08 ` Viswanath, Logeswari P (MCOU OSTL)
2015-02-03 10:27 ` Viswanath, Logeswari P (MCOU OSTL)
2015-02-03 12:03 ` Satish Chandra Kilaru
2015-02-03 16:45 ` Richard Guy Briggs [this message]
2015-02-03 16:54 ` Satish Chandra Kilaru
2015-02-03 17:02 ` Richard Guy Briggs
2015-02-04 8:52 ` Viswanath, Logeswari P (MCOU OSTL)
2015-02-04 16:15 ` Richard Guy Briggs
2015-02-06 6:47 ` Viswanath, Logeswari P (MCOU OSTL)
2015-02-11 16:51 ` Richard Guy Briggs
2015-02-12 14:58 ` Viswanath, Logeswari P (MCOU OSTL)
2015-02-13 14:15 ` Satish Chandra Kilaru
2015-02-06 11:52 ` Viswanath, Logeswari P (MCOU OSTL)
2015-02-11 14:16 ` Viswanath, Logeswari P (MCOU OSTL)
2015-02-11 16:45 ` Richard Guy Briggs
-- strict thread matches above, loose matches on Subject: below --
2015-02-12 16:09 Viswanath, Logeswari P (MCOU OSTL)
2015-02-12 18:25 ` Richard Guy Briggs
2015-02-16 11:25 ` Viswanath, Logeswari P (MCOU OSTL)
2015-02-16 12:59 ` Steve Grubb
2015-02-17 13:10 ` Viswanath, Logeswari P (MCOU OSTL)
2015-02-17 13:25 ` Steve Grubb
2015-02-18 21:13 ` Richard Guy Briggs
2015-02-18 21:21 ` Satish Chandra Kilaru
2015-02-18 21:49 ` Paul Moore
2015-02-18 22:32 ` Richard Guy Briggs
2015-02-19 3:32 ` Paul Moore
2015-02-20 18:29 ` Casey Schaufler
2015-02-20 18:37 ` Ed Christiansen MS
2015-02-20 18:51 ` Casey Schaufler
2015-02-20 21:25 ` Paul Moore
2015-02-20 21:22 ` Paul Moore
2015-02-23 13:28 ` Viswanath, Logeswari P (MCOU OSTL)
2015-02-16 17:32 ` Paul Moore
2015-02-12 16:10 Viswanath, Logeswari P (MCOU OSTL)
2015-02-12 16:31 ` Paul Moore
2015-02-12 16:43 ` Viswanath, Logeswari P (MCOU OSTL)
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=20150203164531.GZ18752@madcap2.tricolour.ca \
--to=rgb@redhat.com \
--cc=iam.kilaru@gmail.com \
--cc=linux-audit@redhat.com \
--cc=logeswari.pv@hp.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox