axsguard Gatekeeper Web Access How To v1.6

Transcription

1 axsguard Gatekeeper Web Access How To v1.6

2 Legal Notice 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. Trademarks VASCO, VACMAN, IDENTIKEY, axsguard, DIGIPASS, and 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. Radius Disclaimer Information on the RADIUS server provided in this document relates to its operation in the axsguard Gatekeeper environment. We recommend that you contact your NAS/RAS vendor for further information. Copyright 2009 VASCO data Security, Inc, VASCO data Security International GmbH All rights reserved.. 2

3 Table of Contents Table of Contents 1 Introduction Audience and Purpose of this document What is the axsguard Gatekeeper? About VASCO General Web Access Concepts Overview Worldwide Web communication protocols HyperText Tranfer Protocol (HTTP) Secure HyperText Transfer Protocol (HTTPS) File Transfer Protocol (FTP) What is a Proxy Server? Definition Advantages Web Access with HTTP Web Access with HTTPS Web Access with FTP FTP Access FQDN Containing the Word FTP Client Configuration Manual Browser Configuration Automatic Proxy Detection with WPAD Automatic Proxy Detection with the SSO Utility Transparent Proxy Web Access Caching Parent Proxy Web Access Filters Overview What is a Web Access Filter? Site Lists Time Restrictions Scenarios Ignore Site List Usage Authentication and Filter Priorities Filter Priorities

4 Table of Contents Authentication Other Web Access Controls General Settings Trend Micro Anti-Virus and Anti-Spyware Login Page Settings Web Access Practical Configuration Overview Client Configuration Manual Configuration Automatic Configuration Automatic Detection with SSO Utility Time Restriction Configuration Creating new Time Restrictions Viewing and Modifying Time Restrictions Configuring a Site List Creating a new Site List Viewing and Modifying Site Lists Predefined Site Lists Configuring a Web Access Filter (ACL) Creating a new Web Access Filter (ACL) Viewing and Modifying Web Access Filters (ACL) Predefined Web Access Filters (ACLs) Web Access System-Wide settings General Web Content Checking Settings Parent Proxy Settings Transparent Proxy Settings Web Access Authentication Settings Web Access Login Page Configuration Logo Configuration Message Configuration Trend Micro Anti-Virus and Anti-Spyware Settings Practical Configuration Examples Overview System-Wide Access for Anti-Virus and Microsoft Updates Allow Web Access to a Specific Group and allow Updates Allow Web Access to a Specific Group except one User Deny Web Access to a Specific Group, except One User

5 Table of Contents Allow Web Access to a Specific Blocked Site for a Specific Group...60 Windows Server Update Services Centralization...62 Restrict FTP Access through the Proxy...64 Example of an Ignore Site List Web Access Tools Overview URL Checker URL Reporter Rebuilding Web Access Cache Web Access Logs Overview Accessing Logs Log Types Access Log Block Log Ignore Log Trend Micro Detailed Web Access Log Web Access Statistics and Reporting Overview Accessing Statistics and generating reports Client Requests Hourly Requests Most Accessed Websites Blocked Websites Blocked Sitelist Usage Statistics: Automatic Compressing Feature Troubleshooting Support Overview If you encounter a problem Return procedure if you have a hardware failure

6 Table of Contents Illustration Index Image 1: Web Access Module...14 Image 2: HTTP Connection...16 Image 3: HTTPS Connect Principle...17 Image 4: FTP Traffic Inspection...19 Image 5: FTP over HTTP...19 Image 6: Manual Browser Configuration...20 Image 7: Automatic Proxy Detection with SSO Utility...22 Image 8: Transparent Proxy Server...23 Image 9: Web Access Caching...24 Image 10: Parent Proxy (ISP)...25 Image 11: Web Access Filter Concept...26 Image 12: Ignore Site List Usage...30 Image 13: Authentication and Web Access Filter Priorities...31 Image 14: Web Access Authentication...32 Image 15: Trend Micro Pattern Update Notification...33 Image 16: Cusomizing the Web Access Login...34 Image 17: Internet Explorer Proxy Settings...36 Image 18: SSO Proxy Settings...37 Image 19: Predefined Time Restrictions...38 Image 20: Creating a new Time Restriction...38 Image 21: Time Restrictions Overview...40 Image 22: Modify Existing Time Restrictions...40 Image 23: Creating a new Site List...41 Image 24: Overview of Predefined Site Lists...43 Image 25: Predef-Porn Site List...44 Image 26: Creating a new Web Access Filter (ACL)...45 Image 27: Predefined Web Access Filters...47 Image 28: General Web Content Checking Settings...49 Image 29: Parent Proxy Settings...50 Image 30: web-transparent-proxy NAT redirection rule...51 Image 31: Web Access and Firewall Linked Authentication...52 Image 32: Web Access Logo Cutomization...53 Image 33: Customizing Web Access Messages...54 Image 34: Update Trend Micro...55 Image 35: Allow Anti-Virus and Microsoft Updates System-Wide...56 Image 36: Configuring the Group Web Access Settings

7 Table of Contents Image 37: User Level Web Access Settings...58 Image 38: Configuring the User Web Access Settings...59 Image 39: Allowing Access to a Blocked Site...60 Image 40: Configuring an Exception...60 Image 41: Centralize Updates on Single Server...62 Image 42: Allow FTP Site List...64 Image 43: Deny FTP Site List...64 Image 44: Creating an Ignore Site List...66 Image 45: Adding an Ignore Site List to an ACL...66 Image 46: Ignored Site replaced by Logo...67 Image 47: Web Access URL Checker...68 Image 48: Web Access URL Reporter...70 Image 49: Rebuild Proxy Cache...71 Image 50: Overview of Web Access Logs...72 Image 51: Web Access Accept Log entries...73 Image 52: Web Access Block Log entries...74 Image 53: Ignore Log Example...74 Image 54: Trend Micro Detailed Web Access Log...75 Image 55: Web Access Report Index...76 Image 56: Client Requests...77 Image 57: Hourly Requests...77 Image 58: Most accessed Websites...78 Image 59: Blocked Websites...78 Image 60: Blocked Sitelist Usage...79 Image 61: Automatic Compressing Feature

8 Table of Contents Index of Tables Table 1: Overview of Site List Types: Web Access > Filters > Sites > Add New > List Types...27 Table 2: Web Access > Filters > ACL: Using Scenarios...29 Table 3: Web Access > Filters > ACL > Scenarios...30 Table 4: Web Access > Filters > Times...39 Table 5: Web Access > Filters > Sites...41 Table 6: Web Access > Filters > Sites > Site List Entries...42 Table 7: Web Access > Filters > Sites...44 Table 8: Web Access > Filters > ACL...46 Table 9: Web Access > Filters > ACL...48 Table 10: Web Access > General > General Web Content Checking...50 Table 11: Web Access > General > Parent Proxy Settings...51 Table 12: Web Access > Tools > URL Checker...69 Table 13: Web Access > Tools > URL Reporter...70 Table 14: Web Access > Log > Access...73 Table 15: Web Access > Log > Block...74 Table 16: Web Access > Log > Access > Result Codes

9 1 Introduction 1.1 Audience and Purpose of this document Introduction This How To describes how Web Access security and control can be implemented in your network using the axsguard Gatekeeper Web Access Module (Proxy Server). It is intended for technical experts and network administrators. In section 2, the axsguard Gatekeeper Web Access General Concepts, such as security, caching and filtering are explained. In section 3,the different elements, such as Times and Site Lists, composing Web Access Filters are explained as well as possible scenarios. Section 4 explains how Web Access Filters (ACLs) are configured using the elements explained in section 3. Section 5 provides some practical examples. Section 6 covers the Web Access Tools, such as the URL checker and the URL reporter. Section 7 explains Web Access logging. In section 8, we explain Web Access statistics and how to generate reports based on different criteria. In section 9, some solutions are offered to solve difficulties. In section 10, we explain how to request support and how to return hardware for replacement. 9

10 Introduction Other documents in the set of axsguard Gatekeeper documentation include: axsguard Gatekeeper Installation Guide, which explains how to set up the axsguard Gatekeeper, and is intended for technical personnel and / or system administrators. 'How to guides', which provide detailed information on configuration of each of the features available as 'addon' modules (explained in the next section). These guides cover specific features such as: axsguard Gatekeeper Authentication axsguard Gatekeeper Firewall axsguard Gatekeeper Single Sign-On axsguard Gatekeeper VPN axsguard Gatekeeper Reverse Proxy axsguard Gatekeeper Directory Services Access to axsguard Gatekeeper guides is provided through the permanently on-screen Documentation button in the Administrator Tool. Further resources available include: Context-sensitive help, which is accessible in the axsguard Gatekeeper Administrator Tool through the Help button. This button is permanently available and displays information related to the current screen. Training courses covering axsguard Gatekeeper features in detail. These courses address all levels of expertise. Please see for further information. Welcome to axsguard Gatekeeper security. 10

11 1.1 Introduction What is the axsguard Gatekeeper? The axsguard Gatekeeper is an authentication appliance, intended for small and medium sized enterprises. In addition to strong authentication, the axsguard Gatekeeper 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, , Web access and VPN management. The axsguard Gatekeeper can easily be integrated into existing IT infrastructures as a stand-alone 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. 1.2 About VASCO VASCO is a leading supplier of strong authentication and Electronic Signature solutions and services specializing in Internet Security applications and transactions. VASCO has positioned itself as a global software company for Internet Security serving customers in more than 100 countries, including many international financial institutions. VASCO s prime markets are the financial sector, enterprise security, e-commerce and egovernment. Over 50 of VASCO s client authentication technologies, products and services are based on the VASCO s one and unique core authentication platform: VACMAN. VASCO solutions comprise combinations of the VACMAN core authentication platform, IDENTIKEY authentication server, axsguard authentication appliances, DIGIPASS client Password and Electronic Signature software and DIGIPASS PLUS authentication services. For further information on these security solutions, please see 11

