Ask HN: क्या Cloudflare HN टिप्पणियाँ ब्लॉक करता है अगर आपकी reply में code blocks हों?

Cloudflare का web application firewall कुछ Hacker News टिप्पणियों को ब्लॉक कर रहा है जिनमें code snippets, जैसे `nc` commands या directory traversal strings, मौजूद हैं, और उन्हें संभावित attacks मान रहा है। टिप्पणीकार इस घटना का उपयोग यह दिखाने के लिए करते हैं कि pattern-based WAF rules कैसे बार-बार false positives पैदा कर सकते हैं, तकनीकी साइटों पर legitimate functionality तोड़ सकते हैं, और संगठनों को “security theater” की ओर धकेल सकते हैं जो dashboards पर अच्छा दिखता है लेकिन users को परेशान करता है। चर्चा Cloudflare की TLS-terminating proxy भूमिका पर चिंताओं को भी उठाती है, जो plaintext traffic देख सकती है, जबकि DDoS protection और performance के लिए इसके लाभों को भी तौलती है।

Cloudflare WAF HN टिप्पणियों को ब्लॉक कर रहा है

  • कई उपयोगकर्ता पुष्टि करते हैं कि टिप्पणियों में कुछ code patterns Cloudflare के WAF को ट्रिगर करते हैं और “banned” पेज लौटाते हैं।
  • उदाहरणों में शामिल हैं:
    • nc के तुरंत बाद एक IPv4 address।
    • ../etc/passwd जैसे directory traversal strings (बिना spaces के)।
  • छोटे बदलाव (अतिरिक्त whitespace, line breaks, अलग separators) अक्सर filter को bypass कर देते हैं, जो crude pattern matching को दिखाता है।

Configuration, responsibility, और workarounds

  • रिपोर्ट के अनुसार Cloudflare के stricter WAF rules paid plans का हिस्सा हैं और individually toggle किए जा सकते हैं; वे सभी by default चालू नहीं होते।
  • कुछ लोगों का तर्क है कि HN WAF को बस disable कर सकता है या rules को tune कर सकता है, खासकर ऐसी साइट के लिए जिसकी core content में shell/SQL snippets शामिल हैं।
  • अन्य लोग तेज़ fixes के लिए HN moderators को email करने का सुझाव देते हैं; public posts अन्य प्रभावित users की मदद करते हैं।
  • आज़माए गए workarounds में शामिल हैं:
    • nc और IPs के आसपास whitespace या line breaks बदलना।
    • कुछ substrings से बचना।
    • content को Base64-encode करना प्रस्तावित है, लेकिन इसे WAF के उद्देश्य को विफल करने वाला कहा गया है।

Cloudflare, TLS, और privacy

  • कई टिप्पणियाँ स्पष्ट करती हैं कि Cloudflare TLS terminate करता है, traffic को decrypt करता है, inspect/modify करता है, और फिर उसे आगे भेजता है (वैकल्पिक रूप से re-encrypted)।
  • इसलिए Cloudflare proxied sites के लिए सभी cleartext traffic देख सकता है, ठीक अन्य CDN/WAF providers की तरह।
  • इसे detect करने के तरीके DNS records, certificate details, या /cdn-cgi/trace को hit करना शामिल हैं।
  • इस बात पर बहस होती है कि क्या users “freely choose” इस MITM setup को, और Cloudflare की मौजूदगी कितनी स्पष्ट होती है, इस पर असहमति है।

WAFs का मूल्य और नुकसान

  • कड़ी आलोचना: WAFs को regex-based, high–false-positive “security theater” कहा गया है जो legitimate traffic (खासकर arbitrary text, zips, code examples) को तोड़ देता है और latency व complexity जोड़ता है।
  • उदाहरणों में blocked e-commerce actions, login loops, और broken URLs/products शामिल हैं।
  • समर्थकों का तर्क है कि WAFs:
    • zero-days और बड़े पैमाने के, असंगत attacks (script kiddies, botnets) को जल्दी कम करने में मदद करते हैं।
    • organizational और compliance भूमिकाएँ निभाते हैं।
  • सहमति यह है: WAFs तब उपयोगी हो सकते हैं जब वे narrowly targeted, monitored, और tuned हों; HN जैसी text-heavy sites पर broad generic rules को अनुपयुक्त माना गया है।

HN infrastructure और Cloudflare usage

  • DNS, certificates, और /cdn-cgi/trace पुष्टि करते हैं कि HN अभी Cloudflare के पीछे है।
  • टिप्पणियाँ सुझाव देती हैं कि यह संभवतः DDoS attacks के जवाब में है, जहाँ एक single-core HN application server को front किया जा रहा है।
  • कुछ users ने logged in होने पर slowdowns की रिपोर्ट की है, हालांकि attribution HN और Cloudflare के बीच अनिश्चित है।