* need help interpreting ausearch results @ 2013-12-14 23:19 Stefano Schiavi 2013-12-21 12:48 ` Stefano Schiavi 0 siblings, 1 reply; 10+ messages in thread From: Stefano Schiavi @ 2013-12-14 23:19 UTC (permalink / raw) To: linux-audit 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: need help interpreting ausearch results 2013-12-14 23:19 need help interpreting ausearch results Stefano Schiavi @ 2013-12-21 12:48 ` Stefano Schiavi 2013-12-22 17:05 ` Peter Moody 0 siblings, 1 reply; 10+ messages in thread From: Stefano Schiavi @ 2013-12-21 12:48 UTC (permalink / raw) To: linux-audit 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: need help interpreting ausearch results 2013-12-21 12:48 ` Stefano Schiavi @ 2013-12-22 17:05 ` Peter Moody 2013-12-22 21:00 ` Burn Alting 0 siblings, 1 reply; 10+ messages in thread From: Peter Moody @ 2013-12-22 17:05 UTC (permalink / raw) To: Stefano Schiavi; +Cc: linux-audit 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: need help interpreting ausearch results 2013-12-22 17:05 ` Peter Moody @ 2013-12-22 21:00 ` Burn Alting 2013-12-22 21:41 ` Stefano Schiavi 0 siblings, 1 reply; 10+ messages in thread From: Burn Alting @ 2013-12-22 21:00 UTC (permalink / raw) To: Peter Moody; +Cc: linux-audit 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 ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: need help interpreting ausearch results 2013-12-22 21:00 ` Burn Alting @ 2013-12-22 21:41 ` Stefano Schiavi 2013-12-22 21:53 ` Burn Alting 0 siblings, 1 reply; 10+ messages in thread From: Stefano Schiavi @ 2013-12-22 21:41 UTC (permalink / raw) To: burn, Peter Moody; +Cc: 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@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 [flat|nested] 10+ messages in thread
* Re: need help interpreting ausearch results 2013-12-22 21:41 ` Stefano Schiavi @ 2013-12-22 21:53 ` Burn Alting 2013-12-22 23:07 ` stefano schiavi 2013-12-23 21:04 ` Stefano Schiavi 0 siblings, 2 replies; 10+ messages in thread From: Burn Alting @ 2013-12-22 21:53 UTC (permalink / raw) To: Stefano Schiavi; +Cc: 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@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 [flat|nested] 10+ messages in thread
* Re: need help interpreting ausearch results 2013-12-22 21:53 ` Burn Alting @ 2013-12-22 23:07 ` stefano schiavi 2013-12-23 21:04 ` Stefano Schiavi 1 sibling, 0 replies; 10+ messages in thread From: stefano schiavi @ 2013-12-22 23:07 UTC (permalink / raw) To: burn; +Cc: linux-audit [-- Attachment #1.1: Type: text/plain, Size: 7383 bytes --] Hello Burn, Thank you very much for your patience. I can follow your instructions, and yes I can review the code on the server, I have root access. I will try this tomorrow. Thank you very much again, Kind regards, Stefano On Dec 22, 2013 10:53 PM, "Burn Alting" <burn@swtf.dyndns.org> 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 > > > > > > > > [-- Attachment #1.2: Type: text/html, Size: 9739 bytes --] [-- Attachment #2: Type: text/plain, Size: 0 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: need help interpreting ausearch results 2013-12-22 21:53 ` Burn Alting 2013-12-22 23:07 ` stefano schiavi @ 2013-12-23 21:04 ` Stefano Schiavi 2013-12-24 2:15 ` Burn Alting 1 sibling, 1 reply; 10+ messages in thread From: Stefano Schiavi @ 2013-12-23 21:04 UTC (permalink / raw) To: burn; +Cc: linux-audit 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 > ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: need help interpreting ausearch results 2013-12-23 21:04 ` Stefano Schiavi @ 2013-12-24 2:15 ` Burn Alting 2013-12-24 18:43 ` Stefano Schiavi 0 siblings, 1 reply; 10+ messages in thread From: Burn Alting @ 2013-12-24 2:15 UTC (permalink / raw) To: Stefano Schiavi; +Cc: 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@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 [flat|nested] 10+ messages in thread
* Re: need help interpreting ausearch results 2013-12-24 2:15 ` Burn Alting @ 2013-12-24 18:43 ` Stefano Schiavi 0 siblings, 0 replies; 10+ messages in thread From: Stefano Schiavi @ 2013-12-24 18:43 UTC (permalink / raw) To: burn; +Cc: linux-audit Thank you very much again Burn, The website was built using joomla, and uses several extensions. It would be a daunting task to inspect all extensions, or that is what it feels for me. I did check the cron jobs before and nothing strange there I did triple checked the configuration of the server. I did search google multiple times but was unable to find anything so far. This was very helpful so far, thanks to the help in this list we were able to setup audit properly and hopefully next time it happens we will have enough information to identify the specific script. Thank you so much for your help. Kind regards and a marvelous Christmas, Stefano On 12/24/13, 3:15 AM, Burn Alting wrote: > 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@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 [flat|nested] 10+ messages in thread
end of thread, other threads:[~2013-12-24 18:43 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-12-14 23:19 need help interpreting ausearch results Stefano Schiavi 2013-12-21 12:48 ` Stefano Schiavi 2013-12-22 17:05 ` Peter Moody 2013-12-22 21:00 ` Burn Alting 2013-12-22 21:41 ` Stefano Schiavi 2013-12-22 21:53 ` Burn Alting 2013-12-22 23:07 ` stefano schiavi 2013-12-23 21:04 ` Stefano Schiavi 2013-12-24 2:15 ` Burn Alting 2013-12-24 18:43 ` Stefano Schiavi
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).