* Re: Exported symbols removed in 2.5.2
From: Steve Grubb @ 2016-05-03 16:33 UTC (permalink / raw)
To: Laurent Bigonville; +Cc: linux-audit
In-Reply-To: <6c976322-72d3-d934-93c0-9695cbad6862@debian.org>
On Tuesday, May 03, 2016 05:15:01 PM Laurent Bigonville wrote:
> >> +#MISSING: 1:2.5.2-1# audit_send_user_message@Base 1:2.2.1
> >>
> >> audit_set_backlog_limit@Base 1:2.2.1
> >> audit_set_backlog_wait_time@Base 1:2.4.2
> >> audit_set_enabled@Base 1:2.2.1
> >>
> >> Is that expected that these 4 symbols have been removed?
> >
> > Yes. This corresponds to the changelog entry:
> >
> > - Revise function hiding technique to better protect audit ABI
> >
> > All functions missing are internal to the audit libraries and could cause
> > symbols collisions or worse if people start using them even though they
> > are
> > not declared in the library headers.
>
> In the private.h header file, I can see the following comment:
>
> // This is the main messaging function used internally
> // Don't hide it, it used to be a part of the public API!
> extern int audit_send_user_message(int fd, int type, hide_t hide_err,
> const char *message);
>
> So doesn't this warrant a soname bump then?
The answer is not simple. It was a hidden symbol:
hidden_proto(audit_send_user_message);
But I noticed that this broke at some point because it was hidden in old
releases but then suddenly started being visible. There has been no changes in
the hiding technique since the 1.2 release. My guess is that something changed
in gcc somewhere along the way that broke the hiding technique from Ulrich
Drepper's DSO programming guidelines.
The function was part of the public API in the 1.0.16 release. It was
deprecated/hidden in the 1.2 release which dates to 7-Apr 2006. Its been about
10 years that the function prototype has not been in libaudit.h. I would hope
that a missing prototype message would have been reported and fixed in the last
10 years. I have personally fixed use of the symbol in everything I know of 10
years ago.
The only problem people would have is in very old utilities they wrote a long
time ago, or very old versions of shadow-utils/pam. I wrote a script that
looks for that symbol in all elf files. I have to test on RHEL 4 to find the
symbol in any programs. So, I think you have a valid concern, but its been so
long that in practice it has worked itself out.
-Steve
^ permalink raw reply
* RE: audit review question
From: Warron S French @ 2016-05-03 18:28 UTC (permalink / raw)
To: Warron S French, Steve Grubb; +Cc: linux-audit@redhat.com
In-Reply-To: <BY1PR09MB0887B51125E85C4F0976D8DEC7660@BY1PR09MB0887.namprd09.prod.outlook.com>
Steve,
I typed up the instructions you provided to me on this thread, and I tested them so that I could then print and carry over to another building these implementations steps.
For the most-part implementation was very smooth. I built a tiny virtual environment with 2 client machines {client1 and client2} and a single server {server1}. I ran through the steps on the client machines as you described; and also on the server as you described. I did not stray from your guidance (I realized where below you used the word 'set' you didn't mean to use that word inside the various configurations files explicitly - so I didn't add the word 'set' anywhere.
However, upon completion I ran the command:
ausearch --start recent -m DAEMON_ACCEPT -i
and it returned with the following:
<no matches>
I did this a few times and I did have success once.
I also attempted to use the command: ausearch --host client1 and I got back <no matches>
So I thought maybe I should tail the /var/log/audit.log file to see if I saw any "hostname=client1" entries but I didn't see anything.
So, I have to ask about this part in your email::::
/etc/audisp/audispd.conf
name_format = HOSTNAME or another suitable option
Was the name_format = HOSTNAME supposed to be set to; name_format = hostname (the man page for this file indicates the lower-case version) or am I doing something else wrong? I did allow port 60/tcp through the iptables firewall (and restarted the firewall).
Thank you,
Warron French, MBA, SCSA
-----Original Message-----
From: linux-audit-bounces@redhat.com [mailto:linux-audit-bounces@redhat.com] On Behalf Of Warron S French
Sent: Friday, April 29, 2016 4:21 PM
To: Steve Grubb <sgrubb@redhat.com>
Cc: linux-audit@redhat.com
Subject: [WARNING: SPOOFED E-MAIL--Non-Aerospace Sender] RE: audit review question
Thank you Steve. That is very helpful. Have a nice weekend.
Warron French, MBA, SCSA
-----Original Message-----
From: Steve Grubb [mailto:sgrubb@redhat.com]
Sent: Friday, April 29, 2016 3:18 PM
To: Warron S French <warron.s.french@aero.org>
Cc: linux-audit@redhat.com
Subject: Re: audit review question
On Thursday, April 28, 2016 03:50:33 PM Warron S French wrote:
> Steve, thanks for your replies to all of my questions.
>
> Can you please send me a walk through document for trying to send the
> 6 workstations and 1 servers audit-data into the same directory structure?
> Something that will definitely work, please?
>
> I have a VM environment that I can make changes on and then test, so I
> would be very grateful for any cooperation I could get.
>
> My intent is to have all the machines log data to the same machine. I
> want the system security auditors to be able to use the typical
> aureport and ausearch commands (that I know you write).
>
> So, I have to ask, can this be done, and the audit logs be parsed on a
> per hostname-basis? Can they be stored in directories that are
> /var/log/audit/YYYY/MM/DD/Hostname_audit.log format - or is that
> inadvisable considering the intention to continue to support/use the two
> commands: aureport and ausearch? What would you advise - please?
The theory of operation is to put all events in one log and then separate them later by using a '--node' command line option.
> I am aware of the /etc/audisp directory, which I am sure is associated
> with the audispd daemon, but I don't have the foggiest clue of how to
> configure them together.
For a clear text transport
on the client side:
/etc/audisp/plugins.d/au-remote.conf
set active = yes
/etc/audisp/audisp-remote.conf
set remote_server = to the machine you are aggregating to if you need lossless transport, set mode = forward set local_port = 60
/etc/audisp/audispd.conf
name_format = HOSTNAME or another suitable option
On the server
/etc/audit/auditd.conf
set tcp_listen_port = 60
set tcp_client_ports = 60
set use_libwrap = yes
in /etc/hosts.allow
auditd: 1.2.4. or some subnet. You can read about all the tcp-wrappers config
options elsewhere.
restart the server
restart clients
To check if working:
ausearch --start recent -m DAEMON_ACCEPT -i
To get an encrypted transport, you need to use kerberos and that is beyond an email for setting it up.
One of these days I'd like to add TLS as an option, too. But it'll be a little longer. You might be able to vpn things to one another in the mean time. Or maybe use a ssh tunnel.
> It is only because of stumbling around for the last 2 years (and very
> feverishly the last 2 days) that I have learned how to use the
> auditctl and aureport commands. I want to do this correctly, and I
> want to do it consistently with "industry standards" so that I can
> continue to get support from people like the folks in this 'forum.'
Sure.
-Steve
>
> Thanks, for any advice and useful links you can share. I am certain
> that as you provide them and I read them it will force me to ask even
> more questions. I hope you don't mind.
>
> Warron French, MBA, SCSA
>
> -----Original Message-----
> From: Steve Grubb [mailto:sgrubb@redhat.com]
> Sent: Thursday, April 28, 2016 11:10 AM
> To: linux-audit@redhat.com
> Cc: Warron S French <warron.s.french@aero.org>
> Subject: Re: audit review question
>
> On Wednesday, April 27, 2016 09:10:39 PM Warron S French wrote:
> > I have a scenario that I need a little help understanding how to
> > work through in an isolated environment of 1 server and 6
> > workstations (7 machines). The 7 machines are all running CentOS-6.7
> > and selinux = disabled.
> >
> > All 6 workstations are configured through rsyslog.conf to send audit
> > data to the server, and I have (but apparently not successfully
> > configured general system messages to also report back to the same
> > server). I am using the conventional filesystems for each, but the
> > directory structure below is different.
>
> Rsyslog will likely mangle the audit lines such that its no longer in
> the native audit format. I don't know if its headers can be stripped
> as it writes to disk.
> > For audit, I use, /var/log/audit/2016/04/27/wk{1..6}_audit.log the
> > directory per day and per month and per year are auto created
> > (miraculously). For system messages, and I know this isn't the forum
> > to get help on this so I will only list the directory is -
> > /var/log/2016/04/27/wk{1..6}_syslog.log.
> >
> > Now that I am doing this, and successfully, I want to test that the
> > security auditors will be able to do their job properly, as well as
> > I am trying to comply with some security constraint that requires me
> > to centralize the logdata into a single server (hence the major
> > driver for all of this).
> >
> > I know that there is the aureport and ausearch command, but I am not
> > sure that I am able to figure out the correct command-line structure
> > to test that audit-data is getting into the appropriate file, on
> > each day of the year, on a per serverName basis.
> >
> > If a real-world situation occurred that the Security Auditors were
> > asking to find out how many machines did userX attempt to log into,
> > what would be the appropriate command for the example audit
> > directory I listed above
> > (/var/log/audit/2016/04/27/wk{1..6}_audit.log), because I am not
> > sure I am running the command with the appropriate switches to scan the files properly?
> >
> > I used:
> >
> > * aureport -if /var/log/audit/2016/04/27/ and it didn't like the
> > input,
>
> Probably due to the header it inserts to each record. But this is how
> you should do it.
> > * aureport -if /var/log/audit/2016/04/27/* and it didn't like the
> > input, am I using the command improperly?
>
> You shouldn't need the '*'. If the passed option is a dir, then it
> automatically looks for more files. But note that the native rotation is
> audit.log <- newest
> audit.log.1
> audit.log.2
> audit.log.3 <- oldest
>
> rsyslog would also have to use this scheme. I have never investigated
> if it does. That does not means that a wrapper script couldn't be made
> to walk the files in rsyslog's order and send them to aureport via
> stdin. You could probably even add a sed command to strip the rsyslog
> headers from each record.
>
> Not the best answer, but once it hits rsyslog, it can change the
> record in ways that unknown to me.
>
> -Steve
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Re: audit review question
From: Steve Grubb @ 2016-05-03 18:53 UTC (permalink / raw)
To: Warron S French; +Cc: linux-audit@redhat.com
In-Reply-To: <BY1PR09MB08873DD3C5E87136ECB4D21BC77A0@BY1PR09MB0887.namprd09.prod.outlook.com>
On Tuesday, May 03, 2016 06:28:12 PM Warron S French wrote:
> Steve,
> I typed up the instructions you provided to me on this thread, and I
> tested them so that I could then print and carry over to another building
> these implementations steps.
>
> For the most-part implementation was very smooth. I built a tiny virtual
> environment with 2 client machines {client1 and client2} and a single
> server {server1}. I ran through the steps on the client machines as you
> described; and also on the server as you described. I did not stray from
> your guidance (I realized where below you used the word 'set' you didn't
> mean to use that word inside the various configurations files explicitly -
> so I didn't add the word 'set' anywhere.
>
> However, upon completion I ran the command:
> ausearch --start recent -m DAEMON_ACCEPT -i
This would be on the aggregating server. The accept events record a client
connecting to the aggregating server.
> and it returned with the following:
> <no matches>
The assuming this was run on the server, the client is not connecting to the
server. Was there anything in the client's syslog?
> I did this a few times and I did have success once.
>
> I also attempted to use the command: ausearch --host client1 and
I got
> back <no matches> So I thought maybe I should tail the
/var/log/audit.log
> file to see if I saw any "hostname=client1" entries but I didn't see
> anything.
>
> So, I have to ask about this part in your email::::
> /etc/audisp/audispd.conf
> name_format = HOSTNAME or another suitable option
>
> Was the name_format = HOSTNAME supposed to be set to; name_format =
> hostname (the man page for this file indicates the lower-case version) or
> am I doing something else wrong? I did allow port 60/tcp through the
> iptables firewall (and restarted the firewall).
Its case insensitive.
Check the syslogs on client and server, There should be something there if the
connection is not working.
-Steve
> -----Original Message-----
> From: linux-audit-bounces@redhat.com [mailto:linux-audit-bounces@redhat.com]
> On Behalf Of Warron S French Sent: Friday, April 29, 2016 4:21 PM
> To: Steve Grubb <sgrubb@redhat.com>
> Cc: linux-audit@redhat.com
> Subject: [WARNING: SPOOFED E-MAIL--Non-Aerospace Sender] RE: audit review
> question
>
> Thank you Steve. That is very helpful. Have a nice weekend.
>
>
> Warron French, MBA, SCSA
>
>
> -----Original Message-----
> From: Steve Grubb [mailto:sgrubb@redhat.com]
> Sent: Friday, April 29, 2016 3:18 PM
> To: Warron S French <warron.s.french@aero.org>
> Cc: linux-audit@redhat.com
> Subject: Re: audit review question
>
> On Thursday, April 28, 2016 03:50:33 PM Warron S French wrote:
> > Steve, thanks for your replies to all of my questions.
> >
> > Can you please send me a walk through document for trying to send the
> > 6 workstations and 1 servers audit-data into the same directory structure?
> > Something that will definitely work, please?
> >
> > I have a VM environment that I can make changes on and then test, so I
> > would be very grateful for any cooperation I could get.
> >
> > My intent is to have all the machines log data to the same machine. I
> > want the system security auditors to be able to use the typical
> > aureport and ausearch commands (that I know you write).
> >
> > So, I have to ask, can this be done, and the audit logs be parsed on a
> > per hostname-basis? Can they be stored in directories that are
> > /var/log/audit/YYYY/MM/DD/Hostname_audit.log format - or is that
> > inadvisable considering the intention to continue to support/use the two
> > commands: aureport and ausearch? What would you advise - please?
>
> The theory of operation is to put all events in one log and then separate
> them later by using a '--node' command line option.
> > I am aware of the /etc/audisp directory, which I am sure is associated
> > with the audispd daemon, but I don't have the foggiest clue of how to
> > configure them together.
>
> For a clear text transport
>
> on the client side:
>
> /etc/audisp/plugins.d/au-remote.conf
> set active = yes
>
> /etc/audisp/audisp-remote.conf
> set remote_server = to the machine you are aggregating to if you need
> lossless transport, set mode = forward set local_port = 60
>
> /etc/audisp/audispd.conf
> name_format = HOSTNAME or another suitable option
>
> On the server
>
> /etc/audit/auditd.conf
> set tcp_listen_port = 60
> set tcp_client_ports = 60
> set use_libwrap = yes
>
> in /etc/hosts.allow
> auditd: 1.2.4. or some subnet. You can read about all the tcp-wrappers
> config options elsewhere.
>
> restart the server
> restart clients
>
> To check if working:
> ausearch --start recent -m DAEMON_ACCEPT -i
>
> To get an encrypted transport, you need to use kerberos and that is beyond
> an email for setting it up.
>
> One of these days I'd like to add TLS as an option, too. But it'll be a
> little longer. You might be able to vpn things to one another in the mean
> time. Or maybe use a ssh tunnel.
> > It is only because of stumbling around for the last 2 years (and very
> > feverishly the last 2 days) that I have learned how to use the
> > auditctl and aureport commands. I want to do this correctly, and I
> > want to do it consistently with "industry standards" so that I can
> > continue to get support from people like the folks in this 'forum.'
>
> Sure.
>
> -Steve
>
> > Thanks, for any advice and useful links you can share. I am certain
> > that as you provide them and I read them it will force me to ask even
> > more questions. I hope you don't mind.
> >
> > Warron French, MBA, SCSA
> >
> > -----Original Message-----
> > From: Steve Grubb [mailto:sgrubb@redhat.com]
> > Sent: Thursday, April 28, 2016 11:10 AM
> > To: linux-audit@redhat.com
> > Cc: Warron S French <warron.s.french@aero.org>
> > Subject: Re: audit review question
> >
> > On Wednesday, April 27, 2016 09:10:39 PM Warron S French wrote:
> > > I have a scenario that I need a little help understanding how to
> > > work through in an isolated environment of 1 server and 6
> > > workstations (7 machines). The 7 machines are all running CentOS-6.7
> > > and selinux = disabled.
> > >
> > > All 6 workstations are configured through rsyslog.conf to send audit
> > > data to the server, and I have (but apparently not successfully
> > > configured general system messages to also report back to the same
> > > server). I am using the conventional filesystems for each, but the
> > > directory structure below is different.
> >
> > Rsyslog will likely mangle the audit lines such that its no longer in
> > the native audit format. I don't know if its headers can be stripped
> > as it writes to disk.
> >
> > > For audit, I use, /var/log/audit/2016/04/27/wk{1..6}_audit.log the
> > > directory per day and per month and per year are auto created
> > > (miraculously). For system messages, and I know this isn't the forum
> > > to get help on this so I will only list the directory is -
> > > /var/log/2016/04/27/wk{1..6}_syslog.log.
> > >
> > > Now that I am doing this, and successfully, I want to test that the
> > > security auditors will be able to do their job properly, as well as
> > > I am trying to comply with some security constraint that requires me
> > > to centralize the logdata into a single server (hence the major
> > > driver for all of this).
> > >
> > > I know that there is the aureport and ausearch command, but I am not
> > > sure that I am able to figure out the correct command-line structure
> > > to test that audit-data is getting into the appropriate file, on
> > > each day of the year, on a per serverName basis.
> > >
> > > If a real-world situation occurred that the Security Auditors were
> > > asking to find out how many machines did userX attempt to log into,
> > > what would be the appropriate command for the example audit
> > > directory I listed above
> > > (/var/log/audit/2016/04/27/wk{1..6}_audit.log), because I am not
> > > sure I am running the command with the appropriate switches to scan the
> > > files properly?
> > >
> > > I used:
> > >
> > > * aureport -if /var/log/audit/2016/04/27/ and it didn't like the
> > > input,
> >
> > Probably due to the header it inserts to each record. But this is how
> > you should do it.
> >
> > > * aureport -if /var/log/audit/2016/04/27/* and it didn't like
> > > the
> > > input, am I using the command improperly?
> >
> > You shouldn't need the '*'. If the passed option is a dir, then it
> > automatically looks for more files. But note that the native rotation is
> > audit.log <- newest
> > audit.log.1
> > audit.log.2
> > audit.log.3 <- oldest
> >
> > rsyslog would also have to use this scheme. I have never investigated
> > if it does. That does not means that a wrapper script couldn't be made
> > to walk the files in rsyslog's order and send them to aureport via
> > stdin. You could probably even add a sed command to strip the rsyslog
> > headers from each record.
> >
> > Not the best answer, but once it hits rsyslog, it can change the
> > record in ways that unknown to me.
> >
> > -Steve
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* RE: audit review question
From: Warron S French @ 2016-05-03 19:30 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit@redhat.com
In-Reply-To: <1489197.J3cpUzIM1N@x2>
I checked in /var/log/messages for both:
I did not see an entry before, but now that I have rebooted both machines in the last 5 minutes, your suggested command:
ausearch --start recent -m DAEMON_ACCEPT -i
actually works.
However, before rebooting, client1 had nothing in its /var/log/messages file, and the messages log-file on client2 did had the following result:
May 3 15:12:34 client2 audisp-remote: Connected to server1
So, I think this may now be a matter of me understanding the ausearch command more now; like what does --start recent mean - as in, what is your definition for a timeframe of "recent;" which after typing more of the email message below I also learned recent= 10minutes ago or less.
Also, I am noticing that if I altered the value of the variable name_format to the lower-case value of hostname; things behave a little bit better. At least with ausearch and aureport I can use the --node switch with an appropriate argument; I was expecting it to work with -hn or --host.
I was expecting to use the term --hostname client1, but if I need to adapt my thinking to understand that I need to use --node I am totally fine with that.
Thank you Steve, again, for your detailed support. For me this was an uphill battle, and you leveled the field for me (and I learned something).
Warron French, MBA, SCSA
-----Original Message-----
From: Steve Grubb [mailto:sgrubb@redhat.com]
Sent: Tuesday, May 03, 2016 2:53 PM
To: Warron S French <warron.s.french@aero.org>
Cc: linux-audit@redhat.com
Subject: Re: audit review question
On Tuesday, May 03, 2016 06:28:12 PM Warron S French wrote:
> Steve,
> I typed up the instructions you provided to me on this thread, and I
> tested them so that I could then print and carry over to another building
> these implementations steps.
>
> For the most-part implementation was very smooth. I built a tiny
> virtual environment with 2 client machines {client1 and client2} and a
> single server {server1}. I ran through the steps on the client
> machines as you described; and also on the server as you described. I
> did not stray from your guidance (I realized where below you used the
> word 'set' you didn't mean to use that word inside the various
> configurations files explicitly - so I didn't add the word 'set' anywhere.
>
> However, upon completion I ran the command:
> ausearch --start recent -m DAEMON_ACCEPT -i
This would be on the aggregating server. The accept events record a client connecting to the aggregating server.
> and it returned with the following:
> <no matches>
The assuming this was run on the server, the client is not connecting to the
server. Was there anything in the client's syslog?
> I did this a few times and I did have success once.
>
> I also attempted to use the command: ausearch --host client1 and
I got
> back <no matches> So I thought maybe I should tail the
/var/log/audit.log
> file to see if I saw any "hostname=client1" entries but I didn't see
> anything.
>
> So, I have to ask about this part in your email::::
> /etc/audisp/audispd.conf
> name_format = HOSTNAME or another suitable option
>
> Was the name_format = HOSTNAME supposed to be set to; name_format =
> hostname (the man page for this file indicates the lower-case version) or
> am I doing something else wrong? I did allow port 60/tcp through the
> iptables firewall (and restarted the firewall).
Its case insensitive.
Check the syslogs on client and server, There should be something there if the
connection is not working.
-Steve
> -----Original Message-----
> From: linux-audit-bounces@redhat.com [mailto:linux-audit-bounces@redhat.com]
> On Behalf Of Warron S French Sent: Friday, April 29, 2016 4:21 PM
> To: Steve Grubb <sgrubb@redhat.com>
> Cc: linux-audit@redhat.com
> Subject: [WARNING: SPOOFED E-MAIL--Non-Aerospace Sender] RE: audit review
> question
>
> Thank you Steve. That is very helpful. Have a nice weekend.
>
>
> Warron French, MBA, SCSA
>
>
> -----Original Message-----
> From: Steve Grubb [mailto:sgrubb@redhat.com]
> Sent: Friday, April 29, 2016 3:18 PM
> To: Warron S French <warron.s.french@aero.org>
> Cc: linux-audit@redhat.com
> Subject: Re: audit review question
>
> On Thursday, April 28, 2016 03:50:33 PM Warron S French wrote:
> > Steve, thanks for your replies to all of my questions.
> >
> > Can you please send me a walk through document for trying to send the
> > 6 workstations and 1 servers audit-data into the same directory structure?
> > Something that will definitely work, please?
> >
> > I have a VM environment that I can make changes on and then test, so I
> > would be very grateful for any cooperation I could get.
> >
> > My intent is to have all the machines log data to the same machine. I
> > want the system security auditors to be able to use the typical
> > aureport and ausearch commands (that I know you write).
> >
> > So, I have to ask, can this be done, and the audit logs be parsed on a
> > per hostname-basis? Can they be stored in directories that are
> > /var/log/audit/YYYY/MM/DD/Hostname_audit.log format - or is that
> > inadvisable considering the intention to continue to support/use the two
> > commands: aureport and ausearch? What would you advise - please?
>
> The theory of operation is to put all events in one log and then separate
> them later by using a '--node' command line option.
> > I am aware of the /etc/audisp directory, which I am sure is associated
> > with the audispd daemon, but I don't have the foggiest clue of how to
> > configure them together.
>
> For a clear text transport
>
> on the client side:
>
> /etc/audisp/plugins.d/au-remote.conf
> set active = yes
>
> /etc/audisp/audisp-remote.conf
> set remote_server = to the machine you are aggregating to if you need
> lossless transport, set mode = forward set local_port = 60
>
> /etc/audisp/audispd.conf
> name_format = HOSTNAME or another suitable option
>
> On the server
>
> /etc/audit/auditd.conf
> set tcp_listen_port = 60
> set tcp_client_ports = 60
> set use_libwrap = yes
>
> in /etc/hosts.allow
> auditd: 1.2.4. or some subnet. You can read about all the tcp-wrappers
> config options elsewhere.
>
> restart the server
> restart clients
>
> To check if working:
> ausearch --start recent -m DAEMON_ACCEPT -i
>
> To get an encrypted transport, you need to use kerberos and that is beyond
> an email for setting it up.
>
> One of these days I'd like to add TLS as an option, too. But it'll be a
> little longer. You might be able to vpn things to one another in the mean
> time. Or maybe use a ssh tunnel.
> > It is only because of stumbling around for the last 2 years (and very
> > feverishly the last 2 days) that I have learned how to use the
> > auditctl and aureport commands. I want to do this correctly, and I
> > want to do it consistently with "industry standards" so that I can
> > continue to get support from people like the folks in this 'forum.'
>
> Sure.
>
> -Steve
>
> > Thanks, for any advice and useful links you can share. I am certain
> > that as you provide them and I read them it will force me to ask even
> > more questions. I hope you don't mind.
> >
> > Warron French, MBA, SCSA
> >
> > -----Original Message-----
> > From: Steve Grubb [mailto:sgrubb@redhat.com]
> > Sent: Thursday, April 28, 2016 11:10 AM
> > To: linux-audit@redhat.com
> > Cc: Warron S French <warron.s.french@aero.org>
> > Subject: Re: audit review question
> >
> > On Wednesday, April 27, 2016 09:10:39 PM Warron S French wrote:
> > > I have a scenario that I need a little help understanding how to
> > > work through in an isolated environment of 1 server and 6
> > > workstations (7 machines). The 7 machines are all running CentOS-6.7
> > > and selinux = disabled.
> > >
> > > All 6 workstations are configured through rsyslog.conf to send audit
> > > data to the server, and I have (but apparently not successfully
> > > configured general system messages to also report back to the same
> > > server). I am using the conventional filesystems for each, but the
> > > directory structure below is different.
> >
> > Rsyslog will likely mangle the audit lines such that its no longer in
> > the native audit format. I don't know if its headers can be stripped
> > as it writes to disk.
> >
> > > For audit, I use, /var/log/audit/2016/04/27/wk{1..6}_audit.log the
> > > directory per day and per month and per year are auto created
> > > (miraculously). For system messages, and I know this isn't the forum
> > > to get help on this so I will only list the directory is -
> > > /var/log/2016/04/27/wk{1..6}_syslog.log.
> > >
> > > Now that I am doing this, and successfully, I want to test that the
> > > security auditors will be able to do their job properly, as well as
> > > I am trying to comply with some security constraint that requires me
> > > to centralize the logdata into a single server (hence the major
> > > driver for all of this).
> > >
> > > I know that there is the aureport and ausearch command, but I am not
> > > sure that I am able to figure out the correct command-line structure
> > > to test that audit-data is getting into the appropriate file, on
> > > each day of the year, on a per serverName basis.
> > >
> > > If a real-world situation occurred that the Security Auditors were
> > > asking to find out how many machines did userX attempt to log into,
> > > what would be the appropriate command for the example audit
> > > directory I listed above
> > > (/var/log/audit/2016/04/27/wk{1..6}_audit.log), because I am not
> > > sure I am running the command with the appropriate switches to scan the
> > > files properly?
> > >
> > > I used:
> > >
> > > * aureport -if /var/log/audit/2016/04/27/ and it didn't like the
> > > input,
> >
> > Probably due to the header it inserts to each record. But this is how
> > you should do it.
> >
> > > * aureport -if /var/log/audit/2016/04/27/* and it didn't like
> > > the
> > > input, am I using the command improperly?
> >
> > You shouldn't need the '*'. If the passed option is a dir, then it
> > automatically looks for more files. But note that the native rotation is
> > audit.log <- newest
> > audit.log.1
> > audit.log.2
> > audit.log.3 <- oldest
> >
> > rsyslog would also have to use this scheme. I have never investigated
> > if it does. That does not means that a wrapper script couldn't be made
> > to walk the files in rsyslog's order and send them to aureport via
> > stdin. You could probably even add a sed command to strip the rsyslog
> > headers from each record.
> >
> > Not the best answer, but once it hits rsyslog, it can change the
> > record in ways that unknown to me.
> >
> > -Steve
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Re: audit review question
From: Steve Grubb @ 2016-05-03 19:38 UTC (permalink / raw)
To: Warron S French; +Cc: linux-audit@redhat.com
In-Reply-To: <BY1PR09MB0887A9A9FA528DAE17292F51C77A0@BY1PR09MB0887.namprd09.prod.outlook.com>
On Tuesday, May 03, 2016 07:30:51 PM Warron S French wrote:
> I checked in /var/log/messages for both:
>
> I did not see an entry before, but now that I have rebooted both machines in
> the last 5 minutes, your suggested command: ausearch --start recent -m
> DAEMON_ACCEPT -i
>
> actually works.
>
> However, before rebooting, client1 had nothing in its /var/log/messages
> file, and the messages log-file on client2 did had the following result:
> May 3 15:12:34 client2 audisp-remote: Connected to server1
>
> So, I think this may now be a matter of me understanding the ausearch
> command more now; like what does --start recent mean - as in, what is your
> definition for a timeframe of "recent;" which after typing more of the
> email message below I also learned recent= 10minutes ago or less.
Correct. The assumption is that you do the config, restart the audit daemon,
and then check that its working. If time elapses then its no longer recent and
you need to resort to other time parameters.
> Also, I am noticing that if I altered the value of the variable name_format
> to the lower-case value of hostname; things behave a little bit better. At
> least with ausearch and aureport I can use the --node switch with an
> appropriate argument; I was expecting it to work with -hn or --host.
The host switch targets the host= field in events. Pam is about the only thing
that uses it. As for name_format, It has a couple other ways to name systems
if the hostname is not the best. Some people like fully qualified domain names.
> I was expecting to use the term --hostname client1, but if I need to adapt
> my thinking to understand that I need to use --node I am totally fine with
> that.
Yes. --node is the switch to select the exact audit stream from remote
systems.
-Steve
> Thank you Steve, again, for your detailed support. For me this was an
> uphill battle, and you leveled the field for me (and I learned something).
>
> Warron French, MBA, SCSA
>
> -----Original Message-----
> From: Steve Grubb [mailto:sgrubb@redhat.com]
> Sent: Tuesday, May 03, 2016 2:53 PM
> To: Warron S French <warron.s.french@aero.org>
> Cc: linux-audit@redhat.com
> Subject: Re: audit review question
>
> On Tuesday, May 03, 2016 06:28:12 PM Warron S French wrote:
> > Steve,
> >
> > I typed up the instructions you provided to me on this thread, and I
> > tested them so that I could then print and carry over to another building
> > these implementations steps.
> >
> > For the most-part implementation was very smooth. I built a tiny
> > virtual environment with 2 client machines {client1 and client2} and a
> > single server {server1}. I ran through the steps on the client
> > machines as you described; and also on the server as you described. I
> > did not stray from your guidance (I realized where below you used the
> > word 'set' you didn't mean to use that word inside the various
> > configurations files explicitly - so I didn't add the word 'set' anywhere.
> >
> > However, upon completion I ran the command:
> > ausearch --start recent -m DAEMON_ACCEPT -i
>
> This would be on the aggregating server. The accept events record a client
> connecting to the aggregating server.
> > and it returned with the following:
> > <no matches>
>
> The assuming this was run on the server, the client is not connecting to the
> server. Was there anything in the client's syslog?
>
> > I did this a few times and I did have success once.
> >
> > I also attempted to use the command: ausearch --host client1 and
>
> I got
>
> > back <no matches> So I thought maybe I should tail the
>
> /var/log/audit.log
>
> > file to see if I saw any "hostname=client1" entries but I didn't see
> > anything.
> >
> > So, I have to ask about this part in your email::::
> > /etc/audisp/audispd.conf
> > name_format = HOSTNAME or another suitable option
> >
> > Was the name_format = HOSTNAME supposed to be set to; name_format =
> > hostname (the man page for this file indicates the lower-case version) or
> > am I doing something else wrong? I did allow port 60/tcp through the
> > iptables firewall (and restarted the firewall).
>
> Its case insensitive.
>
> Check the syslogs on client and server, There should be something there if
> the connection is not working.
>
> -Steve
>
> > -----Original Message-----
> > From: linux-audit-bounces@redhat.com
> > [mailto:linux-audit-bounces@redhat.com] On Behalf Of Warron S French
> > Sent: Friday, April 29, 2016 4:21 PM
> > To: Steve Grubb <sgrubb@redhat.com>
> > Cc: linux-audit@redhat.com
> > Subject: [WARNING: SPOOFED E-MAIL--Non-Aerospace Sender] RE: audit review
> > question
> >
> > Thank you Steve. That is very helpful. Have a nice weekend.
> >
> >
> > Warron French, MBA, SCSA
> >
> >
> > -----Original Message-----
> > From: Steve Grubb [mailto:sgrubb@redhat.com]
> > Sent: Friday, April 29, 2016 3:18 PM
> > To: Warron S French <warron.s.french@aero.org>
> > Cc: linux-audit@redhat.com
> > Subject: Re: audit review question
> >
> > On Thursday, April 28, 2016 03:50:33 PM Warron S French wrote:
> > > Steve, thanks for your replies to all of my questions.
> > >
> > > Can you please send me a walk through document for trying to send the
> > > 6 workstations and 1 servers audit-data into the same directory
> > > structure?
> > > Something that will definitely work, please?
> > >
> > > I have a VM environment that I can make changes on and then test, so I
> > > would be very grateful for any cooperation I could get.
> > >
> > > My intent is to have all the machines log data to the same machine. I
> > > want the system security auditors to be able to use the typical
> > > aureport and ausearch commands (that I know you write).
> > >
> > > So, I have to ask, can this be done, and the audit logs be parsed on a
> > > per hostname-basis? Can they be stored in directories that are
> > > /var/log/audit/YYYY/MM/DD/Hostname_audit.log format - or is that
> > > inadvisable considering the intention to continue to support/use the two
> > > commands: aureport and ausearch? What would you advise - please?
> >
> > The theory of operation is to put all events in one log and then separate
> > them later by using a '--node' command line option.
> >
> > > I am aware of the /etc/audisp directory, which I am sure is associated
> > > with the audispd daemon, but I don't have the foggiest clue of how to
> > > configure them together.
> >
> > For a clear text transport
> >
> > on the client side:
> >
> > /etc/audisp/plugins.d/au-remote.conf
> > set active = yes
> >
> > /etc/audisp/audisp-remote.conf
> > set remote_server = to the machine you are aggregating to if you need
> > lossless transport, set mode = forward set local_port = 60
> >
> > /etc/audisp/audispd.conf
> > name_format = HOSTNAME or another suitable option
> >
> > On the server
> >
> > /etc/audit/auditd.conf
> > set tcp_listen_port = 60
> > set tcp_client_ports = 60
> > set use_libwrap = yes
> >
> > in /etc/hosts.allow
> > auditd: 1.2.4. or some subnet. You can read about all the tcp-wrappers
> > config options elsewhere.
> >
> > restart the server
> > restart clients
> >
> > To check if working:
> > ausearch --start recent -m DAEMON_ACCEPT -i
> >
> > To get an encrypted transport, you need to use kerberos and that is beyond
> > an email for setting it up.
> >
> > One of these days I'd like to add TLS as an option, too. But it'll be a
> > little longer. You might be able to vpn things to one another in the mean
> > time. Or maybe use a ssh tunnel.
> >
> > > It is only because of stumbling around for the last 2 years (and very
> > > feverishly the last 2 days) that I have learned how to use the
> > > auditctl and aureport commands. I want to do this correctly, and I
> > > want to do it consistently with "industry standards" so that I can
> > > continue to get support from people like the folks in this 'forum.'
> >
> > Sure.
> >
> > -Steve
> >
> > > Thanks, for any advice and useful links you can share. I am certain
> > > that as you provide them and I read them it will force me to ask even
> > > more questions. I hope you don't mind.
> > >
> > > Warron French, MBA, SCSA
> > >
> > > -----Original Message-----
> > > From: Steve Grubb [mailto:sgrubb@redhat.com]
> > > Sent: Thursday, April 28, 2016 11:10 AM
> > > To: linux-audit@redhat.com
> > > Cc: Warron S French <warron.s.french@aero.org>
> > > Subject: Re: audit review question
> > >
> > > On Wednesday, April 27, 2016 09:10:39 PM Warron S French wrote:
> > > > I have a scenario that I need a little help understanding how to
> > > > work through in an isolated environment of 1 server and 6
> > > > workstations (7 machines). The 7 machines are all running CentOS-6.7
> > > > and selinux = disabled.
> > > >
> > > > All 6 workstations are configured through rsyslog.conf to send audit
> > > > data to the server, and I have (but apparently not successfully
> > > > configured general system messages to also report back to the same
> > > > server). I am using the conventional filesystems for each, but the
> > > > directory structure below is different.
> > >
> > > Rsyslog will likely mangle the audit lines such that its no longer in
> > > the native audit format. I don't know if its headers can be stripped
> > > as it writes to disk.
> > >
> > > > For audit, I use, /var/log/audit/2016/04/27/wk{1..6}_audit.log the
> > > > directory per day and per month and per year are auto created
> > > > (miraculously). For system messages, and I know this isn't the forum
> > > > to get help on this so I will only list the directory is -
> > > > /var/log/2016/04/27/wk{1..6}_syslog.log.
> > > >
> > > > Now that I am doing this, and successfully, I want to test that the
> > > > security auditors will be able to do their job properly, as well as
> > > > I am trying to comply with some security constraint that requires me
> > > > to centralize the logdata into a single server (hence the major
> > > > driver for all of this).
> > > >
> > > > I know that there is the aureport and ausearch command, but I am not
> > > > sure that I am able to figure out the correct command-line structure
> > > > to test that audit-data is getting into the appropriate file, on
> > > > each day of the year, on a per serverName basis.
> > > >
> > > > If a real-world situation occurred that the Security Auditors were
> > > > asking to find out how many machines did userX attempt to log into,
> > > > what would be the appropriate command for the example audit
> > > > directory I listed above
> > > > (/var/log/audit/2016/04/27/wk{1..6}_audit.log), because I am not
> > > > sure I am running the command with the appropriate switches to scan
> > > > the
> > > > files properly?
> > > >
> > > > I used:
> > > >
> > > > * aureport -if /var/log/audit/2016/04/27/ and it didn't like
> > > > the
> > > > input,
> > >
> > > Probably due to the header it inserts to each record. But this is how
> > > you should do it.
> > >
> > > > * aureport -if /var/log/audit/2016/04/27/* and it didn't like
> > > > the
> > > > input, am I using the command improperly?
> > >
> > > You shouldn't need the '*'. If the passed option is a dir, then it
> > > automatically looks for more files. But note that the native rotation is
> > > audit.log <- newest
> > > audit.log.1
> > > audit.log.2
> > > audit.log.3 <- oldest
> > >
> > > rsyslog would also have to use this scheme. I have never investigated
> > > if it does. That does not means that a wrapper script couldn't be made
> > > to walk the files in rsyslog's order and send them to aureport via
> > > stdin. You could probably even add a sed command to strip the rsyslog
> > > headers from each record.
> > >
> > > Not the best answer, but once it hits rsyslog, it can change the
> > > record in ways that unknown to me.
> > >
> > > -Steve
> >
> > --
> > Linux-audit mailing list
> > Linux-audit@redhat.com
> > https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* RE: audit review question
From: Warron S French @ 2016-05-03 19:54 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit@redhat.com
In-Reply-To: <3553909.5TFhIHL3ic@x2>
Cool! I think I am ready to move to my real system and implement this with my newfound understanding of the Linux Audit configurations and commands.
I truly appreciate your help. Thank you,
Warron French, MBA, SCSA
-----Original Message-----
From: Steve Grubb [mailto:sgrubb@redhat.com]
Sent: Tuesday, May 03, 2016 3:38 PM
To: Warron S French <warron.s.french@aero.org>
Cc: linux-audit@redhat.com
Subject: Re: audit review question
On Tuesday, May 03, 2016 07:30:51 PM Warron S French wrote:
> I checked in /var/log/messages for both:
>
> I did not see an entry before, but now that I have rebooted both
> machines in the last 5 minutes, your suggested command: ausearch
> --start recent -m DAEMON_ACCEPT -i
>
> actually works.
>
> However, before rebooting, client1 had nothing in its
> /var/log/messages file, and the messages log-file on client2 did had the following result:
> May 3 15:12:34 client2 audisp-remote: Connected to server1
>
> So, I think this may now be a matter of me understanding the ausearch
> command more now; like what does --start recent mean - as in, what is
> your definition for a timeframe of "recent;" which after typing more
> of the email message below I also learned recent= 10minutes ago or less.
Correct. The assumption is that you do the config, restart the audit daemon, and then check that its working. If time elapses then its no longer recent and you need to resort to other time parameters.
> Also, I am noticing that if I altered the value of the variable
> name_format to the lower-case value of hostname; things behave a
> little bit better. At least with ausearch and aureport I can use the
> --node switch with an appropriate argument; I was expecting it to work with -hn or --host.
The host switch targets the host= field in events. Pam is about the only thing that uses it. As for name_format, It has a couple other ways to name systems if the hostname is not the best. Some people like fully qualified domain names.
> I was expecting to use the term --hostname client1, but if I need to
> adapt my thinking to understand that I need to use --node I am totally
> fine with that.
Yes. --node is the switch to select the exact audit stream from remote systems.
-Steve
> Thank you Steve, again, for your detailed support. For me this was an
> uphill battle, and you leveled the field for me (and I learned something).
>
> Warron French, MBA, SCSA
>
> -----Original Message-----
> From: Steve Grubb [mailto:sgrubb@redhat.com]
> Sent: Tuesday, May 03, 2016 2:53 PM
> To: Warron S French <warron.s.french@aero.org>
> Cc: linux-audit@redhat.com
> Subject: Re: audit review question
>
> On Tuesday, May 03, 2016 06:28:12 PM Warron S French wrote:
> > Steve,
> >
> > I typed up the instructions you provided to me on this thread, and I
> > tested them so that I could then print and carry over to another building
> > these implementations steps.
> >
> > For the most-part implementation was very smooth. I built a tiny
> > virtual environment with 2 client machines {client1 and client2} and
> > a single server {server1}. I ran through the steps on the client
> > machines as you described; and also on the server as you described.
> > I did not stray from your guidance (I realized where below you used
> > the word 'set' you didn't mean to use that word inside the various
> > configurations files explicitly - so I didn't add the word 'set' anywhere.
> >
> > However, upon completion I ran the command:
> > ausearch --start recent -m DAEMON_ACCEPT -i
>
> This would be on the aggregating server. The accept events record a
> client connecting to the aggregating server.
> > and it returned with the following:
> > <no matches>
>
> The assuming this was run on the server, the client is not connecting
> to the server. Was there anything in the client's syslog?
>
> > I did this a few times and I did have success once.
> >
> > I also attempted to use the command: ausearch --host client1 and
>
> I got
>
> > back <no matches> So I thought maybe I should tail the
>
> /var/log/audit.log
>
> > file to see if I saw any "hostname=client1" entries but I didn't see
> > anything.
> >
> > So, I have to ask about this part in your email::::
> > /etc/audisp/audispd.conf
> > name_format = HOSTNAME or another suitable option
> >
> > Was the name_format = HOSTNAME supposed to be set to; name_format =
> > hostname (the man page for this file indicates the lower-case
> > version) or am I doing something else wrong? I did allow port
> > 60/tcp through the iptables firewall (and restarted the firewall).
>
> Its case insensitive.
>
> Check the syslogs on client and server, There should be something
> there if the connection is not working.
>
> -Steve
>
> > -----Original Message-----
> > From: linux-audit-bounces@redhat.com
> > [mailto:linux-audit-bounces@redhat.com] On Behalf Of Warron S French
> > Sent: Friday, April 29, 2016 4:21 PM
> > To: Steve Grubb <sgrubb@redhat.com>
> > Cc: linux-audit@redhat.com
> > Subject: [WARNING: SPOOFED E-MAIL--Non-Aerospace Sender] RE: audit
> > review question
> >
> > Thank you Steve. That is very helpful. Have a nice weekend.
> >
> >
> > Warron French, MBA, SCSA
> >
> >
> > -----Original Message-----
> > From: Steve Grubb [mailto:sgrubb@redhat.com]
> > Sent: Friday, April 29, 2016 3:18 PM
> > To: Warron S French <warron.s.french@aero.org>
> > Cc: linux-audit@redhat.com
> > Subject: Re: audit review question
> >
> > On Thursday, April 28, 2016 03:50:33 PM Warron S French wrote:
> > > Steve, thanks for your replies to all of my questions.
> > >
> > > Can you please send me a walk through document for trying to send
> > > the
> > > 6 workstations and 1 servers audit-data into the same directory
> > > structure?
> > > Something that will definitely work, please?
> > >
> > > I have a VM environment that I can make changes on and then test,
> > > so I would be very grateful for any cooperation I could get.
> > >
> > > My intent is to have all the machines log data to the same
> > > machine. I want the system security auditors to be able to use
> > > the typical aureport and ausearch commands (that I know you write).
> > >
> > > So, I have to ask, can this be done, and the audit logs be parsed
> > > on a per hostname-basis? Can they be stored in directories that
> > > are /var/log/audit/YYYY/MM/DD/Hostname_audit.log format - or is
> > > that inadvisable considering the intention to continue to support/use the two
> > > commands: aureport and ausearch? What would you advise - please?
> >
> > The theory of operation is to put all events in one log and then
> > separate them later by using a '--node' command line option.
> >
> > > I am aware of the /etc/audisp directory, which I am sure is
> > > associated with the audispd daemon, but I don't have the foggiest
> > > clue of how to configure them together.
> >
> > For a clear text transport
> >
> > on the client side:
> >
> > /etc/audisp/plugins.d/au-remote.conf
> > set active = yes
> >
> > /etc/audisp/audisp-remote.conf
> > set remote_server = to the machine you are aggregating to if you
> > need lossless transport, set mode = forward set local_port = 60
> >
> > /etc/audisp/audispd.conf
> > name_format = HOSTNAME or another suitable option
> >
> > On the server
> >
> > /etc/audit/auditd.conf
> > set tcp_listen_port = 60
> > set tcp_client_ports = 60
> > set use_libwrap = yes
> >
> > in /etc/hosts.allow
> > auditd: 1.2.4. or some subnet. You can read about all the tcp-wrappers
> > config options elsewhere.
> >
> > restart the server
> > restart clients
> >
> > To check if working:
> > ausearch --start recent -m DAEMON_ACCEPT -i
> >
> > To get an encrypted transport, you need to use kerberos and that is
> > beyond an email for setting it up.
> >
> > One of these days I'd like to add TLS as an option, too. But it'll
> > be a little longer. You might be able to vpn things to one another
> > in the mean time. Or maybe use a ssh tunnel.
> >
> > > It is only because of stumbling around for the last 2 years (and
> > > very feverishly the last 2 days) that I have learned how to use
> > > the auditctl and aureport commands. I want to do this correctly,
> > > and I want to do it consistently with "industry standards" so that
> > > I can continue to get support from people like the folks in this 'forum.'
> >
> > Sure.
> >
> > -Steve
> >
> > > Thanks, for any advice and useful links you can share. I am
> > > certain that as you provide them and I read them it will force me
> > > to ask even more questions. I hope you don't mind.
> > >
> > > Warron French, MBA, SCSA
> > >
> > > -----Original Message-----
> > > From: Steve Grubb [mailto:sgrubb@redhat.com]
> > > Sent: Thursday, April 28, 2016 11:10 AM
> > > To: linux-audit@redhat.com
> > > Cc: Warron S French <warron.s.french@aero.org>
> > > Subject: Re: audit review question
> > >
> > > On Wednesday, April 27, 2016 09:10:39 PM Warron S French wrote:
> > > > I have a scenario that I need a little help understanding how to
> > > > work through in an isolated environment of 1 server and 6
> > > > workstations (7 machines). The 7 machines are all running
> > > > CentOS-6.7 and selinux = disabled.
> > > >
> > > > All 6 workstations are configured through rsyslog.conf to send
> > > > audit data to the server, and I have (but apparently not
> > > > successfully configured general system messages to also report
> > > > back to the same server). I am using the conventional
> > > > filesystems for each, but the directory structure below is different.
> > >
> > > Rsyslog will likely mangle the audit lines such that its no longer
> > > in the native audit format. I don't know if its headers can be
> > > stripped as it writes to disk.
> > >
> > > > For audit, I use, /var/log/audit/2016/04/27/wk{1..6}_audit.log the
> > > > directory per day and per month and per year are auto created
> > > > (miraculously). For system messages, and I know this isn't the
> > > > forum to get help on this so I will only list the directory is -
> > > > /var/log/2016/04/27/wk{1..6}_syslog.log.
> > > >
> > > > Now that I am doing this, and successfully, I want to test that
> > > > the security auditors will be able to do their job properly, as
> > > > well as I am trying to comply with some security constraint that
> > > > requires me to centralize the logdata into a single server
> > > > (hence the major driver for all of this).
> > > >
> > > > I know that there is the aureport and ausearch command, but I am
> > > > not sure that I am able to figure out the correct command-line
> > > > structure to test that audit-data is getting into the
> > > > appropriate file, on each day of the year, on a per serverName basis.
> > > >
> > > > If a real-world situation occurred that the Security Auditors
> > > > were asking to find out how many machines did userX attempt to
> > > > log into, what would be the appropriate command for the example
> > > > audit directory I listed above
> > > > (/var/log/audit/2016/04/27/wk{1..6}_audit.log), because I am not
> > > > sure I am running the command with the appropriate switches to
> > > > scan the files properly?
> > > >
> > > > I used:
> > > >
> > > > * aureport -if /var/log/audit/2016/04/27/ and it didn't like
> > > > the
> > > > input,
> > >
> > > Probably due to the header it inserts to each record. But this is
> > > how you should do it.
> > >
> > > > * aureport -if /var/log/audit/2016/04/27/* and it didn't like
> > > > the
> > > > input, am I using the command improperly?
> > >
> > > You shouldn't need the '*'. If the passed option is a dir, then it
> > > automatically looks for more files. But note that the native rotation is
> > > audit.log <- newest
> > > audit.log.1
> > > audit.log.2
> > > audit.log.3 <- oldest
> > >
> > > rsyslog would also have to use this scheme. I have never
> > > investigated if it does. That does not means that a wrapper script
> > > couldn't be made to walk the files in rsyslog's order and send
> > > them to aureport via stdin. You could probably even add a sed
> > > command to strip the rsyslog headers from each record.
> > >
> > > Not the best answer, but once it hits rsyslog, it can change the
> > > record in ways that unknown to me.
> > >
> > > -Steve
> >
> > --
> > Linux-audit mailing list
> > Linux-audit@redhat.com
> > https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Audit reporting misses AUDIT_SOCKETCALL (1306) message when 32-bit binary is running form 64-bit machine.
From: Kangkook Jee @ 2016-05-04 21:21 UTC (permalink / raw)
To: linux-audit
[-- Attachment #1.1: Type: text/plain, Size: 5925 bytes --]
Hi all,
We are running a 32-bit program on a 64-bit machine (Ubuntu 14.04, 3.13.0-57-generic kernel - x86_64) typically issuing network related system calls which, in turn, would invoke the one of socketcall() system call.
However, an expected audit raw message -- AUDIT_SOCKETCALL (1304) is reported when we run the 32-bit binary from a 64-bit machine. The following is the raw audit messages captured for connect() system from a 64-bit machine running 32-bit binary.
MSG (1300): audit(1462273146.351:21482453): arch=40000003 syscall=102 success=no exit=-2 a0=3 a1=ffe38240 a2=f7751000 a3=4 items=0 ppid=10269 pid=10755 auid=19287 uid=19287 gid=19287 euid=19287 suid=19287 fsuid=19287 egid=19287 sgid=19287 fsgid=19287 tty=pts16 ses=12 comm="conn" exe="/home/accountname/32bit_test/conn" key=(null)
MSG (1306): audit(1462273146.351:21482453): saddr=01002F7661722F72756E2F6E7363642F736F636B657400B7160054B7160054B71600130000001300000004000000010000000100000000000000000000000000000028791A0028791A000500000000100000CD5D77F734D676F748A15BF7D4811A00E82C0000A858000006000000
MSG (1320): audit(1462273146.351:21482453):
And this is the raw audit message captured from a 32-bit machine (CentOS 5 2.6.18-404.el5 i686) running 32-bit binary.
MSG (1300): audit(1462289555.340:807319): arch=40000003 syscall=102 success=yes exit=0 a0=3 a1=bfef25b0 a2=67dff4 a3=816840 items=0 ppid=28509 pid=28560 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts2 ses=10 comm="conn" exe="/home/kjee/conn" subj=user_u:system_r:unconfined_t:s0 key=(null)
MSG (1306): audit(1462289555.340:807319): saddr=020000358A0F6D630000000000000000000000000000000000000000
MSG (1304): audit(1462289555.340:807319): nargs=3 a0=4 a1=859c4b8 a2=1c
MSG (1320): audit(1462289555.340:807319):•
I hope you to catch the difference. While the first case does not report AUDIT_SOCKETCALL (1304) event, but the second case report the entry providing the list of arguments starting with "nargs=".
Could you tell me whether this is an expected behavior? Or is there any way that I can fix it?
I'm attaching the source code of the test program (conn.c) and summarizes the procedure to reproduce the problem. If you have any difficulty producing the issue, please let me know.
1. we added the following the audit rules from a 64-bit machine. It is intended to capture events from both 64-bit and 32-bit system calls.
/sbin/auditctl -a exit,always -F arch=b64 -S clone -S close -S creat -S dup -S dup2 -S dup3 -S execve -S exit -S exit_group -S fork -S open -S openat -S rename -S renameat -S unlink -S unlinkat -S vfork -S 288 -S accept -S connect -S listen -S socket -S socketpair
/sbin/auditctl -a exit,always -F arch=b32 -S clone -S close -S creat -S dup -S dup2 -S dup3 -S execve -S exit -S exit_group -S fork -S open -S openat -S rename -S renameat -S unlink -S unlinkat -S vfork
/sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=3 # connect
/sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=4 # listen
/sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=5 # accept
/sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=8 # socketpair
/sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=18 # accept4
$ sudo auditctl -l
LIST_RULES: exit,always arch=3221225534 (0xc000003e) syscall=open,close,dup,dup2,socket,connect,accept,listen,socketpair,clone,fork,vfork,execve,exit,rename,creat,unlink,exit_group,openat,unlinkat,renameat,accept4,dup3
LIST_RULES: exit,always arch=1073741827 (0x40000003) syscall=exit,fork,open,close,creat,unlink,execve,rename,dup,dup2,clone,vfork,exit_group,openat,unlinkat,renameat,dup3
LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=1 (0x1) syscall=socketcall
LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=3 (0x3) syscall=socketcall
LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=4 (0x4) syscall=socketcall
LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=5 (0x5) syscall=socketcall
LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=8 (0x8) syscall=socketcall
LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=18 (0x12) syscall=socketcall
2. We added the following the audit rules from a 32-bit machine.
/sbin/auditctl -a exit,always -F arch=b32 -S clone -S close -S creat -S dup -S dup2 -S dup3 -S execve -S exit -S exit_group -S fork -S open -S openat -S rename -S renameat -S unlink -S unlinkat -S vfork
/sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=2
/sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=3
/sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=4
/sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=5
/sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=8
/sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=18
LIST_RULES: exit,always arch=1073741827 (0x40000003) syscall=exit,fork,open,close,creat,unlink,execve,rename,dup,dup2,clone,vfork,exit_group,openat,unlinkat,renameat,dup3
LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=1 (0x1) syscall=socketcall
LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=2 (0x2) syscall=socketcall
LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=3 (0x3) syscall=socketcall
LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=4 (0x4) syscall=socketcall
LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=5 (0x5) syscall=socketcall
LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=8 (0x8) syscall=socketcall
LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=18 (0x12) syscall=socketcall
3. Build conn.c source and running
conn.c is a simple connection client.
$ cc -o conn conn.c
$ ./conn <remote_host> <port>
Example run
$ ./conn localhost 22
$ Please enter the message: this is random message
SSH-2.0-OpenSSH_4.3
Thanks a lot for your help in advance.
[-- Attachment #1.2.1: Type: text/html, Size: 9362 bytes --]
[-- Attachment #1.2.2: conn.c --]
[-- Type: application/octet-stream, Size: 1656 bytes --]
#include <stdio.h>
#include <stdlib.h>
#include <netdb.h>
#include <netinet/in.h>
#include <string.h>
int main(int argc, char *argv[]) {
int sockfd, portno, n;
struct sockaddr_in serv_addr;
struct hostent *server;
char buffer[256];
if (argc < 3) {
fprintf(stderr,"usage %s hostname port\n", argv[0]);
exit(0);
}
portno = atoi(argv[2]);
/* Create a socket point */
sockfd = socket(AF_INET, SOCK_STREAM, 0);
if (sockfd < 0) {
perror("ERROR opening socket");
exit(1);
}
server = gethostbyname(argv[1]);
if (server == NULL) {
fprintf(stderr,"ERROR, no such host\n");
exit(0);
}
bzero((char *) &serv_addr, sizeof(serv_addr));
serv_addr.sin_family = AF_INET;
bcopy((char *)server->h_addr, (char *)&serv_addr.sin_addr.s_addr, server->h_length);
serv_addr.sin_port = htons(portno);
/* Now connect to the server */
if (connect(sockfd, (struct sockaddr*)&serv_addr, sizeof(serv_addr)) < 0) {
perror("ERROR connecting");
exit(1);
}
/* Now ask for a message from the user, this message
* will be read by server
*/
printf("Please enter the message: ");
bzero(buffer,256);
fgets(buffer,255,stdin);
/* Send message to the server */
n = write(sockfd, buffer, strlen(buffer));
if (n < 0) {
perror("ERROR writing to socket");
exit(1);
}
/* Now read server response */
bzero(buffer,256);
n = read(sockfd, buffer, 255);
if (n < 0) {
perror("ERROR reading from socket");
exit(1);
}
printf("%s\n",buffer);
return 0;
}
[-- Attachment #1.2.3: Type: text/html, Size: 233 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: Audit reporting misses AUDIT_SOCKETCALL (1306) message when 32-bit binary is running form 64-bit machine.
From: Kangkook Jee @ 2016-05-06 22:49 UTC (permalink / raw)
To: linux-audit
In-Reply-To: <80177D63-702B-4077-A716-A083711C068D@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 6266 bytes --]
Hi, all
This is a bump.
Could any of you have a look into this case?
Regards, Kangkook
> On May 4, 2016, at 5:21 PM, Kangkook Jee <aixer77@gmail.com> wrote:
>
> Hi all,
>
> We are running a 32-bit program on a 64-bit machine (Ubuntu 14.04, 3.13.0-57-generic kernel - x86_64) typically issuing network related system calls which, in turn, would invoke the one of socketcall() system call.
>
> However, an expected audit raw message -- AUDIT_SOCKETCALL (1304) is reported when we run the 32-bit binary from a 64-bit machine. The following is the raw audit messages captured for connect() system from a 64-bit machine running 32-bit binary.
>
> MSG (1300): audit(1462273146.351:21482453): arch=40000003 syscall=102 success=no exit=-2 a0=3 a1=ffe38240 a2=f7751000 a3=4 items=0 ppid=10269 pid=10755 auid=19287 uid=19287 gid=19287 euid=19287 suid=19287 fsuid=19287 egid=19287 sgid=19287 fsgid=19287 tty=pts16 ses=12 comm="conn" exe="/home/accountname/32bit_test/conn" key=(null)
> MSG (1306): audit(1462273146.351:21482453): saddr=01002F7661722F72756E2F6E7363642F736F636B657400B7160054B7160054B71600130000001300000004000000010000000100000000000000000000000000000028791A0028791A000500000000100000CD5D77F734D676F748A15BF7D4811A00E82C0000A858000006000000
> MSG (1320): audit(1462273146.351:21482453):
>
> And this is the raw audit message captured from a 32-bit machine (CentOS 5 2.6.18-404.el5 i686) running 32-bit binary.
>
> MSG (1300): audit(1462289555.340:807319): arch=40000003 syscall=102 success=yes exit=0 a0=3 a1=bfef25b0 a2=67dff4 a3=816840 items=0 ppid=28509 pid=28560 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts2 ses=10 comm="conn" exe="/home/kjee/conn" subj=user_u:system_r:unconfined_t:s0 key=(null)
> MSG (1306): audit(1462289555.340:807319): saddr=020000358A0F6D630000000000000000000000000000000000000000
> MSG (1304): audit(1462289555.340:807319): nargs=3 a0=4 a1=859c4b8 a2=1c
> MSG (1320): audit(1462289555.340:807319):•
>
> I hope you to catch the difference. While the first case does not report AUDIT_SOCKETCALL (1304) event, but the second case report the entry providing the list of arguments starting with "nargs=".
>
> Could you tell me whether this is an expected behavior? Or is there any way that I can fix it?
>
> I'm attaching the source code of the test program (conn.c) and summarizes the procedure to reproduce the problem. If you have any difficulty producing the issue, please let me know.
>
> 1. we added the following the audit rules from a 64-bit machine. It is intended to capture events from both 64-bit and 32-bit system calls.
>
> /sbin/auditctl -a exit,always -F arch=b64 -S clone -S close -S creat -S dup -S dup2 -S dup3 -S execve -S exit -S exit_group -S fork -S open -S openat -S rename -S renameat -S unlink -S unlinkat -S vfork -S 288 -S accept -S connect -S listen -S socket -S socketpair
> /sbin/auditctl -a exit,always -F arch=b32 -S clone -S close -S creat -S dup -S dup2 -S dup3 -S execve -S exit -S exit_group -S fork -S open -S openat -S rename -S renameat -S unlink -S unlinkat -S vfork
> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=3 # connect
> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=4 # listen
> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=5 # accept
> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=8 # socketpair
> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=18 # accept4
>
> $ sudo auditctl -l
> LIST_RULES: exit,always arch=3221225534 (0xc000003e) syscall=open,close,dup,dup2,socket,connect,accept,listen,socketpair,clone,fork,vfork,execve,exit,rename,creat,unlink,exit_group,openat,unlinkat,renameat,accept4,dup3
> LIST_RULES: exit,always arch=1073741827 (0x40000003) syscall=exit,fork,open,close,creat,unlink,execve,rename,dup,dup2,clone,vfork,exit_group,openat,unlinkat,renameat,dup3
> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=1 (0x1) syscall=socketcall
> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=3 (0x3) syscall=socketcall
> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=4 (0x4) syscall=socketcall
> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=5 (0x5) syscall=socketcall
> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=8 (0x8) syscall=socketcall
> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=18 (0x12) syscall=socketcall
>
> 2. We added the following the audit rules from a 32-bit machine.
>
> /sbin/auditctl -a exit,always -F arch=b32 -S clone -S close -S creat -S dup -S dup2 -S dup3 -S execve -S exit -S exit_group -S fork -S open -S openat -S rename -S renameat -S unlink -S unlinkat -S vfork
> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=2
> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=3
> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=4
> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=5
> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=8
> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=18
>
> LIST_RULES: exit,always arch=1073741827 (0x40000003) syscall=exit,fork,open,close,creat,unlink,execve,rename,dup,dup2,clone,vfork,exit_group,openat,unlinkat,renameat,dup3
> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=1 (0x1) syscall=socketcall
> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=2 (0x2) syscall=socketcall
> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=3 (0x3) syscall=socketcall
> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=4 (0x4) syscall=socketcall
> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=5 (0x5) syscall=socketcall
> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=8 (0x8) syscall=socketcall
> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=18 (0x12) syscall=socketcall
>
> 3. Build conn.c source and running
> conn.c is a simple connection client.
> $ cc -o conn conn.c
> $ ./conn <remote_host> <port>
>
> Example run
>
> $ ./conn localhost 22
> $ Please enter the message: this is random message
> SSH-2.0-OpenSSH_4.3
>
> Thanks a lot for your help in advance.
>
>
> <conn.c>
[-- Attachment #1.2: Type: text/html, Size: 10390 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Audit reporting Invalid argument
From: Bhagwat, Shriniketan Manjunath @ 2016-05-09 13:40 UTC (permalink / raw)
To: linux-audit@redhat.com
[-- Attachment #1.1: Type: text/plain, Size: 1728 bytes --]
Hello,
I am trying to monitor multiple files using Linux audit. In order to get better performance, I am trying to reduce number of rules.
If I specify more than one path field as in below example I am getting "Invalid argument".
Examle1:
# auditctl -a always,exit -F arch=x86_64 -F path=/home/secpack/test.c -F path=/home/secpack/test -S open
Error sending add rule data request (Invalid argument)
# auditctl -a always,exit -F arch=x86_64 -F path=/home/secpack/test.c -F dir=/tmp/ -S open
Error sending add rule data request (Invalid argument)
However, I am able to create a single rule to monitor multiple PIDs or UIDs as below.
Examle2:
# auditctl -a always,exit -F arch=x86_64 -F pid=3526 -F pid=3537
# auditctl -a always,exit -F arch=x86_64 -F auid=0 -F auid=512 -F auid=1002
As per the auditctl man page, Build a rule field takes up to 64 fields on a single command line. Each one must start with -F. Each field equation is anded with each other to trigger an audit record.
My question is,
1. specify more than one path field as in example1 is valid?
2. If not valid than how do I create single audit rule to monitor multiple files/directory?
3. If valid, then why "Invalid argument" is reported?
4. To monitor 10 files, should 10 audit rules required?
5. if 10 rules are required, how to I optimize the rule for performance?
My next question is does Linux audit support regular expressions? How do I create audit rule to monitor /var/log/*.log?
# auditctl -a always,exit -F arch=x86_64 -F path=^/var/log/*.log$ -S open
Error sending add rule data request (Invalid argument)
If my questions are already documented, please guide me to the documentation.
Regards,
Ketan
[-- Attachment #1.2: Type: text/html, Size: 4956 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: Audit reporting Invalid argument
From: Steve Grubb @ 2016-05-09 13:50 UTC (permalink / raw)
To: linux-audit; +Cc: Bhagwat, Shriniketan Manjunath
In-Reply-To: <8FC6AD31395616439ECBCD98E071A87F4BF14ED7@G4W3202.americas.hpqcorp.net>
On Monday, May 09, 2016 01:40:58 PM Bhagwat, Shriniketan Manjunath wrote:
> I am trying to monitor multiple files using Linux audit. In order to get
> better performance, I am trying to reduce number of rules. If I specify
> more than one path field as in below example I am getting "Invalid
> argument".
>
> Examle1:
> # auditctl -a always,exit -F arch=x86_64 -F path=/home/secpack/test.c -F
> path=/home/secpack/test -S open Error sending add rule data request
> (Invalid argument)
>
> # auditctl -a always,exit -F arch=x86_64 -F path=/home/secpack/test.c -F
> dir=/tmp/ -S open Error sending add rule data request (Invalid argument)
>
> However, I am able to create a single rule to monitor multiple PIDs or UIDs
> as below.
>
> Examle2:
> # auditctl -a always,exit -F arch=x86_64 -F pid=3526 -F pid=3537
> # auditctl -a always,exit -F arch=x86_64 -F auid=0 -F auid=512 -F auid=1002
Which will produce no events due to the anding you mention below. Something
cannot have both pid 3526 and 3537.
> As per the auditctl man page, Build a rule field takes up to 64 fields on a
> single command line. Each one must start with -F. Each field equation is
> anded with each other to trigger an audit record. My question is,
> 1. specify more than one path field as in example1 is valid?
Nope.
> 2. If not valid than how do I create single audit rule to monitor multiple
> files/directory?
They need to be separate rules. You can also recursively watch a directory
with 'dir'
> 3. If valid, then why "Invalid argument" is reported?
> 4. To monitor 10 files, should 10 audit rules required?
Possibly.
> 5. if 10 rules are required, how to I optimize the rule for performance?
The filesystem watches are very efficient. You can probably put a 100 watches on
random files and you will not be able to see any performance hit unless they
are actually triggered. Syscall rules on the otherhand do affect performance.
> My next question is does Linux audit support regular expressions?
No. The kernel pretty much wants things to be numbers rather than strings.
> How do I create audit rule to monitor /var/log/*.log?
-a always,exit -F dir=/var/log/audit/ -F perm=wa -F key=write-audit-log
-Steve
> # auditctl -a always,exit -F arch=x86_64 -F path=^/var/log/*.log$ -S open
> Error sending add rule data request (Invalid argument)
>
> If my questions are already documented, please guide me to the
> documentation.
>
> Regards,
> Ketan
^ permalink raw reply
* Re: audit 2.5.1 released
From: Steve Grubb @ 2016-05-09 14:01 UTC (permalink / raw)
To: linux-audit, Manuel Scunthorpe
In-Reply-To: <543804231.8112760.1462051758161.JavaMail.yahoo@mail.yahoo.com>
On Saturday, April 30, 2016 09:29:18 PM Manuel Scunthorpe wrote:
> Dear Steve,thanks for your helpful observations. I was able to modify the
> PKGBUILD and successfully build the package, and then build e4rat-lite
> which was my ultimate aim. Sadly it didn't seem to work in Arch Linux due
> to the kernel config options, e4rat-lite-collect didn't collect anything,
> complained about being unable to log anything due to a bad file descriptor
> and there was a message at boot saying Cannot open audit socket, which was
> similar to what auditctl said in the terminal. Of course it might work and
> I've got something else wrong, it doesn't look encouraging though without
> CONFIG_AUDIT enabled. But I was just looking at my Void Linux kernel
> options:CONFIG_AUDIT=y CONFIG_HAVE_ARCH_AUDITSYSCALL=y
> CONFIG_AUDITSYSCALL=y
> CONFIG_AUDIT_WATCH=y
> CONFIG_AUDIT_TREE=y
> This looks more promising so I will have to try it here instead sometime,
> although what I will have to build to fulfill the various builddeps I don't
> yet know. Would it be OK if I tried to make an 'audit' package for Void
> Linux if they want one?
Sure.
> There isn't one in the repo at present, so if I get
> a working build then I might as well share it. It could take a while to get
> to that point though, and that's assuming I can get everything to work in
> Void and don't end up using some other readahead utility altogether or
> accidentally corrupting my filesystem. But I can be happy I'm building
> audit correctly now.I will try and pass on your comments about zos servers
> and openldap-devel to the Arch packagers as I can only take credit for the
> confusion over the systemd support option in my earlier PKGBUILD.
>
> Here's my successful modified PKGBUILD with the correct checksum for 2.5.1,
> which downloads and builds cleanly:# Edit /etc/makepkg.conf: staticlibs not
> !staticlibs or they are deleted by makepkg.
>
> # $Id: PKGBUILD 146469 2015-11-10 05:04:55Z thestinger $
> # Maintainer: Daniel Micay <danielmicay@gmail.com>
> # Contributor: <kang@insecure.ws>
> # Contributor: Massimiliano Torromeo <massimiliano.torromeo@gmail.com>
> # Contributor: Connor Behan <connor.behan@gmail.com>
> # Contributor: henning mueller <henning@orgizm.net>
>
> pkgname=audit
> pkgver=2.5.1
> pkgrel=1
> pkgdesc='Userspace components of the audit framework'
> url='https://people.redhat.com/sgrubb/audit'
> arch=(i686 x86_64)
> depends=(krb5 libcap-ng)
> makedepends=(libldap swig linux-headers python)
You can drop libldap since you disable zos support below. Its harmless as is
but not necessary for the configure options below.
-Steve
> license=(GPL)
> options=(emptydirs)
> groups=('modified')
> backup=(
> etc/libaudit.conf
> etc/audit/auditd.conf
> etc/audisp/audispd.conf
> etc/audisp/audisp-remote.conf
> etc/audisp/plugins.d/af_unix.conf
> etc/audisp/plugins.d/au-remote.conf
> etc/audisp/plugins.d/syslog.conf
> )
> source=("$url/$pkgname-$pkgver.tar.gz")
> sha256sums=('3c6ec72d8c16d1e85cc2b9c260cc6440319eb294cb54ca41a7bbe9283cc9f42
> 1') install=$pkgname.install
>
> build() {
> cd $pkgname-$pkgver
> export PYTHON=/usr/bin/python3
> ./configure \
> --prefix=/usr \
> --sbindir=/usr/bin \
> --sysconfdir=/etc \
> --libexecdir=/usr/lib/audit \
> --with-python=yes \
> --enable-gssapi-krb5=yes \
> --enable-systemd=no \
> --with-libcap-ng=yes \
> --disable-zos-remote \
> --enable-static=yes
> make
> }
>
> package() {
> cd $pkgname-$pkgver
> make DESTDIR="$pkgdir" install
>
> cd "$pkgdir"
> install -d var/log/audit
> rm -rf etc/rc.d etc/sysconfig usr/lib/audit
>
> sed -ri 's|/sbin|/usr/bin|' \
> etc/audit/*.conf \
> etc/audisp/plugins.d/*.conf
^ permalink raw reply
* How to Audit ssh Commands --> wget, scp
From: varun gulati @ 2016-05-09 16:13 UTC (permalink / raw)
To: linux-audit@redhat.com
In-Reply-To: <1090410784.877995.1462810399474.JavaMail.yahoo.ref@mail.yahoo.com>
[-- Attachment #1.1: Type: text/plain, Size: 846 bytes --]
Hi Team,
We have requirement where we have to monitor and log any read operations performed on a file.
e.g. /a/b/c/xyz.log
This file is usually copied and downloaded by many users using various operations, like, wget, ssh, jsp Download link provided. These commands are fired from different hosts.
With the auditd we want to create a rule which auditctl can leverage to log the User ID that is reading (and copying) it from a different host may be. I have gone through many of the rules but didn't find anything fruitful as such (which logs wget, scp commands from remote hosts). May be I am missing on something. Since it is a very crucial requirement, appreciate your guidance and directions with this.
Let me know in case you require any further information from my end. Many thanks in advance.
Thanks and Regards,Varun Gulati
[-- Attachment #1.2: Type: text/html, Size: 2225 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Bug#759604: Any problem with making auditd log readable by the adm group?
From: intrigeri @ 2016-05-09 19:07 UTC (permalink / raw)
To: linux-audit; +Cc: 759604
Hi,
in Debian, the convention for many log files is to make them readable
by members of the adm group. We're considering doing the same for the
auditd logs, in order to make apparmor-notify work out-of-the-box.
The maintainer of auditd in Debian would like to know what's your take
on it. What kind of problem could be created if we did that?
Cheers,
^ permalink raw reply
* Re: Any problem with making auditd log readable by the adm group?
From: Steve Grubb @ 2016-05-09 19:33 UTC (permalink / raw)
To: linux-audit; +Cc: intrigeri, 759604
In-Reply-To: <85futrf3ts.fsf@boum.org>
On Monday, May 09, 2016 09:07:11 PM intrigeri wrote:
> in Debian, the convention for many log files is to make them readable
> by members of the adm group. We're considering doing the same for the
> auditd logs, in order to make apparmor-notify work out-of-the-box.
>
> The maintainer of auditd in Debian would like to know what's your take
> on it. What kind of problem could be created if we did that?
I can't think of any problems. Just set the log_group = adm in auditd.conf and
fixup the packaging to have that as the group owner. Auditd should create the
logs with 0640 permissions.
-Steve
^ permalink raw reply
* Re: How to Audit ssh Commands --> wget, scp
From: Steve Grubb @ 2016-05-09 20:02 UTC (permalink / raw)
To: linux-audit, varun gulati
In-Reply-To: <1090410784.877995.1462810399474.JavaMail.yahoo@mail.yahoo.com>
On Monday, May 09, 2016 04:13:19 PM varun gulati wrote:
> Hi Team,
> We have requirement where we have to monitor and log any read operations
> performed on a file. e.g. /a/b/c/xyz.log
-a always,exit -F path=/a/b/c/xyz.log -F perm=r -F key=log-access
> This file is usually copied and downloaded by many users using various
> operations, like, wget, ssh, jsp Download link provided. These commands are
> fired from different hosts. With the auditd we want to create a rule which
> auditctl can leverage to log the User ID that is reading (and copying) it
> from a different host may be.
You will get the local auid/uid that the kernel sees when the request triggers
the rule. There is nothing more that can be done from the audit system.
-Steve
> I have gone through many of the rules but didn't find anything fruitful as
> such (which logs wget, scp commands from remote hosts). May be I am missing
> on something. Since it is a very crucial requirement, appreciate your
> guidance and directions with this. Let me know in case you require any
> further information from my end. Many thanks in advance.
>
>
>
> Thanks and Regards,Varun Gulati
^ permalink raw reply
* Re: Audit reporting misses AUDIT_SOCKETCALL (1306) message when 32-bit binary is running form 64-bit machine.
From: Paul Moore @ 2016-05-09 20:15 UTC (permalink / raw)
To: Kangkook Jee; +Cc: linux-audit
In-Reply-To: <E39C78F5-8A40-4BA6-A55A-47C4B329FCD1@gmail.com>
Without looking at the code too closely, have you tried doing these
tests on the same kernel version, preferably a current kernel? The
test below is comparing 3.13 to 2.6.18 which might not be a valid
comparison, and even 3.13 is a few years old.
On Fri, May 6, 2016 at 6:49 PM, Kangkook Jee <aixer77@gmail.com> wrote:
> Hi, all
>
>
> This is a bump.
> Could any of you have a look into this case?
>
> Regards, Kangkook
>
> On May 4, 2016, at 5:21 PM, Kangkook Jee <aixer77@gmail.com> wrote:
>
> Hi all,
>
> We are running a 32-bit program on a 64-bit machine (Ubuntu 14.04,
> 3.13.0-57-generic kernel - x86_64) typically issuing network related system
> calls which, in turn, would invoke the one of socketcall() system call.
>
> However, an expected audit raw message -- AUDIT_SOCKETCALL (1304) is
> reported when we run the 32-bit binary from a 64-bit machine. The following
> is the raw audit messages captured for connect() system from a 64-bit
> machine running 32-bit binary.
>
> MSG (1300): audit(1462273146.351:21482453): arch=40000003 syscall=102
> success=no exit=-2 a0=3 a1=ffe38240 a2=f7751000 a3=4 items=0 ppid=10269
> pid=10755 auid=19287 uid=19287 gid=19287 euid=19287 suid=19287 fsuid=19287
> egid=19287 sgid=19287 fsgid=19287 tty=pts16 ses=12 comm="conn"
> exe="/home/accountname/32bit_test/conn" key=(null)
> MSG (1306): audit(1462273146.351:21482453):
> saddr=01002F7661722F72756E2F6E7363642F736F636B657400B7160054B7160054B71600130000001300000004000000010000000100000000000000000000000000000028791A0028791A000500000000100000CD5D77F734D676F748A15BF7D4811A00E82C0000A858000006000000
> MSG (1320): audit(1462273146.351:21482453):
>
> And this is the raw audit message captured from a 32-bit machine (CentOS 5
> 2.6.18-404.el5 i686) running 32-bit binary.
>
> MSG (1300): audit(1462289555.340:807319): arch=40000003 syscall=102
> success=yes exit=0 a0=3 a1=bfef25b0 a2=67dff4 a3=816840 items=0 ppid=28509
> pid=28560 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
> tty=pts2 ses=10 comm="conn" exe="/home/kjee/conn"
> subj=user_u:system_r:unconfined_t:s0 key=(null)
> MSG (1306): audit(1462289555.340:807319):
> saddr=020000358A0F6D630000000000000000000000000000000000000000
> MSG (1304): audit(1462289555.340:807319): nargs=3 a0=4 a1=859c4b8 a2=1c
> MSG (1320): audit(1462289555.340:807319):•
>
> I hope you to catch the difference. While the first case does not report
> AUDIT_SOCKETCALL (1304) event, but the second case report the entry
> providing the list of arguments starting with "nargs=".
>
> Could you tell me whether this is an expected behavior? Or is there any way
> that I can fix it?
>
> I'm attaching the source code of the test program (conn.c) and summarizes
> the procedure to reproduce the problem. If you have any difficulty producing
> the issue, please let me know.
>
> 1. we added the following the audit rules from a 64-bit machine. It is
> intended to capture events from both 64-bit and 32-bit system calls.
>
> /sbin/auditctl -a exit,always -F arch=b64 -S clone -S close -S creat -S dup
> -S dup2 -S dup3 -S execve -S exit -S exit_group -S fork -S open -S openat -S
> rename -S renameat -S unlink -S unlinkat -S vfork -S 288 -S accept -S
> connect -S listen -S socket -S socketpair
> /sbin/auditctl -a exit,always -F arch=b32 -S clone -S close -S creat -S dup
> -S dup2 -S dup3 -S execve -S exit -S exit_group -S fork -S open -S openat -S
> rename -S renameat -S unlink -S unlinkat -S vfork
> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=3 # connect
> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=4 # listen
> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=5 # accept
> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=8 # socketpair
> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=18 # accept4
>
> $ sudo auditctl -l
> LIST_RULES: exit,always arch=3221225534 (0xc000003e)
> syscall=open,close,dup,dup2,socket,connect,accept,listen,socketpair,clone,fork,vfork,execve,exit,rename,creat,unlink,exit_group,openat,unlinkat,renameat,accept4,dup3
> LIST_RULES: exit,always arch=1073741827 (0x40000003)
> syscall=exit,fork,open,close,creat,unlink,execve,rename,dup,dup2,clone,vfork,exit_group,openat,unlinkat,renameat,dup3
> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=1 (0x1)
> syscall=socketcall
> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=3 (0x3)
> syscall=socketcall
> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=4 (0x4)
> syscall=socketcall
> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=5 (0x5)
> syscall=socketcall
> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=8 (0x8)
> syscall=socketcall
> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=18 (0x12)
> syscall=socketcall
>
> 2. We added the following the audit rules from a 32-bit machine.
>
> /sbin/auditctl -a exit,always -F arch=b32 -S clone -S close -S creat -S dup
> -S dup2 -S dup3 -S execve -S exit -S exit_group -S fork -S open -S openat -S
> rename -S renameat -S unlink -S unlinkat -S vfork
> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=2
> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=3
> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=4
> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=5
> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=8
> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=18
>
> LIST_RULES: exit,always arch=1073741827 (0x40000003)
> syscall=exit,fork,open,close,creat,unlink,execve,rename,dup,dup2,clone,vfork,exit_group,openat,unlinkat,renameat,dup3
> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=1 (0x1)
> syscall=socketcall
> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=2 (0x2)
> syscall=socketcall
> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=3 (0x3)
> syscall=socketcall
> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=4 (0x4)
> syscall=socketcall
> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=5 (0x5)
> syscall=socketcall
> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=8 (0x8)
> syscall=socketcall
> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=18 (0x12)
> syscall=socketcall
>
> 3. Build conn.c source and running
> conn.c is a simple connection client.
> $ cc -o conn conn.c
> $ ./conn <remote_host> <port>
>
> Example run
>
> $ ./conn localhost 22
> $ Please enter the message: this is random message
> SSH-2.0-OpenSSH_4.3
>
> Thanks a lot for your help in advance.
>
>
> <conn.c>
>
>
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
--
paul moore
www.paul-moore.com
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Re: Audit reporting misses AUDIT_SOCKETCALL (1306) message when 32-bit binary is running form 64-bit machine.
From: Kangkook Jee @ 2016-05-09 20:54 UTC (permalink / raw)
To: Paul Moore; +Cc: linux-audit
In-Reply-To: <CAHC9VhQnknrSNA9Uk=p1BVVL3YwFX=k=e_s4HzA4rbQDrALwkA@mail.gmail.com>
Dear Paul,
First of all, thanks a lot for your response.
I think the problem that I have is that I can’t see expected message (which is AUDIT_SOCKCALL) from 64-bit kernel when it runs 32-bit binary that issues connect() system call.
Regarding 32-bit system that I showed from the previous mail is just for a reference case to show normal behavior. For whatever kernel version, I’m pretty sure it will produce a complete set of all 4 messages (1300, 1306, 1304, 1320).
I think can run the same experiment from relatively newer version of kernel, but if what I see is true at least for a subset of kernel versions , I think it is still a problem.
If you still have any specific item that you want me to perform, please let me know.
Thanks for your help again!
Regards, Kangkook
> On May 9, 2016, at 4:15 PM, Paul Moore <paul@paul-moore.com> wrote:
>
> Without looking at the code too closely, have you tried doing these
> tests on the same kernel version, preferably a current kernel? The
> test below is comparing 3.13 to 2.6.18 which might not be a valid
> comparison, and even 3.13 is a few years old.
>
> On Fri, May 6, 2016 at 6:49 PM, Kangkook Jee <aixer77@gmail.com> wrote:
>> Hi, all
>>
>>
>> This is a bump.
>> Could any of you have a look into this case?
>>
>> Regards, Kangkook
>>
>> On May 4, 2016, at 5:21 PM, Kangkook Jee <aixer77@gmail.com> wrote:
>>
>> Hi all,
>>
>> We are running a 32-bit program on a 64-bit machine (Ubuntu 14.04,
>> 3.13.0-57-generic kernel - x86_64) typically issuing network related system
>> calls which, in turn, would invoke the one of socketcall() system call.
>>
>> However, an expected audit raw message -- AUDIT_SOCKETCALL (1304) is
>> reported when we run the 32-bit binary from a 64-bit machine. The following
>> is the raw audit messages captured for connect() system from a 64-bit
>> machine running 32-bit binary.
>>
>> MSG (1300): audit(1462273146.351:21482453): arch=40000003 syscall=102
>> success=no exit=-2 a0=3 a1=ffe38240 a2=f7751000 a3=4 items=0 ppid=10269
>> pid=10755 auid=19287 uid=19287 gid=19287 euid=19287 suid=19287 fsuid=19287
>> egid=19287 sgid=19287 fsgid=19287 tty=pts16 ses=12 comm="conn"
>> exe="/home/accountname/32bit_test/conn" key=(null)
>> MSG (1306): audit(1462273146.351:21482453):
>> saddr=01002F7661722F72756E2F6E7363642F736F636B657400B7160054B7160054B71600130000001300000004000000010000000100000000000000000000000000000028791A0028791A000500000000100000CD5D77F734D676F748A15BF7D4811A00E82C0000A858000006000000
>> MSG (1320): audit(1462273146.351:21482453):
>>
>> And this is the raw audit message captured from a 32-bit machine (CentOS 5
>> 2.6.18-404.el5 i686) running 32-bit binary.
>>
>> MSG (1300): audit(1462289555.340:807319): arch=40000003 syscall=102
>> success=yes exit=0 a0=3 a1=bfef25b0 a2=67dff4 a3=816840 items=0 ppid=28509
>> pid=28560 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
>> tty=pts2 ses=10 comm="conn" exe="/home/kjee/conn"
>> subj=user_u:system_r:unconfined_t:s0 key=(null)
>> MSG (1306): audit(1462289555.340:807319):
>> saddr=020000358A0F6D630000000000000000000000000000000000000000
>> MSG (1304): audit(1462289555.340:807319): nargs=3 a0=4 a1=859c4b8 a2=1c
>> MSG (1320): audit(1462289555.340:807319):•
>>
>> I hope you to catch the difference. While the first case does not report
>> AUDIT_SOCKETCALL (1304) event, but the second case report the entry
>> providing the list of arguments starting with "nargs=".
>>
>> Could you tell me whether this is an expected behavior? Or is there any way
>> that I can fix it?
>>
>> I'm attaching the source code of the test program (conn.c) and summarizes
>> the procedure to reproduce the problem. If you have any difficulty producing
>> the issue, please let me know.
>>
>> 1. we added the following the audit rules from a 64-bit machine. It is
>> intended to capture events from both 64-bit and 32-bit system calls.
>>
>> /sbin/auditctl -a exit,always -F arch=b64 -S clone -S close -S creat -S dup
>> -S dup2 -S dup3 -S execve -S exit -S exit_group -S fork -S open -S openat -S
>> rename -S renameat -S unlink -S unlinkat -S vfork -S 288 -S accept -S
>> connect -S listen -S socket -S socketpair
>> /sbin/auditctl -a exit,always -F arch=b32 -S clone -S close -S creat -S dup
>> -S dup2 -S dup3 -S execve -S exit -S exit_group -S fork -S open -S openat -S
>> rename -S renameat -S unlink -S unlinkat -S vfork
>> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=3 # connect
>> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=4 # listen
>> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=5 # accept
>> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=8 # socketpair
>> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=18 # accept4
>>
>> $ sudo auditctl -l
>> LIST_RULES: exit,always arch=3221225534 (0xc000003e)
>> syscall=open,close,dup,dup2,socket,connect,accept,listen,socketpair,clone,fork,vfork,execve,exit,rename,creat,unlink,exit_group,openat,unlinkat,renameat,accept4,dup3
>> LIST_RULES: exit,always arch=1073741827 (0x40000003)
>> syscall=exit,fork,open,close,creat,unlink,execve,rename,dup,dup2,clone,vfork,exit_group,openat,unlinkat,renameat,dup3
>> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=1 (0x1)
>> syscall=socketcall
>> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=3 (0x3)
>> syscall=socketcall
>> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=4 (0x4)
>> syscall=socketcall
>> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=5 (0x5)
>> syscall=socketcall
>> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=8 (0x8)
>> syscall=socketcall
>> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=18 (0x12)
>> syscall=socketcall
>>
>> 2. We added the following the audit rules from a 32-bit machine.
>>
>> /sbin/auditctl -a exit,always -F arch=b32 -S clone -S close -S creat -S dup
>> -S dup2 -S dup3 -S execve -S exit -S exit_group -S fork -S open -S openat -S
>> rename -S renameat -S unlink -S unlinkat -S vfork
>> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=2
>> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=3
>> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=4
>> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=5
>> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=8
>> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=18
>>
>> LIST_RULES: exit,always arch=1073741827 (0x40000003)
>> syscall=exit,fork,open,close,creat,unlink,execve,rename,dup,dup2,clone,vfork,exit_group,openat,unlinkat,renameat,dup3
>> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=1 (0x1)
>> syscall=socketcall
>> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=2 (0x2)
>> syscall=socketcall
>> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=3 (0x3)
>> syscall=socketcall
>> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=4 (0x4)
>> syscall=socketcall
>> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=5 (0x5)
>> syscall=socketcall
>> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=8 (0x8)
>> syscall=socketcall
>> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=18 (0x12)
>> syscall=socketcall
>>
>> 3. Build conn.c source and running
>> conn.c is a simple connection client.
>> $ cc -o conn conn.c
>> $ ./conn <remote_host> <port>
>>
>> Example run
>>
>> $ ./conn localhost 22
>> $ Please enter the message: this is random message
>> SSH-2.0-OpenSSH_4.3
>>
>> Thanks a lot for your help in advance.
>>
>>
>> <conn.c>
>>
>>
>>
>> --
>> Linux-audit mailing list
>> Linux-audit@redhat.com
>> https://www.redhat.com/mailman/listinfo/linux-audit
>
>
>
> --
> paul moore
> www.paul-moore.com
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Re: Audit reporting misses AUDIT_SOCKETCALL (1306) message when 32-bit binary is running form 64-bit machine.
From: Paul Moore @ 2016-05-09 21:03 UTC (permalink / raw)
To: Kangkook Jee; +Cc: linux-audit
In-Reply-To: <13164274-DEB3-4674-A978-29DE3C36D844@gmail.com>
Performing the same test with a 32-bit binary on both a 32-bit and
64-bit host using the same, current kernel version would be helpful.
On Mon, May 9, 2016 at 4:54 PM, Kangkook Jee <aixer77@gmail.com> wrote:
> Dear Paul,
>
> First of all, thanks a lot for your response.
>
> I think the problem that I have is that I can’t see expected message (which is AUDIT_SOCKCALL) from 64-bit kernel when it runs 32-bit binary that issues connect() system call.
> Regarding 32-bit system that I showed from the previous mail is just for a reference case to show normal behavior. For whatever kernel version, I’m pretty sure it will produce a complete set of all 4 messages (1300, 1306, 1304, 1320).
>
> I think can run the same experiment from relatively newer version of kernel, but if what I see is true at least for a subset of kernel versions , I think it is still a problem.
> If you still have any specific item that you want me to perform, please let me know.
>
> Thanks for your help again!
>
> Regards, Kangkook
>
>
>> On May 9, 2016, at 4:15 PM, Paul Moore <paul@paul-moore.com> wrote:
>>
>> Without looking at the code too closely, have you tried doing these
>> tests on the same kernel version, preferably a current kernel? The
>> test below is comparing 3.13 to 2.6.18 which might not be a valid
>> comparison, and even 3.13 is a few years old.
>>
>> On Fri, May 6, 2016 at 6:49 PM, Kangkook Jee <aixer77@gmail.com> wrote:
>>> Hi, all
>>>
>>>
>>> This is a bump.
>>> Could any of you have a look into this case?
>>>
>>> Regards, Kangkook
>>>
>>> On May 4, 2016, at 5:21 PM, Kangkook Jee <aixer77@gmail.com> wrote:
>>>
>>> Hi all,
>>>
>>> We are running a 32-bit program on a 64-bit machine (Ubuntu 14.04,
>>> 3.13.0-57-generic kernel - x86_64) typically issuing network related system
>>> calls which, in turn, would invoke the one of socketcall() system call.
>>>
>>> However, an expected audit raw message -- AUDIT_SOCKETCALL (1304) is
>>> reported when we run the 32-bit binary from a 64-bit machine. The following
>>> is the raw audit messages captured for connect() system from a 64-bit
>>> machine running 32-bit binary.
>>>
>>> MSG (1300): audit(1462273146.351:21482453): arch=40000003 syscall=102
>>> success=no exit=-2 a0=3 a1=ffe38240 a2=f7751000 a3=4 items=0 ppid=10269
>>> pid=10755 auid=19287 uid=19287 gid=19287 euid=19287 suid=19287 fsuid=19287
>>> egid=19287 sgid=19287 fsgid=19287 tty=pts16 ses=12 comm="conn"
>>> exe="/home/accountname/32bit_test/conn" key=(null)
>>> MSG (1306): audit(1462273146.351:21482453):
>>> saddr=01002F7661722F72756E2F6E7363642F736F636B657400B7160054B7160054B71600130000001300000004000000010000000100000000000000000000000000000028791A0028791A000500000000100000CD5D77F734D676F748A15BF7D4811A00E82C0000A858000006000000
>>> MSG (1320): audit(1462273146.351:21482453):
>>>
>>> And this is the raw audit message captured from a 32-bit machine (CentOS 5
>>> 2.6.18-404.el5 i686) running 32-bit binary.
>>>
>>> MSG (1300): audit(1462289555.340:807319): arch=40000003 syscall=102
>>> success=yes exit=0 a0=3 a1=bfef25b0 a2=67dff4 a3=816840 items=0 ppid=28509
>>> pid=28560 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
>>> tty=pts2 ses=10 comm="conn" exe="/home/kjee/conn"
>>> subj=user_u:system_r:unconfined_t:s0 key=(null)
>>> MSG (1306): audit(1462289555.340:807319):
>>> saddr=020000358A0F6D630000000000000000000000000000000000000000
>>> MSG (1304): audit(1462289555.340:807319): nargs=3 a0=4 a1=859c4b8 a2=1c
>>> MSG (1320): audit(1462289555.340:807319):•
>>>
>>> I hope you to catch the difference. While the first case does not report
>>> AUDIT_SOCKETCALL (1304) event, but the second case report the entry
>>> providing the list of arguments starting with "nargs=".
>>>
>>> Could you tell me whether this is an expected behavior? Or is there any way
>>> that I can fix it?
>>>
>>> I'm attaching the source code of the test program (conn.c) and summarizes
>>> the procedure to reproduce the problem. If you have any difficulty producing
>>> the issue, please let me know.
>>>
>>> 1. we added the following the audit rules from a 64-bit machine. It is
>>> intended to capture events from both 64-bit and 32-bit system calls.
>>>
>>> /sbin/auditctl -a exit,always -F arch=b64 -S clone -S close -S creat -S dup
>>> -S dup2 -S dup3 -S execve -S exit -S exit_group -S fork -S open -S openat -S
>>> rename -S renameat -S unlink -S unlinkat -S vfork -S 288 -S accept -S
>>> connect -S listen -S socket -S socketpair
>>> /sbin/auditctl -a exit,always -F arch=b32 -S clone -S close -S creat -S dup
>>> -S dup2 -S dup3 -S execve -S exit -S exit_group -S fork -S open -S openat -S
>>> rename -S renameat -S unlink -S unlinkat -S vfork
>>> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=3 # connect
>>> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=4 # listen
>>> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=5 # accept
>>> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=8 # socketpair
>>> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=18 # accept4
>>>
>>> $ sudo auditctl -l
>>> LIST_RULES: exit,always arch=3221225534 (0xc000003e)
>>> syscall=open,close,dup,dup2,socket,connect,accept,listen,socketpair,clone,fork,vfork,execve,exit,rename,creat,unlink,exit_group,openat,unlinkat,renameat,accept4,dup3
>>> LIST_RULES: exit,always arch=1073741827 (0x40000003)
>>> syscall=exit,fork,open,close,creat,unlink,execve,rename,dup,dup2,clone,vfork,exit_group,openat,unlinkat,renameat,dup3
>>> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=1 (0x1)
>>> syscall=socketcall
>>> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=3 (0x3)
>>> syscall=socketcall
>>> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=4 (0x4)
>>> syscall=socketcall
>>> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=5 (0x5)
>>> syscall=socketcall
>>> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=8 (0x8)
>>> syscall=socketcall
>>> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=18 (0x12)
>>> syscall=socketcall
>>>
>>> 2. We added the following the audit rules from a 32-bit machine.
>>>
>>> /sbin/auditctl -a exit,always -F arch=b32 -S clone -S close -S creat -S dup
>>> -S dup2 -S dup3 -S execve -S exit -S exit_group -S fork -S open -S openat -S
>>> rename -S renameat -S unlink -S unlinkat -S vfork
>>> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=2
>>> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=3
>>> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=4
>>> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=5
>>> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=8
>>> /sbin/auditctl -a exit,always -F arch=b32 -S socketcall -F a0=18
>>>
>>> LIST_RULES: exit,always arch=1073741827 (0x40000003)
>>> syscall=exit,fork,open,close,creat,unlink,execve,rename,dup,dup2,clone,vfork,exit_group,openat,unlinkat,renameat,dup3
>>> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=1 (0x1)
>>> syscall=socketcall
>>> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=2 (0x2)
>>> syscall=socketcall
>>> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=3 (0x3)
>>> syscall=socketcall
>>> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=4 (0x4)
>>> syscall=socketcall
>>> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=5 (0x5)
>>> syscall=socketcall
>>> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=8 (0x8)
>>> syscall=socketcall
>>> LIST_RULES: exit,always arch=1073741827 (0x40000003) a0=18 (0x12)
>>> syscall=socketcall
>>>
>>> 3. Build conn.c source and running
>>> conn.c is a simple connection client.
>>> $ cc -o conn conn.c
>>> $ ./conn <remote_host> <port>
>>>
>>> Example run
>>>
>>> $ ./conn localhost 22
>>> $ Please enter the message: this is random message
>>> SSH-2.0-OpenSSH_4.3
>>>
>>> Thanks a lot for your help in advance.
>>>
>>>
>>> <conn.c>
>>>
>>>
>>>
>>> --
>>> Linux-audit mailing list
>>> Linux-audit@redhat.com
>>> https://www.redhat.com/mailman/listinfo/linux-audit
>>
>>
>>
>> --
>> paul moore
>> www.paul-moore.com
>
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
--
paul moore
security @ redhat
--
Linux-audit mailing list
Linux-audit@redhat.com
https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Bug#759604: Any problem with making auditd log readable by the adm group?
From: intrigeri @ 2016-05-10 9:07 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit, 759604
In-Reply-To: <3693067.BeXgSpU3qL@x2>
Steve Grubb wrote (09 May 2016 19:33:16 GMT) :
> On Monday, May 09, 2016 09:07:11 PM intrigeri wrote:
>> in Debian, the convention for many log files is to make them readable
>> by members of the adm group. We're considering doing the same for the
>> auditd logs, in order to make apparmor-notify work out-of-the-box.
>>
>> The maintainer of auditd in Debian would like to know what's your take
>> on it. What kind of problem could be created if we did that?
> I can't think of any problems.
Thanks for your input!
Cheers,
^ permalink raw reply
* Re: How to Audit ssh Commands --> wget, scp
From: varun gulati @ 2016-05-10 10:39 UTC (permalink / raw)
To: Steve Grubb; +Cc: linux-audit@redhat.com
In-Reply-To: <1735441.Z8U2sxjTp5@x2>
[-- Attachment #1.1: Type: text/plain, Size: 1923 bytes --]
Hi Steve,
Thanks for your suggestions. We incorporated the below rule for auditctl which you suggested, but unfortunately it didn't helped. We are able to log the wget from the same server but unfortunately it is still not logging from a different host:
-a always,exit -F path=/a/b/c/xyz.log -F perm=r -F key=log-access
This is how the file looks like:
-w /a/b/c/xyz.log -p rwxa -k Audit
-w /usr/bin/wget -p rwxa -k Audit
-a always,exit -F path=/a/b/c/xyz.log -F perm=r -F key=log-access
But nothing is logging the Audit when wget is called from any other host. Can you please assist on this further.
Thanks and Regards,Varun Gulati
On Tuesday, 10 May 2016 1:32 AM, Steve Grubb <sgrubb@redhat.com> wrote:
On Monday, May 09, 2016 04:13:19 PM varun gulati wrote:
> Hi Team,
> We have requirement where we have to monitor and log any read operations
> performed on a file. e.g. /a/b/c/xyz.log
-a always,exit -F path=/a/b/c/xyz.log -F perm=r -F key=log-access
> This file is usually copied and downloaded by many users using various
> operations, like, wget, ssh, jsp Download link provided. These commands are
> fired from different hosts. With the auditd we want to create a rule which
> auditctl can leverage to log the User ID that is reading (and copying) it
> from a different host may be.
You will get the local auid/uid that the kernel sees when the request triggers
the rule. There is nothing more that can be done from the audit system.
-Steve
> I have gone through many of the rules but didn't find anything fruitful as
> such (which logs wget, scp commands from remote hosts). May be I am missing
> on something. Since it is a very crucial requirement, appreciate your
> guidance and directions with this. Let me know in case you require any
> further information from my end. Many thanks in advance.
>
>
>
> Thanks and Regards,Varun Gulati
[-- Attachment #1.2: Type: text/html, Size: 4233 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* audit-tools and SUDO
From: Warron S French @ 2016-05-10 12:31 UTC (permalink / raw)
To: linux-audit@redhat.com
[-- 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 --]
^ permalink raw reply
* Re: How to Audit ssh Commands --> wget, scp
From: Burn Alting @ 2016-05-10 12:56 UTC (permalink / raw)
To: varun gulati; +Cc: linux-audit@redhat.com
In-Reply-To: <364586275.1275853.1462876771158.JavaMail.yahoo@mail.yahoo.com>
On Tue, 2016-05-10 at 10:39 +0000, varun gulati wrote:
>
>
> Hi Steve,
>
>
> Thanks for your suggestions. We incorporated the below rule for
> auditctl which you suggested, but unfortunately it didn't helped. We
> are able to log the wget from the same server but unfortunately it is
> still not logging from a different host:
>
>
> -a always,exit -F path=/a/b/c/xyz.log -F perm=r -F key=log-access
>
>
> This is how the file looks like:
>
>
> -w /a/b/c/xyz.log -p rwxa -k Audit
>
>
> -w /usr/bin/wget -p rwxa -k Audit
>
>
> -a always,exit -F path=/a/b/c/xyz.log -F perm=r -F key=log-access
>
>
> But nothing is logging the Audit when wget is called from any other
> host. Can you please assist on this further.
If you are using a web service (httpd, etc) to service your files, then
make it authenticated and have it log.
>
>
> Thanks and Regards,
> Varun Gulati
>
>
>
>
>
> On Tuesday, 10 May 2016 1:32 AM, Steve Grubb <sgrubb@redhat.com>
> wrote:
>
>
>
> On Monday, May 09, 2016 04:13:19 PM varun gulati wrote:
> > Hi Team,
> > We have requirement where we have to monitor and log any read
> operations
> > performed on a file. e.g. /a/b/c/xyz.log
>
> -a always,exit -F path=/a/b/c/xyz.log -F perm=r -F key=log-access
>
>
> > This file is usually copied and downloaded by many users using
> various
> > operations, like, wget, ssh, jsp Download link provided. These
> commands are
> > fired from different hosts. With the auditd we want to create a rule
> which
> > auditctl can leverage to log the User ID that is reading (and
> copying) it
> > from a different host may be.
>
> You will get the local auid/uid that the kernel sees when the request
> triggers
> the rule. There is nothing more that can be done from the audit
> system.
>
> -Steve
>
>
>
> > I have gone through many of the rules but didn't find anything
> fruitful as
> > such (which logs wget, scp commands from remote hosts). May be I am
> missing
> > on something. Since it is a very crucial requirement, appreciate
> your
> > guidance and directions with this. Let me know in case you require
> any
> > further information from my end. Many thanks in advance.
> >
> >
> >
> > Thanks and Regards,Varun Gulati
>
>
>
>
>
> --
> Linux-audit mailing list
> Linux-audit@redhat.com
> https://www.redhat.com/mailman/listinfo/linux-audit
^ permalink raw reply
* Re: audit-tools and SUDO
From: Burn Alting @ 2016-05-10 12:52 UTC (permalink / raw)
To: Warron S French; +Cc: linux-audit@redhat.com
In-Reply-To: <BY1PR09MB088756540EEFEFF5B6F54862C7710@BY1PR09MB0887.namprd09.prod.outlook.com>
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
^ permalink raw reply
* RE: audit-tools and SUDO
From: Warron S French @ 2016-05-10 13:07 UTC (permalink / raw)
To: burn@swtf.dyndns.org; +Cc: linux-audit@redhat.com
In-Reply-To: <1462884741.3439.16.camel@swtf.swtf.dyndns.org>
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
^ permalink raw reply
* Re: audit-tools and SUDO
From: Steve Grubb @ 2016-05-10 13:25 UTC (permalink / raw)
To: linux-audit, burn
In-Reply-To: <1462884741.3439.16.camel@swtf.swtf.dyndns.org>
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
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox