Modern ISPs use a variety of technologies to connect to customers. Smaller sites may use the same technology as households: a broadband cable modem connection, optical fiber, or a DSL connection. Larger sites may use special, dedicated lines via either copper or optical connections. Many cell phone companies also offer wireless broadband connections to the internet.

When choosing an ISP, the enterprise needs to consider the amount of internet traffic it needs to support. If the enterprise deploys and manages its own internet servers on-site, then the POP must handle incoming web traffic as well as outbound browser traffic and email.

When there is a single POP, the ISP treats the enterprise as an autonomous system for routing purposes; all inbound and outbound traffic is routed through the central gateway. Enterprise routing also becomes more complex when there are multiple internet connections.

The enterprise must arrange its internet POP to provide both safe and efficient access. There are countless ways to arrange enterprise resources around the POP. The goal is to provide effective outbound access to the internet and effective inbound access to internet-visible enterprise services.

Many sites place internet-visible servers on a special LAN segment called the demilitarized zone (DMZ). The name refers to the “no man’s land” between two opposing armies that hold an uneasy truce. Although the analogy isn’t perfect, the term captures the risky nature of network traffic on the DMZ.

Because outsiders may visit servers on the DMZ, those servers face significantly higher risks than elsewhere on the enterprise network. The POP’s arrangement seeks to restrict all risky traffic to the DMZ. Some experts also refer to the DMZ network as a screened subnet, because the network is behind an enterprise firewall, but not directly connected to the internal enterprise network.

A site’s gateway firewall provides an excellent place to watch for attacks. Even though firewalls try to block attacks by explicitly allowing or blocking specific types of traffic, an intrusion detection system, or IDS, searches for more subtle indications of an attack. Several companies offer commercial IDS products, and there is also the open-source product “Snort.”

Many products, including Snort, use a technique similar to those used by antivirus programs: They look for patterns in the data that distinctively show up in particular attacks. The network administrator may configure the IDS to try to block the traffic associated with the attack, or at least to sound an alarm. Like antivirus software, a pattern-matching IDS won’t detect attacks for which there is no preinstalled pattern.

Some products use a statistical approach; they develop profiles of normal network traffic and report unusual changes. This technique can detect new attack techniques without installing new patterns. On the other hand, it won’t detect an attack that doesn’t affect the network traffic features that it monitors.

There also are distributed IDS systems that collect reports from intrusion sensors spread around the network. The reports go to a central host that may apply either pattern matching or statistical techniques to try to detect intrusions.

A fundamental problem with any pattern-oriented detection technique is that it must be fine-tuned to avoid false alarms. This problem applies to the statistical IDS techniques as well. If the system is too sensitive, it will detect numerous attacks, many of which will be false alarms. If we make the system less sensitive, we receive fewer false alarms but face a greater risk of not detecting an actual attack.

A generic IDS simply reports a problem; it doesn’t respond to it. An intrusion prevention system detects an intrusion and automatically implements security measures to block its operation. The simplest case would be to activate filters that block communications with an attacking host. More sophisticated systems may redirect vulnerable traffic or isolate infected host computers.

Vendors also offer data loss prevention systems; instead of looking for inbound intrusions, they watch for unexpected and undesirable outbound data flows. Although some techniques analyze network traffic to detect leaking data, other techniques examine hosts to try to identify and inventory sensitive data, making it easier to track and protect.

We used this topology when implementing the firewall controls shown in Table 14.4. There is no DMZ; all enterprise servers are inside the firewall. We provide specific firewall rules to focus all inbound internet traffic to authorized servers. The simple firewall introduced in Section 12.4 (Figure 12.15) implements this topology.

FIGURE 14.14 illustrates an older technique that is less common today. The bastion host is a strongly secured host that provides services to the internet. It relies on careful host configuration and up-to-date patches to resist attacks from the internet.

When a modern site deploys a bastion host, the bastion provides internet services. A separate firewall protects the internal enterprise network from internet-based attacks. This requires a relatively simple firewall configuration, but it requires very careful administration of the bastion host.

In older sites, the bastion served as the site’s firewall, as well as hosting internet services. The internal network connected to the bastion, and it applied firewall filtering to all inbound and outbound traffic.

