Hosted NAT traversal

With the increase in the use of VoIP and other media traffic over the Internet, service provider network administrators must defend their networks from threats while allowing voice and multimedia traffic to flow transparently between users and servers and among users. A common scenario could involve providing SIP VoIP services for customers with SIP phones installed behind NAT devices that are not SIP aware. NAT devices that are not SIP aware cannot translate IP addresses in SIP headers and SDP lines in SIP packets but can and do perform source NAT on the source or addresses of the packets. In this scenario the user’s SIP phones would communicate with a SIP proxy server to set up calls between SIP phones. Once the calls are set up RTP packets would be communicated directly between the phones through each user’s NAT device.

The problem with this configuration is that the SIP headers and SDP lines in the SIP packets sent from the phones and received by the SIP proxy server would contain the private network addresses of the VoIP phones that would not be routable on the service provider network or on the Internet. One solution could be to for each customer to install and configure SIP aware NAT devices. If this is not possible, another solution requires implement hosted NAT traversal.

In a hosted NAT traversal (HNT) configuration, a FortiGate is installed between the NAT device and the SIP proxy server and configured with a VoIP profile that enables SIP hosted NAT traversal. Security policies that include the VoIP profile also support destination NAT using a firewall virtual IP. When the SIP phones connect to the SIP server IP address the security policy accepts the SIP packets, the virtual IP translates the destination addresses of the packets to the SIP server IP address, and the SIP ALG NAT traversal configuration translates the source IP addresses on the SIP headers and SDP lines to the source address of the SIP packets (which would be the external IP address of the NAT devices). The SIP server then sees the SIP phone IP address as the external IP address of the NAT device. As a result SIP and RTP media sessions are established using the external IP addresses of the NAT devices instead of the actual IP addresses of the SIP phones.

Configuration example: Hosted NAT traversal for calls between SIP Phone A and SIP Phone B

FortiGate SIP Hosted NAT Traversal configuration

Configuration example: Hosted NAT traversal for calls between SIP Phone A and SIP Phone B

The following address translation takes place to allow a SIP call from SIP Phone A to SIP Phone B in the above diagram.

5. SIP Phone A sends a SIP Invite message to the SIP server. Packet source IP address: 192.168.10.1, destination IP address: 10.21.101.10.
6. The SIP packets are received by the NAT device which translates the source address of the SIP packets from 192.168.10.1 to 10.11.101.20.
7. The SIP packets are received by the FortiGate which translates the packet destination IP address to 10.30 120.20. The SIP ALG also translates the IP address of the SIP phone in the SIP header and SDP lines from 192.168.10.1 to 10.11.101.20.
8. The SIP server accepts the Invite message and forwards it to SIP Phone B at IP address10.11.101.20. The SIP server has this address for SIP Phone B because SIP packets from SIP Phone B have also been translated using the hosted NAT traversal configuration of the SIP ALG.
9. When the SIP call is established, the RTP session is between 10.11.101.10 and 10.11.101.20 and does not pass through the FortiGate. The NAT devices translated the destination address of the RTP packets to the private IP addresses of the SIP phones.

General configuration steps

The following general configuration steps are required for this destination NAT SIP configuration. This example uses the default VoIP profile.

1. Add a VoIP profile that enables hosted NAT translation.
2. Add a SIP proxy server firewall virtual IP.
3. Add a firewall address for the SIP proxy server on the private network.
4. Add a destination NAT security policy that accepts SIP sessions from the Internet destined for the SIP proxy server virtual IP and translates the destination address to the IP address of the SIP proxy server on the private network.
5. Add a security policy that accepts SIP sessions initiated by the SIP proxy server and destined for the Internet.

Configuration steps – GUI

To add the SIP proxy server firewall virtual IP

1. Go to Policy & Objects > Virtual IPs.
2. Add the SIP proxy server virtual IP.

To add a firewall address for the SIP proxy server

1. Go to Policy & Objects > Addresses.
2. Add the following for the SIP proxy server:

Configuration example: Hosted NAT traversal for calls between SIP Phone A and SIP Phone B

To add the security policies

1. Go to Policy & Objects > IPv4 Policy.
2. Add a destination NAT security policy that includes the SIP proxy server virtual IP that allows Phone B (and other SIP phones on the Internet) to send SIP request messages to the SIP proxy server.

3. Turn on NAT and select Use Outgoing Interface Address.
4. Turn on VoIP and select the default VoIP profile.
5. Select OK.
6. Add a source NAT security policy to allow the SIP proxy server to send SIP request messages to Phone B and the

Internet:

7. Turn on NAT and select Use Outgoing Interface Address.
8. Turn on VoIP and select the default VoIP profile.
9. Select OK.

Configuration steps – CLI

To add a VoIP profile that enables hosted NAT translation

1. Enter the following command to add a VoIP profile named HNT that enables hosted NAT traversal. This command shows how to clone the default VoIP profile and enable hosted NAT traversal.

config voip profile

Hosted NAT traversal       Configuration example: Hosted NAT traversal for calls between SIP Phone A and SIP Phone B

clone default to HNT edit HNT config sip set hosted-nat-traversal enable

end

end

To add the SIP proxy server firewall virtual IP and firewall address

1. Enter the following command to add the SIP proxy server firewall virtual IP. config firewall vip edit SIP_Proxy_VIP set type static-nat set extip 10.21.101.10 set mappedip 10.30.120.20 set extintf port1

end

2. Enter the following command to add the SIP proxy server firewall address. config firewall address edit SIP_Proxy_Server set associated interface port2 set type ipmask

set subnet 10.30.120.20 255.255.255.255

end

To add security policies

1. Enter the following command to add a destination NAT security policy that includes the SIP proxy server virtual IP that allows Phone A to send SIP request messages to the SIP proxy server.

config firewall policy edit 0 set srcintf port1 set dstintf port2 set srcaddr all set dstaddr SIP_Proxy_VIP set action accept set schedule always set service SIP set nat enable set utm-status enable

set profile-protocol-options default set voip-profile HNT

end

2. Enter the following command to add a source NAT security policy to allow the SIP proxy server to send SIP request messages to Phone B:

config firewall policy edit 0 set srcintf port2 set dstintf port1 set srcaddr SIP_Proxy_Server

set dstaddr all set action accept set schedule always set service SIP

Hosted NAT traversal for calls between SIP Phone A and SIP Phone C

set nat enable set utm-status enable

set profile-protocol-options default set voip-profile default end

Hosted NAT traversal for calls between SIP Phone A and SIP Phone C

The following address translation takes place to allow a SIP call from SIP Phone A to SIP Phone C in the previous diagram.

1. SIP Phone A sends a SIP Invite message to the SIP server. Packet source IP address: 192.168.10.1 and destination IP address: 10.21.101.10.
2. The SIP packets are received by the NAT device which translates the source address of the SIP packets from 192.168.10.1 to 10.11.101.20.
3. The SIP packets are received by the FortiGate which translates the packet destination IP address to 10.30 120.20. The SIP ALG also translates the IP address of the SIP phone in the SIP header and SDP lines from 192.168.10.1 to 10.11.101.20.
4. The SIP server accepts the Invite message and forwards it to SIP Phone C at IP address 172.20.120.30. The SIP server has this address for SIP Phone C because SIP packets from SIP Phone C have also been translated using the hosted NAT traversal configuration of the SIP ALG.
5. When the SIP call is established, the RTP session is between 10.11.101.10 and 172.20.120.30. The packets pass through the FortiGate which performs NAT as required.

Restricting the RTP source IP

Use the following command in a VoIP profile to restrict the RTP source IP to be the same as the SIP source IP when hosted NAT traversal is enabled.

config voip profile edit VoIP_HNT config sip set hosted-nat-traversal enable set hnt-restrict-source-ip enable

end end

SIP over IPv6

FortiGates operating in NAT/Route and in transparent mode support SIP over IPv6. The SIP ALG can process SIP messages that use IPv6 addresses in the headers, bodies, and in the transport stack. The SIP ALG cannot modify the IPv6 addresses in the SIP headers so FortiGates cannot perform SIP or RTP NAT over IPv6 and also cannot translate between IPv6 and IPv4 addresses.

In the scenario shown in the figure below, a SIP phone connects to the Internet through a FortiGate operating. The phone and the SIP and RTP servers all have IPv6 addresses.

The FortiGate has IPv6 security policies that accept SIP sessions. The SIP ALG understands IPv6 addresses and can forward IPv6 sessions to their destinations. Using SIP application control features the SIP ALG can also apply rate limiting and other settings to SIP sessions.

SIP support for IPv6

To enable SIP support for IPv6 add an IPv6 security policy that accepts SIP packets and includes a VoIP profile.

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

• Checks the SIP request message Request-line
• Checks the following SIP header fields:
• Allow, Call-id, Contact, Contentlength, Content-type, CSeq, Expires, From, Max-Forwards,

P-asserted-identity, Rack,

Record-Route, Route, Rseq, To, Via

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

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
• Unknown line types (message line types that are not defined in any SIP or SDP RFC). Configured using the unknown-header
• Messages that are longer than a configured maximum size. Configured using the max-body-length
• 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

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 on page 27.)

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 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 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) l 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 Deep SIP message inspection best practices

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

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

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

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

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). l 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, 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 operating correctly. See Supporting geographic redundancy when blocking OPTIONS messages on page 113 for information about resolving this problem.

Options for blocking SIP request messages

SIP rate limiting

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

SIP rate limiting

FortiGates support rate limiting for the following types of VoIP traffic:

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

You can use rate limiting of these VoIP protocols to protect the FortiGate 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 receives per second. Rate limiting protects against SCCP

DoS attacks by limiting the number of SCCP call setup messages that the FortiGate receives per minute.

SIP rate limiting

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 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 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 operating correctly. See Supporting geographic redundancy when blocking OPTIONS messages on page 113 for information about resolving this problem.

Options for SIP rate limiting

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 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. Limiting the number of dialogs will not drop calls in progress but may prevent new calls from connecting.

SIP logging

You can enable SIP logging and logging of SIP violations in a VoIP profile.

config voip profile edit VoIP_Pro_Name config sip set log-call-summary enable set log-violations enable

end

end

To view SIP log messages go to Log & Report > Forward Traffic.

Inspecting SIP over SSL/TLS (secure SIP)

Some SIP phones and SIP servers can communicate using SSL or TLS to encrypt the SIP signaling traffic. To allow SIP over SSL/TLS calls to pass through the FortiGate, the encrypted signaling 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 and between the FortiGate 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 and add them to the SSL configuration in the VoIP profile.

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

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

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.

SIP HA session 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 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 if they are sent after the FortiGate 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. No special configuration is required for geographic redundancy, just standard HA configuration.

Supporting geographic redundancy when blocking OPTIONS messages

Geographic redundancy

SIP and HA–session failover and geographic redundancy

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 that they are still operating (or alive). This is a kind of passive SIP monitoring mechanism where the FortiGate isn’t actively monitoring the SIP servers and instead the FortiGate passively receives and analyzes OPTIONS messages from the SIP servers.

If FortiGates 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 FortiGates.

However, you can work around this problem by enabling the block-geo-red-options application control list option. This option causes the FortiGate 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.

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

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 to support SIP calls that include an

RFC 2543-compliant branch parameter in the SIP Via header. This option also allows FortiGates 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

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 debugging

This chapter includes some information to help with debugging SIP configurations.

SIP debug log format

Assuming that diagnose debug console timestamp is enabled then the following shows the debug that is generated for an INVITE if diag debug appl sip -1 is enabled:

2010-01-04 21:39:59 sip port 26 locate session for 192.168.2.134:5061 -> 172.16.67.192:5060

2010-01-04 21:39:59 sip sess 0x979df38 found for 192.168.2.134:5061 -> 172.16.67.192:5060

2010-01-04 21:39:59 sip port 26 192.168.2.134:5061 -> 172.16.67.192:5060

