iNETZERO% JNCIE SEC · 2016. 10. 13. · !1!Copyright!2013!iNET!ZERO,!The!Netherlands!.!All!rights!reserved!! E 1! k:!1!!1! es! 1 0!! 10! iNET!ZERO!–!JNCIE1SEC!Walkthrough!Workbook

http://www.inetzero.com -‐ Copyright 2013 iNET ZERO, The Netherlands . All rights reserved

JNCIE-‐SEC workboo

k:

1

1 iNET ZERO – JNCIE-‐SEC Walkthrough Workbook – version 1.1

iNET ZERO – JNCIE-‐SEC

Walkthrough workbook v1.1 add-‐on For Juniper Networks, inc -‐ JNCIE-‐SEC 2013 Lab Exam



k:

2


Copyright and licensing information

This workbook, iNET ZERO's JNCIE-‐SEC Walkthrough 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.

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.

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.

ISBN/EAN

978-‐90-‐819227-‐0-‐8



k:

3


About iNET ZERO’s content developers and authors:

Jörg Buesink

Jö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 extensive experience in network implementation, design and architecture and teached several networking classes. Jörg is triple JNCIE certified (JNCIE-ENT#21, JNCIE-SP#284 and JNCIE-SEC#30) as well as triple CCIE#10532 (Routing/ Switching, Service provider and Security) and Cisco CCDE#20110002 certified.

Alexey Kolmov

Alexei lives in Moscow and speaks Russian and English. He started his carrier 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, participated 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: JNCIP-M/T, JNCIP-SEC, JNCIS-FW, JNCIS-SSL, JNCIA-EX and Acme Packet Certified Instructor



k:

4


Richard Pracko

Richard Pracko comes from the heart of the Europe, from a small but beautiful country Slovakia. Right after finishing his studies at the university with telecommunications as a major, he joined the Siemens Networking department, 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 beginning 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 English, German, Czech and Slovak. Richard holds the following certifications: JNCIS-FWV, JNCIP-SEC, JNCIS-ENT, JNCIA-EX.



k: Rack rental se

rvice

5


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.

Graded mock lab Did you know we also offer a graded mock lab to simulate a real JNCIE lab exam? Please 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 Networks 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.1 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 together 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 regarding our products is also very appreciated!



k: Tab

le of C

ontents

6


Table of Contents Target audience ........................................................................................................................................

How to use this workbook ........................................................................................................................

iNET ZERO support ....................................................................................................................................

Detailed 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 ...................................................................................................



k:

7


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 ..................................................................................................................................

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 ............................................................................................................



k:

8


Detailed walkthrough -‐ Chapter three: Firewall -‐ Security policies This appendix provides solution details for the security policies chapter. You will configure interfaces, zones and security policies on the SRX devices based on the requirements.

Topology for chapter three:



k: Detailed walkthrou

gh -‐ Ch

apter three

: Fire

wall -‐ Security

policies

9


Junos Security – Security policies overview Security policies are means that tell the Junos security platforms how to handle traffic. Security policies are unidirectional and are defined within a “from-‐zone to-‐zone” context. A security zone is a collection of one or more segments having the same security requirements. Logical units of interfaces are assigned to zones and each logical unit can be assigned to only one zone at a time. However multiple interfaces can be assigned to a single zone. In addition when using routing-‐instances on the Junos device all interfaces assigned to a zone must belong to the same routing instance, i.e. whole zone must belong to only one routing-‐instance. Zones are either system-‐defined (Null zone and junos-‐host) and user-‐defined. Null zone is a default zone and all interfaces not explicitly associated through configuration with any other zone belong to it. All traffic on interfaces from the Null zone is dropped. The junos-‐host zone is optional and used to apply and enforce security policies for the self-‐traffic, i.e. the traffic destined for the device. In earlier Junos versions the self-‐traffic was controlled only through host-‐inbound-‐traffic configuration. The user-‐defined zones can be either functional or security. Currently only one functional zone named “management” (other names are not allowed) is available. The functional zone is used for out-‐of-‐band management by accepting only traffic destined for the device itself and cannot be used in security policies. All transit traffic received on interfaces from the management zone is dropped. The main use, but not exclusive, of the management zone is on branch devices to isolate transit traffic from management because they lack the dedicated management port fxp0 available on high end platforms. The security zone is a collection of one or more network segments requiring the regulation of inbound and outbound traffic through policies. Security zones are used in the contexts for defining security policies and therefore apply to transit traffic.

Security policies tell the device how to treat the traffic traversing from one interface to the other. If both interfaces belong to the same zone the traffic is called intrazone, otherwise the traffic is called interzone. For Junos releases before 11.4 only policies defined in the from-‐zone to-‐zone context, called also regular policies, were evaluated. If no match was found the default policy, typically with action deny, was applied. Starting from the Junos release 11.4 so called global policies are available and the traffic processing has been adjusted. The policies are evaluated in following order until a match is found:

1. Regular policies – Security policies defined in the from-‐zone to-‐zone context and are evaluated only against traffic crossing the respective zones.

2. Global policies – Security policies defined under the [edit security policies global] hierarchy which are evaluated against all traffic regardless of the zones involved in case the regular policies processing did not result in a match.

3. Default policy – Security policy applied to all traffic not matching any regular or global policy. This policy does have only action because the condition is an implicit “catch-‐all” (any,any,any). The action is configured with “set security policies default-‐policy ”. The default value is “deny-‐all”.

A policy consists of a condition (or criteria) and an action. The condition includes source address, destination address and a service (combination of protocol and ports where applicable) and is matched against the traffic. If the traffic matches the condition the action – permit, deny or reject -‐ of that security policy is executed on the traffic. Also security policy logging and counting is configured under the action hierarchy. In addition advanced options can be defined for the permit action, such as firewall authentication, IPsec VPNs, IDP, AppFW, UTM, etc. Firewall authentication is




gh -‐ Ch

apter three

: Fire

wall -‐ Security

policies

10


described later in this chapter and some of other advanced features will be discussed in later chapters.

Processing self traffic:

Self traffic not destined for the incoming interface, i.e. if the packet is destined to an interface IP address on the device but is not received on that interface, must be permitted by respective security policy first.

Processing transit traffic:

Things to remember

-‐ Interface not explicitly assigned to a zone belongs to the Null zone and all traffic is being dropped.

-‐ Transit traffic on interfaces from the management zone is dropped. -‐ From Junos 11.2 address books can be defined either under security zone or under [edit

security address-‐book] hierarchy and then associated with a zone. However the only one of these approaches can be used on a Junos security device. In the latter approach the global address book objects are available in all security policies regardless of the zone context.

-‐ Security policies are evaluated sequentially in the order as they appear in the configuration. Typically reordering policies is necessary.

-‐ The action of the default security policy is deny. -‐ Whereas the default action for the self-‐traffic, e.g. for policies defined in the “from-‐zone

to-‐zone junos-‐host” context, is permit. Of course the self-‐traffic must be permitted in the host-‐inbound-‐traffic.

-‐ Watch for typos in address entries and custom applications.

Does host-‐inbound-‐

traffic allow the traffic?

Does the traffic match any of security polices in the “from-‐zone to-‐zone

junos-‐host” context?

Drop Permit

Execute the action from the matched policy

Does the packet match any of the regular polices?

Execute the action from matched regular policy

security

Execute the action from the default policy

Does the packet match any of the global polices?

Execute the action from the matched global policy

securitytion.




gh -‐ Ch

apter three

: Fire

wall -‐ Security

policies

11


Task 1: Configuring interfaces and security zones In this part you will configure interfaces, zones and assign interfaces to zones.

1) Interface configuration is pretty straightforward and no different than on any other Junos device. Below are examples for configuring interfaces on the srx7 device and an IPv4 interface using vlan-‐tagging on redundant ethernet interface on cluster 2. The IP addresses and network masks are taken from the table presented in the task. Access the [edit interfaces] hierarchy.

