VPN-1 Power/UTM. Administration guide Version NGX R

Transcription

1 VPN-1 Power/UTM Administration guide Version NGX R January 15, 2009

2

3 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 and FAR TRADEMARKS: Please refer to for a list of our trademarks For third party notices, see

4

5 Contents Preface Who Should Use This Guide Summary of Contents More Information Feedback Chapter 1 Chapter 2 Chapter 3 Overview Introduction to NGX R VoIP Security Deployment Scenarios Enterprise Deployment 1: Perimeter VoIP Gateway Enterprise Deployment 2: LAN segmentation Service Provider Deployment Supported VoIP Protocols Signaling and Media Protocols Supported VoIP Standards Supported SIP RFCs and Standards Supported MGCP RFCs and Standards Supported H.323 Protocols and Standards VoIP Logging Predefined VoIP Queries in SmartView Tracker Licensing Requirements Performing a Basic Configuration Workflow for Basic Configuration Setting Up a Basic Configuration Logging in to SmartDashboard Defining the VPN-1 Power/UTM Gateway Defining the Endpoints Defining the Security Rule Installing the Security Policy Testing the Configuration Tour of SmartDashboard for VoIP The VoIP Tab Enforcing Gateways SmartDefense VoIP Protections VoIP Application Policy Application Policy VoIP Entities and Topology QoS Advanced Application Policy for All VoIP Protocols Table of Contents 5

6 SmartDefense VoIP Protections Monitor-Only Mode Chapter 4 Chapter 5 Chapter 6 Chapter 7 VoIP Entities and Topology VoIP Servers The Purpose of VoIP Servers SIP Server Types Hide NAT for SIP traffic Hide NAT for MGCP traffic Configuring Short Extension Numbers for SIP VoIP Endpoints Media Admission Control Definition of Media Admission Control Establishing a VoIP Call: A Typical Flow The Importance of Media Admission Control Configuring Media Admission Control Media Admission Control Decision Flow Chart Entity Protection Summary Understanding the Entity Protection Summary Emergency Numbers How the Gateway Handles Emergency Calls Configuring Emergency Numbers Far End NAT Traversal The VoIP NAT Challenge The Far End NAT Traversal Solution NGX R NAT Deployments How Far End NAT Traversal works Pinhole Maintenance through NAT Devices NAT on the signaling and Media Payloads VoIP Server and Endpoint Compliance Ports and Addresses for Signaling and Media Signaling and Media Port Allocation Choosing the Media Port Range Configuring Far End NAT Traversal for SIP Defining the VoIP gateway Configuring Far End NAT Traversal for the Gateway Configuring the Client SIP Phones Security Rule Base Configuration Rate Limiting DoS Protection Introduction to Denial of Service Protection Rate limiting Protections Configuring Rate Limiting Protections Non SIP Entities Rate Limiting Non SIP Entities Rate Limiting Configuration Details

7 SIP Servers Rate Limiting SIP Servers Rate Limiting Configuration Details SIP Endpoints Rate Limiting SIP Endpoints Rate Limiting Configuration Details SIP Internal Networks Rate Limiting Configuration Details Chapter 8 Chapter 9 Chapter 10 Chapter 11 Quality of Service Introduction to QoS for NGX R Per Gateway QoS Call Admission Control Traffic Policy Gateway Specific Settings Per Server QoS SIP Block Calls from Unregistered Users DiffServ Marking of VoIP Data Packets DiffServ and Expedited Forwarding Configuration Details RTP/RTCP SmartDefense Protections RTP SmartDefense Protections Block multicast RTP connections Block non Version 2 RTP Packets Block multiple Synchronization Sources (SSRC) - RTP Validate ports parity (even) Validate payload size Validate Extension Validate CC field RTCP SmartDefense Protections Block multicast RTCP connections Block multiple Synchronization sources (SSRC) - RTCP Validate port s parity (odd) Validate length RTP/RTCP protections with SecureXL SIP Application Policy Methods Unsupported by SIP Server Application Policy Details Block Unsupported SIP Commands Configuration Details Early Media Proxy Redirecting a Call to a Non-Configured Proxy Proxy Failover Video Audio Instant Messaging Push to Talk over Cellular SIP SmartDefense Protections Table of Contents 7

8 Block Notify messages with Invalid Subscription-State Header Block Basic Authorization Maximum allowed retransmissions SIP Header Spoofing Block Unrecoverable SIP Inspection Errors SIP Protocol Anomaly Protections Introduction to SIP Protocol Anomaly Protections Strict protocol flow enforcement Max allowed Header Name length Max allowed Header Value length Max allowed URI length Max allowed Domain length Max allowed Call-ID length Max allowed Tag length Max allowed SDP line length General header security Specific header security Chapter 12 Chapter 13 Chapter 14 SIP Rule Base Configuration Supported SIP Deployments and NAT Support Additional Conditions for Using NAT in SIP Networks SIP-Specific services General Guidelines for SIP Security Rule Configuration SIP Rules for a Peer-to-Peer No-Proxy Topology SIP Rules for a Proxy in an External Network SIP Rules for a Proxy-to-Proxy Topology SIP Rules for a Proxy in DMZ Topology Using SIP on a Non-Default Port Enabling Dynamic Opening of Ports for SIP Signaling Example Rule With the sip_dynamic_ports Service SIP Advanced Configuration Gateway Clustering Support for SIP Synchronizing SIP Connections Load Sharing of SIP Connections Multicast Support for SIP Configuring SIP-T Support Troubleshooting SIP Inspection of TLS-Secured SIP Traffic Introduction to TLS The Check Point SIP TLS Solution A Typical TLS-Secured Connection Workflow for Configuration of TLS-secured SIP Configuring TLS-Secured SIP Choosing the TLS-Related Service Configuring the Rule for sip_tls_authentication

