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
[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