[edit] lab@srx7# edit interfaces

Create logical units 0 on interfaces ge-‐0/0/1 and ge-‐0/0/2 on srx7. Define IPv4 address for those logical units. IPv4 details are configured under family inet hierarchy.

[edit interfaces] lab@srx7# set ge-0/0/1 unit 0 family inet address 172.16.199.254/24 [edit interfaces] lab@srx7# set ge-0/0/2 unit 0 family inet address 172.16.21.254/24

The interface ge-‐0/0/4 must have enabled vlan0-‐tagging for the firewall to understand and be able to process VLAN tagged frames.

[edit interfaces] lab@srx7# set ge-0/0/4 vlan-tagging

Create logical unit for the VLAN with id 60 and configure appropriate IP address on it. Junos allows you to define arbitrary logical unit number, however it is recommended for sake of troubleshooting simplicity to use the same unit number as the vlan-‐id.

[edit interfaces] lab@srx7# set ge-0/0/4 unit 60 vlan-id 60 [edit interfaces] lab@srx7# set ge-0/0/4 unit 60 family inet address 172.16.60.254/24

Review the configuration.

[edit interfaces] lab@srx7# show | find ge-0/0/1 ge-0/0/1 { unit 0 { family inet { address 172.16.199.254/24; } } } ge-0/0/2 { unit 0 { family inet { address 172.16.21.254/24;




