Description
This article describes best practices for hardening environments with the FortiAuthenticator. It may in parts be true for other installations.
Scope
FortiAuthenticator all versions. FortiGate configuration is referred to in parts.
Solution
General considerations:
FortiAuthenticator can primarily act as a server for many protocols like RADIUS and SAML, as well as 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 available features, not all may be used though. FortiAuthenticator must be instructed whether the use of a protocol or feature is expected. By default, the FortiAuthenticator will offer most services, but not all services will be required in every environment.
- It is 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 given 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.
- Reviewing the firmware release notes for addressed or resolved issues may indicate a vulnerability in the previous version(s).
- 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 work day shift. Requests that cannot be processed in time or dropped altogether, will not only cause a bad user experience. Also logs that will state about timeouts or unfinished login attempts, unreachable nodes.
- When reviewing the state of the product, it is a best practice to verify that it operates as it should so an operating baseline can be 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 require CPU cycles).
- Changes to the environment must be listed up, reviewed, tested, documented, and communicated. Changes might cause user impact, so the review is important to spot if user impact is expected.
Big chunks of a secure environment stem from the configuration and handling of the respective components.
The following section describes a few different scenarios, some of which are built on top of each other.
The scenarios as an overview:
- Scenario 1 - VPN authentication via RADIUS.
- Scenario 2 - VPN authentication via RADIUS with FortiToken Mobile Push.
- Scenario 3 - custom FortiToken Mobile push address.
- Scenario 4 - FortiToken Mobile push notification responses, Firewall configuration.
- Scenario 5 - valid HTTPS/TLS certificates.
- Scenario 6 - SSO Mobility Agent.
- Scenario 7 - Authenticate only already imported Remote LDAP users.
- General setup Notes.
Details:
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 authentication' requests (Access-Request) 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 to 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 to Syslog messages to use them for FSSO. Disabling this is unrelated to the capability of FortiAuthenticator to send 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 who are tied to the web interface, administrative sessions, SAML, or any kind of portal users.
Scenario 2 - VPN authentication via RADIUS with FortiToken Mobile 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 attack surface, 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.
Here, administrative 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 - custom FortiToken Mobile push address.
Taking scenario 2 as a base.
The way how FortiToken Mobile push works is 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 user interface, like the FortiClient token popup, or via the 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:
Technical Tip: Push Notifications
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 is 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 because 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 the Internet via the custom port and port 443 won't be made accessible.
Scenario 4 - FortiToken Mobile push notification responses, Firewall configuration.
Taking scenario 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 SSL VPN 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).
An alternative to create such a list on-demand is documented here, using Automation stitches.
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 SSL VPN.
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:
The lockout is also present as a feature on FortiAuthenticator. At Monitor -> Authentication -> Locked-out IP Addresses it is visible which IP is locked, and it can be configured at Authentication -> User Account Policies -> Lockouts.
More documentation on IP lockouts in our documentation library.
When a lockout is generated on FortiAuthenticator, it is logged with a similar message:
Too many failed login attempts from 148.248.348.448, IP locked for 60 seconds." user="userX"
Note:
Geofencing, that is here geography-based address objects is also suited well for the SSL VPN connection itself. Setting this up can block authentication attempts from unexpected geographic locations. More details in this article Technical Tip: Restricting SSL VPN connectivity from certain countries using firewall geography addr....
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 and the following versions, 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.
Scenario 6 - SSO Mobility Agent.
The SSO Mobility Agent (SSOMA) offers a way for FSSO users to submit the login and change of IP addresses to FortiAuthenticator way quicker than the regular FSSO method with polling of DCAgent could do. While this is not suited for TSAgent environments, it is suited especially well for mixed environments like SSLVPN and on-premise users. This works by directly sending the login from the workstation to the FortiAuthenticator, rather than causing a logon to the domain controller that is read by FortiAuthenticator or a Collector Agent.
This way, the main privilege directive can rely on FSSO, while SSLVPN privileges can be reduced to a bare minimum. In other words: only SSOMA users (must be domain joined clients and users) can access internal resources, matching the respective policies, while SSLVPN users are unable to. This is another layer of security, even if an external thread actor gains credentials and a second factor of a user. While this is still a dangerous situation, it might well give needed time to address the credential leak.
Use a strong pre-shared key, or use 'Require client certificate in TLS connection'.
Scenario 7 - Authenticate only already imported Remote LDAP users.
With the given scenarios, it is clear that outside threat actors will attempt to authenticate to this environment and services that are publicly available. Minimizing the attack surface lowers the risk of breach, but the authentications against the user database the web server, VPN or mail gateways, etc. will happen.
FortiAuthenticator offers the capability to import remote LDAP users from the existing LDAP directory, like the active directory. While FortiAuthenticator is the backend for these services, the backend for FortiAuthenticator will be the server where it imports the users from. This can complement scenario 2, but may well stand on its own.
Consider that by default, FortiAuthenticator will translate each RADIUS Access-Request to the remote user database, regardless of whether this user already imported or not. This is designed since FortiAuthenticator allows authenticating users via a complete group without being imported (which will not allow 2FA via FortiToken Mobile on FortiAuthenticator).
Starting with FortiAuthenticator release 6.4.5, a new setting was introduced to change this behavior.
If it is intended that RADIUS authentication is to succeed for users that are imported to FortiAuthenticator, enable the setting in GUI -> Authentication -> User Management -> Realms:
Realms are to be understood on FortiAuthenticator as a user database/backend on a certain server, and the realms are selectable in the RADIUS policies.
When enabled, the authentication for users that have not been imported to FortiAuthenticator will simply fail, without creating a request to the LDAP server. This setting protects against the intent to lock the respective user from the LDAP server, without actual user interaction.
Note: Changing this setting doesn't affect the current user database in any way. It will only restrict authentication requests sent to FortiAuthenticator to be forwarded to the remote user database only if this user is imported from that server.
The practical outcome of the setting is that the authentication or the LDAP-bind for that user will not be done anymore if the user is not imported. FortiAuthenticator will still check whether the user exists on the LDAP server, and for that, an LDAP-bind for the service account will be done (even the user is not imported). This will then save the LDAP server from user authentication requests and avoid the existing, but not imported users to be locked out with incorrect password logon attempts.
- RADIUS configuration on FortiGate.
- Two-factor authentication order.
- SSL VPN port.
- FortiAuthenticator Network Interface services explanation.
- Resource provisioning.
- Maintenance.
- Trusted hosts.
- Working with Fortinet Technical Support.
Details:
An important change on FortiGate: Do not leave the authentication method as 'Default':
'Default' instructs FortiGate: In case of an Access-Reject by the RADIUS server, try again with another method (MSCHAP). If this fails, try another method (CHAP).
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. In a simple diagram, the authenticating user can be traced over the nodes like this:
Authentication supplicant -> FortiGate -> FortiAuthenticator -> LDAP server.
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 order that FortiGate uses is PAP, MSCHAP, 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=12: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=12: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=12: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"
In this example, FortiGate requested for the user 'vendor' once via PAP without success as the user does not exist on the LDAP server (Access-Reject). FortiGate tries again via MSCHAP without success as well, and another second later, generated another failure via CHAP.
If the user is actually a valid one, the user would be locked on the LDAP server as a result of this operation. The messages will slightly change, so it will not be 'invalid user', but 'invalid password'.
To avoid this type of multi-logon, change the Authentication method to the intended method:
Recommendation: Use MS-CHAP-v2 if FortiAuthenticator is domain joined and uses Domain authentication (see the RADIUS policy 'Identity source' section). Otherwise, use PAP.
FortiGate's radius authentication method troubleshooting steps with explained debugs could be found there.
The log example additionally shows the login attempt of a generic user 'vendor' that simply does not exist on the remote LDAP server. It is a scripted attempt from an outside threat actor. Following scenario 4 might help lower the risk and load.
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.
The FortiGate listens on an SSLVPN port, typically 443. Automated scripts are more likely to test on websites at 443 as the default webserver port. Similar to the FortiToken Mobile push port, choose another port to avoid automated attempts for port 443.
The more random, the better. This does not make the FortiGate unreachable but simply makes it listen on another TCP port. Note that the end user's VPN configuration must reflect the custom port, otherwise the connection will not be possible.
The interface services at GUI -> System -> Network -> 'interface-name' can be grouped as follows:
Admin Access: This concerns the administrative interface. It does not concern any end user-facing services (despite restAPI for FortiAuthenticator 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 FortiAuthenticator as the issuing CA) - tcp/2560.
- CRL (Certificate validity check from client to FortiAuthenticator as the 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/OIDC is used, this has 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 (HTTP-based, tcp/443).
If TACACS is not used, disable it. - tcp/49.
RADSEC will be more specific, if used, it has 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 both port 80 (HTTP) and 443 (HTTPS), the only difference will be TLS encryption. Generally, HTTP port 80 should be avoided, as communication via port 80 is unencrypted.
Related article with more recent and direct service explanations:
Technical Tip: FortiAuthenticator Interface Services
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.
Be sure to plan proper maintenance. Upgrades, shutdowns, or reboots should be properly planned. Changes in settings or firmware should precede a test plan. Prepare a list of use cases that fit this environment and make them available for testing. For example:
- SSL VPN.
- 802.1x wired authentication.
- 802.1x wireless authentication (WPA-Enterprise).
- Push notification.
- FSSO.
When each of the test cases is present, verified and confirmed working, document the cases and results.
After the change, re-test the same test cases to see if there are differences to the documented cases and if these are acceptable/expected or not.
Reboots and shutdown should never be done by pulling the plug (or on hypervisors 'power off') but rather do a proper OS shutdown/reboot. Either this is doable from the GUI, and it may require a descriptive comment as reason for the shutdown. Or if the Graphical UI is unavailable, use the CLI with:
exec shutdown
Or:
exec reboot
And confirm with y.
FortiAuthenticator logs such occurrences with a message in the GUI logs:
date=2024-07-23 time=06:48:48+0000 oid=19298034 logid=30901 cat="Event" subcat="System" level="notice" nas="" action="" status="" msg="FortiAuthenticator recovered from an unintended/unusual shutdown/reboot." user=""
Keep in mind that HA nodes may take over control briefly and that synchronization after the primary node is back may take a few minutes.
On both FortiGate and FortiAuthenticator trusted hosts can be used to allow admin login only from certain subnets.
This is documented already for FortiAuthenticator here:
How to configure trusted host for GUI access on FortiAuthenticator
FortiGate has this documented among other best practices here:
System administrator best practices
Based on reports or issues that occur, technical assistance may be required. More details on how to work with technical support are found here:
Troubleshooting Tip: How to work with FortiAuthenticator Technical Support
And in the support portal: Document List.
Clear error descriptions are required, documentation of the respective problem and availability. Logs that state when and that the issue occurred along with packet captures, depending on the issue, may be required to be exchanged. Avoid superficial issue descriptions in the sense that 'it doesn't work', as the existence of the ticket implies an issue already, and 'it' does not refer to what is not working. See by logs that the issue reported is identifiable.
This will help to save time to solve the reported issue if not even solve it automatically.
