The subject thread I've been following and contributing to has proved to be interesting, to say the least, and the most interesting aspects have little to do with the subject...
First off, I guess I really shouldn't be surprised how many respondants go almost immediately off-topic, without bothering to change the subject line. Bad etiquette, guys, but I guess that's to be expected.
I want to take a second or two so summarize some of the most popular responses I've seen in watching this thread, and comment on them...
There's a lot of talk about "protecting against currently unknown exploits"...and I have to ask, if it's unknown, how do you protect against it and how do you know A/V will help you? Really. One example came up of a new exploit in which the bad guy took control of the system and dropped an already-known rootkit (ie, HackerDefender, etc.) on the system...in such a case, A/V would work. Yes, and you'd be very lucky, b/c the bad guy was very stupid. If the bad guy gained such access, why would he not bother to disable or even uninstall the A/V first? Or roll back the .dat file? Or why use something that's old? If he's using a zero-day exploit, why would he then use an old rootkit?
There have been mentions of Code Red, SQL Spida, and SQL Slammer. To me, it's odd that someone would use those examples and say, "I've seen A/V come to the rescue with these viruses", when the infections could have been easily prevented in the first place with configuration settings. With Code Red, all the IIS admin had to do was disable the .ida/.idq script mappings...something not many folks used anyway. With SQL Spida, all the SQL admin had to do was put a password on the 'sa' account. Need I say it? Duh!
Another biggy is that A/V protects against the things that have been missed, the things that haven't been done. Good point, but I would suggest that perhaps the security process itself needs to revisited. If something wasn't done, why was that? Was it part of the process and the setting wasn't verified before putting the server into production? Or had it been changed? Yet again, A/V software is justified...but as a band-aid approach.
There have been respondants who are in positions where the web servers are administered by multiple folks, and perhaps even developers have admin access to the servers, for adding updates. This falls right into the same category as malware that gains SYSTEM level access...A/V isn't going to help, b/c at that point, it's GAME OVER, guys! Someone with that level of access can simply disable your A/V software.
So...am I being arrogant? I don't think so. I've managed IIS 4.0/5.0 web servers and watched the logs fill up with failed Code Red/Nimda attempts, etc. I've had NT 4.0 boxes (my own) connected to a DSL hookup with no firewall, and no A/V software...and the only time I've ever gotten a virus, worm, or rootkit on my system is when I put it there myself.
Am I saying that A/V software shouldn't be used? Not at all...I think like every tool, it has it's place. However, I do think that if a web server admin is doing their job, then it's not necessary to put A/V software on a web server. That was the original question I responded to.
3 comments:
And SQL Slammer was handled either by the security rollup that came out 6 months prior or SQL Server 2000 Service Pack 3 right before Slammer hit the net. Antivirus also didn't do anything to help stop its initial attack.
Keydet89-
Good stuff.But I'm still firmly in the AV crowd, for reasons I explained before. I'll go slightly agressive here - not to turn this into a flamefest but to provide a counterpoint.
First, I think you're creating an artificially narrow target with the 'just a webserver' line of thought. You're right, the minute it hosts a file server or an SMTP host or whatever it's not 'just a webserver'. I wonder if you would also say this Blogger host isn't 'just a webserver' once it allows people to leave feedback? My point is that today people expect much more functionality from the webserver than they did when the web was young. They want fullblown web applications, not just static HTML pages for retreival.
So - if we posit 'just a webserver' as a simple device for returning nondynamic HTML - no database, no PHP, no ASP, no CGI forms- then sure. I agree 100%. Since the only attack vector is in the URL's people send to port 80/443 of that server, there should be little need for an AV program, firewall, or other safetynet program.
Errr ... unless someone manages to find & exploit a previously unknown vulnerability at the attack surface (it's small, but it's still there). If they manage to exploit this vulnerability in such a way as to then get a virus onto your machine (or leave it open for others to do so), then you might be glad you had your 'bandaid' AV system in place.
Bringing me to my second contention - you seem to create the binary situation where an exploit is either:
-known to the AV providers and the world, therefore all admins should be able to make system changes which protect against the vulnerability without need of an AV system, or
-so new that no one knows about it yet. AV providers don't know about it so AV is no good, and admins don't know about it so they can't make system changes to protect against it.
But there /is/ a middle ground! That being the period between which the AV providers have put a 'bandaid' signature on my system to catch outbreaks, and the time I can reasonably learn about and apply the setting change/patch/whatever which would remove the vulnerability. Sometimes that period is only hours long - other times it can be days or weeks. AV companies have fulltime round-the-clock staffing. I'm one administrator, and I do have other duties. And a life!
So I admit: AV providers can respond to new situations faster than I can. I'm not ashamed to say it.
Finally I wanted to think out loud on your dismissive use of AV systems in this context as 'bandaids'. I agree that some people use AV as a bandaid; they'll just install AV and think their system is secure. I stand side by side with you in saying that's either ignorance or willful neglect.
But any good sysadmin (or team of them) is well aware of his limitations. He cannot be perfect. Process will fail in spite of honest and hardworking attempts to perfect it. Safety nets used by such people are not bandaids in the sense of slapping one on an open head wound rather than taking the time to stitch it up properly. In the 'safety net' (but still work safe!) context, I think AV systems are perfectly justified: they reduce risk.
The only reason we put AV on IIS servers is to check off a box on RFPs. It's nigh impossible to convince prospective customers that it's pointless, so we just do it.
Beau
Post a Comment