Project

General

Profile

Feature #16135

Feature #10034: Translation web platform

Bug #16436: Make the setup production-ready, adjust resource allocation and optimize stuff if needed

Consider filtering abusive requests to Weblate upstream

Added by intrigeri about 1 year ago. Updated 6 months ago.

Status:
Resolved
Priority:
Low
Assignee:
-
Category:
Infrastructure
Target version:
-
Start date:
11/18/2018
Due date:
% Done:

100%

Spent time:
Feature Branch:
Type of work:
Sysadmin
Blueprint:
Starter:
Affected tool:
Translation Platform

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.

History

#1 Updated by u 10 months ago

  • Parent task changed from #10034 to #16436

#2 Updated by groente 8 months ago

  • Status changed from Confirmed to Resolved
  • % Done changed from 0 to 100

everything .php now gets a 403

#3 Updated by intrigeri 6 months ago

  • Assignee deleted (groente)

Also available in: Atom PDF