Enterprise Edge

Figures A-16 and A-17 show a detailed analysis of all of the modules contained within the enterprise edge.

Corporate Internet Module

The corporate Internet module (see Figure A-18) provides internal users with connectivity to Internet services and Internet users access to information on public servers. Traffic also flows from this module to the VPN and remote-access module, where VPN termination takes place. This module is not designed to serve e-commerce applications. Refer to the “E-Commerce Module” section later in this document for more details on providing Internet commerce.

Key Devices

The key devices (see Figure A-19) are as follows:

• SMTP server— Acts as a relay between the Internet and the Internet mail servers; inspects content

• DNS server— Serves as authoritative external DNS server for the enterprise; relays internal requests to the Internet

• FTP/HTTP server— Provides public information about the organization

• Firewall— Provides network level protection of resources and stateful filtering of traffic

• NIDS appliance— Provides Layer 4 to Layer 7 monitoring of key network segments in the module

• URL filtering server— Filters unauthorized URL requests from the enterprise

Threats Mitigated

The threats mitigated (see Figure A-20) are as follows:

• Unauthorized access— Mitigated through filtering at the ISP, edge router, and corporate firewall

• Application layer attacks— Mitigated through IDS at the host and network levels

• Virus and Trojan horse— Mitigated through e-mail content filtering and HIDS

• Password attacks— Limited services available to brute force; OS and IDS can detect the threat

• DoS— Committed access rate (CAR) at ISP edge and TCP setup controls at firewall

• IP spoofing— RFC 2827 and RFC 1918 filtering at ISP edge and enterprise edge router

• Packet sniffers— Switched infrastructure and HIDS limits exposure

• Network reconnaissance— IDS detects reconnaissance; protocols filtered to limit effectiveness

• Trust exploitation— Restrictive trust model and private VLANs limit trust-based attacks

• Port redirection— Restrictive filtering and HIDS limit attack

Design Guidelines

The heart of the module is a pair of resilient firewalls, which provide protection for the Internet public services and internal users. Stateful inspection examines traffic in all directions, ensuring only legitimate traffic crosses the firewall. Aside from the Layer 2 and Layer 3 resilience built into the module and the stateful failover capability of the firewall, all other design considerations center around security and attack mitigation.

Starting at the customer-edge router in the ISP, the egress out of the ISP rate limits nonessential traffic that exceeds prespecified thresholds to mitigate against DDoS or DoS attacks. Also at the egress of the ISP router, RFC 1918 and RFC 2827 filtering mitigate against source-address spoofing of local networks and private address ranges.

At the ingress of the first router on the enterprise network, basic filtering limits the traffic to the expected traffic (addresses and IP services), providing a coarse filter for the most basic attacks. RFC 1918 and RFC 2827 filtering is also provided here as a verification of the ISP's filtering. In addition, because of the enormous security threat that fragmented packets create, the router is configured to drop most fragmented packets that should not generally be seen for standard traffic types on the Internet. Any legitimate traffic lost because of this filtering is considered acceptable when compared to the risk of allowing such traffic. Finally, any IPSec traffic destined for the VPN and remote-access module is routed appropriately. Filtering on the interface that is connected to the VPN module is configured to allow only IPSec traffic to cross, and only when originated from and sent to authorized peers. With remote-access VPNs, you generally do not know the IP address of the system coming in, so filtering can be specific only to the head-end peers with which the remote users are communicating.

The NIDS appliance at the public side of the firewall monitors for attacks based on Layer 4 to Layer 7 analysis and comparisons against known signatures. Because the ISP and enterprise edge router filter certain address ranges and ports, the NIDS appliance can focus on some of the more complex attacks. Still, this NIDS should have alarms set to a lower level than appliances on the inside of the firewall, because alarms seen here do not represent actual breaches, but merely attempts.

The firewall provides connection state enforcement and detailed filtering for sessions initiated through it. Publicly addressable servers have some protection against TCP SYN floods through the use of half-open connection limits on the firewall. From a filtering standpoint, in addition to limiting traffic on the public services segment to relevant addresses and ports, filtering in the opposite direction also takes place. If an attack compromises one of the public servers (by circumventing the firewall, HIDS, and NIDS), that server should not be able to attack the network further. To mitigate against this type of attack, specific filtering prevents any unauthorized requests from being generated by the public servers to any other location. As an example, the Web server should be filtered so that it cannot originate requests of its own, but merely respond to requests from clients. This helps prevent a hacker from downloading additional utilities to the compromised box after the initial attack. It also helps stop unwanted sessions from being triggered by the hacker during the primary attack. An example of such an attack is one that generates an xterm from the Web server through the firewall to the hacker's machine. In addition, private VLANs prevent a compromised public server from attacking other servers on the same segment. This traffic is not even detected by the firewall, which is why private VLANs are critical.

Traffic on the content inspection segment is limited to URL filtering requests from the firewall to the URL filtering device. In addition, authenticated requests are allowed from the enterprise URL filtering device out to a master server for database updates. The URL filtering device inspects outbound traffic for unauthorized WWW requests. It communicates directly with the firewall and approves or rejects URL requests sent to its URL inspection engine by the firewall. Its decision is based on a policy managed by the enterprise using classification information of the WWW provided by a third-party service. URL inspection is preferred over standard access filtering because IP addresses often change for unauthorized web sites, and such filters can grow to be very large. HIDS software on this server protects against possible attacks that somehow circumvent the firewall.

The public services segment includes an NIDS appliance to detect attacks on ports that the firewall is configured to permit. These most often are application layer attacks against a specific service or password attacks against a protected service. You need to set this NIDS in a more restrictive stance than the NIDS on the outside of the firewall because signatures matched here have successfully passed through the firewall. Each of the servers have host intrusion detection software on them to monitor against any rogue activity at the OS level, in addition to activity in common server applications (HTTP, FTP, SMTP, and so forth). The DNS host should be locked down to respond only to desired commands and to eliminate any unnecessary responses that might assist hackers in network reconnaissance. This includes preventing zone transfers from anywhere but the internal DNS servers. The SMTP server includes mail-content inspection services to mitigate against virus and Trojan-type attacks generated against the internal network that are usually introduced through the mail system. The firewall itself filters SMTP messages at Layer 7 to allow only necessary commands to the mail server.

The NIDS appliance on the inside interface of the firewall provides a final analysis of attacks. Very few attacks should be detected on this segment, because only responses to initiated requests and a few select ports from the public services segment are allowed to the inside. Only sophisticated attacks should be seen on this segment, because they generally mean a system on the public services segment has been compromised and the hacker is attempting to leverage this foothold to attack the internal network. For example, if the public SMTP server is compromised, a hacker might try to attack the internal mail server over TCP port 25, which is permitted to allow mail transfer between the two hosts. If attacks are seen on this segment, the responses to those attacks should be more severe than those on other segments because they probably indicate that a compromise has already occurred. The use of TCP resets to thwart, for example, the SMTP attack mentioned above should be seriously considered.

Alternatives

There are several alternative designs for this module. For example, depending on your attitude toward attack awareness, the NIDS appliances might not be required in front of the firewall. In fact, without basic filtering on the access router, this type of monitoring is not recommended. With the appropriate basic filters, which exist in this design, the IDS outside the firewall can provide important alarm information that would otherwise be dropped by the firewall. Because the amount of alarms generated on this segment is probably large, alarms generated here should have a lower severity than alarms generated behind a firewall. Also, consider logging alarms from this segment to a separate management station to ensure that legitimate alarms from other segments get the appropriate attention. With the visibility that NIDS outside the firewall provides, evaluation of the attack types your organization is attracting can be better seen. In addition, evaluation of the effectiveness of ISP and enterprise edge filters can be performed.

Another possible alternative to the proposed design is the elimination of the router between the firewall and the edge distribution module. Though its functions can be integrated into the edge distribution module, the functional separation between modules would be lost, because the edge distribution switches would need to be aware of the entire topology of the corporate Internet module to ensure proper routing. In addition, this limits your ability to deploy this architecture in a modular fashion. If an enterprise's current core is Layer 2, for example, the routing provided in the corporate Internet module would be required.