gh -‐ Ch

apter three

: Fire

wall -‐ Security

policies

12


} } } ge-0/0/4 { vlan-tagging; unit 60 { vlan-id 60; family inet { address 172.16.60.254/24; } } }

For multiple VLANs on an interface multiple logical units, one for each VLAN, have to be created in addition to configuring the vlan-‐tagging parameter. Below is a reth interface configuration example (taken from the previous chapter):

{primary:node0}[edit interfaces] root@srx3# set reth1 vlan-tagging

{primary:node0}[edit interfaces] root@srx3# set reth1 unit 100 vlan-id 100

{primary:node0}[edit interfaces] root@srx3# set reth1 unit 100 family inet address 172.16.100.1/24





Review the configuration. {primary:node0}[edit interfaces] root@srx3# show reth1 vlan-tagging; unit 100 { vlan-id 100; family inet { address 172.16.100.1/24; } } unit 150 { vlan-id 150; family inet { address 172.16.150.1/24; } }




gh -‐ Ch

apter three

: Fire

wall -‐ Security

policies

13


unit 200 { vlan-id 200; family inet { address 172.16.200.1/24; } }

To create a zone and associate interfaces with it access the [edit security zones] hierarchy.

[edit interfaces] lab@srx7# top edit security zones

The security zone creation and interface association steps can be combined in to one, because Junos automatically creates the zone when associating an interface with yet not existing zone. Below is an example from the srx7 device.

NOTE: Keep in mind the zone names are case sensitive. Very common mistake is to make typos in zone names which results in Junos automatically creating them. Also make sure you associate the interface with the correct zone.

NOTE: Do not forget to specify the logical unit number when associating interfaces to security zones. When the logical unit number is omitted Junos automatically uses unit 0.

[edit security zones] lab@srx7# set security-zone FINANCE interfaces ge-0/0/1.0 [edit security zones] lab@srx7# set security-zone PRIVATE interfaces ge-0/0/2.0 [edit security zones] lab@srx7# set security-zone INTERNAL interfaces ge-0/0/4.60

Review the configuration. [edit security zones] lab@srx7# show | find security-zone security-zone FINANCE { interfaces { ge-0/0/1.0; } } security-zone PRIVATE { interfaces { ge-0/0/2.0; } } security-zone INTERNAL { interfaces { ge-0/0/4.60; } }

