SIP and IPS

Leave a reply

SIP and IPS

You can enable IPS in security policies that also accept SIP sessions to protect the SIP traffic from SIP-based attacks. If you enable IPS in this way then by default the pinholes that the SIP ALG creates to allow RTP and RTCP to flow through the firewall will also have IPS enabled.

This inheritance of the IPS setting can cause performance problems if the RTP traffic volume is high since IPS checking may reduce performance in some cases. Also if you are using network processor (NP) interfaces to accelerate VoIP performance, when IPS is enabled for the pinhole traffic is diverted to the IPS and as a result is not accelerated by the network processors.

 

You can use the following CLI command to disable IPS for the RTP pinhole traffic.

config voip profile edit VoIP_Pro_Name

config sip

set ips-rtp disable end

end

SIP and HA–session failover and geographic redundancy

Leave a reply

SIP and HA–session failover and geographic redundancy

FortiGate high availability supports SIP session failover (also called stateful failover) for active-passive HA. To support SIP session failover, create a standard HA configuration and select the Enable Session Pick-up option.

SIP session failover replicates SIP states to all cluster units. If an HA failover occurs, all in progress SIP calls (setup complete) and their RTP flows are maintained and the calls will continue after the failover with minimal or no interruption.

SIP calls being set up at the time of a failover may lose signaling messages. In most cases the SIP clients and servers should use message retransmission to complete the call setup after the failover has completed. As a result, SIP users may experience a delay if their calls are being set up when an HA a failover occurs. But in most cases the call setup should be able to continue after the failover.

In some cases, failover during call teardown can result in hanging RTP connections which can accumulate over time and use up system memory. If this becomes a problem, you can set a time for the call-keepalive SIP VoIP profile setting. The FortiGate will then terminate calls with no activity after the time limit is exceeded.

Range is 1 to 10,080 seconds. This options should be used with caution because it results in extra FortiGate CPU overhead and can cause delay/jitter for the VoIP call. Also, the FortiGate unit terminates the call without sending SIP messages to end the call. And if the SIP endpoints send SIP messages to terminate the call they will be blocked by the FortiGate unit if they are sent after the FortiGate unit terminates the call.

 

SIP geographic redundancy

Maintains a active-standby SIP server configuration, which even supports geographical distribution. If the active SIP server fails (missing SIP heartbeat messages or SIP traffic) FortiOS will redirect the SIP traffic to a secondary SIP server. SIP geographic redundancy

Geographic redundancy  
 

Primary Server

  

Secondary Server

  

Primary Server

Fa

  

Secondary Server

ilover
 

SSIPIP SSeervrveer r

  

SIPSIP SeSrveervrer

  

SIP Server

  

SIP Server

 

SIP

SIP Heartbeat (SIP OPTION)

SIP Heartbeat

SIP Heartbeat

Failover

SIP

 

SIP is forwarded to primary SIP Server, as long as it’s successfully sending heartbeats

 

SIP Signaling Firewall

In the case of SIP heartbeat absence, the SFW will forward the SIP traffic to the secondary SIP Server.

 

SIP Signaling Firewall

Supporting geographic redundancy when blocking OPTIONS messages

For some geographic redundant SIP configurations, the SIP servers may use SIP OPTIONS messages as heartbeats to notify the FortiGate unit that they are still operating (or alive). This is a kind of passive SIP monitoring mechanism where the FortiGate unit isn’t actively monitoring the SIP servers and instead the FortiGate unit passively receives and analyzes OPTIONS messages from the SIP servers.

If FortiGate units block SIP OPTIONS messages because block-options is enabled, the configuration may fail to operate correctly because the OPTIONS messages are blocked by one or more FortiGate units.

However, you can work around this problem by enabling the block-geo-red-options application control list option. This option causes the FortiGate unit to refresh the local SIP server status when it receives an OPTIONS message before dropping the message. The end result is the heartbeat signals between geographically redundant SIP servers are maintained but OPTIONS messages do not pass through the FortiGate unit.

 

Use the following command to block OPTIONS messages while still supporting geographic redundancy:

 

config voip profile edit VoIP_Pro_Name

config sip

set block-options disable

set block-geo-red-options enable end

end

 

The block-options option setting overrides the block-geo-red-options option. If block-options is enabled the FortiGate unit only blocks SIP OPTIONS messages and does not refresh local SIP server status.

 

 

Support for RFC 2543-compliant branch parameters

RFC 3261 is the most recent SIP RFC, it obsoletes RFC 2543. However, some SIP implementations may use RFC 2543-compliant SIP calls.

The rfc2543-branch VoIP profile option allows the FortiGate unit to support SIP calls that include an RFC 2543-compliant branch parameter in the SIP Via header. This option also allows FortiGate units to support SIP calls that include Via headers that are missing the branch parameter.

 

config voip profile edit VoIP_Pro_Name

config sip

set rfc2543-branch enable end

end

Inspecting SIP over SSL/TLS (secure SIP)

Leave a reply

Inspecting SIP over SSL/TLS (secure SIP)

Some SIP phones and SIP servers can communicate using SSL or TLS to encrypt the SIP signalling traffic. To allow SIP over SSL/TLS calls to pass through the FortiGate unit, the encrypted signalling traffic has to be unencrypted and inspected. To do this, the FortiGate SIP ALG intercepts and unencrypts and inspects the SIP packets. The packets are then re-encrypted and forwarded to their destination.

Normally SIP over SSL/TLS uses port 5061. You can use the following command to change the port that the FortiGate listens on for SIP over SSL/TLS sessions to port 5066:

config system settings set sip-ssl-port 5066

end

The SIP ALG supports full mode SSL/TLS only. Traffic between SIP phones and the FortiGate unit and between the FortiGate unit and the SIP server is always encrypted.

You enable SSL/TLS SIP communication by enabling SSL mode in a VoIP profile. You also need to install the SIP server and client certificates on your FortiGate unit and add them to the SSL configuration in the VoIP profile.

 

SIP over SSL/TLS between a SIP phone and a SIP server

SIP Phone

SIP server

TCP session established between SIP phone and SIP server

TCP SYNC TCP SYNC ACK

TCP ACK

SSL/TLS session established between SIP phone and FortiGate unit

TLS ClientHello

TLS Handshake Messages

TLS Finished

SIP Phone sends a secure REGSTER message to the FortiGate unit

SSL/TLS session established between FortiGate unit and SIP Server

TLS ClientHello

TLS Handshake Messages

TLS Finished

The FortiGate unit decrypts the REGSTER message, inspects it, re-encrypts it, and forwards  it to the SIP server

The FortiGate unit decrypts the 200 OK response, inspects  it, re-encrypts it, and forwards  it to the phone

6. The SIP server sends a secure 200 OK response to the SIP Phone

Other than enabling SSL mode and making sure the security policies accept the encrypted traffic, the FortiGate configuration for SSL/TLS SIP is the same as any SIP configuration. SIP over SSL/TLS is supported for all supported SIP configurations.

 

Adding the SIP server and client certificates

A VoIP profile that supports SSL/TLS SIP requires one certification for the SIP server and one certificate that is used by all of the clients. Use the following steps to add these certificates to the FortiGate unit. Before you start, make sure the client and server certificate files and their key files are accessible from the management computer.

1. Go to System > Certificates and select Import.

2. Set Type to Certificate.

3. Browse to the Certificate file and the Key file and select OK.

4. Enter a password for the certificate and select OK.

The certificate and key are uploaded to the FortiGate unit and added to the Local Certificates List.

5. Repeat to upload the other certificate.

The certificates are added to the list of Local Certificates as the filenames you uploaded. You can add comments to make it clear where its from and how it is intended to be used.

 

Adding SIP over SSL/TLS support to a VoIP profile

Use the following commands to add SIP over SSL/TLS support to the default VoIP profile. The following command enables SSL mode and adds the client and server certificates and passwords, the same ones you entered when you imported the certificates:

config voip profile edit default

config sip

set ssl-mode full

set ssl-client-certificate “Client_cert” set ssl-server-certificate “Server_cert” set ssl-auth-client “check-server”

set ssl-auth-server “check-server-group” end

end

Other SSL mode options are also available:

 

ssl-send-empty-frags {disable | enable}

Enable to send empty fragments to avoid CBC IV attacks. Com- patible with SSL 3.0 and TLS 1.0 only. Default is enable.

 

ssl-client-renegotiation {allow | deny | secure}

Control how the ALG responds when a client attempts to rene- gotiate the SSL session. You can allow renegotiation or block sessions when the client attempts to renegotiate. You can also select secure to reject an SSL connection that does not sup- port RFC 5746 secure renegotiation indication. Default is allow.

ssl-algorithm {high | low | medium}

Select the relative strength of the algorithms that can be selec- ted. You can select high, the default, to allow only AES or

3DES, medium, to allow AES, 3DES, or RC4 or low, to allow AES, 3DES, RC4, or DES.

 

ssl-pfs {allow | deny | regqure}

Select whether to allow, deny, or require perfect forward secrecy (PFS). Default is allow.

 

ssl-min-version {ssl-3.0 | tls-1.0 | tls-1.1}

Select the minimum level of SSL support to allow. The default is ssl-3.0.
ssl-max-version {ssl-3.0 | tls-1.0 | tls-1.1}

Select the maximum level of SSL support to allow. The default is tls-1.1.

SIP rate limiting

Leave a reply

SIP rate limiting

Configurable threshold for SIP message rates per request method. Protects SIP servers from SIP overload and DoS attacks.

 

SIP rate limiting

INVITE REGISTER

SUBSCRIBE

  • SIP message rate limitation
  • Individually configurable per SIP

method

  • When threshold is hit additional messages with this method will be

 

SIP

NOTIFY REFER UPDATE OPTIONS MESSAGE ACK

PRACK INFO

SIP

  • Prevents SIP server from getting overloaded by flash crowds or Denial-of-Service attacks.
  • May block some methods at all
  • Can be disabled (unlimited rate)

 

FortiGate units support rate limiting for the following types of VoIP traffic:

  • Session Initiation Protocol (SIP)
  • Skinny Call Control Protocol (SCCP) (most versions)
  • Session Initiation Protocol for Instant Messaging and Presence Leveraging Extensions (SIMPLE).

You can use rate limiting of these VoIP protocols to protect the FortiGate unit and your network from SIP and SCCP Denial of Service (DoS) attacks. Rate limiting protects against SIP DoS attacks by limiting the number of SIP REGISTER and INVITE requests that the FortiGate unit receives per second. Rate limiting protects against SCCP DoS attacks by limiting the number of SCCP call setup messages that the FortiGate unit receives per minute.

You configure rate limiting for a message type by specifying a limit for the number of messages that can be received per second. The rate is limited per security policy. When VoIP rate limiting is enabled for a message type, if the a single security policy accepts more messages per second than the configured rate, the extra messages are dropped and log messages are written when the messages are dropped.

Use the following command to configure a VoIP profile to limit the number of INVITE messages accepted by each security policy that the VoIP profile is added to 100 INVITE messages a second:

config voip profile edit VoIP_Pro_Name

config sip

set invite-rate 100 end

end

If you are experiencing denial of service attacks from traffic using these VoIP protocols, you can enable VoIP rate limiting and limit the rates for your network. Limit the rates depending on the amount of SIP and SCCP traffic that you expect the FortiGate unit to be handling. You can adjust the settings if some calls are lost or if the amount of SIP or SCCP traffic is affecting FortiGate unit performance.

The table below lists all of the VoIP profile SIP rate limiting options. All of these options are set to 0 so are disabled by default.

Blocking SIP OPTIONS messages may prevent a redundant configuration from oper- ating correctly. See Supporting geographic redundancy when blocking OPTIONS mes- sages on page 2822 for information about resolving this problem.

Options for SIP rate limiting

SIP request mes- sage

Rate Limiting CLI Option

ACK                           ack-rate

BYE                           bye-rate

Cancel                       cancel-rate

INFO                          info-rate

SIP request mes- sage

 

Rate Limiting CLI Option

INVITE                       invite-rate

Message                   message-rate

Notify                        notify-rate

Options                     options-rate

PRACK                      prack-rate

Publish                     publish-rate

Refer                         refer-rate

Register                    register-rate

Subscribe                 subscribe-rate

Update                      update-rate

 

Limiting the number of SIP dialogs accepted by a security policy

In addition to limiting the rates for receiving SIP messages, you can use the following command to limit the number of SIP dialogs (or SIP calls) that the FortiGate unit accepts.

config voip profile edit VoIP_Pro_Name

config sip

set max-dialogs 2000 end

end

This command sets the maximum number of SIP dialogs that can be open for SIP sessions accepted by any security policy that you add the VoIP profile to. The default setting of 0 does not limit the number of dialogs. You can add a limit to control the number of open dialogs and raise and lower it as required. You might want to limit the number of open dialogs for protection against SIP-based attackers opening large numbers of SIP dialogs.

Every dialog takes memory and FortiGate CPU resources to process. Limiting the number of dialogs may improve the overall performance of the FortiGate unit. Limiting the number of dialogs will not drop calls in progress but may prevent new calls from connecting.

Blocking SIP request messages

Leave a reply

Blocking SIP request messages

You may want to block different types of SIP requests:

  • to prevent SIP attacks using these messages.
  • If your SIP server cannot process some SIP messages because of a temporary issue (for example a bug that crashes or compromises the server when it receives a message of a certain type).
  • Your SIP implementation does not use certain message types.

When you enable message blocking for a message type in a VoIP profile, whenever a security policy containing the VoIP profile accepts a SIP message of this type, the SIP ALG silently discards the message and records a log message about the action.

Use the following command to configure a VoIP profile to block SIP CANCEL and Update request messages:

config voip profile edit VoIP_Pro_Name

config sip

set block-cancel enable set block-update enable

end end

SIP uses a variety of text-based messages or requests to communicate information about SIP clients and servers to the various components of the SIP network. Since SIP requests are simple text messages and since the requests or their replies can contain information about network components on either side of the FortiGate unit, it may be a security risk to allow these messages to pass through.

The following table lists all of the VoIP profile SIP request message blocking options. All of these options are disabled by default.

Blocking SIP OPTIONS messages may prevent a redundant configuration from oper- ating correctly. See Supporting geographic redundancy when blocking OPTIONS mes- sages on page 2822 for information about resolving this problem.

 

Options for blocking SIP request messages

SIP request mes- sage

SIP message blocking CLI Option

ACK                           block-ack

BYE                           block-bye

Cancel                       block-cancel

INFO                          block-info

INVITE                       block-invite

Message                   block-message

Notify                        block-notify

SIP request mes- sage

 

SIP message blocking CLI Option

Options                     block-options

PRACK                      block-prack

Publish                     block-publish

Refer                         block-refer

Register                    block-register

Subscribe                 block-subscribe

Update                      block-update

Deep SIP message inspection

Leave a reply

Deep SIP message inspection

Deep SIP message syntax inspection (also called Deep SIP header inspection or SIP fuzzing protection) provides protection against malicious SIP messages by applying SIP header and SDP profile syntax checking. SIP Fuzzing attacks can be used by attackers to discover and exploit vulnerabilities of a SIP entity (for example a SIP proxy server). Most often these attacks could crash or compromise the SIP entity.

 

Deep SIP message inspection

SIP message

Malformed SIP header

eld detected

FortiCarrier

SIP

PAacrstiever

Blade

Message compliant

Yes: Check next

header eld

  • Checks the SIP request message

Request-line

  •  Checks the following SIP

header fields:

  • Allow, Call-id, Contact, Content- length, Content-type, CSeq, Expires, From, Max-Forwards,

P-asserted-identity, Rack,

Yes: Return SIP client error Response message

400 Bad Request or

413 Request entity too large

Configured:

“Pass” ?

No

Configured:

“Respond”

?

If no

Record-Route, Route, Rseq, To, Via

  • Checks all SDP profile lines
  • Configurable header and body length checks
  • Optional logging of message violations

 

Discard message

