IP spoofing हमला जो पूरी दुनिया को आपके दोस्तों के पास abuse report भेजने पर मजबूर कर सकता है

 (delroth.net)
1 पॉइंट द्वारा GN⁺ 2024-10-30 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Hetzner ने 195.201.9.37 से SSH port scan होने की abuse report फ़ॉरवर्ड की, लेकिन सर्वर के अंदर malicious process, file change, या असामान्य traffic का कोई सबूत नहीं मिला
  • tcpdump से दिखा असली flow यह था कि सर्वर ने बाहर 22/tcp पर कनेक्ट नहीं किया था, बल्कि कई इंटरनेट hosts सर्वर को TCP RST वापस भेज रहे थे — यानी यह backscatter के अधिक क़रीब था
  • मुख्य कारण यह है कि BCP38 filtering न करने वाले network के ज़रिए कोई भी मनमाना source IP लगाकर packet भेज सकता है, और TCP·QUIC·TLS जैसे protocols में attacker जवाब सीधे देख नहीं सकता क्योंकि उनमें round-trip response चाहिए
  • यही pattern लेखक के दूसरे Tor relay 2 में भी दिखा, और tor-relays mailing list व Tor Project issue में कुछ दिन पहले से ऐसे ही मामले रिपोर्ट हो रहे थे; कुछ nodes अस्थायी रूप से down भी हुए
  • attacker पीड़ित का IP source के रूप में spoof करके कई SSH targets पर connection attempts भेज सकता है, और automated abuse reports, blocklists, व hosting provider action ट्रिगर कर सकता है

Hetzner की abuse report और सर्वर जांच

  • Hetzner ने 195.201.9.37 IP के लिए AbuseInfo mail भेजा
    • रिपोर्ट भेजने वाला: abuse@watchdogcyberdefense.com
    • logs में कई 202.91.16x.x targets के 22/tcp की ओर जाने वाली DENIED entries शामिल थीं
  • ऊपर से देखने पर ऐसा लगा जैसे सर्वर ने इंटरनेट पर SSH connections भेजना शुरू कर दिया हो, इसलिए सामान्य तौर पर malware infection का शक होना स्वाभाविक था
  • 1–2 घंटे की जांच के बाद भी सर्वर लगभग सामान्य मिला
    • कोई असामान्य process नहीं
    • filesystem में कोई बदलाव नहीं
    • hypervisor के नज़रिये से कोई असामान्य network traffic नहीं
  • उस सर्वर पर कई distributed और federated services चल रही थीं
    • Syncthing relay
    • Mastodon instance
    • Tor relay
    • Matrix homeserver
  • Tor relay कुछ 22/tcp relays से connect करता है, लेकिन वह रिपोर्ट किए गए network से मेल नहीं खाता था; Matrix·Mastodon logs और Mastodon Sidekiq queue में भी random IP/port requests के निशान नहीं मिले

tcpdump ने पैकेट flow के बारे में क्या दिखाया

  • शुरुआत में dst port 22 filter से सर्वर से बाहर 22/tcp पर जाने वाला traffic देखने की कोशिश की गई
  • filter को not src host 195.201.9.37 करने पर कई बाहरी IPs के 22/tcp से लेखक के सर्वर के ephemeral ports पर आने वाले TCP RST packets दिखे
  • असल में सर्वर ने random hosts के 22/tcp पर connection नहीं भेजा था; बल्कि random इंटरनेट hosts सर्वर को reset packets भेज रहे थे
  • यह pattern source IP spoofing के कारण spoofed IP पर वापस आने वाले response packets यानी backscatter से मेल खाता है

source IP spoofing और BCP38 की कमी

  • इंटरनेट पर destination IP सही होना ज़रूरी है, लेकिन fake source IP के साथ packets कई destinations पर भेजना अब भी संभव है
  • BCP38 मौजूदा best practice है, जिसके अनुसार peer networks को केवल उन्हीं IP addresses को source के रूप में इस्तेमाल करने देना चाहिए जिनकी उनसे अपेक्षा की जाती है
  • यह filtering packet path की शुरुआत में लागू होनी चाहिए, तभी इसका असर होता है
    • बड़े transit provider स्तर पर meaningful filtering कठिन होती है, क्योंकि peers उस provider से पूरे इंटरनेट traffic को carry करने की उम्मीद रखते हैं
  • सिर्फ़ एक BCP38 न लागू करने वाला transit provider मिल जाए, तो मनमाने source IP के साथ packets भेजे जा सकते हैं
  • APNIC ने 2023 में source address validation अब भी समस्या क्यों है, इस पर लेख प्रकाशित किया था
  • TCP, QUIC, TLS जैसे protocols को round-trip communication चाहिए, इसलिए source IP spoof करने पर attacker responses नहीं देख सकता
    • इसलिए सामान्य port scan results देखने के लिए यह उपयुक्त नहीं है
    • हालाँकि reflection DDoS जैसे ज्ञात दुरुपयोग मौजूद हैं

ऐसा spoofing वास्तविक नुकसान कैसे करता है

  • सबसे संभावित flow यह है कि किसी ने लेखक के IP को source बनाकर कई इंटरनेट hosts के 22/tcp पर connection attempts भेजे
  • अगर उद्देश्य सामान्य open-port probing होता, तो spoofing करने वाला responses देख ही नहीं पाता, इसलिए यह तर्कसंगत नहीं लगता
  • पहले Idle Scanning नाम की एक तकनीक थी, लेकिन वह कम व्यस्त सर्वरों और predictable network stack counters पर निर्भर थी, और दशकों पहले ही व्यावहारिक उपयोगिता खो चुकी है
  • traffic का volume बहुत कम है और अवधि बहुत लंबी, इसलिए scanner configuration में गलती से source IP ग़लत भर देना भी विश्वसनीय नहीं लगता
  • असली नुकसान abuse reporting automation से होता है
    • spoofed connection attempts honeypot या intrusion detection system वाले networks तक पहुँचते हैं
    • कुछ systems अपने-आप abuse reports भेजते हैं
    • hosting providers यह ग़लत समझ सकते हैं कि पीड़ित सर्वर compromised है या malicious है

दूसरे Tor relays में भी यही pattern

  • लेखक ने फिर पुष्टि की कि उनका सर्वर Tor relay के रूप में काम कर रहा है
  • Tor relay, Tor network के अंदर का node होता है; अगर वह exit node नहीं है, तो वह public internet से सीधे communicate नहीं करता
    • relay, Tor network में शामिल nodes के बीच encrypted anonymous traffic forward करता है
    • कुछ relays Guard Node के रूप में काम करते हैं और Tor network का entry point बन सकते हैं
  • अलग-अलग देशों और ISPs में मौजूद 2 अतिरिक्त relays पर भी tcpdump चलाया गया
    • home internet connection पर relay
    • जापान में Linode VPS पर relay
  • दोनों relays पर बाहरी 22/tcp से relay IP की ओर आने वाला वही spoofed TCP response pattern दिखा
  • लेखक ने tor-relays mailing list पर mail भेजी, और कुछ दिन पहले से इसी घटना का विश्लेषण कर रहा Tor Project issue पहले से मौजूद था
  • यह spoofing हमला relays से पहले दूसरे तरह के nodes पर शुरू हुआ था, और बड़े पैमाने पर forged connections की वजह से कुछ nodes अस्थायी रूप से down भी हुए थे

ऐसा attack flow जिसमें कोई भी target बन सकता है

  • संभावित attack flow इस प्रकार है
    • attacker को BCP38 filtering के बिना किसी network तक access मिलता है
    • वह कई random इंटरनेट hosts के 22/tcp पर TCP connection requests भेजता है
    • source IP के रूप में victim का IP spoof करता है
    • target hosts या security systems इसे victim की connection attempt मानकर abuse reports भेजते हैं
    • पर्याप्त scale होने पर victim IP कई blocklists में चढ़ सकता है, और hosting provider सर्वर suspend कर सकता है
  • इस हमले में Tor-विशिष्ट कुछ भी नहीं है
  • किसी एक प्रेरित attacker के लिए इसे अंजाम देना विशेष रूप से कठिन नहीं लगता
  • पीड़ित असली attacker नहीं, बल्कि spoof किए गए source IP का मालिक होता है; लेकिन automated abuse reports और hosting provider की प्रतिक्रिया के कारण उसे operational नुकसान हो सकता है

