Juniper's new Sandbox (SkyATP) - The Good, The Bad, and the Ugly

Hi Folks,

Trying out LinkedIn posting for a change, come check it out:

https://www.linkedin.com/pulse/junipers-new-sandbox-skyatp-good-bad-ugly-craig-dods?trk=prof-post

Juniper SRX: High-end SRX Dataplane Packet Capture

Firstly, Juniper has a decent guide with important caveats for this technique located here. I've just added some additional colour which seems to be oft-requested.

These techniques are applicable to the following platforms:

SRX 1400
SRX 3400
SRX 3600
SRX 5400
SRX 5600
SRX 5800

For those of us who are required to troubleshoot relatively complex issues on Juniper's high-end security platform, gaining insight into the exact makeup of transit packets is of the utmost importance. Unfortunately for us, Juniper does not make this easy when compared to its peers...

While the devices themselves support tcpdump, the tool is only able to capture traffic destined to and from the routing-engine and has no visibility into transit traffic.

The tool that Juniper does provide us with is called datapath-debugging, and it does not produce an output that is readable by tcpdump/Wireshark by default (it requires conversion). 

In our example, I'll be attempting to record packets going to and from a problematic website. It's important to understand that the filters listed below are stateless and do not match in both directions. If you want to see traffic to and from a particular host, you will need to specify two separate packet-filter statements.

In our case, the problematic website is located at 208.74.207.25. It may be necessary (due to volume) for you to specify the other end of the connection. It's also important to be aware of NAT in these situations as it can alter your filters.

First, specify your capture file information (5 files of 10MB) and the snaplen (feel free to choose your own filenames):

set security datapath-debug capture-file pcap_for_problem
set security datapath-debug capture-file size 10m
set security datapath-debug capture-file files 5
set security datapath-debug maximum-capture-size 1514

Second, enable the packet-dump action for ingress and egress NP's:

set security datapath-debug action-profile capture event np-egress packet-dump
set security datapath-debug action-profile capture event np-ingress packet-dump

Third, create two stateless filters that match our traffic:

set security datapath-debug packet-filter OUT action-profile capture
set security datapath-debug packet-filter OUT protocol tcp
set security datapath-debug packet-filter OUT destination-port 80
set security datapath-debug packet-filter OUT destination-prefix 208.74.207.25/32

set security datapath-debug packet-filter IN action-profile capture
set security datapath-debug packet-filter IN protocol tcp
set security datapath-debug packet-filter IN source-port 80
set security datapath-debug packet-filter IN source-prefix 208.74.207.25/32

Fourth, commit your changes:

commit

Finally, when ready, enable the packet capture in operational mode and replicate the problem:

request security datapath-debug capture start

When complete, disable the packet capture with:

request security datapath-debug capture stop

You'll now be presented with file(s) within /var/log with the name you specified in step 1. These will unfortunately not be useful to you immediately.

To convert the files into something readable by tcpdump (-r) or Wireshark, run the following:

e2einfo -Ccapture -Snormalize -I pcap_for_problem -F pcap_for_problem.pcap

Once converted, you'll now be able to view them with the tools of your choosing.

Thanks for reading!

Juniper SRX: How to manage fxp0 across a VPN (Remote Management Best Practices)

This is one of the most common questions I see, both in my professional life as well as on popular Juniper technical forums.  Most of this confusion could be avoided if Juniper allowed for fxp0 to be placed in a non-default routing instance, however, for the time being, we're left with having to perform the following (moving all interfaces to a VR instead of just fxp0).

For those who are unaware, fxp0 represents a dedicated management interface to the routing-engine of the device. On the SRX, there is complete hardware separation between the routing-engine and the dataplane (which is responsible for the actual forwarding of transit traffic). This is accomplished on the high-end devices by a separate hardware module or blade (SRX 650 -> SRX 5800), and by dedicated CPU cores on the shared CPUs on the smaller branch devices.

In this example, our topology will contain the following:
1 Cluster of two SRX to be managed via fxp0 remotely.
1 Stand-Alone SRX acting as our VPN peer. Our SSH Proxy will reside behind this gateway.
1 Virtual-Chassis stack of EX Switches to attach the cluster's fxp0 and management reth to
1 SSH Proxy (172.16.88.100) for remote device management.

