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.

SRX Policy Processing

In step 4 of Figure 4-1’s illustrated SRX packet flow, the SRX builds a list of configured policies and the order in which they are processed. When the network security process determines a source and destination zone, the SRX evaluates only those policies configured between those two zones and continues to evaluate them (in a top-down order) until a matching condition is found, as shown in Figure 4-2. As the network security process evaluates an incoming packet, if a matching policy is found no further policies will be evaluated.

SRX policy processing
Figure 4-2. SRX policy processing

There are two important things to note in the SRX policy process shown in Figure 4-2. First, not all configured policies are evaluated when the SRX does its policy processing. Only the policies that have been configured between the matching from-zone to-zone are evaluated. Second, the policy tables are evaluated in a top-down fashion, which means the order of your policies is very important. When the SRX finds a matching policy it takes whatever action that policy has.

Let’s look at an example of a configuration error that has not taken into account the fact that the policies are evaluated in a top-down fashion:

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;
        }
    }
    policy protect_inside_users {
        match {
            source-address inside-users;
            destination-address bad_hosts;
            application any;
        }
        then {
            deny;
        }
    }
}

When read, the first policy to be evaluated is permitting inside-users to connect to any address using any application, and the second policy that is evaluated is to keep the inside-users from connecting to a list of known, bad hosts, but it is after the permit policy. So, in this instance, when the SRX does its policy lookup, the second policy never gets hit and the inside-users network is never protected from accessing those bad hosts.

Note

For legacy ScreenOS users, it’s important to note that there is no global security policy in the SRX policy system today. This means you cannot write global policies that apply to all zones.

We will discuss proper policy processing throughout this chapter. It really is key to establishing secure and efficient premises, and it depends on how you create the policies. The SRX will do exactly what you tell it to do. Now that we’ve briefly discussed what a security policy is and how the SRX handles its processing let’s take a look at some real policy tables.

Note

A helpful tip that catches many users is where Network Address Translation (NAT) is applied and how that relates to policy. Destination NAT is applied before the policy lookup takes place, and source NAT is applied after. That means when you are configuring policies you must ensure that if a destination NAT is configured, the security policies are using the new NATed address instead of the nontranslated original address.

Viewing SRX Policy Tables

Within the SRX there are multiple ways to view the details of the configured security policies and their order. While viewing the security policies you can issue the optional detail command at the end of any policy lookup. The detail switch gives you additional information regarding the security policies, such as their address books and applications.

Before using the detail command, let’s look at example output that shows how to view all configured security policies using the show security policies command:

juniper@SRX5800> show security policies
Default policy: deny-all
From zone: trust, To zone: trust
  Policy: default-permit, State: enabled, Index: 4, Sequence number: 1
    Source addresses: any
    Destination addresses: any
    Applications: any
    Action: permit
From zone: trust, To zone: Internet
  Policy: default-permit, State: enabled, Index: 5, Sequence number: 1
    Source addresses: any
    Destination addresses: any
    Applications: any
    Action: permit
  Policy: protect_inside_users, State: enabled, Index: 7, Sequence number: 2
    Source addresses: inside-users
    Destination addresses: bad_hosts
    Applications: any
    Action: deny
From zone: Internet, To zone: trust
  Policy: default-deny, State: enabled, Index: 6, Sequence number: 1
    Source addresses: any
    Destination addresses: any
    Applications: any
    Action: deny

Note

Did you notice in the preceding output that this SRX is configured with a default policy of deny-all, meaning that it will deny all traffic by default? Policies must be written to allow traffic to pass between the security zones.

By default, there are two configured policies: the default-permit from Trust to Internet and the default-deny from Internet to Trust. Any additional behaviors must be configured to block or permit the desired traffic. Remember, if additional access is needed from the Internet zone to the Trust zone when a new security policy is configured, it must be placed before the default-deny. The order of policies is very important.

Now, let’s get more information by adding detail at the end of the command:

juniper@SRX5800> show security policies detail
Default policy: deny-all
Policy: default-permit, action-type: permit, State: enabled, Index: 4
  Sequence number: 1
  From zone: trust, To zone: trust
  Source addresses:
    any: 0.0.0.0/0
  Destination addresses:
    any: 0.0.0.0/0
  Application: any
    IP protocol: 0, ALG: 0, Inactivity timeout: 0
      Source port range: [0-0]
      Destination port range: [0-0]
Policy: default-permit, action-type: permit, State: enabled, Index: 5
  Sequence number: 1
  From zone: trust, To zone: Internet
  Source addresses:
    any: 0.0.0.0/0
  Destination addresses:
    any: 0.0.0.0/0
  Application: any
    IP protocol: 0, ALG: 0, Inactivity timeout: 0
      Source port range: [0-0]
      Destination port range: [0-0]

Here the show security policies detail command displays a lot more information than what we saw in the previous output. Now, the true source/destination address IPs are displayed as any, or 0.0.0.0/0, and the application port ranges and protocols are listed.

Instead of viewing all policies configured on the SRX, it is often easier to view policies between two specific zones by using the additional command options from-zone <zone> to-zone <zone>:

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

In this example output of only the security policies between the Trust and Internet zones, you should notice that the policies are still out of order, and that the protect_inside_users policy is still after the default-permit policy. We’ll fix this later in the chapter.

Another way to view a specific policy instead of looking at a large list is to view it by policy-name. The policy-name option shows only that specific policy and provides you with the same level of information as the previous examples, if the name of the policy is already known (in our case it’s protect_inside_users). In this example, the detail command has been used to provide further information about the protect_inside_users policy:

juniper@SRX5800> show security policies policy-name protect_inside_users detail
Policy: protect_inside_users, action-type: deny, State: enabled, Index: 7
  Sequence number: 2
  From zone: trust, To zone: Internet
  Source addresses:
    inside-users: 10.1.1.0/24
  Destination addresses:
    bad_hosts: 198.133.219.25/32
  Application: any
    IP protocol: 0, ALG: 0, Inactivity timeout: 0
      Source port range: [0-0]
      Destination port range: [0-0]

Viewing Policy Statistics

To enable policy statistics the then action must include the count flag. The count statement then enables counters for the specific policy.

Here, count is added to default-deny from Internet to Trust:

juniper@SRX5800# edit security policies from-zone Internet to-zone trust
[edit security policies from-zone Internet to-zone trust]
juniper@SRX5800# set policy default-deny then count

The configuration ends up looking like this:

juniper@SRX5800> show conf security policies from-zone Internet to-
zone trust
policy default-deny {
    match {
        source-address any;
        destination-address any;
        application any;
    }
    then {
        deny;
        count;
    }
}

Notice that both the then action and the count action are deny. This tells the SRX to keep track of statistics on this policy.

Note

You must configure counting directly on each policy on which counting is needed.

Now, when the policy is viewed, new statistics are shown:

juniper@SRX5800> show security policies policy-name default-deny detail
Policy: default-deny, action-type: deny, State: enabled, Index: 6
  Sequence number: 1
  From zone: Internet, To zone: trust
  Source addresses:
    any: 0.0.0.0/0
  Destination addresses:
    any: 0.0.0.0/0
  Application: any
    IP protocol: 0, ALG: 0, Inactivity timeout: 0
      Source port range: [0-0]
      Destination port range: [0-0]
  Policy statistics:
    Input  bytes     :              200               5 bps
    Output bytes     :              500               10 bps
    Input  packets   :              23               2 pps
    Output packets   :              45               4 pps
    Session rate     :              3               1 sps
    Active sessions  :              2
    Session deletions:              1
    Policy lookups   :              3

Notice that the input/output rates are shown, as well as the session ramp rate. The session ramp rate is the number of sessions per second (sps in the preceding output) that the SRX has handled as a result of this policy.

Policy counters allow for much more visibility into the details of a policy, but do proceed with caution. Policy counters can add a bit of overhead to the policy processing, and if the device is a lower-end SRX it might be wise to limit the number of policies that have counters enabled to only those that are truly needed. On the higher-end models, policy counters will add a minor amount of overhead, but it is much less noticeable.

To reset policy counters back to zero use the clear security policies statistics command.

It’s also possible to set alarms based upon predefined traffic count thresholds so that if the number of policy hits exceeds your preconfigured kilobytes-per-minute or bytes-per-second threshold, the SRX can send an alarm or, if an event script is written, take an advanced next-step action such as adding a firewall filter or access control list (ACL) to block the host.

Note

An event script is an automated script that runs directly on the SRX when triggered by a certain event or log. Event scripts are outside the scope of this book. For more information about event scripts, visit http://www.juniper.net/techpubs/.

The code to configure thresholds and alarm for a policy looks something like this:

juniper@SRX5800# edit security policies from-zone Internet to-zone trust
[edit security policies from-zone Internet to-zone trust]
juniper@SRX5800# set policy default-deny then count alarm per-minute-threshold 100

The configuration will look something like this:

juniper@SRX5800# show security policies from-zone Internet to-zone trust
policy default-deny {
    match {
        source-address any;
        destination-address any;
        application any;
    }
    then {
        deny;
        count {
            alarm per-minute-threshold 100;
        }
    }
}

Note

It’s also possible to alarm the local log or an external logging device such as the Network and Security Manager (NSM), a syslog server, or a Simple Network Management Protocol (SNMP) collector on both permit and deny policies on a kilobytes-per-minute or bytes-per-second basis.

Viewing Session Flows

Once traffic has gone through the SRX packet flow, and assuming that the traffic has been permitted, the details of that session go into the SRX’s session table. The session table is a real-time list of current sessions going through the SRX. Only connections that are active or haven’t been timed out show up in the session table.

One very important thing to note is that if a flow is in the session table, it has already been permitted by policy and the session has been created—the SRX has allowed this connection and all return traffic for this flow to pass through. At this point, the SRX is only doing some minor checks via the fast path, as we saw in Figure 4-1 earlier in this chapter.

Here’s an example of what a session looks like:

juniper@SRX5800> show security flow session
Session ID: 4785, Policy name: default-permit/1, Timeout: 1800
  In: 10.10.1.1/49229 --> 10.1.1.254/23;tcp, If: ge-0/0/0.0
  Out: 10.1.1.254/23 --> 10.10.1.1/49229;tcp, If: ge-0/0/1.0

You can learn a lot of useful information about this short session:

  • The policy name that allowed this traffic is default-permit.

  • The timeout is 1,800 seconds or 30 minutes; 30 minutes is the default timeout for TCP traffic.

  • Both the source IP, 10.10.1.1, and the destination IP, 10.1.1.254, are shown with their respective source/destination ports, and the session is TCP port 23 or Telnet.

  • The source interface is ge-0/0/0.0 and the destination interface for this session is ge-0/0/1.0.

To view the session table at a higher level you would use the summary command, which gives a breakdown of the different types of sessions and how many sessions there are:

juniper@SRX5800> show security flow session summary
Session summary:
  Unicast-sessions: 20
  Multicast-sessions: 0
  Failed-sessions: 0
  Sessions-in-use: 20
  Maximum-sessions: 65536

Be aware that session tables are often quite large, with thousands or even millions of sessions at any given time. Even so, the ability to search through the session table is extremely important, and Juniper has added some great filters to assist with this. As always, use the question mark (?) in the command-line interface (CLI) to show the list of possible options, as shown in the following output:

juniper@SRX5800> show security flow session ?
Possible completions:
  <[Enter]>            Execute this command
  application          Show session for specified application or application set
  destination-port     Show each session that uses specified destination port
  destination-prefix   Show each session that matches destination prefix
  idp                  Show IDP sessions
  interface            Show each session that uses specified interface
  protocol             Show each session that uses specified IP protocol
  resource-manager     Show resource-manager sessions
  session-identifier   Show session with specified session identifier
  source-port          Show each session that uses specified source port
  source-prefix        Show each session that matches source prefix
  summary              Show summary of sessions
  tunnel               Show tunnel sessions
  |                    Pipe through a command

Note

Keep in mind that you can apply multiple filters to the search.

Another feature that has been added in Junos but was not available in ScreenOS is the ability to not only search by a source IP or destination IP, but also by an entire subnet.

This is important because it enables you to search for all traffic coming from or going to an entire subnet:

juniper@SRX5800> show security flow session destination-prefix 10.1.1/24
Session ID: 4785, Policy name: default-permit/1, Timeout: 1800
  In: 10.10.1.1/49229 --> 10.1.1.254/23;tcp, If: ge-0/0/0.0
  Out: 10.1.1.254/23 --> 10.10.1.1/49229;tcp, If: ge-0/0/1.0
Session ID: 4787, Policy name: default-permit/1, Timeout: 1800
  In: 10.10.1.5/49131 --> 10.1.1.254/23;tcp, If: ge-0/0/0.0
  Out: 10.1.1.254/23 --> 10.10.1.5/49131;tcp, If: ge-0/0/1.0
2 sessions displayed

In the following example, we are filtering the session table by destination-port 23 or Telnet:

