Welcome to Kraft Kennedy

Move over H1N1; recent months have seen an uptick in a particularly sinister breed of virus, commonly called scareware.

This form of malware disguises itself to appear as though it is an anti-virus or anti-spyware program, when, in fact, it is exactly what it claims to prevent. Often, the rogue software will appear as a red shield in the system tray very similar to the yellow windows update icon, or in a web browser window designed to look just like Symantec or a similar anti-virus program interface. It will alarm the user that the computer has already been affected with spyware or malware, and urge them to click to scan the computer or clean the viruses off the hard drive. Of course, this will only download further malware, or require the user to purchase a registration key and refuse to remove the infection until that is done.

Continue reading…

Installing the VMware Tools package inside a VMware virtual machine improves overall performance and allows the use of advanced features and faster virtual hardware drivers.  The installation package also installs a tray icon that controls guest access to virtual hardware, time synchronization, etc.  Since most virtual machines are servers and end users don’t typically access the console of a server, worries about the security implications of leaving that tray application running have been fairly minimal.  However, as firms move towards solutions like virtualized XenApp servers or virtual desktops, this becomes more of a concern.

Removing administrator access to end users is unfortunately not enough.  For example, a user can open the VMware Tools tray icon and select the Devices tab, and from there can uncheck “NIC1″ and click Apply.  What happens?  You guessed it – the virtual NIC is disconnected and the user loses connection.  That’s bad in a virtual desktop environment since it will orphan the desktop and likely require a connection broker like XenDesktop to create another desktop but it is even worse on a XenApp server where the user potentially just disconnected dozens of other users as well.

This, and several other things found in the VMware Tools, can be dangerous to leave available to an end user even if they have no rights to the server itself.  To get around this, there are two approaches that make sense:

1) Remove access to the VMware Tools for end users.

2) Modify the VMX configuration file to prevent these actions.

I prefer the second method since it allows for more granular control over security, though if you’re interested in option one then you can read VMware’s KB article on the subject.  In order to prevent this at the VMX (virtual machine configuration file) level, simply add the following lines to the virtual machine(s) that you wish to protect (after powering it down):

isolation.device.connectable.disable = “true”
isolation.device.edit.disable = “true”

To see how to add one of these values to the VMX file via PowerShell and PowerCLI, it would look something like this:

$vm = Get-View (Get-VM NameofVM).ID
$vmConfigSpec = New-Object VMware.Vim.VirtualMachineConfigSpec
$vmConfigSpec.extraconfig += New-Object VMware.Vim.optionvalue
$vmConfigSpec.extraconfig[0].Key=”isolation.device.connectable.disable”
$vmConfigSpec.extraconfig[0].Value=”true”
$vm.ReconfigVM($vmConfigSpec)

There are many other security parameters that can be set in the VMX file that are covered in VMware’s Security Hardening document (PDF).  The document covers this and many other common security best practices for virtual machines.  As always, test any change you make (especially the script above) before putting anything into production.

We often come across instances where firms are using NTLM Authentication (Windows integrated authentication) for SharePoint, and expect that Internet Explorer will automatically pass through the authentication from machines within the company, however they still get prompted for credentials.  This issue exists with any IIS website, not just SharePoint, but seems to come up more frequently with SharePoint sites.

The solution revolves around checking the security zones in Internet Explorer, and ensuring that the SharePoint site is included in a zone that will pass through the authentication.  Adding the site to “Trusted Sites” is often the first thought, however that does not work by itself, because “Trusted Sites” only pass the username, not the password, by default in Internet Explorer 7+.  The better choice is to put the SharePoint site in the “Local Intranet” zone, as that’s the only zone which passes both the username and password by default.  If “Trusted Sites” is used, an additional step is necessary beacuse you have to change the custom settings, find user authentication, and check the box to do an “automatic logon with current username and password.”

In order to add your SharePoint site into the “Local Intranet” zone, click Tools –> Internet Options in Internet Explorer.  Then click Security –> Local Intranet –> Sites.  Click “Advanced,” enter the URL of the SharePoint site, and click “Add.”  You’ll notice that the zone name listed in the lower-right corner of the browser changes from “Internet” to “Local Intranet,” and you won’t be prompted for credentials anymore.  Note that this type of pass through authentication is only supported by Internet Explorer, and requires that the computer be inside the corporate network.

When managing a VMware ESX host, most functions can be done via the VI Client. The VI Client offers an easy to use GUI interface for management and configuration of one or multiple ESX hosts. That said, there are times when connecting to the Service Console of the ESX host is required. Often times multiple administrators will login to the Service Console as the root (highest level access) user, making it difficult to know which administrator performed any task.

It is not recommended that all administrators connect to the ESX host as the root user. Further, as a security best practice connecting to the ESX host via SSH as the root user is restricted by default.

With these restrictions and best practices, how should Service Console access be managed on ESX hosts? In truth, ESX hosts are like all other servers and best practices for security and auditing should be followed – that is, all administrators that have to login to the ESX host should do so with their own account.

For administrators, managing multiple logins for different systems can be difficult and can lead to the use of weak or common passwords. To get around this issue with VMware ESX, administrators can enable Active Directory authentication which allows them to login with their domain credentials instead of a local Linux account.

The following steps must be completed on each ESX host in the environment in order to enable AD authentication:

Configure Active Directory Authentication on ESX

1. Connect to the ESX host as the root user. Issue the following command:

   esxcfg-auth –enablead –addmoain=ActiveDirectoryDomain –addc=FQDN.of.domain.controller
   

   For example, configuring AD authentication for Kraft Kennedy’s Research domain research.kraftkennedy.com with a domain controller named nyrdc01.research.kraftkennedy.com would look like the following:

   esxcfg-auth –enablead –addomain=research.kraftkennedy.com –addc=nyrdc01.research.kraftkennedy.com
   

   Additional domain controllers can be added via additional –addc command and should be done to provide some redundancy.

2. Create Linux accounts for each administrator that needs to connect to the ESX Service Console

   Useradd username
   

   To add the “admin.liebowitz” account to the ESX host, the command would be:

   useradd admin.liebowitz
   

   As administrators leave the organization, their accounts can be removed with the following command:

   userdel username
   

3. Once authenticated, if additional access is required the administrator can issue the following command to elevate to root level access:

   su -
   

Once the above steps have been completed, administrators can login to the ESX host via SSH using their AD credentials. This allows organizations to maintain best practices by restricting root level SSH access as well as makes it easier to see which administrators have logged into a particular server.