This example assumes the cluster has already been configured, the VPN (route-based) is up and running, etc. If you are unfamiliar with these topics, you can check out previous articles here on how to set them up (or support.juniper.net for the official documentation).

Step 1: Allocate a new VLAN for management purposes. This VLAN will contain both chassis' fxp0 interfaces, as well as a single reth interface (trunked or otherwise) from the dataplane. Assign the new reth interface to an appropriately named zone (careful not to use 'Management' as it's reserved):

Interface configurations are as follows:

set interfaces reth0 vlan-tagging
set interfaces reth0 redundant-ether-options redundancy-group 1
set interfaces reth0 redundant-ether-options minimum-links 1
set interfaces reth0 redundant-ether-options lacp passive
set interfaces reth0 unit 100 description "Outside interface"
set interfaces reth0 unit 100 vlan-id 100
set interfaces reth0 unit 100 family inet address 10.1.1.1/28
set interfaces reth1 redundant-ether-options redundancy-group 1
set interfaces reth1 unit 0 description "Attached to Management VLAN for fxp0 access"
set interfaces reth1 unit 0 family inet address 192.168.0.210/24
set interfaces st0 unit 0 family inet address 1.1.1.1/28
set groups node0 interfaces fxp0 unit 0 family inet address 192.168.0.211/24
set groups node1 interfaces fxp0 unit 0 family inet address 192.168.0.212/24
set security zones security-zone Outside interfaces reth0.100 host-inbound-traffic system-services ike
set security zones security-zone Mgmt interfaces reth1.0
set security zones security-zone VPN interfaces st0.0

Step 2: Divide the SRX into (at least) two virtual-routers. One with your management (fxp0) interfaces (in inet.0), and one with all of your revenue ports (reth's or otherwise):

set routing-instances Traffic instance-type virtual-router
set routing-instances Traffic interface reth0.100
set routing-instances Traffic interface reth1.0
set routing-instances Traffic interface st0.0
set routing-instances Traffic routing-options static route 172.16.88.0/24 next-hop 1.1.1.2

Step 3: Assign the correct routes to the default routing instance (that should only contain fxp0) so that it has a return path to our SSH Proxy regardless of what state it's in (RPD does not run on the standby node). This requires us to use several pieces of configuration.
The next-hop for all traffic for fxp0 should be our newly created "Mgmt" reth interface (reth1.0)

a) Create a backup router statement for the device to read at boot. This will only take effect during the RE boot sequence before RPD becomes available. Make sure to use host routes here (/32) with a next-hop address of your reth interface

set system backup-router 192.168.0.210
set system backup-router destination 172.16.88.100/32

b) Create a mirrored static route for the backup-router statement. This ensures that the secondary node remains reachable post-failover (backup-router is only read during boot).:

set routing-options static route 172.16.88.100/32 next-hop 192.168.0.210
set routing-options static route 172.16.88.100/32 retain
set routing-options static route 172.16.88.100/32 no-readvertise

c) Create the default route for all other RE (fxp0) traffic to use reth1.0 as well:

set routing-options static route 0.0.0.0/0 next-hop 192.168.0.210

d) Inform the device that all dataplane logs for traffic (Accept/Deny/IPS, from the  'security log' configuration) need to be routed to the new virtual-router (Traffic.inet.0) to reach the syslog/SIEM. This ensures they exit a revenue port and are not impacting the RE negatively:

set routing-options static route IP_of_SYSLOG_Server/32 next-table Traffic.inet.0

Step 4: Add appropriate security policies for the traffic from the Mgmt zone to the VPN zone (and vice-versa) to permit access to fxp0

Step 5: Validate that you have access to both devices and view it on the device (test it with both RG0 and RG1 failover scenarios):

 show security flow session source-prefix 172.16.88.100 node 0
node0:
--------------------------------------------------------------------------

Session ID: 382, Policy name: ANY_ANY_PERMIT/4, State: Active, Timeout: 1800, Valid
  In: 172.16.88.100/44411 --> 192.168.0.212/22;tcp, If: st0.0, Pkts: 459, Bytes: 27651
  Out: 192.168.0.212/22 --> 172.16.88.100/44411;tcp, If: reth1.0, Pkts: 480, Bytes: 161953
Total sessions: 1

Step 6 (Optional): Ensure you can still SSH to the master device if the VPN tunnel goes down by adding SSH accessibility on the outside reth interface. Ensure this is locked down appropriately with firewall filters!

set security zones security-zone Outside interfaces reth0.100 host-inbound-traffic system-services ssh

Step 7 (Optional): If your cluster requires access to things like public DNS, NTP, or application-services updates (IPS/AppFW, etc), you'll need to add NAT and security policies for fxp0 to access  the appropriate resources.

Juniper SRX: IF-MAP, source-identity and restrict-source-identity-lookup

The terms for the uninitiated:

IF-MAP, at its core, is a user identity propagation mechanism and protocol. Juniper's implementation allows you to attach 'roles' to a specific user, and create policies that permit or deny traffic based upon said role. In the case of the SRX, the firewall itself does not participate directly in the IF-MAP Federation; It relies on a proprietary communications channel over SSL (JUEP) to an Infranet Controller (IC) to request/receive user identity information.

source-identity is a (but not the only - see UAC) policy match term you can use to leverage IF-MAP on the SRX. The term was introduced in 12.1, and relies on a 'first-packet-drop-lookup' mechanism to handle packets that match the policy. Basically, if a new connection matches a policy with source-identity as a match condition, the firewall will proceed to drop the packet and query the local IC for the user identity/role information of the source IP address, assuming there is not already an entry in it's local database. Depending on the response from the IC, the firewall will then match the user's role to the policy and permit the flow, or, if the user identity does not contain the required role for the policy in question, it will continue doing policy lookups until a terminal match is found further down in the rulebase. IE: These policies are not terminal.

restrict-source-identity-lookup is a hidden feature/command within the 'unified-access-control' stanza that was added into the 12.1X44D30.4 release which is meant to significantly increase the performance of a device leveraging the source-identity feature. What this command does is quite simple; It makes any rule with source-identity terminal. If a flow matches a policy with source-identity while restrict-source-identity-lookup is configured and the user does not have the required role, the session will be denied. As such, it is generally adviseable to place these policies at or near the bottom of the rulebase to avoid issues with unauthenticated (server-to-server) traffic that may share similar source/destination/application information.

To enable the feature, run:

set services unified-access-control restrict-source-identity-lookup

To successfully use the feature in the rulebase however, the security policies themselves get quite a bit more complex. For every policy that utilizes source-identity matching, you must have a 'clone' policy (placed adjacently) that mirrors the match conditions, while using the source-identity of 'unauthenticated-user' AND 'application-services uac-policy'. The second policy with 'unauthenticated-user' is meant to catch an (you guessed it!) unauthenticated user from an unknown source IP and perform a 'first-packet-drop-lookup' to gather their information. Thus, once the source IP address is known, the flow will come back down through the rulebase and match the first source-identity policy with the required role, and either be permitted or outright denied, based on the received information.

To put this in practice, I've made a policy below which will look for users that have the HR_Management role while using restrict-source-identity-lookup:

set security policies from-zone Outside to-zone DMZ policy HR_Mgmt_NO-AUTH match source-address any
set security policies from-zone Outside to-zone DMZ policy HR_Mgmt_NO-AUTH match destination-address any
set security policies from-zone Outside to-zone DMZ policy HR_Mgmt_NO-AUTH match application junos-https
set security policies from-zone Outside to-zone DMZ policy HR_Mgmt_NO-AUTH match source-identity unauthenticated-user
set security policies from-zone Outside to-zone DMZ policy HR_Mgmt_NO-AUTH then permit application-services uac-policy

set security policies from-zone Outside to-zone DMZ policy HR_Management match source-address any
set security policies from-zone Outside to-zone DMZ policy HR_Management match destination-address any
set security policies from-zone Outside to-zone DMZ policy HR_Management match application junos-https
set security policies from-zone Outside to-zone DMZ policy HR_Management match source-identity HR_Management
set security policies from-zone Outside to-zone DMZ policy HR_Management then permit

Some additional 'useful' operational commands when dealing with IF-MAP and SRX are:

View the available roles on the Enforcer (SRX):

show services unified-access-control roles

View all users currently active on the device: 

show services unified-access-control authentication-table

View connectivity between the SRX and the IC (state should be 'connected'):

show services unified-access-control status

View available information and roles for a specific IP address:

show services unified-access-control authentication-table ip x.x.x.x detail

View available information and roles for a specific user:

show services unified-access-control authentication-table user username detail