Académique Documents
Professionnel Documents
Culture Documents
9.b
Instructor Guide
Juniper Networks, the Juniper Networks logo, JUNOS, NetScreen, and ScreenOS are registered trademarks of Juniper Networks, Inc. in the United States and other
countries. JUNOSe is a trademark of Juniper Networks, Inc. All other trademarks, service marks, registered trademarks, or registered service marks are the
property of their respective owners.
JUNOS for Security Platforms Instructor Guide, Revision 9.b
Copyright 2009, Juniper Networks, Inc.
All rights reserved. Printed in USA.
Revision History:
Revision 9.aJuly 2009
Revision 9.bOctober 2009
The information in this document is current as of the date listed above.
The information in this document has been carefully verified and is believed to be accurate for software Release 9.6R1.13. Juniper Networks assumes no
responsibilities for any inaccuracies that may appear in this document. In no event will Juniper Networks be liable for direct, indirect, special, exemplary, incidental
or consequential damages resulting from any defect or omission in this document, even if advised of the possibility of such damages.
Juniper Networks reserves the right to change, modify, transfer or otherwise revise this publication without notice.
YEAR 2000 NOTICE
Juniper Networks hardware and software products do not suffer from Year 2000 problems and hence are Year 2000 compliant. The JUNOS Software has no
known time-related limitations through the year 2038. However, the NTP application is known to have some difficulty in the year 2036.
SOFTWARE LICENSE
The terms and conditions for using Juniper Networks software are described in the software license provided with the software, or to the extent applicable, in an
agreement executed between you and Juniper Networks, or Juniper Networks agent. By using Juniper Networks software, you indicate that you understand and
agree to be bound by its license terms and conditions. Generally speaking, the software license restricts the manner in which you are permitted to use the Juniper
Networks software, may contain prohibitions against certain uses, and may state conditions under which the license is automatically terminated. You should
consult the software license for further details.
Contents
Chapter 1:
Chapter 2:
Chapter 3:
Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1
The Definition of Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3-3
Zone Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-14
Monitoring Security Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-26
Lab 1: Configuring and Monitoring Zones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-32
Chapter 4:
Chapter 5:
Chapter 6:
Contents iii
Chapter 7:
Chapter 8:
Chapter 9:
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.
Objectives
After successfully completing this course, you should be able to perform the following:
Describe the logical packet flow and session creation performed by SRX Series
Services Gateways.
Intended Audience
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
JUNOS for Security Platforms is an intermediate level course.
Prerequisites
Students should have basic networking knowledge and an understanding of the OSI model and
the TCP/IP protocol suite. Students should also attend the Introduction to JUNOS Software
(IJS) course and the JUNOS Routing Essentials (JRE) course, or have equivalent experience
prior to attending this class.
Course Overview v
Course Agenda
Day 1
Chapter 1: Course Introduction
Chapter 2: Introduction to JUNOS Security Platforms
Chapter 3: Zones
Lab 1: Configuring and Monitoring Zones
Chapter 4: Security Policies
Lab 2: Security Policies
Day 2
Chapter 5: Firewall User Authentication
Lab 3: Configuring Firewall Authentication
Chapter 6: SCREEN Options
Lab 4: Implementing SCREEN Options
Chapter 7: Network Address Translation
Lab 5: Network Address Translation
Day 3
Chapter 8: IPsec VPNs
Lab 6: Implementing IPsec VPNs
Chapter 9: Introduction to Intrusion Detection and Prevention
Lab 7: Implementing IDP
Chapter 10: High Availability Clustering
Lab 8: Implementing Chassis Clusters
vi Course Agenda
Document Conventions
CLI and GUI Text
Frequently throughout this course, we refer to text that appears in a command-line interface
(CLI) or a graphical user interface (GUI). To make the language of these documents easier to
read, we distinguish GUI and CLI text from chapter text according to the following table.
Style
Description
Usage Example
Franklin
Gothic
Normal text.
Courier
New
Console text:
Screen captures
Noncommand-related
syntax
Menu names
commit complete
Exiting configuration
mode
Select File > Open, and then
click Configuration.conf in
the Filename text box.
Description
Usage Example
Normal CLI
No distinguishing variant.
Physical interface:fxp0,
Enabled
Normal GUI
CLI Input
GUI Input
Description
Usage Example
CLI
Variable
policy my-peers
GUI
variable
CLI
Undefined
GUI
Undefined
ping 10.0.1.1
Select File > Save, and enter
filename in the Filename field.
Additional Information
Education Services Offerings
You can obtain information on the latest Education Services offerings, course dates, and class
locations from the World Wide Web by pointing your Web browser to:
http://www.juniper.net/training/education/.
Technical Publications
You can print technical manuals and release notes directly from the Internet in a variety of
formats:
Go to http://www.juniper.net/techpubs/.
Locate the specific software or hardware release and title you need, and choose
the format in which you want to view or print the document.
Documentation sets and CDs are available through your local Juniper Networks sales office or
account representative.
Additional Information ix
x Additional Information
Introductions
This slide asks several questions for you to answer during class introductions.
Course Contents
This slide lists the topics we discuss in this course.
Prerequisites
This slide lists the prerequisites for this course.
Additional Resources
This slide describes additional resources available to assist you in the installation,
configuration, and operation of Juniper Networks products.
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
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.
JNTCP
The Juniper Networks Technical Certification Program (JNTCP) consists of
platform-specific, multitiered tracks that enable participants to demonstrate, through
a combination of written proficiency exams and hands-on configuration and
troubleshooting exams, competence with Juniper Networks technology. Successful
candidates demonstrate thorough understanding of Internet and security
technologies and Juniper Networks platform configuration and troubleshooting skills.
You can learn more information about the JNTCP at
http://www.juniper.net/training/certification/.
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
questions. These computer-based exams are administered at Prometric testing
centers worldwide and have no prerequisite certification requirements.
Professional-level and Expert-level exams are composed of hands-on lab exercises
that are administered at select Juniper Networks testing centers. Professional-level
and Expert-level exams require that you first obtain the next lower certification in the
track. Please visit the JNTCP Web site at
http://www.juniper.net/training/certification/ for detailed exam information, exam
pricing, and exam registration.
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
class.
Traditional Routing
The slide lists the topics we cover in this chapter. We discuss the highlighted topic
first.
Enterprise customer premise applications are served by the J Series family of service
routers and, in the case of larger enterprises, M Series routers. Enterprise data center
applications can also be served by M Series routers. Internet service provider (ISP)
networks can be served by M Series, MX Series, or T Series routers. J Series, M Series,
MX Series and T Series routers support the rich routing and class-of-service (CoS)
features needed by networks, and maintain value, stability, and predictably high
performance.
Traditional Security
The slide highlights the topic we discuss next.
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.
Because the main job of a firewall is to protect networks and devices, fundamental
firewall intelligence consists of the ability to make packet processing decisions based
on IP packet header information, including its upper layers.
Stateful packet processing involves the creation of a unidirectional flow, which
consists of six elements of informationsource IP address, destination IP address,
source port number, destination port number, protocol number, and a session token.
The session token is derived from a combination of a routing instance and a zone. The
outgoing flow initiates a session table entry and the expected return flow for that
packet. Both outgoing and incoming flows comprise the session and are entered into
the session table. The session table enables bidirectional communication without any
additional configurational steps for return traffic.
Firewall 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
access to the Internet, as well as an IP Security (IPsec) VPN tunnel back to a central
site.
The enterprise firewall device at the central site provides VPN termination and firewall
protection between internal zones as well as from the Internet, and it might also
provide other security services such as IDP, Web filtering, and antispam services.
Current Trends
As boundaries of networks are becoming less clear, so are the requirements of
network edge devices. More and more enterprises are interconnecting themselves
through an ISPs virtual cloud by using IP. The Internet has created possibilities and
opportunities for businesses and markets, and it has erased the concept of distance.
With the Internet, however, came network vulnerabilities. Traditionally, routers have
been positioned on the edge of an enterprise network and provided very basic
network security such as stateless firewall filters. Network administrators became
used to relying on separate firewall devices positioned within enterprise DMZs. The
consolidation of these functions at the network edge improves costs, reduces
management overhead, and increases operational simplicity.
A New Perspective
The graphic on the slide illustrates how a device with strong routing and firewall
features can be positioned at network boundaries. Remote offices can deploy SRX
Series branch platforms running 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
with appropriate processing capabilities without sacrificing overall system
performance. SRX Series Services Gateways are next-generation systems designed to
meet the network and security requirements for the enterprise and service provider
infrastructure, and facilitate data center consolidation, rapid managed services
deployments, and security services aggregation.
Based on the Dynamic Services Architecture, the SRX Series provides unrivaled
scalability. Each services gateway can support almost linear scalability with each
additional Services Processing Card (SPC), enabling a fully equipped SRX5800 to
support more than 120 Gbps of firewall throughput. The SPCs are designed to support
a wide range of services enabling future support of new capabilities without the need
for service-specific hardware. Using SPCs on all services ensures that no resources
are idle, based on specific services being used, maximizing the utilization of equipped
hardware.
The scalability and flexibility of the SRX5000 and SRX3000 lines of services gateways
are supported by equally robust interfaces. The SRX Series high-end line employs a
modular approach to interfaces where the gateway can be equipped with a flexible
number of input/output cards (IOCs).
Continued on next page.
Switch Control Board (SCB): The SCB monitors and controls system
functions and provides the interconnections to all the IOCs within a
chassis through the switch fabrics integrated into the SCB. At least one
SCB is required for the system to function. Two or three SCBs increase
capacity or provide redundancy, depending on the specific platform.
For more information on specific SRX Series high-end system models and hardware,
visit the Juniper Networks Web site for technical publications at
http://www.juniper.net/techpubs.
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
line of products.
Physical packet flow through a high-end security platform proceeds through the
following sequence of steps:
1.
2.
The packet traverses the switch fabric from the IOC to the NPC. (In the
SRX5000 line of products, the NPC integrates with the IOC.) The NPC
performs a flow lookup. If the packet belongs to an existing flow, the NPC
forwards the packet to the SPC associated with the packets session. If
the flow does not currently exist, the NPC installs a new session for the
flow and assigns the flow to an SPC for processing. The NPC also
performs QoS, policing, and shaping.
3.
The packet traverses the switch fabric to its associated SPC, where
security processing and forwarding or routing occurs.
4.
The packet traverses the switch fabric back to an NPC where additional
packet processing such as shaping and QoS occurs.
5.
The packet traverses the switch fabric to the IOC associated with the
egress interface and travels to the attached physical medium.
Physical Interface Modules (PIMs): The SRX Series line of branch and
enterprise devices provide various media interfaces known at PIMs. The
media support includes 10/100 Ethernet, 10/100/1000 Ethernet,
Gigabit Ethernet, T1/E1, T3/E3, ISDN, serial, ADSL and G.SHDSL
interfaces, depending on the model. Some SRX Series branch models
also contain an ExpressCard slot for utilization with a 3G wireless card to
serve as a backup for primary interfaces. Select models contain Power
over Ethernet (PoE) enabled ports.
Services and Routing Engine (SRE): The SRE, a field replacable unit in
the SRX650, houses the processing unit and provides processing power
for security services; routing protocol processes; and other software
processes that control the services gateway interfaces, some of the
chassis components, system management, and user access to the
device.
For more information on specific JUNOS security platform branch models and
hardware, visit the Juniper Networks Web site for technical publications at
http://www.juniper.net/techpubs.
Session-Based Forwarding
Note that SRX Series
branch platforms have
the capability to
operate strictly in
packet-based mode.
This mode is
configured using the
set security
forwarding-opti
ons family mpls
mode
packet-based
configuration
command and requires
disabling all security
services. Because this
class is focused on
security features and
this functionality will
change in the near
future, we do not cover
this setting.
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,
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.
Data Plane
The data plane on JUNOS security platforms, implemented on IOCs, NPCs, and SPCs
for high-end devices and on CPU cores and PIMs for branch devices, consists of
JUNOS 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
single flow. Real-time processes enable JUNOS Software to perform session-based
packet forwarding.
2.
If the packet does not drop, the software performs a session lookup to
determine whether the packet belongs to an existing session. JUNOS
Software matches on six elements of traffic information for this
determinationsource IP address, destination IP address, source port
number, destination port number, protocol number, and a session token.
3.
If the packet does not match an existing session, the software creates a
new session for it. This process is referred to as the first-packet path. If
the packet matches a session, the software performs fast-path
processing.
Based on the protocol used and its session layer (TCP or UDP), the
software starts a session timer. For TCP sessions, the default timeout is
30 minutes. For UDP sessions, the default timeout is 1 minute. These
values are the defaults, and you can change them.
2.
3.
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.
6.
7.
8.
9.
The software creates and installs the session. Furthermore, the software
caches the decisions made for the first packet into a flow table, which
subsequent packets of that flow use.
10.
Subsequent packets of a flow are all subject to fast-path processing. The software
takes the following steps during fast-path processing:
1.
2.
3.
4.
5.
b.
c.
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.
Once this new session is created, the software puts it into a session hash table for
further packet matching and processing. Depending on the protocol and service (TCP
or UDP), the session is programmed with a default timeout. The default TCP timeout is
30 minutes and the UDP default timeout is 1 minute.
Session Cleanup
If no traffic matches the session during the service timeout, JUNOS Software ages out
the session and frees it to a common resource pool for a later reuse.
2.
The forwarding table shows that the software detects how to reach the
destination network.
3.
Now that the forwarding lookup is complete, the software can determine
the ingress and egress zones required for security policy evaluation.
The packet is from host 10.1.20.5 and is an HTTP packet. This packet
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.
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.
Review Questions
1.
Traditionally, routers process packets on a per-packet basis.
2.
Traditionally, firewalls process packets based on stateful flows.
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 default allows all traffic to pass.
4.
The first packet of a new session is subject to first-path packet processing.
Chapter 32 Zones
Types of zones;
Application of zones;
Monitoring zones.
Zones Chapter 33
Zone Definition
A zone is a collection of one or more network segments sharing identical security
requirements. To group network segments within a zone, you must assign logical
interfaces from the device to a zone.
Chapter 34 Zones
Zones enable network security segregation. Security policies are applied between
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.
Zones Chapter 35
Chapter 36 Zones
Zones Chapter 37
The slide summarizes logical relationships between interfaces, zones, and routing
instances.
Logical interfaces are connections to specific subnets. Zones are logical groupings of
logical interfaces with a common security requirement, and a logical interface can
belong to only one zone. Zone configuration can be as simple as a two-zone setup,
where all interfaces connected to internal networks are in one zone, and all interfaces
connected to the external world are in a different zone. A more complicated
configuration might divide interfaces based on internal department or function in
addition to external and demilitarized zone (DMZ) connections.
A physical device can be broken up into multiple routing instances. A routing instance
is a logical routing construct within a platform running JUNOS Software. Each routing
instance maintains its own routing table and forwarding table. A routing instance can
contain one or more zones, which cannot be shared with other routing instances.
Chapter 38 Zones
Zone Types
The zones within JUNOS Software can be subdivided into two categoriesuser-defined
and system-defined. You can configure user-defined zones, but you cannot configure
system-defined zones. You can subdivide the user-defined category into security and
functional zones. We cover user-defined and system-defined zones in detail on the
next few pages.
Zones Chapter 39
Security Zones
Security zones are a collection of one or more network segments requiring regulation
of inbound and outbound traffic through the use of policies. Security zones apply to
transit traffic as well as traffic destined to any interfaces belonging to the security
zone. You need one or more security policies to regulate intrazone and interzone
traffic. Note that JUNOS Software does not have any default security zones, and you
cannot share a security zone between routing instances.
Functional Zones
Functional zones are special-purpose zones that cannot be specified in security
policies. Note that transit traffic does not use functional zones. While the fxp0
management ethernet interface is out-of-band by default, the Management Zone
allows you to assign other network interfaces the same behavior of isolating
management traffic from transit traffic.
Null Zone
Currently there is only one system-defined zone, the Null Zone. By default, an
interface belongs to the Null Zone. You cannot configure the Null Zone. When you
delete an interface from a zone, the software assigns it back to the Null Zone. JUNOS
Software rejects all traffic to and from interfaces belonging to the Null Zone.
Branch Platforms
JUNOS security platforms for the branch ship from the factory with a template
configuration that includes security zones. SRX high-end platforms do not contain
zones in the factory-default template configuration and, therefore, you must configure
required zones manually.
Factory-Default Configuration
In branch devices factory-default configuration, two security zones are defined
trust and untrust. In the template configuration, ge-0/0/0.0 belongs to the
trust zone. In addition, the factory-default configuration file has a security policy
permitting all transit traffic within the trust zone and from the trust zone to the
untrust zone. The security policy prohibits any traffic from the untrust zone to the
trust zone. We discuss security policy in further detail in a subsequent chapter. The
zone names trust and untrust have no system-defined meaning. Like any zones
defined in the configuration, you can modify or delete them. You can revert a JUNOS
Software-based platform to its factory-default configuration by entering the load
factory-default command from the top of the configuration hierarchy.
Zone Configuration
The slide highlights the topic we discuss next.
Configuration Mode
To define a zone you must enter configuration mode, as illustrated on the slide.
1.
2.
The slide shows an example of zone configuration. What types of traffic are allowed
into the specified zone and interfaces?
The slide shows another example of zone configuration. What types of traffic are
allowed into the specified zone and interfaces?
The slide shows the third example in this series. What does this configuration do?
Monitoring Zones
The slide is animated.
No additional mouse
click is necessary.
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
the number and names of interfaces bound to the zone.
The slide provides the continuation of the output from the previous page.
Types of zones;
Application of zones;
Zone monitoring.
Review Questions
1.
A zone is a collection of one or more network segments sharing identical security
requirements.
2.
Overall, there are two types of zones in JUNOS Softwareuser-defined and system-defined
zones. User-defined zones include security and functional zones, both of which you can
configure. The Null Zone is a system-defined zone that you cannot configure. The security
zone facilitates transit packets and packets to the device itself. The functional zone facilitates
only management traffic. The Null Zone is a placeholder for interfaces that do not belong to
any zone. All interfaces belonging to the Null Zone drop all packets.
3.
To configure a zone, you must perform the following steps: (1) Define a security zone or a
functional zone; (2) Add logical interfaces to the zone; and (3) Optionally, add services and
protocols that must be permitted into the device.
4.
You can specify traffic types to be allowed into a JUNOS security platform using the
host-inbound-traffic statement.
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
zones, it determines the corresponding security policy, and it performs a security
policy lookup. The system checks the packet against defined policies to determine
how to treat the packet.
In this chapter, we focus on the security policies portion of JUNOS Software.
host-inbound-traffic Examination
If the destination of traffic is the devices incoming interface, security policies are not
applicable. The only examination that takes place is the list of services and protocols
allowed into that interface using the host-inbound-traffic statement within a
zone definition. (See Chapter 3: Zones for details.)
JUNOS Software examines security policies if the traffic destination is any interface
other than the incoming interface. This process is true regardless of whether the
incoming interface and the destination interface are in the same zone (intrazone
traffic) or in different zones (interzone traffic).
The flowchart on the slide illustrates the order of packet examination. When the
device receives traffic destined to itself, it first examines whether the destination of
the traffic is the incoming interface. If so, it skips the policy examination. Otherwise,
the corresponding security policies evaluate the traffic. If no policy match exists for
the traffic, the default policy action applies. We discuss the default security policy on
the next 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
within the corresponding zone, and applies the corresponding action.
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
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.
Trust-to-trust zone policy: Permits all intrazone traffic within the trust
zone;
2.
Trust-to-untrust zone policy: Permits all traffic from the trust zone to the
untrust zone; and
3.
Untrust-to-trust zone policy: Denies all traffic from the untrust zone to the
trust zone.
The devices interfaces are separated into three security zonesprivate, external, and
public. The business requirement calls for an SSH application to be allowed from
Host B, located in the private zone, to Host D, located in the external zone. To meet the
requirement, we created the security policy illustrated on the slide.
The following is the sequence of events that takes place:
1.
2.
The JUNOS security device receives traffic and examines it using its
security policy from the private zone to the external zone. The security
policy permits that traffic.
3.
The Host B-to-Host D flow triggers the creation of the reverse flow from
Host D to Host B. The slide identifies the contents of this newly formed
session. It consists of two flowssource to destination and destination to
source.
4.
Host D sends the return traffic, from Host D to Host B. The device, using a
pre-created session, permits the return traffic through to Host B.
Policy Ordering
Because policies execute in the order of their appearance in the configuration file, you
should be aware of the following:
You can change the order of policies in the configuration file using the
JUNOS Software insert command.
The last policy is the default policy, which has the default action of
denying all traffic.
Policy Components
The slide highlights the topic we discuss next.
You must specify all matching components. If you omit any of these components,
JUNOS Software will not allow you to commit the configuration.
Firewall authentication;
IDP; and
UTM features.
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
Transfer Protocol (HTTP) to access protected resources across the device
receive authentication through a username and password. The JUNOS
security platform intercepts the session and then performs user
authentication.
Each policy has a set of actions that the system performs upon success
of all matching conditions;
Many security policies within the same direction of the flow can exist; and
Policy Scheduling
A policy scheduler is a method for scheduling a policy execution for a specified
duration or a set of durations. A policy scheduler is optional. A scheduler supports
system time updates either through manual configuration or through the Network
Time Protocol (NTP) by synchronizing itself with the time changes.
Slot schedule: This component consists of the start date and time and
the stop date and time of policy enforcement; and
Daily schedule: This component consists of the start time, the stop time,
the all-day option, and the exclude option.
Note that irrespective of the value of policy-rematch policy flag, deletion of the
policy causes the device to drop all impacted existing sessions.
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
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.
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.
Review Questions
1.
The basic components of a policy are: (1) policy name; (2) source zone and destination zone;
(3) matching conditions, consisting of one or many source addresses or sets, one or many
destination addresses or sets, one or many applications or sets; and (4) actions.
2.
The default action for every policy set is to deny traffic.
3.
The policy scheduler enables the user to dynamically activate or deactivate a security policy. If
you deactivate a policy, and no other matches are found, the default security policy examines
the packet.
4.
You can reorder policies using the JUNOS Software insert command.
Pass-Through Authentication
Two types of firewall user authentication are availablepass-through or Web
authentication. Pass-through authentication must first be triggered by Telnet, FTP, and
Hypertext Transfer Protocol (HTTP) traffic. In this type of firewall authentication, the
user initiates a session to a remote network device or resource. If traffic matches the
security policy configured for pass-through authentication, the SRX Series Services
Gateway intercepts the session. The user receives a prompt for a username and
password. If the authentication is successful, subsequent traffic from the same
source IP address is automatically allowed to pass through the device, provided it
matches the applied security policy.
Web Authentication
Web authentication is valid for all types of traffic. With Web authentication configured,
users must first directly access the JUNOS security platform using HTTP. The user
enters the address or hostname of the device into a Web browser and then receives a
prompt for a username and password. If authentication is successful, the user can
then access the restricted resource directly. Subsequent traffic from the same source
IP address is automatically allowed access to the restricted resource, as long as
security policy allows for it.
Local Authentication
JUNOS Software supports local authentication on the JUNOS security platform itself as
well as RADIUS, LDAP, and SecurID external authentication servers. The local
password database supports authentication and authorization.
RADIUS Authentication
JUNOS Software supports Juniper Networks Steel-Belted Radius for authentication as
well as authorization. The JUNOS security platform acts as a RADIUS client and
communication uses UDP. RADIUS uses a shared secret key to encrypt user
information during the exchange.
LDAP Authentication
An LDAP server is another form of external authentication server. JUNOS Software
supports authentication only when utilizing an LDAP server. JUNOS Software is
compatible with LDAP Version 3 and Microsoft Windows Active Directory.
Continued on next page.
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 users 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.
Pass-Through Authentication
The slide highlights the topic we discuss next.
Pass-Through Authentication
The slide is animated.
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
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.
The default idle timeout of 10 minutes is configurable as shown:
Web Authentication
The slide highlights the topic we discuss next.
Web Authentication
The slide is animated.
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
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
configurable as shown here:
Client Groups
The slide highlights the topic we discuss next.
Review Questions
1.
JUNOS Software supports RADIUS, LDAP, and SecurID external authentication servers.
2.
In pass-through authentication, the user attempts to access the remote network resource
directly, and the JUNOS security platform intercepts the session to perform firewall
authentication, while buffering the session. The buffered session is released as long as
authentication is successful. In Web authentication, the user must first access an IP address
belonging to the JUNOS security device using a Web browser; the authentication is
performed using this HTTP session. The user can then proceed to access the remote network
resource as long as authentication is successful. FTP, Telnet, and HTTP traffic trigger
pass-through authentication, while an HTTP session must trigger Web authentication.
3.
A client group is a list of groups associated with a client. Groups can be used in security
policies in place of individual clients for ease of management.
4.
Use the show security firewall-authentication history command to
view a history of firewall authentication attempts.
Although basic network security issues have changed very little over the past decade,
the network security landscape has changed dramatically. Todays IT professionals
must still protect the confidentiality of corporate information, prevent unauthorized
access, and defend the network against attacks. They also face new challenges as
their networks become more complex and dynamic. The following list examines some
of these issues:
The key to striking a balance between tight network security and the network access
required by employees, business partners, and customers is a layered security
solution. A layered security solution gives you a complete set of tools you can deploy to
achieve end-to-end security from the remote site to the data center. If one layer fails,
the next layer stops the attack, limits the damage that might occur, or does both.
Continued on next page.
At the heart of an enterprise is the network data center (or network core)
where the applications and data that drive day-to-day business reside.
Financial, human resources, and manufacturing applications with
supporting data represent the company crown jewels and, if
compromised, can sink even the most stable enterprise. The core
network security layers must protect these business-critical resources by
preventing unauthorized user access, containing internal attacks
launched by disgruntled employees, and protecting against
application-level attacks.
Before discussing SCREEN options, we revisit packet flow through a JUNOS security
platform. Note that SCREEN processing occurs before any packet processing, which
results in fewer resources used and better protection of the JUNOS security platform
itself.
Stages of an Attack
To understand SCREEN option configuration, we must first discuss the stages of
network attacks and the types of network attacks. A network attack consists of three
major stages. In the first stage, the attacker performs reconnaissance on the target
network. This reconnaissance might consist of many different kinds of network
probes. In this information-gathering phase, the attacker works to gather information
about the target network, any open ports, and the operating systems in use.
In the second stage, the attacker launches an attack at the target network. To protect
themselves, attackers must also conceal the origin point of the attack and attempt to
remove any evidence that an attack took place.
Depending on the type of attack, a third phase can occur. After infiltrating a trusted
machine, the attacker can use that machine as a point of origin for further invasion of
the network. Traffic now appears to originate from the trusted system, which might not
be subject to the same security scans as an outside system.
IP Address Sweep
Attackers can better plan their attack when they first know the layout of the targeted
network, possible entry points, and constitution of their victims.
An address sweep occurs when one source IP address sends Internet Control
Message Protocol (ICMP) packets to different hosts. The purpose of this scheme is to
send traffic to various hosts in hope that one replies, thus revealing an address to
target.
Port Scanning
A port scan occurs when one source IP address sends IP packets containing TCP SYN
segments to different ports at the same destination IP address. The purpose of this
scheme is to scan services in hope that one port will respond, thus identifying a
service to target.
IP Options
RFC 791, Internet Protocol, specifies a set of options to provide special routing
controls, diagnostic tools, and security. RFC 791 states that these options are
unnecessary for the most common communications and, in reality, they rarely
appear in IP packet headers. When they do appear, they are frequently being put to
illegitimate use.
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
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.
The Defense
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
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.
The Attack
RFC 791 specifies a set of options within an IP packet, providing special routing
controls, diagnostic tools, and security. Within an IP packet header, these options
come after the destination address field. Although the original intent for these options
was to enhance network functionality, most common communications do not require
them. As the Internet expanded and continues to expand, attackers have started
abusing the options field of a packet, causing problems to networks and network
devices. An attacker can abuse the record route, timestamp, security, and stream ID
fields.
The Defense
To compensate for the vulnerability that these IP options fields create, JUNOS
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.
IP OptionsSCREEN 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
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.
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 optionsit 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.
The Attack
Prior to launching an exploit, an attacker might probe the targeted host, trying to learn
its operating system. Various operating systems react to TCP anomalies in different
ways. With that knowledge, an attacker can decide which further attack might inflict
more damage to the device, the network, or both.
The Defense
JUNOS Software configured with the appropriate SCREEN options blocks operating
system probes by detecting any of the following invalid TCP flag settings:
No flags set.
TCP traffic matching any of these criteria is immediately, and silently, dropped.
To detect the condition when both SYN and FIN flags are set, use the
syn-fin configuration option;
To detect the condition when the FIN flag is set and the ACK flag is not
set, use the fin-no-ack configuration option; and
To detect the condition when no flags are set, use the tcp-no-flag
configuration option.
Note that this configuration only defines the SCREEN optionsit 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.
The Attack
IP address spoofing is one of the earliest and most well known attacks. An attacker
simply inserts a fake source address into the packet header source address field in an
attempt to make the packet appear as if it is coming from a trusted source.
The Defense
JUNOS Software provides IP address spoofing detection with the help of forwarding
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.
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
compares the source IP address 168.10.10.1 of the incoming packet with the closest
match prefix found in its forwarding table, which is 168.10.10/24. It then detects that
the interface associated with prefix 168.10.10/24 is different from the ingress
interface of the packet, which is ge-1/0/0. The software concludes that the packet
has a spoofed source IP address and discards it.
To set up the JUNOS Software IP spoofing SCREEN option, you must perform the
configuration shown on the slide. Note that this configuration only defines the
SCREEN optionit 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.
The Attack
Source routing allows users to specify the packets desired path when traversing a
network. This feature provides additional aid to users during network troubleshooting.
Unfortunately, over the years, attackers have started to abuse source route options.
They use the fields to hide their true address and access restricted areas of a network
by specifying a different route.
The Defense
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.
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
traffic through network 5.5.5.0/24. The attacker spoofs the source address to be part
of network 5.5.5.0/24, and by using the loose source option, directs the packet
through network 5.5.5.0/24. Because the packet came from the 5.5.5.0/24 network
and has the source address of that subnet, it seems to be valid. However, it has the
loose source route option set. We also assume that you enabled the SCREEN option
that discards the packets with the source route option set. As a result, when the
packet arrives at the ge-1/0/0 interface, the JUNOS security platform rejects it.
To set up the JUNOS 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 optionsit 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.
The Attack
The slide lists some of the forms that session table floods can take.
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
servers). By recognizing that all connection attempts originate from the same source
IP address, JUNOS Softwares 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
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.
A SYN-ACK-ACK attack uses TCP connections. The attacker, using a seemingly normal
TCP connection, sends the SYN-ACK-ACK pattern, hoping that the targets will respond
and immobilize themselves. In the illustration shown on the 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
log in. Instead, such a user continues to initiate SYN-ACK-ACK sessions, leading the
devices session table to its limit, which can result in rejecting legitimate connection
requests.
The Attack
A SYN flood occurs when a network resource becomes overwhelmed with SYN
segments initiating uncompleted connection requests to the point where it cannot
accept legitimate connections. Very often a SYN flood attack inundates a site with SYN
segments containing forged or spoofed IP source addresses with nonexistent or
unreachable addresses, thereby forcing the targeted network resources to respond
with SYN/ACK segments to those addresses, then wait for responding ACK segments.
As the SYN/ACK segments travel to nonexistent or unreachable IP addresses, a
response never occurs, thus leading to a connection timeout. SYN floods also fill up
the memory buffer of the targets, potentially disrupting the operating system. A SYN
flood is usually directed at one or more network resources resulting in a network DoS.
The Defense
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
shields hosts on the protected network from incomplete 3-way handshakes. The next
two pages list the specifics of these protection schemes.
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.
Although these threshold parameters are independent of each other, you can
combine the SCREEN options in the configuration for better protection against
attacks.
However, if the initiating host responds with a TCP packet containing the cookie plus 1
in the TCP ACK field, the software extracts the cookie, subtracts 1 from the value, and
recomputes the cookie to validate that it is a legitimate ACK message.
If the cookie is legitimate, the software starts the TCP proxy process by setting up a
session and sending a SYN to the destination host with the source information from
the original SYN message. When JUNOS Software receives a SYN/ACK from the
destination host, it sends ACK messages to the destination and the originating hosts.
Now the connection establishes and the two hosts can communicate directly.
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
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.
The Attack
A LAND attack occurs when an attacker sends spoofed SYN packets containing the IP
address of the target as both the destination and the source IP address. A receiving
system responds by sending the SYN-ACK packet to itself, creating an empty
connection that lasts until it reaches the session idle timeout. Flooding a system with
such empty connections can overwhelm one or more network resources resulting in a
network DoS.
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.
Once you enable the LAND attack SCREEN option, the network is protected from the
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.
The Attacks
The Ping of Death is an OS-targeted attack. It uses an oversized ICMP packet (larger
than 65,507 bytes), which can trigger a wide range of adverse OS reactions, including
DoS, crashing, freezing, and rebooting.
Teardrop attacks exploit the reassembly of fragmented IP packets. One of the fields in
the IP header is the fragment offset field, which indicates the starting position of the
data contained in a fragmented packet relative to the data of the original
unfragmented packet. When the sum of the offset and size of one fragmented packet
differ from that of the next fragmented packet, the packets overlap. A server
attempting to reassemble such a packet can crash.
WinNuke is a DoS attack targeting any computer on the Internet running Windows.
The attacker sends a TCP segment, usually to NetBIOS port 139 with the urgent flag
set, to a host with an established connection. This TCP segment introduces a NetBIOS
fragment overlap, which causes many machines running Windows to crash.
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.
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.
The Attack
ICMP, when used properly, provides an excellent aid for error reporting and network
probe capabilities. Typically, ICMP packets have very short messages. Therefore,
typically, ICMP packets do not fragment.
The Defense
JUNOS Software blocks any fragmented ICMP packet. In addition, the software drops
ICMP packets with a length greater than 1024 bytes.
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 options protected zone.
The Attack
IPv4 protocol field values of 137 or greater are currently unassigned and should be
used only for nonstandard or experimental protocols. Unless your network uses a
nonstandard or experimental protocol, you should block packets containing an IPv4
protocol field value of 137 or greater.
The Defense
Once you define the corresponding SCREEN option, JUNOS Software detects and
drops any packet that uses an unknown protocol.
The Attack
IP encapsulates a TCP SYN segment into an IP packet that initiates a TCP connection.
Because the purpose of this packet is to initiate a connection and invoke a SYN/ACK
segment in response, the SYN segment typically does not contain any data.
Furthermore, because the IP packet is small, no legitimate reason exists for it to
fragment. A fragmented SYN packet is anomalous, and as such, it is suspect. When a
victim receives these packets, the results can range from processing packets
incorrectly to crashing the entire system.
The Defense
Once you define the corresponding SCREEN option, JUNOS Software detects and
drops all received SYN fragments.
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.
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
ICMP abnormalities, ICMP floods, and session table floods.
icmp fragment: Blocks any ICMP packets that have the More Fragments
flag set or that have an offset value indicated in the offset field.
icmp large: Blocks any ICMP packets with a length greater than 1024
bytes.
icmp flood threshold: Ignores any ICMP packets received above the
configured threshold. This protection remains in effect for the duration of
the second when the threshold is reached, as well as the following
second.
Note that by enabling SCREEN protection from large ICMP packets combined with
ICMP fragmented packets, you are also automatically enabling protection from the
Ping of Death attack.
The slide illustrates the application of the SCREEN option to the public zone.
Various types of attacks that SCREEN options can detect and prevent;
Review Questions
1.
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.
2.
The available SCREEN options include IP address sweep detection, port scanning detection,
network investigation triggering, operating system probe blocking, abnormal SYN and FIN
flags setting detection, IP spoofing detection, bad IP source route options detection, ICMP
abnormalities detection, and DoS attack detection.
3.
Beyond offering network and host protection against malicious attacks, the main advantage of
using SCREEN options is that JUNOS Software performs SCREEN checks prior to security
policy processing, which results in fewer resources used for malicious packet processing.
4.
There are two main goals for a DoS attack: immobilizing hosts and immobilizing networks.
5.
Apply SCREEN options under the security zones configuration stanza.
NAT processing;
NAT Overview
The slide lists the topics we cover in this chapter. We discuss the highlighted topic
first.
Historically, the NAT concept was born because of the shortage of public IPv4
addresses. Many organizations moved to deploy so-called private addresses using the
IPv4 private addressing space, as identified in RFC 1918. These addresses include
the following ranges:
Because private addresses are not routable within the public domain, edge network
devices can deploy the NAT feature to replace private, nonroutable addresses with
public addresses prior to sending traffic to the public network and vice versa.
Translation consists of replacing the IP address (NAT), port numbers (PAT), or both,
depending on the configuration.
While primarily deployed to translate private addresses to public addresses, NAT can
translate from any address to any other address, including public to public and private
to private addresses.
You can use PAT in conjunction with NAT. Specifically, PATs 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.
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
flow. Note that destination NAT and source NAT occur separately in the first path
packet flow.
VoIP ALGs
Voice over IP (VoIP) application-level gateways (ALGs) dynamically generate the
allow-incoming table for packets from the public network into the private
network. The table contains the list of dynamically generated addresses for voice
traffic.
Matching Conditions
Traffic that requires destination NAT is subject to a two-layer matching scheme.
Similar to security policy, NAT rule creation occurs under a context indicating traffic
direction. The directional context is the first layer of matching. NAT rules are organized
in rule-sets. Each rule-set contains this context by requiring a from clause. The from
clause can indicate an interface, zone, or routing-instance. If rule-sets overlap by
targeting the same traffic, the rule-set with the most specific context takes
precedence. Interfaces are the most specific context, while routing-instances are the
least specific.
The second layer of matching occurs within NAT rules using a match option. These
options include source-address, destination-address, and
destination-port number. An exception to this second layer of matching is static
destination NAT, which supports only the destination-address match option.
This information is evaluated using packet headers.
Overlap
Static NAT rules take precedence over dynamic destination NAT rules.
Note the following general guidelines regarding addresses, rule-sets, or rules that
overlap:
If more than one rule-set matches traffic, the rule-set with the most
specific context takes precedence; and
Use the JUNOS Software insert command to adjust rules within a rule-set.
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
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.
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
indicating traffic direction. The directional context is the first layer of matching. NAT
rules are organized in rule-sets. For source NAT, each rule-set contains this context by
requiring a from clause and a to clause. The from and to clauses indicate an interface,
zone, or routing-instance. If rule-sets overlap by targeting the same traffic, the rule-set
with the most specific context takes precedence. Interfaces are the most specific
context, while routing-instances are the least specific.
The second layer of matching is performed within NAT rules using a match option.
These options include source-address and destination-address. This
information is evaluated using packet headers.
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:
If more than one rule-set matches traffic, the rule-set with the most
specific context takes precedence; and
Use the JUNOS Software insert command to adjust rules within a rule-set.
PAT Is Default
As illustrated in the previous example, JUNOS Softwares implementation of source
NAT enables PAT by default. Because PAT is enabled and the number of available ports
is near 64,000, it is rare that a source NAT pool will exhaust.
Address Persistence
Regardless of the large available source NAT pool, there is no guarantee that JUNOS
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.
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
problemusing 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.
To enable SNMP traps,
you must configure
SNMP under the
[edit system]
configuration
hierarchy. For more
information about
SNMP configuration,
refer to the Juniper
Networks technical
documentation.
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
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
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.
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
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.
Proxy ARP
The slide highlights the topic we discuss next.
NAT processing;
Review Questions
1.
Destination NAT processing occurs before security policy processing and source NAT
processing occurs after security policy processing.
2.
Static source NAT is supported in one of two waysusing source NAT with address shifting
or the automatic creation of a return session when using static destination NAT.
3.
The NAT off action is for detailed control within NAT rule-sets.
4.
A NAT proxy ARP configuration is necessary when the translated address belongs to the
same subnet as the ingress interface.
5.
The commands used to monitor NAT operations are show security flow
session, show security nat source summary (or show security nat
destination summary), show security nat source pool (or show
security nat destination pool), and show security nat source
rule (or show security nat destination rule).
VPN Types
The slide lists the topics we cover in this chapter. We discuss the highlighted topic
first.
Secure VPNs: These VPNs are IPsec VPNs, carrying payload over IP
securely. We will discuss these VPN types in this chapter.
Secure VPNs
A network device that builds secure VPNs must be able to perform the following
actions:
The slide is animated.
It highlights the
encrypted packet
between private and
public sites.
This chapter focuses on end-to-end static IPSec VPNs. However, note that JUNOS
security platforms also support end-to-site dynamic VPNs and VPN establishment
using the NetScreen Remote VPN client. See the Juniper Networks technical
documentation at http://www.juniper.net/techpubs for further information on these
features.
Security Concerns
Three driving concerns exist for network security: confidentiality, integrity, and
authentication.
Authentication: How does the remote station verify that the information
came from the device from which it expected it to come? You do not want
to be communicating and sending critical information to the wrong
recipient!
ConfidentialityData Encryption
The first of the three VPN security concerns is confidentiality.
Encryption provides data confidentiality. Encryption is the method of taking user
datareferred to as plaintextand converting it into unreadable or secret data named
ciphertext. An encryption algorithm and keys (strings of bits that seed the encryption
process) are applied to the data, resulting in ciphertext.
To reverse the process and decrypt the ciphertext, you must know both the encryption
algorithm and encryption key. You can decrypt encrypted data in one of two ways:
Symmetric key encryption: This method uses the same key for both
encryption and decryption; and
The cipher strength depends on the key size; the larger the key, the more secure the
cipher output. The trade-off is in processing timelarger keys use more computational
cycles to encrypt and decrypt.
Symmetric key sizes range from 40 bits1024 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
management is a problem when using symmetric keys.
Examples of symmetric key encryption include Rivest Cipher 4 (RC4), Data Encryption
Standard (DES), Advanced Encryption Standard (AES), and Blowfish.
Integrity
Now that we have the data encrypted as it traverses the Internet, we must ensure that
the data is not subject to modification along the way. Even though a novice hacker
might not be able to crack the encryption algorithm and key, the hacker can still wreak
havoc by modifying bits that the encrypted payload carries. If this modification
happens, the decrypted output does not match the original data. Who knows what the
consequences might be!
Hashing solves this problem by creating a fingerprint of the data, similar to a cyclic
redundancy check (CRC) checksum. Before data travels, it traverses a hashing engine
that produces a fixed-length hash output. It places the hash in a field in the packet
along with the data before it travels over the network. The destination device takes the
same data and runs it through the same hashing algorithm, calculating its own hash.
The destination device then compares the hash that it calculated against the hash
carried in the packet. The same hash in both locations proves data integrity in transit.
If the hashes do not match, the packet drops.
JUNOS Software supports MD5, SHA1, and 256-bit SHA2 hashing.
You should not be able to calculate the original data from the hashed
output. This property ensures that you cannot derive the plaintext from
the ciphertext.
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
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 requirementa malicious person can change the
plaintext by any multiple of the modulus number and know that the hashed value
remains the same.
The most secure and widely used hash function is the Secure Hash Algorithm 1
(SHA-1). SHA-1 is preferred over Message Digest 5 (MD5), although MD5 is still widely
supported. These functions produce a fixed-length output that is useful when working
with IP packets because the overhead of transmitting the hash value is predictable.
1.
2.
The sender appends the hash value to the data and sends both the data
and the hash value to the receiver.
3.
4.
5.
The receiver then compares the calculated hash value to the received
hash value. If the hash values match, the data is unaltered.
Source Authentication
Encryption protects the packet contents from being viewed on the public network.
Hashing verifies that the data is unaltered. But how do you validate the source of the
data?
The software performs source authentication using the Hashed Message
Authentication Code (HMAC). The sender appends a secret preshared key to the data,
then performs the hash function. For hashes to successfully match, the receiver must
append the same key value to the data before performing the hash function. The key
itself never transmits along with the data.
HMAC Authentication
The following list outlines hashing with HMAC:
The slide is animated.
It illustrates HMAC.
1.
The sender appends the preshared key to the data, then performs the
hash function.
2.
3.
4.
The receiver appends the preshared key to the data, then performs the
hash function.
5.
The receiver then compares the calculated hash value to the received
hash value. If the hash values match, the data is unaltered. If the hash
values do not match, either the data itself is corrupt, or the keys did not
match, meaning the source is invalid. Either way, the receiver discards
the packet.
Key Exchange
As we already discussed, both encryption and authentication are dependent on
security keys, which leads to the problem of key exchange. If keys must be the same
on both sides of a connection, how can you securely exchange key information?
One option is to manually configure the keys on both sides of the connection. Manual
key configuration is straightforward, but misconfigurations, especially when each
device has a different administrator, are common. Furthermore, manual configuration
usually means that keys rarely change, which is itself a potential security issue; given
a large enough sample, any code can be broken.
Automating the key exchange process is a good idea, but we must overcome the
problem of sending keys across a public network. Anyone intercepting the key has the
ability to decode the data.
The Solution
Whitfield Diffie and Martin Hellman developed a solution to this problem in 1970. The
Diffie-Hellman algorithm is a method whereby two parties can agree upon a secret key
known only to them. The strength of the technique is that it allows the participants to
create the secret value over an unsecured medium without exchanging the secret
value itself. This method also makes it impossible to perform reverse generation of
the secret if it is somehow intercepted.
Diffie-Hellman Groups
Diffie and Hellman proposed five groups of prime numbers and generator values to
use in their key exchange algorithm. Each group generates unique keys using a
combination of exponential and modulus calculations.
Juniper Networks does
not support Groups 3
and 4.
JUNOS Software supports Diffie-Hellman (DH) Groups 1, 2, and 5. The larger the
prime numberthe stronger the keyand the more computationally intensive the
calculation. Diffie-Hellman Group 1 uses a 768-bit prime number. Diffie-Hellman
Group 2 uses a 1024-bit prime number. Diffie-Hellman Group 5 uses a 1536-bit prime
number.
You must configure both tunnel peers to use the same DH group; otherwise, the key
generation process fails.
Using the same DH group, each JUNOS security platform creates unique public and
private keys. These keys are mathematically related by means of the DH algorithm.
The public key values exchange across the network. Each peer then runs its local
private key and the received public key value through the DH algorithm to compute a
common session key. The session key itself never passes across the network.
IPsec Details
The slide highlights the topic we discuss next.
IPsec Overview
IPsec is a set of standards that defines how the encryption, validation, and
authentication methods we just discussed are actually implemented in networks.
IPsec works at Layer 3; it supports both unicast and multicast traffic.
1.
2.
We cover the first stepIPsec tunnel establishment using IKEon the next several
pages.
Encryption algorithm;
Hash algorithm;
Diffie-Hellman group.
Once IPsec peers negotiate these attributes, they secure future attribute exchanges
used to protect data. IKE exchanges authenticate using one of the following methods:
Preshared keys;
Digital signatures; or
Security Associations
A security association (SA) is a set of policies and keys used to protect information.
SAs establish upon the successful completion of IKE negotiations. An SA is uniquely
identified by the security parameter index (SPI) value, the tunnel destination address,
and the security protocolEncapsulating Security Payload (ESP) or authentication
header (AH)in use. The lifetime of an SA can be based on either a time value or a
value determined by the volume of traffic protected by the proposal.
SA Database
SAs are stored in a security association database. Each entry includes the name of
the particular VPN, the remote gateway IP address, the SPIs for each direction, the
agreed-upon security protocol, encryption, and authentication algorithms and keys.
IKE Phases
IKE tunnel establishment happens in two phases:
A single Phase 1 channel can establish multiple Phase 2 SAs or VPNs. If wanted, a
second Diffie-Hellman exchange can be performed during Phase 2 to negotiate a new
tunnel key. Because of the encryption on this exchange, it is named Perfect Forward
Secrecy (PFS).
Encryption algorithm;
Hash algorithm;
DH group; and
Authentication method:
Preshared keys;
The first two messages validate the peer configuration (by checking the cookie against
the locally configured peer IP address) and negotiate the parameters listed previously.
Both tunnel peers must have at least one configured matching proposal for Phase 1
exchange success.
The next two messages exchange Diffie-Hellman public key values and nonces
necessary to compute the shared key.
The last two messages send simple identification information using the negotiated
key; these messages validate that the key calculation was correct.
Continued on next page.
DH group number;
Encryption algorithm;
Key lifetime.
For Message 3 and Message 4, the DH public values exchange to create a common
session key. Nonces, which are essentially random numbers, also exchange at this
time for use as seeds for keys generated later.
After both sides exchange their DH public values, a key is created on each side to
encrypt the rest of the IKE Phase 1 messages. The session key is a result of the
exchanged public keys traveling to each partner.
Messages 5 and 6 contain the preshared key.
IKE aggressive mode is used when one of the tunnel peers has a dynamic IP address
that could be a remote end user dialing in to the Internet, or a remote site using DHCP
to acquire an IP address. (Main mode cannot be used because the first two messages
validate peer IP addresses. In the case of a dynamic host address, the peer cannot
preconfigure the address.)
Phase 1 aggressive mode must initiate by the device with the dynamic IP address. The
first two messages negotiate policy and exchange DH public values and nonces. In
addition, the second message authenticates the responder; the ID hash is compared
with the locally configured peer ID.
The third message authenticates the initiator and provides a proof of participation in
the exchange.
Optional DH group.
Upon successful completion of quick mode, user data encrypts between the
configured IPsec peers. Both tunnel peers must have at least one matching proposal
configured for Phase 2 exchange success.
The result of Phase 2 is to create an IPsec VPN for user data to securely transmit
through the network.
Continued on next page.
ESP or AH;
Encryption algorithm;
Authentication algorithm;
Key lifetime;
Message 3 acknowledges information sent from quick mode Message 2 so that the
Phase 2 tunnel can establish.
Now that we have covered the tunnel establishment step of the IPsec process, we
cover the next stepIPsec traffic processing. Once the IPsec tunnel establishes, the
devices are ready to send the payload using the IPsec attributes and protocols, which
ensure payload protection.
IPsec Modes
IPsec handles the payload using one of two modestransport or tunnel. We discuss
each mode in the next few pages.
IPsec Protocols
IPsec uses two protocols to ensure payload securitythe AH protocol and the ESP
protocol. Again, we discuss each of these protocols in the next few pages.
IPsec Modes
You can implement IPsec in the following two modes:
IPsec Protocols
Two protocols exist that IPsec can use to ensure payload securityAH protocol and
ESP:
ESP Auth is the integrity check value (that is, the hash value) for this packet.
1.
2.
3.
JUNOS Software looks up the security policy. The traffic matches a tunnel
policy.
4.
5.
6.
JUNOS Software builds the tunnel packet with a new IP header, IPsec
header, and hash value. The new packet travels to the tunnel peer.
7.
8.
JUNOS Software looks up the incoming SPI in the local SA database. The
matching record contains encryption and authentication algorithms, and
keys.
9.
JUNOS Software compares the locally calculated hash with the received
hash.
10.
11.
JUNOS Software performs the routing lookup for the decrypted packet
and determines the Egress Zone.
12.
Route-based VPNs: Unlike the process for policy-based IPsec VPNs, for
route-based IPsec VPNs, a policy refers to a destination addressnot an
IPsec VPN tunnel. Because a destination address is used, route-based
VPNs are generally the best VPNs to use when a routing protocol
adjacency must be formed across the tunnel. When JUNOS Software
searches a route that must send traffic to the destination address, it
finds a route associated with a secure tunnel interface (st0.x). The tunnel
interface is bound to a specific IPsec VPN tunnel, and traffic routes to the
tunnel if the policy action is permit. With a route-based IPsec VPN, in
most cases, only one VPN exists between two sites.
1.
2.
3.
B.
C.
The slide addresses Step A, which is optional, as you can use the JUNOS Software
predefined proposals. The following are the predefined proposals:
basic:
compatible:
standard:
B.
C.
The slide addresses Step A, which is optional, as you can use predefined proposals.
The following are the predefined proposals:
basic:
compatible:
standard:
1.
2.
Configure a static route or enable dynamic routing that points to the st0.x
interface;
3.
4.
Consider the following example: you must implement a policy-based IPsec VPN
between two SRX Series Services Gateways named Edge and Remote, as illustrated
on the 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.
Proposal for IKE Phase 1: Recall that this step is optional, because you
can use JUNOS Softwares 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.
2.
3.
You must repeat the illustrated configuration on the Remote device, defining the
appropriate external interface and gateway address.
A proposal for IKE Phase 2: Recall that this step is optional because you
can use JUNOS Softwares predefined proposals (the choices are basic,
compatible, or standard). We named the configured proposal
ike-phase2-proposal. We decided to use authentication algorithm
hmac-md5-96, encryption algorithm 3des-cbc, and the ESP protocol.
2.
3.
Note that you should repeat the configuration illustrated for the Edge device on the
Remote device.
The proposal for IKE Phase 1: Recall that this step is optional because
you can use JUNOS Softwares predefined proposals (the choices are
basic, compatible, or standard). We named the configured
proposal ike-phase1-proposal. We decided to use authentication
algorithm md5, encryption algorithm 3des-cbc, a DH key exchange of
group2, and preshared keys as the authentication method.
2.
3.
Note that you must repeat the illustrated configuration at the Remote device, defining
the appropriate external interface and gateway address.
A proposal for IKE Phase 2: Recall that this step is optional, because you
can use JUNOS Softwares predefined proposals (the choices are basic,
compatible, or standard). We named the configured proposal
ike-phase2-proposal. We decided to use authentication algorithm
hmac-md5-96, encryption algorithm 3des-cbc, and the ESP protocol.
2.
3.
When you compare the configuration on the slide to the policy-based IPsec IKE
Phase 2 configuration, you will notice that the only difference between the two is the
statement binding interface st0.0 to the tunnel.
Note that we must also repeat the configuration illustrated for the Edge device at the
Remote device.
Review Questions
1.
The three major security concerns are confidentiality, integrity, and authentication.
2.
The main difference between ESP and AH is that AH does not provide confidentiality, while
ESP does.
3.
JUNOS Software supports the use of the MD5 and SHA protocols to ensure data integrity.
4.
The two modes available in IKE Phase 1 are main and aggressive.
What Is IDP?
Initially, network defense consisted of basic stateless firewall protection. Network
devices, such as routers, often provided this feature. As network attacks became
more sophisticated, network defense also had to become more sophisticated. Stateful
firewalls, authentication mechanisms, and VPN devices utilizing encrypted traffic
offered additional protection from harmful network traffic and malicious users.
Traditional firewalls might not detect some malicious traffic because manufacturers
design VPN devices and firewalls for high-speed operation of VPN control and access
control. For these types of attacks, the solution is to use IDP.
The JUNOS Software IDP feature provides additional security beyond a firewall. While
a firewall traditionally inspects only Layers 3 and 4, JUNOS Software utilizes the IDP
feature to decode and reassemble the protocol stream and thus sees traffic from the
applications point of view (Layer 7). When IDP reassembles the data stream, JUNOS
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
future sessions, and log attacks for review by network administrators.
Utilizing IDP in combination with SCREEN options, zones, security policies, and other
JUNOS security features offers a complete approach to network security.
IDP Successes
Check the security
portal for updates on
recent attack
prevention successes.
Stressing a recent
attack or worm such as
the Conficker worm,
which has predefined
attack objects
associated with it, will
emphasize the
timeliness of signature
database updates.
The JUNOS Software IDP feature regularly protects networks from the latest Microsoft
vulnerabilities. The attack database updates as new threats emerge, keeping JUNOS
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
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.
no-action: JUNOS Software takes no action (used when you only need
to generate a log);
The example on the slide also illustrates a notification action. This action instructs
JUNOS Software to log the attack.
Source IP;
Destination IP;
Destination Port;
Protocol.
You can use the severity action to override the default attack severity to a configured
value.
You can make an IDP rule terminal using the configuration shown on the slide. When
the software configures a match in a terminal rule for the source, destination, zones,
and application, it does not continue to check subsequent rules for the same source,
destination, and application. It does not matter whether traffic matches the attack
objects in the matching rule or not. This option is useful for disregarding traffic that
originates from a known trusted source. Terminal rules should appear near the top of
the rulebase and before other rules that would match the same traffic.
Exempt Rulebases
The functionality of an exempt rulebase complements an IPS rulebase. You can write
rules in an exempt rulebase to skip detection of a set of attacks in certain traffic.
Carefully written rules in an exempt rulebase can significantly reduce the number of
false positives generated by an IPS rulebase. Note that you must configure an IPS
rulebase before using an exempt rulebase. Rules in an exempt rulebase have the
same matching conditions as those of an IPS rulebase. The exception is that you
cannot configure the application object, which means rules match all applications.
When configuring attack or attack-group objects in an exempt rulebase, note that
these attacks are attacks the software should not inspect in traffic matching this rule.
No actions are available for exempt rulebases.
Signature Database
The slide highlights the topic we discuss next.
The signature database is one of the major components of IDP. It contains definitions
of different objectssuch as attack objects, application signature objects, and service
objectsthat it uses to define IDP policy rules. As a response to new vulnerabilities,
Juniper Networks periodically provides a file containing attack database updates on
its Web site. You can download this file to protect your network from new threats. The
database lists the attack objects alphabetically, and the names consist of the attack
object group name and the name of the attack object, as shown on the slide.
The security package, which you can download from Juniper Networks, also includes
IDP policy templates to help you implement IDP policy on your JUNOS security
platform. You can use the template policies as they are, or you can customize them for
your network environment. Templates exist for a multitude of network scenarios. The
most widely used template is called the Recommended policy. We discuss
downloading the signature database and policy templates on subsequent slides.
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
successful license addition.
You can download the Juniper Networks security package manually or automatically at
specified time intervals. The slide illustrates the operational mode commands to
download the security package and check the status of the download. You must
connect the JUNOS security platform to the Internet to update a device directly.
Alternatively, you can download the update to a Network and Security Manager (NSM)
device, which can be configured to push the updated database to your JUNOS security
platform.
Automatic Downloads
As mentioned previously, you can configure a JUNOS security platform to automatically
download the security package. The slide also shows an example configuration of
automating the download.
IDP Counters
The command shown on the slide along with one of the command arguments provides
various counters useful in monitoring IDP operation.
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.
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
platform.
When you configure an IDP rule for logging, each matching event creates a log entry.
Because the software generates IDP event logs during an attack, log generation
happens in bursts, generating a much larger volume of messages during an attack. In
comparison to other event messages, the message size is also much larger for
attack-generated messages. The log volume and message size are important
concerns for log management. To better manage the volume of log messages, IDP
supports log suppression. Log suppression limits multiple instances of the same log
occurring from the same or similar sessions over a given period of time. The software
enables log suppression by default but you can adjust attributes through configuration
under the [edit security idp sensor-configuration log
suppression] hierarchy.
IDP Traceoptions
You can configure IDP traceoptions to log control plane events. Currently, the only flag
available is the all flag. By default, the software logs IDP traceoptions events to the
/var/log/idpd file.
Review Questions
1.
JUNOS Software processes the rule with the most severe action.
2.
The exempt rulebase exempts specified traffic from IDP policy.
3.
Evaluation of a rulebase stops only when the software matches a terminal rule.
4.
To apply an IDP policy, you must make it the active policy and reference an IDP action in a
security policy.
The JUNOS Software high availability (HA) feature provides stateful session failover.
This ability applies to TCP and UDP sessionsthose that deploy Network Address
Translation (NAT), IP Security (IPsec), or authentication, as well as those that do not.
High availability includes the synchronization of configuration files and the dynamic
runtime session states between JUNOS security platforms deploying it. The JUNOS
Software implementation of high availability clustering currently supports an
active-passive redundancy for the control plane and an active-active redundancy for
the data plane. Check the Juniper Networks technical documentation for high
availability support specific to your platform at http://www.juniper.net/techpubs.
We address all chassis cluster components in the next section of this chapter.
cluster-id Details
You can deploy up to fifteen chassis clusters in your environment. A unique
cluster-id value, which ranges from 115, identifies each cluster. A JUNOS
security platform can belong to only one cluster at any given time. The device ignores
high availability configuration and acts as a standalone device if a cluster-id
value is zero. When a device joins a cluster, it becomes a node within that cluster,
identified by a node id. If you choose to alter a cluster-id id or node id
parameter, you must reboot the device to activate the changes.
node id Details
The node id uniquely identifies a JUNOS security platform within a cluster. Because
only two nodes can exist in a cluster, node id values range from 01.
Recall the interface naming structure used by JUNOS Software:
(media type)-(fpc slot #)/(pic slot #)/(port #), for example, ge-1/0/3.
In the case of JUNOS security platforms, the Flexible PIC Concentrator (FPC) can be
either an IOC , an SPC, a Physical Interface Module (PIM), or a fixed interface. The
software uses the node id value to offset the FPC slot value in the interface name of
a device. Specifically, the software uses the following formula to calculate the FPC slot
number:
Cluster interface FPC slot number=
(node id * max FPC slots) + standalone FPC slot number.
For example, a Juniper Networks SRX5800 Services Gateway has a maximum of 12
slots. Using the FPC slot number calculation, you can determine that the second slot
on node 1 of a chassis cluster uses an interface name of ge-13/x/y or xe-13/x/y.
Redundancy Group
A redundancy group (RG) is an abstract construct that includes and manages a
collection of objects. It contains objects on both nodes of a cluster. An RG is primary
on one node and backup on the other node at any given time. When an RG is primary
on a node, its objects on that node are active.
JUNOS security platforms support up to 256 RGs. RGs are independent units of
failover, and one RGs primacy does not affect the other RGs primacy. In other words,
one of the RGs can be primary on node 0, while the other RG is primary on node 1.
When an RG fails over, all its objects fail over together.
When you initialize a JUNOS security platform in chassis cluster mode, the system
creates a redundancy group called RG0. RG0 manages the primacy and failover
between the REs on each node of the cluster. As is the case for all redundancy groups,
RG0 can be primary on only one node at a time. The node on which RG0 is primary
determines which RE is active in the cluster. You must explicitly create RGx in the
configuration and manage interface redundancy. RGx can contain up to 15 redundant
Ethernet interfaces called reth interfaces. We discuss reth interfaces in detail later in
this chapter.
A primary state; or
A secondary state.
RG Primacy Rules
The rules for RG primacy are as follows:
By default, both nodes have the same priority for RG0, but you can
change the default setting to specify which node is primary for RG0. You
must explicitly configure the node priority for RGx.
If you initialize both nodes of a cluster at the same time and you do not
change the default setting for RG0 node priority, Node 0 takes
precedence.
If one node of the cluster initializes before the other, the first node to
initialize takes precedence and remains the primary node for the RG
unless the preempt configuration option is present. Note that the
preempt configuration option is not supported on RG0.
RG State Transitions
For RGx to fail over automatically to another node, the software must monitor its
interfaces. When you configure an RGx, you can specify a set of interfaces the RG is to
monitor for status, checking whether the interface is up or down. When you configure
an interface for RGx to monitor, you give it a weight value. RGx has a threshold
tolerance value initially set to 255. When an interface monitored by RGx becomes
unavailable, the software subtracts its weight from the threshold. When the threshold
reaches zero, all objects within RGx fail over to the other node.
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
is primary on Node 1 for destination network 10.20.0.0/16. In addition, RG1 is
secondary on Node 1 for destination network 10.10.0.0/16, and RG2 is secondary on
Node 0 for destination network 10.20.0.0/16.
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).
The first chassis in a cluster forms a cluster upon booting up. It transitions from the
blank state to the primary state.
A chassis can join an existing cluster. The RG0 of the joining chassis transitions from
the blank state to the secondary state. RGx transitions from the blank state to either
the primary state or the secondary state based on a combination of priorities and
preempt configurations. The join operation causes the joining chassis to perform
configuration synchronization as well. A join operation might cause the existing cluster
node to change its RGx states from primary to secondary.
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.
A merge action happens when a split cluster regains connectivity. The merged cluster
can cause RG state transitions from primary to secondary.
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.
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
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 flows active session is
on Node 1, and the flows backup session is on Node 0.
At this time, JUNOS security platforms support active-active mode for the data plane
only. The control plane always acts in an active-passive fashion, with the secondary
node providing redundancy to the primary node.
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).
Enabling Clustering
Enabling chassis clustering involves setting a cluster-id id and node id on
each chassis in the cluster. The cluster-id value is the same on both nodes. To
activate clustering, once you set the cluster-id id and the node id, you must
reboot the node designated as the primary device first, then reboot the desired
secondary node.
Form a Cluster
To form a cluster using high-end security platforms, you must configure the control
ports on the node. Because the secondary nodes configuration will be synchronized
with the primary nodes 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
device. Remember to perform this operation first on the node designated to be the
primary node and then on the node designated as secondary.
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
255. Be careful with manual failovers. An RG0 failover implies an RE failover. An RE
failover kills all processes running on the primary node and spawns them on the new
primary RE, which can result in a loss of state, such as routing state.
Use the show log jsrpd command to view chassis cluster events. The jsrpd
process is the process associated with managing chassis cluster events. For some
chassis cluster events, the software dynamically populates this log.
Traceoptions
You can also configure traceoptions for chassis cluster operations. You can set flags
for many events.
{primary:node0}[edit]
user@host# set chassis
Possible completions:
all
cli
configuration
eventlib
fsm
heartbeat
init
interface
routing-socket
socket
uspipc
all events
CLI events
configuration events
event library events
finite state machine events
JSRPD heartbeats
initialization events
interface related events
routing socket events
socket events
USP IPC events
Review Questions
1.
The control plane of a chassis cluster uses SPC ports on high-end systems and revenue ports
on branch platforms and is named fxp1. The data plane connects using physical ports named
fab0 and fab1.
2.
The fab interface serves as the data plane link between nodes in a chassis cluster and
transmits RTOs to replicate session state between the two nodes.
3.
An RG is an abstract entity that manages the redundancy of a group of objects. The software
creates RG0 when a chassis cluster forms to manage primacy of REs. The software uses RGx
to manage primacy of reth interfaces.
4.
The default threshold for interface monitoring is 255.
Acronym List A1
A2 Acronym List
Course Introduction
This chapter contains no review questions.
Chapter 2:
Chapter 3:
Zones
1.
A zone is a collection of one or more network segments sharing identical security requirements.
2.
Overall, there are two types of zones in JUNOS Softwareuser-defined and system-defined
zones. User-defined zones include security and functional zones, both of which you can
configure. The Null Zone is a system-defined zone that you cannot configure. The security zone
facilitates transit packets and packets to the device itself. The functional zone facilitates only
management traffic. The Null Zone is a placeholder for interfaces that do not belong to any
zone. All interfaces belonging to the Null Zone drop all packets.
3.
To configure a zone, you must perform the following steps: (1) Define a security zone or a
functional zone; (2) Add logical interfaces to the zone; and (3) Optionally, add services and
protocols that must be permitted into the device.
4.
You can specify traffic types to be allowed into a JUNOS security platform using the
host-inbound-traffic statement.
Answer Key B1
Chapter 4:
Security Policies
1.
The basic components of a policy are: (1) policy name; (2) source zone and destination zone;
(3) matching conditions, consisting of one or many source addresses or sets, one or many
destination addresses or sets, one or many applications or sets; and (4) actions.
2.
The default action for every policy set is to deny traffic.
3.
The policy scheduler enables the user to dynamically activate or deactivate a security policy. If
you deactivate a policy, and no other matches are found, the default security policy examines
the packet.
4.
You can reorder policies using the JUNOS Software insert command.
Chapter 5:
Chapter 6:
SCREEN Options
1.
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.
B2 Answer Key
Chapter 6:
Chapter 7:
Chapter 8:
IPsec VPNs
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.
Answer Key B3
Chapter 8:
Chapter 9:
B4 Answer Key