إن كنتَ لا تريدُ القصةَ الآن، وتريدُ فقط أن تعرفَ ما الأمرُ وكيفَ تُفعِّله، فهذا القسمُ لك. وإن أردتَ العودةَ للقصةِ لاحقاً، فهي تنتظرُك.

جهازُك العامل بنظام لينكس يحتاجُ إلى نوعَين من الحماية، كلٌّ منهما يحرسُ شيئاً مختلفاً:

الأول — جدارُ الحماية firewall:

يحرسُ البابَ الخارجي. يقرِّرُ أيُّ الاتصالاتِ القادمةِ من الشبكةِ يُسمَحُ لها بالدخولِ إلى جهازِك، وأيُّها يُرَدُّ. مثلُ الحارسِ عند بوابةِ المبنى.

الثاني — نظامُ التحكمِ الإلزامي في الوصول (MAC):

يحرسُ الداخل. بعدَ أن يدخلَ البرنامجُ، يُقرِّرُ ما الذي يُسمَحُ له بلمسِه وفتحِه والوصولِ إليه داخلَ النظام. مثلُ الحارسِ داخلَ المبنى الذي يمنعُك من دخولِ غرفٍ بعينِها حتى لو دخلتَ المبنى.

ما التوزيعةُ التي تستخدمُها وما وضعُها؟

كيفَ تعرفُ إن كانَ جدارُ الحمايةِ يعملُ؟

إن كنتَ على Ubuntu أو Mint أو Debian:
افتَح الطرفيةَ واكتُب:

sudo ufw status

إن ظهرَ لكَ Status: inactive فجدارُ الحمايةِ مُطفَأ.

إن كنتَ على Fedora أو RHEL أو openSUSE:

sudo firewall-cmd --state

إن ظهرَ running فأنتَ محمي.

إن كنتَ على Arch أو CachyOS:

sudo nft list ruleset

إن كانَت القائمةُ فارغةً، فلا قواعدَ فعَّالة.

كيفَ تُفعِّلُ جدارَ الحمايةِ إن كانَ مُطفَأً؟

على Ubuntu / Mint / Debian — تفعيلُ UFW:

فعِّل جدارَ الحماية

sudo ufw enable

اسمَح بالمتصفحِ والويب

sudo ufw allow 80
sudo ufw allow 443

تحقَّق من الوضع

sudo ufw status verbose

على Arch / CachyOS — تفعيلُ nftables:

ثبِّت وفعِّل nftables

sudo systemctl enable nftables
sudo systemctl start nftables

أو ثبِّت UFW وفعِّله

sudo pacman -S ufw
sudo ufw enable

على Fedora / RHEL — firewalld مُفعَّلٌ أصلاً، لكن لإضافةِ خدمة:

اسمَح بـHTTP مثلاً

sudo firewall-cmd --add-service=http --permanent
sudo firewall-cmd --reload

تحقَّق من الخدماتِ المسموحِ بها

sudo firewall-cmd --list-all

كيفَ تتحقَّقُ من نظامِ MAC؟

على Ubuntu / Debian / Mint — التحقُّقُ من AppArmor:

sudo apparmor_status

إن رأيتَ ملفاتِ تعريفٍ في وضعِ “enforce” فالنظامُ يعمل.

على Fedora / RHEL — التحقُّقُ من SELinux:

getenforce

إن ظهرَ Enforcing فأنتَ محمي.
إن ظهرَ Permissive فالنظامُ يراقبُ لكنه لا يمنع.
إن ظهرَ Disabled فهو مُطفَأ كلياً.

لتفعيلِ SELinux إن كانَ في وضعِ Permissive:

sudo setenforce 1

وللتغييرِ الدائمِ عدِّل الملف:

sudo nano /etc/selinux/config

غيِّر السطر إلى:
SELINUX=enforcing

القاعدةُ البسيطة

إن كنتَ على Ubuntu أو Mint أو Debian، اكتُب الآن:

sudo ufw enable

هذا وحدَه يرفعُ مستوى حمايتِك بشكلٍ فوري.

إن كنتَ على Fedora أو RHEL أو openSUSE، لا تفعَل شيئاً — أنتَ محميٌّ افتراضياً.

إن كنتَ على Arch أو CachyOS، اختَر أداةً وفعِّلها — النظامُ لا يختارُ عنك.

ماذا لو كسرَ الجدارُ شيئاً؟

إن أوقفَ UFW برنامجاً تحتاجُه، اعرِف المنفذَ الذي يستخدمُه وافتحه:

• افتح منفذاً بعينِه

sudo ufw allow 8080

• أو اعرِف ما الذي يُوقِفُه

sudo ufw status numbered

إن أوقفَ SELinux تطبيقاً، راجِع السجلاتِ:

sudo ausearch -m avc -ts recent

# or

sudo journalctl -xe | grep -i selinux

الآن إن شئتَ القصة الكاملة — من أينَ جاءَت هذه الأدوات، ومن بناها، ولماذا بعضُها مُطفَأٌ وبعضُها مُشغَّل، وما الفلسفةُ الكاملةُ وراءَ كلِّ قرارٍ — فاستمِر في القراءة.

في البَدءِ لم تكن أسوار (١٩٩١–١٩٩٨)

في بداية لينكس عام ١٩٩١، كان الأمنُ فكرةً لاحقة، هامشًا على هامش. كانت الشبكةُ يومذاك قريةً صغيرة، يسكنُها الأكاديميّونَ والباحثونَ والهُواة. أُناسٌ يثقُ بعضُهم ببعض، أو على الأقلّ لم يكن لديهم ما يدعوهم إلى الشكّ. كان لينكس لُعبةً، ثمّ فُضولًا، ثمّ أداةً. ثمّ، على حينِ غفلةٍ من الزمن، أساسًا تقومُ عليه حضارةٌ رقميّةٌ ناشئة.

لكنّ القريةَ صارت مدينة. والمُدنُ تستقطبُ اللصوص.

كانت المحاولاتُ الأولى لتحصينِ لينكس متواضعة، مُستعارةً من أفكارِ الآخرين. وصلَ ipfwadm (إدارةُ جدارِ حمايةِ بروتوكولِ الإنترنت) مع نواةِ لينكس ١.٢.١، وكان نسخةً لينكس من مفهومِ ipfw الذي وُلِدَ في عالمِ يونكس BSD. مَنَحَ المُديرينَ الأوائلَ القدرةَ على أن يقولوا: هذه الرزمةُ تمرّ، وتلك تُمنَع. كان بدائيًّا. كان يدويًّا. كان أشبهَ ببناءِ سورٍ من أيّ حجارةٍ تقعُ تحتَ اليد.

ثمّ جاء ipchains مع نواةِ لينكس ٢.٢. كان أفضلَ، سلاسلُ من القواعد، مُرشِّحاتٌ مُتراكبةٌ بعضُها فوقَ بعض، هندسةٌ أكثرُ تعمُّدًا ونُضجًا. لكنّ ipchains كان عديمَ الحالة: كان يفحصُ كلَّ رزمةٍ بمعزلٍ عن سواها، بلا ذاكرة، بلا سياق. لم يكن يعرفُ أنّ هذه الرزمةَ الداخلةَ هي ردٌّ على اتّصالٍ أنتَ بادرتَ به. كلُّ رزمةٍ كانت غريبًا يُحاكَمُ بأوراقِهِ وحدها، بلا أيِّ اعتبارٍ لما سبقه. هذا القصورُ الجوهريُّ هو ما سيدفعُ الثورةَ التالية.

