O'Reilly logo

Junos Security by James Quinn, Timothy Eberhard, Patricio Giecco, Brad Woodberg, Rob Cameron

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

Chapter 4. Security Policy

Security policies, sometimes called firewall rules, are a method of selectively allowing traffic through a network. In a sense, security policies control who can talk to whom (or rather, what systems can talk to which other systems), and more importantly, how the conversation takes place. Security policies also provide the means for logging, authentication, and accounting of network traffic. The SRX evaluates every packet that passes through its zones and determines whether the traffic is permitted, dropped, logged, or more deeply inspected, or if it requires further authentication. This chapter explores how the SRX evaluates traffic and performs security policy lookups, how to configure those security policies, and some common issues to avoid.

Security Policy Overview

As illustrated in Figure 4-1, when a packet enters the SRX, the flow daemon (flowd) performs a session lookup. It does this to see whether the packet is already part of an existing session. If the packet is part of an existing session, it takes what is referred to as the fast path. If it is not found to be part of an existing session, it goes down the slow path. The fast path has fewer steps involved in checking the packet, and as a result, it is much faster at processing the packet.

Where policy evaluation in the SRX packet flow takes place

Figure 4-1. Where policy evaluation in the SRX packet flow takes place

Why does the security policy lookup take place after so many other checks?

The SRX is a zone-based firewall, meaning that all security policies are associated with zones and those zones are tied to interfaces. The SRX must perform a route lookup to determine the destination zone context before it can examine the correct security policies. In fact, before the firewall can do a security policy evaluation for a flow, it must perform three actions: a screen check (detailed in Chapter 6), a route lookup, and finally, a route lookup to determine the destination security zone. Any of these steps might result in the packet being dropped, even before security policy evaluation.

By default, three security zones come preconfigured on the SRX: the Trust zone, the Untrust zone, and the junos-global zone. It’s best to use custom zones with clear names describing their role and placement in the network. An example of this would be calling the accounting department network segment “accounting-dept” or even “Dept-A.” This will be far more user-friendly than a generic name such as “Trust” when an administrator returns to this zone configuration in the future.

Let’s create a new security zone:

[edit]
juniper@SRX5800> edit security
[edit security]
juniper@SRX5800> set zones security-zone accounting-dept

The new zone is called accounting-dept. Once a new zone has been created there are a few features that can be turned on. The most important feature is called TCP-RST. TCP-RST will send a RESET packet for any non-TCP SYN packet that doesn’t already match an existing session. What does that mean? Well, it basically means that if a session has timed out or is started improperly, the SRX will tell the source node that it needs to restart the TCP connection. It is recommended by the authors that TCP-RST remain disabled unless it is required on your network. This makes the SRX visible when it drops packets and can be abused by a malicious user to probe the SRX’s security policies.

Additional zone configuration items include:

Host-inbound-traffic

This tells the SRX what to allow to this security zone. For example, if you want to ping the SRX’s interface, you need to configure ping under the zone’s host-inbound-traffic profile. Any protocols or system services that need to be allowed to go to the SRX should be configured under host-inbound-traffic. Here’s a quick example:

juniper@SRX5800> set zones security-zone accounting-dept host-inbound-traffic
system-services ping
Screen

Screens are high-performance denial-of-service (DoS) and distributed denial-of-service (DDoS) protections that are extremely efficient and can block a number of floods and attacks in hardware. We will cover screens thoroughly in Chapter 7.

The last step in configuring a security zone is to apply the interface to the zone:

[edit security]
juniper@SRX5800> set zones security-zone accounting-dept interfaces ge-0/0/0

The new zone configuration is:

[edit security]
juniper@SRX5800>  show zones security-zone accounting-dept
host-inbound-traffic {
    system-services {
        ping;
    }
}
interfaces {
    ge-0/0/0.0;
}

These are the fundamentals of zones, so let’s take a look at a quick security policy. The format and configuration of a simple security policy that the firewall administrator has previously configured might look something like the following:

juniper@SRX5800> show configuration security policies
from-zone trust to-zone Internet {
    policy allow-users {
        match {
            source-address inside-users;
            destination-address any;
            application any;
        }
        then {
            permit;
        }
    }
}

Security policy configurations are composed of six major elements all used within this sample security policy:

Source zone

The source zone is referred to as from-zone and is labeled as trust.

Destination zone

The destination, or to-zone, is labeled as Internet.

Policy

This is a descriptive name assigned to the policy. In the preceding example, it’s called allow-users.

Source address

The source address group is inside-users. A source address is a collection or a single IP address used in policy to dictate whom is initiating this connection.

Destination address

In the example allow-users policy, the destination address is any. The destination address again is a collection or a single IP address that the source is talking to. In this case, any means any destination.

Service

In the example allow-users policy, the service is any. The service is a single port or port range such as HTTP (TCP port 80), SSH (TCP port 22), or, for example, DNS (UDP port 53).

These items are all a part of the match statement which details to what and to whom this policy applies.

The last line of the example policy is an action configured to take place if the traffic matches the criteria of the first lines, referred to as the then statement. If traffic is initiated from the Trust zone, has a destination address in the Internet zone, and is from the inside-users segment, the SRX permits the traffic. The then statement describes what action should be taken. An action can include logging, denying, permitting, or sending for deeper inspection in cases such as Intrusion Detection and Protection (IDP) and Unified Threat Management (UTM). We will cover both IDP and UTM later in the book, but for now it’s important to understand that they are enabled and triggered by the then statement in security policies. The security policy is what matches traffic and tells the SRX to send the packet or flow for deeper inspection.

Keep in mind that multiple actions can be configured inside the then statement.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required