Category Archives: FortiGate

Security policy 0

Security policy 0

Any security policy that is automatically added by the FortiGate unit has a policy ID number of zero (0). The most common reasons the FortiGate unit creates this policy is:

  • The IPsec policy for FortiAnalyzer (and FortiManager version 3.0) is automatically added when an IPsec connection to the FortiAnalyzer unit or FortiManager is enabled.
  • The policy to allow FortiGuard servers to be automatically added has a policy ID number of zero.
  • The (default) drop rule that is the last rule in the policy and that is automatically added has a policy ID number of zero.
  • When a network zone is defined within a VDOM, the intra-zone traffic set to allow or block is managed by policy 0 if it is not processed by a configured security policy.

This policy can appear in logs but will never appear in the security policy list, and therefore, can never be repositioned in the list.

When viewing the FortiGate firewall logs, you may find a log field entry indicating policyid=0. The following log message example indicates the log field policyid=0 in bold.

2008-10-06 00:13:49 log_id=0022013001 type=traffic subtype=violation pri=warning vd=root SN=179089 duration=0 user=N/A group=N/A rule=0 policyid=0 proto=17 service=137/udp app_type=N/A status=deny src=10.181.77.73 srcname=10.181.77.73 dst=10.128.1.161 dstname=10.128.1.161 src_int=N/A dst_int=”Internal” sent=0 rcvd=0 src_port=137 dst_port=137 vpn=N/A tran_ip=0.0.0.0 tran_port=0


Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

Local-In policies

Local-In policies

On the FortiGate unit, there are a number of protocols and traffic that is specific to the internal workings of FortiOS. For many of these traffic sources, you can identify a specific port/IP address for this self-originating traffic. The following traffic can be configured to a specific port/IP address:

  • SNMP l Syslog l alert email l FortiManager connection IP l FortiGuard services l FortiAnalyzer logging
  • NTP l DNS
  • Authorization requests such as RADIUS
  • FSSO

Security policies control the flow of traffic through the FortiGate unit. The FortiGate unit also includes the option of controlling internal traffic, that is, management traffic.

Each interface includes an allow access configuration to allow management access for specific protocols. Local policies are set up automatically to allow all users all access. Local-in policies takes this a step further, to enable or restrict the user with that access. This also extends beyond the allow access selection.

Local-in policies are configured in the CLI with the commands:

config firewall local-in-policy edit <policy_number> set intf <source_interface> set srcaddr <source_address> set dstaddr <destination_address> set action {accept | deny} set service <service name> set schedule <schedule_name> set comments <string>

end

For example, you can configure a local-in policy so that only administrators can access the FortiGate unit on weekends from a specific management computer at 192.168.21.12, represented by the address object mgmtcomp1, using SSH on port 3 (192.168.21.77 represented by the address object FG-port3) using the Weekend schedule which defines the time the of access.

config firewall local-in-policy edit <1> set intf port3 set srcaddr mgmt-comp1 set dstaddr FG-port3 set action accept set service SSH set schedule Weekend

end

You can also disable a policy should there be a requirement to turn off a policy for troubleshooting or other purpose. To disable a policy enter the commands:

Security policy 0

config firewall local-in-policy edit <policy_number> set status disable

end

Use the same commands with a status of enable to use the policy again.

It is also an option to dedicate the interface as HA management interface by using the setting: set ha-mgmt-intf-only enable

Local-in policies are also supported for IPv6 by entering the command: config firewall local-in-policy6.

While there is a section under Policy & Objects for viewing the existing Local In Policy configuration, policies cannot be created or edited here in the GUI. The Local In polices can only be created or edited in the CLI.


Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

GUI and CLI

GUI and CLI

Now in FortiGate, there are two places that IPS can be enabled, in a firewall policy and in an interface policy. In the firewall policy implementation, IPS sensor can be configured in both CLI and GUI. When adding an IPS sensor to an interface policy it must be done through the CLI. There is no GUI input window for the “Interface Policy”. There is however, a DoS Policy section in the GUI.


Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

Dropped, flooded, broadcast, multicast and L2 packets

Dropped, flooded, broadcast, multicast and L2 packets

In many evaluation or certification tests, FortiGate firewall is often required to log any packets dropped by the firewall. In most of cases, these packets are of invalid headers so firewall just drops them silently. It is natural to forward all these packets to IPS first so FortiGate firewall is able to generate logs for invalid packets.

Flooded, broadcast and multicast traffics do not reach any of services in the forwarding path. They can be inspected by the interface policy as long as they match the addresses defined. Potentially, L2 packets can also be sent to IPS for inspection through interface-policy, but it is not enabled in FortiOS 4.0.


Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

Traffic destined to the FortiGate unit

Traffic destined to the FortiGate unit

