Tuesday, July 19, 2005

A/V software on web servers

There's an interesting thread over on the SecurityFocus Focus-MS list, regarding the installation of anti-virus software on IIS 6.x web servers. I attempted to ignore it, but this morning felt the need to interject.

In a nutshell, my point has simply been that if a web server is just that...a web server...then for the most part, it's serving up content via port 80 (and possibly port 443). If the system is properly configured, why then is anti-virus software needed? If it's just a web server, and your LAN/infrastructure is properly configured and administered, what is the purpose of adding yet another software package to a system, that's going to generate yet another set of logs that will be ignored?

One post mentioned the fact that you can't possibly know all of the threats you'll face. Well, that's true...if you've got your head stuck in the sand. Remote attacks come down to two basic types...those that exploit poor configurations (ie, weak passwords, running unnecessary services, etc.), and those that exploit improper bounds checking in the software itself (ie, buffer overflows). Understanding this makes it easier to reduce the attack surface by greatly restricting the avenues available to an attacker. In fact, it is possible to reduce the attack surface to the point where you still have your necessary functionality, but pretty much the only way to compromise the system is to be the administrator sitting at the console...and at that point, no amount of anti-virus software is going to do you any good.

Another post mentioned that the web server is the public interface to the rest of the world, and anything that gets on the LAN can make it over to the web server, and you may possibly end up with an embarrassing situation (ie, defacement, malware proliferation, etc.). This may be the case...if you've got your web server installed on the same LAN segment as your employee desktops. However, the most likely avenue of attack at that point would be via NetBEUI/file sharing, and it that's enabled on your web server, then it's no longer just a web server, is it?

Take a look at some of the stuff that's hit the Internet. Remember Code Red? Well, some folks at MS set up an IIS 4.0 web server, and it was not susceptible to Code Red a full year before Code Red was launched. In fact, if everyone had simply disabled the proper script mapping the day before Code Red came out, they would not have been vulnerable.

If you're considering putting anti-virus software on a web server, I'd suggest that you look at the root cause as to why you want to do that. Perhaps a better investment would be in training of your staff (ie, support staff, as well as management), or in another product all together.

Am I saying that web servers should never have A/V installed? No, not at all...what I am saying is that before doing so, you should take a hard look at the reasons why you're doing so. Sometimes just setting some ACLs and removing unnecessary services will go a lot further than installing another software package that needs to be maintained.

As a side note, it seems to me that a lot of folks out there are of the mind, "if you're running Windows, you must have anti-virus installed." To me, this seems to be a very uneducated and misinformed position. I do not use A/V software on any of my personal systems, and have never been infected when I haven't done so intentionally. At work, there are no log entries from the corporate A/V software to indicate an infection of any kind on my workstation. Sure, if your kids are using a home system, you'd want to have anti-virus software installed, but that applies regardless of the platform.

Addendum: I was checking out Bruce Schneier's blog this morning and noticed something that rang true with this blog entry. Specifically, in one of his entries about turning off cell phones in tunnels, Bruce says, "This is as idiotic as it gets. It's a perfect example of what I call "movie plot security": imagining a particular scenario rather than focusing on the broad threats." Wow. Bruce gets lauded as a security expert when he says things like that (and I happen to think he's right). However, when I say something like, "There's no point in installing A/V software on a web server", which is pretty much along the same lines as what Bruce said, only mapped to the digital world, I end up getting emails that are better not quoted in public.

Most known threats can be protected against without the use of A/V software on web servers. New threats won't be caught because they're new, and not yet subject to scrutiny by the A/V community.

Oh, and one other thing...more than one person sent me email telling me that they "saw" A/V software protect systems from being infected with the SQLSpida worm. All I can say is, thanks guys, but you made my point for me.

6 comments:

Anonymous said...

Hi there,

I disagree with your second paragraph. You mention exploits which take advantage of improper bounds checking in software, but you sort of skip over the possibility that such things might represent a good reason to run additional host-based threat mitigation packages.

As a system administrator I can close down and/or firewall every listening port on the web server except 80 & 443. I can remove all unneeded services and executables. But at the end of the day I have very little control over the vulnerabilities exposed by the web server and the web apps themselves. I'm reduced to running patches as soon as MS publishes them, and puffing and blowing at internal web devs about coding practices which secure us from SQL injection, cross site scripting, blah blah blah.

So, as administrator I'll never have complete control, because I didn't write the system from scratch. To me this means that anti-malware systems, host-based IDS/IPS, integrity monitoring, etc are valuable as secondary 'safety net' protection even if I am the most diligent sysadmin in the world when it comes to mitigating other threats. Bottom line: if the additional security nets I install don't add vulnerability, then they reduce vulnerability!

