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.

FortiGate Firewall Components

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

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

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

The features of FortiOS include but are not limited to:

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

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

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