Implementation Guide NEW NETWORK PLATFORM ARCHITECTURE: WAN. Internet Edge

Transcription

1 Implementation Guide NEW NETWORK PLATFORM ARCHITECTURE: WAN Internet Edge Implementation Guide

2 Table of Contents Introduction... 4 Scope... 4 Target Audience... 4 Key Assumptions... 5 Design Considerations... 5 Routing Considerations... 5 Security Considerations... 6 Failure Consideration... 6 Symmetric and Predictable Routing... 6 Quality of Service... 6 Protocol Operation... 6 Implementation...7 Border Routers... 8 Business Considerations... 8 Achieving Primary Business Consideration Strict Primary and Secondary Topology... 8 Achieving Secondary Business Consideration First Layer of Defense...12 SRX Series Security Devices...15 Business consideration:...15 Zone Definitions in SRX Trust zone configuration:...18 Untrust configuration:...18 Core and DMZ Third Layer of Defense...21 Core...21 DMZ: Caveats Products and Software Summary Appendix A Traffic Behavior Appendix B Configurations...28 MX80-1 Configuration...28 MX80-2 Configuration...36 SRX3400 Cluster Configuration...43 References...63 About Juniper Networks Copyright 2012, Juniper Networks, Inc.

3 List of Figures Figure 1: Test topology simulating Internet edge with dedicated primary (ISP1) and secondary (ISP2)....7 Figure 2: Box highlights the border (ISP interfacing) router connecting with the two ISPs... 8 Figure 3: SRX Series security devices in a cluster connected to MX80 routers and the core using OSPF...15 Figure 4: EX Series virtual instance representing the core of the network and connected to SRX Series cluster using OSPF...21 Figure 5: EX Series virtual instance representing the DMZ and connected using static routes to the SRX Series cluster Figure 6: ISP1 failure causes traffic to flow through ISP Figure 7: MX80-1 failure causes traffic to flow through MX Figure 8: IRB failure on MX80-1 causes traffic to flow through MX Figure 9: Failure of the reth.0 interface causes outbound traffic to use the SRX data plane Figure 10: Active SRX node failure causes all traffic to route through the SRX to ISP List of Tables Table 1. Source of Advertised Routes and ISP Preferences... 5 Table 2. Overview of SRX Series Security Policies Implemented to Control Access, with Associated NAT Policies...16 Table 3: Products with Software Releases, Part Numbers, and Licensing Information Copyright 2012, Juniper Networks, Inc. 3

4 Introduction The Internet edge acts as the enterprise s gateway to the Internet. It provides connectivity to the Internet for data center, campus, and branch offices, and it connects remote workers, customers, and partners to enterprise resources. It can also be used to provide backup connectivity to the WAN for branch offices, in case the primary connection to the enterprise WAN fails. Today s Internet edge must enable access to a variety of applications such as cloud computing solutions, mission critical applications, and bandwidth hungry applications such as video. The Internet edge must also scale seamlessly to support growing application performance and bandwidth needs, while supporting a rich set of routing and security features. This implementation guide will help network designers create a simplified Internet edge solution using Juniper Networks MX Series 3D Universal Edge Routers, SRX Series Secure Services Gateways, and EX Series Ethernet Switches. It details specific design considerations, best practices, and Juniper tools that can be used to build the optimal solution. This guide concludes with a real-world deployment example that illustrates the solution and recommended configurations in detail. Scope This Internet edge implementation guide discusses design concepts and articulates implementation details to help WAN architects and engineers deploy an Internet edge solution. Although the specific implementation will vary, the fundamental building blocks provided here can help accelerate any deployment. The guide has been structured to include the following sections: Target Audience: Describes organizations that will find this document applicable and recommended readers. Key Assumptions: The Internet edge solution described in this document makes several assumptions about deployment details, which are described in this section. Design Considerations: The most important design considerations such as routing, security, resiliency, and quality of service (QoS) that must be addressed in designing an Internet edge deployment are summarized here. This section describes the factors driving the need for these considerations and provides a high-level background applicable to the solution described in this document. Protocol Operation: This section details some of the important protocols that are enabled in this Internet edge design. The specific uses of these protocols are also described here. Implementation: This section details the actual implementation of the Internet edge. It starts with a high-level overview of the topology and business considerations, which is followed by a more detailed explanation of the three parts of the topology (border routers, security devices, and core and DMZ). The detailed explanation of each section highlights the best practices and configuration. Appendices: Appendix A and B provide traffic behavior detail and actual configuration code. Target Audience This guide is well suited for organizations that are: Designing robust, highly scalable, and resilient Internet edge infrastructure Simplifying management by consolidating devices and eliminating single purpose devices in the Internet edge Improving security within the Internet edge solution This guide serves as a reference tool for the following audience: Network engineers Network architects Security managers System test engineers 4 Copyright 2012, Juniper Networks, Inc.

