التحقق من افتراضات الشبكة بشكل قابل للتكرار

يستخدم هذا المشروع Ansible لإنشاء ملفات اختبار BATS للتحقق من افتراضات الأمان حول البنية التحتية للشبكة. يتم تشغيل الاختبارات من أجهزة الفحص ("عُقد الفاحص") حيث يتم نشر Prober.

هذه الأداة مخصصة للاختبار الآلي القابل للتكرار للشبكات الخاصة. تدعم تشغيل اختبارات متعددة على عُقد فاحصة، كل منها له رؤية مختلفة للشبكة المفحوصة — على سبيل المثال، رؤية من المنطقة الخارجية، ومن المنطقة الداخلية، ورؤية من داخل DMZ.

قد يكون استخدام Prober لفحص شبكات غير مخول لك أمرًا غير قانوني.

المتطلبات

على جهاز Ansible الرئيسي المستخدم لنشر الاختبارات إلى عُقد الفاحص:

• ansible (بالطبع!)
• python*-netaddr (على GNU/Linux) / py*-netaddr (على FreeBSD)

على عُقد الفاحص نفسها:

• bash
• ssh
• nmap
• dig/kdig
• testssl
• وأي تبعيات أخرى يتم تثبيتها بواسطة دور Ansible.

على النظام الذي تراجع فيه النتائج (ملفات *.tap)، قد ترغب في تثبيت tappy. يتم الاحتفاظ بالنتائج على كل عقدة فاحصة، في مستودعات git محلية (افتراضيًا، في /var/run/prober/results/، راجع أدناه لخيارات التهيئة)، مع علامات commits بتاريخ انتهاء كل جولة فحص، للسجل التاريخي وسهولة المقارنة.

التشغيل

يستخدم Ansible لإنشاء اختبارات على عُقد الفاحص. يمكن أن تكون عقدة الفاحص أي مضيف FreeBSD أو GNU/Linux، طالما أنه من الممكن تثبيت تبعيات Prober. لا يلزم تخصيصها للاختبار، لكن يُوصى بذلك — فمسح شبكة بحجم معقول سيستغرق ساعات، ويستهلك الكثير من وحدة المعالجة المركزية، ويُولِّد قدرًا كبيرًا من حركة المرور.

من المنطقي نشر Prober على عدد من الأجهزة المختلفة للتحقق من شكل شبكتك من وجهات نظر مختلفة (على سبيل المثال: الشبكة الداخلية، DMZ، الإنترنت).

في دليل الاختبار على عُقد الفاحص، يتم إنشاء سكريبت run-tests.sh لتسهيل تشغيل الاختبارات. يتم تشغيل الاختبارات بطريقة تضمن تشغيل <simultaneous_tests_count> اختبار في وقت واحد في جميع الأوقات — هذا المتغير هو الطريقة الرئيسية للتحكم في كمية الموارد التي يستخدمها مسح الفحص ومقدار النطاق الترددي الذي يحتاجه.

ثم يتم حفظ نتائج الاختبار في مستودع git محلي، مع علامات commits بتاريخ انتهاء الجولة المحددة (قد يختلف عن تاريخ البدء لبعض جولات الفحص الطويلة).

إذا كنت تتعامل مع بنية تحتية أكبر من مجرد عدد قليل من المضيفين، فقد يكون من المنطقي استخدام أداة مثل Mitogen لتسريع إنشاء الاختبارات بشكل كبير.

البدء السريع

1. جهز خادم Debian أو FreeBSD لاستخدامه كعقدة فاحصة (لنسمها prober.example.com)، تأكد من أن لديك وصول SSH إليه ويمكنك تنفيذ sudo عليه.

2. انسخ مثال الجرد باسم inventories/test/.

3. في ذلك test inventory:

   1. عدّل group_vars/all.yml واضبط zone_nameserver و zone_domains و address_blocks حسب رغبتك؛ لنفترض أنك أضفت example.com كالنطاق الوحيد الذي سيتم فحصه
   2. عدّل ملف hosts، مهيئًا عقدة الفاحص prober.example.com في القسم [prober-nodes]؛ لنقل أنك ضبطت tested_zone على .

يمكنك الآن استخدام ssh للدخول إلى عقدة الفاحص وتفقد الاختبارات التي تم إنشاؤها في /opt/prober/. بمجرد أن تكون راضيًا، يمكنك تشغيلها بتنفيذ: /opt/prober/run_tests.sh. سيتم حفظ النتائج في /var/run/prober/results.

التهيئة

متغيرات التهيئة (المعرفة في probers.yml):

• tests_directory (الافتراضي: /opt/prober):
  الدليل على عُقد الفاحص حيث يتم إنشاء ملفات الاختبار (ملفات *.bats).

