Explorer II

Solved

reducing brute force ssl vpn login attempts

Forum|Forum|1 year ago
December 5, 2024
4 replies
4378 views

Despite the following, we are still getting a barrage of brute force login attempts on our SSL VPN.

- disabled web mode
- using non 443 port
- edited to the HTML page to hide login fields
- created local-in policy to narrow sources, etc
- tweaked the login attempt-limit, block-time, and login-timeout

I am wondering if forcing the user to present a client certificate would reduce these attempts. In other words, does the enforcement of a client side certificate happen before a username/password attempt is made ?

Any other ideas ?

Don

Best answer by pminarik

> I am wondering if forcing the user to present a client certificate would reduce these attempts. In other words, does the enforcement of a client side certificate happen before a username/password attempt is made ?

To answer this question directly: Requiring client-certificate (either via "set reqclientcert enable" or by allowing only peer-type users) will not stop brute-force attempts, but they will get a constant negative response (not distinguishable from regular bad username+pwd fail) even if they happen to provide a valid username+password.

You will still see these attempts logged as failures. If client-certificates are an additional requirement for users, brute-force attempts should still show up as the usual event 39426 with action="ssl-login-fail" and a new reason="sslvpn_login_cert_checked_error".

If only peer-users are allowed login (certificates only, nobody with username+pwd), random brute-force attempts should appear as the usual reason="sslvpn_login_permission_denied".

sjoshi

Staff

Hi,

You can try setting up automatic stitch to block those user/srcs most common brute forced usernames

Trigger
config system automation-trigger
edit "SSL_VPN_USER_SSL_LOGIN_FAIL_guest"
set description "SSL_VPN_USER_SSL_LOGIN_FAIL"
set event-type event-log
set logid 39426
config fields
edit 1
set name "user"
set value "*uest*"
next
end
next
end

ACTION
config system automation-action
edit "Block_SSL_Failed"
set description "Block_SSL_Failed"
set action-type cli-script
set script "config firewall address
edit SSL_VPN_Block_%%log.remip%%
set subnet %%log.remip%%/32
end
config firewall addrgrp
edit Block_SSL_Failed
append member SSL_VPN_Block_%%log.remip%%
end"
set accprofile "super_admin"
next
edit "SSL_VPN_Block"
set description "SSL_VPN_Block"
set action-type email
set email-to "
email@email.com"
set email-from "
email@email.com"
set email-subject "SSL VPN IP Auto Blocked"
set message "%%log.remip%% address has been added to the address group Block_SSL_Failed"
next
end

the actual stitch
config system automation-stitch
edit "SSL_VPN_Block_guest"
set description "SSL_VPN_Block"
set trigger "SSL_VPN_USER_SSL_LOGIN_FAIL_guest"
config actions
edit 1
set action "Block_SSL_Failed"
set required enable
next
edit 2
set action "SSL_VPN_Block"
set required enable
next
end
next
end

Thanks, Salon

sjoshi

Staff

Also refer:-

https://community.fortinet.com/t5/FortiGate/Technical-Tip-How-to-secure-and-limit-an-SSL-VPN-unknown-user/ta-p/224096

Thanks, Salon

DPadula

Staff & Editor

Another good approach is to Geo restrict the locations that users are located. So if you users are located only in America for example, you could block traffic coming from Asia, Europe, etc.
We do have a community article for that as well: https://community.fortinet.com/t5/FortiGate/Technical-Tip-Restricting-SSL-VPN-connectivity-from-certain/ta-p/191997

doncacciatoconsutingAuthor

Explorer II

thanks all - very useful ideas. Can anyone answer this question:

I am wondering if forcing the user to present a client certificate would reduce these attempts. In other words, does the enforcement of a client side certificate happen before a username/password attempt is made ?

DPadula

Staff & Editor

Hi Don,

When you use client certificate the certificate is used to authenticate the user, there is no username and password anymore. For more details about it check the following document:

https://docs.fortinet.com/document/fortigate/6.2.14/cookbook/266506/ssl-vpn-with-certificate-authentication

From the link above: To use the user certificate, you must first install it on the user’s PC. When the user tries to authenticate, the user certificate is checked against the CA certificate to verify that they match. Every user should have a unique user certificate. This allows you to distinguish each user and revoke a specific user’s certificate, such as if a user no longer has VPN access.

Check also the session best practices

Regards

DPadula

pminarikAnswer

Staff

> I am wondering if forcing the user to present a client certificate would reduce these attempts. In other words, does the enforcement of a client side certificate happen before a username/password attempt is made ?

To answer this question directly: Requiring client-certificate (either via "set reqclientcert enable" or by allowing only peer-type users) will not stop brute-force attempts, but they will get a constant negative response (not distinguishable from regular bad username+pwd fail) even if they happen to provide a valid username+password.

You will still see these attempts logged as failures. If client-certificates are an additional requirement for users, brute-force attempts should still show up as the usual event 39426 with action="ssl-login-fail" and a new reason="sslvpn_login_cert_checked_error".

If only peer-users are allowed login (certificates only, nobody with username+pwd), random brute-force attempts should appear as the usual reason="sslvpn_login_permission_denied".

doncacciatoconsutingAuthor

Explorer II

thanks all for your help!

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded