Setting the Ground Rules

When you connect an enterprise network to the Internet, one of the first things you must think about is what you want to allow to pass to and from the Internet, and what you don't. Just like you already have an idea of who lives in your neighborhood, and maybe the cars that those neighbors drive, you need to have an idea about what type of traffic can be trusted in terms of your Internet connection. After you figure out what you want to use the Internet connection for, and what you don't want to use it for, you can take action to allow only the trusted types of traffic.

Although it might seem like a difficult task to figure out what should and shouldn't be allowed to pass back and forth from the Internet, some of the first steps are pretty easy to understand and appreciate. Figure 18-1 shows a sample network from which the basics can be explained.

Figure 18-1. An Enterprise Network Connecting to the Internet

On the left is an enterprise network, labeled "Internal IP Network" in the figure. In the internal network, there are users at client PCs, like the one labeled C2. C2 uses the e-mail server and the internal web server, named mail.fredsco.com and int.fredsco.com, respectively. The internal web server has stuff that's only appropriate for employees who work for Fredsco. Finally, the web server called www.fredsco.com is meant for external users, but internal clients such as C2 will also want to browse that web server.

In the Internet side of the figure, you see a typical Internet-based web server (www.example.com) and a typical Internet-based e-mail server (mail.isp1.net). The client PC labeled as C3 represents a typical user on the Internet.

The first task to secure Fredsco's network is to define what is allowed and what shouldn't be allowed. You should keep two things in mind when considering this dilemma:

• Between which two hosts do packets need to flow?

• Which host begins that communication?

After you know which two hosts are involved and which one starts the process, you can determine what data is allowed to flow between the hosts. For example, Figure 18-2 shows the flows that I think should be allowed in the same network shown in Figure 18-1. To keep the figure a little less cluttered, I removed some of the icons so that you could focus on the flows between pairs of hosts. (The term flow refers to packets that are sent from a specific host to another host, and vice versa. For instance, when you browse a web page, packets go between your PC and that web server, and vice versathat's a flow.)

Figure 18-2. Typical Types of Traffic Allowed Between an Enterprise and the Internet

Look at C2 inside the internal Fredsco network. The figure shows lines from the client to almost every server. C2 needs to use POP3 to retrieve mail and SMTP to send mailboth to mail.fredsco.com. C2 needs to browse the internal and external Fredsco web servers, and you also want to allow C2 to get to all Internet websites.

Of course, the traffic flows from C2 don't go over the Internet. What about flows that pass through the Internet? A couple of types of flows are allowed in this case. C3, which is simply a user somewhere in the Internet, is allowed to get to the Fredsco website that's appropriate for external users (www.fredsco.com). Also, the two mail servers are sending packets to each other so that they can exchange mail.

The lines shown between hosts represent flows, but they also imply who initiates the flow. The lines mean that packets can go in either direction between the hosts; otherwise, no useful work could happen. However, the lines without an arrow on one end mean that that host initiated the flow. For instance, C2 only has lines without an arrow on the end near C2, meaning that C2 initiates all the flows shown. The line between the two mail servers shows arrows on both ends, which means that you want to allow either mail server to be able to initiate a flow.

Figure 18-2 shows what's allowed. Now let's consider what's not allowed, in Figure 18-3.

Figure 18-3. Traffic That's Typically Not Allowed

Notice which ends of the lines do not have arrows on them; in other words, focus on the IP host that initiates the flows. In this figure, all the IP hosts that initiate the flows are on the Internet. A lot of what Fred wants to prevent is stuff that's initiated by hosts on the Internet, which makes sense if you think of the bad guys on the Internet who are trying to get into your network. For instance, by definition, you do not want to let Internet users open a browser and browse your internal websites. Also, no one should try to initiate a TCP connection to C2. By definition, clients are hosts with users who typically need to initiate flows, not accept them.

Table 18-1 summarizes and characterizes what Fred wants to happen with security.

Table 18-1. Characterizations of What's Allowed and What's Not

Initiates Flow	Receives Flow	Protocol(s)	Allowed?
Internal client (such a C2)	Any internal server	POP3, SMTP, HTTP, FTP, and so on	Yes
Internal client (such as C2)	www.fredsco.com web server	HTTP	Yes
Internal client (such as C2)	Internet-based servers	HTTP and FTP	Yes
Internal mail server	External mail server	SMTP	Yes
External mail server	Internal mail server	SMTP	Yes
Any internal host	Any Internet host	Any protocols that are not otherwise specified	No
Internet clients	www.fredsco.com web server	HTTP	Yes
Internet clients	Any host inside Fredsco	Any protocols that are not otherwise specified	No

If you don't remember the protocols mentioned in the table, the details are covered in Chapter 8, "Shipping Goods over a (Network) Roadway." For the purposes of this chapter, just remember that e-mail clients use POP3 to retrieve mail, that e-mail servers use SMTP to transfer mail to other servers, that HTTP is used for web traffic, and that FTP is used to transfer files.