AWS से मेरी ऑन-प्रिमाइसेस सेवाओं के लिए कनेक्शन ब्लॉक करना

 (consulting.m3047.net)
1 पॉइंट द्वारा GN⁺ 2024-09-01 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • सार्वजनिक इंटरनेट बड़े cloud providers के इर्द-गिर्द बने खंडित ecosystem में बंट सकता है, और AWS से ऑन-प्रिमाइसेस एक्सेस ब्लॉक करना उस प्रवृत्ति का एक परिचालन उदाहरण है
  • ब्लॉकिंग का मुख्य लक्ष्य AWS के अंदर के clients द्वारा ऑन-प्रिमाइसेस सेवाओं के लिए किए जाने वाले TCP connection attempts हैं, जबकि लोकल clients का AWS-hosted services की ओर जाना अब भी संभव है
  • चल रही ऑन-प्रिमाइसेस सेवाओं में web, Trualias demo, DNS, और SMTP शामिल हैं; DNS, UDP और TCP fallback के साथ सीमित सार्वजनिक security telemetry access देता है
  • AWS ब्लॉकिंग की शुरुआत अत्यधिक ping traffic और abusive crawler/scanner से निपटने के लिए हुई, और अभी abuse target या source के रूप में देखे गए AWS address space के 53 CIDR प्रबंधित किए जा रहे हैं
  • अगर बड़े cloud providers reverse DNS, whois, DNS namespace, और abuse patterns जैसी forensic information को बेहतर तरीके से सार्वजनिक नहीं करते, तो cloud के अंदर के users के लिए लगभग बिना असुविधा वाला यह खंडन और मजबूत हो सकता है

बड़े cloud द्वारा पैदा की जा रही खंडन की संभावना

  • अगर बड़े cloud providers “too big to fail” bulletproof infrastructure बन जाते हैं, तो वे सीधे इंटरनेट के खंडन का कारण बन सकते हैं
  • यह अभी पूरी तरह वास्तविकता नहीं बना है, लेकिन इसे ऐसी स्थिति माना गया है जो या तो शुरू हो चुकी है या जल्द दिखाई दे सकती है
  • cloud-native ecosystem में वास्तविक इंटरनेट की तुलना में custom infrastructure है, और हर cloud service साझा architecture से अधिक अलग-अलग features के इर्द-गिर्द बनती है
  • कई सेवाएँ किसी खास cloud के भीतर self-contained तरीके से चलती हैं, और सामान्य इंटरनेट के साथ पारदर्शी interoperability में रुकावटें हैं
  • cloud-native community सामान्य इंटरनेट को एक external resource की तरह देखती है, और इंटरनेट से अधिक किसी खास cloud provider ecosystem के साथ interact करती है

सार्वजनिक इंटरनेट के व्यावसायीकरण की दिशा

  • 1989 से पहले इंटरनेट में आम सार्वजनिक access नहीं था, और यह सरकार, सेना, शोध, और शिक्षा संस्थानों द्वारा उपयोग किया जाने वाला एक निजी प्रकृति का नेटवर्क था
  • NSF backbone के core को manage करता था, और शुरुआती सार्वजनिक access non-commercial traffic की शर्त पर अनुमत था
    • commercial services पूरी तरह प्रतिबंधित नहीं थीं, लेकिन NSFNet backbone से गुजरने वाला traffic विज्ञापन या paid service traffic नहीं होना चाहिए था
  • commercial operators ने अलग commercial internet बनाया, और 1995 में NSFNet ने public access बंद कर दिया
  • 2000 के आसपास की बड़ी छंटनी के बाद user behavior data आधारित advertising और user behavior data बेचने वाले models बचे रहे
  • मौजूदा AI प्रवाह में accessible content को बड़े पैमाने पर इकट्ठा कर साफ़-सुथरा बनाकर model training में इस्तेमाल करना प्रमुख है; curation और training मुख्यतः cloud में, और बढ़ते हुए खुद cloud providers द्वारा की जाती है

