We had out VPN taken down this past weekend… NSA2700.
Our VPN address was “known” as was at least one userId.
The result was that they attempted many times to log into the VPN, which resulted in the LADP query, which resulted in the AD account getting locked… Okay, so security was doing its job.
I want to re-enable the VPN.
- I’m going to change the public IP address of the Sonicwall.
- I’m going to updated the FQDN for the VPN to a different name.
I would like some kind of “automatically block the IP address following failed logins” - but have no idea if theres any way to do this.
I would like to block a userID from signing in after XX attempts - so I can block it at the firewall before it locks the AD account.
Can I do any of those things?
Are you using SSLVPN or Global VPN client?
Can you filter attempt to log into the VPN by geo location? Do you have a need for foreign access?
Are you using 2FA?
IP blocks don’t work best thing you can do for yourself now is get that idea out of your head.
A combination of security measures are needed.
GEO-IP
AD locking on failed logins and things like setting up users with specific time frames they log into AD
2FA
Your VPN will always be known. Don’t change what you have now and inconvenience your users. A bit will sniff out your new address before the day is over.
Implement proper security measures.
Using SSLVPN with LDAP authentication, and MFA via the Authenticator (Bind) app…
GeoIP can help, and we’ve blocked the “bad country list”.
Before we shut things down, at least one userID was known, and it was getting locked out withing 10 seconds of us unlocking it…
Even though I have the management/local account set to lock after 3 failed attempts, I was still able to lock my AD account by typing my username & bad password 5 times in a row…
Is there any way to block the IP address automatically after failed login attempts - or to send an alert to an email, so that I can lock them manually?
When your guys call support, ask for the HF Gen7-47736. SonicWall came out with a possible fix last Friday. Call support and make sure this is applicable in your case.
We had this problem on the weekend on a TZ. We have max attempts set under admin and the lockout is permanent. Although the attack was distributed on many IP’s, it did the job. GEO blocking is great unless it’s a country you need to communicate with. I.e cloud backup.
I highly recommend Duo RADIUS for MFA if your using Net Extender. It cost but it’s very secure. It will continue to use your AD for credentials as well for the users.
Also, their was reported to be a Net Extender vulnerability so make sure your users have the most updated client.
We have seen this on a few units (we only have TZs in the field) over the last week. GEO-IP is the right answer, at least in our case. We also shut off the Virtual Office portal on the WAN side initially, but after we realized clamping down on GEO-IP solved most of the problems, we re-enabled it. All users should have 2FA enabled, it’s crazy not to these days.
Some of the IPs trying to get in were in the US (as we are), so GEO-IP didn’t help there, but there were only a handful, so we blocked those directly with a WAN-to-WAN deny rule. u/drozenski is right, blocking IPs isn’t a scalable solution, but in our case we only had to block about 5 of them and the attempted logins stopped.
What is this? A firmware update?
Would you be willing to confirm the SHA256 sum for any of the hotfix firmware you was provided matches what I have? I’m trying to see if it’s serialized or if they can be used on any SonicWall device, as we have many deployed and I’d rather not create a support case for each and every registered device we have deployed.
71ee72e652515512aea93e4e76ba1ba6c57e1ed355d5013a3b48f5d99f1712c8 sw_tz_270.7.1.1-7051-R3262-HF46826.bin.sig
861cdc6aa9a3083dd6b0b65ed6ca795d8862ca772490b9b54b59f74d439765e4 sw_tz_270w.7.1.1-7051-R3262-HF46826.bin.sig
97fdc5ce20d807f2f15018fdb9f595c9a7f534fde0ae17e681467c5e67076eef sw_tz_370.7.1.1-7051-R3262-HF46826.bin.sig
8135ca3b8cfd072a4ad510cf44c0ca78496f667f3c8f0c1fcf9bac28494827f5 sw_tz_470.7.1.1-7051-R3262-HF46826.bin.sig
4752e78830d1b4005488349677dc670f03986b965a422a4baa9c2f986b9bdfeb sw_tz_570.7.1.1-7051-R3262-HF46826.bin.sig
28201d9dd6eca385c916c4fa9ea07b470a7d7054bcc62eef40182bbad92af166 sw_tz_670.7.1.1-7051-R3262-HF46826.bin.sig
We had the exact same scenario with good results after following the same path as you. We also put a schedule on the allow rule for incoming sslvon and that was helpful.
Yes, it is a hotfix firmware version you can upgrade the firewalls with, which will help with this VPN issue you are seeing.
I was advised by SonicWall support that these are not serialized hotfixes. They simply verify the serial number of the affected device to ensure you have a registered and supported device that is eligible for the hotfix.
This has been an issue since last September. I’m glad they’re working on a solution.
It can be available to you if you log a support case. You should be able to get this to help with the problem. It does help with VPN licensing, but dhcp still hands out an IP, so you may want to expand your dhcp scopes to help.
Does it do anything to prevent or mitigate the spam logins? Or is it simply a patch to prevent the licenses from being consumed by not-fully authenticated sign ins.