Learning mode for policies

The learning mode feature is a quick and easy method for setting a policy to allow everything but to log it all so that it can later be used to determine what restrictions and protections should be applied. The objective is to monitor the traffic not act upon it while in Learning mode.

Once the Learn action is enabled, functions produce hard coded profiles that will be enabled on the policy. The following profiles are set up:

• AntiVirus (av-profile) l Web Filter ( webfilter-profile) l Anti Spam( spamfilter-profile ) l Data Leak Prevention (dlp-sensor ) l Intrusion Protection (ips-sensor ) l Application Control (application-list ) l Proxy Options (profile-protocol-options)
• DNS Filter (Does not have a Flow mode) l Web Application Firewall(Does not have a Flow mode) l CASI(Almost all signatures in CASI require SSL deep inspection. Without SSL inspection, turning on CASI serves little purpose)

The ability to allow policies to be set to a learning mode is enabled on a per VDOM basis.

config system settings set gui-policy-learning [enable | disable] end

Once the feature is enabled on the VDOM, Learn is an available Action option when editing a policy.

Once the Learning policy has been running for a sufficient time to collect needed information a report can be looked at by going to Log & Report > Learning Report.

The Report can be either a Full Report or a Report Summary The time frame of the report can be 5 minutes, 1 hour, or 24 hours.

The Learning Report includes: Deployment Methodology l Test Details l Start time l End time l Model l Firmware

• Policy List

Executive Summary l Total Attacks Detected l Top Application Category l Top Web Category l Top Web Domain l Top Host by Bandwidth l Host with Highest Session Count Security and Threat Prevention l High Risk Applications l Application Vulnerability Exploits

 

Policy Modes

• Malware, botnets and Spyware/Adware l At-Risk Devices and Hosts User Productivity l Application Usage l Top Application Categories l Top Social Media Applications l Top Video/Audio Streaming Applications l Top Peer to Peer Applications l Top Gaming Applications
• Web Usage l Top Web Categories l Top Web Applications l Top Web Domains

Policy Modes

You can operate your FortiGate or individual VDOMs in Next Generation Firewall (NGFW) Policy Mode.

You can enable NGFW policy mode by going to System > Settings, setting the Inspection mode to Flowbased and setting the NGFW mode to Policy-based. When selecting NGFW policy-based mode you also select the SSL/SSH Inspection mode that is applied to all policies

Flow-based inspection with profile-based NGFW mode is the default in FortiOS 5.6.

Or use the following CLI command:

config system settings set inspection-mode flow set policy-mode {standard | ngfw}

end

NGFW policy mode and NAT

If your FortiGate is operating in NAT mode, rather than enabling source NAT in individual NGFW policies you go to Policy & Objects > Central SNAT and add source NAT policies that apply to all matching traffic. In many cases you may only need one SNAT policy for each interface pair. For example, if you allow users on the internal network (connected to port1) to browse the Internet (connected to port2) you can add a port1 to port2 Central SNAT policy similar to the following:

Policy Modes

Application control in NGFW policy mode

You configure Application Control simply by adding individual applications to security policies. You can set the action to accept or deny to allow or block the applications.

Policy Modes

Web Filtering in NGFW mode

You configure Web Filtering by adding URL categories to security policies. You can set the action to accept or deny to allow or block the applications.

 

Other NGFW policy mode options

You can also combine both application control and web filtering in the same NGFW policy mode policy. Also if the policy accepts applications or URL categories you can also apply Antivirus, DNS Filtering, and IPS profiles in NGFW mode policies as well a logging and policy learning mode.

Security profiles

Where security policies provide the instructions to the FortiGate unit for controlling what traffic is allowed through the device, the Security profiles provide the screening that filters the content coming and going on the network. Security profiles enable you to instruct the FortiGate unit about what to look for in the traffic that you don’t want, or want to monitor, as it passes through the device.

A security profile is a group of options and filters that you can apply to one or more firewall policies. Security profiles can be used by more than one security policy. You can configure sets of security profiles for the traffic types handled by a set of security policies that require identical protection levels and types, rather than repeatedly configuring those same security profile settings for each individual security policy.

For example, while traffic between trusted and untrusted networks might need strict antivirus protection, traffic between trusted internal addresses might need moderate antivirus protection. To provide the different levels of protection, you might configure two separate profiles: one for traffic between trusted networks, and one for traffic between trusted and untrusted networks.

Security profiles are available for various unwanted traffic and network threats. Each are configured separately and can be used in different groupings as needed. You configure security profiles in the Security Profiles menu and applied when creating a security policy by selecting the security profile type.

There is a separate handbook for the topic of the Security Profiles, but because the Security Profiles are applied through the Firewall policies it makes sense to have at least a basic idea of what the security profile do and how they integrate into the FortiGate’s firewall policies. The following is a listing and a brief description of what the security profiles offer by way of functionality and how they can be configured into the firewall policies.

l HTTP l SMTP l POP3 l IMAP l FTP l NNTP l MAPI l DNS l IM

AntiVirus

Antivirus is used as a catch all term to describe the technology for protection against the transmission of malicious computer code sometimes referred to as malware. As anyone who has listened to the media has heard that the Internet can be a dangerous place filled with malware of various flavors. Currently, the malware that is most common in the Internet, in descending order, is Trojan horses, viruses, worms, adware, back door exploits, spyware and other variations. In recent years, not only has the volume of malicious software become greater than would have been believed when it first appeared but the level of sophistication has risen as well.

The Antivirus Filter works by inspecting the traffic that is about to be transmitted through the FortiGate. To increase the efficiency of effort it only inspects the traffic being transmitted via the protocols that it has been configured to check. Before the data moves across the FortiGate firewall from one interface to another it is checked for attributes or signatures that have been known to be associated with malware. If malware is detected, it is removed.

Web Filtering

Malicious code is not the only thing to be wary of on the Internet. There is also the actual content. While the content will not damage or steal information from your computer there is still a number of reasons that would require protection from it.

In a setting where there are children or other sensitive people using the access provided by a connected computer there is a need to make sure that images or information that is not appropriate is not inadvertently displayed to them. Even if there is supervision, in the time it takes to recognize something that is inappropriate and then properly react can expose those we wish to protect. It is more efficient to make sure that the content cannot reach the screen in the first place.

In an organizational setting, there is still the expectation that organization will do what it can to prevent inappropriate content from getting onto the computer screens and thus provoking an Human Resources incident. There is also the potential loss of productivity that can take place if people have unfiltered access to the Internet.

Some organizations prefer to limit the amount of distractions available to tempt their workers away from their duties.

The Web filter works primarily by looking at the destination location request for a HTTP(S) request made by the sending computer. If the URL is on a list that you have configured to list unwanted sites, the connection will be disallowed. If the site is part of a category of sites that you have configured to deny connections to the session will also be denied. You can also configure the content filter to check for specific key strings of data on the actual web site and if any of those strings of data appear the connection will not be allowed.

The configuration for each of these protocols is handled separately.

DNS filtering is similar to Web Filtering from the viewpoint of the user. The difference is under the hood. When using regular Web Filtering, the traffic can go through some processing steps before it gets to the point where the web filter determines whether on not the traffic should be accepted or denied. Because the filtering takes place at the DNS level, some sites can be denied before a lot of the additional processing takes place. This can save resource usage on the FortiGate and help performance.

Application Control

Application Control is designed to allow you to determine what applications are operating on your network and to the also filter the use of these applications as required. Application control is also for outgoing traffic to prevent the use of applications that are against an organization’s policy from crossing the network gateway to other networks. An example of this would be the use of proxy servers to circumvent the restrictions put in place using the Web Filtering.

Intrusion Protection (IPS)

Intrusion Prevention System is almost self explanatory. In the same way that there is malware out on the Internet that the network needs to be protected from there are also people out there that take a more targeted approach to malicious cyber activity. No operating system is perfect and new vulnerabilities are being discovered all of the time. An intrusion prevention system is designed to look for activity or behavior that is consistent with attacks against your network. When attack like behavior is detected it can either be dropped or just monitored depending on the approach that you would like to take.

As new vulnerabilities are discovered they can be added to the IPS database so that the protection is current.

Anti-Spam

Spam or unsolicited bulk email is said to account for approximately 90% of the email traffic on the Internet. Sorting through it is both time consuming and frustrating. By putting an email filter on policies that handle email traffic, the amount of spam that users have to deal with can be greatly reduced.

Data Leak Prevention (DLP)

Data Leak Prevention is used to prevent sensitive information from leaving your network. When people think of security in the cyber-world one of the most common images is that of a hacker penetrating your network and making off with your sensitive information, but the other way that you can lose sensitive data is if someone already on the inside of your network sends it out. This does not have to be an act of industrial espionage. It can just be a case of not knowing the policies of the organization or a lack of knowledge of security or laws concerning privacy.

For instance, a company may have a policy that they will not reveal anyone’s Social Security number, but an employee emails a number of documents to another company that included a lengthy document that has a Social Security number buried deep within it. There is not malicious intent but if the information got out there could be repercussions.

If an organization has any information in a digital format that it cannot afford for financial or legal reasons, to leave its network, it makes sense to have Data Leak Prevention in place as an additional layer of protection.

VoIP

Voice over IP is essentially the protocols for transmitting voice or other multimedia communications over Internet

Protocol networks such as the Internet. The Security Profiles VoIP options apply the SIP Application Level Gateway (ALG) to support SIP through the FortiGate unit. The SIP ALG can also be used to protect networks from SIP-based attacks.

ICAP

Internet Content Adaptation Protocol (ICAP) off loads HTTP traffic to another location for specialized processing. The purpose of this module when triggered is to send the incoming HTTP traffic over to a remote server to be processed thus taking some of the strain off of the resources of the FortiGate unit. The reasons for the specialized process could be anything from more sophisticated Antivirus to manipulation of the HTTP headers and URLs.

Just like other components of the FortiGate, there is the option for different Proxy Option profiles so that you can be very granular in your control of the workings of the FortiGate. In the case of the Proxy Option profiles the thing that you will want to focus on is the matching up of the correct profile to a firewall policy that is using the appropriate protocols. If you are creating a Proxy Option profile that is designed for policies that control SMTP traffic into your network you only want to configure the settings that apply to SMTP. You do not need or want to configure the HTTP components.

The Web Application Firewall performs a similar role as devices such as Fortinet’s FortiWeb, though in a more limited fashion. It’s function is to protect internal web servers from malicious activity specific to those types of servers. This includes things like SQL injection, Cross site Scripting and trojans. It uses signatures and other straight forward methods to protect the web servers, but it is a case of turning the feature on or off and the actions are limited toAllow,MonitororBlock.To get protection that is more sophisticated, granular and intelligent, as will as having many more features, it is necessary to get a device like the FortiWeb that can devote more resources to the process. However, if your needs are simple, choosing to use the WAF feature built into the FortiGate should provide valuable protection.

The comfort client feature to mitigates this potential issue by feeding a trickle of data while waiting for the scan to complete so as to let the user know that processing is taking place and that there hasn’t been a failure in the transmission. This slow transfer rate continues until the antivirus scan is complete. Once the file has been successfully scanned without any indication of viruses the transfer will proceed at full speed.

Without prior approval the email should not be forwarded.

Please be environmentally friendly and don’t print out emails

For questions regarding the purchasing of our products please call…

Security Profile Groups

It may seem counter intuitive to have a topic on Security Profile Groups in the Firewall Chapter/Handbook when there is already a chapter/handbook on Security Profiles, but there are reasons.

l Security Profile Groups are used exclusively in the configuration of a firewall policy, which is described in the Firewall Chapter/Handbook. l The CLI commands for creating and using Security Profile Groups are in the firewall configuration context of the command line structure of settings.

The purpose of Security Profile Groups is just the same as other groups such as Address, Service and VIP groups; it’s to save time and effort in the administration of the FortiGate when there are a lot of policies with a similar pattern of Security Profile use. In a fairly basic network setup with a handful of policies it doesn’t seem like it would be worth the effort to set up groups of security profiles but if you have a large complex configuration with hundreds of policies where many of them uses the same security profiles it can definitely save some effort and help prevent missing adding an important profile from a policy. As an added benefit, when it comes time to add or change the profiles for the policies that use the Security Profile Groups, the changes only have to be make to the group, not each policy.

The most difficult part about using Security Profile Groups is making them visible in the GUI.

Making Security Profile Groups visible in the GUI

By default, the Security Profile Groups are not visible in the GUI; neither the ability to assign one to a policy nor the ability to configure the members of a group. It doesn’t have a option in the Feature Visibility Section to enable or disable the visibility of the feature within the GUI. Instead, the Security Profile Groups become visible in the GUI once one has been created and assigned to a policy. This must be done the first time through the CLI.

Set #1 – Create a Security Profile Group:

Enter the command: config firewall profile-group

Use the edit command to give a name to and create a new Security Profile Group

(profile-group) # edit test-group

Configure the members of the group by setting the name of the desired profile in the field for the related profile/sensor/list. The options are:

av-profile	Name of an existing Antivirus profile.
webfilter-profile	Name of an existing Web filter profile.
dnsfilter-profile	Name of an existing DNS filter profile.
spamfilter-profile	Name of an existing Spam filter profile.
dlp-sensor	Name of an existing DLP sensor.
ips-sensor	Name of an existing IPS sensor.
application-list		Name of an existing Application list.
voip-profile		Name of an existing VoIP profile.
icap-profile		Name of an existing ICAP profile.
waf-profile		Name of an existing Web application firewall profile.
profile-protocoloptions		Name of an existing Protocol options profile.
ssl-ssh-profile		Name of an existing SSL SSH profile.

Example:

set av-profile default

set profile-plrotocol-options default

node_check_object fail! for profile-protocol-options Attribute ‘profile-protocol-options’ MUST be set.

Command fail. Return code -56

Step #2 – Add a Security Profile to a policy

Now that there is group to add to a policy we can configure a policy to allow the use of a Security Policy group. This is also done in the CLI.

In the following example only the command necessary to enable the use and pick of a Security Policy group have been listed.

config firewall policy edit 0 set utm-status enable set profile-type group set profile-group test-group

Step #3 – The appearance in the GUI of the Security Profile Group configuration features

• Under Security Profiles there is a menu item called Profile Groups that can be used to create new and edit existing profile groups.
• In the Edit Policy window for IPv4 and IPv6 policies there is a Use Security Profile Group field to enable or disable the use of the groups.
• In the window, policy groups can be created or edited by clicking on the appropriate icons next to or in the drop down menu l In the policy listing window there is a Security Profiles column.
• Right or left clicking on the icon for the group brings up editing options either via a slide out window or a drop down menu, respectively.

Proxy Option Components

Any time a security profile that requires the use of a proxy is enabled the Proxy Options field will be displayed. Certain inspections defined in security profiles require that the traffic be held in proxy while the inspection is carried out and so the Proxy Options are there to define the parameters of how the traffic will be processed and to what level the traffic will be processed. In the same way that there can be multiple security profiles of a single type there can also be a number of unique Proxy Option profiles so that as the requirements for a policy differ from one policy to the next you can also configure a different Proxy Option profile for each individual policy or you can use one profile repeatedly.

