CCSP SelfStudy CCSP CSI: Exam Certification Guide, Second Edition [Electronic resources] نسخه متنی

The Enterprise Edge Layer

The enterprise edge layer is made up of the following modules, as shown in Figure 18-4:

• E-Commerce module

• VPN and Remote Access module

• Corporate Internet module

• WAN module

The E-Commerce Module

The E-Commerce module must balance access and security to provide safe and secure transactions for the end customers. To achieve these aims, the E-Commerce module is divided into the following three primary components, shown in Figure 18-5:

• Database servers

• Application servers

• Web servers

Mitigating Threats in the E-Commerce Module

Table 18-10 shows the expected threats and mitigation techniques for the E-Commerce module.

Design Guidelines for the E-Commerce Module

The core of the E-Commerce module is a pair of firewalls that divide the module into three components: web servers, application servers, and database back end.

The web servers are the public, Internet-facing systems that communicate with the customer. The next layer is composed of the application servers that execute middleware programs, providing the transactional capabilities of the E-Commerce module. The application servers communicate with the database systems behind the second layer of firewalls using SQL queries. The communication between the various layers is enforced through the policies configured on the firewall pairs. Similarly, the firewalls enforce the communication outbound from the various layers. For example, typically the database servers and the application servers do not need to browse the Internet. As such, only approved communications outbound from the database or application servers to the application or web servers, respectively, are allowed through the firewalls. In a similar manner, the web servers are not permitted to browse the web by the access control lists (ACLs) configured on the routers at the edge of the module.

All the servers in this module should be patched to the latest patch level provided by the various software vendors and monitored using NIDS. Additionally, because the web servers are publicly addressable systems, host-based IPS should be installed to further defend this host from attack.

Beyond the firewall, the edge router at the ISP provides the capability to limit the traffic to the E-Commerce module to the small number of protocols required at the endpoint web servers. The ISP should implement rate limiting in accordance with the SAFE axioms described earlier, RFC 1918 address filtering, and RFC 2827 ingress filtering.

The Layer 3 switches behind the first firewall set in the module participate fully in the BGP routing decision of which ISP has the better path to a given user. They also provide verification filtering and IDS monitoring of the traffic to the web servers. If the IDS modules in these switches become oversubscribed in terms of bandwidth, it may become necessary to inspect only the inbound HTTP requests instead of the entire traffic stream.

Host-based IPS is used on all servers in this module to provide a level of protection against application-based attacks. Additionally, the switches in the module can be configured with private VLANs to implement a trust model that matches only the desired communication pattern in a given segment. All management of devices in this module is done out-of-band.

Table 18-11 describes the E-Commerce module devices and their functions.

Design Alternative for the E-Commerce Module

The main alternative design to the E-Commerce module is to colocate the entire module at an ISP. This provides for significantly greater bandwidth but requires some sort of encrypted communication channel into the module for management. This can be provided by using an IPSec VPN tunnel.

The VPN and Remote Access Module

Figure 18-6 shows the VPN and Remote Access module.

Mitigating Threats in the VPN and Remote Access Module

Table 18-12 shows the expected threats and mitigation techniques for the VPN and Remote Access module.

Design Guidelines for the VPN and Remote Access Module

The key devices for this module are the firewalls, the VPN concentrators, and the dial-in access servers. Each of these devices is placed on a separate interface of the firewalls for the termination of the access service. The NIDS devices in the module provide for monitoring of attack traffic aimed against VPN concentrators. The only traffic that should be seen coming into this module from the Corporate Internet module is encrypted VPN traffic. NIDS is blind to this traffic because of the encryption; any alarm activation from the NIDS in the forward part of the module indicates a potential threat against the VPN concentrators.

Similarly, the NIDS behind the firewalls is there to monitor traffic that is permitted by the firewall policy. This helps ensure that an attacker does not enter the corporate network undetected.

Table 18-13 shows the key devices used in the VPN and Remote Access module.

The VPN and Remote Access module provides for the termination of three remote user access services:

• Remote-access IPSec VPN

• Dial-in access

• Site-to-site VPN

Remote-Access IPSec VPN

The remote-access VPN traffic is forwarded from the Corporate Internet module's access routers, which first filter the traffic so that only traffic destined for the VPN concentrators is permitted. The traffic consists of one of several different technologies:

• IPSec VPNs

• Point-to-Point Tunneling Protocol (PPTP)

• Layer-2 Tunneling Protocol (L2TP)

For the purposes of SAFE, the discussion is limited to IPSec VPNs.

IPSec VPNs can use several protocols, including Internet Key Exchange (IKE, over UDP port 500), Encapsulating Security Protocol (ESP, IP protocol 50), or Authentication Header (AH, IP protocol 51) Protocol. IKE provides for the key exchange and the tunnel setup, and either ESP or AH provides for the protection of the transmitted traffic. To work around the difficulties posed by NAT and remote-side firewalling, the VPN traffic is encapsulated in either a UDP or a TCP header and is directed to a specific port on the concentrator. For the purposes of the SAFE design, the remote-access VPN traffic is addressed to the VPN concentrators using IKE, ESP, and UDP 10000.

Authentication of remote users is provided using the XAUTH extensions to IKE. These extensions allow for remote user authentication before any IP parameters are assigned. Additionally, authentication is done using a OTP system. When authentication is complete, the MODCFG extension to IKE provides the remote user with an IP address and DNS and WINS server information. In addition to this configuration information, split tunneling is turned off, thus requiring the user to tunnel all traffic, even traffic that ultimately is destined for a site on the public Internet, through the corporate connection. The IPSec parameters used in the SAFE Enterprise blueprint are 3DES encryption and SHA1-HMAC for data integrity; alternatively, AES can be used in place of 3DES because of the improved encryption performance of this algorithm.

