Lesson 2: Server Application Hardening

Lesson 2: Server Application Hardening

Techniques for protecting client applications were presented in Chapter 6. This lesson focuses on securing network servers, and specifically the services they provide to network clients. Before you secure a network server, you should secure its operating system. All sections in this lesson assume that you have already secured the operating system, as discussed in Lesson 1.


After this lesson, you will be able to

  • 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.

In this lesson, several TCP and UDP ports are mentioned in the areas in which services are introduced. In Appendix B, "Ports and Protocol IDs," you can study a larger list of important TCP and UDP ports. If you want an even more comprehensive and current list of all TCP and UDP ports, check the Internet Assigned Numbers Authority (IANA) database "Protocol Numbers and Assignment Services" at http://www.iana.org.

Web Servers

Many organizations use Web servers to provide information and services to the public and internally on their private networks. Web servers that provide services to the public are typically referred to as Internet Web servers or public Web servers; those providing services to the private network are called intranet Web servers or private Web servers. Internet Web servers are typically considered to be at greater risk because they are exposed to a larger number of anonymous users. For this reason, Internet Web servers are typically located in a perimeter networks (also known as a DMZ, demilitarized zone, or screened subnet), whereas intranet Web servers are typically located on the internal network. All of the security considerations mentioned in this section can be applied equally to either type of Web server.

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.

For detailed information on securing Web servers, see NIST Special Publication 800-44, titled "Guidelines on Securing Public Web Servers."

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.

Attackers might attempt to use other methods to browse a Web server's directory structure. CERT warns about an exploit involving the use of Web publishing tools as a means to enumerate directories in their Vulnerability Note VU#32794, which is located at http://www.kb.cert.org/vuls/id/32794.

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.

figure 8-5 example 8.3 compatible name

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.

For more information on the 8.3 compatible file name issue, see CERT advisory CA-1998-04 at http://www.cert.org/advisories/CA-1998-04.html.

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.

The CERT module titled "Securing Public Web Servers" is a good source for additional Web security tips, available at http://www.cert.org/security-improvement/modules/m11.html.

FTP Servers

Like Web servers, FTP servers can be used to serve internal or external users. Public FTP servers are typically open to everyone on the Internet, whereas private FTP servers are typically secured for internal use only. In Chapter 6, you learned about client-side exploits for FTP communications. In this section you learn about FTP server exploits. In addition to the general issues discussed at the beginning of this lesson, FTP servers can be exploited in the following ways:

  • 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.

CERT Advisory CA-1997-27, "FTP Bounce" (also CVE-1999-0017), further explains the issue and shows specific vendor solutions at http://www.cert.org/advisories/CA-1997-27.html.

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

E-mail servers and clients are vulnerable to many different exploits. In Chapter 6, you learned about ways in which e-mail client communications could be compromised, including e-mail forgery and packet sniffing. You learned there that you could use encryption and digital signatures to solve those issues. In this section, you get to see ways in which e-mail servers are exploited and measures that can be used to secure them. E-mail servers are typically compromised in the following ways:

  • 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.

For more detailed information on securing e-mail servers, see NIST Special Publication 800-45, titled "Guidelines on Electronic Mail Security."

DNS Servers

DNS is an integral part of most communications occurring over TCP/IP networks today. The DNS server converts friendly computer names (host names) into IP addresses so that communications can be correctly routed through the network. Client computers user DNS to locate Web servers, FTP servers, e-mail servers, and a wide variety of other servers and network services. DNS can be an important target for an attacker. The potential ways in which DNS can be exploited include the following:

  • 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

Every major operating system vendor provides a way for you to share files and printers on your network. Although sharing files and printers is considered a necessary and reasonable activity, it is also a common way in which hackers gain information and unauthorized access.

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 6.

  • 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

DHCP provides IP addresses automatically to client computers. When clients request an address, they broadcast a DHCP Discover packet on the network. DHCP servers respond with a DHCP Offer packet that contains a range of valid addresses from which the client can choose. The client chooses an address using a DHCP Request packet and the server acknowledges the request with a DHCP Acknowledge packet. Attackers can attempt to use or interrupt the DHCP address lease process in the following ways:

  • 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

NNTP allows news clients to connect to news servers to read and post messages. NNTP can be used to share information among colleagues privately or to post articles to a public NNTP server. In addition to the problems common to almost all server software, such as buffer overflows, attacker exploits of NNTP can also include the following:

  • 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

Data repositories are locations that hold information about your network or organization, such as user accounts, computer accounts, directories, maps, and so on. Attackers can use the information stored in data repositories to formulate attacks against your organization. Therefore, you must ensure that this information is as limited and restricted as possible, while still meeting the informational needs of your organization. Most techniques to protect this information involve authentication and encryption. The following sections cover securing directory services and databases.

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.

Other ports are also used in LDAP communications. For example, Microsoft's Global Catalog Server is an LDAP server that operates over TCP/UDP ports 3268. Check your software vendor's documentation for an exact list of ports used.

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

Match the services in the left column with the correct TCP/UDP ports on which the service is provided in the right column:

  1. DNS

  2. DHCP

  3. SMTP

  4. POP3

  5. IMAP

  1. 143

  2. 53

  3. 110

  4. 25

  5. 67/68

Lesson Review

The following questions are intended to reinforce key information presented in this lesson. If you are unable to answer a question, review the lesson and then try the question again. Answers to the questions can be found in Appendix A, "Questions and Answers."

  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.



Security+ Certification Training Kit
Security+ Certification Training Kit (Pro-Certification)
ISBN: 0735618224
EAN: 2147483647
Year: 2002
Pages: 55

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net