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