axs GUARD Gatekeeper Firewall How To

Transcription

1 axs GUARD Gatekeeper Firewall How To

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, axs GUARD, DIGIPASS and DIGIPASS PLUS are trademarks of VASCO or its affiliated companies. 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. August VASCO Data Security. 2

3 Table of Contents Table of Contents 1 Introduction Audience and Purpose of this document About VASCO About ABLE Contact Information axs GUARD Gatekeeper Firewall Overview Essential axs GUARD Gatekeeper Firewall Terminology How are axs GUARD Gatekeeper Firewall Rights and Security Levels related? axs GUARD Gatekeeper: Firewall administration made easy axs GUARD Gatekeeper Firewall Concept and Principles Overview Stateful Packet Inspection with Connection Tracking (SPICT) Definition Connection States Example of a Related State connection: FTP axs GUARD Gatekeeper Firewall Zones Definition Firewall Zone Types axs GUARD Gatekeeper Firewall Data Paths Definition Data Paths axs GUARD Gatekeeper Security Levels axs GUARD Gatekeeper Firewall Flow Definition axs GUARD Gatekeeper Firewall Flow Scenarios axs GUARD Gatekeeper Firewall Flow for users who authenticate axs GUARD Gatekeeper Firewall Flow for users who do not authenticate axs GUARD Gatekeeper Firewall Flow for Computers and Servers (authentication is N/A) axs GUARD Gatekeeper System Level Firewall Flow (authentication is N/A) Computer Level Firewall Rights Drawbacks axs GUARD Gatekeeper Firewall Rules Overview and Definition Rule types and naming conventions...19 August VASCO Data Security. 3

4 Table of Contents Predefined and Custom Firewall Rules Advanced Firewall Rules Rule Matching Match Types Generic Matches TCP and UDP Matches Special Matches Matches for rules towards the axs GUARD Gatekeeper Matches for rules through the axs GUARD Gatekeeper Matches for DMZ filter rules Rule Target Actions (Accept, Drop and Reject) Possible Interface Combinations in Firewall Rules axs GUARD Gatekeeper Firewall Policies Overview and Definition Firewall Rule Hierarchy within a Policy Static Firewall Policies Dynamic Firewall Policies Dynamic user / group policies Dynamic computer / server policies DMZ Filter Policies Policy naming conventions Predefined System policies in the input / towards path Predefined System Policies in the forward / through Path axs GUARD Gatekeeper system-wide Firewall Checks Firewall Denial Of Service checks Firewall unclean packet checks Global Bad Packet Management Firewall logging Definition Field and Comment entries in the Firewall log Fields Comments Firewall Status Connections Filter Status Filter Input Filter Forward Filter Output...32 August VASCO Data Security. 4

5 Table of Contents 4 axs GUARD Gatekeeper Firewall Summary Overview What is a Firewall rule? What is a Firewall policy? What are axs GUARD Gatekeeper Security Levels? How are Firewall Rights (Policies) and Security Levels related? System-Wide checks Firewall Logs and Status axs GUARD Gatekeeper Firewall Step by Step Overview The Firewall Graphical User Interface axs GUARD Gatekeeper Firewall General Settings Predefined axs GUARD Gatekeeper Firewall Rules and Policies An example of using and implementing a predefined Firewall Policy (sys- ) Locating the rules of a Firewall policy (sys- ) An example of using and implementing a new custom Firewall Policy (Citrix) Recycling an existing Firewall Policy (Citrix) Changing the Firewall rule hierarchy in a Firewall policy Enable / Disable Firewall logging Adding Rules at the System Level for services on the axs GUARD Gatekeeper Adding Rules at the System Level for services in the DMZ Troubleshooting My application does not work although I have created a firewall rule Firewall log file states: Bad 1 new not syn Firewall log file states: BAD2: unclean I have several secure LANs and they cannot communicate I cannot add or modify a rule in a policy...47 August VASCO Data Security. 5

6 Table of Contents Illustration Index Illustration 1: Gatekeeper Firewall RIghts / Security Level relation...11 Illustration 2: Stateful Packet Inspection with Connection Tracking...12 Illustration 3: SPICT Connection Table...13 Illustration 4: axs GUARD Gatekeeper Secure LAN Zone / DMZ / Internet Zone...14 Illustration 5: axs GUARD Gatekeeper Data Paths - Towards, Through and Output...15 Illustration 6: axs GUARD Gatekeeper Firewall Flow...16 Illustration 7: IP Packet Header...19 Illustration 8: IPTABLES Advanced Rule Example...21 Illustration 9: axs GUARD Gatekeeper Rule Matching...21 Illustration 10: Firewall Rule Target Actions: Accept, Drop, Reject...23 Illustration 11: axs GUARD Gatekeeper Interface combinations and FW rules...24 Illustration 12: Gatekeeper Firewall Special Interface combination actions...25 Illustration 13: Importance of Firewall Rule Hierarchy in a Firewall Policy...26 Illustration 14: axs GUARD Gatekeeper Firewall Log Entry...30 Illustration 15: axs GUARD Gatekeeper Firewall Connection Tracking...32 Illustration 16: axs GUARD Gatekeeper Firewall Filter Output...32 Illustration 17: axs GUARD Gatekeeper Firewall Flow...34 Illustration 18: axs GUARD Gatekeeper Firewall GUI Concept...36 Illustration 19: Firewall > Policies > Static...36 Illustration 20: axs GUARD Gatekeeper Firewall General Settings...37 Illustration 21: axs GUARD Gatekeeper sys- Policy...37 Illustration 22: axs GUARD Gatekeeper sys- Policy Details...38 Illustration 23: axs GUARD Gatekeeper adding sys- to Group Illustration 24: axs GUARD Gatekeeper adding sys- to group Illustration 25: axs GUARD Gatekeeper adding sys- to group Illustration 26: axs GUARD Firewall Policy - Rules...39 Illustration 27: axs GUARD Gatekeeper Rule Details...40 Illustration 28: axs GUARD Gatekeeper - Create Firewall Rules - Step Illustration 29: axs GUARD Gatekeeper - Create Firewall Rules - Step Illustration 30: axs GUARD Gatekeeper - Creating a custom Firewall Policy...42 Illustration 31: Integrating a custom rule into a custom policy...42 Illustration 32: axs GUARD Gatekeeper Firewall Rule Hierarchy...43 Illustration 33: Enabling / Disabling Logging for a FW Rule...44 Illustration 34: axs GUARD Gatekeeper Firewall Troubleshooting Checklist...46 August VASCO Data Security. 6

7 1 Introduction 1.1 Audience and Purpose of this document Introduction This document is an introductory guide to the axs GUARD Gatekeeper Firewall usage and configuration. It is intended for system administrators or technical personnel with a good understanding of network security and TCP/IP. For in-depth information about the axs GUARD Gatekeeper Firewall architecture, concepts and operation, please refer to the axs GUARD Gatekeeper Advanced Firewall Concepts guide. A summary of this guide is available for more advanced users and administrators in section 4. 7

8 1.2 Introduction About VASCO VASCO is the number one supplier of strong authentication and Electronic Signature solutions and services. VASCO has established itself as the world s leading software company specialized in Internet Security, with a customer base of over 4,800 companies in more than 100 countries, including close to 750 international financial institutions. VASCO s prime markets are the financial sector, enterprise security, e-commerce and egovernment. Further, VASCO brings banking security to 50 different vertical applications such as healthcare, e-gaming, human resources, education, administration, manufacturing, legal and automotive sectors, and many more. Over 50 of VASCO s client authentication technologies, products and services are based on the unique VASCO platform: VACMAN. VASCO solutions comprise combinations of the VACMAN core authentication platform, IDENTIKEY authentication server, axs GUARD Gatekeeper authentication appliance, axs GUARD Identifier authentication appliance, DIGIPASS client Password and Electronic Signature software and DIGIPASS PLUS authentication services. For further information on these security solutions, please see About ABLE Able was integrated into the VASCO group in October Able NV, a Belgian company based in Mechelen, designs, develops and markets axs GUARD Gatekeeper. Able developed the axs GUARD Gatekeeper to counter the ever growing Internet threats with a dynamic security and communications product. axs GUARD Gatekeeper is a total (All-in-1) solution to meet all your Internet communication and security needs, and comprises hardware, software and support. Customers design their own axs GUARD Gatekeeper à la Carte, paying only for the modules they need today, making it an affordable solution to SMEs and large organizations alike. Since the introduction of the first axs GUARD Gatekeeper prototype in 1996 by Able, 97% of our customers have remained loyal axs GUARD Gatekeeper users. The long term reliability of this dynamic solution has won their trust. While axs GUARD Gatekeeper secures their Internet communications, they can focus on business. axs GUARD Gatekeeper is distributed worldwide through a network of certified distributors and dealers. 1.4 Contact Information VASCO Belgium (Europe / Middle East / Latin America) Koningin Astridlaan 164 B-1780 Wemmel phone: [email protected] Boston (North America) [email protected] 8

9 Introduction Sydney (Pacific / Japan / India) [email protected] Singapore (Asia) [email protected] Able NV Dellingstraat 28b 2800 Mechelen Belgium Tel: Fax: [email protected] 9

10 2 axs GUARD Gatekeeper Firewall 2.1 Overview GUARD Gatekeeper Firewall The axs GUARD Gatekeeper Firewall protects your network from any unauthorized access (i.e. hackers). In addition, it also prevents unauthorized data from leaving your private network (i.e. blocking outgoing network traffic generated by designated programs). In this section, some key terminology is briefly defined in order to better understand the operation and configuration of the axs GUARD Gatekeeper Firewall. The relation between the 4 axs GUARD Gatekeeper Security levels and Firewall rights is also explained and illustrated. Tip Advanced administrators and users who are familiar with network security and TCP/IP may skip to section Essential axs GUARD Gatekeeper Firewall Terminology Firewall Rule: A firewall rule is the smallest configurable element which governs the handling of network packets. It is the cornerstone of the axs GUARD Gatekeeper Firewall. Firewall Policy: A firewall policy is a set (combination) of firewall rules organized in a certain order. Firewall Policies can be assigned to axs GUARD Gatekeeper security levels (i.e. users, groups, computers or the system). axs GUARD Gatekeeper Security Level: The level to which a firewall policy can be assigned, i.e. an axs GUARD Gatekeeper user, group, computer or system. Firewall Rights: General term used to describe firewall permissions and restrictions at a given security level, i.e. the services a given user can / cannot access. axs GUARD Gatekeeper Firewall GUI: The graphical user interface used to: (1) build and configure firewall rules and policies; (2) assign firewall policies to an adequate security level; (3) consult firewall logs and check the firewall status. How are axs GUARD Gatekeeper Firewall Rights and Security Levels related? Caution Since system-level firewall rights apply to all users, the strictest security should be enforced! If not, unauthenticated users could potentially have more access than authenticated users (see section 3.6). A firewall rule is added to a firewall policy, which in its turn - is assigned to one of the 4 axs GUARD Gatekeeper security levels, i.e. a user, a group, a computer or the system. System-level firewall rights (static policies, see section 3.8.3) apply to all users who are physically connected to the network, while computer, group and user-level firewall rights (dynamic policies, see section 3.8.4) only apply to a given computer, group or user. Illustration 1 shows the relation between firewall rules, firewall policies and the respective axs GUARD Gatekeeper security levels. 10

11 GUARD Gatekeeper Firewall Illustration 1: Gatekeeper Firewall RIghts / Security Level relation 2.4 axs GUARD Gatekeeper: Firewall administration made easy For convenience, the axs GUARD Gatekeeper Firewall comes with a set of (factory) predefined firewall rules, which can be used out of the box. It is also possible to create new (customized) rules, using the axs GUARD Gatekeeper Firewall GUI. Both rule types are explained in section 3.7. Firewall rules and policies can be recycled. This means that rules and / or policies are not necessarily active when they are created. It is possible to create rules and policies for future use. Rules and policies which are no longer applicable, do not have to be removed. They can be saved and enabled or disabled at will. The advantage of using firewall policies: A vast number of rules can be easily and centrally managed with policies. A firewall policy can easily be linked to a large number of users (by using a firewall group policy). A Firewall Policy can be recycled (can be saved and activated or disactivated anytime). Example: The advantage of firewall policies can be demontrated envisioning the following scenario: An office of 500 users divided into 6 groups needs access to the axs GUARD Gatekeeper mail system. This implies the creation of 1 firewall rule per service, i.e. POP, IMAP, SMTP, LDAP (for the addressbook), giving a total of 4 rules. Without Firewall Policies: adding 4 rules to 500 users means 2000 configuration actions. Firewall Policies at the user level: adding 4 rules to 1 policy and subsequently assigning the policy to 500 users means 505 configuration actions. Firewall Policies at the group level: adding 4 rules to 1 policy and subsequently assigning the policy to 6 goups means 11 configuration actions. 11

12 GUARD Gatekeeper Firewall Concept and Principles 3 axs GUARD Gatekeeper Firewall Concept and Principles 3.1 Overview This section covers the main principles and concepts of the axs GUARD Gatekeeper Firewall in detail. One of the main characteristics of the axs GUARD Gatekeeper Firewall, Stateful Packet Inspection with Connection Tracking or SPICT, is explained first. The firewall zones, data paths, security levels and the resulting axs GUARD Gatekeeper firewall flow are explained immediately afterwards. The general use, properties and configuration of axs GUARD Gatekeeper Firewall rules and policies are covered in sections 3.7 and 3.8. Tip Advanced administrators and users who are familiar with network security and TCP/IP may skip to section Stateful Packet Inspection with Connection Tracking (SPICT) Definition An important principle behind the axs GUARD Gatekeeper Firewall is the use of connection tracking. Connection tracking refers to the ability to maintain connection information, such as the source and destination IP address, port number pairs (also known as socket pairs), protocol types, connection states, timeouts, etc. in memory tables. This property is known as stateful. Stateful firewalling (the connection states are explained in section 3.2.2) is inherently more secure than its "stateless" counterpart, simple packet filtering. Connection tracking also considerably accelerates firewall checks (up to 90%), since packets belonging to a same established or assured connection do not require additional firewall checking (see illustrations 2 and 3). In illustration 2, we assume that the described traffic is allowed by the axs GUARD Gatekeeper Firewall. Illustration 2: Stateful Packet Inspection with Connection Tracking 12

