Idea Transcript
Internet Edge Security Design Principles March, 2004
Corporate Headquarters Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA http://www.cisco.com Tel: 408 526-4000 800 553-NETS (6387) Fax: 408 526-4100
THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS. THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY. The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB’s public domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California. NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS” WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE. IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. CCIP, CCSP, the Cisco Arrow logo, the Cisco Powered Network mark, Cisco Unity, Follow Me Browsing, FormShare, and StackWise are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn, and iQuick Study are service marks of Cisco Systems, Inc.; and Aironet, ASIST, BPX, Catalyst, CCDA, CCDP, CCIE, CCNA, CCNP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, the Cisco IOS logo, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Empowering the Internet Generation, Enterprise/Solver, EtherChannel, EtherSwitch, Fast Step, GigaStack, Internet Quotient, IOS, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, LightStream, MGX, MICA, the Networkers logo, Networking Academy, Network Registrar, Packet, PIX, Post-Routing, Pre-Routing, RateMUX, Registrar, ScriptShare, SlideCast, SMARTnet, StrataView Plus, Stratm, SwitchProbe, TeleRouter, The Fastest Way to Increase Your Internet Quotient, TransPath, and VCO are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and certain other countries. All other trademarks mentioned in this document or Web site are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0304R)
Internet Edge Security Design Principles Copyright © 2004 Cisco Systems, Inc. All rights reserved.
CONTENTS Internet Edge Security Design Principles
1
Security Design Requirements 1 Security Policy Definition 1 Host Addressing 2 Application Definition 6 Usage Guidelines 7 Topology/Trust Model 8 Stateful Traffic Inspection 10 Engine Performance Considerations 10 Resiliency 10 Intrusion Detection 11 Network-Based Intrustion Detection (NIDS) 11 Host-Based Intrusion Detection (HIDS) 12 Variance-Based Capture Systems (Honey Pots) 12 IDS Implementation And Performance Considerations
13
Performance Considerations 14 Scalability Requirements 14 Bandwidth 15 Connection Rate 15 Total Connections 16 Asymmetry Concerns 16 Forwarding 17 Translation 17 Security Considerations 19 Element Security 20 Identity Services 20 Common Internet Edge Security Policies
21
INDEX
Internet Edge Security Design Principles Version 1.0
iii
Contents
Internet Edge Security Design Principles
iv
Version 1.0
Internet Edge Security Design Principles This document provides an overview of the basic principles involved in the design of Internet edge security. It discusses: •
Security Design Requirements
•
Performance Considerations
•
Security Considerations
Security Design Requirements Network security is based on the following basic principles: •
Identity — The ability to challenge the credentials offered by a user or host and, based on their validity, determine which network resources they are authorized to access.
•
Trust — The determination of whether information from another device should be accepted. Within network designs, trust is based on the inherent or explicitly constructed ability of the network to forward traffic between hosts.
•
Enforcement — The ability to enforce security policy using four basic types of mechanisms: trust limiting/definition, monitoring capabilities, audits, and security management tools and procedures.
•
Risk — The determination of the likelihood of the network being compromised. Network security has its basis defined relative to the potential risk associated with both known and unknown threats to the network, from internal and external sources.
•
Assessment — The continual evaluation of the validity and effectiveness of the security policy and its implementation. Network security is an ongoing process and network security policies must undergo periodic review to determine how to improve their enforcement and ensure their viability as the network grows and changes.
Because of the transitional nature of the Internet edge, which represents the outer perimeter of the enterprise, there is no area of network design in greater need of network security expertise.
Security Policy Definition Security policy combines the five principles of security (Identity, Trust, Enforcement, Risk, Assessment) into a series of statements, which are used as guidance in developing and implementing a network security design.
Internet Edge Security Design Principles Version 1.0
1
Internet Edge Security Design Principles Security Design Requirements
For example, take the case where a network administrator determines that, due to the lack of authentication security, Telnet sessions should be prohibited in any direction across the Internet edge. The administrator then crafts the following example security policy: “Due to authentication security concerns, particularly the potential for username/password information to be captured by third parties in cleartext format, Telnet traffic (TCP port 23) will be blocked in all directions by the corporate Internet firewall. This policy includes session attempts initiated by any internal user. The use of non-standard TCP ports by Telnet applications is not an authorized alternative. Corporate users impacted by this policy should migrate affected applications to use the SSH protocol. Exceptions to this policy will require the CIO's written approval.” Upon reviewing the above example, you would find that it meets the principles of security as defined above. It is equally clear that although the author of this example policy is defining enforcement using a firewall, they recognize the fact that the use of non-standard TCP ports by Telnet applications is a potential risk. They may not be able to prevent users from using Telnet on TCP port 80, but by indicating that this is not authorized, they make known the possibility of corrective action if non-standard Telnet usage is detected. This section discusses the elements that embody effective security policies and the security mechanisms that can be deployed at the Internet edge, including: •
Host Addressing
•
Application Definition
•
Usage Guidelines
•
Topology/Trust Model
Figure 1 provides a view of design factors and threat factors that are key elements in developing policies. Security Policy Elements
Threat factors
Design factors Host addressing
Vulnerabilities
Application definition Usage guidelines Topology/trust model
Denial of service Policy
Misuse Reconnaissance
76681
Figure 1
Host Addressing One of the basic tenets of Cisco's SAFE blueprint for network security is the use of modular and hierarchical network designs that allow segregation of network hosts based on organizational and functional boundaries. To that end, structured host IP addressing and subnet design can be among the most powerful tools in developing and enforcing network security policies.
Tip
For more information about SAFE, see the white paper titled SAFE: A Security Blueprint for Enterprise Networks, located at: http://www.cisco.com/warp/public/cc/so/cuso/epso/sqfr/safe_wp.htm
Internet Edge Security Design Principles
2
Version 1.0
Internet Edge Security Design Principles Security Design Requirements
Host Addressing Guidelines When developing security policies, use the following IP addressing guidelines: 1.
Wherever possible, hosts of dissimilar organizations or network functionality should not co-exist within the same subnet. For example, servers and user workstations should not be placed within the same subnet boundary, as policy rules written for each would be significantly different. If a server is placed in the same subnet as user workstations, a Layer 2 (Ethernet MAC, etc.) trust association exists between that server and its clients. Therefore, security between these clients and the server is based purely on host configuration; the network does not participate. However, if the user workstations are placed in a different IP subnet, a Layer 3+ (IP, TCP, UDP, etc.) device exists between the server and the clients and some level of policy enforcement can then be applied at the network level. If a server is placed within the same subnet as user workstations, a Layer 2 (Ethernet MAC, etc.) trust association exists between that server and its clients. Therefore security between these clients and the server is based purely on host configuration; the network does not participate. However, if user workstations exist on an IP subnet different from that of the server, this means that a Layer 3+ (IP, TCP, UDP, etc.) device exists to which you can apply some level of policy enforcement at the network level.
Figure 2
Bounded and Unbounded Hosts Within a Common Subnet
Users B .129
C .130
D .131
E .132
Server
Printer
F .2
G .3
Secondary exploits .1
A
Vulnerability exploit
76682
192.168.1.0/24
External networks
In Figure 2, users, the printer, and the file server exist within a common subnet, 192.168.1.0/24. Server F is vulnerable to external security exploits. If compromised, Server F could be used to launch secondary attacks against other hosts within the subnet. Since trust exists at Layer 2, as no Layer 3 boundary exists between these hosts, the attacks can be Layer 2 or Layer 3 in nature. Examples of Layer 2 attacks include ARP spoofing and MAC flooding, either of which allow the
Internet Edge Security Design Principles Version 1.0
3
Internet Edge Security Design Principles Security Design Requirements
compromised server F to observe and collect flowing across the entire network. Even if router A was shielding the user hosts and the printer from potential IP vulnerabilities via ACL, those vulnerabilities can be successfully launched from the compromised server. The reverse is true as well. A compromised user or low-level server (e.g. printer) can potentially be used to attack the server and/or other hosts within the subnet. Figure 3
Bounded and Unbounded Hosts on Separate Subnets
Users B .130
D .132
C .131
Server
Printer
F .2
G .3
E .133
192.168.1.128/25
192.168.1.0/26 .129
192.168.1.64/26
Failed secondary exploits .1
Vulnerability exploit
A
External networks
76683
.65
In Figure 3, the same network exists except the servers and printers are segregated on separate subnets. The actual implementation uses VLANs to provide three separate logical segments on the edge switch, and requires a single physical interface on the router. By using ACLs to filter IP traffic, you significantly mitigate the probability of secondary exploitations between bounded and unbounded hosts. Use the ACLs between: – The users and the server, limited to file and print server protocols – The server and the printer (assuming the server provides print spooling services), limited to
print server protocols – The users and the printer (assuming the printer provides its own print spooling services), limited
to print server protocols 2.
By design, each subnet should include network devices as well as various hosts. Therefore, within a subnet's address design, hosts of differing network properties should be grouped in bit-wise boundaries to allow them to be represented by a single access control list (ACL) statement. The second guideline assumes that all IP subnets have at least one host that acts as a default gateway (and in many cases two such devices exist). Also, it may be more administratively efficient to have hosts of differing network properties share a common set of Layer 3 interfaces on network devices. In such cases, hosts of similar properties within a subnet should be grouped within bit-wise
Internet Edge Security Design Principles
4
Version 1.0
Internet Edge Security Design Principles Security Design Requirements
boundaries in that subnet. For example, consider a 254-host subnet that is required to support: two IP gateways, 100 DHCP-configured hosts (50 workstations and 50 IP phones), and 4 hosts with fixed IP addresses (ex. teleconferencing stations, printers, etc.). One possible bit-wise addressing solution could include (let’s assume a network IP address of 192.168.1.0): – An IP address range of 192.168.1.1 to 192.168.1.6 (falling within the bit-wise range of
192.168.1.0/29) for use by the two gateways (.2 &.3), an explicit HSRP address for the gateways to share (.1), and unused addresses available for management of other network devices (such as switches) within the subnet. – An IP address range of 192.168.1.8 to 192.168.1.14 (falling within the bit-wise range of
192.168.1.8/29) for use by the fixed IP address hosts with two additional addresses available for growth. – An IP address range of 192.168.1.129 to 192.168.1.254 (falling within the bit-wise range of
192.168.1.128/25) for use by DHCP hosts. If DHCP servers can differentiate pools by requestors MAC prefixes, two ranges of 192.168.1.128/26 and 192.168.192/26 could be used for further segmentation of IP phones and workstations.
Note
Figure 4
24 bits 1 x 254
Although the first and last addresses of these ranges can be assigned to hosts (because only the first and last IP address of a subnet itself are reserved for broadcast use), you should avoid using them. This allows for ease of migration should there be a need to break out of these ranges in the future. Class C Network Space
25 bits 2 x 126
26 bits 4 x 62
27 bits 8 x 30
28 bits 16 x 14
29 bits 32 x 6
30 bits 64 x 2
.255
255.255.255.0 255.255.255.128 255.255.255.192 255.255.255.224 255.255.255.240 255.255.255.248
76684
255.255.255.252
.0
Figure 4 provides a breakdown of a Class C (254 host, 24 bit mask) network space. Note that this diagram assumes classless routing. (Older classful routing structures disregard the first and last subnet of a given classful space, which makes 25 bit subnetting unavailable for a Class C address space.)
Internet Edge Security Design Principles Version 1.0
5
Internet Edge Security Design Principles Security Design Requirements
By addressing like function hosts within a subnet along bit-wise boundaries, it is possible to craft ACLs in a meaningful fashion. Using the bit-wise addressing solution above, apply the following policy rules: •
Since all network devices use other interfaces for network management purposes, no traffic should be allowed to access these devices from within the subnet.
•
The four fixed hosts only externally communicate with hosts on the 192.168.100.0/24 subnet.
•
Users are not allowed to use telnet for any reason.
The following are the IOS ACL results: interface FastEthernet0/0 ip address 192.168.1.1 255.255.255.0 ip access-group 101 in access-list access-list access-list access-list access-list
101 101 101 101 101
deny ip any 192.168.1.0 0.0.0.7 permit ip 192.168.1.8 0.0.0.7 192.168.100.0 0.0.0.255 deny ip 192.168.1.8 0.0.0.7 any deny tcp 192.168.1.128 0.0.0.127 any eq telnet permit ip 192.168.1.0 0.0.0.255 any
While discipline in developing IP addressing conventions can be readily achieved in new network designs, one of the major obstacles that network security administrators face is inconsistency of existing host IP addressing. One solution is to use available private IP address spaces (as defined by the IETF in RFC 1918) to establish 'green-field' address spaces, into which existing hosts are migrated to achieve a desired IP address structure. However, private IP address spaces require the use of network address translation (NAT) devices to allow the hosts to communicate with the Internet.
Application Definition The application definition process for the Internet edge appears straight-forward. Many applications are relatively simple and make use of well-known TCP/UDP ports or IP protocols. For example, you expect HTTP traffic to use TCP/80. Others, particularly multimedia applications, make use of a complex combination of ports and protocols. Examples here are IPSec, which makes use of UDP/500 for Internet Key Exchange (IKE), IP protocol 50 for Encapsulating Security Protocol, and IP protocol 51 for Authentication Headers; and H.323, which includes dynamically created RTP streams using high UDP port numbers. Defining applications is the process of researching and observing network applications in order to determine the IP networking environment that must exist for application to properly functioning. The end-result of this process provides administrators with information regarding the supported IP network applications they can use to correctly set up their network security enforcement mechanisms, without impacting the productivity of these applications. Unfortunately, many commercial applications do not provide the level of IP information that is necessary to develop a clear application definition. Therefore, administrators are often required to test applications and solutions within a test network to provide full application definition. A full application definition includes: •
A description of the IP protocols used, including a clean capture of a typical session delineating their use.
•
Reports from auditing tools identifying open ports and protocols on workstations, servers, and other network devices used to host the proposed solution. The purpose of such active ports and protocols should be clearly identified with the results used to disable unnecessary services (to minimize risk) included.
•
An operation, maintenance, and management plan for the proposed solution. Network management protocols must be included in the protocol definitions previously stated.
Internet Edge Security Design Principles
6
Version 1.0
Internet Edge Security Design Principles Security Design Requirements
For example, a network administrator is tasked with setting up a basic public web server. The resulting application definition is shown in Figure 5. Figure 5
Basic HTTP Application
Enterprise networks Web server A
Web client B
Src IP:B, Dst IP:A, TCP, Src Port:High, Dst Port: 80
Src IP:A, Dst IP:B, TCP, Src Port:80, Dst Port: High(same) Response
Note
76685
Request
Although the full TCP handshake is not shown, it is assumed that this session fully conforms to the requirements for a normal TCP session. In addition to the basic function shown in Figure 5, the application definition should also include the following information flows, which are required for proper operation of the solution:
Note
•
The DNS request/reply originating from user B’s network to the network's DNS service.
•
Flows of additional applications required to monitor and maintain the web server.
•
Flows for support for back-end applications that ties into the web-server front-end.
Enterprises typically implement a wide variety of applications for employee productivity. Therefore, security administrators should adopt a practice of participating in their planning and implementation and explicitly defining how those applications are supported within their enterprise networks.
Usage Guidelines Although every Internet edge offers the ability to communicate to other hosts on the Internet, many sites may want to restrict those communications to productive use. By publishing Internet usage guidelines, administrators provide users with a way to self-regulate their Internet usage, thus helping the site maintain maximal utilization of limited Internet access resources. Define usage criteria as enforceable guidelines. This is important for a number of reasons: •
Without the ability for the Internet edge to enforce usage guidelines, users may choose to maintain or ignore such guidelines when convenient. For example, a departing employee may choose to divulge sensitive company information. Again, enforcement is a basic principal of security, and the best security policies have defined enforcement mechanisms to deter malicious activity
•
Many hosts, such as Internet-accessible servers, must operate autonomously. For these hosts, usage guidelines must be enforceable in an equally autonomous fashion at the Internet edge.
Internet Edge Security Design Principles Version 1.0
7
Internet Edge Security Design Principles Security Design Requirements
•
Users and hosts on the Internet are not subject to defined usage guidelines without enforceability. Although an application definition provides most of this usage structure, the Internet edge can offer additional protection for hosts accessing and accessible by the Internet.
One of the significant challenges of network security design is discriminating malicious and non-productive traffic based on content. It is unfortunate that attacks based on malicious code (viruses, worms, malformed requests) appear innocuously as e-mail attachments, HTT requests, and potentially other traffic types that are allowed to flow through the perimeter of the network. While the use of third-party application filters (e-mail scan, URL filtering, etc.) and content networking engines aid in the mitigating such attacks, intrusion detection systems and anomalous data analysis capabilities are needed to effectively detect and twart such threats.
Topology/Trust Model Perhaps the most significant design factor in developing security policies is trust within the network design. Host reachability and the success of networked (and Internet) applications are based on the existence of a trusted forwarding patch between hosts. Levels of Trust in Network Designs
Operational
Subnet
Internet
Subnet
76686
Figure 6
Application
Figure 6 illustrates the four basic levels of trust within network designs: 1.
Subnet—Trust between hosts potentially reachable within the same Layer 2 media.
2.
Internet—Trust between hosts on different subnets, potentially reachable via IP forwarding mechanisms.
3.
Application/Session—Trust between hosts on the same or different IP subnets, based on operating a common set of network applications or protocols.
4.
Operational—Trust which is based on the user's judgement and processes in accessing the network, as well as the ability to manage network functions.
Within a subnet, trust between hosts is based on Layer 2 mechanisms. In nearly all cases, Ethernet-based Layer 2 rules apply, due to the preponderance of that media within network designs. Hosts respond to both unique (unicast) and shared (broadcast/multicast) MAC addresses. The ability to forward traffic between hosts within the same subnet is based upon knowledge of the MAC address.
Internet Edge Security Design Principles
8
Version 1.0
Internet Edge Security Design Principles Security Design Requirements
With shared media (hubs), subnets represent pure trust zones within networks. This is because with shared media, each host sees all traffic within the subnet. However, with switched media, port-level bridging functions provide basic discrimination of unicast Layer 2 traffic, so that hosts connected to one interface do not see unicast traffic destined to hosts on other interfaces. Switches can provide additional Layer 2 traffic discrimination mechanisms, both standards-based and proprietary, including: •
VLAN tagging (802.1Q and ISL), which can provide virtual segmentation of traffic across common physical media.
•
Port-level security mechanisms, which control the learning and inclusion of MAC addresses, as well as port-level traffic-rate limitations.
•
Bridge-level filtering mechanisms, including MAC-filtering, multicast support, and Layer 2-based ACLs (VACLs).
•
MAC-independent Layer 2 forwarding rules, such as the use of private VLANs on Catalyst switches, which can be used to fashion port-level forwarding rules based on the intended function of a port rather than the specific MAC addresses of hosts accessible via that port.
The importance of Layer 2 trust may not be clear to the functions of the Internet edge, which by its nature deals predominantly with Internet, Application/Session, and Operational trust issues. However, network security designers must be aware of the consequences of a security breach, and the ability of intruders to make use of existing trust (including Layer 2 trust) to perform secondary exploitations on other hosts within the enterprise. For example, if Internet-accessible servers of different functions exist on a common DMZ subnet, the compromise of one server could result in the secondary exploitation of other servers, leading to their compromise. If one of these compromised servers has a trust relationship to an internal host, that host could also be compromised. In designing the Internet edge, administrators must not fall into the trap of relying on perimeter security mechanisms only, and must consider the internal threat posed by potentially compromised hosts. Internet-level trust is based on the reachability of hosts by means of their IP addresses. The foremost requirement here is a viable IP forwarding path between two hosts. This is a concern associated with routing protocols, static routes, and other policy-based forwarding mechanisms. The ability to limit Internet-level trust is based on two mechanisms: •
The ability to limit IP forwarding by discriminatingly disabling a forwarding path. There are a number of route poisoning mechanisms available to do this.
•
The ability to limit IP forwarding, based on source or destination IP address filtering. In addition to strict address and network definition by actual IP address, advanced mechanisms are available to limit access by hostname resolution.
In addition to unicast IP traffic, Internet trust must deal with broadcast and multicast traffic. With regard to IP broadcast, directed broadcast to other IP subnets should be prohibited. While broadcasts may have effective local significance in IP to Layer 2 address resolution, inter-subnet broadcast applications are virtually non-existent and represent a significant potential for Denial-of-Service (DoS) attacks. The many-to-one nature of multicast traffic requires a high trust model, and multicast traffic transiting the Internet edge is usually encapsulated within unicast traffic (GRE), in order to allow security to be established bi-directionally between multicast routers (but not between multicast sources and receivers). Another aspect of Internet trust is associated with 1:1 NAT. NAT is a useful (and often necessary) tool to provide forwarding to internal IP hosts, particularly those using private IP addressing (RFC-1918). NAT devices are most often located within the Internet edge.
Internet Edge Security Design Principles Version 1.0
9
Internet Edge Security Design Principles Security Design Requirements
Stateful Traffic Inspection The firewalls used to create this design guide are stateful inspection firewalls. This means that for TCP-based traffic initiated on trusted interfaces, the firewall tracks the state of those connections and allows correctly formatted TCP responses from remote hosts to pass through to the internal hosts that were the session originators. As many common Internet applications are TCP-based, the use of stateful inspection firewalls provides effective protection while maintaining high-performance capabilities. However, it is important not to become overly reliant on the defensive mechanisms offered by stateful inspection firewalls. Although TCP-based traffic can be monitored statefully, UDP and ICMP-based traffic is connectionless and cannot be tracked, and other IP protocols (GRE, IPSec ESP and AH) are not only stateless, but may impact the ability to implement address translation mechanisms. Stateful inspection firewalls rely on simple access control to limit these traffic types, and offer only timers for responses matching internally originated requests. For these reasons, Cisco recommends that you strictly limit ICMP, UDP, and other IP protocol firewall rules. The obvious exception is DNS traffic (UDP/53), which is generally required for hostname translation of Internet hosts. The other potential drawback of stateful inspection firewalls is in their limited ability to detect application-level vulnerabilities. For example, if a firewall rule allows IPSec traffic to pass through (IP protocol 50 for ESP and 51 for AH, plus UDP/500 for IKE), the firewall cannot peek into the tunneled data stream to determine if malicious activity is occurring. Firewalls can make use of internal or third-party application filters that can help detect and mitigate application-level attacks (such as URL filters and SMTP content inspection engines). Cisco firewalls also make use of protocol fixups, which can monitor and predict the behavior of specific applications. This is useful for complex applications that make use of additional TCP/UDP ports for multi-session data transfers (such as H.323 for Voice over IP), and allows administrators to support these applications without opening large ranges of ports. Stateful inspection firewalls provide the ability to focus permitted traffic to only that required for supported network applications. While deploying firewalls is no cure for effective edge device and internal network security, they are the cornerstone of Internet edge design.
Engine Performance Considerations When placing a firewall in a security design, it is important to consider the firewall’s performance, as this determines how well your design withstands DoS attacks. In addition to forwarding IP traffic, stateful inspection firewalls must maintain connection tables. Factors such as connection rates, the number of total and embryonic (half-open) connections allowed, and the maximum time that state is maintained on an idle connection directly impact on the ability of the firewall to deal with periods of heavy demand. For more information, see Performance Considerations, page 14.
Resiliency When developing resiliency into Internet edge designs, consider the following: •
How quickly can a fault be detected and the backup, or standby, unit take up the load?
•
Can statefulness be maintained in recovering from a fault condition?
•
How does the failed unit impact unaffected upstream/downstream devices?
•
How are administrators advised of the failed condition and deployment of resiliency mechanisms?
Internet Edge Security Design Principles
10
Version 1.0
Internet Edge Security Design Principles Security Design Requirements
Cisco PIX firewalls provide failover mechanisms, including stateful failover capabilities, which can be used to develop resilient Internet edge designs. Routers that use the Cisco IOS software Firewall Feature Set do not offer explicit firewall failover mechanisms; but they can make use of router resiliency mechanisms, such as HSRP/VRRP, and routing protocol configurations to provide basic failover capabilities. In addition to firewall resiliency, basic routers and switches used in the design can also be deployed in a resilient fashion. For Layer 2 resiliency, it is important to avoid the use of the spanning-tree protocol (IEEE 802.1D loop-detection), as its reconvergence time precludes the ability to maintain stateful failover mechanisms. Although there are existing and future fast Layer 2 convergence mechanisms, their use must be fully tested comparative to the Layer 3 mechanisms (router/firewall) required to maintain statefulness.
Intrusion Detection At the Internet edge, intrusion detection capabilities play an active role in defending the enterprise from Internet-based attacks. It is not the intention of this design guide to examine the intricacies of intrusion detection system (IDS) design, deployment, and management. However, it is important to touch on the fact that Internet edge designs offer the ability to employ effective intrusion detection capabilities. Generally, there are three basic intrusion detection systems deployed at the Internet edge: 1.
Network-Based Intrustion Detection (NIDS)
2.
Host-Based Intrusion Detection (HIDS)
3.
Variance-Based Capture Systems (Honey Pots)
Additional or future systems (such as anomaly detection, behavior pattern matching, identity-based profiling) can also participate in the designs offered in this guide.
Network-Based Intrustion Detection (NIDS) NIDS capabilities are provided in two ways: 1.
The intrusion detection capabilities inherently available within the Layer 3 (router/firewall) devices within the design.
2.
The use of external NIDS sensors, which promiscuously monitor IP traffic at discreet points within the design.
The primary responsibility of firewalls and routers is to forward IP traffic—not to store or buffer it for signature analysis. Therefore, the NIDS capability offered within the PIX firewall and IOS Firewall Feature Set is limited to approximately 60 exploit signatures, which can be used on streaming data (attacks that can be detected in one to a few consecutive packets). Also, the use of these mechanisms can impact the overall performance of these units. However, NIDS may be useful in smaller Internet edge designs, where a full scale IDS is not cost-justified. The use of external IDS sensors assumes the ability to attach the sensor to the network in a promiscuous fashion. There are often philosophical discussions by network security experts as to which side of the firewall the sensor should be placed (to the ultimate conclusion that you should have a sensor on each firewall interface). That aside, it is important to understand the limitations in using external sensors: •
External sensors work best on shared media (hubs), because their half-duplex operation mitigates sensor overrun issues.
Internet Edge Security Design Principles Version 1.0
11
Internet Edge Security Design Principles Security Design Requirements
•
When using a switched port analyzer (SPAN) port to monitor a switch port, establishing a full-duplex SPAN can result in up to 50% packet loss on the NIDS sensor as the monitored port reaches full load. This is due to the fact that bi-directional traffic is being offered to a SPAN port that is able only to uni-directionally forward traffic to the sensor.
•
When monitoring multiple ports (as with a VLAN) or bi-directional traffic on a single port, buffer overruns on the SPAN port or sensor interface can result in lost packets.
•
Although sensor tuning can help reduce false positive indications, they do not help with packet loss on external NIDS sensors. The exception is the use of VACLs on a Catalyst 6000/6500 series switch, which can filter which packets are copied (not SPAN) to a NIDS sensor port (usually an IDSM that resides within the switch itself).
If NIDS is to be deployed within Internet edge designs, hubs, SPAN capable switches, or Catalyst 6000/6500 switches need to be included to allow NIDS sensor connectivity.
Host-Based Intrusion Detection (HIDS) A general security policy recommended for Internet edge design is that no Internet-originated traffic should pass directly to the interior of an enterprise network. Therefore, hosts that must be accessible from the Internet should be placed in neutral zones, or DMZs. Because DMZs are part of Internet edge design, provisions should be made to include HIDS on Internet-accessible hosts. This provides a means of detecting application-level and operating system malicious activity on such hosts. As HIDS is deployed on edge hosts, the HIDS selection depends on the operating systems running on the protected hosts. For example, the Cisco Host Intrusion Detection System (powered by Entercept) provides support for Microsoft Windows 2000/XP and Sun Solaris based operating systems, while there are numerous open-source solutions for the Linux environment. HIDS generally differs from personal firewalls. HIDS systems harden the behavior of the underlying OS and applications, while personal firewalls focus on the behavior of the host’s IP network layer. HIDS is highly effective on bounded hosts such as servers, where the host is expected to receive IP traffic in support of network applications and requires protection at the application layer. Personal firewalls are most effectively deployed on unbounded user hosts, which should not receive unsolicited IP traffic. Laptops and other user systems that use the Internet as transport benefit from the deployment of personal firewalls.
Variance-Based Capture Systems (Honey Pots) Variance-based capture systems, or honey pots, deploy decoy systems on otherwise unused enterprise IP addresses that are accessible from the Internet. Honey-pots provide a number of advantages. Use a honey-pot to obscure more valuable hosts, by providing additional targets detectable by a ping sweep and other scanning mechanisms. Honey-pot systems most often respond to such activity, offering the attacker easy vantage points in hopes to draw them away from true application hosts. They provide the opportunity to monitor and analyze specific attacks. This information can then be used to strengthen existing defenses. Honey-pots are also useful in collecting evidence for law-enforcement efforts.
Internet Edge Security Design Principles
12
Version 1.0
Internet Edge Security Design Principles Security Design Requirements
Caution
A word of warning on the use of honey-pots—as their nickname suggests, they are effective in attracting potential attackers towards your network. With regard to obscuring meaningful hosts, experienced attackers will know to avoid obvious targets in favor of those that do not respond to basic scans. Honey-pots should only be deployed if the enterprise is committed to full-time expert analysis of their data.
IDS Implementation And Performance Considerations There are five major factors to consider when determining IDS implementation requirements: 1.
Optimal sensor placement
2.
Sensor performance characteristics
3.
Limiting false positive indications
4.
Frequency of signature update, and the ability to develop customer signatures
5.
IDS event analysis and reporting
HIDS is dependant on the placement of the protected host. Optimal sensor placement really deals with the deployment of NIDS sensors. There are three areas of NIDS sensor placement to consider: •
Perimeter Exterior – Placing the NIDS sensor on the segment immediately outside the firewall. The principal benefit of this sensor placement is that the sensor has a full view of all attacks against the enterprise. The principal disadvantages are that this placement does not filter out those attacks that would be blocked by the network perimeter. A growing issue with this placement is the use of broadband and/or VPN encapsulation of traffic terminating on the firewall. Encapsulation may shield attacks from detection.
•
Perimeter Interior –Placing the NIDS sensor on the segment immediately inside of a firewall (can be an inside or on a DMZ interface). The principal benefit of this sensor placement is the focus placed on attacks that have passed through perimeter defenses. The disadvantage is that this placement is not effective in detecting scans and DoS attacks, which are stopped by the firewall.
•
Enterprise Interior – NIDS deployment within the interior of enterprise networks is useful in protecting critical network assets. The problem is that the performance of LAN backbones often exceeds the performance capabilities of NIDS sensors, resulting in sensor-overrun. Thus, internal sensors must be properly tuned to focus on analyzing those protocols of importance to the protected systems.
Sensor performance is limited by the throughput rate supported by the sensing, or promiscuous, interface. For example, if an NIDS sensor has a Fast Ethernet interface, then it can theoretically receive and process 100 Mbps of IP traffic. However, if the source of traffic being analyzed is a switch span port monitoring both the send and receive of another Fast Ethernet port, that results in sensor-overrun, with potentially 200Mbps of traffic monitored by a device capable of receiving only 100 Mbps. If the span port is monitoring multiple ports, for example a VLAN, sensor-overrun is due to buffer-overruns on the span port, in addition to bandwidth mismatch. Proper sensor placement is a critical factor in preventing sensor-overrun. For example, while the core switches of an enterprise network appear to be an excellent placement for a NIDS sensor, because it is central to the IP traffic flowing across the enterprise, the bandwidth supported across the core switches would most certainly exceed the capabilities of available NDIS sensors. However, placement of NIDS sensors on the edge switches supporting mission critical server connectivity may not only offer a more scalable placement, but also allow upstream routers to filter the traffic destined for servers only to that pertinent for the operation of network traffic, which aids is reducing the number of false positive indications.
Internet Edge Security Design Principles Version 1.0
13
Internet Edge Security Design Principles Performance Considerations
You can also use sensor tuning to reduce the number of false positive indications provided by IDS sensors. Tuning IDS sensors generally includes the following tasks: •
Based on your supported application definitions, prioritize those signatures with direct relevance to protecting those applications and supporting network assets.
•
Filter out network management traffic sourced from legitimate sources that would otherwise falsely trigger attack signatures.
•
Analyze IDS alarms and prosecute their causes. If the traffic is legitimate and predictable behavior, create filters to eliminate future false positive indications.
•
Consider filtering traffic that may be sourced from actual attacks, but is known to be blocked by your network networks defenses. Such attacks can be used to ‘dazzle’ a sensor with large numbers of false positives, which due to the resulting sensor-overrun condition, blinds the sensor to the actual attack.
An effectively deployed IDS system has the ability to be updated with both new/revised signatures from the IDS vendor, as well as with custom signatures that are tailored to the enterprise’s specific requirements. The ability to develop custom signatures also provides administrators the ability to respond to newly learned threats, thus providing a more rapid response to new threats than with signature updates alone. The deployment of IDS within enterprise networks results in a significant amount of raw sensor data, possibly from multiple sensors (both HIDS and NIDS). This requires the inclusion of event collection, analysis, and reporting tools as part of the IDS implementation.
Performance Considerations In the Internet edge, performance is determined by the following: •
Scalability Requirements
•
Asymmetry Concerns
Scalability Requirements Generally, the scalability and performance of the Internet edge is based on the following factors: •
Bandwidth—The maximum available throughput supported by the Internet edge. Bandwidth measurements are broken down into two significant values: – Session Bandwidth—Defined by the maximum available throughput supported by individual
elements. Available session bandwidth is based on the limiting value that a single session's packets incur while traversing the Internet edge. – Aggregate Bandwidth—Defined by the maximum available throughput supported by multiple
elements. While a single session may be limited by the throughput value across a single path, multiple active paths allow a higher aggregate throughput across multiple sessions. •
Connection Rate—A rate measured in connections per second. This value is a measure of the scalability an Internet edge has in supporting user populations. Connection rate measurement are broken down into two significant values: – Steady-State Connection Rate—The number of connections per second supported across the
Internet edge on a continual basis. – Maximum Connection Rate—The maximum number of connections per second supported
across the Internet edge, but possibly not on a continual basis.
Internet Edge Security Design Principles
14
Version 1.0
Internet Edge Security Design Principles Performance Considerations
•
Maximum Number of Connections—The total number of connections supported across the Internet edge at any given instance of time.
Bandwidth By design, the amount of aggregate bandwidth supported across the Internet edge should be at least equal to the bandwidth supported by its associated Internet connection. In addition, consideration must be given to the number of users (hosts) that can be supported and the average bandwidth available to each user session across the Internet edge. A principle cause for the development of backdoors to the Internet within enterprise designs is a failure of designers to meet a qualitative level of user bandwidth requirements. For example, if the average user feels that a dial-up connection to an ISP has better performance in reaching the Internet than the enterprise provides, then some users may act upon the obvious conclusion, undermining the overall security of the network for the sake of productivity. An aspect of bandwidth support is based on the physical interfacing supported by the Internet edge. For example, while all components within Internet edge may support 10/100BaseTX, device interface throughput may become a limiting factor when dealing with OC-3 or above, ATM, or PoS connectivity to the Internet. Session bandwidth is associated with the concept of the theoretical throughput a single session sustains across the Internet edge. This is a non-aggregate value that provides a basis for scaling the Internet edge design to meet aggregate session throughput requirements. This value represents the maximum sustainable throughput across a single forward path within the Internet edge. As the number of simultaneous sessions increases, the average bandwidth per session decreases. Once average session bandwidth falls below a qualitative threshold, clients begin to sense excessive delay in their applications, resulting in substandard network performance. This is important, as it is at this point that Internet edge designs with single active paths must either be upgraded to support a higher bandwidth or modified to support multiple active paths.
Note
Aggregate bandwidth represents the total throughput supported by multiple active data paths across the Internet edge. Adding additional active paths results in an increase in the number of supportable sessions. However, an individual session (supported across a single active path), is still limited by the maximum session bandwidth value.
Connection Rate There is a direct relationship between the connection rate supported by the Internet edge and the number of users supportable at a given time, which is independent of any relationship between bandwidth size and number of users. If the Internet edge cannot keep up with the number of user session requests per unit time, the resulting lost sessions significantly impact qualitative network performance. Note that for TCP-based sessions, the TCP backoff algorithm adds additional aggravation to a connection request overload situation. TCP-based sessions have a high degree of variance with regard to connection lifetime, as the majority of the traffic is expected to be HTTP-based and, therefore, short-lived. However, this can result in the generation of a very high number of connection requests, particularly during periods of peak network usage. Another factor to consider is that HTTP applications usually launch multiple sessions simultaneously for performance reasons. The steady-state connection rate represents the ability of the Internet edge to support continual operations. This value varies, depending on the traffic characteristics of the individual network. The value defined is the point at which the connection request rate does not exceed the average session
Internet Edge Security Design Principles Version 1.0
15
Internet Edge Security Design Principles Performance Considerations
teardown rate, but may be limited by a device's performance limitation. For example, if the average session teardown rate for a network is 1,000 sessions per second, then the Internet edge is expected to be able to sustain a similar steady-state connection rate. However, if the firewall or load-balancing platform can only support a maximum of 750 connections, that becomes the steady-state (and maximum connection rate) limit for that path across the Internet edge. The maximum connection rate represents the ability of the Internet edge to meet the session launching requirements during a network's busy (burst) period. This value is based solely on the best connection rate performance available via the Internet edge devices. However, the assumption is that at this rate, the connection request rate exceeds the session teardown rate. Therefore, if the maximum connection rate is sustained, the total number of connections will quickly reach a limiting value. Connection rate factors are aggregated across multiple paths through the use of load-balancing or routing mechanisms. This is the principle reason for including load-balanced firewalls in Internet edge designs.
Total Connections Stateful devices within the Internet edge support a maximum number of total simultaneous connections. This maximum total connections represents a volumetric limit as to the number of users or sessions that can be supported by a given design. Once this limit is reached, additional requests for new connections are dropped. It may be that over a period of time (for example, during the course of a business day), the number of sessions may begin to creep up to reach the maximum total connections value. Methods to increase this value include upgrading devices, as well as aggregation across multiple paths. In the case of the latter, it is important to keep in mind that the failure of a single path may result in overloading the remaining ones, if not properly designed.
Asymmetry Concerns Routing or forwarding asymmetry represents the greatest difficulty in developing Internet edge designs with multiple active paths. Asymmetry occurs when a session is split across two forwarding paths. In forwarding traffic, asymmetry may be seen as an inconvenience. Even without statefulness, asymmetry causes difficulties in event collection and security analysis. For example, if a session uses two forwarding paths, this results in the NIDS of each path seeing only half of the session. If a composite attack occurs within that session, it may be possible for that attack to elude signature detection across the NIDS. When stateful devices, particularly firewalls, are inserted into the Internet edge, asymmetry causes serious functional degradation to the design. Asymmetry results in session failures across multiple active firewalls, due to the fact that the firewall on the return path does not have a stateful connection entry, which was created on the firewall of another path. Generally, the following methods are used to combat asymmetry: •
Provide a means of sharing state information across all active parallel firewalls. Such mechanisms must be inherent to the firewall's functionality and are most probably limited to firewalls that are not geographically dispersed, due to latency reasons.
•
Provide mechanisms to eliminate asymmetry by ensuring traffic returns across the same path used to create the initial session state. Unlike the previous method, solutions in this area support geographically dispersed firewalls.
The basic design mechanisms used to eliminate asymmetry fall into the following categories: •
Forwarding
Internet Edge Security Design Principles
16
Version 1.0
Internet Edge Security Design Principles Performance Considerations
•
Translation
Forwarding A principle method of eliminating asymmetry is through explicit or dynamic control of the forwarding information. Deploy a number of methods using basic router capabilities, including: •
Routing protocol configuration, which is used to adjust route propagation and table information in ways to prevent asymmetric paths from forming. Of specific note is the use of BGP mechanisms on Internet-connected routers, particularly in cases where the multiple paths to the Internet are geographically dispersed.
•
Policy routing, which is used to segment traffic across multiple paths, based on Layer 3+ information. For example, the routers upstream and downstream of a set of parallel firewalls are used to receive inbound HTTP traffic across one firewall, send outbound HTTP traffic across another, and send and receive VPN traffic across a third.
•
Resiliency mechanisms, which are used in combination with routing protocol configuration and policy routing.
Asymmetry mitigation is also achieved through the use of dynamic load-balancing devices, which externally maintain a shared-session state table across multiple, active firewalls. In the absence of address translation, a “load-balancing sandwich” method is used, in which the firewalls are placed between a pair of load-balancers to prevent the formation of asymmetric paths by the load-balancing process itself. The performance characteristics (bandwidth, connection rate, total connections) of the load-balancing mechanisms must be taken into consideration. If the elimination of asymmetry results in performance values below or not significantly improved over the use of a single (but possible resilient) path design, then the multi-path design is difficult to justify.
Translation Using NAT at the Internet edge is a highly effective means of eliminating asymmetry. Using IP address translation methods depends on a number of factors, including: •
The deployment of private IP addressing (RFC 1918), thereby requiring the Internet edge to translate private IP addresses into Internet-routable addresses.
•
The need to avoid asymmetric routing concerns associated with operating multiple Internet Edges or active firewalls in parallel.
•
The ability of applications and their associated protocols to function across address translation boundaries. Applications that use fixed source TCP/UDP port numbers or non TCP/UDP IP protocols (for example, IPSec uses IP protocol 50 for ESP, which has no concept of port numbers), or that carry the original IP address untranslated within the payload generally do not function across a source port address translation (PAT) boundary. Untranslated IP address information carried within the data payload of an IP packet results in application failure even across static 1:1 NAT boundaries.
•
NAT methods may be desirable to overcome complex routing obstacles. For example, a translation boundary across two different autonomous systems (AS) may be easier to administrate than setting up inter-AS route peering.
Internet Edge Security Design Principles Version 1.0
17
Internet Edge Security Design Principles Performance Considerations
In all cases, the translating device is responsible for providing proxy-ARP services for the host IP addresses being translated. This is necessary to ensure proper Layer 2 forwarding of packets to upstream devices. If the next upstream device uses static ARP tables, it must be understood that hosts behind a firewall or other translating device have the same MAC address and possibly the same IP address (in the case of 8:1 source PAT to the interface IP address of the device). Table 1 describes the types of NAT mechanisms available when designing an Internet edge and provides guidance for their use. The following terms are used in this table and often used when describing IP address translation mechanisms: •
Local Address—A local IP address is the address assigned directly to the IP host being translated.
•
Global Address—A global IP address represents a single IP address or pool of IP addresses available to the translating device to use for IP address translation. Relative to the host being translated, the global IP address is the address that this host advertises on the other side of the translating device.
•
Inside Interface—The interface of the translating device accessible to the local IP addresses of the hosts to be translated. Relative to the host being translated, this interface is the one facing towards the host's subnet.
•
Outside Interface—The interface of the translating device providing global IP addresses for hosts to be translated. Relative to the host being translated, the translating device must forward (and therefore translate the source address of) IP packets passing to/through this interface.
The table below describes the types of NAT mechanisms available the Internet edge, and provides guidance for their use: Table 1
NAT Mechanisms
Address Translation Method
Description
Guidelines for Use
1:1 Static NAT
The translating device translates a discretely defined local IP address on the inside interface into a single, specific global address on the outside interface.
Useful for servers and other hosts that must be directly accessible from the Internet. The external DNS entry for these hosts should properly reflect the translated (global) address.
1:1 Dynamic NAT
The translating device has a defined pool of available global addresses on the outside interface. Local hosts are dynamically assigned an IP address from the pool, as required. When no longer used, the dynamically-assigned IP address is returned to the pool for reuse by another client.
Useful for end-user hosts communicating to the Internet. Because each host gets exclusive use of the dynamically-assigned address, 1:1 dynamic NAT offers the widest application support. The size of the available address pool can be used to limit the number of simultaneous hosts accessing the Internet at a given time.
Internet Edge Security Design Principles
18
Version 1.0
Internet Edge Security Design Principles Security Considerations
Address Translation Method
Description
Guidelines for Use
8:1 Dynamic PAT (address overload)
The translating device has a single, global address in its defined pool of available IP addresses and can translate many local addresses into that single global address. Source host discrimination is accomplished by maintaining the state of the local host’s IP address and TCP/UDP source port, and translating the TCP/UDP source port number to a unique value for an active session.
Also known as address overload, dynamic PAT has the advantage of allowing a single global address to represent a large number of local hosts. This is useful when the range of concurrently active local hosts exceeds the available number of global IP addresses. Although using PAT is considered an effective means of obscuring local hosts from the internet, PAT is subject to application limitations due to its reliance TCP/UDP source port information. A single PAT global address places an upper limit of approximately 64,000 active TCP or UDP sessions, which is significantly lower than the maximum number of concurrent sessions supported by many Cisco firewalls.
8:1 Dynamic PAT to outside IP Similar to dynamic PAT, the translating address (Interface PAT) device uses the IP address of its own outside interface as the global address, which is available for use by local hosts.
Also known as interface PAT, dynamic PAT to an outside address is often used in broadband and other environments where only a single IP address is available for use. In many cases, the translating device’s IP address may be dynamically assigned via DHCP. Although interface PAT is highly versatile, increasing use of this method results in greater security concerns for network administrators, because any host on the network could be masking a number of devices behind it.
Bi-directional NAT
Bidirectional NAT is useful when operating multiple active firewalls in parallel. This method ensures consistency in translation for both the source and destination of a given session. Another effective use of bi-directional NAT is where two hosts can communicate across a defined translation boundary each believing the other is a 'local' host. This method is useful for network management to provide presence for a network management tool that would otherwise be on an isolated network management subnet or out-of-band network.
Translating devices that support bi-directional NAT translate source IP addresses in both directions. The result is that from the local host’s point of view, external destination hosts appear to be local themselves.The actual translation mechanisms used can be a combination of those listed above. However, the use of PAT in the both directions is highly discouraged, because randomizing the TCP/UDP port of reply traffic can lead to highly unpredictable application responses.
Security Considerations In the Internet edge, security generally falls into one of the following categories: •
Element Security
•
Identity Services
•
Common Internet Edge Security Policies
Internet Edge Security Design Principles Version 1.0
19
Internet Edge Security Design Principles Security Considerations
Element Security Due to the location of the Internet edge (on the fringes of the enterprise), its components are subject to potential attacks, both internal and from the Internet. To prevent compromise and reduce the potential for secondary attacks, the elements that make up the Internet edge must be well shielded from such attacks. The best way to approach element security is in three steps: Step 1
Disable all management functions on Internet edge elements, with the exception of the direct console ports.
Step 2
Enable AAA functions, to provide strict controls on device access. If external AAA servers are used, it is highly desirable to protect and authenticate the communication between the Internet edge device and the external AAA server. Verify the operation of AAA functions by enabling their use on the console port.
Step 3
Configure, protect, and enable management functions to the minimum extent necessary. For example, if SSL access is desired, disable unencrypted HTTP. Use encrypted protocols whenever possible. (Only use encrypted protocols when allowing remote administration via the Internet.) Limit management protocols to and from specified management hosts or via specific interfaces.
Identity Services As previously mentioned, the concept of identity is fundamental to network security. In a simplified view, identity at the Internet edge is concerned with two issues: •
Is the internal user or host authorized to access the Internet via the applications/protocols requested?
•
Is an Internet user authorized to access the enterprise hosts via the applications/protocols requested?
Identity at the Internet edge is based on information carried within the IP headers of the packets. The authority to forward the packet is granted based on the following criteria: •
The IP header information must match an explicit rule, permitting the packet to be forwarded.
•
Although not explicitly permitted by a static rule, the IP header information must match a dynamically stored state of an existing (or embryonic) connection.
•
The IP packet to be forwarded was received by the proper interface.
•
The Internet edge device is capable of forwarding the IP packet.
•
The IP packet is properly formed. For example, if a firewall requires the packet to be decrypted prior to forwarding (meaning that received IP packets must be encrypted), then non-encrypted packets and those failing decryption are not forwarded.
It is possible to create mechanisms that provide external authentication of users and hosts. These authentication mechanisms augment stateful packet inspection by establishing the conditions for forwarding packets based on that authentication. For example, proxy-authentication on a PIX firewall (via Telnet, FTP, or HTTP) is used to establish the state for a given session or dynamically modify ACLs to temporarily permit user traffic based upon a successful authentication. In another example, a shared-secret or digital certificate exchange between an external host and a VPN capable device within the Internet edge provides the basis for establishing an IPSec connection between those two hosts.
Internet Edge Security Design Principles
20
Version 1.0
Internet Edge Security Design Principles Security Considerations
Common Internet Edge Security Policies Although enterprises vary significantly in their security policies, the following security policies should be included in virtually all designs: •
Avoid policies that allow external hosts to initiate traffic directly to internal hosts, as this aids in mitigating internal threats via secondary exploitation.
•
Hosts to which Internet users can initiate sessions to should be placed into DMZs, to allow monitoring such traffic in a centralized, controlled environment that is separate from the internal enterprise network.
•
Strictly limit ICMP and UDP traffic that is flowing through to and from the Internet, with DNS being the obvious exception.
•
Prevent encapsulation and port redirection mechanisms between internal networks and the Internet, or strictly define their use.
•
Strictly apply anti-spoofing (RFC 2827 and RFC 1918 filters) mechanisms at the outer Internet connection.
Internet Edge Security Design Principles Version 1.0
21
Internet Edge Security Design Principles Security Considerations
Internet Edge Security Design Principles
22
Version 1.0
INDEX
A
H
AAA
20
HIDS
ACL
4
honey pots
ACLs
11, 12
Host Addressing
6
aggregate bandwidth AH
11, 12
Guidelines
14
2
3
host-based intrusion detection
10
Application Definition ARP spoofing ARP tables
6
3
HSRP
5, 11
HTTP
20
11
18
Asymmetry Concerns Forwarding
17
Translation
17
16
I ICMP
autonomous systems
17
IDS
10 11, 14
IDS alarms
14
IEEE 802.1D loop-detection
B
IKE
Bridge-level filtering mechanisms
9
6, 10
inside interface
18
Internet Key Exchange Internet-level trust
C
Intrusion Detection
Class C network space classless routing
Host-Based
5
11
6
9 11
12
Implementation And Performance Considerations
5
D
Enterprise Interior
13
Perimeter Exterior
13
Implementation and Performance Considerations
DHCP
5
DMZ
12
Network-Based
DoS attacks
11
Variance-Based Capture Systems
DNS request/reply
intrusion detection system
7
IPSec
10
13
12
11
17
IPSec ESP
10
G L global address
18 Customer Order Number:
levels of trust
8
Internet Edge Security Design Principles Version 1.0
23
Index
local address
18
Element Security
20
Identity Services
20
Security Design Requirements
M
Assessment
MAC flooding
1
Enforcement
3
MAC-independent Layer 2 forwarding rules maximum connection rate
Identity
9
Risk
14
1
1
1
Trust
1
Security Policy Definition
N
sensor placement
NAT
NAT Mechanisms
signatures
18
network-based intrusion dDetection NIDS
13
session bandwidth
6
SMTP
11
14
14
10
spanning-tree protocol
11, 13
SSL
O outside interface
1
11
20
stateful inspection firewalls
10
steady-state connection rate
14
18
T P
TCP handshake
policy routing
7
Topology/Trust Model
17
Port-level security mechanism
trusted forwarding
9
8
8
V
R resiliency mechanisms RFC 1918
variance-based capture systems
17
VLAN tagging
17
VRRP
11
9
11
S SAFE
2
Scalability Requirements Bandwidth
14
15
Connection Rate Total Connections
15 16
Security Considerations
19
Common Internet Edge Security Policies
21
Internet Edge Security Design Principles
24
Version 1.0