Security+ Certification Training Kit

Author Microsoft Corporation with Andy Ruth and Kurt Hudson Pages 512 Disk 1 Companion CD(s) Level All Levels Published 01/29/2003 ISBN 9780735618220 Price $59.99 To see this book's discounted price, select a reseller below.	More Information About the Book Table of Contents Sample Chapter Index Related Series About the Author Support: Book & CD Rate this book

Chapter 8: Security Baselines

• About This Chapter
• Before You Begin
• Lesson 1: Network Device and Operating System Hardening
• Network Device Updates
• Operating System and Application Updates
• Securing Networking Components
• File System Security
• Operating System Hardening
• Exercise: Using MD5
• Lesson Review
• Lesson Summary
• Lesson 2: Server Application Hardening
• Web Servers
• FTP Servers
• E-Mail Servers
• DNS Servers
• File and Print Servers
• DHCP Servers
• NNTP Servers
• Data Repositories
• Exercise: Port Matching
• Lesson Review
• Lesson Summary

Chapter 8   Security Baselines

About This Chapter

Before You Begin

Lesson 1: Network Device and Operating System Hardening

• Explain the importance of applying network device, operating system, and application updates
• Verify the integrity of security updates
• Locate and download security baseline information for various platforms
• Locate sources for security vulnerability alerts

Estimated lesson time: 60 minutes

There are many specific recommendations and guidelines available for a variety of operating systems. You can review and download security baseline information and related software tools from the following sources:

• Computer Emergency Response Team (CERT) Web site at http://www.cert.org/tech_tips
• CIS Web site at http://www.cisecurity.com
• United States National Security Agency (NSA) Web site at http://www.nsa.gov (see Security Recommendation Guides)
• National Information Assurance Partnership (NIAP) Web site at http://niap.nist.gov
• Computer Security Resource Center (CRSC) of the National Institute of Standards and Technology (NIST) Web site at http://csrc.nist.gov
• National Computer Security Center (NCSC) Trusted Product Evaluation Program (TPEP) at http://www.radium.ncsc.mil/tpep
• Microsoft Web site at http://www.microsoft.com/technet/security/tools/Tools

Network Device Updates

To protect your network devices, be sure to monitor communications from the vendors of those devices for information on new security patches. You should also monitor security newsletters and alerts for information on new exploits. The CERT is probably the most well-known security alert system. In addition, CERT publishes a list of other information sources on its Web site at http://www.cert.org/other_sources.

Verifying Updates

Before you install a security update, you should verify that it is authentic and not corrupted. Verification usually involves checking a digital signature or checksum to verify the authenticity of the patch. A checksum (or hash) is a computation applied to a file that results in a string that can be used to check the integrity of a downloaded file. Figure 8-1 illustrates an example of a Message Digest (MD5) checksum. Three files, all named Code.txt, exist in three different directories—test1, test2, and test3, as shown in the directory listing. All the files have the same date, time, file size, and name. However, they don't all have the same MD5 hash value because they are not all the same. The Code.txt file in the test2 directory is different than the other two files, as shown in the MD5 command hash values.

Click to view graphic

Figure 8-1 MD5 signature verification

Pretty Good Privacy (PGP) can also be used to verify file downloads. Figure 8-2 illustrates signature verification with PGP. The first Code.txt file was modified after the signature file was created and therefore shows up as a bad signature. The second file in the list is intact and therefore shows up with a proper time and date.

Click to view graphic

Figure 8-2 PGP signature verification

If an attacker compromises a vendor Web site, the attacker could feasibly post a Trojan horse in place of a security patch. Many vendors now digitally sign or compute a hash value for security updates, so that you can ensure the update's integrity. Be sure to check that signature or security hash before you install security updates.

Maintaining an Archive of Updates

No matter how you receive updates for your applications, network devices, and operating systems, you should consider building an archive of update files. Maintain all of the updates that you must apply for each type of software and hardware your organization uses. This allows you to quickly reapply updates when new systems are brought in or existing systems require reinstallation.

Testing Updates

Always test updates on nonproduction systems, if possible. This allows you to determine if the update performs properly before you load it onto your production devices, because software vendors can rarely guarantee that updates won't break other applications that you might be using on a production computer. If you don't have a test system for trying out patches, make sure you have an action plan for restoring your production systems if the security patch causes a problem.

Applying Updates

After you verify and test updates, apply them as soon as possible. The actual process for applying firmware updates varies depending on the product and vendor, but typically it is not much more involved than downloading and running a file from the vendor's Web site.

If an exploit is discovered and an update is not available, you might have to follow a workaround. For example, if an exploit for Dynamic Host Configuration Protocol (DHCP) is discovered on a router that supports DHCP, you might consider disabling DHCP on the router and enabling it on a device that doesn't have the same vulnerability. Once the security patch is available, you can decide whether you want to return to the original configuration.

Operating System and Application Updates

Checking for Updates

