Networking Security


These days, Internet access for a company network is a vital asset. However, along with the benefits that Internet access can provide come the risks of having your network permanently connected to the outside world. Thus, it is essential that a network be secured from unauthorized access. This affects you as an Exchange administrator because the methods put in place to keep unwanted outsiders from connecting to your network must often allow connection by any Exchange users outside the network. For example, you may want traveling employees to be able to connect to their mailboxes over the Internet. This section describes several methods used for securing network access.

Authentication

If users are authenticated with a Windows Server 2003 domain controller using Kerberos v5, then those users are automatically granted the appropriate access to Exchange objects without having to be authenticated again. If users are not authenticated by a domain controller, they must be authenticated by another means. For example, a user connecting to an Exchange server over the Internet with a POP3 client would not necessarily be authenticated by a domain controller.

If authentication is not already granted to a user, a virtual server (such as the POP3 server) may authenticate the user instead. Each virtual server on an Exchange server can be configured to use different forms of authentication. With the exception of HTTP, you can configure the authentication method for all protocols by opening the property pages for the appropriate virtual server in System Manager and switching to the Authentication page.

Virtual servers support the following forms of authentication:

Anonymous Anonymous authentication allows any user to access the virtual server without providing a username or password.

Basic (Clear-Text) Basic (Clear-Text) authentication requires the user to submit a valid Windows username and password. The username and password are sent across the network as unencrypted clear text.

Basic over Secure Sockets Layer (SSL) Basic over Secure Sockets Layer (SSL) authentication extends the Basic authentication method by allowing an SSL server to encrypt the username and password before they are sent across the network.

Integrated Windows authentication Integrated Windows authentication also requires the user to provide a valid Windows username and password. However, the user ‚ s credentials are never sent across the network. If you are running a Windows Server 2003 network that is still at the Windows 2000 Server mixed domain functional level, this method uses the NTLM authentication protocol used by Windows NT 4.0. If your network is running at the Windows 2000 Server native domain functional level (or higher), this method uses Kerberos v5.

Firewalls

A firewall is a set of mechanisms that separates and protects your internal network from unauthorized external users and networks. Firewalls can restrict inbound and outbound traffic, as well as analyze all traffic between your network and the outside. Different criteria can be used by a firewall to analyze traffic, such as IP addresses and TCP/IP port numbers. The remainder of this section covers port numbers and example security scenarios that use a firewall.

Port Numbers

A port number is a numeric identifier used to route packets to the correct application on a computer. Just as Media Access Control (MAC) addresses are used to deliver frames to the correct physical computer (actually to the network adapter) and IP addresses are used to route packets to the correct logical computer (e.g., 147.4.56.76), port numbers are used to route a packet to the correct application after the packet has arrived at its destination computer. Multiple applications often run on a single server. When a packet arrives at that server, it cannot be delivered to just any application. For example, POP3 client requests are not going to be understood by an LDAP server application.

Port numbers range from 1 to over 65,000. Most established Internet protocols have assigned port numbers, referred to as well-known port numbers , somewhere below port 1024. Table 15.1 lists some of the protocols discussed in this book and their well-known port numbers.

One way a firewall can work is by prohibiting certain port numbers or allowing only designated port numbers to pass through the firewall. This functionality can be used to restrict the applications that can be used to access your network. For example, if a firewall were configured to prohibit port 80, HTTP clients would not be able to pass through the firewall and communicate with any internal virtual servers. Many firewalls are configured to prevent all but the most well-known port numbers (such as those for POP3, HTTP, and SMTP) from passing through. Often, you will have to open specific ports in order to let the proper traffic pass.

For an extra measure of security, you can usually change the port numbers that an application uses. For example, you might change your POP3 virtual server and all POP3 clients to use port 28,345 instead of the default 110. The downside of doing this is that you will have to manually change any application that will need to communicate with the server. Exercise 15.1 outlines the steps for changing the regular and SSL port numbers for the POP3 virtual server.

Table 15.1: Protocols and Their Well-Known Port Numbers

Protocol

Port Numbers

SMTP

25

DNS

53

HTTP

80

Kerberos v5

88, 750 ‚ 754

MTA - X.400 over TCP/IP

102

POP3

110

NNTP

119

RPC

135

NetBIOS name service

137

IMAP4

143

IRC

194

LDAP

389

HTTP (over SSL)

443

SMTP (over SSL)

465

NNTP (over SSL)

563

LDAP (over SSL)

636

IMAP (over SSL)

993

POP3 (over SSL)

995

Instant Messaging

2890

Global Catalog lookup

3268

EXERCISE 15.1: Changing Port Numbers for a POP3 Virtual Server
  1. Click Start > Programs > Microsoft Exchange > System Manager.

  2. Expand the administrative group and server that contain the virtual server you want to modify.

  3. Expand the Protocols container and then the POP3 container.

  4. Right-click the POP3 virtual server object you want to modify, and select Properties from the context menu.

  5. On the General page, click the Advanced button.

  6. Select the IP address for which you want to change the port number, or leave the default All Unassigned option selected.

  7. Click the Edit button.

  8. In the TCP Port and SSL Port fields, type the new port numbers you want to use. Make sure that the new port numbers do not conflict with the port numbers in use by any other application.

  9. Click OK three times to return to System Manager.

 

