JNCIS-SEC-P1_2012-12-19

1194 North Mathilda AvenueSunnyvale, CA 94089USA408-745-2000www.juniper.net

Worldwide Education ServicesWorldwide Education Services

JNCIS-SEC Study GuidePart 1

This document is produced by Juniper Networks, Inc.

This document or any part thereof may not be reproduced or transmitted in any form under penalty of law, without the prior written permission of Juniper Networks Education Services.

Juniper Networks, Junos, Steel-Belted Radius, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United States and other countries. The Juniper Networks Logo, the Junos logo, and JunosE are trademarks of Juniper Networks, Inc. All other trademarks, service marks, registered trademarks, or registered service marks are the property of their respective owners.

Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice.

YEAR 2000 NOTICE

Juniper Networks hardware and software products do not suffer from Year 2000 problems and hence are Year 2000 compliant. The Junos operating system has no known time-related limitations through the year 2038. However, the NTP application is known to have some difficulty in the year 2036.

SOFTWARE LICENSE

The terms and conditions for using Juniper Networks software are described in the software license provided with the software, or to the extent applicable, in an agreement executed between you and Juniper Networks, or Juniper Networks agent. By using Juniper Networks software, you indicate that you understand and agree to be bound by its license terms and conditions. Generally speaking, the software license restricts the manner in which you are permitted to use the Juniper Networks software, may contain prohibitions against certain uses, and may state conditions under which the license is automatically terminated. You should consult the software license for further details.

JNCIS-SEC Study GuidePart 1.

Copyright 2012, Juniper Networks, Inc.

All rights reserved. Printed in USA.

The information in this document is current as of the date listed above.

The information in this document has been carefully verified and is believed to be accurate for software Release 12.1R1.9. Juniper Networks assumes no responsibilities for any inaccuracies that may appear in this document. In no event will Juniper Networks be liable for direct, indirect, special, exemplary, incidental or consequential damages resulting from any defect or omission in this document, even if advised of the possibility of such damages.

Contents iii

Contents

Chapter 1: Introduction to Junos Security Platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1-1

Chapter 2: Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-1

Chapter 3: Security Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-1

Chapter 4: Firewall User Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-1

Chapter 5: SCREEN Options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .5-1

Chapter 6: Network Address Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6-1

Chapter 7: IPsec VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7-1

Chapter 8: Introduction to Intrusion Detection and Prevention . . . . . . . . . . . . . . . . . . . .8-1

Chapter 9: High Availability Clustering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9-1

Chapter 10: High Availability Clustering Implementation . . . . . . . . . . . . . . . . . . . . . . . . . .10-1

. Overview iv

Overview

Welcome to the JNCIS-SEC Study GuidePart 1. The purpose of this guide is to help you prepare for your JN0-332 exam and achieve your JNCIS-SEC credential. The contents of this document are based on the Junos for Security Platforms course. This study guide covers the configuration, operation, and implementation of SRX Series Services Gateways in a typical network environment. Key topics within this study guide include security technologies such as security zones, security policies, intrusion detection and prevention (IDP), Network Address Translation (NAT), and high availability clusters, as well as details pertaining to basic implementation, configuration, and management.

Agenda

Chapter 1: Introduction to Junos Security Platforms

Chapter 2: Zones

Chapter 3: Security Policies

Chapter 4: Firewall User Authentication

Chapter 5: SCREEN Options

Chapter 6: Network Address Translation

Chapter 7: IPsec VPNs

Chapter 8: Introduction to Intrusion Detection and Prevention

Chapter 9: High Availability Clustering

Chapter 10: High Availability Clustering Implementation

www.juniper.net Document Conventions v

Document Conventions

CLI and GUI TextFrequently throughout this guide, we refer to text that appears in a command-line interface (CLI) or a graphical user interface (GUI). To make the language of these documents easier to read, we distinguish GUI and CLI text from chapter text according to the following table.

Input Text Versus Output TextYou will also frequently see cases where you must enter input text yourself. Often these instances will be shown in the context of where you must enter them. We use bold style to distinguish text that is input versus text that is simply displayed.

Defined and Undefined Syntax VariablesFinally, this guide distinguishes between regular text and syntax variables, and it also distinguishes between syntax variables where the value is already assigned (defined variables) and syntax variables where you must assign the value (undefined variables). Note that these styles can be combined with the input style as well.

Style Description Usage Example

Franklin Gothic Normal text. Most of what you read in the Lab Guide and Study Guide.

Courier New Console text:

Screen captures

Noncommand-related syntax

GUI text elements:

Menu names

Text field entry

commit complete

Exiting configuration mode

Select File > Open, and then click Configuration.conf in the Filename text box.


Normal CLI

Normal GUI

No distinguishing variant. Physical interface:fxp0, Enabled

View configuration history by clicking Configuration > History.

CLI Input

GUI Input

Text that you must enter. lab@San_Jose> show route

Select File > Save, and type config.ini in the Filename field.


CLI Variable

GUI Variable

Text where variable value is already assigned.

policy my-peers

Click my-peers in the dialog.

CLI Undefined

GUI Undefined

Text where the variables value is the users discretion and text where the variables value as shown in the lab guide might differ from the value the user must input.

Type set policy policy-name.

ping 10.0.x.y

Select File > Save, and type filename in the Filename field.

vi Additional Information www.juniper.net

Additional Information

Education Services OfferingsYou can obtain information on the latest Education Services offerings, course dates, and class locations from the World Wide Web by pointing your Web browser to: http://www.juniper.net/training/education/.

About This PublicationThe JNCIS-SEC Study GuidePart 1 was developed and tested using software Release 12.1R1.9. Previous and later versions of software might behave differently so you should always consult the documentation and release notes for the version of code you are running before reporting errors.

This document is written and maintained by the Juniper Networks Education Services development team. Please send questions and suggestions for improvement to [email protected].

Technical PublicationsYou can print technical manuals and release notes directly from the Internet in a variety of formats:

Go to http://www.juniper.net/techpubs/.

Locate the specific software or hardware release and title you need, and choose the format in which you want to view or print the document.

Documentation sets and CDs are available through your local Juniper Networks sales office or account representative.

Juniper Networks SupportFor technical support, contact Juniper Networks at http://www.juniper.net/customers/support/, or at 1-888-314-JTAC (within the United States) or 408-745-2121 (from outside the United States).

2012 Juniper Networks, Inc. All rights reserved. Introduction to Junos Security Chapter 11


Chapter 1: Introduction to Junos Security

This Chapter Discusses: Traditional routing and security implementations;

Current trends in internetworking;

The Junos operating system for the SRX Series; and

Logical packet flow through SRX Series devices.

Built to Forward Packets

The primary responsibility of a router is to forward packets using Layer 3 IP addresses found in an IP packet header. To forward packets, the router must have a path determination mechanism. This mechanism could be statically assigned routes, routing protocols, or policy-based routing.

Packet Processing Is StatelessTraditionally, routers process packets in a stateless fashion. Routers do not keep track of bidirectional sessions; they forward each packet individually based on the packet header.

Separate Broadcast Domains and Provide WAN ConnectivityRouters were originally used to separate broadcast domains. With the introduction of advanced switching technologies and the birth of virtual LAN (VLAN) standards, broadcast domains can also be separated using switches. That capability, however, does not address inter-VLAN connectivity, which still necessitates the use of routers for forwarding traffic between VLANs. Furthermore, routers provide WAN connectivity at the network edge.


Chapter 12 Introduction to Junos Security 2012 Juniper Networks, Inc. All rights reserved.

Layer 3 Packet Forwarding