juniper@SRX5800> show security flow session destination-port 23
Session ID: 4785, Policy name: default-permit/1, Timeout: 1800
  In: 10.10.1.1/49229 --> 10.1.1.254/23;tcp, If: ge-0/0/0.0
  Out: 10.1.1.254/23 --> 10.10.1.1/49229;tcp, If: ge-0/0/1.0
Session ID: 4787, Policy name: default-permit/1, Timeout: 1800
  In: 10.10.1.5/49131 --> 10.1.1.254/23;tcp, If: ge-0/0/0.0
  Out: 10.1.1.254/23 --> 10.10.1.5/49131;tcp, If: ge-0/0/1.0
2 sessions displayed

And finally, here’s how you can apply multiple filters to filter the session output even further. In the following output, two filters have been applied: the source-prefix filter and the destination port filter. This snippet shows only the sessions that match both of these requirements:

juniper@SRX5800> show security flow sess source-prefix 10.10.1.5
destination-port 23
Session ID: 4787, Policy name: default-permit/1, Timeout: 1800
  In: 10.10.1.5/49131 --> 10.1.1.254/23;tcp, If: ge-0/0/0.0
  Out: 10.1.1.254/23 --> 10.10.1.5/49131;tcp, If: ge-0/0/1.0
1 sessions displayed

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

Policy Logging

We briefly covered policy logging from a configuration standpoint earlier in this chapter. Here we’ll discuss the details of policy logging and how to configure and view the logs.

Note

For legacy NetScreen readers, policy logging is very different on the SRX. The logging system is more of a local syslog server than the traditional traffic log found on NetScreen devices, and nearly everything that could be done with the ScreenOS traffic logs can be done on the SRX’s logfiles.

To log on the SRX you must configure the following two items:

  • Policy logging must be enabled on the policy via the session-init and session-close configuration items.

  • A filter and traffic logfile must be created on the SRX.

First, to enable policy logging, configure log session-close session-init on the specific policy on which logging is desired. The session-close flag tells the SRX to log whenever it tears down a session’s connection (a session could close for many reasons, including a timeout, a FIN packet, or an RST packet). The session-init flag tells the SRX to log traffic for that policy when a session is built.

Here’s an example of a policy with logging enabled (that was actually configured earlier in the chapter). This example policy logs both the creation and the teardown of these connections and works on policies that permit traffic as well as policies that deny traffic:

[edit]
juniper@SRX5800# set security policies from-zone trust to-zone web-dmz
policy webdmz_mgt then log session-close session-init

The next item we need to configure is a location for the traffic logs to go to. You can name the traffic logfile whatever you want, although it’s always best to give the log a descriptive name, such as traffic-log or policy-log, just so other users know where to look for the logs.

Here the traffic logfile is called traffic-log. The second line of the config tells the SRX to send all traffic matching RT_FLOW_SESSION, which is a string that shows up in the policy messages:

[edit]
juniper@SRX5800# set system syslog file traffic-log any any
juniper@SRX5800# set system syslog file traffic-log match "RT_FLOW_SESSION"

Now, to view the traffic logs, use the show log <filename> command to display the entire traffic log:

juniper@SRX5800> show log traffic-log
Jan  7 12:07:24  SRX5800 RT_FLOW: RT_FLOW_SESSION_CREATE: session created
10.1.1.100/53910->172.31.100.60/22 junos-ssh
10.1.1.100/53910->172.31.100.60/22 None None 6 webdmz_mgt trust web-dmz 59
Jan  7 12:07:25  SRX5800 RT_FLOW: RT_FLOW_SESSION_CLOSE: session closed TCP RST:
10.1.1.100/53908->172.31.100.60/22 junos-ssh 10.1.1.100/53908->172.31.100.60/22
None None 6 webdmz_mgt trust web-dmz 57 1(64) 1(40) 3

Here is a detailed breakdown of the different types of messages, followed by an example (borrowed from the SRX documentation):

Session creation

<source-address>/<source-port>-><destination-address>/<destination-port>,<protocol-id>: <policy-name>

RT_FLOW_SESSION_CREATE: session created 10.1.1.100/53908->172.31.100.60/22 junos-
ssh 10.1.1.100/53908->172.31.100.60/22 None None 6 webdmz_mgt trust web-dmz 57
Session close

session closed <reason>: <source-address>/<source-port>-><destination-address>/<destination-port>,<protocol-id>:<policy-name>, <inbound-packets>, <inbound-bytes>,<outbound-bytes> <elapsed-time>

RT_FLOW_SESSION_CLOSE: session closed TCP RST: 10.1.1.100/53907->172.31.100.60/22
junos-ssh 10.1.1.100/53907->172.31.100.60/22 None None 6 webdmz_mgt trust web-dmz
56 1(64) 1(40) 2
Session deny

session denied <source-address>/<source-port>-><destination-address>/<destination-port>,<protocol-id>(<icmp-type>):<policy-name>

RT_FLOW_SESSION_DENY: session denied 10.1.1.100/2->10.2.0.254/25931 icmp 1(8)
web_deny trust web-dmz

There are no built-in filters, as there were on the NetScreen platform. Instead, the SRX has some very powerful methods for filtering the displayed data that are built into the Junos operating system. Although a deep dive into all of the different filter options is outside the scope of this chapter, let’s cover a few ways to filter through the traffic log. Just remember, this is only a small sample of what’s possible.

The simplest way to filter the traffic log (or any syslog file, for that matter) is to use the | match <data> command, which filters the output to only that which matches the data that was input:

juniper@SRX5800> show log traffic-log | match 3389
Jan  7 12:06:38  SRX5800 RT_FLOW: RT_FLOW_SESSION_CREATE: session created
10.1.1.100/53904->172.31.100.60/3389 None 10.1.1.100/53904->172.31.100.60/
3389 None None 6 webdmz_mgt trust web-dmz 49

In this example, the match condition was 3389 (in this case, a port for Windows Remote Desktop). The match command is very powerful, and even allows for regular-expression-type searches, such as this match filter matching on the string 3389 OR 22:

juniper@SRX5800> show log traffic-log | match "3389|22"
Jan  7 12:06:38  SRX5800 RT_FLOW: RT_FLOW_SESSION_CREATE: session created
10.1.1.100/53904->172.31.100.60/3389 None 10.1.1.100/53904->172.31.100.60/
3389 None None 6 webdmz_mgt trust web-dmz 49
Jan  7 12:07:22  SRX5800 RT_FLOW: RT_FLOW_SESSION_CREATE: session created
10.1.1.100/53907->172.31.100.60/22 junos-ssh 10.1.1.100/53907->172.31.100.60/22
None None 6 webdmz_mgt trust web-dmz 56
Jan  7 12:07:23  SRX5800 RT_FLOW: RT_FLOW_SESSION_CREATE: session created
10.1.1.100/53908->172.31.100.60/22 junos-ssh 10.1.1.100/53908->172.31.100.60/22
None None 6 webdmz_mgt trust web-dmz 57

Additional methods for viewing the traffic log include the ability to do a Unix-tail-type command. For example, the last command displays the last X number of lines. Here, the last filter is used to display only the last two lines of the traffic log:

juniper@SRX5800> show log traffic-log | last 2
Jan  7 12:07:25  SRX5800 RT_FLOW: RT_FLOW_SESSION_CLOSE: session closed TCP RST:
10.1.1.100/53909->172.31.100.60/22 junos-ssh 10.1.1.100/53909->172.31.100.60/22
None None 6 webdmz_mgt trust web-dmz 58 1(64) 1(40) 2
Jan  7 12:07:25  SRX5800 RT_FLOW: RT_FLOW_SESSION_CLOSE: session closed TCP RST:
10.1.1.100/53910->172.31.100.60/22 junos-ssh 10.1.1.100/53910->172.31.100.60/22
None None 6 webdmz_mgt trust web-dmz 59 1(64) 1(40) 1

Keep in mind that you can use multiple pipe filters together to form powerful commands. For example, if your goal is to determine how many times a certain IP, or segment, showed up in the traffic log, you could use a combination of match and count:

juniper@SRX5800> show log traffic-log | match 172.31.100.60 | count
Count: 13 lines

In the preceding output, 172.31.100.60 shows up 13 times in the traffic log.

You also can see what the firewall has dropped. Assuming that logging has been enabled on the deny policy, a simple filter on deny shows dropped traffic:

juniper@SRX5800> show log traffic-log | match DENY
Jan  7 12:07:05  SRX5800 RT_FLOW: RT_FLOW_SESSION_DENY: session denied
10.1.1.100/53906->172.31.100.60/21 junos-ftp 6(0) web_deny trust web-dmz
Jan  7 12:07:06  SRX5800 RT_FLOW: RT_FLOW_SESSION_DENY: session denied
10.1.1.100/53906->172.31.100.60/21 junos-ftp 6(0) web_deny trust web-dmz
Jan  7 12:07:11  SRX5800 RT_FLOW: RT_FLOW_SESSION_DENY: session denied
10.1.1.100/0->10.2.0.254/25931 icmp 1(8) web_deny trust web-dmz
Jan  7 12:07:12  SRX5800 RT_FLOW: RT_FLOW_SESSION_DENY: session denied
10.1.1.100/1->10.2.0.254/25931 icmp 1(8) web_deny trust web-dmz
Jan  7 12:07:13  SRX5800 RT_FLOW: RT_FLOW_SESSION_DENY: session denied
10.1.1.100/2->10.2.0.254/25931 icmp 1(8) web_deny trust web-dmz

It is also possible to log the policy denies to their own logfile—for example, if you wish to keep a separate copy of dropped traffic. You can do this by creating a new logfile and adjusting the match condition:

[edit]
juniper@SRX5800# set system syslog file traffic-deny any any
[edit]
juniper@SRX5800# set system syslog file traffic-deny match "RT_FLOW_SESSION_DENY"

A helpful trick to make it easier to troubleshoot traffic when a lot of data is going to the traffic logfile is to filter with more specific matching conditions. For example, if we were troubleshooting connectivity to 172.31.100.60, or wanted to log that specific traffic to a different logfile for later evaluation, we could filter only that traffic to a different file. Here, 172.31.100.60 is filtered to a new logfile called troubleshooting_traffic:

[edit]
juniper@SRX5800# set system syslog file troubleshooting_traffic any any
[edit]
juniper@SRX5800# set system syslog file troubleshooting_traffic match
"172.31.100.60"

Now, it’s possible to view the traffic log for just 172.31.100.60:

juniper@SRX5800> show log troubleshooting_traffic
Jan 7 12:24:42 SRX5800 clear-log[1377]: logfile cleared
Jan  7 12:24:46  SRX5800 RT_FLOW: RT_FLOW_SESSION_CREATE: session created
10.1.1.100/53989->172.31.100.60/22 junos-ssh 10.1.1.100/53989->172.31.100.60/22
None None 6 webdmz_mgt trust web-dmz 91
Jan  7 12:24:47  SRX5800 RT_FLOW: RT_FLOW_SESSION_CLOSE: session closed TCP RST:
10.1.1.100/53989->172.31.100.60/22 junos-ssh 10.1.1.100/53989->172.31.100.60/22
None None 6 webdmz_mgt trust web-dmz 91 1(64) 1(40) 2

Once you get the hang of it, you’ll see that there are many ways to filter out and count the data in logfiles using various commands. We’ve just scratched the surface here. Use the CLI question mark (?) to display all the different command possibilities:

juniper@SRX5800> show log troubleshooting_traffic | ?
Possible completions:
  count                Count occurrences
  display              Show additional kinds of information
  except               Show only text that does not match a pattern
  find                 Search for first occurrence of pattern
  hold                 Hold text without exiting the --More-- prompt
  last                 Display end of output only
  match                Show only text that matches a pattern
  no-more              Don't paginate output
  request              Make system-level requests
  resolve              Resolve IP addresses
  save                 Save output text to file
  trim                 Trim specified number of columns from start of line

Oops, I almost forgot to mention another very useful feature, the monitor command. Use the monitor command so that the SRX displays the output of the traffic log in real time to the console. It’s very useful when troubleshooting or evaluating traffic.

juniper@SRX5800> monitor start traffic-log

Then, as data is written to the traffic logfile, it’s displayed to the console. Use the monitor stop command to turn off the monitoring:

juniper@SRX5800>
*** traffic-log ***
Jan  7 12:07:13  SRX5800 RT_FLOW: RT_FLOW_SESSION_DENY: session denied
10.1.1.100/2->10.2.0.254/25931 icmp 1(8) web_deny trust web-dmz

Note

On the high-end lines such as the SRX5800 a limited amount of logging is available to the local logs. There simply isn’t enough disk space or processing to log the high rate of sessions that the high-end SRX devices are capable of handling. Logging to the local disk should be limited on these platforms to only critical policies.

Troubleshooting Security Policy and Traffic Flows

In most cases, simple policy logging of the traffic that is being denied and permitted is sufficient to verify what the SRX is doing with the data. However, in some instances more information is needed. On the NetScreen platform this information was gained via debugs, typically via debug flow basic. Juniper has taken into account how often debugs are used when troubleshooting traffic flows, in addition to policies, and has improved on this feature with traceoptions.

Within traceoptions you can accomplish the equivalent of a “debug flow basic” via basic-datapath traceoption. Traceoptions monitor and log traffic flows going into and out of the SRX and, much like the NetScreen debugs, filters tend to be very resource-intensive. The authors of this book highly suggest that when you use traceoptions you always have a packet filter set, and that the packet filter is as specific as possible to avoid any adverse system impacts.

Note

Unlike on the NetScreen platform, on the SRX you can configure only one expression per packet filter. To examine bidirectional communication you need multiple packet filters, one for each direction.

Troubleshooting Sample

Our sample problem is as follows: while configuring a new web server, users are complaining that they cannot access the website. It has already been confirmed that policy is written correctly and traffic logs session initiation. It’s all shown somewhat briefly in Figure 4-5.

The source is 10.1.1.100, a local workstation on the Trust zone in Dept-A via port ge-0/0/0.0.

The destination is 10.2.0.3, a new web server on the web-dmz zone via port fe-0/0/2.0.

Sample problem showing users unable to access the website
Figure 4-5. Sample problem showing users unable to access the website

The first thing we should do is to configure a logfile for the traceoption output. We can do this using the file <file_name> command. Here, the output file is named tshoot_web:

juniper@SRX5800# edit security flow traceoptions
[edit security flow traceoptions]
juniper@SRX5800# set file tshoot_web

Next we need to set the filters. It’s worth noting that nothing takes effect until the configuration is committed, so it’s perfectly safe to change the order in which these items are configured:

[edit security flow traceoptions]
juniper@SRX5800# set packet-filter trust_to_web source-prefix 10.1.1.100/32
destination-prefix 10.2.0.3/32
[edit security flow traceoptions]
juniper@SRX5800# set packet-filter web_to_trust source-prefix 10.2.0.3/32
destination-prefix 10.1.1.100/32

Note

In the preceding output, two packet filters have been configured. The first filter is for 10.1.1.100 to 10.2.0.3 and the second filter is for the reverse traffic flow 10.2.0.3 talking to 10.1.1.100.

The last item we need to configure is the actual traceoption flag. Here, it is basic-datapath, as this should give us all the information we need:

[edit security flow traceoptions]
juniper@SRX5800# set flag basic-datapath

If you haven’t heard it before, it’s always wise to review the configuration before applying:

juniper@SRX5800# show security flow traceoptions
file tshoot_web;
flag basic-datapath;
packet-filter trust_to_web {
    source-prefix 10.1.1.100/32;
    destination-prefix 10.2.0.3/32;
}
packet-filter web_to_trust {
    source-prefix 10.2.0.3/32;
    destination-prefix 10.1.1.100/32;
}
[edit]

The output of the config looks correct. All of the required configuration options are there: a traceoptions file, a traceoptions flag, and two packet filters for bidirectional traffic. Since everything looks OK, we can commit the configuration and the workstation can initiate some traffic so that we can monitor it. Once the test traffic has been completed, all the data to troubleshoot our problem should be in the tshoot_web traceoptions file.

Note

The output contains a lot of detailed information regarding what the SRX is doing with the packet as it passes through its hardware and does its series of checks, and the reality is that you can overlook much of this information in the output because it’s for developers who are troubleshooting and does not apply to what you need to know. Also, the traceoptions output will likely change over the printed lifetime of this book, as the developers add and remove information.

Troubleshooting Output

The output of the packet’s details is shown in its entirety in Example 4-1. Look through it and then we’ll break down what each portion means or does and what we can overlook.

This output is from a single first packet as it enters the SRX in our troubleshooting scenario (see Figure 4-5).

Example 4-1. Output of the packet’s details, in its entirety
juniper@SRX5800> show log tshoot_web
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:<10.1.1.100/51510-
>10.2.0.3/80;6> matched filter trust_to_web:
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:packet [48] ipid = 57203,
@423f6b9e
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:---- flow_process_pkt: (thd
1): flow_ctxt type 13, common flag 0x0, mbuf 0x423f6a00
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT: flow process pak fast ifl
68 in_ifp ge-0/0/0.0
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:  ge-
0/0/0.0:10.1.1.100/51510->10.2.0.3/80, tcp, flag 2 syn
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT: find flow: table
0x4d5c8238, hash 1430(0xffff), sa 10.1.1.100, da 10.2.0.3, sp 51510,
dp 80, proto 6, tok 384
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:  no session found, start
first path. in_tunnel - 0, from_cp_flag - 0
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:  flow_first_create_session
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:  flow_first_in_dst_nat: in
<ge-0/0/0.0>, out <N/A> dst_adr 10.2.0.3, sp 51510, dp 80
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:  chose interface ge-
0/0/0.0 as incoming nat if.
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:flow_first_rule_dst_xlate:
DST no-xlate: 0.0.0.0(0) to 10.2.0.3(80)
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:flow_first_routing: call
flow_route_lookup(): src_ip 10.1.1.100, x_dst_ip 10.2.0.3, in ifp ge-
0/0/0.0, out ifp N/A sp 51510, dp 80, ip_proto 6, tos 0
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:Doing DESTINATION addr
route-lookup
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:  routed (x_dst_ip
10.2.0.3) from trust (ge-0/0/0.0 in 0) to ge-0/0/0.0, Next-hop:
10.1.1.1
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:  policy search from zone
trust-> zone trust
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:  app 6, timeout 1800s,
curr ageout 20s
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:flow_first_src_xlate:
10.1.1.100/51510 -> 10.2.0.3/80 | 10.2.0.3/80 -> 0.0.0.0/51510:
nat_src_xlated: False, nat_src_xlate_failed: False
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:flow_first_src_xlate: src
nat 0.0.0.0(51510) to 10.2.0.3(80) returns status: 0, rule/pool id:
0/0, pst_nat: False.
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:  dip id = 0/0,
10.1.1.100/51510->10.1.1.100/51510
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:flow_first_get_out_ifp:
1000 -> cone nat test
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:  choose interface ge-
0/0/0.0 as outgoing phy if
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:is_loop_pak: No loop: on
ifp: ge-0/0/0.0, addr: 10.2.0.3, rtt_idx:0
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:policy is NULL (wx/pim
scenario)
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:sm_flow_interest_check:
app_id 0, policy 4, app_svc_en 0, flags 0x2. not interested
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:sm_flow_interest_check:
app_id 1, policy 4, app_svc_en 0, flags 0x2. not interested
Jan 17 12:35:51 12:35:50.1249501:CID-
0:RT:flow_first_service_lookup(): natp(0x4b9f2198):
local_pak(0x3fdedc70.0x423f6a00):  TCP proxy NOT interested: 0.
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:  service lookup identified
service 6.
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:  flow_first_final_check:
in <ge-0/0/0.0>, out <ge-0/0/0.0>
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:  existing vector list 2-
446fe828.
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:  Session (id:9270) created
for first pak 2
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:
flow_first_install_session======> 0x4b9f2198
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT: nsp 0x4b9f2198, nsp2
0x4b9f2204
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:
make_nsp_ready_no_resolve()
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:  route lookup: dest-ip
10.1.1.100 orig ifp ge-0/0/0.0 output_ifp ge-0/0/0.0 orig-zone 6 out-
zone 6 vsd 0
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:  route to 10.1.1.100
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:Installing c2s NP session
wing
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:Installing s2c NP session
wing
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:  flow got session.
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:  flow session id 9270
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:  tcp flags 0x2, flag 0x2
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:  Got syn,
10.1.1.100(51510)->10.2.0.3(80), nspflag 0x1021, 0x20
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT:mbuf 0x423f6a00, exit nh
0x30010
Jan 17 12:35:51 12:35:50.1249501:CID-0:RT: ----- flow_process_pkt rc
0x0 (fp rc 0)

That’s a lot to digest. To make this easier (quicker) to read, a helpful tip is to use the trim command option. The trim command removes a specified number of characters. For instance, you can use it to remove the date and time to make the code a lot easier to read or fit on a screen. Example 4-2 shows the trace file trimmed. Trim 42 removes the date and time as well as the CID-0:RT:, leaving just the important data.

Example 4-2. Trimmed trace file
juniper@SRX5800> show log tshoot_web | trim 42
<10.1.1.100/51510->10.2.0.3/80;6> matched filter trust_to_web:
packet [48] ipid = 57203, @423f6b9e
---- flow_process_pkt: (thd 1): flow_ctxt type 13, common flag 0x0,
mbuf 0x423f6a00
 flow process pak fast ifl 68 in_ifp ge-0/0/0.0
  ge-0/0/0.0:10.1.1.100/51510->10.2.0.3/80, tcp, flag 2 syn
 find flow: table 0x4d5c8238, hash 1430(0xffff), sa 10.1.1.100, da
10.2.0.3, sp 51510, dp 80, proto 6, tok 384
  no session found, start first path. in_tunnel - 0, from_cp_flag - 0
  flow_first_create_session
  flow_first_in_dst_nat: in <ge-0/0/0.0>, out <N/A> dst_adr 10.2.0.3,
sp 51510, dp 80
  chose interface ge-0/0/0.0 as incoming nat if.
flow_first_rule_dst_xlate:  DST no-xlate: 0.0.0.0(0) to 10.2.0.3(80)
flow_first_routing: call flow_route_lookup(): src_ip 10.1.1.100,
x_dst_ip 10.2.0.3, in ifp ge-0/0/0.0, out ifp N/A sp 51510, dp 80,
ip_proto 6, tos 0
Doing DESTINATION addr route-lookup
  routed (x_dst_ip 10.2.0.3) from trust (ge-0/0/0.0 in 0) to ge-
0/0/0.0, Next-hop: 10.1.1.1
  policy search from zone trust-> zone trust
  app 6, timeout 1800s, curr ageout 20s
flow_first_src_xlate: 10.1.1.100/51510 -> 10.2.0.3/80 | 10.2.0.3/80 -
> 0.0.0.0/51510: nat_src_xlated: False, nat_src_xlate_failed: False
flow_first_src_xlate: src nat 0.0.0.0(51510) to 10.2.0.3(80) returns
status: 0, rule/pool id: 0/0, pst_nat: False.
  dip id = 0/0, 10.1.1.100/51510->10.1.1.100/51510
flow_first_get_out_ifp: 1000 -> cone nat test
  choose interface ge-0/0/0.0 as outgoing phy if
is_loop_pak: No loop: on ifp: ge-0/0/0.0, addr: 10.2.0.3, rtt_idx:0
policy is NULL (wx/pim scenario)
sm_flow_interest_check: app_id 0, policy 4, app_svc_en 0, flags 0x2.
not interested
sm_flow_interest_check: app_id 1, policy 4, app_svc_en 0, flags 0x2.
not interested
flow_first_service_lookup(): natp(0x4b9f2198):
local_pak(0x3fdedc70.0x423f6a00):  TCP proxy NOT interested: 0.
  service lookup identified service 6.
  flow_first_final_check: in <ge-0/0/0.0>, out <ge-0/0/0.0>
  existing vector list 2-446fe828.
  Session (id:9270) created for first pak 2
  flow_first_install_session======> 0x4b9f2198
 nsp 0x4b9f2198, nsp2 0x4b9f2204
  make_nsp_ready_no_resolve()
  route lookup: dest-ip 10.1.1.100 orig ifp ge-0/0/0.0 output_ifp ge-
0/0/0.0 orig-zone 6 out-zone 6 vsd 0
  route to 10.1.1.100
Installing c2s NP session wing
Installing s2c NP session wing
  flow got session.
  flow session id 9270
  tcp flags 0x2, flag 0x2
  Got syn, 10.1.1.100(51510)->10.2.0.3(80), nspflag 0x1021, 0x20
mbuf 0x423f6a00, exit nh 0x30010
 ----- flow_process_pkt rc 0x0 (fp rc 0)

Now, let’s analyze the data from the traceoption’s output shown in Example 4-2.

The first line, shown here, displays the source IP 10.1.1.100 and destination IP 10.2.0.3, as well as the ports used to communicate. It then documents that this traffic matched the trust_to_web traceoptions filter.

<10.1.1.100/60218->10.2.0.3/80;6> matched filter trust_to_web:

The next line gives us the IPID, which is 57203 in this example:

packet [48] ipid = 57203, @423f6b9e

These two lines are basically useful to internal developers for troubleshooting hardware/software issues, and not for our problem at hand:

---- flow_process_pkt: (thd 1): flow_ctxt type 13, common flag 0x0,
mbuf 0x423f6a00
 flow process pak fast ifl 68 in_ifp ge-0/0/0.0

Notice that the inbound interface is ge-0/0/0.0 and the protocol is TCP, and that this is a SYN packet:

ge-0/0/0.0:10.1.1.100/60218->10.2.0.3/80, tcp, flag 2 syn

