Using Check Point NGX R65, you can control the traffic coming into or going out of your networks. However, sometimes you will need or want to authenticate specific users that are accessing your resources. For example, an administrator might have to download privileged files from a restricted user’s workstation, and would need special privileges for a short amount of time. With authentication, Check Point NGX’s features are greatly expanded and complement already strong security with the ability to implement security on a per-user basis. Once you understand how NGX authentication works, you will probably find many uses for it in your environment.
Check Point NGX works based on the information it has to permit or deny a connection. To authenticate a particular user, the firewall needs additional information to match the user and a connection. The main topic of this chapter addresses the best way to authenticate users so that they can access privileged resources. Check Point Software has made few changes to the way authentication works since it released the NGX R60.
We will first address the issue of which users can authenticate. Check Point NGX is flexible enough to authenticate users created in various sources, databases, or external directory servers. We will then examine the different types of authentication that NGX allows, which are called user, session, and client authentication. We will also touch on SmartDirectory, Check Point’s Lightweight Directory Access Protocol (LDAP) implementation.
Using authentication involves additional configuration of the firewall and planning an environment that allows users to access the resources they need. Some of the environments that can benefit from authentication include:
Using Dynamic Host Configuration Protocol (DHCP) without Internet Protocol (IP) reservations, while needing to give a few users access to special resources
A support technician downloading drivers and antivirus programs on restricted machines
Implementing an additional security layer on an extranet site
Think of a user as an entity: Bob, Peter, and so on. To recognize (or authenticate) him or herself, the user needs either to know something (a password) or to have something (a token or digital certificate). This chapter focuses on passwords. Most companies already have some sort of user database (Microsoft Active Directory, a Remote Authentication Dial-in User Service [RADIUS] server, etc.), and would like to integrate this database with their firewall, through the use of an Authentication Scheme.
Before you can authenticate users, you need to define them, of course. Check Point NGX is very flexible in this sense. You can use NGX’s built-in user database, as well as external user directories, including LDAP through Check Point SmartDirectory.
There are two ways you can access and edit the user database. You can access the Manage Users and Administrators dialog from the Manage | Users and Administrators menu (see Figure 4.1), or you can use the Object Tree (as in Figure 4.2). Both include a listing of all user-related objects: users, groups, templates, administrators, external user groups, LDAP, and so on. Each entity type is represented by a different icon: Administrators have crowns over them, groups are represented by two users, templates are outlines, and external users have a circle around them.
In the Users tab within the Object Tree, you can right-click on any entity class to add new objects.
The first item you will see in the Manage Users and Administrators dialog box will be a yellow icon named cpconfig_administrators, which represents the administrator configured through the SecurePlatform Web interface or the cpconfig utility on a SmartCenter.
Before you create an administrator, you need to create a Permissions Profile. Go to the Manage | Permissions Profiles dialog and select New | Permissions Profiles, as in Figure 4.3.
In the General tab, you can name the profile, select a color, and enter a comment. In the Permissions tab, you can select among the following:
Allow access via:
SmartPortal and Console Applications Administrators can access both the GUI and the Web interface.
SmartPortal only Administrators can access only the SmartPortal Web interface.
Permissions:
None. Disables an administrator’s permissions.
Read/Write All. Allows full access to all NGX management applications.
Manage Administrators. Allows you to change other administrators’ accounts and profiles.
Read-Only All. Grants access to all configurations, but administrators cannot change anything.
Customized. Allows you to create a personalized profile for administrators with specific functions. The permissions for each option can be Disabled, or Enabled with Read Only and Read/Write. The specific functions you can select are:
SmartUpdate. Using SmartUpdate for managing product updates and assigning licenses
Objects Database. Working with the network objects (services, resources, and servers)
Check Point Users Database. Working with the internal user database
LDAP Users Database. Managing an external LDAP database through SmartDirectory
Security Policy. Working with the security and network address translator (NAT) rules and installing a policy
QoS Policy. Working with the QoS rules and installing a policy
Log Consolidator. Working with Eventia Reporter’s Consolidation Policy
Eventia Reporter. Working with the Eventia Reporter tables and generating reports
Monitoring. Accessing the SmartView Monitor database for statuses
UserAuthority Web Access. Working with the UserAuthority Web Access product
ROBO Gateways Database. Working with the SmartLSM (Large Scale Manager)
Eventia Analyzer Events. Working with the Eventia Analyzer Events database
Eventia Analyzer Policy. Working with the Eventia Analyzer database
Track Logs. Accessing the Traffic Log and Active sessions in the SmartView Tracker
Audit Logs. Accessing the Active sessions and Audit Logs in the SmartView Tracker
Integrity Server. Managing the Integrity Server (see Figure 4.4)
The administrators are the users that have access to the configuration of the firewall. Depending on the Permissions Profile assigned to the administrators, they may or may not have permission to read and write to different parts of the security policy. Once you create or edit an administrator, you’ll see the tabs outlined in the following sections.
In the General tab of the Administrator Properties dialog, you can give a name to the administrator and select a previously created Permissions Profile. You can also click on New and directly create a new profile. View Permissions Profile allows you to view and edit existing profiles (see Figure 4.5).
You will find a Personal tab for both administrators and users. You use the Expiration Date field (in dd-mmm-yyyy format) to set a valid period for an administrator. By default in NGX, the expiration date is 31 December 2030.
You can select which administrator groups this administrator belongs to. You can Add and Remove administrators from the Available Groups and the Belongs to Groups boxes. Admin Groups are used in the Permission to Install field in Check Point objects.
Here you can select what Authentication Scheme will be used for administrators—basically, what to check the password against. The options are Undefined, SecurID, Check Point Password, OS Password, RADIUS, and TACACS. If you select Undefined, the administrator will only be able to authenticate using a digital certificate.
One of the advantages of using SmartDashboard Administrators is that you can implement authentication via digital certificates generated by the Internal Certificate Authority (ICA). If there is no certificate for the administrator, you can click on Generate and Save. Enter and verify the certificate’s password, and save the certificate file. Once you generate the certificate, you can revoke it from this tab.
You can create Administrator Groups and place administrators in them. You can use Administrator Groups by editing a Check Point gateway, using the Advanced | Permissions to Install tab. Here you can specify Administrator Groups to which you want to grant install access. Only administrators with Manage Administrators permission can modify these properties.
Before you create users, you have to understand templates. There are many options to configure for users, and templates save you time by preconfiguring options at the time of user creation. Let’s look at the different tabs you see once you select New | Template.
Select the Name the template will have, which you will use when selecting New | User from Template.
You use the Expiration Date field (in dd-mmm-yyyy format) to set a valid time period for users. By default in NGX R65, the expiration date is 31 December 2030. Enter a Comment for the template and select a Color for the display of its icon. These fields are for informational use only.
Here you can select what Authentication Scheme will be used for these users. The options are Undefined, SecurID, Check Point Password, OS Password, RADIUS, and TACACS. If you select Undefined, the user will not be able to authenticate using a password, only a digital certificate (for virtual private networks [VPNs] only).
Location refers to the users’ allowed sources and destinations. You will be able to select Network Objects and move them to either the Source or Destination box, or leave them as Any. The location then becomes a restriction as to where the users can connect from and connect to. When you configure an authentication rule, you can decide whether the rule has to intersect with the location of the users, or whether it can ignore it.
You can select what day of the week and range of time the User may connect at. Although you can select more than one Day in week, you are limited to a single range for Time of day.
You can create user groups and place users in them. You can select a Name, Comment, and Color for the group, and Add and Remove them from the Not in Group box to the In Group box, as in Figure 4.6.
User groups can also contain other groups in a nested fashion. When you add a group to another group, NGX will ask Would you like to add each member of the group separately? and each group will be expanded in the new group. With nested groups, if you change a group the change will be reflected in the parent group, but that will not happen if you expand the group.
Check Point NGX does not reference individual users directly in rules or object properties, so if you have a user, you should place him or her in a group. If a user is not in a group, the user is still part of the All Users group.
When you want to create a user you have to work based on an existing template. Once you select New | User from Template as in Figure 4.7, you can select the initial template you want and then you will see a dialog box with many tabs. Let’s look at them.
Select the Login Name for the user. The name can have special characters in it, as well as spaces and long names.
The Expiration Date field (in dd-mmm-yyyy format) is used to set a valid time period for a user. By default, in NGX R65 the expiration date is 31 December 2030. Enter a Comment and select a Color for the display of its icon. These fields will be prepopulated with information from the template.
You can select which user groups the user belongs to. You can Add and Remove them from the Available Groups and the Belongs to Groups boxes. The tab will be prepopulated according to the template.
Here you can select which Authentication Scheme the user will have. The options are Undefined, SecurID, Check Point Password, OS Password, RADIUS, and TACACS. If you select Check Point Password, you can click Enter Password to assign and verify it. The passwords should be four to eight characters in length. If you select RADIUS or TACACS, you can select which server to use for verification.
Here you can select specific Source and Destination locations for the users. The fields will be prepopulated from the template. Remember that when you configure an authentication rule, you can decide whether the rule has to intersect with the location of the users, or whether it can ignore it.
You can select what day of the week and range of time User may connect at. Although you can select more than one Day in week, you are limited to a single range for Time of day. It will be prepopulated from the template.
In this tab, you will see the Certificate State (There is no certificate for this object, or Object has a certificate), and the Distinguished Name if it has a certificate. Digital certificates for users apply only for Remote Access VPNs.
If you’re working with external directory servers (RADIUS, TACACS, OS Password, or SecurID) you can create an External User Profile. If users are recognized by an external directory server they will be granted permissions based on the appropriate External User Profile. Still, using OS Password usually is not a good option due to the complexity of managing passwords in the OS on which the Security Gateway is installed.
This profile allows you to selectively query an external user database based on the domain the user enters. The important properties are in the General tab. If you use Distinguished Name (DN) format, you can select a specific organizational unit, organization, or country to authorize. Alternatively, you can use Free Format, in which case the domain will be separated from the username by a character such as @ or (for Microsoft), either before or after the username. In Free Format, you can choose Any Domain is Acceptable, or a specific Domain Name. See Figure 4.8 for details.
The other tabs in the External User Profile (Personal, Groups, Authentication, Location, Time, and Encryption) function like they do in the normal user entity. Remember that in this scenario, you’re leaving authentication and authorization decisions to an external entity.
If you don’t need to be selective regarding the domain with which users must log in, you can use the Match All Users External Profile. It is named generic* and will match any user recognized by the external directory server. Remember that in this scenario, you’re leaving authentication and authorization decisions to an external entity.
We will look at LDAP Groups in the upcoming “SmartDirectory” section.
Check Point NGX is flexible enough to work with several external directory servers, in which a user entity can be defined in the Internal Check Point database, but the password is verified from different sources. Check Point refers to these as Authentication Schemes.
You use the Undefined Authentication Scheme to disable the user’s ability to enter a password. This will force users to employ strong authentication with a digital certificate.
Selecting SecurID as the Authentication Scheme will enable Check Point NGX to become an ACE/Agent for RSA’s SecurID tokens. This integration will require use of a special sdconf.rec generated by the ACE server, and will allow you to enter new PINs and reauthenticate often to secure servers. However, it’s a lot more difficult to configure than through SecurID’s RADIUS interface.
If you select Check Point Password (previously called VPN-1 & Firewall-1 Password), you will enter the user’s password directly into NGX’s internal database. Passwords can be four to eight characters in length. Be aware that the only way to assign or change passwords is through the SmartDashboard interface.
RADIUS is a standard protocol that can authenticate users with a RADIUS server that holds a database. The RADIUS protocol is very flexible and relatively secure. It uses a specific secret key to secure the authentication and only authorized clients can request authentication from the server. You can also set up backup servers in case one of them is out of service.
To configure RADIUS authentication, first create a RADIUS server from the Manage | Servers and OPSEC Applications dialog, as in Figure 4.9. Select New | RADIUS to create the server. Input the appropriate data in the Name, Comment, and Color fields, as in Figure 4.10. For Host, select the physical server that is running the RADIUS server. If you don’t have the server created, use the New button to create a new node. Select the Service to use, either NEW-RADIUS (the official port number) or RADIUS (the most common port number used). The Shared Secret is a password used to secure the information sent between the Check Point Gateways and the RADIUS server(s). You can select the Version to use, either Version 1.0 or Version 2.0. Also select a Priority, to know which server to use first if more than one is available. You can also create RADIUS groups for high availability and load sharing.
The Terminal Access Controller Access Control System is a standard protocol that can authenticate users with an external user database. To configure TACACS authentication, first create a TACACS server from the Manage | Servers and OPSEC Applications dialog. Select New | TACACS and input the appropriate data in the Name, Comment, and Color fields, as in Figure 4.11. For Host, select the physical server that is running the TACACS server. If you don’t have the server created, use the New button to create a new node. Select the Type of the server used, either TACACS, or TACACS+ which is more secure. If you select TACACS+ you can also enter a Secret Key for encryption. Finally, select the Service to use (UDP TACACS or TCP TACACSPLUS).
Most enterprises already have an existing user database that they want to integrate with their security infrastructure. LDAP is an open industry standard for directory access, supported by many vendors and applications including Microsoft Active Directory, Novell, Netscape, and others. Check Point’s LDAP implementation is called SmartDirectory. It requires a separate license, but it’s included in SmartCenter Pro and UTM-1 appliances. You can use SmartDirectory for user authentication and for certificate revocation list (CRL) retrieval.
LDAP elements include the LDAP servers, which hold the directory information; the LDAP tree, which is the hierarchy of the directory; and the LDAP schema, which is a description of the data within the directory. The LDAP tree is a strict hierarchy that can include countries, organizations, organizational units, groups, and common names. Each entity in the LDAP tree has a DN containing the entire path under which the entity exists. When dealing with the schema, take into consideration that standard LDAP servers will not have some of the information that Check Point requires for its users (e.g., VPN-related data, location data, etc.). There are two methods to overcome this limitation: extending the Active Directory schema, and applying a user template to LDAP users.
You can extend the LDAP schema to include the Check Point schema, although you should not undertake this lightly. Because it implies modifying the underlying schema of a production LDAP server, you should make a complete backup of the server prior to modifying the schema. You can find detailed instructions in the Check Point SmartCenter Administration Guide, under SmartDirectory (LDAP) Reference Information.
The first step in configuring SmartDirectory is to enable it from the Global Properties. From Policy | Global Properties | SmartDirectory (LDAP), select Use SmartDirectory (LDAP), as in Figure 4.12.
The settings you can configure here include:
Timeout on cached users. How long the cached users (i.e., the users’ credentials after a successful authentication is made) are stored.
Cache size. How many user credentials to store in memory.
Password expires after. How long the user’s password is valid. Older passwords won’t be accepted.
Display User’s DN at Login. Selects whether to display the DN once authenticated.
Password Strength. Selects the password length, and whether to require lowercase, uppercase, digits, and symbols.
Enforce rules for user management administrators. Applies the password strength rules for LDAP administrators.
Check Point creates Account Units to connect the LDAP servers with Check Point VPN-1. The Account Unit holds servers that have the connection information to the LDAP servers. Create an Account Unit from Manage | Servers and OPSEC Applications | New | LDAP Account Unit, as in Figure 4.13.
You should enter a Name, Comment, and Color, as well as making sure User management is selected. If that option is disabled, the SmartDirectory option in Global Properties has not been enabled. For Profile, the selection includes Microsoft_AD (Microsoft Active Directory), Netscape_DS (Netscape Directory Services), Novell_DS (Novell Directory Services), and OPSEC_DS (for OPSEC-certified LDAP servers). The profiles provide basic compatibility with the designated LDAP standard.
You need to configure the Servers tab with the list of LDAP servers that hold the Account Unit’s information, as in Figure 4.14. You can use multiple servers for resiliency, and you need to select one of the servers for Pre-NG FP3 compatibility.
Click on Add to include an LDAP server for the Account Unit, as in Figure 4.15.
For Host, select an existing object or create a new object where the LDAP server is running. The default LDAP Port is 389; enter the Login DN (the DN that will be used to read and write from the LDAP server). For Microsoft Active Directory, the DN follows the format cn=<username>, cn=groups, dc=<domainsection1>, dc=<domainsection2>. For user LDAPAdmin in domain training.com, the DN would be cn=LDAPAdmin, cn=groups,dc=training,dc=com. Lastly, select whether the Check Point Gateways are allowed to read and/or write data on the server. You would need write permission to lock out a user after failed attempts.
For information as sensitive as user authentication, it is important to enable encryption in the Encryption tab, as in Figure 4.16. Enabling encryption activates port 636, the default LDAP encryption port. You must fetch the Fingerprint by pressing the Fetch button. For it to work in a Microsoft environment, the domain controller must have Certificate Services installed. Then select the minimum and maximum encryption strengths. Select OK to save the server configuration.
In the Objects Management tab, the LDAP branches can be fetched, which will be the first verification that the LDAP server is communicating with the SmartCenter (see Figure 4.17).
Lastly, the Authentication tab is crucial for enabling LDAP users in the Check Point rulebase (see Figure 4.18).
The Allowed authentication schemes define which schemes are approved for the LDAP users. The most important section is Users’ default values. If the LDAP schema has not been extended to include the Check Point schema, these settings are used to fill in those properties missing for the Check Point LDAP schema. If a user template is selected, all of the template’s properties are dynamically assigned to any LDAP user that authenticates to VPN-1. A default authentication scheme will only define which scheme to use, and nothing else. In both options, select Check Point Password for the authentication scheme.
If you have multiple LDAP servers, add them in the LDAP Account Unit Properties, until all servers are included. Select the highest-priority one, or the most robust, as the Early Compatibility server.
Once you have configured an Account Unit, the Users and Administrators Object Tree will show the Account Unit at the bottom, as in Figure 4.19. Double-click on the Account Unit and it should expand to show the LDAP tree; double-click on any of the branches to retrieve the LDAP entities within that branch.
Within the branch information, if write permissions have been configured for the LDAP server, users and groups can be added, edited, and removed.
The preferred way to grant user access via SmartDirectory is to use LDAP groups. Figure 4.20 shows an example.
Select the Account Unit that contains the users to authenticate. In the Group’s Scope, you can select to recognize all of the Account Unit users, or only those in a certain subtree, or a group in a branch. You can also apply a filter to create a dynamic group (e.g., all users in ou=Access).
Once created, an LDAP group behaves like any other user group in the object database. We will now examine the different types of authentication and how to integrate groups into the rulebase.
User authentication is simple to understand and configure. It works by intercepting connections that are passing through the firewall (Check Point calls this folding the connection), and modifying the traffic in such a way that the firewall asks the user to identify itself before allowing the connection to pass through. Because the user requests a connection to his or her final destination, user authentication is a type of transparent authentication; in other words, the user doesn’t need to go through an intermediate process.
Because NGX needs to modify the traffic itself, it can do so only with specific services which it can understand well: HTTP/S, FTP, Telnet, and rlogin. These services belong to the Authenticated group in the predefined Check Point services. When one of these services is used to access a restricted resource, and a rule is configured to allow User Auth for that connection, the traffic is modified so that the user can enter a password to enable the traffic. For HTTP, Telnet, and rlogin, the user sees an intermediary prompt from the firewall, and once the user authenticates, a new connection to the final destination is made. In the case of FTP traffic, the username and password to authenticate to the FTP server need to be embedded in the user credentials.
User authentication is performed on each connection so that if a machine is being shared by different users (e.g., in a client/server or thin client environment), each user will authenticate his or her connection only, which is safe. Because the firewall needs to examine the traffic of these authenticated services, it requires more processing power from the firewall than either session or client authentication.
To allow user authentication, create a new rule. In the Source field, select Add User Access, and add the user groups that will be able to authenticate using that rule. You can also restrict the origin of the connections. Add the appropriate Destination to that rule (if you want to authenticate all traffic to the Internet, leave it as Any), select which Services you’ll authenticate, select User Auth as the Action, and add appropriate Track, Time, and Comment configurations. Figure 4.21 shows a user authentication rule.
You should edit or verify the properties of the Action field in the user authentication rule, as in Figure 4.22.
You can configure the following properties in the Action field:
Source. Controls whether the Restrict To location in the source of the rule has to intersect the configured location of the user in the database. Select Ignore to override the user database.
For instance, if ruleX has a source of Internal_Net and userY has a source location of Alternate_Net, userX would never be authorized, because there is no intersection of Internal_Net and Alternate_Net. If the desired functionality is to allow userX to authenticate from Internal_Net, ignoring the user database will skip over checking the user’s location properties.
Destination. Destination controls whether the Restrict To location in the destination of the rule has to intersect the configured location of the user in the database. Select Ignore to override the user database.
HTTP. Controls whether to allow authentication to a restricted number of servers, or to any accessible machines. When Predefined Servers is selected, users will be able to access only the list of servers that can be defined in the Policy | Global Properties | Firewall-1 | Security Servers dialog. To authenticate traffic to any destination on the Internet, select All Servers.
Depending on the service you will authenticate (HTTP, FTP, Telnet, or rlogin) the way your users will authenticate is different. Let’s see what the user experience is for these services.
User authentication for Telnet and rlogin is easy for the end-user to understand. When a user tries a command such as telnet 172.29.109.1, the firewall will intercept this command and present its own Telnet prompts, as in Figure 4.23. Once the user correctly authenticates, he or she will see the prompts from his or her original destination and can proceed accordingly.
User authentication for FTP is a bit more complex to understand. The user will still use the command ftp 172.29.109.1, which will be intercepted by the firewall’s FTP security server, but the username will have to reflect the user that is authenticating at the FTP server (i.e., the administrator), the user that is authenticating at the firewall (i.e., the user), and the final destination of the FTP connection (even though it was used in the original FTP command). For example, in this case, the username will be administrator@[email protected], and the password will be the passwords of the FTP user separated by an @ sign from the password of the firewall user (i.e., ftppassword@ fwpassword). Then a connection to the FTP server will be established. Figure 4.24 shows the details.
User authentication for HTTP is simple to use. When activated, an HTTP connection that should be authenticated is modified by the firewall in such a way that the user’s browser displays an authentication dialog box or prompt, using HTTP’s authentication mechanism. The prompt reads FW-1: No user. Once the user authenticates with this prompt, the requested site is displayed in the browser. Figures 4.25 and 4.26 show examples that use Microsoft Internet Explorer and Mozilla Firefox.
Selecting User Authentication for HTTP traffic to the Internet will mean that a user might need to authenticate as many as 10 times before seeing a single Web page, because current Web pages usually reference images or code from other sites, and the browsers need to reauthenticate for each different site.
In Figure 4.27, you can see the entry in the SmartView Tracker generated from the authenticated HTTP access.
Check Point rules are sequential, which means that once a rule can be applied to traffic passing through the firewall, that rule is applied and the rest of the rulebase is ignored. However, there is one exception to this. If a rule allows traffic to a destination, even a rule that would require authentication before that rule, the traffic will pass through without the need for users to authenticate. Remember: An authentication rule accepts traffic that is authenticated, but doesn’t block traffic that fails authentication.
Now we’ll discuss some advanced topics.
Traffic that is intercepted by the firewall, be it FTP, Telnet, rlogin, or HTTP, displays a message from Check Point NGX requesting authentication. It is advisable to change this default message to a generic one that doesn’t broadcast the firewall’s identity, and that can include additional information for users. You can select a file to be presented instead of the regular banner for FTP, Telnet, and rlogin (not for HTTP) in the SmartDashboard’s Global Properties | Firewall | Security Servers dialog box.
If you are making HTTP connections, once the connection is authenticated the firewall needs to redirect the original query to the intended destination. It does so by looking at the original URL’s IP address, and redirecting the user’s browser to that IP. However, if the firewall resolves the destination URL to a nonroutable IP (i.e., the non-NATed IP), or if the Web server is configured to need the Host Header for access (i.e., a Web hosting service that shares one IP with multiple Web pages), the connection will fail. To solve this, enable the setting http_use_host_h_as_dst using Policy | Global Properties | SmartDashboard Customization | Configure | Firewall-1 | Web Security | HTTP Protocol, as in Figure 4.28.
The best scenario for user authentication is when you need to grant authenticated access to a limited number of servers you control (i.e., your intranet, or servers you host in a data center). This is because you can control the HTML code of those servers so that they do not refer sites that are different from their own. Your users will have an easy-to-understand experience and will authenticate only once. User authentication for Telnet is also easy to understand and implement, as your users receive simple prompts to authenticate first to the firewall and then to their final destinations.
Another method available for authentication in Check Point NGX is session authentication. This method uses a client program, called the Session Authentication Agent, which is usually installed in each machine that will be used for authentication. You can use the Session Authentication Agent for any service; it authenticates a particular session by the user. When the firewall encounters a rule with session authentication, it tries to query the appropriate machine using the FW1_snauth service on port 261. The agent will then automatically present the user with an authentication dialog. Session authentication combines user and client authentication, because it can authenticate per session for any service.
However, you need to consider that the Session Authentication Agent is a separate program that you have to install in each user’s machine, and that it is a Windows-only program. Furthermore, the last available version is from NG Feature Pack 1 and there’s no NGX version (as of this writing).
The firewall will try to authenticate all sessions that fall under a session authentication rule. If you configure a rule for authenticating any service to any destination, you might end up authenticating every DNS query and NBT broadcast sent, overloading the firewall authentication mechanism and network. Limit the number of services that use session authentication.
Client authentication is a versatile authentication method that you can use for most of your needs. Unlike user authentication, in which a connection is being authenticated, here you authenticate a machine or an IP (which the firewall considers the client). Client authentication is nontransparent by default, which means that the connection has to be directed to the firewall so that it can ask for the specific authentication. However, with partially or fully automatic sign-on methods, client authentication can be as transparent as user or session authentication. Some of the benefits of client authentication are that any service can be authenticated, and that the authentication can last for a specific period of time. Once a user achieves client authentication, traffic can flow freely with little intervention. Because the firewall doesn’t have to interpret or modify the passing connections, is it faster than user and session authentication and doesn’t intervene in the HTTP traffic passing through the gateway.
Client authentication has some security disadvantages. In a multiuser environment (e.g., Citrix or Terminal Services), all requests originate from the same IP and will be given the same access. Also, if the user doesn’t sign off, other users that log on at that machine will have the same permissions as the previously authenticated user until the authorization expires.
To allow client authentication, create a new rule above any rule that would block ports 900 and 259 to the firewall (usually the Stealth rule). In the source field, select Add User Access, and then add the user group that will be able to authenticate, and optionally restrict to a location from where that group can connect. Then, add the appropriate Destination to that rule (if you want to authenticate all traffic to the Internet, leave it as Any), select which Services you’ll authenticate (here you can use any service at all), select ClientAuth as the Action, and add appropriate Track, Time, and Comment configurations, as in Figure 4.29.
Let’s take a look at the Action column of the Client Authentication rule. You can select many different behaviors according to your desired policy. Once you select Client Auth as the Action, right-click on the field and select Edit Properties to configure the setting, as in Figure 4.31.
As in other authentication actions, Source is used to control whether the source of the rule has to intersect the configured Location of the user, or whether it takes precedence. Select Ignore if you want to override the location configured for the user.
Client authentication cannot determine the final destination of a connection, because users are authenticating directly to the firewall. Therefore, the destination field is grayed out and cannot be selected.
Checking this box will allow the client to access resources granted in the rule, once the user authenticates, only if the user is using Check Point SecureClient and the Secure Configuration Verification (SCV) has succeeded.
If you select Standard sign-on, users will be able to access all resources permitted in the rule at which they authenticated. If you select Specific sign-on, users will have to explicitly specify, through a form or a sequence of prompts, the services and destinations allowed for the client. Specific sign-on is useful for a kiosk machine, where an administrator can authorize access to certain sites or services only, without interacting with the firewall administrator.
The Sign On Method is one of the most important settings when using client authentication. Be sure you know how each method works so that you select the most appropriate to your environment.
The Manual sign-on method activates two ports on the firewall gateway for receipt of the authentication. They are port 900 using HTTP and port 259 using Telnet. Because users need to access these ports on the firewall, you must place the Client Authentication rule above the Stealth rule (the one that drops all connections to the firewall module).
This method is nontransparent, meaning that users will know they are first authenticating to a firewall and then be able to access the appropriate resources.
If you want to HTTP to port 900, you can look at Figures 4.32 through 4.36.
If you want to telnet to port 259, see Figures 4.37 through 4.40.
With partially automatic authentication, if a user tries to access a resource for which he could authenticate using any of the authenticated services (HTTP, FTP, Telnet, or rlogin), the firewall will intercept the connection and request authentication from the user, as it would do with user authentication. Manual authentication may still be used.
Once the user enters the username and password, the firewall interprets the authentication as though it had been manually entered to the firewall, as in client authentication. This is extremely useful, because now users will be required to authenticate only once and can use any resource that the rulebase allows them to. Partially automatic authentication is one of the most used methods of authentication. One thing to keep in mind is that as with user authentication, it can be easy for an intruder sniffing the network to decipher usernames and passwords.
With fully automatic authentication, you further extend the ways the firewall can request authentication from the user. If an authenticated service is used, the firewall intercepts the traffic and requests authentication, as in user authentication. For other services, it will try to invoke session authentication to authenticate the user at the connecting machine. Manual authentication may still be used.
With agent automatic authentication, the firewall will try to authenticate connections only using the Session Authentication Agent at the connecting machine. Manual authentication may still be used.
Here you can select whether you want information or alerts sent to the log when a user successfully authenticates. If you select Alert it will also write the information to the log.
Here you can select how long the user authorization will last. Select Indefinite to require an explicit sign-off from the user (via HTTP to port 900 or Telnet to port 259) to cancel the authorization. Select a specific time limit, in Hours and Minutes, if you want to require reauthentication after a time has lapsed. Select Refreshable timeout if you want the user to not be required to reauthenticate as long as the connection is being used. This is useful in that if a user leaves his machine, someone else can’t sit down and use it.
This limits the number of open connections an authenticated user can make through the firewall. If you’re using FTP, Telnet, or rlogin connections, you could limit the number of sessions through here. However, if you’re using HTTP connections, you will need to select Infinite sessions because a browser will normally open many sessions.
Now let’s discuss a few advanced topics.
There are some properties that you need to configure and verify per gateway, to fine-tune the authentication experience for your users, as in Figure 4.41.
It is very important that you select which Authentication Schemes the gateway will allow for its users. If a user authenticates with a scheme that the gateway does not accept, the user will not be granted access to resources on the gateway. You can select Check Point Password (previously VPN-1/Firewall-1 Password), SecurID, OS Password, RADIUS, or TACACS.
Here are brief descriptions of three authentication settings:
User Authentication session timeout. This setting (by default, 15 minutes) has two behaviors. For FTP and Telnet connections, connections with no activity are terminated after the timeout expires. For HTTP, it applies to the use of one-time passwords (i.e., SecurID tokens). Although the timeout hasn’t expired, the server will not request another one-time password for access to a previously authenticated server.
Enable wait mode for Client Authentication. This setting applies to Telnet client authentication, whereby the Telnet session remains open, and when the user closes the session (by pressing Ctrl+C or through some other manner), the authentication expires. If this option is not selected, the user will have to manually sign off or wait for the session timeout.
Authentication Failure Track. Here you can define whether a failed authentication will generate an alert, a log, or no activity. We recommend that you at least log all failed authentications.
Certain properties are configured globally for all authentication performed by the Check Point gateways. Appropriately enough, you access them from the Global Properties | Authentication tab, as in Figure 4.42.
To prevent an intruder from brute-force-guessing your passwords, you can use the Failed authentication attempts setting to terminate connections after a set number of failed attempts (i.e., wrong passwords). You can set a different number of allowed tries for rlogin, Telnet, client authentication, and session authentication connections.
For Remote Access VPNs, if you are using VPNs, you can restrict the gateway to accept only those users that have a specific suffix in their certificates. Also, if an administrator initializes a certificate in the Certificate Authority, you can define for how many additional days users can pull that certificate before it expires.
To prevent an intruder from brute-force-guessing your passwords, you can enable this protection, which is new for NGX. By setting a specific number of milliseconds to delay each authentication, you can dramatically affect any automatic password-guessing system, and a user will barely notice a difference.
Now we’ll discuss registry settings.
The default client authentication HTTP interface requires four pages for a successful login: the username page, password page, method page, and optional specific sign-on page. If you enable the hclient_enable_new_interface setting by selecting Policy Menu | Global Properties | SmartDashboard Customization | Firewall-1 | Authentication | Client Authentication | HTTP, the HTTP interface will combine the username and password pages into one, and will streamline the user experience, as in Figure 4.43.
If you’re using partially or fully automatic sign-on with HTTP connections, once the connection is authenticated the firewall needs to redirect the original query to the intended destination. It does so by looking up the original URL’s IP address and redirecting the user’s browser to that IP. However, if the firewall resolves the destination URL to a nonroutable IP (i.e., the non-NATed IP), or if the Web server is configured to need the host header for access (i.e., a Web hosting service that shares one IP with multiple Web pages), the connection will fail. To avoid this, enable the http_use_host_h_ as _dst setting by selecting Policy Menu | Global Properties | SmartDashboard Customization | Firewall-1 | Web Security | HTTP Protocol.
When you begin to create a complex policy with different rules for granting user access to different resources, you need to consider the fact that the default behavior for client authentication is to grant access only for the rule where you authenticated. If you need to authenticate once and be granted access by all rules that would permit the user, you have to enable the automatically_open_ca_rules setting by selecting Policy Menu | Global Properties | SmartDashboard Customization | Firewall-1 | Authentication | Client Authentication.
Now we’ll discuss configuration files.
Because Telnet and HTTP are not encrypted, client authentication is inherently less secure than session authentication. However, you can configure NGX to enable HTTPS manual authentication, which will give you the encryption you want when using the built-in HTTP server at port 900 for authentication. See the “Are You 0wned?” sidebar for details.
If you plan to use client authentication’s HTTP interface, you will probably want to change its appearance and include your company’s logo, an unauthorized use warning, and some nice graphics. You can do this by editing the HTML files in the $FWDIR/ conf/ahclientd directory. Remember to leave the % commands intact, as NGX uses them to insert the information it needs.
Many security rulebases do not need individual user rights, and they work with hosts, gateways, networks, groups, ranges, and servers. However, for both security and tracking purposes, you might need to integrate authentication with your security policy. You’ll be able to identify users’ navigation, and grant privileged users access to restricted resources or connections with specific services.
You have a choice of how to recognize a user: by accessing external directory servers with RADIUS or TACACS, or by using the internal user database. You can integrate with Microsoft Active Directory through the Microsoft Internet Authentication Service, or get the SmartDirectory license for LDAP integration.
You can choose among user, client, and session authentication, depending on your needs and a balance of security, ease of use, and flexibility. User authentication is easy to use and is transparent, but it is not flexible, has no security, and can be cumbersome for accessing external Web sites. Client authentication is flexible and can be secure, but it is not transparent to the user and it is less secure than other methods. Session authentication is flexible, secure, and easy to use, but installing the agent on each machine will be something you have to consider.
Check Point NGX gives you many options. You just have to choose which to implement.
With authentication you can grant specific permissions to groups of users that might have different IPs and might be moving around different computers. | |
Users in DHCP environments are suitable for implementing authentication, as well as roaming administrators that need to access special files. | |
Authentication rules have to be placed carefully so that a nonauthentication rule does not override the need for a user to authenticate. |
Several schemes are available to authenticate users, from both the internal database and external directories such as RADIUS, TACACS, LDAP, and SecurID. | |
Administrators are created in the SmartDashboard and assign Permissions Profiles to limit their actions within the configuration applications. | |
Users are created based on templates, and should be placed in groups to be integrated with the rulebase. |
SmartDirectory is Check Point’s LDAP implementation, which allows connections to external user databases such as Microsoft Active Directory. | |
SmartDirectory requires the creation of an LDAP Account Unit, which can connect to multiple LDAP servers. The LDAP Account Unit is used for creating LDAP user groups. | |
Within the LDAP Account Unit, you can select a user template that will be applied to LDAP authenticated users when the LDAP schema has not been extended to include Check Point fields. |
User authentication is transparent to the user and doesn’t require configuration of client machines. | |
Only the four authenticated services—HTTP, FTP, Telnet, and rlogin—can work with user authentication. | |
User-authenticated HTTP access to the Internet will require users to authenticate multiple times for a single Web page. |
Session authentication can authenticate each session from the client, and can have encryption enabled for security. | |
Session authentication requires a Session Authentication Agent installed in the authorizing machine. |
3.147.27.131