Designing for a Secure IP Infrastructure

---

Your network infrastructure is vulnerable to many different kinds of attacks. Attackers can eavesdrop on the data by using a network monitoring tool commonly referred to as a packet sniffer, which is used for legitimate troubleshooting but can also be used maliciously by being placed on a compromised router or network between you and the data’s destination. Attackers can take over the administration functionality of a router, switch, or hub and misdirect packets, causing denial of service (DoS) attacks. Attackers can exploit flaws in the firmware or take advantage of known default settings in these devices. They can also launch a DoS attack against a device by trying to overwhelm it with large numbers of packets. These threats to your network will need to be assessed for risk and then mitigated if necessary.

Table 3.1 lists the attacks to which your data is vulnerable.

Table 3.1: Common Attacks to Data Transferred across a Network

Attacks	Description of Attacks
Network monitoring	Administrators or an attacker views confidential data contained in packets from a database application or an e-mail application. Passwords that travel on the network unencrypted are viewed and used to infiltrate servers.
Denial of service	An attacker sends an unusual number of packets to the server or exploits a vulnerability that prevents legitimate users from accessing the resource.
Spoofing	An attacker modifies a packet or data to impersonate another resource or person. For example, the attacker forges return addresses on e-mails or source IP addresses on IP packets.
Data alteration	An attacker modifies data between the source and the destination. This could mean changing the data in the packets, redirecting the packets, or forging information to attack network servers. This is used for man-in-the-middle, replay, session hijacking, and packet tampering.

You will need to determine what vulnerabilities will affect a company’s network and then consider the importance of the data along with the costs and the technical requirements to secure it. The following is a list of considerations that will help you in deciding what and how to secure data:

Decide what network traffic needs securing. Securing network traffic requires the use of CPU and network bandwidth, so you will need to figure out what traffic requires security and the level of security that it requires. This can range from setting up a point-to-point connection from the PC that is sending confidential data to the server to establishing a secure connection or tunnel between routers so all traffic that passes through the routers over the segment is encrypted.

Identify the compatibility issues of the operating systems you have installed and the applications running on them. The version of the OS or application you are running will affect what security options are available for transmitting data. You will need to weigh the cost of upgrading the OS or application with the cost of being less secure.

Make sure that the hardware is secure. If the hardware is not secure, it doesn’t really matter what security measures you are taking on the packets moving across your network. Securing the hardware means making sure you lock the wiring closets and control access to the server room. You can also add more security by using switches rather than hubs on the network. This will make it harder for attackers to “sniff” packets on your network.

Figure out what methods to use to secure data that will be transmitted across a network. Data is vulnerable as it moves across the physical devices and mediums on the network. You can not trust devices that you do not exercise full control over, so you will need to take appropriate precautions with your confidential data. Mainly, you will need to figure out the identity of the person and/or computer that is transmitting the data and encrypt the data so it cannot be read on an insecure network. You will also need to take into account laws that restrict encryption strength and exportation for countries where you will do business. This may mean precluding data from being transmitted into these countries or using a separate physical network instead of the less-expensive public network.

Once you have decided what types of attacks your data is vulnerable to, you will need to come up with a plan to securely transmit data across the network. This may involve coming up with a method to encrypt the data you are transmitting, verifying that the data has not been manipulated in transit, and choosing which method you will use to authenticate remote clients on the network.

Securely Transmitting Data

If you decide that you need to securely transmit data over a network, you have some problems that need to be mitigated:

• You need to make sure that the data will not be read by any unauthorized individual between you and the source.

• You need to verify or authenticate the identity of people who will send packets.

• You need to verify that the data will not be tampered with, meaning the data in a packet won’t be changed by someone in between you and the packet’s source, which is known as a man-in-the-middle attack.

You can overcome these problems with transmitting the data securely by encrypting the data, authenticating the user, and signing the data.

Encrypting Data

You can mitigate the risk of eavesdropping by encrypting the packets that you send over a network. Encrypted packets cannot be read by attackers unless they know the key to decrypt the data in the packets. Therefore, you will need to take extra precautions to secure the keys that are necessary to decrypt the information.

There are many types of technology used to secure data transmissions:

• Secure Sockets Layer (SSL), which is used to secure traffic to and from a web server (also known as HTTPS).

• Transport Layer Security (TLS), which is based on SSL and can be used to secure all types of traffic, from SMTP to database communication.

• IP Security (IPSec), which can be used to establish a secure connection between two devices, but does not provide for strong or flexible authentication mechanisms.

• Virtual Private Network (VPN) technology, which uses either PPP or L2TP to authenticate the user and then Point-to-Point Protocol (PPP) encryption or IP Security (IPSec) to encrypt all the content that traverses the network connection between the two end points. We will discuss more about VPNs in the remote access section of this chapter.

In the following sections, we will take a look at the various methods of encrypting packets.

Secure Sockets Layer and Transport Layer Security

Secure Sockets Layer (SSL) and Transport Layer Security (TLS) are technologies used to provide session encryption and integrity for packets sent from one computer to another. This could be client-to-server or server-to-server network traffic. It also provides a means for the verification of the server to the client and client to the server through X.509 certificates (digital certificates).

Note

You will learn more about X.509 certificates in Chapter 6, “Designing a PKI with Certificate Services,” when we discuss public key infrastructure.

These protocols use the digital certificates in combination with public/private key and symmetric key encryption to securely exchange keys and encrypt network communications. The benefit of these protocols is that they can guard against malicious or accidental viewing of the contents of packets on a local network or over the Internet. They will also prevent the manipulation of packets sent over a network, so you can be assured that the packet that you receive is the same packet that was sent. They support passing through firewalls, Network Address Translation (NAT) servers, and other network devices without any special considerations other than making sure the proper ports are open on the device. Figure 3.1 shows where SSL would typically be used on a network.

Figure 3.1: The usual place for SSL in a network infrastructure.

The drawback of SSL and TLS is, like all encryption, they consume CPU resources. Therefore, enabling them will degrade server and client performance. You can get around this limitation by adding special network cards or devices that perform some of the algorithm’s work that make up SSL and TLS in hardware, thereby saving your hardware’s CPU for other tasks. You could also add CPU to your server to compensate for the increased demands on CPU. You can use Performance Monitor to determine the extent of the performance impact on your hardware.

SSL is popular for web applications that are extended to public networks like the Internet. This is because it is supported by web browsers and web servers on all platforms and has become the standard for encrypting HTTP traffic. It is also easy to set up and is used on an internal network where web data must be secured. SSL and TLS will have the widest range of compatibility among operating systems and applications because of their use on the Web and are therefore good choices when diverse systems must communicate with each other securely.

Note

For more information on SSL see http://wp.netscape.com/eng/ssl3/draft302.txt. For more information on TLS, see RFC 2246 at http://www.ietf.org/rfc/rfc2246.txt.

Note

You will learn more about designing for SSL and TLS in Chapter 6 and Chapter 7, when we discuss designing a network for public key infrastructure and Internet Information Services (IIS) respectively.

In the following Design Scenario, you will look at design criteria for an SSL solution.

Design Scenario: Designing for SSL on a Windows Server 2003 Network

Frankfurters, Inc. is a medium-sized company with about 700 employees located in 5 states in the United States. It produces various meat products and is looking to allow access to e-mail for its sales and executive staff throughout the United States. The company is running Windows Server 2003 on its servers and is using Exchange Server 2003 and Active Directory.

During the design process, you interviewed the following members of the company:

CIO We want to provide e-mail access wherever our sales staff or executives may travel and on whatever computer they may be using. We need to keep the cost low, so we are looking at using the Internet and a national ISP to provide Internet access.

Network Administrator Users may access their e-mail from their home PCs, from laptops issued by Frankfurters’s IT staff, or through computers at other locations.

