Recent vulnerability SNWLID-2020-0010
Otown Newbie ✭
Can someone please explain more on this.
Are all firmwares below latest affected? The advisory is confusing to read.
I have some Azure NSv's on SonicOS Enhanced 22.214.171.124-8v-37-628-6103f3e3
Are these affected?
Is there a patch for 126.96.36.199 Azure NSv or do I have to Re-deploy with Version 188.8.131.52 and upgrade to sonicwall_nsv_azure_184.108.40.206-44v-21-987
Category: Virtual Firewall
Hey! You will be signed out in 60 seconds due to inactivity. Click here to continue using the site.
in my understanding everything is affected listed here (including earlier releases):
And it's fixed with these releases (and later).
I'am no NSv user, but I guess you can install 220.127.116.11-44V-21-987, which is available as .SWI file, only if you already running 18.104.22.168, which is not the case. I wasn't aware of such a limitation and it does not sound like maintaining of NSv that comfortable.
Cheers Michael, yeah its not as well explained as the other CVE's where they give you all the models and firmware versions to and from?
why mention both, if it is 6.5.4 and earlier, that includes 6.5.1 ? Or why not say 6.5.2 also if you are mentioning all the 6.5.x versions? or 6.2.x?
Unfortunately yes on the Azure NSv's if deployed pre 6.5.4 they are on 6.5.0. It sounds like using the VM re-deploy option in Azure will re-deploy with all the same azure resources but on 6.5.4 and then you just import the settings but again their guide is vaguely unhelpful :( .
Please also refer to the following alert: https://www.sonicwall.com/support/product-notification/sonicwall-dos-xss-vulnerabilities/201015132843063/
@micah - SonicWall's Self-Service Sr. Manager
@Micah Thanks, thats a little clearer I guess.
My NSv's in Azure are still a concern. I also have some on 6.5.4-757 and they do not find the new firmware when using the "advised" console method.... ughh
Anyone seen statements regarding the SRA and SMA systems?
that's a valid question about SRA/SMA, not sure how far the similarties are internally.
What I noticed, that the build date of 22.214.171.124-79n is Aug 22nd, that must be a heck of an internal review until it got released more then one month later.
Support said that the swi file can just be used and that the release note recommendation to use System Update is incorrect. Can someone from Sonicwall comment on this and if that's really the case the release notes should be corrected.
I just also noticed that now the update is available through System Update, so I'll probably just do it from there anyway.
That's what I thought also. So the release notes are correct .
I had to go through all of this so here's the story. I am the same person as the OP Otown :)
If your NSv in azure is already a 6.5.4 then you can use the SWI or system upgrade, have used SWI and it was fine.
If it is lower than 6.5.4 (like 126.96.36.199) then you need to spin up a new NSv VM and migrate the config and PIPs.
I documented the process for this:
STEP 1. Export TSR and Settings from existing(old) NSv - remember to take note of the Authentication code/Serial Number.
STEP 2. Deploy latest new NSv in a new RG and as a part of same Virtual Network with a different LAN and WAN interface ip but same subnet.
STEP 3. Move new NSv and all resources attached to old NSv's Resource Group
STEP 4. De-register the Old NSv from within the web mgmt.
STEP 5. Login and Register the new NSv (using new X1 pip) with auth and serial from step 1
STEP 6. Stop (deallocate) both NSV VM's in azure portal
STEP 7. De-attach the X1 and X0 interface from old NSv and new NSv
STEP 8. Attach the old X1 interface to the new NSV first, then attach the old X0 interface to the new NSv
STEP 9. Start and login to new NSv using X1 PIP (note admin/password will have reset to default) and import old settings from step 1
@RedNet That's quit a procedure. Luckily I was on 188.8.131.52 already so I could do the system update once it was finally available. It must have been over a week since the swi release when it became available throught system update.