2010-01-04 21:39:59 sip port 26 read [(0,515)

(494e56495445207369703a73657276696365403139322e3136382e322e3130303a35303630205349502f322e300d0a5669613a2

05349502f322e302f554450203132372e302e312e313a353036313b6272616e63683d7a39684734624b2d363832372d3632302d3

00d0a46726f6d3a2073697070203c7369703a73697070403132372e302e312e313a353036313e3b7461673d36383237534950705

4616730303632300d0a546f3a20737574203c7369703a73657276696365403139322e3136382e322e3130303a353036303e0d0a4 3616c6c2d49443a203632302d36383237403132372e302e312e310d0a435365713a203120494e564954450d0a436f6e746163743 a207369703a73697070403132372e302e312e313a353036310d0a4d61782d466f7277617264733a2037300d0a5375626a6563743 a20506572666f726d616e636520546573740d0a436f6e74656e742d547970653a206170706c69636174696f6e2f7364700d0a436 f6e74656e742d4c656e6774683a20203132390d0a0d0a763d300d0a6f3d757365723120353336353537363520323335333638373 6333720494e20495034203132372e302e312e310d0a733d2d0d0a633d494e20495034203132372e302e312e310d0a743d3020300 d0a6d3d617564696f2036303031205254502f41565020300d0a613d7274706d61703a302050434d552f383030300d0a)(INVITE sip:service@192.168.2.100:5060 SIP/2.0..Via: SIP/2.0/UDP 127.0.1.1:5061;branch=z9hG4bK-6827-620-0..From: sipp

%lt;sip:sipp@127.0.1.1:5061>;tag=6827SIPpTag00620..To: sut

%lt;sip:service@192.168.2.100:5060>..Call-ID: 620-6827@127.0.1.1..CSeq: 1

INVITE..Contact: sip:sipp@127.0.1.1:5061..Max-Forwards: 70..Subject: Performance

Test..Content-Type: application/sdp..Content-Length: 129….v=0..o=user1 53655765 2353687637 IN IP4 127.0.1.1..s=-..c=IN IP4 127.0.1.1..t=0 0..m=audio 6001 RTP/AVP

0..a=rtpmap:0 PCMU/8000..)]

2010-01-04 21:39:59 sip port 26 len 515

2010-01-04 21:39:59 sip port 26 INVITE ‘192.168.2.100:5060’ addr 192.168.2.100:5060

2010-01-04 21:39:59 sip port 26 CSeq: 1 INVITE

2010-01-04 21:39:59 sip port 26 Via: UDP 127.0.1.1:5061 len 14 received 0 rport 0 0 branch ‘z9hG4bK6827-620-0’

2010-01-04 21:39:59 sip port 26 From: ‘sipp ;tag=6827SIPpTag00620’ URI ‘sip:sipp@127.0.1.1:5061’ tag ‘6827SIPpTag00620’

2010-01-04 21:39:59 sip port 26 To: ‘sut ‘ URI ‘sip:service@192.168.2.100:5060’ tag ”

2010-01-04 21:39:59 sip port 26 Call-ID: ‘620-6827@127.0.1.1’

2010-01-04 21:39:59 sip port 26 Contact: ‘127.0.1.1:5061’ addr 127.0.1.1:5061 expires 0

2010-01-04 21:39:59 sip port 26 Content-Length: 129 len 3

2010-01-04 21:39:59 sip port 26 sdp o=127.0.1.1 len=9

2010-01-04 21:39:59 sip port 26 sdp c=127.0.1.1 len=9

2010-01-04 21:39:59 sip port 26 sdp m=6001 len=4

2010-01-04 21:39:59 sip port 26 find call 0 ‘620-6827@127.0.1.1’

2010-01-04 21:39:59 sip port 26 not found

2010-01-04 21:39:59 sip port 26 call 0x97a47c0 open (collision (nil))

2010-01-04 21:39:59 sip port 26 call 0x97a47c0 open txn 0x979f7f8 INVITE dir 0

2010-01-04 21:39:59 sip port 26 sdp i: 127.0.1.1:6001

2010-01-04 21:39:59 sip port 26 policy id 1 is_client_vs_policy 1 policy_dir_rev 0

2010-01-04 21:39:59 sip port 26 policy 1 not RTP policy

2010-01-04 21:39:59 sip port 26 learn sdp from stream address

2010-01-04 21:39:59 sip port 26 call 0x97a47c0 sdp 172.16.67.198:43722

2010-01-04 21:39:59 sip port 26 call 0x97a47c0 txn 0x979f7f8 127.0.1.1:5061 find new address and port

2010-01-04 21:39:59 sip port 26 call 0x97a47c0 txn 0x979f7f8 127.0.1.1:5061 find new address and port

2010-01-04 21:39:59 sip port 26 call 0x97a47c0 txn 0x979f7f8 127.0.1.1:5061 find new address and port

2010-01-04 21:39:59 sip port 30 write 192.168.2.134:5061 -> 172.16.67.192:5060 (13,539) 2010-01-04 21:39:59 sip port 30 write [(13,539)

(494e56495445207369703a73657276696365403137322e31362e36372e3139323a35303630205349502f322e300d0a5669613a2 05349502f322e302f554450203137322e31362e36372e3139383a35323036353b6272616e63683d7a39684734624b2d363832372 d3632302d300d0a46726f6d3a2073697070203c7369703a73697070403137322e31362e36372e3139383a34333732343e3b74616 73d363832375349507054616730303632300d0a546f3a20737574203c7369703a73657276696365403137322e31362e36372e313

9323a353036303e0d0a43616c6c2d49443a203632302d36383237403132372e302e312e310d0a435365713a203120494e5649544

50d0a436f6e746163743a207369703a73697070403137322e31362e36372e3139383a34333732350d0a4d61782d466f727761726 4733a2037300d0a5375626a6563743a20506572666f726d616e636520546573740d0a436f6e74656e742d547970653a206170706 c69636174696f6e2f7364700d0a436f6e74656e742d4c656e6774683a20203133380d0a0d0a763d300d0a6f3d757365723120353 3363535373635203233353336383736333720494e20495034203137322e31362e36372e3139380d0a733d2d0d0a633d494e20495

034203137322e31362e36372e3139380d0a743d3020300d0a6d3d617564696f203433373232205254502f41565020300d0a613d7 274706d61703a302050434d552f383030300d0a)(INVITE sip:service@172.16.67.192:5060 SIP/2.0..Via: SIP/2.0/UDP 172.16.67.198:52065;branch=z9hG4bK-6827-620-0..From: sipp ;tag=6827SIPpTag00620..To: sut ..Call-ID: 6206827@127.0.1.1..CSeq: 1 INVITE..Contact: sip:sipp@172.16.67.198:43725..Max-Forwards: 70..Subject:

Performance Test..Content-Type: application/sdp..Content-Length: 138….v=0..o=user1 53655765 2353687637 IN IP4 172.16.67.198..s=-..c=IN IP4 172.16.67.198..t=0 0..m=audio 43722 RTP/AVP 0..a=rtpmap:0

PCMU/8000..)]

SIP-proxy filter per VDOM

You can use the diagnose sys sip-proxy xxx command in a VDOM to get info about how SIP is operating in each VDOM.

SIP-proxy filter command

Use the diagnose system sip-proxy filter to filter diagnose information for the SIP ALG. The following filters are available:

diag sys sip-proxy filter vd diag sys sip-proxy filter dst-addr4 diag sys sip-proxy filter dst-addr6 diag sys sip-proxy filter dst-port diag sys sip-proxy filter identity-policy diag sys sip-proxy filter negate diag sys sip-proxy filter policy diag sys sip-proxy filter policy-type diag sys sip-proxy filter profile-group diag sys sip-proxy filter src-addr4 diag sys sip-proxy filter src-addr6 diag sys sip-proxy filter src-port diag sys sip-proxy filter vd diag sys sip-proxy filter voip-profile

You can clear, view and negate/invert the sense of a filter using these commands:

diag sys sip-proxy filter clear diag sys sip-proxy filter list diag sys sip-proxy filter negate

SIP debug setting

Control of the SIP debug output is governed by the following command diagnose debug application sip <debug_level_int>

Where the <debug_level_int> is a bitmask and the individual values determine whether the listed items are logged or not. The <debug_level_int> can be:

Display SIP rate-limit data

You can use the diagnose sys sip-proxy meters command to display SIP rate limiting data.

For the following command output rate 1 shows that the current (over last second) measured rate for INVITE/ACK and BYTE was 1 per second, the peak 1 shows that the peak rate recorded is 1 per second, the max 0 shows that there is no maximum limit set, the count 18 indicates that 18 messages were received and drop 0 indicates that none were dropped due to being over the limit.

diag sys sip-proxy meters

sip

sip vd: 0 sip policy: 1 sip identity-policy: 0 sip policy-type: IPv4 sip profile-group: sip dialogs: 18

sip dialog-limit: 0

sip UNKNOWN: rate 0 peak 0 max 0 count 0 drop 0 sip ACK: rate 1 peak 1 max 0 count 18 drop 0 sip BYE: rate 1 peak 1 max 0 count 18 drop 0 sip CANCEL: rate 0 peak 0 max 0 count 0 drop 0 sip INFO: rate 0 peak 0 max 0 count 0 drop 0 sip INVITE: rate 1 peak 1 max 0 count 18 drop 0 sip MESSAGE: rate 0 peak 0 max 0 count 0 drop 0 sip NOTIFY: rate 0 peak 0 max 0 count 0 drop 0 sip OPTIONS: rate 0 peak 0 max 0 count 0 drop 0 sip PRACK: rate 0 peak 0 max 0 count 0 drop 0

