5 ms·

One more question. Whats to stop this being used for amplification DDOS? Register a stolen CC then launch x100 parrell http(s) subrequest for each incoming requ

One more question. Whats to stop this being used for amplification DDOS? Register a stolen CC then launch x100 parrell http(s) subrequest for each incoming request to your intended target, possibly adding large random payload (well as much as you can generate in 50ms minus time to setup 100 subrequests with fetch API)

kentonv 9y ago
If you do that, it won't actually send very much traffic to the victim site, and you'll find your zone suspended pretty quickly. :) As with any anti-abuse measures, though, it's best if we don't describe in detail what steps we've taken to prevent this sort of attack.
- harlanji 9y ago
  I don’t agree that it’s best you don’t describe anti-abuse techniques. I’d be impressed if your manager agrees. I’ll argue points if you like. Can you talk about topology relative to ingress and origin? Eg. is execution pinned in select PoPs per ‘region’ or all? Unrelated, I also wonder about retention of edge cache, is it purged via LRU or similar? Personal note, I was excited to get the early access email, feels like an excellent offering; I’ll be flexing it soon, have some ideas—been getting an HLS system online in the past month using RasPi+CF without a hiccup (720p@4500kbps) and it’s open source/libre, comparable to YT/Twitch—info incl. design/ lectures in profile. Also read above, congrats on what must’ve been a good year! Speaks well of your org that you’ve been able to deliver and talk freely.
  - kentonv 9y ago
    > Can you talk about topology relative to ingress and origin? Eg. is execution pinned in select PoPs per ‘region’ or all? Nope. Every Worker is distributed to every location. Requests are handled at whatever PoP they arrive at. > I also wonder about retention of edge cache, is it purged via LRU or similar? TBH I'm not that familiar with the inner workings of our HTTP cache, but I would assume so?
    - khc 9y ago
      Unless to the cache item expired first, yes
    - harlanji 9y ago
      Great! Thanks
  - jgrahamc 9y ago
    > I’d be impressed if your manager agrees. I am his manager and I agree with him
    - harlanji 9y ago
      I assumed that’d be the case. What’s the average response and resolution time for pro customers? Difference for free customers? How’s your escalation process, if I may ask? (PagerDuty, etc). Can you speak to false positive rates? I break things and run media channels, would instaquit for plan B if there were an issue. (Don’t mess with my paper is the stem of my concern). I’ve designed and built a similar offering at a big B2B company and we spent considerable time coming up with heuristics to plug the gaping holes possible in this kind of system, hence false positive concerns. I’m also a CF partner. Thanks in advance for any insights or pointers.
      - kentonv 9y ago
        I'm probably the better person to answer these questions, since I'm the one who designed the anti-abuse measures in question. If I understand correctly, you're worrying about false positives, i.e. your site accidentally gets shut down because we incorrectly believe you're launching a DDoS. This is not a plausible outcome of the measures we've currently implemented. As a CF partner, you should feel free to arrange a private conversation if you are still concerned.
- forcer 9y ago
  Do CloudFlare Workers require external HTTP endpoints to have CORS headers like Javascript within webpages need?
  - deleted 9y ago
    [deleted]
  - kentonv 9y ago
    No. CORS is designed to protect two things: - The user's cookies for other origins, which the browser will normally send on any request to those origins. - Behind-the-firewall servers that might be accessible from the user's browser but not from the public internet. Neither of these things apply to Workers: a Worker obviously has no access to the browser's cookie jar, nor does it have the ability to see behind-the-firewall services since it's not behind-the-firewall. CORS does NOT protect against DDoS: Typically, CORS does not prevent you from sending requests; it prevents you from seeing the content of the responses. Any web site in a browser can use an <img> tag or submit an invisible <form> to cause a cross-origin request, CORS or not -- but it can't read what comes back. So, Cloudflare Workers do not enforce CORS. We've implemented different measures specifically to mitigate DDoS.

kentonv 9y ago

If you do that, it won't actually send very much traffic to the victim site, and you'll find your zone suspended pretty quickly. :) As with any anti-abuse measures, though, it's best if we don't describe in detail what steps we've taken to prevent this sort of attack.

harlanji 9y ago
I don’t agree that it’s best you don’t describe anti-abuse techniques. I’d be impressed if your manager agrees. I’ll argue points if you like. Can you talk about topology relative to ingress and origin? Eg. is execution pinned in select PoPs per ‘region’ or all? Unrelated, I also wonder about retention of edge cache, is it purged via LRU or similar? Personal note, I was excited to get the early access email, feels like an excellent offering; I’ll be flexing it soon, have some ideas—been getting an HLS system online in the past month using RasPi+CF without a hiccup (720p@4500kbps) and it’s open source/libre, comparable to YT/Twitch—info incl. design/ lectures in profile. Also read above, congrats on what must’ve been a good year! Speaks well of your org that you’ve been able to deliver and talk freely.
- kentonv 9y ago
  > Can you talk about topology relative to ingress and origin? Eg. is execution pinned in select PoPs per ‘region’ or all? Nope. Every Worker is distributed to every location. Requests are handled at whatever PoP they arrive at. > I also wonder about retention of edge cache, is it purged via LRU or similar? TBH I'm not that familiar with the inner workings of our HTTP cache, but I would assume so?
  - khc 9y ago
    Unless to the cache item expired first, yes
  - harlanji 9y ago
    Great! Thanks
- jgrahamc 9y ago
  > I’d be impressed if your manager agrees. I am his manager and I agree with him
  - harlanji 9y ago
    I assumed that’d be the case. What’s the average response and resolution time for pro customers? Difference for free customers? How’s your escalation process, if I may ask? (PagerDuty, etc). Can you speak to false positive rates? I break things and run media channels, would instaquit for plan B if there were an issue. (Don’t mess with my paper is the stem of my concern). I’ve designed and built a similar offering at a big B2B company and we spent considerable time coming up with heuristics to plug the gaping holes possible in this kind of system, hence false positive concerns. I’m also a CF partner. Thanks in advance for any insights or pointers.
    - kentonv 9y ago
      I'm probably the better person to answer these questions, since I'm the one who designed the anti-abuse measures in question. If I understand correctly, you're worrying about false positives, i.e. your site accidentally gets shut down because we incorrectly believe you're launching a DDoS. This is not a plausible outcome of the measures we've currently implemented. As a CF partner, you should feel free to arrange a private conversation if you are still concerned.
forcer 9y ago
Do CloudFlare Workers require external HTTP endpoints to have CORS headers like Javascript within webpages need?
- deleted 9y ago
  [deleted]
- kentonv 9y ago
  No. CORS is designed to protect two things: - The user's cookies for other origins, which the browser will normally send on any request to those origins. - Behind-the-firewall servers that might be accessible from the user's browser but not from the public internet. Neither of these things apply to Workers: a Worker obviously has no access to the browser's cookie jar, nor does it have the ability to see behind-the-firewall services since it's not behind-the-firewall. CORS does NOT protect against DDoS: Typically, CORS does not prevent you from sending requests; it prevents you from seeing the content of the responses. Any web site in a browser can use an <img> tag or submit an invisible <form> to cause a cross-origin request, CORS or not -- but it can't read what comes back. So, Cloudflare Workers do not enforce CORS. We've implemented different measures specifically to mitigate DDoS.