At the Django level, we already try to tune out the very common DisallowedHost exception that Django throws when it encounters spoofed hostnames that are not in ALLOWED_HOSTS. However, there's a certain class of vulnerability scan/attempt which fakes a hosthame that doesn't comply with the RFC, so seems to trigger DisallowedHost but in a way that isn't filtered out. Originally it was thought that this was a different code path in Django, but it's not, so maybe the Django-oriented logger filtering isn't working as expected any more.
This means that Sentry gets a reasonably high volume of errors that we could just be ignoring, and which will be eating into quotas, so it makes sense to find a way to tune these out, too
Context
At the Django level, we already try to tune out the very common
DisallowedHost
exception that Django throws when it encounters spoofed hostnames that are not inALLOWED_HOSTS
. However, there's a certain class of vulnerability scan/attempt which fakes a hosthame that doesn't comply with the RFC, so seems to triggerDisallowedHost
but in a way that isn't filtered out. Originally it was thought that this was a different code path in Django, but it's not, so maybe the Django-oriented logger filtering isn't working as expected any more.This means that Sentry gets a reasonably high volume of errors that we could just be ignoring, and which will be eating into quotas, so it makes sense to find a way to tune these out, too
Success criteria
DisallowedHost
events are sent to Sentrybedrock
https://github.com/mozilla/bedrock/pull/11381nucleus
https://github.com/mozilla/nucleus/pull/625basket
https://github.com/mozmeao/basket/pull/820