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

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

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

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

Stephano, You could look at all processes owned by the user lanogbar and then review the code that they are running. I know you mentioned you had root access, but do you also have the actual php code for your web service? If so, you should do a code review on why the service would change directory permissions. Perhaps look for any cron entries as well that run as lanogbar or spawn off processes for this user. I'd also double and triple check all configurations for your web server code. You may also want to research (google is your friend) for any known exploits against your web service. Chmod'ing the root to 777 is not very 'nice'. Regards Burn On Mon, 2013-12-23 at 22:04 +0100, Stefano Schiavi wrote: > 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(a)redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/linux-audit >>>>> -- >>>>> Linux-audit mailing list >>>>> Linux-audit(a)redhat.com >>>>> https://www.redhat.com/mailman/listinfo/linux-audit