WAF (Web Application Firewall) का उपयोग न करें

• WAF के उपयोग के खिलाफ ज़्यादा लोग नहीं बोलते, इसलिए यह लेख लिखा गया है। WAF के बारे में ज़्यादातर search results खुद WAF vendors ने लिखे हैं
• WAF इंटरनेट के शुरुआती दौर में बनाए गए थे, और वे हर HTTP request को intercept करके सैकड़ों regular expressions evaluate करते हैं ताकि SQL, shellcode आदि जैसे अनुरोधों को block किया जा सके
• साइबर सुरक्षा के शुरुआती समय में WAF एक अच्छा विचार लग सकता था, लेकिन आज WAF ऐसे नहीं हैं
• WAF की performance problems, bypass किए जाने की संभावना, attack vector के रूप में उनका जोखिम, और high false positive rate जैसी वजहों से अब इससे बेहतर security technologies मौजूद हैं

WAF की performance बेहद खराब है

• WAF हर request पर सैकड़ों regular expressions चलाते हैं, जिससे performance degradation होता है
• WAF इस्तेमाल करने पर काफी अतिरिक्त RAM चाहिए होती है, और average upload time, request processing speed, CPU usage बढ़ जाते हैं, साथ ही गलत block भी होते हैं

WAF को आसानी से bypass किया जा सकता है

• WAF और attackers के बीच लगातार चलने वाली प्रतिस्पर्धा में attackers का पलड़ा भारी रहता है
• जटिल syntax और encoding techniques का उपयोग करके WAF rules को bypass करना संभव है
• उदाहरण के लिए, Log4shell attack को साधारण string check से block नहीं किया जा सकता, और attacker कई तरह की bypass techniques का उपयोग कर सकता है (Log4J Lookup)
• इसके अलावा, अगर attack string में लगभग 8KB बेकार लेकिन harmless characters भर दिए जाएँ, तो WAF उसे RAM में लगातार buffer नहीं कर पाता और cutoff हो जाता है, इसलिए बेकार हो जाता है

WAF खुद एक attack vector है

• 2019 में CapitalOne में WAF configuration error के कारण 10 करोड़ credit applications लीक होने की घटना हुई थी
  • बताया गया कि attacker ने WAF को धोखा देकर EC2 metadata service को request भेजी और S3 से sensitive files पढ़ने के लिए credentials हासिल कर लिए
• यानी WAF की गलत configuration के कारण security incident हो सकता है
• ज़्यादातर WAF जटिल होते हैं और अक्सर closed source में लिखे जाते हैं, जिससे attack surface बढ़ता है
  • महंगे "enterprise" products होने के कारण कंपनियाँ उन्हें competitors से अधिक आकर्षक दिखाने के लिए उनमें अनावश्यक features भर देती हैं
• security products पर बुनियादी security principles को अक्सर नज़रअंदाज़ किया जाता है

WAF में false positives की दर बहुत अधिक है

• पिछले 20 वर्षों में open source WAF rule sets आधुनिक प्रकार के attacks को detect करने के लिए काफी बढ़ाए गए हैं। संभव है कि proprietary WAF भी यही कर रहे हों
• इसका मतलब है कि WAF चलाते समय requests को block कर देने वाले strings की संख्या लगातार बढ़ रही है
• हर नए rule के साथ WAF rules के विस्तार से false positives भी बढ़ते हैं
• "next-generation" WAF दावा करते हैं कि वे कई requests की जाँच करके या IP reputation systems का उपयोग करके इस समस्या को हल करते हैं
  • वे false positive rates को कम कर सकते हैं, लेकिन false positive की समस्या को पूरी तरह खत्म नहीं कर सकते
• false positives की वजह से users और support teams के पास स्पष्ट resolution procedure नहीं रह सकता

WAF के विकल्प

• Isolation: ऐसी तकनीक जिससे सिस्टम का एक हिस्सा compromise हो जाने पर भी दूसरे हिस्सों पर असर न पड़े
  • browser यह काम एक विशेष sandboxed process के अंदर सारा code चलाकर करता है, जहाँ cookies, saved passwords, या दूसरे tabs तक मनमाना access नहीं होता
  • microservices को isolation ध्यान में रखकर design किया गया था, लेकिन अलग-अलग libraries और languages का उपयोग करके monolith के रूप में भी यही किया जा सकता है
• Immutability: read-only file system, reboot-required package managers, और append-only backups के ज़रिए attacks की कुछ श्रेणियों को खत्म करना
• Static Analysis: SQL injection रोकने के लिए prepared statements का उपयोग और CI pipeline में static analysis के ज़रिए code की जाँच
• Capability-based Security: हर API endpoint को database और file system पर unlimited access की ज़रूरत नहीं होती; इसके बजाय केवल आवश्यक permissions दी जानी चाहिए

[roxie]

:+1:

[devpain]

अगर nginx + naxsi का संयोजन हो, तो ऊपर बताई गई कुछ बातों में से कोई भी लागू नहीं होगी, ऐसा लगता है.
WAF ruleset को इस तरह संभालना चाहिए कि service developer खुद इसे मैनेज करे.
Security expert, service की समझ के बिना सामान्य settings लागू कर देते हैं, जिससे false positive rate बहुत बढ़ जाता है, और फिर requests के अनुसार ruleset को एक-एक करके हटाते-हटाते WAF अपनी मूल functionality खो देता है.

[nosookja]

bypass या false positive वाले हिस्सों पर मैं कुछ हद तक सहमत हूं, लेकिन कुल मिलाकर ऐसा काफी लगता है कि पक्की जानकारी नहीं होने के बावजूद बातों को मानो तथ्य की तरह गिना दिया गया है। समय मिला तो मूल लेख भी देखना पड़ेगा। खासकर CapitalOne के मामले को WAF की समस्या बताना यह दिखाता है कि मूल लेख के लेखक की WAF को लेकर समझ काफी कम है। WAF कोई ऐसा solution नहीं है जो vulnerability को जड़ से mitigation कर दे। कोड में पैदा हुई vulnerability का सही समाधान तो कोड में ही किया जाना चाहिए। लेकिन हकीकत अक्सर ऐसी नहीं होती, इसलिए संदिग्ध या malicious input को front layer पर जांचने के लिए किसी उपयुक्त चीज़ की ज़रूरत होती है। अगर इसे सही तरीके से operate किया जाए तो यह सच में बहुत अच्छा चाकू बन सकता है, और अगर ठीक से operate न किया जाए तो वही चाकू आपको घायल भी कर सकता है। टूल की दोधारी प्रकृति हमेशा रहती है, लेकिन यह विषय मुझे ऐसा लगता है कि इसमें सिर्फ बहुत बुरे पहलुओं को ही ज़्यादा उभारा गया है।

[xguru]

Hacker News की टिप्पणियों में इस पर अलग-अलग राय और प्रतिवाद हैं। उन्हें भी साथ में देखें https://news.ycombinator.com/item?id=38255004