5 ms·

and if I am not a paying customer, can I enable them manually?

by mkoryak 12y ago

jgrahamc 12y ago
No, the WAF is not included in the free plan.
- TeMPOraL 12y ago
  Out of curiosity, have you considered enabling it temporarily for everyone with Shellshock rules enabled? Just a day or two, to give people time to fix this. Is it feasible with your infrastructure/the way WAF works (I never used one)? It could do a lot of good for people and be a great PR move at the same time.
  - jgrahamc 12y ago
    I'm going to bring it up internally, but don't hold your breath.
    - TeMPOraL 12y ago
      Thanks! EDIT after OP's edit. Sad. This situation feels kind of a disaster-relief thing; not a good time to think about monetizing it. Still, I do understand you don't want people thinking you'll always be protecting them from everything even if they don't pay. EDIT2 after clarification downthread, previous edit is to be disregarded.
      - jgrahamc 12y ago
        It's less about trying to monetize it than about the cost to us of suddenly inspecting every request that goes through us. We service a huge volume of traffic and part of our core value is performance so keeping our processing latency is low as possible is important. (Note: I removed sentence about CloudFlare pricing from previous comment to avoid any confusion about monetization)
        sillysaurus3 12y ago
        Would it be possible to enable it temporarily to see whether the change significantly impacts your processing latency?
        nostrademons 12y ago
        Or do so on a small percentage of free traffic and see how much CPU headroom you still have left.
        TeMPOraL 12y ago
        Fair enough; that's what I meant when asking if it is feasible for you to do so. Thank you for clarification!
      - gtirloni 12y ago
        The monetization has not been put in place right now. It has always been there (the possibility to add these rules). If this is a disaster-relief thing-y, CloudFlare should then be eligible to receive government money later. I doubt that would be even considered by any parties.
    - ChuckMcM 12y ago
      Consider that the bug can be used as an amplification attack and you have a lot of webservers behind the free plan. I'm guessing you don't want to have Cloudflare's infrastructure be the IPs that everyone is blocking because some yoyo is using this to turn those machines into DDOS slaves. Might help your case internally.
    - jgrahamc 12y ago
      Follow up: we enabled basic Shellshock protection for everyone. https://blog.cloudflare.com/shellshock-protection-enabled-for-all-customers/ https://blog.cloudflare.com/shellshock-protection-enabled-fo...
- AznHisoka 12y ago
  As a paying customer, I'd like to say thanks. Too many companies give too much away for free, leaving no incentive to upgrade.
- mmcclellan 12y ago
  Still, publishing suggested rulesets or at least sending them over to OWASP would be Good Guy.
  - jgrahamc 12y ago
    The RedHat advisory had mod_security rules in it. Our rules are our version of that. https://access.redhat.com/articles/1200223 https://access.redhat.com/articles/1200223 SecRule REQUEST_HEADERS: "^\(\) {" "phase:1,deny,id:1000000,t:urlDecode,status:400,log,msg:'CVE-2014-6271 - Bash Attack'" SecRule REQUEST_LINE "\(\) {" "phase:1,deny,id:1000001,status:400,log,msg:'CVE-2014-6271 - Bash Attack'" SecRule ARGS_NAMES "^\(\) {" "phase:2,deny,id:1000002,t:urlDecode,t:urlDecodeUni,status:400,log,msg:'CVE-2014-6271 - Bash Attack'" SecRule ARGS "^\(\) {" "phase:2,deny,id:1000003,t:urlDecode,t:urlDecodeUni,status:400,log,msg:'CVE-2014-6271 - Bash Attack'" SecRule FILES_NAMES "^\(\) {" "phase:2,deny,id:1000004,t:urlDecode,t:urlDecodeUni,status:400,log,msg:'CVE-2014-6271 - Bash Attack'"

and if I am not a paying customer, can I enable them manually?

by mkoryak 12y ago

and if I am not a paying customer, can I enable them manually?

jgrahamc 12y ago

No, the WAF is not included in the free plan.

TeMPOraL 12y ago
Out of curiosity, have you considered enabling it temporarily for everyone with Shellshock rules enabled? Just a day or two, to give people time to fix this. Is it feasible with your infrastructure/the way WAF works (I never used one)? It could do a lot of good for people and be a great PR move at the same time.
- jgrahamc 12y ago
  I'm going to bring it up internally, but don't hold your breath.
  - TeMPOraL 12y ago
    Thanks! EDIT after OP's edit. Sad. This situation feels kind of a disaster-relief thing; not a good time to think about monetizing it. Still, I do understand you don't want people thinking you'll always be protecting them from everything even if they don't pay. EDIT2 after clarification downthread, previous edit is to be disregarded.
    - jgrahamc 12y ago
      It's less about trying to monetize it than about the cost to us of suddenly inspecting every request that goes through us. We service a huge volume of traffic and part of our core value is performance so keeping our processing latency is low as possible is important. (Note: I removed sentence about CloudFlare pricing from previous comment to avoid any confusion about monetization)
      - sillysaurus3 12y ago
        Would it be possible to enable it temporarily to see whether the change significantly impacts your processing latency?
        nostrademons 12y ago
        Or do so on a small percentage of free traffic and see how much CPU headroom you still have left.
      - TeMPOraL 12y ago
        Fair enough; that's what I meant when asking if it is feasible for you to do so. Thank you for clarification!
    - gtirloni 12y ago
      The monetization has not been put in place right now. It has always been there (the possibility to add these rules). If this is a disaster-relief thing-y, CloudFlare should then be eligible to receive government money later. I doubt that would be even considered by any parties.
  - ChuckMcM 12y ago
    Consider that the bug can be used as an amplification attack and you have a lot of webservers behind the free plan. I'm guessing you don't want to have Cloudflare's infrastructure be the IPs that everyone is blocking because some yoyo is using this to turn those machines into DDOS slaves. Might help your case internally.
  - jgrahamc 12y ago
    Follow up: we enabled basic Shellshock protection for everyone. https://blog.cloudflare.com/shellshock-protection-enabled-for-all-customers/ https://blog.cloudflare.com/shellshock-protection-enabled-fo...
AznHisoka 12y ago
As a paying customer, I'd like to say thanks. Too many companies give too much away for free, leaving no incentive to upgrade.
mmcclellan 12y ago
Still, publishing suggested rulesets or at least sending them over to OWASP would be Good Guy.
- jgrahamc 12y ago
  The RedHat advisory had mod_security rules in it. Our rules are our version of that. https://access.redhat.com/articles/1200223 https://access.redhat.com/articles/1200223 SecRule REQUEST_HEADERS: "^\(\) {" "phase:1,deny,id:1000000,t:urlDecode,status:400,log,msg:'CVE-2014-6271 - Bash Attack'" SecRule REQUEST_LINE "\(\) {" "phase:1,deny,id:1000001,status:400,log,msg:'CVE-2014-6271 - Bash Attack'" SecRule ARGS_NAMES "^\(\) {" "phase:2,deny,id:1000002,t:urlDecode,t:urlDecodeUni,status:400,log,msg:'CVE-2014-6271 - Bash Attack'" SecRule ARGS "^\(\) {" "phase:2,deny,id:1000003,t:urlDecode,t:urlDecodeUni,status:400,log,msg:'CVE-2014-6271 - Bash Attack'" SecRule FILES_NAMES "^\(\) {" "phase:2,deny,id:1000004,t:urlDecode,t:urlDecodeUni,status:400,log,msg:'CVE-2014-6271 - Bash Attack'"