Services

While there are a number of services already configured within FortiOS, the firmware allows for administrators to configure there own. The reasons for doing this usually fall into one or more of the following categories:

• The service is not common enough to have a standard configuration
• The service is not established enough to have a standard configuration
• The service has a standard port number but there is a reason to use a different one:
• Port is already in use by another service
• For security reasons, want to avoid standard port

When looking at the list of preconfigured services it may seem like there are a lot, but keep in mind that the theoretical limit for port numbers is 65,535. This gives a fairly good sized range when you are choosing what port to assign a service but there are a few points to keep in mind.

• Most of the well known ports are in the range 0 – 1023
• Most ports assigned by the Internet Corporation for Assigned Names and Numbers (ICANN) will be in the 1024 – 49151 range
• Port numbers between 49,152 and 65,535 are often used for dynamic, private or ephemeral ports. There are 3 Service objects that can be added and configured:
• Categories
• Services
• Service Groups

Firewall schedules

Firewall schedules control when policies are in effect. When you add a security policy on a FortiGate unit you need to set a schedule to determine the time frame in which that the policy will be functioning. While it is not set by default, the normal schedule would be always. This would mean that the policy that has been created is always function and always policing the traffic going through the FortiGate. The time component of the schedule is based on a 24 hour clock notation or military time as some people would say.

There are two types of schedules: One-time schedules and recurring schedules.

One-Time schedules are in effect only once for the period of time specified in the schedule. This can be useful for testing to limit how long a policy will be in effect in case it is not removed, or it can be used for isolated events such as a conference where you will only need a temporary infrastructure change for a few days.

The time frame for a One-time schedule is configured by using a start time which includes, Year | Month | Day | Hour | Minute and a Stop time which includes the same variables. So while the frequency of the schedule is only once it can last anywhere from 1 minute to multiple years.

Recurring schedules are in effect repeatedly at specified times of specified days of the week. The Recurring schedule is based on a repeating cycle of the days of the week as opposed to every x days or days of the month. This means that you can configure the schedule to be in effect on Tuesday, Thursday, and Saturday but not every 2 days or on odd numbered days of the month.

If a recurring schedule has a stop time that is earlier than the start time, the schedule will take effect at the start time but end at the stop time on the next day. You can use this technique to create recurring schedules that run from one day to the next.

Creating a recurring schedule object

1. Go to Policy & Objects > Schedules.

2. Select Create New. A drop down menu is displayed. Select Schedule.

3. From the Type options, choose Recurring.

4. Input a Name for the schedule object.

5. From the Days options, choose the day of the week that you would like this schedule to apply to. The schedule will be in effect on the days of the week that have a check mark in the checkbox to the left of the name of the weekday.

6. Choose a Start Time.

The Start Time is composed of two fields, Hour and Minute. Think of setting the time for a digital clock in

24 hour mode. The Hour value can be an integer from 0 and 23. The Minute value can be from 0 to 59. 0 and 0 would be midnight at the start of the day and 23 and 59 would be one minute to midnight at the end of the day. The value can be entered by keyboard or by using the up and down arrows in the field to select the value.

7. Choose a Stop Time.

Configuration is the same as Start Time.

8. Press OK.

Creating a One-time schedule object

1. Go to Policy & Objects > Schedules.

2. Select Create New. A drop down menu is displayed. Select Schedule.

3. From the Type options, choose One-time.

4. Input a Name for the schedule object.

5. Choose a Start Date.

Selecting the field with the mouse will bring up a interactive calendar graphic that will allow the user to select the date.The date can also be typed in using the format YYYY/MM/DD.

6. Choose an End Date.

Configuration is the same as Start Date.

7. Choose a Start Time.

The Start Time is composed of two fields, Hour and Minute. Think of setting the time for a digital clock in

24 hour mode. The Hour value can be an integer from 0 and 23. The Minute value can be from 0 to 59. 0 and 0 would be midnight at the start of the day and 23 and 59 would be one minute to midnight at the end of the day. The value can be entered by keyboard or by using the up and down arrows in the field to select the value.

8. Choose a Stop Time.

Configuration is the same as Start Time.

9. Enable/Disable Pre–expiration event log.

This configures the system to create an event log 1 to 100 days before the End Date as a warning in case the schedule needs to be extended.

10. If the Pre–expiration event log is enabled, set the value for Number of days before.

11. Press OK.

Example

You want to schedule the use of Skype to only between noon (12:00) and 1 p.m. (13:00). You could create a schedule that allows Skype traffic:

• Starting at Hour:12 and Minute: 00
• Stopping at Hour:13 and Minute: 00
• Set for days of the week: Sunday | Monday |Tuesday |Wednesday | Thursday | Friday | Saturday

Or you could have a schedule that blocks Skype traffic:

• Starting at Hour:13 and Minute: 00 (and goes to the next day)
• Stopping at Hour:12 and Minute: 00
• Set for days of the week: Sunday | Monday |Tuesday |Wednesday | Thursday | Friday | Saturday