Near-Term Architecture Goals

Developing Cisco firewall technology that can communicate directly with other content inspection devices is needed (for example, network-based virus scanning). Currently, URL filtering is the only supported content filtering function that is directly integrated with Cisco firewall technology. Nonintegrated products rely on users operating in a proxy mode that does not properly scale.

VPN and Remote-Access Module

As the name implies, the primary objective of the VPN and remote-access module (see Figure A-21) is threefold: terminate the VPN traffic from remote users, provide a hub for terminating VPN traffic from remote sites, and terminate traditional dial-in users. All of the traffic forwarded to the edge distribution is from remote corporate users that are authenticated in some fashion before being allowed through the firewall.

Key Devices

The key devices (see Figure A-22) are as follows:

• VPN concentrator— Authenticates individual remote users using Extended Authentication (Xauth) and terminate their IPSec tunnels

• VPN router— Authenticates trusted remote sites and provide connectivity using generic routing encapsulation (GRE) or IPSec tunnels

• Dial-in server— Authenticates individual remote users using TACACS+ and terminate their analog connections

• Firewall— Provides differentiated security for the three different types of remote access

• NIDS appliance— Provides Layer 4 to Layer 7 monitoring of key network segments in the module

Threats Mitigated

The threats mitigated (see Figure A-23) are as follows:

• Network topology discovery— Only Internet Key Exchange (IKE) and Encapsulating Security Payload (ESP) are allowed into this segment from the Internet.

• Password attack— OTP authentication reduces the likelihood of a successful password attack.

• Unauthorized access— Firewall services after packet decryption prevent traffic on unauthorized ports.

• Man-in-the-middle— Mitigated through encrypted remote traffic.

• Packet sniffers— A switched infrastructure limits the effectiveness of sniffing.

Design Guidelines

Resilience aside, the core requirement of this module is to have three separate external user services authenticate and terminate. Because the traffic comes from different sources outside of the enterprise network, the decision was made in the SAFE architecture to provide a separate interface on the firewall for each of these three services. The design consideration for each of these services are addressed below.

Remote-Access VPN

The VPN traffic is forwarded from the corporate Internet module access routers, where it is first filtered at the egress point to the specific IP addresses and protocols that are part of the VPN services. Today's remote-access VPNs can use several different tunneling and security protocols. Although IPSec is the tunneling protocol of choice, many organizations choose Point-to-Point Tunneling Protocol (PPTP) and Layer 2 Tunneling Protocol (L2TP) because they are natively supported by popular desktop operating systems. In SAFE, IPSec was chosen because the clients require minimal configuration and at the same time provide good security.

The remote-access VPN traffic is addressed to one specific public address using the IKE (UDP 500) protocol. Because the IKE connection is not completed until the correct authentication information is provided, this provides a level of deterrence for the potential hacker. As part of the extensions (draft RFCs) of IKE, XAUTH provides an additional user authentication mechanism before the remote user is assigned any IP parameters. The VPN concentrator is “connected” to the access control server on the management subnet by its management interface. Strong passwords are provided by the OTP server.

Once authenticated, the remote user is provided with access by receiving IP parameters using another extension of IKE, MODCFG. Besides an IP address and the location of name servers (DNS and WINS), MODCFG provides authorization services to control the access of the remote user. For example in SAFE, users are prevented from enabling split tunneling, thereby forcing the user to access the Internet via the corporate connection. The IPSec parameters that are being used are Triple DES (3DES) for encryption and SHA-HMAC for data integrity. The hardware encryption modules in the VPN concentrator allow scalable remote-access VPN services to be deployed to thousands of remote users. Following termination of the VPN tunnel, traffic is sent through a firewall to ensure that VPN users are appropriately filtered.

Secure management of this service is achieved by pushing all IPSec and security parameters to the remote users from the central site. Additionally, connections to all management functions are on a dedicated management interface.

Dial-In Access Users

