Technical Tip: Restrict HTTPS access from certain countries by using local-in-policy

alwis · ‎11-28-2021

Description

This article describes how to restrict HTTPS access from certain countries to the WAN interface by configuring a local-in policy.

This can be useful for reducing the potential attack surface while still retaining WAN-based administrative access. Though it is important to note that best practice is to outright disable HTTP/HTTPS administrative access on any public-facing interfaces where possible (this removes entry points entirely, rather than simply limiting them; see also: Best Practices - Management network).

Scope

FortiGate.

Solution

Note before starting:

It is generally recommended to have either local admin access to the FortiGate (i.e. access via the LAN, VPN, etc.) or serial-console access before configuring local-in policies. This is useful as a backup plan in-case the local-in policy is accidentally misconfigured (e.g. blocking out allowed admins rather than the intended external attackers).

With the above in mind, the steps to configure HTTPS access on the WAN interface with local-in policy filtering are as follows:

Enable HTTPS administrative access on the WAN interface if not already done:

This can be done by editing the WAN interface in the GUI via Network -> Interfaces and enabling HTTPS in the Administrative Access section. In the CLI, this can be enabled via the following commands:

config system interface
edit <WAN_Interface_Name>
set allowaccess https
next
end

Configure the Geography Address object:

The intent here is to use Geography Address objects (which contain country-based mappings of public IP addresses) as a filter for sources that either allowed or disallowed by the local-in policy (see

In the GUI, go to Policy & Objects -> Addresses and select Create new under the Address section.
Set the Type to Geography, then under Country/Region

To do the same task using the CLI, use the following general commands (use the '?' character to see the list of available two-character codes):

config firewall address
edit 'Allow-Access-Geo'
        set type geography
        set country <two-character country code>
    next
end

Configure the Local-In Policy:

Starting in FortiOS 7.6, local-in policies may be configured in the Web GUI or via the CLI (see also: Technical Tip: Creating a Local-In policy (IPv4 and IPv6) on GUI). In FortiOS 7.4 and earlier, local-in policies may only be configured via the CLI.

With that in mind, use the following commands to configure a local-in policy that blocks access based on the Geography Address object that was created in the earlier step:

config firewall local-in-policy
edit 1
        set intf <WAN_Interface_Name>
        set srcaddr 'Allow-Access-Geo'
        set srcaddr-negate [enable | disable*] <--- See notes below
        set dstaddr 'all'

set service 'HTTPS'

set action [accept | deny*] <--- See notes below
set schedule 'always'
next
end

Notes regarding Local-In Policies:

Unlike firewall policies, local-in policies do not have implicit-deny policies (i.e. all traffic is allowed by default unless explicit deny policies are added). If an implicit deny (aka catch-all) policy is required then it must be manually added and moved to the bottom of the local-in policy list.
The srcaddr-negate option (and the corresponding dstaddr-negate option) allows policymakers to specify if a given address must match the specified Address object or if it must NOT match the Address object.
- In the earlier examples, the United States (US) was specified for the Geography Address object. With srcaddr-negate disable (default), the local-in policy will match all sources that belong within the United Sates.
- With srcaddr-negate enable, the policy will instead inverse, such that it matches all source addresses that are not within the United States (e.g. Canada-based public IPs, Mexico, etc.).
The default action for local-in policies is deny.
In this example, the FortiGate's Admin Web GUI is listening on the default port 443 for HTTPS. If a different port has been set then a new Service object should be created and used here instead.

Testing the Local-In Policy:

To test the HTTPS access after creating the local-in policy, a connection must be attempted from an IP address belonging to a blocked/disallowed country. This requires having a test machine/host in a blocked country or spoofing the source address to a public address that is associated with another country, followed by making a connection using the web browser or with a tool like telnet:

telnet x.x.x.x 443

To observe the local-in policy being assessed on the FortiGate, use the debug flow tool in the CLI:

diagnose debug flow filter dport 443
diagnose debug flow filter proto 6
diagnose de enable
diagnose de flow trace start 10

The following is sample output produced by the debug flow tool that shows traffic being dropped by local-in policy #1.

id=20085 trace_id=1 func=print_pkt_detail line=5746 msg='vd-root:0 received a packet(proto=6, 1.1.1.1:55105->192.168.2.104:443) from wan1. flag [S], seq 2359949110, ack 0, win 65535'
id=20085 trace_id=1 func=init_ip_session_common line=5918 msg='allocate a new session-003741d4'
id=20085 trace_id=1 func=vf_ip_route_input_common line=2615 msg='find a route: flag=80000000 gw-192.168.2.104 via root'
id=20085 trace_id=1 func=fw_local_in_handler line=474 msg='iprope_in_check() check failed on policy 1, drop'

Additionally, it is possible to check for associated log entries under Log & Report -> Local Traffic (filter by service 'HTTPS').

Related documents:

Technical Tip: Restrict HTTPS access from certain countries by using local-in-policy

You are leaving our website