Home > Articles

This chapter is from the book

This chapter is from the book

Security+ Training GuideSecurity+ Training Guide

Learn More Buy

This chapter is from the book

This chapter is from the book

Security+ Training GuideSecurity+ Training Guide

Learn More Buy

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

  • VLANs

  • NAT

  • Tunneling

Security Zones

The three major types of security topologies are as follows:

  • Bastion host

  • 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.

Bastion Host

A bastion host is a dual-homed device—that 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.

NOTE

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.3Figure 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 subnet—it 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.4Figure 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.5Figure 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.

IP Addressing

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.

TIP

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.

DMZs

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.6Figure 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.

Intranets

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.

Extranets

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 A—10.0.0.0 network is reserved for private addressing. Valid host IDs are from 10.0.0.1 to 10.255.255.254.

  • Class B—172.16.0.0–172.31.0.0 networks are reserved for private addressing. Valid host IDs are from 172.16.0.1 to 172.31.255.254.

  • Class C—192.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.

NOTE

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

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.

NOTE

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.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020