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

Checkpoint Top Talkers Script - Display top 50 Source/Destinations

Hi Everyone,

I've finished writing a script that should be very useful to most of you. It allows you to determine the top 50 chattiest hosts on your network based on certain criteria.

This is what it looks like when you run it:

Hello, Welcome to the Checkpoint Top Talkers display utility by Craig Dods
-----------------------------------------------
    M A I N - M E N U
-----------------------------------------------
Please note that this is for use on devices with SecureXL enabled ONLY

1.  Display the top 50 Source/Destination combos
2.  Display the top 50 Source/Destination combos with identical Destination Ports
3.  Display the top 50 Source/Destination combos with identical Source Ports
4.  Display the top 50 Sources
5.  Display the top 50 Destinations
6.  Display the top 50 Source/Destination combos on a Custom Destination Port
7.  Display the top 50 Source/Destination combos on a Custom Source Port
8.  Display the top 50 Sources on a Custom Destination Port
9.  Display the top 50 Destinations on a Custom Destination Port
10. Display the top 50 Sources on a Custom Source Port
11. Display the top 50 Destinations on a Custom Source Port
12. Display the top 20 Destination Ports
13. Display the top 20 Source Ports
14. Display Connections From A Specific Host (large list)
15. Display Connections To A Specific Host (large list)
16. Exit

As you can see, there are quite a few options to choose from.

As an example, let's say you're simply trying to find out the busiest host-to-host connections and which ports they're using. Press #2 to see the results (the formatting looks better in bash, I swear - IP's are also obfuscated):

Please Make A Selection:  2
     #      SRC IP          DST IP       DPort
   9801 192.168.222.222  192.168.111.181  514    
    532 192.168.222.222  192.168.111.181  443    
    464 192.168.222.222  192.168.111.181  443    
    455 192.168.222.222  192.168.111.181  443    
    435 192.168.222.222  192.168.111.181    53      
    431 192.168.222.222  192.168.111.181  443    
    388 192.168.222.222  192.168.111.181  443    
    374 192.168.222.222  192.168.111.181  443    
    369 192.168.222.222  192.168.111.181  443    
    342 192.168.222.222  192.168.111.181  3995
    ................................
    Press [Enter] key to continue...

Another common use case would be if you're trying to determine which host is flooding a certain type of traffic (DNS/Syslog, etc). It's easy to determine who's causing the problem by using one of the 'Custom Port' options:

Looking for hosts generating DNS requests by using option #8:

Please Make A Selection:  8
Please enter the specific Destination Port you wish to filter for:
53

     #  SRC IP on DPORT 53
    199 192.168.0.0
    142 192.168.0.0
     94 192.168.0.0
     79 192.168.0.0
     33 192.168.0.0
     32 192.168.0.0
     26 192.168.0.0
     16 192.168.0.0
     16 192.168.0.0
     13 192.168.0.0

There are obviously many more use cases than I've covered above, so please try it out and let me know how it works!

Some caveats to keep in mind:
1) This only works on devices with SecureXL enabled
2) This may not work on every device. If you find out something isn't working in your environment, let me know!
3) All of this is based on active connections. At no point are these scripts monitoring actual throughput for any host.
4) Since we're pulling the information from SecureXL tables vs the connection table, there will be some oddities such as an entry for each direction of a connection if using option #1:

Please Make A Selection:  1
     #      SRC IP          DST IP
   9095 192.168.0.1  192.168.1.1
   9095 192.168.1.1  192.168.0.1

And finally, you can find the script right here . See my post about WGET if you're not sure on how to pull it down.

WGET on Checkpoint

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

Syslog-ng server recording remote syslog streams

Just a quick how-to for capturing remote syslog streams on Gentoo using syslog-ng

1) Backup your current configuration:

cp /etc/syslog-ng/syslog-ng.conf /etc/syslog-ng/syslog-ng.conf.backup

2) Modify the existing configuration file to accept any and all syslogs directed at the system (note: not exactly 'organized', but useful for a quick replication):

Paste the following above 'source src {' - modify tcp port/max-connections if required:

source s_syslog { unix-stream("/dev/log");
        udp();
        tcp(ip(0.0.0.0) port(5000) max-connections(300));
        pipe("/proc/kmsg");
        };

destination d_syslog { file("/var/log/remote-syslog"); };
log { source(s_syslog); destination(d_syslog); };

3) Restart syslog-ng via openrc (or systemd, whatever you're using). Ignore the pipe/FIFO errors:

 # /etc/init.d/syslog-ng restart
 * Stopping syslog-ng ...
[ ok ]
 * Starting syslog-ng ...
[ ok ]

4) Check to see that your new syslogs are being recorded to /var/log/remote-syslog:

# tail -f /var/log/remote-syslog
Apr 22 15:10:10 NiXToP syslog-ng[8878]: syslog-ng starting up; version='3.3.5'
Apr 23 02:40:52 192.168.0.211 RT_FLOW: RT_FLOW_SESSION_DENY: session denied 192.168.0.10/44870->172.19.1.2/443 junos-https 6(0) global_drop_all(global) Trust Trust UNKNOWN UNKNOWN N/A(N/A) fe-0/0/6.0 No
Apr 23 02:40:56 192.168.0.211 RT_FLOW: RT_FLOW_SESSION_DENY: session denied 192.168.0.10/46526->172.19.1.2/80 junos-http 6(0) global_drop_all(global) Trust Trust UNKNOWN UNKNOWN N/A(N/A) fe-0/0/6.0 No 

For future reference:

# uname -r && syslog-ng -V | head -n 1
3.8.6-gentoo
syslog-ng 3.3.5

Juniper SRX - Determine exact cause of high CPU on PFE

Hi Everyone,

Instead of relying on the sanitized/basic information the SRX generally provides you via usual commands, it's possible to log into the PFE directly and determine which underlying system is causing an issue:

