Enhancing SIP pinhole security

You can use the strict-register option in a SIP VoIP profile to open smaller pinholes. This option is enabled by default on the default VoIP profiles and in all new VoIP profiles that you create.

As shown below, when FortiGate is protecting a SIP server on a private network, the FortiGate does not have to open a pinhole for the SIP server to send INVITE requests to a SIP Phone on the Internet after the SIP Phone has registered with the server.

FortiGate protecting a SIP server on a private network

In the example, a client (SIP Phone A) sends a REGISTER request to the SIP server with the following information:

Client IP: 10.31.101.20

Server IP: 10.21.101.50

Port: UDP (x,5060)

REGISTER Contact: 10.31.101.20:y Where x and y are ports chosen by Phone A.

As soon as the server sends the 200 OK reply it can forward INVITE requests from other SIP phones to SIP Phone A. If the SIP proxy server uses the information in the REGISTER message received from SIP Phone A the INVITE messages sent to Phone A will only get through the FortiGate if a policy has been added to allow the server to send traffic from the private network to the Internet. Or the SIP ALG must open a pinhole to allow traffic from the server to the Internet. In most cases the FortiGate is protecting the SIP server so there is no reason not to add a security policy to allow the SIP server to send outbound traffic to the Internet.

In a typical SOHO scenario, shown below, SIP Phone A is being protected from the Internet by a FortiGate. In most cases the FortiGate would not allow incoming traffic from the Internet to reach the private network. So the only way that an INVITE request from the SIP server can reach SIP Phone A is if the SIP ALG creates an incoming pinhole. All pinholes have three attributes:

(source address, destination address, destination port)

SOHO configuration, FortiGate protecting a network with SIP phones

Enhancing SIP pinhole security                Adding the original IP address and port to the SIP message header after NAT

The more specific a pinhole is the more secure it is because it accept less traffic. In this situation, the pinhole would be more secure if it only accepted traffic from the SIP server. This is what happens if strict-register is enabled in the VoIP profile that accepts the REGISTER request from Phone A.

(SIP server IP address, client IP address, destination port)

If strict-register is disabled (the default configuration) the pinhole is set up with the following attributes

(ANY IP address, client IP address, destination port)

This pinhole allows connections through the FortiGate from ANY source address which is a much bigger and less secure pinhole. In most similar network configurations you should enable strict-register to improve pinhole security.

Enabling strict-register can cause problems when the SIP registrar and SIP proxy server are separate entities with separate IP addresses.

Enter the following command to enable strict-register in a VoIP profile.

config voip profile edit Profile_name config sip set strict-register enable

end

Adding the original IP address and port to the SIP message header after NAT

In some cases your SIP configuration may require that the original IP address and port from the SIP contact request is kept after NAT. For example, the original SIP contact request could include the following:

Contact: <sip:0150302438@172.20.120.110:5060>;

After the packet goes through the FortiGate and NAT is performed, the contact request could normally look like the following (the IP address translated to a different IP address and the port to a different port):

Contact: <sip:0150302438@10.10.10.21:33608>;

You can enable register-contact-trace in a VoIP profile to have the SIP ALG add the original IP address and port in the following format:

Contact: <sip:0150302438@<nated-ip>:<nated-port>;o=<original-ip>: <original-port>>; So the contact line after NAT could look like the following:

Contact: <sip:0150302438@10.10.10.21:33608;o=172.20.120.110:5060>; Enter the following command to enable keeping the original IP address and port:

config voip profile edit Profile_name config sip set register-contract-trace enable

end

Translating SIP sessions to multiple destination ports

You can use a load balance virtual IP to translate SIP session destination ports to a range of destination ports. In this example the destination port is translated from 5060 to the range 50601 to 50603. This configuration can be used if your SIP server is configured to receive SIP traffic on multiple ports.

Example translating SIP traffic to multiple destination ports

To translated SIP sessions to multiple destination ports

1. Add the load balance virtual IP.

Adding the original IP address and port to the SIP message header after NAT

This virtual IP forwards traffic received at the port1 interface for IP address 172.20.120.20 and destination port 5060 to the SIP server at IP address 192.168.10.20 with destination port 5061.

config firewall vip edit “sip_port_ldbl_vip” set type load-balance set portforward enable set protocol tcp set extip 172.20.120.20 set extport 5060 set extintf “port1” set mappedip 192.168.10.20 set mappedport 50601-50603

set comment “Translate SIP destination port range”

end

2. Add a security policy that includes the virtual IP and VoIP profile. config firewall policy edit 1 set srcintf “port1” set dstintf “port2” set srcaddr “all” set dstaddr “sip_port_ldbl_vip” set action accept set schedule “always” set service “ANY” set utm-status enable set voip-profile default

set comments “Translate SIP destination port” end