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
"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."
Have we made any progress on these possible added features? I am getting hammered on a regular basis. I am constantly manually adding ip addresses from Authpoint logs to blocked sites. I have no experience with a cloud managed firebox, so I don't necessarily want to change to cloud managed with a config that has been refined thru the years [10 plus on multiple generations of fireboxes]. It seems as if you have to start from scratch if you switch to cloud managed.
Rob
Hi @robbied31
Updated have been added to the block failed logins feature, as well as adding items to other services to help with unwanted SSLVPN traffic.
I'd suggest following the steps in this article:
(Detect and mitigate brute force attacks that target Mobile VPN with SSL (SSLVPN))
https://techsearch.watchguard.com/KB?type=Article&SFDCID=kA16S000000BcPmSAK&lang=en_US
If you'd like help addressing any of the usage, I'd suggest opening a support case -- one of our support reps can help make recommendations based on what they see.
-James Carson
WatchGuard Customer Support
HI James, Thanks for jumping in. in this thread [above] on Sept. 19th, i asked for help blocking unwanted login attempts. you sent me to the same link previously. I have a locally managed firebox and use Authpoint. You mentioned to me on that same day that in this scenario, I cannot use Authpoint blocking because this firebox is locally managed, and since we use Authpoint, I cannot use automatica blocking in the firebox. I was asking if anything has changed as you also mentioned "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." Are you saying there are changes and I missed them in the link you posted today?
Rob
Hi @robbied31
I don't look back at the entire thread as customers often jump into them (just as you did) -- I'm simply trying to provide basic help for folks that come across it.
-The specific article offers other mitigation methods that include using the block failed logins feature. If you haven't done so, I would suggest looking into the other methods as they may help. I understand that you're really looking for that specific feature. It's being worked on -- several services need to work together in many varying configurations for this to work.
If you're interested in seeing pre-release items, I would suggest enabling the beta toggles inside of WatchGuard cloud as well as looking at the beta program for Fireware at watchguard.centercode.com.
(WatchGuard Beta Program)
https://www.watchguard.com/wgrd-support/beta-program
(Enable Beta Features and Applications)
https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/WG-Cloud/sp_beta-features.html
If none of that helps, I would suggest you open a support case if you haven't done so already.
-James Carson
WatchGuard Customer Support
Hi James,
Again, thanks for the input! I have been thru the doc many times and implemented everything in it. Unfortunately, I seem to be a unicorn with a locally managed firebox as well as using Authpoint which seems to limit the usefulness of everything except geofencing. I cannot use block failed logins feautre in firebox because we use Active Directory along with authpoint [firebox doesn't handle the logins-although it is setup]. Anyway, I will look into the beta stuff and open a ticket. I know Authpoint is supposed to protect us, but the fact that the SSLVPN IP address is being hammered non stop is unsettling.
Also, I am now starting to see traffic from IP addresses that I have previously added to the blocked sites in the past and are still in the blocked sites list [setup>Default Threat protection>Blocked Sites]. I see this traffic in the Authpoint logs, which is where I get the IP addresses to manually add to the blocked sites list. [which seems may not be fool proof now]
Again,
Thanks
Rob