Either way is effective for the task but other factors may make one method work better than another in certain situations of it could be just a preference in approach.

Schedule Groups

You can organize multiple firewall schedules into a schedule group to simplify your security policy list. The schedule parameter in the policy configuration does not allow for the entering of multiple schedules into a single policy so if you have a combination of time frames that you want to schedule the policy for then the best approach, rather than making multiple policies is to use a schedule group.

Creating a recurring schedule object

1. Go to Policy & Objects > Schedules.

2. Select Create New. A drop down menu is displayed. Select Schedule Group

3. Input a Name for the schedule object.

4. In the Members field, select the “+” to bring forth the panel for selecting entries.

5. Press OK.

Example

Your Internet policy allows employees to visit Social Media sites from company computers but not during what is considered working hours. The offices are open a few hours before working hours and the doors are not locked until a few hours after official closing so work hours are from 9 to 5 with a lunch break from Noon to 1:00 p.m.

Your approach is to block the traffic between 9 and noon and between 1:00 p.m. and 5:00 p.m. This means you will need two schedules for a single policy and the schedule group handles this for you. Schedule groups can contain both recurring and one-time schedules. Schedule groups cannot contain other schedule groups.

Schedule Expiration

The schedule in a security policy enables certain aspects of network traffic to occur for a specific length of time. What it does not do however, is police that time. That is, the policy is active for a given time frame, and as long as the session is open, traffic can continue to flow.

For example, in an office environment, Skype use is allowed between noon and 1pm. During that hour, any Skype traffic continues. As long as that session is open, after the 1pm end time, the Skype conversations can continue, yet new sessions will be blocked. Ideally, the Skype session should close at 1pm.

Using a CLI command you can set the schedule to terminate all sessions when the end time of the schedule is reached. Within the config firewall command enter the command:

set schedule-timeout enable

By default, this is set to disable.

Network defense

This section describes in general terms the means by which attackers can attempt to compromise your network and steps you can take to protect it. The goal of an attack can be as complex as gaining access to your network and the privileged information it contains, or as simple as preventing customers from accessing your web server. Even allowing a virus onto your network can cause damage, so you need to protect against viruses and malware even if they are not specifically targeted at your network.

The following topics are included in this section:

• Monitoring
• Blocking external probes
• Defending against DoS attacks

Monitoring

Monitoring, in the form of logging, alert email, and SNMP, does not directly protect your network. But monitoring allows you to review the progress of an attack, whether afterwards or while in progress. How the attack unfolds may reveal weaknesses in your preparations. The packet archive and sniffer policy logs can reveal more details about the attack. Depending on the detail in your logs, you may be able to determine the attackers location and identity.

While log information is valuable, you must balance the log information with the resources required to collect and store it.

GUI & CLI – What You May Not Know

The Graphic User Interface (GUI) is designed to be as intuitive as possible but there are always a few things that are left out because to put all of that information on the interface would clutter it up to the point where it wouldn’t be graphical and intuitive anymore.

This section is made up of knowledge that will make working with the both of the management interfaces easier because you wont have to find out about things like field limitations through trial and error. Some of it has to do with changing in how navigation in the GUI has changed.

The section includes the topics:

• Mouse Tricks
• Changing the default column setting on the policy page
• Naming Rules and Restrictions
• Character Restrictions
• Length of Fields Restrictions l  Object Tagging and Coloring l  Numeric Values
• Selecting options from a list
• Enabling or disabling options
• To Enable or Disable Optionally Displayed Features

Mouse Tricks

In previous version of the firmware much of the navigation, editing or choosing of options in the Web-based Manager was carried out by using the mouse in combination with a number of icons visible on the interface. This version of the firmware makes more extensive use of the right or secondary mouse button as well as the “drag and drop” feature. If you are used to the old Web-based Manager interface you will notice that a number of the options at the top of the display window are not there anymore or there are fewer of them.

To get a feel for the new approach the Policy & Objects > Policy > IPv4 window is a noticeable place to see some of these changes in action.

The different view modes are still in the upper right-hand corner as they were before but now there is no column settings link to move or configure the columns of the window. Now if you wish to reposition a column just use the mouse to click on the column heading and drag it to its new position. If you wish to add a new column just right- click on one of the column headings and a drop down menu will appear with the option “Column Settings”. Use the right pointing triangle to expand the “Column Settings” option to see a choice of possible columns for the window you are in. Those already selected will be at the top with a checked box and the available new ones will be at the bottom ready to be selected.

Rather than having a link to initiate a move in the positioning of policies in the sequence, you can select a policy and hold down the mouse button and drag it to its new position.

By right or secondary clicking the mouse curser in the cells of the Policy window you will get a drop down menu that is contextual to the column and policy row where you made the clck.For example if you right click in the “Schedule” column for the row that is for policy #5 you will get the option to select a schedule for policy #5 along with a number of other configuration options relating to that policy or its position in the sequence of policies.