Log into your PFE (there are LOTS of hidden commands available here, but I'll focus on threads):

root@SRX210_A# run start shell pfe network fwdd


BSD platform (OCTEON processor, 416MB memory, 8192KB flash)

FLOWD_OCTEON(SRX210_A vty)# show threads

PID PR State     Name                   Stack Use  Time (Last/Max/Total) cpu

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

  1 H  asleep    Maintenance            976/73824  0/7/14 ms  0%

  2 L  running   Idle                  1296/73824  0/8/10035 ms  0%

  3 H  asleep    Timer Services        1040/73824  0/8/270 ms  0%

  5 L  asleep    Ukern Syslog           856/73824  0/0/0 ms  0%

  6 L  asleep    Sheaf Background      1296/73824  0/0/0 ms  0%

  7 M  asleep    mac_db                 856/73824  0/0/0 ms  0%

  8 M  asleep    Docsis                1072/73824  0/8/184 ms  0%

  9 M  asleep    ATMX                  1136/73824  0/8/491 ms  0%

 10 M  asleep    XDSL                  1352/73824  0/8/30394 ms  0%

 11 M  asleep    DSX50ms               1272/73824  0/8/2491 ms  0%

 12 M  asleep    DSXonesec             1048/73824  0/8/104 ms  0%

 13 M  asleep    SFP                   1216/73824  0/8/295 ms  0%

 14 M  asleep    Ethernet              1184/73824  0/15/90202 ms  1%

 15 M  asleep    RSMON syslog thread   1024/73824  0/0/0 ms  0%

 16 L  asleep    Syslog                1264/73824  0/8/113 ms  0%

 17 M  asleep    Fwdd Notif Recv       1512/73824  0/8/2816 ms  0%

 18 M  asleep    Forwarding Thread     2456/73824  0/15/36745 ms  0%

 19 M  asleep    Periodic             12936/73824  0/15/21958 ms  0%

 20 M  asleep    USB Thread            1328/73824  0/8/776 ms  0%

 21 M  asleep    FPC_IPC-Thread        2368/73824  0/0/0 ms  0%

 22 H  asleep    TTP Receive           1320/73824  0/15/6219 ms  0%

 23 H  ready     TTP Transmit          1104/73824  0/8/1480 ms  0%

 24 M  asleep    UDP Input              904/73824  0/0/0 ms  0%

 25 H  asleep    TCP Timers            1264/73824  0/8/312 ms  0%

 26 H  asleep    TCP Receive            816/73824  0/0/0 ms  0%

 32 L  asleep    Console               3504/73824  7/7/7 ms  0%

.................etc

You can then look into a certain hook more closely if desired:

FLOWD_OCTEON(SRX210_A vty)# show threads 14
PID PR State     Name                   Stack Use  Time (Last/Max/Total) cpu
--- -- -------   ---------------------  ---------  ---------------------
 14 M  asleep    Ethernet              1184/73824  0/15/95814 ms  1%

Wakeups:
      Type  ID  Enabled  Pending   Context
 Semaphore  00      Yes       No  0x489ac008
     Timer  00      Yes       No  0x489ac158

Frame 00: sp = 0x48cbab38, pc = 0x08014d94
Frame 01: sp = 0x48cbabb0, pc = 0x08215c98
Frame 02: sp = 0x48cbabf0, pc = 0x0802b960
Frame 03: sp = 0x48cbac18, pc = 0x00012060

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

SPLAT R76 fails to install on VMware ESXi 5

Hi everyone

Just a quick one: I went to install the open-server version of SPLAT R76 today on our ESXi host and ran into an error almost immediately. It was the same anaconda error that is found in CheckPoint sk92354 :

Traceback (most recent call last):
File "/usr/bin/anaconda", line 661, in ?
intf.run(id, dispatch, configFileData)
File "/usr/lib/anaconda/text.py", line 441, in run
rc = apply(win, (self.screen, ) + args)
File "/usr/lib/anaconda/textw/splat_comps_text.py", line 56, in __call__
splatCompProcess("Software Blades", screen, meothod, sc,selectedProductsObj,prodLine)
File "/usr/lib/anaconda/textw/splat_comps_text.py", line 48, in splatCompProcess
while (sc.copyNextFile(CD) == -1):
File "/usr/lib/anaconda/splatcomps.py", line 231, in copyNextFile
ret = self.copyFile(source, dir, dest)
File "/usr/lib/anaconda/splatcomps.py", line 85, in copyFile
os.write(d, count)

Changing the SCSI controller from VMware Paravirtual to LSI Logic SAS allows the system to run through the initial configuration/formatting correctly.

WGET on CheckPoint

Just a quick post here since I've been asked about the best way of transfering the scripts I host on github to a FW. The answer of course is wget :)

It's not in the default $PATH of SPLAT/GAIA, however on every version I've looked CP has hidden it somewhere on the device.

For example:

[Expert@R75-B]# wget
-bash: wget: command not found
[Expert@R75-B]# find / -name wget
/var/tmp/CD1/linux/MiniWrapperForMajor/linux/Actions/wget
/sysimg/CPwrapper/linux/MiniWrapperForMajor/linux/Actions/wget

If you want to pull one of my scripts down directly (and assuming you've got a name server in /etc/resolv.conf...), just use the binary in one of the results from find like so:

Tada:

[Expert@R75-B]# /sysimg/CPwrapper/linux/MiniWrapperForMajor/linux/Actions/wget https://raw.github.com/craigdods/scripts/master/interface_rebuild_splat.sh
--10:14:27--  https://raw.github.com/craigdods/scripts/master/interface_rebuild_splat.sh
           => `interface_rebuild_splat.sh.1'
Resolving raw.github.com... done.
Connecting to raw.github.com[199.27.72.133]:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 748 [text/plain]

100%[=================================================================================================================================================================================================>] 748          730.47K/s    ETA 00:00

10:14:27 (730.47 KB/s) - `interface_rebuild_splat.sh.1' saved [748/748]

SPLAT: Interface rebuild script

Hi everyone,

Today I got tired of using sysconfig to create hundreds of subinterfaces while migrating large FWs to new hardware, so I've gone ahead and made a script which does it for you.

First (optional, really), take a backup of your existing firewall with this script:

Interface Backup Script

Side note:
Instead of using this to restore/migrate interfaces, since the format is extremely easy (interface IP netmask), you can use this to quickly configure a new device as well.

Second, transfer the file (or create your own) on the new hardware, and run the rebuild script:

Interface Rebuild Script

Here it is in action:

New firewall (basic config):

[Expert@R75-B]# ifconfig -a | grep -A 1 eth
eth0        Link encap:Ethernet  HWaddr 00:0C:29:13:5C:FC
            inet addr:192.168.0.60  Bcast:192.168.0.255  Mask:255.255.255.0
--
eth1        Link encap:Ethernet  HWaddr 00:0C:29:13:5C:06
            BROADCAST MULTICAST  MTU:1500  Metric:1
--
eth2        Link encap:Ethernet  HWaddr 00:0C:29:13:5C:10
            BROADCAST MULTICAST  MTU:1500  Metric:1

Run the script:

[Expert@R75-B]# ./interface_rebuild_splat.sh 

Hello, please enter the correct log file to analyze

firewall_interfaces_backup

Thank you - Recreating interfaces now

Finished recreating the interfaces...

Please remember to run ifconfig --save when finished!

Goodbye 

[Expert@R75-B]# ifconfig --save

We can now see all of our interfaces have been created and are present in netconf.C:

[Expert@R75-B]# ifconfig -a | grep -A 1 eth

eth0        Link encap:Ethernet  HWaddr 00:0C:29:13:5C:FC  

            inet addr:192.168.0.60  Bcast:192.168.0.255  Mask:255.255.255.0

--

eth1        Link encap:Ethernet  HWaddr 00:0C:29:13:5C:06  

            inet addr:1.1.1.1  Bcast:1.1.1.255  Mask:255.255.255.0

--

eth2        Link encap:Ethernet  HWaddr 00:0C:29:13:5C:10  

            UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

--

eth2:2      Link encap:Ethernet  HWaddr 00:0C:29:13:5C:10  

            inet addr:10.2.2.1  Bcast:10.2.2.255  Mask:255.255.255.0

--

eth2:3      Link encap:Ethernet  HWaddr 00:0C:29:13:5C:10  

            inet addr:10.3.3.1  Bcast:10.3.3.255  Mask:255.255.255.0

--

eth2:4      Link encap:Ethernet  HWaddr 00:0C:29:13:5C:10  

            inet addr:10.4.4.1  Bcast:10.4.4.255  Mask:255.255.255.0

--

eth2:5      Link encap:Ethernet  HWaddr 00:0C:29:13:5C:10  

            inet addr:10.5.5.1  Bcast:10.5.5.255  Mask:255.255.255.0

--

eth2:6      Link encap:Ethernet  HWaddr 00:0C:29:13:5C:10  

            inet addr:10.6.6.1  Bcast:10.6.6.255  Mask:255.255.255.0

--

eth2:7      Link encap:Ethernet  HWaddr 00:0C:29:13:5C:10  

            inet addr:10.7.7.1  Bcast:10.7.7.255  Mask:255.255.255.0

etc....

You can see them via sysconfig:

Choose a connection to display ('e' to exit):

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

1) eth0       4) eth2:10   7) eth2:13  10) eth2:3   13) eth2:6

2) eth1       5) eth2:11   8) eth2:14  11) eth2:4   14) eth2:7

3) eth2       6) eth2:12   9) eth2:2   12) eth2:5   15) eth2:8

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

(Note: configuration changes are automatically saved)

And it's in netconf.C:

[Expert@R75-B]# cat /etc/sysconfig/netconf.C | grep -B 1 -A 6 eth2:6

                : (conn

                        :ifname ("eth2:6")

                        :type (3)

                        :ipaddr ("10.6.6.1/24")

                        :onboot (1)

                        :depend-on (eth2)

                        :s-code (0)

                )

You might find this useful in combination with my  route rebuild scripts located here:

Route rebuild scripts for SPLAT+GAIA

Hopefully some of you get some use out of this! :)