Best Practice for running Sophos on virtual systems

  • Article ID: 110507
  • Rating:
  • 11 customers rated this article 1.9 out of 6
  • Updated: 25 Nov 2013

Sophos Endpoint Security and Control software has supported virtualization for a few years. Over this time, we've amassed the following practical information about how you can optimize our software to work with this technology. The advice is grouped into three main themes: deployment, provisioning dynamic machines and scheduled scans.

Applies to the following Sophos product(s) and version(s)

Sophos Anti-Virus for Windows 2000+
Enterprise Console 4.0.0

For information on supported software and availability of technical support, see the following:

1. Deployment

A common challenge of protecting virtual machines is ensuring that they have current protection. Virtual machines tend to be created dynamically from template images, but the anti-virus software included in the Gold image is obsolete within a few months of its creation. So how can you ensure that the latest software is loaded into the new machine? Here are four ways that you can prepare virtual machines for deployment that will overcome this challenge.

  1. Embedding a deployment task into the virtual machine.

    You can embed an agent deployment task into a virtual machine using a script. This will ensure that when the machine is brought online the latest version of Endpoint Security and Control (Sophos Anti-Virus) is deployed from a network-based central installation directory, which is kept up-to-date by Enterprise Console.

    To embed a startup script in the machine image, you will need to configure a start up task (using Active Directory for example) and then call the Sophos setup application with arguments appropriate for the type of machine.

    For details of how to do this in Active Directory (AD), refer to the knowledgebase article Deploying Endpoint Security and Control (Sophos Anti-Virus) through Active Directory group policy. For other methods, use Sophos Endpoint Security and Control: command line parameters used by setup.exe as your guide to the settings.

  2. Staging the system until it is ready (servers).

    Certain virtualization products like VMware vSphere allow you to stage your systems for preparation before they are put into production. You can take advantage of these staging capabilities to put servers in to a staging virtual network which isolates them from other computers until they have done their preparation workloads. This is a useful technique if you have a wide variety of preparation tasks for your servers -- though it’s somewhat overkill if you just want to deploy an anti-virus program to them.

    If you're going to stage the server before deploying it, we recommend creating a virtual network which provides access to your patching infrastructure, anti-virus updates and other such systems whilst preventing access to the network at large (some customers run a penetration test against the system whilst it is being staged to check that it can't access the outside network). This ensures that by the time the system is put into production it is appropriately up-to-date. You will need to use either technique 3 or 4 in this list to make sure the anti-virus software updates appropriately once it is put on the main network.

  3. Preparing the machine based on the older image, then triggering an update on initiation.

    If you already have a Sophos agent on your virtual machine you can trigger an update as soon as the machine comes online. This ensures that protection is updated as early as possible to minimize the risk of out-of-date clients. You can use Alupdate.exe with arguments to trigger an update, or you can use a script with ALsvc.exe. For details of how to do this, refer to the sections on ALsvc.exe and ALUpdate.exe in the 'Significant Files' section of the knowledgebase article Sophos AutoUpdate: significant files and registry entries.

  4. Embedding the software in the virtual machines and preparing them for cloning.

    The most common way to create new virtual machines is to clone them from a library or an existing working machine. If you intend to clone your virtual machines with the product installed, you will need to make some changes to the product on the disk image to ensure that correct certificates are issued to each cloned machine. This ensures that machines appear as new systems and are allocated the correct policies. For more details, refer to the knowledgebase article Sophos Anti-Virus for Windows 2000+: incorporating Sophos Anti-Virus current versions in a disk image, including for use with cloned virtual machines.

2. Managing dynamic machine provisioning

In the early days of server virtualization, most virtual machines were static - simply virtual equivalents of their physical counterparts. But as virtualization is now able to deliver high availability and resilience, it has become increasingly typical for network administrators with virtual infrastructures to create/remove machines dynamically to deal with load or user requests. A new challenge of using Enterprise Console is emerging: being able to distinguish between virtual machines and physical machines (such as laptop users) that are roaming and expected to return.

These different machines may also require different anti-virus (or other) policies, depending on their business purposes. For instance, a web server might require different protection/performance settings to a database server, or thin client.