5 Key Assumptions This guide assumes that: The Internet edge topology consists of at least two Internet facing routers. Smaller designs that consist of only one Internet edge router are special cases of the design also described here. In some cases, such smaller designs do not use BGP to peer with Internet service providers (ISPs). The two ISPs do not share the same ISP link or intermediate carriers; this is to ensure that at least one of the carriers is always available. The topology described here is based on several medium-sized campus and data center networks and is assumed to be applicable to similar deployments. The Internet edge deployment is considered separate from the WAN deployment. The BGP local preference values for the ISPs is as listed below: Note: For more scope information, see Caveats section later in this guide. Table 1. Source of Advertised Routes and ISP Preferences Source of Advertised Routes ISP Preference Customer 400 Peer 300 Design Considerations There are many design considerations for an Internet edge deployment. Some of these are highlighted below (please note that an exhaustive discussion on these considerations is beyond the scope of this guide). Routing Considerations Enterprises are driven by trade-offs among many objectives when designing their routing topologies. The most common trade-offs center around the following objectives: Improve resiliency Reduce cost Improve performance Improve utilization Other considerations include predictable performance by ensuring that outbound and inbound traffic flows use the same path. The weighting of these objectives affect how enterprises design their inbound and outbound routing topologies. There are three main routing policy categories: topology-driven, primary-secondary, and load-shared routing. In this solution guide, the design uses a strict primary-secondary topology. These topologies are briefly explained below. Topology-driven routing policy This form of routing policy is optimized to maximize performance and utilization of links. In this routing policy, all routes are accepted without attribute modification. Thus, the BGP path selection algorithm looks at factors such as BGP path length, multiple exit discriminator (MED), interior gateway protocol (IGP) metric, etc., in that order, to determine the best route. When two BGP paths are of the same length, then the MED attribute is evaluated. In case multiple BGP paths are still tied, the nearest exit is chosen and IGP metrics are subsequently evaluated. Primary/secondary routing policy This Internet edge architecture is designed to reduce cost and improve resiliency. Therefore, these networks have designated primary (actively used) and secondary (standby) ISP connections. Such a topology is referred to as strict primary-secondary. Some topologies use the secondary ISP connections for specific routes, also known as loose primary-secondary routing. Such deployments are a trade-off between cost and resiliency versus the additional flexibility gained by sending specific traffic through the secondary links. Load shared routing policy With this policy, the Internet edge architecture is optimized for optimal utilization. It designates a large range of routes to each ISP connection. When designing this routing topology, it is important to pay particular attention to failure scenarios in any ISP link, as such failures will result in all traffic falling back to a surviving ISP link and this may result in performance degradation. A more dynamic load shared routing scheme will involve routing based on a variety of metrics such as bandwidth over the ISP that advertises the most preferable route to the destination. Copyright 2012, Juniper Networks, Inc. 5

