Jncis Sec

JNCIS-SEC Study Guide
Worldwide Education Services
1194 North Mathilda Avenue

Sunnyvale, CA 94089
USA
408-745-2000
www.juniper.net
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.
JNCIS-SEC Study Guide.
Copyright © 2010, 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 10.1R1.8. 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.
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.
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
Contents • iii
Overview
Welcome to the JNCIS-SEC Study Guide. The purpose of this guide is to help you prepare for
your JN0-331 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
. Overview • iv
Document Conventions
CLI and GUI Text

Frequently throughout this study 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.
Style Description Usage Example
Franklin Normal text. Most of what you read in the

Gothic Student Guide.
Courier Console text:

New commit complete
• Screen captures
• Noncommand-related Exiting configuration
syntax mode
GUI text elements: Select File > Open, and then
click Configuration.conf in
• Menu names
the Filename text box.
• Text field entry
Input Text Versus Output Text

You will also frequently see cases where you must enter input text yourself. Often this will be
shown in the context of where you must enter it. We use bold style to distinguish text that is
input versus text that is simply displayed.
Normal CLI No distinguishing variant. Physical interface:fxp0,

Enabled
Normal GUI
View configuration history by
clicking Configuration >
History.
CLI Input Text that you must enter. lab@San_Jose> show route
GUI Input Select File > Save, and enter
config.ini in the Filename
field.
v • Document Conventions
Defined and Undefined Syntax Variables
Finally, this study 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.
CLI Text where variable value is already policy my-peers

Variable assigned.
Click on my-peers in the dialog.
GUI
variable
CLI Text where the variable’s value is Type set policy

Undefined the user’s discretion and text where policy-name.
the variable’s value might differ
GUI ping 10.0.x.y
from the value the user must input.
Undefined
Select File > Save, and enter
filename in the Filename field.
Document Conventions • vi
Additional Information
Education Services Offerings

You 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 Publication

The JNCIS-SEC Study Guide was developed and tested using software Release 10.1R1.8.
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
training@juniper.net.
Technical Publications
You 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 Support

For 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).
vii • Additional Information

Chapter 1: Introduction to Junos Security Platforms
This Chapter Discusses:

• Traditional routing and security implementations;
• Current trends in internetworking;
• SRX Series Services Gateways;
• The Junos operating system for the SRX Series; and
• Physical 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 Stateless

Traditionally, 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 Connectivity

Routers 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.
Introduction to Junos Security Platforms • Chapter 1–1

© 2010 Juniper Networks, Inc. All rights reserved.
Layer 3 Packet Forwarding
The graphic illustrates the transmission of packets from host 10.1.1.10 to host 10.3.3.10. 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, on 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.
Promiscuous Behavior of a Traditional Router
A 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 Security

Other 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.
Chapter 1–2 • Introduction to Junos Security Platforms

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 Network

Standalone 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 Devices

A 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 Services
The 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 Processing
Because 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
information—source 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 VPN—not 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.
Current Trends
As boundaries of networks are becoming less clear, so are the requirements of network edge devices. More and
more enterprises are interconnecting themselves through an ISP’s virtual cloud by using IP. The Internet has created
possibilities and opportunities for businesses and markets, and it has erased the concept of distance. With the
Internet, however, came network vulnerabilities. Traditionally, routers have been positioned on the edge of an
enterprise network and provided very basic network security such as stateless firewall filters. Network administrators
became used to relying on separate firewall devices positioned within enterprise DMZs. The consolidation of these
functions at the network edge improves costs, reduces management overhead, and increases operational simplicity.
A New Perspective
The graphic illustrates how a device with strong routing and firewall features can be positioned at network
boundaries. Remote offices can deploy SRX Series branch platforms running the Junos OS to provide both routing
and security features.
The SRX Series Services Gateway at the enterprise headquarters in this example also provides routing and security
in a high-density, modular chassis. The Dynamic Services Architecture allows SRX Series Services Gateways to
leverage new services with appropriate processing capabilities without sacrificing overall system performance. SRX
Series Services Gateways are next-generation systems designed to meet the network and security requirements for
the enterprise and service provider infrastructure, and facilitate data center consolidation, rapid managed services
deployments, and security services aggregation.

SRX Series High-End Systems
The Juniper Networks SRX Series Services Gateways for the high end are next-generation services gateways based
on a revolutionary architecture that provides market-leading scalability and service integration. These devices are
ideally suited for large enterprise and service provider networks:
• Securing large enterprise data centers;
• Securing service provider and collocated data centers;
• Aggregating departmental or segmented security solutions; and
• Securing managed services and core service provider infrastructure.
Based on the Dynamic Services Architecture, the SRX Series provides unrivaled scalability. Each services gateway
can support almost linear scalability with each additional Services Processing Card (SPC), enabling a fully equipped
SRX5800 to support more than 120 Gbps of firewall throughput. The SPCs are designed to support a wide range of
services enabling future support of new capabilities without the need for service-specific hardware. Using SPCs on
all services ensures that no resources are idle, based on specific services being used, maximizing the utilization of
equipped hardware.
The scalability and flexibility of the SRX5000 and SRX3000 lines of services gateways are supported by equally
robust interfaces. The SRX Series high-end line employs a modular approach to interfaces where the gateway can be
equipped with a flexible number of input/output cards (IOCs).
With the IOCs sharing the same interface slot as the SPCs, you can configure the gateway to support the ideal
balance of processing, input, and output. Hence, you can tailor each deployment of the SRX Series to specific
network requirements. With this flexibility, you can configure the SRX5800 to support more than 400 gigabit ports,
with choices of Gigabit Ethernet or 10-Gigabit Ethernet.
The feature integration on the SRX Series is enabled by the Junos OS. By combining the routing heritage of the Junos
OS and the security heritage of ScreenOS, the SRX Series is equipped with a robust list of features that include
firewall, intrusion detection and prevention (IDP), denial of service (DoS), Network Address Translation (NAT), and
quality of service (QoS).

SRX Series High-End System Components

The SRX Series line of high end systems includes the following integral components:
• Input/output card (IOC): To provide the most flexible solution, the SRX Series employs the same
modular architecture for SPCs and IOCs. With the flexibility to install an IOC or an SPC on a given slot,
the SRX Series can be equipped to support an ideal balance between interfaces and processing
capabilities.
• Network Processing Card (NPC): To ensure maximum processing performance and flexibility, the
SRX3000 line utilizes NPCs to distribute inbound and outbound traffic to the appropriate SPCs and
IOCs, to apply QoS, and to enforce DoS and distributed DoS (DDoS) protections. In the SRX5000 line,
the NPC is integrated into the IOC. Note that a minimum of one NPC must be installed in platforms in
the SRX3000 line to ensure proper functionality.
• Services Processing Card (SPC): SPCs are designed to process all available services on the gateway.
Without the need for dedicated hardware for specific services or capabilities, no instances exist in
which a piece of hardware is taxed to the limit while other hardware is sitting idle. All the processing
capabilities of the SPCs are designed to process all configured services on the gateway. Note that a
minimum of one SPC must be installed in an SRX Series high-end system to ensure proper functionality.
• Switch Control Board (SCB): The SCB monitors and controls system functions and provides the
interconnections to all the IOCs within a chassis through the switch fabrics integrated into the SCB. At
least one SCB is required for the system to function. Two or three SCBs increase capacity or provide
redundancy, depending on the specific platform.
• Routing Engine (RE): The RE is an Intel-based PC platform that runs the Junos OS. Software processes
that run on the RE maintain the routing tables, manage the routing protocols, control some chassis
components, and provide the interface for system management and user access to the device.
For more information on specific SRX Series high-end system models and hardware, visit the Juniper Networks Web
site for technical publications at http://www.juniper.net/techpubs.
Physical Packet Flow for High-End Security Platforms
The graphic illustrates physical packet flow through a high-end security platform running the Junos OS. The packet
flow coverage includes the SRX5000 and the SRX3000 line of products.

Physical packet flow through a high-end security platform proceeds through the following sequence of steps:
1. A packet enters the security platform through the IOC.
(Step 1.5: Oversubscription control applies at the IOC.)
2. The packet traverses the switch fabric from the IOC to the NPC. (In the SRX5000 line of products, the
NPC integrates with the IOC.) The NPC performs a flow lookup. If the packet belongs to an existing flow,
the NPC forwards the packet to the SPC associated with the packet’s session. If the flow does not
currently exist, the NPC installs a new session for the flow and assigns the flow to an SPC for
processing. The NPC also performs CoS, policing, and shaping.
3. The packet traverses the switch fabric to its associated SPC, where security processing and forwarding
or routing occurs.
4. The packet traverses the switch fabric back to an NPC where additional packet processing such as
shaping and CoS occurs.
5. The packet traverses the switch fabric to the IOC associated with the egress interface and travels to the
attached physical medium.
SRX Series Branch Devices
Juniper Networks SRX Series Services Gateways for the branch provide essential capabilities that connect, secure,
and manage workforce locations sized from handfuls to hundreds of users. By consolidating fast, highly available
switching, routing, security, and applications capabilities in a single device, enterprises can economically deliver new
services, safe connectivity, and a satisfying end user experience.
SRX Series for the branch operates with the Junos OS, the proven operating system used by core Internet routers in
all of the top 100 service providers around the world. The rigorously tested carrier-class routing features of IP version
4 (IPv4)/IP version 6 (IPv6), OSPF, BGP, and multicast have been proven in over 10 years of worldwide deployments.
SRX Series Services Gateways for the branch provide perimeter security, content security, access control, and
network-wide threat visibility and control. Best-in-class firewall and VPN technologies secure the perimeter with
minimal configuration and consistent performance. By using zones and policies, even new network administrators
can configure and deploy an SRX Series branch device quickly and securely. Policy-based VPNs support more
complex security architectures that require dynamic addressing and split tunneling. For content security, SRX Series
for the branch offers a complete suite of Unified Threat Management (UTM) services consisting of intrusion
prevention system (IPS), antivirus, antispam, Web filtering, and data loss prevention through content filtering to
protect your network from the latest content-borne threats.
Select models feature Content Security Accelerator for high-performance IPS and antivirus performance. Junos
security platforms for the branch integrate with other Juniper Networks security products to deliver enterprise-wide
unified access control and adaptive threat management. These capabilities give security professionals powerful
tools in the fight against cybercrime and data loss.
Branch Platform System Components

The SRX Series line of Junos security platforms include the following integral components:
• Multi-core processing unit: The processing unit uses multiple hardware threads to provide data plane
services including security services and control plane services to the branch device. The SRX branch
line of platforms utilizes a system-on-a-chip (SOC) multi-core processor that provides the control and
data plane functions as well as additional services such as Ethernet controller technology and a
cryptographic engine.
• Physical Interface Modules (PIMs): The SRX Series line of branch and enterprise devices provide various
media interfaces known at PIMs. The media support includes 10/100 Ethernet, 10/100/1000
Ethernet, Gigabit Ethernet, T1/E1, T3/E3, ISDN, serial, ADSL and G.SHDSL interfaces, depending on
the model. Some SRX Series branch models also contain an ExpressCard slot for utilization with a 3G
wireless card to serve as a backup for primary interfaces. Select models contain Power over Ethernet
(PoE) enabled ports.
• Services and Routing Engine (SRE): The SRE, a field replacable unit in the SRX650, houses the
processing unit and provides processing power for security services; routing protocol processes; and
other software processes that control the services gateway interfaces, some of the chassis
components, system management, and user access to the device.
For more information on specific Junos security platform branch models and hardware, visit the Juniper Networks
Web site for technical publications at
http://www.juniper.net/techpubs.
Physical Packet Flow for Branch Security Platforms
In SRX Series branch gateways, control and data plane separation is maintained using multiple threads on multiple
cores within the processor. One hardware core is used for control plane functions. Packets ingress the device
through built-in ports or PIM ports and pass to an Ethernet switch, which acts as the switch fabric for the device. In
SRX Series branch devices, local switching occurs at the switch so that the CPU or the NPU is not taxed with switched
traffic. As a result, security services such as security policy and IDP are not available with locally switched traffic. The
switch performs CoS classification and traffic policing. It then passes non-locally switched packets to the processor
where security services, routing lookup, and forwarding lookup is performed. SRX branch devices then send egress
packets to the appropriate egress port by means of the switch.

Depending on the device type, the CPU might perform hardware acceleration and cryptographic acceleration. Some
branch devices are equipped with a separate regular expression (REGEX) content processor to provide
hardware-based pattern matching for IDP and antivirus acceleration.
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 OS for Security Platforms Merges Routing and Security

The new features of the Junos OS for 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.
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 OS for security
platforms. We discuss these features later in this material.
Junos Elements
SRX 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 OS for security platforms is session-based forwarding,
thereby resulting in a strong suite of security features.

Packet-Based Junos Forwarding

The Junos OS 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-Web—the Junos OS-based graphical user interface (GUI).
Session-Based Forwarding
The Junos OS for security platforms leverages ScreenOS software’s 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 OS for
security platforms is 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. The
Junos OS for security platforms adds a bundle of high-security features to the regular features of a router, including
stateful firewall, VPNs, NAT, ALGs, and IDP.
Control Plane
The 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 OS for security platforms deploys these features along with well-known, traditional Junos features.
Data Plane
The 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
determination—source 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 packet’s incoming zone by the interface through which it arrives. The
software also determines the packet’s 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 Maintenance
When 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 Cleanup
If 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 Run-Time Changes Propagation

The flow module is responsible for propagating any run-time 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
run-time changes always propagate into the session. Security policy run-time changes might propagate into the
session in progress, based on the corresponding security policy configuration.

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 on
the graphic. 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

Answers
1.
Traditionally, routers process packets on a per-packet basis.
2.
Traditionally, firewalls process packets based on stateful flows.
3.
Junos OS for 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.

Chapter 2: Zones

• Zones and their purpose;
• Types of zones;
• Application of zones;
• Configuring zones; and
• Monitoring zones.
Zone Definition
A 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 Platform

Zones 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.
Zones • Chapter 2–1

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 session—source IP address, destination IP address,
source port number, destination port number, protocol number, and a session token.
This material focuses on defining, configuring, and monitoring zones.
Zones and Interfaces

You 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 zone’s 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@host# commit check
[edit security zones security-zone trust]
'interfaces ge-0/0/2.0'
Interface ge-0/0/2.0 already assigned to another zone
error: configuration check-out failed
[edit]
lab@host# 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 options
[edit]
user@host# commit check
[edit security zones security-zone untrust]
Chapter 2–2 • Zones

'interfaces ge-0/0/2.0'
Interface ge-0/0/2.0 must be in the same routing instance as other
interfaces in the zone
One exception to the rule exists when all interfaces are assigned to one zone using the interface all
configuration option. In this case, interfaces can belong to multiple routing instances.
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 categories—user-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 Zones
Security 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 Zones
Functional 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 Zone
Currently there is only one system-defined zone, the Null Zone. By default, an interface belongs 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.
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 Configuration
In branch devices’ factory-default configuration, two security zones are defined—trust 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 subsequent material. 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 Procedure

Zone configuration involves the following steps:
• Define a security or a functional zone;
• Add logical interfaces to the zone; and
• 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 zone’s
interfaces destined for the device is blocked.
Configuration Mode
To define a zone you must enter configuration mode, as illustrated on the graphic.
Defining a Zone Type

Once you enter the configuration mode, you can define a zone type. Recall that you can configure only two types of
zones—functional, 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.
Functional Zone Specifics

The following are two important configuration characteristics of the functional zone:
1. You can define only one type of functional zone—management; and
2. The functional zone does not have a user-defined name.
Adding Logical Interfaces to the Zone

Now you are ready to add logical interfaces to the zone. The graphic 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 1

Without 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. By default, all outbound traffic originating from the device is always allowed.


When specifying types of traffic permitted into a Junos security platform, you use some combination of
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@host# 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@host# set security-zone HR host-inbound-traffic protocols ?
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
nhrp Next Hop Resolution Protocol
ospf Open Shortest Path First
pgm Pragmatic General Multicast
pim Protocol Independent Multicast

rip Routing Information Protocol

router-discovery Router Discovery
rsvp Resource Reservation Protocol
sap Session Announcement Protocol
vrrp Virtual Router Redundancy Protocol

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 on
the graphic, only HTTP system services are allowed into interface ge-0/0/1, 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 graphic shows an example of zone configuration. What types of traffic are allowed into the specified zone and
interfaces?
The graphic shows another example of zone configuration. What types of traffic are allowed into the specified zone
and interfaces?

The graphic shows the third example in this series. What does this configuration do?
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 interfaces. In addition, the command provides information on flow statistics through the interface.
Monitoring Traffic Permitted Into Interfaces: Part 2
The graphic provides the continuation of the output from the previous page.
Review Questions
Answers
1.
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 OS—user-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 facilitates transit packets and packets to the device itself. The functional zone facilitates 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.

Chapter 3: Security Policies

• 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.
Security Policies • Chapter 3–1

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 material, 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 on 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 graphic.
Chapter 3–2 • Security Policies

host-inbound-traffic Examination
If the destination of traffic is the device’s 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.
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 on the graphic 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 next. 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@host# set default-policy permit-all
[edit security policies]

user@host#
Factory-Default Security Policies

The 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 device’s interfaces are separated into three security zones—private, 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 on 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 flows—source 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 Configurations

Like any other Junos configuration stanza, you can delete, deactivate, activate, insert, annotate, and
copy security policies.
Security Policy Contexts

When defining a policy, you must associate it with a source zone, or incoming zone—named the from-zone. Also, you
must define a destination zone, or an outgoing zone—named 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 traffic—intrazone and interzone—through the use of security policies.
Security Policy Components

Within 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
Thread Management (UTM) feature for branch devices, and firewall authentication.
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 will not allow you to
commit the configuration.

Creating Address Book Entries
The graphic 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.
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.
user@host> top 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 sessions—not to existing ones.
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 Actions

Each 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 Traffic

For 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.
Advanced Permit Settings

Among the policy actions mentioned on the previous section, 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 “Firewall User Authentication.”
If a policy associates with a preconfigured IPsec VPN tunnel, the tunnel creation occurs dynamically upon the receipt
of the first packet that matches such a policy. The policy-based IPsec VPN can be one of two types—IKE or manual.
We discuss IPsec VPNs in more detail in “IPsec VPNs.”
A policy can associate with an IDP policy. IDP policies inspect traffic and enforce various attack detection and
prevention techniques. We discuss IDP in more detail in “Introduction to IDP”.
In branch devices only, a policy can also associate traffic with UTM features such as antivirus, content filtering, and
Web filtering.
Policy Components Summary
The following is a summary of the policy components:

• A security policy is positioned within the from-zone and the to-zone direction of traffic within
configuration;
• Each policy has a set of matching conditions;
• Each policy has a set of actions that the system performs upon success of all matching conditions;
• Many security policies within the same direction of the flow can exist; and
• Policy order is important, because policies execute in the order of their appearance in the configuration
file.
Control Plane Logging
The Junos OS logs control plane events either locally or to an external syslog device. Locally stored logs are stored on
the Routing Engine under the /var/log directory; you can view them by using the show log log-name
operational mode command. To configure logs to be sent to an external syslog server, use the host configuration
option. The example on the graphic shows the control plane logging statements present in a factory-default
configuration.
Branch Device Data Plane Logging
Data plane logging in Junos security platforms for the branch can be stored locally or on an external system log
(syslog) server. Use the session-close and session-init configuration options within a security policy to log
the start and close of sessions matching a policy. We suggest to use only session-close on production devices.
Logging both session-close and session-init will cause high CPU utilization on some SRX Series devices for
the branch.
The graphic illustrates a sample log file configuration for branch devices. Logs are stored locally in the /var/log
directory when designated with a filename. To send logs to an external device, use the host IP address configuration
option.

The default facility and severity for data plane session logging is user info. To enable a Network and Security
Manager (NSM) device to be able to retrieve logs, name the log file default-log-messages, as shown on the
graphic, and include the structured-data configuration option.
High-End SRX Series Data Plane Logging
Data plane logging in high-end SRX Series devices can go to an external syslog device. The Junos OS supports limited
local data plane logging because of the high volume of session handling that a high-end SRX Series device supports.
The graphic illustrates the configuration of data plane logging for high-end SRX Series devices.
Currently, the Junos OS supports one stream of logging traffic. Supported collection devices include UNIX
syslogd-based servers and the Juniper Networks Series Security Threat Response Manager (STRM).
Logging Sessions in Security Policy
Use the session-close and session-init configuration options to log the start and close of sessions
matching a policy. The graphic illustrates the configuration of the policy log action.

Collecting Security Policy Statistics

Use the count security policy action to collect statistics and make them available using operational show
commands. The count security policy action is not necessary to enable statistics collection in security policy logs.
Logs containing session-close messages contain statistics by default.
Operational Monitoring Commands
Various show commands are available for monitoring the application of security policy. The show security
policies command allows you to view details about an applied policy such as the policy index number, policy
matching conditions, and policy actions. Use the detail command option to view statistics associated with policy
counters.
The show security flow session command displays active sessions on the device and each session’s
associated security policy. Note that this command output is categorized per Services Processing Unit (SPU)
application-specific integrated circuit (ASIC). The following output is from a services gateway containing two services
processing cards (SPCs) and therefore, four total SPUs. Only one session is active on the services gateway:
user@host> show security flow session
0 sessions displayed
Session ID: 210000935, Policy name: permit-ftp/5, Timeout: 1768