ऑन-प्रिमाइसेस सेवाओं पर AWS कनेक्शन ब्लॉक करना

  • ऑन-प्रिमाइसेस servers तक आने वाली अधिकांश AWS access को निष्क्रिय किया जा रहा है
  • तकनीकी रूप से मुख्य रुचि TCP traffic में है, और शुरुआती handshake से client और server में फर्क किया जा सकता है
    • AWS के अंदर का client अगर ऑन-प्रिमाइसेस service से जुड़ने की कोशिश करता है, तो उसे ब्लॉक किया जाता है
    • लोकल network का client AWS-hosted service से जुड़ सकता है
  • लोकल स्तर पर इंटरनेट पर सार्वजनिक कई सेवाएँ चलाई जा रही हैं
    • web service
    • Trualias demo
    • DNS server
    • SMTP email server
  • वर्षों से no crawl policy बनाए रखी गई है, और उपलब्ध assets मुख्यतः इंटरनेट पर व्यक्तिगत users के लिए हैं
  • DNS server UDP और TCP fallback का उपयोग करता है और सीमित सार्वजनिक security telemetry देता है
    • उदाहरण query: dig @131.191.85.30 'fail2ban;*.keys.redis.athena.m3047' txt
    • यह cloud में चलने वाली सेवाओं के लिए भी उपयोगी हो सकता है, लेकिन संचालन में निर्भर होने से पहले संपर्क करने की अपेक्षा है

reverse DNS और SMTP अपवाद

  • अगर समस्या सिर्फ web service तक सीमित होती, तो reverse DNS lookup जैसे अन्य mitigation इस्तेमाल किए जा सकते थे
  • cloud providers अक्सर reverse DNS को खराब तरीके से चलाते हैं, और यह उस धारणा से मेल खाता है कि cloud के भीतर resources क्षणिक होते हैं
  • AWS कई अन्य cloud providers की तुलना में reverse DNS बेहतर करता है, और सुना है कि instance का reverse DNS सेट किया जा सकता है, हालांकि इसे सीधे आज़माया नहीं गया
  • SMTP के लिए अपवाद रखा गया है
    • जब तक विशेष रूप से गंभीर समस्या न हो, अन्य service connections ब्लॉक होने पर भी mail server connections की अनुमति रहती है
    • तकनीकी रूप से सही reverse DNS के बिना भी SMTP चल सकता है, लेकिन व्यवहार में सही reverse DNS न होने पर सामने वाला mail स्वीकार नहीं करता
  • reverse DNS का मूल्यांकन करके यह प्रारंभिक आकलन किया जा सकता है कि SYN किसी वैध mail server से आया है या नहीं
    • reputation services reverse DNS को score कर सकती हैं
    • rented और ephemeral resources में आम patterns मौजूद हैं
  • reverse DNS की मौजूदगी या उसका रूप भर से भी यह उचित अंदाज़ लगाया जा सकता है कि address किसी cloud provider का है या नहीं

AWS address block की शुरुआत क्यों हुई

  • इसकी शुरुआत कुछ abusive services के पहचाने जा सकने वाले netblocks को ब्लॉक करने से हुई, और बाद में यह छोटे hosting providers की चयनात्मक ब्लॉकिंग के proof of concept तक पहुँची
  • AWS के मामले में शुरुआत अत्यधिक ping traffic से हुई
    • ping connectionless protocol है, इसलिए source spoof किया जा सकता है
    • spoofed ping request का response attacker के बजाय spoof की गई वास्तविक location पर जाता है
  • लगातार ping responses को रोकने के लिए अस्थायी firewall rules बनाने पड़ते हैं, लेकिन Amazon का पैमाना इतना बड़ा है कि rules की संख्या बहुत बढ़ जाती है
  • AWS address ranges इकट्ठा करना शुरू किया गया, और अभी abuse target या abuse source के रूप में देखे गए AWS address space का प्रतिनिधित्व करने वाले 53 CIDR मौजूद हैं
  • कभी-कभी इससे दोगुने अस्थायी firewall rules भी देखे जाते हैं
  • “too big to fail” cloud providers से किराए पर लिए गए abusive crawler और scanner को रोकना एक अच्छा side effect है, और उनके web logs से गायब होने का अफसोस नहीं है

