This advisory sure sounds like the issue here: https://blog.talosintelligence.com/large-scale-brute-force-activity-targeting-vpns-ssh-services-with-commonly-used-login-credentials/
However in checking a few of those IP's and usernames, it doesn't match what we're seeing right now. I was hoping the IOCs were fairly complete, but maybe it's just a snapshot from a small point in time and things have moved on.
In any case, if it's useful for anyone else I grabbed the IOCs from talos at: https://github.com/Cisco-Talos/IOCs/blob/main/2024/04/large-scale-brute-force-activity-targeting-vpns-ssh-services-with-commonly-used-login-credentials.txt
And reformatted them into a list our firewall can use: https://raw.githubusercontent.com/jnorell/threatlist/main/20240417_cisco_talos_iocs_brute-foce-vpns_ips.txt
Question on this. How has 2FA/MFA been your saving grace? Aren't the brute force attacks still pegging your device and Internet similar to a DDOS? I understand that having 2FA/MFA would be protection, but some of the scripts mentioned in this thread don't have any smarts in them except to just run down a list of user names and passwords.
As an FYI for those who have firewalls regularly running out of RAM due to these attacks, support has a hotfix available for both current generations. We have yet to implement it, but figured Id share. These attacks seem to have unintentionally identified a memory leak.
Not sure if it is related, but we have been having issues with a few clients where the SSLVPN will stop working. This has started for the several clients in the passed three weeks or so. When the SSLVPN breaks, the client behavior can be variable. Typically all logged in SSLVPN sessions immediately disconnect. End users can reconnect to the SSLVPN, but will nearly immediately get disconnected when they begin to send traffic over the tunnel.
Restarting the Sonicwall resolves the issue for a period of time, perhaps several days, perhaps a week, but eventually it returns.
Our clients are using TZ and NSA series firewalls and none use an SMA's.
Typically all logged in SSLVPN sessions immediately disconnect. End
users can reconnect to the SSLVPN, but will nearly immediately get
disconnected when they begin to send traffic over the tunnel.
We were getting an average of 2000 requests daily. We were able to minimize this to 1% with a geo-location policy on the firewall and each policy. Also, reviewed some ports and removed any ICMP WAN IN allow policy.
In our case, the requests would come after a ports scan or icmp request.
Just FYI, it looks like a patch was released today to address this issue. I'll apply it tonight and hopefully that will stop the 100K+ logon failure emails I'm greeted with every morning.
For anyone still dealing with the Spray attacks I have successfully dealt with the issue by following this article from SonicWall support. This is for the SonicWALL Firewalls, and not the SMA.
@JiffJiff ,
That article doesn't resolve the issue fully.
It does seem that IP block does not work and mitigate any issue.
the only way I have found to fully stop it is to shut off SSLVPN and move to Global VPN which does not work for some compliancies.
We have about 15 different companies encountering the issue and still ahve some rebooting after attempting the hotfix that was issued: 7.1.1-7051-R3213-HF46826.
We still have NSAs and TZs rebooting due to the DOS attacks after this. We even shut off the CPU watchdog that we thought was allowing the sonicwall's to reboot themselves and haven't found a way to stop the auto-reboot.
We even implemented Dynamic Botnet List, but that only works well until the 2k limit is reached after which it seems to slow down the performance of the list and not block as fast.
< Sigh > Yep…. found that out Friday at 5PM. Logged in and found the spray attack going on once again.
So, if i understand your correctly. You got the hot fix from SonicWALL as mentioned in the article and it isn't helping resolve the exhaustion issue? I was going to reach out today myself and upload if i could.
Appreciate your above reply, thank you and cheers!
I applied the hotfix to my Gen6 NSA over the weekend, I'm hoping it will help. There is no reason the Sonicwall should not be able to handle these extremely common attacks, but I'm not really surprised since the SSLVPN performance is abysmal even without being attacked. I'm counting the days to the EOL of this product so I can replace it with a more reputable brand.
Still getting pummeled by Radius requests for authentication. Issue, bad actors are indeed connecting fine to the VPN Public IP. My first thought was to deploy certs to only allow only our systems to connect. Seems that wont work for sonicwall. (TZ 500 series). I did see some thoughts on moving the ports (SSL from 4433 to something else). I am sure that would help for a bit. However, thoughts to moving the UDP Port (500) typically to somewhere else for ESP phases. Probably would screw the attempts up for a bit longer. Rotating ports ?
If helpful for anyone, we've made some headway with a firewall ahead of the SMA, and using tcp connection rate limits (src ip gets blocked above 45 connections/60 seconds right now .. takes some tuning, but 30/60s hit legit traffic for us).
Offhand, does anyone have experience with measuring or limiting tcp connects to the SMA's, to know what legit traffic will do? We keep tweaking our limit, which recently hit a limit of 45 connections/20 seconds from a legitimate user. That seems nuts, and I sure can't reproduce anything near that, so it has something to do with their (home) environment, but wondering if anyone else has useful data points on that?
Depending on how big your VPN user base is, that could be quite the burden. What we have done is MFA, GEO-IP Block, and conducted an intense audit of the end user base. If they had not setup the 2FA, the lost VPN access until they did. I have had ONE attempted attack since it was all in place. Assuming you have the SSL-VPN setup to best practices, this should be enough to secure the system. However, until there is a firmware fix, the denial of access as a consequence of this type of attack will continue. To over come that, i communicated to my userbase to contact me when the system presents the exhaustion error and then i manually block the current IP conducting the spray.
Answers
I believe we've been getting hit for at least a month of so.
Not sure if this helps or hurts, but here's a link to a github for spraying:
https://github.com/hoodoer/sonicWallBruteForce
Edit: We only have a NSA2700, not a SMA.
This advisory sure sounds like the issue here: https://blog.talosintelligence.com/large-scale-brute-force-activity-targeting-vpns-ssh-services-with-commonly-used-login-credentials/
However in checking a few of those IP's and usernames, it doesn't match what we're seeing right now. I was hoping the IOCs were fairly complete, but maybe it's just a snapshot from a small point in time and things have moved on.
In any case, if it's useful for anyone else I grabbed the IOCs from talos at: https://github.com/Cisco-Talos/IOCs/blob/main/2024/04/large-scale-brute-force-activity-targeting-vpns-ssh-services-with-commonly-used-login-credentials.txt
And reformatted them into a list our firewall can use: https://raw.githubusercontent.com/jnorell/threatlist/main/20240417_cisco_talos_iocs_brute-foce-vpns_ips.txt
Ditto. None of the IPs or usernames in that list match a sample of what I found on customer firewalls.
I think hoping for an exhaustive list is wishful thinking :(
Question on this. How has 2FA/MFA been your saving grace? Aren't the brute force attacks still pegging your device and Internet similar to a DDOS? I understand that having 2FA/MFA would be protection, but some of the scripts mentioned in this thread don't have any smarts in them except to just run down a list of user names and passwords.
As an FYI for those who have firewalls regularly running out of RAM due to these attacks, support has a hotfix available for both current generations. We have yet to implement it, but figured Id share. These attacks seem to have unintentionally identified a memory leak.
Not sure if it is related, but we have been having issues with a few clients where the SSLVPN will stop working. This has started for the several clients in the passed three weeks or so. When the SSLVPN breaks, the client behavior can be variable. Typically all logged in SSLVPN sessions immediately disconnect. End users can reconnect to the SSLVPN, but will nearly immediately get disconnected when they begin to send traffic over the tunnel.
Restarting the Sonicwall resolves the issue for a period of time, perhaps several days, perhaps a week, but eventually it returns.
Our clients are using TZ and NSA series firewalls and none use an SMA's.
Has anyone changed there SSL VPN port?
Yes, we've had this.
We were getting an average of 2000 requests daily. We were able to minimize this to 1% with a geo-location policy on the firewall and each policy. Also, reviewed some ports and removed any ICMP WAN IN allow policy.
In our case, the requests would come after a ports scan or icmp request.
Just FYI, it looks like a patch was released today to address this issue. I'll apply it tonight and hopefully that will stop the 100K+ logon failure emails I'm greeted with every morning.
@CCAdmin just to avoid any confusion, there is a new Firmware 10.2.1.12 for SMA 100 Series, Firewall admins are still facing the issue.
The HTTP DOS Settings is new and should do the trick, classic fail2ban.
—Michael@BWC
Nice addition for the SMA. Before I reach out to support, any indication that they will implement a feature for the firewalls?
For anyone still dealing with the Spray attacks I have successfully dealt with the issue by following this article from SonicWall support. This is for the SonicWALL Firewalls, and not the SMA.
https://www.sonicwall.com/support/knowledge-base/sslvpn-license-exhaustion-on-gen7-firewalls/240325115738957/
@JiffJiff ,
That article doesn't resolve the issue fully.
It does seem that IP block does not work and mitigate any issue.
the only way I have found to fully stop it is to shut off SSLVPN and move to Global VPN which does not work for some compliancies.
We have about 15 different companies encountering the issue and still ahve some rebooting after attempting the hotfix that was issued: 7.1.1-7051-R3213-HF46826.
We still have NSAs and TZs rebooting due to the DOS attacks after this. We even shut off the CPU watchdog that we thought was allowing the sonicwall's to reboot themselves and haven't found a way to stop the auto-reboot.
We even implemented Dynamic Botnet List, but that only works well until the 2k limit is reached after which it seems to slow down the performance of the list and not block as fast.
@Onepocket
< Sigh > Yep…. found that out Friday at 5PM. Logged in and found the spray attack going on once again.
So, if i understand your correctly. You got the hot fix from SonicWALL as mentioned in the article and it isn't helping resolve the exhaustion issue? I was going to reach out today myself and upload if i could.
Appreciate your above reply, thank you and cheers!
I applied the hotfix to my Gen6 NSA over the weekend, I'm hoping it will help. There is no reason the Sonicwall should not be able to handle these extremely common attacks, but I'm not really surprised since the SSLVPN performance is abysmal even without being attacked. I'm counting the days to the EOL of this product so I can replace it with a more reputable brand.
Still getting pummeled by Radius requests for authentication. Issue, bad actors are indeed connecting fine to the VPN Public IP. My first thought was to deploy certs to only allow only our systems to connect. Seems that wont work for sonicwall. (TZ 500 series). I did see some thoughts on moving the ports (SSL from 4433 to something else). I am sure that would help for a bit. However, thoughts to moving the UDP Port (500) typically to somewhere else for ESP phases. Probably would screw the attempts up for a bit longer. Rotating ports ?
Thoughts on that ?
Cheers!
Offhand, does anyone have experience with measuring or limiting tcp connects to the SMA's, to know what legit traffic will do? We keep tweaking our limit, which recently hit a limit of 45 connections/20 seconds from a legitimate user. That seems nuts, and I sure can't reproduce anything near that, so it has something to do with their (home) environment, but wondering if anyone else has useful data points on that?
Thanks
@SnarfySplat
Depending on how big your VPN user base is, that could be quite the burden. What we have done is MFA, GEO-IP Block, and conducted an intense audit of the end user base. If they had not setup the 2FA, the lost VPN access until they did. I have had ONE attempted attack since it was all in place. Assuming you have the SSL-VPN setup to best practices, this should be enough to secure the system. However, until there is a firmware fix, the denial of access as a consequence of this type of attack will continue. To over come that, i communicated to my userbase to contact me when the system presents the exhaustion error and then i manually block the current IP conducting the spray.
Hope all is well.