2.2 to 2.3 isn't upgradeable

[ChrisMcKee]

    ActivateBadBotProtectionParam             = "yes"
    ActivateCrossSiteScriptingProtectionParam = "yes"
    ActivateHttpFloodProtectionParam          = "yes - AWS WAF rate based rule"
    ActivateReputationListsProtectionParam    = "yes"
    ActivateScannersProbesProtectionParam     = "yes - AWS Lambda log parser"
    ActivateSqlInjectionProtectionParam       = "yes"
    AppAccessLogBucket                        = "logs"
    EndpointType                              = "CloudFront"
    ErrorThreshold                            = "50"
    RequestThreshold                          = "2000"
    WAFBlockPeriod                            = "240"

Changing the properties that have been renamed etal from 2.2.

The deployment fails and rolls back with the screenshot errors.

[hvital]

Hi @ChrisMcKee

In order to replicate the behavior here, do you remember what was your configuration before? I mean, for v2.2.0 stack.

In any case, it's recommended to use a blue-green deployment approach by creating a new stack and switch your endpoint to use the new webACL. This way you'll have a easy way to rollback if needed.

On top of that, you can also run the new webACL in test-mode for a while just to triple check if it is working as expected. More info: https://amzn.to/2s3nglj

[ChrisMcKee]

Hi; everything was enabled so bar the renames of parameters it was the same as the first msg. I considered a blue green and tried spinning up a second one hooked to the same logs bucket, which failed with a naming exception; I'm assuming it was related to the naming of the IAM role/policies it creates to access the bucket. (CF error logging is eye wateringly undetailed)

I was running the same setup via a modified version of https://github.com/cerbo/aws-waf-security-automation but there's that many components to keep modifying to keep up to date with the CF version I figured I'd give cloudformation a punt 😁

[hvital]

If you're using the same logs buckets during the blue/green, probably the error is related to Cannot have overlapping suffixes in two rules if the prefixes are overlapping for the same event type. This is caused when the new stack try to subscribe the new Log Parser destination using the same notification structure (event, prefix, suffix) used by the existing stack.

Solutions:

• Temporarily remove log parser event for your logs bucket while you create the new stack and switch WebACL.
• Adapt the solution to receive S3 notifications through a SNS topic (which can be used to forward the event to multiple lambdas). More info: https://amzn.to/2Ck3ENX

PS: Are you using the project through https://github.com/cerbo/aws-waf-security-automation? Never tested this project but can take a look on it ...

[ChrisMcKee]

Nah the cerbo one's a complete terraform version of the cloudformation setup; which is nice as it means it only updates the bits that change. But its out of date and I'm lacking the time to go back through the fork modifying it all (for now).

Ta for the help; I kinda expected cloudformation (going off the reviews from other people) to be a tad more robust for managing upgrades and tracking changes (with the rollbacks built in etc). It's been a 'learning experience' 😉