InstantForum.NET v4.1.4SQLServerCentralhttp://www.sqlservercentral.com/Forums/notifications@sqlservercentral.comTue, 16 Mar 2010 18:11:04 GMT20http://www.sqlservercentral.com/Forums/Topic652308-263-1.aspxSounds a lot like genetics. The "Pure Breeds" are often far more susceptible to health problems whereas the mongrel will be healthy for decades :)Wed, 11 Feb 2009 14:33:24 GMTDavid in .AUhttp://www.sqlservercentral.com/Forums/Topic652308-263-1.aspxI agree. We standardized a lot of stuff at JD Edwards, but when Oracle came in, they let things go wilder, almost chaotic, but it did result in interesting security issues. Things couldn't propogate as easily since platforms were mixed, and there were different virii or worms caught be different products.Wed, 11 Feb 2009 09:39:49 GMTSteve Jones - Editorhttp://www.sqlservercentral.com/Forums/Topic652308-263-1.aspx[quote][b]Derek Dongray (2/11/2009)[/b][hr][quote][b]David B (2/10/2009)[/b][hr]in a standard corporate network all AV's will probably be the same brand and version and so if the workstation AV cant stop it, neither will the server's version.[/quote]A company I worked at, for historical reasons, had different AV software in the US and in Europe. After discussion, it was decided to keep it that way, partly so that we had the additional cover if one manufacturer could detect something the other didn't.We also installed the Exchange specific AV add-ons for those servers to check mail messages.[/quote]We did that when I was in the USAF. My organization, though it was attached to a particular HQ unit, actually reported to the HQ unit above that. So we have some leeway in what we did as far as managing our own systems. We ran a different AV suite. Sure enough, our AV suite flagged a Word macro virus the rest of the base was infected with that its AV suite wasn't detecting. So we stayed clean and was able to alert said unit so they could take corrective actions.Wed, 11 Feb 2009 07:11:22 GMTK. Brian Kelleyhttp://www.sqlservercentral.com/Forums/Topic652308-263-1.aspx[quote][b]AndyD (2/11/2009)[/b][hr]Just a brief note to say that if your MS SQL Server is "behind the firewall", then it is not safe. Any organisation that has a single firewall between the evil internet and the safe-and-cuddly LAN is bound to failure and will suffer exploits.However, if your SQL Server is on a segmented part of the network (eg. virtual LAN), behind its OWN firewall, then it could be safe.Andy[/quote]My contention is that even in those cases, there are too many ports that remain open which can be exploited. For instance, most remote administration access involves RPC. Turn that off and folks are going to the box or to a IP-based KVM to administer. And in those cases, forget about any kind of automated tasks across multiple systems. Wed, 11 Feb 2009 07:08:35 GMTK. Brian Kelleyhttp://www.sqlservercentral.com/Forums/Topic652308-263-1.aspx[quote][b]Michael Demmitt (2/10/2009)[/b][hr]The server ops team where I work set up AV software on our SQL boxes and left them to the default settings. Unfortunately, we found out the hard way the AV software was causing our clusters to fail. A call to MS PSS revealed when the AV software scans the folder where the cluster logs reside the cluster fails. We excluded this drive from scanning and I excluded database files(mdf, ndf, ldf, bak, trn) and now all seems well for 1 week anyway. Also, watch out for DiskKeeper, defrag can ruin your cluster's day.[/quote]Anything which could cause contention on the Quorum is a big no-no, so yeah, AV and defrag should be avoided. This is also the reason Microsoft moved the recommendation for MS DTC off the Quorum when it came to Windows Server 2003 clusters. If you ran comclust.exe in Windows 2000 clusters, it put MS DTC in the cluster group containing the Quorum drive, meaning DTC would use it. They had come across customers where heavy DTC activity caused the disk contention and subsequently the cluster to drop.Wed, 11 Feb 2009 07:05:24 GMTK. Brian Kelleyhttp://www.sqlservercentral.com/Forums/Topic652308-263-1.aspx[quote][b]David B (2/10/2009)[/b][hr]in a standard corporate network all AV's will probably be the same brand and version and so if the workstation AV cant stop it, neither will the server's version.[/quote]A company I worked at, for historical reasons, had different AV software in the US and in Europe. After discussion, it was decided to keep it that way, partly so that we had the additional cover if one manufacturer could detect something the other didn't.We also installed the Exchange specific AV add-ons for those servers to check mail messages.Wed, 11 Feb 2009 06:11:02 GMTDerek Dongrayhttp://www.sqlservercentral.com/Forums/Topic652308-263-1.aspxJust a brief note to say that if your MS SQL Server is "behind the firewall", then it is not safe. Any organisation that has a single firewall between the evil internet and the safe-and-cuddly LAN is bound to failure and will suffer exploits.However, if your SQL Server is on a segmented part of the network (eg. virtual LAN), behind its OWN firewall, then it could be safe.AndyWed, 11 Feb 2009 03:00:27 GMTAndyD_is_not_a_numberhttp://www.sqlservercentral.com/Forums/Topic652308-263-1.aspxGood to know I shouldn't scan clustered servers.I think SQL and Exchange can be finicky. Exchange has some scanners built in for content, but I think I'd be happy to protect all other servers and clients, leave SQL out of the AV loops.Tue, 10 Feb 2009 22:31:52 GMTSteve Jones - Editorhttp://www.sqlservercentral.com/Forums/Topic652308-263-1.aspxThe server ops team where I work set up AV software on our SQL boxes and left them to the default settings. Unfortunately, we found out the hard way the AV software was causing our clusters to fail. A call to MS PSS revealed when the AV software scans the folder where the cluster logs reside the cluster fails. We excluded this drive from scanning and I excluded database files(mdf, ndf, ldf, bak, trn) and now all seems well for 1 week anyway. Also, watch out for DiskKeeper, defrag can ruin your cluster's day.Tue, 10 Feb 2009 17:37:47 GMTMichael Demmitthttp://www.sqlservercentral.com/Forums/Topic652308-263-1.aspx[quote][b]K. Brian Kelley (2/10/2009)[/b][hrFrom a security perspective, we've come to the point where we don't assume that because you're behind a firewall, you're okay. Nimda, Welchia, and now Conficker have all shown that to be a false premise. All it takes is a single machine that's infected and if you don't have protection against the vunerability (or vulnerabilities) said worm exploits, it'll spread. And sooner or later a system that connects to a SQL Server (such as a domain controller) will get hit. In fact, if you think about it, you're probably only talking about 2 hops...[/quote]Quite true, even with deep packet inspection something could indeed slip through, although one would hope that every other machine on the network does have AV running (I am not going to assume that of course, but one can hope :) ) and so the virus should be caught there and as such it still can't get to that internal server and in a standard corporate network all AV's will probably be the same brand and version and so if the workstation AV cant stop it, neither will the server's version.What I don't know (I'm not the server guy here so am a little out of touch) is whether there exists an AV program specifically designed for high IO servers (such as SQL), if there are, what would people in the know suggest? If not, AV creators, please feel free to do so :)Tue, 10 Feb 2009 15:17:23 GMTDavid in .AUhttp://www.sqlservercentral.com/Forums/Topic652308-263-1.aspx[quote][b]Jack Corbett (2/10/2009)[/b][hr]We are not currently running AV on our SQL Servers. This is something I have typically left up to the Network/System Admins with the caveat that, if AV is running, we exclude the proper paths and file types.Of course, as Brian has mentioned there are viruses/malware that can get to your SQL Servers even when they are behind the firewall. Even something as far back at the blaster worm that affected RPC.[/quote]Yup, include Blaster in that list. What a pain. Welchia was a variant of Blaster.Tue, 10 Feb 2009 12:25:57 GMTK. Brian Kelleyhttp://www.sqlservercentral.com/Forums/Topic652308-263-1.aspxWe are not currently running AV on our SQL Servers. This is something I have typically left up to the Network/System Admins with the caveat that, if AV is running, we exclude the proper paths and file types.Of course, as Brian has mentioned there are viruses/malware that can get to your SQL Servers even when they are behind the firewall. Even something as far back at the blaster worm that affected RPC.Tue, 10 Feb 2009 11:34:40 GMTJack Corbetthttp://www.sqlservercentral.com/Forums/Topic652308-263-1.aspx[quote][b]David B (2/9/2009)[/b][hr]I think it all depends.If your server is in a position where it is accessible to the net at large, then oh yeah, AV that bad boy, run it real time, because a scheduled task isnt going to help you if you are already comprimised. Do it even if you are firewalled, because if a virus uses a valid connection port through the firewall and then uses some unknown/unpatched buffer overflow exploit, well you are just as screwed.If it is sitting on an internal IP address and is only connected to via an application server or internal management client and even then only via a firewall, then it probably doesnt make much sense.and if you are an admin that directly downloads random executables and runs them on your production SQL (or any) server without having scanned them, well, you get what you deserve.[/quote]From a security perspective, we've come to the point where we don't assume that because you're behind a firewall, you're okay. Nimda, Welchia, and now Conficker have all shown that to be a false premise. All it takes is a single machine that's infected and if you don't have protection against the vunerability (or vulnerabilities) said worm exploits, it'll spread. And sooner or later a system that connects to a SQL Server (such as a domain controller) will get hit. In fact, if you think about it, you're probably only talking about 2 hops...Client -&gt; DC -&gt; SQL ServerAnd since these worms are exploiting from the network, it's not about being smart when you're on SQL Server. That's not the attack vector. RPC, SMB, etc., which don't require an interactive login, are.Tue, 10 Feb 2009 11:21:46 GMTK. Brian Kelleyhttp://www.sqlservercentral.com/Forums/Topic652308-263-1.aspxServers I've managed have always gone with a variation of 3(b). That is, AV is installed but settings are adjusted to minimize impact, e.g. only scan on writes to the hard disk, skip certain extensions, etc.Tue, 10 Feb 2009 03:41:51 GMTDerek Dongrayhttp://www.sqlservercentral.com/Forums/Topic652308-263-1.aspxI think it all depends.If your server is in a position where it is accessible to the net at large, then oh yeah, AV that bad boy, run it real time, because a scheduled task isnt going to help you if you are already comprimised. Do it even if you are firewalled, because if a virus uses a valid connection port through the firewall and then uses some unknown/unpatched buffer overflow exploit, well you are just as screwed.If it is sitting on an internal IP address and is only connected to via an application server or internal management client and even then only via a firewall, then it probably doesnt make much sense.and if you are an admin that directly downloads random executables and runs them on your production SQL (or any) server without having scanned them, well, you get what you deserve.Mon, 09 Feb 2009 22:28:55 GMTDavid in .AUhttp://www.sqlservercentral.com/Forums/Topic652308-263-1.aspxGiven that the last few successful virus/worm threats attacked SMB/RPC, I believe in running AV on the SQL Server, while setting the AV software not to scan the appropriate file types SQL Server cares about. For instance, Conficker attacks SMB, and therefore, if your SQL Server is on the domain and talking to DCs and other systems (even app servers) using Windows authentication, accessible to most patch management software, remote management, etc., it's going to use those protocols. If you've got a 0-day, then the AV definition may be the only thing that catches and smacks down the virus/worm. I'd rather take the small performance hit from a properly configured AV software then take the larger risk of the server compromise because someone brought in an infected USB drive, accessed the wrong site on the Internet before it could be properly categorized (especially normally legitimate sites like .edu ones which are often compromised because (a) they aren't being watched as carefully as a commercial site and (b) because of the fact that until reclassified the site is seen as legitimate by the web filtering software most organizations use), or brought in an infected laptop that was in standby or hibernation mode.Mon, 09 Feb 2009 16:36:33 GMTK. Brian Kelleyhttp://www.sqlservercentral.com/Forums/Topic652308-263-1.aspxWhen I administered SQL boxes in the past, I turned off the real-time scan on the SQL-only boxes and disabled scanning for the MSSQL/Data folder during regular nightly scans.Seemed a good trade-off for performance. Granted the SQL boxes were behind firewall and had not direct file access by regular (non-admin) clients.Mon, 09 Feb 2009 16:26:22 GMTEd Pearsonhttp://www.sqlservercentral.com/Forums/Topic652308-263-1.aspxon our own dedicated SQL servers we don't run AV. When working with external clients who already have it present on their system we recommend excluding the data/log/backup dirs.Mon, 09 Feb 2009 15:52:41 GMTkarl.spamhttp://www.sqlservercentral.com/Forums/Topic652308-263-1.aspxYour answers are all over the place, which is mostly what I expected to see. In my editorial, I avoided telling you what I have traditionally done because I didn't want to bias anyones response. I generally have gone with option "2". I leave don't run any antivirus locally, but scan rermotely once a week during maintenance periods. In addition, I harden each of the SQL Servers as much as possible. In my close to 14 years of managing SQL Servers, I have never had a virus problem yet, even when other servers in the company were having virus issues. Of course, now that I say this, one of my servers will probably get a virus.Mon, 09 Feb 2009 15:31:58 GMTBrad M. McGeheehttp://www.sqlservercentral.com/Forums/Topic652308-263-1.aspxExcellent topic and some very interesting posts.Mon, 09 Feb 2009 14:58:15 GMTD Gillespiehttp://www.sqlservercentral.com/Forums/Topic652308-263-1.aspxWe run AV on all our servers.For db servers we exclude the db file locatons as well as the location of the backup files.We recently had an issue with one (of many) SQL2000 instance which lost connectivity (unless time had been set to &gt; 20sec) after installing McAfee 8.5 (+6upd)Still looking for a valid solution .....Mon, 09 Feb 2009 14:23:00 GMTALZDBAhttp://www.sqlservercentral.com/Forums/Topic652308-263-1.aspxHuh, I always assumed that we did run AV on the server boxes. Went to check, and it appears that we don't. It doesn't alarm me, since the servers are dedicated and sit behind the firewall. Still, I can't get rid of a nagging thought - in the unlikely event that we do get a virus, it would be very difficult to explain to TPTB why it was unnecessary to scan the servers. :DMon, 09 Feb 2009 14:12:55 GMTOlga Bhttp://www.sqlservercentral.com/Forums/Topic652308-263-1.aspxI've rarely run AV on a server, except for file servers. And then mostly to prevent the spread from workstation to workstation.For SQL, we've prevented browsing from most of the servers, prevented people from actively doing things on them except with RPC, so AV hasn't made a lot of sense for us.If you do it, definitely exclude folders or extensions. You don't want to necessarily do files unless your backups are all run on the same names.Mon, 09 Feb 2009 13:52:11 GMTSteve Jones - Editorhttp://www.sqlservercentral.com/Forums/Topic652308-263-1.aspxSo 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. MichaelMon, 09 Feb 2009 09:58:06 GMTBolingerMhttp://www.sqlservercentral.com/Forums/Topic652308-263-1.aspxWe 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. :PMon, 09 Feb 2009 09:00:41 GMTJason Miller-476791http://www.sqlservercentral.com/Forums/Topic652308-263-1.aspxWe set up the normal exclusions - some by file extension, some by directory exclusion. And then do a full scan over the weekend maintenance &#119;indow.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 EMon, 09 Feb 2009 07:23:35 GMTGreg Edwards-268690http://www.sqlservercentral.com/Forums/Topic652308-263-1.aspxWe 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?Mon, 09 Feb 2009 06:59:46 GMTChris Denker-441894http://www.sqlservercentral.com/Forums/Topic652308-263-1.aspxMy 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.Mon, 09 Feb 2009 06:58:51 GMTVEBhttp://www.sqlservercentral.com/Forums/Topic652308-263-1.aspxAs 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):):):)Mon, 09 Feb 2009 06:55:59 GMTsgmunsonhttp://www.sqlservercentral.com/Forums/Topic652308-263-1.aspxIn 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.AndyMon, 09 Feb 2009 03:53:46 GMTAndyD_is_not_a_numberhttp://www.sqlservercentral.com/Forums/Topic652308-263-1.aspxWhere 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...Mon, 09 Feb 2009 01:57:15 GMTNeil Thomashttp://www.sqlservercentral.com/Forums/Topic652308-263-1.aspxYes, 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.....Sat, 07 Feb 2009 16:23:54 GMTDavid Benoithttp://www.sqlservercentral.com/Forums/Topic652308-263-1.aspxComments posted to this topic are about the item [B]<A HREF="/articles/Editorial/65764/">Guest Editorial: Do You Run Antivirus Software on Your SQL Servers?</A>[/B]Sat, 07 Feb 2009 15:31:09 GMTBrad M. McGehee