12 2 General Web Access Concepts 2.1 Overview General Web Access Concepts This section describes the concepts underpinning Internet access control through the use of the axsguard Gatekeeper Web Access Module (Proxy Server). Some key definitions are provided in order to better understand the operation and configuration of this Module explained in the following chapters. Topics covered in this section include: A quick introduction to worldwide Internet communication protocols, such as HTTP, HTTPS and FTP. Web Access Concepts, such as caching, virus detection and content scanning. Web Access client configuration concepts. Web Access caching properties. Web Access with a Parent Proxy. 2.2 Worldwide Web communication protocols A protocol is a formal description of formats and rules computers must follow in order to successfully exchange messages. Protocols can describe low-level details of machine-to-machine communication, such as the order in which bits and bytes are sent across a wire, or high-level exchanges between applications, such as the way in which two programs transfer a file across the Internet, e.g. the File Transfer Protocol. The axsguard Gatekeeper Web Access Module provides access control and security for high-level protocols such as HTTP, HTTPS and FTP. These protocols are briefly explained in the following subsections HyperText Tranfer Protocol (HTTP) The HyperText Transfer Protocol or HTTP is a protocol which is used by clients on the Internet to retrieve web pages from a web server. It is a high-level application protocol operating by default on TCP port 80. If another port is used, it has to be specified in the URL, e.g. HTTP defines how messages should be formatted and transmitted and which actions web browsers should take in response to certain commands, for instance when a URL is entered in a web browser. HTTP traffic uses cleartext transmission, which allows its content to be monitored and scanned. There are two versions of HTTP, 1.0 and 1.1, which are briefly described below. In-depth information about both versions of HTTP is available in RFC 1945 (HTTP/1.0) and RFC 2616 (HTTP/1.1). HTTP/1.0 Typically, an HTTP client initiates a request and opens a new connection for each new request. It establishes a Transmission Control Protocol (TCP) connection to a particular port on a host (port 80 by default). An HTTP server listening on that port waits for the client to send a request message. Upon receiving the request, the server sends back a status line, such as "HTTP/ OK", and a message of its own. HTTP/1.0 is a stateless protocol because each command is executed independently, without taking previous commands into account. 12

13 General Web Access Concepts HTTP/1.1 HTTP/1.0, in its documented form, made no provision for persistent connections. Some HTTP/1.0 implementations, however, use a Keep-Alive header to request that a connection persists. Because this design did not interoperate with intermediate proxies, HTTP/1.1 specifies a more general solution. HTTP/1.1 makes persistent connections the default. HTTP/1.1 clients, servers, and proxies assume that a connection will be kept open after the transmission of a request and its response. The protocol does allow an implementation to close a connection at any time, in order to manage its resources, although it is best to do so only after the end of a response. Because an implementation may prefer not to use persistent connections if it cannot efficiently scale to large numbers of connections or may want to cleanly terminate one for resource-management reasons, the protocol permits it to send a Connection: close header to inform the recipient that the connection will not be reused. HTTP/1.1 is the most commonly used version in today's implementations Secure HyperText Transfer Protocol (HTTPS) The HTTPS protocol is the secure version of the HTTP protocol described above. Its functioning is almost identical, except that all traffic is encrypted using Secure Socket Layer (SSL) technology. This prevents eavesdropping and offers protection against man-in-the-middle attacks. With HTTPS, the client uses the server's public key to encrypt the data transmission. The public key of the server is included in the Public Certificate (More information about Public Certificates is available in the axsguard Gatekeeper IPsec How To, which is accessible by clicking on the permanently available Documentation button in the Administrator Tool). By convention, URLs which require an SSL connection start with HTTPS rather than HTTP. A TCP port may be specified in an HTTPS URL. If none is specified, port 443 is used by default. Unlike HTTP, HTTPS is a stateful protocol. HTTPS reuses the same connection, rather than opening a new one for each request. More information about the axsguard Gatekeeper Web Access Module and HTTPS is provided in section File Transfer Protocol (FTP) FTP is a file transfer protocol for exchanging and manipulating files over the Internet. An FTP client may connect to an FTP server to manipulate files on that server. FTP runs exclusively over TCP. By default, it listens on port 21 for incoming connections. A connection to this port from the FTP client forms the control stream on which commands are passed from the FTP client to the FTP server and on occasion from the FTP server to the FTP client. FTP uses a separate connection for control and data. This means that for the actual file transfer, a different connection is required which is called the data stream. 13

14 General 2.3 What is a Proxy Server? Definition Web Access Concepts The axsguard Gatekeeper Web Access Module (Proxy Server), as illustrated below, is an application layer control module, which services requests on behalf of its clients by forwarding these requests to their destination. It listens on port A client connects to the axsguard Gatekeeper, requesting a web page on an Internet server. The axsguard Gatekeeper makes a separate connection to the Internet server and requests the page on behalf of the client, if allowed by the Access Control List (ACL). ACLs are explained in section 3. Optionally, the client's request or the server's response may be altered / blocked by the axsguard Gatekeeper depending on the applicable Web Access Access Control List (ACL). If the request is allowed by the axsguard Gatekeeper Proxy, it may still be blocked by the Anti-Virus and / or Anti-Spyware Module, based on the automatically downloaded Virus Pattern files and / or Site Lists. If the page is cached, it is provided to the requesting client without contacting the Internet server (see section 2.8). Image 1: Web Access Module 14

15 2.3.2 General Web Access Concepts Advantages ADVANCED INTERNET ACCESS CONTROL AND MONITORING The use of the axsguard Gatekeeper Web Access Module (Proxy Server) offers several advantages over direct connections: Allowed websites can be tailored to the user's needs level via Authentication: You can enforce user authentication for Web Access. Not only do users in the LAN have to authenticate to access the Internet, but the accessible pages / servers depend on the user's Web Access rights. The axsguard Gatekeeper Proxy increases speed and saves bandwidth through the Caching of Web Pages: Each time a page is accessed on the Internet, a copy is kept on the axsguard Gatekeeper. This is the same principle applied with browser caching. This technique not only allows to retrieve web pages more rapidly, but also allows an important reduction in HTTP traffic and saves bandwidth. Cashing is further explained in section 2.8. Statistics and Reporting: User authentication facilitates the tracking of accessed and blocked web pages at the user level. These functions are further explained in sections 7 and 8. Content Scanning: You can implement filters (ACLs are explained in section 3) to control access to web sites, servers or specific URLs. These filters can be applied to any axsguard Gatekeeper security level, such as the user level, the group level, the computer level or system-wide. For more information about axsguard Gatekeeper Security levels, refer to the System Administration How To, which is accessible by clicking on the permanently available Documentation button in the Administrator Tool. ADVANCED ANTI-MALWARE PROTECTION If you purchased and activated the axsguard Gatekeeper Trend Micro Anti-Virus and Anti-Spyware Module (see section 3.4.2) is purchased, you benefit from: Anti-Virus Protection: Viruses can easily be transmitted by visiting web sites containing malicious code. All Web traffic is scanned to prevent clients from being infected. Note that this isn't the case when web traffic is not channeled through the Web Access Module (see section 2.4). Anti-Spyware Protection: Spyware is software installed on a client without the user's knowledge or consent. This software secretly gathers information about this user while he/she navigates the Internet and is mostly used for advertising purposes. The Web Access Module offers Anti-Spyware Protection if this Module is purchased and activated. Anti-Phishing Protection: Phishing is a fraudulent process used by attackers attempting to acquire sensitive information such as user names, passwords and credit card details. This is done by posing as a trustworthy entity in electronic communications. CUSTOMIZABLE AUTHENTICATION PAGE AND NOTIFICATION MESSAGES You can change the default axsguard Gatekeeper Proxy Server login / blocking page to display your company logo and even add custom notification messages, such as custom instructions, warnings and disclaimers. The procedures to change the default logo and messages are explained in section 4.9. The login / blocking page is displayed when: Users need to authenticate for Web Access. When an unauthorized page is blocked. 15

16 General 2.4 Web Access Concepts Web Access with HTTP As explained in section 2.3, a client initiates a request to browse a web site on the Internet. Typically, web sites are hosted on servers which listen for incoming connections on port 80. Other ports may be used. Rather than connecting directly to the web server, the client's request is handled by the axsguard Gatekeeper Web Access module, which inspects it. The inspection is based on the implemented ACL (explained in chapter 3). Assuming the request is allowed by the ACL, the axsguard Gatekeeper checks whether the web page has been previously requested by another client in the network (caching, see section 2.8). If this is not the case, the Gatekeeper terminates the connection and initiates a new one towards the web server on behalf of the requesting client. The requested web page is then retrieved by the axsguard Gatekeeper Web Access Module. Once the page is retrieved, it is checked for virusses and other malware before it is cached. The caching function allows to accelerate future requests for the same web page by other clients. Finally, the requested web page is forwarded to the requesting client. Cautions The best practice is to never allow surfing without the Web Access and Content Scanning Module, because it bypasses the axsguard Gatekeeper Anti-Virus protection. It is NOT recommended to implement Firewall Policies which allow clients to directly access web servers on the Internet, as this prevents the axsguard Gatekeeper from inspecting the web traffic and exposes the client's vulnerabilities. Image 2: HTTP Connection 16

17 General 2.5 Web Access Concepts Web Access with HTTPS As mentioned in section 2.2.2, HTTPS is a secure, stateful protocol which uses end-to-end encryption. A single connection is used for all requests. It is not possible to manipulate HTTPS traffic, since this would be considered a man-in-the-middle attack. Furthermore, content scanning is impossible, as HTTPS network traffic is inherently encrypted. The browser connects to the axsguard Gatekeeper Web Access Module and sends a CONNECT URL request for a tunnel to the remote (secure) web server, as shown below. Once the CONNECT message is received, the axsguard Gatekeeper automatically tunnels the HTTPS request if the requested URL is allowed by the implemented ACL and port 443 (which is the standard port for HTTPS traffic) is listed in the safe proxy ports (see section 3.4.1). In short, only the initial CONNECT URL is checked. HTTPS traffic cannot be checked for content because it is encrypted. If the initial URL is not allowed, the axsguard Gatekeeper refuses the connection. Cautions The best practice is to never allow surfing without the Web Access and Content Scanning Module, because it bypasses the axsguard Gatekeeper Anti-Virus protection. It is NOT recommended to implement Firewall Policies which allow clients to directly access web servers on the Internet, as this prevents the axsguard Gatekeeper from inspecting the web traffic and exposes the client's vulnerabilities. HTTPS traffic content cannot be scanned since it is encrypted, as opposed to HTTP. Only the initial CONNECT URL request is checked. Image 3: HTTPS Connect Principle 17

