JNCIE-SEC V1.3 walkthrough (2017) - iNETZERO · walkthrough (2017) Demo workbook . ... JNCIS-FWV, JNCIP-SEC, JNCIS-ENT, JNCIA-EX. About the authors About me Alexei lives in …

JNCIE-SEC V1.3walkthrough (2017) Demo workbook

Why this demo workbook?

This workbook is intended to give you an idea of what the

purched workbook looks like, and the way the original workbook

teaches you the curriculum.

Due to this, we hope you will understand that

some content will be covered.

If you have any questions, please don’t hesitate to contact me.

Jörg Buesink

[email protected]

Owner iNET ZERO

About meRichard Pracko comes from the heart of the Europe, from a small but beau-

tiful country Slovakia. Right after finishing his studies at the university with

telecommunications as a major, he joined the Siemens Networking depart-

ment, and focused on the integration of Juniper Networks and Siemens

products. There, he gathered a lot of experience and skills in the networking

area by taking an active part to numerous projects, and this , all over the

world. It was during that time that his teaching career started. In the begin-

ning of 2009, he left Siemens on his own initiative, and became a full time

instructor and technical consultant, over a vast geographic area (EMEA and

more).

Richard is an energetic young man, with interests ranging across numerous

sport disciplines like tennis, soccer, skiing and others. Richard speaks En-

glish, German, Czech and Slovak. Richard holds the following certifications:

JNCIS-FWV, JNCIP-SEC, JNCIS-ENT, JNCIA-EX.

About the authors

About meAlexei lives in Moscow and speaks Russian and English. He started his car-

rier in telecommunication area in 1995 as a technician in S.W.I.F.T. Access

Point. Since that time he gained experience as a field, technical support and

systems engineer, project manager, technical writer and instructor. He had

taken part in many projects for corporate clients and service providers, par-

ticipated in the creation of networks based on X.25, Frame Relay, ATM, PDH/

SDH, TCP/IP and VoIP technologies, learned and implemented solutions from

Motorola, Nortel Networks, Tellabs and Acme Packet.

Since 2006 Alexei has been working with Juniper Networks technologies and

products, focusing primarily on security solutions. Alexei becomes energized

and determined to stimulate people to move, grow and develop to higher

levels of personal effectiveness. Alexei holds the following certification: JN-

CIE-SEC#113, JNCIP-M/T, JNCIS-FW, JNCIS-SSL, JNCIA-EX and Acme Packet

Certified Instructor

About meJörg lives in the Netherlands near Amsterdam and brings more than 10 years

of experience in the IT and networking industry. He has worked for several

large ISPs / service providers in the role of technical consultant,designer and

network architect.He has extensiveexperience in network implementation,

design and architecture and teached several networking classes.

CertificationsQuadruple JNCIE certified

