FGT Local In Policy Allows UDP 1144 and 3799 for all ports - Details?

[tanr]

Hi All,

As I step through locking down a new FortiGate 300D, 5.4.1, I've turned on the feature to display Local In Policy for the GUI to look at what services/ports are open by default.  Most of what I see makes sense, and matches to either the 5.4 docs, http://docs.fortinet.com/d/fortios-ports-and-protocols, or to previous versions like http://docs.fortinet.com/uploaded/files/1880/FortinetOpenPorts.pdf.

However, local in policy shows UDP 1144 and UDP 3799 as allowed for all ports, including wan ports, and I can't find any information on these ports, except that TCP/UDP 3799 might be used for radius-dynauth (though that doesn't match the RADIUS ports listed in the Fortinet docs).  Perhaps they're something related to the new security fabric?  Without knowing what these are for I'm uncomfortable leaving them open on wan ports.

Anybody have more information on UDP 1144 or UDP 3799?

[tanr]

Nobody familiar with FortiGate's v5.4.1 use of UDP 1144 and UDP 3799 through local in policy?

Guess I'll block them through local-in-policy and see what breaks...

[tanr]

FYI, I contacted Fortinet and got the details on these open ports.  Here's a recap of the situation, the use of the ports, and the security concern.

With a FortiGate 300D (or any FGT) with v5.4.1, turn on the feature to display Local In Policy for the GUI.

Now, local in policy shows UDP 1144 and UDP 3799 as allowed for all interfaces, including wan interfaces.

There is no documentation for these services, and it appears there is no way (through the GUI) to block them.

The security issue is that it appears these ports are left open for ALL interfaces, internal and external, regardless of the FGT’s configuration.  

TAC told me that the ports' are used for:

- UDP port 1144 for AeroScout Mobileview and its communication to our FortiAPs. - UDP port 3799 for Radius Dynamic Authorization/Change of Authorization

Given those uses, you would think that not using those features would leave the ports closed, but that is not the case.  For example: - My current configuration has no RADIUS accounting on any interface, and no external (FortiCloud/FortiManager) management so UDP 3799 shouldn't be open on any ports, much less my wan ports, but it is open. - My current configuration is not (yet) set up to work with any FortiAP's (no CAPWAP on any interface, no cloud management of FortiAP's), so UDP port 1144 shouldn't be open on any ports, much less my wan ports, but it is open.

I could see how these ports could be open for certain interfaces IF I enabled external RADIUS or cloud management, or cloud management of FortiAPs, but they really shouldn't be open by default. Having them both open and undocumented is dangerous.

I've passed on the following new feature requests to Fortinet:

1. At a minimum, these ports should be documented in the list of what ports and protocols the FortiGate uses (http://docs.fortinet.com/...-ports-and-protocols). 2. Do not have UDP 1144 and UDP 3799 open by default on all ports. Expose these services in the GUI, under Network>Interface>Administrative Access, so that only when the FortiOS GUI shows the appropriate Administration Access setting does the Interface have these ports open.

With the current design, a FortiGate user has no documentation telling them about these ports, and the default configuration of the GUI (with the Local In Policy feature turned off) doesn’t show them these ports are open.

It looks like the only way to block these ports is with the CLI’s local-in-policy.

I'll post here if I get new information on this.

[GregoryC]

Disable here:

config firewall local-in-policy     edit 1         set intf "interface"         set srcaddr "src address"         set dstaddr "dst address"         set action deny         set service "put service here i.e 1144"         set schedule "always"     next

Before:

id=20085 trace_id=2 func=print_pkt_detail line=5319 msg="vd-root received a packet(proto=17, 192.168.113.2:37784->192.168.113.1:1144) from lan. " id=20085 trace_id=2 func=init_ip_session_common line=5475 msg="allocate a new session-0002659b" id=20085 trace_id=2 func=vf_ip_route_input_common line=2578 msg="find a route: flag=84000000 gw-192.168.113.1 via root"

After:

id=20085 trace_id=1 func=print_pkt_detail line=5319 msg="vd-root received a packet(proto=17, 192.168.113.2:37784->192.168.113.1:1144) from lan. " id=20085 trace_id=1 func=init_ip_session_common line=5475 msg="allocate a new session-00026577" id=20085 trace_id=1 func=vf_ip_route_input_common line=2578 msg="find a route: flag=84000000 gw-192.168.113.1 via root" id=20085 trace_id=1 func=fw_local_in_handler line=389 msg="iprope_in_check() check failed on policy 1, drop"

[ispcolohost]

They're doing the same for ports 2000 and 8014 now too.  I attempted to make your changes, but the local-in web policy view still shows the ports as accept, even when I set the interfaces to match any.