وفي تلك السنواتِ المبكّرة، لم يكن ثمّةَ تحكُّمٌ إلزاميٌّ بالوصول البتّة. كان نموذجُ الصلاحيّاتِ: مُستخدِم، مجموع، آخرون؛ قراءة، كتابة، تنفيذ، يُعتبَرُ كافيًا. وكان الجِذرُ (root) بمثابةِ إلهٍ فعليّ، لا يُقيِّدُهُ إلّا الحدودُ الغليظةُ لصلاحيّاتِ يونكس التقليديّة. فإن جرى برنامجٌ بصلاحيّاتِ الجِذر، استطاعَ أن يفعلَ كلَّ شيءٍ تقريبًا. لم يكن هناك مفهومٌ يقول: “نعم، أنتَ الجِذر، ولكنّكَ مع ذلك لا تستطيعُ المساسَ بهذا الملفّ، لأنّ السياسةَ تمنعك.”

تلك كانت براءةُ ما قبلَ السقوط.

صعودُ Netfilter و iptables — الجدارُ الحقيقيُّ الأوّل (١٩٩٨–٢٠١٢)

لم يُبنَ الجدارُ التالي بِيَدِ لجنة. بل بَنَتهُ — في معظمِهِ — يدُ رجلٍ واحد. ثمّ أعادَ الرجلُ ذاتُهُ بناءَه.

راستي راسِل Rusty Russell، مطوِّرُ نواةٍ أستراليّ، هو الذي كتبَ ipchains لنواةِ ٢.٢. كان يعرفُ عيوبَهُ أحسنَ من أيِّ إنسانٍ آخر، لأنّه هو الذي صنعها. فبدأ من سنة ١٩٩٨، يُصمِّمُ ما يخلُفُه: إطارًا جديدًا سمّاه netfilter، وأداةً جديدةً في فضاءِ المُستخدِم سمّاها iptables.
وفي عام ١٩٩٩ أسّسَ فريقَ Netfilter الأساسيّ ليرعى المشروع. أُدمِجَ الكودُ في سلسلةِ التطويرِ لينكس ٢.٣ في مارس ٢٠٠٠، وحينَ صَدَرت نواةُ لينكس ٢.٤ في الرابعِ من يناير ٢٠٠١، وصلَ netfilter و iptables معيارًا جديدًا.

ثمّة شيءٌ دراميٌّ في هذا: الرجلُ الذي بنى الجدارَ نظرَ إليه، رأى عيوبَه، هدمَهُ، وبنى بَدَلَهُ جدارًا أفضل. هذا نادرٌ في أيِّ حقل. أغلبُ المُبدعينَ يُدافعونَ عن صنيعِهم. أمّا راسِل فاستبدَلَ صنيعَه.

الابتكارُ الجوهريُّ كان الحالةَ statefulness . حيثُ كان ipchains يفحصُ كلَّ رزمةٍ كجزيرةٍ منعزلة، فإنّ iptables عَبرَ نظامِ تتبُّعِ الاتّصالات conntrack كان يتذكَّر. كان يعرفُ أنّ رزمةً قادمةً على المنفذِ ٤٤٣٨٧ هي ردٌّ على طلبٍ أرسلَهُ مُتصفِّحُك. كان يُميِّزُ بينَ رزمةٍ تنتمي إلى محادثةٍ قائمةٍ ورزمةٍ هي غريبٌ يطرقُ الباب بلا دعوة. هذا التحوُّلُ المعماريُّ الواحد — الذاكرة — حوَّلَ جدارَ لينكسِ الناريَّ من أداةٍ فَظّةٍ إلى شيءٍ قادرٍ على التمييز.

Netfilter كان المحرِّكَ المدفونَ عميقًا في النواة: خطّافاتٌ عند كلِّ نقطةٍ يمكنُ فيها اعتراضُ رزمةٍ شبكيّة، أو فحصُها، أو تعديلُها، أو قبولُها، أو إسقاطُها. كان أنيقًا في هندستِهِ وقاسيًا في تعقيده. أمّا iptables فكان الأمرَ الذي يواجِهُ الإنسان. الطريقةُ التي يُخاطبُ بها المُديرُ ذلك المحرِّك، فيكتبُ القواعدَ واحدةً واحدة، سلسلةً سلسلة.

وصارَ iptables أُسطوريًّا. لا لأنّه كان محبوبًا، بل لأنّه كان في كلِّ مكان. كلُّ خادمِ لينكس، كلُّ مُوجِّهٍ (راوتر) يعملُ بلينكس، كلُّ جهازِ جدارٍ ناريّ . كان iptables هو اللغةَ التي يتحدّثونها. حفظَ مُديرو الأنظمةِ صياغتَهُ كما يحفظُ الرهبانُ أسفارَهم: لا لأنّها كانت جميلة، بل لأنّها كانت ضرورة.

ثلاثةُ أسطر:
1- اجعلِ السياسةَ المبدئيّةَ إسقاطَ كلِّ شيء.
2- اسمحْ بالردودِ على الاتّصالاتِ التي بدأتَها.
3- اسمحْ بِــ SSH.

1- iptables -P INPUT DROP
2- iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
3- iptables -A INPUT -p tcp --dport 22 -j ACCEPT

في الواقع، كانت إعداداتُ iptables الحقيقيّةُ تتمدّدُ إلى مئاتٍ، بل أحيانًا آلاف. من الأسطر: مُتشابكة، هَشّة، مُرعبةٌ في التعديل. قاعدةٌ واحدةٌ خاطئةٌ وتحبسُ نفسَكَ خارجَ خادمِك، تُحدِّقُ في مُؤشِّرٍ يومِضُ على طرفيّةٍ بعيدةٍ . وقاعدةٌ واحدةٌ مفقودةٌ وتتركُ البابَ مفتوحًا على مِصراعَيه.

كان iptables جدارَ المملكةِ الحجريّ: متينًا، مُجرَّبًا، وبائسًا في البناء.

لكنّ هاهنا يكمنُ السؤالُ الفلسفيُّ الذي لم يُجِب عنه iptables قطّ: الجدارُ يصدُّ الغرباء، لكنّ ماذا عن الأعداءِ الذينَ هم أصلًا في الداخل؟

تدخلُ وكالةُ الأمنِ القوميّ SELinux وفلسفةُ الارتياب (٢٠٠٠–٢٠٠٣)

في أواخرِ عام ٢٠٠٠، فعلت وكالةُ الأمنِ القوميِّ الأمريكيّة الـNSA، شيئًا غيرَ متوقَّع. أطلقت شِفرة. شِفرةً مفتوحةَ المصدر. مجموعةَ رُقَعٍ لنواةِ لينكس تُنفِّذُ مفهومًا يُدعى التحكُّمَ الإلزاميَّ بالوصول Mandatory Access Control.

سمَّوهُ SELinux: لينكس مُعزَّزُ الأمان.

جاء الإصدارُ العلنيُّ الأوّلُ في الثاني والعشرينَ من ديسمبر ٢٠٠٠. نموذجٌ أوّليّ، إثباتُ مفهوم، إعلانُ نوايا. لكنّ البنيةَ المعماريّةَ استغرقت سنواتٍ لتنضج. فإطارُ وحداتِ أمانِ لينكس LSM: نظامُ الخطّافاتِ المُعياريُّ الذي يسمحُ لتطبيقاتِ التحكُّمِ الإلزاميِّ بالانغراسِ في النواةِ دونَ أن يحتاجَ كلٌّ منها إلى رُقَعٍ جراحيّةٍ خاصّةٍ به. لم يُدمَج في النواةِ الرسميّةِ إلّا في ديسمبر ٢٠٠٣، وجرى تكييفُ SELinux ليعملَ من خلاله.

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

