Reverse Proxy How To. Version 8.0.0

Transcription

1 Reverse Proxy How To Version 8.0.0

2 Table of Contents 1. Introduction About this Document... Examples used in this Guide... Documentation Sources... About the AXS GUARD What is it? Spare Units Licensed Units Configuration Wizards About VASCO Reverse Proxy Concept Overview... What is the Reverse Proxy?... Reverse Proxy versus Port Fowarding... Reverse Proxy versus DMZ... Using Separate Connections... Supported Protocols Main Features of the Reverse Proxy Overview... 7 RFC Compliance... 7 URL Sanitizing... 7 Request Filtering Overview Denied Requests Allowed Requests Base URL Protection Single Point of Access Concepts Non Listening Domain Catch All Entry Examples Self-Signed and Trusted Certificates Overview Self-Signed Certificates Certificates Signed by a Trusted CA Domain Name Mismatch HTTP and SSL Encryption Overview HTTPS Gateway for External Connections HTTPS for Internal Connections Supported Authentication Methods Overview AXS GUARD Authentication Single Sign-On (SSO) and Password Auto-Learning Predefined Back-End Servers Advanced Settings ii

3 4. Using the Reverse Proxy with FTP Overview... Supported Authentication Methods... Source Host List... FTP and Connection Tracking (SPICT) HTTP(S) Configuration Examples Overview Non Listening Domain Catch All Entry Microsoft OWA 2003 with Basic Authentication Overview Configuration Microsoft OWA 2003 with Basic Authentication and SSL Certificate Overview Using a Self-Signed Certificate Trusted CA Certificates Microsoft OWA 2003 with Form-Based Authentication and SSO Overview Configuration Microsoft Exchange RPC over HTTPS About Configuration Citrix Server with Single Sign-On Overview Configuration Running a Classic Website Overview Configuration Intranet Web Server with Authentication FTP Reverse Proxy Configuration Example Overview Configuration Logging Overview Accessing the HTTPS Logs Accessing the FTP Logs Troubleshooting Support Overview If you encounter a problem Return procedure if you have a hardware failure... Alphabetical Index iii

4 VASCO Products VASCO Data Security, Inc. and/or VASCO Data Security International GmbH are referred to in this document as VASCO. VASCO Products comprise Hardware, Software, Services and Documentation. This document addresses potential and existing VASCO customers and has been provided to you and your organization for the sole purpose of helping you to use and evaluate VASCO Products. As such, it does not constitute a license to use VASCO Software or a contractual agreement to use VASCO Products. Disclaimer of Warranties and Limitations of Liabilities VASCO Products are provided as is without warranty or conditions of any kind, whether implied, statutory, or related to trade use or dealership, including but not limited to implied warranties of satisfactory quality, merchantability, title, non-infringement or fitness for a particular purpose. VASCO, VASCO DISTRIBUTORS, RESELLERS AND SUPPLIERS HAVE NO LIABILITY UNDER ANY CIRCUMSTANCES FOR ANY LOSS, DAMAGE OR EXPENSE INCURRED BY YOU, YOUR ORGANIZATION OR ANY THIRD PARTY (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF PROFITS, BUSINESS INTERRUPTION OR LOSS OF DATA) ARISING DIRECTLY OR INDIRECTLY FROM THE USE, OR INABILITY TO USE VASCO SOFTWARE, HARDWARE, SERVICES OR DOCUMENTATION, REGARDLESS OF THE CAUSE OF THE LOSS, INCLUDING NEGLIGENCE, EVEN IF VASCO HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES, OR IF THEY WERE FORESEEABLE. OUR MAXIMUM AGGREGATE LIABILITY TO YOU, AND THAT OF OUR DISTRIBUTORS, RESELLERS AND SUPPLIERS SHALL NOT EXCEED THE AMOUNT PAID BY YOU FOR THE PRODUCT. THE LIMITATIONS IN THIS SECTION SHALL APPLY WHETHER OR NOT THE ALLEGED BREACH OR DEFAULT IS A BREACH OF A FUNDAMENTAL CONDITION OR TERM, OR A FUNDAMENTAL BREACH. THIS SECTION WILL NOT APPLY ONLY WHEN AND TO THE EXTENT THAT APPLICABLE LAW SPECIFICALLY REQUIRES LIABILITY DESPITE THE FOREGOING EXCLUSIONS AND LIMITATIONS. Intellectual Property and Copyright VASCO Products contain proprietary and confidential information. VASCO Data Security, Inc. and/or VASCO Data Security International GmbH own or are licensed under all title, rights and interest in VASCO Products, updates and upgrades thereof, including copyrights, patent rights, trade secret rights, mask work rights, database rights and all other intellectual and industrial property rights. No part of these Products may be transferred, disclosed, reproduced or transmitted in any form or by any means, electronic, mechanical or otherwise, for any purpose, except as expressly permitted by VASCO or its authorized licensee in writing. This document is protected under US and international copyright law as an unpublished work of authorship. No part of it may be transferred, disclosed, reproduced or transmitted in any form or by any means, electronic, mechanical or otherwise, for any purpose, except as expressly permitted in writing by VASCO or its authorized licensee. VASCO Trademarks VASCO, VACMAN, IDENTIKEY, axsguard, AXS GUARD, DIGIPASS, DIGIPASS as a Service, MYDIGIPASS.COM and the logo are registered or unregistered trademarks of VASCO Data Security, Inc. and/or VASCO Data Security International GmbH in the U.S. and other countries. Other company brand or product names or other designations, denominations, labels and/or other tags, titles, as well as all URLs (Internet addresses) linked to such designations or communications (irrespective of whether protected by intellectual property law or not), mentioned in VASCO Products may be the trademarks or registered trademarks or be part of any other entitlement of their respective owners. Other Trademarks Citrix and XenServer are trademarks or registered trademarks of Citrix Systems, Inc. VMware and vsphere are registered trademarks or trademarks of VMware, Inc. Hyper-V is a registered trademark of Microsoft Corporation. Copyright 2014 VASCO Data Security, VASCO Data Security International GmbH. All rights reserved. iv

