SSLVPN Access Attempts
Recently we had a law office with a breach (can't always protect them from themselves). During that breach, I noticed in their logs, and specifically, the PCI compliance that shows denied attempts was filled with a single IP address hitting the server every 30 seconds or so with a new attempt. This went back for days! I logged into the WG and created a block for that IP address, but it had me wondering why I had to do that? Why is there not some form of a ban in place for an obviously abusive user? If a user attempts SSL access from a single IP more than 10 times, why not automatically banned? This is a security platform and incorrect user lockouts have been a thing since before 2000s. This is desperately needed today.
On that same note, I decided to audit all of our watchguards (we have over 100 deployed). I was curious to see the same IP appear in a few of them. I wrote a compliant email to the provider, but I am curious to see if this person is specifically targeting watchguards or us. Anyone else have a 79.110.62.82 appear in their denies?
Comments
Hi @rmatthew
I'd suggest taking a look at the article here, which goes over some actions you can take:
(Unknown authentication attempts against Mobile VPN with SSL from a user named "test" or other random users)
https://techsearch.watchguard.com/KB?type=Article&SFDCID=kA16S000000BcPmSAK&lang=en_US
In general, we will advise of suggested policy changes via KBs or release notes, but we will not change existing policies on your firewall. Doing so runs the risk of breaking customer's policies/configurations
-James Carson
WatchGuard Customer Support
James, while that article addresses the issue occurring, it does nothing to actually address the issue. That article talks about using Connection rate limits, which I already described would be bypassed by the user by waiting 30-60 seconds between attempts. They also appear to be hitting the login page on the majority of my watchguards. So far, I have not seen them get in, but this is still a cause of concern that I had to manually notice something so obvious. Also, I am curious if other users with SSLVPNs have the same issue with the same IP.
You can disable the SSLVPN download page via the CLI.
Access to https://Firebox IP address:port no longer shows a log on screen.
You get a 404 Not Found.
One still gets warnings about the HTTPS cert on the firewall not being trusted by the web browser.
See the Software Downloads Page Hosted by the Firebox section, below:
Plan Your Mobile VPN with SSL Configuration
https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/mvpn/ssl/configure_fb_for_mpvpn_ssl_c_before.html
Hi @rmatthew
There's several things to try in that article, aside from rate limiting.
-The IP you mentioned (edited) specifically shows up as Bulgaria. If your customer does not do business outside North America, Geolocation can deny traffic to/from these areas. If you're unsure what areas you might be sending data to, I'd suggest enabling Geolocation with no countries blocked, as this will add gelocation logging to each traffic log. If you are logging to Dimension or WatchGuard Cloud, you can view a map with this data, which may be helpful.
-Disabling the SSLVPN logon page on the Firebox can reduce the attack surface of this specific attack. Users can download the SSLVPN directly from WatchGuard's website under the downloads for each firewall:
https://software.watchguard.com/
-I don't have any specific data related to that IP (edited) aside from that it's in Bulgaria. I'd suggest that if it is an attacker, they likely have other IPs they can attack from, so the exact IP is less important as it'll likely change.
-James Carson
WatchGuard Customer Support
James, please edit your post. You didn't grab the IP I listed, you copied mine from where I was posting from.
@rmatthew removed, thanks for catching that.
-James Carson
WatchGuard Customer Support
I ran into the same issue with our SSLVPN, but I have setup our Geo-Location filter which helps a little, and our "Account Lockout". I the end of my policies list, I setup a policy trap for our public SSLVPN IP. If the client is not successful in logging in the SSLVPN policy, it is caught by this final policy that blocks it for 30 minutes or so. Brut force will take years before they get a 20+ character long password.
FYI - V12.10.4 adds this feature - from the Release Notes:
. You can now block the source IP address of consecutive authentication failures to the Firebox. [FBX-9333, FBX-19172]
See the What's New for V12.10.4 for details:
https://www.watchguard.com/help/docs/fireware/12/en-US/whats-new_Fireware_v12-10-4.pptx
This includes access attempts for SSLVPN
Thank you Bruce!
I just configured the policy (FBX-19172) and blocked the three IP address that tormented my poor Firebox in the last months.
FYI - you can add specific IP addrs or subnets to your Blocked Sites list to block access from them. Note that you will see denies for these in Traffic Monitor.
If you want to block specific IP addrs or and not see them in Traffic Monitor, you can add an Any packet filter, From: the IP addrs To: Firebox. Set the policy to Denied, set the Logging to not send a log message and move the policy to the top of your policies list.
Thank you fam!! This is one of the things I needed
How can we check the blocked IPs due to this?
Thanks,
@Pabs
Blocked IPs should end up in blocked sites:
https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/intrusionprevention/blocked_sites_about_c.html
-James Carson
WatchGuard Customer Support
So, I am hoping I am reading this wrong, but it seems to me that this funcionality is not going to help with a firebox that is locally managed and uses Authpoint. Is that the case? I am having to manually collect IP addresses and add them to the blocked list every few days. It seems I will be forced to make our Fireboxes cloud managed to get this funcitonality. Is that correct?
Edit, I am asking about SSLVPN autoblocking in particular for a locally managed firebox that uses authpoint.
Thanks
Hi @robbied31
You can do this in WSM/WebUI on a locally managed device. The setting you're looking for are in the global authentication settings.
See:
https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/authentication/global_auth_settings_c.html
Look for the "block failed logons" button if you're using policy manager, or the "Block IP addresses with consecutive failed logins" in WebUI.
-James Carson
WatchGuard Customer Support
Hi James,
I have set this up today, but while reading the https://www.watchguard.com/help/docs/fireware/12/en-US/whats-new_Fireware_v12-10-4.pptx powerpoint, it seems this does not solve the SSLVPN failed login issue??? Here is what I am referring to, it is on slide #5. "This feature does not block failed login attempts for: Authpoint Authentication"
Am I wrong? Are these 2 separate events? I was searching logs in Watchguard Cloud > Monitor > Logs > Log Search for failed SSL VPN logins, but I cannot find any. So I was thinking that is why it won't work because the logs don't even show them. but maybe I have logging turned off for the SSL VPN policy. I will go look now.
Edit... logging is off, but logs should show a failed login. I only see failed logins in the Authpoint logs ..... Watchguard Cloud > Admin > Audit Logs
Thanks for the guidance.
Rob
Hi Rob,
If you're using AuthPoint, you can't use the automatic block function. Other options such as geofencing are available via AuthPoint.
-James Carson
WatchGuard Customer Support
Is my case of using locally managed Firebox with Authpoint unique? Not sure why my setup is an outlier.
Hi @robbied31
I don't have any data for what users use which option.
In your specific instance, I would suggest exploring the options available inside of AuthPoint. As you've noted, the IPs change often, so adding them to blocked sites will likely only help for a very short period of time.
Work is being done to add features to what is effectively brute-force prevention to this and other features based on current security/attack trends.
-James Carson
WatchGuard Customer Support