General Operating System Security

Although every operating system is different, there are a number of fundamental security practices that apply to all systems, regardless of vendor. In this section, we examine some of the “best practices” that transcend vendor constraints and benefit all system administrators.

Patches, Service Packs, and Hot Fixes

If you take a few moments to browse through the security bulletins published by operating system manufacturers and computer security organizations, you find that there are hundreds of known vulnerabilities for almost every operating system in existence today.

Unfortunately, these bulletins are available to “white hats” (security professionals) and “black hats” (malicious hackers) alike. Vendors and organizations must carefully balance providing enough information for administrators to safeguard their systems against the risk of providing hackers with sufficient detail to exploit the vulnerability. More often than not, automated exploitation scripts appear at hacker Web sites soon after a security alert hits the Internet.

For alert administrators, this is not a problem. They quickly download and install the necessary patches as soon as they become aware of the threat (usually from an automated mailing list they subscribe to, such as the ones listed in Chapter 7, “Intrusions, Attacks, and Countermeasures”). However, many administrators are overworked and simply don't place a high priority on maintaining the most recent patches for all the software installed at their location. Hackers using automated scripts quickly find these vulnerable sites and exploit the vulnerabilities.

For this reason, it's critical to keep abreast of security patches, service packs, and hot fixes issued by vendors and apply those appropriate for your environment. Microsoft realized the complexity of this task and released a free utility in late 2001 called the Microsoft Network Security Hotfix Checker (HFNetChk), which automatically scans an entire network for unpatched systems from a central location. One of the most important features of this tool is that it connects to the Microsoft Web site at each execution to retrieve an XML file with up-to-date patch-level information. This tool works with the Windows NT and 2000 operating systems, as well as Internet Information Server (IIS), SQL Server, the Microsoft Data Engine (MSDE), and Internet Explorer.

Password Policies

As you learned in Chapter 7, hackers use a variety of techniques to penetrate the security of systems that use weak passwords.

There are several general principles of password security that apply to all operating systems and applications. First, remember that it is essential for your password to be difficult to guess, even for someone who knows you well. This rules out common choices such as a birthday (your own or that of a family member), phone numbers, house numbers, or even portions of your Social Security number. Similarly, you should never use your user ID or any variation of it (such as reversing the letters) as your password.

IN THE FIELD: COMMONLY USED PASSWORDS Many hackers (both “white hats” and “black hats”) and psychologists publish studies detailing the reasons people choose passwords and the manner in which they reflect on the individual. If you're curious, spending a few minutes researching this topic on the Internet yields very interesting results. The following is a partial listing of the most common passwords among Internet users. The results aren't surprising when you consider that many people use a word that's important to their day-to-day life. password god sex money secret

It's equally important to never use a dictionary word as your password. One of the most common passwords in use today is, believe it or not, “password.” Hackers (and their tools) are wise to many other common variations, such as

• Combining two words to form a password (for example, “dogcat”)

• Spelling words backward (for example, “esrever”)

• Using the username as the password

• Substituting the number 0 for the letter o (for example, “d0g”)

• Substituting the number 1 for the letter l (for example, “app1e”)

• Appending a digit to a dictionary word (for example, “dog1”)

• Appending the year to a dictionary word (for example, “dog2002” or “dog02”)

Many operating systems incorporate features that strengthen password security by implementing additional security controls. Some of these features and policies include

• Minimum Password Length. Ensures that passwords are long enough to create sufficient cryptographic security.

  WARNING

  Check the Default Minimum Password Length Many operating systems and applications that utilize passwords ship with a default minimum password length of zero. This allows users to have a blank password—a major security mistake. Be sure to check this default value when installing a new system. Most administrators require a minimum of either six or eight characters. Higher minimum values yield more secure systems but increase the likelihood of complaints from annoyed users.

  
  

• Password Aging. Limits the amount of time that a user can go without changing passwords. For example, if a system implements a password-aging policy with a 30-day limit, users are forced to change their password every 30 days.

