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

Policy Structure

Earlier in the chapter we broke down an example security policy into its core elements. Now, let’s discuss how to create the various objects that go into those security policies and toy with some of the advanced configuration options.

Security Zones

The first thing we need to do is to create a new security zone and assign it to the corresponding interface:

juniper@SRX5800> edit
Entering configuration mode
[edit]
juniper@SRX5800# set security zones security-zone web-dmz
juniper@SRX5800# set security zones security-zone web-dmz interfaces fe-0/0/2.0

Now we need to configure the IP address of the web servers. IP addresses or DNS names are configured in what’s called address-books. These address-books store the IP or DNS information used in security policies. Additionally, address-books are tied to a single security zone; it’s not possible to assign the same address-book to two different security zones.

The important thing to note is that it’s not possible to configure IP addresses directly into the security policy—it must be done within an address-book.

juniper@SRX5800> edit
Entering configuration mode
[edit]
juniper@SRX5800# edit security zones security-zone web-dmz
[edit security zones security-zone web-dmz]
juniper@SRX5800# set address-book address web1 172.31.100.60

Here, a new address-book has been created on web-dmz that was previously configured. The new address-book has been assigned the label of web1, and the IP address of web1 is 172.31.100.60.

You create a second address-book for the second web server on web-dmz in the same way:

juniper@SRX5800>
[edit security zones security-zone web-dmz]
juniper@SRX5800# set address-book address web2 172.31.100.61

The third address-book that is configured is slightly different. This time, instead of using IP addresses, the address-book is configured with a DNS name:

juniper@SRX5800> edit security zones security-zone Internet
[edit security zones security-zone Internet]
juniper@SRX5800# set address-book address hackers_web hackers.com

Here, the address-book hackers_web was configured to the Internet security zone. The hackers_web address-book includes the DNS name hackers.com.

Warning

Some address-book names are reserved internally for the SRX and cannot be used. The prefixes are static_nat_, incoming_nat_, and junos_.

In situations where the policy calls for multiple IP addresses, ranges, or DNS names, instead of writing multiple security policies that all take the same action it’s possible to use an address-set. An address-set is simply a grouping of address books.

Think of the address-book as a business card with information such as a phone number and name. Those business cards can all be stored into a single Rolodex or an address-set. Creating an address-set is similar to creating an address-book. Address-sets are also assigned to security zones and configured in the same manner:

juniper@SRX5800> edit security zones security-zone web-dmz
Entering configuration mode
[edit security zones security-zone web-dmz]
juniper@SRX5800# set address-book address-set web-servers address web1
[edit security zones security-zone web-dmz]
juniper@SRX5800# set address-book address-set web-servers address web2

A new address-set has been configured and is called web-servers, and the two web server address-books have been assigned to it. Now, when policy is written later, instead of writing policy for both web1 and web2 we can just use web-servers and it is applied to both.

We can verify the configuration by looking at the web-dmz zone to confirm that the proper addresses are assigned to the zone, and that the address-set is configured properly:

juniper@SRX5800> show configuration security zones security-zone web-dmz
address-book {
    address web1 172.31.100.60/32;
    address web2 172.31.100.61/32;
    address-set web-servers {
        address web1;
        address web2;
    }
}

Service Configuration

The next object to configure in our policy structure is the application (or service, as it was previously known in ScreenOS). Applications are used in policy to state how the source and destination can talk to each other, with some examples including HTTP, SSH, DNS, and SIP.

The SRX comes with a large list of preconfigured applications with much of the hard work already done. The protocol, source port, destination port, and other values have already been configured. All we need to do is to assign it to a policy.

These predefined applications start with junos-. To view a list of the predefined services use the show configuration groups junos-defaults applications command:

juniper@SRX5800> show configuration groups junos-defaults applications
#
# File Transfer Protocol
#
application junos-ftp {
    application-protocol ftp;
    protocol tcp;
    destination-port 21;
}
#
# Trivial File Transfer Protocol
#
application junos-tftp {
    application-protocol tftp;
    protocol udp;
    destination-port 69;
}
#
# Real Time Streaming Protocol
#
application junos-rtsp {
    application-protocol rtsp;
    protocol tcp;
    destination-port 554;

To view the details of a specific application use the syntax show configuration groups junos-defaults applications application junos-<application name>:

juniper@SRX5800> show conf groups junos-defaults app app junos-telnet
protocol tcp;
destination-port 23;

Much like address-books and address-sets, it is also possible to configure application-sets. This is a useful feature that replaces the need to write the same policy again and again just to permit a single additional service. Here’s a web-management application-set that allows the network administrator to manage the servers on web-dmz:

juniper@SRX5800> edit applications application-set
Entering configuration mode
[edit applications application-set]
juniper@SRX5800# set web_mgt application junos-ssh
[edit applications application-set]
juniper@SRX5800# set web_mgt application junos-ping

[edit applications application-set]
juniper@SRX5800# set web_mgt application junos-pc-anywhere

The application-set web_mgt has been created and then configured for SSH, ping, and pcAnywhere as a part of that web management group.

If there is a custom program on the network, or perhaps an application isn’t already configured on the SRX, it’s easy to create a custom application. Say the local system administrators don’t use pcAnywhere, but instead use a different remote access solution that goes over TCP port 4999. Now we’ll have to create a custom application for them to use.

You must configure the following items when configuring a custom application:

Application name

This is a label assigned to the custom application.

Protocol

This specifies what protocol is used: TCP, UDP, ICMP, and so on.

Source-port

This is the source port for the application. Keep in mind that most of the time the source port is a randomly assigned port between 1024 and 65535. Any is not an accepted configuration option; however, a range can be used.

Destination-port

This is the destination port or range.

Inactivity-timeout

This is how long the SRX will let the connection go idle before removing it from the session table. This value is configured in seconds and is optional. If you don’t configure a value, the default timeout for the protocol will apply. For TCP the default is 30 minutes, and for UDP it is 2 minutes.

Here is an example of a custom remote_mgt application created for the system administrators to access into their web servers. This application allows them to connect to TCP port 4999, and because no inactivity-timeout is configured, it’s automatically set for 30 minutes, the TCP default:

juniper@SRX5800> edit applications application
Entering configuration mode
[edit applications application]
juniper@SRX5800# set remote_mgt protocol tcp source-port 1024-65535
destination-port 4999

Now that the application has been configured, it’s time to create the policies for the web-dmz zone. The first policy to create is to allow system administrators on the Trust zone to manage the web servers on the web-dmz zone and log the traffic.

juniper@SRX5800# edit security policies from-zone trust to-zone web-dmz
[edit security policies from-zone trust to-zone web-dmz]
juniper@SRX5800# set policy webdmz_mgt match source-address any
destination-address web-servers application web_mgt
[edit security policies from-zone trust to-zone web-dmz]
juniper@SRX5800# set policy webdmz_mgt then permit
[edit security policies from-zone trust to-zone web-dmz]
juniper@SRX5800# set policy webdmz_mgt then log session-close session-init

Now let’s confirm the webdmz_mgt policy configuration:

juniper@SRX5800# show security policies from-zone trust to-zone web-dmz
policy webdmz_mgt {
    match {
        source-address any;
        destination-address web-servers;
        application web_mgt;
    }
    then {
        permit;
        log {
            session-init;
            session-close;
        }
    }
}

The next step is to set up access from the Internet zone to the web-dmz zone to allow users on the Internet to access the web servers via HTTP and keep statistics on the traffic:

juniper@SRX5800# edit security policies from-zone Internet to-zone web-dmz
[edit security policies from-zone Internet to-zone web-dmz]
juniper@SRX5800# set policy http-access match source-address any
destination-address web-servers application junos-http
[edit security policies from-zone Internet to-zone web-dmz]
juniper@SRX5800# set policy http-access then permit
[edit security policies from-zone Internet to-zone web-dmz]
juniper@SRX5800# set policy http-access then count

Keep in mind that, as stated earlier, unless something is explicitly permitted, it will be denied. So, there is no reason to write a deny when evaluating traffic from the Internet zone to the web-dmz zone, as only HTTP is permitted (as currently configured), unless you want to modify the deny policy for logging purposes:

juniper@SRX5800> show conf security policies from-zone Internet to-zone web-dmz
policy http-access {
    match {
        source-address any;
        destination-address web-servers;
        application junos-http;
    }
    then {
        permit;
        count;
    }
}

To recap what we have done so far, we created a new zone named web-dmz; assigned two web server addresses to the web-servers address-set; created an application-set called web_mgt for system administrator access; and wrote a policy between both the Internet zone and the web-dmz zone for HTTP access in addition to a policy between the Trust zone and the web-dmz zone for management. Figure 4-3 shows that user Dept-A can now connect to the web application servers.

Dept-A data path to web servers

Figure 4-3. Dept-A data path to web servers

Blocking Unwanted Traffic

The next thing we need to do as we explore our sample policy structure is to deny unwanted outbound traffic from the users zone. In cases of Trust to Untrust, there is a default permit. Network operators may wish to block undesired programs and protocols from being used on the network using this default permit, such as instant messaging clients, outbound email (with the exception of email going through the corporate email servers), and many popular P2P applications. In this type of situation, we would need to explicitly block them.

Let’s configure the SRX to block some of these services per the Campus Core’s Internet access policy. The goal is to have the SRX silently deny all of these applications, as shown in Figure 4-4.

Blocking unwanted traffic with the SRX

Figure 4-4. Blocking unwanted traffic with the SRX

Let’s start our configuration:

juniper@SRX5800# edit applications application-set
[edit applications application-set]
juniper@SRX5800# set deny_services application junos-ymsg
[edit applications application-set
juniper@SRX5800# set deny_services application junos-smtp
[edit applications application-set
juniper@SRX5800# set deny_services application junos-msn
[edit applications application-set
juniper@SRX5800# set deny_services application junos-irc
[edit applications application-set
juniper@SRX5800# set deny_services application junos-gnutella
[edit applications application-set
juniper@SRX5800# set deny_services application junos-aol

Now, we’ll create an open policy that applies to everyone going to any destination (any source to any destination):

juniper@SRX5800# edit security policies from-zone trust to-zone Internet
[edit security policies from-zone trust to-zone Internet]
juniper@SRX5800# set policy denied_apps match source-address any
destination-address any application deny_services

When blocking traffic on the SRX you have a couple of options that are very different in terms of how they go about dropping traffic:

deny

The deny flag will silently drop the connection. The packet is dropped and logged (if configured to do so).

reject

The reject flag has a key difference from the deny flag. Although reject drops the packet and logs (if configured to do so), it will also send an ICMP Port Unreachable packet to the initiating source for every packet that is rejected. This is used to inform the end host that the traffic was dropped.

Obviously, you must be careful with the reject flag because a large number of rejected packets could cause the SRX’s performance to degrade due to flooding ICMP messages. In nearly all cases, the authors of this book highly recommend using deny instead of reject. For the same reason as the zone TCP-RST configuration, policies configured with reject could allow for malicious users to notice the SRX on your network and assist in mapping out your security policies. With that in mind, let’s proceed with our blocking traffic policy:

[edit security policies from-zone trust to-zone Internet]
juniper@SRX5800# set policy denied_apps then deny log session-close session-init

Now let’s confirm the deny policy’s configuration:

juniper@SRX5800# show security policies from-zone trust to-zone Internet
policy denied_apps
match {
    source-address any;
    destination-address any;
    application deny_services;
}
then {
    deny;
    log {
        session-init;
        session-close;
    }
}

Always remember to evaluate policy ordering—since the policy that was just created is after the permit-any policy it must be moved before the permit-any policy to take effect. To do this use the insert command and insert denied_apps before default-permit:

[edit]
juniper@SRX5800# insert security policies from-zone trust to-zone Internet
policy denied_apps before policy default-permit

A quick confirmation shows that the policies are in the correct order:

juniper@SRX5800> show security policies from-zone trust to-zone Internet
From zone: trust, To zone: Internet
  Policy: denied_apps, State: enabled, Index: 13, Sequence number: 1
    Source addresses: any
    Destination addresses: any
    Applications: deny_services
    Action: deny, log
  Policy: default-permit, State: enabled, Index: 5, Sequence number: 2
    Source addresses: any
    Destination addresses: any
    Applications: any
    Action: permit
  Policy: protect_inside_users, State: enabled, Index: 6, Sequence number: 3
    Source addresses: inside-users
    Destination addresses: bad_hosts
    Applications: any
    Action: deny

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