I stopped using a resident AV in 2005, mainly for the same reasons you listed. Today, 9X users have another reason to add to that list, a dwindling number of choices that run on 9X systems. Most users have grown up with AVs on their systems. Thanks in large part to companies motivated by profit promoting a single method of protection that creates user dependence on a continuous stream of updates, the majority of users are not aware that there are other ways to protect/secure a PC that are equally or more effective. Windows has long had convenience and permissiveness as its core philosophy. The user can do anything, as can most of the installed software. Except for some specifically blocked items, any application can launch any other application, including ones that can alter critical settings in the OS. AVs are also based on this philosophy or policy, which can be accurately described as default-permit. In the beginning, this policy was reasonably effective. There wasn't that much malicious code. Internet access was primarily dialup, which helped keep down the rate that malicious code spread. The present day scenario is much different. Counting variants, there's over half a million examples of malicious code. Today, high speed and connected 24/7 is the norm. Static IPs are common. PCs are connected and targetable all the time, not just when a user is online. 9X users also have to deal with dwindling software support for user software. The security flaws aren't getting fixed in the versions we have to use for many apps.
One of the most effective ways to secure a 9X system is to reverse the philosophy it's based on. On 9X systems, there's no separation of user and administrator functions. The first step in securing a 9X system is defining user and administrative functions. Installing or updating software, registering DLLs, registry modifying, changing system settings, etc should all be regarded as administrative tasks. The advice that's given to users of NT systems applies to 9X as well. The OS shouldn't be in an administrator mode during normal usage. The task then becomes effectively separating the user and administrator modes. For this, we have a couple of tools available. The first is on the Windows CD, the policy editor. It's located in \tools\reskit\netadmin\poledit\ and is not part of a default install. The file, poledit.exe can be run from a floppy and works by making specific changes to the registry. Before using the policy editor to make any changes to your system, make a full backup of the registry. On units with more than one user profile, make sure the backup includes the user.dat files for each profile. When the policy editor is used to open the registry, two choices are displayed:
1, Local Computer.
2, Local User.
The settings most useful for the creation of separate user and administrator modes are found under Local_User\Windows 98 system.
The options available here are:
1, Shell.
2, Control Panel.
3, Desktop Display.
4, Restrictions.
The Shell and Control Panel sections are useful for restricting users access to sensitive parts of the system. The last section, Restrictions, has more powerful options. The screenshot below shows where an application whitelist can be created.
Resized to 93% (was 758 x 457) - Click image to enlarge
This section will not restrict system executables but will restrict applications, installers, trojans, adware, etc from being launched by explorer or another user application. Whitelisted applications need to be entered as a filename with the extension, such as poledit.exe. Make certain that you include poledit.exe in your whitelist or you won't be able to get back into the policy editor. With a little planning, all the apps a user might need for normal user tasks can be added. Since the user can't accidentally launch a malicious process or install an unwanted program, this will greatly reduce the chances of the user compromising the system. On multiple user PCs, each users allowed list can be individually made.
The policy editor performs some of the functions normally associated with HIPS (Host Intrusion Protection System) software but is not as reliable. On 98, the policy editor does not check the path used by the whitelisted executable or its integrity. It has no signature checking. If test.exe is in the allowed list, any file named test.exe will be allowed to execute. NT systems have more safeguards against this type of spoofing, so the practice isnot nearly as common as it used to be.
On NT systems, HIPS software, whether free-standing or part of a firewall suite gives those systems the equivalent of a policy editor on steroids. Just about all of them are for NT systems only, but there is one exception that I know of. It's the free version of System Safety Monitor. It's no longer supported or being developed, but then neither is 98. It is the most effective option I've ever seen for controlling applications and their activities on a 9X system. I'll cover this along with controlling internet access, preventing compromise by limiting integration and interprocess activity, registry protection, and filtering undesired and malicious web content from the allowed traffic in later posts. It takes some time and planning to go through the details, but with a well thought out strategy, a 9X system can be made very close to bulletproof, and at no cost.
Rick
No comments:
Post a Comment