Fortigate Local in Policy what it does and how to change/configure it


Fortigate comes with some services allowed in incoming direction, even without any configuration done by you. Important to note is that in such pre-configured security rules the destination is mostly the Fortigate itself, sometimes its specific interfaces, sometimes all of the interfaces. That is, this does not allow access though the firewall to the internal nets. Anyway, especially in penetration testing audits, these ports show up as open/closed/filtered and auditors complain asking to close them. Here is how to do so.

Another use case is when you actually want to allow only specific IPs to communicate with Fortigate. This is the only way, for example, to allow only specific IPs to initiate IPSec IKE negotiations (ports UDP 500 and 4500).

You make default Local policy visible in GUI by going to System -> Feature Visibility -> Local In Policy

Even then, you can only see but not change the policy in the GUI. You can change the policy but only in CLI.

NOTE: In GUI we can only see the default rules, managed automatically by enabling/disabling services. We will NOT see there the custom rules we create on CLI! It may confuse you when you configure rules in CLI and then cannot find them in the GUI - this is expected (bug or feature decide for yourself) behaviour.

This is how the default Policy looks (I only configured admin access via SSH/HTTPS, the rest of configs are pristine):

Policy & Objects -> Local In Policy.

fortigate-local-in-policy-rules

Other ports open and their meaning:

Port Description
1144 (Undocumented) Allows AeroScout to communicate with FortiAPs "The AeroScout suite of products provides Enterprise Visibility Solutions using Wi-Fi wireless networks as an infrastructure." More details: AeroScout – Meru Interop - Fortinet Knowledge Base
3799 (Undocumented) Radius Dynamic Authorization/Change of Authorization communication.For more details see `radius-coa {enable | disable}` in CLI reference.
2000 Cisco Skinny Clients protocol for IP Phones to communicate with Call Manager
8014 Uploading logs and diagnostics to EMS server, see Fortinet Communication Ports and Protocols

To see open to/from the Fortigate itself ports and conenctions:

diagnose ip tcp list

diagnose ip tcp list
  sl  local_address rem_address   st tx_queue rx_queue tr tm->when retrnsmt   uid  timeout inode                                                     
   0: 00000000:28A0  00000000:0000 0A 00000000:00000000 00:00000000 00000000     0        0 14035 2 ffff88001f77a080 100 0 0 10 -1 0:0/0:0/0:0 0                    
   1: 00000000:1E82 00000000:0000 0A 00000000:00000000 00:00000000 00000000     0        0 14064 2 ffff8800186d5980 100 0 0 10 -1 0:0/0:0/0:0 0    
                 |--- local open port in hex ( 1E82 = 7810 )
....

And for UDP:

diagnose ip udp list

  sl  local_address rem_address   st tx_queue rx_queue tr tm->when retrnsmt   uid  timeout inode ref pointer drops             
    2: 00000000:0202 00000000:0000 07 00000000:00000000 00:00000000 00000000     0        0 13933 3 ffff88001ab720c0 0 1:0/1:0/0:0 0         
    2: 00000000:0202 00000000:0000 07 00000000:00000000 00:00000000 00000000     0        0 13291 3 ffff88001ab72740 0 1:0/1:0/0:0 0   
                 |---this is local open port on Fortigate in hex (0202 = 514) 
....

Now to the next important question - How do I disable these listening ports?
You have two ways to do so: disable services listening on these ports, unfortunately not always working one, and change Local Policy way that always works.
Fortinet recommends trying to disable some (not all services can be disabled completely) services that use these open ports, for example to close ports 5060 for SIP and 2000 for Skinny, they give us:

config system settings
set default-voip-alg-mode kernel-helper-based
end

But first, disabling VOIP helpers affects ALL VOIP communications, when you might want to leave it open for the legitimate voice traffic. Second, they do not always work, depending on the firmware version and who knows what else conditions.

I, instead, prefer to edit the Local In security Policy and block or restrict to specific IPs the open ports. It always works and has predictable results.

For example, I will block all incoming traffic from Kali linux host 192.168.13.17 to the Fortigate at 192.168.13.91.

config firewall address
    edit "Kali_192.168.13.17"
        set color 13
        set subnet 192.168.13.17 255.255.255.255
    next 


config firewall local-in-policy
    edit 1
        set intf "port1"
        set srcaddr "Kali_192.168.13.17"
        set dstaddr "all"
        set service "ALL"
        set schedule "always"
    next
end

Let's see the difference.

BEFORE:

root@kali:~# nmap -sS -T 5 192.168.13.91
Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-07 06:08 EDT
Nmap scan report for 192.168.13.91
Host is up (0.00026s latency).
Not shown: 995 filtered ports
PORT    STATE  SERVICE
22/tcp  open   ssh
80/tcp  open   http
113/tcp closed ident
443/tcp open   https
541/tcp open   uucp-rlogin

root@kali:~# nmap -sU -T 5 192.168.13.91  
Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-07 06:08 EDT
Nmap scan report for 192.168.13.91
Host is up (0.00094s latency).
Not shown: 996 open|filtered ports
PORT     STATE  SERVICE
500/udp  closed isakmp
520/udp  closed route
2000/udp closed cisco-sccp
4500/udp closed nat-t-ike

AFTER:

root@kali:~# nmap -sS -T 5 192.168.13.91
Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-07 06:12 EDT
Nmap scan report for 192.168.13.91
Host is up (0.00027s latency).
Not shown: 999 filtered ports
PORT    STATE  SERVICE
113/tcp closed ident

root@kali:~# nmap -sU -T 5 192.168.13.91
Starting Nmap 7.80 ( https://nmap.org ) at 2020-06-07 06:12 EDT
Nmap scan report for 192.168.13.91
Host is up (0.00042s latency).
All 1000 scanned ports on 192.168.13.91 are open|filtered

Additional Resources

Follow me on https://www.linkedin.com/in/yurislobodyanyuk/ not to miss what I publish on Linkedin, Github, blog, and more.