Integrate F5 SSL VPN with CheckPoint Identity Awareness
Problem this snippet solves: Goal This snippet allows you to use "identity based" rules on a CheckPoint firewall to manage the permissions for users connected by SSL VPN with F5 APM. Context Usually, when deploying SSL VPN with F5 APM, you need to use F5 ACL to manage the permissions for the VPN users defining which user or group is allowed to reach which servers or networks. These rules may be duplicates of existing rules implemented in the core firewall of the company. Since the mappings (username, assigned VPN IP) is known only by F5, it is impossible for the core firewall to apply the proper filtering based on users identity. The idea with this snippet is to be able to manage all the rules centrally on the CheckPoint firewall such as the following : User "Paul Anderson" is allowed to reach the network 10.10.1.0/24 User "Robert Schmitt" is allowed to go everywhere except 10.10.2.0/24 Active Directory group "Admins" is allowed to go everywhere on TCP ports 443 and 22 This snippet allows this kind of rules defined in a CheckPoint gateway to work also when the users are connected with F5 APM SSL VPN. How it works We are using the new CheckPoint R80 Web API to spread the association (username, assigned VPN IP) to the CheckPoint gateway. Indeed, the VPN connection follows the following steps : The user "Paul Robert" connects the F5 SSL VPN (through the Edge Client or the browser helper) The user "Paul Robert" is given an IP by F5 within the "lease pool" : let's say 192.168.1.13 F5 sends an HTTP request to the CheckPoint Identity Awareness Web API containing the association : 192.168.1.13 --> "Paul Robert" When Paul generates traffic through the VPN, this traffic is seen as coming from the source IP 192.168.1.13 from the CheckPoint firewall point of view. The firewall is able to apply the proper "identity based rules" because it knows that 192.168.1.13 is actually "Paul Robert" How to use this snippet: Requirements APM module provisioned on F5 SSL VPN service already configured with APM Import the iRule "HTTP Super Sideband Requestor" on your F5 Download here This iRule must be named "HSSR" and must be in the partition "Common" CheckPoint Gateway R80 with the blade Identity Awareness enabled Existing firewall rules based on identity CheckPoint Identity Awareness Web API By default, the WebAPI is not enabled in a CheckPoint gateway, you need to first configure it. The configuration is simply setting up which source IP are allowed to use the API and defining a secret for each client. It is done in the gateway object from the Smart Console : Here I configured my F5 as a WebAPI client with the secret "Fr38N....." Once the configuration is done, you need to install the policy on the gateway to apply the configuration. To validate the WebAPI is working, you can use the following bash command on F5 : curl -k -v --data '{ "shared-secret":"<api_secret>", "ip-address":"1.2.3.4", "user":"testuser1" }' https://<checkpoint_gw_ip/_IA_API/v1.0/add-identity This command sends the association (IP : "1.2.3.4" --> User: "testuser1"). If successful, you should get the following message from the gateway : { "ipv4-address" : "1.2.3.4", "message" : "Association sent to PDP." } F5 configuration Once you've validated the CheckPoint WebAPI is working and the F5 SSL VPN is ready, the needed configuration to integrate F5 with CheckPoint is composed of the 4 following steps : Create a new pool Pool member: CheckPoint gateway IP / port 443 Monitoring TCP Create a new local virtual server Type: standard Destination : A fake, non existing IP address (such as 1.1.1.1 for example)* Port : 443 Server SSL profile : serverssl-insecure-compatible Pool : previously created pool Source address translation: Automap (if needed) Import the iRule in this snippet with the following adaptations : Change <secret_api> with your WebAPI secret Change <vs_name> with the name of the previously created virtual server Add this iRule to your existing SSL VPN virtual server Testing After having applied the iRule, every new VPN connection should append the following line in the log file /var/log/ltm on F5 : VPN : Publishing VPN IP in CheckPoint identity - SUCCESS Moreover, all your existing "identity based rules" in CheckPoint must now work with clients connected through the F5 VPN. Notes For this configuration we made two assumptions : The "network access" object for the VPN is not doing any SNAT (SNAT Pool: none). Indeed, if we are using "Automap" for the network access, all the connected clients are hidden behind the same IP, so there is no way to identify the users outside of F5. In the iRule, we suppose the username to send to CheckPoint is present in the APM variable "session.logon.last.username". If it's not your case, you need to adapt the iRule by changing this variable name. Code : when RULE_INIT { ## Secret configured on CheckPoint to authenticate the F5 to the Web API set static::checkpoint_api_secret " " } when CLIENT_ACCEPTED { ACCESS::restrict_irule_events disable } when HTTP_REQUEST { # Thx to John Alam for this way to get assigned VPN IP # https://devcentral.f5.com/s/questions/how-do-i-record-the-ip-assigned-to-a-client-after-login if { [HTTP::uri] starts_with "/myvpn?sess=" } { after 5000 { set api_username [ACCESS::session data get session.logon.last.username] set vpn_ip [ACCESS::session data get session.assigned.clientip] set jsonBody "{ \"shared-secret\":\"$static::checkpoint_api_secret\", \"ip-address\":\"$vpn_ip\", \"user\":\"$api_username\" }" set sts [call /Common/HSSR::http_req -virt /Common/ -uri "http://checkpoint.webapi.local/_IA_API/v1.0/add-identity" -method POST -body $jsonBody -rbody apiResp] if { $apiResp contains "Association sent to PDP" } { log local0. "VPN : Publishing VPN IP in CheckPoint identity - SUCCESS" } else { log local0. "VPN ERROR : Failed to publish the VPN IP in CheckPoint Identity : $apiResp" } } } } Tested this on version: 13.0The BIG-IP Application Security Manager Part 9: Username and Session Awareness Tracking
This is the penultimate article in a 10-part series on the BIG-IP Application Security Manager (ASM). The first eight articles in this series are: What is the BIG-IP ASM? Policy Building The Importance of File Types, Parameters, and URLs Attack Signatures XML Security IP Address Intelligence and Whitelisting Geolocation Data Guard Let's say you are building an awesome web application. You want to have as many visitors as possible, but you want to keep your application safe from malicious activity. The BIG-IP ASM can help secure your application by blocking harmful behavior before it ever gets to your app, but it can also help you track down and block the bad guys if they are able to somehow find a way in. This article will focus on the different ways you can track users by session or by username. Using these tracking capabilities, you can find a bad guy, and then you can track the activity or block it altogether. Session Tracking A session begins when a user accesses the web application and it ends when a user exits the application (or when the user exceeds an established timeout length). When a user accesses a web application, the ASM generates a session ID number for that specific session. You can track a specific session by enabling "Session Awareness" on the ASM. Navigate to Security >> Application Security >> Sessions and Logins >> Session Tracking and you will see the screen shown below. Simply check the "Enabled" box for Session Awareness (and Save and Apply Policy) and the ASM will give you the option to take certain actions on any specific session you choose. So, if you are looking through your ASM event logs and notice that a particular user is doing some bad things, you can start logging all activity for that user session or you can block the session completely. I used my trusty Hack-it-yourself auction site to do some testing with this feature. I enabled Session Awareness and then accessed the auction site. Then, I reviewed the ASM event logs (Security >> Event Logs >> Application >> Requests) to see the details of the activity for my user session. Notice in the screenshot below that the Request Details show the Session ID as well as a link to Session Tracking Details (it also gives you a link to the APM session details...pretty cool). When you click on the Session Tracking Details link, you are given the option to Log All Requests, Delay Blocking, and/or Block All. I selected Log All Requests and Block All, and then I tried to log back into the auction site. Guess what? Totally got blocked...and it all got logged in the ASM event logs. So, using this blocking feature, I can easily stop a user from accessing the web application simply by blocking the user session. Now, here's a little more of my story...I accessed the auction site from my Firefox browser and, like I said before, I got blocked. I switched over to Internet Explorer and accessed the site without any problem. Makes sense, though, because I started a totally new session with the other browser. I just wanted to make sure you kept that in mind as you determine the best way to track and stop the bad guys who access your application. Username Tracking Let's talk about your awesome web app for a second. When you created said web app, you no doubt built a login page and established URLs and parameters so that users could authenticate and gain access. By adding these URLs and parameters into your security policy, the ASM can track users by username via the login URL you establish. In order to configure the appropriate login and access parameters, navigate to Security >> Application Security >> Sessions and Logins >> Login Pages List and create a new Login Pages List. In the Login URL, select either Explicit or Wildcard then select either HTTP or HTTPS based on the type of traffic the application accepts, then type in the path of the login page. Next, you can select the Authentication Type (I chose HTML Form based on the structure of the Hack-it-yourself auction site). Next, type in the parameter names for the application's Username and Password parameters (these are case sensitive). When the ASM detects these parameters used together, it knows that a login attempt is taking place. Finally, you need to configure Access Validation criteria that must be satisfied in order for the ASM to allow the user to access the authenticated URL. It's important to note that at least one of these criteria must be selected. If multiple criteria are selected, they must all be satisfied in order for the ASM to allow access to the authenticated URL. The screenshot below shows the settings for my Hack-it-yourself auction site: After the Login Page Properties are set, you can go back to the Session Tracking settings and add the Login Page to the Application Username settings (see the screenshot below). This tells the ASM to start tracking the username from the login URL you listed. The Test I accessed the auction site and logged in with my username (jwagnon) and password. See the screenshot below. Based on all the ASM settings I configured earlier, the ASM should have recognized this login and it should give me the option of tracking this specific user. Sure enough, the ASM Event Logs show the login action (notice the log entry for the Requested URL of /login.php in the screenshot below). I clicked on this specific log entry, and the request details show that the username "jwagnon" logged in to the site. Much like the session tracking options, the ASM gives the option to Log All Requests, Delay Blocking, and/or Block All activity from this specific user. I chose to Log All Requests and Block All activity from this username. Then, I attempted to log back into the auction site using the "jwagnon" username and password, and the ASM blocked the request. Remember how I switched from Firefox to Internet Explorer on the session awareness tracking and I was able to access the site because of the new session I started? Well, I tried that same thing with the username tracking but the ASM blocked it. That's because I used the same username to access the application from both browsers. I also wanted to show the actual HTTP request from this login action. I clicked on the HTTP Request tab for the /login.php event. The screenshot below shows that the request includes the parameters "username" and "password". These are the values for the username and password parameters that were identified in the Login Page Properties that we saw earlier (this is why the values for the parameters are case sensitive). The ASM recognized these two parameter values in the HTTP Request for the /login.php URL, so it gave the option for tracking the username. Session Tracking Status The last thing I'll mention about all this tracking goodness is that the ASM gives you the option of viewing all the session and/or username tracking details from one screen. Navigate to Security >> Reporting >> Applications >> Session Tracking Status to see all the details regarding the sessions and/or usernames you have taken action on. Notice in the screenshot below that the details for Block All and Log All Requests for both session and username are listed (it even shows the value of the session and username). You can click on the hyperlink "View Requests" on the right side of the page and the ASM will display all the requests that satisfy that specific criteria. Pretty cool and handy stuff! Well, I hope this article has helped in your understanding of yet another fantastic capability of the BIG-IP ASM. Here's to tracking down the bad guys and shutting down their nefarious behavior! Update: Now that the article series is complete, I wanted to share the links to each article. If I add any more in the future, I'll update this list. What is the BIG-IP ASM? Policy Building The Importance of File Types, Parameters, and URLs Attack Signatures XML Security IP Address Intelligence and Whitelisting Geolocation Data Guard Username and Session Awareness Tracking Event Logging
