# Junos Security Zones and Policies

> Chapter 13 of the Courseiva JUNIPER-JNCIA-JUNOS curriculum — https://courseiva.com/learn/juniper-jncia-junos/junos-security-zones-and-policies

**Official objective:** 5.1 — Configure security zones, inter-zone and intra-zone security policies.

## Introduction

Exam objective 5.3 asks you to configure security zones and the policies that control traffic between them. This chapter solves the problem of how to let the right traffic through your network while blocking everything else. For the JNCIA-JUNOS exam, understanding zones and policies is the most practical skill you will learn because it directly translates to building a real corporate firewall.

## The Office Building Security Desk Analogy

An office building has a main entrance with a security desk. This desk is the firewall. Inside the building, different areas have different levels of access. The ground-floor lobby is a security zone called 'Public'. Anyone can walk in. The second floor holds the sales team; it is a zone called 'Sales_Trusted'. The third floor is the server room, a zone called 'High_Security'. The security guard controls traffic between these zones.

When an employee from Sales_Trusted wants to go to the server room (High_Security), the guard checks the employee's badge against a policy. The policy might say: 'Only people with red badges can enter the server room between 9am and 5pm.' This is an inter-zone policy. If two people in the same Sales_Trusted zone want to share a document, the guard checks a different policy for traffic inside the same zone. That is an intra-zone policy.

Every person entering the building is a packet. Their destination floor is the destination zone. Their source floor is the source zone. The security guard does not guess. The guard follows a set of written rules, just as a Junos device follows security policies. This specific office layout with defined zones and a guard at a single chokepoint is exactly how Junos Security Zones and Policies work on a router or switch. The building's floor plan is the zone configuration. The guard's rulebook is the policy list. Without these, anyone could wander anywhere, which is a security disaster.

## Core explanation

A Juniper Networks device, like an SRX Series firewall, uses **security zones** to organise network interfaces. A security zone is a logical grouping of one or more interfaces that share a common security requirement. Think of a zone as a labelled container. You might put all the interfaces connected to your internal company network into a zone called 'Trust'. You might put the interface connected to the internet into a zone called 'Untrust'. The device does not know what traffic is 'good' or 'bad' by itself. It only knows what zone the traffic came from and what zone it is going to.

The magic happens with **security policies**. A security policy is a rule that decides what happens to traffic, based on its source zone, destination zone, source IP address, destination IP address, and the application (like HTTP for web traffic or SSH for secure shell access). Every policy has an action: either **permit** (let it through) or **deny** (block it).

There are two main types of traffic flow between zones. **Inter-zone traffic** is traffic moving from one zone to a different zone. For example, a user in the 'Trust' zone trying to reach a web server in the 'Untrust' zone. This is the most common type of traffic you will configure. **Intra-zone traffic** is traffic moving between two interfaces that belong to the same zone. For example, two computers both in the 'Trust' zone trying to talk to each other. By default, Junos devices block all inter-zone traffic and permit all intra-zone traffic. You use policies to change these defaults.

The device evaluates policies in a specific order, from top to bottom in the configuration. The first policy that matches the traffic is applied. This is called **first-match logic**. If no policy matches, the traffic is denied by an implicit default policy at the end. This default is called the **default deny** policy.

To configure this, you do three things:

- Define the zone and assign interfaces to it.
- Create a security policy that specifies source zone, destination zone, and the match conditions.
- Set the action to permit or deny.

Why does this replace older methods? Before modern firewalls, people used **Access Control Lists (ACLs)** on routers, which were simple lists of allow/deny rules applied directly to an interface without any concept of zones. Zones provide more structure. They let you apply a single policy to multiple interfaces at once, and they make it easier to understand the security posture of your whole network at a glance. For the exam, you must understand that a policy always references the zone names, not the interface names. The interface is just a member of the zone.

A final critical point: **screens**. A screen is a Junos feature that protects against certain types of attacks, like IP spoofing or port scans. Screens are attached to a zone, not to a policy. If you enable a screen for the 'Untrust' zone, every packet entering that zone is checked against the screen rules before any policy is evaluated. Remember that screens are a zone-level protection, not a policy-level one.

## Real-world context

An IT professional at a small company, 'Bright Widgets Ltd', needs to set up a firewall. The company has three physical network segments: a public Wi-Fi for guests, an internal network for employees, and a server room for the company website. The IT pro configures three zones on an SRX firewall.

- Zone 'Guest' has one interface, ge-0/0/0, connected to the guest Wi-Fi access point.
- Zone 'Internal' has one interface, ge-0/0/1, connected to the employee network switch.
- Zone 'DMZ' (a demilitarised zone) has one interface, ge-0/0/2, connected to the web server.

