[syslog-ng] Unable to track root activity in syslog-ng

vijay amruth vijayamruth at gmail.com
Thu May 11 17:50:06 UTC 2017


Thank you Scot, Jim, Bazsi.

JIm/Bazsi, thank you for the detailed explanation.
Jim, I was not aware of this unix behavior, I  always learn from all you.
thank you.
Bazsi, I am trying to set up auditd as suggested, thank you very much.

Vijay Amrut.

On Wed, May 10, 2017 at 8:52 PM, Scheidler, Balázs <
balazs.scheidler at balabit.com> wrote:

> I think the answer you are looking at is auditd, which can generate audit
> entries for all exec() system calls. (Set up using auditctl)
>
> Then have auditd send its entries to syslog.
>
> The format of the audit log is a name-value format that can be parsed by
> linux-audit-parser(), which is built into syslog-ng. You'll probably also
> need to correllate multiple messages as a single event is producing
> multiple audit entries. That can be achieved using grouping-by(), again a
> parser built into syslog-ng.
>
> Hth,
> Bazsi
>
> On May 11, 2017 3:21 AM, "Jim Hendrick" <james.r.hendrick at gmail.com>
> wrote:
>
>> Your syslog-ng config is fine. The problem is your understanding of how
>> sudo logs vs. commands run in a shell.
>>
>> sudo the program is written specifically to log all its commands. Shells
>> are not. They write history files, but do not send the commands to the
>> kernel logging facility.
>>
>> There are certainly ways to deal with this but the best answer is to use
>> sudo. Basically do not allow users to login (or su ) to root directly.
>> Often this is done in the sudoers file with something like
>> <user> all, !shells
>>
>> where the "shells" macro is expanded to whatever is installed as system
>> shells (e.g. /bin/bash, /bin/csh, /bin/sh, etc.)
>>
>> Why shells do not log all commands to the kernel is a topic for
>> philosophical analysis of the development of unix :-)
>>
>> Seriously - just say no to root shell!
>>
>> Best,
>> Jim
>>
>> On Wed, May 10, 2017 at 7:33 PM, vijay amruth <vijayamruth at gmail.com>
>> wrote:
>>
>>> Hello everyone, here is is my configuration file, I am unable to track
>>> root activity, I am able to track user activity like the commands ran etc.
>>>
>>> For example: If I run a command as sudo, I see it in the log however the
>>> same command when switched to root is not being tracked.
>>>
>>> Any help is appreciated. Thank you.
>>>
>>>
>>> @version:3.9
>>> @include "scl.conf"
>>>
>>>
>>> options { threaded(yes); };
>>>
>>>
>>> source s_sys {
>>> unix-stream("/dev/log");
>>>     system();
>>>     internal();
>>>
>>> };
>>>
>>>
>>> # Destinations
>>> ##############
>>>
>>> destination d_cons { file("/dev/console"); };
>>> destination d_mesg { file("/var/log/messages"); };
>>> destination d_auth { file("/var/log/secure"); };
>>> destination d_mail { file("/var/log/maillog" flush_lines(10)); };
>>> destination d_spol { file("/var/log/spooler"); };
>>> destination d_boot { file("/var/log/boot.log"); };
>>> destination d_cron { file("/var/log/cron"); };
>>> destination d_kern { file("/var/log/kern" ); };
>>> destination d_mlal { usertty("*"); };
>>>
>>>
>>> # Filters
>>> ##########
>>>
>>> filter f_kernel     { facility(kern); };
>>> filter f_default    { level(info..emerg) and
>>>                         not (facility(mail)
>>>                         or facility(authpriv)
>>>                         or facility(cron)); };
>>> filter f_auth       { facility(authpriv); };
>>> filter f_mail       { facility(mail); };
>>> filter f_emergency  { level(emerg); };
>>> filter f_news       { facility(uucp) or
>>>                         (facility(news)
>>>                         and level(crit..emerg)); };
>>> filter f_boot   { facility(local7); };
>>> filter f_cron   { facility(cron); };
>>>
>>> # Log Bindings
>>> ##############
>>>
>>>
>>> #log { source(s_sys); filter(f_kernel); destination(d_cons); };
>>> log { source(s_sys); filter(f_kernel); destination(d_kern); };
>>> log { source(s_sys); filter(f_default); destination(d_mesg); };
>>> log { source(s_sys); filter(f_auth); destination(d_auth); };
>>> log { source(s_sys); filter(f_mail); destination(d_mail); };
>>> log { source(s_sys); filter(f_emergency); destination(d_mlal); };
>>> log { source(s_sys); filter(f_news); destination(d_spol); };
>>> log { source(s_sys); filter(f_boot); destination(d_boot); };
>>> log { source(s_sys); filter(f_cron); destination(d_cron); };
>>>
>>>
>>>
>>> --
>>> Thanks,
>>> Vijay.
>>>
>>> ____________________________________________________________
>>> __________________
>>> Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng
>>> Documentation: http://www.balabit.com/support
>>> /documentation/?product=syslog-ng
>>> FAQ: http://www.balabit.com/wiki/syslog-ng-faq
>>>
>>>
>>>
>>
>> ____________________________________________________________
>> __________________
>> Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng
>> Documentation: http://www.balabit.com/support/documentation/?product=
>> syslog-ng
>> FAQ: http://www.balabit.com/wiki/syslog-ng-faq
>>
>>
>>
> ____________________________________________________________
> __________________
> Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng
> Documentation: http://www.balabit.com/support/documentation/?
> product=syslog-ng
> FAQ: http://www.balabit.com/wiki/syslog-ng-faq
>
>
>


-- 
Thanks,
Vijay Amrut.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.balabit.hu/pipermail/syslog-ng/attachments/20170511/6ac34cdb/attachment.html>


More information about the syslog-ng mailing list