Description
This article describes best practices for hardening the FortiAuthenticator.
Scope
FortiAuthenticator all versions. FortiGate configuration is referred to in parts.
Solution
General considerations:
FortiAuthenticator can act as a server for many protocols like RADIUS and SAML primarily, but also TACACS, OpenID, OAuth, and LDAP.
Thus, FortiAuthenticator can be flexibly integrated with various environments. This may require to expose FortiAuthenticator to the Internet.
Of the many features that are available, not all may be used though. FortiAuthenticator has to be instructed whether the use of a protocol or feature is expected or not. By default, the FortiAuthenticator will be offering most services, but not all services will be required in every environment.
- It is a best practice to review the requirements of this environment and enable only features/protocols that are needed. Which use cases does the environment have that this product should cover. This will also help in educating end users on what to expect and how certain flows are designed ('open this page, then this screen should appear....').
- Services should also be split into multiple interfaces, so certain interfaces only are available for the respective user groups. So the admin login via the web server is not available for the external guest users, as an example. The network layout may not enable a firewall like FortiGate to serve a protecting role here.
- Splitting services across the interfaces will then also serve in splitting administrative and operational access or end-user access.
- Firewall policies can help to limit access further, and even more granular would be the FortiWeb that would allow certain URLs only.
- Reviewing the release notes for known issues, and considerations on upgrades, can help to avoid issues.
- Check whether FortiAuthenticator is set up with enough memory, according to the datasheet, sizing guidelines and release notes. This can avoid abnormal behavior in busier times, like the start of the shift. Requests that cannot be processed, will cause a bad user experience, but also logs that will state about timeouts or unfinished login attempts.
- When reviewing the state of the product, it is a best practice that it operates as it should and has a regular baseline under which regular operation is expected.
- Disabling unneeded services will have the positive effect of less load on this device (this is not only true for the FortiAuthenticator).
- Controlling inbound and outbound traffic can also help to reduce the load on any of the processing devices (processing packets requires CPU cycles).
The following section describes a few different scenarios, which intentionally overlap, but can stand alone on their own.
Scenario 1 - VPN authentication via RADIUS:
FortiGate offers VPN for remote FortiClient users. Authentication against FortiAuthenticator via RADIUS. FortiAuthenticator offers 2-factor authentication (2FA) with FortiToken Mobile (or FortiToken Hardware) and the end user puts in the OTP token code manually.
FortiAuthenticator is configured to use a domain controller as LDAP backend and also joined to the domain to offer MSCHAPv2 authentication for enabling password changes.
The default network configuration on FortiAuthenticator may look similar to:
What is required from FortiAuthenticator:
- Listen to "RADIUS auth" requests from the RADIUS client, the FortiGate.
What is not required from FortiAuthenticator:
- Any other service.
Note as an example, that the service 'LDAP' is not required, because it defines that FortiAuthenticator should listen for LDAP requests. In this case, FortiAuthenticator is the LDAP client and is not to receive requests, but create requests to another LDAP service. Responses to FortiAuthenticator do not need FortiAuthenticator to listen as an LDAP service.
The same is true for Syslog - FortiAuthenticator can listen for Syslog messages to use them for FSSO. Disabling this is unrelated to the capability of FortiAuthenticator sending Syslog messages to a syslog server or FortiAnalyzer.
To cover this given scenario, the following interface configuration is valid:
Note that upon pressing the 'Apply' button, the web interface will restart (as the warning in blue on the screen says as well).
This may affect users that are tied to the web interface, administrative sessions, SAML, or any kind of portal users.
Scenario 2 - FTM Push:
Similar to Scenario 1, but adding FortiToken Mobile-Push notification instead of manual OTP input.
The implication of this is that FortiAuthenticator needs to be reachable from the Internet to receive these responses.
While push notifications offer a good user experience, they will also give a possible intrusion point to the network to be protected.
To reduce the risk, administrative and operational services should be split between interfaces. This is to avoid opening FortiAuthenticator administrative access to the internet FortiAuthenticator while only requiring a server for FortiToken Mobile push responses.
Splitting the interfaces would then as an example allow administrative access on interface port1 while allowing the operational access on port2.
Admin access is granted via port1 which is only accessible from inside the managed network.
Port2 for push notification will then only need to have 'FortiToken Mobile API (/api/v1/pushauthresp, /api/v1/transfertoken)' enabled.
The IP address provided here must be the address that which FortiGate will forward the FortiToken Mobile Push-sourced HTTPS connections.
Scenario 3 - FortiToken Mobile push address:
The way how FortiToken Mobile push works is in very simple:
As a second factor, FortiAuthenticator requires the user to provide an OTP. This is either done with the input field on the end users interface, like FortiClient token popup or via FortiToken Mobile popup on the phone.
Technical note: The “Approve/Deny” popup on FortiToken Mobile causes an HTTPS session from FortiToken Mobile to the FortiAuthenticator Address, stated in GUI -> System -> Administration -> System Access, and there is 'Public IP/FQDN for FortiToken Mobile'.
The mobile will resolve this address and then connect to it through the firewall, typically with a VIP or port forwarding to the FortiAuthenticator.
More technical information and troubleshooting is found in this article and its related articles:
https://community.fortinet.com/t5/FortiAuthenticator/Technical-Tip-Push-Notifications/ta-p/239864
Note that regardless of the address and port configured, FortiAuthenticator only listens on port 443.
The address here should be chosen with a different port than port 443. HTTPS default port 443 will be automatically probed by external actors and this more than other ports. So choose a random other port for example 48448 or any other.
Note that this in itself is no more secure than 443, but will cause less load on the environment, simply since most automated scripts will scan well-known ports first, but ignore others completely. An example configuration on FortiAuthenticator and FortiGate:
On the firewall there will need to be a port forwarding rule in place, to forward connection from the chosen high port to to FortiAuthenticator TCP port 443.
On FortiGate this requires two steps. Create a VIP for the port forwarding, and use it in a firewall policy.
This way FortiAuthenticator can only be reached from Internet via the custom port and port 443 won't be made accessible.
Scenario 4 - FTM Push, firewall configuration:
Taking Scenario 2 and 3 as a base. However, reviewing the requirements has shown that end users only connect from two countries (the UK and France) and only during certain times of the day (Monday-Friday 9 am-6 pm).
The FortiGate can use geographic address objects as policy objects and as such only allow access from some countries or even block access from certain countries.
A firewall policy allowing the countries France and the UK during certain day times could look like this (yellow highlight):
Here, traffic from the cell phone application FortiToken Mobile would enter wan1. Routing determines that the packets have to go to port 2. Source addresses only match if originating from these two countries. The Schedule will only match during the required shift times.
Traffic outside the schedule will be dropped. That includes FortiToken Mobile push traffic as well as any other traffic.
Note: The same is true for a regular firewall policy on SSLVPN push.
An advanced method to block unwanted addresses is to use a thread feed. FortiGate can pull a list of IP addresses from any source into a firewall address object. This can be a public list of known malware IPs for example. Putting such an object into the source of an inbound policy can help to disallow traffic from these IPs. Adding the object into an outbound policy as a destination object can block connections to these destinations. It is recommended to log this traffic, since the logged cases need investigation (of why a node is contacting an intentionally blocked address).
Another way to block IP address ranges, is to use the offending range as an allowed source address range and negate the setting.
config vpn ssl setting
set source-address "Block_SSLVPN"
set source-address-negate enable
end
This way, the IP addresses can be blocked from connecting to SSLVPN.
This is documented in article 206883.
Additionally, the FortiGate has an IP-based login-block by default enabled:
config vpn ssl settings
set login-attempt-limit 2
set login-block-time 60
end
The login-block-time (in seconds) can be increased, so brute-forcing will be harder. These settings in turn are documented in the FortiGate CLI reference.
Note:
Geofencing, that is here geography-based address objects are also suited well for the SSL VPN connection itself. Setting this up can block authentication attempts from unexpected geographic locations. More details in article 191997.
Scenario 5 - valid HTTPS/TLS certificates:
Most accesses to FortiAuthenticator (or any other service), be it administrative or operational, will require encrypted communication. FortiAuthenticator acts for the administration access, guest portals as well, and FortiToken Mobile push server as a regular TLS server. Browsers, so TLS clients, are set to warn in any case of abnormality.
A working TLS server as an HTTPS web server will be accessible from the end user/admin without any warning. This will be the baseline.
Note that if there is a certificate warning, there will be a good reason for this and the users have to understand to not continue any further.
Make sure that any access to the FortiAuthenticator, FortiGate, or any other web server in the environment comes up with a secured connection, and inspect the provided certificate. Security does not only come from the implementation but also from the users. Security will not help if the users intentionally bypass warnings like that.
As an example, https://fac.forti.lab must resolve to the administrative interface address and present a certificate with the same FQDN in the subject (and SubjectAlternativeName, SAN).
This is true for typical websites, like Fortinet but also the captive portal, self-service portal, or admin interface on FortiAuthenticator.
Educating users to ignore certificate warnings can lead to a case in which the certificate changes due to an attack. The end user would still ignore the certificate warning and thus, allow the attacker to proceed to another step. This is an example of such a warning.
End users should never see this and never get into the habit of ignoring these.
General technical information about certificates and requirements can be found in this Technical Tip: TLS and the use of Digital Certific... - Fortinet Community.
For generating them and handling debugging on the FortiGate follow this Guide to FortiGate and certificate issues.
Additionally, note that with FortiAuthenticator 6.6.0, the SHA-1 algorithm is no longer accepted on certificates as the algorithm is considered insecure, that affects the web interface as well as other services that rely on certificates, like LDAPS for remote LDAP user authentication. Any EAP method will also be affected. See the release notes for documentation.
General Notes:
- RADIUS configuration on FortiGate:
A small advised change on FortiGate: Do not leave the authentication method as 'default':
In case of an Access-Reject, the FortiGate will try again with another method, which will still fail. It will try another method and fail again. Each time, FortiAuthenticator will test against the user database. This is likely an LDAP server, for example, Active-Directory, and the directory will also log a failure count of authentication each time.
Depending on the configuration, a user lockout is done after three consecutive login failures, which automatically happens in this situation when a user entered an incorrect password once. The user is then locked on the LDAP server as a result of this configuration.
The order that FortiGate uses is PAP, MSCHAP(v2), and finally CHAP.
An example set of logs, visible on FortiAuthenticator in the general log section, GUI > Logging > Log Access > Logs
date=2023-10-31 time=22:34:56+0000 oid=1048050 logid=20101 cat="Event" subcat="Authentication" level="information" nas="192.168.48.1" action="Authentication" status="Failed" msg="Remote LDAP user authentication(chap) with no token failed: invalid user" user="vendor"
date=2023-10-31 time=22:34:57+0000 oid=1048049 logid=20101 cat="Event" subcat="Authentication" level="information" nas="192.168.48.1" action="Authentication" status="Failed" msg="Remote LDAP user authentication(mschap) with no token failed: invalid user" user="vendor"
date=2023-10-31 time=22:34:58+0000 oid=1048048 logid=20101 cat="Event" subcat="Authentication" level="information" nas="192.168.48.1" action="Authentication" status="Failed" msg="Remote LDAP user authentication with no token failed: invalid user" user="vendor"
Here, FortiGate requested once via PAP without success, then via MSCHAPv2 without success as well, and another second later, via CHAP.
To avoid this type of multi-logon, change the Authentication method to the intended method:
Use MS-CHAP-v2 if FortiAuthenticator is domain joined, otherwise use PAP.
The log example additionally show the log in attempt of a generic user "vendor" that simply does not exist on the remote LDAP server. It is a scripted attempt from an outside thread actor. Following Scenario 4 might help lower the risk and load.
- Two factor authentication order:
Another layer of security can be added by enabling the option 'PCI DSS 3.2 two-factor authentication' in the GUI under Authentication -> User Account Policies -> General (see screenshot). It will offer the second factor input field, regardless of the success of the first factor, the credentials being correct or not. It will not give away to an attacker whether the guessed password was correct.
- FortiAuthenticator Network Interface services explanation:
The interface services at GUI > System > Network > "interface-name" can be grouped as follows:
Admin Access: This concerns administrative interface. It does not concern any end user facing services (despite restAPI for FAC Agents, which use an admin web access key).
Services:
These are mixed and may not be clearly understood as to what they offer. They will depend on the functionality that FortiAuthenticator is required for.
It can be said that if a function is not used in the environment, all related services can be disabled without impacting existing services.
FSSO related services:
- SAML SP SSO (offers a portal with SAML authentication for creating FSSO entries)
- Kerberos SSO (offers a portal with Kerberos authentication for creating FSSO entries)
- FortiGate FSSO (connections from FortiGate to the FortiAuthenticator for general FSSO communication) - tcp/8000
- FortiClient FSSO (used for SSO Mobility Agent) - tcp/8001
- Hierarchical FSSO (used for tiering multiple FortiAuthenticators) - tcp/8003
- DC/TS Agent FSSO - tcp/8002
- Syslog (used to create FSSO users with authentication success messages, received via syslog) - udp/514
- Syslog over TLS - tcp/6514
- SAML IdP SSO
- RADIUS Accounting SSO (used to create FSSO users with Accounting Start messages)
FortiAuthenticator as Certificate Authority, related services:
- SCEP (Certificate enrollment protocol)
- CMP (Certificate enrollment protocol)
- OCSP (Certificate validity check from client to FAC as issuing CA) - tcp/2560
- CRL (Certificate validity check from client to FAC as issuing CA)
Portal related services - these are a bit more distinct, however can be disabled, if portals are not used.
- Legacy Self-service Portal
- Captive Portals
- OAuth Service (if OpenID is used, this may have to stay enabled)
- RADIUS Accounting Monitor (used for usage tracking of guest users) - udp/1646
The remaining services are more direct.
If SAML is not used, all SAML related services can be disabled.
If TACACS is not used, disable it. - tcp/49
RADSEC will be more specific, if used, it had to be explicitly configured. - tcp/2083
LDAPS, LDAP and RADIUS Auth are offering the FortiAuthenticator as a respective server to other nodes. Disabling RADIUS Accounting does not impact RADIUS Auth. Ports tcp/636, tcp/389 or udp/1812 respectively are used.
If services are offered on port 80 (HTTP) and 443 (HTTPS), the only difference will be TLS encryption. HTTP port 80 should be avoided generally as communication via port 80 is regularly unencrypted.
- Resource provisioning:
See that FortiAuthenticator as a VM has enough resources. If the web service is overused with SAML and portal queries, FortiAuthenticator needs more resources. The "Available Memory" widget may not be accurate as FortiAuthenticator kills services when it runs out of memory (OOM). The result is that it will always have enough memory on display.
A histogram on the hypervisor for memory usage will be helpful to spot these issues.
Following the general sizing guidelines will help to avoid these issues popping up in production:
Fortinet Docs: VM sizing guidelines
The default memory/CPU assignment taken from the default image may not fit the actual environment and intended usage of FortiAuthenticator.