The objective of the graphic is to illustrate transmission of packets from Host-A to Host-B. Routers perform Layer 3 packet forwarding using routing table entries. Routers build routing tables based on the results of dynamic routing protocols (for example, RIP, OSPF, IS-IS, and BGP), statically entered routes, or both of these methods. Note that routers forward packets based on the longest prefix match. For example, in the graphic, Router-A selects interface ge-0/0/2 to send traffic to destination 10.3.3.10 because 10.3.3.10/32 is a longer prefix match than 10.3.3.0/24. If entry 10.3.3.10/32 does not exist in the routing table, the router selects interface ge-0/0/0 as the next hop for the same packet flow.

Layer 3 Packet ForwardingA traditional router is a promiscuous device that performs stateless packet processing. It is promiscuous because once it is configured, it immediately forwards all traffic by default (provided, of course, that some combination of static and dynamic routing is configured). Typically, a router operates only at Layer 3 and does not recognize any security threats in higher-layer protocols. Furthermore, a traditional router operates per packet, which adds to its fundamentally insecure nature, because it cannot detect malformed sessions. The network and the router itself are immediately vulnerable to all security threats.

Typical Treatment of SecurityOther than implementing standard access control using IP header information, most routers are not equipped to secure a network. Traditionally, a full security solution involves adding a separate firewall device.

Typical Router Positioning

Enterprise customer premise applications are served by the J Series family of service routers and, in the case of larger enterprises, M Series routers. Enterprise data center applications can also be served by M Series routers. Internet service



provider (ISP) networks can be served by M Series, MX Series, or T Series routers. J Series, M Series, MX Series and T Series routers support the rich routing and class-of-service (CoS) features needed by networks, and maintain value, stability, and predictably high performance.

Adding Security to the NetworkStandalone routers do not provide adequate security to enterprise networks and data centers. As networks expand, network applications continue to diversify and expand, and as new methods of remote communications such as telecommuting increase, the need for added security becomes apparent. Typically, a standalone firewall is added to the network, increasing costs and maintenance.

Requirements for Firewall DevicesA firewall device must be capable of the following:

Stateful packet processing based on contents of IP and higher-level packet information, which includes TCP/UDP and the Application Layer;

Network Address Translation (NAT) and Port Address Translation (PAT), achieving private-to-public translations and vice versa; and

Establishing virtual private networks (VPNs) compounded with authentication and encryption.

Additional ServicesThe growth in network security has resulted in additional services provided by standalone firewalls such as Secure Sockets Layer (SSL) network access, intrusion detection and prevention (IDP), application-level gateway (ALG) processing, and more.

Firewall: Stateful Packet ProcessingBecause the main job of a firewall is to protect networks and devices, fundamental firewall intelligence consists of the ability to make packet processing decisions based on IP packet header information, including its upper layers.

Stateful packet processing involves the creation of a unidirectional flow, which consists of six elements of informationsource IP address, destination IP address, source port number, destination port number, protocol number, and a session token. The session token is derived from a combination of a routing instance and a zone. The outgoing flow initiates a session table entry and the expected return flow for that packet. Both outgoing and incoming flows comprise the session and are entered into the



session table. The session table enables bidirectional communication without any additional configurational steps for return traffic.

Firewall: NAT and PAT

When a security device resides at the edge of a network, it must be able to replace private, nonroutable addresses with public addresses before traffic is sent to the public network. Translation can consist of replacing the IP address, port numbers, or both, depending on the configuration. Note that NAT can be used on both source and destination addresses, and PAT can be used on both source and destination ports.

Firewall: Virtual Private Networks

You can use a firewall to build VPNs using the public network as an access medium between two private sites. As such, the firewall must be able to perform the following:

Encapsulate the original traffic in a packet that can be transported over the public network;

Encrypt the original packet so that it cannot be easily decoded if it is intercepted on the public network; and

Authenticate the originating device as a member of the VPNnot a random device operating on the public network.



Firewall Positioning

The graphic illustrates a typical enterprise deployment of firewall devices. Small office and home offices or retail storefronts use branch firewall devices to provide secured access to the Internet, as well as an IP Security (IPsec) VPN tunnel back to a central site.

The enterprise firewall device at the central site provides VPN termination and firewall protection between internal zones as well as from the Internet, and it might also provide other security services such as IDP, Web filtering, and antispam services.

Junos Security Platforms Versus a Traditional Router

The traditional router and a Junos security platform have completely different starting points with respect to security and traffic flow.



The traditional router begins by forwarding all traffic. Thus, the network is vulnerable to all threats. You add security policies to reduce vulnerability until you reach the ideal configuration. Because the traditional router begins as completely promiscuous and it requires that you add security policies, a greater chance exists that the network will remain vulnerable to some threats.

An SRX Series Services Gateway running the Junos OS begins by forwarding no traffic. The network is secure but not functional. You add rules to allow traffic until you reach the ideal configuration. Because a Junos security platform begins by forwarding no traffic and because you must add rules, a greater likelihood exists that the network will restrict undesirable traffic.

The Junos Security Platforms Merge Routing and Security

The new features of the Junos security platforms bring new core security capabilities to the Junos OS. Because the forwarding algorithm is session-based, security features are tightly integrated into the forwarding plane, improving security performance. Session-based forwarding and stateful firewall features derive from Juniper Networks ScreenOS software.

The Junos security platforms incorporate ALG functionality, IPsec VPNs, and screen protection in a flowd module within the Junos OS. Juniper Networks world-class IDP technology is also fully integrated into the Junos security platforms. We discuss these features later in this material.

Junos ElementsSRX Series Services Gateways use the Junos OS as their base operating system. As such, these devices deploy all the industry-proven processes of the Junos OS, such as the routing process, management process, device control process, and others. Another building element of the Junos security platforms is session-based forwarding, thereby resulting in a strong suite of security features.

Packet-Based Junos Forwarding The Junos OSs basic control plane, routing protocol process implementation, per-packet stateless filters, policers, and CoS functions are all packet based. Furthermore, other nonsecurity-related features, such as all interface encapsulations and de-encapsulations, use the industry-proven Junos OS. You can configure SRX Series Services Gateways using either the CLI or J-Webthe Junos OS-based graphical user interface (GUI).

Session-Based ForwardingThe Junos security platforms leverage ScreenOS softwares security features as well as its flow-based nature. The first packet entering the device follows a series of path and policy determination schemes. The Junos OS caches the session information, the creation of which is triggered by the first packet of the flow. The cached session is used by subsequent packets of that same flow and the reverse flow of that session. Using the flow module, which is integrated into the forwarding path, the hardware performs data-plane packet forwarding. Because the Junos security platforms are security-based, all IPv4 packets entering the services gateway on an interface associate with an incoming zone. Likewise, all IPv4 packets exiting the device on an interface associate with an outgoing zone. If a route changes, as long as the interface remains in the same zone, the session remains intact. It only needs a new session if resulting interfaces are in different zones.The Junos security platforms add a bundle of high-security features to the regular features of a router, including stateful firewall, VPNs, NAT, ALGs, and IDP.



Control PlaneThe control plane on a Junos security platform is implemented using the Routing Engine. The control plane consists of the Junos kernel, various processes, chassis management, user interface, routing protocols and some security features. Many of the security features resemble ScreenOS features, including the network security process, the VPN process, the authentication process, and Dynamic Host Configuration Protocol (DHCP). For its control plane, the Junos security platform deploys these features along with well-known, traditional Junos features.

Data PlaneThe data plane on Junos security platforms, implemented on IOCs, NPCs, and SPCs for high-end devices and on CPU cores and PIMs for branch devices, consists of Junos OS packet-handling modules compounded with a flow engine and session management like that of the ScreenOS software. Intelligent packet processing ensures that one single thread exists for packet flow processing associated with a single flow. Real-time processes enable the Junos OS to perform session-based packet forwarding.

Logical Packet Flow Details

Security platforms running the Junos OS handle an incoming packet as follows:

1. The software applies stateless policing filters and CoS classification to the packet at the ingress.