In: 10.100.0.2/50054 --> 10.200.1.2/21;tcp, If: ge-1/2/1.10
Out: 10.200.1.2/21 --> 10.100.0.2/50054;tcp, If: ge-1/0/1.40

Tracing Security Policy
The configuration shown on the graphic enables the tracing of security policy evaluation and sessions on a Junos
security platform. Use the packet-filter configuration option to log only details concerning selected sessions.
Note that because of the architectural design of Juniper Networks security and routing platforms, you can enable
reasonably detailed tracing in a production network without negative impact on overall performance or packet
forwarding. However, a good practice would be to deactivate traceoptions when not troubleshooting the device
to reduce the impact on system resources.
Policy Scheduling
A policy scheduler is a method for scheduling a policy execution for a specified duration or a set of durations. A policy
scheduler is optional. A scheduler supports system time updates either through manual configuration or through the
Network Time Protocol (NTP) by synchronizing itself with the time changes.

Rules for Scheduling

The following rules apply to policy scheduling:
• An individual policy can have only one scheduler applied;
• Multiple policies can use the same scheduler; and
• A scheduler must be referenced in a policy to become active. Without a defined scheduler within a
policy, the policy is always active.
Security Policy Scheduler Components

A security policy scheduler provides you with the flexibility to identify the start date and time and stop date and time
for policy enforcement. In particular, the scheduler components include the following:
• Slot schedule: This component consists of the start date and time and the stop date and time of policy
enforcement; and
• Daily schedule: This component consists of the start time, the stop time, the all-day option, and the
exclude option.
Policy Scheduler Details
A policy scheduler turns on recurrently or once at the specified time. Recall that a policy scheduler activates and
deactivates a policy according to the scheduled time, which you configure. Once you create the scheduler, you must
apply it to a policy. The default behavior of a policy is to execute at all times.

Optionally Applying the policy-rematch Statement
The default behavior of the Junos OS is to not disturb sessions in progress when you make configuration changes to
security policies. For example, you can modify an address field or modify the actions of a policy used for session
examination. By default, because a session was pre-established, it continues to be operational without any
interruptions. You can change that default behavior by enabling the policy-rematch statement. Once you enable
the statement, every time a configuration change to a policy occurs, it reflects in the sessions in progress.
Configuration changes, such as source addresses, destination addresses, and application changes, cause policy
re-evaluation as the system performs a policy lookup. If the newly matched policy is not the policy referred to by the
session, the session clears. If an IPsec VPN change occurs, the Junos security platform clears the session.
The following list explains the actions that the Junos OS performs on impacted sessions in progress based on
whether the policy-rematch flag is enabled or disabled.
• When the policy-rematch flag is enabled:
– The software inserts a policy: no impact;
– The software modifies the action field of a policy from permit to either deny or reject: all
existing sessions are dropped; and
– The software modifies some combination of source address, destination addresses, and
applications fields: the Junos OS re-evaluates policy lookup.
• When the policy-rematch flag is disabled (default behavior):
– The software inserts a policy: no impact;
– The software modifies the action field of a policy from permit to either deny or reject: all
existing sessions continue; and
– The software modifies some combination of source address, destination addresses, and
applications fields: all existing sessions continue unchanged.
Note that irrespective of the value of policy-rematch policy flag, deletion of the policy causes the device to drop
all impacted existing sessions.

Case Study: Creating Policies
The next series of graphics presents an example and configurations for a setup in which two zones exist—HR and
Public. The private PCs A and B, located in the HR Zone, must communicate with Server C in the Public Zone using a
custom application set. Restrictions are placed on the rest of the 10.1.0.0/16 network that are logged and counted.
Case Study: Entering Host Addresses into the HR Zone
The graphic presents the configuration that adds host addresses belonging to zone HR. The hosts include PC_A and
PC_B, whose addresses are 10.1.10.5 and 10.1.20.5 respectively. The rest of the 10.1.0.0/16 subnet is also
defined, which is named all-10-1 in the address book. In addition, the PC_A and PC_B addresses are grouped
into an address set named HR_PCs.

Case Study: Entering Host Addresses into the Public Zone
The graphic presents the configuration that adds host addresses belonging to the Public Zone. The Public Zone has
Server_C, whose address is 1.1.70.250. The rest of the 1.1.7.0/24 subnet is also defined, named all-1-1-70
in the address book. In addition, an address set, named address-Public, consists of the Server_C address for
now.
Case Study: Adding New Applications
The graphic presents the configuration of a new application, HR-telnet, for the HR Zone. In the configuration,
source-port is an optional setting for an application. The configuration shows that the new application is added
under the applications stanza. In addition, the new application set, named HR-Public-applications
consists of two predefined applications, junos-ftp and junos-ike, and the newly defined HR-telnet
application.

Case Study: Creating Policy Entries: Part 1
We must now define the policies from the HR Zone to the Public Zone. We must define two policies. The purpose of
the first one, named HR-to-Public on the graphic, is to permit traffic from the HR Zone to Public Zone, provided
that its source address belongs to the address set HR_PCs, its destination address belongs to the address set
address-Public, and its application is part of HR-Public-applications. Matching traffic is logged and
counted.
Case Study: Creating Policy Entries: Part 2
The graphic shows the definition of the next policy for the same direction—from the HR Zone to the Public Zone. This
policy denies packets, logs, and counts packets for only the following cases:
• The source address of the packet must be all-10-1;
• The destination address must be all-1-1-70; and
• The application must be junos-ftp.

If a packet does not match the previous policy—HR-to-Public—or—otherHR-to-Public, the default security
policy examines it, resulting in the device dropping it.
Case Study: Optionally Creating a Scheduler
We now create a scheduler named schedulerHR. Its purpose is to activate policy HR-to-Public on a daily
basis, from 9:00 am until 5:00 pm, excluding weekends (Saturday and Sunday). Because HR-to-Public is the
only policy that permits some traffic, application of the scheduler results in the Junos security device blocking all
traffic completely on a daily basis after 5:00 pm and on weekends.
Case Study: Optionally Applying a Scheduler
The graphic shows the application of the previously defined scheduler schedulerHR to the HR-to-Public
policy.

Check Your Knowledge
What are the answers to the questions posed on the graphic?
Case Study: Monitoring Security Policies: Part 1
The graphic shows the output of the show security policies detail command for one of the policies in the
case study. We removed some content for brevity.

Case Study: Monitoring Security Policies: Part 2
The graphic shows an example of the data plane log output resulting from live FTP traffic transiting the case study’s
security policy. We captured the output on an external UNIX syslogd-enabled server.
Review Questions
Answers
1.
The basic components of a policy are: (1) policy name; (2) source zone and destination zone; (3) matching conditions,
consisting of one or many source addresses or sets, one or many destination addresses or sets, one or many applications or
sets; and (4) actions.
2.
The default action for every policy set is to deny traffic.
3.
The policy scheduler enables the user to dynamically activate or deactivate a security policy. If you deactivate a policy, and no
other matches are found, the default security policy examines the packet.
4.
You can reorder policies using the Junos insert command.

Chapter 4: Firewall User Authentication

• The purpose of firewall user authentication;
• Implementing pass-through authentication;
• Implementing Web authentication;
• Using client groups; and
• Monitoring firewall user authentication.
The Purpose of Firewall User Authentication
Firewall user authentication provides another layer of protection in the network on top of security zones, policies,
and screens. With firewall authentication, you can restrict or permit users individually or in groups. Users attempting
to access a network resource receive a prompt from the Junos operating system for a username and password even
if a security policy is in place permitting the traffic.
Users can be authenticated using a local password database or using an external password database. The Junos OS
supports RADIUS, Lightweight Directory Access Protocol (LDAP), or SecurID authentication servers.
The example on the graphic illustrates a user (Host A) attempting to access a network resource belonging to the
Public Zone. With firewall user authentication configured, the user must first authenticate with the Junos security
platform before accessing the resource. In this example, the device can query an external authentication server to
determine the authentication result. The security policy must also allow traffic flow. Once the user receives
Firewall User Authentication • Chapter 4–1

authentication, subsequent sessions from the same source IP address bypass firewall user authentication. This
behavior is especially important when considering the usage of firewall user authentication for a network that might
have source-based Network Address Translation (NAT) employed.
Pass-Through Authentication
Two types of firewall user authentication are available—pass-through or Web authentication. Pass-through
authentication must first be triggered by Telnet, FTP, and Hypertext Transfer Protocol (HTTP) traffic. In this type of
firewall authentication, the user initiates a session to a remote network device or resource. If traffic matches the
security policy configured for pass-through authentication, the SRX Series Services Gateway intercepts the session.
The user receives a prompt for a username and password. If the authentication is successful, subsequent traffic
from the same source IP address is automatically allowed to pass through the device, provided it matches the
applied security policy.
Web Authentication
Web authentication is valid for all types of traffic. With Web authentication configured, users must first directly
access the Junos security platform using HTTP. The user enters the address or hostname of the device into a Web
browser and then receives a prompt for a username and password. If authentication is successful, the user can then
access the restricted resource directly. Subsequent traffic from the same source IP address is automatically allowed
access to the restricted resource, as long as security policy allows for it.
Local Authentication
The Junos OS supports local authentication on the Junos security platform itself as well as RADIUS, LDAP, and
SecurID external authentication servers. The local password database supports authentication and authorization.
RADIUS Authentication
The Junos OS supports Juniper Network’s Steel-Belted Radius for authentication as well as authorization. The Junos
security platform acts as a RADIUS client and communication uses UDP. RADIUS uses a shared secret key to encrypt
user information during the exchange.
LDAP Authentication
An LDAP server is another form of external authentication server. The Junos OS supports authentication only when
utilizing an LDAP server. The Junos OS is compatible with LDAP Version 3 and Microsoft Windows Active Directory.
Chapter 4–2 • Firewall User Authentication

SecurID Authentication
An RSA SecurID server can be used for external authentication. This method allows users to enter either static or
dynamic passwords as credentials. A dynamic password is a combination of a user’s PIN and a randomly generated
token that is valid for a short period of time. The Junos OS supports SecurID servers for authentication only and does
not support the SecurID challenge feature.
Pass-Through Authentication
The graphic illustrates the process used for pass-through firewall authentication. A user attempts to connect directly
to a remote network resource using either Telnet, HTTP, or FTP. The Junos security platform intercepts the first packet
and stores it in memory. The device prompts the end user for a username and password. If authentication is
successful, a configurable banner displays to the user, and the original buffered packet travels to its destination. The
Junos OS allows subsequent traffic from the same source IP address until the user is idle for 10 minutes. At this
point, authentication must be performed again for further traffic to pass through the device. The default idle timeout
of 10 minutes is configurable as shown:
[edit access profile profile-name]
user@host# set session-options client-idle-timeout ?
<client-idle-timeout> Time in minutes of idleness after which access is
denied

Creating an Access Profile
The graphic provides an example of a basic access profile. This example shows the configuration of a user-defined
profile name. One or more clients are configured within the profile, representing end users. The client-name
represents the username. The password is entered in plain-text format but displays in encrypted form when you view
the configuration.
Associating the Access Profile with an Authentication Type
Once an access profile has been defined, it must be associated with pass-through firewall authentication. The
graphic shows a basic example of this configuration. The Junos OS also allows you to set a customized banner that
will display to the end user. The Junos OS can display an initial login banner, a successful authentication banner, and
a failed authentication banner when configuring pass-through authentication.

Apply Pass-Through Authentication as Policy Action
Enable pass-through and Web authentication using security policies. To be subject to firewall user authentication,
traffic must align with the policy’s matching conditions and have an extended action of permit, specifying the type of
firewall authentication to use. The graphic shows an example of applying pass-through firewall authentication to a
security policy.
Web Authentication
The graphic illustrates the process used for Web firewall authentication. A user that requires access to a remote
network resource must first access the Junos security platform directly using a Web browser. The device prompts the
end user for a username and password. If authentication is successful, a configurable banner displays and the user
gains permission to access the remote resource. The Junos OS allows subsequent traffic from the same source IP
address until the user is idle for 10 minutes. At this point, authentication must be performed again for further traffic
to pass through the device. The default idle timeout of 10 minutes is configurable as shown here:
[edit access profile profile-name]
user@host# set session-options client-idle-timeout ?

<client-idle-timeout> Time in minutes of idleness after which access is
denied
Enabling the HTTP Process
To use Web authentication, the SRX Series device must initiate the httpd process. The graphic highlights the required
configuration to enable this system process for the device. The highlighted configuration allows HTTP access for Web
management using the J-Web user interface and also allows for the use of Web authentication. You can also
configure this feature to restrict access to an individual interface or a group of interfaces. The security zone
containing the interface to be used for Web authentication (or for the J-Web user interface) must allow HTTP traffic
as host inbound traffic.
Enabling Interface for Web Authentication
The interface that users access for Web authentication must be enabled for authentication. The graphic illustrates a
sample configuration for enabling Web authentication on the ge-0/0/0 interface. We recommend using a secondary
IP address as the Web authentication address. The Web authentication address must be in the same subnet as the
primary interface address. Use the preferred configuration option to ensure that traffic sourced from this
interface continues to use the primary address as its source address.

Creating an Access Profile
Web authentication can use the same profile as pass-through authentication. The example on the graphic shows the
configuration of a user-defined profile name. One or more clients are configured within the profile representing end
users. The client-name represents the username. The user enters the password in plain-text format but it displays in
encrypted form when you view the configuration.
Associating the Access Profile with an Authentication Type
The access profile must associate with Web authentication using the same configuration structure as pass-through
authentication. The graphic shows a basic example of this configuration. The Junos OS also allows you to set a
customized banner that will display to the end user. Web authentication supports a customized banner for
successful authentication only.
Applying Web Authentication as Policy Action
Pass-through and Web authentication are enabled using security policies. To be subject to firewall user
authentication, traffic must align with the policy’s matching conditions and have an extended action of permit,
specifying the type of firewall authentication to use. The graphic shows an example of applying Web firewall
authentication to a security policy.

A Cleaner Method of Web Authentication
Directly accessing the device through a browser before gaining access to a remote resource is burdensome. To
alleviate this burden, the Junos OS allows Web redirection. The graphic illustrates the configuration of Web
redirection. With Web redirection enabled, the device responds to the user device with an HTTP redirect message,
which tells the user device to use HTTP to access the Junos security platform at a particular address. The Junos OS
uses the address of the interface on which the initial user request was received. You must enable Web
authentication for this interface and for the system itself, just as you would for standard Web authentication.
Using Client Groups
A client group is a list of groups associated with a client. Client groups allow for easier management of multiple
firewall users. Security policy references client groups in the same manner in which it references individual clients.
The graphic shows a simple conceptual example of using client groups to manage multiple users. The next two
graphics utilize this example for illustrating the configuration of client groups.

Adding Client Groups to a User
The graphic provides an example configuration of three users associated with various groups. A number of groups
(contained in square brackets in the example configuration) represent a client group. Groups are not configured
elsewhere, thus the utilization of the tab key can be beneficial to ensure that you do not inadvertently create extra
groups.
Configuring a Policy to Use Client Groups
Once client groups have been organized, groups can be referenced in a security policy with firewall authentication.
Groups can be used in place of individual clients. The graphic illustrates the use of a client group in a security policy.
In this example, Group-A from the previous graphic is subject to pass-through authentication.

Which Users Have Telnet Access to the Engineering Resource?

In the referenced example configuration, firewall authentication is enabled and the security policy specifies only
client group Group-A. Client group Group-A associates with user1 and user2. Therefore, user1 and user2 have
access to the engineering remote network resource (if they authenticate successfully).
What if All Three Users Use the Same Source IP Address?

Firewall user authentication is based on the source IP address. As we discussed earlier in this material, once firewall
authentication is successful, subsequent sessions from the same source IP address are not subject to further
authentication within the idle timeout period. In this example, if user1 or user2 were to authenticate first, user3
would also be able to access the remote engineering resource.
Default Client Groups
The Junos OS allows the configuration of a default client group to serve as a catch-all for all users within an access
profile. This setup allows ease of management by categorizing users in access profiles. If a user or client does not
associate with a client group and a default client group exists, the user associates with the default client group. The
client group can consist of one or more groups.
Adding Servers to the Access Profile
You configure external authentication server details within an access profile. The Junos OS supports only one
external authentication server for access profiles, but you can use it in conjunction with the local password
database. You must specify an authentication order if you plan to use an external server. The Junos security platform
will try to authenticate with the first method listed. If the configuration does not list the password database in the
authentication order and the listed method of external authentication is unreachable, the Junos OS still consults the
local password database. However, if the listed external authentication method fails, the Junos OS does not consult
the local password database, denying user access.

Viewing the Authentication Table
The example on the graphic illustrates how to view the current authentication table. This table contains a list of users
and their associated access profiles. It shows the source IP address, source and destination security zones, the
authentication result, and the current age of the idle timer. You can also sort the authentication table by source IP
address or user ID by issuing the command with the address or identifier command options as shown in the
following output:
user@host> show security firewall-authentication users ?
<[Enter]> Execute this command
address Locate authentication entry by ip address
identifier Locate authentication entry by id
Viewing Authentication Table History
The graphic shows how to view a historical authentication table. This table keeps a record of firewall authentication
attempts in brief form, including date and time stamps. This command also supports the use of the address and
identifier command options.
Review Questions

Answers
1.
The Junos OS supports RADIUS, LDAP, and SecurID external authentication servers.
2.
In pass-through authentication, the user attempts to access the remote network resource directly, and the Junos security
platform intercepts the session to perform firewall authentication, while buffering the session. The buffered session is released
as long as authentication is successful. In Web authentication, the user must first access an IP address belonging to the Junos
security device using a Web browser; the authentication is performed using this HTTP session. The user can then proceed to
access the remote network resource as long as authentication is successful. FTP, Telnet, and HTTP traffic trigger pass-through
authentication, while an HTTP session must trigger Web authentication.
3.
A client group is a list of groups associated with a client. Groups can be used in security policies in place of individual clients
for ease of management.
4.
Use the show security firewall-authentication history command to view a history of firewall
authentication attempts.

Chapter 5: SCREEN Options

• SCREEN options and their meanings;
• Various types of attacks prevented by SCREEN options;
• SCREEN options advantages;
• Configuration of SCREEN options; and
• Applying and monitoring SCREEN options.
Networks Are Under Attack
Although basic network security issues have changed very little over the past decade, the network security
landscape has changed dramatically. Today’s IT professionals must still protect the confidentiality of corporate
information, prevent unauthorized access, and defend the network against attacks. They also face new challenges
as their networks become more complex and dynamic. The following list examines some of these issues:
• Ubiquitous Internet access: The growing availability of Internet access has made every home, office,
and business partner a potential entry point for an attack. The corporate network is vulnerable to
attacks that hackers can deliberately launch and from remote users logging onto the corporate network
SCREEN Options • Chapter 5–1

and unknowingly hiding an attack within their sessions. The trend of working at home and using a work
PC for personal use increases the possibility of dangerous and annoying attacks such as spyware,
phishing, and spam.
• Internal attacks: While stopping external attacks remains a constant challenge, the attacks that
originate from inside the network by employees are equally challenging. Internal attacks can range from
unauthorized server or resource access to a disgruntled employee destroying or stealing proprietary
information.
• Regulatory compliance: As new national and industry regulations emerge, security is a continual
emphasis. Whether the requirement is to encrypt all data or simply to protect it from unauthorized
access, complying with these new regulations complicates matters for you as a security administrator.
• Changing levels of trust: Remote employees, business partners, customers, and suppliers might have
different levels of access to corporate resources. You must take appropriate measures to protect the
corporate network at all these levels. While the number of applications to which remote users have
access through the demilitarized zone (DMZ) increases, companies are simultaneously trying to reduce
costs by minimizing the application instances between internal and external users. This approach
makes it necessary for security policies to accommodate application use by both groups.
Points of Vulnerability Equal Points of Control
The key to striking a balance between tight network security and the network access required by employees,
business partners, and customers is a layered security solution. A layered security solution gives you a complete set
of tools you can deploy to achieve end-to-end security from the remote site to the data center. If one layer fails, the
next layer stops the attack, limits the damage that might occur, or does both.
Layered security allows you to apply the appropriate level of resource protection to the various network entry
locations based upon your different security, performance, and management requirements. The following are
vulnerable points in the network:
• Remote access occurs when a user connects to the corporate network through a public or private
connection. The key security goal to pursue with remote access is the protection of content and user
identity as they traverse the network.
• Site-to-site communications, both employee and nonemployee, are the interactions between two offices
of any type or any size. The site-to-site security layers must protect resources at both sites from external
threats such as session hijacking, U-turn attacks, and Trojan or worm attacks launched from a trusted
Chapter 5–2 • SCREEN Options

PC that has been compromised. Internal attacks are increasingly common and can include
unauthorized server access, improper use of bandwidth, and planting of spyware.
• The network perimeter represents the point at which external traffic gains initial access to the network,
as well as the point through which internal traffic traverses the Internet. With the diversity of traffic that
the perimeter represents, the security solution must protect against the widest range of attacks using
an assortment of security layers that can include a VPN, denial of service (DoS) protection, a firewall,
antivirus scanning, an intrusion detection service (IDS), and possibly antispam scanning.
• At the heart of an enterprise is the network data center (or network core) where the applications and
data that drive day-to-day business reside. Financial, human resources, and manufacturing applications
with supporting data represent the company crown jewels and, if compromised, can sink even the most
stable enterprise. The core network security layers must protect these business-critical resources by
preventing unauthorized user access, containing internal attacks launched by disgruntled employees,
and protecting against application-level attacks.
• In conjunction with applying layered security to the network core, IT departments are increasingly
deploying security internally on LANs to prevent unauthorized user access to network resources, to
encrypt and decrypt communications, and to contain damage that might occur if an attack succeeds.
Attack Detection System: SCREEN Options

The most obvious element of the Junos operating system for security platforms is basic access control using security
policies. These policies define who and what has access to the network. The Junos OS uses stateful inspection to
protect the network from malicious content. With stateful inspection, Junos security platforms collect data such as
source and destination IP addresses, source and destination port numbers, and packet sequence numbers from
TCP and UDP pseudosessions. The device then maintains this data in state tables for future use in analyzing traffic.
Through the deployment of custom security zones, you can use the Junos OS not only to protect the perimeter of your
network, but also to provide segmentation of your internal infrastructure. Used internally, SRX Series Services
Gateways provide additional layers of access control to protect against the organization's sprawling definition of
authorized user.
Using SCREEN options, Junos security platforms can protect against more than 30 different internal and external
attacks, including SYN flood attacks, UDP flood attacks, and port scan attacks. DoS attack protection leverages
stateful inspection to look for and then allow or deny all connection attempts that require crossing an interface on
their way to and from the intended destination.
When applied, SCREEN options pertain to traffic at its entry point. The Junos OS applies SCREEN checks to traffic
prior to the security policy processing, thereby resulting in less resource utilization.

Review: Packet Flow
Before discussing SCREEN options, we revisit packet flow through a Junos security platform. Note that SCREEN
processing occurs before any packet processing, which results in fewer resources used and better protection of the
Junos security platform itself.
Stages of an Attack
To understand SCREEN option configuration, we must first discuss the stages of network attacks and the types of
network attacks. A network attack consists of three major stages. In the first stage, the attacker performs
reconnaissance on the target network. This reconnaissance might consist of many different kinds of network probes.
In this information-gathering phase, the attacker works to gather information about the target network, any open
ports, and the operating systems in use.
In the second stage, the attacker launches an attack at the target network. To protect themselves, attackers must
also conceal the origin point of the attack and attempt to remove any evidence that an attack took place.
Depending on the type of attack, a third phase can occur. After infiltrating a trusted machine, the attacker can use
that machine as a point of origin for further invasion of the network. Traffic now appears to originate from the trusted
system, which might not be subject to the same security scans as an outside system.
IP Address Sweep
Attackers can better plan their attack when they first know the layout of the targeted network, possible entry points,
and constitution of their victims.
An address sweep occurs when one source IP address sends Internet Control Message Protocol (ICMP) packets to
different hosts. The purpose of this scheme is to send traffic to various hosts in hope that one replies, thus revealing
an address to target.
Port Scanning
A port scan occurs when one source IP address sends IP packets containing TCP SYN segments to different ports at
the same destination IP address. The purpose of this scheme is to scan services in hope that one port will respond,
thus identifying a service to target.

IP Options
RFC 791, “Internet Protocol,” specifies a set of options to provide special routing controls, diagnostic tools, and
security. RFC 791 states that these options are “unnecessary for the most common communications” and, in reality,
they rarely appear in IP packet headers. When they do appear, they are frequently being put to illegitimate use.
OS Probes
An attacker might try to probe the targeted host to learn its operating system. Because TCP standards do not dictate
how to respond to anomalous traffic, different operating systems respond differently to anomalies. The response to
the anomaly gives the attacker information about the type of operating system running on a given host.
Evasion Techniques
Whether gathering information or launching an attack, the attacker generally tries to avoid detection. Although some
IP address and port scans are blatant and easily detectable, more advanced attackers use a variety of means to
conceal their activity.
Forms of Denial of Service Attacks
The intent of a DoS attack is to overwhelm the targeted victim with a tremendous amount of fake traffic so that the
victim becomes so preoccupied processing fake traffic that it is unable to process legitimate traffic. In the case of a
router or firewall device, the goal of a DoS attack is to fill up the device session table so that no new sessions can be
established. An attacker can also launch a network DoS or a DoS targeting various operating systems.
This material explains each of the attacks and the ability of the Junos OS to handle these attacks.

Types of Attacks: Suspicious Packets
Attackers can craft packets to perform reconnaissance or launch DoS attacks. Sometimes the intent of a crafted
packet is unclear, but its crafted nature suggests that it is being put to an insidious use.
SCREEN Options—Best Practices
Prior to analyzing Junos SCREEN options in detail, we discuss best practice suggestions for SCREEN option use.
You should understand the applications and their behavior within your network before you begin implementing
features that might have an impact on legitimate traffic. Furthermore, you must understand the traffic patterns
traversing your network. To determine appropriate thresholds for limit-based SCREEN functions, you must first know
what is typical of your network. For example, if you want to enable SYN flood protection, you must first determine
what constitutes an acceptable number of connection requests. This determination requires a period of observation
and analysis to establish a baseline for typical traffic flows. You must also consider the maximum number of
concurrent sessions required to fill up the session table of the particular Junos security platform you are using. To
see the maximum number of sessions that your session table supports, use the CLI command show security
flow session summary. Remember the output of this command reports statistics for each Services Processing
Unit (SPU) separately.
You can use the alarm-without-drop statement, as illustrated on the graphic, to gather the traffic going to and
through your Junos security platform. The gathered information might help you to better understand your network’s
vulnerabilities. Typically, you want to deploy SCREEN options only in vulnerable zones.
IP Address Sweep and TCP Port Scan: The Attack

An address sweep occurs when one source IP address sends a predefined number of ICMP packets to various hosts
within a predefined interval of time. The purpose of this attack is to send ICMP packets, which are typically echo
requests, to various hosts, hoping that at least one host replies. Once attackers receive a reply, they uncover an
address, which becomes a target.
Port scanning occurs when one source IP address sends IP packets containing TCP SYN segments to a predefined
number of different ports at the same destination IP address within a predefined time interval. This attack attempts
to scan the available services hoping that at least one port responds, thereby identifying an attack target.
IP Address Sweep and TCP Port Scan: The Defense

The Junos OS internally logs the number of ICMP echo request packets from one remote source. You can set up a
threshold interval, ranging from 1000 to 1,000,000, measured in microseconds for those ICMP packets. The default
threshold value is 5000. By using the default settings, if a remote host sends ICMP echo request traffic to 10

addresses in 0.005 seconds (5000 microseconds), the Junos security platform flags that remote host as an address
sweep attacker. The flagging process results in the denial of all further ICMP echo requests from that host for the
remainder of the configured threshold time period.
For TCP port scanning protection, the Junos OS internally logs the number of different ports scanned from one
remote source. The configured threshold value is in microseconds, ranging from 1000 to 1,000,000. The default
threshold value is 5000 microseconds. The Junos OS flags the traffic as an attack when 10 ports are scanned within
the threshold value. Once port scanning detection triggers, the Junos OS silently drops all further packets from the
remote source for the remainder of the configured threshold time period.
IP Address Sweep and Port Scanning—SCREEN Options
The graphic illustrates an IP address sweep or port scanning attack. During an IP address sweep attack, the
attacker, using one source IP address, sends ICMP packets to different hosts in hopes that at least one host replies,
thereby uncovering an address to target.
During a port scanning attack, the attacker, using one source IP address, sends IP packets containing TCP SYN
segments to a defined number of different ports at the same destination IP address within a defined interval. The
attacker hopes that at least one port responds, thereby uncovering a service to target.
To block IP address sweeps or TCP port scans originating in a particular security zone, you must perform the
configuration illustrated on the graphic. Note that this configuration only defines the SCREEN option—it does not
activate it. To activate the SCREEN option, you must apply it within a security zone. We address this topic later in the
material.
IP Address Sweep and Port Scanning: The Attack

RFC 791 specifies a set of options within an IP packet, providing special routing controls, diagnostic tools, and
security. Within an IP packet header, these options come after the destination address field. Although the original
intent for these options was to enhance network functionality, most common communications do not require them.
As the Internet expanded and continues to expand, attackers have started abusing the options field of a packet,
causing problems to networks and network devices. An attacker can abuse the record route, timestamp, security,
and stream ID fields.

IP Address Sweep and Port Scanning: The Defense

To compensate for the vulnerability that these IP options fields create, the Junos OS tracks packets that have any of
these option fields used, flags them as a network reconnaissance attack, and records the event. You can view the
events in the SCREEN counters list for the ingress interface.
IP Options—SCREEN Options
The graphic illustrates an IP packet header, highlighting the options field. An attacker can misuse bits within the
options field to cause problems with networks. You can define SCREEN options to detect the IP options that an
attacker can use. These IP options fields include record route, timestamp, security, and stream ID. The Junos OS
flags an event in which a device configured with the appropriate SCREEN options receives a packet with any of these
IP options. The Junos OS marks the event as a network reconnaissance attack and records the associated ingress
interface.
The graphic illustrates the syntax for this SCREEN option definition. You can configure each of the options
independently. Note that this configuration only defines the SCREEN options—it does not activate them. To activate
the SCREEN options, you must apply them within a security zone. We address this topic later in the material.
Operating System Probes: The Attack

Prior to launching an exploit, an attacker might probe the targeted host, trying to learn its operating system. Various
operating systems react to TCP anomalies in different ways. With that knowledge, an attacker can decide which
further attack might inflict more damage to the device, the network, or both.
Operating System Probes: The Defense

The Junos OS configured with the appropriate SCREEN options blocks operating system probes by detecting any of
the following invalid TCP flag settings:
• Both SYN and FIN flags set;
• FIN flag set and ACK flag not set; or
• No flags set.
TCP traffic matching any of these criteria is immediately, and silently, dropped.

Operating System Probes—SCREEN Options
The graphic illustrates the TCP header, highlighting the SYN and FIN flags, which an attacker might use to launch the
attack. The graphic also illustrates the configuration of SCREEN options designed to block these probes. You
configure each statement independently as follows:
• To detect the condition when both SYN and FIN flags are set, use the syn-fin configuration option;
• To detect the condition when the FIN flag is set and the ACK flag is not set, use the fin-no-ack
configuration option; and
• To detect the condition when no flags are set, use the tcp-no-flag configuration option.
Note that this configuration only defines the SCREEN options—it does not activate them. To activate the SCREEN
options, you must apply them within a security zone. We address this topic later.
IP Spoofing: The Attack

IP address spoofing is one of the earliest and most well known attacks. An attacker simply inserts a fake source
address into the packet header source address field in an attempt to make the packet appear as if it is coming from
a trusted source.
IP Spoofing: The Defense

The Junos OS provides IP address spoofing detection with the help of forwarding table entries. The Junos OS
compares the source IP address of an incoming packet with the closest prefix match found in its forwarding table. If
the interface associated with that prefix is different from the ingress interface of the packet, the software concludes
that the packet has a spoofed source IP address and discards it. Once it detects IP spoofing, the Junos OS silently
drops all spoofed packets.

IP Spoofing Detection—SCREEN Option
The graphic illustrates an IP spoofing attack in which the attacker uses an IP address belonging to the range of IP
addresses within the private zone. The Junos OS compares the source IP address 168.10.10.1 of the incoming
packet with the closest match prefix found in its forwarding table, which is 168.10.10/24. It then detects that the
interface associated with prefix 168.10.10/24 is different from the ingress interface of the packet, which is ge-1/0/
0. The software concludes that the packet has a spoofed source IP address and discards it.
To set up the Junos IP spoofing SCREEN option, you must perform the configuration shown on the graphic. Note that
this configuration only defines the SCREEN option—it does not activate it. To activate the SCREEN option, you must
apply it within a security zone. We address this topic later.
IP Source Router Options: The Attack

Source routing allows users to specify the packet’s desired path when traversing a network. This feature provides
additional aid to users during network troubleshooting.
Unfortunately, over the years, attackers have started to abuse source route options. They use the fields to hide their
true address and access restricted areas of a network by specifying a different route.
IP Source Router Options: The Defense

Depending on the configuration, the Junos OS either blocks any packets with loose or strict source route options
settings, or detects those options as being set, and records them. If you choose to block the suspect packets, the
software silently discards the packets.

IP Source Route Options—SCREEN Options
Using the illustration shown on the graphic, we assume that network 3.3.3.0/24 checks for spoofed IP addresses.
The attacker, who is aware of this checking, wants to direct traffic through network 5.5.5.0/24. The attacker spoofs
the source address to be part of network 5.5.5.0/24, and by using the loose source option, directs the packet
through network 5.5.5.0/24. Because the packet came from the 5.5.5.0/24 network and has the source address of
that subnet, it seems to be valid. However, it has the loose source route option set. We also assume that you enabled
the SCREEN option that discards the packets with the source route option set. As a result, when the packet arrives at
the ge-1/0/0 interface, the Junos security platform rejects it.
To set up the Junos IP source route options SCREEN options, you must perform configuration as shown on the
graphic. You can configure each of the options independently. Note that this configuration only defines the SCREEN
options—it does not activate them. To activate the SCREEN options, you must apply them within a security zone. We
address this topic later.
Goals of DoS Attacks

If attackers discover a firewall, they might launch a DoS attack against it. In fact, many attackers consider the
successful DoS firewall attack to be equivalent to a network attack because a firewall under DoS stops sending any
traffic to and from a protected network.
Firewall and Router Device DoS Attacks

An attacker might use two methods in an attempt to immobilize a Junos security platform. Because the Junos OS for
security platforms is a session-based operating system in which each packet flow creates a session, DoS attacks
attempt to fill up the session table in the hope that the device will reach its session table limit. Attackers can use two
methods to fill up the session table: session table flood and SYN-ACK-ACK proxy flood.
Network DoS Attacks

A network DoS attack results in the flooding of many network resources with enormous amounts of some
combination of SYN, ICMP, and UDP packets. Depending on the learned intelligence information, an attacker might
target a specific host or a specific network segment for attacks. The Junos OS has the capability to mitigate those
attacks, which we discuss in the upcoming pages.

OS-Specific DoS Attacks

Should attackers identify an OS in use, they might launch an OS-specific DoS attack, focusing on one-packet or
two-packet kills. These attacks include the Ping of Death attack, the Teardrop attack, and the WinNuke attack. The
Junos OS has the capability to mitigate these attacks, which we discuss in the upcoming pages.
Firewall and Router Device DoS—Session Table Floods: The Attack
The graphic lists some of the forms that session table floods can take.
Firewall and Router Device DoS—Session Table Floods: The Defense

To control session table floods, the Junos OS offers the ability to set up a source-based session limit so that it can
prevent attacks such as the Nimda virus (which infects servers and then generates massive amounts of traffic from
those servers). By recognizing that all connection attempts originate from the same source IP address, the Junos
session table flood control also mitigates any attempts to fill up the session table of the attacked Junos security
platform.
In addition to the source-based session limit, the Junos OS offers the flexibility to limit the number of concurrent
sessions to the same destination IP address, which protects your device from a distributed denial of service (DDoS)
attack. DDoS attacks can come from hundreds of various hosts, known as zombie agents, which are under the
control of an attacker.
Session Table Flood—SCREEN Option

The graphic illustrates the required configuration to limit the number of concurrent sessions based on source IP
address, destination IP address, or both.
The Junos OS offers a default maximum number for a source-based or destination-based session limit, which is 128
concurrent sessions. The valid range of sessions depends upon the type of Junos security platform.
Note that the configuration shown on the graphic only defines the SCREEN option. To activate the SCREEN option,
you must apply it within a security zone. We address this topic later.
Firewall and Router Device DoS—SYN-ACK-ACK Proxy Flood: The Attack
A SYN-ACK-ACK attack uses TCP connections. The attacker, using a seemingly normal TCP connection, sends the
SYN-ACK-ACK pattern, hoping that the targets will respond and immobilize themselves. In the illustration shown on
the graphic, a malicious user initiates a Telnet connection. The user sends a SYN segment to the Telnet server
behind the Junos security platform. The Junos OS intercepts the SYN segment, creates an entry in its session table,
and proxies a SYN-ACK segment to the user. The user replies with an ACK segment. At this point, the initial three-way
handshake is complete. The server sends a login prompt to the user. The malicious user does not log in. Instead,
such a user continues to initiate SYN-ACK-ACK sessions, leading the device’s session table to its limit, which can
result in rejecting legitimate connection requests.

Firewall and Router Device DoS—SYN-ACK-ACK Proxy Flood: The Defense
SYN-ACK-ACK proxy protection enables a Junos security platform to detect malicious intent behind a seemingly
normal TCP connection. Because the device acts as a proxy for a TCP connection, creating a session table and
proxying a SYN-ACK segment to the sender, it can detect SYN-ACK-ACK sessions appearing after the success of the
initial session setup. The Junos OS rejects further connection requests from an IP address after the number of
connections from that address reaches the SYN-ACK-ACK proxy threshold. The default value of the proxy threshold is
512 connections from a single IP address. The configured threshold can range from 1 to 250,000 connections.
The graphic illustrates the syntax required to configure the SYN-ACK-ACK proxy flood SCREEN option, limiting the
number of concurrent TCP sessions from a single source.
Note that this configuration only defines the SCREEN option—it does not activate it. To activate the SCREEN option,
you must apply it within a security zone. We address this topic later.
Network DoS—SYN Flood: The Attack

A SYN flood occurs when a network resource becomes overwhelmed with SYN segments initiating uncompleted
connection requests to the point where it cannot accept legitimate connections. Very often a SYN flood attack
inundates a site with SYN segments containing forged or spoofed IP source addresses with nonexistent or
unreachable addresses, thereby forcing the targeted network resources to respond with SYN/ACK segments to those
addresses, then wait for responding ACK segments. As the SYN/ACK segments travel to nonexistent or unreachable
IP addresses, a response never occurs, thus leading to a connection timeout. SYN floods also fill up the memory
buffer of the targets, potentially disrupting the operating system. A SYN flood is usually directed at one or more
network resources resulting in a network DoS.
Network DoS—SYN Flood: The Defense

The Junos OS can prevent SYN floods by limiting the number of SYN segments per second permitted to pass through
the Junos security platform. You can set the attack threshold based on the destination address, source address, or
both. This behavior shields hosts on the protected network from incomplete three-way handshakes. The next two
pages list the specifics of these protection schemes.

SYN Floods—SCREEN Options
The graphic illustrates the Junos SCREEN options that you can implement to handle SYN floods.
Note that the illustrated configuration only defines the SCREEN option. To activate the SCREEN options, you must
apply it within a security zone. We address this topic later.
You can set up the following threshold parameters for proxying uncompleted TCP connection requests:
• Alarm threshold: This threshold is the number of proxied, half-complete TCP connection requests per
second before an alarm logs. This counter begins after the below attack threshold triggers.The default
and configurable range varies by device type.
• Attack threshold: This threshold is the number of SYN segments per second required to trigger the SYN
proxy mechanism. Although you can set any threshold number within a specified range, we recommend
that you determine normal traffic patterns at your sites. The default and configurable range varies by
device type.
• Source threshold: This threshold is the number of SYN segments received per second from a single
source IP address, regardless of the destination IP address and port number. Once requests reached
the threshold, further connection attempts drop. The default and configurable range varies by device
type.
• Destination threshold: This threshold is the number of SYN segments received per second for a single
destination IP address and destination port pair. Once requests reach the threshold, further connection
attempts to the destination drop. The default and configurable range varies by device type.
• Timeout: This parameter is the maximum length of time before a half-completed connection drop from
the queue. The default is 20 seconds, and the range is 1–50 seconds.
Although these threshold parameters are independent of each other, you can combine the SCREEN options in the
configuration for better protection against attacks.

SYN Cookie Advantages

As mentioned previously when we discussed SYN floods, SYN segments directed at network resources can render a
network segment unusable. The SYN cookie feature helps Junos security platforms ensure receipt of a valid SYN
cookie response prior to allowing processing of a new TCP connection flow, thereby avoiding the invoking of
resource-intensive actions such as route and session lookups. A SYN cookie is stateless, and as such it does not set
up a session, which requires policy and route lookups. This stateless nature is the prime advantage of using a SYN
cookie over the traditional SYN proxying mechanism.
SYN Cookie Details

