Connectra-1.0 Administration Guide

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 Points SecureKnowledge at:
http://support.checkpoint.com/kb/
See the latest version of this document in the User Center at:
http://www.checkpoint.com/support/technical/documents/
docs_r55.html
Part No.: 00000
June 2004
2003-2004 Check Point Software Technologies Ltd. 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
All rights reserved. This product and related documentation are protected by copyright OTHER DEALINGS IN THE SOFTWARE.
and distributed under licensing restricting their use, copying, distribution, and The following statements refer to those portions of the software copyrighted by The OpenSSL
decompilation. No part of this product or related documentation may be reproduced in Project. This product includes software developed by the OpenSSL Project for use in the
any form or by any means without prior written authorization of Check Point. While every OpenSSL Toolkit (http://www.openssl.org/).
precaution has been taken in the preparation of this book, Check Point assumes no
THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT `ÀS IS'' AND ANY *
responsibility for errors or omissions. This publication and features described herein are
EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
subject to change without notice.
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR ITS
RESTRICTED RIGHTS LEGEND: CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
Use, duplication, or disclosure by the government is subject to restrictions as set forth in EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
DFARS 252.227-7013 and FAR 52.227-19. PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY
OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
TRADEMARKS: NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Check Point, the Check Point logo, ClusterXL, ConnectControl, FireWall-1, FireWall-1 The following statements refer to those portions of the software copyrighted by Eric Young.
GX, FireWall-1 SecureServer, FireWall-1 SmallOffice, FireWall-1 VSX, FireWall-1 XL, THIS SOFTWARE IS PROVIDED BY ERIC YOUNG `ÀS IS'' AND ANY EXPRESS OR
FloodGate-1, INSPECT, INSPECT XL, IQ Engine, MultiGate, Open Security Extension, IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
OPSEC, Provider-1, SecureKnowledge, SecurePlatform, SecureXL, SiteManager-1, OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
SmartCenter, SmartCenter Pro, SmartDashboard, SmartDefense, SmartLSM, SmartMap, DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR
SmartUpdate, SmartView, SmartView Monitor, SmartView Reporter, SmartView Status, ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
SmartView Tracker, SmartConsole, TurboCard, Application Intelligence, SVN, UAM, DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE
User-to-Address Mapping, UserAuthority, VPN-1, VPN-1 Accelerator Card, VPN-1 Net, GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
VPN-1 Pro, VPN-1 SecureClient, VPN-1 SecuRemote, VPN-1 SecureServer, VPN-1 INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER
SmallOffice and VPN-1 VSX are trademarks or registered trademarks of Check Point IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
Software Technologies Ltd. or its affiliates. All other product names mentioned herein are OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
trademarks or registered trademarks of their respective owners. ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. Copyright 1998 The Open Group.
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 The following statements refer to those portions of the software copyrighted by
patents, or pending applications. Jean-loup Gailly and Mark Adler Copyright (C) 1995-2002 Jean-loup Gailly and
Mark Adler. This software is provided 'as-is', without any express or implied
THIRD PARTIES: 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
Entrust is a registered trademark of Entrust Technologies, Inc. in the United States and other any purpose, including commercial applications, and to alter it and redistribute it
countries. Entrusts logos and Entrust product and service names are also trademarks of freely, subject to the following restrictions:
Entrust Technologies, Inc. Entrust Technologies Limited is a wholly owned subsidiary of
1. The origin of this software must not be misrepresented; you must not claim that
Entrust Technologies, Inc. FireWall-1 and SecuRemote incorporate certificate management
you wrote the original software. If you use this software in a product, an
technology from Entrust.
acknowledgment in the product documentation would be appreciated but is not
required.
Verisign is a trademark of Verisign Inc.
2. Altered source versions must be plainly marked as such, and must not be
The following statements refer to those portions of the software copyrighted by University of
misrepresented as being the original software.
Michigan. Portions of the software copyright 1992-1996 Regents of the University of
Michigan. All rights reserved. Redistribution and use in source and binary forms are permitted 3. This notice may not be removed or altered from any source distribution.
provided that this notice is preserved and that due credit is given to the University of The following statements refer to those portions of the software copyrighted by the
Michigan at Ann Arbor. The name of the University may not be used to endorse or promote Gnu Public License. This program is free software; you can redistribute it and/or
products derived from this software without specific prior written permission. This software is modify it under the terms of the GNU General Public License as published by the
provided as is without express or implied warranty. Copyright Sax Software (terminal Free Software Foundation; either version 2 of the License, or (at your option) any
emulation only). later version. This program is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
The following statements refer to those portions of the software copyrighted by Carnegie MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Mellon University. General Public License for more details.You should have received a copy of the
Copyright 1997 by Carnegie Mellon University. All Rights Reserved. GNU General Public License along with this program; if not, write to the Free
Permission to use, copy, modify, and distribute this software and its documentation for any Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
purpose and without fee is hereby granted, provided that the above copyright notice appear The following statements refer to those portions of the software copyrighted by Thai Open
in all copies and that both that copyright notice and this permission notice appear in Source Software Center Ltd and Clark Cooper Copyright (c) 2001, 2002 Expat maintainers.
supporting documentation, and that the name of CMU not be used in advertising or publicity Permission is hereby granted, free of charge, to any person obtaining a copy of this software
pertaining to distribution of the software without specific, written prior permission.CMU and associated documentation files (the "Software"), to deal in the Software without
DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL restriction, including without limitation the rights to use, copy, modify, merge, publish,
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the
CMU BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR Software is furnished to do so, subject to the following conditions: The above copyright notice
ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, and this permission notice shall be included in all copies or substantial portions of the
WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
THIS SOFTWARE. MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
The following statements refer to those portions of the software copyrighted by The Open IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
Group. CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. GDChart is free for use in your applications and for chart generation. YOU MAY NOT re-
IN NO EVENT SHALL THE OPEN GROUP BE LIABLE FOR ANY CLAIM, DAMAGES OR distribute 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, 2001. 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) 628-2000 Fax: (650) 654-4233, info@CheckPoint.com
International Headquarters: 3A Jabotinsky Street, Ramat Gan, 52520, Israel, Tel: 972-3-753 4555 Fax: 972-3-575 9256, http://www.checkpoint.com
RR02188 by the National Institutes of Health. Portions copyright 1996, 1997, 1998, 1999, PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY
2000, 2001, 2002 by Boutell.Com, Inc. Portions relating to GD2 format copyright 1999, 2000, OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
2001, 2002 Philip Warner. Portions relating to PNG copyright 1999, 2000, 2001, 2002 Greg NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
Roelofs. Portions relating to gdttf.c copyright 1999, 2000, 2001, 2002 John Ellson SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
(ellson@graphviz.org). Portions relating to gdft.c copyright 2001, 2002 John Ellson This software consists of voluntary contributions made by many individuals on behalf of the
(ellson@graphviz.org). Portions relating to JPEG and to color quantization copyright 2000, PHP Group. The PHP Group can be contacted via Email at group@php.net.
2001, 2002, Doug Becker and copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, For more information on the PHP Group and the PHP project, please see <http://
2001, 2002, Thomas G. Lane. This software is based in part on the work of the Independent www.php.net>. This product includes the Zend Engine, freely available at <http://
JPEG Group. See the file README-JPEG.TXT for more information. Portions relating to www.zend.com>.
WBMP copyright 2000, 2001, 2002 Maurice Szmurlo and Johan Van den Brande. Permission This product includes software written by Tim Hudson (tjh@cryptsoft.com).
has been granted to copy, distribute and modify gd in any context without fee, including a
Copyright (c) 2003, Itai Tzur <itzur@actcom.co.il>
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 All rights reserved.
is to assure proper credit for the authors of gd, not to interfere with your productive use of gd. Redistribution and use in source and binary forms, with or without modification, are permitted
If you have questions, ask. "Derived works" includes all programs that utilize the library. provided that the following conditions are met:
Credit must be given in user-accessible documentation. This software is provided "AS IS." Redistribution of source code must retain the above copyright notice, this list of conditions
The copyright holders disclaim all warranties, either express or implied, including but not and the following disclaimer.
limited to implied warranties of merchantability and fitness for a particular purpose, with Neither the name of Itai Tzur nor the names of other contributors may be used to endorse or
respect to this code and accompanying documentation. Although their code does not appear promote products derived from this software without specific prior written permission.
in gd 2.0.4, the authors wish to thank David Koblas, David Rowley, and Hutchison Avenue THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
Software Corporation for their prior contributions. "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
except in compliance with the License. You may obtain a copy of the License at http:// PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
www.apache.org/licenses/LICENSE-2.0 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
The curl license SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
COPYRIGHT AND PERMISSION NOTICE LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
Copyright (c) 1996 - 2004, Daniel Stenberg, <daniel@haxx.se>.All rights reserved. DATA, OR PROFITS; OR BUSINESS
Permission to use, copy, modify, and distribute this software for any purpose INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER
IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
with or without fee is hereby granted, provided that the above copyright
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
notice and this permission notice appear in all copies. ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS Copyright (c) 1998, 1999, 2000 Thai Open Source Software Center Ltd
OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
Permission is hereby granted, free of charge, to any person obtaining a copy of this software
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT
and associated documentation files (the "Software"), to deal in the Software without
OF THIRD PARTY RIGHTS. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
restriction, including without limitation the rights to use, copy, modify, merge, publish,
HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN
distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the
AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
Software is furnished to do so, subject to the following conditions: The above copyright notice
CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
and this permission notice shall be included in all copies or substantial portions of the
SOFTWARE.
Software.
Except as contained in this notice, the name of a copyright holder shall not be used in
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
advertising or otherwise to promote the sale, use or other dealings in this Software without
OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
prior written authorization of the copyright holder.
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
The PHP License, version 3.0 IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
Copyright (c) 1999 - 2004 The PHP Group. All rights reserved. CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
Redistribution and use in source and binary forms, with or without modification, is permitted TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
provided that the following conditions are met: SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWA
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 <http://www.php.net/>".
THIS SOFTWARE IS PROVIDED BY THE PHP DEVELOPMENT TEAM `ÀS 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
Check Point Software Technologies Ltd.

U.S. Headquarters: 800 Bridge Parkway, Redwood City, CA 94065, Tel: (650) 628-2000 Fax: (650) 654-4233, info@CheckPoint.com
International Headquarters: 3A Jabotinsky Street, Ramat Gan, 52520, Israel, Tel: 972-3-753 4555 Fax: 972-3-575 9256, http://www.checkpoint.com
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
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 Email Services 46
Configuring File Shares 50
Associating Applications with User Groups 51
Managing Users and Groups

The Need for Managing Users and Groups 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
Table of Contents 5
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
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
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
Status 104
Audit Log 105
Traffic Log 107
Configuring Logging 109
Setting Log Levels 109
Log Capacity 110
Remote Log Servers 111
111
Customizing the User Portal
6
The Need for Customization 113
Customizing Look & Feel 113
Changing the Language 114
Changing the Title 114
Changing the Company Logo 114
Changing the Companys URL 114
114
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
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
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.

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
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 email 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 email 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 email 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

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
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

client side:
1 Connectra implements Secure Configuration Verification of the remote users
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.

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.
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
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.

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
Deploying Connectra
After installation, the administrator must perform initial configuration and deployment
of Connectra.
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.

TABLE 1-1 Example Rules for deploying connectra in the DMZ
Rule Source Destination Service Action Comment

1 Admin Connectra HTTPS/4433 Accept Administrator access.
host (encrypted)
2 Any Connectra HTTP/80 Accept End user access to portal
HTTPS/443 for
Web applications,
File sharing
Web mail.
HTTP is only for
redirection. All actual
communication is
encrypted.
3 Connectra LAN HTTP/80 Accept Connectra to LAN for
HTTPS/443 Web applications
IMAP/143 (encrypted)
POP3/110 File sharing
nbsession/TCP (unencrypted)
port 139 Web mail
microsoft-ds/ (unencrypted)
TCP port 445
nbdatagram
/UDP port 138
nbname/UDP
port 137
4 Any Connectra POP3/110 Accept End user access for native
POP3-SSL/995 mail clients (both
SMTP/25 encrypted and
SMTP-SSL/465 unencrypted).
5 Connectra LAN POP3/110 Accept Connectra to LAN for
SMTP/25 native mail clients
(unencrypted)
Other rules may well be needed, depending on the configuration:
Connectra requires access to DNS servers and possibly to WINS servers
For backups, Connectra may need access to a TFTP or SCP server.
18
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 Connectras 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

Defining an application is about deciding which internal LAN applications to expose to

remote users. Typically:
Web applications
Email 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 Connectras logging capabilities, the administrator can monitor and analyze
network activity of remote users. Connectras 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
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, email 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

Connectra Administration Portal

In This Section:
Overview page 22
Using the Administration Portal page 22
Overview
Connectra enables secure access to remote users, requiring only minimal user input of
basic configuration elements, such as IP addresses, routing information, etc. An
easytouse 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: https:\\192.168.1.1:4433, 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
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
https://<management IP address>:4433. The default administration IP address is
192.168.1.1.
2 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.

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,
Email servers and File shares) which can be made available to
remote users.
24
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

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

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
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 6000.
If the usage of the appliance exceeds the terms of the license, you may purchase a
suitable license from the checkpoint user-center:
https://usercenter.checkpoint.com/usercenter/index.jsp
To add a license:
1 Obtain a license from: https://usercenter.checkpoint.com/usercenter/index.jsp
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.

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
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:

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 Connectras 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
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:8080.
3 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.

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
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:

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 Connectras 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
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:
Defining Allowed IP Address for Administrators page 35

Creating Connectra Administrators page 36
Settings page 36
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.

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
Administrators account after <x> login failures.
4 Set the Unlock Administrators account after <y> minutes.
5 Click Apply.
36
CHAPTER 2
Defining Applications
In This Chapter
The Need for Defining Applications page 37

Configuring Connectra Applications page 44
The Need for Defining Applications

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.

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
Email services
File shares
37
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
www.checkpoint.com/wwseresources/*; 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 users 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
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

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

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

What is a mail service

A mail service enables users to use their email 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 Email 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 email and address books. Employees can access their email 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 email 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 email 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
While the Connectra portal offers a web email interface, many users will prefer to take
advantage of their native email clients, for example: Outlook, Netscape, or Eudora.
Connectras 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 email 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.
Email 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 email. Once authenticated, users can not only compose, send and
receive email but also:
Create, delete, rename, and manipulate mail folders
Index messages in various ways
Stores addresses
Search emails according to various criteria, such as body text, subject, senders
address, etc.
Highlight messages with different background colors, enabling quick differentiation
Display preferences

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 e-mail, calendaring, and contacts.
Native mail
While the Connectra portal offers a web email interface, many users will prefer to take
advantage of their native email clients, for example: Outlook, Netscape, Eudora.
Connectras 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 email client.
The same applies when mail is sent using SMTP.
42
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.

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.

In This Section:
Configuring Web Applications page 44

Configuring Email 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
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, www.mycompany.com
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:

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 Email 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
A display name
3 In the Security section, supply:
A protection level
4 In the SMTP Server section, supply:
A host name, for example, www.mycompany.com
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:

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
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.

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
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.

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
CHAPTER 3
Managing Users and

Groups
In This Chapter
The Need for Managing Users and Groups 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.

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
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.

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
Creating Internal User Groups
FIGURE 3-1 Adding a new user page
3 In the User Details section:

Supply a login name
Enter the users 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

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
Working with LDAP Groups
Configuring External User Groups

In This Section:
Working with LDAP Groups page 57

Working with RADIUS Servers page 60

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. Connectras LDAP client then handles
authentication and examines the specified LDAP branches to retrieve the users 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 External 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 users 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
Creating an LDAP Group
To create an LDAP Group:


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
Select the web applications that are to be accessible to the LDAP Group
members, and add them to the Applications for this group.

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. Connectras RADIUS client then handles
authentication and examines the specified RADIUS class to retrieve the users 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
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:

Internal Group
LDAP Group
RADIUS Group

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.

Select the web applications that are to be accessible to the RADIUS Group
members, and add them to the Applications for this group.
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
CHAPTER 4
Authentication and
Authorization
In This Chapter
The Need for Authentication and Authorization 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.

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
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
applications 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 Group Server

Connectra (Internal Internal
database)
LDAP LDAP
RADIUS LDAP
ACE LDAP
RADIUS/ACE Internal
RADIUS RADIUS
Client certificates LDAP/ Internal
64
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 users 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 users
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

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 applications 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 users groups. Once the LDAP or RADIUS groups are mapped to the users
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 requirements
Protection Authentication
Level
Standard Username/password
High SecurID
Advanced 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.

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
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 organizations 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.

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
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

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
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).

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 companys 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

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
7 Click Apply.

74
CHAPTER 5
Using Certificates
In This Chapter
The Need for Certificates 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 networks applications..

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
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
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

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
Importing a Client Certificate to Internet Explorer
Configuring Client Certificates

In This Section:
Importing a Client Certificate to Internet Explorer page 79

Client Certificate Verification page 82
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 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 administrators instructions.
3 In Microsoft Internet Explorer, select Tools > Options. The Internet Options
window appears. The General tab is displayed:
FIGURE 5-4 Internet Options window

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
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:

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
CHAPTER 6
Security
In This Chapter
The Need for Security page 83

Configuring Session Time-Outs page 86
Configuring Web Intelligence page 87
Using Client Side Security page 95
The Need for Security

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.

In This Section:
General Security Issues page 84

Web Intelligence Protections page 85
Client Side Security page 86
83
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

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
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

client side:
1 Connectra implements Secure Configuration Verification of the remote users
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
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
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.
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 Buffer Overflow Protection Security Levels
Security Description
Level
Low Inspects any suspicious URL or HTTP header. When
the HTTP header is found to be suspicious, the HTTP
body is also inspected.
Normal 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.
High Inspects all URLs and HTTP headers. Inspects HTTP
body if either the HTTP header of HTTP body is
suspicious.
88
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.

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.
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 Cross Site Scripting Protection Security Levels
Level
Low Rejects requests with keywords related to scripts (e.g.,
script, ActiveX object, applet, etc.) when located inside
HTML tags.
Normal Rejects requests that have any HTML tags.
High 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
The following table defines the Security Levels that may be assigned to SQL Injection
protection.
TABLE 6-3 SQL Injection Protection Security Levels
Level
Low Rejects forms and URLs that contain special SQL
characters or distinct SQL commands in the path and
form fields.
Normal Rejects forms and URLs that contain special SQL
characters, distinct SQL commands, or non-distinct SQL
commands in the path and form fields.
High 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.).
The following table defines the Security Levels that may be assigned to Command
Injection protection.
TABLE 6-4 Command Injection Protection Security Levels
Level
Low Rejects forms that contain special Shell characters and
distinct Shell commands in the path and form fields.
Normal Rejects forms that contain special Shell characters,
distinct Shell commands, and non-distinct Shell
commands in the path and form fields.
High 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,
"http://www.server.com/first/second/../../.." is illegal because it goes deeper than the
root directory. "http://www.server.com/first/second/../" is legal because it is equivalent
to "http://www.server.com/first/". 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
Configuring HTTP Protocol Inspection
To enable Application Layer Protection:

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.
To enable HTTP Protocol Inspection:

appears. The HTTP Protocol Inspection section is shown in the following figure:
FIGURE 6-4 HTTP Protocol Inspection section
2 In the section, decide whether to enable HTTP Format.

HTTP Protocol Inspection
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
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
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 Description

Worms Programs or algorithms that replicate
over a computer network for the
purpose of disrupting network
communications or damaging software
or data.
Trojan horses Malicious programs that masquerade as
harmless applications.
Hacker tools Tools that facilitate a hackers access to a
computer and/or the extraction of data
from that computer.
Keystroke loggers Programs that record user input activity
(that is, mouse or keyboard use) with or
without the users consent. Some
keystroke loggers transmit the recorded
information to third parties.
Adware Programs that display advertisements, or
records information about Web use
habits and store it or forward it to
marketers or advertisers without the
users authorization or knowledge.
Browser plug-ins 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
Administrator Configuration of CV
TABLE 6-5 Screened Software Types
Software Type Description

Dialers Programs that change the users 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.
3rd party cookies Cookies that are used to deliver
information about the users Internet
activity to marketers.
Other undesirable Any unsolicited software that secretly
software 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.
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
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:
FIGURE 6-8 Server Confirmation window
The user is asked to confirm that the listed CV server is identical to the
organizations site for remote access.
2 If the user clicks Yes,
the CV client continues the software scan. Moreover, if the
checkbox is selected, the Server Confirmation
Save this confirmation for future use
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
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 Description

Scan Again 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.
Cancel Prevents the user from proceeding with
the portal login, and closes the current
browser window.
Continue 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 administrators 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 administrators Traffic Log. However, a Continue button is
displayed, and the user may proceed to access the portal.

102
CHAPTER 7
Status and Logging
In This Chapter
The Need for Status and Logging Information 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

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
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 Points 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
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

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 Color

Administrator Login GREEN
Object Manipulation BLUE
Failure RED
Audit Log Tracker Options

The following table lists the various Log Tracker options:
TABLE 7-2 Audit Log Options
Option Description
Find 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.
Log Number Allows you to navigate to a specific log
entry. Enter the log entry ID number
and click Go.
File 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.
Filter 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
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 Color
Web BLUE
Native Mail PURPLE
Failure RED
File Shares BLACK
Session Timeout BLACK
Portal Event BLACK

TABLE 7-3 Traffic log category and access color code
Description Color
Login/Logout BLACK
Success GREEN
Access denied 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 106.
108
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.

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
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
section.
Servers
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.

Configuring Logging
112
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 Companys URL page 114
113
Customizing Look & Feel
The composition of the users portal is determined by selecting Settings > Portal Look
The Portal Look and Feel page appears:
and Feel.
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 Companys URL

In the Company Logo URL field, enter the URL of the companys intranet homepage,
or any other URL that can serve as a starting point.
114
CHAPTER 9
Troubleshooting
This chapter provides you with a list of error messages that you may encounter while
working with Connectra, and teaches you how to deal with the issues involved. Most of
the error messages involve field validation errors. The error messages appear in red at
the top of the HTML page, being viewed.
TABLE 9-1 Connectra Error Messages
Error Message Solution

One of the parameters was incorrect. Reaccess the page.
Whitespaces may not be part of an Instead of a whitespace, use an underscore
object names. in the name.
The login name is invalid. Enter a valid login name.
Login name must be 1 to 100
characters long and cannot contain
spaces.
Invalid comment. Indicates that the comment is too long.
Shorten it.
Invalid host name. Check for whitespaces and illegal
characters. Legal characters are the
alphanumeric characters, underscore,
hyphen and period.
The login distinguished name (DN) The correct syntax is either cn=<x>, or
is invalid. dn=<y>.
The branch distinguished name The correct syntax is dn=<y>.
(DN) is invalid.
The group common name (CN) is The correct syntax is cn=<x>.
invalid.
115

The LDAP branch's branch is The correct syntax is dn=<y>.
invalid.
The LDAP branch's group is invalid. The correct syntax is cn=<x>.
Invalid port number. Number outside range.
Invalid protection level. Reaccess the page.
Invalid incoming host. Host name is incorrect. Check for
whitespaces and illegal characters. Legal
characters are the alphanumeric
characters, underscore, hyphen and
period.
Invalid incoming port. Port is out of range.
Invalid incoming protocol. Reaccess the page.

Invalid outgoing host. Host name is incorrect. Check for
period.
Invalid outgoing port. Port is out of range.
Invalid http host. Host name is incorrect. Check for
period.
Invalid https host. Host name is incorrect. Check for
period.
Invalid http port. Port is out of range.
Invalid https port. Port is out of range.
Empty http host. Enter value for http host.
Empty https host. Enter value for https host.
Empty http port. Enter value for http port.
116

Empty https port. Enter value for http port.
No user exists with this name. You must define this user name.
Invalid ID. You must verify that this ID exists.
Invalid full name. Full names must Enter valid full name.
be 1 to 50 characters long.
Invalid authentication scheme. Reaccess the page.
Internal password must be 4 to 8 Enter valid Internal password.
characters long. Please note that
spaces are being stripped from the
beginning and end of the password.
Invalid group name. Verify that this group exists.
Invalid group name. Group names Group name out of range.
must be 1 to 50 characters long.
A group with this name already Rename the group.
exists.
Invalid active session timeout: Session timeout value out of range.
number of minutes should be
between 1 and 1500.
Invalid idle session timeout. number Session timeout value out of range.
of minutes should be between 1 and
1500.
The host name cannot be resolved Either the host does not exist, or a
into a valid IP address. Please make mistake was made in the host name. It is
sure the server name is spelled also possible that the DNS configuration
correctly. Also, please verify that the is incorrect.
DNS settings are in order.
The name given to the object is Enter a valid name.
invalid. Please make sure the name
starts with a letter, is not a reserved
word, and does not contain spaces.
The display name given to the object Enter a valid display name.
is invalid.
The portal title given is invalid. No portal title was entered. Enter a valid
portal title.
Chapter 9 Troubleshooting 117


No LDAP server has been Configure the LDAP server.
configured. You must configure the
LDAP server in order to define
LDAP user groups.
No RADIUS server has been Configure the RADIUS server.
configured. You must configure the
RADIUS server in order to define
RADIUS user groups.
Invalid Windows domain. Windows domain name is incorrect.
Check for whitespaces and illegal
characters. Legal characters are the
alphanumeric characters, underscore,
hyphen and period.
Invalid URL. An example of valid URL syntax is:
http://checkpoint.com
Invalid Display Name. Enter valid Display Name.

Invalid URL tooltip. Enter valid URL tooltip.
Invalid LDAP server address. Enter valid LDAP server address.
Confirmed password is different Try again.
from original password.
The RADIUS server has not been Configure the RADIUS server.
configured. Authentication scheme
has been defaulted to LDAP.
Failed to fetch the LDAP branches. Verify all the parameters. Try again.
Invalid RADIUS server address. Enter valid RADIUS server address.
A host with this name already exists. Select another host.
Could not connect to the Check that the server is up and that the
management server. license has not expired.
The object was not found. Verify that the object exists.
The object could not be created. Contact Support.
Could not save the current settings. Contact Support.
The object could not be deleted. Contact Support.
The software license is invalid. Renew the software license.
118

Files did not upload to server Select another certificate.
correctly.
Certificate file is invalid. Select another certificate.
Private key file is invalid. Select another certificate.
Certificate and key files do not Select another certificate.
match.
Private key's password missing or Select another certificate.
incorrect.
Received an invalid filename for the Select another CA file.
trusted CA file.
Invalid traffic log level. Reaccess the page.
Invalid audit log level. Reaccess the page.
Invalid debug log level. Reaccess the page.
Invalid logged user. Did not provide username for Debug
Log.
Invalid log switch interval. Values Log switch interval value out of range.
must range between 1 and 2048.
Invalid minimum free space for Minimum free space for logging value out
logging. Values must range between of range.
1 and 32000.
Invalid log expiration value. Did not enter log expiration value, or it is
out of range.
Invalid logging script path. Path must start with /.
Invalid color for title bar text. Enter valid color for title bar text.
Invalid color for title bar Enter valid color for title bar background.
background.
Invalid color for inner bar text. Enter valid color for inner bar text.
Invalid color for inner bar Enter valid color for inner bar
background. background.
Failed to copy the company logo Try again. Select another file.
file.
The logo path name is empty. Provide logo path name.
Chapter 9 Troubleshooting 119


Invalid IMAP type. Try again.
Invalid Network Mask. Verify Network Mask.
Invalid language selected. Try again.
Could not connect to the Check that the server is up and that the
management server. license has not expired.
120
CHAPTER 10
SecurePlatform CLI
In This Chapter
Check Point SecurePlatform Overview page 121

Managing SecurePlatform page 121
Secure Shell page 122
SecurePlatform Shell Commands page 123
Copying Files Using SCP page 126
Check Point SecurePlatform Overview

The Connectra appliance utilizes a customized and hardened operating system: Check
Point SecurePlatform.
The system is pre-configured and optimized to facilitate the task of enabling 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 shell provides a set of commands required for easy configuration and rou-
tine administration of a security system, including: network settings, backup and restore
utilities, upgrade utility, system log viewing and control. A Web GUI enables most of the
administration configuration, as well as the first time installation setup, to be performed
from an easytouse Web interface.
Managing SecurePlatform
This section provides information on how to manage your Connectra system, using the
SecurePlatform Command Shell. The Command Shell provides a set of commands
required for configuration, administration and diagnostics of various system aspects.
SecurePlatform Command Shell uses standard shell command line editing conventions.
121
Secure Shell
SecurePlatform Shell includes two permission levels (Modes): Standard and Expert.
Standard Mode
Standard Mode is the default mode when logging in to a SecurePlatform system. In
Standard Mode the SecurePlatform Shell provides a set of commands required for easy
configuration and routine administration of a SecurePlatform system. Standard Mode
displays this prompt: [hostname]#, where hostname is the host name of the machine.
Expert Mode
Expert Mode provides the user with full system root permissions and a full system shell.
Switching from Standard Mode to Expert Mode requires a password. The first time you
switch to Expert mode you will be asked to select a password. Until then, the password
is the same as the one you set for Standard Mode. To exit Expert Mode run the
command exit. Expert Mode displays this prompt: [Expert@hostname]# where
hostname is the host name of the machine.
NOTE: Expert Mode should be used with caution. The flexibility of an open shell
with a root permission exposes the system to the possibility of administrative errors.
Secure Shell
Connectra enables SSH access, allowing secured, authenticated and encrypted access to the
SecurePlatform system. SSH (or Secure SHell) is a protocol for creating a secure connec-
tion between two systems. In the SSH protocol, the client machine initiates a connection
with a server machine. The following safeguards are provided by SSH:
After an initial connection, the client can verify that it is connecting to the same
server during subsequent sessions.
The client can transmit its authentication information to the server, such as a
username and password, in an encrypted format.
All data sent and received during the connection is transferred using strong
encryption, making it extremely difficult to decrypt and read.
The SSH service runs by default. Granular control of permitted IP addresses that are
allowed access to the SecurePlatform system using SSH can be set using the Connectra
administration portal. SSH login is allowed using the Standard Mode account user name
and password only.
122
Expert Mode Command
SecurePlatform Shell Commands

In This Section:
Expert Mode Command page 123

Backup and Restore page 123
Snapshot Image Management page 124
Web Administration Server Control page 125
Check Point Commands page 126
Network Diagnostics Commands page 126
This section describes commonly used SecurePlatform shell commands. These

commands are required for configuration, administration and diagnostics of various
system aspects.
NOTE: All commands are case sensitive.
Expert Mode Command

Switch from Standard Mode to Expert Mode.
Syntax
expert
Description
After issuing the expert command supply the expert password, after password
verification you will be switched into expert mode.
Backup and Restore

Connectra provides a command line or Web GUI capability for conducting backups of
your system settings and products configuration. The backup utility can store backups
either locally on the SecurePlatform machine hard drive or remotely to a TFTP server or
SCP server. The backup can be performed on request, or it can be scheduled to take place
at set intervals. The backup files are kept in tar gzipped format (.tgz). Backup files saved
locally are kept in /var/CPbackup/backups. The restore command line utility is used for
restoring SecurePlatform settings and/or Product configuration from backup files.
NOTE: Only administrators with Expert permission can directly access directories of a
Connectra system.
Chapter 10 SecurePlatform CLI 123

SecurePlatform Shell Commands
backup
Backup the system configuration. The backup command, run by itself, without any
additional flags, will use default backup settings and will perform a local backup.
Syntax:
backup [-h] [-d] [--purge DAYS] [--sched [on hh:mm <-m DayOfMonth> | <-w
DaysOfWeek>] | off] [[--tftp <ServerIP> [<Filename>]] | [--scp
<ServerIP> <Username> <Password> [<Filename>]] | [--file <Filename>]]
restore
Restore the system configuration.
Syntax:
restore [-h] [-d][[--tftp <ServerIP> <Filename>] | [--scp <ServerIP>
<Username> <Password> <Filename>] | [--file <Filename>]]
Snapshot Image Management

Enables taking a snapshot of the entire system and to restore the system from the
snapshot are available. The system can be restored at any time, and at boot time the user
is given the option of booting from any of the available snapshots. This feature greatly
reduces the risks involved in configuration changes. The snapshot and revert commands
can use a TFTP server, SCP Server to store snapshots, or snapshots can be stored
locally.
snapshot
This command creates a snapshot file. The snapshot command, run by itself, without
any additional flags, will use default backup settings and will create a local snapshot.
Syntax:
snapshot [-h] [-d] [[--tftp <ServerIP> <Filename>] | [--scp <ServerIP>
revert
Reboot the system from a snapshot file. The revert command, run by itself, without
any additional flags, will use default backup settings and will reboot the system from a
local snapshot.
Syntax:
revert [-h] [-d] [[--tftp <ServerIP> <Filename>] | [--scp <ServerIP>
124
Web Administration Server Control
Web Administration Server Control

cpadmin
In SecurePlatform expert mode, you can start, stop and restart the Web administration
server that manages the Connectra portal.
Syntax: cpadmin { start | stop | restart }
cpadminip
In SecurePlatform expert mode, you may limit access of administrators to specific IPs or
networks.
NOTE: In SecurePlatform mechines, SSH access to the Connectra appliance is also
governed by this setting.
Syntax: cpadmin { -add | -rem | -allowAll | -print}
Parameters
TABLE 10-1 cpadminip Parameters
parameter meaning
-add Adds an IP or network to the list of allowed
addresses.
-rem Removes an IP or a network from the list of
allowed addresses.
-allowAll If True, would allow to connect from any
address. If False, would allow only addresses,
specified in the list of allowed addresses.
-print Shows the allowed IPs (all, or a list).
Chapter 10 SecurePlatform CLI 125

Copying Files Using SCP
Check Point Commands

The following commands start and stop all Connectra module processes (not including
the Web administration server).
cpstart
cpstart starts all the Check Point applications running on a machine (other than
cprid, which is invoked upon boot and keeps on running independently). cpstart
implicitly invokes fwstart (or any other installed Check Point product, such as
etmstart, uagstart, etc.).
Syntax: cpstart
cpstop
cpstop stops all the Check Point applications running on a machine (other than cprid,
which is invoked upon boot and keeps on running independently). cpstop implicitly
invokes fwstop (or any other installed Check Point product, such as etmstop, uagstop,
etc.).
Syntax: cpstop
cplic
Show, add or remove Check Point licenses.
Syntax: cplic { put | del | print | check }
Network Diagnostics Commands

ping
send ICMP ECHO_REQUEST packets to network hosts.
Syntax:
ping [-dfnqrvR] [-c count] [-i wait] [-l preload] [-p pattern] [-s
packetsize]
Copying Files Using SCP

You can use SecureCopy (SCP) to copy files to and from SecurePlatform over a secured
channel. SCP is always available to copy files from SecurePlatform. To copy a file to
SecurePlatform requires configuration. You must create the file /etc/scpusers that
contains a list of users who have SCP access to SecurePlatform. Enter each username in
a separate line.
NOTE: For more detailed information, refer to the SecurePlatform NG with Application
Intelligence (R55) User Guide.
126
APPENDIX A
Configuration of Native
Mail Clients
To utilize the Native Mail feature, you must configure the desired mail client. This
appendix describes how to configure various common mail clients:
Microsoft Outlook 2000
To configure Microsoft Outlook 2000:
1 Select Tools > Options > Mail Services tab.
2 Click Reconfigure Mail Support. The e-mail Service Options window appears.
3 If Internet Only is configured, continue configuration as specified for Microsoft
Outlook Express 6.
4 If Corporate or Workgroup is configured, continue configuration as follows:
5 Select Tools > Services. The Services window appears.
6 Click Add. Select Internet E-mail and click OK.
7 Click Properties. The Mail Account Properties window appears.

8 Continue configuration as specified for Microsoft Outlook 2002.
Microsoft Outlook 2002
To configure Microsoft Outlook 2002: (Existing Email Account))
1 Select Tools > E-mail accounts and click Next.
2 Select an e-mail account and click Change.
3 Click More Settings.
127
4 In the Outgoing Server tab, select the My outgoing server (SMTP) requires
authentication checkbox.
5 In the Advanced tab, select the This server requires a secure connection (SSL)
checkbox for both Incoming server (SMTP) and Outgoing server (POP3).
6 Click OK and click Next.
7 Click Finish.
To configure Microsoft Outlook 2002: (Creating a New Mail Account)

1 Select Tools > E-mail accounts.
2 Click Next and click Add.
3 Select Pop3 and click Next
4 In the User Information section, fill in Your Name and E-mail address.
5 In the Logon Information section, fill in your User name and Password.
NOTE: Use the same user name and password that you use for Connectra.
6 In the Server Information section, enter the Connectra IP address in both Incoming
mail server (POP3) and in Outgoing mail server (SMTP).
7 Click More Settings.
8 In the Outgoing Server tab, select the My outgoing server (SMTP) requires
authentication checkbox.
checkbox for both Incoming server (SMTP) and Outgoing server (POP3).
10 Click OK.
NOTE: You can test the connection to the mail server by clicking Test account
Settings. All categories should be green.
11 Click Next and click Finish.

NOTE: The first time that you try to connect to your account via Connectra you
will be informed that the server requires authentication and asked to confirm.
Microsoft Outlook Express 6
To configure Microsoft Outlook Express 6:
1 Select Tools > Accounts.
2 In the Mail tab, select an e-mail account and click Properties.
128
3 In the Servers tab, select My server requires authentication in the Outgoing mail
server section.
checkbox for both Incoming mail (SMTP) and Outgoing mail (POP3).
5 Click OK and click Close.
Eudora 6
To configure Eudora 6:
1 Select Tools > Options.
2 In the Getting Started tab, select Allow authentication for the SMTP Server
(Outgoing).
3 In the Checking Mail tab, select Required, Alternate port in the Secure Sockets when
receiving section.
4 In the Incoming Mail tab, select Passwords in the Authentication style section.
5 In the Sending Mail tab, select Required, Alternate port in the Secure Sockets when
receiving section.
6 Click OK.
The ports used by the Alternate Port setting are:

For POP3: port 995
For SMTP: port 465
To modify the port for use with Required, Alternate Port:
1 Quit Eudora.
2 Open eudora.ini using Notepad.
3 Add the following settings to eudora.ini under the Settings section:
SMTPSSLAlternatePort=
POPSSLAlternatePort=
IMAPSSLAlternatePort=
4 Place the desired port number after the "=" sign.
Appendix A Configuration of Native Mail Clients 129

5 Once you have entered the desired settings, save the changes and exit Notepad.
When you next open Eudora, the new settings will be in effect.
NOTE: The root CA certificate, issued by the same CA that issued the Connectra
server certificate, must be installed on the client machine. Otherwise, the SSL
negotiation between the client and the server will fail.
Netscape 7.1
To configure Netscape 7.1:
1 Select Edit > Mail and Newsgroups accounts settings.
2 In the Server Settings tab, select Use Secure connection.
3 In the Outgoing Server tab, select Use name and password and fill in the port
number 25.
NOTE: The port number may be left blank.
4 In the same tab, under Use secure connection (SSL), select Always.
5 Click OK.
130
APPENDIX B
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.
On the remote SmartCenter server:

Step 1) Using the command line interface, enter the cpstop command, in order to stop
all of the running servers.
NOTE: Your SmartCenter server will not be able to serve any requests or
receive any logs while stopped.
Step 2) Backup the file: $CPDIR/conf/sic_policy.conf
Step 3) Edit the file: $CPDIR/conf/sic_policy.conf
a Scroll down to the Inbound rules section, and then to the Logs subsection.
b Locate the line:
Log_Server; Modules, Management; ANY; log; sslca
c Add the following line directly beneath the above mentioned line:
ANY; ANY; ANY ; log; ssl
Step 4) Save the file.
131
On the Connectra machine:
Step 5) In the command line interface, enter the following command:

fw putkey -p [one time password] [Connectra machine IP]
For example:
fw putkey -a verysecret 10.50.21.49
TABLE B-1 putkey Parameters
Parameter Description
[one time password] A temporary password, which will be
used to establish trust with the
Connectra machine.
[Connectra machine IP] IP of the Connectra machine from
which logs will be forwarded.
NOTE: You must remember the one time password, in order to use it when
configuring the Connectra machine.
Step 6) Enter the cpstart command in order to start all of the servers anew.

Step 1) Login to the Connectra Administration Portal, and navigate to Status and Logs
> Log Settings.
Step 2) In the Remote Log Servers section, add the IP of the machine to which you
would like to forward Connectra's logs, and click Apply.
Step 3) Using an SSH console, login to the Connectra machine.
Step 4) Enter a cpstop command in order to stop all of the running servers.
NOTE: If users are currently connected to the Connectra machine, they will
be disconnected.
Step 5) Edit the file: $CPDIR/conf/sic_policy.conf
NOTE: If log forwarding has been configured previously on the Connectra
machine (i.e. the SIC policy file has already been configured), there is no
need to repeat the changes to the SIC file. Please skip to step 7.
a Scroll down to the Outbound rules section and then to the Logs
subsection.
132
b Change the line:
ANY; Log_Server; ANY; log; sslca
to:
ANY; ANY; ANY; log; ssl, sslca
Step 6) Save the file.

Step 7) Using the SSH console, enter the following command:
fw putkey -p [one time password] [remote machine IP]
For example:
fw putkey -a verysecret 10.50.21.46
TABLE B-2 putkey Parameters
Parameter Description
[one time password] A temporary password, which will be
used to establish trust with the remote
machine.
[Connectra machine IP] IP of the machine to which Connectra
will forward its logs.
NOTE: The one time password must be identical to the one used when the fw
command was issued on the remote server.
putkey
Step 8) Enter the cpstart command in order to start all of the servers anew.
Once the above procedures have been performed, logs, created on the Connectra
machine, will also be forwarded to the remote SmartCenter server.
Appendix B Establishing Trust between Connectra and a SmartCenter Server 133

134
Index
A Configuration of Native Mail

Clients 127, 131
configuring 57
Configuring Authentication 66
Accessing Applications 21 Configuring Authentication via
Active Directory 60
Active time-out 13
LDAP 67
Configuring Authentication via
F
Administration Concepts 16 Radius 68
Application Intelligence 86 Configuring Connectra 19 File shares
Associating Mail Services with User Configuring Connectra configuration of 50
Groups 50 Applications 44 File shares in Connectra 44
Audit log 105 Configuring Server Certificates 75
Audit Log Options 106 Connectra
Auditing Using Logs 20
Authenticating Users in
Need for 9
what is it? 10 G
Connectra 65 Connectra Email Services 40
Authentication 11 Connectra Security Features 13 General HTTP Worm Catcher 87
Authentication & Authorization 63 Cookie capture 86 General Security Issues 83
Authentication via Certificates 69 Cookies 12
Authorization 12 Creating a Protection Level 71
Cross Site Scripting 89
Customizing H
Changing the Companys
B URL 114 How Connectra Maps LDAP
Changing the Language 114 groups 65
Built-in Webmail 41 Changing the Title 114 How Connectra Maps Radius
Customizing Look & Feel 113 Groups 65
Customizing the User Portal 113 HTTP Protocol Inspection 86, 93
Cyclic logging 110
C
Changing the Company Logo 114 I
Client Certificate D
importing 79 Initial Configuration of
login 76 Debug log 111 Connectra 19
verification 82 Defining Applications 37 Initial Setup 21
Client Certificate Verification 82 Deploying Connectra in the Internal User groups
Client Side Security 85, 95 DMZ 15 creating 55
Client Side Security Highlights 13 Directory Traversal 92 Internal Users
Client Verification 12 adding 54
command configuring 54
expert 123
Command Injection 91 E
Command Line Interface 121
Commonly Used Concepts 11
Compliance
Email services L
configuration of 46
client side security 97 Eudora 6 129 LDAP
Compliance Options 97 Expert Mode 123 configuring 58
External User group LDAP Group
135
creating 59
LDAP Groups S
working with 57
Log Capacity 109 Screened Software Types 96
Log switching 110 Security 13, 83
Server Certificate
automatically generated 76
changing 78
M installing 77
viewing 76
mail Server Side Security 84
what is it 40 Server Side Security Highlights 13
Malicious Code Protectio 87 Session 12
Malicious Code Protector 86 Session Time-Outs 86
Managing Access 19 Session timeouts 86
Managing Users & Groups 53 Setting Protection Level 20
Microsoft Outlook 2000 127 Signing In 20
Microsoft Outlook 2002 127 Spyware 86
Microsoft Outlook Express 6 128 SQL Injection 89, 90
Status 104
Status & Logging 103
N
Native mail 42
T
Need for Customization 113
Need for Status and Logging Time-out
Information 103 active 86
Netscape 7.1 130 passive 86
Traffic log 107
Trouble shooting 115
O
Outlook Web Access 42 U
Understanding Authentication &
Authorization 63
P Understanding the Connectra
Logging Solution 103
Upgrade 29
Passive time-out 12 User Workflow 20
Protection Level 12
Protection-levels
configuring 71
understanding 66 W
Web application explained 38
R Web applications
configuration of 44
Web Intelligence 87
Radius
working with 61
Remote Log Servers 111
136 July 2004

Connectra-1.0 Administration Guide

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Connectra-1.0 Administration Guide

Diunggah oleh

Hak Cipta:

Format Tersedia

Connectra Server

SSL VPN and Web Security Server

Check Point Software Technologies Ltd.

Check Point Software Technologies Ltd.

Managing Users and Groups

Authentication and Authorization

Status and Logging

Customizing the User Portal

Configuration of Native Mail Clients

The Need for Connectra page 9

The Need for Connectra

applications. However, depending on the network circumstances faced by the

The Check Point Solution

Overview - What is Connectra? page 10

Overview - What is Connectra?

How Connectra Works

Commonly Used Concepts

Chapter 1 Introduction to Connectra 11

Connectra Security Features

Server Side Security Highlights

Client Side Security Highlights

Chapter 1 Introduction to Connectra 13

Planning Connectra Deployment page 14

Planning Connectra Deployment

Deployment Overview page 14

Deploying Connectra in the DMZ

Chapter 1 Introduction to Connectra 15

Deploying Connectra on the LAN

Deploying Connectra page 17

The administration workflow comprises the following steps:

Planning Connectra Deployment

In general, it is recommended to deploy Connectra in the DMZ. Connectra can,

Configuring the Firewall Access Rules

Chapter 1 Introduction to Connectra 17

TABLE 1-1 Example Rules for deploying connectra in the DMZ

Rule Source Destination Service Action Comment

Initial Configuration of Connectra

Access management in Connectra is accomplished by defining users and assigning them

Chapter 1 Introduction to Connectra 19

Defining an application is about deciding which internal LAN applications to expose to

Auditing Using Logs

The user workflow comprises the following steps:

Chapter 1 Introduction to Connectra 21

Connectra Administration Portal

Using the Administration Portal

Accessing the Administration Portal for the First Time page 22

Accessing the Administration Portal for the First Time

4 Change the administrator password, as prompted. The First-Time Configuration

6 Initialize Connectra software components, in order to complete the initial

Logging-In to the Connectra Administration Portal

Chapter 1 Introduction to Connectra 23

The Connectra Administration Portal

TABLE 1-2 summarizes the Administration Portal functional areas:

TABLE 1-2 Administrator Portal Functional Areas

Configuring Device, Network and Administrator Settings

Configuring Device and Network Settings page 25

Configuring Device and Network Settings

The Device options are listed below:

Chapter 1 Introduction to Connectra 25

Device Control page 26

To view the active processes running on SecurePlatform:

The Connectra appliance has a pre-configured permanent license that corresponds to

Configuring the Date and Time

To configure the date and time: