ابدأ بالمنافذ التي يستخدمها عملاؤك مباشرة: HTTPS على المنفذ 443، وإعادة التوجيه على المنفذ 80، ومنافذ بوابة API، وكذلك DNS أو SMTP إذا كنت تستضيفهما بنفسك. بعد ذلك، غطِّ الاعتماديات الداخلية القادرة على إسقاط المنظومة بأكملها، مثل قواعد البيانات وذاكرات التخزين المؤقت وقوائم انتظار الرسائل. وأخيراً، راقب منافذ الإدارة مثل SSH وRDP وواجهة Docker API للتأكد من أنها غير قابلة للوصول من الإنترنت.
رتِّب المنافذ حسب الأثر لا حسب الرقم
مراقبة كل خدمة مُصغية دفعة واحدة تُنتج تنبيهات مزعجة دون مسؤولية واضحة. بدلاً من ذلك، قيِّم كل منفذ وفق ثلاثة أسئلة قبل إضافة أي فحص:
- الأثر على العملاء والإيرادات. إذا توقف هذا المنفذ عن الاستجابة، هل سيرى المستخدمون أخطاء، أو تفشل عملية الدفع، أو تنتهي مهلة عملاء API؟
- نقطة الفشل الوحيدة. هل توجد خلفه قاعدة بيانات رئيسية واحدة أو وسيط رسائل واحد أو موازن أحمال واحد، أم أن الحركة تنتقل تلقائياً إلى بديل؟
- خطر الانكشاف. إذا أصبح هذا المنفذ متاحاً من الإنترنت العام، فهل يُعد ذلك حادثاً أمنياً؟
الدرجات المرتفعة في السؤالين الأولين تضع المنفذ في مستوى توافرية، أما الدرجة المرتفعة في السؤال الثالث فتضعه في مستوى انكشاف يكون فيه «مفتوح» هو شرط التنبيه.
المستوى 1: نقاط الدخول العامة
أنشئ هذه الفحوصات أولاً، عادةً بفواصل زمنية من 30 إلى 60 ثانية ومن عدة مناطق:
- 443 (HTTPS): بوابتك الأمامية الرئيسية. تحقّق من مصافحة TLS، لا من اتصال TCP فقط.
- 80 (HTTP): يجب أن يستجيب بإعادة توجيه إلى 443. إعادة التوجيه المعطّلة تترك المستخدمين القادمين من روابط قديمة دون وجهة.
- منافذ بوابة API (مثل 8443 أو منفذ gRPC مخصص) التي يستدعيها الشركاء أو تطبيقات الجوال مباشرة.
- المنفذ 53 عبر TCP وUDP إذا كنت تستضيف خادم DNS الموثوق بنفسك. يحمل UDP معظم الاستعلامات، بينما يتولى TCP الاستجابات الكبيرة ونقل المناطق، لذا افحص كليهما.
- 25 أو 465 أو 587 إذا كنت ترسل رسائل البريد الإلكتروني التشغيلية عبر خوادم الترحيل الخاصة بك. فإذا تعطّل SMTP بصمت، تتوقف رسائل إعادة تعيين كلمات المرور والفواتير عن الوصول.
تكتسب الفحوصات من مواقع متعددة أهمية خاصة، لأن تغييراً في جدار الحماية أو شبكة CDN قد يترك منفذاً مفتوحاً في منطقة ومحجوباً في أخرى.
المستوى 2: الاعتماديات الداخلية
لا ينبغي أن تكون هذه الخدمات عامة، لذا افحصها من داخل الشبكة أو من عنوان IP للمراقبة مسموح به صراحةً في جدار الحماية:
- 5432 (PostgreSQL) و3306 (MySQL): نقاط النهاية الرئيسية والنسخ المتماثلة على حد سواء.
- 6379 (Redis): كثيراً ما تتعطل ذاكرات التخزين المؤقت بصمت، ثم تُثقل قاعدة البيانات التي خلفها.
- 5672 (RabbitMQ) و9092 (Kafka): توقف وسيط الرسائل يؤدي إلى تراكم كل المهام غير المتزامنة.
- مستمعو موازنات الأحمال الداخلية أمام طبقات الخدمات.
تتبّع زمن الاتصال إلى جانب حالة التشغيل والتوقف. فمنفذ قاعدة بيانات يستغرق 800 مللي ثانية لقبول الاتصال بدلاً من 5 مللي ثانية يشير غالباً إلى استنفاد مجمّع الاتصالات أو تشبّع الخادم.
المستوى 3: منافذ يجب أن تبقى مغلقة
يعكس المستوى الأخير المنطق: إذ تُطلق التنبيه عندما تكون هذه المنافذ قابلة للوصول من الإنترنت العام.
| المنفذ | الخدمة | سبب خطورة الانكشاف العام |
|---|---|---|
| 22 | SSH | هدف دائم لهجمات القوة الغاشمة وحشو بيانات الاعتماد |
| 3389 | RDP | نقطة دخول متكررة لبرمجيات الفدية |
| 2375 / 2376 | Docker API | المنفذ 2375 بلا مصادقة ويمنح تحكماً كاملاً في الخادم |
| 6443 | Kubernetes API | يجب حصره في نطاقات IP مسموح بها أو في شبكة خاصة |
| 9200 | Elasticsearch | مصدر شائع لتسريب البيانات |
| 27017 | MongoDB | تعرّض تاريخياً للمسح الجماعي ومحو البيانات حين تُرك مفتوحاً |
شغّل هذه الفحوصات من مواقع خارجية كل 5 إلى 15 دقيقة. بذلك تكتشف مجموعة أمان خُففت قيودها، أو مخطط Helm مُهيأ بشكل خاطئ، أو منفذ تصحيح أخطاء منسياً.
كيف تطبّق ذلك مع UpScanX
تُجري مراقبة المنافذ في UpScanX فحوصات TCP وUDP من أكثر من 15 موقعاً عالمياً، ما يجعلها مناسبة للتطبيق على مراحل:
- الأسبوع 1: أضف فحوصات المستوى 1 مع التحقق من الاستجابة الخاص بكل بروتوكول، حتى يُطلق المنفذ تنبيهاً إذا قبل الاتصالات لكنه أعاد استجابات معطوبة.
- الأسبوع 2: أضف فحوصات المستوى 2 حيثما تسمح شبكتك بوصول المراقبة، مع تتبّع زمن الاتصال وزمن الاستجابة. اضبط التحذير عند نحو ضعفين إلى ثلاثة أضعاف زمن الاتصال المعتاد.
- الأسبوع 3: سجّل خط أساس للتهيئة في المستوى 3 وفعّل اكتشاف تغيّر حالة المنافذ. كما ينبّهك التعرف على بصمة الخدمة مع اكتشاف الإصدار إلى منفذ يُفترض أن يشغّل nginx لكنه يُعرّف نفسه فجأة كخدمة أخرى.
وجّه تنبيهات المستوى 1 إلى Slack أو Microsoft Teams حيث يتابعها فريق الاستجابة، وأرسل تنبيهات الانكشاف في المستوى 3 إلى فريق الأمن عبر البريد الإلكتروني أو Webhook. ولمعرفة ما يجب التحقق منه في كل منفذ مفتوح، راجع قائمة التحقق لمراقبة المنافذ المفتوحة الحرجة.
أبرز النقاط
- حدّد الأولويات وفق الأثر على العملاء ونقاط الفشل الوحيدة وخطر الانكشاف، لا وفق رقم المنفذ.
- راقب نقاط الدخول العامة أولاً، ثم اعتماديات البيانات الداخلية، ثم منافذ الإدارة.
- تتبّع زمن الاتصال، لا قابلية الوصول فقط، لاكتشاف التدهور مبكراً.
- راجع القائمة بعد كل تغيير كبير في البنية التحتية، فالخدمات الجديدة تضيف منافذ جديدة دون أن يلاحظ أحد.