audit-tools and SUDO

audit-tools and SUDO

[Warron S French]

[-- Attachment #1.1: Type: text/plain, Size: 1379 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 6118 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: audit-tools and SUDO

[Burn Alting]

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@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit


--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

RE: audit-tools and SUDO

[Warron S French]

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@aero.org>
Cc: linux-audit@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@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit



--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: audit-tools and SUDO

[Steve Grubb]

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@redhat.com
> > https://www.redhat.com/mailman/listinfo/linux-audit
> 
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit


--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

RE: audit-tools and SUDO

[Warron S French]

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@redhat.com; burn@swtf.dyndns.org
Cc: Warron S French <warron.s.french@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@redhat.com
> > https://www.redhat.com/mailman/listinfo/linux-audit
> 
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit


--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: audit-tools and SUDO

[Steve Grubb]

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

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

RE: audit-tools and SUDO

[Warron S French]

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@aero.org>
Cc: linux-audit@redhat.com; burn@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

--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit

Re: audit-tools and SUDO

[Steve Grubb]

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

RE: audit-tools and SUDO

[Warron S French]

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@aero.org>
Cc: linux-audit@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