To keep your business online and ensure critical devices, such as Check Point firewalls, meet operational excellence standards it is helpful to compare your environment to a third party data set. As part of the Indeni Automation Platform, customers have access to Indeni Insight which benchmarks adoption of the Check Point capabilities and user behavior to adhere to ITIL best practices.

GAIA WebUI and SSH introduction

When you login to a Check Point firewall or device over either web or SSH, you are authenticated in the same way. The different authentication methods are

1.    Local user account
2.    External authentication server for a local account
3.    External authentication for a non-local account

Adding a local user in GAIA  – Using WebUI

[divider width=”full”]

This is the simplest way and often the easiest method of adding a user and authenticating. Begin by logging into the WebUI. The standard is HTTPS over port 443

Go to User Management > Users and click “Add” to set up a new user:

In the next window you can select options for the user.

Login Name: This is the username used when logging in
Password: Password
Real name: To identify users easier
Home directory: Home directory, this will be /home/<USERNAME> as default
Shell: This is the standard shell when you login. Default shell is clish. If you change it to /bin/bash remember that the user will be able to run commands with root privileges if he has UID = 0
UID:  The default is 0, which means that you will have the same permissions as root if you get into the /bin/bash shell. However in order to get into that shell you must either have that set as your standard shell, or know the expert password.

You can also select if the user can login to either Web or SSH or both, as well as assign one or more Roles. The Roles determine what permissions you have to run commands and modify configuration.

Adding a local user in GAIA  – Using clish

[divider width=”full”]

clish is the default shell when connecting to the Check Point device over SSH. clish works in a very similar way as when modifying configurations in a switch or router.

Adding user

# add user <USERNAME> uid <UID> homedir <HOME_DIRECTORY> # set user <USERNAME> password # add rba user <USERNAME> roles <ROLE> # save config

Deleting user

# delete user <USERNAME>

So using local users is easy, but let’s see what the pros and cons are :

Advantage:            Easy to setup
Disadvantages:     Static passwords on each device means a lot of work to change them all if you have many devices
There is no password expiration set as default
If a user quits it’s a lot of work to find everywhere where the user has accounts and delete them
If a new user joins the team it’s a hassle to create accounts for him on all devices

These disadvantages often lead to teams managing the devices to use the admin account for everything, and share the password, since it is easier. This is of course bad for several reasons.
Sharing the account means that you cannot determine who did what from the logs. A shared password is more work to change, as everyone needs to be informed, and often means that it will be changed less frequently, if at all.
According to PCI-DSS 8.5.8 it is stated:
8.5.8 Do not use group, shared, or generic accounts and passwords, or other authentication methods.

Password policy for local accounts

Here you can setup the password policy for local users

Roles

Roles are permissions sets that you can assign to a user.
You configure it here:

Each Role has two types of permissions.
Commands = Commands that can be executed in CLI
Features = Part of the configuration. If a user does not have the NTP feature then the user will not see the NTP part in WebUI and cannot change it in CLI either.

There are three pre-defined Roles, adminRole, cloningAdminRole and monitorRole with different permission sets.

Authentication servers

[divider width=”full”]

Configure if you want to use an external authentication server, either for non-local users, or local users who authenticate remotely

RADIUS

RADIUS Servers: Here you can define your RADIUS servers, which IP, port and timeout as well as shared secret.
Network Access Server (NAS):  The IP that should be recorded in the RADIUS Access Request as the IP of the gateway. If nothing is selected here it will use the source IP address of the packet.
Sometimes when packets go via NAT the source IP of the packet can change. Then it can be good to have the true source IP recorded inside the RADIUS Access Request.
RADIUS Users Default Shell: This is the default shell for non-local users.
Super User UID: This is the UID for non-local users when entering expert mode. This should be 0 in most cases.  The only other option is 96, which is the UID of the “_nonlocl” built in user. If 96 is selected the user will not be able to run any commands from expert.
If you are unable to select 0, then check sk98958 or sk97206.

[divider width=”full”]

TACACS+

For TACACS+ the settings are the same. You need to set a priority, server IP, shared key and timeout.
Don’t forget to change the User UID to 0 if you want to be able to use expert mode properly.
Also different from RADIUS is that you need to enable TACACS+ with the checknox “Enable TACACS+ authentication”

Adding a local user that will authenticate to an external authentication server

[divider width=”full”]

Add a local user as described earlier in this guide. Remember that the password you set on the user will still work even when using external authentication. So if someone would input the local password it would fail the external authentication, but still be allowed in on the local password.
We could set the local user to some random password, or we could unset it completely.
To set a blank password, login via cli and do

# dbset passwd:<username>:passwd "*" && dbset save

This will set the password hash to a * and nothing can be hashed to only *.
After adding a user, and setting the password to random or nothing at all, we need to configure which remote authentication server we will use.

In this example I will show how to do this from the WebUI, but it can also be done from clish.

1.    Open the WebUI and go to User management -> Authentication Servers
Here we can add either a RADIUS or a TACACS+ authentication server.
In this example we will add RADIUS servers.

2.    Click “Add”
Chose the Priority (the first host should have 0, the next one 1 etc)
Input the IP address in the Host field.
Select UDP port or accept the standard 1812
Input the shared secret that the authentication server will use.
You can increase the timeout if you are working on a slow connection.
You should have at least two external authentication servers for redundancy.
The Check Point device will try the one with the lowest priority, wait for the timeout, and then try the next.

3.    Choose whether or not you need to change the “Network access Server (NAS)” as described earlier in this guide.
Make sure that the default shell is as you want it to be, as well as keeping the Super User UID to 0.

4.    Click Apply

5.    Add the user on your external authentication server and make sure the firewall is open.
You need to open port 1812 from the Check Point device towards the RADIUS Servers.
Remember that the RADIUS Authentication request could be NATed behind the cluster IP of the Check Point Gateway.
This means that in your RADIUS server you need to put in the Cluster IP.
It also means that if one of the nodes in a cluster is down, it will not sync with the active one, and as such RADIUS will not work.
If the “down” node sends an Authentication request to the RADIUS server, which is NATed behind the cluster IP, the reply packet will be send to the active node.
Since the node who sent the request is down, the connection would not have been synced to the active node, and the active node will drop the packet with reason “no such connection”
The solution is not to hide NAT RADIUS requests, which I will explain below

6.    If you are going to use RADIUS over VPN you need to read sk31692 because RADIUS packets are in the implied rules, as such they are excluded from all VPN tunnels per default. The SK describes how to edit the implied rules file on the management server to solve this.

7.    Now you should be able to authenticate.
Troubleshooting can be done via packet capture and view the packets in tcpdump, and also check /var/log/messages

Advantage:       This method is good because you can now control users from a central place. This means that you only need to change your
password in one place, and if a user quits you can remove his account in the central authentication server.
Disadvantage:  Even if you remove the user from the central authentication server the user will still be in the user list. Also, if a new user joins
your team, you need to add this user to all devices.

That brings us to the next solution, using non-local users

Adding a non-local user that will authenticate with an external authentication server

[divider width=”full”]

Check Point also has support for something called non-local users. This means that no local user is added on the device, so the user list will only who the default users.

For this method we not only have to authenticate the user, we also need to tell the device what permissions he needs. To be able to do this in a simple way we will assign the user to a Role. You can use the built in Roles, or create new ones.

In order for the RADIUS server to send not only the OK or Not OK, but also which groups the user belongs to we will need to use something called VSA (Vendor Specific Attributes)

This is the standard way of letting the RADIUS server include additional attributes to return to the Check Point device along with the authentication reply.

Go to sk72940 to get information on how to put the dictionary needed onto the RADIUS server.
You then need to configure the RADIUS server to send these attributes when a user authenticates.
The procedure is different depending on RADIUS server, but for RSA Authentication Manager 8 it looks like this:

So here the adminRole was selected.
We have also selected the user to be allowed to go into expert mode with UID 0, which is root permissions.
If you do not have SuperUser access set to 1, you will be user “_nonlocl” when going into expert, and that means you will not be able to run most commands.

Now you should be able to login with a user that is not in the Users list at the Check Point device.

Authentication for SmartDashboard

[divider width=”full”]

For SmartDashboard we have a few other authentication methods.

To choose one for a user, go to “Users and Administrators -> Administrators” and double click a user