Sites rarely use bastion hosts today; typical sites deploy servers on a DMZ. However, most sites “harden” their internet servers, despite firewall protection, because firewalls can’t prevent the entire range of internet attacks.

The three-legged firewall uses a single device to provide separate connections to the ISP, to the internal enterprise network, and to a separate DMZ. FIGURE 14.15 shows a typical configuration. The arrows show the general policy for allowing connections. All internet traffic is allowed to reach the DMZ hosts, but it is blocked from making inbound connections to the internal network. Outbound connections can go to the DMZ or to the internet.

Because the firewall controls access between all three networks, it can also restrict administrative access to the DMZ. The firewall can restrict or block network management protocols from moving between the internet and the DMZ, and exchange management protocols only with the internal network. Unfortunately, however, a great deal of administration now takes place via HTTP, and we must allow HTTP traffic onto the DMZ from the internet.

The dual-firewall topology uses one firewall to protect the entire enterprise from the internet and a second firewall to protect the internal network from the DMZ. This arrangement is also called a screened subnet. FIGURE 14.16 illustrates the topology. Dual firewalls can enforce the same policies as a three-legged firewall.

Sites may choose this design because a three-legged firewall lacks the performance required. Others choose it because they prefer the Defense in Depth inherent in having two separate devices. Some experts argue that the best approach uses two separate brands of firewalls, because flaws present in one product might not be present in the other.

Although dual firewalls may have security and performance benefits, they also may be harder to manage. Each has its own set of firewall rules, but the rules must be coordinated to enforce the site’s internet connection policy correctly.

Over the Christmas vacation in 1994, an intruder broke into computers in the San Diego Supercomputer Center. A particular target seemed to be a computer belonging to Tsutomu Shimomura, a security expert who had demonstrated how to reprogram an analog cell phone to eavesdrop on all nearby conversations. The firewall did not detect the attack because the packets appeared to come from inside the site: The source IP addresses were for internal computers. The attack used IP spoofing, described earlier in Section 12.2.2.

The stream of packets aimed a long series of SYN and ACK packets at one of Shimomura’s machines, trying to guess TCP sequence numbers. Finally, the packets struck home and the computer accepted a shell command carried by the attack. The command opened a back door that allowed the attacker into the machine. The attack eventually was attributed to Kevin Mitnick, who was captured and arrested after a lengthy investigation and search.

In a different case, attackers discovered that they could bypass packet filters if the IP packets were broken into two oddly structured fragments. In particular, the packets were too small for the firewall to locate the TCP and UDP port numbers. The firewall checked the first packet in the fragment and let the second packet go through, assuming that it already had checked the port numbers.

In both cases, the firewall allowed attacks through because the attackers took unexpected steps. In the first case, the attacker sent TCP packets with internal IP addresses. In the second case, the attacker sent packets that didn’t appear to carry port numbers.

Network protocol designers try to make protocols as simple as possible. Simpler protocols are easier to analyze, which makes it easier to find potential problems like these. As we find protocol problems, we modify firewall configurations and rules and patch our protocol stacks to block attacks that they might support.

Tunneling poses a particular challenge for many sites. Site policies generally permit or deny traffic flow based on the application being used; many sites allow DNS, email, file transfer, and web traffic. Firewalls generally enforce this by looking at port numbers in the traffic. If a firewall sees port 80, for example, it assumes the connection carries a web transaction.

In practice, however, the endpoint hosts may use port 80 to carry whatever traffic they want. This is the essence of tunneling: Two endpoints use an existing protocol standard to carry different traffic. Some firewalls use proxies to examine traffic more closely and ensure that it contains web-like transactions. Some tunneling software circumvents even this level of filtering by embedding their traffic inside web traffic.

Some more-or-less legitimate vendors of gaming or instant message applications use tunneling to circumvent firewalls that would otherwise filter out their traffic. Although network managers may see this as a policy violation, vendors often see this as an improvement in reliability. In some cases, the policy might not have been intended to block their application’s traffic and the tunneling ensures reliable connectivity.

It can be very difficult to detect and block undesired tunneling. If the vendor combines tunneling with SSL encryption, there is no practical way to distinguish a legitimate SSL connection from unauthorized tunneling.