The e-mail contains important sales projections, client information, and other confidential information, and you need to protect this information in transit, so we need to make sure the solution can deliver the information securely over various network topologies.

We are looking at using the HTTP access in Exchange 2003 called Outlook Web Access (OWA) because it looks easy to use and comes with Exchange 2003.

Sales and Executives We want a solution that is easy to use. We do not want to deal with setting up software or configuration settings for security on the device we may use.

1. Question: What kind of a solution would you propose for Frankfurters, Inc.? Answer: Use OW A to provide access to e-mail through HTTP. Enable SSL on the server by generating a public and private key and obtaining a certificate from a company like VeriSign. Provide the user s with a URL for accessing the OWA server.

2. Question: Which technology would you use to secure network traffic for the solution? Answer: SSL is supported across most operating systems and devices, so it is the best solution for encrypting access to e-mail in this situation. SSL also does not require special intervention by the sales or executi ve staff. It will also be able to traver semostfi rewall topologies that support HTTP and SSL.

Point-to-Point Tunneling Protocol with PPP Encryption

Point-to-point Tunneling Protocol (PPTP) can be used to enable an encrypted session between two computers. PPTP tunnels the Point-to-Point Protocol (PPP) over a network like the Internet. This means that you can use the PPP infrastructure and authentication mechanisms to provide secure access to your internal network for partners or employees over the Internet or private connections in much the same way as you can use dial-up access over a modem.

PPTP was developed and standardized by Microsoft to provide a simple mechanism to create a virtual private network (VPN) with Windows NT 4 and Windows 9x clients. Microsoft decided to take advantage of the PPP support in the Windows NT 4 RAS server to authenticate the PPTP session. The resulting session key from the authentication process is used to encrypt the packets that are sent across the tunnel. Encryption is not enabled by default for PPTP, so you will need to enable it through the Security tab of the user’s Property dialog box, as shown in Figure 3.2.

Figure 3.2: Enabling PPP encryption on Windows Server 2003

The advantages of this protocol are that it has widespread adoption in Microsoft operating systems, and it is easy to set up on any Windows platform without special downloads. It is also the only way you can set up a VPN connection to a Windows NT 4 RAS server without third-party software. PPTP will traverse all NAT devices because it encapsulates PPP packets inside an IP packet, does not provide IP packet integrity, and does not care if the IP address is changed on the packet. This means that you can use PPTP to establish a tunnel through a NAT server that does not support NAT-Traversal.

There are downfalls associated with using PPTP. Although support on the Windows platform is strong, it has not been as widely or well supported in other operating systems and devices. You would need to verify that the device with which you need to set up a PPTP session supports the protocol. PPTP supports authenticating users but not machines, so you should use it only when you need user authentication and not machine authentication. Another weakness is in the way PPTP does encryption. Its encryption strength is essentially tied to the strength of the password, so you will want to make sure you have strong password policies if you need to use PPTP. This also means if an attacker were to obtain a user’s password, they may be able to use this information to decrypt the session. Currently, Microsoft does not recommend using PPTP for VPNs in Windows 2000 or later. Microsoft recommends using Layer 2 Tunneling Protocol (L2TP), for authentication, and IPSec, for encryption, as stronger protocols for secure point-to-point communication, as you will see in the next section.

In the following Design Scenario, you will look at using PPTP to establish a VPN connection to a Windows Server 2003 Routing and Remote Access Services (RRAS) server.

Design Scenario: Designing for PPTP on a Windows Server 2003 Network

Frankfurters, Inc. is a medium-sized company with about 700 employees located in 5 states in the United States. It produces various meat products and is looking to provide secure access to various applications used by sales and executive staff. It is running Windows Server 2003 with RRAS installed on it. This server sits behind the firewall that provides NAT services. This firewall is not installed on a Windows Server 2003 machine but is a dedicated device.

During the design process, you interviewed the following members of the company:

CIO We need a solution that will provide secure access to our internal resources. We do not require high security and do not have the budget to install a complicated solution.

Network Administrator Our firewall does not support NAT-Traversal. We do not have the budget to upgrade the firewall to a product that supports NAT-Traversal. For security reasons, the RRAS server must sit behind the firewall.

The users need to get to the applications from their laptops, client computers, and home computers. These run operating systems varying from Windows 98 to Windows XP.

1. Question: What kind of a solution would you propose for Frankfurters, Inc.? Answer: Because its firewall does not support NAT-Traver sal and the VPN connection needs to be set up through the firewall, you will need to use PPTP. The company doesn’t require high security, so the fact that PPTP relies on passwords for generating encryption keys is not as much of a concern and it keeps the infrastructure simple.

L2TP and IP Security (IPSec)

One of the ways to secure data that is sent across any type of network is with IP Security (IPSec). IPSec is a set of standards that will verify, authenticate, and encrypt data at the IP packet level. IPSec accomplishes this by authenticating the client and the server and exchanging keys that are used to encrypt and sign data. This guards against man-in-the-middle attacks. It also implements the Encapsulating Security Payload (ESP) and Authenticated Header (AH) headers, which use sequence numbers and digital signatures to reduce vulnerability to replay attacks and spoofing attacks, respectively.

The ESP header encrypts and signs each packet. This prevents somebody from reading anything in and above Layer 3 in the OSI model. It will also prevent packet tampering by hashing each packet and encrypting the hash (signing the packet). The receiving computer then verifies the hash by re-computing it and comparing it with the encrypted version contained in the packet. If they don’t match, the packet is discarded because it is assumed that it has been tampered with somehow. The AH header will sign traffic but not encrypt it. This means that, for data that does not require encryption, you can guard against packet tampering and man-in-themiddle attacks on a network.

IPSec does this all transparently to the user. It is contained inside of a standard IP packet and routes the same as other IP packets except when it comes into contact with a Network Address Translation (NAT) device. Because NAT needs to alter the IP address in the packet, it will cause the packet to be rejected by the client on the other end (remember the hash). Windows Server 2003 supports NAT-Traversal of IPSec packets. NAT-Traversal is an Internet Engineering Task Force (IETF) draft standard that comes up with a solution for applications like IPSec that are sensitive to the IP packet being altered. NAT-Traversal uses User Datagram Protocol (UDP) encapsulation. This means that the IPSec packet is wrapped inside a UDP/IP header. The NAT device can then change the UDP/IP header’s IP address or port number without changing the contents of the IPSec packet; therefore, it will not be rejected on the other end of the connection. You can set up a point-to-point connection with IPSec through a Windows Server 2003 used as a NAT server if the client supports NAT-Traversal also.

Note

The L2TP/IPSec client available for Windows 98, ME, 2000, and XP supports NAT-Traversal. See www.microsoft.com/windows2000/server/evaluation/news/bulletins/l2tpclient.asp for more information.

The advantages of IPSec is that it provides stronger encryption options than PPTP does. Instead of being based on the password, it can be set up to use a preshared key or a certificatebased mechanism, which would provide the strongest encryption. You can also use IPSec to verify the identity of the user (with L2TP) and the machine.

The main disadvantage of IPSec is that it does not support NAT unless NAT-Traversal is available as explained earlier. It can also be more difficult to deploy the solution if you involve preshared keys or certificate-based encryption. You will also need to use L2TP to support user authentication.

When setting up a VPN or providing security for IP traffic in Windows 2000 or later, IPSec is the preferred protocol. IPSec is built into Windows 2000 or later clients and is available for download for Windows 98 and Windows NT 4 from Microsoft’s website.

CONFIGURING IPSEC THROUGH SECURITY POLICY

