أساسيات Linux لطالب الأمن السيبراني: تعلّم النظام بعقلية المحلل لا بحفظ الأوامر

يظهر Linux في تحليل الحوادث، وإدارة الخوادم، واختبار الاختراق، والتحليل الجنائي الرقمي، وتشغيل الأدوات الأمنية. لكن الخطأ الشائع لدى الطالب هو التعامل معه بوصفه مجموعة أوامر يجب حفظها.

المحلل الأمني لا يسأل فقط: ما الأمر الذي أكتبه؟ بل يسأل: من نفّذ العملية؟ ما الملف الذي تغيّر؟ ما الصلاحية المستخدمة؟ وإلى أي عنوان اتصل الجهاز؟

في هذا الدرس ستتعلم قراءة Linux من خلال أربعة آثار أمنية: الهوية، والملفات، والعمليات، والاتصالات. وستنفذ مختبرًا قانونيًا داخل جهازك دون مهاجمة أي نظام خارجي.

«إذا كنت تبدأ من الصفر، فراجع خريطة تعلم الأمن السيبراني لطالب الجامعة لتعرف موقع Linux ضمن مسار التعلم وما الذي تدرسه بعده.»

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

ما Linux؟ ولماذا يحتاجه طالب الأمن السيبراني؟

Linux ليس أداة اختراق، بل عائلة من أنظمة التشغيل المبنية على نواة Linux. وتسمى الحزم الكاملة المبنية حول النواة توزيعات، مثل Ubuntu وDebian وKali Linux.

يُستخدم Linux بكثرة في الخوادم والحوسبة السحابية والحاويات وأجهزة الشبكات ومنصات الأمن. لذلك فإن فهمه يساعدك في ثلاثة أدوار مختلفة:

• حماية خادم Linux ومراجعة إعداداته.
• تحليل جهاز أو حساب يُشتبه في تعرضه للاختراق.
• استخدام بيئة عمل أمنية لتشغيل أدوات الفحص والتحليل.

ولا يعني تثبيت Kali Linux أنك أصبحت مختبر اختراق. Kali منصة مجهزة بأدوات أمنية عديدة، لكن قيمتها الحقيقية لا تظهر قبل فهم النظام والشبكات والصلاحيات والسجلات.

ابدأ بـ Ubuntu أم Kali Linux؟

للتعلم اليومي، يمكن البدء بتوزيعة Ubuntu داخل جهاز افتراضي؛ فهي مناسبة لفهم الملفات والمستخدمين والخدمات والسجلات وإدارة الحزم.

استخدم Kali Linux عندما تحتاج إلى مختبر أمني يحتوي على أدوات جاهزة، مع إبقائه داخل شبكة معزولة. لا تجعله نظامك الأساسي لمجرد كثرة أدواته، ولا تشغّل أداة لا تعرف وظيفتها أو نطاق تأثيرها.

«قبل تجربة Ubuntu أو Kali، تعلّم كيف تنشئ مختبر أمن سيبراني منزلي آمن حتى تبقى تجاربك منفصلة عن أجهزتك وشبكتك الأساسية.»

الاختيار الأفضل للطالب

• جهاز Ubuntu افتراضي لتعلم إدارة Linux وتحليل النظام.
• جهاز Kali افتراضي منفصل للتجارب الأمنية المصرح بها.
• لقطة Snapshot نظيفة قبل كل تجربة مهمة.
• شبكة NAT أو Host-only بحسب هدف المختبر.

إذا لم تُنشئ بيئة معزولة بعد، فابدأ بدليل إنشاء مختبر أمن سيبراني منزلي آمن قبل تنفيذ التمارين.

الفكرة التي تختصر عليك Linux: ابحث عن الأثر

كل نشاط داخل النظام يترك أثرًا واحدًا أو أكثر. ولتحليل أي حالة، ابدأ بهذه الأسئلة:

1. الهوية: أي مستخدم نفّذ النشاط؟
2. الملف: ما الذي تمت قراءته أو تغييره؟
3. العملية: ما البرنامج الذي كان يعمل؟
4. الاتصال: مع أي جهاز أو خدمة تواصل؟
5. الزمن: متى بدأ النشاط ومتى انتهى؟

هذه الأسئلة أهم من حفظ عشرات الأوامر؛ لأنها تمنحك طريقة ثابتة للتحقيق حتى لو تغيرت الأداة أو التوزيعة.

ابدأ بتحديد هويتك ومكانك

افتح الطرفية Terminal ونفّذ:

whoami

يعرض هذا الأمر اسم المستخدم الحالي.

ثم نفّذ:

id

يعرض رقم المستخدم والمجموعات التي ينتمي إليها. وقد تمنح عضوية مجموعة معينة صلاحيات لا تظهر من اسم الحساب وحده.

لمعرفة مكانك الحالي:

pwd

ولعرض الملفات:

ls -la

الخيار -l يعرض التفاصيل، بينما يُظهر الخيار -a الملفات المخفية التي تبدأ أسماؤها بنقطة.

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

كيف تقرأ نظام الملفات دون أن تضيع؟

تُرتّب ملفات Linux في شجرة تبدأ من الرمز /، ولكل مجلد وظيفة تقريبية:

• /home: ملفات المستخدمين العاديين.
• /etc: إعدادات النظام والخدمات.
• /var/log: عدد من سجلات النظام والتطبيقات.
• /tmp: ملفات مؤقتة يمكن أن تستخدمها برامج ومستخدمون متعددون.
• /usr/bin: كثير من البرامج والأوامر.
• /root: المجلد الشخصي للمستخدم root.
• /proc: معلومات حية يقدمها النظام عن العمليات والنواة.

لا تحفظ الشجرة كاملة. اسأل: هل أبحث عن إعداد، أم سجل، أم ملف مستخدم، أم معلومات عن عملية؟ ثم اتجه إلى المكان المناسب.

إنشاء مساحة آمنة للتجربة

mkdir -p ~/linux-security-lab

cd ~/linux-security-lab

أنشئ ملفًا تجريبيًا:

touch notes.txt

اكتب داخله سطرًا:

echo “authorized lab only” > notes.txt

ثم اقرأه:

cat notes.txt

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

الصلاحيات: اقرأها قبل أن تغيّرها

نفّذ:

ls -l notes.txt

قد ترى نتيجة مشابهة:

-rw-r–r– 1 student student 20 Sep 12 10:30 notes.txt

كيف تُقرأ الصلاحيات؟

قسّم الصلاحيات إلى ثلاثة أجزاء:

• rw- لصاحب الملف.
• r– للمجموعة.
• r– لبقية المستخدمين.

الحروف الأساسية هي:

• r: القراءة.
• w: الكتابة أو التعديل.
• x: التنفيذ، أو الدخول عندما تكون الصلاحية على مجلد.

لجعل الملف مقروءًا ومكتوبًا لصاحبه فقط:

chmod 600 notes.txt

ثم تحقق:

ls -l notes.txt

النتيجة المتوقعة:

-rw——-

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

لا تستخدم chmod 777 باعتباره حلًا سريعًا. فهو يمنح الجميع صلاحيات واسعة، وقد يحول مشكلة تشغيل بسيطة إلى نقطة اختراق.

من يملك الملف؟

اعرض مالك الملف ومجموعته باستخدام:

ls -l

ويمكن تغيير الملكية بالأمر chown، لكن لا تستخدمه عشوائيًا:

sudo chown user:group file

المبدأ الصحيح هو أقل صلاحية لازمة: امنح الحساب أو الخدمة ما تحتاجه فقط لإنجاز المهمة، لا أكثر.

ما الفرق بين المستخدم العادي وroot؟

المستخدم root يمتلك صلاحيات واسعة جدًا. أما sudo فيسمح للمستخدم المصرح له بتنفيذ أمر محدد بصلاحيات مرتفعة.

قبل استخدام sudo اسأل:

• لماذا يحتاج هذا الأمر إلى صلاحية مرتفعة؟
• ما الملفات التي سيعدلها؟
• هل كتبت المسار بصورة صحيحة؟
• هل توجد طريقة أقل خطورة؟

لا تنسخ أمرًا من الإنترنت وتسبقه بـsudo قبل فهمه. الخطورة ليست في sudo وحده؛ بل في إعطاء أمر غير مفهوم القدرة على تعديل النظام.

العمليات: ماذا يعمل الآن؟

كل برنامج يعمل في Linux يظهر كعملية لها رقم يسمى PID.

اعرض العمليات باستخدام:

ps aux

ولعرضها بصورة متجددة:

top

وإذا كان htop مثبتًا، فإنه يقدم عرضًا أسهل:

htop

علامات تستحق الفحص

لا تبحث فقط عن اسم غريب، بل ابحث عن سياق غير طبيعي، مثل:

• عملية تعمل تحت حساب لا يناسب وظيفتها.
• استهلاك مرتفع للمعالج دون سبب واضح.
• أمر يعمل من مجلد مؤقت مثل /tmp.
• عملية بدأت في وقت حدوث المشكلة.
• برنامج يُعاد تشغيله بعد إيقافه.
• عملية لها اتصال خارجي غير متوقع.

للبحث عن عملية باسم معين:

ps aux | grep ssh

لكن تذكر أن نتيجة grep نفسها قد تظهر في القائمة. لذلك لا تعتبر كل سطر دليلًا على وجود مشكلة.

لإيقاف عملية تجريبية بصورة طبيعية استخدم:

kill PID

استبدل PID برقم العملية. ولا تبدأ مباشرة باستخدام kill -9؛ لأن الإيقاف الطبيعي يمنح البرنامج فرصة لإغلاق ملفاته وإنهاء عمله بصورة سليمة.

الخدمات: العملية التي تعود بعد إيقافها

قد توقف عملية ثم تجدها تعمل من جديد؛ لأنها مُدارة بواسطة خدمة.

لمراجعة خدمة SSH مثلًا:

systemctl status ssh

ولعرض الخدمات العاملة:

systemctl –type=service –state=running

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

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

الاتصالات: اربط العملية بالشبكة

لعرض المنافذ والاتصالات والعمليات المرتبطة بها:

sudo ss -tulpn

ماذا تعني الخيارات؟

• t لاتصالات TCP.
• u لاتصالات UDP.
• l للمنافذ التي تستمع للاتصال.
• p لإظهار العملية.
• n لإظهار الأرقام دون تحويلها إلى أسماء.

لا يعني وجود منفذ مفتوح أن الجهاز مخترق. اسأل أولًا:

• هل أعرف الخدمة التي تستمع على المنفذ؟
• هل تحتاج إلى استقبال اتصالات من الشبكة كلها؟
• هل تستمع على 127.0.0.1 فقط أم على جميع الواجهات؟
• هل توجد قاعدة جدار ناري تقيد الوصول إليها؟

لعرض عناوين الجهاز:

ip addr

ولعرض مسارات الشبكة والبوابة الافتراضية:

ip route

ولعرض خوادم DNS المستخدمة على الأنظمة التي تدعم systemd-resolved:

resolvectl status

هنا يلتقي Linux مع الدروس السابقة: الأمر ss يريك العملية والمنفذ، بينما يساعدك Wireshark في رؤية الحزم نفسها. جمع المصدرين يمنحك تفسيرًا أقوى من الاعتماد على أحدهما منفردًا.

السجلات: دفتر الأحداث وليس آلة لإعطاء الحقيقة

في الأنظمة التي تستخدم systemd، يعرض الأمر التالي السجل:

journalctl

ولعرض رسائل الإقلاع الحالي:

journalctl -b

ولعرض رسائل الخطأ وما هو أشد منها:

journalctl -p err -b

ولعرض سجل خدمة معينة:

journalctl -u ssh

ولعرض الأحداث منذ وقت محدد:

journalctl –since “2026-09-12 09:00:00”

لا تقرأ السجل من الأعلى إلى الأسفل بلا هدف. ابدأ بزمن الحادث، ثم اسم الخدمة أو العملية، ثم وسّع الفترة الزمنية إذا احتجت.

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

الأنابيب وإعادة التوجيه: ابنِ سؤالًا بدل أمر طويل

الرمز | يرسل نتيجة أمر إلى أمر آخر. مثال:

ps aux | grep ssh

وللبحث عن أخطاء داخل ملف سجل تجريبي:

grep -i “error” app.log

الخيار -i يجعل البحث غير حساس لحالة الأحرف الإنجليزية.

لعرض آخر عشرين سطرًا:

tail -n 20 app.log

ولمتابعة السطور الجديدة لحظة وصولها:

tail -f app.log

لإيقاف المتابعة اضغط:

Ctrl + C

بدل حفظ أوامر كثيرة، فكّر بهذه الصيغة:

مصدر البيانات ← تصفية النتيجة ← عرض الجزء المهم

هذه الطريقة هي أساس العمل الفعلي للمحلل داخل الطرفية.

التجزئة: هل تغير الملف؟

أنشئ بصمة للملف:

sha256sum notes.txt

احفظ القيمة، ثم أضف سطرًا:

echo “second line” >> notes.txt

أعد تنفيذ:

sha256sum notes.txt

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

لذلك يجب ربط البصمة بالزمن والملكية والسجلات.

تحديث النظام وإدارة الحزم

على Ubuntu وDebian والتوزيعات المبنية عليهما:

sudo apt update

sudo apt upgrade

الأمر الأول يحدّث معلومات الحزم المتاحة، والثاني يثبت الترقيات المناسبة.

قبل تثبيت أي أداة اسأل

• هل المصدر مستودع رسمي وموثوق؟
• ما الحزم الإضافية التي ستُثبت؟
• هل تحتاج الأداة فعلًا؟
• هل يمكن تجربتها داخل لقطة افتراضية أولًا؟

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

تمرين دليل التقنية: أنشئ بطاقة هوية أمنية للنظام