The Proxy Options refer to the handling of the following protocols:

l HTTP l SMTP l POP3 l IMAP l FTP l NNTP l MAPI l DNS l IM

The configuration for each of these protocols is handled separately.

It should also be noted that these configurations apply to only the Security Profiles Proxy-based processes and not the Flow-based processes.

The use of different proxy profiles and profile options

Just like other components of the FortiGate, there is the option for different Proxy Option profiles so that you can be very granular in your control of the workings of the FortiGate. In the case of the Proxy Option profiles the thing that you will want to focus on is the matching up of the correct profile to a firewall policy that is using the appropriate protocols. If you are creating a Proxy Option profile that is designed for policies that control SMTP traffic into your network you only want to configure the settings that apply to SMTP. You do not need or want to configure the HTTP components.

Oversized File Log

This setting is for those that would like to log the occurrence of oversized files being processed. It does not change how they are processed it only enables the FortiGate unit to log that they were either blocked or allowed through. A common practice is to allow larger files through without antivirus processing. This allows you to get an idea of how often this happens and decide on whether or not to alter the settings relating to the treatment of oversized files.

The setting of the threshold for what is considered to be an oversized file is located in the Oversized File / Email Threshold that is found in some of the protocol options for the Proxy Options.

Protocol Port Mapping

While each of the protocols listed has a default TCP port that is commonly used, the level of granularity of control on the FortiGate firewall allows that the port used by the protocols can be individually modified in each separate Profile. It can also be set to inspect any port with flowing traffic for that particular protocol. The headers of the packets will indicate which protocol generated the packet. To optimize the resources of the unit the mapping and inspection of protocols can be enabled or disabled depending on your requirements.

Comfort Clients

When proxy-based antivirus scanning is enabled, the FortiGate unit buffers files as they are downloaded. Once the entire file is captured, the FortiGate unit begins scanning the file. During the buffering and scanning procedure, the user must wait. After the scan is completed, if no infection is found, the file is sent to the next step in the process flow. If the file is a large one this part of the process can take some time. In some cases enough time that some users may get impatient and cancel the download.

The comfort client feature to mitigates this potential issue by feeding a trickle of data while waiting for the scan to complete so as to let the user know that processing is taking place and that there hasn’t been a failure in the transmission. This slow transfer rate continues until the antivirus scan is complete. Once the file has been successfully scanned without any indication of viruses the transfer will proceed at full speed.

If there is evidence of an infection the FortiGate unit caches the URL and drops the connection. The client does not receive any notification of what happened because the download to the client had already started. Instead, the download stops and the user is left with a partially downloaded file. If the user tries to download the same file again within a short period of time, the cached URL is matched and the download is blocked. The client receives the Infection cache message replacement message as a notification that the download has been blocked. The number of URLs in the cache is limited by the size of the cache.

Client comforting is available for HTTP and FTP traffic. If your FortiGate unit supports SSL content scanning and inspection, you can also configure client comforting for HTTPS and FTPS traffic.

Buffering the entire file allows the FortiGate unit to eliminate the danger of missing an infection due to fragmentation because the file is reassembled before examination. Client comforting can send unscanned and therefore potentially infected content to the client. You should only enable client comforting if you are prepared to accept this risk. Keeping the client comforting interval high and the amount low will reduce the amount of potentially infected data that is downloaded.

Oversized File/Email Threshold

This is another feature that is related to antivirus scanning. The FortiGate unit has a finite amount of resources that can be used to buffer and scan a file. If a large file such as an ISO image or video file was to be downloaded this could not only overwhelm the memory of the FortiGate, especially if there were other large files being downloaded at the same time, but could exceed it as well. For this reason, how to treat large files needs to be addressed.

A threshold is assigned to determine what should be considered an oversize file or email. This can be set at any size from 1 MB to 50 MB. Any file or email over this threshold will not be processed by the Antivirus Security Profiles. Once a file is determined to be oversized it must be then determined whether to allow it or to block it.

These settings are not a technical decision but a policy one that will depend on your comfort level with letting files into your network. As there often is, there is a compromise between convenience or ease of use and security. If you want to go for a high peace of mind level you can configure the firewall to block oversized files and thus no

 

SSL/SSH Inspection

files would be coming into the network that have not been scanned. If you are looking for optimizing the memory of the FortiGate unit and making sure that everybody is getting the files they want, you can lower the threshold and allow files that are over the threshold.

It should be noted that in terms of probability that malware is more likely to be found in smaller files than in larger files. A number of administrators take this into account when they lower the default threshold so as to lessen the impact on memory if they see the FortiGate unit going into conserve mode on a regular basis.

Chunked Bypass

The HTTP section allows the enabling of “Chunked Bypass”. This refers to the mechanism in version 1.1 of HTTP that allows a web server to start sending chunks of dynamically generated output in response to a request before actually knowing the actual size of the content. Where dynamically generated content is concerned this means that there is a faster initial response to HTTP requests. From a security stand point it means that the content will not be held in the proxy as an entire file before proceeding.

Allow Fragmented Messages

The specifications of RFC 2046 allow for the breaking up of emails and sending the fragments in parallel to be rebuilt and read at the other end by the mail server. It was originally designed to increase the performance over slower connections where larger email messages were involved. It will depend on your mail configuration if this is even possible for your network but outside of Microsoft Outlook and Outlook Express, not many email clients are set up to break up messages like this. The drawback of allowing this feature is that if malware is broken up between multiple fragments of the message the risk is run that it will not be detected by some antivirus configurations because the code may not all be present at the same time to identify.

Append Email Signature

The Append Email Signature is used when an organization would like to ensure that over and above our in this case underneath the existing personal signatures of the sender, all of the emails going out of their network have the appropriate “boilerplate”, for lack of a better term. These appended emails do not replace existing signatures.

They are as the feature states, appended to the email.

Examples could include things like:

l Without prior approval the email should not be forwarded. l Please be environmentally friendly and don’t print out emails l For questions regarding the purchasing of our products please call…

It can be anything that the organization would like as long as it is in text format. The use of this feature usually works best in an environment where there is some standardization of what goes into the personal signatures of the senders so that there is no duplication or contradiction of information in the signatures.

Firewall policies

The firewall policy is the axis around which most of the other features of the FortiGate firewall revolve. A large portion of the settings in the firewall at some point will end up relating to or being associated with the firewall policies and the traffic that they govern. Any traffic going through a FortiGate unit has to be associated with a policy. These policies are essentially discrete compartmentalized sets of instructions that control the traffic flow going through the firewall. These instructions control where the traffic goes, how it’s processed, if it’s processed and even whether or not it’s allowed to pass through the FortiGate.

When the firewall receives a connection packet, it analyzes the packet’s source address, destination address, and service (by port number). It also registers the incoming interface, the outgoing interface it will need to use and the time of day. Using this information the FortiGate firewall attempts to locate a security policy that matches the packet. If it finds a policy that matches the parameters it then looks at the action for that policy. If it is ACCEPT the traffic is allowed to proceed to the next step. If the Action is DENY or a match cannot be found the traffic is not allowed to proceed.

The 2 basic actions at the initial connection are either ACCEPT or DENY:

• If the Action is ACCEPT, thee policy action permits communication sessions. There may be other packet processing instructions, such as requiring authentication to use the policy or restrictions on th source and destination of the traffic.
• If the Action is DENY, the policy action blocks communication sessions, and you can optionally log the denied traffic. If no security policy matches the traffic, the packets are dropped. A DENY security policy is needed when it is required to log the denied traffic, also called “violation traffic”.

There are two other Actions that can be associated with the policy:

• LEARN – This is a specialized variation on the ACCEPT That is set up to allow traffic but to keep traffic logs so that the administrator can go through them to learn what kind of traffic has to be dealt with. l IPsec – This is an ACCEPT action that is specifically for IPsec VPNs.

There can also be a number of instructions associated with a FortiGate firewall in addition to the ACCEPT or DENY actions, some of which are optional. Instructions on how to process the traffic can also include such things as:

• Logging Traffic l Authentication l Network Address Translation or Port Address Translation l Use Virtual IPs or IP Pools l Caching l Whether the source of the traffic is based on address, user, device or a combination l Whether to treat as regular traffic or IPsec traffic l What certificates to use l Security profiles to apply l Proxy Options l Traffic Shaping

Firewall policy parameters

As mentioned before, for traffic to flow through the FortiGate firewall there must be a policy that matches its parameters:

Incoming Interface(s)

This is the interface or interfaces that the traffic is first connection to the FortiGate unit by. The exception being traffic that the FortiGate generates itself. This is not limited to the physical Ethernet ports found on the device.

The incoming interface can also be a logical or virtual interface such as a VPN tunnel, a Virtual WAN link or a wireless interface.

Outgoing Interface(s)

After the firewall has processed the traffic it needs to leave a port to get to its destination and this will be the interface or interfaces that the traffic leaves by. This interface, like the Incoming Interface is not limited to only physical interfaces.

Source Address(es)

The addresses that a policy can receive traffic from can be wide open or tightly controlled. For a public web server that the world at large should be able to access, the best choice will be “all”. If the destination is a private web server that only the branch offices of a company should be able to access or a list of internal computers that are the only ones allowed to access an external resource then a group of preconfigured addresses is the better strategy.

Additional parameters under the Source Address, though they are not mandatory are:

l Source User(s)

This parameter is based on a user identity that can be from a number of authentication authorities. It will be an account or group that has been set up in advance that can be selected from the drop down menu. The exception to this is the feature that allows the importing of LDAP Users. When the feature is used, a small wizard window will appear to guide the user through the setup. The caveat is that the LDAP server object in the User and Device > Authentication > LDAP Servers section has to be already configured to allow the use of this import feature. l Source Device Type

This parameter is for narrowing down the traffic sending devices to those that the FortiGate is familiar with. Again the contents of this parameter need to be a preconfigured object and these are defined at User and Device > Custom Devices & Groups. This parameter can limit the devices that can connect to this policy to those specific MAC addresses that are already known by the FortiGate and are approved for the policy.

Destination Address(es)

In the same way that the source address may need to be limited, the destination address can be used as a traffic filter. When the traffic is destined for internal resources the specific address of the resource can be defined to better protect the other resources on the network. One of the specialized destination address options is to use a Virtual IP address. The destination address doesn’t need to be internal you can define policies that are only for connecting to specific addresses on the Internet.

Internet service(s)

In this context, and Internet service is a combination of one or more addresses and one or more services associated with a service found on the Internet such as an update service for software.

Schedule

The time frame that is applied to the policy. This can be something as simple as a time range that the sessions are allowed to start such as between 8:00 am and 5:00 pm. Something more complex like business hours that include a break for lunch and time of the session’s initiation may need a schedule group because it will require multiple time ranges to make up the schedule.

Service

The service or service chosen here represent the TCP/IP suite port numbers that will most commonly be used to transport the named protocols or group of protocols. This will be a little different than Application Control which looks more closely at the packets to determine the actual protocol used to create them.

Without all six (possibly 8) of these things matching, the traffic will be declined. Each traffic flow requires a policy and the direction is important as well. Just because packets can go from point A to point B on port X does not mean that the traffic can flow from point B to point A on port X. A policy must be configured for each direction.

When designing a policy there is often reference to the traffic flow, but most communication is a two way connection so trying to determine the direction of the flow can be somewhat confusing. If traffic is HTTP web traffic the user sends a request to the web site, but most of the traffic flow will be coming from the web site to the user. Is the traffic flow considered to be from the user to the web site, the web site to the user or in both directions? For the purposes of determining the direction for a policy the important factor is the direction of the initiating communication. The user is sending a request to the web site so this is the initial communication and the web site is just responding to it so the traffic will be from the users network to the Internet.

A case where either side can initiate the communication like between two internal interfaces on the FortiGate unit would be a more likely situation to require a policy for each direction.

What is not expressly allowed is denied

One of the fundamental ideas that can be found in just about any firewall is the rule than anything that is not expressly allowed is by default denied. This is the foundation for any strategy of protecting your network. Right out of the box, once you have your FortiGate device connected into your network and hooked up with your ISP your network is protected. Nothing is getting out or in so it is not very convenient, but you don’t have to worry that between the time you hooked it up and the point that you got all of the policies in place that someone could have gotten in and done something to your resources. The reason that this needs to be kept in mind when designing policies is because you cannot assume that any traffic will be allowed just because it makes sense to do so. If you want any kind of traffic to make it past the FortiGate firewall you need to create a policy that will allow that traffic. To maintain the protection of the network should also make sure that the any policy you create allows only the traffic you intend to go only to where you specifically want it to go and when you want it to go there.

Example

You have a web server on your network that is meant to provide a collaborative work environment web site for your employees and a partner company for a project over the course of the next 3 months.

It is theoretically possible to allow connections into your network to any device on that network for any service and at any time. The problem with this is that we might not want just anybody looking at those resources. Sadly, no matter how much it is wished otherwise, not everybody on the Internet can be trusted. Which means we now have to be very specific in our instructions as to what traffic to allow into the network. Each step that we take towards being more specific as to what we allow means that there is that much more that is not allowed and the level of protection of a resources is directly proportional to the amount of traffic that is not allowed. If somebody can’t get at it they can’t damage or steal it.

Limiting where the traffic is allowed to go to means that other computers on your network besides the web-server are protected.

• Limiting where the traffic is allowed to come from means that, if feasible, you can limit the systems that can access the web server to just employees or the partner company computers.
• Limiting the services to just web traffic means that a malicious person, even if they were connection from a computer at the partner organization could only use the features of web traffic to do anything malicious.
• Limiting the policy to the time span of the project would mean that even if the IT department forgot to remove the policy after the end of the project than no computer from the other company could be used to do anything malicious through the policy that allowed the traffic.

This is just a very basic example but it shows the underlying principles of how the idea that anything not expressly allowed is by default denied can be used to effectively protect your network.

Policy order

Another important factor in how firewall policies work is the concept of precedence of order or if you prefer a more recognizable term, “first come, first served”.

It is highly likely that even after only a relatively small number of policies have been created that there will be some that overlap or are subsets of the parameters that the policies use to determine which policy should be matched against the incoming traffic. When this happens there has to be a method to determine which policy should be applied to the packet. The method which is used by most firewalls it based on the order of the sequence of the policies.

If all of the policies were placed in a sequential list the process to match up the packet would start at the top of the list and work its way down. It would compare information about the packet, specifically these points of information:

1. The interface the packet connected to the FortiGate firewall
2. The source of the packet. This can include variations of the address, user credentials or device
3. The destination of the packet. This can include address or Internet service
4. The interface the packet would need to use to get to the destination address based on the routing table
5. The service or port the packet is destined for
6. The time that the packet connected to the FortiGate

As soon as the a policy is reached that matches all of the applicable parameters, the instructions of that policy are applied and the search for any other matching policies is stopped. All subsequent policies are disregarded. Only 1 policy is applied to the packet.