Commit the configuration.

[edit security zones]




gh -‐ Ch

apter three

: Fire

wall -‐ Security

policies

14


lab@srx7# commit and-quit

To check the interface status and the IP address use following command, e.g. for ge-‐0/0/4.60

lab@srx7> show interfaces terse ge-0/0/4.60 Interface Admin Link Proto Local Remote ge-0/0/4.60 up up inet 172.16.60.254/24

The following command displays also the VLAN tag value.

lab@srx7> show interfaces ge-0/0/4.60 Logical interface ge-0/0/4.60 (Index 73) (SNMP ifIndex 548) Flags: SNMP-Traps 0x0 VLAN-Tag [ 0x8100.60 ] Encapsulation: ENET2 Input packets : 0 Output packets: 1 Security: Zone: INTERNAL Protocol inet, MTU: 1500 Flags: Sendbcast-pkt-to-re Addresses, Flags: Is-Preferred Is-Primary Destination: 172.16.60/24, Local: 172.16.60.254, Broadcast: 172.16.60.255

The command below shows the existing security zones and their interfaces.

lab@srx7> show security zones Security zone: FINANCE Send reset for non-SYN session TCP packets: Off Policy configurable: Yes Interfaces bound: 1 Interfaces: ge-0/0/1.0 Security zone: INTERNAL Send reset for non-SYN session TCP packets: Off Policy configurable: Yes Interfaces bound: 1 Interfaces: ge-0/0/4.60 Security zone: PRIVATE Send reset for non-SYN session TCP packets: Off Policy configurable: Yes Interfaces bound: 1 Interfaces: ge-0/0/2.0 Security zone: junos-host Send reset for non-SYN session TCP packets: Off Policy configurable: Yes Interfaces bound: 0 Interfaces:

Viewing the zone association of a particular interface, e.g. for the interface ge-‐0/0/4.60.




gh -‐ Ch

apter three

: Fire

wall -‐ Security

policies

15


lab@srx7> show interfaces ge-0/0/4.60 extensive| match "Security: Zone" Security: Zone: INTERNAL

Additional verification step for interface configuration is the neighbor reachability. The simplest method is to execute ping to the neighbor IP address. However at this moment neither the security policies exist nor the host-‐inbound-‐traffic is configured to permit the pings.

Using the approach described above configure all interfaces, zones and their associations according the table below.

NOTE: The “copy and paste” approach might be helpful for saving time.

Device Interface IP address VLAN-‐ID Zone srx1 ge-‐0/0/1.0 172.16.10.254/24 None TRUST srx1 ge-‐0/0/2.0 172.16.11.254/24 None DMZ srx1 ge-‐0/0/3.0 80.10.8.1/24 None UNTRUST srx2 ge-‐0/0/2.0 172.16.20.254/24 None TRUST srx2 ge-‐0/0/3.0 80.10.10.1/24 None UNTRUST srx2 ge-‐0/0/4.0 172.16.21.254/24 None PRIVATE Cluster1 (srx3, srx4) reth0 80.10.99.100/24 None UNTRUST Cluster1 (srx3, srx4) reth1.100 172.16.100.1/24 100 TRUST Cluster1 (srx3, srx4) reth1.150 172.16.150.1/24 150 DMZ Cluster1 (srx3, srx4) reth1.200 172.16.200.1/24 200 WAREHOUSE Cluster2 (srx5, srx6) reth0 80.10.1.1/24 None UNTRUST Cluster2 (srx5, srx6) reth1.50 172.16.50.10/24 50 TRUST Cluster2 (srx5, srx6) reth1.55 172.16.55.10/24 55 DMZ Cluster2 (srx5, srx6) reth1.60 172.16.60.10/24 60 INTERNAL srx7 ge-‐0/0/1.0 172.16.199.254/24 None FINANCE srx7 ge-‐0/0/2.0 172.16.21.254/24 None PRIVATE srx7 ge-‐0/0/4.0 172.16.60.1/24 60 INTERNAL srx8 ge-‐0/0/1.0 192.168.10.254/24 None TRUST srx8 ge-‐0/0/3.0 80.10.199.1/24 None UNTRUST




gh -‐ Ch

apter three

: Fire

wall -‐ Security

policies

16


Task 2: Local traffic and static routing The host-‐inbound-‐traffic configuration in the security or functional zone is used to control the local traffic, called also “self-‐traffic”. In chapter one the host-‐inbound-‐traffic configuration was done for the management access, i.e. for the functional zone called management. Here the same approach is used for allowing self-‐traffic on the interfaces associated with security zones. As mentioned in the brief security policy overview at the beginning of this chapter the junos-‐host zone provides enhanced means of controlling the self traffic. However to satisfy the presented tasks the host-‐inbound-‐traffic alone is fully sufficient.

The static routing configuration is located under the [edit routing-‐options static] hierarchy. Because the Junos security devices inherited lot of functionality from Junos routing devices the static routing configuration offers many options, such as bfd, use of rib-‐groups, etc. However for the purpose of the given tasks simple static routes with next-‐hops are enough.

1) Because all interfaces should have ping allowed the best way (easy and fast) is to allow ping in each security zone in the host-‐inbound-‐traffic statement on each device. The interfaces associated with these zones will then inherit this setting. The configuration below is for the security zones on srx7 device. Other devices will have same configuration just with their zones. Access the zones hierarchy.

[edit] lab@srx7# edit security zones

Permit the ping for all security zones.

[edit security zones] lab@srx7# set security-zone FINANCE host-inbound-traffic system-services ping [edit security zones] lab@srx7# set security-zone INTERNAL host-inbound-traffic system-services ping [edit security zones] lab@srx7# set security-zone PRIVATE host-inbound-traffic system-services ping

Do not forget to define it also for the functional zone “management” so the ping will be allowed also for the ge-‐0/0/0 interfaces.

[edit security zones] lab@srx7# set functional-zone management host-inbound-traffic system-services ping


[edit security zones] lab@srx7# show functional-zone management { interfaces {




gh -‐ Ch

apter three

: Fire

wall -‐ Security

policies

17


ge-0/0/0.0; } host-inbound-traffic { system-services { ping; ssh; telnet; http; https; } } } security-zone FINANCE { host-inbound-traffic { system-services { ping; } } interfaces { ge-0/0/1.0; } } security-zone PRIVATE { host-inbound-traffic { system-services { ping; } } interfaces { ge-0/0/2.0; } } security-zone INTERNAL { host-inbound-traffic { system-services { ping; } } interfaces { ge-0/0/4.60; } }


[edit security zones] lab@srx7# commit and-quit

The extensive information about an interface lists the allowed services on that interface. In addition the same output contains the interface to zone association information.




gh -‐ Ch

apter three

: Fire

wall -‐ Security

policies

18


lab@srx7> show interfaces ge-0/0/4.60 extensive | find "Security: Zone" Security: Zone: INTERNAL Allowed host-inbound traffic : ping ... lab@srx7> show interfaces ge-0/0/1.0 extensive | find "Security: Zone" Security: Zone: FINANCE Allowed host-inbound traffic : ping ...

2) All interfaces connected to the CORE network are assigned to the UNTRUST zone as shown

on the topology image. Therefore allowing the OSPF communication on these interfaces can be done by allowing the OSPF protocol in the UNTRUST zone. The exception is SRX7 which is connected to the cluster 2 and not to the CORE and on this device the OSPF communication is not needed at this time. Allow the OSPF protocol in the host-‐inbound-‐traffic configuration on all devices except srx7. The following example is from srx1 device.

[edit security zones] lab@srx1# set security-zone UNTRUST host-inbound-traffic protocols ospf

