F5 SSL traffic capture and decrypt - iRule

 To capture SSL traffic and decrypt it on a virtual we can use the below iRule.

First create the iRule and save it example SSL_Decrypt_iRule

when CLIENTSSL_HANDSHAKE {
    log local0. "Client Side [IP::client_addr][TCP::client_port] :: RSA Session-ID:[SSL::sessionid] Master-Key:[SSL::sessionsecret]"
  }
when SERVERSSL_HANDSHAKE {
    log local0. "Server Side [IP::client_addr][TCP::client_port] :: RSA Session-ID:[SSL::sessionid] Master-Key:[SSL::sessionsecret]"
}

Attach this to the VIP for the duration of the test. Don't forget to remove it after or else it will keep logging the Session ID's to the log file.

After the tcp capture is completed, use the below command from CLI to extract the session keys to the pms file

sed -e 's/^.*\(RSA Session-ID\)/\1/;tx;d;:x' /var/log/ltm > /var/tmp/problem.pms

Now open the pcap and use the pms file to decrypt the requests.

Extract F5 ASM attack signature rule

 Just for troubleshooting if you need to extract ASM signature rules run the below on a device that is not heavily used or after hours since its process intensive from the CLI.

"mysql -uasm -p`perl -I/ts/packages -MF5::Cfg -e 'print F5::Cfg::get_mysql_password()'` PLC -e "select PLC.NEGSIG_SETS.set_name,PLC.NEGSIG_SETS.set_id,PLC.NEGSIG_SIGNATURES.sig_id,PLC.NEGSIG_SIGNATURES.sig_name,PLC.NEGSIG_SIGNATURES.rule  from PLC.NEGSIG_SETS,PLC.NEGSIG_SIGNATURES order by set_name,sig_id;" > /var/tmp/unit1_sig_sets.out"

F5 scheduled backup script.

F5 scheduled backup script

I needed an automatic backup solution to backup LTM's and GTM's devices in my environment. The below scripts would generate UCS, scf files and would then transfer the files to FTP server.
 
Create 2 files dailybackup.sh and monthlybackup.sh

Copy the below code into those files. Daily backup will be send to the FTP server and I needed monthly backup which runs once every month to be on the device. The only change that needs to be done here is FTP SERVER IP, FTP USER and FTP PASSWORD and the beginning of the script and it should work fine.
 
Daily – Backup files sent to FTP server
Monthly – Backup files on the F5 devices @ /var/local/usc and /var/local/scf folders

Daily backup script –

#!/bin/bash
#/home/root/dailyf5backup.sh
HOST="<>"      # FTP Server IP
USER="<>"       # FTP User
PASS="<>"    # FTP Password
DIR="/"        # FTP Directory

#Create current date/time stamp variable
DATETIME=$( date '+%Y-%m-%d_%H-%M' )

#Create hostname variable
HOSTNAME=$(uname -n| cut -f 1 -d".")
UCS_FILENAME="${DATETIME}_$HOSTNAME"
SCF_FILENAME="${DATETIME}_$HOSTNAME"