• results_repo_directory (الافتراضي: /var/run/prober/results) دليل المستودع لنتائج الاختبار (ملفات *.tap); يتم تهيئة مستودع git هناك وإنشاء دليل فرعي tap/ للنتائج الفعلية; يتم إيداع النتائج في مستودع git، ويتم وضع علامات على الإيداعات بتاريخ بتنسيق yyyy-mm-dd (مثلاً، الإيداع الذي يحتوي على نتائج اختبار انتهى في 19 مارس 2020 يُوسم بـ 2020-03-19).

• simultaneous_tests_count (الافتراضي: 20):
  عدد الاختبارات التي يتم تشغيلها في وقت واحد.

• prober_dev (الافتراضي: ): تخطي بعض المهام التي لا معنى لها على جهاز التطوير (مثل إعداد أو ).

المناطق

يتم تعريف المناطق في ملفات ./data/<zone_name>.yml حيث يكون المفتاح الأعلى هو السلسلة "tested_zone_settings"، والتي تحتوي بعد ذلك على مفاتيح:

• name: اسم المنطقة، مطابق لاسم الملف (بدون امتداد); على سبيل المثال: "internal", "external", "dmz"
• default (اختياري): الإعدادات الافتراضية لجميع المضيفين في هذه المنطقة
• مفاتيح تعبير عادي (تبدأ بالضرورة بحرف "^") تطابق أسماء FQDN متعددة
• مفتاح لكل FQDN يحتاج إلى تهيئة صريحة

المفتاح default، وكل مفتاح تعبير عادي، وكل مفتاح نطاق بدوره يمكن أن يحتوي على هذه المفاتيح:

• resolve: هل يجب أن يحل المضيف إلى عنوان IP ذي الصلة (قيمة منطقية true/false، أو السلسلة "skip")
• ping: هل يجب أن يستجيب المضيف لـ ping (قيمة منطقية true/false، أو السلسلة "skip")
• ports: قائمة بمنافذ TCP و UDP المسموح بفتحها (المفاتيح الفرعية "tcp" و "udp"، يحتوي كل منها على مصفوفة من الأعداد الصحيحة التي تحدد المنافذ المسموح بفتحها، أو السلسلة "skip")، ومنافذ TLS الممكّنة لإجراء فحص أعمق عليها (المفتاح الفرعي tls، يحتوي على قاموس بأرقام المنافذ كمفاتيح، ونوع خدمة TLS أو الكلمة "skip" كقيمة) هو اختصار لـ: أنواع خدمات TLS هي ما يدعمه لخيار ، و لاختبار HTTPS (بما في ذلك الترويسات)، أو "" لاختبار TLS العام. : لا يتم تشغيل اختبارات TLS ما لم يتم أيضًا وضع علامة على المنفذ كمفتوح في المفتاح "".

يمكنك رؤية مثال التهيئة هنا.

يتم تعريف الإعدادات الافتراضية العامة في probers.yml. لكل مضيف مفحوص، يتم بعد ذلك دمجها مع الإعدادات الافتراضية للمنطقة ذات الصلة، ثم مع مفاتيح التعبير العادية التي تطابق اسم المضيف المحدد، وأخيرًا مع إعدادات المضيف المحددة.

هذا يعني أن إعدادات المضيف المحددة في منطقة معينة لها أولوية على الإعدادات من مفاتيح التعبير العادية المطابقة، والتي بدورها تسبق الإعدادات الافتراضية للمنطقة، والتي بدورها تسبق الإعدادات الافتراضية العامة.

يتم التعامل مع المفتاح ports بطريقة خاصة بعض الشيء: إذا تم إدراج منافذ معينة في مكان ما في سلسلة توارث التهيئة، فمن المستحيل إلغاء إدراجها في الأسفل في السلسلة، فقط إضافة أرقام منافذ إضافية، أو اختيار "skip" لاختبارات جميع منافذ بروتوكول معين بشكل كامل.

يتم تحديد ملفات المنطقة بناءً على المتغير tested_zone المضبوط لكل عقدة فاحصة.

اختبارات لكل-IP مقابل اختبارات لكل-اسم مضيف

بعض الاختبارات منطقية في سياق عناوين IP الفردية، بغض النظر عن عدد النطاقات/أسماء المضيفين التي تحلها لها; على سبيل المثال، التحقق مما إذا كانت منافذ معينة مفتوحة. على سبيل المثال، لنفترض أن a.example.com و b.example.com يشيران إلى نفس عنوان IP. مع التهيئة من المثال أعلاه، يعني ذلك أن المنفذين 8080/tcp و 8443/tcp من المفترض أن يكونا مفتوحين، وأن HTTPS متوقع على المنفذ 8443/tcp.

بعض الاختبارات منطقية في سياق مجموعات نطاق/اسم مضيف معين وعنوان IP; على سبيل المثال، إذا كانت شهادة TLS المقدمة لاسم نطاق معين على عنوان IP معين صالحة.

يتم تنفيذ هذين النوعين من الاختبارات عن طريق إنشاء قائمتين منفصلتين من الأهداف:

• قائمة لكل-IP، حيث يكون كل عنصر من الشكل:
  <ip-address> <hostname1> (<hostname2> <hostname3> ... <hostnameN>)
  لا يجب أن تتكرر عناوين IP في هذه القائمة;
• قائمة لكل-اسم مضيف، حيث يكون كل عنصر من الشكل:
  <ip-address> <hostname>
  يمكن توقع تكرار عناوين IP في هذه القائمة.

يتم بعد ذلك إنشاء بعض ملفات الاختبار فقط للأهداف من القائمة الأولى (على سبيل المثال، اختبار المنافذ المفتوحة)، والبعض الآخر فقط للأهداف من القائمة الثانية (على سبيل المثال، المتعلقة بـ TLS).

المنافذ والاختبارات

بعض الاختبارات لا معنى لها إذا كانت منافذ معينة غير مفتوحة. يتم إنشاء الاختبارات المتعلقة بـ TLS لمضيف معين فقط إذا تم تهيئة أي منافذ TCP ذات صلة كمفتوحة في المنطقة المحددة.

افتراضيًا، إذا تم تكوين أي من المنافذ المعروفة الممكّنة لـ TLS كمفتوحة في المفتاح ports.tcp، سيتم إنشاء اختبارات TLS لها. يتم تحديد قائمة المنافذ المعروفة الممكّنة لـ TLS في المتغير default_host_settings.

الأسئلة الشائعة

بشكل عام، الفرق بين Prober والعديد من الأدوات أو الخدمات المماثلة الأخرى يتلخص عادةً في مجموعة من:

• كونه مستضافًا ذاتيًا، مع إمكانية نشر عُقد Prober في أي مكان داخل أو خارج بنيتك التحتية;
• التركيز على عمليات الفحص المنتظمة والقابلة للتكرار التي تتحقق من افتراضات محددة جيدًا وقابلة للتهيئة;
• منحك التحكم في جدول جولات الاختبار، والوصول إلى نتائج الفحص الخام.

كيف يختلف هذا عن Shodan؟

Shodan يزحف على الإنترنت للعثور على الأنظمة المكشوفة. Prober يزحف على بنيتك التحتية الخاصة للتحقق من افتراضاتك حولها، من عدد لا يحصى من وجهات النظر التي تحتاجها. يركز على قابلية تكرار النتائج عبر اختبارات محددة جيدًا وجولات منتظمة مجدولة، ويحاول تقديم نتيجة منطقية "نجاح/فشل" لكل من الافتراضات المختبرة (مع توفر بيانات نتيجة الفحص الكاملة للتدقيق).

كيف يختلف هذا عن BitSight؟

BitSight تتحقق من فكرتها عن الافتراضات المعقولة حول بنيتك التحتية، دون منحك التحكم في أو معلومات حول متى سيتم إجراء الفحص بالضبط، ولا توفر بيانات الفحص الخام. Prober يتحقق من افتراضاتك حول بنيتك التحتية، ويقوم بذلك وفقًا لجدولك الزمني، ويوفر بيانات الفحص الخام الكاملة للتدقيق.

كيف يختلف هذا عن Natlas؟

يبدو أن Natlas أقرب إلى Shodan (الزحف للعثور على المضيفين المكشوفين، وعرض النتائج استجابةً للاستعلامات)، ولكن مع القدرة على الاستضافة الذاتية (وبالتالي أيضًا تشغيل وكيل Natlas في مواقع مختلفة داخل وخارج بنيتك التحتية، مثل عُقد Prober). يقوم Prober بإجراء فحوصات منتظمة لبنيتك التحتية للتحقق من افتراضاتك الخاصة حولها، كما هو معبر عنه في التهيئة.

أسئلة كبيرة

• التبديل إلى نظام اختبار أكثر قوة؟
  • لدى BATS قيود مزعجة، على سبيل المثال: لا توجد طريقة لإجراء اختبار شرطي ("إذا فشل الاختبار A فتخط الاختبار B"، إلخ)
  • التخلي عن نظام الاختبار بالكامل؟
    • https://docs.ansible.com/ansible/latest/reference_appendices/test_strategies.html
    • https://github.com/benwebber/ansible-tap
• من المستحيل إكمال فحوصات الكتلة الكاملة لـ IPv6 خلال ألف عام
  • توفير طريقة لتكوين الاستدلال لاختيار عناوين IP للمسح (عشوائي، البدء من الأسفل بـ "خطوة" مهيأة، إلخ)؟

شكر وتقدير

الشعار مبني على Magnifying Glass by verry obito, ID; CC-By و Network by Creative Stall, PK; CC-By، عبر The Noun Project.