Martin Englund's Weblog

Comments:

This is certainly useful as the problem you mentioned in the blog is real and serious. Although I don't think syslog is the best solution since it uses UDP for transport so delivery is not guaranteed . Also messages can be easily spoofed and the truncation problem is nasty. Plus you would probably need something different from auditreduce and the rest of standard audit commands to parse these audit trails embedded in syslog. So although functional this method doesn't look polished/integrated enough I think of two other variants that are a little more complicated to setup but seem clean 1) For Solaris 10: don't do anything in the global zone. Put anything into a nonglobal zone and do the logging from the global zone. If one becomes root in the nonglobal zone s/he can't access the log or stop the audit daemon. If we assume the barrier between zones cannot be crossed no matter what this is a good method. The possible downside for some people is that you need to put everything in a nonglobal zone for every log client. 2) Other Solaris versions: Have a log server on which create a special RBAC user which can only execute a script. No other rights (uncomment the "AUTHS_GRANTED and PROFS_GRANTED in /etc/security/policy.ocnf). The script can only append to an existing audit log file. From log clients create a script that does something like "tail bsm_log | ssh rbacusr@logsrv append". Setup ssh key authentication from clients to the server for the RBAC user. This way someone that becomes root on one client can only append data to the log file on the log server. It cannot modify existing data. And since the user it get access to on the log server is a RBAC user that can only execute a wrapper script, the attacker cannot use a local-user escalation exploit to become root on the server. Of course for this method you need to setup key authentication and carefully create the scripts but if done the format of the files is the same as in a standard logging system. What do you think of these ? Vlad.

Posted by Vlad Grama on August 26, 2004 at 03:55 AM PDT #

Hi Vlad!

Both your suggestions are good solutions to the problem, but as I run IPsec between my systems, I don't have to worry about the spoofing. The lost and truncated records is a bigger problem.

As you point out, what we need is a secure syslog demon.

cheers,
/Martin

Posted by Martin Englund on August 26, 2004 at 04:11 AM PDT #

Audit plugins

Old entries