You can enable and configure the IPSec protocol with Group Policy for Windows 2000 or later computers or through the Network Connection Wizard. For a Windows 98, ME, or NT 4 client, you would simply create a new dial-up networking connection and choose Microsoft L2TP/ IPSec VPN Adapter (or RASL2TPM on a Windows NT 4 Workstation computer). You can configure rules that a computer will follow in applying IPSec to outgoing and incoming packets. Windows Server 2003 has three built-in IPSec policies:

Client (Respond Only) The client will use IPSec if the server requests or requires it.

Server (Request Security) The server will request that an IPSec session be created with the client but will still establish a connection if the client does not support it.

Server (Require Security) The server will only allow communication with clients that support IPSec. This means that one of the previous two rules needs to be configured.

These settings are located by navigating to the Security Settings section of the Group Policy console or launching the Domain, Domain Controller, or Local Security Policy MMC from the Administrative Tools section of the Start menu. You can click on the IP Security Policies section to reveal the information shown in Figure 3.3.

Figure 3.3: The policy settings for IPSec on Windows Server 2003

These policies are made up of a default set of rules and are useful for many but not all situations. Therefore, it is also possible to create a custom policy, which is just a collection of rules that form the IPSec policy. You can create rules that define the following:

• A filter that decides what type of traffic (like HTTP or SMTP) to apply the IPSec policy to.

• A filter action that defines what the policy should do when it matches the traffic type defined in the filter. This could be requiring encryption for a protocol or blocking all traffic from a protocol.

• An authentication method that uses one of three mechanisms: Kerberos v5 protocol, PKI certificate, or a preshared key. Kerberos or PKI certificates are the more secure choices but require additional infrastructure. The preshared key does not require Kerberos or PKI infrastructure, but the same key must be entered on each computer. The preshared key option is less secure because it is stored in the policy, which could be compromised, causing difficulty in distributing the key.

• The type of IPSec connection, which is either tunnel or transport mode. Tunnel mode secures traffic between two points (like router to router), and the clients that communicate across the link do not need to support IPSec. Transport mode secures all communication between two hosts but requires the clients to support IPSec.

• The network interface that the IPSec policy applies to, such as a VPN connection or specific network interface.

• The means for exchanging keys over the Internet via Internet Key Exchange (IKE).

It is important to recognize that the default rules do not encrypt all traffic. The following types of traffic are not protected by the filters in the default policies:

• Broadcast traffic

• Multicast traffic

• Internet Key Exchange (IKE)

• Kerberos protocol

• Resource Reservation Protocol (RSVP)

You would need to create your own custom policy rules to accommodate these protocols. You can also create rules that apply IPSec only to certain protocols or only to communication sessions with specific servers. This can allow you to reduce the performance issues associated with IPSec.

There are some limitations and concerns when applying IPSec policies to computers on your network. Windows allows only one IPSec policy to be applied to a computer at a time. This can be a limitation to some security designs that need to be mitigated through third-party support. IPSec is not free in terms of resource usage. You need to consider that IPSec will cause a degradation of performance depending on whether you use encryption, the encrypting protocol you choose, and how many filters you are applying. This will be in terms of CPU usage (although this will not be noticeable unless you are moving a large volume of data on modern systems) and bandwidth (which will only be noticed on low-bandwidth networks). You should enable IPSec only when necessary and then enable encryption only if necessary on top of the AH header. You can also buy network adapters and devices that take the load off the CPU.

You can configure IPSec through IPSec policies by following these steps:

1. From the Start menu, choose All Programs Administrative Tools and then choose Local Security Settings or Default Domain Controller Security Settings, depending on whether you are using Windows Server 2003 or Windows Server 2003 configured as a domain controller.

2. Click the IP Security Policies On Local Machine to show the rules available in the details pane.

3. Right-click the Secure Server (Require Security) rule and choose Properties, which will bring up the Secure Server (Require Security) Properties dialog box.

4. In the Secure Server (Require Security) Properties dialog box, click the IP Filter List tab. The IP security rules that are enabled for this policy are listed.