IPS enabled in firewall policies can only inspect the traffic pass through FortiGate unit, not the traffic destined to FortiGate unit. Enabling IPS in interface-policy allows IPS to pick up any packet on the interface so it is able to inspect attacks targeting FGT.


Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

IPv6 IPS

IPv6 IPS

IPv6 IPS signature scan can be enabled by interface policy. The user can create an normal IPS sensor and assign it to the IPv6 interface policy.

config firewall interface-policy6 edit 1 set interface “port1” set srcaddr6 “all” set dstaddr6 “all” set service6 “ANY” set ips-sensor-status enable set ips-sensor “all_default”

next

end


Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

One-Arm IDS

One-Arm IDS

Interface-based policy only defines what and how IPS functions are applied to the packets transmitted by the interface. It works no matter if the port is used in a forwarding path or used as an One-Arm device.

To enable One-Arm IDS, the user should first enable sniff-mode on the interface, config system interface

edit port2 set ips-sniffer-mode enable

next

end

Once sniff-mode is turned on, both incoming and outgoing packets will be dropped after IPS inspections. The port can be connected to a hub or a switch’s SPAN port. Any packet picked up by the interface will still follow the interface policy so different IPS and DoS anomaly checks can be applied.


Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

DoS protection

DoS protection

Denial of Service (DoS) policies are primarily used to apply DoS anomaly checks to network traffic based on the FortiGate interface it is entering as well as the source and destination addresses. DoS checks are a traffic anomaly detection feature to identify network traffic that does not fit known or common traffic patterns and behavior. A common example of anomalous traffic is the denial of service attack. A denial of service occurs when an attacking system starts an abnormally large number of sessions with a target system. The large number of sessions slows down or disables the target system, so that legitimate users can no longer use it.

DoS policies are similar to firewall policies except that instead of defining the way traffic is allowed to flow, they keep track of certain traffic patterns and attributes and will stop traffic displaying those attributes. Further, DoS policies affect only incoming traffic on a single interface. You can further limit a DoS policy by source address, destination address, and service.

DoS configurations have been changed a couple of times in the past. In FortiOS 4.0, DoS protection is moved to the interface policy, so when it is enabled, it is the first thing checked when a packet enters FortiGate. Because of this early detection, DoS policies are a very efficient defense that uses few resources. Denial of service attacks, for example, are detected and its packets dropped before requiring security policy look-ups, antivirus scans, and other protective but resource-intensive operations.

A DoS policy examines network traffic arriving at an interface for anomalous patterns usually indicating an attack. This does not mean that all anomalies experience by the firewall are the result of an intentional attack.

Because an improperly configured DoS anomaly check can interfere with network traffic, no DoS checks are preconfigured on a factory default FortiGate unit. You must create your own before they will take effect. Thresholds for newly created sensors are preset with recommended values that you can adjust to meet the needs of your network.

To create a Denial of Service policy determine if it needs to be an IPv4 or IPv6 policy, then go to:

Policy & Objects > IPv4 DoS Policy for IPv4.

Policy & Objects > IPv6 DoS Policy for IPv6.

The Enable SSH Deep Scan feature is enabled by default when creating a new

SSL/SSH Inspection profile. There are situations were this feature can cause issues so be sure that you would like it enabled before applying it.

 

Settings used in configuring DoS

Incoming interface

The interface to which this security policy applies. It will be the that the traffic is coming into the firewall on.

Source address

This will be the address that the traffic is coming from and must be a address listed in the Address section of the Firewall Objects. This can include the predefined “all” address which covers any address coming in on any interface. Multiple addresses or address groups can be chosen

Destination address

This will be the address that the traffic is addressed to. In this case it must be an address that is associated with the firewall itself. For instance it could be one of the interface address of the firewall, a secondary IP address or the interface address assigned to a Virtual IP address. Just like with the Source Address this address must be already configured before being used in the DoS policy. Multiple addresses, virtual IPs or virtual IP groups can be chosen.

Service

While the Service field allows for the use of the ALL service some administrators prefer to optimize the resources of the firewall and only check on the services that will be answered on an interface. Multiple services or service groups can be chosen.

Anomalies

The anomalies can not be configured by the user. They are predefined sensors set up for specific patterns of anomalous traffic

The anomalies that have been predefined for use in the DoS Policies are:

Anomaly Name Description Recommended Threshold
tcp_syn_flood If the SYN packet rate of new TCP connections, including retransmission, to one destination IP address exceeds the configured threshold value, the action is executed. 2000 packets per second.
tcp_port_scan If the SYN packet rate of new TCP connections, including retransmission, from one source IP address exceeds the configured threshold value, the action is executed. 1000 packets per second.
tcp_src_session If the number of concurrent TCP connections from one source IP address exceeds the configured threshold value, the action is executed. 5000 concurrent sessions.

 

Anomaly Name Description Recommended Threshold
tcp_dst_session If the number of concurrent TCP connections to one destination IP address exceeds the configured threshold value, the action is executed. 5000 concurrent sessions.
udp_flood If the UDP traffic to one destination IP address exceeds the configured threshold value, the action is executed. 2000 packets per second.
udp_scan If the number of UDP sessions originating from one source IP address exceeds the configured threshold value, the action is executed. 2000 packets per second.
udp_src_session If the number of concurrent UDP connections from one source IP address exceeds the configured threshold value, the action is executed. 5000 concurrent sessions.
udp_dst_session If the number of concurrent UDP connections to one destination IP address exceeds the configured threshold value, the action is executed. 5000 concurrent sessions.
icmp_flood If the number of ICMP packets sent to one destination IP address exceeds the configured threshold value, the action is executed. 250 packets per second.
icmp_sweep If the number of ICMP packets originating from one source IP address exceeds the configured threshold value, the action is executed. 100 packets per second.
icmp_src_ session If the number of concurrent ICMP connections from one source IP address exceeds the configured threshold value, the action is executed. 300 concurrent sessions
icmp_dst_ session If the number of concurrent ICMP connections to one destination IP address exceeds the configured threshold value, the action is executed. 3000 concurrent sessions
ip_src_session If the number of concurrent IP connections from one source IP address exceeds the configured threshold value, the action is executed. 5000 concurrent sessions.
ip_dst_session If the number of concurrent IP connections to one destination IP address exceeds the configured threshold value, the action is executed. 5000 concurrent sessions.
sctp_flood If the number of SCTP packets sent to one destination IP address exceeds the configured threshold value, the action is executed. 2000 packets per second
Anomaly Name Description Recommended Threshold
sctp_scan If the number of SCTP sessions originating from one source IP address exceeds the configured threshold value, the action is executed. 1000 packets per second
sctp_src_session If the number of concurrent SCTP connections from one source IP address exceeds the configured threshold value, the action is executed. 5000 concurrent sessions
sctp_dst_session If the number of concurrent SCTP connections to one destination IP address exceeds the configured threshold value, the action is executed. 5000 concurrent sessions

Status

The status field is enabled to enable the sensor for the associated anomaly. In terms of actions performed there is no difference between disabling a sensor and having the action as “Pass” but by disabling sensors that are not being used for blocking or logging you can save some resources of the firewall that can be better used elsewhere.

Logging

Regardless of whether the traffic is blocked or passed through the anomalous traffic will be logged.

Pass

Allows the anomalous traffic to pass through unimpeded.

Block

For Thresholds based on the number of concurrent sessions blocking the anomaly will not allow more than the number of concurrent sessions set as the threshold.

For rate based thresholds where the threshold is measured in packets per second, the Action setting “Block” prevents the overwhelming of the firewall by anomalous traffic in one of 2 ways. Setting which of those 2 ways will be issued is determined in the CLI.

l continuous – blocks packets once an anomaly is detected. This overrides individual anomaly settings. l periodical – allows matching anomalous traffic up to the rate set by the threshold.

If the period for a particular anomaly is 60 seconds, such as those where the threshold is measured in concurrent sessions, after the 60 second timer has expired, the number of allowed packets that match the anomaly criteria is reset to zero. This means that if you allow 10 sessions through before blocking, after the 60 seconds is up, another 10 will be allowed. The attrition of sessions from expiration should keep the allowed sessions from reaching the maximum.

To set the type of block action for the rate based anomaly sensors:

config ips global set anomaly-mode continuous set anomaly-mode periodical end

Threshold

The threshold can be either in terms of concurrent session or in packets per second depending on which sensor is being referred to.

Quarantine

The quarantine feature is found in the CLI. This setting is used to block any further traffic from a source address that is now considered to be a malicious actor or a source of traffic dangerous to the network. Not only is no more traffic accepted for the duration of the quarantine through the DoS policy but the source IP address of the traffic is added to the banned source ip list. This list is kept in the kernel and used by

l Antivirus l Data Leak Prevention (DLP) l Denial of Service (DoS) l Intrusion Prevention System (IPS)

Any policies that use any of these features will block traffic from the attacker’s IP address.

Syntax

config firewall {DoS-policy|DoS-policy6} edit <policyid> set quarantine {none|attacker} set quarantine-exipiry {string} set quarantine-log {enable|disable}

end

Option Description
quarantine Quarantine method.

l  none – Quarantine is disabled.

l  attacker – Block all traffic sent from the attacker’s IP address. The quarantined IP address is also added to the banned ip list. The destination address is not affected.

quarantine-expiry Duration of quarantine

The format is ###d##h##m, ranging from 1 minute to 364 days, 23 hours, and 59 minutes starting from now. The default is 0d0h5m. Requires quarantine set to attacker.

quarantine-log Enables or disables the logging of quarantine events.

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!