Warning: Described in the article is somewhat outdated, because I abandoned Windows in the Windows 2003 era.

Every time my acquaintances ask me: “which antivirus is better?”, I can only say one thing: “an antivirus is like a court shaman. It can be better, it can be worse, but it’s impossible to determine who klamat is better. ” Anti-Virus does not guarantee protection against viruses, moreover, it has the full moral right to miss a new infection and start detecting it in 2-3 days after the “incident”. Those. as the main means of protection it is not very good.

The following describes the windows setting, which will protect against any real (ie, naturally occurring) viruses without the use of antivirus software. This configuration has been working on a terminal server for 3 and a half years, where users (in the best of times up to 70 people) are not at all embarrassed to drag all kinds of assholes on flash drives, climb on the network anywhere, etc.
')

Theory

Any self-respecting virus, once launched, by one or another method tends to gain a foothold in the system, i.e. creates an executable file or library that is written in one way or another in the launch. “Auto” launch or in the form of “add-ons” to other executable files (debugger, hander, plugin, etc.) is not important. Important: there is a barrier called “code launch”. Even good old viruses that write themselves to executable files should still be able to write to the files that are supposed to run.

Of course, there are viruses that multiply without creating files (for example, ms-blast). But the condition for the appearance of this virus should be the availability of the server for calls from the carriers of the virus or the launch of code through an exploit in the browser \ network component. In the case of a hole in the browser, further reproduction is not possible (because you need to access browsers on other machines, and this requires raising the server where other users will go and motivating users to go exactly to this node). In the case of a hole in the network component and reproduction without saving to disk, the method I have described is unlikely to work and an epidemic is possible. However, I am not sure that antiviruses will catch such a 0day exploit, plus, they (holes) are pretty quickly fixed, so I put this scenario as unlikely. The presence of firewalls further reduces their danger. Timely (automated) installation of updates saves from non-0day.

So, the main household danger is represented by viruses that run “from file” (if only because they are experiencing a computer restart). If we prohibit in some way the launching of “incorrect” files, the problem will be solved (because the virus that does not persist in the file will not survive the reboot, and in the case of a launch with user rights, even a banal relogin).

In Windows, there is a technology - a policy of limited launch applications. It can be activated in the "prohibit all that is not allowed." If you put a complete ban - for everyone, including administrators, all files, including libraries, then we will get an exact guarantee that an outsider (not included in the list of allowed files) will not run. At least I have not yet heard that there are holes in this technology. I draw your attention to the need to prohibit the library too, because the infamous configor runs from flash drives with the help of the library launch by deceiving rundll32.

However, prohibitions and permissions will not make sense if you do not formulate rules that prohibit the launch of "outsiders".

Security model

Before describing the configuration in detail, I will formulate the theoretical principles of its organization:

1. Where the user can write closed to run.
2. What the user can run is closed for recording.

These two simple rules allow you to protect the system from the launch of viruses by the user - the virus cannot form where the user cannot write, and where the virus can write will not give the desired effect - launch will be prohibited from there. At the same time, it protects (on the terminal server) from launching foreign applications with unknown gluttony in terms of resources.

Problems

But behind this rainbow simplicity lies the mass of pitfalls.

Stone number one: wild software. Software that stores executable files in a user profile, software that wants to write "to itself in the directory." In the proposed model, the rule strictly applies: software (executable files) in their directories, user data and settings in their own, and these directories do not overlap. (In fact, this is a re-creation of a classic unix-vey with / usr / bin and ~, mounted with a ban on + x). Servers are configured for the task (rather than selecting tasks for the server), so the presence of such programs can automatically mean that it is impossible to implement the described system. There is a lot of wild software, and it sometimes surprises (for example, Adobe Illustrator wants to write a lot to the Windows directory).

Stone number two: scripting languages. It will not protect us from a malicious user, however, a ban on launching script extensions completely protects from viruses. (the logic is this: even if the virus launches the script by running the resolved interpreter, it cannot survive the reboot, since it will need to launch the interpreter with the script after the download, and creating files that can be run, including shortcuts, is prohibited).

Stone number three: shortcuts will not work for users. In part, this can be solved by placing the necessary labels in all users, but users really do not like being forbidden to create labels. This is partially solved by creating personal quick launch panels for which the user does not have recording rights (i.e., they are updated upon user request).

Stone number four: many updates will not be placed (since they are not allowed to start). To solve this problem, you need to unleash group policy, put updates and tighten it back.

Stone number five: network components like IIS / Exchange. They still can not break the habit of writing anywhere (and in the case of IIS and execute code from anywhere), but I hope that you don’t do Exchange on the terminal server.

In other words - the protection is not given a little blood.

Settings

A ban can be set in the server's group policy (I usually use a policy with loopback processing and assign it to all terminal servers), or in a local policy (gpedit.msc).

The policy path is Computer Configuration, Windows Settings, Security Settings, Software Restriction Policies. When you first use them, you need to create them - right-click on Software Restriction Policies, "New Software Policies".

First, the paths that are allowed (additional rules) are configured:

Everything that is in c: \ windows, c: \ windows \ system32 c: \ program files is allowed to run. c: \ documents and settings \ all users \ desktop, c: \ documents and settings \ Start menu. Everything else is prohibited. In particular, it is necessary to prohibit the launch of the disk from the root default users can write to the root of the disk (yes, this is Microsoft's phagofich for compatibility with the old blunt software). To allow launching from c: \ documens and settings \ All users \ * (it shouldn't be done in bulk either - there is a directory of shared documents open for writing to all users.

All but the above is prohibited. More precisely, in the course of work, you may want to allow individual directories (for example, network balls), but you should strictly follow the described rule: you can run - you can not write. You can write - you can not run.

The ban is included in two stages - first in secruty levels (Disallowed), then in the root of the Software Restriction Policy in Enforcement - in “All software files” and “All users”.

The use of domain group policy is good because if you mess up with the policy and cannot run anything (even gpedit), then this can be fixed from a third-party server.

Practical operation

The configuration has been used for several years without major changes, during this time there have not been a single case of terminal server infection (at best, up to 70 people with IE6 / 7 and a bunch of flash drives) or workstations running Windows XP (about three dozen in three companies) . In the logs, I occasionally see messages prohibiting the launch of a file (most often from temporary internet files). During this time, a lot of software that was incompatible with the configuration was discovered - from Autodesk view (DWG viewer, it works somehow, but with mothers) to Thunderbird (which tries to store plugins in the user profile).

Operation of this configuration in automatic mode is likely to fail (it does not work, it does not work), but with a little care it allows you to forget about the antivirus problem (and in terms of the terminal server it can significantly save on hardware, because the load on the server greatly reduced).

Moreover, even one computer running as an administrator (the specifics of the software used) works in this mode - during this time there has not been a single successful infection (although theoretically it is possible under such conditions).

Windows 2008/7 / Vista

Here I can’t speak very confidently, but in that small amount, how many I watched them, directory names were changed (in particular, for applications and all users), which requires a substantial processing policy (from the half-boot of windows 7 with the above described ways the user is not allowed to run the program).