JNCIS SEC PPT - Security Policies - Coruse 10.a

Junos for Security Platforms
Chapter 4: Security Policies
© 2010 Juniper Networks, Inc. All rights reserved. | www.juniper.net | Worldwide Education Services
Chapter Objectives
 After successfully completing this chapter, you will be

able to:
•Explain security policy functionality
•Describe the components of a security policy
•Verify policies and monitor their execution
•Configure a basic security policy using the following
elements:
• Policy match conditions
• Policy actions—basic and advanced
• Policy scheduling
© 2010 Juniper Networks, Inc. All rights reserved. Worldwide Education Services www.juniper.net | 4-2
Agenda: Security Policies
Security Policy Overview

 Policy Components
 Verifying Policy Operation
 Policy Scheduling and Rematching
 Policy Case Study
Security Policy Defined
 What is a security policy?

•A set of rules that tells a Junos security device what to do
with transit traffic between zones and within a zone
What should I do
if a packet comes
in matching
Criterion A?
Internet
Review: Packet Flow
Focus of this chapter
Forwarding
Flow Module
Session-based SCREEN
D-NAT Route Zones Policy S-NAT Services Session
Options ALG
No First Path
Match Yes SCREEN Services

Session TCP NAT
? Options ALG
Fast Path
Packet-based Per Packet Filters

Per Packet Policer Per Packet Shaper
Ingress Egress
Packet Packet
Transit Traffic Examination
 The Junos OS for security platforms always examines

transit traffic by using security policies
Does a security No Apply default

Packet in policy match the policy
traffic?
Yes
Apply policy
actions
Local Inbound Traffic Examination
 host-inbound-traffic follows this process:
Is the packet Yes
Packet in destined to the incoming
interface?
No
Does a security No Apply default

host-inbound-traffic
policy match the policy
traffic?
Yes
Apply policies
actions Is system
Does the Yes service or protocol No
policy permit the Deny traffic
allowed into the interface of
traffic? the device?
No
Yes
Drop traffic
Permit traffic
Default Security Policies
 System-default security System-default security

policies behavior
policy: deny all traffic

through the device Deny ALL transit
traffic
•You can change the
default policy to permit all
traffic Factory-default security
policies behavior
 Factory-default template
2
security policies (branch Trust zone Untrust
zone
devices only): 1
•Trust to trust: permit all 3
•Trust to untrust: permit all

•Untrust to trust: deny all
Security Policy Conceptual Example
Security Policy:
from private zone to external zone
Private If Source IP address = Host B
Internet
D External
Zone Destination IP address = Host D
2
Application = SSH
2 Zone
then permit traffic
A
B 3
Public
4 Session Table Zone
Source Source Destination Destination Prot Int C
Address Port Address Port
B 29200 D 22 6 ge-0/0/0
.
B
 Steps: D 22 B 29200 6 ge-1/0/0
1. Host B initiates SSH to Host D—Flow B  D

2. Security policy permits that flow
3. The flow triggers reverse flow creation; both flows result in a
formed session
4. The return traffic, Host D  Host B receives permission also
Policy Ordering
 Ordering:
•Order is important!
•By default, new policies go to the end of the list
•Can change the order using the insert command
•Remember the system default policy!
insert security policies from-zone name to-zone name policy name

[before | after] policy name
Editing Security Configurations
 Like any other Junos configuration stanza, you can

perform the following actions on the security
configuration components:
•Delete
•Deactivate
•Activate
•Insert
•Annotate
•Copy
•Rename
•Search and replace
 Security Policy Overview

Policy Components
Policy Language
 You create policies under a context

•from-zone zone-name to-zone zone-name
•Set under the [edit security policies] hierarchy
 Each policy:
•Identified by user-defined name
•Composed of a match statement and a then statement
• Match criteria must include source address, destination address,
and application
• Action can be permit, deny, reject, log, or count (or combination)
•Optionally contains other advanced policy actions
• IDP, UTM (branch devices only), firewall authentication
Policy Match Criteria
 Policy matching criteria:

•Source addresses
• Individual address Configured within a
zone’s address book
• Address set
•Destination addresses
• Individual address Configured within a
• Address set zone’s address book
•Applications or application sets

• User defined
• System defined
Creating Address Book Entries
 Commands for address book entries:

•Adding an address •Creating a group of
to an address book: addresses, named
address sets:
[edit security zones] [edit security zones]

security-zone name { security-zone name {
address-book { address-book {
address name1 X.X.X.X / mask; address-set name {
address name2 X.X.X.X / mask; address name1;
… address name2;
} …
} }
}
}
Defining Custom Applications
 Specifics of implementation:
•Many built-in applications (junos-rsh, junos-sip,
junos-bgp, junos-tacacs, and so forth)
•You can add applications, application sets, or both to the
predefined list
• No restrictions for the naming convention
• You can modify protocols, ports, inactivity timers, and so forth
[edit applications] [edit applications]

application name { application-set name {
application-protocol alg-protocol; application name1;
protocol protocol; application name2;
source-port source-port; …
destination-port destination-port; }
}
…
Creating Policy Match Entries
 Specifics: [edit security policies]

from-zone zone-name to-zone zone-name {
•Group all policies policy name1 {
match {
together in the source-address address-name1;
proper order, destination-address address-name1;
application application-name1;
ensuring proper }
…
order of execution }
policy name2 {
•Apply defined match {
source-address address-name2;
matching destination-address address-name2;
parameters }
application application-name2;
…
}
…
}
Basic Policy Actions
 Policy actions:
• permit: allows traffic flow
• deny: silently drops traffic
• reject: drops traffic and sends an ICMP unreachable
message for UDP traffic and a TCP (RST) message for TCP
traffic
 Optionally log and count traffic
•Logs sent to external syslog server
• Can be stored locally on branch devices
•Counters viewable with the show security policies
detail command
Advanced Permit Settings
 If the security policy allows traffic to pass, you can

also configure the following actions:
•Firewall authentication: authenticate the client prior to
forwarding the traffic
• Pass-through
• Web authentication
•IPsec VPN: perform encryption and decryption of permitted
transit traffic
•IDP: perform IDP policy evaluation
•UTM: perform UTM services such as antivirus, Web filtering,
and content filtering
• UTM services only available for branch platforms
Policy Components Summary
[edit security policies] from-zone and
from-zone zone-name to-zone zone-name { to-zone context
policy name1 {
match {
source-address address-name;
destination-address address-name; Matching criteria
application application-name;
}
then {
<action>;
} Action
}
policy name2 {
match {
source-address address-name;
destination-address address-name;
application application-name; Matching criteria
}
then {
<action>; Action
}
}
…
}
Verifying Policy Operation
Logging (1 of 3)
 Control plane logging can be stored locally or sent to

an external syslog device
•Default control plane logging configuration:
[edit system]
user@host# show syslog
user * {
any emergency;
}
file messages {
any critical;
authorization info;
}
file interactive-commands {
interactive-commands error;
}
Logging (2 of 3)
 SRX Series branch devices can log data plane logs

locally or send them to an external server
[edit system syslog]
user@host# show
host 10.210.14.130 {
user info; Default facility and severity
for data plane logs
source-address 10.210.14.133;
}
file messages {
any any;
authorization info;
}
file default-log-messages { Use this filename for NSM
any any;
structured-data; Structured data format
}
Logging (3 of 3)
 For high-end SRX Series devices, data plane logging