Because the VPN tunnels terminate before passing through the firewall interface in the VPN and Remote Access module firewalls, additional filtering can be applied at that interface. Also, as with the other modules, all management traffic is carried in an out-of-band network, if possible.

Dial-In Access

Dial-in access is provided by one of two access routers in the module. These routers include built-in modems, thus providing for Layer 1 connectivity between the remote user and the network. Authentication is provided using the Challenge Handshake Authentication Protocol (CHAP) and an OTP, as in the remote-access VPN.

Site-to-Site VPN

Site-to-site connectivity is provided through the use of IPSec-encapsulated Generic Routing Encapsulation (GRE) tunnels. GRE is used to provide a routed link between the sites to carry routing protocol traffic as well as other multicast and unicast traffic. The use of routing protocols in the site-to-site links allows for the detection of link failure. This is done by building two separate VPN links between the remote sites to each of the central VPN routers.

Design Alternative for The VPN and Remote Access Module

Many possible alternatives can be deployed in the VPN and Remote Access module:

• Smart-card authentication

• Biometric authentication

• L2TP/PPTP remote-access VPN tunnels

• Certificate Authorities (CAs)

• MPLS VPNs

The Corporate Internet Module

The Corporate Internet module, shown in Figure 18-7, provides Internet access and connectivity for internal users. This module also provides access from the Internet to information stored on public servers such WWW and DNS. A pair of firewalls in failover configuration provide stateful inspection of traffic. Redundancy is built throughout the module by ensuring Layer 2 and Layer 3 resiliency. Examining the security in this module more closely reveals the characteristic defense in depth approach.

Mitigating Threats in the Corporate Internet Module

Table 18-14 shows the expected threats and mitigation techniques for the Corporate Internet module.

Design Guidelines for the Corporate Internet Module

The ISP routers provide egress filtering as specified in RFC 2827 and also filtering of RFC 1918 address spaces from the ISP cloud to the Corporate Internet module. In addition, there are rate limits on nonessential traffic. This helps mitigate against denial-of-service (DoS) and distributed denial-of-service (DDoS) attacks. Basic filtering is configured at the ingress of the first routers to the module and with RFC 1918 and RFC 2827 filtering. Any IPSec traffic destined for the VPN and Remote Access modules is permitted through.

The NIDS appliances provide for Layer 4 through Layer 7 inspection; however, because of the filtering done at the edge routers, they can focus their attention only on the protocols allowed through the edge. The alarm levels on the signatures of the NIDS outside the firewalls are set lower than those same signatures on the NIDS inside the firewall because signatures seen here represent attempts at attacks instead of successful penetration of the firewall perimeter.

The firewalls in this module provide for additional filtering of traffic into the corporate network and to the publicly available servers. Placing the servers on a DMZ leg off the firewalls both limits traffic to the servers and sets up egress filtering specifically designed to prevent unwanted outbound connections.

The content inspection segment traffic is limited to URL filtering requests from the firewall to the URL-filtering server. This device inspects outbound traffic against a database of permitted sites and instructs the firewall on whether to permit the traffic.

Both the public services segment in the firewall DMZ and the segment behind the firewall have NIDS deployed in a more restrictive stance than the NIDS directly behind the routers. This is because attacks that these devices see are application layer attacks and have made it through the firewall's filtering policy.

Finally, all hosts should be locked down and patched to the latest patch levels, and host-based IPS should be deployed to help prevent an attacker from compromising the system.

The key devices in this module are listed in Table 18-15.

Design Alternatives for the Corporate Internet Module

Several alternative designs exist for this module. Placement of the NIDS appliances in front of the firewall might not be required. This is particularly important if no filtering is being done before the firewall. If filtering is done on the edge routers, the NIDS provides the capability to monitor this filtered traffic and to alarm only if an attack is seen in the filtered traffic. Alternatively, it is possible to turn on all the signatures in the NIDS database and set the alarm levels for attacks on services blocked by the router to a higher level than all others. This is known as a reverse policy.

The NIDS monitors all traffic coming in, even the traffic filtered by the router. If the NIDS sees traffic that should be filtered, a serious policy violation has occurred and the NIDS should raise the highest possible alarm to indicate that a significant event has occurred. Alarms from this NIDS probably should be logged to a separate management station because the number of alarms generated would be greater than those generated by internal NIDS. The number of alarms from the external NIDS easily could overwhelm the number of alarms generated by the internal NIDS, and internal alarms might go unnoticed.

The WAN Module

The WAN module is used to provide connections to remote locations or extranet partner networks. Frame Relay encapsulation is used, and traffic is routed between the remote and central sites.

Mitigating Threats in the WAN Module

Table 18-16 shows the expected threats and mitigation techniques for the WAN module.

Design Guidelines in the WAN Module

Security in the WAN module is provided through the use of ACLs and additional Cisco IOS security features. Inbound ACLs restrict what traffic is permitted into the enterprise network campus layer from the remote locations, and outbound ACLs determine what traffic from the enterprise campus layer is permitted to reach the remote networks. Some of the additional Cisco IOS security features include the firewall feature set, which provides firewall capabilities within the router, in-line IDS capabilities, TCP SYN flood attack mitigation, and IPSec VPN tunnel termination.

Design Alternative for the WAN Module

The only alternative to this design is to use IPSec VPNs for all WAN connections to remote sites.