13 GUARD Gatekeeper Firewall Concept and Principles Stream / Connection Table: Illustration 3: SPICT Connection Table Five different connection states exist: New, Established, Related, Invalid and Assured. An example of an assured connection is shown in section Connection States New: The first packet of a specific connection is given this state. Established: After receiving the first reply on a New packet, the connection state changes to Established. Related: A connection is Related when it is associated with an already Established connection; Invalid: This state is assigned to a packet which cannot be identified or which doesn't have a state; Assured: a connection becomes Assured after it has been Established for a certain time Example of a Related State connection: FTP The related state is used to handle special protocols such as IRC (chat), FTP (File Transfer Protocol), ICQ (instant messaging), etc. The FTP connection uses two different channels to exchange information: one to control the connection and one to send data. When the control channel is successfully established, a second channel for the data is negotiated in the payload section (data section) of the first connection. The firewall has no knowledge of this, so the second connection is denied. This problem is resolved by adding a module to the connection tracking system, which examines the payload of the first connection. Upon detection of the negotiation, a second connection is triggered based on the first one and given the related state. This second connection is then used to transfer the data. The axs GUARD Gatekeeper uses helpers or additional code for the following protocols: PPTP (Point to Point Tunneling Protocol) FTP (File Transfer Protocol.) VoIP (Voice over IP) IRC (Internet Relay Chat) 13

14 GUARD Gatekeeper Firewall Concept and Principles 3.3 axs GUARD Gatekeeper Firewall Zones Definition A Network Zone is a physical network (subnetwork) to which the axs GUARD Gatekeeper can be connected. Three network zones can be distinguished in relation to the axs GUARD Gatekeeper (see illustration 4) Firewall Zone Types Secure Zone (sec): The secure local network (LAN), possibly extended with remote connections (RAS, VPN) Internet Zone (int): The World Wide Web Demilitarized Zone (dmz): Network segment which is accessible from the Internet and strictly separated from the Secure Zone (secure LAN), i.e. a webserver hosting a corporate website Illustration 4: axs GUARD Gatekeeper Secure LAN Zone / DMZ / Internet Zone Note It is possible to have multiple zones of the same type, depending on the number of network interfaces. 14

15 GUARD Gatekeeper Firewall Concept and Principles 3.4 axs GUARD Gatekeeper Firewall Data Paths Definition The direction in which data packets travel in relation to the axs GUARD Gatekeeper. Three main paths can be distinguished: the towards, through and output path (see illustration 5) Data Paths Towards Path:This path designates data packets destined for a process running on the axs GUARD Gatekeeper. Through Path: This path designates data packets destined for a process running elsewhere, travelling through the axs GUARD Gatekeeper from one network zone to another, i.e. a DMZ. Output Path: This path designates data packets generated from and sent out by a process running on the axs GUARD Gatekeeper. Illustration 5: axs GUARD Gatekeeper Data Paths - Towards, Through and Output 3.5 axs GUARD Gatekeeper Security Levels The axs GUARD Gatekeeper enforces network security on 4 levels: The system level: axs GUARD Gatekeeper system-wide security, applicable to all users who are physically connected to the network. The computer level: axs GUARD Gatekeeper security rights associated to a workstation or a server. 15

16 GUARD Gatekeeper Firewall Concept and Principles The group level: security rights associated to a group of axs GUARD Gatekeeper users. The user level: security rights associated to a specific axs GUARD Gatekeeper user. Detailed information about the security levels is available in the axs GUARD Gatekeeper Getting Started and the axs GUARD Gatekeeper System Administration guides. 3.6 axs GUARD Gatekeeper Firewall Flow Definition Caution Since system-level firewall rights apply to all users and computers, the strictest security should be enforced! The different firewall security levels and policies which are encountered by a user who is connected to the network, whether authenticated or not, is called the axs GUARD Gatekeeper Firewall flow. Firewall policies can be implemented at different axs GUARD Gatekeeper security levels (see section 3.5). A firewall flow exists for each scenario as described below axs GUARD Gatekeeper Firewall Flow Scenarios This section describes the possible axs GUARD Gatekeeper firewall flows for hosts (users) which are physically connected to the network. A diagram of this flow is provided below (illustration 6). Illustration 6: axs GUARD Gatekeeper Firewall Flow 16

17 GUARD Gatekeeper Firewall Concept and Principles axs GUARD Gatekeeper Firewall Flow for users who authenticate A user with an axs GUARD Gatekeeper account who authenticates is subject to the following firewall flow (see illustration 6). Depending on the user profile, either A, B or C applies always followed by the computer and axs GUARD Gatekeeper system policies: (A) Use group firewall policies: The firewall rights are based solely on the user's axs GUARD Gatekeeper group membership OR. (B) Add to group firewall policies: The user's Firewall rights are applied first, if any. Then the firewall rights based on the user's axs GUARD Gatekeeper group membership (see A). Additionally, specific firewall rights are assigned to the user. These specific rights can either be more restrictive or more permissive than the user's group firewall policies OR. (C) Overrule group firewall policies: The user's axs GUARD Gatekeeper group firewall policies are overruled and do not apply. Only the user's specific Firewall rights apply AND. Computer policies: The user's axs GUARD Gatekeeper computer firewall policies applies (if available). The computer firewall policies are based on the computer's IP address AND. axs GUARD Gatekeeper system policies: The axs GUARD Gatekeeper system-wide policy applies.traffic which is not allowed at the system level is blocked. axs GUARD Gatekeeper Firewall Flow for users who do not authenticate A user with an axs GUARD Gatekeeper account who does not authenticate is subject to the following firewall flow (see illustration 6): Computer policies: The axs GUARD Gatekeeper computer firewall policies apply (if available). The computer firewall policies are based on the computer's IP address. No information about the connected user is available, since he/she is not authenticated! axs GUARD Gatekeeper system policies: The axs GUARD Gatekeeper system-wide policy applies.traffic which is not allowed at the system level is blocked. Note VASCO recommends and endorses DIGIPASS user authentication, as this is the most secure option. Computer policies should only be used for servers to which system administrators have access (see section 3.6.3) axs GUARD Gatekeeper Firewall Flow for Computers and Servers (authentication is N/A) A computer or server in the network is subject to the following firewall flow (see illustration 6): Computer policies: The user's axs GUARD Gatekeeper computer firewall policies apply (if available). The computer firewall policies are based on the computer's IP address. axs GUARD Gatekeeper system policies: The axs GUARD Gatekeeper system-wide policy applies.traffic which is not allowed at the system level is blocked. 17

18 GUARD Gatekeeper Firewall Concept and Principles Note VASCO recommends and endorses DIGIPASS user authentication, as this is the most secure option. Computer policies should only be used for servers to which system administrators have access (see section 3.6.3) axs GUARD Gatekeeper System Level Firewall Flow (authentication is N/A) This flow is applicable when: A user does not authenticate. The user's computer does not exist in the axs GUARD Gatekeeper Computer list Only system-wide firewall policies apply. Non-specified traffic is blocked. Maximum security and restrictions should be enforced at this level! Permissions should be granted at the group / user level. Example: When 2 secure LANs are present in the network, they are shielded from each other by default, which means traffic between those networks is not allowed. In order to allow traffic between these networks, the necessary rules and policies should be added on the axs GUARD Gatekeeper Computer Level Firewall Rights Drawbacks Computer firewall rights should only be assigned to servers (with a static IP address) which need specific access, for instance access to Microsoft updates. In all other instances, the use of user and group firewall rights are advised. Following is a list of drawbacks which arise from assigning firewall rights at the computer level: The authentication process (identification of the user) is bypassed, which is insecure. Physical access to a computer is sufficient to possibly obtain more firewall rights than would normally be allowed with user authentication and could lead to possible abuse, i.e. misuse of the network's public IP address or access to unauthorized resources. A computer list may lead to errors and is difficult to maintain (DHCP), while a user list is not (especially for large networks). It is not possible to assign different firewall rights to multiple users who use the same computer, i.e. a reception desk. This is only possible with user authentication. Troubleshooting is more difficult and cumbersome, since a computer list (inventory) in which each user is linked to a computer has to be maintained separately. A user name is linked to an IP address (after authentication) and therefore easier to find and troubleshoot. Tip It is imperative to enforce user authentication wherever possible. A Single Sign-On Tool is available for the axs GUARD Gatekeeper. This tool allows users to automatically sign-on with the axs GUARD Gatekeeper after logging on to their client PC. See the axs GUARD Single Sign-On Utility (SSO) guide for details. 18