The traditional dial-in users are terminated on one of the two access routers with built-in modems. Once the Layer 1 connection is established between the user and the server, three-way Challenge Handshake Authentication Protocol (CHAP) is used to authenticate the user. As in the remote-access VPN service, the authentication, authorization, and accounting (AAA) and OTP servers are used to authenticate and provide passwords. Once authenticated, the users are provided with IP addresses from an IP pool through Point-to-Point Protocol (PPP).

Site-to-Site VPN

The VPN traffic associated with site-to-site connections consists of GRE tunnels protected by an IPSec protocol in transport mode using ESP. As in the remote-access case, the traffic that is forwarded from the corporate Internet module can be limited to the specific destination addresses on the two VPN routers and the source addresses expected from the remote sites. The ESP protocol (IP 50) and the IKE protocol are the only two expected on this link.

GRE is used to provide a full-service routed link that will carry multiprotocol, routing protocol, and multicast traffic. Because routing protocols (Enhanced Interior Gateway Routing Protocol [EIGRP] is used between remote sites) can detect link failure, the GRE tunnel provides a resilience mechanism for the remote sites if they build two GRE connections, one to each of the central VPN routers.

As in remote-access VPN, 3DES and SHA-HMAC are used for IKE and IPSec parameters to provide the maximum security with little effect on performance. IPSec hardware accelerators are used in the VPN routers.

Rest of the Module

The traffic from the three services is aggregated by the firewall onto one private interface before being sent to the edge distribution module by a pair of routers. The firewall must be configured with the right type of constraining access control to allow only the appropriate traffic through to the inside interface of the firewall from each of the services. A pair of NIDS appliances are positioned at the public side of the module to detect any network reconnaissance activity targeted at the VPN termination devices. On this segment, only IPSec (IKE/ESP) traffic should be seen. Because the NIDS cannot see inside the IPSec packets, any alarm on this network indicates a failure or compromise of the surrounding devices. As such, these alarms should be set to high severity levels. A second pair of NIDS appliances are positioned after the firewall to detect any attacks that make it through the rest of the module. This NIDS device also has a restrictive policy in place. All users crossing this segment should be bound to or coming from a remote location, so any shunning or TCP resets will affect only those users.

Alternatives

In VPN and authentication technology, there are many alternatives available, depending on the requirements of the network. These alternatives are listed below for reference, but the details are not addressed in this document.

• Smart card or biometric authentication

• L2TP or PPTP remote-access VPN tunnels

• Certificate authorities (CAs)

• IKE keep-alive resilience mechanism

• Multiprotocol Label Switching (MPLS) VPNs

WAN Module

Rather than being all-inclusive of potential WAN designs, this module shows resilience and security for WAN termination. Using Frame Relay encapsulation, traffic is routed between remote sites and the central site.

Key Devices

The IOS router, using routing, access-control, and QoS mechanisms, is the key device (see Figure A-24).

Threats Mitigated

The threats mitigated (see Figure A-25) are as follows:

• IP spoofing— Mitigated through Layer 3 filtering.

• Unauthorized access— Simple access control on the router can limit the types of protocols to which branches have access.

Design Guidelines

The resilience is provided by the dual connection from the service provider, through the routers, and to the edge distribution module. Security is provided by using IOS security features. Input access lists are used to block all unwanted traffic from the remote branch.

Alternatives

Some organizations that are very concerned about information privacy encrypt highly confidential traffic on their WAN links. Similar to site-to-site VPNs, you can use IPSec to achieve this information privacy.

E-Commerce Module

Because e-commerce is the primary objective of this module (see Figure A-26), the balance between access and security must be carefully weighed. Splitting the e-commerce transaction into three components allows the architecture to provide various levels of security without impeding access.

Key Devices

The key devices (see Figure A-27) are as follows:

• Web server— Acts as the primary user interface for the navigation of the e-commerce store

• Application server— Is the platform for the various applications required by the Web server

• Database server— Is the critical information that is the heart of the e-commerce business implementation

• Firewall— Governs communication between the various levels of security and trust in the system

• NIDS appliance— Provides monitoring of key network segments in the module