18 2.6 General Web Access Concepts Web Access with FTP Rather than connecting directly to the FTP server, the FTP request is handled by the axsguard Gatekeeper Web Access Module (Proxy Server), which first inspects it. When a client attempts to connect to an FTP site via a browser, the axsguard Gatekeeper inspects the request and either allows or denies the connection based on the implemented ACL (explained in chapter 3) and the Safe Proxy Ports list (see page 50). Caution For the correct configuration of the axsguard Gatekeeper Web Access Module, it is crucial to make a distiction between real FTP traffic, which uses standard port 21 and a Fully Qualified Domain Name (FQDN) which contains the word 'ftp': ftp://ftpserver.somedomain.com is different from FTP Access By default, the axsguard Gatekeeper Web Access Module (Proxy Server) allows FTP traffic, as port 21 is listed in the Safe Proxy Ports list (see page 50). This is a system-wide setting, which means that all users can access FTP servers via the Web Access Module (if authorized by the ACL), even if the user's Firewall settings prevent it. To prevent users from accessing FTP servers via the Web Access Module, port 21 should be removed from the safe proxy ports. This is further explained in section 3.4. FTP traffic is inspected as follows: 1. A client initiates a request to browse an FTP site on the Internet, e.g. ftp://ftp.somedomain.com. In most cases, FTP servers listen for incoming connections on port Rather than connecting directly to the FTP server, the FTP request is handled by the Web Access module (Proxy Server), which inspects it, as shown in Image If port 21 is listed in the axsguard Gatekeeper Safe Proxy Ports and the destination server is allowed by the ACL (see chapter 3), the FTP request is forwarded to the FTP server. 18

19 General Web Access Concepts Image 4: FTP Traffic Inspection FQDN Containing the Word FTP In case you make an HTTP connection to a server which 'appears' to be an FTP server, because the FQDN starts with or contains the word 'ftp' as shown below, traffic is handled the same way as explained in section 2.4, since it is regular HTTP traffic. Image 5: FTP over HTTP 19

20 General 2.7 Web Access Concepts Client Configuration Caution If the browser on the client is not configured to use the axsguard Gatekeeper Web Access Module, web pages are directly retrieved from the web server by the requesting client. This means that the anti-virus scanning, content scanning, logging and statistics functionalities of the Web Access Module are bypassed, except when the Transparent Proxy option is used (see section 2.7.4). The Web Access Module operates on TCP port In order to access web pages via the axsguard Gatekeeper Web Access Module (Proxy Server): The Web Access Feature should be enabled. Client browsers need to be correctly configured. Several methods exist to configure clients to use Web Access via the axsguard Gatekeeper. These are explained in the following subsections Manual Browser Configuration The LAN IP address of the axsguard Gatekeeper and the Proxy port (3128) need to be manually configured in the browser (see image below). The configuration steps vary depending on the used Internet browser. The practical client configuration is explained in section 4.2. Image 6: Manual Browser Configuration 20

21 2.7.2 General Web Access Concepts Automatic Proxy Detection with WPAD The axsguard Gatekeeper is equipped with an automatic detection system based on the Web Proxy Auto Discovery (WPAD) protocol. This protocol allows browsers to automatically locate proxy servers in a network. The WPAD protocol functions as follows: The browser on the client requests a DNS address lookup for "wpad.your.domain.com" where "your.domain.com" is the client's configured domain name. "wpad.your.domain.com" should resolve to the LAN IP address of the axsguard Gatekeeper (see tip below). Once the WPAD request is received, the axsguard Gatekeeper provides the correct proxy configuration to the requesting client. The client's browser automatically updates its proxy configuration so that all web traffic is handled by the axsguard Gatekeeper Web Access Module. If no valid response is received, a new DNS request is sent by removing the lowest leaf name of the configured domain, for instance wpad.domain.com. If no valid answer is received after removing the lowest leaf name, no proxy server is used for Web Access. Tip If you use a third-party DNS server (not the axsguard Gatekeeper), e.g. a Microsoft Active Directory server, the wpad.your.domain.com entry should be added to its DNS repository so that it correctly resolves to the axsguard Gatekeeper LAN IP address. 21

22 General Web Access Concepts Automatic Proxy Detection with the SSO Utility The Single Sign-On (SSO) Utility can be dowloaded directly from the axsguard Gatekeeper and installed on the clients. It makes axsguard Gatekeeper authentication easy and transparent to users. The SSO utility can be configured to automatically and transparently adjust the user's Internet browser settings when successfully authenticated, so that the axsguard Gatekeeper is used as a Proxy Server for Web Access. More information about the SSO Utility is available in the Single Sign-On Utility (SSO) How To, available by clicking the permanently available Documentation button in the Administrator Tool. Image 7: Automatic Proxy Detection with SSO Utility 22

23 General Web Access Concepts Transparent Proxy The axsguard Gatekeeper can be used as a Transparent Proxy as shown below. Transparent Proxies are also commonly known as intercepting proxies. The axsguard Gatekeeper Transparent Proxy listens on port 3127 (as apposed to the regular Proxy which listens on port 3128). Transparent or intercepting proxies are commonly used in businesses to prevent avoidance of implemented user policies (ACLs), and to ease administrative burden, since no client browser configuration is required. Caution This setup is only possible for regular HTTP traffic, which uses port 80 by default. It does not work for FTP, HTTPS (secure) sites and HTTP sites which dynamically act on the client's browser configuration settings. Therefore, VASCO does not recommend its use. Operation HTTP requests are automatically redirected towards port 3127 of the Web Access Module (Proxy Server) without any client-side configuration. To configure the axsguard Gatekeeper as a Transparent Proxy, the web-transparent-proxy NAT redirection rule needs to be enabled. This is explained in section 4.7. Image 8: Transparent Proxy Server 23

24 General 2.8 Web Access Concepts Web Access Caching axsguard Gatekeeper web caching is the process by which web documents (e.g. HTML pages, images) are temporarily saved in order to reduce bandwidth usage, server load, and perceived lag. The web cache stores copies of documents passing through it; subsequent client requests may be satisfied from the cache if certain conditions are met. Web caches can be deployed in a variety of ways. User agent caches, such as those in web browsers, are private caches, operating on behalf of a single user. Intermediaries can also implement shared caches that serve more than one person, such as the axsguard Gatekeeper Web Access Module (see below). Image 9: Web Access Caching Stale vs. Fresh pages Copies of pages on the axsguard Gatekeeper Web Access Module may be out of date once a page has been updated at the source. Out-of-date web pages are often referred to as stale, while current pages are often referred to as fresh. The Web Access Module has a system to keep track of fresh and stale pages. Tags are used to prevent fresh pages from being retrieved in response to new requests. If a page is stale, it is automatically refreshed. Although caching improves efficiency, it is possible that in some instances the refresh procedure fails. In such a case, the bowser cache should be cleaned. The axsguard Gatekeeper also has a built-in tool to clean the Web Access Module cache, as explained in section 6.4. Cache Size The Cache Size determines the maximum amount of disk space which should be reserved to cache web documents. The settings are explained in section

25 General 2.9 Web Access Concepts Parent Proxy Caution If a Parent Proxy Server is used, all requested pages which are not cached by the axsguard Gatekeeper are forwarded to the Parent Proxy server. Intranet pages are not accessible via the Internet. Therefore, the Intranet pages need to be explicitly registered on the axsguard Gatekeeper. This prevents requests for Intranet pages to be forwarded to the parent Proxy Server (see section 4.6.2). This section describes the operation of the axsguard Gatekeeper Web Access Module with a second (parent) Proxy Server, e.g. the Proxy Server of an Internet Service Provider, as shown below. This Parent Proxy may also impose certain restrictions, which are beyond the control of axsguard Gatekeeper administrators. Rather than sending requests directly to a web server, the axsguard Gatekeeper sends the requests to the Proxy Server of the ISP. The proxy server of the ISP uses the same principles as the axsguard Gatekeeper. A page is requested directly from the source on behalf of the axsguard Gatekeeper, stored in the parent Proxy Server's cache and finally returned to the axsguard Gatekeeper. In turn, the axsguard Gatekeeper caches a copy of the retrieved page and replies to the requesting client. Image 10: Parent Proxy (ISP) Notes The axsguard Gatekeeper Anti-Virus is configured as a Parent Proxy Server (see section 4.6.2). Using another Proxy Server (e.g. your ISP Proxy) with the axsguard Gatekeeper AntiVirus system creates a Proxy Server chain. 25

26 Web 3 Web Access Filters 3.1 Overview Access Filters This section explains the concept of axsguard Gatekeeper Web Access Filters or Access Control Lists (ACL) and the elements composing them. Topics covered in this section include: A general explanation of Web Access Filters. Site Lists, which determine the sites users can or cannot access. Times, which determine when the Site Lists are in effect. Scenarios which can be applied to Web Access Filters. Additional Web Access Controls, such as blocking dangerous file extensions and changing the default logo of the login page. Web Access Filter Priorities and Authentication. 3.2 What is a Web Access Filter? Web Access Filters or Access Control Lists (ACL), as shown below, control the access to specific URLs or entire websites. They consist of Site Lists (see section 3.2.1) and Times (see section 3.2.2). Once an ACL has been configured, it can be added to any axsguard Gatekeeper Security level, such as a user, a group, a computer or the axsguard Gatekeeper system itself (system-wide implementation). Computer and system-wide filters are activated on the fly, while group and user filters are activated after authentication (see section 3.3). Image 11: Web Access Filter Concept 26

