Making Your Windows Box a Little More Secure

by DieselDragon

0x00: Introduction

Following a long period of playing around with the various security tools and features in Windows, I thought that I'd share some of my findings.  Hopefully, this might help those of us "locked in" to using the Windows family in protecting our machines a little bit better than they are normally.  The things detailed here have been tested and applied on a machine running Windows XP Pro SP2, but should hopefully be supported in all versions of Windows 2000, Windows XP, and Vista.

0x01: Who This Guide Is For

Most articles in 2600 seem, to my eye, to be written mainly for those lucky enough to be able to understand and use Linux without experiencing serious implosion of the brain.  Sadly, some of us are classic victims of vendor lock-in and, try as we might, find that the only kind of OS we can efficiently use is one of the Microsoft Windows family of operating systems.  This article is primarily aimed at general users of Windows, and concentrates mainly on applying secure practices in Windows XP.  The methods and practices used here should also be adaptable for use in Windows Vista and other operating systems.

This article has been written so that it can be used easily by those without much computer know-how (such as the less computer-savvy friends of regular readers) and as a result a lot of the wording may appear very simple and newbie-friendly to more experienced readers.

Please accept my apologies in advance if this article is too simplistic or verbose.

If You("Experienced user") = True Then
  Goto 0x07
End If

0x02: Security in Windows - A Brief Intro

With the exception of Windows CE and ME, the Windows operating system has been based on NT technology from Windows 2000 onwards.  One of the major benefits of this change has been a switchover from using the FAT filesystem - which had been in use since 1980, and had no support for user accounts and file security - to the NTFS filesystem, which supports user accounts and allows for user-specific access control to individual files and folders.

In short, this means that any user on a Windows 98/ME machine can install programs and make changes to the operating system without needing administrative privileges, whereas users on Windows 2000/XP/Vista computers who don't have the administrator privileges, cannot generally make any changes except creating and changing files inside their own document folders.

In addition, the same security measures also mean that User A cannot read or change User B's files unless User A has administrative privileges, or User B has specifically allowed User A access to those files.

0x03: A hypothetical Case-Study

Let's take the Doe family: Jane and John Doe, and their three children: Claire, Mark, and David.

They bought their home PC from a major computer store about two years ago.  It came with Windows XP Home Edition.  John uses the computer for editing sensitive work documents that include private financial and client data.  Jane runs a business from home and uses the computer to keep track of business finances, word processing, client management, and online banking.

The children mainly use the computer for surfing the Internet and using various instant messaging applications, although Claire also manages an ever increasing music library using iTunes, Mark creates and edits music using several studio packages, and David plays just about any half interesting game that can be freely downloaded from the Internet.

When they set up their computer, the Doe family simply plugged it in and turned it on, giving no thought to computer and user management.  They created user accounts for everyone using the Windows default settings - unwittingly giving all five users full administrative privileges, and allowing anyone logged in to the machine to install programs and change any aspect of the operating system.

At this stage, everyone has become extremely annoyed with the computer.

Over time it has gradually slowed down and become increasingly unreliable.  Their anti-virus programs (of which they have several) continually warn of viruses and malware that keep appearing over and over, and nothing they try seems to get rid of them.  They can't seem to figure out how all of this malware keeps making its way through the firewall and installing itself onto the computer.

In addition, unusual transactions from foreign countries have recently started appearing on Jane's business account with an ever increasing frequency.

0x04: Spotting the Security Flaws

Anyone with an eye for computer security will immediately spot several major mistakes in the way that the system has been set up and managed.

Giving all users of the computer administrative privileges is a major error in any circumstance.  Especially so, when some of those users are children.  As any parent will readily testify, children love playing computer games.  The first thing he or she will do upon coming home is to download and install the game so that they can play it with their friends and compete for the highest score.

Very rarely will a child think to run a virus/malware scan over the game before installing it.  They may even think that it's safe just because it came from a website.  If the game comes with malware attached, as so many "free" games and applications do, then it'll be installed along with the game and gain full access to everything on the system.  Remember, the child's account has admin rights.

In this case, a firewall (or even 1,000 firewalls) would be completely useless in preventing the application from making it to the computer because the initial connection to the download site was made by the user.

Although a firewall might warn the user that the application is trying to communicate with the Internet when it's run, many users will allow such communications as a reflex action, especially if the game, or whatever application, is known to make use of some kind of online functionality.

Likewise, giving any regularly used account administrative rights is an unwise practice for a computer in a home or general office environment, as it would grant any potentially malicious code (say, ActiveX controls in a web page) full reign of the system.

It takes only a momentary lapse in security - or just a single web page - for malicious code to arrive and be executed on the computer.

For general computer use, the best practice, in my personal opinion, is for every user of the system to have a restrictive user account that can only make changes to the user's own document folders, and to have a single administrator account that is password protected and is only ever used for system maintenance purposes and the installation of known, trusted applications... similar to the best practice often applied on Linux machines concerning use of the "root" account.