• Password Uniqueness. Works hand-in-hand with password-aging policies. They ensure that users don't repeat passwords in a cyclical manner. Without a password-uniqueness policy in place, password-aging policies become ineffective. Users could simply change their passwords when they expire to satisfy the password-aging policy and then immediately change the password back to its original value. Password-uniqueness policies are measured in either days (a password can be used only every X days) or cycles (a password can be repeated only after X other passwords are used).

  NOTE

  Mnemonics Memory tricks are a great source of secure passwords. One way to accomplish this is to make up a sentence that you'll remember and use the first letter of each word as your password. For example, “My dog Hunter eats delicious food every Sunday” becomes “MdHedfeS,” a strong password. Another fun password is “ne14+10s?” which corresponds to the sentence: “Anyone for some tennis?” (If you can't figure this one out, try to say it out loud.)

  
  

• Account Lockout. Helps prevent brute-force password-guessing attacks against a system. They specify a threshold number of unsuccessful logon attempts that may occur before the account is locked out of the system for a predetermined period of time.

• Complexity Rule. Dictates specific alphanumeric requirements for passwords. For example, complexity rules might require that each password contain at least one uppercase character, one lowercase character, and one digit or symbol.

We've covered a lot of rules that restrict users' choices for good passwords. Be careful when crafting specific policies for your own systems. You don't want to make your password policies so stringent that they force users to write down their passwords on a piece of paper that may be subject to Dumpster diving or other physical attacks. For this reason, it's a good idea always to let users choose their own passwords rather than have security administrators assign “secure” passwords to them.

“Out-of-the-Box” Security

No matter what operating system you use, it's a general truth that it will be insecure when you take it out of the box and turn it on. Operating systems more than a couple of years old (such as Windows NT and Unix) were not designed with security in mind. They contain serious security flaws that you must address before placing the machine on a production network.

More recently developed operating systems (such as Windows 2000) do contain wonderful built-in security features and ship in a locked-down state that eliminates many security holes. However, this does not relieve your burden. This lockdown really ensures only that you won't be running unnecessary services on your system or have default accounts enabled. You still need to visit the vendor's Web site and check for relevant security patches or hot fixes that address pressing security vulnerabilities that developed after the operating system shipped.

Patches, Service Packs, and Hot Fixes

Review the previous section on this topic. As discussed during the introduction to this section, it's critical to apply security patches to any new system introduced to your network. Don't assume a system is safe because it contains the most recent version of the operating system. Check the operating system vendor's Web site for newly released fixes, even if your hardware vendor assures you that your new system contains all the recent patches.

Known User Accounts

Many older operating systems and applications (and even some modern ones!) ship preconfigured with one or more administrative accounts. Vendors provide these accounts to facilitate the installation and configuration process for system administrators. Normally, the system documentation contains the username and password combinations for these accounts and urges administrators to change them immediately upon installation. Unfortunately, many administrators fail to change the passwords on these accounts or delete them after completing the installation process.

Recently, software vendors realized the grave threat these accounts pose to system security and it's rare to find such flaws in newly released products. However, many legacy products sitting on the shelves in IT shops around the world still contain these flaws. For example, all versions of Microsoft SQL Server prior to SQL Server 2000 contained no default password for the all-powerful 'sa' account. The security community recognized this flaw many years ago but it continued to appear in release after release of SQL Server.

Unfortunately, a SQL Server worm (see Chapter 7, for a discussion of worms and other malicious code) surfaced in November 2001 that exploited this vulnerability. The SQL worm scanned IP address ranges for systems running SQL Server on port 1433 and then attempted to connect to those systems using the 'sa' account with a blank password. It then configured the system for use as a relay site in distributed denial-of-service attacks directed against third-party systems.

Ideally, software manufacturers would carry the burden of ensuring that operating systems and applications don't contain default accounts. Unfortunately, there are too many products on the market today that contain these gaping vulnerabilities and the task of avoiding these pitfalls now falls upon the shoulders of overworked system administrators.