If there is no matching policy among the policies that have been configured for traffic the packet finally drops down to what is always the last policy. It is an implicit policy. One of a few that are referred to by the term “policy0”. This policy denies everything.

The implicit policy is made up of the following settings:

l Incoming Interface: any l Source Address: any l Outgoing Interface: any l Destination Address: any l Action: DENY

The only setting that is editable in the implicit policy is the logging of violation traffic.

A logical best practice that comes from the knowledge of how this process works is to make sure that the more specific or specialized a policy is, the closer to the beginning of the sequence it should be. The more general a policy is the higher the likelihood that it could include in its range of parameters a more specifically targeted policy. The more specific a policy is, the higher the probability that there is a requirement for treating that traffic in a specific way.

Example

For security reasons there is no FTP traffic allowed out of a specific subnet so there is a policy that states that any traffic coming from that subnet is denied if the service is FTP, so the following policy was created:

Policy #1

Source Interface	Internal1
Source Address	192.168.1.0/24
Source User(s)	<left at default setting>
Source Device Type	<left at default setting>
Outgoing Interface	WAN1
Destination Address	0.0.0.0/0.0.0.0
Service	FTP
Schedule	always
Action	deny

Now as these things usually go it turns out that there has to be an exception to the rule. There is one very secure computer on the subnet that is allowed to use FTP and once the content has been checked it can them be distributed to the other computer on the subnet. So a second firewall policy is created.

Policy #2

Source Interface	Internal1
Source Address	192.168.1.38/32
Source User(s)	<left at default setting>
Source Device Type	<left at default setting>
Outgoing Interface	WAN1
Destination Address	0.0.0.0/0.0.0.0
Service	FTP
Schedule	always
Action	Allow

By default, a policy that has just been created will be placed last in the sequence so that it is less likely to interfere with existing policies before it can be moved to its intended position. If you look at Policy #2 you will notice that it is essentially the same as Policy #1 exempt for the Source Address and the Action. You will also notice that the Source Address of the Policy #2 is a subset of the Source address in policy #1. This means that if nothing further is done, Policy #2 will never see any traffic because the traffic will always be matched by Policy #1 and processed before it has a chance to reach the second policy in the sequence. For both policies to work as intended Policy #2 needs to be moved to before Policy #1 in the sequence.

Policy Identification

There are two ways to identify a policy. The most obvious is the policy name and this is easily read by humans, but with a little effort it is possible to have a policy without a name, therefore every policy has an ID number.

When looking at the policy listing it can appear as if the policies are identified by the sequence number in the far left column. The problem is that this number changes as the position of the policy in the sequence changes. The column that correctly identifies the policy, and the value sticks with the policy is the “ID” column. This column is not shown by default in the listing but can be added to the displayed columns by right clicking on the column heading bar and selecting it from the list of possible columns.

When looking in the configuration file the sequence is based upon the order of the policies as they are in the file just as they are in the list in the GUI. However, if you need to edit the policy in the CLI you must use the ID number.

UUID Support

Universally Unique Identifier (UUID) attributes have been added to policies to improve functionality when working with FortiManager or FortiAnalyzer units. If required, the UUID can be set manually through the CLI.

CLI Syntax:

config firewall {policy/policy6/policy46/policy64} edit 1 set uuid <example uuid: 8289ef80-f879-51e2-20dd-fa62c5c51f44> next

end

Access Control Lists

Access Control Lists (ACLs) in the FortiOS firmware could be considered a granular or more specifically targeted blacklist. These ACLs drop IPv4 or IPv6 packets at the physical network interface before the packets are analyzed by the CPU. On a busy appliance this can really help the performance.

The ACL feature is available on FortiGates with NP6-accelerated interfaces. ACL checking is one of the first things that happens to the packet and checking is done by the NP6 processor. The result is very efficient protection that does not use CPU or memory resources.

Incoming Interfaces

The configuration of the Access Control List allow you to specify which in interface the ACL will be applied to. There is a hardware limitation that needs to be taken into account. The ACL is a Layer 2 function and is offloaded to the ISF hardware, therefore no CPU resources are used in the processing of the ACL. It is handled by the inside switch chip which can do hardware acceleration, increasing the performance of the FortiGate. The drawback is that the ACL function is only supported on switch fabric driven interfaces. It also cannot be applied to hardware switch interfaces or their members. Ports such as WAN1 or WAN2 that are found on some models that use network cards that connect to the CPU through a PCIe bus will not support ACL.

Addresses

Because the address portion of an entry is based on a FortiGate address object, id can be any of the address types used by the FortiGate, including address ranges. There is further granularity by specifying both the source and destination addresses. The traffic is blocked not on an either or basis of these addresses but the combination of the two, so that they both have to be correct for the traffic to be denied. Of course, If you want to block all of the traffic from a specific address all you have to do is make the destination address “all”.

Because the blocking takes place at the interface based on the information in the packet header and before any processing such as NAT can take place, a slightly different approach may be required. For instance, if you are trying to protect a VIP which has an external address of x.x.x.x and is forwarded to an internal address of y.y.y.y, the destination address that should be used is x.x.x.x, because that is the address that will be in the packet’s header when it hits the incoming interface.

Services

Further granulation of the filter by which the traffic will be denied is done by specifying which service the traffic will use.

How Packets are handled by FortiOS

To give you idea of what happens to a packet as it makes its way through the FortiGate unit here is a brief overview. This particular trip of the packet is starting on the Internet side of the FortiGate firewall and ends with the packet exiting to the Internal network. An outbound trip would be similar. At any point in the path if the packet is going through what would be considered a filtering process and if fails the filter check the packet is dropped and does not continue any further down the path.

This information is covered in more detail in other in the Troubleshooting chapter of the FortiOS Handbook in the Life of a Packet section.

The incoming packet arrives at the external interface. This process of entering the device is referred to as ingress.

Step #1 – Ingress

1. Denial of Service Sensor
2. IP integrity header checking

Interfaces and Zones

3. IPsec connection check
4. Destination NAT
5. Routing

Step #2 – Stateful Inspection Engine

1. Session Helpers
2. Management Traffic
3. SSL VPN
4. User Authentication
5. Traffic Shaping
6. Session Tracking
7. Policy lookup

Step #3 – Security Profiles scanning process

1. Flow-based Inspection Engine
2. IPS
3. Application Control
4. Data Leak Prevention
5. Email Filter
6. Web Filter
7. Anti-virus
8. Proxy-based Inspection Engine
9. VoIP Inspection
10. Data Leak Prevention
11. Email Filter
12. Web Filter
13. Anti-virus
14. ICAP

Step #4 – Egress

1. IPsec
2. Source NAT
3. Routing

Interfaces and Zones

A Firewall is a gateway device that may be the nexus point for more than 2 networks. The interface that the traffic is coming in on and should be going out on is a fundamental concern for the purposes of routing as well as security. Routing, policies and addresses are all associated with interfaces. The interface is essentially the connection point of a subnet to the FortiGate unit and once connected can be connected to other subnets.

The following types of interfaces are found on a FortiGate:

Interfaces and Zones

• Interface , this can refer to a physical or virtual interface l Zone
• Virtual Wired Pair

Interfaces

Physical interfaces or not the only ones that need to be considered. There are also virtual interfaces that can be applied to security policies. VLANs are one such virtual interface. Interfaces if certain VPN tunnels are another.

Policies are the foundation of the traffic control in a firewall and the Interfaces and addressing is the foundation that policies are based upon. Using the identity of the interface that the traffic connects to the FortiGate unit tells the firewall the initial direction of the traffic. The direction of the traffic is one of the determining factors in deciding how the traffic should be dealt with. You can tell that interfaces are a fundamental part of the policies because, by default, this is the criteria that the policies are sorted by.

