Fortinet black logo

FortiGate Methods to Utilize the Feed

FortiGate Methods to Utilize the Feed

There are various methods in which administrators can apply access control based on the IP Threat Feed that is synchronized from FortiSIEM. Below are examples of several methods.

Method 1: Apply threat feed as source in firewall policy to deny access to VIP

Applies to: On-net and Off-net users and devices

This assumes that FortiGate has various protected servers exposed to the Internet or on the internal network via a VIP. To block access from risky devices, set the policy source to the IP threat feed (FSM_Threat_Feed).

Note: For the Off-net use case, the IP threat feed must contain public IPs that should be blacklisted.

Method 2: Apply threat feed as source in a regular firewall policy

Applies to: On-net users and devices

When users are on-net and have access to protected servers without going through VIPs, the corresponding ISFW (Internal Segmentation Firewall) can block traffic from devices in the IP threat feed.

Note: When firewalls are configured in a security fabric, the IP threat feed does not get synchronized from the root FortiGate. Therefore, an IP threat feed must be configured on each FortiGate that is configured as a ISFW.

Method 3: Apply threat feed as source in a local-in policy to deny IKE/SSL/HTTPS or any administrative access destined to the FortiGate WAN or internal interface.

Applies to: On-net and Off-net users and devices

config firewall local-in-policy
    edit 1
        set intf "port1"
        set srcaddr "FSM_Threat_Feed"   // name of threat feed
        set dstaddr "all"
        set service "IKE"               // service(s) to block
        set schedule "always"
    next
end 

This can block new VPN connections based on source IP via IKE, HTTPS (443) or custom SSL VPN port. This will also block existing tunnel connections, since this is blocking at the packet/protocol level.

Blocking local-in traffic can also prevent rogue employees from accessing the FortiGate firewall itself.

See https://docs.fortinet.com/document/fortigate/7.2.99/administration-guide/363127/local-in-policy

Note: For the Off-net use case, the IP threat feed must contain public IPs for this to work.

Method 4: Apply threat feed as source on a SSL VPN or IPsec VPN based firewall policy.

Applies to: Off-net Dialup IPsec VPN users or SSL VPN users

This method assumes an endpoint is connected to the FortiGate for VPN already. The user/device behavior triggers the risk threshold to be exceeded on FortiSIEM, and consequently triggers its VPN address to be added to the watchlist.

The above policy allows traffic from any users that is NOT in the IP-threat-VPN-IPs feed. This method can block a device based on the IP assigned by FortiGate via SSL VPN or IPsec VPN.

Example source IP pool for SSL VPN:

Note: The FortiSIEM watchlist needs to filter for only events that produce the SSL VPN or IPsec VPN IP address assigned by the FortiGate.

Method 5: Apply threat feed as source on a ZTNA policy.

Applies to: Off-net users

This method assumes the remote device connects to protected resources behind the FortiGate via its ZTNA application gateway. In an agentless use case, FortiClient is not installed on the endpoint and the FortiGate must disable verification of device certificate.

config firewall access-proxy
    edit "ZTNA-access"
        set vip "ZTNA-access"
        set client-cert disable
     next 
end

ZTNA tags will not be used for security posture check. However, the threat feed can be used as source in the firewall policy.

The following policy allows traffic sourced from all IPs except for those in the FSM_Threat_Feed.

config firewall proxy-policy
    edit 1
        set name "ZTNA-Rule"
        set proxy access-proxy
        set access-proxy "86-FortiGate"
        set srcintf "port1"
        set srcaddr "FSM_Threat_Feed"
        set dstaddr "all"
        set srcaddr-negate enable
        set action accept
        set schedule "always"
        set groups "Remote-Rad"
    next
end

FortiGate Methods to Utilize the Feed

There are various methods in which administrators can apply access control based on the IP Threat Feed that is synchronized from FortiSIEM. Below are examples of several methods.

Method 1: Apply threat feed as source in firewall policy to deny access to VIP

Applies to: On-net and Off-net users and devices

This assumes that FortiGate has various protected servers exposed to the Internet or on the internal network via a VIP. To block access from risky devices, set the policy source to the IP threat feed (FSM_Threat_Feed).

Note: For the Off-net use case, the IP threat feed must contain public IPs that should be blacklisted.

Method 2: Apply threat feed as source in a regular firewall policy

Applies to: On-net users and devices

When users are on-net and have access to protected servers without going through VIPs, the corresponding ISFW (Internal Segmentation Firewall) can block traffic from devices in the IP threat feed.

Note: When firewalls are configured in a security fabric, the IP threat feed does not get synchronized from the root FortiGate. Therefore, an IP threat feed must be configured on each FortiGate that is configured as a ISFW.

Method 3: Apply threat feed as source in a local-in policy to deny IKE/SSL/HTTPS or any administrative access destined to the FortiGate WAN or internal interface.

Applies to: On-net and Off-net users and devices

config firewall local-in-policy
    edit 1
        set intf "port1"
        set srcaddr "FSM_Threat_Feed"   // name of threat feed
        set dstaddr "all"
        set service "IKE"               // service(s) to block
        set schedule "always"
    next
end 

This can block new VPN connections based on source IP via IKE, HTTPS (443) or custom SSL VPN port. This will also block existing tunnel connections, since this is blocking at the packet/protocol level.

Blocking local-in traffic can also prevent rogue employees from accessing the FortiGate firewall itself.

See https://docs.fortinet.com/document/fortigate/7.2.99/administration-guide/363127/local-in-policy

Note: For the Off-net use case, the IP threat feed must contain public IPs for this to work.

Method 4: Apply threat feed as source on a SSL VPN or IPsec VPN based firewall policy.

Applies to: Off-net Dialup IPsec VPN users or SSL VPN users

This method assumes an endpoint is connected to the FortiGate for VPN already. The user/device behavior triggers the risk threshold to be exceeded on FortiSIEM, and consequently triggers its VPN address to be added to the watchlist.

The above policy allows traffic from any users that is NOT in the IP-threat-VPN-IPs feed. This method can block a device based on the IP assigned by FortiGate via SSL VPN or IPsec VPN.

Example source IP pool for SSL VPN:

Note: The FortiSIEM watchlist needs to filter for only events that produce the SSL VPN or IPsec VPN IP address assigned by the FortiGate.

Method 5: Apply threat feed as source on a ZTNA policy.

Applies to: Off-net users

This method assumes the remote device connects to protected resources behind the FortiGate via its ZTNA application gateway. In an agentless use case, FortiClient is not installed on the endpoint and the FortiGate must disable verification of device certificate.

config firewall access-proxy
    edit "ZTNA-access"
        set vip "ZTNA-access"
        set client-cert disable
     next 
end

ZTNA tags will not be used for security posture check. However, the threat feed can be used as source in the firewall policy.

The following policy allows traffic sourced from all IPs except for those in the FSM_Threat_Feed.

config firewall proxy-policy
    edit 1
        set name "ZTNA-Rule"
        set proxy access-proxy
        set access-proxy "86-FortiGate"
        set srcintf "port1"
        set srcaddr "FSM_Threat_Feed"
        set dstaddr "all"
        set srcaddr-negate enable
        set action accept
        set schedule "always"
        set groups "Remote-Rad"
    next
end