I know this blogging system runs on WordPress. So our WordPress on GCP are under attack by bots causing DDoS and I had to take them down by deleting NS Records (duh). It’s time to use mod_security2 as I did before on onprem servers. Google rebranded mod_security2 as Google Cloud Armor (GCA). This article is for documentation purpose only, use it with caution.

Prerequisite

• A backend service is already configured in (classic) load balancer.
• You’re familiar with gcloud CLI.
• Your public IP address is within GCP VPC Network

Things to do
First thing first: create policy name “block-with-modsec-crs”

gcloud compute security-policies create block-with-modsec-crs --description "Block with OWASP ModSecurity CRS"

Create priority number 2147483647, the lowest rule for our block-with-modsec-crs policy, give it action deny-403 as per GCA rule.

gcloud compute security-policies rules update 2147483647 --security-policy block-with-modsec-crs --action "deny-403"

Create rule number 10000, only allow HTTP(S) traffic from your internal network. Use “curl ifconfig.me” from your terminal (not gcloud CLI) to show your own IP. This is optional. You can skip this rule.

gcloud compute security-policies rules create 10000 --security-policy block-with-modsec-crs --description "allow traffic from my IP" --src-ip-ranges "1xx.1xx.1xx.1xx/32" --action "allow"

Priority number 9000: block LFI Attack, give those bots a HTTP Error 403 instead. This is taken from CRS 3.0 expression.

gcloud compute security-policies rules create 9000 --security-policy block-with-modsec-crs --description "block local file inclusion" --expression "evaluatePreconfiguredExpr('lfi-stable')" --action deny-403

Priority number 9001: block RCE (CRS 3.0 expression), give HTTP error 403.

gcloud compute security-policies rules create 9001 --security-policy block-with-modsec-crs --description "block rce attacks" --expression "evaluatePreconfiguredExpr('rce-stable')" --action deny-403

Priority number 9002: block bot scanner (CRS 3.0 expression), give HTTP error 403

gcloud compute security-policies rules create 9002 --security-policy block-with-modsec-crs --description "block scanners" --expression "evaluatePreconfiguredExpr('scannerdetection-stable')" --action deny-403

Priority number 9003: block protocol attacks (CRS 3.0)

gcloud compute security-policies rules create 9003 --security-policy block-with-modsec-crs --description "block protocol attacks" --expression "evaluatePreconfiguredExpr('protocolattack-stable')" --action deny-403

Priority number 9004: session fixation (CRS 3.0)

gcloud compute security-policies rules create 9004 --security-policy block-with-modsec-crs --description "block session fixation attacks" --expression "evaluatePreconfiguredExpr('sessionfixation-stable')" --action deny-403

Priority number 9005: block sql injection (CRS 3.3 expression)

gcloud compute security-policies rules create 9005 --security-policy block-with-modsec-crs --description "prevent sqli-canary rule-1" --expression "evaluatePreconfiguredExpr('sqli-v33-stable')" --action deny-403

Priority number 9006: block xss injection (CRS 3.3 expression)

gcloud compute security-policies rules create 9006 --security-policy block-with-modsec-crs --description "prevent xss rule-1" --expression "evaluatePreconfiguredExpr('xss-v33-stable')" --action deny-403

Priority number 9007: block php injection attack (CRS 3.3)

gcloud compute security-policies rules create 9007 --security-policy block-with-modsec-crs --description "prevent php injection attack-1" --expression "evaluatePreconfiguredExpr('php-v33-stable')" --action deny-403

Attach rules above to WordPress backend. Use this command to show all your backends: gcloud compute backend-services list.

gcloud compute backend-services update backend-wordpress --security-policy block-with-modsec-crs --global

Play with those rules above: add, modify, remove. Find reference here.