6 Other factors that can influence routing topology include: Routing policies such as local preference adopted by the ISPs. Type of ISP (Tier 1, Tier 2, etc.). For instance, a Tier 1 ISP will have a shorter route than a Tier 2 service provider and hence may be preferred by the Internet edge routers. A common question that arises in many Internet edge deployments is when do we use full BGP feeds? The answer depends on the specific use of these routes. One use case of a full BGP feed may be in a load shared routing topology. In such a topology, ISP routers need to dynamically transmit over several possible routes, using a variety of metrics learned from the ISPs. A full BGP feed will allow the Internet edge to choose the best possible route. Security Considerations An Internet edge is the gateway to the Internet and therefore must be designed to protect corporate resources from attacks. To improve protection, Juniper recommends using multiple layers of security such as: Protect against distributed denial of service (DDOS) using firewall filters Guard against malicious traffic using firewalls on the security devices Minimize compromising all infrastructure using separate logical tiers for routing and security Prevent leaking internal traffic using SRX Series zones and non-routable IP addresses Prevent exposure of internal IP addresses and firewall to the external world using Network Address Translation (NAT) This Internet edge deployment incorporates the above described security best practices. The SRX Series security cluster is configured to restrict traffic using various security policies. The devices also have NAT enabled to perform destination NAT and secure NAT (DNAT and SNAT). The Juniper Networks MX80 3D Universal Edge Router complements the security enabled in the SRX Series with firewall filters. In addition to these, the network topology is architected to enhance security in every way possible. Failure Consideration Symmetric and Predictable Routing When designing their Internet edge network topologies, enterprises must not only consider normal operations but must also consider failure conditions and subsequent behavior upon restoration from failure. For instance, when a primary ISP link fails (in primary-secondary routing policy), ingress and egress traffic gets routed through the secondary link. Upon restoration of the ISP link, the ingress and egress traffic must switch to the primary link. The Internet edge deployment highlights this best practice. To understand traffic flow under several failure conditions, please refer to Appendix A. Quality of Service Since traffic is sent to the Internet, QoS is not implemented on egress traffic. For ingress traffic, QoS is deployed inside the enterprise network. For this reason, this Internet edge deployment does not detail specific QoS configurations. The DMZ houses many externally accessible services such as the Domain Name System (DNS), HTTP, and FTP servers, to name a few. Protocol Operation There are several protocols enabled in this Internet edge design, which include: OSPF: The IGP protocol of choice in our implementation is OSPF. OSPF is enabled internally in the topology, divided into two areas: The backbone area, Area 0, which exchanges routes between the core and the SRX Series security devices; and Area 1, which is used to advertise summary routes to the ISP interfacing routers from the security devices. Note that OSPF can exchange routes between areas, and for this reason we rely on security devices to control any traffic exchange between the OSPF areas. Alternatively, we could have used OSPF in the core and IS-IS to advertise routes to ISP interfacing routers from the security devices. EBGP: EBGP is enabled between BGP peers that belong to two different Autonomous Systems (AS). In this validation, we enabled EBGP between the Internet facing routers (MX80) and the ISP routers. The ISPs internally peer using EBGP. IBGP: IBGP is used to peer between BGP peers that belong to the same AS. It uses the loopback address of the routers so that any failure on the links does not impact the protocol. The IBGP peers need not be neighbors. In our implementation, we have enabled IBGP between the MX80 routers purely to illustrate alternate topology. Redundant Ethernet (reth): Link aggregation groups (LAGs) can be established across nodes in a chassis cluster. Link aggregation allows a redundant Ethernet interface (known as a reth interface in CLI commands) to add multiple child interfaces from both nodes and thereby create a redundant Ethernet interface LAG. These are logical interfaces that are assigned to physical links on an SRX Series cluster (redundant nodes) Integrated routing and bridging (IRB): An IRB interface acts as a Layer 3 routing interface for a bridge domain. The IRB interface, in this solution, is used for interfacing the MX Series with the reth interface on the SRX Series. 6 Copyright 2012, Juniper Networks, Inc.