19 GUARD Gatekeeper Firewall Concept and Principles 3.7 axs GUARD Gatekeeper Firewall Rules Overview and Definition Caution A firewall rule does not enter into effect until it is enabled, added to a firewall policy and properly assigned. Before a certain network packet may continue its journey, it is first examined by (a) firewall rule(s). A firewall rule(s) decide(s) what should happen to a certain network packet. The axs GUARD Gatekeeper Firewall classifies packets according to properties found in the (IP) packet header fields (see illustration 7). If a packet matches a rule, it may be dropped, rejected or accepted. If it doesn't match the rule, it is checked by a subsequent rule, if present. A packet for which no rule is defined is dropped by default at the system level (see section 3.6). The target actions drop, accept and reject are explained separately in section There are several classes of matches: generic matches which apply to all protocols, protocol-specific matches (i.e. for TCP, UDP and ICMP), and special matches (see section 3.7.6). Certain firewall configuration elements are path-specific (see sections 3.4 and 3.7.2). Firewall rules can be recycled, which means they can be saved and implemented at any given time. An existing firewall rule is not necessarily active. Illustration 7: IP Packet Header Rule types and naming conventions Three different types of Firewall rules exist, based on the zones (see section 3.3): Rules towards the axs GUARD Gatekeeper, through the axs GUARD Gatekeeper and DMZ filter rules (see section 3.4). The DMZ filter rules can only be used in the FORWARD path and specifically regulate traffic from the Internet to the DMZ. For convenience, a set of predefined firewall rules is readily available on the axs GUARD Gatekeeper. To view the list of all available rules for each path, navigate to Firewall > Rules > Towards / Through / DMZ Filter and select all in the items per page list. 19

20 GUARD Gatekeeper Firewall Concept and Principles Note The amount of predefined rules depends on the number of purchased axs GUARD Gatekeeper features. The rule naming convention is based on the different classes of filter rules, with the following prefixes: sec- Rules for packets sent to a secure axs GUARD Gatekeeper interface int- Rules for packets sent to an axs GUARD Gatekeeper Internet interface dmz- Rules for packets sent to an axs GUARD Gatekeeper DMZ interface all-assistance Rules used for remote assistance from supplier fwd- Rules for packets travelling through the axs GUARD Gatekeeper dmzf- DMZ filtering rules pr- & pf- Automatically generated port redirection and port forwarding rules in the filter table. See the separate guide, axs GUARD Gatekeeper Advanced Firewall Concepts, for more information about automatically added port redirection and port forwarding rules. Predefined and Custom Firewall Rules The axs GUARD Gatekeeper comes with a set of predefined rules which can be used out of the box. When installing the axs GUARD Gatekeeper for the first time, some of these rules are already activated at the system level for convenience, i.e. rules allowing ICMP traffic and VASCO remote support. A detailed list of active factory default rules is available in section Most services can be configured using the supplied predefined firewall rules. In some instances, administrators may prefer to create and implement custom rules. Tip When creating custom rules, it is recommended to use the naming conventions mentioned in section This facilitates troubleshooting and VASCO customer support. An example of a custom firewall rule created with the axs GUARD Firewall GUI is provided in section Advanced Firewall Rules Caution The use of advanced Firewall rules may lead to insecure configurations and is strongly discouraged! VASCO cannot be held responsible for security leaks incurred by improper use of such rules. Advanced firewall rules always have priority over any other firewall rules. Misconfiguration and misuse might lead to insecure configurations (leaks), accidental deactivation of axs GUARD Gatekeeper remote support and automatic upgrades, amongst others. For detailed information about firewall rule hierarchy, see section

21 GUARD Gatekeeper Firewall Concept and Principles The Firewall engine of the axs GUARD Gatekeeper is based on IPTABLES. In order to create advanced firewall rules, refer to the adequate IPTABLES man pages. Illustration 8 shows an example of such a rule. Illustration 8: IPTABLES Advanced Rule Example More information about advanced firewall rules is also available in the axs GUARD Advanced Firewall Concepts guide Rule Matching Each rule contains specifications of the packets to be matched. It also contains a target. As a packet traverses a firewall policy, each rule - in its turn - examines it. If a packet does not match a rule, the packet is checked by the next rule in the policy, etc. If a packet matches a rule in the policy, the appropriate action is taken, which, for instance, may result in the packet being (dis)allowed to continue its way. In a rule, a packet is either accepted, dropped or rejected (see section 3.7.7) Match Types Several types of matching exist: generic matches, TCP and UDP matches, special matches and matches based on the data path (see illustration 9). The data paths are explained in section 3.4. Illustration 9: axs GUARD Gatekeeper Rule Matching 21

22 GUARD Gatekeeper Firewall Concept and Principles Generic Matches The following matches can be applied to all protocols and include: The protocol: only matches when the packet uses the protocol specified in the rule. The source: only matches when the source of the packet is specified in the rule. A source can be specified as an IP address or as a subnet, for instance: /32 or / Destination: only matches when the destination of the packet is specified in the rule. A destination can be defined as a single IP address, or as a subnet TCP and UDP Matches These matches only apply when the TCP or UDP protocol is used and include: The source port: only matches when the packet uses the source port specified in the rule. A range of ports can be specified using the x:x format, for instance: 1000:1024. The destination port: only matches when the packet uses the destination port specified in the rule. A range of ports can be specified using the x:x format, for instance: 1000: Special Matches There are many different types of special matches. An important special match is the limit match, which is explained in the axs GUARD Gatekeeper Advanced Firewall Concepts guide Matches for rules towards the axs GUARD Gatekeeper Interface: only matches if the interface type in the data packet towards the axs GUARD Gatekeeper is specified in the rule, i.e. Secure, DMZ or Internet Matches for rules through the axs GUARD Gatekeeper in-interface: only matches if the interface by which the data packet is received is specified in the rule. out-interface: only matches if the interface from which the data packet is sent is specified in the rule Note Please refer to section and illustration 12 for allowed interface combinations Matches for DMZ filter rules These rules regulate traffic from the Internet to the DMZ, so the in- and out-interfaces are already defined and there are no other special matching criteria. 22

23 3.7.7 GUARD Gatekeeper Firewall Concept and Principles Rule Target Actions (Accept, Drop and Reject) The target action specifies the action to perform on a matched packet (see illustration 10). Possible actions are: ACCEPT: The packet is accepted and may continue its route. Accepted network traffic is not logged by default. DROP: Prohibits a packet from passing. Sends no response to the sending host. The packet is destroyed. Logging is enabled by default. REJECT: Prohibits a packet from passing, but also notifies the sending host. Logging is enabled by default. By rejecting rather than dropping unwanted packets, TCP aborts the connection and the sending application immediately gets a notification that the connection has failed, which is a security risk. The less connection information is provided to potential attackers, the more secure. Use security by obscurity. Use this option for troubleshooting and testing only. Note As accepted traffic is not logged by default, the log rule target option should be checked when troubleshooting (see section 5). Illustration 10: Firewall Rule Target Actions: Accept, Drop, Reject 23