can go to an external logging device
•Sample configuration:
[edit security log]
user@host# show
format sd-syslog;
source-address address;
stream name {
severity debug;
host {
address;
}
}
•Sample log:
Jun 17 09:41:10 10.210.14.133 [RT_FLOW_SESSION_CLOSE][junos@2636.1.1.1.2.36:
session closed TCP FIN: 172.20.102.10/56879->172.20.202.10/23,6: test2,
55(3040) 40(2554) 9
Monitoring Policies (1 of 3)
 Use log action in security policy

[edit security policies from-zone trust to-zone untrust]
user@host# set policy 812 then log ?
Possible completions:
+ apply-groups Groups from which to inherit configuration data
+ apply-groups-except Don't inherit configuration data from these groups
session-close Log at session close time
session-init Log at session init time
 Use count action in security policy

•show outputs add counter
• Statistics go to logs by default
 show commands:
•Use the show security policies command to view
details about policies:
user@host> show security policies ?
Possible completions:
<[Enter]> Execute this command
detail Show the detailed information
from-zone Show the policy information matching the given source zone
policy-name Show the policy information matching the given policy name
to-zone Show the policy information matching the given destination zone
| Pipe through a command
• Use the detail option to display statistics

• Policy must have a counter configured
• show security flow session
• Displays flows and associated policy names and index numbers
 Use traceoptions for detailed troubleshooting:

[edit security]
user@host# show
policies {
traceoptions {
file name;
flag all;
}
flow {
traceoptions {
file name;
flag basic-datapath;
flag session;
packet-filter name {
source-prefix address-prefix;
destination-prefix address-prefix;
}
}
}

Policy Scheduling and Rematching
Policy Scheduling Overview
 A scheduled policy is a policy that uses a configured

scheduler to make the policy active at specific times
 Policy and scheduler relationship:
•A policy can refer to only one scheduler
•Multiple policies can refer to the same scheduler
•Policy remains active without an applied scheduler
Policy activated Policy deactivated
Policy Scheduler Components
 You can configure a policy scheduler with the

following:
•Slot schedule:
• Start date and time
• Stop date and time
•Daily schedule:
• Start time
• Stop time
• All day
• Exclude option
Policy Scheduler Details
 Scheduler:
•Set up the schedule for policy execution, including time and
date:
set schedulers scheduler name [day-of-the-week | daily] [specifics of time]
[edit security policies]

•Apply the scheduler from-zone name to-zone name {
policy name {
•Default behavior: match {
…
• Policies that do not …
have schedulers are }
always active and in then {
…
force }
scheduler-name name;
Apply the }
scheduler }
policy-rematch Statement
 policy-rematch statement: signals the application

of policy configuration changes to existing sessions
set security policies policy-rematch
•Default behavior: Action on Policy Description

Rematch Flag
Enable Disable (default)
• Deletion of policies Delete Deletes policy Drops all existing Drops all existing
cause drops of sessions sessions
impacted Modify action Modifies action field

of policy from
Drops all existing
sessions
All existing sessions
continue
sessions permit to deny or
reject, or vice
• Configuration versa
Modify address Modifies source or Re-evaluates policy All existing sessions
changes to existing destination address lookup continue
policies do not
Modify application Modifies application Re-evaluates policy All existing sessions
impact sessions in lookup continue
progress

Policy Case Study
Case Study: Creating Policies Between HR
and Public Zones
Objectives:
10.1.10.0/24 HR -Allow PC A and PC B to FTP to server C using a
.1 .254 custom application set
Zone
A -Deny other users in the HR zone from using FTP
services in the 1.1.70/24 network; log and count
these violations
10.1.10.5 10.1.1.0/24
ge-0/0/1
ge-0/0/2
10.1.20.0/24
10.1.2.0/24 ge-0/0/3
1.1.7.0/24
B 1.1.70.0/24
.1 .254
.254 .1
10.1.20.5 C
Public
ge-0/0/1 – 10.1.1.1 B
ge-0/0/2 – 10.1.2.1
Zone 1.1.70.250
ge-0/0/3 – 1.1.7.1
Case Study:
Entering Host Addresses into the HR Zone
[edit security]
user@host# show zones security-zone HR
address-book {
address PC_A 10.1.10.5/32;
address PC_B 10.1.20.5/32;
address all-10-1 10.1.0.0/16;
address-set HR_PCs {
address PC_A; 10.1.10.0/24
.1 .254 HR
address PC_B; A Zone
10.1.10. 10.1.1.0/24
} 5
ge-0/0/1
} ge-0/0/2
10.1.20.0/24
interfaces { 10.1.2.0/24 ge-0/0/3
1.1.7.0/24 1.1.70.0/24
B
ge-0/0/1.0; .1 .254
10.1.20.5 .254 .1
C
ge-0/0/2.0; Public
ge-0/0/1 – 10.1.1.1
ge-0/0/2 – 10.1.2.1 Zone 1.1.70.250
} ge-0/0/3 – 1.1.7.1
Case Study: Entering Host Addresses into
the Public Zone
[edit security]
user@host# show zones security-zone Public
address-book {
address Server_C 1.1.70.250/32;
address all-1-1-70 1.1.70/24;
address-set address-Public {
address Server_C;
} 10.1.10.0/24
.1 .254 HR
} A Zone
10.1.10. 10.1.1.0/24
interfaces { 5
ge-0/0/1
ge-0/0/3.0; ge-0/0/2
10.1.20.0/24
} 10.1.2.0/24 ge-0/0/3
1.1.7.0/24 1.1.70.0/24
B
.1 .254
10.1.20.5 .254 .1
C
Public
ge-0/0/1 – 10.1.1.1
ge-0/0/2 – 10.1.2.1 Zone 1.1.70.250
ge-0/0/3 – 1.1.7.1
Case Study: Creating the Application Set
[edit applications]
user@host# show
application HR-telnet {
protocol tcp;
source-port 1024-65535;
destination-port telnet;
}
application-set HR-Public-applications {
application junos-ftp;
application junos-ike;
application HR-telnet;
}
Case Study: Creating Policy Entries (1 of 2)
[edit security]
user@host# show policies
from-zone HR to-zone Public {
policy HR-to-Public {
match {
source-address HR_PCs;
destination-address address-Public;
application HR-Public-applications;
}
10.1.10.0/24
then { .1 .254 HR
A Zone
permit;
10.1.10. 10.1.1.0/24
log {
5
session-init; ge-0/0/1
ge-0/0/2
session-close; 10.1.20.0/24
10.1.2.0/24 ge-0/0/3
} 1.1.7.0/24 1.1.70.0/24
B
count; .1 .254
10.1.20.5 .254 .1
C
} Public
ge-0/0/1 – 10.1.1.1
ge-0/0/2 – 10.1.2.1 Zone 1.1.70.250
}
ge-0/0/3 – 1.1.7.1
. . .
Case Study: Creating Policy Entries (2 of 2)
policy otherHR-to-Public {
match {
source-address all-10-1;
destination-address all-1-1-70;
application junos-ftp;
}
then { 10.1.10.0/24
HR
.1 .254
deny; A Zone
10.1.10. 10.1.1.0/24
log { 5
ge-0/0/1
session-init; ge-0/0/2
} 10.1.20.0/24
10.1.2.0/24 ge-0/0/3
1.1.7.0/24 1.1.70.0/24
count; B
.1 .254
10.1.20.5 .254 .1
C
} Public
ge-0/0/1 – 10.1.1.1
ge-0/0/2 – 10.1.2.1 Zone 1.1.70.250
} ge-0/0/3 – 1.1.7.1
}
Case Study: Creating a Scheduler
[edit]
user@host# show schedulers
scheduler schedulerHR {
daily {
start-time 09:00:00 stop-time 17:00:00;
}
sunday exclude;
saturday exclude;
}
Case Study: Applying a Scheduler
[edit]
user@host# show security policies
from-zone HR to-zone Public {
policy HR-to-Public {
match {
source-address HR-PCs;
destination-address address-Public;
application HR-Public-applications;
}
then {
permit ;
log {
session-close;
}
count;
}
scheduler-name schedulerHR;
}
Case Study: Check Your Knowledge
 Questions:
•Will the policies illustrated in the previous example be
sufficient to permit FTP traffic between the HR Zone and the
Public Zone? Explain your reasoning.
•Will network administrators be able to use Telnet to access
the Junos security device? Explain your reasoning.
10.1.10.0/24
.1 .254 HR
A Zone
10.1.10. 10.1.1.0/24
5
ge-0/0/1
ge-0/0/2
10.1.20.0/24
10.1.2.0/24 ge-0/0/3
1.1.7.0/24 1.1.70.0/24
B
.1 .254
10.1.20.5 .254 .1
C
Public
ge-0/0/1 – 10.1.1.1
ge-0/0/2 – 10.1.2.1 Zone 1.1.70.250
ge-0/0/3 – 1.1.7.1
Case Study: Monitoring the Policy (1 of 2)
 Viewing the policy:
user@host> show security policies policy-name HR-to-Public detail
Policy: HR-to-Public, action-type: permit, State: enabled, Index: 15
Sequence number: 1
From zone: HR, To zone: Public
Source addresses:
PC-A: 10.1.10.5/32
Destination addresses:
Server_C: 1.1.70.250/32
Application: HR-Public-applications
IP protocol: tcp, ALG: ftp, Inactivity timeout: 1800
Source port range: [0-0]
Destination port range: [21-21]
Session log: at-create, at-close
Scheduler name: schedulerHR
Policy statistics:
Input bytes : 3844 35 bps
Output bytes : 2299 21 bps
Input packets : 70 0 pps
Output packets : 43 0 pps
Session rate : 2 0 sps
Active sessions : 0
Session deletions: 2
Policy lookups : 1
Note: Output is abbreviated.
Case Study: Monitoring the Policy (2 of 2)
 Policy log from external server:

Apr 10 12:34:12 10.210.14.133 [RT_FLOW_SESSION_CREATE] [junos@2636.1.1.1.2.36:
session created 10.1.10.5/60557->1.1.70.250/21,6: HR-to-Public
Apr 10 12:41:22 10.210.14.133 [RT_FLOW_SESSION_CLOSE] [junos@2636.1.1.1.2.36:

session closed TCP FIN: 10.1.10.5/60557->1.1.70.250/21,6: HR-to-Public,
28(1236) 22(1398) 430
Inbound packets (bytes) Outbound packets (bytes) Elapsed time in seconds
Summary
 In this chapter, we:

•Explained security policy functionality
•Described the components of a security policy
•Verified policies and monitored their execution
•Configured a basic security policy using the following
elements:
• Policy match conditions
• Policy actions—basic and advanced
• Policy scheduling
Review Questions
1. What are the basic components of a policy?

2. What is the default action for every policy set?
3. What is the purpose of a scheduler within the security
stanza?
4. How can you reorder policies?
Lab 2: Security Policies
 Create policies that control access between networks.
Worldwide Education Services

JNCIS SEC PPT - Security Policies - Coruse 10.a

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

JNCIS SEC PPT - Security Policies - Coruse 10.a

Enviado por

Direitos autorais:

Formatos disponíveis

Junos for Security Platforms

Chapter 4: Security Policies

 After successfully completing this chapter, you will be

Security Policy Overview

 What is a security policy?

Match Yes SCREEN Services

Packet-based Per Packet Filters

 The Junos OS for security platforms always examines

Does a security No Apply default

Does a security No Apply default

 System-default security System-default security

policy: deny all traffic

•Trust to trust: permit all 3

•Trust to untrust: permit all

 Steps: D 22 B 29200 6 ge-1/0/0

1. Host B initiates SSH to Host D—Flow B  D

insert security policies from-zone name to-zone name policy name

 Like any other Junos configuration stanza, you can

 Security Policy Overview

 You create policies under a context

 Policy matching criteria:

•Applications or application sets

 Commands for address book entries:

[edit security zones] [edit security zones]

[edit applications] [edit applications]

 Specifics: [edit security policies]

 If the security policy allows traffic to pass, you can

 Control plane logging can be stored locally or sent to

 SRX Series branch devices can log data plane logs

 For high-end SRX Series devices, data plane logging

 Use log action in security policy

 Use count action in security policy

• Use the detail option to display statistics

 Use traceoptions for detailed troubleshooting:

 Security Policy Overview

 A scheduled policy is a policy that uses a configured

Policy activated Policy deactivated

 You can configure a policy scheduler with the

[edit security policies]

 policy-rematch statement: signals the application

•Default behavior: Action on Policy Description

impacted Modify action Modifies action field

 Security Policy Overview

 Policy log from external server:

Apr 10 12:41:22 10.210.14.133 [RT_FLOW_SESSION_CLOSE] [junos@2636.1.1.1.2.36:

Inbound packets (bytes) Outbound packets (bytes) Elapsed time in seconds

 In this chapter, we:

1. What are the basic components of a policy?

 Create policies that control access between networks.

Você também pode gostar