February 9, 2009 at 3:52 pm
on 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.
February 9, 2009 at 4:26 pm
When 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.
February 9, 2009 at 4:36 pm
Given 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.
K. Brian Kelley
@kbriankelley
February 9, 2009 at 10:28 pm
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.
February 10, 2009 at 3:41 am
Servers 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.
Derek
February 10, 2009 at 11:21 am
David B (2/9/2009)
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.
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 -> DC -> SQL Server
And 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.
K. Brian Kelley
@kbriankelley
February 10, 2009 at 11:34 am
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.
Jack Corbett
Consultant - Straight Path Solutions
Check out these links on how to get faster and more accurate answers:
Forum Etiquette: How to post data/code on a forum to get the best help
Need an Answer? Actually, No ... You Need a Question
February 10, 2009 at 12:25 pm
Jack Corbett (2/10/2009)
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.
Yup, include Blaster in that list. What a pain. Welchia was a variant of Blaster.
K. Brian Kelley
@kbriankelley
February 10, 2009 at 3:17 pm
K. Brian Kelley (2/10/2009)[hr
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...
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 🙂
February 10, 2009 at 5:37 pm
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.
February 10, 2009 at 10:31 pm
Good 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.
February 11, 2009 at 3:00 am
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
February 11, 2009 at 6:11 am
David B (2/10/2009)
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.
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.
Derek
February 11, 2009 at 7:05 am
Michael Demmitt (2/10/2009)
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.
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.
K. Brian Kelley
@kbriankelley
February 11, 2009 at 7:08 am
AndyD (2/11/2009)
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
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.
K. Brian Kelley
@kbriankelley
Viewing 15 posts - 16 through 30 (of 33 total)
You must be logged in to reply to this topic. Login to reply