I have been conducting a detailed performance and stability analysis of our Radware DefensePro deployment over the last three quarters, specifically tracking configuration drift post-maintenance. We have encountered a recurring and critical issue following the application of certain hotfixes and version patches (observed on both 20.2.1.x and 20.3.0.x branches): our custom mitigation policies, particularly those involving complex signatures and behavioral thresholds, partially revert to a seemingly default or previous state.
The problem manifests not as a complete wipe, but as a subtle corruption. For instance:
* **Signature-based policies:** Custom attack signatures we've fine-tuned for false-positive reduction will sometimes have their `Severity` or `Action` fields reset. A previously set `Severity: High` might revert to `Medium`, altering the overall policy risk profile.
* **Thresholds:** Anomaly detection thresholds (e.g., HTTP Max URL Length, Max Requests per Source IP) will revert to factory defaults, causing either a surge in false positives or, more dangerously, a drop in detection efficacy.
* **Protection Templates:** Policies built from modified templates occasionally lose their customizations and revert to the base template structure.
Our change control process is meticulous. We generate full configuration backups (`show configuration full`) immediately prior to any patch activity. Post-patch, a differential analysis (`diff` on pre- and post-backup text files) reveals the alterations. The reverts are not present immediately after the patch application, but appear within 24-48 hours, often coinciding with a scheduled policy push or a system consolidation event.
I have isolated the issue to a specific sequence:
1. Apply a system patch via the management interface (primary C&C).
2. Reboot the managed DefensePro units as instructed.
3. Verify policy integrity immediately – all configurations appear correct.
4. Within the next two days, the system undergoes its scheduled `config-sync` operation.
5. Following this sync, the differential analysis shows the aforementioned reversions.
My current hypothesis is that the patch process may not correctly update an internal configuration schema or version marker, and a subsequent sync operation forces a "reconciliation" with an older or baseline schema stored elsewhere. This is, however, speculative.
**Key Questions for the Community:**
* Has anyone observed similar mitigation policy instability after patching, specifically tied to sync operations?
* Are there known prerequisites or steps (e.g., disabling automatic sync before patching, performing a manual export/import post-patch) that can prevent this?
* Is there a method to validate the configuration schema version before and after a patch to confirm a mismatch?
For reference, here is a simplified example of the differential output we see, focusing on a signature change:
```diff
--- pre-patch_config.txt
+++ post-sync_config.txt
@@ -1543,7 +1543,7 @@
signature "HTTP: Unusual HTTP Method (RFC Compliant)" {
base-signature-id 12345;
status enabled;
- severity high;
+ severity medium;
action drop;
tags {
tag-name "TAG_HTTP";
```
Any shared experiences, diagnostic steps, or confirmed workarounds would be invaluable to our ongoing stability benchmarking.
I've been learning Radware myself lately, and this is exactly the kind of headache I'm scared of running into.
So when you say they revert to a "seemingly default or previous state," does the system's audit log show who or what made the change? Is it logged as the patch itself, or does it look like a user edit? Might help narrow down if it's the patch process or something else kicking in after.
That's a great question about the audit logs. In my experience with similar systems, sometimes the log just shows "system" as the initiator for changes made during a patch cycle, which isn't super helpful.
A trick I've used is to take a config snapshot right before patching - not just a backup, but a detailed export of the specific policies. Then you can compare the literal text files after the patch, regardless of what the log says. It's a bit manual, but it gives you concrete proof of the drift.
Ever tried that? Might be a decent workaround while you're figuring out if it's the patch itself or some post-patch cleanup script.
Infrastructure as code is the only way
Oh wow, that sounds really frustrating. We just started using a similar system for our support portal, and I'd be lost if our internal rules reset like that.
When you say they partially revert, do you mean it's always the same policies or the same *types* of changes? Like, is it only severity levels, or is it a random grab bag of settings? Trying to learn what to watch for 😬
Ask me in a year
>when you say they partially revert, do you mean it's always the same policies or the same *types* of changes?
That's the million dollar question, right? In my experience, it's rarely random, though it looks like it at first. The patch process is probably hitting some deprecated config schema or validation logic that existed when the policy was first created.
You'll often see it target specific *fields* that have a dependency the patch notes don't mention. For us, it was always the timeout and threshold values in behavioral policies, because they changed the underlying data type from integer to float in a patch. The system would "correct" our configs back to a default it understood.
So watch for patterns in the *type* of drift, not just which policies. It's a clue about what the patch actually messed with under the hood. Annoying as hell, though.
NightOps
Your detailed logging of the drift patterns across multiple patch versions is precisely the right approach. We experienced something similar, but on an earlier branch (19.x), and the root cause was ultimately linked to a schema mismatch in the underlying policy database.
Specifically, when a patch performed its internal validation, it would flag certain custom objects as "invalid" because they contained fields that weren't in the default schema template for that policy type. Instead of preserving the non-conforming data, the patch routine silently truncated those fields, reverting them to the schema default. This was most pronounced with behavioral thresholds and custom signature metadata, exactly as you're seeing.
Have you been able to correlate the specific patches that cause this with their release notes, particularly any mention of "database optimizations" or "configuration validation improvements"? In our case, that language was a reliable indicator that we needed to pre-emptively export, then re-import, our critical policies after the patch settled. It's a laborious process, but it became a non-negotiable step in our change control procedure.
That's a compelling point about the schema mismatch being a silent validation failure. It tracks with our logs showing the patch's internal "configuration verification" step immediately precedes the drift we detect.
We haven't found consistent keywords in the release notes, though. The patch that caused our most severe reset was billed as a "memory management enhancement." Your method of post-patch re-import is solid, but we've had mixed results. Sometimes the re-imported policy is immediately flagged by the newly patched system as having invalid parameters, forcing us to rebuild it from scratch against the new schema. Have you seen that happen?
>patch that caused our most severe reset was billed as a "memory management enhancement."
Of course it was. The "feature" patches rarely touch configs. It's always the obscure performance or "stability" updates that shred your policy stack because they sneak in a database schema change.
This is a vendor support problem. You'll spend weeks documenting it, they'll ask for logs, and eventually they'll shrug and call it a "known issue" with a hotfix in the next paid maintenance release.
Our workaround: Never patch without a full config dump and a weekend to rebuild from scratch. Their upgrade validation is just a checklist, not a guarantee.
Read the contract