Can you show us an example from the WAF log?

Cheers - Bob

Sure, not problem.

Typically every attack cycle comes from 5-6 IP addresses, at about 10.000 req/s.

What I think is that these are requests for one of our valid public IP's on the external interface (and not on hostname), with in the http header "host: 5.135.179.221" (which is not ours). And "webserver.name" is simply the first defined in the WAF on that IP, so the logentry is slighly misleading.

We have an Arbor Networks DDoS system in front of the UTM, and that does kick in initially, but then the number of concurrent requests seem to go down below the threshold for that system, and still hits the UTM. Since we also host high volume sites, we can't lower that threshold, so I'm looking for a solution that doesn't block legitimate traffic.

Now, every time our monitoring system sends a high CPU alert out, I have to manually check the reverseproxy.log for these IP's, and add them to as individual hosts to the network group that I have defined for the blackhole route. Once done, order is restored and CPU drops from 90-95% to 15-20%. Until the next attack cycle. This happens about 2-4 time every day now, so I'm looking for a less manual solution. ;-)

I think you're stuck with the manual approach until you decide to hire someone with strong RESTful API skills.  Maybe Sophos has a consultant that could do this.  Don't share the solution with us, but please let us know if you've found someone that can do this.

Cheers - Bob

Was afraid of that.

API skills isn't a problem, we've got a full house of those. Challenge will be to find a way to get a trigger from the RP.

What I have a bit of an issue with is that obviously there is something that checks and validates the HTTP header in a URL hardening process, but I can't find what it is exactly (it's not httpd, it might be mod_security?), and there also doesn't seeem to be a way to change the detection into a rejection... 

Interesting.  Maybe you could run a cron job every minute that looks for "does not match the server name" in a tail of the log.  I realize that's not very elegant, though.

Cheers - Bob

Nope. I'll have a deep think about this, I'll report back if and when I have found a solution.