5. Select All IP Traffic by clicking the radio button next to it and click the Edit button, which will display the Edit Rule Properties dialog box.

6. In the Edit Rule Properties dialog box, look at the various authentication and filter settings by clicking the tabs. You define the type of network traffic that will be affected by the rule on the IP Filter List tab (as shown in Figure 3.4), and you can specify how the rule will negotiate and secure communications on the Filter Action tab. You use the Authentication Methods tab to define whether you want to use Kerberos (strong), certificates (strongest), or a preshared key (weakest) for authentication. The Tunnel Setting tab is where you can set up point-to-point communication or a tunnel, and on the Connection Type tab you can define whether the rule applies to all network traffic to and from the server or client, or you can specify that the rule only applies to LAN or remote access traffic.

   
   Figure 3.4: Creating IPSec rules on Windows Server 2003

7. Click the Cancel button so that the IPSec policy will not be changed.

Server Message Block Signing

Server Message Block (SMB) signing adds a keyed hash to each SMB packet. This allows you to guard your network against man-in-the-middle, replay, and session hijacking attacks. But SMB signing does nothing to protect the confidentiality of the data that is passing over the network connection. Signing requires that every packet be signed and verified, which means that you can expect a slowdown when accessing an SMB resource like a file share.

This option is enabled by default on a Windows 2000 Server, Windows XP, and Windows Server 2003. All Windows clients support it except for Windows 95 without the Active Directory client and Windows NT pre–Service Pack 3. If SMB signing is not enabled on the client, it will not be able to connect to a server on which SMB signing is enabled. This will prevent access to Group Policy, printing, and file shares on a domain controller or server with SMB signing enabled. If you have computers that must run these operating systems, then segment all computers that they need to communicate with in their own OU and apply the following Group Policy setting to the OU:

 Computer Configuration\Windows Settings\Security Settings\Local Policies\    Security Options\Microsoft Network Server: Digitally sign communications    (always) = Disabled 

This can also be applied to a domain, but it will increase the risk of the attacks mentioned earlier. IPSec provides a mechanism to sign all IP traffic and would be a better choice for heterogeneous networks.

Note

See Knowledge Base articles Q230545 and Q161372 for information about enabling SMB signing on Windows NT 4 and Windows 98.

Using Packet and IP Filtering to Secure Your Network

When a computer is connected to a network, anything running on the server is vulnerable to one of the attacks listed in Table 3.1. It would therefore be a prudent step to lock down each server so that it will respond only to network requests for the services that its clients need.

The first rule when locking down your server is that you should install only software that you are using. We have lost count of the number of times we have heard administrators say, “I am not sure what this does, so I will install it anyway because the server might not operate correctly without it.” Determining what software is necessary and what is not may take extra time, but it will make your server more secure. You must investigate each and every software package you install on a server and figure out if you really need it in your environment. This can mean even uninstalling software that is installed by default by Windows. Microsoft does not know your environment only you do, so you need to decide what should be on the server. This way, you will maintain the software properly by keeping up with security patches and service packs.

That said, it can be difficult to keep up with all the software that gets installed. For instance, the marketing departments of software companies have their goals (to move product) and the security of your network usually is not one of them. So, as an added layer of protection, you should enable filtering on your servers. There are two types of filters that you can apply to your server: IP address filtering and IP packet filtering.

IP Address Filtering

IP address filtering involves filtering traffic based on the IP address of the client computer. You have two options to enable IP filtering: You can enable all traffic except traffic from the IP addresses listed, or you can exclude all IP addresses and allow only the IP addresses listed.

If you enable IP address filtering, it is recommended that you filter all traffic except the traffic explicitly specified. You also need to realize that an IP address can be “spoofed” (forged), so you should still rely on additional forms of authentication for the users.

You can enable IP address filtering on Windows Server 2003 to specify the traffic you want to filter. To do so, follow these steps:

1. Choose Start All Programs Administrative Tools Internet Information Services (IIS) Manager.

