Sunday, February 8, 2009

Antivirus on Servers

Many consider having antivirus on servers to be a fundamental of security. Although, having it on the desktop is a must, some have claimed that it isnt that important now for servers. This is true in a sense that if you are up to date with you patching, administrators access is limited and used only when required (means no browsing to the web!) and have a proper firewall and network setup. This would basically negate the need for AV products which are playing catchup to new threats anyways. On top of that, there could be a lot of head aches associated with installing AV on servers due to compatibility issues.

Having said that, I think that although the previous trends of large scale virus attacks have definitely decreased the value of having an AV solution. It still adds value by providing another line of defense. Moreover, most AV companies tend to lincese their product based on the size of the organisation and if an AV product is being used on the desktops you can add that protection at no extra cost. Recently I had worked on coming up with a set of broad guidelines for deploying AV on servers. I have edited the main policy features to reporoduce it below so that you can find it helpful it developing your own AV policy for servers.


1. Implement strict client deployment procedures to avoid service disruption
Installing AV on servers should be done in conjunction with the server management teams for the particular systems. To improve performance and stability care must be taken to exclude files that are under heavy utilizations such as DB files, transaction logs e.t.c. These are based on MS or other vendor recommendations such as recommended directories and files to be excluded on Exchange AD and Database servers. It is imperative that these should be followed carefully to prevent any service disruption. A detailed exclusion list based on Server roles is provided in the Appendix.

2. Enable real-time scanning
Real-time scanning ensures that any viruses are detected and treated as soon as possible. Not having a real-time scanning policy in place defeats the purpose of having AV. However, depending on the AV product selected, real-time scanning might result in a performance hit. Disabling scanning on read access should be used to reduce performance impact.

3. Disable extra AV services
Any features like FW services or Endpoint Security should be disabled. These are useful for home users but on a corporate server environment, it introduces extra complexity. Any firewalling should be done by firewall appliances and the AV product should be used to provide only Anti-virus protection

4. Disaster Recovery of AV management server to be based on VM
A single VM server should be used as a management server. In a disaster situation, the VM management server can be migrated to BRS where it can continue to provide management services without any service disruption.

5. Use automatic update of AV signature and have a rollback plan
Automatic updates of AV components and signatures should be enabled. A rollback plan should be in place if an unstable update is released.

6. Scanning should be implemented on Write access Only
Virus scanning should be implemented on write access only. This will improve performance as any files that are read from the servers will not be scanned by the AV engine. This is appropriate as the possibility of getting infected when files are read from the server is minimal. By disabling virus scanning on read we can improve server performance while not compromising AV protection.

7. Use a Clean/Quarantine policy
The default action should be Clean/Quarantine. This is in case of a false positive we do not want any files being deleted from the system. The Clean/Quarantine policy will first attempt to clean the infection and if that is not possible, it will quarantine the file. If the false positive is confirmed, then the file can be added as exclusion and replaced onto the server. Using this approach will help minimise the chances of deleting files that may result in system failure

8. Have an appropriate scheduled scan policy in place.
A scheduled scan should be run on servers once a day possibly out of business hours. This is similar to the current policy on Desktops. However, care must be taken to schedule scans in a distributed fashion. Particularly as VM servers residing on the SAN can experience performance issues if all virtual images run scheduled scans at the same time.

No comments: