common design elements. mail relay a mail relay is one means to help secure your environment's...

COMMON DESIGN ELEMENTS

Mail Relay A mail relay is one means to help secure your environment's email functionality.

Mail can be passed into your environment using a properly configured external

mail relay server to forward inbound messages to a separate internal mail

system.

To accomplish this, you install mail-relaying software on a bastion host that is

accessible from the Internet.

You then configure the relay to forward all inbound messages to the internal

mail server, which, in turn, delivers them to the organization's internal users.

Splitting the mail server into two components allows you to place them into

separate security zones.

Justifying Mail Server Separation

Instead of implementing a store-and-forward configuration to

separate mail functions into two components, we could have used a

single mail server to attend to internal users and accept email from

the Internet.

This setup eliminates the cost of deploying and maintaining an

additional host, but it increases the risk that an external attacker

might get access to the company's sensitive information.


it often makes sense to separate public systems from the internal

ones to sandbox an attacker who gains access to an Internet-

accessible server.

Additionally, modern mail systems such as Microsoft Exchange,

which are commonly used within a company, are complex and

feature rich. Hardening such software so that it is robust enough to

be accessible from the Internet is often difficult.


1. Splitting the public-facing component of the server from the internal

mail distribution system allows us to place these resources into

separate security zones. This offers many benefits over a

configuration that integrates the two components into a single

system:

2. We can use different software for each component in a manner

that is optimized for the component's tasks and risk factors.

3. We can isolate the most vulnerable component in a way that limits

the extent of a potential compromise.


4. We can have higher confidence that we tightened the relay's

configuration appropriately because its software is relatively

straightforward.

4. We can allow ourselves granular control over how tightly each

component is configured and how it can be accessed over the

network.

Implementing a Mail Relay

A common configuration for implementing a mail relay is illustrated in Figure next.


As you can see, we have placed the mail-forwarding agent into the

Public Servers zone, which was set up as a screened subnet.

The internal mail server was placed on the Corporate zone to be

used by internal users when sending and receiving email

messages.

To ensure that messages from the Internet are delivered to the mail

relay server, the organization's DNS server set the mail exchange

(MX) record for the company's network to point to the relay server.


The primary function of the mail relay is to receive messages from

the outside and forward them to the internal mail server.

To further isolate the internal mail server from the Internet, you

might want to route outbound messages through the mail relay as

well.

Making outbound connections is not as risky as accepting inbound

ones, but fully separating the internal server from the outside helps

decrease the likelihood that it will be adversely affected by a system

on the Internet.

Implementing a Mail Relay In this configuration, the internal mail server accepts messages from internal

workstations and servers and forwards those that are Internet-bound to the

mail relay in the Public Servers zone.

One of the advantages of splitting Internet-facing mail functionality away

from the internal mail server is that it allows us to use different software

packages for each component of the mail infrastructure.

For instance, a Microsoft Exchange server might have the desired

functionality for an internal server, but you might consider it too feature

loaded for a simple mail-forwarding agent. In that case, you might want to

use software you feel more comfortable locking down, such as Sendmail,

Postfix, or Qmail, to implement the mail relay.

Implementing a Mail Relay Specifics for configuring a mail relay to forward inbound messages

to the internal server and outbound messages to the appropriate

system on the Internet differ with each software vendor. In most

cases, you need to specify the following parameters on the mail

relay:

1. The name of the domain for which the forwarder is relaying mail. If

you don't specify this, the mail relay might reject inbound messages,

thinking they are destined for somebody else's domain.


2. The name or addresses of internal systems from which you accept

outbound mail messages. To prevent internal SMTP clients from

accessing the relay directly, you should consider limiting this to include

only your internal mail server.

3. The name or address of the internal mail server to which inbound

messages will be forwarded.

You should also consider implementing masquerading features on

the relay server, especially if multiple internal servers need to send

outbound mail through the relay.

Implementing a Mail Relay The Enterprise editions of the Microsoft Exchange 2000 and

Windows 2003 Server support a distributed topology that allows you

to set up a front-end server that acts as a relay for mail-related

communications and forwards them to the back-end server that

actually maintains users' mailboxes.

Microsoft recommends that the front-end server be fully configured

before placing it into the DMZ or a screened subnet:

Implementing a Mail Relay If you are interested only in relaying SMTP and do not require POP, IMAP,

and Outlook Web Access (OWA) functionality of Microsoft Exchange,

you could use the SMTP Virtual Server built in to Microsoft's Internet

Information Services (IIS) as the mail relay.

Such configuration will generally cost less to deploy because you are not

required to purchase the Enterprise Edition of Microsoft Exchange 2003

Server. As shown in Figure next.

The SMTP component of IIS offers highly configurable mail-relaying

functionality, and it can be set up with most of the other functionality built

in to IIS disabled.

Split DNS The DNS service, which maps hostnames to IP addresses, and vice

versa, is a principal component of many networks.

Split DNS configuration, which is also sometimes called Split

Horizon DNS.

This is a relatively common design pattern that calls for separating

the DNS service into two components: one that is available to

external Internet users, and another that is used internally within the

organization.

Split DNS One of the purposes of Split DNS is to limit what information about

the network's internal infrastructure is available to external users.

If an Internet-accessible DNS server hosts your public and internal

records, an external attacker might be able to query the server for

hostnames, addresses, and related DNS information of your internal

systems.

The attacker can issue targeted lookup requests for a specific

domain, hostname, or IP address, or attempt to retrieve the

complete DNS database through a zone transfer.

Justifying DNS Server Separation

When deciding where to place DNS servers and whether to split DNS

servers into multiple security zones, consider two primary types of

users of DNS services:

1.Users on the Internet who need to be able to obtain DNS information

of publicly accessible systems hosted on your network. In addition to

being able to resolve hostnames of your public systems, external hosts

use DNS to obtain the name and address of the MX server.


2. Internal users within your network perimeter who need to be able to

obtain DNS information of hosts on the Internet as well as of hosts on the

intranet. If a DNS server does not know the answer to the internal user's

query, it can connect to external DNS servers to find out the answer; this

action is known as a recursive query. Alternatively, the DNS server can

simply forward the request to a predefined DNS server that will perform

the necessary recursive queries and return the final answer to the initial

DNS server.

DNS servers catering to different audiences vary in the sensitivity of

data they require for useful operation.

DNS Spoofing Attacks DNS is an attractive target for spoofing, or poisoning attacks

through which attackers attempt to propagate incorrect hostname-

to-IP-address mappings to the DNS server.

Such attacks, in various forms, have been known to affect DNS

software from most vendors.

Because DNS queries are typically submitted over UDP, servers

cannot rely on the transport protocol to maintain the state of the

DNS connection.

DNS Spoofing Attacks Therefore, to determine which response matches to which query,

DNS servers embed a numeric query ID into the DNS payload of the

packet.

If an attacker is able to predict the query ID the DNS server used

when directing a recursive query to another DNS server, the

attacker can craft a spoofed response that might get to the asking

server before the real one does.

The DNS server usually believes the first response it receives,

discarding the second one as a duplicate.

DNS Spoofing Attacks Consequently, the host that uses the DNS server to look up the spoofed

domain record is directed to the IP address of the attacker's choice.

Predicting DNS query IDs was relatively easy in older versions of DNS

software because it tended to simply increment the IDs by one after

each query.

Another variation of the DNS spoofing attack is effective against servers

that happily cache a DNS mapping even if they received it as additional

information in response to a query that was completely unrelated to the

spoofed record. By default, DNS server software that comes with

Windows NT and 2000 is vulnerable to this attack.

The Secure Cache Against Pollution check box (shown in Windows 2000) is not enabled by default

Implementing Split DNS The implementation of Split DNS is relatively straightforward when it

comes to servicing inbound DNS requests from the Internet.

As shown in Figure next, the external DNS server is located in the Public

Servers zone, which is typically set up as a screened subnet or a DMZ.

The external server's database only contains information on domains and

systems of which the outside world should be aware.

Records that need to be accessible only by internal users are stored on

the internal DNS server.

This design decreases the possibility that an attacker can obtain sensitive

information by querying or compromising the external DNS server.

Implementing Split DNS The internal DNS server, in addition to maintaining authoritative

records for internal systems, needs to handle requests from internal

hosts for DNS information about systems on the Internet.

We can configure the internal server to forward such queries to

another DNS server that performs the recursive query.

Frequently, the DNS server located in the Public Servers zone plays

this role. Alternatively, we can configure the internal DNS server to

perform recursive queries.

Implementing Split DNS Consider a scenario in which the internal DNS server forwards

queries for Internet records to our external server.

In this case, the internal DNS server is maximally isolated from the

Internet .

The external DNS server, of course, needs to be configured to

accept recursive queries only if they come from the internal DNS

server.

Implementing Split DNS Unfortunately, in this scenario, the internal server relies on the

server in the Public Servers zone to handle such requests. That is

the same server we deem to be under increased risk because it

accepts DNS requests from external hosts.

If an attacker compromises the external DNS server or manages to

spoof its DNS records, the internal DNS server might receive

fabricated answers to its queries.

An alternative configuration permits the internal DNS server to

perform recursive queries.

Implementing Split DNS

If you use a server in the Public Servers zone to process outbound DNS

requests, you are not protected against attacks such as DNS cache poisoning

because spoofed information might be propagated to the internal DNS server.

If you are willing to accept the risk that a compromise to the external DNS

server might impact the ability of your internal users to resolve Internet

hostnames, consider relaying outbound DNS requests through the server in

the Public Servers zone. In a best-case scenario.

you would actually use three DNS servers: one for servicing external users,