To overcome both of these challenges, the following steps set out a simplified system to categorize your machines when you have a virtual infrastructure running alongside a physical one. These steps will help you both to identify and remove machines from Enterprise Console when they are no longer required and to assign appropriate policies to all machines on the network.

  1. Use AD groups to isolate and manage virtual machines.

    Most enterprise virtualization products enable you to place virtual machines into a specific AD group as part of their provisioning process. In most organizations, various policies are applied through AD to the virtual systems depending on their use.

    The benefit of this approach is that Sophos Enterprise Console can synchronize with Active Directory and automatically apply the correct Endpoint Security and Control policies to the systems as they are created. Furthermore, should a system be provisioned which does not have appropriate anti-virus protection, Enterprise Console can be configured to automatically deploy the software, which is a great fail safe. This feature will ensure that any dynamically created systems have the correct policies - this is particularly useful if you allow users to provision their own machines, or anytime a department outside of IT might miss this step in the provisioning workflow.

    We recommend:

    • Creating a high level container for virtual systems in AD, so they can be easily separated from physical systems.
    • Further separating your systems by type or service delivered. For example, you may have four systems dedicated to hosting your website. In Enterprise Console, you would create a group called Web Servers and apply a specific anti-virus policy to those servers. If a new web server is brought online to deal with load, it will be provisioned with the correct policy automatically.
  2. Use the deployment flag during manual installation. (For networks that don't use Active Directory or a similar network management tool)

    If you don't use Enterprise Console to protect groups of computers, you can use setup.exe with an argument to put them in a specific group to protect new systems as they are brought online. The bootstrap application can be provided with a group using the -G switch. Manual installation is further described in Endpoint Security and Control: installing software manually on networked computers. The list of parameters available for use with setup.exe can be found in Sophos Endpoint Security and Control: command line parameters used by setup.exe.
  3. Tag virtual machines with an identifier.

    You can add a tag to the description field of your cloned systems so that they are identified as virtual machines when they are reported to Enterprise Console. Then you can run a report on this attribute so that machines can be quickly identified and sorted according to whether they are virtual or physical.

    A further best practice is to tag machines according to their location in the physical virtual infrastructure - e.g. VMRackServer1. This enables easier identification of events that impact multiple virtual machines of the same class or on the same system. For example, you could classify virtual machines according to their use - e.g.a VM for storing credit card data could be managed to ensure it’s not running on a host with web servers. Read Enterprise console: changing the description of virtual machines to aid management for more details. This practice can also help you comply with various security standards, for example, in identifying systems in scope for PCI (processing in scope data).
  4. Purge old records.

    Old machines can be purged either by selecting the group in the console and smart filtering for connected status, or by using a database query along the lines of purge records where machines have been disconnected for more than ‘x’ days and where they belong to the group ‘x’ or have the description ‘X, e.g. VMRackServer1’. Read Purging old virtual machines for more details. This management task is useful in environments where virtual machines are created often to fill temporary requirements, or where users are allowed to provision their own machines. This control ensures that your Enterprise Console view is kept clean and describes the assets within your environment without muddying
3. Managing scheduled scans

Security products sometimes need to perform tasks which are CPU or disk I/O intensive. One of the best examples of this is scheduled scanning for latent malware or when you must complete a scan for clean up purposes. Scheduled scans can significantly degrade the performance of virtual machines if they are not managed appropriately. There are a number of ways to manage this impact, including using other system management tools for which you have already created policies.

  1. Use the Virtualization Scan Controller to set scan schedules for virtual machines (e.g .how many VMs to scan at a time, set scan schedule and time windows) in order to avoid overloading the physical host. Refer to the Virtualization Scan Controller: Overview, which also provides a link to the download site.
  2. Run scheduled scans at an appropriate interval depending on the exposure of the machine. Try to schedule these scans in periods of downtime for virtual machines to minimize the impact of the scan on the system. Remember to think about other critical processes such as backup so that these items do not overlap.
  3. Remember that scheduled scans on one system can impact the performance of another.
    Resources are not totally isolated in a virtual environment. For high priority systems, you can use the virtualization management tools to create separate disks hosted on different I/O backplanes. Your virtualization provider can provide more tips on disk and resource management.
  4. Scheduled scans can be initiated by a third party tool enabling you to manage the timing more appropriately. This can be useful if you already have a definition of task schedules (like backup) that are compatible with your workload. Randomization or planned offsets are frequently used approaches that can be worked into your existing processes.

 
If you need more information or guidance, then please contact technical support.

Rate this article

Very poor Excellent

Comments