* Auditd statsd integration @ 2021-02-09 1:43 Steve Grubb 2021-02-10 19:07 ` LC Bruzenak 0 siblings, 1 reply; 4+ messages in thread From: Steve Grubb @ 2021-02-09 1:43 UTC (permalink / raw) To: linux-audit Hello, I have recently checked in to the audit tree 2 experimental plugins. You can enable them by passing --enable-experimental to configure. One of the new plugins is aimed at providing audit metrics to a statsd server. The idea being that you can use this to relay the metrics to influxdb, prometheus or some other collector. Then you can use Grafana to visualize and alert. Currently, it supports the following metrics: kernel.audit.lost kernel.audit.backlog auditd.free_space auditd.plugin_current_depth auditd.plugin_max_depth audit_events.total_count audit_events.total_failed audit_events.avc_count audit_events.fanotify_count audit_events.logins_failed audit_events.logins_success audit_events.anomaly_count audit_events.response_count I'd be interested in hearing if this would be useful. And if these are the right metrics that people are interested in. Should something else be measured? Should an example Grafana dashboard be included? Let me know what you think. -Steve -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Auditd statsd integration 2021-02-09 1:43 Auditd statsd integration Steve Grubb @ 2021-02-10 19:07 ` LC Bruzenak 2021-02-10 19:11 ` LC Bruzenak 0 siblings, 1 reply; 4+ messages in thread From: LC Bruzenak @ 2021-02-10 19:07 UTC (permalink / raw) To: Linux-audit@redhat.com [-- Attachment #1.1: Type: text/plain, Size: 2150 bytes --] On Mon, Feb 8, 2021 at 7:44 PM Steve Grubb <sgrubb@redhat.com> wrote: > Hello, > > I have recently checked in to the audit tree 2 experimental plugins. You > can > enable them by passing --enable-experimental to configure. One of the new > plugins is aimed at providing audit metrics to a statsd server. The idea > being that you can use this to relay the metrics to influxdb, prometheus > or > some other collector. Then you can use Grafana to visualize and alert. > > Currently, it supports the following metrics: > > kernel.audit.lost > kernel.audit.backlog > auditd.free_space > auditd.plugin_current_depth > auditd.plugin_max_depth > audit_events.total_count > audit_events.total_failed > audit_events.avc_count > audit_events.fanotify_count > audit_events.logins_failed > audit_events.logins_success > audit_events.anomaly_count > audit_events.response_count > > I'd be interested in hearing if this would be useful. And if these are the > right metrics that people are interested in. Should something else be > measured? Should an example Grafana dashboard be included? > > Let me know what you think. > > -Steve > > Steve, I think this could be awesome; hoping to give it a try soon. An example dashboard would be very helpful if you could include that. The stats you already point out a good start. I'd also like to have a way to parse the per-machine kernel-assigned event IDs for missing ones. Might that need a separate plugin for that or could something be done within this setup? I'm pretty sure there are more metrics that would be desired as well as some derived; e.g. take a per-user login/logoff set to identify time spent on a particular machine (screenlocks notwithstanding, but maybe eventually). Or perhaps if clients send events+heartbeats, when are they up/down? These are some of the questions I've heard from security overseers. And while some of these may not be inspected directly by the end users, in the case of trouble calls or questions they might be the exact thing I'd ask them to relay to me in order to diagnose a problem or answer a question remotely. Thx, LCB -- LC (Lenny) Bruzenak lenny@magitekltd.com [-- Attachment #1.2: Type: text/html, Size: 2844 bytes --] [-- Attachment #2: Type: text/plain, Size: 102 bytes --] -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Auditd statsd integration 2021-02-10 19:07 ` LC Bruzenak @ 2021-02-10 19:11 ` LC Bruzenak 2021-02-10 20:06 ` Steve Grubb 0 siblings, 1 reply; 4+ messages in thread From: LC Bruzenak @ 2021-02-10 19:11 UTC (permalink / raw) To: Linux-audit@redhat.com [-- Attachment #1.1: Type: text/plain, Size: 2441 bytes --] On Wed, Feb 10, 2021 at 1:07 PM LC Bruzenak <lenny@magitekltd.com> wrote: > On Mon, Feb 8, 2021 at 7:44 PM Steve Grubb <sgrubb@redhat.com> wrote: > >> Hello, >> >> I have recently checked in to the audit tree 2 experimental plugins. You >> can >> enable them by passing --enable-experimental to configure. One of the new >> plugins is aimed at providing audit metrics to a statsd server. The idea >> being that you can use this to relay the metrics to influxdb, prometheus >> or >> some other collector. Then you can use Grafana to visualize and alert. >> >> Currently, it supports the following metrics: >> >> kernel.audit.lost >> kernel.audit.backlog >> auditd.free_space >> auditd.plugin_current_depth >> auditd.plugin_max_depth >> audit_events.total_count >> audit_events.total_failed >> audit_events.avc_count >> audit_events.fanotify_count >> audit_events.logins_failed >> audit_events.logins_success >> audit_events.anomaly_count >> audit_events.response_count >> >> I'd be interested in hearing if this would be useful. And if these are >> the >> right metrics that people are interested in. Should something else be >> measured? Should an example Grafana dashboard be included? >> >> Let me know what you think. >> >> -Steve >> >> > Steve, > > I think this could be awesome; hoping to give it a try soon. An example > dashboard would be very helpful if you could include that. > The stats you already point out a good start. > > I'd also like to have a way to parse the per-machine kernel-assigned event > IDs for missing ones. Might that need a separate plugin for that or could > something be done within this setup? > I'm pretty sure there are more metrics that would be desired as well as > some derived; e.g. take a per-user login/logoff set to identify time spent > on a particular machine (screenlocks notwithstanding, but maybe > eventually). Or perhaps if clients send events+heartbeats, when are they > up/down? These are some of the questions I've heard from security overseers. > > And while some of these may not be inspected directly by the end users, in > the case of trouble calls or questions they might be the exact thing I'd > ask them to relay to me in order to diagnose a problem or answer a question > remotely. > > Thx, > LCB > > ... and I forgot to ask - can you include a README there which specifies the minimum kernel/userspace level of code required? LCB -- LC (Lenny) Bruzenak lenny@magitekltd.com [-- Attachment #1.2: Type: text/html, Size: 3373 bytes --] [-- Attachment #2: Type: text/plain, Size: 102 bytes --] -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Auditd statsd integration 2021-02-10 19:11 ` LC Bruzenak @ 2021-02-10 20:06 ` Steve Grubb 0 siblings, 0 replies; 4+ messages in thread From: Steve Grubb @ 2021-02-10 20:06 UTC (permalink / raw) To: Linux-audit@redhat.com On Wednesday, February 10, 2021 2:11:55 PM EST LC Bruzenak wrote: > On Wed, Feb 10, 2021 at 1:07 PM LC Bruzenak <lenny@magitekltd.com> wrote: > > On Mon, Feb 8, 2021 at 7:44 PM Steve Grubb <sgrubb@redhat.com> wrote: > >> Hello, > >> > >> I have recently checked in to the audit tree 2 experimental plugins. You > >> can > >> enable them by passing --enable-experimental to configure. One of the > >> new > >> plugins is aimed at providing audit metrics to a statsd server. The idea > >> being that you can use this to relay the metrics to influxdb, prometheus > >> or > >> some other collector. Then you can use Grafana to visualize and alert. > >> > >> Currently, it supports the following metrics: > >> > >> kernel.audit.lost > >> kernel.audit.backlog > >> auditd.free_space > >> auditd.plugin_current_depth > >> auditd.plugin_max_depth > >> audit_events.total_count > >> audit_events.total_failed > >> audit_events.avc_count > >> audit_events.fanotify_count > >> audit_events.logins_failed > >> audit_events.logins_success > >> audit_events.anomaly_count > >> audit_events.response_count > >> > >> I'd be interested in hearing if this would be useful. And if these are > >> the > >> right metrics that people are interested in. Should something else be > >> measured? Should an example Grafana dashboard be included? > >> > >> Let me know what you think. > >> > >> -Steve > > > > Steve, > > > > I think this could be awesome; hoping to give it a try soon. An example > > dashboard would be very helpful if you could include that. > > The stats you already point out a good start. > > > > I'd also like to have a way to parse the per-machine kernel-assigned > > event IDs for missing ones. Might that need a separate plugin for that or > > could something be done within this setup? This is not tracking event IDs. I don't think that fits with performance metrics. To do this, you'd need to keep track of all events coming in and some way of determining what's missing. Which means keeping event state around until some timeout just in case a straggler comes through late. > > I'm pretty sure there are more metrics that would be desired as well as > > some derived; e.g. take a per-user login/logoff set to identify time > > spent on a particular machine (screenlocks notwithstanding, but maybe > > eventually). I was hoping to hear from people that might currently be using Grafana or Graphite to hear if there is anything else needed. Do we need to namespace the machines? If so, how is the best way based on experience? Is dot notation better or underscores? As for session time, I wonder if that kind of metric is currently provided by other parts of statsd/telegraf? > > Or perhaps if clients send events+heartbeats, when are they > > up/down? These are some of the questions I've heard from security > > overseers. I suppose it would be easy enough to check the audisp-remote state report for it's information. > > And while some of these may not be inspected directly by the end users, > > in the case of trouble calls or questions they might be the exact thing > > I'd ask them to relay to me in order to diagnose a problem or answer a > > question remotely. That's the idea with system metrics...to see the system getting in trouble in realtime before the user calls. There are other system metrics that can be configured into statsd/telegraph and standard dashboards for Linux Server metrics. How this differs is that this is statistics specifically aimed at the audit daemon. > ... and I forgot to ask - can you include a README there which specifies > the minimum kernel/userspace level of code required? There is no minimal kernel. It does need an audit-3.0 daemon in order to dump internal state. However, if it doesn't find the state report, then it simply doesn't update those counters. So, in that respect, you could transplant it to pretty much any audit daemon. -Steve -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2021-02-10 20:06 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2021-02-09 1:43 Auditd statsd integration Steve Grubb 2021-02-10 19:07 ` LC Bruzenak 2021-02-10 19:11 ` LC Bruzenak 2021-02-10 20:06 ` Steve Grubb
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).