The SYN cookie was originally invented by D. J. Bernstein and Eric Shenk. Its purpose is to minimize the impact of
spoofed SYN flood attacks. The SYN cookie uses a cryptographic hash to generate a unique TCP initial sequence
number (ISN) when it receives a SYN segment. The hash uses a counter, local address, foreign address, and local
and foreign ports to generate the cookie. The Junos OS then sends a SYN/ACK segment back with this cookie as an
ISN. After it receives the ACK segment back, it cryptographically verifies whether it is a valid ACK segment based on
the cookie.
SYN Cookie Handling
The graphic illustrates how a TCP connection establishes when a SYN cookie is active. Once the SYN cookie is
enabled, the Junos security platform becomes the TCP-negotiating proxy for the destination host. It replies to each
incoming SYN segment with a SYN/ACK segment containing an encrypted cookie as its ISN. If there is no response to
the packet containing the cookie, the software notes the attack as an active SYN attack, thereby stopping it.
However, if the initiating host responds with a TCP packet containing the cookie plus 1 in the TCP ACK field, the
software extracts the cookie, subtracts 1 from the value, and recomputes the cookie to validate that it is a legitimate
ACK message.
If the cookie is legitimate, the software starts the TCP proxy process by setting up a session and sending a SYN to the
destination host with the source information from the original SYN message. When the Junos OS receives a SYN/ACK
from the destination host, it sends ACK messages to the destination and the originating hosts. Now the connection
establishes and the two hosts can communicate directly.
ICMP Flood—The Attack

An ICMP flood typically occurs when ICMP echo request messages overload the victim, causing resources to stop
responding to valid traffic.
ICMP Flood—The Defense

The Junos OS allows you to set up a threshold, which, once exceeded, invokes the ICMP flood attack protection
feature. Once requests exceed the threshold value (set in packets per second), the software ignores any further
ICMP echo request messages for the remainder of that second plus the next second. The default and configurable
range varies by device type.
UDP Flood—The Attack

UDP flooding occurs when an attacker sends IP packets containing UDP datagrams with the purpose of slowing
down the target to such a degree that it cannot accept any valid connections.
UDP Flood—The Defense

Junos UDP flood protection enables you to set up the threshold value, which, once exceeded, invokes the UDP flood
attack protection feature. The default value and configurable range are in packets per second and vary by device
type.
ICMP and UDP Flood Handling—SCREEN Options
The graphic illustrates an attacker trying to overload the target with an ICMP flood, a UDP flood, or both. The graphic
illustrates the configuration syntax for ICMP and UDP flood protection. Note that the configuration shown on the
graphic only defines the SCREEN options. To activate the SCREEN options, you must apply them within a security
zone. We address this topic later.

Network DoS—LAND Attack: The Attack

A LAND attack occurs when an attacker sends spoofed SYN packets containing the IP address of the target as both
the destination and the source IP address. A receiving system responds by sending the SYN-ACK packet to itself,
creating an empty connection that lasts until it reaches the session idle timeout. Flooding a system with such empty
connections can overwhelm one or more network resources resulting in a network DoS.
Network DoS—LAND Attack: The Defense

When you enable the Junos SCREEN option to block LAND attacks, the Junos OS combines elements of the SYN
flood defense and IP spoofing protection to detect software and block any malicious attempts of this nature.
LAND Attack—SCREEN Option
The graphic illustrates the impact of the LAND attack on network resources.
Once you enable the LAND attack SCREEN option, the network is protected from the attack.
The graphic illustrates the configuration syntax for the LAND attack SCREEN option. Note that the illustrated
configuration only defines the SCREEN option. To activate the SCREEN option, you must apply it within a security
zone. We address this topic later.
PC-Based Operating System DoS Attacks: The Attacks

The Ping of Death is an OS-targeted attack. It uses an oversized ICMP packet (larger than 65,507 bytes), which can
trigger a wide range of adverse OS reactions, including DoS, crashing, freezing, and rebooting.
Teardrop attacks exploit the reassembly of fragmented IP packets. One of the fields in the IP header is the fragment
offset field, which indicates the starting position of the data contained in a fragmented packet relative to the data of
the original unfragmented packet. When the sum of the offset and size of one fragmented packet differ from that of
the next fragmented packet, the packets overlap. A server attempting to reassemble such a packet can crash.
WinNuke is a DoS attack targeting any computer on the Internet running Windows. The attacker sends a TCP
segment, usually to NetBIOS port 139 with the urgent flag set, to a host with an established connection. This TCP
segment introduces a NetBIOS fragment overlap, which causes many machines running Windows to crash.

PC-Based Operating System DoS Attacks: The Defense

To handle the Ping of Death attack, the Junos SCREEN option detects oversized and irregular ICMP packets, even
when the attacker hides the total packet size by purposefully fragmenting it. To handle the Teardrop attack, the
Junos SCREEN option detects the discrepancy in a fragmented packet and drops it. To handle the WinNuke attack,
the software detects the urgency flag, unsets it, clears the pointer, and forwards the modified packet. It then logs the
attempted WinNuke attack event.
PC-Based OS DoS—SCREEN Options
The graphic illustrates the syntax for configuring the Ping of Death, Teardrop, and WinNuke SCREEN options.
Note that the illustrated configuration only defines the SCREEN options. To activate the SCREEN options, you must
apply them within a security zone. We address this topic later.
ICMP Abnormalities: The Attack

ICMP, when used properly, provides an excellent aid for error reporting and network probe capabilities. Typically,
ICMP packets have very short messages. Therefore, typically, ICMP packets do not fragment.
ICMP Abnormalities: The Defense

The Junos OS blocks any fragmented ICMP packet. In addition, the software drops ICMP packets with a length
greater than 1024 bytes.

ICMP Abnormalities Detection—SCREEN Option
The graphic illustrates an IP packet header, highlighting the protocol field, which is equal to 1 for ICMP, the total
packet length field, the fragment offset field, and the M (more fragments) field. Once you set the ICMP abnormalities
detection SCREEN option, the Junos OS blocks any ICMP packets that have the M flag set or have an offset value
indicated in the fragment offset field. Furthermore, the SCREEN option can include blocking unusually large ICMP
packets (> 1024 bytes). To set up this SCREEN option, you must perform the configuration shown on the graphic.
Note that this configuration defines only the SCREEN option. To activate the SCREEN option, you must apply it within
a security zone. We address this topic later.
IP Packet Fragments: The Attack

As packets traverse different networks, it is sometimes necessary to fragment them based on the maximum
transmission unit (MTU) for each network. IP fragments might contain an attacker’s attempt to exploit the
vulnerabilities in the packet reassembly code of specific IP stack implementations. When the victim receives these
packets, the results can range from processing packets incorrectly to crashing the entire system.
Bad IP Address Options: The Attack

Some attackers can abuse the IP option fields, the original intent of which was (and still is) to provide special routing
controls, diagnostic tools, and security. By misconfiguring these options, attackers produce either incomplete or
malformed fields within a packet. Attackers can use these malformed packets to compromise hosts on the network.
IP Packet Fragments and Bad IP Address Options: The Defense

Once you define the corresponding SCREEN option, the Junos OS detects and drops all IP packet fragments or
packets with incorrectly formatted IP options that it receives at the interfaces bound to the SCREEN option’s
protected zone.

IP Packet Fragments and Bad IP Options Detection—SCREEN Option
The graphic illustrates an IP packet header and highlights the more fragment (M), fragment offset and IP options
fields. Using the block-frag SCREEN option, the Junos OS checks whether the M field is set or if a nonzero value
is in the fragment offset field. If it finds any of these values set, it begins blocking fragmented IP packets.
Attackers can configure the IP options field incorrectly, resulting in incomplete or malformed fields. To set up the bad
IP options SCREEN option, you must perform the configuration shown on the graphic.
Note that this configuration only defines the SCREEN option. To activate the SCREEN option, you must apply it within
Unknown Protocols: The Attack

IPv4 protocol field values of 137 or greater are currently unassigned and should be used only for nonstandard or
experimental protocols. Unless your network uses a nonstandard or experimental protocol, you should block packets
containing an IPv4 protocol field value of 137 or greater.
Unknown Protocols: The Defense

Once you define the corresponding SCREEN option, the Junos OS detects and drops any packet that uses an
unknown protocol.

Unknown Protocols—SCREEN Option
The graphic illustrates an IP packet header and highlights the protocol field containing the protocol number. To set
up the unknown protocols detection SCREEN option, you must perform the configuration shown on the graphic.
SYN Fragments: The Attack

IP encapsulates a TCP SYN segment into an IP packet that initiates a TCP connection. Because the purpose of this
packet is to initiate a connection and invoke a SYN/ACK segment in response, the SYN segment typically does not
contain any data. Furthermore, because the IP packet is small, no legitimate reason exists for it to fragment. A
fragmented SYN packet is anomalous, and as such, it is suspect. When a victim receives these packets, the results
can range from processing packets incorrectly to crashing the entire system.
SYN Fragments: The Defense

Once you define the corresponding SCREEN option, the Junos OS detects and drops all received SYN fragments.

SYN Fragments—SCREEN Option
The graphic illustrates IP and TCP headers and highlights the M and fragment offset fields, which are part of the IP
header, and the SYN flag, which is part of the TCP header. Using the syn-frag SCREEN option, the Junos OS
checks SYN segments to see whether the M field is set or if a nonzero value is in the fragment offset field. If it finds
SYN fragments, it begins blocking the SYN fragment packets.
To set up the SYN fragment SCREEN option, you must perform the configuration shown on the graphic.
Syntax for SCREEN Options Commands
The graphic illustrates the Junos OS syntax that you must use when configuring SCREEN options.

First you must define the SCREEN options. Then you must apply these options to the desired zone. Recall that the
Junos OS applies SCREEN options at the ingress zone of the Junos security platform prior to applying any security
policy or route lookup.
Case Study Example
Consider the example illustrated on the graphic. Two zones exist in this network: private and public. The objective is
to use SCREEN options to protect the private zone from ICMP abnormalities, ICMP floods, and session table floods.
Case Study: Step 1—Creating the SCREEN Option
The graphic illustrates the creation of a SCREEN option named Protector, which lists the necessary options
needed to meet the objective from the previous graphic. The following list describes the behavior of each SCREEN
option:
• icmp fragment: Blocks any ICMP packets that have the More Fragments flag set or that have an offset
value indicated in the offset field.
• icmp large: Blocks any ICMP packets with a length greater than 1024 bytes.
• icmp flood threshold: Ignores any ICMP packets received above the configured threshold. This
protection remains in effect for the duration of the second when the threshold is reached, as well as the
following second.
• source-ip-based session limit: Limits the number of sessions from one source IP address to the
specified number.
Note that by enabling SCREEN protection from large ICMP packets combined with ICMP fragmented packets, you are
also automatically enabling protection from the Ping of Death attack.
Example: Step 2—Applying the SCREEN Option
The graphic illustrates the application of the SCREEN option to the public zone.
Attack Monitoring: Part 1
You can monitor SCREEN statistics using the show security screen statistics zone zone-name
command. You can tell which values are incrementing by issuing the command multiple times.

The graphic shows the result of the show security screen ids-option screen-name command, which
displays the Protector SCREEN option content. Note the correspondence between the actual configuration of the
Protector SCREEN option and the monitoring show security screen ids-option screen-name
command.
The graphic illustrates an example traceoptions configuration for monitoring SCREEN options operations. After
committing the configuration, you can view the resulting trace file using the show log filename command.
Review Questions

Answers
1.
The purpose of SCREEN options in the Junos OS is to offer better network protection to the networks behind the Junos
security platform, and to the device itself, from malicious information or attacks.
2.
The available SCREEN options include IP address sweep detection, port scanning detection, network investigation triggering,
operating system probe blocking, abnormal SYN and FIN flags setting detection, IP spoofing detection, bad IP source route
options detection, ICMP abnormalities detection, and DoS attack detection.
3.
Beyond offering network and host protection against malicious attacks, the main advantage of using SCREEN options is that
the Junos OS performs SCREEN checks prior to security policy processing, which results in fewer resources used for
malicious packet processing.
4.
There are two main goals for a DoS attack: immobilizing hosts and immobilizing networks.
5.
Apply SCREEN options under the security zones configuration stanza.

Chapter 6: Network Address Translation

• The purpose and functionality of Network Address Translation (NAT) and Port Address Translation (PAT);
• NAT processing;
• Configuration of source NAT
• Configuration of destination NAT;
• Configuration of static NAT; and
• Monitoring and verifying NAT operation.
Network Address Translation
Historically, the NAT concept was born because of the shortage of public IPv4 addresses. Many organizations moved
to deploy so-called private addresses using the IPv4 private addressing space, as identified in RFC 1918. These
addresses include the following ranges:
• 10.0.0.0–10.255.255.255 (10.0.0.0/8 prefix);
• 172.16.0.0–172.31.255.255 (172.16.0.0/12 prefix); and
• 192.168.0.0–192.168.255.255 (192.168.0.0/16 prefix).
Because private addresses are not routable within the public domain, edge network devices can deploy the NAT
feature to replace private, nonroutable addresses with public addresses prior to sending traffic to the public network
and vice versa. Translation consists of replacing the IP address (NAT), port numbers (PAT), or both, depending on the
configuration.
Network Address Translation • Chapter 6–1

While primarily deployed to translate private addresses to public addresses, NAT can translate from any address to
any other address, including public to public and private to private addresses.
You can use PAT in conjunction with NAT. Specifically, PAT’s invaluable benefit is that several hosts can use a single
public address. In this situation, PAT enables a unique host and application match during the NAT process.
Review: Packet Flow
A security platform running the Junos operating system implements NAT and PAT into both first path and fast path
flows processing. The graphic reviews the NAT process position within the overall packet flow. Note that destination
NAT and source NAT occur separately in the first path packet flow.
In the first path, NAT is distributed depending on the kind of translation to be done to accommodate the different use
cases relevant to each NAT type. For instance, destination and static NAT are processed before route lookup and
security policy processing, which eliminates the need to install fictitious routes in the routing table.
NAT and PAT Processing
During first packet processing, a combination of destination and source IP address information and port translation
information set up occurs. In first packet processing, destination NAT processing occurs before security policy and
route lookups while source NAT processing occurs after security policy and route lookups. Based on the first packet
of a session, the Junos OS installs NAT and PAT information into the session table for fast path processing. This
information speeds up subsequent packet processing.
The design is such that firewall administrators only need to be concerned with the actual endpoints involved in the
communication.
Chapter 6–2 • Network Address Translation

Three Basic Types of NAT
Three basic types of NAT exist—source NAT, destination NAT, and static NAT. Destination NAT translates the
destination IP address of a packet. Source NAT translates the source IP address of a packet. Static NAT allows
connections to be originated from either side of the network, but is limited in that only one-to-one translations are
possible. Both destination and source NAT can deploy either static or dynamic address mapping.
Combination of Destination and Source NAT and PAT

Destination and source NAT and PAT can co-exist within the same platform. You can deploy both source and
destination NAT and PAT simultaneously, applying each within its own flow direction.
Dynamic Versus Static Address Translation and Port Translation

Dynamic address translation implies that the association between the original address and port and the translated
address and port is not fixed. On the other hand, static address translation implies that the association between the
original address and port and the translated address and port is fixed and has a one-to-one mapping. We address
this topic in more detail later in the material.
Source IP Address and Port Translation
Source IP address and port translation imply that the router translates the source IP address to a different IP
address, the port number to a different port number, or both.
Three Mechanisms for Source NAT and PAT

The Junos OS supports three methods to perform source NAT and PAT:
1. Interface-based source NAT, which is the translation of the original source IP address to the egress
interface’s address always employing PAT;
2. Standard pool-based NAT, which is a dynamic mapping of the original source address to an address
from a user-defined pool with or without PAT; and
3. Source NAT with address shifting, which is a one-to-one mapping of the original source address to a
user-defined pool performed by shifting the IP addresses without PAT.
Matching Conditions
Traffic requiring source NAT application is subject to a two-layer matching scheme. Similar to security policy, the
Junos OS creates source NAT rules under a context indicating traffic direction. The directional context is the first layer
of matching. NAT rules are organized in rule-sets. For source NAT, each rule-set contains this context by requiring a

from clause and a to clause. The from and to clauses indicate an interface, zone, or routing-instance. If rule-sets
overlap by targeting the same traffic, the rule-set with the most specific context takes precedence. Interfaces are the
most specific context, while routing-instances are the least specific.
The second layer of matching is performed within NAT rules using a match option. These options include
source-address and destination-address. This information is evaluated using packet headers.
NAT Rule Actions

Traffic that matches a directional context and NAT rule-matching condition is subject to a NAT action. Source NAT
actions are specified using a then clause and include off, pool (followed by a user-defined pool name), and
interface (followed by a user-defined interface name including the logical unit).
Overlap
Static source NAT (reverse mapping of static destination NAT) rules take precedence over dynamic source NAT rules.
Note the following general guidelines regarding addresses, rule-sets, or rules that overlap:
• Addresses used for NAT pools, whether it be source NAT pools or destination NAT pools, should never
overlap;
• If more than one rule-set matches traffic, the rule-set with the most specific context takes precedence;
and
• Within a rule-set, the ordering of rules is significant. Rules evaluation occurs sequentially. In other
words, if traffic matches two rules within the same rule-set, the first rule listed in the configuration is
the only rule applied.
Use the Junos insert command to adjust rules within a rule-set.
Live Configuration Changes

If a change is made to a NAT rule or pool that is currently in use, the Junos OS tears down the session once the
change is committed. The Junos OS re-initiates the session as soon as it receives further matching traffic.
Interface-Based Source NAT Sample Topology
The graphic illustrates a sample topology that demonstrates interface-based source NAT using the Junos OS. Using
the topology shown on the graphic, we will enable interface-based source NAT for traffic sourced from the network
attached to the ge-0/0/2.0 interface with a destination belonging to the Untrust Zone. The traffic should be
translated to use the egress interface address 1.1.70.5.

Interface-Based Source NAT Configuration
The graphic illustrates the required configuration to enable interface-based source NAT for the given example. Pools
are not necessary for this configuration. Interface-based NAT requires a rule-set to associate with a directional
context. In this example, traffic from the network attached to the ge-0/0/2.0 interface that has a source address
belonging to the 0.0.0.0/0 prefix translates to a source address of the egress interface.
Verifying the Result
Use the show security flow session command to observe NAT translation. The output shows traffic
entering the device using the private source address 10.1.10.5 destined to a public host at 1.1.70.6. The return
traffic from this flow travels to the translated public address 1.1.70.5.
The show security nat source summary command provides a quick look at the rule-set, rule, context, and
rule action resulting from this configuration.
Pool-Based Source NAT Sample Topology with PAT

The graphic illustrates an example topology that demonstrates pool-based source NAT and PAT using the Junos OS.
Using the topology shown on the graphic, we will enable pool-based source NAT with PAT for traffic destined to the
Untrust Zone and sourced from the Trust Zone. Only traffic belonging to the 10.1.10/24 network should be
translated. The traffic should be translated to a public source IP address of 207.17.137.229.
Pool-Based Source NAT Configuration with PAT
The graphic illustrates the required configuration to enable source NAT and PAT for the given example. Junos
pool-based NAT requires a user-defined address pool and a rule-set that associates with a directional context. In this
example, traffic from the Trust Zone destined to the Untrust Zone and with a source address belonging to the prefix
10.1.10/24 translates to a source address of 207.17.137.229. In the Junos OS, PAT is automatically enabled for
pool-based source NAT.
entering the device using the private source address 10.1.10.5 destined to a public host at 1.1.70.6. Source address
translation occurs and the return traffic is sent to the public address 207.17.137.229.
The show security nat source summary command provides a quick way to look at existing source NAT
rules and pools. In this case, the source NAT pool contains a single address, and PAT is enabled by default. The

source NAT rule illustrates the parameters set by the configuration with an associated action of translation using
Pool A.
PAT Is Default
As illustrated in the previous example, the Junos OS’s implementation of source NAT enables PAT by default.
Because PAT is enabled and the number of available ports is near 64,000, it is rare that a source NAT pool will
exhaust.
Address Persistence
Regardless of the large available source NAT pool, there is no guarantee that the Junos OS will use the same source
IP address for different traffic types associated with the same source host. To ensure the use of the same address,
configure the address-persistent global source NAT option as shown on the graphic.
Pool-Based Source NAT Sample Topology Without PAT
The graphic illustrates a sample topology that demonstrates pool-based source NAT without PAT using the Junos OS.
Using the topology shown on the graphic, we will enable pool-based source NAT without PAT for traffic destined to the
translated. The traffic should be translated to a public source IP address range consisting of the 207.17.137/24
network.
Disabling PAT dramatically reduces the number of addresses available in a source pool. Recall that previously, using
PAT, approximately 64,000 variations were available per address. Without PAT, each address in the source pool must
use its original source port, which can lead to higher pool utilization. To combat this problem, we will enable a
backup method to use the egress interface address if a pool is exhausted of addresses. We refer to this backup
method as an overflow pool. An overflow pool can use the egress interface (as in this example) or a separate
user-defined pool. In either case, the overflow pool must have PAT enabled, which is the mandated default for
interface-based NAT.

Pool-Based Source NAT Configuration Without PAT
The graphic illustrates the required configuration to enable source NAT without PAT for the given example. Junos
example, traffic from the Trust Zone destined to the Untrust Zone and with a source address belonging to the
10.1.10/24 prefix translates to a source address belonging to the 207.17.137/24 prefix. PAT is explicitly disabled and
an overflow pool is defined using the egress interface address, in case pool A becomes exhausted of all available
addresses. Recall that interface-based source NAT uses PAT by default.
translation is performed, and the return traffic is destined to the public address 207.17.137.127.
The show security nat source summary command provides a quick way to look at existing source NAT
rules and pools. In this case, the source NAT pool contains the 207.17.137.1 through 207.17.137.254 address range
and PAT is disabled. The source NAT rule illustrates the parameters set by the configuration with an associated
action of translation using pool A.

Pool Utilization
If the Junos OS runs out of addresses in a source NAT pool, further packets requiring translation will drop. We already
discussed one method to overcome this problem—using an overflow pool. While an overflow pool is a handy tool, you
likely also want to know that this situation has occurred so that you can take measures to increase the pool size or
evaluate the usage patterns.
The Junos OS provides a pool utilization alarm for monitoring pool usage. The utilization alarm is disabled by default.
The graphic shows the configuration for the pool utilization alarm, which is global to the source NAT stanza. The
values represent a percentage of pool utilization. Once pool utilization reaches the raise-threshold (in this case,
50%), the Junos security platform sends an SNMP trap notification to a configured network management station. If
traffic falls below the clear-threshold, the Junos OS sends an SNMP trap to the network management station. Note
that while the pool utilization alarm is disabled by default, if configured, the default setting for the clear-threshold is
80 percent of the raise-threshold.
Source NAT with Address Shifting Sample Topology
The graphic illustrates a sample topology that demonstrates source NAT with address shifting using the Junos OS.
Using the topology shown on the graphic, we will enable source NAT with address shifting for traffic destined to the
translated starting with the 10.1.10.5 address for shifting purposes. The traffic should be translated to a public
source IP address range consisting of the 207.17.137/24 network.
By definition, this type of translation is one-to-one, static, and without PAT. If the original source address range is
larger than the address range in the user-defined pool, packets might drop. Use the previously discussed tools to
assist in this situation.

Source NAT with Address Shifting Configuration
The graphic illustrates the required configuration to enable source NAT with address shifting for the given example.
Junos source NAT with address shifting requires a user-defined address pool and a rule-set that associates with a
directional context. In this example, traffic from the Trust Zone destined to the Untrust ZoneTrust Zone and with a
source address belonging to the 10.1.10/24 prefix translates to a source address belonging to the 207.17.137/24
prefix. The 10.1.10.5 address is configured as the host-address-base and serves as a starting point for
address shifting.
translation is performed, and the return traffic travels to the public address 207.17.137.1.
The show security nat destination pool all command illustrates the pool of translated addresses. In
the example, because address shifting is used for this pool, the full range is not listed; however, the output shows
that 254 total addresses are available. The 10.1.10.5 address shows as the base starting address for address
shifting. The output also illustrates that PAT is disabled for this type of address translation. You can view this output
for an individual address pool by specifying the pool name instead of using the all option.

Check Your Knowledge
The off NAT action is useful for detailed control. The configuration shown on the graphic represents how you might
use a NAT off action. In this example, all traffic sourced from the 10.1.10.0/24 network, with the exception of traffic
destined to the 172.18.20.0/24 has source NAT applied to it. Recall that the ordering of rules within a rule-set is
significant. In the example, traffic matching the directional context (from the Trust Zone to the external zone) is first
evaluated by rule 1 and then evaluated by rule 2.
Destination IP Address and Port Translation
Destination IP address and port translation imply that the device translates the destination IP address to a different
IP address, the destination port number to a different port number, or both.
Two Mechanisms for Destination NAT and PAT

The Junos OS supports two mechanisms to perform destination NAT and PAT:
• Interface-based NAT is the translation of the original destination IP address to private addresses with or
without PAT; and
• Standard pool-based NAT is a one-to-one mapping with or without PAT, using address pools.
VoIP ALGs
Voice over IP (VoIP) application-level gateways (ALGs) dynamically generate the allow-incoming table for packets
from the public network into the private network. The table contains the list of dynamically generated addresses for
voice traffic.
Matching Conditions
Traffic that requires destination NAT is subject to a two-layer matching scheme. Similar to security policy, NAT rule
creation occurs under a context indicating traffic direction. The directional context is the first layer of matching. NAT
rules are organized in rule-sets. Each rule-set contains this context by requiring a from clause. The from clause can
indicate an interface, zone, or routing-instance. If rule-sets overlap by targeting the same traffic, the rule-set with the
most specific context takes precedence. Interfaces are the most specific context, while routing-instances are the
least specific.
The second layer of matching occurs within NAT rules using a match option. These options include
source-address, destination-address, and destination-port number. An exception to this second
layer of matching is static destination NAT, which supports only the destination-address match option. This
information is evaluated using packet headers.
NAT Rule Actions

Traffic that matches a directional context and NAT rule-matching condition is subject to a NAT action. NAT actions are
specified using a then clause and include off, pool (followed by a user-defined pool name), and static-nat
prefix (followed by a user-defined address prefix). A destination NAT pool can contain a maximum of one address
or address-range and one port.
Overlap
Static NAT rules take precedence over dynamic destination NAT rules.
Note the following general guidelines regarding addresses, rule-sets, or rules that overlap:
• Addresses used for NAT pools, whether it be source NAT pools or destination NAT pools, should never
overlap;
• If more than one rule-set matches traffic, the rule-set with the most specific context takes precedence;
and
• Within a rule-set, the ordering of rules is significant. Rules evaluation occurs sequentially. In other
words, if traffic matches two rules within the same rule-set, the first rule listed in the configuration is
the only rule applied.
Use the Junos insert command to adjust rules within a rule-set.
Live Configuration Changes

If a change is made to a NAT rule or pool that is currently in use, the Junos OS tears down the affected session once
the change is committed. The Junos OS re-initiates the session as soon as it receives further matching traffic.
Pool-Based Destination NAT Sample Topology
The graphic illustrates a sample topology that demonstrates pool-based destination NAT using the Junos OS. Using
the topology shown on the graphic, we will enable pool-based destination NAT for traffic destined to 100.0.0.1
coming from the Untrust Zone. The traffic should be translated to a private IP address of 10.1.10.5.

Pool-Based Destination NAT Configuration with a Single Address
The graphic illustrates the required configuration to enable destination NAT for the given example. Junos pool-based
NAT requires a user-defined address pool and a rule-set that associates with a directional context. In this example,
traffic from the Untrust Zone with a destination address of 100.0.0.1 translates to a destination address of
10.1.10.5. This example includes a pool with only one available address and no port translation.
Pool-Based Destination NAT Configuration with an Address Pool
The graphic illustrates the required configuration to enable destination NAT for the given example. The Junos OS
example, traffic from the Untrust Zone with a destination address of 100.0.0.1 translates to a destination address
within a range of 10.1.10.5 to 10.1.10.6. There is no port translation.

Pool-Based Destination NAT Configuration with PAT
The graphic illustrates the required configuration to enable destination NAT and PAT for the given example. Junos
example, traffic from the Untrust Zone with a destination address of 100.0.0.1 and a destination port of 80
translates to a destination address of 10.1.10.5 and a destination port of 8080.
Result of NAT with PAT
entering the device using the public destination address 100.0.0.1 and destination port of 80 from a public host at
1.1.70.6. The return traffic from this flow originates with the private address 10.1.10.5 and private port 8080.
The show security nat destination pool all command illustrates the pool of translated addresses—in
this case a single address—and the translated port number. You can also view this output for an individual address
pool by specifying the pool name instead of using the all option.

Use the show security nat destination rule all operational mode command to view NAT rules as the
Junos OS programs them. The output on the graphic illustrates the rule. You can verify traffic translation by this rule
by the translation hits counter.
You can also view this output for an individual NAT rule by specifying the rule name instead of using the all option.
Static NAT Sample Topology
The graphic illustrates a sample topology that demonstrates static NAT using the Junos OS. Using the topology shown
on the graphic, we discuss enabling static NAT for traffic destined to 100.0.0.1 coming from the Untrust Zone. The
traffic should be translated to a private IP address of 10.1.10.5.
Static Destination NAT Configuration
The graphic illustrates the required configuration to enable static NAT for the given example. Junos static NAT
requires a rule-set association with a directional context. In this example, traffic from the Untrust Zone with a
destination address of 100.0.0.1 translates to a destination address of 10.1.10.5

entering the Junos security platform using the public address 100.0.0.1 from a public host at 1.1.70.6. The return
traffic from this flow originates with the private address 10.1.10.5.
Static Source NAT

The graphic illustrates the creation of a second session. Once static NAT is enabled and a session triggers, the Junos
OS automatically creates a reverse static source NAT session. Neither the destination static NAT session, nor the
source static NAT session creation occurs until traffic that matches the NAT rule actually traverses the device.
Dropping Non-NAT Traffic
Because NAT processing has been separated from security policies, both translated and untranslated addresses
might match policies. In this network, the Junos device performs destination NAT to allow Internet connections to
Host A. Traffic sent to the public address of the server and to the private address of the server seem the same to the
policy engine. To overcome this challenge, whenever destination NAT or static NAT is used, the policy engine is
informed that traffic has been translated, which allows policies to explicitly drop translated or untranslated traffic as
shown in the example on the graphic.

When to Use Proxy ARP
The Junos OS for security platforms requires a proxy Address Resolution Protocol (ARP) configuration whenever
translated traffic belongs to the same subnet as the ingress interface. This task is not automatic and you must
configure it as needed.
When a network device needs to send a packet to a destination IP address using ethernet, the device sends an ARP
request to obtain the layer two MAC address associated with the destination IP address. Once that association is in
place, the sending device typically stores this information in memory and subsequently addresses Ethernet frames
to the appropriate Layer 2 MAC address. Without proxy ARP, if an interface receives an ARP request for an address
other than its own, it ignores the packet. It assumes the packet is meant for another device attached to the same
broadcast media. Using proxy ARP, the interface acts as a proxy for the destination by replying to ARP requests on
behalf of the intended destination. Packets destined for the intended destination then travel to the proxying device,
which can then forward the packets to the actual destination.
The graphic illustrates the configuration hierarchy and options for NAT proxy ARP.
Proxy ARP Example
The graphic illustrates a sample situation requiring proxy ARP and the associated configuration. In the example, the
device performs source translation for traffic from the Trust Zone, translating the private source address to a public
source address in the 1.1.70.10 to 1.1.70.100 address range. The NAT source pool belongs to the same subnet as

the public interface. For return traffic to successfully reach the 10.1.10.5 host, the device must perform proxy ARP
for the 1.1.70.10–1.1.70.100 address range.
Key Monitoring Commands
The graphic lists four operational mode show commands used to verify and monitor NAT operation. We repeatedly
illustrate these commands throughout examples in this material. You can use the show security nat
commands for source or destination NAT.
Traceoptions for NAT Operation

Traceoptions are available for a more detailed view of NAT operation. The traceoptions log is stored as /var/log/
security-trace by default, or optionally, the user can define a different log name.
NAT internal operation consists of two main components—the Packet Forwarding Engine (PFE) and the Routing
Engine (RE). The PFE is divided into two elements—the ukernal element and the real-time element. Traceoptions
flags can be set to trace NAT operation within the PFE ukernal, the PFE real-time element, or within the RE. The
output that follows lists all the available flags for tracing NAT operation.
[edit security nat traceoptions]
user@host# set flag ?
all Trace everything
destination-nat-pfe Trace destination nat events on PFE-ukernel side
destination-nat-re Trace destination nat events on RE side
destination-nat-rt Trace destination nat events on PFE-RT side
source-nat-pfe Trace source nat events on PFE-ukernel side
source-nat-re Trace source nat events on RE side
source-nat-rt Trace source nat events on PFE-RT side
static-nat-pfe Trace static nat events on PFE-ukernel side
static-nat-re Trace static nat events on RE side
static-nat-rt Trace static nat events on PFE-RT side
Review Questions

Answers
1.
Destination NAT processing occurs before security policy processing and source NAT processing occurs after security policy
processing.
2.
Static source NAT is supported in one of two ways—using source NAT with address shifting or the automatic creation of a
return session when using static destination NAT.
3.
The NAT off action is for detailed control within NAT rule-sets.
4.
A NAT proxy ARP configuration is necessary when the translated address belongs to the same subnet as the ingress interface.
5.
The commands used to monitor NAT operations are show security flow session, show security nat
source summary (or show security nat destination summary), show security nat source
pool (or show security nat destination pool), and show security nat source rule (or show
security nat destination rule).

Chapter 7: IPsec VPNs

• Various types of virtual private networks (VPNs);
• Major security concerns;
• IP Security (IPsec) VPNs and their functionality;
• IPsec VPN configuration using policy-based and route-based methods; and
• IPsec VPN monitoring.
The Meaning Behind VPNs

VPNs are used to transport private network traffic over a public network infrastructure. The term VPN has been used
broadly in the networking industry for decades. For instance, the networking industry has referred to X.25, Frame
Relay, and ATM infrastructures as VPN networks. As the Internet spread and as carriers and service providers
migrated all their service offerings to IP, new forms of VPNs emerged.
Types of VPNs Today

We can subdivide these new forms of VPNs into three categories:
• Clear-text VPNs: These VPNs include Layer 3 VPNs, Layer 2 VPNs (Kompella and Martini
implementations), and virtual private LAN service (VPLS). These VPNs rely on MPLS services and the
use of signaling protocols over IP.
• Secure VPNs: These VPNs are IPsec VPNs, carrying payload over IP securely. We will discuss these VPN
types in this material.
• Combination of clear-text and secure VPNs: These VPNs are based on Layer 3 VPNs, built on MPLS
technology, and compounded with IPsec security.
IPsec VPNs • Chapter 7–1

Secure VPNs
A network device that builds secure VPNs must be able to perform the following actions:
• Encrypt the original packet so that it cannot be easily decoded should it be intercepted on the public
network;
• Verify the original payload ensuring data integrity; and
• Authenticate the originating device as a member of the VPN, rather than a random device operating on
the public network.
This material focuses on end-to-end static IPsec VPNs. However, note that security platforms running the Junos
operating system also support end-to-site dynamic VPNs and VPN establishment using the NetScreen Remote VPN
client. See the Juniper Networks technical documentation at http://www.juniper.net/techpubs for further
information on these features.
Security Concerns
Three driving concerns exist for network security: confidentiality, integrity, and authentication.
• Confidentiality: Online banking, credit card information, or a company’s competitive information—how
do we keep this information secure from the man in the middle? We want information stored in such a
way that if someone were to capture this datagram, the information would appear meaningless.
• Integrity: Even though the information might be secure and hidden, meaning that someone might not
be able to determine or understand its contents, it could still be possible for someone to change it.
Someone could tweak bits to change the data from what was originally sent through the network. So
how do we ensure that if the data is compromised, the remote station recognizes this fact and refuses
to process the information?
• Authentication: How does the remote station verify that the information came from the device from
which it expected it to come? You do not want to be communicating and sending critical information to
the wrong recipient!
Chapter 7–2 • IPsec VPNs

Confidentiality—Data Encryption
The first of the three VPN security concerns is confidentiality.
Encryption provides data confidentiality. Encryption is the method of taking user data—referred to as plaintext—and
converting it into unreadable or secret data named ciphertext. An encryption algorithm and keys (strings of bits that
seed the encryption process) are applied to the data, resulting in ciphertext.
To reverse the process and decrypt the ciphertext, you must know both the encryption algorithm and encryption key.
You can decrypt encrypted data in one of two ways:
• Symmetric key encryption: This method uses the same key for both encryption and decryption; and
• Asymmetric key encryption: This method uses a private key for encryption and a mathematically related
public key for decryption.
The cipher strength depends on the key size; the larger the key, the more secure the cipher output. The trade-off is in
processing time—larger keys use more computational cycles to encrypt and decrypt.
Confidentiality—Symmetric Key Encryption
Symmetric key encryption is the most straightforward form of encryption with the least amount of overhead. We refer
to it as symmetric because the key used to encrypt the data is the same key used to decrypt the data. Thus, the
same key must be known on both sides of a connection.
Symmetric key sizes range from 40 bits–1024 bits. These keys are considered to be very fast because they are not
very long, and they are widely used for bulk data encryption. However, because the key must be known to both the
sender and the receiver, key management is a problem when using symmetric keys.
Examples of symmetric key encryption include Rivest Cipher 4 (RC4), Data Encryption Standard (DES), Advanced
Encryption Standard (AES), and Blowfish.
Public Key Encryption

The public, asymmetric key encryption method requires a pair of mathematically related keys. One of the keys is kept
secret and known only to the owner; this key is the private key. The owner distributes the other key widely and anyone
can access it; this key is the public key. You can only decrypt data encrypted by the private key by using the
corresponding public key, and vice versa. The keys are mathematically related such that it is almost impossible to
derive one key out of another.
Public key sizes range from 512 to 2048 bits. Because of the large size, these keys are extremely slow and generally
not feasible for bulk data encryption. However, public keys are widely used for user and device authentication (for
example, digital certificates). An example of public, asymmetric key encryption is RSA.
Integrity
Now that we have the data encrypted as it traverses the Internet, we must ensure that the data is not subject to
modification along the way. Even though a novice hacker might not be able to crack the encryption algorithm and
key, the hacker can still wreak havoc by modifying bits that the encrypted payload carries. If this modification
happens, the decrypted output does not match the original data. Who knows what the consequences might be!
Hashing solves this problem by creating a fingerprint of the data, similar to a cyclic redundancy check (CRC)
checksum. Before data travels, it traverses a hashing engine that produces a fixed-length hash output. It places the
hash in a field in the packet along with the data before it travels over the network. The destination device takes the
same data and runs it through the same hashing algorithm, calculating its own hash. The destination device then
compares the hash that it calculated against the hash carried in the packet. The same hash in both locations proves
data integrity in transit. If the hashes do not match, the packet drops.
The Junos OS supports MD5, SHA1, and 256-bit SHA2 hashing.
One-Way Hash Algorithms
A hash function must have two basics properties:

• You should not be able to calculate the original data from the hashed output. This property ensures that
you cannot derive the plaintext from the ciphertext.
• It must be mostly collision resistant. A collision occurs when two different inputs give the same output.
It must not be possible to predict a different input value that gives the same output. This property is
necessary because the purpose of hashing is to verify that the data has not changed.
To see how it is possible to create a one-way function, think of the example on the graphic, which shows a modulus
operation. Given the value of 3, it is not possible to determine the original value because an infinite range of possible
answers exists.
However, this example is not suitable as a real-world hash function because it does not satisfy the collision-resistant
requirement—a malicious person can change the plaintext by any multiple of the modulus number and know that the
hashed value remains the same.
The most secure and widely used hash function is the Secure Hash Algorithm 1 (SHA-1). SHA-1 is preferred over
Message Digest 5 (MD5), although MD5 is still widely supported. These functions produce a fixed-length output that
is useful when working with IP packets because the overhead of transmitting the hash value is predictable.

Integrity—The Hash Process
The following list outlines the hash process:

1. The sender runs the data through the hash process.
2. The sender appends the hash value to the data and sends both the data and the hash value to the
receiver.
3. The receiver separates the data and the hash value.
4. The receiver hashes the data.
5. The receiver then compares the calculated hash value to the received hash value. If the hash values
match, the data is unaltered.
Source Authentication
Encryption protects the packet contents from being viewed on the public network. Hashing verifies that the data is
unaltered. But how do you validate the source of the data?
The software performs source authentication using the Hashed Message Authentication Code (HMAC). The sender
appends a secret preshared key to the data, then performs the hash function. For hashes to successfully match, the
receiver must append the same key value to the data before performing the hash function. The key itself never
transmits along with the data.
HMAC Authentication
The following list outlines hashing with HMAC:
1. The sender appends the preshared key to the data, then performs the hash function.
2. The data and hash value travel to the receiver.
3. The receiver separates the data and the hash value.
4. The receiver appends the preshared key to the data, then performs the hash function.
5. The receiver then compares the calculated hash value to the received hash value. If the hash values
match, the data is unaltered. If the hash values do not match, either the data itself is corrupt, or the
keys did not match, meaning the source is invalid. Either way, the receiver discards the packet.

Key Exchange
As we already discussed, both encryption and authentication are dependent on security keys, which leads to the
problem of key exchange. If keys must be the same on both sides of a connection, how can you securely exchange
key information?
One option is to manually configure the keys on both sides of the connection. Manual key configuration is
straightforward, but misconfigurations, especially when each device has a different administrator, are common.
Furthermore, manual configuration usually means that keys rarely change, which is itself a potential security issue;
given a large enough sample, any code can be broken.
Automating the key exchange process is a good idea, but we must overcome the problem of sending keys across a
public network. Anyone intercepting the key has the ability to decode the data.
The Solution
Whitfield Diffie and Martin Hellman developed a solution to this problem in 1970. The Diffie-Hellman algorithm is a
method whereby two parties can agree upon a secret key known only to them. The strength of the technique is that it
allows the participants to create the secret value over an unsecured medium without exchanging the secret value
itself. This method also makes it impossible to perform reverse generation of the secret if it is somehow intercepted.
Diffie-Hellman Groups
Diffie and Hellman proposed five groups of prime numbers and generator values to use in their key exchange
algorithm. Each group generates unique keys using a combination of exponential and modulus calculations.
The Junos OS supports Diffie-Hellman (DH) Groups 1, 2, and 5. The larger the prime number—the stronger the key—
and the more computationally intensive the calculation. Diffie-Hellman Group 1 uses a 768-bit prime number.
Diffie-Hellman Group 2 uses a 1024-bit prime number. Diffie-Hellman Group 5 uses a 1536-bit prime number.
You must configure both tunnel peers to use the same DH group; otherwise, the key generation process fails.
The DH Key Exchange Process
Using the same DH group, each Junos security platform creates unique public and private keys. These keys are
mathematically related by means of the DH algorithm.

