Which action in a security policy rule results in traffic being silently rejected?

Chapter 8. Security Policies

Security policies are at the core of applying the security mechanisms of the SRX. This makes logical sense because of the granular, flexible nature of the firewall rulebase. Up until this point, we have had various discussions about the platform-level support of the SRX, but now, as we enter the second half of the book, we focus in on the actual application of security features.

In this chapter, we begin by quickly reviewing the packet flow of the SRX, followed by a discussion of the related security policy components, and an in-depth discussion of the SRX policy configuration itself. We explore some additional security policy features like the Level 7 security features and ALGs. We conclude this chapter with some hands-on discussions of best practices, troubleshooting and device operations, and sample deployments. By the end of this chapter, you should be a pro at not only configuring security policies, but also properly designing an effective security policy in your network.

Packet Flow

Earlier in the book we reviewed the packet flow of an SRX, but it is helpful to briefly discuss it here as a refresher (or if you’re just reading this chapter out of the book by itself).

Figure 8-1 gives us a visual representation of the security policy. When it comes to security policy enforcement on the SRX, this is entirely handled on the data plane of the SRX, unlike ScreenOS, which would do at least the policy lookup on the control plane. Completely leveraging the data plane for the processing of security policies protects the SRX from succumbing to DoS attacks that could leave the management engine unavailable.

From a firewall policy enforcement perspective, it is important to understand that firewall policy lookup only happens once per session (with one slight exception to that), which is on the initial packet arriving for that flow. Every time a packet arrives, we check to see if it is part of a known session. If it is not part of an existing session, then we put it through the full slow path lookup, which includes performing NAT, route/switching lookups, and the firewall security policy in addition to the standard processing of screens, Level 3 or Level 4 enforcement checks, and ALG/services. Because this only needs to happen once, the performance is usually quite good.

For sessions that already match a known session, we don’t need to go through the entire lookup process. We simply match the session criteria to an existing session in the firewall session table, which gives us instructions on how to process existing flows (see Figure 8-1), including what firewall policy they are based on, NAT translation instructions, ALG and other Level 7 services, and so on.

Figure 8-1. Junos SRX packet flow

So you might be wondering what exactly makes up session criteria? There are a few things, so let’s look at the output of a session table entry.

Session ID: 936, Status: Normal, State: Active
Flag: 0x8100000
Policy name: GOutbound/12
Source NAT pool: Host-Outbound, Application: junos-https/58
Dynamic application: junos:AIM,
Application firewall rule-set: Allowed-Outbound, Rule: 1
Maximum timeout: 1800, Current timeout: 1624
Session State: Valid
Start time: 64145, Duration: 1922656
   In: 192.168.1.30/1454 --> 64.12.165.69/443;tcp,
    Interface: reth2.0,
    Session token: 0x5007, Flag: 0x621
    Route: 0x6353c2, Gateway: 192.168.1.30, Tunnel: 0
    Port sequence: 0, FIN sequence: 0,
    FIN state: 0,
    Pkts: 10888, Bytes: 545020
   Out: 64.12.165.69/443 --> 173.169.214.17/55484;tcp,
    Interface: reth0.0,
    Session token: 0x4006, Flag: 0x620
    Route: 0x627bc2, Gateway: 173.169.214.17, Tunnel: 0
    Port sequence: 0, FIN sequence: 0,
    FIN state: 0,
    Pkts: 10888, Bytes: 436945

From the output shown here, there are a number of values that we see in an individual session. These tell most of the story from a match criteria point of view.

• Source Interface (Reth2.0)

• Source IP Address (192.168.1.30)

• Destination IP Address (64.12.165.69)

• Source Port (1454)

• Destination Port (443)

• Protocol (TCP)

There is certainly additional information, such as the session ID (0x936), the NAT translation, route, outbound interfaces, and packet and byte counters. If you look closely, you can see that the SRX contains two parts of the session, the In and the Out “wings” as they are known. This allows the firewall to match the packets for both the ingress and egress interfaces, including with NAT transforms.

When it comes to the initial policy lookup, the SRX takes the following criteria into account to determine what policy to select (in no particular order). This is known as the nine-tuple. In the past, prior to Logical Systems (LSYS) and User Identity as part of UserFW, this was known as the seven-tuple.

1. Source zone (based on ingress logical interface)

2. Destination zone (based on the route/switching lookup to determine the egress interface)

3. Source IP address

4. Destination IP address (after static and destination NAT transform, so the security policy must match the translated destination IP address)

5. Source port

6. Destination port (after the destination NAT transformation so the security policy must match the translated destination port in the packet)

7. Logical system (if applicable, based on the ingress interface)

8. User identity (in Junos 12.1 and higher; see Chapter 12 for more details)

9. Protocol (what Level 3/Level 4 protocol)

It is important to note here that the destination/destination-static NAT takes place on the ingress before the policy lookup as we see in Figure 8-1, so your firewall policy has to take this into account to ensure that you’re matching the right parameters. Source/source-static NAT, on the other hand, is performed after the policy lookup, so you do not need to take it into account in the security policy configuration.

Security Policy Criteria and Precedence

Before we dive into the actual security policies themselves, we need to familiarize (or refamiliarize in some cases) ourselves with the various components that make up security policies. Typically, you will want to have these defined before configuring the security policies, or at least before you commit the configuration. The following are components of the security policies and their descriptions:

Zones

Each security policy will have two zones, a source and destination (or from/to) zone, with the exception of the global zone, which encompasses both the source and destination.

These are objects that either directly or indirectly refer to IP addresses or are groups of address objects. These can be applied to both the source and destination fields of the security policy. There are a few different types of address objects, which we explore shortly.

In ScreenOS these were known as service objects. For the purpose of this book, we refer to them with the same convention that is used in Junos, which is application objects. These refer to Level 3/Level 4 application objects, and not those of Level 7 or dynamic application objects that are used in the AppSecure policies. Application objects can include the Level 3/Level 4 protocol, along with port information for UDP/TCP, and type info for ICMP.

These are for the UserFW feature, which will explore in Chapter 12. They are visible in Junos 12.1 and newer, so if you are running an older version of Junos they won’t be applicable.

These define a time period for the policy to be active. This is useful if you want to apply different policies based on time of day or day of week, such as policies enforced during business hours.

The preceding objects primarily have to do with match criteria, but once a policy is matched, you need to decide what to do with it. If the action is to permit the traffic (from a security policy perspective), then additional processing can be done on the session to which it is matched. There are numerous types of action profiles including UTM, AppSecure, SSL Proxy, and a handful of others that we overview in this chapter and explore in greater depth in their respective chapters.

Security Policy Precedence

When it comes to a policy match, it is important to understand how the firewall evaluates security policies. Juniper calls a security policy context the policy that is within the same from-to-zone pair, for instance all policies within from-zone trust to-zone untrust are in the same context. In terms of context precedence, the SRX follows the following order:

1. Match intrazone policies: Evaluate the initial packet in an unknown session to determine if the source and destination zones are the same (e.g., from-zone trust to-zone trust). This would happen if both the ingress and egress interfaces are in the same zone. This context match has the highest precedence and will be matched first if it exists.

2. Match interzone policies: If the session does not match an intrazone context or policy, then the next thing to evaluate is if it matches a from-zone and to-zone context such as from-zone trust to-zone untrust. If the context matches, then the policies within the context will be evaluated for a match. Interzone policies will only be evaluated if there is no matching intrazone policy match, and happen before a global policy match.

3. Global policies: If there is no policy match for intrazone or interzone policies, then the next policy that would be matched would be global policies. This matches any zone context so to speak, but has the same match criteria for the policies as any other firewall policy (e.g., source address, destination address, application, user object, and so on). It is the last policy set to be evaluated after intrazone and interzone policies.

4. Default action: This is the action that should be taken if there is no match on intrazone, interzone, or global policies.

Note

For those of you migrating from ScreenOS, note that in ScreenOS interfaces in the same zone were permitted by default (intrazone blocking was off by default). With the SRX, intrazone blocking is always on, so you need to explicitly permit the traffic to communicate intrazone.

Top to Bottom Policy Evaluation

It is important to understand that the policy evaluation in the rulebase will be evaluated from the top of the rulebase down to the bottom. The first policy to match the criteria of the policy will be matched. This means that the firewall rules are terminal. All criteria must match the rule for it to considered a match; there are no partial matches. If no policy is matched, the firewall will evaluate the next context or default match in the same order that we just discussed: intrazone, then interzone, then global, and finally default.

Let’s look at the following sample policy, which includes intrazone, interzone, global, and a default match.

{primary:node0}[edit]
root@SRX550-Node0# show security policies
from-zone trust to-zone untrust {
    policy Block-FTP {
        match {
            source-address any;
            destination-address any;
            application junos-ftp;
        }
        then {
            deny;
            log {
                session-init;
            }
        }
    }
    policy Allow-Any {
        match {
            source-address any;
            destination-address any;
            application any;
        }
        then {
            permit;
            log {
                session-close;
            }
        }
    }
}
from-zone trust to-zone trust {
    policy Intra-zone {
        match {
            source-address any;
            destination-address any;
            application any;
        }
        then {
            permit;
        }
    }
}
global {
    policy deny-all-log {
        match {
            source-address any;
            destination-address any;
            application any;
        }
        then {
            deny;
            log {
                session-init;
            }
        }
    }
}
default-policy {
    deny-all;
}

You should be able to determine which policy is which. The policy called intrazone is an intrazone policy not merely because of its name, but because both the from- and to-zones are the same (“trust” in this case.) If the ingress and egress interface are both in the trust zone, we will match this policy. Next is the trust to untrust context, which has two rules. The first blocks FTP if it matches from any IP address while any other service is permitted. Order is important here because if the Allow-Any rule was first, we would never match the Block-FTP rule because of top-down precedence. Of course, this context will only be evaluated if the ingress and egress interfaces are in the trust and untrust zones, respectively. Let’s say that both interfaces are in the untrust zone; then we won’t match the intrazone or interzone policies because of the context match failure. Instead, they would match the global policy called deny-all-log.

In this example, there is no possibility of matching the “default-policy” action, which is deny all. This is because the match criteria for the global policy deny-all-log is any source, any destination, or any application, which essentially means everything. So why have a global policy if we could just do this with the default action? The answer is because with the default policy you can only permit or deny, but you can’t reject or log the traffic. It’s a good idea to configure the default policy just as a catchall in case you make a mistake but also leverage the global policy as your catchall. Of course, if you have catchall rules in your firewall contexts (like Allow-Any for the trust to untrust context), then as long as there is a context match (e.g., the from-zone is trust and the to-zone is untrust), you won’t evaluate further than that context.

Note

Global policies are supported in Junos 11.2r2 and 11.4+. If you are running an earlier version, only intrazone, interzone, and default actions are supported.

Security Policy Components in Depth

Now that we have overviewed the different components of the security policies, let’s dig into the individual elements and explore how they are configured and applied. In this section, we begin with the match criteria of security policies, which include the zones, address objects, and application objects. This is followed by a detailed look at the action components of the security policies.

Match Criteria

Before we can take any action on the traffic with our security policies, we need to identify how the traffic is matched. The match criteria do exactly what they state: they match traffic that falls within the range of the parameters defined. In a way, you can think of the match criteria as a filter set to match the values in that range.

Note

When working with match criteria, remember that the SRX is stateful, so it isn’t a strict static access list like those of older routing platforms where you might need to define both directions (depending on how it is defined). The SRX security policy only defines the initial packet parameters as the match criteria, and will automatically allow the return traffic for the session by installing a reverse “wing” as we will see later.

Security zones

As we mentioned earlier, the security zones allow us to define the origin and destination of the traffic passing through the SRX. The source zone (from-zone) defines the interface (or collection of interfaces that fall within that source zone), and the destination zone (to-zone) defines the egress interface (or pools of interfaces) for the traffic. Whereas the source interface is known when the traffic arrives on the SRX, the egress interface is not known until the policy lookup time when the SRX will either do a routing lookup (in Level 3 mode) or a switching lookup (in Level 2 mode).

One interface per zone versus multiple interfaces per zone

We’ve alluded to the fact that you can have one or more interfaces per zone. As you recall from Chapter 3, zones essentially define a security grouping of interfaces that you want to be classified with the same security level. You can still separate them with intrazone security policies, of course. One other reason to have multiple interfaces in the same zone is for traffic failover. Let’s say you have traffic arriving on ge-0/0/0 and leaving on interface ge-0/0/1, as shown in Figure 8-2. Then the interface ge-0/0/1 goes down, triggering a route failover to interface ge-0/0/2. As long as those interfaces are in the same zone, the traffic will be failed over to the other interface due to the route change. If the route were to point to an interface in a different zone, the traffic would be dropped because the interfaces aren’t in the same zone. This is true for both ingress and egress traffic.

Figure 8-2. Policy failover

Note

Remember that when we say interfaces we are really referring to logical interfaces, so you can have different logical interfaces on the same physical interfaces in different zones. For instance, ge-0/0/0.0 could be in zone trust, and ge-0/0/0.100 could be in zone untrust. These can also span the physical boundaries, so ge-0/0/0.0 could be in trust along with xe-0/1/0.0.

Configuring security zones

Just as a refresher, or for those who didn’t read Chapter 3, configuring the security zones is really quite simple. In this example, we configure two security zones, trust and untrust, for use in our upcoming examples. Security zone trust will have interface reth0.0, and security zone untrust will contain reth2.0.

{primary:node0}[edit]
root@SRX550-Node0# set security zones security-zone trust interfaces reth0.0

{primary:node0}[edit]
root@SRX550-Node0# set security zones security-zone untrust interfaces reth2.0

{primary:node0}[edit]
root@SRX550-Node0# show security zones
security-zone trust {
    interfaces {
        reth0.0;
    }
}
security-zone untrust {
    interfaces {
        reth2.0;
    }
}

In this example, we aren’t yet defining which interface is going to be the source or destination zone; that will be defined by our security policy context, as we showed earlier. The important thing to take in here is that we need to define the security zone as a classifier of the interface so that we can apply it to the security policies later on. This is different from some other competitive platforms that might have a flat rulebase (e.g., CheckPoint) and rely on the IP addresses to define direction. The direction of the traffic is inherently defined by the rulebase from-to-zones—with the exception of an intrazone or global policy. This is because the intrazone policy has the same source and destination zones so direction doesn’t matter as long as it’s within that context, and global is from any zone to any zone so it is zone agnostic, so to speak.

Address books

An address book is essentially a high-level container for the address objects that exist within it. By default, starting in Junos 11.2, there is a default address book called global. Other address books can be created and attached to individual zones. Prior to Junos 11.2, you had to define addresses under the zone configuration. This was less than ideal because you might have objects that need to be defined in duplicate zones, and also they couldn’t be used in other policies like NAT and IPS. We focus on defining the new model, because many of you will be doing new deployments or will be moving to post-11.2 releases if you haven’t already.

Note

From our perspective, it is best to just define objects in the global zone rather than applying them to individual zones. This is because you can reuse the objects rather than having to define them for each zone. On the other hand, if you are most security conscious, then defining them per zone has the slight advantage of not using them in security zones for which they weren’t intended. This is more of a corner case, however, because you still need to define the security policies to permit the traffic anyway.

In this example, we just show how addresses are added to the global address book, along with how to attach an address book called “trust” to zone trust.

{primary:node0}[edit]
root@SRX550-Node0# set security address-book global address Internal-Clients  1.1.1.0/24

{primary:node0}[edit]
root@SRX550-Node0# set security address-book global address Trust-Clients  2.1.1.0/24


{primary:node0}[edit]
root@SRX550-Node0# set security address-book trust attach zone trust

{primary:node0}[edit]
root@SRX550-Node0# show security address-book
global {
    address Internal-Clients 1.1.1.0/24;
}
trust {
    address Trust-Clients 2.1.1.0/24
    attach {
        zone trust;
    }
}

Address objects

Address objects are used to map an IP address to an object that can be used elsewhere in the device configuration, rather than strictly defining IP prefixes. This is much easier to deal with, particularly when you can tie a mnemonic name to the objects that will better classify what the IP object represents. This is useful for the same reason we have DNS: human-readable names are much easier for humans to remember than a series of numbers. Behind the scenes, the SRX doesn’t care at all about the object name but rather the IP address information it represents. Of course, you can always just make the object name the same as the IP address, or better yet, include a mnemonic name and the IP prefix information, which is the best of both worlds.

There are several different types of Address objects that you can leverage in the SRX policies, each of which we discuss in turn.

Note

You can only specify one type per object at a time, so you can’t have an object that is, say, both a wildcard and an IP prefix object at the same time. You can, however, define multiple objects and put them into a group.

IP prefix address objects

IP prefix objects are the simplest form of address objects that you can define, and the most traditional. Put simply, they define an IP prefix, as the name suggests. This means the IP network and netmask is given in the form X.X.X.X/YY where X is the IP address prefix and Y is the netmask in the shorthand notation. In the previous example for Internal-Clients, this was written as 1.1.1.0/24. Of course, IPv6 address prefixes are also supported using the standard IPv6 conventions (including the :: shorthand) and the shorthand netmask notation; for example, 2001::6:1/120.

Configuring IP prefix address objects

In this example, we configure an IP prefix object that will be tied to the global address book for the public DNS server 8.8.8.8, which is a Google Public DNS server. Google also has a public IPv6 DNS server 2001:4860:4860::8888 that we will add as well. Finally, we also attach a description to the object to specify that it is a public DNS server.

{primary:node0}[edit]
root@SRX550-Node0# set security address-book global address Public-DNS description "Public DNS Server" 8.8.8.8/32

root@SRX550-Node0# set security address-book global address IPv6-Public-DNS description "Public IPv6 DNS Server" 2001:4860:4860::8.8.8.8/128


{primary:node0}[edit]
root@SRX550-Node0# show security address-book
global {
    address Public-DNS {
        description "Public DNS Server";
        8.8.8.8/32;
    }
    address IPv6-Public-DNS {
        description "Public IPv6 DNS Server";
        2001:4860:4860::8.8.8.8/128;
    }

}

DNS address objects

Sometimes you have an object that might change its IP address from time to time, rather than setting a fixed IP address using the IP prefix option. The DNS address object type allows you to do exactly this. There are a few things that you should know about this.

• DNS objects require you to have a DNS server configured that the SRX can query. The queries will be sent from the INET.0 routing instance by default, but you can manipulate them to go through other interfaces or instances with routing.

• DNS objects can accept up to 32 IP addresses per DNS object at the time of writing this book.

• IPv4 and IPv6 are supported.

• The SRX honors the TTLs of the DNS objects that are defined by the DNS server. When the TTL expires, the SRX will requery the DNS server. If the response is different from the last values, the SRX will update the policy accordingly.

• All DNS queries are done in advance (at commit/ttl expire) rather than in real time for performance reasons. If an IP address changes, then the SRX will update on the next TTL expiration.

• If no DNS server is reachable or the host is unknown, the object will be left blank so you won’t be able to do any match with it.

Configuring DNS address objects

In this example, we configure the SRX to query an internal DNS server 192.168.0.50, and we create an object for www.juniper.net and attach it to the global address book.

{primary:node0}[edit]
root@SRX550-Node0# set system name-server 192.168.0.50

root@SRX550-Node0# show system name-server
192.168.0.50;

{primary:node0}[edit]
root@SRX550-Node0# set security address-book global address www.juniper.net dns-name www.juniper.net

{primary:node0}[edit]
root@SRX550-Node0# show security address-book
global {
    address www.juniper.net {
        dns-name www.juniper.net;
    }
}

Note

You might have noticed that you can also specify an IP prefix object as a DNS name. So what’s the difference? If you specify an IP prefix object as a DNS name, the SRX will resolve the name and will put it in the configuration as the IP address, meaning that it will not change in the future like a true DNS object. If you want the SRX to continuously resolve the DNS to IP mapping then you need to explicitly specify that it should use the DNS-Name as we did in this previous example.

## As IP Object ##
{primary:node0}[edit]
root@SRX550-Node0# set security address-book global address services.netscreen.com services.netscreen.com

{primary:node0}[edit]
root@SRX550-Node0# show security address-book
global {
    address services.netscreen.com 207.17.137.227/32;
}

## As DNS Object ##
{primary:node0}[edit]
root@SRX550-Node0# set security address-book global address services.netscreen.com dns-name services.netscreen.com

{primary:node0}[edit]
root@SRX550-Node0# show security address-book
global {
    address services.netscreen.com {
        dns-name services.netscreen.com;
    }
}

IP range objects

IP range objects were added in the Junos 12.1X45 release, allowing you to define a contiguous range of IP addresses. This is helpful when you need to define a range of IP addresses that doesn’t fit neatly with an IP prefix boundary without over- or underextending the access. At the time of writing this book, this feature is only supported by IPv4 and not IPv6. Essentially, you define the bottom and top IP addresses in the contiguous range, and it will create an object that is inclusive of the bottom and top IP addresses. For instance, if you defined an IP range object as 192.168.1.1 through 192.168.1.4, it would include 192.168.1.1, 192.168.1.2, 192.168.1.3, and 192.168.1.4.

Configuring IP range objects

In this example, we configure an IP range object called DHCP-Addresses-192.168.1.50-100 that includes IP addresses 192.168.1.50 through 192.168.1.100. We place it in the global address book and give it the description DHCP Client Range.

{primary:node0}[edit]
root@SRX550-Node0# set security address-book global address DHCP-Addresses-192.168.1.50-100 description "DHCP Client Range" range-address 192.168.1.50 to 192.168.1.100

{primary:node0}[edit]
root@SRX550-Node0# show security address-book
global {
    address DHCP-Addresses-192.168.1.50-100 {
        description "DHCP Client Range";
        range-address 192.168.1.50 {
            to {
                192.168.1.100;
            }
        }
    }
}

Wildcard address objects

Traditional IP address objects are useful when defining an IP host or IP prefix that you want to match in a policy. There are, however, some limitations with IP prefix-based matches. First, the subnet mask has to be contiguous, meaning that it starts as all 1s, and once a 0 bit is used, the rest of the values must be 0s. For instance

• Valid IP subnet (/24)

  • 11111111.11111111.11111111.00000000

• Invalid IP subnet, valid wildcard mask

  • 11111110.11111111.11111111.00000000

In this example, the first is a valid subnet mask because there are contiguous 1s followed by contiguous 0s. The second example is invalid because the last bit of the first octet is a 0, which is in between 1s. This is valid for a wildcard mask, though, and it would mean that we don’t care what that bit is. It does not have to be a match when comparing an IP address to the wildcard address or mask.

So why would you want to use this? Two scenarios can come up. First, you’re a totally old-school IOS administrator, and you still want to use wildcard matching in your devices like you did with old IOS access lists. More common, however, is that sometimes you can structure some really efficient security policies if your network follows a certain standard addressing scheme.

For instance, let’s say you operate a large retail environment with thousands of stores connected via a hub and spoke VPN. At every store the components have the same IP address with a different subnet. For example, the stores have their own class C in the 10.50.x.0/24 range. At each store the cash register is 10.50.x.100. You could make a wildcard mask that would be 10.50.0.100/255.255.0.255, which would match .100 for any subnet in the 10.50.x range.

Note

Unlike Cisco IOS, the Junos wildcard match does not require that you use inverse notation, but the same notation as subnet masks—it’s just that the contiguous restriction is relaxed. Second, at the time of writing this book, only IPv4 is supported for wildcard addresses, not IPv6.

With the preceding example, you could use this single address object in a policy at the head end, along with the branch networks to represent any cash register.

Configuring wildcard address objects

Let’s configure the example that we just discussed in the preceding section as a wildcard address for an object called Cash-Registers.

{primary:node0}[edit]
{primary:node0}[edit]
root@SRX550-Node0# set security address-book global address Cash-Registers description "All Corporate Cash Registers Wildcard Object" wildcard-address 10.50.0.100/255.255.0.255

{primary:node0}[edit]
root@SRX550-Node0# show security address-book
global {
    address Cash-Registers {
        description "All Corporate Cash Registers Wildcard Object";
        wildcard-address 10.50.0.100/255.255.0.255;
    }
}

Address sets

Now that we have explored creating the various types of individual address objects, you might find it useful to group these together for ease of use within other firewall frameworks such as security policies. Quite often in organizations there will be common requirements for similar types of access across different rules, so leveraging groups (particularly when it’s more than a few objects) is quite advantageous. In Junos, groups are known as sets; it is the same concept, just a different name.

You can have any number of different types of objects within a set (e.g., host, network, dns, wildcard, etc.) and even other groups (in Junos 11.2 and newer) within a group.

Configuring address sets

Address sets are very simple objects: you simply define them, specify which address or other address sets you would like to add, optionally define a description, and you’re good to go. The address set can then be used in place of individual address objects in a policy. In this example, we define two sets: one called Active-Directory with two objects (DC1: 192.168.1.1/32 and DC2: 192.168.4.1/32), and we include another address set in the Active Directory set called Exchange, which has one object called Mail1: 192.168.5.1/32.

[edit]
root@srx3600n0# edit security address-book global

[edit security address-book global]
root@srx3600n0# set address-set Active-Directory address DC1

[edit security address-book global]
root@srx3600n0# set address-set Active-Directory address DC2

 [edit security address-book global]
root@srx3600n0# set address-set Active-Directory description "Active Directory Domain Controllers"

 [edit security address-book global]
root@srx3600n0# set address DC1 192.168.1.1/32

[edit security address-book global]
root@srx3600n0# set address DC2 192.168.4.1/32

[edit security address-book global]
root@srx3600n0# set address Mail1 192.168.5.1/32

[edit security address-book global]
root@srx3600n0# set address-set Exchange address Mail1

[edit security address-book global]
root@srx3600n0# set address-set Exchange description "Exchange Servers"

[edit security address-book global]
root@srx3600n0# set address-set Active-Directory address-set Exchange

[edit security address-book global]
root@srx3600n0# show
address DC1 192.168.1.1/32;
address DC2 192.168.4.1/32;
address Mail1 192.168.5.1/32;
address-set Active-Directory {
    description "Active Directory Domain Controllers";
    address DC1;
    address DC2;
    address-set Exchange;
}
address-set Exchange {
    description "Exchange Servers";
    address Mail1;
}

Application objects

Similar to address objects, application objects allow you to specify objects to be used in the match criteria of security policies. For those of you who are coming from the world of ScreenOS, application objects are the same as service objects in ScreenOS; they are Layer 3 or Layer 4 objects for ports or protocols, rather than Layer 7 application objects that are dynamically determined by Application Identification (known as dynamic applications). These objects do not match any patterns using regex, unlike their Layer 7 counterparts, which we explore in Chapter 12.

The SRX does come with a list of prepopulated address objects so you don’t necessarily need to define your own unless it is truly a custom service.

Note

For some unknown reason, at the time of writing this book, there is still no official command to view the predefined application objects in Junos—but there is a trick to do this, which can also be used to view other Junos default configurations. The junos-defaults group is a hidden group, but if you just type it out, you can specify any modifier after it. In this case, it is applications, as we are at the base Junos Config level, but you could do security or security idp after it if you wanted for the same effect. The full output of this table is too long to list here, but you can check it out on your own system.

root@srx3600n0> 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;
}
#
# Network Basic Input Output System  - networking protocol used on
# Windows networks   session service port
#
application junos-netbios-session {
    protocol tcp;
    destination-port 139;
}
application junos-smb-session {
    protocol tcp;
    destination-port 445;
}

Application objects allow you to set numerous attributes to help define what the match criteria for this object should be. Let’s take a look at each attribute here:

[edit]
root@srx3600n0# set applications application Custom440 ?
Possible completions:
  application-protocol  Application protocol type
+ apply-groups         Groups from which to inherit configuration data
+ apply-groups-except  Don't inherit configuration data from these groups
  description          Text description of application
  destination-port     Match TCP/UDP destination port
  do-not-translate-A-query-to-AAAA-query  Knob to control the translation of A query to AAAA query
  do-not-translate-AAAA-query-to-A-query  Knob to control the translation of AAAA query to A query
  ether-type           Match ether type
  icmp-code            Match ICMP message code
  icmp-type            Match ICMP message type
  icmp6-code           Match ICMP6 message code
  icmp6-type           Match ICMP6 message type
  inactivity-timeout   Application-specific inactivity timeout (seconds)
  protocol             Match IP protocol type
  rpc-program-number   Match range of RPC program numbers
  source-port          Match TCP/UDP source port
> term                 Define individual application protocols
  uuid                 Match universal unique identifier for DCE RPC objects

Application protocol

This is used if you would like to monitor (or not monitor) an application on this port or protocol using an ALG. For instance, if you wanted to have the FTP Control session on port 10021, or maybe you didn’t want to listen for DNS on port 53, you could specify a custom application object and either specify the ALG you would like to use or ignore to disable it. Then you would use this object in the firewall policy accordingly.

Simply that: give this a description!

Defines what destination port should be used to match this object. Can be for TCP or UDP.

The SRX can automatically translate between IPv4 and IPv6 DNS objects, but this knob tells the SRX not to do this.

This is the opposite of the previous object, which is not to translate IPv6 into IPv4 objects.

This is useful for matching Level 2 objects in the policy, but not usually required.

If you’re matching the ICMP protocol, you can further filter down to individual ICMP codes rather than ICMP as a whole (IPv4).

In addition to ICMP codes, you can filter by types (IPv4).

Note

There is a full list of ICMP code/types available from IANA.

If matching ICMPv6, there are different codes than V4, so there is a different object if matching IPv6.

If matching ICMPv6, there are different types than V4, so there is a different object if matching IPv6.

Also known as the idle timeout that should be applied to this application object. By default, TCP has a 30-minute idle timeout, and UDP has a 60-second idle timeout. Known IP protocols have a 30-minute timeout, whereas unknown ones have a 60-second timeout. Setting the inactivity timeout is very useful, particularly if you are concerned about applications either timing out or remaining idle for too long and filling up the session table.

Note

Inactivity timeouts are only used when a session is idle, but not if it is closed by some other mechanism. For instance, if a TCP session is closed by a TCP FIN or Reset sequence, the SRX won’t wait for the idle timeout to kick in, and the session will be immediately closed. Other examples of closing a session would be as follows:

ALGs

For instance, the DNS ALG will close the session when the DNS reply arrives in response to a query, rather than wait the normal 60 seconds for UDP.

Services like IDP, AppSecure, UTM, and other objects can request a session to be closed—for instance, if an attack is seen and the setting is to close the session.

If the SRX administrator issues the clear security flow session command and the sessions are manually closed.

If in an HA cluster, the other node can inform the SRX to clear the session.

Note

Remember, the inactivity timeout is only used when the session is truly idle (no traffic is sent or received); as long as traffic is being sent and received, the idle timeout will be reset. It is only when there is no traffic seen that the idle timeout starts to decrease until it goes to 0 and the session is closed.

The protocol field refers to what IP protocol number you might be using for this value. For instance, you might specify TCP, UDP, or something else. If you only specified a destination port (e.g., 53) but no protocol, then the application would match either TCP or UDP for that destination port. Besides the known protocols shown here, you can also specify any other protocol number of your choosing 0–255.

root@srx3600n0# set applications application Custom440 protocol ?
Possible completions:
  <number>             Numeric protocol value (0 .. 255)
  ah                   IP Security authentication header
  egp                  Exterior gateway protocol
  esp                  IPSec Encapsulating Security Payload
  gre                  Generic routing encapsulation
  icmp                 Internet Control Message Protocol
  icmp6                Internet Control Message Protocol Version 6
  igmp                 Internet Group Management Protocol
  ipip                 IP in IP
  ospf                 Open Shortest Path First
  pim                  Protocol Independent Multicast
  rsvp                 Resource Reservation Protocol
  sctp                 Stream Control Transmission Protocol
  tcp                  Transmission Control Protocol
  udp                  User Datagram Protocol

This attribute is set if you want to specify a specific RPC program number if you are using the RPC ALG.

This parameter allows you to specify the source port to match for an application for UDP and TCP. Beware: usually you want to specify the destination port rather than the source port for most protocols, as the source port is randomly selected by the client machine OS. There are some scenarios where the source port might be fixed, and in these cases it could be ideal to use the source port parameter, but it is not common, particularly with contemporary applications.

If you are familiar with creating firewall filters and policy statements, you will be familiar with using terms in your policies. Term allows you to specify multiple criteria within a single object. For instance, let’s say you want to select multiple different ports for an application that can communicate over a set of different ports. You can use terms to specify multiple criteria rather than specifying multiple application objects and then putting them together in a set. You’ll see how to do this in our example coming up.

This is useful when using an RPC protocol to narrow down which UUIDs apply to the application rather than allowing any communication to go through.

Application sets

Just like address objects, you can define sets of applications or even other nested application sets so that you can provide for a cleaner policy rather than having to reference multiple application objects in the policy. You can use both predefined and custom-defined application objects. This is especially handy if you need to reuse these objects in multiple locations in the security policy.

Configuring applications and application sets

In this example, we create three custom applications: one for Remote Desktop on TCP port 3389: one for FTP on TCP port 10021 with the FTP ALG enabled; and one for a Custom DNS on UDP port 53 and UDP port 5353, with an inactivity timeout of four seconds, with the ALG disabled. All three of these custom applications will be grouped in an application set called Custom-App-Group.

[edit]
root@srx3600n0# set applications application Remote-Desktop protocol tcp destination-port 3389

root@srx3600n0# set applications application Custom-FTP application-protocol ftp protocol tcp destination-port 10021

[edit]
root@srx3600n0# set applications application Custom-DNS inactivity-timeout 4 term 1 protocol udp destination-port 53

[edit]
root@srx3600n0# set applications application Custom-DNS application-protocol ignore term 2 protocol udp destination-port 5353

root@srx3600n0# set applications application-set Custom-App-Group application Custom-DNS

[edit]
root@srx3600n0# set applications application-set Custom-App-Group application Custom-FTP

 [edit]
root@srx3600n0# set applications application-set Custom-App-Group application Remote-Desktop

[edit]
root@srx3600n0# show applications
application Remote-Desktop {
    protocol tcp;
    destination-port 3389;
}
application Custom-FTP {
    application-protocol ftp;
    protocol tcp;
    destination-port 10021;
}
application Custom-DNS {
    application-protocol ignore;
    inactivity-timeout 4;
    term 1 protocol udp destination-port 53;
    term 2 protocol udp destination-port 5353;
}
application-set Custom-App-Group {
    application Custom-DNS;
    application Custom-FTP;
    application Remote-Desktop;
}

Source-Identity

Starting in Junos 12.1, we can support an additional field in the SRX called Source-Identity, which serves as match criteria to identify a user tied to a source IP address. This is in addition to the other criteria of From-To-Zone, Source IP, Destination IP, and Application. We cover Source-Identity in depth in Chapter 12.

Negated source and destination objects

Starting in Junos 12.1X45, the SRX supports the ability to define objects to be excluded from firewall rules for source or destination address match criteria. Prior to 12.1X45, you could accomplish the same functionality, but it would take two rules: a specific rule with the exempted objects to be matched with a permit or deny action, then a second rule matching everything else with the opposite action. Negated Address support allows you to simplify your ruleset. Note that it is not supported for applications, just source and destination addresses.

[edit]
root# set security policies from-zone trust to-zone untrust policy Negate match ?
Possible completions:
  <[Enter]>            Execute this command
+ application          Port-based application
+ apply-groups         Groups from which to inherit configuration data
+ apply-groups-except  Don't inherit configuration data from these groups
+ destination-address  Match destination address
  destination-address-excluded  Exclude destination addresses
+ source-address       Match source address
  source-address-excluded  Exclude source addresses
+ source-identity      Match source identity
  |                    Pipe through a command

The source-address-excluded and destination-address-excluded are just attributes. When they are on, all addresses for the source, destination, or both will be excluded. It cannot be done on an individual object basis within the firewall rule itself, but can be applied to only source addresses, only destination addresses, or both.

Schedulers

Although not an explicit part of the match criteria, policy schedulers allow you to define when the policy is active, and thus are an implicit match criterion. They are useful for defining day-of-week and time-of-day criteria to determine when the policy will be active. For instance, you might want to define security policies that open or close access based on business hours. This can be both for permit and deny policies, but also for other Level 7 services like AppSecure (especially AppFW/AppQoS) and UTM (particularly URL Filtering). Often organizations use these to increase productivity by only allowing external web browsing during lunch and nonbusiness hours, or only permitting business partners to connect at certain times in conjunction with contracts.

Note

You can define multiple schedulers that can be defined in the system and applied to different policies, but only one scheduler can be active per policy.

When a scheduler is inactive, you can think of that policy as not existing. Similar to how the deactivate statement works, the policy lookup engine will bypass these policies.

For existing sessions, you can either choose to use Policy Rematch (which will re-evaluate sessions when a policy change occurs) or by default it will continue to take the original action of the original policy lookup.

In terms of scheduler components, they are very simple and contain the following parameters:

Day of week

Each individual weekday can be defined individually, along with the option to select all days.

For each day, you can define what time you want the policies to be active. This is done on a day-by-day basis unless you select daily, in which case it is applied evenly to all days.

You can define when you want this schedule to take effect from a year/month/day/time perspective if you want to stage changes for a future date.

Note

At the time of writing this book, you cannot define which weeks, months, or years you want the policy to be active, just on a day-of-week basis. Days of the week are the most common use case, but you could leverage Junos Scripts or Security Design to schedule policies to take place in a completely custom fashion if so desired.

Configuring schedulers

Now that we’ve looked at schedulers, we actually configure them in an example. Here we configure three different schedulers to examine the different options:

• Configure a scheduler called Business-Hours that is active Monday through Friday from 9 a.m. to 5 p.m. Apply this scheduler to a security policy called Allowed-Business-Hours.

• Configure a scheduler called All-Day-Friday that is active all day long on Friday and is applied to a policy called All-Day-Friday-Policy.

• Configure a scheduler called B2B-Contract that activates a policy on January 1, 2013, at 8 a.m. and is active until December 31, 2013, at 11:59 p.m. This policy should be active between 5 p.m. and 7 p.m. on Sundays, which is applied to a policy called B2B-Policy.

• Configure the SRX to reevaluate the security policies when the schedulers change status.

• Configure the SRX to get its time from NTP Server 192.168.50.50.

Note

It is very important that you have a reliable time source that the SRX can leverage when using schedulers, both for the SRX and the other devices connecting through it. If the SRX and the clients and servers have vastly differing clocks, this could result in unexpected results such as unintentional denial of access. This is not a concern that is specific to schedulers; there are plenty of reasons to have accurate time throughout your infrastructure. This just adds to the list.

[edit]
root@srx3600n0# set schedulers scheduler Business-Hours daily start-time 09:00 stop-time 17:00

 [edit]
root@srx3600n0# set schedulers scheduler Business-Hours saturday exclude

[edit]
root@srx3600n0# set schedulers scheduler Business-Hours sunday exclude

[edit]
root@srx3600n0# set security policies from-zone Trust to-zone Untrust policy Allowed-Business-Hours scheduler-name Business-Hours

[edit]
root@srx3600n0# set schedulers scheduler All-Day-Friday friday all-day

[edit]
root@srx3600n0# set schedulers scheduler B2B-Contract sunday start-time 17:00 stop-time 19:00

root@srx3600n0# set security policies from-zone Trust to-zone Untrust policy B2B-Policy scheduler-name B2B-Contract

from-zone Trust to-zone Untrust {
    policy Allowed-Business-Hours {
        scheduler-name Business-Hours;
    }
    policy All-Day-Friday-Policy {
        scheduler-name All-Day-Friday;
    }
    policy B2B-Policy {
        scheduler-name B2B-Contract;
    }
}
policy-rematch;

[edit]
root@srx3600n0# show system ntp
server 192.168.50.50;

Note

This security policy is technically incomplete because we haven’t defined the full match/then criteria, but for this example we are just highlighting the scheduler configuration. A complete example is shown in the section Sample Deployment later in this chapter.

Action Criteria

Now that we have covered the components that lead to matching actual firewall sessions, we next discuss the action criteria. Action criteria define the action the firewall should perform with the session once it’s been matched by the policy engine.

The action criteria available in security policies are broken down into the following areas:

Primary actions

These are the main actions that define how the traffic will be processed. Only one of these options can be configured in a single security policy rule, and one action must be configured or an error will be thrown at commit time.

Deny

The deny action instructs the firewall to silently drop all packets for the session. The firewall will not send any active control messages like TCP Resets or ICMP Unreachable messages when this option is enabled. Most often, the deny action is useful for hiding assets from untrusted resources. The lack of response makes identifying destinations in the packet much more difficult. Typically, scanners like NMAP and Nessus will try to scan and look at what responses are received, including to anomalous packets. The deny action provides them no response to work with and also causes the scan to take much longer, particularly if they are trying to be stealthy with longer timeouts.

When the reject action is configured, the SRX will send a TCP Reset if the protocol is TCP and an ICMP reset if it is UDP, ICMP, or any other IP protocol. This option is most useful when facing trusted resources so that the applications don’t spend unnecessary time waiting for timeouts and instead get the active message. Typically, reject isn’t recommended in segments that face untrusted resources because it gives attackers a bit more to key off of, but this isn’t a major concern, just a best practice to use deny in those cases.

Traffic is permitted at the Level 3/Level 4 level according to the security policy. That isn’t to say that the traffic couldn’t be blocked at some later point in the session by stateful firewall, ALG, UTM, IPS, and other services, but just based on the initial policy lookup the packet is permitted. We explore this option in greater detail in the next section.

These are parallel actions taken with the primary action. They are optional and independent of the primary action. Either one can be configured in any combination, as they are mutually exclusive.

Count

This action performs an internal counting function of the bytes transmitted in this policy. You can also set alarms based on thresholds per second or minute on a policy-by-policy basis. The count option is useful if you don’t have an external syslog server to monitor traffic consumption or if you are particularly interested in certain FW rules and the traffic behavior in them.

Logging is a very important option to configure in most cases. By default, the SRX will not log on any firewall rule passing through the device. This means that while a session is active you can view it in the session table, but after the session has ended there will not be a trace of it. Logging instructs the system to generate a log for the session. Logs can be generated on session initialization or on session close. The session-init logs are good for Deny/Reject policies when the traffic is immediately closed, or when you want to be notified when a session is opened, such as for troubleshooting purposes. Session Close is the ideal option when permitting traffic. Unlike Session Init, the close has a lot more information, such as the bytes or packets sent and received, the reason for closing the session, and Level 7 session information. Because this information is not known when the session is established, it can only be reported when the session is closed. The only downside to using session-close logs is that you only know about the session (from a logging perspective) when the session closes. This is normally fine, but if you are trying to troubleshoot, you might want to use Session Init as well. That’s right, you can configure both options. The main reason for not doing both is primarily the fact that you’ll be getting twice as many logs, but if that’s not a concern, then it’s fine.

Permit options

In the last section, we alluded to a number of options being available under the permit stanza, and we explore them in this section. The options available include launching Layer 7 services like AppSecure, UTM, IPS, SSL Proxy, Unified Access Control, Firewall Authentication, Policy-Based IPsec VPNs, TCP options, and destination NAT options. That sounds like a lot, and in a way it is. One question you might have is why we only have these options enabled under the permit stanzas rather than for deny and reject. The reason is simple: if the initial packet is blocked by policy (and thus the entire session) then there is really no reason to process the traffic further with other services, so those options don’t apply in the case of deny and reject.

We examine all of the available UTM, IPS, AppSecure, and IPsec options at length in their respective chapters, but we cover the other policy-based options in this chapter.

Note

There are some differences in the “then” actions between the high-end SRX and the branch SRX. For instance, at the time of writing this book, SSL Proxy and AppQoS are not available on the branch SRX, and UTM is not available on the high-end SRX. Some options, like services offload, are only available on the HE SRX and aren’t likely to be ported to the branch based on platform architecture.

**************************
From an SRX 3600 on 12.1R1
**************************
[edit]
root@srx3600n0# set security policies from-zone trust to-zone untrust policy 2 then permit ?
Possible completions:
  <[Enter]>            Execute this command
> application-services  Application Services
+ apply-groups         Groups from which to inherit configuration data
+ apply-groups-except  Don't inherit configuration data from these groups
> destination-address  Enable destination address translation
> firewall-authentication  Enable authentication for this policy if permit or tunnel
  services-offload     Enable services offloading
> tcp-options          Transmission Control Protocol session configuration
> tunnel               Tunnel packets
  |                    Pipe through a command
[edit]
root@srx3600n0# set security policies from-zone trust to-zone untrust policy 2 then permit application-services ?
Possible completions:
> application-firewall  Application firewall services
> application-traffic-control  Application traffic control services
+ apply-groups         Groups from which to inherit configuration data
+ apply-groups-except  Don't inherit configuration data from these groups
  gprs-gtp-profile     Specify GPRS Tunneling Protocol profile name
  gprs-sctp-profile    Specify GPRS stream control protocol profile name
  idp                  Intrusion detection and prevention
> ssl-proxy            SSL proxy services
> uac-policy           Enable unified access control enforcement of policy

************************
From an SRX100 on 12.1R1
************************
{primary:node0}[edit]
root@SRX100HM# set security policies from-zone trust to-zone untrust policy 2 then permit ?
Possible completions:
  <[Enter]>            Execute this command
> application-services  Application Services
+ apply-groups         Groups from which to inherit configuration data
+ apply-groups-except  Don't inherit configuration data from these groups
> destination-address  Enable destination address translation
> firewall-authentication  Enable authentication for this policy if permit or tunnel
> tcp-options          Transmission Control Protocol session configuration
> tunnel               Tunnel packets
  |                    Pipe through a command
{primary:node0}[edit]
root@SRX100HM# set security policies from-zone trust to-zone untrust policy 2 then permit application-services ?
Possible completions:
> application-firewall  Application firewall services
+ apply-groups         Groups from which to inherit configuration data
+ apply-groups-except  Don't inherit configuration data from these groups
  gprs-gtp-profile     Specify GPRS Tunneling Protocol profile name
  gprs-sctp-profile    Specify GPRS stream control protocol profile name
  idp                  Intrusion detection and prevention
  redirect-wx          Set WX redirection
  reverse-redirect-wx  Set WX reverse redirection
> uac-policy           Enable unified access control enforcement of policy
  utm-policy           Specify utm policy name

Configuring security policies

Now that we have examined the various options that are used to compose a security policy, let’s dig in and explore some different examples. After all, hands-on learning is much more effective than just studying the theory! In this example, we are going to configure five different policies with options as follows:

1. Policy from-zone trust to-zone untrust called Allow-Web that permits traffic from 192.168.1.0/24 to any destination on HTTP and HTTPS. Log traffic on this policy.

2. Policy from-zone trust to-zone untrust called NTP-DNS that permits traffic from any source in trust to time.nist.gov and 4.2.2.2 on NTP/DNS (udp) ports. Log this traffic.

3. All intrazone traffic from trust to trust should be permitted, but logged.

4. Allow inbound traffic from untrust to dmz called Email-Inbound, which allows SMTP traffic from any source to the DMZ email server 172.16.100.50.

5. Create a global rule to drop all traffic with logging.

6. Configure policy rematch.

7. Just for thoroughness, configure the policy engine to drop all unmatched traffic by default (note that this won’t take effect with the global policy, but we’ll just configure it anyway).

[edit]
root@srx3600n0# edit security policies from-zone trust to-zone untrust

[edit security policies from-zone trust to-zone untrust]
root@srx3600n0# set policy Allow-Web match source-address 192.168.1.0/24 destination-address any application [junos-http junos-https]

[edit security policies from-zone trust to-zone untrust]
root@srx3600n0# set policy Allow-Web then permit

[edit security policies from-zone trust to-zone untrust]
root@srx3600n0# set policy Allow-Web then log session-close

[edit security policies from-zone trust to-zone untrust]
root@srx3600n0# set policy NTP-DNS match source-address any destination-address [time.nist.gov 4.2.2.2] application [junos-dns-udp junos-ntp]

[edit security policies from-zone trust to-zone untrust]
root@srx3600n0# set policy NTP-DNS then permit

[edit security policies from-zone trust to-zone untrust]
root@srx3600n0# set policy NTP-DNS then log session-close

[edit security policies from-zone trust to-zone untrust]
root@srx3600n0# up

[edit security policies]
root@srx3600n0# set from-zone trust to-zone trust policy Allow-All match source-address any destination-address any application any

[edit security policies]
root@srx3600n0# set from-zone trust to-zone trust policy Allow-All then permit

[edit security policies]
root@srx3600n0# set from-zone trust to-zone trust policy Allow-All then log session-close

[edit security policies]
root@srx3600n0# set from-zone untrust to-zone dmz policy Email-Inbound match source-address any destination-address 172.16.100.50 application junos-smtp

[edit security policies]
root@srx3600n0# set from-zone untrust to-zone dmz policy Email-Inbound then permit

[edit security policies]
root@srx3600n0# set from-zone untrust to-zone dmz policy Email-Inbound then log session-close

[edit security policies]
root@srx3600n0# set global policy Deny-All-Log match source-address any destination-address any application any

root@srx3600n0# set global policy Deny-All-Log then deny

[edit security policies]
root@srx3600n0# set global policy Deny-All-Log then log session-init

root@srx3600n0# set policy-rematch

[edit security policies]
root@srx3600n0# set default-policy deny-all

[edit security]
root@srx3600n0# show policies
from-zone trust to-zone untrust {
    policy Allow-Web {
        match {
            source-address 192.168.1.0/24;
            destination-address any;
            application [ junos-http junos-https ];
        }
        then {
            permit;
            log {
                session-close;
            }
        }
    }
    policy NTP-DNS {
        match {
            source-address any;
            destination-address [ time.nist.gov 4.2.2.2 ];
            application [ junos-dns-udp junos-ntp ];
        }
        then {
            permit;
            log {
                session-close;
            }
        }
    }
}
from-zone trust to-zone trust {
    policy Allow-All {
        match {
            source-address any;
            destination-address any;
            application any;
        }
        then {
            permit;
            log {
                session-close;
            }
        }
    }
}
from-zone untrust to-zone dmz {
    policy Email-Inbound {
        match {
            source-address any;
            destination-address 172.16.100.50;
            application junos-smtp;
        }
        then {
            permit;
            log {
                session-close;
            }
        }
    }
}
global {
    policy Deny-All-Log {
        match {
            source-address any;
            destination-address any;
            application any;
        }
        then {
            deny;
            log {
                session-init;
            }
        }
    }
}
default-policy {
    deny-all;
}
policy-rematch;


[edit security]
root@srx3600n0# show address-book
global {
    address 192.168.1.0/24 192.168.1.0/24;
    address 4.2.2.2 4.2.2.2/32;
    address 172.16.100.50 172.16.100.50/32;
    address time.nist.gov {
        dns-name time.nist.gov;
    }
}

Note

If you haven’t noticed already, when you create a security policy rule it automatically places the rule at the bottom of the security policy context (e.g., trust to untrust) rather than at the top. The reason for this is because it stands the least likelihood of causing issues if you forget to specify where to put it. When using the CLI, you can use the insert command to move the policy statement in the policy set. If using J-Web or SD, you have options in the GUI to reorder the rule placement.

[edit]
root@srx3600n0# show security policies from-zone untrust to-zone trust
from-zone untrust to-zone trust {
    policy 3 {
        match {
            source-address any;
            destination-address any;
            application any;
        }
        then {
            permit {
                application-services {
                    idp;
                    ssl-proxy {
                        profile-name CA;
                    }
                }
            }
        }
    }
    policy 2 {
        match {
            source-address any;
            destination-address any;
            application any;
        }
        then {
            permit {
                application-services {
                    idp;
                }
            }
            log {
                session-close;
            }
        }
    }
}
default-policy {
    permit-all;
}

[edit]
root@srx3600n0# insert security policies from-zone untrust to-zone trust policy 2 before policy 3

[edit]
root@srx3600n0# show security policies from-zone untrust to-zone trust
policy 2 {
    match {
        source-address any;
        destination-address any;
        application any;
    }
    then {
        permit {
            application-services {
                idp;
            }
        }
        log {
            session-close;
        }
    }
}
policy 3 {
    match {
        source-address any;
        destination-address any;
        application any;
    }
    then {
        permit {
            application-services {
                idp;
                ssl-proxy {
                    profile-name CA;
                }
            }
        }
    }
}

Host security policies

There is one other type of security policy that was added in the Junos 11.2 time frame, which is to evaluate security policies for traffic originated from or terminated on the SRX itself. Prior to this feature being added, you could configure stateless firewall filters and apply them to the loopback interface or other transit interfaces, but this had its shortcomings. First, it was another place you had to look to evaluate access control. Second, firewall filters do not share the same address object and application object components, and they can’t be used with advanced actions like IPS. Heeding customer feedback, Juniper added the ability to configure security policies based on a new zone type called junos-host. If you want to control traffic from the SRX to an external destination, then you would leverage junos-host as the from-zone (and whatever pertinent zone the traffic will egress). If you want to define what traffic should be permitted to the firewall, then you would define firewall rules with junos-host as the destination zone.

Note

This feature only applies to traffic arriving or leaving on the data plane. If the traffic is terminated or generated on fxp0 of the control plane, this security won’t be enforced.

Configuring a policy to restrict inbound or outbound management requests

The concepts here are really no different than with other security policies, except by default the SRX will not filter traffic in these rules if they are not present. Let’s try an example: we will filter inbound connections so that SSH and HTTP are only permitted from the untrust zone from host 192.168.1.0/24 on the firewall itself. Let’s also restrict the firewall from any outbound connections to the untrust zone for security purposes.

[edit]
root@srx3600n0# set security policies from-zone untrust to-zone junos-host policy Allow-Management match source-address 192.168.1.0/24 destination-address 172.16.1.1 application [junos-ssh junos-http]

[edit]
root@srx3600n0# ...security policies from-zone untrust to-zone junos-host policy Allow-Management then permit

[edit]
root@srx3600n0# set security policies from-zone untrust to-zone junos-host policy Allow-Management then log session-close

[edit]
root@srx3600n0# set security policies from-zone untrust to-zone junos-host policy Deny-All-Else match source-address any destination-address any application any

[edit]
root@srx3600n0# set security policies from-zone untrust to-zone junos-host policy Deny-All-Else then deny

[edit]
root@srx3600n0# set security policies from-zone untrust to-zone junos-host policy Deny-All-Else then log session-init

[edit]
root@srx3600n0# set security policies from-zone junos-host to-zone untrust policy Deny-All match source-address any destination-address any application any

[edit]
root@srx3600n0# set security policies from-zone junos-host to-zone untrust policy Deny-All then deny

[edit]
root@srx3600n0# set security policies from-zone junos-host to-zone untrust policy Deny-All then log session-init


from-zone untrust to-zone junos-host {
    policy Allow-Management {
        match {
            source-address 192.168.1.0/24;
            destination-address 172.16.1.1;
            application [ junos-ssh junos-http ];
        }
        then {
            permit;
            log {
                session-close;
            }
        }
    }
    policy Deny-All-Else {
        match {
            source-address any;
            destination-address any;
            application any;
        }
        then {
            deny;
            log {
                session-init;
            }
        }
    }
}
from-zone junos-host to-zone untrust {
    policy Deny-All {
        match {
            source-address any;
            destination-address any;
            application any;
        }
        then {
            deny;
            log {
                session-init;
            }
        }
    }
}
[edit]
root@srx3600n0# set security zones security-zone untrust host-inbound-traffic system-services ssh

[edit]
root@srx3600n0# set security zones security-zone untrust host-inbound-traffic system-services http

[edit]
root@srx3600n0# show security zones security-zone untrust
host-inbound-traffic {
    system-services {
        ssh;
        http;
    }
}
interfaces {
    xe-1/0/1.0;
}

Note

You can also leverage the global security policies as a catchall here. Be sure that you allow the system service to listen on the ingress interface or else the system won’t activate the service on that interface (thus your policy will work but there won’t be any listener for the daemon on that interface). Also, as mentioned before, this only works for data plane connections, and not for those on fxp0. If you want to filter connections on fxp0, you will need to use traditional firewall filters and apply them to the lo0 interface.

Application Layer Gateways

We’d be remiss to not discuss ALGs in this chapter, as they very much have to do with security policies. Although many contemporary applications have shifted away from relying on multiple TCP/IP sessions per application session with another host, particularly to avoid using dynamic sessions and reverse connections from server to client, there are still many applications both legacy and modern that rely on this type of functionality. A prime example is FTP. Although there are many modes of FTP, the traditional active mode relies on a connection from the client to server on destination port 21, and the server makes a reverse connection back to the client on port 20. At the time that FTP was designed, access control (and stateful firewalls for that matter) were not as prevalent as they are today, nor were all of the security threats. Without an ALG to make this type of behavior work properly, you would have to create both a firewall rule to allow traffic outbound on port 21 and also inbound on port 20. This becomes an issue particularly if you are using NAT and if you can’t restrict down the server IPs. Other applications like FTP passive might have a standard control port like 21 from client to server, and the server provides the client with a dynamic port on which to make a second connection to the server, rather than having the server connect back to the client as in active mode. The issue here is that if you have a solid firewall policy, you won’t let some arbitrary dynamic connection outbound on an anomalous port. Again, we need something that can dynamically handle this, as shown in Figure 8-3.

Figure 8-3. FTP ALG flowchart

Many real-time voice and video protocols like SIP, H.323, RTSP, MGCP, and others have similar behaviors, along with data-driven protocols like RPC (MSRPC and SunRPC).

The solution to this problem is not to configure a wide open security policy (which probably wouldn’t work in scenarios with NAT anyway), but rather to leverage ALGs that can automate the process of dynamically opening “pinhole” sessions for you based on the application negotiation.

To explain this in more detail, an ALG works as follows:

1. A client makes a connection to a server on a control channel. This can be a well-known port or you can define a custom application with an ALG enabled in it as we did in the application configuration section. This traffic must be permitted by firewall policy.

2. The ALG inspects the connection and parses the information at Layer 7 to identify what port or protocol the auxiliary session will be required for.

3. The ALG creates a pinhole session in the firewall for the auxiliary dynamic session that is negotiated between the client and server. This session does not require an explicit policy in the security rulebase, and is derived based on the real-time traffic between the client and server.

4. Once the session is completed (e.g., TCP FIN/RST or application response such as a DNS reply or timeout), the auxiliary session and the control session will be cleared from the firewall session table.

It looks like the following in the session table. You can use the resource-manager qualifier to look for any sessions that are using ALGs, or you could also look it up by destination port. You can see when an ALG is active by the resource information.

{primary:node0}
root@SRX100HM> show security flow session resource-manager
node0:
--------------------------------------------------------------------------

Session ID: 7804, Policy name: General-Outbound/14, State: Active, Timeout: 1762, Valid
Resource information : FTP ALG, 20, 0
  In: 192.168.1.30/2634 --> 207.17.137.56/21;tcp, If: reth2.0, Pkts: 11, Bytes: 526
  Out: 207.17.137.56/21 --> 172.16.1.20/35732;tcp, If: reth0.0, Pkts: 10, Bytes: 623
Total sessions: 1

We can look for the pinhole sessions or “gates” that are dynamically opened from the ALG.

{primary:node0}
root@SRX100HM> show security flow gate
node0:
--------------------------------------------------------------------------

Hole: 207.17.137.56-207.17.137.56/0-0->172.16.1.20-172.16.1.20/20-20
  Translated: 207.17.137.56/0->192.168.1.30/0
  Protocol: tcp
  Application: FTP ALG
  Age: 65534 seconds
  Flags: 0x0020
  Zone: Danger
  Reference count: 3
  Resource: 6-13-8

Valid gates: 1
Pending gates: 0
Invalidated gates: 0
Gates in other states: 0
Total gates: 1

The following ALGs are available on the firewall platforms at the time of writing this book. Note that some are disabled by default.

root@srx3600n0> show security alg status
ALG Status :
  DNS      : Enabled
  FTP      : Enabled
  H323     : Disabled
  MGCP     : Disabled
  MSRPC    : Enabled
  PPTP     : Enabled
  RSH      : Enabled
  RTSP     : Disabled
  SCCP     : Disabled
  SIP      : Disabled
  SQL      : Enabled
  SUNRPC   : Enabled
  TALK     : Enabled
  TFTP     : Enabled
  IKE-ESP  : Disabled

Enabling an ALG example

Let’s enable the SIP ALG, which is disabled by default on the system. To do this we simply need to activate it in the security ALG stanza. Note that different ALGs have a variety of options, but digging into the various ALGs is outside the scope of this book, as they are not typically needed and are considered an advanced feature that you would perform with a strong understanding of the application or with the direction of JTAC.

[edit]
root@srx3600n0# set security alg sip

[edit]
root@srx3600n0# set security alg sip ?
Possible completions:
  <[Enter]>            Execute this command
> application-screen   Configure application screens
+ apply-groups         Groups from which to inherit configuration data
+ apply-groups-except  Don't inherit configuration data from these groups
  c-timeout            Set C timeout (3..10 minutes)
  disable              Disable SIP ALG
> dscp-rewrite         DSCP code rewrite
  inactive-media-timeout  Set inactive media timeout (10..2550 seconds)
  maximum-call-duration  Set maximum call duration (3..720 minutes)
  retain-hold-resource  Retain SDP resources during call hold
  t1-interval          Set T1 interval (500..5000 milliseconds)
  t4-interval          Set T4 interval (5..10 seconds)
> traceoptions         SIP ALG trace options
  |

Note

Remember that you can create custom Layer 3/Layer 4 application objects under set applications application, with which you can both enable or disable the ALGs for certain objects and reference them in policies if need be. An example would be if you wanted to run an ALG on a nonstandard port like FTP control channel on 10021 or disable an ALG like DNS so that it doesn’t automatically close the session when the response is received but instead waits for the UDP timeout.

ALGs also have the ability to control application behaviors, as we saw in the SIP ALG. Some ALGs like DNS do not open auxiliary sessions but operate to manipulate data like DNS Proxy, or to close sessions quickly like when a DNS response is heard. The options vary among ALGs. Other behaviors can also be controlled through Level 7 services like IPS.

Best Practices

Configuring security policies is really the easy part of implementing the SRX as an effective enforcement point in a network. The part that makes this more of an art than a science is specifically how you craft the rules and order, and how they interact with the traffic. There are several best practices that can be employed when defining an effective firewall policy.

Least privilege

This means that your firewall rules should be as tight as possible in terms of match criteria and permitting traffic. Only traffic that is permitted by organizational policy should be permitted; all other traffic should be denied. This is true not only for inbound security policies from the Internet to internal resources, but also from internal resource to other internal resources and outbound to the Internet. It takes more effort to design this than a policy that merely allows out traffic outbound, but this is the first fundamental step to ensuring that you have an effective security policy. A least privilege security policy cannot guarantee that threats cannot affect your network, but it can help to minimize your attack surface, which makes other controls more effective and the work of an attacker that much more difficult.

The SRX is a zone-based firewall, which means that you can place different interfaces into different zones. The SRX can only enforce traffic that crosses it, which means that you must properly design your network so that different resources are placed in a manner where the firewall can enforce controls (e.g., in different zones, or at least different interfaces on the firewall because you can still control traffic with an intrazone policy). Products like the UAC allow you to extend the security control to the access layer.

Typically, it is best to place the most explicit firewall rules at the top of the rulebase for any given context because we match traffic starting at the top of the rulebase, going down with the first match. If you place a less specific rule at the top, it is more likely to shadow the less specific rules lower down in the rulebase.

Address and application sets make administration of the firewall policies much simpler. First, they allow you to group large sets of objects so that you can reference them as a single object in the security policy. Second, changes to the group membership will automatically be updated into the security rules. The more rules you can reference to these groups, the simpler it is to make changes. Because most organizations have logical objects that can be grouped, these containers make perfect sense for the security policies.

Placing an any-any-any drop rule at the bottom of each security zone context (e.g., trust to untrust) along with the global policy is considered a best practice to ensure that undesired traffic is not leaked through the security policy. This doesn’t replace the need to properly define your firewall rules, but it does provide a simple catchall mechanism to capture unclassified traffic. Ideally, you should log this traffic.

Logging on all firewall policies is highly recommended for most environments. This gives you an audit trail of network activity both for troubleshooting and diagnosis. Because it’s difficult to retroactively collect this information, it is best to log and leverage a log collector like STRM, Splunk, Syslog-NG, or another application to manage the logs. The main reason you might not want to log on a policy rule would be the volume of logs it might generate. This is common in service provider environments where CPS are in the hundreds of thousands per second. For most other environments, it’s advisable (if not also required by organizational policy, laws, and regulations) to log firewall rules, both deny and permit.

Unless you are troubleshooting, it is typically best to use Log on Session Close instead of Log on Session Init when permitting traffic because it will include a great deal more information about the session that is useful for historical purposes. Log on Session Init is good for situations where you might have long-lived sessions and you are trying to do some troubleshooting or if you are dropping the traffic, because they will only be logged on session init.

Proper clock synchronization is key for many aspects of the security functionality. If the clock is wrong, not only will your log and troubleshooting information be incorrect, but security objects like schedulers will also have unintended impacts. NTP is a simple way to ensure that this won’t occur.

Use ALGs to open specific auxiliary sessions rather than wide open security policies. Data ALGs are enabled by default, but VoIP/Video ALGs are disabled by default.

Troubleshooting and Operation

Because security policies are the cornerstone of traffic processing on the SRX, it is imperative to have a solid understanding of their operation. There is a lot of data that can be gleaned from the various operational and troubleshooting facilities in security and flow processing, and we examine the most pertinent ones here.

Viewing Security Policies

Besides leveraging the configuration itself, you can view the security policies with the show security policies command. There are numerous parameters that you can use to filter the output returned. It is often helpful to view the firewall rules both before and after you create a rule to make sure that its creation and placement are correct. Here we show the various options to view the security policy along with the difference between the default output and the detailed output.

root@srx3600n0> show security policies ?
Possible completions:
  <[Enter]>            Execute this command
  application-firewall  Show the information of application-firewall
  count                Number of policies to show (1..65535)
  detail               Show the detailed information
  from-zone            Show the policy information matching the given source zone
  global               Show the policy information of global policies
  hit-count            Show the hit count of policies
  logical-system       Logical-system name
  policy-name          Show the policy information matching the given policy name
  root-logical-system  Root logical-system (default)
  start                Show the policies from a given position (1..65535)
  to-zone              Show the policy information matching the given destination zone
  zone-context         Show the count of policies in each context (from-zone and to-zone)
  |                    Pipe through a command

root@srx3600n0> show security policies
Default policy: permit-all
From zone: trust, To zone: untrust
  Policy: 1, State: enabled, Index: 4, Scope Policy: 0, Sequence number: 1
    Source addresses: any
    Destination addresses: any
    Applications: any
    Source identities: any
    Action: permit, application services, log
