Audit in Kerberos
Ezra Peisach
epeisach at mit.edu
Thu Jan 21 15:47:04 EST 2010
On 1/21/2010 3:04 PM, Zhanna Tsitkova wrote:
> Hello,
> I would like to re-introduce the idea of extending the Kerberos
> security policy by adding an Audit feature to track the activity on
> the KDC side.
>
> This would include such events, both successes and failures, as
> ticket request, ticket issued/renewed, is ticket forwardable, kdc
> referral activity, password modified/expired, constarained delegation
> (for future) etc.
>
> There are few problems that must be addressed
> 1. Where to store the audit info - in file or DB?
> Syslog seems to be an attractive option. However, only admin
> privileged users can access and interpret the log.
>
Not all OS's protect the syslog information. The advantage/disadvantage
of syslog is that it pushes the info out fast using UDP (I believe) and
then the syslogd manages it. Messages can get lost if the disk fills, etc.
> DB log storage suggests more flexibility when users based on
> their access rights may review and analyze the accumulated log data.
> The drawback here is the worsened performance and scalability.
>
There are a number of newer databases out there that show better
performance than the DB we have (tokyocabinet and I think there is
something newer)
> 2. What format should be used to store the messages. If the messages
> are stored in the syslog they need to be suitable for db uploading.
> XML or text? (XML format would result into the rapid file-size growth
> but , if stored remotely may be not a problem)
>
I do not personally like xml - but I would not want a binary format.
> 3. Make this feature plugable.
>
Definite - then you can have the syslog, db, xml, mysql, sqlite, remote
reporting, etc plugins as needed.
> 4. Some vendors have their own in-house audit mechanisms incorporated
> in the Kerberos code. Should we introduce our own daemons to
> monitor,alert, interpret, archive and cleanup or sanitization of the
> accumulated log data or should we relay on the OS capabilities?
>
>
This is an os issue. If you are using syslogd - O/S vendors have their
own tools to cleanup the files - do not reinvent the wheel. On the
other hand - providing a tool for groveling the logs, send alerts, etc
periodically would be useful. But there might be something out there
that does that already for say an xml structured file (heck I bet nagios
could do this). I would say - don't reinvent the wheel there - but if
there is a standard monitoring program that can be extended - with their
own plugin system - then write the plugin.... Heck - just googling - I
found sawmill - which looks nice
> Any feedback and opinions and recommendations are greatly appreciated.
>
>
In short - give people options w/ plugins - but provide some rudimentary
backends...
ezra
More information about the krbdev
mailing list