"Hostname in HTTP request (194.126.141.186) does not match the server name (utm)"

The certificate used in the Virtual Server determines the FQDN that must be used in the HTTPS request. If that doesn't help, please Use rich formatting and insert a picture of the edit of your Virtual Server wit 'Advanced' open.

Cheers - Bob

Sorry for sort of hijacking this thread.

What exactly is the IP listed between the brackets? I'm having HTTP DDoS attacks that fill the reverseproxy log at a very fast rate, but the IP listed not in our public range?

Harro, (194.126.141.186) above would appear to be the public IP that his Virtual Server uses.  I wanted to see if he had either 'Rewrite HTML' or 'Pass host header' selected.

Cheers - Bob

Bob,

Thanks, I thought so.

My issue is that in the reverseproxy.log lines I have an unknown IP. Not only not a virtual server, not even an IP in one of our ranges. So this must be a fake/constructed HTTP header, since the "Host" header contains a different IP from the virtual server that is being connected to.

Is there a way to have the firewall or the WAF drop all these url_hardening errors? Now I have to add host entries for each of the abusers source IP's so I can block them in my blackhole route. And since they are a different set every day (we get attached on a daily basis), thats a lot of manual work...

Bob,

Thanks, I thought so.

My issue is that in the reverseproxy.log lines I have an unknown IP. Not only not a virtual server, not even an IP in one of our ranges. So this must be a fake/constructed HTTP header, since the "Host" header contains a different IP from the virtual server that is being connected to.

Is there a way to have the firewall or the WAF drop all these url_hardening errors? Now I have to add host entries for each of the abusers source IP's so I can block them in my blackhole route. And since they are a different set every day (we get attached on a daily basis), thats a lot of manual work...

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.