أدت الطبيعة العالمية لتطبيقات الوب لانتشارها. غالباً ما يتم تشغيل عدة تطبيقات وب على التوازي: webmail، ويكي، نظام إدارة مجموعات، منتديات، ألبوم صور، مدونة، وغيرها. تعتمد معظم هذه التطبيقات على ”LAMP‏“ (Linux, Apache, MySQL, PHP). لسوء الحظ، تكتب معظم هذه التطبيقات دون اعتبار المشاكل الأمنية كثيراً. في معظم الأحيان، تستخدم البيانات الواردة من العالم الخارجي بعد التحقق منها بشكل ضعيف أو بلا تحقق أبداً. يمكن تقديم قيم مُعدَّة خصيصاً لإفساد استدعاء أحد الأوامر بحيث يتم تنفيذ أمر آخر بدلاً منه. أُصلِحَت معظم المشاكل الواضحة عبر الزمن، لكن تظهر مشاكل أمنية جديدة بانتظام.

لا مفر من تحديث تطبيقات الوب بانتظام، خشية أن يتمكن أي مخرب (سواء كان مهاجماً محترفاً أو script kiddy) من استغلال ثغرة معروفة. يختلف الخطر الفعلي حسب الحالة، ويتراوح ما بين تدمير البيانات إلى تنفيذ أكواد عشوائية، بما في ذلك تشويه الموقع (defacement).

غالباً ما تُستَخدَم الثغرة في تطبيق الوب كنقطة انطلاق لمحاولات الاختراق. فيما يلي استعراض قصير للعواقب المحتملة.

يختلف مدى وضوح آثار الاختراق حسب أهداف المهاجم. يطبق Script-kiddy الوصفات التي يجدها على مواقع الوب فقط؛ أغلب الأحيان، سوف يشوه مظهر صفحة وب أو يحذف بيانات. في الحالات الأكثر حذقاً، سيضيف محتوى غير مرئي لصفحات الوب بحيث تتحسن referrals لموقعه الشخصي في محركات البحث.

أما المهاجم الأكثر تقدماً فسوف يسعى لما هو أبعد من ذلك. من السيناريوهات الكارثية أن يحدث ما يلي: يتمكن المهاجم من تنفيذ الأوامر تحت هوية المستخدم www-data، لكن تنفيذ الأوامر يحتاج للكثير من المناورات. لتسهيل الوضع على نفسه، سوف يثبّت تطبيقات وب أخرى مصممة خصيصاً لتنفيذ انواع كثيرة من الأوامر عن بعد، مثل تصفح نظام الملفات، فحص الصلاحيات، رفع أو تنزيل الملفات، تنفيذ الأوامر، أو حتى تقديم سطر أوامر عبر الشبكة. أغلب الأحيان، ستسمح لهم الثغرة بتنفيذ الأمر wget لتنزيل برمجية خبيثة ما ضمن المجلد /tmp/، ثم تنفيذها. تُنزّل البرمجيات الخبيثة من مواقع غريبة مُختَرَقة سابقاً، وذلك لتغطية الأثر وجعل تقفي الأدلة إلى المصدر الفعلي للهجوم أصعب.

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

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

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

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

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

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

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

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

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

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

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

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

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

فالمهاجم الذي يستولي على جهازك ثم يستخدمه كقاعدة انطلاق (تعرف باسم ”relay system“ أو محطة ترحيل) ينفذ منها نشاطات خبيثة أخرى قد يسبب لك متاعب قانونية، لأن الجهة المهاجَمَة قد ترى في البداية أن الهجوم يرد من نظامك، وتعتبرك المهاجم (أو شريكاً في الجريمة). في العديد من الحالات، سيستخدم المهاجم مخدمك كمحطة لإرسال رسائل دعائية، ويجب ألا يسبب هذا ضرراً كبيراً (فيما عدا احتمال تسجيلك على قوائم سوداء قد تحد من قدرتك على إرسال رسائل مشروعة)، لكنه لن يكون ساراً أيضاً. في حالات أخرى، قد يسبب الجهاز لك مشاكل أهم، مثل هجمات denial of service. قد يسبب هذا أحياناً خسارة أرباح، بسبب توقف الخدمات المشروعة أو تدمير البيانات؛ كما قد يسبب هذا تكاليفاً حقيقية، لأن الجهة المهاجَمَة قد تتخذ إجراءات قضائية ضدك. يستطيع حاملو حقوق النشر مقاضاتك لمشاركة النسخ غير المرخصة للأعمال التي يحميها قانون حقوق النشر، كما تستطيع الشركات الأخرى الملتزمة باتفاقيات مستوى الخدمة إذا اضطرت لدفع غرامات نتيجة الهجمات الصادرة عن جهازك.

عندما تحدث حالات مثل هذه، لن ينفعك ادعاء البراءة وحده؛ بل ستحتاج على الأقل لأدلة مقنعة تُبيّن ورود النشاطات المشبوهة على نظامك من عنوان IP معين. لن تتمكن من الحصول على أدلة كهذه إذا أهملت نصائح هذا الفصل وتركت المهاجم يحصل على إمكانية الوصول لحساب بصلاحيات مرتفعة (وبالأخص حساب الجذر) واستعماله لتغطية آثاره.