From zone: untrust, To zone: trust
  Policy: 3, State: enabled, Index: 5, Scope Policy: 0, Sequence number: 1
    Source addresses: any
    Destination addresses: any
    Applications: any
    Action: permit, application services
  Policy: 2, State: enabled, Index: 6, Scope Policy: 0, Sequence number: 2
    Source addresses: any
    Destination addresses: any
    Applications: any
    Action: permit, application services

root@srx3600n0> show security policies detail
Default policy: permit-all
Policy: 1, action-type: permit, State: enabled, Index: 4, Scope Policy: 0
  Policy Type: Configured
  Sequence number: 1
  From zone: trust, To zone: untrust
  Source addresses:
    any-ipv4(global): 0.0.0.0/0
    any-ipv6(global): ::/0
  Destination addresses:
    any-ipv4(global): 0.0.0.0/0
    any-ipv6(global): ::/0
  Application: any
    IP protocol: 0, ALG: 0, Inactivity timeout: 0
      Source port range: [0-0]
      Destination port range: [0-0]
  Source identities:
    any
  Per policy TCP Options: SYN check: No, SEQ check: No
  Intrusion Detection and Prevention: enabled
  Unified Access Control: disabled
  Session log: at-close
Policy: 3, action-type: permit, State: enabled, Index: 5, Scope Policy: 0
  Policy Type: Configured
  Sequence number: 1
  From zone: untrust, To zone: trust
  Source addresses:
    any-ipv4(global): 0.0.0.0/0
    any-ipv6(global): ::/0
  Destination addresses:
    any-ipv4(global): 0.0.0.0/0
    any-ipv6(global): ::/0
  Application: any
    IP protocol: 0, ALG: 0, Inactivity timeout: 0
      Source port range: [0-0]
      Destination port range: [0-0]
  Per policy TCP Options: SYN check: No, SEQ check: No
  Intrusion Detection and Prevention: enabled
  Unified Access Control: disabled
  SSL Proxy Profile Name: CA
Policy: 2, action-type: permit, State: enabled, Index: 6, Scope Policy: 0
  Policy Type: Configured
  Sequence number: 2
  From zone: untrust, To zone: trust
  Source addresses:
    any-ipv4(global): 0.0.0.0/0
    any-ipv6(global): ::/0
  Destination addresses:
    any-ipv4(global): 0.0.0.0/0
    any-ipv6(global): ::/0
  Application: any
    IP protocol: 0, ALG: 0, Inactivity timeout: 0
      Source port range: [0-0]
      Destination port range: [0-0]
  Per policy TCP Options: SYN check: No, SEQ check: No
  Intrusion Detection and Prevention: enabled
  Unified Access Control: disabled

Security policy tools

Besides looking at the security policy itself in the configuration or with the operational mode commands, there are some useful tools in the SRX that allow you to gain some additional information about the firewall rule usage along with the ability to determine what traffic will match which rules in the device. Here we look at both of these.

Hit Count:


root@srx3600n0> show security policies hit-count ?
Possible completions:
  <[Enter]>            Execute this command
  ascending            Ascending order
  descending           Descending order
  from-zone            Show the policy hit-count matching the given source zone
  greater-than         Minimum hit-count  (0..4294967295)
  less-than            Maximum hit-count  (0..4294967295)
  logical-system       Logical-system name
  root-logical-system  Root logical-system (default)
  to-zone              Show the policy hit-count matching the given destination zone
  |                    Pipe through a command
root@srx3600n0> show security policies hit-count
Logical system: root-logical-system
 Index   From zone        To zone           Name           Policy count
 1       trust            untrust           1              137398256
 2       untrust          trust             3              366305
 3       untrust          trust             2              0

Number of policy: 3


Match Policies

root@srx3600n0> show security match-policies source-ip 1.1.1.1 destination-ip 2.2.2.2 from-zone trust to-zone untrust destination-port 21 protocol tcp root-logical-system source-port 5000
Policy: 1, action-type: permit, State: enabled, Index: 4
0
  Policy Type: Configured
  Sequence number: 1
  From zone: trust, To zone: untrust
  Source addresses:
    any-ipv4(global): 0.0.0.0/0
    any-ipv6(global): ::/0
  Destination addresses:
    any-ipv4(global): 0.0.0.0/0
    any-ipv6(global): ::/0
  Application: any
    IP protocol: 0, ALG: 0, Inactivity timeout: 0
      Source port range: [0-0]
      Destination port range: [0-0]
  Source identities:
    any
  Per policy TCP Options: SYN check: No, SEQ check: No
  Intrusion Detection and Prevention: enabled
  Unified Access Control: disabled
  Session log: at-close

The Hit Count output is especially useful when you are operating with a very large policy set and you want to view which rules are being highly utilized and which ones might not be used at all. Particularly when you see rules that don’t have any hits, you might want to do some investigating to determine if they are being shadowed by another policy and thus are not active. The match policy allows you to take the flow criteria that would be evaluated for a session and see how they would be matched in the security policy. This is very telling and makes it much easier for an administrator to manage the device without having to manually generate traffic, which can be difficult to do, particularly for certain scenarios where you don’t control the resources. Do keep in mind that this command is a bit cumbersome in that you must specify all of the criteria, including source port and so forth. Because this is going to simulate a policy lookup, you cannot define IP prefixes or port ranges, but rather the atomic criteria that would normally be in a session.

Viewing the Firewall Session Table

One of the most powerful troubleshooting tools at your disposal is the contents of the session table. The session table in its entirety would probably result in information overload, but Junos has some excellent facilities to filter the contents of the session table down to individual sessions along with different criteria. We start by viewing the available criteria that you can choose from to filter the table, followed by the terse (default) output of this command and the extensive output of the command.

root@srx3600n0> show security flow session ?
Possible completions:
  <[Enter]>            Execute this command
  application          Application protocol name
  application-firewall  Show application-firewall sessions
  application-firewall-rule-set  Show application-firewall session by rule-set
  application-traffic-control  Show application-traffic-control sessions
  application-traffic-control-rule-set  Show application-traffic-control session by rule-set
  brief                Show brief output (default)
  destination-port     Destination port (1..65535)
  destination-prefix   Destination IP prefix or address
  dynamic-application  Dynamic application name
  dynamic-application-group  Dynamic application group name
  encrypted            Show encrypted traffic
  extensive            Show detailed output
  family               Protocol family
  idp                  IDP sessions
  interface            Name of incoming or outgoing interface
  logical-system       Logical-system name
  nat                  Sessions with network address translation
  protocol             IP protocol number
  resource-manager     Sessions with resource manager
  root-logical-system  Root logical-system (default)
  services-offload     Services-offload sessions
  session-identifier   Show session with specified session identifier
  source-port          Source port (1..65535)
  source-prefix        Source IP prefix or address
  summary              Show output summary
  tunnel               Tunnel sessions
  |                    Pipe through a command

root@srx3600n0> show security flow session
Flow Sessions on FPC3 PIC0:

Session ID: 60000167, Policy name: 1/4, Timeout: 1800, Valid
  In: 10.102.1.87/48308 --> 10.102.2.186/80;tcp, If: xe-1/0/0.0, Pkts: 6, Bytes: 548
  Out: 10.102.2.186/80 --> 10.102.1.87/48308;tcp, If: xe-1/0/1.0, Pkts: 5, Bytes: 4448

Session ID: 60000414, Policy name: 1/4, Timeout: 1800, Valid
  In: 10.102.1.148/8191 --> 10.102.2.160/80;tcp, If: xe-1/0/0.0, Pkts: 297, Bytes: 15684
  Out: 10.102.2.160/80 --> 10.102.1.148/8191;tcp, If: xe-1/0/1.0, Pkts: 302, Bytes: 443622

root@srx3600n0> show security flow session extensive
Flow Sessions on FPC3 PIC0:

Session ID: 60000014, Status: Normal
Flag: 0x80000042
Policy name: 1/4
Source NAT pool: Null, Application: junos-dns-udp/16
Dynamic application: junos:DNS,
Application traffic control rule-set: INVALID, Rule: INVALID
Maximum timeout: 2, Current timeout: 2
Session State: Valid
Start time: 698343, Duration: 0
   In: 10.102.1.69/47144 --> 10.102.2.106/53;udp,
    Interface: xe-1/0/0.0,
    Session token: 0x6, Flag: 0x2621
    Route: 0xa40010, Gateway: 10.102.1.69, Tunnel: 0
    Port sequence: 0, FIN sequence: 0,
    FIN state: 0,
    Pkts: 1, Bytes: 72
   Out: 10.102.2.106/53 --> 10.102.1.69/47144;udp,
    Interface: xe-1/0/1.0,
    Session token: 0x7, Flag: 0x2620
    Route: 0x1be0010, Gateway: 10.102.2.106, Tunnel: 0
    Port sequence: 0, FIN sequence: 0,
    FIN state: 0,
    Pkts: 1, Bytes: 88

Session ID: 60000024, Status: Normal
Flag: 0x42
Policy name: 1/4
Source NAT pool: Null
Dynamic application: junos:RPC,
Application traffic control rule-set: INVALID, Rule: INVALID
Maximum timeout: 60, Current timeout: 54
Session State: Valid
Start time: 698338, Duration: 5
   In: 10.102.1.162/46036 --> 10.102.2.33/63413;udp,
    Interface: xe-1/0/0.0,
    Session token: 0x6, Flag: 0x2621
    Route: 0x450010, Gateway: 10.102.1.162, Tunnel: 0
    Port sequence: 0, FIN sequence: 0,
    FIN state: 0,
    Pkts: 2, Bytes: 268
   Out: 10.102.2.33/63413 --> 10.102.1.162/46036;udp,
    Interface: xe-1/0/1.0,
    Session token: 0x7, Flag: 0x2620
    Route: 0x1030010, Gateway: 10.102.2.33, Tunnel: 0
    Port sequence: 0, FIN sequence: 0,
    FIN state: 0,
    Pkts: 2, Bytes: 152

root@srx3600n0> show security flow session summary
Flow Sessions on FPC3 PIC0:
Unicast-sessions: 3365
Multicast-sessions: 0
Services-offload-sessions: 0
Failed-sessions: 0
Sessions-in-use: 4724
  Valid sessions: 3334
  Pending sessions: 0
  Invalidated sessions: 1390
  Sessions in other states: 0
Maximum-sessions: 131072

Flow Sessions on FPC4 PIC0:
Unicast-sessions: 11286
Multicast-sessions: 0
Services-offload-sessions: 0
Failed-sessions: 1376487
Sessions-in-use: 13053
  Valid sessions: 11739
  Pending sessions: 3
  Invalidated sessions: 1311
  Sessions in other states: 0
Maximum-sessions: 262144

Flow Sessions on FPC5 PIC0:
Unicast-sessions: 12132
Multicast-sessions: 0
Services-offload-sessions: 0
Failed-sessions: 736153
Sessions-in-use: 14059
  Valid sessions: 12141
  Pending sessions: 0
  Invalidated sessions: 1918
  Sessions in other states: 0
Maximum-sessions: 262144

Flow Sessions on FPC6 PIC0:
Unicast-sessions: 12559
Multicast-sessions: 0
Services-offload-sessions: 0
Failed-sessions: 1084150
Sessions-in-use: 14522
  Valid sessions: 12487
  Pending sessions: 1
  Invalidated sessions: 2034
  Sessions in other states: 0
Maximum-sessions: 262144

As you can see, Junos offers a very extensive set of options when it comes to filtering the session table. You can filter on just about any session property. If you just need an overview, you can use the show security flow session command with modifiers to dump the matching sessions. This is good if you just need basic information about the sessions like the Flow info (including NAT translations), policy match, timeout, and the packets and bytes that are sent in both directions. You can also issue the extensive modifier after show security flow session and any optional filters to get the full details of the individual session. Finally, we showed session summary information. Note that this was done on a high-end SRX, so you can see the breakout of the session table on each of the SPUs. This includes open sessions, those that are pending termination (invalidated sessions), pending sessions (those that are being created), and counters on failed counters and the maximum number of firewall sessions per SPU.

Let’s look at the output of one of the preceding sessions and dissect what each field stands for.

root@srx3600n0> show security flow session
Flow Sessions on FPC3 PIC0:

Session ID: 60000167, Policy name: 1/4, Timeout: 1800, Valid
  In: 10.102.1.87/48308 --> 207.102.2.186/80;tcp, If: xe-1/0/0.0, Pkts: 6, Bytes: 548
  Out: 207.102.2.186/80 --> 173.167.229.50/59201;tcp, If: xe-1/0/1.0, Pkts: 5, Bytes: 4448

The following output indicates that this session has the unique ID of 60000167 on the platform. It matches Policy name 1, and the timeout is 1,800 seconds. While a session is actively transmitting data, you will see the maximum timeout for that service. In this case, TCP is 30 minutes or 1,800 seconds. Valid indicates the state of that session. Other states can be pending (creation), invalid (terminated, waiting for garbage cleanup), and backup (HA).

We also see there is an IN and an OUT portion of this session. These refer to the two wings of the session, or in this case, the traffic that arrives on the firewall from client to server, and the return traffic from server to client. We see different IP addresses here because we are using source NAT for this session, so the traffic arrives from source 10.102.1.87 source port 48308 to destination 207.102.2.186 on destination port 80. The traffic arrives on interface xe-1/0/0.0. At the time of polling this command, we have seen 6 packets/528 bytes of data in this direction.

The OUT direction indicates the return of the traffic. We notice that now the server is the source and there is a different IP address in the destination because we are performing source NAT on the traffic, and the session table shows the wings exactly as they are installed on the device for how the SRX should handle the traffic as it arrives. The destination port of the OUT direction is also different from the original source port, which means that we must also be doing port overloading in the source NAT. We also see that the traffic arrives on the device on port xe-1/0/1.0 and has seen 5 packets/4,448 bytes in the server-to-client direction.

Different NAT scenarios will look different in the session table; for instance, with destination NAT you would see the translated source in the OUT direction, and if you do both source and destination NAT, both criteria would be translated in the return direction. The firewall leverages the translated data in the OUT direction because it needs to be able to perform a fast lookup when the return traffic arrives on the device. That way, we only need to do the NAT policy lookup once, then the transform instructions are attached to the firewall session behind the scenes so that we can perform fast path processing from that point on.

Sample firewall logs

Although looking at counters and session tables is useful when the traffic is live on the device, they don’t give you a good audit capability, particularly after the session has closed. When it comes to firewall logs, there are three different types that we’re interested in: deny logs, and session init and close logs for permitted traffic. There are three different types of data plane logs today on the SRX: standard syslog, structured syslog, and binary syslog. All three essentially contain the same information but in different formats. In this example, we dissect structured syslog (which includes the field headers) for each event.

Session close:

<14>1 2012-11-19T02:40:08.985 SRX210-HoneyNet RT_FLOW - RT_FLOW_SESSION_CLOSE [ reason="timeout" source-address="64.40.9.8" source-port="51697" destination-address="172.16.42.204" destination-port="53" service-name="junos-dns-udp" nat-source-address="64.40.9.8" nat-source-port="51697" nat-destination-address="172.16.42.204" nat-destination-port="53" src-nat-rule-name="None" dst-nat-rule-name="None" protocol-id="17" policy-name="Allow-Internet" source-zone-name="LAN" destination-zone-name="HoneyNet" session-id-32="23211" packets-from-client="1" bytes-from-client="64" packets-from-server="1" bytes-from-server="3863" elapsed-time="2" application="junos:DNS" nested-application="UNKNOWN" username="N/A" roles="N/A" packet-incoming-interface="ge-0/0/0.0" encrypted="UNKNOWN"]

We won’t go through every single field in this session because there are a lot, but we do cover the main ones. We can see this log was generated on an SRX called SRX210-HoneyNET. The source address was 64.40.9.8 and the destination was 172.16.42.204 with a destination port of 53, so we can assume the traffic was DNS. Because there was no NAT configured, we don’t see any source or destination NAT rules, but if it was configured, we would see the name accordingly. The source zone of the traffic is LAN and the destination is Honeynet using the firewall policy Allow-Internet. Additionally, information about the bytes and packets sent and received is included. The elapsed time is the amount of time the session was active. The Application field is the Level 7 application, which is junos:DNS. There is no nested application here. If we were using the UserFW feature, then we would have a username and role here. We can see the traffic originated on interface ge-0/0/0.0. Encrypted refers to traffic like SSL that can be decrypted, so the answer here is really no. You can also see that the session was closed due to a timeout, which means that the ALG was likely disabled, otherwise we would have seen a message about the ALG closing the session. When TCP is used, we usually see TCP FIN or TCP RST, although there can be plenty of other reasons a session might be closed, including Layer 7 features like IPS, UTM, manually cleared by the administrator, HA, and others.

Note

If you’re wondering, RT stands for real time in the logs, which is the name of the subsystem that handles the logging on the data plane. It is called real time because it isn’t saved to disk or memory (at least not on the data plane; it can be sent to the control plane).

Session init (Create):

<14>1 2012-11-19T03:02:24.173 SRX210-HoneyNet RT_FLOW - RT_FLOW_SESSION_CREATE [ source-address="98.109.158.154" source-port="1329" destination-address="172.16.42.205" destination-port="139" service-name="junos-smb" nat-source-address="98.109.158.154" nat-source-port="1329" nat-destination-address="172.16.42.205" nat-destination-port="139" src-nat-rule-name="None" dst-nat-rule-name="None" protocol-id="6" policy-name="Allow-Internet" source-zone-name="LAN" destination-zone-name="HoneyNet" session-id-32="30171" username="N/A" roles="N/A" packet-incoming-interface="ge-0/0/0.0" application="UNKNOWN" nested-application="UNKNOWN" encrypted="UNKNOWN"]

When you have the session-init option enabled to log traffic that is permitted, the output of the syslog will look like what we just saw. Unlike the deny traffic that follows, we do see information about the NAT rules and session info, in addition to the basic flow and policy info. We don’t have all of the same data that are available in the session-close log because this can only be gleaned at the end of the session.

Session deny:

<14>1 2012-11-19T02:55:08.975 SRX210-HoneyNet RT_FLOW - RT_FLOW_SESSION_DENY [ source-address="192.168.4.30" source-port="3690" destination-address="172.16.42.20" destination-port="55" service-name="None" protocol-id="6" icmp-type="0" policy-name="Block-Internal-Else" source-zone-name="LAN" destination-zone-name="HoneyNet" application="UNKNOWN" nested-application="UNKNOWN" username="N/A" roles="N/A" packet-incoming-interface="ge-0/0/0.0" encrypted="UNKNOWN" reason="policy deny"]

It’s easy to see that this session was denied by the reason field "policy deny" along with the fact that the log is called RT_FLOW_SESSION_DENY. Just like the preceding output, the fields are pretty much the same, but because no traffic is allowed to flow in this output, there are no data-like bytes and packets sent and received. Because the traffic is blocked at the firewall level, there isn’t information about the NAT rules or session information like we see in the session-init for permitted traffic.

Note

At the time of writing this book, you MUST use the session-init option on deny/rejected traffic to log it. Session-close will only work for permitted traffic; if you aren’t seeing denied traffic in your log system, that’s probably why.

Of course all of this information is in the raw text of the syslog messages. Syslog collection platforms like STRM, Security Insight, Splunk, Arcsight, and others can do a much better job of representing the data. When using external log collectors, it is usually best to use structured syslog unless they natively understand the messages (or have the binary dictionary); otherwise the logs might just be a flat text string.

Monitoring Interface Counters

There are a number of interface counters that are very helpful when it comes to troubleshooting. If you use the extensive parameter with the show interfaces operational mode command, you will get both the traditional information that you would see in other platforms and some very helpful information that is pertinent to the SRX as a security platform, most notably the flow error statistics on a per-interface basis (logged on the ingress interface). Most of these errors are self-explanatory. You can clear the stats with clear interface statistics or specify an interface to clear if you are troubleshooting and you want to watch how fast these counters are increasing. The error statistics can represent issues with processing traffic, as well as potential attacks from malicious parties, so it’s not necessarily unlikely to see these counters present. You can further leverage flow traces to get more information about individual sessions—this is just a very quick sanity check.

root@srx3600n0> show interfaces xe-1/0/0.0 extensive
  Logical interface xe-1/0/0.0 (Index 70) (SNMP ifIndex 570) (Generation 135)
    Flags: SNMP-Traps 0x0 Encapsulation: ENET2
    Traffic statistics:
     Input  bytes  :         554090633312
     Output bytes  :         568304820836
     Input  packets:           3068138050
     Output packets:           1214983255
     IPv6 transit statistics:
      Input  bytes  :                   0
      Output bytes  :                   0
      Input  packets:                   0
      Output packets:                   0
    Local statistics:
     Input  bytes  :             21417726
     Output bytes  :             15835172
     Input  packets:               244984
     Output packets:               218750
    Transit statistics:
     Input  bytes  :                    0                    0 bps
     Output bytes  :                    0                    0 bps
     Input  packets:                    0                    0 pps
     Output packets:                    0                    0 pps
     IPv6 transit statistics:
      Input  bytes  :                   0
      Output bytes  :                   0
      Input  packets:                   0
      Output packets:                   0
    Security: Zone: trust
    Allowed host-inbound traffic : bootp bfd bgp dns dvmrp igmp ldp msdp nhrp ospf pgm pim rip router-discovery rsvp sap vrrp dhcp finger ftp tftp ident-reset http https ike netconf ping reverse-telnet
    reverse-ssh rlogin rpm rsh snmp snmp-trap ssh telnet traceroute xnm-clear-text xnm-ssl lsping ntp sip r2cp
    Flow Statistics :
    Flow Input statistics :
      Self packets :                     14325
      ICMP packets :                     6
      VPN packets :                      0
      Multicast packets :                0
      Bytes permitted by policy :        274623218636
      Connections established :          110601667
    Flow Output statistics:
      Multicast packets :                0
      Bytes permitted by policy :        501476506302
    Flow error statistics (Packets dropped due to):
      Address spoofing:                  0
      Authentication failed:             0
      Incoming NAT errors:               0
      Invalid zone received packet:      0
      Multiple user authentications:     0
      Multiple incoming NAT:             0
      No parent for a gate:              0
      No one interested in self packets: 0
      No minor session:                  0
      No more sessions:                  2061160
      No NAT gate:                       0
      No route present:                  40
      No SA for incoming SPI:            0
      No tunnel found:                   0
      No session for a gate:             0
      No zone or NULL zone binding       0
      Policy denied:                     0
      Security association not active:   0
      TCP sequence number out of window: 1037145
      Syn-attack protection:             0
      User authentication errors:        0
    Protocol inet, MTU: 1500, Generation: 154, Route table: 0
      Flags: Sendbcast-pkt-to-re
      Addresses, Flags: Is-Preferred Is-Primary
        Destination: 10.102.1/24, Local: 10.102.1.1, Broadcast: 10.102.1.255, Generation: 140
      Addresses, Flags: Is-Preferred
        Destination: 10.102.3/24, Local: 10.102.3.1, Broadcast: 10.102.3.255, Generation: 142
    Protocol inet6, MTU: 1500, Generation: 155, Route table: 0
      Flags: Is-Primary
      Addresses, Flags: Is-Default Is-Preferred Is-Primary
        Destination: 2001::/120, Local: 2001::1
    Generation: 144
      Addresses, Flags: Is-Preferred
        Destination: fe80::/64, Local: fe80::221:59ff:fe8b:4090
    Protocol multiservice, MTU: Unlimited, Generation: 146
    Generation: 156, Route table: 0
      Flags: Is-Primary
      Policer: Input: __default_arp_policer__

Performing a Flow Trace

When the first lines of troubleshooting steps like checking the firewall logs, security policy sanity check, and counters fail, it can be useful to leverage the power of packet flow traces (or flow debugs). The SRX has the ability to dump a log of all of the decisions the SRX makes on a packet or flow to help provide guidance on what is occurring during the packet forwarding. At the time of writing this book, the flow debug is configured in the actual configuration itself rather than in operational mode, but you do have the ability to dump the debug to logfiles (including all of the standard Junos log functionality, like off-box storage, archiving, file size definitions, etc.). The following is an overview of how to configure the flow debug. Essentially, it is broken up into a few steps:

1. Define what events you would like to log: Basic-Datapath, Packet-Drops, or All.

2. Specify where you would like this information to be logged. The logfile will be stored in /var/log on the SRX. You can optionally define the various file parameters mentioned earlier and others.

3. Define a packet filter (this is very important). Without a packet filter, the SRX will log debugs on all packets, which not only affects performance, but also will generate way too much information for you to parse without losing some sanity. The packet filter has the standard tuple information that you’d expect: Source/Destination Prefix, Source/Destination Port, Protocol, and Interface. Note that you can only define one of each parameter per filter, but you can assign multiple active filters to the debug.

4. Commit the configuration for it take effect.

5. Generate traffic and review the logfile.

6. Disable to delete the flow trace.

{primary:node0}[edit]
root@SRX100HM# set security flow traceoptions ?
Possible completions:
+ apply-groups         Groups from which to inherit configuration data
+ apply-groups-except  Don't inherit configuration data from these groups
> file                 Trace file information
> flag                 Events and other information to include in trace output
  no-remote-trace      Disable remote tracing
> packet-filter        Flow packet debug filters
  rate-limit           Limit the incoming rate of trace messages (0..4294967295)
{primary:node0}[edit]
root@SRX100HM# set security flow traceoptions flag ?
Possible completions:
  all                  All events
  basic-datapath       Basic packet flow
  packet-drops         Packet drops
{primary:node0}[edit]
root@SRX100HM# set security flow traceoptions flag basic-datapath

{primary:node0}[edit]
root@SRX100HM# set security flow traceoptions file FlowTrace

{primary:node0}[edit]
root@SRX100HM# set security flow traceoptions packet-filter ?
Possible completions:
  <filter-name>        Name of the filter
{primary:node0}[edit]
root@SRX100HM# set security flow traceoptions packet-filter 1 ?
Possible completions:
+ apply-groups         Groups from which to inherit configuration data
+ apply-groups-except  Don't inherit configuration data from these groups
  destination-port     Match TCP/UDP destination port
  destination-prefix   Destination IP address prefix
  interface            Logical interface
  protocol             Match IP protocol type
  source-port          Match TCP/UDP source port
  source-prefix        Source IP address prefix
{primary:node0}[edit]
root@SRX100HM# set security flow traceoptions packet-filter 1 destination-port 21

{primary:node0}[edit]
root@SRX100HM# show security flow traceoptions
file FlowTrace;
flag basic-datapath;
packet-filter 1 {
    destination-port 21;
}

{primary:node0}[edit]
root@SRX100HM# commit
node0:
commit complete
node1:
commit complete

{primary:node0}[edit]
root@SRX100HM# run show log FlowTrace

Nov 19 18:19:59 18:19:58.868688:CID-1:RT:<192.168.4.30/2460->207.17.137.56/21;6> matched filter 1:

Nov 19 18:19:59 18:19:58.868688:CID-1:RT:packet [48] ipid = 27864, @0x4232701a

Nov 19 18:19:59 18:19:58.868688:CID-1:RT:---- flow_process_pkt: (thd 1): flow_ctxt type 15, common flag 0x0, mbuf 0x42326e00, rtbl_idx = 5

Nov 19 18:19:59 18:19:58.868688:CID-1:RT: sysstats_inc_InCnts

Nov 19 18:19:59 18:19:58.868688:CID-1:RT: flow process pak fast ifl 71 in_ifp reth2.0

Nov 19 18:19:59 18:19:58.868688:CID-1:RT:  reth2.0:192.168.4.30/2460->207.17.137.56/21, tcp, flag 2 syn

Nov 19 18:19:59 18:19:58.868688:CID-1:RT: find flow: table 0x4cbeec78, hash 4532(0xffff), sa 192.168.4.30, da 207.17.137.56, sp 2460, dp 21, proto 6, tok 20487

Nov 19 18:19:59 18:19:58.868688:CID-1:RT:  no session found, start first path. in_tunnel - 0x0, from_cp_flag - 0

Nov 19 18:19:59 18:19:58.868688:CID-1:RT:  flow_first_create_session

Nov 19 18:19:59 18:19:58.868688:CID-1:RT:  flow_first_in_dst_nat: in <reth2.0>, out <N/A> dst_adr 207.17.137.56, sp 2460, dp 21

Nov 19 18:19:59 18:19:58.868688:CID-1:RT:  chose interface reth2.0 as incoming nat if.

Nov 19 18:19:59 18:19:58.868688:CID-1:RT:flow_first_rule_dst_xlate: DST no-xlate: 0.0.0.0(0) to 207.17.137.56(21)

Nov 19 18:19:59 18:19:58.868688:CID-1:RT:flow_first_routing: vr_id 5, call flow_route_lookup(): src_ip 192.168.4.30, x_dst_ip 207.17.137.56, in ifp reth2.0, out ifp N/A sp 2460, dp 21, ip_proto 6, tos 0

Nov 19 18:19:59 18:19:58.868688:CID-1:RT:Doing DESTINATION addr route-lookup

Nov 19 18:19:59 18:19:58.868688:CID-1:RT:  routed (x_dst_ip 207.17.137.56) from LAN (reth2.0 in 1) to reth0.0, Next-hop: 172.16.200.14

Nov 19 18:19:59 18:19:58.868688:CID-1:RT:  policy search from zone LAN-> zone Danger (0x0,0x99c0015,0x15)

Nov 19 18:19:59 18:19:58.868688:CID-1:RT:  policy has app_id 1

Nov 19 18:19:59 18:19:58.868688:CID-1:RT:  policy has timeout 900

Nov 19 18:19:59 18:19:58.868688:CID-1:RT:  app 1, timeout 1800s, curr ageout 20s

Nov 19 18:19:59 18:19:58.868688:CID-1:RT:flow_first_src_xlate:  nat_src_xlated: False, nat_src_xlate_failed: False

Nov 19 18:19:59 18:19:58.868688:CID-1:RT:flow_first_src_xlate: src nat returns status: 1, rule/pool id: 1/32772, pst_nat: False.

Nov 19 18:19:59 18:19:58.868688:CID-1:RT:  dip id = 4/1, 192.168.4.30/2460->172.16.200.7/50088 protocol 6

Nov 19 18:19:59 18:19:58.868688:CID-1:RT:  choose interface reth0.0 as outgoing phy if

Nov 19 18:19:59 18:19:58.868688:CID-1:RT:is_loop_pak: No loop: on ifp: reth0.0, addr: 207.17.137.56, rtt_idx:4

Nov 19 18:19:59 18:19:58.868688:CID-1:RT:  check nsrp pak fwd: in_tun=0x0, VSD 1 for out ifp reth0.0

Nov 19 18:19:59 18:19:58.868688:CID-1:RT:  vsd 1 is active

Nov 19 18:19:59 18:19:58.868688:CID-1:RT:-jsf : Alloc sess plugin info for session 390842026058

Here we can see lots of details: the packet is a new session not currently known. We perform a route lookup, determine the egress interface is reth0.0, and then do a policy lookup that matches policy 1. We see the timeout is 1,800 seconds, which is the default TCP timeout; and the current ageout is set to 20 seconds because this is the first packet in the TCP session, and the default initial TCP timeout is 20 seconds until the handshake has been completed. We also see that there is source NAT occurring here and that it is applied to Pool ID 1, no persistent NAT, the transform is defined, and the packet is sent to the physical interface to be sent out. Subsequent packets in an existing session will have much less information because they will match existing sessions and many of the lookups only need to happen on the first packet.

Nov 19 18:19:59 18:19:58.873415:CID-1:RT:<192.168.4.30/2460->207.17.137.56/21;6> matched filter 1:

Nov 19 18:19:59 18:19:58.873415:CID-1:RT:packet [44] ipid = 29333, @0x4392c8c0

Nov 19 18:19:59 18:19:58.873415:CID-1:RT:---- flow_process_pkt: (thd 1): flow_ctxt type 28, common flag 0x800, mbuf 0x4392c680, rtbl_idx = 0

Nov 19 18:19:59 18:19:58.873415:CID-1:RT: in_ifp <LAN:reth2.0>

Nov 19 18:19:59 18:19:58.873415:CID-1:RT:setting rtt to:0x4ccc1458 based on VR ID:5 carried over in flow ctxt,  proto 2(ipv4)

Nov 19 18:19:59 18:19:58.873415:CID-1:RT:flow_process_pkt_exception: setting rtt in lpak to 0x4ccc1458

Nov 19 18:19:59 18:19:58.873415:CID-1:RT: jsf reinj: ctxt flag 0 sess 390842026058 src pid 25 reinj flag 6

Nov 19 18:19:59 18:19:58.873415:CID-1:RT:  flow session id 2122

Nov 19 18:19:59 18:19:58.873415:CID-1:RT: vector bits 0x94a2 vector 0x4ac0df20

Nov 19 18:19:59 18:19:58.873415:CID-1:RT:  vsd 1 is active

Nov 19 18:19:59 18:19:58.873415:CID-1:RT:****jsf svc chain: sess id 2122, dir 1. No more plugins

Nov 19 18:19:59 18:19:58.873415:CID-1:RT: tcp strict 3way handshake check: tcp flag 0x2, datalen=0

Nov 19 18:19:59 18:19:58.873415:CID-1:RT:  tcp flags 0x2, flag 0x2

Nov 19 18:19:59 18:19:58.873415:CID-1:RT:  Got syn, 192.168.4.30(2460)->207.17.137.56(21), nspflag 0x1621, 0x620

Nov 19 18:19:59 18:19:58.873415:CID-1:RT:flow_xlate_pak

Nov 19 18:19:59 18:19:58.873415:CID-1:RT:  post addr xlation: 172.16.200.7->207.17.137.56.

