Checkpoint Identity Awareness

Unfortunately this blog has passed away (don’t worry it was peaceful), but just like Jesus we have a resurrection, go take a peak at the future https://theworldsgonemad.net/2018/checkpoint-identity-awareness/

The 3 main elements that run identity awareness under the hub are Active Directory Query (ADQ), PDP and PEP. The all intertwine to allow the different blades of the checkpoint to track and restrict access based on AD user and machine name.

PDP – The process on the Security Gateway responsible for collecting and sharing identities.
PEP – The process on the Security Gateway responsible for enforcing network access restrictions. Decisions are made according to identity data collected from the PDP.
AD Query – Is the module responsible for acquiring identities of entities (users or computers) from the Active Directory (AD).

PDP and PEP

PDP uses PEP and ADLOG to gather security information about a person/system and stores it in the PDP database.

1. PEP inspects packets looking at the IP address and checks in its own internal table to see if there was an existing association.
2. If not it asks PDP if it knows about the packet.
3. If not, then PDP asks ADLOG if there were any WMI events with this IP.
4. If ADLOG has WMI events, the PDP asks the LDAP server if it has any more information about the user.
5. If the user exists in AD, then this USER/IP/MACHINE are somewhat trusted under your AD environment.

If based on the source IP address the firewall is able to identity (not necessarily authenticate) a user associated with this address, the firewall will put the user into the PDP user table. At a minimum this association will be used to tag each log entry with the username.

Before a user is allowed to pass through firewall must:
1. Identity
2. Verify identity (authentication)
3. Groups belong to (authorization)
4. System user is currently using (IP address)
5. Permitted time period
4. Application

netstat -nop | fgrep pdp   See if pdp is communicating with ldap
pdp monitor all      Lists pkts the fw has attempted to identify
pdp monitor ip [ip]
pdp monitor user [name]
pdp monitor groups [name]

pdp connections pep      Conn status of all PEPs that should be updated by PDP
pdp control sync         Force an initiated synchronization operation between the PDPs and the PEPs. At the end the PDP and the PEPs will contain the same info
pdp control revoke_ip [ip]     Remove a single IP mapping

There is no easy way to remove ALL user to IP address mappings. Need to use bash one-liner!
pep show user all | egrep -o ‘[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}’ | grep -v ‘127.0.0.1’ | xargs -i -p pdp revoke_ip {} 

The outputs from the above cmds show a list of user-to-ip mappings of both firewall AUTHENICATED users and users just passing through minding their own business.
PDP will show all the users associated, be it Kerberos or ADquery.
When the reauth time times out it will be removed from PDP table.

>[Expert@ckp-gw1:0]# pdp monitor all
 Session:  83531e33
 Session UUID:  {3B8C8AA4-1FE2-1BD3-A65F-0A831E183F23}
 Ip:  10.10.10.195
 Users:
 bob@STESWORLD.COM {dee7a1c9}
  Groups: ad_user_bob;All Users;ad_group_InternalUsers
 Roles: Bob;Vcef3d17b-8fd8-4bab-bfc1-41084f244002
 Client Type: portal
 Authentication Method: Kerberos
 Connect Time: Wed May 10 21:16:28 2017
 Next Reauthentication: Wed May 10 21:21:28 2017
 Next Connectivity Check: Wed May 10 21:21:28 2017

–IP: The computer the user is connected to
-Groups: AD groups relevant to fw access (not all groups)
-Roles: The smartdashboard access role
-Auth method: Type can be Kerberos, AD query, username password (portal)
-Next Reauthentication: When user will next need to reauth.

PEP is responsible for enforcement of the rulebase which allows/ permits AD users and AD machines (not IP addresses) through a firewall. So just like PDP, PEP keeps a table/ cache of IP/ Users that it has seen pass through the firewall.

pep show pdp all               Number of users
pep show user all              Names of users & IP

Active Directory Query (ADQ) and SSO (Kerberos)

Keeps track of users by reading the Active Directory Event logs. Therefore it will see if a user logins into a laptop, uses MS services like mounting a file share, RDPs to a server or uses an Internet browser.

It does not see log out events, to track this it relies on:
-The user / IP association (default 720mins)
-Assume that only 1 user is connected per comp (disabled by default)

The 4 AD events tracked by ADQ are:
4624: Local login
4768: Kerberos ticket was requested from DC. This identifies the user/machine in Kerberos
4769: Kerberos Service Ticket was requested: User/machine requires access to resource like file system mapping or web server
4770: Kerberos Service was renewed: Kerberos will auto renew service ticket if user still logged in

ADLOG is like an external cache of WMI events for AD. Because an IP is in this cache doesn’t mean the firewall cares or uses the IP addresses.  With no Access roles configured within checkpoint this will be just a list of users, machines and the associations.

The cache is there so that PDP and PEP can refer to the IP list in the future when needed.
In a HA gateway setup the ADLOG tables are not replicated to the standby member, however the PDP/PEP tables are.

“Identity Source: AD Query” in checkpoint logs is the ADQ (WMI events)

adlog a dc
adlog a query all | more
adlog a service_accounts      Suspected to be "service accounts" based on number of logins 
adlogconfig

You don’t NEED ADQ enabled if you plan on using Captive Portal or SSO to authenticate users. However, the logs might be somewhat barren of user-to-IP address mappings without it.

If ADQ and SSO are both enabled, ADQ is only one that is updated in PDP table and used by Identity awareness. Therefore if using them both, SSO Identity awareness will only used (added to pdp database) when it is a non-corporate machine (not in AD).

With SSO when a user logs out and a different user logs in on the same computer (IP) the PEP or PDP table are not updated until the old users PDP entry times out. The default for this timer is 720 minutes but can be reduced to 5 minutes. As soon as this expires the new user is added to the PDP database.

“Identity Source: Captive Portal” in logs are captive portal or SSO (not WMI)

Caveats

 “Run as” will generate a new log so update the ADLOG, however when original user attempts another action it will still be seen as the “run as” user until an action is done to generate a new AD event (for example lock screen). With SSO it doesn’t even register the “run as” as a new user.

If you need to use a proxy or load balancer that hides the true source IP you can add the XFF header and Identity Awareness will recognise this. However the checkpoint can only identify IPs from the XFF header, if you all add anything else such as usernames the checkpoint will ignore these.

XFF only works for HTTP traffic, with HTTPS traffic even if you are using HTTPS inspection on the checkpoint so it can decrypt the packet, the checkpoint cant read the XFF header. I feel this is a major flaw, I had cases open with checkpoint about this and in the end they said it is expected behaviour and the only thing I could do is put in a feature request. The XFF header is there, the checkpoint is already decrypting the packet, so why not allow it to read it. With the amount of sites now being HTTPS think is very shortsighted by checkpoint.