الأمن في أنظمة جنو / لينكس ، هل يعتمد على النظام أو المدير؟

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

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

أنظمة مصابة جنو / لينكس، في جميع الحالات ، يتم تشغيل Linux kernel الإصدار 2.6، صدر في عام 2007 أو قبل ذلك. لم يذكر بأي حال من الأحوال إصابة الأنظمة التي تشغل نواة عالية الجودة أو التي تم تحديثها على النحو الواجب ؛ لكن بالطبع ، لا يزال هناك إداريون يعتقدون "... إذا لم يتم كسرها ، فلا تحتاج إلى إصلاح" ثم تحدث هذه الأشياء.

وعلاوة على ذلك، دراسة حديثة أجرتها شركة الأمن ESET، يعرض المكالمة بالتفصيل "عملية Windigo"، والتي من خلال عدة مجموعات هجومية ، بما في ذلك واحدة تسمى مغمور مصمم خصيصًا لـ Apache وخوادم الويب مفتوحة المصدر الشائعة الأخرى ، بالإضافة إلى خادم آخر يسمى إيبري SSH، لقد كان تم اختراق أكثر من 26,000 نظام جنو / لينكس منذ مايو من العام الماضي ، هل هذا يعني أن جنو / لينكس لم يعد آمنًا؟

بادئ ذي بدء ، ضع الأشياء في السياق ، إذا قارنا الأرقام السابقة مع ما يقرب من مليوني جهاز كمبيوتر يعمل بنظام Windows تم اختراقها بواسطة bootnet ZeroAccess قبل إغلاقها في ديسمبر 2013 ، من السهل استنتاج أنه من حيث الأمان ، لا تزال أنظمة جنو / لينكس أكثر أمانًا من أولئك الذين يستخدمون نظام تشغيل Microsoft ، لكن هل خطأ جنو / لينكس تعرض 26,000 نظام مع نظام التشغيل هذا للاختراق؟

كما في حالة ثغرة PHP الحرجة التي تمت مناقشتها أعلاه ، والتي تؤثر على الأنظمة التي لا تحتوي على تحديثات kernel ، فإن هذه الهجمات الأخرى تتضمن أنظمة لم يتم فيها تغيير اسم المستخدم و / أو كلمة المرور الافتراضية والتي حافظت على المنفذين 23 و 80 مفتوحين دون داع؛ إذن ، هل هذا حقًا خطأ جنو / لينكس؟

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

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

إذا كان لديك نظام GNU / Linux تحت رعايتك مع Apache أو خادم ويب آخر مفتوح المصدر وتريد التحقق مما إذا كان قد تم اختراقه ، فإن الإجراء بسيط. في حالة إبري، يجب عليك فتح Terminal واكتب الأمر التالي:

ssh -G

إذا كانت الإجابة مختلفة عن:

ssh: illegal option – G

ثم قائمة الخيارات الصحيحة لهذا الأمر ، فسيتم اختراق نظامك.

في حالة مغمور، الإجراء أكثر تعقيدًا بعض الشيء. يجب عليك فتح Terminal وكتابة:

curl -i http://myserver/favicon.iso | grep "Location:"

إذا تم اختراق نظامك ، إذن مغمور سيعيد توجيه الطلب ويعطيك المخرجات التالية:

Location: http://google.com

خلاف ذلك ، لن يتم إرجاع أي شيء أو موقع مختلف.

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

للحصول على تحليل أكثر تفصيلاً للطرق التي تعمل بها هذه العدوى ، فضلاً عن الطرق المحددة المستخدمة لنشرها والتدابير المقابلة التي يتعين اتخاذها ، نقترح تنزيل وقراءة التحليل الكامل لـ "عملية Windigo" متوفر على الرابط التالي:

عملية Windigo

وأخيرا ، أ الاستنتاج الأساسي: لا يوجد نظام تشغيل مضمون ضد المسؤولين غير المسؤولين أو المهملين ؛ أما بالنسبة للسلامة ، فهناك دائمًا ما يجب القيام به ، لأن الخطأ الأول والأكثر خطورة هو الاعتقاد بأننا قد حققنا ذلك بالفعل ، أم أنك لا تعتقد ذلك؟