Security Scenarios Using a Basic Firewall

Firewalls are useful in a number of ways, some of which are illustrated in the following scenarios.

Scenario 1

You have just configured your Exchange server for IMAP4 client access. IMAP4 clients can be authenticated with either the Basic (Clear-Text) or Basic over SSL authentication method. The administrator of your firewall tells you that the firewall will allow traffic from SMTP (port 25), IMAP4 (port 143), and HTTP (port 80). For what additional traffic must the firewall be configured to allow your Exchange server IMAP4 configuration to be used?

Because the Exchange server is using SSL as one of its authentication methods, IMAP over SSL (port 993) would also need to be opened on the firewall.

Scenario 2

A new Exchange server has been installed and configured for LDAP, HTTP, and POP3. The network project plan calls for allowing the following clients to access this server: LDAP, web software using Integrated Windows NT, POP3, and Microsoft Outlook using secure passwords. You refer to the current firewall configuration and see that it is open to DNS, HTTP, SMTP, and ports higher than 1023. What, if anything, must you do to enable the desired Exchange clients to pass through the firewall?

You must open LDAP (port 389), POP3 (port 110), and the RPC Endpoint Mapper Service (port 135). Without these changes, the firewall would not allow traffic from LDAP, POP3, or Exchange MAPI clients (which Outlook is).

Scenario 3

In each of the next three scenarios (including this one), you will see the same starting situation. But each scenario requires different mandatory and optional results, and it presents different possible courses of action.

CURRENT SITUATION

Your Exchange server is using TCP/IP and is configured with LDAP, HTTP, and POP3. A firewall sits between your network and the Internet. Your Exchange server has its name and IP address entered into a public DNS server on the Internet.

Your network ‚ s firewall prohibits traffic on all ports that are not explicitly allowed. The open ports are port 25 (SMTP), port 53 (DNS), port 80 (HTTP), and all ports greater than port 1023.

REQUIRED RESULTS

Management requires that users be able to connect over the Internet to your Exchange server using Microsoft Outlook and LDAP applications. Policy dictates that passwords be transmitted in a secure manner.

OPTIONAL RESULTS

While not required, management would like web clients that do not support Integrated Windows authentication to be able to connect to your Exchange server. Another preference is for POP3 clients to connect to the Exchange server and download their messages.

PROPOSED COURSE OF ACTION

One proposed course of action is to do the following:

  • Assign port numbers to the Exchange Directory Service and Information Store. Then allow those ports through the firewall.

  • Configure LDAP on the Exchange server to allow Anonymous access.

  • Configure the Exchange protocols to use SSL as an authentication method.

Allow SSL traffic through the firewall.

Allow LDAP traffic (port 389) through the firewall.

Allow RPC traffic (port 135) through the firewall.

Allow POP3 traffic (port 110) through the firewall.

See Figure 15.1 for a depiction of this scenario.


Figure 15.1: Scenario 3 illustrated
RESULTS OF THE PROPOSED ACTIONS

This course of action would meet both required results and both optional results. The key actions were forcing Exchange to use fixed port numbers for the DS and IS, configuring SSL on the Exchange server, and enabling the firewall to allow LDAP, POP3, SSL ports, RPC, and the fixed port numbers for the DS and IS.

Scenario 4

As mentioned, the following current situation, required results, and optional results are the same as above. The difference in this scenario is the proposed actions and, possibly, the results of those actions.

CURRENT SITUATION

Your Exchange server is using TCP/IP and is configured with LDAP, HTTP, and POP3. A firewall sits between your network and the Internet. Your Exchange server has its name and IP address entered into a public DNS server on the Internet.

Your network ‚ s firewall prohibits traffic on all ports that are not explicitly allowed. The open ports are port 25 (SMTP), port 53 (DNS), port 80 (HTTP), and all ports greater than port 1023.

REQUIRED RESULTS

Management requires that users be able to connect over the Internet to your Exchange server using Microsoft Outlook and LDAP applications. Policy dictates that passwords be transmitted in a secure manner.

OPTIONAL RESULTS

While it is not required, management would like web clients that do not support Integrated Windows authentication to be able to connect to your Exchange server. Another preference is for POP3 clients to be able to connect to the Exchange server and download their messages.

PROPOSED COURSE OF ACTION

One proposed course of action is to do the following:

  • Assign port numbers to the Exchange Directory Service and Information Store. Then allow those ports through the firewall.

  • Configure LDAP on the Exchange server to allow Anonymous access.

  • Allow LDAP traffic (port 389) through the firewall.

RESULTS OF THE PROPOSED ACTIONS

This course of action would not meet the required results because port 135, used by the Mapper service, is not open on the firewall, and there is no capability to use secure passwords. Only one of the optional results is met, namely web access to your server (that ability was already inherent in the current situation). The POP3 optional result is not met because POP3 is not allowed through the firewall.

Scenario 5

The final scenario presents the same situation as the previous scenario but proposes a different course of action.