27 Web Access Filters Site Lists A Site List is a set of defined websites, URLs, IP addresses or key words for which access may be allowed, ignored or blocked according to the Site List Type. Three types of Site Lists can be defined, as explained in Table 1: Table 1: Overview of Site List Types: Web Access > Filters > Sites > Add New > List Types Type Action Allow List The websites, URLs, IP addresses and key words in this list are allowed, e.g. the corporate intranet site. Block List The websites, URLs, IP addresses and key words in this list are blocked, e.g. all sites containing pornographic references and terms, such as sex. Ignore List (see section 3.2.4) The websites, URLs, IP addresses and key words in this list are ignored. This type of list is used to allow access to a bonafide web page which embeds URL(s) which are registered in a Block List. By adding the blocked URL to the Ignore List, the bonafide webpage itself is accessible, while the embedded part is replaced by an axsguard Gatekeeper logo. Two types of Site Lists exist, automatic and manually defined lists. Automatic Lists: If you purchased and activated the Trend Micro Anti-Virus and Anti-Spyware Module (see section 2.3.2), Site Lists are updated daily. As such, known malafide sites are automatically included and blocked, based on their IP address or DNS name. The axsguard Gatekeeper provides predefined Site Lists (automatically updated, similar to Anti-Virus patterns), which are also included in the unrestricted ACL. The Site Lists which are included in te unrestricted ACL can be disabled by creating a custom ACL (see chapter 4). The automatic lists are devided into categories in relation to the filtered content. A few examples are: blacklist-aggressive, blacklist-spyware, etc. Over malafide sites are included. Manually Defined Lists: Lists can be maintained manually by entering IP addresses and character strings either matching an entire URL or a part thereof. For instance, gambling matches all URLs containing the word gambling. Wilcards can be used to make the matches even more generic. The configuration of Site Lists is explained in section Time Restrictions Time Restrictions define start and stop times for a Web Access Filter for each day of the week. This means you can enforce different Web Access scenarios (see section 3.2.3) during the course of a same day, e.g. a scenario which applies during the defined times (e.g. restricted Web Access during office hours) and a scenario which applies outside the defined times (e.g. permissive Web Access after office hours and during lunch breaks). If the defined time is set to 24/7, only one Web Access scenario applies. Whenever a web page is requested, the appropriate scenario is automatically applied. Days for which no Time Restrictions have been defined, automatically fall under the outside the defined times category. The configuration of Time Restrictions is explained in section

28 3.2.3 Web Access Filters Scenarios An ACL combines Times and Site Lists. Each ACL determines whether access is allowed or not during a specific time. Web Access control is achieved either by blocking everything and defining exceptions (block scenario) or by allowing everything and specifying sites to which access should be blocked (allow scenario). Ignore Lists, as explained in section 3.2.1, Table 1 are independent of Scenarios and Times. An example of an Ignore List is provided in section Block Scenario The Block scenario blocks access to all sites, except to the ones which are specifically allowed. Select the desired Allow Lists (see 3.2.1). Allow Scenario The Allow scenario allows access to all websites, except to the ones which are specifically blocked. Select the desired Block Lists (see 3.2.1). If there are any sites which are registered in a Block List, e.g. a site containing the word sex, (see section 3.2.1), the blocking can be overruled in the Allow Scenario by: Creating an Allow List and entering those site(s) of the Block List to which access should be allowed, e.g. =m. Selecting the newly created Allow List in the Exception Site List. The configuration of Web Access Filters (ACLs) is explained in section 4.5. Practical examples are provided in chapter 5. 28

29 Web Access Filters Example Block and Allow Scenario (Based on Table 2) Assume you need to create a Web Access Filter (ACL) which only allows access to the corporate Intranet and the Virgin Express reservation site during office hours. Access to any other websites is prohibited during office hours. First, a Time Restriction defining the office needs to be created, e.g. 8:00 AM until 5:00 PM. Second, a Site List in which the corporate URL(s) and the Virgin Express site are included and allowed needs to be created. Once this Site List is configured, create a new ACL, select the Block Scenario during the specified Time Restriction and check the Site List containing the corporate URL(s) and the Virgin Express site in the Allowed Site List. To permit access to other websites during off hours, select the Allow scenario outside the specified Time Restriction and make the desired selections. Table 2: Web Access > Filters > ACL: Using Scenarios Web Access Filter used in Example on page 29 Time Restriction: Working Hours (8:00 AM until 5:00 PM) During the Time Restriction (8:00 AM 05:00 PM) Scenario Block Scenario Allowed Sites Corporate Intranet: intranet.mycompany.com Virgin Express Site: =m Outside the Time Restriction (05:01 PM 07:59 AM) Scenario Allow Scenario Blocked Site List Phishing Sites, Gambling Sites, Porn Sites. Exceptions Site List See the Exception Site List as explained above. Virgin Express Site: =m 29

30 Web Access Filters Ignore Site List Usage As explained in section 3.2.1, this type of list is used to allow access to a bonafide web page which embeds URL(s) which are registered in a Block List. By adding the blocked URL to the Ignore List, the bonafide webpage itself is accessible, while the embedded part (e.g. an advertising banner) is replaced by an axsguard Gatekeeper logo. Table 3: Web Access > Filters > ACL > Scenarios Example of a Web Access Filter with Ignore Site List Time Restriction: 24/7 Every day of the week. During the Time Restriction (Always) Scenario Block Scenario Allowed Sites Corporate Intranet: intranet.mycompany.com Virgin Express Site: =m Yahoo: Ignore Site List(s) Advertising, banners, pop-ups, and others. Result The advertising banners are not displayed when visiting the allowed sites, e.g. providing the Fully Qualified Domain Name (FQDN) and / or IP addresses pointing to these banners are correctly registered in the Ignore List. Image 12: Ignore Site List Usage 30

31 3.3 Web Access Filters Authentication and Filter Priorities Caution Web Access Filters should be configured to provide the strongest security at the system level. The priority in which Web Access Filters (ACLs) are applied is crucial for control and security (see section below). This prevents unauthenticated users from accessing more sites than authorized while authenticated Filter Priorities There are two distinct methods by which a Web Access Filter is assigned to an IP address as shown below: System and computer level Web Access is assigned by the axsguard Gatekeeper at boot time and are independent of user Authentication (see section 3.2). By default, nothing is allowed at the system level. This is the most secure setting. Group and user level Web Access is assigned dynamically, depending on the provided user credentials (see section 3.2). This is the recommended and most secure procedure. After receiving a request, the axsguard Gatekeeper's Web Access Module checks which Web Access Filter (ACL) is applicable: a system (system-wide), a computer, a group or a user level filter. A user or group ACL is only assigned after successful authentication. The IP address requesting Web Access is automatically linked to one of the four security levels as described below. Image 13: Authentication and Web Access Filter Priorities 31

32 Web Access Filters An ACL is assigned to a requesting IP addresses as follows: The axsguard Gatekeeper system level filter is assigned by default in the absence of any other filter; An existing filter at the computer level overrules the axsguard Gatekeeper system level filter; Denial of Web Access at the system or computer level prompts the user for authentication (see image below), except if the user is already authenticated; The axsguard Gatekeeper assigns the defined group level Web Access rights following a successful authentication, unless a user level filter exists, in which case; The filter defined for the user overrules the group level filter. Image 14: Web Access Authentication Tips The login screen as shown above may also be activated by typing tool in the URL field of your browser. It can also be customized (see section 3.4.3). More information about user authentication is available in the axsguard Gatekeeper Authentication How To, which is accessible by clicking on the permanently available Documentation button in the Administrator Tool Authentication Web Access Rights determine the type of Web pages users may or may not visit and are based on the provided axsguard Gatekeeper user credentials. The axsguard Gatekeeper allows the implementation of several Authentication Methods, such as DIGIPASS Authentication for Web Access. The setups and configuration of these Authentication Methods are explained in the axsguard Gatekeeper Authentication How To, accessible by clicking on the permanently available Documentation button in the Administrator Tool. 32

33 Web 3.4 Access Filters Other Web Access Controls Besides Internet browsing Acceleration and Content Filtering, the axsguard Gatekeeper Web Access Module allows the implementation of additional security checks, such as the blocking of dangerous file extensions, defining allowed TCP ports and Parent Proxy Settings, as explained in sections 2.9 and It is also possible to change the default login page (see page 32) General Settings Blocking file extensions: It is possible to define file extensions which should be blocked while browsing the Internet, for instance scr or pif files. This provides additional security, as some executable files are automatically downloaded and executed while a site is being visited. Such files can potentially execute malicious code and compromise the integrity of the client's operating system. This blocking feature, if used, is applicable system-wide and therefore enforced for every client connected to the network via the axsguard Gatekeeper Web Access Module. The configuration is explained in section Safe Proxy Ports: It is possible to define which ports are allowed by the Web Access Module, e.g. port 80, port 21 and port 443, which are standard ports used to browse the Internet. If needed, ports which are required for other services can be added. The configuration is explained in section Note File extensions are blocked based on the URL, not the content of the web page Trend Micro Anti-Virus and Anti-Spyware The Trend Micro Anti-Virus and Anti-Spyware Module (if purchased and enabled) is a process running on top of the axsguard Gatekeeper Web Access Module (Parent Proxy Server, see section 2.9). This means that web traffic is scanned for malicious content, such as spyware and virusses. The Trend Micro Anti-Virus and Anti-Spyware Module automatically downloads the latest pattern files. If no pattern files are present, users will not be able to access web pages as a security precaution (since the pages cannot be scanned for the very latest virusses and spyware). In case users are no longer able to access the Web via the axsguard Gatekeeper Proxy, administrators should check if the latest pattern files have been downloaded. Administrators are notified by as soon as the patterns have been updated (see below), but the process can be triggered manually as well. This is explained in section Image 15: Trend Micro Pattern Update Notification 33

34 Web Access Filters Login Page Settings You can change the default axsguard Gatekeeper Web Access login / blocking page to display your company logo. You can also add custom notification messages, such as instructions, warnings and disclaimers in standard text or HTML (see example below). The specified logo and entered notification(s) replace the default axsguard Gatekeeper logo and text as shown on page 32. The procedures to customize the axsguard Gatekeeper login page and notification messages are explained in section 4.9. Image 16: Cusomizing the Web Access Login Note This logo is also used for Webmail. See the axsguard Gatekeeper Mail Storage How To, which can be accessed by clicking on the permanently available Documentation button in the Administrator Tool. 34

