tag:blogger.com,1999:blog-9518042.post112197396217063915..comments2024-03-19T07:46:20.437-05:00Comments on Windows Incident Response: A/V software on web servers, revisitedUnknownnoreply@blogger.comBlogger3125tag:blogger.com,1999:blog-9518042.post-1121987636619272442005-07-21T18:13:00.001-05:002005-07-21T18:13:00.001-05:00The only reason we put AV on IIS servers is to che...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.<BR/>BeauAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-9518042.post-1121987611489954562005-07-21T18:13:00.000-05:002005-07-21T18:13:00.000-05:00Keydet89-Good stuff.But I'm still firmly in the AV...Keydet89-<BR/><BR/>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. <BR/><BR/>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.<BR/><BR/>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.<BR/><BR/>Errr ... unless someone manages to find & exploit a previously unknown vulnerability at the attack surface (it's small, but it's still <B>there</B>). 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. <BR/><BR/>Bringing me to my second contention - you seem to create the binary situation where an exploit is either:<BR/><BR/>-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<BR/>-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.<BR/><BR/>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! <BR/><BR/>So I admit: AV providers can respond to new situations faster than I can. I'm not ashamed to say it.<BR/><BR/>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.<BR/><BR/>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.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-9518042.post-1121984756223240422005-07-21T17:25:00.000-05:002005-07-21T17:25:00.000-05:00And SQL Slammer was handled either by the security...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.Anonymoushttps://www.blogger.com/profile/13441809988487585009noreply@blogger.com