Zones

Zones are a mechanism that was created to help in the administration of the firewalls. If you have a FortiGate unit with a large number of ports and a large number of nodes in you network the chances are high that there is going to be some duplication of policies. Zones provide the option of logically grouping multiple virtual and physical FortiGate firewall interfaces. The zones can then be used to apply security policies to control the incoming and outgoing traffic on those interfaces. This helps to keep the administration of the firewall simple and maintain consistency.

For example you may have several floors of people and each of the port interfaces could go to a separate floor where it connects to a switch controlling a different subnet. The people may be on different subnets but in terms of security they have the same requirements. If there were 4 floors and 4 interfaces a separate policy would have to be written for each floor to be allowed out on to the Internet off the WAN1 interface. This is not too bad if that is all that is being done, but now start adding the use of more complicated policy scenarios with Security Profiles, then throw in a number of Identity based issues and then add the complication that people in that organization tend to move around in that building between floors with their notebook computers.

Each time a policy is created for each of those floors there is a chance of an inconsistency cropping up. Rather than make up an additional duplicate set of policies for each floor, a zone can be created that combines multiple interfaces. And then a single policy can created that uses that zone as one side of the traffic connection.

Virtual Wire Pair

The simplified explanation is that two interfaces are set up so that whatever traffic goes through one of the pair is replicated on the other. They are most commonly used when scanning is needed on an interface without interfering with the traffic. On interface “A”, everything goes through unaffected. The replicated traffic on interface “B” is sent to an analysand of some kind and the traffic can be thoroughly scanned without worry of impacting performance.

When two physical interfaces are setup as a Virtual Wire Pair, they will have no IP addressing and are treated similar to a transparent mode VDOM. All packets accepted by one of the interfaces in a virtual wire pair can only exit the FortiGate through the other interface in the virtual wire pair and only if allowed by a virtual wire pair firewall policy. Packets arriving on other interfaces cannot be routed to the interfaces in a virtual wire pair. A FortiGate can have multiple virtual wire pairs.

Access Control Lists

You cannot add VLANs to virtual wire pairs. However, you can enable wildcard VLANs for a virtual wire pair. This means that all VLAN-tagged traffic can pass through the virtual wire pair if allowed by virtual wire pair firewall policies.

FortiGate Modes

The FortiGate unit has a choice of modes that it can be used in, either NAT/Route mode or Transparent mode. The FortiGate unit is able to operate as a firewall in both modes, but some of its features are limited in Transparent mode. It is always best to choose which mode you are going to be using at the beginning of the set up. Once you start configuring the device, if you want to change the mode you are going to lose all configuration settings in the change process.

NAT/Route Mode

NAT/Route mode is the most commonly used mode by a significant margin and is thus the default setting on the device. As the name implies the function of NAT is commonly used in this mode and is easily configured but there is no requirement to use NAT. The FortiGate unit performs network address translation before IP packets are sent to the destination network.

These are some of the characteristics of NAT/Route mode:

l Typically used when the FortiGate unit is a gateway between private and public networks. l Can act as a router between multiple networks within a network infrastructure. l When used, the FortiGate unit is visible to the networks that is connected to. l Each logical interface is on a distinct subnet. l Each Interface needs to be assigned a valid IP address for the subnet that it is connected to it.

Transparent Mode

Transparent mode is so named because the device is effectively transparent in that it does not appear on the network in the way that other network devices show as a nodes in the path of network traffic. Transparent mode is typically used to apply the FortiOS features such as Security Profiles etc. on a private network where the FortiGate unit will be behind an existing firewall or router. These are some of the characteristics of Transparent mode:

l The FortiGate unit is invisible to the network. l All of its interfaces are on the same subnet and share the same IP address. l The FortiGate unit uses a Management IP address for the purposes of Administration. l Still able to use NAT to a degree, but the configuration is less straightforward

In Transparent mode, you can also perform NAT by creating a security policy or policies that translates the source addresses of packets passing through the FortiGate unit as well as virtual IP addresses and/or IP pools.

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

FortiGate Modes

• 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 Protection 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

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

What’s new for the Firewall in 5.6

New Firewall Features in 5.6.0

Optimization of the firewall Service cache (355819)

In order to improve the efficiency and performance of the firewall Service cache, the following improvements have been made:

• The logic behind the structure of the cache has been simplified. Instead of storing ranges of port numbers, we store each individual port number in the cache
• Separate caches are created for each VDOM so that cache searches are faster.
• The performance of more frequently used cases has been increased l Hash tables are used to improve the performance of complex cases. These could include such instances as:
• service names tied to specific IP Ranges
• redefinition (one port number with multiple service names)

New CLI option to prevent packet order problems for sessions offloaded to NP4 or NP6 (365497)

In order to prevent the issue of a packet, on FortiGate processing a heavy load of traffic, from being processed out of order, a new setting has been added to better control the timing of pushing the packets being sent to NP units.

The new option, delay-tcp-npc-session, has been added into the context of config firewall policy within the CLI

config firewall policy edit <Integer for policy ID> set delay-tcp-npc-session

end

Policy may not be available on units not using NP units.

GUI changes to Central NAT (371516)

The Central NAT configuration interface prevents the accidental occurrence of being able to select “all” and “none” as two objects for the same field. It only allows the selecting of a single IP pool, though it is still possible to select multiple IP pools within the CLI.

Max value for Firewall User authentication changed (378085)

Previously, the maximum time that a member of a firewall user group could remain authenticated without any activity was 24 hours (1440 minutes). The maximum value for this setting has been changed to 72 hours (4320 minutes). This allow someone to log in but not be kicked off the system due to inactivity over the course of a weekend.

The syntax in the CLI for configuring this setting is:

config user group edit <name of user group> set authtimeout 4320

end

Changes to default SSL inspection configuration (380736)

SSL is such a big part of normal traffic that SSL certificate inspection is no longer disabled by default. SSL inspection is not mandatory in both the CLI and GUI when it is applicable. The default setting is the Certificate Inspection level. As a result there have been a few changes within the CLI and the GUI.

CLI

The setting SSL-SSH-Profile, is a required option, with the default value being “certificate-inspection”, when it is applicable in the following tables:

• profile-group l firewall.policy l firewall.policy6, l firewall.proxy-policy

The following default profiles are read-only:

• certificate-inspection l deep-ssl-inspection

GUI

IPv4/IPv6 Policy and Explicit Proxy Policy edit window l The configuration and display set up for SSL/SSH Inspection is now similar to “profile-protocol-option” option l The disable/enable toggle button is no longer available for the Profile Protocol Option l The default profile is set to “certificate-inspection” IPv4/IPv6 Policy, Explicit Proxy Policy list page l There is validation for SSL-SSH-Profile when configuring UTM profiles SSL/SSH Inspection list page l There is no delete menu on GUI for default ssl profiles l The “Edit” menu has been changed to “View” for default SSL profiles l The default SSL profile entries are considered an implicit class and are grayed out SSL/SSH Inspection edit window l The only input for default SSL profiles is now download/view trusted certificate links l To return to the List page from default SSL profiles, the name of the button is now “Return” Profile Group edit window l There is no check box for SSL-SSH-Profile. It is always required.

Add firewall policy comment field content to log messages (387865)

There has been a need by some customer to have some information in the logs that includes specific information about the traffic that produced the log. The rather elegant solution is that when the log-policy-comment option is enabled, the comment field from the policy will be included in the log. In order to make the logs more useful regarding the traffic just include a customized comment in the policy and enable this setting.

Syntax

config system settings set log-policy-comment [enable | disable] end

