RE: audit review question

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(a)aero.org&gt; Cc: linux-audit(a)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(a)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(a)redhat.com&gt; > Cc: linux-audit(a)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(a)aero.org&gt; > Cc: linux-audit(a)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(a)redhat.com > > Cc: Warron S French <warron.s.french(a)aero.org&gt; > > 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(a)redhat.com > https://www.redhat.com/mailman/listinfo/linux-audit