When it comes to patching and updating ESX and ESXi hosts and VMs, solution providers have several options. Remote and local command line utilities are used to update hosts and VMs, and standalone applications, such as the vSphere Host Update Utility and vCenter Update Manager, are also helpful.
While command line utilities are just as effective as standalone applications, many customers prefer to use application clients for hosting and patching. Using command line utilities can be tedious, and solution providers must know proper syntaxes to use them properly. On the other hand, application clients are easier to use and have more features, such as the ability to schedule when updates are applied.
Read the full article at searchsystemschannel.com…
Early Sunday morning I was alerted by a tweet DM from @terrafx that the vLaunchpad website was hacked and was displaying a turkish hacker page. The vLaunchpad is one of 5 web sites that I have hosted with godaddy.com, this one is on their Linux grid computing platform (cloud). I quickly checked the site and everything looked OK to me so I investigated further. I started browsing the web server and found a suspicious file in the root directory called x.txt. After downloading it to my PC and opening it I found the following HTML code:
Obviously this was a malicious file that was displaying the page that people were seeing after the hack occurred. I wasn’t sure what all happened so I started looking at date/time stamps to see if any other files were altered and also checking through some of the key wordpress php files. Seeing nothing else malicious I contacted godaddy that didn’t know anything about it. So I investigated further and found a nifty tool inside their web-based control center that allows you to interact with all the files on the website. There is a history button in their web based file manager that lets you go back to scheduled snapshots that occur automatically on the website. Once you pick a date it shows you any files that have changed, been added or deleted from the current file listing. I picked the date of the attack and here’s what I saw:
The listing showed 4 files deleted and one file modified, so obviously something happened. This capability is pretty cool because if a hack occurs you can see exactly what files have been changed. I really didn’t find out much else besides that but I wanted to know how the hack occured, there really was only 3 reasons that I could think of, a compromised password (wordpress or ftp), wordpress vulnerability or a web server vulnerability. Two were within my control, I had pretty strong wordpress/ftp passwords so I didn’t think that was the cause and my wordpress version was fairly update to date. The web server was beyond my control as it is godaddy’s responsibility. I wanted to eliminate ftp as a cause so I asked godaddy for the ftp logs for the last few days. Once I got those I saw nothing but my IP address in them after the hack occurred so I was back to either Wordpress or the web server being the cause. I pushed godaddy for more information, basically blaming the web server for the attack and I finally got an answer from them:
Apparently using compromised SSH accounts (you can enable SSH on godaddy websites) and exploiting a vulnerability in the GNU C Library that is part of Linux operating systems, an attacker was able to execute and upload code to many customers websites that were running on the server, mine happened to be one of them. So it looks like what happened is that after godaddy was alerted to the hack, they went in and cleaned everything up on their own without involving their customers which would explain why everything looked normal when I check the website after I was alerted. It looks like they restored the original files, renamed the malicious file to x.txt and deleted the extra files that were put on the web server. If I hadn’t been alerted about it I probably would of never known the hack occurred. Thanks to godaddy’s quick response the hack was quickly identified and fixed.
The hack did serve as a wake up call though and if you have a wordpress blog make sure you do frequent backups, especially of the database. I kick off the database backup from the godaddy control panel than ftp all wordpress files including the db backup file to my local PC. There are also plugins that you can use to help automate this. There are also a variety of security plugins that you can install on your wordpress site. Here’s a few good links to dealing with a wordpress hack and how to better secure your wordpress website.