sip PUBLISH: rate 0 peak 0 max 0 count 0 drop 0 sip REFER: rate 0 peak 0 max 0 count 0 drop 0 sip REGISTER: rate 0 peak 0 max 0 count 0 drop 0 sip SUBSCRIBE: rate 0 peak 0 max 0 count 0 drop 0 sip UPDATE: rate 0 peak 0 max 0 count 0 drop 0 sip PING: rate 0 peak 0 max 0 count 0 drop 0 sip YAHOOREF: rate 0 peak 0 max 0 count 0 drop 0

In this video I cover how to do some editing, deleting, and creating of Hardware Switches in FortiOS. The GUI leaves a lot of stuff out. Get Flexible and have some fun!

Managing “bring your own device”

FortiOS can control network access for different types of personal mobile devices that your employees bring onto your premises. You can:

• identify and monitor the types of devices connecting to your networks, wireless or wired l use MAC address based access control to allow or deny individual devices l create security policies that specify device types
• enforce endpoint control on devices that can run FortiClient Endpoint Control software This chapter contains the following sections:

Device monitoring

Device groups

Controlling access with a MAC Address Access Control List Security policies for devices

Device monitoring

The FortiGate unit can monitor your networks and gather information about the devices operating on those networks. Collected information includes: l MAC address l IP address l operating system l hostname l user name

l how long ago the device was detected and on which FortiGate interface

You can go to User & Device > Device Inventory to view this information. Mouse-over the Device column for more details.

Depending on the information available, the Device column lists the Alias or the MAC address of the device. For ease in identifying devices, Fortinet recommends that you assign each device an Alias.

Device monitoring is enabled separately on each interface. Device detection is intended for devices directly connected to your LAN ports. If enabled on a WAN port, device detection may be unable to determine the Device monitoring operating system on some devices. Hosts whose device type cannot be determined passively can be found by enabling active scanning on the interface.

You can also manually add devices. This enables you to ensure that a device with multiple interfaces is displayed as a single device.

To configure device monitoring

1. Go to Network > Interfaces.
2. Edit the interface that you want to monitor devices on.
3. In Networked Devices, turn on Device Detection and optionally turn on Active Scanning.
4. Select OK.
5. Repeat steps 2 through 4 for each interface that will monitor devices.

To assign an alias to a detected device or change device information

1. Go to User & Device > Device Inventory and edit the device entry.
2. Enter an Alias such as the user’s name to identify the device.
3. Change other information as needed.
4. Select OK.

To add a device manually

1. Go to User & Device > Custom Devices & Groups.
2. Select Create New > Device.
3. Enter the following information:
   • Alias (required) l MAC address
   • Additional MACs (other interfaces of this device) l Device Type l Optionally, add the device to Custom Groups. l Optionally, enter Comments.

3. Select OK.

FortiGate firewall components

The FortiGate firewall is made up of a number of different components that are used to build an impressive list of features that have flexibility of scope and granularity of control that provide protection that is beyond that provided by the basic firewalls of the past.

Some of the components that FortiOS uses to build features are:

• Interfaces
• VLANs
• Soft Switches l Zones
• Predefined Addresses l IP address based l FQDN based l Geography based l Access Schedules l Authentication l Local User based l Authentication Server based (Active Directory, Radius, LDAP) l Device Based l Configureable Services l IPv4 and IPv6 protocol support

The features of FortiOS include but are not limited to:

• Security profiles, sometimes referred to as Unified Threat Management (UTM) or Next Generation Firewall

(NGFW) l Predefined firewall addresses (this includes IPv4 and IPv6, IP pools,. wildcard addresses and netmasks, and geography-based addresses)

• Monitoring traffic l Traffic shaping and per-IP traffic shaping (advanced) l Firewall schedules l Services (such as AOL, DHCP and FTP) l Logging traffic l Quality of Service (QoS) l Identity-based policies l Endpoint security

How does a FortiGate protect your network?

The FortiGate firewall protects your network by taking the various components and using them together to build a kind of wall or access control point so that anyone that is not supposed to be on your network is prevented from accessing your network in anyway other than those approved by you. It also protects your network from itself by keeping things that shouldn’t happen from happening and optimizing the flow of traffic so that the network is protected from traffic congestion that would otherwise impede traffic flow.

