Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 

K. Brian Kelley - Databases, Infrastructure, and Security

IT Security, MySQL, Perl, SQL Server, and Windows technologies.

Updated Thoughts on Antivirus on SQL Servers

Baby bodyguard

I hate running antivirus on SQL Servers. I agree antivirus is a necessary evil on most systems, but I don't like running standard antivirus on Exchange, SQL Server, or Active Directory domain controllers. My SharePoint admin friends have made good arguments to avoid it there, too. But a lot of corporate policies say you have to have it. Fine, if that's the case, here are the exclusions I would ensure are enforced:

 

  • Any .mdf files
  • Any .ndf files
  • Any .ldf files
  • Any .bak files (if you use this as a backup extension)
  • Any .trn files (if you use this as a backup extension)
  • Any .sqb (SQL Backup) or other third party extensions for backup files
  • Any .ckp files (used to be able to restart a restore if a failure occurs)
  • Any directories tied to FILESTREAM
  • Any directories tied to full text
  • Any .log files

 

Any others folks can think of?

 

As to my preferences, I would rather an external scan be conducted against the drives of the SQL Server, which is possible in most enterprise antivirus products. This keeps the AV load off the SQL Server and keeps AV from filtering at both the disk and network interfaces.

 

Comments

Posted by Brent Ozar on 24 April 2012

Trace files is another one I've seen excluded.

Posted by K. Brian Kelley on 24 April 2012

Good one, Brent, even if we're not running a trace, if default trace is on...

Posted by mrdenny on 24 April 2012

FileStream and now FILETABLE are things that I would actually want scanned.  Not cleaned, but scanned and reported on.  These are files that client computers will be opening and if these files are infected that could unleash something against the entire company network.

Think of a situation where files are uploaded from customers on the internet and are stored using FileStream on the SQL Server.  We sure can't trust that the files were clean from the Internet user so we've not potentially got a file sitting on a SQL Server, which isn't going to be scanned just waiting for someone to open that file and unleash what ever hell is stored within that file.

Posted by K. Brian Kelley on 24 April 2012

Denny, blocking FileStream was actually a recommendation I heard from Paul Randal last spring (2011) at Connections. In the scenario you've given, there are tools designed to scan the files in flight, so that's where I'd do it. For instance, there is Forefront for SharePoint for this very purpose with respect to SharePoint farms. We also do this with ForeFront for Exchange.

Posted by GilaMonster on 25 April 2012

I'd exclude errorlog as well. Just the current one.

Posted by F. Dwarf on 30 April 2012

How about directories tied to Replication?

Posted by rudy - Doctor "X" on 30 April 2012

errorlog & SQLAgent.out !!!

possibly even FTDATA where appropriate.

Posted by kent.mcconnell on 30 April 2012

I've always had the opposite thought. SQL, Exchange, and AD are your most critical servers if they are compromised you have just lost the keys to the kingdom. You can have the most secure environment possible and still get a virus. You can have SQL configured with a minimal exposure and still get compromised by the underlying OS. With the proper exclusions or the proper SQL (Exchange, AD) aware antivirus solution the performance impact can be minimal to none at least in my experience. What seems to cause a bigger performance impact to me is improper indexing or poor query design.

Microsoft has kb articles out there on what files/directories to exclude with antivurs for a variety of servers, including SQL, Exchange, and AD. support.microsoft.com/.../943556

Leave a Comment

Please register or log in to leave a comment.