Traffic Analysis on Juniper SRX’s

Tim EberhardBAJUG3

So we have a lot of traffic on our network. Now what?

Live Session Table

Four main ways to look at traffic data on an SRX.

Policy Logs

Jflow

Packet Captures

Policy Logs

Policy logs-▪ Typically sent to an external syslog server

▪ Lots and lots of tools to collect syslogs

▪ Easy to parse and easy to read

When does it make sense to use them?▪ Historical analysis

▪ Policy denies

▪ High level overview over long periods of time

▪ Monitoring for unused rules

Dec 6 13:10:49 SRX220 RT_FLOW: RT_FLOW_SESSION_CREATE: session created 10.183.1.1/16138->10.194.201.112/9100 None 10.183.1.1/16138->192.168.168.12/9100 None vpn_printer 6 default-permit vpn trust 60756 N/A(N/A) st0.0

Jan 7 12:07:05 SRX5800 RT_FLOW: RT_FLOW_SESSION_DENY: session denied 10.1.1.100/53906->172.31.100.60/21 junos-ftp 6(0) web_deny trust web-dmz

Dec 6 13:11:20 SRX220RGA RT_FLOW: RT_FLOW_SESSION_CLOSE: session closed TCP FIN: 10.183.1.1/16138->10.194.201.112/9100 None 10.183.1.1/16138->192.168.168.12/9100 None vpn_printer 6 default-permit vpn trust 60756 98(78354) 56(2986) 31 N/A(N/A) st0.0

Using STRM to Analyze top talkers for the last 7 days

If you don’t have the funding for something fancy like STRM, Splunk or my SRX session Analyzer can parse traffic logs.

Caution: My log analyzer looks like shit compared to STRM

Live Session Table

Session Table-▪ A real time table of current traffic loads

▪ Better filters on the SRX than previously available on the Netscreen

When does it make sense to analyze?▪ Real time analysis of events

▪ Top talkers, bandwidth hogs, etc.

▪ High level overview of current sessions

How do we parse the session table?

You could use your unix sed, awk, uniq, grep foo..Or you could use the SRX Session Analyzer

In 2006 I built a session analyzer for the netscreen. Poorly called NSSA (Netscreen Session Analyzer). The SRX session Analyzer is just that same idea created for the SRX platform.

Free and open source posted on github. Written in python3.

Filter top talkers by:-Source IP-Dest IP-Source/Dest port-Policies-Protocol, Interfaces-Packets, Bytes

Why Analyze the session table vs looking at policy logs?

-Sessions that are persistent are not recorded to the policy logs. This means if a session is still open, you have a single log message about it. Session create. Until that session is close, you have no idea how much traffic it has passed or how long it has been up. Your session table could be completely different now vs yesterday.

-It’s easy to parse when troubleshooting current loads takes just 5-10 minutes to download analyze.

-Does not include drops or expired sessions. Real time useful data only.

Jflow

Jflow-▪ IP traffic sampling

▪ Typically samples a ratio of packets. Not often deployed 1:1

▪ Lots of great tools to parse and analyze

When does it make sense to use Jflow?▪ Historical analysis

▪ Analyzing traffic patterns

▪ Bandwidth usage

▪ Top talkers real time and historically

Looking back at Syslog. Here are the top talkers from syslog traffic logs…

Now looking at top talkers on that same network with Jflow.

All of a sudden a single address stands out. Low session usage but high bandwidth usage.

We also have the ability to look at the network from an application layer.

Ignoring that one bandwidth hog..

Packet Captures

Packet Captures-▪ Only available on the branch SRX’s

▪ Will dump in pcap format

▪ Allows detailed look of packets passing through firewall.

▪ Extremely resource intensive

When does it make sense to take a packet capture?▪ Extremely rarely. Seriously, a last resort.

▪ Troubleshooting application layer

▪ Gathering packet details for IDP signatures

A quick and dirty example-Set up the packet capture in forwarding-options.

[edit]user@host# edit forwarding-options packet-capture[edit forwarding-options packet-capture] user@host# set file filename mypacketcapture[edit forwarding-options packet-capture] user@host# set maximum-capture-size 1500

Set up a firewall filter to match the interesting traffic.

[edit] user@host#set firewall filter dest-jnet term dest-term from destination-address 207.17.137.239/32[edit] user@host#set firewall filter dest-jnet term dest-term then sample accept[edit] user@host#set firewall filter dest-jnet term default-permit then accept

[edit] user@host#set interfaces ge-0/0/0 unit 0 family inet filter output dest-jnet

Enable sampling on the interface. You can do input, output or both.

[edit]user@host# edit interfaces ge-0/0/0 unit 0 family inet

[edit interfaces ge-0/0/0 unit 0 family inet]user@host# set sampling input output

Packet captures are stored in /var/tmpuser@host> file list /var/tmp/ | match mypacketcapture*   mypacketcapture.ge-0.0.0