Windows Setup Guide: Security
Out of the box Windows XP is reasonably secure as far as security policies are concerned, but due to bug discoveries since its release there are a few major concerns. For the average user on dial-up Internet access, or for those unfortunate enough to have no Internet access, security coverage is narrowed down to local system intrusion. But, for the person on a high speed "always on" connection there are a few major concerns when installing Windows XP. So for peace of mind I will explain how to tightly secure your Windows computer.
Table of Contents
1. Windows Security Flaws
Normally after installing Windows XP you will be facing a clean update free version. Since the release of Windows XP there have been many major flaws that could cause your computer to be compromised by a cracker or a virus (worm) if let exposed on the Internet for only a few minutes. This should be patched as quickly as possible. Note that this holds true for Windows 2000 also. Please see the updates section for information on how to safely update your computer after a clean install.
The most notorious of these flaws is the one that MSBlast (and several other worms) exploited. The knowledge base article covering this problem at Microsoft is KB823980. If a computer exists on an open network along with a computer infected with a virus that takes advantage of this problem risks the chance of being infected if unpatched.
Return to top.
When first installing Windows XP you will be presented with a wizard that allows you to enter the users of the computer. It does not however allow you to enter passwords for these accounts and as such these accounts have no passwords. In Windows 2000 it has you set a password and then you use that password with the login account Administrator. Windows uses a username (actually associated IDs for those usernames called SIDs) and a password combination for you to log into your machine. But, what is not so commonly known is that these usernames and passwords can also be used to remotely access your computer's data (covered later). If you are wondering why these holes exist then the quick answer is that it allows network administrators at corporations to automate the control of vast corporate networks, and not at all suited for the average user.
In Windows 2000 it is highly advisable to either use a strong password or disable network access (covered later). The definition of a strong password varies from source to source, but generally it is anything that requires too much time or effort to crack. A password crack usually consists of a program that tries common dictionary words and then if that fails it attempts every character combination (called a brute force attack). This can be very timing consuming across a network, and so it would take years if your password is over 7 characters long and contains numbers and / or symbols. Most security advisors recommend at least using an 8 character password to protect yourself, but in section b and c I will explain how far that security will go under differing circumstances. My best advice is this, if you use a password do not use a dictionary word.
b. Auditing / Cracking
In case you are wondering there is a program called l0phtcrack that locally will decrypt a Windows password. This program will crack most any Windows password in less than two weeks if given the proper circumstances. Due to the nature of this program it must be run on the computer it needs to crack the password of and it must be running under Administrator permissions, which you most likely do. In older versions of Windows such as NT4 this was not the case, but now Windows uses a feature called syskey to further secure your passwords. In any event, this program is able to test your password against dictionary words, hybrid dictionary words (such as "monkey1" or "1monkey"), and can try every possible password combination to gain entry.
On a Pentium 4 2.8Ghz machine with 333MHz DDR RAM (a fairly decent computer) it is able to try 6.3 million passwords a second (or so). Plus due to a weakness of Windows passwords all passwords are divided internally into 7 segment parts (called hashes) that can be "solved" individually. This means an eight character password is solved as a 7 character password and then as a one character password and so provides very little benefit over a seven character password. Likewise, a 14 character password is solved as two 7 character passwords giving you a maximum strength of 7 character passwords. Although, 14 characters would take about twice as long as to solve as a 7 character password, but who wants to remember that? Most likely you would be using a 10 character password (7 + 3), and that provides very little benefit over a 7. In fact, if the person cracking your password guesses you only use letters that means they only need to check against letters. For a one character password that would be 26 possible keys, for two 676 ... up to 7 which is 8,031,810,176 possible keys. Using letters and numbers would be 78,364,164,096 possible keys for a 7 character password and using letters, numbers and all possible password symbols would be 6,722,988,818,432 possible keys for a 7 character password. Now, given our typical 2.8Ghz machine with 6.3 million keys per second this means any 3 character password would be solved in less than one second. For a 7 character letter password it would take at a maximum 21.25 minutes, for letters and numbers it would be 3.46 hours, and for letters, numbers and symbols it would take 12.35 days. But, don't let this bother you too much for reasons covered in section 4c under the fifth policy.
Remotely this would take much longer since you can't try 6.3 million keys a second over a network (more like a few hundred a second, and that's a high estimate) and if you follow the steps below you can disable that threat completely, or at least be alerted when someone attempts it. Later on in section 4 under security policies I will discuss a policy that will eliminate the ability to guess local passwords.
However, with Windows XP there is a feature called "limit local account user of blank passwords to logon only" that disables remote access to a username if it has no password (bravo Microsoft). The result of this default security policy on Windows XP means that any user without a password is safe from network intrusion, at least through the official remote login methods. This is good and it means if you have Windows XP then generally speaking you are safer without a password then with one. This feature for Windows XP is called a security policy and we will cover those in section 4.
Another program exists that you should be aware of so you can protect yourself from it. It is called the "Offline NT Password Reset Utility" and that's a fancy way of saying it can change your password without the need to login or know your previous password. Since the advent of syskey that makes it nearly impossible to crack (guess) a Windows password unless you already have Administrator privileges to a computer, crackers needed a way to gain access to machines still. So, instead of figuring out the password, this program (and others like it such as Winternal's ERD Commander's Locksmith) are able to inject a new password. The Offline NT Password Reset utility requires physical access to a computer and the ability to boot your computer from a CD or a floppy, so if you are concerned about people accessing your system then be sure to secure those access methods.
Windows uses a fixed algorithm to generate the password hashes from what you recognize as your password limiting the complexity of the stored password hash. Some systems will use "salt" or a randomization seed in generating the password hash making the password much more secure (it basically stores unneeded information and that complicates password cracking). This wasn't a problem at all in the past, and isn't much threat for the near future but it does raise some security concerns. A system given enough RAM could store all possible Windows hashes and crack your Windows passwords in minutes, if not less. Both Linux and Mac use 12-bit salt making the effort of cracking the password 4096 times harder. Now, the test of this took 12.6 seconds so it would take around 14 hours to crack any of their passwords on an AMD 2.5GHz processor with 1.5GB of RAM, which isn't that powerful by the standards of high end computers. But, this was only testing for alphanumeric passwords and to crack these passwords would require administrator access to an account on the machine before being able to attempt a crack on other user accounts.
A number of system policies exist to protect the secracy of the stored passwords on a Windows machine, and with Windows XP a great deal of those are enabled by default. However, to further protect yourself you should know about a few password security policies that exist which could protect you further. These are discussed later under local security policies.
Return to top.
3. Administrator Shares
One of the methods for remote access to your system are administrator shares. By default all Windows NT based machines (that includes NT4, 2000 and XP) come with their entire hard-drive shared to the network they are on (in most cases this is the Internet) and are intentionally there to allow network administrators to automate corporate networks (BTW, if you're familiar with Windows shares then they're called C$, D$, etc. for each drive letter you have and share your entire drive, as well as ADMIN$ that shares your Windows folder). The only protection between your hard-drive and the outside world is your username and password. Now, normally the username is accessible from the Internet through SAM enumeration (covered later) as well as a few security policies. So by knowing (or guessing) your username and password an Internet user anywhere else on the planet can access your files. This makes it very important not to use a short password, a dictionary word, or something that someone could potentially guess about you (see the password section above).
This may make your paranoid knowing this, and frankly it should. But, I will let you know a few things that will relax you a bit. Most Internet Service Providers (such as AOL, Charter Communications, Earthlink, etc.) block Windows share traffic (known as SMB traffic) from the Internet at large. Without going into much detail this means that people on the same ISP as you may be able to access your computer if they knew your login information, but most likely not people from other ISPs so the risk drops a great deal. Also, if you're on Windows XP and have no password the risk here is gone (see section 2). However, if you're using Windows 2000 then you better turn this off.
The fix for this is to turn off administrator shares, unless you have a strong password and wish to use this function. Personally I use this ability a great deal at work, but the average user will never wish to use them. The fix for this issue is easy for anyone with a little knowledge of the registry. If you wish to automatically disable then use this file ( ashares.reg ) and run it and on your next reboot you will no longer have this problem to worry about. If you are familiar with the registry then the key for this is a DWORD in HKLM\System\CurrentControlSet\LanManServer\Parameters called AutoShareWks (but, you should set AutoShareServer too). If it's not there then it is set to 1, which is the same as on. If you set it to 0 then this disables admin shares.
Return to top.
4. Local Security Policies
The local security policies on your Windows machine are the systems that you configure to protect your computer from risks, most of which involve local and network intrusion. The most important of these are accessed through the local security settings menu that is accessible through a few different ways. However, the easiest way is by launching the program manually. Since it is just a MSC file in your Windows\System32 directory you can simply go to your start menu, select run and type in secpol.msc and hit the okay button to launch it. You may be interested to browse the options available there, but I discourage altering too much because, as an example, if you remove all accounts from local logins then you've locked yourself out of your computer (you would have to reinstall).
a. User Rights Assignment
The first policy that you should look at is the one called access this computer over the network. This can be found in the secpol.msc (see above) under Local Policies and then under User Rights Assignment. This is a list of all users and groups on your computer that can access your computer remotely over the network. This is not needed for most people, and if you don't use Windows file sharing (please note that KaZaA is not an example of Windows file sharing) then you will want to remove all users and groups from this list. Simply open the policy, select all the items in the list and remove them (in Windows 2000 this looks like a bunch of check boxes, uncheck them). Any user or group in this list represents their ability to connect to your computer unless they are denied permission (next policy). This means any user in this list that knows (or guesses) your username and password could connect to your Windows shares (including Administrator shares discussed in section 3, unless disabled) or otherwise remotely manage your computer.
The second policy that you should look at is the one called deny access to this computer from the network. This can be found in the same location as the previous one. The same rules apply to this policy as those discussed for the previous one, except this is the deny policy for the same thing. Any user in this list is not authorized to access your computer. This means if a username or group is listed in this then they have been denied remote access to your computer even if you granted them access from the previously discussed policy.
The third and fourth policies that you should be interested in are called log on locally and deny logon locally. Like the previous two policies these represent two faces of the same policy. These policies control which users / groups are able to locally use your computer. This means any user that must enter a username and password to access the computer when they're in front of it. You normally want Administrators to have access, but the rest is up to you. Please be very careful. If you remove all users (or deny all users) then no one will be able to login and you will have to reinstall Windows.
The fifth and six policies that I will cover are called allow logon through Terminal Services and deny logon through Terminal Services. The way these work are like the previously covered policies. They allow and/or deny access to Terminal Services. For those not familiar with this function it is a way for you to connect to your computer across a network and use it as if you are sitting in front of it. Previous to Windows XP this was only available on servers (Windows NT4 Server and Windows 2000 Server) and allowed for multiple users to login and use their own desktops independently of each other (Linux users will recognize this like an X-Server or others may recognize it like Citrix, only not as powerful). In Windows XP as well as Windows Server 2003 you are able to use Remote Desktop to use your computer remotely (other such products exist for doing this like Remote Administrator, VNC, PC Anywhere). This can be enabled from the remote tab on system properties (right click my computer, properties) on Windows XP. On Windows XP the current user will be logged off when it is used and for Server 2003 only two remote desktops can operate at a time in terminal server fashion. As you can imagine this is a security risk if you have a weak password so if you don't plan on using this feature then it is best to be sure no users exist in the allow logon through terminal services policy.
The next few policies are for audits. An audit is a type of security check. So, whenever an event that you specified takes place then the system makes a note of that event in your audit log. The audit log is accessed from the event viewer (start menu, run, eventvwr.msc, okay and then check the listing under security (it will be blank if you haven't enabled audits). These can be sound in secpol.msc under local policies and then under audit policy. They can have two states, either success or failure. If enabled for success a log entry will be made when that policy type grants access. Conversely, if enabled for failure a log entry will be made when the policy type denies permission. There is a great deal of audits you can enable, however you normally won't want to audit too much as auditing can make a hit on performance.
The audit policy for audit account logon events responds and audit logon events when users either are allowed to log in or are forbidden access, either locally or remotely. I would recommend setting this for failure as it will alert you when people fail to log into your computer. This would be useful in identifying if a computer on your network is attempting to break into your machine (commonly because they're infected with worms). A success would be useful in identifying if users logging in should be. The difference between the two policies is their scope. Whereas the first focuses on local logins, the second focuses on domains and includes authentication of member servers. If you are not a domain then the second is most likely unnecessary to monitor. Whereas audit account logon events will not log logoffs, audit logon events will.
The audit policy for audit account management responds when users modify accounts, such as creating or deleting a user. Unless you are running a server then leaving this set to no auditing should be fine. Success auditing could be useful in identifying modified / created accounts if your computer is cracked though. Failure auditing could show what users are trying to modify what without the proper permission which could show people sniffing around for backdoors.
The audit policy for audit directory service access responds when the computer is in use as an active directory. For most users this would be useless, but for a server administrator this could show what active directory objects are accessed. Unless there is good reason though this should not be audited because it could potentially slow the computer down a great deal.
The audit policy for audit object access responds when "objects" are accessed. An object is anything that has a security access control list associated with it. This includes files, directories (folders), registry keys, and printers. Under normal circumstances you will not wish to audit this as would degrade performance and complicate the security log a great deal. Useful in tracking down permission problems though.
The audit policy for audit policy change responds when policies (such as these) are altered, successfully or not. This could be useful in identifying if someone is changing security policies on you, whether it is a coworker or a cracker using a particular account to change your security settings to give them easier access. If you are running a server this is perhaps a good idea to use on success because it gives you tracking information on what policies you have altered, otherwise I suggest leaving it be.
The audit policy for audit privilege use responds when a user's privilege is checked against the usage of an item. For example, when you launch the event viewer (eventvwr.msc) it performs a check if you authorized to do so. This is a very broad audit and I would generally recommend not enabling it unless you find a need for it.
The audit policy for audit process tracking responds when a process (a program) is run. This will show you what programs are being used by your computer. This could be quite useful in identifying failed access to programs that a user should have, or in listing used programs on a computer, or in tracking down what user is launching what, etc.. I highly suggest not using this audit under normal usage as it could potentially slow your computer down.
The audit policy for audit system events responds when the system is shutdown or restarted or when an event occurs that affects system security or the security log. This is nice if you want to find out who has been shutting down your server. But, generally you won't need this audited.
c. Security Options
This section of the local security settings contains a great deal of very important security settings. However, this section shows some settings very differently between Windows 2000 and Windows XP so I will attempt to point out the differences. The settings here become even more important if you are using Windows file sharing (SMB) or are a member of a domain.
The first policy here we should discuss is accounts: rename administrator account. This policy allows you to change the name of the primary account on the computer that normally has the login name of "Administrator". When crackers or worms attempt to access a computer they begin by trying several well known account types, the first of which is administrator. If they know the account to be administrator then half the puzzle is solve and they just need to figure out the password. Therefore for security reasons I would recommend renaming this account. You can either do it here or from the user account manager (start menu, run, lusrmgr.msc, okay on either Windows 2000 or Windows XP Professional). When an account that has a profile (normally these are stored in C:\Documents and Settings and contain all the users settings, my documents, etc.) is renamed it retains the same profile path but the username to login changes. This can be remedied by deleting the profile directory for that user when logged in as another user. Remember that if you delete the user's profile directory that all files and registry values for that user will be lost. The way to back it up is through User Profiles's Copy To ability, but I would only recommend this if you know what you're doing. From a remote perspective though it is a good idea just to disable this account and use a different account you've created as an administrator as the internal ID of the primary account is always the same.
The second policy here we should discuss is accounts: rename guest account. This policy works the same way as the last policy, but renames the guest account rather than the administrator account. By default on Windows the guest account is disabled. The guest account has several different abilities. If given permission to access over a network and is enabled (by default it is denied access over the network and the account itself is disabled) then it will give anonymous access to the computer over a network if no password is given to it and blank passwords are allowed for remote access. If given a password then it acts like an account with a password for remote access. This is useful for Windows 9x (95, 98, Me) remote access as they generally authenticate as guest unless given a strict username to login with. If used as a local account and is granted local login privileges it acts like a normal user (same as if a user is added only to the guests group). When a guest user logs out locally their account profile will not be saved and this is very useful for computer lab setups. Also, both locally and remotely the guest permissions are the same as a normal user. Normally this account is fine to just leave disabled and not worry about it.
The third policy under security options that I will cover is network access: allow anonymous SID/Name translation. When enabled this would allow an anonymous user (a user that hasn't yet authenticated with a correct username and password combination) to find the name of a user from a SID or a SID from a name. A SID is a security identifier that represents the internal method of referring to a user. This allows you to make references to a user, then rename the user and leave the original pointers to the user intact, because they referred to the internal SID rather than the external descriptor name. Allowing the translation of SIDs to names and vice versa could potentially compromise a bit of security, so this should be disabled on non-servers. For a list of the SIDs that exist in all versions of Windows please see this Microsoft page.
The fourth policy and fifth policies we will discuss under this section are do not allow anonymous enumeration of SAM accounts and do not allow anonymous enumeration of SAM accounts and shares. From the names of the policies you should have figured out that they are both the same except that the second of the two restricts accounts as well as shares. What both of these restrict is anonymous connections to the Windows IPC$ share. On a safe network it is quite useful to be able to connect to a remote computer and tell what file shares exist on that computer. It also could be useful to detect what user accounts exist on a remote computer. The listing of these resources is called enumeration and on an insecure network this could be a security risk. If an anonymous (non authenticated) user is able to list off the users that exist on a computer then they just need to crack the password for that user to gain access to the resources that the user is able to access, if that user is allowed remote access at all. Likewise, if a cracker is able to list the shares they may gain a reason to try and break into those shares. These policies do not apply for authenticated users so under normal circumstances you will want to enable both of these policies. In the very least you will want the first enabled as there are few reasons to have user account (SAM) enumeration on.
The fifth important policy here is network access: sharing and security model for local accounts. This policy has two options, the first for classic and the second as guest. Classic is the way Windows NT was designed to run with each created account able to remotely connect to the work with their username and password. The second method was introduced in Windows XP to simplify the complicated security model that Windows 9x (95, 98, Me) users were not comfortable with (also called simple file sharing). This makes it so when users connect they remotely register as the Guest account, which makes it much easier for 9x to interface with. In any event this is up to you which mode you wish to use. The classic mode is much more secure, but the guest method could be considered easier as you don't need to fiddle with user permissions on file shares. If you don't wish to use Windows file sharing then I would recommend setting it to classic and then removing all user rights to access the computer over a network.
The fifth policy we will discuss is network security: do not store LAN Manager hash value on next password change. This policy connects well with the issues brought up in section 2 for passwords. Internally Windows NT4, 2000 and XP store their passwords what is called NTLM (NT Lan Manager) that is a security model that Microsoft created for its corporate users. Microsoft never expected the average user to need network access, especially nothing to scale with the Internet. Because of this Windows 9x stored its passwords in an inferior format that was very insecure and easily cracked. Since Windows 9x did not use username and passwords for local usage, and only for network access, it didn't need to store the network passwords since shares on 9x used static passwords. So, network passwords were stored in .PWL files that were cached on logging in.
For network access Windows 9x also used an inferior authentication scheme called LM (notice the lack of NT on its name) that lacked case sensitivity, had a maximum length of 14 characters, and used an inferior algorithm. Microsoft considered this sufficient for the limited networking that Windows 9x would receive, or at least should. However, Microsoft believed that Windows 9x needed the ability to access Windows NT shares and so they used the LM password hashes to authenticate with. Like the old saying goes, something is only as strong as its weakest component and this is no different. Also the LM hash a problem where it divides the password into 7 character segments, which presents a large security risk (for reasons discussed earlier in the passwords section). But, if you do not need compatibility with Windows 9x then there is no reason to store this less secure password hash.
This fixes a large problem with Windows password cracking and makes it take a great deal longer to crack passwords greater than 7 characters, and benefits passwords of all lengths due to case sensitivity. By enabling this policy and changing all passwords on the active system for each user (this will remove all cached LM hashes) you will have taken a large step in securing your machine. However, if you aren't worried about people cracking your Windows password (like if you have none) and if you don't use networking (and have disabled remote connections) then this policy will make no difference to you. Also be aware that setting a user's password larger than 14 characters will cause Windows not to store a LM hash.
The sixth policy that I will cover under security options is network security: LAN Manager authentication level. This policy has several options including send LM & NTLM responses, send LM & NTLM responses - use NTLMv2 session security if negotiated, send NTLM response only, send NTLMv2 response only, send NTLMv2 response only\refuse LM, send NTLMv2 response only\refuse LM & NTLM. As discussed previously LM and NTLM are password hashes, and this policy allows you to select which policy you would like to use in the handshake (handshake being the authentication mechanism) between the server and the client. LM is the weakest of the password hashes and NTLM and for the password only contains upper case letters, numbers, punctuation marks and 32 other symbols, and breaks passwords into 7 segment chunks for a maximum length of 14 characters. NTLM fixes the problem of length and segmentation and NTLMv2 increases the encryption to 128bit. Therefore, you should use only NTLMv2 whenever possible. However, only NT4, 2000 and XP support NTLMv2 (or NTLM for that matter). So, use the scheme that fits you the best. I would recommend setting this policy to use send LM & NTLM responses - use NTLMv2 session security if negotiated unless you have reasons otherwise. This would use LM or NTLM only as fallbacks if NTLMv2 isn't available on the other computer.
Return to top.
5. Running as a Limited Administrator
On a Windows machine there are a number of default permission groups built into the operating system. The regular type of account on a Windows NT (NT4, 2000, XP) based machine falls under the group title of user. This type of account has limited access to the computer and cannot install programs, uninstall programs, change system policies, start or stop system services, add new users, etc. but is able to run programs that aren't disallowed. Another group exists called guest and this is a special form of a user. A guest is a user that is unable to make any permanent changes to a system. Any changes that user with group access makes is discarded after the guest user logs off. The controlling group of these is called the administrator. This group is allowed to do most anything on the computer. The first user created on a Windows NT based machine is a permanent administrator, and this user cannot be deleted (although it can be renamed or disabled from the default name of Administrator). When installing Windows XP all users created from the initial setup will also be given administrator privileges. A group between user and administrator exists and is called a power user. This group is a hybrid admin-user and has the ability to install programs but does not have the ability to override any administrators or create administrator users. If you are using Windows XP Home edition then your account groups are slightly different and only offer a variation on administrator and on user.
Most users that run Windows run it as an administrator, which means that Windows doesn't limit what they can do from a local security standpoint. This is both good and bad. Good because you're free to use your computer without limitation, and bad because any program you run equally has the same freewill as you do. This means that when you run a program, it could potentially wipe all the files on your hard-drive or add files to the system startup behind your back. Everyone running as administrator is one of the reasons that spyware, adware and viruses run so rampant, because one wrong execution and you're completely infected and your computer is actively trying to infect others. Yet, if you were running as a user when you accidentally ran that email attachment that you thought came from a friend, but really came from an Internet worm, the program wouldn't be able to overwrite system files, start itself automatically on the next reboot, or to wipe your hard-drive clean. The problem here is that few people wish to run as a user because it limits them so much.
However, there is a cure. On *nix (this includes all Unix operating systems and Linux distributions) you almost never run as root (this is the *nix version of administrator). There is a great deal of reasons why this is so, and I won't go into detail about *nix security. But, if everyone only has user accounts then how do they install things? Well, the first answer is they don't unless they're the maintainer of the computer, and even then root normally doesn't log in (especially since most *nix logins are done remotely). A command called SU, which means super user or switch user ... depending on the usage) allows you to take on the identity of any other user on the system. So, you could log into your account and then use this command to take on the identity of the root account, giving you the ability to then do whatever you wish. This makes it so you install only what you want to install. You might be thinking that sounds like a pain, but the security benefits reaped from this is great. The first is that things do not get installed without your permission. The second is the less apparent though. Not using root means less computers are vulnerable to attack because of user error, which means less computers are compromised, which means worms and trojans for *nix are very few and far between.
Or you might be wishing such an ability existed in Windows. If so, you're in luck... it does. Microsoft's version of SU is entitled Run As. This ability exists due to a system service called secondary logon, and when this service is enabled you are able to right click on programs and select "run as" then login with the user's credentials you desire (most likely an administrator). This allows you to use a user account and then execute programs as administrator only when you require that ability. Programs can also be executed with alternate credentials from the command line through the runas command, but that's a feature only a handful of people will appreciate. The advantages here are obvious, but of course drawbacks exist. The first is that not everything can be runased. The runas feature only appears when you right click executable files so if you needed to edit a text file that was read only to your account privileges you would have to open notepad with different credentials and then open the file instead of double clicking the text file. The next problem is that not all shortcuts register as linking to an executable. In my eyes this is a huge mistake, so any icon such as my computer or the desktop internet explorer icon don't have the runas ability. And, the last problem is more of an inconvenience than a problem. You can't change credentials for an active program session. Other than that the runas ability is great. You could, for example, walk away from your computer and not worry about your kids screwing things up even if your account is still logged in because they would still require the administrator password. But, this feature isn't for anyone and the majority of the fault lies with Microsoft not working out the features and bugs from the runas system. Listen Microsoft, make it work on everything, give it a keyboard shortcut (hold down CTRL or something and then double click it to get the prompt automatically), and if something you execute doesn't have permissions for you to run it, then popup the runas automatically if the service is running.
A concern was brought up by Steve Gibson on his GRC website that relates to this problem. On his page he brought up the fact that Windows XP introduced a new feature to the Windows product line called raw sockets. Normally the operating system introduces a translation layer between programs and the network it is on that filters dirty and overbearing data. But, new to Windows XP was the ability for a program to override the OS' security measures so that it could send whatever data it wanted to onto the network is resides (in this case we're concerned about the Internet). This means if your computer is compromised by a virus, worm or trojan that your computer can then spoof network data headers (like getting a false driver's license) or denial of servicing another computer (like what a funeral precession does to a road). Normally on other operating systems that have raw sockets they limit access to these "features" by allowing only administrator type accounts to use them, but since the majority of Windows users run as administrator the threat of this being taken advantage of is great. I believe raw sockets are an advantage from a technical standpoint, but from a security standpoint I believe Microsoft should not have implemented this feature on a desktop OS, especially not on XP Home edition.
Return to top.
6. Malware protection (viruses, spyware, adware)
Please see the malware guide for a complete discussion on this broad and complicated subject.
Return to top.
One of the hot topics of Internet security involves firewalls. Most magazines you read recommend that you use Blackice Defender, Zone Alarm or some other firewall software package to protect you from hackers. For those who are not in the know for firewalls, they are simply a hardware device or a software program that blocks Internet traffic based on rules, which can normally be configured. These rules specify certain types of traffic, such as from a specific Internet IP range or specific ports, that are allowed or not. Some firewalls have the ability to filter incoming and outgoing traffic, but most of the time home users are only interested in incoming since you feel your computer is threatened by the Internet and not vice versa. By using a firewall you could block incoming traffic to your computer making it hard, if not impossible to gain entrance to your computer.
What a firewall does is block ports on your computer or a certain type of traffic to your computer. Think of these as virtual access points to your operating system. When an Internet enabled service is installed on your computer it will listen on a particular port. If your operating system receives Internet traffic data that specifies its destined port as one that is assigned to a particular program then the operating system passes that data off to that designated application. If data is sent to your computer that no application is monitoring then your computer either replies back to the computer with an error such as nothing listening on this port, or it drops the data. The former is the proper way for your computer to respond and the secondary is what has been termed stealthed since the sending computer gets no response and as such has no way of knowing if you received the data to begin with. Normally what a firewall will do is ignore data on specific ports or it will ignore data following a specific pattern.
In the current Internet standard there are 65536 ports. These are numbered 0 to 65535 (2^16 bits), although 0 is considered an unused port and is rarely addressed from the outside. In fact, if a program asks to open port 0 the operating system usually intreprets this as "I will assign a free port and tell you what I assigned". On a *nix machine the first 1024 ports are designated as reserved for the root user of the machine, so that you can be sure that standard services such as FTP (port 21), HTTP (port 80), etc. were setup by the administrator of the server rather than by a standard user on the system. This isn't true for a Windows machine though and all ports on a Windows machine can be opened by any authenticated user of that system. Using what is called a port scanner you can initiate a connection to every port on a remote computer and you will get a response if you established a connection on that port. Since certain ports are understood to be on certain ports, such as the web on 80, you can detect what open ports are on a system and then from the port number you can guess as to what the port is used for, if it doesn't return you with easily identifiable information when connecting. Please note that you can run a webserver on any port, or a FTP server on any port, but then in the URL for it you would have to identify the port. For example, http://www.vernalex.com runs on port 80, but if it ran on port 81 then you would have to use the URL http://www.vernalex.com:81 instead to identify the nonstandard port it uses.
Now, the problem with firewalls is the cost versus benefit. While using a firewall, either a hardware or software one, can almost guarantee your computer will not be cracked. However, this comes at a large (and annoying) cost. Since a firewall blocks ports this means that the service provided by that port is also blocked. This means if you are running a web server on port 80 and your firewall blocks port 80 then no one will be able to access your HTTP (web) server. This would defeat the purpose of running the server at all. This means that you will have to make sure that in your firewall rules that you block what you want to block, and not what you don't want to. So, why run a firewall at all when you could just disable the open ports? That's a very good question, but the problem remains that Windows opens a great deal of remote ports that you can't disable, and you may not even know what they are. If you are interested in seeing your current connections drop to DOS and use netstat (start menu, run, cmd, okay, netstat -an). This will show you all the connections you have going out and coming in to your computer. Also, firewall programs have the annoying habit of popping up questioning messages every time you receive a port request asking if you would like to allow the behavior.
In a corporate environment users will not need to run a personal firewall such as Zone Alarm because their network will be (or should be) equipped with a hardware firewall. These are used by businesses to filter the traffic their private network receives or gives to the Internet. This allows them to make sure their employees only can visit certain websites, that they can only use specific services (such as outgoing web access and not KaZaA or AIM), and assures them that viruses cannot penetrate their administrated network. This is good from the perspective of the network administrators, but not always from the employees that have their network access limited. Corporate networks may also make use of the Windows firewall built into Windows XP as it provides local computer security in addition to the intranet being equipped with its own firewall to protect it from the Internet. The Windows firewall is the best firewall for large scale deployment because it can be modified through group policies.
Personally I prefer to using a home router. My favorites are the Linksys routers with the BEFSR41 being the most common of theirs. These allow you to share a home broadband connection (only a few work for dialup) through a technology known as Network Address Translation (NAT). What I find is funny is how Linksys, SMC, Netgear, Microsoft, Cisco and the other router brands offer their products as a firewall, but the fact is that is more of a flaw than a feature. The reason they consider them firewalls is because these home routers take a single Internet (WAN) IP address and split it into many personal (LAN) IP addresses. From the perspective of the Internet your multiple computers only have a single IP, and in fact they see your router as the culmination of all machines on your home network. From the perspective of your home computers you see the Internet normally and can connect to any Internet site as you would if you were directly connected to the broadband modem.
But, the problem here is when an Internet computer attempts to make a connection to your home computer. An example of this would be if you are using AIM and a friend on AIM tries to send you a file. With the AIM standard your computer will open a listening port, normally between 5900 and 6000, and the person sending the file will attempt to connect to that port so they can send you the file. However, when they attempt to initialize a connection to your Internet IP address your router receives the response. Since there are multiple computers on your home network your router does not know which computer the data it received was meant for, so it discards the data and your file transfer times out.
The way around this problem is through router traffic rules. These are called different things by different routers, but they all do the same thing. Basically, you tell the router what ports it should forward to what computer on your home network. This is a hack to say the least because that means only a single computer on your network can respond to that particular port number. To explain this better say you had two computers attempting to run FTP servers on port 21. With this model you could only have your router forward the incoming port 21 request to one of the two computers. The way around this is to use a nonstandard FTP port for one, but that's annoying. Many routers also have a feature called DMZ host. This allows your router to forward all incoming port requests to a particular computer on your network. This defeats the firewallesqe bevavior of your router, but it means you don't have to forward particular ports or port ranges.
So, the bottom line is that yes a firewall can secure your computer. But, it's more important to secure your computer by keeping your Internet listening software up-to-date, by disabling unneeded Internet services, and by limiting network access through security policies. If you are using Windows XP then I would highly recommend the firewall built into the networking options as it's easy and centralized. And if you're using broadband that it may be a good idea to use a home router even if you have a single computer on your home network.
Return to top.
8. System Services
In Windows there are several places where programs can be set to startup when your computer boots. One of these places, and also the most important one, is the system services. These can be found in the Services Console (start menu, run, services.msc, okay). The services console should present you with a list of all services, and they can be organized by name, by startup type, by their current running state or by other less relevant things. When you double click an item it should pop up a dialog with other important data pertaining to it. From here you can start and stop the service, as well as change its behavior on Windows startup. The purpose of a system service is to provide shared functionality, such as Internet connectivity that any Internet enabled program can use. The benefit of these services, as opposed to other startup locations, is that they have the ability to run even before you have logged into Windows. In *nix the name for these are Daemons, but they provide the same functionality.
All Windows NT based operating systems (NT4, 2000, XP) have system services, but Windows 9x based operating systems (95, 98, Me) do not since they don't have the ability to really log into them. On Windows NT systems the system services contains some very important startup items, and for this reason you need to be careful. By disabling a system service you could be removing a critical system function. However, many services provide features that you won't want to use and take up RAM/CPU time, or will leave your computer more vulnerable to cracks. For this reason it is a good idea to shut down these services. For a complete list of services, their functions and what I recommend you do with them see my services tool. For more complete explanation of services I would recommend that you read the services part of my components guide.
Each service has three startup modes. The first is automatic. This means that when your operating system first loads it will run that particular service, or at least try. This means that the functionality of that service is available when your OS is booted. The second is manual. This mode means that the service is not started on boot but starts when required. So, if program requires that service it will start it and then use. Sometimes after the program is done with it the service will be stopped, thus freeing the resources it was using. Sometimes services are always considered needed and by setting them to manual they will be started on startup because some other service or another program wanted it running even though it may not require it. The third is disabled. This means that the service can't be started even if a program requires functionality from it, and it can't be enabled by the operator unless very set to manual or automatic. There is no benefit of disabled over manual if the service isn't requested to start by another process, so normally you should set it to manual unless you know it's not needed or you don't want it.
The first service I will talk about is the messenger service. This is an especially annoying service since a few nasty spammers have taken upon themselves to make a quick buck. The purpose of this service is so network administrators on corporate networks can send you text notifications through a popup message and so the alerter service can send out text notifications. These messages are for things such as, "the file server is going down for a reboot and will be back in a few minutes." So, this service isn't really meant for the home user but in Windows this was enabled even for the home users for some reason. I would like to point out that this service is in no way connected to Windows Messenger, the chat program. And, I would recommend disabling this service unless you know you need it.
The second important service I will present is the remote registry service. Once again this service was designed for corporate networks so that network administrators could remotely control your computer. This service gives direct control to your registry from a remote control if they know your username and password. Your registry is the central repository for all system information; including installed programs, your system services, email settings, etc.. For obvious reasons this is a security hole and should only be enabled if you require it. Therefore, disable it if you're not on a corporate network. And if you want to better understand the registry then please read the registry chapter of my components guide.
The third service that is a potential security risk is the SSDP Discovery Service. The SSDP Discovery Service provides Universal Plug and Play to Windows. UP&P is much like ordinary plug and play, but instead of detecting devices connected to your computer directly it detects devices through the network. A good example of this is the Microsoft family of routers. When you connect your computer to a Microsoft router your computer will detect the router through a series of probes and then the router will be automatically installed on your computer. The danger here is that your computer seeks out devices on a network that represent themselves as something your computer wants to install, but this is a very serious security risk. For this reason I would strongly recommend disabling this service unless you require it.
The fourth service is called Terminal Services and you may want to disable it, unless you want the functionality is provides. The purpose of this service originates with the Windows server line and allows you to connect to Windows operating systems running as terminal servers to host your desktop. This is a similar concept to that of an X Server for *nix or a Citrix server or a mainframe, allowing you to use your computer as a dumb terminal. With Windows XP the functionality of this service was extended beyond the server line, allowing you to remotely control your computer across the Internet using Remote Desktop. When this service is enabled, when Remote Desktop is enabled, and when you have allowed users or groups through the allow logon through terminal services a user will be able to log into your computer as if they were sitting in front of it. This presents a large security risk if you have a weak password, so unless you intend on using this feature I highly recommend disabling this service.
Return to top.
9. Windows Management Instrumentation (WMI)
Windows Management Instrumentation (WMI) is one of those things that is extremely useful, but for the most part unknown, and definitely not needed for the majority of users. For network administrators out there that wish to remotely manage a network of WIndows machines WMI would be a supreme time saver. It provides a scripting API that allows you to interface with computers on a network and do everything from list services to run a program remotely. For those of you that have never programmed before, an API is a programming layer that allows the programmer to manipulate the desired device without having to speak to the device directly. This simply means that a layer of protection is added between the programmer and the device. So, if the device's version is every changed then the API commands would remain the same even if the function of the device changed. This not only protects the device from unwanted tweaking, but also protects your programs from breaking if an upgrade occurs.
As you may have guessed the features provided by WMI could be considered a security risk. Since WMI allows remote probing and execution any user that can be authenticated through a username and password with the proper security that user would have compromised the security of the computer. Plus besides the security concerns the WMI logger has been known to immensely slow down computers if the WMI engine gets caught in a error loop. For these reasons I would highly recommend disabling this feature unless you are on a corporate or managed network.
Return to top.
10. Web browser settings
For maximum security you should either secure Internet Explorer or use an alternate web browser that is less common. Please also see the updates section of this guide to learn how to patch your browser(s). If you running other browsers such as Mozilla, Netscape, Mozilla FireFox, or Opera then you have little to fear as long as you keep fairly up-to-date with the versions.
If you are running Internet Explorer then you have some issues to think about. And even if you use an alternate browser doesn't mean you shouldn't keep IE safe since IE is a part of Windows that can be used by other programs or by Windows itself.
In Internet Explorer there are things called security zones. These allow you to set settings for different websites that you trust on a linear scale. The least trusted is called Restricted zones, then Internet, then Local intranet and then Trusted sites. Restricted zones represent websites that you manually specify and this allows you to set websites such as "gator.com" (makers of adware) as untrusted and you can apply very restrictive settings to those sites. The Internet zone is for websites that you don't know if you can trust or not, and as such you want fairly generic security that doesn't let one slip passed you, but doesn't make the Internet useless. The Local intranet sites represents websites on your local network (such as a corporate network, this doesn't apply really to home users except for their ISPs website) and you normally set less restrictive settings than you would for normal websites. The Trusted zone is for websites that you trust explicitly. Normally you would apply these to websites that you know you can always trust. Be careful though because some websites display content that are from external websites and a good example of this would be an email provider such as Yahoo or Hotmail.
To access the security settings for scripting open an Internet Explorer window. Then select the Tools dropdown and then select Options. The menu that opens up can also be accessed from the control panel's Internet Options icon. Under the Security tab the security zones are listed. If you select one of the zone icons you can then either edit the settings for that zone through the custom level button or use the default level button to return the settings for that zone to the default values. For Restricted and Trusted sites you can specify which websites you trust or don't. For Trusted sites you will want to uncheck the box for require server verification (https:) for all sites in this zone to make it more usuable.
From any of the custom level dialog pages you can select individual options for how much you trust the sites in that zone. You can also reset custom settings to one of several templates. By default Restricted is high, Internet is medium, Intranet is medium-low and Trusted is low.
I would suggest resetting the security the Internet zone to medium and then scrolling down to the scripting section and setting advanced scripting to either disable or prompt. If this option is set to disabled then any site not in the trusted sites will not execute scripts. If this option is set to prompt then you will be asked anytime a website attempts to execute a script that is in that zone. It is a better idea to set this to disabled and any site you need to function properly that you trust should be added to the Sites list for the Trust sites. If you set it to prompt you may just ignore the warnings. In any event this setting will save you from a lot of security problems in the future and it will give you peace of mind.
The other setting option that I would suggest you change is Internet Explorer's Install on Demand. This is a feature that brings up the largest security risk for Internet Explorer, besides not keeping the browser up-to-date. The purpose of this feature is to install applications automatically from a website and featurewise this wasn't a bad idea. The programs that are expected to beinstalled from this are normally web browser plug-ins such as Macromedia's Flash or Shockwave or RealPlayer or Apple's Quicktime. However, this feature makes it too easy to install applications from untrusted websites just by visiting a website and clicking the okay button of the often ignored security warning that Internet Explorer gives. Most spyware and adware are installed from this feature proving that this is feature isn't worth the problems it creates.
I would suggest disabling this feature until such a point that you believe you need it on a website that you trust personally. This is fairly easily done too. From an Internet Explorer window go to Tools and then Options. The dialog box that pops up can also be found in the Control Panel under Internet Options. From the advanced tab you will find a lot of options, but find the option called "Enable Install On Demand [Other]" and uncheck the box to disable automatic plug-in installation. Disabling this feature will save you from installing a great deal of programs that you don't want. And this is even more important if you have kids in your household as they're infamous for clicking yes on these boxes. I would suggest installing plug-ins using the tried and true method of downloading and manually installing as this reduces the security risk by a good degree.