في ظلِّ SELinux، كلُّ ملفٍّ وكلُّ عمليّةٍ وكلُّ مَقبَسٍ وكلُّ منفذٍ يحملُ وَسْمًا، سياقًا أمنيًّا. وسياسةٌ مركزيّةٌ تُحدِّد، بدقّةٍ مُطلقة، أيَّ العمليّاتِ المَوسومةِ يجوزُ لها أن تتعاملَ مع أيِّ المواردِ المَوسومة، وبأيِّ صورة. خادمُ الويب المَوسومُ بِـ ـhttpd_t يستطيعُ قراءةَ الملفّاتِ المَوسومةِ بِــ httpd_sys_content_t، لكنّه لا يستطيعُ قراءةَ دليلِكَ الشخصيّ، حتّى لو منحتهُ ثغرةٌ صلاحيّاتِ الجِذر. السياسةُ تمنعه. والنواةُ تُنفِّذ.

هذا لم يكن جدارًا ناريًّا. SELinux لا يُعنى بالرزمِ القادمةِ من الشبكة. بل يُعنى بِما يحدثُ بعدَ وصولِ الرزمة . بما يُسمَحُ للعمليّةِ التي تلقّتها أن تفعل. الجدارُ الناريُّ سورٌ حولَ المدينة. أمّا SELinux فمجموعةُ قوانينَ تُحدِّدُ لكلِّ مُواطنٍ داخلَ المدينةِ ما يجوزُ له أن يلمسَ ويحملَ ويفتحَ وينطقَ به.

الصراع

كانت SELinux بارعةً ومُعذِّبةً بالمقدارِ ذاته.

كانت السياساتُ شاسعة، مُتشعِّبة، شبهَ مُستعصيةٍ على الفهمِ بالنسبةِ للمُديرينَ العاديّين. حينَ كان شيءٌ يتعطّل، وكانت الأشياءُ تتعطّلُ بلا انقطاعٍ في السنواتِ الأولى. كانت رسائلُ الخطأ غامضة. وأدواتُ التشخيصِ بدائيّة. والوثائقُ مكتوبةٌ بأيدي باحثي أمنٍ لباحثي أمن، لا لمُديرِ أنظمةٍ في شركةٍ صغيرةٍ لا يريدُ إلّا أن يُقدِّمَ Apache صفحاتِ الويب.

وهكذا بدأ التمرُّدُ الكبيرُ على SELinux: عبرَ الإنترنت، في المنتديات، في التدوينات، في قنواتِ IRC، صارت النصيحةُ الأكثرُ تداوُلًا في عالمِ لينكس:

“اجعل SELinux في وضعِ التساهل.”

“عطِّل SELinux.”

"setenforce 0 وامضِ في حياتك."

كان ذلك أشبهَ بنزعِ كاشفِ الدُّخانِ لأنّ صفيرَهُ أزعجك. ومع ذلك، لسنواتٍ طويلة، فعلَ ذلك عددٌ لا يُحصى من المُديرين. أطفأوا أعقدَ نظامِ تحكُّمٍ إلزاميٍّ بُنيَ لنظامِ تشغيلٍ عامّ، لأنّه كان صعبًا جدًّا، ومُربكًا جدًّا، وكثيرَ الاحتكاكِ بينهم وبينَ ما يُحاولونَ إنجازَه.

لكنّ ردهات لم تستسلم قطّ. تبنّت SELinux نظامًا افتراضيًّا للتحكُّمِ الإلزاميِّ في RHEL وفيدورا. ضخّت مواردَ في سياساتٍ أفضل، وأدواتٍ أرقى audit2allow ، sealert ، semanage وتدريجيًّا، على مدار عقدٍ من الزمن، صارت SELinux قابلةً للإدارة. ليست سهلة. لن تكونَ سهلةً أبدًا. لكنّها قابلةٌ للإدارة. مُعلِّمةٌ صارمةٌ أنتجت في النهايةِ تلامذةً أقوياء.

ووجدت SELinux تصديقَها النهائيَّ في مكانٍ غيرِ متوقَّع: أندرويد. تبنّت غوغل SELinux نظامًا للتحكُّمِ الإلزاميِّ في منصّتِها المحمولة، وصارَ الإنفاذُ الكاملُ هو الوضعَ الافتراضيَّ ابتداءً من أندرويد ٥.٠ عام ٢٠١٤. مشروعُ أندرويد المفتوحُ المصدر (AOSP) يُوزَّعُ بسياساتِ SELinux مُفعَّلةٍ افتراضيًّا، وسياساتُ غوغل المُخصَّصة — المبنيّةُ فوقَ هندسةِ وكالةِ الأمنِ القوميّ لكنّها مُكيَّفةٌ تكييفًا واسعًا للعالمِ المحمول — تعملُ الآنَ عبرَ أجهزةِ أندرويد السائدةِ بحجمٍ يُقاسُ بالمليارات.

المفارقةُ تستحقُّ أكثرَ من نظرةٍ عابرة. أكثرُ الأجهزةِ خصوصيّةً التي يملكُها معظمُ البشر، الهاتفُ الذي يحتضنُ رسائلَهم وصوَرَهم وسجلَّ مواقعِهم ونبضاتِ قلوبِهم. يعملُ بمنظومةِ أمانٍ وُلِدت هندستُها المعماريّةُ في أروقةِ أقوى أجهزةِ استخباراتِ الإشاراتِ في العالم. لكن ماذا يعني هذا للثقة؟ يعني، ربّما أنّ أصلَ الأداةِ لا يُحدِّدُ مصيرَها. فغوغل لم تُلقِ SELinux على أندرويد كما هي دونَ تعديل؛ بل كتبت آلافَ الأسطرِ من السياساتِ المُخصَّصة، وكيَّفتها لعالمٍ لم تُصمِّمه وكالةُ الأمنِ القوميّ قطّ، وبذلك جعلت التقنيةَ ملكَها. أو بالأحرى جعلتها ملكَ الجميع. بنت الوكالةُ المحرِّك. وأعادت غوغلُ بناءَ السيّارةِ حوله. والآنَ تحملُ تلك السيّارةُ البشريّة.

استراحة: حُرّاسٌ آخرونَ نسيَهُمُ التاريخ

قبلَ أن نمضيَ إلى AppArmor، اعترافٌ لا بدّ منه: هذه الحكاية، كسائرِ الحكايات، تتركُ أُناسًا خارجَ الإطار.

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

grsecurity وPaX، اللذان طوَّرهما ابتداءً من ١٩٩٩ بالدرجةِ الأولى براد سبنغلر Brad Spengler وفريقُ PaX، كانا مجموعتَي رُقَعٍ للنواةِ نفَّذتا أفكارًا لم تكن النواةُ الرسميّةُ قد تبنَّتها بعدُ: التوزيعُ العشوائيُّ لتخطيطِ فضاءِ العناوين ASLR ، ومناطقُ الذاكرةِ غيرِ القابلةِ للتنفيذ، وفصلُ الامتيازاتِ المُشدَّد، ودفاعاتٌ أخرى ضدَّ فئاتٍ كاملةٍ من الثغرات. كانا، في أوجهٍ كثيرة، سابقَين لزمانِهما. يدفعانِ النواةَ نحوَ وضعيّةٍ أمنيّةٍ لن تتبنّاها النواةُ الرسميّةُ إلّا تدريجيًّا، ميزةً ميزة، على مدى العَقدِ التالي.

لم تُدمَج grsecurity في النواةِ الرسميّةِ قطّ. ظلّت رُقعةً من طرفٍ ثالث، تستخدمُها التوزيعاتُ الحريصةُ على الأمانِ والمُديرونَ الذين لا يثقونَ إلّا بأصلبِ الأهداف. علاقتُها بمجتمعِ النواةِ الرسميّةِ كانت متوتّرة، بل مريرةً أحيانًا، وبحلولِ أواخرِ عَقدِ ٢٠١٠ انتقلت إلى نموذجِ وصولٍ مُقيَّدٍ حدَّ من انتشارِها أكثر.

لكنّ أفكارَها — كالتوزيعِ العشوائيِّ لتخطيطِ فضاءِ العناوين (ASLR)، والتوزيعِ العشوائيِّ لعناوينِ النواة (KASLR)، وحمايةِ الذاكرةِ المُشدَّدة — تسرَّبت إلى النواةِ الرسميّةِ على أيّ حال، وتبنّاها مطوِّرونَ آخرونَ وأعادوا تنفيذَها. كانت grsecurity المعماريَّ الذي استُخدِمت مُخطَّطاتُهُ بلا إسنادِ فضل، والنبيَّ المُكرَّمَ في كلِّ مكانٍ إلّا في المعبد.

وهناك أيضًا وضعُ الحوسبةِ الآمنة seccomp الذي وصلَ بهدوءٍ في نواةِ لينكس ٢.٦.١٢ عام ٢٠٠٥، ثمّ وُسِّعَ لاحقًا إلى seccomp-bpf عام ٢٠١٢، ليسمحَ بترشيحٍ دقيقٍ لأيِّ استدعاءاتِ نظامٍ يُسمَحُ للعمليّةِ بتنفيذِها. إن كانت SELinux مجموعةَ القوانينِ التي تُحدِّدُ أيَّ المواردِ يجوزُ للعمليّةِ الوصولُ إليها، فإنّ seccomp هو مجموعةُ القوانينِ التي تُحدِّدُ أيَّ الأفعالِ يجوزُ للعمليّةِ حتّى أن تُحاوِلَها.
هو ما يستخدمُهُ دوكر لتقييدِ الحاويات. وما يستخدمُهُ كروم وفايرفوكس لعزلِ محرِّكاتِ العرضِ في صناديقِ . هو قطعةٌ أساسيّةٌ في منظومةِ أمانِ الحاوياتِ الحديثة، وفي أندرويد يعملُ جنبًا إلى جنب مع SELinux. حارسان يُراقبانِ أبوابًا مختلفة.

هذه ليست هوامشَ ثانويّة. هي جزءٌ من المشروعِ الفلسفيِّ ذاته: الإدراكُ البطيءُ والمرير بأنّ نواةً تثقُ بعمليّاتِها هي نواةٌ تنتظرُ أن تُخان.

AppArmor — المُتمرِّدُ الوديع (١٩٩٨–الحاضر)

لم يكن الجميعُ مؤمنًا بأنّ نَهجَ SELinux هو النَّهجُ الصائب. أو بالأدقّ: لم يكن الجميعُ مؤمنًا بأنّ كلَّ تعقيدِ SELinux كان ضروريًّا.

في أواخرِ التسعينيّات، طوَّرت شركةٌ تُدعى Immunix مقاربةً بديلةً للتحكُّمِ الإلزاميِّ بالوصول. سمَّوها SubDomain. كانت أبسط. كانت ألطف. بدلًا من وسمِ كلِّ كائنٍ في نظامِ الملفّاتِ بأكملِهِ بسياقٍ أمنيّ، كانت SubDomain تعملُ بِـمسارِ الملفّ. تكتبُ ملفَّ تعريفٍ لبرنامجٍ (لنقُل /usr/sbin/nginx) وفي ذلك الملفِّ تُدرِجُ المساراتِ التي يُسمَحُ له بالوصولِ إليها، والقدراتِ التي يستطيعُ استخدامَها، والإجراءاتِ الشبكيّةِ التي يُبيحُها له. هذا كلُّ شيء.

لا إعادةَ وسمٍ لنظامِ الملفّات. لا سياسةَ مركزيّةً مُهيبة. لا أزمةَ حينَ تُضيفُ دليلًا جديدًا.

في عام ٢٠٠٥، استحوذت نوفِل على Immunix، وبُعِثت SubDomain من جديدٍ باسمِ AppArmor. لم يكن تغييرُ الاسمِ تجميليًّا وحسب، بل أشارَ إلى تحوُّلٍ من مُنتَجِ أمانٍ مُتخصِّصٍ إلى مُكوِّنٍ جوهريٍّ في استراتيجيّةِ نوفِل لنظامِ SUSE Linux.

لكنّ طريقَ AppArmor إلى النواةِ الرسميّةِ لم يكن ممهَّدًا. حينَ قُدِّمت للإدراج، واجهت مقاومةً شرسة. لا سيّما من مطوِّرينَ ينتمونَ إلى مشروعِ SELinux، احتجّوا بأنّ الأمانَ المبنيَّ على المسارِ أضعفُ جوهريًّا من الأمانِ المبنيِّ على الوسم. الاعتراضاتُ التقنيّةُ كانت حقيقيّة: المساراتُ يمكنُ تمويهُها عبرَ الوصلاتِ الرمزيّة، ونقاطِ الربطِ المزدوجة، والوصلاتِ الصلبة، والتحكُّمُ بالمسارِ قد يكونُ أكثرَ حساسيّةً للأخطاءِ تحتَ إعادةِ التسميةِ والربطِ والتسمياتِ المتعدّدةِ من التحكُّمِ بالوسم. والاعتراضاتُ السياسيّةُ كانت حقيقيّةً أيضًا: كان مجتمعُ النواةِ يُطلَبُ منه صيانةُ نظامَي تحكُّمٍ إلزاميٍّ بمعماريَّتَينِ مختلفتَينِ جذريًّا، وبعضُهم رأى أنّ ذلك نظامٌ زائدٌ عن الحاجة.

رُفِضت AppArmor من النواةِ الرسميّة. ثمّ أُعيدَ تقديمُها. ثمّ نُوقِشت. ثمّ نُقِّحت. استغرقت العمليّةُ سنوات. وأُدمِجت أخيرًا في النواةِ الرسميّةِ في لينكس ٢.٦.٣٦، الصادرةِ في أكتوبر ٢٠١٠. أي بعدَ عقدٍ كاملٍ من الإصدارِ العلنيِّ الأوّلِ لِـ SELinux.

الانقسامُ الفلسفيّ

ها هنا يتعمّقُ الصراع، لأنّ المعركةَ بينَ SELinux وAppArmor لم تكن قطّ معركةً تقنيّةً محضة. كانت فلسفيّة.

SELinux قالت: “الأمنُ يجبُ أن يكونَ شاملًا. كلُّ كائنٍ يجبُ أن يُوسَم. كلُّ تفاعلٍ يجبُ أن تحكمَهُ السياسة. ثمنُ ذلك التعقيد، لكنّ جائزتَهُ الاكتمال. إن لم تُوسِم كلَّ شيء، فثمّةَ ثغرات. والثغراتُ هي حيثُ يسكنُ المُهاجِمون.”

AppArmor قالت: “الأمنُ يجبُ أن يكونَ عمليًّا. إن كان النظامُ معقَّدًا إلى الحدِّ الذي يدفعُ المُديرينَ إلى تعطيلِه، فلن تكونَ قد حقَّقتَ شيئًا. نظامٌ أبسطُ يستخدمُهُ الناسُ فعلًا أكثرُ أمانًا في الواقعِ من نظامٍ مثاليٍّ يُطفئُهُ الناس.”