You will find this approach used much more frequently through out the Web-based Manager, giving it a more modern and intuitive feel once you learn to use the right mouse button rather than finding a link displayed on the page.

Multicast forwarding

Multicasting (also called IP multicasting) consists of using a single multicast source to send data to many receivers. Multicasting can be used to send data to many receivers simultaneously while conserving bandwidth and reducing network traffic. Multicasting can be used for one-way delivery of media streams to multiple receivers and for one-way data transmission for news feeds, financial information, and so on.

Also RIPv2 uses multicasting to share routing table information, OSPF uses multicasting to send hello packets and routing updates, Enhanced Interior Gateway Routing Protocol (EIGRP) uses multicasting to send routing information to all EIGRP routers on a network segment and the Bonjour network service uses multicasting for DNS.

A FortiGate unit can operate as a Protocol Independent Multicast (PIM) version 2 router. FortiGate units support PIM sparse mode (RFC 4601) and PIM dense mode (RFC 3973) and can service multicast servers or receivers on the network segment to which a FortiGate unit interface is connected. Multicast routing is not supported in transparent mode (TP mode).

To support PIM communications, the sending/receiving applications and all con- necting PIM routers in between must be enabled with PIM version 2. PIM can use static routes, RIP, OSPF, or BGP to forward multicast packets to their destinations. To enable source-to-destination packet delivery, either sparse mode or dense mode must be enabled on the PIM-router interfaces. Sparse mode routers cannot send mul- ticast messages to dense mode routers. In addition, if a FortiGate unit is located between a source and a PIM router, two PIM routers, or is connected directly to a receiver, you must create a security policy manually to pass encapsulated (multicast) packets or decapsulated data (IP traffic) between the source and destination.

A PIM domain is a logical area comprising a number of contiguous networks. The domain contains at least one Boot Strap Router (BSR), and if sparse mode is enabled, a number of Rendezvous Points (RPs) and Designated Routers (DRs). When PIM is enabled on a FortiGate unit, the FortiGate unit can perform any of these functions at any time as configured.

Sparse mode

Initially, all candidate BSRs in a PIM domain exchange bootstrap messages to select one BSR to which each RP sends the multicast address or addresses of the multicast group(s) that it can service. The selected BSR chooses one RP per multicast group and makes this information available to all of the PIM routers in the domain through bootstrap messages. PIM routers use the information to build packet distribution trees, which map each multicast group to a specific RP. Packet distribution trees may also contain information about the sources and receivers associated with particular multicast groups.

When a FortiGate unit interface is configured as a multicast interface, sparse mode is enabled on it by default to ensure that distribution trees are not built unless at least one downstream receiver requests multicast traffic from a specific source. If the sources of multicast traffic and their receivers are close to each other and the PIM domain contains a dense population of active receivers, you may choose to enable dense mode throughout the PIM domain instead.

An RP represents the root of a non-source-specific distribution tree to a multicast group. By joining and pruning the information contained in distribution trees, a single stream of multicast packets (for example, a video feed) originating from the source can be forwarded to a certain RP to reach a multicast destination.

Each PIM router maintains a Multicast Routing Information Base (MRIB) that determines to which neighboring PIM router join and prune messages are sent. An MRIB contains reverse-path information that reveals the path of a multicast packet from its source to the PIM router that maintains the MRIB.

To send multicast traffic, a server application sends IP traffic to a multicast group address. The locally elected DR registers the sender with the RP that is associated with the target multicast group. The RP uses its MRIB to forward a single stream of IP packets from the source to the members of the multicast group. The IP packets are replicated only when necessary to distribute the data to branches of the RP’s distribution tree.

To receive multicast traffic, a client application can use Internet Group Management Protocol (IGMP) version 1 (RFC 1112), 2 (RFC 2236), or 3 (RFC 3376) control messages to request the traffic for a particular multicast group. The locally elected DR receives the request and adds the host to the multicast group that is associated with the connected network segment by sending a join message towards the RP for the group. Afterward, the DR queries the hosts on the connected network segment continually to determine whether the hosts are active. When the DR no longer receives confirmation that at least one member of the multicast group is still active, the DR sends a prune message towards the RP for the group.

FortiOS supports PIM sparse mode multicast routing for IPv6 multicast (multicast6) traffic and is compliant with RFC 4601: Protocol Independent Multicast – Sparse Mode (PIM-SM). You can use the following command to configure IPv6 PIM sparse multicast routing.

config router multicast6

set multicast-routing {enable | disable}

config interface

edit <interface-name>

set hello-interval <1-65535 seconds>

set hello-holdtime <1-65535 seconds>

end

config pim-sm-global config rp-address

edit <index>

set ipv6-address <ipv6-address>

end

The following diagnose commands for IPv6 PIM sparse mode are also available:

diagnose ipv6 multicast status diagnose ipv6 multicast vif diagnose ipv6 multicast mroute