(JNCIE-DC#007,JNCIE-ENT#21,JNCIE-SP#284 and JNCIE-SEC#30)

Triple CCIE #15032

(Routing/Switching, Service provider and Security),

Cisco CCDE#20110002 certified,

Huawei HCIE#2188 Routing and Switching.

Rack rental service

Did you know that this workbook can be used in combination with our premium JNCIE rack rental service?

Take a look at our website for more information.

Target audience

This workbook is developed for experienced network engineers who are preparing for the Juniper Net-

works JNCIE-SEC lab exam. Although not required it is highly recommended that you have passed the

JNCIS-SEC written exam. iNET ZERO’s JNCIE-SEC walkthrough guide is targeted at JNCIS-SEC certified

engineers who are studying for the JNCIE-SEC certification and need a little bit of extra help in their

preparation for the JNCIE-SEC lab exam. The JNCIE-SEC walkthrough guide is a very detailed walkthrough

of the JNCIE-SEC v1.3 workbook tasks, including additional theory sections and step by step explanations,

many screenshots for additional help in solving the workbook tasks. This workbook must be used togeth-

er with iNET ZERO’s JNCIE-SEC workbook as it is an add-on product and is not sold separately.

iNET ZERO support

Always feel free to ask us questions regarding the workbook or JNCIE rack rental. You can reach us at

[email protected]. We love to hear from you regarding your preparation progress. Your feedback regard-

ing our products is also very appreciated!

Table of ContentsDetailed walkthrough - Chapter one: General system features

Task 1: Initial configuration

Task 2: Authentication and authorization

Task 3: Syslog

Task 4: NTP

Task 5: SNMP

Detailed walkthrough - Chapter two: High availability

Chassis clusters overview

Task 1: Creating clusters – initial setup

Task2: Configuring redundancy groups and redundant ethernet interfaces

Cluster checking

Detailed walkthrough - Chapter three: Firewall - Security policies

Junos Security – Security policies overview

Task 1: Configuring interfaces and security zones

Task 2: Local traffic and static routing

Task 3: Security policies

Troubleshooting

Configurations

Detailed walkthrough - Chapter four: Unified Threat Management

Unified Threat Management (UTM) overview

Task 1: Web-filtering

Task 2: Antivirus

Task 3: Content filtering

Task 4: Antispam

Detailed walkthrough Chapter five: IPSec VPNs

IPsec VPN overview

Task 1: Configuring Policy-based VPN

Task 2: Configuring Route-based VPN

Task 3: Configuring GRE-tunnel over Route-based VPN

Task 4: Configuring Dynamic VPN

Detailed walkthrough - Chapter six: NAT

Network Address Translation overview

Task 1: Source NAT

Task 2: Destination NAT

Task 3: Static NAT

Task 4: NAT Protocol Translation (IPv6/IPv4)

Detailed walkthrough - Chapter seven: Attack Prevention and Mitigation

Firewall filters overview

Task 1: Firewall Filters

SCREEN overview

Task 2: SCREEN

Intrusion Prevention System Overview

Task 3: Intrusion Prevention System

Detailed walkthrough - Chapter eight: Extended Implementation Concepts

Transparent mode overview

Task 1: Transparent Mode

Filter based forwarding overview

Task 2: Filter Based Forwarding

Detailed walkthrough - Chapter nine: AppSecure

AppSecure overview

Task 1: AppID

Task 2: AppTrack

Task 3: AppFW

Task 4: AppQoS

Task 5: SSL Proxy

Task 6: User identification

Detailed walkthrough – Super Lab 1

Structure of document

Task 1: Initial configuration part 1

Task 1 – Hostnames

Task 2 – Cluster build

Task 3 – Cluster fabric

Task 4 – Xparent cluster control plane

Task 5 – Redundant Ethernet interfaces

Task 6 – Cluster forwarding plane

Task 7 – Management interfaces

Task 8 – Management services

Task 9 – Default route

Task 2: Initial configuration part 2

Task 1 – System users

Task 2 - Syslog

Task 3 – Syslog format

Task 4 – NTP server

Task 5 – NTP boot server

Task 6 – Time zone

Task 7 – NTP authentication

Task 8 – SNMP queries

Task 9 – SNMP traps

Task 10 – SNMP traps exa-fw

Task 11 – SNMP query restrictions

Task 12 - Location

Task 13 – Control plane protection

Task 3: Interfaces, zones, local traffic and routing

Task 1,2 – Interfaces and Zones

Roffice1

Roffice2

Central cluster

Building

Xparent cluster

Task 3 – SSH in TRUST zones

Task 4 – Default route

Task 5 – Internal static routes

Task 6 – Routing instances

Task 7 – VLAN rewrite

BGP Overview

Task 8 - BGP

MPLS, MBGP and L3VPN overview

Task 9 – Selective packet mode for MPLS

Task 4: UTM

Task 1 – Antivirus

Task 2 – Web-filtering

Task 3 – Content filtering

Task 4 – Websense content filtering and Filter Based Forwarding

Task 5 - Antispam

Task 5: NAT

Task 1 – Source NAT branch1

Task 2 – Source NAT branch2

Task 3 – Source and destination NAT exa-fw

Task 4 – Source and destination NAT central cluster

Task 6: IPSec VPN

Task 1 – VPN and OSPF branch offices

IPSec tunnel build

Task 2 – VPN home office

IPSec tunnel and security policies

Traffic steering

Task 3 – VPN Hub and Spokes

IPSec tunnels

Static NAT

Internal BGP

Security policies

Task 7: Attack prevention and mitigation

Task 1 – IDS branches

Task 2 – IDS building

Task 3 – IDP

Task 8: AppSecure – Central cluster

Task 1 – Application caching

Task 2 - Apptrack

Task 3 – AppFW MSN

Task 4 – AppFW HTTP

Task 5 – AppFW logging

Task 6 - AppQoS

Task 7 – SSL decryption

Task 8 – User ID

Task 9: Extended implementation – IPv6

Task 1 – BGP and OSPFv3

Central Cluster

Roffice1

Roffice2

Exa-fw

Task 2 – Interfaces and Zones

Central Cluster

Roffice1

Roffice2

Exa-fw

Task 3 – VPN roffice1 and central cluster

Task 4 – GRE

Task 5 – VPN roffice1 and exa-fw

Detailed walkthrough – Super Lab 2

Task 1: Infrastructure

Task 1 – Cluster build

Task 2 – Redundant Ethernet interfaces

Task 3 – Reachability and management

Task 4 – SNMP

Task 5 – VLAN rewrite

Task 6 – Management services and access

Task 2: Security

Task 1 – Scheduling

Task 2 – DMZ services

Task 3 – DMZ-DC public access

Task 4 – DMZ-DC FTP firewall authentication

Task 5 – Policy reevaluation

Task 6 – Selective packet mode

Task 7 – Control plane protection

Task 3: VPN and Routing

Task 1 – VPN Hub and Spoke

Task 2 – VPN branch1

Task 3 – Dead Peer Detection

Task 4 – BGP over IPsec

Task 5 – GRE and IPv6

Task 4: Network Address Translation

Task 1 – VPN and overlapping addresses

Task 2 – NAT46

Task 3 – Source NAT to DMZ-DC

Task 4 – Source NAT central

Task 5: Content filtering

Task 1 – Anti-virus and Filter based Forwarding

Task 2 – Web filtering

Task 6: Attack prevention

Task 1 - IDS

Task 2 - IDP

Task 3 - AppQoS

Task 4 - AppTrack

Workbook updates and configuration files

iNET ZERO rack rental service

Detailed walkthrough - Chapter two: High availability

This appendix provides details about the solution for the chapter two which is focused on

system clustering.

Topology for chapter two:

Chassis clusters overviewJunos security platforms use chassis clustering for providing high-availability. A chassis cluster consists

of grouped pair of SRX series or J-series devices connected to each other with control and data links.

The control link uses fpx1 interfaces and is either on high end devices between service processing cards

(SPCs) or dedicated control board ports; or on branch device between fixed revenue ports. This connec-

tion is used to synchronize the configuration and kernel state. The data link uses only revenue ports as

fab interfaces on all models and is used to synchronize sessions for redundancy and for transmitting the

cross-node data traffic. In chassis cluster both member devices must be the same model having the same

hardware revision and cards - SPCs, network processing cards (NPCs), and input/output cards (IOCs) on

high-end platforms - placed in the same slots. In this setup the chassis cluster provides network node

redundancy with stateful failover of processes and services in the event of system or hardware failure.

The control plane operates in active-backup mode whereas the data plane can operate in active/passive

or active/active modes depending on the configuration.

The main chassis clusters components are cluster nodes, redundancy groups and redundant ethernet

interfaces. Each cluster is identified by an identifier called “cluster-id” from the range 1-15. The cluster

members are called nodes. Because each cluster can consist of maximum two devices “node-id” is used

for their designation - node 0 or node 1. Each device can belong to only one cluster at any time. When the

cluster forms the interface names on the node 1 are changed to reflect the cluster setup. Specifically the

FPC number changes according this formula on node 1: max FPC slots on given device model + standalone

FPC slot number.

A redundancy group (RG) is an abstract construct that includes and manages a collection of objects. An

RG has objects on both nodes and is primary on one node and secondary on the other at any time. The

objects are active on the node where the RG is active to which they belong. RGs are independent units

from the failover perspective, i.e. each redundancy group fails over from one node to the other inde-

pendently from all other redundancy groups. In case of failover all objects belonging to the redundancy

group failover together to the other node, i.e. become active. RG0 is reserved and created automatically

for routing engines. It manages the primacy of REs, i.e. the routing engine is active on the node where the

RG0 is active. All other RGs manage interface redundancy and need to be explicitly defined in the configu-

ration. RG except RG0 can contain up to 15 redundant Ethernet interfaces. The RG primacy is determined

by the following things – node priority, node-id and node initialization time. Node with higher priority has

the RG is primary. If both nodes have the same priority for the RG it will be primary on the node with low-

er node-id. If one node boots up and initializes before the other all RGs will be primary on that node un-

less the preempt option is used. Each RG having the preempt option enabled will be primary on the node

with higher priority whenever possible. However the preempt option is not supported on RG0. Each RG

can have defined which interfaces and/or IP addresses to monitor, i.e. checking the interface status – up

or down, and the IP address reachability. When a failure is detected – monitored interface or IP address –

a failover happens depending whether the weight of failed objects reaches the RG failover threshold of

255.

Enter this temporary vouchercode within 1 week to get

10% off your purchase! ( workbooks only ) Go to:

www.bit.ly/2cfMeXFH2993DJ

Automatically expires within one week of downloading this demo workbook

A reth is a pseudo-interface that includes a physical interface from each node of the cluster. A redundant

Ethernet interface must contain, at minimum, a pair of Fast Ethernet interfaces or a pair of Gigabit Ether-

net interfaces that are referred to as child interfaces of the redundant Ethernet interface (the redundant

parent). If more than two interfaces are assigned to the reth a link aggregation group is created automat-

ically from all children interfaces on the same node. The children interface of reth must be the same kind

(fast or gigabit or 10gigabit ethernet) but do not need to be in the same slots on the nodes. The associ-

ation to the reth interface is done in the child interface configuration. The reth configuration contains

association to the RG and properties that inherited by the child interfaces. Only child interfaces on the

node where the RGs is primary to which the reth belong are active.

The chassis cluster requires both links – control and data – to be up and operational. If one of them fails

the node with RG0 active disables the other node to prevent split brain situation. Once the connection

is recovered the disabled node needs to be rebooted to join the cluster. To minimize this situation Junos

security allows defining the redundant fabric links on all modes. The redundant control links are available

only on the high end devices but certain restriction apply, e.g. for SRX5000 series devices each node must

be equipped with 2nd RE, on SRX3000 series a SCM module is required on each device.

Few things to remember:

- Both nodes must run the same Junos software

- fxp0 and fxp1 ports are predefined and fixed on branch devices. Therefore make sure the

configuration file does not contain any configuration for these ports. Otherwise the cluster will

not form correctly.

- Preempt is not available for RG0

- Each node must have its own license for licensed features, such as UTM, IDP, AppSecure, etc.

- IPSec tunnel termination is supported on reth interfaces only.

- Etc.

Task 1: Creating clusters – initial setupNOTE: Before executing the activities in this part ensure the configuration on all cluster nodes are pre-

pared. The labs consist of SRX240 devices, which are branch devices and do not have dedicated manage-

ment interface, such as fxp0. On the SRX branch devices in cluster setup dedicated ports (not configu-

rable) become the management port (fxp0) and control link (fxp1) – specifically on SRX 240s those are

the ge-0/0/0 and ge-0/0/1 ports respectively. In order for the nodes to form the cluster successfully no

configuration must exists for these interfaces in the configuration file. This allows Junos to perform inter-

nal tasks associated with these interfaces. In order to assure this execute following commands on EACH

node of the cluster prior any cluster related tasks:

[edit]

root@srx3# delete interfaces ge-0/0/0

[edit]

root@srx3# delete interfaces ge-0/0/1

When deleting an interface configuration also all references to that interface need to be removed. From

the previous chapter the functional zone “management” is referencing the interface. If there are any oth-

er references to these interfaces remove them as well.

[edit]

root@srx3# delete security zones functional-zone management interfaces ge-0/0/0

[edit]

root@srx3# commit

Failing to perform the above procedure can result in the cluster not forming correctly, i.e. the nodes will

not be able to see each other (status “lost” or similar).

1) The table presented in the task defines following:

a. srx3 should be node 0 and srx4 should be node 1 in the cluster 1

b. srx5 should be node 0 and srx6 should be node 1 in the cluster 2

Then perform following operational mode command on each device. Starting with node 0 simplified the

situation because the node 0 will be the first one to boot and all RGs including RG0 will become primary

on this node.

NOTE: Forming the cluster requires device’s reboot. Therefore it is suitable to execute the following com-

mands and perform the initial configuration tasks using the console connection.

Cluster 1:

Node 0:

root@srx3>set chassis cluster cluster-id 1 node 0 reboot

Node 1:


Cluster 2:

Node 0:


Node 1:


Use the show chassis cluster status command to check the cluster status after the device’s reboot. You

can execute this command on either node. The node status primary and secondary indicate the nodes see

each other and the cluster formed correctly.

Cluster 1:

{primary:node0}

root@srx3>show chassis cluster status

Cluster ID: 1

Node name Priority Status Preempt Manual failover

Redundancy group: 0 , Failover count: 1

node0 1 primary no no

node1 1 secondary nono

Cluster 2:

{primary:node0}


Cluster ID: 2

Node name Priority Status Preempt Manual failover



node1 1 secondary no no

Any other nodes status means the cluster did not form correctly.

{hold:node0}


Cluster ID: 1

Node Priority Status Preempt Manual failover


node0 1 hold no no

node1 0 lost n/a n/a

In this case check:

- if both nodes run the same software version.

- root@srx3>show system software

- if the configuration file does not have any configuration present for the ge-0/0/0 and ge-0/0/1 on

both nodes. If so, delete it and commit the changes. You might need to use configure shared command to

enter the configuration mode.

- root@srx3>show configuration interfaces ge-0/0/0

- root@srx3>show configuration interfaces ge-0/0/1

- the status of the cluster control link

- root@srx3>show chassis cluster interfaces

- control and data link heartbeats and probes statistics

- root@srx3>show chassis cluster control-plane statistics

- if no information helps you to pin down the problem examine the jsprd log for errors

- root@srx3>show log jsrpd | match error | last 20

Fix the problems, reboot the nodes and check the cluster status again.

As soon as the cluster forms correctly is it sufficient to perform the configuration changes only on node

because cluster software automatically takes care of synchronizing the between nodes. Typically the con-

figuration changes are done on the primary node, i.e. on the node where the RG0 is primary.

2) As mentioned earlier the branch devices have fixed definition which ports will become fxp0 and

fxp1. This means the control link fxp1 is configured automatically on the lab devices. The fabric

link on the other hand requires manual configuration. Based on the instructions the ge-0/0/2

