Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 1234»»»

Guest Editorial: Do You Run Antivirus Software on Your SQL Servers? Expand / Collapse
Author
Message
Posted Saturday, February 07, 2009 3:31 PM


SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Friday, January 10, 2014 7:20 AM
Points: 175, Visits: 723
Comments posted to this topic are about the item Guest Editorial: Do You Run Antivirus Software on Your SQL Servers?

Brad M. McGehee
Microsoft SQL Server MVP
Director of DBA Education, Red Gate Software
www.bradmcgehee.com
Post #652308
Posted Saturday, February 07, 2009 4:23 PM


SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Tuesday, April 15, 2014 3:20 PM
Points: 2,105, Visits: 3,560
Yes, we run AV software on our SQL boxes. I was dead set against this for the longest time but most of the AV software folks have become intelligent about this now and allow you to eliminate scan on certain items and you can configure it so that you really don't impact your database server too much. There is always a hit which can't be avoided but we have had success doing this.

Seriously, can anyone risk being hit with a virus on the SQL Server box? Not I.....


David

@SQLTentmaker
SQL Tentmaker
“He is no fool who gives what he cannot keep to gain that which he cannot lose” - Jim Elliot
Post #652316
Posted Monday, February 09, 2009 1:57 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Thursday, January 30, 2014 8:09 AM
Points: 347, Visits: 171
Where I used to ork, we ran AV software on SQL Server boxes as well. We were able to set up scanning exclusions for specific groups of servers, but by default had the default set of exclusions, rather than the SQL set (or the IIS set). This meant we had to let the server team know the server purpose before it got put to use.

Occasionally got hit by AV updates that wanted servers rebooted(!), and then gave them the default set of exclusions...
Post #652590
Posted Monday, February 09, 2009 3:53 AM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Yesterday @ 9:55 AM
Points: 986, Visits: 1,030
In general I am against AV on a server, because the vast majority of the time it is useless. However, the very occasional time it is useful (eg. prevent a trojan jumping from server to server through your whole network) probably means that an AV engine is worthwhile.

Personally, I'd much rather the applications running on the server were configured to be secure; but that is often asking too much. If the server sits behind a firewall, and the only ports exposed are to penetration-tested applications, then an AV is pointless (and liable to cause more problems than it solves; a forced reboot is just one of them).

However, in the last few places I have worked, a "contract" is in place with the AV provider which stipulates the AV engine must be installed on every single server. No exceptions. So an AV engine on the SQL Server servers has become an inevitable pain that I have to live with.

The AV engines I have experience of, generally don't even need MDF, LDF, etc files to be excluded. They sit quietly in the background, and as long as the hardware is up to it, don't cause me many problems.

So I guess I fall into category 1.

Andy
Post #652666
Posted Monday, February 09, 2009 6:55 AM
SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Thursday, April 03, 2014 7:20 AM
Points: 1,528, Visits: 1,971
As I'm not in the corporate world at the moment, I can only speak to what I saw back when I was, and it was AV on every server, no exceptions. That company was working exclusively with Symantec's products. As I had been there for more than 20 years, my own server and my Vista machine with SQL Server on it, along with at least 2 other XP client machines, are all running Symantec EndPoint Protection, and wow, what a difference in resource usage. Back with SAV 10.1, the client SAV would take as much as 75 MEG, ALL the time, and since it wasn't looking at spyware, I had to add WebRoot SpySweeper, for another 25 meg. Now with EPP, my Vista machine uses well less than 20 meg, and my wife's XP machine is SO much faster, she can't believe it. FYI...

Steve
(aka smunson)
:):):)


Steve
(aka sgmunson)

Internet ATM Machine
Post #652772
Posted Monday, February 09, 2009 6:58 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Monday, January 10, 2011 7:58 PM
Points: 25, Visits: 184
My opinion is that while AV software is the must on a file server, it is useless on a "well-configured" SQL Server, since the treatment goes to be worse than the illness.

By "well-configured" I mean:
1. it's used only as SQL Server (no file-sharing, no IIS, etc.);
2. the SQL Services are run under least privileged accounts;
3. it's locked down by Security Configuration Wizard (to disable all unneeded services, and leave opened only needed IP ports);
4. it's patched with critical security updates just as they released.

With such a configuration there's no way for a virus to come into a system, which makes AV software useless. Alright, there're 2 "but-s":
1. there might come up a virus which exploits unknown vulnerability;
2. not every company can afford such role-targetted servers.
As for the first, while there's such a probability, Microsoft has been doing well on this front for the past moths, and as a rule, they release pathes before the vulnerability is used by virus-makers; for the worst case one could use imaging backup software to quickly restore the system - anyway it would be less expensive than an AV software in terms of purchase, deployment, maintenance, support, server workloads - all mean money. As for the second "but"... well, the way out is consolidation and virtualisation of file-, print-, web-, infra- servers to free up a well-built box(es) dedicated to SQL Server only.

P.S. A couple of years ago, I went to a seminar of a famous AV company and talked to its analysts about usage their AV software on various servers. They said, while an AV software is really the must on a file-server, it's absolutely unneeded on a domain controller and on a database server, =if= 1. these servers are strictly dedicated to their roles; 2. they are promptly patched. Since then, I followed their advice, and the time just confirmed it.
Post #652776
Posted Monday, February 09, 2009 6:59 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Friday, January 03, 2014 4:35 PM
Points: 237, Visits: 237
We have it installed and set to bypass the usual extensions and haven't had any issues. Hopefully there won't be an exploit that use .MDF extensions to sneak by AV, it's probably a matter of time.

Along a similar subject, I'd be curious to hear what other's policies are on server monitoring for SQL boxen; we have standardized on IBM Director and I have banned it on SQL servers due to many problems I've seen with resource consumption, unplanned reboots, etc. It's a little invasive to say the least. Do any others use Director for monitoring SQL hardware? Any stories to share?
Post #652779
Posted Monday, February 09, 2009 7:23 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Yesterday @ 6:20 PM
Points: 1,146, Visits: 6,244
We set up the normal exclusions - some by file extension, some by directory exclusion. And then do a full scan over the weekend maintenance window.
Seems like a common compromise.
Running default settings was a noticeable hit. Lots of I/O and CPU was being consumed, especially during nightly ETL and Cube Builds.
Greg E
Post #652802
Posted Monday, February 09, 2009 9:00 AM


SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Thursday, November 18, 2010 5:25 AM
Points: 162, Visits: 694
We have a list of files explicitly skipped. Not just file extensions. Plus a complete scan during our maintenance window on Sundays. Plus the server sits behind firewalls, closed ports, and a rather surly attack Beagle. :P




Honor Super Omnia-
Jason Miller
Post #652896
Posted Monday, February 09, 2009 9:58 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Tuesday, October 08, 2013 3:41 PM
Points: 9, Visits: 61
So far we are on the '3(b)' option (Other DBAs leave the AV software on their SQL Servers, but change the default settings so that the scans exclude .mdf, .ldf, .ndf, .bak, .trn, full-text catalog files, and any folders that include Analysis Services data).

My remaining decision is to do a full weekly after hours scan of the entire server and SAN drives or not. Or do we just weekly scan for the file types that are excluded in real time? Will SQL Server 2005 Enterprise have trouble with an after hours scan that it would not have had with real time? We are using McAfee.

Michael
Post #652978
« Prev Topic | Next Topic »

Add to briefcase 1234»»»

Permissions Expand / Collapse