#Delete files that are older than 10 days
find /var/tmp/*.tar -mtime +10 -type f -delete
find /var/tmp/*.scf -mtime +10 -type f -delete
find /var/tmp/*.ucs -mtime +10 -type f -delete
logger -p local0.info -t BIGIP configuration backup started.
cd /config
tmsh save /sys config
tmsh save /sys ucs /var/tmp/$UCS_FILENAME.ucs
tmsh save sys config file /var/tmp/$SCF_FILENAME.scf
logger -p local0.info -t BIGIP configuration upload to $HOST started.
FILE=/var/tmp/$hostname.ucs
TONAME=$hostname-$DATE.ucs
ftp -inv $HOST<    user $USER $PASS
    bin
    lcd /var/tmp
    cd $DIR
    put $UCS_FILENAME.ucs
 put $SCF_FILENAME.scf
 put *.tar
   quit
END_SCRIPT
logger -p local0.info -t BIGIP configuration upload to $HOST completed.
logger -p local0.info -t BIGIP configuration backup completed.
exit 0

Monthly backup script -

#!/bin/bash
#/home/root/monthlyf5backup.sh
#
#UCS Files will be saved to /var/local/ucs/
#SCF Files will be saved to /var/local/scf/
#Create current date/time stamp variable
DATETIME=$( date '+%Y-%m-%d_%H-%M' )
#Create hostname variable
HOSTNAME=$(uname -n| cut -f 1 -d".")

#Uncomment the following line for troubleshooting
#echo $DATETIME
#Create filename variable
UCS_FILENAME="${DATETIME}_$HOSTNAME"

#Uncomment the following line for troubleshooting
#echo $UCS_FILENAME

#Save the system config before saving UCS and SCF files.
tmsh save /sys config

#Create a UCS archive with the filename specified above

#The file extension will be .ucs will be available in the GUI
tmsh save sys ucs "${UCS_FILENAME}"

#Also create an SCF file with the same filename
#The file extension will be .scf won't be available in the GUI
tmsh save sys config file "${UCS_FILENAME}.scf"

#If you don’t delete these files /var will become full fairly quickly
#Change the +31 value (10 days) to whatever suits you
#find /var/local/ucs/*.ucs -mtime +10 -type f -delete
#find /var/local/scf/*.scf -mtime +10 -type f -delete\
#find /var/local/scf/*.scf.tar -mtime +10 -type f -delete
#EOF

To make the above scripts executable run the below command –
Chmod u+x /home/root/backup.sh ( I shored my scripts @ /home/root
..and finally both the scripts to the cronjob daily to run every day, monthly to run on first of every month.

crontab -e
type: crontab -e and add the following line, as the bigip is using vim as editor for crontab, you have just to type i for insert first. After inserting   the line below just hit Escape and type :wq for write and quit

@daily /home/root/dailyf5backup.sh
@monthly /home/root/maonthlyf5.backup.sh

One thing to remember is when the BigIP devices are updated with newer versions of firmware, the copy config does not move these backup scripts so you have to do this all over again or store these scripts in /shared/tmp folder.

Enjoy...!

What is F5 license dates and service check date?

On the BigIP device under /config --> you can see a file called bigip.license. This file is typically your license file which has information like what modules are provisioned, list out any additional licenses that were added, platform id. Serial number etc.

Now before upgrading your F5 device its always recommended that admin should reactivate the license. What happens during this process is that the service check date would get updated in bigip.license file which will then allow you to upgrade to the latest and greatest firmware. This is based on your active support contract.

If the license is not Re-Activated and the Service check date is earlier than license check date then the config will not load. You will get an error saying - Config failed to load....

Fail - Service check date is 1/1/2016 and License date is 3/18/2016 (this is just as an example)

Pass - Service check date is 4/1/2016 and License date is 3/18/2016

Service check date - is updated each time when you re-activate the license based on your active support contract.

License check date  - is a static date corresponding to the software version.

https://support.f5.com/kb/en-us/solutions/public/7000/700/sol7727.html

The above F5 link provides the license dates for different versions.

Connection reaping

Can be defined as the process of manually cleaning/clearing the inactive/stale connections from the connection table.

Big IP maintains every connection in the connection table. (Server side and client side). Each connection uses LTM resources since they are monitored.So that is why this connection table can not grow to big or else all the resources are used to maintain this table which might lead to starvation of resources when/where they are actually needed.

Some connection might have a tear down sequence while others might not. It depends on the protocol as well for example TCP usually would have this tear down sequence but UDP will not since its connectionless. So F5 depends on the idle timeout values to remove old, stale connections. The idle timeout values can be manipulated by using profile assigned to the VIP - Virtual IP of the LTM device.

Checkpoint Lab - 11 (LDAP integration) Tutorial

LDAP Integration - 

Before we proceed for the lab setup I am using Microsoft Active Directory for LDAP. Its configured and setup - itlinks.com. Create 4-6 test users and one user with admin credentials - cpadmin

There are multiple ways to authenticate or tie your users if you will to a centralized auth like LDAP. You can create users locally and give out id/password to your users, configure LDAP, RADIUS or TACACS ect to manage and give access to users. Once the LDAP is setup Check point then can make queries against the LDAP server and read the user data. The calls to the LDAP server can be encrypted (port 636) or unencrypted (port 389).

Create users locally - This is very simple method. If you have a small environment small number of users can be created manually with ease. But if you have 1000 users at that point you might consider integrating it with LDAP.
Backup the existing policy on which you have been working so far. Create a db revision to restore if any thing goes wrong.
Select the user container, right click select new user, select default.

In General properties enter the user name and other relevant information.


















Option to create groups and club the users under groups is available as well. Since this is a local user creation under "Authentication"  select "Check Point Password" and enter the password and save the user.

Example of group creation and adding the user to the group is below.

For adding LDAP server follow the below steps -
Create a user id (cpadmin) in AD to be used by checkpoint exclusively to query the LDAP db.
Create a bridge from checkpoint to LDAP server.
Create a LDAP group that utilizes this bridge and gets the user information.
I created a group called "Firewall" in the AD and in that group I have the users as listed below -

Next open the "Global properties" from Smart Dashboard and check the below option -

Again from the dashboard open "Launch Menu" --> Manage --> "Servers and OPSEC Applications"

It opens up a window, internal_ca is default value that is pre populated. To create bridge click "New" and select "LDAP Account Unit"

Here in the LDAP account unit the AD server details and id that has rights to query the AD needs to be entered as shown below. If you also want to manage CRL and users check the boxes highlighted below.

Servers tab is used to add the LDAP server itself and provide the user details. Click "Add"

I created an object called "MainDC" which is the active directory server. Port is selected as 389 and input the other info as per the screen print. Check the encryption when you can setup the secure communication. I would advice if its a production to go and use that option,but here since this is a lab setup I will use the unsecured communication.

Click ok and you will see -

Select the "Object Management" tab and click on "Fetch Branches" tab, if the config is correct it will query the AD and display as below

Finally on the "Authentication" tab select "Checkpoint Password"

Once the bridge config is done, its visible under "Users and Administration" container. Right click and choose "Update tree" , its going to pull the entire AD content..

So far good, the remaining task is to create a group utilizing this bridge. Right click the "LDAP Groups" and enter a name that you want to reference it as, select the account unit and in group scopes you can define Sub trees since its X.509 Compatiable.

So this is how we link check point to LDAP server.

Checkpoint Lab - 10 (Building VPN tunnel) Tutorial

VPN Tunnel -  

In this section lets see how to setup an IPSec VPN tunnel between Main Office and Branch Office. In order to setup a VPN connection between 2 systems we must cover the process and methods on what happens when VPN connections is established and how it works. The main purpose of establishing a VPN tunnel is to give users access to the resources @ either offices with out creating NAT's. (Its not always possible to create NAT's for example lets say a network admin who has access to all the server and workstations travels to branch office and then is called to work on an issue in main office, its not possible to put all the servers or work stations on NAT for him to access externally. So to make sure he has access to all resources same like when he is sitting in the main office Site to site VPN can be established). Once the user VPN's in or a VPN tunnel is established they can access 10.1.1.0 or 10.2.2.0 networks including the DMZ's as soon as the policies are created.
To use any VPN technology the data packet between the 2 points need to be encrypted (DES, 3DES or AES) and the integrity of the data packet should be checked constantly (MD5, SHA) to determine the packet sent is actually the packet received.

Concept - Symmetrical key exchange

• The technology by which 2 devices use the same key to encrypt and decrypt the data packet. Content to generate and exchange must be done in secure fashion.
• Internet key exchange (IKE) is used to accomplish the above. (Version1, Version 2)
• Diffie-Hellman (DH) is the method that the symmetrical keys are built and exchanged.

There is a great article from checkpoint regarding the IPSec VPN. I would strongly recommend to read this before proceeding further.

IKE version1 - The VPN connection is setup in 2 phases.

Phase1 - Both the peers negotiate on the technologies they will use to set the connection, similar to SSL (article posted here)
They authenticate with each other using a pre shared key or a certificate.
Both the parties create a shared key that only either of them knows using DH.Using this key the subsequent data is exchanged.
At this point IKE Phase 1 tunnel is established between 2 end points.
This phase supports 2 modes
Main mode  - Its the default mode where the IKE negotiation happens using 6 packets. This mode is less vulnerable to Dos attacks. DH computations is done after the auth is done unlike aggressive mode where both are done at same time.
Aggressive mode  - It performs the IKE negotiation with three packets. (Config vai check box 13 images down - Advanced VPN Properties)

Phase2 - This kicks in when the client actually initiates the traffic. Like admin tries to connect to a server in main office.
Both the parties start a new negotiation based on the previous Phase1 negotiation (The encryption and hash values can be changed, need not be the same, we can use SHA and AES in phase2 if in phase1 we used MD5 and 3DES)
Symmetric IPSec keys are created using DH keys from phase1 and an IPSec tunnel is built for the bulk data exchange. Depending on the values selected it can be taxing on systems but hard to break and vice versa.

Checkpoint terminology for VPN

Mesh - When the requirement is to set up vpn tunnels between all the gateways so that they can talk to each other then its called Mesh topology.

Start or Hub and Spoke - When the requirement is setup a tunnel between One (Main Office) and multiple branches. The branch office can only communicate with the main office but not with each other.

VPN Community - The entire topology gateways, servers, routers, switches between which the tunnel is setup is called VPN community.
VPN Member - The gateway/Firewall from which the VPN connection will be configured is called VPN member.
VPN Domain - The network (excluding the gateway) is called VPN domain. For example 10.1.1.0 with server, DMZ, work stations, manager is called a VPN domain.
VPN Site  - VPN Domain + VPN Member.

 Now lets setup VPN tunnel between main and branch office in the lab environment.
First thing to check and enable is the IPSec VPN blade on the gateways.

Next step is to define VPN domain. A gateway has multiple interfaces, we have an option of defining which subnet should be part of the VPN domain. Go to "Topology" option  and for the VPN domain either choose all the interfaces or we can manually specify the interface which should be part of the domain. In the lab I am using the 10.X.X.X subnet so selected "Main_Internal_10.1.1.0" at main office and "Branch_Internal_10.2.2.0" at branch office.

Now a VPN community needs to be defined. So go to Smart Dash Board and select "IPSec VPN" tab.

We will setup Star or Hub and spoke community between the 2 lab gateways.

Because its hub and spoke select Main office gateway device as Center Gateways and Branch office device as Satellite Gateways by using "Add" button.

In the encryption options we can select what version of IKE to use, version 1 is selected by default (Usually version 2 is used with IPv6 and when you need to set up the site to site vpn tunnel with a non checkpoint device like Cisco or sonic wall version 2 is not supported).

Encryption Suite lets you define hash, encryption, DH algorithms...by default "Custom" is selected. As mentioned earlier the encryption can be different for phase1 and phase2 so I changed the phased 2 to AES-128 and SHA 256.

Tunnel management option lets you define how many VPN tunnels need to be opened between gateways - default value is "One VPN tunnel per subnet pair" so it uses one phase2 IPSec tunnel and let the whole subnet 10.1.1.0 and 10.2.2.0 talk.

Most important thing is to disable natting when you VPN in from one site to another because its not needed and if the user from site A connects to a resource in site B the source packet will be natted to the gateway and the resource will send the packet to the gateway.

We can also specify the DH properties at phase1 and 2, renegotiate SA option (the more number of times that its negotiated and recreated the more secure, but overhead on resources is also more)

By following the above steps the new VPN community is setup.
Next thing to accomplish is to set up the policy for the flow of traffic.  The VPN policy that need to be in place for the VPN communication to happen is below (Save and install the policy once created.)

 This completes the site to site VPN set up. So test this from main office network ping ClientB at branch office. For some reason if the ping does not work check to see the smart view tracker. If the policies are setup as per the lab example you should get a response back. Open the smart view tracker to look at the VPN traffic.

 The first key is phase1 and the second is pahse2. Double click the first key and you will see that its AES-256+SHA1 encryption as per Custom Encryption Suite (6 screenshots up)

Open the second key and you will see phase 2 tunnel build log.

Since we enabled Perfect Forward Secrecy (6 screen prints above) PFS, AES-128 and SHA 256 are displayed in the phase 2 negotiation. From the CLI perspective "vpn tu" can be used to look at the LKE and IPSec SA's. Go through all the options, try deleting the SA and initiate the ping requests and see how the communication happens.

This concludes the site to site VPN setup.