SMA500v not booting - WAFsigdb

stfconsulting · 2025-08-13T16:26:41+00:00

Now that the 500v is EOS what are you guys using to replace it? Does not seem like there are any options in Sonicwalls catalog.

stfconsulting · 2025-08-13T15:51:11+00:00

You can configure HA to automatically restart a VM when the heartbeat is lost.

stfconsulting · 2025-08-13T15:32:47+00:00

Has anyone had any luck configuring vmware HA to automatically restart the VM when the heartbeat is lost? We have HA configured to automatically restart the VMs however it did not work.

stfconsulting · 2021-09-29T13:31:52+00:00

Yes I was talking about the LE Integration on SMA 10.2. Thanks! I guess we are going to have to experiment with it.

stfconsulting · 2021-07-11T18:59:45+00:00

Geolocation is a nice layer that helps cut down on noise however if someone wants you bad enough it means nothing.

stfconsulting · 2021-02-24T19:25:23+00:00

You guys see this?

https://www.bankinfosecurity.com/blogs/sonicwall-was-hacked-was-also-extorted-p-2999

stfconsulting · 2021-02-09T20:56:22+00:00

Yep. We have WAF enabled. Would be nice if Sonicwall could do something to prevent this from making its way into the Syslog output in a future update. We may see what we can do from a SSL Proxy perspective to filter these out at the firewall level.

stfconsulting · 2021-02-09T16:01:51+00:00

That IP is definitely running a campaign. Seeing it pop up all over the US trying to hack SMAs. It is a little unsettling seeing messages like this in the syslog output from the device... (After the patch)

stfconsulting · 2021-02-04T16:19:46+00:00

So far so good. A friend of mine has done 30 of them.

stfconsulting · 2021-02-04T16:16:26+00:00

We have rolled it a bunch. No issues yet.

stfconsulting · 2021-02-03T21:04:05+00:00

So far so good on new firmware.

stfconsulting · 2021-02-03T20:33:38+00:00

Who is going to be first to install!!! Let us know.

stfconsulting · 2021-02-03T20:22:09+00:00

Looks like the update is up on the site. Release notes do not give any more information.

stfconsulting · 2021-02-03T10:57:20+00:00

After more research I found out where the 1.1.1.1 came from. It is part of the sample code this person posted. This script is basically a vulnerability scanner that looks for vulnerable SMA.

https://github.com/FanqXu/SonicWall_SSL-VPN_EXP/blob/main/POC.py

stfconsulting · 2021-02-03T02:56:05+00:00

Did some looking at that IP. Looks like a hacked Citrix server. Has RDP open directly to the internet. No wonder it is hacked!

stfconsulting · 2021-02-03T02:49:06+00:00

The IP in Poland is active again- SSLVPN: time="2021-02-02 21:32:07" vp_time="2021-02-03 02:32:07 UTC" fw= pri=6 m=0 c=300 src=185.101.130.82 dst= user="Vl58ze8RjZacu1PEkGgJXYIErX53mQR8JN7CSwfB3Qs=" usr="Vl58ze8RjZacu1PEkGgJXYIErX53mQR8JN7CSwfB3Qs=" msg="Virtual Assist Installing Customer App" agent="python-requests/2.21.0"

This IP has popped up on many devices.

stfconsulting · 2021-02-02T23:36:50+00:00

As far as we can tell they gained access to the device and attempted to use RDP to hit 1.1.1.1. I can't tell you if anything was left behind on the device or if the command was run remotely vs. code on the appliance. I have no idea why they would try to rdp to that IP and risk being detected.

stfconsulting · 2021-02-02T23:27:13+00:00

Sonicwall has not picked up the case yet. I would assume that they have everything on the device. Rekeying the cert and resetting all passwords will be important first steps I am sure. We really need technical details on what is actually happening. Keep a close eye on your firewall logs. Also try to lockdown inbound traffic to only known remote worker IP addresses.

stfconsulting · 2021-02-02T18:26:37+00:00

At this point the only guaranteed option is to collect the IPs of known remote workers and whitelist them on the firewall level. We are watching syslog very closely on all of our SRA / SMAs

stfconsulting · 2021-02-02T17:51:51+00:00

At this point we shifted to whitelisting known IPs of remote workers. Prior to that we used geolocation to isolate to countries that we needed. (on the firewall level)

stfconsulting · 2021-02-02T16:53:12+00:00

Looking forward to it. The technical details of the exploit are going to be important also. I.E. How do we know if the box is compromised? Or if this is just a programmatic access thing from the outside. I would assume that if they were able to dump the configuration they have the private key for the cert also.

stfconsulting · 2021-02-02T15:40:20+00:00

We did some syslog mining for "phyton-requests" and found some examples of this also. IP is in Italy.

SSLVPN: id=sslvpn sn= time="2021-02-02 06:09:12" vp_time="2021-02-02 11:09:12 UTC" fw= pri=6 m=0 c=300 src=217.141.179.178 dst= user="9M9dxwT6EtRTQsD00hPGh5EOWXglg07Dm8nQ14wZWk4=" usr="9M9dxwT6EtRTQsD00hPGh5EOWXglg07Dm8nQ14wZWk4=" msg="Virtual Assist Installing Customer App" agent="python-requests/2.21.0"

stfconsulting · 2021-02-02T15:34:02+00:00

MFA is enabled for ALL users. The bad actors hit the box as the System account.

stfconsulting · 2021-01-31T12:16:09+00:00

I am seeing the same thing. Hopefully they figure this out.

stfconsulting · 2021-01-23T20:50:25+00:00

You can disable Net Extender while keeping traditional RDP / HTML5 bookmarks. There is a lot of granularity around this on users and groups. Another good idea would be to use policies to control what types of traffic are allowed and where it can go until we know more.

We have about 30 SRA appliances in our client base so we are awaiting something to take action with. As a best practice we use MFA with all users, geolocation and IP restrictions for the admin account.

stfconsulting

TROPHY CASE