Is on-access anti-virus a must?

[inCharge.co.uk]

If on-access scanners check every file every time its read or written, doesn't that add a massive overhead to a busy web-server, where files are being re-read & updated constantly? Is it worth it?

OK, cacheing would reduce the overhead a bit but still...

I guess you could tune it to only scan executables so it doesn't waste resources scanning html, database & log files. Is that safe?

Without on-access scanning, if a virus does get onto a machine, it could tamper with the on-demand anti-virus software, so evade detection.

Is relying solely on on-demand scanning worth the risk? Can a serious web-server afford the performance hit?

Cheers

[knightfoo]

I would not risk the performance hit. There should not be anything in your web root anyway that is executable and thus able to contain a virus. There are only a few ways you can get a virus on a server; checking e-mail, downloading from untrusted sources, and exploits that allow uploads. You can normally fix the first two with some common sense and an on-demand virus scan. The last is trickier, because if you have exploits that allow code execution, then the AV is cut out of the loop .. there is no file on the disk to even scan.

If you limit the ability to upload files and make sure you don't run extra stuff that is potentially exploitable, then you can just focus your on-access virus scans to specific directories (like a temporary upload directory). If you scan everything as it comes in then you don't have to worry about scanning it when it goes out.

[inCharge.co.uk]

You’re asking me to think like a Linux admin now!

e.g: we can rely on the file system to enforce security better than a 3rd party on-access scanner ever can.

Maybe if a server is sufficiently locked down then no on-access scanning is required.

[knightfoo]

The only time a file system access control would not work is if someone managed privilege escalation through an exploitable service. Also, if the service is exploitable, then code can be executed in memory and never touch the hard drive, so AV would not see it. SQL slammer did this .. it only existed in memory and got wiped if you rebooted. AV is only a small part of a good security solution.

[inCharge.co.uk]

That's a good reason to switch off services that aren't needed and run the rest on user accounts instead of the all-powerful SYSTEM, where possible.

How do I enforce this simple rule: Only Administrators may set files' 'Executable' attribute?

I don't think it can be done with NTFS permissions. Applications must run so 'Executable' can't be denied. Applications must set other permissions so 'Change Permissions' can't be denied.

An on-access scanner that prevents the creation of ANY executable would be better in some ways than an anti-virus scanner. More thorough because is would stop everything, not just the known/recognised stuff. Quicker because it woudln't need to scan file contents.

Programs like trust-no-exe come close:
http://www.beyondlogic.org/solutions/trust-no-exe/trust-no-exe.htm

[knightfoo]

On Linux you can run someting like SELinux or LIDS that prevents filesystem writes and code execution at the kernel level. Some of the newer processors have a feature that allows pages in memory to be marked "noexec", which limits the targets for buffer overflows. I *think* Windows takes advantage of this, but I cannot remember the name of the feature or where to set it.

[tsuehpsyde]

On Linux you can run someting like SELinux or LIDS that prevents filesystem writes and code execution at the kernel level. Some of the newer processors have a feature that allows pages in memory to be marked "noexec", which limits the targets for buffer overflows. I *think* Windows takes advantage of this, but I cannot remember the name of the feature or where to set it.

That would be "Data Execution Protection", or DEP.

http://support.microsoft.com/kb/875352

Beginning with Windows XP SP2, the 32-bit version of Windows uses one of the following:
• The no-execute page-protection (NX) processor feature as defined by AMD.
• The Execute Disable Bit (XD) feature as defined by Intel.

[inCharge.co.uk]

DEP is installed with w2k3 SP1.
To check whether a server's processor supports it & whether it is enabled:
- Click Start, Settings, Control Panel, System.
- On the Advanced tab, under Performance, click Settings.
- Select the Data Execution Prevention tab

[DXD]

DEP is installed with w2k3 SP1.
To check whether a server's processor supports it & whether it is enabled:
- Click Start, Settings, Control Panel, System.
- On the Advanced tab, under Performance, click Settings.
- Select the Data Execution Prevention tab

Any performance hits by enabling this?

[inCharge.co.uk]

I have a newer server and found it was already enabled. That server performs better than my older servers that don't have DEP but then it's a faster processor. So the DEP didn't negate other processor improvements.

[devilspgd]

Any performance hits by enabling this?

Performance, no -- However, if you have some apps that randomly stop working without explanation, good odds are it's DEP related.

Sometimes there will be an eventlog entry, but not always. Even explorer.exe occasionally dies on my box at home when DEP is enabled. It's also worth noting that this is far more problematic on multiple-CPU (dual-core included) HALs due to the additional threading complexity.