Remote Authentication Dial-In User Service, or RADIUS, is one of the most common authentication and accounting services used on the Internet. The main driver behind RADIUS development was serving dialup users, as implied in the service’s name. Over time, RADIUS has evolved into an enterprise authentication, authorization, and accounting (AAA) product.
Nowadays it is possible to integrate most of the commonly used authentication schemes with RADIUS servers. Since the RADIUS standards are open (IETF RFC-2058), most manufacturers of new products (including Check Point) chose to integrate with RADIUS..
RADIUS work principles are very simple.The RADIUS protocol defines a client and server. VPN-1/FireWall-1 acts as a network access server (NAS)—the client part of the setup. Client and server communicate on UDP port 1645. Communication is partly hashed by MD5, to provide some level of message integrity. When VPN-1/FireWall-1 receives a request that matches a RADIUS authentication rule, the firewall sends an access-request packet to the RADIUS server.The access-request packet contains the username, encrypted password, NAS IP address, and port.The RADIUS server returns "access-reject" or "access-accept" messages, depending on the validation of the request. Check Point does not utilize other challenge/response authentication protocols (such as PAP/CHAP) over the RADIUS protocol. Authorization and accounting features are also not functional for VPN-1/FireWall-1. FireWall-1 logs successful or failed
RADIUS authentication attempts with its native logging facilities.
Setting Up the Firewall for RADIUS Authentication
The RADIUS protocol is included in VPN-1 and VPN-1/FireWall-1 Control Connections, but remember that in NG, Accept VPN-1 and VPN-1/FireWall-1 Control Connections only applies to VPN-1/FireWall-1 installed devices.
The basic steps to define RADIUS authentication for FireWall-1 are as follows:
1. Define a RADIUS server. From the Objects tree. select Servers | RADIUS. Enter the host description service and the shared secret, as displayed in Figure 3.73.The shared secret will be used to authenticate with the RADIUS server. In NG you may define multiple RADIUS servers in a single group. To define a RADIUS group, select Servers | RADIUS Group and add your servers one at a time. A RADIUS group is for simple high availability only; for sophisticated chaining options, use a third-party RADIUS proxy.
Figure 3.73 Radius Server Properties
2. You have two options for defining users.You may either define your users in the firewall’s user database and control authentication from the firewall, or you can use external user profiles. With external profiles, authentication requests are checked not on a per-user basis, but on a per-profile basis. When Match All is chosen, all unknown users will be matched against the Generic* profile, which eliminates the need for redefining each user on FireWall-1 (see Figure 3.74).
Figure 3.74 External User Profile Properties
Tools & Traps…
The Order of Authentication Schemas on VPN-1/FireWall-1
If the same username is defined in multiple user databases, VPN-1/FireWall-1 searches the databases in the following order: FireWall-1 user database, LDAP, then Generic*. With NG FP3, when external user groups are defined, this limitation becomes obsolete with domain matching.
3. Create a regular user group (see Figure 3.75) for your RADIUS users, and then add the RADIUS users to this group. If external user profiles are used, profiles should be added to user groups. The Encryption tab should be configured if SecureClients will be used with IKE. Choose the related RADIUS server or group from the Authentication tab.
Figure 3.75 The Object Tree Users Tab
4. As displayed in Figure 3.76, allow RADIUS authentication on the gateway’s Authentication tab. If a policy server is used, RADIUS user groups should also be added to the Policy Server group on the Authentication tab of the gateway.
Figure 3.76 Gateway Authentication Properties
5. For SecureClient/SecuRemote access in a simplified policy, add a RADIUS user group to participating user groups in your Remote Access Community and define your Rule Base as shown in Figure 3.77.
Figure 3.77 Rule Base for RADIUS Authentication
6. On your VPN client, you will get an "Authenticated by RADIUS" message if you successfully complete the settings. In SmartTracker, you should see the log entries shown in Figure 3.78.
Figure 3.78 SmartView Tracker Entries for RADIUS Authentication
Setting Up RADIUS for FireWall-1 Authentication
Since RADIUS is an industry standard, there are plenty of RADIUS server vendors on the market. Using an OPSEC certified RADIUS solution is recommended. We used OPSEC certified Steel-Belted RADIUS software when running tests for this topic. Besides serving standard RADIUS requests, most of the AAA servers can pipe authentication requests to proprietary systems. For example, if you want to use NT 4.0 user groups in your authentication, the AAA server can act as a proxy.
Configuring Steel-Belted RADIUS for standard RADIUS authentication is very simple. Simply define your VPN-1/FireWall-1 as a RAS client and select Check Point FireWall-1/VPN-1 in the Make/Model drop-down list (see Figure 3.79). When you enter your shared secret for RADIUS in the appropriate box, you are all set. This shared secret should only be used for RADIUS authentication on the FireWall-1 side.
Figure 3.79 Configuring Steel-Belted RADIUS for Standard RADIUS Authentication
Once the firewall is defined as a RAS client, all RADIUS access-requests from VPN-1/FireWall-1 will be authenticated in the RADIUS user database (see Figure 3.80).You may either define your usernames in the native RADIUS DB or use existing user repositories. To back up all your configuration, simply export your configuration to a RADIUS information file (*.rif) from the RADIUS GUI. Database files are specific to implementation.
Figure 3.80 RADIUS User Database
Suggested Uses of RADIUS Authentication
A RADIUS server could be a good choice for the following reasons:
■ It accommodates existing user database integration.
■ Most third-party strong authentication systems are integrated with RADIUS servers.
■ It provides a unified AAA server.
■ SmartClient Administrator logins are supported.
A RADIUS server has the following disadvantages when used with VPN-1/ FireWall-1:
■ Granular control policies cannot be applied, since the IP address of the gateway is unique and only a single policy can be applied for all users of VPN-1/FireWall-1.
■ RADIUS has many attributes that are defined for authorization and accounting of dialup connections.These attributes are not used by VPN-1/ FireWall-1.
■ Database access is not standard and requires specific interfaces.
■ RADIUS does not support IKE natively (although this was extended by RFC-3162). VPN-1/FireWall-1 handles authentication with Hybrid mode support. Client/server communication between the firewall and the RADIUS server is encrypted by MD5.