هذا جدلٌ قديمٌ في شؤونِ البشر: التوتُّرُ بينَ المثاليِّ والممكن. كانت SELinux الصَّرْح، صمَّمها معماريّونَ يفهمونَ كلَّ حجر. وكانت AppArmor الكوخ، بنَتهُ أيدٍ تعرفُ الخشبَ والطقس.

وكان كلا الطرفَينِ على حقّ. وكان كلا الطرفَينِ على خطأ. ولم يُنتِج أيُّ طرفٍ التوليفةَ، النظامَ الذي هو شاملٌ وقابلٌ للاستخدامِ في آن. حاولَ آخرون: TOMOYO Linux، نظامُ تحكُّمٍ إلزاميٍّ آخرُ مبنيٌّ على المسارِ أُدمِجَ في النواةِ عام ٢٠٠٩. و SMACK (نواةُ التحكُّمِ الإلزاميِّ المُبسَّطة)، نظامُ وسمٍ بسيطٌ صُمِّمَ للأجهزةِ المُدمَجة. كلٌّ منهما مثَّلَ نقطةً مختلفةً على الطيفِ بينَ شموليّةِ SELinux وبساطةِ AppArmor. ولم يُزِح أيٌّ منهما أيًّا من المُتصدِّرَين.

ربّما التوليفةُ غيرُ موجودة. ربّما التوتُّرُ بينَ الشمولِ وسهولةِ الاستخدامِ ليسَ مشكلةً تُحَلّ بل حالةً تُدار . كالتوتُّرِ بينَ الحريّةِ والنظامِ في المُجتمع. لا تُبدِّدُه. تُبحِرُ فيه.

أوبونتو اختارت AppArmor. قرَّرَت كانونيكال أنّ لتوزيعةٍ مُوجَّهةٍ لسطحِ المكتب، تسعى لسهولةِ الاستخدام، كانت بساطةُ AppArmor هي المقايضةَ الصائبة. شُحِنت مُفعَّلةً افتراضيًّا، تُشغِّلُ ملفّاتِ تعريفٍ للخدماتِ الأساسيّة، وأغلبُ مُستخدِمي أوبونتو لم يعلموا قطّ بوجودِها. وهذا تحديدًا كان المطلوب.

openSUSE أيضًا احتضنت AppArmor لسنوات. كانت جزءًا من العائلة. استثمرت فيها SUSE ونوفِل، وكانت تلائمُ فلسفةَ سطحِ مكتبِ openSUSE.

UFW — حُلمُ البساطة (٢٠٠٨–الحاضر)

بينما كانت SELinux وAppArmor تتجادلانِ حولَ ما يستطيعُ البرنامجُ فعلَه، ظلَّ سؤالُ أيِّ الرزمِ يجوزُ لها أن تدخلَ الآلةَ خاضعًا لصياغةِ iptables القاتمة. ولمعظمِ مُستخدِمي أوبونتو كان iptables جدارًا من الطلاسمِ المُستعصية.

فابتدعت كانونيكال ما سمَّتهُ UFW: الجدارُ الناريُّ غيرُ المُعقَّد.

الاسمُ بحدِّ ذاتِهِ كان بيانًا. في عالمٍ تُعتبَرُ فيه عبارةٌ كـ

iptables -A INPUT -p tcp -s 192.168.1.0/24 --dport 443 -m state --state NEW,ESTABLISHED -j ACCEPT

أمرًا طبيعيًّا،

قالت UFW:

ufw allow 443

هذا كلُّ شيء. سطرٌ واحد. اسمحْ بمرورِ HTTPS. انتهى.

لم تكن UFW محرِّكَ جدارٍ ناريّ. كانت واجهة مُترجمةً بينَ نيّةِ الإنسانِ وآليّةِ النواة. تحتَ الغطاء، كانت تُخاطبُ iptables. وعلى أوبونتو الحديثة، تستهدفُ أدواتُ iptables عادةً واجهةَ nftables البرمجيّةَ عبرَ مسارِ التوافقِ iptables-nft، فتنتهي قواعدُ UFW في أغلبِ الأحوالِ قواعدَ nftables تحتَ الغطاءِ دونَ أن يدريَ المُستخدِم. UFW هي الدبلوماسيُّ الذي يتحدّثُ لغةَ المَلِكِ ولغةَ الشعب، ويقفُ بينهما كي لا يُضطرَّ أيُّهما للصياحِ في وجهِ الآخر.

لكنّ ها هنا المُفارقة

شُحِنت UFW مع أوبونتو. كانت مُثبَّتةً افتراضيًّا. لكنّها لم تكن مُفعَّلةً افتراضيًّا.

اقرأ ذلك مرّةً أخرى. الجدارُ الناريُّ كان هناك، على النظام، جاهزًا لحمايتِك، وكان مُطفَأ.

لماذا؟ لأنّ فلسفةَ أوبونتو، لا سيّما لسطحِ المكتب، كانت: أغلبُ المُستخدِمينَ يجلسونَ خلفَ موجِّهٍ (راوتر) منزليّ. الموجِّهُ يقومُ بترجمةِ عناوينِ الشبكة (NAT). الزياراتُ الواردةُ غيرُ المطلوبةِ لا تصلُ أبدًا إلى الحاسوب. فالجدارُ الناريُّ المُضيفُ طبقةٌ إضافيّةٌ قد تُربكُ المُستخدِمينَ أو تحجبُ تطبيقاتِهم دونَ سابقِ إنذار.

هذا التعليلُ كان مقبولًا تقنيًّا ومُقلقًا فلسفيًّا. كان يفترضُ أنّ بيئةَ المُستخدِمِ آمنة. يفترضُ أنّ الموجِّهَ مُعَدٌّ إعدادًا صحيحًا. يفترضُ أنّ ليس على الشبكةِ المحليّةِ أجهزةٌ أخرى قد تكونُ عدائيّة. لا جهازَ إنترنتِ أشياءَ مُختَرَقًا، ولا حاسوبًا محمولًا مُصابًا ببرمجيّةٍ خبيثة، ولا ضيفًا على شبكةِ الواي فاي يحملُ نوايا سيّئة. يفترضُ أنّ المُستخدِمَ لن يتّصلَ أبدًا بمنفذِ إيثرنت في فندق، ولن يُشاركَ اتّصالَ هاتفٍ في مؤتمر، ولن ينضمَّ إلى شبكةِ جامعةٍ يتقاسمُها عشرةُ آلافِ غريب.

وهكذا، لسنوات، بقيت الغالبيّةُ العُظمى من تثبيتاتِ أوبونتو ولينكس مِنت المكتبيّةِ الافتراضيّةِ جالسةً على شبكاتٍ بلا أيِّ قواعدِ جدارٍ ناريٍّ مُضيفٍ فعّالة. بُنيَ الجدار. رُكِّبَت البوّابة. وظلّت البوّابةُ مفتوحة.

firewalld رؤيةُ ردهات للمناطق (٢٠١١–الحاضر)

بينما حلمت كانونيكال بالبساطة، حلمت ردهات بِـالعمارة.

في عام ٢٠١١، قدَّمت ردهات firewalld. خدمةَ إدارةِ جدارٍ ناريٍّ صُمِّمت لعالمٍ تتنقّلُ فيه الآلاتُ بينَ الشبكات. حاسوبُكَ المحمولُ في البيت، في المكتب، في المقهى. كلُّ بيئةٍ لها مستوى ثقةٍ مختلف. قدَّمت firewalld مفهومَ المناطق: منزل، عمل، عامّة، موثوقة، إسقاط. لكلِّ منطقةٍ مجموعةُ قواعدِها. حينَ تتّصلُ بشبكةٍ جديدة، يستطيعُ جدارُكَ الناريُّ تلقائيًّا أن يُبدِّلَ وضعيّتَه.