Here you can select
Undefined = No authentication mode set. User cannot login
SecurID = Proprietary login method from the company RSA
Check Point Password = A static password set in this window
OS Password = The same password as a WebUI/SSH user with the same username
RADIUS = Authenticating via RADIUS
TACACS = Authenticating via TACACS

RADIUS authentication for SmartDashboard

[divider width=”full”]

When doing RADIUS authentication for SmartDashboard we cannot use non-local users, so we need to create each user manually.

First let’s define our RADIUS servers.

1.    Open SmartDashboard
2.   Create a host object for all RADIUS servers
3.   Go to “Servers and OPSEC”

4.    Right click on “RADIUS” and select “New RADIUS..”
5.    Fill in the information
Select a name
Select the host object you created earlier
Change the Service to NEW-RADIUS
Input the shared secret
Do the same for all RADIUS servers.

6.    Now right click “RADIUS Group” and select “New RADIUS Group..”

7.    Put in all RADIUS servers in here and click OK

Now we can enable RADIUS authentication on a user.

1.    Open up a user as described earlier in this guide
2.    Go to “Authentication” and select “RADIUS”
3.    Where it says “Select a RADIUS Server or Group of Server” select the RADIUS group you created earlier
4.    Press OK on the window and next let’s install database
5.    Go to File -> Policy -> Install database

Now it should work to login using RADIUS for SmartDashboard

Some additional settings can be found at ‘SmartDashboard > Global Properties > SmartDashboard Customization > Configure > FireWall-1 > Authentication > RADIUS’

For example timeout.
radius_user_timeout Timeout interval for the user to respond to a RADIUS challenge (in seconds)
radius_retrant_num Maximum number of connection attempts to the RADIUS server
radius_send_framed  Send the framed host (source IP of the connection) to the RADIUS server
radius_connect_timeout Timeout interval until next attempt to connect to the RADIUS server (in seconds)
radius_retrant_timeout Timeout interval for each RADIUS server connection attempt (in seconds)
radius_ignore  When handling RADIUS authentication, FireWall-1 verifies that the RADIUS attributes are RFC compliant. If your system uses non-standard RADIUS attributes, you can force FireWall-1 to ignore these attributes

TACACS+ authentication for SmartDashboard

[divider width=”full”]

First we need to define the TACACS+ servers.
1.    Open SmartDashboard
2.    Create a host object for each of the TACACS+ servers
3.    Go to “Servers and OPSEC”
4.    Right click the “Servers” folder and select New -> TACAS..

5.    Fill in the information
Name:
Comment(optional):
Host: Select the host object
Type: Select TACACS+
Secret key: Put in the pre shared key
Service:  Already filled in as TACACS

Now we can enable TACACS+ authentication on a user

1.    Open up a user as described earlier in this guide.
2.    Go to “Authentication” and select “TACACS”
3.    Where it says “Select a TACACS Server” select the TACACS server you created earlier.
4.    Press OK on the window and next let’s install database.
5.    Go to File -> Policy -> Install database.

Common issues and solutions

[divider width=”full”]

To stop RADIUS requests to being hide NATed behind the cluster IP:
1.    Find the table.def file (sk98339)
In most cases found here: $FWDIR/lib/table.def
2.   Edit the file and find the line that says:
no_hide_services_ports =
Example syntax
no_hide_services_ports = { <4500,17>, <500, 17>, <259, 17>, <1701, 17>, <5500, 17>, <68,17>, <67,17>};
each entry has portnr, then number 17 for UDP or number 6 for TCP
3.    Add (without quotes) “, <1812,17>” to the end of the line, before the finishing “};”
4.    Push policy to all gateway clusters.

To allow radius passwords with more than 16 characters – see this link sk13740
It explains that if you need to have more than 16 characters in the passwords for RADIUS you can change the protocol on the RADIUS object from the standard “RADIUS ver 1.0 Compatible” to “RADIUS ver 2.0 Compatible”

We have hundreds of automation elements to prevent problems from occurring in your environment. Check out our top picks for Check Point firewalls automation.

Johnathan Browall Nordström is the Team Lead of Network & Security at Betsson Group. He has been working with Check Point firewalls for more than four years. If you want to contribute as well, click here.

[divider width=”full”]

Request a demo of Indeni for Check Point.