35 4 Web Access Practical Configuration 4.1 Overview Web Access Practical Configuration This section explains how to build a Web Access Filter (ACL) and covers the following topics: Client-side configuration (see section 2.7). The configuration of Time Restrictions (see section 3.2.2). The configuration of Site Lists (see section 3.2.1). Web Access General Settings and their effects. Transparent Proxy Settings (see section 2.7.4). Configuration examples. 4.2 Client Configuration As explained in section 2.7, your client (Internet browser) needs to be correctly configured to use the axsguard Gatekeeper Proxy (for traffic to be monitored and scanned). There are several methods to configure your browser. We briefly explain the methods here. For practical reasons, we limit the explanation to Microsoft Internet Explorer. For other browsers, consult the adequate documentation Manual Configuration 1. Double-click on the Internet Explorer Icon on your desktop or click on Start > All Programs > Internet Explorer. 2. In the Internet Explorer menu, click on Tools > Internet Options. 3. Click on the Connections tab. 4. Click on LAN Settings (see Image 17). 5. Check use a Proxy Server for your LAN 6. Enter the LAN IP address of the axsguard Gatekeeper. 7. Enter the axsguard Gatekeeper Proxy port number (3128). 8. Click on the Advanced button. 9. Check Use the same proxy server for all protocols. 10. Click on OK (twice). 11. Close the Internet Explorer and start it again. You will be requested to log on as shown on page

36 Web Access Practical Configuration Image 17: Internet Explorer Proxy Settings Automatic Configuration The axsguard Gatekeeper is equipped with an automatic detection system based on the Web Proxy Auto Discovery (WPAD) protocol (see section 2.7.2). This protocol allows browsers to automatically locate Proxy Servers in a network. 1. Repeat steps 1 to 4 as explained in section Check Automatically detect settings and click on OK. 3. Close the Internet Explorer and start it again. You will be requested to log on as shown on page 32. Tip If you use a third-party DNS server (not the axsguard Gatekeeper), e.g. a Microsoft Active Directory server, the wpad.your.domain.com entry should be added to its DNS repository so that it correctly resolves to the axsguard Gatekeeper LAN IP address. 36

37 Web Access Practical Configuration Automatic Detection with SSO Utility The SSO tool allows axsguard Gatekeeper users to easily and transparently authenticate for Firewall and Web Access. More information about the SSO tool is available in the axsguard Gatekeeper Single Sign-On Utility How To, which is accessible by clicking on the permanently available Documentation button in the Administrator Tool. 1. Download and install the SSO Utility. 2. In the Windows Tray, right-click on the SSO icon and select Edit / Delete Profiles. 3. Select the desired profile. 4. Check the Use axsguard as Proxy Server option and click on Save. 5. In the Windows Tray, right-click on the SSO icon and select Settings. 6. Check the Change Firefox Proxy Settings (if applicable) and click on OK. Image 18: SSO Proxy Settings 37

38 Web Access Practical 4.3 Configuration Time Restriction Configuration As explained in section 3.2.1, Time Restrictions allow administators to define a start and stop times for a Web Access Filter (ACL). Predefined Time Restrictions are readily available on the axsguard Gatekeeper for convenience Creating new Time Restrictions 1. Log on to the axsguard Gatekeeper Administrator Tool as explained in the System Administration How To, which is accessible by clicking on the permanently available Documentation button in the Administrator Tool. 2. Navigate to Web Access > Filters > Times. A screen as shown below is displayed. Image 19: Predefined Time Restrictions 3. Click on Add New. 4. Enter the settings as explained in Table 4 and shown in Image Click on Save. An activation notice is displayed. Image 20: Creating a new Time Restriction 38

39 Web Access Practical Configuration Table 4: Web Access > Filters > Times Time Restriction Configuration Settings Reference Name Enter a name for the Time Restriction, using lower cases without spaces, starting with an alphabetic character and thereafter any number of alphanumeric characters. Only the following special characters are allowed: back slash (\), hyphen (-), underscore (_), full stop(.), and the "at" sign (@). Description Enter a description for the Time Restriction (optional). Day of the Week Enter the time frame for each day of the week in the HH:MM-HH:MM format, for instance 09:00-17:30. It is possible to define multiple time frames for a single day. In such a case, the list should be comma separated, for instance 09:0012:30,13:30-17:30. If no times are entered, e.g. on Saturday and Sunday, the 'outside Time Restriction' scenario applies (also see section 3.2.2). Example Based on the settings as shown on page 38, the following applies: During business hours (During the Time Restriction), from Monday until Friday, from 09:00 AM to 12:30 PM and from 01:00 PM to 05:30 PM, Web Access Policy X is applicable. Outside business hours, from Monday until Friday, between 12:30 PM and 01:00 PM, Web Access Policy Y is applicable. On Saturdays and Sundays, Web Access Policy Y applies, since left empty (see Table 4 and section 3.2.2). 39

40 Web Access Practical Configuration Viewing and Modifying Time Restrictions In order to view or modify the available Time Restrictions: 1. Log on to the axsguard Gatekeeper Administrator Tool as explained in the System Administration How To, which is accessible by clicking on the permanently available Documentation button in the Administrator Tool. 2. Navigate to Web Access > Filters > Times. 3. Click on the Time Restriction's Reference Name to view its configuration details (see below). Image 21: Time Restrictions Overview 4. Modify the settings as needed, according to the guidelines provided in section Image 22: Modify Existing Time Restrictions 5. Click on Update. Tip In the Time Restriction configuration screen (see image above), you can click on Edit as New to create a new Time Restriction based on an existing one. 40

41 Web Access Practical 4.4 Configuration Configuring a Site List A Site List contains a list of defined web sites, URLs or key words for which access may be allowed, ignored or blocked (see section 3.2.1). If the axsguard Gatekeeper Trend Micro Anti-Virus and Anti-Spyware Module is purchased and activated, predefined Site Lists become available and are automatically updated (see sections and 3.4.2). Predefined Site Lists are readily available on the axsguard Gatekeeper for convenience Creating a new Site List 1. Log on to the axsguard Gatekeeper Administrator Tool as explained in the System Administration How To, which is accessible by clicking on the permanently available Documentation button in the Administrator Tool. 2. Click the Add new button. A screen as shown below is displayed. 3. Enter the settings as explained in Table Click on Save. Image 23: Creating a new Site List Table 5: Web Access > Filters > Sites Overview of Site List Configuration Settings Reference Name Enter a Site List name, using lower cases without spaces, starting with an alphabetic character and thereafter any number of alphanumeric characters. Only the listed special characters are allowed: back slash (\), hyphen (-), underscore (_), full stop(.), and the "at" sign (@). Description Enter a description for the Site List (optional). Enabled Check / uncheck to enable / disable the filter. List Type Three types are available: Allow List, Block List and Ignore List (see section 3.2.1). Allow List: contains sites to which access is allowed. Block List: contains sites to which access is denied. Ignore List: contains sites which should be ignored. Site List Enter the sites according to the format as specified in the table below. Each entry should be made on a separate line. 41

42 Web Access Practical Configuration Site List Entries Format Site List entries are composed of character strings which match: A entire URL in which the protocol is specified, e.g. ftp://ftp.somesite.com vs. A host name, e.g. ftp.somesite.com A part of a URL, e.g. somesite An IP address, e.g Wildcards, which are representations of characters (explained in Table 6) Wildcards can be used in the strings in order to make matches more generic. A table containing a set of allowed wildcards is provided below. Table 6: Web Access > Filters > Sites > Site List Entries Overview of allowed wildcards for Site List entries * Represents any character zero or multiple times, e.g. matches as well as or Represents any character, but only once, for instance matches but NOT ^ ^ at the beginning of a string indicates that the search should only match the beginning of that string, e.g. ^ftp matches ftp.microsoft.com, ftp.vasco.com, but NOT (see section 2.6 and the example on page 64). $ $ at the end of a string indicates that the search should only match the end of that string, e.g. vasco.com/products$ matches with but not with Example of a protocol-specific match Assume that you wish to grant access to a specific host, e.g. ftp.somesite.com, which is running several services, such as FTP, HTTP and HTTPS. Only group X should be allowed access to the host, 24 hours a day, 7 days a week. FTP access should be denied, while HTTP and HTTPS access to the server should be allowed. 1. Create a Site List in which and are allowed, e.g. somesite-allow. 2. Create another Site List in which access to ftp://ftp.somesite.com is denied, e.g. somesite-deny. 3. Create a new ACL and select the Block Scenario. 4. Select somesite-deny as a Blocked Site List. Specify somesite-allow as an Exception Site List. 5. Assign the ACL to group X. 42

43 Web Access Practical Configuration Viewing and Modifying Site Lists In order to view the available Site Lists: 1. Log on to the axsguard Gatekeeper Administrator Tool as explained in the System Administration How To, which is accessible by clicking on the permanently available Documentation button in the Administrator Tool. 2. Navigate to Web Access > Filters > Sites. A screen as shown below is displayed. 3. Click on a Site List's Reference Name to view its configuration details. Image 24: Overview of Predefined Site Lists Predefined Site Lists Predefined Site Lists are available on the axsguard Gatekeeper for convenience. Two types exist: Automatically updated Site Lists: These lists are automatically updated by the Trend Micro Anti-Virus and Anti-Spyware Module (see sections and 3.4.2), e.g. blacklists such as blacklist-aggressive. An overview of automatically updated Site Lists is available in Table 7. Others: These lists are predefined to facilitate the configuration of the Web Access Module, e.g. the predef-porn Site List, which prevents access to porn sites (see below). To access the Predefined Site Lists, follow the same steps as explained above. Image 25 is an example of a Predefined Site List. Tips Predefined Site Lists cannot be modified, only enabled or disabled. To create a new Site List based on an existing one, click on the Reference Name, then click on Edit as New. Make sure the Enabled flag is set if you wish to use a Site List in an ACL (see Image 24). 43

