Deny policies

Deny security policies deny traffic that is coming into the network. The FortiGate unit automatically blocks traffic that is associated with a deny security policy.

Deny security policies are usually configured when you need to restrict specific traffic, for example, SSH traffic. Deny security policies can also help when you want to block a service, such as DNS, but allow a specific DNS server.

Accept policies

Accept security policies accept traffic that is coming into the network. These policies allow traffic through the FortiGate unit, where the packets are scanned, translated if NAT is enabled, and then sent out to its destination.

Accept security policies are the most common security policies that are created in FortiOS. These security policies are basic policies, such as allowing Internet access, as well as complex policies, such as IPsec VPN.

DNS traffic in NGFW policy-mode

FortiOS has an option to enable the creation of an implicit policy to allow DNS traffic.

Certain Application Control profiles may not work properly if DNS traffic is not allowed. Enabling theimplicitallow-dns option adds an implicit policy to allow the DNS traffic. This policy is situated in the policy sequence Deny policies

just above the implicit deny policy. Since this is a config system settings command, this option can be enabled per VDOM.

CLI

config system settings set implicit-allow-dns {enable|disable} end

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

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.

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.

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.

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.

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