The public key values exchange across the network. Each peer then runs its local private key and the received public
key value through the DH algorithm to compute a common session key. The session key itself never passes across
the network.
The session key is then used as the key for symmetric data encryption.
IPsec Overview
IPsec is a set of standards that defines how the encryption, validation, and authentication methods we just
discussed are actually implemented in networks. IPsec works at Layer 3; it supports both unicast and multicast
traffic.
IPsec: A Two-Step Process

IPsec VPNs consists of two major steps:
1. IPsec tunnel establishment: You can manually establish an IPsec tunnel or the Internet Key Exchange
(IKE) protocol can do it dynamically.
2. IP traffic processing: During this step payload protection takes place using security parameters defined
in the tunnel establishment phase.
We cover the first step—IPsec tunnel establishment using IKE—next.
Step 1: Tunnel Establishment Using Internet Key Exchange

IKE is a secure key management protocol used by IPsec to have information exchanged in a secure and dynamic
manner with little or no intervention. The IKE proposal exchange is Phase 1 of the IPsec tunnel establishment
process. The following attributes exchange between IPsec peers as a part of the IKE process:
• Encryption algorithm;
• Hash algorithm;
• Authentication method; and
• Diffie-Hellman group.
Once IPsec peers negotiate these attributes, they secure future attribute exchanges used to protect data. IKE
exchanges authenticate using one of the following methods:
• Preshared keys;
• Digital signatures; or
• Public key encryption.
IKE is preferable to manual keys in IPsec implementations because of the ease of management and scalability.
Security Associations
A security association (SA) is a set of policies and keys used to protect information. SAs establish upon the
successful completion of IKE negotiations. An SA is uniquely identified by the security parameter index (SPI) value,
the tunnel destination address, and the security protocol—Encapsulating Security Payload (ESP) or authentication
header (AH)—in use. The lifetime of an SA can be based on either a time value or a value determined by the volume
of traffic protected by the proposal.

SA Database
SAs are stored in a security association database. Each entry includes the name of the particular VPN, the remote
gateway IP address, the SPIs for each direction, the agreed-upon security protocol, encryption, and authentication
algorithms and keys.
IKE Phases
IKE tunnel establishment happens in two phases:
• Phase 1 establishes a secured channel between gateways for Phase 2 negotiations to occur. The
Diffie-Hellman key exchange algorithm establishes a shared key for encryption.
• Phase 2 establishes the specific VPN connections. SAs are negotiated on behalf of IPsec to determine
the encryption and authentication algorithms to use when sending user data. The SA is identified by a
unique SPI that is also negotiated during Phase 2.
A single Phase 1 channel can establish multiple Phase 2 SAs or VPNs. If wanted, a second Diffie-Hellman exchange
can be performed during Phase 2 to negotiate a new tunnel key. Because of the encryption on this exchange, it is
named Perfect Forward Secrecy (PFS).

IKE Phase 1: Main Mode
IKE main mode is used when both tunnel peers have static IP addresses. The Phase 1 exchange determines the
following attributes:
• Hash algorithm;
• DH group; and
• Authentication method:
– Preshared keys;
– Digital signatures; and
– Public key encryption.
The first two messages validate the peer configuration (by checking the cookie against the locally configured peer IP
address) and negotiate the parameters listed previously. Both tunnel peers must have at least one configured
matching proposal for Phase 1 exchange success.
The next two messages exchange Diffie-Hellman public key values and nonces necessary to compute the shared key.
The last two messages send simple identification information using the negotiated key; these messages validate
that the key calculation was correct.
For Message 1 and Message 2, peers exchange cookies and SA proposals. Cookies are 8-byte pseudo-random
numbers generated by the sending machine (I=initiator) and receiving machine (R=receptor). Every cookie is unique
to the machine and to each particular exchange. These cookies guarantee uniqueness and replay protection by
hashing the sender's IP address, port, protocol, and timestamp, which results in a unique identifier known only to the
originator. Hence, they are included in every IPsec packet and used to identify communication. In turn, the receptor
inserts its known cookie in Message 2 if it accepts the SA proposal.
An IPsec SA proposal contains the following:
• Phase 1 authentication method (main mode or aggressive mode);
• DH group number;

• Authentication algorithm; and

• Key lifetime.
For Message 3 and Message 4, the DH public values exchange to create a common session key. Nonces, which are
essentially random numbers, also exchange at this time for use as seeds for keys generated later.
After both sides exchange their DH public values, a key is created on each side to encrypt the rest of the IKE Phase 1
messages. The session key is a result of the exchanged public keys traveling to each partner.
Messages 5 and 6 use the pre-shared key in the HMAC algorithm.
IKE Phase 1: Aggressive Mode
IKE aggressive mode is used when one of the tunnel peers has a dynamic IP address that could be a remote end
user dialing in to the Internet, or a remote site using DHCP to acquire an IP address. (Main mode cannot be used
because the first two messages validate peer IP addresses. In the case of a dynamic host address, the peer cannot
preconfigure the address.)
Phase 1 aggressive mode must initiate by the device with the dynamic IP address. The first two messages negotiate
policy and exchange DH public values and nonces. In addition, the second message authenticates the responder;
the ID hash is compared with the locally configured peer ID.
The third message authenticates the initiator and provides a proof of participation in the exchange.

IKE Phase 2: Quick Mode
Once Phase 1 is complete, proposals exchange to establish a specific VPN. The following attributes are negotiated in
Phase 2:
• Security protocol (ESP or AH);
• Tunnel mode or transport mode;
• Proxy IDs; and
• Optional DH group.
Upon successful completion of quick mode, user data encrypts between the configured IPsec peers. Both tunnel
peers must have at least one matching proposal configured for Phase 2 exchange success.
The result of Phase 2 is to create an IPsec VPN for user data to securely transmit through the network.
For Message 1 and Message 2, a Phase 2 proposal list exchanges. The list contains encrypted and authenticated
information that determines the algorithms and keys for encrypting and authenticating user data. The Phase 2
proposal list contains the following items:
• ESP or AH;
• DH group number (0 for no PFS);
• Authentication algorithm;
• Key lifetime;
• Proxy ID (policy rule); and
• DH public keys (optional if using PFS).
Message 3 acknowledges information sent from quick mode Message 2 so that the Phase 2 tunnel can establish.
IPsec: A Two-Step Process—Step 2

Now that we have covered the tunnel establishment step of the IPsec process, we cover the next step—IPsec traffic
processing. Once the IPsec tunnel establishes, the devices are ready to send the payload using the IPsec attributes
and protocols, which ensure payload protection.

Goal of IPsec Traffic Processing
During the IPsec traffic processing step, the devices have one goal—to ensure traffic protection. The most commonly
used IPsec mode is ESP tunnel mode.
IPsec Modes
IPsec handles the payload using one of two modes—transport or tunnel. We discuss each mode in the next few
pages.
IPsec Protocols
IPsec uses two protocols to ensure payload security—the AH protocol and the ESP protocol. Again, we discuss each of
these protocols in the next few pages.
IPsec Modes
You can implement IPsec in the following two modes:

• Tunnel mode: This mode is the most commonly implemented method. Tunnel mode is implemented
between IPsec gateways or an IPsec gateway and a remote client providing secure access to the
networks behind the gateway. In this method, end systems need not be aware of the IPsec protocol
suite. All encryption and decryption takes place on the IPsec gateways on behalf of the hosts behind the
gateway.
• Transport mode: This mode is implemented between IPsec end systems. End systems should be aware
of the IPsec protocol suite. They do all the encryption and decryption of data.

IPsec Protocols
Two protocols exist that IPsec can use to ensure payload security—AH protocol and ESP:
• AH provides only data integrity, authentication, and antireplay services. AH is identified by IP protocol
number 51. It uses MD5 or SHA-1 to provide data integrity services. AH provides no encryption of data
in the packets.
• ESP provides data confidentiality, data integrity, authentication, and antireplay services. It does not use
a transport protocol like TCP or UDP; it rides directly on top of IP using protocol number 50. ESP uses
symmetric key algorithms like DES, triple Data Encryption Standard (3DES), or AES, and hash methods
like MD5 and SHA-1 to provide security services. Antireplay services ensure that third parties cannot
capture and retransmit datagrams. By checking sequence numbers, a receiver can determine receipt of
a packet and can discard any repetitions.
Example: Tunnel Mode AH Packets
AH authenticates only the immutable fields in the IP header. Fields like time to live (TTL) and type of service (ToS)
change during packet transit, so these fields do not receive authentication. The new IP header contains protocol
number 51, signifying AH.
The AH header contains the following items:
• Next header: Information on the next expected segment;
• Payload length: Indicates the size of the payload;
• SPI: An arbitrary 32-bit value that, in combination with the destination IP address and security protocol
(AH), uniquely identifies the security association for this datagram; and
• Sequence number: An unsigned 32-bit field containing a monotonically increasing counter value
(sequence number). It is used to detect antireplay.

Example: Tunnel Mode ESP Packets
In tunnel mode, the ESP header inserts between the new IP header and the original IP header. The new IP header
contains protocol 50, representing ESP. The ESP header contains the following information:
• SPI: An arbitrary 32-bit value that, in combination with the destination IP address and security protocol
(ESP), uniquely identifies the security association for this datagram; and
• Sequence number: An unsigned 32-bit field containing a monotonically increasing counter value
(sequence number); it is used to detect antireplay.
The ESP trailer contains the following information:
• Padding/pad length: Depending on original data size, padding might be required to fill the packet; and
• Next header: Information on the next expected segment.
ESP Auth is the integrity check value (that is, the hash value) for this packet.
Traffic Processing: Part 1

The following list describes the order of traffic processing:

1. The packet arrives at the remote Junos security platform.
2. The Junos OS looks up the destination route and determines the Egress Zone.
3. The Junos OS looks up the security policy. The traffic matches a tunnel policy.
4. The original packet receives encryption.
5. The Junos OS hashes the packet with an authentication key.
6. The Junos OS builds the tunnel packet with a new IP header, IPsec header, and hash value. The new
packet travels to the tunnel peer.
Traffic Processing: Part 2
This list is a continuation of the list from the previous section, describing the order of traffic processing:
7. The corporate Junos security platform receives the encrypted packet.
8. The Junos OS looks up the incoming SPI in the local SA database. The matching record contains
encryption and authentication algorithms, and keys.
9. The Junos OS compares the locally calculated hash with the received hash.
10. The Junos OS decrypts the packet.
11. The Junos OS performs the routing lookup for the decrypted packet and determines the Egress Zone.
12. The Junos OS checks the associated security policy. It forwards the packet if the tunnel policy exists for
the packet.

IPsec Processing Summary
The graphic provides a summary of all the steps of IPsec traffic processing.
IPsec Implementation Methods

The Junos OS offers two methods for IPsec VPN implementation:
• Policy-based VPNs: To implement this method, a security policy specifies as its action the IPsec VPN
tunnel for transit traffic that meets the policy’s match criteria. Policy-based VPNs are required when one
endpoint of the tunnel uses dynamic addressing. For policy-based IPsec VPNs, a new tunnel generates
for each flow of traffic that matches the policy. Because each tunnel requires its own negotiation
process and a separate pair of SAs, the use of policy-based IPsec VPNs can require more resources
than route-based IPsec VPNs.
• Route-based VPNs: Unlike the process for policy-based IPsec VPNs, for route-based IPsec VPNs, a policy
refers to a destination address—not an IPsec VPN tunnel. Because a destination address is used,
route-based VPNs are generally the best VPNs to use when a routing protocol adjacency must be
formed across the tunnel. When the Junos OS searches a route that must send traffic to the destination
address, it finds a route associated with a secure tunnel interface (st0.x). The tunnel interface is bound
to a specific IPsec VPN tunnel, and traffic routes to the tunnel if the policy action is permit. With a
route-based IPsec VPN, in most cases, only one VPN exists between two sites.
Elements of IPsec VPN Configuration

IPsec VPN configuration consists of three steps:
1. Configuring IKE Phase 1;
2. Configuring IKE Phase 2; and
3. Applying the IPsec implementation method, which includes implementing either policy-based VPNs or
route-based VPNs.

Configuring IKE Phase 1 Parameters: Step A
IKE Phase 1 configuration requires that you perform the following steps:
A. Configure IKE Phase 1 proposals;
B. Configure IKE policies and reference the proposals; and
C. Configure the IKE gateway and reference the policy.
The graphic addresses Step A, which is optional, because you can use the Junos predefined proposals. The following
are the predefined proposals:
• basic:
– Proposal 1: preshared key, DH g1, DES, and SHA1
– Proposal 2: preshared key, DH g1, DES, and MD5
• compatible:
– Proposal 1: preshared key, DH g2, 3DES, and SHA1
– Proposal 2: preshared key, DH g2, 3DES, and MD5
– Proposal 3: preshared key, DH g2, DES, and SHA1
– Proposal 4: preshared key, DH g2, DES, and MD5
• standard:
– Proposal 1: preshared key, DH g2, 3DES, and SHA1
– Proposal 2: preshared key, DH g2, AES128, and SHA1
Configuring IKE Phase 1 Parameters: Step B
The graphic illustrates the syntax for Step B of IKE Phase 1 configuration, which is policy configuration. For this step
you must either refer to the preconfigured proposal from Step A or use a system-defined proposal. Also, within the
policy you must specify the preshared key and mode of IKE—main or aggressive.

Configuration of IKE Phase 1 Parameters: Step C
The graphic illustrates the last step of IKE Phase 1 configuration, which is gateway configuration. In this step, you
must refer to the policy configured in the previous step, define the peer address, and specify the outgoing interface.
Optionally, you can configure dead peer detection (DPD) to send a DPD request packet if the device does not receive
traffic from a peer for the number of seconds specified with the interval option. You can also configure DPD to
consider the peer unavailable after a threshold number of interval periods is reached. For example, assume that the
interval value is 10 seconds and the threshold value is 5. If the device does not receive traffic from a peer for 10
seconds, it sends a DPD request packet to it. The Junos security platform then considers the peer unavailable after
five sequences of waiting for 10 seconds.
Configuring IKE Phase 2 Parameters: Step A
IKE Phase 2 configuration requires that you configure the following steps:
A. IKE Phase 2 proposals;
B. IKE Phase 2 policies; and
C. IKE Phase 2 VPN tunnel.
The graphic addresses Step A, which is optional, because you can use predefined proposals. The following are the
predefined proposals:
• basic:
– Proposal 1: no PFS, ESP, DES, and SHA1
– Proposal 2: no PFS, DH g1, DES, and MD5
• compatible:
– Proposal 1: no PFS, ESP, 3DES, and SHA1
– Proposal 2: no PFS, ESP, 3DES, and MD5
– Proposal 3: no PFS, ESP, DES, and SHA1
– Proposal 4: no PFS, ESP, DES, and MD5
• standard:
– Proposal 1: ESP, DH g2, 3DES, and SHA1
– Proposal 2: ESP, DH g2, AES128, and SHA1

Configuring IKE Phase 2 Parameters: Step B
The graphic illustrates the syntax for Step B of IKE Phase 2 configuration, which is policy configuration. For this step,
you must either refer to the preconfigured proposal from Step A or use a system-defined proposal. Also, within the
policy, you have the option to configure PFS to use with the three supported groups of DH as the method for the
Junos OS to generate the encryption key.
Configuring IKE Phase 2 Parameters: Step C
The graphic illustrates the last step of IKE Phase 2 configuration, which is VPN configuration. In this step, you must
refer to the policy defined in the previous step, as well as the gateway preconfigured in Step C of IKE Phase 1. If you
are configuring a route-based VPN, you must bind the st0.x interface to the VPN, as illustrated on the graphic. If you
manually set up a tunnel, you must specify all the necessary attributes manually. Should you choose to do so, you
can set up all the necessary parameters under the security ipsec vpn configuration stanza. The optional
establish-tunnels command specifies when to activate IKE-- immediately, or on-traffic. The
immediately option signals the device to activate IKE immediately after VPN configuration or configuration
changes are committed. The on-traffic option signals the device to activate IKE only when payload traffic
flows.

Applying IPsec—Policy-Based IPsec VPNs
If you are implementing a policy-based IPsec VPN, you must apply the configured VPN from within the security policy,
as illustrated on the graphic.
Applying IPsec—Route-Based IPsec VPNs
If you are implementing a route-based IPsec VPN, you must perform the following steps:
1. Configure the secure tunnel interface (st0.x);
2. Configure a static route or enable dynamic routing that points to the st0.x interface;
3. Add the st0.x interface to the appropriate security zone; and
4. Bind the st0.x interface to the IPsec VPN.

Example: Creating Policy-Based IPsec VPNs Using IKE
Consider the following example: you must implement a policy-based IPsec VPN between two SRX Series Services
Gateways named Edge and Remote, as illustrated on the graphic. A policy-based IPsec VPN implies that you must
refer to the VPN tunnel from within the policies at each end, as demonstrated on the graphic.
Example: Configuring IKE Phase 1 Parameters
The graphic illustrates the configuration of the following parameters for IKE Phase 1:
1. Proposal for IKE Phase 1: Recall that this step is optional, because you can use the Junos predefined
proposals (the choices are basic, compatible, or standard). On the graphic, we named the
configured proposal ike-phase1-proposal. We decided to use authentication algorithm md5,
encryption algorithm 3des-cbc, a DH key exchange of group 2, and preshared keys as the
authentication method.
2. A policy, called ike-policy1: Within the policy we specified the mode that IKE Phase 1 will use—
main mode, in this case. We referred to the proposal ike-phase1-proposal, and we specified the
preshared key.
3. Gateway, called ike-phase1-gateway: Within the gateway stanza we referred to the policy
ike-policy1, specified the address of peer Remote (1.1.70.1), and specified the external interface
that IKE will use to establish the tunnel (ge-1/0/1.0). Also, we decided to use DPD so that a peer
sends a DPD request packet to another peer if it does not hear from it for 20 seconds. Suppose it is
Edge that sends the DPD request packet to Remote. After sending the DPD request packet, Edge
considers Remote to be unavailable after five sequences of waiting for 20 seconds.
You must repeat the illustrated configuration on the Remote device, defining the appropriate external interface and
gateway address.
Example: Configuring IKE Phase 2 Parameters for Policy-Based IPsec VPNs
The graphic illustrates configuration of IKE Phase 2 parameters for our example. Our configuration consists of the
following:
1. A proposal for IKE Phase 2: Recall that this step is optional because you can use the Junos predefined
proposals (the choices are basic, compatible, or standard). We named the configured proposal
ike-phase2-proposal. We decided to use authentication algorithm hmac-md5-96, encryption
algorithm 3des-cbc, and the ESP protocol.
2. A policy called ipsec-pol1: Within the policy we referred to the proposal ike-phase2-proposal,
and we specified that IPsec will use DH Group 2 as its PFS.
3. A VPN tunnel, called TunnelA: Within the tunnel we referred to the gateway ike-phase1-gateway
and the IKE Phase 2 policy ipsec-pol1. We also specified that tunnels should establish immediately.
Note that you should repeat the configuration illustrated for the Edge device on the Remote device.

Monitoring Policy-Based IPsec VPNs
Once you finish and commit all the configurations, you must ensure that the tunnels are working properly by
following the order of how IPsec works. First ensure that IKE Phase 1 is working properly, then ensure that IKE
Phase 2 is working properly. To check that IKE Phase 1 functions properly, check whether the SAs are formed.
Similarly, you perform IKE Phase 2 checking by viewing the resulting SAs.
The graphic illustrates both commands with the resulting outputs. Also, you can view the IPsec statistics that specify
the number of transit packet bytes that the device has encrypted and decrypted.
Example: Creating Route-Based IPsec VPNs Using IKE
Consider another example: In this case you need to set up the IPsec tunnel using the route-based method and IKE.
Recall that a route-based VPN requires only one tunnel between Junos security platforms, while a policy-based VPN
sets up a tunnel for every new flow.

You must ensure that both ends of the VPN tunnel have a secure tunnel interface configured—in our case it is the
st0.0 interface, with IP address 1.1.80.0/28. Furthermore, you must ensure that each of the devices has a valid
route referring to the st0.0 interface. In our case we are using static route 0.0.0.0/0.
Example: Configuring a Security Zone for a Route-Based IPsec VPN
Once you configure interface st0.0, you must add it to the corresponding security zone. In our case, we must add it to
the Public security zone. Also note that although the graphic provides the configuration for the Edge device, you
must also repeat it for the Remote device.
Example: Configuring IKE Phase 1 Parameters
The graphic illustrates the configuration of the following parameters for IKE Phase 1:
1. The proposal for IKE Phase 1: Recall that this step is optional because you can use the Junos
predefined proposals (the choices are basic, compatible, or standard). We named the
configured proposal ike-phase1-proposal. We decided to use authentication algorithm md5,
encryption algorithm 3des-cbc, a DH key exchange of group2, and preshared keys as the
authentication method.
2. A policy, called ike-policy1: Within the policy, we specified the mode that IKE Phase 1 will use—the
main mode, in this case. We referred to the proposal ike-phase1-proposal, and we specified the
preshared key.

3. A gateway, called ike-phase1-gateway: Within the gateway stanza we referred to the policy
ike-policy1, specified the address of the peer Remote (1.1.70.1), and specified the external
interface IKE will use to establish the tunnel (ge-1/0/1.0). Also, we decided to use DPD so that a peer
will send a DPD request packet to another peer if it does not hear from it for 20 seconds. Suppose that
it is Edge that sends the DPD request packet to Remote. After sending the DPD request packet, Edge
considers Remote to be unavailable after five sequences of waiting for 20 seconds.
Note that you must repeat the illustrated configuration at the Remote device, defining the appropriate external
interface and gateway address.
Example: Configuring IKE Phase 2 Parameters for a Route-Based IPsec VPN
The graphic illustrates configuration of IKE Phase 2 parameters for our example. Our configuration consists of the
following:
1. A proposal for IKE Phase 2: Recall that this step is optional, because you can use the Junos predefined
proposals (the choices are basic, compatible, or standard). We named the configured proposal
ike-phase2-proposal. We decided to use authentication algorithm hmac-md5-96, encryption
algorithm 3des-cbc, and the ESP protocol.
2. A policy, named ipsec-pol1: Within the policy we referred to the proposal
ike-phase2-proposal, and we specified that IPsec will use DH group2 as its PFS.
3. A VPN tunnel, called TunnelA: Within the tunnel we referred to the gateway ike-phase1-gateway
and the IKE Phase 2 policy ipsec-pol1. We also specified that tunnels should establish immediately.
Furthermore, we bound the st0.0 interface to the tunnel.
When you compare the configuration on the graphic to the policy-based IPsec IKE Phase 2 configuration, you will
notice that the only difference between the two is the statement binding interface st0.0 to the tunnel.
Note that we must also repeat the configuration illustrated for the Edge device at the Remote device.

Monitoring a Route-Based IPsec VPN: Part 1
Once you finish and commit all the configurations, you must ensure that the tunnels work properly by following the
order of how IPsec works. First ensure that IKE Phase 1 works properly, then ensure that IKE Phase 2 works properly.
To check that IKE Phase 1 functions properly, you must check whether the SAs form. Similarly, you perform IKE
Phase 2 checking by viewing the resulting SAs.
The graphic illustrates both commands with the resulting outputs. Also, you can view IPsec statistics that specify the
number of transit packet bytes that the device encrypts and decrypts.
One of the differentiating points of a route-based IPsec VPN is that it uses the st0 interface. Therefore, you can use
the show interfaces st0.x command to view whether the interface is up as well as how much information
transits through it. If there is a problem in establishing the route-based IPsec tunnel, the st0 interface is not in the

up state. The graphic illustrates the results of the show interface st0 detail command for the Edge
device.
The graphic is the continuation of the show interfaces st0 detail command from the previous graphic. It
provides statistical information for the st0 interface, including flow input, flow output, and flow error statistics.
As we work with a route-based IPsec VPN, it is useful to check the routing table entries, ensuring that an active route
referring to the st0 interface exists. In our case, the 0.0.0.0/0 default route, using interface st0.0 as its next hop, is
active.
Other IPsec VPN Monitoring Commands

You can enable traceoptions to debug IKE Phase 1 and Phase 2. Also, you can clear IKE Phase 1 and Phase 2
SAs and statistics using the clear security ike and clear security ipsec operational commands.

Common IPsec Configuration Problems

You should be aware of the following common problems when configuring IPsec VPNs:
• Proposal mismatch: The IKE Phase 1 proposal lists configured on each side do not agree. In this case,
the initiator of the tunnel sees retransmissions and a retransmission limit indicator. The problem is
evident at the destination gateway (the responder). The responder rejects all proposals sent by the
initiator.
• Preshared key mismatch: The keys do not match.
• No route information is available: To establish a gateway, you must either configure an explicit route or a
default route (or use a dynamic routing protocol) to be used to reach the remote gateway.
• The destination gateway is misconfigured: It might happen that the destination gateway (responder)
does not recognize the incoming request as originating with a valid peer gateway. Any of the following
misconfigurations could cause this problem:
– The peer gateway is not configured correctly;
– The outgoing interface is not the right one; or
– A proposal mismatch exists.
Review Questions
Answers
1.
The three major security concerns are confidentiality, integrity, and authentication.
2.
The main difference between ESP and AH is that AH does not provide confidentiality, while ESP does.
3.
The Junos OS supports the use of the MD5 and SHA protocols to ensure data integrity.
4.
The two modes available in IKE Phase 1 are main and aggressive.

Chapter 8: Introduction to Intrusion Detection and

Prevention

• The purpose of the Junos operating system’s Intrusion Detection and Prevention (IDP) feature;
• Utilizing and updating the IDP signature database;
• Utilizing and configuring IDP policy using a policy template; and
• Monitoring IDP operation.
What Is IDP?
Initially, network defense consisted of basic stateless firewall protection. Network devices, such as routers, often
provided this feature. As network attacks became more sophisticated, network defense also had to become more
sophisticated. Stateful firewalls, authentication mechanisms, and VPN devices utilizing encrypted traffic offered
additional protection from harmful network traffic and malicious users.
Traditional firewalls might not detect some malicious traffic because manufacturers design VPN devices and
firewalls for high-speed operation of VPN control and access control. For these types of attacks, the solution is to use
IDP.
The Junos IDP feature provides additional security beyond a firewall. While a firewall traditionally inspects only
Layers 3 and 4, the Junos OS utilizes the IDP feature to decode and reassemble the protocol stream and thus sees
traffic from the application’s point of view (Layer 7). When IDP reassembles the data stream, the Junos OS examines
the stream for specified attack patterns. If no problem with the stream exists, the Junos OS forwards the original
Introduction to Intrusion Detection and Prevention • Chapter 8–1

packets. If the software detects a problem within the stream, IDP can drop packets, close or drop sessions, prevent
future sessions, and log attacks for review by network administrators.
Utilizing IDP in combination with SCREEN options, zones, security policies, and other Junos security features offers a
complete approach to network security.
Fully Integrated IDP
Junos security platforms have IDP functionality fully integrated into the Junos OS. This integration means no
additional hardware or operating system is necessary, resulting in less cost, lower management overhead, and
increased operational simplicity.
Live Attack Database
Juniper Networks maintains a database of attack signatures for use with the IDP feature. With a valid license, users
can retrieve updates manually by running a CLI command or automatically by configuring a Junos security platform
to update its database at regular intervals. The full security package download includes various policy templates.
These policy templates offer protection against a variety of common attacks. Once you install the templates, you can
customize them to fit the traffic patterns of a particular network.
IDP Successes
The Junos IDP feature regularly protects networks from the latest Microsoft vulnerabilities. The attack database
updates as new threats emerge, keeping the Junos OS on the leading edge of network defense. IDP allows you to
stop attacks before they fully compromise the network. In the past, you often had to take a reactive approach to
network security by parsing logs for security threats before being able to take action. In the meantime, the network
remained vulnerable. Using IDP, you can be proactive by stopping attacks as they occur, and by preventing future
Chapter 8–2 • Introduction to Intrusion Detection and Prevention