• Layer 3 switch with IDS module— Is the scalable e-commerce input device with integrated security monitoring

Threats Mitigated

The threats mitigated (see Figure A-28) are as follows:

• Unauthorized access— Stateful firewalls and access control lists (ACLs) limit exposure to specific protocols.

• Application layer attacks— Attacks are mitigated through the use of IDS.

• DoS— ISP filtering and rate limiting reduce DDoS or DoS potential.

• IP spoofing— RFC 2827 and RFC 1918 prevent locally originated spoofed packets and limit remote spoof attempts.

• Packet sniffers— A switched infrastructure and HIDS limit the effectiveness of sniffing.

• Network reconnaissance— Ports are limited to only what is necessary; ICMP is restricted.

• Trust exploitation— Firewalls ensure that communication flows only in the proper direction on the proper service.

• Port redirection— HIDS and firewall filtering limit exposure to these attacks.

Design Implementation Description

The heart of the module is two pairs of resilient firewalls that provide protection for the three levels of servers: Web, application, and database. Some added protection is provided by the ISP edge routers at the ISP and the enterprise. The design is best understood by considering the traffic flow sequence and direction for a typical e-commerce transaction.

The e-commerce customer initiates an HTTP connection to the Web server after receiving the IP address from a DNS server hosted at the ISP network. The DNS is hosted on a different network to reduce the amount of protocols required by the e-commerce application. The first set of firewalls must be configured to allow this protocol through to that particular address. The return traffic for this connection is allowed back, but there is no need for any communication initiated by the Web server back out to the Internet. The firewall should block this path to limit the options of hackers if they get control of one of the Web servers.

As the user navigates the web site, certain link selections cause the Web server to initiate a request to the application server on the inside interface. This connection must be permitted by the first firewall, as well as the associated return traffic. As in the case with the Web server, there is no reason for the application server to initiate a connection to the Web server or even out to the Internet. Likewise, the user's entire session runs over HTTP and SSL with no ability to communicate directly with the application server or the database server.

At one point, the user might want to perform a transaction. The Web server should protect this transaction, and the SSL protocol will be required from the Internet to the Web server.

At the same time, the application server might want to query or pass information on to the database server. These are typically Structured Query Language (SQL) queries that are initiated by the application server to the database server, and not vice versa. These queries run through the second firewall to the database server. Depending on the specific applications in use, the database server might need to communicate with back-end systems located in the server module of the enterprise.

In summary, the firewalls must allow only three specific communication paths, each with its own protocol, and block all other communication, unless it is the return path packets that are associated with the three original paths.

The servers themselves must be fully protected, especially the Web server, which is a publicly addressable host. The operating system and Web server application must be patched to the latest versions and monitored by the host intrusion detection software. This should mitigate against most application layer primary and secondary attacks, such as port redirection and root kits. The other servers should have similar security in case the first server or firewall is compromised.

Beyond the Firewall

The e-commerce firewalls are initially protected by the customer edge router at the ISP. At the router egress point, toward the enterprise, the ISP can limit the traffic to the small number of protocols required for e-commerce with a destination address of the Web servers only. Routing protocol updates (generally Border Gateway Protocol [BGP]) are required by the edge routers, and all other traffic should be blocked. The ISP should implement rate limiting, as specified in the “SAFE Axioms” section, to mitigate DDoS or DoS attacks. In addition, filtering according to RFC 1918 and RFC 2827 should be implemented by the ISP.

On the enterprise premises, the initial router serves only as an interface to the ISP. The Layer 3 switch does all the network processing because it has features off-loaded to hardware processors. The Layer 3 switches participate in the full BGP routing decision to decide which ISP has the better route to the particular user. The Layer 3 switches also provide verification filtering in keeping with the ISP filtering described above; this provides overlapping security. The Layer 3 switches also provide built-in IDS monitoring. If the connection to the Internet exceeds the capacity of the IDS line card, you might need to look at inbound Web requests from the Internet on the IDS line card. Although this will miss some HTTP alarm signatures (approximately 10 percent), it is better than looking at the entire stream in both directions, where many misses would occur. The other NIDS appliances behind the various interfaces of the firewall monitor the segments for any attacks that might have penetrated the first line of defense. For example, if the Web server is out of date, hackers could compromise it over an application layer attack, assuming they were able to circumvent the HIDS. As in the corporate Internet module, the false positives must be removed so that all true attack detections are treated with the correct level of priority. In fact, because only certain types of traffic exist on certain segments, you can tune NIDS very tightly.