2. If the packet does not drop, the software performs a session lookup to determine whether the packet belongs to an existing session. The Junos OS matches on six elements of traffic information for this determinationsource IP address, destination IP address, source port number, destination port number, protocol number, and a session token.

3. If the packet does not match an existing session, the software creates a new session for it. This process is referred to as the first-packet path. If the packet matches a session, the software performs fast-path processing.

The first packet of a flow is subject to first-packet-path processing. The software takes the following steps during first-packet-path processing:

1. Based on the protocol used and its session layer (TCP or UDP), the software starts a session timer. For TCP sessions, the default timeout is 30 minutes. For UDP sessions, the default timeout is 1 minute. These values are the defaults, and you can change them.



2. The software applies firewall SCREEN options.

3. If destination NAT is used, the software performs address allocation.

4. Next, the software performs the route lookup. If a route exists for the destination prefix, the software takes the next step. Otherwise, it drops the packet.

5. The software determines the packets incoming zone by the interface through which it arrives. The software also determines the packets outgoing zone by the forwarding lookup.

6. Based on incoming and outgoing zones, the corresponding security policy is determined and a security policy lookup takes place. The software checks the packet against defined policies to determine how to treat the packet.

7. If source NAT is used, the software performs address allocation.

8. The software sets up the ALG service vector.

9. The software creates and installs the session. Furthermore, the software caches the decisions made for the first packet into a flow table, which subsequent packets of that flow use.

10. The packet now enters the fast-path processing.

Subsequent packets of a flow are all subject to fast-path processing. The software takes the following steps during fast-path processing:

1. The software applies firewall SCREEN options.

2. The software performs TCP checks.

3. The software applies NAT.

4. The software applies an ALG.

5. The software applies packet forwarding features, which include the following:

a. Stateless packet filters;

b. Traffic shaping by packet; and

c. Packet encapsulation and transmission.

Session-Based Mode ForwardingThe inset briefly reviews a couple of things about the two types of data-plane forwarding on an SRX device: session-based and packet-based forwarding. Both types of forwarding require packets to pass through any configured inbound and outbound firewall filters and class-of-service (CoS) elements (policers and shapers). Beyond that, the two types of forwarding are very different. Regarding session-based forwarding, each packet is examined to determine whether or not it is part of an existing session. If the incoming packet is the first packet of a session or flow, then the flow module keeps track of source and destination IP addresses, source and destination ports, and the IP protocol used in a session state table.

The session information is cached so that subsequent packets for the same flow, as well as packets for the return flow for the session, are allowed through the device. This latter operation is referred to as fast-path processing.

Packet-Based Mode ForwardingWith packet-based forwarding, each packet is individually inspected, every time. If the incoming packet is not dropped by either a configured policer or filter, then the SRX device performs a route lookup and forwards the packet. An SRX device forwards these packets without keeping track of any session state information. No packet requires any information from any other packet. None of the packets have to be examined to determine whether they are part of a session.



Packet-Based Mode Uses Stateless Security

Packet-based forwarding is stateless forwarding. Packet-based forwarding is performed on a packet-by-packet basis without regard to flow or state information. With packet-based forwarding, the Junos OS does not maintain information about the session.

With packet-based forwarding, the Junos OS allows for limited security in the form of stateless firewall filters, sometimes referred to as access control lists (ACLs). The actions for a filter can be discard, reject, log, or count. So, without any session table information to keep track of any sessions, the filters must be applied for both initial and return traffic.

The diagram shows the packet flow for packet-based mode. Packets coming into the SRX device pass through a policer and an inbound firewall filter (if configured). Next, a route lookup is performed to determine the egress interface for the packet. Notice that the packet does not participate with any of the services on the flow module. It bypasses the security services of the SRX device. Once the egress interface for the packet is determined, an outbound firewall filter can be applied, as well as a traffic shaper. Otherwise, the packet is forwarded out to the next-hop interface.

Junos Selective Packet-Mode Forwarding

Branch SRX devices can use both packet-based and session-based forwarding simultaneously. This functionality is called Junos Selective Stateless Packet-Based Services.

A stateless firewall filter on the inbound interface can specify any matching traffic to be processed as packet-based, in which case the traffic will bypass the services and security features within the flow module. Otherwise, the rest of the traffic will be processed within the flow module as session-based traffic.

AdvantagesOne advantage of having certain traffic be packet-based is scalability. Packet-based traffic has less overhead than session-based traffic, because it does not pass through the various security and services inspections of the flow module. For this reason, packet-based mode has a higher scalability than session-based mode, and any packet-based mode traffic will



reduce the processing load within the flow module. The ability to provide packet-based services such as MPLS in conjunction with session-based security represents another advantage of selective packet-mode filtering.

Selective Packet-Based ConfigurationThe command-line interface (CLI) commands displayed in the inset demonstrate a firewall filter used for selective packet-based services. The example illustrates a stateless firewall filter named selective. Term 1 shows that any traffic matching a source IP address of 10.10.10.1 will have a matching action of then packet-mode. With the packet-mode action, the Junos OS forwards matching packets without applying stateful security services (assuming there is a forwarding table entry). The example shows the firewall filter applied under the logical unit of the ingress interface. The Junos OS can also apply filters to virtual LAN (VLAN) interfaces on the branch SRX series.

Selective Forwarding ExampleThe inset illustrates a practical example, where a branch SRX device participates in an MPLS network, and also provides session-based security services. The example uses two different routing instances to forward the two modes of traffic, packet-based and session-based. The Packet-VRF routing instance provides MPLS and virtual private network (VPN) services by connecting to an MPLS network and terminating the Layer 3 VPN connection. The main instance has an interface configured that is connected to the MPLS core network. BGP peering is established, and LDP is used as the MPLS protocol, which then uses the BGP signaling to establish its path to the remote provider edge (PE) device.

The Junos OS uses the Session-VRF to provide stateful inspection and session-based security. The Junos OS forwards traffic between the two routing instances over logical tunnel interfaces. Because the routing tables of the two routing instances are separated, the Junos OS shares routing information between them by means of either a static or dynamic routing protocol. All traffic going in or out of the Session-VRF participates in security zones, and must pass through security policies to be allowed through.

The configuration requires a selective packet-based firewall filter to place the traffic into packet-mode. The operator configures the filter inbound on the logical tunnel (lt-0/0/0) unit 1 interface. The Junos OS applies the filter as traffic ingresses the Packet-VRF.

The Junos MPLS and VPNs (JMV) course contains more detailed information on VPNs.



Session MaintenanceWhen a packet enters the system and does not match any existing sessions, the Junos OS creates a new session based on routing and security policy information. Once this new session is created, the software puts it into a session hash table for further packet matching and processing. Depending on the protocol and service (TCP or UDP), the session is programmed with a default timeout. The default TCP timeout is 30 minutes and the UDP default timeout is 1 minute.

Session CleanupIf no traffic matches the session during the service timeout, the Junos OS ages out the session and frees it to a common resource pool for a later reuse.

Session Runtime Changes PropagationThe flow module is responsible for propagating any runtime changes that happen during the lifetime of the session. This propagation allows new packets that match the session to forward using up-to-date information. Routing runtime changes always propagate into the session. Security policy runtime changes might propagate into the session in progress, based on the corresponding security policy and zone configuration. We discuss this topic more thoroughly in a subsequent chapter.

Managing Session CharacteristicsSessions are created, based on routing and other classification information, to store information and allocate resources for a flow. Sessions have characteristics, some of which you can change, such as when they are terminated. For example, you might want to ensure that a session table is never entirely full to protect against an attackers attempt to flood the table and thereby prevent legitimate users from starting sessions.

As noted on the preceding page, depending on the protocol and service, a session is programmed with a timeout value. For example, the default timeout for TCP is 30 minutes. The default timeout for UDP is 1 minute. When a flow is terminated, it is marked as invalid, and its timeout is reduced to 10 seconds.

