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!