E-Mail

Designing network security for e-mail centers on separating inbound and outbound mail and providing for network virus scanning. This separation is made both for security and to ensure quick delivery of messages without requiring internal users to go outside for mail messages or external senders to come inside the firewall to deliver mail. Network antivirus (in the form of server-based e-mail filtering) is strongly recommended for e-mail because e-mail is the most common infection point for viruses. In the event that a new virus attacks your systems, you can update the signatures on the mail servers quickly to stop further infection. In addition to stopping virus spread internally, antivirus protection prevents the virus from attacking other networks through your systems. Without antivirus filtering on the e-mail servers, you must update the signatures on each and every host, lengthening the process and increasing the risk that serious damage can be done before you are able to stop it.

Basic Two-Tier E-Mail Design

As shown in Figure 8-1, the standard design uses an internal mail server and an external mail server. This design is most appropriate for midsize organizations based on the amount of server resources utilized. Smaller organizations can use this as well, or they might elect to host their e-mail service at an Internet service provider (ISP).

Figure 8-1. Standard Two-Tier E-Mail Design

As shown in this design, Simple Mail Transfer Protocol (SMTP) servers outside the organization send mail to the external SMTP server, which in turn routes the messages to the internal mail server. This external server is also configured to allow the internal mail servers to route messages through it by using SMTP. In this way, the external mail server is the source of all internal and external mail for the organization. SMTP can be blocked at the firewall to prevent any other systems from sending mail using SMTP.

The internal mail server must perform two functions as well. First, it allows intraorganization mail to route between systems. This allows two users on the internal network to talk to one another without involving the external server. This way, even if the external server is compromised, the attacker is unable to read messages within the organization without compromising the internal mail server as well. Second, this server forwards traffic destined for outside the organization to route through the external SMTP server. This internal server is typically running SMTP and Post Office Protocol 3 (POP3)/Internet Message Access Protocol (IMAP).

NOTE

Adding antivirus (AV) to a basic two-tier e-mail design is pretty straightforward. In most cases, you can add the e-mail AV software on the mail servers directly. This gives you the exact same topology, just with AV scanning occurring as traffic routes from user to user or from server to server.

 

Distributed Two-Tier E-Mail Design

This design (Figure 8-2) is used in larger networks. The key differences from the basic design are as follows:

• Different servers for POP3/IMAP versus SMTP, which allows greater scalability for your e-mail system
• Dedicated servers for e-mail antivirus processing

Figure 8-2. Distributed Two-Tier E-Mail Design

The biggest difference from the previous design is the addition of an antivirus mail layer. This layer scans all incoming and outgoing messages and can comprise several servers, depending on the size of your mail system. AV scanning sits on the internal servers as well, but only for intraserver traffic that has no need to route through the antivirus layer. This keeps the AV load on internal servers small. The types of organizations that should adopt this design typically have many (10+) internal mail servers and several inbound mail relay hosts.

In the event of a zero-day virus outbreak, the antivirus layer should be the first servers to which you add the signature. This prevents any additional inbound infected messages and keeps your organization from sending infected messages externally. Next you must update your internal servers to prevent the virus from spreading to users sharing the same mail server.

Access Control Example

After showing the two sample designs, it is useful to see how these topologies translate into specific access control rules to enforce the policy. Figure 8-3 shows a topology that uses the distributed design as a base and assumes six internal mail servers, two antivirus servers, and two external mail servers.

Figure 8-3. Distributed Two-Tier E-Mail Design

The firewall access control policies to implement this design are as follows. Only the mail-related portions of the access control list (ACL) are shown. Bogon and ingress filtering are excluded for clarity. Stateful filtering is assumed, so the return traffic in a conversation is implicitly permitted.

Inbound on the inside interface:

!Permit the AV layer to send traffic to the external servers using SMTP
access-list 101 permit tcp host 10.8.8.5 host 192.0.2.50 eq 25
access-list 101 permit tcp host 10.8.8.5 host 192.0.2.51 eq 25
access-list 101 permit tcp host 10.8.8.6 host 192.0.2.50 eq 25
access-list 101 permit tcp host 10.8.8.6 host 192.0.2.51 eq 25
!Deny all other SMTP traffic from the internal network, outbound
access-list 101 deny tcp any any eq 25

Inbound on the outside interface:

!Permit outside mail servers to send messages via SMTP, only when
!talking to the external mail servers.
access-list 102 permit tcp any host 192.0.2.50 eq 25
access-list 102 permit tcp any host 192.0.2.51 eq 25
access-list 102 deny tcp any any eq 25

Inbound on the public services interface:

!Permit external mail servers to relay messages to the AV layer.
access-list 103 permit tcp host 192.0.2.50 host 10.8.8.5 eq 25
access-list 103 permit tcp host 192.0.2.50 host 10.8.8.6 eq 25
access-list 103 permit tcp host 192.0.2.51 host 10.8.8.5 eq 25
access-list 103 permit tcp host 192.0.2.51 host 10.8.8.6 eq 25
!Prevent external mail servers from relaying mail to any other internal system.
access-list 103 deny tcp any 10.8.8.0 0.0.0.255 eq 25
!Allow external mail servers to send messages to outside mail servers.
access-list 103 permit tcp host 192.0.2.50 any eq 25
access-list 103 permit tcp host 192.0.2.51 any eq 25
!Deny all other SMTP
access-list 103 deny tcp any any eq 25

 

Mail Application Design Recommendations

Although this list is far from comprehensive, here are a few big-ticket items you should be sure to accomplish in the application configuration for your e-mail systems:

• Allow your external servers to relay mail outbound only when it comes from internal servers. Without this protection, anyone on the Internet could use your external servers as blind relays, allowing for spam and other forged e-mail.
• Lock down the SMTP relay application. If you are using sendmail, Sendmail by Bryan Costales (O'Reilly, 2002) includes a chapter on hardening your configuration that you should read. Numerous guides are also available online.
• Some firewalls offer application inspection into SMTP. This inspection often limits the SMTP commands that an outside mail server can use when forwarding mail to your server. Similar to turning off unneeded services on a host, this filtering further narrows the possible attack vectors within the SMTP listener. The minimum commands required are identified in section 4.5.1 of RFC 2821 as EHLO, HELO, MAIL, RCPT, DATA, RSET, NOOP, QUIT, and VRFY.

NOTE

In addition to the security guidelines outlined here, e-mail solutions that offer secure communications over standard mail protocols exist. Solutions such as Pretty Good Privacy (PGP) and Secure Multipurpose Internet Mail Extensions (S/MIME) offer users the ability to send cryptographically secure communications over a cleartext protocol such as SMTP. Deployment issues with these solutions center on key management and user education. As a secure network designer, you might suggest the use of these solutions for certain user groups that have a defined need.

Additionally, by using the same designs defined here, antispam or other content filtering can be implemented in the same place that AV is implemented.