In many enterprise environments business needs for performance often trump security (Ok, more often then not). A good example of this is Exchange Administrators getting grumpy about your AV client causing too much of a performance impact on the back-end servers. Depending on the political weight and structure of your position/group, this argument usually ends in one of two ways. Either AV gets put on the box and the Exchange Admins live with the performance hit, or you live without AV on the Exchange server.
Antivirus products can also cause havoc with some products if they detect something and try to remove it. Sure, that string of text may have been similar to a virus from 1997, but the fact that your AV client decided to delete the database in which it was written, well that's a problem.
Luckily, there is a middle ground.
Most enterprise level antivirus solutions allow you to implement specific policies for groups of computers. The problem exists with knowing how and what to implement as well as when to realize that it can't solve your problem. Most software vendors provide (or will provide when asked) a list of specific files/folders to exclude that may have undesired effects on their product. An example using Exchange is provided below.
Exclude the following directories:
- %Program Files%\Exchsrvr\MDBData*.*
- %Program Files%\Exchsrvr\Mtadata*.*
- %Program Files%\Exchsrvr\Server_Name.log
- %Program Files%\Exchsrvr\Mailroot*.*
- %Program Files%\Exchsrvr\Srsdata*.*
- %System Root%\System32\Inetsrv*.*
- %Program Files%\Exchsrvr\IMCData*.*
If your AV software has a web application component, it also may be a good idea to disable monitoring on the ports that Exchange uses, especially HTTP, POP3, IMAP, and all the various secure forms of those protocols.
For more information, see the Microsoft documentation here: File-Level Antivirus Scanning on Exchange 2010 and Overview of Exchange Server 2003 and antivirus software.
Some additional rules for various server types are below.
- Exclude the install directory of the backup software
- Exclude any Backup to Disk locations if they are local to a client
- Disable On-Access scanning during backups (or disable scan on file read/open; only scan on write/execution)
- Install directory for database (Ex: C:\Program Files\Oracle)
- Database files themselves (Ex: .DB files)
- If accessed remotely, disable scanning on the port(s) that the database is accessed from
- Disable GUI loading (so each logged in user doesn't start a new process that isn't needed)
- Disable all interaction with the client (have it default to strict cleaning, no popups etc.¬†Chances are the user won't have rights/knowledge on how to deal with it anyway, and it could hang the client if it's waiting on a user to take action on a file.
Basically you want to exclude directories, files (or file extensions), and ports that get modified a lot. This will bog down the AV client's scanning and bring the system to a crawl. You'll have to look at each OS and specific applications that are running on your network (this is a good chance for some software inventory and control - no web browsing or email checking on servers), as well as the limitations and features of your specific AV client.
Keep in mind that this approach will not solve all problems and can create it's own. When creating policies keep in mind that you can't (and shouldn't) create unique policies for every host on your network, this will become quickly impossible to manage. There also is a place of diminishing returns when configuring an AV client. If you're excluding more than you are scanning for performance concerns, it might be a good idea to forget the AV and focus on network segmentation and continuous monitoring of the host.
Of corse you want to thoroughly test any implementation before taking it live.
Putting together a set of comprehensive AV policies for your organization can be an excellent step towards better network security, just don't forget the idea of a layered defense; antivirus can't solve everything!
Seth Matheson @ Port 22 Tech
If you are in the DC Metro-area and are interested in learning the theory and language of computer security, I'll be mentoring a SANS 401 GSEC: SANS Security Essentials class in June '11. Contact me or register through the SANS website.