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" <[email protected]> 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 > > >>> [email protected] > > >>> https://www.redhat.com/mailman/listinfo/linux-audit > > >> -- > > >> Linux-audit mailing list > > >> [email protected] > > >> https://www.redhat.com/mailman/listinfo/linux-audit > > > > > > > >
-- Linux-audit mailing list [email protected] https://www.redhat.com/mailman/listinfo/linux-audit