Almost every piece of software and hardware that your organization has is likely to be updated at some point. As with firmware updates, you must stay attuned to appropriate information sources (such as your software vendor's Web site or an alert list) so that you know about exploits when they are discovered and fixed.

Operating systems in particular are likely to be updated routinely. Updates are so frequent that many software vendors have worked to simplify the process of finding and installing updates. For example, CERT lists scanning tools on their Web site list of security tools under the heading "Tools to Scan Hosts for Known Vulnerabilities," located at http://www.cert.org/tech_tips/security_tools.html#D. Two of those scanning tools are Internet Security Scanner (ISS) and Security Administrator Tool for Analyzing Networks (SATAN). Other examples of scanning tools include the Microsoft Baseline Security Analyzer (MBSA) and the Microsoft Network Security Hot Fix Checker (HFNetChk).

Automated Updates

Many software vendors are providing methods for receiving and applying updates automatically. Many virus scanner vendors offer automated programs for updating virus definition files. Microsoft offers an automatic updates program called Software Update Services for many of its operating systems. These automated updates can be configured to automatically download updates from the vendor's Web site on a regular schedule or whenever they are available.

Securing Networking Components

Disabling Unnecessary Network Services and Protocols

People often speak of disabling unnecessary "services" and "protocols" interchangeably. This is because services and protocols often have the same name. For example, the Simple Network Management Protocol (SNMP) is by name a protocol, but it is also a service. SNMP is typically used for remote management of hosts on a TCP/IP network. As a service, SNMP communications occur by default over User Datagram Protocol (UDP) ports 161 and 162. As a protocol, SNMP communicates according to standards documented in Request for Comments (RFC) 1643. (RFC articles can be found at http://www.icann.rfceditor.org.)

A network service is a program used to provide some function for another computer or device on the network. Network services are often generically referred to as services. Many operating systems install and enable services by default that might not be necessary or appropriate on your network. Of course, the necessity and appropriateness of a service depends on the role that the computer is performing. For example, CERT Advisory CA-1996-01, "UDP Port Denial-of-Service Attack," (also CVE-1999-0103) warns of a denial of service (DoS) attack directed against two UDP services: chargen and echo.

Most network operating systems allow network administrators to list the services that are active on the system. In Microsoft Windows, UNIX, and Linux systems the netstat command can be used to provide a list of network connections and listening ports over which services are provided. Figure 8-3 shows the netstat command and appropriate command-line switches to show all listening TCP and UDP ports in numerical order.

Click to view graphic

Figure 8-3 Netstat on Windows 2000 Professional

You can usually find a list of services and ports in the Services file. This file is located in different places on different operating systems. On UNIX and Linux operating systems, the file is commonly stored as the services file in the /Etc directory. Microsoft Windows 2000 and Microsoft Windows XP operating systems store the services file in the %systemroot%\System32\Drivers\Etc folder. You can view and edit the Services file in any text editor program such as vi, Emacs, or pico in UNIX/Linux operating systems or Notepad in Microsoft Windows operating systems.

Once you figure out what services are running on your system, you should disable all unnecessary services. In UNIX and Linux operating systems, disabling services is typically done by editing the /Etc/Inetd.conf or /Etc/Xinetd.conf files. To disable a service in Inetd.conf, you add a pound sign (#) in front of the line referencing the service. An excerpt of an Inetd.conf file is shown here with the echo and chargen services disabled:

#echo       stream    tcp    nowait    root     internal
#echo       dgram     udp    wait      root     internal
discard     stream    tcp    nowait    root     internal
discard     dgram     udp    wait      root     internal
daytime     stream    tcp    nowait    root     internal
daytime     dgram     udp    wait      root     internal
#chargen    stream    tcp    nowait    root     internal
#chargen    dgram     udp    wait      root     internal

Once you have disabled all the unnecessary services, you must restart the inetd program so that it reads the edited Inetd.conf file. Depending on the specific distribution of UNIX or Linux, you might do this by typing killall -HUP inetd. The preferred technique for accomplishing a restart of inetd might be different in your specific operating system, so consult your documentation.

In Microsoft Windows operating systems, disabling specific services can be a bit more complex because you need to know which software applications are providing which services. For example, consider the following list (excerpted from Figure 8-3):

Proto   Local Address
TCP   10.200.200.153:139
UDP   10.200.200.153:137
UDP   10.200.200.153:138 

All entries in this list are associated with NetBIOS over TCP/IP services. If you have no need for NetBIOS over TCP/IP services, you can disable them through the Advanced TCP/IP Settings dialog box by clicking the WINS tab, and then choosing the option to disable NetBIOS over TCP/IP, as shown in Figure 8-4.

Click to view graphic

Figure 8-4 Disabling NetBIOS over TCP/IP in Windows 2000

In addition to disabling unnecessary services on the clients and server operating systems on your network, you should filter unneeded services at the firewall. As mentioned in Chapter 4, you'd be wise to use a default-deny rule on the firewall and enable only needed services.

Removing Unnecessary Programs

The Melissa virus (described in Chapter 6) was targeted at systems running Microsoft Word and Microsoft Outlook. The Melissa virus would not have affected someone who didn't have Word and Outlook installed. The more programs you have installed and running on your system, the greater the likelihood that someone can create or find an exploit for one of your programs.

To reduce the risk of compromise on your network, you should remove all unnecessary programs from every device on your network. Most operating systems provide a method for you to determine which processes and applications are running. UNIX and Linux systems have the ps command that can be used to list running processes. In Microsoft Windows operating systems released after 1995 (including Microsoft Windows 95, Microsoft Windows 98, Microsoft Windows Me, Windows 2000, and Windows XP) you can hold the Ctrl, Alt, and Delete keys simultaneously to activate the Task Manager. In Windows XP, you can also use the tasklist.exe command to view processes on local and remote computers from the command line.

Once you have listed all of the running processes, you can determine if they are necessary. Determining which processes are actually necessary depends on many different factors. Later in this lesson and in the following lesson we cover some of the guidelines that help you determine which processes are necessary. However, beyond all of the recommendations, in many cases, the decision on whether a process is necessary varies depending on what the individual or organization needs to accomplish or provide.

Disabling Unnecessary Protocol Stacks

As you saw in Chapter 2, TCP/IP is a suite of protocols. TCP/IP is often referred to as a protocol stack. Other types of protocol stacks include IPX/SPX and NetBEUI. Many operating systems and network devices are capable of running more than one protocol stack. As with removing an unnecessary service or protocol, you should also remove any unnecessary protocol stacks. For example, the IPX/SPX protocol stack is only used on Novell NetWare networks. However, recent versions of NetWare frequently use TCP/IP. If you convert your network to TCP/IP completely, you can remove IPX/SPX from hosts and routers on your network. The fewer protocols, protocol stacks, and services that your systems support, the less likely it is that newly discovered vulnerabilities will affect them. At a minimum, removing unnecessary services, protocols, and protocol stacks improves performance and makes systems less complex to troubleshoot.

Disabling Promiscuous Mode

Attackers who are able to compromise one of the systems on your network might use that compromised system to gather information and possibly exploit other systems. One way in which an attacker might gather information is to install a protocol analyzer program on the compromised system. The attacker then uses the protocol analyzer to monitor data packets, hoping to find passwords, user names, or additional information that might help to compromise other systems.

To protect your systems from this type of attack, you must do all you can to ensure that a system is not compromised in the first place. However, if a system is compromised, one method for stopping the attacker from gathering additional information is to disable the promiscuous mode of the network card. Promiscuous mode is a condition that a network adapter can be placed in to gather all passing information. Normally, network adapters do not gather information that is not specifically destined for the adapter or broadcast to all adapters. Certain programs (such as protocol analyzer programs) place adapters into promiscuous mode.

Many network card manufacturers provide directions for disabling promiscuous mode through various operating systems. Unfortunately, if the attacker is savvy enough to compromise the system and gain full control (root, superuser, or administrative access), then he or she can probably re-enable promiscuous mode on the adapter through the operating system. Some network card manufacturers make network cards on which promiscuous mode can be permanently disabled. If you can permanently disable promiscuous mode on the network adapter, even if an attacker does compromise the system, installing a protocol analyzer would not provide any additional advantages to the attacker.

Disabling Unnecessary Systems

Computer systems that are not in use on your network should be disabled. Network attacks are often launched against test systems that were never properly secured and then forgotten about. Even a test system that has no legitimate user accounts locally could be quite useful to an attacker. As previously mentioned, if an attacker compromises an unsecured system, she or he could install a protocol analyzer and other tools that could lead to further exploits.

To protect your network from exploits launched against systems that are not in use, you must routinely audit your systems. You can use vulnerability scanners on your own network to scan for unsecured systems, and you can also physically inspect your network to see if there are any computers or other network devices that are no longer in use.

Access Control Lists

Packet filtering, as described in Chapter 4, is typically accomplished with an access control list (ACL). An ACL is a rule list that tells the router or firewall how to deal with network packets the router receives, so routers and firewalls use ACLs to determine which packets to forward and which to drop. As you learned in Chapter 4, packet filters can be used to restrict packets based on source address, destination address, protocol ID, TCP or UDP port number, Internet Control Message Protocol (ICMP) message type, fragmentation flags, and options.

One common problem with router and firewall configurations is that packet filters are not stringent enough. As an example, assume you work for an organization that handles name resolution for all internal client systems. In addition, you want to allow Domain Name System (DNS) zone transfers from your Internet service provider's (ISP's) DNS server (named IspDNS) to your local DNS server (named CorpDNS). Because the ISP's DNS server sends zone transfers over the standard port (TCP port 53) to your organization, you know you must enable that port on the firewall. You can configure an ACL that looks like the one shown in Table 8-1.

Table 8-1. Sample Access Control List

Rule	Direction	Destination	Source	Protocol	Source Port	Destination Port
Zone XFR1	OUT	Any	CorpDNS	TCP	>1023	53
Zone XFR2	IN	CorpDNS	Any	TCP	53	>1023

However, if you do this, an attacker could potentially use port 53 to scan your entire network. Further, an attacker could send a bogus zone transfer right through your firewall to your DNS server. The problem is the use of "any" instead of listing the actual DNS server of the ISP. A more secure solution would be to restrict zone transfers to only the IP address of your ISP's DNS server, as shown in Table 8-2.

Table 8-2. A More Secure Access Control List

Rule	Direction	Destination	Source	Protocol	Source Port	Destination Port
Zone XFR1	OUT	IspDNS	CorpDNS	TCP	>1023	53
Zone XFR2	IN	CorpDNS	IspDNS	TCP	53	>1023

Configuring a secure ACL is an important way to help protect your network from attack. Make sure that your firewall and router rules limit the connections that can be made and from where.

File System Security

• File and directory permissions
• Data encryption
• Shared or exported data

File and Directory Permissions

File and directory permissions are used to identify who can access a file or directory. Many operating systems use file systems that allow you to set file and directory permissions. Typical permissions you can configure include read, write, and execute.

Some operating systems allow you to choose to install a file system that supports file- and directory-level security and one that does not. For example, Microsoft Windows NT, Windows 2000, and Windows XP allow you to choose between the file allocation table (FAT) file system and the NTFS file system (NTFS). FAT does not support file and directory security, whereas NTFS does. To better secure your operating system, you should select the file system that supports file- and directory-level security.

To best protect your operating systems from compromise, configure security on files and directories according to the rule of least privilege. This means giving each person or group only the required amount of access and nothing more. For example, if all the users in the marketing department need access to read, but not change, a file you should give them read access only, and nothing more. By limiting permissions you can protect files from being accessed or deleted by attackers who are able to compromise a trusted user account. Further, you help to prevent accidental deletions by legitimate users.

Data Encryption

Some file systems, such as NTFS in Windows 2000 and Windows XP, enable you to encrypt data. You should encrypt all files that you are concerned about keeping private. Although file system permissions should protect your files, encryption adds an additional layer of protection. For more information on data encryption, see Chapter 3, Chapter 4, and Chapter 6.

Shared or Exploited Data

Sharing files and folders is common and so is the exploitation of those shares. To secure your shared files and folders, you can typically configure access controls on them, commonly referred to as share permissions or export permissions. Be sure to follow the rule of least privilege when granting access to shared files and directories.

Operating System Hardening

• Disable unnecessary programs and processes.
• Disable unnecessary services.
• Disable unnecessary protocols.
• Verify, test, and install all vendor patches.
• Use vulnerability scanners to identify potential security weaknesses.
• Disable promiscuous mode.
• Configure file system security according to the rule of least privilege.

In addition to taking those precautions, you should consider the following to better protect your operating system:

• Set complex passwords for all user accounts and change them frequently.   Setting complex passwords was discussed in Chapter 4. Be sure to routinely change passwords to keep them secure.
• Set account lockout policies.   If someone is trying to guess a password, they'll probably take a few guesses. If you have an account lockout policy that locks someone out after three to five attempts, the chances of that person guessing a password successfully are greatly reduced.
• Remove or disable all unnecessary modems.   Modems (or dial-up adapters) can become a way to circumvent the security of your network, as explained in Chapter 4.
• Enable monitoring, logging, auditing, and detection.   You should monitor your hosts and connectivity devices. Many operating systems allow you to log user access, file system access, and other security-related events. You can also configure a host-based intrusion detection system. Monitoring was covered in Chapter 4. Intrusion detection is covered in greater detail in Chapter 11, "Intrusion Detection."
• Maintain backups and images.   One of the most important ways to protect your operating systems is by backing them up. You can also use disk-imaging software to maintain a complete image of the operating system and its data.

There are many specific recommendations and guidelines available for a variety of operating systems available on the Internet. Here are some links to recommendations for specific operating systems:

• The UNIX Security Checklist v2.0 from CERT is available at http://www.cert.org/tech_tips/unix_security_checklist2.0.html.
• The CIS Web site at http://www.cisecurity.com includes information for securing Solaris, Linux, HP-UX, Cisco IOS, Windows 2000, Windows NT, and more.
• The U.S. NSA Web site at http://www.nsa.gov has security guides for Windows 2000, Windows NT, and Cisco routers. Also, the NSA has published a security-enhanced version of the Linux operating system (see Security Enhanced Linux on the NSA Web site).
• The Information Systems and Technology Department of the University of Waterloo Web site at http://ist.uwaterloo.ca/security/howto includes information on securing Windows NT, Windows 2000, Windows XP, AIX, Solaris, and Linux.
• Windows NT Configuration Guidelines from CERT are available at http://www.cert.org/tech_tips/win_configuration_guidelines.html.
• Windows 95 and Windows 98 Computer Security Information from CERT is available at http://www.cert.org/tech_tips/win-95-info.html.

Lesson 2 discusses securing specific types of servers. Servers present specific challenges because they must often run additional protocols and provide additional services that can potentially be exploited by attacks.

Exercise: Using MD5

1. Download the MD5.exe file from the Internet. You can use any Internet search engine. Copy the MD5.exe file to your C drive.
2. Create a text file named Code.txt, type some text into the file using a text editor such as Notepad, and then save the file somewhere on your C drive.
3. Create three folders on the C drive named test1, test2, and test3.
4. Copy Code.txt to each of the folders (test1, test2, and test3).
5. Modify the contents of the Code.txt file in the test2 folder and save it.
6. From the Start menu, click Run and then type CMD or command (depending on your version of Windows) and press Enter. A command prompt appears.
7. At the command prompt, type CD\ and press Enter.
8. Type MD5 C:\test1\code.txt, and press Enter.
9. Type C:\test2\code.txt and press Enter.
10. Type C:\test3\code.txt and press Enter.

You should see that the first and third files have the same hash value, but the value of the second is different.

Lesson Review

1. How can you stop certain protocols from traversing your routers?
2. What can you do to make it more difficult for an attacker to sniff your network?
3. What can you do to secure your computer's file system?
4. What is the purpose of disabling unnecessary systems, programs, processes, protocols, and services?
5. Why is it imperative that you monitor security alerts?

Lesson Summary

• Vulnerabilities are often discovered in network devices, operating systems, and applications. You should monitor for security alerts to ensure that you know about exploits that could affect your equipment. Be sure to verify, test, and apply all security updates as soon as possible.
• To better protect your network devices and hosts, you should do the following:
• Disable unnecessary programs and processes.
• Disable unnecessary services.
• Disable unnecessary protocols.
• Verify, test, and install all vendor patches.
• Use vulnerability scanners to identify potential security weaknesses.
• Disable promiscuous mode.

• Choose secure file systems that allow you to set file- and folder-level permissions. Configure file system permissions according to the rule of least privilege.
• In addition to removing all unnecessary components and applying security updates, additional steps to secure operating systems, beyond those already discussed, include the following:
• Set complex passwords for all user accounts and change them frequently.
• Set account lockout policies.
• Remove or disable all unnecessary modems.
• Enable monitoring, logging, auditing, and detection.
• Maintain backups and disk images.

Lesson 2: Server Application Hardening

• Identify methods that attackers use to exploit Web, File Transfer Protocol (FTP), e-mail, DNS, Network News Transfer Protocol (NNTP), file and printer sharing, DHCP, directory services, and database servers.
• Select methods to secure Web, FTP, e-mail, DNS, NNTP, file and printer sharing, DHCP, directory services, and database servers.

Estimated lesson time: 60 minutes

In this lesson the focus is on general security tips for specific types of servers. Beyond securing the host operating system, there are some additional security tips, presented here, that apply to all types of servers:

• Watch out for buffer overflow vulnerabilities.   Buffer overflows are historically the most frequent type of exploit discovered. Tracking and applying the latest security updates, as mentioned in Lesson 1, is the appropriate method for handling buffer overflows.
• Research issues specific to your server and its applications.   Learn about the discovered vulnerabilities concerning the applications and services you are making available.
• Keep informed of security alerts.   Subscribe to one or more vulnerability alert services that notify people of discovered exploits and solutions for your specific server application. Test, verify, and apply security updates as soon as they are made available.
• Enable logging mechanisms on your server.   You should keep a record of people who visit your server and what they do on it. Review the log to see what is happening and investigate anything that is inappropriate, such as entries that show someone is trying to access operating system files through one of your services or applications.
• Use encryption appropriately.   To protect the transfer of sensitive or private information, ensure that encryption is enabled between the server and client.
• Maintain a backup.   Keep an up-to-date backup copy of your server and the applications and services it is providing so that you can quickly recover from successful attacks.
• Use vulnerability scanning tools.   Some software vendors and security-related organizations produce vulnerability scanning tools designed for specific types of servers. For example, Microsoft Corporation has the IISLockDown Wizard, which is a utility that fixes common security issues with Microsoft Internet Information Services (IIS) servers.

Web Servers

There are many different software vendors that provide Web servers today. In addition, many applications come with the added ability to share documents or information over a Web protocol [Hypertext Transfer Protocol (HTTP)], effectively making them Web servers. So many exploits exist for Web servers that entire books are dedicated to securing Web services. The text that follows includes a brief discussion of three potential Web server exploits: packet sniffing, directory listing, and 8.3 compatible file names. After the discussion of exploits, we review some general guidelines on how to secure a Web server.

Packet Sniffing

Web clients typically contact Web servers over the well-known TCP port 80. The port the Web server sends information to is dynamically negotiated during the TCP handshake. Normal HTTP communications are not encrypted and can be easily captured and decoded by a protocol analyzer. Methods for encrypting Web communications were covered in Chapter 6.

Directory Listing

Automatic directory listings, enabled by some Web servers, allow a client browser to see the contents of a directory when no default document is specified or available. A default document is the page that is loaded when a client navigates to a specific directory. For example, many Web servers specify a default document of index.html. When a client browser makes a connection to the Web server, the default document is loaded. However, if the client connects directly to a subdirectory without a default document, the client sees a listing of files and folders that is in the subdirectory. Attackers might use this feature to browse your Web server's directory structure and available files, which is called directory enumeration. To help prevent directory enumeration, disable automatic directory listings. Once this is done, your Web server posts an error message when the default document cannot be found.

8.3 Compatible File Names

Microsoft Windows 32-bit operating systems support two types of file names. The first type is called a long file name (LFN), which allows for file names of up to 255 characters. The second is the 8.3 compatible file name, which allows for eight-character file names plus a three-character file extension. Figure 8-5 illustrates a file named Longfilename.txt and its 8.3 compatible file name Longfi~1.txt.

Click to view graphic

Figure 8-5 Example 8.3 compatible name

The 8.3 compatible names are created to allow older 16-bit programs to work appropriately with files in the newer 32-bit Windows operating systems. Unfortunately, if you use the Web server application only to control access to files, an attacker can open a file using the 8.3 compatible file names without restrictions.

Web servers that run on Windows 32-bit platforms might be vulnerable to this exploit. Some software vendors have released updates to correct this problem and others advise you to disable 8.3 compatible file name support.

General Tips for Securing a Web Server

Instead of reviewing the multitude of potential Web server exploits and corrective actions, this section lists some general steps that you can take to secure a Web server. First, Web servers are most secure when you configure them as bastion hosts, meaning that you secure them as much as possible by removing as many services and programs from them as possible. The job of the Web server should be to serve Web pages and nothing more. Don't configure a Web server as a printer server or file server because that opens up additional avenues for exploitation. In addition to the items mentioned previously, here are some further items to consider when securing Web servers:

• Reduce features.   Although you might want to provide a highly engaging and interactive Web site, you must consider that every additional feature is another potential point for compromise. Remove all unnecessary plug-ins, scripts, programs, and other features that are not required on the Web server.
• Secure available features.   For the scripts, programs, and plug-ins that you do decide to use on your Web site, be sure to follow all appropriate cautions. Use the appropriate security for all directories, files, and objects. For example, Common Gateway Interface (CGI) scripts should be placed in their own directory and should not be run by the system account. Only read and execute permissions should be enabled for the least privileged user account possible for running CGI programs.
• Place public Web servers in your perimeter network.   Isolate your public Web servers from the rest of your internal network by placing them in a perimeter network. If someone compromises your Web server, you want to protect the rest of the network from being compromised through that Web server.
• Protect your internal network by restricting or denying access to intranet Web servers.   Web services are offered over the standard HTTP TCP port 80 or HTTPS TCP port 443. If you want to block standard Web communications, you should be sure that these ports are blocked on the firewall.
• Carefully choose your Web directories.   You should make your Web root directory (the directory location where users connect by default) a directory that does not include files or folders that contain operating system files or sensitive data. If possible, don't put your Web server files and your operating system files on the same physical volume. Also, don't store sensitive or private data on your Web server.

FTP Servers

• Incorrectly configured FTP directory structure.   Some administrators incorrectly configure their FTP server's structure to include files that they did not intend to be available over FTP, such as operating system files or private data.
• Allowing write permissions.   Some organizations allow users write permission to their servers intentionally, and others do so by mistake. Attackers search for directories on FTP servers that allow write access. Software traders utilize improperly configured FTP directories to exchange software with others.
• Sniffing password exchanges between FTP server and client.   FTP clients contact FTP servers over TCP port 21 to begin communications. By default, FTP communications are not encrypted and this can be easily decoded by a protocol analyzer. FTP servers that require authentication could allow for the compromise of user names and passwords, as attackers can sniff the network and capture user names and passwords. This exploit was discussed in Chapter 6.
• FTP bounce.   There is an FTP exploit that allows attackers to run scans against other computers through your FTP server, called an FTP bounce. This makes it look like your FTP server is scanning client computers. Although this attack is related to the proper functioning of FTP, many vendors have found solutions for preventing it in the form of security updates or configuration changes.

When setting up an FTP server for private or public access, you should consider the security implications of doing so. Here are some items to consider when setting up and securing an FTP server:

• Place public FTP servers in your perimeter network.   Isolate your public FTP servers from the rest of your internal network by placing them in a perimeter network. If someone compromises your FTP server, you want to protect the rest of the network from being compromised through that FTP server.
• Protect your internal network by restricting or denying access to intranet FTP servers.   FTP services are typically offered over TCP ports 21 and 20. If you want to block standard FTP communications, you should be sure to block these ports on the firewall.
• Carefully choose your FTP directories.   You should make your FTP root directory (the directory location where users connect by default) a directory that includes files or folders that do not contain operating system files or sensitive data.
• Don't allow unauthenticated write access.   Some organizations allow write access to their FTP servers. Some organizations configure blind FTP servers or directories, which allow write access, but not file listings (read access). This is a way for an organization to collect files anonymously or share files with people who know the exact names of those files. However, blind FTP areas can also be used for trading software. Software traders do not need to see file listings to share files, because they can only see the file names and locations. Typically software traders post these names and locations on other Web sites or share them through newsgroups, bulletin boards, or chat programs.
• Configure encrypted authentication for your FTP servers.   You can use S/FTP or Kerberized FTP to secure the user name and password exchanges. You can also configure a VPN to secure communications between any client and server.
• Check your FTP directories.   You should routinely check or scan your FTP file structure for unusual or unexpected files and folders.

E-Mail Servers

• Packet sniffing.   E-mail generally moves through the Internet and other networks between e-mail servers, and also between e-mail clients and servers. E-mail servers relay e-mail to one another over the Simple Mail Transfer Protocol (SMTP) that uses TCP port 25. E-mail clients most commonly check e-mail using one of two protocols: the Post Office Protocol version 3 (POP3) or Internet Message Access Protocol (IMAP). POP3 clients contact the e-mail server on TCP port 110 and IMAP clients contact the e-mail server on TCP port 143. By default, these network communications are not encrypted and data can be intercepted with a protocol analyzer.
• DoS attacks.   DoS attacks against e-mail servers typically involve programming flaws that cause them to stop responding for some reason when certain data is sent to them. A DoS attack can also occur when users on a network receive and execute a virus that overburdens the e-mail server with traffic.
• Open relays.   E-mail servers and other types of servers sometimes act as SMTP relay servers. This is convenient for users and other servers that need to transmit e-mail. However, it is also a security issue because people who send spam seek out SMTP relays.

To protect your e-mail servers from those exploits, you can take the following actions:

• Use virus scanners.   You should configure virus-scanning programs on all client and server computers on which e-mail is accessed. E-mail is a popular transmission method for viruses and other malicious software.
• Use an e-mail relay or e-mail gateway to protect your mail server.   E-mail relays or e-mail gateways can be used to scan, clean, and filter e-mail before it reaches your e-mail server. These products typically run on separate secured servers and reduce the amount of e-mail that your server has to process. The e-mail relay or gateway can be used to filter potential virus attachments, spam, and other undesirable or suspicious e-mail.
• Check for, and close, open e-mail relays.   There are scanning programs that you can use on your own network to check for open SMTP relay services so you can find them before spammers do.

DNS Servers

• Snooping around the DNS server.   Anyone can query DNS, so limit the information you maintain there.
• Stealing zone transfers.   DNS servers are often configured to provide other DNS servers with updates. The DNS server receiving the update is typically referred to as a secondary server. The purpose of the secondary DNS server is to maintain a backup copy of the DNS database and to provide name resolution services for client computers. An attacker could potentially receive a zone transfer and use it to help map out your network and search for potential targets.
• Zone update spoofing.   An attacker can potentially spoof the address of the real primary DNS server and send a bogus update to a secondary DNS server. Client computers using that falsely updated DNS server would receive incorrect information and network communications could be redirected to a location controlled by the attacker.
• DNS spoofing.   The dsniff utility, mentioned in Chapter 6, has a subordinate tool called dnsspoof that allows an attacker to set up a bogus DNS server to answer client systems. If the DNS server is spoofed, clients receive bogus information when they request name resolutions. This enables the attacker to redirect traffic.
• Dynamic DNS (DDNS) record spoofing.   DDNS record spoofing allows client computers to update DNS with their name and IP address. Attackers could use DDNS to overwrite records that belong to other systems, or at least put bogus records in the DNS server.
• DNS cache poisoning.   DNS servers maintain caches of IP name resolutions, allowing the DNS server to quickly answer a DNS name query that it has previously answered. Flaws have been found in some DNS servers that allow attackers to insert bogus information into a DNS cache. This exploit is referred to as DNS cache poisoning.

To secure your DNS server from the types of exploits just listed, consider taking the following actions:

• Use a separate DNS server for the perimeter network.   Don't put any information in your publicly accessible DNS server that you don't want to the public to see.
• Restrict information in DNS. Limit the amount of additional information you provide in DNS. Although DNS allows you to store additional host information in HINFO records, consider how an attacker could use that information.
• Limit zone transfers.   Configure your DNS servers to only allow zone transfers to specific secondary servers.
• Secure zone transfers.   Berkeley Internet Name Domain version 9 (BIND 9), a DNS version maintained by the Internet Software Consortium (ISC), allows zone transfers to be signed. Zone transfer signing allows secondary servers to verify the credentials of the primary server. Microsoft's Windows 2000 DNS implementation is integrated with its directory services architecture, which allows servers to verify credentials before accepting data.
• Secure dynamic updates.   Microsoft's Windows 2000 DNS implementation allows for a cross-check of client computer credentials before allowing an update to take place. BIND version 9 is capable of supporting signed DNS updates from clients. Implementing either method gives you a more secure dynamic update because client credentials are established before an update is allowed. You can also choose to disable dynamic updates and instead enter IP addresses manually.
• Use Secure DNS.   Both BIND 9 and Microsoft's Windows 2000 version of DNS implement DNS security, which allows client systems to be sure that they are communicating with the correct DNS server, which prevents DNS spoofing.
• Prevent cache poisoning.   The correction for DNS cache poisoning is to get an updated version or security patch for your DNS server that does not allow the DNS cache to be poisoned.

File and Print Servers

Two of the most popular file sharing protocols are the Network File System (NFS) and Server Message Block (SMB). NFS is typically associated with UNIX networks, but there are add-ons to allow other operating environments, such as those from Microsoft and Novell, to share files over NFS. SMB is typically associated with Microsoft File and Printer Sharing, especially over the Network Basic Input/Output System (NetBIOS). However, there are products, such as Samba, that allow other operating environments to share files over SMB.

Attackers can use both NFS and SMB/NetBIOS file and printer shares to gain inappropriate information and access to your network in the following ways:

• Enumerating resources.   Attackers attempt to make unauthenticated connections to shared resources on the network.
• Exploiting incorrectly configured shares.   Shares that are made available to anyone are easy targets for attackers. If permissions are configured incorrectly or too much permission is available for an easily exploited user account, attackers can do plenty of harm.
• Packet sniffing.   Attackers might try to read data (printer files or data files) as they traverse the network.

Consider the following methods for securing your file and printer shares:

• Block access to shares and related information at the firewall.   Administrators commonly block TCP/UDP ports 137, 138, and 139, which are commonly used for NetBIOS names and sessions. Administrators also block NFS TCP/UDP port 2049. This prevents many of the exploits discussed in this section by preventing external attackers from making connections to internally shared resources.
• Use the highest security and authentication levels available.   Some systems allow you to use varying levels of authentication strength. For more secure configurations, use stronger authentication, as discussed in Chapter 7.
• Verify share security.   Use the rule of least privilege to secure your shares. If possible, further secure data beyond the share by limiting access using file system permissions or encryption.
• Use VPNs.   If you need to secure the data transmitted between clients and servers, use a VPN to encrypt communications, as covered in Chapter 5.

DHCP Servers

• Rogue DHCP server.   An attacker can use a rogue DHCP server to subvert client communications. Some DHCP servers even provide the address of the DNS server. If an attacker is able to configure a client computer with a bogus IP address, the attacker can misdirect the client to resources controlled by the attacker.
• Leasing legitimate addresses to attackers.   Attackers get a foothold on your network when they obtain a legitimate IP address. They immediately learn part of your internal addressing scheme and could make use of the address to attack other systems on your network.

Consider the following solutions to these issues:

• Scan for rogue DHCP servers.   You can use a protocol analyzer or configure an intrusion-detection system to discover DHCP Offer packets from unauthorized DHCP servers.
• Configure DNS server information at the client.   Client computers that have a preconfigured DNS address ignore additional options, such as DNS server IP address. If you set the DNS IP address on the client computer, a rogue DHCP server is unable to trick a client computer into calling a bogus DNS server.
• Restrict address leases.   You can configure most DHCP servers not to lease addresses to unknown adapters. Typically, you configure all of the allowed media access control (MAC) addresses as address reservations for your DHCP clients to prevent the server from leasing addresses to unknown systems.
• Block DHCP at the firewall.   DHCP and Boot Protocol (BOOTP) operate over TCP/UDP ports 67 and 68. To prevent your DHCP server from accidentally answering queries from outside your network, be sure that these ports are blocked at the firewall.

NNTP Servers

• Browsing private NNTP servers.   Attackers might connect to a private NNTP server to gain information that they shouldn't be able to see.
• Targeted information gathering.   In Chapter 6 you learned that spammers frequent public sites to collect e-mail addresses. When you post a message to an NNTP server, the information you post could be seen by an attacker looking to compromise your network. People using NNTP sites sometimes post accurate diagrams of their network for the purpose of asking a technical question. However, attackers might use such information to look for ways to exploit a network. They might even offer bogus advice to create a hole in the network's defenses. They could also use information gathered to help them conduct a social engineering attack, which is explained in Chapter 11.

The following are some ways to protect your organization from NNTP server exploits:

• Block NNTP on the firewall.   If you have a private NNTP server that should not be accessible to external users, block the NNTP port TCP/UDP 119 at the firewall.
• Require authentication and encryption.   If you are posting private information on an NNTP server, you should protect that information. Some NNTP servers allow you to configure user authentication that prevents anonymous or unauthenticated users from connecting to and browsing your NNTP server. You can also configure encrypted communications using Secure Sockets Layer/Transport Layer Security (SSL/TLS) or set up a VPN between NNTP clients and servers to prevent packet sniffing of sensitive data.
• Watch what you post.   Don't post items on a public NNTP server that could compromise your network. If you manage an NNTP server, don't allow others to post sensitive information to the public.

Data Repositories

Directory Services

In computer networking, a directory service is any information storage and retrieval process that provides information about an organization's network. The information in a directory service can include computer accounts, user accounts, mail accounts, service locations, and shared resource information. The Lightweight Directory Access Protocol (LDAP) is a common directory service on many networks today that organizes data in a hierarchical fashion. The top of the hierarchy is called the LDAP root. The LDAP root server creates the hierarchy and the rest of the structure (and resources) branch out from that location. LDAP uses objects to represent computers, user accounts, shared resources, services, and so on. These objects are usually referred to by a name called the common name. Objects are organized into containers called organizational units (OUs). The directory service hierarchy and the information it stores provide a good map of your network infrastructure. Although this is convenient and useful for legitimate users on your network, it can also be quite useful to an attacker.

There are two basic ways in which attackers try to compromise LDAP servers:

• Information gathering.   A directory service is used to store information about network resources. Attackers can use this information to examine your network structure, resources, and potential targets.
• Packet sniffing.   Information traveling over typical LDAP communications is not encrypted. Attackers can listen to information transferred over LDAP, thereby gaining information about your network.

To protect your LDAP hierarchy, consider implementing the following controls:

• Configure strong authentication. The two most popular versions of LDAP are version 2 (LDAP v2) and version 3 (LDAP v3). Both versions support anonymous and simple authentication, which are not very secure. Anonymous authentication doesn't require a password at all, and simple authentication uses a password, but it is transmitted unencrypted over the network, meaning an attacker could use a protocol analyzer to compromise it. Strong authentication over LDAP v2 is provided through Kerberos version 4 authentication. Strong authentication over LDAP v3 is provided through Simple Authentication and Security Layer (SASL) communications defined in RFC 2222. Configure the strongest authentication that your version of LDAP supports to better protect your LDAP hierarchy.
• Utilize encryption.   Secure LDAP (LDAPS, formerly known as sldap) allows you to encrypt communications using SSL/TLS.
• Block access to LDAP ports from the Internet.   LDAP communications travel over TCP/UDP port 389, and LDAPS communications travel over TCP/UDP port 636. Be sure that attackers cannot listen to or make connections using these ports.

Databases

As you know, database servers store data, and both the data and the database server are potential targets for an attacker. An attacker might seek to compromise or disrupt your database server communications, steal your data, or take over your database server. In addition to the common software problems described at the beginning of this lesson (such as buffer overflows), database servers can be exploited in the following ways:

• Unexpected data queries or commands.   Many database servers use Structured Query Language (SQL), which allows for the querying and posting of data. A SQL-savvy attacker might use SQL commands to make your database server do things that you didn't expect or want it to do. This is known as SQL injection.
• Unauthenticated access.   If you allow unauthenticated access to your database server, attackers can more easily connect to and attempt to exploit your database server.
• Packet sniffing.   Attackers might sniff data that is transferred to and from the database server.

Here are some items you should consider that could help to secure your database server:

• Run test queries.   Test the database to see if you can submit extraneous queries and attempt to access unauthorized information.
• Use stored procedures.   Instead of having Hypertext Markup Language (HTML) or Active Server Pages (ASP) build SQL query strings from user input, use stored procedures to prevent SQL injection.
• Configure authenticated access.   Don't allow unauthenticated connections to your database server, whenever possible. Use the strongest authentication that your database server allows.
• Encrypt data transfers.   If you are transferring private data to or from your database server, consider using an SSL/TLS connection or VPN to protect the data.
• Block database ports at the firewall.   If your database server should not be queried by external entities, block access to it on the firewall. Different database servers utilize different TCP/UDP ports to transfer information. Check your specific database to determine which ports you should block.

Exercise: Port Matching

1.   DNS 2.   DHCP 3.    SMTP 4.    POP3 5.    IMAP

a.    143 b.    53 c.    110 d.    25 e.    67/68

Lesson Review

1. What are some ways to secure your network from exploits targeted at servers capable of dynamic DNS (DDNS)?
2. What steps can you take to secure DHCP servers and clients on your network?
3. How might an attacker use your FTP server to compromise another computer?
4. What are the differences in authentication support between LDAP v2 and LDAP v3?
5. What are the components in an LDAP hierarchy?

Lesson Summary

• The following security tips are common to all servers: research issues that are specific to your server and its applications, keep informed of security alerts and updates, enable logging mechanisms, enable user encryption, maintain backup copies of information, and use vulnerability scanning tools.
• General tips for securing Web servers include the following: reduce features, secure available features, isolate your public Web servers from your internal network by placing them in a perimeter network, protect your internal Web servers by blocking port 80 on the internal firewall, and carefully choose Web server directories and secure them appropriately.
• Security tips for FTP servers include the following: isolate your public FTP servers from the internal network by placing them in a perimeter network, protect your internal FTP servers by blocking TCP/UDP ports 21 and 20 on the internal firewall, don't allow unauthenticated write access, configure encrypted authentication and data transfer where possible, and monitor your FTP directories for unauthorized content.
• The following are some security tips for e-mail servers: use virus scanners to protect your systems from viruses, use an e-mail relay or gateway server to protect your e-mail server, reduce processing load, scan for unwanted content, and scan for and close open SMTP relays.
• Security tips for DNS servers include the following: use a separate DNS server for internal and perimeter network name resolution, restrict the information you place in DNS, limit zone transfers, secure zone transfers, secure dynamic updates, and use secure DNS when possible.
• The following are some security tips for DHCP: scan for rogue DHCP servers, configure DNS server information at the DHCP client, restrict address leases to known MAC addresses, and block DHCP ports at the firewall.
• Security tips for file and printer servers include the following: block access to shares and related information at the firewall, use the highest security and authentication levels available, and verify share security.
• Security tips for NNTP servers include the following: block NNTP at the internal firewall, require authentication and encryption on private servers, and consider the information you allow and post on NNTP servers.
• The following are some security tips for LDAP servers: configure strong authentication, implement SLADP when encryption is required, and block access to LDAP ports from external networks.
• Security tips for database servers include the following: run test queries against the server to check security, use stored procedures, configure authenticated access and restrict or disallow unauthenticated access, encrypt data transfers for confidential data, and block database ports at the firewall.

Last Updated: January 13, 2003

Top of Page