Join the Conversation

To sign in, use your existing MySonicWall account. To create a free MySonicWall account click "Register".

Recent vulnerability SNWLID-2020-0010

Hi,

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 6.5.0.2-8v-37-628-6103f3e3

Are these affected?

Is there a patch for 6.5.0.2 Azure NSv or do I have to Re-deploy with Version 6.5.4.4 and upgrade to sonicwall_nsv_azure_6.5.4.4-44v-21-987

Category: Virtual Firewall
Reply

Best Answer

Answers

  • BWCBWC Cybersecurity Overlord ✭✭✭

    Hi @Otown

    in my understanding everything is affected listed here (including earlier releases):

    • SonicOS 6.5.4.7-79n and earlier
    • SonicOS 6.5.1.11-4n and earlier
    • SonicOS 6.0.5.3-93o and earlier
    • SonicOSv 6.5.4.4-44v-21-794 and earlier
    • SonicOS 7.0.0.0-1

    And it's fixed with these releases (and later).

    • SonicOS 6.5.4.7-83n
    • SonicOS 6.5.1.12-1n
    • SonicOS 6.0.5.3-94o
    • SonicOS 6.5.4.v-21s-987
    • Gen 7 7.0.0.0-2 and onwards


    I'am no NSv user, but I guess you can install 6.5.4.4-44V-21-987, which is available as .SWI file, only if you already running 6.5.4.4, which is not the case. I wasn't aware of such a limitation and it does not sound like maintaining of NSv that comfortable.

    --Michael@BWC

  • OtownOtown Newbie ✭
    edited October 2020

    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?

    Like

    • SonicOS 6.5.4.7-79n and earlier
    • SonicOS 6.5.1.11-4n and earlier

    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 :( .

  • MicahMicah Administrator

    🖐️ Sr. Manager, Web and Digital, SonicWall. Say "hi" by tagging me at @micah.

  • OtownOtown Newbie ✭

    @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


  • kthorkthor Newbie ✭

    Hello,

    Anyone seen statements regarding the SRA and SMA systems?


    K

  • BWCBWC Cybersecurity Overlord ✭✭✭

    @kthor

    that's a valid question about SRA/SMA, not sure how far the similarties are internally.

    What I noticed, that the build date of 6.5.4.7-79n is Aug 22nd, that must be a heck of an internal review until it got released more then one month later.

    --Michael@BWC

  • 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.

  • SonicAdmin80SonicAdmin80 Newbie ✭
    edited November 2020

    That's what I thought also. So the release notes are correct .

  • RedNetRedNet Enthusiast ✭✭

    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 6.5.0.2) 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 6.5.4.4 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.

Sign In or Register to comment.