Nov 19 18:19:59 18:19:58.873415:CID-1:RT:  post addr xlation: 172.16.200.7->207.17.137.56.

Nov 19 18:19:59 18:19:58.873415:CID-1:RT:skip pre-frag: is_tunnel_if- 0, is_if_mtu_configured- 0

Nov 19 18:19:59 18:19:58.873415:CID-1:RT:flow_dscp_vector: natp 0x4fdec978 dscp 0x0

Nov 19 18:19:59 18:19:58.873415:CID-1:RT: sysstats_inc_OutCnts

Nov 19 18:19:59 18:19:58.873415:CID-1:RT:mbuf 0x4392c680, exit nh 0x861bc2

Nov 19 18:19:59 18:19:58.873415:CID-1:RT:flow_process_pkt_exception: Freeing lpak 0x4cc6d630 associated with mbuf 0x4392c680

Nov 19 18:19:59 18:19:58.873415:CID-1:RT: ----- flow_process_pkt rc 0x0 (fp rc 0)

Let’s take a quick look at one more example in which the traffic is denied so we are familiar with how that looks as well. I’ve changed my flow debug to look at port 2121, which is denied by policy, then generated the traffic.

{primary:node0}[edit]
root@SRX100HM# set security flow traceoptions packet-filter 1 destination-port 2121

{primary:node0}[edit]
root@SRX100HM# show security flow traceoptions
file FlowTrace;
flag basic-datapath;
packet-filter 1 {
    destination-port 2121;
}

{primary:node0}[edit]
root@SRX100HM# commit
node0:
configuration check succeeds
node1:
commit complete
node0:
commit complete
Exiting configuration mode

{primary:node0}[edit]
root@SRX100HM# run clear log FlowTrace

{primary:node0}[edit]
root@SRX100HM# run show log FlowTrace
Nov 19 18:36:09 SRX100HM clear-log[89025]: logfile cleared

Nov 19 18:36:22 18:36:21.1135406:CID-1:RT:<192.168.4.30/2604->207.17.137.56/2121;6> matched filter 1:

Nov 19 18:36:22 18:36:21.1135406:CID-1:RT:packet [48] ipid = 3357, @0x423c551a

Nov 19 18:36:22 18:36:21.1135406:CID-1:RT:---- flow_process_pkt: (thd 1): flow_ctxt type 15, common flag 0x0, mbuf 0x423c5300, rtbl_idx = 5

Nov 19 18:36:22 18:36:21.1135406:CID-1:RT: sysstats_inc_InCnts

Nov 19 18:36:22 18:36:21.1135406:CID-1:RT: flow process pak fast ifl 71 in_ifp reth2.0

Nov 19 18:36:22 18:36:21.1135406:CID-1:RT:  reth2.0:192.168.4.30/2604->207.17.137.56/2121, tcp, flag 2 syn

Nov 19 18:36:22 18:36:21.1135406:CID-1:RT: find flow: table 0x4cbeec78, hash 55216(0xffff), sa 192.168.4.30, da 207.17.137.56, sp 2604, dp 2121, proto 6, tok 20487

Nov 19 18:36:22 18:36:21.1135406:CID-1:RT:  no session found, start first path. in_tunnel - 0x0, from_cp_flag - 0

Nov 19 18:36:22 18:36:21.1135406:CID-1:RT:  flow_first_create_session

Nov 19 18:36:22 18:36:21.1135406:CID-1:RT:  flow_first_in_dst_nat: in <reth2.0>, out <N/A> dst_adr 207.17.137.56, sp 2604, dp 2121

Nov 19 18:36:22 18:36:21.1135406:CID-1:RT:  chose interface reth2.0 as incoming nat if.

Nov 19 18:36:22 18:36:21.1135406:CID-1:RT:flow_first_rule_dst_xlate: DST no-xlate: 0.0.0.0(0) to 207.17.137.56(2121)

Nov 19 18:36:22 18:36:21.1135406:CID-1:RT:flow_first_routing: vr_id 5, call flow_route_lookup(): src_ip 192.168.4.30, x_dst_ip 207.17.137.56, in ifp reth2.0, out ifp N/A sp 2604, dp 2121, ip_proto 6, tos 0

Nov 19 18:36:22 18:36:21.1135406:CID-1:RT:Doing DESTINATION addr route-lookup

Nov 19 18:36:22 18:36:21.1135406:CID-1:RT:  routed (x_dst_ip 207.17.137.56) from LAN (reth2.0 in 1) to reth0.0, Next-hop: 172.16.200.14

Nov 19 18:36:22 18:36:21.1135406:CID-1:RT:  policy search from zone LAN-> zone Danger (0x0,0xa2c0849,0x849)

Nov 19 18:36:22 18:36:21.1135406:CID-1:RT:  app 0, timeout 1800s, curr ageout 20s

Nov 19 18:36:22 18:36:21.1135406:CID-1:RT:  packet dropped, denied by policy

Nov 19 18:36:22 18:36:21.1135406:CID-1:RT:  packet dropped,  policy deny.

Nov 19 18:36:22 18:36:21.1135406:CID-1:RT:  flow find session returns error.

Nov 19 18:36:22 18:36:21.1135406:CID-1:RT: ----- flow_process_pkt rc 0x7 (fp rc −1)

As we see in the preceding output, we get the initial packet, perform destination NAT checks followed by a route lookup to determine the egress interface, and then we can determine the egress or to-zone. In this case, the context is “from LAN to Danger” and the security policy lookup matches a deny rule, thus the packet is dropped.

Note

Enabling a flow trace should not impact the forwarding performance of the platform as long as you define specific filters. If there is no filter defined for the traffic, the SRX will process it normally. However, if the session matches the packet filter in the flow traceoption, then the SRX will record the detailed output. Ideally, this should only be done for the first few packets that are received by the SRX, not a high-speed data transfer! As long as this is honored, then the process should have a negligible impact.

The full details of a debug are admittedly a bit esoteric and verbose. Juniper has expressed interest in improving their troubleshooting facilities, so definitely stay tuned to the release notes, forums, and KBs for up-to-the-minute information on what might have changed.

Note

At the time of writing this book, Juniper is also beta testing a new feature called monitor flow that does not require you to make a configuration change. Please monitor the current release notes for more information on this feature’s release.

Performing a Packet Capture on SRX Branch

Due to the architectural differences of the high-end and branch SRX, there are two different ways to do packet captures depending on which platform you are using. For the branch, because it is a central CPU-based platform, there is a single method to collect the data. The high-end SRX has a truly granular mechanism for collecting the packet capture at multiple different locations in the platform due to the distributed nature of the architecture. You can even collect packet captures (PCAPs) at different locations in the processing path on the data plane!

Let’s start with the branch SRX debug. The tasks involved include the following:

1. Enable the packet capture in the forwarding-options configuration.

2. Define the file to log this to.

3. Define the maximum bytes per packet to log (snaplength).

4. Define the firewall filter that defines the packets that you would like to match and sample.

5. Apply the firewall filter to an interface.

6. Commit.

