تقييد محاولات إدخال كلمة المرور في لينكس لتأمين SSH والخدمات

إذا كنت تدير خادم لينكس مُعرَّضًا للإنترنت، فسترى عاجلاً أم آجلاً في سجلات النظام ما يلي: آلاف محاولات تسجيل الدخول عبر SSH من عناوين IP عشوائيةليس الأمر أنهم يكنون لك كراهية: إنها روبوتات آلية تتجول في نطاقات عناوين IP بحثًا عن أبواب ضعيفة الحماية.

على خادم صغير، يمكن أن تترجم تلك المحاولات إلى ارتفاعات مفاجئة في استخدام وحدة المعالجة المركزية، وتدهور في الأداء، وحتى انقطاعات عرضية في الخدمةوالخبر السار هو أن نظام لينكس يوفر ترسانة من الأدوات للحد من محاولات كلمات المرور، وحظر عناوين IP العدوانية، وتحصين SSH لجعل الأمر صعبًا للغاية على المهاجم.

الكشف عن هجمات القوة الغاشمة على بروتوكول SSH وتأثيرها على الخادم

قبل أن نبدأ في ضبط أي شيء، من المفيد أن نفهم كيفية اكتشاف ما إذا كنا نواجه مشكلة ما. هجوم القوة الغاشمة على SSH أو خدمات أخرىوما هي آثار ذلك على الآلة.

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

لتحليل ما كان يحدث في فترة زمنية محددة، من المفيد جدًا استخدام journalctlأداة systemd لقراءة سجلات النظام والخدمات والنواة وسجلات المصادقة. مثال كلاسيكي على الاستعلام هو:

journalctl --since "2025-11-16 13:10" --until "2025-11-16 13:16"

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

في كثير من الحالات ستجد أسطرًا متكررة متعلقة بـ SSH، مثل: "كلمة مرور خاطئة لـ" تشير إلى محاولات تسجيل دخول فاشلةهذا يكاد يكون مرادفاً لاستخدام برامج الروبوت لاختبار بيانات الاعتماد بالقوة الغاشمة.

قم بحساب عدد المحاولات الفاشلة في /var/log/auth.log

في أنظمة ديبيان/أوبونتو، يكون الملف الرئيسي لتتبع أي شيء يتعلق بالمصادقة هو /var/log/auth.logهنا يتم تسجيل عمليات تسجيل الدخول الناجحة، والمحاولات الفاشلة، وأحداث PAM، وعمليات قفل الحساب، وما إلى ذلك.

إذا كنت تريد معرفة عدد مرات تسجيل النمط "كلمة مرور فاشلة" في السجل الحالي، يمكنك استخدام:

sudo grep 'Failed password' /var/log/auth.log | wc -l

قد تكون النتيجة مفاجئة: فليس من غير المألوف أن نرى تراكمت آلاف المحاولات الفاشلة في غضون ساعات.وتذكر أن هذا مجرد الملف الحالي.

بما أن سجلات النظام تُدار دوريًا، فمن المهم أيضًا مراجعة الملفات القديمة. يمكنك معرفة الفترة الزمنية التي يغطيها السجل الحالي باستخدام أمر مشابه لما يلي:

head -n 1 /var/log/auth.log
tail -n 1 /var/log/auth.log

وبهذه الطريقة ستعرف تاريخ أول وآخر سجل موجود في ملف auth.logأما بقية المحاولات السابقة فستكون في auth.log.1 وفي الملفات المضغوطة auth.log.N.gz.

لمراجعة السجلات القديمة المضغوطة وحساب عدد محاولات إدخال كلمة المرور الفاشلة، يمكنك استخدام ما يلي:

zgrep 'Failed password' /var/log/auth.log.*.gz | wc -l

إذا جمعت ما تراه في auth.log و auth.log.1 و auth.log.*.gz ستحصل على فكرة جيدة عن سجل تاريخي للهجمات العنيفةمع الأخذ في الاعتبار أن أقدمها ربما تكون قد اختفت بالفعل بسبب الدوران.

كيف تعمل عملية تدوير سجلات المصادقة

