- Understanding the Basic Security Concepts of Network and System Devices
- Understanding the Basic Security Concepts of Media
- Understanding the Concepts of Security Topologies
- Case Study: Bright Picture Solutions, Inc.
- Chapter Summary
- Apply Your Knowledge
Understanding the Concepts of Security Topologies
The concepts of security topologies are based on firewalls and their application to specific network design scenarios. Topologies consist of hardware devices and security zones that are created with these devices. The remainder of this chapter provides an overview of how firewalls are used to segment the network into security zones and create various security topologies. The following security topics are covered in more detail in the following sections:
Security zone topologies
The three major types of security topologies are as follows:
Screened host gateway
Screened subnet gateway
Various combinations of these three basic security topologies can yield additional categories that combine the benefits and disadvantages of the fundamental topologies, but for the purposes of our discussion we will concentrate on these three.
A bastion host is a dual-homed devicethat is, a device with two network interfaces. It can be a specialized hardware device (Cisco PIX, Checkpoint Firewall, and so on); a router running access lists (most Cisco and other routers are capable of this); or a PC running Windows 2000 or later, Unix, or another operating system that supports routing rules definitions or traffic-filtering mechanisms. Any routing between the interfaces on the dual-homed device is disabled and specialized software (IP Security in Windows 2000, Cisco IOS, and so on) is configured to allow only certain types of traffic through while excluding the rest of the traffic.
This type of firewall secures the network by filtering communications based on different configurable criteria, such as port numbers (traffic type), source or destination IP addresses or IP subnets, whether the connection is a secondary connection to an already established communication session (file transfer requests of an FTP session), and so on. Regardless of hardware configuration, IP forwarding (routing) must be disabled between the two network interfaces and the process of forwarding packets between interfaces must be controlled by specialized software. A bastion host is used to connect the outside network (unsecure extranet) with the inside network (secured intranet), and in most cases, it is one of the first devices public traffic hits on its way into your network.
Dedicated Hardware and Software for Specific Purposes Is Secure For smaller companies that are short on cash, this might seem too expensive, but using cobbled-together solutions opens the infrastructure to potentially devastating attacks that could ruin a small business. If you have a Web server exposed to the public, it should be just that: a Web server (that is, it should not host mailing and database applications). This is especially true about firewalls of any type or topology. A firewall device is the first line of defense against network intrusions, and the less software features that are installed on it, the smaller the attack surface is.
The more specialized this device or software is, the more unlikely it is that someone will be able to exploit a flaw in its overall design. Therefore, it is highly recommended that only specialized devices or machines dedicated to securing the network border be used as bastion hosts. The number and diversity of features and applications running on any given device are sometimes referred to as the attack surface. Keeping the attack surface small makes a more secure bastion host.
In addition to the purposes outlined previously, a specialized solution is more likely to maintain desirable performance levels without introducing bottlenecks and lags.
Bastion host solutions are most common to small corporate networks, small branches or remote locations, and home office or telecommuter environments. Figure 3.3 depicts the basic elements of a device built as the bastion host.
Figure 3.3 Bastion host firewall.
Screened Host Gateway
A screened host gateway is a packet-filtering device, usually also a router, which communicates only with a designated application gateway inside the secured network. No other traffic is allowed in or out of a screened host gateway. The basic functionality is the same as a bastion host; however, a few important differences exist. Unlike with a bastion host, the network design incorporates an application gateway. Traffic coming in from the Internet is filtered based on what is considered to be safe. If a data stream is deemed safe (based on the configuration), it is forwarded to the application gateway. The application gateway then determines how to handle this stream and redirects it to an appropriate information server or workstation in the network. The process works in reverse for outgoing communications. The screened host gateway ignores all outgoing traffic that is not coming from the application gateway.
An application gateway is a one-interface device, whereas a screened host gateway is a dual-homed device (just as a bastion host firewall is). Therefore, an application gateway does not need a special subnetit can be just another network node in the corporate or production subnet as far as network design is concerned. An application gateway also runs a few application services (hence, the name), redirecting traffic it receives from the borderline filter to the systems inside the network. The borderline filter (screened host gateway) can also be configured to allow redirection of certain types of traffic considered to be safe directly to the systems inside the network. DNS requests or Telnet sessions are examples of such traffic.
Compared to a bastion host, the screened host gateway scenario is more likely to let certain types of offending traffic slip through unnoticed. In the case of a bastion host, all rules are configured on one device (if it's a pool of devices serving several redundant connections, the same configuration can be applied to other devices in the pool). With application gateways, two devices need to be configured very carefully: the borderline packet filter and the application gateway itself. This leaves room for unnoticed configuration errors and loopholes that might not be discovered until an attack has been executed, which is too late. Another reason this solution is less secure is because the packet filter is configured in a rather generic fashion, usually allowing "all or none" requests of configured types, which forwards all those requests to the application gateway indiscriminately. Because the application gateway's attack surface is significantly greater than that of the bastion host, greater potential exists that the application gateway can be compromised.
Application gateways do provide greater flexibility, albeit at the expense of security. It might be more convenient to take advantage of the modularity implemented with the two types of devices in this scenario, each responsible for its own functions. Packet filtering rules can be difficult to configure and even more difficult to maintain on one device where you have to manage permit/reject rules for more than one internal system in the absence of an application gateway. The difficulty of creating rules for a single device that must allow only specific types of traffic to reach only specific hosts can create security holes. With a bastion host, administrators often create rules that are too permissive, especially after receiving numerous complaints from special case users who cannot receive legitimate traffic. In these instances, a screened host gateway can be more secure.
Figure 3.4 depicts a typical screened host gateway deployment set of elements.
Figure 3.4 A screened host gateway.
Screened Subnet Gateway
The third type of topology is called a screened subnet gateway. Screened subnet gateway architecture includes two screened host gateway devices that isolate the LAN from the Internet, creating what is known as a screened subnet, or DMZ, between them. The architecture also includes a proxy server (bastion host).
This architecture is essentially a combination of the bastion host and screened host gateway architectures discussed in the previous section. Traditionally, this approach offers the best solution because traffic is controlled more granularly and the design has built-in redundancy; it isolates the internal network with more than one layer of security. Public inbound traffic is restricted to and is allowed only in the DMZ subnet. Outbound traffic flows through the DMZ, which creates anonymity for the requesting clients on the LAN. The only obvious disadvantage of this mixed architecture is that it is more complex than the other two; however, the complexity is partially offset by the fact that different components of this mixed architecture have their own functions and areas of responsibility. In effect, the planning requires the most effort, not the actual configuration.
Consider the deployment scenario depicted in Figure 3.4. In the DMZ are application servers the public needs to be able to access to communicate with internal clients. You would therefore place certain critical application systems inside that subnet, as shown in Figure 3.5. For example, your email servers, Web servers, DNS servers, FTP servers, and other public-facing information servers would need to be located in the screened subnet. This does not compromise the security of these application systems because at least one bastion host still exists on the borderline between the DMZ subnet and the unsecure extranet. This bastion host would be configured to allow communications initiated from the public, nontrusted clients specific to the applications the DMZ servers provide (in this case, SMTP [TCP port 25], DNS [TCP 53], FTP [TCP 21], and HTTP [TCP 80]). All other communications from the public to internal clients on the LAN or any other communications not explicitly allowed into the DMZ would be rejected. Optionally, you could place a rule to forward certain requests to certain internal machines, but this has to be justified by corporate or production requirements.
Figure 3.5 A screened subnet gateway.
Now, you can install any other application gateways in the DMZ to make external resources available to your internal clients, and vice versa. This application gateway can provide an extra layer of security in cases where Application-layer security is necessary. Thus, administrators can have control over traffic leaving internal networks and initiating bidirectional communications with the outside world on a user level. Good examples of an application gateway are a CERN-compliant proxy server, Microsoft Internet Security and Acceleration (ISA) Server 2000, or some similar software product. From an internal client's perspective, they can either be configured to talk to the outside world directly, only receiving email, DNS, and corporate intranet Web services from the DMZ, or be restricted to talking only to application gateways and information servers in the DMZ. An external borderline bastion host would then be responsible for blocking outbound communications that originate internally.
With a screened subnet topology, two local subnet IP addresses are needed to implement this architecture. One subnet address is used within the DMZ, and another subnet (which can be subnetted further) is used for internal network segments.
A few words need to be mentioned here about IP addressing. Using publicly routed IP addressing for your LAN design is very unsecure. Not only does it allow direct communications between outside hosts and internal clients (at least in theory), but it also wastes scarce public IP address space. After Internet Protocol Version 6 (IPv6) is widely accepted and deployed, more IP addresses will be available for public communications. Nonetheless, even without the problem of scarcity, using private addressing internally is much more secure and much more maintainable.
The "Network Address Translation" section that appears later in this chapter provides more information on public and private addressing. For the moment, suffice it to say that the combination of NAT plus private IP addresses helps avoid the need to renumber internal networks if an organization ever contemplates changing from one service provider to another. Because ISPs are the primary source of public IP addresses, you can sidestep the need to renumber entire networks (only the public interfaces in your network need to change) only by avoiding the use of public addresses.
Know the three major types of security zones.
Disadvantages of this architecture are the complexity of implementation and the possibility of firewall policy violations when conduits are administratively allowed from the borderline firewall through the DMZ and into the internal network. However, this second disadvantage is not unique to the screened subnet scenario. This scenario is by far the most flexible and secure topology because of its capability to completely eliminate inside/outside communications and conduct everything through a strictly controlled middleman called the DMZ.
A DMZ can be viewed as a layer of privacy between the corporate infrastructure and the Internet, exposing only those systems that must be known to the public. Strict authentication and encryption can add to the security the two firewall devices provide to make the internal network impenetrable. Demilitarized zones can also be created with just one firewall device with three network interface cards on board, as depicted in Figure 3.6.
Figure 3.6 An alternative DMZ configuration.
In Figure 3.6, an intranet and the Internet are separated by a single device and both of these segments are attached to separate interfaces. The third interface is attached to a separate network segment that effectively is an alternative DMZ and an extranet. This alternative solution compromises a little bit of security (an intruder has to break only one firewall as opposed to two), but with proper planning, good hardware, and solid configuration, this is highly unlikely. Companies can opt to use this method in situations where security is a must but the budget does not allow for two well-designed firewalls.
As can be inferred from the discussion in the preceding section, an intranet is the portion of a network that belongs to and is controlled by a company. It is not necessarily just the inside LAN segment; it can also include the DMZ segment, WAN links to remote locations, and the remote locations. The definition of an intranet is somewhat blurry, and opinion varies as to whether a DMZ can properly be considered part of the intranet. However, one rule is that if a portion of the infrastructure belongs to the company and the communications links are managed and secured by the company, these elements are encompassed in the definition of an intranet.
Security requirements for intranets (with the exception of the DMZ) are usually significantly lower than with extranets or the Internet, although this might not be true in certain organizations. (A good example is a university, where firewalls are used to protect staff networks from student networks.) In classical examples, some access separation exists between departments, branches, and geographical locations, but by and large, company resources are accessible and trusted within the intranet, which is open to authorized personnel and members of the company.
More recently, security organizations such as SANS have been advocating an approach called Defense in Depth that calls for multiple layers of security, mixed brands of defense devices, and overlapping areas of security coverage to make network penetration significantly more difficult for attackers. In addition, the deployment of security devices within the intranet can help contain breaches of network security and limit the scope of an attack.
The notion of an extranet is even blurrier than that of an intranet. It refers to the practice of allowing partners, whose network space is outside the company's control, to use some of the resources available on the intranet, usually in the DMZ.
The extranet is a public portion of the company's IT infrastructure that allows certain resources to be accessed by outside users, such as partners and resellers, with proper authorization and authentication. The DMZ serves as a security cushion between the extranet and the intranet. Although it is technically located within the intranet, the DMZ can serve as the extranet as well. Resources on the extranet trust and honor only requests that have been authenticated using a reliable authentication technology such as PKI or digital certificates.
Virtual Local Area Networks
A virtual local area network (VLAN) unites network nodes logically into the same broadcast domain regardless of whether they are physically united. A VLAN can create a logically stable environment when computers are not physically stationary or are not physically close. For example, network administrators and technical personnel can roam a complex corporate environment but, regardless of their physical connection locations, still need access to their administrative resources.
At the same time, a VLAN can allow one broadcast domain to be split into two or more domains that restrict access to certain network resources. This can be a handy addition to user management and security strategy for the company.
VLANs are implemented using a technology known as tagging. The 802.1Q standard defines a Q-tag mechanism that allows marking frame headers with tags that identify VLANs. VLAN-aware network devices look for Q-tags in frames and make appropriate forwarding decisions. A VLAN is therefore a software solution that enables the creation of unique Q-tag identifiers to be assigned to ports on network switching devices. One switch port can be a member of many VLANs.
Network Address Translation
Network address translation (NAT) enables the use of public IP address space by devices that use private IP address space. A NAT device creates and maintains mappings between private IP address space, invisible to the outside world, and public IP address space that can communicate with external resources.
Private address ranges, defined in RFC 1918, are special address ranges in class A, B, and C networks that can freely be used by organizations internally. Their key feature is that addresses within these ranges are considered nonroutable on the Internet. If your organization is connected to the Internet, it is recommended that private address ranges be used on the LAN.
Private addressing through NAT provides three major benefits. First, routable network address space is preserved because the Internet community is running out of available addresses rather quickly. The second benefit is that because private addressing is nonroutable, it is harder (but not impossible) for intruders to penetrate the perimeter of your network. Third, if you change Internet service providers, your public IP address changes, but your private network addresses can remain the same.
As a security measure, NAT deprives intruders of the direct access to LAN workstations that they would have with public IP addresses. Instead, intruders must break through the NAT and, in most cases, a firewall that secures the Internet connection.
Workstations communicate with outside networks through the NAT device. Each outgoing request dynamically creates a mapping on the NAT device, and NAT proceeds with the outgoing request, acting as a proxy. When it gets the reply, it looks up the mapping and forwards the information to the original requester. In the same fashion, static mappings can be created to instruct NAT to forward certain requests to certain hosts on the inside network.
In a variation of NAT called port address translation (PAT), the idea is the same, but instead of creating address-based mappings, port-based mappings are employed on a higher level up the OSI model. This becomes useful in situations where IP addresses on the public interface of a NAT device are scarce, allowing many internal IP addresses to be mapped to a single external IP address and differentiating between the channels using port assignments.
NAT can also be used for address translation between multiple protocols, which measurably improves security and provides for more interoperability in heterogeneous networks. For more information about NAT, see RFC 2663 at http://www.ietf.org/rfc/rfc2663.txt.
The private address ranges are as follows:
Class A10.0.0.0 network is reserved for private addressing. Valid host IDs are from 10.0.0.1 to 10.255.255.254.
Class B172.16.0.017126.96.36.199 networks are reserved for private addressing. Valid host IDs are from 172.16.0.1 to 172.31.255.254.
Class C192.168.0.0 network is reserved for private addressing. Valid host IDs are from 192.168.0.1 to 192.168.255.254.
For companies that do not have and do not plan to have any Internet connectivity, any network address range will work as long as it accommodates the company's host number needs.
NAT Does Not Work Well with IPSec A NAT device must strip the headers off incoming packets and attach its own headers before sending the packets on. This might not be possible in the IPSec channel where information is encrypted.
Another address range to keep in mind when designing IP address space is Microsoft's Automatic Private IP Addressing (APIPA). Microsoft implemented APIPA in Windows 98 and Windows 2000 clients. If these workstations are configured as DHCP clients and no DHCP server is available at the time of a DHCP lease request, a client automatically is configured with an address from 169.254.0.1 to 169.254.255.254.
Tunneling, also known as virtual private networking (VPN), poses some particular security challenges. When using VPN with firewalls, you need to define a set of firewall rules that permits the tunneling. Unfortunately, after a VPN tunnel is created, it is considered a communication channel that has already passed necessary security checks. In most popular solutions, VPN traffic is not filtered by a firewall. After establishing a communications channel, a remote user could funnel any traffic through, bypassing the rules instituted by the firewall. Furthermore, when encryption is used in a tunnel, filtering is impossible because the firewall does not see the contents due to end-to-end encryption between the peers.
Creating VPN Solutions for Home Offices When creating VPN solutions for the purpose of telecommuting and working from home, keep in mind that requiring the use of an application gateway for public Web and DNS traffic for remote users can cause performance problems at higher volumes. Such a requirement means the client must send and receive large volumes of encrypted traffic that could safely travel directly between public Web sites and the remote client without having to go through the corporate VPN channel. Encryption/decryption, unless it is performed by dedicated hardware, is resource intensive for both the client and server. Be sure to factor in the costs of dedicated hardware or existing hardware upgrades when evaluating solutions.
Some topological solutions are possible for these problems. One such solution is to deploy the VPN host in parallel with an internal firewall and then force decrypted traffic to pass through the firewall. Another possible solution is to use the VPN features of some firewall products such as PIX and Checkpoint firewalls. In addition, the threat of malicious traffic traveling through VPN is greatly reduced if the remote host employs adequate security measures. This can require more IT support for remote users, especially less technically sophisticated users, but it can greatly enhance security.