ports should be used for fabric link on all clusters and their members.

NOTE: Keep in mind the interface names/numbers in cluster setup. The SRX240 has places for 4 additional

PIMs, therefore the FPC number in interface names starts from value 5 on node1.

Cluster 1:

{primary:node0}[edit]

root@srx3# set interfaces fab0 fabric-options member-interfaces ge-0/0/2



Cluster 2:





Junos security devices can automatically perform the reboot of the disabled node in case of restoring the

failed control link using the control-link-recovery option under [edit chassis cluster] hierarchy. Following

statement enables this behaviour.

Cluster 1:


root@srx3#set chassis cluster control-link-recovery


root@srx3#commit and-quit

Cluster 2:


root@srx5#set chassis cluster control-link-recovery


root@srx5#commit and-quit

The changes can be verified as follows:

{primary:node0}

root@srx3>show chassis cluster interfaces

Control link status: Up

Control interfaces: Index Interface Status

0 fxp1 Up

Fabric link status: Up

Fabric interfaces: Name Child-interface Status

fab0 ge-0/0/2 Up

fab0

fab1 ge-5/0/2 Up

fab1

{primary:node0}

root@srx3>show configuration chassis cluster

control-link-recovery;

Task 2: Configuring redundancy groups and redundant ethernet interfaces1) As listed before the RG0 is reserved for routing engines (this behavior cannot be changed).

In SRX cluster every redundancy group can have priorities associated with each node. Normally

the RG is active on the node with higher priority and in case of failure the RG becomes active

on the other node. Upon failure recovery the failback is dependent whether the RG has the

“preempt” parameter defined or not. If defined the RG will be always active on the available

node with the highest priority, if not the RG will remain active on the current mode. According

to the task instructions the node 0 should be normally primary for the RG0 on both clusters.

The following steps perform that:

Cluster 1:

Configure higher priority for node0, e.g. 200, and lower priority for node1, e.g. 100, for the

redundancy group 0 which is dedicated to routing engines.


root@srx3#edit chassis cluster

{primary:node0}[edit chassis cluster]

root@srx3#set redundancy-group 0 node 0 priority 200



Review and commit the configuration. In chassis cluster the configuration can be

committed only from the top.


root@srx3#show redundancy-group 0

node 0 priority 200;



root@srx3#top


root@srx3#commit

Cluster 2:

Perform the same steps on cluster 2.


root@srx5#edit chassis cluster






root@srx5#show redundancy-group 0




root@srx5#top


root@srx5#commit

NOTE: The preempt parameter cannot be defined for RG0. However manual failover for RG0 is possible.

The “show chassis cluster status” command lists the node priorities for the existing redundancy groups in

the chassis cluster.

{primary:node0}


Cluster ID: 1

Node Priority Status Preempt Manual failover



node1 100 secondary no no

2) Based on the topology image the following reths need to be created (keep in mind the

interface renaming in cluster environment).

Cluster-id Reth Reth children

1 reth0 ge-0/0/5, ge-5/0/5

1 reth1 ge-0/0/4, ge-5/0/4

2 reth0 ge-0/0/5, ge-5/0/5

2 reth1 ge-0/0/4, ge-5/0/4

The cluster needs to be explicitly told how many reth interfaces it should create. It might be useful to do

it at the beginning of the reth configuration to prevent commit errors.

Cluster 1:


root@srx3# set chassis cluster reth-count 2

Detailed walkthrough - Chapter four: Unified Threat Management

Because the UTM policy is referenced in a security policy the UTM features are enforced only on traffic

permitted by a security policy. The actual UTM processing happens within the service processing stage.

To enforce UTM features correctly additional processing is needed. The security device intercepts all

TCP connections, because all supported UTM protocols are TCP based. In the next step TCP proxy is used

where security device acts as the server to the originating client and as the client to the desired server.

This allows the security device to request the needed data for UTM processing from either side inde-

pendently. The data is then supplied to the application proxy which decodes and extracts the application

protocol (HTTP, FTP, IMAP, POP3, SMTP) information and sends it to the appropriate UTM feature for

further processing.

Content only available in the original workbook

Task 1: Web-filteringThe instructions define that the existing policies should be reused whenever possible, e.g. associating the

newly created utm-policy with already existing security policies.

Branch office: srx1

1) The following security policy created in the previous chapter can be used to enforce the

web-filtering on the traffic from zone TRUST to UNTRUST.

Device Incoming Outgoing Source address Destination Application Action

zone zone Entry Adress entry

srx1 TRUST UNTRUST 172.16.10.0/24 any junos-http permit

junos-https

2) To define the integrated surf-control as the used option access the [edit security utm] hierarchy.

[edit]

lab@srx1# edit security utm

Execute the following command which specifies the integrated surf-control type for web-filtering.

[edit security utm]

lab@srx1# set feature-profile web-filtering type surf-control-integrated

Create the feature profile for the web-filtering. Here the used feature profile name is “BranchOf-

fice-Web”.

[edit security utm]

lab@srx1# edit feature-profile web-filtering surf-control-integrated profile BranchOffice-Web

3) Define the requested categories and their respective action.

a. Block the categories “Hacking, Violence, Gambling, Games”

[edit security utm feature-profile web-filtering surf-control-integrated profile BranchOffice-Web]

lab@srx1#set category Hacking action block


lab@srx1#set category Violence action block


lab@srx1#set category Gambling action block


lab@srx1#set category Games action block

b. Permit the categories “News, Computing_Internet”


lab@srx1#set category News action permit


lab@srx1#set category Computing_Internet action permit

c. Permit and log all other URL’s. This means to define the default action as permit and log.


lab@srx1# set default log-and-permit

Review the configuration.


lab@srx1# show

category {

Hacking {

action block;

}

Violence {

action block;

}

Gambling {

action block;

}

Games {

action block;

}

News {

action permit;

}

Computing_Internet {

action permit;

}

}

default log-and-permit;

NOTE: The custom categories and URL’s belonging to them are defined using custom objects under [edit

security utm] stanza. The evaluation for custom categories precedes the predefined (SurfControl) ones.

4) Define the custom message (“Blocked site!”) the clients will receive in case their request

is blocked.


lab@srx1# set custom-block-message “Blocked site!”



lab@srx1# show custom-block-message

custom-block-message “Blocked site!”;

5) The fallback options specify the engine behaviour when experiencing various issues when

processing requests. The given instructions require following handling:

a. For “too many requests” situation the action is drop/block


lab@srx1# set fallback-settings too-many-requests block

b. Server communication problems (response timeout reached and lost connectivity)

result in blocking the requests.


lab@srx1# set fallback-settings server-connectivity block


lab@srx1# set fallback-settings timeout block

c. For all other causes (default) the action is permit and log.


lab@srx1# set fallback-settings default log-and-permit



lab@srx1# show fallback-settings

default log-and-permit;

server-connectivity block;

timeout block;

too-many-requests block;

6) The following command defines 120 seconds as server communication timeout limit.


lab@srx1# set timeout 120

View the web-filtering status.

lab@srx1>show security utm web-filtering status

UTM web-filtering status:

Server status: SC-CPA server down

Test the web-filtering configuration. When testing define the UTM feature tested, which profile of that

feature to use and the string for testing. For example in this case:

