Home > Blogs > VMware vSphere Blog


Virtual Appliances getting more secure with vSphere 5.5 – Part 4

Meeting Objectives with VMware Hardened Virtual Appliances

In this final part, we’ll go over setting up logging (both system and audit logs) and Grub hardening and NFS/NIS management and wrap it all up in the Conclusion.

Log Forwarding – Syslog-ng and Auditd

All VMware Hardened Virtual Appliances include both comprehensive system and audit logging to support high governance compliance. In 2013, VMware released the VMware Log Insightproduct to support centralized log services and log analytics. For setup and configuration information, please refer to the product configuration guide.

To enable forwarding of system logs, modify the configuration file of the syslog server to specify the protocol, IP address, and port of the central log server. The syslog configuration file is located in /etc/syslog-ng/syslog-ng.conf. Using the vi editor as root, find the following two lines:

#destination logserver { udp("10.10.10.10" port(514)); };
#log { source(src); destination(logserver); };

 

Uncomment the two lines, and modify the fields. In this example, using tcp as the transport, 10.10.10.10 as the IP of the central syslog server, and port 514 as the syslog central server port, the entry would be:

destination logserver { tcp("10.10.10.10" port(514)); };
log { source(src); destination(logserver); };

 

Restart the service as root to incorporate the change:

# service syslog restart

 

NOTE: Ensure that the firewall allows access to the port specified for the syslog destination log server.

Audit Log Forwarding .vs. System Log Forwarding

For auditd forwarding, the vCenter Virtual Appliance includes the audisp-remote package to separate audit log forwarding from system log forwarding. If separation of the two logging services is preferred or required, the audit daemon remote configuration file is located in /etc/audisp/audisp-remote.conf to provide the necessary configuration settings to forward audit logs to a centralized audit server. Using the vi editor as root, edit the following entries:

remote_server = ip_of_remote_audit_server
port = port of auditd central service
transport = protocol for transferring audit logs

 

In this example, using tcp as the transport, 10.10.10.10 as the IP of the auditd central server, and port 60, the entries would be:

remote_server = 10.10.10.10
port = 60
transport = tcp

 

Restart the service as root to incorporate the change:

# service auditd restart

 

NOTE: Ensure that the firewall allows access to the port specified for the auditd destination log server.

For all other hardened appliances, the syslog remote plugin is provided to forward all audit logs to the syslog-ng service. The configuration file is located in /etc/audisp/plugins.d/syslog.conf. Using the vi editor as root, edit the entry:

active = no

 

to:

active=yes

 

This will forward all audit logs to /var/log/messages.

Restart the service as root to incorporate the change:

# service auditd restart

 

NOTE: When using the high governance audit rules, there is an increase in the amount of logging traffic that may warrant reconfiguration of both the q_depth and the priority_boost of the audit dispatcher daemon. The configuration file is located in /etc/audisp/audispd.conf. Using the vi editor as root, edit the following entries:

q_depth = 80 (recommendation for high governance audit logs is at least 1280)
priority_boost = 4 (recommendation for high governance audit logs is at least 
8)

 

Restart the service as root to incorporate the change:

# service auditd restart

 

NOTE: When using the high governance audit rules, there is an increase in the size of log files. To decrease the number of stored logs on the hardened appliances (this assumes log forwarding has been configured), customers can tune the number of daily log files stored by modifying the rotation number. All log rotation configurations are stored in /etc/logrotate.d.

To control the number of stored daily log files for syslog, edit the /etc/logrotate.d/syslog file as root. Modify all of the “rotate 15” entries with the vi editor to the number of days to store local logs. The recommended number of days for centralized log services is at least 7.

To control the number of stored daily log files for the audit daemon, edit the /etc/logrotate.d/audit file as root. Modify the “rotate 15” entry with the vi editor to the number of days to store local audit logs. The recommended number of days for centralized audit log services is at least 7.

Boot Loader (Grub) Password

All VMware Hardened Appliances have the ability to protect the appliance with a password for modification of the default boot settings. To verify it’s configuration, read the /boot/grub/menu.lst file. The third line should contain:

