TL; DR हमलावर आपके सर्वर के पते के साथ स्रोत आईपी की जगह लेता है और स्वचालित गालियां चलाता है। नतीजतन, क्लाइंट को दुर्भावनापूर्ण गतिविधि के लिए होस्टिंग पर प्रतिबंध लगा दिया गया है जो वहां नहीं था।Vdsina.ru द्वारा टिप्पणी:
यह लेख हमारे मुवक्किल द्वारा लिखा गया था, जो DDoS हमले के बाद एक बड़े हॉस्टल से हमारे पास आया और कृपया इस कहानी को साझा करने के लिए सहमत हुए।
मैं आपको DDoS हमलों के एक आश्चर्यजनक रूप से कपटी तरीके के बारे में बताऊंगा, जिसका मैंने पहले सामना नहीं किया था। कपटी बात यह है कि पीड़ित के सर्वर पर कोई हमला नहीं किया जाता है। इसके बजाय, हमलावर आपके सर्वर के लिए पूरी तरह से वास्तविक शिकायतें (आम लोगों को "गालियां") देने के लिए मजबूर करते हुए, थर्ड-पार्टी अटैक डिटेक्शन सिस्टम के संचालन के लिए उकसाता है।
होस्टर की तरफ से, ऐसा लगता है कि आप दुर्भावनापूर्ण गतिविधि में लगे हुए हैं, हालांकि वास्तव में यह सच नहीं है। यह पता चला है कि कई बड़े होस्टिंग प्रदाता समस्या के कारणों को गहराई से समझने के लिए तैयार नहीं हैं और नियमों को तोड़ने के लिए आपको बस प्रतिबंध लगाना पसंद करते हैं।
यह लेख एक वास्तविक मामले में इस प्रकार के हमले का विवरण देता है।
घटनाओं के कालक्रम
मैंने एक प्रसिद्ध होस्ट में वीपीएस सर्वरों पर कई व्यक्तिगत परियोजनाएं रखीं। एक बार मुझे उनसे एक पत्र मिला:
# 9042382: ToS उल्लंघन - दुर्भावनापूर्ण गतिविधि
हैलो,
हमें आपके सर्वर XXXX से उत्पन्न होने वाली दुर्भावनापूर्ण गतिविधि की रिपोर्ट मिली है। हम पूछते हैं कि जैसे ही आप सक्षम होते हैं आप इस मामले की जांच करते हैं। एक बार जब आप अपनी जांच पूरी कर लेते हैं, तो कृपया निम्नलिखित सवालों के जवाब के साथ इस टिकट का जवाब दें:
...
Reported-From: abuse-out@checkdomain.de Category: info Report-Type: info Service: different services Version: 0.1 User-Agent: Checkdomain Express 0.19 Date: Fri, 26 May 2018 19:25:19 +0200 Source-Type: ipv4 Source: my-server-ip-xx-xxx Port: dif. Report-ID: dih3cefnp@checkdomain.de Schema-URL: http://www.blocklist.de/downloads/schema/info_0.1.1.json Attachment: text/plain DETAILS ZU DEN ATTACKEN/STÖRUNGEN | DETAILS OF THE ATTACKS (letzten 60 Tage / max. 100 St.) | (last 60 days / max. 100 hits) portflood: syn | | standby.checkdomain.de | VORHERIGE SPERREN DER IP-NUMMER | BANNED HISTORY OF THIS IP-NUMBER my-server-ip-xxx-xxx-xxx: this ip-number was never banned before AUZUG AUS SERVERLOGDATEI | EXCERPT FROM SERVER LOGFILE tcp 0 0 85.10.207.190:80 my-server-ip-xx-xxx:41667 SYNRECV - tcp 0 0 85.10.207.190:80 my-server-ip-xx-xxx:46208 SYNRECV - tcp 0 0 85.10.207.190:80 my-server-ip-xx-xxx:13000 SYNRECV - tcp 0 0 85.10.207.190:80 my-server-ip-xx-xxx:39104 SYNRECV - tcp 0 0 85.10.207.190:80 my-server-ip-xx-xxx:55348 SYNRECV - tcp 0 0 85.10.207.190:80 my-server-ip-xx-xxx:37266 SYNRECV - tcp 0 0 85.10.207.190:80 my-server-ip-xx-xxx:60684 SYNRECV - tcp 0 0 85.10.207.190:80 my-server-ip-xx-xxx:63878 SYNRECV - tcp 0 0 85.10.207.190:80 my-server-ip-xx-xxx:50445 SYNRECV - tcp 0 0 85.10.207.190:80 my-server-ip-xx-xxx:56215 SYNRECV -
जहाँ
my-server-ip-xx-xxx सर्वर आईपी एड्रेस है।
इसमें, होस्टर मुझे अपने दुर्व्यवहार @ मेलबॉक्स पर प्राप्त एक शिकायत भेजता है, और तुरंत दुर्भावनापूर्ण गतिविधि को रोकने के लिए कहता है, अन्यथा मुझे अवरुद्ध कर दिया जाएगा। संलग्न लॉग SYN RECEIVED स्थिति में 80 (HTTP) पोर्ट के लिए टीसीपी कनेक्शन की एक सूची दिखाता है। अर्थात्, मेरे सर्वर से किसी के वेब सर्वर पर SYN बाढ़ है।
मेरा पहला विचार यह है कि उन्होंने मुझे हैक किया और मेरे सर्वर से SYN बाढ़ आ रही है। लिनक्स पर, सामान्य उपयोगकर्ता अधिकारों के साथ सॉकेट्स के प्रबंधन पर प्रतिबंध हैं और आप केवल रूट विशेषाधिकार के साथ केवल SYN पैकेट (पूर्ण टीसीपी कनेक्शन स्थापित किए बिना) भेज सकते हैं। और इसका मतलब है कि वे पूरी तरह से टूट चुके हैं।
घबराहट में, मैं दुर्भावनापूर्ण प्रक्रिया को देखने के लिए सर्वर पर चलता हूं। मैं शीर्ष, एसएस, lsof की जांच करता हूं और कुछ भी संदिग्ध नहीं देखता हूं। प्राथमिक निष्कर्ष: "
हॉरर, वे शायद ऐसे शांत रूटकिट को भरते हैं जो वायरस को सभी सिस्टम उपयोगिताओं से कर्नेल स्तर पर छुपाता है! "। अनुसंधान की प्रक्रिया में, यह पता चलता है कि सर्वर पर लोड नहीं बदला गया है, मेजबान पैनल में ग्राफ़ के अनुसार, इंटरफ़ेस पर ट्रैफ़िक समान रहता है।
इससे पहले, मैंने निवर्तमान ट्रैफ़िक दिखाने वाले फ़िल्टर के साथ
tcpdump शुरू किया, और कुछ भी संदिग्ध नहीं देखा। हताश, मैं सर्वर पर सभी ट्रैफ़िक देखने का फैसला करता हूं। मुझे वैध ट्रैफ़िक की धारा में अजीब सर्वर से दुर्लभ आरएसटी पैकेट मिलते हैं।
यह कुछ इस तरह दिखता है, जहाँ
my-server-ip-xx-xxx मेरे सर्वर का पता है:
IP 85.10.207.190.http > my-server-ip-xx-xxx.8389: Flags [R] IP 85.10.207.190.http > my-server-ip-xx-xxx.8389: Flags [R] IP 85.10.207.190.http > my-server-ip-xx-xxx.8389: Flags [R] IP adsl-070-154.sip.pns.bellsouth.net.http > my-server-ip-xx-xxx.8389: Flags [R] IP adsl-070-154.sip.pns.bellsouth.net.http > my-server-ip-xx-xxx.8389: Flags [R] IP adsl-070-154.sip.pns.bellsouth.net.http > my-server-ip-xx-xxx.8389: Flags [R]
यह स्पष्ट था कि यह एक विसंगति थी, क्योंकि इन सर्वरों के साथ अधिक विनिमय नहीं था और उन्होंने कनेक्शन बंद करने के लिए एक पैकेट क्यों भेजा, यह मेरे लिए स्पष्ट नहीं था।
इस बिंदु पर, अनुभवी व्यवस्थापक तुरंत सब कुछ समझ जाएंगे, लेकिन हम इसे अपनी उंगलियों पर हल करेंगे
यह कैसे काम करता है
आने वाले आरएसटी पैकेट एक निजी पोर्ट पर टीसीपी कनेक्शन स्थापित करने के प्रयासों के जवाब हैं। उसी समय, मेरे सर्वर से आरएसटी भेजने वाले सर्वर पर कोई आउटगोइंग ट्रैफ़िक नहीं है। इसका मतलब है कि हमलावर खदान से बाहर जाने वाले पते की जगह लेता है और डीडीओएस हमले के समान ट्रैफिक उत्पन्न करता है। लेकिन केवल एक चीज जो एक हमलावर कर सकता है, वह एक आउटगोइंग पैकेट भेजना है, सर्वर से सभी प्रतिक्रियाएं मेरे सर्वर पर आती हैं।
केवल नकली अनुरोधों के जवाब पीड़ित के सर्वर तक पहुंचते हैंआमतौर पर, ऐसे हमलों का उपयोग DNS प्रवर्धन के लिए किया जाता है, जब हमलावर पीड़ित की ओर से एक छोटा अनुरोध भेजता है, और पीड़ित को एक बड़ी प्रतिक्रिया मिलती है कि उसने अनुरोध नहीं किया था। यह एक क्लासिक चैनल थकावट का हमला तंत्र है।
मेरे मामले में, हमलावर ने पीड़ित सर्वर के चैनल को समाप्त करने के लिए सेट नहीं किया था। इसकी गतिविधि चैनल के खपत ग्राफ़ पर पूरी तरह से अदृश्य थी। इसका मुख्य लक्ष्य नेटवर्क हमलों की स्वचालित अधिसूचना की प्रणालियों को भड़काना था जो कि मेरे प्रदाता के व्हाट्सएप सबनेट में निर्दिष्ट दुरुपयोग पते की शिकायत करने वाला एक पत्र भेजेगा।
इंट्रोसिव प्रिवेंट / डिटेक्ट सिस्टम जैसे कि
स्नॉर्ट और
सुरिकटा यह कर सकते हैं ।
नतीजतन, होस्टर को वैध कंपनियों से एक बिल्कुल वास्तविक पत्र प्राप्त होता है, जिसमें मेरी दुर्भावनापूर्ण गतिविधि और यहां तक कि वास्तविक लॉग के बारे में शिकायत होती है। उसी समय, हमलावर को एक बड़े चैनल की आवश्यकता नहीं होती है, क्योंकि वह उन सर्वरों के पते को पहले से जानता है, जिन पर आईडीएस / आईपीएस सिस्टम स्थापित हैं और काम करने के लिए स्वचालित शिकायत के लिए न्यूनतम आवश्यक संख्या में पैकेट हैं।
एक हमलावर के लिए एकमात्र कठिनाई एक सर्वर ढूंढना है जो पैकेट में आउटगोइंग आईपी पते के प्रतिस्थापन की अनुमति देता है। सभी सामान्य होस्टर्स ऐसे पैकेट्स को ब्लॉक कर देते हैं। केवल दो प्रकार की होस्टिंग हैं, जो क्लाइंट को आउटगोइंग आईपी को बदलने की अनुमति देता है: या तो बहुत अनपढ़ कॉन्फ़िगर किया गया है, या विशेष रूप से साइबर अपराध के लिए बनाया गया है।
आईपी पते के स्पूफिंग की संभावना की जांच करना
मैं आपको सलाह देता हूं कि आउटगोइंग आईपी को बदलने की संभावना के लिए अपने होस्ट की जांच करें। इसके लिए दो सर्वरों की आवश्यकता होगी, एक यातायात प्राप्त करने के लिए, दूसरा भेजने के लिए।
सर्वर की ओर से प्राप्त होने पर, हम आने वाले ट्रैफ़िक को लॉग करना शुरू कर देंगे। हम एक दुर्लभ पोर्ट को एक फिल्टर के रूप में निर्दिष्ट करते हैं जिस पर सामान्य समय में कोई ट्रैफ़िक नहीं होना चाहिए:
tcpdump -i any port 9912
जिस सर्वर पर हम परीक्षण कर रहे हैं, हम आउटगोइंग आईपी एड्रेस के
1.1.1.1 के प्रतिस्थापन के साथ एक पैकेज उत्पन्न करेंगे, जिसे 9912 पोर्ट के लिए निर्देशित किया जाएगा। इसके लिए हम
नैम डेवलपर्स से कूल यूटिलिटी
नैपिंग का उपयोग करते हैं। यह आपको L2 और L3 स्तर पर किसी भी गैर-मानक पैकेज को उत्पन्न करने की अनुमति देता है।
nping --tcp -p 9912 -S 1.1.1.1 receiver-server.com
रिसीवर-server.com - सुनने वाले सर्वर का पता tcpdump चल रहा है
१.१.१.१ - स्थानापन्न निवर्तमान पता
9912 - रिमोट पोर्ट
यदि रिसीवर-server.com की ओर से आपको एक पैकेट दिखाई देता है जो 1.1.1.1 की ओर से आया है, तो आपका प्रदाता आपको आउटगोइंग आईपी पते को बदलने की अनुमति देता है। यह नेटवर्क उपकरण स्थापित करने में समस्याओं के बारे में सूचित करने का एक अवसर है। अक्सर यह समस्या घर के इंटरनेट सेवा प्रदाताओं द्वारा प्रभावित होती है।
बेवकूफ तकनीक का समर्थन
शिकायतों के कारणों का पता लगाने के बाद, मैंने छात्रावास के लिए सब कुछ विस्तृत किया:
हैलो,
मैं आखिरकार समझ गया कि क्या हुआ।
वे स्रोत पते के रूप में मेरे पते का उपयोग करके मेरे आईपी पते और डीडीओएस यादृच्छिक होस्ट को खराब करते हैं। इसलिए पीड़ित मेरे होस्टिंग प्रदाताओं को स्वत: दुर्व्यवहार की रिपोर्ट उत्पन्न करते हैं।
आप दुर्व्यवहार लॉग पर देख सकते हैं कि कनेक्शन केवल SYN_RECV राज्य (पूर्ण टीसीपी-कनेक्शन स्थापित नहीं) में हैं क्योंकि वे स्पूफ किए गए आईपी का उपयोग करके केवल एक पैकेट भेज सकते हैं और टीसीपी-हैंडशेक को समाप्त नहीं कर सकते।
मैं यह साबित कर सकता हूं। मेजबानों से मेरे सर्वर पर अभी कई टीसीपी आरएसटी आने वाले पैकेट हैं जिन्हें मैंने कभी कोई पैकेट नहीं भेजा।
आप इसे अभी चलाकर देख सकते हैं:
tcpdump -i eth0 "tcp [tcpflags] & (tcp-rst)! =" "!
आप देखेंगे कि कई RST पैकेट मेजबानों से आए हैं जिनमें से मैंने कभी कोई डेटा नहीं भेजा है।
यह साबित करता है कि हमलावर मुझसे समझौता करने और गालियां देने के लिए मेरा आईपी-पता खराब कर रहा है।
तब मुझे ऐसा लगा कि कोई भी योग्य तकनीकी सहायता इंजीनियर स्थिति को समझेगा और सवाल बंद हो जाएगा। लेकिन इसके बजाय, उन्होंने मांग की कि मैं एंटीवायरस सॉफ़्टवेयर के साथ सर्वर की जांच करता हूं या ओएस को पूरी तरह से पुनर्स्थापित करता हूं। जब हमने तकनीकी सहायता से संपर्क किया, तो गालियाँ आती रहीं और एक दिन में मुझे प्रतिबंधित कर दिया गया।
यह बेतहाशा अपमानजनक था कि मुझे वास्तव में फंसाया गया था। यह स्थिति दिखाती है कि लोग कितने कमजोर हैं, जो समझने के बजाय, विचारपूर्वक स्क्रिप्ट का अनुसरण करते हैं। तब से, मैं अक्सर इस मामले को एक उदाहरण के रूप में उद्धृत करता हूं जब महत्वपूर्ण परियोजनाओं के लिए होस्टिंग चुनने के बारे में बहस सामने आती है। दुर्भाग्य से, कई होस्टिंग कंपनियां केवल छोटे ग्राहकों के गैर-मानक मामलों में ज्यादा समय नहीं दे सकती हैं और आपकी समस्याओं को हल करने की तुलना में आपको प्रतिबंधित करना आसान है।
हमारे Instagram डेवलपर की सदस्यता लें