24 3.7.8 GUARD Gatekeeper Firewall Concept and Principles Possible Interface Combinations in Firewall Rules Caution INT to LAN, INT to INT and DMZ to LAN rules compromize the safety of your network and are not allowed! Some restrictions do apply when creating firewall rules. The axs GUARD Gatekeeper Firewall prohibits certain network interface combinations in rules, because they are inherently dangerous and could seriously compromize network security and integrity (see illustration 11). If an attempt is made to configure a dangerous / prohibited interface combination in a firewall rule, the axs GUARD Gatekeeper generates an error message. The rule is NOT created. When the interface combination cannot be validated during the configuration, for instance when no incoming device is selected, packets are still dropped at runtime for invalid combinations (see illustration 12). Illustration 11 shows the possible interface combinations which can be used in firewall rules, illustration 12 shows the special actions which are triggered depending on the used interface combination. Illustration 11: axs GUARD Gatekeeper Interface combinations and FW rules 24

25 GUARD Gatekeeper Firewall Concept and Principles Illustration 12: Gatekeeper Firewall Special Interface combination actions Note For traffic from the Internet to the DMZ, use DMZ filter rules only, see section axs GUARD Gatekeeper Firewall Policies Overview and Definition A firewall policy is a set (combination) of firewall rules, which can be implemented at the different axs GUARD Gatekeeper security levels (see section 2.2). Firewall policies can be either static or dynamic (see sections and 3.8.4). A special type of firewall policy, the DMZ filter policy, is explained in section Like rules, policies can be recycled. This means they can be saved and activated or deactivated anytime. Note Since a rule always needs to be added to a policy, a Firewall Policy can also consist of a single rule Firewall Rule Hierarchy within a Policy Caution Within a Firewall Policy, the first rule which matches a packet is always applied! The order in which Firewall Rules are listed in a policy is referred to as the rule hierarchy.the first rule always has priority over the second, the third, etc. (see illustration 13). The second rule always has priority over the third, the fourth, etc. For this reason, the order (hierarchy) of firewall rules within a policy can be altered. Advanced firewall rules always have absolute priority over any other rules (see section 3.7.4) and can lead to an insecure network environment if used improperly! 25

26 GUARD Gatekeeper Firewall Concept and Principles Note The rule hierarchy (order) cannot be changed in factory axs GUARD Gatekeeper Firewall Policies. Illustration 13: Importance of Firewall Rule Hierarchy in a Firewall Policy If the intention is to drop traffic B, Rule 5 should be placed before Rule 2. Another option is to remove Rule 2 from the policy Static Firewall Policies Static firewall policies are deployed as soon as the axs GUARD Gatekeeper firewall is started. They are linked to the system level (see section 3.5) and are permanently active. For convenience, factory default static policies exist on the axs GUARD Gatekeeper, for example remote support and ICMP traffic (see section ). Static Firewall Policy Properties: Authentication independent. Valid for all users and computers physically connected to the network. Rules added to Static Policies are immediately active. Dynamic Firewall Policies Dynamic policies are linked to either a user, a group or a computer. Two types of dynamic firewall policies exist as explained below. 26

27 GUARD Gatekeeper Firewall Concept and Principles Dynamic user / group policies The policy is only activated when a user / group is successfully authenticated. The policy only applies to the authenticated user. Note When a rule is added to a dynamic user policy while the user is authenticated, the rule is immediately activated. The user is not required to sign / log off Dynamic computer / server policies Caution Computer policies should only be used for servers with restricted administrator access. For regular computers, user authentication should be enforced (see section 3.6.3) The policy is permanently active, user authentication is not applicable. The policy applies to the listed computer, based on the IP address. DMZ Filter Policies The default DMZ filter policy intercepts and drops all packets arriving from an Internet interface and destined for the DMZ interface. By default, it consists of a single through rule (DMZ filter) to drop all packets and can be customized by adding links to other DMZ filter rules, prior to the drop rule in the policy. This feature allows complete control over packets arriving for the DMZ. DMZ filter rules are managed separately Policy naming conventions Prefixes for policies are as follows: stat- Static Policy names stat-xxx This policy groups all rules related to the XXX service. For example, stat-int contains all services available on the Internet interface, initiated during firewall start-up. Predefined System policies in the input / towards path Caution The predefined Dynamic policies no-restrictions, int-no-restrictions and dmz-no-restrictions should ONLY be used for troubleshooting, NEVER in a live / production environment. These policies eliminate Firewall Security! The policies below (and the rules they contain) are active by default. Predefined (factory) policies cannot be modified. 27

28 GUARD Gatekeeper Firewall Concept and Principles stat-portredirect: This policy cannot be modified and contains automatically added port redirection NAT rules. See the separate guide, axs GUARD Gatekeeper Advanced Firewall Concepts, for more information about automatically added port redirection rules. stat-z-fix: This policy cannot be modified and contains the following rules: all-assistance1 to 5 These rules enable remote assistance from the supplier, accepting packets received on an axs GUARD Gatekeeper Internet interface using ports 22 (SSH), 3128 (axs GUARD Gatekeeper proxy) or 82 (axs GUARD Gatekeeper administrator tool). sec-tool 1 and 2 These rules allow the use of the axs GUARD Gatekeeper administrator tool from within the secure LAN and only accepts packets for port 82 or 83 on a secure axs GUARD Gatekeeper interface. sec-ssh This rule allows the use of the Secure Shell (SSH) from within the secure LAN and only accepts packets for port 22 (SSH) on a secure axs GUARD Gatekeeper interface. stat-int: This policy enables services which are permanently available on an axs GUARD Gatekeeper Internet interface and adds the following rules by default: int-smtp This rule allows the axs GUARD Gatekeeper mail system to function on the Internet, only accepting TCP packets which use port 25 (SMTP) and are received by an axs GUARD Gatekeeper Internet interface; int-ident This rule enables the Identification Protocol on an axs GUARD Gatekeeper Internet interface. The Identification Protocol provides the possibility to determine the identity of a user of a particular TCP connection. Provided with a TCP port number pair, it returns a character string identifying the owner of that connection on the server's system. The rule only accepts packets for TCP port 113 on an axs GUARD Gatekeeper Internet interface. int-icmp This rule allows ICMP packets to enter the axs GUARD Gatekeeper system on an Internet interface, making it possible to use the ping or traceroute command from the Internet towards the axs GUARD Gatekeeper. This can be useful for troubleshooting purposes. The rule only accepts packets which use the ICMP protocol and are received by an axs GUARD Gatekeeper Internet interface. stat-sec: This policy enables services which are permanently available on a secure axs GUARD Gatekeeper interface and includes the following rules by default: sec-ntp Enables automatic updating of the axs GUARD Gatekeeper clock from the secure LAN. Only accepts packets which use TCP and UDP port 123 (NTP) and are received by a secure interface on the axs GUARD Gatekeeper. sec-dns Allows the axs GUARD Gatekeeper DNS system to work on the secure LAN. Only accepts packets which use UDP port 53 (DNS) and are received by an axs GUARD Gatekeeper secure interface. sec-proxy Allows the axs GUARD Gatekeeper proxy system and intranet to work on the secure LAN side. Only accepts packets which use TCP port 3128 (proxy server) and are received by a secure interface on the axs GUARD Gatekeeper. This rule also allows ICMP packets coming from a secure LAN interface to enter the axs GUARD Gatekeeper. (i.e. ping or traceroute) 28

