Virtualization Pro:

Tripwire

Apr 15 2009   7:01PM GMT

Must-have VMware infrastructure plug-ins



Posted by: Edward L. Haletky
Edward L. Haletky, Texiwill, H9Labs, Hyper9, Tripwire, VMware, VI Plugins, Hytrust, Wishlist

There are quite a few VMware plug-ins out there, but which would you really use on a regular basis? Here is a simple guide to the plug-ins I use and why I would not use some of the others.

Must haves:

  • VMware Update Manager (part of VMware vCenter Server)
  • Storage VMotion plug-in. This plug-in was created by Andrew Kutz who now works for Hyper9 and works on the H9Labs.com projects.
  • H9Labs Hyper9 VI Client plug-in Also from Andrew Kutz. It allows me to do simple searches within the infrastructure and hooks in to Hyper9 if you have it. Continued »

Mar 23 2009   3:39PM GMT

My virtualization toolbox



Posted by: Edward L. Haletky
Edward L. Haletky, VMware Toolbox, VMware, Tools, Tripwire, Veeam, Vizioncore, ESX, ESXi

What comprises a VMware vExpert’s virtualization toolbox? I actually think there are several different layers of tools depending on the particular VMware virtualization administrators job role. Mine, for example, has a number of security tools that most people would not normally need, but I do. So below is a list of what comprises my virtualization toolbox.

Administration Tools

  • VMware’s VI Toolkit w/Microsoft PowerShell
  • VMware’s VI Perl Toolkit
  • VMware’s Remote CLI
  • VMware Update Manager Plug-in for VMware Infrastructure Client
  • Andrew Kutz’s Storage VMotion VMware Infrastructure Client Plug-in
  • Hyper9’s Search Toolbar VMware Infrastructure Client Plug-in
  • Tripwire Opscheck (a must for solving VMware VMotion issues)
  • PuTTY (a must for accessing host via secure shell (SSH) from Window’s systems)
  • PowerGUI (GUI for PowerShell and VI Toolkit)
  • Snaphunter (hunt for and destroy snapshots)
  • Snapalert (find and commit snapshots with Remote CLI support)
  • Adobe Acrobat (for reading VMware whitepapers, hardware compatibility lists and other documents)
  • Twhirl (for Twitter access)
  • Firefox for access to the VMware Communities Forums and Google Search

Performance/Monitoring Tools

  • VMware Infrastructure Client for real time performance graphs
  • VMware’s esxtop for details on server utilization
  • vmktree
  • Vizioncore’s vFoglight
  • Nagios for service monitoring

Reporting

Backup Tools

  • VMware Consolidated Backup
  • VMware Converter
  • If only ESX, then one of either Vizioncore vRangerPro, PHD Technologies’ esXpress, or Veeam Backup
  • If only ESXi, then Veeam Backup 3.0
  • VMware’s vcbMounter

P2V Tools

  • VMware Capacity Planner
  • VMware Converter 4.0

Security Tools

  • Ultimate Boot CD for Darik’s Boot and Nuke utility (in ISO form)
  • Tripwire ConfigCheck
  • My own Virtual Security Management Suite (still in pre-beta with a hope to get it out soon!)
  • Hardening Script from VMware Virtual Infrastructure Security: Securing ESX and the Virtual Environment, available first half of 2009.
  • DISA STIG for ESX SRR
  • Nessus
  • Nmap
  • Backtrack for Penetration Testing (in ISO form)
  • Helix for Forensics (in ISO form)
  • Nuclues Kernel Linux for Data Recovery
  • Virtual Firewall (smoothwall, IPcop, etc.)

General Tool

There you have it: the contents of my virtualization toolbox. I am sure there are many more that I have missed as I do not use them very much or have never used them. Which of these tools will prove to be the most useful in the future? I believe it will be the VI Toolkit but I will keep all these tools within the toolbox, cleaned, and ready for use.

Editor’s note: Readers, any suggestions for other helpful tools? Comment and add to the list.


Feb 5 2009   7:59PM GMT

New VMware ESX v3.5 U3 vulnerabilities



Posted by: Edward L. Haletky
Edward L. Haletky, Texiwill, Virtualization security, VMware ESX Security, VMware, DISA, CISecurity, ESX, Tripwire, ConfigCheck

There is a new vulnerability in VMware ESX v3.5 U3 with all the patches that has just come to light. VMware has been made aware of this issue, and will fix it sometime in the near future. This bug relates to world writable directories on the VMware ESX service console.

This is not a huge issue as long as your VMware ESX service console is properly protected, but you may want to be concerned if it is not. The vulnerability allows any one who can access the VMware ESX host to write anything to these directories and could cause a disk to fill up or something worse to happen.  The remediation is quite simple.

chmod 755 /var/lib/pegasus /var/lib/pegasus/trace

This is a simple oversight that could lead to something possibly dangerous. However it is also easily made right. This is one of the reasons that is you are using a security assessment script that you run after every patch or update.

The other issue is more a historical item that could lead to a possible security issue if a malicious user does have access to the service console once more. This is the ability to run code as root possibly within the hypervisor using the vmkload_app and vmware-vmx commands. These programs are set up with their setuid bits which allows a normal user to run these as the super user. The reason these are set up this way is more an issue of history.

In VMware ESX 2.5.x days, it was possible for a normal user to run VMs. With VMware ESX v3.x this functionality was dropped from any of the management tools, yet the capability was left in. The solution is to remove the setuid bits so that these commands can only be run as the root user, which is their normal method of operation.

chmod u-s /usr/sbin/vmware-authd /usr/lib/vmware/{bin,bin-debug}/{vmkload_app,vmware-vmx}

It is interesting that while the DISA UNIX STIG and CISecurity CIS-CAT for RHEL found these issues, the TripWire ConfigCheck tool did not. This inconsistency has been reported to Tripwire as well, and they will work with VMware for a possible VMware Hardening Guide modification. TripWire ConfigCheck goes so far as to warn you that these files have had their setuid bits removed, when it should check to see if they are missing. It is a contradiction.

Making these changes will add to your security stance but not harden your system 100%. In my case, I never trust just one hardening guide as they often over look things that the others do not. I try to make my systems pass all the guidelines available and if there are inconsistencies between them, I document those decisions as well. Note that there are several inconsistencies in each guide.

These slight changes are also reasons you want to redo security assessments after you patch or update your VMware ESX hosts!