44 Web Access Practical Configuration Image 25: Predef-Porn Site List Table 7: Web Access > Filters > Sites Overview of Automatically Updated Predefined Site Lists antivirus-update Allows access to servers hosting essential updates for Anti-Virus software (see tip below). blacklist-* Denies access to sites containing potentially offensive and dangerous content, such as violence, drug abuse, phishing, spyware, etc. ('*' needs to be replaced by the type of content, e.g. drugs, gambling, etc.) microsoft-update Allows access to Microsoft update servers. predef-porn Denies access to sites containing pornographic material. predef-porn-overrule Allows access to bonafide sites, which indicentally include words, such as 'sex' (see example on page 29). Tip Anti-Virus update servers should be added specifically for the Anti-Virus software you are using on your clients. To know which update servers are being used by your software, consult your Anti-Virus software documentation. On the axsguard Gatekeeper, select the antivirus-update Site List, click on Edit as New and add the Anti-Virus update servers. Add the updated Site List to the appropriate ACL and assign the ACL to the appropriate user, group, computer or the system (system-wide). 44

45 Web Access Practical 4.5 Configuration Configuring a Web Access Filter (ACL) Web Access Filters combine Time Restrictions (see section 4.3) and Site Lists (see section 4.4). Predefined Web Access Filters are readily available on the axsguard Gatekeeper for convenience. Web Access scenarios are explained in section Creating a new Web Access Filter (ACL) 1. Log on to the axsguard Gatekeeper Administrator Tool as explained in the System Administration How To, which is accessible by clicking on the permanently available Documentation button in the Administrator Tool. 2. Navigate to Web Access > Filters > ACL. 3. Click on Add new. A screen as shown below is displayed. 4. Enter the configuration settings as explained in Table Click on Save. Image 26: Creating a new Web Access Filter (ACL) 45

46 Web Access Practical Configuration Table 8: Web Access > Filters > ACL Overview of Web Access Filter (ACL) Configuration Settings Access Filter Name Enter an ACL name, using lower cases without spaces, starting with an alphabetic character and thereafter any number of alphanumeric characters. Only the listed special characters are allowed: back slash (\), hyphen (-), underscore (_), full stop(.), and the "at" sign Description Provide a description for the new ACL (optional). Enabled Check to enable the ACL. An ACL can also be enabled / disabled in the list of available ACLs (see section 4.5.2). Caution ACLs are not applied if not enabled, even when selected for a user, a group, a computer or the system (systemwide). Time Restriction Select the applicable Time Restriction (see section 4.3) from the drop-down list. Tabs During Time Restriction Select the scenario which should be applied during the Time Restriction. Outside Time Restriction Select the scenario which should be applied outside the Time Restriction. Ignore lists Specify which site(s) or URL(s) should be ignored (see section 3.2.4). Scenario Choose the applicable scenario as explained in section Block Scenario and specify exceptions Allowed Site List Check the Site List(s) which should be allowed during and/or outside a given Time Restriction. Allow scenario and specify exceptions Blocked Site List Check the Site List(s) which should be blocked during and/or outside a given Time Restriction. Exception Site List If you wish to grant access to any sites registered in a blocked list, the blocking can be overruled, as explained in section

47 Web Access Practical Configuration Viewing and Modifying Web Access Filters (ACL) To view and modify existing ACLs: 1. Log on to the axsguard Gatekeeper Administrator Tool as explained in the System Administration How To, which is accessible by clicking on the permanently available Documentation button in the Administrator Tool. 2. Navigate to Web Access > Filters > ACL. 3. Click on an Access Filter Name to view its configuration details. Image 27: Predefined Web Access Filters Tip To create a new ACL based on an existing one, click on the Access Filter Name, then click on Edit as New. Make sure the Enabled flag is set if you wish to use the ACL. ACLs are not applied if not enabled, even when selected for a user, a group, a computer or the system (system-wide). 47

48 Web Access Practical Configuration Predefined Web Access Filters (ACLs) Predefined Web Access Filters are readily available on the axsguard Gatekeeper for convenience (see the table below). To access the Predefined ACLs, follow the same steps as provided in section Table 9: Web Access > Filters > ACL Overview of Predefined ACLs automatic-updates Allows 24 hour access to Anti-Virus and Microsoft update servers (see the tip below). no-access Web Access is not allowed. predef-no-porn Allows 24 hour access to all sites, except sites containing pornographic and potentially offensive content (blacklisted sites, see page 44). unrestricted Allows 24 hour access to all sites, except blacklisted sites (see page 44). working-hours During working hours: Blocks all access, except to allowed sites. Outside working hours: Allows access to all sites, except blacklisted sites (see page 44) Tip Anti-Virus update servers should be added specifically for the Anti-Virus software you are using on your clients. To know which update servers are being used by your software, consult your Anti-Virus software documentation. On the axsguard Gatekeeper, select the antivirus-update Site List, click on Edit as New and add the Anti-Virus update servers. Add the updated Site List to the appropriate ACL and assign the ACL to the appropriate user, group, computer or the system (system-wide). 48

49 Web Access Practical 4.6 Configuration Web Access System-Wide settings This section explains the system-wide configuration settings of the Web Access Module. 1. Log on to the axsguard Gatekeeper Administrator Tool as explained in the System Administration How To, which is accessible by clicking on the permanently available Documentation button in the Administrator Tool. 2. Navigate to Web Access > General. Two tabs are available: General Web Content Checking Settings and Parent Proxy Settings. Both are explained separately in the following subsections General Web Content Checking Settings Caution Web Access Filters should be configured by default to provide the strongest security at the system level. The priority in which filters are applied is crucial for control and security (see section 3.3). This prevents unauthenticated users from accessing more sites than authorized while authenticated. The General Web Content Checking Settings tab is selected by default when the General configuration menu is accessed. A screen as shown below is displayed. Image 28: General Web Content Checking Settings Enter the settings as explained in Table

50 Web Access Practical Configuration Table 10: Web Access > General > General Web Content Checking Overview of General Web Content Checking Settings Proxy Cache Size (See section 2.8) Enter the maximum cache storage capacity (in Mb) which should be available on the axsguard Gatekeeper's hard drive. 100 Mb is the system default. Maximum Cache object Size (See section 2.8) Object caching eliminates the need to repeatedly download the same data. Enter the maximum allowed cache object size (in Mb). Objects exceeding the specified size are not cached. System Web Access Filter Enter the Web Access Filter which should be applied at the system level (see section 3.3). Make sure to enforce the strictest security. Block File Extensions Add the file extension(s) which should be blocked as explained in section 3.4. Each extension should be added individually. This is a system-wide setting, which means the specified extensions are blocked for all users. The file extensions you wish to block need to be entered without a dot, e.g. exe, bat, com, etc. (as shown in Image 28). Safe Proxy Ports Add / remove the port(s) which should be allowed / denied by the Web Access Module as explained in section 3.4, e.g. remove port 21 if you wish to prevent access to FTP sites (ftp://ftp.someserver.com) This is a system-wide setting, which means the specified ports are allowed for all users. Parent Proxy Settings This tab allows you to enter your Parent Proxy Settings (see section 2.9). Caution If a parent Proxy Server is used, all pages which are not cached by the axsguard Gatekeeper are forwarded to the parent proxy server. Intranet pages are not accessible via the Internet. Therefore, the Intranet pages need to be explicitly registered on the axsguard Gatekeeper. This prevents requests for Intranet pages to be forwarded to the parent Proxy Server Select the Parent Proxy Settings tab to enter the proxy settings as explained in Table 11. Contact your ISP to obtain the necessary information, if necessary. Image 29: Parent Proxy Settings 50

51 Web Access Practical Configuration Table 11: Web Access > General > Parent Proxy Settings Overview of Parent Proxy Configuration Settings ISP Proxy Server Enter the IP address or DNS name of your ISP's proxy server. ISP Proxy Server Port Enter the port number which is used by your ISP's proxy server. ISP Proxy User Enter the user name which is needed to authenticate with the ISP's proxy server. ISP Proxy Password Enter the password which is needed to authenticate with the ISP's proxy server. Do not use the Parent Proxy for Add your corporate intranet URLs or any URLs which may be accessed directly (not via the Proxy Server of the ISP). Each entry should be made on a separate line. Notes The axsguard Gatekeeper Anti-Virus system is configured as a Parent Proxy Server. (If the Trend Micro Anti-Virus and Anti-Spyware Module is purchased and enabled, see pages 15 and 33). Using another Proxy Server (e.g. your ISP Proxy) with the axsguard Gatekeeper AntiVirus system creates a Proxy Server chain. 4.7 Transparent Proxy Settings As explained in section 2.7.4, the axsguard Gatekeeper can be used as a Transparent Proxy server. This setup requires the web-transparent-proxy NAT redirection rule to be enabled: Caution This setup is only possible for regular HTTP traffic, which uses port 80 by default. It does not work for FTP, HTTPS (secure) sites and HTTP sites which dynamically act on the client's browser configuration settings. Therefore, VASCO does not recommend its use. 1. Log on to the axsguard Gatekeeper Administrator Tool as explained in the System Administration How To, which is accessible by clicking on the permanently available Documentation button in the Administrator Tool. 2. Navigate to Network > NAT > Port Redirection. 3. Enable (check) the web-transparent-proxy NAT redirection rule as shown below. Image 30: web-transparent-proxy NAT redirection rule All traffic for TCP port 80 is intercepted and redirected to port 3127 for access control. 51

52 Web Access Practical Configuration For more information about NAT, consult the System Administration and Firewall How To guides, available by clicking the permanently available Documentation button in the Administrator Tool. 4.8 Web Access Authentication Settings Authentication for Web Access can be linked or unlinked to Firewall Authentication. The details about linked and unlinked Authentication as well as the configuration settings are explained in the Authentication How To, accessible by clicking the permanently available Documentation button in the Administrator Tool. To link Web Access and Firewall Authentication (RECOMMENDED): 1. Log on to the axsguard Gatekeeper Administrator Tool as explained in the System Administration How To, which is accessible by clicking on the permanently available on-screen Documentation button in the Administrator Tool. 2. Navigate to Authentication > General. A screen as shown below appears. 3. Check Link Web Access and Firewall Authentication. 4. Click on Update. Image 31: Web Access and Firewall Linked Authentication To unlink Web Access and Firewall Authentication use the recommended settings according to your network topology as explained in the axsguard Gatekeeper Authentication How To, which is accessible by clicking on the permanently available Documentation button in the Administrator Tool. 52