My “Where Fortinet is Going Wrong” page will be getting updated soon. I have been receiving a large amount of emails from users of Fortinet regarding various things that are rubbing them the wrong way about our beloved device manufacturer. I am sure a lot of you will agree with a lot of what will be listed. Hopefully, someone at Fortinet is listening and can assist us with tackling these issues!

Dense mode

The packet organization used in sparse mode is also used in dense mode. When a multicast source begins to send IP traffic and dense mode is enabled, the closest PIM router registers the IP traffic from the multicast source (S) and forwards multicast packets to the multicast group address (G). All PIM routers initially broadcast the multicast packets throughout the PIM domain to ensure that all receivers that have requested traffic for multicast group address G can access the information if needed.

To forward multicast packets to specific destinations afterward, the PIM routers build distribution trees based on the information in multicast packets. Upstream PIM routers depend on prune/graft messages from downstream PIM routers to determine if receivers are actually present on directly connected network segments. The PIM routers exchange state refresh messages to update their distribution trees. FortiGate units store this state information in a Tree Information Base (TIB), which is used to build a multicast forwarding table. The information in the multicast forwarding table determines whether packets are forwarded downstream. The forwarding table is updated whenever the TIB is modified.

PIM routers receive data streams every few minutes and update their forwarding tables using the source (S) and multicast group (G) information in the data stream. Superfluous multicast traffic is stopped by PIM routers that do not have downstream receivers—PIM routers that do not manage multicast groups send prune messages to the upstream PIM routers. When a receiver requests traffic for multicast address G, the closest PIM router sends a graft message upstream to begin receiving multicast packets.

FortiGate units operating in NAT mode can also be configured as multicast routers. You can configure a FortiGate unit to be a Protocol Independent Multicast (PIM) router operating in Sparse Mode (SM) or Dense Mode (DM).

Multicast IP addresses

Multicast uses the Class D address space. The 224.0.0.0 to 239.255.255.255 IP address range is reserved for multicast groups. The multicast address range applies to multicast groups, not to the originators of multicast packets. The following table lists the reserved multicast address ranges and describes what they are reserved for:

Reserved Multicast address ranges

Creating multicast security policies requires multicast firewall addresses. You can add multicast firewall addresses by going to Firewall Objects > Address > Addresses and selecting Create New > Multicast Address. The factory default configuration includes multicast addresses for Bonjour (224.0.0.251-224.0.0.251, EIGRP (224.0.0.10-224.0.0.100), OSPF (224.0.0.5-224.0.0.60), all_hosts (224.0.0.1-224.0.0.1), and all_routers (224.0.0.2-224.0.0.2).

PIM Support

A FortiGate unit can be configured to support PIM by going to Router > Dynamic > Multicast and enabling multicast routing. You can also enable multicast routing using the config router multicast CLI command. When PIM is enabled, the FortiGate unit allocates memory to manage mapping information. The FortiGate unit communicates with neighboring PIM routers to acquire mapping information and if required, processes the multicast traffic associated with specific multicast groups.

The end-user multicast client-server applications must be installed and configured to initiate Internet connections and handle broadband content such as audio/video information.

Client applications send multicast data by registering IP traffic with a PIM-enabled router. An end-user could type in a class D multicast group address, an alias for the multicast group address, or a call-conference number to initiate the session.

Rather than sending multiple copies of generated IP traffic to more than one specific IP destination address, PIM- enabled routers encapsulate the data and use the one multicast group address to forward multicast packets to multiple destinations. Because one destination address is used, a single stream of data can be sent. Client applications receive multicast data by requesting that the traffic destined for a certain multicast group address be delivered to them — end-users may use phone books, a menu of ongoing or future sessions, or some other method through a user interface to select the address of interest.

A class D address in the 224.0.0.0 to 239.255.255.255 range may be used as a multicast group address, subject to the rules assigned by the Internet Assigned Numbers Authority (IANA). All class D addresses must be assigned in advance. Because there is no way to determine in advance if a certain multicast group address is in use, collisions may occur (to resolve this problem, end-users may switch to a different multicast address).

To configure a PIM domain

1. If you will be using sparse mode, determine appropriate paths for multicast packets.

2. Make a note of the interfaces that will be PIM-enabled. These interfaces may run a unicast routing protocol.

3. If you will be using sparse mode and want multicast packets to be handled by specific (static) RPs, record the IP addresses of the PIM-enabled interfaces on those RPs.

4. Enable PIM version 2 on all participating routers between the source and receivers. On FortiGate units, use the config router multicast command to set global operating parameters.

5. Configure the PIM routers that have good connections throughout the PIM domain to be candidate BSRs.

6. If sparse mode is enabled, configure one or more of the PIM routers to be candidate RPs.

7. If required, adjust the default settings of PIM-enabled interface(s).

Multicast forwarding and FortiGate units

In both transparent mode and NAT mode you can configure FortiGate units to forward multicast traffic.

For a FortiGate unit to forward multicast traffic you must add FortiGate multicast security policies. Basic multicast security policies accept any multicast packets at one FortiGate interface and forward the packets out another FortiGate interface. You can also use multicast security policies to be selective about the multicast traffic that is accepted based on source and destination address, and to perform NAT on multicast packets.

In the example shown below, a multicast source on the Marketing network with IP address 192.168.5.18 sends multicast packets to the members of network 239.168.4.0. At the FortiGate unit, the source IP address for multicast packets originating from workstation 192.168.5.18 is translated to 192.168.18.10. In this example, the FortiGate unit is not acting as a multicast router.

Multicast forwarding and RIPv2

RIPv2 uses multicast to share routing table information. If your FortiGate unit is installed on a network that includes RIPv2 routers, you must configure the FortiGate unit to forward multicast packets so that RIPv2 devices can share routing data through the FortiGate unit. No special FortiGate configuration is required to share RIPv2 data, you can simply use the information in the following sections to configure the FortiGate unit to forward multicast packets.

RIPv1 uses broadcasting to share routing table information. To allow RIPv1 packets through a FortiGate unit you can add standard security policies. Security policies to accept RIPv1 packets can use the ANY predefined firewall service or the RIP pre- defined firewall service.

Example multicast network including a FortiGate unit that forwards multicast packets

Configuring FortiGate multicast forwarding

You configure FortiGate multicast forwarding from the Command Line Interface (CLI). Two steps are required:

• Adding multicast security policies
• Enabling multicast forwarding

This second step is only required if your FortiGate unit is operating in NAT mode. If your FortiGate unit is operating in transparent mode, adding a multicast policy enables multicast forwarding.

There is sometimes a confusion between the terms “forwarding” and “routing”. These two functions should not be taking place at the same time.

It is mentioned that multicast-forward should be enabled when the FortiGate unit is in NAT mode and that this will forward any multicast packet to all interfaces. However, this parameter should NOT be enabled when the FortiGate unit operates as a mul- ticast router (i.e. with a routing protocol enabled. It should only be enabled when there is no routing protocols activated.

Adding multicast security policies

You need to add security policies to allow packets to pass from one interface to another. Multicast packets require multicast security policies. You add multicast security policies from the CLI using the config firewall multicast-policy command. As with unicast security policies, you specify the source and destination interfaces and optionally the allowed address ranges for the source and destination addresses of the packets.

You can also use multicast security policies to configure source NAT and destination NAT for multicast packets. Keep the following in mind when configuring multicast security policies:

• The matched forwarded (outgoing) IP multicast source IP address is changed to the configured IP address.
• Source and Destination interfaces are optional. If left blank, then the multicast will be forwarded to ALL interfaces.
• Source and Destination addresses are optional. If left un set, then it will mean ALL addresses.
• The nat keyword is optional. Use it when source address translation is needed.

FortiGate PIM-SM debugging examples

Using the example topology shown below, you can trace the multicast streams and states within the three FortiGate units (FGT-1, FGT-2, and FGT-3) using the debug commands described in this section. The command output in this section is taken from FortiGate unit when the multicast stream is flowing correctly from source to receiver.

PIM–SM debugging topology

Checking that the receiver has joined the required group

From the last hop router, FGT-3, you can use the following command to check that the receiver has correctly joined the required group.

FGT-3 # get router info multicast igmp groups

IGMP Connected Group Membership

Group Address Interface Uptime Expires Last Reporter

239.255.255.1 port3 00:31:15 00:04:02 10.167.0.62

Only 1 receiver is displayed for a particular group, this is the device that responded to the IGMP query request from the FGT-3. If a receiver is active the expire time should drop to approximately 2 minutes before being refreshed.

Checking the PIM-SM neighbors

Next the PIM-SM neighbors should be checked. A PIM router becomes a neighbor when the PIM router receives a

PIM hello. Use the following command to display the PIM-SM neighbors of FGT-3.

FGT-3 # get router info multicast pim sparse-mode neighbour

Neighbor Interface Uptime/Expires Ver DR Address Priority/Mode

10.132.0.156 port2 01:57:12/00:01:33 v2 1 /

Checking that the PIM router can reach the RP

The rendezvous point (RP) must be reachable for the PIM router (FGT-3) to be able to send the *,G join to request the stream. This can be checked for FGT-3 using the following command:

FGT-3 # get router info multicast pim sparse-mode rp-mapping

PIM Group-to-RP Mappings Group(s): 224.0.0.0/4, Static RP: 192.168.1.1

Uptime: 07:23:00

Viewing the multicast routing table (FGT-3)

The FGT-3 unicast routing table can be used to determine the path taken to reach the RP at 192.168.1.1. You can then check the stream state entries using the following commands:

FGT-3 # get router info multicast pim sparse-mode table

IP Multicast Routing Table

(*,*,RP) Entries: 0 (*,G) Entries: 1 (S,G) Entries: 1 (S,G,rpt) Entries: 1

FCR Entries: 0

Example multicast destination NAT (DNAT) configuration

The example topology shown and described below shows how to configure destination NAT (DNAT) for two multicast streams. Both of these streams originate from the same source IP address, which is 10.166.0.11. The example configuration keeps the streams separate by creating 2 multicast NAT policies. In this example the FortiGate units have the following roles:

• FGT-1 is the RP for dirty networks, 233.0.0.0/8.
• FGT-2 performs all firewall and DNAT translations.
• FGT-3 is the RP for the clean networks, 239.254.0.0/16.
• FGT-1 and FGT-3 are functioning as PM enabled routers and could be replaced can be any PIM enabled router. This example only describes the configuration of FGT-2. FGT-2 performs NAT so that the receivers connected to FGT-3 receive the following translated multicast streams.
• If the multicast source sends multicast packets with a source and destination IP of 10.166.0.11 and 233.2.2.1; FGT-3 translates the source and destination IPs to 192.168.20.1 and 239.254.1.1
• If the multicast source sends multicast packets with a source and destination IP of 10.166.0.11 and 233.3.3.1; FGT-3 translates the source and destination IPs to 192.168.20.10 and 239.254.3.1

Example multicast DNAT topology

To configure FGT-2 for DNAT multicast

1. Add a loopback interface. In the example, the loopback interface is named loopback.

config system interface edit loopback

set vdom root

set ip 192.168.20.1 255.255.255.0 set type loopback

next end

2. Add PIM and add a unicast routing protocol to the loopback interface as if it was a normal routed interface. Also add static joins to the loopback interface for any groups to be translated.

config router multicast config interface

edit loopback

set pim-mode sparse-mode config join-group

edit 233.2.2.1 next

edit 233.3.3.1 next

end

next

3. In this example, to add firewall multicast policies, different source IP addresses are required so you must first add an IP pool:

config firewall ippool edit Multicast_source

set endip 192.168.20.20 set interface port6

set startip 192.168.20.10 next

end

4. Add the translation security policies.

Policy 2, which is the source NAT policy, uses the actual IP address of port6. Policy 1, the DNAT policy, uses an address from the IP pool. The source and destination addresses will need to be previously created address objects. For this example, 233.3.3.1 255.255.255.255 will be represented by “example-addr_1” and 10.166.0.11

255.255.255.255 will be represented by “example-addr_2”. You will likely want to use something more intuitive from your own network.

config firewall multicast-policy edit 1

set dnat 239.254.3.1

set dstaddr example-addr_1 set dstintf loopback

set nat 192.168.20.10

set srcaddr example-addr_2 set srcintf port6

next edit 2

set dnat 239.254.1.1

set dstaddr 233.2.2.1 255.255.255.255 set dstintf loopback

set nat 192.168.20.1

set srcaddr 10.166.0.11 255.255.255.255 set srcintf port6

next end

5. Add a firewall multicast policy to forward the stream from the loopback interface to the physical outbound interface.

This example is an any/any policy that makes sure traffic accepted by the other multicast policies can exit the

FortiGate unit.

config firewall multicast-policy edit 3

set dstintf port7

set srcintf loopback next

end

Example PIM configuration that uses BSR to find the RP

This example shows how to configure a multicast routing network for a network consisting of four FortiGate-500A units (FortiGate-500A_1 to FortiGate-550A_4). A multicast sender is connected to FortiGate-500A_2. FortiGate-500A_2 forwards multicast packets in two directions to reach Receiver 1 and Receiver 2.
The configuration uses a Boot Start Router (BSR) to find the Rendezvous Points (RPs) instead of using static RPs. Under interface configuration, the loopback interface lo0 must join the 236.1.1.1 group (source). This example describes:

• Commands used in this example
• Configuration steps
• Example debug commands

PIM network topology using BSR to find the RP

Commands used in this example

This example uses CLI commands for the following configuration settings:

• Adding a loopback interface (lo0)
• Defining the multicast routing
• Adding the NAT multicast policy

Adding a loopback interface (lo0)

Where required, the following command is used to define a loopback interface named lo0.

config system interface edit lo0

set vdom root

set ip 1.4.50.4 255.255.255.255

set allowaccess ping https ssh snmp http telnet set type loopback

next end

Defining the multicast routing

In this example, the following command syntax is used to define multicast routing.

The example uses a Boot Start Router (BSR) to find the Rendezvous Points (RPs) instead of using static RPs. Under interface configuration, the loopback interface lo0 must join the 236.1.1.1 group (source).

config router multicast config interface

edit port6

set pim-mode sparse-mode next

edit port1

set pim-mode sparse-mode next

edit lo0

set pim-mode sparse-mode set rp-candidate enable

config join-group edit 236.1.1.1 next

end

set rp-candidate-priority 1 next

end

set multicast-routing enable config pim-sm-global

set bsr-allow-quick-refresh enable set bsr-candidate enable

set bsr-interface lo0 set bsr-priority 200

end end

Chapter 10 – FortiView

FortiView

• Overview on page 1149 outlines the role FortiView plays in FortiOS and its overall layout. This section also identifies which FortiGate platforms support the full FortiView features.
• FortiView consoles on page 1160 describes the various FortiView consoles available in FortiOS, including example scenarios, in most cases.
• Reference on page 1172 explains reference information for the various consoles in FortiView, and describes the assortment of filtering options, drilldown options, and columns available.
• Troubleshooting FortiView on page 1183 offers solutions to common technical issues experienced by FortiGate users regarding FortiView.

What‘s new in FortiOS 5.4

New Consoles

In FortiOS 5.4, a variety of new consoles have been added to FortiView:

FortiView Policies console

The new Policies console works similarly to other FortiView consoles, yet allows administrators to monitor policy activity, and thereby decide which policies are most and least active. This helps the administer to discern which policies are unused and can be deleted.

In addition, you have the ability to click on any policy in the table to drill down to the Policies list and view or edit that policy. You can view this new console in either Table or Bubble Chart view.

FortiView Interfaces console

The new Interfaces console works similarly to other FortiView consoles and allows administrators to perform current and historical monitoring per interface, with the ability to monitor bandwidth in particular. You can view this new console in either Table or Bubble Chart view.

FortiView Countries console

A new Countries console has been introduced to allow administrators to filter traffic according to source and destination countries. This console includes the option to view the Country Map visualization (see below).

FortiView Device Topology console

The new Device Topology console provides an overview of your network structure in the form of a Network Segmentation Tree diagram (see below).

FortiView Traffic Shaping console

A new Traffic Shaping console has been introduced to improve monitoring of existing Traffic Shapers. Information displayed includes Shaper info, Sessions, Bandwidth, Dropped Bytes, and more.

FortiView Threat Map console

A new Threat Map console has been introduced to monitor risks coming from various international locations arriving at a specific location, depicted by the location of a FortiGate on the map (see below).

FortiView Failed Authentication console

A Failed Authentication console has been added under FortiView that allows you to drill down an entry to view the logs. This new console is particularly useful in determining whether or not the FortiGate is under a brute force attack. If an administrator sees multiple failed login attempts from the same IP, they could (for example) add a local-in policy to block that IP.

The console provides a list of unauthorized connection events in the log, including the following:

• unauthorized access to an admin interface (telnet, ssh, http, https, etc.) l  failure to query for SNMP (v3) or outside of authorized range (v1, v2, v3) l  failed attempts to establish any of the following:
• Dial-up IPsec VPN connections
• Site-to-site IPsec VPN connections
• SSL VPN connections
• FGFM tunnel

Enabling FortiView

By default, FortiView is enabled on FortiGates running FortiOS firmware version 5.2 and above. You will find the FortiView consoles in the main menu. However, certain options will not appear unless the FortiGate has Disk Logging enabled.

Only certain FortiGate models support Disk Logging. A complete list of FortiGate platforms that support Disk Logging is provided in the matrix below.

To enable Disk Logging

1. Go to Log & Report > Log Settings and select the checkbox next to Disk.

2. Apply the change.

To enable Disk Logging – CLI

config log disk setting set status enable

end

FortiView Feature Support – Platform Matrix

Note that the following table identifies three separate aspects of FortiView in FortiOS 5.2.3:

• Basic feature support
• Historical Data
• Disk Logging

a = Default support.

# = Local storage required.

* Refer to section on Historical Data below.

Configuration Dependencies

Most FortiView consoles require the user to enable several features to produce data. The following table summarizes the dependencies:

Feature Dependencies (Realtime) Dependencies (Historical)

Sources
None, always supported
Traffic logging enabled in policy

Destinations
None, always supported
Traffic logging enabled in policy

Feature Dependencies (Realtime) Dependencies (Historical)

Interfaces None, always supported Disk logging enabled

Traffic logging enabled in policy

Policies None, always supported Disk logging enabled

Traffic logging enabled in policy

Countries None, always supported Disk logging enabled

Traffic logging enabled in policy

All Sessions None, always supported Traffic logging enabled in policy

Applications None, always supported Disk logging enabled

Traffic logging enabled in policy

Application control enabled in policy

WiFi Clients None, always supported Disk logging enabled

Traffic logging enabled in policy

Cloud Applications Not supported Disk logging enabled
Application control enabled in policy SSL “deep inspection” enabled in policy Deep application inspection enabled in
application sensor

Extended UTM log enabled in application sensor

Web Sites Disk logging enabled

Web Filter enabled in policy

“web-url-log” option enabled in Web Fil- ter profile

Disk logging enabled

Web Filter enabled in policy

“web-url-log” option enabled in Web Filter profile

Feature Dependencies (Realtime) Dependencies (Historical)

Threats
Not supported
Disk logging enabled

Traffic logging enabled in policy

Threat weight detection enabled

Threat Map
None, always supported
Disk logging enabled

Traffic logging enabled in policy

Threat weight detection enabled

FortiSandbox
Not supported
Disk logging enabled

Traffic logging enabled in policy

Failed Authentic- ation
Not supported
Disk logging enabled

System Events
Not supported
Disk logging enabled

Admin Logins
Not supported
Disk logging enabled

VPN
Not supported
Disk logging enabled

Traffic logging enabled in policy

FortiView interface

FortiView lets you access information about the traffic activity on your FortiGate, visually and textually. FortiView is broken up into several consoles, each of which features a top menu bar and a graph window, as seen in the following image:

FortiView Application console sorted by Sessions (Blocked/Allowed)

The top menu bar features:

• a Refresh button, which updates the data displayed,
• a Filter button, for filtering the data by category,
• a Settings button (containing additional viewing settings and a link to the Threat Weight menu).
• a drop-down menu of different views:
• Time Display (options: now, 5 minutes, 1 hour, or 24 hours),
• Table View
• Timeline View
• Bubble Chart 1
• Country Map 2

1 For information on the Bubble Chart, refer to Bubble Chart Visualization on page 1157.

2 For more information on the Country Map, refer to Countries on page 1162.

The FortiView graph

The graph window can be hidden using the X in the top right corner, and re-added by selecting Show Graph. To zoom in on a particular section of the graph, click and drag from one end of the desired section to the other. This will appear in the Time Display options as a Custom selection. The minimum selection size is 60 seconds.

Only FortiGate models 100D and above support the 24 hour historical data.

Bubble Chart Visualization

Notes about the Bubble Chart:

• It is possible to sort on the Bubble Chart using the Sort By: dropdown menu.
• The size of each bubble represents the related amount of data.
• Place your cursor over a bubble to display a tool-tip with detailed info on that item.
• You can click on a bubble to drilldown into greater (filtered) detail.

Links created between FortiView and View/Create Policy

The Policy column in FortiView consoles and the Log Viewer pages includes a link, which navigates to the IPv4 or IPv6 policy list and highlights the policy.

Right-clicking on a row in FortiView or the Log Viewer has menu items for Block Source, Block Destination and Quarantine Source where appropriate columns are available to determine these values. When multiple rows are selected, the user will be prompted to create a named Address Group to contain the new addresses.

When the user clicks Block Source or Block Destination they are taken to a policy creation page with enough information filled in to create a policy blocking the requested IP traffic.

The policy page will feature an informational message block at the top describing the actions that will be taken. Once the user submits the form, the requisite addresses, groups and policy will be created at once.

If the user clicks on Quarantine User then they will be prompted for a duration. They may also check a box for a Permanent Ban. The user can manage quarantined users under Monitor > User Quarantine Monitor.

Visualization support for the Admin Logins page

A useful chart is generated for Admin login events under FortiView > Admin Logins. You can view the information in either Table View or Timeline View (shown below). In Timeline View, each line represents on administrator, with individual sessions indicated per administrator line. When you hover over a particular timeline, detailed information appears in a tooltip.

FortiView consoles

This section describes the following log filter consoles available in FortiView:

• Sources on page 1160 explains the features of FortiView’s Sources console, and shows how you can investigate an unusual spike in traffic to determine which user is responsible.
• Destinations on page 1161 explains the features of FortiView’s Destinations console and shows how you can access detailed information on user destination-accessing through the use of drill down functionality.
• Interfaces on page 1161 explains the number of interfaces connected to your network, how many sessions there are in each interface, and what sort of traffic is occurring.
• Policies on page 1162 explains what policies are in affect on your network, what their source and destination interfaces are, how many sessions are in each policy, and what sort of traffic is occurring.
• Countries on page 1162 explains and graphically displays network activity by geographic region.
• WiFi Clients on page 1164 shows a list of all the devices connected to the WLAN.
• All Sessions on page 1164 explains the features of FortiView’s All Sessions console and shows how you can filter sessions by port number and application type.
• Applications on page 1165 explains the features of FortiView’s Applications console and shows how you can view what sort of applications their employees are using.
• Cloud Applications on page 1165 explains the features of FortiView’s Cloud Applications console and shows how you can drill down to access detailed data on cloud application usage, e.g. YouTube.
• Web Sites on page 1166 explains the features of FortiView’s Web Sites console and shows how you can investigate instances of proxy avoidance which is the use of a proxy site in order to access data that might otherwise be blocked by the server.
• Threats on page 1167 explains the features of FortiView’s Threats console and shows how you can monitor threats to the network, both in terms of their Threat Score and Threat Level.
• Threat Map on page 1168 explains the features of Fortiview’s Threat Map console which provides a geographical display of threats, in realtime, from international sources as they arrive at your FortiGate.
• Failed Authentication on page 1169 explains instances in which users attempted to connect to the server but were unsuccessful.
• System Events on page 1169 explains security events detected by FortiOS, providing a name and description for the events, an assessment of the event’s severity level, and the number of instances the events were detected.
• Admin Logins on page 1170 explains information on administrator interactions with the network, including the number of login instances, number of failed logins, and the length of time logged in.
• VPN on page 1170 explains how users can access information on any VPNs associated with their FortiGate.