A lawsuit against SonicWall highlights a critical DevOps blind spot: treating appliance backups as an afterthought. Learn why vendor-provided backups can fail and how to build a resilient, multi-layered strategy for your network configurations using Git, IaC principles, and isolated storage.

Your Firewall Backup Is a Lie (And How to Fix It)

It was 2 AM. Of course it was. PagerDuty was screaming about a total network outage at our primary data center. A junior engineer, bless his heart, had tried to push a “routine” firmware update to our core firewall cluster, `corp-firewall-primary`, and turned it into a very expensive brick. “No problem,” he’d said, “I’ll just restore from the cloud backup.” An hour later, my phone rang. The vendor’s cloud portal was throwing a cryptic 500 error, and the “one-click restore” was a fantasy. We spent the next six hours rebuilding the ruleset from memory and old change tickets. That night taught me a lesson I’ll never forget: if your backup isn’t in your own control, you don’t have a backup.

So when I saw the news that a law firm, Marquis, is suing SonicWall over a supposedly failed firewall backup leading to a ransomware attack, I just nodded. I’ve lived that nightmare. It’s a classic case of what happens when we blindly trust a vendor’s marketing materials over sound engineering principles.

Why This Keeps Happening: The Fallacy of the “Set It and Forget It” Backup

Look, the root cause here isn’t a single faulty product. The real issue is a mindset problem. We treat critical network appliances like magic boxes. We configure them once, enable the vendor’s convenient “cloud backup” checkbox, and move on. We assume that because we pay them a subscription, they’ve got our back.

But that backup is often an opaque process. Where is it stored? How is it encrypted? How is it versioned? Can you perform a partial restore? Most importantly, have you ever actually tried a full, bare-metal restore from it? The lawsuit alleges that the backup simply wasn’t there when it was needed. Whether it was a technical glitch, a misconfiguration, or something else, the outcome is the same: a critical failure at the worst possible moment.

Your firewall configuration—your ACLs, NAT policies, VPN tunnels—is as vital as your production database. It’s your company’s front door, and its configuration is the key. You wouldn’t let your database provider be the *only* one with a copy of your data, would you? It’s time to apply the same rigor to our network infrastructure.

Fixing The Problem: From Panic to Process

Here are three ways to take back control, ranging from a quick fix you can do today to a proper, resilient system that will let you sleep at night.

Solution 1: The Quick Fix (The “Better Than Nothing” Dump)

This is the manual, “break-glass-in-case-of-emergency” approach. It’s not pretty, it’s not automated, but it’s a thousand times better than having nothing. The goal is to get a plain-text copy of your device’s running configuration and store it somewhere safe.

You literally SSH into your device and dump the config to a text file. For a Cisco-like device, it might be:

darian.vance@bastion-host:~$ ssh admin@fw-dmz-01
admin@fw-dmz-01# show running-config
!
! Last configuration change at 14:25:31 UTC Tue Nov 5 2024
!
version 16.9
hostname fw-dmz-01
!
ip access-list extended INGRESS_WEB
 permit tcp any host 10.100.1.50 eq 443
 deny   ip any any log
!
...
end

Copy that entire output. Save it as `fw-dmz-01-config-backup-YYYY-MM-DD.txt` and store it in a secure location like a password manager (1Password, Bitwarden) or an encrypted folder. Do this after every significant change. Is it tedious? Yes. Is it a lifesaver when that device fails? Absolutely.

Solution 2: The Permanent Fix (The “Infrastructure as Code” Approach)

This is where we start acting like true DevOps engineers. We treat our firewall configuration as code. This means version control, automation, and an audit trail.

The concept: Use a tool to automatically pull the configuration from your firewall on a schedule (e.g., nightly), check if it has changed, and if it has, commit it to a dedicated Git repository.

My weapon of choice here is Ansible. It has modules for nearly every network vendor out there. You can create a simple playbook that connects to the device, fetches the config, and saves it locally. A CI/CD tool like GitLab CI or Jenkins then runs this playbook and handles the Git side.

Here’s a conceptual Ansible task snippet:

---
- name: Backup Firewall Configuration
  hosts: firewalls
  gather_facts: false
  connection: network_cli

  tasks:
    - name: Fetch running configuration from device
      cisco.ios.ios_command:
        commands:
          - show running-config
      register: firewall_config

    - name: Save config to file
      copy:
        content: "{{ firewall_config.stdout[0] }}"
        dest: "./configs/{{ inventory_hostname }}.cfg"

This playbook logs in, runs `show running-config`, and saves the output to a file named after the device. Your CI pipeline then runs a `git add`, `git commit`, and `git push`. Now you have a versioned history of every change made to your firewall. You can see who changed what and when (or at least, when the change was detected), and you can revert to any previous version with ease.

Solution 3: The ‘Nuclear’ Option (The “I Trust No One” Strategy)

This is for the truly paranoid and the heavily regulated. It builds on Solution 2 but adds a crucial layer: redundant, isolated, and immutable storage. Don’t just trust your GitLab instance. What if your entire primary cloud account or on-prem environment is compromised?

The concept: After your CI pipeline commits the config to Git, add another step to push an encrypted copy to a completely separate, air-gapped-style location.

This means:

• An AWS S3 bucket in a completely different AWS account, with Object Lock (immutability) enabled.
• An Azure Blob Storage container with immutability policies.
• A Backblaze B2 bucket.

The key is that the credentials for this storage are *only* known to the CI runner, and they have write-only permissions. No one can easily log in and delete the backups.

A final step in your CI pipeline might look like this:

# Last step in your gitlab-ci.yml or Jenkinsfile
- gpg --encrypt --recipient security-team@techresolve.com -o configs/{{ inventory_hostname }}.cfg.gpg configs/{{ inventory_hostname }}.cfg
- aws s3 cp configs/{{ inventory_hostname }}.cfg.gpg s3://techresolve-disaster-recovery-bucket/firewall-configs/ --profile isolated-backup-user

Darian’s Pro Tip: A backup that hasn’t been tested is just a rumor. Whatever solution you choose, you MUST schedule regular fire drills. Once a quarter, spin up a virtual appliance or a lab device and try to perform a full restore from your chosen backup. If the process is painful, automate the pain away. The time to find out your GPG key is expired is not during a real outage.

Comparing the Approaches

Ultimately, the SonicWall lawsuit is a wake-up call. We can’t abdicate responsibility for our own infrastructure’s resilience. Stop clicking the “backup” checkbox and start building a real, testable, and controlled recovery process. Your 2 AM self will thank you for it.

Darian Vance

Lead Cloud Architect & DevOps Strategist

With over 12 years in system architecture and automation, Darian specializes in simplifying complex cloud infrastructures. An advocate for open-source solutions, he founded TechResolve to provide engineers with actionable, battle-tested troubleshooting guides and robust software alternatives.

🤖 Frequently Asked Questions