* 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).