5 Chapter 1. Introduction 1.1. About this Document This document has been written for AXS GUARD version and is based on changes and features that have been implemented since version This document was last updated on 22 Sep This document is intended for technical experts and system administrators. It describes the concept and configuration of the AXS GUARD Reverse Proxy with HTTP(S) and FTP back-end servers. We also explain the different security features of the AXS GUARD Reverse Proxy module and provide several configuration examples. In Chapter 1, Introduction, we introduce the AXS GUARD and explain the difference between licensed and spare units. In Chapter 2, Reverse Proxy Concept, we explain the AXS GUARD Reverse Proxy concept and its advantages. In Chapter 3, Main Features of the Reverse Proxy, we explain the features of the AXS GUARD HTTP and HTTPS Reverse Proxy, such as URL sanitizing, SSL encryption and DIGIPASS Authentication. In Chapter 4, Using the Reverse Proxy with FTP we explain the AXS GUARD FTP Reverse Proxy features. In Chapter 5, HTTP(S) Configuration Examples, we provide some pratical configuration examples of Reverse Proxy entries. In Chapter 6, FTP Reverse Proxy Configuration Example, we provide a configuration example of an FTP reverse proxy entry. In Chapter 7, Logging, we explain the AXS GUARD Reverse Proxy Logging system. In Chapter 8, Troubleshooting, we provide some solutions to solve difficulties. In Chapter 9, Support, we explain how to request support, and return hardware for replacement Examples used in this Guide All setups and configuration examples in this guide are executed as an advanced administrator. Some options are not available if you log on as a full administrator or a user with lower privileges. The administrator levels are explained in the system administration guide. As software development and documentation are ongoing processes, screenshots shown in this guide may slightly vary from the screens of the software version installed on your appliance Documentation Sources Other documents in the set of AXS GUARD documentation include: AXS GUARD Installation Guide, which explains how to set up the AXS GUARD, and is intended for technical personnel or system administrators. How to guides, which provide detailed information on the configuration of each of the features available as add-on modules (explained in Section 1.4.1, What is it? ). These guides cover specific features such as: AXS GUARD Authentication 1

