TRANSPARENT AUTHENTICATION GUIDE

Transcription

1 TRANSPARENT AUTHENTICATION GUIDE Webwasher Web Gateway Security e Version 6.0 and higher

2 Part Number: A All Rights Reserved, Published and Printed in Germany 2007 Secure Computing Corporation. This document may not, in whole or in part, be copied, photocopied, reproduced, translated, or reduced to any electronic medium or machine-readable form without prior consent in writing from Secure Computing Corporation. Every effort has been made to ensure the accuracy of this manual. However, Secure Computing Corporation, makes no warranties with respect to this documentation and disclaims any implied warranties of merchantability and fitness for a particular purpose. Secure Computing Corporation shall not be liable for any error or for incidental or consequential damages in connection with the furnishing, performance, or use of this manual or the examples herein. The information in this document is subject to change without notice. Webwasher, MethodMix, AV PreScan, Live Reporting, Content Reporter, ContentReporter, Real-Time Classifier are all trademarks or registered trademarks of Secure Computing Corporation in Germany and/or other countries. Microsoft, Windows NT, Windows 2000 are registered trademarks of Microsoft Corporation in the United States and/or other countries. McAfee is a business unit of Network Associates, Inc. CheckPoint, OPSEC, and FireWall-1 are trademarks or registered trademarks of CheckPoint Software Technologies Ltd. or its affiliates. Sun and Solaris are trademarks or registered trademarks of Sun Microsystems, Inc. in the United States and other countries. Squid is copyrighted by the University of California, San Diego. Squid uses some code developed by others. Squid is Free Software, licensed under the terms of the GNU General Public License. NetCache is a registered trademark of Network Appliances, Inc. in the United States and other countries. Linux is a registered trademark of Linus Torvalds. Other product names mentioned in this guide may be trademarks or registered trademarks of their respective companies and are the sole property of their respective manufacturers. Secure Computing Corporation Webwasher A Secure Computing Brand Vattmannstrasse 3, Paderborn, Germany Phone: +49 (0) Fax: +49 (0) info@webwasher.com European Hotline Phone: +49 (0) US Hotline Phone: ,

3 Contents Chapter 1 Introduction Chapter 2 On Authentication Chapter 3 Deployment Planning and Configuration Deployment Scenarios Configuration Steps i

4

5 Introduction Chapter 1 This document provides information on the use of transparent authentication under Webwasher. The information applies to version 6.0 and higher versions of Webwasher. Successful authentication means that a proxy or server knows the user who requested access to an object. A concept related to authentication is policy mapping, but while authentication establishes who requested a resource, policy mapping is used to decide how this request will be handled, i. e. what security policy is applied to it. Usually, authentication is a prerequisite for policy mapping. This document explains some basic concepts of the authentication process, see Chapter 2. Furthermore, it describes some deployment scenarios and the configuration steps required for setting up transparent authentication under Webwasher, see Chapter

6

7 On Authentication Chapter 2 This chapter explains a number of basic concepts to enable a better understanding of what happens when you are setting up authentication under Webwasher. Credential Retrieval Methods There are several methods for retrieving user credentials from a client that sent a request. Note that these methods should be seen independently from the methods chosen for verification of the credentials. The following retrieval methods are dealt with in this document: Basic The client sends the combined user name and password as request header in base64-encoded format to the destination, e. g. to the proxy or server. Integrated The integrated method is a challenge/response technique that does not allow to recover a password from a sniffed connection. The password hash will be hashed with two random values, one chosen by the client and one by the server. This means that three steps are required to complete the authentication procedure. Login Page Under this method, the proxy/server sends an HMTL page to let the user submit a user name and password. This will then be treated as a regular request. 2 1

8 On Authentication Credential Verification Methods After a proxy or a server has retrieved the credentials of a user, there are several methods for verifying them and retrieving the additional user information (group membership) that is needed in order to do policy mapping: NTLM Submitting a query to a Windows domain controller This requires that Webwasher is running on a Windows server, or the use of the NTLM Agent running on a separate server. LDAP Submitting a query to an LDAP server Webwasher User Database Looking up user data in the Webwasher User Database This database runs on every supported platform and does not require the use of additional servers. Authentication Authentication is credential retrieval plus credential verification. A graphical representation of the authentication procedure including both these parts is provided by the diagrams shown below. The procedure starts after the proxy/server has indicated that authentication is required. The bold arrows inside the credential retrieval diagram show how many steps are required between the client and proxy/server in order to transmit the credentials: 2 2

9 On Authentication Proxy Authentication vs. Transparent Authentication Authentication procedures may also differ with regard to whether they are done as Proxy Authentication or Transparent Authentication. There are two main features that distinguish these authentication methods: 1. With proxy authentication, you need to configure the browser on the client to use the proxy server. 2. With proxy authentication each request or connection (when the integrated method of retrieving credentials is applied) is authenticated. This means that a request or connection is mapped to a user. With transparent authentication under Webwasher, the mapping is done between an IP address and a user. Note that it is not possible with this authentication method to distinguish between multiple users on a single system. The following diagram shows the various steps that are completed when transparent authentication is used: A user requests a URL (1) and the ICAP client forwards this request to the ICAP server (2). If the ICAP server is unable to map the IP address of the client to a user name (3, 4), it starts the authentication process. 2 3

10 On Authentication Instead of filtering the request (in REQMOD or RESPMOD communication mode), it sends a redirect that points to the authentication server (5, 6). This server, which is identical with the ICAP server under Webwasher, uses the configured credential retrieval and verification methods to obtain a user name and group membership (7). This information is assigned to an IP address and distributed in the Webwasher cluster as required. Depending on the chosen methods, this procedure will not be visible to the user and does not require any user interaction. After authentication has been successfully achieved, the authentication server sends another redirect to the original URL (8). By following this redirect, the client requests the URL once again (9), and the usual data flow (10-14) will go on now because the user has been authenticated. 2 4