cloud users पर प्रभाव

  • लोकप्रिय resources या वे resources जिन्हें cloud पर deploy किया जा सकता है, उनमें से अधिकांश GitHub पर hosted हैं
  • जो लोग अन्य resources को cloud पर deploy करते हैं, उन्हें staging के लिए अपना repository बनाए रखना होगा
  • अगर repository AWS में है, तो अब updates की जाँच संभव नहीं रहेगी
    • desktop से जाँच करनी होगी
    • private hosted resource से जाँच करनी होगी
    • अलग arrangement पर चर्चा की जा सकती है
  • सिर्फ smartphone, S3 bucket, और EC2 instance होने को “इंटरनेट पर होना” कहना मुश्किल है, लेकिन smartphone से ऐसे resources तक पहुंचना संभव होना चाहिए

data theft mitigation और अनचाहा उपयोग

  • open source सामग्री का बिना अनुमति अनचाहे उद्देश्यों के लिए इस्तेमाल किया जाना data theft का खतरा भी है, जिसके लिए अलग mitigation चाहिए
  • AWS ब्लॉकिंग ऐसे mitigation में से एक की तरह भी काम करती है
  • cats, bunnies, और birds से जुड़ी सामग्री भी mitigation के संदर्भ में साथ में चर्चा की जाती है
    • cats और bunnies इसलिए आते हैं क्योंकि उनसे जुड़े बहुत से videos हैं और उनमें से कुछ खरीदे जा सकते हैं
    • birds OSI layer 2 में अधिक प्रभावी हैं, और IP datagram transmission के तरीके के रूप में RFC में documented हैं

बड़े cloud providers के लिए आवश्यक सार्वजनिक जानकारी

  • बड़े cloud providers को अभी से बेहतर forensic information distribution व्यवस्था देनी चाहिए
  • DNS और whois संभावित रूप से उपयोगी जानकारी बाँटने के साधन हो सकते हैं
  • बड़े operators को अपना reverse DNS चलाने में सक्षम होना चाहिए
  • individual addresses के लिए whois, reverse DNS में encoded अतिरिक्त जानकारी, और DNS namespace में अलग सार्वजनिक जानकारी की ज़रूरत हो सकती है
  • मौजूदा abuse patterns और प्रभावित address blocks को कवर करने वाला storm center blog भी एक संभव तरीका है
  • SMTP में reverse DNS के अलावा DNS TXT records में प्रकाशित SPF भी होता है
  • सिर्फ एक IP address से भी ऐसी जानकारी मिलनी चाहिए जो इन सवालों का जवाब दे सके
    • क्या उस address के पीछे का resource ping भेजता है
    • कितना ping भेजता है
    • क्या outbound TCP connections बनाता है
    • किन services से जुड़ता है
    • resource को कौन नियंत्रित करता है
    • क्या resource पर हमला हो रहा है
    • किस तरह का हमला है
    • इंटरनेट के अन्य resources कौन-सी mitigation चाहते हैं
  • उचित mitigation सबके लिए मददगार है, लेकिन गलत लक्ष्य वाली mitigation नहीं

खंडित इंटरनेट के परिणाम

  • अगर यह तरीका फैलता है, तो यह balkanized internet की ओर ले जा सकता है
  • बड़े cloud providers के bubble के भीतर ऑनलाइन जीवन जीने वाले लोग अधिकांश असुविधा को शायद महसूस ही न करें
  • जो असुविधा महसूस होगी भी, उसे किसी खास cloud provider चुनने का परिणाम माना जा सकता है

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