Now I completely agree with the idea that one shouldn't place too much faith in safety nets like antivirus software - after all, it's a reactive safety measure, and proactive ones are usually more profitable.

Posting as anonymous because I really don't want another username/password to track. My name is Bryan, and I run adminfoo.net

H. Carvey said...

Bryan,

Thanks for your comments...this shows that one person read the blog today.

I think it's great that you posted, and it's cool that you disagree, but I'd like to address a few of your comments...

As a system administrator I can close down and/or firewall every listening port on the web server except 80 & 443.

Well, you shouldn't have to...b/c if the system is only a web server, only port 80 (and maybe port 443) should be open, right? There shouldn't be anything left to close down. After all, if you've got an IIS 6.0 web server, and you left file sharing up and running, then it's not just a web server, it's also a file server.

I simply don't understand why you'd want to firewall off a port that is already closed anyway...

Also, I don't remember making any mention of web apps, just the web server.

...at the end of the day I have very little control over the vulnerabilities exposed by the web server...

True, but you do have control of the functionality provided by the web server, and you can therefore reduce the attack surface. Remember what I said about Code Red? The buffer overflow to the .hta script mapping? As an admin, you're right...you had no control over that vulnerability being developed or released. However, when originally configuring the system, had you determined that you didn't require that functionality and disabled it, then you would not have been susceptible to that vulnerability.

if the additional security nets I install don't add vulnerability, then they reduce vulnerability!

I'm not sure I entirely agree with that. After all, based on your own statements (ie, "because I didn't write the system from scratch") how can you then say that if a software package doesn't add a vulnerability, then it reduces vulnerability?

Anyway, good comments, and I like the site...I've added it to my list of blogs to check.

Thanks!

Anonymous said...

Keydet89 -

In a lot of cases the system didn't become only a web server until a system administrator went through it and removed all the excess baggage. So I think we are saying the same thing there. To rephrase: "as an administrator I ensure it's only a webserver by verifying no extra services running and no extra ports open."

By "web app", I meant the actual web content. Sometimes this is just static pages being served. Sometimes this is an interactive thing, like your blog or mine. These might then require us to expose other executable functions like PHP or ASP or whatever. In this case the web server is still "only" a web server, but it's gatewaying to executable functions which increase the attack surface

Yes I completely understand what you meant with Code Red. My point is that while we can reduce the attack surface, we can never eliminate it. Well, not unless we also want to eliminate the actual function of the server that is!

To expand on my 'if it doesn't add vulnerability' thoughts. I was thinking something like this:

-IF the program is an actual 'safetynet' program such as antivirus, IDS, etc. ...
-AND it exposes no external vulns (listening ports)
-THEN the attacker must gain access to the safetynet program VIA whatever vulns the webserver might expose. He has to do this before the safetynet program detects and responds to his intrusion!

So, the safetynet program exposes no external vulnerability. Any internal vulnerability it exposes would require the attacker to be aware of and exploit two vulns, one after the other. Not impossible, but much less likely.

To me, security is all about risk and effort. If I can lower my risk level without greatly increasing my effort level, security is enhanced. Adding a safetynet program like antivirus, IDS, integrity checking, etc to a system with an already-low risk profile will cost little effort, and further reduce the risk that the system will be breached successfully and stealthfully.

It's not enough to build thick walls around Fort Knox. We still need ways to detect and respond if an intruder figures out a way to get inside those walls.

-Bryan
adminfoo.net

Anonymous said...

"So, the safetynet program exposes no external vulnerability."

I suppose the recent buffer overflows in various antivirus products are imaginary, then?

Good rule of thumb: more code == less secure, and its corollary.

H. Carvey said...

Thanks, Cory...from your post to the list, here's the Blackhat presentation.

Anonymous said...

Hi Cory,

No, those buffer overflows are not imaginary. But my original statement still stands, because every one of these exploits I've seen requires the attacker to actually get a file onto the AV protected system. So again using keydet89's example of 'just a webserver', the hacker has two problems: 1) he gain access to the server's AV system (by uploading a file, email, whatever). 2) He must then craft the exploit which takes advantage of the AV vulnerability.

The attacker has to solve (1) before he is in a position to begin solving (2). And that doesn't even address how the attacker would learn what AV system vulns exist on the server (or what AV system is running at all!).

So, yes, I stand by my statement about AV systems creating external vulnerabilities.

-Bryan