SSL VPN and Web Security Server

Transcription

1 Connectra Server SSL VPN and Web Security Server IMPORTANT Check Point recommends that customers stay up-to-date with the latest service packs and versions of security products, as they contain security enhancements and protection against new and changing attacks. For additional technical information about Check Point products, consult Check Point s SecureKnowledge at: See the latest version of this document in the User Center at: docs_r55.html Part No.: June 2004

2

3 Check Point Software Technologies Ltd. All rights reserved. This product and related documentation are protected by copyright and distributed under licensing restricting their use, copying, distribution, and decompilation. No part of this product or related documentation may be reproduced in any form or by any means without prior written authorization of Check Point. While every precaution has been taken in the preparation of this book, Check Point assumes no responsibility for errors or omissions. This publication and features described herein are subject to change without notice. RESTRICTED RIGHTS LEGEND: Use, duplication, or disclosure by the government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS and FAR TRADEMARKS: Check Point, the Check Point logo, ClusterXL, ConnectControl, FireWall-1, FireWall-1 GX, FireWall-1 SecureServer, FireWall-1 SmallOffice, FireWall-1 VSX, FireWall-1 XL, FloodGate-1, INSPECT, INSPECT XL, IQ Engine, MultiGate, Open Security Extension, OPSEC, Provider-1, SecureKnowledge, SecurePlatform, SecureXL, SiteManager-1, SmartCenter, SmartCenter Pro, SmartDashboard, SmartDefense, SmartLSM, SmartMap, SmartUpdate, SmartView, SmartView Monitor, SmartView Reporter, SmartView Status, SmartView Tracker, SmartConsole, TurboCard, Application Intelligence, SVN, UAM, User-to-Address Mapping, UserAuthority, VPN-1, VPN-1 Accelerator Card, VPN-1 Net, VPN-1 Pro, VPN-1 SecureClient, VPN-1 SecuRemote, VPN-1 SecureServer, VPN-1 SmallOffice and VPN-1 VSX are trademarks or registered trademarks of Check Point Software Technologies Ltd. or its affiliates. All other product names mentioned herein are trademarks or registered trademarks of their respective owners. The products described in this document are protected by U.S. Patent No. 6,496,935, 5,606,668, 5,699,431 and 5,835,726 and may be protected by other U.S. Patents, foreign patents, or pending applications. THIRD PARTIES: Entrust is a registered trademark of Entrust Technologies, Inc. in the United States and other countries. Entrust s logos and Entrust product and service names are also trademarks of Entrust Technologies, Inc. Entrust Technologies Limited is a wholly owned subsidiary of Entrust Technologies, Inc. FireWall-1 and SecuRemote incorporate certificate management technology from Entrust. Verisign is a trademark of Verisign Inc. The following statements refer to those portions of the software copyrighted by University of Michigan. Portions of the software copyright Regents of the University of Michigan. All rights reserved. Redistribution and use in source and binary forms are permitted provided that this notice is preserved and that due credit is given to the University of Michigan at Ann Arbor. The name of the University may not be used to endorse or promote products derived from this software without specific prior written permission. This software is provided as is without express or implied warranty. Copyright Sax Software (terminal emulation only). The following statements refer to those portions of the software copyrighted by Carnegie Mellon University. Copyright 1997 by Carnegie Mellon University. All Rights Reserved. Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation, and that the name of CMU not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission.cmu DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL CMU BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. The following statements refer to those portions of the software copyrighted by The Open Group. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE OPEN GROUP BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. The following statements refer to those portions of the software copyrighted by The OpenSSL Project. This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit ( THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY * EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. The following statements refer to those portions of the software copyrighted by Eric Young. THIS SOFTWARE IS PROVIDED BY ERIC YOUNG ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. Copyright 1998 The Open Group. The following statements refer to those portions of the software copyrighted by Jean-loup Gailly and Mark Adler Copyright (C) Jean-loup Gailly and Mark Adler. This software is provided 'as-is', without any express or implied warranty. In no event will the authors be held liable for any damages arising from the use of this software. Permission is granted to anyone to use this software for any purpose, including commercial applications, and to alter it and redistribute it freely, subject to the following restrictions: 1. The origin of this software must not be misrepresented; you must not claim that you wrote the original software. If you use this software in a product, an acknowledgment in the product documentation would be appreciated but is not required. 2. Altered source versions must be plainly marked as such, and must not be misrepresented as being the original software. 3. This notice may not be removed or altered from any source distribution. The following statements refer to those portions of the software copyrighted by the Gnu Public License. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.you should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. The following statements refer to those portions of the software copyrighted by Thai Open Source Software Center Ltd and Clark Cooper Copyright (c) 2001, 2002 Expat maintainers. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. GDChart is free for use in your applications and for chart generation. YOU MAY NOT redistribute or represent the code as your own. Any re-distributions of the code MUST reference the author, and include any and all original documentation. Copyright. Bruce Verderaime. 1998, 1999, 2000, Portions copyright 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002 by Cold Spring Harbor Laboratory. Funded under Grant P41- Check Point Software Technologies Ltd. U.S. Headquarters: 800 Bridge Parkway, Redwood City, CA 94065, Tel: (650) Fax: (650) , info@checkpoint.com International Headquarters: 3A Jabotinsky Street, Ramat Gan, 52520, Israel, Tel: Fax: ,

4 RR02188 by the National Institutes of Health. Portions copyright 1996, 1997, 1998, 1999, 2000, 2001, 2002 by Boutell.Com, Inc. Portions relating to GD2 format copyright 1999, 2000, 2001, 2002 Philip Warner. Portions relating to PNG copyright 1999, 2000, 2001, 2002 Greg Roelofs. Portions relating to gdttf.c copyright 1999, 2000, 2001, 2002 John Ellson Portions relating to gdft.c copyright 2001, 2002 John Ellson Portions relating to JPEG and to color quantization copyright 2000, 2001, 2002, Doug Becker and copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, Thomas G. Lane. This software is based in part on the work of the Independent JPEG Group. See the file README-JPEG.TXT for more information. Portions relating to WBMP copyright 2000, 2001, 2002 Maurice Szmurlo and Johan Van den Brande. Permission has been granted to copy, distribute and modify gd in any context without fee, including a commercial application, provided that this notice is present in user-accessible supporting documentation. This does not affect your ownership of the derived work itself, and the intent is to assure proper credit for the authors of gd, not to interfere with your productive use of gd. If you have questions, ask. "Derived works" includes all programs that utilize the library. Credit must be given in user-accessible documentation. This software is provided "AS IS." The copyright holders disclaim all warranties, either express or implied, including but not limited to implied warranties of merchantability and fitness for a particular purpose, with respect to this code and accompanying documentation. Although their code does not appear in gd 2.0.4, the authors wish to thank David Koblas, David Rowley, and Hutchison Avenue Software Corporation for their prior contributions. Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at The curl license COPYRIGHT AND PERMISSION NOTICE Copyright (c) , Daniel Stenberg, <daniel@haxx.se>.all rights reserved. Permission to use, copy, modify, and distribute this software for any purpose with or without fee is hereby granted, provided that the above copyright notice and this permission notice appear in all copies. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. Except as contained in this notice, the name of a copyright holder shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Software without prior written authorization of the copyright holder. The PHP License, version 3.0 Copyright (c) The PHP Group. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. The name "PHP" must not be used to endorse or promote products derived from this software without prior written permission. For written permission, please contact group@php.net. 4. Products derived from this software may not be called "PHP", nor may "PHP" appear in their name, without prior written permission from group@php.net. You may indicate that your software works in conjunction with PHP by saying "Foo for PHP" instead of calling it "PHP Foo" or "phpfoo" 5. The PHP Group may publish revised and/or new versions of the license from time to time. Each version will be given a distinguishing version number. Once covered code has been published under a particular version of the license, you may always continue to use it under the terms of that version. You may also choose to use such covered code under the terms of any subsequent version of the license published by the PHP Group. No one other than the PHP Group has the right to modify the terms applicable to covered code created under this License. 6. Redistributions of any form whatsoever must retain the following acknowledgment: "This product includes PHP, freely available from < THIS SOFTWARE IS PROVIDED BY THE PHP DEVELOPMENT TEAM ``AS IS'' AND ANY EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE PHP DEVELOPMENT TEAM OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. This software consists of voluntary contributions made by many individuals on behalf of the PHP Group. The PHP Group can be contacted via at group@php.net. For more information on the PHP Group and the PHP project, please see < This product includes the Zend Engine, freely available at < This product includes software written by Tim Hudson (tjh@cryptsoft.com). Copyright (c) 2003, Itai Tzur <itzur@actcom.co.il> All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: Redistribution of source code must retain the above copyright notice, this list of conditions and the following disclaimer. Neither the name of Itai Tzur nor the names of other contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. Copyright (c) 1998, 1999, 2000 Thai Open Source Software Center Ltd Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWA Check Point Software Technologies Ltd. U.S. Headquarters: 800 Bridge Parkway, Redwood City, CA 94065, Tel: (650) Fax: (650) , info@checkpoint.com International Headquarters: 3A Jabotinsky Street, Ramat Gan, 52520, Israel, Tel: Fax: ,

5 Table Of Contents Introduction to Connectra The Need for Connectra 9 The Check Point Solution 10 Overview - What is Connectra? 10 How Connectra Works 11 Commonly Used Concepts 11 Connectra Security Features 13 Special Considerations 14 Planning Connectra Deployment 14 Administration Workflow 16 User Workflow 20 Connectra Administration Portal 22 Overview 22 Using the Administration Portal 22 Configuring Device, Network and Administrator Settings 25 Configuring Device and Network Settings 25 Configuring Administrator Settings 35 Defining Applications The Need for Defining Applications 37 The Check Point Solution 37 What is a Web Application? 38 What is a mail service 40 What is a File Share 44 Configuring Connectra Applications 44 Configuring Web Applications 44 Configuring Services 46 Configuring File Shares 50 Associating Applications with User Groups 51 Managing Users and Groups The Need for Managing Users and Groups 53 The Check Point Solution 53 Configuring Internal Users 54 Creating Internal Users 54 Creating Internal User Groups 55 Configuring External User Groups 57 Working with LDAP Groups 57 Working with RADIUS Servers 60 Authentication and Authorization The Need for Authentication and Authorization 63 The Check Point Solution 63 Table of Contents 5

6 Authenticating Users in Connectra 65 Authorization in Connectra 65 Configuring Authentication and Authorization 66 Configuring Authentication via LDAP 67 Configuring Authentication via RADIUS 68 Authentication via Certificates 69 SecurID 70 Configuring Protection Levels 71 Using Certificates The Need for Certificates 75 The Check Point Solution 75 Automatically Generated Server Certificate 76 Login with Client Certificate 76 Configuring Server Certificates 77 Installing a New Server Certificate 77 Configuring Client Certificates 79 Importing a Client Certificate to Internet Explorer 79 Client Certificate Verification 82 Security The Need for Security 83 The Check Point Solution 83 General Security Issues 84 Web Intelligence Protections 85 Client Side Security 86 Configuring Session Time-Outs 86 Configuring Web Intelligence 87 Configuring Malicious Code Protection 87 Configuring Application Layer Protection 89 Configuring HTTP Protocol Inspection 93 Updating SmartDefense and Web Intelligence 95 Using Client Side Security 95 Screened Software Types 96 Administrator Configuration of CV 97 End-User CV Experience 99 Status and Logging The Need for Status and Logging Information 103 The Check Point Solution 103 Status 104 Audit Log 105 Traffic Log 107 Configuring Logging 109 Setting Log Levels 109 Log Capacity 110 Remote Log Servers Customizing the User Portal 6

7 The Need for Customization 113 Customizing Look & Feel 113 Changing the Language 114 Changing the Title 114 Changing the Company Logo 114 Changing the Company s URL Troubleshooting SecurePlatform CLI Check Point SecurePlatform Overview 121 Managing SecurePlatform 121 Standard Mode 122 Expert Mode 122 Secure Shell 122 SecurePlatform Shell Commands 123 Expert Mode Command 123 Backup and Restore 123 Snapshot Image Management 124 Web Administration Server Control 125 Check Point Commands 126 Network Diagnostics Commands 126 Copying Files Using SCP 126 Configuration of Native Mail Clients Establishing Trust between Connectra and a SmartCenter Server On the remote SmartCenter server: 131 On the Connectra machine: 132 Table of Contents 7

8 8

9 CHAPTER 1 Introduction to Connectra In This Chapter The Need for Connectra page 9 The Check Point Solution page 10 Special Considerations page 14 Connectra Administration Portal page 22 Configuring Device, Network and Administrator Settings page 25 The Need for Connectra Giving remote users access to the internal network exposes the network to external threats. A balance needs to be struck between connectivity and security. In all cases, strict authentication is needed to ensure that only the right people gain access to the corporate network, and strong encryption methods are needed to guarantee user privacy. Remote Access VPN provides the following baseline functions for secure connectivity: User authentication and access control processing, either through its own internal database or reaching out to LDAP, RADIUS, or ACE servers. Privacy, Encryption guarantees user privacy. Data integrity, Encryption guarantees data integrity. There are two main technologies to provide Remote Access VPN, SSL (Secure Sockets Layer) and IPSec. Both enable secure connectivity for remote users to their home/office network. Both provide authenticated users with secure access to corporate 9

10 The Check Point Solution applications. However, depending on the network circumstances faced by the administrator, giving SSL access might be preferable to the overhead of maintaining client software. The Check Point Solution In This Section: Overview - What is Connectra? page 10 How Connectra Works page 11 Commonly Used Concepts page 11 Connectra Security Features page 13 Overview - What is Connectra? A dedicated appliance designed for use in existing networks, Connectra provides SSL VPN remote access capabilities, with integrated server and endpoint security. Connectra enables secure remote access to corporate applications that can be integrated with a firewall protected network. Connectra provides the remote user with a single point of access, using the SSL protocol, to corporate applications, primarily web applications, mail services and file shares, instead of requiring a separate access point for each application. Connectra presents a simple and user-friendly Web interface. Connectra provides Web connectivity with unmatched security. Connectra employs Web Intelligence to rapidly inspect all Connectra related network activity. Connectra functions as a Clientless SSL VPN server that: Takes advantage of an SSL capable browser to provide secure communication via the Internet. Employs SSL to provide the granular access control demanded for remote users. Leverages existing infrastructure (the Internet) to provide cheap, flexible connectivity. All connections to the Connectra Gateway from remote users are SSL encrypted to ensure privacy and data integrity. The connections are subject to authentication and authorization. In addition, Connectra protects the information and applications to which authenticated users have access by enforcing a set of security restrictions, both on the server and client side. 10

11 How Connectra Works How Connectra Works Connectra provides the remote user with access to the various corporate applications, primarily, web applications, mail services and file shares: A web application can be defined as a set of URLs that are used in the same context and that is accessed via a web browser, for example inventory management, or HR management. Connectra supports mail services including: Built-in webmail: Webmail services give users access to corporate mail servers via the browser. Connectra provides a web front for any server that supports the IMAP and SMTP protocols. Other web-based mail services, such as Outlook Web Access (OWA). Connectra relays the session between the client and the OWA server. Native mail applications: Connectra also supports non-http protocols, for example: SMTP/POP3 for native support. Connectra Native Mail utilizes a proxy mail server that terminates the SSL encrypted POP3 traffic, performs authentication, and relays the POP3 traffic to the POP3 mail server on the protected LAN. A file share defines a collection of files, made available across the network by means of a protocol, such as SMB for Windows, that enables actions on files, such as opening, reading, writing and deleting files across the network. Remote users initiate a standard HTTPS request to the Connectra Gateway, authenticating via username/password, certificates, or some other method such as SecurID. Users are placed in groups and these groups are given access to a number of applications. These applications may be file shares, web applications, or services associated with a protection level. Commonly Used Concepts This section briefly describes commonly used concepts that you will encounter when dealing with Connectra. Authentication All remote users accessing the Connectra portal must be authenticated by one of the supported authentication methods. As well as being authenticated through the internal Connectra database, remote users may also be authenticated via LDAP, RADIUS, ACE (SecurID), or certificates. Chapter 1 Introduction to Connectra 11

12 The Check Point Solution Authorization Authorization determines if and how remote users access the internal applications on the corporate LAN. If the remote user is not authorized, he/she will not be granted access to the services provided by the Connectra server. After being authenticated, the user will attempt to use an application. To access a particular application, the user must be authorized to do so. The user must belong to a group that has been granted access to the given application. In addition, the user must satisfy the security requirements of the application, such as authentication method. Client Verification Client Verification (CV) may be used to scan endpoint computers for potentially harmful software before allowing them to access the internal application. When end users access the User Portal for the first time, they are prompted to download an ActiveX component that scans the end user machine for Malware. The scan results are presented both to the Connectra and to the end user. Portal access is granted/denied to the end user based on the compliance options set by the administrator. Cookies Cookies, in the web browsing context, provide a way of maintaining state information between clients and servers. A cookie is a text file placed on the clients hard drive by the web server. Cookies contain information, such as login or registration information. Cookies issued by applications that are not security oriented, if stolen can reveal sensitive information or contain harmful code. Protection Levels Protection levels are introduced in order to balance between connectivity and security. The protection level represents a security criterion that must be satisfied by the remote user before access is given. For example, an application may have a protection level, which requires users to satisfy a specific authentication method. Out of the box, Connectra has three pre-defined protection levels standard, high, and advanced, with standard being the weakest and advanced the strongest. Session Once authenticated, remote users are assigned a Connectra session. The session provides the context in which Connectra processes all subsequent requests until the user logs out, or the session ends due to a time-out. Each session has two configurable time-outs: Passive time-out. If the connection remains idle for this period, the session is terminated. 12

13 Connectra Security Features Active time-out. The maximum length of session. When this period is reached, the user must login once more. Connectra Security Features Greater access and connectivity demands a higher level of security. The Connectra security features may be grouped as server side security and client side security. Server Side Security Highlights The following list outlines the security highlights and enhancements available on the server side: 1 Check Point Web Intelligence enables protection against malicious code transferred in web-related applications: worms, various attacks such as Cross Site Scripting, buffer overflows, SQL injections, Command injections, Directory traversal, and http code inspection. 2 Connectra provides a granular authorization policy, limiting which users get access to which applications by enforcing authentication, encryption, and client security requirements. 3 Connectra provides application support over HTTPS for web-based applications, file shares, and mail support. Access is allowed for a specific application set rather than full network-level access. 4 Connectra maintains a separate portal for administrators. 5 Connectra employs FireWall-1 technology, providing Check Point FireWall-1 security features, and using secure code and infrastructure. 6 The operating system used by Connectra is the hardened Check Point operating system: SecurePlatform. Client Side Security Highlights The following list outlines the security highlights and enhancements available on the client side: 1 Connectra implements Secure Configuration Verification of the remote user s machine, preventing threats posed by Malware types, such as Worms, Trojan horses, Hacker's tools, Key loggers, Browser plug-ins, Adwares, Third party cookies, and so forth. Chapter 1 Introduction to Connectra 13

14 Special Considerations 2 Connectra controls browser caching. You decide what web content may be cached by browsers, when accessing web applications, associated with a given protection level. Disabling browser caching can help prevent unauthorized access to sensitive information. 3 Connectra captures cookies sent to the remote client by a web server. Cookies provide a way of maintaining state information between clients and servers. If cookies are stolen they may be used to impersonate a user. For this reason, Connectra captures the cookies and maintains them on the server. Connectra simulates user/web server cookie transmission by appending the cookie information, stored on Connectra, to the request that Connectra makes to a web server, in the name of the remote user. 4 Connectra supports strong authentication methods using SecurID tokens and SSL client certificates. Special Considerations In This Section: Planning Connectra Deployment page 14 Administration Workflow page 16 User Workflow page 20 Planning Connectra Deployment In This Section: Deployment Overview page 14 Deploying Connectra in the DMZ page 15 Deploying Connectra on the LAN page 16 Deployment Overview In general, it is recommended to deploy Connectra in the DMZ. Connectra can, however, also be deployed in other configurations, such as on the internal LAN. In both scenarios, SSL termination takes place at the Connectra Gateway. Web Intelligence on the Connectra Gateway inspects the traffic for harmful content before it reaches the internal servers. 14

15 Planning Connectra Deployment Deploying Connectra in the DMZ FIGURE 1-1 shows a typical Connectra deployment in the DMZ: FIGURE 1-1 Connectra deployment in the DMZ When Connectra is placed in the DMZ, sensitive applications are decoupled from remote users. Remote users initiate an SSL connection to the Connectra Gateway. The firewall should be configured to allow traffic from the user to the Connectra server, where SSL termination and web security inspection takes place. Requests are then forwarded to the internal servers, via the firewall, which inspects the traffic for harmful content. Internal requests from Connectra to LAN web servers can also be SSL encrypted. Chapter 1 Introduction to Connectra 15

16 Special Considerations Deploying Connectra on the LAN Connectra can be deployed on the LAN along side the internal servers, as shown in FIGURE 1-2: FIGURE 1-2 Connectra on the LAN The remote user opens a browser and initiates an HTTPS request to the Connectra server. The SSL connection is terminated within the LAN, and the clear text requests forwarded to the internal servers. The internal servers reply in the clear to Connectra, which encrypts the back connection to the remote user. In the scenario shown in FIGURE 1-2, the perimeter firewall must be configured to allow encrypted SSL traffic to Connectra. Administration Workflow In This Section: Deploying Connectra page 17 Configuring Connectra page 19 Auditing Using Logs page 20 The administration workflow comprises the following steps: 1 Deploying Connectra, and configuring the firewall access rules 2 Configuring Connectra 3 Auditing using logs 16

17 Administration Workflow Deploying Connectra After installation, the administrator must perform initial configuration and deployment of Connectra. Planning Connectra Deployment In general, it is recommended to deploy Connectra in the DMZ. Connectra can, however, also be deployed in other configurations, such as on the internal LAN. The LAN protecting firewall should be configured accordingly. For more detailed information, refer to Deploying Connectra in the DMZ on page 15 and Deploying Connectra on the LAN on page 16. Configuring the Firewall Access Rules Configure the firewall according to the chosen deployment. The exact rules depend on your setup, for example, for VPN-1 Pro, a typical Security Rule Base configuration is as follows: To deploy Connectra in a DMZ The following rules apply to the deployment shown in Figure 1-1, Connectra deployment in the DMZ, on page 15. Chapter 1 Introduction to Connectra 17

18 Special Considerations TABLE 1-1 Example Rules for deploying connectra in the DMZ Rule Source Destination Service Action Comment 1 Admin host Connectra HTTPS/4433 Accept Administrator access. (encrypted) 2 Any Connectra HTTP/80 HTTPS/443 3 Connectra LAN HTTP/80 HTTPS/443 IMAP/143 POP3/110 nbsession/tcp port 139 microsoft-ds/ TCP port 445 nbdatagram /UDP port 138 nbname/udp port Any Connectra POP3/110 POP3-SSL/995 SMTP/25 SMTP-SSL/465 5 Connectra LAN POP3/110 SMTP/25 Accept Accept Accept Accept Other rules may well be needed, depending on the configuration: End user access to portal for Web applications, File sharing Web mail. HTTP is only for redirection. All actual communication is encrypted. Connectra to LAN for Web applications (encrypted) File sharing (unencrypted) Web mail (unencrypted) End user access for native mail clients (both encrypted and unencrypted). Connectra to LAN for native mail clients (unencrypted) Connectra requires access to DNS servers and possibly to WINS servers For backups, Connectra may need access to a TFTP or SCP server. 18

19 Administration Workflow To send logs to a remote log server, Connectra may need access to the SmartCenter Server or to a Customer Log Module (CLM). For authentication, Connectra may need access to LDAP, RADIUS and ACE servers. For clock synchronization, Connectra may need access to an NTP server. To deploy Connectra in a LAN If you choose to deploy Connectra in the LAN: Rules 3 and 5 are not needed. In Rules 2 and 4, make the Source: Any and Destination: LAN. Configuring Connectra This section discusses initial configuration and managing access. Initial Configuration of Connectra Connectra requires only minimal user input of basic configuration elements, such as IP addresses, routing information, etc. The initial configuration of Connectra must be performed using a First-Time Configuration Wizard. Configure the Network Connections, Routing Table, DNS Servers, Host and Domain Name and Device Date and Time Setup windows. In order to complete the initial configuration, Connectra software components must be initialized. This process may take several minutes. The administration portal is then used to further configure Connectra. Managing Access Access management in Connectra is accomplished by defining users and assigning them to groups, and defining applications and associating those applications with the groups. In addition, Connectra associates each application with a protection level, that is a security requirement that the remote user must satisfy before being given access to the application. Defining Users and Groups Access to internal corporate applications is based on group membership. To access a particular application, remote users must belong to a group with the relevant authorization (as well as satisfy the security requirements of the application). These groups can be defined on Connectra s internal user database, or on external databases. The LDAP group can be a branch in a tree, or an administrator defined LDAP group that contains users from different branches. Defining Applications and Associating them with Groups Chapter 1 Introduction to Connectra 19

20 Special Considerations Defining an application is about deciding which internal LAN applications to expose to remote users. Typically: Web applications servers File shares The administrator must configure the applications and associate them with groups. This association means authorizing certain user groups to use those applications. Setting Protection Levels for Applications Connectra associates each application with a protection level. The protection level is a security requirement that the remote user must satisfy before being given access to the application. For example, the user must be authenticated using a certificate. Auditing Using Logs Using Connectra s logging capabilities, the administrator can monitor and analyze network activity of remote users. Connectra s integrated log viewer enables powerful filtering of logs, in order to easily locate specific events. User Workflow In This Section: Signing In page 20 Initial Setup page 21 Accessing Applications page 21 The user workflow comprises the following steps: 1 Signing In 2 Initial Setup 3 Accessing Applications Signing In Using a browser, the user types in the URL, assigned by the system administrator, for the Connectra Gateway. The user enters his User Name and Password and clicks Sign In. Before Connectra gives access to the applications on the LAN, the credentials of remote users are first validated. Connectra authenticates the users either through its 20

21 User Workflow own internal database, LDAP, RADIUS or RSA ACE/Servers. Once the remote users have been authenticated, and associated with Connectra groups, access is given to corporate applications such as internal LAN web servers, servers, and file shares. NOTE: If the Client Verification feature is enabled, the user may be required to pass a verification scan on his/her computer, before being granted access to the Connectra Sign In page. Initial Setup The user may be required to configure certain settings, such as credentials for file shares and mail services. In addition, the user can define favorites for web applications and file shares. Accessing Applications After the remote users have logged onto the Connectra Gateway, they are presented with a portal, which enables access to all the internal applications that the administrator has configured as available from within the organization: FIGURE 1-3 Connectra Portal Chapter 1 Introduction to Connectra 21

22 Connectra Administration Portal Connectra Administration Portal Overview In This Section: Overview page 22 Using the Administration Portal page 22 Connectra enables secure access to remote users, requiring only minimal user input of basic configuration elements, such as IP addresses, routing information, etc. An easy to use Web interface, the Administration portal, enables you to configure Connectra, thereby managing access to corporate applications via Connectra, and to audit Connectra performance and usage, via logs and status displays. Using the Administration Portal In This Section: Accessing the Administration Portal for the First Time page 22 Logging-In to the Connectra Administration Portal page 23 The Connectra Administration Portal page 24 The following sections describe how to access the portal for the first time and how to login to the Connectra Administration Portal. In addition, it introduces you to the Administration Portal features, with which you will configure Connectra. Accessing the Administration Portal for the First Time When accessing the Administration Portal for the first time, proceed as follows: 1 To access the Administration Portal, make an SSL connection from a browser to the default management IP address: and press Enter. 2 The license agreement appears. To accept it, press I Accept. 3 The login window appears. Login with the default system administrator username/password: admin/admin, and press Login. 22

23 Using the Administration Portal 4 Change the administrator password, as prompted. The First-Time Configuration Wizard begins to run. Note - You must run the First Time Configuration Wizard. If you change the machine's IP, not via the administration GUI, (e.g. using the sysconfig utility) the status screen will appear blank. 5 Configure the Network Connections, Routing Table, DNS Servers, Host and Domain Name and Device Date and Time Setup windows. 6 Initialize Connectra software components, in order to complete the initial configuration. For more information, refer to the Connectra Getting Started Guide. Logging-In to the Connectra Administration Portal To Login to the Connectra Administration Portal: 1 From a web browser, connect to the administration interface, at IP address>:4433. The default administration IP address is Login using the administrator user name and password. NOTE: It is strongly recommended, that you create a backup of the system, at this stage, using the Settings > Device > backup page. To restore the system, use the restore shell command, from the appliance. For details see the command usage, or refer to Chapter 12: Command Line Interface. Chapter 1 Introduction to Connectra 23

24 Connectra Administration Portal The Connectra Administration Portal The Administration Portal is used to configure Connectra. FIGURE 1-4 shows the portal: FIGURE 1-4 The Administrator Management Portal TABLE 1-2 summarizes the Administration Portal functional areas: TABLE 1-2 Administrator Portal Functional Areas Menu Purpose 1. Status and Logs View status and audit traffic logs, adjust local and remote log server settings. 2. Security Configure Web Intelligence protections to protect web applications, and configure client verifications to scan endpoint computers for potentially harmful software before allowing them access. You can set Session Timeouts, configure and update Web Intelligence, configure Client Verification and set Protection Levels. 3. Applications Define internal LAN applications (such as Web applications, servers and File shares) which can be made available to remote users. 24

25 Configuring Device and Network Settings TABLE 1-2 Administrator Portal Functional Areas Menu Purpose 4. Users and Groups Configure user groups, define the applications for the groups, and assign users to the groups. Authenticated users can only access an application if they belong to the appropriate user group or groups, and satisfy the security restrictions of the application. 5. Administrators Create a Connectra administrator, define a permissible network for administrators and configure administrator session parameters. 6. Settings Configure device and network settings, server certificate and the portal look and feel. Configuring Device, Network and Administrator Settings In This Section: Configuring Device and Network Settings page 25 Configuring Administrator Settings page 35 Configuring Device and Network Settings Connectra may be configured, by using, primarily, the options listed under Device and Network, on the navigation tree. In addition, a Connectra administrator can be created by using the Manage option, listed under Administrators. For more information, refer to the SecurePlatform Users Guide. The Device options are listed below: Control Licenses Date and Time Backup Upgrade Servers The Network options are listed below: Http Proxy Connections Routing DNS Servers Chapter 1 Introduction to Connectra 25

26 Configuring Device, Network and Administrator Settings Domain Hosts WINS Servers The Administrators options are listed below: Allowed IPs Manage Settings Device Options In This Section: Device Control page 26 Adding a License page 27 Configuring the Date and Time page 27 Backup and Restore page 28 Upgrade page 29 Controlling Server IPs and Ports page 29 To configure SecurePlatform you must set the options, listed under Device. Device Control To view the active processes running on SecurePlatform: On the navigation tree, select Settings > Device > Control. The Device Control page appears. The Processes pane lists all running processes. To stop and start SecurePlatform and the Connectra processes installed on SecurePlatform: Click Device Control. The Device Control drop-down list appears. You can: Start Connectra processes Restart Connectra processes Stop Connectra processes Reboot device Shutdown device Download diagnostic file 26

27 Configuring Device and Network Settings Adding a License The Connectra appliance has a pre-configured permanent license that corresponds to the model you purchased. Connectra is designed specifically for SSL remote access and is available in three models to support the performance needs of different remote access deployments: Connectra 1000, 2000 and If the usage of the appliance exceeds the terms of the license, you may purchase a suitable license from the checkpoint user-center: To add a license: 1 Obtain a license from: 2 On the navigation tree, select Settings > Device > Licenses. The Licenses page appears. 3 On the Licenses page, click New. The Add License page appears. 4 Paste in the following license details, using Paste License, or add them manually: IP Address Expiration Date SKU / Features Signature Key 5 Click Apply. NOTE: Using the command line interface, you can use the CPLIC commands to install and obtain information about your license. For example, use cplic printlic to view license details, and cplic putlic to install the license. For more information, refer to the FireWall-1 and SmartDefense User Guide. Configuring the Date and Time To configure the date and time: 1 On the navigation tree, select Settings > Device > Date and Time. The Device Date and Time Setup page appears. 2 On the Device Date and Time Setup page, enter the date and time manually, or configure a Primary NTP Server. 3 Click Apply. Chapter 1 Introduction to Connectra 27

28 Configuring Device, Network and Administrator Settings Backup and Restore The Connectra backup mechanism enables exporting snapshots of the entire dynamic configuration. Exported configurations can later be imported in order to restore a previous state in case of failure. The mechanism is also used for seamless upgrades of the software. The information backed up includes: All settings performed by the Admin GUI Network configuration data Database of user settings (personal favorites, credentials, cookies etc.) Two common use cases are: When the current configuration stops working, a previous exported configuration may be used in order to revert to a previous system state. Upgrading to a new Connectra version. The procedure would include: Backing up the configuration of the current version Installing the new version Importing the backed up configuration Backup can be performed in configurable schedules. To view the Scheduling Status: On the navigation tree, select Settings > Device > Backup. The Backup page appears. The Scheduling Status pane displays the following information: Enabled Backup to Start at Recur every To restore the backup, run the restore shell command from the device. The available options are: Restore local backup package Restore local backup package from TFTP server Restore local backup package from SCP server To schedule a backup: 1 On the Backup page, click Scheduled backup. The Scheduled backup page appears. 2 Select the Enable backup recurrence checkbox. 28

29 Configuring Device and Network Settings 3 Set up the backup schedule. 4 Select a device to hold the backup. The options include the current SecurePlatform, a TFTP Server (Trivial File Transfer Protocol: A version of the TCP/IP FTP protocol that has no directory or password capability), or an SCP Server (SCP is a secure FTP protocol). 5 Click Apply. To execute a backup: Click Backup now. To view the backup log: Click View backup log. The Backup Log page appears. Upgrade To upgrade your device: 1 On the navigation tree, select Settings > Device > Upgrade. The Upgrade page appears. 2 Download an upgrade package, as directed. 3 Select the upgrade package file. 4 Click Upload package to device. 5 Select either Safe Upgrade or Double-Safe Upgrade. If you selected Double-Safe Upgrade, your browser will automatically try to perform the first login immediately after the upgrade, within the time interval that you set. To enable that, you should not close the Upgrade page, and not browse to any other page. Otherwise, you will have to login manually before the above interval expires. 6 Click Start Upgrade. The Upgrade Status pane provides information such as Action, Start Time, Status and Details. Controlling Server IPs and Ports The IPs and ports, used, are configurable. Use this section to configure the listening IP and port of the portal and administration servers. To view which servers Connectra is currently running: Chapter 1 Introduction to Connectra 29

30 Configuring Device, Network and Administrator Settings 1 On the navigation tree, select Settings > Device > Servers. The Servers page appears. There are three servers: Portal redirect port: A server which redirects requests from port 80 to port 443, or 4433 Portal SSL: The server that provides the user portal Administration Server: The server that provides the administration portal 2 Select a specific server. The Internal Server Definition page for that server appears. You can manually configure the Portal SSL and the Administration servers. The Portal redirect port server can not be configured manually. 3 Enter a port and address and click Apply. NOTE: If you change the Portal SSL IP, the Portal redirect port server parameters change automatically. Network Options In This Section: Defining an HTTP Proxy page 30 Configuring a Network page 31 Configuring Routing page 33 Defining a DNS Server page 33 Configuring a Domain page 34 Hosts page 34 Defining WINS Servers page 34 To configure Connectra s connectivity to the network, you must set the options, listed under Network. Defining an HTTP Proxy An HTTP Proxy can be used by Connectra to access internal and external web servers. An HTTPS Proxy can be used by Connectra to access sites secured by SSL. To define an HTTP Proxy: 1 On the navigation tree, select Settings > Network > Http Proxy. The HTTP Proxy page appears: 30

31 Configuring Device and Network Settings FIGURE 1-5 HTTP Proxy page NOTE: You should specify separate proxies for HTTP and HTTPS. 2 Select Proxy for HTTP and enter the proxy name, or IP address and port, for example proxy.mycompany.com: Select Proxy for HTTPS and enter the proxy name, or IP address and port. 4 Click Apply. Configuring a Network You may configure the (primary) IP and network mask of each interface. You may also configure additional (secondary) IPs on each interface. Primary IPs may be configured to be obtained automatically using DHCP. This option is not recommended for deployment in a production environment. The initial management interface of all three Connectra models is shown in the following figure: The logical name of the initial management interface is always eth0. Chapter 1 Introduction to Connectra 31

32 Configuring Device, Network and Administrator Settings FIGURE 1-6 Initial Management Interface of all three Connectra models There are two tasks to perform in the configuration of an interface: Task 1: Configure the primary IP of an interface Task 2: (Optional) Add a secondary IP to an interface. To configure the primary IP of an interface: 1 On the navigation tree, select Settings > Network > Connections. Each interface can be associated with a primary IP and optionally with one or more secondary IPs. NOTE: This page displays a list of all physical NICs that are on the appliance. 2 Click on a specific interface. The Edit Connection page appears. 3 If you enable Use the following configuration, enter the IP address and Netmask. 4 If you enable Obtain IP address automatically (DHCP), the primary IPs are obtained automatically using DHCP. 5 Click Apply. To add a secondary IP to an interface: 1 On the Network Connections page, click New. The Add Network Connections drop-down box is displayed. The options are: Secondary IP PPTP PPPoE VLAN 32

33 Configuring Device and Network Settings 2 Select Secondary IP. The Add Secondary IP Connection page appears. 3 On the Add Secondary IP Connection page: Select an interface from the drop-down box Supply an IP address Supply a network mask 4 Click Apply. Configuring Routing You can add a static route or default route via the administration portal. To configure routing: 1 On the navigation tree, select Settings > Network > Routing. The Routing Table page appears. 2 On the Routing Table page, click New. The Add Route drop-down box is displayed. The options are: Route Default Route 3 Select Route. The Add New Route page appears. 4 On the Add New Route page, supply a: Destination IP Address Destination Netmask Gateway Metric 5 Click Apply. Defining a DNS Server Domain Name resolution is handled using the following methods: lmhosts (manual name resolution) DNS WINS Broadcast (only works within LAN) To configure DNS Servers: Chapter 1 Introduction to Connectra 33

34 Configuring Device, Network and Administrator Settings 1 On the navigation tree, select Settings > Network > DNS Servers. The DNS Servers page appears. 2 On the DNS Servers page: Provide IP addresses for up to three DNS servers, and click Apply. NOTE: Changes in the DNS configuration will take effect only after restarting all Connectra processes, which can be performed via the Device Control page. Configuring a Domain To configure a domain: 1 On the navigation tree, select Settings > Network > Domain. The Host and Domain Name page appears. 2 On the Host and Domain Name page: Supply a Hostname for the Connectra Gateway. Supply a Domain name for the Connectra Gateway. Select an interface from the drop-down box, and click Apply. Hosts The host file stores Connectra s name and IP address for DNS resolution. To add additional host names and IP Addresses: 1 On the navigation tree, select Settings > Network > Hosts. The Local Hosts Configuration page appears: 2 On the Local Hosts Configuration page, click New. The Add Host page appears. 3 Enter the new host name and IP address 4 Click Apply. Defining WINS Servers If your network includes Windows NT or 2000 systems, it is necessary to support WINS Domain Name resolution. If you enable LMHosts lookup, the system will check if an lmhosts file exists. You can configure up to three WINS servers to be used for host name resolution for accessing remote file shares (SMB/CIFS). To configure WINS Servers: 1 On the navigation tree, select Settings > Network > WINS Servers. The WINS Servers page appears. 34

35 Configuring Administrator Settings 2 On the WINS Servers page: Provide IP addresses for up to three WINS servers, and click Apply. Configuring Administrator Settings In This Section: To create a Connectra administrator, define a permissible network for administrators and configure administrator session parameters, you must set the options, listed under Administrators. Defining Allowed IP Address for Administrators To successfully login to Connectra, an administrator must do so from a permitted network or host. If you have selected a network, the base IP address of this network and network mask must be defined beforehand. If you have selected a host, the base IP address of this host must be defined beforehand. Out-of-the-box, administrators may connect to the Administration Portal from any source IP. You may limit access of administrators to specific IPs or networks. NOTE: SSH access to the Connectra appliance is also governed by this setting. To define a permissible network for administrators: 1 On the navigation tree, select Administrators > Allowed IPs. The Allowed Administrator Addresses page appears. 2 In the Access Scheme panel, select either Allow any address or Allow specific addresses. 3 If you select Allow specific addresses, click Specify. The Specific Allowed Addresses page appears. 4 Click Add. The New Allowed Addresses page appears. 5 If you select Host, enter the IP address 6 If you select Network, enter the IP address and network mask of the allowed network. 7 Click OK. Defining Allowed IP Address for Administrators page 35 Creating Connectra Administrators page 36 Settings page 36 Chapter 1 Introduction to Connectra 35

36 Configuring Device, Network and Administrator Settings Creating Connectra Administrators To create a Connectra administrator: 1 On the navigation tree, select Administrators > Manage. The Administrator Configuration page appears. 2 On the Administrator Configuration page, click New. The Add New Administrator page appears. 3 Provide a name and a password for the Connectra administrator. 4 Click Apply. To download a One Time Login Key: Click Download. NOTE: The One Time Login Key will be required in case you forget your password. Save this file on a diskette, and keep it in a safe place. Settings To configure administrator session parameters: 1 On the navigation tree, select Administrators > Settings. The Administrator Security Settings page appears. 2 Set the Administrator Session Timeout value. 3 In the Administrator Login Restrictions area, enable and set the Lock Administrator s account after <x> login failures. 4 Set the Unlock Administrator s account after <y> minutes. 5 Click Apply. 36

37 CHAPTER 2 Defining Applications In This Chapter The Need for Defining Applications page 37 The Check Point Solution page 37 Configuring Connectra Applications page 44 The Need for Defining Applications Giving remote users access to the internal network exposes the network to external threats. A balance needs to be struck between connectivity and security. In all cases, strict authentication is needed to ensure that only the right people gain access to the corporate network. Defining an application is about deciding which internal LAN applications to expose to what kind of remote user. The Check Point Solution In This Section What is a Web Application? page 38 What is a mail service page 40 What is a File Share page 44 Connectra provides secure remote access to a set of application, available on the corporate LAN. Typically, the application types for which remote access is required are: Web applications services File shares 37

38 The Check Point Solution What is a Web Application? A web application can be defined as a set of URLs that are used in the same context and that is accessed via a web browser, for example inventory management or HR management. Alternatively, a web application can be defined as a particular path within the same URL; partial URLs Domain Names, such as *.checkpoint.com, or or specific ports. The web application uses HTTP for its core communication protocol and delivers web-based information to the user in HTML format. In this way, a web application is a collection of components that: Provides a Query Interface Transmits the Query to a web server Performs Server Side Processing Manipulates data in accordance with the user s request Transmits return Results Displays the results to the user In the simplest case, a user initiates an HTTP request to a web browser, specifying an HTML document, which the server returns and the browser displays. There are web sites that require authentication. Connectra supports basic, digest and NTLM authentication methods. When the user attempts to access these sites the HTTP Authentication Request page appears: FIGURE 2-1 HTTP Authentication Request The user must enter his/her Username and Password and click OK. NOTE: Connectra rejects Java applets that attempt to make direct to HTTP or HTTPS connections. Connectra Web Applications Connectra web applications can be narrowly or broadly defined (See Broader Versus Narrow Definitions). A web application is generally a collection of URLs. 38

39 What is a Web Application? When creating a Connectra web application, you give the application a name, define hosts, ports, paths, and a protection level. (See Configuring Protection Levels on page 71) For example: TABLE 2-1 Any web site Name Host Ports Paths Protection Any web site Any 80 Any Low The definition in TABLE 2-1 turns the Internet into a single web application. NOTE: To allow browsing on the Internet, the administrator must define the Internet as a single web application. TABLE 2-2 Single web site Name Host Ports Paths Protection Example example.com 80,443 Any Low The definition in TABLE 2-2 turns the example website into a single web application. The same destination with a different protection level constitutes a separate web application: TABLE 2-3 Same host, different protection Name Host Ports Paths Protection Example example.com 80,443 Any High Broader Versus Narrow Definitions Whether to broadly or narrowly define an application depends on the nature of the application. Obviously, it makes sense to define sensitive applications as narrowly as possible. A narrowly defined application will take longer to deploy and require greater maintenance, yet results in greater security. Also, narrow definitions allow remote users deeper access into an organization, providing a trusted user with secure access to all the applications that an individual needs to be productive. Less sensitive applications can be broadly defined, deployed quickly, and require less maintenance. However, a lower level of security results, since more remote users will have access to the application. Chapter 2 Defining Applications 39

40 The Check Point Solution What is a mail service A mail service enables users to use their accounts from where ever they are, as shown in the following figure: FIGURE 2-2 Connectra mail services There are 3 types of mail services enabled by Connectra. Connectra Services Connectra supports built-in webmail, other web-based mail services, such as Outlook Web Access (OWA), and native mail applications. Built-in webmail provides a simple way for remote users, through a web browser interface, to access their and address books. Employees can access their from any computer that has access to the Internet, such as a computer in a library, or internet cafe. There is no need to install special or remote access software. This is helpful for employees who work outside the office on a regular basis. If employees want to quickly read and send mail, Connectra webmail is fine. However, since mail is not actually downloaded to the machine, the user must be constantly connected. For longer mails that require some thought, the better option would be to use a native client and download the mail for later consideration. The employee might prefer a more sophisticated webmail product, such as Outlook Web Access (OWA), which contains capabilities such as group calendars. However, OWA is limited to Microsoft Exchange Servers, whereas Connectra webmail is compatible with all mail web servers. 40

41 What is a mail service While the Connectra portal offers a web interface, many users will prefer to take advantage of their native clients, for example: Outlook, Netscape, or Eudora. Connectra s native mail feature supports encrypted mail connectivity from the Internet to the internal domain, leveraging the ability of the most common mail clients to work with SSL. Built-in Webmail Built-in webmail gives users access to corporate mail servers via the browser. Connectra provides a web front for any server that supports the IMAP protocol. The remote user initiates an HTTPS request to the Connectra Gateway. Connectra uses the IMAP and SMTP mail protocols to access the mail server. In Connectra, users securely connect to an IMAP account. IMAP is a mail protocol which provides a way of accessing electronic mail kept on one or more mail servers. stored on the IMAP server is manipulated through the browser interface without having to transfer the messages back and forth. Users can connect to several mail servers depending on the groups to which they belong. The remote user initiates an HTTPS request to the Connectra web server and views the Connectra Portal. Users are presented with a login screen and must authenticate themselves before being given access to the portal. Since Connectra handles the login procedure, credentials can be automatically reused when authenticating to the mail server. If the reused credentials are incorrect, Connectra again presents the user with a login screen. Correct credentials are saved for future logins. From the portal, the user navigates to the webmail page. Using the mail pages, the user sends and receives . Once authenticated, users can not only compose, send and receive but also: Create, delete, rename, and manipulate mail folders Index messages in various ways Stores addresses Search s according to various criteria, such as body text, subject, sender s address, etc. Highlight messages with different background colors, enabling quick differentiation Display preferences Chapter 2 Defining Applications 41

42 The Check Point Solution Special Considerations Connectra webmail is based on SquirrelMail, a PHP-based open source web mail interface. For Connectra: A number of default file permissions have been changed Configuration settings are no longer stored on config.php but managed by the Connectra gateway. Currently, there is no mechanism that cleans the directory where attachments are sometimes stored Customizing the GUI for webmail is not currently available. Attachments over 2MB in size cannot currently be sent LDAP cannot be configured as an address book for webmail users. Outlook Web Access Connectra supports Outlook Web Access (OWA). OWA is a Web-based mail service, with the look, feel and functionality of Microsoft Outlook. It provides a Web environment for users to access Exchange data, via an Internet browser. OWA combines the usability of Microsoft Outlook with the ease of operation of a browser. NOTE: Outlook Web Access is designed to work with any browser that supports HTML version 3.2 and JavaScript. Outlook Web Access provides most of the advantages of Microsoft Outlook messaging while using an Internet browser. OWA functionality encompasses basic messaging components such as , calendaring, and contacts. Native mail While the Connectra portal offers a web interface, many users will prefer to take advantage of their native clients, for example: Outlook, Netscape, Eudora. Connectra s native mail feature supports encrypted mail connectivity from the Internet to the internal domain, leveraging the ability of the most common mail clients to work with SSL. Connectra runs its own proxy mail server. The Connectra proxy mail server terminates the SSL encrypted POP3 traffic, performs authentication, and relays the POP3 traffic to the POP3 mail server on the protected LAN. In this way, remote users are able to access their mail account within the protected domain using their standard client. The same applies when mail is sent using SMTP. 42

43 What is a mail service The User activates a mail client and sends/receives mail. The mail client establishes a secure SSL connection with the Native Mail (NM) Proxy. The NM proxy comprises a proxy server and a proxy client. The NM proxy server communicates with the mail client via an SSL connection. Upon successful authentication, the NM proxy client communicates with the mail server via a SMTP/POP3 clear connection. To utilize the Native Mail feature, the end user must configure the desired mail client. See Configuration of Native Mail Clients. Supported Mail Clients and Servers The following mail clients are supported: On PC/Windows: Outlook Express/Outlook Eudora Mozilla Netscape On Linux: Pine Mutt Fetchmail On Macintosh: OSX Mail (comes with the OSX install) Entourage (Microsoft) Eudora (OS 8 or 9 only) Mozilla Netscape The following mail servers are supported: Exchange 2000 Exchange 2003 Exchange 5.5 Sendmail One of the following options will be selected for mail server configuration: Static configuration - The mail server must be configured to accept clear connections. Dynamic configuration - Connectra will supply the mail server's encryption/authentication configuration to the Native Mail proxy per user. Chapter 2 Defining Applications 43

44 Configuring Connectra Applications What is a File Share A file share is a file made available across the network by means of a file sharing protocol. A file sharing protocol is a high-level network protocol that provides commands for actions, such as opening, reading, writing, copying and moving files across the network (also known as a client/server protocol ). In order for a client to have access to multiple servers running different operating systems, either the client supports the file sharing protocol of each operating system or the server supports the file sharing protocol of each client. The most common file sharing protocol is Server Message Block (SMB) for the Windows operating system. Connectra supports Windows file shares using the SMB file system protocol. The user interface for file shares is based on web DAV, and requires Internet Explorer. Configuring Connectra Applications In This Section: Configuring Web Applications page 44 Configuring Services page 46 Configuring File Shares page 50 Associating Applications with User Groups page 51 Configuring Web Applications To configure Web applications: 1 On the navigation tree, click Applications > Web Applications. The Web Applications page opens. 2 Click New. The Add/Edit Web Application page appears. The Application, Security and Specification sections are displayed in the following figure: 44

45 Configuring Web Applications FIGURE 2-3 Add/Edit Web Application page 3 Enter: A name for the web application, such as my_web_application A protection level A resolvable host name, for example, List of available ports, separated by a comma 4 If the definition needs to be narrowed, in Paths, click Configure. The Web Application Paths page appears. 5 Click New. The Add/Edit Path page appears. FIGURE 2-4 Add/Edit Path page NOTE: There are cases in which the Web server requires the path to be case sensitive. Then, select Paths are case sensitive. 6 Define a path, for example, /finance/data/, and click OK. The Portal Favorite section is displayed in the following figure: Chapter 2 Defining Applications 45

46 Configuring Connectra Applications FIGURE 2-5 Portal Favorite section 7 Select Enable Favorite and enter the URL, Display name and Tooltip for the web application that you are designating as a favorite. 8 Click Apply. Configuring Services To configure all Mail Services 1 On the navigation tree, click Applications > Mail Services. The Mail Services page appears. 2 Click New. The Mail Services drop-down list appears. The options are Mail Service and Outlook Web Access. To configure the Native Mail and Webmail Mail Services 1 If you select Mail Service, the Add/Edit Mail Service page appears. The Mail Service Details, Security and SMTP Server sections are shown in the following figure: FIGURE 2-6 Add/Edit Mail Service page 2 In the Mail Service Details section, supply: A name for the mail server, for example, my_mail_server 46

47 Configuring Services A display name 3 In the Security section, supply: A protection level 4 In the SMTP Server section, supply: A host name, for example, A port number for mail traffic NOTE: SMTP is required for built-in webmail and for native mail, but not for OWA. The Incoming Mail Server and Credentials sections are shown in the following figure: FIGURE 2-7 Incoming Mail Server and Credentials sections 5 In the Incoming Mail Server section supply: A mail protocol, IMAP or POP3 Host name NOTE: The Port is automatically set, based on your mail protocol selection. 6 If the incoming mail protocol was set to POP3, native mail is set as the Mail Service Usage, as shown in FIGURE 2-7. NOTE: You can configure multiple Native Mail services. 7 If the incoming mail protocol was set to IMAP, web-mail is set as the Mail Service Usage, as shown in the following figure: Chapter 2 Defining Applications 47

48 Configuring Connectra Applications FIGURE 2-8 Webmail Configuration 8 If the incoming mail protocol was set to IMAP, enter a mail domain and select an IMAP server type from the drop-down box. 9 In the Credentials section, specify whether to reuse portal credentials, or to prompt the user for credentials. 10 If the User Name and Password to access the mail account are identical to those used to access the Connectra Portal, select Reuse portal credentials. 11 If the User Name and Password to access the mail account are different than those used to access the Connectra Portal, for example, if Pete is the User Name, used to access the Connectra Portal and Peter is the User Name, to access the mail account, select Prompt user for credentials. Enter the User Name and Password. 12 Click Apply. 48

49 Configuring Services To configure Outlook Web Access 1 If you select Outlook Web Access, the Add/Edit Web-Access Server page appears: FIGURE 2-9 Add/Edit Web-Access Server page 2 In the Application section, supply: A name for the mail server A display name 3 In the Security section, supply: A protection level 4 In the Server section: Enter a host name, for example, owa.mycompany.com Select either Enable clear (HTTP) access to OWA server or Enable SSL (HTTPS) access to OWA server 5 In the Application paths section, supply: Private Mailboxes Public Folders Graphics and Controls 6 Click Apply. Chapter 2 Defining Applications 49

50 Configuring Connectra Applications Configuring File Shares To configure file shares: 1 On the navigation tree, click Applications > File shares. The File Shares page appears. 2 Click New. The Add/Edit File Share page appears. The Application, Security and Specification sections are shown in the following figure: FIGURE 2-10 Add/Edit File Share page 3 Enter: A name for the file share A protection level The NetBios host name, for example, Johnny.company.com The proper share name, for example, file_folder1 The default windows domain or workgroup 50

51 Associating Applications with User Groups The Credentials and Portal Favorite sections are shown in the following figure: FIGURE 2-11 Credentials and Portal Favorites sections 4 In the Credentials section, specify whether to reuse portal credentials. 5 If the User Name and Password to access the file share are identical to those used to access the Connectra Portal, select Reuse portal credentials. 6 If the User Name and Password to access the file share are different than those used to access the Connectra Portal, for example, if Pete is the User Name, used to access the Connectra Portal and Peter is the User Name, to access the file share, select Prompt user for credentials. Enter the User Name and Password. 7 Select Enable Favorite and enter the Path, Display name and Tooltip for the file share that you are designating as a favorite. 8 Click Apply. Associating Applications with User Groups In This Section Associating Web Applications with User Groups page 52 Associating Mail Services with User Groups page 52 Associating File Shares with User Groups page 52 To associate Connectra defined applications with a user group: 1 On the navigation tree, click Users and Groups > User Groups. The User Groups page appears. Chapter 2 Defining Applications 51

52 Configuring Connectra Applications 2 Select the relevant User Group type: Internal, LDAP, or RADIUS. 3 Double-click the relevant group. The Editing Group page appears. 4 Associate Connectra defined applications, as required. For example, associating Web applications, mail services, or file shares with a user group. 5 Click Apply. Associating Web Applications with User Groups To associate Web applications with a user group: 1 Click the Web Access tab 2 Use the Add or Add all buttons to assign the configured Web applications to the group. 3 Click Apply. Associating Mail Services with User Groups To associate mail services with a user group: 1 Click the Mail Access tab 2 Use the Add or Add all buttons to assign the configured mail services to the group. 3 Click Apply. Associating File Shares with User Groups To associate file shares with a user group: 1 Click the File Access tab 2 Use the Add or Add all buttons to assign the configured file shares to the group. 3 Click Apply. 52

53 CHAPTER 3 Managing Users and Groups In This Chapter The Need for Managing Users and Groups page 53 The Check Point Solution page 53 Configuring Internal Users page 54 Configuring External User Groups page 57 The Need for Managing Users and Groups The easiest way of working with users is to gather them into groups with common needs. The members of a particular group share similar properties, for example: all the members of Group A authenticate via an LDAP server. Administration is made easier by assigning access control policies to groups rather than single users. The Check Point Solution Connectra supports two kinds of groups for users: Internal groups External groups Internal users are defined on the local Connectra database. Connectra maintains a database of users and groups and the associations between them. Connectra can also work with groups of users defined on external authorization servers. These external groups can be defined on LDAP, RADIUS, or ACE. Connectra maps these external groups and associates them with an authorization policy. 53

54 Configuring Internal Users For organizations with large numbers of users, employing external databases is a more scalable solution for user management. It makes sense to use these external databases where available. By utilizing these external databases, Connectra simplifies the process of building an access control policy for remote users. Once these groups, internal or external, have been created or mapped in Connectra, they can be assigned an access control policy. Providing the users meet the sensitivity demands of the application, access is given. NOTE: It should be stressed that users belonging to several groups are assigned the unified access rights of all the groups. This is true whether the groups are internal or external. Configuring Internal Users In This Section: Creating Internal Users page 54 Creating Internal User Groups page 55 Creating Internal Users To add Internal Users: 1 On the navigation tree, click Users and Groups > Users. The Users page opens. 2 Click New. The Adding a new user page appears: 54

55 Creating Internal User Groups FIGURE 3-1 Adding a new user page 3 In the User Details section: Supply a login name Enter the user s full name Select Internal as the authentication scheme Supply a password 4 In the Groups section, select the group or groups to which the user belongs. 5 Click Apply. Creating Internal User Groups To create Internal User Groups: 1 On the navigation tree, click Users and Groups > User Groups. The User Groups page appears. 2 Click New. The User Groups drop-down list appears. The available options are: Internal Group LDAP Group RADIUS Group 3 Select Internal Group. The Adding a new group page appears.: Chapter 3 Managing Users and Groups 55

56 Configuring Internal Users FIGURE 3-2 Adding a new group page 4 On the Group tab: Provide a name for the group and select a logging option Add users to the group from the list of configured users 5 On the Home Page tab, configure whether the users should log into the Connectra portal or be taken directly to a specific page. 6 On the Web Access tab: Select the web applications that are to be accessible to the Group members, and add them to the Applications for this group. 7 On the Mail Access tab, select the mail services to which users of this group will be granted access. A link to the mail services will automatically appear on the Connectra portal main page. 8 On the File Access tab: Select the File Shares that are to be accessible to the Group members, and add them to the Shares for this group. 9 Click Apply. 56

57 Working with LDAP Groups Configuring External User Groups In This Section: Working with LDAP Groups To authenticate using LDAP groups, configure connectivity with the LDAP server, in the authentication servers section of the administrative portal. While Connectra is capable of authenticating and authorizing LDAP users and groups, it cannot administer users and groups directly on the LDAP server. Connectra does not create new users and groups on the LDAP server. Users and groups must first be configured in LDAP. Connectra s LDAP client then handles authentication and examines the specified LDAP branches to retrieve the user s groups. Once the LDAP group has been retrieved, Connectra maps the LDAP group to the appropriate Connectra group and adds a group policy. The group policy supplies access restrictions and a unique portal with appropriate favorites for that user group. FIGURE 3-3 Working with LDAP Groups page 57 Working with RADIUS Servers page 60 Working with External groups Chapter 3 Managing Users and Groups 57

58 Configuring External User Groups In FIGURE 3-3, the remote user initiates an HTTPS request to the Connectra Gateway. The Connectra Gateway, via the firewall, performs authentication using the LDAP server. The LDAP server authenticates the remote user and returns a list of the remote user s groups. These LDAP groups are then matched to an appropriate Connectra group and with its access policy. Connectra also provides High Availability for user management by supporting up to three replicated LDAP servers. FIGURE 3-4 LDAP failover In FIGURE 3-4, the remote user initiates an HTTPS connection to the Connectra Gateway. Connectra terminates the SSL connection and initiates a second encrypted connection to the LDAP server (the company security policy specifies connections between LDAP servers on the LAN and machines in the DMZ must be encrypted). If the first LDAP server fails to respond, Connectra queries the replicated LDAP server to authenticate the remote user. Configuring LDAP groups Generally, the administrator needs: To create the users and groups on the LDAP server To create a local Connectra group that will then be mapped to the LDAP group once authentication is complete. 58

59 Working with LDAP Groups Creating an LDAP Group To create an LDAP Group: 1 On the navigation tree, click Users and Groups > User Groups. The User Groups page appears. 2 Click New. The User Groups drop-down list appears. The available options are: Internal Group LDAP Group RADIUS Group 3 Select LDAP Group. The Adding a new group page appears: FIGURE 3-5 Adding a new group page (LDAP) 4 On the Group tab: Provide a name for the group. Select all LDAP branches, or specify one branch, or define an LDAP group 5 On the Home Page tab, configure whether the users should log into the Connectra portal or be taken directly to a specific page. 6 On the Web Access tab: Select the web applications that are to be accessible to the LDAP Group members, and add them to the Applications for this group. Chapter 3 Managing Users and Groups 59

60 Configuring External User Groups 7 On the Mail Access tab, select the mail services to which users of this group will be granted access. A link to the mail services will automatically appear on the Connectra portal main page. 8 On the File Access tab: Select the File Shares that are to be accessible to the LDAP Group members, and add them to the Shares for this group. 9 Click Apply. Microsoft Active Directory Active Directory is the directory service, included since Windows 2000, that stores information regarding objects on the networks in a central database, and makes this information available to users and administrators. Active Directory Service Interfaces (ADSI) gives access to directory services provided by other vendors, such as LDAP or NDS. Connectra leverages the Active Directory LDAP interface to provide authentication. Active Directory is configured the same way as LDAP. Working with RADIUS Servers While Connectra does not provide RADIUS management, Connectra does authenticate user and user groups defined on the RADIUS server. Users and groups must first be configured in RADIUS. Connectra s RADIUS client then handles authentication and examines the specified RADIUS class to retrieve the user s groups. The RADIUS group, by default, is mapped to the class attribute of the RADIUS user. For example, if the attribute value is Managers, then you must create a RADIUS group in Connectra, with the same name. If you are using another attribute in the RADIUS server to indicate the group, procede as follows. 1 Run cpstop. 2 Edit $FWDIR/conf/objects_5_0.C 3 Search for the string radius_groups_attr, and change the value inside the brackets from 25 (Class attribute code) to any other Radius attribute, which holds the group name, on the Radius server. For example: :radius_groups_attr (25) into :radius_groups_attr (11) (in case you wish to use the Filter-Id attribute. 4 Run cpstart. 60

61 Working with RADIUS Servers Once the RADIUS group has been retrieved, Connectra maps the RADIUS group to the appropriate Connectra group and applies a group policy. The group policy supplies access restrictions and a unique portal with appropriate bookmarks for that user group. Configuring Connectra for RADIUS To configure Connectra for RADIUS: 1 On the navigation tree, click Users and Groups > User Groups. The User Groups page appears. 2 Click New. The User Groups drop-down list appears. The available options are: Internal Group LDAP Group RADIUS Group Chapter 3 Managing Users and Groups 61

62 Configuring External User Groups 3 Select RADIUS Group. The Adding a new group page appears: FIGURE 3-6 Adding a new group (RADIUS) 4 On the Group tab, provide a name for the group. 5 On the Home Page tab, configure whether the users should log into the Connectra portal or be taken directly to a specific page. 6 On the Web Access tab: Select the web applications that are to be accessible to the RADIUS Group members, and add them to the Applications for this group. 7 On the Mail Access tab, select the mail services to which users of this group will be granted access. A link to the mail services will automatically appear on the Connectra portal main page. 8 On the File Access tab: Select the File shares that are to be accessible to the RADIUS Group members, and add them to the Shares for this group. 9 Click Apply 62

63 CHAPTER 4 Authentication and Authorization In This Chapter The Need for Authentication and Authorization page 63 The Check Point Solution page 63 Configuring Authentication and Authorization page 66 The Need for Authentication and Authorization Strict authentication is needed to ensure that only the right people gain access to the corporate network. All remote users must be authenticated. Authorization determines if and how remote users access the internal applications on the corporate LAN. If the remote user is not authorized, he/she will not be granted access to the applications. The Check Point Solution In This Section: Authenticating Users in Connectra page 65 Authorization in Connectra page 65 The Connectra strategy for identity and access management is two-fold. Remote users must first prove their identity. Second, authenticated users can only access an application if they belong to the appropriate user group or groups and satisfy the access requirements of the application, as specified by the application protection level. 1 Remote users must first prove their identity through an authentication process. Remote users can authenticate through the Connectra internal database or via: 63

64 The Check Point Solution Lightweight Directory Access Protocol (LDAP) Servers Remote Authentication Dial-in User Service (RADIUS) ACE Management Servers (SecurID) User Certificates 2 Once users are authenticated, they are authorized to access the application, and use the available functionality (for example web mail). This authorization is based on the user groups to which they belong and the access requirements of the application. The user groups can be defined internally on the Connectra database, or externally on LDAP or RADIUS servers. Connectra enforces an access control policy for each group. To access the application, the individual user must also satisfy the access requirements of the application, as defined by the protection level. Classifying internal applications according to protection level is one way of securing applications. For example, a web application for ordering office supplies is less sensitive than an application that controls money transfers. All remote users can be given access to the office-supplies application, identifying themselves with a username and password. However, the money transfer application may be restricted to an exclusive group of remote users and require them to authenticate using certificates. In this way, the level of security surrounding an application is based on the application s protection level. Generally, LDAP, and RADIUS Servers can be used for both authentication and authorization (ACE servers can be used for authentication only), but any of the following combinations are possible: TABLE 4-1 Authentication/Authorization Combinations Authentication Server Connectra (Internal database) LDAP RADIUS ACE RADIUS/ACE RADIUS Client certificates Group Server Internal LDAP LDAP LDAP Internal RADIUS LDAP/ Internal 64

65 Authenticating Users in Connectra Authenticating Users in Connectra If a user has a certificate, Connectra authenticates the user via the certificate. If a user does not have a certificate, Connectra authenticates users through its internal database, or through the LDAP, RADIUS, or ACE servers. Connectra searches for users in the databases in the following order: Are the remote users defined on the internal database? Are remote users defined in an LDAP database? If the remote user is neither defined in the internal database nor in LDAP, then Connectra checks the RADIUS server. The RADIUS server uses a profile for all external users that authenticate via RADIUS. When a remote user initiates an HTTPS request to the Connectra gateway, the Connectra gateway uses the specific client used for authentication, LDAP, RADIUS or ACE(SecurID), to verify the remote user s identity with the specific server used for authentication. (The clients are part of the Connectra authentication infrastructure.) For example, the Connectra gateway uses the LDAP client to verify the remote user s identity with the LDAP server. The authenticated user is assigned a group or number of groups. How Connectra Maps LDAP groups An LDAP group specifies certain characteristics of LDAP users. Users with the same characteristics belong to the same LDAP group. Connectra supports LDAP groups by mapping them to a logical group known as an external group. Connectra interacts with LDAP servers by maintaining an LDAP account unit object. The administrator defines a certain point in the branch as group. The external group object that Connectra generates includes all the members of that branch and below. In this way, Connectra has a default schema which is a description of the data structure in the LDAP directory. How Connectra Maps RADIUS Groups The RADIUS group, by default, is mapped to the class attribute of the RADIUS user. For example, if the attribute value is Managers, then you must create a RADIUS group in Connectra, with the same name. You may configure another attribute in the RADIUS server to indicate the group. Authorization in Connectra Authorization is the process that controls the access to the applications on the internal network. This is done by enforcing an access control policy. Connectra implements a group based access control policy. An access control policy is applied to groups, not Chapter 4 Authentication and Authorization 65

66 Configuring Authentication and Authorization individual users. During the authentication process, the remote users are associated with one or more groups. Remote users, once authenticated, can only access those applications which have been authorized for their groups. In other words, for access to be granted, Connectra checks for: Access rights. Does the remote user belong to a group which is allowed to access the application? Security requirements. Does the remote user meet the security restrictions as expressed by the application s protection level? Connectra can authenticate remote users through its own internal database, LDAP, or RADIUS Servers. Connectra requests LDAP or RADIUS Servers to return a list of the remote user s groups. Once the LDAP or RADIUS groups are mapped to the user s groups as defined on Connectra, an access control policy is assigned. Understanding Connectra Protection Levels Out of the box, Connectra comes with three pre-defined protection levels: standard, high, and advanced, each with its own criteria, as shown in TABLE 4-2. TABLE 4-2 Protection Level Standard High Advanced Protection Level requirements Authentication Username/password SecurID Client certificate Each protection level defines what level user authentication is required, for example if users can identify themselves via a combination of username and password, or need to provide certificates. Configuring Authentication and Authorization In This Section: Configuring Authentication via LDAP page 67 Configuring Authentication via RADIUS page 68 Authentication via Certificates page 69 SecurID page 70 Configuring Protection Levels page 71 66

67 Configuring Authentication via LDAP This section discusses how to configure authentication and authorization, using LDAP, RADIUS, ACE servers and/or user certificates. Configuring Authentication via LDAP 1 On the navigation tree, click Users and Groups > Authentication > LDAP server. The LDAP page appears. The LDAP Servers section is displayed, as shown in the following figure: FIGURE 4-1 LDAP page (LDAP Servers section) The LDAP Servers section lists your organization s LDAP servers. Each of these servers should contain the same information, allowing a redundant configuration, and thereby guaranteeing optimal system performance. The servers are queried in their order of appearance. If a server can not be reached, the system queries the next server listed. 2 In the LDAP Servers section, click New. The Add LDAP page appears. 3 Provide the server name or IP Address of the LDAP Server, and click OK. The Networking and Login to LDAP sections are displayed in the following figure: FIGURE 4-2 Networking and Login to LDAP sections 4 In the Networking section: Decide whether to Use SSL for the connection. Chapter 4 Authentication and Authorization 67

68 Configuring Authentication and Authorization Configure a port number. Select an LDAP type, for example Microsoft Active Directory. 5 In the Login to LDAP section: Provide the Login Distinguished Name. Provide a password. The Branches and Authentication sections are displayed in the following figure: FIGURE 4-3 Branches and Authentication sections 6 In the Branches section, select an existing branch, or click New to create a new branch. 7 Click Fetch Branches to display all the branches of the selected LDAP server. 8 In the Authentication section, select an authentication scheme. 9 Click Apply. Configuring Authentication via RADIUS 1 On the navigation tree, click Users and Groups > Authentication > RADIUS Server The RADIUS page appears: FIGURE 4-4 RADIUS page 2 Enter: Host name of the RADIUS Server 68

69 Authentication via Certificates A port number for the connection (The RADIUS default port number is UDP Port 1645.) From the drop-down box, select which version of RADIUS you are working with Enter a shared secret (password) 3 Click Apply. Authentication via Certificates In order for the Connectra server to authenticate users via client certificates, Connectra must trust the CA that signed the certificate. The administrator can define which CAs are trusted by Connectra. To view the Trusted CAs list: 1 On the navigation tree, click Users and Groups > Authentication > Trusted CAs The Trusted CAs page appears: FIGURE 4-5 Trusted CAs page Chapter 4 Authentication and Authorization 69

70 Configuring Authentication and Authorization 2 Click on a specific Trusted CA link to view the certificate details, as illustrated in the following figure: FIGURE 4-6 Certificate Details To add a new Trusted CA: 1 Click New. The Edit Trusted CAs page appears: FIGURE 4-7 Edit Trusted CAs page 2 Browse to a trusted CA file in PEM format. 3 Click Apply. SecurID To work with an RSA ACE/Server (Configuring SecurID): NOTE: Connectra communicates with the ACE server using port 5500/udp. Depending on your setup, you may need to enable this port on the firewall. 70

71 Configuring Protection Levels 1 Define the Connectra server on the ACE/Server GUI. For the primary IP setting, use the Connectra server interface that connects to the ACE/Server. The ACE/Server GUI generates a sdconf.rec file for the defined Connectra server. 2 Copy the file to the Connectra server under the directory: /var/ace. 3 If /var/ace does not exist, create the directory. 4 In some cases, the SecurID client used by Connectra may use the wrong interface IP (in case of multiple interfaces) to decrypt the reply from ACE/Server and as a result authentication will fail. To overcome the problem place a new text file sdopts.rec next to sdconf.rec with the following line CLIENT_IP=<ip>, where <ip> is Connectra's primary IP, as defined on the ACE/Server (the IP of the interface that the server is routed to). Configuring Protection Levels Generally, the system administrator needs to: 1 Make a list of applications which will be exposed to remote access. 2 Classify applications according to their protection level, for example advanced, high, or standard. 3 For each protection level, define security restrictions, such as the level of authentication required username/password, or certificates, or SecurID. 4 For each application, assign a protection level. The protection level should reflect the company s security policy. To access applications with a specific protection level, users must authenticate using one of the selected authentication schemes. Creating a Protection Level To create a Protection Level: 1 Login to the administration portal. 2 In the navigation tree, select Security > Protection Levels. The Protection Levels page appears: FIGURE 4-8 Protection Levels page Chapter 4 Authentication and Authorization 71

72 Configuring Authentication and Authorization 3 Double-click the link of the protection level to be customized, for example High. The Edit Protection Level page appears. The Protection Level and Authentication sections are displayed in the following figure: FIGURE 4-9 Edit Protection Level page 4 Customize the protection level by modifying the allowed authentication schemes selected: Username & Password SecurID Client Certificate The Prevent Browser Caching section is displayed in the following figure: FIGURE 4-10 Prevent Browser Caching section 5 Select one of the following options: Prevent caching of all content Allow caching of these content types Allow caching of all content 6 If you select Allow caching of these content types, select Images and Flash, Scripts and/or HTML. 72

73 Configuring Protection Levels 7 Click Apply. Chapter 4 Authentication and Authorization 73

74 Configuring Authentication and Authorization 74

75 CHAPTER 5 Using Certificates In This Chapter The Need for Certificates page 75 The Check Point Solution page 75 Configuring Server Certificates page 77 Configuring Client Certificates page 79 The Need for Certificates When working with SSL a server certificate is required so that the user/client may trust the server side. In addition, remote users must prove their identity through an authentication process, such as a user certificate, before they can attempt to access the corporate network s applications.. The Check Point Solution In This Section: Automatically Generated Server Certificate page 76 Login with Client Certificate page 76 The following sections describe the automatically generated Connectra server certificate and how to login with a client certificate. 75

76 The Check Point Solution Automatically Generated Server Certificate Connectra automatically generates a server certificate during installation. The automatic certificate is self-signed, imported to the browser of a connecting user or administrator, and valid for ten years. The certificate is imported along the SSL negotiation. It does not require a password. The user, accessing the Portal, will be notified that the automatically generated server certificate is not signed by a trusted CA. The certificate is from a CA located on the Connectra server. Viewing Server Certificate Details The administrator, via the administration portal, will be able to view the server certificate details. The details will include a summary of the X509 data: Issued by: Issued to: Valid from: Valid to: To view the server certificate details: On the navigation tree, click Settings > Server certificate. The Server Certificate page appears: FIGURE 5-1 Server Certificate page Login with Client Certificate At the Connectra Portal SignIn page, the user can select to either sign in with a username/password or with a client certificate, as shown in the following figure: 76

77 Installing a New Server Certificate FIGURE 5-2 Connectra Portal SignIn page To sign in with a client certificate, the user must first install the certificate on the computer. Once signed-in, the system will mark the client as having provided a client certificate for the entire session and access will be granted accordingly. Configuring Server Certificates The following section describes how to install a new server certificate. Installing a New Server Certificate Before deploying to a production environment, users will probably want to change to a certificate signed by a known CA, such as VeriSign. In order to certify the Connectra gateway by a well known public CA, the certificate used by Connectra has to be replaced. The administrator, via the administration portal, will be able to install certificates in the following formats: PEM (provides 2 files) For PEM, in addition to the certificate files, that is, certificate and private key, the administrator will supply the password for the private key. Chapter 5 Using Certificates 77

78 Configuring Server Certificates Changing a Server Certificate When you already have received a certificate and a private key, you can change the server certificate, as follows. To change the server certificate: 1 On the navigation tree, click Settings > Server Certificate. The Server Certificate page appears. 2 Click Change Server Certificate. The Change Server Certificate page appears: FIGURE 5-3 Change Server Certificate page 3 Select the Certificate file. 4 Select the Private key file. 5 Decide whether to use a Password or not. 6 Click Apply. 78

79 Importing a Client Certificate to Internet Explorer Configuring Client Certificates In This Section: The following sections describe how to import a client certificate, and verification and validation of a client certificate. Importing a Client Certificate to Internet Explorer Importing a client certificate to Internet Explorer is acceptable for allowing access to either a home PC with broadband access or a corporate laptop with a dial-up connection. The client certificate will be automatically used by the browser, when connecting to Connectra. WARNING: The client certificate that you have downloaded to a browser will also be available to other users. To prevent misuse of the certificate, only download a certificate to a browser, on a computer approved by your system administrator. To import a client certificate: 1 If you do not have a digital certificate, request a client certificate, in PKCS12 format, for example, from the administrator. 2 Save the certificate as per the administrator s instructions. 3 In Microsoft Internet Explorer, select Tools > Options. The Internet Options window appears. The General tab is displayed: FIGURE 5-4 Importing a Client Certificate to Internet Explorer page 79 Client Certificate Verification page 82 Internet Options window Chapter 5 Using Certificates 79

80 Configuring Client Certificates 4 Select the Content tab. The Content tab is displayed: FIGURE 5-5 Content tab 5 Click Certificates. The Certificates window appears: FIGURE 5-6 Certificates window 80

81 Importing a Client Certificate to Internet Explorer 6 Click Import. The Certificate Import Wizard screen appears: FIGURE 5-7 Certificate Import Wizard screen 7 Click Next. The File to Import screen appears: FIGURE 5-8 File to Import screen 8 Browse for your certificate file. 9 Select a P12 file for your certificate and click Next. The Password screen appears: Chapter 5 Using Certificates 81

82 Configuring Client Certificates FIGURE 5-9 Password screen 10 Enter your password, click Next twice and Finish. The Import Successful screen appears: FIGURE 5-10 Import Successful screen 11 Click OK. The Certificates window appears. The imported certificate is now listed in the Personal tab. 12 Click Close and OK. NOTE: You may need to close and reopen your browser. Client Certificate Verification Client certificate verification will be carried out by using trusted CAs, displayed in a table. You will be able to add to the list of trusted CAs. See Authentication via Certificates on page 69. For each certificate, the following will be displayed: "Issued to "Issued by "Valid from/to date Clicking on a certificate in the table will display all the X509 fields. It will be possible to add/delete CA certificates 82

83 CHAPTER 6 Security In This Chapter The Need for Security page 83 The Check Point Solution page 83 Configuring Session Time-Outs page 86 Configuring Web Intelligence page 87 Using Client Side Security page 95 The Need for Security Giving remote users access to the internal network exposes the network to external threats. Greater access and connectivity demands a higher level of security. The information and applications to which authenticated users have access must be secured. In addition, strong encryption methods are needed to guarantee user privacy and data integrity. The Check Point Solution In This Section: General Security Issues page 84 Web Intelligence Protections page 85 Client Side Security page 86 83

84 The Check Point Solution All connections to the Connectra Gateway from remote users are SSL encrypted to ensure privacy and data integrity. The connections are subject to authentication and authorization. In addition, Connectra protects the information and applications to which authenticated users have access by enforcing a set of security restrictions, both on the server and client side. Connectra provides a unified security framework for various components that identify and prevent attacks. It unobtrusively analyzes activity across your network, tracking potentially threatening events and optionally sends notifications. It protects organizations from all known, and most unknown network attacks using intelligent security technology. General Security Issues In This Section: Server Side Security Highlights page 84 Client Side Security Highlights page 85 This section discusses how Connectra handles various general security issues. The Connectra security features may be categorized as server side security and client side security. Server Side Security Highlights The following list outlines the security highlights and enhancements available on the server side: 1 Check Point Web Intelligence enables protection against malicious code transferred in web-related applications: worms, various attacks such as Cross Site Scripting, buffer overflows, SQL injections, Command injections, Directory traversal, and http code inspection. 2 Connectra provides a granular authorization policy, limiting which users get access to which applications by enforcing authentication, encryption, and client security requirements. 3 Connectra provides application support over HTTPS for web-based applications, file shares, and mail support. Access is allowed for a specific application set rather than full network-level access. 4 Connectra maintains a separate portal for administrators. 84

85 Web Intelligence Protections 5 Connectra employs FireWall-1 technology, providing Check Point FireWall-1 security features, and using secure code and infrastructure. 6 Connectra is fully integrated with the hardened Check Point operating system: SecurePlatform. Client Side Security Highlights The following list outlines the security highlights and enhancements available on the client side: 1 Connectra implements Secure Configuration Verification of the remote user s machine, preventing threats posed by Malware types, such as Worms, Trojan horses, Hacker's tools, Key loggers, Browser plug-ins, Adwares, Third party cookies, and so forth. 2 Connectra controls browser caching. You decide what web content may be cached by browsers, when accessing web applications, associated with a given protection level. Disabling browser caching can help prevent unauthorized access to sensitive information, thus contributing to overall information security. 3 Connectra captures cookies sent to the remote client by the internal web server. Cookies provide a way of maintaining state information between clients and servers. If cookies are stolen they may be used to impersonate a user. For this reason, Connectra captures the cookies and maintains them on the server. Connectra simulates user/web server cookie transmission by appending the cookie information, stored on Connectra, to the request that Connectra makes to the internal web server, in the name of the remote user. 4 Connectra supports strong authentication methods using SecurID tokens and SSL client certificates. Web Intelligence Protections Web Intelligence protections are designed specifically for web-based attacks. They compliment the network and application level protections offered by SmartDefense. Web Intelligence provides proactive attack protections that ensure correct interaction between clients and web servers, restricts hackers from executing irrelevant system commands, and inspects traffic passing to web servers to ensure that they don't contain dangerous malicious code. Web Intelligence utilizes a number of advanced defenses, including Cross Site Scripting, Command Injection, SQL Injection and Malicious Code Protection, to provide good protection, with a minimum number of false positives. Web Intelligence is based on the following Check Point technologies: Chapter 6 Security 85

86 Configuring Session Time-Outs Malicious Code Protector: Blocks hackers from sending malicious code to target web servers and applications. These protections allow you to prevent attacks that run malicious code on web servers (or clients). Application Intelligence: Set of technologies that detect and prevent application-level attacks. Prevents hackers from introducing text, tags, commands, or other characters that a web application will interpret as special instructions. HTTP Protocol Inspection: HTTP Protocol Inspection provides strict enforcement of the HTTP protocol, ensuring these sessions comply with RFC standards and common security practices. Client Side Security Client Verification (CV) scans endpoint computers for potentially harmful software before allowing them to access the web site or gateway. NOTE: Currently, the CV client will work on Internet Explorer only. When end users access the User Portal for the first time, they are prompted to download an ActiveX component that scans the end user machine for Malware. The scan results are presented both to the Connectra and to the end user. Portal access is granted/denied to the end user based on the compliance options set by the administrator. Configuring Session Time-Outs Once authenticated, remote users are assigned a Connectra session. The session provides the context in which Connectra processes all subsequent requests until the user logs out or the session ends due to a time-out. Each session has two configurable time-outs: Passive time-out. If the connection remains idle for this period, the session is terminated. Active time-out. The maximum length of session. When this period is reached, the user must login once more. In HTTP, the Web browser automatically supplies the password to the server for each connection. This creates special security considerations when using User Authenticating for HTTP with one-time passwords. To avoid forcing users of one-time passwords to generate a new password for each connection, the HTTP Security Server extends the validity of the password for the time period defined in Session time-out. Users of one-time passwords do not have to reauthenticate for each request during this time period. To configure Session Time-Outs: 86

87 Configuring Malicious Code Protection 1 On the navigation tree, click Security > Timeouts. The Timeouts page appears: FIGURE 6-1 Timeouts page 2 In the Force active users to re-authenticate after: field, enter the active time-out, in minutes. 3 In the Terminate non-active sessions after: field, enter the passive time-out, in minutes. 4 Click Apply. Configuring Web Intelligence In This Section: Configuring Malicious Code Protection page 87 Configuring Application Layer Protection page 89 Configuring HTTP Protocol Inspection page 93 Updating SmartDefense and Web Intelligence page 95 This section discusses how to configure the supported protections, and how to update the SmartDefense feature. Configuring Malicious Code Protection This section discusses the following options, used by Connectra to provide malicious code protection: General HTTP Worm Catcher Buffer Overflow General HTTP Worm Catcher A worm is self-replicating malware (malicious software) that propagates by actively sending itself to new machines. Many worms propagate by using security vulnerabilities in HTTP servers or clients. Chapter 6 Security 87

88 Configuring Web Intelligence Buffer Overflow Buffer overflow vulnerabilities in web servers and web applications are both common and dangerous. By formatting special strings that contain assembly code, an attacker can create a memory corruption that can cause a server to crash or even run arbitrary code. An attack exploiting a buffer overflow vulnerability does not require user interaction. This allows the attack to spread easily via reusable exploit scripts or worms. Buffer overflow attacks can be performed using any space where user input is expected, such as, URLs, HTTP headers, and HTTP bodies. The following table defines the Security Levels that may be assigned to the Buffer Overflow protection. Traffic is considered suspicious when it contains at least one non-ascii character. TABLE 6-1 Security Level Low Normal High Buffer Overflow Protection Security Levels Description Inspects any suspicious URL or HTTP header. When the HTTP header is found to be suspicious, the HTTP body is also inspected. Inspects all URLs. Inspects any suspicious HTTP header or HTTP body. When the HTTP header is found to be suspicious, the HTTP body is also inspected. Inspects all URLs and HTTP headers. Inspects HTTP body if either the HTTP header of HTTP body is suspicious. 88

89 Configuring Application Layer Protection To enable Malicious Code Protection: 1 On the navigation tree, click Security > Web Intelligence. The Web Intelligence page appears. The Malicious Code Protection section is shown in the following figure: FIGURE 6-2 Malicious Code Protection section 2 In the Malicious Code Protection section, decide whether to enable General HTTP Worm Catcher. 3 Decide whether to enable Malicious Code protection. 4 Before enabling Malicious Code protection, select a Security Level from the Security Level drop-down box. Configuring Application Layer Protection This section discusses the following options, used by Connectra to provide application layer protection: Cross Site Scripting SQL Injection Command Injection Directory Traversal Cross Site Scripting Cross Site Scripting attacks exploit the trust relationship between a user and a website by employing specially crafted URLs that contain malicious scripts. The intention of the attack is to steal cookies that contain user identities and credentials, or to trick users into supplying their credentials to the attacker. Typically this attack is launched by embedding scripts in an HTTP request (both GET and POST) that the user unwittingly sends to a trusted site. Web servers are protected by detecting and blocking inbound HTTP requests that contain threatening scripting code. Alternatively, all inbound HTTP requests that contain any tags at all, whether script tags or other tags, can be blocked. Chapter 6 Security 89

90 Configuring Web Intelligence The following table defines the Security Levels that may be assigned to Cross Site Scripting protection. These protections are applied to places where a hacker could place cross-site scripting characters: URLs, query strings, and HTTP POST request bodies. TABLE 6-2 Security Level Low Normal High Cross Site Scripting Protection Security Levels Description Rejects requests with keywords related to scripts (e.g., script, ActiveX object, applet, etc.) when located inside HTML tags. Rejects requests that have any HTML tags. Rejects requests that have any HTML tags. In addition checks for Unicode encoding of HTML tags. SQL Injection SQL Injection attacks allow a remote attacker to execute SQL commands disguised as a URL or form input to a database. A successful attack may get the database to run undesirable commands. This could cause damage by revealing confidential information, modify the database, or even shut it down. Web Intelligence can inspect for the presence of SQL commands in web forms or URLs sent in HTTP requests to a server. The protection looks for several categories of commands: distinct SQL commands, non-distinct SQL commands, and special SQL separator characters (e.g., + ' -). Strings that are unique to SQL and not likely to appear in common language are considered distinct (e.g., "sql_longvarchar", "sysfilegroups", etc.). Strings that may appear in common language are considered non-distinct (e.g., "select", "join", etc.). 90

91 Configuring Application Layer Protection The following table defines the Security Levels that may be assigned to SQL Injection protection. TABLE 6-3 Security Level Low Normal High SQL Injection Protection Security Levels Description Rejects forms and URLs that contain special SQL characters or distinct SQL commands in the path and form fields. Rejects forms and URLs that contain special SQL characters, distinct SQL commands, or non-distinct SQL commands in the path and form fields. Rejects forms and URLs that contain special SQL, distinct SQL commands, or non-distinct SQL commands in the entire URL. Command Injection Command Injection attacks allow a remote attacker to execute operating system commands disguised as a URL or form input to a web server. A successful system command execution can provide a remote attacker with administrative access to a web server. This could result in damage such as defacement of the web site, data theft, or data loss. Web Intelligence looks for the presence of system commands in web forms and URLs sent to a protected server. The protection looks for several categories of commands: distinct system commands, non-distinct system commands, and special system characters (e.g., ;[ ]<>&\t). Strings that are unique to system commands, not likely to appear in common language, and often used in command injection are considered distinct (e.g., "chown", "regsvr32", etc.), while strings that may appear in common language are considered non-distinct (e.g., "format", "convert", etc.). Chapter 6 Security 91

92 Configuring Web Intelligence The following table defines the Security Levels that may be assigned to Command Injection protection. TABLE 6-4 Security Level Low Normal High Command Injection Protection Security Levels Description Rejects forms that contain special Shell characters and distinct Shell commands in the path and form fields. Rejects forms that contain special Shell characters, distinct Shell commands, and non-distinct Shell commands in the path and form fields. Rejects forms that contain special Shell characters, distinct Shell commands, or non-distinct Shell commands in the entire URL. Directory Traversal Directory Traversal attacks allow hackers to access files and directories that should be out of their reach. Using this attack, a hacker may be able to view a list of directories, or in some cases allow them to run executable code to the web server with a single, well-crafted URL. There are several techniques to launch a directory traversal attack. Most of the attacks are based on using an HTTP request with a dot-dot-slash sequence "../.." within a file system. This sequence of characters allows a hacker to move outside of the root directory of a given web page. For example, " is illegal because it goes deeper than the root directory. " is legal because it is equivalent to " In a more advanced form of this attack, a hacker my use an encoded URL to run the attack. This protection verifies that the URL does not contain an illegal combination of directory traversal characters, including encoded URLs. Requests in which the URL contains an illegal directory request are blocked. 92

93 Configuring HTTP Protocol Inspection To enable Application Layer Protection: 1 On the navigation tree, click Security > Web Intelligence. The Web Intelligence page appears.the Application Layer Protection section is shown in the following figure: FIGURE 6-3 Application Layer Protection section 2 In the Application Layer Protection section, decide whether to enable Cross Site Scripting. 3 Before enabling Cross Site Scripting, select a Security Level from the Security Level drop-down box. 4 Decide whether to enable SQL Injection. 5 Before enabling SQL Injection, select a Security Level from the Security Level drop-down box. 6 Decide whether to enable Command Injection. 7 Before enabling Command Injection, select a Security Level from the Security Level drop-down box. 8 Decide whether to enable Directory Traversal. Configuring HTTP Protocol Inspection HTTP Protocol Inspection provides strict enforcement of the HTTP protocol, ensuring these sessions comply with RFC standards and common security practices. HTTP protocol inspection settings that are too severe can affect connectivity to and from valid web servers. Chapter 6 Security 93

94 Configuring Web Intelligence To enable HTTP Protocol Inspection: 1 On the navigation tree, click Security > Web Intelligence. The Web Intelligence page appears. The HTTP Protocol Inspection section is shown in the following figure: FIGURE 6-4 HTTP Protocol Inspection section 2 In the HTTP Protocol Inspection section, decide whether to enable HTTP Format. HTTP Format protection restricts URL lengths, header lengths or the number of headers. These elements can be used to perform a Denial of Service attack on a web server. NOTE: These restrictions can also potentially block valid sites. 3 Select the fields that you would like to activate: ASCII only Request protection can block connectivity to web pages that have non-ascii characters in URLs. Enforce ASCII only HTTP Headers activates ASCII only Request protection on HTTP Headers. Enforce ASCII only Form Fields activates ASCII only Request protection on Form Fields. HTTP methods protection allows you to block certain standard and non-standard HTTP methods that can be used to exploit vulnerabilities on a web server. Web Intelligence divides HTTP methods into three groups: Standard Safe (GET, HEAD and POST), Standard Unsafe (remaining HTTP methods), and WebDAV. By default, all methods other than Standard Safe methods are blocked. The other groups can be individually enabled. Block unsafe HTTP methods enables blocking Standard Unsafe methods. Block WebDAV HTTP methods enables blocking WebDAV methods. To allow users access to popular applications such as Microsoft Hotmail, Outlook Web Access, and FrontPage, WebDAV HTTP methods can be allowed. Several WebDAV methods are used for these applications. Microsoft WebDAV methods have certain security issues, but blocking them can prevent use of important applications. 94

95 Updating SmartDefense and Web Intelligence 4 Click Apply. Updating SmartDefense and Web Intelligence You can update your SmartDefense via the Connectra Administration Portal GUI. To Update SmartDefense: 1 On the navigation tree, click Security > Update Web Intelligence. The SmartDefense and Web Intelligence Update page appears: FIGURE 6-5 SmartDefense and Web Intelligence Update page 2 Click Check SmartDefense and Web Intelligence updates. Your current SmartDefense version, date of version upload and new version available are displayed. 3 Click Yes if you wish to continue with the upgrade. The Upload updated content form is displayed: FIGURE 6-6 Upload updated content form 4 Enter your User Center username and password, and click Upload SmartDefense update. You are informed that the SmartDefense content was updated successfully. 5 Click OK. Using Client Side Security In This Section: Screened Software Types page 96 Administrator Configuration of CV page 97 End-User CV Experience page 99 Chapter 6 Security 95

96 Using Client Side Security Screened Software Types Client Verification can screen for the Malware software types listed in the following table: TABLE 6-5 Screened Software Types Software Type Worms Trojan horses Hacker tools Keystroke loggers Adware Browser plug-ins Description Programs or algorithms that replicate over a computer network for the purpose of disrupting network communications or damaging software or data. Malicious programs that masquerade as harmless applications. Tools that facilitate a hacker s access to a computer and/or the extraction of data from that computer. Programs that record user input activity (that is, mouse or keyboard use) with or without the user s consent. Some keystroke loggers transmit the recorded information to third parties. Programs that display advertisements, or records information about Web use habits and store it or forward it to marketers or advertisers without the user s authorization or knowledge. Programs that change settings in the user's browser or adds functionality to the browser. Some browser plug-ins change the default search page to a pay-per-search site, change the user's home page, or transmit the browser history to a third party. 96

97 Administrator Configuration of CV TABLE 6-5 Screened Software Types Software Type Dialers 3rd party cookies Other undesirable software Description Programs that change the user s dialup connection settings so that instead of connecting to a local Internet Service Provider, the user connects to a different network, usually a toll number or international phone number. Cookies that are used to deliver information about the user s Internet activity to marketers. Any unsolicited software that secretly performs undesirable actions on a user's computer and does not fit any of the above descriptions. Administrator Configuration of CV The client's behavior will be defined according to the administrator configuration of the CV. The administrator configuration includes: determining which categories of undesired software are to be scanned for at the client's computer, and how to deal with them, in terms of granting or blocking access. The administrator will be able to set one of 3 options for each category: Do not scan: The client will not conduct a scan for that specific category. Moreover, the user will be redirected to the Connectra portal, if the client scan does not detect items in other categories. Scan for Malware and ask for user directions: The user receives the findings of the current scan and be given the ability to proceed, at his/her discretion. Scan for Malware and prevent user connectivity to site: The user will not be able to access the Connectra portal until he/she removes the malware, which was detected on his/her computer. Chapter 6 Security 97

98 Using Client Side Security To configure the CV: 1 On the navigation tree, click Security > Client Verification. The Client Verification page appears. FIGURE 6-7 Client Verification page NOTE: You must have a valid Connectra Client Verification license before activating this feature. 2 Activate the use of CV. Disabling CV will redirect the user to the Connectra portal. 3 Select a Log level. 4 Select Malware Protection levels for each type of malware. 5 Click Apply. CV Session Timeout After the client finishes the CV procedure, a CV Session Timeout begins. The CV Session Timeout defines the interval, within which the user can login to the Connectra portal, without undergoing another software scan. The administrator defines the CV Session Timeout in the file CVPNDIR\conf\cvpnd.C. The syntax is: CVSessionTimeout (xxx seconds) The default Session Timeout value is 3600 seconds. 98

99 End-User CV Experience End-User CV Experience In This Section: Security Settings in Internet Explorer page 99 Server Confirmation page 99 Scanning the Client Machine page 100 Client Verification and Non-IE Users page 101 This section describes the CV experience, as experienced by the end-user. The User must have at least POWER USER privileges to download and install ActiveX. Security Settings in Internet Explorer This section explains how to configure the Internet Explorer security settings in order to be able to download and run the CV ActiveX. To configure the Internet Explorer security settings: 1 Click Tools > Internet Options > Security and enable: Download signed ActiveX controls Run ActiveX controls and plug-ins Script ActiveX controls marked as safe for scripting Active scripting NOTE: If you know in which web content zone the organization's site is located, enable the following settings in that zone, to download and run the CV ActiveX. If not, enable the following settings in the Internet, Local intranet and Trusted sites zones. 2 Click Tools > Internet Options > Privacy. In the Medium setting, select Advanced. Check Override automatic cookie handling and enable: Accept 1st party cookies Accept 3rd party cookies Server Confirmation To confirm the CV server: 1 The user enters the URL of the Connectra portal. If this is the first time that the user attempts to access the Connectra portal, the Server Confirmation window appears: Chapter 6 Security 99

100 Using Client Side Security FIGURE 6-8 Server Confirmation window The user is asked to confirm that the listed CV server is identical to the organization s site for remote access. 2 If the user clicks Yes, the CV client continues the software scan. Moreover, if the Save this confirmation for future use checkbox is selected, the Server Confirmation window will not appear the next time the user attempts to login. 3 If the user clicks No, an error message is displayed and the user is denied access. Scanning the Client Machine Once the user has confirmed the CV server, an automatic software scan takes place on the client's machine. Upon completion, the user is displayed with the scan results. NOTE: The scan results are presented to the user, as shown in the following figure, and to the administrator, as log entries in the Traffic Log. Each log entry lists the username, his/her group, the source computer, malware name, malware type and malware description. FIGURE 6-9 Scan Results 100

101 End-User CV Experience Each malware is displayed as a link, which, if selected, redirects you to a data sheet describing the detected malware. The data sheet includes the name and a short description of the detected malware, that is what it does, and the recommended removal method/s. The options available to the user are configured by the administrator. For example, the option Continue is only available if the administrator has configured the Scan for Malware and ask for user directions setting for the relevant category. The options are listed in the following table: TABLE 6-6 Scan Options Scan Option Scan Again Cancel Continue Description Allows a user to rescan for malware. This option is used in order to get refreshed scan results, after manually removing an undesired software item. Prevents the user from proceeding with the portal login, and closes the current browser window. Causes the CV client to disregard the scan results and proceed with the log on process. Client Verification and Non-IE Users When a non Internet Explorer browser attempts accessing the portal, and CV is enabled, with at least one prevent access action selected, the user is notified that he/she can not proceed, since the browser is not compatible. In addition, a corresponding log entry is generated in the administrator s Traffic Log. When a non Internet Explorer browser attempts accessing the portal, and CV is enabled, with no prevent access action selected, the user is notified that no scan has been performed, since the browser is not compatible. In addition, a corresponding log entry is generated in the administrator s Traffic Log. However, a Continue button is displayed, and the user may proceed to access the portal. Chapter 6 Security 101

102 Using Client Side Security 102

103 CHAPTER 7 Status and Logging In This Chapter The Need for Status and Logging Information page 103 The Check Point Solution page 103 Configuring Logging page 109 The Need for Status and Logging Information As with any Gateway situated at the perimeter of the network, there are many events that should be monitored, for security and other reasons. A log database is useful when the administrator needs to: Troubleshoot Track usage Plan for future loads and capacity Audit The Check Point Solution In This Section Status page 104 Audit Log page 105 Traffic Log page 107 Connectra uses the same proven logging infrastructure available on every Check Point module. Connectra produces two types of log: A traffic log, which records events generated by user activity 103

104 The Check Point Solution An audit log, which records events generated by the administrator Traffic events are saved to fw.log. Audit events are saved to fw.adtlog. Both these files can be found in the log directory under: /var/opt/cpfw1-r55. These log files can be integrated with Check Point s SmartView Reporter. Status To view the Device Status: On the navigation tree, click Status and Logs> Status. The Device Status page appears. FIGURE 7-1 Device Status page The Host ID, operating system, product information, CPU usage, total memory, available memory, and active sessions are displayed. 104

105 Audit Log Audit Log To view the Audit Log: On the navigation tree, click Status and Logs > Audit log. The Audit Log Tracker page appears. FIGURE 7-2 Audit Log Tracker page The Audit log records events generated by the administrator, such as when an administrator logs in, changes policy, etc. Fields The fields include: Date Hour Subject, for example, Object Manipulation Operation, for example, Create Object Operation name Administrator Machine Chapter 7 Status and Logging 105

106 The Check Point Solution Color code Entries in the log appear in various colors. There are two possible subjects to the "Subject" field. The Audit log subject color code is presented in the following table: TABLE 7-1 Audit log subject color code Subject description Administrator Login Object Manipulation Failure Color GREEN BLUE RED Audit Log Tracker Options The following table lists the various Log Tracker options: TABLE 7-2 Audit Log Options Option Find Log Number File Filter Description Allows you to search for a specific log entry that matches the text criterion that you set. You can search through all the columns and rows. You must specify if you wish to search ahead of or behind the present cursor position in the log. Allows you to navigate to a specific log entry. Enter the log entry ID number and click Go. 1) Enables you to open a log file. Select the log file from a list and click OK. 2) Allows you to purge the active log file, in general the fw.log file. Allows you to apply a filter on your log display. Scope: You can choose to view either All Connectra Logs or All Logs. Fields: You can select a field, enable the Filter checkbox, and configure the filter for that field. NOTE: The filters are cumulative. Clear All: Clears all filters. 106

107 Traffic Log Traffic Log To view the Traffic Log: On the navigation tree, click Status and Logs > Traffic Log. The Traffic Log Tracker page appears. FIGURE 7-3 Traffic Log Tracker page Fields The traffic log displays events generated by users, such as login, web requests, etc. Color code The Traffic log category and access status color code is presented in the following table: TABLE 7-3 Traffic log category and access color code Description Web Native Mail Failure File Shares Session Timeout Portal Event Color BLUE PURPLE RED BLACK BLACK BLACK Chapter 7 Status and Logging 107

108 The Check Point Solution TABLE 7-3 Traffic log category and access color code Description Login/Logout Success Access denied Color BLACK GREEN A red X is displayed, as well as a message in the category color. For example, if access was denied to a web application, the access denied message will be in blue. Traffic Log Tracker Options The Traffic Log Tracker options are the same as those available for the Audit Log Tracker. See Audit Log Tracker Options on page

109 Setting Log Levels Configuring Logging In This Section Setting Log Levels page 109 Log Capacity page 110 Remote Log Servers page 111 To configure the log: On the navigation tree, click Status and Logs > Log Settings. The Log Settings page appears. The Traffic Log Levels and Audit Log Level sections are displayed in the following figure: FIGURE 7-4 Traffic Log Levels and Audit Log Level sections Setting Log Levels Select the specific log levels for the Traffic Logs, for various aspects of user interactions with Connectra, and select the specific log level for the Audit Log. Chapter 7 Status and Logging 109

110 Configuring Logging Log Capacity The Log Capacity and Remote Log Servers sections are displayed in the following figure: FIGURE 7-5 Log Capacity and Remote Log Servers sections Configure the log capacity by setting the log switching and cyclic logging options. Log switching The size of the active log file is kept below a definable limit. When the limit is reached, i.e. 2GB, the file is closed and a new file opened. This is known as log switching, and can be performed automatically when the log file reaches the specified limit. The file that is closed is written to disk and named according to current date/time. The new file receives the default log file name, fw.log or fw.atdlog Cyclic logging Cyclic logging refers to the require free space option, located in the Log Capacity section. When there is a lack of sufficient free space, the system stops generating logs. To ensure the logging process continues even when there is no more space, a process of cyclic logging is used. This process automatically deletes old files when the specified free disk space limit is reached so that the modules can continue logging. The cyclic process is controlled by: modifying the amount of required free disk space 110

111 Remote Log Servers Preventing the module from deleting logs older than a certain value (one day, two days) Remote Log Servers The Names and IP addresses of the Remote Log Servers are listed in the Remote Log Servers section. To add a Remote Log Server: 1 Click New. The Add Remote Log Server page appears. 2 Enter the server name or IP address, and click OK. Establishing Trust between Connectra and a SmartCenter Server After adding a Remote Log Server to Connectra, you must establish trust between Connectra and the SmartCenter server, in order to enable log forwarding. For more information refer to Appendix B, Establishing Trust between Connectra and a SmartCenter Server on page 131. Chapter 7 Status and Logging 111

112 Configuring Logging 112

113 CHAPTER 8 Customizing the User Portal In This Chapter: The Need for Customization page 113 Customizing Look & Feel page 113 The Need for Customization Since the user portal must reflect the company, it is important to be able to change elements from their out-of-the-box defaults. The Connectra administration portal contains a user customization page that lets you change: Portal language Portal Title Company logo Company homepage Customizing Look & Feel In This Section Changing the Language page 114 Changing the Title page 114 Changing the Company Logo page 114 Changing the Company s URL page

114 Customizing Look & Feel The composition of the users portal is determined by selecting Settings > Portal Look and Feel. The Portal Look and Feel page appears: FIGURE 8-1 Portal Look and Feel page Changing the Language In the portal language field, select the language from a drop-down list. Changing the Title In the portal title field, enter the name of your company, or any other text. Changing the Company Logo In the company Logo file field, browse to a folder or network node where company logo/icons are kept. It is recommended to copy company logo/icons into a folder on the Connectra Gateway and then reference them from that point. Changing the Company s URL In the Company Logo URL field, enter the URL of the company s intranet homepage, or any other URL that can serve as a starting point. 114