Disabling Unused Services

For obvious reasons, operating system manufacturers love to pack their products with many diverse features. A decade ago, most operating systems supported a few basic services—FTP, SMTP, Telnet, HTTP, and a few others. Today, the acronym soup is waist-deep with the addition of SNMP, WAP, DHCP, IRC, and many others. Each one of these services adds additional vulnerabilities to the machines on which they run.

Frequently, the default configuration for an operating system enables as many of these services as possible. This increases the “out-of-the-box” usability of a system. Administrators can have a new box up and running supporting a number of necessary services in a matter of minutes. Unfortunately, this also leads to a growing number of systems connected to the Internet running services that lie dormant, unnoticed (and not maintained!) by system administrators until a hacker stumbles across the unused service and uses it to penetrate a network and launch a massive assault.

It's extremely important that you constantly monitor the services running on your network. If you're going to maintain a secure computing environment, it stands to reason that you must know what services run on the network you're attempting to secure. One extremely useful utility that assists with this task is the nmap program available for various Unix-based operating systems. This tool sends out a variety of cleverly designed network packets that probe all the systems on a network and determine the following characteristics of individual systems:

• Operating System in use

• OS version and patch level

• Services/ports active on each system

• Usernames bound to each service

• Port filtering techniques in use

• DNS names of each host

Nmap is an extremely valuable tool and should be a part of every security administrator's toolkit. If you're not running a Unix system, you may also want to use NmapNT, a Windows port of this popular tool. Administrators merely need to set up a single box to run nmap scans of an entire network. It's a good practice to run a baseline scan and then investigate each of the services running on your network, taking the time to eliminate any unnecessary/undesirable services. That task is admittedly somewhat monumental but the baseline it provides proves very useful. Administrators should run future scans on a periodic basis and compare those scans to the baseline. The only analysis required is a comparison of the new scan to the baseline and an investigation of any new services that appeared since the last scan.

Establishing Audit Policies

Proper system audit policies provide critical information to administrators investigating security breaches or troubleshooting system failures. All modern operating systems make provisions for some degree of auditing, including tracking system logons, file activity, and other system events. Most allow administrators to specify that they want to audit all attempts to use a privilege or only to audit successful/unsuccessful attempts on a user, group, or systemwide basis.

Security policymakers should establish an enterprisewide audit policy that specifies a minimum level of auditing for all systems connected to the network. This ensures collection of a baseline level of information throughout the organization. Critical and/or sensitive systems might impose more stringent auditing requirements, as needed.

OS-specific auditing procedures are discussed in the “Windows Security Basics” and “Unix Security Basics” sections of this chapter.

File/Folder Sharing

Prior to the mainstream implementation of local area networks (LANs), computer users took advantage of the “sneaker net” (transferring files onto a floppy disk and physically transporting them to another system) to share files. The advent of the LAN and the network operating system (NOS) eliminated the need for these “sneaker nets” by allowing users to share files and folders between computers over a high-speed network connection.

Network operating systems generally offer two different file-sharing security options:

• Share-Level Security. Controls access to network resources (files, folders, printers, and so on) using a single password shared among all authorized users. This level of security is easy to implement and maintain but provides extremely limited auditing capability because it does not identify individual network users. Workgroups and other decentralized networks often use this type of security. Under share-level security, users typically control access to resources on their local systems.

  WARNING

  File Sharing Is Dangerous! Many operating systems ship with file sharing enabled as a default option. Furthermore, many uneducated users activate the file-sharing features of their operating systems without realizing the full impact of this decision. Be sure to audit systems regularly for unauthorized file-sharing activity.

  
  

• User-Level Security. Allows assignment of network resource access privileges by user and/or group. User-level security provides much more detailed auditing capabilities because it tracks activity by individual user. Under the user-level security model, network administrators typically control access permissions for resources located on dedicated servers.