The IT pro now writes policies. Here is the step-by-step process:

- Step 1: Create a policy called 'Allow_Employees_to_Internet'. Source zone: Internal. Destination zone: Guest (because the internet is reached through the guest zone's uplink in this simple setup). Source address: 192.168.1.0/24 (the employee subnet). Destination address: any. Application: any. Action: permit.
- Step 2: Create a policy called 'Allow_Internet_to_Web'. Source zone: Guest. Destination zone: DMZ. Source address: any. Destination address: 10.0.0.5 (the web server's IP). Application: http. Action: permit.
- Step 3: Create a policy called 'Deny_All_Guest_to_Internal'. Source zone: Guest. Destination zone: Internal. Action: deny. This ensures guests cannot reach the employee network.
- Step 4: The final policy is the implicit default deny, which blocks anything not explicitly allowed.

The IT pro then tests by trying to browse the web from a guest laptop. The traffic matches 'Allow_Internet_to_Web' only if it is destined for the web server. For general internet access from the guest network, the IT pro realises he forgot a policy. He adds 'Allow_Guest_to_Internet' with source Guest, destination any, action permit. He also enables a screen called 'icmp-flood' on the Guest zone to prevent ping-based attacks.

This real scenario shows exactly what an IT professional does daily: identifying traffic flows, defining zones, writing policies, and testing. The exam expects you to understand this exact workflow, including the order of policies and the role of the default deny.

## Exam focus

The JNCIA-JUNOS exam tests Security Zones and Policies heavily. You can expect around 5-8 questions on this topic. The exam loves to test your understanding of the default behaviour. A classic trap is asking: 'What is the default action for inter-zone traffic?' The wrong answer is 'permit', but the correct answer is 'deny'. Similarly, for intra-zone traffic, the default is 'permit'.

The exam also tests the structure of the policy. You will see questions like: 'Which statement is true about a security policy?' The correct answer will mention that a policy must have a source zone, a destination zone, and an action. Another common trap is asking about 'policies without zones' or 'policies that apply to all interfaces'. This is wrong; a policy always has at least one source zone and one destination zone.

Here are the key topics the exam focuses on:

- The difference between inter-zone and intra-zone traffic flows.
- The concept of the default deny policy.
- The order of operations: screens are applied before policies.
- The components of a security policy: source-zone, destination-zone, source-address, destination-address, application, action.
- How to assign an interface to a zone.
- The fact that a zone can contain multiple interfaces.
- The idea that you must define a zone before you can reference it in a policy.

Traps to watch for:

- A question says 'Traffic from zone A to zone A is intra-zone traffic.' That is true, but the exam might ask if the default action is deny. It is not; it is permit.
- A question might list a policy with only a source zone and an action, leaving out the destination zone. This is an invalid configuration.
- A question might claim that changing the order of policies does not matter. This is false; first-match logic means order is critical.

Definitions to memorise:

- Security Zone: A logical grouping of interfaces that share a common security policy.
- Security Policy: A rule that controls traffic based on source and destination zones and other criteria.
- Inter-zone: Traffic between two different zones.
- Intra-zone: Traffic within the same zone.
- Default Deny: The implicit rule at the end of every policy list that drops unmatched traffic.
- Screen: A zone-level protection against attacks, evaluated before policies.

## Step by step

1. **Define the security zone** — Create a zone using the 'set security zones security-zone <name>' command. This defines the container but does not yet assign any interfaces.
2. **Assign interfaces to the zone** — Use 'set security zones security-zone <name> interfaces <interface-name>' to add an interface. An interface can only belong to one zone. This step is crucial because traffic entering that interface is now subject to that zone's policies.
3. **Create a security policy** — Use 'set security policies from-zone <source-zone> to-zone <destination-zone> policy <policy-name>' to begin a policy definition. This creates the two-zone framework for the rule.
4. **Define match conditions** — Inside the policy, set the source address, destination address, and application. For example, 'set security policies from-zone Trust to-zone Untrust policy Allow-Web match source-address any destination-address any application junos-http'. These conditions tell the device what traffic this rule applies to.
5. **Set the action** — Use 'set security policies from-zone Trust to-zone Untrust policy Allow-Web then permit' to allow matching traffic. You can also use 'then deny' to block it. The action is the final decision the device makes for traffic that matches all conditions.

## Comparisons

### Inter-zone Traffic vs Intra-zone Traffic

**Inter-zone Traffic:**
- Traffic moves between two different security zones.
- Default action is deny.
- Requires an explicit policy to permit.

**Intra-zone Traffic:**
- Traffic stays within the same security zone.
- Default action is permit.
- Does not require a policy unless you want to restrict it.

### Security Zone vs Security Policy

**Security Zone:**
- A logical container for interfaces.
- Defines the security boundary.
- Does not contain rules by itself.

**Security Policy:**
- A rule that controls traffic flow.
- References source and destination zones.
- Includes match conditions and an action.

### Screen vs Policy

**Screen:**
- Configured on a zone, not on a policy.
- Protects against specific attack types.
- Evaluated before policy lookup.

**Policy:**
- Configured between two zones.
- Controls access based on addresses and applications.
- Evaluated after screen checks.

## Diagram

_This diagram shows the flow of a packet through zone screen checks then policy lookup, ending in either a permit/deny action or the default deny._

```mermaid
flowchart TD
    A[Packet arrives on interface] --> B{Which zone?}
    B -->|Zone = Trust| C[Screen check on Trust zone]
    B -->|Zone = Untrust| D[Screen check on Untrust zone]
    C --> E{Policy lookup for Trust to destination zone}
    D --> F{Policy lookup for Untrust to destination zone}
    E --> G[Match found?]
    F --> G
    G -->|Yes| H[Apply policy action (permit/deny)]
    G -->|No| I[Implicit default deny]
```

## Common misconceptions

- **Misconception:** Intra-zone traffic is blocked by default. **Reality:** Intra-zone traffic is permitted by default in Junos. (This mistake is common because inter-zone traffic is blocked by default, and people assume the same rule applies to all traffic types.)
- **Misconception:** A security policy can be applied to a specific interface instead of a zone. **Reality:** A security policy always references zones, not interfaces. Interfaces are members of zones. (Beginners who learn ACLs first think of rules tied to an interface. Junos zones abstract this level of detail.)
- **Misconception:** If no policy matches traffic, the traffic is permitted by default. **Reality:** If no policy matches, the traffic is denied by the implicit default deny policy. (This misconception comes from a false sense of security; people assume a device is permissive unless told otherwise. The opposite is true.)
- **Misconception:** Screens are part of a security policy. **Reality:** Screens are configured on a zone, not on a policy. They are evaluated before policy lookup. (The names 'screens' and 'policies' sound similar, so beginners assume they are configured together.)
- **Misconception:** You can have a policy without specifying a source zone. **Reality:** Every policy must have at least a source zone and a destination zone. (Some vendors allow zone-less policies, but Junos requires explicit zone definitions.)

## Key takeaways

- Inter-zone traffic is denied by default; intra-zone traffic is permitted by default.
- A security policy must specify source zone, destination zone, and action.
- Policies are evaluated in order from top to bottom using first-match logic.
- Screens protect against attacks at the zone level, before any policy is matched.
- A zone can contain multiple interfaces, and a single interface can belong to only one zone.
- The implicit default deny policy is always the last rule and blocks all unmatched traffic.

## FAQ

**What is the difference between inter-zone and intra-zone traffic?**

Inter-zone traffic moves between two different security zones. Intra-zone traffic moves within the same zone. By default, inter-zone is blocked and intra-zone is allowed.

**Can I assign the same interface to two zones?**

No. Each interface can belong to only one security zone at a time. If you try, the device will return a configuration error.

**What happens if no security policy matches my traffic?**

The traffic is denied by the implicit default deny policy. This is a built-in rule at the end of every policy list that drops any unmatched packets.

**Do I need to configure the default deny policy?**

No. The default deny policy is automatically present and cannot be deleted. It is always the last rule.

**What is a screen in Junos?**

A screen is a set of protection mechanisms that guard against attacks like IP spoofing or port scans. It is configured on a zone and evaluated before any policy.

**Can I reorder security policies?**

Yes, you can insert or move policies using the 'insert' command. Order matters because the firewall uses first-match logic.

## Check your understanding

1. **What is the default action for inter-zone traffic?**

   Answer: The default action is deny. Traffic between different zones is blocked unless an explicit permit policy is configured.

2. **What are the mandatory components of a Junos security policy?**

   Answer: A security policy must have a source zone, a destination zone, and an action (permit or deny).

3. **Can you assign two different interfaces to the same security zone?**

   Answer: Yes. A security zone can contain multiple interfaces, and they all share the same security policies.

4. **What is the first-match logic in the context of security policies?**

   Answer: First-match logic means the device evaluates policies from top to bottom and applies the first policy whose conditions match the traffic, ignoring all subsequent policies.

5. **Where are screens configured and when are they evaluated?**

   Answer: Screens are configured on a security zone and are evaluated on traffic entering that zone before any security policy lookup occurs.

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/juniper-jncia-junos/junos-security-zones-and-policies