अप्रबंधित नेटवर्क स्थान खोज

मैं एक समस्या के समाधान को प्रदर्शित करना चाहता हूं जो कि अधिकांश "नेटवर्कर" सिद्धांत रूप में असंभव मानते हैं। यह एक अप्रबंधित नेटवर्क में एक मेजबान के भौतिक स्थान की गणना करने के बारे में है। एक मानव रहित नेटवर्क मानव रहित स्विच पर एक नेटवर्क है, और एक स्थान उत्तर है:

"ऐसा और ऐसा होस्ट यहां स्थित स्विच से जुड़ा है"

मैं तुरंत इनपुट शर्तों को पूरा करूंगा:

- मैं एक प्रशासक हूं, अर्थात, मैं नेटवर्क टोपोलॉजी जानता हूं;
- मेरे पास सब्सक्राइबर्स का एक डेटाबेस है, जिनके कनेक्शन पॉइंट्स मुझे ज्ञात हैं।

नेटवर्क टोपोलॉजी का उल्लंघन, साथ ही ग्राहकों द्वारा धोखाधड़ी (आईपी एक्सचेंज, कनेक्शन बिंदु का परिवर्तन) कुछ हद तक परिणाम की सटीकता को कम करता है। हालांकि, मैं नियमित रूप से अपने नेटवर्क पर इस एल्गोरिथ्म का उपयोग करता हूं और यह काफी सटीक डेटा दिखाता है।

कठिनाई क्या है?

एक अनवांटेड नेटवर्क एक ब्लैक बॉक्स है, कोई भी ईथरनेट फ्रेम जो आपके पास आता है उसके पास कोई जानकारी नहीं होती है कि वह किस स्विच से गुजरता है। एक मानवरहित स्विच एक पारदर्शी उपकरण है, यह किसी भी तरह से फ्रेम को नहीं बदलता है, यह केवल उन्हें आवश्यक बंदरगाहों (उनकी राय में) के लिए निर्देशित करता है।

इस प्रकार, हम ईथरनेट फ्रेम से या स्विच से पथ के बारे में जानकारी प्राप्त नहीं कर सकते हैं।

वास्तव में, यह पूरी तरह सच नहीं है। हम स्विच से जानकारी का अनुरोध नहीं कर सकते, लेकिन हमारे पास उनके व्यवहार को बदलने और परिणाम का विश्लेषण करने का अवसर है।

जैसा कि आप जानते हैं, प्रत्येक अप्रबंधित स्विच में मैक-पोर्ट मैपिंग टेबल है। यह तालिका प्रत्येक आने वाले फ्रेम द्वारा एक बहुत ही सरल एल्गोरिथ्म के अनुसार अपडेट की जाती है: जो फ्रेम में आया था, वर्तमान फ्रेम के src-mac क्षेत्र से मैक एड्रेस उस पोर्ट से जुड़ा हुआ है। भविष्य में, dst-mac के साथ किसी भी आने वाले फ्रेम जैसे वर्तमान को इस मैक के साथ जुड़े पोर्ट पर सख्ती से भेजा जाएगा।

प्रक्रिया में, मैक एड्रेस टेबल बदल सकती है यदि एक ही src-mac के साथ एक फ्रेम एक अलग पोर्ट में प्रवेश करता है। इस मामले में, पुरानी जानकारी "भूल" है। आमतौर पर, यह स्थिति तब होती है जब आप केबल को फिर से कनेक्ट करते हैं। डिटेक्शन एल्गोरिथ्म इस "फीचर" पर आधारित है।

मैं सिद्धांत को बाहर नहीं खींचूंगा और इसे लाऊंगा।

So. हमारे पास स्विच की एक बेकाबू माला है (छोटे घरेलू नेटवर्क की कठोर वास्तविकता), हम शाखाओं में से एक का चयन करते हैं। इस धागे के अंत में, किसी भी ग्राहक का चयन करें। मैं उसे एजेंट कहता हूं। यह एक महत्वपूर्ण भूमिका निभाता है - एक अज्ञात होस्ट (लिपियों में मैं इसे हैकर कहता हूं) की खोज सर्वर-एजेंट साइट पर होगी। इस प्रकार, एक एजेंट के रूप में सबसे दूरस्थ ग्राहक चुनना वांछनीय है।

Iteration शुरू होता है:

1) अर्प-अनुरोधों का अनुरोध किया जाता है आईपी एजेंट और आईपी हैकर। आईपी ​​विभिन्न तार्किक सबनेट में हो सकता है, हमारे लिए यह महत्वपूर्ण नहीं है। महत्वपूर्ण बात है
कि arp-request द्वारा हम नेटवर्क को उसकी सामान्य स्थिति में "ट्रांसलेट" करते हैं, क्योंकि भविष्य में हम इसे थोड़ा अस्थिर कर देंगे।

2) हम किसी भी ग्राहक के आधार से लेते हैं, जिस स्थान को हम जानते हैं। मैं उसे उपयोगकर्ता कहता हूं। हम arp-request भेजकर ईथरनेट स्पूफिंग करते हैं:

src-mac - हैकर मैक
src-ip - इससे कोई फर्क नहीं पड़ता (आप हैकर या नकली आईपी)
dst-mac - उपयोगकर्ता मैक
dst-ip - उपयोगकर्ता आईपी (आप नकली आईपी कर सकते हैं)

इस पैकेज का उद्देश्य हैकर पॉपी के साथ सर्वर से उपयोगकर्ता तक स्विच की श्रृंखला में बंदरगाहों (मैक पते की तालिका को बदलना) को "रिप्रोग्राम" करना है। यदि कोई "रिप्रोग्राम किए गए" अनुभाग में हैकर के मैक को नेटवर्क पर पैकेट भेजता है, तो यह हमारे सर्वर द्वारा प्राप्त किया जाएगा, न कि हैकर द्वारा।

3) Arp-request एजेंट को भेजा जाता है:

src-mac - हैकर मैक
src-ip - यह महत्वपूर्ण नहीं है (आप हैकर या नकली आईपी का उपयोग कर सकते हैं, यह महत्वपूर्ण है कि एजेंट का सबनेट)
dst-mac - एजेंट मैक
dst-ip - एजेंट आईपी

इस पैकेज के साथ, हम एजेंट को अर्प-रिक्वेस्ट का जवाब देने के लिए बाध्य करते हैं, जो कथित तौर पर हैकर से आया था।

नोट करने के लिए एक बहुत ही महत्वपूर्ण बिंदु: प्रोटोकॉल इनकैप्सुलेशन। तथ्य यह है कि एक arp अनुरोध का अपना डेटा है, लेकिन यह एक ईथरनेट फ्रेम में "पैक" है जिसका अपना डेटा है। विशेष रूप से, आर्क-अनुरोध के मानक उपयोग के साथ src-mac, जो arp पैकेट में है, कि ईथरनेट फ्रेम में समान हैं। पिछले पैकेज के विपरीत, हमें एआरपी स्पूफिंग को लागू करने की आवश्यकता है, लेकिन ईथरनेट नहीं! यानी ईथरनेट फ्रेम में src-mac हमारा सर्वर होना चाहिए, और arp पैकेज src-mac = हैकर मैक में। यदि यह स्थिति पूरी होती है, तो वे स्विच जिनके माध्यम से फ्रेम पास होता है, उनके मैक एड्रेस टेबल को नहीं बदलेगा।

4) सर्वर पर, हम प्रोमिसस मोड में जाते हैं (अर्थात, हम उन पैकेट्स को नहीं छोड़ते हैं जो हमारे पास जाते हैं, लेकिन हमारे पते पर नहीं हैं) और arp-reply की निगरानी करते हैं।
हैं:
a) हम हैकर मैक को निर्देशित पैकेट प्राप्त करते हैं - इसका मतलब है कि भौगोलिक रूप से हैकर उपयोगकर्ता और सर्वर के बीच है
b) हम प्राप्त नहीं करते हैं - शायद हैकर उपयोगकर्ता के पीछे है

दूसरे मामले में कोई पूर्ण गारंटी नहीं है, इसलिए संभावना बढ़ाने के लिए कई बार सभी बिंदुओं को दोहराना आवश्यक है, और अन्य ग्राहकों पर परीक्षण करते समय डेटा को भी ध्यान में रखना चाहिए।

आकृति में, हमारे पास 4 स्विच की एक श्रृंखला है। लाल रेखा चरण 2 में पैकेट के पथ को इंगित करती है। परिणामस्वरूप, तालिका को सर्वर के निकटतम स्विच की पॉप-अप तालिका के साथ "पुन: क्रमित" किया जाएगा, ताकि उसे लगे कि "हैकर पोर्ट नंबर 1 से जुड़ा है"। कोई अन्य स्विच उनके राज्य को नहीं बदलेगा क्योंकि पैकेट उनके पास से नहीं गुजरेगा।

सर्वर -> एजेंट के अनुरोध (आइटम 3) के बाद, बाद वाले को हैकर के पोस्ता की प्रतिक्रिया भेजता है क्योंकि src-mac को अधिगृहीत किया गया है। चूंकि सभी स्विच ने हैकर-एजेंट अनुभाग पर अपना राज्य नहीं बदला, इसलिए पैकेट आसानी से हैकर तक पहुंच जाएगा।


उस स्थिति में जब उपयोगकर्ता हैकर-एजेंट साइट पर होता है, एजेंट की प्रतिक्रिया सर्वर पर आएगी:


5) चरण 1 पर जाएं और अगले उपयोगकर्ता का चयन करें

परीक्षण के अंत में, हमारे पास एक तालिका है: उपयोगकर्ता - एजेंट से प्रतिक्रिया प्राप्त / प्राप्त नहीं हुई है। यदि आप डेटा को कार्ड पर डालते हैं (और मेरी स्क्रिप्ट करता है), तो व्यवस्थापक छोटे विचलन (आमतौर पर वे नहीं हैं) को तुरंत समाप्त कर देता है और एक बहुत सटीक परिणाम प्राप्त करता है: हैकर प्राप्त किए गए ब्लॉकों के जंक्शन पर होता है / जवाब नहीं मिला।

मैंने यहां जो कुछ भी वर्णित किया है, मैं दोहराता हूं, मैंने व्यवहार में लागू किया है: स्क्रिप्ट्स पर्ल में लिखे गए हैं (नेट :: पैकेट का उपयोग करें; नेट का उपयोग करें: पैकेट :: डंप;)।