29 GUARD Gatekeeper Firewall Concept and Principles sec-icmp Allows ICMP packets from secure interfaces to be received by the axs GUARD Gatekeeper. (i.e. ping, traceroute) sec-dhcp Allows the axs GUARD Gatekeeper to distribute IP addresses to hosts in the secure LAN. Only accepts packets which use TCP port 67 (DHCP) and are received by a secure interface on the axs GUARD Gatekeeper. sec-auth Allows authentication with the axs GUARD Gatekeeper from hosts in the secure LAN stat-dmz: This policy enables services which are permanently available on an axs GUARD Gatekeeper DMZ interface, and includes the following rules by default: dmz-ident Allows the Identification Protocol to work on an axs GUARD Gatekeeper DMZ interface. Only accepts packets which use TCP port 113 (ident). dmz-icmp Allows ICMP packets to enter the axs GUARD Gatekeeper from the DMZ. (i.e. ping or traceroute) Only accepts packets which use the ICMP protocol and are received on an axs GUARD Gatekeeper DMZ interface. dmz-smtp Allows the transmission of coming from the DMZ zone. Only accepts packets which use TCP port 25 (SMTP) and are received by an axs GUARD Gatekeeper DMZ interface. Predefined System Policies in the forward / through Path stat-portforward: This policy cannot be modified and contains automatically added NAT rules. See the separate guide, axs GUARD Gatekeeper Advanced Firewall Concepts for more information about automatically added port forwarding rules. stat-dmzfilter: This policy contains all DMZ filtering rules. The chain has only one rule by default, dmzf_drop_all, which drops all data packets. Rules to allow specific network traffic from the Internet to the DMZ should be added to the policy before the default dmzf_drop_all rule.tip Note Rules cannot be added to predefined system policies. Exceptions are described below. Exceptions: Rules can be added to the stat-int, stat-sec, stat-dmz and stat-dmz-filter policies. New rules for these policies should include the same input interface. For rules through the axs GUARD Gatekeeper, a new static policy has to be created, using the applicable fwd rules. Note Adding rules to these predefined system policies facilitates customer support and troubleshooting. 29

30 GUARD Gatekeeper Firewall Concept and Principles 3.9 axs GUARD Gatekeeper system-wide Firewall Checks Firewall Denial Of Service checks A Denial-of-service attack (DoS attack) or a distributed denial-of-service attack (DDoS attack) is an attempt to make a computer resource unavailable to its intended users. Although the means to, motives for, and targets of a DoS attack may vary, it generally consists of the concerted, malevolent efforts of a person(s) or to prevent an internet site or service from functioning, temporarily or indefinitely. When the option is enabled, the axs GUARD Gatekeeper Firewall takes action when such attacks occur. This option is highly recommended when running web servers or any other kind of service which is publically available Firewall unclean packet checks A packet containing a bad checksum or other invalid values in one of its fields is unclean. The contents of an IP packet are shown in illustration 7. Hackers sometimes transform packets to gain unauthorized access or to trigger certain unwanted network communication behavior. Packets can also sustain damage when a hardware failure occurs along its route. When the option is enabled, the axs GUARD Gatekeeper Firewall prevents such packets from entering your network. In this case, the comment Bad 2 unclean appears in the Firewall logs (see section ) Global Bad Packet Management The axs GUARD Gatekeeper firewall includes special checks, which detect and manage bad packets at a global level, for instance packets of a TCP connection that was not opened using the 3-way handshake or packets that seem malformed or unusual, i.e. containing bad headers or checksums. For a full explanation of the 3-way handshake, please consult the axs GUARD Gatekeeper Basic Network Concepts guide. The axs GUARD Gatekeeper prevents asymmetric routing. (see the axs GUARD Gatekeeper Advanced Firewall Concepts guide for more information about asymmetric routing). In this case, the comment Bad 1 new not sync appears in the Firewall logs (see section ) Firewall logging Definition The firewall log shows packets which are dropped or rejected. To protect the axs GUARD Gatekeeper from Denial Of Service attacks (explained in the axs GUARD Advanced Firewall Concepts guide), a limit for the number of logs to be recorded is set, meaning not every single dropped or rejected packet is logged. A typical log entry is shown below: Illustration 14: axs GUARD Gatekeeper Firewall Log Entry 30

31 GUARD Gatekeeper Firewall Concept and Principles Note As accepted traffic is not logged by default, the log rule target option should be checked when troubleshooting (see section 5) Field and Comment entries in the Firewall log Fields TIME The time when the logged packet was dropped or rejected. IN AND OUT The interfaces on which the dropped or rejected packet was received and the interface on which the packet should have left the axs GUARD Gatekeeper. PROTO The protocol used in the dropped or rejected packet. LEN The size of the dropped or rejected packet. SIP AND DIP The source and destination IP address of the dropped or rejected packet. SPT AND DPT The source and destination port used in the dropped or rejected packet. FLAGS The enabled flags of the dropped or rejected packet. More information about TCP and IP flags is available in the separate axs GUARD Gatekeeper Basic Networking Concepts guide. COMMENT This field provides more information about the action performed on a packet. Comments INPUT DROP This message indicates that a packet was dropped in the INPUT chain of the firewall. INPUT REJECT This message indicates that a packet was dropped in the INPUT chain of the firewall and a notification was sent to the source of the packet. FORWARD DROP This message indicates that a packet was dropped in the FORWARD chain of the firewall. FORWARD REJECT This message indicates that a packet was dropped in the FORWARD chain of the firewall and a notification was sent to the source of the packet. BAD1: New not syn This messages indicates that a packet matched a rule in the _BAD_PKTS chain of the firewall, which checks for TCP packets with the NEW state and in which the SYN flag is not set. This match indicates a bad TCP connection, so the packet is dropped. BAD2: Unclean This message indicates that a packet matched a rule in the _BAD_PKTS chain of the firewall, which checks for unclean packets that seem malformed or unusual. (i.e. bad headers) Also see section Firewall Status Connections Navigate to Firewall > Status > Connections. This shows the tracking of all connections to and from the axs GUARD Gatekeeper (see section 3.2). 31

32 GUARD Gatekeeper Firewall Concept and Principles Illustration 15: axs GUARD Gatekeeper Firewall Connection Tracking Illustration 15 shows a connection from a host on the Internet making a connection to the administrator tool of an axs GUARD Gatekeeper on the Internet (port 82). The connection states are explained in section Filter Status The filter status shows a live flow chart of the applicable firewall checks for a certain path (input, forward and output). The filter status is a live view of the axs GUARD Gatekeeper firewall flow as explained in section Filter Input Shows the filter status for the input (Packets entering the axs GUARD Gatekeeper) Filter Forward Shows the filter status for packets which are forwarded from one network zone to another Filter Output Shows the filter status for packets leaving the axs GUARD Gatekeeper. Illustration 16: axs GUARD Gatekeeper Firewall Filter Output 32

