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

Juniper SRX - PKI - Certificate-based VPNs - Part 03 - SRX Configuration

Continuing on with Part 03 of this series (Part 02 found here), we'll finish the SRX configuration and bring up the tunnel:

set security ike proposal CERT_PROP authentication-method rsa-signatures
set security ike proposal CERT_PROP dh-group group2
set security ike proposal CERT_PROP authentication-algorithm sha1
set security ike proposal CERT_PROP encryption-algorithm aes-128-cbc
set security ike proposal CERT_PROP lifetime-seconds 86400

set security ike policy vSRX_02_CERT mode main
set security ike policy vSRX_02_CERT proposals CERT_PROP
set security ike policy vSRX_02_CERT certificate local-certificate SRX210_key_01
set security ike policy vSRX_02_CERT certificate peer-certificate-type x509-signature

set security ike gateway vSRX_02 ike-policy vSRX_02_CERT

set security ike gateway vSRX_02 address 10.0.0.102

set security ike gateway vSRX_02 external-interface reth2.0
set security ike gateway vSRX_02 local-identity user-at-hostname "your.email@domain.com"
set security ike gateway vSRX_02 remote-identity user-at-hostname "your.email@domain.com"

root@SRX210_A# run show security ike sa 10.0.0.102 detail
node0:
--------------------------------------------------------------------------
IKE peer 10.0.0.102, Index 1917721, Gateway Name: vSRX_02
  Role: Responder, State: UP
  Initiator cookie: 1bb59a819ce8e2df, Responder cookie: 4daa2c9906f66705
  Exchange type: Main, Authentication method: RSA-signatures
  Local: 192.168.0.211:500, Remote: 10.0.0.102:500
  Lifetime: Expires in 86381 seconds
  Peer ike-id: your.email@domain.com
  Xauth assigned IP: 0.0.0.0
  Algorithms:
   Authentication        : hmac-sha1-96
   Encryption            : aes128-cbc
   Pseudo random function: hmac-sha1
   Diffie-Hellman group  : DH-group-2
  Traffic statistics:
   Input  bytes  :                 2516
   Output bytes  :                 2296
   Input  packets:                    5
   Output packets:                    4
  Flags: IKE SA is created
  IPSec security associations: 1 created, 0 deleted
  Phase 2 negotiations in progress: 0

    Negotiation type: Quick mode, Role: Responder, Message ID: 0
    Local: 192.168.0.211:500, Remote: 10.0.0.102:500
    Local identity: your.email@domain.com
    Remote identity: your.email@domain.com
    Flags: IKE SA is created

Juniper SRX - PKI - Certificate-based VPNs - Part 02 - SRX Configuration & Certificate Signings

Continuing on with Part 02 of this series (Part 01 found here), we'll configure the SRX (at least partially) to utilize PKI and generate CSR's and have them signed by our previously configured CA.

1. Configure the ca-profile for the CA (version check included for posterity)

root@SRX210_A# show security pki | display set
set security pki ca-profile Ubuntu01 ca-identity Ubuntu01
set security pki ca-profile Ubuntu01 revocation-check disable

root@SRX210_A# run show version
node0:
--------------------------------------------------------------------------
Hostname: SRX210_A
Model: srx210h-poe
JUNOS Software Release [11.4R9.4]

root@vSRX_02# run show version
Hostname: vSRX_02
Model: junosv-firefly
JUNOS Software Release [12.1X44-D20.3]

2. Transfer (copy/paste) /etc/ssl/testCA/cacert.pem from your CA onto your SRX:

root@SRX210_A#  run start shell
root@SRX210_A% cat cacert.pem
-----BEGIN CERTIFICATE-----
MIIFtTCCA52gAwIBAgIBADANBgkqhkiG9w0BAQUFADB1MQswCQYDVQQGEwJDQTEQ
--------------------------SNIP FOR BREVITY------------------------------------
ymJ/BQZIyKLD9zvqgtjoMK/UoV6r/oVZWzX53B8uLcLBQqbWQivN7jb8j00hf5K9
HOnf7ieBfbYq/J20ik0TXAIsHkWGtKtVTA==
-----END CERTIFICATE-----