Review the configuration. [edit security zones] lab@srx1# show security-zone UNTRUST host-inbound-traffic { system-services { ping; } protocols { ospf; } } interfaces { ge-0/0/3.0; }



As mentioned earlier the interface extensive output lists the allowed services and the zone association. Because these details are located right after one another it is advisable to review to them together.

lab@srx1> show interfaces ge-0/0/3.0 extensive | find "Security: Zone" Security: Zone: UNTRUST Allowed host-inbound traffic : ospf ping ...




gh -‐ Ch

apter three

: Fire

wall -‐ Security

policies

19


3) Similarly as in the previous step allowing ssh on all interfaces belonging to the zone TRUST can be achieved by allowing the ssh in TRUST zone host-‐inbound-‐traffic. This needs to be done on each device except srx7 which does not have the zone TRUST. The following example is from srx1 device.

[edit security zones] lab@srx1# set security-zone TRUST host-inbound-traffic system-services ssh

Review the configuration. [edit security zones] lab@srx1# show security-zone TRUST host-inbound-traffic { system-services { ssh; } } interfaces { ge-0/0/1.0; }



Again, the extensive information output about an interface contains the allowed services.

lab@srx1> show interfaces ge-0/0/1.0 extensive | find "Security: Zone" Security: Zone: TRUST Allowed host-inbound traffic : ssh ...

4) The management interface configuration was part of chapter 1. Since the ntp and snmp services were added later on, the host-‐inbound-‐traffic needs to be adjusted as well to include them as well. Allow the snmp and ntp in the management zone’s host-‐inbound-‐traffic.

[edit security zones] lab@srx1# set functional-zone management host-inbound-traffic system-services snmp [edit security zones] lab@srx1# set functional-zone management host-inbound-traffic system-services ntp Review the configuration. [edit security zones] lab@srx1# show functional-zone management interfaces {




gh -‐ Ch

apter three

: Fire

wall -‐ Security

policies

20


ge-0/0/0.0; } host-inbound-traffic { system-services { ping; telnet; ssh; http; https; snmp; ntp; } }



Verify the changes.

lab@srx1> show interfaces ge-0/0/0.0 extensive | find "Security: Zone" Security: Zone: Management Allowed host-inbound traffic : http https ping snmp ssh telnet ntp ...

Also the snmp needs to be added to the srx8 host-‐inbound traffic configuration for the UNTRUST zone to allow connections from the 2.2.2.0/28 networks because they arrive in this zone.

[edit security zones] lab@srx8# set security-zone UNTRUST host-inbound-traffic system-services snmp Review the configuration. [edit security zones] lab@srx8# show security-zone UNTRUST address-book { address corp-network 172.16.0.0/16; } host-inbound-traffic { system-services { ping; snmp; } protocols { ospf; } } interfaces { ge-0/0/3.0; }




gh -‐ Ch

apter three

: Fire

wall -‐ Security

policies

21




Verify the changes.

lab@srx8> show interfaces ge-0/0/3.0 extensive | find "Security: Zone" Security: Zone: UNTRUST Allowed host-inbound traffic : ospf ping snmp ...

5) The static default route has 0.0.0.0/0 as the destination network and the next hop IP address is different for every device. It depends on the interface facing the CORE network. To configure default static route on each device execute following command on each device with correct next hop value. The example below is from the srx1 device.

[edit] lab@srx1# set routing-options static route 0.0.0.0/0 next-hop 80.10.8.254


[edit] lab@srx1# show routing-options static { route 0.0.0.0/0 next-hop 80.10.8.254; }


[edit] lab@srx1# commit and-quit

The “show route” operational mode command displays the current routing information on the device. If you desire routing information only about specific address or addresses just use the address or addresses together with the word “exact” as the command parameters. Check in the command output if the next-‐hop value and the outgoing interface are correct.




gh -‐ Ch

apter three

: Fire

wall -‐ Security

