Contents/Index/Search Download Complete PDF Send Feedback Print This Page

Previous

Next

VPN for Remote Access Considerations

When designing Remote Access VPN, consider the following issues:

Related Topics

Policy Definition for Remote Access

User Certificate Creation Methods when Using the ICA

Multiple Certificates per User

Internal User Database vs. External User Database

NT Group/RADIUS Class Authentication Feature

Granting User Access Using RADIUS Server Groups

Associating a RADIUS Server with Security Gateway

Policy Definition for Remote Access

There must be a rule in the Security Policy Rule Base that grants remote users access to the LAN. Consider which services are allowed. Restrict those services that need to be restricted with an explicit rule in the Security Policy Rule Base.

User Certificate Creation Methods when Using the ICA

Check Point's Internal Certificate Authority (ICA) offers two ways to create and transfer certificates to remote users:

  1. The administrator generates a certificate in Security Management server for the remote user, saves it to removable media and transfers it to the client "out-of-band."
  2. The administrator initiates the certificate process on the Security Management server (or ICA management tool), and is given a registration key. The administrator transfers the registration key to the user "out-of-band." The client establishes an SSL connection to the ICA (using the CMC protocol) and completes the certificate generation process using the registration key. In this way:
    • Private keys are generated on the client.
    • The created certificate can be stored as a file on the machines hard-drive, on a CAPI storage device, or on a hardware token.

    This method is especially suitable for geographically spaced-remote users.

Multiple Certificates per User

Check Point VPN lets you define many certificates for each user. This lets users connect from different devices without the necessity to copy or move certificates from one device to another. Users can also connect from different devices at the same time.

Internal User Database vs. External User Database

Remote Access functionality includes a flexible user management scheme. Users are managed in a number of ways:

  • INTERNAL - A Security Gateway can store a static password in its local user database for each user configured in Security Management server. No additional software is needed.
  • LDAP - LDAP is an open industry standard that is used by multiple vendors. Check Point products integrate LDAP with Check Point User Directory. Manage the users externally on the LDAP server, and changes are reflected on the SmartDashboard. Security Gateways query the User Directory data for authentication.
  • RADIUS - Remote Authentication Dial-In User Service (RADIUS) is an external authentication scheme that provides security and scalability by separating the authentication function from the access server.

    When employing RADIUS as an authentication scheme, the Security Gateway forwards authentication requests by remote users to the RADIUS server. The RADIUS server, which stores user account information, authenticates the users. The RADIUS protocol uses UDP for communications with the Security Gateway. RADIUS Servers and RADIUS Server Group objects are defined in SmartDashboard.

  • SecurID Token Management ACE/Server - Developed by RSA Security, SecurID requires users to both possess a token authenticator and to supply a PIN or password. Token authenticators generate one-time passwords that are synchronized to an RSA ACE/Server, and may come in the form of hardware or software. Hardware tokens are key-ring or credit card-sized devices, while software tokens reside on the PC or device from which the user wants to authenticate. All tokens generate a random, one-time-use access code that changes every minute or so. When a user attempts to authenticate to a protected resource, that one-time-use code must be validated by the ACE/Server.

    When employing SecurID as an authentication scheme, the Security Gateway forwards authentication requests by remote users to the ACE/Server. ACE manages the database of RSA users and their assigned hard or soft tokens. The VPN module acts as an ACE/Agent 5.0, which means that it directs all access requests to the RSA ACE/Server for authentication. For agent configuration see ACE/Server documentation.

The differences between user management on the internal database, and User Directory:

  • User Directory is done externally and not locally.
  • If you change User Directory templates the change is applied to users dynamically, immediately.

NT Group/RADIUS Class Authentication Feature

Authentication can take place according to NT groups or RADIUS classes. In this way, remote access users are authenticated according to the remote access community group they belong to.

Note - Only NT groups are supported, not Active Directory.

Granting User Access Using RADIUS Server Groups

