need help interpreting ausearch results

Sun Dec 22 23:07:17 UTC 2013

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 at 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 at redhat.com
> > >>> https://www.redhat.com/mailman/listinfo/linux-audit
> > >> --
> > >> Linux-audit mailing list
> > >> Linux-audit at redhat.com
> > >> https://www.redhat.com/mailman/listinfo/linux-audit
> > >
> >
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20131223/06305d5a/attachment.htm>