policies

22


lab@srx1> show route inet.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[Static/5] 00:02:39 > to 80.10.8.254 via ge-0/0/3.0 10.10.1.0/24 *[Direct/0] 20:46:53 > via ge-0/0/0.0 10.10.1.1/32 *[Local/0] 20:47:05 Local via ge-0/0/0.0 10.10.10.0/24 *[Static/5] 20:46:53 > to 10.10.1.254 via ge-0/0/0.0 80.10.8.0/24 *[Direct/0] 00:32:56 > via ge-0/0/3.0 80.10.8.1/32 *[Local/0] 00:32:56 Local via ge-0/0/3.0 172.16.10.0/24 *[Direct/0] 00:32:56 > via ge-0/0/1.0 172.16.10.254/32 *[Local/0] 00:32:56 Local via ge-0/0/1.0 172.16.11.0/24 *[Direct/0] 00:32:56 > via ge-0/0/2.0 172.16.11.254/32 *[Local/0] 00:32:56 lab@srx1> show route 0/0 exact inet.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[Static/5] 00:02:45 > to 80.10.8.254 via ge-0/0/3.0

Verifying reachability through the CORE network can be done at this moment because the routing should be present and the ping is defined in the host-‐inbound-‐traffic configuration for the UNTRUST zone. Below are few examples. Test the reachability from the srx1 to the srx2 ge-‐0/0/3.0 interface.

lab@srx1> ping 80.10.10.1 count 3 PING 80.10.10.254 (80.10.10.1): 56 data bytes 64 bytes from 80.10.10.1: icmp_seq=0 ttl=64 time=1.271 ms 64 bytes from 80.10.10.1: icmp_seq=1 ttl=64 time=1.595 ms 64 bytes from 80.10.10.1: icmp_seq=2 ttl=64 time=1.652 ms --- 80.10.10.1 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.271/1.506/1.652/0.168 ms

Test the reachability from the srx1 to the srx8 ge-‐0/0/3.0 interface.




gh -‐ Ch

apter three

: Fire

wall -‐ Security

policies

23


lab@srx1> ping 80.10.199.1 count 3 PING 80.10.199.1 (80.10.199.1): 56 data bytes 64 bytes from 80.10.199.1: icmp_seq=0 ttl=63 time=8.956 ms 64 bytes from 80.10.199.1: icmp_seq=1 ttl=63 time=1.640 ms 64 bytes from 80.10.199.1: icmp_seq=2 ttl=63 time=3.894 ms --- 80.10.199.1 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.640/4.830/8.956/3.059 ms

In the given topology the srx7 device is specific because it is not directly connected to the CORE network. The traffic has to go through the cluster 2. Therefore the default route on the srx7 has as the next-‐hop the IP address of the reth1.60 interface on cluster 2.

[edit] lab@srx7# set routing-options static route 0.0.0.0/0 next-hop 172.16.60.10

Review the configuration

[edit] lab@srx7# show routing-options static { route 0.0.0.0/0 next-hop 172.16.60.10; }



Verify the changes. lab@srx7> show route 0/0 exact inet.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 0.0.0.0/0 *[Static/5] 00:06:04 > to 172.16.60.10 via ge-0/0/4.60

6) To provide connectivity for the FINANCE zone in the Finance department through the cluster

2 the static route needs to be created on cluster 2 for the network in the FINANCE zone on srx7 using the ge-‐0/0/4.0 interface IP address from the srx7 as the next-‐hop.

{primary:node0} [edit] lab@srx5# set routing-options static route 172.16.199.0/24 next-hop 172.16.60.1


{primary:node0}[edit] lab@srx5# show routing-options static {




gh -‐ Ch

apter three

: Fire

wall -‐ Security

policies

24


route 0.0.0.0/0 next-hop 80.10.1.254; route 172.16.199.0/24 next-hop 172.16.60.1; }