11 Chapter 3 Deployment Planning and Configuration This chapter introduces two scenarios for using transparent authentication, see 3.1. Furthermore, it describes in detail the steps required under Webwasher to configure this authentication method, see Deployment Scenarios There are at least two scenarios where it would make sense to use transparent authentication in a Webwasher configuration: 1. Clients use Webwasher as proxy and authentication is done using LDAP, or NTLM with the basic method of credential retrieval. The disadvantage with this scenario is that the LDAP user name and password will be sent unprotected and can be sniffed at any point in the network. The security hole can be overcome by using transparent authentication, with credential retrieval performed in basic mode over an SSL-secured connection and credential verification done using an LDAP server. However, a better solution can be found here: If the user credentials are verified on an active directory, you can use the NTLM Agent, or instead of an LDAP server, you can use the integrated method of credential retrieval together with the Webwasher User Database. In the latter case, you may also use the LDAP synchronization feature to enable a smooth transition. 2. There is no proxy in your configuration, such as the Webwasher Pass-By ICAP Client, but authentication or policy mapping is required, or the proxy server (ICAP client) installed in the configuration is not capable of performing the desired authentication method. 3 1

12 Deployment Planning and Configuration 3.2 Configuration Steps This section describes the configuration steps that are required to configure transparent authentication under Webwasher. Proceed as follows: 1. Log in to the Webwasher Web interface and go to the Web Mapping tab under User Management > Policy Mapping. Note that this step is required even if you only want to configure authentication without policy mapping. 2. Set up a mapping like the one shown under 1. in the upper list if you want to do only authentication or to assign a policy that is based on the user name. A mapping like 2. should be chosen to assign a policy based on the group membership of the client. After setting up a mapping, click on the Edit rules and options button in the same line. 3 2

13 Deployment Planning and Configuration The User based Mapping (or Group based Mapping) tab appears: 3. In the User Name Location section, select Transparent Authentication from the first drop-down list to let Webwasher search for the user name in the (transparent) authenticated user database. 4. If the Input value must exist checkbox is marked in the Mapping Options section, the ICAP server will send a redirect if it does not find a user name corresponding to an IP address. 5. In the Add Rule section, add a user mapping rule, e. g. default = *, which means that only authenticated users are allowed access. 3 3

14 Deployment Planning and Configuration The next steps are required to configure the authentication server: 1. Go to the Authentication Server tab under User Management > Authentication Server. 2. In the Authentication Server Settings section, enable use of the server by marking the checkbox next to the section heading. 3. Depending on the authentication method selected in step 6, make sure the Use SSL checkbox is marked, see the description given for that step. 4. Accept the default port, which is 9094, or enter another port. 5. Accept the standard value of 120 seconds to configure how long the mapping from an IP address to a user should be valid. After this interval has expired, the ICAP server will again send a redirect for the next request and the mapping (and authentication) must be renewed. The danger in configuring a long interval here is that a user switch on one computer or a new assignment of the IP address by DHCP to another computer will not be recognized, which will lead to an inaccurate mapping. On the other hand, a short interval may increase the number of redirects that are required in the authentication process. 3 4

15 Deployment Planning and Configuration 6. In the Authentication Process section, select an authentication method. If you select more than one method, authentication is achieved if at least one of them was applied successfully. Depending on the chosen method, SSL encryption should be used for the connection between client and authentication server. To enable this, use the corresponding checkbox in the Authentication Server Settings section, see step 3. SSL encryption can be omitted if the method selected is User Database, NTLM, or NTLM Agent and if the integrated method is used to retrieve the user credentials. The method is enabled by marking the corresponding checkbox in the NTLM and NTLM-Agent Authentication Options or User Database Authentication Options section. Note that today all widely distributed browsers support this integrated method. If you want the user to submit the credentials through the login page, mar the corresponding checkbox above the methods list. The only benefit of the login page is that the user sees what happens. Credentials are entered manually, and this must be repeated every time the authentication has expired. Technically speaking, it does not make sense to use the login page since the other options are not less secure, but more comfortable. The following table provides an overview of how often the user must enter the credentials (assuming the browser process does not terminate): Basic Integrated Login Page Windows First time Never First Time + each renewal Other First Time First Time First Time + each renewal 7. The other sections on the tab are used to configure further authentication parameters. After specifying the appropriate values in all sections, click on the Apply Changes button to make your settings effective. 3 5

16 Deployment Planning and Configuration Notes on Some Pitfalls Note that there are some pitfalls that must be taken into account when setting up transparent authentication: POST requests will fail if the ICAP server sends an redirect to the authentication server. This affects, however, only the renewal of the mapping since for the browser the request was successful, and the POST body will not be sent again after the final redirect. Authentication at a server (here the authentication server) over a proxy connection. In this configuration, the Microsoft Internet Explorer will not send the credentials. Possible work-arounds: use login page configure the Internet Explorer not to use a proxy for the authentication server. Note that if Webwasher has been configured to run in a cluster, all IP addresses must be excluded. Redirection loops. A browser requests URL A. The ICAP server sends a redirect to B and the authentication server sends an redirect to A again. Firefox treats this as an endless loop and stops the request. (the Internet Explorer will not recognize the problem). To solve the problem, Webwasher appends a dummy parameter to A in the default configuration, so it is not a loop any longer (A -> B -> A2). The additional parameter will be removed in the REQMOD call. Further problems may occur when using the Pass-By ICAP Client because this client searches only for blocked requests and not for modified requests. There are many Web servers that have no problem with the additional parameter, but some will respond with a File not found error message. 3 6