تحدّثت firewalld إلى النواةِ عبرَ netfilter (ولاحقًا nftables). أُديرت عبرَ firewall-cmd أو عبرَ D-Bus، ما يعني أنّ الأدواتِ الرسوميّةَ وبيئاتِ سطحِ المكتبِ تستطيعُ التعاملَ معها برمجيًّا. خُزِّنت إعداداتُها في ملفّاتِ XML. أحبَّها بعضُ المُديرينَ لوضوحِها، وكرهَها آخرونَ لإسهابِها.

الانقسام

وهكذا انشقَّ عالمُ لينكس، لا بالحقدِ بل بِـالثقافة:

• أوبونتو/ديبيان/مِنت استخدمت UFW: بسيطة، مُسطَّحة، “فقط افتحْ هذا المنفذ.”
• فيدورا/RHEL/CentOS Stream/openSUSE استخدمت firewalld: مُهيكلة، مُقسَّمةً إلى مناطق، “هذه الشبكةُ موثوقة، وتلك ليست.”

لم يكن أيٌّ منهما مُخطئًا. عكسا افتراضاتٍ مختلفةً عن المُستخدِم:

• UFW رأت الآلةَ جسمًا ثابتًا. خادمًا في رفّ. حاسوبًا مكتبيًّا على طاولة. شبكتُهُ لا تتغيّر؛ وقواعدُهُ لا تحتاجُ إلى تغيير.
• firewalld رأت الآلةَ مسافرًا. حاسوبًا محمولًا، هاتفًا، جهازًا يتجوّلُ بينَ العوالمِ وعليه أن يُكيِّفَ دفاعاتِهِ مع كلِّ عالم.

الفجوةُ الفلسفيّةُ لم تكن عن الرزم. كانت عن الهويّة.

nftables الثورةُ الهادئة (2014–الحاضر)

تحتَ كلِّ هذه الواجهات — UFW، firewalld، أوامرُ iptables الخام — كانت النواةُ نفسُها تتغيّر.

في عام 2014، مع لينكس 3,13، وصلت nftables. كانت خليفةَ iptables، صُمِّمت لتُصلِحَ الدَّينَ التقنيَّ المتراكمَ خمسةَ عشرَ عامًا. حيثُ كان لِـiptables أدواتٌ منفصلةٌ لِـIPv4 وIPv6 وARP والتجسير (iptables، ip6tables، arptables، ebtables)، وحَّدتها nftables جميعًا في إطارٍ واحدٍ بصياغةٍ أرشق وأكثرَ تعبيرًا.

كانت nftables الأساسَ الجديد، الصخرَ الذي سيُبنى عليه كلُّ شيءٍ آخر. لكنّها جاءت بهدوء، بل بخفاء. معظمُ المُستخدِمينَ لم يتعاملوا معها مباشرة. واصلوا استخدامَ UFW أو firewalld، وتلك الأدواتُ ببساطةٍ بدَّلت خلفيّاتِها من iptables إلى nftables.

هكذا تتغيّرُ البنيةُ التحتيّةُ في العالمِ الحقيقيّ: لا بثورةٍ يُلاحظُها المُواطنون، بل باستبدالٍ صامتٍ للأنابيبِ تحتَ الشارع. تفتحُ الحنفيّة، والماءُ يتدفّقُ كالعادة. لا تعلمُ أبدًا أنّ الأنابيبَ جديدة.

ومع ذلك، لسنوات، عاشَ الناسُ مرحلةً هجينةً غريبة. وهنا تحديدًا عانى مُديرو الأنظمةِ في العالمِ الحقيقيّ. أنتجَ الانتقالُ ملفَّي تنفيذٍ مختلفَينِ لِـiptables يمكنُ أن يتعايشا على النظامِ ذاته:

• iptables-legacy: الملفُّ التنفيذيُّ الأصليّ، يُخاطبُ مباشرةً النظامَ الفرعيَّ القديمَ في النواة (xt_tables).
• iptables-nft: الملفُّ التنفيذيُّ الجديد، يقبلُ صياغةَ iptables المألوفةَ ذاتَها لكنّه يُترجمُها داخليًّا إلى قواعدِ nftables.

أيُّهما كان يعملُ على نظامِك؟ ذلك يتوقّفُ على توزيعتِك، وإصدارِك، ومسارِ ترقيتِك، وأحيانًا على أيِّ حزمةٍ صودِفَ أنّها مُثبَّتة. ديبيان بدَّلت افتراضيَّها إلى iptables-nft في بَستر (2019). فيدورا تحرَّكت قبل ذلك. أوبونتو لحِقت. لكن لنافذةٍ زمنيّةٍ مؤلمة، كان بإمكانِ مُديرٍ أن يكتبَ iptables -L فيرى لا شيء. لأنّ القواعدَ كانت في النظامِ الفرعيِّ لِـnftables، وملفُّ iptables-legacy التنفيذيُّ كان يبحثُ في القديم.

قواعدُ كُتِبت بملفٍّ تنفيذيٍّ كانت غيرَ مرئيّةٍ للآخر. نصوصُ جدارٍ ناريٍّ عملت لعقدٍ من الزمنِ توقّفت بصمتٍ عن العمل. لا برسالةِ خطأ، بل بِـغياب. بدا الجدارُ فارغًا، لكنّ القواعدَ كانت ببساطةٍ في غرفةٍ لم يعلمِ المُديرُ بوجودِها.

لم تكن كارثةً دراماتيكيّة. كانت أسوأ: ارتباكٌ هادئٌ أنهكَ الثقةَ في الأدواتِ ذاتِها.

انشقاقُ openSUSE — حينَ تختارُ العائلةُ اختياراتٍ مختلفة (2024–الحاضر)

كانت openSUSE عائلةَ AppArmor لنحوِ عقدَينِ من الزمن. كانت AppArmor وليدةَ نظامِها البيئيّ. طفلتَها. إرثَها من حقبةِ نوفِل/SUSE. المُديرونَ الذين أداروا openSUSE عرفوا AppArmor. كتبوا ملفّاتِ تعريفٍ لها. شخَّصوا أعطالَها. وثِقوا بها.

لكنّ العالمَ كان يتغيّر. SUSE، الشركةُ الأمّ، كانت تتحرّكُ نحوَ مُنتجاتِ المؤسّسات: منصّاتُ الحاويات، والحوسبةُ الطرفيّة، وأنظمةُ التشغيلِ غيرُ القابلةِ للتغيير. وفي ذلك العالم، كانت SELinux قد صارت اللغةَ المشتركة. ربِحت ردهات حربَ التحكُّمِ الإلزاميِّ في عالمِ المؤسّسات، لا بأن كانت أكثرَ وِدًّا، بل بأن كانت أكثرَ إصرارًا. كوبرنيتيز، الحاويات، البنيةُ التحتيّةُ السحابيّةُ الأصيلة. كلُّ ذلك بُنيَ وافتراضاتُ SELinux مُدمَجةٌ في أساسه.

فاختارت openSUSE MicroOS (البديلُ غيرُ القابلِ للتغيير، المُحسَّنُ للحاويات) SELinux لا AppArmor. كان قرارًا عمليًّا: إن كانت منظومتُكَ التشغيليّةُ مُصمَّمةً لتشغيلِ حاويات، وكان النظامُ البيئيُّ للحاوياتِ يتحدّثُ SELinux، فإنّ التحدُّثَ بِـAppArmor يعني ترجمةً مستمرّة، وتكيُّفًا مستمرًّا، وسباحةً دائمةً عكسَ التيّار.

