7:31 a.m.
Good morning everyone,
I am working on an environment where I have managed to get centralized audit logging to
work - roughly 95% properly on six (6) CentOS-6.7 workstations and a single (1) CentOS-6.7
server.
I have two problems though; and they seem somewhat minor:
1. The audit events being captured don't seem to be tied to any given node (so
that I can perform ausearch --node hostName, or aureport), that's the first issue.
2. The second issue is that I need to configure sudo to enable my Special Security
Team with the ability to perform their duties using the aureport and the ausearch
commands, but I get an error that appears to be based on permissions.
I am hoping that you guys can steer me in the correct direction; and I can update my
documentation to be even a little more thorough.
Scenario2, might be more of a membership issue now that I think about it; so please
disregard as I think this is some weird 389-ds issue.
I am hoping though that someone can suggest a reason why, when I look directly at the
content of the /var/log/audit/audit.log I am not see any references to node=hostname1,
hostname2 .. hostnameN? Maybe I did misconfigure something, but I followed my own
instructions to the "T" and they didn't produce this issue.
Thank you in advance for your precious time sincerely,
Warron French, MBA, SCSA
7:52 a.m.
On Tue, 2016-05-10 at 12:31 +0000, Warron S French wrote:
Good morning everyone,
I am working on an environment where I have managed to get centralized
audit logging to work – roughly 95% properly on six (6) CentOS-6.7
workstations and a single (1) CentOS-6.7 server.
I have two problems though; and they seem somewhat minor:
1. The audit events being captured don’t seem to be tied to any
given node (so that I can perform ausearch --node hostName, or
aureport), that’s the first issue.
What have you set the configuration parameter 'name_format'
in /etc/audit/auditd.conf to?
One assumes you may want to set
name_format = fqd
or
name_format = hostname
After the change on each host, don't forget to reload the configuration
with either a sighup on the auditd process or just restart the service.
2. The second issue is that I need to configure sudo to enable my
Special Security Team with the ability to perform their duties using
the aureport and the ausearch commands, but I get an error that
appears to be based on permissions.
I recommend you show the command and resultant error in situations like
this. That way we can provide a more informed response.
I am hoping that you guys can steer me in the correct direction; and I
can update my documentation to be even a little more thorough.
Scenario2, might be more of a membership issue now that I think about
it; so please disregard as I think this is some weird 389-ds issue.
I am hoping though that someone can suggest a reason why, when I look
directly at the content of the /var/log/audit/audit.log I am not see
any references to node=hostname1, hostname2 .. hostnameN? Maybe I did
misconfigure something, but I followed my own instructions to the “T”
and they didn’t produce this issue.
Thank you in advance for your precious time sincerely,
Warron French, MBA, SCSA
--
Linux-audit mailing list
Linux-audit(a)redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
8:07 a.m.
Hello Burn, thanks for your inputs.
Oddly enough in my lab, where this is working as expected, the name_format = NONE; and
that is on my test server (server1), and also in both test clients (client1 and client2).
However, in my production environment, I would have to double check the setting
/etc/audit/auditd.conf::name_format and see what it is set to because my instructions
don't mention it; based on the email interaction with Steve Grubb.
Thanks for the prompt reply Burn.
Warron French, MBA, SCSA
-----Original Message-----
From: Burn Alting [mailto:burn@swtf.dyndns.org]
Sent: Tuesday, May 10, 2016 8:52 AM
To: Warron S French <warron.s.french(a)aero.org>
Cc: linux-audit(a)redhat.com
Subject: Re: audit-tools and SUDO
On Tue, 2016-05-10 at 12:31 +0000, Warron S French wrote:
Good morning everyone,
I am working on an environment where I have managed to get centralized
audit logging to work – roughly 95% properly on six (6) CentOS-6.7
workstations and a single (1) CentOS-6.7 server.
I have two problems though; and they seem somewhat minor:
1. The audit events being captured don’t seem to be tied to any
given node (so that I can perform ausearch --node hostName, or
aureport), that’s the first issue.
What have you set the configuration parameter 'name_format'
in /etc/audit/auditd.conf to?
One assumes you may want to set
name_format = fqd
or
name_format = hostname
After the change on each host, don't forget to reload the configuration with either a
sighup on the auditd process or just restart the service.
2. The second issue is that I need to configure sudo to enable my
Special Security Team with the ability to perform their duties using
the aureport and the ausearch commands, but I get an error that
appears to be based on permissions.
I recommend you show the command and resultant error in situations like this. That
way we can provide a more informed response.
I am hoping that you guys can steer me in the correct direction; and I
can update my documentation to be even a little more thorough.
Scenario2, might be more of a membership issue now that I think about
it; so please disregard as I think this is some weird 389-ds issue.
I am hoping though that someone can suggest a reason why, when I look
directly at the content of the /var/log/audit/audit.log I am not see
any references to node=hostname1, hostname2 .. hostnameN? Maybe I did
misconfigure something, but I followed my own instructions to the “T”
and they didn’t produce this issue.
Thank you in advance for your precious time sincerely,
Warron French, MBA, SCSA
--
Linux-audit mailing list
Linux-audit(a)redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
8:25 a.m.
On Tuesday, May 10, 2016 10:52:21 PM Burn Alting wrote:
On Tue, 2016-05-10 at 12:31 +0000, Warron S French wrote:
> Good morning everyone,
>
>
>
> I am working on an environment where I have managed to get centralized
> audit logging to work – roughly 95% properly on six (6) CentOS-6.7
> workstations and a single (1) CentOS-6.7 server.
>
>
>
> I have two problems though; and they seem somewhat minor:
>
>
>
> 1. The audit events being captured don’t seem to be tied to any
> given node (so that I can perform ausearch --node hostName, or
> aureport), that’s the first issue.
What have you set the configuration parameter 'name_format'
in /etc/audit/auditd.conf to?
One assumes you may want to set
name_format = fqd
or
name_format = hostname
After the change on each host, don't forget to reload the configuration
with either a sighup on the auditd process or just restart the service.
This would set it for the local logs. And you would need to do this on the
server that is aggregating the logs. (I think I forgot to mention that last
week.) But for the workstations, you have to set name_format in audispd.conf.
> 2. The second issue is that I need to configure sudo to
enable my
> Special Security Team with the ability to perform their duties using
> the aureport and the ausearch commands, but I get an error that
> appears to be based on permissions.
I recommend you show the command and resultant error in situations like
this. That way we can provide a more informed response.
One approach some people take is to use the log_group setting in auditd.conf.
If there is a group that the security people belong to that others don't, then
using that group name for log_group this is the easiest way and exactly why
this option exists.
-Steve
> I am hoping that you guys can steer me in the correct direction;
and I
> can update my documentation to be even a little more thorough.
>
> Scenario2, might be more of a membership issue now that I think about
> it; so please disregard as I think this is some weird 389-ds issue.
>
> I am hoping though that someone can suggest a reason why, when I look
> directly at the content of the /var/log/audit/audit.log I am not see
> any references to node=hostname1, hostname2 .. hostnameN? Maybe I did
> misconfigure something, but I followed my own instructions to the “T”
> and they didn’t produce this issue.
>
>
>
>
>
>
>
> Thank you in advance for your precious time sincerely,
>
>
>
> Warron French, MBA, SCSA
>
>
> --
> Linux-audit mailing list
> Linux-audit(a)redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
--
Linux-audit mailing list
Linux-audit(a)redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
8:44 a.m.
Replies are in-line with responses.
Warron French, MBA, SCSA
-----Original Message-----
From: Steve Grubb [mailto:sgrubb@redhat.com]
Sent: Tuesday, May 10, 2016 9:25 AM
To: linux-audit(a)redhat.com; burn(a)swtf.dyndns.org
Cc: Warron S French <warron.s.french(a)aero.org>
Subject: Re: audit-tools and SUDO
On Tuesday, May 10, 2016 10:52:21 PM Burn Alting wrote:
On Tue, 2016-05-10 at 12:31 +0000, Warron S French wrote:
> Good morning everyone,
>
>
>
> I am working on an environment where I have managed to get
> centralized audit logging to work – roughly 95% properly on six (6)
> CentOS-6.7 workstations and a single (1) CentOS-6.7 server.
>
>
>
> I have two problems though; and they seem somewhat minor:
>
>
>
> 1. The audit events being captured don’t seem to be tied to any
> given node (so that I can perform ausearch --node hostName, or
> aureport), that’s the first issue.
What have you set the configuration parameter 'name_format'
in /etc/audit/auditd.conf to?
One assumes you may want to set
name_format = fqd
or
name_format = hostname
After the change on each host, don't forget to reload the
configuration with either a sighup on the auditd process or just restart the service.
On the lab-clients ends:
In, and ONLY IN, my /etc/audisp/audispd.conf file have I set name_format=hostname, where
hostname is a literal string of 'hostname' not THE hostname; there is no
name_format reference in any other file on my lab-client machines under the directory
/etc/audisp/ anywhere. Also on my lab-client machines in the /etc/audit/auditd.conf file
the name_format variable is set to NONE.
On the lab-server end:
In the only file that I modified, /etc/audit/auditd.conf, the only variables that I
altered were:
tcp_listen_port = 60
tcp_client_ports = 60
use_libwrap = no (because I am using iptables)
The lab works as expected, but my production environment does not. %-/
This would set it for the local logs. And you would need to do this on the server that is
aggregating the logs. (I think I forgot to mention that last
week.) But for the workstations, you have to set name_format in audispd.conf.
> 2. The second issue is that I need to configure sudo to
enable my
> Special Security Team with the ability to perform their duties using
> the aureport and the ausearch commands, but I get an error that
> appears to be based on permissions.
I recommend you show the command and resultant error in situations
like this. That way we can provide a more informed response.
One approach some people take is to use the log_group setting in auditd.conf.
If there is a group that the security people belong to that others don't, then using
that group name for log_group this is the easiest way and exactly why this option exists.
-Steve
Thanks for this Steve, I am going to engage the Special Security Team, because I have
thought of another approach - making the auditors group become a local (/etc/group) file
entry instead of using 389-ds to manage this association; that way it will always be
reliable.
> I am hoping that you guys can steer me in the correct direction;
and
> I can update my documentation to be even a little more thorough.
>
> Scenario2, might be more of a membership issue now that I think
> about it; so please disregard as I think this is some weird 389-ds issue.
>
> I am hoping though that someone can suggest a reason why, when I
> look directly at the content of the /var/log/audit/audit.log I am
> not see any references to node=hostname1, hostname2 .. hostnameN?
> Maybe I did misconfigure something, but I followed my own instructions to the “T”
> and they didn’t produce this issue.
>
>
>
>
>
>
>
> Thank you in advance for your precious time sincerely,
>
>
>
> Warron French, MBA, SCSA
>
>
> --
> Linux-audit mailing list
> Linux-audit(a)redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
--
Linux-audit mailing list
Linux-audit(a)redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
9:31 a.m.
On Tuesday, May 10, 2016 01:44:50 PM Warron S French wrote:
> > I have two problems though; and they seem somewhat minor:
> >
> > 1. The audit events being captured don’t seem to be tied to any
> > given node (so that I can perform ausearch --node hostName, or
> > aureport), that’s the first issue.
>
>
> What have you set the configuration parameter 'name_format'
> in /etc/audit/auditd.conf to?
>
> One assumes you may want to set
> name_format = fqd
> or
> name_format = hostname
>
> After the change on each host, don't forget to reload the
> configuration with either a sighup on the auditd process or just restart
> the service.
On the lab-clients ends:
In, and ONLY IN, my /etc/audisp/audispd.conf file have I set
name_format=hostname, where hostname is a literal string of 'hostname' not
THE hostname;
This is correct. Did you set remote_server in /etc/audisp/audisp-remote.conf?
there is no name_format reference in any other file on my
lab-client machines under the directory /etc/audisp/ anywhere. Also on my
lab-client machines in the /etc/audit/auditd.conf file the name_format
variable is set to NONE.
On the lab-server end:
In the only file that I modified, /etc/audit/auditd.conf, the only variables
that I altered were:
tcp_listen_port = 60
tcp_client_ports = 60
use_libwrap = no (because I am using iptables)
You would want to set name_format. This way the local events on the
aggregating server have the same format.
The lab works as expected, but my production environment does not.
%-/
I would start by checking that events are coming out of the remote systems.
You can use tcpdump port 60 on the clients. After confirming that, do the same
on the server to see if events are getting there. Then look in syslog for
anything that might give a clue. And then you can also tail -f
/var/log/audit/audit.log to see if things are getting written to disk.
-Steve
10:25 a.m.
Replies are inline.
Warron French, MBA, SCSA
-----Original Message-----
From: Steve Grubb [mailto:sgrubb@redhat.com]
Sent: Tuesday, May 10, 2016 10:31 AM
To: Warron S French <warron.s.french(a)aero.org>
Cc: linux-audit(a)redhat.com; burn(a)swtf.dyndns.org
Subject: Re: audit-tools and SUDO
On Tuesday, May 10, 2016 01:44:50 PM Warron S French wrote:
> > I have two problems though; and they seem somewhat minor:
> >
> > 1. The audit events being captured don’t seem to be tied to any
> > given node (so that I can perform ausearch --node hostName, or
> > aureport), that’s the first issue.
>
>
> What have you set the configuration parameter 'name_format'
> in /etc/audit/auditd.conf to?
>
> One assumes you may want to set
> name_format = fqd
> or
> name_format = hostname
>
> After the change on each host, don't forget to reload the
> configuration with either a sighup on the auditd process or just
> restart the service.
On the lab-clients ends:
In, and ONLY IN, my /etc/audisp/audispd.conf file have I set
name_format=hostname, where hostname is a literal string of 'hostname'
not THE hostname;
This is correct. Did you set remote_server in /etc/audisp/audisp-remote.conf?
\\Yes, the /etc/audisp/audisp-remote.conf file does have remote_server =
<myServer1>.
there is no name_format reference in any other file on my lab-client
machines under the directory /etc/audisp/ anywhere. Also on my
lab-client machines in the /etc/audit/auditd.conf file the name_format
variable is set to NONE.
On the lab-server end:
In the only file that I modified, /etc/audit/auditd.conf, the only
variables that I altered were:
tcp_listen_port = 60
tcp_client_ports = 60
use_libwrap = no (because I am using iptables)
You would want to set name_format. This way the local events on the aggregating server
have the same format.
\\So, Steve, I will set name_format, on the server, to 'hostname' explicitly
without the quotes then - thank you.
The lab works as expected, but my production environment does not.
%-/
I would start by checking that events are coming out of the remote systems.
You can use tcpdump port 60 on the clients. After confirming that, do the same
on the server to see if events are getting there. Then look in syslog for
anything that might give a clue. And then you can also tail -f
/var/log/audit/audit.log to see if things are getting written to disk.
\\ Steve, I know that I am receiving inputs to the server; because I can see events that I
am purposely triggering based on 2 rules that I added and know how to cause an event; it
is just that the node=client1 (for example) aren't being sent along with the line
being recorded. Does this troubleshooting step still make sense anyway?
-Steve
10:45 a.m.
On Tuesday, May 10, 2016 03:25:36 PM Warron S French wrote:
> The lab works as expected, but my production environment does
not. %-/
I would start by checking that events are coming out of the remote systems.
You can use tcpdump port 60 on the clients. After confirming that, do the
same on the server to see if events are getting there. Then look in syslog
for anything that might give a clue. And then you can also tail -f
/var/log/audit/audit.log to see if things are getting written to disk.
\\ Steve, I know that I am receiving inputs to the server; because I can see
events that I am purposely triggering based on 2 rules that I added and
know how to cause an event; it is just that the node=client1 (for example)
aren't being sent along with the line being recorded. Does this
troubleshooting step still make sense anyway?
No. If you are getting events at the server and audispd.conf has name_format=
hostname, it should be working.
If this was set after the audit daemon on the clients started, then you need
to restart the audit daemon for the name to take effect. As written, it
collects the name one time at start up and uses it in all future events. This
could be changed but that is how its doing today.
If you restart auditd on a non-systemd OS, this will cause the admin's auid to
get stuck into the audit daemon's task structure and will cause problems. So,
the cleanest thing to do is reboot the work station so that audispd has the
hostname and your auid is not in daemons.
-Steve
12:46 p.m.
OK, thank you.
I will do/try that and see if it makes a difference and then report-back to close out this
thread.
Thanks Steve,
Warron French, MBA, SCSA
-----Original Message-----
From: Steve Grubb [mailto:sgrubb@redhat.com]
Sent: Tuesday, May 10, 2016 11:45 AM
To: Warron S French <warron.s.french(a)aero.org>
Cc: linux-audit(a)redhat.com
Subject: Re: audit-tools and SUDO
On Tuesday, May 10, 2016 03:25:36 PM Warron S French wrote:
> The lab works as expected, but my production environment does
not.
> %-/
I would start by checking that events are coming out of the remote systems.
You can use tcpdump port 60 on the clients. After confirming that, do
the same on the server to see if events are getting there. Then look
in syslog for anything that might give a clue. And then you can also
tail -f /var/log/audit/audit.log to see if things are getting written to disk.
\\ Steve, I know that I am receiving inputs to the server; because I
can see events that I am purposely triggering based on 2 rules that I
added and know how to cause an event; it is just that the node=client1
(for example) aren't being sent along with the line being recorded.
Does this troubleshooting step still make sense anyway?
No. If you are getting events at the server and audispd.conf has name_format= hostname, it
should be working.
If this was set after the audit daemon on the clients started, then you need to restart
the audit daemon for the name to take effect. As written, it collects the name one time at
start up and uses it in all future events. This could be changed but that is how its doing
today.
If you restart auditd on a non-systemd OS, this will cause the admin's auid to get
stuck into the audit daemon's task structure and will cause problems. So, the cleanest
thing to do is reboot the work station so that audispd has the hostname and your auid is
not in daemons.
-Steve
3147
days inactive
3147
days old
linux-audit@lists.linux-audit.osci.io
8 comments
3 participants
participants (3)
-
Burn Alting -
Steve Grubb -
Warron S French