LAUS, Auditors and log reviews

[dmaahs]

The question here; how are others performing log review of LAUS and other ESX Service console logs that are required by STIG. By requirement, the auditd daemon must be running on the ESX Service Console from both the Linux SRR and ESX Checklist. That would be the simple part. The ongoing issue is how to review and archive of all the logs created.

Our audit team does not have shell access to the service console, nor am I comfortable with providing this access. So I was considering creating a script to augrep and find records in intervals, passing the results to the logger function to get the information to our central syslog server. Then using a standard grep, doing the same thing for the other logs that need to be reviewed on a period basis. The audit team has access to the syslog server and could review everything centrally.

How are others either planning on, or doing the review/archive process?

[Texiwill]

Hello,

Our audit team does not have shell access to the service console, nor am I comfortable with providing this access. So I was considering creating a script to augrep and find records in intervals, passing the results to the logger function to get the information to our central syslog server. Then using a standard grep, doing the same thing for the other logs that need to be reviewed on a period basis. The audit team has access to the syslog server and could review everything centrally.

They should not be given access, setup remote syslog from the SC. THat is the best option as your audit team already has the access they need and all your ESX logs should be going there anyways per other security guides.

Best regards,

Edward L. Haletky

VMware Communities User Moderator

====

Author of the book 'VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers', Copyright 2008 Pearson Education.

CIO Virtualization Blog: http://www.cio.com/blog/index/topic/168354

As well as the Virtualization Wiki at http://www.astroarch.com/wiki/index.php/Virtualization

[Mark_Moeller]

I'm not sure what your end purpose of auditing your logs is, best practice or compliance, but we have been able to assist customers with audit data from their virtual servers and desktops. If you'd like to see some samples of the reports we can generate, please check our website at for general reporting or for regulatory compliance reporting. Our methodology does not require access to the service console since we monitor the activity going across the virtual switch which provides great compliance and user access data across hosts and is independent of OS or applications.

If you'd like more detailed information please contact me at .

[dmaahs]

The end purpose of the review and archive of the logs is to meet government compliance. ESX as a host is required to comply with the UNIX and ESX STIGs as published by DISA for DIACAP. Both STIGs have a review and archive component that if not met becomes a 'finding'. (Maybe should have a topic that defines all the acronyms)

GEN002900 - Audit files are retained for at least 1 year.

GEN002920 - Audit files are backed up no less than weekly on to a different system.

GEN002940 - On a daily basis the IAO will review the audit trails and/or system logs for... (There is a long list)

ESX0420 - ESX Server logs are not reviewed daily, this includes vmkernel, vmkwarning, vmksummary, hostd.log, each instances vmware.log, vpxa.log, webAccess, messages, and secure.

ESX0820 - VirtualCenter logs are not reviewed daily.

Those are most of the findings, but not insignificant when considered that LAUS, each instances vmware.log, webAccess and many of the other logs are not syslog compliant, that I am aware of. So there needs to be a method for either direct access to the service console for the daily review, or a way to off-load to an external server for review and archive. I don't like the option of have more people in the console than needed so off-loading some way appears to be it.

To accomplish this, the method right now that comes to mind is script(s) that push the information through the logger binary. This will then send it to the syslog server and then falls under the retention policies of that system. Plus the auditors have direct access to the syslog system.

My purpose for this topic was two fold. One, I want to see if someone is doing it another way that would be better. I was planning on writing these scripts, but don't want to if I don't have to. And two, since DISA just published the ESX Checklist more people are having to come up with the how to get the job done. If this topic can assist with how to get through the LAUS, log review and retention findings, great. I am glad it could help.

[Texiwill]

Hello,

vmSight has a great product but will not help much with the LAUS and other SC logs. It does help when you are discussing VM to VM communication and anything that travels over a vSwitch however.

Many of the VMware logs are syslog compliant or you can use a combination of tail and logger to redirect those logs to a syslog server.

Best regards,

Edward L. Haletky

VMware Communities User Moderator

====

Author of the book 'VMWare ESX Server in the Enterprise: Planning and Securing Virtualization Servers', Copyright 2008 Pearson Education.

CIO Virtualization Blog: http://www.cio.com/blog/index/topic/168354

As well as the Virtualization Wiki at http://www.astroarch.com/wiki/index.php/Virtualization

[dmaahs]

I wrote this script yesterday and let it run overnight. Been working pretty good thus far.

The script will export everything from within the audit database since the last time it ran. The export uses logger, so everything will end up in /var/log/messages, but will also now be forwarded to a syslog host. We use syslog-ng on our central servers, so the data is seperated based on the tags that are used, the -t flag on logger.

Place the script in /usr/local/bin, and the .cron file in /etc/cron.d. It is currently set to export every 15 minutes. Keep an eye on the script's log, /var/log/audit.d/exportAuditData.log. The script will log how many events it exports and for what period. Depending on the run frequency, this may grow quickly. Put an entry in logrotate.d to rotate it if it becomes an issue.

Enjoy, but standard disclaimers. Run on your test boxes first to make sure it works in your environment.

In the next week or so, I hope to have the scripts written to export the other logs that do not use syslog currently.

[dmaahs]

Didn't see the .cron file attached so here it is.