7 Implementation This section describes the Internet edge implementation highlighting different best practices for the topology and the associated configuration. The implementation is divided into the following sections: 1. Border routers 2. Security devices 3. Core and DMZ In each section, we will cover the associated important configuration, the best practices, and any variations to the topologies that are observed in the field. ISP1 AS300 (EX Series virtual instance) ebgp ISP2 AS500 (EX Series virtual instance) ge-0/0/ ge-0/0/ ISP interfacing router MX80-1 AS100 ebgp ge-1/0/0 ae1 ge-1/1/4 ge-1/1/ ge-1/0/3 ibgp ae1 ge-1/1/4 ge-1/1/ ge-1/0/4 ebgp ge-1/0/0 MX80-2 AS100 Default routes advertised ge-1/0/2 Irb Area 1 Irb ge-1/0/5 reth reth Security Devices Default routes advertised ge-0/0/0 ge-0/0/2 ge-8/0/0 ge-8/0/2 SRX SRX ge-0/0/7 ge-8/0/6 ge-0/0/6 ge-8/0/7 Area 0 Static Routes Core & DMZ SRX Series reth EX Series vlan ge-0/0/0 ge-0/0/1 EX4200 Core (virtual instance) SRX Series reth EX Series vlan ge-0/0/4 ge-0/0/5 EX4200 DMZ (virtual instance) /24 Vlan Figure 1: Test topology simulating Internet edge with dedicated primary (ISP1) and secondary (ISP2). Figure 1 shows the Internet edge deployment of a small campus or data center. The ISP interfacing router, MX80-1, is connected to the ISP1, and MX80-2 is connected to ISP2 using EBGP. ISP1 is the primary and ISP2 is the secondary; this implies that all traffic is sent and received using the primary ISP, by default, and when ISP1 becomes unreachable, ISP2 is used. MX80-1 and MX80-2 are connected to each other using IBGP links over an Aggregate Ethernet AE interface (ae1 on each MX Series router). The MX80 routers are connected to the clustered SRX Series devices using OSPF. The MX80-1 and SRX Series cluster interface with irb.0 and reth0.0. The MX80-2 and SRX Series cluster interface with irb.0 and reth1.0. The SRX Series cluster operates in active/standby mode. Figure 1 also shows the EX Series virtual instances representing the DMZ and the core of the network. The DMZ is connected to the SRX Series cluster using static routes, and the core is connected to the SRX Series using OSPF. In order to ensure that we have very predictable performance and simplified debugging, we recommend using symmetric routing. Our topology uses symmetric routing so that outbound and inbound traffic flow using the same path. We will examine this topology below in greater detail. Copyright 2012, Juniper Networks, Inc. 7

8 Border Routers The border (ISP interfacing) routers route Internet traffic to and from the core network and DMZ. Business Considerations The primary business consideration of a strict primary and secondary topology is to minimize cost and improve resiliency. Cost is minimized because the customer incurs most of the cost only for a single dedicated link. Customers can also benefit from improved traffic resiliency, with minimal loss of critical user traffic, by failing over to a standby link. Secondary business consideration is to protect the core of the network from security attacks from the Internet, since the border router acts as the first layer of defense. ISP1 AS300 (EX Series virtual instance) ebgp ISP2 AS500 (EX Series virtual instance) ge-0/0/ ge-0/0/ ISP interfacing router MX80-1 AS100 ebgp ge-1/0/0 ae1 ge-1/1/4 ge-1/1/ ge-1/0/3 ibgp ae1 ge-1/1/4 ge-1/1/ ge-1/0/4 ebgp ge-1/0/0 MX80-2 AS100 Default routes advertised ge-1/0/2 Irb Area 1 Irb ge-1/0/5 reth reth Security Devices Default routes advertised ge-0/0/0 ge-0/0/2 ge-8/0/0 ge-8/0/2 SRX SRX ge-0/0/7 ge-8/0/6 ge-0/0/6 ge-8/0/7 Area 0 Static Routes Core & DMZ SRX Series reth EX Series vlan ge-0/0/0 ge-0/0/1 EX4200 Core (virtual instance) SRX Series reth EX Series vlan ge-0/0/4 ge-0/0/5 EX4200 DMZ (virtual instance) /24 Vlan Figure 2: Box highlights the border (ISP interfacing) router connecting with the two ISPs Before we examine how the two business considerations are accomplished, let s understand the border router topology highlighted by the box in Figure 2. There are two MX80 routers (MX80-1 and MX80-2) that are connected using an IBGP link. The MX80-1 is connected to ISP1 (primary ISP), and MX80-2 is connected ISP2 (secondary ISP) using EBGP. Achieving Primary Business Consideration Strict Primary and Secondary Topology Outbound routing with ISP1 as primary: In this section, we will examine how to achieve strict primary-secondary configuration for outbound traffic from the Internet edge. In the strict primary-secondary topology, MX80-1 and MX80-2 accept default routes ( /0) from ISP1 and ISP2. Accepting default routes from ISPs also ensures that the Internet edge is not used as a transit point for ISP1 to ISP2 traffic. Note that there are other ways of preventing the Internet edge from becoming a transit point for ISP1 to ISP2 traffic, such as using filters to prevent the two MX Series routers from advertising ISP learned routes to each other. 8 Copyright 2012, Juniper Networks, Inc.