The Security Gateway enables you to control access for authenticated RADIUS users, based on the administrator's assignment of users to RADIUS groups. These groups are used in the Security Rule Base to restrict or grant access to users to specific resources. Users are unaware of the groups to which they belong.

To use RADIUS groups, you must define a return attribute in the RADIUS user profile of the RADIUS server. This attribute is returned to the Security Gateway and contains the group name (for example, RAD_<group to which the RADIUS users belong>) to which the users belong. Although other RADIUS attributes can be used, by default the Class attribute is used (IETF RADIUS attribute number 25).

To grant access using RADIUS server groups:

  1. In SmartDashboard, go to Manage > Server and OPSEC Applications.

    Servers and OPSEC Applications window opens.

  2. Click New > RADIUS.

    RADIUS Server Properties window opens.

  3. Configure new server properties:
    1. Name the RADIUS Server object.
    2. Click New to create a new Host Object.

      Host Node window opens.

    3. Enter the Name and the IP Address of the new RADIUS Host object, and click OK.
    4. Select the Service - RADIUS (on port 1645) or NEW-RADIUS (on port 1812 service).

      Note - The default setting is RADIUS, however the RADIUS standards group recommends using NEW-RADIUS, because port 1645 can conflict with the datametrics service running on the same port.

    5. Enter the Shared Secret that you configured on the RADIUS server.
    6. Select the version - RADIUS Ver. 1.0 Compatible (RFC 2138 compliant) or RADIUS Ver. 2.0 Compatible (RFC 2865 compliant).
    7. Select the Priority, if you use more than one RADIUS Authentication server.
    8. Click OK.
    9. Click Close.
  4. Create a generic* External User Profile:
    1. Go to Manage > Users and Administrators.

      Users and Administrators window opens.

    2. Go to New > External User Profile > Match all users.

      External User Profile Properties window opens.

    3. In the Authentication tab, select RADIUS as the Authentication Scheme.
    4. Select the created RADIUS server (not the node) from the drop-down list.
    5. Click OK.
    6. Click Close.
  5. Define the RADIUS user groups
    1. Go to Manage > Users & Administrators.

      User and Administrators window opens.

    2. Go to New > User Group.

      Group Properties window opens.

    3. Enter the name of the group in this format: RAD_<group to which the RADIUS users belong>. Make sure the group is empty.
    4. Click OK.
    5. Click Close.
  6. Create the required Rule Base rules to allow access to RADIUS users.
  7. Save the changes, and exit SmartDashboard.
  8. Run cpstop on the Security Management Server.
  9. On the Security Management Server, use GuiDBedit to change the value of the add_radius_groups attribute from false to true.
  10. Run cpstart on the Security Management Server.
  11. Install the policy.
  12. On the RADIUS server, modify the RADIUS users to include a class RADIUS attribute on the users Return list that corresponds to the user group that they access.

To use a different attribute instead of the class attribute, do one of the following:

  1. On the Security Gateway, use GuiDBedit to modify the value of the firewall_properties attribute radius_groups_attr to the new RADIUS attribute.
  2. On the RADIUS server, ensure that you use the same RADIUS attribute (on the users' Return list that corresponds to the Firewall user group that they access).

Associating a RADIUS Server with Security Gateway

You can associate users with the Radius authentication server in the User PropertiesAuthentication tab. You can also associate a gateway with a Radius server so that this overrides the User to Radius server association. This is performed by editing the database using the dbedit command.

To associate one or more Radius servers to a gateway:

  1. Run the dbedit command as follows:

    modify network_objects <gw obj> radius_server servers:<radius obj>

  2. To switch off the Radius to the Security Gateway association so that the user always authenticates to the Radius server specified in the User Properties Authentication tab, switch off another attribute in the database by running the dbedit command:

    modify users <user obj> use_fw_radius_if_exist false

 
Top of Page ©2013 Check Point Software Technologies Ltd. All rights reserved. Download Complete PDF Send Feedback Print