53 Web Access Practical 4.9 Configuration Web Access Login Page Configuration This section explains how to customize your axsguard Gatekeeper Web Access login and blocking page (see sections and You can customize: The default logo. Notification messages, such as instructions, warnings, etc. You can use standard text or HTML Logo Configuration Caution Only the JPG format is supported until further notice. To change the default axsguard Gatekeeper to your company logo (see below): 1. Log on to the axsguard Gatekeeper Administrator Tool as explained in the System Administration How To, which is accessible by clicking on the permanently available on-screen Documentation button in the Administrator Tool. 2. Navigate to System > Customer. 3. Click on the Customer Logo Settings tab. 4. Click on Browse to select your company (or any other) logo. 5. Click on Update. Image 32: Web Access Logo Cutomization Note This logo is also used for Webmail (see the axsguard Gatekeeper Mail Storage How To, which can be accessed by clicking on the permanently available Documentation button in the Administrator Tool). 53

54 Web Access Practical Configuration Message Configuration To change the default axsguard Gatekeeper Web Access login / notification messages (see below): 1. Log on to the axsguard Gatekeeper Administrator Tool as explained in the System Administration How To, which is accessible by clicking on the permanently available on-screen Documentation button in the Administrator Tool. 2. Navigate to Web Access > Localization. 3. Enter the desired messages in the appropriate fields using standard text or HTML. 4. Click on Update. Image 33: Customizing Web Access Messages 54

55 Web Access Practical 4.10 Configuration Trend Micro Anti-Virus and Anti-Spyware Settings As mentioned in section 3.4.2, the Trend Micro Anti-Virus and Anti-Spyware Module automatically downloads pattern files to ensure your network is protected against the latest virusses and spyware. If the pattern files are none existent (because they haven't initially been downloaded), users will not be able to access web pages as a security precaution (since the pages cannot be scanned for the very latest virusses and spyware and the Trend Micro Module functions as a Parent Proxy). To manually trigger Trend Micro updates: 1. Log on to the axsguard Gatekeeper Administrator Tool as explained in the System Administration How To, which is accessible by clicking on the permanently available Documentation button in the Administrator Tool. 2. Navigate to Anti-Malware > Status > Trend Micro (see image below) 3. Click on Check for antivirus pattern updates. The patterns should start downloading and updating immediately, after which users will be able to access the Web again. Image 34: Update Trend Micro 55

56 5 Practical Configuration Examples 5.1 Overview Practical Configuration Examples This section provides some basic configuration examples based on predefined Web Access Filters (see section 4.5.3). To modify the configuration, you must log on to the axsguard Gatekeeper with administrator privileges. This procedure is explained in the axsguard Gatekeeper System Administration How To, which is accessible by clicking on the permanently available Documentation button on the Administrator Tool. 5.2 System-Wide Access for Anti-Virus and Microsoft Updates Caution Web Access Filters should be configured to provide the strongest security at the system level. The priority in which Web Access Filters (ACLs) are applied is crucial for control and security (see section 3.3). This prevents unauthenticated users from accessing more sites than authorized while authenticated. Configuration 1. Navigate to Web Access > General as explained in section Select automatic updates as your system web access filter (see image below). 3. Click on Update. Image 35: Allow Anti-Virus and Microsoft Updates System-Wide 56

57 5.3 Practical Configuration Examples Allow Web Access to a Specific Group and allow Updates Purpose The purpose is to allow Anti-Virus and Microsoft updates for all clients which are connected to the network (system-wide), also at night and when not authenticated. In addition, only one specific group is allowed Web Access to all sites, except porn sites and other sites containing malicious and offensive material. Configuration 1. Follow the same steps as explained in section Navigate to Users&Groups > Groups and select the group to which Web Access should be allowed. 3. In the Web Access tab, select predef-no-porn as the Web Access filter (see below). 4. Click on Update. Image 36: Configuring the Group Web Access Settings 5.4 Allow Web Access to a Specific Group except one User Purpose The purpose is the same as explained in section 5.3, except that one user of the group is denied access to the Internet, except for Anti-Virus and Microsoft updates. Configuration 1. Follow the same steps as explained in section Navigate to Users&Groups > Users and select the user to which web access should be denied. 3. Click on the user's Web Access tab (see Image 37). 57

58 Practical Configuration Examples Image 37: User Level Web Access Settings 4. Check the Overrule Group Web Access option. 5. Select the automatic-updates Allow Automatic Updates ACL. 6. Click on Update. Tip Web Access Rights at the user level overrule the settings which are configured at the group level (see section 3.3). 58

59 5.5 Practical Configuration Examples Deny Web Access to a Specific Group, except One User Purpose The purpose is the exact opposite as explained in section 5.4: A specific group is denied Web Access, except for Anti-Virus and Microsoft updates. One member of the group is allowed to Web Access, with the exception of porn sites and and other sites containing malicious and offensive material. Configuration 1. Follow the same steps as explained in section Navigate to Users&Groups > Groups and select the group to which access should be denied. 3. In the Web Access Filter tab, select the automatic-updates Allow Automatic Updates ACL. 4. Navigate to Users&Groups > Users and select the user of the same group to which access should be allowed. 5. In the Web Access tab, make sure the Overrule Group Web Access Filter option is checked (see below). 6. Select the predef-no-porn ACL as shown below. 7. Click on Update. Image 38: Configuring the User Web Access Settings 59

60 Practical 5.6 Configuration Examples Allow Web Access to a Specific Blocked Site for a Specific Group Purpose The purpose is to: Overrule the blocking of a website of which the name (or a portion thereof) has been automatically registered as malicious by the Trend Micro Anti-Virus and Anti-Spyware Module (see sections and 3.2.1). Allow access to this website 24 hours a day, 7 days a week. Allow this access to one specific group. Configuration 1. Navigate to Web Access > Filters >Sites and create a new Site List (allow list) as explained in section Add the blocked site to the list and set the List Type to allow list (see image below). Image 39: Allowing Access to a Blocked Site 3. Click on Save. 4. Navigate to Web Access > Filters > ACL and select the ACL which blocks access to the site, i.e. the ACL which applies to the group which should be allowed access to the site (see below). Image 40: Configuring an Exception 60

61 Practical Configuration Examples 5. In the During Time Restriction tab, check the newly created Site List as an exception. 6. Click on Update. Result Group X now has permanent Web Access to Note Depending on the applicable scenario (Block or Allow), you have to select the allowed site either in the Allowed or Exceptions Site List. 61

62 Practical 5.7 Configuration Examples Windows Server Update Services Centralization Purpose The purpose is to: Centralize critical Windows updates and Anti-Virus updates on one server, i.e. an Active Directory (AD) server. This not only saves bandwidth, but also allows system administrators to control and apply system updates more efficiently. Allow access to the updates 24 hours a day, 7 days a week. Workstations (clients) are denied access to these updates. Configuration Deny Web Access at the axsguard Gatekeeper system level. 1. Navigate to Web Access > General. 2. Set the System Web Access Filter to no access. 3. Click on Update. Allow Access to the Microsoft and Anti-Virus update servers to your AD server. 1. Navigate to Computers. 2. Click on the Computer Name of your AD server. Image 41: Centralize Updates on Single Server 3. Click on the Web Access Control Tab. 4. Check the Overrule system Web Access Filter. 5. Set automatic updates Allow automatic updates as the Web Access Filter. 6. Click on Udpate. Configure the group and user-level Web Access rights according to your needs. The steps to modify the group and user settings are provided on pages 57 and

63 Practical Configuration Examples Result Only the AD server has access to Microsoft and Anti-Virus updates. The downloaded updates are centrally managed and pushed to the clients via the AD server and download bandwidth is saved. Tip Anti-Virus update servers should be added specifically for the Anti-Virus software you are using on your clients. To know which update servers are being used by your software, consult your Anti-Virus software documentation. On the axsguard Gatekeeper, select the antivirus-update Site List, click on Edit as New and add the Anti-Virus update servers. Add the updated Site List to the appropriate ACL and assign the ACL to the appropriate user, group, computer or the system (system-wide). 63

64 Practical 5.8 Configuration Examples Restrict FTP Access through the Proxy Purpose By default, the axsguard Gatekeeper Web Access Module is set to accept FTP traffic (port 21), which is a system-wide setting (see sections 2.6 and 4.6.1). The purpose is to: Allow all users to access the sites defined in the predef-no-porn ACL. Limit FTP traffic to allowed servers only. Limit FTP traffic to specific groups. Restrict any other users / groups from accessing FTP servers, even when using anonymizers. An anonymizer or an anonymous proxy is a browser-based tool that attempts to make activity on the Internet untraceable. It accesses the Internet on the user's behalf, protecting personal information by hiding the source computer's identifying information. Anonymizers are also used to bypass web technologies which limit online content access to a certain number of minutes or quantity of data, e.g. Creating the necessary Site Lists 1. Create a Site List with specifically allowed FTP server(s), as explained in section 4.4.1, e.g. ftp://ftp.belnet.be. Label it as 'ftpallowed'. Image 42: Allow FTP Site List 2. Create and label a Site List which denies access to any ftp server, as explained in section 4.4.1, e.g. *ftp*. Label it as 'noftp'. Image 43: Deny FTP Site List 64

65 Practical Configuration Examples Creating the necessary ACLs 1. Select the predef-no-porn ACL and click on Edit as New. 2. Label it as 'custom-ftp1'. 3. Select the Allow Scenario. 4. Check all Blocked Site Lists, including the Site List labeled 'noftp'. 5. Check the Site List labeled 'ftpallowed' as an Exception Site List. 6. Click on Save. 7. Repeat the steps 1 to Provide another label for the ACL, e.g. 'custom-ftp2'. 9. Make sure the Site List labeled 'ftpallowed' is unchecked. 10. Click on Save. Implementing the new ACLs 1. Set the System Web Access Filter to the newly created ACL 'custom-ftp2'. 2. Add the 'custom-ftp1' ACL to the desired group, e.g. 'accounting'. Result All members of the group 'accounting' have access to the sites defined in the predef-no-porn ACL and ftp://ftp.belnet.be via the axsguard Gatekeeper Proxy. Other FTP servers cannot be accessed. All other users / groups have access to the sites defined in the predef-no-porn ACL, but cannot access any FTP server, including ftp://ftp.belnet.be. Tip Filtering occurs at the URL level. Some anonymizers completely transform or rewrite the original URL so that it no longer matches the Web Filter. As a result, the FTP request is not detected. Define these anonymizers in a separate Block Site List and include them in an ACL to block any unauthorized (FTP) sites. 65

66 Practical 5.9 Configuration Examples Example of an Ignore Site List Purpose The purpose is to: Ignore advertising banners in bonafide web pages (They are replaced by an axsguard Gatekeeper logo) at the system level. Configuration 1. Navigate to Web Access > Filters > Sites. 2. Create a new Site List of the Ignore type, e.g. nopublicity. Image 44: Creating an Ignore Site List 3. Enter the advertising sites (or others) to be ignored. 4. Click on Save. 5. Navigate to Web Access > Filters > ACL. 6. Select the Web Filter which is applied at the system level (see tip on page 67). Image 45: Adding an Ignore Site List to an ACL 7. Click on the Ignore Lists Tab. 8. Check the nopublicity ACL created in steps 2 to Click on Update. 66

67 Practical Configuration Examples Tip To know the Web Access Filter which is applied at the system level, navigate to: Web Access > General. Result The advertising sites listed in Image 44 are automatically ignored and replaced by an axsguard Gatekeeper logo (as shown below). This is a system level Web Filter, so it applies to all the clients connected to the axsguard Gatekeeper network, authenticated or not. Image 46: Ignored Site replaced by Logo 67

68 Web Access Tools 6 Web Access Tools 6.1 Overview This section explains the function of the Web Access Module tools: The URL Checker. The URL Blocker. Rebuilding the Web Access cache. 6.2 URL Checker The URL Checker allows axsguard Gatekeeper system administators to check the following: Whether a given URL or site is blocked or allowed by a Site List or an ACL. In case the URL or site is blocked, which ACL or Site List is responsible. This is useful to allow access to a blocked site in case a website of which the name (or a portion thereof) or the IP address has been automatically flagged as malicious by the Trend Micro Anti-Virus and Anti-Spyware Module (see pages 15 and 33). The procedure is explained in section 5.6. Note Escaped URL characters are not decoded and do not return a hit. To access the URL Checker: 1. Log on to the axsguard Gatekeeper Administrator Tool as explained in the System Administration How To, which is accessible by clicking on the permanently available Documentation button in the Administrator Tool. 2. Navigate to Web Access > Tools > URL Checker. A screen as shown below appears. 3. Enter the settings as explained in Table 12. Image 47: Web Access URL Checker 68

69 Web Access Tools Table 12: Web Access > Tools > URL Checker URL Checker Usage Blocked URL Enter the URL or IP address to be checked. Site List to be used Select the Site List to be searched. If none is selected, the URL checker searches all available site lists. Web Access Filter to be used Select the ACL to be searched. If none is selected, the URL checker searches all available ACLs. Check Click this button to check the entered URL. Clear Click this button to clear the screen. Tip If known, specifying the ACL or Site List accelerates the search. 69

70 Web Access Tools 6.3 URL Reporter The URL Reporter allows axsguard Gatekeeper system administators to report malicious URLs which have not been registered by the Trend Micro Anti-Virus and Anti-Spyware Module (see pages 15 and 33). The report is sent to the VASCO back office for inspection. To access the URL Reporter: 1. Log on to the axsguard Gatekeeper Administrator Tool as explained in the System Administration How To, which is accessible by clicking on the permanently available Documentation button in the Administrator Tool. 2. Navigate to Web Access > Tools > URL Reporter. A screen as shown below appears. 3. Enter the settings as explained in Table 13. Image 48: Web Access URL Reporter Table 13: Web Access > Tools > URL Reporter URL Reporter Usage Malicious URL Enter the full address of the malicious site, e.g. Content Category Select the appropriate Content Category. Currently 8 categories are available. Receive acknowledgement Check this option if your wish to receive an acknowledgement of your report via . address to receive acknowledgement Specify the address to which the acknowledgement should be sent. Send Click this button to send the report to the VASCO back office for inspection. Clear Click this button to cancel the operation. 70

71 Web Access Tools 6.4 Rebuilding Web Access Cache The Web Access Cache (see section 2.8) should be cleaned or rebuilt if: The cache size (see section 4.6.1) has been reduced. The axsguard Gatekeeper cache has been corrupted due to an incorrect shutdown (power failure). To clean or rebuild the Web Access cache: 1. Log on to the axsguard Gatekeeper Administrator Tool as explained in the System Administration How To, which is accessible by clicking on the permanently available Documentation button in the Administrator Tool. 2. Navigate to System > Tools > Actions. A screen as shown below appears. 3. Click the Rebuild Proxy Cache button. Image 49: Rebuild Proxy Cache 71

72 Web 7 Web Access Logs 7.1 Overview Access Logs Logs are records of current and past events relating to Web Access. Three types of Web Access logs are available: the access log, the block log and the ignore log. These are explained in section Accessing Logs The Web Access logs are organized in a table and are ordered chronologically by default. The most recent log is listed first. Logs are labeled using the YYYY-MM-DD format. The log size is measured in Kilobytes (KB). To access Web Access Logs: 1. Log on to the axsguard Gatekeeper Administrator Tool as explained in the System Administration How To, which is accessible by clicking on the permanently available Documentation button in the Administrator Tool. 2. Navigate to Web Access > Log. A screen as shown below appears. 3. Click on the desired log date / log type (see section 7.3) to view the log entries. Image 50: Overview of Web Access Logs 72

73 Web 7.3 Access Logs Log Types Web Access logs are organized according to the type of gathered information. Three types are available and are listed below. The Access log: contains all entries for allowed sites and webpages which were successfully accessed. The Block log: contains entries for all access attempts to blocked pages or sites. The Ignore log: contains entries for ignored pages or sites, as explained in sections and The Trend Micro Detailed Web Access Log: contains detailed entries off all Web requests Access Log 1. Navigate to Web Access > Log. 2. Click on the desired access log date to view the log entries. A screen as shown below appears. The entries are explained in Table 14. Image 51: Web Access Accept Log entries Table 14: Web Access > Log > Access Overview of Accept Log Entries Time The time when the axsguard Gatekeeper Web Access cache was accessed. Host The IP address of the accessing host. User The user who initiated the request (if known). Res The time taken by the axsguard Gatekeeper Web Access cache to service the request (in milliseconds). Size The size of the requested web page. Cache A special result code indicating how the request was handled by the axsguard Gatekeeper Web Access Module (see Appendix A on page 83 for the result codes). Action The action performed by the Web Access Module. GET indicates the download of a page. PUT indicates the upload of a page. CONNECT indicates a secure page was accessed (HTTPS, see section 2.5). 73

74 Web Access Logs Block Log Follow the same steps as explained in section 7.3.1, but select the desired block log date. A screen as shown below appears. The entries are explained in Table 15. Image 52: Web Access Block Log entries Table 15: Web Access > Log > Block Overview of Block Log Entries Time The time the page was blocked. Host The IP address of the blocked host. User The user who initiated the request (if known). ACL The ACL which was used to block the request. Site List The Site List which blocked the request. Action The action performed by the Web Access Module e.g. a redirect to the login page or the blocking of an unauthorized web page. Ignore Log Follow the same steps as explained in section 7.3.1, but select the desired ignore log date. The entries are identical to the ones decribed in Table 15. Image 53: Ignore Log Example 74

75 Web 7.4 Access Logs Trend Micro Detailed Web Access Log To access the Trend Micro Detailed Web Access log: 1. Log on to the axsguard Gatekeeper Administrator Tool as explained in the System Administration How To, which is accessible by clicking on the permanently available Documentation button in the Administrator Tool. 2. Navigate to Anti-Malware > Logs > TM Detailed Web. 3. Click on the desired log date to view the log entries (see below). Image 54: Trend Micro Detailed Web Access Log 75

76 Web Access Statistics and 8 Web Access Statistics and Reporting 8.1 Overview Reporting This section explains the use of the Web Access Statistics on the axsguard Gatekeeper. The statistics consist of a database from which the following reports can be extracted: Client requests. Hourly requests. Most frequently accessed websites. Blocked requests. Blocked sites. Reports are generated for a selected period. Caution The gathered content is sensitive and may be subject to privacy legislation in your country. Make sure to check the applicable legislation before disclosing or using any information included in these reports. The user names in Web Access reports can be obfuscated. Contact VASCO Support if this option is required in your country. 8.2 Accessing Statistics and generating reports Several types of reports can be generated and are explained in the following subsections. To generate a report: 1. Log on to the axsguard Gatekeeper Administrator Tool as explained in the System Administration How To, which is accessible by clicking on the permanently available Documentation button in the Administrator Tool. 2. Navigate to Statistics > Reports. A screen as show below appears. 3. Select the period for which a report should be generated. 4. Click the appropriate View link to generate the report. Image 55: Web Access Report Index 76

77 Web Access Statistics and Reporting Client Requests The client request report displays the number of web requests and the total downloaded volume (in MB) per client during a given period (see below). It is possible to display the web access details of a given client, such as the volume used for each accessed website up to the individual files and directories which were downloaded, by clicking on the client's IP address or user name. Image 56: Client Requests Hourly Requests The hourly request report displays the number of web requests over 24 hours for a given period, e.g. a week, in a graphic (see below). This report provides system administrators with an overview of traffic peaks and allows to detect any unusual or undesired web traffic. Click on any orange bar to view the details per site (see below) or per client (see above) for the given time. Image 57: Hourly Requests 77

78 Web Access Statistics and Reporting Most Accessed Websites This report provides an overview of the most frequently accessed websites for a selected period (see below). The generated download volume for each site is sorted in descending order. The total number of requests is also listed per site. The number of requests can be consulted: Per Client Per Site Click on the desired site in the list to view the number of requests per client or per site. Image 58: Most accessed Websites Blocked Websites This report provides an overview of blocked websites for a selected period. The number of requests per client and per site can be consulted by following the same procedure as described in section Image 59: Blocked Websites 78