3. Import the CA's public key into the ca-profile created earlier:

root@SRX210_A> request security pki ca-certificate load ca-profile Ubuntu01 filename ~/cacert.pem

node0:

--------------------------------------------------------------------------

Fingerprint:

  56:57:3d:71:d2:55:b0:68:e7:f6:ee:53:3c:6a:5f:21:01:3b:8f:d5 (sha1)

  fe:4d:56:cd:6c:9c:34:5b:b8:cf:0d:bd:15:d1:87:15 (md5)

CA certificate for profile Ubuntu01 loaded successfully

4. Generate the SRX's private key:

root@SRX210_A> request security pki generate-key-pair type rsa size 2048 certificate-id SRX210_key_01

node0:

--------------------------------------------------------------------------

Generated key pair SRX210_key_01, key size 2048 bits

5. Generate the Certificate Signing Request (CSR) - no underscores in subject!:

root@SRX210_A>request security pki generate-certificate-request certificate-id SRX210_Key_01 email your.email@domain.com subject "DC=SRX210,CN=SRX210,OU=VPN,O=TestLab,L=Ottawa,ST=Ontario,C=CA"

node0:

--------------------------------------------------------------------------

Generated certificate request

-----BEGIN CERTIFICATE REQUEST-----

MIIC8jCCAdoCAQAweTEWMBQGCgmSJomT8ixkARkWBlNSWDIxMDEPMA0GA1UEAxMG

--------------------------SNIP FOR BREVITY------------------------------------

VwHvUcODc9OBKzYZzxUSDc8ICOkSNtW89WT7YYkBotdmCNbDZ74=

-----END CERTIFICATE REQUEST-----

Fingerprint:

48:1e:f5:a1:da:62:00:10:d9:66:62:3f:20:db:32:fe:5d:37:c8:41 (sha1)

01:5c:ca:b9:25:ad:1a:f0:c0:ae:16:fb:5a:47:dc:43 (md5)

6. Transfer (copy/paste) CSR to CA and verify:

root@Ubuntu01:/etc/ssl/testCa# openssl req -noout -text -in SRX210_key_01.csr

Certificate Request:

    Data:

        Version: 0 (0x0)

        Subject: DC=SRX210, CN=SRX210, OU=VPN, O=TestLab, L=Ottawa, ST=Ontario, C=CA

        Subject Public Key Info:

            Public Key Algorithm: rsaEncryption

                Public-Key: (2048 bit)

--------------------------SNIP FOR BREVITY------------------------------------

         cf:08:08:e9:12:36:d5:bc:f5:64:fb:61:89:01:a2:d7:66:08:

         d6:c3:67:be

7. Sign the CSR with the CA (cert is placed in certs/ and index.txt will be updated):

root@Ubuntu01:/etc/ssl/testCa# openssl ca -verbose -in SRX210_key_01.csr -out certs/SRX_210.pem -cert cacert.pem -extfile x509ext.txt

Using configuration from /usr/lib/ssl/openssl.cnf

Enter pass phrase for /etc/ssl/testCa/private/cakey.pem:

     --------------------------SNIP FOR BREVITY------------------------------------

Certificate is to be certified until Dec  5 02:26:27 2014 GMT (365 days)

Sign the certificate? [y/n]:y

1 out of 1 certificate requests certified, commit? [y/n]y

Write out database with 1 new entries

writing new certificates

writing /etc/ssl/testCa/newcerts/01.pem

Data Base Updated

root@Ubuntu01:/etc/ssl/testCa# cat index.txt ; ls -lh certs/
V       141205022627Z           01      unknown /C=CA/ST=Ontario/O=TestLab/OU=VPN/CN=SRX210
total 8.0K
-rw-r--r-- 1 root root 5.2K Dec  4 21:26 SRX_210.pem

8. Finally, transfer the signed SRX Certificate back to the SRX and import it:

root@SRX210_A> request security pki local-certificate load certificate-id SRX210_key_01 filename ~/SRX210.pem
node0:
--------------------------------------------------------------------------

