FortiGate lots of “SSL user failed to logged in” events

Last Update: 31.07.2024

Since last week, we observed a lot of failed SSL-VPN login events on various FortiGate setups. (Edit: That was back in August of 2021 and the big “scanning” ended around two weeks after it has started. But messages are still shown from time to time, since scanning is going on over the internet all the time. Therefore, this post is still very relevant.)

Most of the administrators saw a rised number of the following log messages in the “VPN Event Log” on the FortiGate / FortiAnalyzer.

And no, there’s no spelling mistakes in the title… That’s the way the log message is named:

date=2021-08-23 time=11:22:33 logid="0101039426" type="event" subtype="vpn" level="alert" vd="root" eventtime=1629710539 logdesc="SSL VPN login fail" action="ssl-login-fail" tunneltype="ssl-web" tunnelid=0 remip=11.22.33.44 user="administrador" group="N/A" dst_host="N/A" reason="sslvpn_login_permission_denied" msg="SSL user failed to logged in"

What we see

Lets summarize what we have found out until today:

• A lot of failed login events are being logged.
• A lot means around 5-20 events per hour.
• Almost every login try is coming from a different source IP to prevent a block.
• Not all FortiGates that are connected and reachable publicly over the internet are affected.
• Only a few usernames are being tried: admin, administrador, administrator, user, vpn, vpnuser, aadmin, badmin, cadmin, dadmin … zadmin, and few more.
• Only SSL-VPN Sites on Port 10443 are being attacked, Portals running on other ports like 443 are not (yet).

We discussed a lot of possible solutions and came to the conclusion, that there is no simple way to block these attacks. Neither there is no strong need to block those “very basic” attack because this attack is not very sophisticated and should have no effect on a well secured and hardened setup.

Why?

• The attacks are being executed very slowly (5 – 20 login tries per hour), so no performance problems are to expect.
• There is not one user that is being attacked but there are plenty of them and they are being attached serially. That is slowing down the whole process a lot.
• All the usernames that we were able to observe are users that are not existing or have no access to the SSL-VPN in most setups.
• In environments, where the basic rules of security are implemented properly, there is no chance that such an attack will be successfull. (Have a look at our tipps below on how to minimize the attach surface)

Did you make similar observations? Did you come to another conclusion? Your comments regarding this events are very appreciated.

How to minimize the attack surface

Use strong passwords for all accounts

This includes password rules like in this example:

• Passwords must have a minimum length of 12 characters
• Passwords must contain numbers
• Passwords must contain special characters
• Passwords must contain upper- and lowercase letters
• Passwords must have an age below 8 weeks

Implement Two-factor authentication for all accounts

Two factor authentication prevents an attacker from being able to log in to an account only with username and password. With the third factor, the attacker needs access to additional information like the smartphone (in case of push token) or a 6 digit number (in case of mobile or hardware tokens).

Ensure, that admin users have no access to the SSL-VPN portal

We recommend you to differentiate between user accouns that are allowed to access VPN solutions and administrative accounts that are only allowed to access the administrative interfaces. Use different usernames for admin accounts and for user accounts.

Change the listening Port for the SSL-VPN portal

Using another port is an easy but effective measurement if an attacker is only probing the default port of an application. Don’t forget to change the port on all VPN clients too. Otherwise the connection will break.

Limit the count of failed login attepts until the user is banned

Fortinet has a KB regarding the implementation of a login-limit for SSL VPN under https://kb.fortinet.com/kb/documentLink.do?externalID=FD48714

Restrict the source IP address area

If your users only need access to the SSL VPN portal from a specific source address or range, you can limit the allowed source addresses to those addresses.
There is a Fortinet KB that explains everything (please note the last part too).

Please note: You may also consider to implement local-in policies to prevent the traffic from reaching the FortiOS in any way.

Ensure, that a no-access profile is enabled for “All other users/groups”

At the bottom of the table in the “SSL-VPN Settings” where the Authentication/Portal Mapping is configured, there is an option for “All Other Users/Groups”. We recommend you to disallow access to the SSL-VPN for groups that were not explicitly allowed on the mappings above.

config vpn ssl web portal
    edit "no-access"
        set tunnel-mode disable
        set ipv6-tunnel-mode disable
        set web-mode disable
        set allow-user-access ping
        set limit-user-logins enable
        set forticlient-download disable
    next
end
config vpn ssl settings
    set default-portal "no-access"
end

In addition to disallow the access for “All Other Users/Groups”, you may also restrict the access for users and groups inside the firewall policies. Configure those policies as selective and restrictive as possible.

Enable selective E-Mail notifications for events you want to be informed about

E-Mail notifications are a good tool to be informed about such kind of attacks. If the amount of sent E-Mail messages is getting too big for the failed login attempts, you may review your FortiGate configuration (for the mentioned points above) and disable the notifications temporary until the attack is over.