JN0-231 Security policies

Security Policies Detailed Explanation

Security policies are fundamental in configuring and managing traffic flow on SRX devices. They define rules for how traffic is allowed, denied, or logged between different network zones.

1. Purpose and Components

Purpose of Security Policies

Security policies control traffic between zones on an SRX device. Without these policies, traffic between zones (e.g., trust and untrust) is blocked by default. These policies are critical for:

1. Allowing legitimate traffic (e.g., internal users browsing the Internet).
2. Blocking malicious or unauthorized traffic (e.g., external attackers trying to access internal servers).
3. Monitoring traffic with logging for visibility and troubleshooting.

Components of a Security Policy

Each security policy consists of several components:

1. Source Address

Defines where the traffic originates:

• Can be a single IP address, subnet, or a group defined in the address book.
• Example: A subnet 192.168.1.0/24.

2. Destination Address

Defines where the traffic is going:

• Can be a single IP address, subnet, or group.
• Example: A web server at 203.0.113.10.

3. Application or Service

Specifies the type of traffic or protocol:

• Can be predefined applications (e.g., HTTP, HTTPS) or custom-defined services.
• Example: Allowing only web traffic (HTTP, HTTPS).

4. Action

Determines what happens to the traffic:

• Permit: Allows the traffic.
• Deny: Blocks the traffic.
• Log: Records traffic details for monitoring or troubleshooting.

5. Optional Features

• Logging: Enables recording of policy hits, useful for audits and troubleshooting.
• Scheduling: Activates the policy only during specific times or days.

How Security Policies Work

1. Traffic enters the SRX device and is inspected.
2. The device checks policies in order (from top to bottom).
3. The first matching policy is applied, and the process stops.
4. If no policies match, the traffic is denied by default (default deny rule).

2. Policy Configuration

Basic Example: Allow Web Traffic

Scenario

Allow HTTP (TCP port 80) traffic from the trust zone to the untrust zone.

Configuration

1. Match traffic originating from any address in the trust zone:

   set security policies from-zone trust to-zone untrust policy allow-web match source-address any
   

2. Match traffic destined for any address in the untrust zone:

   set security policies from-zone trust to-zone untrust policy allow-web match destination-address any
   

3. Match the application (HTTP):

   set security policies from-zone trust to-zone untrust policy allow-web match application junos-http
   

4. Permit the traffic:

   set security policies from-zone trust to-zone untrust policy allow-web then permit
   

Example with Logging

Scenario

Allow all traffic from the trust zone to the untrust zone and log every session for monitoring.

Configuration

1. Match all traffic from the trust zone:

   set security policies from-zone trust to-zone untrust policy log-all match source-address any
   

2. Permit the traffic and enable logging:

   set security policies from-zone trust to-zone untrust policy log-all then permit log
   

Advanced Configuration: Restrict by Source

Scenario

Allow SSH traffic only from a specific subnet (192.168.1.0/24) in the trust zone to an external server (203.0.113.10) in the untrust zone.

Configuration

1. Match traffic from 192.168.1.0/24:

   set security address-book global address internal-network 192.168.1.0/24
   set security policies from-zone trust to-zone untrust policy ssh-access match source-address internal-network
   

2. Match traffic destined for 203.0.113.10:

   set security address-book global address web-server 203.0.113.10
   set security policies from-zone trust to-zone untrust policy ssh-access match destination-address web-server
   

3. Match the SSH application:

   set security policies from-zone trust to-zone untrust policy ssh-access match application junos-ssh
   

4. Permit the traffic:

   set security policies from-zone trust to-zone untrust policy ssh-access then permit
   

Verify the Policy

Use the following commands to verify your configuration:

1. View the policy:

   show configuration security policies
   

2. Monitor traffic matching the policy:

   show security flow session
   

3. Check hit counts (number of times the policy has been used):

   show security policies hit-count
   

3. Key Features

1. Policy Scheduling

What is Policy Scheduling?

• Schedules define when a policy is active.
• Useful for limiting access to specific hours (e.g., only during business hours).

Configuration Example

Allow HTTP traffic only from 8:00 AM to 6:00 PM:

1. Define a schedule:

   set schedules time-range business-hours start-time 08:00 stop-time 18:00 daily
   

2. Attach the schedule to the policy:

   set security policies from-zone trust to-zone untrust policy allow-web then permit schedule business-hours
   

2. Policy Hierarchy

How Are Policies Evaluated?

• Policies are checked in order from top to bottom.
• The first policy that matches the traffic is applied, and the process stops.
• Best Practice: Place more specific policies at the top and broader ones at the bottom.

3. Default Deny

What Happens to Unmatched Traffic?

• Any traffic that doesn’t match a policy is automatically denied.
• This is known as the default deny rule.

Best Practice

Always create explicit policies for legitimate traffic and rely on the default deny for unwanted traffic.

4. Troubleshooting Security Policies

Why Troubleshooting is Important

• Misconfigured security policies can cause traffic interruptions, unauthorized access, or difficulty in diagnosing issues.
• Effective troubleshooting ensures that your policies function as intended.

1. Common Troubleshooting Tools

a. View Active Sessions

The show security flow session command shows all active traffic sessions on the device, including:

• Source and destination IPs.
• Ports, protocols, and zones.
• Policies applied to the session.

Command:

show security flow session

Example Output:

Session ID: 12345
  From: 192.168.1.10/1234 to 203.0.113.10/80, TCP
  Policy name: allow-web
  Ingress interface: ge-0/0/1
  Egress interface: ge-0/0/2

• Policy name: Indicates the security policy that permitted the session.

b. Check Policy Hit Counts

The show security policies hit-count command displays how many times each policy has been matched.

Command:

show security policies hit-count

Example Output:

From zone: trust, To zone: untrust
Policy: allow-web
  Hits: 234
Policy: deny-all
  Hits: 45

• Hits: Number of times the policy has been applied to traffic.

c. Enable Policy Logging

Policy logging captures detailed information about traffic matches. Use it to analyze traffic patterns or investigate denied traffic.

Configuration: Enable logging for a policy:

set security policies from-zone trust to-zone untrust policy allow-web then permit log

View log messages:

show log messages

2. Debugging Traffic Flow

If traffic isn’t working as expected, you can trace its path through the SRX device.

a. Trace Options for Security Flow

1. Enable trace logging for flow issues:

   set security flow traceoptions file flow-log
   set security flow traceoptions flag basic-datapath
   

2. Commit the changes:

   commit
   

3. View the trace log:

   show log flow-log
   

3. Troubleshooting Unmatched Traffic

If traffic isn’t matching a policy:

1. Check source/destination zones and IPs.
2. Ensure the correct application or service is specified.
3. Verify the order of policies (remember: first match applies).
4. Look for blocked traffic in the default deny log.

5. Advanced Use Cases

1. Layer 7 (Application-Based) Policies

Junos OS supports deep packet inspection (DPI) to identify applications regardless of their port numbers.

Scenario

You want to block Facebook traffic but allow general web browsing.

Configuration

1. Use the predefined application facebook:

   set security policies from-zone trust to-zone untrust policy block-facebook match application facebook
   set security policies from-zone trust to-zone untrust policy block-facebook then deny
   

2. Allow web browsing:

   set security policies from-zone trust to-zone untrust policy allow-web match application junos-http
   set security policies from-zone trust to-zone untrust policy allow-web match application junos-https
   set security policies from-zone trust to-zone untrust policy allow-web then permit
   

2. Geo-IP Policies

Block or allow traffic based on the geographic location of IP addresses.

Scenario

Allow traffic only from the United States and block all others.

Configuration

1. Enable Geo-IP filtering:

   set security policies from-zone untrust to-zone trust policy geo-block match source-address country US
   set security policies from-zone untrust to-zone trust policy geo-block then permit
   