You can configure the Junos OS to aggressively age-out sessions based on how full the session table is by specifying the following options under the [edit security flow aging] hierarchy.

early-ageout: Specify the timeout value in seconds in which sessions age out once the high-watermark value is met.

high-watermark: Specify a percentage of how full the session table must be to implement the early-ageout function.

low-watermark: Specify the percentage at which the SRX device disables the early-ageout function and returns to the default age out time for the sessions.

The Junos OS provides a mechanism for disabling security checks on TCP packets to ensure interoperability with hosts and devices with faulty TCP implementations. Employing the no-syn-check command tells the Junos OS that it does not need to look for the TCP SYN packet for session creation. The no-sequence-check command disables TCP sequence checking validation. Applying these commands under the [edit security tcp-session] hierarchy can increase the throughput of the SRX device. SYN checking and sequence checking are enabled by default, and the previous commands disable TCP SYN checks and TCP sequence checks on all TCP sessions, thus reducing security. This might be required in scenarios with customers, or with applications that do not correctly work with standards. However, you can disable TCP SYN checking and TCP sequence checking globally and then specify these mechanisms on a per-policy basis.

[edit security policies from-zone untrust to-zone trust policy TCP]user@srx# set then permit tcp-options ?Possible completions:+ apply-groups Groups from which to inherit configuration data+ apply-groups-except Don't inherit configuration data from these groups sequence-check-required Enable per policy sequence-number checking syn-check-required Enable per policy SYN-flag check

Other options for TCP sessions can be set under the [edit security tcp-session] hierarchy, which affects how the Junos OS handles certain situations.

rst-invalidate-session: Marks a session for immediate termination when it receives a TCP RST segment. By default, this statement is disabled. When this statement is disabled, the router applies the normal session timeout intervalfor TCP, session timeout is 30 minutes; for HTTP, it is 5 minutes; and for UDP, it is 1 minute.



rst-sequence-check: Checks that the TCP sequence number in a TCP segment with the RST bit enabled matches the previous sequence number for a packet in that session, or is the next higher number incrementally. By default, this check is disabled.

strict-syn-check: Enables the strict three-way handshake check for the TCP session. It enhances security by dropping data packets before the three-way handshake is finished. By default, this check is disabled.

tcp-initial-timeout: Sets the initial TCP session timeout in the session table during the TCP three-way handshake. The timer is initiated when the first SYN packet is received, and reset with each packet during the three-way handshake. Once the three-way handshake is completed, the session timeout is reset to the timeout defined by the specific application. If the timer expires before the three-way handshake is complete, the session is removed from the session table.

You can specify the maximum segment size (MSS) in TCP SYN packets used during session establishment. Decreasing the MSS helps to limit packet fragmentation and to protect against packet loss that can occur when a packet must be fragmented to meet the MTU size but the packets DF-bit (do not fragment) is set. The following options can be set under the [edit security flow tcp-mss] hierarchy:

all-tcp: Sets the MSS on all TCP packets for network traffic.

gre-in: Enables you to specify the TCP MSS for generic routing encapsulation (GRE) packets that are coming out from an IPsec VPN tunnel. If the device receives a GRE-encapsulated TCP packet with the SYN bit and TCP MSS option set and the TCP MSS option specified in the packet exceeds the TCP MSS specified by the device, the device modifies the TCP MSS value accordingly. By default, a TCP MSS for GRE packets is not set.

gre-out: Enables you to specify the TCP MSS for GRE packets that are going into an IPsec VPN tunnel. If the device receives a GRE-encapsulated TCP packet with the SYN bit and TCP MSS option set, and the TCP MSS option specified in the packet exceeds the TCP MSS specified by the device, the device modifies the TCP MSS value accordingly. By default, a TCP MSS for GRE packets is not set.

ipsec-vpn: Enables MSS override for all packets entering an IPsec tunnel.

Packet Flow Example: Part 1

We now apply the described decision process to a specific example. As the graphic shows, Host-B at 10.1.20.5 wants to initiate an HTTP session with the Web server at 200.5.5.5. The traffic passes through an SRX Series Services Gateway and is therefore subject to the decision process.




The graphic shows the packet as received by the SRX Series Services Gateway on interface ge-0/0/1. Following the flowchart, you can track the progress of the packet through the services gateway:

1. Based on a lookup in the session table, the Junos OS determines that this session is not an existing session.

2. The forwarding table shows that the software detects how to reach the destination network.

3. Now that the forwarding lookup is complete, the software can determine the ingress and egress zones required for security policy evaluation.




The following is a continuation of the list from the previous page:

4. The packet is from host 10.1.20.5 and is an HTTP packet. This packet matches the policy statement in the inset. The action for this particular type of traffic is to permit it.

5. The SRX Series Services Gateway adds the flow information to the session table. At the same time a return flow is automatically created and also adds to the session table.

6. The SRX Series Services Gateway then forwards the packet out interface ge-1/0/0 (as determined by the destination lookup). The Junos OS allows traffic in both directions for this particular session to pass without any subsequent policy evaluation.

Review Questions



Answers1.

Traditionally, routers process packets on a per-packet basis.

2.

Traditionally, firewalls process packets based on stateful flows.

3.

The Junos OS that runs on security platforms uses session-based packet forwarding and by default does not allow traffic to pass, whereas the traditional Junos OS uses packet-based forwarding and by default allows all traffic to pass.

4.

The first packet of a new session is subject to first-path packet processing.

2012 Juniper Networks, Inc. All rights reserved. Zones Chapter 21


Chapter 2: Zones

This Chapter Discusses: Zones and their purpose;

Types of zones;

Application of zones;

Configuring zones; and

Monitoring zones.

Zone DefinitionA zone is a collection of one or more network segments sharing identical security requirements. To group network segments within a zone, you must assign logical interfaces from the device to a zone.

Traffic Regulation Through a Junos Security PlatformZones enable network security segregation. Security policies are applied between zones to regulate traffic through the security platform running the Junos operating system. By default, all network interfaces belong to the system-defined Null Zone. All traffic to or from the Null Zone is dropped. Special interfaces including the fxp0 management Ethernet interface present in some SRX Series platforms, chassis cluster fabric interfaces, and internal system em0 interfaces cannot be assigned to a zone.


Chapter 22 Zones 2012 Juniper Networks, Inc. All rights reserved.

Review: Packet Flow

Recall the packet flow through a Junos security platform. Specifically, once the packet enters a flow module, the device examines it to determine whether it belongs to an already established session. Recall that the Junos OS matches on six elements of traffic information to identify a sessionsource IP address, destination IP address, source port number, destination port number, protocol number, and a session token.

This chapter focuses on defining, configuring, and monitoring zones.

Zones and InterfacesYou can assign one or more logical interfaces to a zone. You can also assign one or more logical interfaces to a routing instance. You cannot assign a logical interface to multiple zones or multiple routing instances. You must also ensure that all of a zones logical interfaces are in a single routing instance. Violating any of these restrictions results in a configuration error as shown in the following examples:

[edit]user@srx# commit check[edit security zones security-zone trust] 'interfaces ge-0/0/2.0' Interface ge-0/0/2.0 already assigned to another zoneerror: configuration check-out failed[edit]user@srx# commit check[edit routing-instances A interface] 'ge-0/0/0.0' RT Instance: Interface ge-0/0/0.0 already configured under instance B[edit routing-instances B] 'interface' Interface ge-0/0/0.0 is in more than one routing instance (latest A)error: dcd_config_read fails to set parsing optionserror: configuration check-out failed

[edit]user@srx# commit check



[edit security zones security-zone untrust] 'interfaces ge-0/0/2.0' Interface ge-0/0/2.0 must be in the same routing instance as other interfaces in the zoneerror: configuration check-out failed

Interfaces, Zones, and Routing Instances

The graphic summarizes logical relationships between interfaces, zones, and routing instances.

