Feature #16135
Consider filtering abusive requests to Weblate upstream
100%
Description
I see that Weblate gets tons of requests, presumably from security scanners, to random URLs that match the \.php\?
regexp. There’s no PHP on this system and I don’t see ourselves adding .php
files to translate in Weblate any time soon. It looks like the Weblate Python process spends lots of CPU time figuring out it should reply 404 to these requests. So I would suggest we short-circuit the handling of these requests, by configuring the upstream reverse proxy (nginx on www.lizard) to reject them with some kind of error, before they hit Apache or the WSGI Python process.
Of course, mod_security
could do this and much more, but it requires quite some more work to set up and fine tune, so IMO we should not block on that if there’s a simple 3 lines solution that already fixes a great part of the problem. Happy to help on the nginx side if needed.
Subtasks
History
#1 Updated by Anonymous 2019-02-07 15:13:22
- Parent task changed from
Feature #10034toBug #16436
#2 Updated by groente 2019-04-16 13:09:24
- Status changed from Confirmed to Resolved
- % Done changed from 0 to 100
everything .php now gets a 403
#3 Updated by intrigeri 2019-06-27 17:17:03
- Assignee deleted (
groente)