CrowdStrike ने कुछ महीने पहले Debian और Rocky Linux को भी प्रभावित किया था

 (neowin.net)
1 पॉइंट द्वारा GN⁺ 2024-07-22 | 3 टिप्पणियां | WhatsApp पर शेयर करें
  • Windows की बड़े पैमाने की BSOD समस्या से अलग, CrowdStrike अपडेट ने पहले ही Debian और Rocky Linux वातावरणों में भी सर्वर ठप होने की घटनाएँ पैदा की थीं
  • अप्रैल में एक civic tech lab में अपडेट के तुरंत बाद सभी Debian Linux सर्वर एक साथ क्रैश हो गए और बूट होने से इनकार कर दिया, तथा CrowdStrike हटाने के बाद ही रिकवरी संभव हुई
  • संबंधित Debian कॉन्फ़िगरेशन को समर्थित माना जाता था, लेकिन वह नवीनतम स्थिर Debian संस्करण के साथ संगत नहीं था, और root cause analysis में test matrix omission की पुष्टि हुई
  • Rocky Linux उपयोगकर्ताओं ने भी बताया कि RockyLinux 9.4 अपग्रेड के बाद CrowdStrike चलाने वाले सर्वर kernel bug के कारण क्रैश हो रहे थे, और CrowdStrike सपोर्ट टीम ने भी समस्या को स्वीकार किया
  • CrowdStrike पर निर्भर संगठनों को अपडेट लागू करने में अधिक सावधानी बरतनी चाहिए और आउटेज से निपटने के लिए emergency plan तैयार रखना चाहिए

Windows आउटेज से पहले Linux ठप होने की घटनाएँ

  • Windows PC पर हुई व्यापक Blue Screen of Death समस्या ने एयरलाइंस, बैंकों, healthcare providers सहित कई क्षेत्रों के संचालन में बाधा डाली
    • इसका कारण CrowdStrike द्वारा अपडेट के जरिए भेजी गई समस्या वाली channel file थी
    • CrowdStrike ने पुष्टि की कि इस क्रैश का असर Mac या Linux PC पर नहीं पड़ा
  • लेकिन Debian और Rocky Linux उपयोगकर्ताओं ने भी CrowdStrike अपडेट के कारण गंभीर व्यवधान झेले, जिससे update और testing procedures को लेकर चिंता बढ़ी
    • यह उन ग्राहकों के लिए संभावित जोखिम हो सकता है जो रोज़ CrowdStrike प्रोडक्ट्स पर निर्भर रहते हैं

Debian और Rocky Linux में सामने आई समस्याएँ

  • Debian सर्वरों का एक साथ क्रैश होना

    • अप्रैल में एक civic tech lab में CrowdStrike अपडेट ने सभी Debian Linux सर्वर एक साथ क्रैश कर दिए और उन्हें बूट होने से रोक दिया
    • वह अपडेट नवीनतम स्थिर Debian संस्करण के साथ संगत नहीं था, जबकि उस Linux कॉन्फ़िगरेशन को समर्थित माना जाता था
    • IT टीम ने पाया कि CrowdStrike हटाने पर मशीनें बूट हो जाती हैं और इसके बाद घटना की रिपोर्ट की

  • प्रतिक्रिया में देरी और testing की कमी

    • घटना से जुड़े एक टीम सदस्य ने CrowdStrike की देरी से प्रतिक्रिया पर नाराज़गी जताई
    • CrowdStrike ने एक दिन बाद समस्या स्वीकार की, लेकिन root cause analysis देने में कई हफ्ते लगे
    • विश्लेषण में पता चला कि Debian Linux कॉन्फ़िगरेशन CrowdStrike की test matrix में शामिल ही नहीं था
    • टीम सदस्य ने आलोचना करते हुए कहा, “Crowdstrike का मॉडल ऐसा लगता है कि चाहे मामला urgent हो या नहीं, और testing हुई हो या नहीं, वे जब चाहें आपकी मशीनों पर software push कर देते हैं”

  • Rocky Linux 9.4 अपग्रेड के बाद क्रैश

    • Rocky Linux उपयोगकर्ताओं ने बताया कि RockyLinux 9.4 अपग्रेड के बाद CrowdStrike चलाने वाले सर्वर kernel bug के कारण क्रैश हो रहे थे
    • CrowdStrike सपोर्ट टीम ने इस समस्या को स्वीकार किया
    • अलग-अलग operating systems में बार-बार सामने आई compatibility समस्याएँ testing की कमी और पर्याप्त सावधानी न बरतने के पैटर्न को दिखाती हैं

