LDAP : Lightweight Directory Access Protocol
During the Installation process, we created 1 administrator account and we gave that account super user access. But in production/real time we’ll be having many administrators and for that we need to create multiple user accounts and we also want to define their privileges like give any user read only view.
Now, we can store that database of users on our management server but suppose if we have 1000s of users and those already sitting in some kind of database in any 3rd party server. So, Instead of creating all those users again , we can configure and ask that 3rd party server if any given user credentials exist and are correct. And so we have LDAP for that.
Let’s say if we have a Microsoft AD server having 1000s user credentials then we can enable LDAP services on this AD server and have our Checkpoint gateway make query to the AD server with a user account preconfigured that has the ability to make those requests and by this way we can validate user accounts .
AD is not the only LDAP option we have, there are other options available also but AD is the most widely deployed/used solution for big implementations.
Other option we might use are : RADIUS (Remote Authentication Dial -IN User Service), TACACS , TACACS(+) , Secure ID
As you might be knowing , In RADIUS actual communication between client and RADIUS server is not encrypted , only password is protected however in TACACS whole communication is encrypted. In LDAP we have option to use encryption or non-encryption both but it’s always good to use encrypted communication.
LDAP Configuration :
- Enable user directory under global properties on Checkpoint
- Create a Account Unit which will bridge the communication from Gateway to AD server.
- Create LDAP Group which will link to the Account Unit.
And the communication path would be like this :
Gateway–> LDAP Group–> Account Unit–> AD Server
Now, create some Users and Administrators .
Use below snapshot and go to user and administrator –>create new administrator and perform similar step for creating users as pointed out in below snapshot. Also as we can see, we can define type of user/administrator roles here.
If we want to create many users of the same role then we can also use templates.
For now, let’s create 1 test template and create 1 user sam through test-template.
Right click on Users and then click on test-template then below page will open.
In general properties, give name – SAM-local and in authentication choose checkpoint password.
Now, if we want to put him into a group then we can create 1 group let’s say sales:
Now we can use this Sales group and push policies.
So, this is how we create local accounts in checkpoint database.Of course save the changes and if you are making any policy changes then push to the firewall.
Now, integrate Checkpoint as a client to LDAP server :
First, create a host object of the LDAP server , we named it LDAP_Server and create a user in the Microsoft 2012 AD server which we are using for AD purpose.
–Create user sam-AD in the AD user database.
Now, as mentioned earlier, Perform LDAP configuration 1st point :
- Enable user directory under global properties on Checkpoint as given below :
Now, 2nd point :
- Create a Account Unit which will bridge the communication from Gateway to AD server.
Go to Launch Menu–> Manage–> Servers and Opsec Applications
you’ll see internal certificate authority which is built into the manager. Click on new and choose LDAP Account unit from below options :
and on below window , give following details :
Name = LDAP-AU (as you wish)
Profile = Microsoft-AD (As we are using Microsoft AD server) , Domain = lab.com (my test domain)
Click on CRL (Certificate revocation List ) retrieval and below options given below :
Now, Add AD server in the list (2nd Column)
In login DN type : cn=administrator,cn=users,dc=lab,dc=com
If you want to use encryption, which we should in production then click on to use encryption in next column as seen in above snapshot. Encryption uses port 636.
Now, go to 3rd column and click on fetch branches, if it fetches your domain as we can see in below figure then it is a really great sign as the query goes from gateway to AD server and fetched out the details.
If this is unsuccessful, then need to troubleshoot your AD communication.
Now in last 4th column, choose authentication scheme and in our case it is checkpoint password , so choose that and click on ok.
And a new LDAP-AU account unit has been created to make queries to the AD server which will be reflected under users section.
Now, the 3rd part of LDAP Configuration :
- Create LDAP Group which will link to the Account Unit.
Once the group is created, now we can fetch out all the AD details as we selected whole directory in our LDAP Group.Now, to browse the entire directory of the LDAP server, go to LDAP-AU, simply double click on it and it will go out and read in all the contacts and you’ll see below tab. Double click on users and you can see our created user-Sam and administrator in it under object list as shown in below snapshots :So, here we can see our created user sam-AD, Administrator and default guest account.
Identity Awareness :
If we want to see who all are my internal users who are accessing the internet then we need identity awareness means we want to know the user’s name along with their IP address.
Also, if we want to restrict access based on AD queries/user’s names that also we can achieve through this.
So, let’s say our created user sam (in LDAP Section), wants to go out then we will not only see his source IP, Destination IP but his name as well.
For other users, who’s devices (phone/tablet) which are not registered through our AD server , we can use captive portal application (directing user from http to https captive portal page) here. Means users when trying to go out will be asked to share his identity and this session of captive portal and the user device will be encrypted. So, anybody eavesdropping will not be able to see user’s plain password. Once the user will share his details , firewall will check in its local database or it can again check in AD server query.
So, just because users are not logged into active directory, they still can be authenticated.
And for users coming from outside to our DMZ server , we can also redirect them to give some user information before allowing the access , so that we can have some basic user information.
Another option we have is a software/client/agent which is running either on a computer or on a terminal server on device like citrix who can provide the information to checkpoint like who that user is.
Here from our captive portal, we can ask users to download the agent and tell us who they are…
We don’t have to ask the user multiple times like who they are :
In case of VPN also, if they are using remote-access vpn then that user is already authenticated and we just simply allow that user in.
Three Steps to allow this features :
- Enable the feature (software blade)
- Create Access Role : Means let’s say access for inside users for which we need network address and that user should be a part of user group like ABC. And in AD environment we can be even more granular.
- Use above two things in rules.
We’ll see the implementation and rules of how this works in this series.
First enable the feature, enable it and below pop up window will open.
As already mentioned, AD Query for users already registered and Browser based authentication for captive portal. This option is for those user devices which are not associated with AD server like phone or tablet.
Now, click on next
Here, we can find our already created AD, if you want to create a new one, that is also available from drag and drop option where lab.com is mentioned.
Click on connect and it should successfully connect to the AD server.
See the below snapshot and click on next.
Here, we can see our captive portal settings. By default it is accessible on inside interface but we can make it accessible on outside or on all interfaces (Outside interface for outside users) by clicking on edit option.
Also, we can see in source side, an access role is selected (Means user part of an AD server)
and in action tab we can permit that user. Also to enable captive portal settings, edit the accept option. I’ll explain it in some time. Here we are using the outside interface IP as it is generally publically accessible for outside users.
Click on Next :
and it is explaining how it is going to find out the name with IP address .
Click on finish and it’s done.
Similarly , configure for the branch firewall.
For BR, choose :
- Only browser based authentication (NOT AD)
- Do not wish to configure AD on this
- In next tab, it will show the outside interface of the firewall for browser based authentication by default because it depends on which IP interface we have taken the management of the firewalls. Edit the option to portal accessible through all interfaces and click on finish.
- Here, on the left side we can see all identity awareness settings. If we want to change anything, we can change it from here. Also in certificate option, we can import any CA signed certificate.
Similarly we can make changes in authentication settingsWe can enable guest account and ask for certain information like this :
Authentication settings as shown in 1st snapshot out of above two and guest settings as shown in 2nd snapshot.
–Also we can ask user to use agents globally.
and we can customize our portal like this :
and for user access we can define specific user settings.
and click on ok on below settings :
Now, define the access roles :
Go to Access Roles–> Use name–HQ_Inside under networks which is used as a source and in users use LDAP Group which contains all our AD users like sam and Administrator and guests.
We can identify machines also, but as of now I am just clicking ok.
Now we are going to define the rule to use this access role. See rule no 4 and if we edit the accept action then we can enable captive port as given below and final rule will be shown like this :
Push the policy on both firewalls.
Once policy is pushed, let’s try using policy is pushed, let’s try accessing our DMZ server from our Admin_PC. Once i put 172.16.1.50 (Our HQ_DMZ server IP), it is redirecting me to the captive portal page with untrusted certificate. We’ll click on proceed.
It asks for our HQ_Server crdemtials means login is successful.
and after configuring guest settings in identity Awarness tab, if there is a guest user and if that user doesn’t have AD credential then it also opens the agent portal so that guest user can give all required details (Name/Organization/Email/Phone Number) and then it allows that uses in.
and from next time, it won’t ask for any credentials.
and the best part is, through SVT , we can see the user details as well as given in below snapshot.
And for another user trib :
HTTPS Inspection :
When a user wants to hide his data in a SSL session means original traffic is going from let’s say our user sam’s pc to actual permitted destination but inside that traffic he might be sending the data to some not permissible website or any malicious data.
Then we need more inspection on our security gateway. What we can do it to terminate the session on the firewall , decrypt the data and again encrypt from firewall to end destination.
Means firewall here is acting as man in the middle. As per end user it’s connection is terminating on end website/server but in actual this session is building from end user to firewall and then from firewall to end application.
Same holds true for traffic coming from outside to access applications hosted in our DMZ zone.
When we should do this :
We shouldn’t do when a user is going to any financial institution like personal banking. We shouldn’t sniff any data which is personal.
Similarly, we can set this up like what to inspect and what not to in any direction.
Set up this feature :
- Enable the feature https inspection on the firewall. Once we do that any Checkpoint features that can take advantages of analyzing the data like app control, URL Filtering, IPS,DLP. All these feature which can act on the data can see the data unencrypted and perform their functions.
2.manage certificates like 3rd party CA signed trusted certificates.
3.Configure Rules : When we enable the feature then rule is already applied to inspect traffic but we can define some rules for traffic which we shouldn’t inspect. eg : Financial Traffic.
Now to enable the feature, perform following steps :
Go to the firewall topology and on left side click on https inspection, once the window which will be pop up, create or import the certificate.
In our case we are creating a self signed certificate and installing that on our local pc. In an organization either we use signed certificate and need to install on all PC.
We can also export that certificate and click on enable https inspection and click on ok.
Here it is showing me warning that export the cert and install on user’s computers in my organization but for test environment we are going to ignore this.
And similarly enable the feature on the BRFW as well.
save and push the policy.
Now, where is the https inspection policy.
See the below snapshot to find out the https inspection policy and what is actually blocks.
you can see all the object list, source destination IP and destination is any here and our self signed certificate. For now, let’s remove the port 8080 and push the policy.
To block any service which we don’t want to inspect just make a rule and select services accordingly
The inspected traffic will be shown like this in SVT :
(Don’t miss the yellow sign in logs which confirms that the traffic is being inspected.)
Once you put any traffic in no-inspection zone, then light green bypass signal in logs will be reflected.
App Control and URL Filtering :
In any organization, we have acceptable used policy and every user to go through that. Means there are certain websites which are allowed and there are certain which are not and these are classified based on the site categories.
In some organization, we have policies like gaming sites are banned. And in some social media sites are allowed but games in those websites are blocked. So, Checkpoint gives us granularity upto that level. Eg : To allow facebook and blocking users to play games on facebook.
Application control on the other hand gives us a very great feature of deep inspection into the content. Firewall can take decision based on the content of the data.
This feature helps us to protect against any malware producing sites or certain kind of websites producing malwares.
To stop the bandwidth abuse : we can limit the cap on any streaming media applications, or we can limit the throughput.
Blocking non-approved sites.
Steps to implement App control & URL filtering feature :
- Enable the feature on the firewall
2.Add rules and push policy.
Once the feature is enabled. Go to App control and URL filtering tab and check if this is enabled on the gateways you mentioned.
Now go to policy to add any specific web URL rules.
And this is the default rule allowed in the policy :
Let’s allow facebook rule in this policy.
And let’s block some pages like gambling sites, pornography.
And we can edit the block message as well and see what message it will pop up when the traffic hit this rule :
So, the sites which are blocked in the URL filtering , above message will be popped up to the users.
To rate Limit the traffic on to particular websites :
Let’s an example we want to put rate limit on websites like you tube (Streaming websites):
First, create a rule for this :
save and push the policy and now if we browse you tube videos then it will only allow maximum throughput limit of 512 kbps.
By this way , we can create our custom category of sites which can be allowed or blocked as per company policies.
Also to see the hit count on any policy , we can refresh or see as per our comfort like to see count in percentage. See this :
As per above snapshot, go to global properties and there we can mention for how much time we want the hit count to be present and after the mentioned time, hit count will be reset.
Or we can go to individual firewall and check/uncheck the hit count option.
- Checkpoint – Checkpoint Fundamentals and first time configuration Wizard – Part I
- Checkpoint – Pushing Policy, NAT , Policy Packages and database Versions – Part II
- Checkpoint – SMART View Tracker and SMART View monitor – Part III
- Checkpoint – LDAP, identity Awareness, HTTPS inspection, App control and URL Filtering – Part IV
- Checkpoint – Command line Interface and IPSEC VPN – Part V
- Checkpoint – SMART Update, Remote Access VPN and High Availability – Part VI