Most people have at one time or another played with the children’s toy system that is made up of interlocking blocks. The blocks come in different shapes and sizes so that you can build structures to suit your needs and in your way. The components of the FortiGate firewall are similar. You are not forced to use all of the blocks all of the time. You mix and match them to get the results that you are looking for. You can build a very basic structure Introduction     What’s new for Firewall in 6.0.1

that’s only function is to direct traffic in and out to the correct subnets or you can build a fortress that only allows specific traffic to specific hosts from specific hosts at specific times of day and that is only if they provide the credentials that have been pre-approved and all of the traffic is encrypted so that even when the traffic is out on the Internet it is private from the world. Just like the interlocking blocks, what you build is up to you, but chances are if you put them together the right way there isn’t much that can’t be built.

Here is one example of how the components could be put together to support the requirements of a network infrastructure design.

• Off the Internal interface you could have separate VLANs. One for each for the departments of Sales, Marketing and Engineering so that the traffic from the users on one VLAN does not intrude upon the hosts of the other VLANs and the department are isolated from one another for security reasons.
• To ease in the administration each of the VLAN sub-interfaces is made a member of a zone so that security policies that apply to all of the hosts on all of the VLANs can be applied to all of them at once.
• Using the addresses component each of the IP address ranges could be assigned a user friendly name so that they could be referred to individually and then for policies that would refer to them all as a whole the individual ranges to be made members of an address group.
• Firewall schedules could be created to address the differing needs of each of the groups so that Sales and Marketing could be allowed access to the Internet during regular business hours and the Engineering department could be allowed access during the lunch break.
• By setting up the outgoing policies to use FortiGuard Web-filtering the employees could be prevented from visiting inappropriate sites and thus enforcing the policies of the HR department.
• A couple of virtual IP addresses with port forwarding could be configured to allow users on the Internet to access a web server on the DMZ subnet using the company’s only Public IP address without affecting the traffic that goes to the company’s mail server that is hosted on a complete different computer.
• Even though the Web server on the same DMZ has an FTP service to allow for the uploading of web pages to the web server from the Marketing and Engineer teams, by placing a DENY policy on any FTP traffic from the Internet malicious users are prevented from abusing the FTP service.
• By monitoring the traffic as it goes through the policies you can verify that the policies are in working order.
• By using a combination of ALLOW and DENY policies and placing them in the correct order you could arrange for an outside contractor to be allowed to update the web site as well

These set of configurations is not extensive but it does give an idea of how different components can be mixed and matched to build a configuration that meets an organization’s needs but at the same time protect it from security risks.

If you are looking for a good device to get started on then check out the FortiGate 30E. It is an inexpensive entry point and will enable you to get experience on a quality infrastructure. Definitely sets you up to further your firewall career if you are looking for it. Click the link below to see the ones we have for sale!

FortiGate 30E

What is a firewall?

The term firewall originally referred to a wall intended to confine a fire or potential fire within a building. Later uses refer to similar structures, such as the metal sheet separating the engine compartment of a vehicle or aircraft from the passenger compartment.

A firewall can either be software-based or hardware-based and is used to help keep a network secure. Its primary objective is to control the incoming and outgoing network traffic by analyzing the data packets and determining whether it should be allowed through or not, based on a predetermined rule set. A network’s firewall builds a What is a firewall? bridge between an internal network that is assumed to be secure and trusted, and another network, usually an external (inter)network, such as the Internet, that is not assumed to be secure and trusted.

Network layer or packet filter firewalls

Stateless firewalls

Stateless firewalls are the oldest form of these firewalls. They are faster and simple in design requiring less memory because they process each packet individually and don’t require the resources necessary to hold onto packets like stateful firewalls. Stateful firewalls inspect each packet individually and check to see if it matches a predetermined set of rules. According to the matching rule the packet is either be allowed, dropped or rejected. In the case of a rejection an error message is sent to the source of the traffic. Each packet is inspected in isolation and information is only gathered from the packet itself. Simply put, if the packets were not specifically allowed according to the list of rules held by the firewall they were not getting through.

Stateful Firewalls