Deep SIP message inspection checks the syntax of each SIP header and SDP profile line to make sure they conform to the syntax defined in the relevant RFC and IETF standard. You can also configure the SIP ALG to inspect for:

  • Unknown SIP message types (message types not defined in a SIP RFC) this option is enabled by default and can be disabled. When enabled unknown message types are discarded. Configured using the block-unknown option.
  • Unknown line types (message line types that are not defined in any SIP or SDP RFC). Configured using the unknown-header option.
  • Messages that are longer than a configured maximum size. Configured using the max-body-length option.
  • Messages that contain one or more lines that are longer that a set maximum line length (default 998 characters). Configured using the max-line-length option.

 

Actions taken when a malformed message line is found

When a malformed message line or other error is found the SIP ALG can be configured to discard the message containing the error, pass the message without any other actions, or responding to the message with a 400 Bad Request or 413 Request entity too large client error SIP response message and then discard the message. (For information about client error SIP response messages, see “Client error”.)

If a message line is longer than the configured maximum, the SIP ALG sends the following message:

SIP/2.0 413 Request Entity Too Large, <optional_info>

If a message line is incorrect or in an unknown message line is found, the SIP ALG sends the following message:

SIP/2.0 400 Bad Request, <optional_info>

The <optional_info> provides more information about why the message was rejected. For example, if the SIP ALG finds a malformed Via header line, the response message may be:

SIP/2.0 400 Bad Request, malformed Via header

If the SIP ALG finds a malformed message line, and the action for this message line type is discard, the message is discarded with no further checking or responses. If the action is pass, the SIP ALG continues parsing the SIP message for more malformed message lines. If the action is respond, the SIP ALG sends the SIP response message and discards the message containing the malformed line with no further checking or response. If only malformed message line types with action set to pass are found, the SIP ALG extracts as much information as possible from the message (for example for NAT and opening pinholes, and forwards the message to its destination).

If a SIP message containing a malformed line is discarded the SIP ALG will not use the information in the message for call processing. This could result in the call being terminated. If a malformed line in a SIP message includes information required for the SIP call that the SIP ALG cannot interpret (for example, if an IP address required for SIP NAT is corrupted) the SIP ALG may not be able to continue processing the call and it could be terminated. Discarded messages are counted by SIP ALG static message counters.

 

Logging and statistics

To record a log message each time the SIP ALG finds a malformed header, enable logging SIP violations in a VoIP profile. In all cases, when the SIP ALG finds an error the FortiGate unit records a malformed header log message that contains information about the error. This happens even if the action is set to pass.

If, because of recording log messages for deep message inspection, the CPU performance is affected by a certain amount, the FortiGate unit records a critical log message about this event and stops writing log messages for deep SIP message inspection.

The following information is recorded in malformed header messages:

  • The type of message line in which the error was found.
  • The content of the message line in which the error was found (it will be truncated if it makes the log message too long)
  • The column or character number in which the error was found (to make it easier to determine what caused the error)

 

Deep SIP message inspection best practices

Because of the risks imposed by SIP header attacks or incorrect data being allowed and because selecting drop or respond does not require more CPU overhead that pass you would want to set all tests to drop or respond. However, in some cases malformed lines may be less of a threat or risk. For example, the SDP i= does not usually contain information that is parsed by any SIP device so a malformed i= line may not pose a threat.

You can also used the pre-defined VoIP profiles to apply different levels of deep message inspection. The default VoIP profile sets all deep message inspection options to pass and the strict VoIP profile sets all deep message inspection options to discard. From the CLI you can use the clone command to copy these pre-defined VoIP profiles and then customize them for your requirements.

 

Configuring deep SIP message inspection

You configure deep SIP message inspection in a VoIP profile. All deep SIP message inspection options are available only from the CLI.

Enter the following command to configure deep SIP message inspection to discard messages with malformed Request-lines (the first line in a SIP request message):

config voip profile edit VoIP_Pro_Name

config sip

set malformed-request-line respond end

end

 

You cannot configure message inspection for the Status-line, which is the first line in a SIP response message.

The following table lists the SIP header lines that the SIP ALG can inspect and the CLI command for configuring the action for each line type. The table also lists the RFC that the header line is defined in.

 