l This setting is for all traffic and security logs. l It can be select on a per VDOM basis

Learning mode changes profile type to single (387999)

The Learning mode does not function properly when it is applied to a policy that has a UTM profile group applied to it. The logging that should be taking place from the Learning Mode profiles does not occur as intended, and the

Automatically switching the profile type to single on a policy with Learning mode enabled prevents it from being affected by the UTM policy groups.

MAC address authentication in firewall policies and captive portals (391739)

When enabled, a MAC authentication request will be sent to fnbamd on any traffic. If the authentication receives a positive response, login becomes available. If the response is negative the normal authentication process takes over.

CLI

New option in the firewall policy setting

config firewall policy edit <policy ID> set radius-mac-auth-bypass [enable |disable] end

New option in the interface setting

config system interface edit <interface> set security-mode captive-portal set security-mac-auth-bypass end

Display resolved IP addresses for FQDN in policy list (393927)

If a FQDN address object is used in a policy, hovering the cursor over the icon for that object will show a tool tip that lists the parameters of the address object. This tool tip now includes the IP address that the FQDN resolves to.

Added comment for acl-policy, interface-policy and DoS-policy (396569)

A comment field has been added to the following policy types: l acl-policy l interface-policy l DoS-policy

Comments of up to 1023 characters can be added through the CLI.

Examples:

DoS policy

config firewall DoS-policy

edit 1

set comment “you can put a comment here(Max 1023).”

set interface “internal” set srcaddr “all” set dstaddr “all” set service “ALL” config anomaly edit “tcp_syn_flood” set threshold 2000

next

end

end

Interface policy

config firewall interface-policy

edit 1

set comment “you can put a comment here(max 1023).”

set interface “dmz2” set srcaddr “all” set dstaddr “all” set service “ALL” end

Firewall ACL

config firewall acl

edit 1 set status disable

set comment “you can put a comment here(max 1023).”

set interface “port5” set srcaddr “all” set dstaddr “all” set service “ALL”

end

Internet service settings moved to more logical place in CLI (397029)

The following settings have moved from the application context of the CLI to the firewall context:

 

internet-service internet-service-custom

Example of internet-service

config firewall internet-service 1245324

set name “Fortinet-FortiGuard” set reputation 5 set icon-id 140 set offset 1602565

config entry

edit 1

set protocol 6

set port 443 set ip-range-number 27 set ip-number 80

next

edit 2

set protocol 6 set port 8890 set ip-range-number 27 set ip-number 80

next

edit 3

set protocol 17 set port 53

set ip-range-number 18

set ip-number 31

next

edit 4

set protocol 17 set port 8888 set ip-range-number 18

set ip-number 31 next

end

Example of internet-service-custom

config firewall internet-service-custom

edit “custom1” set comment “custom1”

config entry

edit 1

set protocol 6 config port-range

edit 1

set start-port 30 set end-port 33

next

end

set dst “google-drive” “icloud”

next

end

next

end

Example of get command:

get firewall internet-service-summary

Version: 00004.00002

Timestamp: 201611291203

Number of Entries: 1349

Certificate key size selection (397883)

FortiOS will now support different SSL certificate key lengths from the HTTPS server. FortiOS will select a key size from the two options of 1024 and 20148, to match the key size (as close as possible, rounding up) on the HTTS server. If the size of the key from the server is 512 or 1024 the proxy will select a 1024 key size. If the key size from the servers is over 1024, the proxy will select a key size of 2048.

CLI changes:

In ssl-ssh-profile remove:

• certname-rsa l certname-dsa l certname-ecdsa

In vpn certificate setting, add the following options :

• certname-rsa1024 l certname-rsa2048 l certname-dsa1024 l certname-dsa2048 l certname-ecdsa256 l certname-ecdsa384

AWS API integration for dynamic firewall address object (400265)

Some new settings have been added to the CLI that will support instance information being retrieved directly from the AWS server. The IP address of a newly launched instance can be automatically added to a certain firewall address group if it meets specific requirements. The new address type is:ADDR_TYPE_AWS New CLI configuration settings:

The AWS settings

config aws set access-key set secret-key set region set vpc-id set update-interval

l access-key – AWS access key. l secret-key – AWS secret key. l region – AWS region name. vpc-id – AWS VPC ID. update-interval – AWS service update interval (60 – 600 sec, default = 60).

The AWS address:

config firewall address edit <address name> set type aws set filter <filter values>

The filter can be a combination of any number of conditions, as long as the total length of filter is less than 2048 bytes. The syntax for the filter is:

<key1=value1> [& <key2=value2>] [| <key3=value3>]

For each condition, it includes a key and value, the supported keys are:

1. instanceId, (e.g. instanceId=i-12345678)
2. instanceType, (e.g. instanceType=t2.micro)
3. imageId, (e.g. imageId=ami-123456)
4. keyName, (e.g. keyName=aws-key-name)
5. architecture, (e.g. architecture=x86)
6. subnetId, (e.g. subnetId=sub-123456)
7. availabilityzone, (e.g. placement.availabilityzone=us-east-1a)
8. groupname, (e.g. placement.groupname=group-name)
9. tenancy, (e.g. placement.tenancy=tenancy-name)
10. privateDnsName, (e.g. privateDnsName=ip-172-31-10-211.us-west-2.compute.internal)
11. publicDnsName, (e.g. publicDnsName=ec2-54-202-168-254.us-west-2.compute.amazonaws.com)
12. AWS instance tag, each tag includes a key and value, the format of tag set is: tag.Name=Value, maximum of 8 tags are supported.

Internet service configuration (405518)

To make the CLI configuration of Internet service configuration more intuitive, the settings for Internet service in Explicit Web proxy are closer to those in the Firewall police. An Internet service enable switch has been added to the Explicit Web proxy with the same text description as the Firewall policy.

CLI:

The relevant options in the firewall policy are:

config firewall policy edit 1 set internet-service enable

set internet-service-id 327681 1572864 917519 393225 1572888 1572877 917505

next end

The Explicit Web proxy is now has these options:

config firewall proxy-policy

edit 1

set uuid f68e0426-dda8-51e6-ac04-37fc3f92cadf set proxy explicit-web set dstintf “port9” set srcaddr “all” set internet-service 2686980 set action accept set schedule “always” set logtraffic all

next end

Changes to SSL abbreviate handshake (407544)

The SSL handshake process has changed to make troubleshooting easier.

• In order to better identify which clients have caused SSL errors, the WAD SSL log will use the original source address rather than the source address of packets. l The return value of wad_ssl_set_cipher is checked.
• The wad_ssl_session_match has been removed because it will add the connection into bypass cache and bypass further inspection.
• DSA and ECDSA certificates are filtered for admin-server-cert l cert-inspect is reset after a WAD match to a Layer 7 policy l An option to disable the use of SSL abbreviate handshake has been added

CLI addition

config firewall ssl setting set abbreviate-handshake [enable|disable]

NGFW mode in the VDOM – NAT & SSL Inspection considerations (407547)

Due to how the NGFW Policy mode works, it can get complicated in the two areas of NAT and SSL Deep

Inspection. To match an application against a policy, some traffic has to pass through the FortiGate in order to be properly identified. Once that happens may end up getting mapped to a different policy, where the new policy will be appropriately enforced.

NAT

In the case of NAT being used, the first policy that is triggered to identify the traffic might require NAT enabled for it to work correctly. i.e., without NAT enabled it may never be identified, and thus not fall through. Let’s use a very simple example:

Policy 1: Block Youtube

Policy 2: Allow everything else (with NAT enabled)