2. Deny traffic from all other countries:

   set security policies from-zone untrust to-zone trust policy deny-all then deny
   

3. Policy Scheduling

Scenario

Allow FTP traffic only during business hours (9 AM - 5 PM).

Configuration

1. Define a time range:

   set schedules time-range business-hours start-time 09:00 stop-time 17:00 daily
   

2. Apply the schedule to the policy:

   set security policies from-zone trust to-zone untrust policy allow-ftp match application junos-ftp
   set security policies from-zone trust to-zone untrust policy allow-ftp then permit schedule business-hours
   

6. Best Practices

1. Organize Policies Logically

• Group related rules together (e.g., web policies, admin access policies).
• Use meaningful names for policies.

2. Prioritize Specific Policies

• Place more specific policies above broader ones.
• Example:
  • Allow specific admin access first.
  • Deny general access afterward.

3. Use Logging Strategically

• Enable logging for critical policies, such as:
  • Deny-all policies (to monitor blocked traffic).
  • High-priority rules (to track sensitive access).
• Avoid enabling logging for every policy to prevent log overflow.

4. Regularly Review Policies

• Remove unused or outdated policies.
• Check hit counts to identify policies that are no longer in use.

5. Secure Management Access

• Restrict administrative access to trusted IPs.
• Use a separate management zone for device access.

Security Policies (Additional Content)

1. Application vs. Service in Security Policies – Mutual Exclusivity

This is a must-know rule for both Junos configuration and the JNCIA-SEC exam.

Key Rule: You Cannot Use Both service and application in the Same Policy

In Junos OS, a security policy match clause can include either:

• An application or application-set OR

• A service or service-set

But not both at the same time. Attempting to use both results in a configuration failure at commit time.

Invalid Policy Example

set security policies from-zone trust to-zone untrust policy invalid-policy match application junos-http
set security policies from-zone trust to-zone untrust policy invalid-policy match service my-custom-service

→ This configuration will fail to commit, because it tries to use both application and service.

Why This Happens

• Application objects provide deep inspection and protocol identification (layer 7).

• Service objects rely only on port/protocol matching (layer 4).

• Mixing both would create ambiguity in traffic classification.

Best Practice

• Decide whether you want to use application-based or service-based matching.

• Stick to application objects when using features like UTM, IDP, or when using application sets.

Exam Tip

Expect questions like:

"A security policy fails to commit due to configuration syntax. Which of the following is the cause?"

→ Correct answer:

"The policy uses both application and service match conditions, which are mutually exclusive in Junos OS."

2. Priority of Application over Service in Policy Contexts

Even though you cannot use both in the same policy, it's important to understand why application objects are preferred, especially in complex environments.

Why Applications Take Priority Conceptually

• Applications (like junos-http, junos-https) support:

  • Protocol detection beyond port numbers

  • Integration with application-based UTM, AppFW, IDP, and logging

  • Support for nested application sets

• Services (e.g., TCP port 80) only match based on layer 4 headers (protocol + port)

When Using Application-Sets

• You can group multiple applications into application-sets and reference those in your policy.

• This is stronger and more flexible than service objects.

• Example:

  set applications application-set web-traffic application [ junos-http junos-https ]
  set security policies from-zone trust to-zone untrust policy allow-web match application web-traffic
  

Practical Insight

• If your policy uses application-set, the system will:

  • Detect traffic dynamically.

  • Apply match based on actual application behavior, not just port.

Exam Tip

"Which of the following statements about applications and services in a policy is true?"
→ Correct answer:
"Security policies cannot include both application and service in the match clause."

Summary Table

Rule/Concept	Details
Mutual exclusivity	application and service cannot be used together in one policy
Application matching priority	Application objects offer richer detection and policy granularity
Preferred for security features	Use application when using UTM, AppFW, IDP, or content inspection
Policy syntax enforcement	Misuse leads to commit-time error, not runtime failure