July 26, 2010 at 08:41Windows-based computer without antiviruses
Warning: Described in the article is somewhat outdated, as I abandoned Windows in the era of Windows 2003.
Every time my friends ask me: “which antivirus is better?”, I can only say one thing: “antivirus is like a court shaman. It’s better, it’s worse, but it’s not possible to determine who is better off. ” Antivirus does not guarantee protection against viruses, moreover, it has the full moral right to skip a new infection and begin to detect it 2-3 days after the “incident”. Those. as the main means of protection, it is not very suitable.
The following describes the windows setting, which will protect against any real (i.e., naturally occurring) viruses without the use of antiviruses. 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, surf the network anywhere, etc.
Any virus that respects itself, once it has been launched, seeks to gain a foothold in the system, i.e. creates an executable file or library, which is written in one way or another to run. "Auto" launch or in the form of "additions" to other executable files (debugger, hander, plug-in, etc.) - it does not matter. Important: there is a barrier called code execution. Even the good old viruses that add themselves to executable files should still be able to write to the files that they intend 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 accessing the virus carriers or the launch of code through an exploit in the browser \ network component. In the case of a hole in the browser, further propagation is not possible (because you need to access the browsers on other machines, and this requires raising the server, where other users will go and motivation for users to go to this particular node). In the case of a hole in the network component and propagation without saving to disk, the technique described by me with high probability will not work and an epidemic is possible. However, I’m not sure that antiviruses will catch such a 0day exploit, plus, they (holes) will be quite briskly fixed, so I postpone this scenario as unlikely. The presence of firewalls further reduces their danger.
So, viruses that run “from a file” (mainly because they are undergoing a computer reboot) represent the main domestic danger. If we forbid somehow the launch of the “wrong” files, then the problem will be solved (because a virus that is not saved in the file will not be able to survive a reboot, and if launched with user rights, even a banal relogin).
There is a technology in Windows - a policy of limited application launch. It can be activated in the “prohibit everything that is not allowed” mode. If the ban is complete - for everyone, including administrators, all files, including libraries, then we will get an accurate guarantee that an extraneous (not included in the list of allowed) file will not be launched. At least I have not yet heard that there are holes in this technology. I draw attention to the need to prohibit libraries, too, because the infamous conficer is launched from flash drives by launching the library by tricking rundll32.
However, prohibitions and permissions will not make sense if you do not formulate rules that prohibit the launch of "strangers."
Before describing the configuration in detail, I will formulate the theoretical principles of its organization:
1. Where the user can write is closed for launch.
2. That the user can start 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, it will not have the desired effect - from there the launch will be prohibited. At the same time, this protects (on the terminal server) from running extraneous applications with unknown resource gluttony.
But behind this rainbow simplicity lies a mass of pitfalls.
Stone number one: wild software. Software that stores executable files in the user profile, software that wants to write "to your 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 intersect. (In fact, this is a recreation of the classic Unix vei with / usr / bin and ~, mounted with a ban on + x). The servers are configured for the task (and do not select tasks for the server), so the presence of such programs may automatically mean the inability 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 in the Windows directory).
Stone number two: scripting languages. This will not protect us from a malicious user, however, the ban on running script extensions fully protects us from viruses. (the logic is this: even if a virus starts a script by running an authorized interpreter, it will not be able to survive a reboot, since it will need to run an interpreter with a script after loading, and creating files from which you can run, including shortcuts, is prohibited).
Stone number three: shortcuts will not work for users. This can be partially solved by placing the necessary shortcuts in all users, but users really do not like it when they are forbidden to create shortcuts. This is partially solved by creating personal quick launch panels to which the user does not have write permissions (i.e., they are updated at the user's request).
Stone number four: many updates will not be installed (since they are prohibited from starting). To solve this problem, you need to unwind the group policy, install updates and spin it back.
Stone number five: network components like IIS / Exchange. They still cannot break the habit of writing anywhere (and, in the case of IIS, executing code from anywhere), but I hope that you are not doing Exchange on a terminal server.
In other words, protection is not given by little blood.
The ban can be registered in the server’s group policy (I usually use a policy with loopback processing and assign it to all terminal servers), or in the local policy (gpedit.msc).
The path to the policy is Computer Configuration, Windows Settings, Security Settings, Software Restriction Policies. At first use, 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 located 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 forbidden. In particular, it is necessary to prohibit starting from the root of the disk, because users by default can write to the root of the disk (yes, this is the phagofic of Microsoft for compatibility with old stupid software). Allow starting from c: \ documens and settings \ All users \ * (wholesale_ also should not be - there is a directory of general documents open for recording to all users.
Everything except the above is prohibited. More precisely, you may want to allow certain directories (for example, network balls), but you must strictly follow the rule described: you can run - you can not write. You can write - you can not run.
The ban is included in two stages - first at secruty levels (Disallowed), then at the root of the Software Restriction Policy in Enforcement - in "All software files" and "All users".
Using domain group policy is good because if you messed up in politics and cannot start anything (even gpedit), then this can be fixed from a third-party server.
The configuration has been used for several years without any changes, during this time there has not been a single case of terminal server infection (up to 70 people with IE6 / 7 and a bunch of flash drives in the best of times) or workstations running Windows XP (about three dozen in three companies) . In the logs, I periodically see messages about the prohibition of starting a particular file (most often from temporary internet files). During this time, a lot of software incompatible with the configuration was discovered - from Autodesk view (DWG viewer, somehow working, but with matugs) to Thunderbird (which tries to store plugins in the user’s profile).
The operation of this configuration in automatic mode is likely to be unsuccessful (it doesn’t work, it doesn’t work), but with a little care it allows you to forget about the problem of antiviruses (and in the conditions of a terminal server it can significantly save on hardware, because the server load greatly reduced).
Moreover, even one computer from under the administrator works in this mode (the specifics of the software used) - during this time there has not been a single successful infection (although theoretically in such conditions it is possible).
Here I can’t speak very confidently, but in the small amount I watched them, they changed the directory names (in particular, for applications and all users), which requires significant processing of policies (from half-windows 7 with the above ways the user was not allowed to run programs).
Every time my friends ask me: “which antivirus is better?”, I can only say one thing: “antivirus is like a court shaman. It’s better, it’s worse, but it’s not possible to determine who is better off. ” Antivirus does not guarantee protection against viruses, moreover, it has the full moral right to skip a new infection and begin to detect it 2-3 days after the “incident”. Those. as the main means of protection, it is not very suitable.
The following describes the windows setting, which will protect against any real (i.e., naturally occurring) viruses without the use of antiviruses. 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, surf the network anywhere, etc.
Theory
Any virus that respects itself, once it has been launched, seeks to gain a foothold in the system, i.e. creates an executable file or library, which is written in one way or another to run. "Auto" launch or in the form of "additions" to other executable files (debugger, hander, plug-in, etc.) - it does not matter. Important: there is a barrier called code execution. Even the good old viruses that add themselves to executable files should still be able to write to the files that they intend 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 accessing the virus carriers or the launch of code through an exploit in the browser \ network component. In the case of a hole in the browser, further propagation is not possible (because you need to access the browsers on other machines, and this requires raising the server, where other users will go and motivation for users to go to this particular node). In the case of a hole in the network component and propagation without saving to disk, the technique described by me with high probability will not work and an epidemic is possible. However, I’m not sure that antiviruses will catch such a 0day exploit, plus, they (holes) will be quite briskly fixed, so I postpone this scenario as unlikely. The presence of firewalls further reduces their danger.
So, viruses that run “from a file” (mainly because they are undergoing a computer reboot) represent the main domestic danger. If we forbid somehow the launch of the “wrong” files, then the problem will be solved (because a virus that is not saved in the file will not be able to survive a reboot, and if launched with user rights, even a banal relogin).
There is a technology in Windows - a policy of limited application launch. It can be activated in the “prohibit everything that is not allowed” mode. If the ban is complete - for everyone, including administrators, all files, including libraries, then we will get an accurate guarantee that an extraneous (not included in the list of allowed) file will not be launched. At least I have not yet heard that there are holes in this technology. I draw attention to the need to prohibit libraries, too, because the infamous conficer is launched from flash drives by launching the library by tricking rundll32.
However, prohibitions and permissions will not make sense if you do not formulate rules that prohibit the launch of "strangers."
Safety model
Before describing the configuration in detail, I will formulate the theoretical principles of its organization:
1. Where the user can write is closed for launch.
2. That the user can start 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, it will not have the desired effect - from there the launch will be prohibited. At the same time, this protects (on the terminal server) from running extraneous applications with unknown resource gluttony.
Problems
But behind this rainbow simplicity lies a mass of pitfalls.
Stone number one: wild software. Software that stores executable files in the user profile, software that wants to write "to your 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 intersect. (In fact, this is a recreation of the classic Unix vei with / usr / bin and ~, mounted with a ban on + x). The servers are configured for the task (and do not select tasks for the server), so the presence of such programs may automatically mean the inability 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 in the Windows directory).
Stone number two: scripting languages. This will not protect us from a malicious user, however, the ban on running script extensions fully protects us from viruses. (the logic is this: even if a virus starts a script by running an authorized interpreter, it will not be able to survive a reboot, since it will need to run an interpreter with a script after loading, and creating files from which you can run, including shortcuts, is prohibited).
Stone number three: shortcuts will not work for users. This can be partially solved by placing the necessary shortcuts in all users, but users really do not like it when they are forbidden to create shortcuts. This is partially solved by creating personal quick launch panels to which the user does not have write permissions (i.e., they are updated at the user's request).
Stone number four: many updates will not be installed (since they are prohibited from starting). To solve this problem, you need to unwind the group policy, install updates and spin it back.
Stone number five: network components like IIS / Exchange. They still cannot break the habit of writing anywhere (and, in the case of IIS, executing code from anywhere), but I hope that you are not doing Exchange on a terminal server.
In other words, protection is not given by little blood.
Settings
The ban can be registered in the server’s group policy (I usually use a policy with loopback processing and assign it to all terminal servers), or in the local policy (gpedit.msc).
The path to the policy is Computer Configuration, Windows Settings, Security Settings, Software Restriction Policies. At first use, 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 located 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 forbidden. In particular, it is necessary to prohibit starting from the root of the disk, because users by default can write to the root of the disk (yes, this is the phagofic of Microsoft for compatibility with old stupid software). Allow starting from c: \ documens and settings \ All users \ * (wholesale_ also should not be - there is a directory of general documents open for recording to all users.
Everything except the above is prohibited. More precisely, you may want to allow certain directories (for example, network balls), but you must strictly follow the rule described: you can run - you can not write. You can write - you can not run.
The ban is included in two stages - first at secruty levels (Disallowed), then at the root of the Software Restriction Policy in Enforcement - in "All software files" and "All users".
Using domain group policy is good because if you messed up in politics and cannot start anything (even gpedit), then this can be fixed from a third-party server.
Practical operation
The configuration has been used for several years without any changes, during this time there has not been a single case of terminal server infection (up to 70 people with IE6 / 7 and a bunch of flash drives in the best of times) or workstations running Windows XP (about three dozen in three companies) . In the logs, I periodically see messages about the prohibition of starting a particular file (most often from temporary internet files). During this time, a lot of software incompatible with the configuration was discovered - from Autodesk view (DWG viewer, somehow working, but with matugs) to Thunderbird (which tries to store plugins in the user’s profile).
The operation of this configuration in automatic mode is likely to be unsuccessful (it doesn’t work, it doesn’t work), but with a little care it allows you to forget about the problem of antiviruses (and in the conditions of a terminal server it can significantly save on hardware, because the server load greatly reduced).
Moreover, even one computer from under the administrator works in this mode (the specifics of the software used) - during this time there has not been a single successful infection (although theoretically in such conditions it is possible).
Windows 2008/7 / Vista
Here I can’t speak very confidently, but in the small amount I watched them, they changed the directory names (in particular, for applications and all users), which requires significant processing of policies (from half-windows 7 with the above ways the user was not allowed to run programs).