2. Navigate to the Default Web Site node in the tree view.

3. Right-click the Default Web Site node and choose Properties from the context menu.

4. In the Default Web Site Properties dialog box, choose the Directory Security tab.

5. Click the Edit button in the IP Address And Domain Name Restrictions dialog box, shown in Figure 3.5.

   
   Figure 3.5: Filtering IP addresses using the IP Address And Domain Name Restrictions dialog box

6. Click the Add button to add an IP address, domain name, or range of IP addresses to filter.

IP Packet Filtering

If you need more granular control than just preventing an IP address from communicating with your server, you can use IP packet filtering. IP packet filtering prevents specific packets from reaching their destined ports on the server. This can be effective in guarding against packets for specific services that would not represent legitimate traffic to the server.

You define a filter based on the ports of the protocols of UDP, TCP, or the IP number. Filtering based on UDP or TCP allows you to filter all packets except the packets destined for the ports that you specify. Filtering based on the IP protocol allows you to filter all packets except for those from the IP protocol number that you specify. This would allow you to filter the ARP protocol, for example. It will not allow you to filter ICMP traffic, though.

You can enable IP packet filtering on Windows Server 2003 by following these steps:

1. Right-click the network connection that you would like to enable packet filtering on and select Properties from the context menu to open the Network Connection dialog box.

2. Click Internet Protocol (TCP/IP) in the list box and then click the Properties button.

3. In the Internet Protocol (TCP/IP) Properties dialog box, click the Advanced button and then click the Options tab in the Advanced TCP/IP Settings dialog box.

4. Click on TCP/IP Filtering and then click on the Properties button to open up the TCP/IP Filtering dialog box, shown in Figure 3.6.

   
   Figure 3.6: Filtering IP packets using the TCP/IP Filtering dialog box

5. In the TCP/IP Filtering dialog box, configure the packet filter. Select the Enable TCP/IP Filtering (All Adapters) check box to enable TCP/IP filtering for all the adapters on the box.

6. To configure a filter on the adapter, select the Permit Only option and then click the Add button. Type in the port that you want to filter. For instance, to permit only connections to a web server on the server, click the Permit Only option over the TCP Ports selection, click the Add button, and then type 80 in the TCP Ports list box.

Real World Scenario: A W32.Slammer Worm Attack Prevented Because of Filters

We had a web server that had some of the sample applications installed for some development purposes. This meant that it had Microsoft Data Engine (MSDE) 2000 installed on it and the web server was not being maintained (we were not installing the latest SQL Server 2000 patches on the server). Therefore, the server was vulnerable to attacks due to security holes that are inevitable in any product. This is usually not as much of a problem on a server that is actively maintained. The patches would be installed and the vulnerability would be patched. But this was not the case on this server. We had installed packet filtering on the box as part of the standard setup of the server. We knew that the box would be used for web applications, FTP, and SMTP-based applications. We enabled the filters to allow this traffic along with the capability to authenticate with Active Directory. When the Slammer worm hit, the server was protected because it was not allowing packets to communicate with port UDP 1434, so the Slammer worm was not able to infect the computer. These filters, by being totally exclusive of all traffic except the traffic we allowed, prevented attacks even though the applications were not properly maintained.

In the following Design Scenario, you will create a security design that will include filtering.

Design Scenario: Designing for Filtering

Frankfurters, Inc. has just set up a server that will serve as its web server. The folks in the IT department are concerned about the viruses and worms that are on the Internet. They have been careful to only install the services that they need on their web server. They are still concerned that they may have missed a service.

1. Question: When designing their IP Infrastructure, what would you do to help alleviate their concerns? Answer: You could propose enabling IP pack et filtering on the server to prevent access to other protocols. You would enable access to port 80 and 443 to support HTTP and SSL. You would also need to consider the por ts used to manage the server and to upload new content to the server. A secure design would probably enable these only when needed.

---