33 GUARD Gatekeeper Firewall Summary 4 axs GUARD Gatekeeper Firewall Summary 4.1 Overview Note This firewall summary is intended for advanced administrators and users who are familiar with network security and TCP/IP. For detailed information, please read sections 2 and 3. The axs GUARD Gatekeeper Firewall protects your network from any unauthorized access (i.e. hackers). In addition, it also prevents unauthorized data from leaving your private network (i.e. blocking outgoing network traffic generated by designated programs). 4.2 What is a Firewall rule? Caution The use of advanced Firewall rules may lead to insecure configurations and is strongly discouraged! VASCO cannot be held responsible for security leaks incurred by improper use of such rules. A firewall rule is the smallest configuration element which governs the handling of network packets. It is the cornerstone of the axs GUARD Gatekeeper Firewall. If a packet matches a rule, it may be dropped, rejected or accepted. axs GUARD Gatekeeper Firewall rules can be recycled (saved, activated or deactivated at will). Network interface combination restrictions apply when creating rules (see section 3.7.8), because they are inherently dangerous. Several rule types exist: 4.3 Predefined (Factory) rules: Readily available on the axs GUARD Gatekeeper. Can be immediately integrated in Firewall Policies. Custom rules: Rules which can be created using the axs GUARD Gatekeeper Firewall GUI. Advanced rules: Rules created based on IPTABLES syntax. CAUTION IS ADVISED! (see section 3.7.4). Advanced rules ALWAYS have priority over any other rules. What is a Firewall policy? A firewall policy consists of a set (combination) of firewall rules or a single firewall rule, which can be implemented on different axs GUARD Gatekeeper security levels: the user, the group, the computer or the system level. Firewall policies can be static or dynamic. A dynamic policy is linked to a user, a group or a host. A static policy is linked to the system. A special type of firewall policy exists, the DMZ filter policy (see section 3.8.5). Like rules, policies can be recycled. The rule hierarchy in a policy is crucial (see section 3.8.2) Static Policies: Valid for all connected users / hosts, authentication idependent, added rules are immediately active. Dynamic Policies: Firewall rights are applied after authentication for users / groups. For computers, the rights are permanently active and authentication is not applicable. (Computer level policies are only advised for servers with a static IP address, see section 3.6.3) 33

34 GUARD Gatekeeper Firewall Summary Note It is advised to respect the policy naming conventions as set forth in section What are axs GUARD Gatekeeper Security Levels? The axs GUARD Gatekeeper enforces network security on 4 levels: 4.5 The system level (1): axs GUARD Gatekeeper system-wide security, applicable to all users who are physically connected to the network. The computer level (2): axs GUARD Gatekeeper security rights associated to a workstation or a server (only recommended for servers, see section 3.6.3). The group level (3): security rights associated to a group of axs GUARD Gatekeeper users. The user level (4): security rights associated to a specific axs GUARD Gatekeeper user. How are Firewall Rights (Policies) and Security Levels related? A firewall rule is added to a policy, which is assigned to a security level. For details see section 3.6. Since system-level policies apply to all physically connected hosts, the strictest security should be enforced! Illustration 17: axs GUARD Gatekeeper Firewall Flow 34

35 4.6 GUARD Gatekeeper Firewall Summary System-Wide checks The following system-wide checks are available (see section 3.9): 4.7 Denial of Service checks (DoS). Unclean packets checks. Global Bad Package Management. Firewall Logs and Status See sections 3.10 and

36 GUARD Gatekeeper Firewall Step by Step 5 axs GUARD Gatekeeper Firewall Step by Step 5.1 Overview This section provides step by step information about the axs GUARD Gatekeeper Firewall feature configuration, using and creating axs GUARD Gatekeeper Firewall rules and policies. 5.2 The Firewall Graphical User Interface Navigate to Firewall > Policies > General. This menu is used to set the axs GUARD Firewall configuration options. Illustration 18: axs GUARD Gatekeeper Firewall GUI Concept Note Depending on the administrator level, additional configuration options will appear (see the axs GUARD Gatekeeper Getting Started guide). Clicking on an item in the firewall menu displays the according configuration screen, as shown below, i.e. Firewall > Policies > Static. Illustration 19: Firewall > Policies > Static 36

37 GUARD 5.3 Gatekeeper Firewall Step by Step axs GUARD Gatekeeper Firewall General Settings To configure the axs GUARD Gatekeeper Firewall general settings, navigate to Firewall > General. Illustration 20: axs GUARD Gatekeeper Firewall General Settings Note Depending on the administrator level, additional configuration options will appear (see the axs GUARD Gatekeeper Getting Started guide). 5.4 Enable Firewall Denial of Service Checks: See section When enabled, the axs GUARD Gatekeeper Firewall blocks DoS attacks. Enable Firewall unclean packet checks: See section When enabled, the axs GUARD Gatekeeper Firewall blocks packets containing a bad checksum or other invalid packet header values. Predefined axs GUARD Gatekeeper Firewall Rules and Policies As mentioned in section , ready to use firewall policies and rules are supplied, some of which are already enabled. To view all rules, navigate to Firewall > Rules > Towards / Through / DMZ Filter. Select all from the items per page drop-down list. Click on a rule to view its details. 5.5 An example of using and implementing a predefined Firewall Policy (sys- ) This example shows how to implement the axs GUARD Gatekeeper mail services from the secure LAN for a specific group, using a predefined policy and rules. Navigate to Firewall > Policies > Dynamic. Enter mail as a search string (see illustration 21) and press enter. Illustration 21: axs GUARD Gatekeeper sys- Policy 37

38 GUARD Gatekeeper Firewall Step by Step Click on sys- in the list. The firewall rules are displayed. As this is a predefine (factory) policy, it cannot be modified (see section ). Make sure the firewall policy is enabled (see illustration 22). Illustration 22: axs GUARD Gatekeeper sys- Policy Details The policy is now enabled, but should be linked to a security level (i.e. a user or a group) before it is active. Navigate to Users&Groups > Groups and click on a group in the list. Select the Firewall tab and click the Add Firewall Policy button (see illustration 23). Illustration 23: axs GUARD Gatekeeper adding sys- to Group 1 Enter mail as the search string and press enter (see illustration 24). A list of policies containing the search string mail appears. Illustration 24: axs GUARD Gatekeeper adding sys- to group 2 Click on sys- once and exit the screen. The sys- policy has now been added to the selected group (see illustration 25). 38

39 GUARD Gatekeeper Firewall Step by Step Illustration 25: axs GUARD Gatekeeper adding sys- to group Click update to finish. The sys- policy is now in effect for the selected group. Locating the rules of a Firewall policy (sys- ) Follow the 2 first steps as explained in section 5.5. Click on sys- . The rules of the sys- firewall policy are displayed (see illustration 26). Click on a rule in the list (for instance sec-smtp) to view its details (see illustration 27). Illustration 26: axs GUARD Firewall Policy - Rules Note As this is a predefined (factory) rule, it cannot be modified. Predefined rules can only by enabled / disabled. 39

40 GUARD Gatekeeper Firewall Step by Step Illustration 27: axs GUARD Gatekeeper Rule Details 5.7 An example of using and implementing a new custom Firewall Policy (Citrix) This example shows how to implement an axs GUARD Gatekeeper custom Firewall Policy for a Citrix Back-End server and how to assign the new policy to a group. Navigate to Firewall > Rules > Through. Click the add new button, after which the screen as shown in illustration 28 appears. Illustration 28: axs GUARD Gatekeeper - Create Firewall Rules - Step 1 40