Stateful firewalls retain packets in memory so that they can maintain context about active sessions and make judgments about the state of an incoming packet’s connection. This enables Stateful firewalls to determine if a packet is the start of a new connection, a part of an existing connection, or not part of any connection. If a packet is part of an existing connection based on comparison with the firewall’s state table, it will be allowed to pass without further processing. If a packet does not match an existing connection, it will be evaluated according to the rules set for new connections. Predetermined rules are used in the same way as a stateless firewall but they can now work with the additional criteria of the state of the connection to the firewall.

Best Practices Tip for improving performance:

Blocking the packets in a denied session can take more cpu processing resources than passing the traffic through. By putting denied sessions in the session table, they can be kept track of in the same way that allowed session are so that the FortiGate unit does not have to redetermine whether or not to deny all of the packets of a session individually. If the session is denied all packets of that session are also denied. In order to configure this you will need to use 2 CLI commands

config system setting

set ses-denied-traffic enable

set block-session-timer <integer 1 – 300> (this determines in seconds how long, in seconds, the session is kept in the table) end

Application layer firewalls

Application layer filtering is yet another approach and as the name implies it works primarily on the Application Layer of the OSI Model.

Application Layer Firewalls actually, for lack of a better term, understand certain applications and protocols. Examples would be FTP, DNS and HTTP. This form of filtration is able to check to see if the packets are actually behaving incorrectly or if the packets have been incorrectly formatted for the protocol that is indicated. This

What is a firewall?

process also allows for the use of deep packet inspection and the sharing of functionality with Intrusion Prevention Systems (IPS).

Application-layer firewalls work on the application level of the TCP/IP stack (i.e., all browser traffic, or all telnet or ftp traffic), and may intercept all packets traveling to or from an application. They block other packets (usually dropping them without acknowledgment to the sender). Application firewalls work much like a packet filter but application filters apply filtering rules (allow/block) on a per process basis instead of filtering connections on a per port basis.

On inspecting all packets for improper content, firewalls can restrict or prevent outright the spread of networked computer worms and trojans. The additional inspection criteria can add extra latency to the forwarding of packets to their destination.

Proxy servers

A proxy server is an appliance or application that acts as an intermediary for communicating between computers. A computer has a request for information. The packets are sent to the designated resource but before they can get there they are blocked by the proxy server saying that it will take the request and pass it on. The Proxy Server processes the request and if it is valid it passes onto the designated computer. The designated computer gets the packet and processes the request, sending the answer back to the proxy server. The proxy server sends the information back to the originating computer. It’s all a little like a situation with two people who refuse to talk directly with each other using someone else to take messages back and forth.

From a security stand point a Proxy Server can serve a few purposes:

• Protects the anonymity of the originating computer l The two computers never deal directly with each other l Packets that are not configured to be forwarded are dropped before reaching the destination computer. l If malicious code is sent it will affect the Proxy server with out affecting the originating or sending computer.

Proxies can perform a number of roles including:

• Content Filtering l Caching l DNS proxy
• Bypassing Filters and Censorship l Logging and eavesdropping l Gateways to private networks l Accessing service anonymously

UTM/ NGFW

Unified Threat Management and Next Generation Firewall are terms originally coined by market research firms and refer to the concept of a comprehensive security solution provided in a single package. It is basically combining of what used to be accomplished by a number of different security technologies all under a single umbrella or in this case, a single device. On the FortiGate firewall this is achieved by the use of Security Profiles and optimized hardware.

In effect it is going from a previous style of firewall that included among its features:

• Gateway Network Firewall l Routing

• VPN

To a more complete system that includes:

• Gateway Network Firewall l Routing
• VPN
• Traffic Optimization l Proxy Services l Content Filtering l Application Control l Intrusion Prevention l Denial of Service Attack Protection l Anti-virus l Anti-spam l Data Leak Prevention l Endpoint Control of Security Applications l Load Balancing l WiFi Access Management l Authentication Integration into Gateway Security l Logging l Reporting

Advantages of using security profiles

• Avoidance of multiple installations. l Hardware requirements are fewer. l Fewer hardware maintenance requirements. l Less space required. l Compatibility – multiple installations of products increase the probability of incompatibility between systems. l Easier support and management.
• There is only one product to learn therefore a reduced requirement of technical knowledge. l Only a single vendor so there are fewer support contracts and Service Level Agreements. l Easier to incorporated into existing security architecture. l Plug and play architecture. l Web based GUI for administration.