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!
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!