9 Configuration Using the sip_tls_with_server_certificate Service Legacy Solution for SIP TLS Support Chapter 15 Chapter 16 MGCP-Based VoIP Introduction to MGCP Supported MGCP RFCs and Standards MGCP SmartDefense Protections Max length of header value Block unrecoverable MGCP inspection errors MGCP Protocol Anomaly Protections MGCP Application Policy Commands Unsupported by MGCP Server Fax MGCP Supported Deployments and NAT Support Additional Conditions for Using NAT in MGCP Networks Rule Base Configuration for MGCP MGCP-Specific services MGCP Rules for a Call Agent in the External Network MGCP Rules for Call Agent in DMZ MGCP Rules for Call Agent to Call Agent H.323-Based VoIP Introduction to H Supported H.323 Protocols and Standards Signaling and Media Protocols for H Supported H.323 Standards H.323 SmartDefense Protections Introduction to SmartDefense for H The SmartDefense H.323 Branch Block sessions that do not start with Setup message H.323 Protocol Anomaly Protections H.323 Application Policy Introduction to H.323 Application Policy Sessions that use H.245 Tunneling T H.323 connection from RAS messages Supported H.323 Deployments and NAT Support H.323 Security Rule Base Configuration H.323 Specific Services General Guidelines for H.323 Security Rule Configuration H.323 Rule for an Endpoint-to-Endpoint Topology H.323 Rules for a Gatekeeper-to-Gatekeeper Topology H.323 Rules for a Gateway-to-Gateway Topology H.323 Rules for a Gatekeeper in the External Network H.323 Rules for a Gateway in the External Network H.323 Rules for a Gatekeeper in DMZ Topology H.323 Rules for a Gateway in DMZ Topology Table of Contents 9

10 Chapter 17 Chapter 18 SCCP-Based VoIP Introduction to SCCP Security and Connectivity Encrypted Protocol Support SCCP SmartDefense Protections Max Allowed SCCP Message Length Verify SCCP State Machine Verify SCCP Header Content Block unrecoverable SCCP Inspection Errors SCCP Application Policy Block Unknown SCCP Messages SCCP Supported Deployments Configuring SCCP Connectivity and Security General Guidelines for SCCP Security Rule Configuration SCCP-Specific services Configuring the Rule Base for SCCP Configuring SmartDefense and Application Policy for SCCP Alcatel-Based VoIP Alcatel Security and Connectivity Supported Alcatel Protocols Configuring Alcatel Connectivity and Security Predefined Alcatel Services Configuring the Rule Base for Alcatel Configuring Media Access control for Alcatel Call Servers

11 Preface P Preface In This Chapter Who Should Use This Guide page 12 Summary of Contents page 13 More Information page 15 Feedback page 16 11

12 Who Should Use This Guide This guide is intended for administrators responsible for maintaining network security within an enterprise, including Policy management and user support. This guide assumes a basic understanding of: System administration. The underlying operating system. Internet protocols (IP, TCP, UDP etc.). 12

13 Summary of Contents This guide describes how to administer VPN-1 Power/UTM NGX R It contains the following sections and chapters: Chapter Chapter 1, Overview Chapter 2, Performing a Basic Configuration Chapter 3, Tour of SmartDashboard for VoIP Chapter 4, VoIP Entities and Topology Chapter 5, Emergency Numbers Chapter 6, Far End NAT Traversal Chapter 7, Rate Limiting DoS Protection Chapter 8, Quality of Service Chapter 9, RTP/RTCP SmartDefense Protections Description General overview and a summary of NGX R connectivity, security, and management features. 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. 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. 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. How to configure Check Point gateways to allow SIP calls to and from any number that is configured as an emergency number. 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. SmartDefense protections against rate-based denial of service attacks. Assuring levels of service for SIP by means of Per Gateway QoS, Per Server QoS, and DiffServ Marking. SmartDefense protections for RTP and RTCP for version NGX R

14 Chapter Chapter 10, SIP Application Policy Chapter 11, SIP SmartDefense Protections Chapter 12, SIP Rule Base Configuration Chapter 14, Inspection of TLS-Secured SIP Traffic Chapter 13, SIP Advanced Configuration Chapter 15, MGCP-Based VoIP Chapter 16, H.323-Based VoIP Chapter 17, SCCP-Based VoIP Chapter 18, Alcatel-Based VoIP Description Configuring SIP application policy, in the SmartDashboard VoIP tab, under Application Policy > SIP. SmartDefense protections for SIP for version NGX R Security Rule Base configuration for SIP-based VoIP. How to configure Check Point gateways to decrypt and inspect TLS-secured SIP calls. Some advanced aspects of SIP configuration and troubleshooting. SmartDefense protections for MGCP-based VoIP, MGCP application policy, and Rule Base configuration. SmartDefense protections for H.323 for version NGX R , application policy configuration, and Security Rule Base configuration. SmartDefense protections for SCCP for version NGX R , application policy configuration, and Security Rule Base configuration. How to configure Security Rule Base rules so that the gateway allows UA calls. 14

15 More Information For additional technical information about Check Point products, and for the latest version of this document, see the Check Point Support Center at 15

16 Feedback Check Point is engaged in a continuous effort to improve its documentation. Please help us by sending your comments to: cp_techpub_feedback@checkpoint.com 16

17 Chapter 1 Overview In This Chapter Introduction to NGX R 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 17

18 Introduction to NGX R NGX R is a VoIP aware Check Point gateway offering comprehensive security for Enterprises, Telecom networks, and Service Provider VoIP environments. The NGX R 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 R 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 R , 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 R provides monitoring mode and highly detailed logs, specifically tailored to VoIP traffic, making it easy to perform ongoing administration and troubleshooting. NGX R 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. 18

19 VoIP Security Deployment Scenarios NGX R can be deployed by enterprises, managed service providers and telecom network providers. Enterprise Deployment 1: Perimeter VoIP Gateway In 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 R 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. Chapter 1 Overview 19

20 Figure 1-1 NGX R in an Enterprise Deployment: Perimeter VoIP Gateway 20

21 Enterprise Deployment 2: LAN segmentation In this enterprise deployment, an NGX R 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 R in an Enterprise Deployment: LAN Segmentation Chapter 1 Overview 21

22 Service Provider Deployment A 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 R also makes it possible to implement strong security measures that are necessary to maintain a high quality of service. Figure 1-3 NGX R in a Managed Service provider Deployment 22

23 Supported VoIP Protocols VPN-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 and that the caller and recipient are allowed to make and receive VoIP calls. In addition, VPN-1 examines the contents of the packets passing through every allowed port to ensure that they contain the correct information. Full stateful inspection on H.323, SIP, MGCP, and SCCP commands ensures that all VoIP packets are structurally valid, and that they arrive in a valid sequence. Signaling and Media Protocols A 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. Chapter 1 Overview 23

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. 24

25 Supported VoIP Standards Supported SIP RFCs and Standards The following SIP RFCs and standards are supported: RFC The most recent SIP RFC. RFC Session Initiation Protocol for Telephones (SIP-T). RFC UPDATE message. RFC INFO message. RFC REFER message. RFC SIP Events. RFC Reliability of Provisional Responses. RFC MESSAGE message. RFC SDP Session Description Protocol RFC 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 Standards See Supported MGCP RFCs and Standards on page 203. Supported H.323 Protocols and Standards See Supported H.323 Protocols and Standards on page 223. Chapter 1 Overview 25

26 VoIP Logging SmartView 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. 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 If VoIP logging is disabled, then only standard logging takes place, showing the source, destination and protocol information. Predefined VoIP Queries in SmartView Tracker In Smartview Tracker, there are a number of predefined VoIP log queries: The following queries are available: Registration Session These 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 Session These 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. 26

27 Security Events These 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 R 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 Session These 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), Chapter 1 Overview 27

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 Events These 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. 28

29 Licensing Requirements The following features require a VoIP license, in addition to the Check Point gateway license: Feature RTP/RTCP protections Rate limiting protections Far End NAT Traversal SmartDashboard and Administration Guide Locations SmartDashboard SmartDefense tab: Application Intelligence > VoIP > Protections for R > RTP RTCP Administration Guide RTP SmartDefense Protections on page 118 RTCP SmartDefense Protections on page 121 SmartDashboard SmartDefense tab: Application Intelligence > VoIP > Protections for R > Rate Limiting Administration Guide Rate Limiting DoS Protection on page 93 SmartDashboard Check Point gateway: Advanced > VoIP page Internal Far End NAT Traversal Administration Guide Far End NAT Traversal on page 75 Chapter 1 Overview 29

30 Feature TLS encrypted inspection using the service sip_tls_with_server_certificate QoS Per Gateway Media Admission Control SmartDashboard and Administration Guide Locations SmartDashboard SIP Server, TLS page Administration Guide Configuration Using the sip_tls_with_server_certificate Service on page 185 SmartDashboard VoIP tab: QoS > Per Gateway > Call Admission Control Traffic policy Administration Guide Call Admission Control on page 111 Traffic Policy on page 111 SmartDashboard VoIP tab: VoIP Entities and Topology > Media Admission Control Administration Guide Media Admission Control on page 58 30

31 Chapter 2 Performing 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 31

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. 32

33 Setting Up a Basic Configuration This 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 Chapter 2 Performing a Basic Configuration 33

34 Logging in to SmartDashboard The 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. Note - This step is only necessary the first time you log in. Defining the VPN-1 Power/UTM Gateway The 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. 34

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 R 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. Chapter 2 Performing a Basic Configuration 35

36 Note - Do not disable this option if Use Internal SIP Far End NAT Traversal is enabled It is possible to disable dynamic pinholing for gateways of version NGX 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: 36

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 Type For 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 Endpoints Define 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 Chapter 2 Performing a Basic Configuration 37

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 Rule Configure 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: Source Destination Service Action internal-net sip_server_host sip_server_host internal-net sip sip_dynamic_ports sip-tcp Accept Note - In the Install On cell of the rule, include the VPN-1 Power/UTM gateway. Installing the Security Policy From the SmartDashboard main menu, select Policy > Install and Install the security Policy. Testing the Configuration Test the configuration by making phone calls: 38

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 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). Chapter 2 Performing a Basic Configuration 39

40 Figure 2-3 Example of a Call Session VoIP Log 40

41 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 the VoIP sections of SmartDashboard. In This Chapter The VoIP Tab page 42 SmartDefense VoIP Protections page 45 Monitor-Only Mode page 47 41

42 The VoIP Tab All VoIP-related configuration can be performed from the VoIP tab. This section summarizes the purpose of each section of the VoIP tab. Enforcing Gateways Create 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 Policy Summary view of the Application Policy options. View and configure the settings for each option. 42

43 The summary view shows the following information: Category Name Policy Details Location of the option in the Application Policy section of the VoIP tab. Name of the application policy option. 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. 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 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. Chapter 3 Tour of SmartDashboard for VoIP 43

44 VoIP Entities and Topology QoS The 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. Assure 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 <1024 This 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. 44

45 SmartDefense VoIP Protections SmartDashboard includes VoIP-comprehensive SmartDefense protections for gateways of version NGX R 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 H.323 SIP MGCP SCCP (Skinny) Purpose SmartDefense protections organized according to VoIP protocol. These protections are supported on gateways of version R65 and lower. Protections for R 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. Chapter 3 Tour of SmartDashboard for VoIP 45

46 Protections for R Purpose 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

47 Monitor-Only Mode Monitor-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 R > Monitor-only for protections Switches on monitor-only for all protections in the VoIP > Protections for R 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. Chapter 3 Tour of SmartDashboard for VoIP 47

48 48

49 Chapter 4 VoIP Entities and Topology In This Chapter VoIP Servers page 50 VoIP Endpoints page 57 Media Admission Control page 58 Entity Protection Summary page 65 49

50 VoIP Servers In This Section 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 The Purpose of VoIP Servers The 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 Types For 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 50

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 Note - The option described in this section is configured in the Advanced page of the SIP server object. 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). 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. An explanation follows of how this option works. Chapter 4 VoIP Entities and Topology 51

52 SIP Packet Before NAT The packet capture shown here shows a SIP packet from a phone with IP address , and source port 5060 (the default SIP port). The phone number is 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 , 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:4321@ :5060. A phone with the number 8765 would be registered as sip:8765@ :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. 52

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 , and the source port is also translated to an allocated port of 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:4321@ :10015 (as shown in the packet capture), and another phone with the number 8765 as (for example) sip:8765@ : As a result, all internal phones are registered successfully on the server. Hide NAT for MGCP traffic Note - The option described in this section is configured in the Advanced page of the MGCP server object. 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. Chapter 4 VoIP Entities and Topology 53

54 MGCP Packet Before NAT The packet capture shown here shows an MGCP packet from a phone with IP address , 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 , but the source port 2427 is unchanged. In this case all the internal phones are registered with the same Source IP (for example ) 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. 54

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 , and the source port is also translated, to an allocated port of 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 and source port (as shown in the packet capture), and another phone with source IP and source port 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 @example.com, and the configured extension length is 4, then the gateway will be able to associate calls to/from 4321@example.com 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. Chapter 4 VoIP Entities and Topology 55

56 3. Select Assume VoIP network uses extension length and insert the extension length, For this example, select Install the policy. Configuring Support for a Range of Extension Lengths If 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 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 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 ac is the hexadecimal representation of and 3 is the minimum extension length, as in this example. 5. To add another server, for example, a SIP server 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. 56

57 VoIP Endpoints VoIP 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. Chapter 4 VoIP Entities and Topology 57

58 Media Admission Control In This Section 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 Definition of Media Admission Control Media 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 Flow To 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. 58

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 Control The 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. Chapter 4 VoIP Entities and Topology 59

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 Control VoIP 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 R 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 60

61 To configure media admission control (for connections through NGX R 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. Chapter 4 VoIP Entities and Topology 61

62 Accept ensures no media admission control is performed. All VoIP servers are allowed to open dynamic ports of behalf of all VoIP entities. 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 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). 62

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 Configured If 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 R 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. Chapter 4 VoIP Entities and Topology 63

64 Media Admission Control Decision Flow Chart The 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 64

65 Entity Protection Summary The 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. Chapter 4 VoIP Entities and Topology 65

66 Understanding the Entity Protection Summary The 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. 66

67 Application Policy Section The 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 sip_registrar MGCP_server All other entities Action Accept Drop Monitor Only Chapter 4 VoIP Entities and Topology 67

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 68

69 SmartDefense Section The 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. Chapter 4 VoIP Entities and Topology 69

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. 70

71 Chapter 5 Emergency 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 71

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. 72

73 Configuring Emergency Numbers The 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 Chapter 5 Emergency Numbers 73

74 74

75 Chapter 6 Far End NAT Traversal In This Section The VoIP NAT Challenge page 76 The Far End NAT Traversal Solution page 76 NGX R 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 75

76 The VoIP NAT Challenge In 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 R are able to route VoIP calls using Far End NAT Traversal. The Far End NAT Traversal Solution The 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 R 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 R 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 R 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

77 NGX R NAT Deployments NGX R 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 R gateway at the main office. Upgrading to version NGX R 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 R in an Enterprise Deployment Chapter 6 Far End NAT Traversal 77

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 R 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 R in a Managed Service Provider Deployment 78

79 How Far End NAT Traversal works The 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 R 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 Devices When 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 R 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. Chapter 6 Far End NAT Traversal 79

80 Pinhole Maintenance Configuration Options In 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 Payloads When Far End NAT is configured on the NGX R 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 R , and the signaling path from a VoIP phone behind a NAT device via the NGX R gateway to the VoIP server and destination IP phone. Note - In this example, IP addresses starting x.x and x.x denote public IP addresses. Figure 6-3 Far End NAT Traversal in a Carrier Deployment 80

81 NGX R 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 R gateway: Performs NAT on the IP header. The IP is changed from to 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 R gateway routes the packet to the VoIP server. 5. VoIP server routes the VoIP packet to the destination phone. Chapter 6 Far End NAT Traversal 81

82 VoIP Server and Endpoint Compliance In 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. 82

83 Ports and Addresses for Signaling and Media In addition to the Far End NAT that the NGX R 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 Allocation A 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 Range If 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. Chapter 6 Far End NAT Traversal 83

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. 84

85 Configuring Far End NAT Traversal for SIP To 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 gateway To 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 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 The Enforcing Gateways Page of the SmartDashboard VoIP Tab Chapter 6 Far End NAT Traversal 85

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 R 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 Gateway To 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 R In the Check Point Products section, at least the Firewall product is selected. 2. Select the Advanced > VoIP page (Figure 6-6). 86

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. Note - Do not disable this option if Use Internal SIP Far End NAT Traversal is enabled 4. Select Use Internal SIP Far End NAT Traversal. Chapter 6 Far End NAT Traversal 87

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. 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. 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 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. 88

89 Defining a SIP Proxy In 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. Chapter 6 Far End NAT Traversal 89

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 Gateway The 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). 90

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. Chapter 6 Far End NAT Traversal 91

92 Configuring the Client SIP Phones In 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. 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. Security Rule Base Configuration Define a rule in the Security Rule Base that allows Far End NAT Traversal. Configure the following security rule: 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:sip and/or TCP:sip-tcp 92

93 Chapter 7 Rate 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

94 Introduction to Denial of Service Protection A 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 R 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 R > Rate Limiting. 94

95 Rate limiting Protections Limiting 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 Are not supported in a ClusterXL Load Sharing deployment. Chapter 7 Rate Limiting DoS Protection 95

96 Configuring Rate Limiting Protections In 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. 96

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 R 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. Chapter 7 Rate Limiting DoS Protection 97

98 Non SIP Entities Rate Limiting This 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 Details To 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 Go to SmartDefense > Application Intelligence > VoIP > Protections for R > 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. 98

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. Chapter 7 Rate Limiting DoS Protection 99

100 SIP Servers Rate Limiting This 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 Attacks In 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 Users When 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. 100

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 the user is bob. 2. The source IP address of the request. How a User Becomes Trusted There 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 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 Details To 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 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 R > Rate Limiting > SIP Servers Rate Limiting 4. Click Enforcing servers. Chapter 7 Rate Limiting DoS Protection 101

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. 102

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. 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. For an explanation of the Advanced options, see the Example of SIP Server Rate Limiting. For information on Method Limiting see Method Limiting Chapter 7 Rate Limiting DoS Protection 103

104 Example of SIP Server Rate Limiting The 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 104

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 = 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 Chapter 7 Rate Limiting DoS Protection 105

106 SIP Endpoints Rate Limiting This 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 Details To 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 Go to SmartDefense > Application Intelligence > VoIP > Protections for R > 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. 106

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. 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. 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 Go to SmartDefense > Application Intelligence > VoIP > Protections for R > Rate Limiting > SIP Internal Networks Rate Limiting Chapter 7 Rate Limiting DoS Protection 107

108 SIP Internal Networks Rate limiting Settings Per Profile Figure 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. 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. 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 - 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. 108

109 Chapter 8 Quality of Service In This Chapter Introduction to QoS for NGX R page 110 Per Gateway QoS page 111 Per Server QoS page 113 DiffServ Marking of VoIP Data Packets page

110 Introduction to QoS for NGX R 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 R 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. 110

111 Per Gateway QoS Call 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 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 These options are not supported in a ClusterXL Load Sharing deployment. 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 Chapter 8 Quality of Service 111

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 Settings It 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. 112

113 Per Server QoS SIP Block Calls from Unregistered Users This 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. Chapter 8 Quality of Service 113

114 DiffServ Marking of VoIP Data Packets Quality 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 Forwarding DiffServ-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 codepoint, as specified in RFC "An Expedited Forwarding PHB (Per-Hop Behavior)". Configuration Details The 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 codepoint referred to in RFC The ToS byte is marked for expedited forwarding only if the existing marking is for "normal service" (that is, the six bits are zero). 114

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 codepoint referred to in RFC Exceptions per Gateway It 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 115

116 116

117 Chapter 9 RTP/RTCP SmartDefense Protections NGX R includes a number of SmartDefense protections for RTP and RTCP. This chapter describes the RTP and RTCP protections. Note - RTP and RTCP SmartDefense Protections require a VoIP license, in addition to the Check Point gateway license. See Licensing Requirements on page 29. 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 RTP SmartDefense Protections page 118 RTCP SmartDefense Protections page 121 RTP/RTCP protections with SecureXL page

118 RTP SmartDefense Protections Description 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 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 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. 118

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. Chapter 9 RTP/RTCP SmartDefense Protections 119

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. 120

121 RTCP SmartDefense Protections Description 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 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). In This Section Block multicast RTCP connections Description 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 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. Chapter 9 RTP/RTCP SmartDefense Protections 121

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." 122

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. Chapter 9 RTP/RTCP SmartDefense Protections 123

124 RTP/RTCP protections with SecureXL SecureXL 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 124

125 Chapter 10 SIP 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

126 Methods Unsupported by SIP Server Methods 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 Configuration This 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 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

127 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 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 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. Chapter 10 SIP Application Policy 127

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 128

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. Chapter 10 SIP Application Policy 129

130 Proxy Failover 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. 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. 130

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. 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. Push to Talk over Cellular This 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. Chapter 10 SIP Application Policy 131

132 132

133 Chapter 11 SIP SmartDefense Protections SmartDefense protects against attacks by identifying attacks signatures, identifying packets with protocol anomalies, and ensuring RFC compliance. NGX R 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

134 Block Notify messages with Invalid Subscription-State Header Attack Name: VoIP-Phones: SIP-Notify-Message packet spoofing Industry Reference CVE 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 voic . 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. 134

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 Threat Description RFC 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. Chapter 11 SIP SmartDefense Protections 135

136 Maximum allowed retransmissions Description 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. 136

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 R > 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 of RFC3261. It is recommended to define the compact version in addition to the long form. Chapter 11 SIP SmartDefense Protections 137

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. 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. 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. 138

139 Block Unrecoverable SIP Inspection Errors Description 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. Chapter 11 SIP SmartDefense Protections 139

140 SIP Protocol Anomaly Protections In This Section 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 Introduction to SIP Protocol Anomaly Protections A 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. 140

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 Four state machines are defined: Invite Client Transaction (Section of RFC 3261) Non Invite Client Transaction (Section ) Invite Server Transaction (Section ) Non Invite Server Transaction (Section ) Threat Description If the protocol flow is not enforced, SIP transactions become vulnerable to call hijacking and man in the middle attacks. Chapter 11 SIP SmartDefense Protections 141

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, 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 142

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:bob@example.com, or sip:alice@pc33.atlanta.com). 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: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@biloxi.com i:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@ Chapter 11 SIP SmartDefense Protections 143

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:alice@example.com>;tag= 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 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:

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. Chapter 11 SIP SmartDefense Protections 145

146 General header security These protections relate to protocol anomalies in the SIP header in general, rather than to specific header fields. In This Section 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 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 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. 146

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 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. Chapter 11 SIP SmartDefense Protections 147

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. 148

149 Specific header security These protections relate to protocol anomalies in specific SIP header fields. In This Section Block messages with invalid header value Description 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 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 " "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." Chapter 11 SIP SmartDefense Protections 149

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 watson@example.org). 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:t.watson@example.org > Another example of an invalid format is a single quote in the display name To: "Mr. J. User <sip:j.user@example.com> 150

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. Chapter 11 SIP SmartDefense Protections 151

152 Block messages with invalid format in Via Header Description RFC 3261 section 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 ;;,;,,;;; A example of an unreasonable client address is or 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. 152

153 Block messages with invalid format in Cseq header Description Section 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 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. Chapter 11 SIP SmartDefense Protections 153

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 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 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 154

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 " 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 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. Chapter 11 SIP SmartDefense Protections 155

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. 156

157 Chapter 12 SIP 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

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. Table 12-1 Supported SIP Topologies Endpoint to Endpoint (Figure 12-1 on page 158) SIP Proxy in External (Figure 12-2 on page 159) SIP Proxy to Proxy (Figure 12-3 on page 159) SIP Proxy in DMZ (Figure 12-4 on page 159) No NAT NAT for Internal Phones Hide/Static NAT NAT for Proxy Static NAT Yes Static NAT only Not applicable Yes Yes Not applicable Yes Yes Yes Yes Yes Yes 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. 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

159 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. Additional Conditions for Using NAT in SIP Networks SIP can be used with Network Address Translation (NAT), subject to the following conditions: Chapter 12 SIP Rule Base Configuration 159

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. 160

161 SIP-Specific services The following predefined SIP services are available: Service UDP:sip TCP:sip-tcp TCP:sip_tls_with_server_certificate TCP:sip_tls_authentication TCP:sip_tls_not_inspected Other: sip_dynamic_ports Purpose Used for SIP over UDP Used for SIP over TCP Used for encrypted SIP over TLS. Used for unencrypted SIP over TLS Insecure way of allowing SIP over TLS to pass without inspection Enables the dynamic opening of ports for SIP signaling. See Enabling Dynamic Opening of Ports for SIP Signaling on page 171. 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 Service UDP:sip_any TCP:sip-tcp_any Purpose Used for gateways of version NGX R65 or below, if not enforcing handover. Do not use for NGX R 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. Chapter 12 SIP Rule Base Configuration 161

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. 162

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: Source Destination Service Action Comment Net_A Net_B or Net_B Net_A UDP:sip Accept SIP over UDP Bidirectional calls Source Destination Service Action Comment Net_A Net_B Net_B Net_A SIP over TCP service Accept SIP over TCP Bidirectional calls 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 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. Chapter 12 SIP Rule Base Configuration 163

164 3. Install the security Policy. SIP Rules for a Proxy in an External Network Figure 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: Source Destination Service Action Comment SIP_Proxy Net_A Net_A SIP_Proxy UDP:sip Accept SIP over UDP Bidirectional calls or 164

165 Source Destination Service Action Comment SIP_Proxy Net_A Net_A SIP_Proxy 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 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. SIP over TCP service Accept SIP over TCP Bidirectional calls Chapter 12 SIP Rule Base Configuration 165

166 SIP Rules for a Proxy-to-Proxy Topology Figure 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: Source Destination Service Action Comment Proxy_A Proxy_B or Proxy_B Proxy_A UDP:sip Accept SIP over UDP Bidirectional calls Source Destination Service Action Comment Proxy_A Proxy_B Proxy_B Proxy_A SIP over TCP service Accept SIP over TCP Bidirectional calls 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

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. Chapter 12 SIP Rule Base Configuration 167

168 SIP Rules for a Proxy in DMZ Topology Figure 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: Source Destination Service Action Comment Proxy_DMZ Net_A Net_B or Net_A Net_B Proxy_DMZ UDP:sip Accept SIP over UDP Bidirectional calls Source Destination Service Action Comment Proxy_DMZ Net_A Net_B Net_A Net_B Proxy_DMZ SIP over TCP service Accept SIP over TCP Bidirectional calls 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

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 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): Table 12-2 Original Translated Comment Source Destination Service Source Destination Service Proxy_DMZ Net_B *Any Proxy_DMZ _NATed: Static Net_B Proxy_DMZ_NATed *Any = Proxy_DMZ: Static 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: :0D:60:83:B3:74 = = Outgoing calls = Incoming calls Where is the static address, and 00:0D:60:83:B3:74 is the address of the external interface. Chapter 12 SIP Rule Base Configuration 169

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 Port By default, SIP uses the UDP port 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. 170

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 For example, a registration request of phone number 2001 with IP address port An example of such a Contact header field is as follows: Contact: <sip:2001@ :3000;rinstance=64d25786c64e7975>;expires= The "rport" parameter is used in the Via header field (see RFC An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing). For example: Via: SIP/2.0/TCP :5060;branch=z9hG4bK f cd82e34eec4112ae8; 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 Service The 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: Chapter 12 SIP Rule Base Configuration 171

172 Source Destination Service Action SIP_phone SIP_server SIP_server SIP_phone udp:sip sip_dynamic_port Accept 172

173 Chapter 13 SIP 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

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. Note - The Synchronize connections on Cluster option is enabled by default 5. Click OK. 174

175 6. Install the policy. Load Sharing of SIP Connections SIP 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 The following are not supported in a Load Sharing deployment: SmartDefense Rate Limiting protections, Located in Application Intelligence > VoIP > Protections for R > Rate Limiting VoIP tab, QoS Per Gateway options (Call Admission Control and Traffic Policy). Multicast Support for SIP The 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. Chapter 13 SIP Advanced Configuration 175

176 Configuring SIP-T Support To configure support for RFC 3372 Session Initiation Protocol for Telephones (SIP-T): 1. Add the $FWDIR/lib/user.def line on the SmartCenter server: sipt_hosts = { < first_ip, second_ip>, < first_ip, second_ip>,......,< first_ip, second_ip> } ; 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 and , and between and add the following line: sipt_hosts = { < , >, < , > } ; If the file does not exist, create it. 2. Save the file. 3. Install the security policy. Troubleshooting SIP To 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). 176

177 Chapter 14 Inspection 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

178 Introduction to TLS Transport 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. 178

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 Connection Figure 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. Chapter 14 Inspection of TLS-Secured SIP Traffic 179

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. 180

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. Chapter 14 Inspection of TLS-Secured SIP Traffic 181

182 182 For detailed instructions on how to configure support for SIP TLS, see Configuring TLS-Secured SIP on page 183.

183 Configuring TLS-Secured SIP The procedure for configuring SIP TLS depends on your VoIP environment. In This Section 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 Choosing the TLS-Related Service Choose the appropriate TLS-related service to use in the Security Rule Base rule: sip_tls_with_server_certificate or sip_tls_authentication: Table 14-1 TLS-Related SIP Services For TLS connections that are Encrypted Not encrypted, but are authenticated, and are changed by the gateway (via NAT or the SmartDefense SIP Header Spoofing protection) Not encrypted, but are authenticated, and are not changed by the gateway (no NAT, and the SmartDefense SIP Header Spoofing protection does not apply) Use the TLS Service TCP:sip_tls_with_server_certificate TCP:sip_tls_authentication Note - Do not use both TLS-related services in the same rule. 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 Chapter 14 Inspection of TLS-Secured SIP Traffic 183

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_authentication If 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: : Source Destination Service SIP Proxy SIP Phones sip_tls_authentication SIP Phones SIP Proxy 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. 184

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. 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. 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 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 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. 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). Chapter 14 Inspection of TLS-Secured SIP Traffic 185

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: 186

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 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 Complete the configuration by configuring the Security Rule Base. See Configuring the Rule for sip_tls_with_server_certificate on page 198 Chapter 14 Inspection of TLS-Secured SIP Traffic 187