From an application standpoint, the communications paths between the various layers (web, apps, dbase) should be encrypted, transactional, and highly authenticated. For example, if the apps server was to get data from the database over some type of scripted interactive session (SSH, FTP, Telnet, and so forth), a hacker could leverage that interactive session to initiate an application layer attack. By employing secure communications, you can limit potential threats.

The Layer 2 switches that support the various firewall segments provide the ability to implement private VLANs, thereby implementing a trust model that matches the desired traffic communication on a particular segment and eliminates all others. For example, there is usually no reason for one Web server to communicate with another Web server.

The management of the entire module is done completely out of band, as in the rest of the architecture.

Alternatives

The principle alternative to this deployment is colocating the entire system at an ISP. Though the design remains the same, there are two primary differences. The first is that bandwidth is generally larger to the ISP and uses a LAN connection. Though not recommended, this potentially eliminates the need for the edge routers in the proposed design. The additional bandwidth also creates different requirements for DDoS or DoS mitigation. The second is the connection back to the enterprise, which needs to be managed in a different way. Alternatives include encryption and private lines. Using these technologies creates additional security considerations, depending on the location of the connections and their intended use.

There are several variations on the primary design for this module. Aside from listing the alternatives, further discussion is beyond the scope of this appendix.

• The use of additional firewalls is one alternative. Sample communications would be edge routing to firewall to Web server to firewall to applications server to firewall to database server. This allows each firewall to control communications for only one primary system.

• Load-balancing and caching technologies are not specifically discussed in this appendix, but they can be overlaid onto this architecture without major modifications. A future paper will address these needs.

• For very high security requirements, the use of multiple firewall types may be considered. Note that this creates additional management overhead in duplicating policy on disparate systems. The goal of these designs is to avoid a vulnerability in one firewall from circumventing the security of the entire system. These types of designs tend to be very firewall-centric and do not adequately take advantage of IDS and other security technologies to mitigate the risk of a single firewall vulnerability.

Enterprise Options

The design process is often a series of trade-offs. This short subsection of the document highlights some of the high-level options that a network designer could implement if faced with tighter budget constraints. Some of these trade-offs are done at the module level, while others are done at the component level.

One option is to collapse the distribution modules into the core module. This reduces the number of Layer 3 switches by 50 percent. The cost savings would be traded off against performance requirements in the core of the network and flexibility to implement all the distribution security filtering.

A second option is to merge the functionality of the VPN and remote-access module with the corporate Internet module. Their structure is very similar, with a pair of firewalls at the heart of the module surrounded by NIDS appliances. This may be possible without loss of functionality if the performance of the components matches the combined traffic requirements of the modules, and if the firewall has enough interfaces to accommodate the different services. Keep in mind that as functions are aggregated to single devices, the potential for human error increases. Some organizations go even further and include the e-commerce functions in the corporate Internet/VPN module. The authors feel that the risk of doing this far outweighs any cost savings unless the e-commerce needs are minimal. Separation of the e-commerce traffic from general Internet traffic allows the e-commerce bandwidth to be better optimized by allowing the ISP to place more restrictive filtering and rate-limiting technology to mitigate against DDoS attacks.

A third option is to eliminate some of the NIDS appliances. Depending on your operational threat response strategy, you might need fewer NIDS appliances. The number of appliances is also affected by the amount of HIDS deployed, because this might reduce the need for NIDS in certain locations. This is discussed, where appropriate, in the specific modules.

Clearly, network design is not an exact science. Choices must always be made depending on the specific requirements facing the designer. The authors are not proposing that any designer would implement this architecture verbatim, but are encouraging designers to make educated choices about network security grounded in this proven implementation.