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); };

1 2	#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); };

1 2	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

1	# 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

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

remote_server = 10.10.10.10

port = 60

transport = tcp

Restart the service as root to incorporate the change:

# service auditd restart

1	# 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

1	active = no

to:

active=yes

1	active=yes

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

Restart the service as root to incorporate the change:

# service auditd restart

1	# 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)

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

Restart the service as root to incorporate the change:

# service auditd restart

1	# 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)

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

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

# grub

# grub

The grub shell will appear.

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.

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

1	password --md5 md5hash

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

# 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