188 Scenario B: Proxy is External, Phones are Internal In 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: 188

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 Complete the configuration by configuring the Security Rule Base. See Configuring the Rule for sip_tls_with_server_certificate on page 198 Chapter 14 Inspection of TLS-Secured SIP Traffic 189

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 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 190

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 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. Chapter 14 Inspection of TLS-Secured SIP Traffic 191

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. 192

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 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 Internal In this scenario, the proxy and the phones are internal (under the control of the administrator). Chapter 14 Inspection of TLS-Secured SIP Traffic 193

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 External In 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 Gateway 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. 194

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. Chapter 14 Inspection of TLS-Secured SIP Traffic 195

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 196

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 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 CAs An 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 Chapter 14 Inspection of TLS-Secured SIP Traffic 197

198 The Certificate Authority Properties window opens. 3. In the General tab, click VoIP. Note - For External Trusted CAs, the settings in the Advanced tab of the Certificate Authority Properties window are not supported. 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. Note - Supported certificate file formats are: *.crt, *.cer, *.p7b, *.b64, *.mme 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. 198

199 1. Configure the SIP TLS security rule. A typical rule is as follows: : Source Destination Service SIP Proxy SIP Phones sip_tls_with_server_certificate SIP Phones SIP Proxy 2. Follow the instructions for configuring SIP over TCP rules in chapter 12, SIP Rule Base Configuration on page Install the Policy. Legacy Solution for SIP TLS Support If 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. Warning - 1. Opening all high UDP ports is very insecure. 2. Neither the SIP signaling nor the data is inspected. 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 A typical rule that assumes the phones send data directly to each other, and not through the proxy, is as follows: Source Destination Service SIP Proxy SIP Phones TCP: sip_tls_not_inspected SIP Phones SIP Proxy SIP Phones SIP Phones UDP: udp-high-ports 4. Install the Policy. Chapter 14 Inspection of TLS-Secured SIP Traffic 199

200 200

201 Chapter 15 MGCP-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

202 Introduction to MGCP MGCP 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. 202

203 Supported MGCP RFCs and Standards SmartDefense for MGCP enforces strict compliance with the following RFCs and standards: RFC RFC-3435 (version 1.0) ITU TGCP specification J.171. Chapter 15 MGCP-Based VoIP 203

204 MGCP SmartDefense Protections NGX R 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 page 204 Block unrecoverable MGCP inspection errors page 205 MGCP Protocol Anomaly Protections page 205 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. 204

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 Chapter 15 MGCP-Based VoIP 205

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 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." 206

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 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 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 states: "EndpointId is the identifier for the connection endpoint in the gateway where CreateConnection executes". Chapter 15 MGCP-Based VoIP 207

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 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 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. 208

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 ( ). MGCP messages containing illegal characters are blocked. Chapter 15 MGCP-Based VoIP 209

210 MGCP 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 MGCP application policy options are available in the SmartDashboard VoIP tab, under Application Policy > MGCP. In This Section Commands Unsupported by MGCP Server page 210 Fax page 213 Commands Unsupported by MGCP Server This option blocks MGCP request commands that the MGCP server is not allowed to process. Supported commands are configured per server. Blocking MGCP Commands There 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. 210

211 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) Blocking User Defined MGCP Commands RFC 3435 section 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. Chapter 15 MGCP-Based VoIP 211

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 Details To 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. 212

213 Figure 15-2 Supported Commands Page of the MGCP Server Object Fax 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. When 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. Chapter 15 MGCP-Based VoIP 213

214 MGCP Supported Deployments and NAT Support VPN-1 supports the MGCP deployments listed in Table 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 Call Agent in external network (Figure 15-3) Call Agent in DMZ (Figure 15-4) Call Agent to Call Agent (Figure 15-5) No NAT NAT for Internal Phones - Hide/Static NAT Yes Yes Yes Yes No No 214

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 Chapter 15 MGCP-Based VoIP 215

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. 216

217 Rule Base Configuration for MGCP This 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 services The following predefined MGCP services are available: Table 15-3 Predefined MGCP-Specific Services Service UDP:mgcp_CA UDP:mgcp_MG Other:MGCP_dynamic_ports Purpose Used for MGCP over UDP, for connections using the well known port is the Call-Agent port (2727). Used for MGCP over UDP, and whose well known port is the Media Gateway port (2427). Allows a MGCP connection to be opened on a dynamic port and not on the MGCP well-known port. 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 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. Chapter 15 MGCP-Based VoIP 217

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: Source Destination Service Action MGCP_Call_Agent Net_A Net_A MGCP_Call_Agent mgcp_ca or mgcp_mg or mgcp_dynamic_ports Accept For additional information on MGCP services, refer to MGCP-Specific services on page 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 DMZ Figure 15-7 illustrates an MGCP-based VoIP topology where a Call Agent is installed in the DMZ. 218

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: Source Destination Service Action Comment Net_A Net_B Call_Agent Net_A Net_B Call_Agent mgcp_ca or mgcp-mg Accept Bidirectional calls. For additional information on MGCP services, refer to MGCP-Specific services on page Install the security Policy. MGCP Rules for Call Agent to Call Agent Figure 15-8 illustrates a Call Agent-to-Call Agent topology with the Call Agents on opposite sides of the VPN-1 gateway. Chapter 15 MGCP-Based VoIP 219

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: Source Destination Service Action Comment Call_Agent_Int Call_Agent_Ext Call_Agent_Ext Call_Agent_Int For additional information on MGCP services, refer to MGCP-Specific services on page Install the security Policy. mgcp_ca or mgcp-mg Accept Bidirectional calls. 220

