Embed Size (px)
Citation preview
VPN-1 Power/UTMAdministration guide
Version NGX R65.2.100
January 15, 2009
© 2003-2009 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:
Please refer to http://www.checkpoint.com/copyright.html for a list of our trademarks
For third party notices, see http://www.checkpoint.com/3rd_party_copyright.html.
Table of Contents 5
Contents
Preface Who Should Use This Guide.............................................................................. 12Summary of Contents ....................................................................................... 13More Information ............................................................................................. 15Feedback ........................................................................................................ 16
Chapter 1 Overview Introduction to NGX R65.2.100........................................................................ 18VoIP Security Deployment Scenarios.................................................................. 19
Enterprise Deployment 1: Perimeter VoIP Gateway ......................................... 19Enterprise Deployment 2: LAN segmentation................................................. 21Service Provider Deployment........................................................................ 22
Supported VoIP Protocols ................................................................................. 23Signaling and Media Protocols ..................................................................... 23
Supported VoIP Standards ................................................................................ 25Supported SIP RFCs and Standards.............................................................. 25Supported MGCP RFCs and Standards .......................................................... 25Supported H.323 Protocols and Standards.................................................... 25
VoIP Logging ................................................................................................... 26Predefined VoIP Queries in SmartView Tracker............................................... 26
Licensing Requirements ................................................................................... 29
Chapter 2 Performing a Basic Configuration Workflow for Basic Configuration ....................................................................... 32Setting Up a Basic Configuration....................................................................... 33
Logging in to SmartDashboard ..................................................................... 34Defining the VPN-1 Power/UTM Gateway....................................................... 34Defining the Endpoints................................................................................ 37Defining the Security Rule ........................................................................... 38Installing the Security Policy........................................................................ 38Testing the Configuration............................................................................. 38
Chapter 3 Tour of SmartDashboard for VoIP The VoIP Tab................................................................................................... 42
Enforcing Gateways..................................................................................... 42SmartDefense VoIP Protections .................................................................... 42VoIP Application Policy ............................................................................... 42Application Policy ....................................................................................... 43VoIP Entities and Topology .......................................................................... 44QoS........................................................................................................... 44Advanced................................................................................................... 44Application Policy for All VoIP Protocols........................................................ 44
6
SmartDefense VoIP Protections ......................................................................... 45Monitor-Only Mode .......................................................................................... 47
Chapter 4 VoIP Entities and Topology VoIP Servers.................................................................................................... 50
The Purpose of VoIP Servers ........................................................................ 50SIP Server Types ........................................................................................ 50Hide NAT for SIP traffic .............................................................................. 51Hide NAT for MGCP traffic .......................................................................... 53Configuring Short Extension Numbers for SIP ................................................ 55
VoIP Endpoints................................................................................................ 57Media Admission Control .................................................................................. 58
Definition of Media Admission Control .......................................................... 58Establishing a VoIP Call: A Typical Flow........................................................ 58The Importance of Media Admission Control.................................................. 59Configuring Media Admission Control............................................................ 60Media Admission Control Decision Flow Chart................................................ 64
Entity Protection Summary ............................................................................... 65Understanding the Entity Protection Summary............................................... 66
Chapter 5 Emergency Numbers How the Gateway Handles Emergency Calls........................................................ 72Configuring Emergency Numbers....................................................................... 73
Chapter 6 Far End NAT Traversal The VoIP NAT Challenge................................................................................... 76The Far End NAT Traversal Solution .................................................................. 76NGX R65.2.100 NAT Deployments ................................................................... 77How Far End NAT Traversal works ..................................................................... 79
Pinhole Maintenance through NAT Devices ................................................... 79NAT on the signaling and Media Payloads ..................................................... 80
VoIP Server and Endpoint Compliance ............................................................... 82Ports and Addresses for Signaling and Media ..................................................... 83
Signaling and Media Port Allocation ............................................................. 83Choosing the Media Port Range.................................................................... 83
Configuring Far End NAT Traversal for SIP ......................................................... 85Defining the VoIP gateway ........................................................................... 85Configuring Far End NAT Traversal for the Gateway ........................................ 86Configuring the Client SIP Phones................................................................ 92Security Rule Base Configuration ................................................................. 92
Chapter 7 Rate Limiting DoS Protection Introduction to Denial of Service Protection........................................................ 94Rate limiting Protections .................................................................................. 95Configuring Rate Limiting Protections................................................................ 96Non SIP Entities Rate Limiting ......................................................................... 98
Non SIP Entities Rate Limiting Configuration Details ..................................... 98
Table of Contents 7
SIP Servers Rate Limiting............................................................................... 100SIP Servers Rate Limiting Configuration Details ........................................... 101
SIP Endpoints Rate Limiting........................................................................... 106SIP Endpoints Rate Limiting Configuration Details ....................................... 106SIP Internal Networks Rate Limiting Configuration Details ............................ 107
Chapter 8 Quality of Service Introduction to QoS for NGX R65.2.100 .......................................................... 110Per Gateway QoS ........................................................................................... 111
Call Admission Control .............................................................................. 111Traffic Policy............................................................................................ 111Gateway Specific Settings.......................................................................... 112
Per Server QoS .............................................................................................. 113SIP Block Calls from Unregistered Users ..................................................... 113
DiffServ Marking of VoIP Data Packets............................................................. 114DiffServ and Expedited Forwarding ............................................................. 114Configuration Details................................................................................. 114
Chapter 9 RTP/RTCP SmartDefense Protections RTP SmartDefense Protections........................................................................ 118
Block multicast RTP connections ............................................................... 118Block non Version 2 RTP Packets ............................................................... 119Block multiple Synchronization Sources (SSRC) - RTP ................................. 119Validate ports parity (even) ........................................................................ 119Validate payload size................................................................................. 120Validate Extension .................................................................................... 120Validate CC field....................................................................................... 120
RTCP SmartDefense Protections...................................................................... 121Block multicast RTCP connections ............................................................. 121Block multiple Synchronization sources (SSRC) - RTCP................................ 122Validate port’s parity (odd)......................................................................... 122Validate length ......................................................................................... 122
RTP/RTCP protections with SecureXL .............................................................. 124
Chapter 10 SIP Application Policy Methods Unsupported by SIP Server................................................................ 126
Application Policy Details .......................................................................... 126Block Unsupported SIP Commands Configuration Details ............................. 127
Early Media................................................................................................... 129Proxy Redirecting a Call to a Non-Configured Proxy ........................................... 129Proxy Failover ................................................................................................ 130Video............................................................................................................ 131Audio ........................................................................................................... 131Instant Messaging.......................................................................................... 131Push to Talk over Cellular ............................................................................... 131
Chapter 11 SIP SmartDefense Protections
8
Block Notify messages with Invalid Subscription-State Header ........................... 134Block Basic Authorization............................................................................... 135Maximum allowed retransmissions................................................................... 136SIP Header Spoofing...................................................................................... 137Block Unrecoverable SIP Inspection Errors....................................................... 139SIP Protocol Anomaly Protections.................................................................... 140
Introduction to SIP Protocol Anomaly Protections ........................................ 140Strict protocol flow enforcement................................................................. 141Max allowed Header Name length............................................................... 142Max allowed Header Value length ............................................................... 142Max allowed URI length............................................................................. 142Max allowed Domain length ....................................................................... 143Max allowed Call-ID length ........................................................................ 143Max allowed Tag length ............................................................................. 144Max allowed SDP line length...................................................................... 144General header security ............................................................................. 146Specific header security ............................................................................ 149
Chapter 12 SIP Rule Base Configuration Supported SIP Deployments and NAT Support.................................................. 158
Additional Conditions for Using NAT in SIP Networks................................... 159SIP-Specific services ..................................................................................... 161General Guidelines for SIP Security Rule Configuration ..................................... 162SIP Rules for a Peer-to-Peer No-Proxy Topology ................................................ 163SIP Rules for a Proxy in an External Network.................................................... 164SIP Rules for a Proxy-to-Proxy Topology ........................................................... 166SIP Rules for a Proxy in DMZ Topology ............................................................ 168Using SIP on a Non-Default Port ..................................................................... 170Enabling Dynamic Opening of Ports for SIP Signaling........................................ 171
Example Rule With the sip_dynamic_ports Service....................................... 171
Chapter 13 SIP Advanced Configuration Gateway Clustering Support for SIP ................................................................. 174
Synchronizing SIP Connections .................................................................. 174Load Sharing of SIP Connections ............................................................... 175
Multicast Support for SIP ............................................................................... 175Configuring SIP-T Support .............................................................................. 176Troubleshooting SIP....................................................................................... 176
Chapter 14 Inspection of TLS-Secured SIP Traffic Introduction to TLS........................................................................................ 178The Check Point SIP TLS Solution................................................................... 179
A Typical TLS-Secured Connection ............................................................. 179Workflow for Configuration of TLS-secured SIP ................................................. 181Configuring TLS-Secured SIP.......................................................................... 183
Choosing the TLS-Related Service .............................................................. 183Configuring the Rule for sip_tls_authentication............................................ 184
Table of Contents 9
Configuration Using the sip_tls_with_server_certificate Service ..................... 185Legacy Solution for SIP TLS Support .......................................................... 199
Chapter 15 MGCP-Based VoIP Introduction to MGCP..................................................................................... 202Supported MGCP RFCs and Standards............................................................. 203MGCP SmartDefense Protections..................................................................... 204
Max length of header value ........................................................................ 204Block unrecoverable MGCP inspection errors ............................................... 205MGCP Protocol Anomaly Protections ........................................................... 205
MGCP Application Policy ................................................................................ 210Commands Unsupported by MGCP Server ................................................... 210Fax.......................................................................................................... 213
MGCP Supported Deployments and NAT Support.............................................. 214Additional Conditions for Using NAT in MGCP Networks ............................... 216
Rule Base Configuration for MGCP .................................................................. 217MGCP-Specific services............................................................................. 217MGCP Rules for a Call Agent in the External Network ................................... 217MGCP Rules for Call Agent in DMZ............................................................. 218MGCP Rules for Call Agent to Call Agent ..................................................... 219
Chapter 16 H.323-Based VoIP Introduction to H.323 .................................................................................... 222Supported H.323 Protocols and Standards....................................................... 223
Signaling and Media Protocols for H.323 .................................................... 223Supported H.323 Standards ...................................................................... 223
H.323 SmartDefense Protections .................................................................... 224Introduction to SmartDefense for H.323 ..................................................... 224The SmartDefense H.323 Branch............................................................... 224Block sessions that do not start with Setup message .................................... 225H.323 Protocol Anomaly Protections .......................................................... 225
H.323 Application Policy ............................................................................... 230Introduction to H.323 Application Policy .................................................... 230Sessions that use H.245 Tunneling ............................................................ 230T.120...................................................................................................... 230H.323 connection from RAS messages ....................................................... 230
Supported H.323 Deployments and NAT Support ............................................. 232H.323 Security Rule Base Configuration .......................................................... 235
H.323 Specific Services............................................................................ 235General Guidelines for H.323 Security Rule Configuration ............................ 236H.323 Rule for an Endpoint-to-Endpoint Topology ....................................... 237H.323 Rules for a Gatekeeper-to-Gatekeeper Topology ................................. 238H.323 Rules for a Gateway-to-Gateway Topology.......................................... 239H.323 Rules for a Gatekeeper in the External Network ................................. 240H.323 Rules for a Gateway in the External Network ..................................... 241H.323 Rules for a Gatekeeper in DMZ Topology........................................... 243H.323 Rules for a Gateway in DMZ Topology ............................................... 244
10
Chapter 17 SCCP-Based VoIP Introduction to SCCP Security and Connectivity ................................................ 248Encrypted Protocol Support ............................................................................ 249SCCP SmartDefense Protections...................................................................... 250
Max Allowed SCCP Message Length............................................................ 250Verify SCCP State Machine ........................................................................ 250Verify SCCP Header Content ...................................................................... 250Block unrecoverable SCCP Inspection Errors ............................................... 251
SCCP Application Policy................................................................................. 252Block Unknown SCCP Messages................................................................. 252
SCCP Supported Deployments ........................................................................ 253Configuring SCCP Connectivity and Security..................................................... 255
General Guidelines for SCCP Security Rule Configuration ............................. 255SCCP-Specific services.............................................................................. 256Configuring the Rule Base for SCCP ........................................................... 256Configuring SmartDefense and Application Policy for SCCP .......................... 257
Chapter 18 Alcatel-Based VoIP Alcatel Security and Connectivity .................................................................... 260
Supported Alcatel Protocols ....................................................................... 260Configuring Alcatel Connectivity and Security ................................................... 261
Predefined Alcatel Services ....................................................................... 261Configuring the Rule Base for Alcatel.......................................................... 261Configuring Media Access control for Alcatel Call Servers ............................. 262
11
Preface PPreface
In This Chapter
Who Should Use This Guide page 12
Summary of Contents page 13
More Information page 15
Feedback page 16
12
Who Should Use This GuideThis 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.).
13
Summary of ContentsThis guide describes how to administer VPN-1 Power/UTM NGX R65.2.100. It contains the following sections and chapters:
Chapter Description
Chapter 1, “Overview” General overview and a summary of NGX R65.2.100 connectivity, security, and management features.
Chapter 2, “Performing a Basic Configuration”
How to set up a basic VoIP configuration. The example configuration enables SIP calls between endpoints on both sides of a VPN-1 Power/UTM gateway, and within the internal network.
Chapter 3, “Tour of SmartDashboard for VoIP”
VoIP options are located in two areas of SmartDashboard: The SmartDefense tab, and the VoIP tab. This chapter will help you find your way around SmartDashboard.
Chapter 4, “VoIP Entities and Topology”
VoIP Servers and VoIP endpoints are the building blocks of VoIP security. Media admission control restricts the ability of a VoIP Server to enable an endpoint to send media directly to another endpoint.
Chapter 5, “Emergency Numbers”
How to configure Check Point gateways to allow SIP calls to and from any number that is configured as an emergency number.
Chapter 6, “Far End NAT Traversal”
Check Point gateways make it possible to deliver VoIP services across territorial boundaries, without NAT and firewall devices limiting that capability, and without changing the established IP infrastructure. This functionality is referred to as Far End NAT traversal.
Chapter 7, “Rate Limiting DoS Protection”
SmartDefense protections against rate-based denial of service attacks.
Chapter 8, “Quality of Service”
Assuring levels of service for SIP by means of Per Gateway QoS, Per Server QoS, and DiffServ Marking.
Chapter 9, “RTP/RTCP SmartDefense Protections”
SmartDefense protections for RTP and RTCP for version NGX R65.2.100.
14
Chapter 10, “SIP Application Policy”
Configuring SIP application policy, in the SmartDashboard VoIP tab, under Application Policy > SIP.
Chapter 11, “SIP SmartDefense Protections”
SmartDefense protections for SIP for version NGX R65.2.100.
Chapter 12, “SIP Rule Base Configuration”
Security Rule Base configuration for SIP-based VoIP.
Chapter 14, “Inspection of TLS-Secured SIP Traffic”
How to configure Check Point gateways to decrypt and inspect TLS-secured SIP calls.
Chapter 13, “SIP Advanced Configuration”
Some advanced aspects of SIP configuration and troubleshooting.
Chapter 15, “MGCP-Based VoIP”
SmartDefense protections for MGCP-based VoIP, MGCP application policy, and Rule Base configuration.
Chapter 16, “H.323-Based VoIP”
SmartDefense protections for H.323 for version NGX R65.2.100, application policy configuration, and Security Rule Base configuration.
Chapter 17, “SCCP-Based VoIP”
SmartDefense protections for SCCP for version NGX R65.2.100, application policy configuration, and Security Rule Base configuration.
Chapter 18, “Alcatel-Based VoIP”
How to configure Security Rule Base rules so that the gateway allows UA calls.
Chapter Description
15
More InformationFor additional technical information about Check Point products, and for the latest version of this document, see the Check Point Support Center at http://support.checkpoint.com/.
16
FeedbackCheck Point is engaged in a continuous effort to improve its documentation. Please help us by sending your comments to:
17
Chapter 1Overview
In This Chapter
Introduction to NGX R65.2.100 page 18
VoIP Security Deployment Scenarios page 19
Supported VoIP Protocols page 23
Supported VoIP Standards page 25
VoIP Logging page 26
Licensing Requirements page 29
18
Introduction to NGX R65.2.100NGX R65.2.100 is a VoIP aware Check Point gateway offering comprehensive security for Enterprises, Telecom networks, and Service Provider VoIP environments.
The NGX R65.2.100 version of Check Point's leading security product VPN-1 Power/UTM, provides the highest levels of security, connectivity, and QoS, by using Check Point’s stateful inspection engine to analyze the VoIP traffic. NGX R65.2.100 is centrally managed by Check Point's management platforms.
The gateway includes Far End NAT Traversal functionality, which enables VoIP traffic to traverse NAT devices such as network layer firewalls and DSL modems, that are not VoIP aware.
VoIP traffic security includes features such as DoS/DDoS protection, protocol inspection, encryption, call filtering, and Quality of Service (QoS).
Topology awareness allows for highly granular configuration of connectivity and security per network and server type.
With NGX R65.2.100, Check Point’s gateway integrates firewall, VPN, and SBC components into a single gateway, thereby eliminating the need for additional VoIP session control devices. It is straightforward to install and configure.
NGX R65.2.100 provides monitoring mode and highly detailed logs, specifically tailored to VoIP traffic, making it easy to perform ongoing administration and troubleshooting.
NGX R65.2.100 interoperates with VoIP devices from many leading vendors, including Alcatel, Avaya, Cisco, Nokia, Nortel, and Siemens. It supports all major VoIP protocols, including SIP, H.323, MGCP, SCCP (Skinny), and Alcatel.
Chapter 1 Overview 19
VoIP Security Deployment ScenariosNGX R65.2.100 can be deployed by enterprises, managed service providers and telecom network providers.
Enterprise Deployment 1: Perimeter VoIP GatewayIn this enterprise deployment remote users and branch offices can make VoIP calls to and from the protected enterprise network by means of the Far End NAT capability of the gateway.
NGX R65.2.100 is used to set up IPsec encrypted VPNs. In the diagram, for example, a VPN can be set up between the main office branch offices. Security capabilities for VoIP include:
• Protecting servers and PBXs in the enterprise LAN against Denial of Service attacks.
• Preventing unauthorized phone calls by means of Media admission control. These checks allow only defined servers to set up calls for the phones.
20
Figure 1-1 NGX R65.2.100 in an Enterprise Deployment: Perimeter VoIP Gateway
Chapter 1 Overview 21
Enterprise Deployment 2: LAN segmentationIn this enterprise deployment, an NGX R65.2.100 gateway is used for internal LAN segmentation of VoIP and data traffic.
Dedicated gateways are deployed for VoIP security. Security is required to protect availability of VoIP equipment such as servers and PBXs within the enterprise LAN.
Figure 1-2 NGX R65.2.100 in an Enterprise Deployment: LAN Segmentation
22
Service Provider DeploymentA service provider deployment enables secure enterprise and residential VoIP services. Managed service providers use Far End NAT traversal to allow the use of VoIP protocols from private networks with internet connections using NAT. NGX R65.2.100 also makes it possible to implement strong security measures that are necessary to maintain a high quality of service.
Figure 1-3 NGX R65.2.100 in a Managed Service provider Deployment
Chapter 1 Overview 23
Supported VoIP ProtocolsVPN-1 Power/UTM secures VoIP traffic in H.323, SIP, MGCP, SCCP, and Alcatel environments.
VoIP calls use a series of complex protocols, each of which can carry potentially threatening information through many ports. Figure 1-4 illustrates the VoIP protocols supported by VPN-1.Figure 1-4 Secured VoIP Protocols: SIP, H.323, MGCP and SCCP
VPN-1 Power/UTM ensures that caller and recipient addresses are where they claim to be andthat the caller and recipient are allowed to make and receive VoIP calls. In addition, VPN-1examines the contents of the packets passing through every allowed port to ensure that theycontain the correct information. Full stateful inspection on H.323, SIP, MGCP, and SCCPcommands ensures that all VoIP packets are structurally valid, and that they arrive in a validsequence.
Signaling and Media ProtocolsA phone call on both an ordinary digital phone network and a VoIP network is made up of media and control signals. The voice conversation itself is the media stream. Dial tones and ringing tones, for example, are an indication that call control processes are taking place.
24
The various VoIP protocols all use very different technologies, though they have the same aims. As illustrated in Figure 1-4 on page 23, VoIP protocols handle the following call control (or gateway) control and media functions:
• Call Control (signaling): Responsible for setting up the call, finding the peer, negotiating coding protocols, making the connection, and ending the call.
• Gateway Control: Similar to call control, Gateway Control is responsible for communication between VoIP gateways, rather than between endpoint phones. These gateways act as intermediaries on behalf of the phones.
• Media: The actual voice. Both VoIP and ordinary phone networks use RTP/RTCP for the media. RTP carries the actual media and RTCP carries status and control information.
Control signals open both fixed (known) and dynamic ports. The parties of a call then use control signals to negotiate dynamically assigned ports that each side opens to receive the RTP/RTCP media stream.
In order to allow SIP conversations, you must create rules that permit SIP control signals in the VPN-1 gateway. There is no need to define a media rule that specifies which ports to open and which endpoints that can talk because VPN-1 derives this information from the signaling. Given a particular VoIP signaling rule, VPN-1 automatically opens ports for the endpoint-to-endpoint RTP/RTCP media stream.
Chapter 1 Overview 25
Supported VoIP Standards
Supported SIP RFCs and StandardsThe following SIP RFCs and standards are supported:
• RFC 3261 - The most recent SIP RFC.
• RFC 3372 - Session Initiation Protocol for Telephones (SIP-T).
• RFC 3311 - UPDATE message.
• RFC 2976 - INFO message.
• RFC 3515 - REFER message.
• RFC 3265 - SIP Events.
• RFC 3262 - Reliability of Provisional Responses.
• RFC 3428 - MESSAGE message.
• RFC 4566 - SDP Session Description Protocol
• RFC 3264 - An Offer-Answer Model with Session Description Protocol
• MSN messenger over SIP.
• SIP over TCP.
• SIP over UDP.
• SIP early media.
SIP can be configured using the standard, dynamic, and nonstandard ports.
Supported MGCP RFCs and StandardsSee “Supported MGCP RFCs and Standards” on page 203.
Supported H.323 Protocols and StandardsSee “Supported H.323 Protocols and Standards” on page 223.
26
VoIP LoggingSmartView Tracker displays detailed, protocol-specific logs for VoIP traffic. SIP, H.323, MGCP, SCCP and Alcatel events are logged in SmartView Tracker. There are also a number of predefined SmartView Tracker VoIP log queries. These logs provide enhanced troubleshooting capabilities.
SmartView Tracker logs are either Accept, Drop, or Monitor-Only logs. Drop logs have a Configuration field in log that gives the path to the SmartDefense protection or the application policy option in the VoIP tab that caused the Drop log.
If VoIP logging is disabled, then only standard logging takes place, showing the source, destination and protocol information.
Predefined VoIP Queries in SmartView TrackerIn Smartview Tracker, there are a number of predefined VoIP log queries:
The following queries are available:
Registration SessionThese are Accept logs. They are sent after successful registration. Displays the registration IP address, port and transport protocol (TCP/UDP), the registration period (in seconds), and the IP address of the registrar server.
Other SessionThese are Accept logs. They are sent after a final response to SIP requests such as MESSAGE and UPDATE. Displays the source IP address, port and phone number, the destination IP address, port and phone number, and the SIP request type.
To enable VoIP logging of... Configure the Track option to Log in the ...
VoIP calls Security Rule Base VoIP rule
SmartDefense protections SmartDefense protection
VoIP application policy Application policy option
Chapter 1 Overview 27
Security EventsThese are Drop or Monitor-Only logs. They are sent as a result of violation of the SmartDefense configuration in the Application Intelligence > VoIP > Protections for R65.2.100 section. Displays the source IP address, port and phone number, the destination IP address, port and phone number, information about the reason for sending the log (Attack and Attack Information fields), and the exact path to configure the relevant Smart Defense protection.
Call SessionThese are Accept logs. They are sent after a call is established, and updated after the call is closed. Displays the source IP address, port and phone number, the destination IP address, port and phone number, state of the call (open/closed),
28
duration (in seconds), direction (Inbound/Outbound), and information about the media (if there are several media streams, information is shown only about the first one).
Policy EventsThese are Drop or Monitor-Only logs. They are sent as a result of violation of the VoIP application policy in VoIP tab. Displays the source IP address, port and phone number, the destination IP address, port and phone number, information about the reason for sending the log (VoIP Reject Reason and VoIP Reject Reason Information fields), exact path to configure the relevant VoIP tab policy, etc.
Chapter 1 Overview 29
Licensing RequirementsThe following features require a VoIP license, in addition to the Check Point gateway license:
Feature SmartDashboard and Administration Guide
Locations
RTP/RTCP protections SmartDashboard
SmartDefense tab: Application Intelligence > VoIP > Protections for R65.2.100 > RTPRTCP
Administration Guide
“RTP SmartDefense Protections” on page 118“RTCP SmartDefense Protections” on page 121
Rate limiting protections SmartDashboard
SmartDefense tab: Application Intelligence > VoIP > Protections for R65.2.100 > Rate Limiting
Administration Guide
“Rate Limiting DoS Protection” on page 93
Far End NAT Traversal SmartDashboard
Check Point gateway: Advanced > VoIP page Internal Far End NAT Traversal
Administration Guide
“Far End NAT Traversal” on page 75
30
TLS encrypted inspection using the servicesip_tls_with_server_certificate
SmartDashboard
SIP Server, TLS page
Administration Guide
“Configuration Using the sip_tls_with_server_certificate Service” on page 185
QoS Per Gateway SmartDashboard
VoIP tab: QoS > Per Gateway > Call Admission Control Traffic policy
Administration Guide
“Call Admission Control” on page 111“Traffic Policy” on page 111
Media Admission Control SmartDashboard
VoIP tab: VoIP Entities and Topology > Media Admission Control
Administration Guide
“Media Admission Control” on page 58
Feature SmartDashboard and Administration Guide
Locations
31
Chapter 2Performing a Basic Configuration
This chapter describes how to set up a basic VoIP configuration. The example configuration makes it possible to make SIP calls between endpoints on both sides of a VPN-1 Power/UTM gateway, and within the internal network.
In This Chapter
Workflow for Basic Configuration page 32
Setting Up a Basic Configuration page 33
32
Workflow for Basic Configuration To perform a basic configuration:
1. Log in to SmartDashboard.
2. Define the VPN-1 Power/UTM gateway.
3. Define the VoIP server.
4. Define the endpoints.
5. Define the security rule.
6. Install the security Policy.
7. Test the configuration.
Chapter 2 Performing a Basic Configuration 33
Setting Up a Basic ConfigurationThis section explains the step by step procedure for setting up the following deployment.Figure 2-1 Basic SIP Test Setup
This procedure assumes that:
• The gateway and the SmartCenter components of VPN-1 Power/UTM are already installed.
• The VoIP phones in the external networks are not behind a NAT device (or they are behind a VoIP-aware NAT device). If the external phones are behind a basic NAT device that is not VoIP aware, you need to configure define Far-End NAT on the gateway. See “Far End NAT Traversal” on page 75.
In This Section
Logging in to SmartDashboard page 34
Defining the VPN-1 Power/UTM Gateway page 34
Defining VoIP Servers page 36
Defining the Endpoints page 37
Defining the Security Rule page 38
Installing the Security Policy page 38
Testing the Configuration page 38
34
Logging in to SmartDashboardThe login process authenticates the administrator. To authenticate as an administrator:
1. Open SmartDashboard by selecting Start > Programs > Check Point SmartConsole R65.4 > SmartDashboard.
2. Log in using the User Name and Password defined in the Configuration Tool’s Administrators page during SmartCenter server installation.
3. Specify the name or IP address of the target SmartCenter server and click OK.
4. Manually approve the fingerprint of the SmartCenter server, ensuring that it is the same as the fingerprint generated when the SmartCenter was configured.
Defining the VPN-1 Power/UTM GatewayThe VoIP tab is the central location for securing your VoIP infrastructure. All VoIP-related operations can be performed from here.
To define a VPN-1 Power/UTM gateway with advanced VoIP capability:
1. In SmartDashboard, click the VoIP tab.
2. In the left pane tree, click to select the Enforcing Gateways page.
Note - This step is only necessary the first time you log in.
Chapter 2 Performing a Basic Configuration 35
Figure 2-2 The Enforcing Gateways Page of the SmartDashboard VoIP Tab
3. To edit an existing gateway, select a gateway and click Edit.To create a new gateway, click New, and create the gateway object.
The Check Point Gateway - General Properties page opens.
4. Define the following required fields:
• Name
• IP address
• Version must be NGX R65.2.100.
• OS
• In the Check Point Products section, select at least Firewall.
5. In the Topology page, configure the gateway interfaces. To do so automatically, click Get > Interfaces with Topology
6. In the Check Point Gateway object, click the Advanced > VoIP page.
7. Configure Dynamic Pinholing.
Dynamically open ports for VoIP media channel opens dynamically assigned ports for media connections, according to the information in the signaling connection. This option is enabled by default. It should normally be selected when the VoIP connections pass through the gateway. It applies for SIP, H.323, MGCP and SCCP.
36
It is possible to disable dynamic pinholing for gateways of version NGX 65.2.100. For example, if the Check Point gateway protects another SBC which handles the opening of media connections and Far End NAT Traversal, there is no need for the gateway to open ports for the media connections. In that case it is more secure to disable this option
Defining VoIP Servers
It is possible to define VoIP servers. Defining VoIP servers makes for highly granular configuration of security and connectivity. For example, it is possible to define exceptions to the default configuration, that apply to specific VoIP servers.
To define a VoIP server:
1. In the VoIP tab, select the VoIP Entities and Topology > VoIP Servers page.
2. Click New…
3. Select the VoIP server type.
The General Properties page of the VoIP server opens.
4. In the General Properties page, choose a Name for the VoIP server (e.g. sip_server)
5. Define the VoIP Server host:
Note - Do not disable this option if Use Internal SIP Far End NAT Traversal is enabled
Chapter 2 Performing a Basic Configuration 37
a. Click Manage…
b. Click New…
c. The Host Node window, General Properties page opens.
d. Type a Name for the host (e.g. sip_server_host), and specify its IP address.
e. Click OK. This brings you back to the General Properties page of the VoIP server object.
Defining the SIP Server TypeFor SIP, it is possible to define the VoIP server type. This makes it possible to configure certain SmartDefense protections for SIP according to the server type. The supported server types are proxy, registrar, and presence.
1. In the General Properties page of the SIP server object, define the Server Type. Select one or more of SIP proxy, SIP Registrar and SIP Presence. A SIP server defined as a SIP proxy is also a registrar and a presence server.
2. Click OK.
Defining the EndpointsDefine the internal VoIP phones (endpoints) by defining the networks to which they belong. There is no need to define the external phones.
To define networks for the internal endpoints:
1. In the VoIP tab, select the VoIP Entities and Topology > VoIP Endpoints page.
2. Click Add…
38
The Add VoIP Endpoints page opens.
3. Either define a new network, or specify a previously defined network.
• To define a new network:
A. Click New… > Network. The Network Properties window opens.
B. Define the Name (e.g. Internal_net), Network Address and Net Mask.
C. Click OK. This brings you back to the Add VoIP Network page
D. Select the newly defined network, and click Add.
• To specify a previously defined network (e.g. Internal_net), select the network and click Add.
Defining the Security RuleConfigure a simple Security Rule Base rule to allow traffic between the endpoints on each side of the VPN-1 Power/UTM gateway.
To allow traffic between the endpoints:
1. Click the Security tab.
2. Add the following rule:
Installing the Security PolicyFrom the SmartDashboard main menu, select Policy > Install… and Install the security Policy.
Testing the ConfigurationTest the configuration by making phone calls:
Source Destination Service Action
internal-net sip_server_host
sip_server_hostinternal-net
sipsip_dynamic_portssip-tcp
Accept
Note - In the Install On cell of the rule, include the VPN-1 Power/UTM gateway.
Chapter 2 Performing a Basic Configuration 39
• Within the internal network.
• From an internal phone to an external phone.
• From an external phone to an internal phone.
After making each call, view the resulting logs in SmartView Tracker.
To view the VoIP logs:
1. From the SmartDashboard main menu, select Window > SmartView Tracker.
Smartview Tracker opens.
2. Select the VoIP > Call Session filter.
3. Examine the resulting logs.
Figure 2-3 on page 40 shows a typical Call Session VoIP log for a successful inbound call from an external phone to an internal phone. See the Call Direction field in the Record Details window of the log. The call is from Source IP-phone 5004 to Destination IP-phone 5002. Refer to Figure 2-1 on page 33 to see the network layout
The Source IP-phone and Destination IP-phone fields show the phone extension (that is, the user), whether or not a proxy is involved.
The Source and Destination fields (click More Information to see them) show the connection though the gateway. For example, if the internal phone makes a connection to the SIP Server, the Source field shows the sip_server_host node (refer to Figure 2-1 on page 33).
40
Figure 2-3 Example of a Call Session VoIP Log
41
Chapter 3Tour of SmartDashboard for VoIP
VoIP options are located in two areas of SmartDashboard: The SmartDefense tab and the VoIP tab. This chapter will help you find your way around the VoIP sections of SmartDashboard.
In This Chapter
The VoIP Tab page 42
SmartDefense VoIP Protections page 45
Monitor-Only Mode page 47
42
The VoIP TabAll VoIP-related configuration can be performed from the VoIP tab.
This section summarizes the purpose of each section of the VoIP tab.
Enforcing GatewaysCreate and edit advanced VoIP-aware Check Point gateways. All Check Point gateways are shown.
VoIP-related configuration is performed in the Advanced > VoIP page of the Check Point gateway.
SmartDefense VoIP Protections Summary view of all SmartDefense VoIP Protections. View and configure the settings of each protection, per profile.
VoIP Application PolicySummary view of the Application Policy options. View and configure the settings for each option.
Chapter 3 Tour of SmartDashboard for VoIP 43
The summary view shows the following information:
Application PolicyAn organization may decide to block certain VoIP services because they consume more bandwidth than the IP infrastructure can support, or because they do not comply with the organization’s policy.
Application Policy options limit the VoIP services available to users.
Application Policy options are not intended to protect against attacks, which is the role of SmartDefense.
Application Policy options are available for the following VoIP protocols:
• Application Policy for All VoIP Protocols
• SIP Application Policy
• MGCP Application Policy
• H.323 Application Policy
• SCCP Application Policy
Category Name Policy Details
Location of the option in the Application Policy section of the VoIP tab.
Name of the application policy option.
Change the policy by moving the slider to one of the following settings:
Drop: The Application Policy option is active (on). Do not allow traffic that matches this Application Policy option. No response is sent to the client and the connection will eventually time out.
Monitor-only: Allow all traffic, but log the traffic as if the Policy is Drop.
Accept: Allow all traffic. The Application Policy option is inactive (off).
More information.
44
VoIP Entities and TopologyThe VoIP Entities and Topology section allows you to:
• Create and edit VoIP Servers and VoIP Endpoints
• Configure Media Admission Control for VoIP servers.
• Entity Protection Summary allows you to see at a glance how each gateway handles traffic from and to a given VoIP entity, for each application policy option and SmartDefense protection.
QoSAssure service levels for SIP by means of:
• Per Gateway QoS: Set a limit to the number of allowed concurrent SIP calls, and a limit to the maximum overall bandwidth allowed for SIP calls.
• Per Server QoS: Blocks SIP calls from unregistered users.
• DiffServ Marking of VoIP Data Packets: Marks all VoIP data packets, such as RTP and RTCP, though the gateway with the DiffServ encoding for expedited forwarding.
Advanced• Configure Emergency Numbers. SIP calls to/from those phone numbers are
inspected but not dropped.
• Configuring External Trusted CAs is normally done while Configuring TLS-Secured SIP.
Application Policy for All VoIP Protocols
Sessions with Data Connections from Port <1024This option verifies that RTP data sessions (Audio and Video, for example), do not use a connection with a well known port number (<1024). It is enforced for SIP, MGCP, H.323 and SCCP. Opening a well known port (port 80 for HTTP, for example), allows the gateway sessions for any application using that port to pass through. The default is to drop sessions with data connections that use a well known port.
Chapter 3 Tour of SmartDashboard for VoIP 45
SmartDefense VoIP Protections SmartDashboard includes VoIP-comprehensive SmartDefense protections for gateways of version NGX R65.2.100. Gateways of previous versions have the same protections as do gateways managed by SmartCenter NGX R65. VoIP protections are located in the SmartDefense protections tree at Application Intelligence > VoIP. They are organized as follows:
Protections for Other Versions Purpose
• H.323
• SIP
• MGCP
• SCCP (Skinny)
SmartDefense protections organized according to VoIP protocol. These protections are supported on gateways of version R65 and lower.
Protections for R65.2.100 Purpose
• Monitor-only for protections Monitor-only inspects traffic without blocking it. No packets are dropped, but intrusions are logged. Monitor-only can be be configured either globally, or per VoIP Application Policy option, or per SmartDefense VoIP protection. The global settings override the individually configured settings.See “Monitor-Only Mode” on page 47.
• Exceptions list for all VoIP Protections
A “white list” of VoIP networks to which the protections do not apply. Packets where these IPs appear in the source or destination are allowed.
46
• Rate Limiting Rate limiting protections prevent rate-based application level denial of service attacks. Traffic that exceeds administrator configured thresholds is blocked. Thresholds can be configured for all SIP internal networks, and for particular SIP servers or endpoints. Protections are also available for non-SIP VoIP servers in the internal network. See “Rate Limiting DoS Protection” on page 93.
• RTP See “RTP SmartDefense Protections” on page 118
• RTCP See “RTCP SmartDefense Protections” on page 121
• SIP See “SIP SmartDefense Protections” on page 133
• MGCP See “MGCP SmartDefense Protections” on page 204
• H.323 See “H.323 SmartDefense Protections” on page 224
• SCCP (Skinny) See “SCCP SmartDefense Protections” on page 250
Protections for R65.2.100 Purpose
Chapter 3 Tour of SmartDashboard for VoIP 47
Monitor-Only ModeMonitor-only inspects VoIP traffic without blocking it. No packets are dropped, but intrusions are logged in SmartView Tracker.
Monitor-only mode is useful for observing traffic during the deployment process in order to create appropriate settings, and also for debugging connectivity problems. Monitor-only mode also enables an audit-only deployment of SmartDefense and of the Application Policy options.
Monitor-only mode can be configured individually for each SmartDefense VoIP protection, and for each Application Policy option in the SmartDashboard VoIP tab.
Monitor-only mode can also be configured globally. Global settings override individually configured settings. Global configuration is performed in the following locations:
• SmartDefense > Application Intelligence > VoIP > Protections for R65.2.100 > Monitor-only for protections Switches on monitor-only for all protections in the VoIP > Protections for R65.2.100 section of SmartDefense.
• VoIP tab > Enforcing Gateways Switches on monitor-only for all the options in the VoIP Application Policy section of the VoIP tab.
48
49
Chapter 4VoIP Entities and Topology
In This Chapter
VoIP Servers page 50
VoIP Endpoints page 57
Media Admission Control page 58
Entity Protection Summary page 65
50
VoIP ServersIn This Section
The Purpose of VoIP ServersThe simplest method of communication between VoIP endpoints is to send both signaling and media from endpoint to endpoint. In many VoIP networks, however, the endpoints do not know the location of their peers. In this case, the call is managed by devices called VoIP Servers, which allow two (or more) remote peers to establish VoIP calls with each other. Examples of VoIP Servers for different VoIP signaling protocols are:
• SIP: Proxy server, Registrar, and Presence server.
• H.323: Gatekeeper and/or Gateway.
• MGCP: Call Agent (also called Media Gateway Controller).
• SCCP (Skinny): CallManager.
Defining VoIP servers makes for highly granular configuration of security and connectivity. SmartDefense protections can be configured to apply to specific VoIP servers, and in the VoIP tab, per-server configuration is available for VoIP application policy, QoS, and media admission control.
SIP Server TypesFor SIP, it is possible to define the following types of SIP server: Proxy, Registrar, and Presence.
• SIP Proxy: Services SIP requests by processing them and passing them along to other SIP servers. A proxy server may act as both a server and a client, and can modify a SIP request before passing it along. A proxy is involved only in the
The Purpose of VoIP Servers page 50
SIP Server Types page 50
Hide NAT for SIP traffic page 51
Hide NAT for MGCP traffic page 53
Configuring Short Extension Numbers for SIP page 55
Chapter 4 VoIP Entities and Topology 51
set-up and teardown of communications. Once a session is established, communications occur directly between the parties. A SIP server defined as a SIP proxy is also a registrar and a presence server.
• SIP Registrar: A server that accepts REGISTER requests. It registers users when they come on-line and stores information on the users logical identity. It also stores information about the associated device (identified by IP address or URL) or devices it will allow for communications. A registrar is typically co-located with a proxy or redirect server and may offer location services.
• SIP Presence Server: Accepts, stores, and distributes presence information. Callers can learn about the availability of the person they are trying to reach and how they wish to be contacted—before they try to contact that person. For example, when a user is on a phone, their status ("on the phone") can be automatically updated and communicated to a central presence server.
For details of how to configure a SIP server, see “Defining a SIP Proxy” on page 89.
Hide NAT for SIP traffic
Enabling the Hide NAT changes source port for VoIP traffic over UDP option configures the gateway to perform Hide NAT both on the IP address and on the source port of the SIP endpoint phones — for SIP over UDP traffic. (For SIP over TCP, the source port is always translated if there is Hide NAT.) With this option disabled, the gateway performs Hide NAT only on the IP address of the SIP endpoint phones. This option must be enabled in environments where:
1. The gateway is configured (in SmartDashboard) to perform Hide NAT on the internal IP addresses of the endpoints.
2. The SIP server can register only one endpoint with a given IP address and port combination (as is the case with Cisco Unified communications Manager).
An explanation follows of how this option works.
Note - The option described in this section is configured in the Advanced page of the SIP server object.
Note - In order for all internal phones to be registered successfully on the server, the source port of the REGISTER message sent by the phone must be the same as the port in the Contact header of the REGISTER message. In Cisco IP Phones, for example, this is done by selecting the "NAT Enabled" option.
52
SIP Packet Before NAT
The packet capture shown here shows a SIP packet from a phone with IP address 192.168.3.40, and source port 5060 (the default SIP port). The phone number is 4321.
Packet After Hide NAT When Option is Disabled
The packet capture shown here shows the SIP packet after Hide NAT, with the Hide
NAT changes source port for VoIP traffic option disabled. The IP address is translated to the Hide NAT address of 172.16.8.232, but the source port 5060 is unchanged.
In this case all the internal phones are registered with the same Source IP: port combination, for example: sip:[email protected]:5060. A phone with the number 8765 would be registered as sip:[email protected]:5060.
Certain SIP servers can register only a single phone with a given IP address and port combination. As a result, only one of the phones behind that IP address will be registered successfully on the server.
Chapter 4 VoIP Entities and Topology 53
Packet After NAT When Option Is Enabled
This packet capture shows the SIP packet after Hide NAT, with the NAT changes
source port for VoIP traffic option enabled. The IP address is translated to the Hide NAT address of 172.16.8.232, and the source port is also translated to an allocated port of 10015.
In this case a different port is allocated for each internal phone, so all phones are registered with different Source IP: port combination. For example: one phone as sip:[email protected]:10015 (as shown in the packet capture), and another phone with the number 8765 as (for example) sip:[email protected]:10016.
As a result, all internal phones are registered successfully on the server.
Hide NAT for MGCP traffic
Enabling the Hide NAT changes source port for VoIP traffic over UDP option configures the gateway to perform Hide NAT both on the IP address and on the source port of the MGCP endpoint phones. With this option disabled, the gateway performs Hide NAT only on the IP address of the MGCP endpoint phones. This option must be enabled in environments where:
1. The gateway is configured (in SmartDashboard) to perform Hide NAT on the internal IP addresses of the endpoints.
2. The MGCP server can register only one endpoint with a given IP address and port combination.
An explanation follows of how this option works.
Note - The option described in this section is configured in the Advanced page of the MGCP server object.
54
MGCP Packet Before NAT
The packet capture shown here shows an MGCP packet from a phone with IP address 194.90.147.53, and source port 2427 (the default MGCP port).
Packet After Hide NAT When Option is Disabled
The packet capture shown here shows the MGCP packet after Hide NAT, with the NAT changes source port for VoIP traffic option disabled. The IP address is translated to the Hide NAT address of 194.90.147.14, but the source port 2427 is unchanged.
In this case all the internal phones are registered with the same Source IP (for example 194.90.147.14) and the default MGCP source port (2427).
Certain MGCP servers can register only a single phone with a given IP address and port combination. As a result, only one of the phones behind that IP address will be registered successfully on the server.
Chapter 4 VoIP Entities and Topology 55
Packet After NAT When Option Is Enabled
The following packet capture shows the MGCP packet after Hide NAT, with this option enabled. The IP address is translated to the Hide NAT address of 194.90.147.14, and the source port is also translated, to an allocated port of 10416.
In this case a different port is allocated for each internal phone, so all phones are registered with a different Source IP: port combination. For example: one phone with source IP 194.90.147.14 and source port 10416 (as shown in the packet capture), and another phone with source IP 194.90.147.14 and source port 10417.
As a result, all internal phone are registered successfully on the server.
Configuring Short Extension Numbers for SIP
The Check Point gateway can be configured to support short extension numbers for SIP.
Endpoints register with the SIP server using their full name (which is usually a number). The gateway can be configured to identify a shortened name as belonging to an already registered endpoint, so that calls can be made and received to and from endpoints using a short extension name. The short extension name is a suffix of the full name. The length of the extension name is configurable.
For example, if the full name of an endpoint registered with the SIP server is [email protected], and the configured extension length is 4, then the gateway will be able to associate calls to/from [email protected] with the registered endpoint.
To configure support for short extension numbers for SIP:
1. In the SmartDashboard VoIP tab, in the VoIP Entities and Topology > VoIP Servers section, select the SIP Server that registers the endpoints, and click Edit.
2. Select the Advanced page.
56
3. Select Assume VoIP network uses extension length and insert the extension length, For this example, select 4.
4. Install the policy.
Configuring Support for a Range of Extension LengthsIf the SIP server supports a range of extension lengths, then the Check Point gateway has to be configured accordingly.
For example, if the IP address of the SIP server is 172.16.8.120 and it supports extensions of 3 to 5 digits, then configure the gateway as follows.
1. In the SmartDashboard VoIP tab, in the VoIP Entities and Topology > VoIP Servers section, select the SIP Server that registers the endpoints, and click Edit.
2. Select the Advanced page.
3. Select Assume VoIP network uses extension length and insert the maximum extension length. For this example, select 5.
4. The minimum extension length is defined from the command line of the management server (SmartCenter or CMA). To define the minimum extension length:
a. Open a command line connection to the management machine (SmartCenter server or CMA), and login.
b. At the command prompt, type expert, and the expert password.
c. Save a backup copy of the file $FWDIR/conf/user.def.CPVOIPCMP.
d. Edit the file $FWDIR/conf/user.def.CPVOIPCMP
e. Add the following line to file:
sip_min_extension_len_by_server = {<0x ac100878;3>};
Where 0x ac100878 is the hexadecimal representation of 172.16.8.120 and 3 is the minimum extension length, as in this example.
5. To add another server, for example, a SIP server 192.168.6.50 that supports extensions of lengths 4 to 6 digits, edit the line as follows:
sip_min_extension_len_by_server = {<0x ac100878;3>,<0xc0a80632;4>};
6. Save the file.
7. From SmartDashboard, install the Policy.
Chapter 4 VoIP Entities and Topology 57
VoIP EndpointsVoIP endpoints represent VoIP phones.
Defining VoIP endpoints allows highly granular configuration of security and connectivity. For SmartDefense, VoIP endpoints can be included in a “white list”, as exceptions to which protections do not apply. In addition, the SIP Endpoints Rate Limiting SmartDefense protection can be configured to apply to specific endpoints. In the VoIP tab, endpoints can be defined as exceptions to some application hardening protections.
A VoIP endpoint can be an individual phone, an IP network, an Address Range, a Simple Group, or a Group with Exclusion.
58
Media Admission ControlIn This Section
Definition of Media Admission ControlMedia admission control is the process by which a VoIP Server enables an endpoint to send media directly to another endpoint.
In previous Check Point VoIP versions, Media Admission Control was known as “handover”.
Establishing a VoIP Call: A Typical FlowTo understand VoIP media admission control, it is important to examine a typical flow for establishing a VoIP call.
Figure 4-1 illustrates a conversation that Endpoint A initiates with endpoint B, using VoIP server C.
When Endpoint A wants to establish a VoIP call with Endpoint B:
1. Endpoint A sends control signals to VoIP Server C. The signaling messages include details about the media capabilities of Endpoint A.
2. VoIP Server C sends control signals to Endpoint B, either directly (as shown in the diagram, if it knows its physical location), or through another VoIP Server.
3. If Endpoint B accepts the call, and both endpoints agree on the parameters of the media communication, then the call is established.
Definition of Media Admission Control page 58
Establishing a VoIP Call: A Typical Flow page 58
The Importance of Media Admission Control page 59
Configuring Media Admission Control page 60
Media Admission Control Decision Flow Chart page 64
Chapter 4 VoIP Entities and Topology 59
Figure 4-1 VoIP Media Admission Control
Endpoints always send the control signals to their respective VoIP Server, and never directly to each other.
The media (voice, video, and so forth), on the other hand, can be sent by the endpoints either through their VoIP Server, or (as shown in Figure 4-1) directly to each other. In order for the endpoints to send media directly to each other, each endpoint must first learn the physical location of the other endpoint from the control signals it receives from its VoIP Server.
The Importance of Media Admission ControlThe gateway is placed so that control signals pass through it (Figure 4-2). The gateway allows control signals to pass only if they are allowed by the Rule Base. In addition, the gateway dynamically opens pinholes for media connections, according to the information the gateway derives from its inspection of allowed control signals.
60
Figure 4-2 VoIP Media Admission Control Enforcement
If no limitations are placed on VoIP media admission control, attackers may be able to craft control signals in order to open pinholes, to gain access that is unauthorized by the Rule Base. In addition, by crafting control signals, attackers could cause internal endpoints to send media to IP addresses of their choice, in order to eavesdrop, modify, or disrupt communications. Correct setup of media admission control prevents such attacks.
Configuring Media Admission ControlVoIP media admission control limits the dynamic opening of ports for media connections, and permits only defined servers to open dynamic ports on behalf of a defined endpoint.
VoIP media admission control configuration is performed per VoIP server, in the Media admission control page of the SmartDashboard VoIP tab.
Note - A VoIP license is required for Media Admission Control, in addition to the Check Point gateway license. See “Licensing Requirements” on page 29.
Note - The procedure described here applies to connections through NGX R65.2.100 gateways. For gateways of versions R65 and lower, handover domains must be configured. For details see the “Securing Voice Over IP (VoIP)” chapter of the Firewall NGX R65 Administration Guide at
http://supportcontent.checkpoint.com/documentation_download?ID=7247
Chapter 4 VoIP Entities and Topology 61
To configure media admission control (for connections through NGX R65.2.100 gateways):
1. Open the VoIP Entities and Topology > Media Admission Control page of the SmartDashboard VoIP tab (Figure 4-3).
Figure 4-3 Media Admission Control Page of the SmartDashboard VoIP Tab
2. Define the VoIP Servers for which you want to perform media admission control. Use the VoIP Entities and Topology > VoIP Servers page of the SmartDashboard VoIP tab.
3. Configure Media Admission Control settings:
• Drop block the dynamic opening of ports for media connections by undefined VoIP servers, and allow only the defined VoIP servers to dynamically open ports on behalf of defined VoIP entities.
• Monitor only logs the media admission control, as if the Policy is Drop, but allows All VoIP servers to open dynamic ports of behalf of all VoIP entities.
62
• Accept ensures no media admission control is performed. All VoIP servers are allowed to open dynamic ports of behalf of all VoIP entities.
4. The VoIP Entities and Topology > Media Admission Control page shows the following information for each VoIP server:
• VoIP Server is the name of the VoIP Server object.
• Type is the VoIP server type (SIP, MGCP, H.323, SCCP, or Alcatel).
• Endpoints is the list of IP addresses (other than the server's own IP), to which the VoIP entities that send their control signals to the VoIP Server are allowed to send media directly.
5. To configure media admission control for a VoIP Server, select the VoIP server in the table, and click Edit…
The Media Admission Control page of the selected VoIP Server opens (Figure 4-4).
Note - For the default behavior if Drop is selected, and a VoIP server is not configured, see “Media Admission Control if a VoIP Server is not Configured” on page 63.
Chapter 4 VoIP Entities and Topology 63
Figure 4-4 Media Admission Control Page of the VoIP Server
• Any (including undefined endpoints) allows the server to open dynamic ports on behalf of any endpoint.
• Specific endpoints allows the server to open dynamic ports only from the objects in the Allowed from list. The remaining defined VoIP servers and VoIP Endpoints are listed under Available, and can be added to the Allowed from list. Note: To add a VoIP server to the list, add the host object of the VoIP server.
Media Admission Control if a VoIP Server is not ConfiguredIf Drop is selected in the VoIP Entities and Topology > Media Admission Control page, media admission control for VoIP servers that are not configured is as follows:
If IP address A is not defined as a VoIP Server, then the NGX R65.2.100 gateway blocks the opening of dynamic ports on behalf of A to an IP address B, unless both A and B are external. If both A and B are external, the opening of dynamic ports is allowed.
64
Media Admission Control Decision Flow ChartThe following flow chart illustrates how the gateway uses the media admission control settings to either allow or prevent a server from opening dynamic ports to a given IP Address.
Figure 4-5 Media Admission Control Flow Chart
Chapter 4 VoIP Entities and Topology 65
Entity Protection SummaryThe Entity Protection Summary allows you to see at a glance how each gateway enforces each and every application policy option and SmartDefense protection, for traffic passing through the gateway from and to a given VoIP entity.
To check the protection status of a VoIP entity:
1. Go to the VoIP Entities and Topology > Entity Protection Summary page of the VoIP tab
2. Choose the VoIP entity.
3. Choose the gateway.
4. Click Show Summary.
66
Understanding the Entity Protection SummaryThe Entity Status page is divided into three sections: the upper section, the Application Policy section, and the SmartDefense section
Upper Section In the upper part of Entity Status page, the VoIP entity and the gateway are selected.
A VoIP Entity is any VoIP server or VoIP endpoint that is defined in the VoIP Entities and Topology section of the VoIP tab.
Traffic from or to a VoIP entity can pass through more than one gateway. The way that each gateway handles traffic is determined by the SmartDefense profile that is assigned to the gateway. Gateway profile assignment is configured in the Profile Assignment page of the SmartDefense tab.
Chapter 4 VoIP Entities and Topology 67
Application Policy SectionThe Application Policy section of the Entity Status page shows how the selected gateway enforces each application policy option for traffic passing through the gateway from and to the selected VoIP entity.
The examples below show how settings for the Application Policy option, Sessions with Data Connections from Port <1024, are displayed in the Entity Status page.
In the following screenshot, the application policy for the Sessions with Data Connections from Port <1024 option is:
VoIP Entity Action
sip_registrar AcceptMGCP_server DropAll other entities Monitor Only
68
The Entity Status page presents the same information as follows:
• For VoIP entity: Sip_registrar, the application policy is Accept
• For VoIP entity: MGCP_server, the application policy is Drop
• For any other VoIP entity, such as VoIP_External_SIP_phones, the application policy is Monitor
Chapter 4 VoIP Entities and Topology 69
SmartDefense SectionThe SmartDefense section of Entity Status page shows how the selected gateway enforces each SmartDefense protection, for traffic passing through the gateway from and to the selected VoIP entity.
The composite screenshot in Figure 4-6 shows how settings for the SmartDefense protection SIP Servers Rate Limiting are displayed in the Entity Status page.
The active profile on the selected gateway, SBC_gw, is Default _Protection. The SmartDefense page for SIP Servers Rate Limiting shows that the protection is active on the Default_protection profile, and that the protection is Active on the server SIP_proxy_external_server. The Entity Protection Summary therefore shows that the policy is Active for the protection.
70
Figure 4-6 SIP Servers Rate Limiting Smart Defense Page
For other SIP Servers Rate Limiting protection settings, the Entity Protection Summary would show a different policy. For example:
• If the active profile on the selected gateway, SBC_gw, is Default_protection, but the protection is inactive on the Default_protection profile, the policy would be Inactive (irrespective of whether or not SIP_proxy_external_server is configured as a protected server for this protection).
• If the active profile on the selected gateway, SBC_gw, is Default_Protection, and the protection is active on the Default_Protection profile, but SIP_proxy_external_server is not configured as a protected server for this protection, the policy would be Inactive.
71
Chapter 5Emergency Numbers
This chapter explains how to configure Check Point Gateways to allow SIP calls to and from any number that is configured as an emergency number.
In This Chapter
How the Gateway Handles Emergency Calls page 72
Configuring Emergency Numbers page 73
72
How the Gateway Handles Emergency Calls VoIP providers in many countries are required by law to support emergency services.
The Check Point gateway always allows SIP calls through the gateway, to and from numbers that are defined as emergency numbers.
If the From or To field of a SIP packet includes an emergency number, no protections are enforced, all packets are passed, and no log is generated, in order to avoid delaying the packet.
Chapter 5 Emergency Numbers 73
Configuring Emergency NumbersThe Check Point gateway always allows SIP calls to and from numbers that are defined as emergency numbers.
To configure an emergency number:
1. In the SmartDashboard VoIP tab, select the Advanced > Emergency Numbers page.
The Emergency Numbers page opens.
2. Click Add.
The Emergency number window opens.
3. Type the Emergency number. All characters are allowed.
4. Type a comment (optional).
5. Install the Policy. In the Policy menu, select Install…
74
75
Chapter 6Far End NAT Traversal
In This Section
The VoIP NAT Challenge page 76
The Far End NAT Traversal Solution page 76
NGX R65.2.100 NAT Deployments page 77
How Far End NAT Traversal works page 79
VoIP Server and Endpoint Compliance page 82
Ports and Addresses for Signaling and Media page 83
Configuring Far End NAT Traversal for SIP page 85
76
The VoIP NAT ChallengeIn order to allow VoIP across the internet, the IP addresses of the VoIP phones must be routable on the internet. The task of converting private addresses to public ones has long been handled by Network Address Translation (NAT).
Simple NAT devices such as network-layer firewalls and ADSL routers perform NAT on the IP header. However, the VoIP packet payload contains the private IP address of the client, and network-layer firewalls cannot perform NAT on the VoIP headers. This makes VoIP fundamentally incompatible with network layer NAT devices.
Check Point VPN-1 gateway products are application layer firewalls that support VoIP deployments where the NAT is performed by the gateway itself. If NAT is performed by other non VoIP-aware devices such as simple ADSL routers, VPN-1 gateways of version NGX R65.2.100 are able to route VoIP calls using Far End NAT Traversal.
The Far End NAT Traversal SolutionThe VoIP NAT capability of Check Point gateways overcomes some of the problems that firewalls and NAT cause for VoIP calls.
Check Point gateways of version NGX R65.2.100 make it possible to deliver VoIP services across territorial boundaries, without NAT and firewall devices limiting that capability, and without changing the established IP infrastructure.
NGX R65.2.100 enables VoIP connectivity even though the gateway does not control the NAT devices at the customer premises. The ability to provide connectivity in such complex scenarios is achieved by its Far End NAT traversal capability. This is done by modifying the signaling and media packets from a centralized location. The NGX R65.2.100 gateway acts like a Back-to-Back User Agent for both sides (VoIP servers and VoIP phones). It exerts control over the incoming and outgoing signaling and media streams involved in setting up, conducting, and tearing down calls..
Note - A VoIP license is required for the Far End NAT Traversal capabilities of the gateway, in addition to the Check Point gateway license. See “Licensing Requirements” on page 29.
Chapter 6 Far End NAT Traversal 77
NGX R65.2.100 NAT DeploymentsNGX R65.2.100 can be deployed by enterprises and by service providers.
An enterprise deployment (Figure 6-1) makes it possible for remote users and offices with non VoIP-aware firewalls to use the organization’s VoIP system and make VOIP calls within the enterprise network.
In Figure 6-1, VoIP calls are enabled for the home office, small office, and for remote users, by the Far End NAT Traversal capabilities of the NGX R65.2.100 gateway at the main office. Upgrading to version NGX R65.2.100 allows all users in the enterprise to make VoIP calls. Prior to upgrading the main office gateway, calls are possible only between the main office and the branch office.
Figure 6-1 NGX R65.2.100 in an Enterprise Deployment
78
A managed service provider deployment (Figure 6-2) makes it possible to provide enterprise and residential VoIP services. Managed service providers can use NGX R65.2.100 to allow the use of VoIP protocols from private networks with internet connections using NAT, and also to implement strong security measures that are necessary to maintain a high quality of service.
Figure 6-2 NGX R65.2.100 in a Managed Service Provider Deployment
Chapter 6 Far End NAT Traversal 79
How Far End NAT Traversal worksThe challenge of Far End NAT is to allow incoming calls to phones behind the NAT devices. Most NAT devices use Hide NAT and therefore allow only outgoing connections.
The Far End NAT capability of NGX R65.2.100 solves this challenge by keeping maintaining a pinhole through the NAT device for incoming connections, and by performing NAT on the signaling and media payloads of the TCP or UDP packets.
Pinhole Maintenance through NAT DevicesWhen phones make an outgoing connection through a NAT device, the NAT device opens a pinhole (a source port at an IP address) for each phone. This allows outgoing connections for a fixed period of time. The pinhole on the NAT device is kept open by the phone which sends a TCP or UDP keepalive message with a timeout that determines how long the pinhole remains open.
During the time that the pinhole is open, incoming connections can be made to the endpoints via the same pinhole.
The NGX R65.2.100 gateway makes it possible to make incoming calls to phones behind the NAT devices by keeping the pinhole open so that it can be used by incoming connections.
The gateway keeps the pinhole on the NAT device open as follows:
1. A phone sends a registration request through the NAT device to the proxy.
2. The proxy registers the phone for a fixed period of time. After that time the phone must re-register.
3. The gateway intercepts the registration confirmation that the proxy sends to the clients, and shortens the registration period (to 30 seconds for example) so that it is less than the keepalive timeout of the clients (foe example, 40 seconds).
4. The gateway forwards the modified registration confirmation to the clients.
5. The phones are forced to re-register more frequently than their keepalive timeout. Whenever a phone makes a new registration request, it opens a new connection and sends a keepalive message to the NAT device through the same port it used for its previous registration request (phones re-use the same port for every connection).
This keeps the pinhole open through the NAT device. Incoming calls can therefore be made through the pinhole to endpoints behind the NAT device.
80
Pinhole Maintenance Configuration OptionsIn the VoIP page of the Check Point Gateway object, under Advanced, the TCP keepalive timeout and the UDP keepalive timeout can be configured.
This keepalive timeout is the registration period that the gateway assigns to the registration confirmation that the proxy sends to the phones.
SIP phones communicate either over TCP or UDP. A typical UDP timeout for a SIP phone is 40 seconds. A typical TCP timeout is 3600 seconds.
In order to allow Far End NAT Traversal, it is recommended to make the TCP keepalive timeout and the UDP keepalive timeout 10-25% shorter than the TCP and UDP keepalive timeouts of the phones.
NAT on the signaling and Media PayloadsWhen Far End NAT is configured on the NGX R65.2.100 gateway, the gateway intercepts VoIP packets and changes them so that servers can route packets to the VoIP clients. The signaling and media packets are modified in both directions and NAT is done both on the payload and the IP header of the VoIP packet.
Figure 6-3 shows a carrier deployment of NGX R65.2.100, and the signaling path from a VoIP phone behind a NAT device via the NGX R65.2.100 gateway to the VoIP server and destination IP phone.
Figure 6-3 Far End NAT Traversal in a Carrier Deployment
Note - In this example, IP addresses starting 172.16.x.x and 192.168.x.x denote public IP addresses.
Chapter 6 Far End NAT Traversal 81
NGX R65.2.100 performs Far End NAT traversal as follows:
1. SIP phone initiates the VoIP call.
2. A non-VoIP aware firewall performs NAT on the IP header of the VoIP packet.
3. The NGX R65.2.100 gateway:
• Performs NAT on the IP header. The IP is changed from 192.168.10.1 to 172.16.5.1
• Performs NAT on the SIP header of the packet. It translates the NATed IP address of the IP phones in the SIP header to the signaling IP address of the gateway.
• Translates the source port number to a port number that is unique for that phone call.
4. The NGX R65.2.100 gateway routes the packet to the VoIP server.
5. VoIP server routes the VoIP packet to the destination phone.
82
VoIP Server and Endpoint ComplianceIn order for the Far End NAT traversal solution to properly function:
• The proxy must support the registration of several users with the same IP, differentiated by the source port.
• Endpoints (such as IP phones) must comply with the following requirements (most do):
1. Support symmetric signaling – The endpoint listening port must be the same as the endpoint signaling source port (as specified in RFC 3581).
2. Support symmetric RTP – The endpoint RTP receiving port must be the same as the endpoint RTP source port.
3. SIP endpoints must be able to adjust their REGISTER expiration time, in order to allow pinholes though the NAT devices to be kept open.
4. Support early media (SIP) – Endpoints must not wait until receiving RTP packets from other side, but must begin sending RTP packets immediately after signaling is sent.
Chapter 6 Far End NAT Traversal 83
Ports and Addresses for Signaling and Media
In addition to the Far End NAT that the NGX R65.2.100 gateway performs on the signaling components of the VoIP packet (illustrated in Figure 6-3 on page 80), the gateway also controls the media (RTP/RTCP), by performing Far End NAT on the media ports used by the IP phones.
When configuring Far End NAT on the gateway, an IP address must be configured for the signaling. Optionally, an IP can be configured for the media. The signaling IP address must be routable by the SIP servers. The media IP address must be routable by the participants of the call. The media IP can be the same as the signaling IP address or different from it.
Signaling and Media Port AllocationA total of 55,000 ports are available per IP address. The 0-10,000 port range is reserved, and is not usable. The 10,000- 65,000 port range is available for signaling and media.
It is possible to configure a different IP address for the media than for the signaling.
If the signaling and media IP addresses are different, 55,000 ports are available for each, so that gateway is able to handle more users and calls.
If the same IP address is used for both signaling and media, the available port range is shared between signaling and media. The administrator must decide how to allocate the available ports.
Choosing the Media Port RangeIf the same IP address is used for both signaling and media, the available port range is shared between signaling and media. You must configure a port range for the media (from X to 65,000, as in Figure 6-4), where x is the boundary between the signaling and media port ranges.
84
Figure 6-4 Available Ports When the Same IP is Used for Signaling and Media
In order to choose the most appropriate signaling and media port ranges, consider the number of simultaneous calls that can be expected, and the type of VoIP services that will be used. Take the following into account:
• For signaling, 1 port per call is required for each participant in a call. This port is allocated when the phone registers with the proxy, and freed when the phone turns off. If a user makes two calls, one after the other, the same source port is used for both calls.
• For media, the number of required ports depends on the type of call. For voice, at least 4 ports per call are required: For a 2 person call, each caller requires 1 port for RTP and 1 for RTCP (4 ports in total). For advanced VoIP services such as conference calls and video, more ports are required.
Chapter 6 Far End NAT Traversal 85
Configuring Far End NAT Traversal for SIPTo configure Far End NAT Traversal for SIP, an Advanced VoIP gateway with Far End NAT capability must be defined. In addition, access rules for the client IP phones must be configured in the Security rule base.
In This Section
Defining the VoIP gatewayTo configure Far End NAT traversal, you must first define an enforcing gateway.
To define a VPN-1 Power/UTM gateway with advanced VoIP capability:
1. In SmartDashboard, click the VoIP tab.
2. In the left pane tree, click to select the Enforcing Gateways page.
Figure 6-5 The Enforcing Gateways Page of the SmartDashboard VoIP Tab
Defining the VoIP gateway page 85
Configuring Far End NAT Traversal for the Gateway page 86
Configuring the Client SIP Phones page 92
Security Rule Base Configuration page 92
86
3. To edit an existing gateway, select a gateway and click Edit.To create a new gateway, click New, and create the gateway object.
The Check Point Gateway - General Properties page opens.
4. Define the following required fields:
• Name
• IP address
• Version must be NGX R65.2.100.
• OS
• In the Check Point Products section, select at least Firewall.
5. In the Topology page, configure the gateway interfaces. To do so automatically, click Get > Interfaces with Topology
Configuring Far End NAT Traversal for the GatewayTo add Far End NAT Traversal capabilities to the gateway:
1. In the General Properties page of the Check Point Gateway window, ensure that:
• The Version is at least NGX R65.2.100
• In the Check Point Products section, at least the Firewall product is selected.
2. Select the Advanced > VoIP page (Figure 6-6).
Chapter 6 Far End NAT Traversal 87
Figure 6-6 The Advanced > VoIP page of the Check Point Gateway
3. Configure Dynamic Pinholing.
Dynamically open ports for VoIP media channel opens dynamically assigned ports for media connections, according to the information in the signaling connection. This option is enabled by default. It should normally be selected when the VoIP connections pass through the gateway. It applies for SIP, H.323, MGCP and SCCP.
4. Select Use Internal SIP Far End NAT Traversal.
Note - Do not disable this option if Use Internal SIP Far End NAT Traversal is enabled
88
5. Configure the signaling channel for Far End NAT Traversal. For the Translate source IP for signaling channel option, select (or create and then select) a host object whose IP address is routable to the SIP proxy (this host object represents an IP address, not a real machine). If both the VoIP proxy and the gateway are in the internal network, this IP address need not be publicly routable. In addition, this IP address must not exist on any of the gateway interfaces.
6. Configure the media channel for Far End NAT Traversal. Either:
• Use port range for media translation, or
• Configure a dedicated IP address for media translation. The IP address for media must be Internet routable.
7. The gateway can connect to either a single VoIP proxy server or to multiple VoIP proxy servers. Configure either Single Server or Multiple servers.
8. Click Advanced.
The Advanced window opens.
9. The Configure the TCP keepalive timeout default value is 3000 seconds and the UDP keepalive timeout default value is 30 seconds. To allow Far End NAT Traversal, it is recommended to make these timeouts 10-25% shorter than the corresponding TCP and UDP keepalive timeouts of the phones. A typical TCP timeout for a phone is 3600 seconds. A typical UDP timeout is 40 seconds. For background information, see “Pinhole Maintenance through NAT Devices” on page 79.
10. After the SIP phones have initiated the call, the media can flow directly between the endpoints without the mediation of a SIP Proxy. To allow direct media flow, select Enable direct media flow between endpoints residing on the same LAN.
11. Click OK.
This takes you back to the VoIP page of the Check Point gateway.
12. Click OK
13. This closes and saves the Check Point gateway.
14. Install the Policy.
Note - Either this host object or the gateway can be used in the firewall access rules to the Far End NAT Traversal component of the gateway.
Chapter 6 Far End NAT Traversal 89
Defining a SIP ProxyIn order to complete the Far End NAT Traversal configuration of the gateway, you need to define the SIP proxy or proxies used by the gateway for registrations and call initiations.
If you have not yet defined a SIP server, do so now. To configure a SIP proxy, configure a SIP Server object, and then define it as a SIP proxy.
To define a VoIP server:
1. In the VoIP tab, select the VoIP Entities and Topology > VoIP Servers page.
2. Click New…
3. Select the VoIP server type.
The General Properties page of the VoIP server opens.
4. In the General Properties page, choose a Name for the VoIP server (e.g. sip_server)
5. Define the VoIP Server host:
a. Click Manage…
b. Click New…
c. The Host Node window, General Properties page opens.
90
d. Type a Name for the host (e.g. sip_server_host), and specify its IP address.
e. Click OK. This brings you back to the General Properties page of the VoIP server object.
Specifying the SIP Proxy Used By the GatewayThe gateway can work with either a single proxy or multiple proxies. An example of a multiple proxy server configuration is illustrated in Figure 6-2 on page 78, which shows an IP Centrex server farm in the MSP core network.
To specify the SIP proxy or proxies used by the gateway:
1. In the Check Point Gateway object, select the Advanced > VoIP page (Figure 6-7).
Chapter 6 Far End NAT Traversal 91
Figure 6-7 SIP Proxy Configuration in the VoIP Page of the Check Point Gateway Object
2. Select one of the options:
• Single server to select an existing SIP Server.
• Manage to add a new SIP server or edit an existing SIP server.
• Multiple servers- chosen by round robin, then click Manage and then Add to add the SIP proxy servers. Round robin means that successive SIP packet flows from SIP clients are assigned to successive servers.
3. Click OK.
92
Configuring the Client SIP PhonesIn the configuration utility of the client SIP phones, configure an IP address to be used by the SIP clients as their SIP proxy. Use the signaling IP address that you configured in the Check Point Gateway properties window, Advanced VoIP page. Far End NAT Traversal is performed when required. The SIP signaling is routed through this IP address and not through the firewall component of the gateway.
Security Rule Base ConfigurationDefine a rule in the Security Rule Base that allows Far End NAT Traversal.
Configure the following security rule:
Note - Do not use IP address of SIP Proxies in the configuration utility of the IP phones. Using the SIP proxy IP address prevents the gateway from performing Far End NAT Traversal.
Source Destination Service
• Group of devices that generate SIP messages (either NAT devices or IP phones).
• Otherwise, use Any (not recommended practice)
• Host object for signaling translation of the gateway.
UDP:sipand/orTCP:sip-tcp
93
Chapter 7Rate Limiting DoS Protection
In This Section
Introduction to Denial of Service Protection page 94
Rate limiting Protections page 95
Configuring Rate Limiting Protections page 96
Non SIP Entities Rate Limiting page 98
SIP Servers Rate Limiting page 100
SIP Endpoints Rate Limiting page 106
SIP Internal Networks Rate Limiting page 107
94
Introduction to Denial of Service ProtectionA denial-of-service attack (DoS attack) is an attempt to make a resource unavailable to its intended users. It generally involves trying to prevent an Internet site or service from functioning efficiently or at all, temporarily or indefinitely.
One variety of attacks that can lead to denial of service are buffer overflow attacks. SmartDefense for NGX R65.2.100 includes many protocol anomaly protections to protect against buffer overflows attacks. These protections are available for
• SIP (see “SIP Protocol Anomaly Protections” on page 140).
• MGCP (see “MGCP Protocol Anomaly Protections” on page 205).
• H.323 (see “H.323 Protocol Anomaly Protections” on page 225).
• SCCP (see “SCCP SmartDefense Protections” on page 250).
Another variety of attacks that can lead to denial of service involves rogue IP phones sending legitimate requests at very high rates in order to overwhelm the application servers. SmartDefense protects against this type of application-level attack using rate limiting protections. This chapter relates to the SmartDefense rate limiting protections.
Rate Limiting protections are configured in SmartDefense, under Application Intelligence > VoIP > Protections for R65.2.100 > Rate Limiting.
Chapter 7 Rate Limiting DoS Protection 95
Rate limiting ProtectionsLimiting the rate of traffic to internal VoIP networks and servers is one of the techniques that can help protect against application level denial of service attacks. Rate limiting is accomplished by configuring traffic thresholds. Traffic that exceeds the thresholds is blocked.
Thresholds can be configured for all SIP internal networks, and for particular SIP servers or endpoints. Protections are also available for non-SIP VoIP servers in the internal network.
Unusual but legitimate network traffic patterns may create false alarms. In order for the thresholds to be effective, they must be appropriate for the traffic conditions. Rate limiting protections are tightly integrated with SmartView Monitor, so that the administrator can examine traffic statistics and fine-tune appropriate, granular thresholds based on actual traffic patterns.
It is possible define an “allow list” of source IP addresses for which the rate limiting detection thresholds do not apply.
Note - Rate Limiting SmartDefense Protections 1. Require a VoIP license, in addition to the Check Point gateway license. See “Licensing Requirements” on page 29.2. Are not supported in a ClusterXL Load Sharing deployment.
96
Configuring Rate Limiting ProtectionsIn order for the all Rate Limiting protections to function correctly, ensure that:
• The VoIP gateway topology is defined in SmartDashboard so that it has at least one internal interface and at least one external interface.
• Protected objects (VoIP servers and/or networks) are defined as internal.
To protect against Rate based DoS attacks, configure Rate Limiting protections as follows:
1. In SmartDashboard, define the VoIP entities (servers and/or networks) to be protected.
2. Define the VoIP gateway topology so the VoIP entities to be protected are behind an internal interface of the gateway:
a. In the VoIP gateway object, select the Topology page, and edit an interface. The Interface Properties window opens (b.).
b. In the Topology tab of the Interface Properties window, ensure that the IP addresses of the VoIP entities to be protected are behind a gateway interface whose topology is defined as Internal.
3. In the Security Rule Base, define a VoIP access policy that allow VoIP calls across the VoIP gateway, to and from the internal VoIP entities.
Chapter 7 Rate Limiting DoS Protection 97
4. If required, define a “white list” of external VoIP entities to which the Rate limiting protections do not apply. Define those entities in the SmartDefense Rate Limiting > Source IP Addresses Excluded from Rate Limiting Inspection page.
5. In the SmartDefense tab, configure the Rate Limiting protections under Application Intelligence > VoIP > Protections for R65.2.100. Continue with:
• “Non SIP Entities Rate Limiting” on page 98.
• “SIP Servers Rate Limiting” on page 100.
• “SIP Endpoints Rate Limiting” on page 106.
• “SIP Internal Networks Rate Limiting” on page 107.
98
Non SIP Entities Rate LimitingThis protection prevents rate-based denial of service attacks from the external network against non-SIP entities in the internal network, such as MGCP, H.323, SCCP, or Alcatel servers.
Non-SIP entities are deployed behind an internal interface of a VoIP gateway, to which non-SIP calls are allowed via the Security Rule Base.
Rate thresholds can be configured to limit the number of call attempts per minute that the VoIP gateway will allow to any internal non-SIP entity from any external IP address.
It is possible define an “allow list” of source IP addresses for which the thresholds in this protection do not apply.
Figure 7-1 Non-SIP Entities Rate Limiting settings
Non SIP Entities Rate Limiting Configuration DetailsTo configure rate limiting for non-SIP entities:
1. Perform step 1 to step 4 of the general instructions for configuring rate limiting protections. See “Configuring Rate Limiting Protections” on page 96.
2. Go to SmartDefense > Application Intelligence > VoIP > Protections for R65.2.100 > Rate Limiting > Non-SIP Entities Rate Limiting
3. Configure the Global Default Settings.
Max Number of call initiations per minute from specific IP is the maximum allowed number of call initiation requests per minute from the same external IP address. The count starts from the first relevant request.
Chapter 7 Rate Limiting DoS Protection 99
For example, if the setting is 120 call initiations per minute, in the first minute, up to 120 call initiations are allowed from the same external IP address. After this threshold is exceeded, no more are allowed from the same IP address during that minute. In the next minute interval, call initiations from that IP address are again allowed, until the 120 call threshold is exceeded, and so on.
4. Configure an Exceptions List for all Profiles. Here you can define an rate limiting thresholds for for non-SIP entities that are different from the Global default settings for non-SIP entities.
5. If required, define a “white list” of external VoIP entities in the Rate Limiting > Source IP Addresses Excluded from Rate Limiting Inspection page. Rate limits do not apply to traffic from locations listed there.
6. Install the Policy.
100
SIP Servers Rate LimitingThis protection prevents rate-based denial of service attacks against individual SIP servers. SIP servers are defined in the VoIP Entities and Topology > VoIP Servers page of the SmartDashboard VoIP tab. Rate thresholds can be configured for requests from users in the external network to SIP servers in the internal network, per SIP server, for:
• All requests.
• Requests from a single IP address.
• Requests from a single user.
• Requests using particular methods (commands).
SmartView Monitor displays statistics that show actual numbers of requests, and the configured thresholds.
Rate-Based DoS and DDoS AttacksIn a rate-based denial of service (DoS) attack, the attacker normally spoofs the source IP address in an attempt to prevent the source of the attack being identified. Blocking the apparent source of the attack is not effective, because the attacker can easily spoof a different IP address. Also, the attacker might spoof the address of a legitimate user.
In a distributed denial of service (DDoS) attack, multiple compromised systems flood the targeted system service with requests. Usually, each compromised system sends requests at a relatively low rate, in order to make it more difficult to detect the sources of the attack and to block them.
Trusted and Non Trusted SIP UsersWhen the SIP Servers Rate Limiting protection is active, the VoIP gateway inspects incoming traffic to the VoIP servers, and dynamically categorizes external users as either trusted or non-trusted.
The gateway ensures that the rate of incoming requests to the internal SIP server does not exceed the configured threshold. Out of all incoming requests, it ensures that a certain number of requests from trusted users will always be able to reach the server. In addition, the gateway limits the rate of incoming requests from individual non-trusted and trusted users.
Initially, the gateway categorizes all users as non-trusted. Eventually, users can become trusted by the gateway.
Chapter 7 Rate Limiting DoS Protection 101
A user is identified by
1. The user component of the SIP URI, which identifies the sender of the request. For example, in the SIP URI sip:[email protected], the user is bob.
2. The source IP address of the request.
How a User Becomes TrustedThere are two ways that a user can become trusted.
One way that the user becomes trusted is to perform authenticated registration with the SIP server. A SIP server can require that the user’s client phone authenticate when the client registers. The way this works is that the proxy sends a proxy-authenticate (407) or an unauthorized (401) response to the client. If the client responds with authentication credentials, and the proxy accepts those credentials, then the client is authenticated. The SIP headers used in proxy authentication are defined in RFC 3261 section 20.7.
A second way that a user can become trusted is for the server to allow the user to establish a call, and for the VoIP gateway to confirm that the IP address of the user’s client is not spoofed.
SIP Servers Rate Limiting Configuration DetailsTo configure SIP Servers Rate Limiting:
1. Perform step 1 to step 4 of the general instructions for configuring rate limiting protections. See “Configuring Rate Limiting Protections” on page 96.
2. If required, define a “white list” of external VoIP entities in the Rate Limiting > Source IP Addresses Excluded from Rate Limiting Inspection page. Rate limits do not apply to traffic from locations listed there.
3. Go to SmartDefense > Application Intelligence > VoIP > Protections for R65.2.100 > Rate Limiting > SIP Servers Rate Limiting
4. Click Enforcing servers.
102
The Protected servers window open.
In this window you can see a list of all the defined SIP servers, and on which servers this protection is active.
5. Select an existing endpoint and click Edit.
Chapter 7 Rate Limiting DoS Protection 103
The Protections > Rate Limiting window of the SIP Server Object opens
• Enable SIP Rate limiting on incoming traffic to this server turns this protection on or off for this server.
• Max number of requests in total per interval includes all types of SIP request commands (methods) from the external networks to SIP servers in the internal network.
• Interval is in seconds, is an adjustable sampling window. The default value is 5 seconds. Only change this value if it does not match network usage patterns.
• For an explanation of the Advanced options, see the Example of SIP Server Rate Limiting.
• For information on Method Limiting see Method Limiting…
Note - Allowing a large number of requests over a large interval is very different from allowing fewer requests over a proportionally smaller interval. For example, allowing 1000 requests over 5 seconds is different from allowing 200 requests over 1 second. Allowing a higher number of requests over a longer interval reduces the number of false positives, but allows request spikes.
104
Example of SIP Server Rate LimitingThe behavior of the SIP server rate limiting protection is best illustrated by an example.
Assuming the following scenario:
• A SIP server in the internal network is to be protected against rate-based DoS attacks. The server is capable of handling up to 10K requests/sec.
• There are SIP entities in the internal network that must be able to communicate with the server even when the server is under a rate-based DoS attack. The internal entities usually do not send more than 1K requests/sec to the SIP server.
Configure the SIP Server Rate Limiting thresholds as follows:
• Interval = 5 seconds (the default)
• Max number of requests in total per interval = 90% x 10K/sec x 5 sec = 45,000.
Advanced
• In most cases, rate-based DoS attackers are categorized by the VoIP gateway as non-trusted users. Trusted users must have a guaranteed share of the total incoming requests. Make sure that the Max % of requests from non trusted users out of total requests is not lower than 10%, because it takes a few requests for a legitimate user to be categorized by the gateway as trusted. A reasonable figure is to limit the number of requests from non-trusted users to 25% of the total.
• A single trusted user should not be able to send unlimited amounts of requests to the server. A trusted user sending too many requests may be a legitimate user trying to attack the server, or just extremely active. If the server is capable of handling up to 10K requests/sec, for example, then 100 requests per second from a single trusted user is reasonable. Therefore, Max number of requests from a single trusted user (requests per interval) = 100/sec x 5 sec = 500.
• New users are initially categorized by the gateway as non-trusted. They must be allowed to become trusted by the gateway. However, each non-trusted user should be allowed to send fewer requests to the server than a trusted user. In the scenario of this example, 30 requests per second from non-trusted users is reasonable. Therefore, Max number of requests from a single non trusted user (requests per interval) = 30/sec x 5 sec = 150.
• SIP servers are trusted, and SIP servers make more requests than users. However, it is relatively easy to impersonate a SIP server by spoofing its IP address. Therefore, the threshold should not be too high. Assuming that each
Chapter 7 Rate Limiting DoS Protection 105
external SIP server must be able to send about 500 requests/sec to the internal server, Max number of requests from a single SIP server = 500/sec x 5 sec = 2500. Note that this threshold applies to all requests sent from each external SIP server defined in the VoIP Entities > VoIP Servers page of the SmartDashboard VoIP tab.
Method Limiting… • Method Limiting permits configuration of rate limits for SIP requests for specific
methods (commands), including INVITE, REGISTER and OPTIONS. These protections limit the number of requests from all users. No distinction is made between trusted and non-trusted users.
Figure 7-2 SIP Server Object: Protections > Rate Limiting > Method Limiting window
106
SIP Endpoints Rate LimitingThis protection prevents rate-based denial of service attacks from users in the external network against SIP endpoints in the internal network. SIP endpoints can be IP networks, address ranges, or even individual IP phones.
SIP Endpoints Rate Limiting Configuration DetailsTo configure rate limiting for endpoints:
1. Perform step 1 to step 4 of the general instructions for configuring rate limiting protections. See “Configuring Rate Limiting Protections” on page 96.
2. Go to SmartDefense > Application Intelligence > VoIP > Protections for R65.2.100 > Rate Limiting > SIP Endpoints Rate Limiting
3. Click Enforcing endpoints.
The Protected endpoints window opens. It shows the SIP endpoints objects configured in the VoIP Entities and Topology > VoIP Endpoints page, and whether or not each SIP endpoints object is protected by the SIP Endpoints Rate Limiting protection.
4. Click Add, or select an existing endpoint and click Edit.
The Endpoint Rate Limiting window opens.
Chapter 7 Rate Limiting DoS Protection 107
• Enable SIP rate limiting on these Endpoints turns this protection on or off for the
SIP endpoints.
• Max number of requests to a single endpoint per interval includes all types of SIP request commands (methods) from the external networks to a single SIP endpoint in the internal network. Note that if the SIP endpoints object includes several endpoints, then the threshold is enforced for each of them separately.
• Interval size is x seconds is an adjustable sampling window. Default value is 5 seconds. Only change this value if it does not match network usage patterns.
• SIP Internal Networks Rate Limiting
This protection limits the rate of SIP requests incoming to the internal networks. Rate thresholds can be configured for all internal networks, for SIP requests from the external to the internal network, for:
• All requests.
• Registration requests.
• Call initiation requests.
SIP Internal Networks Rate Limiting Configuration Details
1. Perform step 1 to step 4 of the general instructions for configuring rate limiting protections. See “Configuring Rate Limiting Protections” on page 96.
2. Go to SmartDefense > Application Intelligence > VoIP > Protections for R65.2.100 > Rate Limiting > SIP Internal Networks Rate Limiting
Note - Allowing a large number of requests over a large interval is very different from allowing fewer requests over a proportionally smaller interval. For example, allowing 1000 requests over 5 seconds is different than allowing 200 requests over 1 second. Allowing a higher number of requests over a longer interval reduces the number of false positives, but allows request spikes.
108
SIP Internal Networks Rate limiting Settings Per ProfileFigure 7-3 SIP Internal Networks Rate Limiting Settings
• Max number of requests in total to internal networks per interval includes all types of SIP request commands (methods) from the external networks to internal networks.
• Interval in seconds, is an adjustable sampling window. The default value is 5 seconds. Only change this value if it does not match network usage patterns.
Advanced
• Max % of registration requests (out of total requests): Applies specifically to REGISTER commands. The default value is 25%.
• Max % of initiation requests (out of total requests): The default value is 90%. An initiation request is any request with a new Call-ID, that creates a new SIP dialog.
Note - Allowing a large number of requests over a large interval is very different from allowing fewer requests over a proportionally smaller interval. For example, allowing 1000 requests over 5 seconds is different than allowing 200 requests over 1 second. Allowing a higher number of requests over a longer interval reduces the number of false positives, but allows request spikes.
Note - The sum of the percentages Max % of registration requests (out of total requests) and Max % of initiation requests (out of total requests) can add up to more than 100% because there can be an overlap between those groups. For example, REGISTER commands with a new Call-ID are also counted as initiation requests.
109
Chapter 8Quality of Service
In This Chapter
Introduction to QoS for NGX R65.2.100 page 110
Per Gateway QoS page 111
Per Server QoS page 113
DiffServ Marking of VoIP Data Packets page 114
110
Introduction to QoS for NGX R65.2.100 In environments when converged voice, video and data traffic share the same network, network congestion can result in dropped packets, delay, or jitter. For video and voice traffic, this can lead to unacceptable degradation in call quality, with effects such as service interruptions and noise.
Enterprises and service providers must provide their customers with assured levels of service. NGX R65.2.100 makes this possible by means of:
• Per Gateway QoS, which sets a limit to the number of allowed concurrent SIP calls, and a limit to the maximum overall bandwidth allowed for SIP calls.
• Per Server QoS, which blocks SIP calls from unregistered users.
• DiffServ Marking of VoIP Data Packets, which marks all VoIP data packets, such as RTP and RTCP, though the gateway with the DiffServ encoding for expedited forwarding.
Chapter 8 Quality of Service 111
Per Gateway QoSCall Admission Control and Traffic Policy protects the network behind the VoIP gateway from congestion by limiting the number of concurrent SIP calls and the total bandwidth used for SIP calls from exceeding the network’s capacity.
These mechanisms are called Per Gateway QoS in the SmartDashboard VoIP tab because the limits are enforced globally by the gateway, for all SIP traffic passing through the gateway.
When the configured limits are exceeded, the gateway sends the appropriate signals to gracefully reject new calls. Users that try to make a new call hear a busy signal. Existing calls are unaffected.
The Per Gateway QoS options are:
• Call Admission Control
• Traffic Policy
Call Admission Control The Call Admission Control option includes the following setting:
• Maximum number of concurrent SIP calls prevents VoIP servers from being overloaded, by setting a maximum number of concurrent calls. The rationale for this is that adding more calls will lead to deterioration of the quality of every call. Requests and responses with the same Call-ID are considered part of the same call. Only SIP calls crossing the gateway are counted.
Traffic Policy The Traffic Policy option includes the following setting:
• Block SIP calls exceeding overall bandwith limits the volume of SIP call traffic being sent across the gateway.
The gateway calculates the maximum bandwidth required for all concurrent SIP media sessions. It does this by adding together the bandwidth requirements of the codecs used for each media session. Only media sessions related to SIP
Note - 1. A VoIP license is required for the QoS Call Admission Control and Traffic Policy options, in addition to the Check Point gateway license. See “Licensing Requirements” on page 29.2. These options are not supported in a ClusterXL Load Sharing deployment.
112
traffic crossing the gateway are considered.
The codec to be used in each media session is negotiated using SDP, in an SDP message that is carried by a SIP message.
For example, the G.711 codec requires a bandwidth of up to 64 Kbps. If 10 simultaneous calls are made through the gateway, and both sides of every call use the G.711 codec, then the maximum overall bandwidth that may be required for all calls is 10 x 64 x 2 = 1280 Kbps. The actual bandwidth used by the media sessions is likely to be lower.
Gateway Specific SettingsIt is possible to define exceptions to the default gateway settings. For each gateway, it is possible to either enable settings that are different from the default, or to disable the settings for that gateway.
Chapter 8 Quality of Service 113
Per Server QoS
SIP Block Calls from Unregistered UsersThis option is intended to relieve server load. This is achieved by blocking SIP messages, not including REGISTER requests and responses, if neither of the users that appear in the From and To headers are registered. A user is registered if he/she has completed a successful SIP registration, which was inspected by the gateway and has not yet expired.
114
DiffServ Marking of VoIP Data PacketsQuality of Service (QoS) in IP networks is achieved by using dedicated devices to tag IP packets in order to provide preferential treatment for application traffic, according to its characteristics (e.g. high bit rate, low delay).
The model by which the packets are tagged is referred to as the DiffServ (differentiated services) model.
Tagging is done by setting the type of service (ToS) bits on a packet's IP header.
The QoS > DiffServ Marking option in the VoIP tab controls the DiffServ marking of VoIP data packets (such as RTP and RTCP). It does not affect signaling packets.
DiffServ and Expedited ForwardingDiffServ-aware routers implement Per-Hop Behaviors (PHBs), which define the packet forwarding properties associated with a class of traffic.
Most networks use the following commonly-defined Per-Hop Behaviors:
• Default PHB—which is typically best-effort traffic.
• Expedited Forwarding (EF) PHB—for low-latency, low jitter and low-loss traffic.
• Assured Forwarding (AF)—behavior group.
The IP packet for DiffServ networks is classified by six of the bits of the Type of Service (TOS) octet. For Expedited Forwarding, the TOS octet is marked with the the 101110 codepoint, as specified in RFC3246 - "An Expedited Forwarding PHB (Per-Hop Behavior)".
Configuration DetailsThe following configuration settings apply to the QoS > DiffServ Marking option in the VoIP tab:
Default Gateway Settings• Mark ToS with expedited forwarding marks the ToS byte of the IP header of all RTP and
RTCP traffic through the gateway, with the DiffServ encoding for expedited forwarding. This corresponds to the 101110 codepoint referred to in RFC 3246. The ToS byte is marked for expedited forwarding only if the existing marking is for "normal service" (that is, the six bits are zero).
Chapter 8 Quality of Service 115
• Override existing marking marks the ToS byte of the IP header of all RTP and RTCP traffic through the gateway, with the DiffServ encoding for expedited forwarding, irrespective of the existing markings of the ToS header. This corresponds to the 101110 codepoint referred to in RFC 3246.
Exceptions per GatewayIt is possible to define exceptions to the default gateway settings. For each gateway, it is possible to either enable settings that are different from the default, or to disable the settings for that gateway.
116
117
Chapter 9RTP/RTCP SmartDefense Protections
NGX R65.2.100 includes a number of SmartDefense protections for RTP and RTCP. This chapter describes the RTP and RTCP protections.
SmartDefense protections can be configured per profile. For each profile, the protection can be made inactive or active, and can be set to monitor-only mode. Logging options for each protection can also be configured per profile.
The descriptions in this chapter appear in SmartDashboard, at the bottom of every SmartDefense protection. The information is included in this guide for reference purposes.
In This Section
Note - RTP and RTCP SmartDefense Protections require a VoIP license, in addition to the Check Point gateway license. See “Licensing Requirements” on page 29.
RTP SmartDefense Protections page 118
RTCP SmartDefense Protections page 121
RTP/RTCP protections with SecureXL page 124
118
RTP SmartDefense ProtectionsDescription
RTP (Real-Time Transport Protocol) is an Internet protocol for transmitting real-time data such as audio and video. RTP itself does not guarantee real-time delivery of data, but it does provide mechanisms for the sending and receiving applications to support streaming data. Typically, RTP runs on top of the UDP protocol, although the specification is general enough to support other transport protocols.
SmartDefense Protection
RTP security protections verify that various RTP headers are compliant with RFC 3550 for RTP. Malformed packets are blocked. 0
Block multicast RTP connections
Description
RFC 3350 section 14 states "RTP may be sent via IP multicast, which provides no direct means for a sender to know all the receivers of the data sent and therefore no measure of privacy. Rightly or not, users may be more sensitive to privacy concerns with audio and video communication than they have been with more traditional forms of network communication".
SmartDefense Protection
This protection blocks multicast RTP packets from crossing the gateway.
Note - RTP and RTCP security is enforced only if media connections are opened dynamically by the Check Point gateway (as configured in SmartDashboard, in the VoIP page of the gateway).
Block multicast RTP connections page 118
Block non Version 2 RTP Packets page 119
Block multiple Synchronization Sources (SSRC) - RTP page 119
Validate ports parity (even) page 119
Validate payload size page 120
Validate Extension page 120
Validate CC field page 120
Chapter 9 RTP/RTCP SmartDefense Protections 119
Block non Version 2 RTP Packets
Description
The RTP header has a fixed format, and includes the version (V) field. RFC 3350 states "This field identifies the version of RTP. The version defined by this specification is two (2). (The value 1 is used by the first draft version of RTP and the value 0 is used by the protocol initially implemented in the "vat" audio tool.)"
SmartDefense Protection
This protection ensures that the value of the version field in the RTP packet is 2. RTP packets with a different version number are dropped.
Block multiple Synchronization Sources (SSRC) - RTP
Description
The Synchronization Source (SSRC) field in the RTP packet header identifies the source of a stream of RTP packets. It is the call identification for the RTP stream.
SmartDefense Protection
This protection validates that the SSRC belongs to the current connection, thereby preventing session hijacking.
Validate ports parity (even)
Description
RFC 3550 states that "RTP relies on the underlying protocol(s) to provide demultiplexing of RTP data and RTCP control streams. For UDP and similar protocols, RTP SHOULD use an even destination port number and the corresponding RTCP stream SHOULD use the next higher (odd) destination port number."
SmartDefense Protection
This protection ensures that the destination port number of RTP data packets is even. RTP packets with an odd destination port number are dropped.
120
Validate payload size
Description
An RTP packet includes the fixed RTP header and the payload data. Typical RTP payload data are audio samples or compressed video data. RTP packets can carry many different audio and video Payload Types (CODECs). Each Payload Type has a maximum allowed size.
SmartDefense Protection
This protection ensures that the RTP packet size corresponds to the permitted of size of the payload.
Validate Extension
Description
The RTP fixed headers can be followed by a (single) header extension. The size of the header extension is variable. The header extension contains a 16-bit length field that counts the size of the extension.
SmartDefense Protection
This protection verifies that the actual length of the extension matches the length field of the header extension.
Validate CC field
Description
The RTP packet fixed header includes the CSRC count (CC) field. The CSRC list that follows the fixed header identifies the contributing sources for the payload contained in this packet, and the number of identifiers is given by the CC field.
SmartDefense Protection
The CC field must be consistent with the RTP packet size. This protection verifies that actual size of the RTP packet matches the CC field of the header extension.
Chapter 9 RTP/RTCP SmartDefense Protections 121
RTCP SmartDefense ProtectionsDescription
RTP control protocol (RTCP), forms part of the RTP protocol used to carry VoIP communications. RTCP monitors the quality of service (QoS) and conveys information about the participants in an on-going session. It is based on the periodic transmission of control packets to all participants in the session, using the same distribution mechanism as the data packets
SmartDefense Protection
RTCP security protections verify that various RTP headers are compliant with RFC 3550 for RTP. Malformed packets are blocked. 0
In This Section
Block multicast RTCP connections
Description
RFC 3350 section 14 states "RTP may be sent via IP multicast, which provides no direct means for a sender to know all the receivers of the data sent and therefore no measure of privacy. Rightly or not, users may be more sensitive to privacy concerns with audio and video communication than they have been with more traditional forms of network communication".
SmartDefense Protection
This protection blocks multicast RTCP packets from crossing the gateway.
Note - RTP and RTCP security is enforced only if media connections are opened dynamically by the Check Point gateway (as configured in SmartDashboard, in the VoIP page of the gateway).
Block multicast RTCP connections page 121
Block multiple Synchronization sources (SSRC) - RTCP page 122
Validate port’s parity (odd) page 122
Validate length page 122
122
Block multiple Synchronization sources (SSRC) - RTCP
Description
The Synchronization Source (SSRC) field in the RTCP packet header identifies the source of a stream of RTCP packets. It is the is the call identification for the RTCP stream.
SmartDefense Protection
This protection validates that the SSRC belongs to the current connection, thereby preventing session hijacking.
Validate port’s parity (odd)
Description
RFC 3550 states that "RTP relies on the underlying protocol(s) to provide demultiplexing of RTP data and RTCP control streams. For UDP and similar protocols, RTP SHOULD use an even destination port number and the corresponding RTCP stream SHOULD use the next higher (odd) destination port number."
SmartDefense Protection
This protection ensures that the destination port number for RTCP is odd. RTCP packets with an even destination port number are dropped.
Validate length
Description
RFC 3550 states that "Each RTCP packet begins with a fixed part similar to that of RTP data packets, followed by structured elements that MAY be of variable length according to the packet type... The alignment requirement and a length field in the fixed part of each packet are included to make RTCP packets "stackable". Multiple RTCP packets can be concatenated without any intervening separators to form a compound RTCP packet that is sent in a single packet of the lower layer protocol, for example UDP."
Chapter 9 RTP/RTCP SmartDefense Protections 123
SmartDefense Protection
This protection validates that the length field adds up to the overall packet length minus 1. RTCP packets with an invalid length are dropped.
124
RTP/RTCP protections with SecureXLSecureXL supports RTP/RTCP enforcement. With SecureXL installed, there is no performance impact when turning on the RTP and RTCP protections.
Some SecureXL devices do not support RTP/RTCP security. To check whether the SecureXL device supports RTP/RTCP security, run the fwaccel stat command on the gateway.
When using SecureXL devices that do not support RTP/RTCP security, it is possible to either accelerate RTP/RTCP, or enforce RTP/RTCP security. The default is to enforce RTP/RTCP security. To change the default behavior and accelerate RTP/RTCP, run the command fw ctl set int cphwd_accel_rtp_no_dev_enforce 1
125
Chapter 10SIP Application Policy
An organization may decide to block certain VoIP services because they consume more bandwidth than the IP infrastructure can support, or because they do not comply with the organization’s policy.
Application Policy options limit the VoIP services available to users.
Application Policy options are not intended to protect against attacks, which is the role of SmartDefense.
The SIP application policy options are available in the SmartDashboard VoIP tab, under Application Policy > SIP.
In This Chapter
Methods Unsupported by SIP Server page 126
Early Media page 129
Proxy Redirecting a Call to a Non-Configured Proxy page 129
Proxy Failover page 130
Video page 131
Audio page 131
Instant Messaging page 131
Push to Talk over Cellular page 131
126
Methods Unsupported by SIP ServerMethods are essentially commands that the SIP requests invoke on a server. RFC 3261 states that "SIP is based on an HTTP-like request/response transaction model. Each transaction consists of a request that invokes a particular method, or function, on the server and at least one response".
There are various types of SIP server, each performing specific functions. A SIP proxy is one type of SIP server, whose key function is signal routing. Other types of SIP server are "Registrar" and "Presence server". The core function of a proxy is signal routing, but it may well act as a registrar and presence server as well.
If SIP server is flooded with requests with methods the server does not support, the server may be overloaded, which could affect customers service levels.
Application Policy Details
Server Specific ConfigurationThis option makes it possible to block requests with specific SIP methods (commands) at the VoIP gateway, so that the requests do not reach the SIP server.
Methods can be blocked per SIP server type. Blocking methods per server type makes it possible to ensure that only specific server with specific capabilities are allowed to handle particular signaling tasks.
A SIP server can be defined as one or more of the following server types: Proxy, Registrar and Presence server.
Each SIP Server type has a set of methods that it supports by default, as shown in Table 10-1. The list of the methods supported by each server can be changed.
There are two options for blocking unsupported methods. Methods can be blocked based on SIP server type, or alternatively, specific methods can be blocked.
In addition, it is also possible to block unknown methods. Unknown methods are methods that do not appear in Table 10-1.
Chapter 10 SIP Application Policy 127
Block Unsupported SIP Commands Configuration Details
To block commands that are unsupported by the SIP server:
1. Define the SIP server(s), and the type of each server: Proxy, Registrar or Presence server. See “Defining a SIP Proxy” on page 89.
2. In the SmartDashboard VoIP tab, go to: Application Policy > SIP > Methods Unsupported by SIP Server.
3. in the Server specific configuration section, configure each server. Select a server and click Edit.
The Supported Methods page of the SIP server object opens.
Table 10-1 Default methods supported by each SIP server type
Method SIP Proxy SIP Registrar SIP Presence
INVITE X
ACK X
BYE X
CANCEL X
REGISTER X X
OPTIONS X
INFO X
MESSAGE X
NOTIFY X X X
PING X
PRACK X
PUBLISH X
REFER X
SUBSCRIBE X X
UPDATE X
128
Figure 10-1 Supported Methods page of the SIP server object
4. Configure the methods (commands) to be prevented from reaching the server. There are two options for blocking unsupported methods:
• Block methods based on SIP server type (Proxy, Registrar, Presence)
• Block specific methods
5. Optionally, Block unknown methods.
• Block unknown methods blocks methods that are not in the list or Blocked Methods or the list of Allowed methods. This option is enabled by default. If disabled, the firewall accepts unrecognized messages, but only if they conform to the SIP RFC (i.e., they are properly formatted and contain the mandatory CALL-ID, FROM and TO fields).
6. Click OK.
This takes you back to the Methods Unsupported by SIP Server page of the VoIP tab.
In the Gateway Install-On section of the Methods Unsupported by SIP Server page, choose the VoIP gateways on which to apply the option. Either
• Enforce on all gateways, or
Chapter 10 SIP Application Policy 129
• Do not enforce on specific gateways, by defining an Exception list.
7. Select Tracking Options for Blocked/Monitored traffic.
8. Save, and install the Policy.
Early Media SIP enables endpoints in an INVITE transaction to send media packets before an SDP offer/answer exchange has completed. These media packets are called early media. The use of early media causes several problems:
• Call failure (when endpoints use early media for an extended period of time).
• Lack of confidentiality (due to the inability to negotiate keys for media security).
• Lack of access control (the UAC is obliged to receive media received from any host on the Internet).
• Undefined interaction with forked media streams.
• Denial of Service attacks which make use of Early media.
Blocking early media is a simple but mostly effective way of solving most of the problems that early media can cause. Blocking early media also reduces traffic. In many cases, when early media is blocked, users hear a ringing tone instead of "on hold" media.
Proxy Redirecting a Call to a Non-Configured Proxy
When establishing a SIP session, the proxy may redirect the endpoint to a different proxy.
Enabling redirection to another proxy makes it possible to improve service availability by having a backup server take over in case the first server fails. In addition, the second server can be set up for load sharing with the first server.
130
Proxy FailoverWhen establishing a SIP session, the proxy may redirect the endpoint to a different proxy.
Enabling redirection to another proxy makes it possible to improve service availability by having a backup server take over in case the first server fails. In addition, the second server can be set up for load sharing with the first server.
However, allowing redirection to another proxy can lead to security concerns. An organization may be willing to work only with known proxy servers.
This option blocks connections from and to any proxy that takes over control of calls from another proxy. The default is to allow proxy failover.
Chapter 10 SIP Application Policy 131
Video This option blocks all applications that use SIP to carry video. This includes the video components of MSN Messenger, when it is configured to use SIP. The default is not to block.
Audio This option blocks all applications that use SIP to carry audio. This includes the audio components of MSN Messenger when it is configured to use SIP. The default is not to block.
Instant Messaging There are several known security issues associated with SIP-based instant messaging applications. These are similar to the vulnerabilities associated with SIP when used for Voice Over IP (VoIP), with additional vulnerabilities caused by the nature of Instant Messengers and the way that they are used in the enterprise.
This option blocks all applications that use SIP for instant messaging. The default is to block.
Push to Talk over CellularThis option blocks Push to Talk over Cellular traffic.
Push to Talk over Cellular (PTToC or PoC) is a way of instantaneously sending transmissions to other users on a mobile phone network. It emulates walkie-talkie communications.
Note - To selectively block applications provided by MSN Messenger, do not check this option. Instead, configure Application Intelligence > Instant Messengers > MSN Messenger over SIP. Some peer to peer applications also allow Instant Messaging, and these can be blocked via Application Intelligence > Peer to Peer.
132
133
Chapter 11SIP SmartDefense Protections
SmartDefense protects against attacks by identifying attacks signatures, identifying packets with protocol anomalies, and ensuring RFC compliance.
NGX R65.2.100 includes a large number of SmartDefense protections for SIP. This chapter describes every SIP protection for gateways of that version.
SmartDefense protections can be configured per profile. For each profile, the protection can be made inactive or active, and can be set to monitor-only mode. Logging options for each protection can also be configured per profile.
The descriptions in this chapter appear in SmartDashboard, at the bottom of every SmartDefense protection. The information is included in this guide for reference purposes.
In This Chapter
Block Notify messages with Invalid Subscription-State Header page 134
Block Basic Authorization page 135
Maximum allowed retransmissions page 136
SIP Header Spoofing page 137
Block Unrecoverable SIP Inspection Errors page 139
SIP Protocol Anomaly Protections page 140
134
Block Notify messages with Invalid Subscription-State Header
Attack Name:
VoIP-Phones: SIP-Notify-Message packet spoofing
Industry Reference
CVE-2005-2181
Threat Description
Many VoIP hardphones ignore the value of Call-ID header field, the tag and branch parameters while processing NOTIFY messages. Consequently they can be fooled into processing status messages that do not match their status, such as "Messages-Waiting".
According to RFC 3265 section 3.2, if the state of a subscription changes, the notifier must send a NOTIFY message to the subscriber — even if the subscription was created using a non-SUBSCRIBE mechanism. If a UAC node that is unaware of the subscription receives a NOTIFY message, the node must respond with a "481 Subscription does not exist" message.
Some phones process spoofed messages (such as "Messages-Waiting") even if they are unaware of the subscription.
An attacker could send bogus "Messages-Waiting: yes" messages to all phones in a SIP-environment. If the phones process this status message they will indicate to users that a message is waiting for them (by means of an icon or a blinking display, for example). If this message is sent to many recipients it could lead to server peaks as many users simultaneously attempt to reach their voicemail. Because there are no in fact no new voice messages, users will call support, to fix this apparent server problem, leading to reduced support service levels.
SmartDefense Protection
If a UAC node receives a NOTIFY message to change its subscription state, and the subscription state of the message with the NOTIFY method is not valid, (that is, the node is not subscribed) then the message is blocked.
Chapter 11 SIP SmartDefense Protections 135
Block Basic Authorization Description
RFC 3261 SIP: Session Initiation Protocol states: "SIP servers MUST NOT accept or request Basic authentication." and "Basic authentication has been removed entirely and its usage forbidden." This is a change from RFC 2543.
Threat Description
RFC 2069 - An Extension to HTTP Digest Access Authentication states: "The greatest threat to the type of transactions for which these protocols are used is network snooping. This kind of transaction might involve, for example, online access to a database whose use is restricted to paying subscribers. With Basic authentication an eavesdropper can obtain the password of the user. This not only permits him to access anything in the database, but, often worse, will permit access to anything else the user protects with the same password.
SmartDefense Protection
The use of Basic Authentication is blocked.
136
Maximum allowed retransmissionsDescription
A SIP client (such as an IP phone) begins a transaction (a phone call, for example) by sending an INVITE to a server (such as a proxy). The server accepts the invitation with a 200 OK response. The client acknowledges the response by sending an ACK to the server. The server keeps on transmitting its 200 OK message until it receives the ACK from the client, or until a timeout occurs.
Threat Description
An attacker can flood a SIP server with irresolvable requests belonging to different transactions. This can consume server resources, leading to reduced service levels.
SmartDefense Protection
This protection allows you to configure the maximum number of times that a SIP server is allowed to retransmit a response within a transaction. Subsequent server responses are blocked.
Chapter 11 SIP SmartDefense Protections 137
SIP Header Spoofing Threat Description
One of the first steps an attacker takes before attacking a VoIP entity (server or endpoint) is to analyze the server response, in order to gather as much information as possible about it. This is known as "fingerprinting".
Some headers in the response from the VoIP entity contain information that can be used by an attacker to identify the VoIP entity. The attacker can then launch an attack that exploits weaknesses in that particular entity.
SmartDefense Protection
This protection allows you to either delete (strip) a header field from a SIP header, or change its value. For example, a typical SIP header contains the name and version number of the SIP entity participating in the session. This protection can be used to spoof the version information.
Configuration Details
To define a header field, and either strip it from the SIP header, or change its value:
1. In the SmartDefense tab, select Application Intelligence > Protections for R65.2.100 > SIP > SIP Header Spoofing.
2. In the SmartDefense SIP Header Spoofing page, click Edit.
The Header Spoofing Patterns window opens.
3. Click Add.
The Header Spoofing Settings window opens.
4. Define a header name, and either strip it from the SIP header, or change its value:
• Header Name is the case sensitive name of the header field. Ensure the Header field name is configured exactly as it appears in SIP messages - with correct capitalization, and without the white space/delimeter after the header field name. Use a packet capture utility to determine the exact name, and to confirm whether or not it is the same as the name defined in section 20 of the SIP RFC (RFC3261). Some SIP implementations may use the compact form of the header field name, as defined in section 7.7.3 of RFC3261. It is recommended to define the compact version in addition to the long form.
138
• Strip header deletes the specified Header Name from a SIP header. The From, To and CallID headers are never stripped. If they are defined to be stripped, a policy installation warning is generated. Stripping of headers may result in a failure of a SIP call. It is advisable to test the effect before implementing in a production network.
• Replace Value is the value of the header field that will replace the original header value. The name of the header field is unchanged.
5. Click OK twice to return to the SIP Header Spoofing page.
6. Add Exceptions, if any.
7. Define SIP Header Spoofing Settings per Profile.
8. Install the Policy.
Note - For Strip header and Replace header - 1. The values of the From, To and CallID headers are never stripped or replaced. If they are defined to be stripped or replaced, a policy installation warning is generated. 2. Stripping and Replacing of mandatory header field values may result in a failure of a SIP call. It is advisable to test the effect before implementing in a production network.
Chapter 11 SIP SmartDefense Protections 139
Block Unrecoverable SIP Inspection ErrorsDescription
In rare situation, SmartDefense cannot inspect a packet, due to reasons that are unconnected to any of the configurable SmartDefense SIP protections or VoIP tab SIP Application Policy options, for example, due to memory allocation issues.
Threat Description
If SmartDefense is unable to inspect a packet, and the packet is accepted, the internal network is unprotected against any possible threat that may be carried by that packet.
SmartDefense Protection
Configure SmartDefense to handle packets that cannot be inspected. Either block (for increased security) or allow such packets (for increased connectivity). By default, those packets are dropped.
140
SIP Protocol Anomaly ProtectionsIn This Section
Introduction to SIP Protocol Anomaly ProtectionsA protocol anomaly is a field name or value in the protocol header that is RFC compliant, but deviates from normal use. A field value with 100s of characters where a few characters is normal, is a protocol anomaly.
If a protocol anomaly is found in the VoIP packet, this is a good indication that the VoIP network is being attacked.
The following definitions relate to the structure of SIP headers. The definitions are based on RFC 3261 section 6:
• SIP messages are made up of a header and a body.
• A header is structured as a sequence of header fields.
• A header field can appear as one or more header field rows.
• Each header field consists of a field name, followed by a colon (":") and zero or more field values (field-name: field-value)
• Multiple header field values on a given header field row are separated by commas.
• Some header fields can only have a single header field value, and as a result, always appear as a single header field row.
Introduction to SIP Protocol Anomaly Protections page 140
Strict protocol flow enforcement page 141
Max allowed Header Name length page 142
Max allowed Header Value length page 142
Max allowed URI length page 142
Max allowed Domain length page 143
Max allowed Call-ID length page 143
Max allowed Tag length page 144
Max allowed SDP line length page 144
General header security page 146
Specific header security page 149
Chapter 11 SIP SmartDefense Protections 141
Threat Description
Protocol anomalies can lead to buffer overflow conditions, parser errors, and to malformed packets.
Protocol anomalies in SIP messages make SIP applications vulnerable to Denial of Service and other attacks that repeatedly send huge quantities of bogus data, eventually overwhelming the servers.
For example, many buffer-overflow attacks repeatedly send a very large header to the VoIP phone. Buffer overflow conditions can also allow for arbitrary code execution.
SmartDefense Protection
Stateful and Stateless protocol validation is performed on SIP headers. SIP messages with header values that do not match normal usage are blocked.
Strict protocol flow enforcement
Description
RFC 3261 states: "A SIP transaction between a client and a server and comprises all messages from the first request sent from the client to the server up to a final (non-1xx) response sent from the server to the client. If the request is INVITE and the final response is a non-2xx, the transaction also includes an ACK to the response. The ACK for a 2xx response to an INVITE request is a separate transaction."
SIP message flow is defined in RFC 3261. Four state machines are defined:
• Invite Client Transaction (Section 17.1.1 of RFC 3261)
• Non Invite Client Transaction (Section 17.1.2)
• Invite Server Transaction (Section 17.2.1)
• Non Invite Server Transaction (Section 17.2.2)
Threat Description
If the protocol flow is not enforced, SIP transactions become vulnerable to call hijacking and man in the middle attacks.
142
SmartDefense Protection
RFC 3261 defines a final response as a response that terminates a SIP transaction, as opposed to a provisional response that does not. All 2xx, 3xx, 4xx, 5xx and 6xx responses are final.
This protection enforces the protocol state machine. For example, it ensures that no further response follows a final response to a request.
Max allowed Header Name length
SmartDefense Protection
This protection ensures that the field name element of all header fields is shorter than the maximum length specified in this protection.
Note that the lengths of some specific header names are validated by other Protocol Anomaly protections.
Max allowed Header Value length
SmartDefense Protection
This protection ensures that the lengths of all header field values are shorter than the maximum length specified in this protection.
Note that the lengths of some specific field values are validated by other Protocol Anomaly protections.
Max allowed URI length
Description
RFC 3261 defines a SIP or SIPS URI as follows: "A SIP or SIPS URI identifies a communications resource. Like all URIs, SIP and SIPS URIs may be placed in web pages, email messages, or printed literature. They contain sufficient information to initiate and maintain a communication session with the resource."
"Its general form, in the case of a SIP URI, is:
sip:user:password@host:port;uri-parameters?headers
Chapter 11 SIP SmartDefense Protections 143
The format for a SIPS URI is the same, except that the scheme is "sips" instead of sip. "
SIP or SIPS URI can appear in various places in the SIP message, for example, in the Request-Line, and in the To, From and Contact header fields.
SmartDefense Protection
This protection verifies that the length of a URI that appears in any SIP header field is shorter than or equal to the length configured here. SIP messages containing longer URIs are blocked.
Max allowed Domain length
Description
The domain appears in many SIP messages in a number of locations, normally as part of the SIP URI. In a SIPI URI, the domain appears on the right hand side of the at-sign. For instance: sip:[email protected], or sip:[email protected]).
SmartDefense Protection
This protection ensures that wherever the domain appears, its length is shorter or equal to than the maximum length specified in this protection.
Max allowed Call-ID length
Description
RFC 3261 section 20.8 states "The Call-ID header field uniquely identifies a particular invitation or all registrations of a particular client. A single multimedia conference can give rise to several calls with different Call-IDs, for example, if a user invites a single individual several times to the same (long-running) conference. Call-IDs are case-sensitive and are simply compared byte-by-byte."
Examples:
Call-ID: [email protected]
144
SmartDefense Protection
This protection ensures that the lengths of the Call-ID header field is shorter than or equal to the maximum length specified in this protection.
Max allowed Tag length
Description
RFC 3261 section 19.3 states: "The "tag" parameter is used in the To and From header fields of SIP messages. It serves as a general mechanism to identify a dialog, which is the combination of the Call-ID along with two tags, one from each participant in the dialog. "
The tag parameter is a random string that is added to the URI in the header by the SIP phone. For example:
From: Alice <sip:[email protected]>;tag=1928301774
SmartDefense Protection
This protection ensures that the lengths of the tag parameter is shorter than or equal to the maximum length specified in this protection.
Max allowed SDP line length
Description
The Session Description Protocol (SDP) (described in RFC 4566) is used for describing multimedia sessions. SDP can be used by endpoints to agree on the parameters of a session. The SDP message is carried in the body of the SIP message, in a way that is analogous to a document attachment being carried by an email message, or a web page being carried in an HTTP message.
The SIP message contains a Content-Type header and a Content-Length header. The Content-Type header field indicates the media type of the message-body sent to the recipient, and the Content-Length header field indicates the size of the message-body.
For example:
Content-Type: application/sdp
Content-Length: 142
Chapter 11 SIP SmartDefense Protections 145
SmartDefense Protection
This protection measures the actual length of the SDP message in the body of the SIP message (as opposed to the length indicated in the Content-Length header field). If the SDP message is longer than configured here, the message is blocked.
146
General header securityThese protections relate to protocol anomalies in the SIP header in general, rather than to specific header fields.
In This Section
Verify Format of header
Threat Description
An invalid header field format can lead to incorrect parsing of the message, a parser crash, incorrect handling of the message, and to Denial of Service, due to the need to respond to the invalid message.
SmartDefense Protection
This protection validates various parts of the message header. It ensure there is a header name, that there is a colon after the header name, that header field-values are not empty, and that the values of unknown header fields (which are allowed) have a valid syntax.
Max allowed occurrences of the same field (for fields with multiple occurrences)
Description
RFC 3261 section 20 specifies the allowed SIP header fields. There are 44 in total. Examples of header field are CONTACT, RECORD-ROUTE, and VIA.
RFC 3261 sections 7.3.1 specifies that "Multiple header field rows with the same field-name MAY be present in a message". However, the number of times a header field may occur in a message is not limited.
Verify Format of header page 146
Max allowed occurrences of the same field (for fields with multiple occurrences) page 146
Enforce mandatory fields existence page 147
Enforce single occurrence of fields by the RFC page 147
Chapter 11 SIP SmartDefense Protections 147
Threat Description
A header field that occurs many times in a message may lead to a Parser crash or incorrect parsing of the message.
SmartDefense Protection
This protection allows you to limit the number of times that a given header field can occur in a message.
Enforce mandatory fields existence
Description
RFC 3261 section 8.1.1 states "A valid SIP request formulated by a UAC MUST, at a minimum, contain the following header fields: To, From, CSeq, Call-ID, Max-Forwards, and Via; all of these header fields are mandatory in all SIP requests. These six header fields are the fundamental building blocks of a SIP message, as they jointly provide for most of the critical message routing services including the addressing of messages, the routing of responses, limiting message propagation, ordering of messages, and the unique identification of transactions. "
Threat Description
Repeated sending of a SIP message that does not contain one of the mandatory header fields may lead to Denial of Service because the User Agent Server or client are kept busy sending error responses. The User Agents may also be mishandle these messages, which could result in service disruption.
SmartDefense Protection
This protection ensures that all mandatory header fields (To, From, CSeq, Call-ID, Max-Forwards, and Via) are present. Messages that do not contain the mandatory header fields are blocked.
Enforce single occurrence of fields by the RFC
Description
Some header fields must occur only once in a SIP message. These header fields are: To, From, CSeq, Call-ID and Max- Forwards.
148
Threat Description
If header fields that are required to appear only once in a SIP message header appear multiple times, this can lead to a parser crash, or incorrect parsing of the message. It may also lead to Denial of Service because the User Agent Server or client are kept busy sending error responses.
SmartDefense Protection
This protection ensures that all header fields that are required to appear only once (To, From, CSeq, Call-ID and Max- Forwards) are present. Messages that contain multiple instances of these header fields are blocked.
Chapter 11 SIP SmartDefense Protections 149
Specific header securityThese protections relate to protocol anomalies in specific SIP header fields.
In This Section
Block messages with invalid header value
Description
RFC 3261 defines the allowed SIP message request and response header fields, specifies their format, and limits the values of some of those header fields.
"Max-Forwards serves to limit the number of hops a request can make on the way to its destination … The Max-Forwards value is an integer in the range 0-255."
"The CSeq header field serves as a way to identify and order transactions. It consists of a sequence number and a method … The sequence number value MUST be expressible as a 32-bit unsigned integer and MUST be less than 2**31."
"The Expires header field gives the relative time after which the message (or content) expires … The value of this field is an integral number of seconds (in decimal) between 0 and (2**32)-1, measured from the receipt of the request."
"The Min-Expires header field conveys the minimum refresh interval supported for soft-state elements managed by that server … The header field contains a decimal integer number of seconds from 0 to (2**32)-1."
Block messages with invalid header value page 149
Block messages with invalid formats in headers with username page 150
Block messages with invalid format in Start line page 151
Block messages with invalid format in Via Header page 152
Block messages with invalid format in Cseq header page 153
Block messages with invalid port in the SDP header page 153
Block messages with invalid IP address in the SDP header page 154
Min. allowed 'Max forwards' value page 154
Max allowed 'Content length' page 155
150
Threat Description
SIP messages with header fields with values that are not RFC-compliant can lead to a parser crash, or incorrect parsing of the message. They may also lead to Denial of Service because the User Agent Server or client are kept busy sending error responses.
SmartDefense Protection
This protection ensures that the values of the Max-Forwards, CSeq, Expires and Min-Expires header fields are RFC-compliant. Messages with non-compliant values are blocked.
This protection overrides the SIP General Security protections. For example: if this protection is off, then the Verify Format of Header protection is not performed on invalid headers.
Block messages with invalid formats in headers with username
Description
RFC 3261 specifies the valid form for display names (such as "Watson, Thomas") and usernames (such as [email protected]). Usernames appear in SIP and SIPS URIs. SIP or SIPS URI can appear in the Request-Line, and in the To, From and Contact header fields.
The format of Contact header field, for example, is defined in section 20.10, which states "When the header field value contains a display name, the URI including all URI parameters is enclosed in "<" and ">".
Also stated in section 20.10: "There may or may not be LWS (linear whitespace) between the display-name and the "<". These rules for parsing a display name, URI and URI parameters, and header parameters also apply for the header fields To and From."
An example of an invalid format is a SIP URI with spaces:
To: "Watson, Thomas" < sip:[email protected] >
Another example of an invalid format is a single quote in the display name
To: "Mr. J. User <sip:[email protected]>
Chapter 11 SIP SmartDefense Protections 151
Threat Description
In invalid format in a header with a username may lead to a parser crash or to incorrect parsing of the username. It could also lead to database poisoning.
SmartDefense Protection
This protection ensures that the format of headers with username is valid. Messages with invalid formats in headers with usernames are blocked.
This protection overrides the SIP General Security protections. For example: if this protection is off, then the Verify Format of Header protection is not performed on headers with usernames.
Block messages with invalid format in Start line
Description
RFC 3261 section 7.1 states "SIP requests are distinguished by having a Request-Line for a start- line. A Request-Line contains a method name, a Request-URI, and the protocol version separated by a single space (SP) character.
The Request-Line ends with CRLF. No CR or LF are allowed except in the end-of-line CRLF sequence. No linear whitespace (LWS) is allowed in any of the elements.
Request-Line = Method SP Request-URI SP SIP-Version CRLF"
Section 7.1 also defines "Method", "Request-URI" and "SIP-Version".
Threat Description
An invalid format of a start line in a SIP request can lead to a parser crash, or incorrect parsing of the message. It may also lead to Denial of Service because the User Agent Server or client are kept busy sending error responses.
SmartDefense Protection
This protection ensures that the start line of a SIP request has a valid format. Messages with a start line that has an invalid format are blocked.
This protection overrides the SIP General Security protections. For example: if this protection is off, then the Verify Format of Header protection is not performed on messages with invalid format in Start line.
152
Block messages with invalid format in Via Header
Description
RFC 3261 section 20.42 states: "The Via header field indicates the path taken by the request so far and indicates the path that should be followed in routing responses. The branch ID parameter in the Via header field values serves as a transaction identifier, and is used by proxies to detect loops.
A Via header field value contains the transport protocol used to send the message, the client's host name or network address, and possibly the port number at which it wishes to receive responses. A Via header field value can also contain parameters such as "maddr", "ttl", "received", and "branch". "
An example of a via header:
Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds
Threat Description
A via header field with an invalid format can lead to a parser crash, or incorrect parsing of the message. It may also lead to Denial of Service because the User Agent Server or client are kept busy sending error responses.
SmartDefense Protection
This protection ensures that the syntax of the via header is valid, and that it contains reasonable values.
An example of bad syntax in the header field is additional semicolons and commas without parameters or values:
Via: SIP/2.0/UDP 192.0.2.15;;,;,,;;;
A example of an unreasonable client address is 255.255.255.255 or 127.0.0.1.
Messages with invalid format in Via Header are blocked.
This protection overrides the SIP General Security protections. For example: if this protection is off, then the Verify Format of Header protection is not performed on messages with invalid format in the Via Header.
Chapter 11 SIP SmartDefense Protections 153
Block messages with invalid format in Cseq header
Description
Section 8.1.1.5 states: "The CSeq header field serves as a way to identify and order transactions. It consists of a sequence number and a method. The method MUST match that of the request. For non-REGISTER requests outside of a dialog, the sequence number value is arbitrary. The sequence number value MUST be expressible as a 32-bit unsigned integer and MUST be less than 2**31. "
Example: CSeq: 4711 INVITE
Threat Description
An invalid format of the Cseq header field can lead to a parser crash, or incorrect parsing of the message. It may also lead to Denial of Service because the User Agent Server or client are kept busy sending error responses.
SmartDefense Protection
This protection enforces the format of the Cseq header field name and value. Among the checks it makes: Ensures the Cseq header field appears once only in the header, and that its value has the correct format.
This protection overrides the SIP General Security protections. For example: if this protection is off, then the Verify Format of Header protection is not performed on the Cseq header.
Block messages with invalid port in the SDP header
Description
The Session Description Protocol (SDP) (described in RFC 4566) is used for describing multimedia sessions. SDP can be used by endpoints to agree on the parameters of a session. The SDP message is carried in the body of the SIP message, in a way that is analogous to a document attachment being carried by an email message, or a web page being carried in an HTTP message.
Media announcements in the SDP description have the format:
m=<media> <port> <transport> <fmt list>
The <port> sub-field is the transport port to which the media stream will be sent. The transport port should be a digit in the range "1024" to "65535" inclusive, for UDP based media.
154
SmartDefense Protection
This protection ensures that the transport port in the SDP header is a digit in the range "1024" to "65535" inclusive. SDP messages that do not conform are blocked.
Block messages with invalid IP address in the SDP header
Description
The Session Description Protocol (SDP) (described in RFC 4566) is used for describing multimedia sessions. SDP can be used by endpoints to agree on the parameters of a session. The SDP message is carried in the body of the SIP message, in a way that is analogous to a document attachment being carried by an email message, or a web page being carried in an HTTP message.
The session connection data line in the SDP description takes the form:
c=<network type> <address type> <connection address>
Typically the connection address will be a class-D IP multicast group address. If the session is not multicast, then the connection address contains the fully-qualified domain name or the unicast IP address of the expected data source or data relay or data sink.
SmartDefense Protection
This protection ensures that the connection IP address specified in the SDP header is valid. A value of 127.0.0.1 for example, is not valid. SDP headers with invalid IP addresses are blocked.
Min. allowed 'Max forwards' value
Description
RFC 3261 states: "The Max-Forwards header field serves to limit the number of hops a request can make on the way to its destination. It consists of an integer that is decremented by one at each hop. If the Max-Forwards value reaches 0 before the request reaches its destination, it will be rejected with a 483(Too Many Hops) error response."
"A UAC MUST insert a Max-Forwards header field into each request it originates with a value that SHOULD be 70. This number was chosen to be sufficiently large to guarantee that a request would not be dropped in any SIP network when there
Chapter 11 SIP SmartDefense Protections 155
were no loops, but not so large as to consume proxy resources when a loop does occur. Lower values should be used with caution and only in networks where topologies are known by the UA."
"The Max-Forwards value is an integer in the range 0-255."
Threat Description
A value of Max-forwards request header that is too low indicates that the SIP message has traversed a large number of proxies, that it is spending too long on the network and is consuming proxy resources. It also indicates and that there may be loops in the SIP network.
SmartDefense Protection
This protection ensures that the value of the Max-forwards request header field does not fall below the configured value. Messages with a Max-forwards header field value that is lower than the configured minimum are blocked.
This protection overrides the SIP General Security protections. For example: if this protection is off, then the Verify Format of Header protection is not performed on the Max forward header.
Max allowed 'Content length'
Description
RFC 3261 section 20.14 states: "The Content-Length header field indicates the size of the message-body, in decimal number of octets, sent to the recipient. Applications SHOULD use this field to indicate the size of the message-body to be transferred, regardless of the media type of the entity. If a stream-based protocol (such as TCP) is used as transport, the header field MUST be used."
Example: Content-Length: 349
Threat Description
A Content-length header field that is incorrect or invalid can lead to a parser crash, or incorrect parsing or handling of the message.
156
SmartDefense Protection
This protection ensures that the value of the Content-Length header is valid. If it is larger or smaller than the message body, or if it is a negative number, or not a number, then the message is blocked. It is also possible to configure a maximum value for the Content-Length header field.
This protection overrides the SIP General Security protections. For example: if this protection is off, then the Verify Format of Header protection is not performed on messages the Content Length header.
157
Chapter 12SIP Rule Base Configuration
This chapter explains how to configure Security Rule Base rules so that the gateway allows SIP calls.
In This Chapter
Supported SIP Deployments and NAT Support page 158
SIP-Specific services page 161
General Guidelines for SIP Security Rule Configuration page 162
SIP Rules for a Peer-to-Peer No-Proxy Topology page 163
SIP Rules for a Proxy in an External Network page 164
SIP Rules for a Proxy-to-Proxy Topology page 166
SIP Rules for a Proxy in DMZ Topology page 168
Using SIP on a Non-Default Port page 170
Enabling Dynamic Opening of Ports for SIP Signaling page 171
158
Supported SIP Deployments and NAT Support
Table 12-1 displays a list of supported SIP deployments. NAT, either Hide or Static, can be configured for the phones in the internal network as well as for the proxy.
The Proxy is any SIP proxy and/or registrar. If there is more than one proxy device, signaling passes through one or more Proxies or Registrars. Once the call has been set up, the media passes from endpoint to endpoint, either directly or through one or more Proxies.
Table 12-1 Supported SIP Topologies
No NAT NAT for Internal
Phones—
Hide/Static NAT
NAT for Proxy—
Static NAT
Endpoint to Endpoint(Figure 12-1 on page 158)
Yes Static NAT only Not applicable
SIP Proxy in External (Figure 12-2 on page 159)
Yes Yes Not applicable
SIP Proxy to Proxy (Figure 12-3 on page 159)
Yes Yes Yes
SIP Proxy in DMZ (Figure 12-4 on page 159)
Yes Yes Yes
Figure 12-1 SIP Endpoint-to-Endpoint Topology
The IP Phones communicate directly, without a Proxy. Static NAT can be configured for the phones on the internal side of the gateway. See “SIP Rules for a Peer-to-Peer No-Proxy Topology” on page 163.
Chapter 12 SIP Rule Base Configuration 159
Additional Conditions for Using NAT in SIP Networks
SIP can be used with Network Address Translation (NAT), subject to the following conditions:
Figure 12-2 SIP Proxy in External Network
The IP Phones use the services of a Proxy on the external side of the gateway. This topology enables using the services of a Proxy that is maintained by another organization. It is possible to configure Hide NAT (or Static NAT or no NAT) for the phones on the internal side of the gateway.See “SIP Rules for a Proxy in an External Network” on page 164.
Figure 12-3 SIP Proxy to SIP Proxy Each Proxy controls a separate endpoint domain. Static NAT can be configured for the internal Proxy. For the internal phones, Hide NAT (or Static NAT) can be configured. See “SIP Rules for a Proxy-to-Proxy Topology” on page 166.
Figure 12-4 SIP Proxy in DMZ The same Proxy controls both endpoint domains. This topology makes it possible to provide Proxy services to other organizations. Static NAT (or no NAT) can be configured for the Proxy. Hide NAT (or Static or no NAT) can be configured for the phones on the internal side of the gateway. See “SIP Rules for a Proxy in DMZ Topology” on page 168.
160
• NAT is not supported on IP addresses behind an external Check Point gateway interface
• Manual NAT rules are not supported except for proxy in DMZ deployments. Use Automatic NAT whenever possible.
• When both endpoints are on the trusted side of the gateway, calls cannot be made from the same source to two endpoints, where one endpoint is NATed (either Static or Hide) and the other is not.
• Bidirectional NAT of VoIP calls is not supported. For example, a call from a phone whose address is Hide NATted by a gateway, that sends a message to a proxy server with static NAT, when the phone and the proxy are behind different interfaces of the same gateway.
Chapter 12 SIP Rule Base Configuration 161
SIP-Specific servicesThe following predefined SIP services are available:
For TLS-related configurations, see “Inspection of TLS-Secured SIP Traffic” on page 177.
The following legacy SIP services are available for gateways of version NGX R65 or below. For details on how to use these services, see the “Securing Voice Over IP (VoIP)” chapter of the Firewall NGX R65 Administration Guide at
http://supportcontent.checkpoint.com/documentation_download?ID=7247
Service Purpose
UDP:sip Used for SIP over UDPTCP:sip-tcp Used for SIP over TCPTCP:sip_tls_with_server_certificate Used for encrypted SIP over TLS. TCP:sip_tls_authentication Used for unencrypted SIP over TLSTCP:sip_tls_not_inspected Insecure way of allowing SIP over TLS to pass
without inspectionOther: sip_dynamic_ports Enables the dynamic opening of ports for SIP
signaling. See “Enabling Dynamic Opening of Ports for SIP Signaling” on page 171.
Service Purpose
UDP:sip_any TCP:sip-tcp_any
Used for gateways of version NGX R65 or below, if not enforcing handover. Do not use for NGX R65.2.100.Do not place a VoIP domain in the source or destination of the rule. Instead, use *Any or a network object, together with one of these services. If a VoIP domain is used with these services, it is equivalent to the sip service. For VoIP equipment that uses SIP TCP, use the sip-tcp_any service. When it uses SIP UDP, use the sip_any service.
Note - The services sip and sip_any cannot be used in the same rule because they contradict each other. The same is true for sip-tcp and sip-tcp_any.
162
General Guidelines for SIP Security Rule Configuration
• Anti-spoofing must be configured on the Check Point gateway interfaces.
• Use regular Network objects to allow SIP signaling. There is no need to define special Network objects. Pinholes for data connections (RTP/RTCP and other) are opened dynamically.
• When using Hide NAT for SIP over UDP, the hiding IP cannot be included in the destination of the SIP rule. On the other hand, when using Hide NAT for SIP over TCP, you must include the hiding IP in the destination of the SIP rule, in order to allow the initiation of TCP handshake from the external network to the hiding IP.
• Security rules can be defined that allow either bidirectional calls or only incoming or outgoing calls. The examples provided in the following sections describe how to define bidirectional rules.
Chapter 12 SIP Rule Base Configuration 163
SIP Rules for a Peer-to-Peer No-Proxy Topology
Figure 12-5 illustrates SIP rules for a peer-to-peer topology.Figure 12-5 SIP Peer-to-Peer Topology
To configure SIP rules for a peer-to-peer topology:
1. Define a rule that allows IP phones in Net_A to call Net_B and, and vice versa:
or
The SIP over TCP services are TCP:sip-tcp, TCP:sip_tls_with_server_certificate, TCP:sip_tls_authentication and TCP:sip_tls_not_inspected. For additional information on SIP services, refer to “SIP-Specific services” on page 161.
2. Define Hide NAT (or Static NAT) for the phones in the internal network by editing the Network object for Net_A.
• In the NAT tab of the Network object, select Add Automatic Address Translation Rules and then the Translation method (Hide or Static).
• If Hide NAT is defined, add a node object with the Hide NAT IP address object to the Destination of the SIP over TCP rule.
Source Destination Service Action Comment
Net_ANet_B
Net_BNet_A
UDP:sip Accept SIP over UDPBidirectional calls
Source Destination Service Action Comment
Net_ANet_B
Net_BNet_A
SIP over TCP service Accept SIP over TCPBidirectional calls
164
3. Install the security Policy.
SIP Rules for a Proxy in an External NetworkFigure 12-6 illustrates a SIP topology with a Proxy in an external network. Figure 12-6 SIP Proxy in External Network
To enable bidirectional calls between SIP phones in both an internal and an external network (Net_A and Net_B), and to define NAT for the internal phones:
1. Define the Network objects (nodes or networks) for the IP Phones that are managed by the SIP Proxy or Registrar, and that are permitted to make calls, and whose calls are inspected by the VPN-1 gateway. In Figure 12-6, these are Net_A.
2. Define the Network object for the SIP Proxy or Registrar (SIP_Proxy).
If the Proxy and Registrar are on one machine with a single IP address, define just one object. If they have different IP addresses, define an object for each IP address.
3. Define the following Security rule:
or
Source Destination Service Action Comment
SIP_Proxy Net_A
Net_A SIP_Proxy
UDP:sip Accept SIP over UDPBidirectional calls
Chapter 12 SIP Rule Base Configuration 165
The SIP over TCP services are TCP:sip-tcp, TCP:sip_tls_with_server_certificate, TCP:sip_tls_authentication and TCP:sip_tls_not_inspected. For additional information on SIP services, refer to “SIP-Specific services” on page 161.
4. Define Hide NAT (or Static NAT) for the phones in the internal network by editing the Network object for Net_A.
• In the NAT tab, select Add Automatic Address Translation Rules, and then the Translation method (Hide or Static).
• If Hide NAT is defined, add a node object with the Hide NAT IP address object to the Destination of the SIP over TCP rule.
5. Install the security Policy.
Source Destination Service Action Comment
SIP_Proxy Net_A
Net_A SIP_Proxy
SIP over TCP service
Accept SIP over TCPBidirectional calls
166
SIP Rules for a Proxy-to-Proxy TopologyFigure 12-2 illustrates a Proxy-to-Proxy topology with Net_A and Net_B on opposite sides of the VPN-1 gateway. Figure 12-7 SIP Topology: Proxy-to-Proxy
To enable bidirectional calls between phones in both the internal and the external networks (Net_A and Net_B) and to define NAT for the internal phones and the internal Proxy (GW_A):
1. Define the Network objects (nodes or networks) for the phones that are permitted to make calls and whose calls are inspected by the VPN-1 gateway. In Figure 12-2, these are Net_A.
2. Define the Network object for the Proxy objects (Proxy_A and Proxy_B).
3. Define the following Security rule:
or
The SIP over TCP services are TCP:sip-tcp, TCP:sip_tls_with_server_certificate, TCP:sip_tls_authentication and TCP:sip_tls_not_inspected. For additional information on SIP services, refer to “SIP-Specific services” on page 161.
Source Destination Service Action Comment
Proxy_AProxy_B
Proxy_BProxy_A
UDP:sip Accept SIP over UDPBidirectional calls
Source Destination Service Action Comment
Proxy_AProxy_B
Proxy_BProxy_A
SIP over TCP service Accept SIP over TCPBidirectional calls
Chapter 12 SIP Rule Base Configuration 167
4. Define Hide NAT (or Static NAT) for the phones in the internal network by editing the Network object for the internal network (Net_A).
• In the NAT tab, select Add Automatic Address Translation Rules and then the Translation method (Hide or Static).
• If Hide NAT is defined, add a node object with the Hide NAT IP address object to the Destination of the SIP over TCP rule.
5. Define Static NAT for the Proxy in the internal network by repeating step 4 for the Proxy object (Proxy_A).
6. Install the security Policy.
168
SIP Rules for a Proxy in DMZ TopologyFigure 12-8 illustrates a SIP-based VoIP topology where a Proxy is installed in the DMZ. Figure 12-8 SIP Topology: Proxy in the DMZ
To enable bidirectional calls between phones both in an internal and an external network (Net_A and Net_B) and to define NAT for the internal phones and the Proxy in the DMZ (Proxy_DMZ):
1. Define the Network objects (nodes or networks) for the phones that are permitted to make calls and whose calls are inspected by the VPN-1 gateway. In Figure 12-8, these are Net_A and Net_B.
2. Define the Network object for the Proxy (Proxy_DMZ).
3. Define the following Security rule:
or
The SIP over TCP services are TCP:sip-tcp, TCP:sip_tls_with_server_certificate, TCP:sip_tls_authentication and TCP:sip_tls_not_inspected. For additional information on SIP services, refer to “SIP-Specific services” on page 161.
Source Destination Service Action Comment
Proxy_DMZNet_ANet_B
Net_ANet_BProxy_DMZ
UDP:sip Accept SIP over UDPBidirectional calls
Source Destination Service Action Comment
Proxy_DMZNet_ANet_B
Net_ANet_BProxy_DMZ
SIP over TCPservice
Accept SIP over TCPBidirectional calls
Chapter 12 SIP Rule Base Configuration 169
4. Define Hide NAT (or Static NAT) for the phones in the internal network:
a. To edit the Network object for Net_A, In the NAT tab, select Add Automatic Address Translation Rules and then the Translation method (Hide or Static).
b. To configure Hide NAT, select the Hide behind IP address option and type the IP address of the Hiding address of the phones in the internal network.
• If Hide NAT is defined, add a node object with the Hide NAT IP address object to the Destination of the SIP over TCP rule defined in step 3.
5. Define Static NAT for the Proxy in the DMZ as follows:
• Create a node object for the Static address of the Proxy (for example, Proxy_DMZ_NATed)
• Add Proxy_DMZ_NATed to the Destination of the Rule Base rule, for both sip and sip-tcp services.
• Add the following manual NAT rules (Table 12-2):
6. As for all manual NAT rules, configure proxy-arps. To associate the translated IP address with the MAC address of the Check Point gateway interface that is on the same network as the translated addresses, use the local.arp file in Unix or the arp command in Windows.
The fw ctl arp command displays the proxy ARP table on Check Point gateways that run on Unix. On Windows, use the arp -a command.
On Unix-based (including SecurePlatform) Check Point gateways:
a. Create a file $FWDIR/conf/local.arp
b. Add the relevant entry, such as:
192.168.6.145 00:0D:60:83:B3:74
Where 192.168.6.145 is the static address, and 00:0D:60:83:B3:74 is the address of the external interface.
Table 12-2
Original Translated Comment
Source Destination Service Source Destination Service
Proxy_DMZ Net_B *Any Proxy_DMZ_NATed: Static
= = Outgoingcalls
Net_B Proxy_DMZ_NATed *Any = Proxy_DMZ:Static
= Incomingcalls
170
c. From the SmartDashboard main menu, select Policy > Global Properties, and in the NAT page, select Merge Manual Proxy ARP Configuration.
d. Install the security Policy.
e. Ensure that the fw ctl arp command displays the new entry in the proxy ARP table.
Using SIP on a Non-Default PortBy default, SIP uses the UDP port 5060. However, SIP phones and SIP Proxies can be configured to use a different port. VPN-1 can enforce SIP security on any SIP port. To configure a new port, a new UDP service must be defined in SmartDashboard. You can use both the newly defined service and the predefined service (sip) in the same Security Rule Base rule.
To configure a new SIP service:
1. From the SmartDashboard main menu, select Manage > Services > New… > UDP.
2. In the UDP Service Properties window, name the new service and specify the new SIP port.
3. Click Advanced….
4. In the Advanced UDP Service Properties window, select the Protocol Type:
SIP_UDP and click OK.
5. Define a rule in the Security Rule Base that uses the new service.
Chapter 12 SIP Rule Base Configuration 171
Enabling Dynamic Opening of Ports for SIP Signaling
The sip_dynamic_ports service service enables the dynamic opening of ports in the gateway for SIP signaling. By default, only port 5060 is defined for SIP over UDP and TCP services, and port 5061 for the SIP over TLS services (see “SIP-Specific services” on page 161). In addition, SIP services can be defined for non-default ports (see "“Using SIP on a Non-Default Port” on page 170).
The sip_dynamic_ports service is used in order to enable the dynamic opening of ports which are not defined by any of the SIP services (default and non-default). It is necessary to open such ports in order to allow the establishment of SIP connections to ports which are not known in advance. The Check Point gateway opens and closes ports based on the inspection of SIP signaling messages.
Add the sip_dynamic_ports service to the rule in the following cases:
1. The phones register themselves at a SIP server by associating their phone number with a port other than 5060 or 5061. For example, a registration request of phone number 2001 with IP address 172.16.8.3 port 3000. An example of such a Contact header field is as follows:
Contact: <sip:[email protected]:3000;rinstance=64d25786c64e7975>;expires=3600
2. The "rport" parameter is used in the Via header field (see RFC 3581 - An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing). For example:
Via: SIP/2.0/TCP 172.16.8.3:5060;branch=z9hG4bK-1193792f8039818cd82e34eec4112ae8;rport=4039
The sip_dynamic_ports service is not needed for Far End NAT Traversal rules.
Only use the sip_dynamic_ports service in a rule together with at least one other SIP service (over TCP or UDP).
Example Rule With the sip_dynamic_ports ServiceThe following is an example of a SIP UDP rule.
SIP_phone is the IP address of the SIP phone.
SIP_server is the IP address of the SIP server:
172
Source Destination Service Action
SIP_phoneSIP_server
SIP_serverSIP_phone
udp:sipsip_dynamic_port
Accept
173
Chapter 13SIP Advanced Configuration
This chapter covers some advanced aspects of SIP configuration and troubleshooting.
In This Chapter
Gateway Clustering Support for SIP page 174
Multicast Support for SIP page 175
Configuring SIP-T Support page 176
Troubleshooting SIP page 176
174
Gateway Clustering Support for SIP
Synchronizing SIP Connections SIP calls can be made across a ClusterXL gateway cluster or a third-party gateway cluster. For both ClusterXL and third party gateway clusters, and whenever SIP connections must be synchronized across gateways, ensure that the Synchronize connections on Cluster option is configured for all services used in rules that secure SIP connections through the gateway cluster.
To ensure SIP connections through a gateway cluster are synchronized:
1. In the SmartDashboard objects tree, select the Services tab
2. Edit the SIP service that is used in rules that secure SIP connections through the gateway cluster.
3. In the Service Properties window of the SIP service, click Advanced.
4. Select Synchronize connections on Cluster.
5. Click OK.
Note - The Synchronize connections on Cluster option is enabled by default
Chapter 13 SIP Advanced Configuration 175
6. Install the policy.
Load Sharing of SIP ConnectionsSIP calls can be made across a ClusterXL gateway cluster in either High Availability or Load Sharing modes. In Load Sharing Mode, the Sticky Decision Function must be enabled (for additional information, refer to the ClusterXL NGX R65 Administration Guide at
http://supportcontent.checkpoint.com/documentation_download?ID=7240.
The following are not supported in a Load Sharing deployment:
• SmartDefense Rate Limiting protections, Located in Application Intelligence > VoIP > Protections for R65.2.100 > Rate Limiting
• VoIP tab, QoS Per Gateway options (Call Admission Control and Traffic Policy).
Multicast Support for SIPThe fw_sip_allow_mcast (true, false) property allows or drops multicast RTP traffic. The default value of this property is false. This is a per module property. To change the value, run the fw ctl set int fw_sip_allow_mcast command.
176
Configuring SIP-T SupportTo configure support for RFC 3372 Session Initiation Protocol for Telephones (SIP-T):
1. Add the $FWDIR/lib/user.def line on the SmartCenter server:
where first_ip and second_ip are the IP addresses between which (bi-directional) SIP-T are allowed. For example, to allow SIP-T between 192.1.1.1 and 192.1.1.2, and between 192.1.1.1 and 192.1.1.3 add the following line:
If the file does not exist, create it.
2. Save the file.
3. Install the security policy.
Troubleshooting SIPTo view a list of all of the online IP phones that VPN-1 has recorded as having registered:
Run the fw tab -t sip_registration -f command. The output of this command is a list in the username; IP address format.
To obtain information on current SIP calls:
Run the fw tab -t sip_state -f command. The following output is displayed:
• Control connection (source, destination).
• RTP connection (endpoint IP addresses).
• Call state (established, ended, registration).
• Media type (audio, video, audio/video, application).
• Number of reinvites (number of participants in a conference call).
sipt_hosts = { < first_ip, second_ip> , < first_ip, second_ip> , .... ....,< first_ip, second_ip> } ;
sipt_hosts = { < 192.1.1.1, 192.1.1.2> , < 192.1.1.1, 192.1.1.3> } ;
177
Chapter 14Inspection of TLS-Secured SIP Traffic
This chapter explains how to configure support for TLS-secured SIP.
In This Chapter
Introduction to TLS page 178
The Check Point SIP TLS Solution page 179
Workflow for Configuration of TLS-secured SIP page 181
Configuring TLS-Secured SIP page 183
178
Introduction to TLSTransport Layer Security (TLS) is a cryptographic protocol. TLS is used as one of the standard methods for protecting SIP application signaling. It provides authentication and/or encryption of the SIP signaling associated with VoIP. TLS is essentially the same as Secure Sockets Layer (SSL). TLS is an application layer protocol that runs over TCP, and below SIP or other application protocols, such as HTTP.
After the TCP handshake is completed, the client and server execute the TLS handshake. During the TLS handshake, the client and server agree on parameters used to establish the connection’s security, including those used for encryption and authentication of the application protocol (such as SIP). During the TLS handshake, the client authenticates the server’s identity, by requiring the server to present a valid digital certificate from a trusted certificate authority (CA). This is called server authentication. Optionally, client authentication may take place, in which the server authenticates the client using a digital certificate.
Chapter 14 Inspection of TLS-Secured SIP Traffic 179
The Check Point SIP TLS Solution When TLS-secured SIP traffic passes through a Check Point gateway, the gateway is able to securely inspect and modify the traffic, thereby providing full security and connectivity. The gateway handles SIP TLS traffic as follows:
• Inspection of TLS-Encrypted SIP Traffic— In many VoIP deployments that secure SIP with TLS, malicious endpoints may nevertheless be able to establish a TLS connections with the SIP server. The reason is that either the server does not require the endpoint to present a trusted client certificate, or because the attacker can easily obtain such a certificate. In those cases, DoS attacks against the SIP server could be carried out over the TLS connection. By having the ability to inspect SIP traffic secured by TLS, even if the traffic is encrypted, the gateway can protect the SIP server from such attacks.
• Dynamic Pinholing of TLS-Encrypted SIP Traffic — By inspecting encrypted SIP signaling, the gateway can dynamically open pinholes for data (e.g., voice, video), eliminating the need to statically open a large range of high UDP ports in the firewall.
• NAT for TLS-Encrypted SIP Traffic — Most SIP signaling messages contain IP addresses and ports of VoIP entities. Therefore, when NAT is applied, SIP messages are usually modified by the NAT device. By being able to securely modify SIP messages which are secured by TLS, the gateway can apply NAT to SIP messages over TLS.
A Typical TLS-Secured ConnectionFigure 14-1 illustrates a SIP connection (connection 1) between a SIP-based phone and a SIP proxy that is both encrypted and authenticated by means of TLS . During the TLS handshake, which passes through the gateway, the gateway presents itself to the endpoint phones as a proxy. It does this by presenting a server certificate to the phone on behalf of the proxy, with the name of the proxy in the certificate.
Two TLS-secured connections are therefore established: one between the endpoint phone and the gateway (connection 1), and the other between the gateway and the proxy (connection 2). When the gateway receives a SIP message on one connection, it decrypts and authenticates it with that connection’s keys. The gateway inspects the decrypted message, and opens dynamic ports as necessary. Finally, the gateway authenticates and encrypts the message with the other connection's keys, and sends the message.
180
Figure 14-1 A SIP Connection that is Authenticated and Encrypted using TLS
In some environments, the proxy is configured to require a client certificate from the phones. The purpose of the client certificate is to allow the proxy to verify with whom it is communicating.
In that case, the Check Point gateway must maintain the trust between the phones and the proxy. It does this by requiring the phones to present a valid certificate that was issued by a trusted CA. The gateway then presents to the proxy a client certificate on behalf of the phones.
Chapter 14 Inspection of TLS-Secured SIP Traffic 181
Workflow for Configuration of TLS-secured SIP
The general workflow for configuring support for TLS-secured SIP is as follows:
1. Create objects in SmartDashboard for the SIP proxy and the endpoint phones.
2. Choose the appropriate service for the security rule from the following options:
• sip_tls_with_server_certificate
• sip_tls_authentication
• sip_tls_not_inspected
3. If sip_tls_authentication is the appropriate service, then complete the configuration by setting up the security rule.
4. If sip_tls_with_server_certificate, is the appropriate service, and the private key and certificate of the SIP proxy are available, then:
a. Install on the Check Point gateway the private key and certificate of the SIP proxy, by adding a file containing both to the SIP proxy object. Alternatively, if the endpoints trust a local CA, use the local CA to create a private key and certificate with the same name as the proxy’s certificate, and then install it on the gateway.
b. If the SIP proxy is configured to require a client certificate from the phones, install the client certificate on the Check Point gateway, to be used for connections to the SIP Proxy. To do that, add the client certificate and private key to the SIP proxy object.
c. If the certificate used by the SIP proxy is different from the one installed on the Check Point gateway, or if the gateway is configured to verify client certificates, then the gateway has to trust the external certificate authorities issuing the certificates. To do that, define the CA as an External Trusted CA for VoIP.
d. Configure the security rule, with the sip_tls_with_server_certificate service.
5. If a certificate — which the endpoints are willing to accept as belonging to the proxy — and its corresponding private key are not available, then the only way to allow TLS-secured SIP signaling is via an insecure workaround; by configuring a rule that opens all high UDP ports for the entities sending data, and another rule that uses the sip_tls_not_inspected service to open TCP port 5061 for the entities sending signaling.
182
For detailed instructions on how to configure support for SIP TLS, see “Configuring TLS-Secured SIP” on page 183.
Chapter 14 Inspection of TLS-Secured SIP Traffic 183
Configuring TLS-Secured SIPThe procedure for configuring SIP TLS depends on your VoIP environment.
In This Section
Choosing the TLS-Related ServiceChoose the appropriate TLS-related service to use in the Security Rule Base rule: sip_tls_with_server_certificate or sip_tls_authentication:
Now you are ready to configure the Security Rule Base rules.
• If the appropriate TLS service is sip_tls_authentication, continue with “Configuring the Rule for sip_tls_authentication” on page 184
Choosing the TLS-Related Service page 183
Configuring the Rule for sip_tls_authentication page 184
Configuration Using the sip_tls_with_server_certificate Service page 185
Legacy Solution for SIP TLS Support page 199
Table 14-1 TLS-Related SIP Services
For TLS connections that are Use the TLS Service
• Encrypted
• Not encrypted, but are authenticated, and are changed by the gateway (via NAT or the SmartDefense SIP Header Spoofing protection)
TCP:sip_tls_with_server_certificate
• Not encrypted, but are authenticated, and are not changed by the gateway (no NAT, and the SmartDefense SIP Header Spoofing protection does not apply)
TCP:sip_tls_authentication
Note - Do not use both TLS-related services in the same rule.
184
• If the appropriate TLS service is sip_tls_with_server_certificate, continue with “Configuration Using the sip_tls_with_server_certificate Service” on page 185
• If the VoIP environment is not known, continue with “Legacy Solution for SIP TLS Support” on page 199.
Configuring the Rule for sip_tls_authenticationIf the appropriate TLS service is sip_tls_authentication, define the Security rule as follows:
1. Define Network objects in SmartDashboard for the SIP phones.
2. Define a Network object in SmartDashboard for the SIP proxy.
3. Configure the following rule: :
4. Follow the instructions for configuring SIP over TCP rules in chapter 12, “SIP Rule Base Configuration” on page 157.
This completes the configuration of SIP TLS support for TLS connections that require the sip_tls_authentication service.
Source Destination Service
• SIP Proxy
• SIP Phones
• SIP Phones
• SIP Proxy
sip_tls_authentication
Chapter 14 Inspection of TLS-Secured SIP Traffic 185
Configuration Using the sip_tls_with_server_certificate Service
This part of the procedure for configuring SIP TLS support applies if sip_tls_with_server_certificate is the appropriate service for the SmartDashboard security rule.
Proceed as follows:
1. Define Network objects in SmartDashboard for the SIP phones.
2. Create a SIP Server object in the SmartDashboard VoIP tab, and define it as a SIP proxy. See “Defining VoIP Servers” on page 36.
3. Choose one of the following scenarios, that matches your VoIP environment, depending on whether you have access to the private key and certificate of the proxy, or whether you can configure the phones to trust a local CA, or both.
• “Scenario A: Proxy is Internal, Phones are External” on page 185
• “Scenario B: Proxy is External, Phones are Internal” on page 188
• “Scenario C: Proxy and Phones are Internal” on page 193
• “Scenario D: Proxy and Phones are External” on page 194
Scenario A: Proxy is Internal, Phones are External In this scenario, the proxy is internal (under the control of the administrator) and the phones are external (not under the control of the administrator).
Note - A VoIP license is required for TLS encrypted inspection using the service sip_tls_with_server_certificate, in addition to the Check Point gateway license. See “Licensing Requirements” on page 29.
Note - Internal means the administrator controls the device(s). External means the administrator does not control the device(s). These terms do not refer to the physical location of the device(s) or to the anti-spoofing configurations on the Check Point gateway Interfaces.
186
Figure 14-2 Proxy is Internal, Phones are External
This procedure for configuring SIP TLS support applies if the administrator has access to the server certificate of the proxy as well as the private key.
If the private key of the server certificate of the proxy is not available (as is the case with Cisco Call Manager, for example), continue with “Legacy Solution for SIP TLS Support” on page 199.
To maintain the trust chain between the phones and the proxy, the gateway must present to the phones the server certificate of the proxy. A PKCS#12 (.p12) file containing the proxy's server certificate and private key must therefore be added to the SIP server object.
Installing the Server Certificate on the Gateway
To install the server certificate on the gateway, obtain a password-encrypted PKCS#12 file containing the proxy's private key and certificate, and add it to the SIP server object:
Chapter 14 Inspection of TLS-Secured SIP Traffic 187
1. In SmartDashboard, open the SIP Server object of the SIP proxy, and select the TLS page.
2. Select Use this certificate to inspect encrypted SIP over TLS traffic...
3. In the Server Certificate section, click Import.
4. Select the file containing the private key and certificate of the SIP Proxy.
5. Enter the password for decrypting the .p12 file.
6. Click OK twice to close the SIP Server object.
7. Install the policy.
Completing the SIP TLS Configuration for Scenario A
1. Continue with the following procedures, if appropriate for your environment:
• “Installing the Client Certificate on the Gateway” on page 194
• “Configuring External Trusted CAs” on page 197
2. Complete the configuration by configuring the Security Rule Base. See “Configuring the Rule for sip_tls_with_server_certificate” on page 198
188
Scenario B: Proxy is External, Phones are InternalIn this scenario, the proxy is external (not under the control of the administrator) and the phones are internal (under the control of the administrator). The administrator therefore does not have the private key of the proxy, but does have the public key certificate of the proxy.
Figure 14-3 Proxy is External, Phones are Internal
This procedure for configuring SIP TLS support applies if the phones can be configured to trust a local CA .
If the phones cannot be configured to trust a local CA (as is the case with Cisco 7970 IP phones, for example), continue with “Legacy Solution for SIP TLS Support” on page 199.
To maintain the trust chain between the phones and the proxy, create a certificate with the same name as the proxy’s certificate, and to which you have the private key. Have a local CA trusted by the phones sign this certificate. The gateway presents this certificate to the SIP phones.
To add a certificate with the name of the proxy to the SIP server object:
1. Locate the name of the proxy’s server certificate. The name of the certificate is the value of the CN of the Subject field. If you view the certificate on a Windows machine, the Subject of the certificate is one of the fields that appears in the Details tab of the certificate.
2. Create a a password-protected PKCS#12 file containing a private key and a certificate whose certificate name is the same as the certificate name of the proxy. There are two options:
• Creating a Certificate Issued By An External Trusted CA
• Creating a Certificate Issued by the Check Point Internal CA
3. Install the Server Certificate (generated by the local CA or by the ICA) on the Gateway:
Chapter 14 Inspection of TLS-Secured SIP Traffic 189
a. In SmartDashboard, open the SIP Server object of the SIP proxy, and select the TLS page.
b. Select Use this certificate to inspect encrypted SIP over TLS traffic...
c. In the Server Certificate section, click Import.
d. Select the .p12 file containing the private key and certificate of the SIP Proxy.
e. Enter the password for decrypting the .p12 file.
f. Click OK twice to close the SIP Server object
g. Install the Policy.
4. Continue with the following procedures, if appropriate for your environment:
• “Installing the Client Certificate on the Gateway” on page 194
• “Configuring External Trusted CAs” on page 197
5. Complete the configuration by configuring the Security Rule Base. See “Configuring the Rule for sip_tls_with_server_certificate” on page 198
190
Creating a Certificate Issued By An External Trusted CA
The recommended, and simplest way of creating a certificate with the same name as the proxy is to use an external CA. In this case, the phones must be configured to trust the external CA that issues the certificate.
The general procedure for creating a certificate issued by an external trusted CA is usually as follows. For the details, consult your CA:
1. Create a public key-pair.
2. Create a Certificate Signing Request (CSR) containing the public key created in step 1. The certificate name must be the same as that of the proxy.
3. Send the CSR to the external CA and receive the signed certificate.
4. Create a password-protected PKCS#12 file containing the signed certificate and the private key generated in step 1.
Continue with step 3 on page 188.
Creating a Certificate Issued by the Check Point Internal CA
An alternative way of creating a certificate with the same name as the proxy is to use the Check Point Internal Certificate Authority (ICA) on the SmartCenter server. In this case, the phones must be configured to trust the ICA. The ICA Management Tool is used to configure the ICA.
Before using the ICA Management Tool:
• Use SmartDashboard to generate and save an administrator (or user) certificate. For details, see the Configuring Administrators section of the SmartCenter NGX R65 Administration Guide at
http://supportcontent.checkpoint.com/documentation_download?ID=7256
• Save the certificate to the certificate store of the browser machine from which the ICA management tool will be accessed.
To issue a PKCS#12 certificate on the ICA:
1. Enable the ICA Management tool. From the command line on the SmartCenter server, run the command:
cpca_client set_mgmt_tool on -a "administrator DN"
Note - For more information about the ICA Management Tool, run the cpca_client set_mgmt_tool command (with no other parameters), or see the Internal Certificate Authority chapter in the SmartCenter NGX R65 Administration Guide at
http://supportcontent.checkpoint.com/documentation_download?ID=7256
Chapter 14 Inspection of TLS-Secured SIP Traffic 191
administrator DN is the full DN of the administrator (or user) certificate defined in SmartDashboard. For a SmartDashboard administrator, the DN is shown in the Admin Certificates tab.
2. Access the Internal CA by connecting to the the ICA Management Tool via a browser. Connect to https://<mgmnt_ip>:18265 where mgmt_ip is the IP of the management machine.
3. Click Create Certificates.
4. Click the Form link.
A form for entering the certificate details opens.
192
Figure 14-4 The Create Certificates page of the Internal CA Management Tool
5. In the Name field, type the name of the proxy’s server certificate. Be exact. Note that the Name is the CN of the certificate.
6. Fill any other desired fields. They are not mandatory.
7. Click Done.
The form closes.
8. Back in the Create Certificates page, the Full DN of the certificate appears in the Enter User Name field.
Chapter 14 Inspection of TLS-Secured SIP Traffic 193
9. Select Generate.
10. Choose a Password for the PKCS#12 certificate and click Go.
11. Save the .p12 certificate file.
12. In order for the phones to trust the Internal CA, the CA certificate must be installed on the phones. From the browser, connect to http://<mgmnt_ip>:18264 where mgmt_ip is the IP of the management machine.
The Certificate Services page opens.
Figure 14-5 The Certificate Services page of the ICA Management Tool
13. Click Download CA Certificate.
14. Save the .cer certificate file of the Internal CA.
15. Install the CA certificate on all the phones.
Continue with Continue with step 3 on page 188.
Scenario C: Proxy and Phones are InternalIn this scenario, the proxy and the phones are internal (under the control of the administrator).
194
Figure 14-6 Proxy and Phones are Internal
To configure a certificate to allow the gateway to inspect SIP over TLS traffic, use either the procedure for Scenario A: Proxy is Internal, Phones are External or the procedure for Scenario B: Proxy is External, Phones are Internal.
The Scenario A: Proxy is Internal, Phones are External procedure is simpler to configure, and is therefore preferred.
Scenario D: Proxy and Phones are ExternalIn this scenario, the proxy as well as the phones are external (not under the control of the administrator), so that the private key of the proxy and of the phones are not available.
Figure 14-7 Proxy and Phones are External
Continue with “Legacy Solution for SIP TLS Support” on page 199.
Installing the Client Certificate on the GatewayIn some environments, the proxy is configured to require a client certificate from the phones. The purpose of the client certificate is to allow the proxy to verify with whom it is communicating.
Chapter 14 Inspection of TLS-Secured SIP Traffic 195
Figure 14-8 shows a connection between the gateway and the proxy server (connection 2), in which the gateway presents a client certificate to the proxy on behalf of the phones.
Figure 14-8 A SIP Connection that is Authenticated and Encrypted using TLS
In environments in which the SIP proxy is configured to require a client certificate from the phones, the gateway must be able to present a valid certificate, from a CA trusted by the proxy, on behalf of the phones.
The client certificate to be used by the gateway is configured on the SIP proxy object in SmartDashboard as follows:
1. In the SmartDashboard VoIP tab, go to the VoIP Entities and Topology > VoIP Servers page.
2. Select the SIP server object and click Edit.
3. Select the TLS page.
4. In the Client Certificate section, click Advanced…
The Advanced window opens.
196
5. In the Advanced window, configure the client certificate that the gateway will present to the proxy on behalf of the phones. This applies to TLS connections between gateway and SIP server (connection 2 in Figure 14-8). The options are:
• Use SIP Server’s Certificate — the client certificate used by the gateway will be the same as the uploaded server certificate (used in connection 1 in Figure 14-8).
• Use Imported Certificate — the client certificate used by the gateway will be the certificate imported in this window.
6. To import a client certificate, select Use imported certificate and click Import…
The Import Certificate window opens.
7. In the Import Certificate window:
• Select the .p12 file containing the client certificate and corresponding private key. The file is password protected.
• Type the password for decrypting the file.
8. Click OK twice.
9. Install the Policy.
Maintaining Trust Between the Phones and the SIP Proxy
Because the Check Point gateway presents a certificate on behalf of the phone, the SIP proxy is unable to verify the phone's certificate. In order to maintain trust between the phones and the SIP proxy, the gateway must be configured to verify the phone's certificate.
Before configuring the gateway to verify the phone's certificate:
In SmartDashboard, define the CA that issues the phone's certificate as an External Trusted CA for VoIP (see “Configuring External Trusted CAs” on page 197) or as a Trusted CA (see the "Trusting a CA – Step-By-Step" section in the Virtual Private Networks NGX R65 Administration Guide at
http://supportcontent.checkpoint.com/documentation_download?ID=7261
Chapter 14 Inspection of TLS-Secured SIP Traffic 197
Configure the gateway to verify the phone's certificate as follows:
1. In the SmartDashboard VoIP tab, go to the VoIP Entities and Topology > VoIP Servers page.
2. Select the SIP server object and click Edit.
3. Select the TLS page.
4. Select the Verify client certificate when endpoint connects to the server option.
This applies to connection 1 Figure 14-8. The gateway verifies that the certificate of the endpoint phones is valid, and that it was issued by a trusted CA.
5. Click OK.
6. Install the Policy.
Configuring External Trusted CAsAn organization may choose to trust a particular CA (Certificate Authority) to issue certificates only for a particular purpose.
In SmartDashboard, it is possible to define an External Trusted CA that is trusted by the Check Point gateway only for VoIP. In other words, the CA is only trusted for connections that match Security Rule Base rules with VoIP services.
If the server certificate that is uploaded to the gateway is different from the one used by the proxy, it is highly recommended to define the CA of the proxy’s server certificate as an External Trusted CA for VoIP only. Similarly, if the phones present a client certificate to the proxy, the CA of the client certificate of the phones should be defined as an External Trusted CA for VoIP.
To define a CA that is trusted only for VoIP connections:
1. In the SmartDashboard VoIP tab, select Advanced > External Trusted CAs.
2. Click New…
198
The Certificate Authority Properties window opens.
3. In the General tab, click VoIP.
4. Import the public key certificate file of the CA.
a. Click import…
b. Browse to the location of the file, select it, and click Open.
5. Click OK twice.
6. Install the Policy.
Configuring the Rule for sip_tls_with_server_certificate After completing the configuration of the SIP proxy object, the SIP TLS Security rule can be configured, with the sip_tls_with_server_certificate service.
Note - For External Trusted CAs, the settings in the Advanced tab of the Certificate Authority Properties window are not supported.
Note - Supported certificate file formats are: *.crt, *.cer, *.p7b, *.b64, *.mme
Chapter 14 Inspection of TLS-Secured SIP Traffic 199
1. Configure the SIP TLS security rule. A typical rule is as follows: :
2. Follow the instructions for configuring SIP over TCP rules in chapter 12, “SIP Rule Base Configuration” on page 157.
3. Install the Policy.
Legacy Solution for SIP TLS SupportIf none of the other options for configuring SIP TLS support are available, it is possible to configure a rule to allow TLS connections by opening all high UDP ports for the entities sending data, and another rule a rule that uses the service sip_tls_not_inspected to open TCP port 5061 for the entities sending signaling.
To configure support for SIP TLS in environments where a secure solution is not available:
1. Define Network objects in SmartDashboard for the SIP phones.
2. Define a Network object for the SIP proxy.
3. Configure a rule that opens all high UDP ports and TCP port 5061. A typical rule that assumes the phones send data directly to each other, and not through the proxy, is as follows:
4. Install the Policy.
Source Destination Service
• SIP Proxy
• SIP Phones
• SIP Phones
• SIP Proxy
sip_tls_with_server_certificate
Warning - 1. Opening all high UDP ports is very insecure. 2. Neither the SIP signaling nor the data is inspected.
Source Destination Service
• SIP Proxy
• SIP Phones
• SIP Phones
• SIP Proxy
TCP: sip_tls_not_inspected
• SIP Phones • SIP Phones UDP: udp-high-ports
200
201
Chapter 15MGCP-Based VoIP
In This Chapter
Introduction to MGCP page 202
Supported MGCP RFCs and Standards page 203
MGCP SmartDefense Protections page 204
MGCP Application Policy page 210
MGCP Supported Deployments and NAT Support page 214
Rule Base Configuration for MGCP page 217
202
Introduction to MGCPMGCP is a protocol for controlling telephony gateways from external call control devices called Call Agents (also known as Media Gateway Controllers).
MGCP is a master/slave protocol, which means it assumes limited intelligence at the edge (endpoints) and intelligence at the core (Call Agent). In this way it differs from SIP and H.323, which are peer-to-peer protocols.
The MGCP assumes that the call control devices, or Call Agents, will synchronize with each other to send commands to devices under their control called Media Gateways. Call Agents can also connect directly to IP Phones. The Media Gateways or IP Phones are expected to execute commands sent by the Call Agents. Figure 15-1 shows the MGCP elements and a simplified call control process.Figure 15-1 MGCP Elements
Media Gateways and MGCP IP phones normally support features such as conference calls, 3-way brokering and supervisor inspection.
Chapter 15 MGCP-Based VoIP 203
Supported MGCP RFCs and StandardsSmartDefense for MGCP enforces strict compliance with the following RFCs and standards:
• RFC-2705.
• RFC-3435 (version 1.0)
• ITU TGCP specification J.171.
204
MGCP SmartDefense ProtectionsNGX R65.2.100 includes a number of SmartDefense protections for MGCP. This chapter describes the MGCP protections for gateways of that version.
SmartDefense protects against attacks by identifying attack signatures and identifying packets with protocol anomalies. Strict compliance is enforced with RFC-2705, RFC-3435 (version 1.0), and ITU TGCP specification J.171. In addition, all SmartDefense network security capabilities are supported, such as inspection of fragmented packets, anti spoofing, and protection against Denial of Service attacks.
SmartDefense protections can be configured per profile. For each profile, the protection can be made inactive or active, and can be set to monitor-only mode. Logging options for each protection can also be configured per profile.
The descriptions in this chapter appear in SmartDashboard, at the bottom of every SmartDefense protection. The information is included in this guide for reference purposes.
In This Section
Max length of header value
Description
RFC 3435 section 3.2 states:” The command header is composed of:
• A command line, identifying the requested action or verb, the transaction identifier, the endpoint towards which the action is requested, and the MGCP protocol version,
• A set of zero or more parameter lines, composed of a parameter name followed by a parameter value.
Max length of header value page 204
Block unrecoverable MGCP inspection errors page 205
MGCP Protocol Anomaly Protections page 205
Chapter 15 MGCP-Based VoIP 205
Threat Description
If the values of the mandatory commands are longer than the allowed maximum length, various threats are possible: the message may be incorrectly parsed, the parser may crash, the message may be incorrectly handled, and ultimately, there may be Denial of Service.
SmartDefense Protection
This protection verifies that the length of each of the MGCP command header values (MGCP command, TransactionID, and EndpointID) is shorter than or equal to the length configured here. MGCP messages containing longer header values are blocked.
Block unrecoverable MGCP inspection errors
Description
As well as performing packet inspections for the MGCP SmartDefense protections, SmartDefense performs other, additional inspections. Use this option to either block or allow packets that fail those additional inspections. By default, those packets are dropped.
MGCP Protocol Anomaly Protections
In This Section
Introduction to MGCP Protocol Anomaly Protections page 206
Maximum allowed CallID length page 206
Maximum allowed Domain name length page 207
Maximum allowed EndpointID length page 207
Maximum allowed Connection Mode length page 208
Maximum allowed TransactionID length page 208
Block MGCP messages with binary characters page 209
206
Introduction to MGCP Protocol Anomaly Protections
Description
A protocol anomaly is a field name or value in the protocol header that is RFC compliant but deviates from normal use. For example, a header value whose length is hundreds of characters, while the norm is a few characters in length, is a protocol anomaly.
By default, the maximum values of the MGCP protocol anomaly protections are RFC compliant.
Threat Description
Malformed packets with protocol anomalies can lead to buffer overflow conditions and parser errors.
Protocol anomalies in MGCP messages make MGCP applications vulnerable to Denial of Service and other attacks that repeatedly send huge quantities of bogus data, eventually overwhelming the servers.
For example, many buffer-overflow attacks repeatedly send a very large header to the VoIP phone. Buffer overflow conditions can also allow arbitrary code execution.
SmartDefense Protection
Stateful and Stateless protocol validation is performed on MGCP headers. MGCP messages with header values that do not match normal usage are blocked.
Maximum allowed CallID length
Description
RFC 3435 section 2.3.5 states: "CallId is a parameter that identifies the call (or session) to which this connection belongs. This parameter SHOULD, at a minimum, be unique within the collection of Call Agents that control the same gateways. Connections that belong to the same call SHOULD share the same callId. The call-id has little semantic meaning in the protocol; however it can be used to identify calls for reporting and accounting purposes. It does not affect the handling of connections by the gateway."
Chapter 15 MGCP-Based VoIP 207
SmartDefense Protection
This protection verifies that the length of the CallId parameter is shorter than or equal to the length configured here. MGCP messages containing longer CallIds are blocked.
Maximum allowed Domain name length
Description
RFC 3435 section 2.1.2 states: "Endpoint identifiers have two components that both are case-insensitive:
• the domain name of the gateway that is managing the endpoint
• a local name within that gateway
Endpoint names are of the form:
local-endpoint-name@domain-name
where domain-name is an absolute domain-name as defined in RFC 1034 and includes a host portion, thus an example domain-name could be:
mygateway.whatever.net"
SmartDefense Protection
This protection verifies that the length of the domain-name parameter that appears in any MGCP header field is shorter than or equal to the length configured here. MGCP messages containing longer domain-names are blocked.
Maximum allowed EndpointID length
Description
RFC 3435 section 2.1.2 states: "Endpoint identifiers have two components that both are case-insensitive:
• the domain name of the gateway that is managing the endpoint
• a local name within that gateway
Endpoint names are of the form:
local-endpoint-name@domain-name"
Section 2.3.5 states: "EndpointId is the identifier for the connection endpoint in the gateway where CreateConnection executes".
208
The length of the EndpointId parameter is made up of the length of the domain name plus the length of the local name.
SmartDefense Protection:
This protection verifies that the length of the EndpointId parameter that appears in any MGCP header field is shorter than or equal to the length configured here. MGCP messages containing longer EndpointIds are blocked.
Maximum allowed Connection Mode length
Description
The Connection Mode indicates the mode of operation of the connection. RFC 3435 section 3.2.2.6 lists 10 basic modes, for example mode "sendonly" (the gateway should only send packets) and mode "recvonly" (the gateway should only receive packets). The set of connection modes can be extended.
SmartDefense Protection
This protection verifies that the length of the ConnectionMode parameter that appears in the MGCP header field is shorter than or equal to the length configured here. MGCP messages containing longer ConnectionMode values are blocked.
Maximum allowed TransactionID length
Description
RFC 3435 section 3.5.2 states: “Transaction identifiers are integer numbers in the range from 1 to 999,999,999 (both included). Call-agents may decide to use a specific number space for each of the gateways that they manage, or to use the same number space for all gateways that belong to some arbitrary group.” TransactionIDs are unique per transaction originated by the logical Call Agent. The transactions are composed of a command and a mandatory response.
SmartDefense Protection
This protection verifies that the length of the TransactionID parameter that appears in the MGCP header is shorter than or equal to the length configured here. MGCP messages containing longer TransactionIDs are blocked.
Chapter 15 MGCP-Based VoIP 209
Block MGCP messages with binary characters
Threat Description
If there are illegal characters in an MGCP message header, various threats are possible: the message may be incorrectly parsed, the parser may crash, the message may be incorrectly handled, and ultimately, there may be Denial of Service.
SmartDefense Protection
This protection validates that the MGCP message header does not contain illegal binary characters. Illegal binary characters are: NULL (0), DEL (127), Control characters except TAB (9), LF (10) and CR (13), and Extended ASCII Codes (129 - 255).
MGCP messages containing illegal characters are blocked.
210
MGCP Application PolicyAn organization may decide to block certain VoIP services because they consume more bandwidth than the IP infrastructure can support, or because they do not comply with the organization’s policy.
Application Policy options limit the VoIP services available to users.
Application Policy options are not intended to protect against attacks, which is the role of SmartDefense.
The MGCP application policy options are available in the SmartDashboard VoIP tab, under Application Policy > MGCP.
In This Section
Commands Unsupported by MGCP ServerThis option blocks MGCP request commands that the MGCP server is not allowed to process. Supported commands are configured per server.
Blocking MGCP CommandsThere are nine predefined MGCP commands. They are defined in RFC 3435 section 2.3. Commands can be sent by the MGCP server to the endpoint or from the endpoint to the MGCP server. It is possible to block or allow any command as dictated by the security needs.
If an MGCP server is flooded with requests that use commands the server does not support, the server may be overloaded, which could affect customers service levels.
This option makes it possible to block commands that the MGCP server does not support or that the administrator does not want the server to handle.
Commands Unsupported by MGCP Server page 210
Fax page 213
Chapter 15 MGCP-Based VoIP 211
Blocking User Defined MGCP CommandsRFC 3435 section 3.2.1.1 states "New verbs may be defined in further versions of the protocol. It may be necessary, for experimentation purposes, to use new verbs before they are sanctioned in a published version of this protocol. Experimental verbs MUST be identified by a four letter code starting with the letter X, such as for example XPER."
It is possible to define new commands, and configure this option to allow those commands.
Unknown commands
Unknown commands are commands that do not appear in the Blocked commands or Allowed commands lists. By default, all unknown commands are blocked.
SDP Headers of MGCP Commands
MGCP packets contain an optional SDP header. This header contains information such as the destination port number, the destination IP address, and the media type (audio or video). The predefined MGCP commands, MDCX and CRCX, have an SDP header.
Table 15-1 The Nine MGCP Commands
MGCP Commands
AuditConnection (AUCX)
AuditEndpoint (AUEP)
CreateConnection (CRCX)
DeleteConnection (DLCX)
EndpointConfiguration (EPCF)
ModifyConnection (MDCX)
NotificationRequest (RQNT)
Notify (NTFY)
RestartInProgress (RSIP)
212
When defining an MGCP command, it is possible to specify whether or not the command contains an SDP header. This VoIP security option parses the header and checks that it has the correct syntax. If the destination address and port in the header are allowed, the media connection is allowed through the Gateway.
Block Unsupported MGCP Commands Configuration DetailsTo block commands that are unsupported by the MGCP server:
1. In the SmartDashboard VoIP tab, VoIP Entities and Topology > VoIP Servers page, define the MGCP server(s).
2. In the VoIP tab, select Application Policy > MGCP > Commands Unsupported by SIP Server.
3. In the Server specific configuration section, configure each server. Select a server and click Edit. The Supported Commands page of the MGCP server object opens.
4. In this page you can:
• Block or allow commands.
• Manage user defined commands
• Define and block Unknown commands
5. In the Gateway Install-on section, choose the VoIP gateways on which to apply the option. Monitor-only can be applied to selected gateways. Either
• Apply to all gateways, or
• Do not Install on these gateways, and define an Exception list.
Chapter 15 MGCP-Based VoIP 213
Figure 15-2 Supported Commands Page of the MGCP Server Object
6. Click Manage user defined commands… to define commands, other than the nine predefined commands, that are to be prevented from reaching the server. For each command, specify whether or not it contains an SDP header.
7. Optionally, Block unknown commands.
FaxWhen an MGCP call is made, a number of connections are set up, one of which is intended for fax. The Fax option blocks all applications that use MGCP to transmit fax. The default is not to block.
214
MGCP Supported Deployments and NAT Support
VPN-1 supports the MGCP deployments listed in Table 15-2. It is possible to configure NAT (either Hide or Static) for the phones in the internal network.
NAT is not supported on IP addresses behind an external Check Point gateway interface
The SmartDashboard configuration depends on the topology, as described in “Rule Base Configuration for MGCP” on page 217 which includes diagrams showing the most widely used deployment topologies.
Table 15-2 Supported MGCP Topologies
No NAT NAT for Internal Phones -
Hide/Static NAT
Call Agent in external network (Figure 15-3)
Yes Yes
Call Agent in DMZ (Figure 15-4)
Yes No
Call Agent to Call Agent (Figure 15-5)
Yes No
Chapter 15 MGCP-Based VoIP 215
Figure 15-3 Call Agent in external network
The IP Phones use the services of a Call Agent on the external side of the gateway. This topology enables using the services of a Call Agent that is maintained by another organization. It is possible to configure Hide NAT (or Static NAT or no NAT) for the phones on the internal side of the gateway.
See “MGCP Rules for a Call Agent in the External Network” on page 217
Figure 15-4 Call Agent in the DMZ The same Call Agent controls both endpoint domains. This topology makes it possible to provide Call Agent services to other organizations.
See “MGCP Rules for Call Agent in DMZ” on page 218
Figure 15-5 Call Agent to Call Agent Each Call Agent controls a separate endpoint domain.
Where there is one or more Call Agents, the signaling passes through each Call Agent. Once the call has been set up, the media can pass endpoint to endpoint.
See “MGCP Rules for Call Agent to Call Agent” on page 219
216
Additional Conditions for Using NAT in MGCP Networks
MGCP can be used with Network Address Translation (NAT), subject to the following conditions:
• Hide NAT can be used for all types of calls (incoming, outgoing, internal and external). For security reasons, when using Hide NAT for incoming calls, the Destination of the VoIP call in the appropriate rule in the Security Rule Base cannot be Any.
• Manual NAT rules are only supported for Call Agent in DMZ deployments. Use Automatic NAT whenever possible.
• Where both endpoints are on the trusted side of the VPN-1 Power/UTM gateway, calls cannot be made from the same source to two endpoints, where one endpoint is NATed (either Static or Hide) and the other is not.
• Bidirectional NAT of VoIP calls is not supported.
Chapter 15 MGCP-Based VoIP 217
Rule Base Configuration for MGCPThis section explains how to configure Security Rule Base Rules so that the gateway allows MGCP calls.
• It is recommended to configure anti-spoofing on the Check Point gateway interfaces.
• To allow MGCP conversations you need only create rules to allow the MGCP control signals through the Check Point gateway. There is no need to define a rule for the media that specifies which ports to open and which endpoints will talk. The gateway derives this information from the signaling. Given a particular VoIP signaling rule, the gateway automatically opens ports for the endpoint-to-endpoint RTP/RTCP media stream.
MGCP-Specific servicesThe following predefined MGCP services are available:
MGCP Rules for a Call Agent in the External Network
An MGCP topology with a Call Agent in the external network is shown in Figure 15-6. The following procedure explains how to allow bidirectional calls between the MGCP phones in the internal network (Net_A) and phones in an external network (Net_B), and how to define NAT for the internal phones.
Table 15-3 Predefined MGCP-Specific Services
Service Purpose
UDP:mgcp_CA Used for MGCP over UDP, for connections using the well known port is the Call-Agent port (2727).
UDP:mgcp_MG Used for MGCP over UDP, and whose well known port is the Media Gateway port (2427).
Other:MGCP_dynamic_ports Allows a MGCP connection to be opened on a dynamic port and not on the MGCP well-known port.
218
Figure 15-6 MGCP Call Agent in External Network
To define an MGCP rule for a call agent in the external network:
1. Define the network objects (Nodes or Networks) for the IP Phones that are managed by the MGCP Call Agent and are allowed to make calls, and whose calls are tracked by the VPN-1 Gateway.
For the example in Figure 15-6, these are Net_A and Net_B.
2. Define the network object for the Call Agent (MGCP_Call_Agent).
3. Define the following Security Rule:
For additional information on MGCP services, refer to “MGCP-Specific services” on page 217.
4. To define Hide NAT (or Static NAT) for the phones in the internal network, edit the network object for Net_A. In the NAT tab, check Add Automatic Address Translation Rules, and select the Translation method (Hide or Static)
5. Install the security policy.
MGCP Rules for Call Agent in DMZFigure 15-7 illustrates an MGCP-based VoIP topology where a Call Agent is installed in the DMZ.
Source Destination Service Action
MGCP_Call_Agent Net_A
Net_A MGCP_Call_Agent
mgcp_CA or mgcp_MG or mgcp_dynamic_ports
Accept
Chapter 15 MGCP-Based VoIP 219
Figure 15-7 MGCP Topology: Proxy in the DMZ
To enable bidirectional calls between phones both in an internal and an external network (Net_A and Net_B):
1. Define the Network objects (nodes or networks) for the phones that are permitted to make calls and whose calls are tracked by the VPN-1 gateway. In Figure 15-7, these are Net_A and Net_B.
2. Define the Network object for the Call Agent (Call_Agent).
3. Define the following Security rule:
For additional information on MGCP services, refer to “MGCP-Specific services” on page 217.
4. Install the security Policy.
MGCP Rules for Call Agent to Call AgentFigure 15-8 illustrates a Call Agent-to-Call Agent topology with the Call Agents on opposite sides of the VPN-1 gateway.
Source Destination Service Action Comment
Net_ANet_BCall_Agent
Net_ANet_BCall_Agent
mgcp_CAor mgcp-MG
Accept Bidirectional calls.
220
Figure 15-8 MGCP Topology: Call Agent-to-Call Agent
To enable bidirectional calls between phones in both the internal and the external networks:
1. Define the Network object for the Proxy objects (Call_Agent_Int and Call_Agent_Ext).
2. Define the following Security rule:
For additional information on MGCP services, refer to “MGCP-Specific services” on page 217.
3. Install the security Policy.
Source Destination Service Action Comment
Call_Agent_IntCall_Agent_Ext
Call_Agent_ExtCall_Agent_Int
mgcp_CAor mgcp-MG
Accept Bidirectional calls.
221
Chapter 16H.323-Based VoIP
In This Chapter
Introduction to H.323 page 222
Supported H.323 Protocols and Standards page 223
H.323 SmartDefense Protections page 224
H.323 Application Policy page 230
Supported H.323 Deployments and NAT Support page 232
H.323 Security Rule Base Configuration page 235
222
Introduction to H.323H.323 is an ITU (International Telecommunication Union) standard that specifies the components, protocols, and procedures that provide multimedia communication services, real-time audio and video, and data communications over packet networks, including Internet protocol (IP) based networks.
NGX R65.2.100 supports the following H.323 architectural elements:
• IP phones, which are IP devices that handle both signaling (that is, the H.323 commands themselves) and media. They connect to an H.323 gatekeeper.
IP Phones are defined in SmartDashboard, usually as a network of IP Phones. There is normally no need to define Network objects for individual IP Phones.
• Conventional telephones that connect to an H.323 gateway. These are not IP devices and there is no need to define them in SmartDashboard.
• A Gatekeeper manages a collection of H.323 devices, such as phones. It converts phone numbers to IP addresses. A Gatekeeper usually provides gateway services as well.
• A Gateway provides interoperability between different networks. It translates between the telephony protocol and IP.
The Gatekeeper and Gateway are media admission control devices, and can be defined as H.323 Servers to perform media admission control. See “Media Admission Control” on page 58.
Chapter 16 H.323-Based VoIP 223
Supported H.323 Protocols and Standards
Signaling and Media Protocols for H.323Media in H.323 uses the RTP/RTCP and/or T.120 protocols.
Signaling is handled by the following H.323 protocols:
• RAS manages registration, admission, and status. RAS uses a fixed port: UDP 1719.
• Q.931 manages call setup and termination. Q.931 uses a fixed port: TCP 1720.
• H.245 negotiates channel usage and capabilities. H.245 uses a dynamically assigned port.
As an H.323 call is processed by a Gatekeeper, these protocols are used in sequence and then the media passes. To end a call, the signaling protocols are used in reverse order.
The protocol sequence for a Gateway is the same, except that an endpoint does not use RAS when it connects to the Gateway.
VPN-1 also supports H.245 tunneling and Fast Connect, a H.323 capability that ensures that audio is available as soon as the phone is answered. This feature is active by default, and is always available.
Supported H.323 StandardsThe following H.323 ITU standards are supported:
• H.323 Versions 2, 3, and 4.
• H.225 Versions 2, 3, and 4.
• H.245 Versions 3, 5, and 7.
224
H.323 SmartDefense ProtectionsIn This Section
Introduction to SmartDefense for H.323 SmartDefense protects against attacks by identifying attacks, identifying packets with protocol anomalies, and ensuring standards compliance.
NGX R65.2.100 includes a number of SmartDefense protections for H.323. This section describes the H.323 protection for gateways of that version.
SmartDefense protections can be configured per profile. For each profile, the protection can be made inactive or active, and can be set to monitor-only mode. Logging options for each protection can also be configured per profile.
The descriptions in this chapter appear in SmartDashboard, at the bottom of every SmartDefense protection. The information is included in this guide for reference purposes.
The SmartDefense H.323 Branch
SmartDefense Protection
SmartDefense supports H.323 version 4 and below, which includes H.225 version 4 and H.245 version 7. It performs the following application layer checks:
• Strict enforcement of the protocol, including the order and direction of H.323 packets.
• H.323 messages length restrictions.
• Stateful checks on RAS messages.
• Protection against Denial of Service attacks.
Introduction to SmartDefense for H.323 page 224
The SmartDefense H.323 Branch page 224
Block sessions that do not start with Setup message page 225
H.323 Protocol Anomaly Protections page 225
Chapter 16 H.323-Based VoIP 225
Block sessions that do not start with Setup message
Description
SETUP is a Q.931 based H.225.0 call signaling message. This message is sent by a calling H.323 entity to indicate its desire to set up a connection to the called entity.
SmartDefense Protection
It is not possible to perform packet inspection on the messages following the call setup without seeing the setup details. This protection ensures that all H.225 Call Signaling (Q.931) connections that do not start with a SETUP message are dropped.
H.323 Protocol Anomaly Protections
Description
A protocol anomaly is a field value or a message in the protocol that is standards compliant, but deviates from normal use. For example, a field value with 100 bytes where a few bytes is normal is a protocol anomaly, as is a message with 1400 bytes where 800 bytes is normal.
A message that is sent out of protocol state (that is, when not allowed by the protocol) is also a protocol anomaly.
A protocol anomaly in a VoIP packet is a good indication that the VoIP network is being attacked.
Threat Description
The size of various H.323 messages and the size of elements of an H.323 packet are not limited by the standards. This leaves H.323 applications vulnerable to Denial of Service and other attacks that repeatedly send huge quantities of bogus data, eventually overwhelming the servers. For example, many buffer-overflow attacks repeatedly send a very large header to the VoIP phone. Buffer overflow conditions can also allow for arbitrary code execution.
226
SmartDefense Protection
Good security practice limits the sizes of various H.323 messages or message elements, verifies the order of the protocol messages and verifies the existence of important information fields.
In This Section
Max allowed Extension length
Description
The address of the endpoint can have various formats. One of the formats is dialed digits. Dialled digits can be 0-9 and "#" and "*". The dialedDigits field is used in RAS messages or in Q.931 based H.225.0 call signaling messages to identify the destination or the source of the call. An example of the dialedDigits field is + 41447556000.
SmartDefense Protection
This protection ensures that the length of the dialedDigits field is shorter than or equal to the maximum length specified in this protection. By default, a maximum of 24 dialled digits is allowed.
Maximum allowed RAS message length
Description
RAS (Registration, Admission and Status) is the protocol for communication between H.323 endpoints and gatekeepers. RAS is used to perform registration, admission control, bandwidth changes, status, and disengage procedures between endpoints and gatekeepers. A RAS channel is used to exchange RAS messages.
Max allowed Extension length page 226
Maximum allowed RAS message length page 226
Maximum allowed Q.931 message length page 227
Maximum allowed H.245 message length page 227
Verify message Content page 228
Verify H.323 State Machine page 228
Block Messages with illegal ASN.1 encoding page 228
Chapter 16 H.323-Based VoIP 227
This signaling channel is opened between an endpoint and a gatekeeper prior to the establishment of any other channels. Typically, RAS communication is carried out via UDP through port 1719 (unicast) and port 1718 (multicast).
SmartDefense Protection
This protection ensures that the length of the RAS message (including the UDP header) is shorter than or equal to the maximum length specified in this protection. By default, the maximum allowed message length is 1500 bytes.
Maximum allowed Q.931 message length
Description
Q.931 based H.225.0 call signaling messages manage call setup and termination between two H.323 entities. Call signaling involves the exchange of H.225 messages over a reliable call signaling channel. Q.931 uses a fixed port: TCP 1720.
SmartDefense Protection
This protection ensures that the length of the Q.931 message (the Q.931 header and the H.225 message) is shorter than or equal to the maximum length specified in this protection. By default, the maximum allowed message length is 3500 bytes.
Maximum allowed H.245 message length
Description
H.245 is one of the protocols in the H.323 suite of protocols. H.245 messages negotiate channel usage and capabilities including:
• Terminal capability exchange.
• Master/Slave determinations.
• Logical channel signaling.
• Conference control.
H.245 messages are carried via a special channel called the H.245 Control Channel and use a dynamically assigned port. The H.245 channel is often a separate TCP connection, but it may be tunneled inside the H.225.0 Call Signaling Channel.
228
SmartDefense Protection
This protection ensures that the length of the H.245 message is shorter than or equal to the maximum length specified in this protection. The H.245 message length is verified whether it is a separate H.245 message or a tunneled message inside the H.225.0 Call Signaling Channel. By default, the maximum allowed message length is 1500 bytes.
Verify message Content
Description
The H.323 ITU-T Recommendation specifies the required information fields in each message, including H.225.0 and H.245 messages.
SmartDefense Protection
This protection verifies the existence of mandatory H.323 information fields in messages. For example it verifies the existence of rasAddress information field in the RAS Gatekeeper Request (GRQ) message and the existence of the callSignalAddress information field in the RAS Registration Request (RRQ) message. If these fields do not exist, the packet is dropped.
Verify H.323 State Machine
SmartDefense Protection
This protection verifies that certain RAS messages are sent when allowed by the protocol. For example, this protection verifies that the Unregistration Request (URQ) or the light RRQ registration keep alive are sent after the endpoint is already registered. In addition this protection verifies that RAS confirmation messages such as UCF, RCF, ACF, LCF are received only after their request was previously received.
Block Messages with illegal ASN.1 encoding
Description
Abstract Syntax Notation One (ASN.1) is a formal language for abstractly describing messages to be exchanged among an extensive range of applications, including H.323. RAS messages, H.225.0 call signaling messages and H.245 messages are in ASN.1 syntax
Chapter 16 H.323-Based VoIP 229
Prior to inspection, the gateway must decode the ASN.1 encoded H.323 packet. If the gateway is unable to decode the H.323 packet, the packet cannot be inspected.
SmartDefense Protection
This protection blocks H.323 messages (RAS, Q.931 based H.225.0 call signaling, and H.245 messages) with illegal ASN.1 encoding. If the packet cannot be decoded (because of illegal ASN.1 encoding or a mismatch of H.323 versions, for example), the packet is blocked. If this protection is inactive or in monitor-only mode, and the packet is illegally encoded, it passes as-is without inspection.
230
H.323 Application Policy
Introduction to H.323 Application PolicyAn organization may decide to block certain VoIP services because they consume more bandwidth than the IP infrastructure can support, or because they do not comply with the organization’s policy.
Application Policy options limit the VoIP services available to users.
Application Policy options are not intended to protect against attacks, which is the role of SmartDefense.
The H.323 application policy options are available in the SmartDashboard VoIP tab, under Application Policy > H.323.
Sessions that use H.245 Tunneling This option prevents the encapsulation of a H.245 message in any Q.931 message. H.245 tunneling conserves resources, synchronizes call signaling and control, and reduces call setup time. H.245 Tunneling should be allowed, if the VoIP equipment supports it.
T.120This option blocks dynamic opening of T.120 connections, for example in application-sharing file transfer, and chat, and application sharing in applications such as Microsoft NetMeeting. T.120 is not allowed by default.
If the policy is configured to block the dynamic opening of T.120 connections, the H.323 connection is not dropped. A log of the T.120 message is generated with the Action: ACCEPT (not with the Action: DROP). The log states that dynamic T.120 connections from H.323 messages will not be dynamically opened from H.323 messages.
H.323 connection from RAS messagesThis option controls the way the H323_ras service works. If the H323_ras service is allowed in the Rule Base, this setting controls whether control connections required by all H.323 connections will be dynamically opened by the firewall from RAS messages.
Chapter 16 H.323-Based VoIP 231
This setting applies only to connections that start with RAS (that are allowed and inspected by the H323_ras service). If H.323 connections opened from RAS messages are blocked, it is necessary to allow the H323 service in the Rule Base.
If the policy is configured to drop H.323 connections from RAS messages, a log of the RAS message is generated with the Action: ACCEPT (not with the Action: DROP). The log states that H.323 connections will not be dynamically opened from RAS messages.
232
Supported H.323 Deployments and NAT Support
Supported H.323 deployments are listed in Table 16-1. NAT (either Hide or Static) can be configured for the phones in the internal network, and (where applicable) for the Gatekeeper.
• NAT is not supported on IP addresses behind an external Check Point gateway interface
• Manual NAT rules are not supported (only Automatic NAT is supported), except the where the gatekeeper is in the DMZ
Note - When using Hide NAT for H.323, include the hiding IP address in the destination of the H.323 rule, in order to allow the initiation of a TCP handshake from the external network to the hiding IP.
Table 16-1 Supported H.323 Topologies
No NAT NAT for
Internal
Phones—
Hide/Static
NAT
NAT for Gatekeeper—
Static NAT
Endpoint to Endpoint (Figure 16-1 on page 233)
Yes Static NAT only
Not applicable
Gatekeeper/Gateway in External(Figure 16-2 on page 233)
Yes Yes Not applicable
Gatekeeper/Gateway to Gatekeeper/Gateway(Figure 16-3 on page 233)
Yes Yes Yes
Gatekeeper/Gateway in DMZ(Figure 16-4 on page 234)
Yes Yes Yes
Chapter 16 H.323-Based VoIP 233
Figure 16-1 Endpoint-to-Endpoint Communication The IP Phones communicate directly, without a Gatekeeper or an H.323 Gateway. Static NAT can be configured for the phones on the internal side of the VPN-1 gateway.
Figure 16-2 Gatekeeper or H.323 Gateway in External Network
The IP Phones use the services of a Gatekeeper or H.323 Gateway on the external side of the VPN-1 gateway. This topology enables using the services of a Gatekeeper or an H.323 Gateway that is maintained by another organization. It is possible to configure Hide NAT (or Static NAT or no NAT) for the phones on the internal side of the VPN-1 gateway.
Figure 16-3 H.323 Gatekeeper/Gateway to Gatekeeper/Gateway
Each Gatekeeper or H.323 Gateway controls a separate endpoint domain. Static NAT can be configured for the internal Gatekeeper. For the internal phones, Hide NAT (or Static NAT) can be configured.
234
Figure 16-4 Gatekeeper or H.323 Gateway in the DMZ
The same Gatekeeper or H.323 Gateway controls both endpoint domains. This topology makes it possible to provide Gatekeeper or H.323 Gateway services to other organizations. Static NAT (or no NAT) can be configured for the Gatekeeper or H.323 Gateway. Hide NAT (or Static or no NAT) can be configured for the phones on the internal side of the VPN-1 gateway.
Chapter 16 H.323-Based VoIP 235
H.323 Security Rule Base ConfigurationThis section explains how to configure Security Rule Base Rules so that the gateway allows H.323 calls.
In This Section
H.323 Specific ServicesThe following predefined H.323 services are available:
H.323 Specific Services page 235
General Guidelines for H.323 Security Rule Configuration page 236
H.323 Rule for an Endpoint-to-Endpoint Topology page 237
H.323 Rules for a Gatekeeper-to-Gatekeeper Topology page 238
H.323 Rules for a Gateway-to-Gateway Topology page 239
H.323 Rules for a Gatekeeper in the External Network page 240
H.323 Rules for a Gateway in the External Network page 241
H.323 Rules for a Gatekeeper in DMZ Topology page 243
H.323 Rules for a Gateway in DMZ Topology page 244
Table 16-2 Predefined H.323 services
Service Purpose
TCP:H323 Allows a Q.931 to be opened (and if needed, dynamically opens an H.245 port), and dynamically opens ports for RTP/RTCP or T.120.
236
General Guidelines for H.323 Security Rule Configuration
• It is recommended to configure anti-spoofing on the Check Point gateway interfaces.
• To allow H.323 traffic, you need only create rules to allow the H.323 control signaling through the Check point gateway. There is no need to define a rule for the media that specifies which ports to open and which endpoints will talk. The gateway derives this information from the signaling. Given a particular H.323 signaling rule (with RAS and/or H.323 services) the gateway automatically opens ports for the H.245 connections and RTP/RTCP media stream connections. However, dynamic ports will only be opened if the port is not used by another service. For example: If the Connect message sends port 80 for the H.245 it will not be opened. This prevents well-known ports from being used illegally.
UDP:H323_ras Allows RAS port to be opened, and then dynamically opens a Q.931 port (an an H.245 port if needed). Also dynamically opens and RTP/RTCP and T.120 ports.
UDP:H323_ras_only Allows only RAS. Cannot be used to make calls. If this service is used, no Application Intelligence checks (payload inspection or modification as NAT translation) are made. Do not use if you want to perform NAT on RAS messages. Do not use in the same rule as the H323_ras service.
TCP:H323_any Relevant only for version R65 and lower gateways:
Similar to the H323 service, but also allows the Destination in the rule to be ANY rather than a Network object. Only use H323_any if you do not know the VoIP topology, and are not enforcing media admission control (formerly known as Handover) using a VoIP domain. Do not use in the same rule as the H.323 service.
Table 16-2 Predefined H.323 services
Service Purpose
Note - In general, use the H.323 and H.323_ras services in H.323 Security Rule Base rules.
Chapter 16 H.323-Based VoIP 237
To allow H.323 traffic in the Security Rule Base, use regular Network objects. There is no need to define special Network objects.
H.323 Rule for an Endpoint-to-Endpoint TopologyAn endpoint-to-endpoint topology is shown in Figure 16-5, with Net_A and Net_B on opposite sides of the VPN-1 gateway. The following procedure explains how to allow bidirectional calls between the phones in the internal network (Net_A) and phones in an external network (Net_B), and how to define NAT for the internal phones. No incoming calls can be made when Hide NAT is configured for the internal phones.Figure 16-5 H.323 Topology: Direct Endpoint-to-Endpoint Communication
To define an H.323 rule for endpoint-to-endpoint topology:
1. Define the following rule:
2. To define Hide NAT (or Static NAT) for the phones in the internal network, edit the network object for the internal network (Net_A). In the NAT tab, check Add Automatic Address Translation Rules, and select the Translation method (Hide or Static).
3. Install the security policy.
Note - When using Hide NAT for H.323, include the hiding IP address in the destination of the H.323 rule, in order to allow the initiation of a TCP handshake from the external network to the hiding IP.
Table 16-3
Source Destination Service Action
Net_ANet_B
Net_BNet_A
H323 Accept
238
H.323 Rules for a Gatekeeper-to-Gatekeeper Topology
A Gatekeeper-to-Gatekeeper topology is shown in Figure 16-6, with Net_A and Net_B on opposite sides of the VPN-1 gateway. The following procedure explains how to allow bidirectional calls between the phones in the internal network (Net_A) and phones in an external network (Net_B), and how to define NAT for the internal phones and the internal Gatekeeper (GK_A). Figure 16-6 H.323 Topology: Gatekeeper-to-Gatekeeper
To define an H.323 rule for gatekeeper-to-gatekeeper topology:
1. Define the network objects (Nodes or Networks) for the phones which use the Gatekeeper for registration, and are allowed to make calls, and whose calls are tracked by the VPN-1 gateway.
In the example in Figure 16-6, these are Net_A and Net_B.
2. Define the Network object for the Gatekeeper objects (GK_A and GK_B)
3. Define the following Security Rule Base rule:
For an explanation of the H.323 services, refer to “H.323 Specific Services” on page 235.
4. To define Hide NAT (or Static NAT) for the phones in the internal network, edit the network object for the internal network (Net_A). In the NAT tab, select Add Automatic Address Translation Rules, and select the Translation method (Hide or Static).
Source Destination Service Action Comment
GK_AGK_B
GK_BGK_A
H323H323_ras
Accept Bidirectional calls.
Chapter 16 H.323-Based VoIP 239
5. To define Static NAT for the Gatekeeper/Gateway in the internal network, repeat step 4 for the Gatekeeper object (GK_A).
6. It is recommended to make the time-out of the H323_ras service equal to or greater than the Gatekeeper registration time-out. Configure the time-outs in the Advanced Properties window of the Service object.
7. Install the security policy.
H.323 Rules for a Gateway-to-Gateway TopologyA Gateway-to-Gateway topology is shown in Figure 16-7, with Net_A and Net_B on opposite sides of the VPN-1 gateway. The following procedure explains how to allow bidirectional calls between the phones in the internal network (Net_A), and phones in an external network (Net_B), and how to define NAT for the internal phones and the internal gateway (GW_A). Figure 16-7 H.323 Topology: Gateway-to-Gateway
To define an H.323 rule for gateway-to-gateway topology:
1. Define the network objects (Nodes or Networks) for the phones which are allowed to make calls, and whose calls are tracked by the VPN-1 Gateway.
For the example in Figure 16-7, these are Net_A and Net_B.
2. Define the network object for the gateway objects (GW_A and GW_B)
3. Define Security Rule Base rules:
Source Destination Service Action Comment
GW_AGW_B
GW_BGW_A
H323 Accept Bidirectional calls.
240
For an explanation of the H.323 services, refer to “H.323 Specific Services” on page 235.
4. To define Hide NAT (or Static NAT) for the phones in the internal network, edit the network object for the internal network (Net_A). In the NAT tab, select Add Automatic Address Translation Rules, and select the Translation method (Hide or Static)
5. To define Static NAT for the Gatekeeper/Gateway in the internal network, repeat step 4 for the Gatekeeper/Gateway object (GK_A).
6. Install the security policy.
H.323 Rules for a Gatekeeper in the External Network
An H.323 topology with a Gatekeeper in the Internet is shown in Figure 16-8, with Net_A and Net_B on opposite sides of the VPN-1 gateway. The following procedure explains how to allow bidirectional calls between the phones in the internal network (Net_A) and phones in an external network (Net_B), and how to define NAT for the internal phones. Figure 16-8 H.323 Topology: Gatekeeper In External Network
To define an H.323 rule for a gatekeeper in the external network:
1. Define the network objects (Nodes or Networks) for the phones which use the Gatekeeper for registration, and that are allowed to make calls, and whose calls are tracked by the VPN-1 Gateway.
For the example in Figure 16-8, these are Net_A and Net_B.
2. Define the network object for the Gatekeeper (GK_B)
Chapter 16 H.323-Based VoIP 241
3. Define Security Rule Base rules:
For an explanation of the H.323 services, refer to “H.323 Specific Services” on page 235.
4. To define Hide NAT (or Static NAT) for the phones in the internal network:
• Edit the network object for the internal network (Net_A). In the NAT tab, check Add Automatic Address Translation Rules, and select the Translation method (Hide or Static)
• If defining Hide NAT, add a Node object with the Hide NAT IP address to the Destination of the rule(s) defined in step 3.
5. It is recommended to make the time-out of the H323_ras service greater or equal to the Gatekeeper registration time-out. Configure the time-outs in the Advanced Properties window of the Service object.
6. Install the security policy.
H.323 Rules for a Gateway in the External NetworkAn H.323 topology with a Gateway in the Internet is shown in Figure 16-9, with Net_A and Net_B on opposite sides of the VPN-1 gateway. The following procedure explains how to allow bidirectional calls between the phones in the internal network (Net_A) and phones in an external network (Net_B), and how to define NAT for the internal phones.
Source Destination Service Action Comment
Net_ANet_BGK_B
GK_BNet_A
H323_rasH323
Accept Bidirectional calls.
242
Figure 16-9 H.323 Topology: Gateway In External Network
To define an H.323 rule for a gateway in the external network:
1. Define the network objects (Nodes or Networks) for the phones that are allowed to make calls, and whose calls are tracked by the VPN-1 gateway.
For the example in Figure 16-9, these are Net_A and Net_B.
2. Define the network object for the Gateway (GW_B)
3. Define the Security Rule Base rules, as follows:
For an explanation of the H.323 services, refer to “H.323 Specific Services” on page 235.
4. To define Hide NAT (or Static NAT) for the phones in the internal network:
• Edit the network object for the internal network (Net_A). In the NAT tab, select Add Automatic Address Translation Rules, and select the Translation method (Hide or Static).
• If using Hide NAT, you must add a Node object with the Hide NAT IP address to the Destination of the rule(s) defined in step 3.
5. Install the security policy.
Table 16-4
Source Destination Service Action Comment
Net_ANet_BGW_B
GW_BNet_A
H323 Accept Bidirectional calls.
Chapter 16 H.323-Based VoIP 243
H.323 Rules for a Gatekeeper in DMZ TopologyA H.323-based VoIP topology where a Gatekeeper is installed in the DMZ is shown in Figure 16-10. The following procedure explains how to allow bidirectional calls between the phones in the internal network (Net_A) and phones in an external network (Net_B), and how to define NAT for the internal phones and the Gatekeeper in the DMZ (GK_DMZ). Figure 16-10 H.323 Topology: Gatekeeper in the DMZ
To define an H.323 rule for a gatekeeper in the DMZ:
1. Define the network objects (Nodes or Networks) for the phones which use the Gatekeeper for registration, and that are allowed to make calls, and whose calls are tracked by the VPN-1 Gateway.
For the example in Figure 16-10, these are Net_A and Net_B.
2. Define the network object for the Gatekeeper (GK_DMZ).
3. Define the Security rule:
For an explanation of the H.323 services, refer to “H.323 Specific Services” on page 235.
4. To define Hide NAT (or Static NAT) for the phones in the internal network:
• Edit the network object for Net_A. In the NAT tab, select Add Automatic Address Translation Rules, and select the Translation method (Hide or Static).
Table 16-5
Source Destination Service Action Comment
GK_DMZNet_ANet_B
Net_ANet_BGK_DMZ
H323H323_ras
Accept Bidirectional calls.
244
• If using Hide NAT, you must select the Hide behind IP address option, and type the IP address of the Hiding address of the phones in the internal network.
• If using Hide NAT, you must add a Node object with the Hide NAT IP address to the Destination of the rule(s) defined in step 3.
5. To define Static NAT for the Gatekeeper in the DMZ, add manual NAT rules, as follows:
• Create a Node object for the Static address of the Gatekeeper (for example: GK_DMZ_NATed).
• Define the following manual NAT rules:
• As for all manual NAT rules, configure proxy-ARPs. In other words, you must associate the translated IP address with the MAC address of the Check Point Gateway interface that is on the same network as the translated addresses. Use the arp command in Unix or the local.arp file in Windows.
The command fw ctl arp displays the ARP proxy table on VPN-1 Gateways that run on Windows. On Unix, use the arp -a command.
6. It is recommended to make the time-out of the H.323_ras service greater than or equal to the Gatekeeper registration time-out. Configure the time-outs in the Advanced Properties window of the Service object.
7. Install the security policy.
H.323 Rules for a Gateway in DMZ TopologyA H.323-based VoIP topology where a Gateway is installed in the DMZ is shown in Figure 16-11. The following procedure explains how to allow bidirectional calls between the phones in the internal network (Net_A) and phones in an external network (Net_B), and how to define NAT for the internal phones and the Gateway in the DMZ (GW_DMZ).
Table 16-6
Original Translated Comment
Source Destination Service Source Destination Service
GK_DMZ Net_B *Any GK_DMZ:Static
= = Outgoing calls
Net_B GK_DMZ_NATed
*Any = GK_DMZ:Static
= Incoming calls
Chapter 16 H.323-Based VoIP 245
Figure 16-11 H.323 Topology: Gateway in the DMZ
To define an H.323 rule for a gateway in the DMZ:
1. Define the network objects (Nodes or Networks) for the phones that are allowed to make calls, and whose calls are tracked by the VPN-1 Gateway.
For the example in Figure 16-11, these are Net_A and Net_B.
2. Define the network object for the Gateway (GW_DMZ).
3. Define Security Rule Base rule:
For an explanation of the H.323 services, refer to “H.323 Specific Services” on page 235.
4. To define Hide NAT (or Static NAT) for the phones in the internal network:
• Edit the network object for Net_A. In the NAT tab, check Add Automatic Address Translation Rules, and select the Translation method (Hide or Static).
• If using Hide NAT, you must select the Hide behind IP address option, and type the IP address of the Hiding address of the phones in the internal network.
• If using Hide NAT, you must add a Node object with the Hide NAT IP address to the Destination of the rule(s) defined in step 3.
Source Destination Service Action Comment
GW_DMZNet_ANet_B
Net_ANet_BGW_DMZ
H323 Accept Bidirectional calls.
246
5. To define Static NAT for the Gateway in the DMZ, add manual NAT rules, as follows:
• Create a Node object for the Static address of the Gateway (for example: GW_DMZ_NATed).
• Define the following manual NAT rules:
• As for all manual NAT rules, configure proxy-arps. In other words, you must associate the translated IP address with the MAC address of the Check Point Gateway interface that is on the same network as the translated addresses. Use the arp command in Unix or the local.arp file in Windows.
The command fw ctl arp displays the ARP proxy table on VPN-1 Gateways that run on Windows. On Unix, use the arp -a command.
6. Install the security policy.
Table 16-7
Original Translated Comment
Source Destination Service Source Destination Service
GW_DMZ Net_B *Any GW_DMZ:Static
= = Outgoing calls
Net_B GW_DMZ_NATed *Any = GW_DMZ:Static
= Incoming calls
247
Chapter 17SCCP-Based VoIP
This chapter explains how to configure Security Rule Base rules so that the gateway allows SCCP calls.
In This Chapter
Introduction to SCCP Security and Connectivity page 248
Encrypted Protocol Support page 249
SCCP SmartDefense Protections page 250
SCCP Application Policy page 252
SCCP Supported Deployments page 253
Configuring SCCP Connectivity and Security page 255
248
Introduction to SCCP Security and Connectivity
SCCP (Skinny Client Control Protocol) controls telephony gateways from external call control devices called Call Agents (also known as Media Gateway Controllers).
Connectivity and network level security for SCCP-based VoIP communication is supported. All SCCP traffic is inspected and legitimate traffic is allowed to pass while attacks are blocked. Other firewall gateway capabilities are supported, such as anti- spoofing and protection against denial of service attacks. Fragmented packets are examined and secured using kernel-based streaming. However, NAT on SCCP devices is not supported.
The validity of SCCP message states is verified for all SCCP messages. For a number of key messages, the existence and correctness of the message parameters is verified.
Chapter 17 SCCP-Based VoIP 249
Encrypted Protocol SupportThe Check Point gateway enables secure connectivity for mixed secure and non-secure SCCP (Skinny) environments. In these environments, phones can communicate using either encrypted or cleartext signaling protocols. Encrypted protocols make it impossible for traditional firewalls to either identify the secure phones, or understand the encrypted signaling stream. For traditional firewalls, allowing connectivity therefore requires ports to be kept permanently open for all phones. The gateway guarantees secure connectivity by dynamically identifying secure phones, opening ports only for the required phones, and closing them at the end of the call.
Secure SCCP uses TCP port 2443.
To secure encrypted SCCP, use the predefined services in Security Rule Base rules.
• TCP:Secure_SCCP
• Other:high_udp_for_secure_SCCP
When an SCCP phone is turned on and it is identified as Secure SCCP, its IP address is added to the database of secure SCCP phones.
When RTP traffic arrives at the gateway, it is allowed only if the source or destination is in the database of secure SCCP phones.
250
SCCP SmartDefense ProtectionsA number of non-SCCP specific SmartDefense protections apply to SCCP:
• “Non SIP Entities Rate Limiting” on page 98,
• “Block multicast RTP connections” on page 118, and
• “Block multicast RTCP connections” on page 121.
The following SmartDefense protections are available under Application Intelligence > VoIP > Protections for R65.2.100 > SCCP (Skinny).
Max Allowed SCCP Message Length
SmartDefense Protection
This protection allows you to limit the length of SCCP message. By default, this protection is active with a limit of 1000 characters.
Verify SCCP State Machine
Threat Description
If the SCCP state machine is not enforced, an attacker could, for example, send a start media transmission message before the open receive channel message. This can make SCCP transactions vulnerable to call hijacking and man in the middle attacks.
SmartDefense Protection
This protection enforces the protocol state machine by verifying that each message is allowed to follow the previous one. For example, it ensures that media transmission starts only after an open receive channel message is received.
Verify SCCP Header Content
SmartDefense Protection
This protection confirms that the SCCP header is protocol-compliant. For a number of key messages, it verifies the existence and correctness of the message parameters. For example, the names of the header fields and their sizes are verified. Messages with an invalid headers are blocked.
Chapter 17 SCCP-Based VoIP 251
Block unrecoverable SCCP Inspection Errors
Description
In rare situation, SmartDefense cannot inspect a packet, due to reasons that are unconnected to any of the configurable SmartDefense SCCP protections or VoIP tab SCCP Application Policy options, for example, due to memory allocation issues.
Threat Description
If SmartDefense is unable to inspect a packet, and the packet is accepted, the internal network is unprotected against any possible threat that may be carried by that packet.
SmartDefense Protection
Configure SmartDefense to handle packets that cannot be inspected. Either block (for increased security) or allow such packets (for increased connectivity). By default, those packets are dropped.
252
SCCP Application PolicyAn organization may decide to block certain VoIP services because they consume more bandwidth than the IP infrastructure can support, or because they do not comply with the organization’s policy.
Application Policy options limit the VoIP services available to users.
Application Policy options are not intended to protect against attacks, which is the role of SmartDefense.
The SCCP application policy options are available in the SmartDashboard VoIP tab, under Application Policy > SCCP (Skinny).
The following SCCP Application Policy option is available:
Block Unknown SCCP MessagesThis option blocks messages that are not defined in the SCCP protocol.
Chapter 17 SCCP-Based VoIP 253
SCCP Supported DeploymentsThe SCCP deployments shown in Table 17-1 are supported. NAT on SCCP devices is not supported.
Table 17-1 Supported SCCP Topologies
No NAT NAT for Internal
Phones
- Hide/Static NAT
NAT for the
CallManager
- Static NAT
CallManager in internal network(Figure 17-1)
Yes No No
CallManager in the DMZ (Figure 17-3)
Yes No No
CallManager in external network (Figure 17-2)
Yes No Not applicable
254
Figure 17-1 CallManager in the Internal Network
The IP Phones use the services of a CallManager in an internal network
Figure 17-2 CallManager in an External Network
The IP Phones use the services of a CallManager on the external side of the gateway. This topology enables using the services of a CallManager that is maintained by another organization.
Figure 17-3 CallManager in the DMZ
The same CallManager controls both endpoint domains. This topology makes it possible to provide CallManager services to other organizations.
Chapter 17 SCCP-Based VoIP 255
Configuring SCCP Connectivity and SecurityThis section explains how to configure Security Rule Base Rules so that the gateway allows SCCP calls.
After the Rule Base is in place, all SCCP communication is fully secured by SmartDefense.
To tune SCCP security to the needs of the organization, default settings, and exceptions to the defaults should be configured for SmartDefense and for SCCP application hardening.
General Guidelines for SCCP Security Rule Configuration
SCCP has a centralized call-control architecture. The CallManager manages SCCP clients (VoIP endpoints), which can be IP Phones or Cisco ATA analog phone adapters. The CallManager controls all the features of the endpoints. It requests information, such as the station capabilities, and sends information, such as the button template and the date/time, to the VoIP endpoints.
The CallManagers are defined in SmartDashboard, usually as Node objects. The networks containing directly-managed IP Phones are also defined in SmartDashboard. There is normally no need to define network objects for individual phones. Cisco ATA devices that are managed by a CallManager must be defined in SmartDashboard, but the connected analog phones are not defined.
To allow SCCP conversations, you need only create rules to allow the SCCP control signals through the Check Point gateway. There is no need to define a rule for the media that specifies which ports to open and which endpoints will talk. The gateway derives this information from the signaling. Given a particular VoIP signaling rule, the gateway automatically opens ports for the endpoint-to-endpoint RTP/RTCP media stream.
256
SCCP-Specific servicesThe following predefined SCCP services are available:
Configuring the Rule Base for SCCPBefore configuring security rules for SCCP, ensure that
• Anti-spoofing is configured on the Check Point gateway interfaces, and
• The interface that faces the Internet is defined as External.
To configure the Security Rule Base for secure SCCP-based VoIP:
1. Define the Network objects (Nodes or Networks) for the SCCP endpoints (Cisco ATA devices or IP Phones) that are controlled by the CallManagers.
2. Define an SCCP server for the machine(s) on which the CallManager(s) is (are) installed. To define an SCCP server:
a. In the VoIP tab, select the VoIP Entities and Topology > VoIP servers page.
b. Click New…
c. Select SCCP (Skinny) server.
The General Properties page of the VoIP server opens.
d. In the General Properties page, choose a Name for the SCCP server
e. Define the SCCP Server host:
A. Click Manage…
B. Click New…
C. The Host Node window, General Properties page opens.
D. Choose a Name for the host, and specify its IP address.
E. In the Topology page, configure the host interfaces. To do so automatically, click Get… > Interfaces with Topology…
Service Purpose
TCP:SCCP Used for SCCP over TCPTCP:Secure_SCCP Used for encrypted SCCP over TCPOther:high_udp_for_secure_SCCP Used for media from Secure SCCP phones
Chapter 17 SCCP-Based VoIP 257
F. Click OK. This brings you back to the General Properties page of the SCCP server object.
3. Define the SCCP security rules. SCCP interoperates with other VoIP protocols. However, define separate rules for SCCP and the other VoIP protocols.
The following rule allows all phones in Net_A and Net_B to make calls to each other:
Net_A is the internal IP phone network
Net_A is the external IP phone network
The CallManager (Call_Manager) is can be in the internal, in the external network, or in a DMZ network connected to a separate interface of the VPN-1 gateway.
4. To secure encrypted SCCP over TCP connections, define another rule that is identical, other than the service. In the Service cell, include only the services TCP:Secure_SCCP and Other:high_udp_for_secure_SCCP.
5. Install the security policy.
Configuring SmartDefense and Application Policy for SCCP
To configure SmartDefense protections and application policy for SCCP:
1. Configure the SmartDefense protections under Application Intelligence > VoIP > Protections for R65.2.100 > SCCP (Skinny):
• Max Allowed SCCP Message Length
• Verify SCCP State Machine
• Verify SCCP Header Content
• Block unrecoverable SCCP Inspection Errors
2. in the VoIP tab, under Application Policy > SCCP (Skinny), configure Block Unknown SCCP Messages.
Source Destination Service Action Comment
Net_ANet_BCall_Manager
Net_ANet_BCall_Manager
SCCP Accept Incoming and Outgoing calls
258
259
Chapter 18Alcatel-Based VoIP
This chapter explains how to configure Security Rule Base rules so that the gateway allows Alcatel proprietary protocols.
In This Chapter
Alcatel Security and Connectivity page 260
Configuring Alcatel Connectivity and Security page 261
260
Alcatel Security and ConnectivityNGX R65.2.100 provides full connectivity and network level security for Alcatel-based VoIP communication.
All traffic is inspected, whether the Check Point gateway is placed between the Call server and Media Gateway or between the IP touch phones and the Call server. Legitimate traffic is allowed to pass while attacks are blocked.
Firewall capabilities such as anti-spoofing and protection against denial of service attacks are supported. However, NAT in Alcatel environments is not supported.
The validity of UA messages is verified including the existence and correctness of the message parameters.
SmartDefense protections apply to Alcatel protocols. Specifically, “Non SIP Entities Rate Limiting” on page 98.
Supported Alcatel ProtocolsThe supported protocols are:
• UA/NOE signaling, which handles signaling between the IP phone set and the Call Server.
• IPlink, which handles signaling between the media gateway (or voice mail system) and the Call Server.
Chapter 18 Alcatel-Based VoIP 261
Configuring Alcatel Connectivity and Security
To secure Alcatel communication across the gateway, a Security rule must be defined. After the rules are in place, all Alcatel communication is fully secured by NGX R65.2.100.
Predefined Alcatel ServicesThere are two predefined services for UA:
Configuring the Rule Base for AlcatelTo configure the Security Rule Base for UA-based VoIP:
1. Configure anti-spoofing on the Check Point gateway interfaces.
2. Define the network objects (Nodes or Networks) for the Alcatel endpoints (IP Phones and softphones) that are controlled by the Call servers.
3. Define the network object(s) for the machine(s) on which the Call server and media gateways are installed.
Service Port
UA_CS 32640
UA_PHONE 32512
262
4. Define the following rules. They are presented as two different rules for clarity, but they can be combined into a single rule.
Configuring Media Access control for Alcatel Call Servers
Media access control can be enforced on Alcatel servers.
There is no need to define special network objects. Pinholes for data connections (RTP/RTCP and other) are opened dynamically.
To configure Media Access Control:
1. In the VoIP Entities and Topologies > VoIP Servers page of the VoIP tab, define an Alcatel server.
2. In the Media Access Control page of the Alcatel server, define the specific endpoints for which the server is allowed to open a port for media connections.
For more information about Media Access Control, see “Configuring Media Admission Control” on page 60.
Source Destination Service Action Comment
• Media gateways
• Call servers
• Media gateways
• call servers
UA_PHONE UA_CS
Accept Rule for IPlink, which handles signaling between the media gateway (or voice mail system) and the Call Server.
• Endpoints
• call servers
• Endpoints
• call servers
UA_PHONE UA_CS
Accept Rule for UA NOE, for example, for traffic between IP touch phones and call servers
