FireWall-1_GX.book Page 1 Tuesday, March 27, 2007 10:03 AM
FireWall-1 GX
Administration Guide Version 4.0
October 2006 FireWall-1_GX.book Page 2 Tuesday, March 27, 2007 10:03 AM FireWall-1_GX.book Page 3 Tuesday, March 27, 2007 10:03 AM
© 2003-2006 Check Point Software Technologies Ltd.
All rights reserved. This product and related documentation are protected by copyright and distributed under licensing restricting their use, copying, distribution, and decompilation. No part of this product or related documentation may be reproduced in any form or by any means without prior written authorization of Check Point. While every precaution has been taken in the preparation of this book, Check Point assumes no responsibility for errors or omissions. This publication and features described herein are subject to change without notice.
RESTRICTED RIGHTS LEGEND:
Use, duplication, or disclosure by the government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS 252.227-7013 and FAR 52.227-19.
TRADEMARKS:
©2003-2006 Check Point Software Technologies Ltd. All rights reserved.
Check Point, Application Intelligence, Check Point Express, the Check Point logo, AlertAdvisor, ClusterXL, Cooperative Enforcement, ConnectControl, Connectra, CoSa, Cooperative Security Alliance, Eventia, Eventia Analyzer, FireWall-1, FireWall-1 GX, FireWall-1 SecureServer, FloodGate-1, Hacker ID, IMsecure, INSPECT, INSPECT XL, Integrity, InterSpect, IQ Engine, Open Security Extension, OPSEC, Policy Lifecycle Management, Provider-1, Safe@Home, Safe@Office, SecureClient, SecureKnowledge, SecurePlatform, SecuRemote, SecureXL Turbocard, SecureServer, SecureUpdate, SecureXL, SiteManager-1, SmartCenter, SmartCenter Pro, Smarter Security, SmartDashboard, SmartDefense, SmartLSM, SmartMap, SmartUpdate, SmartView, SmartView Monitor, SmartView Reporter, SmartView Status, SmartViewTracker, SofaWare, SSL Network Extender, Stateful Clustering, TrueVector, Turboc ard, UAM, User-to-Address Mapping, UserAuthority, VPN-1, VPN-1 Accelerator Card, VPN-1 Edge, VPN-1 Pro, VPN-1 SecureClient, VPN-1 SecuRemote, VPN-1 SecureServer, VPN-1 VSX, VPN-1 XL, Web Intelligence, ZoneAlarm, ZoneAlarm Pro, Zone Labs, and the Zone Labs logo, are trademarks or registered trademark s of Check Point Software Technologies Ltd. or its affiliates. All other product names mentioned herein are trademarks or registered trademarks of their respective owners. The products described in this document are protected by U.S. Patent No. 5,606,668, 5,835,726, 6,496,935 and 6,850,943 and may be protected by other U.S. Patents, foreign patents, or pending applications.
For third party notices, see THIRD PARTY TRADEMARKS AND COPYRIGHTS. FireWall-1_GX.book Page 4 Tuesday, March 27, 2007 10:03 AM FireWall-1_GX.book Page 5 Tuesday, March 27, 2007 10:03 AM
Contents
Preface Who Should Use This Guide...... 10 Summary of Contents...... 11 Appendices ...... 11 More Information ...... 12
Chapter 1 GPRS/UMTS Overview A Global System for Mobile Communications...... 14 General Packet Radio Services ...... 15 Universal Mobile Telecommunications System...... 16 IP Multimedia Subsystem...... 17 Basic Components of GPRS/UMTS Networks ...... 18 On the Network ...... 18 Interfaces...... 19 Signalling Protocol...... 19 Comparing GTP Versions 0 and 1 ...... 21 Port Changes...... 21 Multiple PDP Contexts for the Same PDP Address...... 21 Secondary PDP Context Activation...... 22 Tunnel Update Initiated by the GGSN...... 22 Delete Teardown Flag...... 22
Chapter 2 Introducing FireWall-1 GX The Need for Security on GPRS/UMTS Networks...... 24 GTP - Insecure By Design ...... 24 Check Point Protects GPRS/UMTS Networks ...... 25 The Check Point GPRS/UMTS Commitment...... 25 Overview of FireWall-1 GX...... 26 Logging, Alerts, and Reporting ...... 26 Before Installing FireWall-1 GX ...... 26 Deploying FireWall-1 GX...... 27
Chapter 3 Securing GPRS/UMTS Networks Introduction to Securing GPRS/UMTS Networks...... 30 GTP Protocol Security ...... 31 Introduction to GTP Protocol Security ...... 31 Understanding the Overbilling Attack...... 31 Deleting PDP Contexts From the Command Line ...... 33 GTP-Aware Security Policy...... 34 Introduction to GTP-Aware Security Policy...... 34 GSN Address Filtering ...... 34 GTP Tunnel Management/ User Traffic...... 35
Table of Contents 5 FireWall-1_GX.book Page 6 Tuesday, March 27, 2007 10:03 AM
GTP Path Management Message Support ...... 38 GTP Mobility Management Message Support ...... 39 Dynamic Configuration of New GTP Messages and Information Elements ...... 40 Intra-Tunnel Inspection ...... 41 Introduction to Intra-Tunnel Inspection...... 41 GTP Address Anti-Spoofing...... 41 Block GTP in GTP...... 42 MS to Gn Network Policy Enforcement...... 43 APN Domain End User Address Enforcement...... 43 Wildcard APN Matching ...... 44 MS to MS Policy Enforcement...... 44 Mobile Subscriber Traffic Security...... 46 Cellular Specific Services ...... 47 WAP...... 47 MMS Over WAP ...... 47 Configuring Security...... 48 Creating a Basic Security Policy ...... 48 Enabling Overbilling Attack Protection ...... 54 Enforcing a More Granular GTP Security Policy...... 58 Using FW SAM to Close PDP Contexts ...... 69 Adding Support for New GTP Messages and Information Elements ...... 71 Adjusting Settings with GUI Dbedit ...... 72
Chapter 4 Using QoS to Manage GTP Bandwidth Introduction to GTP Bandwidth Management using QoS ...... 76 How it Works...... 77 Unsupported Features ...... 79 Configuring QoS with FireWall-1 GX...... 80
Chapter 5 Monitoring GPRS Network Security Introduction to Monitoring GPRS Network Security ...... 82 GTP Tracking Logs and Alerts ...... 83 Recording GTP Data from Unmatched PDUs...... 83 GTP Accounting...... 83 Excessive Logs Protection...... 84 Eventia Reporter Reports...... 85 Monitor-Only Mode ...... 88 SNMP Extensions for GTP Statistics ...... 89 Configuring Monitoring...... 90
Chapter 6 Log Messages Introduction to Log Messages...... 92 Adding Information Elements to Logs ...... 93 Log Messages...... 94
Chapter 7 Advanced Configuration GRX Redundant Deployment...... 104
6 FireWall-1_GX.book Page 7 Tuesday, March 27, 2007 10:03 AM
Introduction to GRX Redundant Deployment...... 104 Asymmetric Routing...... 105 Configuration...... 107 Testing the Setup ...... 108 Fine-tuning Synchronization Parameters...... 108 Stripping Information Elements...... 109 FireWall-1 GX Bridge Mode...... 110 Overview of FireWall-1 GX Bridge Mode...... 110 Description of IPSO Transparent Mode...... 110 Configuring Bridge Mode ...... 112
Appendix A Setting up a Layer 2 Tunnel on Cisco Routers Sample Deployment ...... 114 Configuration of Router 1 ...... 115 Defining the Tunnel ...... 115 Establishing Encryption (Optional)...... 115 Configuration of Router 2 ...... 117 Defining the Tunnel ...... 117 Establishing Encryption (Optional)...... 117
Appendix B Glossary
Index...... 131
Table of Contents 7 FireWall-1_GX.book Page 8 Tuesday, March 27, 2007 10:03 AM
8 FireWall-1_GX.book Page 9 Tuesday, March 27, 2007 10:03 AM
Preface P
Preface In This Chapter
Who Should Use This Guide page 10 Summary of Contents page 11 More Information page 12
9 FireWall-1_GX.book Page 10 Tuesday, March 27, 2007 10:03 AM
Who Should Use This Guide Who Should Use This Guide This guide is intended for administrators responsible for maintaining network security within an enterprise, including policy management and user support. This guide assumes a basic understanding of • System administration. • The underlying operating system. • Internet protocols (IP, TCP, UDP etc.).
10 FireWall-1_GX.book Page 11 Tuesday, March 27, 2007 10:03 AM
Summary of Contents Summary of Contents This guide contains the following chapters:
Chapter Description Chapter 1, “GPRS/UMTS Provides an overview of GPRS/UMTS. Overview” Chapter 2, “Introducing Describes how FireWall-1 GX provides cellular FireWall-1 GX” operators, enterprises and end users with an integrated, open, end-to-end security solution and shows how FireWall-1 GX enables operators to define and enforce customized, granular “GTP-aware” security policies for both GTP v0 and GTP v1 Chapter 3, “Securing Presents the various protections that FireWall-1 GPRS/UMTS Networks” GX provides for GPRS/UMTS networks Chapter 4, “Using QoS to Introduces GTP Bandwidth Management using Manage GTP Bandwidth” QoS and shows how to configure QoS using Firewall-1 GX. Chapter 5, “Monitoring GPRS Shows how to gather information on the Network Security” network’s traffic patterns by monitoring GPRS Network Security. Chapter 6, “Log Messages” Explains how to add information elements to logs and presents Firewall-1 GX log messages. Chapter 7, “Advanced Describes GRX Redundant Deployment. Configuration”
Appendices
This guide contains the following appendices:
Appendix Description Appendix A, “Setting up a Provides sample deployments and configuration Layer 2 Tunnel on Cisco examples. Routers” Appendix B, “Glossary” Provides the definition of commonly used terms.
Preface11 FireWall-1_GX.book Page 12 Tuesday, March 27, 2007 10:03 AM
More Information More Information • For additional technical information about Check Point products, consult Check Point’s SecureKnowledge at https://secureknowledge.checkpoint.com/.
• See the latest version of this document in the User Center at http://www.checkpoint.com/support/technical/documents.
12 FireWall-1_GX.book Page 13 Tuesday, March 27, 2007 10:03 AM
Chapter 1 GPRS/UMTS Overview
In This Chapter
A Global System for Mobile Communications page 14 General Packet Radio Services page 15 Universal Mobile Telecommunications System page 16 Basic Components of GPRS/UMTS Networks page 18 Comparing GTP Versions 0 and 1 page 21
13 FireWall-1_GX.book Page 14 Tuesday, March 27, 2007 10:03 AM
A Global System for Mobile Communications A Global System for Mobile Communications The most widely deployed wireless networks worldwide are those based on Global System for Mobile Communications, or GSM, technology. Formerly known as "Groupe Spécial Mobile," GSM is a world-wide standard for digital wireless mobile phones. The standard was originated by the European Conference of Postal and Telecommunications Administrations (CEPT) and further developed by the European Telecommunications Standards Institute (ETSI) as a standard for European mobile phones, with the intention of developing an open, non-proprietary standard for adoption world-wide. It has been remarkably successful, with more than one billion people using GSM phones as of early 2004. The ubiquity of the GSM standard makes intra-nation roaming very common, with international roaming frequently enabled by "roaming agreements" between operators. GSM differs from its predecessors most significantly in that both signalling and speech channels are digital. It has also been designed for a moderate level of security. GSM employs time division multiple access between stations on a frequency duplex pair of radio channels, with slow frequency hopping between channels.
14 FireWall-1_GX.book Page 15 Tuesday, March 27, 2007 10:03 AM
General Packet Radio Services General Packet Radio Services General Packet Radio Services, or GPRS, is a GSM extension which allows packet switched data transmission. GPRS has been called 2.5G, as it is viewed as a stepping stone toward pure 3G systems like UMTS/W-CDMA or similar. GPRS is backward compatible with GSM, a fact that eases the migration path for GSM operators, who can gradually upgrade their infrastructure as the GPRS market expands. From the user's point of view, GPRS is a wireless extension of data networks. It can access multiple types of data networks, such as IP based networks like the public Internet, private intranet, both IPv4 and IPv6 protocols, and X.25 based networks. GPRS upgrades GSM data services providing: • Point-to-point (PTP) service: internetworking with the Internet (IP protocols) and X.25 networks. • Point-to-multipoint (PTM) service: point-to-multipoint multicast and point-to-multipoint group calls. • Short Message Service (SMS): bearer for SMS. Thus mobile subscribers can receive an array of services, including web browsing, e-mail communications, intranet access and location-based services. GPRS is basically an addition to GSM that enables packet based communications. Data transmitted by packet switching is faster and more efficient than circuit switching, the method used in 2G networks. Whereas in GSM timeslots are normally allocated to create a circuit-switched connection, in GPRS timeslots are allocated to a packet-connection on an as-needed basis. This means that if no data are sent by a sender, the frequencies involved remain free to be used by others. Users of GPRS networks can stay continuously logged in to email and Internet services, while paying for these services only when sending and receiving data. Development of GPRS is directed by the 3rd Generation Partnership Project (3GPP), a collaboration agreement established in 1998. 3GPP's original goal was to produce technical specifications for third generation mobile systems, and now is involved in maintaining and developing GSM standards, including GPRS.
Chapter 1 GPRS/UMTS Overview 15 FireWall-1_GX.book Page 16 Tuesday, March 27, 2007 10:03 AM
Universal Mobile Telecommunications System Universal Mobile Telecommunications System Universal Mobile Telecommunications System, or UMTS, is one of the third generation (3G) mobile phone technologies that comprise the next major evolution of wireless networks. UMTS further extends the capabilities of GPRS networks, offering much higher air interface bandwidth. UMTS networks provide an average bandwidth of up to 384Kbit/sec, which is more than 26 times the bandwidth obtainable on a single GSM error-corrected circuit switched data channel. This increased bandwidth allows for the development and support of a whole new set of services, mostly multimedia-based, such as video streaming, video conferencing, online games, advanced location services, and more.
16 FireWall-1_GX.book Page 17 Tuesday, March 27, 2007 10:03 AM
IP Multimedia Subsystem IP Multimedia Subsystem A description of the evolving UMTS network would not be complete without mentioning IP Multimedia Subsystem, or IMS. The IP Multimedia Subsystem (IMS) is a common architecture that allows cellular operators to provide multimedia services. Promoted by 3GPP, IMS uses SIP as its basic signalling protocol. IMS uses SIP to register and authenticate the mobile user when joining a multimedia session, as well as to initiate the session by locating the destination of the session (either a multimedia server, or other mobile user, or other non mobile user). By selecting a standard protocol for multimedia services, the aim is to eliminate interoperability issues in the creation of multimedia sessions between mobile users, and between mobile users and users on the Internet. Check Point's portfolio of cellular security solutions includes solutions for IMS security as well.
Chapter 1 GPRS/UMTS Overview 17 FireWall-1_GX.book Page 18 Tuesday, March 27, 2007 10:03 AM
Basic Components of GPRS/UMTS Networks Basic Components of GPRS/UMTS Networks
On the Network
PLMN (Public Land Mobile Network) — a mobile wireless network that uses land-based radio transmitters or base stations. PDN (Public Data Network or Packet Data Network) — a network that provides packetized data services, such as the Internet. GSN or xGSN (GPRS Support Node) — a generic term that refers to both SGSNs and GGSNs. • SGSN (Serving GPRS Support Node) — sends and receives data from mobile stations, and maintains information about their location. • GGSN (Gateway GPRS Support Node) — acts as mediator between encapsulated GTP traffic on the PLMN, and packetized IP traffic on the Internet and other PDNs. MS (Mobile Station) — a wireless device that uses a radio interface to access network services. GRX (GPRS Roaming eXchange) — an IP network that connects PLMNs, enabling MSs to connect to their home PLMNs through roaming partners. APN (Access Point Name) — provides routing information for SGSNs PDF (Policy Decision Function) — logical element that uses standard IP mechanisms to implement policy in the IP media layer. The PDF uses policy rules to make decisions in regard to network based IP policy, and communicates these decisions to the PEP on the GGSN. PEP (Policy Enforcement Point) —logical entity that enforces policy decisions made by the PDF. It resides on the GGSN. Figure 1-1 illustrates most of these concepts: Figure 1-1 GPRS Local Network Architecture
18 FireWall-1_GX.book Page 19 Tuesday, March 27, 2007 10:03 AM
Basic Components of GPRS/UMTS Networks
Interfaces
An interface is the point of connection between telecommunication entities. While there are many types of interfaces in a cellular network, this guide deals primarily with the following interfaces. • Gi interface — connects GGSN to an external PDN. • Gn interface — connects xGSNs on same PLMN. • Go interface — connects a GGSN to a Policy Decision Function (PDF). • Gp interface — connects xGSNs on different PLMNs. Figure 1-2 illustrates these interfaces. Figure 1-2 GPRS interfaces
Signalling Protocol
GTP (GPRS Tunneling Protocol) — used to transport user data between GSNs. The data is encapsulated inside a packet, which consists of the data payload and a routing header. GTP version 0 has been updated to include new capabilities in version 1, however most GPRS networks maintain support for both. GTP-C (GPRS Tunneling Protocol - Control) — used for control messages to create, update and delete GTP tunnels, and for path management. GTP-U (GPRS Tunneling Protocol - User) — used for user messages to carry user data packets, and signalling messages for path management and error indication. TEID (Tunnel Endpoint IDentifier) — used to unambiguously identify a tunnel endpoint. G-PDU (GTP Protocol Data Unit) — used for data and control information.
Chapter 1 GPRS/UMTS Overview 19 FireWall-1_GX.book Page 20 Tuesday, March 27, 2007 10:03 AM
Basic Components of GPRS/UMTS Networks
PDP (Packet Data Protocol) — a network protocol used by an external packet data network (usually IP). PDP address — the address of an MS in the external packet data network, also called End User IP address. PDP context — a logical association between an MS and PDN. There are five types of PDP context commands: • Create • Update • Delete • Request • Response See the “Glossary” on page 119 for an extensive list of industry-specific terms.
20 FireWall-1_GX.book Page 21 Tuesday, March 27, 2007 10:03 AM
Comparing GTP Versions 0 and 1 Comparing GTP Versions 0 and 1 The most important differences between GTP version 0 and version 1 arise from the fact that GTP version 1 supports several different services simultaneously, which in turn requires a clearer focus on Quality of Service (QoS).
Port Changes
While the entire GTP version 0 communication is transmitted over a single UDP (3386), GTP version 1 packets are transmitted over two different UDP ports: • The Control plane, which includes the create, update, delete and echo exchanges, now uses UDP port 2123. • The User plane, which includes the tunneled data packets, now uses UDP port 2152. By separating signalling and mobile user traffic to two different ports, either one of these types of traffic can be encrypted without the other.
Multiple PDP Contexts for the Same PDP Address
In GTP version 0, an MS might have several simultaneous PDP contexts, but a single PDP address on a specific APN is uniquely associated with a single PDP context. For each combination of external packet network and MS-local address, there is one tunnel (PDP context). In GTP version 1, multiple PDP contexts are allowed per PDP address and APN. After a successful GPRS activation, where the MS establishes a PDP context and connects to the external network, the MS can initiate more PDP contexts with the same APN. The new PDP contexts for the same PDP address differ in QoS requirements and charging characteristics, and are used to separate streams of different services or protocols. This is useful for IMS, where the initial PDP Context (used for SIP registration) has low bandwidth requirements, but the following PDP Contexts (used for actual data streaming) require a higher bandwidth.
Chapter 1 GPRS/UMTS Overview 21 FireWall-1_GX.book Page 22 Tuesday, March 27, 2007 10:03 AM
Comparing GTP Versions 0 and 1
Secondary PDP Context Activation
The mechanism used to initiate additional PDP contexts for the same MS and APN is known as “Secondary PDP context activation. The same message exchange (create PDP context) is used for this activation. However, since the MS and APN information is already known, the message in this procedure contains fewer Information Elements (IE) than the initial exchange. To reference to the original exchange, the secondary create PDP context message contains the Network Service Access Point Identifier (NSAPI) number of the original create message, known as the linked NSAPI.
Tunnel Update Initiated by the GGSN
As part of its extended QoS support, GTP version 1 allows the GGSN to initiate an PDP context update. Another usage of this exchange by the GGSN is to provide a PDP address to the SGSN and/or MS when the GGSN acts as a DHCP or Mobile IP agent.
Delete Teardown Flag
The teardown flag is another enhancement in v1 as compared to v0. It was motivated by the existence of multiple PDP contexts for the same MS and network/service. This flag controls indicates whether this delete request is for a specific PDP context or for the whole bunch of PDP contexts (original and secondaries) that were based on the same primary creation exchange.
22 FireWall-1_GX.book Page 23 Tuesday, March 27, 2007 10:03 AM
Chapter 2 Introducing FireWall-1 GX
In This Chapter
The Need for Security on GPRS/UMTS Networks page 24 Check Point Protects GPRS/UMTS Networks page 25 Overview of FireWall-1 GX page 26 Deploying FireWall-1 GX page 27
23 FireWall-1_GX.book Page 24 Tuesday, March 27, 2007 10:03 AM
The Need for Security on GPRS/UMTS Networks The Need for Security on GPRS/UMTS Networks As GPRS networks undergo the transition from proprietary, closed networks to the open world of IP, both the MS and the network itself become exposed to the full range of security threats that plague the Internet, as well as to threats that specifically target wireless mobile networks. IP-based signals expose GPRS/UMTS networks to a wide range of attacks: Denial of Service, IP spoofing, Overbilling, tunnel hijacking, flooding, DNS cache poisoning, and many other attacks. Any hacker with the will to do so can compromise security and disrupt communications.
GTP - Insecure By Design
GTP, the key protocol used in delivering mobile data services, offers no solution. The GTP specification specifically states: No security is provided in GTP to protect the communication between different GPRS networks. The security is provided, if needed, between the Border Gateways in different GPRS networks by operator agreements. A security mechanism that may be considered is for example IP Security. The GPRS/UMTS network is at risk from both its own subscribers and its partner networks. Despite years of development and deployment, new security vulnerabilities are constantly being found in IP software, and evolving GPRS/UMTS software will be no different. The lesson: don't depend on the network to provide your security - provide your own security.
24 FireWall-1_GX.book Page 25 Tuesday, March 27, 2007 10:03 AM
Check Point Protects GPRS/UMTS Networks Check Point Protects GPRS/UMTS Networks Check Point FireWall-1 GX has been protecting GPRS and UMTS (also known as 2.5 and 3rd Generation) networks worldwide since 2001 by providing a GTP-level security solution that blocks illegitimate traffic "at the door." Only FireWall-1 GX provides cellular operators, enterprises and end users with an integrated, open, end-to-end security solution. FireWall-1 GX enables operators to define and enforce customized, granular “GTP-aware” security policies for both GTP v0 and GTP v1. FireWall-1 GX is fully configurable, and produces GTP-specific detailed logs and alerts. It can be installed on the: • Gp interface (between the Home PLMN and the GRX network) • Gn interface (between the GGSNs and the SSGNs in the Home PLMN) Working together with standard VPN-1 Pro on the Gi interface, FireWall-1 GX provides GPRS/UMTS networks with the highest level of security available today. FireWall-1 GX provides protection from the following threats to the core network and mobile users: Figure 2-1 FireWall-1 GX protections for cellular networks Attack Target Attack Source Deploy FireWall-1 GX on Core network Partner network, or Partner of a Gp interface Partner, or anyone with access to GRX Core network Mobile Users Gn interface Core network Internet or enterprise connections Gn interface, with VPN-1 Pro on Gi interface Core network Within core network Gn interface Mobile Users Mobile user to mobile user Gn interface
Check Point FireWall-1 GX is based on the industry-leading NGX technology and fully supports the wide range of security features that this release offers. This document describes the FireWall-1 GX features added to VPN-1 Pro, and assumes the reader has a working knowledge of VPN-1 Pro.
The Check Point GPRS/UMTS Commitment
Check Point maintains a dedicated R&D and product management team specializing in GPRS/UMTS security. Check Point is a member of the Global Systems Mobile communications Association (GSMA) security group, and is fully committed to keeping its products up-to-date with GPRS and UMTS standards.
Chapter 2 Introducing FireWall-1 GX 25 FireWall-1_GX.book Page 26 Tuesday, March 27, 2007 10:03 AM
Check Point Protects GPRS/UMTS Networks
Overview of FireWall-1 GX
FireWall-1 GX was specifically designed for wireless operators and combines Check Point's patented Stateful Inspection technology with full GPRS Tunneling Protocol (GTP) awareness. FireWall-1 GX inspects all GTP tunnel fields in the context of both the packet and the tunnel. This enables granular security policies that deliver the highest level of security for these wireless infrastructures.
Logging, Alerts, and Reporting
In addition to security enforcement, FireWall-1 GX provides a rich set of GTP-specific log information, including granular logging details on tunnel creation, updates and deletions. Administrators can set a wide range of security alerts based on defined activity. And FireWall-1 GX provides a GTP-enhanced reporting tool to give a bird’s-eye view of network activity. See chapter 5, “Monitoring GPRS Network Security” on page 81 for more information on logging, alerts and reports.
Before Installing FireWall-1 GX
Before installing FireWall-1 GX, familiarize yourself with the following Check Point documentation: 1. Read the user guides relevant for your environment included on the CD. 2. Read this document, which describes the FireWall-1 GX-specific features. 3. Read the most up-to-date Release Notes at http://www.checkpoint.com/techsupport/downloads.jsp for the latest information about supported platforms and other FireWall-1 GX information.
26 FireWall-1_GX.book Page 27 Tuesday, March 27, 2007 10:03 AM
Deploying FireWall-1 GX Deploying FireWall-1 GX For maximum security, a FireWall-1 GX Enforcement Module should be installed at all points in the network where the Home PLMN interfaces with other networks: at Border Gateways (Gp) and Intra-PLMN interfaces (Gn). Figure 2-2 depicts a suggested FireWall-1 GX deployment. Figure 2-2 Suggested FireWall-1 GX deployment
In this example, two types of Check Point Enforcement Modules are deployed. The protections provided by each are described in Figure 2-3 and Figure 2-4: FireWall-1 GX Enforcement Modules
Chapter 2 Introducing FireWall-1 GX 27 FireWall-1_GX.book Page 28 Tuesday, March 27, 2007 10:03 AM
Deploying FireWall-1 GX
Figure 2-3 FireWall-1 GX Enforcement Modules are deployed at these interfaces Interface Located Between Description Gp the Home PLMN Filters incoming roaming traffic and enforces a GTP- and GRX aware Security Policy, protecting the Home PLMN from malicious or erroneous traffic from the networks of roaming partners, as well as from traffic not originating from legitimate roaming partners. Gn the GGSNs and Filters GPRS traffic between the Home PLMN GSNs, the SSGNs in the protecting them from malicious or erroneous traffic. Home PLMN
VPN-1 Pro Enforcement Modules Figure 2-4 VPN-1 Pro Enforcement Modules are deployed at these interfaces Interface Located Between Description Gi the Home PLMN Protects the network from threats originating from and the Internet the Internet, such as the Overbilling attack. Go the GGSN and Protects the CSCF (Call Session Control Function) SIP CSCF SIP server server and enforces the SIP protocol. A major feature of this Enforcement Module is RTP pinholing - i.e., it dynamically follows the negotiated RTP sessions, opening only the UDP ports required.
Note - Mobile to mobile IMS communications can also be protected by the Enforcement Module on the Go interface. To do so, mobile to mobile traffic must be routed from the GGSN to the Enforcement Module and back to the GGSN.
28 FireWall-1_GX.book Page 29 Tuesday, March 27, 2007 10:03 AM
Chapter 3 Securing GPRS/UMTS Networks
In This Chapter
Introduction to Securing GPRS/UMTS Networks page 30 GTP Protocol Security page 31 GTP-Aware Security Policy page 34 Intra-Tunnel Inspection page 41 Cellular Specific Services page 47 Configuring Security page 48
29 FireWall-1_GX.book Page 30 Tuesday, March 27, 2007 10:03 AM
Introduction to Securing GPRS/UMTS Networks Introduction to Securing GPRS/UMTS Networks FireWall-1 GX includes a variety of measures to protect GPRS/UMTS networks from possible attack. The GPRS Tunneling Protocol (GTP), the communications protocol of mobile networks, was designed without regard to security, and so any security scheme for GPRS/UMTS networks must account for the GTP protocol. FireWall-1 GX thus enforces a security policy that is GTP-aware, capable of identifying and rejecting malicious data or attempts to misuse the protocol, and even inspect GTP-encapsulated data packets. Additional security measures can be deployed at the Gn or Go interface. By deploying a VPN-1 Pro NGX Enforcement Module with advanced cellular network capabilities at the Gn and/or Go interface, the following additional security is available: • at the Gn interface: • MMS/WAP based security policy • at the Go interface: • GSM-SIP aware firewall security over IPv4 or IPv6 This chapter presents the various protections that FireWall-1 GX provides for GPRS/UMTS networks, and is divided into the following sections: • “GTP Protocol Security” on page 31 discusses how FireWall-1 GX scans GTP communications for abuse of the protocol, and includes a summary of the Overbilling attack and the protection that FireWall-1 GX provides. • “GTP-Aware Security Policy” on page 34 discusses the principles of establishing a Security Policy that can selectively allow the various signalling messages within GTP, as well as the addresses from which the communications originate. • “Intra-Tunnel Inspection” on page 41 discusses how FireWall-1 GX inspects mobile user traffic encapsulated by GTP. • “Cellular Specific Services” on page 47 provides detail on cellular-specific services that can be incorporated into the Security Policy. • “Configuring Security” on page 48 explains how to create a basic Security Policy and configure the security features available with FireWall-1 GX.
30 FireWall-1_GX.book Page 31 Tuesday, March 27, 2007 10:03 AM
GTP Protocol Security GTP Protocol Security
In This Section
Introduction to GTP Protocol Security page 31 Understanding the Overbilling Attack page 31 Deleting PDP Contexts From the Command Line page 33
Introduction to GTP Protocol Security
FireWall-1 GX inspects all GTP tunnel fields in the context of both the packet and the tunnel, which allows the definition and enforcement of a granular, GTP-specific Security Policy that protects both network assets and subscribers from possible attack. FireWall-1 GX secures the GTP protocol in the following ways. • GTP protocol enforcement ensures the legitimate use of the GTP protocol, protecting GSN servers from harmful traffic. The FireWall-1 GX parser verifies that each GTP message contains the correct set of Information Elements (IE) in the proper sequence. • GTP Stateful Inspection ensures that only legitimate GTP traffic passes through the gateway. For example, data packets (G-PDUs) and PDP context update messages are allowed only for open PDP contexts. FireWall-1 GX detects any tampering with the state and rejects such traffic. • PDP context timelines are strictly verified, and operations on unestablished or deleted contexts are disallowed.
Understanding the Overbilling Attack
The Overbilling attack targets a cellular operator’s network, reputation, and bottom line. The attack takes advantage of a weakness in the architecture of GPRS networks where previously used IP addresses are reassigned to other devices. The attack takes place as follows: 1. Attacker connects to cellular network as a legitimate subscriber. 2. An SGSN assigns the mobile device an IP address. 3. Attacker uses a malicious server to continuously send packets to the address assigned in step 2. 4. Attacker ends the GPRS connection and the PDP context is deleted.
Chapter 3 Securing GPRS/UMTS Networks 31 FireWall-1_GX.book Page 32 Tuesday, March 27, 2007 10:03 AM
GTP Protocol Security
5. The malicious server ignores TCP FIN packets and continues to send packets to the address assigned in step 2. 6. An innocent subscriber requests service, and the SGSN reassigns the original IP address. 7. The data traffic that the malicious server is sending to that address is charged to the new device’s account, without the knowledge of its owner. The device ignores the traffic as noise, but its owner is charged for the time-slots occupied. 8. Attacker repeats the process, adding IP addresses to the attack each time a new one is assigned. When invoices are distributed, the company is attacked again by irate customers who claim they didn’t use this bandwidth. The net effect of this attack is inflated receivables estimates, a swamped customer/billing center, loss of customer loyalty, and great aggravation for the customer. The attacker in this way compromises the cellular provider’s good name.
The Check Point Solution to the Overbilling Attack This attack was officially reported to the GSM Association in 2002, and the FireWall-1 GX solution is the GSMA-approved solution for this attack. Briefly, FireWall-1 GX protects GPRS networks from Overbilling attacks as follows: • FireWall-1 GX is deployed on the Gn interface, and a standard FireWall-1 Enforcement Module is on the Gi interface. • Whenever a GTP tunnel is deactivated, FireWall-1 GX notifies the FireWall-1 Module on the Gi interface to block all packets belonging to connections of the de-activated tunnel. Thus the packets sent by the malicious server are stopped at the firewall, and no further steps need to be taken. To enable Check Point’s protection for the Overbilling attack, see “Enabling Overbilling Attack Protection” on page 54.
32 FireWall-1_GX.book Page 33 Tuesday, March 27, 2007 10:03 AM
GTP Protocol Security
Deleting PDP Contexts From the Command Line
FireWall-1 GX has the ability to gracefully and actively close an active PDP context, as well as limit access to certain network services based on IP, port, and IP protocol criteria. From the command line, you can delete an active PDP context from the connection table. Any further attempts to create a PDP context are blocked. You can disconnect a specific IMSI, MS-ISDN, or APN, or some combination of them. For example, you can disconnect IMSI user Joe from APN Texas. See “Using FW SAM to Close PDP Contexts” on page 69 for usage details.
Chapter 3 Securing GPRS/UMTS Networks 33 FireWall-1_GX.book Page 34 Tuesday, March 27, 2007 10:03 AM
GTP-Aware Security Policy GTP-Aware Security Policy
In This Section
Introduction to GTP-Aware Security Policy page 34 GSN Address Filtering page 34 GTP Tunnel Management/ User Traffic page 35 GTP Path Management Message Support page 38 GTP Mobility Management Message Support page 39
Introduction to GTP-Aware Security Policy
FireWall-1 GX provides the ability to define a single GTP-aware Security Policy using Check Point’s intuitive GUI tools. The following section details how you can use GSN address filtering, and GTP Tunnel, Path, and Mobility Management signalling messages to create a GPRS Security Policy.
GSN Address Filtering
The ability of FireWall-1 GX to identify the various aspects of GTP traffic allows for the enforcement of security rules in a granular manner. One such capability is the ability to enforce the creation and update of PDP contexts by defined GSN addresses. • PDP context creation is enforced according to directional security rules that identify the range of SGSN addresses that are allowed to create tunnels. • PDP context updates, redirection and handover are enforced according to directional security rules. In addition, FireWall-1 GX strictly enforces SGSN handovers and GSN redirections according to predefined address ranges and sets (Handover Groups).
34 FireWall-1_GX.book Page 35 Tuesday, March 27, 2007 10:03 AM
GTP-Aware Security Policy
GTP Tunnel Management/ User Traffic
In This Section
Introduction to GTP Tunnel Management/ User Traffic page 35 Tunnel Management and User Traffic Service page 35 GTP Service Filters page 36 End User PDU Protections page 36 End User Address Modes page 37 Session Hijacking Protection through GSN Handover Groups page 37
Introduction to GTP Tunnel Management/ User Traffic FireWall-1 GX recognizes and can control the access of GTP Tunnel management services to your network. You can build simple security rules to allow all GTP user traffic on your network, or opt for a more refined policy through the various customizations possible with FireWall-1 GX. The following sections discuss the various ways you can secure user traffic on your GPRS/UMTS network.
Tunnel Management and User Traffic Service Tunnel management services are those parts of the GTP protocol that carry the actual user traffic - voice, data, etc. FireWall-1 GX allows you to build security rules to allow this traffic within your GPRS network. Use these services to enable communication between incoming traffic and your xGSNs. Tunnel management services on FireWall-1 GX are predefined as: • gtp_v0_default, which addresses message types defined in 3GPP TS 09.60. • gtp_v1_default, which addresses message types defined in 3GPP TS 29.060. See “Creating Security Rules with GTP Services” on page 50 for more information about using tunnel management services in security rules.
Chapter 3 Securing GPRS/UMTS Networks 35 FireWall-1_GX.book Page 36 Tuesday, March 27, 2007 10:03 AM
GTP-Aware Security Policy
GTP Service Filters You can be more selective than simply allowing all tunnel traffic, however. You can build security rules to more precisely select which user traffic can cross the firewall. Through the use of GTP-aware filters, FireWall-1 GX provides the ability to limit the creation of PDP contexts to traffic that matches specific parameters that you define. You can set up a GTP service filter that matches traffic by: • APN • IMSI (MCC, MNC) Prefix • MS-ISDN Prefix • APN Selection Mode • LDAP Group As cellular operators tend to sort their LDAP databases by either IMSI or MS-ISDN, FireWall-1 GX can identify whether a user belongs to a specific LDAP group by IMSI or MS-ISDN prefix. You can learn more about securing LDAP databases in the SmartDirectory (LDAP) and User Management chapter of the SmartCenter book. By customizing the pre-defined user traffic services gtp_v0_default and gtp_v1_default, or creating new customized services, you can build a logical “and” argument to choose what specific characteristics to match, and then configure a security rule to accept this specific class of user traffic. While predefined GTP services are provided with FireWall-1 GX, it is recommended that you create new services for customization. For configuration information, see “Customizing GTP Services” on page 59.
End User PDU Protections FireWall-1 GX protects the integrity of Protocol Data Units (PDUs). • Sequence Number Validation - FireWall-1 GX verifies PDU sequence numbers for both signaling and user traffic. For configuration information, see “GTP PDU Integrity Tests” on page 66. • Flow Labels Validation - In GTP ver. 0, when two GTP tunnels are open on one device, they have the same tunnel ID. To distinguish between tunnels, FireWall-1 GX adds packet flow labels to the tunnel ID. To secure this solution, FireWall-1 GX can validate that the flow labels assigned belong to packets of a similar flow.
36 FireWall-1_GX.book Page 37 Tuesday, March 27, 2007 10:03 AM
GTP-Aware Security Policy
• Multiple GGSN Interface Support - GTP ver. 1 allows xGSNs to reply to PDP context requests from a different interface than the one to which the request was sent. This capability, useful for load balancing, can make a system vulnerable to Session Hijacking. FireWall-1 GX is able to protect against Session Hijacking through the use of Handover Groups. For configuration information, see “Secure Connectivity Features” on page 67.
End User Address Modes FireWall-1 GX can be configured to block PDP context creations from MSs with static IP addresses. For configuration information, see Allow usage of static IP address in “Secure Connectivity Features” on page 67.
IPv6 T-PDU Security FireWall-1 GX enforces the proper use of IPv6 T-PDUs encapsulated inside IPv4 GTP G-PDUs. The IPv6 End User Address Information Element in the Create PDP Context message is inspected and allowed upon proper validation. The IPv6 End User address in the T-PDU is then tested for GTP Anti-Spoofing. For more information, see “GTP Address Anti-Spoofing” on page 41.
Session Hijacking Protection through GSN Handover Groups When an SGSN sends data to a GGSN and awaits a reply, an unprotected GPRS/UMTS network may become exposed to what is known as Session Hijacking. Session Hijacking is a type of attack that involves eavesdropping on an established communications session and assuming the identity of an authenticated user. It can occur during handover, redirection, and by permitting “unknown” GGSNs to reply to SGSN-initiated communications. Handover, which enables subscribers to seamlessly move from one area to another with no interruption of active sessions, is a fundamental feature of GPRS/UMTS. But this ability to move from SGSN to SGSN can expose the cellular operator to Session Hijacking. In GTP, a GGSN will relinquish control of a tunnel to any device from which it receives a PDP context update request message. This can be exploited to hijack GTP tunnels or cause a Denial of Service (DoS). Redirection, which enables load sharing among xGSNs, is also vulnerable to Session Hijacking. In some GTP signaling messages, a malicious xGSN can redirect the handling of subsequent messages to another device by inserting that device’s IP address in the message.
Chapter 3 Securing GPRS/UMTS Networks 37 FireWall-1_GX.book Page 38 Tuesday, March 27, 2007 10:03 AM
GTP-Aware Security Policy
A cellular operator may choose to set up multiple GGSNs, and under version 1 of the GTP protocol allow a GGSN other than the one that received an SGSN message to reply to that message. This practice can leave a network vulnerable to Session Hijacking, where a malicious GGSN responds to an SGSN message before the real GGSN can respond. Because the SGSN has been configured to allow any response, it directs traffic to the malicious GGSN.
Check Point’s Solution - Handover Groups To protect against this threat, FireWall-1 GX uses Handover Groups, sets of IP addresses among which handovers are allowed. Handover Groups typically consist of the IP addresses of a GPRS/UMTS operator’s GSNs. FireWall-1 GX strictly enforces Handover Groups, allowing handover and redirection only within the group. In addition, tunneled and signaling packets are matched according to tunnel ID against a tunnel internal state table. Improper use of GTP signaling is blocked and logged. For configuration information, see “Creating a GSN Handover Group” on page 50.
GTP Path Management Message Support
According to the protocol specification 3GPP TS 29.060, a path is a UDP/IP connection used to multiplex GTP tunnels between GPRS network resources, such as from one xGSN to another. The GTP signaling messages that maintain the GPRS tunnels are known as Path Management. FireWall-1 GX allows you to build security rules to allow this traffic within your GPRS network. Use these services to enable communication among your xGSNs. Path management services on FireWall-1 GX are predefined as: • gtp_v0_path_mgmt, which addresses message types defined in 3GPP TS 09.60. • gtp_v1_path_mgmt, which addresses message types defined in 3GPP TS 29.060. See “Creating Security Rules with GTP Services” on page 50 for more information about using path management services in security rules. The following FireWall-1 GX security features allow you to protect your network from various attempts to abuse Path Management signaling messages. • GTP Echo Stateful Inspection - ensures that there is a matching echo request in the log before allowing an echo response packet through the firewall.
38 FireWall-1_GX.book Page 39 Tuesday, March 27, 2007 10:03 AM
GTP-Aware Security Policy
• Limit Echo Rate - The GTP protocol states that “an echo request shall not be sent more often than every 60 seconds per path.” If desired, you can enforce echo requests as the protocol specifies, or to whatever interval you want. FireWall-1 GX can be configured to restrict the echo rate per GTP path or allow GTP echo exchange only between GSNs with an active PDP context. • GTP signal packet rate limit enforcement - can be configured to limit the rate of signaling PDU to prevent signaling flooding or Denial of Service (DoS) attacks. For configuration information of Path Management, see “Limiting Signaling Rates” on page 68.
GTP Mobility Management Message Support
Mobility Management messages are the control plane messages as defined in 3GPP TS 23.060 and 3GPP TS 24.008. They are sent between SGSNs during the GPRS Attach and Inter SGSN Routing Update procedures. FireWall-1 GX enforces protocol integrity and security policy for mobility management messages. FireWall-1 GX also allows you to isolate these messages within GTP packets and permit them access to your SGSNs, while denying access to other types of GTP traffic. This capability can be used to enhance network security by allowing only mobility management GTP message traffic between xGSNs. FireWall-1 GX allows you to build security rules to allow this traffic within your GPRS network. Use these services to enable mobility management communications among your xGSNs. Mobility Management services on FireWall-1 GX are predefined as: • gtp_mm_v0_default, which addresses message types defined in 3GPP TS 09.60. • gtp_mm_v1_default, which addresses message types defined in 3GPP TS 29.060. See “Creating Security Rules with GTP Services” on page 50 for more information about using path management services in security rules.
Chapter 3 Securing GPRS/UMTS Networks 39 FireWall-1_GX.book Page 40 Tuesday, March 27, 2007 10:03 AM
GTP-Aware Security Policy
Dynamic Configuration of New GTP Messages and Information Elements
FireWall-1 GX 4.0 is aware of all commercially used 3GPP Release-6 GTP messages and Information Elements. It is however possible that new GTP messages (e.g., from 3GPP Release-7) and new GTP Information Elements will be used by GSN equipment in the future, and that these messages and Information Elements will not be known to FireWall-1 GX 4.0 "out of the box". To expedite support for these innovations, new GTP messages and Information Elements can be defined on the FireWall-1 GX 4.0 management station. For details, see “Adding Support for New GTP Messages and Information Elements” on page 71.
40 FireWall-1_GX.book Page 41 Tuesday, March 27, 2007 10:03 AM
Intra-Tunnel Inspection Intra-Tunnel Inspection
In This Section
Introduction to Intra-Tunnel Inspection page 41 GTP Address Anti-Spoofing page 41 Block GTP in GTP page 42 MS to Gn Network Policy Enforcement page 43 APN Domain End User Address Enforcement page 43 Wildcard APN Matching page 44 MS to MS Policy Enforcement page 44
Introduction to Intra-Tunnel Inspection
One of the fundamental features of GTP is to encapsulate underlying (also known as end user or subscriber) protocols within the GPRS/UMTS backbone network. User data is tunneled between GSNs, which means the data payload is encapsulated inside a GTP packet. FireWall-1 GX can inspect the GTP traffic and enforce a Security Policy based on the encapsulated protocols. The following sections deal with the ability of FireWall-1 GX to secure the GPRS network from malicious tunneled data. See also the section “Mobile Subscriber Traffic Security” on page 46, which describes how these capabilities are extended further.
GTP Address Anti-Spoofing
Spoofing is the act of impersonating an end user IP address, usually for malicious purposes. FireWall-1 GX enforces the proper use of end user IP addresses for IPv4 and IPv6 end user headers in tunneled GTP packets (G-PDUs). During tunnel establishment, the end user’s IP address is exchanged. FireWall-1 GX verifies that all G-PDUs that are exchanged using this tunnel use a matching IP address as the user side IP address. During PDP context establishment, an end user IP address is exchanged. This address is stored in the state information table of the tunnel, and is used by the MS in the subsequent G-PDUs. In the GTP dynamic mode, this IP address is allocated by the GGSN and is sent back in the create PDP context reply. In the static mode the subscriber has a constant (static) IP address. In this case the MS sends this IP address to the SGSN, who in turn sends it to the GGSN in the create PDP context request.
Chapter 3 Securing GPRS/UMTS Networks 41 FireWall-1_GX.book Page 42 Tuesday, March 27, 2007 10:03 AM
Intra-Tunnel Inspection
FireWall-1 GX can be configured to inspect each G-PDU on a specific tunnel for malicious use of the end user IP address. For configuration information, see “GTP Intra Tunnel Inspection and Enforcement” on page 65.
GTP Address Anti-Spoofing for IPv4 In IPv4, the end user IP address in the tunneled IP packet’s header is compared to the tunnel's established end user IP address. If the addresses are different, the packet is dropped and logged.
GTP Address Anti-Spoofing for IPv6 In IPv6, the end user IP address in the tunneled IP packet’s header is compared to the tunnel’s established end user IP address. FireWall-1 GX allows the following IPv6 address scenarios: • The prefix of the IPv6 address equals the tunnel's established end user IPv6 prefix. • If the IPv6 address is a Link local address and its identifier equals the tunnel's established end user IPv6 identifier. In addition, FireWall-1 GX allows the following IPv6 address types. • An unspecified address :: (0::0) in T-PDUs originating from an SGSN. • A Multicast IPv6 address in T-PDUs originating from an GGSN. If an IPv6 address appears in any other form, the packet is dropped and logged.
Block GTP in GTP
An SGSN converts mobile user traffic to encapsulated GTP when passing the data to a GGSN. This encapsulation can be exploited by an attacker, whereby a mobile user injects a forged GTP packet, which is in turn encapsulated by the SGSN. This packet could contain an instruction to the GGSN, such as to disconnect users. FireWall-1 GX can detect and block GTP encapsulated inside GTP. For configuration information, see “GTP Intra Tunnel Inspection and Enforcement” on page 65.
42 FireWall-1_GX.book Page 43 Tuesday, March 27, 2007 10:03 AM
Intra-Tunnel Inspection
MS to Gn Network Policy Enforcement
If the IP addresses of the servers on an unprotected Gn network were to become known to a potential attacker, a Mobile User could exploit the fact that the GGSN will route back to the Gn network T-PDU packets with a destination address of the Gn network, and initiate a Telnet session or other forms of unauthorized communications to attack the system. While some GGSNs are capable of blocking this type of attack, others are not. FireWall-1 GX can be configured to deny any attempt by a Mobile User to send data to the Gn network. This is an extension of the Block GTP in GTP feature, i.e., disabling additional potential attacks. MS to Gn network traffic is blocked by creating an APN object to represent the Gn network and then blocking all user traffic from IP addresses belonging to real APNs destined for the Gn network. For configuration instructions, see “Blocking MS to Gn Network Traffic” on page 63.
APN Domain End User Address Enforcement
An Access Point Name (APN) provides routing information for SGSNs and GGSNs. The APN, which is written as a string, contains the identity of the external service requested (the Operator ID) by the MS, and routing information (the Network ID). The two IDs are written something like this: Operator ID: MNC1234.MCC5678.gprs Network ID: example.net Check Point has taken APNs a step further, integrating support of domains with APNs. A domain, consisting of addresses, IP subnets, address ranges or groups thereof, may be configured on an APN object. APN Domains specify the range of IP addresses that are assigned to MSs upon connecting to an APN. For example, you can create one APN called Content_Servers that assigns a range of IP addresses from 10.1.1.1 to 10.1.10.255, and another called Internet, that assigns from a range of 192.168.1.1 to 192.168.10.255. You can also use APN objects to define rules that specify things like: from which networks PDP contexts for enterprise APNs may be created, or to grant the CEO sole access to a specific APN, or to accept Handovers only between specified networks. When a PDP context is created in which the exchanged end user IP address does not belong to the configured domain, the context will be dropped and logged.
Chapter 3 Securing GPRS/UMTS Networks 43 FireWall-1_GX.book Page 44 Tuesday, March 27, 2007 10:03 AM
Intra-Tunnel Inspection
Wildcard APN Matching
To further enhance the ability to define and include certain APN addresses in security rules, FireWall-1 GX allows the use of wildcards in APN matching. For example, you can create an APN object called *.example.gprs that will match APN object strings like 123.example.gprs and abc.example.gprs. For configuration information, see “Creating an APN Object” on page 60 and “GTP Intra Tunnel Inspection and Enforcement” on page 65.
MS to MS Policy Enforcement
FireWall-1 GX can be configured to prevent undesirable traffic between two end users (MSs) simultaneously connected to a GPRS PLMN. There are two variations of this capability: the ability to block intra-tunnel traffic between MSs of the same APN, and the ability to block user plane traffic between MSs of different APNs. It is possible to enforce the correct use of server side IP addresses in tunneled GTP packets (G-PDU). Server side IP addresses refer to the IP address in the G-PDU header not belonging to the mobile subscriber, but to the server (host) with which the MS is communicating. For G-PDUs traveling from the SGSN to the GGSN, the destination IP address of the G-PDU if considered to be the server side address. For G-PDUs traveling from the GGSN to the SGSN, the source IP address of the G-PDU is the server side address. Each G-PDU is inspected for malicious use of server side IP address. The server side IP address in the tunneled IP packet’s header is compared to the relevant predefined APN address domains, and if the address is found to be in one of those disallowed domains for this tunnel, then the packet is dropped and logged. Note the following: • MSs that are connected using tunnels of APNs that are configured to block non-desirable MS to MS traffic are protected.
44 FireWall-1_GX.book Page 45 Tuesday, March 27, 2007 10:03 AM
Intra-Tunnel Inspection
• APN domains that are searched for possible violation of the inter-APN enforcement are global (all defined APN domains, except the one in whose context we are currently inspecting), and therefore they are not dependent on the current APN context. • Only local APNs need to be defined in the system for the purpose of this feature. This feature does not require configuration of roaming providers’ APNs. The reason for this is that packets of PDP contexts belonging to roaming operators’ APNs should never connect to the local GGSN. • Configuration of only local APNs will not interfere in any way with visiting MS traffic since GTP tunnels used by such users belong to external operators’ APNs. See “GTP Intra Tunnel Inspection and Enforcement” on page 65 for information on configuring APN objects.
Chapter 3 Securing GPRS/UMTS Networks 45 FireWall-1_GX.book Page 46 Tuesday, March 27, 2007 10:03 AM
Mobile Subscriber Traffic Security Mobile Subscriber Traffic Security Mobile Subscriber Traffic Security, sometimes referred to as Full Intra Tunnel Inspection, enables real VPN-1 Pro filtering for T-PDU traffic (i.e., decapsulated G-PDU). T-PDU traffic can now be processed by the FireWall-1 inspection engine. This protection is selectable per GTP service, and effectively enables the following security measures for Mobile User traffic: • VPN-1 Pro Security Policy, including optional Anti-Spoofing protection • SmartDefense protections • Web Intelligence protections • Event Logging and Reporting. An IMSI field, which indicates which mobile user is linked to a logged event, can be added to every log generated, thereby eliminating reliance on End User IP address for identification. This feature works by first passing the G-PDU through the regular GTP engine. If the G-PDU matches a GTP service where Mobile Security Traffic filtering has been enabled, the G-PDU is decapsulated and then analyzed with the security measures listed above. If the decapsulated packet is dropped, the outer packet will be dropped as well. Mobile Subscriber Traffic Security can be enforced per GTP service. This means that a Security Policy can be implemented that inspects traffic from certain partners, and not from others. Intra Tunnel Inspection is fully supported, however, only in environments with unfragmented external (G-PDU) and internal (T-PDU) packets, and without overlapping IP addresses. This is a very powerful feature - enabling true and full intra tunnel inspection for user traffic at the Gn and Gp interfaces. To enable these protections on GTP services, see “Customizing GTP Services” on page 59. For the latest information regarding Full Intra Tunnel Inspection, refer to the FireWall-1 GX 4.0 Release Notes, available online at: http://www.checkpoint.com/techsupport/downloads.jsp.
46 FireWall-1_GX.book Page 47 Tuesday, March 27, 2007 10:03 AM
Cellular Specific Services Cellular Specific Services
WAP
Wireless Application Protocol (WAP) is a worldwide standard for providing Internet communications and advanced telephony services on digital mobile phones, pagers, personal digital assistants and other "smart" wireless terminals. FireWall-1 GX includes four predefined UDP services for WAP: • wap_wdp, wireless datagram protocol, is a simplified protocol suitable for low bandwidth mobile stations. It runs over port 9200. • wap_wdp_enc, wireless datagram protocol with wireless transport layer security, is the secure version of wap_wdp. It runs over port 9202. • wap_wtp, wireless transaction protocol, is a light weight transaction oriented protocol suitable for low bandwidth mobile stations that enables a connection mode. It runs over port 9201. • wap_wtp_enc, wireless transaction protocol with wireless transport layer security, is the secure version of wap_wtp. It runs over port 9203. Use these services to allow WAP on your network. For configuration information, see “Adjusting Settings with GUI Dbedit” on page 72.
WAP Redirection FireWall-1 GX can follow the port redirection feature commonly employed with WAP. FireWall-1 GX anticipates the port to which the WAP communication is redirected, and opens just that port for a response.
MMS Over WAP
Through deep packet inspection, FireWall-1 GX can identify Multimedia Short Message Service (MMS) traffic as it travels over WAP. By creating a security rule with an MMS resource, cellular network operators can block or allow MMS transactions. In this way users can be restricted to specific MMS servers, thereby blocking competing MMS providers and foiling attempts to evade billing servers. MMS over WAP security is implemented on a VPN-1 Pro Enforcement Module on the Gi interface. For configuration information, see “Adjusting Settings with GUI Dbedit” on page 72.
Chapter 3 Securing GPRS/UMTS Networks 47 FireWall-1_GX.book Page 48 Tuesday, March 27, 2007 10:03 AM
Configuring Security Configuring Security
In This Section
Creating a Basic Security Policy page 48 Enabling Overbilling Attack Protection page 54 Enforcing a More Granular GTP Security Policy page 58 Using FW SAM to Close PDP Contexts page 69 Adding Support for New GTP Messages and Information Elements page 71 Adjusting Settings with GUI Dbedit page 72
Creating a Basic Security Policy
In This Section
Before You Begin page 48 Creating GSN Objects page 49 Creating a GSN Handover Group page 50 Creating Security Rules with GTP Services page 50
Before You Begin The configuration information included in this chapter refers only to the cellular network features provided by FireWall-1 GX. For information about configuring other aspects of Check Point software, please refer to the NGX (R60) documentation. This chapter on configuring FireWall-1 GX assumes that you have followed the FireWall-1 GX 4.0 Getting Started Guide’s installation instructions, and you are now ready to configure FireWall-1 GX. In brief, you should have: 1. Installed the following: • Management Server • SmartConsole GUI • FireWall-1 GX Module 2. Started the SmartConsole and connected to the Management Server. The initial configuration of GX involves:
48 FireWall-1_GX.book Page 49 Tuesday, March 27, 2007 10:03 AM
Configuring Security
• Creating GSN Objects • Creating a GSN Handover Group • Setting up a Security Policy Follow the steps below to set up basic security, and then continue to “Enforcing a More Granular GTP Security Policy” on page 58 to further customize your security policy.
Creating GSN Objects Use SmartDashboard to create objects representing your GSNs and the GSNs of your roaming partners.
Note - To create GSN objects for your roaming partners, you should obtain a list of their IP addresses.
1. For the Home PLMN, define a Host object for an xGSN. 1. In the Network Objects tree, right click on Nodes, and select New > Host. 2. Enter an identifying name and the xGSN’s IP address. 3. Repeat for each SGSN and GGSN on your network. 2. For the roaming partners, define a Host object for an xGSN. • If the GSN has a single IP address, right click on Nodes, and select New > Host. Enter an identifying name and the xGSN’s IP address. Repeat for each roaming partner SGSN and GGSN. • If the GSN has a range of IP addresses or subnets, right click on Network Objects, and select New > Address Range…. Enter an identifying name and define subnets or IP address ranges to represent the packets coming from or intended for the GSN. Repeat for each roaming partner SGSN and GGSN.
Chapter 3 Securing GPRS/UMTS Networks 49 FireWall-1_GX.book Page 50 Tuesday, March 27, 2007 10:03 AM
Configuring Security
Creating a GSN Handover Group GSN Handover Groups prevent Session Hijacking and enable secure handover, redirection, and multiple GGSN interface support on FireWall-1 GX. You should create Handover Groups for your own GSNs, and for your roaming partners’ GSNs. Typically there will be one GGSN Handover Group and one SGSN Handover Group for each operator. After you define your Handover Groups, include them as source and destination addresses in the rule base in order to allow handover, redirection, and multiple GGSN interface support for the GSNs that you included in the Handover Groups. To define a GSN Handover Group: 1. In the Network Objects tree, right click on Groups, and select New Groups > GSN Handover Group…. 2. Give the group a name, such as SG_Home_HG, where SG stands for SGSN. 3. Add the appropriate GSN objects you created in “Creating GSN Objects” on page 49. To simplify the Security Policy rule base, it is recommended that you: • Define a group consisting of all your home PLMN GSNs. • For each of your partner networks, define two groups: • one consisting of all of its SGSNs or IP address ranges as appropriate • one consisting of all of its GGSNs or IP address ranges as appropriate For more information on Handover Groups, see “Session Hijacking Protection through GSN Handover Groups” on page 37
Creating Security Rules with GTP Services Allow GTP traffic on your network by creating rules using GTP services. There are six pre-defined GTP related services in FireWall-1 GX: • path management — gtp_v0_path_mgmt and gtp_v1_path_mgmt (User Defined services) • tunnel management — gtp_v0_default and gtp_v1_default (Tunnel services and User traffic) • mobility management - gtp_mm_v0_default and gtp_mm_v1_default (Mobile User services)
50 FireWall-1_GX.book Page 51 Tuesday, March 27, 2007 10:03 AM
Configuring Security
A basic Security Policy can be built with these services and the network objects you created in Creating GSN Objects and Creating a GSN Handover Group. Use the Handover Groups you created as the Source and Destination objects.
For the Home PLMN 1. Create a Tunnel Management rule to restrict tunnels and user traffic on your network to your GGSNs from only your SGSNs. 2. Create a Path Management rule to enable path management services between SGSNs and GGSNs.
Note - Use the GSN Handover Groups you created in “Creating a GSN Handover Group” as the Source and Destination objects in the security rules.
Table 3-1 depicts a basic security policy consisting of these two rules.
Table 3-1 Basic Security Policy SRC DEST SERVICE ACTION COMMENT Home PLMN Rules (Rules 1-2) SG_Home_HG GG_Home_HG gtp_v0_default Accept Tunnel Management gtp_v1_default & User Traffic SG_Home_HG GG_Home_HG gtp_v0_path_mgmt Accept Path Management GG_Home_HG SG_Home_HG gtp_v1_path_mgmt
3. If you want to enable Mobility Management between SGSNs, the rule should look something like Table 3-2.
Table 3-2 Mobility Management Rule SRC DEST SERVICE ACTION COMMENT Mobility Management Rule (Rule 3) SG_Home_HG SG_Home_HG gtp_mm_v0_defaul Accept Allow Mobility t Management between gtp_mm_v1_defaul SGSNs t
Chapter 3 Securing GPRS/UMTS Networks 51 FireWall-1_GX.book Page 52 Tuesday, March 27, 2007 10:03 AM
Configuring Security
For the Roaming Partners 4. Add an inbound roaming traffic Tunnel Management rule to allow mobile subscribers to my network to connect from partners’ SGSNs to my GGSNs. 5. Add an outbound roaming traffic Tunnel Management rule to allow mobile subscribers of my roaming partners’ networks to connect to their GGSNs through my local SGSNs. 6. Add a Path Management rule to enable those services over both networks. Roaming partner security rules should look something like Table 3-3.
52 FireWall-1_GX.book Page 53 Tuesday, March 27, 2007 10:03 AM
Configuring Security
Table 3-3 Roaming Partners Rules SRC DEST SERVICE ACTION COMMENT Roaming Partner Rules (Rules 4-6) PartnerA_HG GG_Home_HG gtp_v0_default Accept Roaming for my gtp_v1_default users on partner’s networks SG_Home_HG PartnerA_HG gtp_v0_default Accept Roaming for partner’s gtp_v1_default users on my network PartnerA_HG PartnerA_HG gtp_v0_path_mgm Accept Path management SG_Home_HG GG_Home_HG t across networks GG_Home_HG SG_Home_HG gtp_v1_path_mgm t
Note -
Under Service, specify either the GTP version 0 or the GTP version 1 service, as appropriate to the partner GSN.
In rules with a GTP service, the Reject action rejects the connection and sends the subscriber a "User Not Authenticated" PDU. 7. Install the Security Policy on the FireWall-1 GX Modules. To further refine your Security Policy, see “Enforcing a More Granular GTP Security Policy” on page 58.
Chapter 3 Securing GPRS/UMTS Networks 53 FireWall-1_GX.book Page 54 Tuesday, March 27, 2007 10:03 AM
Configuring Security
Enabling Overbilling Attack Protection
In This Section
If the Gi and GX Firewalls are Managed by One Management Server page 54 If the Gi and GX Firewalls are Managed by Different Management Servers page 55 Testing Overbilling Protection page 58
Protection against Overbilling attacks can be implemented quickly and simply on networks with both a FireWall-1 GX Enforcement Module and a FireWall-1 Enforcement Module on the Gi interface. FireWall-1 GX resolves the vulnerability inherent in the GTP protocol by sending a clean state message to the FireWall-1 Enforcement Module whenever a PDP context is deleted. Configuration of this feature differs between systems where the Gi and GX firewalls are managed by the same management server, and those managed by different management servers.
If the Gi and GX Firewalls are Managed by One Management Server To protect your GPRS/UMTS network from an Overbilling attack, do the following: 1. Create an Overbilling Group object: 1. From the Network Object tree, right click on Group, then select New Groups > Simple Group. 2. Name the group (e.g., overb_gw_group). 3. Select and add to the group the enforcement modules that will receive the clean state message whenever a PDP context is deleted. 4. Click OK. 2. Enable Overbilling attack protection: 1. From the Network Object tree, double click the Gateway object of a FireWall-1 GX module. 2. Select the FireWall-1 GX tab. 3. Check the Send “clean state” request on each GTP tunnel Deactivation property. 4. Select as the Target the group you created in step 1.
54 FireWall-1_GX.book Page 55 Tuesday, March 27, 2007 10:03 AM
Configuring Security
5. Repeat for each FireWall-1 GX module. 3. Reinstall the security policy to each affected module.
If the Gi and GX Firewalls are Managed by Different Management Servers Enabling Overbilling protection in environments with multiple management servers is a more complicated procedure. In addition to steps 1-3, you must make modifications to the management and enforcement modules for both FireWall-1 and FireWall-1 GX, including: • Add a rule to the rule base that allows SAM traffic from the FireWall-1 GX Module to the FireWall-1 Module • Set SAM traffic to use SSL • Establish a trust relationship between the enforcement modules Follow the steps below precisely, and then test the solution according the instructions in “Testing Overbilling Protection” on page 58.
On the GX Management: 1. On the GX management, use SmartDashboard to define each Gi member as an Externally Managed Gateway. 1. Enter the IP address for the object, and check the Firewall-1 checkbox. There is no need to define the exact topology of each externally managed Gi module/member. In the case of a Gi cluster, the IP address used should be the unique IP of the cluster member, and not the IP address of the cluster itself. 2. Insert the Gi members into the Overbilling group
On the GX Modules: 1. Set SAM to use SSL on FireWall-1 GX Modules by updating the file $CPDIR/conf/sic_policy.conf. 1. Use a text editor to open the file, and search for the line [Outbound rules]. 2. Insert a new line with the following format: ANY ; "DN" ; ANY ; sam ; ssl "DN" is the unique name of each Gi module/member, as it appears in the Gi SmartDashboard, on the main page of the Gi object.
Chapter 3 Securing GPRS/UMTS Networks 55 FireWall-1_GX.book Page 56 Tuesday, March 27, 2007 10:03 AM
Configuring Security
For example, if the name of the Gi management is gi-mgmt, and the name of one of the Gi modules/members is gi-mod1, the DN would be something like "CN=gi-mod1,O=gi-mgmt..7au2cw". And so, the line in sic_policy.conf would look like: ANY ; "CN=gi-mod1,O=gi-mgmt..7au2cw" ; ANY ; sam ; ssl
Note - The double quotes in the line are mandatory. Be sure to use double quotes ("), and not single quotes (') when writing the line in sic_policy.conf.
For every additional Gi module/member you wish to use, add additional lines below the lines you have just added. Be sure to use the correct DN for each new Gi module. 2. Establish a trust relationship between enforcement modules by running the following command on each GX module/member: fw putkey -ssl -p [secret] [IP of Gi module/member] [secret] is any string that will be used in the first authentication between the GX and the Gi modules. The string used here must match the string used in the putkey command which you run on the Gi module/member. For additional Gi modules/members, run the fw putkey command again with the IP address of that member. Make sure that in all cases you use the unique IP address of each cluster member, and not the IP address of the cluster itself. 3. Run cpstop and cpstart on all GX modules/members on which you have edited sic_policy.conf for the changes to take effect.
On the Gi Management: 1. Define a node object using the IP address of the FireWall-1 GX cluster. Note that you need to use the GX cluster IP address associated with the interface facing the Gi module/cluster. 2. Define a rule allowing FW1_sam traffic from the GX cluster IP address to the Gi modules/members.
Table 3-4 Source Destination Service Action FireWall-1 GX Module FireWall-1 Module FW1_sam Accept 3. Install the policy on the Gi modules/members.
56 FireWall-1_GX.book Page 57 Tuesday, March 27, 2007 10:03 AM
Configuring Security
On the Gi Modules: 1. Set SAM to use SSL on FireWall-1 Modules by updating the file $CPDIR/conf/sic_policy.conf. 1. Use a text editor to open the file, and search for the line [Inbound rules]. 2. Insert a new line with the following format: ANY ; "DN" ; ANY ; sam ; ssl
“DN” is the unique name of each GX module/member, as it appears in the GX SmartDashboard, on the main page of the GX object. For example, if the name of the GX management is gx-mgmt, and the name of one of the GX modules/members is gx-mod1, the DN would be something like "CN=gx-mod1,O=gx-mgmt..7au2cw". And so, the line in sic_policy.conf would look like: ANY ; "CN=gx-mod1,O=gx-mgmt..7au2cw" ; ANY ; sam ; ssl
Note - The double quotes in the line are mandatory. Be sure to use double quotes ("), and not single quotes (') when writing the line in sic_policy.conf.
For every additional GX module/member you wish to use, add additional lines below the previous lines you've added. Be sure to use the correct DN for each new GX module. 2. Establish a trust relationship between enforcement modules by running the following command on each Gi module/member: fw putkey -ssl -p [secret] [IP of Gx module/member] Where [secret] is any string that will be used in the first authentication between the GX and the Gi modules. The string used here must match the string used in the putkey command which you run on the GX module/member. For additional GX modules/members, run the fw putkey command again with the IP address of that member. Make sure that in all cases you use the unique IP address of each member, and not the IP address of the shared cluster. 3. Run cpstop and cpstart on all Gi modules/members on which you have edited sic_policy.conf for the changes to take effect.
Chapter 3 Securing GPRS/UMTS Networks 57 FireWall-1_GX.book Page 58 Tuesday, March 27, 2007 10:03 AM
Configuring Security
Testing Overbilling Protection Enabling Overbilling protection for a clustered environment is complex, and is prone to mistakes. It is therefore highly recommended to perform several tests to make sure the configuration was done correctly. 1. Delete a GTP tunnel. On the GX management, examine the logs in SmartView Tracker and verify that the GTP tunnel deletion was done through a specific GX member. 2. On the Gi management, verify that there is a log from each Gi module/member reporting that a SAM rule has been added. 3. Delete a GTP tunnel through the other GX members. In most cases, you will need to perform a failover in the GX cluster. 4. Again verify that there is a log from each Gi module/member reporting that a SAM rule has been added.
Enforcing a More Granular GTP Security Policy
In This Section
Customizing GTP Services page 59 Creating an APN Object page 60 Using APNs in a Security Policy page 62 Customizing WAP and MMS Over WAP page 63 GTP Intra Tunnel Inspection and Enforcement page 65 GTP PDU Integrity Tests page 66 Secure Connectivity Features page 67 Limiting Signaling Rates page 68
Through the use of GTP service filters and APN objects, you can create security rules that allow GTP traffic only within the parameters that you specify. GTP-aware filters provide the ability to limit the creation of PDP contexts to traffic that matches specific parameters that you define.
58 FireWall-1_GX.book Page 59 Tuesday, March 27, 2007 10:03 AM
Configuring Security
Customizing GTP Services FireWall-1 GX allows you to build your own GTP service filters, which can provide a more granular GTP security policy. When you create a new GTP service, you can set exactly which prefixes or other identifiers to allow onto your network. While you can modify the pre-defined GTP services gtp_v0_default and gtp_v1_default, it is recommended that you create a new service. As such, the following GTP customization example begins with the steps required to create a new service. To define a new GTP service as follows: 1. In the Services tree, right click on GTP > New GTP… > GTP V0… or GTP V1.. 2. Give the new GTP service filter a name, such as my_gtp_v1.
Note - The port numbers of the GTP services cannot be modified.
3. Click Advanced. The Advanced GTP Service Properties window appears (see Figure 3-1). Figure 3-1 Advanced GTP Service Properties window
4. Define the parameters of the service. For each of the first five parameters, specify a value for the parameter, or select Any.
Chapter 3 Securing GPRS/UMTS Networks 59 FireWall-1_GX.book Page 60 Tuesday, March 27, 2007 10:03 AM
Configuring Security
• IMSI Prefix specifies a subscriber identity prefix. The subscriber identity prefix is usually of the form Country and Operator, for example, 23477 (where 234 is the MCC and 77 is the MNC). • Access Point Name specifies an APN object. An example of an APN is internet.mnc55.mcc243.gprs, or example.com. For APN configuration information, see “Creating an APN Object” on page 60. • Selection Mode specifies a selection mode indicating the origin of the APN that appears in the PDP context request. • MS-ISDN Prefix specifies an MS-ISDN prefix (for example, 447788). • LDAP Group specifies an LDAP group, sorted by two main attributes. • according to IMSI or MS-ISDN identifies whether a user belongs to a specific LDAP group by IMSI or MS-ISDN. Furthermore, the service can be customized to perform the following actions on matching GTP traffic: • Allow usage of static IP addresses allows mobile subscribers with pre-assigned IP addresses to make a connection. While IP addresses are usually allocated by the GGSN, some users may have static, pre-assigned IP addresses. The default is to allow such paths. When this option is set, PDP context activation will be enabled in static mode as well. • Accelerate GTP user traffic (with SecureXL) accelerates GTP user data (G-PDUs) on matched traffic. All security measures are enforced when using acceleration. • Apply FireWall-1 Security on User Traffic causes all mobile user traffic encapsulated in G-PDUs to be inspected by FireWall-1 & SmartDefense stateful inspection. • Add IMSI field to logs generated by User Traffic inserts the value in the IMSI field for any log generated by mobile user data, linking the log to the mobile user. 5. Add a rule in the rule base using this service, and make sure the rule is above all other GTP-based rules.
Creating an APN Object It is possible to control which end user IP addresses can access your network by enforcing APN domains. This is useful in environments where some or all of the local APNs have a pre-defined unique domain of end user IP addresses. To create an APN object:
60 FireWall-1_GX.book Page 61 Tuesday, March 27, 2007 10:03 AM
Configuring Security
1. Right click on Network Objects, select New > Access Point Name…. The APN Properties window appears (see Figure 3-2). Figure 3-2 APN Properties window
2. Name the APN. 3. Specify an APN string that identifies the APN, for example internet.mnc55.mcc243.gprs, or example.com. 4. Define a GTP service that is restricted to the APN you defined in the previous step. Define the new GTP service in the GTP Service Properties window and set its properties in the Advanced GTP Service Properties window (Figure 3-1 on page 59). If the end user’s IP address does not match the APN string, then PDP context create response or request messages are dropped with the error message IP is not in the APN domain . To match more than one string to an APN rule: 1. Create an APN. 2. Include a wildcard in its name, such as *.example.gprs. An APN with this name will match strings with names like 123.example.gprs and abc.example.gprs. Supported wildcards are listed in the following table:
Table 3-5 Symbol Stands for * any number of any characters ? any 1 character
Chapter 3 Securing GPRS/UMTS Networks 61 FireWall-1_GX.book Page 62 Tuesday, March 27, 2007 10:03 AM
Configuring Security
Using APNs in a Security Policy Suppose two APNs are defined as follows:
Table 3-6 APN End User Domain example Name IP address range Block MS to MS traffic Block MS to MS traffic between this and other within this APN End APN End User Domains User Domain APN1 10.1.1.0 - checked checked 10.1.1.24 APN2 20.1.1.0 - not checked not checked 20.1.1.24
G-PDUs encapsulated in PDP-contexts using APN_Jamaica with server IPs from the range 10.1.1.0/24 or 20.1.1.0/24 will be dropped. No restriction will be placed on G-PDUs belonging to APN_Spain. Specifically, a packet sent from a server to an MS with source IP 10.1.1.4 and destination IP 20.1.1.7 is allowed. For more information on configuring APNs, see “GTP Intra Tunnel Inspection and Enforcement” on page 65.
62 FireWall-1_GX.book Page 63 Tuesday, March 27, 2007 10:03 AM
Configuring Security
Blocking MS to Gn Network Traffic To deny MS to Gn traffic, do the following: 1. Define an APN object for the Gn network (the APN string value in this case in not important). 2. Enable the property Enforce End User Domain and select the domain with the range of IP addresses of the Gn network you want to protect. 3. Enable the property Block MS to MS traffic between this and other APN End User domains on this and all other APNs defined.
Customizing WAP and MMS Over WAP In order to enabling MMS-aware services over your network, a FireWall-1 GX Enforcement Module is required on the Gi interface.
To allow MMS over WAP and WAP Redirection: 1. Create an MMS Resource. 1. On the Resources tab, right click Resources, and select New > MMS…. 2. Give the new MMS Resource a name, such as mms_rsc_1. 3. Set the Action you want to occur when this resource is matched to Accept, as well as the tracking policy.
Note - When creating a security rule using an MMS Resource, the Action column of the rule must be set to Accept. However, MMS Resources themselves may be set to Drop MMS transactions. In this case, set the Action property to Drop.
2. Add a security rule to the rule base: 1. Insert a new line in the rule base. 1. On the Service column, right click and select Add with Resource…. 2. Select either wap_wdp or wap_wtp, and from the Resource drop down list select the MMS Resource you created in step 1. Click OK. 3. Set the Action to Accept. The rule should look something like this:
Table 3-7 Source Destination Service Action any any wap_wdb > Accept mms_rsc_1
Chapter 3 Securing GPRS/UMTS Networks 63 FireWall-1_GX.book Page 64 Tuesday, March 27, 2007 10:03 AM
Configuring Security
4. Make sure the rule is above any other MMS traffic rules.
To accept WAP but deny MMS over a certain connection: Follow the previous example’s instruction, with the exception of the Action setting in step 1, c. Set this property to Deny.
To create an MMS Billing Server rule: 1. Create an MMS Server object: 1. Right click on Network Objects, then select New > Node > Host…. 2. Give the MMS Server a name and enter its IP address. 3. Click OK. 2. Add a rule to the rule base: 1. Set Source as Any. 2. Set Destination as your MMS billing server, and then right click the object and select Negate Cell. This means the transaction will only be allowed if it is not an MMS transaction. 3. Set the Service as your MMS resource. 4. Set Action as Accept. The rule should look something like this:
Table 3-8 Source Destination Service Action any MMS_Server wap_wdb > Accept (negated) mms_rsc_1
64 FireWall-1_GX.book Page 65 Tuesday, March 27, 2007 10:03 AM
Configuring Security
GTP Intra Tunnel Inspection and Enforcement
In This Section
Defining Access Using APN Objects page 65 Enforce GTP Anti-Spoofing page 65 Block GTP in GTP page 65
Defining Access Using APN Objects To define Intra Tunnel enforcement by end user domain: 1. Create an APN object as detailed in “Creating an APN Object” on page 60, or edit an existing APN object. 2. Enable Enforce End User Domain to block user traffic that is outside a range of defined IP addresses. 3. Choose the relevant End User Domain from the drop down list. 4. Enable Block MS to MS traffic between this and other APN End User domains to drop and log intra-tunnel traffic between two MSs with IP addresses other than the ones specified in this APN End User Domain drop-down list. 5. Enable Block MS to MS traffic within this APN domain to drop and log intra-tunnel traffic between two MSs with IP addresses that match the addresses specified in this APN End User Domain drop-down list. For conceptual information, see “APN Domain End User Address Enforcement” on page 43.
Enforce GTP Anti-Spoofing GTP Anti-Spoofing drops G-PDUs that do not use the end user IP address agreed upon in the PDP context activation process. The setting Enforce GTP Anti-Spoofing is located in the FireWall-1 GX tab of the Global Properties window (see Figure 3-3). Its default setting is enabled.
Block GTP in GTP Block GTP in GTP drops GTP packets encapsulated inside GTP tunnels. The setting is located in the FireWall-1 GX tab of the Global Properties window (see Figure 3-3). Its default setting is enabled.
Chapter 3 Securing GPRS/UMTS Networks 65 FireWall-1_GX.book Page 66 Tuesday, March 27, 2007 10:03 AM
Configuring Security
Figure 3-3 FireWall-1 GX — Global Properties window
GTP PDU Integrity Tests The following GTP PDU Integrity checks are available on the FireWall-1 GX tab of the Global Properties window: • Verify Flow Labels checks that each packet’s flow label matches the flow labels defined by GTP signaling. This option is relevant for GTP version 0 only. The default setting is unchecked. • G-PDU seq number check with a maximum deviation of a value set here. Sequence checking is enforced, but an out-of-sequence G-PDU is accepted if the difference between its sequence number and the expected sequence number is less than or equal to the maximum deviation. The default setting is unchecked. The following related parameters take effect only if G-PDU sequence number check with a maximum deviation of is enabled, and can be configured using the GuiDBedit Database Tool:
66 FireWall-1_GX.book Page 67 Tuesday, March 27, 2007 10:03 AM
Configuring Security
• gtp_sequence_deviation_drop — Drop all out-of-sequence packets. The default setting is FALSE. • gtp_sequence_deviation_alert — Generate a log when an out-of-sequence packet is encountered. The default setting is TRUE.
Secure Connectivity Features The following features are concerned with connectivity: • Allow GGSN Replies From Multiple Interfaces allows GTP signaling replies from an IP address different from the IP address to which the requests are sent. The default setting is checked. When this option is enabled, be sure to protect against Session Hijacking through the use of Handover Groups. For information on setting up Handover Groups, see “Creating a GSN Handover Group” on page 50. • Enable Reverse Connections accepts PDUs from the GGSN to the SGSN on a previously established PDP context even if these PDUs are sent over ports that do not match the ports of the established PDP context. This is available for the following PDUs: • G-PDUs • Delete PDP context requests • GTP version 1 update PDP context requests • GTP error indication messages The default setting is enabled. These features are located in the Other section of the FireWall-1 GX tab in Global Properties. • Allow usage of static IP address allows packets from MSs with static IP addresses to activate PDP contexts. While IP addresses are usually allocated dynamically by GGSNs, some mobile subscribers have static, pre-assigned IP addresses. To maintain maximum security from static IP-based attacks, preserve the default setting of disallowing traffic from static IP addresses. You can, however, accept traffic with static IP addresses in a selective way, through the use of a GTP service filter. See “Enforcing a More Granular GTP Security Policy” on page 58 for more information about GTP service filters. This connectivity feature is configured on the Advanced GTP Services tab, and the default setting is unchecked.
Chapter 3 Securing GPRS/UMTS Networks 67 FireWall-1_GX.book Page 68 Tuesday, March 27, 2007 10:03 AM
Configuring Security
Limiting Signaling Rates • Allow one GTP Echo on each path every x seconds sets the interval at which GTP Echo requests are allowed per path. Echo requests exceeding this rate will be dropped and logged. You can disable the signaling rate limit, and thereby accept all Echo requests, by entering 0. The default setting is 1. • GTP Signaling rate limit sampling interval sets the interval for signal packet rate sampling. The default setting is 60 seconds. • Enforce GTP Signal packet rate limit sets the number of PDUs allowed per second. PDU traffic exceeding this rate will be dropped and logged. This feature protects local GSNs from Denial of Service attacks by restricting the signaling rate that can be sent to a local GSN. It is configured on the FireWall-1 GX page of each GSN network object. If checked, GTP signaling PDUs destined to this GSN above the specified rate are blocked and dropped. The default rate is 2048. Consider the following example: The rate limit sampling interval is set to the default rate of 1 second and the network object has enforced a GTP signal packet rate limit of the default of 2048 PDU per second. Then sampling will occur once per second and will allow 2048 signaling PDUs between two successive samplings. The following related parameters can be set using the GUI Dbedit Database Tool: • gtp_rate_limit_drop drops packets that exceed the configured rate. The default value is TRUE. • gtp_rate_limit_alert issues an alert when packets exceed the configured rate. The default value is TRUE.
68 FireWall-1_GX.book Page 69 Tuesday, March 27, 2007 10:03 AM
Configuring Security
Using FW SAM to Close PDP Contexts
The fw sam command in FireWall-1 GX has a new type of generic
Table 3-9 FireWall -1 GX Content Filter Arguments Key Value Meaning service gtp Service of ‘gtp’ indicates that the request applies only to connections that go through the gtp tunnel between the SGSN and the GGSN machines. All Firewall - 1 GX requests must include this argument. imsi String of International Mobile Subscriber Identity, a unique numbers number identifying a particular mobile subscriber which comprises the MCC, (Mobile Country Code), MNC (Mobile Network Code) and MSIN (Mobile Subscriber Identification Number. msisdn String of Mobile Subscriber phone number. numbers apn String of up to Access Point Name. 115 characters
Chapter 3 Securing GPRS/UMTS Networks 69 FireWall-1_GX.book Page 70 Tuesday, March 27, 2007 10:03 AM
Configuring Security
Table 3-9 FireWall -1 GX Content Filter Arguments tunl_dst Dotted decimal Destination IP address of the tunnelled IP address connection tunl_dp Short integer Destination port of the tunnelled connection ort represented as string tunl_pro Short integer Destination protocol of the tunnelled connection to represented as string
Note - Names and values are case sensitive.
Table 3-10 lists the different types of FireWall-1 GX requests, each represented with a certain combination of key=value pairs. Table 3-10 Firewall - 1 GX request types
• Request Type Includes Notes Destination APN Network Request User IMSI and/or MSISDN Identification User to 1) IMSI and/or MSISDN The 3 tunnelled connection Destination 2) One or more of the arguments of tunl_dst, following destination tunl_dport and tunl_proto, arguments: must come together • APN The Firewall - 1 GX module does • All of the following not close open tunnels. tunnelled connection Therefore, a request that arguments: includes tunl_dst, tunl_dport tunl_dst, and tunl_proto may not be used tunl_dport and with -J and -I options. tunl_proto
70 FireWall-1_GX.book Page 71 Tuesday, March 27, 2007 10:03 AM
Configuring Security
Note - It is not possible to monitor the GX requests with the -M option. Note - Names and values are case sensitive.
The following example demonstrates the use of the generic criteria for sending a FireWall-1 GX request: fw sam –f monica-gx –i generic service=gtp imsi=055123456 tunl_dst=10.100.100.1 tunl_dport=80 tunl_proto=6
This call inhibits connections on FireWall-1 GX object monica-gx from a user with IMSI number 051123456 connecting over HTTP to server 10.100.100.1
Adding Support for New GTP Messages and Information Elements
New TLV Information Elements and/or GTP Message Types can be added to the list of messages recognized by FireWall-1 GX, thereby allowing them to pass through the firewall. To define the new Elements or Types, add the relevant line(s) to the end of file $FWDIR/lib/gtp.def on the Management Server: gtp_additional_types = {new Message Types}; gtp_additional_elements = {new Information Elements};
Each line should list the ID (number) of the additional Message Types and/or Information Elements, respectively. For example: if you define the following: gtp_additional_types = {71, 72, 73}; gtp_additional_elements = {239, 240, 241};
Message Types 71, 72 and 73 and Information Elements 239, 240 and 241 will be allowed to pass through the system. As long as their GTP headers are valid, the new Message Types will pass irrespective of their content. The new Information Elements defined may be included in any Message Type, and can appear in any location in the sequence of Information Elements in the message. You may add just new Message Types, or just new Informational Elements, or both.
Chapter 3 Securing GPRS/UMTS Networks 71 FireWall-1_GX.book Page 72 Tuesday, March 27, 2007 10:03 AM
Configuring Security
Adjusting Settings with GUI Dbedit
There are a number of settings within FireWall-1 GX that do not have a Graphical User Interface. The value of these properties may be changed using the GUI Dbedit Database Tool. Global settings are detailed in Table 3-11, and settings by module are detailed in Table 3-12.
Table 3-11 Global Settings property meaning defau lt gtp_sequence_deviation_d If T-PDU sequence number check with a maximum FALSE rop deviation of is enabled (Figure 3-3 on page 66), drop out-of-sequence packets. gtp_sequence_deviation_a If T-PDU sequence number check with a maximum TRUE lert deviation of is checked (Figure 3-3 on page 66), a log will be generated when an out-of-sequence packet is encountered. gtp_allow_recreate_pdpc When a Create PDP Context arrives at the OPEN FireWall-1 GX Module and the tunnel already exists, the question whether this new Create should be allowed depends on whether the FireWall-1 GX Module is configured to be strict or open with regard to this scenario. For GTP Version 1, a tunnel is composed of four TEIDs. If any one of the four TEIDs of a new create attempt is already in use (for the same SGSN-GGSN pair), this will be considered a recreate. If gtp_allow_recreate_pdpc is set to open, the recreate is allowed. The Create Log generated for the new tunnel will include a remark in the info field stating “reusing TEID”. gtp_rate_limit_drop A packet exceeding the allowed rate is dropped by TRUE default. To accept such packets, change the property’s value to FALSE. gtp_rate_limit_alert If a packet exceeds the allowed rate, a log is TRUE issued. To cancel such logs, change the property’s value to FALSE. gtp_chk_hdr_len If TRUE, FireWall-1 GX verifies the length written in TRUE the GTP header.
72 FireWall-1_GX.book Page 73 Tuesday, March 27, 2007 10:03 AM
Configuring Security
Table 3-11 Global Settings property meaning defau lt gtp_delete_upon_error If TRUE, an error on a tunnel causes the tunnel to FALSE be deleted from the FireWall-1 GX tables. gtp_echo_requires_path_i If TRUE, FireWall-1 GX verifies that at least one FALSE n_use tunnel between the SGSN and GGSN participating in the echo is established. gtp_loggrace FireWall-1 GX eliminates similar logs indicating 10 error each gtp_loggrace seconds. gtp_max_req_retransmit Only gtp_max_req_retransmit retransmissions of 5 the same request are allowed. gtp_monitor_mode If TRUE, FireWall-1 GX will not drop any GTP traffic FALS even if it was evaluated as malicious, illegal, etc. E The GX logging system will however log the intended drop as it would in regular operation mode. This enables the operator to realize the impact of GX on the system without actually enforcing that impact. gtp_log_additional_fields If TRUE, additional Information Elements are added FALS to the logs of GTP traffic. E
Table 3-12 Settings per Module Table 3-13 property meaning defau lt gtp_pending_hashsize Sets the hash size of the gtp_pending kernel table, 65536 which is used to store pending GTP signalling requests. This value must be a power of 2. gtp_pending_limit Sets the maximum number of entries stored in the 25000 gtp_pending kernel table. gtp_pending_timeout Sets the timeout of entries in the gtp_pending 40 kernel table. secon ds
Chapter 3 Securing GPRS/UMTS Networks 73 FireWall-1_GX.book Page 74 Tuesday, March 27, 2007 10:03 AM
Configuring Security
Table 3-13 gtp_sam_close_upon_delete A boolean parameter used to enable sending a TRUE delete PDP context request message to GSNs when a tunnel is deleted using the SAM API or when PDP contexts expire. gtp_tunnels_hashsize Sets the hash size of the gtp_tunnels kernel table, 65536 which is used for storing active PDP contexts. This value must be a power of 2. gtp_tunnels_limit Sets the maximum number of entries stored in the 25000 gtp_tunnels kernel table. gtp_tunnels_timeout Sets the timeout of entries in the gtp_tunnels 3600 kernel table. secon ds
74 FireWall-1_GX.book Page 75 Tuesday, March 27, 2007 10:03 AM
Chapter 4 Using QoS to Manage GTP Bandwidth
In This Chapter
Introduction to GTP Bandwidth Management using QoS page 76 How it Works page 77 Unsupported Features page 79 Configuring QoS with FireWall-1 GX page 80
75 FireWall-1_GX.book Page 76 Tuesday, March 27, 2007 10:03 AM
Introduction to GTP Bandwidth Management using QoS Introduction to GTP Bandwidth Management using QoS FireWall-1 GX is now able to allocate bandwidth to subscribers of partner networks by setting QoS rules for the partner networks. By leveraging QoS capabilities, FireWall-1 GX can be used to limit a certain bandwidth for user traffic per PDP Context. Different bandwidth criteria can be set for traffic from different partners. Each mobile user of a partner network receives the identical bandwidth, as set by the QoS rule. Beside adding support for QoS on data packets (T-PDUs), FireWall-1 GX has improved the method of identifying the home network of mobile users. The user's home network can be specified via GTP service property (IMSI, APN or MS-ISDN), replacing the need to specify GGSN and SGSN IP addresses.
76 FireWall-1_GX.book Page 77 Tuesday, March 27, 2007 10:03 AM
How it Works How it Works FireWall-1 GX 4.0 can leverage Check Point QoS to manage the GTP bandwidth of GPRS/EDGE/UMTS mobile user sessions. When a mobile user establishes a PDP Context, Check Point QoS sets the rate for the GTP session according to predefined rules. Different bandwidth criteria can be set for different partner traffic. Figure 4-1 illustrates such a deployment: Figure 4-1 Check Point QoS allocating GTP bandwidth to different partner operators
A mobile user session is defined as the sum of all GTP traffic within a PDP Context that a user generates during an active connection. In cases where a handset supports multiple PDP contexts, each PDP context is assigned its own bandwidth limit. When a T-PDU packet arrives, FireWall-1 GX 4.0 identifies to which PDP-Context it belongs (via the GTP service that the packet is matched on), and allocates the bandwidth as configured in the QoS Rule Base. QoS rules are defined in the QoS tab of SmartDashboard. Figure 4-2 shows a typical set of rules. Figure 4-2 Sample QoS rules
Source Destination Service Action Track Comment Any Any GTP_v1_op_A PC limit Log Operator A Roamers in 128KBps Home network Any Any GTP_v1_op_B PC limit Log Operator B Roamers in 64KBps Home network By setting the Action to PC limit 128 KBps (per connection), each PDP Context established with OperatorA's Gn network is limited to 128 Kbps.
Chapter 4 Using QoS to Manage GTP Bandwidth 77 FireWall-1_GX.book Page 78 Tuesday, March 27, 2007 10:03 AM
How it Works
With QoS, an operator can allocate or limit a specified bandwidth per PDP Context in the Gp interface according to agreement with partner operators. For configuration instructions, see “Configuring QoS with FireWall-1 GX” on page 80. For a complete discussion of QoS capabilities and configuration, see the Check Point QoS User Guide.
78 FireWall-1_GX.book Page 79 Tuesday, March 27, 2007 10:03 AM
Unsupported Features Unsupported Features The following features are not supported: • Limit per rule and Guarantee, only per connection limit (it is per tunnel actually) • NAT with GTP • QoS VPN with GTP • QoS logs with GTP • QoS Express Mode with GTP • QoS limits smaller than 10 KBps • Accounting • DiffServ
Chapter 4 Using QoS to Manage GTP Bandwidth 79 FireWall-1_GX.book Page 80 Tuesday, March 27, 2007 10:03 AM
Configuring QoS with FireWall-1 GX Configuring QoS with FireWall-1 GX 1. Using SmartDashboard, enable QoS on the FireWall-1 GX gateway: a. Edit the FireWall-1 GX object's properties, and under Check Point Products, enable QoS. b. Go to the Topology tab, select the relevant interface > Edit > QoS tab, and set the Inbound and Outbound bandwidth rate for the gateway. Click OK. 2. Create security rules with GTP services in the Security Rule Base. Note - Every GTP service that is placed in the QoS Rule Base must have a corresponding rule in the Security Rule Base. 3. Create QoS rules in the QoS Rule Base using the desired GTP services. GTP services can be dragged from the Services tab of the Objects tree to the Service column of each QoS rule. Leave the Source and Destination fields of each QoS rule as Any. Note - In the QoS Rule Base, there can only be one GTP service per rule. If you have the same limit on more then one service, create a separate rule for each of the services. 4. Right-click in the Action field of each QoS rule and select Edit Properties. 5. In the QoS Action Properties window, set the Action Type as Advanced, enable and configure the Rule Weight and Per connection limit properties for the desired GTP service(s). 6. Save the changes and install policy to the FireWall-1 GX gateway.
80 FireWall-1_GX.book Page 81 Tuesday, March 27, 2007 10:03 AM
Chapter 5 Monitoring GPRS Network Security
Introduction to Monitoring GPRS Network Security page 82 GTP Tracking Logs and Alerts page 83 Eventia Reporter Reports page 85 Monitor-Only Mode page 88 SNMP Extensions for GTP Statistics page 89 Configuring Monitoring page 90
81 FireWall-1_GX.book Page 82 Tuesday, March 27, 2007 10:03 AM
Introduction to Monitoring GPRS Network Security Introduction to Monitoring GPRS Network Security In order to effectively manage your network and make informed decisions, you need to gather information on the network’s traffic patterns. If you experience connectivity or security related problems, you need to be able to identify changes in the traffic. FireWall-1 GX provides a set of tools that address the special needs of cellular networks.
82 FireWall-1_GX.book Page 83 Tuesday, March 27, 2007 10:03 AM
GTP Tracking Logs and Alerts GTP Tracking Logs and Alerts FireWall-1 GX records cellular-specific information of GTP signaling activity, including APN, IMSI, Selection Mode, GSN addresses and more. The information recorded in these logs can help you determine why certain GTP traffic may be dropped or rejected, and to decide if whether to adjust the Security Policy to accept that traffic. For more information about understanding logs and using SmartView Tracker, see the SmartCenter book. For information regarding cellular-specific error messages that describe why GTP traffic was dropped or rejected, see “Log Messages” on page 91. The FireWall-1 GX GTP Inspection Module generates a wide range of detailed security alerts in the event of protocol and Security Policy violations, including PDU details, network information and protocol violation type. FireWall-1 GX also provides GTP-specific alerts on malformed packets and malicious activity. See “Configuring Monitoring” on page 90 for information on setting the alert type.
Note - As in all security rules, you must set the tracking option of the rule to Log if you want to record GTP activity.
Recording GTP Data from Unmatched PDUs
FireWall-1 GX can record GTP traffic that is not matched by a GTP rule in the rule base. Normally, traffic that is not matched is logged in the general SmartView Tracker log as a simple Drop. FireWall-1 GX provides a tool for capturing this data with the special GTP-related fields that can help to discover the cause of these drops. To configure this feature, see Produce extended log on unmatched PDUs in “Configuring Monitoring” on page 90.
GTP Accounting
By setting a GTP user traffic rule to Log, FireWall-1 GX generates a log entry for every terminated PDP context that matches on the rule. The log records the total number of user packets (n_pdu) and bytes (n_byte) transferred in the user plane during the PDP context. FireWall-1 GX issues logs for the following events: • PDP context delete • Tunnel expiration • Tunnel recreation • Active Module goes down (when in High Availability mode)
Chapter 5 Monitoring GPRS Network Security 83 FireWall-1_GX.book Page 84 Tuesday, March 27, 2007 10:03 AM
GTP Tracking Logs and Alerts
Excessive Logs Protection
Due to the small packet nature of cellular communications, FireWall-1 GX records a vast amount of data each day, far more than a typical Check Point firewall. This data collection is essential to accurately diagnose network status, and to troubleshoot network errors. This intensive logging activity could make some systems more vulnerable to Denial of Service (DoS) attacks. FireWall-1 GX protects against this type of attack by setting a similar logging threshold, above which it does not generate similar logs. This feature is configurable. See gtp_loggrace in “Adjusting Settings with GUI Dbedit” on page 72. The default is every 10 seconds.
84 FireWall-1_GX.book Page 85 Tuesday, March 27, 2007 10:03 AM
Eventia Reporter Reports Eventia Reporter Reports Check Point Eventia Reporter delivers a user-friendly solution for monitoring and auditing the vast amount of data that crosses the firewall each day. By analyzing and consolidating log files into easy-to-read reports, Eventia Reporter allows you to see, for example, unusual spikes in dropped PDUs, indicating a possible problem. You can then use this information as a starting point to drill down through the logs to correct the problem. The FireWall-1 GX version of Eventia Reporter is enhanced to include cellular specific data like the total number of successful deleted PDP contexts or rejected GTP create requests in a certain time. The following list of reports can be generated: • GTP Accepted Signaling Activity This report shows the GTP signaling activity accepted by FireWall-1 GX according to date and time of day, and includes a breakdown of the different GTP message types. • GTP Dropped/Rejected Signaling Activity This report shows the dropped or rejected signaling activity according to time of day, and includes a breakdown of the different GTP message types. • GTP Exchanges Not Accepted By Peer GSN This report shows GTP signaling responses where the cause and request accepted Information Elements are different. • GTP Security Alerts This report shows the number of dropped GTP signaling or traffic PDUs due to protocol violation according to time of day and alert type. • GTP Activity Summary This report is a digest of all the other reports. Figure 5-1 shows a sample generated report:
Chapter 5 Monitoring GPRS Network Security 85 FireWall-1_GX.book Page 86 Tuesday, March 27, 2007 10:03 AM
Eventia Reporter Reports
Figure 5-1 Sample FireWall-1 GX Eventia Reporter Report
The hyperlinked sections take you to charts and tables of consolidated data like Figure 5-2 and Figure 5-3. Figure 5-2 Sample FireWall-1 GX Eventia Reporter Chart
86 FireWall-1_GX.book Page 87 Tuesday, March 27, 2007 10:03 AM
Eventia Reporter Reports
Figure 5-3 Sample FireWall-1 GX Eventia Reporter Table
You can also use the Eventia Reporter to present quantitative reports to management. For example, you can measure a rise in PDP context creations after initiating a marketing campaign. To create Eventia Reporter reports, launch Eventia Reporter, choose the reports you want, and click Generate. For more information on using and customizing SmartView reports, see the Eventia Reporter book.
Chapter 5 Monitoring GPRS Network Security 87 FireWall-1_GX.book Page 88 Tuesday, March 27, 2007 10:03 AM
Monitor-Only Mode Monitor-Only Mode Monitor-Only Mode tracks certain unauthorized traffic without blocking it. While in this mode, the firewall continues to inspect GTP traffic, but does not enforce any of the GTP related protections. It does continue to enforce GTP-related security rules, log GTP-related activity, and issue GTP error logs and alerts. Monitor-Only Mode enables operators to preview the results of changes to global properties and settings concerning GTP inspection. This mode is helpful in preventing unanticipated behavior when phasing in FireWall-1 GX for the first time, and whenever changes are made to the global properties. After a careful review of the logs and ensuring that the changes do not impede legitimate cellular traffic, the cellular operator can turn off Monitor-Only Mode, and the firewall can commence blocking malicious GTP traffic. FireWall-1 GX follows the GTP tunnels and keeps their state as it would in regular operation mode. Therefore you can smoothly switch Monitor-Only Mode on and off - all tunnel information continues to exist in both modes, and no tunnels are lost in transition. For configuration information, see gtp_monitor_mode in “Adjusting Settings with GUI Dbedit” on page 72.
Note - Monitor-Only Mode works with FireWall-1 GX 2.5 enforcement modules, and with FireWall-1 GX 2.0 enforcement modules that are managed from a FireWall-1 GX 2.5 management station.
88 FireWall-1_GX.book Page 89 Tuesday, March 27, 2007 10:03 AM
SNMP Extensions for GTP Statistics SNMP Extensions for GTP Statistics FireWall-1 GX can be configured to send SNMP polling data and traps. Various cellular-specific statistics, such as the number of PDP contexts created and deleted, can be polled by SNMP monitoring stations. Alerts and logs can also be set via GTP-aware security rules to send SNMP traps to a monitoring station when events that require attention occur. The Check Point MIB is a data file that contains the collection of Check Point’s SNMP-manageable network devices. It contains SNMP extensions for FireWall-1 GX. For more information about SNMP and MIB, see Working with SNMP Management Tools in the SmartCenter guide. OPSEC partners and developers can find the MIB documentation online at: http://www.opsec.com/.
Chapter 5 Monitoring GPRS Network Security 89 FireWall-1_GX.book Page 90 Tuesday, March 27, 2007 10:03 AM
Configuring Monitoring Configuring Monitoring • Produce extended log on unmatched PDUs logs GTP packets not matched by previous rules with FireWall-1 GX’s extended GTP-related log fields. These logs appear brown and their Action attribute is empty. The default setting is checked. • Protocol violation track option allows you to set the appropriate track or alert option to be used when a protocol violation (malformed packet) is detected. The default setting is Log. You can enable these options in Global Properties > FireWall-1 GX > Track.
90 FireWall-1_GX.book Page 91 Tuesday, March 27, 2007 10:03 AM
Chapter 6 Log Messages
In This Chapter
Introduction to Log Messages page 92 Adding Information Elements to Logs page 93 Log Messages page 94
91 FireWall-1_GX.book Page 92 Tuesday, March 27, 2007 10:03 AM
Introduction to Log Messages Introduction to Log Messages Check Point products provide you with the ability to collect comprehensive information on your network activity in the form of logs. You can then audit these logs at any given time, analyze your traffic patterns and troubleshoot networking and security issues. Familiarizing yourself with the logs can help you understand and learn the status of your network, as well as resolve problems you are experiencing with the system. Reviewing SmartView Tracker traffic logs is a very important aspect of security management, and should get careful attention. For more information about understanding logs and using SmartView Tracker, see the SmartCenter User Guide.
92 FireWall-1_GX.book Page 93 Tuesday, March 27, 2007 10:03 AM
Adding Information Elements to Logs Adding Information Elements to Logs FireWall-1 GX 4.0 provides the option of including certain Information Elements to logs with GTP information. These Information Elements are: • RAT - (Radio Access Type) • IMEI-SV (International Mobile Equipment Identity - Software Version) • MS-Time Zone • Mobile User Location To add these Information Elements to the log, use the GuiDBedit database tool to set the attribute gtp_log_additional_fields to true. The default setting is false.
Chapter 6 Log Messages 93 FireWall-1_GX.book Page 94 Tuesday, March 27, 2007 10:03 AM
Log Messages Log Messages This section contains a list of FireWall-1 GX log messages. The log messages are explained, and when necessary, a recommended course of action is included.
Note - You may encounter self-explanatory log messages that are not included here.
Table 6-1 Listed Alphabetically Log Message Meaning Resolution Duplicate This G-PDU carries a Enforcement of G-PDU sequence numbers sequence duplicated sequence is determined in the FireWall-1 GX page of number number. the Global Properties window. Also, it is possible to change the drop and alert behavior of the rate limiting feature by editing the gtp_sequence_deviation_drop and gtp_sequence_deviation_alert properties with the GUI Dbedit tool (see “Adjusting Settings with GUI Dbedit” on page 72). Echo Request An echo request was This will happen only if you set the value not within time received too close to a of the gtp_echo_req_frequency property to limit previous echo request. the number of seconds required between This echo request will be Echo Requests. You can use this dropped. parameter to protect against Echo Request Flooding. Echo Request An echo request was This happens if you set the value of the on a path received on a path gtp_echo_requires_path_in_use property. which is not in (SGSN-GGSN pair) that By default such Echo Requests are not use currently has no active dropped. PDP Context. The request will be dropped.
94 FireWall-1_GX.book Page 95 Tuesday, March 27, 2007 10:03 AM
Log Messages
Table 6-1 Listed Alphabetically (continued) Log Message Meaning Resolution GTP quota This packet (PDU) This could be the result of a Signaling threshold alert: exceeded the Signaling flood attack. If this happens during normal too many Rate Limit defined for the operation it might be advisable to increase packets indicated destination host Enforce GTP Signal packet rate limit for this GSN entity in the FireWall-1 GX page of the Workstation Properties window or increase Rate limit sampling interval in the FireWall-1 GX page of the Global Properties window. Also, it is possible to change the drop and alert behavior of the rate limiting feature by editing the gtp_rate_limit_drop and gtp_rate_limit_alert properties using the GUI Dbedit tool (see “Adjusting Settings with GUI Dbedit” on page 72). GTP: T-PDU is This T-PDU packet (The If you do want to enable such type of a GTP message internal packet of a packets, you can check the Allow GTP in G-PDU) is a GTP packet GTP in the FireWall-1 GX page of the Global by itself. This may Properties tab (equivalent to setting indicate on attempt to block_gtp_in_gtp to 0). inject GTP packets into the system. GTP: Invalid This T-PDU packet (The Uncheck the Enforce GTP AntiSpoofing End User IP internal packet of a property in the FireWall-1 GX page of the Address G-PDU) has an end user Global Properties window (this is equivalent address IP that does not to setting the gtp_anti_spoofing property match the end user IP to 0). address of the PDP To uncheck only GTP IPv6 AntiSpoofing, context associated with set the gtp_ipv6_anti_spoofing property this G-PDU packet. to 0. GTP The end user address of Change the end user Domain Policy in the intra-tunnel this T-PDU does not APN Properties window (see “Adjusting Inspection: conform to the end user Settings with GUI Dbedit” on page 72). Forbidden Domain Policy defined for MS-to-MS the APN of the PDP traffic Context associated with this G-PDU packet.
Chapter 6 Log Messages 95 FireWall-1_GX.book Page 96 Tuesday, March 27, 2007 10:03 AM
Log Messages
Table 6-1 Listed Alphabetically (continued) Log Message Meaning Resolution Illegal An Update Request was Adjust the GSN Handover Group Handover initiated from a new definitions in the GSN Handover Group SGSN (source IP) which is window. not in the Handover group of the old SGSN of the tunnel. You can see the new SGSN IP in the Source column and the old SGSN IP in the SGSN Signal column. Illegal Illegal redirection attempt Adjust the GSN Handover Group Handover – for GSN signaling. The definitions in the GSN Handover Group GSN Signaling GSN Signaling window. Information Element IP is not in the same Handover group as the Source IP of the message. You can see both IPs in the log. Illegal Illegal redirection attempt Adjust the GSN Handover Group Handover - for GSN traffic. The GSN definitions in the GSN Handover Group GSN Traffic traffic Information window. Element IP is not in the same Handover group as the source IP of the message. You can see both IPs in the log. Illegal This “Create PDP Context If the gtp_allow_recreate_pdpc property is Handover – Request” PDU did not set to open, the policy allows recreating a Recreate PDPC conform to the handover tunnel using SGSN addresses complying policy. with the SGSN handover policy. GSN handover and GSN redirection are only allowed within a GSN Handover Group (see “Creating a Basic Security Policy” on page 48). If this PDU does conform to your handover policy, adjust the GSN Handover Group definitions in the GSN Handover Group window.
96 FireWall-1_GX.book Page 97 Tuesday, March 27, 2007 10:03 AM
Log Messages
Table 6-1 Listed Alphabetically (continued) Log Message Meaning Resolution Illegal response The response cause in this cause response message is illegal for this message type. Invalid G-PDU Relevant for V0 G-PDUs. You can remove flow label compliance on The SGSN IP, GGSN IP or the FireWall-1 GX page of the Global Flow Label of the G-PDU Properties window. However if the Flow does not match the Labels are wrong, it is recommended to definitions of the tunnel investigate the cause. IP checking cannot the G-PDU belongs to. be disabled. (Tunnel association is according to TID). Invalid Relevant for V0. There The recreate policy of established tunnels Signaling was an attempt to create a is determined by the Recreate Req PDP Context of an already gtp_allow_recreate_pdpc property (see PDU established tunnel. “Adjusting Settings with GUI Dbedit” on page 72). A strict policy allows recreating a tunnel using only the identical GSN addresses. If a tunnel is recreated using different GSN addresses and we are in a strict "Re-Create" Policy - the create is dropped and this message is logged. An open policy allows GSN handover for tunnel recreations. Invalid Relevant for V0 Delete Flow label verification can be disabled by Signaling Req Request, V0 Update deselecting the Verify Flow Label setting, PDU Request, and V0->V1 found in the FireWall-1 GX tab of Global Update Request. Either Properties. IP checking cannot be the source IP address, disabled. dest. IP address, or flow label does not match those of the tunnel (TID) to which the packet belongs.
Chapter 6 Log Messages 97 FireWall-1_GX.book Page 98 Tuesday, March 27, 2007 10:03 AM
Log Messages
Table 6-1 Listed Alphabetically (continued) Log Message Meaning Resolution Invalid V0 Update Resp. The flow Flow label verification can be disabled by Signaling Flow label does not match the deselecting the Verify Flow Label setting, Label PDU tunnel (TID) to which the found in the FireWall-1 GX tab of Global (Update Resp) packet belongs. Properties. IP checking cannot be disabled.
Invalid V0 Create Resp. The flow Flow label verification can be disabled by Signaling Flow label does not match the deselecting the Verify Flow Label setting, Label PDU tunnel (TID) to which the found in the FireWall-1 GX tab of Global (Create Resp) packet belongs. Properties. IP checking cannot be disabled.
Invalid V0 Delete Resp. The flow Flow label verification can be disabled by Signaling Flow label does not match the deselecting the Verify Flow Label setting, Label PDU tunnel (TID) to which the found in the FireWall-1 GX tab of Global (Delete Resp) packet belongs. Properties. IP checking cannot be disabled.
IP is not in the The assigned static or This packet is dropped according to the APN domain dynamic end user IP is APN end user Domain defined in not part of end user SmartDashboard. Domain defined for the related APN. Malformed This Path management Path management PDUs are verified Path PDU does not conform to against GTP Release 1997 and 1999 Management GTP standards. Standards. PDU
98 FireWall-1_GX.book Page 99 Tuesday, March 27, 2007 10:03 AM
Log Messages
Table 6-1 Listed Alphabetically (continued) Log Message Meaning Resolution No Match on A “Create PDP Context The allowed types of “Create PDP Context Create PDP Request” PDU was not Request” PDUs are defined in the Rule Context PDU matched on the Rule Base using Source, Destination and the Base. Advanced GTP Service Properties window. If the combination of the above in the dropped PDU should have been allowed, please review your Rule Base to allow this traffic. If the last rule in the Security Policy Rule Base is an “Accept” rule, set Produce extended log on unmatched PDUs to “Last” instead of “Before Last” in the FireWall-1 GX page of the Global Properties window. Out of range This G-PDU carries an Enforcement of G-PDU sequence numbers sequence out-of-range sequence is determined in the FireWall-1 GX page of number number. the Global Properties window (Figure 3-3 on page 66), where you can also define the maximum allowed deviation for all FireWall-1 GX Modules. Also, it is possible to change the drop and alert behavior of the rate limiting feature by editing gtp_sequence_deviation_drop and gtp_sequence_deviation_alert properties using the GUI Dbedit tool (see “Adjusting Settings with GUI Dbedit” on page 72). Packet or some During stateful inspection, This packet does not have the minimal Information this packet (PDU) was length to hold the GTP header information, Element is shorter then expected. or the packet size is small than indicated shorter than by the length field in the GTP header. expected Passed Too many re-transmissions Set the gtp_max_req_retransmit variable maximum of the same delete request to the number of allowed outstanding create request were received (while re-transmits. create response not received yet by the FireWall-1 GX module). This request packet will be dropped.
Chapter 6 Log Messages 99 FireWall-1_GX.book Page 100 Tuesday, March 27, 2007 10:03 AM
Log Messages
Table 6-1 Listed Alphabetically (continued) Log Message Meaning Resolution Passed Too many re-transmissions This can occur if the FireWall-1 GX Module maximum of the same delete request is configured to close all end user delete request were received (while connections using the SAM API. delete response not Set the gtp_max_req_retransmit variable received yet by the to the number of allowed outstanding FireWall-1 GX module). re-transmits. This request packet will be dropped. Passed Too many re-transmissions Set the gtp_max_req_retransmit variable maximum of the same update to the number of allowed outstanding update request request were received re-transmits. (while update response not received yet by the FireWall-1 GX module). This request packet will be dropped. re-using TEID The specified TEID of this If the attribute gtp_allow_recreate_pdpc Control tunnel create attempt is in is set to strict, the new tunnel is not Downlink use by another tunnel (for created in this case. the same SGSN- GGSN pair). The new tunnel is created. re-using TEID The specified TEID of this If the attribute gtp_allow_recreate_pdpc Data Downlink tunnel create attempt is in is set to strict, the new tunnel is not use by another tunnel (for created in this case. the same SGSN- GGSN pair). The new tunnel is created. re-using TEID The specified TEID of this If the attribute gtp_allow_recreate_pdpc Data Uplink tunnel create attempt is in is set to strict, the new tunnel is not use by another tunnel (for created in this case. the same SGSN- GGSN pair). The new tunnel is created.
100 FireWall-1_GX.book Page 101 Tuesday, March 27, 2007 10:03 AM
Log Messages
Table 6-1 Listed Alphabetically (continued) Log Message Meaning Resolution re-using TEID The specified TEID of this If the attribute gtp_allow_recreate_pdpc Control Uplink tunnel create attempt is in is set to strict, the new tunnel is not use by another tunnel (for created in this case. the same SGSN- GGSN pair). The new tunnel is created. re-using TEID The specified TEID of this If the attribute gtp_allow_recreate_pdpc Control Uplink, tunnel create attempt is in is set to strict, the new tunnel is not SRC=0 use by another tunnel (for created in this case. the same SGSN-GGSN pair). The new tunnel is created. Request/ This Signaling Response Signaling Response PDUs must match a Response PDU carries a wrong previously approved Signaling Request Mismatch Sequence number or PDU in order to pass the FireWall-1 GX doesn’t match any Module. This cannot be configured. Signaling Request. TEID 0 not A V1 Update Request has This packet will be dropped. allowed for TEID 0. This is valid only Update for V0 to V1 handover message type cases. However the imsi and nsapi Information Elements of this Request do not match an existing V0 tunnel. TID 0 not A Signaling PDU carries a This packet violated basic packet integrity allowed for this NULL TID violating the and will not pass through the FireWall-1 message type GTP protocol. GX Module.
Chapter 6 Log Messages 101 FireWall-1_GX.book Page 102 Tuesday, March 27, 2007 10:03 AM
Log Messages
Table 6-1 Listed Alphabetically (continued) Log Message Meaning Resolution Unestablished This signaling or data PDUs can only pass the FireWall-1 GX Tunnel packet belongs to an Module if they carry a Tunnel ID (V0) or a unestablished tunnel. Tunnel EndPoint ID (V1) of a previously • For V0, the packet has established PDP context that was not yet a Tunnel ID (TID) of terminated. This packet violates basic an Unknown PDP tunnel integrity and will not be allowed. Context. • For V1, the packet has a Tunnel EndPoint Identifier (TEID) of an Unknown PDP Context. Unknown GTP This packet constitutes an Message Type unsupported GTP Signaling message. Unsupported A GTP packet with version The packet will be dropped. version other than V0 or V1 was received.
102 FireWall-1_GX.book Page 103 Tuesday, March 27, 2007 10:03 AM
Chapter 7 Advanced Configuration
In This Chapter
GRX Redundant Deployment page 104 Stripping Information Elements page 109 FireWall-1 GX Bridge Mode page 110
103 FireWall-1_GX.book Page 104 Tuesday, March 27, 2007 10:03 AM
GRX Redundant Deployment GRX Redundant Deployment
Introduction to GRX Redundant Deployment page 104 Asymmetric Routing page 105 Configuration page 107 Testing the Setup page 108 Fine-tuning Synchronization Parameters page 108
Introduction to GRX Redundant Deployment
Cellular operators strive to maintain 99.999% network availability. In this effort, they sometimes use two separate connections to the GRX (GPRS Roaming eXchange) network using two separate GRX providers on different sites. This is somewhat similar to a dual ISP scenario, but with the difference that each GRX connection is set up in a different physical site protected by its own FireWall-1 GX module. The demanded availability requires all GPRS/UMTS connections to survive in the event that one of these GRX connections will fail. For that reason, the cellular operator needs to synchronize the kernel state tables between the two FireWall-1 GX modules which are situated on physically distant locations. This requires the synchronization traffic to be transported over a wide area network (WAN). Synchronization traffic originally was designed to pass between cluster members only on a Local Area Network (LAN). Here we present a method that has been validated to work well to synchronize the FireWall-1 GX cluster members over a Wide Area Network, and maintain full uptime and security for all PDP contexts during a "GRX failover". Uptime and security is maintained for PDP Contexts that existed before the failover occurred, and for the new ones that were initiated after the failover occurred. All PDP Contexts are maintained and secured during the failback as well. The basic idea behind the solution presented here is to deploy a Layer 2 tunnel between the two FireWall-1 GX modules, which allows the FireWall-1 GX cluster members to operate normally, as if they were on the same LAN, even though the Layer 2 tunnel traffic is being routed over a WAN network.
104 FireWall-1_GX.book Page 105 Tuesday, March 27, 2007 10:03 AM
GRX Redundant Deployment
Asymmetric Routing
This solution works for both symmetric and asymmetric routing. Asymmetric routing takes place when some of the packets of a certain PDP Context session pass through one GRX, while other packets of the same PDP Context pass through another GRX. This can take place in either direction, i.e., to or from the partner. In this deployment, asymmetric routing can be manifested in a few ways: • A GTP Create Request passes through GRX-A, and the corresponding GTP Create Response returns through GRX-B. • Same as #1 for Update, Delete, Echo exchanges. • T-PDU traffic may be split between GRX-A and GRX-B, in both directions (to and from the partner). Asymmetric routing is supported by holding critical packets at the receiving Enforcement Module until the peer module has acknowledged that it its information on these packets is in sync. This is true, for example, for all Request type messages, since the peer Enforcement Module must register a Request packet before the corresponding Response message arrives.
Note - The solution presented here is supported on FireWall-1 GX versions 2.5 and NGX.
During normal operation, traffic is load-shared between the two GRXs, and consequently load-shared between the two FireWall-1 GX Enforcement Modules, as illustrated in Figure 7-1. The traffic flow is according to the operator routing settings.
Chapter 7 Advanced Configuration 105 FireWall-1_GX.book Page 106 Tuesday, March 27, 2007 10:03 AM
GRX Redundant Deployment
Figure 7-1 GRX load sharing during normal operation
If any point on the network of one of the GRXs should fail, all traffic takes the path of the other, fully-functional GRX, as illustrated in Figure 7-2. Figure 7-2 Traffic failover during GRX failure
The path change occurs via dynamic routing settings using OSPF, BGP, etc. The data remains synchronized between the two Enforcement Modules.
106 FireWall-1_GX.book Page 107 Tuesday, March 27, 2007 10:03 AM
GRX Redundant Deployment
Configuration
The distributed FireWall-1 GX cluster consists of two FireWall-1 GX Enforcement Modules.
Note - It is likely that more than two FireWall-1 GX Enforcement Modules in such a deployment will work as well (e.g., in a deployment with three GRX connections), although this has not been verified.
1. Define a FireWall-1 GX cluster, using 3rd Party HA mode, and add cluster members. 2. Set up the cluster to support non sticky connections, which enables the proper handling of asymmetric routing flows. 3. Set up a Layer 2 tunnel, such as L2TP, GRE, etc., between the two FireWall-1 GX Enforcement Modules. The interfaces on both Enforcement Modules constituting the sync network should connect to the Layer 2 tunneling device on a LAN (or crossover cable). See “Setting up a Layer 2 Tunnel on Cisco Routers” on page 113 for an example of a Layer 2 deployment. Figure 7-3 Synchronizing FireWall-1 GX over a WAN
4. If desired, and the Layer 2 tunneling device supports it, establish encryption on the Layer 2 tunnel. 5. On the interfaces of the sync network, set the MTU to 1400. A value higher than 1400 may cause PMTU discovery procedures not supported by the tunneling device.
Chapter 7 Advanced Configuration 107 FireWall-1_GX.book Page 108 Tuesday, March 27, 2007 10:03 AM
GRX Redundant Deployment
Testing the Setup
Perform the tests below to verify that the synchronization over the WAN network is operating properly. 1. Check on each FireWall-1 GX member that it can see the other member over Layer 2. This is done by running the command arp -a on one member, and verifying that it displays the MAC address of the other member. This will indicate that the Layer 2 tunnel is set up correctly. 2. Using tools such as tcpdump, fw monitor, etc., verify that sync traffic is being transmitted on the sync network. 3. Verify the health of the sync mechanism by checking the output of the command cphaprob stat and cphaprob [-reset] syncstat. Refer to the ClusterXL User Guide included on the CD for details on the output of these commands. 4. Verify that the GTP kernel tables are synchronized between the 2 members after passing some GTP traffic between them. Use the command fw tab -s | grep gtp and compare the results. In general both members should show the same values for the tables. Slight differences are acceptable. 5. Simulate failover by either shutting down an Enforcement Module and/or diverting all traffic to the other GRX path. In all cases, existing and new PDP contexts should remain intact. 6. Perform a reboot of FireWall-1 GX member and verify that existing and new PDP Contexts remain intact. 7. Perform tests of asymmetric routing by setting up such routes in your network.
Fine-tuning Synchronization Parameters
See “Enlarging the Sending Queue” and “Enlarging the Receiving Queue” in the Cluster XL User Guide for suggestions for fine tuning synchronization parameters.
108 FireWall-1_GX.book Page 109 Tuesday, March 27, 2007 10:03 AM
Stripping Information Elements Stripping Information Elements In situations where an operator has advanced GSNs, using up-to-date or preliminary Information Elements, it may occur that a partner of this operator will have a GTP-aware firewall that drops these messages. This is due to the "suspicious" nature of firewalls to "unknown" traffic. FireWall-1 GX can be configured to strip specific Information Elements for GTP messages exchanged with specific partners in order to avoid cases where the firewall of the partner will drop the message. Today this already has potential relevancy for the following Information Elements: • IMEI-SV • User Location Information • RAT • Time Zone To strip Information Elements from traffic destined for specific partners, do the following: 1. Create a new GTP v1 service as detailed in “Enforcing a More Granular GTP Security Policy” on page 58 and select Save. 2. Open the GuiDBedit tool. Go to Services >services, and select the new service. 3. In the variables list, select the field stripped_information_elements and insert the numeric values of the Information Elements you want to remove. The delimiter can be either ',' (comma) or ' ' (space). Valid values for the Information Elements are from 1-30 (TV Information Elements), 116-127 (TV reserved Information Elements - they are all reserved accept 127 that is in use), and 128 - 255 (TLV Information Elements). For example, if you want to strip the RAT and IMEI Information Elements enter: 151, 154
Note - If the input is illegal, policy will not successfully install.
4. Save and close GuiDBedit. 5. Add the new service to the Security Rule Base for the partner(s) for whom you want to strip the IEs, and install policy. The selected Information Elements will be removed from traffic to the selected partner(s).
Chapter 7 Advanced Configuration 109 FireWall-1_GX.book Page 110 Tuesday, March 27, 2007 10:03 AM
FireWall-1 GX Bridge Mode FireWall-1 GX Bridge Mode
In This Section
Overview of FireWall-1 GX Bridge Mode page 110 Description of IPSO Transparent Mode page 110 Configuring Bridge Mode page 112
Overview of FireWall-1 GX Bridge Mode
Bridge mode, as its name implies, allows FireWall-1 GX to function as if it were a Layer 2 device, such as a switch or a bridge. This enables you to introduce FireWall-1 GX into an existing network without changing network configuration and IP addressing. Currently bridge mode is only supported on Nokia IPSO platforms. In IPSO the term widely used for Bridge mode is Transparent mode. The remainder of this chapter will describe the IPSO Transparent mode.
Description of IPSO Transparent Mode
IPSO Transparent mode consists of the following elements: • “Transparent Groups” • “Neighbor Learning” • “Receive & Transmit Processing” • “FireWall-1 GX Support” • “VRRP Support”
Transparent Groups A transparent group holds all the interfaces that are on the same logical subnet. By default, a transparent group is disabled, and while disabled, every interface that belongs to it will not function. If you have more than one group on the same FireWall-1 GX host, the groups must be visible to each other on an IP level, i.e., they must have routing between them. For that at least one interface in each group should have an IP address.
110 FireWall-1_GX.book Page 111 Tuesday, March 27, 2007 10:03 AM
FireWall-1 GX Bridge Mode
Neighbor Learning Neighbor learning is the process of associating a MAC address with an interface whenever a packet is received with an unknown source MAC address. This association is called a neighbor control block. The neighbor control block is deleted from the address table after a period of inactivity (age time out). The age time-out is reset to this initial value for the neighbor control block on receiving any packet from that neighbor.
Receive & Transmit Processing Receive Processing The regular ARP and IP receive handlers are replaced by the Transparent mode handler. Transmit Processing Packets are transmitted from one interface to the other based on the information in the Neighbor control block and the destination MAC address of the packet to be transmitted. Packets that originate locally on the FireWall-1 GX Enforcement Module, or that have been forwarded by its IP layer, are transmitted in a similar manner. Link Multicast packets are transmitted on all interfaces of the group of the interface that received the packets. They are not transmitted back to the receiving interface itself.
FireWall-1 GX Support While IP packets are filtered by FireWall-1 GX both inbound and outbound, GTP packets are filtered in general when they are inbound. In any case, there is no difference in the flow of the packet within the FireWall-1 GX engine, compared to a regular FireWall-1 GX router type deployment. ARP packets are not filtered, and address translation is not supported. Folding, i.e., passing packets to user space security servers, is supported.
VRRP Support VRRP is supported. A node learns if it is a VRRP master or slave by the VRRP Virtual address. A VRRP master performs all of the Receive and Transmit operations described above; a VRRP slave drops all packets except those with local destinations.
Chapter 7 Advanced Configuration 111 FireWall-1_GX.book Page 112 Tuesday, March 27, 2007 10:03 AM
FireWall-1 GX Bridge Mode
Configuring Bridge Mode
Create a Transparent Mode Group 1. In Nokia Voyager, select Config > Interface Configuration > Transparent Mode. Enter a group number (1-100) in the text box. Select Apply and Save.
Add an Interface to a Transparent Group 2. On the Transparent Mode page, select the group to be modified > Add-Interface > interface to be added. Select Apply and Save. 3. Repeat step 2. for each interface you want to add. Note that the interfaces will not process packets until you enable the group.
Enable VRRP 4. On the Transparent Mode page, select VRRP Enabled and click Yes.
Monitor Transparent Mode 5. Return to the Home page and select Monitor > Transparent Mode Monitor > the group ID you wish to monitor.
Note - The solution presented here is supported on FireWall-1 GX versions 2.5 and NGX.
112 FireWall-1_GX.book Page 113 Tuesday, March 27, 2007 10:03 AM
Appendix A Setting up a Layer 2 Tunnel on Cisco Routers
In This Appendix
Sample Deployment page 114 Configuration of Router 1 page 115 Configuration of Router 2 page 117
113 FireWall-1_GX.book Page 114 Tuesday, March 27, 2007 10:03 AM
Sample Deployment Sample Deployment
Figure A-1 Illustration of sample deployment
Display the router version with the command sh ver. Output should be similar to the following: Cisco IOS Software, C2600 Software (C2600-A3JK9S-M), Version 12.3(11)T3, RELEASE SOFTWARE (fc4) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2005 by Cisco Systems, Inc. Compiled Tue 25-Jan-05 15:48 by pwade
ROM: System Bootstrap, Version 12.2(8r) [cmong 8r], RELEASE SOFTWARE (fc1)
ROUTER1 uptime is 48 minutes System returned to ROM by reload System image file is "flash:c2600-a3jk9s-mz.123-11.T3.bin"
114 FireWall-1_GX.book Page 115 Tuesday, March 27, 2007 10:03 AM
Configuration of Router 1 Configuration of Router 1
Defining the Tunnel
Enter the following commands at Router 1’s interface: 1. interface FastEthernet0/1 1. ip address 10.10.10.1 255.255.255.0 2. l2tp-class default 1. authentication 2. hello 20 3. password <...> 3. pseudowire-class ckpoint 1. encapsulation l2tpv3 2. sequencing both 3. protocol l2tpv3 default 4. ip local interface Loopback0 5. ip pmtu 4. interface Loopback0 1. ip address 1.1.1.1 255.255.255.255 5. interface FastEthernet0/0 1. xconnect 2.2.2.2 100 encapsulation l2tpv3 pw-class ckpoint 6. ip route 2.2.2.2 255.255.255.255 10.10.10.2 7. ip route 20.20.20.0 255.255.255.0 10.10.10.2 8. access-list 100 permit ip host 1.1.1.1 host 2.2.2.2
Establishing Encryption (Optional)
Enter the following set of commands if encryption is desired: 1. crypto isakmp policy 10 1. encr 3des
Chapter A Setting up a Layer 2 Tunnel on Cisco Routers 115 FireWall-1_GX.book Page 116 Tuesday, March 27, 2007 10:03 AM
Establishing Encryption (Optional)
2. hash md5 3. authentication pre-share 4. group 2 2. crypto isakmp key 6
116 FireWall-1_GX.book Page 117 Tuesday, March 27, 2007 10:03 AM
Configuration of Router 2 Configuration of Router 2
Defining the Tunnel
Enter the following commands at Router 2’s interface: 1. interface FastEthernet0/0 1. ip address 20.20.20.2 255.255.255.0 2. l2tp-class default 1. authentication 2. hello 20 3. password <...> 3. pseudowire-class ckpoint 1. encapsulation l2tpv3 2. sequencing both 3. protocol l2tpv3 default 4. ip local interface Loopback0 5. ip pmtu 4. interface Loopback0 1. ip address 2.2.2.2 255.255.255.255 5. interface FastEthernet0/1 1. xconnect 1.1.1.1 100 encapsulation l2tpv3 pw-class ckpoint 6. ip route 1.1.1.1 255.255.255.255 20.20.20.1 7. ip route 10.10.10.0 255.255.255.0 20.20.20.1 8. access-list 100 permit ip host 2.2.2.2 host 1.1.1.1
Establishing Encryption (Optional)
Enter the following set of commands if encryption is desired: 1. crypto isakmp policy 10 1. encr 3des
Chapter A Setting up a Layer 2 Tunnel on Cisco Routers 117 FireWall-1_GX.book Page 118 Tuesday, March 27, 2007 10:03 AM
Establishing Encryption (Optional)
2. hash md5 3. authentication pre-share 4. group 2 2. crypto isakmp key 6
118 FireWall-1_GX.book Page 119 Tuesday, March 27, 2007 10:03 AM
Appendix B Glossary
A AA Anonymous Access — the network does not know the real identity of the mobile, opposite of non-anonymous access. AP Access Point — entry point to an external network. APN Access Point Name — the identifier of an external packet data network. B Bluetooth A short-range communication standard — backed by Nokia, Ericsson, IBM, Intel, Toshiba and others — for pro-active background communication devices in a 10-meter range. BG Border Gateway — a logical box that connects two (or more) operators together via Inter-PLMN backbone; protects operator’s intra-PLMN network against intruders. BSSAP+ Base Station System Application Part+ — the protocol between SGSN and MSC/VLR BSSGP Base Station System GPRS Protocol — the protocol between SGSN and BSS. C CCU Channel Codec Unit — the functional element in BSS that handles low level GPRS control in radio. CLNS Connection Less Network Service; similar to the IP protocol. CONS Connection Oriented Network Service, similar to the X.25 protocol. CS Circuit Switched; opposite of packet switched.
119 FireWall-1_GX.book Page 120 Tuesday, March 27, 2007 10:03 AM
D DNS Domain Name System — IP service that can be used to map logical name (for example, “myfavoritecookiecutter.com”) to an IP address. DOS Denial of Service — an attack that attempts to disrupt or degrade the service offered to end users. DRX Discontinuous Reception — when MS receives intermittently. E EDGE Enhanced Data-rates for GSM Evolution, a technology for enhancing GSM to deliver mobile data and multimedia services; an alternative to UTMS. End-to-End A single encrypted and authenticated tunnel through the operator Security network, reaching from the wireless device to the server. End-to-end security requires that the entire connection be IP-based; this can occur only in third-generation networks. G Gb Interface between an SGSN and a BSS. Gc Interface between a GGSN and an HLR. Gd Interface between a SMS-GMSC and an SGSN, and between a SMS-IWMSC and an SGSN. Gf Interface between an SGSN and an EIR. Gi Reference point between GPRS and an external packet data network. Gn Interface between two GSNs within the same PLMN. Gp Interface between two GSNs in different PLMNs. The Gp interface allows support of GPRS network services across areas served by the co-operating GPRS PLMNs. Gr Interface between an SGSN and an HLR. Gs Interface between an SGSN and an MSC/VLR. GGSN Gateway GSN (GPRS Support Node) GMM/SM GPRS Mobility Management and Session Management — protocol stack between MS and SGSN that handles GPRS attach/detach, PDP context activation/deactivation, etc. G-PDU A user data message, comprising a G-PDU and a GTP header. GPRS General Packet Radio System, a non-voice value-added service for faster data transactions over a mobile telephone network, designed for deployment on GSM and TDMA-based mobile networks. GPRS overlays a packet-based air interface on the existing switched network.
120 FireWall-1_GX.book Page 121 Tuesday, March 27, 2007 10:03 AM
GSM Global System for Mobile Communications (originally Groupe Speciale Mobile, hence the acronym) — a second generation time-division mobile network standard. GSN GPRS Support Node GTP GPRS Tunnel Protocol GTP Tunnel In GTP version 0 GTP tunnel is defined by two associated PDP Contexts in different GSN nodes and is identified with a Tunnel ID. In GTP version 1, a GTP tunnel in the GTP-U plane is defined for each PDP Context in the GSNs. A GTP tunnel in the GTP-C plane is defined for all PDP Contexts with the same PDP address and APN (for Tunnel Management messages), or for each MS (for messages not related to Tunnel Management). A GTP tunnel is identified in each node with a TEID, an IP address and a UDP port number. In both versions, a GTP tunnel is necessary to forward packets between an external packet data network and an MS user. H HPLMN Home Public Land Mobile Network — the home network. HSCSD High Speed Circuit Switched Data — a new GSM service for circuit switched connections. I IE Information Element — a group of information which may be included within a signaling message or data flow. IETF Internet Engineering Task Force — Internet standardization organization. IMSI International Mobile Subscriber Identity — a user’s unique ID in GSM/GPRS networks. Interface Well standardized point in the GPRS standard that typically has multivendor capability; opposite of reference point. IP Internet Protocol IPv4 Internet Protocol version 4 — the currently used IP version. IPv6 Internet Protocol version 6 — the next generation IP version, not yet widely used. ISP Internet Service Provider — an organization or operator that sells Internet access. L
Chapter B Glossary 121 FireWall-1_GX.book Page 122 Tuesday, March 27, 2007 10:03 AM
LDAP Lightweight Directory Access Protocol — client/server protocol for accessing information in network directories. LLCLogical Link Control — the protocol layer between MS and SGSN. M MACMedium Access Control — the radio level protocol used to allocate the radio channel. MIB Management Information Base — a collection of managed objects defined by their attributes and visible to the network management system. MMS Multimedia Short Message Service — wireless service that transmits text, audio and video over WAP. MTP2 Message Transfer Part layer 2 — S7 protocol layer 2. MTP3 Message Transfer Part layer 3 — SS7 protocol layer 3. MS Mobile Station — a portable device that connects subscribers to a wireless network, for example a cellular phone or a laptop with a cellular modem. MS-ISDN Mobile Station International ISDN Number — the standard international telephone number used to identify a given subscriber. N N-Byte Number of Bytes. N-PDU Number of Packets. NSAPI Network Service Access Point Identifier — an integer value in the range [0; 15], used in the two GTP versions for PDP Context identification in the MS and SGSN. NS Network Service — the protocol layer between BSS and SGSN. NSS Network SubSystem — the network part of the network (in GPRS this means SGSN and GGSN). O OPSECOpen Platform for Security — the framework for integration and interoperability of Check Point products with those of third-party vendors. P PCU Packet Control Unit — functional element in BSS that handles upper level GPRS control in radio. PDA Personal Digital Assistant— a device that fits in hand and has limited services.
122 FireWall-1_GX.book Page 123 Tuesday, March 27, 2007 10:03 AM
PDN Packet Data Network — a network that carries user data in packets (for example, Internet and X.25) PDP Packet Data Protocol — a network protocol used by an external packet data network (usually IP). PDP address The MS’s address in the external packet data network, also called End User IP address. PDP context Information sets held in MS and GSNs for a specific PDP address. PDU Protocol Data Unit — a packet. PLMN Public Land Mobile Network. P-TMSI Packet TMSI — a packet system’s temporary mobile’s identity. PPP Point-to-Point Protocol — a widely used protocol under IP to connect (for example, PC and ISP via modems). PTM Point To Multipoint — one sender, multiple receivers. PTP Point To Point— one sender, one receiver. Q QoS Quality of Service — definition of the service class of the connection between MS and the network. R R Reference point between a non-ISDN compatible TE and MT. Typically this reference point supports a standard serial interface. RA Routing Area — a set of cells belonging to one group. RA is always a subset of a LA (location area). RLCRadio Link Control — A protocol between MS and BSS to handled retransmission and other radio related issues. S SGSN Serving GSN — a GPRS Support Node. SLIP Serial Line IP protocol — a protocol similar to PPP. SMS Short Message Service — A protocol enabling mobile phone users to send and receive short messages of up to 160 characters messages. SM-SCShort Message Service Center — a computer that handles short messages. SMS-GMSC Short Message Service Gateway MSC — an MSC used to deliver data to/from SGSN. SMS-IWMSCShort Message Service Interworking MSC — an MSC used to deliver data to/from SGSN.
Chapter B Glossary 123 FireWall-1_GX.book Page 124 Tuesday, March 27, 2007 10:03 AM
SNDCSubNetwork Dependent Convergence) — The protocol layer between MS and SGSN. SNDCP SubNetwork Dependent Convergence Protocol — the protocol used in SNDC. SNMP Simple Network Management Protocol runs over TCP/IP and is used to control and manage IP gateways and other network functions. T TCAP Transaction Capabilities Application Part — SS7 protocol layer. TCP Transmission Control Protocol — protocol layer on top of the IP protocol. TE Terminal Equipment — typically a computer, host. TEID Tunnel End Point Identification — The GTP version 1 uni-directional tunnel identifier. TFT Traffic Flow Template, a packet filter list that sorts the packets coming into the GGSN to the correct PDP Context. Also allows some protocol security filtering. TID Tunnel ID — the GTP version 0 GTP tunnel identifier. Consists of the user ID, or equivalent when Anonymous Access is used, and NSAPI. TLLI Temporary Logical Link Identity — provides a signalling address for communication between the MS and the SGSN. T-PDU An original packet from an MS or a network node in an external packet data network. U Um Radio interface between MS and the network. UMTS Universal Mobile Telephone System, a third generation service (part of the IMT-2000 vision) that is expected to enable cellular service providers to deliver high-value broadband information, commerce and entertainment services to mobile users via fixed, wireless and satellite networks. V
124 FireWall-1_GX.book Page 125 Tuesday, March 27, 2007 10:03 AM
VPLMN Visited Public Land Mobile Network — the network where the MS is currently located. W WAP Wireless Application Protocol, a standard wireless protocol specification, based on existing Internet standards such as XML and IP, that leverages HTTP and enables developers to use existing tools to produce scalable applications that deliver Internet content and advanced services to mobile phones and other wireless terminals.
Chapter B Glossary 125 FireWall-1_GX.book Page 126 Tuesday, March 27, 2007 10:03 AM
126 FireWall-1_GX.book Page 127 Tuesday, March 27, 2007 10:03 AM
THIRD PARTY TRADEMARKS AND COPYRIGHTS AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING Entrust is a registered trademark of Entrust Technologies, Inc. in the United IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF States and other countries. Entrust’s logos and Entrust product and service THE POSSIBILITY OF SUCH DAMAGE. names are also trademarks of Entrust Technologies, Inc. Entrust Technologies Limited is a wholly owned subsidiary of Entrust Technologies, The following statements refer to those portions of the software copyrighted Inc. FireWall-1 and SecuRemote incorporate certificate management by Eric Young. THIS SOFTWARE IS PROVIDED BY ERIC YOUNG ``AS IS'' technology from Entrust. AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND Verisign is a trademark of Verisign Inc. FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, The following statements refer to those portions of the software copyrighted INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL by University of Michigan. Portions of the software copyright © 1992-1996 DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF Regents of the University of Michigan. All rights reserved. Redistribution and SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR use in source and binary forms are permitted provided that this notice is BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF preserved and that due credit is given to the University of Michigan at Ann LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT Arbor. The name of the University may not be used to endorse or promote (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF products derived from this software without specific prior written permission. THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF This software is provided “as is” without express or implied warranty. SUCH DAMAGE. Copyright © 1998 The Open Group. Copyright © Sax Software (terminal emulation only). The following statements refer to those portions of the software copyrighted The following statements refer to those portions of the software copyrighted by Jean-loup Gailly and Mark Adler Copyright (C) 1995-2002 Jean-loup Gailly by Carnegie Mellon University. and Mark Adler. This software is provided 'as-is', without any express or implied warranty. In no event will the authors be held liable for any damages Copyright 1997 by Carnegie Mellon University. All Rights Reserved. arising from the use of this software. Permission is granted to anyone to use this software for any purpose, including commercial applications, and to alter Permission to use, copy, modify, and distribute this software and its it and redistribute it freely, subject to the following restrictions: documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies and that both that 1. The origin of this software must not be misrepresented; you must not claim copyright notice and this permission notice appear in supporting that you wrote the original software. If you use this software in a product, an documentation, and that the name of CMU not be used in advertising or acknowledgment in the product documentation would be appreciated but is publicity pertaining to distribution of the software without specific, written not required. prior permission.CMU DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF 2. Altered source versions must be plainly marked as such, and must not be MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL CMU BE LIABLE misrepresented as being the original software. FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR 3. This notice may not be removed or altered from any source distribution. PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH The following statements refer to those portions of the software copyrighted THE USE OR PERFORMANCE OF THIS SOFTWARE. by the Gnu Public License. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public The following statements refer to those portions of the software copyrighted License as published by the Free Software Foundation; either version 2 of the by The Open Group. License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY the implied warranty of MERCHANTABILITY or FITNESS FOR A KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE PARTICULAR PURPOSE. See the GNU General Public License for more WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR details.You should have received a copy of the GNU General Public License PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE OPEN along with this program; if not, write to the Free Software Foundation, Inc., GROUP BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, 675 Mass Ave, Cambridge, MA 02139, USA. WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE The following statements refer to those portions of the software copyrighted OR OTHER DEALINGS IN THE SOFTWARE. by Thai Open Source Software Center Ltd and Clark Cooper Copyright (c) 2001, 2002 Expat maintainers. Permission is hereby granted, free of charge, The following statements refer to those portions of the software copyrighted to any person obtaining a copy of this software and associated by The OpenSSL Project. This product includes software developed by the documentation files (the "Software"), to deal in the Software without OpenSSL Project for use in the OpenSSL Toolkit (http://www.openssl.org/). restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND permit persons to whom the Software is furnished to do so, subject to the ANY * EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT following conditions: The above copyright notice and this permission notice LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND shall be included in all copies or substantial portions of the Software. THE FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, SHALL THE OpenSSL PROJECT OR ITS CONTRIBUTORS BE LIABLE FOR EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. GDChart is free for use in your applications and for chart generation. YOU
Check Point Software Technologies Ltd.
U.S. Headquarters: 800 Bridge Parkway, Redwood City, CA 94065, Tel: (650) 628-2000 Fax: (650) 654-4233, [email protected] International Headquarters: 3A Jabotinsky Street, Ramat Gan, 52520, Israel, Tel: 972-3-753 4555 Fax: 972-3-575 9256, http://www.checkpoint.com FireWall-1_GX.book Page 128 Tuesday, March 27, 2007 10:03 AM
MAY NOT re-distribute or represent the code as your own. Any re- 2. Redistributions in binary form must reproduce the above copyright notice, distributions of the code MUST reference the author, and include any and all this list of conditions and the following disclaimer in the documentation and/ original documentation. Copyright. Bruce Verderaime. 1998, 1999, 2000, or other materials provided with the distribution. 2001. Portions copyright 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002 by Cold Spring Harbor Laboratory. Funded under Grant P41- 3. The name "PHP" must not be used to endorse or promote products RR02188 by the National Institutes of Health. Portions copyright 1996, derived from this software without prior written permission. For written 1997, 1998, 1999, 2000, 2001, 2002 by Boutell.Com, Inc. Portions relating permission, please contact [email protected]. to GD2 format copyright 1999, 2000, 2001, 2002 Philip Warner. Portions relating to PNG copyright 1999, 2000, 2001, 2002 Greg Roelofs. Portions 4. Products derived from this software may not be called "PHP", nor may relating to gdttf.c copyright 1999, 2000, 2001, 2002 John Ellson "PHP" appear in their name, without prior written permission from ([email protected]). Portions relating to gdft.c copyright 2001, 2002 John [email protected]. You may indicate that your software works in conjunction Ellson ([email protected]). Portions relating to JPEG and to color with PHP by saying "Foo for PHP" instead of calling it "PHP Foo" or "phpfoo" quantization copyright 2000, 2001, 2002, Doug Becker and copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, Thomas G. Lane. 5. The PHP Group may publish revised and/or new versions of the license This software is based in part on the work of the Independent JPEG Group. from time to time. Each version will be given a distinguishing version See the file README-JPEG.TXT for more information. Portions relating to number. Once covered code has been published under a particular version WBMP copyright 2000, 2001, 2002 Maurice Szmurlo and Johan Van den of the license, you may always continue to use it under the terms of that Brande. Permission has been granted to copy, distribute and modify gd in version. You may also choose to use such covered code under the terms of any context without fee, including a commercial application, provided that any subsequent version of the license published by the PHP Group. No one this notice is present in user-accessible supporting documentation. This other than the PHP Group has the right to modify the terms applicable to does not affect your ownership of the derived work itself, and the intent is to covered code created under this License. assure proper credit for the authors of gd, not to interfere with your productive use of gd. If you have questions, ask. "Derived works" includes all 6. Redistributions of any form whatsoever must retain the following programs that utilize the library. Credit must be given in user-accessible acknowledgment: documentation. This software is provided "AS IS." The copyright holders disclaim all warranties, either express or implied, including but not limited to "This product includes PHP, freely available from
with or without fee is hereby granted, provided that the above copyright For more information on the PHP Group and the PHP project, please see
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY This product includes software written by Tim Hudson ([email protected]). KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR Copyright (c) 2003, Itai Tzur
Copyright (c) 1999 - 2004 The PHP Group. All rights reserved. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, Redistribution and use in source and binary forms, with or without INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF modification, is permitted provided that the following conditions are met: MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. FireWall-1_GX.book Page 129 Tuesday, March 27, 2007 10:03 AM
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, The material in document is provided with "RESTRICTED RIGHTS." Software SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT and accompanying documentation are provided to the U.S. government NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; ("Government") in a transaction subject to the Federal Acquisition LOSS OF USE, DATA, OR PROFITS; OR BUSINESS Regulations with Restricted Rights. The Government's rights to use, modify, reproduce, release, perform, display or disclose are INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING restricted by paragraph (b)(3) of the Rights in Noncommercial Computer NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF Software and Noncommercial Computer Soft-ware Documentation clause at THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DFAR 252.227-7014 (Jun 1995), and the other restrictions and terms in DAMAGE. paragraph (g)(3)(i) of Rights in Data-General clause at FAR 52.227-14, Alternative III (Jun 87) and paragraph (c)(2) of the Commer-cial Copyright (c) 1998, 1999, 2000 Thai Open Source Software Center Ltd Computer Software-Restricted Rights clause at FAR 52.227-19 (Jun 1987). Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal Use of the material in this document by the Government constitutes in the Software without restriction, including without limitation the rights to acknowledgment of NextHop's proprietary rights in them, or that of the use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies original creator. The Contractor/Licensor is NextHop located at 1911 of the Software, and to permit persons to whom the Software is furnished to Landings Drive, Mountain View, California 94043. Use, duplication, or do so, subject to the following conditions: The above copyright notice and this disclosure by the Government is subject to restrictions as set forth in permission notice shall be included in all copies or substantial portions of the applicable laws and regulations. Software. Disclaimer Warranty Disclaimer Warranty Disclaimer Warranty Disclaimer THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY Warranty KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR THE MATERIAL IN THIS DOCUMENT IS PROVIDED "AS IS" WITHOUT PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS WARRANTIES OF ANY KIND EITHER EXPRESS OR IMPLIED. TO THE OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR FULLEST EXTENT POSSIBLE PURSUANT TO THE APPLICABLE LAW, OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR NEXTHOP DISCLAIMS ALL WARRANTIES, OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR Copyright © 2003, 2004 NextHop Technologies, Inc. All rights reserved. PURPOSE, NON INFRINGEMENT OR OTHER VIOLATION OF RIGHTS. NEITHER NEXTHOP NOR ANY OTHER PROVIDER OR DEVELOPER OF Confidential Copyright Notice MATERIAL CONTAINED IN THIS DOCUMENT WARRANTS OR MAKES ANY REPRESEN-TATIONS REGARDING THE USE, VALIDITY, ACCURACY, OR Except as stated herein, none of the material provided as a part of this RELIABILITY OF, OR THE RESULTS OF THE USE OF, OR OTHERWISE document may be copied, reproduced, distrib-uted, republished, RESPECTING, THE MATERIAL IN THIS DOCUMENT. downloaded, displayed, posted or transmitted in any form or by any means, including, but not lim-ited to, electronic, mechanical, photocopying, Limitation of Liability recording, or otherwise, without the prior written permission of NextHop Technologies, Inc. Permission is granted to display, copy, distribute and UNDER NO CIRCUMSTANCES SHALL NEXTHOP BE LIABLE FOR ANY download the materials in this doc-ument for personal, non-commercial use DIRECT, INDIRECT, SPECIAL, INCIDENTAL OR CONSEQUENTIAL only, provided you do not modify the materials and that you retain all copy- DAMAGES, INCLUDING, BUT NOT LIMITED TO, LOSS OF DATA OR PROFIT, right and other proprietary notices contained in the materials unless ARISING OUT OF THE USE, OR THE INABILITY TO USE, THE MATERIAL IN otherwise stated. No material contained in this document may be "mirrored" THIS DOCUMENT, EVEN IF NEXTHOP OR A NEXTHOP AUTHORIZED on any server without written permission of NextHop. Any unauthorized use REPRESENTATIVE HAS ADVISED OF THE POSSIBILITY OF SUCH of any material contained in this document may violate copyright laws, DAMAGES. IF YOUR USE OF MATERIAL FROM THIS DOCUMENT RESULTS trademark laws, the laws of privacy and publicity, and communications IN THE NEED FOR SERVICING, REPAIR OR CORRECTION OF EQUIPMENT regulations and statutes. Permission terminates automatically if any of these OR DATA, YOU ASSUME ANY COSTS THEREOF. SOME STATES DO NOT terms or condi-tions are breached. Upon termination, any downloaded and ALLOW THE EXCLUSION OR LIMITATION OF INCIDENTAL OR printed materials must be immediately destroyed. CONSEQUENTIAL DAMAGES, SO THE ABOVE LIMITATION OR EXCLUSION MAY NOT FULLY APPLY TO YOU. Trademark Notice Copyright © ComponentOne, LLC 1991-2002. All Rights Reserved. The trademarks, service marks, and logos (the "Trademarks") used and displayed in this document are registered and unregistered Trademarks of BIND: ISC Bind (Copyright (c) 2004 by Internet Systems Consortium, Inc. NextHop in the US and/or other countries. The names of actual companies ("ISC")) and products mentioned herein may be Trademarks of their respective owners. Nothing in this document should be construed as granting, by Copyright 1997-2001, Theo de Raadt: the OpenBSD 2.9 Release implication, estoppel, or otherwise, any license or right to use any Trademark displayed in the document. The owners aggressively enforce their intellectual PCRE LICENCE property rights to the fullest extent of the law. The Trademarks may not be used in any way, including in advertising or publicity pertaining to distribution PCRE is a library of functions to support regular expressions whose syntax of, or access to, materials in and semantics are as close as possible to those of the Perl 5 language. Release 5 of PCRE is distributed under the terms of the "BSD" licence, as this document, including use, without prior, written permission. Use of specified below. The documentation for PCRE, supplied in the "doc" Trademarks as a "hot" link to any website is prohibited unless establishment directory, is distributed under the same terms as the software itself. of such a link is approved in advance in writing. Any questions concerning the use of these Trademarks should be referred to NextHop at U.S. +1 734 Written by: Philip Hazel
+44 1223 334714.
Copyright (c) 1997-2004 University of Cambridge All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
* Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/ or other materials provided with the distribution.
* Neither the name of the University of Cambridge nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. FireWall-1_GX.book Page 131 Tuesday, March 27, 2007 10:03 AM
Index
DoS 39, 68 echo stateful inspection 38 Numerics error indication 67 in GTP 42 3G 15 mobility management 39 E path management 38 PDU integrity tests 66 Echo Request Flooding 94 protocol enforcement 31 A End User Address Modes 37 protocol integrity 31 End User Domain 65 protocol timelines 31 Access Point Name 60 ETSI 14 security 24 Alerts 83 Excessive Logs Protection 84 service filter 36, 59 APN signal packet rate limit creating object 60 enforcement 39 in security policy 62 Stateful Inspection 31 wildcard matching 44 F tunnel management 35 APN Selection Mode version 0 53, 90 GTP service filters 36 flow label 66 version 1 21, 53 GTP anti-spoofing 41 APN, see Access Point Name Flow Labels GTP services validation 36 customizing 59 GTP, security 30 B GTP-aware G Security Policy 34 Border Gateways, deploying GUI Dbedit GX 27 Glossary 20 adjusting settings 72 G-PDU 67 GPRS 15 C GSM 14 GSMA 25 H CEPT 14 GSN Handover 37 Close PDP Contexts address filtering 34 GSN address filtering 34 using FW SAM 69 creating handover groups 50 Handover Groups 34, 38 creating objects 49 Control Plane 21 creating 50 Create PDP Context 22 illegal handover 96 illegal redirection 96 GSN handover group 50 GSN Handover Groups 37 I D GTP accounting 83 IMSI Prefix 60 Delete PDP Context 67 anti-spoofing 41 LDAP 60 Denial of Service 24 awareness 26, 30 Interface Denial of Service, see DoS differences between multiple GGSN support 37 Deploying GX, Border versions 90 Interfaces 19 echo exchange 39 Gateways 27 Gi 25 echo rate 39 DHCP 22 Gn 25
March 2007 131 FireWall-1_GX.book Page 132 Tuesday, March 27, 2007 10:03 AM
Gp 25 Overbilling Attack, solution 32 multiple GGSN interface IP address 60 support 37 Signalling Request PDU 101 P SmartView Reporter 85 L SNMP 89 packet integrity 101 LDAP Group Path Management 38 GTP service filters 36 PDP Context 60, 67 T match 60 multiple 21 Limit Echo Rate 39 PDP context creation Teardown flag, deleting 22 linked NSAPI 22 GSN address filtering 34 Timeslots 15 load balancing 37 PDP context update 22 T-PDU 44 Logs 83 GSN address filtering Tunnel Management 35 34 PDP Contexts, deleting 33 PDU Integrity Tests 66 M PDUs U data from unmatched 83 Management UDP port 2123 21 mobility 39 UDP port 2152 21 path 38 UDP port 3386 21 tunnel 35 Q UMTS 15 Match with LDAP Group 60 Unmatched PDUs 83 MIB 89 QoS 21 Update PDP Context 67 MMS Over WAP 47 Quality of Service, see QoS user plane 21 configuration 63 user plane traffic 44 Mobile IP 22 User Traffic 35 Mobile Station 62 Mobility Management 39 R Monitor-Only Mode 88 MS to MS Enforcement 44 Redirection 37 V MS-ISDN GSN address filtering 34 LDAP 60 Release Notes, location of 26 Verify Flow Labels 66 MS-ISDN Prefix 60 Multiple GGSN Interface Support 37, 38 S W
SAM API 100 WAP 47 N Secondary PDP Context customizing 63 Activation 22 MMS over 47 NSAPI 22 Security Policy redirection 47 GTP-aware 34 Security Rules creating 50 O Selection Mode 60 Sequence Number 66 Overbilling Attack validation 36 enabling protection 54 Session Hijacking overbilling attack 31 GSN handover groups 37 Overbilling Attack, concept 31
132