6 Chapter 1. Introduction AXS GUARD Firewall AXS GUARD Single Sign-On AXS GUARD VPN AXS GUARD Reverse Proxy AXS GUARD Directory Services Access to AXS GUARD guides is provided through the permanently on-screen Documentation button in the AXS GUARD Administrator Tool. Further resources available include: Context-sensitive help, which is accessible in the AXS GUARD Administrator Tool through the Help button. This button is permanently available and displays information related to the current screen. Training courses covering features in detail can be organized on demand. These courses address all levels of expertise. Please see for further information About the AXS GUARD What is it? The AXS GUARD is an authentication appliance, intended for small and medium sized enterprises. In addition to strong authentication, the AXS GUARD has the potential to manage all of your Internet security needs. Its modular design means that optional features can be purchased at any time to support, for example, and Web access control. The AXS GUARD can easily be integrated into existing IT infrastructures as a standalone authentication appliance or as a gateway providing both authentication services and Internet Security. Authentication and other features such as firewall, and Web access, are managed by security policies, which implement a combination of rules, for example, whether a user must use a DIGIPASS One-Time Password in combination with a static password for authentication. Security Policies are applied to specific users or groups of users and can also be applied to specific computers and the entire system Spare Units A Spare Unit is an unlicensed appliance, with limited configuration possibilities and allows you to swiftly replace a defective appliance. It can also be licensed as a new appliance. In fact, all appliances can be considered spare units until they are licensed. Restoring to a Spare Unit is restricted to: the same hardware version (e.g. AG-3XXX, AG-5XXX or AG7XXX) as the unit being replaced. the same software version as the appliance being replaced (or a higher version on which data migration is supported; please contact VASCO support (support@vasco.com) for guidance. Once a backup is restored on a Spare Unit, full functionality is available. The configuration tool of the appliance can then be accessed by any user with administrative privileges (see the AXS GUARD System Administration How To.) The license from the backup is also restored on the Spare Unit. However, an appliance with a restored license only remains operational for a grace period of 30 days, during which the System Administrator needs to acquire a new license. If a new license has not been issued after this grace period, all services on the appliance will be stopped. Only the Administrator Tool will remain accessible. Contact VASCO support (support@vasco.com) to release the restored license of the original appliance. To relicense the appliance, follow the same procedure as used during first-time licensing Licensed Units With a licensed appliance, a user with full administrative privileges has access to all the configuration options on the AXS GUARD. Use the sysadmin account to create a user with administrative privileges. Since the 2

7 Chapter 1. Introduction sysadmin user can create new administrators, you should change the default password of this account when you log in to the appliance for the first time. Licensing and accessing a fully operational in-service appliance requires the following steps: 1. Logging on to the AXS GUARD as the default sysadmin user and changing the sysadmin password 2. Creating a new user with full administration rights, which is required to configure the AXS GUARD 3. Licensing the appliance Configuration Wizards Use the configuration wizards to configure your system essentials more easily About VASCO VASCO is a world leader in strong authentication and e-signature solutions, specializing in online accounts, identities and transactions. As a global software company, VASCO serves a customer base of approximately 10,000 companies in over 100 countries, including approximately 1,500 international financial institutions. In addition to the financial sector, VASCO s technologies secure sensitive information and transactions for the enterprise security, e-commerce and e-government industries. For further information, please visit 3

8 Chapter 2. Reverse Proxy Concept 2.1. Overview In this section, we introduce the AXS GUARD Reverse Proxy. Topics covered in this section include: A definition of the Reverse Proxy concept The advantages of using a Reverse Proxy Supported back-end protocols 2.2. What is the Reverse Proxy? The AXS GUARD Reverse Proxy services Internet client requests by forwarding these requests to the correct server in the LAN, while providing access control, auditing and content monitoring (illustrated image below). Figure 2.1. Reverse Proxy Concept An Internet client connects to the AXS GUARD Reverse Proxy Server requesting some service, such as a file or a web page, available on a server in the LAN. If authorized, the resource is provided by the AXS GUARD Reverse Proxy server, which connects and requests the service on behalf of the Internet client. This means that a direct connection from the Internet to the LAN server is prevented and the server is shielded from possible attacks and exploits. From now on, we will use the term back-end server when referring to a server in the secure LAN or DMZ Reverse Proxy versus Port Fowarding With port forwarding, the back-end server is directly accessible from the Internet and therefore its potential vulnerabilites can be more easily exploited. If a back-end server is compromized, your private data in the secure LAN is fully exposed. 4

9 Chapter 2. Reverse Proxy Concept VASCO strongly advises against the use of port forwarding, due to its inherent security risks. For more information about port forwarding, see the AXS GUARD System Administration How To, which can be accessed via the Documentation button in the Administrator Tool Reverse Proxy versus DMZ Another method to allow access to a web server is the use of a DMZ (illustrated below). The DMZ concept is explained in the AXS GUARD Firewall How To, which can be accessed via the Documentation button in the Administrator Tool. The DMZ solves the problem of possible access to private data in the secure LAN. However, the DMZ server itself can still be compromized, as it is directly accessible from the Internet. Furthermore, a connection from your DMZ web server to a database server in the secure LAN is not allowed by the AXS GUARD Firewall. Traffic from the DMZ to the secure LAN can be allowed with advanced Firewall Rules. However, VASCO does not recommended their use. The slightest misconfiguration may have a serious impact on your network security. Figure 2.2. DMZ Concept 2.5. Using Separate Connections The AXS GUARD Reverse Proxy server offers an alternative solution to port forwarding and the DMZ explained in Section 2.3, Reverse Proxy versus Port Fowarding and Section 2.4, Reverse Proxy versus DMZ. The AXS GUARD Reverse Proxy prevents direct access to a server(s) in the secure LAN, hereby protecting it from hacking attempts and OS vulnerability exploits. Instead, the AXS GUARD Reverse Proxy uses two separate connections: one to accept the request from the Internet client 5

10 Chapter 2. Reverse Proxy Concept another to forward the connection to the server in the secure LAN (from which data is retrieved). Hence, your private data in the secure LAN remains private and is shielded from potential intruders. The AXS GUARD Reverse Proxy server also allows you to securely connect a Web server with a database server in the LAN (illustrated below). This is not the case with a DMZ. Figure 2.3. Using Separate Connections for Security 2.6. Supported Protocols The AXS GUARD Reverse Proxy works at the URL level and inspects HTTP traffic. It also allows you to modify the contents of a URL (a.k.a. URL Replacement). The following TCP/IP protocols are supported: HTTP HTTPS FTP VASCO strongly recommends the use of the AXS GUARD Reverse Proxy for all back-end servers which are using these protocols. For back-end servers using other protocols, you are advised to use a DMZ or a VPN. RPC is a protocol directly above TCP/IP and is not supported, except if the implementation on the backend server is fully RFC compliant. 6

11 Chapter 3. Main Features of the Reverse Proxy 3.1. Overview In this chapter, we explain the main features of the AXS GUARD Reverse Proxy server used with HTTP and HTTPS back-end servers. Topics covered in this section include: RFC compliance URL sanitizing HTTP encryption User authentication 3.2. RFC Compliance By international agreements, referred to as RFC (Requests For Comments), a URL needs to comply with certain standards. These standards are used by the AXS GUARD Reverse Proxy server, providing a secure environment for back-end servers. For detailed information about URL standards, see RFC 2396: Example 3.1. Length of a URL An example of an RFC standard is the length of a URL. Not all web applications can handle extensively long URLs. Such URLs may cause buffer overflows, resulting in unwanted program behavior (hacking attempt) or a crash. The AXS GUARD Reverse Proxy server automatically rejects requests that contain oversized URLs URL Sanitizing Per RFC, only certain ASCII characters are allowed in a URL. Characters which deviate from RFC standards are converted. The conversion of URL characters is referred to as escaping. Not all back-end servers comply with the international standards (RFCs); they are vulnerable to attacks. To protect these servers, the AXS GUARD Reverse Proxy is equipped with a URL sanitizer. The URL sanitizer filters out all non RFC compliant URL characters before a query string. Example 3.2. How spaces are converted A space in a URL is converted to %20. The characters after? in the following URL constitute a query string and are not escaped by the URL sanitizer: Request Filtering Overview The AXS GUARD Reverse Proxy server allows you to add URL restrictions on top of the enforced RFC standards. The Reverse Proxy can be configured to reject URLs or parts thereof. The URLs have to be 7

12 Chapter 3. Main Features of the Reverse Proxy manually entered in the Reverse Proxy configuration screen. Via the Reverse Proxy, administrators can block URLs with specific content and allow exceptions. The default configuration of the AXS GUARD Reverse Proxy server is optimised for a Microsoft IIS back-end server. Filters either: Deny requests Allow requests (exceptions) Example 3.3. Blocked URLs and Exceptions All URLs containing the word scripts, such as are blocked, while the URL is defined as an exception. The AXS GUARD Reverse Proxy server accepts requests for (a) URL(s) which is / are defined as an exception Denied Requests URLs matching the configured patterns, or parts thereof, are denied. You can use wildcards to define patterns: An asterisk or star wildcard * has the broadest meaning of all wildcards, as it either represents zero characters, all characters or any string e.g., matches etc., but also A question mark? is used to designate any character, e.g. the string matches etc. A caret ^ designates the beginning of the server portion in a URL, e.g. ^slashdot.org matches but not mail.slashdot.org/. $ designates the end of a website, e.g. vrt.be/teletekst$ matches teletekst, but not Figure 3.1. Example of Denied Requests Allowed Requests URL restrictions can be overruled by adding a full URL entry or a part thereof, using the same syntax as explained in Section 3.4.2, Denied Requests Base URL Protection Base URL protection is a method to protect your web server against unauthorized access. This is achieved by restricting access to a defined set of URLs. Check the documentation of your back-end server to verify which URLs it publishes by default and which are the ones that need special protection. Example 3.4. Web Server Base URL Protection A web server such as has several URLs: 8

13 Chapter 3. Main Features of the Reverse Proxy By adding /public/ as a base URL, only is accessible to the public. Other requests are redirected to the allowed URL, e.g. an incoming request for would be redirected to Example 3.5. Microsoft OWA 2003 When running a Microsoft OWA 2003 server, only the following URLs should be accessible: /exchange/ /exchweb/ /public/ Include a forward slash / before and after each entry. If multiple base URLs are defined, any unauthorized request is automatically redirected to the base URL on top of the list. In the example below, that would be /exchange/ Figure 3.2. Base URL Protection 3.6. Single Point of Access Concepts The AXS GUARD Reverse Proxy server is the single point of Internet access towards your back-end server(s) in the Secure LAN. The Reverse Proxy will select one of the configured back-end servers based on the URL which is entered by users on the Internet (illustrated below). Hence, multiple back-end servers with different hostnames can be made available to Internet users, while only a single public IP address is needed on port 443 or 80. It is advised to use multiple hostnames rather than multiple ports, as ports which deviate from the RFC standards (80 and 443) may not be allowed by intermediate Internet firewalls or routers. Hostnames are also easier to remember than port numbers. The use of non-standard ports requires users to specify a port number after the URL, e.g. Each reverse proxy entry must have a unique IP address, port and hostname. Multiple hostnames (FQDNs) can be specified for a single back-end. If a site is pointed at the server but does not actually exist, users will get served with an existing site on the server rather than a "domain cannot be found" message or similar. It is therefore recommended to create a "catch all" reverse proxy entry for non listening domains. 9

14 Chapter 3. Main Features of the Reverse Proxy Figure 3.3. Reverse Proxy as a Single Point of Access You must add a period to the Certificate Connection Name in the Reverse Proxy entry to prevent the AXS GUARD from automatically appending its system domain to the common name of the certificate. In case you enter an FQDN, make sure to end it with a period, e.g. owa.domain.com.. See the examples in Chapter 5, HTTP(S) Configuration Examples for practical guidance Non Listening Domain Catch All Entry Assume you have 3 active reverse proxy entries pointing to the public IP External hostname: a.yourdomain.com Internal IP: External hostname: b.yourdomain.com Internal IP: External hostname: c.yourdomain.com Internal IP: Assume there is also a DNS record dns.random.net somewhere on the Internet which is pointing to This record is out of your control, i.e. created by mistake or even intentionally. If a user on the Internet goes to dns.random.net or , (s)he will end up at a.yourdomain.com, i.e. the first active entry in your reverse proxy list. To prevent this this behavior, we recommend to create a "catch all" reverse proxy entry, where you don t specify an external hostname and point to an internal server with an "Unauthorized" or "Domain not found" page. Figure 3.4. Catch All Entry 10

15 Chapter 3. Main Features of the Reverse Proxy Examples Example 3.6. One reverse proxy entry using port 443 In this scenario, it is recommended to leave the hostname field empty. This way, all names resolving to the specified IP address will be allowed by the Reverse Proxy. If a hostname is entered, only requests matching the entered FQDN will be allowed by the AXS GUARD Reverse Proxy Server. If a hostname is specified, you cannot use the public IP address in the browser s URL field. Both the hostname and IP address must be added if needed. Example 3.7. One public IP address with multiple reverse proxy entries using port 443 The IP address and port number are predefined. This means only the hostname can be used to point to the correct server in the secure LAN. A server with the following hostname intranet.yourdomain.com and AXS GUARD authentication can be used to connect to the intranet webserver. Another host, e.g. owa.yourdomain.com, can be added to connect to your corporate MS Outlook Web Access server. A third Reverse Proxy entry can be added for your company website. In this case you could add as a hostname or you can choose not to specify a hostname at all. In the first case, all non-matching FQDNs resolving to the Reverse Proxy s IP are blocked as a security precaution. In the second case, any FQDN which resolves to this IP address provides a connection to the company website Self-Signed and Trusted Certificates Overview A digital certificate is a computer file containing information which uniquely identifies its owner. The information consists of the owner s public key, the expiration date of the certificate, the name of the Certificate Authority (CA), a unique name (host name), the signature of the CA (signed with the CA s private key), and other descriptive data. Certificates are encoded by the CA s private key and can be verified with the CA s public key. Any unauthorised changes to the certificate file generate a warning message in the client s browser. 11

16 Chapter 3. Main Features of the Reverse Proxy Figure 3.5. Digital Certificate Chain Self-Signed Certificates A company may choose to create and sign its own certificate. This means the company acts as a CA and signs its own certificate. When you connect to a website with a self-signed certificate, a warning message similar to the image below appears. Figure 3.6. Self Signed Certificate Warning Certificates Signed by a Trusted CA Rather than signing their own certificate, companies may choose to purchase a certificate from a trusted known CA. A trusted CA is an independent network entity, responsible for the issuance and management of digital 12

17 Chapter 3. Main Features of the Reverse Proxy certificates. When you connect to a website that has a certificate signed by a trusted CA, your browser will not generate a warning message Domain Name Mismatch The warning message Domain Name Mismatch occurs when the FQDN entered in the browser s URL field does not match the host name used in the server certificate. This is to inform users that the contacted site may not be the actual intended site (man-in-the-middle attack). The same message appears when a site changes its name (FQDN) without purchasing a new certificate that includes the changed name or when entering the server s public IP address in the browser s URL field, e.g. rather than the FQDN. Figure 3.7. Example of a Domain Name Mismatch Warning If you change the name of your Certificate Connection Name in an existing Reverse Proxy entry, you must use a new certificate with the correct host name. See Chapter 5, HTTP(S) Configuration Examples for practical guidance and configuration examples HTTP and SSL Encryption Overview An HTTPS connection is a secured HTTP connection. All data in the connection is encrypted using the Secure Sockets Layer (SSL) protocol (illustrated below). SSL is based on the public/private key (PKI) encryption model. The public key is published via a certificate stored on the secure webserver. 13

18 Chapter 3. Main Features of the Reverse Proxy Figure 3.8. SSL Connection Negotiation HTTPS Gateway for External Connections Enabling HTTPS for external connections is strongly encouraged, as all data is sent towards the user(s) on the insecure Internet (illustrated below). The HTTPS protocol can be activated separately for each reverse proxy entry. The AXS GUARD SSL Gateway keeps the maintenance and monitoring of your SSL infrastructure centralized, eliminating the need for SSL maintenance on the back-end server(s). Besides self-signing, the AXS GUARD supports the integration of trusted party (CA) SSL certificates. These certificates can be imported via the AXS GUARD Administrator tool. Currently, only PKCS#12 and PEM certificates are supported. You can either import a single PEM certificate file or a PEM certificate with a separate key file, which in turn can be encrypted and password protected. 14

19 Chapter 3. Main Features of the Reverse Proxy Figure 3.9. HTTPS for External Connections HTTPS for Internal Connections Using HTTPS for communications between the AXS GUARD Reverse Proxy and the back-end server(s) in the secure LAN is not recommended, as this produces encryption overhead. However, some back-end servers only support HTTPS. For these servers it is more convenient to allow HTTPS, rather than modifying the backend server configuration. You can only use HTTPS for internal connections if it is also used for the external connection Supported Authentication Methods Overview The AXS GUARD protects access to your back-end server with authentication. Before access is granted to the back-end server, authentication on the AXS GUARD needs to be successful. Three types of authentication are available for the AXS GUARD Reverse Proxy server: Back-end server authentication: The back-end server handles the entire authentication process; the AXS GUARD only conveys authentication requests and replies between the client and the back-end server. 15

20 Chapter 3. Main Features of the Reverse Proxy Figure Back-end Authentication AXS GUARD authentication: The AXS GUARD requests and verifies the user credentials before contacting the back-end server; the authentication process in handled entirely by the AXS GUARD. This method allows you to enforce DIGIPASS Autentication. More information about Autentication is available in the AXS GUARD Authentication How To, which can be accessed via the Documentation button in the Admininistrator Tool. Single Sign-On (SSO) authentication: SSO requires the back-end server to use form-based authentication; the AXS GUARD forwards the back-end server s authentication request, e.g. the Outlook Web Access logon page, to the client on the Internet. The client s credentials are intercepted and examined by the AXS GUARD. After successful authentication with the AXS GUARD, the AXS GUARD credentials are replaced by the preconfigured back-end credentials to authenticate with the back-end server. In the following sections, we explain AXS GUARD authentication and SSO authentication in more detail AXS GUARD Authentication The AXS GUARD prompts for user credentials when a webpage is requested. No requests are forwarded to the back-end server as long as the requesting user is not succesfully authenticated with the AXS GUARD (illustrated below). 16

21 Chapter 3. Main Features of the Reverse Proxy Figure AXS GUARD Authentication The AXS GUARD uses basic authentication. Basic authentication is a method which enables users to provide their credentials through a pop-up window (illustrated below). Figure Basic Authentication It is recommended to use SSL (HTTPS) with basic authentication. Not using SSL causes all passwords to be transmitted in clear text. Because of its concept and design, basic authentication cannot be implemented simultaneously on the backend server and on the AXS GUARD. For example, enabling basic authentication on a Microsoft Outlook Web 17

22 Chapter 3. Main Features of the Reverse Proxy Access 2003 server and the AXS GUARD is technically impossible. VASCO advises the use of Single SignOn (SSO) if authentication is required on the AXS GUARD and the back-end server. Authentication Methods The AXS GUARD offers a variety of authentication methods. Once a method has been selected, it applies to all reverse proxy entries. Detailed information about AXS GUARD authentication methods is available in the AXS GUARD Autentication How To, which is accessible via the Documentation button. The following autentication methods are available for the AXS GUARD Reverse Proxy: Deny Always: e.g. when you are maintaining your back-end server VASCO DIGIPASS DIGIPASS and Directory Service: Directory Service password followed by DIGIPASS OTP. DIGIPASS and Static Password: AXS GUARD password, followed by VASCO DIGIPASS OTP. DIGIPASS or Directory Service: Directory Service password or DIGIPASS OTP. DIGIPASS or Static Password: VASCO DIGIPASS OTP or AXS GUARD password. Directory Service password, e.g. your Active Directory password. Static Password: AXS GUARD local password. To select the authentication method for the AXS GUARD Reverse Proxy: 1. Log on to the AXS GUARD as explained in the AXS GUARD System Admininistration How To, which is accessible via the Documentation button in the Admininistrator Tool. 2. Navigate to Authentication Services. 3. Select Reverse Proxy from the list of services. 4. Select the desired authentication method (as shown in the image below). 5. Click on Update. Figure Selecting the Authentication Method Single Sign-On (SSO) and Password Auto-Learning Requirements SSO can only be used if the back-end server uses form-based authentication, i.e. the user credentials are entered in a form which is incorporated in the webpage, rather than a separate pop-up window (see Section 3.9.2, AXS GUARD Authentication ). 18

23 Chapter 3. Main Features of the Reverse Proxy Figure Example of Form-Based Authentication on OWA Form-based authentication. The user enters his AXS GUARD credentials which are verified by the Reverse Proxy, as illustrated below. Users only see the back-end authentication form (e.g. the Outlook Web Access authentication screen), not the authentication page of the AXS GUARD. 19

24 Chapter 3. Main Features of the Reverse Proxy Figure SSO Request If the user successfully autenticates with the AXS GUARD, a set of predefined user credentials is forwarded to the back-end server; the user is automatically and transparently authenticated with the back-end server. Hence, the name Single Sign-On. The authentication page of the back-end server is resent to the user if he or she fails to authenticate with the AXS GUARD (illustrated below). Figure SSO Authentication Flow Predefined user credentials Single Sign-On only works if the back-end credentials for each user are entered on the AXS GUARD. The credentials must be entered/updated using the AXS GUARD Administrator Tool when they are added/modified on the back-end server. The back-end server credentials can only be entered or modified by an Administrator. 20

25 Chapter 3. Main Features of the Reverse Proxy To enter / modify the back-end server credentials: 1. Log on to the AXS GUARD as explained in the AXS GUARD System Admininistration How To, which is accessible via the Documentation button in the Admininistrator Tool. 2. Navigate to Users & Groups Users. 3. Click on the user name of which the back-end server credentials must be entered or modified. 4. Click on the Reverse Proxy tab. 5. Enter the back-end server credentials. 6. Click on Update. Figure Back-end credentials If no password is entered, the user s AXS GUARD password is used to authenticate with the backend server. Password Auto-Learning The AXS GUARD Reverse Proxy offers a back-end password auto-learning feature, so that users only have to provide the back-end server s password during the first authentication (until it expires, according to the set password policy on the back-end server). If used, the AXS GUARD safely stores the provided back-end server password for future use (illustrated below), so that users only have to provide one set of credentials and don t have to remember two sets. The password auto-learning feature allows you to implement DIGIPASS authentication; the user authenticates with the AXS GUARD using his / her back-end password in combination with a One-Time Password (DIGIPASS OTP). The back-end password and OTP are entered as a single string. After successful authentication, the DIGIPASS OTP password is truncated; the remaining part of the entered authentication string (the back-end password) is saved by the AXS GUARD and forwarded to the back end server. 21

26 Chapter 3. Main Features of the Reverse Proxy Always enter the AXS GUARD password or OTP first, followed by the configured password separator and end with the back-end password. Although you can also use other AXS GUARD password types (static password) in combination with the back-end server password, it is strongly advised to use DIGIPASS Authentication, which is the most secure option. Possible authentication scenarios are explained further in this manual. A Reverse Proxy entry must be created by a full admininstrator. Only advanced administrators can configure the Password Auto-Learn feature and the password separator string. Figure Password Auto-Learning 1. A user on the Internet provides his back-end password and DIGIPASS OTP. 2. The AXS GUARD verifies the DIGIPASS OTP. 3. If the DIGIPASS OTP is valid, the back-end password is saved on the AXS GUARD for future use. 4. The saved back-end password is forwarded to the back-end server to authenticate the user. Authentication Scenarios 1. Users authenticate using only their AXS GUARD password while their back-end server password is stored on the AXS GUARD (Single Sign-On). 2. Users authenticate using only their AXS GUARD password while their back-end server password is not stored on the AXS GUARD. Authentication fails and the back-end server authentication form is presented to the user. As authentication is seamless, the administrator must verify whether the authentication problem is related to the back-end server or the AXS GUARD. 3. Users authenticate using only their AXS GUARD password, but the stored back-end server password is invalid (e.g. changed by Active Directory password policy). Authentication fails and the back-end server authentication form is returned to the user. As authentication is seamless, the administrator must verify whether the authentication problem is related to the back-end server or the AXS GUARD. 4. Users authenticate with the back-end server and the AXS GUARD password using a password separator string. The back-end password, which preceeds the separator string, is stored on the AXS GUARD for future back-end server authentication (Single Sign-On). 5. Users authenticate with the back-end server and the AXS GUARD password without a password separator string. This is only possible with a DIGIPASS. The back-end server password, which preceeds the DIGIPASS OTP, is stored on the AXS GUARD for futur authentication with the back-end server. 22

27 Chapter 3. Main Features of the Reverse Proxy The password separator string is configured in the AXS GUARD Administrator Tool and is only needed if DIGIPASS authentication isn t used. Only advanced administrators can configure the Password AutoLearn feature and the password separator string Predefined Back-End Servers The AXS GUARD Reverse Proxy server allows you to choose from a list of preconfigured back-end servers. When you choose a preconfigured back-end server, the correct settings are automatically applied, e.g. the base path settings, URL Sanitizing, form-based authentication settings, NTLM settings, etc. Additionally, some automatic redirects are activated depending on the selected back-end type, e.g. if you select MS OWA 2003, a redirect from to exchange is automatically configured. Do not use the No specific back-end option for a Microsoft Outlook Web Access (OWA) back-end server. Instead, select one of the predefined back-end servers. Failure to select one of the preconfigured back-end servers may cause the back-end authentication (NTLM) to fail. Back-end Description OWA 2010 With Office Outlook Web Access 2010, you can use a Web browser to access your Microsoft Exchange Server mailbox from any computer with an Internet connection. Only form-based authentication is supported. Also use this back-end for RPC over HTTPS. OWA 2007 With Office Outlook Web Access 2007, you can use a Web browser to access your Microsoft Exchange Server mailbox from any computer with an Internet connection. You can use Outlook Web Access with Microsoft Internet Explorer or many other browsers for UNIX, Apple Macintosh, or computers running Microsoft Windows. Outlook Web Access is an effective solution for people who require roaming, remote access, or crossplatform functionality. Also use this back-end for RPC over HTTPS. Two authentication types are available: Form-based authentication (see Section 3.9.3, Single Sign-On (SSO) and Password Auto-Learning ) Basic authentication (see Section 3.9.2, AXS GUARD Authentication ) OWA 2003 Same as above, but version Also use this back-end for RPC over HTTPS. Two authentication types are available: Form-based authentication (see Section 3.9.3, Single Sign-On (SSO) and Password Auto-Learning ) Basic authentication (see Section 3.9.2, AXS GUARD Authentication ) OWA 2000 Same as above, but version Also use this back-end for RPC over HTTPS. Basic authentication only (see Section 3.9.2, AXS GUARD Authentication ). Citrix 3 Citrix Metaframe 3 allows you to run applications you have at work from anywhere in the world. For detailed information about Citrix products, visit: 23

28 Chapter 3. Main Features of the Reverse Proxy Back-end Description Citrix 4 Citrix Metaframe 4 allows you to run applications you have at work from anywhere in the world. For detailed information about Citrix products, visit: Citrix Access 4 Back-end server for Citrix Access Gateway, Version 4.0. For detailed information about Citrix products, visit: XenApp 5 Citrix XenApp is a Windows application delivery system that manages applications in a datacenter and delivers them as an on-demand service to users anywhere using any device. For detailed information about Citrix products, visit: Table 3.1. Predefined Back-end Servers Advanced Settings These settings can and must be modified only by advanced administrators. Option Description Request Timeout Specifies the time in seconds during which the TCP connection between the connecting Internet client, the AXS GUARD Reverse Proxy and the back-end server remains alive (Keep-Alive parameter in HTTP 1.1). 300 seconds is the system default. Base URL Enter the URL(s) which are allowed, e.g. /public/. Enter a forward slash / to allow all paths on the server. Only the specified URL(s) are allowed. Allow tcp optimization to Server Enables the recycling of the existing TCP connection between the AXS GUARD Reverse Proxy and the back-end server. Allow tcp optimization to Client Enables the recycling of the existing TCP connection between the Internet client and the AXS GUARD Reverse Proxy Disable NTLM Disables NTLM authentication if checked. NTLM authentication is optional for an Outlook Web Access back-end server. CAUTION: It is highly insecure to enable NTLM authentication while TCP optimization is enabled. Public IP outside multilayer NAT The public IP address (Internet address) of the router connected to the AXS GUARD Internet interface. Public TCP port multilayer NAT The port number of the public IP address (Internet address) of the router connected to the AXS GUARD Internet interface. outside Activate debug logging If enabled, extra entries are added to the log files for debugging purposes. Table 3.2. Advanced Options 24

29 Chapter 4. Using the Reverse Proxy with FTP 4.1. Overview In this chapter, we explain the settings and features of the AXS GUARD Reverse Proxy server for use with FTP back-ends. The following topics are covered: Authentication The Source Host List FTP Connection Tracking 4.2. Supported Authentication Methods Only local AXS GUARD authentication is available for FTP back-end servers. It is not possible to authenticate with a DIGIPASS or Single Sign-On. The aim is to enable authentication for and protect FTP servers which allow anonymous authentication by default Source Host List You can limit FTP back-end access to a single or a set of source IP addresses, i.e. users on the Internet with static IP addresses. The IP addresses must be entered as comma-separated values without spaces. If an asterisk * is entered, requests from all source hosts are accepted FTP and Connection Tracking (SPICT) An important principle behind the AXS GUARD firewall is the use of connection tracking. Connection tracking refers to the ability to maintain connection information, such as the source and destination IP address, port number pairs (also known as socket pairs), protocol types, connection states, timeouts, etc. in memory tables. This property is known as stateful. Stateful firewalling (the connection states are explained in the AXS GUARD Firewall How To). is inherently more secure than its "stateless" counterpart, simple packet filtering. Connection tracking also considerably accelerates firewall checks (up to 90%), since packets belonging to a same established or assured connection do not require additional firewall checking. Figure 4.1. Example of SPICT 25

30 Chapter 4. Using the Reverse Proxy with FTP Figure 4.2. Resulting Firewall Connection Table FTP uses a control port (21) and a data connection port (20). The AXS GUARD Firewall uses SPICT to allow both connections through the Firewall. The AXS GUARD must be rebooted if a destination port different from 21 is configured for the FTP back-end server. 26

31 Chapter 5. HTTP(S) Configuration Examples 5.1. Overview In this section, we provide some examples of HTTP(s) Reverse Proxy configurations, such as: A catch all entry, as explained in Section 3.6.2, Non Listening Domain Catch All Entry. A Microsoft OWA 2003 back-end server with basic authentication. A Microsoft OWA 2003 back-end server with basic authentication and SSL certificates. A Citrix back-end server with Single Sign-On. Setting up a corporate web site. Setting up an Intranet web server with AXS GUARD autentication Non Listening Domain Catch All Entry 1. Go to Reverse Proxy > HTTP(S) 2. Add a new entry with the following settings: External hostname: leave empty Internal server name: the IP of a server in your LAN with a "Domain does not exist" page Back-end: No authentication, no specific back-end Advanced: Leave as is Figure 5.1. Creating a Catch All Entry 27

32 Chapter 5. HTTP(S) Configuration Examples 5.3. Microsoft OWA 2003 with Basic Authentication Overview This setup requires that the MS OWA 2003 back-end server is configured for basic authentication or integrated authentication. Integrated authentication is a special form of basic authentication using the same HTTP properties. The simultaneous use of basic authentication on the AXS GUARD and the back-end server is not possible. Since SSO (see Section 3.9.3, Single Sign-On (SSO) and Password Auto-Learning ) can only be used with form-based authentication on the back-end server, AXS GUARD authentication cannot be implemented. HTTP or HTTPS You can either choose HTTP or HTTPS for the internal and/or external connection. As explained in Section 3.8.2, HTTPS Gateway for External Connections, it is highly recommended to use HTTPS for the external connection, as this is the most secure option. Depending on the configuration settings of the MS OWA 2003 back-end server, HTTP or HTTPS can be selected for the internal connection. In this configuration example, we use HTTP for the internal connection Configuration 1. Log on to the AXS GUARD as explained in the AXS GUARD System Admininistration How To, which can be accessed via the Documentation button in the Admininistrator Tool. 2. Navigate to Reverse Proxy HTTP(S). 3. Click on Add New. 4. Follow the configuration steps as explained further. 5. Click on Save. The External Tab 1. Enter a name for the Reverse Proxy entry, e.g. owa Enter a desciption for the Reverse Proxy entry (optional). 3. Check the Enabled option. 4. Enter the external IP address. This is the Internet IP address of your AXS GUARD. 5. Enter the external port number. 443 is the default port for HTTPS. 6. Enable the Use secure HTTP (HTTPS) option. 7. Enter the Certificate connection name, e.g. owa (see notes below and Section 3.6.1, Concepts ). 8. Enter the external hostname. 9. Keep the default external certificate settings. 28