1 टिप्पणियां

 
GN⁺ 2024-09-01
Hacker News की रायें

  • सभी बड़े cloud providers machine-readable IP range lists प्रकाशित करते हैं
    उदाहरण: https://docs.aws.amazon.com/vpc/latest/userguide/aws-ip-rang...
    https://www.microsoft.com/en-us/download/details.aspx?id=565...
    https://support.google.com/a/answer/10026322?product_name=Un... आदि

    • आज मैंने जांचा तो नहीं, लेकिन उदाहरण के लिए Amazon की JSON फ़ाइल असल ownership से अलग, यह बात लगभग छिपा देती है कि वह व्यवहार में 3.0.0.0/8 इस्तेमाल करता है
      “Amazon की विशाल JSON list को block करके देखते हैं” जैसा खेल खेलने का इरादा नहीं है, और rules सिर्फ 53 हैं। कुछ side effects सह सकता हूं, और AWS पर मौजूद sites भी ठीक से खुलती हैं

  • आजकल internet पर infrastructure public करते ही aggressive traffic आने की रफ्तार पागल कर देने वाली है
    हाल ही में anycast configuration के लिए एक /23 subnet को BGP से advertise किया, और route up होकर router पर traffic आते ही tcpdump range के हर IP पर port scans से भर गया
    बेशक यह route की वजह से नहीं था; लगता है कई actors हर IP range को लगातार और indiscriminately scan करते रहते हैं। यह range कई सालों से advertise नहीं हुई थी, इसलिए यह किसी की active server list में भी नहीं रही होगी
    GitLab जैसी internal web services को अभी भी सीधे internet पर expose करना चौंकाने वाला है। कम-से-कम VPN जैसी additional protection layer रखनी चाहिए ताकि service public internet से discover न हो
    public access वाली चीज़ सिर्फ एक bastion host का SSH है, और आगे चलकर उस पर भी VPN layer लगाकर इसे हटाना चाहूंगा

    • उम्मीदों को फिर से calibrate करना बेहतर है। port scan कोई बड़ी बात नहीं है, और इसे attack कहना भी थोड़ा मुश्किल है—यह internet की background radiation जैसी चीज़ है
      जैसे अंतरिक्ष में background radiation होती है, वैसे ही internet पर internet की background radiation होती है। अगर आप vulnerable services नहीं चला रहे हैं, तो ऐसे port scans का जोखिम महीने में एक extra केला खाने जितना ही है
      console में सीधे देख रहे हैं इसलिए यह परेशान करता है। जैसे airplane में बहुत संवेदनशील Geiger counter लेकर बैठें तो डर लग सकता है, लेकिन पता न हो तो नुकसान नहीं होता
      internal services को internet पर expose करना मुझे भी चौंकाता है, और इसकी दो वजहें हैं। मैं ज्यादातर programs के authentication systems पर भरोसा नहीं करता, और बाहर वालों को यह नहीं बताना चाहता कि कौन-सी internal services इस्तेमाल कर रहा हूं। यह pure technical security से ज्यादा privacy जैसा कारण भी है
      इसके उलट, जो चीजें internet पर होनी ही चाहिए, जिनके पास मजबूत front door है या जिन्हें पर्याप्त sandboxed मानते हैं, वे पूरे दिन internet पर रह सकती हैं
      port scan शहर में घूमकर यह लिखने का internet वाला रूप है कि किस घर की बत्ती जल रही है। यह थोड़ा stalker जैसा लग सकता है, लेकिन public information है
      संदर्भ के लिए, ssh -w VPN tunnel interface बनाता है, लेकिन असली VPN product की तरह बाकी configuration अपने-आप setup नहीं करता
    • अगर उसके ऊपर VPN layer जोड़नी हो, तो कौन-सा VPN software इस्तेमाल करेंगे, यह जानने की जिज्ञासा है। निजी तौर पर मुझे OpenSSH जितना भरोसेमंद कुछ नहीं मिला
    • गलत configure किया हुआ public SSH कभी नहीं लगाना चाहिए। सचमुच कुछ सेकंड में compromise हो सकता है
      internet अब धीरे-धीरे Cyberpunk की blackwall के पीछे होने वाली चीजों जैसा महसूस होता है
    • यह सिर्फ “आजकल” की बात नहीं है। 25 साल पहले भी exposed web servers को scripts या bots से लगातार check करना काफी आम था, और web access logs में अक्सर दिखता था
      firewall के denied access logs चालू करें तो known और unknown ports पर attempts लगातार आते रहते थे
      अगर आप कुछ expose करते हैं, तो भले ही वह बहुत अंदर छिपा web component हो, उसे data और infrastructure में घुसने का दरवाजा नहीं बनने देना चाहिए
      तब से थोड़ा जो बदला है, वह traffic के sources और यह तय करने के criteria हैं कि उसे allow करना है या block। legitimate servers/services, end-user side proxies, cloud providers और crawlers की संख्या बहुत बढ़ गई है
    • यह IPv4-specific समस्या जैसी लगती है। अगर IPv6-only पर जाएं, तो malicious actors के लिए IP scanning व्यावहारिक रूप से असंभव नहीं हो जाएगी?

  • यह सच में अफसोस की बात है। ऐसा करने पर आपकी सामग्री search engines में बिल्कुल नहीं आएगी, Marginalia में भी नहीं पकड़ी जाएगी, और Wayback Machine में भी save न हो पाने का जोखिम रहेगा
    अगर आप सचमुच यही चाहते हैं, तो शायद सभी cloud और datacenter को block करना सही हो सकता है। यहां तक कि कोई छोटा ISP अपना CGNAT gateway कहां चलाता है, इस पर निर्भर करके उस ISP के users भी block हो सकते हैं। संभावना कम है, पर असंभव नहीं
    लेख में असल दुरुपयोग के तौर पर सिर्फ spoofed source address वाले ping का जिक्र दिखता है। spoofed ping packets AWS से आए थे या नहीं, यह पता नहीं चल सकता। source address वह address होता है जहां spoofer response भेजना चाहता है, spoofer का अपना address नहीं
    इससे कहीं कम intrusive mitigation यह है कि ping को करीब 10 प्रति सेकंड तक rate limit कर दिया जाए
    Internet का balkanization हो तो रहा है, लेकिन इसकी मुख्य वजह IP range blocking से ज्यादा social media का ads और data revenue के लिए silo बनना, और AI training data से कमाई निकालने की प्रवृत्ति है। Reddit/Google exclusive contract जैसे मामले इसके ज्यादा करीब हैं
    कुछ ping की वजह से किसी provider को block करते हुए IP connectivity के balkanization की शिकायत करने वाली सोच समझना मुश्किल है। balkanization पैदा करने वाला पक्ष block करने वाला ही है

    • आजकल search engines में विशाल ad-भरे content farms और Wikipedia, Stack Overflow, बड़े news/media sites, YouTube जैसे बड़े sites के अलावा लगभग कुछ नहीं दिखता
      personal blogs या छोटे hobby sites search results में दिखे काफी समय हो गया है
      Wikipedia या Stack Overflow चाहिए तो उन sites पर सीधे search किया जा सकता है। “हमेशा दिखने वाले candidates” को छोड़कर long tail content देखने का कोई option हो तो अच्छा होगा
    • यह उन कदमों पर अफसोस जैसा लगता है जिन्हें balkanization पैदा कर सकने के बावजूद “मजबूरन” उठाना पड़ा
      हालांकि पूरा tone ऐसा है जैसे मच्छर के काटने की घटना को किसी भव्य ऐतिहासिक कथा में पिरो दिया गया हो
    • कोई छोटा ISP अपनी IP space के बाहर CGNAT gateway क्यों चलाएगा?
      cloud में CGNAT gateway चलाने से बहुत समस्याएं होंगी। subscribers residential IP पर नहीं रहेंगे, इसलिए वे Netflix जैसी services शायद न देख पाएं, और Cloudflare या Google पर bot protection CAPTCHA भी अधिक बार सामने आ सकता है
      जिज्ञासा है कि क्या इसके कोई सचमुच जाने-पहचाने उदाहरण हैं
    • “search engine में न आना” को downside या नुकसान मानने की धारणा क्या है, यह जानना चाहूंगा। मैं उस नजरिए से सहमत नहीं हूं, लेकिन उसे समझने की कोशिश कर रहा हूं
    • लेखक लंबे समय से कहते आए हैं कि वे no crawling policy बनाए रखते हैं। शायद उन्हें फर्क नहीं पड़ेगा, और Google की enshittification को देखते हुए यह उलटा सही चुनाव भी हो सकता है

  • Hetzner, DigitalOcean, Linode, OVH, Contabo को मैं कुछ समय से block करता आ रहा हूं
    pfBlocker NG में ASN blocking से भी कर सकते हैं, और UFW rules से भी संभव है: https://blog.abctaylor.com/ufw-and-firewalld-rules-to-block-...

    • इस तरह पूरा block करने से legitimate organizations site तक पहुंच नहीं पाएंगी। अगर site कुछ बेचती है तो यह समस्या हो सकती है
      उदाहरण के लिए कोई organization cloud provider पर WireGuard या कोई और VPN solution खुद चलाती हो, और लोग उसके जरिए connect करें, तो outgoing IP cloud provider IP के रूप में दिखेगा
    • आजकल बड़ी-छोटी कंपनियां cloud में exit node वाले VPN या similar solutions बहुत इस्तेमाल करती हैं। ऐसी blocking आखिरकार work computers से websites access न कर पाने की स्थिति बना सकती है
    • अरे, Hetzner तक क्यों?
    • मुझे लगता है यह real world की तरह reciprocal होना चाहिए। अगर कोई किसी provider को block करता है, तो उस provider को भी पलटकर block करने में सक्षम होना चाहिए
      इसमें automation भी जोड़ा जा सकता है। तभी यह fair होगा और हर party को पता रहेगा कि क्या हो रहा है। नहीं तो इस sandbox-जैसी शरारत की जगह असली बंदूकें ही इस्तेमाल कर लो

  • मेरा पहला विचार यह था कि AWS पर चलने वाले actual desktops, खासकर Amazon Workspaces जैसी services, block हो सकती हैं
    हालांकि लगता है ऐसी services की IP space भी public docs में दर्ज है, इसलिए जरूरत पड़ने पर उन IPs को अलग से allow किया जा सकता है
    फिर भी proxy या VPN इस्तेमाल करें तो ऐसी blocking bypass करना बहुत आसान है

    • आपके लिए आसान हो सकता है। लेकिन आजकल serverless की ओर भागते इतने लोगों को देखकर लगता है कि ज्यादातर technologists भी अपनी networking या infrastructure को खुद संभालना नहीं चाहते

  • बहुत पहले Amazon servers की दर्जनों machines ने हमारे on-premises server को slow करना शुरू कर दिया था, इसलिए मैंने ऐसा किया
    शायद यह किसी SSO attempt जैसा कुछ रहा हो, लेकिन आखिर तक पूरी तरह trace नहीं कर पाया। बस Amazon IP ranges की list नियमित रूप से download करके सब block करने वाला script लिख दिया और आगे बढ़ गया

  • समझ आता है। अगर मैं अपने बनाए हुए में Internet के बड़े हिस्से के सामने दीवार खड़ी करना चाहता, तो मैं भी यही करता। यह पूरे देश को block करने से बहुत अलग नहीं है
    noise घटाने और सिर्फ “छोटे friend group” को allow करने की इच्छा भी समझ आती है
    हालांकि मैं ऐसा पूरे domain पर नहीं, सिर्फ कुछ specific services पर करता हूं। Mumble server केवल उन 3–4 देशों के लिए खोलता हूं जहां दोस्त हैं, और cloud providers को exclude करता हूं। tech blog दुनिया में किसी को भी देखने देता हूं
    मैं इस बात पर दृढ़ हूं कि shared knowledge सबके लिए फायदेमंद है। 300-baud C64 modem के modem initialization string पर मेरे notes अगर एक भी व्यक्ति की मदद कर दें, तो वह व्यक्ति वही तकलीफ दोबारा नहीं झेलेगा जो मैंने झेली, और दुनिया थोड़ी बेहतर होगी
    कई वजहों से ऐसी इच्छा पैदा हो सकती है, यह समझता हूं। ठीक है। हर कोई अपने हिसाब से करे

    • मैंने जो Zen InterSLIP Dialing Script लिखा था, वह सचमुच दुनिया भर में घूम चुका है
      Amazon इतना बड़ा है कि उसे ignore नहीं किया जा सकता। मैं समझता हूं कि ICMP और SYN traffic का बड़ा हिस्सा कचरा है। मैं भी blocking में मदद करना चाहता हूं और असल में mitigation defaults भी तैयार रखे हैं
      समस्या यह है कि Amazon “scale पर” मेरे mitigations को छेड़ता है, इसलिए वह सिरदर्द है। Amazon भूसे और अनाज को अलग करने में मदद नहीं करता। उसका तरीका “ping problem के लिए PCAP भेजो” जैसा है
      Amazon को data भेजकर कोई response न मिले तो सीखने को कुछ नहीं मिलता। मुझे good traffic भी नहीं चाहिए, bad traffic भी नहीं, और उन पर हमला करने वाला spoofed traffic भी नहीं चाहिए
      अगर वे मुझे उनकी मदद करने में मदद करने का इरादा नहीं रखते, तो मुझे यह सब नहीं चाहिए। मैं बस अपनी जिंदगी simple रख रहा हूं

  • ऐसी चीज़ें देखकर पुराने इंटरनेट की याद आती है। कमर्शियलाइज़ेशन से पहले इंटरनेट कितना शानदार था, यह समझाना वाकई मुश्किल है
    यह कड़वी-मीठी खुशी कि हमने बिल्कुल सही अनुमान लगाया था कि नतीजा ऐसा ही होगा, खोई हुई चीज़ की भरपाई के लिए बिल्कुल भी काफी नहीं है

    • आह, हाँ। यह नॉस्टैल्जिक बकवास है। इंटरनेट शुरू से ही पैसे की बात था

  • DigitalOcean, OVHcloud, ColoCrossing, Scaleway, Tencent, यहाँ तक कि Google जैसी जगहों की तुलना में AWS तो बॉय स्काउट जैसा है
    खासकर DigitalOcean के लिए, मुझे लगता है कि “साइबरसिक्योरिटी” कम्युनिटी को मार्केट करना एक भयानक गलती थी

    • असल में लेख पढ़ें तो उसमें लिखा है कि “proof of concept के तौर पर कुछ छोटे hosting providers को ब्लॉक किया,” और वह असल में DigitalOcean ही है। उसी वजह से जिसके बारे में आप कह रहे हैं

  • हितों का खुलासा: AWS फिलहाल मेरा नियोक्ता है
    हो सकता है मैं कोई बहुत स्पष्ट बात चूक रहा हूँ, लेकिन अगर लेखक मानता है कि ping traffic spoofed था, तो उसे कैसे पता कि स्रोत AWS था?

    • AWS की भारी मात्रा में abuse, घटिया scrapers और crawlers के स्रोत के रूप में बहुत खराब प्रतिष्ठा है। कई बार खराब crawlers और वास्तविक हमलों में फर्क करना भी मुश्किल होता है
      मेरे अनुभव में, मैंने बहुत बार देखा है कि AWS से बहुत ज्यादा traffic आया, और कुछ मामलों में वही समाधान अपनाना पड़ा—यानी पूरे AWS को ब्लॉक करना
      मुझे नहीं पता AWS परवाह नहीं करता, या उसका response slow है। शायद report करना ही बहुत मुश्किल हो
      जो स्पष्ट बात छूट गई है, वह यह है। AWS “bad” traffic का बहुत बड़ा स्रोत है, और misbehaving customers को रोकना बहुत मुश्किल है, जबकि malicious actors के लिए बेहिसाब capacity किराए पर लेना बहुत आसान है
      मैंने शायद ही कभी देखा हो कि GCP या Azure उसी स्तर के पागलपन भरे traffic का स्रोत बने हों