Logical interfaces are connections to specific subnets. Zones are logical groupings of logical interfaces with a common security requirement, and a logical interface can belong to only one zone. Zone configuration can be as simple as a two-zone setup, where all interfaces connected to internal networks are in one zone, and all interfaces connected to the external world are in a different zone. A more complicated configuration might divide interfaces based on internal department or function in addition to external and demilitarized zone (DMZ) connections.

A physical device can be broken up into multiple routing instances. A routing instance is a logical routing construct within a platform running the Junos OS. Each routing instance maintains its own routing table and forwarding table. A routing instance can contain one or more zones, which cannot be shared with other routing instances.

Zone Types

The zones within the Junos OS can be subdivided into two categoriesuser-defined and system-defined. You can configure user-defined zones, but you cannot configure system-defined zones. You can subdivide the user-defined category into security and functional zones. We cover user-defined and system-defined zones in detail on the next few pages.



Security ZonesSecurity zones are a collection of one or more network segments requiring regulation of inbound and outbound traffic through the use of policies. Security zones apply to transit traffic as well as traffic destined to any interfaces belonging to the security zone. You need one or more security policies to regulate intrazone and interzone traffic. Note that the Junos OS does not have any default security zones, and you cannot share a security zone between routing instances.

Functional ZonesFunctional zones are special-purpose zones that cannot be specified in security policies. Note that transit traffic does not use functional zones. While the fxp0 management Ethernet interface is out-of-band by default, the Management zone allows you to assign other network interfaces the same behavior of isolating management traffic from transit traffic.

Null ZoneCurrently only one system-defined zone exists, the Null zone. By default, all interfaces belong to the Null zone. You cannot configure the Null zone. When you delete an interface from a zone, the software assigns it back to the Null zone. The Junos OS rejects all traffic to and from interfaces belonging to the Null zone.

Junos-Host Zone The junos-host zone is a system-defined zone. You can configure the junos-host zone in a security policy to provide granular control for which host-inbound or host-outbound traffic is allowed in or out of a security zone on the SRX device.

Functional zones, such as the management zone, cannot be used in a security policy. For inbound traffic to be processed by the junos-host zone, the traffic has first to be allowed by the host-inbound-traffic setting of an ingress security zone, after which a normal policy lookup will be done from the ingress zone to the junos-host zone. You can also use the junos-host zone to control or apply services to host outbound traffic. An example of controlling services to host-outbound traffic would be to configure a security policy to allow host-outbound traffic through a policy-based VPN. Traffic is permitted through the junos-host zone unless otherwise explicitly denied by a user-defined security policy.



Junos-Host Zone Configuration

The inset demonstrates a configuration example for using the junos-host zone within a security policy. In this case, the junos-host zone is specified in the to-zone context within the policy. FTP and ping traffic are allowed as host-inbound traffic on the untrust zone, as shown in the inset security zone configuration. The host-inbound FTP and ping traffic are then evaluated by the security policy from the untrust zone to the junos-host zone. In this case, if the ping traffic has a source address of 172.20.1.10, it will be denied. Otherwise, it will be allowed. Also, all FTP traffic will be allowed, and if the FTP traffic has a source address of 10.10.10.1, the traffic will be logged on session initialization.

Branch Platforms

Junos security platforms for the branch ship from the factory with a template configuration that includes security zones. SRX Series high-end platforms do not contain zones in the factory-default template configuration and, therefore, you must configure required zones manually.

Factory-Default ConfigurationIn branch devices factory-default configuration, two security zones are definedtrust and untrust. In the template configuration, vlan.0 belongs to the trust zone. In addition, the factory-default configuration file has a security policy permitting all transit traffic within the trust zone and from the trust zone to the untrust zone. The security policy prohibits any traffic from the untrust zone to the trust zone. We discuss security policy in further detail in a subsequent chapter. The zone names trust and untrust have no system-defined meaning. Like any zones defined in the configuration, you can modify or delete them. You can revert a Junos platform to its factory-default configuration by entering the load factory-default command from the top of the configuration hierarchy.

Zone Configuration ProcedureZone configuration involves the following steps:

1. Define a security or a functional zone;

2. Add logical interfaces to the zone; and



3. Optionally, identify some combination of system services and protocols allowed into the device through the interfaces belonging to the zone. If you omit this step, all traffic entering through the zones interfaces destined for the device is blocked.

Configuring Zones

To define a zone you must enter configuration mode, as illustrated in the inset.

Once you enter the configuration mode, you can define a zone type. Recall that you can configure only two types of zonesfunctional, which is used for device management only (no transit traffic is permitted), and security. You define zones under the security configuration stanza. Note that user-defined zone names are case sensitive and can contain any standard characters, like any other variable name in the Junos OS.

Two important configuration characteristics of the functional zone are as follows:

You can define only one type of functional zonemanagement; and

The functional zone does not have a user-defined name.



Adding Logical Interfaces to a Zone

Now you are ready to add logical interfaces to the zone. The inset illustrates two variations. The first example illustrates adding interface ge-0/0/1.0 to the security zone, called HR, and the second example illustrates adding interface ge-0/0/1.100 to the functional management zone. If you omit the specification of the logical unit of the interface, the Junos OS assumes unit 0. Also, you can assign all interfaces to a zone by using the keyword all. Should you choose to assign all interfaces to a zone, you will not be able to assign any interfaces to a different zone.

Specifying Types of Traffic Permitted into the Device: Part 1Without explicit configuration, traffic destined for a Junos security platform is not permitted. You can specify types of traffic allowed into the device using the host-inbound-traffic configuration option under a specific zone or under an interface configured in a zone. All outbound traffic originating from the device is always allowed.

Specifying Types of Traffic Permitted into the Device: Part 2When specifying types of traffic permitted into a Junos security platform, you use some combination of the system-services and protocols configuration options. The Junos OS provides you with the ability to refer to all system services and protocols and respective ports with the help of the all keyword. To open all ports for all services, use the any-service keyword. In addition, you can isolate any exceptions to the referred list of protocols or system services with the help of the except keyword. The examples on the following pages illustrate the use of this keyword.

You can specify any of the following system services:

[edit security zones]user@srx# set security-zone HR host-inbound-traffic system-services ?Possible completions: all All system services any-service Enable services on entire port range dns DNS and DNS-proxy service finger Finger service ftp FTP http Web management service using HTTP https Web management service using HTTP secured by SSL ident-reset Send back TCP RST to IDENT request for port 113 ike Internet Key Exchange lsping Label Switched Path ping service netconf NETCONF service ntp Network Time Protocol service ping Internet Control Message Protocol echo requests reverse-ssh Reverse SSH service



reverse-telnet Reverse telnet service rlogin Rlogin service rpm Real-time performance monitoring rsh Rsh service sip Enable Session Initiation Protocol service snmp Simple Network Management Protocol service snmp-trap Simple Network Management Protocol traps ssh SSH service telnet Telnet service tftp TFTP traceroute Traceroute service xnm-clear-text JUNOScript API for unencrypted traffic over TCP xnm-ssl JUNOScript API service over SSL

You can specify any of the following protocols:

[edit security zones]user@srx# set security-zone HR host-inbound-traffic protocols ? Possible completions: all All protocols bfd Bidirectional Forwarding Detection bgp Border Gateway Protocol dvmrp Distance Vector Multicast Routing Protocol igmp Internet Group Management Protocol ldp Label Distribution Protocol msdp Multicast Source Discovery Protocol ndp Enable Network Discovery Protocol nhrp Next Hop Resolution Protocol ospf Open Shortest Path First ospf3 Open Shortest Path First version 3 pgm Pragmatic General Multicast pim Protocol Independent Multicast rip Routing Information Protocol ripng Routing Information Protocol next generation router-discovery Router Discovery rsvp Resource Reservation Protocol sap Session Announcement Protocol vrrp Virtual Router Redundancy Protocol.