- UTM feature: web-filtering

- Profile: BranchOffice-Web

- Test string: google.com

Currently the result shows the message the specified URL has not been found in custom categories, be-

cause the categorization is purely done by the external server and the connection to the server is down. If

the category is not found for the URL the profile default action is executed.

lab@srx1>test security utm web-filtering profile BranchOffice-Web test-string google.com

Web-filtering test results: Not found in custom category list

Verify if the security policy has enabled UTM processing.

lab@srx1>show security policies from-zone TRUST to-zone UNTRUST policy internet-access detail

Policy: internet-access, action-type: permit, State: enabled, Index: 10, Scope Policy: 0

Policy Type: Configured

Sequence number: 1

From zone: TRUST, To zone: UNTRUST

Source addresses:

trust-address-range: 172.16.10.0/24

Destination addresses:

any-ipv4: 0.0.0.0/0

any-ipv6: ::/0

Application: trust-app-set

IP protocol: tcp, ALG: 0, Inactivity timeout: 1800

Source port range: [0-0]

Destination port range: [80-80]

IP protocol: tcp, ALG: 0, Inactivity timeout: 1800

Source port range: [0-0]

Destination port range: [443-443]

Per policy TCP Options: SYN check: No, SEQ check: No

Intrusion Detection and Prevention: disabled

Unified Access Control: disabled

Unified Threat Management: 0x06000003

Central office: cluster 2

7) The WebSense type of web-filtering has to be used on this device. Use similar command as on the

srx1 device but specify “websense-redirect” instead of the integration surf-control option.

Access the [edit security utm] hierarchy.


lab@srx5#edit security utm

Define the websense-redirect type for web-filtering.

{primary:node0}[edit security utm]

lab@srx5# set feature-profile web-filtering type websense-redirect

8) The following existing security policy between TRUST and UNTRUST zones can be used because

is fulfills the requirements given in the task. However the association with the UTM policy will

be done later after creating it.

Device Incoming Outgoing Source address Destination Application Action

zone zone entry address entry

cluster2 TRUST UNTRUST 172.16.50.0/24 any junos-http permit

junos-https

9) To exclude URLs form the web-filtering checking they must be listed in the white-list. In addition,

to satisfy the given requirements in the task the use of wildcards is needed.

NOTE: Although the SRX allows using wildcards when defining URLs there are some limitations. The following

wildcard rule applies: \*\.[]\?* and you must precede all wildcard URLs with “http://”. You can only use “*” if it is

at the beginning of the URL and is followed by a “.”. You can only use “?” at the end of the URL. For example the

following wildcard syntax is supported: http://*.juniper.net, http://www.juniper.ne?, http://www.juniper.n??. And

the following wildcard syntax is NOT supported: *.juniper.net , www.juniper.ne?, http://*juniper.net, http://*.

a. The expression “http://*.bing.com” matches all sites that end with the “bing.com” string.

Create a url-pattern custom object containing the string. Here the object is named

“Allowed-sites”.

{primary:node0}[edit security utm]

lab@srx5# set custom-objects url-pattern Allowed-sites value http://*.bing.com

DEMO END 410+ pages

This workbook was developed by iNET ZERO.

All rights reserved. No part of this publication may be reproduced or distributed in any form or

by any means without the prior written permission of iNET ZERO a registered company in the

Netherlands. This product cannot be used by or transferred to any other person.

You are not allowed to rent, lease, loan or sell iNET ZERO training products including this

workbook and its configurations. You are not allowed to modify, copy, upload, email or

distribute this workbook in any way. This product may only be used and printed for your

own personal use and may not be used in any commercial way. Juniper (c), Juniper Networks

inc, JNCIE, JNCIP, JNCIS, JNCIA, Juniper Networks Certified Internet Expert, are registered

trademarks of Juniper Networks, Inc.

This original workbook helped over more than 340+ people achieve the expert certification

Unfortunately you have reached the end of this demo workbook.

Enter this temporary vouchercode within 1 week to get

10% off your purchase! ( workbooks only ) Go to:

www.bit.ly/2cfMeXF

H2993DJAutomatically expires within one week of downloading this demo workbook

Documents

JNCIE-SEC V1.3 walkthrough (2017) - iNETZERO · walkthrough (2017) Demo workbook . ... JNCIS-FWV, JNCIP-SEC, JNCIS-ENT, JNCIA-EX. About the authors About me Alexei lives in …