Local certificate loaded successfully

root@SRX210_A> request security pki local-certificate verify certificate-id SRX210_key_01
node0:
--------------------------------------------------------------------------
Local certificate SRX210_key_01 verification success

You'll obviously have to rinse/repeat for each SRX you have in your lab. In Part 03 we'll explore actually using these certificates!

Juniper SRX - PKI - Certificate-based VPNs - Part 01 - Create your own Certificate Authority with Linux

Hi Everyone,

I was having issues getting a fully functional lab setup with PKI to use for testing Cert-based VPN's. I've pieced the following (functional!) steps together from multiple blogs and official OpenSSL documentation. Hopefully you'll find it useful during your studies.

1. Prepare the Server - Make sure to modify the email address field

mkdir -p testCa/{certs,private,newcerts} ; cd testCa/ ; touch index.txt ; echo "01" > serial
echo "subjectAltName=email:your_email_address_here" > x509ext.txt

2. Modify configuration file (/usr/lib/ssl/openssl.cnf) to use our testCA directory, and reduce the "strictness" when signing certificates (or use the one I've hosted here).

[ CA_default ]
dir             = /etc/ssl/testCa       # Where everything is kept

# For the CA policy
[ policy_match ]
stateOrProvinceName = supplied
organizationName = supplied

3. Generate the CA's Private Key (Password Required)

openssl genrsa -des3 -out private/cakey.pem 4096

root@Ubuntu01:/etc/ssl/testCa# openssl genrsa -des3 -out private/cakey.pem 4096
Generating RSA private key, 4096 bit long modulus
..........................++
............................................................++
e is 65537 (0x10001)
Enter pass phrase for private/cakey.pem:
Verifying - Enter pass phrase for private/cakey.pem:

4. Create the CA's Root Certificate (lasts for 5 years) - Fill in your correct details as required - Do not use underscores as they are not ANS.1 compliant

openssl req -new -x509 -key private/cakey.pem -out cacert.pem -days 1825 -set_serial 0

root@Ubuntu01:/etc/ssl/testCa# openssl req -new -x509 -key private/cakey.pem -out cacert.pem -days 1825 -set_serial 0
Enter pass phrase for private/cakey.pem:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:CA
State or Province Name (full name) [Some-State]:Ontario
Locality Name (eg, city) []:Ottawa
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:
Email Address []:

Juniper SRX - IDP Categories

Hi Everyone,

While trying to define some custom attack-groups for IPS, I was unable to actually locate a full list of categories to define my groups with. As such, I've included a list for everyone from the latest Attack Database below:

root@SRX210_A% cli show security idp predefined-attacks | sed 's/\"//g' | awk -F":" '{print $1}' | uniq

APP

CHARGEN

CHAT

DB

DDOS

DHCP

DISCARD

DNS

DOS

ECHO

FINGER

FTP

GOPHER

HTTP

ICMP

IDENT

IKE

IMAP

IP

LDAP

LPD

LPR

MISC

MS-RPC

NDMP

NETBIOS

NFS

NNTP

NTP

OS

P2P

POP3

PORTMAPPER

PROTOCOLS

RADIUS

REXEC

RLOGIN

RPC

RSH

RSYNC

RTSP

RUSERS

SCADA

SCAN

SHELLCODE

SMB

SMTP

SNMP

SNMPTRAP

SPYWARE

SSH

SSL

SYSLOG

TCP

TELNET

TFTP

TIP

TROJAN

UDP

VIRUS

VNC

VOIP

WHOIS

WORM

X11

As an aside, I found it mildly interesting to see the protections-per-category breakdown from Juniper:

root@SRX210_A% cli show security idp predefined-attacks | sed 's/\"//g' | awk -F":" '{print $1}' | sort | uniq -c | sort -n -r
4019 HTTP
 804 APP
 793 SPYWARE
 269 TROJAN
 260 SCAN
 254 SMTP
 209 DB
 160 CHAT
 158 VOIP
 156 SMB
 155 FTP
 145 P2P
 114 POP3
 109 DNS
 108 MS-RPC
 101 LDAP
  90 SHELLCODE
  80 SCADA
  76 SNMP
  75 WORM
  73 TCP
  65 IMAP
  62 SSL
  58 NETBIOS
  51 TELNET
  51 RPC
  47 SNMPTRAP
  42 DOS
  40 LPR
  40 DHCP
  37 VNC
  33 NTP
  33 NFS
  33 DDOS
  31 TFTP
  25 RADIUS
  23 RTSP
  22 ICMP
  20 SSH
  18 SYSLOG
  17 IKE
  17 FINGER
  16 RUSERS
  15 PROTOCOLS
  14 VIRUS
  14 PORTMAPPER
  14 NNTP
  13 OS
  13 IP
  12 RLOGIN
  12 IDENT
  10 GOPHER
   9 RSH
   6 MISC
   5 REXEC
   4 UDP
   4 LPD
   4 ECHO
   3 X11
   3 WHOIS
   3 RSYNC
   3 DISCARD
   3 CHARGEN
   2 TIP
   1 NDMP

Juniper SRX - OSPF over GRE over IPSEC

Hi everyone,

As promised, and as a continuation of my JNCIE-SEC studies, a follow up to the basic Route Based VPN article. This is how you can join two separate OSPF domains together across an IPSEC/GRE tunnel. Keep in mind running GRE is not necessary on an SRX<->SRX IPSEC tunnel, however more limited platforms like ASA's require it.

As a recap, this is the topology we're working with:

We'll do this for SRX210_A only, mirror the config to SRX210_B with slight adjustments if you're following along:

Create the GRE Tunnel and add it to our DMZ Zone, making sure to use st0 as the source/destination:

set interfaces gr-0/0/0.0 tunnel source 172.16.30.1
set interfaces gr-0/0/0.0 tunnel destination 172.16.30.2
set interfaces gr-0/0/0.0 family inet address 172.16.30.5/30
set security zones security-zone DMZ interfaces gr-0/0/0.0 host-inbound-traffic system-services ping

Ensure VPN allows any system service for the time being (lock it down later):

set security zones security-zone VPN host-inbound-traffic system-services any-service

Test time - Make sure your GRE tunnel is up and running by trying to reach the remote side:

ping 172.16.30.6 rapid 
PING 172.16.30.6 (172.16.30.6): 56 data bytes
!!!!!
--- 172.16.30.6 ping statistics ---
5 packets transmitted, 5 packets received, 0% packet loss

round-trip min/avg/max/stddev = 4.811/5.521/6.624/0.703 ms

OSPF Area 0  configuration for GRE and DMZ interfaces:

set security zones security-zone DMZ host-inbound-traffic protocols ospf
set protocols ospf area 0 interface gr-0/0/0.0
set protocols ospf area 0 interface fe-0/0/5.0

Verify OSPF neighbor adjacency across gr-0/0/0.0 and that you're receiving the correct routes:

show ospf neighbor
Address          Interface              State     ID               Pri  Dead
172.16.30.6      gr-0/0/0.0             Full      10.200.200.1     128    39

show route protocol ospf 
inet.0: 16 destinations, 17 routes (16 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.200.200.0/24    *[OSPF/10] 00:03:17, metric 2
                    > via gr-0/0/0.0
172.16.30.4/30      [OSPF/10] 00:03:28, metric 1
                    > via gr-0/0/0.0
224.0.0.5/32       *[OSPF/10] 00:03:38, metric 1
                      MultiRecv

You'll notice if you try and ping the remote hosts you'll get drop logs for DMZ -> DMZ:

May  2 09:47:27 192.168.0.212 RT_FLOW: RT_FLOW_SESSION_DENY: session denied 10.200.200.100/1->10.100.100.101/36102 icmp 1(8) global_drop_all(global) DMZ DMZ UNKNOWN UNKNOWN N/A(N/A) fe-0/0/5.0 No 

Finally, create a new policy to allow the new DMZ<->DMZ traffic we've just bridged:

set security policies from-zone DMZ to-zone DMZ policy DMZ_to_DMZ match source-address 10.100.100.0/24
set security policies from-zone DMZ to-zone DMZ policy DMZ_to_DMZ match source-address 10.200.200.0/24
set security policies from-zone DMZ to-zone DMZ policy DMZ_to_DMZ match destination-address 10.200.200.0/24
set security policies from-zone DMZ to-zone DMZ policy DMZ_to_DMZ match destination-address 10.100.100.0/24
set security policies from-zone DMZ to-zone DMZ policy DMZ_to_DMZ match application any
set security policies from-zone DMZ to-zone DMZ policy DMZ_to_DMZ then permit
set security policies from-zone DMZ to-zone DMZ policy DMZ_to_DMZ then log session-init

Verify our connectivity again by pinging from the remote hosts across the tunnel:

show security flow session destination-prefix 10.100.100/24 
Session ID: 38948, Policy name: DMZ_to_DMZ/15, Timeout: 2, Valid
  In: 10.200.200.100/17 --> 10.100.100.101/36614;icmp, If: gr-0/0/0.0, Pkts: 1, Bytes: 84
  Out: 10.100.100.101/36614 --> 10.200.200.100/17;icmp, If: fe-0/0/5.0, Pkts: 1, Bytes: 84

And we're done!

Full configuration will be uploaded to github shortly (once they're done their maintenance).
Full configuration on github

Juniper SRX - Route Based VPN How To

Hi everyone,

I'm currently working on my JNCIE-SEC, and figured I'd start posting some of the labs I'm working on. This one is the basis for all of my route-based VPN configuration.

Basic topology (we'll build on this later for more interesting things like OSPF over GRE):

We'll do this for SRX210_A only, mirror the config to SRX210_B with slight adjustments if you're following along:

Creating a route-based IPSEC VPN

Create the Secure Tunnel Interface (st0.0)

set interfaces st0 unit 0 family inet address 172.16.30.1/30
set security zones security-zone VPN interfaces st0.0

Create the IKE policy and proposal (phase one)

set security ike proposal ike_aes_128 dh-group group2
set security ike proposal ike_aes_128 authentication-method pre-shared-keys
set security ike proposal ike_aes_128 authentication-algorithm sha1
set security ike proposal ike_aes_128 encryption-algorithm aes-128-cbc

set security ike policy phase1_aes_128 mode main
set security ike policy phase1_aes_128 pre-shared-key ascii-text vpn123
set security ike policy phase1_aes_128 proposals ike_aes_128

Create the IKE Gateway (SRX210_B across ae1.0 - 172.19.1.2)

set security ike gateway SRX210_B ike-policy phase1_aes_128
set security ike gateway SRX210_B external-interface ae1.0
set security ike gateway SRX210_B address 172.19.1.2

Create the IPSEC policy and proposal (phase two)

set security ipsec proposal ipsec_aes_128 protocol esp
set security ipsec proposal ipsec_aes_128 authentication-algorithm hmac-sha1-96
set security ipsec proposal ipsec_aes_128 encryption-algorithm aes-128-cbc
set security ipsec policy phase2_aes_128 proposals ipsec_aes_128

Create the VPN and bind it to st0.0

set security ipsec vpn VPN_To_SRX210_B ike gateway SRX210_B
set security ipsec vpn VPN_To_SRX210_B ike ipsec-policy phase2_aes_128
set security ipsec vpn VPN_To_SRX210_B establish-tunnels immediately
set security ipsec vpn VPN_To_SRX210_B bind-interface st0.0

Verify the tunnel is up and working correctly (after configuring the peer):

show security ike security-associations
Index   State  Initiator cookie  Responder cookie  Mode           Remote Address
2534013 UP     1e051d13d519794d  1d833a97c85cf299  Main           172.19.1.2    

show security ipsec security-associations
Total active tunnels: 1
ID    Algorithm       SPI      Life:sec/kb  Mon vsys Port  Gateway
<131073 ESP:aes-128/sha1 c7570e07 3526/ unlim -  root 500   172.19.1.2  
>131073 ESP:aes-128/sha1 21a14b61 3526/ unlim -  root 500   172.19.1.2

And we're done! (sort of...)
We still have to configure a security policy to allow traffic to traverse between our VPN zone and our internal resources, as well as to create the correct routes for our peer's encryption domains. Since I'll be doing a tutorial on how to setup OSPF over GRE later on (to work with those pesky, lesser vendors), I'll leave this part blank for now. I'm sure you already know how to do this anyways :)

Github for the full configuration

Edit: Since someone has already asked how to make a generic working-config, this is basically how you do it:

Add a route for the remote encryption domain pointing to your secure tunnel interface:

set routing-options static route 10.200.200.0/24 next-hop st0.0

Add appropriate policies to permit traffic (bidirectional optional):

set security policies from-zone VPN to-zone DMZ policy Allow_All match source-address any destination-address any application any
set security policies from-zone VPN to-zone DMZ policy Allow_All then permit
set security policies from-zone VPN to-zone DMZ policy Allow_All then log session-init

set security policies from-zone DMZ to-zone VPN policy Allow_All match source-address any destination-address any application any
set security policies from-zone DMZ to-zone VPN policy Allow_All then permit
set security policies from-zone DMZ to-zone VPN policy Allow_All then log session-init

Juniper SRX - Compare Rollbacks

Hi Everyone,

As requested, here is how you can do a diff between rollbacks:

A) Determine which rollback you want to compare via:

root@SRX210_A> show system commit                              
0   2013-04-21 08:46:04 UTC by root via cli
1   2013-04-21 08:44:55 UTC by root via cli
2   2013-04-21 08:43:58 UTC by root via cli
3   2013-04-21 08:42:27 UTC by root via cli
4   2013-04-21 08:35:52 UTC by root via cli
5   2013-04-21 08:33:21 UTC by root via cli
6   2013-04-21 08:25:22 UTC by root via cli
7   2013-04-21 08:24:50 UTC by root via cli
8   2013-04-21 07:57:11 UTC by root via cli
9   2013-04-21 07:56:03 UTC by root via cli
10  2013-04-21 07:53:25 UTC by root via cli
11  2013-04-21 07:52:37 UTC by root via cli
12  2013-04-21 07:47:42 UTC by root via cli
13  2013-04-16 20:25:01 UTC by root via cli

B) Select the rollback you wish to compare based on the above list via:

root@SRX210_A> show system rollback compare 5 0  
[edit security policies from-zone Trust to-zone Trust policy Trust_to_Trust match]
-      source-address Net_192.168.0.0/24;
-      destination-address any;
-      application any;
+      source-address Net_192.168.0.0/24;
+      destination-address any;
+      application junos-icmp-all;
[edit security zones security-zone Trust address-book]
       address Net_192.168.0.0/24 { ... }
+      address Host_192.168.0.10 192.168.0.10/32;

The output above compares rollback '5' to the active configuration '0'

Juniper SRX - Create Global Drop/Cleanup rule

Hi everyone,

To avoid having to create a drop rule with logging enabled on an SRX for everyone Zone-to-Zone possibility, you can now create a global cleanup rule as of 12.1 like so:

# run show configuration security policies global | display set
set security policies global policy global_drop_all match source-address any
set security policies global policy global_drop_all match destination-address any
set security policies global policy global_drop_all match application any
set security policies global policy global_drop_all then deny
set security policies global policy global_drop_all then log session-init

A 'show security policies' will then show this as the last rule:
Global policies:

  Policy: global_drop_all, State: enabled, Index: 8, Scope Policy: 0, Sequence number: 1
    Source addresses: any
    Destination addresses: any
    Applications: any
    Action: deny, log

Looking at the log itself it'll show up as:

Apr 21 08:36:23  SRX210_A RT_FLOW: RT_FLOW_SESSION_DENY: session denied 192.168.0.10/33514->172.19.1.1/80 junos-http 6(0) global_drop_all(global) Trust Trust UNKNOWN UNKNOWN N/A(N/A) fe-0/0/6.0 No

Logging is currently configured as:

set system syslog file traffic-log any any
set system syslog file traffic-log match RT_FLOW_SESSION