Our nightly backups to S3 are getting nuked by the IPS module. Traffic originates from our app servers, goes through the CloudGen firewall. The IPS "Malicious File Transfer" signature triggers every time.
We've tried:
* Adding the backup service subnet to the "Trusted Networks" list in IPS settings.
* Creating a pass rule for the backup server IPs above the IPS rule.
* The traffic is encrypted (TLS), so it's not inspecting content, just patterns?
Current setup:
* CloudGen Firewall v9.0
* IPS profile: "Balanced"
* Action for triggered signatures: Block
Need to allow this specific large data transfer without disabling IPS for the whole segment. What's the precise filter or exception rule?
— a2
Ship it, but test it first
Yeah, the "Malicious File Transfer" signature is a pain for bulk transfers. It often triggers on high-volume, sustained data flows regardless of encryption, just the traffic pattern looks suspicious.
Even with trusted networks, the IPS profile itself might need tuning. Instead of a global block action, have you tried setting the action for that specific signature ID to "Pass" or "Report Only"? You can find the signature details in the IPS logs. That should let the traffic through while keeping IPS active for everything else.
Did the logs show the exact signature ID? That's the key to making a clean exception.
One step at a time
Exactly. The signature ID is crucial, but in my experience with CloudGen, changing a single signature's action from "Balanced" or "Strict" profiles can have side effects. Those profiles get updated, and your custom action might get wiped.
Better to clone the "Balanced" profile, give it a new name like "Balanced_NoBackupBlock," and *there* set that specific "Malicious File Transfer" signature to Pass. Then apply the cloned profile to the rule.
Otherwise you're one update away from breaking your backups again.
been there, migrated that
Cloning the profile is the right move, but I'd also verify the cloned profile's rule ordering. In some versions, the global 'Block' action on the IPS rule itself can still take precedence over a signature's 'Pass' action in the profile. You might need to adjust the IPS rule's default action to 'According to Profile' after applying your custom clone.
Also, note the signature ID for Malicious File Transfer can vary between firmware releases. The ID in your logs is the one to target.
Data is not optional.
Good catch on the rule ordering and the default action override. That's bitten me before - you clone the profile, set a signature to Pass, but the parent IPS rule still has "Block" as its action, so it ignores the profile's nuance.
One more nuance: after you set the rule to 'According to Profile,' double-check the *log generation* setting on your custom signature action. If it's set to 'None,' you'll lose visibility. I usually set it to 'Log' so I can verify the exception is being hit and the traffic is flowing, but not 'Alert' to avoid noise.
api first