تعتمد طريقة وتواتر دوران جذوع الأشجار على تكوين logrotateفي نظام أوبونتو، يتم عادةً تحديد عملية تدوير ملف auth.log في المسار /etc/logrotate.d/rsyslog، حيث ستجد عادةً شيئًا مثل:

weekly
rotate 4
compress

هذا يعني أنه يتم تدوير السجل أسبوعياً، ويتم الاحتفاظ بأربع نسخ قديمة، ويتم ضغط النسخ القديمة في ملفات .gz.تتولى مهمة cron اليومية مسؤولية تشغيل logrotate وتطبيق هذه القواعد.

لذلك، عند حساب محاولاتك باستخدام القوة الغاشمة، افترض أن أنت لا ترى سوى البيانات التاريخية من عدة أسابيع مضت.أي شيء حدث في الماضي البعيد لن يكون موجوداً في النظام.

تحديد المستخدمين وعناوين IP المهاجمة

بغض النظر عن العدد الإجمالي، من المهم معرفة ما هي أسماء المستخدمين المستهدفين، ومن أي عناوين IP تنطلق الهجمات؟باستخدام القليل من أوامر awk على ملف auth.log، يصبح الأمر في متناول يدك.

لمعرفة أسماء المستخدمين التي يتم تجربتها في المحاولات الفاشلة:

sudo grep 'Failed password' /var/log/auth.log \
  | awk '{print $(NF-5)}' \
  | sort | uniq -c

وللاطلاع على عناوين IP التي سجلت أكثر الأنشطة المشبوهة:

sudo grep 'Failed password' /var/log/auth.log \
  | awk '{print $(NF-3)}' \
  | sort | uniq -c | head

سيسمح لك هذا باكتشاف ما إذا كانوا يهاجمون بسرعة. حسابات حقيقية من نظامك أو مستخدمين عاديين مثل root و admin و test و user وما إلى ذلك، وعناوين IP التي يجب حظرها بشكل عاجل.

هل الأمر خطير حقاً لدرجة وجود آلاف المحاولات؟

يجب افتراض أنه إذا كان خادمك متاحًا من الإنترنت ولديه يستمع SSH على المنفذ 22 أو أي منفذ آخرسيستقبل هذا الخادم هذا النوع من حركة البيانات على مدار الساعة. من الطبيعي أن ترى آلاف المحاولات الفاشلة إذا كان الخادم يعمل لفترة طويلة.

تعتمد الجاذبية الفعلية على إعداداتك:

ترتيب	المخاطر التقريبية
كلمات مرور ضعيفة + اتصال SSH مفتوح بالإنترنت	خطر اختراق مرتفع للغاية
كلمات مرور قوية	مخاطرة متوسطة، ولكن استهلاك الموارد
تم تكوين Fail2ban بشكل صحيح	هجمات منخفضة المخاطر ومخففة للغاية
الوصول متاح فقط باستخدام مفاتيح SSH	المخاطر تقترب من الصفر تقريبًا باستخدام القوة الغاشمة

بمعنى آخر: الهجمات الآلية شائعة، ولكن إذا كان نظامك متساهلاً، يكفي مجرد فشل واحد في إدخال كلمة المرور ليتسبب في فقدان الخادم بأكمله.ولهذا السبب من المهم جداً الحد من المحاولات، وحظر عناوين IP، والتخلص من كلمات المرور حيثما أمكن ذلك.

تأمين SSH الأساسي: خيارات بالغة الأهمية في ملف sshd_config

خط الدفاع الأول هو داخل المرء برنامج SSH daemon (sshd) وملف التكوين الخاص به /etc/ssh/sshd_config (وملفات .d المرتبطة بها). تعمل بعض التوجيهات المُحسّنة جيدًا على تقليل مساحة الهجوم بشكل كبير.