221 Chapter 16 H.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

222 Introduction to H.323 H.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 R 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

223 Supported H.323 Protocols and Standards Signaling and Media Protocols for H.323 Media 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 Q.931 manages call setup and termination. Q.931 uses a fixed port: TCP 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 Standards The 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. Chapter 16 H.323-Based VoIP 223

224 H.323 SmartDefense Protections In This Section 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 Introduction to SmartDefense for H.323 SmartDefense protects against attacks by identifying attacks, identifying packets with protocol anomalies, and ensuring standards compliance. NGX R 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. 224

225 Block sessions that do not start with Setup message Description SETUP is a Q.931 based H 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. Chapter 16 H.323-Based VoIP 225

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 call signaling messages to identify the destination or the source of the call. An example of the dialeddigits field is 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 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 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. 226

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 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 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 Call Signaling Channel. Chapter 16 H.323-Based VoIP 227

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 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 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 call signaling messages and H.245 messages are in ASN.1 syntax 228

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 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. Chapter 16 H.323-Based VoIP 229

230 H.323 Application Policy Introduction to H.323 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 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.120 This 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 messages This 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. 230

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. Chapter 16 H.323-Based VoIP 231

232 Supported H.323 Deployments and NAT Support Supported H.323 deployments are listed in Table 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 Endpoint to Endpoint (Figure 16-1 on page 233) Gatekeeper/Gateway in External (Figure 16-2 on page 233) Gatekeeper/Gateway to Gatekeeper/Gateway (Figure 16-3 on page 233) Gatekeeper/Gateway in DMZ (Figure 16-4 on page 234) No NAT Yes NAT for Internal Phones Hide/Static NAT Static NAT only NAT for Gatekeeper Static NAT Not applicable Yes Yes Not applicable Yes Yes Yes Yes Yes Yes 232

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. Chapter 16 H.323-Based VoIP 233

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. 234

235 H.323 Security Rule Base Configuration This section explains how to configure Security Rule Base Rules so that the gateway allows H.323 calls. In This Section 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 H.323 Specific Services The following predefined H.323 services are available: Table 16-2 Service TCP:H323 Predefined H.323 services Purpose 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. Chapter 16 H.323-Based VoIP 235

236 Table 16-2 Service UDP:H323_ras UDP:H323_ras_only TCP:H323_any Predefined H.323 services Purpose 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. 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. 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. Note - In general, use the H.323 and H.323_ras services in H.323 Security Rule Base rules. 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. 236

237 To allow H.323 traffic in the Security Rule Base, use regular Network objects. There is no need to define special Network objects. 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. H.323 Rule for an Endpoint-to-Endpoint Topology An 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: Table 16-3 Source Destination Service Action Net_A Net_B Net_B Net_A H 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. Accept Chapter 16 H.323-Based VoIP 237

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: Source Destination Service Action Comment GK_A GK_B H323 Accept Bidirectional calls. GK_B GK_A H323_ras For an explanation of the H.323 services, refer to H.323 Specific Services on page 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). 238

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 Topology A 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_A GW_B GW_B GW_A H323 Accept Bidirectional calls. Chapter 16 H.323-Based VoIP 239

240 For an explanation of the H.323 services, refer to H.323 Specific Services on page 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) 240

241 3. Define Security Rule Base rules: Source Destination Service Action Comment Net_A Net_B GK_B GK_B Net_A H323_ras H323 Accept Bidirectional calls. For an explanation of the H.323 services, refer to H.323 Specific Services on page 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 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 Network An 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. Chapter 16 H.323-Based VoIP 241

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: Table 16-4 Source Destination Service Action Comment Net_A Net_B GW_B GW_B Net_A For an explanation of the H.323 services, refer to H.323 Specific Services on page 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 Install the security policy. H323 Accept Bidirectional calls. 242

243 H.323 Rules for a Gatekeeper in DMZ Topology A H.323-based VoIP topology where a Gatekeeper is installed in the DMZ is shown in Figure 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 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: Table 16-5 Source Destination Service Action Comment GK_DMZ Net_A Net_B Net_A Net_B GK_DMZ H323 H323_ras Accept Bidirectional calls. For an explanation of the H.323 services, refer to H.323 Specific Services on page 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). Chapter 16 H.323-Based VoIP 243

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 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: Table 16-6 Original Translated Comment Source Destination Service Source Destination Service GK_DMZ Net_B *Any GK_DMZ: Static Net_B GK_DMZ_N ATed 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. *Any = GK_DMZ: Static = = Outgoing calls = Incoming calls H.323 Rules for a Gateway in DMZ Topology A H.323-based VoIP topology where a Gateway is installed in the DMZ is shown in Figure 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). 244

245 Figure 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: Source Destination Service Action Comment GW_DMZ Net_A Net_B Net_A Net_B GW_DMZ H323 Accept Bidirectional calls. For an explanation of the H.323 services, refer to H.323 Specific Services on page 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. Chapter 16 H.323-Based VoIP 245

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: Table 16-7 Original Translated Comment Source Destination Service Source Destination Service GW_DMZ Net_B *Any GW_DMZ: Static Net_B GW_DMZ_NATed *Any = GW_DMZ: Static 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. = = Outgoing calls = Incoming calls 246

247 Chapter 17 SCCP-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

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. 248

249 Encrypted Protocol Support The 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 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. Chapter 17 SCCP-Based VoIP 249

250 SCCP SmartDefense Protections A 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 R > 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. 250

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. Chapter 17 SCCP-Based VoIP 251

252 SCCP 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 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 Messages This option blocks messages that are not defined in the SCCP protocol. 252

253 SCCP Supported Deployments The SCCP deployments shown in Table 17-1 are supported. NAT on SCCP devices is not supported. Table 17-1 Supported SCCP Topologies CallManager in internal network (Figure 17-1) CallManager in the DMZ (Figure 17-3) CallManager in external network (Figure 17-2) No NAT NAT for Internal Phones - Hide/Static NAT Yes No No Yes No No NAT for the CallManager - Static NAT Yes No Not applicable Chapter 17 SCCP-Based VoIP 253

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. 254