Specifying Types of Traffic Permitted into the Device: Part 3

You can specify allowed traffic either at the zone level of configuration or the interface level within a zone. As with any configuration in the Junos OS, the precedence rule of more specific configuration applies here as well. In other words, interface-level configuration (as it is more specific) overrides the zone-level configuration. In the examples in the inset, only the HTTP system service is allowed into interface ge-0/0/1.0, which is part of the HR Zone. All other interfaces associated with the HR Zone can accept all system services.

Check Your Knowledge: Part 1

The inset shows an example of zone configuration. What types of traffic are allowed into the specified zone and interfaces? In this example, a security zone named HR is configured. Interfaces ge-0/0/0.0 and ge-0/0/1.0 belong to that zone. Inbound Telnet and FTP traffic are allowed into the device through these interfaces. All other inbound traffic that is local to the device on these interfaces is dropped.




The inset shows another example of zone configuration. What types of traffic are allowed into the specified zone and interfaces? In this example, a security zone named HR is configured. Interfaces ge-0/0/0.0 and ge-0/0/1.0 belong to that zone. As the SNMP service is specified to be allowed only through interface ge-0/0/1.0, SNMP will not be allowed into interface ge-0/0/0.0. In addition, Telnet and FTP services will be allowed only using the ge-0/0/0.0 interface and not the ge-0/0/1.0 interface.




The inset shows the third example in this series. What does this configuration do? In this example, a security zone named zone1 is defined. It permits all inbound services with the exception of Telnet. There are two interfaces that belong to security zone zone1ge-0/0/0.0 and ge-0/0/1.0. Interface ge-0/0/0.0 permits all services with the exception of Telnet. Interface ge-0/0/1.0 permits all services with the exception of HTTP and FTP services.



Monitoring Zones

The graphic illustrates the show security zones command, which is useful for zone monitoring. The command provides information on the zone type and name along with the number and names of interfaces bound to the zone.



Monitoring Traffic Permitted into Interfaces: Part 1

Using the show interfaces interface-name extensive command enables you to view zone specifics. The command displays information on permitted protocols and system services allowed into the device through the corresponding interface. In addition, the command provides information on flow statistics through the interface.

Monitoring Traffic Permitted Into Interfaces: Part 2

The inset provides the continuation of the output from the previous page.



Review Questions

Answers1.

A zone is a collection of one or more network segments sharing identical security requirements.

2.

Overall, there are two types of zones in the Junos OSuser-defined and system-defined zones. User-defined zones include security and functional zones, both of which you can configure. The Null Zone is a system-defined zone that you cannot configure. The security zone allows transit packets and packets to the device itself. The functional zone allows only management traffic. The Null Zone is a placeholder for interfaces that do not belong to any zone. All interfaces belonging to the Null Zone drop all packets.

3.

To configure a zone, you must perform the following steps: (1) Define a security zone or a functional zone; (2) Add logical interfaces to the zone; and (3) Optionally, add services and protocols that must be permitted into the device.

4.

You can specify traffic types to be allowed into a Junos security platform using the host-inbound-traffic statement.

2012 Juniper Networks, Inc. All rights reserved. Security Policies Chapter 31


Chapter 3: Security Policies

This Chapter Discusses: Security policy functionality;

Components of a security policy;

Verification and monitoring of security policies; and

Configuring a security policy.

What Is a Security Policy?

A security policy is a set of statements that controls traffic from a specified source to a specified destination using a specified service. If a packet arrives that matches those specifications, the SRX Series device performs the action specified in the policy.

Network security policies are highly valuable for secure network functionality. Network security policies outline all network resources within a business and the required security level for each resource. The Junos operating system provides a set of tools to implement a network security policy within your organization. Security policies enforce a set of rules for transit traffic, identifying which traffic can pass through the firewall and the actions taken on the traffic as it passes through the firewall.


Chapter 32 Security Policies 2012 Juniper Networks, Inc. All rights reserved.

Review: Packet Flow

The graphic reviews packet flow through the flow module of a Junos security platform.

When the device examines the first packet of a flow, based on incoming and outgoing zones, it determines the corresponding security policy, and it performs a security policy lookup. The system checks the packet against defined policies to determine how to treat the packet.

In this chapter, we focus on the security policies portion of the Junos OS.

Transit Traffic Examination

The Junos OS for security platforms always examines transit traffic by using security policies. As illustrated in the graphic, should no match exist in the security policy, the default security policy applies to the packet. We highlight the default security policy in a subsequent section.



host-inbound-traffic Examination

If the destination of traffic is the devices incoming interface, security policies are not applicable. The only examination that takes place is the list of services and protocols allowed into that interface using the host-inbound-traffic statement within a zone definition. (See Chapter 3: Zones for details.)

The Junos OS examines security policies if the traffic destination is any interface other than the incoming interface. This process is true regardless of whether the incoming interface and the destination interface are in the same zone (intrazone traffic) or in different zones (interzone traffic).

The flowchart illustrates the order of packet examination. When the device receives traffic destined to itself, it first examines whether the destination of the traffic is the incoming interface. If so, it skips the policy examination. Otherwise, the corresponding security policies evaluate the traffic. If no policy match exists for the traffic, the default policy action applies. We discuss the default security policy on the next page. If traffic matches a security policy that permits it, the device then examines the list of services and protocols allowed into the destination interface within the corresponding zone, and applies the corresponding action.



System-Default Security Policy

By default, the Junos OS denies all traffic through an SRX Series device. In fact, an implicit default security policy exists that denies all packets. You can change this behavior by configuring a standard security policy that permits certain types of traffic, or by configuring the default policy to permit all traffic as shown in the following screen capture.

[edit security policies]user@srx# set default-policy permit-all

Factory-Default Security PoliciesThe factory-default template configuration file in branch security platforms has three preconfigured security policies (not to be confused with the system-default security policy discussed in the previous paragraph):

1. Trust-to-trust zone policy: Permits all intrazone traffic within the trust zone;

2. Trust-to-untrust zone policy: Permits all traffic from the trust zone to the untrust zone; and

3. Untrust-to-trust zone policy: Denies all traffic from the untrust zone to the trust zone.



Security Policy Conceptual Example

We now examine an example of a packet flow through a Junos security platform.

The devices interfaces are separated into three security zonesprivate, external, and public. The business requirement calls for an SSH application to be allowed from Host B, located in the private zone, to Host D, located in the external zone. To meet the requirement, we created the security policy illustrated in the graphic.

The following is the sequence of events that takes place:

1. Host B initiates the SSH session to Host D.

2. The Junos security device receives traffic and examines it using its security policy from the private zone to the external zone. The security policy permits that traffic.

3. The Host B-to-Host D flow triggers the creation of the reverse flow from Host D to Host B. The graphic identifies the contents of this newly formed session. It consists of two flowssource to destination and destination to source.

4. Host D sends the return traffic, from Host D to Host B. The device, using a pre-created session, permits the return traffic through to Host B.

Policy Ordering

Because policies execute in the order of their appearance in the configuration file, you should be aware of the following:

Policy order is important.

New policies go to the end of the policy list.



You can change the order of policies in the configuration file using the Junos insert command.

The last policy is the default policy, which has the default action of denying all traffic.

Editing Security ConfigurationsLike any other Junos configuration stanza, you can delete, deactivate, activate, insert, annotate, copy, rename and search and replace security policies.

What Is an ALG?

An ALG is a software process used to associate multiple connections from an application with the initial session that application creates. Each ALG must be designed for a specific protocol, and all ALGs function slightly differently from each other.

The ALG module, which is part of the flow module on SRX devices, is responsible for Application-Layer-aware processing. The ALG processing is performed in both the first-path and the fast-path. When the initial packet is received, the first path sets up the ALG vector and the fast-path applies the ALG.

For an ALG to performs its role, it must do the following:

Inspect the packet for an embedded IP address and port information in the packet payload;

Open a gate for the IP address and port number to permit data exchange for the session; and

Perform Network Address Translation (NAT) processing if necessary.



FTP ALG Example

This graphic and the next several graphics provide an overview of the functionality of the FTP ALG during an active FTP session.

We begin our basic example by showing an FTP control session. By default, an FTP session uses both a control channel and a data channel between the client and server. The control channel establishes from the client to the server using the well-known TCP port 21.

FTP Data Session

Continuing with the FTP ALG example, the graphic shows the client successfully establishing a control connection, and the server initiating a data connection originating from a port one lower then the control session. The server expects TCP port 20 for the data connection, as this port is the default, well-known port.



However, because FTP uses a different connection for data transfers, it requires the intervention of the ALG. The initial FTP request is initiated using port 21, which invokes the ALG.

Upon being invoked, the Junos OS FTP ALG opens a pinhole for server replies on the data channel. A pinhole is the opening of a port to allow return traffic using the security policy that matches on the original traffic. After the control channel establishes from client to server, the ALG creates a pinhole for the returning data channel, which is established from server to client. Pinholes are common functions that are used by more than one ALG.

By default, the Junos OS uses the next lowest port for this transaction. With the use of the PORT command, the ALG parses the statement and extracts the specified client port. A pinhole session holder can be created from the server data port to the new client port.

FTP with the ALG Applied

As shown in this inset, with the FTP ALG applied, only the trust-to-untrust security policy is needed to allow traffic in both directions. The trust-to-untrust security policy allows the initial client-to-server FTP control channel to establish using port 21. The ALG allows for the return data channel to establish using port 20 from the same security policy.

FTP with the ALG Ignored

With the FTP ALG ignored, only the FTP control channel (port 21) is allowed to use the security policy trust-to-untrust, which permits the initial FTP traffic. To allow the FTP data channel (port 20) from the server, policy untrust-to-trust is needed to allow the return traffic. Another option is to create a custom application to allow passive FTP. You need only a single security policy with passive FTP-the client initiates both control and data connections.

Supported ALGs and Behavior

The list of ALGs that the Junos OS supports is shown in the inset. A brief description of each ALG follows:

Domain Name System (DNS): The DNS ALG monitors the DNS reply packet. Once a reply packet returns from the DNS server, the session closes.

FTP: For default FTP, the FTP ALG opens a pinhole for replies from server to client one port lower than the control session. The FTP ALG monitors PORT, PASV and 227 commands. The FTP ALG also monitors EPRT, EPSV and 229 commands for IP version 6 (IPv6).

H.323: A number of dynamic ports must be determined to open the appropriate pinholes for the return traffic. The ALG parses the various confirmation and response messages, and extract the network and transport addresses that they contain. The ALG alters this data if NAT is in effect to replace public and private



addresses as needed. In addition, the ALG uses the embedded Transport layer address to open pinholes for future communications to the peer client.

Media Gateway Control Protocol (MGCP): The MGCP ALG conducts voice over IP (VoIP) and MGCP signaling payload inspection, provides stateful processing, performs NAT, and manages pinholes for VoIP traffic.

Point-to-Point Tunneling Protocol (PPTP): The PPTP ALG parses the control messages, looking for the outgoing call request and outgoing call reply messages. The ALG opens up one gate to accept generic routing encapsulation (GRE) traffic sent by the server and the other gate to accept GRE traffic sent by the client. The ALG can support Port Address Translation (PAT) for PPTP.

Real-Time Streaming Protocol (RTSP): The RTSP ALG monitors the control connection, opens flows dynamically for media streams, and performs NAT address and port rewrites.

Sun Microsystems Remote Procedure Call (SUNRPC): The SUNRPC ALG provides the functionality for handling the dynamic transport address negotiation mechanism of the Sun RPC and to ensure program number-based security policy enforcement. You can define a security policy to permit or deny all RPC requests, or to permit or deny by specific program number. The ALG also supports route and NAT mode for incoming and outgoing requests.

Microsoft Remote Procedure Call (MSRPC): The MSRPC ALG provides the functionality for handling the dynamic transport address negotiation mechanism of the MSRPC, and to ensure universal unique identifier (UUID) based security policy enforcement. You can define a security policy to permit or deny all RPC requests, or to permit or deny by specific UUID number. The ALG also supports route and NAT mode for incoming and outgoing requests.

in (RSH): The RSH ALG handles TCP packets destined for port 514 and processes the RSH port command. The RSH ALG also performs NAT on the port, in the PORT command and opens gates as necessary.

Session Initiation Protocol (SIP): The SIP ALG reads SIP messages and the Session Description Protocol (SDP) content, and extracts the port-number information it needs to dynamically open pinholes to let the media stream traverse the SRX device.

Skinny Client Control Protocol (SCCP): The SCCP ALG parses the remote IP address, the remote port in start media transmission, and the open receive channel messages. The SCCP ALG then opens pinholes for the return traffic.

Structured Query Language (SQL): The SQL ALG processes SQL Transparent Network Substrate (TNS) response frame from the server side. It parses the packet and looks for the (HOST=ipaddress), (PORT=port) pattern, and performs NAT and gate opening on the client side for the TCP data channel.

TALK: The TALK protocol uses UDP port 517 and port 518 for control channel connections. The talk program consists of a server and a client. The server handles client notifications and helps to establish talk sessions. The two types of talk servers are ntalk and talkd. The TALK ALG processes packets of both ntalk and talkd formats. It also performs NAT and gate opening as necessary.

Trivial File Transfer Protocol (TFTP): The TFTP ALG processes the packet that initiates the request and opens a gate to allow return packets to the port that sends the request.

Internet Key Exchange and Encapsulating Security Payload (IKE-ESP): The IKE-ESP ALG monitors IKE traffic between the client and the server, and permits only one IKE Phase 2 message exchange between any given client and server pair. Note that the IKE-ESP ALG is disabled by default.

ALG Configuration

You configure ALGs under the [edit security alg] hierarchy. Note that some ALGs have specific configuration options. You can enable a disabled ALGfor example IKE-ESPunder this hierarchy as well. You can configure all ALGs for traceoptions.

This inset shows an example for the configuration options for the DNS ALG.



Applying ALGsTo apply an ALG to a custom application, configure application-protocol under the [edit applications application name] hierarchy. This configuration is needed for a custom application to take advantage of the ALG. For example, when creating a custom application for FTP, you must apply the ALG for it to be associated with the custom FTP application. Use the application-protocol configuration option to also configure an ALG to be ignored, which we cover later in the chapter.

any-ipv4: 0.0.0.0/0 any-ipv6: ::/0 Application: junos-ftp IP protocol: tcp, ALG: ftp, Inactivity timeout: 1800 Source port range: [0-0] Destination port range: [21-21]

Verifying ALGs

This inset shows the show security policies detailed command. The output indicates that the trust-to-untrust policy has the FTP ALG applied to it. You can use other variations of this command for the same information, which might be helpful if many policies are configured. The following screen capture provides another example of how to show the details of a security policy:

user@srx> show security policies from-zone trust to-zone untrust policy-name trust-to-untrust detail Policy: trust-to-untrust, action-type: permit, State: enabled, Index: 6, Scope Policy: 0 Policy Type: Configured Sequence number: 1 From zone: trust, To zone: untrust Source addresses: any-ipv4: 0.0.0.0/0 any-ipv6: ::/0 Destination addresses:

Security Policy ContextsWhen defining a policy, you must associate it with a source zone, or incoming zonenamed the from-zone. Also, you must define a destination zone, or an outgoing zonenamed the to-zone. Within a direction of source and destination zones, you can define more than one policy, referred to as an ordered set of policies, which the Junos OS executes in the order of their configuration.

Recall that a zone is a collection of multiple logical interfaces with identical security requirements. The Junos OS always checks all transit trafficintrazone and interzonethrough the use of security policies.



Security Policy ComponentsWithin the defined context title, each policy is labeled with a user-defined name. Under the user-defined name is a list of matching criteria and specified actions, similar to a Junos routing policy. One major difference is that each security policy must contain a matching source address, destination address, and application. Actions for traffic matching the specified criteria include permit, deny, reject, log, or count.

The Junos OS also uses policy to invoke the use of Intrusion Detection and Prevention (IDP) policies, the Unified Threat Management (UTM) feature for branch devices, and firewall authentication. We discuss IDP and firewall authentication in detail in subsequent chapters.

Policy Match Criteria

Each of the defined policies must include the following matching criteria:

Source addresses: This criterion can be in the form of address sets or individual addresses. You can group individual addresses into address sets.

Destination addresses: This criterion can be in the form of an address sets or individual addresses. You can group individual addresses into address sets.

Applications or application sets: This criterion can be user-defined or system-defined. The Junos OS supports system-crafted default applications and application sets, referred to using the format junos-application, where application is the name of the actual application. You can also define your own applications.

You must specify all matching components. If you omit any of these components, the Junos OS does not allow you to commit the configuration.

Creating Address Book Entries

The inset illustrates the syntax that you must use when creating address book entries. An address book within a zone can consist of individual addresses or address sets. An address set is a set of one or more addresses defined within an address book. Address sets are useful when you must refer to a group of addresses more than once. If the matching criteria needs no



specific address, no address book entry is necessary. In this case, you can specify the configuration option any as the source or destination address in a security policy.

IPv6 Addressing

In this inset, we show the syntax you must use when you create an IPv6 address book entry within a zone. You must enable the inet6 flow-based option under the security forwarding-options hierarchy when adding an IPv6 address book entry. After you issue a commit to activate inet6 flow-based, you must reboot the SRX device for the changes take effect. If SRX devices are in a cluster, you must reboot both nodes. The following example shows how to verify the flow status of the SRX device:

user@srx> show security flow status Flow forwarding mode: Inet forwarding mode: flow based Inet6 forwarding mode: flow based MPLS forwarding mode: drop ISO forwarding mode: drop Flow trace status Flow tracing status: off

Creating a DNS Address Book EntryThe DNS address book entry allows for using security policies to base the match criteria on a domain name instead of an IP address. You must configure the SRX device for a DNS server for the DNS address book entry to allow the specified domain name entry. This inset shows how to configure a DNS address book entry and a DNS server.

The following example is a detailed security policys output showing what to expect with a DNS address book entry. Under the destination addresses, the domain name should be with the resolved IP address.

user@srx> show security policies policy-name name detail Policy: name, action-type: permit, State: enabled, Index: 6, Scope Policy: 0 Policy Type: Configured Sequence number: 1 From zone: dc, To zone: untrust Source addresses: any-ipv4: 0.0.0.0/0 any-ipv6: ::/0 Destination addresses: abc.com: 192.168.10.100/32



...

Defining Custom Applications

The Junos OS has many built-in applications, such as junos-rsh, junos-sip, junos-bgp, and so forth. You can customize the list of predefined applications (thus expanding the overall list), which gives you the capability to support complex applications.

[edit]user@srx# show groups junos-defaults | match application | match junos application junos-ftp { application junos-tftp { application junos-rtsp { application junos-netbios-session { application junos-ssh { application junos-telnet {...

To configure a custom application, define the application name, associate the application with a protocol and ports. Use the application-protocol configuration option to associate the custom application with an application-level gateway (ALG). A user-configured application has a timeout value associated with it. The Junos OS applies the timeout value to the created session. Once the timeout expires, the software clears the session from the session table. You can modify the timeout value for a specific application. Note that the new timeout value applies only to new sessionsnot to existing ones.

Viewing Predefined ApplicationsAs the inset shows, use the show groups junos-defaults applications configuration mode command to view predefined applications. The junos-defaults part of the command is hidden, and therefore, you must fully type this part of the command. Alternatively, the operational mode command, show configuration groups junos-defaults applications, provides the same output.

On the inset, we show the predefined application junos-ftp.

Altering Predefined ApplicationsYou might choose to alter predefined applications so that you permanently change the defaults to settings you prefer. Although you can also create new applications so that you do not alter the applications that are built in to the Junos OS, doing so requires several additional steps and does not generally warrant the time if you know that you will never want to use the built-in applications with their default settings.

The following list provides some common reasons to alter predefined applications:

You want to use a different port number for an application than that which is predefined, because not using well-known ports might help you increase security.



You want to increase or decrease the predefined timeout value to alter how long an application can be inactive before it times out.

You want an application to ignore the ALG, which effectively disables the ALG for that application, but still keep the ALG enabled for other applications. (If you actually disable the ALG, the ALG is disabled for all applications.)

To alter predefined applications, create a new application with the same name as the built-in application. Create the new application under the [edit applications] hierarchy. Remember that to view built-in application, issue the command show groups junos-defaults applications.

The same options exist for altering a built-in application as for creating a custom application. You must configure only the options you want to alter. The following example alters only the inactive timeout for the junos-ftp application from 1800 seconds to 3600 seconds; the other options stay as predefined.

[edit applications]user@srx# showapplication junos-ftp inactivity-timeout 3600;

Altering Predefined Applications Using Groups

You can alter predefined applications using a group configuration and applying it to the groupas long as the applications all use the same IP protocol. Note, however, that you might find it difficult to find applications with enough in common to be able to use a group configuration.

The inset illustrates how to create a group to alter the timeout for junos-ftp and junos-finger. The inset also shows that the group is applied at the top of the configuration hierarchy using configuration mode. You can also apply the group at the [edit applications] hierarchy as an alternative to the global configuration. The following is an example of applying the group at the [edit applications] hierarchy:

[edit]user@srx# show applications apply-groups group-name;



Verifying the Altered Application

The output shows us that our group configuration for the application wildcard, (which you can see in the previous output), was successful. Note that the timeout value for both junos-ftp and junos-finger is now altered from its original, default value.

Creating Policy Match Entries

You enter all policies under the from-zone...to-zone stanza for that particular traffic direction. The from-zone...to-zone stanza associates the policies under it with a source zone and a destination zone. Under a specific zone direction, each security policy contains a name, match criteria, and an action. This example focuses on match criteria. The system executes all policies in the order of their appearance within a configuration file.

Basic Policy ActionsEach policy has a list of basic and advanced actions associated with it. The basic actions are the following:

permit: Allows traffic flow;

deny: Results in a silent packet drop; and



reject: Results in a packet drop and the sending of an Internet Control Message Protocol (ICMP) unreachable message for UDP traffic and a TCP reset register suppression time (RST) message for TCP traffic.

Log and Count TrafficFor each of these actions, you can configure the Junos OS to log and count traffic as well. To view counters, use the show security policies detail operational mode command. We discuss logging in detail in subsequent pages.

Advanced Permit SettingsAmong the policy actions mentioned previously, the following advanced permit settings exist:

Firewall authentication;

IPsec VPN tunnel;

IDP; and

UTM features.

Firewall authentication enables you to restrict and permit users accessing protected resources that could be located in different zones. The Junos OS offers two methods of firewall authentication:

Pass-through: Firewall users that are using FTP, Telnet, or the Hypertext Transfer Protocol (HTTP) to access protected resources across the device receive authentication through a username and password. The Junos security platform intercepts the session and then performs user authentication.

Web authentication: Firewall users use HTTP or HTTP over Secure Sockets Layer (HTTPS) to access an IP address of the Junos security device, instead of the protected resource. The device acts as a proxy, authenticating the user with a username and password and caches the information.

We discuss firewall authentication in more detail in the chapter titled, Firewall User A

Documents

JNCIS-SEC-P1_2012-12-19