one for answering queries for internal domains, and one for performing

recursive queries about Internet systems.

Client Separation As we mentioned previously, resources should be placed together

based on their level of acceptable risk.

One example of a set of resources in most business environments

that share a similar acceptable risk is the client network, where end-

user workstations and their ilk reside.

However, as networks became more and more complicated and

businesses had a need for outside users to contact their servers, it

became apparent that in most environments, servers needed to be

split off into their own security zones.

Client Separation

Now, in a world filled with Internet worms, mail-transported viruses,

and the like, it is often more likely for a client to propagate a virus

than a server.

Because this places clients at a similar level of acceptable risk, it

makes sense that they all share a security zone of their own. Clients

differ in their level of insecurity, ranging from LAN-connected

desktops, wandering laptops, VPN and dialup remote connectors,

and, finally, wireless clients.

LAN-Connected Desktops LAN-connected desktops usually have the lowest risk of any of our

network's clients.

Although most such clients have Internet access and the potential to

propagate viruses and the like, at least we as administrators have the

capability to force these stations to subscribe to our organization's

security policy.

We can verify that they are properly patched, with up-to-date virus

definitions, and locked down to the best of our abilities, even creating

automated processes that verify that all is well on a daily basis.

LAN-Connected Desktops

Despite all our efforts as administrators, the client PC can still be a

liability to our network's security.

By keeping clients in a separate security zone from internal and/or

Internet available servers, we limit the chances of having our clients

affect the availability of our server networks.

Although having a firewall between our clients and servers requires

additional administration to upkeep the firewall policy, it facilitates a

"chokepoint" to control communications between them and to help

mitigate client risks.

Wandering Laptops, VPN and Dialup Users

A more complicated challenge in many network environments is the

client we can't control.

Whether physically located at our site or connecting in through a

dialup connection or the Internet, it can be very difficult to force

these hosts to subscribe to our security policy.

It is a best practice to segregate all remote users into their own

security zone, preferably behind a firewall.


This will prevent these hosts from contacting resources they

shouldn't, while logging their access to resources they should.

Though dividing these clients into a separate security zone affords

an additional level of protection, it does not confirm that the hosts

follow your security policy.

How can you be sure that the sales rep who is plugging in to a

conference room network jack has the latest virus updates? Or that

a VPN or dialup user has carefully patched all known vulnerabilities

for her version of operating system?


One answer is an initiative like Cisco's Self-Defending Network "A

Unified Security Perimeter: The Importance of Defense in Depth."

It uses Network Admission Control to confirm that any host that

connects to your network meets certain criteria (patched, up-to-date

virus definitions, certain version of the OS, and so on) before

allowing access.

The Wireless Client The wireless client is by far the most vulnerable of the clients.

It has all the vulnerabilities and concerns of other clients, plus is

exposed to possible anonymous connection without physical access

being necessary.

Depending on your requirements, you might consider limiting the

way every wireless node communicates with each other.

Alternatively, in a more cost-effective manner, you might group

wireless nodes with similar security risks into their own security

zones. As shown in Figure next.

The Wireless Client we group all wireless laptops into a single security zone because for

the purposes of this example.

Our laptops do not significantly differ in acceptable risk exposure. (For

this example, each laptop is as likely to be compromised as the other

because of its use and configuration, and each laptop contains data of

similar sensitivity.)

At the same time, we consider wireless nodes to be more vulnerable

to attacks than hosts on the wired segment and therefore decide to

separate wireless and wired systems by placing them into different

security zones.

The Wireless Client In this scenario, wireless and wired machines are hosted on

different subnets, one representing the Corporate zone, and another

representing the Wireless zone.

We use an internal firewall to control the way that traffic passes

between the two subnets.

The firewall ensures that even if an attacker is able to gain Layer 2

access to the Wireless zone or its hosts, her access to the

Corporate zone will be restrained by the firewall's rule set.

The Wireless Client This separation is imperative, not only because of the client issues

of the laptops themselves, but also the vulnerabilities inherent in

wireless technology.

Wireless is the first Layer 2 network medium to which we need to

worry about attackers having remote anonymous access.

Note that wireless access points typically have hub-like

characteristics. This means that any wireless node that gains Layer

2 access to the access point might be able to promiscuously monitor

network traffic on all ports of the access point.

The Wireless Client Placing a firewall between wireless and wired hosts does not protect

you against such attacks because the firewall can only control traffic

that crosses security zones you defined.

To mitigate risks of wireless-to-wireless attacks, you would probably

need to employ personal firewalls coupled with robust VPN

solutions such as IPSec to encrypt and authenticate wireless traffic

in a manner similar to protecting wired traffic that travels across

potentially hostile networks.

common design elements. mail relay a mail relay is one means to help secure your environment's...

Documents

internal mail server

single mail server

mail server separationinstead

mail server separation4

mail server separationit

mail relayas

external mail relay

separate internal mail