From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefano Schiavi Subject: Re: need help interpreting ausearch results Date: Mon, 23 Dec 2013 22:04:17 +0100 Message-ID: <52B8A551.8020907@gmail.com> References: <52ACE768.7030606@gmail.com> <52B58E25.4080007@gmail.com> <87d2koddfi.fsf@root.hda3.com> <1387746051.3594.9.camel@swtf.swtf.dyndns.org> <52B75CA7.8060209@gmail.com> <1387749181.3594.16.camel@swtf.swtf.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: Received: from mx1.redhat.com (ext-mx13.extmail.prod.ext.phx2.redhat.com [10.5.110.18]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id rBNL4NB9013312 for ; Mon, 23 Dec 2013 16:04:23 -0500 Received: from mail-ee0-f51.google.com (mail-ee0-f51.google.com [74.125.83.51]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rBNL4KVv007304 for ; Mon, 23 Dec 2013 16:04:21 -0500 Received: by mail-ee0-f51.google.com with SMTP id b15so2577252eek.10 for ; Mon, 23 Dec 2013 13:04:20 -0800 (PST) In-Reply-To: <1387749181.3594.16.camel@swtf.swtf.dyndns.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: burn@swtf.dyndns.org Cc: linux-audit@redhat.com List-Id: linux-audit@redhat.com Hello Burn, Thank you so much again. I have implemented the steps you suggested below. One question: is there anything you think I can do now to clarify what process triggered the chmod command 9 days ago? Thank you! kind regards, Stefano On 12/22/13, 10:53 PM, Burn Alting wrote: > Stefano, > > Just add the lines to /etc/audit/audit.rules after your directory > watches > > -a always,exit -F arch=b32 -S chmod -S fchmod -S fchmodat -S chown -S > fchown -S fchownat -S lchown -S setxattr -S lsetxattr -S fsetxattr -S > removexattr -S lremovexattr -S fremovexattr -F auid!=0 -F auid! > =4294967295 -k perm_mod > -a always,exit -F arch=b64 -S chmod -S fchmod -S fchmodat -S chown -S > fchown -S fchownat -S lchown -S setxattr -S lsetxattr -S fsetxattr -S > removexattr -S lremovexattr -S fremovexattr -F auid!=0 -F auid! > =4294967295 -k perm_mod > > -a exit,always -F arch=b32 -S execve -k cmds > -a exit,always -F arch=b64 -S execve -k cmds > > Then reload the audit service with > service auditd reload > or > /etc/init.d/auditd reload > > At this point you should start seeing more events in > your /var/log/audit/audit.log files. > > Then monitor your filesystem or audit till you see the 777 change again. > > Can you review your web server code? In effect, auditd has already > informed you that a php process executed the chmod system call ... the > execve monitoring will just help with the arguments to the program and > the parent processes (and their arguements). > > The bottom line is that you will still need to be able to review your > php code. > > Rgds > Burn > > > > On Sun, 2013-12-22 at 22:41 +0100, Stefano Schiavi wrote: >> Hello and thank you very much for your responses! >> >> You have to forgive me but it's a tad hard for me to follow. >> >> I am not sure I can trace down the process by the pid since the incident >> happened about 8 days ago. Please correct me if wrong. >> >> I have the following rules setup: >> >> -a exit,always -F dir=/home/lanogbar/public_html -F perm=war -F >> key=lanogbar-pubhtmlwatch >> >> -a exit,always -F path=/home/lanogbar/public_html -F perm=war -F >> key=lanogbar-pubhtmlwatch >> >> I only watch directories not files. >> Specifically the public_html whcih is the one causing the troubles. >> >> Because I don't have much experience with this, would it be possible for >> you to suggest me how to change the above rules or what commands to run now? >> >> Apologies for being unable to follow your guidance. >> >> Please let me know anything else I can do. >> It would be really great to finally nail down what is causing the >> website to break out of the blue every now and then. >> >> Thank you again. >> Kind regards, >> Stefano >> >> >> >> >> On 12/22/13, 10:00 PM, Burn Alting wrote: >>> Stefano, >>> >>> I assume your rules are file watches. Yes, on the surface, it looks like >>> a service user, lanogbar, is running a php application which has make >>> the chmod system call making the change to 777 (ie a1=1ff in the second >>> event shown). >>> >>> You could check the process id's (the one which does the chmod - pid = >>> 8804, or the parent process id - ppid = 27717) although these might be >>> temporary processes ... perhaps you could turn on execution audit >>> >>> -a exit,always -F arch=b32 -S execve -k cmds >>> -a exit,always -F arch=b64 -S execve -k cmds >>> >>> >>> perhaps also specific chmods also ... >>> >>> -a always,exit -F arch=b32 -S chmod -S fchmod -S fchmodat -S chown -S >>> fchown -S fchownat -S lchown -S setxattr -S lsetxattr -S fsetxattr -S >>> removexattr -S lremovexattr -S fremovexattr -F auid!=0 -F auid! >>> =4294967295 -k perm_mod >>> -a always,exit -F arch=b64 -S chmod -S fchmod -S fchmodat -S chown -S >>> fchown -S fchownat -S lchown -S setxattr -S lsetxattr -S fsetxattr -S >>> removexattr -S lremovexattr -S fremovexattr -F auid!=0 -F auid! >>> =4294967295 -k perm_mod >>> >>> Also, as Peter suggests it does help if you present the output from >>> ausearch -i rather than the raw data from /var/log/audit/audit.log. >>> >>> >>> >>> >>> On Sun, 2013-12-22 at 09:05 -0800, Peter Moody wrote: >>>> What's the actual rule? On my system, syscall 88 is either symlink (64 bit) or reboot (32 bit). >>>> >>>> On Sat, Dec 21 2013 at 04:48, Stefano Schiavi wrote: >>>>> Hello, >>>>> >>>>> Could anyone help with this? I really don't know where else to ask. >>>>> >>>>> Thank you very much. >>>>> Stefano >>>>> >>>>> >>>>> On 12/15/13, 12:19 AM, Stefano Schiavi wrote: >>>>>> Hello, >>>>>> >>>>>> Thank you Steve and all for keeping up the great work here. >>>>>> >>>>>> Some time ago I setup some audit rules to monitor what would change the permissions of the >>>>>> public_html directory since we found that once in a while it would change to 777 out of the >>>>>> blue. >>>>>> >>>>>> It happened again yesterday and I believe these parts of the log represent when the issue >>>>>> happened: >>>>>> >>>>>> type=PATH msg=audit(1386933561.795:7958476): item=2 name="./www" inode=4980752 dev=08:08 >>>>>> mode=0120777 ouid=501 ogid=501 rdev=00:00 >>>>>> type=PATH msg=audit(1386933561.795:7958476): item=1 name="./" inode=4980737 dev=08:08 >>>>>> mode=040711 ouid=501 ogid=501 rdev=00:00 >>>>>> type=PATH msg=audit(1386933561.795:7958476): item=0 name="public_html" >>>>>> type=CWD msg=audit(1386933561.795:7958476): cwd="/home/lanogbar" >>>>>> type=SYSCALL msg=audit(1386933561.795:7958476): arch=c000003e syscall=88 success=yes exit=0 >>>>>> a0=1306d160 a1=1306d200 a2=11 a3=0 items=3 ppid=18728 pid=18731 auid=0 uid=501 gid=501 >>>>>> euid=501 suid=501 fsuid=501 egid=501 sgid=501 fsgid=501 tty=(none) ses=117304 comm="gtar" >>>>>> exe="/bin/tar" key="lanogbar-www" >>>>>> >>>>>> >>>>>> This is just a guess though and I can not be sure as I have no experience parsing the >>>>>> logs. Looking through with the I flag we can see the following:: >>>>>> >>>>>> type=PATH msg=audit(12/13/2013 15:00:03.759:7970202) : item=0 >>>>>> name=/home/lanogbar/public_html/ inode=4980744 dev=08:08 mode=dir,750 ouid=lanogbar >>>>>> ogid=nobody rdev=00:00 >>>>>> type=CWD msg=audit(12/13/2013 15:00:03.759:7970202) : cwd=/home/lanogbar/public_html >>>>>> type=SYSCALL msg=audit(12/13/2013 15:00:03.759:7970202) : arch=x86_64 syscall=chmod >>>>>> success=yes exit=0 a0=1585e520 a1=1ff a2=2f a3=146c1d40 items=1 ppid=27717 pid=8804 auid=root >>>>>> uid=lanogbar gid=lanogbar euid=lanogbar suid=lanogbar fsuid=lanogbar egid=lanogbar >>>>>> sgid=lanogbar fsgid=lanogbar tty=(none) ses=117304 comm=php exe=/usr/bin/php >>>>>> key=lanogbar-public_html >>>>>> >>>>>> Do you think this is relevant? >>>>>> If so it would seem a php script was responsible. >>>>>> >>>>>> Would you have any suggestion on how to identify the script? >>>>>> >>>>>> Thank you very much for the very valuable help. >>>>>> Kind regards, >>>>>> Stefano >>>>> -- >>>>> 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 >