[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [Linux-cluster] Quick off topic question

Hash: SHA1

Brian Pontz wrote:
>> Unfortunately, that would defeat the purpose behind
>> my wanting to remotely log 
>> the activity.
> You can do this through syslog but it would require
> you to modify the kernel code and recompile it. You
> would basically printk() all exec's in the kernel.
> Otherwise the honeynet project would probably be the
> best people to ask about this.

Isn't that what the audit subsystem is designed for?

No need for custom kernels - just set some audit rules to monitor execs
and parse the auditd output. This still won't be a perfect replacement
for bash_history though as it will loose some detail of the arguments.

That said, if this is purely for security monitoring and not to have a
list of commands and their arguments for re-play purposes (that's the
goal of a shell history), I think audit would be the most
straightforward solution.

You need to set up two files to configure auditing, auditd.conf and
audit.rules. The first governs the daemon itself, the second tells it
what to audit.

There's currently no direct support for syslog-style @host remote
logging, but there is a "dispatcher" directive in auditd.conf that will
run an external command when audit starts and pipe each message to that
program's stdin - a simple wrapper would then be able to squirt the
messages to a remote server if needed.

Alternately, make /var/log/audit a separate filesystem on GFS and write
the logs here. That will probably need some twiddling as I think auditd
normally starts before GFS filesystems are mounted but shouldn't be

A simple audit rule to get started could look like this:

- -a exit,always -S exec

You can be more specific about what to log, filter by uid, pid and other
attributes - see the auditctl man page for the details as well as the
sample rule files under /usr/share/doc/audit-*/.

One word of warning - it's possible to DoS yourself in a couple of ways
with audit. The default behavior when audit cannot create its logs is to
panic - this is for high security environments where no service is
better than insecure service. Disable it by setting "-f 0" or "-f 1" in
the rules file (silent/printk on error respectively).

Also, the volume of messages can be huge with a very broad ruleset - be
sure to allow enough space for the logs and to configure rotation if needed.

More info here:




> Brian
> --
> Linux-cluster mailing list
> Linux-cluster redhat com
> https://www.redhat.com/mailman/listinfo/linux-cluster

Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]