4:02 a.m.
Hi,
Apart the man pages, I didn’t find anything useful relating to audisp-remote.
I am searching information on how it scales ? Is there any performance issue ?
How to use it in a large environment ? ….
Most of what I found dated a long time ago and mainly said use rsyslog instead.
It seems that centralizing the messages through rsyslog is far more popular.
Is audisp-remote really used ?
The man page read :
tcp_max_per_addr
This is a numeric value which indicates how many concurrent
connections from one IP address is allowed. The
default is 1 and the maximum is 1024. Setting this too large may allow for a
Denial of Service attack on the log‐
ging server. Also note that the kernel has an internal maximum that will
eventually prevent this even if auditd
allows it by config. The default should be adequate in most cases unless a
custom written recovery script runs to
forward unsent events. In this case you would increase the number only large
enough to let it in too.
Where could I find an example of recovery script ?
Could it be a way to inject the audit message in auditd after having receiving them via
rsyslog ?
This might be useful just because, by default ausearch in all available logs and the -if
parameter accepts only one file.
Maybe my lack of knowledge about auditd leads me to write rubbish.
If so, please direct me to where I can find how to manage and use audit logs after
centralizing them.
Not only keeping them but acutually using them.
Philippe
equensWorldline is a registered trade mark and trading name owned by the Worldline Group
through its holding company.
This e-mail and the documents attached are confidential and intended solely for the
addressee. If you receive this e-mail in error, you are not authorized to copy, disclose,
use or retain it. Please notify the sender immediately and delete this email from your
systems. As emails may be intercepted, amended or lost, they are not secure.
EquensWorldline and the Worldline Group therefore can accept no liability for any errors
or their content. Although equensWorldline and the Worldline Group endeavours to maintain
a virus-free network, we do not warrant that this transmission is virus-free and can
accept no liability for any damages resulting from any virus transmitted. The risks are
deemed to be accepted by everyone who communicates with equensWorldline and the Worldline
Group by email
1:14 p.m.
On Friday, February 7, 2020 5:02:01 AM EST MAUPERTUIS, PHILIPPE wrote:
Apart the man pages, I didn’t find anything useful relating to
audisp-remote. I am searching information on how it scales ? Is there any
performance issue ? How to use it in a large environment ?
It is really designed for smaller deployments. If you have 10 or so systems,
it should do OK. I have not tested load handling of the daemon via network
sources. But have tested the ability to write logs and its very fast. Fast
enough to fill your hard drive in a minute or so.
Most of what I found dated a long time ago and mainly said use
rsyslog
instead. It seems that centralizing the messages through rsyslog is far
more popular. Is audisp-remote really used ?
For small deployments sure. If you really have a lot, then you probably
should use some kind of subsystem designed to handle large amounts of data.
ELK, graylog, splunk are all a couple that come to mind. I also suspect you
want audit data correlated with other application information.
The main issues at scale are log management, searching, and alerting. These
are all problems that one person hacking on spare time can't really achieve
well. If we had a stronger community with more participants, we probably
would have better and nicer tools.
The man page read :
tcp_max_per_addr
This is a numeric value which indicates how many
concurrent connections from one IP address is allowed. The default is 1
and the maximum is 1024. Setting this too large may allow for a Denial of
Service attack on the log‐ ging server. Also note that the kernel
has an internal maximum that will eventually prevent this even if auditd
allows it by config. The default should be adequate in most cases unless a
custom written recovery script runs to forward unsent events. In this
case you would increase the number only large enough to let it in too.
Where could I find an example of recovery script ?
Could it be a way to inject the audit message in auditd after having
receiving them via rsyslog ? This might be useful just because, by default
ausearch in all available logs and the -if parameter accepts only one
file.
I think you can inject logs by
ausearch --start XXX --raw | audisp-remote
Maybe my lack of knowledge about auditd leads me to write rubbish.
If so, please direct me to where I can find how to manage and use audit
logs after centralizing them. Not only keeping them but acutually using
them.
There may be others in the community that can offer some insight here.
-Steve
1:27 p.m.
Philippe, by "managing and using" the audit logs after centralizing, what
do you mean?
You can centralize logfiles using *rsyslog *to a "central" (r)*syslog*
server, then you can find the logs in whatever path you decided to store
them and use the ausearch command and seek out whatever records you want
based on audit record details you can query.
It is important though to fully and discretely articulate what you mean by
"managing and using" audit logs after centralizing.
Perhaps what you mean by managing is: logrotation?
Perhaps what you mean by using is: query audit-record data based on
specific filter-capable details?
--------------------------
Warron French
On Fri, Feb 7, 2020 at 2:15 PM Steve Grubb <sgrubb(a)redhat.com> wrote:
On Friday, February 7, 2020 5:02:01 AM EST MAUPERTUIS, PHILIPPE
wrote:
> Apart the man pages, I didn’t find anything useful relating to
> audisp-remote. I am searching information on how it scales ? Is there any
> performance issue ? How to use it in a large environment ?
It is really designed for smaller deployments. If you have 10 or so
systems,
it should do OK. I have not tested load handling of the daemon via network
sources. But have tested the ability to write logs and its very fast. Fast
enough to fill your hard drive in a minute or so.
> Most of what I found dated a long time ago and mainly said use rsyslog
> instead. It seems that centralizing the messages through rsyslog is far
> more popular. Is audisp-remote really used ?
For small deployments sure. If you really have a lot, then you probably
should use some kind of subsystem designed to handle large amounts of
data.
ELK, graylog, splunk are all a couple that come to mind. I also suspect
you
want audit data correlated with other application information.
The main issues at scale are log management, searching, and alerting.
These
are all problems that one person hacking on spare time can't really
achieve
well. If we had a stronger community with more participants, we probably
would have better and nicer tools.
> The man page read :
> tcp_max_per_addr
> This is a numeric value which indicates how many
> concurrent connections from one IP address is allowed. The default is 1
> and the maximum is 1024. Setting this too large may allow for a Denial of
> Service attack on the log‐ ging server. Also note that the kernel
> has an internal maximum that will eventually prevent this even if auditd
> allows it by config. The default should be adequate in most cases unless
a
> custom written recovery script runs to forward unsent events. In this
> case you would increase the number only large enough to let it in too.
> Where could I find an example of recovery script ?
> Could it be a way to inject the audit message in auditd after having
> receiving them via rsyslog ? This might be useful just because, by
default
> ausearch in all available logs and the -if parameter accepts only one
> file.
I think you can inject logs by
ausearch --start XXX --raw | audisp-remote
> Maybe my lack of knowledge about auditd leads me to write rubbish.
> If so, please direct me to where I can find how to manage and use audit
> logs after centralizing them. Not only keeping them but acutually using
> them.
There may be others in the community that can offer some insight here.
-Steve
--
Linux-audit mailing list
Linux-audit(a)redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
1780
days inactive
1780
days old
linux-audit@lists.linux-audit.osci.io
2 comments
3 participants
participants (3)
-
MAUPERTUIS, PHILIPPE -
Steve Grubb -
warron.french