Any new session established will never be identified immediately as Youtube, so it’ll match policy #1 and let some traffic go to try and identify it. Without NAT enabled to the Internet, the session will never be setup and thus stuck here.

Solution:

NAT for NGFW policies must be done via Central SNAT Map

Central SNAT Map entries now have options for ‘srcintf’, ‘dstintf’ and ‘action’.

• If no IP-pools are specified in the Central SNAT entry, then the outgoing interface address will be used.
• NGFW policies now must use a single default ssl-ssh-profile. The default ssl-ssh-profile can be configured under the system settings table.

SSL

In the case of SSL inspection, the issue is a bit simpler. For each policy there are 3 choices:

1. No SSL,
2. Certificate Only
3. Deep Inspection.

For 1. and 2. there is no conflict and the user could enable them inter-changeably and allow policy fallthrough.

The issue happens when:

• The first policy matched, uses Certificate Only
• After the application is detected, it re-maps the session to a new policy which has Deep Inspection enabled This switching of behavior is the main cause of the issue.

Solution:

• Multiple SSL profiles have been replaced with a single page of settings l The user can setup exemptions for destination web category, source IP or etc.

CLI

Changes

config system settings set inspection-mode flow set policy-mode [standard | ngfw]

Has been changed to:

config system settings set inspection-mode flow

set ngfw-mode [profile-based | policy-based]

l ngfw-mode – Next Generation Firewall mode. l profile-based – Application and web-filtering is configured using profiles applied to policy entries. l policy-based – Application and web-filtering is configured as policy match conditions.

Additions

Setting the vdom default ssl-ssh-profile

config system settings set inspection-mode flow set ngfw-mode policy-based set ssl-ssh-profile <profile>

ssl-ssh-profile – VDOM SSL SSH profile.

Setting srcintf, dstintf, action on the central-snat policy

config firewall central-snat-map edit <id> set srcintf <names or any> set dstintf <names or any> set action (permit | deny)

l srcintf – Source interface name. l dstintf – Destination interface name. l action – Action of central SNAT policy.

GUI

System settings, VDOM settings list/dialog: l A field has been added to show the default ssl-ssh-profile IPv4/v6 Policy list and dialogs:

• In NGFW policy-based mode, there are added tool tips under NAT columns/fields to indicate that NAT must be configured via Central SNAT Map. Additionally, links to redirect to Central SNAT list were added.
• Default ssl-ssh-profile is shown in the policy list and dialog for any policies doing NGFW (`application, application-categories, url-categories`) or UTM (`av-profile etc.) inspection. l Default ssl-ssh-profile is disabled from editing in policy list dialog Central SNAT Policy list and dialogs:
• In both profile-based & policy-basedngfw-mode, fields for srcintf, dstintf were added to Central

SNAT policies entries.

• In policy-based mode only, a toggle-switch for NAT Action was added in Central SNAT policy dialog. The action is also configurable from the Action column in Central SNAT policy list.

SSL/SSH Inspection list:

• In policy-based mode only, the navigation bar link to SSL/SSH Inspection redirects to the profiles list l In policy-based mode only, the SSL/SSH Inspection list table indicates which profile is the current VDOM default.

Additionally, options are provided in the list menu and context menu to change the current VDOM default.

Support HTTP policy for flow-based inspection (411666)

It is possible to impliment an HTTP-policy in a VDOM that is using the Flow-based inspection mode. Enabling the

HTTP-policy causes the traffic to be redirected to WAD so that the traffic can be properly matched and processed.

 

Support for CA chain downloading to improve certificate verification (369270)

During certificate verification, if the certificate chain is not complete and CA issuer information exists in the certifcate, FortiOS attempts to download intermediate/root CAs from the HTTP server and attempts to perform chain verification. The downloaded CAs are saved in a cache (max 256) to be re-used for future certificate validation. CAs are removed from the cache if they are inactive or not needed for more than 1 hour.

CA chain downloading is used to improve verification results for certificates that are difficult to verify. The CAs are kept in the cache to improve performance.

New WAN Optimization Features in 5.6

WAN Optimization GUI changes (283422)

Improvements have been made to the WAN Optimization Profiles and Authentication Group pages.

New Proxy Features in 5.6

Explicit proxy supports multiple incoming ports and port ranges (402775, 398687)

Explicit proxy can now be configured to listen on multiple ports on the same IP as well as listen for HTTP and HTTPS on those same (or different) ports.

Define the IP ranges using a hyphen (–). As shown below, port_high is not necessary to specify if port_low is equal to port_high.

CLI syntax

config web-proxy explicit set http-incoming-port <port_low> [-<port_high>]

end

Explicit proxy supports IP pools (402221)

Added a new command, poolname, to config firewall proxy-policy. When setting the IP pool name with this command, the outgoing IP will be selected.

CLI syntax

config firewall proxy-policy edit <example> set poolname <name>

end

New Proxy Features

Option to remove unsupported encoding from HTTP headers (392908)

Added a new command to config web-proxy profile that, when enabled, allows the FortiGate to strip out unsupported encoding from request headers, and correctly block banned words. This is to resolve issues when attempting to successfully block content using Google Chrome.

CLI syntax:

config web-proxy profile edit <example> set strip-encoding {enable | disable}

end

New authentication process for explicit web proxying (386474, 404355)

While in Proxy inspection mode, explicit proxy options can be set under Network > Explicit Proxy. These settings will affect what options are available for creating proxy policies under Policy & Objects > Proxy Policy. From here you may create new policies with Proxy Type set to either Explicit Web, Transparent Web, or FTP.

Authentication will be triggered differently when configuring a transparent HTTP policy. Before such a policy can be configured, you must enable HTTP Policy Redirect under Security Profiles > Proxy Options.

Added Internet services to explicit proxy policies (386182)

Added two new commands to config firewall proxy-policy. FortiOS can use the Internet Service Database (introduced in 5.4.1) as the web-proxy policy matching factor.

CLI syntax:

config firewall proxy-policy edit <example> set internet-service <application-id> set internet-service-custom <application-name>

Virtual WAN link in an explicit proxy firewall policy (385849, 396780)

Virtual WAN link (VWL) interfaces may now be set as the destination interface in an explicit proxy policy, routing traffic properly using basic virtual WAN link load balance settings. This is now configurable through both the CLI under firewall proxy-policy and the GUI.

Added application ID and category setting on the explicit proxy enabled service (379330)

This feature introduces support for application ID/category in the service of explicit proxy as one policy selection factor. The intent is to identify the application type based on the HTTP request with IPS application type detection function. It is similar to the current firewall explicit address, but it is implemented as a service type, and you can select the application ID/ category to define explicit service. Of course, now it must be an HTTP-based application.

CLI syntax config firewall service custom

Proxy Features in 5.6

edit “name” set app-service-type [disable|app-id|app-category]

next

end

Explicit Proxy – populate pac-file-url in transparent mode (373977)

You can now use manageip to populate pac-file-url in transparent opmode. Previously, in the CLI, when displaying pac-file-url, the code only tries to get interface IP to populate pac-file-url.

CLI syntax

config vdom edit root config system settings set opmode transparent set manageip 192.168.0.34/24

end config web-proxy explicit set pac-file-server-status enable get pac-file-url [url.pac]

end

SSL deep inspection OCSP support for Explicit Proxy (365843)

OCSP support for SSL deep inspection added for Explicit Proxy.

CLI syntax

config vpn certificate setting set ssl-ocsp-status [enable|disable] set ssl-ocsp-option [certificate|server]

end

Timed out authentication requests are now logged (357098)

CLI syntax

config web-proxy explicit set trace-auth-no-rsp [enable|disable] end

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 Introduction     How does a FortiGate Protect Your Network? 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 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.