For instance, let’s log any packets that are destined to port 21 on destination IP 207.17.137.56 (ftp://ftp.juniper.net). Apply this to the reth0.0 interface

{primary:node0}[edit]
root@SRX100HM# set forwarding-options packet-capture file filename FTP

{primary:node0}[edit]
root@SRX100HM# set forwarding-options packet-capture maximum-capture-size 1500

{primary:node0}[edit]
root@SRX100HM# set firewall filter FTP term 1 from destination-address 207.17.137.56/32

{primary:node0}[edit]
root@SRX100HM# set firewall filter FTP term 1 from protocol tcp

root@SRX100HM# set firewall filter FTP term 1 from destination-port 21

{primary:node0}[edit]
root@SRX100HM# set firewall filter FTP term 1 then accept sample

root@SRX100HM# set firewall filter FTP term default then accept

{primary:node0}[edit]
root@SRX100HM# set interfaces reth2.0 family inet filter input FTP

{primary:node0}[edit]
root@SRX100HM# set interfaces reth2.0 family inet filter output FTP

{primary:node0}[edit]
root@SRX100HM# show interfaces reth2.0
family inet {
    primary;
    filter {
        input FTP;
        output FTP;
    }
    address 192.168.4.1/24;
}

{primary:node0}[edit]
root@SRX100HM# show forwarding-options
packet-capture {
    file filename FTP size 10000000;
    maximum-capture-size 1500;
}

{primary:node0}[edit]
root@SRX100HM# show firewall filter FTP
term 1 {
    from {
        destination-address {
            207.17.137.56/32;
        }
        protocol tcp;
        destination-port 21;
    }
    then {
        sample;
        accept;
    }
}
term default {
    then accept;
}

{primary:node0}[edit]
root@SRX100HM# commit
node0:
configuration check succeeds
node1:
commit complete
node0:
commit complete

{primary:node0}[edit]
root@SRX100HM# exit
Exiting configuration mode

Note

Don’t forget to set the default accept rule or else you will deny the traffic that doesn’t match the filter by default! Also, the packet filter is stateless, so you might need to define both directions of the traffic (depending on how you craft your filter), including the reverse direction. When it comes to applying the filter, you need to ensure that the firewall filter matches the packet as it arrives on the firewall (pre-NAT) if you are capturing on the ingress interface, or post-NAT if capturing on the egress interface.

Regarding HA, at the time of writing this book, the SRX will create two packet capture filters, one with the ingress and one with the egress packet capture when using the capture on reth interfaces.

{primary:node0}
root@SRX100HM> file list /cf/var/tmp

/cf/var/tmp:
FTP.reth2
cleanup-pkgs.log
eedebug_bin_file
gksdchk.log
gres-tp/
idp_license_info
install/
kmdchk.log
krt_gencfg_filter.txt
pics/
rtsdb/
sampled.pkts
sec-download/
spu_kmd_init
usb/
vi.recover/

{primary:node0}
root@SRX100HM> start shell
root@SRX100HM% tcpdump -r /cf/var/tmp/FTP.reth2

19:01:47.102785  In IP 192.168.4.30.2825 > colo-ftp2.juniper.net.ftp: S 1610170857:1610170857(0) win 65535 <mss 1460,nop,nop,sackOK>
19:01:47.167478  In IP 192.168.4.30.2825 > colo-ftp2.juniper.net.ftp: . ack 3940080389 win 65535
19:01:47.167575  In IP 192.168.4.30.2825 > colo-ftp2.juniper.net.ftp: . ack 21 win 65515

As you can see from this output, the SRX will log this file named <filename>.<interface-name> into the /var/tmp directory. You can either grab this PCAP off of the SRX using FTP/SCP and load it onto your favorite PCAP viewer on your desktop, or you can even leverage TCPDUMP on the box and read it directly as just shown.

Performing a Packet Capture on the High-End SRX

The high-end SRX platforms leverage a different mechanism for collecting PCAPs on the data plane, as the architecture is different, so you have some additional options for the packet capture. On the high-end SRX, the name of this feature is End to End Datapath Debug because there are multiple components that play a role in the processing of a packet from ingress to egress. To aid in troubleshooting, Juniper has provided the ability to collect the PCAPs at different locations in the data plane.

The following tasks must be performed to enable end-to-end debug:

1. Define the capture file.

2. Define the maximum capture size per packet (snaplen).

3. Define the Action profile (which specifies what to do with the matched packets).

4. Define the packet filter.

5. Commit the configuration.

6. Enable Datapath Debug at the operational-mode level.

7. Capture traffic.

8. Disable Datapath Debug at the operational-mode level.

9. Convert PCAP (for export) or view locally.

This probably sounds like a lot, but it only takes a few steps. The key is to be sure to set solid packet filters that define what traffic to capture so you don’t capture all traffic, and also to choose the right location to capture the PCAP. Just like the branch packet capture function, the high end allows you to define multiple packet filters, and the filters match the packets as defined. In terms of the location, you can see that you can capture the packets at many different locations in the processing path, but typically you can use NP-Ingress if you want to see what is arriving on the SRX before firewall processing, and if you need to compare what’s coming in versus out, you can define NP-Egress as well. The other options are helpful, but are geared more for JTAC and developers than administrators.

There are other options besides capturing the full packet, but for our purposes, we’ll just focus on the packet-capture or packet-dump option.

[edit]
root@srx3600n0# set security datapath-debug action-profile Capture ?
Possible completions:
+ apply-groups         Groups from which to inherit configuration data
+ apply-groups-except  Don't inherit configuration data from these groups
> event
> module
  preserve-trace-order  Preserve trace order (has performance overhead)
  record-pic-history   Record the PIC(s) in which the packet has been processed
[edit]
root@srx3600n0# set security datapath-debug action-profile Capture event ?
Possible completions:
  jexec                JExec
  lbt                  Load-Balance-Thread
  lt-enter             LT(Logical Tunnel) enter
  lt-leave             LT(Logical Tunnel) leave
  mac-egress           A2/A10 IOC Mac(broadcom) egress
  mac-ingress          A2/A10 IOC Mac(broadcom) ingress
  np-egress            NP egress
  np-ingress           NP ingress
  pot                  Packet-Order-Thread
[edit]
root@srx3600n0# set security datapath-debug action-profile Capture module ?
Possible completions:
  flow                 Flow module

[edit]
root@srx3600n0# set security datapath-debug action-profile Capture event np-ingress ?
Possible completions:
+ apply-groups         Groups from which to inherit configuration data
+ apply-groups-except  Don't inherit configuration data from these groups
  count                Count action
  packet-dump          Packet dump action
  packet-summary       Packet summary action
  trace                Trace action
[edit]
root@srx3600n0# set security datapath-debug action-profile Capture event np-ingress packet-dump

[edit]
root@srx3600n0# set security datapath-debug packet-filter 1 destination-port 21 action-profile Capture

[edit]
root@srx3600n0# show security datapath-debug
capture-file PCAP;
maximum-capture-size 10000;
action-profile {
    Capture {
        event np-ingress {
            packet-dump;
        }
    }
}
packet-filter 1 {
    action-profile Capture;
    destination-port 21;
}

[edit]
root@srx3600n0# commit and-quit
commit complete
Exiting configuration mode

root@srx3600n0> request security datapath-debug st
                                                ^
syntax error, expecting <command>.
root@srx3600n0> request security datapath-debug ?
Possible completions:
  capture
root@srx3600n0> request security datapath-debug capture st
                                                          ^
'st' is ambiguous.
Possible completions:
  start                Start datapath debug packet capture
  stop                 Stop datapath debug packet capture
root@srx3600n0> request security datapath-debug capture start
datapath-debug capture started on file PCAP

###Generate Traffic###

root@srx3600n0> request security datapath-debug capture stop
datapath-debug capture succesfully stopped, use show security datapath-debug capture to view

root@srx3600n0> show security datapath-debug capture
Packet 1: (C0/F11:np-ingress)
00 21 59 8b 40 90 02 1a c5 01 00 49 08 00 45 00
00 38 21 dd 40 00 20 06 20 07 0a 66 01 49 0a 66
02 c8 97 9f 00 15 e1 39 26 a6 00 00 00 00 90 02
16 a0 03 9a 00 00 02 04 05 b4 01 01 08 0a 1f 41
6d 23 00 00 00 00
Packet 2: (C0/F11:np-ingress)
00 21 59 8b 40 90 02 1a c5 01 00 49 08 00 45 00
00 28 21 3f 40 00 20 06 20 b5 0a 66 01 49 0a 66
02 c8 97 9f 00 15 e1 39 26 a7 63 86 8a 6f 50 10
16 a0 f2 cc 00 00 00 00 00 00 00 00
Packet 3: (C0/F11:np-ingress)
00 21 59 8b 40 90 02 1a c5 01 00 49 08 00 45 00
00 28 21 38 40 00 20 06 20 bc 0a 66 01 49 0a 66
02 c8 97 9f 00 15 e1 39 26 a7 63 86 8a 7c 50 10
1c 54 ed 0b 00 00 00 00 00 00 00 00

This is something, but not exactly human readable. Let’s convert it to something we and PCAP viewers like Wireshark/TCP Dump can understand.

root@srx3600n0% e2einfo -Ccapture -Snormalize -I PCAP -F output.pcap
sucessfully convert 1491 packets
root@srx3600n0% tcpdump -r PCAP -c 5
Reverse lookup for 10.102.1.73 failed (check DNS reachability).
Other reverse lookup failures will not be reported.
Use <no-resolve> to avoid reverse lookups on IP addresses.

02:13:28.340303 C0/F11 event:1(np-ingress) IP 10.102.1.73.38815 > 10.102.2.200.ftp: S 3778619046:3778619046(0) win 5792 <mss 1460,nop,nop,timestamp 524381475 0>
02:13:28.359050 C0/F11 event:1(np-ingress) IP 10.102.1.73.38815 > 10.102.2.200.ftp: . ack 1669761647 win 5792
02:13:28.359999 C0/F11 event:1(np-ingress) IP 10.102.1.73.38815 > 10.102.2.200.ftp: . ack 14 win 7252
02:13:28.360370 C0/F11 event:1(np-ingress) IP 10.102.1.73.38815 > 10.102.2.200.ftp: P 0:16(16) ack 14 win 7252
02:13:28.361917 C0/F11 event:1(np-ingress) IP 10.102.1.73.38815 > 10.102.2.200.ftp: . ack 51 win 8712
root@srx3600n0% tcpdump -r output.pcap -c 5
Reverse lookup for 10.102.1.73 failed (check DNS reachability).
Other reverse lookup failures will not be reported.
Use <no-resolve> to avoid reverse lookups on IP addresses.

02:13:28.340303 IP 10.102.1.73.38815 > 10.102.2.200.ftp: S 3778619046:3778619046(0) win 5792 <mss 1460,nop,nop,timestamp 524381475 0>
02:13:28.359050 IP 10.102.1.73.38815 > 10.102.2.200.ftp: . ack 1669761647 win 5792
02:13:28.359999 IP 10.102.1.73.38815 > 10.102.2.200.ftp: . ack 14 win 7252
02:13:28.360370 IP 10.102.1.73.38815 > 10.102.2.200.ftp: P 0:16(16) ack 14 win 7252
02:13:28.361917 IP 10.102.1.73.38815 > 10.102.2.200.ftp: . ack 51 win 8712

In this output, we use the e2e configure tool to convert the original capture PCAP to output.pcap. The syntax is e2einfo –Ccapture –Snormalize –I <end-to-end-debug-pcap> -F <standard pcap>. Although TCP dump does a decent job of parsing the original PCAP (we can see the metadata about the np-ingress info in the header) most other programs like Wireshark will scoff at the capture as corrupted. Once the capture is converted, you can retrieve it from the SRX and export it to your host machine with FTP/SCP for better viewing.

Sample Deployment

Now that we have covered so many concepts in this chapter, let’s leverage an example that examines the key concepts we have discussed in this chapter. The example is configured as follows:

• Configure an intrazone policy for the “trust” zone that permits ICMP between hosts but blocks any other communication between hosts in the trust zone that crosses the firewall.

• Configure a security policy from “trust” to “untrust” called HTTP-Business-Hours that only allows HTTP on TCP port 80 and 8000 out to the Internet between 9 a.m. and 5 p.m. Monday through Friday. All internal hosts from the subnet 192.168.1.0/24 should be allowed to talk to the Internet. Log this traffic in a way that collects the most information about the traffic being sent.

• Configure the firewall to actively terminate any other traffic in the trust to untrust zone rather than silently drop it.

• Enable the SIP ALG and configure it for UDP port 5061, which is a port that some VoIP solutions use rather than 5060. This service should have a timeout of five times the normal timeout of UDP.

• Create a policy called Internal-VoIP that allows the internal users in the subnet 192.168.1.0/24 of the trust to connect on the new custom SIP application to destination voip.company.local. The firewall should be able to dynamically change the IP address of this object if it changes in the internal infrastructure without having to reconfigure the SRX. The VoIP server is in the zone Internal-Servers.

• Create a policy from zone Branch-Office to zone Internal-Servers that allows any cash registers at IP address 10.x.100.50 to talk to servers 172.16.100.50-100. Make an application set for this policy that includes HTTP, ICMP, FTP, and SSH.

• Create a policy that allows only host 192.168.1.100 from the trust zone to connect to the SRX via SSH. Log these connections.

• Finally, create a global policy that silently drops and logs any other traffic.

[edit]
root@srx3600n0# set security zones security-zone trust

[edit]
root@srx3600n0# set security zones security-zone untrust

[edit]
root@srx3600n0# set security policies from-zone trust to-zone trust policy Allow-ICMP match source-address any destination-address any application junos-icmp-all

[edit]
root@srx3600n0# set security policies from-zone trust to-zone trust policy Allow-ICMP then permit

root@srx3600n0# set security policy from-zone trust to-zone trust policy Block-All-Else match source-address any destination-address any application any

[edit]
root@srx3600n0# set security policies from-zone trust to-zone trust policy Block-All-Else then deny

[edit]
root@srx3600n0# set applications application Custom-HTTP-8000 protocol tcp destination-port 8000

[edit]
root@srx3600n0# set security address-book global address 192.168.1.0/24 192.168.1.0/24

[edit]
root@srx3600n0# set schedulers scheduler Business-Hours daily start-time 09:00:00 stop-time 17:00:00

[edit]
root@srx3600n0# set schedulers scheduler Business-Hours saturday exclude

[edit]
root@srx3600n0# set schedulers scheduler Business-Hours sunday exclude

[edit]
root@srx3600n0# set security policies from-zone trust to-zone untrust policy HTTP-Business-Hours match source-address 192.168.1.0/24 destination-address any application [junos-http Custom-HTTP-8000]

[edit]
root@srx3600n0# set security policies from-zone trust to-zone untrust policy HTTP-Business-Hours then permit

[edit]
root@srx3600n0# set security policies from-zone trust to-zone untrust policy HTTP-Business-Hours then log session-close

[edit]
root@srx3600n0# set security policies from-zone trust to-zone untrust policy HTTP-Business-Hours scheduler-name Business-Hours

[edit]
root@srx3600n0# set security policeis from-zone trust to-zone untrust policy Reject-All-Else match source-address any destination-address any application any

[edit]
root@srx3600n0# set security policies from-zone trust to-zone untrust policy Reject-All-Else then reject

[edit]
root@srx3600n0# set applications application Custom-SIP-5061 protocol udp destination-port 5061 application-protocol sip inactivity-timeout 300

[edit]
root@srx3600n0# set security policies from-zone trust to-zone Internal-Servers policy Internal-VoIP match source-address 192.168.1.0/24 destination-address voip.company.local application Custom-SIP-5061

[edit]
root@srx3600n0# set security policies from-zone trust to-zone Internal-Servers policy Internal-VoIP then permit

[edit]
root@srx3600n0# set security zones security-zone Branch-Office

[edit]
root@srx3600n0# set security address-book global address Cash-Registers wildcard-address 10.0.100.50/255.0.255.255

[edit]
root@srx3600n0# set security address-book global address Servers range-address 172.16.100.50 to 172.16.100.100

[edit]
root@srx3600n0# set applications application-set Cash-Register-Apps application junos-http

[edit]
root@srx3600n0# set applications application-set Cash-Register-Apps application junos-icmp-all

[edit]
root@srx3600n0# set applications application-set Cash-Register-Apps application junos-ftp

[edit]
root@srx3600n0# set applications application-set Cash-Register-Apps application junos-ssh

[edit]
root@srx3600n0# set security policies from-zone Branch-Office to-zone Internal-Servers policy Cash-Register match source-address Cash-Registers destination-address Servers application Cash-Register-Apps

[edit]
root@srx3600n0# set security policies from-zone Branch-Office to-zone Internal-Servers policy Cash-Register then permit

[edit]
root@srx3600n0# set security policies from-zone trust to-zone junos-host policy Allow-SSH match source-address 192.168.1.100 destination-address any application junos-ssh

[edit]
root@srx3600n0# set security policies from-zone trust to-zone junos-host policy Allow-SSH then permit

[edit]
root@srx3600n0# set security policies from-zone trust to-zone junos-host policy Allow-SSH then log session-close

[edit]
root@srx3600n0# set security policies global policy Drop-All match source-address any destination-address any application any

[edit]
root@srx3600n0# set security policies global policy Drop-All then deny

[edit]
root@srx3600n0# set security policies global policy Drop-All then log session-init

[edit]
root@srx3600n0# show security policies
from-zone trust to-zone trust {
    policy Allow-ICMP {
        match {
            source-address any;
            destination-address any;
            application junos-icmp-all ;
        }
        then {
            permit;
        }
    }
    policy Block-All-Else {
        match {
            source-address any;
            destination-address any;
            application any;
        }
        then {
            deny;
        }
    }
}
from-zone trust to-zone untrust {
    policy HTTP-Business-Hours {
        match {
            source-address 192.168.1.0/24;
            destination-address any;
            application [ junos-http Custom-HTTP-8000 ];
        }
        then {
            permit;
            log {
                session-close;
            }
        }
        scheduler-name Business-Hours;
    }
    policy Reject-All-Else {
        match {
            source-address any;
            destination-address any;
            application any;
        }
        then {
            reject;
        }
    }
}
from-zone trust to-zone Internal-Servers {
    policy Internal-VoIP {
        match {
            source-address 192.168.1.0/24;
            destination-address voip.company.local;
            application Custom-SIP-5061;
        }
        then {
            permit;
        }
    }
}
from-zone Branch-Office to-zone Internal-Servers {
    policy Cash-Register {
        match {
            source-address Cash-Registers;
            destination-address Servers;
            application Cash-Register-Apps;
        }
        then {
            permit;
        }
    }
}
from-zone trust to-zone junos-host {
    policy Allow-SSH {
        match {
            source-address 192.168.1.100;
            destination-address any;
            application junos-ssh;
        }
        then {
            permit;
            log {
                session-close;
            }
        }
    }
}
global {
    policy Drop-All {
        match {
            source-address any;
            destination-address any;
            application any;
        }
        then {
            deny;
            log {
                session-init;
            }
        }
    }
}


[edit]
root@srx3600n0# show security address-book
global {
    address 192.168.1.0/24 192.168.1.0/24;
    address voip.company.local {
        dns-name voip.company.local;
    }
    address Cash-Registers {
        wildcard-address 10.0.100.50/255.0.255.255;
    }
    address Servers {
        range-address 172.16.100.50 {
            to {
                172.16.100.100;
            }
        }
    }
}

[edit]
root@srx3600n0# show applications
application Custom-HTTP-8000 {
    protocol tcp;
    destination-port 8000;
}
application Custom-SIP-5061 {
    application-protocol sip;
    protocol udp;
    destination-port 5061;
    inactivity-timeout 300;
}
application-set Cash-Register-Apps {
    application junos-http;
    application junos-ftp;
    application junos-ssh;
    application junos-icmp-all;
}

[edit]
root@srx3600n0# show security zones
security-zone trust;
security-zone untrust;
security-zone Internal-Servers;
security-zone Branch-Office;

[edit]
root@srx3600n0# show schedulers
scheduler Business-Hours {
    daily {
        start-time 09:00:00 stop-time 17:00:00;
    }
    sunday exclude;
    saturday exclude;
}

Summary

In this chapter, we covered the security policy components of the SRX. Security policies provide a centralized pivot point for processing of traffic on the SRX. They define how traffic should be matched, along with how it will be processed. There are a lot of options when it comes to processing traffic, many of which we discussed here and some that are discussed in later chapters, like UTM, IPS, and AppSecure. By not only learning how security policies function, but also how to properly leverage them for administrative purposes, you can create powerful security policies that are easy to maintain, reduce your attack surface, and provide visibility for your infrastructure. Without a good understanding of how security policies function, you will not be able to effectively enforce other security controls in the platform. We will constantly reference the security policies throughout the other chapters in this book, so this chapter is not only effective as an educational tool but also as a reference!

Study Questions

Questions

1. What type of firewall inspection does the SRX perform and how does it logically separate network segments?

2. What is a security policy context?

3. What are the three types of security policy contexts and in which order are they evaluated?

4. How does the firewall determine the source and destination (from and to) zones?

5. In what order are the rules in a security policy context evaluated?

6. How are network segments classified by zones?

7. Is intrazone traffic permitted by default?

8. What parameters make up the match criteria for a security rule?

9. True or False: You need to define a reverse policy to allow the return traffic from server to client to flow properly.

10. What is the difference between a regular address object and a wildcard address object?

11. What is the difference between an address object that uses the “dns-name” attribute and one that just specifies the name in the fully qualified domain name (FQDN) format?

12. What type of objects can be part of an address or application set?

13. At what layers does the application object operate?

14. What is an ALG and how does it function?

15. What is policy rematch?

16. What are the main actions that a firewall can take on the traffic and which option allows you to leverage further processing options?

17. What is the difference between Log and Count?

18. What is the difference between session init and session close?

19. What are the default timeouts for TCP, UDP, and other protocols?

20. What is the difference between configuring a policy for IPv4 and IPv6?

21. When creating a new firewall rule in the CLI, where in the rulebase is the rule placed by default?

1. The SRX is a stateful firewall that leverages security zones to logically separate network segments.

2. A security policy context is a pair of security zones that define the direction traffic will take. Traffic arrives on the source zone and leaves the destination zone (e.g., trust to untrust). All security policies in this context follow in that traffic direction.

3. Intrazone, interzone, and global. They are evaluated in that order.

4. The source (from) zone is determined by which interface the traffic arrives on in the firewall, whereas the destination (to) zone is determined by either a routing lookup in Layer 3 or a switching lookup in Layer 2 transparent mode to determine what the egress interface is. Once the egress interface is known, the system knows what the egress zone is, and thus the security policy context in which to match a firewall rule.

5. The rules within a context are evaluated from top to bottom, looking for the most specific match. Once a match is found, no more rules are evaluated.

6. Network segments are classified by zones by placing interfaces into zones. Technically this is at the IFL level (subinterface) so you can have an untagged interface in a zone or individual VLANs in separate zones.

7. No, unlike ScreenOS, intrazone traffic requires a security policy to be permitted.

8. From-To-Zone, Source Address, Destination Address, and Application. Starting in Junos 12.1, Source-Identity is also on this list. Schedulers are not technically under the match criteria but in their own way are a match criteria based on time and day.

9. False. The firewall will automatically allow return traffic for a given session back to the client. You do not need to define a return rule.

10. A standard address entry follows the standard variable length subnet mask notation with both an address prefix and a subnet mask. The subnet mask bits must be contiguous. A wildcard address object specifies an address prefix but rather than a contiguous mask, the bits in the wildcard mask do not need to be contiguous. This is useful for making address objects that follow some convention like all Odd/Even objects or all objects with a specific IP address in the last octet. For instance, if you have retail environments where every cash register and printer uses the .10 address in a subnet, 192.168.x.10/255.255.0.255. The wildcard mask in this case would match the first, second, and fourth octets, but not the third. You don’t have to do this on octet boundaries; any bit combination is acceptable.

11. When you use the dns-name attribute, that triggers the SRX to dynamically resolve the hostname at policy commit time, boot time, and every time the TTL expires or the cache list is purged. If you specify the address object by name without the dns-name attribute, then the firewall will immediately resolve the name and put the IP address into the configuration at commit time, but it will not be automatically resolved after that point.

12. Address sets can have any address object type or other address sets in them (e.g., address, DNS name, wildcard, range, and other address sets), whereas application sets can have any application objects and other application object sets.

13. Application objects primarily operate at Layer 3 and Layer 4 (technically they can be used to specify ALGs, which in a way operate at Layer 7). These are different than dynamic application objects (covered in Chapter 12), which truly operate at Layer 7 and match patterns and application behaviors in the protocol stream.

14. An ALG is an application layer gateway. It is used to monitor the control channels of applications and determine if auxiliary firewall sessions called pinholes must be opened. They operate at Layer 7. Some ALGs are also used to permit or deny application behaviors within the traffic stream.

15. Policy rematch instructs the firewall to reevaluate firewall policies for existing sessions when changes are made to the security rulebase. Essentially, the firewall rules will be reevaluated as if they were at the beginning of the session.

16. The three primary options for actions in the security policy are permit, deny, and reject. Permit allows the traffic, deny silently drops the traffic, and reject drops the traffic but sends a TCP reset for TCP and a ICMP message if it is non-TCP. Only permit allows you to configure other processing options, because if the traffic is dropped, there is no point in performing additional actions.

17. Both log and count are optional actions that can be taken regardless of which action is selected (permit, deny, reject). Log triggers a syslog message to be generated, whereas count tracks the data throughput for the given firewall rule on which it is configured.

18. Session init triggers a log message when the session is created (ideal for troubleshooting or deny/reject sessions), whereas session close triggers a log message when the session closes. The session-close option has a lot more information than session init because additional information about the traffic is only available at session close (duration, bytes sent or received, application type, reason for close, and others), whereas session init can only define the state of the connection when the traffic is established.

19. By default, TCP has a 30-minute idle timeout, UDP has a 60-second idle timeout, known IP traffic has a 30-minute idle timeout, and unknown has a 60-second idle timeout. Idle means that there is no traffic passing through the device for the session; if the timeout is reached, the session will be cleared. A session can be closed by TCP Reset/FIN, ALG, Level 7 service like IPS/AppSecure/UTM, manually cleared, or by other system events, along with aging out from the idle timeout.

20. There is not any difference between IPv4 and IPv6 objects in security policies; they can be referenced independently or concurrently in security policies. There are some limitations with IPv6 when it comes to address objects like range and wildcard support, but within policies you can use them side by side with IPv4 and IPv6. It is important to point out that at the time of writing this book, an address object can only have one time, either IPv4 or IPv6, but not both. This also goes for “any” objects.

21. The rule is placed at the bottom of the security policy context (e.g., trust to untrust; it will be the bottom rule until you move it).