Here is the output as the SRX performs its 5-tuple lookup. The 5-tuple includes the source, destination, source port, destination port, and protocol. Protocol number 6 is TCP.

find flow: table 0x4d5c8238, hash 1430(0xffff), sa 10.1.1.100, da 10.2.0.3, sp
51510, dp 80, proto 6, tok 384

Note

The Internet Assigned Numbers Authority (IANA) has assigned numbers to all protocols. Here is a link to a list that IANA updates periodically: http://www.iana.org/assignments/protocol-numbers/.

Now that the 5-tuple lookup has been completed, a flow lookup is done. At this point, as shown by the output, the SRX determines if there is an existing session for this packet and whether it can take the fast path, or if this is a new session and it needs to go down the slow path. The example packet that is being broken down is, in fact, a first packet of a new session, and as such, the SRX determines that no existing session has been found and one must be created:

no session found, start first path. in_tunnel - 0, from_cp_flag - 0
  flow_first_create_session

The SRX then checks to see if there are any destination NAT configurations that apply. In this case, there are none, so no NAT is applied:

flow_first_in_dst_nat: in <ge-0/0/0.0>, out <N/A> dst_adr 10.2.0.3, sp 51510,
dp 80
  chose interface ge-0/0/0.0 as incoming nat if.
flow_first_rule_dst_xlate:  DST no-xlate: 0.0.0.0(0) to 10.2.0.3(80)

After the destination NAT has been looked up and applied, a route lookup can be done if one exists. The route lookup must take place after a destination NAT for routing purposes:

10.2.0.3, in ifp ge-0/0/0.0, out ifp N/A sp 51510, dp 80, ip_proto 6, tos 0
Doing DESTINATION addr route-lookup
  routed (x_dst_ip 10.2.0.3) from trust (ge-0/0/0.0 in 0) to ge-0/0/0.0,
Next-hop: 10.1.1.1

Once a route lookup is done on the destination, the SRX can determine the source and destination zones via a zone lookup. It then does a policy search to see if this traffic is denied/rejected/permitted or some other action, but in our case, it’s permitted:

policy search from zone trust-> zone web-dmz
  app 6, timeout 1800s, curr ageout 20s

If it had been denied by policy, a message such as this would have shown up, saying that the packet was denied and dropped:

packet dropped, denied by policy
packet dropped, policy deny.
flow find session returns error.
----- flow_process_pkt rc 0x7 (fp rc −1)

But that’s not the case, and now that the policy has been evaluated, the SRX checks to see if any source NAT configuration applies. In this case, there is no source NAT and everything returns false:

flow_first_src_xlate: 10.1.1.100/51510 -> 10.2.0.3/80 | 10.2.0.3/80 ->
0.0.0.0/51510: nat_src_xlated: False, nat_src_xlate_failed: False
flow_first_src_xlate: src nat 0.0.0.0(51510) to 10.2.0.3(80) returns status: 0,
rule/pool id: 0/0, pst_nat: False.
  dip id = 0/0, 10.1.1.100/51510->10.1.1.100/51510
flow_first_get_out_ifp: 1000 -> cone nat test

The SRX then determines the outgoing interface for this packet:

choose interface ge-0/0/0.0 as outgoing phy if
is_loop_pak: No loop: on ifp: ge-0/0/0.0, addr: 10.2.0.3, rtt_idx:0

Next, the SRX does some additional policy checks to see if items such as TCP proxy and WX apply:

policy is NULL (wx/pim scenario)
sm_flow_interest_check: app_id 0, policy 4, app_svc_en 0,
flags 0x2. not interested
sm_flow_interest_check: app_id 1, policy 4, app_svc_en 0,
flags 0x2. not interested
flow_first_service_lookup(): natp(0x4b9f2198): local_pak(0x3fdedc70.0x423f6a00):
TCP proxy NOT interested: 0.
  service lookup identified service 6.

In the preceding output, notice the policy number, policy 4. All security policies are assigned an index number. This index number is mainly for internal reference, but it can be viewed within the show security policies command, as shown in the following output, where you can see that policy 4 is a default-permit:

juniper@SRX5800> show security policies | match index
  Policy: default-permit, State: enabled, Index: 4, Sequence number: 1
  Policy: default-permit, State: enabled, Index: 5, Sequence number: 1
  Policy: protect_inside_users, State: enabled, Index: 6, Sequence number: 2
  Policy: webdmz_mgt, State: enabled, Index: 8, Sequence number: 1
  Policy: web_deny, State: enabled, Index: 9, Sequence number: 2
  Policy: default-deny, State: enabled, Index: 7, Sequence number: 1
  Policy: http-access, State: enabled, Index: 10, Sequence number: 1
  Policy: deny-all, State: enabled, Index: 11, Sequence number: 2

Back to our SRX output … the packet is sent out as the last checks are completed, as indicated here:

flow_first_final_check: in <ge-0/0/0.0>, out <ge-0/0/0.0>
  existing vector list 2-446fe828.
  Session (id:9270) created for first pak 2
  flow_first_install_session======> 0x4b9f2198
 nsp 0x4b9f2198, nsp2 0x4b9f2204
  make_nsp_ready_no_resolve()
  route lookup: dest-ip 10.1.1.100 orig ifp ge-0/0/0.0 output_ifp ge-0/0/0.0
orig-zone 6 out-zone 6 vsd 0
  route to 10.1.1.100
Installing c2s NP session wing
Installing s2c NP session wing
  flow got session.
  flow session id 9270
  tcp flags 0x2, flag 0x2
  Got syn, 10.1.1.100(51510)->10.2.0.3(80), nspflag 0x1021, 0x20
mbuf 0x423f6a00, exit nh 0x30010
 ----- flow_process_pkt rc 0x0 (fp rc 0)

Although the output from traceoptions is a bit cryptic and hard to read, sometimes it’s much easier to understand if you look at it line by line, like we just did.

So, from the output in the tshoot_web file, it appears that traffic is going out the incorrect interface. From the preceding output, the route lookup is done and it appears that traffic is exiting the same interface on which it is entering. The ifp is the inbound interface and the output_ifp is the outbound interface.

route lookup: dest-ip 10.1.1.100 orig ifp ge-0/0/0.0 output_ifp ge-0/0/0.0
orig-zone 6 out-zone 6 vsd 0

Look at the routing table to confirm that traffic is not exiting the proper interface:

juniper@SRX5800> show route 10.2.0.3
inet.0: 4 destinations, 4 routes (4 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0          *[Static/5] 6d 11:52:38
                    > to 10.1.1.1 via ge-0/0/0.0

The routing is incorrect. A quick static route should fix this problem and route traffic out the proper interface:

juniper@SRX5800> edit
[edit]
juniper@SRX5800> set routing-options static route 10.2.0.0/24 next-hop 10.2.1.1

Fix the problem and return to the show route command. Once a correct route is added, the traffic works for all users on the internal LAN:

juniper@SRX5800> show route 10.2.0.3
inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.2.0.0/24     *[Static/5] 00:02:32
                    > 10.2.1.1 via fe-0/0/2.0

Turning Off Traceoptions

After you have completed any troubleshooting in your network, is it highly recommended that you turn off traceoptions. Unless there is a very good reason to leave them running, you should always disable them as soon as you have finished troubleshooting, as traceoptions can consume SRX resources, and depending on the amount of traffic being debugged, SRX performance could be impacted.

There are two ways to turn off traceoptions. The first method is to just deactivate the configuration. This leaves the traceoptions configuration in the SRX, but it is turned off until it is reactivated at a later date when troubleshooting has resumed.

To deactivate everything use the deactivate security flow traceoptions command. However, be careful when using the deactivate command, because much like the delete command, if you use it incorrectly, it can have a severe impact on the SRX.

 [edit]
juniper@SRX5800# deactivate security flow traceoptions

To confirm that the traceoptions have been disabled, just look at the configuration with the show command. Junos will tell you that this portion of the configuration is inactive:

juniper@SRX5800# show security flow traceoptions
##
## inactive: security flow traceoptions
##
file tshoot_web;
flag basic-datapath;
packet-filter trust_to_web {
    source-prefix 10.1.1.100/32;
    destination-prefix 10.2.0.3/32;
}
packet-filter web_to_trust {
    source-prefix 10.2.0.3/32;
    destination-prefix 10.1.1.100/32;
}

The second method to turn off traceoptions is to delete the traceoptions configuration. If the traceoptions configuration is no longer needed and troubleshooting has been completed, it’s wise to delete the configuration from the SRX.

To do this, use the delete command coupled with the security flow traceoptions configuration:

[edit]
juniper@SRX5800# delete security flow traceoptions

Now confirm that the traceoptions configuration is gone:

[edit]
juniper@SRX5800# show security flow traceoptions
[edit]
juniper@SRX5800#

The authors recommend that whenever you use the delete command you issue a show | compare before committing the configuration. This will display all changes to the configuration that are applied when a commit is done. It also ensures that no unintended configurations are made, or in this case, deleted:

juniper@SRX5800# show | compare
[edit security]
-   flow {
-       traceoptions {
-           file tshoot_web;
-           flag basic-datapath;
-           packet-filter trust_to_web {
-               source-prefix 10.1.1.100/32;
-               destination-prefix 10.2.0.3/32;
-           }
-           packet-filter web_to_trust {
-               source-prefix 10.2.0.3/32;
-               destination-prefix 10.1.1.100/32;
-           }
-       }
-   }
[edit]

As shown, only the traceoptions configuration has been deleted, so it’s safe to do a commit and exit configuration mode.

Note

To remove old troubleshooting logfiles, use the file delete <filename> command. It’s always a best practice to remove old, unused files when you no longer need them.

Application Layer Gateway Services

Application layer gateways (ALGs) are advanced application-inspecting features available on the SRX that serve two primary purposes. The first is to dynamically pinhole traffic for applications allowing return inbound packets (e.g., for FTP there may be multiple sessions for control and data for the same data connection between the source and destination). The second role of an ALG is to provide a deeper layer of inspection and a more granular layer of application security. ALGs can be better described as extra intelligence built to assist with certain applications that have problems with stateful firewalls.

This type of extra security and inspection is possible because an ALG understands the application protocol and how it is supposed to function. The SRX can prevent many types of SCCP DoS attacks, such as call flooding, from taking place on the network. We will cover these configurable application screens in detail in Chapter 7, but in a nutshell, ALGs are application (Layer 7)-aware packet processing (Layer 4).

Note

It’s worth noting that not all ALGs are available in the higher-end SRX models. For example, at the time of this writing, SCCP and H323 are not available on the high-end SRX devices, while the branch SRX Series has full support for all listed ALGs.

Here is a list of ALGs currently built into the SRX, along with a brief explanation of what each one does:

REAL

RealAudio/RealVideo are proprietary formats developed by RealNetworks and they use what is called Progressive Network Audio (PNA) or Progressive Network Media (PNM) to send streaming audio data. PNA packets are sent over a TCP connection and act like a control channel. The audio data itself is sent over a UDP connection. The ALG dynamically allows these UDP data connections and performs any NAT that needs to take place.

RTSP

Real-Time Streaming Protocol is used to establish and control media connections between end hosts. RTSP handles all client-to-media server requests such as play and pause, and is used to control real-time playback of the media files from the server. RTSP does not, however, stream any media data. Commonly, that is left to Real-time Transport Protocol (RTP), and the two are used in combination to deliver media to the clients.

DNS

The Domain Name System ALG monitors DNS queries and response packets. Since DNS is UDP and is a simple request-response type of flow, the DNS ALG monitors for the response flag and then closes down the UDP session. This is very useful; otherwise, the SRX would wait two minutes before timing out the session, which is the default for UDP.

FTP

The File Transfer Protocol ALG monitors the FTP connection for PORT, PASV, and 227 commands. The ALG will handle all NAT functions and pinholing of any additional ports necessary. Additional security options can be leveraged by configuring the FTP ALG to block specific FTP functions, such as FTP put or FTP get.

TFTP

The Trivial File Transfer Protocol ALG monitors the initiation of a TFTP connection and pinholes a connection through the SRX permitting the reverse direction.

TALK

TALK is a legacy chat-type application for Unix platforms developed in the early 1980s. TALK communicates on UDP port 517/518 for control-channel-type functions. The TALK ALG will handle all NAT functions in addition to any pinholing that needs to take place.

RSH

RSH stands for Remote Shell. RSH is a Unix-type program that can execute commands across a network. RSH typically uses TCP port 514. RSH has largely been replaced by SSH as RSH communicates unencrypted. The RSH ALG handles all NAT functions as well as any pinholing that needs to take place.

PPTP

Point-to-Point Tunneling Protocol is a Layer 2 protocol used for tunneling PPP over an IP network. PPTP is often used as a way to implement virtual private networks (VPNs) and is tunneled over TCP and a Generic Route Encapsulation (GRE) tunnel encapsulating the PPP packets. The PPTP ALG handles all NAT functions and pinholing for functions of PPTP, such as Call IDs of PAC and PNS.

SQL

The Structured Query Language ALG handles SQL TNS response frames and then evaluates the packet for IP address and port information. The SQL ALG handles all NAT functions and pinholing for the TCP data channel.

H323

This is a suite of protocols that provides audio-visual communication sessions over an IP network. The H.323 standard includes call signaling, call control, multimedia transport, multimedia control, and bandwidth control. The H323 ALG handles all NAT functions in addition to gatekeeper discovery, endpoint registration/admission/status, and call control/call setup. The H323 ALG also has many application screens that provide additional protections at an application level.

SIP

Session Initiation Protocol is a signaling protocol used for initiating, modifying, and terminating multimedia sessions such as voice and video calls over IP. The SIP ALG on the SRX only supports Session Description Protocol (SDP), even though SIP can use a variety of different description protocols to describe the session. The SIP ALG monitors SIP connections and dynamically pinholes for the SIP traffic.

SCCP

Skinny Client Control Protocol is a Cisco protocol for VoIP call signaling to the Cisco CallManager. The SCCP ALG will look within the control packets and allow the RTP port number and IP address of the media termination, dynamically pinholing for the RTP flows. In addition to pinholing, the SCCP ALG also handles all NAT functions and application layer protections.

MGCP

Media Gateway Control Protocol is a signaling and call control protocol used in VoIP between the media gateway and media controller. The MGCP ALG handles the dynamic pinholing for any additional connections needed, as well as handling all NAT functions. The MGCP ALG also inspects the VoIP signaling data and ensures that it complains to RFC standards blocking any malformed packets or attacks. Additional application layer protections are also configurable within the ALG.

RPC

Remote Procedure Call is a secure interprocess communication that handles data exchange and invocation to a different process, typically to a machine on the local network or across the Internet. The RPC ALG handles dynamic port negotiation and pinholing as well as all NAT functions.

IKE/ESP

IKE (Internet Key Exchange) and ESP (Encapsulating Security Payload) are a part of the IP Security (IPsec) protocol. In situations where the SRX is inline and an IPsec VPN passes through the SRX and NAT is enabled, IPsec VPNs can have issues. This is a common problem with IPsec and address translation. The IKE/ESP ALG should help with that problem, enabling the SRX to go inline and not interfere with VPN flows.

ALGs all perform the same type of function: they inspect the applications control channel and handle either NAT, dynamic pinholing of ports, or both. The ALG process does not inspect or monitor the actual data channel, something to keep in mind when working with ALGs.

To view which ALGs are currently enabled on the SRX, use the show security alg status command to display the ALGs:

juniper@SRX5800> show security alg status
ALG Status :
  DNS      : Enabled
  FTP      : Enabled
  H323     : Enabled
  MGCP     : Enabled
  MSRPC    : Enabled
  PPTP     : Enabled
  RSH      : Enabled
  RTSP     : Enabled
  SCCP     : Enabled
  SIP      : Enabled
  SQL      : Enabled
  SUNRPC   : Enabled
  TALK     : Enabled
  TFTP     : Enabled

How to Configure an ALG

Let’s use the FTP ALG as our first configuration example, because if you remember from earlier in this chapter, it was configured for web-dmz administration.

From the trust network the web administrators are now requesting FTP access to the web1 server so that files can be uploaded to the server. In a secured network, their request should be denied because FTP transmits everything in clear text as it is an insecure protocol. The web administrators should be told to use SFTP. However, for this example, let’s assume that SFTP is not available and FTP must be used. Sadly, cases such as this widely exist due to many legacy platforms and applications.

Enabling the FTP ALG is simple, since there is already a policy that allows the web administrators to connect to the web-dmz:

juniper@SRX5800> show security policies from-zone trust to-zone web-dmz
From zone: trust, To zone: web-dmz
  Policy: webdmz_mgt, State: enabled, Index: 8, Sequence number: 1
    Source addresses: any
    Destination addresses: web-servers
    Applications: web_mgt
    Action: permit, log
  Policy: web_deny, State: enabled, Index: 9, Sequence number: 2
    Source addresses: any
    Destination addresses: any
    Applications: any
    Action: deny, log

All we need to do is add the Junos-FTP service to the web_mgt application-set:

[edit]
juniper@SRX5800# set applications application-set web_mgt application junos-ftp
[edit]
juniper@SRX5800# commit and-quit
commit complete
Exiting configuration mode

Look at the applications the Junos-FTP service shows under web_mgt:

juniper@SRX5800> show configuration applications application-set web_mgt
application junos-ssh;
application junos-ping;
application junos-pc-anywhere;
application windows_rdp;
application junos-http;
application junos-ftp;

A more detailed look at the webdmz_mgt policy shows the new ALG information:

juniper@SRX5800> show security policies from-zone trust to-zone web-dmz
policy-name webdmz_mgt detail
Policy: webdmz_mgt, action-type: permit, State: enabled, Index: 8
  Sequence number: 1
  From zone: trust, To zone: web-dmz
  Source addresses:
    any: 0.0.0.0/0
  Destination addresses:
    web2: 10.2.0.2/32
    web1: 172.31.100.60/32
  Application: web_mgt
    IP protocol: tcp, ALG: 0, Inactivity timeout: 1800
      Source port range: [0-0]
      Destination port range: [22-22]
    IP protocol: 1, ALG: 0, Inactivity timeout: 60
      ICMP Information: type=255, code=0
    IP protocol: udp, ALG: 0, Inactivity timeout: 60
      Source port range: [0-0]
      Destination port range: [5632-5632]
    IP protocol: tcp, ALG: 0, Inactivity timeout: 1800
      Source port range: [1024-65535]
      Destination port range: [3389-3389]
    IP protocol: tcp, ALG: 0, Inactivity timeout: 1800
      Source port range: [0-0]
      Destination port range: [80-80]
    IP protocol: tcp, ALG: ftp, Inactivity timeout: 1800
      Source port range: [0-0]
      Destination port range: [21-21]
  Session log: at-create, at-close

Let’s confirm that FTP does work to the server and that the web administrators can now upload their files as needed:

ftp> open 172.31.100.60
Connected to 172.31.100.60.
220-FileZilla Server version 0.9.34 beta
220-written by Tim Kosse (Tim.Kosse@gmx.de)
220 Please visit http://sourceforge.net/projects/filezilla/
Name (172.31.100.60:tle4729):
331 Password required for tle4729
Password:

Now view this connection on the SRX:

juniper@SRX5800> show security flow session application ftp
Session ID: 11663, Policy name: webdmz_mgt/8, Timeout: 788
  In: 10.1.1.100/59832 --> 172.31.100.60/21;tcp, If: ge-0/0/0.0
  Out: 172.31.100.60/21 --> 10.1.1.100/59832;tcp, If: fe-0/0/2.0
Session ID: 11664, Policy name: webdmz_mgt/8, Timeout: 790
  In: 10.1.1.100/59834 --> 172.31.100.60/21;tcp, If: ge-0/0/0.0
  Out: 172.31.100.60/21 --> 10.1.1.100/59834;tcp, If: fe-0/0/2.0
2 sessions displayed

Voilà! Some ALGs are simple to set up, as easy as using the prebuilt Junos application. ALGs such as FTP, TFTP, and DNS are perfect examples of this type of ALG. Other, more complex ALGs have more optional configuration knobs.

Our second ALG configuration example concerns the SIP ALG. The SIP ALG has a lot more configuration options than the FTP ALG, but the SIP ALG is applied in the same way the FTP ALG is applied: via security policy and Junos-SIP as the application.

Although SIP has various configuration knobs under the security alg sip stanza, I’ll cover just a few here. First, set the SIP ALG maximum-call-duration setting to 1,000 minutes (that’s more than 15 hours!):

[edit]
juniper@SRX5800# set security alg sip maximum-call-duration 1000

The next optional configuration is the timeout value (this value is in seconds):

[edit]
juniper@SRX5800# set security alg sip inactive-media-timeout 60

Overall, the SIP ALG is pretty easy to set up and configure. Problems arise when vendors do not follow RFC guidelines or they write their own one-off SIP implementations. If issues start after the SIP ALG is configured, the primary things to check are the SIP counters for errors. For inoperability issues, one possible workaround is to enable the unknown-message option; by default, the SRX’s SIP ALG drops all unsupported messages for security purposes. Note that this disables that security feature:

[edit]
juniper@SRX5800# set security alg sip application-screen unknown-message
permit-routed

Another common issue is when vendors implement proprietary headers into their SIP packets. Per standards, the call-id header should contain a hostname or source IP address, and in some cases, vendors adjust or change this. To disable the call-id enforcement use the following:

[edit]
juniper@SRX5800# set security alg sip disable-call-id-hiding
juniper@SRX5800# edit security policies from-zone trust to-zone voip-dmz

Once that has been applied, the base SIP configuration is finished. SIP calls can be made and should have no problems going through. Let’s verify the SIP stats by using the show security alg sip counters command to view the counters, including errors on decoding packets:

juniper@SRX5800> show security alg sip counters
   Method       T     1xx      2xx      3xx     4xx      5xx    6xx
               RT      RT       RT       RT      RT       RT     RT
   INVITE       2       1        0        0       2        0      0
                0       0        0        0       0        0      0
   CANCEL       0       0        0        0       0        0      0
                0       0        0        0       0        0      0
      ACK       2       0        0        0       0        0      0
                0       0        0        0       0        0      0
      BYE       0       0        0        0       0        0      0
                0       0        0        0       0        0      0
 REGISTER      28       0        8        0      20        0      0
                0       0        0        0       0        0      0
  OPTIONS       0       0        0        0       0        0      0
                0       0        0        0       0        0      0
     INFO       0       0        0        0       0        0      0
                0       0        0        0       0        0      0
  MESSAGE       0       0        0        0       0        0      0
                0       0        0        0       0        0      0
   NOTIFY       0       0        0        0       0        0      0
                0       0        0        0       0        0      0
    PRACK       0       0        0        0       0        0      0
                0       0        0        0       0        0      0
  PUBLISH       0       0        0        0       0        0      0
                0       0        0        0       0        0      0
    REFER       0       0        0        0       0        0      0
                0       0        0        0       0        0      0
SUBSCRIBE       0       0        0        0       0        0      0
                0       0        0        0       0        0      0
   UPDATE       0       0        0        0       0        0      0
                0       0        0        0       0        0      0
 BENOTIFY       0       0        0        0       0        0      0
                0       0        0        0       0        0      0
  SERVICE       0       0        0        0       0        0      0
                0       0        0        0       0        0      0
    OTHER       0       0        0        0       0        0      0
                0       0        0        0       0        0      0
SIP Error Counters:
  Total Pkt-in                  : 76
  Total Pkt dropped on error    : 13
  Transaction error             : 0
  Call error                    : 0
  IP resolve error              : 0
  NAT error                     : 0
  Resource manager error        : 0
  RR header exceeded max        : 0
  Contact header exceeded max   : 0
  Call Dropped due to limit     : 0
  SIP stack error               : 0
  SIP decode error              : 13
  SIP unknown method error      : 0
  RTO message sent              : 0
  RTO message received          : 0
  RTO buffer allocation failure : 0
  RTO buffer transmit failure   : 0
  RTO send processing error     : 0
  RTO receive processing error  : 0
  RTO receive invalid length    : 0

To view a higher-level overview of calls, use the show security alg sip calls command as the optional detail flag at the end to display even more information about the call:

juniper@SRX5800> show security alg sip calls
Total number of calls: 2 (# of call legs 4)
   Call leg1: zone 3
      UAS callid:120ed748-11121207-04c1279d-0bbb7e18@172.31.100.50 (pending tsx 1)
      Local tag
      Remote tag: 120ed748111212e264b0a951-5cbb0a95
      State: STATE_DISCONNECTED
   Call leg2: zone 2
      UAC callid:120ed748-11121207-04c1279d-0bbb7e18@172.31.100.50 (pending tsx 1)
      Local tag: 120ed748111212e264b0a951-5cbb0a95
      Remote tag
      State: STATE_DISCONNECTED
   Call leg1: zone 3
      UAS callid:120ed748-11121207-04c1279d-0bbb7e18@172.31.100.50 (pending tsx 1)
      Local tag:  120f90542e7e64cd724880f5-65db2f99
      Remote tag: 120ed748111212e264b0a951-5cbb0a95
      State: STATE_ESTABLISHED
   Call leg2: zone 2
      UAC callid:120ed748-11121207-04c1279d-0bbb7e18@172.31.100.50 (pending tsx 1)
      Local tag:  120ed748111212e264b0a951-5cbb0a95
      Remote tag: 120f90542e7e64cd724880f5-65db2f99

To view transactions, use the show security alg sip transaction command:

 juniper@SRX5800> show security alg sip transaction
Total number of transactions: 1
       Transaction Name   Method  CSeq  State        Timeout  VIA RSC ID
       UAS:gsn0x5a06ddf1   BYE    101   Proceeding      −1        -
       UAC:gsn0x5a06f615   BYE    101   Calling         25        8184

And to view the overall health of the SIP ALG, use show security alg sip rate:

juniper@SRX5800> show security alg sip rate
CPU ticks per microseconds is 3735928559
Time taken for the last message is 0 microseconds
Total time taken for 0 messages is 0 microseconds(in less than 10 minutes)
Rate: 3735928559 messages/second

ALGs provide an additional layer of security and handle NAT as well as dynamic pinholing when needed. With that deeper layer of inspection come more processing and additional potential problems. Oftentimes when Juniper writes ALGs, they are written to follow and enforce RFC specifications. The problem most commonly comes when vendors write one-off applications or their own additions to the protocol, or to the service, and the ALG doesn’t know how to properly handle it.

Juniper has incorporated as many workarounds as possible, such as called-hiding and unknown-message, in the SIP ALG. However, sometimes issues still occur. In these events, the only option may be to open more port ranges than the vendor has provided.

Policy Schedulers

Policy schedulers are rules that you can enable or disable based on time and date. Schedulers are configured on a per-policy basis and only one scheduler can be configured per policy. However, multiple policies can reference a single scheduler.

You can use schedulers in a number of different situations and for several different purposes:

Internet browsing access

You can write a scheduler to allow Internet access from the employees’ network only during nonbusiness hours. For example, from 5:00 p.m. to 8:00 a.m. and from noon to 1:00 p.m. (lunch hour) employees are allowed to access the Internet via HTTP as this is during nonbusiness hours.

Access to payroll systems

You can write a scheduler to allow the HR department to access the payroll system only during business hours—for example, from 8:00 a.m. to 6:00 p.m. This can prevent rogue access when nobody is on-site or in the office.

In both of the preceding examples, you can use schedules to restrict or permit access based on the time or date. Schedulers can assist in enforcing company policies and in increasing security, and you can be quite creative based on the habits of typical network users.

You can enable schedules by first creating the scheduler and then applying it to the policy.

Let’s create a few sample schedulers and then discuss what was done.

juniper@SRX5800# set schedulers scheduler deny-web daily start-time 08:00
stop-time 17:00
[edit]

In the preceding output, a scheduler was created called deny-web that is enforced daily from 8:00 a.m. to 5:00 p.m., thus applying this scheduler to anything that you do not want done during office hours.

Now, let’s apply that scheduler to a policy that denies access to HTTP:

juniper@SRX5800# edit security policies from-zone trust to-zone Internet
[edit security policies from-zone trust to-zone Internet]
juniper@SRX5800# set policy deny_daytime_websurfing match source-address any
destination-address any application junos-http
[edit security policies from-zone trust to-zone Internet]
juniper@SRX5800# set Internet policy deny_daytime_websurfing then deny
[edit security policies from-zone trust to-zone Internet]
juniper@SRX5800# set policy deny_daytime_websurfing scheduler-name deny-web

In the preceding output, a security policy was written from the Trust zone going to the Internet zone for any HTTP traffic. Then an action of deny was applied, and finally the scheduler deny-web was configured to be active during those time frames in deny-web.

It is also possible to add days to exclude, as in the following:

juniper@SRX5800# edit schedulers scheduler
[edit schedulers scheduler]
juniper@SRX5800# set network-access daily start-time 09:00 stop-time 20:00
[edit schedulers scheduler]
juniper@SRX5800# set network-access saturday exclude
[edit schedulers scheduler]
juniper@SRX5800# set network-access sunday exclude

The scheduler called network-access runs daily from 9:00 a.m. to 8:00 p.m. (This scheduler might be used to control remote access into the network.) Notice that two additional lines were configured for both Saturday and Sunday to be excluded. In other words, remote users will not be able to access the network on weekends once this scheduler is applied to the proper policy.

Just like the first policy, let’s configure this setup to allow the contractor subnet access to everything on the web-dmz zone during the defined times in network-access:

juniper@SRX5800#set security zones security-zone trust address-book address
contractor_subnet 10.3.0.0/24
[edit]
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 contractor_access match source-address
contractor_subnet destination-address any application any

[edit security policies from-zone trust to-zone web-dmz]
juniper@SRX5800# set policy contractor_access then permit

[edit security policies from-zone trust to-zone web-dmz]
juniper@SRX5800# set policy contractor_access scheduler-name network-access

Now look at the configuration to check that everything is in order:

juniper@SRX5800# show security policies from-zone trust to-zone web-dmz policy
contractor_access
match {
    source-address contractor_subnet;
    destination-address any;
    application any;
}
then {
    permit;
}
scheduler-name network-access;
[edit]

One-Time Schedulers

One-time schedulers can also be configured to run for a predefined period of time. After that period of time, the scheduler becomes inactive and does not activate the policy. You can use this in situations where access should be granted on a temporary basis or something needs to be blocked for a period of time.

An example of a one-time scheduler is a scheduler that grants access to a vendor for a window of time to troubleshoot or fix a problem. If the web servers we configured earlier were having problems, we could configure a policy that allowed Microsoft to access them remotely. The security department should have a problem with granting this type of access permanently, so we would use a scheduler to ensure that access is removed after a previously agreed upon time frame. Here’s a one-time scheduler granting temporary access into the network:

[edit]
juniper@SRX5800# set schedulers scheduler microsoft_remote_access
start-date 2010-02-14.09:00 stop-date 2010-02-15.09:00
[edit]
juniper@SRX5800#

This one-time scheduler is called microsoft_remote_access and is set to enable on February 14, 2010 at 9:00 a.m. It will end 24 hours later. Here is the permit that will no longer apply after 24 hours:

juniper@SRX5800# edit
[edit]
juniper@SRX5800# set security zones security-zone Internet address-book address
ms_support 207.46.197.32

[edit]
juniper@SRX5800# set security policies from-zone Internet to-zone web-dmz

[edit security policies from-zone Internet to-zone web-dmz]
juniper@SRX5800# set policy temp_ms_access match source-address ms_support
destination-address web1 application any
[edit security policies from-zone Internet to-zone web-dmz]
juniper@SRX5800# set policy temp_ms_access scheduler-name microsoft_remote_access

[edit security policies from-zone Internet to-zone web-dmz]
juniper@SRX5800# set policy temp_ms_access then permit
[edit security policies from-zone Internet to-zone web-dmz]
juniper@SRX5800#

In the preceding output, a new address book was created for Microsoft’s source IP address. Then a policy was written to allow that IP access to the web1 server via any application. The third item configured was the scheduler microsoft_remote_access that was applied. Now, this scheduler will be active from February 14 until February 15 to allow Microsoft to remotely access the server.

Let’s look at the configuration as a whole:

juniper@SRX5800# show security policies from-zone Internet to-zone web-dmz
policy temp_ms_access
match {
    source-address ms_support;
    destination-address web1;
    application any;
}
then {
    permit;
}
scheduler-name microsoft_remote_access;
[edit]

You can view configured schedulers with the show schedulers command. Here is the output from the three already configured schedulers. Right now it appears that there are two active schedulers and one inactive scheduler. The output will also list the next time a scheduler is set to turn on or off.

juniper@SRX5800> show schedulers
Scheduler name: deny-web, State: active
  Next deactivation: Fri Jan 22 17:00:00 2010
Scheduler name: microsoft_remote_access, State: inactive
  Next activation: Sun Feb 14 09:00:00 2010
Scheduler name: network-access, State: active
  Next deactivation: Fri Jan 22 20:00:00 2010

Let’s look at a detailed policy output to confirm that the schedule is applied and it is active (the state should show enabled):

juniper@SRX5800> show security policies from-zone trust to-zone web-dmz
policy-name contractor_access detail
Policy: contractor_access, action-type: permit, State: enabled, Index: 14
  Sequence number: 3
  From zone: trust, To zone: web-dmz
  Source addresses:
    contractor_subnet: 10.3.0.0/24
  Destination addresses:
    any: 0.0.0.0/0
  Application: any
    IP protocol: 0, ALG: 0, Inactivity timeout: 0
      Source port range: [0-0]
      Destination port range: [0-0]
  Scheduler name: network-access

Web and Proxy Authentication

The SRX can also be used as an inline web proxy, forcing users to authenticate for access, or as a pass-through authentication forcing Telnet, FTP, and HTTP to authenticate, adding an additional layer of security while keeping a historical log for later review and auditing.

Web Authentication

Figure 4-6 illustrates the stages of the web authentication process.

How web authentication works
Figure 4-6. How web authentication works

Configuring web authentication is relatively painless. The largest task is creating the user profiles that would be needed for authentication.

The first step is to enable authentication on the interface itself. Here we apply web authentication to an already existing interface, ge-0/0/0, of which the Trust zone is a part:

[edit]
juniper@SRX5800# set interfaces ge-0/0/0 unit 0 family inet
address 10.1.0.254/24 web-authentication http
[edit]
juniper@SRX5800#

Next, we need to create a user or list of users that have permission to access the Web. Here we use the volunteer sample user Tim_Eberhard which has been set up under access profile web-allow-group. The access profile will be referenced later in the configuration.

[edit]
juniper@SRX5800# set access profile web-allow-group client Tim_Eberhard
firewall-user password letmeinpls

An alternative to using local user lists on the SRX is to authenticate users to an external database on a RADIUS, RSA, or LDAP server.

Let’s begin a web authentication configuration example to an external RADIUS server. A RADIUS server could be configured with thousands of individual accounts:

[edit]
juniper@SRX5800# set access profile web-allow-group_radius
radius-server 10.3.4.100 secret radius_secret_key retry 2

Next we will configure the SRX to try the RADIUS server first; if that server fails, the SRX will resort back to the local database (this way, if the RADIUS server ever fails, it’s possible to have a default account that allows access during emergencies):

[edit]
juniper@SRX5800# set access profile web-allow-group authentication-order radius
authentication-order password

Now we’ll apply the web authentication to the policy, adding the permit-http policy from the Trust zone to the Internet zone:

[edit]
juniper@SRX5800# set security policies from-zone trust to-zone Internet
policy permit-http then permit firewall-authentication web-authentication

Let’s look at the configuration as a whole:

[edit]
juniper@SRX5800# show access profile web-allow-group
authentication-order [ radius password ];
client Tim_Eberhard {
    firewall-user {
        password "$9$hISclM7NbgaUX7wgoZkqCtu0RS7Nb2oG"; ## SECRET-DATA
    }
}
radius-server {
    10.3.4.100 {
        secret "$9$iq5Fn6AOBEP5hrvM-d6/CuIcKvLN-wKM7VbsZGREclvLdVYgJD";
## SECRET-DATA
        retry 2;
    }
}
[edit]
juniper@SRX5800# show interfaces ge-0/0/0
description "Inside network";
speed 100m;
link-mode full-duplex;
unit 0 {
    family inet {
        address 10.1.0.254/24 {
            web-authentication http;
        }
    }
}
juniper@SRX5800# show security policies from-zone trust to-zone Internet
policy permit-http {
    match {
        source-address any;
        destination-address any;
        application junos-http;
    }
    then {
        permit {
            firewall-authentication {
                web-authentication;
            }
        }
    }
}

This basic web authentication will prompt users when they try to use HTTP. Web authentication is basically a portal that will authenticate a user’s traffic through.

Pass-Through Authentication

Another method of authentication that you can use on the SRX is called pass-through authentication. Pass-through authentication is different from web authentication as it just prompts the user to enter his account information for authentication somewhat transparently. Pass-through can be triggered by HTTP, Telnet, and FTP traffic.

From a user standpoint, the authentication process looks as though the website or Telnet, or the FTP session, is prompting the user for his account information, whereas with web authentication users need to go to a certain IP address and authenticate before attempting to send any other traffic.

Figure 4-7 illustrates the pass-through authentication process.

How pass-through authentication works
Figure 4-7. How pass-through authentication works

Configuring pass-through authentication is much like configuring web authentication. The first thing you need to do is to turn on pass-through authentication and assign it to a profile. For the following example, we’ll reuse web-allow-group since it already had a user account and RADIUS server configured. The second thing you need to do is to set a banner to inform the user what to submit for authentication.

Note

A banner should provide a phone number or an email address that users can use for support if they cannot get past the inline challenge.

We’ll use the Telnet service for our example. Since Telnet is an insecure protocol that must sometimes be supported due to legacy applications and systems, using inline authentication here is an additional layer of security that we can apply to our connection.

juniper@SRX5800# edit access firewall-authentication pass-through
[edit access firewall-authentication pass-through]
juniper@SRX5800# set default-profile web-allow-group
[edit access firewall-authentication pass-through]
juniper@SRX5800# set telnet banner success "PLEASE ENTER IN YOUR ACCOUNT INFO.
FOR SUPPORT PLEASE CALL THE NOC AT 1-800-555-1212"
[edit access firewall-authentication pass-through]
juniper@SRX5800# top
[edit]
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 permit-telnet match source-address any
destination-address any
[edit security policies from-zone trust to-zone web-dmz]
juniper@SRX5800# set policy permit-telnet match application junos-telnet
[edit security policies from-zone trust to-zone web-dmz]
juniper@SRX5800# set policy permit-telnet then permit firewall-authentication
pass-through access-profile web-allow-group

And here is what that configuration looks like all together:

juniper@SRX5800# show | compare
[edit security policies from-zone trust to-zone web-dmz]
      policy web_deny { ... }
+     policy permit-telnet {
+         match {
+             source-address any;
+             destination-address any;
+             application junos-telnet;
+         }
+         then {
+             permit {
+                 firewall-authentication {
+                     pass-through {
+                         access-profile web-allow-group;
+                     }
+                 }
+             }
+         }
+     }

We can view active authenticated information about the SRX’s authentications using the following output:

juniper@SRX5800# show security firewall-authentication users
Firewall authentication data:
  Total users in table: 1
          Id Source Ip       Src zone Dst zone Profile    Age Status   User
           4 10.3.0.12     Trust   Internet      webauth-     4 Success  Tim

The show security firewall-authentication history command shows all active and authenticated users currently passing through the SRX:

juniper@SRX5800> show security firewall-authentication history
History of firewall authentication data: Authentications: 2 Id Source Ip
Date Time Duration Status User
1 10.1.0.120 2010-01-12 18:20:02 0: 00:22 Failed bob
2 10.1.0.125 2010-01-13 12:22:48 0: 00:21 Success bill

Firewall authentication provides an additional layer of security as well as logs. It can be used to enforce company access policies or better protect network boundaries and access. It is a very simple way to improve the overall security strategy of anything from the smallest home office to a large corporate network.

Case Study 4-1

Objective: Set up basic firewall policy for the company’s network, including web and email access for the users, and inbound as well as outbound access for the servers.

Our strategies to achieve that objective are as follows:

  • Create a security policy that allows access to the web server DMZ from anywhere on the Internet.

  • Allow access to the mail servers on the mail server DMZ from the internal user networks 10.1.0.0/24 and 10.1.2.0/24, and inbound/outbound mail access to the mail server from the Internet.

  • Create a custom application with a 60-minute timeout for TCP port 6667 and apply that custom application on the web server DMZ to the Internet.

  • Create a policy that requires users on the trust network 10.1.0.0/24 to authenticate for web browsing during business hours to comply with the company’s Internet access policy.

Figure 4-8 shows our topology for Case Study 4-1.

Case Study 4-1’s objective
Figure 4-8. Case Study 4-1’s objective

First, we need to write a policy for access to the web server DMZ from the Internet. This is a basic permit policy with any source. Since it’s a web server facing the public Internet logging will be enabled. Let’s start with the following:

[edit]
juniper@SRX5800# set security zones security-zone web-dmz address-book address
web_server 172.31.100.60/32
[edit]
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 "allow_http_from_web" match source-address any
destination-address web1 application junos-http
[edit security policies from-zone internet to-zone web-dmz]
juniper@SRX5800# set policy "allow_http_from_web" then permit
[edit security policies from-zone internet to-zone web-dmz]
juniper@SRX5800# set policy "allow_http_from_web" then log session-close
session-init

Next, we need to write a couple of policies that make the mail server work. To do this, we’ll create one policy that allows the user segments to access the mail server and another policy to allow both inbound and outbound mail access from the mail server itself.

First we need to create the address-books. An address-set will combine both user segments into a single address-set:

[edit security policies from-zone internet to-zone web-dmz]
juniper@SRX5800# top
[edit]
juniper@SRX5800# edit security zones security-zone dept-a address-book
[edit security zones security-zone dept-a address-book]
juniper@SRX5800# set address users1 10.1.0.0/24
[edit security zones security-zone dept-a address-book]
juniper@SRX5800# set address users2 10.1.2.0/24
[edit security zones security-zone dept-a address-book]
juniper@SRX5800# set address-set users_segments address users1
[edit security zones security-zone dept-a address-book]
juniper@SRX5800# set address-set users_segments address users2

Now, we need to create the mail server DMZ and configure an address-book for that server:

[edit security zones security-zone dept-a address-book]
juniper@SRX5800# top
[edit]
juniper@SRX5800# set security zones security-zone mail-dmz
[edit]
juniper@SRX5800# set security zones security-zone mail-dmz address-book
address mail_server 172.31.100.70/32

We need to configure an application-set to allow the various mail services:

juniper@SRX5800# edit applications application-set
[edit applications application-set]
juniper@SRX5800# set mail_services application junos-imap
[edit applications application-set]
juniper@SRX5800# set mail_services application junos-smtp
[edit applications application-set]
juniper@SRX5800# set mail_services application junos-pop3

Once that is complete, we can configure the first policy that allows users to access the mail server:

[edit applications application-set]
juniper@SRX5800# top
[edit]
juniper@SRX5800# edit security policies from-zone dept-a to-zone mail-dmz
[edit security policies from-zone dept-a to-zone mail-dmz]
juniper@SRX5800# set policy "allow_users_to_mail" match source-address
users_segments destination-address mail_server application mail_services
[edit security policies from-zone dept-a to-zone mail-dmz]
juniper@SRX5800# set policy "allow_users_to_mail" then permit

Now that users are allowed to access the mail servers, the mail servers need to send email out as well as receive mail from the Internet.

Here is the code to send email from mail-dmz to the Internet:

[edit security policies from-zone dept-a to-zone mail-dmz]
juniper@SRX5800# top
[edit]
juniper@SRX5800# edit security policies from-zone mail-dmz to-zone internet
[edit security policies from-zone mail-dmz to-zone internet]
juniper@SRX5800# set policy "permit_outbound_mail"
match source-address mail_server destination-address any
application mail_services
[edit]
juniper@SRX5800# set policy "permit_outbound_mail" then permit

Now, here’s the code to reverse connectivity:

juniper@SRX5800# top
[edit]
juniper@SRX5800# edit security policies from-zone internet to-zone mail-dmz
[edit security policies from-zone internet to-zone mail-dmz]
juniper@SRX5800# set policy "permit_inbound_mail" match source-address any
destination-address mail_server application mail_services
[edit security policies from-zone internet to-zone mail-dmz]
juniper@SRX5800# set policy "permit_inbound_mail" then permit
[edit security policies from-zone internet to-zone mail-dmz]
juniper@SRX5800# set policy "permit_inbound_mail" then log session-init
session-close

You might have noticed that logging was enabled. It is a best practice to log anything coming in from the Internet, at the very least. Here, both the web server and the mail server inbound connections from the Internet are logged.

Another service that needs to be permitted is TCP port 6667 with an inactivity timeout of 60 minutes; we also need to allow the web server to connect to any destination on the Internet with that port. Since timeouts are configured in seconds, our timeout will need to be 3,600 seconds:

juniper@SRX5800# top
[edit]
juniper@SRX5800# set applications application tcp_6667 protocol tcp
source-port 6667 destination-port 1-65000 inactivity-timeout 3600
[edit]
juniper@SRX5800# edit security policies from-zone web-dmz to-zone internet
[edit security policies from-zone web-dmz to-zone internet]
juniper@SRX5800# set policy "permit_irc" match source-address web1
destination-address any application tcp_6667
[edit]
juniper@SRX5800# set policy "permit_irc" then permit

The last few configurations we need to make are to create a policy that forces users on the Dept-A segment to authenticate for HTTP access during business hours. We can do this by creating a scheduler and then configuring pass-through authentication for HTTP.

But before we can configure anything, we must set a scheduler for the normal business hours of 8:00 a.m. to 5:00 p.m., excluding weekends, to enforce company policy:

juniper@SRX5800# top
[edit]
juniper@SRX5800# edit schedulers scheduler
[edit schedulers scheduler]
juniper@SRX5800# set "http-business-hours" daily start-time 08:00:00
stop-time 17:00:00
[edit schedulers scheduler]
juniper@SRX5800# set "http-business-hours" sunday exclude
[edit schedulers scheduler]
juniper@SRX5800# set  "http-business-hours" saturday exclude

Now we can set up a pass-through authentication profile:

juniper@SRX5800# top
[edit]
juniper@SRX5800# set access profile web-allow-group radius-server 10.3.4.100
secret radius_secret_key retry 2
[edit]
juniper@SRX5800# set access firewall-authentication pass-through
default-profile web-allow-group http banner login
"PLEASE ENTER IN YOUR ACCOUNT INFO. FOR SUPPORT PLEASE CALL THE NOC AT
1-800-555-1212"

OK, now we need to write our policy to reference both the scheduler and the pass-through access profile:

[edit]
juniper@SRX5800# edit security policies from-zone dept-a to-zone internet
[edit security policies from-zone dept-a to-zone internet]
juniper@SRX5800# set policy "http_auth" match source-address users_segments
destination-address any application junos-https
[edit security policies from-zone dept-a to-zone internet]
juniper@SRX5800# set policy "http_auth" scheduler-name http-business-hours
[edit security policies from-zone dept-a to-zone internet]
juniper@SRX5800# set policy "http_auth" then permit firewall-authentication
pass-through access-profile web-allow-group

Finally, let’s take a look at the entire configuration and ensure that everything commits correctly:

juniper@SRX5800# show | compare
[edit security zones security-zone web-dmz address-book]
       address web2 { ... }
+      address web_server 172.31.100.60/32;
[edit security zones]
     security-zone CDN { ... }
+    security-zone internet;
+    security-zone dept-a {
+        address-book {
+            address users1 10.1.0.0/24;
+            address users2 10.1.2.0/24;
+            address-set users_segments {
+                address users1;
+                address users2;
+            }
+        }
+    }
+    security-zone mail-dmz {
+        address-book {
+            address mail_server 172.31.100.70/32;
+        }
+    }
[edit security]
+   policies {
+       from-zone internet to-zone web-dmz {
+           policy allow_http_from_web {
+               match {
+                   source-address any;
+                   destination-address web1;
+                   application junos-http;
+               }
+               then {
+                   permit;
+                   log {
+                       session-init;
+                       session-close;
+                   }
+               }
+           }
+       }
+       from-zone dept-a to-zone mail-dmz {
+           policy allow_users_to_mail {
+               match {
+                   source-address users_segments;
+                   destination-address mail_server;
+                   application mail_services;
+               }
+               then {
+                   permit;
+               }
+           }
+       }
+       from-zone mail-dmz to-zone internet {
+           policy permit_outbound_mail {
+               match {
+                   source-address mail_server;
+                   destination-address any;
+                   application mail_services;
+               }
+               then {
+                   permit;
+               }
+           }
+       }
+       from-zone internet to-zone mail-dmz {
+           policy permit_inbound_mail {
+               match {
+                   source-address any;
+                   destination-address mail_server;
+                   application mail_services;
+               }
+               then {
+                   permit;
+                   log {
+                       session-init;
+                       session-close;
+                   }
+               }
+           }
+       }
+       from-zone web-dmz to-zone internet {
+           policy permit_irc {
+               match {
+                   source-address web1;
+                   destination-address any;
+                   application tcp_6667;
+               }
+               then {
+                   permit;
+               }
+           }
+       }
+       from-zone dept-a to-zone internet {
+           policy http_auth {
+               match {
+                   source-address users_segments;
+                   destination-address any;
+                   application junos-https;
+               }
+               then {
+                   permit {
+                       firewall-authentication {
+                           pass-through {
+                               access-profile web-allow-group;
+                           }
+                       }
+                   }
+               }
+               scheduler-name http-business-hours;
+           }
+       }
+   }
[edit]
+  access {
+      profile web-allow-group {
+          radius-server {
+              10.3.4.100 {
+                  secret
"$9$VZsoGDjq5T3gonCu0cSjikPz6pu1hclp0Eyrex7F36Au1SyKMX-";
## SECRET-DATA
+                  retry 2;
+              }
+          }
+      }
+      firewall-authentication {
+          pass-through {
+              default-profile web-allow-group;
+              http {
+                  banner {
+                      login "PLEASE ENTER IN YOUR ACCOUNT INFO.
FOR SUPPORT PLEASE CALL THE NOC AT 1-800-555-1212";
+                  }
+              }
+          }
+      }
+  }
[edit applications]
    application windows_rdp { ... }
+   application tcp_6667 {
+       protocol tcp;
+       source-port 6667;
+       destination-port 1-65000;
+       inactivity-timeout 3600;
+   }
[edit applications]
    application-set web_mgt { ... }
+   application-set mail_services {
+       application junos-imap;
+       application junos-smtp;
+       application junos-pop3;
+   }
[edit]
+  schedulers {
+      scheduler http-business-hours {
+          daily {
+              start-time 08:00:00 stop-time 17:00:00;
+          }
+          sunday exclude;
+          saturday exclude;
+      }
+  }
[edit]
juniper@SRX5800# commit check
configuration check succeeds

After reviewing the changes and performing a commit check, everything looks good. Our SRX is now set up for the company when users come into the office.

Case Study 4-2

Objective: A new department is being added and their network configured on the company’s network, and while in a meeting to talk about their access requirements they stated they need the following networking requirements:

  • Full unfiltered Internet access

  • Full unfiltered access to the web and mail servers

  • Access from the Internet into their network segment so that they can host customer-facing web servers

Our strategy to achieve that objective is to evaluate how best to give them the requested access while maintaining network security. Figure 4-9 illustrates their needs.

Case Study 4-2’s objectives
Figure 4-9. Case Study 4-2’s objectives

This case study is more real-world than you might think. All too often, users (including management) do not understand the needs of their business or how to incorporate security into the workflow. External servers should never be on the same segment as users, and unfiltered access may sound like a good idea from a “getting things done” point of view, but in reality, policies can be written to allow the user department to do everything that they need to do while maintaining an acceptable level of security.

Corporate security policies should apply to everyone. They exist for a reason, and if it’s a corporation’s security policy to block P2P apps on its network, this should be done globally.

First, let’s set up their Internet access. We need to create a new zone for Dept-B, and we need to create address-books which should be put into an address-set.

[edit]
juniper@SRX5800# edit security zones security-zone
[edit security zones security-zone]
juniper@SRX5800# set dept-b
[edit security zones security-zone]
juniper@SRX5800# set dept-b address-book address users3 10.2.1.0/24
[edit security zones security-zone]
juniper@SRX5800# set dept-b address-book address users4 10.2.2.0/24
[edit security zones security-zone]
juniper@SRX5800# set dept-b address-book address users5 10.2.3.0/24
[edit security zones security-zone]
juniper@SRX5800# set dept-b address-book address-set dept_b_users address users3
[edit security zones security-zone]
juniper@SRX5800# set dept-b address-book address-set dept_b_users address users4
[edit security zones security-zone]
juniper@SRX5800# set dept-b address-book address-set dept_b_users address users5

Next, we should block a group of predetermined applications from accessing the Internet. We should put these applications into an address-set for ease of policy engineering, and we need to deny those applications via policy.

[edit security zones security-zone]
juniper@SRX5800# top
[edit]
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
[edit applications application-set]
juniper@SRX5800# top
[edit]
juniper@SRX5800# edit security policies from-zone dept-b to-zone internet
[edit security policies from-zone dept-b to-zone internet]
juniper@SRX5800# set policy "deny_bad_apps" match source-address dept_b_users
destination-address any application deny_services
[edit security policies from-zone dept-b to-zone internet]
juniper@SRX5800# set policy "deny_bad_apps" then deny log session-close
session-init

Don’t forget to add the policy that allows everything else! The new department’s users might be upset if all of their traffic was denied.

[edit security policies from-zone dept-b to-zone internet]
juniper@SRX5800# set policy "permit-to-internet-any" match source-address
dept_b_users destination-address any application any
[edit security policies from-zone dept-b to-zone internet]
juniper@SRX5800# set policy "permit-to-internet-any" then permit

Now that we’ve taken care of Internet access, the next order of business is access to the mail server. Using the application-set and mail address-book that we created earlier, all we really need to do is to create a policy to permit the traffic.

[edit security policies from-zone dept-b to-zone internet]
juniper@SRX5800# top
[edit]
juniper@SRX5800# edit security policies from-zone dept-b to-zone mail-dmz
[edit security policies from-zone dept-b to-zone mail-dmz]
juniper@SRX5800# set policy "permit_b_to_mail" match source-address dept_b_users
destination-address mail_server application mail_services
[edit security policies from-zone dept-b to-zone mail-dmz]
juniper@SRX5800# set policy "permit_b_to_mail" then permit

The last item is to address this new web server that Dept-B wants on the network. The web server should be moved to its own DMZ and policy specifically for that web server needs to be written:

[edit security policies from-zone dept-b to-zone mail-dmz]
juniper@SRX5800# top
[edit]
juniper@SRX5800# set security zones security-zone Bweb-dmz
[edit]
juniper@SRX5800# set security zones security-zone Bweb-dmz address-book
address web5 10.3.0.1/32
[edit]
juniper@SRX5800# edit security policies from-zone internet to-zone Bweb-dmz
[edit security policies from-zone internet to-zone Bweb-dmz]
juniper@SRX5800# set policy "permit_to_bweb" match source-address any
destination-address web5 application junos-http
[edit security policies from-zone internet to-zone Bweb-dmz]
juniper@SRX5800# set policy "permit_to_bweb" then permit
[edit security policies from-zone internet to-zone Bweb-dmz]
juniper@SRX5800# set policy "permit_to_bweb" then log session-close session-init

And if you noticed, as always, it’s suggested that you log the traffic from the Internet.

Now, let’s take a look at the entire configuration for Dept-B:

juniper@SRX5800# show | compare
[edit security zones]
     security-zone mail-dmz { ... }
+    security-zone dept-b {
+        address-book {
+            address users3 10.2.1.0/24;
+            address users4 10.2.2.0/24;
+            address users5 10.2.3.0/24;
+            address-set dept_b_users {
+                address users3;
+                address users4;
+                address users5;
+            }
+        }
+    }
+    security-zone Bweb-dmz {
+        address-book {
+            address web5 10.3.0.1/32;
+        }
+    }
[edit security policies]
     from-zone dept-a to-zone internet { ... }
+    from-zone dept-b to-zone internet {
+        policy deny_bad_apps {
+            match {
+                source-address dept_b_users;
+                destination-address any;
+                application deny_services;
+            }
+            then {
+                deny;
+                log {
+                    session-init;
+                    session-close;
+                }
+            }
+        }
+        policy permit-to-internet-any {
+            match {
+                source-address dept_b_users;
+                destination-address any;
+                application any;
+            }
+            then {
+                permit;
+            }
+        }
+    }
+    from-zone dept-b to-zone mail-dmz {
+        policy permit_b_to_mail {
+            match {
+                source-address dept_b_users;
+                destination-address mail_server;
+                application mail_services;
+            }
+            then {
+                permit;
+            }
+        }
+    }
+    from-zone internet to-zone Bweb-dmz {
+        policy permit_to_bweb {
+            match {
+                source-address any;
+                destination-address web5;
+                application junos-http;
+            }
+            then {
+                permit;
+                log {
+                    session-init;
+                    session-close;
+                }
+            }
+        }
+    }
[edit applications]
    application-set mail_services { ... }
+   application-set deny_services {
+       application junos-ymsg;
+       application junos-smtp;
+       application junos-msn;
+       application junos-irc;
+       application junos-gnutella;
+       application junos-aol;
+   }
[edit]
juniper@SRX5800# commit check
configuration check succeeds

The commit check appears to be successful and the configuration looks good. The new department can now come online without any issues and the security of the company has not been compromised.

Converters and Scripts

To help bridge the gap between the NetScreen system and the SRX system several tools have been developed. One such tool is the S2JES (ScreenOS to Junos-ES) converter. This is a free tool (it requires a valid login to http://www.juniper.net) that will convert a ScreenOS configuration file or syntax to Junos-ES. It can help with migration from a ScreenOS policy base to Junos policy. You can find the tool at https://i2j.juniper.net/s2jes/index.jsp.

Op scripts will also assist in migration efforts. Op scripts are SLAX or XSLT-based scripts that run directly on the SRX. These scripts are often developed by Juniper and by external users. You can use op scripts to view information in a summarized format or, for example, to run a series of health checks.

One of my favorite op scripts for the SRX is the policy test script. The policy test script will take input such as a source IP, destination IP, source port, or destination port and find any matching policies. All of these fields are optional, so the match can be as broad or as narrow as you want it to be.

Here is example output of the policy test script:

user@cli# op policy-test source-address 10.1.1.1 destination-address 10.2.2.2
From-Zone    To-Zone      Name            Src-Addr        Dst-Addr
Application  Action trust        untrust      ftp-permit      any             any
junos-ftp    permit trust        untrust      http-https-rej  any             any
junos-https  reject                                              junos-http

The policy test script found two policies that match the source/destination address. From the preceding output it appears that only FTP is allowed and HTTP/HTTPS is explicitly denied.

Other scripts mimic the output of ScreenOS-type commands, such as “get interface,” “get service,” and “get policy.” You can find these scripts in a number of places, but two of the major sites are:

http://www.juniper.net/us/en/community/junos/script-automation/library/
http://code.google.com/p/junoscriptorium/

You can find the policy test script shown earlier at the following URL:

http://www.juniper.net/us/en/community/junos/script-automation/library/configuration/policy-test/

Summary

The SRX security policy system is extremely flexible and straightforward. We will use security policies in later chapters to perform functions such as VPN, IDP, UTM, and more. The SRX exemplifies why a zone-based firewall is a better choice than a traditional interface-based firewall, and with more granular security and less work involved in assigning levels of trusts to their various zones, will make your life as a security engineer much better.

Although the SRX policy system doesn’t have complete feature parity with NetScreen’s, Juniper continues to make progress with its large resource base that is working on the SRX. New features such as additional ALGs are being deployed regularly with no signs of slowing down.

Chapter Review Questions

  1. How do you write a global security policy on an SRX?

  2. When writing security policies for traffic that the destination is NATed to, which IP address would you put in the security policy—the true destination address or the NATed IP address?

  3. What is the difference between deny and reject actions in a security policy?

  4. How do you view all active sessions from the 192.168.0.0 subnet?

  5. How do you filter denied traffic to a file called Deny_log?

  6. What are traceoptions and why would you use them to troubleshoot security policies?

  7. What are ALGs and what do they do?

  8. How can you, as the SRX administrator, limit access to specific network segments during nonbusiness hours?

  9. At what step does firewall policy lookup take place in the SRX flow process?

  10. What is the difference between a fast path and a slow path?

Chapter Review Answers

  1. Global security policies are not supported on the SRX. They are a legacy NetScreen feature and are not available today on the SRX platform.

  2. Destination NAT is applied before security policy is evaluated. As a result, all security policies must be written for the NATed address. Source NAT is applied after the security policy is evaluated and should be written for the nontranslated IP address.

  3. The deny action will silently drop the packet, where reject will send back an ICMP Port Unreachable to the source IP address. The deny action is usually the preferred method, unless it’s critical that the source IP address be notified that its traffic has been dropped by a firewall.

  4. To view all active sessions from the 192.168.0.0 subnet, use either:

    juniper@SRX5800> show security flow session source-prefix 192.168/16

    or:

    juniper@SRX5800> show security flow session source-prefix 192.168.0.0/16

    Either method is acceptable.

  5. To filter denied traffic to a file called Deny_log, first you will need to ensure that the security policy has logging enabled. Without that, nothing will be sent to the local syslogs. Once that is complete, you’ll need to specify a syslog file and filter for the RT_FLOW_SESSION_DENY string:

    [edit]
    juniper@SRX5800# set system syslog file Deny_log any any
    [edit]
    juniper@SRX5800# set system syslog file Deny_log match "RT_FLOW_SESSION_DENY"
  6. Traceoptions are much like debugs on the NetScreen platform. Traceoptions will monitor and record the packet as it’s evaluated through the various stages of packet processing. You can use traceoptions to verify that a packet is arriving on the correct interface and is being evaluated by the correct policy. You can also use traceoptions to ensure that the correct action is being taken (deny, permit, IDP, etc.) and to verify return traffic.

  7. Application layer gateways are Layer 6 and Layer 7 inspections of certain protocols by the SRX. They are used to assist with certain applications that have problems with stateful firewalls, and can be used to provide an additional layer of application security. ALGs monitor the control channel of a data connection for specific information so that the SRX can dynamically handle firewall pinholing and NAT translation.

  8. This is a perfect example of when to use policy schedulers. Policy schedulers can control when traffic is allowed (or denied) to network segments or services. Using policy schedulers, an SRX admin could lock down the payroll servers during nonbusiness hours by writing a policy scheduler that only permits traffic from 8:00 a.m. to 5:00 p.m. Monday through Friday.

  9. As shown in Figure 4-1 at the beginning of this chapter, security policy lookup takes place just after route lookup/destination zone lookup. It is critical to understand the flow processing, as it will often be used while troubleshooting traffic down the road.

  10. As a packet arrives on the interface of an SRX, an existing session lookup takes place. The SRX looks at the packet and tries to match it to an already established connection in the session table. If one is found, the SRX sends it down the fast path. If no session match is found, it is sent down the slow path.

    When a packet is sent down the slow path, the SRX must initially perform several checks when the new session is created, such as NAT, route lookup, and policy lookup, among others. Once those have been completed and the traffic is permitted, the SRX will build a session in the session table and all additional packets for that connection will take the fast path.

    The fast path just does some basic TCP checks and screens to ensure that everyone is playing nicely on this already allowed connection. Additionally, the SRX will do some ALG processing, and if an action such as IDP of VPNs exists, the action will also be processed.

Get Junos Security now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.