Checkpoint Identity Awareness

The 3 main elements that run identity awareness under the hub are Active Directory Query (ADQ), PDP and PEP. They all intertwine in some way to allow the different blades of the Checkpoint to track and restrict access based on AD user and machine name. I tested these features as part of a POC and personally I would not consider them fit for purpose in a production environment. See the caveats at the end of the post for more details on this.

PDP - The process responsible for collecting and sharing identities
PEP - The process responsible for enforcing network access restrictions. Decisions are made according to identity data collected from the PDP
AD Query - The module responsible for acquiring identities of entities (users or computers) from 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 no existing association it asks PDP if it knows about the packet
3. If PDP does not know about it PDP asks ADLOG if there were any WMI events with this IP
4. If ADLOG has WMI events, 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 classed as 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 the firewall must verify the:

1. Identity (authentication)
2. Groups belong to (authorization)
3. System the user is currently using (IP address)
4. Permitted time period
5. Application

netstat -nop | fgrep pdp                               See if pdp is communicating with ldap
pdp monitor all                                        Lists packets 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 PDP and PEP
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! The output from this cmd is a list of user-to-ip mappings of both firewall AUTHENTICATED users and users just passing through minding their own business.

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 {}</pre>

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 and 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 device, uses MS services like mounting a file share, RDPs to a server or uses an Internet browser.

It does not see log out events so instead to track this it relies upon:

• 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.

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 be 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: AD Query in the logs are the ADQ (WMI) events
Identity Source: Captive Portal in the logs are captive portal or SSO (not WMI) events

Caveats

Windows run as
When executing tasks in Windows using Run as a new log is generated meaning ADLOG is updated, however when original user attempts another action it will still be seen as the same 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.
This is a problem for any firewalls that use this same method of parsing windows logs, the only really option to get the true user information is to install a client on the the end hosts.

XFF header
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 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 behavior 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.

• ← Previous Post
• Next Post →