{primary:node0}[edit] lab@srx5# commit

Verify the changes.

{primary:node0} lab@srx5> show route 172.16.199.0/24 exact inet.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 172.16.199.0/24 *[Static/5] 00:00:34 > to 172.16.60.1 via reth1.60

7) The following static route provides connectivity to the management network 10/8 using the given next-‐hop 10.10.1.254. This static route is the same on all devices. The “copy and paste” approach can speed up the configuration process. The example is from srx1 device. Alternatively you can specify the “no-‐readvertise” parameter to prevent the management route to be distributes to other routers through dynamic routing protocols. This is also recommended approach for production networks. You can omit it in this case because it is not explicitly requested by the task.

[edit] lab@srx1# set routing-options static route 10/8 next-hop 10.10.1.254 Review the configuration.

[edit] lab@srx1# show routing-options static { route 10.0.0.0/8 next-hop 10.10.1.254; route 0.0.0.0/0 next-hop 80.10.8.254; }

The configuration with the “no-‐readvertise” parameter looks as follows.

[edit] lab@srx1# show routing-options static { route 10.0.0.0/8 { next-hop 10.10.1.254; no-readvertise; } route 0.0.0.0/0 next-hop 80.10.8.254; }





gh -‐ Ch

apter three

: Fire

wall -‐ Security

policies

25



Verify the changes.

lab@srx1> show route 10/8 exact inet.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 10.10.10.0/24 *[Static/5] 22:19:34 > to 10.10.1.254 via ge-0/0/0.0




gh -‐ Ch

apter three

: Fire

wall -‐ Security

policies

26


Task 3: Security policies The table below lists the values referenced in the tasks.

Name Network range Private corporate network 172.16/16 Internet 0.0.0.0/0

The resulting security policies that need to be created are presented tabular form, containing the device, zone context (incoming zone, outgoing zone), address books values, applications and actions. In addition for some security policies a brief description/explanation is provided.

Few actual configuration steps (creating address entries, address-‐sets, applications, application-‐sets, security polices and additional needed configuration) are provided. At the end this chapter the security policies configuration excerpts for every device are shown.

NOTE: The names for the address entries in the actual configurations can be arbitrary, but it is recommended to keep them meaningful.

NOTE: Every time a new regular security policy is created in a given context of incoming zone to outgoing zone it is always placed at the end in that context and many times reordering is needed. The same applies for global policies. Each time a new global policy is created it is placed at the end for the global policies list. The command “insert” is used for policy reordering.

Branch office 1: srx 1

1) The hosts from the TRUST zone and its network range can go to the outside network (internet) with http and https. To avoid creation of multiple policies an application-‐set can be used to group junos-‐http and junos-‐https applications.

Device Incoming zone

Outgoing zone

Source address entry

Destination address entry

Application Action

srx1 TRUST UNTRUST 172.16.10.0/24 Any junos-‐http junos-‐https

permit

Access the [edit security] hierarchy.

[edit] lab@srx1# edit security

Create the custom application set either by using the “top” command in combination with the “set” command or by accessing the [edit applications] hierarchy. The example below uses the first approach and uses the “trust-‐app-‐set” name for the custom application set.

[edit security] lab@srx1# top set applications application-set trust-app-set application junos-http




gh -‐ Ch

apter three

: Fire

wall -‐ Security

policies

27


[edit security] lab@srx1# top set applications application-set trust-app-set application junos-https


[edit security] lab@srx1# top show applications application-set trust-app-set { application junos-http; application junos-https; }

DEMO END check www.inetzero.com for more info

iNET ZERO - your JNCIE training partner

Documents

iNETZERO% JNCIE SEC · 2016. 10. 13. · !1!Copyright!2013!iNET!ZERO,!The!Netherlands!.!All!rights!reserved!! E 1! k:!1!!1! es! 1 0!! 10! iNET!ZERO!–!JNCIE1SEC!Walkthrough!Workbook