"Harlan Carvey" <keydet89@yahoo.com> 07/20/05 10:55 AM
There is no doubt there have been many security
holes in Windows. Some of them have been
remotely-exploitable without user intervention (RPC
vulnerabilities, for example).
With respect to web servers, if the system is running
RPC/DCOM, then it is no longer *just* a web server.
This is a point I've been making all along. If you
install IIS 6.0 on a stock installation of Win2K3,
without any modifications, then there exists a flaw in
the security process, for which the installation of
A/V software is a poor band-aid.
I used RPC vulnerabilities as the example. However, anything that can cause
improper code to start executing would do it. Code Red/Nimda, for example.
Web server facing out to the Internet and using standard HTTP. This is an
example where the machine could be locked down as far as it could go and yet
still have a vulnerability.
WRT servers in general, I would have to wonder why
these servers are being treated in isolation. Do
companies (or any other organization) really put
sensitive information on systems that are simply
plugged into the Internet, with no surrounding
infrastructure at all? If that's the case, then I say
again, A/V software is a poor band-aid b/c something
in the security process is broken. Such breakdowns
cannot be resovled with the installation of software
packages...the process itself must be fixed.
No matter how good the process is, there can still be flaws. The measures that
an administrator takes can be deemed complete at the time, yet have an unknown
vulnerability hidden away. "Prove to mean your machine is invulnerable." It
cannot be done.
You said in one of your responses that for every additional layer you add,
there's an additional layer of administration and complexity. And I agree. So
I don't advocate for just automatically throwing a software package at a
perceived problem because it (potentially) introduces more problems into the
system.
Without AV software,
I have no chance of catching anything that comes
into my server through unexpected means.
If the means are unexpected, then how do they get
caught? IMHO, part of the security process is to
reduce the attack surface, limiting those resources
that are exposed, and securing those that are.
Reducing the attack surface does not mean there is no attack surface. It means
you have accounted for everything you know and can consider. If a virus or
worm infects a machine, it will likely be writing a file to the disk
(otherwise, it would have no means of surviving a reboot). The AV software
should catch it upon writing the file to the disk.
With AV
software, the odds improve that I will find the
virus or worm around the time it is trying to get
in. The odds may not be 100%, especially for a
0-day.
Interesting. If the malware is not 0-day, is it then
known? What's the timeframe? Are we talking about a
scale of weeks or months? If that's the case, then it
is known, and understood...perhaps not by the person
who administers the machine, though.
However, I have a slim chance that
heuristics may catch it. I will take a slim chance
over no chance.
And I choose to take an educated approach,
understanding the purpose of the system, it's
exposures, and what I can do to protect it.
The decision to run AV software as a tool to try to compensate for the unknown
does not imply it is an uneducated approach. If anything, it is a recognition
that trusted mechanisms (such as authentication mechanisms) can fail or be
subverted within computing systems and an attempt to provide a plan "B" in the
event of such failure.
I get the feeling you're trying to hear someone say that it is not necessary to
run AV software on a server. I can't say that. What I can say is that it is
something that needs to be considered in the planning stage for bringing the
server together within the context of a complete security analysis. I would
hope you would agree that it is something that needs to be _considered_, even
if ultimately rejected, just because it is another mechanism that can be used
to provide additional security. If I have a router or a switch that I program
to deny inbound connections except to port 80 on a Web server, that doesn't
mean I should leave all the other ports and services running on said Web
server. I should still go through and shut off anything that isn't needed.
Configuring the network hardware and the server to deny those connections
complement each other. If the router/switch programming fails, I am still
protected on the server. So despite my best efforts to protect the server
through other means, AV can provide a backup in the event that other mechanisms
fail. AV can complement the other security measures I take.
If you choose not to use AV, that's fine, so long as you have taken "an
educated approach," understand what it can and cannot do, and have elected to
accept the risks based on your analysis. It's all a matter of accepting
responsibility for whatever choice you make as to whether to use or not use a
particular security mechanism. That's really all it is. And that applies to
any security measure, not just AV.
Matt
---------------------------------------------------------------------------
---------------------------------------------------------------------------