attacks. IDP uses attack signatures to protect your network from thousands of known attacks. It can also detect
protocol anomalies to protect your network from unknown or potential attacks. Juniper Networks maintains a
Web-based security portal (http://www.juniper.net/security) listing the latest attack database updates, Microsoft
security bulletins, attack trends, and other useful security information.
IDP Policy Framework
Policy drives the IDP attack detection engine. IDP policy enables selective enforcement of various IDP attack
detection and prevention techniques on network traffic passing through the IDP engine. Users can write very
granular rules to match a section of traffic based on zones, networks, and applications. Users can then apply
specific attack prevention techniques on that traffic, and take active or passive preventive actions.
The graphic illustrates the structural view of an IDP policy. An IDP policy can consist of two types of rulebases—an
intrusion prevention system (IPS) rulebase and an exempt rulebase. A rulebase is a collection of rules. Rules contain
a collection of configuration objects and are similar in structure to security policy because they use configuration
objects to create match conditions and resulting actions. Once you create an IDP policy, the action of a security
policy applies it. Although many IDP policies might exist within the configuration, only one IDP policy is active on a
Junos security platform.
IDP Configuration Objects

The Junos OS uses configuration objects to build IDP rules. Use configuration objects to match on zones, source and
destination networks, applications, and attacks or attack groups.

IDP Policy Matching Conditions
The graphic shows a sample IDP policy configured with the Junos OS template policy named Recommended. The
graphic shows a rule named rule 2 in an IPS rulebase with the matching conditions highlighted. In this case, the rule
matches on traffic from any zone and source address to any zone and destination address. The rule also matches on
an application type of default. When you select this application type, the software bases application matches on the
attack or attack group objects. The Junos OS automatically matches on application or service settings associated
with the defined attack or attack group object. You can also specify a configured application or application-set or use
the any option.
The sample configuration on the graphic shows a predefined attack group designed for Internet Control Message
Protocol (ICMP) attacks. Predefined attack and attack group objects are part of the signature database that can be
downloaded from Juniper Networks. We discuss the signature database in subsequent material. You can also specify
custom attack and attack group objects or dynamic attack group objects. Custom attacks and attack groups are
user-defined configuration objects. The software builds dynamic attack groups using filters that match on a
particular option, such as an application. For more information on custom attacks and groups or dynamic attack
groups, refer to http://www.juniper.net/techpubs for the Juniper Networks technical documentation.
IDP Policy Actions

The graphic shows the same sample policy rule as the previous graphic, but with the action section of the rule
highlighted. This example defines an action of Recommended. This type of action is only applicable to IPS rulebases
utilizing predefined attack objects. A Juniper Networks recommended action is associated with all predefined attack
objects. A rule can have one of the following actions:
• no-action: The Junos OS takes no action (used when you only need to generate a log);
• ignore-connection: The Junos OS stops scanning traffic for the rest of the connection;
• mark-diffserv: The Junos OS assigns the indicated service-differentiation value to the packet then
passes it on normally;
• drop-packet: The Junos OS drops a packet before it can reach its destination, but does not close the
connection;
• recommended: The action that Juniper Networks recommends when it detects a predefined attack;
• drop-connection: The Junos OS drops the connection, preventing traffic for the connection from
reaching its destination;
• close-client: The Junos OS closes the connection and sends a RST packet to the client but not to
the server;
• close-server: The Junos OS closes the connection and sends a RST packet to the server but not to
the client; and
• close-client-and-server: The Junos OS closes the connection and sends an RST packet to both
the client and the server.
The example on the graphic also illustrates a notification action. This action instructs the Junos OS to log the attack.
Additional IDP Policy Actions

The graphic lists a continuation of IDP policy actions. IP actions prevent repeat attacks. This rule action applies to
future sessions that have the same IP action attributes of the flow on which the software detects an attack. For
example, you could configure one of the IP actions in a rule to block all future HTTP sessions between two hosts if
the software detects an attack on a session between those hosts. Optionally, you can specify a timeout value
defining that the action should apply only if new sessions initiate within a specified timeout value in seconds. (The
default IP action timeout is 0, which means no timeout.) IP action attributes consist of a combination of the following
fields:
• Source IP;
• Destination IP;
• Destination Port;
• From Zone; and
• Protocol.
These IP action attributes can be used only in certain combinations and list as targets in the following output:
[edit security idp idp-policy Recommended rulebase-ips rule 2]
user@host# set then ip-action target ?
destination-address Match destination
service Match source, destination, dst-port and protocol
source-address Match source
source-zone Match source-zone
zone-service Match source-zone, destination, dst-port, protocol

The following are possible IP actions:

• ip-block: The Junos OS silently drops all packets matching the IP action rule;
• ip-close: The Junos OS closes any new sessions matching the IP action rule by sending an RST
packet to the client and server; and
• ip-notify: The Junos OS generates a log when it finds a session matching the IP action rule.
You can use the severity action to override the default attack severity to a configured value.
Applying IDP Policy
You enable IDP policies by specifying the IDP policy in a security policy, as shown on the graphic. The security policy
action must be to permit the flow. Note that once an IDP policy is in use, any change to the [edit security
idp] hierarchy, the associated security policy configuration, or the associated custom applications causes an IDP
policy recompilation when you issue the commit.
Active IDP Policy
Recall that only one IDP policy is active on a Junos security platform at any given time. The graphic shows how to
configure the active IDP policy.
Evaluating IDP Rulebases
Once the software compiles an IDP policy, it pushes the policy to the data plane where the IDP policy evaluation
occurs. IDP policy evaluates only the first packet of a session. If a match occurs, the software creates a set of objects
and caches them within the session for use with attack detection on subsequent packets.
The Junos OS evaluates all IDP rules (unlike security policy) but does so sequentially. If a new session matches
multiple rules, the Junos OS performs the most severe action among the rules. The graphic shows the order of
severity associated with rule actions.
You can make an IDP rule terminal using the configuration shown on the graphic. When the software configures a
match in a terminal rule for the source, destination, zones, and application, it does not continue to check
subsequent rules for the same source, destination, and application. It does not matter whether traffic matches the
attack objects in the matching rule or not. This option is useful for disregarding traffic that originates from a known
trusted source. Terminal rules should appear near the top of the rulebase and before other rules that would match
the same traffic.

Exempt Rulebases
The functionality of an exempt rulebase complements an IPS rulebase. You can write rules in an exempt rulebase to
skip detection of a set of attacks in certain traffic. Carefully written rules in an exempt rulebase can significantly
reduce the number of false positives generated by an IPS rulebase. Note that you must configure an IPS rulebase
before using an exempt rulebase. Rules in an exempt rulebase have the same matching conditions as those of an
IPS rulebase. The exception is that you cannot configure the application object, which means rules match all
applications. When configuring attack or attack-group objects in an exempt rulebase, note that these attacks are
attacks the software should not inspect in traffic matching this rule. No actions are available for exempt rulebases.
The Signature Database
The signature database is one of the major components of IDP. It contains definitions of different objects—such as
attack objects, application signature objects, and service objects—that it uses to define IDP policy rules. As a
response to new vulnerabilities, Juniper Networks periodically provides a file containing attack database updates on
its Web site. You can download this file to protect your network from new threats. The database lists the attack
objects alphabetically, and the names consist of the attack object group name and the name of the attack object, as
shown on the graphic.
The security package, which you can download from Juniper Networks, also includes IDP policy templates to help you
implement IDP policy on your Junos security platform. You can use the template policies as they are, or you can
customize them for your network environment. Templates exist for a multitude of network scenarios. The most widely
used template is called the Recommended policy. We discuss downloading the signature database and policy
templates .

IDP Signature Update License
To update the IDP signature database, an IDP signature license is necessary. The graphic illustrates the
configuration command for adding a system license, and the result of a successful license addition.
Updating the Security Package Manually
You can download the Juniper Networks security package manually or automatically at specified time intervals. The
graphic illustrates the operational mode commands to download the security package and check the status of the
download. You must connect the Junos security platform to the Internet to update a device directly. Alternatively, you
can download the update to a Network and Security Manager (NSM) device, which can be configured to push the
updated database to your Junos security platform.

Installing the Security Package
Once you successfully download the security package, you must install it. The graphic illustrates the operational
mode commands for installing the security package and verifying the status of an installation.
Automatic Downloads
As mentioned previously, you can configure a Junos security platform to automatically download the security
package. The graphic also shows an example configuration of automating the download.
Signature and Attack Database Version

The graphic illustrates the operational mode command used to verify the attack database. The version includes a
time and date stamp so you can check the date of your local database.
Checking Your Connection to the Update Server

The graphic illustrates the operational mode command used to check the server connection from your Junos security
platform. This command not only verifies network connectivity, but also provides the remote database version, which
is useful for comparing version differences with the previous command output.

Applying the Recommended IDP Policy: Part 1
The graphic and the next two graphics demonstrate the steps necessary for downloading and installing the Juniper
Networks recommended IDP policy. This graphic shows the operational mode commands used to download and
install the latest policy templates provided by Juniper Networks. Recall that a Junos security platform must have an
IDP signature license to download the signature database or associated policy templates.
The Junos OS downloads Juniper Networks policy templates in the form of a commit script. Once you download and
install the policy templates, you must activate the template commit script with the configuration mode command
shown on the graphic. You must perform a commit action to activate a commit script. In this example, we use the
Junos CLI auto-completion feature to verify the availability of the policy templates for configuration as the active IDP
policy. For more information regarding commit scripts, refer to http://www.juniper.net/techpubs for the Juniper
Networks technical publications.

The next step is to set the recommended policy as the active policy. Recall that only one IDP policy can be active on
a Junos security platform. As illustrated on the graphic, you must delete or deactivate the commit script. This step is
important because every subsequent commit will overwrite any changes that you made to template policies. The
final step to activating the recommended IDP policy is to apply the IDP action to a security policy. Do not forget to
commit the changes!
Verifying the Application of IDP Policy
The graphic shows a sample output of the show security policies policy-name command. By using the
detail option, you can verify that you enabled IDP for this security policy.

Monitoring IDP Status and Statistics
The graphic illustrates the show security idp status command. This command provides traffic statistics
related to the IDP policy engine. It also outputs the active IDP policy and IDP detector version.
IDP Counters
The command shown on the graphic along with one of the command arguments provides various counters useful in
monitoring IDP operation.
Monitoring Memory Utilization
If the IDP process runs out of memory, the software no longer evaluates traffic for attacks. Use the command shown
on the graphic to monitor memory utilization.

IDP Logging
You enable logging using the notification action. The Junos OS stores logs according to the data plane logging
configuration present on the Junos security platform.
When you configure an IDP rule for logging, each matching event creates a log entry. Because the software
generates IDP event logs during an attack, log generation happens in bursts, generating a much larger volume of
messages during an attack. In comparison to other event messages, the message size is also much larger for
attack-generated messages. The log volume and message size are important concerns for log management. To
better manage the volume of log messages, IDP supports log suppression. Log suppression limits multiple instances
of the same log occurring from the same or similar sessions over a given period of time. The software enables log
suppression by default but you can adjust attributes through configuration under the [edit security idp
sensor-configuration log suppression] hierarchy.
IDP Traceoptions
You can configure IDP traceoptions to log control plane events. Currently, the only flag available is the all flag. By
default, the software logs IDP traceoptions events to the /var/log/idpd file.
Review Questions

Answers
1.
The Junos OS processes the rule with the most severe action.
2.
The exempt rulebase exempts specified traffic from IDP policy.
3.
Evaluation of a rulebase stops only when the software matches a terminal rule.
4.
To apply an IDP policy, you must make it the active policy and reference an IDP action in a security policy.

Chapter 9: High Availability Clustering

• High availability (HA) clustering and its functionality;
• Chassis cluster components;
• Chassis cluster operation;
• Chassis cluster configuration; and
• Chassis cluster monitoring.
High Availability Characteristics

The Junos operating system high availability (HA) feature provides stateful session failover. This ability applies to TCP
and UDP sessions—those that deploy Network Address Translation (NAT), IP Security (IPsec), or authentication, as
well as those that do not.
High availability includes the synchronization of configuration files and the dynamic runtime session states between
Junos security platforms deploying it. The Junos implementation of high availability clustering currently supports an
active-passive redundancy for the control plane and an active-active redundancy for the data plane. Check the
Juniper Networks technical documentation for high availability support specific to your platform at
http://www.juniper.net/techpubs.
High Availability Clustering • Chapter 9–1

High Availability Using Chassis Clusters
The Junos OS achieves high availability on Junos security platforms using chassis clustering. Chassis clustering
provides network node redundancy by grouping two like devices into a cluster. The two nodes back each other up
with one node acting as the primary and the other as the secondary node, ensuring the stateful failover of processes
and services in the event of system or hardware failure. A control link between services processing cards (SPCs) or
revenue ports and an Ethernet data link between revenue ports connect two like devices. Junos security platforms
must be the same model, and all SPCs, network processing cards (NPCs), and input/output cards (IOCs) on high-end
platforms must have the same slot placement and hardware revision.
The chassis clustering feature in the Junos OS is built on the high availability methodology of Juniper Networks
M Series and T Series platforms and the TX Matrix platform, including multichassis clustering, active-passive Routing
Engines (REs), active-active Packet Forwarding Engines (PFEs), and graceful RE switchover capability.
Considering all the process implementations on M Series and T Series platforms, most of which have complete
hardware and control plane redundancies, the Junos implementation for Junos security platforms mirrors the RE and
PFE backup system and RE and PFE redundancy using Ethernet interfaces. Junos security platforms add redundancy
features by introducing interchassis clustering and stateful failovers. Devices in a chassis cluster synchronize the
configuration, kernel, and PFE session states across the cluster to facilitate high availability, failover of stateful
services, and load balancing.
Chassis Cluster Components

A chassis cluster consists of the following components:
• Cluster identification, including cluster-id id and node id;
• Redundancy groups (RGs); and
• Chassis cluster interfaces:
– fxp1: The control plane interface;
– fxp0: The out-of-band management interface;
– fab: The data plane interface; and
– reth: A redundancy interface.
Chapter 9–2 • High Availability Clustering
cluster-id Details
You can deploy up to fifteen chassis clusters in your environment. A unique cluster-id value, which ranges from
1–15, identifies each cluster. A Junos security platform can belong to only one cluster at any given time. The device
ignores high availability configuration and acts as a standalone device if a cluster-id value is zero. When a
device joins a cluster, it becomes a node within that cluster, identified by a node id. If you choose to alter a
cluster-id id or node id parameter, you must reboot the device to activate the changes.
node id Details
The node id uniquely identifies a Junos security platform within a cluster. Because only two nodes can exist in a
cluster, node id values range from 0–1.
Recall the interface naming structure used by the Junos OS:
(media type)-(fpc slot #)/(pic slot #)/(port #), for example, ge-1/0/3.
In the case of Junos security platforms, the Flexible PIC Concentrator (FPC) can be either an IOC, an SPC, a Physical
Interface Module (PIM), or a fixed interface. The software uses the node id value to offset the FPC slot value in the
interface name of a device. Specifically, the software uses the following formula to calculate the FPC slot number:
Cluster interface FPC slot number=
(node id * max FPC slots) + standalone FPC slot number.
For example, a Juniper Networks SRX5800 Services Gateway has a maximum of 12 slots. Using the FPC slot number
calculation, you can determine that the second slot on node 1 of a chassis cluster uses an interface name of ge-13/
x/y or xe-13/x/y.
Redundancy Group
A redundancy group (RG) is an abstract construct that includes and manages a collection of objects. It contains
objects on both nodes of a cluster. An RG is primary on one node and backup on the other node at any given time.
When an RG is primary on a node, its objects on that node are active.
Junos security platforms support up to 256 RGs. RGs are independent units of failover, and one RG’s primacy does
not affect the other RG’s primacy. In other words, one of the RGs can be primary on node 0, while the other RG is
primary on node 1. When an RG fails over, all its objects fail over together.
When you initialize a Junos security platform in chassis cluster mode, the system creates a redundancy group called
RG0. RG0 manages the primacy and failover between the REs on each node of the cluster. As is the case for all
redundancy groups, RG0 can be primary on only one node at a time. The node on which RG0 is primary determines
which RE is active in the cluster. You must explicitly create RGx in the configuration and manage interface
redundancy. RGx can contain up to 15 redundant Ethernet interfaces called reth interfaces. We discuss reth
interfaces in detail later in this material.

Three RG Object States
An RG object can be in one of the following three states:

• A blank state, which is the starting state for an RG;
• A primary state; or
• A secondary state.
RG Object State Transitions

As indicated on the diagram on the graphic, an RG object state can transition from blank to either primary or
secondary. In addition, an RG object in the primary state can transition to the secondary state, and vice versa. Both
primary and secondary states can transition back to the blank state when you delete an RG from the configuration
file or when the device reboots.
RG Primacy Rules
The rules for RG primacy are as follows:
• An RG is primary on the node with the higher priority.
• By default, both nodes have the same priority for RG0, but you can change the default setting to specify
which node is primary for RG0. You must explicitly configure the node priority for RGx.
• If you initialize both nodes of a cluster at the same time and you do not change the default setting for
RG0 node priority, Node 0 takes precedence.
• If one node of the cluster initializes before the other, the first node to initialize takes precedence and
remains the primary node for the RG unless the preempt configuration option is present. Note that the
preempt configuration option is not supported on RG0.
RG State Transitions
For RGx to fail over automatically to another node, the software must monitor its interfaces. When you configure an
RGx, you can specify a set of interfaces the RG is to monitor for status, checking whether the interface is up or down.
When you configure an interface for RGx to monitor, you give it a weight value. RGx has a threshold tolerance value
initially set to 255. When an interface monitored by RGx becomes unavailable, the software subtracts its weight from
the threshold. When the threshold reaches zero, all objects within RGx fail over to the other node.

Illustration of RGx’s Use for Load Balancing
The graphic illustrates an example of load balancing between two nodes of a cluster. Specifically, RG1 is primary on
Node 0 for destination network 10.10.0.0/16, and RG2 is primary on Node 1 for destination network 10.20.0.0/16.
In addition, RG1 is secondary on Node 1 for destination network 10.10.0.0/16, and RG2 is secondary on Node 0 for
destination network 10.20.0.0/16.
Chassis Cluster Interfaces—reth

A reth is a pseudo-interface that includes a physical interface from each node of a cluster. A reth can contain either
two physical Ethernet interfaces, referred to as child interfaces of the reth interface. Each reth can contain only two
interfaces because a cluster contains only two nodes. Although reth interfaces must be the same kind—either Fast
Ethernet, Gigabit Ethernet, or 10-Gigabit Ethernet—they do not need to be in the same slots on each node. A reth
child interface associates with the reth interface as part of the child interface configuration. A reth child interface
inherits properties of its parent interface. A reth interface inherits its failover properties from RGx. Consequently, a
reth interface can remain active even if one of its child interfaces becomes unavailable. Only one child interface of a
reth interface can accept and send traffic at a time. A reth interface has a virtual MAC address, which is based on
the cluster ID and the interface ID.
Chassis Cluster Interfaces—fxp0

Junos security platform management interfaces allow out-of-band network access and network management to
each node in the cluster. Only high-end security platforms contain an fxp0 interface. For branch security platforms in
a chassis cluster, the Junos OS designates one of the revenue ports to act as the fxp0 interface. Refer to your
product’s documentation at http://www.juniper.net/techpubs to determine which port acts as the fxp0 interface for
your specific branch device.
We recommend giving each node in a chassis cluster a unique IP address for the fxp0 interface of each node. This
practice allows independent node management. To accomplish this practice, you must configure interfaces in
separate configuration groups under the [edit groups] configuration hierarchy. We cover details regarding
configuration of groups later in this material.
Chassis Cluster Interfaces—fxp1

Each SPC on a high-end SRX Series platform has two ports for use as a chassis cluster control link, named fxp1.
Currently, the software supports only a single control link. On high-end security platforms, the control link connects
through ports on SPCs. Use Port 0 if the RE is in RE Slot 0 within the chassis, and use Port 1 if the RE is in RE Slot 1.

Branch security platforms use revenue ports for the chassis cluster control link. Check the documentation specific to
your device to determine which port to use.
On high-end security platforms, configuration is necessary to designate the ports associated with fxp1 as shown:
[edit chassis cluster]
user@host1# show
control-ports {
fpc slot port port;
fpc slot port port;
}
The system provides each fxp1 control link interface with an internal IP address and uses the proprietary Trivial
Network Protocol (TNP) to transmit the session state, the configuration file, and liveliness signals across the nodes.
The Junos OS periodically transmits heartbeat signals over the control link to determine the health of the control link.
If the number of missed heartbeats reaches the configured threshold and the fabric link is operational, the system
signals a control link failure.
If the control link fails, the Junos OS disables the secondary node to prevent the possibility of each node becoming
primary for all RGs, including RG0.
Once a secondary node is disabled, you must reboot the node to resume operation. You can make this reboot
automatic on some Junos security platforms using the control-link-recovery configuration option as follows:
{primary:node0}[edit chassis cluster]
user@host# show
control-link-recovery;
Chassis Cluster Interfaces—fab

The Junos OS uses the fabric (fab) interface for the high availability data plane. When the system creates the fab
interface, the software assigns it an internally derived IP address that it uses for packet transmission. The fab is a
physical connection between two Ethernet interfaces on the same LAN. Both interfaces must be the same media
type. Unlike the control link that has system-determined interfaces, you specify the physical interfaces to use for the
fab data link in the configuration.
Similar to the fxp1 control link, the fab link uses fabric probes to determine the health of the link. If the Junos OS
determines that there has been a fabric link failure, it disables the secondary node, and a reboot is required to
restore operation.
The Junos OS does not support traditional interface features such as firewall filters, policies, logical interfaces, or
system services on the fab link, and the fab link is not configured under a security zone. Although the Junos OS does
not support fragmentation on the fab link, it does support jumbo frames up to 8980 bytes. Therefore, we
recommend that no interface in a chassis cluster exceed this maximum transmission unit (MTU) size.
Purpose of Real-Time Objects

To provide for session or flow redundancy, the data plane synchronizes its state by sending special payload packets
named real-time objects (RTOs) from one node to the other across the fab data link. By transmitting information
about a session between the nodes, RTOs ensure the consistency and stability of sessions if a failover occurs; thus,
they enable the system to continue to process traffic belonging to existing sessions. To ensure session information
synchronization between the two nodes, the data plane gives RTO packets priority over transit traffic.
Dynamics of RTOs
The Junos OS creates RTOs dynamically in memory. Some examples of dynamically created RTOs include session
table entries and IPsec security associations (SAs).

Chassis Cluster Interface Summary
The graphic summarizes all the cluster interfaces that we just discussed.
Cluster Operation: Forming a Cluster
The first chassis in a cluster forms a cluster upon booting up. It transitions from the blank state to the primary state.
Cluster Operation: Joining a Cluster

A chassis can join an existing cluster. The RG0 of the joining chassis transitions from the blank state to the
secondary state. RGx transitions from the blank state to either the primary state or the secondary state based on a
combination of priorities and preempt configurations. The join operation causes the joining chassis to perform
configuration synchronization as well. A join operation might cause the existing cluster node to change its RGx states
from primary to secondary.
Cluster Operation: Leaving a Cluster
A leave action happens when a node chassis reboots or powers off. This leave action can trigger RG state changes
from secondary to primary in another cluster node.
Cluster Operation: Splitting a Cluster
The Junos OS offers automatic protection from split scenarios by disabling the secondary node if either the control
link or the fabric link suffers a loss of keepalives or heartbeat messages. You must reboot the disabled node to have
it rejoin the cluster. However, if the Junos OS detects a failure on both links simultaneously, such as in the case of a
system failure, both devices become primary nodes.

Cluster Operation: Merging a Cluster
A merge action happens when a split cluster regains connectivity. The merged cluster can cause RG state transitions
from primary to secondary.
One Node Handling Transit Traffic
The graphic illustrates the packet flow in active-passive mode for the data plane. In this case, Node 0 is the primary
node, and Node 1 is the secondary node.

Both Nodes Handling Transit Traffic
In active-active mode for the data plane, two nodes handle transit traffic. The graphic illustrates the packet flow in
which ingress and egress interfaces are on different devices of a cluster. The node containing the egress interface
for the first flow in a session always acts as the host of the session. In this case, the flow’s active session is on
Node 1, and the flow’s backup session is on Node 0.
At this time, Junos security platforms support active-active mode for the data plane only. The control plane always
acts in an active-passive fashion, with the secondary node providing redundancy to the primary node.
Connecting the Two Devices

Ensure that you interconnect two Junos security platforms of the same model, with SPCs inserted in identical slots
(on a high-end platform), as follows:
• Connect the ports for use as the control link. On high-end platforms, use the SPC port with the
same number as the RE slot. On branch platforms, use the appropriate revenue port specific to the
model of device.
• Connect the Ethernet interfaces of the two nodes to create the fabric link (fab interface).
Configuring Control Ports

For high-end platforms, enable the SPC control plane ports in the configuration and commit the configuration.
Enabling Clustering
Enabling chassis clustering involves setting a cluster-id id and node id on each chassis in the cluster. The
cluster-id value is the same on both nodes. To activate clustering, once you set the cluster-id id and the
node id, you must reboot the node designated as the primary device first, then reboot the desired secondary
node.

Enabling the Chassis Cluster
The graphic illustrates the configuration required to enable the SPC control plane ports for high-end security
platforms. It also displays the syntax of a command that is necessary to set up the cluster-id id and node id.
Note that you perform this command in operational mode and the mandatory reboot is available as part of the
command.
Enabling the Chassis Cluster on the Second Node

Because the second node inherits the configuration associated with the primary node, no control port configuration
is necessary. The graphic illustrates the operational mode command required to add the second node to the chassis
cluster.
Cluster Configuration Steps
Once you reboot a node of a cluster, you are ready to configure other cluster parameters. The graphic lists the
configuration steps you must follow to accomplish cluster configuration.

Configuring the Management Interface
You configure management access to the cluster by defining a unique hostname for each node and assigning a
unique IP address for the fxp0 interface on each node. Note that the configured group names must be node0 and
node1. You must apply the configured groups using the apply-groups configuration stanza, as illustrated on the
graphic.
Configuring Fabric Interfaces
You configure the fab interface between the two nodes using the syntax illustrated on the graphic. The member
interface for fab0 is an Ethernet interface on Node 0, and the member interface for fab1 is an Ethernet interface on
Node 1. Both fab interfaces must be of the same media type.

Configuring a Redundancy Group
The graphic illustrates the syntax necessary for configuring an RG. You perform the configuration under the
chassis cluster configuration stanza. The configuration includes specifying the following:
• The node priorities (the higher number takes precedence);
• The number of gratuitous Address Resolution Protocol (ARP) requests that an interface can send to
notify other network devices of its presence after an RG to which it belongs fails over;
• Weights to the monitored interfaces; and
• An optional preemption, which allows a node with a better priority to initiate a failover to become
primary for the configured RG.
Configuring a Redundant Ethernet Interface
To create a reth interface, you configure the two physical interfaces independently. You configure the rest of the
parameters pertaining to reth interfaces at the interfaces reth number configuration stanza. Once you
commit the configuration, all child interfaces of a reth interface inherit those parameters. Because reth interfaces
are pseudo-interfaces, you must define the number of reth interfaces in a cluster by configuring reth-count.

Configuring Cluster Failover Parameters
The following are the cluster failover parameters that you can configure, should you choose to alter their default
values:
• heartbeat-interval: Interval or duration when all nodes in the cluster receive the heartbeat
message broadcast; and
• heartbeat-threshold: Number of missed heartbeats that must be exceeded to declare the cluster
node dead.
Disabling a Chassis Cluster
The graphic illustrates the operational mode command used to remove a Junos security platform from a cluster.
Enter it first on the primary node and then on the secondary node. Because it will have its configuration synced to
the primary node configuration, the secondary node will also need its interfaces renamed.

Example: Network Diagram Prior to Issuing the Cluster-Forming Command
Consider the example on the graphic. Two high-end security platforms, host1 and host2, interconnect together using
Gigabit Ethernet interfaces as well as SPC control ports in Slot 3. We connected both nodes to the server site
using the ge-0/0/0 interface and to the Internet using the ge-1/0/0 interface.
Form a Cluster
To form a cluster using high-end security platforms, you must configure the control ports on the node. Because the
secondary node’s configuration will be synchronized with the primary node’s configuration, you are only required to
configure control ports on the node designated as primary. Make sure to commit the configuration.
For all Junos security platforms, use the operational mode commands shown on the graphic to set the cluster
identification number and node identification number. The operational mode command also allows you to perform
the mandatory reboot on each device. Remember to perform this operation first on the node designated to be the
primary node and then on the node designated as secondary.

Example: Network Diagram After Issuing the Cluster-Forming Command
After you reboot the SRX Series Services Gateways, they form a cluster. The cluster formation results in interface
names changing, as illustrated on the graphic.
Cluster Status Check
Use the show commands illustrated on the graphic to display the status of the chassis cluster and the cluster
interfaces.

Configuring the Management Interface
Next, configure the management interface using the groups and apply-groups configuration stanzas, as
illustrated on the graphic.
Configuring the Fabric Interfaces
In the example on the graphic, the fab0 and fab1 interfaces of the cluster use ge-0/0/2 and ge-12/0/2 physical
interfaces. The graphic depicts the configuration of the fab0 and fab1 interfaces as well as the resulting status. Note
that the fab interfaces now show a link status of up.

Configuring a Redundancy Group
The graphic illustrates the configuration of RG0 and RG1. Node 0 is primary because its priority is higher than Node
1’s priority. RG1 monitors the ge-0/0/0 interface connected to the server site. If the ge-0/0/0 interface becomes
unavailable, RG1 fails over to Node 1 and the ge-12/0/0 interface.
Viewing Redundancy Groups
To view the RG status, use the show chassis cluster status command. This command allows you to see
which nodes are primary and secondary for RG0 and RG1. You can also verify that you enabled preemption or if a
manual failover is in effect. We discuss manual failovers on a subsequent graphic.

Configuring reth Interfaces
In the example on the graphic, one reth interface is shown—reth1—and it belongs to RG1. Interfaces ge-0/0/0 and
ge-12/0/0 constitute the reth1 interface. The total number of reth interfaces that the cluster will recognize is two
(based on a reth-count value).
Configuring Cluster Failover Parameters
According to the configuration on the graphic, heartbeat messages between the nodes in the cluster happen every
1200 milliseconds. In addition, the system assumes the node is dead if the number of missed heartbeats exceeds
five.

Monitoring Cluster Statistics
Use the show chassis cluster statistics command to display chassis cluster counters. The counters are
useful for troubleshooting and verifying proper operation.
Manual Failover
You can initiate a failover manually with the request command shown on the graphic. A manual failover bumps up
the priority of the redundancy group for that member to 255. Be careful with manual failovers. An RG0 failover
implies an RE failover. An RE failover kills all processes running on the primary node and spawns them on the new
primary RE, which can result in a loss of state, such as routing state.

Resetting a Manual Failover
After a manual failover, the new primary node continues in that role until a reset or failback occurs. If a failback
occurs, the manual failover is lost, and the software bases state election on priority and preempt settings. A failback
in manual failover mode can occur if the primary node fails or if the threshold of an RG reaches zero.
Chassis Cluster Logging
Use the show log jsrpd command to view chassis cluster events. The jsrpd process is the process associated
with managing chassis cluster events. For some chassis cluster events, the software dynamically populates this log.
Traceoptions
You can also configure traceoptions for chassis cluster operations. You can set flags for many events.
{primary:node0}[edit]
user@host# set chassis cluster traceoptions flag ?
all Trace all events
cli Trace CLI events
configuration Trace configuration events
eventlib Trace event library events

fsm Trace finite state machine events

heartbeat Trace JSRPD heartbeats
init Trace initialization events
interface Trace interface related events
routing-socket Trace routing socket events
socket Trace socket events
uspipc Trace USP IPC events
Review Questions
Answers
1.
The control plane of a chassis cluster uses SPC ports on high-end systems and revenue ports on branch platforms and is
named fxp1. The data plane connects using physical ports named fab0 and fab1.
2.
The fab interface serves as the data plane link between nodes in a chassis cluster and transmits RTOs to replicate session state
between the two nodes.
3.
An RG is an abstract entity that manages the redundancy of a group of objects. The software creates RG0 when a chassis
cluster forms to manage primacy of REs. The software uses RGx to manage primacy of reth interfaces.
4.
The default threshold for interface monitoring is 255.


Jncis Sec

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Jncis Sec

Hochgeladen von

Copyright:

Verfügbare Formate

JNCIS-SEC Study Guide

Worldwide Education Services

1194 North Mathilda Avenue

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

CLI and GUI Text

Style Description Usage Example

Franklin Normal text. Most of what you read in the

Courier Console text:

Input Text Versus Output Text

Style Description Usage Example

Normal CLI No distinguishing variant. Physical interface:fxp0,

Style Description Usage Example

CLI Text where variable value is already policy my-peers

CLI Text where the variable’s value is Type set policy

Education Services Offerings

About This Publication

Juniper Networks Support

vii • Additional Information

Chapter 1: Introduction to Junos Security Platforms

This Chapter Discusses:

Built to Forward Packets

Packet Processing Is Stateless

Separate Broadcast Domains and Provide WAN Connectivity

Introduction to Junos Security Platforms • Chapter 1–1

Layer 3 Packet Forwarding

Promiscuous Behavior of a Traditional Router

Typical Treatment of Security

Chapter 1–2 • Introduction to Junos Security Platforms

Typical Router Positioning

Adding Security to the Network

Requirements for Firewall Devices

Introduction to Junos Security Platforms • Chapter 1–3

Firewall: Stateful Packet Processing

Firewall: NAT and PAT

Chapter 1–4 • Introduction to Junos Security Platforms

Firewall: Virtual Private Networks

Introduction to Junos Security Platforms • Chapter 1–5

Chapter 1–6 • Introduction to Junos Security Platforms

SRX Series High-End Systems

Introduction to Junos Security Platforms • Chapter 1–7

SRX Series High-End System Components

Physical Packet Flow for High-End Security Platforms

Chapter 1–8 • Introduction to Junos Security Platforms

SRX Series Branch Devices

Branch Platform System Components

Physical Packet Flow for Branch Security Platforms

Chapter 1–10 • Introduction to Junos Security Platforms

Junos Security Platforms Versus a Traditional Router

The Junos OS for Security Platforms Merges Routing and Security

Introduction to Junos Security Platforms • Chapter 1–11

Packet-Based Junos Forwarding

Chapter 1–12 • Introduction to Junos Security Platforms

Logical Packet Flow Details

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