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