SIP header lines that the SIP ALG can inspect for syntax errors

SIP Header line VoIP profile option RFC
 

Allow

  

malformed-header-allow

  

RFC 3261
 

Call–ID

  

malformed-header-call-id

  

RFC 3261
 

Contact

  

malformed-header-contact

  

RFC 3261
 

Content-Length

  

malformed-header-content-length

  

RFC 3261
 

Content-Type

  

malformed-header-content-type

  

RFC 3261
 

CSeq

  

malformed-header-cseq

  

RFC 3261
 

Expires

  

malformed-header-expires

  

RFC 3261
 

From

  

malformed-header-from

  

RFC 3261
 

Max-forwards

  

malformed-header-max-forwards

  

RFC 3261
 

P–Asserted–Iden– tity

  

malformed-header-p-asserted-identity

  

RFC 3325
 

RAck

  

malformed-header-rack

  

RFC 3262
 

Record–Route

  

malformed-header-record-route

  

RFC 3261
 

Route

  

malformed-header-route

  

RFC 3261

 

SIP Header line VoIP profile option RFC
 

RSeq

  

malformed-header-rseq

  

RFC 3262
 

To

  

malformed-header-to

  

RFC 3261
 

Via

  

malformed-header-via

  

RFC 3261

The table below lists the SDP profile lines that the SIP ALG inspects and the CLI command for configuring the action for each line type. SDP profile lines are defined by RFC 4566 and RFC 2327.

 

SDP profile lines that the SIP ALG can inspect for syntax errors

Attribute                  VoIP profile option

a=                              malformed-header-sdb-a

b=                              malformed-header-sdp-b

c=                              malformed-header-sdp-c

i=                               malformed-header-sdp-i

k=                              malformed-header-sdp-k

m=                             malformed-header-sdp-m

o=                              malformed-header-sdp-o

r=                               malformed-header-sdp-r

s=                              malformed-header-sdp-s

t=                               malformed-header-sdp-t

v=                              malformed-header-sdp-v

z=                               malformed-header-sdp-z

 

Discarding SIP messages with some malformed header and body lines

Enter the following command to configure deep SIP message inspection to discard SIP messages with a malformed Via line, a malformed route line or a malformed m= line but to pass messages with a malformed i= line or a malformed Max-Forwards line

config voip profile edit VoIP_Pro_Name

config sip

set malformed-header-via discard set malformed-header-route discard

set malformed-header-sdp-m discard set malformed-header-sdp-i pass

set malformed-header-max-forwards pass end

end

 

Discarding SIP messages with an unknown SIP message type

Enter the following command to discard SIP messages with an unknown SIP message line type as defined in all current SIP RFCs:

config voip profile edit VoIP_Pro_Name

config sip

set unknown-header discard end

end

 

Discarding SIP messages that exceed a message size

Enter the following command to set the maximum size of a SIP message to 200 bytes. Messages longer than 200 bytes are discarded.

config voip profile edit VoIP_Pro_Name

config sip

set max-body-length 200 end

end

The max-body-length option checks the value in the SIP Content-Length header line to determine body length. The Content-Length can be larger than the actual size of a SIP message if the SIP message content is split over more than one packet. SIP message sizes vary widely. The size of a SIP message can also change with the addition of Via and Record-Route headers as the message is transmitted between users and SIP servers.

 

Discarding SIP messages with lines longer than 500 characters

Enter the following command to set the length of a SIP message line to 500 characters and to block messages that include lines with 500 or more characters:

config voip profile edit VoIP_Pro_Name

config sip

set max-line-length 500

set block-long-lines enable end

end

FortiOS 5.6 Beta 2 NGFW Policy

6 Replies

NGFW Policy mode is going to make a bunch of engineers smile ear to ear. There are a lot of cool features coming in 5.6 that includes a much improved security fabric (with audit capabilities) as well as dashboard tweaks, source and destination NAT on the same policy etc. The one feature I have been adamantly submitting to Fortinet over the past few years has been NGFW style policy. Check out the video below where I go into detail!