![]() Limit the count of failed login attepts until the user is bannedįortinet has a KB regarding the implementation of a login-limit for SSL VPN under Restrict the source IP address area Don’t forget to change the port on all VPN clients too. Using another port is an easy but effective measurement if an attacker is only probing the default port of an application. Change the listening Port for 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. Ensure, that admin users have no access to the SSL-VPN portal 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). Two factor authentication prevents an attacker from being able to log in to an account only with username and password. Implement Two-factor authentication for all accounts ![]() ![]() Passwords must have an age below 8 weeks.Passwords must contain upper- and lowercase letters.Passwords must contain special characters.Passwords must have a minimum length of 12 characters.This includes password rules like in this example: How to minimize the attack surface Use strong passwords for all accounts (Have a look at our tipps below on how to minimize the attach surface)ĭid you make similar observations? Did you come to another conclusion? Your comments regarding this events are very appreciated. In environments, where the basic rules of security are implemented properly, there is no chance that such an attack will be successfull.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.That is slowing down the whole process a lot. There is not one user that is being attacked but there are plenty of them and they are being attached serially.The attacks are being executed very slowly (5 – 20 login tries per hour), so no performance problems are to expect.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 setup. We discussed a lot of possible solutions and came to the conclusion, that there is no simple way to block these attacks. Only SSL-VPN Sites on Port 10443 are being attacked, Portals running on other ports like 443 are not (yet).Only a few usernames are being tried: admin, administrador, administrator, user, vpn, vpnuser, aadmin, badmin, cadmin, dadmin … zadmin, and few more.Not all FortiGates that are connected and reachable publicly over the internet are affected.Almost every login try is coming from a different source IP to prevent a block.A lot means around 5-20 events per hour. ![]() A lot of failed login events are being logged.Lets summarize what we have found out until today: Most of the administrators saw a rised number of the following log messages in the “VPN Event Log” on the FortiGate / FortiAnalyzer.Īnd no, there’s no spelling mistakes in the title… That’s the way the log message is named: date= 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" Therefore, this post is still very relevant.) But messages are still shown from time to time, since scanning is going on over the internet all the time. (Edit: That was back in August of 2021 and the big “scanning” ended around two weeks after it has started. Since last week, we observed a lot of failed SSL-VPN login events on various FortiGate setups. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |