Options
Is anyone getting hammered by password spray attacks recently?
CBaird
Newbie ✭
In the past month we've been seeing over 100K /day brute force / password spray attacks hitting our SMA appliances daily.
Sonicwall SMA does not appear to have any capability to just automatically block IP addresses when they are obviously using BOTs to try an endless array of passwords against incorrect usernames - i.e. if user doesn't exist, block IP after 10 attempts in < 1 min... or shorter.
Looks like the hackers got a new toolkit and they're really targeting Sonicwall, maybe any SSL-VPN solutions...
Need some kind of DDOS protection for this.
Any ideas?
Category: Secure Mobile Access Appliances
0
Answers
Yes we are seeing a huge amount of invalid user logins on our SMA since last week. They are like 1 every second there has got to be a way to stop this.
We have been seeing this as well since 3/17/24. Began with adding IP blocks as Botnet entries on our NSa's in front of our SMA, which quickly proved futile. Then adjusted the Login Security settings (Lockout for source IP Address>reduced Max Login Attempts per Minute, increased Lockout Period). That had no impact (?!).
Then came across this KB post: https://www.sonicwall.com/support/knowledge-base/sma100-how-to-block-brute-force-dictionary-attacks-with-sma/170502830832951/ . I gather we are required to purchase an additional Web Application Firewall license to combat this sort of attack.
We tried their Web Application Firewall last year when there were sporadic attempts to break into the Sonicwall admin accounts.
It's pretty useless. It locks out IPs that fail login more than X times (you set) - but when a legitimate user gets locked out due to mistyping their password (yes it can happen over 5 times or whatever we set it at :-() -- there's no way to unlock the account. You have to wait through the duration.
I'll have to ask our CTO because I think there were a variety of other problems with it. Costs $1K / year. Sonicwall SMA / Web App firewall support also said it's not being actively developed or improved and so didn't sound very promising that the product issues would get addressed anytime soon...
Instead we removed external web access for admin accounts. But we can't do that for the users.
One saving grace for us is we require 2FA for VPN use so we at least have that extra layer. We are seeing the attacks between midnight and 5AM from what I have gathered from the logs. We do use Geo/IP filters from the NSA which is catching a a lot I also reduced the amount of connections in the firewall rule for the SMA public ip but I can't believe that there is nothing on the SMA to help combat this.
Cheers
Agreed. MFA is a must these days.
We're trying to figure out how to get Sonicwall to introduce a feature that blocks IP addresses when they repeatedly try to login to accounts that are not valid users on the appliance (or AD). With an override, of course, if a mistake is made.
If they did that, we'd see an end to these attacks.
It's not very good for Sonicwall's reputation or standing on Security that they don't address the issue. :-(
Totally agree, it seems like a no brainer to me.
I can only recommend you lock down using the Geo IP as much as possible. Even blocking Russia and China has reduced ours by about 90% 😅
>>Began with adding IP blocks as Botnet entries on our NSa.
I've added the Tor Exit ipv4 to the dynamic botnet list. That stopped 99%
secureupdates.checkpoint.com/IP-list/TOR.txt
Excellent idea (TY!). Query if you had to manipulate to apply this as the DBL on an NSa (we have 2650's)? I am hitting a rejection error due to format, not sure yet if due to list length or because it also contains IPv6 entries. We otherwise have had GEO-blocking locked down on both our NSa's and SMA for years. Stuff we are currently seeing resolve within the lower 48.
How would one accomplish this on an SMA210? I'm only seeing ability to block botnet ip addresses or networks, but no way to import txt files
I don't want to type down the exact solution we found in case the bad guys are reviewing these forum posts (which they probably are), but we worked with Sonicwall support last week and found 2 solutions that really fixed the issue.
They actually have developed the feature I was asking for but it's being debugged. Fingers crossed it will be available to all of us shortly.
Ask about "domain" visibility feature in the web interface and SMA support should be able to show you what you can modify to stop these for now.
Hi.
I would suggest, on TZ- or NSa-Models, to configure the Geo-IP-Block-Feature IN the access-rule for the SSL-VPN-connection with all countries and seperate the locations from where your employees connect. In my case I couldn't block all countries with the global filter because of a web- and mailserver behind the firewall. This solution seems to have a slight lag because the firewall has to solve incoming IPs prior to block them but it seems generally working.
So you worked out a way to slow or stop these on the fly? Would love to know how without having to take the time to deal with support as I am a 1 man show here. But I understand you reasoning.
Cheers
I'm glad to hear a solution is at least in the works. With 2FA enabled, I'm not too worried about this, but the 100s of thousands of emails and logs generated by this are really annoying. It really feels like a feature to prevent this should already exist. Geo-blocking doesn't help me since they all resolve to the US anyways. The WAF paid feature does seem limit attacks against the web portal, but, according to a support agent, it does nothing for the Net Extender portal.
I did this on our SMA, blocking all countries but US and its cut down on login attempts by about 80%. On our TZ470 I have an object address rule that only allows WAN access to our TZ from my home IP address so no other external IP addresses can attempt to log in to it
Thanks for the info I was able to decipher what you were talking about at least with the domains. Testing now.
Cheers
Enabled MFA
Enabled lock IP forever after 3 tries
Disabled the virtual portal for the outside
But even then they still trying...
I even changed the domain to see if it would help...nope it looks like theres some way to bypass that?
Your close as stated above don't want to give the answer out loud incase of wondering eyes. The test I tried yesterday up to this point has stopped all attempts because of "domain" visibility that is the key. If you go through your SMA you will figuer it out. I can't say they aren't trying they just aren't getting any response or connection because of this.
Good luck
Ah, you're using SMA, I'm using a TZ, I don't know if I will have the same options as you do.
@mwatson536 you can send me a message with the configuration?
I agree that this is getting out of control. I have over 27k attempts in the past 3 hours alone. This is definitely impacting our network…It is aggravating that there isn't a security option to block IP automatically to protect against this brute force attack attempts. I enabled MFA a long time ago so thats a saving grace on that aspect but still frustrating there isnt a way to block this completely.
Perhaps it may be time for us to look at other vendors because we are an extremely small IT shop to have this much overhead….
And from time to time they can break my firewall, good thing I have HA in place otherwise my network would be down…
I think that this issue is with the newer version of the firmware 7.1.1
Does anybody know if this is happening on Fortigate as well?? We are thinking of switching over all our routers upon renewals.
It has been a nightmare the past 2-3 weeks with all these problems, especially those 7.1.1 with the reboot issues.
and now this spray attack.
@grabbath blocking bad logins is available in FortiOS for ages. But nearly all VPN solutions are under attack at the moment.
https://community.fortinet.com/t5/FortiGate/Technical-Tip-How-to-limit-SSL-VPN-login-attempts-and-block/ta-p/194229
Most of my deployments are authenticating against Radius and this gives me the additional juice I need for limiting bad logins.
—Michael@BWC
Hey sorry everyone - been slammed with other emergencies - Healthcare insurance renewal time for my company… OMG our system in the US is so horrible! :-(
For those that asked - yes we used the hide the Domain solution and it worked for about 10 days - no more attacks. But the bad guys have caught on to that and updated their kit.
Best thing we can do now is all pressure Sonicwall support and the Developers — go to your Sales Account Manager to do this - to FIX THE BUG in their feature that blocks IPs after X (you select) failed logins. For those that implemented that item, we heard from Sonicwall Support that it simply doesn't work.
And ask your Sales Account Manager to block any IP trying to login when it's not using a valid username — with an override when stupid mistakes happen… because they always will. I believe this is the only way we can stop these attacks.
Bots gotta be fought by automation. Nothing manual is going to work.
Best of luck everyone!
I'm running the NSa2650 and I really believe the user lockout option does not work.
a. Select Enable local administrator/user account lockout (uncheckfor login IP address lockout).This option locks out user accounts and IP addresses when they have surpassed a specified
number of incorrect login attempts. This option is only available when Enable administrator/user
lockout is selected.
It clearly states to UNCHECK it if you want the IP to lockout, after X attempts. IT DOES NOT SEEM TO WORK. This is a bug, a flaw, whatever you want to call it. Why is Sonicwall not immediately fixing it? Then it doesn't matter if it's a real user name, or a fake username, after X invalid attempts it should block that IP. Am I missing something?
Same here on my 2650. That TOR list is not loading (too large?). I ended up using this much smaller FEODO list:
https://feodotracker.abuse.ch/downloads/ipblocklist.txt
But I don't think that will help with this Login Credentials attack we are experiencing right now.
We are experiencing this issue with at least two of our SMA customers. SonicWall Support has insisted the "IP lockout" feature (which is a total misnomer and should be renamed) is working as expected and is not a bug. We disagree of course, but are not expecting a hotfix of any sorts. We've had some success in using Geo-IP Filter and a Dynamic Botnet List on the upstream SonicWall firewall to block TOR exit nodes, but I understand not everyone has a firewall in front of their SMA, so hopefully SonicWall can produce an on-board solution for the SMA soon.
Ugh - that's unfortunate… but thanks for letting me know SheildITNetworks.
We use the Geo-IP filter within the SMA appliance — when we implemented in our firewall it caused too many false-positive problems for clients going to various business websites that do business in the USA but are actually hosted in other countries. When this started, the worst attacks were coming from the Netherlands, then Germany and France. But since they're using TOR exit nodes, the benefit we achieved has diminished considerably.
Cisco, unfortunately, has no automated / managed system for TOR exit nodes so we'd have to apply the list and it changes ~ every 6 hours or even more frequently from what we're seeing.
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).
I'm trying various blocklists; you can get TOR exit nodes from https://secureupdates.checkpoint.com/IP-list/TOR.txt @CBaird, I infer you have a cisco firewall? Cisco always supports routing protocols, you might be able to easily script a download of some blocklists and feed it to your cisco via bgp for a null route.
My current gameplan, time permitting, is to grab syslog output from the SMA, parse to find repeated failures, and feed it back to the firewall sitting in from of them. Hopefully SonicWall ups their game and adds support to block this blatent/obvious abuse.
Team
Please refer to this KB for more information and follow the steps. If you still have issues, then open a ticket so that one of support engineer can share the build along with few more new settings with new build, That should to help mitigate this issue
https://www.sonicwall.com/support/knowledge-base/how-to-mitigate-dos-and-ddos-attacks-towards-sma-appliances/240410085042530/
Vijay Kumar KV
Enterprise Tech Support Consultant | SME