Академический Документы
Профессиональный Документы
Культура Документы
tio
9.a
uc
d
ro Student Guide
ep
rR
fo
ot
USA
408-745-2000
www.juniper.net
n
tio
uc
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 Software has no
d
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
ro
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.
ep
rR
fo
ot
N
Contents
n
Traditional Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .2-8
Breaking the Tradition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-14
tio
JUNOS Software Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-23
uc
Zone Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-14
Monitoring Security Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-26
Lab 1: Configuring and Monitoring Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-32
d
Chapter 4: Security Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1
Overview of Security Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4-3
ro
Policy Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-12
Verifying Policy Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-22
Policy Scheduling and Rematching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-29
Policy Case Study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-35
ep
Case Study: Monitoring Security Policies: Part 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-45
Case Study: Monitoring Security Policies: Part 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-46
Lab 2: Security Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-49
rR
Contents • iii
Chapter 7: Network Address Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-1
NAT Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-3
Destination NAT Operation and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-8
Source NAT Operation and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-21
Proxy ARP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-40
Monitoring and Verifying NAT Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-43
Lab 5: Network Address Translation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7-48
n
VPN Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-3
Secure VPN Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-6
tio
IPsec Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-19
Configuration of IPsec VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-40
IPsec VPN Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-53
Lab 6: Implementing IPsec VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8-70
uc
Chapter 9: Introduction to Intrusion Detection and Prevention . . . . . . . . . . . . . . . . . . . . 9-1
Introduction to JUNOS Software IDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-3
IDP Policy Components and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-7
d
Signature Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-18
Case Study: Applying the Recommended IDP Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-24
ro
Monitoring IDP Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-28
Lab 7: Implementing IDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9-36
iv • Contents
Course Overview
JUNOS for Security Platforms covers the configuration, operation, and implementation of SRX
Series Services Gateways in a typical network environment. Key topics within this course
include security technologies such as security zones, security policies, intrusion detection and
prevention (IDP), Network Address Translation (NAT), high availability clusters, as well as details
pertaining to basic implementation, configuration, and management. The course includes
extensive hands-on labs configuring and monitoring JUNOS Software for SRX Series devices.
n
Objectives
After successfully completing this course, you should be able to perform the following:
tio
• Describe traditional routing and security and the current trends in
internetworking.
• Provide an overview of SRX Series Services Gateways and software architecture.
uc
• Describe the logical packet flow and session creation performed by SRX Series
Services Gateways.
• Describe, configure, and monitor zones.
d
• Describe, configure, and monitor security policies.
• Describe, configure, and monitor firewall user authentication.
•
•
ro
Describe various types of network attacks.
Configure and monitor SCREEN options to prevent network attacks.
ep
• Explain, implement, and monitor NAT as implemented on JUNOS security
platforms.
• Explain the purpose and mechanics of IPsec VPNs.
• Implement and monitor policy-based and route-based IPsec VPNs.
rR
Intended Audience
fo
The course content is aimed at operators of SRX Series Services Gateways. These operators
include network engineers, administrators, support personnel, and reseller support personnel.
Course Level
ot
Prerequisites
N
• The Introduction to JUNOS Software (IJS) and JUNOS Routing Essentials (JRE)
courses or equivalent experience; and
• Basic networking knowledge including an understanding of the OSI model and
TCP/IP.
. Course Overview • v
Course Agenda
Day 1
Chapter 1: Course Introduction
Chapter 2: Introduction to JUNOS Security Platforms
Chapter 3: Zones
n
Lab 1: Configuring and Monitoring Zones
Chapter 4: Security Policies
tio
Lab 2: Security Policies
Day 2
Chapter 5: Firewall User Authentication
uc
Lab 3: Configuring Firewall Authentication
Chapter 6: SCREEN Options
Lab 4: Implementing SCREEN Options
d
Chapter 7: Network Address Translation
Day 3
ro
Lab 5: Network Address Translation
vi • Course Agenda
Document Conventions
n
Franklin Normal text. Most of what you read in the Lab
tio
Gothic Guide and Student Guide.
uc
• Noncommand-related Exiting configuration
syntax mode
GUI text elements: Select File > Open, and then
click Configuration.conf in
• Menu names
d
the Filename text box.
• Text field entry
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
ot
field.
N
n
CLI policy my-peers
Variable assigned.
Click on my-peers in the dialog.
tio
GUI
variable
uc
the variable’s value as shown in the
GUI ping 10.0.1.1
lab guide might differ from the
Undefined
value the user must input. Select File > Save, and enter
filename in the Filename field.
d
ro
ep
rR
fo
ot
N
n
The JUNOS for Security Platforms Student Guide was developed and tested using software
version 9.5R1.8. Previous and later versions of software might behave differently so you
tio
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
uc
training@juniper.net.
Technical Publications
You can print technical manuals and release notes directly from the Internet in a variety of
d
formats:
• Go to http://www.juniper.net/techpubs/.
ro
• 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
ep
account representative.
support/, or at 1-888-314-JTAC (within the United States) or 408-745-2121 (from outside the
United States).
fo
ot
N
Additional Information • ix
n
tio
d uc
ro
ep
rR
fo
ot
N
x • Additional Information
JUNOS for Security Platforms
n
tio
Chapter 1: Course Introduction
d uc
ro
ep
rR
fo
ot
N
JUNOS for Security Platforms
n
tio
d uc
ro
ep
This Chapter Discusses:
• Objectives and course content information;
• Additional Juniper Networks, Inc. courses; and
rR
n
tio
d uc
ro
ep
Introductions
This slide asks several questions for you to answer during class introductions.
rR
fo
ot
N
n
tio
d uc
ro
ep
Course Contents
This slide lists the topics we discuss in this course.
rR
fo
ot
N
n
tio
d uc
ro
ep
Prerequisites
This slide lists the prerequisites for this course.
rR
fo
ot
N
n
tio
d uc
ro
ep
General Course Administration
This slide documents general aspects of classroom administration.
rR
fo
ot
N
n
tio
d uc
ro
ep
Training and Study Materials
This slide describes Education Services materials that are available for reference both
in the classroom and online.
rR
fo
ot
N
n
tio
d uc
ro
ep
Additional Resources
This slide describes additional resources available to assist you in the installation,
configuration, and operation of Juniper Networks products.
rR
fo
ot
N
n
tio
d uc
ro
ep
Satisfaction Feedback
Juniper Networks uses an electronic survey system to collect and analyze your
comments and feedback. Depending on the class you are taking, please complete the
rR
survey at the end of the class, or be sure to look for an e-mail about two weeks from
class completion that directs you to complete an online survey form. (Be sure to
provide us with your current e-mail address.)
Submitting your feedback entitles you to a certificate of class completion. We thank
you in advance for taking the time to help us improve our educational offerings.
fo
ot
N
n
tio
d uc
ro
ep
Juniper Networks Education Services Curriculum
Juniper Networks Education Services can help ensure that you have the knowledge
and skills to deploy and maintain cost-effective, high-performance networks for both
rR
enterprise and service provider environments. We have expert training staff with deep
technical and industry knowledge, providing you with instructor-led hands-on courses
as well as convenient, self-paced eLearning courses.
You can access the latest Education Services offerings covering a wide range of
platforms at http://www.juniper.net/us/en/training/technical_education/.
fo
ot
N
n
tio
d uc
ro
ep
JNTCP
The Juniper Networks Technical Certification Program (JNTCP) consists of
platform-specific, multitiered tracks that enable participants to demonstrate, through
rR
n
tio
d uc
ro
ep
Certification Levels
Each JNTCP track has one to four certification levels. Associate-level and
Specialist-level exams are computer-based exams composed of multiple choice
rR
n
tio
d uc
ro
ep
Prepping and Studying
This slide lists some options for those interested in prepping for Juniper Networks
certification.
rR
fo
ot
N
n
tio
d uc
ro
ep
Any Questions?
If you have any questions or concerns about the class you are attending, we suggest
that you voice them now so that your instructor can best address your needs during
rR
class.
fo
ot
N
n
tio
Chapter 2: Introduction to JUNOS Security
Platforms
d uc
ro
ep
rR
fo
ot
N
JUNOS for Security Platforms
n
tio
d uc
ro
ep
This Chapter Discusses:
• Traditional routing and security implementations;
• Current trends in internetworking;
rR
n
tio
d uc
ro
ep
Traditional Routing
The slide lists the topics we cover in this chapter. We discuss the highlighted topic
first.
rR
fo
ot
N
n
tio
d uc
ro
ep
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
rR
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.
ot
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.
n
tio
d uc
ro
ep
Layer 3 Packet Forwarding
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,
rR
OSPF, IS-IS, and BGP), statically entered routes, or both of these methods. Note that
routers forward packets based on the longest prefix match. For example, in the
graphic on the slide, 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.
fo
ot
N
n
tio
d uc
ro
ep
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
rR
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, as it
cannot detect malformed sessions. The network and the router itself are immediately
vulnerable to all security threats.
fo
routers are not equipped to secure a network. Traditionally, a full security solution
involves adding a separate firewall device.
N
n
tio
d uc
ro
ep
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
rR
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.
fo
ot
N
n
tio
d uc
ro
ep
Traditional Security
The slide highlights the topic we discuss next.
rR
fo
ot
N
n
tio
d uc
ro
ep
Adding Security to the Network
Standalone routers do not provide adequate security to enterprise networks and data
centers. As networks continue to expand, network applications continue to diversify
rR
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.
n
tio
d uc
ro
ep
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
rR
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.
ot
N
n
tio
d uc
ro
ep
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
rR
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.
fo
ot
N
n
tio
d uc
ro
ep
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:
rR
n
tio
d uc
ro
ep
Firewall Positioning
The slide illustrates a typical enterprise deployment of firewall devices. Small office
and home offices or retail storefronts use branch firewall devices to provide secured
rR
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.
fo
ot
N
n
tio
d uc
ro
ep
Breaking the Tradition
The slide highlights the topic we discuss next.
rR
fo
ot
N
n
tio
d uc
ro
ep
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
rR
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
fo
n
tio
d uc
ro
ep
A New Perspective
The graphic on the slide illustrates how a device with strong routing and firewall
features can be positioned at network boundaries. Remote offices can deploy SRX
rR
Series branch platforms running JUNOS Software 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
fo
n
tio
d uc
ro
ep
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 new architecture that
rR
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;
fo
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).
Continued on next page.
n
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).
tio
SRX Series High-End System Components
The SRX Series line of high end systems includes the following integral components:
uc
• 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
d
and processing capabilities.
• Network Processing Card (NPC): To ensure maximum processing
ro
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
ep
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
rR
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
ot
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
N
n
tio
d uc
ro
ep
Physical Packet Flow for High-End Security Platforms
The slide illustrates physical packet flow through a high-end security platform running
JUNOS Software. The packet flow coverage includes the SRX5000 and the SRX3000
rR
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.
fo
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 QoS, policing, and shaping.
N
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 QoS occurs.
5. The packet traverses the switch fabric to the IOC associated with the
egress interface and travels to the attached physical medium.
n
tio
d uc
ro
ep
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
rR
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
ot
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
N
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.
Continued on next page.
n
The SRX Series line of JUNOS security platforms include the following integral
components:
tio
• 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
uc
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
d
enterprise devices provide various media interfaces known at PIMs. The
media support includes 10/100 Ethernet, 10/100/1000 Ethernet,
ro
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
ep
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
rR
http://www.juniper.net/techpubs.
ot
N
n
tio
d uc
ro
ep
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
rR
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
fo
n
tio
d uc
ro
ep
JUNOS Software Architecture
The slide highlights the topic we discuss next.
rR
fo
ot
N
n
tio
d uc
ro
ep
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.
rR
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.
fo
n
tio
d uc
ro
ep
JUNOS for Security Platforms Merges Routing and Security
The new features of JUNOS for security platforms bring new core security capabilities
to JUNOS Software. Because the forwarding algorithm is session-based, security
rR
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 JUNOS Software. Juniper Networks world-class IDP
fo
technology is also fully integrated into JUNOS for security platforms. We discuss these
features later in this course.
ot
N
n
tio
d uc
ro
ep
JUNOS Software Elements
SRX Series Services Gateways use JUNOS Software as their base operating system. As
such, these devices deploy all the industry-proven processes of JUNOS Software, such
rR
as the routing process, management process, device control process, and others.
Another building element of JUNOS Software for security platforms is session-based
forwarding, thereby resulting in a strong suite of security features.
The JUNOS Software 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 industry-proven JUNOS Software. You can configure SRX
ot
Series Services Gateways using either the CLI or J-Web—the JUNOS Software-based
graphical user interface (GUI).
N
n
tio
d uc
ro
ep
Session-Based Forwarding
JUNOS Software for security platforms leverages ScreenOS software’s security
features as well as its flow-based nature. The first packet entering the device follows a
rR
series of path and policy determination schemes. JUNOS Software 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 JUNOS Software for
security platforms is security-based, all IPv4 packets entering the services gateway on
fo
an interface associate with an incoming zone. Likewise, all IPv4 packets exiting the
device on an interface associate with an outgoing zone. JUNOS Software 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.
ot
N
n
tio
d uc
ro
ep
Control Plane
The control plane on a JUNOS security platform is implemented using the Routing
Engine. The control plane consists of the JUNOS Software kernel, various processes,
rR
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, JUNOS Software for security
platforms deploys these features along with well-known, traditional JUNOS Software
features.
fo
Data Plane
The data plane on JUNOS security platforms, implemented on IOCs, NPCs, and SPCs
ot
for high-end devices and on CPU cores and PIMs for branch devices, consists of
JUNOS Software 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
N
n
tio
d uc
ro
ep
Logical Packet Flow Details
JUNOS security platforms handle an incoming packet as follows:
1. The software applies stateless policing filters and CoS classification to
rR
processing.
Continued on next page.
N
n
3. If destination NAT is used, the software performs address allocation.
tio
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
uc
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
d
checks the packet against defined policies to determine how to treat the
packet.
7.
8.
ro
If source NAT is used, the software performs address allocation.
The software sets up the ALG service vector.
9. The software creates and installs the session. Furthermore, the software
ep
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.
rR
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.
fo
n
tio
d uc
ro
ep
Session Maintenance
When a packet enters the system and does not match any existing sessions, JUNOS
Software creates a new session based on routing and security policy information.
rR
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.
fo
Session Cleanup
If no traffic matches the session during the service timeout, JUNOS Software ages out
the session and frees it to a common resource pool for a later reuse.
ot
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. We
discuss this topic more thoroughly in a subsequent chapter.
n
tio
d uc
ro
ep
Packet Flow Example: Part 1
We now apply the described decision process to a specific example. As the slide
shows, Host-B at 10.1.20.5 wants to initiate an HTTP session with the Web server at
rR
200.5.5.5. The traffic passes through an SRX Series Services Gateway and is
therefore subject to the decision process.
fo
ot
N
n
tio
d uc
ro
ep
Packet Flow Example: Part 2
The slide 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
rR
3. Now that the forwarding lookup is complete, the software can determine
the ingress and egress zones required for security policy evaluation.
ot
N
n
tio
d uc
ro
ep
Packet Flow Example: Part 3
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
rR
matches the policy statement on the slide. 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.
fo
6. The SRX Series Services Gateway then forwards the packet out
interface ge-1/0/0 (as determined by the destination lookup). JUNOS
Software allows traffic in both directions for this particular session to
pass without any subsequent policy evaluation.
ot
N
n
tio
d uc
ro
ep
This Chapter Discussed:
• Traditional routing and security implementations;
• Current trends in internetworking;
rR
n
tio
d uc
ro
ep
Review Questions
1.
rR
2.
3.
fo
4.
ot
N
n
tio
Chapter 3: Zones
d uc
ro
ep
rR
fo
ot
N
JUNOS for Security Platforms
n
tio
d uc
ro
ep
This Chapter Discusses:
• Zones and their purpose;
• Types of zones;
rR
• Application of zones;
• Configuring zones; and
• Monitoring zones.
fo
ot
N
n
tio
d uc
ro
ep
The Definition of Zones
The slide lists the topics we cover in this chapter. We discuss the highlighted topic
first.
rR
fo
ot
N
n
tio
d uc
ro
ep
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
rR
zones to regulate traffic through the JUNOS security platform. 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 platforms, chassis cluster fabric interfaces, and internal system
em0 interfaces cannot be assigned to a zone.
ot
N
n
tio
d uc
ro
ep
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
rR
n
tio
d uc
ro
ep
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
rR
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
fo
n
error: dcd_config_read fails to set parsing options
error: configuration check-out failed
tio
[edit]
user@host# commit check
[edit security zones security-zone untrust]
uc
'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
error: configuration check-out failed"
One exception to the rule exists when all interfaces are assigned to one zone using the
d
interface all configuration option. In this case, interfaces can belong to multiple
routing instances. ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
Interfaces, Zones, and Routing Instances
The slide summarizes logical relationships between interfaces, zones, and routing
instances.
rR
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
fo
contain one or more zones, which cannot be shared with other routing instances.
N
n
tio
d uc
ro
ep
Zone Types
The zones within JUNOS Software can be subdivided into two categories—user-defined
and system-defined. You can configure user-defined zones, but you cannot configure
rR
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.
fo
ot
N
n
tio
d uc
ro
ep
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
rR
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 JUNOS Software does not have any default security zones, and you
cannot share a security zone between routing instances.
fo
ot
N
n
tio
d uc
ro
ep
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
rR
n
tio
d uc
ro
ep
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
rR
delete an interface from a zone, the software assigns it back to the Null Zone. JUNOS
Software rejects all traffic to and from interfaces belonging to the Null Zone.
fo
ot
N
n
tio
d uc
ro
ep
Branch Platforms
JUNOS security platforms for the branch ship from the factory with a template
configuration that includes security zones. SRX high-end platforms do not contain
rR
zones in the factory-default template configuration and, therefore, you must configure
required zones manually.
Factory-Default Configuration
fo
trust zone. We discuss security policy in further detail in a subsequent chapter. The
zone names trust and untrust have no system-defined meaning. Like any zones
defined in the configuration, you can modify or delete them. You can revert a JUNOS
Software-based platform to its factory-default configuration by entering the load
N
n
tio
d uc
ro
ep
Zone Configuration
The slide highlights the topic we discuss next.
rR
fo
ot
N
n
tio
d uc
ro
ep
Zone Configuration Procedure
Zone configuration involves the following steps:
• Define a security or a functional zone;
rR
n
tio
d uc
ro
ep
Configuration Mode
To define a zone you must enter configuration mode, as illustrated on the slide.
rR
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 JUNOS Software.
ot
n
tio
d uc
ro
ep
Adding Logical Interfaces to the Zone
Now you are ready to add logical interfaces to the zone. The slide illustrates two
variations. The first example illustrates adding interface ge-0/0/1.0 to the security
rR
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, JUNOS Software 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.
fo
ot
N
n
tio
d uc
ro
ep
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
rR
n
tio
d uc
ro
ep
Specifying Types of Traffic Permitted into the Device: Part 2
When specifying types of traffic permitted into a JUNOS security platform, you use
some combination of system-services and protocols configuration options.
rR
JUNOS Software 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.
fo
n
+ apply-groups-except Don't inherit configuration data from these groups
dns DNS and DNS-proxy service
tio
except Type of incoming system-service traffic to disallow
finger Finger service
ftp FTP
http Web management service using HTTP
https Web management service using HTTP secured by SSL
uc
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
d
ntp Network Time Protocol service
ping Internet Control Message Protocol echo requests
rlogin Rlogin service ro
rpm Real-time performance monitoring
rsh Rsh service
snmp Simple Network Management Protocol service
snmp-trap Simple Network Management Protocol traps
ep
ssh SSH service
telnet Telnet service
tftp TFTP
traceroute Traceroute service
rR
n
bfd Bidirectional Forwarding Detection
bgp Border Gateway Protocol
tio
dvmrp Distance Vector Multicast Routing Protocol
except Protocol type of incoming traffic to disallow
igmp Internet Group Management Protocol
ldp Label Distribution Protocol
msdp Multicast Source Discovery Protocol
uc
nhrp Next Hop Resolution Protocol
ospf Open Shortest Path First
pgm Pragmatic General Multicast
pim Protocol Independent Multicast
d
rip Routing Information Protocol
router-discovery Router Discovery
rsvp Resource Reservation Protocol
ro
sap Session Announcement Protocol
vrrp Virtual Router Redundancy Protocol
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
Specifying Types of Traffic Permitted into the Device: Part 3
You can specify allowed traffic either at the zone level of configuration or the interface
level within a zone. As with any configuration in JUNOS Software, the precedence rule
rR
n
tio
d uc
ro
ep
Check Your Knowledge: Part 1
The slide shows an example of zone configuration. What types of traffic are allowed
into the specified zone and interfaces?
rR
fo
ot
N
n
tio
d uc
ro
ep
Check Your Knowledge: Part 2
The slide shows another example of zone configuration. What types of traffic are
allowed into the specified zone and interfaces?
rR
fo
ot
N
n
tio
d uc
ro
ep
Check Your Knowledge: Part 3
The slide shows the third example in this series. What does this configuration do?
rR
fo
ot
N
n
tio
d uc
ro
ep
Monitoring Security Zones
The slide highlights the topic we discuss next.
rR
fo
ot
N
n
tio
d uc
ro
ep
Monitoring Zones
The slide illustrates the show security zones command, which is useful for zone
monitoring. The command provides information on the zone type and name along with
rR
n
tio
d uc
ro
ep
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
rR
and system services allowed into the device through the corresponding interfaces. In
addition, the command provides information on flow statistics through the interface.
fo
ot
N
n
tio
d uc
ro
ep
Monitoring Traffic Permitted Into Interfaces: Part 2
The slide provides the continuation of the output from the previous page.
rR
fo
ot
N
n
tio
d uc
ro
ep
This Chapter Discussed:
• Zones and their purpose;
• Types of zones;
rR
• Application of zones;
• Zone configuration; and
• Zone monitoring.
fo
ot
N
n
tio
d uc
ro
ep
Review Questions
1.
rR
2.
3.
fo
4.
ot
N
n
tio
d uc
ro
ep
Lab 1: Configuring and Monitoring Zones
The slide provides the objective for this lab.
rR
fo
ot
N
n
tio
Chapter 4: Security Policies
d uc
ro
ep
rR
fo
ot
N
JUNOS for Security Platforms
n
tio
d uc
ro
ep
This Chapter Discusses:
• Security policy functionality;
• Components of a security policy;
rR
n
tio
d uc
ro
ep
Overview of Security Policy
The slide lists the topics we cover in this chapter. We discuss the highlighted topic
first.
rR
fo
ot
N
n
tio
d uc
ro
ep
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
rR
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. JUNOS Software provides a set of tools to implement
a network security policy within your organization. Security policies enforce a set of
fo
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.
ot
N
n
tio
d uc
ro
ep
Review: Packet Flow
The slide 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
rR
n
tio
d uc
ro
ep
Transit Traffic Examination
JUNOS Software for security platforms always examines transit traffic by using security
policies. As illustrated on the slide, should no match exist in the security policy, the
rR
default security policy applies to the packet. We highlight the default security policy in
a subsequent slide.
fo
ot
N
n
tio
d uc
ro
ep
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
rR
the traffic, the default policy action applies. We discuss the default security policy on
the next slide. If traffic matches a security policy that permits it, the device then
examines the list of services and protocols allowed into the destination interface
N
n
tio
d uc
ro
ep
System-Default Security Policy
By default, JUNOS Software denies all traffic through an SRX Series device. In fact, an
implicit default security policy exists that denies all packets. You can change this
rR
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
fo
n
tio
d uc
ro
ep
Security Policy Conceptual Example
We now examine an example of a packet flow through a JUNOS security platform.
rR
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 slide.
The following is the sequence of events that takes place:
fo
3. The Host B-to-Host D flow triggers the creation of the reverse flow from
Host D to Host B. The slide identifies the contents of this newly formed
session. It consists of two flows—source to destination and destination to
N
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.
n
tio
d uc
ro
ep
Policy Ordering
Because policies execute in the order of their appearance in the configuration file, you
should be aware of the following:
rR
• The last policy is the default policy, which has the default action of
denying all traffic.
ot
N
n
tio
d uc
ro
ep
Editing Security Configurations
Like any other JUNOS Software configuration stanza, you can delete, deactivate,
activate, insert, annotate, and copy security policies.
rR
fo
ot
N
n
tio
d uc
ro
ep
Policy Components
The slide highlights the topic we discuss next.
rR
fo
ot
N
n
tio
d uc
ro
ep
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—
rR
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 JUNOS Software
executes in the order of their configuration.
Recall that a zone is a collection of multiple logical interfaces with identical security
requirements. JUNOS Software always checks all transit traffic—intrazone and
fo
Under the user-defined name is a list of matching criteria and specified actions,
similar to a JUNOS Software routing policy. One major difference is that each security
policy must contain a matching source address, destination address, and application.
N
Actions for traffic matching the specified criteria include permit, deny, reject, log, or
count.
JUNOS Software 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. We discuss IDP and firewall authentication in
detail in subsequent chapters.
n
tio
d uc
ro
ep
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
rR
n
tio
d uc
ro
ep
Creating Address Book Entries
The slide 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
rR
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.
fo
ot
N
n
tio
d uc
ro
ep
Defining Custom Applications
JUNOS Software 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
rR
expanding the overall list), which gives you the capability to support complex
applications.
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
fo
gateway (ALG). A user-configured application has a timeout value associated with it.
JUNOS Software 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.
ot
N
n
tio
d uc
ro
ep
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
rR
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.
fo
ot
N
n
tio
d uc
ro
ep
Basic Policy Actions
Each policy has a list of basic and advanced actions associated with it. The basic
actions are the following:
rR
n
tio
d uc
ro
ep
Advanced Permit Settings
Among the policy actions mentioned on the previous slide, the following advanced
permit settings exist:
rR
• Firewall authentication;
• IPsec VPN tunnel;
• IDP; and
• UTM features.
fo
Firewall authentication enables you to restrict and permit users accessing protected
resources that could be located in different zones. JUNOS Software offers two
methods of firewall authentication:
• Pass-through: Firewall users that are using FTP, Telnet, or the Hypertext
ot
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.
Continued on next page.
n
various attack detection and prevention techniques. We discuss IDP in more detail in
the chapter titled, “Introduction to IDP”.
tio
In branch devices only, a policy can also associate traffic with UTM features such as
antivirus, content filtering, and Web filtering.
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
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
rR
• 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.
ot
N
n
tio
d uc
ro
ep
Verifying Policy Operation
The slide highlights the topic we discuss next.
rR
fo
ot
N
n
tio
d uc
ro
ep
Control Plane Logging
JUNOS Software 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;
rR
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 slide shows the control plane logging statements present
in a factory-default configuration.
fo
ot
N
n
tio
d uc
ro
ep
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
rR
session-init configuration options within a security policy to log the start and
close of sessions matching a policy.
The slide 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.
fo
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 slide, and include the
structured-data configuration option.
ot
N
n
tio
d uc
ro
ep
High-End SRX Series Data Plane Logging
Data plane logging in high-end SRX Series devices must go to an external syslog
device. JUNOS Software does not support local data plane logging because of the high
rR
volume of session handling that a high-end SRX Series Services Gateway supports.
The slide illustrates the configuration of data plane logging for SRX Series high-end
devices.
Currently, JUNOS Software supports one stream of logging traffic. Supported
collection devices include UNIX syslogd-based servers and Juniper Networks STRM.
fo
ot
N
n
tio
d uc
ro
ep
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 slide illustrates the configuration of the
rR
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. The case study later in this
chapter provides examples of both forms of statistics collection.
ot
N
n
tio
d uc
ro
ep
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
rR
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
fo
0 sessions displayed
N
0 sessions displayed
1 sessions displayed
n
tio
d uc
ro
ep
Tracing Security Policy
The configuration shown on the slide enables the tracing of security policy evaluation
and sessions on a JUNOS security platform. Use the packet-filter configuration
rR
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, it is a good practice to disable
traceoptions when not troubleshooting the device to reduce the impact on system
resources.
fo
ot
N
n
tio
d uc
ro
ep
Policy Scheduling and Rematching
The slide highlights the topic we discuss next.
rR
fo
ot
N
n
tio
d uc
ro
ep
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
rR
system time updates either through manual configuration or through the Network
Time Protocol (NTP) by synchronizing itself with the time changes.
n
tio
d uc
ro
ep
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
rR
n
tio
d uc
ro
ep
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,
rR
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.
fo
ot
N
n
tio
d uc
ro
ep
Optionally Applying the policy-rematch Statement
JUNOS Software’s default behavior is to not disturb sessions in progress when you
make configuration changes to security policies. For example, you can modify an
rR
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
fo
n
to either deny or reject: all existing sessions are dropped; and
– The software modifies some combination of source address,
tio
destination addresses, and applications fields: JUNOS Software
re-evaluates policy lookup.
• When the policy-rematch flag is disabled (default behavior):
– The software inserts a policy: no impact;
uc
– 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,
d
destination addresses, and applications fields: all existing
sessions continue unchanged.
ro
Note that irrespective of the value of policy-rematch policy flag, deletion of the
policy causes the device to drop all impacted existing sessions.
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
Policy Case Study
The slide highlights the topic we discuss next.
rR
fo
ot
N
n
tio
d uc
ro
ep
Case Study: Creating Policies
The next series of slides 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
rR
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.
fo
ot
N
n
tio
d uc
ro
ep
Case Study: Entering Host Addresses into the HR Zone
The slide 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
rR
respectively. The rest of the 10.1.0.0/16 subnet is also defined, which is named
other-10-1 in the address book. In addition, the PC_A and PC_B addresses are
grouped into an address set named HR_PCs.
fo
ot
N
n
tio
d uc
ro
ep
Case Study: Entering Host Addresses into the Public Zone
The slide 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
rR
n
tio
d uc
ro
ep
Case Study: Adding New Applications
The slide presents the configuration of a new application, HR-telnet, for the HR
Zone. The configuration shows that the new application is added under the
rR
n
tio
d uc
ro
ep
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 slide, is to
rR
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.
fo
ot
N
n
tio
d uc
ro
ep
Case Study: Creating Policy Entries: Part 2
The slide 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
rR
n
tio
d uc
ro
ep
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
rR
(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.
fo
ot
N
n
tio
d uc
ro
ep
Case Study: Optionally Applying a Scheduler
The slide shows the application of the previously defined scheduler schedulerHR to
the HR-to-Public policy.
rR
fo
ot
N
n
tio
d uc
ro
ep
Check Your Knowledge
What are the answers to the questions posed on the slide?
rR
fo
ot
N
n
tio
d uc
ro
ep
Case Study: Monitoring Security Policies: Part 1
The slide 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.
rR
fo
ot
N
n
tio
d uc
ro
ep
Case Study: Monitoring Security Policies: Part 2
The slide 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
rR
syslogd-enabled server.
fo
ot
N
n
tio
d uc
ro
ep
This Chapter Discussed:
• Security policy functionality;
• Security policy configuration, including:
rR
n
tio
uc
d
ro
ep
Review Questions
1.
rR
2.
3.
fo
4.
ot
N
n
tio
d uc
ro
ep
Lab 2: Security Policies
The slide provides the objective for the lab.
rR
fo
ot
N
n
tio
d uc
ro
ep
rR
fo
ot
N
n
tio
Chapter 5: Firewall User Authentication
d uc
ro
ep
rR
fo
ot
N
JUNOS for Security Platforms
n
tio
d uc
ro
ep
This Chapter Discusses:
• The purpose of firewall user authentication;
• Implementing pass-through authentication;
rR
n
tio
d uc
ro
ep
Firewall User Authentication Overview
The slide lists the topics we cover in this chapter. We discuss the highlighted topic
first.
rR
fo
ot
N
n
tio
d uc
ro
ep
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
rR
to determine the authentication result. The security policy must also allow traffic flow.
Once the user receives authentication, subsequent sessions from the same source IP
address bypass firewall user authentication. This behavior is especially important
N
when considering the usage of firewall user authentication for a network that might
have source-based Network Address Translation (NAT) employed.
n
tio
d uc
ro
ep
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
rR
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
fo
Web Authentication
ot
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
N
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.
n
tio
d uc
ro
ep
Local Authentication
JUNOS Software supports local authentication on the JUNOS security platform itself as
well as RADIUS, LDAP, and SecurID external authentication servers. The local
rR
RADIUS Authentication
JUNOS Software supports Juniper Network’s Steel-Belted Radius for authentication as
fo
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.
ot
LDAP Authentication
An LDAP server is another form of external authentication server. JUNOS Software
supports authentication only when utilizing an LDAP server. JUNOS Software is
N
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. JUNOS Software supports SecurID servers for authentication only
and does not support the SecurID challenge feature.
n
tio
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
Pass-Through Authentication
The slide highlights the topic we discuss next.
rR
fo
ot
N
n
tio
d uc
ro
ep
Pass-Through Authentication
The slide 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
rR
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. JUNOS Software 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.
fo
n
tio
d uc
ro
ep
Creating an Access Profile
The slide 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
rR
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.
fo
ot
N
n
tio
d uc
ro
ep
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 slide shows a basic example of this configuration. JUNOS
rR
Software also allows you to set a customized banner that will display to the end user.
JUNOS Software can display an initial login banner, a successful authentication
banner, and a failed authentication banner when configuring pass-through
authentication.
fo
ot
N
n
tio
d uc
ro
ep
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
rR
and have an extended action of permit, specifying the type of firewall authentication to
use. The slide shows an example of applying pass-through firewall authentication to a
security policy.
fo
ot
N
n
tio
d uc
ro
ep
Web Authentication
The slide highlights the topic we discuss next.
rR
fo
ot
N
n
tio
d uc
ro
ep
Web Authentication
The slide illustrates the process used for Web firewall authentication. A user that
requires access to a remote network resource must first access the JUNOS security
rR
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. JUNOS
Software 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
fo
n
tio
d uc
ro
ep
Enabling the HTTP Process
To use Web authentication, the SRX Series device must initiate the httpd process. The
slide highlights the required configuration to enable this system process for the
rR
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.
fo
ot
N
n
tio
d uc
ro
ep
Enabling Interface for Web Authentication
The interface that users access for Web authentication must be enabled for
authentication. The slide illustrates a sample configuration for enabling Web
rR
n
tio
d uc
ro
ep
Creating an Access Profile
Web authentication can use the same profile as pass-through authentication. The
example on the slide shows the configuration of a user-defined profile name. One or
rR
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.
The access profile must associate with Web authentication using the same
configuration structure as pass-through authentication. The slide shows a basic
example of this configuration. JUNOS Software also allows you to set a customized
banner that will display to the end user. Web authentication supports a customized
ot
n
tio
d uc
ro
ep
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
rR
conditions and have an extended action of permit, specifying the type of firewall
authentication to use. The slide shows an example of applying Web firewall
authentication to a security policy.
fo
ot
N
n
tio
d uc
ro
ep
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, JUNOS Software allows Web
rR
redirection. The slide 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. JUNOS Software 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
fo
authentication.
ot
N
n
tio
d uc
ro
ep
Client Groups
The slide highlights the topic we discuss next.
rR
fo
ot
N
n
tio
d uc
ro
ep
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
rR
same manner in which it references individual clients. The slide shows a simple
conceptual example of using client groups to manage multiple users. The next two
slides utilize this example for illustrating the configuration of client groups.
fo
ot
N
n
tio
d uc
ro
ep
Adding Client Groups to a User
The slide provides an example configuration of three users associated with various
groups. A number of groups (contained in square brackets in the example
rR
n
tio
d uc
ro
ep
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
rR
slide illustrates the use of a client group in a security policy. In this example, Group-A
from the previous slide is subject to pass-through authentication.
fo
ot
N
n
tio
d uc
ro
ep
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
rR
with user1 and user2. Therefore, user1 and user2 have access to the engineering
remote network resource (if they authenticate successfully).
n
tio
d uc
ro
ep
Default Client Groups
JUNOS Software 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
rR
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.
fo
ot
N
n
tio
d uc
ro
ep
Using External Authentication Servers
The slide highlights the topic we discuss next.
rR
fo
ot
N
n
tio
d uc
ro
ep
Adding Servers to the Access Profile
You configure external authentication server details within an access profile. JUNOS
Software supports only one external authentication server for access profiles, but you
rR
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, JUNOS Software still consults the local password
database. However, if the listed external authentication method fails, JUNOS Software
fo
does not consult the local password database, denying user access.
ot
N
n
tio
d uc
ro
ep
Verifying Firewall User Authentication
The slide highlights the topic we discuss next.
rR
fo
ot
N
n
tio
d uc
ro
ep
Viewing the Authentication Table
The first example on the slide illustrates how to view the current authentication table.
This table contains a list of users and their associated access profiles. It shows the
rR
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 ?
fo
Possible completions:
<[Enter]> Execute this command
address Locate authentication entry by ip address
identifier Locate authentication entry by id
ot
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.
n
tio
d uc
ro
ep
This Chapter Discussed:
• The purpose of firewall user authentication;
• Implementation of pass-through authentication;
rR
n
tio
d uc
ro
ep
Review Questions
1.
rR
2.
3.
fo
4.
ot
N
n
tio
d uc
ro
ep
Lab 3: Configuring Firewall Authentication
The slide provides the objective for this lab.
rR
fo
ot
N
n
tio
Chapter 6: SCREEN Options
d uc
ro
ep
rR
fo
ot
N
JUNOS for Security Platforms
n
tio
d uc
ro
ep
This Chapter Discusses:
• SCREEN options and their meanings;
• Various types of attacks prevented by SCREEN options;
rR
n
tio
d uc
ro
ep
Multilayer Network Protection
The slide lists the topics we cover in this chapter. We discuss the highlighted topic
first.
rR
fo
ot
N
n
tio
d uc
ro
ep
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
rR
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 and unknowingly hiding an attack within their
sessions. The trend of working at home and using a work PC for personal
ot
n
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)
tio
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.
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
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
rR
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.
Continued on next page.
fo
ot
N
n
• Site-to-site communications, both employee and nonemployee, are the
interactions between two offices of any type or any size. The site-to-site
tio
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 PC that has been compromised. Internal attacks
are increasingly common and can include unauthorized server access,
improper use of bandwidth, and planting of spyware.
uc
• 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
d
widest range of attacks using an assortment of security layers that can
include a VPN, denial of service (DoS) protection, a firewall, antivirus
ro
scanning, an intrusion detection service (IDS), and possibly antispam
scanning.
• At the heart of an enterprise is the network data center (or network core)
ep
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
rR
n
tio
d uc
ro
ep
Attack Detection System: SCREEN Options
The most obvious element of JUNOS Software for security platforms is basic access
control using security policies. These policies define who and what has access to the
rR
network. JUNOS Software 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.
fo
Through the deployment of custom security zones, you can use JUNOS Software 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.
ot
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
N
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. JUNOS Software
applies SCREEN checks to traffic prior to the security policy processing, thereby
resulting in less resource utilization.
n
tio
d uc
ro
ep
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
rR
results in fewer resources used and better protection of the JUNOS security platform
itself.
fo
ot
N
n
tio
d uc
ro
ep
Stages and Types of Attacks
The slide highlights the topic we discuss next.
rR
fo
ot
N
n
tio
d uc
ro
ep
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
rR
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
fo
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
ot
n
tio
d uc
ro
ep
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.
rR
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.
fo
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
ot
service to target.
IP Options
N
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.
Continued on next page.
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
n
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.
tio
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
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
rR
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 establish. An attacker can also launch a network DoS or a DoS targeting
various operating systems.
This chapter explains each of the attacks and JUNOS Software’s ability to handle
fo
these attacks.
ot
N
n
tio
d uc
ro
ep
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
rR
n
tio
d uc
ro
ep
Using JUNOS Software SCREEN Options—Reconnaissance Attack
Handling
The slide highlights the topic we discuss next.
rR
fo
ot
N
n
tio
d uc
ro
ep
SCREEN Options—Best Practices
Prior to analyzing JUNOS Software SCREEN options in detail, we discuss best practice
suggestions for SCREEN option use.
rR
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
fo
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.
N
n
tio
d uc
ro
ep
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
rR
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
fo
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.
The Defense
ot
JUNOS Software 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
N
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 device
flags that remote host as an address sweep attacker. The flagging process results in
the rejection of all further ICMP echo requests from that host for the remainder of the
configured threshold time period.
Continued on next page.
n
tio
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
IP Address Sweep and Port Scanning—SCREEN Options
The slide 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
rR
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
fo
the chapter.
N
n
tio
d uc
ro
ep
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
rR
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.
fo
The Defense
To compensate for the vulnerability that these IP options fields create, JUNOS
ot
Software 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.
N
n
tio
d uc
ro
ep
IP Options—SCREEN Options
The slide 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
rR
SCREEN options to detect the IP options that an attacker can use. These IP options
fields include record route, timestamp, security, and stream ID. JUNOS Software flags
an event in which a device configured with the appropriate SCREEN options receives a
packet with any of these IP options. JUNOS Software marks the event as a network
reconnaissance attack and records the associated ingress interface.
fo
The slide 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 chapter.
ot
N
n
tio
d uc
ro
ep
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
rR
ways. With that knowledge, an attacker can decide which further attack might inflict
more damage to the device, the network, or both.
The Defense
fo
JUNOS Software 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
ot
• No flags set.
TCP traffic matching any of these criteria is immediately, and silently, dropped.
N
n
tio
d uc
ro
ep
Operating System Probes—SCREEN Options
The slide illustrates the TCP header, highlighting the SYN and FIN flags, which an
attacker might use to launch the attack. The slide also illustrates the configuration of
rR
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
fo
them. To activate the SCREEN options, you must apply them within a security zone. We
address this topic later in the chapter.
N
n
tio
d uc
ro
ep
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
rR
The Defense
JUNOS Software provides IP address spoofing detection with the help of forwarding
fo
table entries. JUNOS Software 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, JUNOS Software silently drops all spoofed packets.
ot
N
n
tio
d uc
ro
ep
IP Spoofing Detection—SCREEN Option
The slide illustrates an IP spoofing attack in which the attacker uses an IP address
belonging to the range of IP addresses within the private zone. JUNOS Software
rR
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.
fo
To set up the JUNOS Software IP spoofing SCREEN option, you must perform the
configuration shown on the slide. 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 chapter.
ot
N
n
tio
d uc
ro
ep
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.
rR
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.
The Defense
fo
Depending on the configuration, JUNOS Software 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.
ot
N
n
tio
d uc
ro
ep
IP Source Route Options—SCREEN Options
Using the illustration shown on the slide, 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
rR
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
fo
packet arrives at the ge-1/0/0 interface, the JUNOS security platform rejects it.
To set up the JUNOS Software IP source route options SCREEN options, you must
perform configuration as shown on the slide. You can configure each of the options
independently. Note that this configuration only defines the SCREEN options—it does
ot
not activate them. To activate the SCREEN options, you must apply them within a
security zone. We address this topic later in the chapter.
N
n
tio
d uc
ro
ep
Using JUNOS Software SCREEN Options—Denial of Service Attack
Handling
The slide highlights the topic we discuss next.
rR
fo
ot
N
n
tio
d uc
ro
ep
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
rR
attack because a firewall under DoS stops sending any traffic to and from a protected
network.
proxy flood.
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. JUNOS Software has the capability to mitigate
those attacks, which we discuss in the upcoming pages.
Continued on next page.
n
tio
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
The Attack
The slide lists some of the forms that session table floods can take.
rR
The Defense
To control session table floods, JUNOS Software 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
fo
servers). By recognizing that all connection attempts originate from the same source
IP address, JUNOS Software’s session table flood control also mitigates any attempts
to fill up the session table of the attacked JUNOS security device.
In addition to the source-based session limit, JUNOS Software offers the flexibility to
limit the number of concurrent sessions to the same destination IP address, which
ot
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.
N
n
tio
d uc
ro
ep
Session Table Flood—SCREEN Option
The slide illustrates the required configuration to limit the number of concurrent
sessions based on source IP address, destination IP address, or both.
rR
n
tio
d uc
ro
ep
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
rR
and immobilize themselves. In the illustration shown on the slide, a malicious user
initiates a Telnet connection. The user sends a SYN segment to the Telnet server
behind the JUNOS security platform. JUNOS Software 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 3-way handshake is
complete. The server sends a login prompt to the user. The malicious user does not
fo
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.
ot
N
n
tio
d uc
ro
ep
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
rR
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. JUNOS Software 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
fo
connections.
The slide 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
ot
activate the SCREEN option, you must apply it within a security zone. We address this
topic later in the chapter.
N
n
tio
d uc
ro
ep
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
rR
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
fo
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.
The Defense
ot
JUNOS Software 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
N
shields hosts on the protected network from incomplete 3-way handshakes. The next
two pages list the specifics of these protection schemes.
n
tio
d uc
ro
ep
SYN Floods—SCREEN Options
The slide illustrates the JUNOS Software SCREEN options that you can implement to
handle SYN floods.
rR
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
in the chapter.
Continued on next page.
fo
ot
N
n
second required to trigger the SYN proxy mechanism. Although you can
set any threshold number within a specified range, we recommend that
tio
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
uc
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
d
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
ro
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
ep
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.
rR
fo
ot
N
n
tio
d uc
ro
ep
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
rR
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.
fo
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. JUNOS Software then sends a SYN/ACK
N
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.
n
tio
d uc
ro
ep
SYN Cookie Handling
The slide illustrates how a TCP connection establishes when a SYN cookie is active.
Once the SYN cookie is enabled, the JUNOS security platform becomes the
rR
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
fo
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 JUNOS Software receives a SYN/ACK from the
ot
destination host, it sends ACK messages to the destination and the originating hosts.
Now the connection establishes and the two hosts can communicate directly.
N
n
tio
d uc
ro
ep
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.
rR
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.
ot
valid connections.
n
tio
d uc
ro
ep
ICMP and UDP Flood Handling—SCREEN Options
The slide illustrates an attacker trying to overload the target with an ICMP flood, a UDP
flood, or both. The slide illustrates the configuration syntax for ICMP and UDP flood
rR
protection. Note that the configuration shown on the slide only defines the SCREEN
options. To activate the SCREEN options, you must apply them within a security zone.
We address this topic later in the chapter.
fo
ot
N
n
tio
d uc
ro
ep
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
rR
The Defense
When you enable the JUNOS Software SCREEN option to block LAND attacks, JUNOS
Software combines elements of the SYN flood defense and IP spoofing protection to
detect software and block any malicious attempts of this nature.
ot
N
n
tio
d uc
ro
ep
LAND Attack—SCREEN Option
The slide illustrates the impact of the LAND attack on network resources.
Once you enable the LAND attack SCREEN option, the network is protected from the
rR
attack.
The slide 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 in
the chapter.
fo
ot
N
n
tio
d uc
ro
ep
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
rR
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
ot
The Defense
To handle the Ping of Death attack, the JUNOS Software 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
Software 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.
n
tio
d uc
ro
ep
PC-Based OS DoS—SCREEN Options
The slide illustrates the syntax for configuring the Ping of Death, Teardrop, and
WinNuke SCREEN options.
rR
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 in the chapter.
fo
ot
N
n
tio
d uc
ro
ep
Using JUNOS Software SCREEN Options—Suspicious Packets Attack
Handling
The slide highlights the topic we discuss next.
rR
fo
ot
N
n
tio
d uc
ro
ep
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,
rR
The Defense
JUNOS Software blocks any fragmented ICMP packet. In addition, the software drops
fo
n
tio
d uc
ro
ep
ICMP Abnormalities Detection—SCREEN Option
The slide 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
rR
fragments) field. Once you set the ICMP abnormalities detection SCREEN option,
JUNOS Software 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 slide.
fo
Note that this configuration only defines the SCREEN option. To activate the SCREEN
option, you must apply it within a security zone. We address this topic later in the
chapter.
ot
N
n
tio
d uc
ro
ep
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
rR
fields within a packet. Attackers can use these malformed packets to compromise
hosts on the network.
N
The Defense
Once you define the corresponding SCREEN option, JUNOS Software 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.
n
tio
d uc
ro
ep
IP Packet Fragments and Bad IP Options Detection—SCREEN Option
The slide illustrates an IP packet header and highlights the more fragment (M),
fragment offset and IP options fields. Using the block-frag SCREEN option, JUNOS
rR
Software 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
fo
n
tio
d uc
ro
ep
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
rR
The Defense
fo
Once you define the corresponding SCREEN option, JUNOS Software detects and
drops any packet that uses an unknown protocol.
ot
N
n
tio
d uc
ro
ep
Unknown Protocols—SCREEN Option
The slide illustrates an IP packet header and highlights the protocol field containing
the protocol number. To set up the unknown protocols detection SCREEN option, you
rR
n
tio
d uc
ro
ep
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
rR
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.
fo
The Defense
Once you define the corresponding SCREEN option, JUNOS Software detects and
drops all received SYN fragments.
ot
N
n
tio
d uc
ro
ep
SYN Fragments—SCREEN Option
The slide 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
rR
header. Using the syn-frag SCREEN option, JUNOS Software 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 slide.
fo
Note that this configuration only defines the SCREEN option. To activate the SCREEN
option, you must apply it within a security zone. We address this topic later in the
chapter.
ot
N
n
tio
d uc
ro
ep
Applying and Monitoring SCREEN Options
The slide highlights the topic we discuss next.
rR
fo
ot
N
n
tio
d uc
ro
ep
Syntax for SCREEN Options Commands
The slide illustrates the JUNOS Software syntax that you must use when configuring
SCREEN options.
rR
First you must define the SCREEN options. Then you must apply these options to the
desired zone. Recall that JUNOS Software applies SCREEN options at the ingress zone
of the JUNOS security platform prior to applying any security policy or route lookup.
fo
ot
N
n
tio
d uc
ro
ep
Example
Consider the example illustrated on the slide. Two zones exist in this network: private
and public. The objective is to use SCREEN options to protect the private zone from
rR
n
tio
d uc
ro
ep
Case Study: Step 1—Creating the SCREEN Option
The slide illustrates the creation of a SCREEN option named protect, which lists the
necessary options needed to meet the objective from the previous slide. The following
rR
• 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.
ot
ICMP fragmented packets, you are also automatically enabling protection from the
Ping of Death attack.
n
tio
d uc
ro
ep
Example: Step 2—Applying the SCREEN Option
The slide illustrates the application of the SCREEN option to the public zone.
rR
fo
ot
N
n
tio
d uc
ro
ep
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
rR
n
tio
d uc
ro
ep
Attack Monitoring: Part 2
The slide shows the result of the show security screen ids-option
screen-name command, which displays the protect SCREEN option content.
rR
Note the correspondence between the actual configuration of the protect SCREEN
option and the monitoring show security screen ids-option
screen-name command.
fo
ot
N
n
tio
d uc
ro
ep
Attack Monitoring: Part 3
The slide illustrates an example traceoptions configuration for monitoring
SCREEN options operations. After committing the configuration, you can view the
rR
n
tio
d uc
ro
ep
This Chapter Discussed:
• The meaning of SCREEN options;
• Various types of attacks that SCREEN options can detect and prevent;
rR
n
tio
d uc
ro
ep
Review Questions
1.
rR
2.
3.
fo
4.
5.
ot
N
n
tio
d uc
ro
ep
Lab 4: Implementing SCREEN Options
The slide provides the objective for this lab.
rR
fo
ot
N
n
tio
Chapter 7: Network Address Translation
d uc
ro
ep
rR
fo
ot
N
JUNOS for Security Platforms
n
tio
d uc
ro
ep
This Chapter Discusses:
• The purpose and functionality of Network Address Translation (NAT) and
Port Address Translation (PAT);
rR
• NAT processing;
• Configuration of destination NAT
• Configuration of source NAT; and
• Monitoring and verifying NAT operation.
fo
ot
N
n
tio
d uc
ro
ep
NAT Overview
The slide lists the topics we cover in this chapter. We discuss the highlighted topic
first.
rR
fo
ot
N
n
tio
d uc
ro
ep
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
rR
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
fo
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.
n
tio
d uc
ro
ep
Review: Packet Flow
A JUNOS security platform implements NAT and PAT into both first path and fast path
flows processing. The slide reviews the NAT process position within the overall packet
rR
flow. Note that destination NAT and source NAT occur separately in the first path
packet flow.
fo
ot
N
n
tio
d uc
ro
ep
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,
rR
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, JUNOS Software installs NAT and PAT information into the
session table for fast path processing. This information speeds up subsequent packet
processing.
fo
ot
N
n
tio
d uc
ro
ep
Two Basic Types of NAT
Two basic types of NAT exist—destination NAT and source NAT. Destination NAT
translates the destination IP address of a packet. Source NAT translates the source IP
rR
address of a packet. Both destination and source NAT can deploy either static or
dynamic address mapping.
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.
ot
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 chapter.
n
tio
d uc
ro
ep
Destination NAT Operation and Configuration
The slide highlights the topic we discuss next.
rR
fo
ot
N
n
tio
d uc
ro
ep
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
rR
VoIP ALGs
Voice over IP (VoIP) application-level gateways (ALGs) dynamically generate the
N
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.
n
tio
d uc
ro
ep
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
rR
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.
fo
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.
ot
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.
Continued on next page.
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
n
specific context takes precedence; and
• Within a rule-set, the ordering of rules is significant. Rules evaluation
tio
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 Software insert command to adjust rules within a rule-set.
uc
Live Configuration Changes
If a change is made to a NAT rule or pool that is currently in use, JUNOS Software tears
d
down the affected session once the change is committed. JUNOS Software re-initiates
the session as soon as it receives further matching traffic.
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
Static Destination NAT Sample Topology
The slide illustrates a sample topology that demonstrates static destination NAT using
JUNOS Software. Using the topology shown on the slide, we discuss enabling static
rR
destination NAT for traffic destined to 100.0.0.1 coming from the Untrust Zone. The
traffic should translate to a private IP address of 10.1.10.5.
fo
ot
N
n
tio
d uc
ro
ep
Static Destination NAT Configuration
The slide illustrates the required configuration to enable static destination NAT for the
given example. JUNOS Software static NAT requires a rule-set association with a
rR
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
fo
ot
N
n
tio
d uc
ro
ep
Verifying the Result
Use the show security flow session command to observe NAT translation.
The output shows traffic entering the JUNOS security platform using the public
rR
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.
The slide illustrates the creation of a second session. Once static destination NAT is
enabled and a session triggers, JUNOS Software 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.
ot
N
n
tio
d uc
ro
ep
Pool-Based Destination NAT Sample Topology
The slide illustrates a sample topology that demonstrates pool-based destination NAT
using JUNOS Software. Using the topology shown on the slide, we will enable
rR
pool-based destination NAT for traffic destined to 100.0.0.1 coming from the Untrust
Zone. The traffic should translate to a private IP address of 10.1.10.5.
fo
ot
N
n
tio
d uc
ro
ep
Pool-Based Destination NAT Configuration with a Single Address
The slide illustrates the required configuration to enable destination NAT for the given
example. JUNOS Software pool-based NAT requires a user-defined address pool and a
rR
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.
fo
ot
N
n
tio
d uc
ro
ep
Pool-Based Destination NAT Configuration with an Address Pool
The slide illustrates the required configuration to enable destination NAT for the given
example. JUNOS Software pool-based NAT requires a user-defined address pool and a
rR
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 within a range of 10.1.10.5 to 10.1.10.6. There is no port translation.
fo
ot
N
n
tio
d uc
ro
ep
Pool-Based Destination NAT Configuration with PAT
The slide illustrates the required configuration to enable destination NAT and PAT for
the given example. JUNOS Software pool-based NAT requires a user-defined address
rR
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 and a destination port
of 80 translates to a destination address of 10.1.10.5 and a destination port of 8080.
fo
ot
N
n
tio
d uc
ro
ep
Result of NAT with PAT
Use the show security flow session command to observe NAT translation.
The output shows traffic entering the device using the public destination address
rR
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
fo
n
tio
d uc
ro
ep
Verifying the Result
Use the show security nat destination rule all operational mode
command to view NAT rules as JUNOS Software programs them. The output on the
rR
slide 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.
fo
ot
N
n
tio
d uc
ro
ep
Source NAT Operation and Configuration
The slide highlights the topic we discuss next.
rR
fo
ot
N
n
tio
d uc
ro
ep
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.
rR
PAT; and
• 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
N
n
tio
d uc
ro
ep
Matching Conditions
Traffic requiring source NAT application is subject to a two-layer matching scheme.
Similar to security policy, JUNOS Software creates source NAT rules under a context
rR
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.
fo
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.
ot
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).
Continued on next page.
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;
n
• If more than one rule-set matches traffic, the rule-set with the most
specific context takes precedence; and
tio
• 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.
uc
Use the JUNOS Software insert command to adjust rules within a rule-set.
d
If a change is made to a NAT rule or pool that is currently in use, JUNOS Software tears
down the session once the change is committed. JUNOS Software re-initiates the
session as soon as it receives further matching traffic.
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
Interface-Based Source NAT Sample Topology
The slide illustrates a sample topology that demonstrates interface-based source NAT
using JUNOS Software. Using the topology shown on the slide, we will enable
rR
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 translate to use the egress interface address 1.1.70.5.
fo
ot
N
n
tio
d uc
ro
ep
Interface-Based Source NAT Configuration
The slide illustrates the required configuration to enable interface-based source NAT
for the given example. Similar to static NAT, pools are not necessary for this
rR
n
tio
d uc
ro
ep
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
rR
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.
fo
ot
N
n
tio
d uc
ro
ep
Pool-Based Source NAT Sample Topology with PAT
The slide illustrates an example topology that demonstrates pool-based source NAT
and PAT using JUNOS Software. Using the topology shown on the slide, we will enable
rR
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
translate. The traffic should translate to a public source IP address of 207.17.137.229.
fo
ot
N
n
tio
d uc
ro
ep
Pool-Based Source NAT Configuration with PAT
The slide illustrates the required configuration to enable source NAT and PAT for the
given example. JUNOS Software pool-based NAT requires a user-defined address pool
rR
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 JUNOS
Software, PAT is automatically enabled for pool-based source NAT.
fo
ot
N
n
tio
d uc
ro
ep
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
rR
n
tio
d uc
ro
ep
PAT Is Default
As illustrated in the previous example, JUNOS Software’s implementation of source
NAT enables PAT by default. Because PAT is enabled and the number of available ports
rR
Address Persistence
Regardless of the large available source NAT pool, there is no guarantee that JUNOS
fo
Software 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 slide.
ot
N
n
tio
d uc
ro
ep
Pool-Based Source NAT Sample Topology Without PAT
The slide illustrates a sample topology that demonstrates pool-based source NAT
without PAT using JUNOS Software. Using the topology shown on the slide, we will
rR
enable pool-based source NAT without 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
translate. The traffic should translate 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
fo
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
ot
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.
N
n
tio
d uc
ro
ep
Pool-Based Source NAT Configuration Without PAT
The slide illustrates the required configuration to enable source NAT without PAT for
the given example. JUNOS Software pool-based NAT requires a user-defined address
rR
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 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.
fo
ot
N
n
tio
d uc
ro
ep
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
rR
source NAT rule illustrates the parameters set by the configuration with an associated
action of translation using pool A.
ot
N
n
tio
d uc
ro
ep
Pool Utilization
If JUNOS Software runs out of addresses in a source NAT pool, further packets
requiring translation will drop. We already discussed one method to overcome this
rR
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.
JUNOS Software provides a pool utilization alarm for monitoring pool usage. The
utilization alarm is disabled by default. The slide shows the configuration for the pool
fo
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,
JUNOS Software sends an SNMP trap to the network management station. Note that
ot
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.
N
n
tio
d uc
ro
ep
Source NAT with Address Shifting Sample Topology
The slide illustrates a sample topology that demonstrates source NAT with address
shifting using JUNOS Software. Using the topology shown on the slide, we will enable
rR
source NAT with address shifting 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 starting with the 10.1.10.5 address for shifting purposes. The traffic should
translate to a public source IP address range consisting of the 207.17.137/24
network.
fo
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.
ot
N
n
tio
d uc
ro
ep
Source NAT with Address Shifting Configuration
The slide illustrates the required configuration to enable source NAT with address
shifting for the given example. JUNOS Software source NAT with address shifting
rR
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.
fo
ot
N
n
tio
d uc
ro
ep
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
rR
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.
ot
N
n
tio
d uc
ro
ep
Pop Quiz!
The off NAT action is useful for detailed control. The configuration shown on the slide
represents how you might use a NAT off action. In this example, all traffic sourced
rR
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.
fo
ot
N
n
tio
d uc
ro
ep
Proxy ARP
The slide highlights the topic we discuss next.
rR
fo
ot
N
n
tio
d uc
ro
ep
When to Use Proxy ARP
JUNOS Software for security platforms requires a proxy Address Resolution Protocol
(ARP) configuration whenever translated traffic belongs to the same subnet as the
rR
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
fo
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
ot
destined for the intended destination then travel to the proxying device, which can
then forward the packets to the actual destination.
The slide illustrates the configuration hierarchy and options for NAT proxy ARP.
N
n
tio
d uc
ro
ep
Proxy ARP Example
The slide illustrates a sample situation requiring proxy ARP and the associated
configuration. In the example, the device performs source translation for traffic from
rR
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.
fo
ot
N
n
tio
d uc
ro
ep
Monitoring and Verifying NAT Operation
The slide highlights the topic we discuss next.
rR
fo
ot
N
n
tio
d uc
ro
ep
Key Monitoring Commands
The slide lists four operational mode show commands used to verify and monitor NAT
operation. We repeatedly illustrate these commands throughout examples in this
rR
chapter. You can use the show security nat commands for source or destination
NAT.
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
ot
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.
N
n
source-nat-re Trace source nat events on RE side
source-nat-rt Trace source nat events on PFE-RT side
tio
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
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
This Chapter Discussed:
• The purpose and functionality of NAT and PAT;
• NAT processing;
rR
n
tio
d uc
ro
ep
Review Questions
1.
rR
2.
3.
fo
4.
5.
ot
N
n
tio
d uc
ro
ep
Lab 5: Network Address Translation
The slide provides the objective for this lab.
rR
fo
ot
N
n
tio
Chapter 8: IPsec VPNs
d uc
ro
ep
rR
fo
ot
N
JUNOS for Security Platforms
n
tio
d uc
ro
ep
This Chapter Discusses:
• Various types of virtual private networks (VPNs);
• Major security concerns;
rR
n
tio
d uc
ro
ep
VPN Types
The slide lists the topics we cover in this chapter. We discuss the highlighted topic
first.
rR
fo
ot
N
n
tio
d uc
ro
ep
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
rR
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.
n
tio
d uc
ro
ep
Secure VPNs
A network device that builds secure VPNs must be able to perform the following
actions:
rR
features.
N
n
tio
d uc
ro
ep
Secure VPN Requirements
The slide highlights the topic we discuss next.
rR
fo
ot
N
n
tio
d uc
ro
ep
Security Concerns
Three driving concerns exist for network security: confidentiality, integrity, and
authentication.
rR
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!
n
tio
d uc
ro
ep
Confidentiality—Data Encryption
The first of the three VPN security concerns is confidentiality.
Encryption provides data confidentiality. Encryption is the method of taking user
rR
• 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.
ot
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.
N
n
tio
d uc
ro
ep
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
rR
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 as 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
fo
n
tio
d uc
ro
ep
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
rR
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
fo
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.
ot
N
n
tio
d uc
ro
ep
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
rR
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
fo
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
ot
carried in the packet. The same hash in both locations proves data integrity in transit.
If the hashes do not match, the packet drops.
JUNOS Software supports MD5, SHA1, and 256-bit SHA2 hashing.
N
n
tio
d uc
ro
ep
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
rR
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
fo
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
slide, which shows a modulus operation. Given the value of 3, it is not possible to
ot
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
N
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.
n
tio
d uc
ro
ep
Integrity—The Hash Process
The following list outlines the hash process:
1. The sender runs the data through the hash process.
rR
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.
fo
5. The receiver then compares the calculated hash value to the received
hash value. If the hash values match, the data is unaltered.
ot
N
n
tio
d uc
ro
ep
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
rR
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
fo
n
tio
d uc
ro
ep
HMAC Authentication
The following list outlines hashing with HMAC:
1. The sender appends the preshared key to the data, then performs the
rR
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
fo
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
ot
match, meaning the source is invalid. Either way, the receiver discards
the packet.
N
n
tio
d uc
ro
ep
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
rR
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
fo
The Solution
Whitfield Diffie and Martin Hellman developed a solution to this problem in 1970. The
N
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.
n
tio
d uc
ro
ep
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
rR
number.
You must configure both tunnel peers to use the same DH group; otherwise, the key
generation process fails.
ot
N
n
tio
d uc
ro
ep
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.
rR
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.
fo
ot
N
n
tio
d uc
ro
ep
IPsec Details
The slide highlights the topic we discuss next.
rR
fo
ot
N
n
tio
d uc
ro
ep
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.
rR
n
tio
d uc
ro
ep
IPsec: A Two-Step Process
IPsec VPNs consists of two major steps:
1. IPsec tunnel establishment: You can manually establish an IPsec tunnel
rR
pages.
ot
N
n
tio
d uc
ro
ep
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
rR
• Preshared keys;
• Digital signatures; or
N
n
tio
d uc
ro
ep
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
rR
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.
fo
ot
N
n
tio
d uc
ro
ep
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
rR
n
tio
d uc
ro
ep
IKE Phases
IKE tunnel establishment happens in two phases:
• Phase 1 establishes a secured channel between gateways for Phase 2
rR
Secrecy (PFS).
N
n
tio
d uc
ro
ep
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:
rR
• Encryption algorithm;
• Hash algorithm;
• DH group; and
• Authentication method:
fo
– Preshared keys;
– Digital signatures; and
– Public key encryption.
ot
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
N
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.
Continued on next page.
n
An IPsec SA proposal contains the following:
tio
• Phase 1 authentication method (main mode or aggressive mode);
• DH group number;
• Encryption algorithm;
uc
• 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
d
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
ro
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 contain the preshared key.
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
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
rR
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
fo
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.
ot
N
n
tio
d uc
ro
ep
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:
rR
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
ot
n
• Encryption algorithm;
• Authentication algorithm;
tio
• Key lifetime;
• Proxy ID (policy rule); and
• DH public keys (optional if using PFS).
uc
Message 3 acknowledges information sent from quick mode Message 2 so that the
Phase 2 tunnel can establish.
d
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
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
rR
devices are ready to send the payload using the IPsec attributes and protocols, which
ensure payload protection.
fo
ot
N
n
tio
d uc
ro
ep
Goal of IPsec Traffic Processing
During the IPsec traffic processing step, the devices have one goal—to ensure traffic
protection.
rR
IPsec Modes
IPsec handles the payload using one of two modes—transport or tunnel. We discuss
each mode in the next few pages.
fo
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.
ot
N
n
tio
d uc
ro
ep
IPsec Modes
You can implement IPsec in the following two modes:
• Tunnel mode: This mode is the most commonly implemented method.
rR
n
tio
d uc
ro
ep
IPsec Protocols
Two protocols exist that IPsec can use to ensure payload security—AH protocol and
ESP:
rR
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
ot
n
tio
d uc
ro
ep
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
rR
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;
fo
n
tio
d uc
ro
ep
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
rR
ESP Auth is the integrity check value (that is, the hash value) for this packet.
n
tio
d uc
ro
ep
Traffic Processing: Part 1
The following list describes the order of traffic processing:
1. The packet arrives at the remote JUNOS security platform.
rR
n
tio
d uc
ro
ep
Traffic Processing: Part 2
This list is a continuation of the list from the previous page, describing the order of
traffic processing:
rR
9. JUNOS Software compares the locally calculated hash with the received
hash.
10. JUNOS Software decrypts the packet.
11. JUNOS Software performs the routing lookup for the decrypted packet
ot
n
tio
d uc
ro
ep
IPsec Processing Summary
The slide provides a summary of all the steps of IPsec traffic processing.
rR
fo
ot
N
n
tio
d uc
ro
ep
Configuration of IPsec VPN
The slide highlights the topic we discuss next.
rR
fo
ot
N
n
tio
d uc
ro
ep
IPsec Implementation Methods
JUNOS Software offers two methods for IPsec VPN implementation:
• Policy-based VPNs: To implement this method, a security policy specifies
rR
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
fo
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
ot
VPNs are generally the best VPNs to use when a routing protocol
adjacency must be formed across the tunnel. When JUNOS Software
searches a route that must send traffic to the destination address, it
N
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.
n
tio
d uc
ro
ep
Elements of IPsec VPN Configuration:
IPsec VPN configuration consists of three steps:
1. Configuring IKE Phase 1;
rR
n
tio
d uc
ro
ep
Configuring IKE Phase 1 Parameters: Step A
IKE Phase 1 configuration requires that you perform the following steps:
A. Configure IKE Phase 1 proposals;
rR
• basic:
– Proposal 1: preshared key, DH g1, DES, and SHA1
– Proposal 2: preshared key, DH g1, DES, and MD5
ot
• compatible:
– Proposal 1: preshared key, DH g2, 3DES, and SHA1
N
• standard:
– Proposal 1: preshared key, DH g2, 3DES, and SHA1
– Proposal 2: preshared key, DH g2, AES128, and SHA1
n
tio
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
Configuring IKE Phase 1 Parameters: Step B
The slide 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
rR
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.
fo
ot
N
n
tio
d uc
ro
ep
Configuration of IKE Phase 1 Parameters: Step C
The slide 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,
rR
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
fo
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.
ot
N
n
tio
d uc
ro
ep
Configuring IKE Phase 2 Parameters: Step A
IKE Phase 2 configuration requires that you configure the following steps:
A. IKE Phase 2 proposals;
rR
• basic:
– Proposal 1: no PFS, ESP, DES, and SHA1
– Proposal 2: no PFS, DH g1, DES, and MD5
ot
• compatible:
– Proposal 1: no PFS, ESP, 3DES, and SHA1
N
n
tio
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
Configuring IKE Phase 2 Parameters: Step B
The slide 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
rR
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 JUNOS
Software to generate the encryption key.
fo
ot
N
n
tio
d uc
ro
ep
Configuring IKE Phase 2 Parameters: Step C
The slide 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
rR
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
slide. 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
fo
n
tio
d uc
ro
ep
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 slide.
rR
fo
ot
N
n
tio
d uc
ro
ep
Applying IPsec—Route-Based IPsec VPNs
If you are implementing a route-based IPsec VPN, you must perform the following
steps:
rR
n
tio
d uc
ro
ep
IPsec VPN Monitoring
The slide highlights the topic we discuss next.
rR
fo
ot
N
n
tio
d uc
ro
ep
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
rR
on the slide. 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 slide.
fo
ot
N
n
tio
d uc
ro
ep
Example: Configuring IKE Phase 1 Parameters
The slide 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
rR
can use JUNOS Software’s predefined proposals (the choices are basic,
compatible, or standard). On the slide, 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.
fo
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.
n
tio
d uc
ro
ep
Example: Configuring IKE Phase 2 Parameters for Policy-Based IPsec
VPNs
The slide illustrates configuration of IKE Phase 2 parameters for our example. Our
rR
immediately.
Note that you should repeat the configuration illustrated for the Edge device on the
Remote device.
n
tio
d uc
ro
ep
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
rR
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 slide 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
fo
n
tio
d uc
ro
ep
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
rR
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
fo
the st0.0 interface. In our case we are using static route 0.0.0.0/0.
ot
N
n
tio
d uc
ro
ep
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
rR
although the slide provides the configuration for the Edge device, you must also
repeat it for the Remote device.
fo
ot
N
n
tio
d uc
ro
ep
Example: Configuring IKE Phase 1 Parameters
The slide 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
rR
you can use JUNOS Software’s 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.
fo
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.
n
tio
d uc
ro
ep
Example: Configuring IKE Phase 2 Parameters for a Route-Based IPsec
VPN
The slide illustrates configuration of IKE Phase 2 parameters for our example. Our
rR
n
tio
d uc
ro
ep
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
rR
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 slide illustrates both commands with the resulting outputs. Also, you can view
IPsec statistics that specify the number of transit packet bytes that the device
fo
n
tio
d uc
ro
ep
Monitoring a Route-Based IPsec VPN: Part 2
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
rR
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 slide illustrates the results of the show interface st0
detail command for the Edge device.
fo
ot
N
n
tio
d uc
ro
ep
Monitoring a Route-Based IPsec VPN: Part 3
The slide is the continuation of the show interfaces st0 detail command
from the previous slide. It provides statistical information for the st0 interface,
rR
n
tio
d uc
ro
ep
Monitoring a Route-Based IPsec VPN: Part 4
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,
rR
the 0.0.0.0/0 default route, using interface st0.0 as its next hop, is active.
fo
ot
N
n
tio
d uc
ro
ep
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
rR
n
tio
d uc
ro
ep
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
rR
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.
fo
n
tio
d uc
ro
ep
This Chapter Discussed:
• Various types of VPNs;
• Major security concerns;
rR
n
tio
d uc
ro
ep
Review Questions
1.
rR
2.
3.
fo
4.
ot
N
n
tio
d uc
ro
ep
Lab 6: Implementing IPsec VPNs
The slide provides the objective for this lab.
rR
fo
ot
N
n
tio
Chapter 9: Introduction to Intrusion Detection
and Prevention
d uc
ro
ep
rR
fo
ot
N
JUNOS for Security Platforms
n
tio
d uc
ro
ep
This Chapter Discusses:
• The purpose of the JUNOS Software Intrusion Detection and Prevention
(IDP) feature;
rR
n
tio
d uc
ro
ep
Introduction to JUNOS Software IDP
The slide lists the topics we cover in this chapter. We discuss the highlighted topic
first.
rR
fo
ot
N
n
tio
d uc
ro
ep
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
rR
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
fo
Software examines the stream for specified attack patterns. If no problem with the
stream exists, JUNOS Software forwards the original packets. If the software detects a
problem within the stream, IDP can drop packets, close or drop sessions, prevent
N
n
tio
d uc
ro
ep
Fully Integrated IDP
JUNOS security platforms have IDP functionality fully integrated into JUNOS Software.
This integration means no additional hardware or operating system is necessary,
rR
n
tio
d uc
ro
ep
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
rR
IDP Successes
The JUNOS Software IDP feature regularly protects networks from the latest Microsoft
vulnerabilities. The attack database updates as new threats emerge, keeping JUNOS
ot
Software 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
N
proactive by stopping attacks as they occur, and by preventing future 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.
n
tio
d uc
ro
ep
IDP Policy Components and Configuration
The slide highlights the topic we discuss next.
rR
fo
ot
N
n
tio
d uc
ro
ep
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
rR
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 slide illustrates the structural view of an IDP policy. An IDP policy can consist of
fo
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
ot
within the configuration, only one IDP policy is active on a JUNOS security platform.
N
n
tio
d uc
ro
ep
IDP Configuration Objects
JUNOS Software uses configuration objects to build IDP rules. Use configuration
objects to match on zones, source and destination networks, applications, and
rR
n
tio
d uc
ro
ep
IDP Policy Matching Conditions
The slide shows a sample IDP policy configured with the JUNOS Software template
policy named Recommended. The slide shows a rule named rule 2 in an IPS rulebase
rR
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. JUNOS
Software automatically matches on application or service settings associated with the
defined attack or attack group object. You can also specify a configured application or
fo
Networks. We discuss the signature database on subsequent slides. 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,
N
n
tio
d uc
ro
ep
IDP Policy Actions
The slide shows the same sample policy rule as the previous slide, but with the action
section of the rule highlighted. This example defines an action of Recommended. This
rR
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: JUNOS Software takes no action (used when you only need
to generate a log);
fo
n
The example on the slide also illustrates a notification action. This action instructs
JUNOS Software to log the attack.
tio
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
Additional IDP Policy Actions
The slide 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
rR
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
fo
fields:
• Source IP;
• Destination IP;
ot
• Destination Port;
• From Zone; and
• Protocol.
N
n
source-address Match source
source-zone Match source-zone
tio
zone-service Match source-zone, destination, dst-port, protocol
The following are possible IP actions:
• ip-block: JUNOS Software silently drops all packets matching the IP
action rule;
uc
• ip-close: JUNOS Software closes any new sessions matching the IP
action rule by sending an RST packet to the client and server; and
• ip-notify: JUNOS Software generates a log when it finds a session
matching the IP action rule.
d
You can use the severity action to override the default attack severity to a configured
value. ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
Applying IDP Policy
You enable IDP policies by specifying the IDP policy in a security policy, as shown on
the slide. The security policy action must be to permit the flow. Note that once an IDP
rR
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.
Recall that only one IDP policy is active on a JUNOS security platform at any given
time. The slide shows how to configure the active IDP policy.
ot
N
n
tio
d uc
ro
ep
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
rR
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.
JUNOS Software evaluates all IDP rules (unlike security policy) but does so
sequentially. If a new session matches multiple rules, JUNOS Software performs the
most severe action among the rules. The slide shows the order of severity associated
fo
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.
N
n
tio
d uc
ro
ep
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.
rR
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
fo
these attacks are attacks the software should not inspect in traffic matching this rule.
No actions are available for exempt rulebases.
ot
N
n
tio
d uc
ro
ep
Signature Database
The slide highlights the topic we discuss next.
rR
fo
ot
N
n
tio
d uc
ro
ep
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
rR
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
ot
n
tio
d uc
ro
ep
IDP Signature Update License
To update the IDP signature database, an IDP signature license is necessary. The slide
illustrates the configuration command for adding a system license, and the result of a
rR
n
tio
d uc
ro
ep
Updating the Security Package Manually
You can download the Juniper Networks security package manually or automatically at
specified time intervals. The slide illustrates the operational mode commands to
rR
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.
fo
ot
N
n
tio
d uc
ro
ep
Installing the Security Package
Once you successfully download the security package, you must install it. The slide
illustrates the operational mode commands for installing the security package and
rR
Automatic Downloads
As mentioned previously, you can configure a JUNOS security platform to automatically
fo
download the security package. The slide also shows an example configuration of
automating the download.
ot
N
n
tio
d uc
ro
ep
Signature and Attack Database Version
The slide 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
rR
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.
ot
N
n
tio
d uc
ro
ep
Case Study: Applying the Recommended IDP Policy
The slide highlights the topic we discuss next.
rR
fo
ot
N
n
tio
d uc
ro
ep
Applying the Recommended IDP Policy: Part 1
This slide and the next two slides demonstrate the steps necessary for downloading
and installing the Juniper Networks recommended IDP policy. The slide shows the
rR
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.
fo
ot
N
n
tio
d uc
ro
ep
Applying the Recommended IDP Policy: Part 2
JUNOS Software downloads Juniper Networks policy templates in the form of a commit
script. Once you download and install the policy templates, you must activate the
rR
template commit script with the configuration mode command shown on the slide.
You must perform a commit action to activate a commit script. In this example, we use
the JUNOS Software 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.
fo
ot
N
n
tio
d uc
ro
ep
Applying the Recommended IDP Policy: Part 3
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 slide,
rR
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!
fo
ot
N
n
tio
d uc
ro
ep
Monitoring IDP Operation
The slide highlights the topic we discuss next.
rR
fo
ot
N
n
tio
d uc
ro
ep
Verifying the Application of IDP Policy
The slide shows a sample output of the show security policies
policy-name command. By using the detail option, you can verify that you
rR
n
tio
d uc
ro
ep
Monitoring IDP Status and Statistics
The slide illustrates the show security idp status command. This command
provides traffic statistics related to the IDP policy engine. It also outputs the active IDP
rR
n
tio
d uc
ro
ep
IDP Counters
The command shown on the slide along with one of the command arguments provides
various counters useful in monitoring IDP operation.
rR
fo
ot
N
n
tio
d uc
ro
ep
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 slide to monitor memory utilization.
rR
fo
ot
N
n
tio
d uc
ro
ep
IDP Logging
You enable logging using the notification action. JUNOS Software stores logs
according to the data plane logging configuration present on the JUNOS security
rR
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
fo
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
ot
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.
n
tio
d uc
ro
ep
This Chapter Discussed:
• The purpose of the JUNOS Software IDP feature;
• Utilizing and updating the IDP signature database;
rR
n
tio
d uc
ro
ep
Review Questions
1.
rR
2.
3.
fo
4.
ot
N
n
tio
d uc
ro
ep
Lab 7: Implementing IDP
The slide provides the objective for this lab.
rR
fo
ot
N
n
tio
Chapter 10: High Availability Clustering
d uc
ro
ep
rR
fo
ot
N
JUNOS for Security Platforms
n
tio
d uc
ro
ep
This Chapter Discusses:
• High availability (HA) clustering and its functionality;
• Chassis cluster components;
rR
n
tio
d uc
ro
ep
High Availability Overview
The slide lists the topics we cover in this chapter. We discuss the highlighted topic
first.
rR
fo
ot
N
n
tio
d uc
ro
ep
High Availability Characteristics
The JUNOS Software high availability (HA) feature provides stateful session failover.
This ability applies to TCP and UDP sessions—those that deploy Network Address
rR
the data plane. Check the Juniper Networks technical documentation for high
availability support specific to your platform at http://www.juniper.net/techpubs.
ot
N
n
tio
d uc
ro
ep
High Availability Using Chassis Clusters
JUNOS Software achieves high availability on JUNOS security platforms using chassis
clustering. Chassis clustering provides network node redundancy by grouping two like
rR
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
fo
cards (IOCs) on high-end platforms must have the same slot placement and hardware
revision.
The chassis clustering feature in JUNOS Software is built on the high availability
methodology of Juniper Networks M Series and T Series platforms and the TX Matrix
ot
of which have complete hardware and control plane redundancies, the JUNOS
Software 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.
n
tio
d uc
ro
ep
Chassis Cluster Components
The slide highlights the topic we discuss next.
rR
fo
ot
N
n
tio
d uc
ro
ep
Chassis Cluster Components
A chassis cluster consists of the following components:
• Cluster identification, including cluster-id id and node id;
rR
n
tio
d uc
ro
ep
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
rR
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.
fo
ot
N
n
tio
d uc
ro
ep
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.
rR
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.
ot
n
tio
d uc
ro
ep
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
rR
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.
fo
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
N
this chapter.
n
tio
d uc
ro
ep
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;
rR
• A primary state; or
• A secondary state.
As indicated on the diagram on the slide, 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
ot
n
tio
d uc
ro
ep
RG Primacy Rules
The rules for RG primacy are as follows:
• An RG is primary on the node with the higher priority.
rR
• 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
fo
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
ot
n
tio
d uc
ro
ep
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
rR
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.
fo
ot
N
n
tio
d uc
ro
ep
Illustration of RGx’s Use for Load Balancing
This slide 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
rR
n
tio
d uc
ro
ep
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
rR
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
fo
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.
ot
N
n
tio
d uc
ro
ep
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
rR
platforms contain an fxp0 interface. For branch security platforms in a chassis cluster,
JUNOS Software 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
fo
n
tio
d uc
ro
ep
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
rR
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
fo
uses the proprietary Trivial Network Protocol (TNP) to transmit the session state, the
configuration file, and liveliness signals across the nodes. JUNOS Software
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.
Continued on next page.
n
control-link-recovery;
tio
d uc
ro
ep
rR
fo
ot
N
n
tio
d uc
ro
ep
Chassis Cluster Interfaces—fab
JUNOS Software uses the fabric (fab) interface for the high availability data plane.
When the system creates the fab interface, the software assigns it an internally
rR
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.
fo
Similar to the fxp1 control link, the fab link uses fabric probes to determine the health
of the link. If JUNOS Software determines that there has been a fabric link failure, it
disables the secondary node, and a reboot is required to restore operation.
JUNOS Software 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
ot
configured under a security zone. Although JUNOS Software 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
N
n
tio
d uc
ro
ep
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
rR
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.
fo
Dynamics of RTOs
JUNOS Software creates RTOs dynamically in memory. Some examples of dynamically
created RTOs include session table entries and IPsec security associations (SAs).
ot
N
n
tio
d uc
ro
ep
Chassis Cluster Interface Summary
The slide summarizes all the cluster interfaces that we just discussed.
rR
fo
ot
N
n
tio
d uc
ro
ep
Chassis Cluster Operation
The slide highlights the topic we discuss next.
rR
fo
ot
N
n
tio
d uc
ro
ep
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.
rR
fo
ot
N
n
tio
d uc
ro
ep
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
rR
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.
fo
ot
N
n
tio
d uc
ro
ep
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.
rR
fo
ot
N
n
tio
d uc
ro
ep
Cluster Operation: Splitting a Cluster
JUNOS Software 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
rR
or heartbeat messages. You must reboot the disabled node to have it rejoin the
cluster. However, if JUNOS Software detects a failure on both links simultaneously,
such as in the case of a system failure, both devices become primary nodes.
fo
ot
N
n
tio
d uc
ro
ep
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.
rR
fo
ot
N
n
tio
d uc
ro
ep
One Node Handling Transit Traffic
The slide 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.
rR
fo
ot
N
n
tio
d uc
ro
ep
Both Nodes Handling Transit Traffic
In active-active mode for the data plane, two nodes handle transit traffic. This slide
illustrates the packet flow in which ingress and egress interfaces are on different
rR
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
fo
n
tio
d uc
ro
ep
Chassis Cluster Configuration
The slide highlights the topic we discuss next.
rR
fo
ot
N
n
tio
d uc
ro
ep
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:
rR
• 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).
fo
Enabling Clustering
N
n
tio
d uc
ro
ep
Enabling the Chassis Cluster
The slide illustrates the configuration required to enable the SPC control plane ports
for high-end security platforms.
rR
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.
Because the second node inherits the configuration associated with the primary node,
no control port configuration is necessary. The slide illustrates the operational mode
command required to add the second node to the chassis cluster.
ot
N
n
tio
d uc
ro
ep
Cluster Configuration Steps
Once you reboot a node of a cluster, you are ready to configure other cluster
parameters. The slide lists the configuration steps you must follow to accomplish
rR
cluster configuration.
fo
ot
N
n
tio
d uc
ro
ep
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.
rR
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 slide.
fo
ot
N
n
tio
d uc
ro
ep
Configuring Fabric Interfaces
You configure the fab interface between the two nodes using the syntax illustrated on
the slide. The member interface for fab0 is an Ethernet interface on Node 0, and the
rR
member interface for fab1 is an Ethernet interface on Node 1. Both fab interfaces
must be of the same media type.
fo
ot
N
n
tio
d uc
ro
ep
Configuring a Redundancy Group
The slide illustrates the syntax necessary for configuring an RG. You perform the
configuration under the chassis cluster configuration stanza. The configuration
rR
n
tio
d uc
ro
ep
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
rR
n
tio
d uc
ro
ep
Configuring Cluster Failover Parameters
The following are the cluster failover parameters that you can configure, should you
choose to alter their default values:
rR
n
tio
d uc
ro
ep
Disabling a Chassis Cluster
The slide 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
rR
node. Because it will have its configuration synced to the primary node configuration,
the secondary node will also need its interfaces renamed.
fo
ot
N
n
tio
d uc
ro
ep
Chassis Cluster Monitoring
The slide highlights the topic we discuss next.
rR
fo
ot
N
n
tio
d uc
ro
ep
Example: Network Diagram Prior to Issuing the Cluster-Forming
Command
Consider the example on the slide. Two high-end security platforms, host1 and host2,
rR
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.
fo
ot
N
n
tio
d uc
ro
ep
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
rR
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
slide to set the cluster identification number and node identification number. The
operational mode command also allows you to perform the mandatory reboot on each
fo
device. Remember to perform this operation first on the node designated to be the
primary node and then on the node designated as secondary.
ot
N
n
tio
d uc
ro
ep
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 slide.
rR
fo
ot
N
n
tio
d uc
ro
ep
Cluster Status Check
Use the show commands illustrated on the slide to display the status of the chassis
cluster and the cluster interfaces.
rR
fo
ot
N
n
tio
d uc
ro
ep
Configuring the Management Interface
Next, configure the management interface using the groups and apply-groups
configuration stanzas, as illustrated on the slide.
rR
fo
ot
N
n
tio
d uc
ro
ep
Configuring the Fabric Interfaces
In the example on the slide, the fab0 and fab1 interfaces of the cluster use ge-0/0/2
and ge-12/0/2 physical interfaces. The slide depicts the configuration of the fab0 and
rR
fab1 interfaces as well as the resulting status. Note that the fab interfaces now show
a link status of up.
fo
ot
N
n
tio
d uc
ro
ep
Configuring a Redundancy Group
The slide 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
rR
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.
fo
ot
N
n
tio
d uc
ro
ep
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.
rR
You can also verify that you enabled preemption or if a manual failover is in effect. We
discuss manual failovers on a subsequent slide.
fo
ot
N
n
tio
d uc
ro
ep
Configuring reth Interfaces
In the example on the slide, 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
rR
number of reth interfaces that the cluster will recognize is two (based on a
reth-count value).
fo
ot
N
n
tio
d uc
ro
ep
Configuring Cluster Failover Parameters
According to the configuration on the slide, heartbeat messages between the nodes in
the cluster happen every 1200 milliseconds. In addition, the system assumes the
rR
n
tio
d uc
ro
ep
Monitoring Cluster Statistics
Use the show chassis cluster statistics command to display chassis
cluster counters. The counters are useful for troubleshooting and verifying proper
rR
operation.
fo
ot
N
n
tio
d uc
ro
ep
Manual Failover
You can initiate a failover manually with the request command shown on the slide. A
manual failover bumps up the priority of the redundancy group for that member to
rR
n
tio
d uc
ro
ep
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
rR
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.
fo
ot
N
n
tio
d uc
ro
ep
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
rR
Traceoptions
You can also configure traceoptions for chassis cluster operations. You can set flags
fo
n
tio
d uc
ro
ep
This Chapter Discussed:
• High availability clustering and its functionality;
• Chassis cluster components;
rR
n
tio
uc
d
ro
ep
Review Questions
1.
rR
2.
3.
fo
4.
ot
N
n
tio
d uc
ro
ep
Lab 8: Implementing Chassis Clusters
The slide provides the objective for this lab.
rR
fo
ot
N
n
tio
uc
d
ro
ep
rR
fo
ot
N
n
CoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . class-of-service
CRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . cyclic redundancy check
tio
DDoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . distributed denial of service
DES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Data Encryption Standard
DHCP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dynamic Host Configuration Protocol
DMZ. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . demilitarized zone
DoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . denial of service
uc
DPD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .dead peer detection
ESP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Encapsulating Security Payload
FPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Flexible PIC Concentrator
GUI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . graphical user interface
d
HA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .high availability
HMAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .Hashed Message Authentication Code
ro
HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hypertext Transfer Protocol
HTTPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Hypertext Transfer Protocol over Secure Sockets Layer
ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Internet Control Message Protocol
IDP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Intrusion Detection and Prevention
ep
IDP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . initial domain part
IDS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . intrusion detection service
IKE. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Internet Key Exchange
IOC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .input/output card
IPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . intrusion prevention system
rR
IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IP Security
IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IP version 4
IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IP version 6
ISN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . initial sequence number
ISP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Internet service provider
JNTCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Juniper Networks Technical Certification Program
fo
n
VoIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . voice over IP
VPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .virtual private LAN service
tio
VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .virtual private network
d uc
ro
ep
rR
fo
ot
N
n
Chapter 2: Introduction to JUNOS Security Platforms
1.
tio
Traditionally, routers process packets on a per-packet basis.
2.
Traditionally, firewalls process packets based on stateful flows.
uc
3.
JUNOS for security platforms uses session-based packet forwarding and by default does not
allow traffic to pass, whereas traditional JUNOS Software uses packet-based forwarding and by
d
default allows all traffic to pass.
4. ro
The first packet of a new session is subject to first-path packet processing.
Chapter 3: Zones
ep
1.
A zone is a collection of one or more network segments sharing identical security requirements.
2.
rR
Overall, there are two types of zones in JUNOS Software—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
fo
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
ot
You can specify traffic types to be allowed into a JUNOS security platform using the
host-inbound-traffic statement.
n
3.
The policy scheduler enables the user to dynamically activate or deactivate a security policy. If
tio
you deactivate a policy, and no other matches are found, the default security policy examines
the packet.
4.
uc
You can reorder policies using the JUNOS Software insert command.
d
1.
JUNOS Software supports RADIUS, LDAP, and SecurID external authentication servers.
2.
ro
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
ep
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
rR
4.
Use the show security firewall-authentication history command to view a
history of firewall authentication attempts.
ot
The purpose of SCREEN options in JUNOS Software is to offer better network protection to the
networks behind the JUNOS security platform, and to the device itself, from malicious
information or attacks.
n
Beyond offering network and host protection against malicious attacks, the main advantage of
using SCREEN options is that JUNOS Software performs SCREEN checks prior to security policy
processing, which results in fewer resources used for malicious packet processing.
tio
4.
There are two main goals for a DoS attack: immobilizing hosts and immobilizing networks.
5.
uc
Apply SCREEN options under the security zones configuration stanza.
d
1.
ro
Destination NAT processing occurs before security policy processing and source NAT processing
occurs after security policy processing.
2.
ep
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.
rR
4.
A NAT proxy ARP configuration is necessary when the translated address belongs to the same
subnet as the ingress interface.
5.
fo
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
ot
rule).
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.
n
1.
tio
JUNOS Software processes the rule with the most severe action.
2.
The exempt rulebase exempts specified traffic from IDP policy.
uc
3.
Evaluation of a rulebase stops only when the software matches a terminal rule.
4.
d
To apply an IDP policy, you must make it the active policy and reference an IDP action in a
security policy.
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
fo
creates RG0 when a chassis cluster forms to manage primacy of REs. The software uses RGx
to manage primacy of reth interfaces.
4.
ot