password --md5 $1$(followed by additional characters)

 

To change or add a password for Grub, run the following procedure as root:

# grub

 

The grub shell will appear.

grub 9

Run the “md5crypt” command to create the hashed password. Once you type in a password, the hash will be presented. Copy the password. Run the “quit” command to return to the root shell.

grub md5 10

Use the vi editor as root to modify the /boot/grub/menu.lst file. Add the following to the third line of the file:

password --md5 md5hash

 

md5 hash paste 11

Paste the md5 encrypted hash to the end of the entry, and save the file.

NFS and NIS

All hardened appliances come prepackaged with the ability to serve as both a NIS and NFS client. In 2013, NIS service support is depreciated. NFS is included as a non-standard means of supporting syslog shipping. If neither of the two services are required, it is recommended that they are disabled. To disable the services in the hardened virtual appliances, run the following set of commands as root:

# chkconfig ypbind off
# chkconfg nfs off
# chkconfig rpcbind off
# service ypbind stop
# service nfs stop
# service rpcbind stop

Conclusion

Please note that all of these methods and procedures are to be carried out if you are required to do so by your local security team or regulatory compliance mandates. The documenting of these procedures does not imply a mandatory requirement to implement them by VMware. In addition to all of the things outlined in these posts, a good Defense in Depth strategy is paramount. Further defenses can be, but are not limited to,

  • Log collection – see VMware’s Log Insight tool for this! See my post on ESXi logins for examples)
  • Virtual firewalls – VMware’s VCNS product is a great solution
  • Good identity management – Know who is logging in and with logging enabled, know what they are doing
  • RBAC – Role Based Access Control. Leverage Roles and Permission at the vCenter or ESXi level
I know a lot of this is very hands on but as I said in Part 1, security is a journey, not a destination. All of these methods we discussed will make your systems more secure, but nothing will ever make you completely secure. The fact that you can now more easily meet compliance objectives with VMware Hardened Virtual Appliances is a great first step in the adoption of virtual appliances by IT and Security teams.
I hope you’ve enjoyed this series. I’ve been excited to write about it since I came to VMware in January and learned about the program. A HUGE thanks go to my VMware colleague Simon Mijolovic whose amazing content was the basis for this series of blog posts! He’s done yeoman’s work in making VMware Hardened Virtual Appliances a reality!
As always, if you have a vSphere security topic you are interested in and want me to blog about, contact me!
Thanks for reading,
mike
This entry was posted in Security, vSphere and tagged on by .
Mike Foley

About Mike Foley

Mike Foley is a Senior Technical Marketing Manager at VMware. His primary focus is on security of the core platform (vSphere). He is the current keeper of the vSphere Hardening Guide. His primary goal is to help IT/VI Admins build more secure platforms that stand up to scrutiny from security teams. Previously, Mike was on the evangelist team at RSA where he concentrated on virtualization and cloud security and contributed as a member of the product architect team. Mike has a blog at http://yelof.com and contributes to the VMware vSphere and Security blogs as well. Follow him at @vSphereSecurity on Twitter

4 thoughts on “Virtual Appliances getting more secure with vSphere 5.5 – Part 4

  1. Pingback: Jase's Place » VMware vCSA 5.5 – Ready for Prime-time & the War Fighter

  2. Pingback: Welcome to vSphere-land! » vSphere 5.5 Link-O-Rama

  3. Don Gray

    Its good to see that VMware is getting serious on security policies, but all of this is meaning less if I cant patch the OS.

    Currently vcsa 5.5.0.5101-1398493 has 13 Security vulnerabilities according to nessus and there are no updates available on vmware.com

    How am I going to explain this to a DISA auditor?

    Reply
  4. induction portable cooktop canada

    Great goods from you, man. I have understand your stuff previous to and you’re just too magnificent.
    I actually like what you have acquired here, certainly like what you’re stating and the way
    in which you say it. You make it enjoyable and you still care for to keep it
    smart. I cant wait to read much more from you. This is really
    a tremendous web site.

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>