9 MX80-1: protocols { bgp { traceoptions { file bgp.log; flag all; group isp1 { type external; import [ localpref-80 default-only ]; authentication-key $9$9c0zt0IylMNdsEcds24DjCtu ; ## SECRET-DATA export ebgp-out; neighbor { local-address ; peer-as 300; : policy-options { : policy-statement default-only { term match-default { route-filter /0 exact; then accept; term reject { then reject; : policy-statement localpref-80 { local-preference 80; : The above configuration snippet (in red) shows the setting for influencing the outbound routing. Setting the local preference value to 80 ensures that ISP1 is the preferred outbound route. MX80-2 will set a lower value for local preference, i.e., 70 (see below for details). Note that for the purpose of this implementation guide, the setting of local preference value to influence outbound routing is not required and is illustrated here purely for purposes of future extension. The local preference setting, as illustrated here, is useful when MX80-1 and MX80-2 advertise ISP routes to each other using the IBGP links. For instance, MX80-2 will send outbound traffic that it receives from the SRX Series to MX80-1 over the IBGP link rather than directly to ISP2 (assuming the destination is reachable over the ISP2 link and all other conditions are favorable). However, in this implementation guide we only accept default routes from both ISPs, and we influence the outbound traffic using IGP metrics (as discussed below). We also enforce strict primary-secondary, with no traffic between the two MX Series routers using the IBGP link. As long as MX80-1 and ISP1 are active, all traffic will be sent to MX80-1. Upon failure of ISP1 traffic, MX80-1 stops advertising the default routes and traffic will be sent to MX80-2. Copyright 2012, Juniper Networks, Inc. 9

10 MX80-2: protocols { bgp { group isp2 { type external; import [ localpref-70 default-only ]; authentication-key $9$eshMLNs2aikPdbkP5Q9CKM8 ; ## SECRET-DATA export ebgp-out; bfd-liveness-detection { minimum-interval 300; minimum-receive-interval 300; neighbor { local-address ; peer-as 500; : The outbound routing configuration also needs to influence the outbound traffic from SRX Series to MX Series to prefer the link to MX80-1, since ISP1 is the preferred primary. To ensure that this occurs, we set the IGP metric to 20 on the irb.0 interface between MX80-2 and the SRX Series cluster. The IGP metric on the IRB interface between MX80-1 and the SRX Series cluster has the default value of 0. Therefore, as long as the link between the Juniper Networks SRX3400 Services Gateway (SRX3400-1) and MX80-1 is active, the SRX will send traffic to MX80-1. policy-statement default-to-ospf { term accept { protocol bgp; route-filter /0 exact; state active; metric 20; accept; term reject { then reject; protocols { : : 10 Copyright 2012, Juniper Networks, Inc.

11 ospf { export default-to-ospf; import ospf-reject-default; area { interface irb.0 { bfd-liveness-detection { minimum-interval 300; full-neighbors-only; interface lo0.0; Inbound routing with ISP1 as primary: We have seen the configuration for outbound routing in the MX80 routers using ISP1 as the dedicated primary. Next, we will examine how to influence the inbound traffic to use ISP1 as the dedicated primary. As previously explained, in routing considerations the actual behavior is subject to the ISP s own unique routing policies and what customer settings are accepted by the ISP. MX80-2: policy-options { : policy-statement ebgp-out { term term1 { route-filter /24 exact; local-preference 200; as-path-prepend ; accept; term reject { then reject; : The code snippet above shows the local preference and as-path-prepend values that are necessary to ensure that ISP2 is the secondary ISP for inbound routes. The local preference is set to a value lower than what the ISP2 will assign to customer advertised routes, causing ISP2 to prefer routes advertised by its peer. Further, the AS-PATH prepend ensures that ISP2 will favor peer routes because MX80-2 advertised routes are longer than that advertised by the ISP peers. The AS-PATH length advertisement is necessary to ensure that ISP2 will continue to be the secondary ISP for inbound routes even after recovery from any failures in the ISP network. The ISP interfacing routers also play a critical role as the first layer of defense in a layered defense approach to protect the rest of the enterprise network from the Internet. Copyright 2012, Juniper Networks, Inc. 11

12 Achieving Secondary Business Consideration First Layer of Defense Securing and protecting against denial of service (DoS) attacks: To prevent attacks against the Internet edge network, MX Series routers are configured with re-protect firewall filters. The filter is used to prevent small packet attacks, fragments, and floods of traffic from specific protocols such as ICMP, BGP, OSPF, SNMP, UDP, and TCP. The filter is applied to the loopback interface of the MX Series router, and it applies to traffic destined for the router and not transit traffic. Thus, to protect against IP fragment attacks used to circumvent L4-L7 filters transiting these routers, other filters must be set up. These are shown below: MX80-1: interfaces { : lo0 { filter { input re-protect; f re-protect filter applied to loopback interface address /32; : firewall { filter re-protect { interface-specific; term small-packets { packet-length 0-24; count small-packet-attack; log; discard; term fragment-packets { fragment-offset-except 0; protocol [ icmp igmp pim tcp ]; count frag-attack; log; discard; f Prevent Small Packet Attack f Prevent Fragment DOS (non-initial) term icmp-in { source-prefix-list { f Accept from white list.police incoming ICMP 12 Copyright 2012, Juniper Networks, Inc.

13 trusted-networks; protocol icmp; policer limit-2m; count icmp-in; accept; term bgp-in { source-prefix-list { trusted-bgp-peer; protocol tcp; port bgp; policer limit-2m; count bgp-in; accept; term ospf-in { source-prefix-list { trusted-ospf-neighbor; protocol ospf; policer limit-2m; count ospf-in; accept; term snmp-in { source-prefix-list { trusted-networks; protocol udp; port snmp; policer limit-2m; count snmp-in; accept; term access-in {f Control access from trusted networks source-prefix-list { trusted-networks; Copyright 2012, Juniper Networks, Inc. 13

14 : : source-prefix-list { trusted-networks; protocol tcp; port [ ssh ftp ftp-data ]; count access-in; accept; term udp-services { source-prefix-list { trusted-networks; protocol udp; source-port ; policer limit-2m; count udp-in; accept; : : term deny-all { count illegal-traffic-in; log; discard; policer limit-2m { f Policer definition to limit traffic to 2Mb with 500K burst if-exceeding { bandwidth-limit 2m; burst-size-limit 500k; then discard; 14 Copyright 2012, Juniper Networks, Inc.

15 SRX Series Security Devices Business consideration: The primary requirement of security devices is to protect the corporate network from attacks from the Internet. ISP1 AS300 (EX Series virtual instance) ebgp ISP2 AS500 (EX Series virtual instance) ge-0/0/ ge-0/0/ ISP interfacing router MX80-1 AS100 ebgp ge-1/0/0 ae1 ge-1/1/4 ge-1/1/ ge-1/0/3 ibgp ae1 ge-1/1/4 ge-1/1/ ge-1/0/4 ebgp ge-1/0/0 MX80-2 AS100 Default routes advertised ge-1/0/2 Irb Area 1 Irb ge-1/0/5 reth reth Security Devices Default routes advertised ge-0/0/0 ge-0/0/2 ge-8/0/0 ge-8/0/2 SRX SRX ge-0/0/7 ge-8/0/6 ge-0/0/6 ge-8/0/7 Area 0 Static Routes Core & DMZ SRX Series reth EX Series vlan ge-0/0/0 ge-0/0/1 EX4200 Core (virtual instance) SRX Series reth EX Series vlan ge-0/0/4 ge-0/0/5 EX4200 DMZ (virtual instance) /24 Vlan Figure 3: SRX Series security devices in a cluster connected to MX80 routers and the core using OSPF Before we examine how the business requirement is accomplished, let s understand the network setup for the security devices. The SRX Series devices (highlighted by the box in Figure 3) are connected together in an active/standby mode cluster configuration, which enables device-level resiliency. This guide does not use the SRX Series in an active/active mode. The SRX Series is connected to the MX Series using reth and is an area border router (ABR) that advertises routes (using Area 1) to MX Series routers. The backbone area (Area 0) is between the core and the SRX Series cluster. The core area router (or routers) interfacing with the SRX Series is expected to summarize routes before advertising them to SRX Series Services Gateways. The SRX3400 cluster is connected to the EX Series virtual instance, simulating the core using reth2.0. The core of the network is denoted by /24 subnet. The SRX Series cluster is connected to an EX Series virtual instance that simulates the DMZ, using reth3.0. The DMZ is denoted by the /24 subnet. OSPF Area 0 is between the SRX Series cluster and the EX Series core virtual instance. The concerns about leaking internal core routes to Area 1 are addressed using strict security policies that control access between the zones. The DMZ is linked to SRX Series gateways using static routes (most DMZs are small enough to do this). Further, static routes are an additional layer of protection that are used to avoid leaking routes between the different zones. Copyright 2012, Juniper Networks, Inc. 15

16 Achieving Business Consideration: Securing Traffic to and from the Core and DMZ Second Layer of Defense The primary function of the SRX Series security device is to control access to the core and DMZ. The SRX Series also performs source and destination NAT. The NAT functionality is used to not only translate internal private IP addresses but also to hide the internal network addresses from attacks. Thus, SRX Series gateways add multiple additional layers of defense. Table 2. Overview of SRX Series Security Policies Implemented to Control Access, with Associated NAT Policies Source ISP Preference NAT Core (trust zone) Internet (Area 1, a.k.a. untrust zone) Source NAT Internet (Area 1, a.k.a. untrust zone) DMZ Destination NAT Core (trust zone) DMZ None Core (trust zone) Core (trust zone) None Table 2 shows the different firewall policies that are set up to control access between the different zones. The table also indicates the different NAT policies that hide internal IP addresses, providing an additional layer of security. It should be noted that the NAT policies are not set up for access between the core and DMZ because NAT-level security is not necessary for traffic within the network. We will examine the configuration relevant to Table 2 in detail below. SRX3400: policies { from-zone trust to-zone untrust { policy outbound-access { match { source-address trust; f Traffic is from trust zone destination-address any; f Traffic is destined to any address application outbound-apps; f Access is from specified apps permit; f Traffic is Permitted log { session-init; session-close; count; from-zone untrust to-zone dmz { policy untrust-to-dmz { match { source-address any; f Traffic is from any address(internet) destination-address /32;f Traffic destined to DMZ services application dmz-services; ;f Permit only specific DMZ applications permit; f Traffic is Permitted, if all conditions satisfied log { session-close; count; 16 Copyright 2012, Juniper Networks, Inc.

17 from-zone trust to-zone dmz { policy trust-to-dmz { match { source-address trust; f Traffic is from core destination-address /32; f Traffic destined to DMZ application [ junos-ping junos-http junos-ftp ]; permit; log { session-close; count; from-zone trust to-zone trust { policy trust-to-trust { match { source-address any;f Traffic from any source address in trust zone destination-address any;f Traffic to any destn. address in trust zone application any; permit { application-services { idp; : : : applications { application-set outbound-apps { application junos-http; application junos-https; application junos-ping; application-set dmz-services { application junos-ping; application junos-ssh; application junos-ftp; application junos-https; The above configuration represents the access restrictions shown in Table 2. The traffic is permitted as long as it is from the designated source to the specific destination and is from one of the permitted applications. To illustrate this point, see the policy outbound-access under from-zone trust to-zone untrust. Here, application traffic (HTTP. HTTPS, and ICMP echo) from the core to any Internet destination is permitted. Similar reasoning holds for other security policies. Note that the DMZ applications that can be accessed can also be controlled by adding or deleting the applications specified under dmz-services in the applications configuration. All other traffic is blocked. Copyright 2012, Juniper Networks, Inc. 17

18 Zone Definitions in SRX3400 We have seen the different restrictions imposed on the inter-zone traffic and the associated configuration. Now let s examine the configuration of the trust, untrust, and DMZ zones. Zone configuration, in this topology, includes the following items: Addresses that are included in the zone Interfaces that are part of the trust zone Services and protocols supported on the interface in the zone Trust zone configuration: zones { security-zone trust { address-book { address trust /24; interfaces { reth2.0 { host-inbound-traffic { system-services { ping; protocols { ospf; bfd; Untrust configuration: security-zone untrust { screen untrust-screen; interfaces { reth0.0 { host-inbound-traffic { system-services { ping; protocols { ospf; bfd; reth1.0 { host-inbound-traffic { system-services { ping; protocols { ospf; bfd; 18 Copyright 2012, Juniper Networks, Inc.

19 The untrust zone includes all traffic inbound from reth0.0 and reth1.0. These two reth interfaces are on the OSPF Area 1 and enable the OSPF and BFD protocol packets in the untrust zone. The untrust zone configuration also uses the untrust-screen to enable intrusion detection service (IDS), as shown in the security configuration below. Here, DoS attack prevention is enabled (ICMP, IP, and TCP). security { : : screen { ids-option untrust-screen { icmp { ping-death; ip { source-route-option; tear-drop; tcp { syn-flood { alarm-threshold 1024; attack-threshold 200; source-threshold 1024; destination-threshold 2048; timeout 20; : : DMZ zone configuration: security-zone dmz { address-book { address / /24; address / /32; address / /32; address / /32; interfaces { reth3.0 { host-inbound-traffic { system-services { ping; The configuration for security-zone DMZ shows several addresses in the address book. The address book for a security zone contains the IP address or domain names of hosts and subnets whose traffic is either allowed, blocked, encrypted, or user authenticated. For our purpose, the addresses are those for which traffic is allowed. The /24 is the subnet address for NAT. The address is the specific NAT address for hiding the DMZ address. The /32 is not currently used by this topology. The reth3.0 interface is connected to the EX Series virtual instance simulating the DMZ, and it supports the systemservices of ICMP echo. Copyright 2012, Juniper Networks, Inc. 19

20 NAT definitions: Let s examine the configuration and usage of NAT in more detail. Security { : : nat { traceoptions { file nat.log; flag all; source { pool outbound-nat {f NAT address pool range for ISP traffic address { /32 to /32; rule-set source-nat { from zone trust; to zone untrust; rule trust-nat { match {f Applies SNAT on traffic leaving core source-address /24; source-nat { pool { outbound-nat; destination { pool dmz-server1 {f NAT address pool range for ISP traffic address /32; rule-set dmz-server1-rule { from zone untrust; rule one-to-one { match {f Applies DNAT on DMZ bound traffic from internet destination-address /32; destination-nat pool dmz-server1; The Internet edge implementation uses Source NAT (SNAT) to mask internal IP addresses from the core of the network. The NAT addresses here are taken from an NAT pool of 50 specified addresses. The SNAT is applied to all traffic from the core (trust zone) to the Internet (untrust zone). All traffic destined for DMZ from the Internet (untrust zone) will have a destination address of Note: The address is assumed to be a well-known address in the Internet. Therefore all DMZ bound traffic will trigger a match with the destination address and translation to the address, which is the dmz-server1 DNAT pool. Note that we advertised the /24 subnet to the ISP in the MX80 routing configuration. 20 Copyright 2012, Juniper Networks, Inc.