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.

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

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.

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:

1	Configuration changes, mainly addition/deletion/modification of virtual domains.
2	TCP connection accepts or connects, redirect creation.
4	Create or delete a session.
16	Any IO read or write.
32	An ASCII dump of all data read or written.
64	Include HEX dump in the above output.
128	Any activity related to the use of the FortiCarrier dynamic profile feature to determine the correct profile-group to use.
256	Log summary of interesting fields in a SIP call.
1024	Any activity related to SIP geo-redundancy.
2048	Any activity related to HA syncing of SIP calls.

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

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

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

 

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:

ssl-send-empty-frags {disable | enable}	Enable to send empty fragments to avoid CBC IV attacks. Compatible 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 renegotiate 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 support RFC 5746 secure renegotiation indication. Default is allow.

 

ssl-algorithm {high | low medium}	|	Select the relative strength of the algorithms that can be selected. 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 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.