संगठनों को क्या तैयारी करनी चाहिए

  • भविष्य में ऐसी समस्याएँ कम करने के लिए CrowdStrike को सभी समर्थित कॉन्फ़िगरेशनों पर अधिक सख्त testing को प्राथमिकता देनी चाहिए
  • संगठनों को CrowdStrike अपडेट सावधानी से लागू करने चाहिए और संभावित व्यवधान को कम करने के लिए emergency plan तैयार रखना चाहिए
  • संबंधित स्रोत

संबंधित पढ़ाई

3 टिप्पणियां

 
click 2024-07-22

लगता है AI ने मुख्य लेख नहीं, बल्कि विज्ञापन का सारांश बना दिया।
 
xguru 2024-07-22

Neowin साइट की HTML संरचना अजीब है, इसलिए ऊपर की बार के सभी विज्ञापन मुख्य लेख के हिस्से के रूप में पहचाने जा रहे थे। मैंने इसे ठीक कर दिया है.
 
GN⁺ 2024-07-22
Hacker News की राय

  • OSS/Linux ecosystem में स्वतंत्र और ढीले तौर पर coordinated groups द्वारा मुफ्त में जोड़े गए code के ढेर बहुत हैं, फिर भी यह अक्सर अरबों डॉलर वाली कंपनियों के बनाए software से ज्यादा मजबूत होता है—यह बात हैरान करती है
    इसकी एक वजह यह हो सकती है कि OSS system programmers अपनी गंदी धुलाई सार्वजनिक रूप से करते हैं। यह “ज्यादा आंखें हों तो bugs उथले हो जाते हैं” से ज्यादा “कोई देख ही ले तो खराब code शर्मिंदगी बन जाता है” जैसा है
    मैं एक commercial project को open source के रूप में public करने की कोशिश कर रहा हूं, और source code खोलने से पहले documentation सुधारने, TODO/FIXME साफ करने, comments verify करने जैसे काफी काम करने पड़ रहे हैं। लेकिन बंद commercial codebase के अंदर मैंने इससे कहीं बदतर चीजें खूब देखी हैं, और लगता है कि ज्यादातर enterprise software भी इसी स्तर का होगा

    • OSS software में profit motive बहुत कम होता है, इसलिए इसे कुछ “बेचने” के बजाय “चलाने” के लिए लिखा जाता है
      समय का दबाव भी कम होता है, इसलिए release टल भी जाए तो quarterly results पर असर नहीं पड़ता। मुझे commercial software engineering work से ज्यादा marketing work जैसा लगता है
    • Linus शायद इससे सहमत नहीं होंगे, और kernel हमेशा इतनी बड़ी दीवारें खड़ी रखता है, इसकी वजह है। वे user-space code के ज्यादातर हिस्से को जायज तौर पर reject कर देंगे
      kernel के बाहर की चीजों का चल जाना अपने आप में चमत्कार है, और distribution updates के दौरान वे कितनी बार टूटती हैं, उन्हें फिर से चलाने के लिए पूरे को दुबारा build करना कितनी बार पड़ता है—यह सब दिखाता है। Production में update करना बेहद stress वाला process है
      Audio और video की बात अभी शुरू भी नहीं की, और उसके ऊपर Wayland जोड़ दें तो वह अलग ही nightmare है। इसलिए कई मायनों में Windows standard के करीब लगता है। वह हर तरफ से कठोर व्यवहार झेलते हुए भी असंख्य machines पर हर दिन महत्वपूर्ण काम करता है
      पैसा मिल रहा है या नहीं, यह महत्वपूर्ण नहीं है; Raymond Chen आदि के लेखों में दिखने वाली decision-making की गहराई OSS दुनिया में भी बहुत दुर्लभ है
    • पैसे लेकर बनाए गए, लेकिन जहां अंतिम फैसले MBA लेते हैं, ऐसी चीजें hobby या passion projects की तुलना में अक्सर बेहद खराब होती हैं
      मुझे नहीं लगता कि यह सिर्फ मेरे साथ है, और उम्मीद है कि उपयोगी चीजें और अपने नियंत्रण में रहने वाले tools बनाने की इच्छा से बनी communities बनी रहेंगी
    • Deadlines भी शायद बड़ा factor हैं। कई OSS developers अपने खाली समय में अपने और दूसरों के लिए projects बनाते हैं, और passion project हो तो व्यक्ति अपने काम पर ज्यादा गर्व कर सकता है
      Commercial software अक्सर manager की deadline पूरी करने के लिए duct tape से जोड़ा हुआ लगता है, जिससे “क्या फर्क पड़ता है” वाला रवैया आ जाता है और बस खत्म कर देने पर संतोष हो जाता है
    • Code लिखने वालों को amateurs कहना अच्छा वर्णन नहीं लगता। उनमें से ज्यादातर अनुभवी और बहुत technical लोग होंगे, और “loosely coordinated” कई कंपनियों पर भी लागू होता है
      Open source में coding करने वाले लोगों के लिए अहम बात यह है कि वे रुचि के कारण करते हैं। अगर आप कुछ अच्छा, अच्छी तरह चलने वाला और clever बनाना चाहते हैं, तो सिर्फ पैसे लेकर करने या शर्मिंदगी से बचने की तुलना में सफल होने की संभावना ज्यादा होती है

  • कल के बड़े CrowdStrike thread से संबंधित comment: “CrowdStrike ने 19 अप्रैल को हमारी production Linux fleet के साथ यही किया था, और तब से मैं लगातार rant करना चाहता था” [1]
    इसके बाद कई paragraphs का rant चलता है
    [1] https://news.ycombinator.com/item?id=41005936

    • कुछ हफ्तों बाद आई root cause analysis में भी हमारा इस्तेमाल किया गया scenario test matrix में नहीं था। जबकि यह Debian stable पर n-1 version चलाने वाली supported configuration जैसा दिखता था
      उनकी अपनी postmortem analysis में भी वही चीज दोबारा होने से रोकने का कोई वास्तविक तरीका नहीं था। क्योंकि structure ही ऐसा था: “आपात स्थिति हो या नहीं, test हो या नहीं, हम जब चाहें आपकी machines पर software push कर देते हैं”
    • यह सिर्फ related comment नहीं, बल्कि लगता है कि इस HN thread को article में मुख्य source के रूप में इस्तेमाल किया गया है

  • इस field में काम करते समय हमेशा यह सवाल साथ रहता था: “क्या ये चीजें सच में useful हैं?”
    जवाब देना कठिन सवाल है, लेकिन जानना चाहता हूं कि CrowdStrike जैसे products की effectiveness verify करने वाली कोई third-party research है या नहीं। या फिर सब लोग security theater के कारण अपनी जिंदगी और खराब बना रहे हैं

    • यह vaccine effectiveness पर research करने जैसा है। फिर भी आप जैसे जवाब पहले ही दे चुके हैं। अगर executives पचा सकें ऐसे metrics बना दिए जाएं, तो उसे valuable माना जाता है
      इतना invasive कुछ जोड़ना कैसे समझ में आता है, यह सवाल है। 90s में antivirus companies viruses भी बनाती थीं, और अपनी बनाई चीजों को networks पर फैलाते हुए subscribers के लिए जादू की तरह infection रोक देती थीं
    • जानना चाहता हूं कि क्या किसी ने इसे सच में कुछ रोकते हुए देखा है। वह tool बनाने वाली company भी जाहिर है अपना product इस्तेमाल करती होगी
      अगर पूरी web से पूछा जाए “किसी ने देखा है?” तो कोई न कोई सामने आ जाएगा, लेकिन ऐसे tools की वजह से security vulnerabilities झेलने वाले लोग बेहद ज्यादा हैं, और stability व availability issues झेलने वाले लोग तो लगभग उतने ही हैं जितने उस tool के users हैं

  • प्रोडक्ट क्वालिटी विमान से लेकर software तक free fall में है। आजकल हर कोई बस अतिरिक्त revenue की चिंता करता है, इसलिए QA की कमी default बन गई है

    • हमारी economy को profit के लिए min-max करने की तरह optimize किया गया है, और लगता है अब उसकी फसल काटने का समय आ गया है
      यूक्रेन भेजने के लिए पर्याप्त artillery shells न बना पाना, chip manufacturing को देश में वापस न ला पाना, और जहाज न बना पाना—कारण वही है
    • गैर-technical लोग decisions ले रहे हैं, और यहां तक कि technical programs develop करने का काम भी बढ़ता जा रहा है—यह भी एक वजह है
      15 साल पहले industry में ज्यादातर लोग सच में वहीं होना चाहते थे, exceptions कम थे। अब यह भी किसी दूसरे profession जैसा हो गया है, जहां ज्यादातर developers को output में खास दिलचस्पी नहीं है, और अंत में result भी खराब निकलता है
      पिछले कुछ सालों में मुझे अपने बेकार code को सच में test करने वाले senior से नीचे के developers शायद ही मिले हों
    • गलती करने की economic cost कमाए जा रहे profit से कम है। जब तक यह नहीं बदलेगा, कुछ भी नहीं बदलेगा
    • यह सिर्फ product quality की समस्या नहीं है
      यह ऐसी व्यवस्था है जहां marketing की बू वाले influencers, जिन्हें खुद नहीं पता कि वे क्या कर रहे हैं, supplier द्वारा पैदा की गई paranoia को compliance checkboxes से ढकने की कोशिश कर रहे लोगों को कचरा बेचते हैं। इन्हें threat modeling नहीं आता, और यह भी नहीं पता कि operating system कैसे काम करता है
      CIA triad के हिसाब से देखें तो availability को पूरी तरह छोड़ दिया गया है, system की हर activity किसी cloud company को भेजकर confidentiality का भी कुछ हिस्सा sacrifice किया गया है, और integrity की झूठी सुरक्षा-भावना हासिल करने की कोशिश की जा रही है, जिसकी guarantee supplier देता भी नहीं। properly layered security architecture में इस product के सच में कुछ करने का evidence मुझे मुश्किल से दिखा है
      यह security proposition का ठीक उलटा है। यह झूठ और अक्षमता पर बना ताश का महल है, और literally malware की definition के करीब है। यह ऐसे data को बाहर भेजता है जिसे आप control नहीं कर सकते, remote command-and-control functionality से systems को गिरा सकता है, और ring 0 में पूरी तरह arbitrary code execute करता है
      मार्च 2023 में मैंने इस पूरी चीज को गंभीर business risk बताया था, लेकिन ऊपर वाले लोगों ने इसे push किया। मैंने विरोधी राय record कर रखी थी और अब उसी से हिसाब बराबर करने का सोच रहा हूं
      लोग खरीद लें तो चीज को कचरा बना देने से फर्क नहीं पड़ता। और असल में यह कचरा ही बना हुआ है
    • दुखद है। हर company अलग होती है, और personally software engineering में यह मेरा सबसे पसंदीदा हिस्सा है, लेकिन कई बड़ी companies मौका मिलते ही QA काट देती हैं

  • ऐसी reports भी थीं कि CrowdStrike ने Windows applications में buggy DLL inject किया, जिससे application की अपनी गलती न होने पर भी crash हो सकता था
    https://x.com/molecularmusing/status/1808756095860543916

    • वह पूरी तरह अलग मामला है। inject होने वाला DLL default रूप से off रहने वाला optional feature है, और admins को deployment से पहले fleet के साथ compatibility verify करने की साफ warning दी जाती है
      लागू किए जा सकने वाले hooks के चार levels हैं, जो आगे बढ़ने पर और unstable होते जाते हैं, और UI व documentation में बार-बार warnings हैं। उदाहरण के लिए XUMD running process में library load करके कई user-mode APIs को hook करता है, जिससे sensor information monitor कर पाता है
      कुछ endpoint telemetry सिर्फ user-mode hooks से ही collect की जा सकती है। XUMD यह जानकारी देता है कि process कौन-से APIs use कर रहा है, और यह जानकारी observed cumulative behavior के आधार पर sensor के कई prevention mechanisms में इस्तेमाल होती है
      AUMD के उलट, cloud sensor update के बिना XUMD visibility को dynamically बदल सकता है। Settings Disabled, Cautious, Moderate, Aggressive, Extra Aggressive हैं, और आगे की settings में performance या application compatibility issues बढ़ते जाते हैं, इसलिए production के लिए recommended नहीं हैं
      XUMD उन user processes में load होता है जिनके साथ इसे मूल रूप से develop नहीं किया गया था, इसलिए खासकर ऐसे environments में जहां दूसरे security products installed हों, crashes, startup failures या performance degradation हो सकती है। कौन-सी process ने XUMD DLL load किया है यह देखने के लिए command line में tasklist /m csxumd* चलाएं

  • यह सब इसलिए होता है क्योंकि companies contract के जरिए consequential damages liability से बच सकती हैं
    जैसे जान गंवाने पर consequential liability को contract से exclude नहीं किया जा सकता, वैसे ही ऐसे clauses को भी unenforceable बनाना चाहिए या कम से कम limit करना चाहिए

    • क्या वही Europe की cybersecurity directive करने की कोशिश नहीं कर रही थी? वही directive जिस पर सब नाराज हुए और फिर FOSS exception आया था

  • “update Debian के latest stable version के साथ compatible नहीं था, लेकिन वह Linux configuration supported बताई गई थी” और “analysis में पाया गया कि Debian Linux configuration test matrix में नहीं था” वाली बातें असल fraud के काफी करीब लगती हैं
    यानी configuration X को support करने की घोषणा करके असल में configuration X को बिल्कुल test न करना। यह वैसा ही है जैसे car में seatbelt होने का दावा करना, लेकिन manufacturing process में कहीं भी यह check न करना कि seatbelt install हुई है और काम करती है या नहीं
    अगर कोई car company ऐसा करती तो शायद prosecution होता, फिर CrowdStrike के साथ ऐसा क्यों नहीं, समझ नहीं आता। किसी Linux version को support न करना समझ में आ सकता है, लेकिन support advertise करके test तक न करना कम से कम willful negligence है, और शायद खुला fraud भी

  • “किसी ने notice नहीं किया” कहना ऐसा cute expression लगता है जैसे CrowdStrike ने press को notice न करने के लिए दबा दिया हो। bug वाले दिन HN post में comments थे कि लोग महीनों पहले से problem report करने की कोशिश कर रहे थे
    article भी ऐसा लिखता है जैसे लोगों ने problem notice की थी। तो फिर किसने notice नहीं किया? या वे problems इतनी famous नहीं थीं कि उन्हें ignore न किया जाए?

    • क्या आपका मतलब है कि CrowdStrike ने media coverage suppress किया? सोच रहा हूं क्या आपको लगता है कि उन्होंने NY Times, WaPo और बड़े broadcasters को cheques भेजे होंगे
      media को कुछ servers मर जाने में interest नहीं होता, जब तक वह aircraft operations रुकने जैसी real world में दिखने वाली चीज न हो
    • मुझे याद है कि उस समय कुछ देखा था, लेकिन मैंने सोचा था कि Linux पर ऐसा software install करने वाले लोग बहुत कम होंगे। असल में ऐसी companies भी बहुत कम हैं
      blast radius छोटा था, और शायद खराब Nvidia driver से भी छोटा रहा होगा

  • अगर यहां कोई CrowdStrike इस्तेमाल करता है, तो जानना चाहूंगा कि यह असल में करता क्या है। इसे “एंटीवायरस” कहा जाता है, लेकिन ऑफिस के लैपटॉप पर इंस्टॉल देखकर यह कीलॉगर और गतिविधि मॉनिटर जैसा लगता है
    लोग कहते हैं “छिपाने को कुछ नहीं है,” लेकिन कंपनी के super users का मुझे मॉनिटर करना फिर भी खटकता है

    • सुरक्षा, compliance और legal टीमों की मंजूरी की मुहर दिलवा देता है
    • एंटीवायरस/EDR solutions को malware या spyware कहने से बेहतर हल है। ऑफिस के डिवाइस को निजी काम के लिए इस्तेमाल न करें
      वह डिवाइस कंपनी की संपत्ति है, और कंपनी के environment तक पहुंचने के लिए इस्तेमाल होता है, इसलिए अगर उसमें असली malware आ जाए तो नुकसान पहुंचा सकने वाला जिम्मेदारी का बिंदु है। निजता चाहिए तो अलग डिवाइस इस्तेमाल करना ही सही है

  • कुछ कंपनियों में कहा जाता है कि सभी endpoints पर CrowdStrike deploy है, लेकिन किसी ने बताया कि वह इसे resources सीमित की हुई virtual machine के अंदर ही चलाता रहा और किसी ने कुछ नहीं कहा। उसने यह भी कहा कि उसी समय के आसपास virtual machines fail होती देखी थीं
    एक दूसरी बड़ी कंपनी के पूर्व सहकर्मी से यह भी सुना कि IT ने Linux endpoints पर compliance enforce करना बस छोड़ दिया था। कुछ IT admins शायद असल में “न पूछो, न बताओ” नीति अपनाते हैं
    अपना वैकल्पिक stack खुद सही से configure कर लो, और हंगामा मत खड़ा करो या झूठ मत बोलो, तो अपनी मर्जी से करो—कुछ ऐसा रवैया। अगर enforcement की वजह ज्यादातर checkbox compliance है तो यह काफी समझ में आता है
    सोचता हूं कि इस तरह की malicious compliance कितनी व्यापक है, और अप्रैल वाली घटना के बड़ी खबर न बनने में इसका कितना योगदान रहा