ضع في اعتبارك أنه في التوزيعات الحديثة مثل أوبونتو 22.04 والإصدارات الأحدث، يقرأ sshd أولاً الملف /etc/ssh/sshd_config ثم الملفات الموجودة في /etc/ssh/sshd_config.d/*.conf بالترتيب الأبجدي. أي شيء يظهر لاحقًا قد يحل محل المعلمات المحددة مسبقًا، لذا كن حذرًا جدًا عند تغيير أي شيء.

قم بتعطيل الوصول بدون كلمة مرور والجلسات غير الضرورية

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

PermitEmptyPasswords no

عادةً ما يتم تعطيل هذا الخيار أو ضبطه صراحةً على "لا". تأكد أيضًا من تعطيل الميزات التي لن تستخدمها، مثل... إعادة توجيه X11 (X11Forwarding) إذا كنت لا تقوم بجلسات رسومات عن بُعد:

X11Forwarding no

فيما يتعلق بالبروتوكولات، إذا كنت تدير نظامًا قديمًا جدًا لأي سبب من الأسباب، فتحقق من السماح بإجراءات معينة فقط. بروتوكول SSH 2:

Protocol 2

قم بتغيير المنفذ الافتراضي وحدد الواجهة التي يستمع إليها.

خدعة أخرى بسيطة، وإن لم تكن مضمونة النتائج، هي انقل SSH من المنفذ 22 إلى منفذ غير قياسي.هذا لا يحميك من مهاجم خطير، ولكنه يقوم بتصفية كمية كبيرة من الضوضاء الآلية التي تقوم فقط بفحص الـ 22.

Port 2222
ListenAddress 192.168.56.8

بالإضافة إلى تغيير المنفذ، يمكنك تحديد عنوان معين يستمع إليه SSH، على سبيل المثال، عنوان IP الداخلي الخاص بك إذا كنت ترغب في حصره بشبكة معينة. مع ذلك، إذا كانت توزيعتك تستخدم ssh.socket من systemd، فقد تحتاج إلى... قم بتعطيل المقبس والعودة إلى خدمة ssh.service الكلاسيكية. مراعاة إعدادات المنفذ:

sudo systemctl disable ssh.socket
sudo systemctl daemon-reload
sudo systemctl enable ssh.service
sudo systemctl start ssh.service

كلما قمت بتغيير المنفذ، اختبر الاتصال من طرفية أخرى قبل إغلاق الجلسة الرئيسية، حتى لا تتعطل بدون الوصول عن بعد.

حظر أو تقييد الوصول إلى صلاحيات الجذر

المستخدم الجذر هو فريسة سهلة للمهاجمين، لذا فهذا أمر منطقي. منع الاتصال عبر SSHحتى مع كلمات المرور. يمكنك التحكم في هذا السلوك باستخدام التوجيه التالي:

PermitRootLogin no

في العديد من الأنظمة الحديثة، يأتي البرنامج مُفعّلاً بوضع "حظر كلمة المرور"، الذي يمنع تسجيل الدخول باستخدام كلمة المرور ولكنه يسمح باستخدام الشهادات. ولضمان أقصى درجات الأمان، يُنصح بتعطيل هذا الخيار واستخدام حساب عادي مع صلاحيات المستخدم الجذر (sudo) لإدارة النظام.

حدد من يمكنه الوصول: AllowUsers و AllowGroups

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

لتقييد المستخدمين المسموح لهم، لديك التوجيهات التالية. السماح للمستخدمين y السماح للمجموعات. على سبيل المثال:

AllowUsers harry hermione
AllowGroups gryffindor

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

من الممارسات الجيدة العمل بشكل أساسي مع المجموعات النمطية. مستخدمو SSH أو المسؤولون وأضف الحسابات المصرح بها هناك، بدلاً من الاحتفاظ بقائمة المستخدمين واحداً تلو الآخر في الملف.

الحد من محاولات المصادقة ووقت التوقف

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

MaxAuthTries 3

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

فيما يتعلق بوقت الخمول، يسمح لك SSH بإنهاء الاتصالات التي تظل مفتوحة دون أي نشاط يتجاوز عتبة محددة. ClientAliveInterval (بالثواني):

ClientAliveInterval 180

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

تقييد الوصول حسب عنوان IP: أغلفة TCP والمطابقة

في بعض الحالات قد تكون مهتمًا بـ لا يمكن الوصول عبر SSH إلا من خلال عناوين IP أو نطاقات محددة.لديك عدة طرق للقيام بذلك: من جدار الحماية نفسه (iptables/nftables)، من خلال TCP Wrappers، إلى كتل Match في sshd_config.

باستخدام أغلفة TCP، التي لا تزال مستخدمة في العديد من التوزيعات، يتم التحكم في الوصول باستخدام ملفي /etc/hosts.allow و /etc/hosts.deny. ويكون التسلسل كالتالي: أولاً، يتم تقييم hosts.allow، ثم hosts.deny.ومن الأمثلة التقييدية ما يلي:

# /etc/hosts.deny
ALL: ALL

# /etc/hosts.allow
sshd: 192.168.1.89 192.168.1.55
sshd: ALL: DENY

مع هذا التكوين، لن يتمكن سوى مضيفين محددين من الاتصال عبر SSHأما الباقي فسيتم رفضه. إنه فعال للغاية في البيئات المغلقة، على الرغم من أنه أقل مرونة من جدار الحماية الحديث الجيد.

ثمة خيار آخر، وهو أكثر شيوعًا في بروتوكول SSH، وهو استخدام الكتل. مباراة يمكنك استخدام `allowUsers` ضمن ملف `sshd_config` لتطبيق قواعد بناءً على العنوان أو المستخدم. على سبيل المثال، إذا أردتَ السماح للمستخدم "git" بتسجيل الدخول من أي مكان، بينما لا يستطيع المستخدم الإداري "greg" تسجيل الدخول إلا من الشبكة المحلية 192.168.1.0/24، فيمكنك دمج قواعد `allowUsers` مع قواعد `Match Address`، ولكن عليك توخي الحذر الشديد عند استخدامها. لا تنعزل عن نفسك.

Fail2ban: الحظر التلقائي مقابل القوة الغاشمة

حتى مع تعزيز أمان SSH، ستظل البرامج الآلية تحاول الوصول إلى بيانات الاعتماد، مما يؤدي إلى زيادة استهلاك وحدة المعالجة المركزية وظهور بيانات غير ضرورية في سجلات النظام. وللتخفيف من هذه المشكلة، يأتي دور هذا الحل. Fail2ban، نظام منع الاختراق القائم على السجلات والذي يقوم تلقائيًا بحظر عناوين IP التي تحتوي على عدد كبير جدًا من الأخطاء.

تمت كتابة Fail2ban بلغة بايثون وتعتمد على "السجون" أو السجون، كل منها مرتبط بخدمة وملف سجل واحد أو أكثرعندما يكتشف نمط خطأ متكرر (فشل كلمة المرور، الوصول المحظور، إلخ)، فإنه يقوم بتشغيل إجراءات، عادة ما تكون قواعد جدار الحماية لحظر المصدر.

قم بتثبيت برنامج Fail2ban على توزيعات لينكس الشائعة

التثبيت الأساسي بسيط للغاية باستخدام مدير الحزم الخاص بتوزيعتك. على أوبونتو أو ديبيان، يكفي هذا:

sudo apt update
sudo apt install fail2ban

في الأنظمة القائمة على RHEL (RHEL، CentOS، AlmaLinux، Rocky، إلخ) يكون الأمر النموذجي مع dnf أو yum، حسب الإصدار:

sudo dnf install fail2ban

تتضمن الحزمة عادةً خدمة systemd التي تبدأ تلقائيًا، على الرغم من أنه يجدر التحقق من ذلك. يبدأ برنامج Fail2ban عند بدء التشغيل ويكون نشطًا:

sudo systemctl enable fail2ban
sudo systemctl start fail2ban
sudo systemctl status fail2ban

بنية التكوين: jail.conf و jail.local و jail.d

يوجد التكوين في /etc/fail2ban/الملف الرئيسي هو jail.conf، ولكن لا يُنصح بتعديله مباشرةً لأنه يُستبدل أثناء التحديثات. بدلاً من ذلك، يجب عليك:

أنشئ أو عدّل الملف /etc/fail2ban/jail.local لتجاوز القيم الافتراضية.
أو أضف ملفات محددة إلى /etc/fail2ban/jail.d/*.conf.

يقوم برنامج Fail2ban بتحميل الإعدادات بهذا الترتيب:

/etc/fail2ban/jail.conf
/etc/fail2ban/jail.d/*.conf
/etc/fail2ban/jail.local

كل ما تحدده في ملف jail.local له الأولوية على كل ما سبقه، لذلك يمكنك التخصيص دون المساس بملفات الحزمة..

المعلمات العامة المهمة: مدة الحظر، الحد الأقصى لإعادة المحاولة، تجاهل عنوان IP

ستجد داخل ملف jail.conf (أو jail.local) قسمًا بعنوان [DEFAULT] يحتوي على معلمات عامة تؤثر على جميع السجون ما لم يتم تجاوزها. أهمها ما يلي:

بانتيم: الوقت الذي سيتم خلاله حظر عنوان IP (بالثواني) بعد تجاوز عدد حالات الفشل المسموح بها.
ماكسريتري: الحد الأقصى لعدد المحاولات الفاشلة قبل تطبيق الحظر.
اوجد وقت: الفترة الزمنية التي يتم فيها احتساب تلك المحاولات (على سبيل المثال، 10 دقائق لمدة عشر دقائق).
تجاهل: قائمة عناوين IP أو النطاقات التي يجب ألا يحظرها Fail2ban مطلقًا (على سبيل المثال، عنوان IP العام الخاص بك أو شبكة الإدارة الخاصة بك).

على سبيل المثال، يمكنك الحصول على شيء كهذا في [الافتراضي]:

[DEFAULT]
bantime  = 600
findtime = 600
maxretry = 5
ignoreip = 127.0.0.1/8 192.168.1.0/24

مع هذا التكوين، أي عنوان IP يفشل خمس مرات في غضون عشر دقائق سيتم حظره لمدة عشر دقائق.، إلا إذا كان جزءًا من النطاقات المتجاهلة.

قم بتهيئة خادم SSH المعزول (jail sshd) لمنع هجمات SSH

أكثر أنواع السجون شيوعًا هو سجن SSH. في العديد من التوزيعات، يأتي مُهيأً مسبقًا في ملف jail.conf؛ كل ما عليك فعله هو تفعيله أو ضبط قيمه في ملف jail.local. مثال بسيط:

[sshd]
enabled  = true
filter   = sshd
logpath  = /var/log/auth.log
maxretry = 3
bantime  = 600
findtime = 10m

في هذه الحالة، ثلاث محاولات تسجيل دخول فاشلة مسجلة في ملف auth.log خلال عشر دقائق ستؤدي إلى حظر عنوان IP الخاص بالمهاجم لمدة عشر دقائق.يقوم Fail2ban بإدخال القواعد في جدار الحماية (iptables أو nftables أو UFW، حسب النظام) بحيث لا تصل الاتصالات من عنوان IP هذا إلى sshd.

لتطبيق أي تغييرات في الإعدادات، تذكر إعادة تشغيل الخدمة:

sudo systemctl restart fail2ban

اطلع على حالة السجون وعناوين IP المحظورة

يتضمن برنامج Fail2ban أداة تحكم سهلة الاستخدام للغاية، العميل fail2banباستخدام هذه الأداة، يمكنك معرفة السجون النشطة وعناوين IP المحظورة. على سبيل المثال:

sudo fail2ban-client status

سيظهر شيئًا مشابهًا لما يلي:

Status
|- Number of jail: 1
`- Jail list: sshd

للحصول على معلومات مفصلة حول سجن وزارة الداخلية:

sudo fail2ban-client status sshd

تتضمن المخرجات، من بين حقول أخرى، عدد عناوين IP المحظورة حاليًا و إجمالي عدد العناوين التي تم حظرها مرة واحدة على الأقل تاريخياًبالإضافة إلى قائمة عناوين IP الجارية.

باستخدام هذه البيانات يمكنك الحصول على فكرة عن ما مقدار حركة المرور الضارة التي يتلقاها خادمك، وما مدى فعالية التكوين الحالي؟.

أقفال دائمة وفترات حظر متزايدة

إذا كنت ترغب في أن تكون صارمًا بشكل خاص مع المخالفين المتكررين، فإن Fail2ban يقدم استراتيجيتين مثيرتين للاهتمام: حظر دائم وحظر تدريجي.

لحظر أي عنوان IP بشكل دائم يتجاوز الحد المسموح به، ما عليك سوى إدخال ما يلي:

bantime = -1

مع هذا التعديل، لا يتم رفع الحظر عن عناوين IP الخاضعة للعقوبات تلقائيًا أبدًا.لا يمكنك إزالتها يدويًا إلا إذا كنت بحاجة إلى ذلك.

أما الآلية التدريجية فهي أكثر مرونة، حيث يؤدي كل تكرار للجريمة إلى زيادة مدة الحظر وفقًا لعامل معين:

bantime           = 10m
bantime.increment = true
bantime.rndtime   = 0
bantime.factor    = 4
bantime.maxtime   = -1

بهذه القيم، سيبدو التدرج على النحو التالي:

الكتلة الثالثة: 10 دقيقة
الكتلة الثانية: 40 دقيقة
الكتلة الثالثة: 160 دقيقة (ساعتان و40 دقيقة تقريبًا)
المربع الرابع: حول ساعات 10,6
الكتلة الخامسة: بعض ساعات 42

بما أن قيمة bantime.maxtime تساوي -1، فإن يمكن أن تستمر المدة في النمو إلى أجل غير مسمىمما أدى إلى استبعاد اللاعبين الأقوياء من اللعبة إلى الأبد.

استخدام Fail2ban خارج نطاق SSH: Apache، WordPress، MySQL، المتاجر الإلكترونية...

بمجرد أن تتقن استخدام Fail2ban، فإن الشيء المنطقي الذي يجب فعله هو توسيعه ليشمل حماية الخدمات الحساسة الأخرى إلى جانب SSHلوحات إدارة المواقع الإلكترونية، وأنظمة إدارة المحتوى، وقواعد البيانات، وما إلى ذلك.

على سبيل المثال، بالنسبة لمتجر إلكتروني (مثل ماجنتو، بريستاشوب، ووكومرس...)، من المنطقي جدًا إنشاء بيئة معزولة تراقب... سجلات الوصول الخاصة بـ Apache أو Nginx تبحث عن العديد من رموز 401/403 في /admin أو /loginيمكن أن يكون التكوين الأدنى القائم على أباتشي كالتالي:

[apache-auth]
enabled  = true
filter   = apache-auth
logpath  = /var/log/apache2/access.log
maxretry = 5
bantime  = 3600

في بيئات ووردبريس، يتمثل أحد التركيبات الشائعة في المراقبة /wp-login.php و /xmlrpc.phpهذه هي نقاط الدخول الكلاسيكية لهجمات القوة الغاشمة وهجمات البرامج الآلية. يمكن وضع الفلتر في المسار التالي: /etc/fail2ban/filter.d/wordpress.conf

[Definition]
failregex = .*"POST /wp-login.php HTTP.*" 403
ignoreregex =

والسجن المقابل في ملف jail.local:

[wordpress]
enabled  = true
filter   = wordpress
logpath  = /var/log/apache2/access.log
maxretry = 3
bantime  = 3600

وينطبق المبدأ نفسه على قواعد البيانات المكشوفة (وهو أمر يُفضّل تجنبه عمومًا): إذا كنت ترغب في حماية MySQL من محاولات الوصول الفاشلة المتكررة، يمكنك إنشاء عامل تصفية لـ رسائل "تم رفض الوصول للمستخدم" في سجل الأخطاء:

[Definition]
failregex = ^<HOST>.*Access denied for user.*$
ignoreregex =

ثم السجن:

[mysqld-auth]
enabled  = true
filter   = mysql
logpath  = /var/log/mysql/error.log
maxretry = 5
bantime  = 1800

استضافة الخوادم المزودة بلوحات تحكم لوحة التحكم أو Pleskكما أن Fail2ban يتكامل بشكل جيد: فهو يستطيع مراقبة خدمات البريد الإلكتروني، وApache، وFTP، وحتى لوحة التحكم نفسها، وحظر عناوين IP التي تتجاوز الحد المسموح به من محاولات تسجيل الدخول.

المصادقة باستخدام مفاتيح SSH: نهاية هجمات كلمات المرور

كل ما سبق يساعد، لكن القفزة الحقيقية في الجودة تأتي عندما تقرر توقف عن استخدام كلمات المرور لبروتوكول SSH وانتقل إلى استخدام المفاتيح العامة/الخاصةعند هذه النقطة، تتوقف هجمات التخمين العشوائي لكلمات المرور عن أن تكون منطقية.

الفكرة بسيطة: كل مستخدم شرعي لديه زوج من المفاتيح، و مفتاح خاص يبقى على جهازك وعلى المفتاح العام الذي يتم نسخه إلى الخادم في ملف ~/.ssh/authorized_keys الخاص بالمستخدم المعني.

عندما يتصل العميل، فإنه لا يرسل المفتاح الخاص؛ بل يرسل المفتاح العام ثم يقوم بتوقيع تحدي الخادم باستخدام التوقيع الخاص. يتحقق الخادم من هذا التوقيع مقابل التوقيع العام، ولا يسمح بالوصول إلا إذا تطابقا.

لماذا تُبطل مفاتيح SSH هجمات التخمين العشوائي لكلمات المرور؟

في نظام كلمات المرور التقليدي، يكفي أن يجرب المهاجم سلاسل نصية حتى يتطابق أحدها مع كلمة المرور المخزنة (أو تجزئتها). على الرغم من أن كلمة المرور الجيدة لها العديد من الاحتمالات، نحن نتحدث عن أرقام هائلة تصل إلى 10¹⁰ احتمالاً لكلمات المرور العادية.

يتحرك مفتاح SSH النموذجي ذو 256 بت (مثل تلك الموجودة في Ed25519) في مساحات البحث بترتيب معين. 10⁶¹⁷ تركيبةمن الناحية العملية، من المستحيل رياضياً أن يتمكن المهاجم من تخمين المفتاح الخاص باستخدام أسلوب التجربة والخطأ مع أجهزة الكمبيوتر الحديثة.

بل والأكثر من ذلك، أن الخادم لا يحاول حتى حساب أي شيء إذا كان المفتاح العام المقدم غير موجود في authorized_keysفي هذه الحالة، يقوم بإلغاء الاتصال على الفور تقريبًا، دون استدعاء PAM أو عمليات المصادقة التقليدية، لذا فإن استهلاك وحدة المعالجة المركزية أثناء الهجوم الضخم يكون ضئيلاً.

قم بإنشاء مفاتيح SSH والتحقق منها على جهاز العميل

قبل الوصول إلى الخادم، تحقق مما إذا كان جهازك يحتوي بالفعل على زوج مفاتيح SSH تم إنشاؤه مسبقًا. ما عليك سوى سرد محتويات الملف ~/.ssh:

ls -l ~/.ssh

إذا رأيت ملفات مثل id_ed25519 و id_ed25519.pub إذا كنت تستخدم id_rsa و id_rsa.pub، فلديك بالفعل زوج صالح. يُعدّ Ed25519 أحدث وأخف وزنًا، لذا فهو عادةً الخيار الأفضل هذه الأيام.

إذا لم تكن لديك مفاتيح، فقم بإنشاء مفاتيح جديدة باستخدام:

ssh-keygen -t ed25519 -C "tu_usuario@tu_equipo"

سيقوم الأمر بإنشاء ملفين:

id_ed25519المفتاح الخاص، الذي يجب ألا تشاركه أبداً.
id_ed25519.pubالمفتاح العام، الذي يمكنك نسخه إلى الخوادم.

يمكنك عرض محتويات المفتاح العام باستخدام:

cat ~/.ssh/id_ed25519.pub

انسخ المفتاح العام إلى الخادم واختبر الوصول

على الخادم، تأكد من وجود مجلد ~/.ssh للمستخدم الذي ستسجل الدخول به (على سبيل المثال، git أو مستخدم المسؤول الخاص بك) وأنّه يحتوي على التصاريح 700:

mkdir -p ~/.ssh
chmod 700 ~/.ssh

ثم أضف محتوى ملف id_ed25519.pub الخاص بعميلك إلى ~ / .ssh / author_keys (إنشاء الملف إذا لم يكن موجودًا) ومنحه الصلاحيات 600:

echo "TU_PUBLIC_KEY" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

تذكر استبدال YOUR_PUBLIC_KEY بالسطر الكامل الذي رأيته باستخدام الأمر `cat` على جهازك. بعد ذلك، يمكنك اختبار الاتصال بتحديد المفتاح صراحةً إذا رغبت في ذلك.

ssh -i ~/.ssh/id_ed25519 usuario@IP_DEL_SERVIDOR

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

قم بتعطيل خاصية التحقق من كلمة المرور على الخادم بشكل كامل

بمجرد التأكد من إمكانية الوصول إلى حسابك باستخدام كلمة المرور الخاصة بك من جهاز واحد على الأقل (ويُفضل جهازين، في حالة فقدان أحدهما)، فمن المستحسن تعطيل تسجيل الدخول بكلمة المرور لبروتوكول SSHهذا يقضي على أي محاولة لاستخدام القوة الغاشمة التقليدية في مهدها.

قبل تعديل الإعدادات، من المستحسن معرفة الملفات التي تُعرّف خاصية PasswordAuthentication، لأن العديد من عمليات التثبيت الحديثة توجد ملفات بامتداد .d تقوم باستبدال قيمة ملف sshd_config الرئيسي:

sudo grep -R "PasswordAuthentication" /etc/ssh/

من الشائع العثور على شيء مثل:

/etc/ssh/sshd_config.d/50-cloud-init.conf:PasswordAuthentication yes
/etc/ssh/sshd_config:PasswordAuthentication no

في هذه الحالة، ستكون قيمة الإعداد الفعلي "نعم" لأن ملف 50-cloud-init.conf يُحمّل لاحقًا ويستبدل القيمة. يمكنك التحقق من النتيجة النهائية التي يطبقها sshd باستخدام:

sudo sshd -T | grep passwordauthentication

لتعطيل كلمات المرور الحقيقية، قم بتحرير الملف المسؤول (على سبيل المثال /etc/ssh/sshd_config.d/50-cloud-init.conf) واترك ما يلي:

PasswordAuthentication no

ثم أعد تشغيل خدمة SSH:

sudo systemctl restart ssh

وتأكد مرة أخرى من خلال:

sudo sshd -T | grep passwordauthentication

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

دمج مفاتيح SSH مع Fail2ban وإجراءات أخرى

عند إزالة خاصية PasswordAuthentication من المعادلة، تصبح قيمة Fail2ban لبروتوكول SSH أكثر فائدة من كونها ضرورية، لأن لا تحتوي برامج الروبوت حتى على حقل لإدخال كلمة المرور.ومع ذلك، يُنصح بإبقاء سجن sshd نشطًا لأنه بمثابة طبقة إضافية ضد المحاولات غير العادية من الأنواع الأخرى أو إساءة استخدام المفاتيح.

إذا كان هذا المزيج من مفاتيح SSH فقط + Fail2ban + قفل الجذر + قوائم AllowUsers/AllowGroups مضبوطة بدقة أضف جدار حماية مقيد (iptables/nftables، UFW، firewalld) وإذا كان ذلك مناسبًا، قوائم التحكم في الوصول مع TCP Wrappers، وستكون قد قللت من احتمالية الاختراق بالقوة الغاشمة إلى مستوى ضئيل.

وفي بيئات أكثر حساسية، يمكنك المضي قدمًا وإدخال المصادقة الثنائية (2FA) لبروتوكول SSHباستخدام وحدات مثل Google Authenticator أو ما شابه ذلك عبر PAM، أو حتى تقييد من يمكنه الوصول إلى منفذ SSH باستخدام شبكات VPN مخصصة.

مع دمج كل هذه العناصر بشكل جيد - اكتشاف السجلات، وتكوين sshd بعناية، والاستخدام المكثف لـ Fail2ban، ومفاتيح SSH بدلاً من كلمات المرور، وعند الضرورة، عناصر التحكم القائمة على IP - يمكن لخادم Linux التعامل مع هجمات القوة الغاشمة المستمرة على SSH والخدمات الأخرى المكشوفةمع الحفاظ على وصول مريح وآمن للمسؤولين.