41 GUARD Gatekeeper Firewall Step by Step Illustration 29: axs GUARD Gatekeeper - Create Firewall Rules - Step 2 Enter a name for the new firewall rule, i.e. fwd-citrix. Enter a description (optional) for the new rule. Make sure to enable the rule. Select TCP as the protocol. Enter the destination IP address of the Citrix Back-End server (for instance: ). Enter the destination Port number (1494 is the default Citrix port). Select accept for the Target. Select Log this rule target, if you wish to log events related to this rule. Select Limit this rule target, if you wish to limit the matches and logs per second (DoS Protection). Enter the limit rate per second (the default is 5). Save the rule. The rule is now created. It is not active yet. Before it can be activated, it needs to be added to a policy. The policy should then be added to the adequate axs GUARD Gatekeeper security level. Navigate to Firewall > Policies > Dynamic and click add new. A screen similar to illustration 30 appears. 41

42 GUARD Gatekeeper Firewall Step by Step Illustration 30: axs GUARD Gatekeeper - Creating a custom Firewall Policy Enter a label for the policy, i.e. fwd-citrix. Enter a description for the policy (optional). Click the Add Firewall Rule button, a pop-up window appears (see illustration 31). Illustration 31: Integrating a custom rule into a custom policy Enter a portion of the rule's label as the search string, i.e. citrix and press enter. Click on the rule label, i.e. fwd-citrix, to add it to the new policy and close the window. The rule should now be listed in the policy. Save the policy. Finally, the policy needs to be added to the adequate axs GUARD Gatekeeper security level in order to be activated. Navigate to Users&Groups > Groups. Select (click) the group to which the policy should be assigned. Select the Firewall Tab and click Add Firewall Policy. A pop-up window appears. Enter a portion of the policy's name, i.e. citrix Click on the policy to add it to the group and close the window. Save the settings by clicking update. The policy has now been assigned to the selected group and applies to all users falling under this group. 42

43 GUARD 5.8 Gatekeeper Firewall Step by Step Recycling an existing Firewall Policy (Citrix) This example shows how to implement an axs GUARD Gatekeeper custom Firewall Policy for a Citrix Back-End server based on an existing Firewall Policy. Navigate to Firewall > Rules > Through. Enter a search string, i.e. citrix and press enter. Click on the policy. In the policy, click the edit as new button and modify the policy accordingly. Click save. Add the policy to the adequate axs GUARD Gatekeeper security level as explained in section 5.7. Tip The edit as new button can also be used for firewall rules, using the same method as descibed above. 5.9 Changing the Firewall rule hierarchy in a Firewall policy See section for details. Navigate to Firewall > Policies > Static or Dynamic and click on the desired firewall policy (see illustration 32). Illustration 32: axs GUARD Gatekeeper Firewall Rule Hierarchy To change the order (hierarchy) of the rules in the policy, the arrow buttons should be clicked until the desired result is obtained. Note The rule hierarchy cannot be changed in factory (predefined) policies Enable / Disable Firewall logging Navigate to Firewall > Rules > Towards / Through / DMZ Filter and click the specific rule for which logging should be enabled Check Log this rule target in order to enable logging. 43

44 GUARD Gatekeeper Firewall Step by Step Note As accepted traffic is not logged by default, the log rule target option should be checked for troubleshooting. Illustration 33: Enabling / Disabling Logging for a FW Rule 5.11 Adding Rules at the System Level for services on the axs GUARD Gatekeeper Caution Since system-level firewall rights apply to all users and computers, the strictest security should be enforced! See sections 3.6 and This example shows the procedure for adding a rule to a predefined static policy (system level) in order to access a service on the axs GUARD Gatekeeper from within the secure LAN. Navigate to Firewall > Policies > Static and enter stat-sec as a search string. Press enter. Click on stat-sec. Click the add firewall rule button. Click on the rule(s) which should be added (for instance sec-smtp) and close the window. Click update to add the rules to the policy. SMTP is now available for all users in the secure LAN Adding Rules at the System Level for services in the DMZ Caution Since system-level firewall rights apply to all users and computers, the strictest security should be enforced! See sections 3.6 and This example shows the procedure for adding a rule to a predefined static policy (system level) in order to access a service in the DMZ from the Internet 44

45 GUARD Gatekeeper Firewall Step by Step Navigate to Firewall > Policies > Static and enter dmz as a search string. Press enter. Click on stat-dmzf. Click the add firewall rule button. Click on the rule(s) which should be added (for instance dmzf-sweb) and close the window. Click update to add the rules to the policy. HTTPS is now available from the Internet on the server in the DMZ. Note For traffic from the Internet to the DMZ, use DMZ filter rules only, see section

46 Troubleshooting 6 Troubleshooting 6.1 My application does not work although I have created a firewall rule Please use the following chart to troubleshoot any Firewall problem: Illustration 34: axs GUARD Gatekeeper Firewall Troubleshooting Checklist Telnet: Use the telnet command to verify whether the problem is application related or connection related, for instance telnet for SMTP. (Use: telnet + IP address or DNS name, followed by a space and the service port number). See the appropriate telnet documentation for more details. Client Application: If a telnet connection can be established, the problem is application related and the client's application settings should be checked, for instance the browser's proxy settings. Refer to the application's documentation for assistance. Firewall Log: If a telnet connection cannot be established, check the Firewall Logs by navigating to Firewall > Logs. Click on the applicable date and enter the appropriate search string. 46

47 6.2 Troubleshooting Accept: If you wish to check log entries related to a certain rule for which the target is set to accept, make sure to verify whether the Log this rule target option is checked in this firewall rule (see illustration 29). Accepted packets are not logged by default. If the log shows the specific traffic as accepted, the problem is not firewall or rule related. The related axs GUARD Gatekeeper or Back-End service should be checked. Refer to the appropriate axs GUARD Gatekeeper Feature How To guides and application logs or the Back-End server's documentation for further assistance. Drop / Reject: If traffic - which normally should be allowed - is dropped, check the rule hierarchy in the firewall policy (see section 5.9). The order in which rules are entered in a policy affects that policy's behavior. Adding a rule to a policy which allows certain traffic has no effect when that rule is preceded by another rule dropping or rejecting the same traffic. The way a rule is contructed may also cause problems. Make sure to verify al fields of the rule, by navigating to Firewall > Rules > Towards / Through / DMZ Filter. Not Logged: Use the tcpdump command as explained in the axs GUARD Gatekeeper CLI guide, i.e. tcpdump -ni eth0 (Advanced troubleshooting only). The axs GUARD CLI guide is currently in progress and will be available shortly. More information about using the tcpdump command can also be found in the appropriate man pages. Firewall log file states: Bad 1 new not syn Also see the Advanced Firewall Concepts guide. This messages indicates that a packet matched a rule in the _BAD_PKTS chain of the firewall, which checks for TCP packets in the New state and the SYN flag not set. This match signifies a bad TCP connection setup (assymmetric routing), so the packet was dropped (see section 3.9.3). 6.3 Firewall log file states: BAD2: unclean Also see the Advanced Firewall Concepts guide. This message indicates that a packet matched a rule in the _BAD_PKTS chain of the firewall, which checks for unclean packets which seem malformed or unusual, containing bad headers or checksums. The packet is therefore dropped (see section 3.9.2). 6.4 I have several secure LANs and they cannot communicate By default, the axs GUARD Gatekeeper Firewall does not allow traffic between secure LANs. Adequate firewall rules and policies should be created and assigned to regulate (enable) this network traffic (see section ). 6.5 I cannot add or modify a rule in a policy Modifications are not allowed in (factory) predefined policies, except the ones as mentioned in section Tip In order to create a new rule or policy based on an existing one, use the edit as new button. 47