ccie blog

Basic Juniper SRX Setup

This guide goes over the basics for setting up a Juniper SRX firewall. The bullet points below identify what is covered in this article.

  • Root password setup
  • Basic IP address configration
  • Remote access managment: HTTP & HTTPS setup (for J-Web browser application), and SSH
  • Ping to the SRX
  • Basic security zone & policy configuration.  I will permit R2 (untrust zone) to ping R1 (trust zone)

Note:  The SRX I’m using is a virtual platform on GNS3, and has been loaded with factory default configuration.

 

Diagarm

Basic_Juniper_SRX_Setup

Root password configuration:

Before you can commit any configuration, a root password must be set.

set system root-authentication plain-text-password
#type-in-your-password

 

IP address configuration

See the topology for IP address details.

set interfaces ge-0/0/0.0 family inet address 10.99.0.254/24
set interfaces ge-0/0/1.0 family inet address 192.168.0.254/24
set interfaces ge-0/0/2.0 family inet address 13.0.0.254/24
commit

root# run show interfaces terse | match ge
ge-0/0/0                up    up
ge-0/0/0.0              up    up   inet     10.99.0.254/24
ge-0/0/1                up    up
ge-0/0/1.0              up    up   inet     192.168.0.254/24
ge-0/0/2                up    up
ge-0/0/2.0              up    up   inet     13.0.0.254/24

 

HTTP, HTTPS, SSH, and Ping Configuration

To understand how to configure these settings, you have to understand very basic security zones.  From the output below, you can see that there are two zones by default: “trust” and “untrust”.

root# show security zones
security-zone trust {
    tcp-rst;
}
security-zone untrust {
    screen untrust-screen;
    interfaces {
        ge-0/0/0.0 {
            host-inbound-traffic {
                system-services {
                    http;
                    https;
                    ssh;
                    telnet;
                    dhcp;

As you can see, ge-0/0/0.0 has (by default on this platform) been allocated to the untrust zone. This is my management interface, and I want to apply it to the trust zone. First I have to delete it out the untrust zone.

edit security zones security-zone untrust
 delete interfaces ge-0/0/0.0
commit

exit

root# run show security zones
security-zone trust {
    tcp-rst;
}
security-zone untrust {
    screen untrust-screen;

Now I need to add ge-0/0/0.0 to the trust zone and allow management access to the box.

edit security zones security-zone trust
 set interfaces ge-0/0/0.0 
 set interfaces ge-0/0/0.0 host-inbound-traffic system-services ping
 set interfaces ge-0/0/0.0 host-inbound-traffic system-services http
 set interfaces ge-0/0/0.0 host-inbound-traffic system-services https
 set interfaces ge-0/0/0.0 host-inbound-traffic system-services ssh

Note: I also included ping traffic to the SRX because by default, it is not possible the firewalls interface.

Next, a admin user account needs to be configured.

set system login user test class super-user authentication plain-text-password
#type-in-your-password
commit

Finally, for https to work, you just need to create a certificate.  Here I use a self-signed certificate as I am only in a lab.

set system services web-management https system-generated-certificate
commit

Everything is now available.

 

Basic Security Zones and Policies

I want to configure R2  to be part of an untrusted zone, R1 as part of a trusted zone, then allow R2 to ping R1.  Let’s take a re-cap on what our zones look like so far:

test# show security zones
security-zone trust {
    tcp-rst;
    interfaces {
        ge-0/0/0.0 {
            host-inbound-traffic {
                system-services {
                    ping;
                    http;
                    ssh;
                    https;
                }
            }
        }
    }
}
security-zone untrust {
    screen untrust-screen;

So we have two zones, trust and untrust with ge-0/0/0.0 allocated to the trust zone. Let’s add ge-0/0/1.0 to the trust zone, and ge-0/0/2.0 to the untrust zone.

test# edit security zones
 set security-zone trust interfaces ge-0/0/1.0
 set security-zone untrust interfaces ge-0/0/2.0
commit

We need to understand what policies are in use for communication between these zones, so let’s look at the current (factory default) configuration.

test# show security policies
from-zone trust to-zone trust {
    policy default-permit {
        match {
            source-address any;
            destination-address any;
            application any;
        }
        then {
            permit;
        }
    }
}
from-zone trust to-zone untrust {
    policy default-permit {
        match {
            source-address any;
            destination-address any;
            application any;
        }
        then {
            permit;
        }
    }
}
from-zone untrust to-zone trust {
    policy default-deny {
        match {
            source-address any;
            destination-address any;
            application any;
        }
        then {
            deny;
        }
    }
}

This is similar to most firewalls. Basically:

  • Trusted to Trusted = Permit
  • Trusted to Untrusted = Permit
  • Untrusted to Trusted = Deny

So let’s configure a security policy that allows a simple ping from the R2 (untrust zone) to R1 (trust zone). The first thing to do is make an address book for each host under the relevant security-zone.

set security zones security-zone trust address-book address R1 192.168.0.1/32
set security zones security-zone untrust address-book address R2 13.0.0.1/32

Address books are simply a way of naming a host within a zone (or globally if required). Address books are used as a point of reference within any security policy configuration.

Now to create the policy:

edit security policies from-zone untrust to-zone trust
 set policy R2_TO_R1_POLICY match source-address R2
 set policy R2_TO_R1_POLICY match destination-address R1
 set policy R2_TO_R1_POLICY match application junos-icmp-ping
 set policy R2_TO_R1_POLICY then permit
commit

Now annoyingly, the new policy is actually created underneath any existing security policy for that zone. So if we take a look at the security policy as it stands you will see what I mean:

test# show security policies from-zone untrust to-zone trust
policy default-deny {
    match {
        source-address any;
        destination-address any;
        application any;
    }
    then {
        deny;
    }
}
policy R2_TO_R1_POLICY {
    match {
        source-address R2;
        destination-address R1;
        application junos-icmp-ping;
    }
    then {
        permit;
    }
}

Basically if I left the configuration like this, everything would be denied by the first policy. What needs to happen is the new policy needs to be inserted before the default deny rule. Let’s do it.

edit security policies from-zone untrust to-zone trust
 insert policy R2_TO_R1_POLICY before policy default-deny

The policy is then re-ordered, as shown below:

test# show security policies from-zone untrust to-zone trust
policy R2_TO_R1_POLICY {
    match {
        source-address R2;
        destination-address R1;
        application junos-icmp-ping;
    }
    then {
        permit;
    }
}
policy default-deny {
    match {
        source-address any;
        destination-address any;
        application any;
    }
    then {
        deny;
    }
}

Done.

Leave a comment

Your comment