Although this practice would not defeat all forms of malware, it should make it much harder for a malicious application to gain full control of the system and access every file on the machine.  This means that malware arriving and successfully installing itself under a child's account can only access and manipulate data in the child's document folders, and should only be able to monitor whatever that child is doing, as opposed to monitoring every keystroke and mouse click of every user of the machine.

Remember that when an application is run, it is subject to the same privileges and restrictions as the user who started it, therefore an application running under a restricted user account should not be able to make changes to the operating system, or access any other user's files.

0x05: A Clean, More Secure Installation

John Doe has had enough of the constant virus and malware alerts, the abysmal machine and Internet performance, and the continual errors.

Enlisting the help and advice of a computer-literate friend (who we'll call Bob), he decides to go for a full format and re-installation of his system.  Under Bob's supervision, he carefully backs-up user files on the machine, avoiding unrecognized EXE, COM, MSI, and VBS files in the children's accounts.

He unplugs the Ethernet cable from the back of the computer, and reboots the machine with the Windows XP CD-ROM inserted.  After rebooting, he performs a full NTFS format of the hard drive, and Windows XP begins installing as normal.

After the usual succession of reboots, progress bars, language/network related prompts, setting a very strong password for the "Administrator" account, and on-screen messages of how "superior" Windows XP is, he comes to the Windows XP first-run screen or what Microsoft calls an "Out of Box Experience."

Upon arriving at the page where the user enters names for accounts that will use the machine, Bob tells him to stop entering account names as there is a problem with this page: All accounts created here will be given administrative rights by default, and it's very difficult, if not downright impossible, to change them to limited accounts later on.

Instead, Bob advises creating a single account called "SuperUser" that can be used to create general user accounts, and for system administration at a later date.

After even more waiting around whilst Windows gets its first-run act together, John is finally logged in as "SuperUser" and gets a default Windows desktop. Before doing anything else, Bob shows him how to turn on the Windows firewall:

("My Computer -> Network Connections -> right-click the Internet connection -> select 'Properties' -> click the 'Advanced' tab -> check the box and click 'Apply'")

and he sets it up with the "Don't allow exceptions" rule.

John then reconnects his Ethernet cable, activates Windows over the Internet, and updates his machine using Windows Update.  Now his machine has been fully updated with the latest security patches, and the most up-to-date settings for default users have been applied.

After updating Windows with the latest security patches and making a "clean start" system restore point:

("Start -> Programs -> Accessories -> System Tools -> System Restore")

He proceeds to the "User Accounts" control panel to create logons for himself, his wife, and kids.

Before doing anything else though, he sets a suitably strong password for the "SuperUser" account so that only authorized users (himself and Bob in this case) can perform system-wide changes and application installations.

After this, he creates new accounts for everyone and ensures that everyone, himself included, has a "restricted" account that will not be able to change anything that would affect the system.

Additionally, he turns off the "fast user switching" feature ("User Account control panel -> Change how users log on and off") to reduce the chance of a malicious application running under a restricted user account managing to "jump" over to the SuperUser account if both are logged in at the same time.

Finally, after reinstalling Windows, activating the Windows firewall, creating restricted accounts for all users, performing fresh installs of security software and firewalls, and restoring backed-up user data, he tests his restricted account by logging on and trying to install an application, finding it to his satisfaction that the install program quits with an "Access denied - User has no administrative privileges" error.

0x06: Dealing With Troublesome Applications

A year after reinstalling his system in this way, everyone is still happy with how well it's working.

Although the system does slow down every so often thanks to the large number of system services installed (security software, iTunes, and several cellphone application suites), the number of malware and virus alerts has remained very low - such alerts often being traced to game install packages downloaded by the children, that would be checked and verified by John first before installation via the SuperUser account if that application was considered safe.

However, there is one problem: David, having recently developed a serious addiction to World of Warcraft is requesting that his user account be made into an Administrator's account.

The reason is because World of Warcraft is frequently updated with new patches and software updates, and although David can play the game fine with a restricted account, updates need to be installed as the "SuperUser".

It normally runs under David's account, and thus only has read permissions for the World of Warcraft program folder, and John can't always be there to update the game as soon as a new patch is released.  Noting that the majority of malware and virus alerts on the system are traced to files stored in David's account, John is rightly against the idea of giving David's account administrative rights.  He consults Bob for advice on how to work around the problem without placing the system at risk.

Bob knows that every file and folder on an NTFS drive has an Access-Control List (ACL) attached to it that controls which users can access, create, or change that file.

Noting that David is the only family member who uses World of Warcraft, he logs in as "SuperUser", opens the command prompt:

("Start -> Run -> type COMMAND.COM and hit Enter)

Change to the PROGRAM FILES folder by typing CD \PROGRA~1 (which is a DOS short-path and should be valid on XP and Vista PCs), and checks the ACL for the World of Warcraft folder by typing CACLS WORLDO~1 and hitting Enter.

This shows a list of which users have access to the World of Warcraft folder; All users can read it, but only administrators can make changes.

Typing CACLS /? will display a brief guide to using the command.

The next step is best done only by experienced computer users: Bob decides to give David full access rights to the World of Warcraft folder, and uses the command: CACLS WORLDO~1 /T /E /C /G DAVID:F

This gives David full read/write/modify/execute rights to the World of Warcraft program folder and every file and folder below it.

After verifying the output, Bob logs out of "SuperUser" and asks David to log in and try running World of Warcraft to see if the changes to the ACL were successful.  David tries some functions that would result in data being changed on the hard drive (performing a World of Warcraft update, taking in-game screenshots, and setting up character macros are three such tests that can be performed), and finds that now the in-game screenshots and character macros have been saved to the World of Warcraft program folders successfully.

As a precaution, Bob also adds a shortcut to David's startup folder ("Start -> Programs -> Startup") that fires up the antivirus program and performs a full scan on the World of Warcraft folder to make sure that no malware infections in the World of Warcraft folder go undetected, before World of Warcraft itself is run.

Another approach to solving this problem, useful if an application - is accessed by multiple users, is to create a new restricted user account specifically for that program, give the account read/write or full access to the relevant folder using CACLS, and change the application shortcuts to make sure that the program is run under the application-specific account:

("Right-click the shortcut -> select 'Properties' -> click the 'Advanced' button under the 'Shortcut' tab -> select 'Run As' or 'Run with different credentials'")

instead of the current user's account.

An additional benefit to this approach, assuming that the "Protect my files, folders and settings" option is checked, is that anything running under that account, including malware, will be denied access to user files or folders by Windows.

However this technique would inhibit legitimate read/write operations to user files if it was applied to a program that uses them, such as Microsoft Word.

Following Bob's simple modification to the World of Warcraft folder ACL, David has been able to play and update World of Warcraft himself, without needing John or Bob to log in under the "SuperUser" account.  This has saved David a lot of inconvenience and waiting around, and John no longer has to deal with continual requests and SMS messages asking him to come home and update World of Warcraft as soon as he can!

0x07: Windows Security and Best-Practice Summary

For those who have lost all track of what I am saying thanks to the sheer volume of text above, here is a brief "bullet-point" summary of the article:

  • Windows 2000, XP and Vista all use the more secure NTFS filesystem by default, and this makes it easier to control which users can do what.  If you're still using Windows 98 or ME (or horror of horrors, Windows 95!) with a FAT filesystem, consider upgrading your operating system as quickly as possible.  This also applies to Windows 2000/XP computers upgraded from Windows 95/98/ME that are still using a FAT filesystem on the hard drive instead of NTFS.
  • Firewalls may prevent malware from sending data (keylogging info, etc.) to external servers, but they won't stop viruses or malware from arriving on a machine if a user unknowingly downloads them in the first place.  Most firewalls allow known web browsers (IE and Firefox, to name but a few) to always connect to the Internet, effectively throwing open the door for malicious data to come through if the user opens the connection in the first place.
  • Viruses and malware can only run with the same privileges as the current user, at least until they are run under an account with admin rights.  Therefore, if the current user account is a restricted one, any malware programs running under it will only be able to change data under the user's own data folders and "shared documents," and will have a great degree of difficulty installing themselves as a system-wide application or service.
  • When using Windows 2000, XP or Vista, the best practice is to make all user accounts (i.e. the one that you use to log on to Windows) restricted ones, and only use accounts with admin privileges for system maintenance.  This is especially important where accounts used by children or teenagers are concerned.  On the same token, one should always be very careful when logging onto an account with administrative rights, and make sure that you don't run anything that is potentially unsafe.  Do a cold boot (shutdown, wait a minute, then power up again) if you consider it necessary.
  • Windows 2000 and XP users beware that accounts created using the initial Windows welcome and setup screens are given administrative privileges by default, and it's very hard to change them to restricted accounts later on.  Just create a single "SuperUser" account (use whatever name you wish) to get past the setup screens, and create restricted accounts later on.  This might not apply to Vista users, but you should double-check this by looking carefully at the user account's control panel all the same.
  • If a program needs to update itself on a regular basis by writing updated files to its own folders, consider modifying the file/folder ACL using the CACLS command, instead of automatically giving the user of that program administrative rights to the whole system.
  • If several users all make use of a regularly updated program, consider creating a restricted user account especially for that program and configure access rights and restrictions for that account, ensuring that the account itself can only change the program and directly associated files that it has been created for.  Remember to set the program to only run under that special account, instead of having it run as the current user.

0xFF: The Final Word

I hope that this tutorial has helped you all learn a little about how the security setup works on Windows NT-based platforms, and some best practices for ensuring that your Windows boxes are set up to inhibit or reduce the damage done from unwanted system-wide changes and malware installations.

If you need assistance with doing anything mentioned in this article, there are many free support forums out there for Windows users where you should be able to get help much quicker and more easily than I could ever manage!

Shouts to whoever came up with the User/Group/Other permission system in Linux from which the initial principles in this article are derived and a family from Guildford who were the inspiration for the case-study above, and indeed the article itself.

Return to $2600 Index