Introduction
Upcoming SlideShare
Loading in...5
×
 

Introduction

on

  • 300 views

 

Statistics

Views

Total Views
300
Views on SlideShare
300
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Introduction Introduction Document Transcript

    • SecurID Ready Partner Product Implementation Guide Introduction • Company Name: Nokia • Product: Nokia IP with Check Point FireWall-1 Nokia IP Security Solutions offer a comprehensive line of products for Internet security applications. We combine world-class routing capabilities with the best-of-breed firewall software from Check Point. This unique combination of the Nokia IPSO™ routing operating system and Check Point FireWall-1™ gives you an unprecedented security solution for Internet access and Virtual Private Networking (VPN). The fully integrated router/firewall solution introduces a new level of simplicity in deploying firewalls and VPNs. Additionally, Nokia supports true high-availability through the combination of the Virtual Router Redundancy Protocol (VRRP) and Check Point Fire Wall- 1 Synchronization. . • Product Category: Firewall & VPN • Marketing Contact: • Name: Karl Danz • Phone: : 408-990-2020 • FAX: : 408-743-5677 • E-mail: kwd@iprg.nokia.com Support Contact: Internet Security • Phone: 1-888-477-9824 or 1-650-625-2525 • Fax: 1-650-625-2903 • Email: support@iprg.nokia.com • Web: https://support.iprg.nokia.com/ • Web Location: www.nokia.com Configuration Description FireWall-1 supports native SecurID authentication via the ACE/Agent APIs. FireWall-1 has configured SecurID service icons for easy implementation of SecurID Authentication. SecurID authentication is supported in four authentication methods to the firewall: • User authentication • Client authentication • Session Authentication • SecuRemote (virtual private networking) 1
    • SecurID Ready Partner Product Implementation Guide Product Characteristics • Authentication methods supported Direct via ACE/Agent • Implementation SecurID authentication is supported for the following protocols: FTP TELNET HTTP RLOGIN SecuRemote (VPN) SecurID users are specified by their authentication scheme and group membership. • ACE/Server client definition: UNIX FIREWALL-1 VERSION 4.0 INCLUDES SUPPORT FOR ACE/AGENT DES ENCRYPTION ONLY. Configure the client for DES encryption, not SDI. Product Requirements SecurID authentication is supported on the following FireWall-1 platforms: Hardware: Nokia IP family Software : IPSO 3.1.4-FCS1 or Higher. An X Windows GUI environment is required to manage FireWall-1 for UNIX platforms. Also the Nokia Voyager administration program. 2
    • SecurID Ready Partner Product Implementation Guide ACE/Client features supported The following features are supported for all authentication methods: • New Pin Mode * • Next Tokencode Mode * • ACE/Server Slave • DES encryption (SDI encryption no longer used as of version 4.0) • All token types * New Pin and Next Tokencode do not work to a Slave ACE/Server. Third-party ACE/Client Configuration Before implementing SecurID, make sure the FireWall-1 product is working properly. FIREWALL-1 VERSION 4.0 INCLUDES ONLY ACE/CLIENT LIBRARIES WITH ‘DES‘ ENCRYPTION. MAKE SURE THE ACE/SERVER CLIENT DEFINITION FOR THE FIREWALL SYSTEM IS SET FOR DES, AND THAT A DES-ENCRYPTED SDCONF.REC IS MOVED TO THE FIREWALL SYSTEM. An important step in allowing communication to the ACE/Server is to have the sdconf.rec file in the proper directory on the firewall. Create a /var/ace directory on the firewall, and copy the ACE/Server’s $VAR_ACE/sdconf.rec file to this directory. The $VAR_ACE directory is the full path for the ace/data directory. Important: Remember if using FTP to transfer the sdconf.rec, transfer the file in binary mode. Creating Rules for SecurID Authentication SecurID authentication is supported for user, client, and session authentication. Complete information on these authentication methods and when each should be used can be found in the FireWall-1 Architecture and Administration User Guide. For each type, define a user in the Users Manager and set the users authentication scheme to SecurID: 3
    • SecurID Ready Partner Product Implementation Guide Define a User Group that includes the defined user(s). Below is a brief description (largely from Check Point documentation) and examples of each type’s configuration and use. In all these examples, a group called SecurID_Users was created, and its members are users who have SecurID specified as their authentication scheme. User Authentication User authentication allows an administrator to grant access privileges on a per user basis, without regard to the user’s IP source. Rule #1 below allows all SecurID users access to the ‘Authenticated’ services, which include ftp, telnet, rlogin, and http, by default. Note that rules 2 and 3 are here for clarity, but are not required if the firewall is configured to allow outgoing packets. These rules would be required if the firewall was configured not to allow outgoing packets as part of the policy properties. A sample telnet authentication (with new PIN) using this rule: 4
    • SecurID Ready Partner Product Implementation Guide Client Authentication Client authentication allows an administrator to grant access to a specific user at a specific source. Once user authentication is working with SecurID, client authentication works similarly. Refer to the Architecture and Administration User Guide for more information on client authentication and its different options. For SecurID users client authentication is attractive since you can authenticate to the firewall once, then establish additional connections without having to re-authenticate. In order to do this, though, you must manually connect and authenticate using client authentication. For example, if you specify a policy similar to the one above, but for Client Authentication, and set the action properties as below: 5
    • SecurID Ready Partner Product Implementation Guide You can authenticate once, and that authentication will be valid for the specified time, and can be ‘refreshable’. A sample client authentication would look like the following: By specifying a ‘Standard Sign-on’, and depending on the rule, you could then establish subsequent connections without having to re-authenticate. Client authentication is available by opening a telnet connection to port 259 or http connection to port 900 of the firewall. Session Authentication Firewall-1’s session authentication support is a useful option for SecurID users, but requires an additional piece of client software be loaded on each client PC. Session authentication can be used to authenticate any service on a per-session basis. Because of this, it allows for relatively transparent authentication through the firewall. To configure session authentication on the firewall, create a rule similar to the following: You would now require users to run the Session Authentication Agent on each PC or workstation that requires access through this rule. Session authentication allows for the caching of passwords so users don’t have to authentication for every connection. This is not supported for one-time passwords like SecurID, so you must configure the Session Authentication Agent as follows: 6
    • SecurID Ready Partner Product Implementation Guide When a user attempts to open a new connection that matches the rule, you’ll see a window like below to perform a SecurID authentication: VPN Authentication via SecuRemote FireWall-1’s encryption support for virtual private networking also supports SecurID authentication. This is achieved with use of the SecuRemote client. Refer to the FireWall-1 Virtual Private Networking book for information on how to configure the firewall for encrypted tunnels. Below is an example of a simple rule set that requires client PCs that want to pass through the firewall to use the SecuRemote client to encrypt the connections: 7
    • SecurID Ready Partner Product Implementation Guide 8
    • SecurID Ready Partner Product Implementation Guide Similar to other authentication methods, SecurID support is established by the user definitions and how the rule is created. Once the firewall is configured and the SecuRemote client is installed and configured on the client PCs, authentication will look like the following: Known Problems Authentication to a Slave ACE/Server The Nokia IP family of products will not successfully authenticate a user who is in NEW- PIN or NEXT-TOKENCODE mode to a slave ACE/Server. 9