CURRENT SITUATION

Your Exchange server is using TCP/IP and is configured with LDAP, HTTP, and POP3. A firewall sits between your network and the Internet. Your Exchange server has its name and IP address entered into a public DNS server on the Internet.

Your network ‚ s firewall prohibits traffic on all ports that are not explicitly allowed. The open ports are port 25 (SMTP), port 53 (DNS), port 80 (HTTP), and all ports greater than port 1023.

REQUIRED RESULTS

Management requires that users be able to connect over the Internet to your Exchange server using Microsoft Outlook and LDAP applications. Policy dictates that passwords be transmitted in a secure manner.

OPTIONAL RESULTS

While it is not required, management would like web clients that do not support Integrated Windows NT authentication to be able to connect to your Exchange server. Another preference is for POP3 clients to be able to connect to the Exchange server and download their messages.

PROPOSED COURSE OF ACTION

One course of action would be to do the following:

  • Assign port numbers to the Exchange Directory Service and Information Store. Then allow those ports through the firewall.

  • Configure LDAP on the Exchange server to allow Anonymous access.

  • Allow LDAP traffic (port 389) through the firewall.

  • Allow RPC traffic (port 135) through the firewall.

RESULTS OF THE PROPOSED ACTIONS

This course of action would meet one of the required results, namely allowing Microsoft Outlook and LDAP clients to access the Exchange server. The second required result, secure passwords, is not met because an authentication method using SSL is not used. Only one of the optional results is met, namely web access to the server. The other optional result, POP3 client access, is not met because the firewall does not allow POP3.

Firewalls and Front-End/Back-End Servers

In addition to the basic use of firewalls outlined previously, the introduction of front-end servers and back-end servers in Exchange Server 2003 presents other possible configurations for the use of firewalls. There are three basic configurations that you can use, each offering a different level of security.

Using a Firewall between a Front-End Server and a Back-End Server

In this configuration, a front-end server sits outside the firewall for your network, as shown in Figure 15.2. This type of configuration can be useful for authenticating and then redirecting clients using different protocols to various back-end servers behind the firewall. Keep in mind, though, that no firewall protects the front-end server.


Figure 15.2: Firewall between a front-end and a back-end server

Figure 15.2 illustrates the following process:

  1. A POP3 client connects to the front-end server using port 110.

  2. The front-end server connects to the Global Catalog through the firewall over port 3268 and identifies the correct back-end server to receive the POP3 request.

  3. The front-end and back-end servers communicate using HTTP over port 80.

  4. The front-end server returns the information to the client using port 110.

Using a Firewall between a Client and a Front-End Server

In this configuration, the front-end server sits inside the network firewall, as shown in Figure 15.3. This method offers a higher level of security for the front-end server than placing it outside the firewall but also requires more configuration of the firewall. Instead of having to open just two ports (3268 for the Global Catalog and 80 for the HTTP communications between front and back-end servers), you must open a port for each type of communication that you want to allow. For example, to allow POP3, IMAP, and HTTP clients to connect, you would have to open ports 110, 143, and 80.


Figure 15.3: Firewall between clients and a front-end server
Placing the Front-End Server in a Perimeter Network

One highly secure firewall configuration calls for placing two firewalls between the outside world and your private network. A front-end server is then placed between the two firewalls, as shown in Figure 15.4. The area between the two firewalls is commonly referred to as a perimeter network or a demilitarized zone (DMZ) . When using this configuration, you must open all ports on the outside firewall for the clients that should be able to connect to the front-end server (i.e. POP3, IMAP, or HTTP) and then open ports 3268 and 80 on the interior firewall so that the front-end server can query the Global Catalog and pass information to the back-end server. Also, if you are using Kerberos V5 authentication, you must open port 88 on both firewalls.


Figure 15.4: A perimeter network

Viruses

Viruses can enter a system in a number of ways ‚ through an infected file on a floppy disk that someone brings in, by downloading a file from the Internet, through e-mail, and even through shared documents. Most networks implement a number of virus protection schemes that work together to help prevent the problems viruses can cause. Some of these schemes are as follows :

  • Virus protection built into the network firewall that tries to prevent viruses from entering the network in the first place.

  • Virus software that works with Exchange Server 2003 to scan all messages transferred through Exchange.

  • Virus scanning software on servers and clients that examines files as they are transferred or used and examines messages as they are received by a client application. However, messages that are encrypted for security cannot be effectively scanned for viruses, allowing those messages to slip through the firewall and Exchange Server virus scanners . One great advantage this scheme has over the others is that once a message is decrypted on the client computer, any virus protection on that computer can scan the contents of the message and any attachments.

Exchange Server 2003 provides a new and more robust version of the Virus Scanning API (VSAPI) , allowing antivirus products developed for Exchange Server 2003 to run on servers that do not typically host any mailboxes, such as gateway servers and bridgehead servers. As well, the new VSAPI allows antivirus products to automatically delete an infected message and send a notification, if desired, to the sender of that infected message.




MCSA[s]MCSE
MCSA[s]MCSE
ISBN: 735621527
EAN: N/A
Year: 2004
Pages: 160

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