need help interpreting ausearch results

[Stefano Schiavi]

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