هذه الممارسة تحول الأوامر المنفصلة إلى تقرير يمكن مقارنته لاحقًا.

الخطوة الأولى: إنشاء مجلد التقرير

mkdir -p ~/linux-security-lab/baseline

cd ~/linux-security-lab/baseline

الخطوة الثانية: تسجيل الوقت

date > baseline.txt

الخطوة الثالثة: إضافة هوية المستخدم

whoami >> baseline.txt

id >> baseline.txt

الخطوة الرابعة: إضافة معلومات النظام

uname -a >> baseline.txt

الخطوة الخامسة: إضافة معلومات الشبكة

ip addr >> baseline.txt

ip route >> baseline.txt

الخطوة السادسة: إضافة المنافذ المستمعة

sudo ss -tulpn >> baseline.txt

الخطوة السابعة: إضافة العمليات

ps aux >> processes.txt

الخطوة الثامنة: إنشاء بصمة للتقرير

sha256sum baseline.txt > baseline.sha256

أصبحت لديك الآن بطاقة حالة مرجعية Baseline للجهاز.

أجرِ تغييرًا قانونيًا بسيطًا داخل المختبر، مثل تشغيل خدمة تعرفها، ثم أنشئ بطاقة ثانية وقارن النتيجتين:

diff baseline.txt baseline-after.txt

القيمة الحقيقية ليست في اكتشاف اختلاف فقط، بل في تفسيره:

• ما الذي تغيّر؟
• هل التغيير متوقع؟
• من سببه؟
• هل ظهر أثره في العملية والمنفذ والسجل؟
• هل يجب توثيقه أم التراجع عنه؟

هذه هي بداية عقلية التحقيق، وهي مهارة أكثر فائدة من استعراض قائمة طويلة من أوامر Linux.

سيناريو تحليلي مصغر

افترض أن جهاز المختبر أصبح بطيئًا وظهر اتصال غير متوقع. لا تبدأ بحذف ملفات أو إيقاف خدمات عشوائيًا. اتبع التسلسل الآتي:

1. سجّل الوقت الحالي باستخدام date.
2. تحقق من المستخدم الحالي باستخدام whoami وid.
3. راجع العمليات باستخدام ps aux أو top.
4. اعرض المنافذ والعمليات باستخدام sudo ss -tulpn.
5. افحص حالة الخدمة المشتبه بها باستخدام systemctl status.
6. راجع سجلها ضمن الفترة الزمنية المناسبة باستخدام journalctl.
7. دوّن النتائج قبل إجراء أي تعديل.
8. إذا احتجت إلى فحص الحزم، نفّذ ذلك داخل مختبرك باستخدام Wireshark.

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

أخطاء يجب أن يتجنبها الطالب

• تنفيذ أوامر مجهولة بصلاحية sudo.
• استخدام chmod 777 لحل مشكلات الصلاحيات.
• تنزيل سكربت وتشغيله مباشرة دون قراءته.
• اعتبار كل منفذ مفتوح علامة اختراق.
• إيقاف العمليات بالقوة قبل توثيقها.
• إجراء التجارب على شبكة الجامعة أو شبكة عامة.
• تشغيل Kali Linux خارج شبكة مختبر معزولة.
• التقاط بيانات أشخاص آخرين دون تصريح.
• حفظ كلمات المرور أو مفاتيح الوصول داخل ملفات المشروع.
• نشر سجلات أو لقطات تحتوي على عناوين أو بيانات شخصية.

مشروع عملي مقترح: تقرير حالة Linux

أنشئ تقريرًا قصيرًا داخل مختبرك يتضمن:

• اسم التوزيعة وإصدارها.
• المستخدم الحالي والمجموعات التي ينتمي إليها.
• خمسة ملفات مهمة وصلاحياتها.
• خمس عمليات وسبب تشغيل كل واحدة.
• المنافذ المستمعة والخدمات المرتبطة بها.
• سجل خدمة واحدة خلال عشر دقائق.
• بصمة SHA-256 لملف التقرير.
• مقارنة بين الحالة قبل تشغيل خدمة وبعدها.
• تفسيرك للتغيير، وليس مجرد نسخ النتائج.

احذف أسماء المستخدمين والعناوين وأي بيانات حساسة قبل نشر المشروع على GitHub.

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

الخلاصة

لا تحتاج في البداية إلى حفظ مئات أوامر Linux. تحتاج إلى طريقة تفكير منظمة تربط بين الهوية والملف والعملية والاتصال والزمن.

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

عندما تستطيع وصف ما يعمل في جهاز Linux، ومن شغّله، وما الملفات التي يستخدمها، وما الاتصالات التي أنشأها، تكون قد انتقلت من مستخدم للأوامر إلى محلل يفهم النظام.