tls-attacker/tls-scannerماسح ضوئي آلي لتكوين خادم وعميل TLS لاختبار الاختراق والباحثين. يقوم بتقييم مجموعات التشفير وإصدارات البروتوكول وإرشادات الأمان مع عمق مسح قابل للتخصيص ومخرجات قابلة للقراءة آليًا.
# TLS-Scanner
[](https://hydrogen.cloud.nds.rub.de/job/TLS-Scanner/)
TLS-Scanner هي أداة لمساعدة مختبري الاختراق والباحثين الأمنيين في تقييم إعدادات خادم وعميل TLS.
**يرجى الملاحظة:** *TLS-Scanner هي أداة بحثية موجهة لمطوري TLS ومختبري الاختراق والمسؤولين والباحثين. لا توجد واجهة رسومية. إنها في الإصدار الأول وقد تحتوي على بعض الأخطاء.*
# الترجمة (Compiling)
من أجل ترجمة واستخدام TLS-Scanner، تحتاج إلى تشغيل:
```bash
$ cd TLS-Scanner
$ git submodule update --init --recursive
$ mvn clean package
```
بدلاً من ذلك، إذا كنت في عجلة من أمرك، يمكنك تخطي الاختبارات باستخدام:
```bash
$ mvn clean package -DskipTests=true
```
إذا كنت تريد استخدام TLS-Scanner كمكتبة، فأنت بحاجة إلى تثبيتها بالأمر التالي:
```bash
$ mvn clean install
```
# التشغيل
من أجل تشغيل TLS-Scanner، تحتاج إلى تشغيل أحد ملفات jar في مجلد apps/.
يمكن الحصول عليها عن طريق ترجمة التطبيق بنفسك أو عن طريق
[تنزيل ملفات jar المنشورة من GitHub](https://github.com/tls-attacker/TLS-Scanner/releases).
```bash
$ java -jar apps/TLS-Server-Scanner.jar -connect localhost:4433
```
سيقوم TLS-Scanner بتقييم الخادم المحدد (هنا `localhost` على المنفذ `4433`)، وفي النهاية سيطبع تقريرًا.
يستخدم التقرير الألوان لنقل خطورة النتائج:
- الأخضر: نتيجة جيدة.
- الأصفر: تحذير، قد يكون مشكلة محتملة.
- خلفية صفراء: نتائج يكون فيها الماسح غير متأكد مما إذا كان الهدف عرضة للثغرات.
- الأحمر: مشكلة خطيرة، يجب إصلاحها.
- اللون الافتراضي (حسب الطرفية الخاصة بك، على الأرجح أسود أو أبيض): نتيجة محايدة، ليست جيدة ولا سيئة. يتضمن ذلك النتائج المعلوماتية.
- الأزرق: لم يتمكن الماسح من فحص الخادم لهذا الاختبار المحدد. من المحتمل أن يكون ذلك بسبب عدم دعم متطلب أساسي لهذا الاختبار.
- الأرجواني: واجه الماسح خطأ أثناء فحص الخادم لهذا الاختبار المحدد. يمكن أن يكون ذلك نتيجة لخطأ في الماسح، ولكن أيضًا بسبب عدم دعم الخادم لميزة مطلوبة.
- السماوي: يُستخدم لتنظيم التقرير (العناوين، ...).
## المعلمات المهمة
يجب عليك تحديد المضيف الذي تريد فحصه باستخدام المعلمة -connect.
إذا كنت تريد تحسين أداء الفحص، يمكنك استخدام المعلمة `-threads` لزيادة عدد الخيوط المستخدمة.
معلمة مهمة أخرى لأسباب تتعلق بالأداء هي المعلمة `-scanDetail`، والتي يمكن استخدامها لتكوين مدى التفصيل الذي تريد الفحص به. القيم الممكنة التي تتراوح من سريع إلى مفصل جدًا هي: QUICK، NORMAL، DETAILED، ALL.
يمكن تكوين تفصيل المخرجات باستخدام المعلمة `-reportDetail`. من أجل رؤية مزيد من التفاصيل حول الإرشادات، استخدم `-reportDetail ALL`.
بشكل افتراضي، تُكتب النتائج إلى الطرفية فقط. إذا كنت تريد مخرجات قابلة للقراءة آليًا، يمكنك استخدام `-outputFile output.json` لكتابة النتائج تلقائيًا في ملف JSON.
## حالات الاستخدام
أهم المعلمات التي يجب تغييرها هي `-scanDetail` و `-reportDetail`. فيما يلي، نشرح بعض حالات الاستخدام لهذه المعلمات.
### الفحص الافتراضي
في معظم الحالات، تكون إعدادات المعلمات الافتراضية لدينا كافية. يقوم هذا بإجراء فحص مع ضبط كلا مستويي التفصيل على `NORMAL`.
### الفحص السريع
إذا كنت تريد إجراء فحص سريع والحصول على نظرة عامة سريعة على نظامك، فإننا نوصي بضبط كلا مستويي التفصيل على `QUICK`. يحد هذا من مدى بعض الفحوصات المنفذة لتقليل وقت التشغيل ويحد من تفصيل التقرير لعدم تضمين معلومات مفصلة جدًا وتقنية.
### الفحص المفصل
إذا كنت تريد تقييم نظامك بالكامل وتنفيذ كل ما لدينا، فإننا نوصي بضبط كلا مستويي التفصيل على `ALL`. يقوم هذا بتنفيذ جميع الفحوصات الموجودة بالكامل ويطبع معلومات مفصلة جدًا لمزيد من التحليل والتقييم.
## ملفات تعريف الفحص (Scan Profiles)
بدلاً من (أو بالإضافة إلى) ضبط معلمات مثل `-scanDetail` بشكل فردي، يمكنك تجميع
الفحوصات التي تريد تشغيلها وأي من هذه المعلمات تريد استخدامها في ملف تعريف فحص JSON قابل لإعادة الاستخدام
باستخدام المعلمة `-profile <path/to/profile.json>`. وهي متاحة على كل من `TlsServerScanner` و
`TlsClientScanner`.
ملف التعريف هو ملف JSON يحتوي على:
- `inheritedFromProfiles`: مسارات لملفات تعريف أخرى لدمج الفحوصات منها، يتم حلها نسبةً إلى
دليل ملف التعريف الذي يعلن عنها (يُستخدم المسار المطلق كما هو).
- `probes`: الفحوصات التي يجب تشغيلها، كخريطة من الاسم المؤهل بالكامل لفئة تعداد `ProbeType`
إلى قائمة أسماء ثوابتها التي يجب تشغيلها. يقوم هذا بتجميع الفحوصات حسب النوع بدلاً من تكرار
النوع لكل فحص على حدة، بينما لا يزال بإمكان ملف تعريف واحد دمج الفحوصات بحرية من
تطبيقات `ProbeType` مختلفة، مثل `TlsProbeType` و `QuicProbeType`. تقبل كل قائمة
لكل نوع أيضًا `"*"` (جميع ثوابت ذلك النوع) و `"!CONSTANT_NAME"` (إزالة ثابت
تمت إضافته سابقًا بالاسم أو بواسطة `"*"`)، وتتم معالجتها بالترتيب — راجع `Everything.json` و
`demo.json` في [`scan-profiles/`](https://github.com/tls-attacker/tls-scanner/blob/main/scan-profiles) للحصول على أمثلة.
- `settings` (اختياري): تجاوزات لمعلمات مثل `-scanDetail`، `-reportDetail`،
`-postAnalysisDetail`، `-noColor`، `-outputFile`، `-probeTimeout`، `-parallelProbes`، و
`-threads`. أي حقل يتم تركه يحتفظ بقيمته الافتراضية العادية (أو أي قيمة تم تمريرها على سطر
الأوامر). **على عكس `probes`، لا يتم توريث `settings`** — فقط الإعدادات المعلنة مباشرة على
ملف التعريف الذي تشير إليه `-profile` هي التي تُطبق، حتى لو كان يورث الفحوصات من ملفات تعريف أخرى.
يتم تنفيذ فقط الفحوصات التي تم حلها من ملف التعريف النشط (وكل ما يورثه منه)؛
يتم تخطي كل شيء آخر.
مثال، يجمع بين فحوصات ملف تعريف أساسي وفحوصاتك الخاصة ويضبط تفصيل الفحص:
`base.json`:
```json
{
"probes": {
"de.rub.nds.tlsscanner.core.constants.TlsProbeType": ["PROTOCOL_VERSION", "CIPHER_SUITE"]
}
}
```
`quic.json` (في نفس دليل `base.json`):
```json
{
"inheritedFromProfiles": ["base.json"],
"settings": {
"scanDetail": "QUICK"
},
"probes": {
"de.rub.nds.tlsscanner.core.constants.QuicProbeType": ["SUPPORTED_VERSIONS"]
}
}
```
```bash
$ java -jar apps/TLS-Server-Scanner.jar -connect localhost:4433 -profile quic.json
```
يقوم هذا بتشغيل `PROTOCOL_VERSION` و `CIPHER_SUITE` و `SUPPORTED_VERSIONS` مع `-scanDetail QUICK`.
لمشاهدة كل فحص متاح لماسح معين (دون الاتصال بهدف)، استخدم `-listProbes`.
يطبعها مجمعة حسب فئة `ProbeType` بصيغة JSON الدقيقة التي يتوقعها حقل `probes` في ملف التعريف،
حتى تتمكن من نسخها ولصقها مباشرة في ملف تعريف:
```bash
$ java -jar apps/TLS-Server-Scanner.jar -listProbes
{
"de.rub.nds.tlsscanner.core.constants.TlsProbeType" : [ "ALPN", "ESNI", "CERTIFICATE", ... ],
"de.rub.nds.tlsscanner.core.constants.QuicProbeType" : [ "SUPPORTED_VERSIONS", ... ]
}
```
## جميع المعلمات
للحصول على معلومات مفصلة حول جميع المعلمات الممكنة، استخدم المعلمة `-help` أو نفذ ملف jar دون ضبط أي معلمات.
# Docker
نوفر صور Docker مبنية مسبقًا لسهولة استخدام TLS-Server-Scanner.
```bash
$ docker run -it --network host ghcr.io/tls-attacker/tlsscanner -connect localhost:4433
```
الصورة مصممة للاستخدام في فحص الخادم ولكنها تحتوي أيضًا على ملفات jar الأخرى.
يمكن الوصول إليها عن طريق تغيير نقطة الدخول (entrypoint).
```bash
$ docker run -it --network host --entrypoint java ghcr.io/tls-attacker/tlsscanner -jar TLS-Client-Scanner.jar
```
نوفر لك أيضًا ملف Dockerfile، لبناء الحاوية بنفسك:
```bash
$ docker build . -t tlsscanner
$ docker run -t tlsscanner
```
**يرجى الملاحظة:** *أنا لست على دراية بأفضل ممارسات Docker بأي حال من الأحوال. إذا كنت تعرف كيفية تحسين ملف Dockerfile
فلا تتردد في إرسال طلب سحب (pull request)*
# نظام المتطلبات (Requirement System)
أحيانًا يكون لفحوصات (TLS) متطلبات أساسية مطلوبة لتنفيذ هذا الفحص المحدد. يسمح لك نظام المتطلبات بتعريف مجموعات من هذه المتطلبات التي يجب تلبيتها لكي يتم تنفيذ الفحص.
يقدم كل متطلب دالة `evaluate` تُرجع قيمة منطقية تشير إلى ما إذا كان المتطلب قد تم استيفاؤه.
يمكن ربط المتطلبات بعدة طرق باستخدام العمليات المنطقية المعروفة. يقدم كل متطلب دوال
`and` و `or` و `not` و `xor` كدوال على المثيل لربط متطلبات متعددة. الفحوصات التالية منفذة حاليًا ويمكن استخدامها جاهزة:
- `FulfilledRequirement` - يُقيّم دائمًا إلى `true`، مفيد للإشارة إلى عدم وجود متطلب.
- `UnfulfillableRequirement` - يُقيّم دائمًا إلى `false`، يمنع تنفيذ الفحوصات.
- `ProbeRequirement` - يُقيّم إلى `true` إذا تم تنفيذ الفحص (الفحوصات) المحدد.
- `PropertyRequirement` - يُقيّم إلى `true` إذا كانت الخصائص المحللة المحددة لها قيمة محددة مسبقًا. يمكن توفير القيمة إما كمعلمة للمُنشئ أو يمكن استخدام `PropertyTrueRequirement` و `PropertyFalseRequirement` كاختصار لـ `TestResults.TRUE` و `TestResults.FALSE`.
- `PropertyComparatorRequirement` - يُقيّم إلى `true` إذا كانت نتيجة المجموعة لخاصية محللة أصغر أو تساوي أو أكبر من قيمة ثابتة.
- `ProtocolRequirement` - يُقيّم إلى `true` إذا كانت إصدارات بروتوكول معينة مدعومة.
- `ExtensionRequirement` - يُقيّم إلى `true` إذا كانت امتدادات معينة مدعومة من النظير البعيد.
- `OptionsRequirement` - يُقيّم إلى `true` إذا تم ضبط أعلام cli إضافية. يُستخدم حاليًا في بعض فحوصات العميل (ALPN، SNI، استئناف الجلسة).
- `WorkingConfigRequirement` - يُقيّم إلى `true` إذا تم العثور على تكوين عامل.
بصرف النظر عن هذه المتطلبات المحددة مسبقًا، يمكن للمرء أيضًا توسيع فئة `Requirement` بشكل مجهول داخل دالة `getRequirements`. إذا لم يكن هناك متطلب، يمكنك إرجاع `FulfilledRequirement` الذي يُقيّم دائمًا إلى true.
يمكن العثور على أمثلة حول كيفية استخدام المتطلبات في حزم `probe` الخاصة بـ `tls-client-scanner` و `tls-server-scanner`.
```java
@Override
public Requirement<ClientReport> getRequirements() {
return new ProbeRequirement<ClientReport>(TlsProbeType.CIPHER_SUITE)
.and(new PropertyTrueRequirement<>(TlsAnalyzedProperty.SUPPORTS_DHE));
}
```