Consolidate Fastly rules for Phabricator
Categories
(Conduit :: Infrastructure, task)
Tracking
(Not tracked)
People
(Reporter: shtrom, Unassigned)
References
Details
We are seeing waves of requests to Phabricator, and particularly the /source endpoints. We have per-IP rate limits, but they don't stand up well against distributed requests.
- We should investigate the possibility of adding global limits (or maybe per-netblock/asn/...), rather than just per-IP.
- Could be based on observed increase of latency from Phabricator?
- We should put a single set of limits in front of all Phabricator environments.
|
Reporter | |
Updated•7 days ago
|
|
|
Reporter | |
Updated•7 days ago
|
|
|
Reporter | |
Comment 1•2 days ago
|
||
It doesn't look like we can factor response latency in the conditions for rules to fire https://quic.fastly.com/documentation/guides/next-gen-waf/using-ngwaf/rules/defining-rule-conditions/.
Perhaps we should instead cap the global requests limits to the view-source based on a wide aggregate than IP address.
We could use the DATACENTER signal https://quic.fastly.com/documentation/guides/next-gen-waf/using-ngwaf/signals/using-system-signals/#:~:text=Datacenter%20Traffic%20is%20non%2Dorganic%20traffic%20originating%20from%20identified%20hosting%20providers%2E%20This%20type%20of%20traffic%20is%20not%20commonly%20associated%20with%20a%20real%20end%20user
Description
•