Borderware Firewall Server Version 7.1 VPN Authentication Configuration Guide Copyright 2005 CRYPTOCard Corporation All Rights Reserved http://www.cryptocard.com
Overview The BorderWare Firewall Server is a comprehensive integrated solution for securing an internet connection. Built on a hardened operating system, it eliminates vulnerabilities and costs associated with a separate firewall and operating system. Configuring Authentication methods The Proxy Server can use multiple authentication methods for authenticating users: Local Users, RADIUS or LDAP. One or more of these methods can be used at a time, so multiple authentication methods can be combined. If only one method is enabled for use, then a failure to authenticate using that method will result in a user being denied access. Enabling authentication types can be done through the Authentication Types menu in BWClient or the firewall console. When the Proxy Server is configured to use more than one authentication type, the server will attempt each method in sequence until a successful authentication has occurred. If no method is successful, access will be denied. The sequence of the various methods is determined by the Priority parameter set for each method. Methods with lower priority will be attempted first. To enable and set the priority for an authentication type, follow these steps: Open BWClient and log into the firewall. Under the Proxy Server menu, select Authentication Types. 3 rd Party Integration: Borderware Firewall Server 1
Modify the correct type by double-clicking on the entry. Enable the type, and set the Priority value as desired. Click on the Apply button to apply your changes. Configuring RADIUS servers Once this is complete, a list of RADIUS servers must be specified with the following parameters: Host (FQDN or IP address). The domain name or IP address of the RADIUS server. Priority. If multiple RADIUS servers are specified, this field will govern the order they are queried in. Lower priority servers will be contacted first. This field only applies to 3 rd Party Integration: Borderware Firewall Server 2
RADIUS servers and is not related to the global priority setting for the Authentication Type. Secret. This is the secret shared between the firewall and the RADIUS server. It must match exactly the same value entered on the RADIUS server. Timeout. This is the amount of time in seconds that the firewall will wait for a response from the RADIUS server before retrying Retries. This is the number of attempts the firewall will make to contact the RADIUS server before aborting. Once this number has been exceeded, the firewall will attempt the next RADIUS server in the list, or the next authentication type listed. To add a RADIUS Server, double click on the RADIUS Authentication type and select the Server List tab. Click on New and fill in the parameters. The Sentinel Client and the IPSec server include the option to require additional authentication from a connecting VPN client. The current release supports a user name and 3 rd Party Integration: Borderware Firewall Server 3
password, which are maintained on the Firewall Server, and RADIUS. This additional authentication guards against the risk that an unauthorized user may attempt to use the client workstation to gain access to the protected network via the VPN. Open the VPN connection and under the XAUTH/Remote Auth IDs tab, you can configure extended authentication, such as RADIUS, for additional security, as the basic password method uses clear-text passwords. The Sentinel client must be configured to recognize that the VPN connection requires additional authentication. This is done by checking the Extended Authentication box on the properties screen. The Sentinel client can use XAUTH from a static address. Configure the CRYPTO-Server If you wish to use the CRYPTO-Server as your RADIUS server, you must verify that the Protocol Server is configured to accept RADIUS communications. Connect to the CRYPTO-Server using the Console, and choose Server -> System Configuration & Status from the menu. 3 rd Party Integration: Borderware Firewall Server 4
In the Entity column choose RadiusProtocol. Next look at the Value corresponding to the key NAS.2. The data in this value field defines which RADIUS clients are allowed to connect to the CRYPTO-Server, and the shared secret they must use. RadiusProtocol NAS.# keys By default, the CRYPTO-Server is configured to listen for RADIUS requests over UDP port 1812, from any host on the same subnet, using a shared secret of testing123. You can manually define as many RADIUS clients as desired by adding NAS.# entries to the CRYPTO-Server configuration. The syntax of the data for a NAS entry is as follows: <First IP>, <Last IP>, <Hostname>, <Shared Secret>, <Perform Reverse Lookup?>, <Authentication Protocols> Where: <First IP>: The first IP address of the RADIUS client(s) configured in this NAS.# key. <Last IP>: The last IP address of the RADIUS client(s) configured in this NAS.# key. If only one IP address is defined by a NAS.# key, the <First IP> and <Last IP> will be the same. 3 rd Party Integration: Borderware Firewall Server 5
<Hostname>: Only applies in cases where the NAS.# key is for one host. Required for performing reverse lookup. <Shared Secret>: A string used to encrypt the password being sent between the CRYPTO-Server and the RADIUS client (i.e. the Check Point VPN/Firewall). You will need to enter the exact same string into the Check Point configuration in Section 3. The <Shared Secret> string can be any combination of numbers and uppercase and lowercase letters. <Perform Reverse Lookup?>: An added security feature of the CRYPTO-Server is its ability to verify the authenticity of a RADIUS client by cross-checking its IP address with the Domain Name Server. If this value is set to true, when the CRYPTO-Server receives a RADIUS request from the RADIUS client defined by this NAS.# entry, it sends a request to the DNS using the hostname set in the NAS.# entry. The DNS should respond with the same IP address as configured in the NAS.# entry, otherwise the CRYPTO-Server assumes that the RADIUS packet is coming from some other host posing as the RADIUS client, and ignores the request completely (also known as a man in the middle attack). <Authentication Protocols>: Many different authentication protocols can be used during RADIUS authentication. Common examples are PAP, CHAP,MS-CHAP and EAP. This setting determines which authentication protocols the CRYPTO-Server will allow from a given RADIUS client. Currently PAP and CHAP are the only available authentication protocols for RADIUS clients. NOTE: After changing or adding a NAS.# entry, click the Apply button. Verifying the CRYPTO-Server RADIUS Protocol Settings The RADIUSProtocol.dbg log on the CRYPTO-Server will include information about its RADIUS configuration. Each time the Protocol Server starts, the following information is logged: Adding IP range 127.0.0.1 to 127.0.0.1 to ACL with reverse lookup set to false Adding IP range 192.168.21.1 to 192.168.21.254 to ACL with reverse lookup set to false RADIUS protocol has established link with EJB server at jnp://192.168.21.5:1099 RADIUS Receiver Started: listening on port 1812 UDP. RADIUS Receiver Started: listening on port 1813 UDP. This example indicates that the CRYPTO-Server is listening for RADIUS requests on UDP port 1812 (for authentication) and 1813 (for accounting), and RADIUS clients within the IP range of 192.168.21.1 to 192.168.21.254. As well, no reverse lookup is being performed. 3 rd Party Integration: Borderware Firewall Server 6