2024 में भी बना हुआ इंटरनेट ऑपरेशंस का संकट

  • spoofed source IP का 2024 में भी समस्या बने रहना इंटरनेट ऑपरेशंस की विफलता जैसा है
  • सिर्फ़ BCP38 ही नहीं, RPKI को भी deployment के मामले में मिलती-जुलती समस्याएँ रहीं; बड़े इंटरनेट businesses ने सीधे peers पर requirements लागू करनी शुरू कीं, तब जाकर adoption बढ़ना शुरू हुआ
  • इस हमले के अगले कदम स्पष्ट नहीं हैं
    • यह पहले से वास्तविक दुनिया में हो रहा है
    • लेखक को नहीं पता कि यह पहले से documented attack है या नहीं
    • spoofed IP packets के असली source को बाद में trace करने का कोई तरीका लेखक को ज्ञात नहीं है
  • जिन operators को ऐसी abuse reports मिलें, उन्हें यह सत्यापित करना चाहिए कि उनका सर्वर attacker नहीं बल्कि victim हो सकता है, और hosting provider को समझाने के लिए प्रमाण जुटाने चाहिए

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

1 टिप्पणियां

 
GN⁺ 2024-10-30
Hacker News की टिप्पणियां

  • इस तरह की समस्या से निपटना सच में बहुत झुंझलाहट भरा है। दुरुपयोग की रिपोर्ट का वैध जवाब—“किसी ने मेरा IP spoof किया, वह मैं नहीं था, और मेरे उपकरण भी compromise नहीं हुए”—किसी दुर्भावनापूर्ण व्यक्ति के बहाने जैसा बिल्कुल वही लगता है
    आखिरकार, लेख में बताए अनुसार, आपको ऐसे पक्ष के सामने अनुपस्थिति का प्रमाण देना पड़ता है जिसे खास परवाह भी नहीं होती, और यह व्यावहारिक रूप से लगभग असंभव है

    • Hetzner ने ईमेल में कहा था कि जवाब देने की जरूरत नहीं है
      किसी ऐसी चीज़ पर automated abuse report, जिसे आसानी से spoof किया जा सकता है, अपने-आप में रिपोर्ट को उचित नहीं ठहराती; लेकिन यह मेरे server के सही चलने और hijack न होने की जल्दी जांच करने की वजह जरूर हो सकती है
    • वैध जवाब में किसी भरोसेमंद third party द्वारा वास्तविक दुनिया में गारंटी देने जैसा वास्तविक प्रमाण शामिल होना चाहिए
      कम से कम पहचान और jurisdiction का आधार, और शायद video call जैसी चीज़ भी जरूरी हो सकती है। इंटरनेट पर anonymously “मैं अच्छा व्यक्ति हूं” कहकर भरोसा करने को कहना पर्याप्त नहीं है

  • Spoof किए गए MAC address, email address, ARP messages, Neighbor Discovery, man-in-the-middle TLS certificates के साथ भी यही बात है
    फिर भी यह हैरानी की बात है कि अभी भी कुछ चीजें काम कर रही हैं

    • इंटरनेट टूटा हुआ नहीं है; इसमें बहुत ज्यादा उपयोगिता और भरोसेमंदता है
      अगर इसे बिल्कुल perfect design और operate करने के लिए बनाया गया होता, तो शायद यह काफी बार बड़े स्तर पर टूटता। थोड़ी imperfection सहने की क्षमता ने इंटरनेट की मजबूती और उपयोगिता में बड़ा योगदान दिया है
      इसका मतलब यह नहीं कि सुधार न किए जाएं; यह ज्यादा एक चेतावनी है कि perfectionism के पीछे भागने से सब कुछ बिगाड़ देने वाली बड़ी गलती आसानी से हो सकती है
    • Spoof किए जा सकने वाले MAC address Wi-Fi privacy के लिए काफी जरूरी हैं
    • मोबाइल नेटवर्क के SS7 में भी ऐसी ही समस्या है: https://youtu.be/wVyu7NB7W6Y
    • अब लगने लगा है कि चीन ने इंटरनेट protocols में सुधार का जो प्रस्ताव रखा था, उसमें शायद कुछ तुक थी
    • DNS को लेकर शिकायतें अक्सर सुनता हूं, लेकिन असल में यह कितना सुरक्षित है और इसे ठीक करने की कोशिशें इतनी कम क्यों हैं, यह जानने की उत्सुकता है

  • पहले इसी तरह DrDoS reflection servers scan किए जाते थे। कोई hosting provider port scan की शिकायतें नहीं पाना चाहता, इसलिए scan का source address किसी अच्छी reputation वाले निर्दोष cloud provider के IP पर सेट कर दें, तो reflection servers खुशी से UDP responses उसी तरफ भेज देते थे
    Cloud provider को स्वाभाविक रूप से ढेर सारी complaints मिलती हैं, लेकिन अगर मैं कहता कि मेरे server से scan नहीं हो रहा, तो provider जांच करके service बंद नहीं करता था। Spoofed scan packets भेजने वाला server detect नहीं होता, इसलिए सामान्य abuse-report की समस्या के बिना पूरे इंटरनेट को बार-बार scan किया जा सकता था
    असल में यह कितनी बार होता है, पता नहीं; लेकिन transit providers के साथ मिलकर hops को पीछे trace करें तो spoofed packets के source को track करना संभव है। एक बार JPMorgan ने Cogent के साथ मिलकर मुझे बताया था कि उनके IP address पर packets न भेजूं। संदर्भ के लिए, Cogent इंटरनेट के Tier 1 providers में भी spoofing को लेकर काफी tolerant है
    यह तरीका खास तौर पर Tor के लिए इस्तेमाल हुआ, यह पहली बार सुना, और यह intuitively थोड़ा उलटा लगता है। क्योंकि spoofed packets भेजने वाला व्यक्ति Tor supporter जैसा लगता। शायद यह बस कोई troll है, और अच्छी बात है कि Tor host करने वाले providers ऐसी चीजों को ज्यादा गंभीरता से नहीं लेंगे

    • कुल मिलाकर Cogent भी कुछ खास अच्छा नहीं लगता
      यह बस troll भी हो सकता है, लेकिन कोई ऐसा पक्ष भी हो सकता है जो Tor को radioactive waste जैसा बना देना चाहता हो, क्योंकि Tor surveillance operations में बाधा डालता है

  • यह कोई नई बात नहीं है। कुछ साल पहले मैंने एक बहुत basic firewall rule बनाया था: destination port 22 पर आने वाले TCP packets में अगर SYN=1, ACK=0 हो, तो source IP को एक दिन के लिए block कर देता था
    फिर शिकायतें आने लगीं कि कुछ खास sites और services काम नहीं कर रहीं। पता चला कि हर कुछ दिनों में 8.8.8.8, 1.1.1.1, Steam, Roblox, Microsoft, Facebook, Instagram, और कई chat services जैसे popular server IPs से ऐसे packets आ रहे थे। जाहिर है वे सभी spoofed packets थे, और आखिरकार firewall rule में थोड़ा और verification जोड़ना पड़ा
    इसलिए मुझे पूरा भरोसा है कि यह काफी common है। व्यक्तिगत रूप से मुझे पता है कि कई IP addresses operate करना एक exceptional case है, लेकिन मुझे यह flexibility चाहिए कि मैं अपने source addresses में से कोई भी इस्तेमाल करके किसी भी ISP को packets भेज सकूं। मेरे लिए यह महत्वपूर्ण है, और अगर ISP source के आधार पर filtering करता है, तो यह contract खत्म करने की वजह है; मैं दूसरे ISP पर चला जाऊंगा

    • अगर आपके पास सच में अपने IP addresses हैं, तो यह normal और expected behavior है। लेकिन अगर ISP A का IP address ISP B के जरिए इस्तेमाल किया जा सकता है, या उल्टा, तो वह हमेशा से bug था और उसे ऐसे इस्तेमाल नहीं किया जाना चाहिए
      बाद वाला मामला “spacebar heating फिर चालू करना” जैसी category में आता है, और उम्मीद है कि ISPs अपने broken networks ठीक करेंगे
    • एक ठोस वास्तविक उदाहरण देता हूं
      एक company ने branch office on-premises में कुछ web assets host किए थे, और वहां 1Gbps line थी। headquarters में कई 10G lines और काफी अच्छा datacenter था, इसलिए web VM को headquarters में shift किया गया, लेकिन assigned IP address—यानी ISP-A का public static IP—बरकरार रखा गया। VPN के जरिए headquarters तक routing की, और server ने default gateway का इस्तेमाल करते हुए ISP-A source IP वाले responses ISP-B की 10G line से भेजे
      इससे incoming traffic 1G तक limited रहा, लेकिन outgoing में 10G का फायदा मिला। वैसे भी सिर्फ GET requests थीं। यह optimal setup नहीं था और आखिरकार IP बदल दिया गया, लेकिन यह valid use case लगता है
      दूसरा, हमारे पास दो अलग-अलग ISP lines, अपना ASN, और अपना /23 address था। कुछ traffic को load-balance करने के लिए आधे IPs ISP-A से और बाकी आधे ISP-B से भेजे। यह ठीक चला, लेकिन balance थोड़ा मिलाने की कोशिश पर एक दिलचस्प समस्या सामने आई। पहला /24 ISP-A पर और दूसरा /24 ISP-B पर announce किया था, लेकिन ISP-A में RP filtering थी। इसलिए सभी IPs वहां भी announce करने पड़े
      RP filter के काम करने के तरीके के कारण prepend जैसी चीज़ नहीं कर सकते, और सारा traffic उनके जरिए ही आना पड़ता है। अगर उस prefix के लिए बेहतर route दिखता है, तो वह filter कर देता है। कई महीनों तक उन्होंने security का हवाला देकर इसे ठीक करने से इनकार किया। Security best practice के नाम पर था, इसलिए ISP का नाम बता सकता हूं: Virgin Media
      संदर्भ के लिए, rp_filter वाली इंटरनेट line कोई 20 डॉलर महीने वाली नहीं थी, बल्कि 5 हजार डॉलर प्रति माह से ज्यादा की थी। उस इलाके में विकल्प नहीं था इसलिए बदल नहीं सके, लेकिन अगर विकल्प होता तो किसका contract जाता, यह साफ है
    • मैं आम तौर पर हर जगह rp_filter enable रखता हूं, इसलिए सच में जानना चाहता हूं कि ऐसी flexibility की जरूरत क्यों होती है
    • Technically, ऐसे ISPs भी violation में होंगे। अपना ASN चाहिए

  • “किसी को Tor relay पसंद नहीं हैं” वाली परिकल्पना, लगाई गई मेहनत के मुकाबले बहुत भरोसेमंद नहीं लगती
    हो सकता है कि malicious relay चलाने वाला कोई पक्ष वैध relay को अनैतिक तरीके से हटवाकर, अपने नियंत्रण वाले network का अनुपात बढ़ाना चाहता हो

    • लगभग तय तौर पर मामला वही लगता है। कुछ बहुत बड़े भी नहीं nodes के logs तक पहुंच रखने वाला attacker, व्यक्तियों के service access patterns कितनी आसानी से देख सकता है—इस बारे में यहां काफ़ी हकीकत से आंख चुराना दिखता है
    • अगर Tor network से नफ़रत है, तो आसान तरीका traffic की बाढ़ डालकर service degrade करना है
      कुछ BitTorrent downloads चला देना भी काफी हो सकता है

  • spoofing को आगे असंभव बनाने के लिए, BCP38 लागू न करने वाले सभी AS का traffic पर्याप्त संख्या में network operators द्वारा reject करवाने के लिए क्या चाहिए होगा?

    • सिर्फ Cloudflare भी शायद काफी हो सकता है
      उसके पास पहले से ही काफी inbound traffic पर पकड़ है, इसलिए “connection security check” का सच में मतलब हो सकता है
    • network operators को परवाह करने पर मजबूर करने का तरीका खोजना होगा। खासकर Tier-1 transit providers या असामान्य रूप से बड़े networks महत्वपूर्ण हैं
      हालांकि reflection amplification factor घटाना कहीं ज्यादा आसान है। क्योंकि IPv4 में reflection vectors scan किए जा सकते हैं, और input bytes के 10 गुना response देने वालों से शिकायत की जा सकती है

  • यह swatting जैसी ही समस्या है। यह इस बात पर निर्भर करती है कि authority वाला कोई पक्ष unverifed problem reports के आधार पर कड़ा action ले
    फर्क शायद यह है कि authority से सीधे संपर्क करने के बजाय, unrelated third parties से report भिजवाई जाती है

  • single packet और बिना round-trip वाली requests के लिए, जब तक traffic denial-of-service level का न हो, system को automatic abuse reports नहीं भेजनी चाहिए
    खासकर SSH में, किसी भी तरह का handshake होने से पहले उसे valid connection attempt मानने का कोई तरीका नहीं है

    • अगर कोई भी abuse report डाल सकता है, तो server provider को “2 दिन में जवाब नहीं दिया तो server suspend” जैसे terms वाले कदम उठाने से पहले report को सच में verify करना चाहिए
      मेरा मुख्य server भी fake abuse report की वजह से down हो चुका है। दावा था कि मेरे IP से 1Gbps से ज्यादा का DoS attack हुआ, जबकि मेरे server की line 400Mbps पर capped थी। अगर किसी इंसान ने report पढ़ ली होती, तो उसे पता चल जाता कि यह असंभव है, और छुट्टी के दौरान phone support से दो दिन तक लड़ना नहीं पड़ता
    • लेकिन port scan जैसी कुछ वास्तविक दिखने वाली abuse activity में कभी-कभी बस ऐसा एक packet ही होता है

  • यह IP version का swatting, patent trolling, निर्दोष लोगों को फंसाना, और competitor को हटाने के लिए DMCA takedown requests जैसा है
    मूल रूप से यह abuse-prevention mechanisms को weaponize करके नापसंद target पर हमला करने का तरीका है। यह दिलचस्प है कि authority वाला पक्ष weak link बनकर अनैतिक actors के लक्ष्य हासिल करने में सक्रिय रूप से इस्तेमाल हो सकता है, लेकिन यह पूरी तरह नई घटना नहीं है

    • अगर कोई चतुर है और उसके पास अपना relay भी है, तो जितने ज्यादा दूसरे relays हटेंगे, उसका अपना relay चुने जाने की probability उतनी ही बढ़ेगी
      metrics.torproject.org पर relay count और “advertised bandwidth” graphs देखने पर लगता नहीं कि इससे बहुत बड़ा फर्क पड़ा, लेकिन फिर भी यह दिलचस्प है
      सबसे खराब बात यह है कि “Watchdog Cyber Defense”, Spamhaus, Shadowserver, या UCEPROTECT जैसे extortionists की नकल करने वाली जगहें लाखों automated reports डाल सकती हैं, और hosts को अपनी IP range blocklist में न चढ़े, इसके लिए व्यावहारिक रूप से उन reports को मानना पड़ता है

  • इस समस्या का कोई in-band solution नहीं है, लेकिन out-of-band solution हो सकता है
    उदाहरण के लिए (1) destination ISP को बताना कि reverse traffic मिल रहा है, (2) वह ISP packets कहां से आ रहे हैं यह जांच करे और उस ISP को बताए, (3) source मिलने तक step 2 दोहराना, (4) उस network के हिस्से को तब तक isolate करना जब तक वह ठीक से काम न करे
    आखिरकार internet इंसानों से बना है

    • कभी-कभी लोग यह जानकर हैरान होते हैं कि पूरा internet इसलिए चलता है क्योंकि मानवता का एक हिस्सा दुनिया का सबसे बढ़ा-चढ़ाकर बताया गया pipe game manage करना सच में पसंद करता है
    • step 2 और 3 के लिए बहुत से लोगों को दूसरे की समस्या हल करने के लिए बिना pay काम करना पड़ता है
    • संदर्भ: https://news.ycombinator.com/item?id=41985920