IPS for VoIP
Introduction to IPS for VoIP
IPS adds more than 80 IPS VoIP protections and VoIP settings to protect against attacks. IPS protects against malicious attacks by:
- Identifying attack signatures
- Identifying packets with protocol anomalies
- Ensuring RFC compliance
- Inspecting signaling protocols, for example verifying header formats and protocol call flow state
- Giving enhanced security and more granular settings for SIP, H.323. SCCP and MGCP
As part of IPS, different VoIP protections can be enforced for different gateways using IPS profiles. With IPS, it is possible to change VoIP protections to mode. Running VoIP protections in mode lets you:
- Monitor events
- Do troubleshooting
- Get detailed IPS logs with packet captures on VoIP security events
|
Note - Event monitoring and detailed logging are also available in Prevent Mode.
|
For non-RFC complaint VoIP traffic, you can add exceptions to specified VoIP protections. These exceptions prevent the traffic from being dropped (for example due to illegal implementation) without compromising other VoIP security.
VoIP Protections in SmartDashboard
VoIP Protections in SmartDashboard are found on thetab
|
Important -
|
Protocol Engine Settings in IPS
IPS engine settings are found on thetab
For each protocol you can find its General Settings. For example, double-clicking shows and NAT . For more, see the section on SIP Engine Settings.
VoIP Call Initiation Rate Limiting
VoIP Call Initiation Rate Limiting is a general protection for SIP, MGCP, H.323 and SCCP protocols. Configure this protection on the:
tab
IPS Profiles
Using IPS profiles, a range of VoIP protections can be enforced on different Security Gateways.
SIP IPS Protections
IPS protects against attacks by identifying attacks signatures, identifying packets with protocol anomalies, and ensuring RFC compliance.
The Security Gateway includes a large number of IPS protections for SIP.
IPS protections can be configured for each profile. For each profile, the protection can be:
- Prevent
- Detect
- Inactive
|
Note -
- Application Policy options are not intended to protect against attacks.
- Logging settings for each protection are configured for each profile.
|
SIP Protections
The tab page has these protections
- Block SIP Calls from Unregistered Users
- Block SIP Basic Authentication
- Block Unrecoverable SIP Inspection Errors
- SIP Maximum Allowed Retransmissions
- SIP Media Admission Control
- Block SIP Multicast Connections
SIP Application Policy
Specified VoIP services can be blocked if the services
- Consume more bandwidth than the IP infrastructure can support
- Do not comply with the organization's security policy
Application policy options are not intended to protect against attacks.
These Application Policy options are available:
- Block SIP Audio
- Block SIP Instant Messaging
- Block SIP Proxy Failover
- SIP Block Push to Talk over Cellular
- Block SIP Video
- Block SIP Early Media
- Block SIP Keep Alive Messages
- SIP - Method Filtering
These SIP application policy options are on the:
tab
SIP Protocol Anomaly
A protocol anomaly is a field name or value in the protocol header that is RFC compliant, but deviates from usual use. For example a field value, which contains hundreds of characters where less than ten is usual, is an anomaly. If a protocol anomaly is found in the VoIP packet, this is a good indication that the VoIP network is being attacked.
These definitions are related 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 show as one or more header field rows.
- Each header field:
- Consists of a field name
- Is 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 one header field value, and show as a single header field row.
Protocol anomalies can result in buffer overflow conditions, parser errors, and malformed packets. Protocol anomalies in SIP messages make SIP applications vulnerable to attacks that send again and again huge quantities of fraudulent data, eventually overwhelming the server. For example, many buffer-overflow attacks send again and again a very large header to the VoIP phone. Buffer overflow conditions can also result in arbitrary code execution.
Stateful and Stateless protocol validation is done on SIP headers. SIP messages with header values that do not match correct usage are blocked.
These options are available to protect against SIP protocol anomalies:
- SIP Max Allowed URI Length
- SIP Max Allowed Call-ID Length
- SIP Max Allowed Domain Length
- SIP Max Allowed Header Name Length
- SIP Max Allowed Header Value Length
- SIP Max Allowed SDP Length
- SIP Max Allowed Tag Length
- Strict SIP Protocol Flow Enforcement
- Block SIP Messages with Binary Characters
Find these protections on the:
tab >
General Header Security
These protections are related to protocol anomalies in the SIP header in general, rather than specified header fields:
- SIP Max Allowed Occurrences of the Same Field
- Verify Format of SIP Header
- Enforce SIP Mandatory Fields Existence
- Enforce Single Occurrence of Fields by SIP RFC
- Block SIP Messages with Invalid SDP Format
Find these protections under: tab > .
Specific Header Security
These protections are related to protocol anomalies in specified SIP header fields:
- Block SIP NOTIFY Messages with Invalid Subscription-State Header
- SIP Min Allowed 'Max-Forwards' Value
- SIP Max Allowed 'Content-Length'
- Block SIP Messages with Invalid Header Value
- Block SIP Messages with Invalid Format in Start Line
- Block SIP Messages with Invalid Format in Via Header
- Block SIP Messages with Invalid Formats in Headers with Usernames
- Block SIP Messages with Invalid IP Address in SDP Header
- Block SIP Messages with Invalid Port in SDP Header
- Block SIP Messages with Invalid Format in CSeq Header
These protections are available on the: tab > .
IPS Engine Settings for SIP
Generals settings are configured on the tab.
Configure these fields:
determines how long endpoint registration information is kept in the database if a timeout is not specified in registration messages. The time period must be greater than or equal to the registration time period of the endpoint or the proxy. The default registration expiration period is 3600 seconds. If the endpoint does not send a user registration message in this period, registration information is deleted from the database.
determines the maximal allowed time period between one SIP signaling message and the next. This includes scenarios where Dynamic Pinholing (see below) is disabled, or for calls between two external endpoints or two internal endpoints. The default idle period is 3600 seconds.
. Selecting this option configures the gateway, when doing Hide NAT, to translate the IP address and source port of SIP endpoints.
|
Note - This applies to SIP over UDP traffic. For SIP over TCP, the source port is always translated if Hide NAT is enabled.
|
With this option cleared, the gateway does Hide NAT only on the IP address of the SIP endpoint phones. This option must be enabled in environments where:
- The gateway is configured to do Hide NAT on the internal endpoint IP addresses and:
- The SIP server can register only one endpoint with a given IP address and port combination. For example, if the server is a Cisco Unified communications Manager.
|
Note - 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.
|
For more, see the section on Hide NAT and SIP.
. The gateway can be configured to support short extension numbers for SIP. Endpoints register with the SIP server using their full name (usually a number). The gateway can be configured to identify a shortened name as belonging to an already registered endpoint. Calls to and from endpoints are made using a short extension name: 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 987654321@example.com, and the configured extension length is 4. The gateway can associate calls to or from 4321@example.com with the registered endpoint.
. Selecting this option prevents SIP media channels from opening. A Security Gateway dynamically opens ports for the VoIP media channel according to data in the signaling connection. Do not select this option if SIP media channel passes through the gateway.
H.323 IPS Protections
IPS protects against attacks by identifying attacks, identifying packets with protocol anomalies, and ensuring standards compliance.
- IPS does these application layer checks:
- Strict protocol enforcement, including the order and direction of H.323 packets
- H.323 messages length restrictions
- Stateful checks on RAS messages
- The Security Gateway supports these H.323 IPS protections:
- H.323 Media Admission Control
- Block H.323 Multicast Connections
- Block Unrecoverable H.323 Inspections Errors
These protections can be found at:
tab
IPS protections can be configured for each profile. The protection can be , , or . Logging settings for each protection are configured for each profile.
H.323 Application Policy
Specified VoIP services can be blocked if the services
- Consume more bandwidth than the IP infrastructure
- Do not comply with the organization's security policy
Application policy options are not intended to protect against attacks.
These Application Policy options are available:
- Block H.245 Tunneling
- Block T.120 over H.323
H.323 application policy options are available on the:
tab
H.323 Protocol Anomaly
A protocol anomaly is a field value or a message in the protocol that is standards compliant but deviates from correct use. For example a field value with 100 bytes, where much less is usual, is a protocol anomaly. A message with 1400 bytes where 800 bytes is usual is a protocol anomaly. A message that is sent "out of protocol state" (the message does not match the definition of 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. To protect against H.323 protocol anomalies, these options are available:
- Max Allowed H.245 Message Length
- Block H.323 Messages with Illegal ASN.1 Encoding
- H.323 Max Allowed Phone's Extension Length
- Max Allowed Q.931 Message Length
- Max Allowed RAS Message Length
- Verify H.323 State
- Verify H.323 Message Content
- Block H.323 Sessions that Do Not Start with Setup Message
H.323 Protocol Anomaly Protections are available on the:
tab
IPS Engine Settings for H.323
Generals settings are configured on the tab.
Configure these settings:
A timeout for a dynamically opened T.120 connection.
A Security Gateway dynamically opens ports for the VoIP media channel according to data in the H.323 signaling connection. Selecting this option prevents the opening of H.323 media channels. Do not select this option if a H.323 media channel passes through the gateway.
If the H323_ras service is allowed in the Rule Base, this option configures if control connections will be dynamically opened by the firewall from RAS messages. (Control connections are required by all H.323 connections.)
This option applies only to connections that start with RAS (that are allowed and inspected by the H323_ras service). If you select this setting, make sure that the H323 service is allowed in the Rule Base.
The endpoint usually initiates the H.323 (H.225) TCP connection to the Gatekeeper or server. In scenarios where the Gatekeeper initiates the TCP connection to the endpoint, this setting must be selected.
|
Note - In this scenario, Hide NAT on the internal network is not supported.
|
MGCP IPS Protections
The Security Gateway has a number of IPS protections for MGCP. IPS 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 IPS network security capabilities are supported, such as inspection of fragmented packets, anti-spoofing, and protection against Denial of Service attacks.
IPS protections can be configured for each profile. For each profile, the protection can be , , or . Logging options for each protection can also be configured for each profile.
Supported MGCP IPS protections:
- Block Unrecoverable MGCP Inspection Errors
- MGCP Media Admission Control
- Block MGCP Multicast Connections
- Block MGCP Messages with Binary characters
- MGCP - General Settings
MGCP Protections are available at:
tab
MGCP Protocol Anomaly Protections
- MGCP Max Allowed Call-ID Length
- MGCP Max Allowed Connection Mode Length
- MGCP Max Allowed Domain Name Length
- MGCP Max Allowed EndpointID Length
- MGCP Max Length of Header Value
- MGCP Max Allowed TransactionsID Length
MGCP Protocol Anomaly Protections are available at:
tab
MGCP Application Policy
Specified VoIP services can be blocked if the services consume more bandwidth than the IP infrastructure can support (or if the services simply do not comply with the organization's security policy).
These Application Policy options limit the VoIP services available to users.
- Block MGCP Fax
- MGCP - Command Filtering
MGCP Application Policy options are available on the:
tab
MGCP Command Filtering
This option blocks MGCP commands that must not be processed. MGCP command filtering makes it possible to block commands that the MGCP server does not support, or that you do not want the server to handle.
Supported MGCP Commands
There are nine 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.
Supported commands are configured for all servers on the:
tab
The Nine supported MGCP commands are:
- AuditConnection (AUCX)
- AuditEndpoint (AUEP)
- CreateConnection (CRCX)
- DeleteConnection (DLCX)
- EndpointConfiguration (EPCF)
- ModifyConnection (MDCX)
- NotificationRequest (RQNT)
- Notify (NTFY)
- RestartInProgress (RSIP)
|
Important - If an MGCP server is flooded with requests that use commands the server does not support, the server might experience an overload. An overloaded MGCP server will affect customer service levels.
|
User Defined MGCP Commands
RFC 3435 section 3.2.1.1 states: New verbs may be defined in further versions of the protocol. It may be necessary, for experimentation purposes, to use new verbs before they are sanctioned in a published version of this protocol. Experimental verbs MUST be identified by a four letter code starting with the letter X, such as for example XPER.
It is possible to define new commands, and configure the option to allow these commands.
Block Unknown Commands
Unknown commands are commands that do not show in the commands or commands lists. By default, all unknown commands are blocked.
User Defined Commands have SDP Header
This option specifies if user-defined commands include an SDP header. If the option is selected, the gateway inspects the SDP header attached to the command. If this option is not selected, the SDP header is ignored.
When defining an MGCP command, you can specify if 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 unsupported by the MGCP server:
- Open tab .
- On the page, double-click the related IPS profile.
The window opens.
- In the area, clear from the list the MGCP commands you want to block.
Fax
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.
IPS Engine Settings for MGCP
Generals settings are configured on the tab.
Configure these options:
Enabling the option configures the gateway to do Hide NAT on the:
- IP address
- Source port of the MGCP endpoint phones.
With this option disabled, the gateway does Hide NAT only on the IP address of the MGCP endpoint phones. This option must be enabled in environments where:
- The gateway is configured for Hide NAT on the internal IP addresses of the endpoints.
- The MGCP server can register only one endpoint with a given IP address and port combination.
A Security Gateway dynamically opens ports for VoIP media channel, according to the information in the MGCP signaling connection. This option prevents opening of MGCP media channels. Do not select this option if an MGCP media channel passes through the gateway.
SCCP (Skinny) IPS Protections
IPS protects by identifying attacks, identifying packets with protocol anomalies, and ensuring standards compliance.
The Security Gateway has a number of IPS protections for SCCP. IPS protections are configured for each profile. For each profile, the protection can be , , or . Logging settings for each protection are configured for each profile.
SCCP IPS Protections
- Block Unrecoverable SCCP Inspection Error
- SCCP Media Admission Control
- Block SCCP Multicast Connections
SCCP Protections are available on the:
tab
SCCP Application Policy
Specified VoIP services can be blocked if the services:
- Consume more bandwidth than the IP infrastructure can support
- Do not comply with the organization's security policy
One SCCP Application Policy option is available: Block Unknown SCCP Messages. The option is available on the:
tab
SCCP Protocol Anomaly Protections
Three SCCP anomaly protections are available on the:
tab
The protections are:
- Max Allowed SCCP Message Length
- Verify SCCP State
- Verify SCCP Header Content
IPS Engine Settings for SCCP
Generals settings are configured on the tab.
prevents opening of the SCCP media channel. Based on information in the SCCP signaling connection, a Security Gateway dynamically opens ports for the VoIP media channel. Do not select this option if a SCCP media channel passes through the gateway.
VoIP Media Admission Control
Media admission control refers to how a VoIP Server lets one endpoint to send media directly to a different endpoint. In earlier VoIP versions, Media Admission Control was known as handover.
To understand VoIP media admission control, it is important to examine a typical flow for establishing a VoIP call.
Endpoint A initiates with endpoint B, using VoIP server C.
When Endpoint A wants to open a VoIP call with Endpoint B:
- Endpoint A sends control signals to VoIP Server C. The signaling messages include details about the media capabilities of Endpoint A.
- VoIP Server C sends control signals to Endpoint B.
The signals are sent directly (as shown in the diagram, if it knows its physical location), or through a different VoIP Server.
- If Endpoint B accepts the call, and the endpoints agree on the parameters of the media communication, the call is established.
Endpoints send the control signals to their designated VoIP Server, not to each other. The media (voice or video) can be sent through the endpoints designated VoIP servers or directly to each other. For the endpoints to send media directly to each other, each endpoint must first learn the physical location of the other endpoint. Physical location is contained in the control signals the endpoint receives from its designated VoIP Server.
Control signals must pass through the gateway. The gateway allows control signals through only if they are allowed by the Rule Base. According to the information the gateway derives from its inspection of allowed control signals, the gateway dynamically opens pinholes for media connections.
If no limitations are placed on VoIP media admission control, attackers can possibly craft control signals that:
- Open pinholes for unauthorized access
- Cause internal endpoints to send media to IP addresses of their choice
- Eavesdrop, modify, or disrupt communications
Media admission control protection is available for:
Media Admission Control is configured on each VoIP Server.
Configuring VoIP Media Admission Control
- Create Host object for the VoIP Server
- Create Host or Network objects for VoIP endpoints.
- Create a Group for VoIP endpoints:
.
- Create VoIP Domain:
- Select one of the following:
- SIP Proxy
- H.323 Gatekeeper or Gateway
Note - For H.323 Media admission control, you can configure a VoIP Domain H.323 gateway or a VoIP Domain H.323 gatekeeper. There is no difference between the two types of domain. The routing mode tab on these domains can be safely ignored.
- MGCP Call Agent
- SCCP CallManager
- In the section, select the group you created for the VoIP endpoints.
- In the section, select the VoIP Server Host you created.
- In the rule base, add the VoIP Domain object to the and columns of the VoIP rule.
Note - VoIP domains disable SecureXL templates. If you are using SecureXL, move rules with VoIP Domains in them to the end of the Rulebase.
- Enable the related IPS protection according to the VoIP protocol:
tab
|