ثمّ بدأت openSUSE Tumbleweed تتحرّكُ نحوَ SELinux هي الأخرى. جاءت اللحظةُ المفصليّةُ مع لقطةِ فبراير 2025، حينَ صارت التثبيتاتُ الجديدةُ لِـTumbleweed تعتمدُ SELinux افتراضيًّا. ووثائقُ openSUSE Leap 16 تعكسُ SELinux نظامَ تحكُّمٍ إلزاميٍّ افتراضيًّا للمُضيّ قُدمًا. التقليدُ العائليُّ القديمُ كان يُنحّى جانبًا، لا تدريجيًّا ولا بغموض، بل بلقطاتٍ مُحدَّدةٍ ومُلاحظاتِ إصدارٍ واضحة.

اشتعلت منتدياتُ openSUSE وصفحاتُ Reddit بِـالحُزنِ الهادئ لأُناسٍ شعروا أنّ شيئًا مألوفًا يُنتزَعُ منهم.

“لماذا نتخلّى عن AppArmor؟ إنّها تعمل. إنّها أبسط. إنّها لنا.”

“SELinux أصعبُ في التعلُّم. مُستخدِمو سطحِ المكتبِ سيعانون.”

“هذا نموذجُ ردهات. هل نحنُ الآنَ مُجرَّدُ تابعينَ لردهات؟”

والحُججُ المقابلة:

“SELinux هي حيثُ تتّجهُ الصناعة. مُقاومتُها تعني التخلُّفَ عن الرَّكب.”

“الأنظمةُ غيرُ القابلةِ للتغييرِ والحاوياتُ تحتاجُ أمانًا مبنيًّا على الوسم. المساراتُ لا تفي بالغرض في ذلك العالم.”

“إن أردنا أن تكونَ openSUSE بوّابةً لمُنتجاتِ SUSE المؤسّسيّة، فعلينا أن نتبنّى النموذجَ الأمنيَّ ذاتَهُ من القمّةِ إلى القاع.”

لم يكن هذا نقاشًا تقنيًّا. كان أزمةَ هويّة. ما هي openSUSE؟ أهي مشروعٌ مجتمعيٌّ يسلكُ طريقَهُ الخاصّ؟ أم هي حقلُ تجاربٍ لطموحاتِ SUSE المؤسّسيّة؟ أيمكنُها أن تكونَ كليهما؟

الجوابُ حتّى الآن: كلاهما، بقلق. ستظلُّ تثبيتاتُ openSUSE التقليديّةُ تدعمُ AppArmor. لكنّ الافتراضيّ — الشيءُ الذي يُشحَنُ إن لم تختر خلافَهُ — يتحوّلُ إلى SELinux. الحَرسُ القديمُ يُراقب. والجيلُ الجديدُ يتكيَّف. والتوتُّرُ بينَ الموروثِ والبراغماتيّةِ يتجلّى في مربّعاتِ اختيارِ المُثبِّتِ وسجلّاتِ اللقطات.

اختراقُ كابيتال وان — حينَ يكونُ في الجدارِ ثقب (2019)

لا تكتملُ حكايةٌ عن الجدرانِ الناريّةِ بلا حكايةٍ عن الإخفاق.

في يوليو 2019، أعلن البنك الامريكي كابيتال وان أنّ مُهندسَ سحابةٍ سابقًا استغلَّ سلسلةً من سوءِ الإعداداتِ للوصولِ إلى البياناتِ الشخصيّةِ لنحوِ 106 مليونِ شخص. وقعَ الاختراقُ في بيئةِ AWS السحابيّةِ التابعةِ لكابيتال وان. لا على خادمِ لينكس تقليديٍّ يُبدِّلُ فيه المُديرُ أوضاعَ الجدارِ الناريّ، بل في العالمِ المَرِنِ المُجرَّدِ للبنيةِ التحتيّةِ السحابيّة.

الآليّةُ الموصوفةُ على نطاقٍ واسعٍ تضمَّنت هجومَ تزويرِ طلباتٍ من جانبِ الخادم SSRF ضدَّ جدارٍ ناريٍّ لتطبيقِ ويب سيِّئِ الإعداد، ما سمحَ للمُهاجِمِ بالاستعلامِ من خدمةِ البياناتِ الوصفيّةِ لمثيلِ EC2 (IMDSv1). وهي خدمةٌ كانت، في ذلك الوقت، تستجيبُ لأيِّ طلبِ HTTP قادمٍ من المثيلِ دونَ أن تتطلّبَ استيثاقًا قائمًا على الجلسة. من خدمةِ البياناتِ الوصفيّةِ حصلَ المُهاجِمُ على بياناتِ اعتمادٍ مؤقّتةٍ لدورِ IAM، والتي بدورِها منحتهُ وصولًا إلى حاوياتِ تخزينِ S3 التي كانت تحتوي على البياناتِ الحسّاسة.

الجدارُ الناريُّ لم يكن غائبًا، كان حاضرًا ويعمل. لكنّه كان مُعَدًّا بصورةٍ سمحت لِـSSRF بالنجاح، والمعماريّةُ الأوسعُ افتقرت إلى الضوابطِ المُتعدّدةِ الطبقاتِ التي كان يمكنُها احتواءُ الضرر.

التخفيفاتُ الحديثةُ لهذا الصنفِ من الهجماتِ معماريّةٌ بطبيعتِها: IMDSv2 (الذي يتطلّبُ طلباتِ رمزٍ مبنيّةٍ على الجلسة، بِـPUT ثمّ GET، ما يُصعِّبُ استغلالَ SSRF كثيرًا)، وسياساتُ دورِ IAM مضبوطةُ النطاق، وتقسيمُ الشبكة، ومراقبةُ الدفاعِ بالعمق. هذه ضوابطُ سحابيّةٌ أصيلة، ليست من النوعِ الذي يُصلَحُ بتفعيلِ SELinux على مُضيفٍ واحد.

هل كان التحكُّمُ الإلزاميُّ على مستوى المُضيفِ قد يُفيد؟ ربّما عند الهوامش، بتقييدِ ما يُسمَحُ للعمليّةِ المُختَرَقةِ بفعلِهِ حتّى بعدَ الاستغلال. لكنّ الجوابَ الصادقَ هو أنّ هذا الاختراقَ سكنَ في طبقةٍ معماريّةٍ مختلفة عن تلك التي تحرسُها SELinux أو AppArmor بالدرجةِ الأولى. الدرسُ ليس “كانت SELinux لتُنقذَهم.” الدرسُ أعمق:

الجدارُ الناريُّ الموجودُ ليس بالضرورةِ جدارًا ناريًّا يعمل. والجدارُ الناريُّ الذي يعملُ ليس بالضرورةِ بنيةً أمنيّةً تصمد.

كان لكابيتال وان أسوار. كان لها حُرّاس. كان لها سياسات. ومع ذلك اختُرِقت، لا لأنّ الأدواتِ خذلتها، بل لأنّ الافتراضاتِ المُضمَّنةَ في الإعداداتِ حولَ ما ستقبلُهُ خدمةُ البياناتِ الوصفيّة، وما يستطيعُ دورُ IAM بلوغَه، وما سيصدُّهُ جدارُ تطبيقِ الويب الناريّ تلك الافتراضاتُ كانت خاطئة. والافتراضاتُ الخاطئةُ أصعبُ في الترقيعِ من البرمجيّاتِ الخاطئة.

الحاضر — خريطةُ المملكة (2025)

الجدرانُ الناريّة (مَن يحرسُ البوّابة)

الحُرّاس (مَن يُراقبُ العمليّات)

الأساس (ما يُرشِّحُ الرزم)

تحتَ كلِّ شيء — UFW، firewalld، حتّى أوامرُ iptables الخام — محرِّكُ ترشيحِ الرزمِ الفعليُّ في لينكس الحديثِ هو nftables، وهو جزءٌ من إطارِ netfilter في النواة. كلُّ ما عداهُ واجهة. صلةُ وصلٍ بشريّةٌ بينَ الإنسانِ والآلةِ في الأسفل.

ويندوز يُطِلّ

في الطرفِ الآخر، في مملكةِ ويندوز، كان شيءٌ واحدٌ مختلفًا، بصورةٍ تنطوي على عبرة.

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

لم يكنِ الأمرُ كذلك دائمًا. في مطلعِ الألفيّة، كان ويندوز يُشحَنُ بلا جدارٍ ناريٍّ مُضيفٍ فعّال، وكانت العواقبُ كارثيّة. وبائيّاتُ الديدانِ بينَ ٢٠٠١ و٢٠٠٤ — كود رِد، ونيمدا، وSQL سلامر، وMSبلاستر — مزّقت الإنترنت، وأصابت ملايينَ الأجهزةِ في ساعات. لم تكن هجماتٍ مُتقنةً ضدَّ أهدافٍ مُحصَّنة. كانت ثغراتٍ مُؤتمتةً تمسحُ الشبكةَ بحثًا عن منافذَ مفتوحةٍ على أنظمةٍ بلا حماية، ووجدتها في كلِّ مكان.

كان ردُّ مايكروسوفت هو حزمةُ الخدمةِ الثانية لويندوز XP (أغسطس ٢٠٠٤)، التي فعَّلت جدارَ ويندوز الناريَّ افتراضيًّا، خطوةٌ كانت يومذاك مثارَ جدل. تعطّلَ توافقُ التطبيقات. تضاعفت مكالماتُ الدعمِ الفنّيّ. لكنّ وبائيّاتِ الديدانِ تباطأت، ولم تتراجع مايكروسوفت قطّ. احتُرِقَ الدرسُ في ذاكرةِ المؤسّسة: الإيقافُ الافتراضيُّ ترفٌ لا تستطيعُ تحمُّلَهُ على مستوى المُستهلِك.

لم يعشْ لينكس تلك الحسابَ ذاتَهُ على مستوى المُستهلِك، لأنّ قاعدةَ مُستخدِمي لينكس الاستهلاكيّينَ في عام 2003 كانت صغيرة، تقنيّة، وعمومًا تجلسُ خلفَ جدرانِ جامعاتٍ أو مؤسّسات. كان الافتراض: مُستخدِمونا يعرفونَ ما يفعلون.

لكنّ العالمَ تغيّر. انتشرَ لينكس في مثيلاتٍ سحابيّةٍ يُطلقُها أُناسٌ لم يكتبوا أمرَ صَدَفةٍ في حياتهم. في أجهزةِ إنترنتِ أشياءَ ببياناتِ اعتمادٍ افتراضيّةٍ وبلا آليّةِ تحديث. في حاوياتٍ مُنسَّقةٍ بملفّاتِ YAML مَنسوخةٍ من Stack Overflow. افتراضُ أنّ المُستخدِمَ يعرف صارَ أقلَّ وأقلَّ موثوقيّة. ومع ذلك، على كثيرٍ من التوزيعات، لم تتغيّرِ الافتراضيّات.

المقارنةُ مع ويندوز ليست “ويندوز أكثرُ أمانًا.” إنّما هي هذه: تعلَّمت ويندوز، عبرَ التجربة، أنّ الافتراضيّاتِ أهمُّ من التوثيق. أمّا لينكس، بتوزيعِهِ المسؤوليّةَ على عشراتِ التوزيعاتِ المُستقلّة، فكان أبطأَ في تعلُّمِ الدرسِ ذاته، لا لأنّ الدرسَ مجهول، بل لأنّه ما من سلطةٍ واحدةٍ تفرضُه.

خمسةُ دروسٍ من حُرّاسِ الأبواب

هذا ما تُعلِّمُنا إيّاهُ هذه الحكاية:

• أوّلًا: الأمنُ ليس شيئًا واحدًا. إنّه طبقات. الجدارُ الناريُّ يحرسُ البوّابةَ (UFW، firewalld، nftables). نظامُ التحكُّمِ الإلزاميِّ يحرسُ الداخلَ (SELinux، AppArmor). Seccomp يحرسُ استدعاءاتِ النظام. الصلاحيّاتُ تحرسُ الغُرَف. الترقيعُ يحرسُ من نقاطِ الضعفِ المعروفة. المراقبةُ تحرسُ من المجهول. لا طبقةٌ واحدةٌ تكفي. ولا طبقةٌ واحدةٌ يُستغنى عنها.

• ثانيًا: أفضلُ نظامِ أمانٍ هو الذي يستخدمُهُ الناسُ فعلًا. قد تكونُ AppArmor أقلَّ اكتمالًا نظريًّا من SELinux، لكنّ إن كان الناسُ يتركونَها تعملُ بينما يُطفئونَ SELinux، فإنّ AppArmor قد أنجزت عملًا أمنيًّا حقيقيًّا أكثر. وقد تكونُ UFW أقلَّ قوّةً من firewalld، لكن إن دفعت شخصًا ما لأن يكتبَ ufw enable حيثُ كان سيستسلمُ أمامَ iptables، فإنّ UFW ربحت معركةً لم تستطع iptables ربحَها.

• ثالثًا: الافتراضيّاتُ أهمُّ من الميزات. أوبونتو تُشحَنُ وUFW مُطفَأة. فيدورا تُشحَنُ وfirewalld مُشتعلة. ذلك الفرقُ الوحيد — مُشتعلةٌ أو مُطفَأة — يُؤثِّرُ في الوضعِ الأمنيِّ لملايينِ الأجهزة. المُستخدِمُ الذي يُثبِّتُ ويمضي محميٌّ في فيدورا ومكشوفٌ في أوبونتو. لا لأنّ أوبونتو تفتقرُ إلى الأداة، بل لأنّها تفتقرُ إلى الافتراضيّ. هذه أهمُّ ملاحظةٍ في الحكايةِ كلِّها، وهي تسري أبعدَ كثيرًا من الجدرانِ الناريّة.

• رابعًا: الجدلُ بينَ SELinux وAppArmor، بينَ UFW وfirewalld، بينَ التفعيلِ والتعطيل، هذا الجدلُ ليس في حقيقتِهِ عن برمجيّات. إنّه عن العلاقةِ بينَ الحريّةِ والأمان. وُلِدَ لينكس من الحريّة. لكنّ الحريّةَ بلا أمانٍ هَشّة. والأمانَ بلا حريّةٍ قمع. كلُّ توزيعة، كلُّ افتراضيّ، كلُّ اختيارٍ هو محاولةٌ لموازنةِ هاتَينِ القوّتَين. ولم يجد أحدٌ التوازنَ الكامل، لأنّ التوازنَ الكاملَ غيرُ موجود. التوتُّرُ ليس خللًا. إنّه الحال.

• خامسًا: الجدارُ ليس كافيًا. كان لكابيتال وان أسوار. كان لها حُرّاس. كان لها سياسات. ومع ذلك اختُرِقت. لا لأنّ الأدواتِ أخفقت، بل لأنّ الافتراضاتِ أخفقت، لأنّ بشرًا اتّخذوا خياراتٍ تركت فجواتٍ في أماكنَ لم يكن أحدٌ يُراقبُها. الجدارُ الناريُّ ليس درعًا سحريًّا. إنّه مجموعةُ قواعد، والقواعدُ لا تفوقُ جودتُها جودةَ البشرِ الذين يكتبونَها ويُراجعونَها ويُحدِّثونَها.