البحث في الموقع

نعرف نحن مطوّري البرامج أهميّة اتّباع أفضل الممارسات الأمنية؛ إلا أننا نتسرّع غالبا في تنفيذها، ربما بسبب ما تستدعيه من العمل الجادّ حتى ترسخ في الأذهان. يحدُث أحيانا أن ترى ممارسة أمنية شديدة الخطورة لدرجة أنها تبقى محفورة في ذهنك. أمرّ في عملي مدير أنظمة على الكثير من الممارسات الأمنية الخاطئة، إلا أن الثلاثة التي سأتحدّث عنها في هذا المقال هي أساسيّات يجب على كلّ مطوّر برامج تفاديها. أنبّه هنا إلى أنني أرى كل واحدة من الممارسات المذكورة لدى شركات كبيرة ومطوّرين ذوي خبرة طويلة، لذا فليس صحيحا لصقُها بالمطوّرين المبتدئين. لا تستخدم التعمية لكلمات السّر .. بل التجزئة Hash عملتُ في وقت سابق من مسيرتي المهنية مع شركة تستخدم نظام إدارة يخزّن بيانات شديدة الأهميّة، وفي أحد الأيام طُلِب مني إجراء مراجعة أمنية للشبكة والبرنامج الذين تعتمد عليهما بياناتنا الحرجة. قضيتُ بضع دقائق في البحث ثم قرّرت تشغيل Wireshark لرؤية حركة البيانات عبر الشبكة. استخدمتُ حاسوب العمل للدخول إلى نظام المعلومات ولاحظتُ أمرا غريبا. رغم أن هذه الحادثة كانت قبل انتشار SSL إلا أنني لم أكن أتوقّع أن أرى نصوصا واضحة تحوي حقولا مثل username (اسم المستخدِم) وpassword (كلمة السرّ). بدا بعد التدقيق أن النظام كان يُرسِل اسم المستخدم الخاصّ بي وسلسلة محارف عشوائية - لم تكن كلمتي للسرّ - عبر الشبكة. لم أستطع ترك الأمر على تلك الحال، فحاولتُ تسجيل الدخول مجدّدا إلا أنني هذه المرة أدخلتُ - عن قصد - كلمة سرّ خاطئة. لم أغيّر كلمة السّر كليّةً، بل اكتفيتُ بتغيير محرف واحد فقط. كنتُ أتوقّع رؤية سلسلة محارف جديدة مختلفة تمامًا تمثّل كلمتي للسّر تمرّ عبر الشبكة. بدلا من ذلك، لم يتغيّر سوى أول محرفيْن من سلسلة المحارف. كان الأمر مثيرًا للانتباه، فرغم أن خبرتي كانت متواضعة نوعا ما، إلا أنني كنتُ أعرف أنه إن طُبِّقت دالة تجزئة Hash بطريقة صحيحة على كلمتي للسرّ فستكون سلسلة المحارف مختلفة تماما، وليس فقط أول محرفين. ياللهوْل.. حتى مخطّط تعميّة (تشفير) جيّد كان سيُنتج سلسلتيْ محارف مختلفتين تماما، وهو ما يبدو أن مخطّط التعمية المستخدَم لا يقوم به. جرّبتُ كلمتي سرّ أخرييْن. تسلّحتُ بأوراق وقلم رصاص وقضيتُ الساعتيْن المواليتيْن في محاولة العثور على مخطّط فكّ التعمية. كان لديّ بانتهاء هاتيْن الساعتيْن سكريبت بايثون يمكنه أخذ أي واحدة كلمات السّر “المعمّاة” تلك ثوم فكّ تعميّتها وكشف كلمة السّر الأصلية؛ أمر يُفترَض أن لا أحد بإمكانه فعله. أنا متأكّد من أنه لم يدُر بخلد الشخص الذي وضع ذلك المخطَّط أن أحدا سيجلس ساعتيْن ويعمل على تفكيك مخطّطه؛ إلا أني فعلتُ ذلك. لماذا؟ لأنه كان بإمكاني ذلك. لا تعمّي كلمات السّر إن اضطررت لتخزينها من أجل المقارنة، فهناك دائما إمكانية أن يستطيع أحدهم إيجاد خوارزميّة أو مفتاح لفك التعميّة. لا يوجد عكس مباشر للتجزئة، بمعنى أنه لا يمكن لأحد الحصول على الأصل إلا إذا كان لديه جدول يربط بين النص الواضح وتجزئته (أو أنه خمّنه). معرفة آلية التجزئة وطريقة عملها لا تضرّ بسلامة البيانات، في حين يحدُث ذلك عند معرفة مخطّط التعمية ومفتاحها. 2. لا تترك منافذ خلفية Backdoors سريّة في البرامج كنتُ في وظيفة سابقة لدى إحدى شركات الخدمات البرمجية أقدّم الدعم لمستخدمين أخبروني أن أسماء المستخدمين التي بحوزتهم لم تعد تعمل. كان الدعم جزءًا من خدمة مدفوعة تقدّمها الشركة المطوّرة للبرنامج المستخدَم. خطر ببالي، قبل محاولة معرفة المشكل الكامن وراء إحدى أكثر مكالمات الدعم الفني إضجارا (“بيانات الدخول الخاصة بي لا تعمل”)، أن أجرّب تسجيل الدخول بنفسي. بالفعل لم تكن أسماء الدخول تعمل. كان النظام منصةً تعليمية مبنية على تقنيات الوِب، وكنا قد دفعنا مقابل وظائف محدودة من قدراتها الكثيرة. لفت أمر نظري بينما كنتُ أبحث في صفحة تسجيل الدخول. بدا حرف في إحدى المحارف ذا شكل مختلف قليلا عن البقية. ربما كان السببُ استخدام خط مختلف عن بقية الصفحة. عرضتُ مصدر الصفحة ولاحظتُ وجود رابط على هذا الحرف بالضبط. كان الرابط مخفيًّا عن قصد ولم تكن حالة المؤشّر تتغيّر عندما يحوم على الرابط. فتحتُ - بحذر شديد - الرابط في نافذة متصفّح جديدة. فجأةً بدت أمامي شاشة تفصّل معلومات عن مجموعة كاملة من الحواسيب، وتعطيني التحكّم الكامل في ما يمكن لهذه الحواسيب أن تعمله. كان بمقدوري إطفاء هذه الحواسيب، إعادة تشغيلها، أخذ لقطات من الشاشة.. أي شيء. هاتفتُ الشركة المطوّرة للبرنامج وطلبتُ الحديث مع مسؤول التقنية لديهم. تحدّثتُ في الأخير بعد المرور على أشخاص عدّة مع مَن يبدو أنهم يفهم ما أتحدّث عنه. أجاب “آه.. فعلا”، وأكمل “أضفنا ذلك الرابط ليسهل علينا الوصول. ولا أحد - قبلك - أبدا عثر عليه. سنحذفه فورا”. سألني قبل أن ننهي المكالمة سؤالا أخيرا: “لماذا بدأت في النظر إلى شفرات HTML في صفحة الدخول؟” كانت إجابتي بسيطة: “لأنني أستطيع ذلك”. لا يستحق وضعُ منفذ خلفي في نظام ما أي درجة من المخاطرة.. سيعثُر عليه شخص ما في نهاية المطاف. مهما كانت درجة الغموض فإن تحليل الشفرات البرمجية - كذلك البحث والحافز عموما - يحمل في طيّاته أكثر النتائج غرابة وفجائية. 3. استوثق من المستخدمين على جميع الصفحات.. وليس فقط صفحة الدخول كنتُ في مرحلة سابقة من مسيرتي المهنية جزءًا من مشروع تطوير برمجي كان يتولّى تنفيذه مطوّر متمرّس. كنتُ أحسّ بعدم الارتياح مع هذا التطبيق خصوصا، فأخبرتُ مديري بأننا نحتاج لإجراء مراجعة أمنية معمَّقة للشفرة البرمجية. طُلِب مني أن أنظُر في التطبيق بحثا عمّا يمكنني العثور عليه. بدأتُ بالتجوّل في التطبيق، تسجيل الدخول، وعرض بعض البيانات. ثم لاحظتُ أمرا بدا لي مثيرا للاهتمام. إن علمتُ Bookmarked رابطا بعد تسجيل الدخول والتجول في النظام فإن بإمكاني نسخه ثم لصقه في متصفّح آخر وسأحصُل على نفس الصفحة المُعلَّمة، دون الحاجة لتسجيل الدخول. سألتُ المطوّر “لماذا لا تتحقّق في كل صفحة من أن المستخدم مسجَّل الدخول؟ إذ يكفي أن أحصُل على رابط بعد تسجيل الدخول ونسخه ويمكنني الوصول إلى هذه الصفحة متى أردت دون الحاجة لتسجيل الدخول”، فسألني “لماذا تفعل ذلك؟”. أجبتُه: “لأنه يمكنني ذلك”. لا تترك أي شيء للصدفة حتى المطوّرون المتمرّسون يقعون في هذه الأخطاء؛ فهم يظنّون ألا أحد سيتعمّق في نظام لا يحقّ له الوصول إليه. المشكلة أن المستخدمين سيتسكّعون في النظام وسيعثرون على هذه الثغرات في النهاية. النصيحة الأهم التي يمكن لشخص مثلي، مجرّد هاو لمجال الحماية، أن يقدّمها هي:لا تترك أي شيء للصدفة. يوجد أشخاص - مثلي - يحبون التعمق في الأشياء لمعرفة كيف تعمل ولماذا. ولكن يوجد آخرون ربما أكثر خبرة ومعرفة سيتعمّقون في الأنظمة بحثا عن اكتشاف الثغرات ولاستغلالها. لماذا؟ لأن باستطاعتهم فعل ذلك. ترجمة - بتصرّف - للمقال 3 security tips for software developers لصاحبه Pete Savage. حقوق الصورة البارزة محفوظة لـ Freepik

ينصبّ الاهتمام عند إعداد بنية تحتيّة Infrastructure - عادةً - على جعل التّطبيقات تعمل بالطّريقة المرجوّة. ما لا ينتبه له الكثيرون أنّ التّركيز على عمل التّطبيقات دون الاهتمام الكافيّ بالاحتيّاجات الأمنيّة للبنية التحتيّة يُمكن أن تنتُج عنه نتائج كارثيّة في حال حدوث عمليّات اختراق. سنشرح في هذا الدّليل بعض التّصرّفات الأمنيّة الأساسيّة الّتي ينبغي تنفيذها قبل إعداد تطبيقاتك أو أثناءه. مفاتيح SSH تُستخدَم مفاتيح SSH بديلًا عن الاستيثاق المعتمد على كلمات السّرّ Password-based authentication للاتّصال بخادوم SSH؛ وهي عبارة عن زوج من المفاتيح، علنيّ Public وسريّ Private، تُنشأ قبل الاستيثاق. يحتفظ المستخدم بالمفتاح السّرّي ولا يُشاركه مع أيّ كان، في حين يُمكن مشاركة المفتاح العلنيّ. يجب وضع المفتاح العلنيّ للمستخدِم ضمن مجلَّد خاصّ على الخادوم حتى يُمكنَ استخدامُ الاستيثاق عن طريق مفاتيح SSH. يطلُب الخادوم، عند محاولة المستخدِم الاتّصال به، دليلًا على أنّ العميل Client يمتلك المفتاح السّري الموافق للمفتاح العلنيّ الموجود على الخادوم. يستخدم عميل SSH طريقة تُثبت للخادوم امتلاكه للمفتاح السّرّي للمستخدِم؛ فيسمح الخادوم للمستخدِم بالولوج دون كلمة سرّ. 1- كيف تحسّن مفاتيح SSH من الأمان؟ تُعمّى Encryption تمامًا كلّ إجراءات الاستيثاق، بما فيها الاستيثاق عن طريق كلمة السّر، عند استخدام SSH. في المقابل، يُمكن لسيّئي النّيّات - عند السّماح بالاستيثاق عن طريق كلمات السّرّ - محاولة الولوج إلى الخادوم مرارًا وتكرارًا عبر تخمين كلمة السّرّ. تمنح القدرات الحاليّة للحواسيب المهاجمين على تشغيل محاولات الاختراق آليًّا إلى أن يُعثَر على كلمة السّرّ الصّحيحة. يسمح إعداد استيثاق يعتمد على مفاتيح SSH بتعطيل الاستيثاق عن طريق كلمات السّرّ؛ إذ تحوي مفاتيح SSH عمومًا محارف أكثر بكثير من أيّ كلمة سرّ وهو ما يعني وجود إمكانيّات أكثر يجب على المُهاجم تجربتها. تعدّ الكثير من خوارزميّات غير قابلة للكسر، لسبب بسيط هو أنّ العتاد المتوفّر حاليًّا سيستغرق عقودًا أو أكثر للمرور بجميع الاحتمالات الممكنة. 2- ما مدى صعوبة إعداد الاستيثاق اعتمادًا على مفاتيح SSH؟ ضبط مفاتيح SSH سهلٌ جدًّا، كما أنّها الطّريقة الّتي يُنصَح بها للولوج عن بعد إلى خواديم لينكس ويونكس. يُمكن في ظرف دقائق إنشاء زوج من مفاتيح SSH على جهازك الشّخصيّ ثمّ نقل المفتاح العلنيّ إلى الخواديم. إذا كنت تشعر أنّك تحتاج للاستيثاق بالاعتماد على كلمات السّر فمن الجيّد استخدام حلول مثل fail2ban على خادومك للحدّ من إمكانيّة تخمين كلمة السّرّ. الجدران النّاريّة Firewalls الجدار النّاري عبارة عن برنامج (أو عتاد) يتحكّم في الخِدْمات المعروضة عبر الشّبكة. يعني هذا حظر أو تقييد الوصول إلى أي منفَذ Port لا يدخل ضمن المنافذ المتاحة للعموم. توجد بعض الخدمات الّتي تُشغَّل افتراضيًّا في الكثير من الخواديم. يُمكن تقسيم هذه الخِدْمات إلى المجموعات التّاليّة: الخِدْمات العموميّة الّتي يُمكن لأيّ كان الوصول إليها عبر الإنترنت، غالبًا بصفةِ مجهول. خادوم الويب مثال جيّد على هذه المجموعة، إذ يسمح عادةً للجميع بالوصول إلى موقع الويب. الخِدْمات الخاصّة الّتي لا يُمكن الوصول إليها لغير مجموعة حسابات مُرخَّص لها أو من أماكن محدَّدة . لوحة التّحكّم في قاعدة البيانات مثال على هذه المجموعة من الخِدْمات. الخِدْمات الدّاخليّة الّتي يمكِن الوصول إليها فقط من الخادوم نفسِه؛ دون أن تُعرَض للعالم الخارجيّ. قاعدة بيانات لا تقبل سوى الاتّصالات المحليّة (من الخادوم) مثال على هذه المجموعة. تتأكد الجدران النّاريّة من أنّ الوصول إلى برنامجك مقيّد وفقًا للمجموعات أعلاه. تُترك الخِدمات العموميّة مفتوحةً ومتاحةً للجميع بينما يُحصَر الوصول إلى الخِدْمات الخاصّة اعتمادا على معايير محدَّدة. بالنّسبة للخِدمات الدّاخليّة فيُمكن جعلُها غير مرئيّة تمامًا من خارج الخادوم. تمنع أغلب إعدادات الجدران النّاريّة تمامًا الوصولَ إلى المنافذ غير المستعملة. 1- كيف تحسّن الجدران النّاريّة من الأمان؟ الجدران النّاريّة جزء أساسيّ من إعداد أيّ خادوم. يُشكّل الجدار النّاري طبقة حماية إضافيّة، حتى ولو كانت البرامج الّتي تستخدمها تطبّق تدابير أمنيّة أو تقتصِر على الواجهات الّتي تريد لهذه البرامج العمل عليها. يمنع جدار ناريّ مضبوط بطريقة صحيحة الوصول إلى جميع الخِدمات ما عدا تلك الّتي تحتاج إلى أن تبقى مفتوحة. يقلّل عرض مجموعة برامج قليلة من الجوانب الّتي يُمكن إتيان الخادوم منها ممّا يعني قابليّةً أقلّ للتّعرّض للثّغرات الأمنيّة. 2- ما مدى صعوبة إعداد الجدران النّاريّة؟ توجد جدران ناريّة كثيرة على أنظمة لينكس، تختلف في صعوبة التّعامل معها. بصفة عامّة، يجب ألّا تتجاوز مدّة ضبط الجدار النّاري بضع دقائق؛ كما أنّه عمليّة تُجرى عند الإعداد الابتدائيّ للخادوم أو عند تغيير الخِدمات المتاحة عبر الخادوم. جدار UFW خيّار سهل. توجد أيضًا خيّارات أخرى مثل استخدام iptables أو جدار CSF النّاريّ. الشّبكات الخاصّة الافتراضيّة VPN والتّشبيك الخاصّ Private Networking الشّبكات الخاصّة هي شبكات متاحة لبعض الخواديم أو المستخدمين فقط؛ أمّا الشّبكات الخاصّة الافتراضيّة Virtual private network (أو VPN) فهي طريقة لإنشاء اتّصالات آمنة بين جهازيْن متباعديْن بحيث يظهر الاتّصال كما لو أنّه في شبكة خاصّة محليّة. تُتيح الشّبكات الخاصّة الافتراضيّة طريقة لإعداد خِدمات موجودة على خواديم متباعدة بحيثُ تظهر وكأنّها في شبكة خاصّة كما أنّها تؤمّن الاتّصالات بين خواديم متباعدة. 1- كيف تحسّن الشّبكات الخاصّة من الأمان؟ يُنصح دائمًا بتفضيل الشّبكات الخاصّة بدلًا من العموميّة في الاتّصالات الدّاخليّة كل ما كان ذلك ممكنًا. مع ذلك يجب تطيق تدابير أمنيّة إضافيّة لتأمين الاتّصالات بين الخواديم والحؤول دون وصول مستخدمي الشّبكة الدّاخليّة غير المرخَّص لهم إلى خواديمك. يُعدّ استخدام شبكات خاصّة افتراضيّة طريقة ذات فعاليّة لوضع شبكة خاصّة لا تُمكن لغير رؤيتها خواديمك؛ ستكون الاتّصالات خاصّة ومؤمّنة تمامًا. يُمكن ضبطُ بقيّة التّطبيقات لتمرير بياناتها عبر الواجهات الافتراضيّة الّتي يعرضها برنامج الشّبكات الخاصّة الافتراضيّة. لا تُعرض في هذا الإعداد عبر شبكة الإنترنت سوى سوى الخدمات الموجهة للعملاء العموميين. 2- ما مدى صعوبة إعداد الشّبكات الخاصّة الافتراضيّة؟ من السّهل استخدام الشّبكات الخاصّة في مراكز البيانات Data centers الّتي لديها هذه القدرة، إذ يقتصر الأمر على تفعيل واجهات الشّبكة أثناء إنشاء الخادوم وإعداد التّطبيقات والجدار النّاريّ لاستخدام الشّبكة الخاصّة. انتبه إلى أنّ الشّبكات الخاصّة الّتي تمتدّ عبر مركز البيانات تشترك في نفس الشّبكة مع بقيّة الخواديم. بالنّسبة للشّبكات الخاصّة الافتراضيّة فإنّ الإعداد الابتدائيّ أكثر تعقيدًا؛ إلّا أنّ الرّفع من مستوى الأمان يُعوّض الجهد في أغلب الحالات. يتطلّب إعداد شبكات خاصّة افتراضيّة تثبيت وضبط إعداد الأمان المشتركة على كلّ خادوم؛ ثمّ بعد إطلاق وتشغيل الشّبكة الخاصّة الافتراضيّة، إعداد التّطبيقات لاستخدامها. البنية التّحتيّة للمفاتيح العلنيّة PKI والتّعميّة بواسطة SSL/TLS تُحيل البنية التّحتيّة للمفاتيح العلنيّة Public key infrastructure (أو PKI) إلى نظام مُصمّم لإنشاء، إدارة والتحقق من شهادات Certificates تحديد الهويّة وتعميّة الاتّصال. يُمكن استخدام شهادات SSL أو TLS لتوثيق عناصر من النّظام لدى أخرى. يمكن - بعد الاستيثاق - استخدام الشّهادات لتعميّة الاتّصال. 1- كيف تحسّن البنية التّحتيّة للمفاتيح العلنيّة من الأمان؟ يُمكّن التّأسيس لسلطة شهادات Certificate authority وإدارتها ضمن خواديمك كلَّ عنصُر داخل بنيتك التّحتيّة من التّحقّق من هويّة بقيّة العناصر وتعميّة البيانات المتلادلة معها. يُمكن أن تمنع هذه الآليّة هجمات من نوع “رجل في الوسط” Man-in-the-middle الّتي يحاكي فيها المهاجم أحد الخواديم ضمن بنيتك التّحتيّة بهدف التقاط حركة البيانات. يُمكن ضبط كلّ خادوم ليثق في سلطة شهادات مركزيّة بحيث تُصبح أي شهادة تُوقّع عليها السّلطة المركزيّة موثوقة. إذا كانت التّطبيقات والبروتوكولات الّتي تستخدمها للاتّصال تدعم التّعمية بواسطة TLS/SSL، فإنّ هذه طريقة لتعميّة النّظام دون إغراق الاتّصال عن طريق شبكة خاصّة افتراضيّة (يدخل SSL غالبًا في آليّة عمل الشّبكات الخاصّة الافتراضيّة). 2- ما مدى صعوبة إعداد بنية التّحتيّة للمفاتيح العلنيّة؟ قد يحتاج إعداد سلطة شهادات وتثبيت بقيّة البنية التّحتيّة للمفاتيح العلنيّة في البداية لكثير من المجهود. علاوةً على ذلك فإنّ إدارة الشّهادات قد تزيد عبئًا إضافيًّا عند الحاجة لإنشاء شهادات جديدة، توقيعها أو إبطالها. لن يُشكّل تنفيذ بنية تحتيّة متكاملة للمفاتيح العلنيّة إضافةً محسوسة للكثير من المستخدمين إلّا عند زيادة احتيّاجاتهم. ربّما يكون تأمين الاتّصال بين عناصر البنية التّحتيّة عبر شبكات خاصّة افتراضيّة إجراءً مناسبًا إلى أن يصلوا إلى المرحلة الّتي تُصبح فيها بنية المفاتيح العلنيّة تعوّض الجهد الإضافيّ المبذول لإدارتها. فحص الخدمات Service auditing تطرّقنا حتى الآن لتقنيّات يُمكن اللّجوء إليها للرّفع من مستوى الأمان. يقبع جزء مهمّ من الأمان في تحليل الأنظمة المستخدَمة، فهم الجوانب الّتي يُمكن أن تُؤتَى منها، وقفل العناصر حسب إمكاناتك. يُشير فحص الخدمات إلى العمليّة الّتي تكتشف عن طريقها الخدمات العاملة في البنية التّحتيّة. يُضبط - غالبًا - نظام التّشغيل ليبدأ تشغيل خدمات معيّنة عند الإقلاع Boot. قد تجرّ البرامج الإضافيّة اعتماديّات Dependencies تُشغَّل هي الأخرى آليًّا عند الإقلاع. يسمح فحص الخدمات بمعرفة الخدمات العاملة على النّظام، المنافذ المستخدمة للاتّصالات، والبروتوكولات المقبولة. تُساعد هذه المعلومات في ضبط إعدادات الجدار النّاريّ. 1- كيف يُحسّن فحص الخدمات من الأمان؟ تُشغّل الخواديم عمليّات Processes عديدة لأداء أعمال داخليّة في الخادوم أو للتّعامل مع عملاء خارجيّين. يُمثّل كلّ واحد من هذه العناصر وسيلةً محتملة قد يستغلّها مستخدمون ذوو نيّات خبيثة لمهاجمة الخادوم؛ فكلّ ما زادت الخدمات الّتي تشغّلها زاد احتمال وجود ثغرات في البرامج الّتي تستخدمها. يُمكن أن تبدأ تحليل الخدمات الموجودة على جهازك فور حصولك على فكرة جيّدة عنها. في ما يلي بعض الأسئلة الّتي يجب أن تطرحها لكلّ واحدة من هذه الخِدمات: هل أحتاج لهذه الخدمة؟ هل تعمل الخدمة على واجهات لا تحتاج إليها؟ هل يحب تحديدها بعنوان IP واحد؟ هل قواعد الجدار النّاريّ معدّة بطريقة تسمح للبيانات المرخَّص لها بالمرور إلى الخدمة؟ هل يمنع الجدار النّاريّ الوصول غير المرخَّص إلى الخدمة؟ هل لديك وسيلة تحصُل بها على إشعارات عن الثّغرات المُكتشفة في البرنامج؟ يجب أن يكون فحص الخدمة تدبيرًا قيّاسيًّا عند إعداد أي خادوم جديد. 2- ما مدى صعوبة إعداد فحص الخدمات؟ الفحص الأساسيّ للخدمة سهلٌ جدًّا، إذ يعرض أمر netstat الخدمات الّتي تُنصِت لحركة البيانات عبر منافذ كلّ واجهة. في ما يلي مثال يعرض اسم البرنامج، معرّف العمليّة PID والعناوين المستخدَمة لحركة البيانات وفقًا لبروتوكول نقل البيانات (TCP أو UDP): sudo netstat -plunt ستكون المُخرجات مقاربة للتّاليّة: Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 887/sshd tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 919/nginx tcp6 0 0 :::22 :::* LISTEN 887/sshd tcp6 0 0 :::80 :::* LISTEN 919/nginx الأعمدة الأساسيّة الّتي يجب عليك الانتباه إليها هي Porto (المنفذ) ، Local Address (العنوان المحلّي)، ومعرّف العمليّة/البرنامج (PID/Program). إذا كان عنوان IP الّذي تستقبل الخدمة عليه الاتّصالات هو 0.0.0.0 فهذا يعني أنّ الخدمة تقبل الاتّصالات من جميع الواجهات. فحص الملفّات وأنظمة الكشف عن التّطفّل Intrusion detection systems نعني بفحص الملفّات العمليّة الّتي بموجبها نُقارن وضعيّة النّظام الحاليّة بسجلّ لملفّات النّظام وخصائصها عندما كان في وضعيّة تُعرف بأنّها جيّدة. يُستخدم فحص الملفّات للتّعرّف على التّغييرات الّتي يُمكن أن يكون النّظام قد سمح بها. نظام الكشف عن التّطفّل (IDS اختصارًا) هو برنامج يُراقب نظام التّشغيل أو الشّبكة بحثًا عن أنشطة غير مسموح بها. تعتمد الكثير من أنظمة الكشف عن التّطفّل المُستضافة على الخادوم على طريقة فحص الملفّات للتّحقّق من وجود تعديلات في نظام التّشغيل. 1- كيف تُحسّن أنظمة الكشف عن التّطفّل وفحص الملفّات من الأمان؟ إذا كنت مهتمًّا بالرّفع من مستوى أمان بنيتك التّحتيّة فمن المفيد إجراء فحوص على مستوى الملفّات، مثلها مثل الخدمات. يُمكن أن يكون هذا الإجراء دوريًّا، يؤدّيه المسؤول؛ أو آليًّا ضمن نظام للكشف عن التّطفّل. تعدّ هذه الوسائل من الطّرق القليلة الّتي تتأكّد من خلالها أنّ نظام الملفّات Filesystem لم يغيِّره أو يُعدِّل عليه مستخدم أو برنامج. يُفضّل المتطفّلون في كثير من الأحيان، لأسباب مختلفة، البقاء متخفّين للاستمرار في استغلال الثّغرات الموجودة في النّظام لمدّة أطول. يُمكن لمن يستغلّ ثغراتٍ في النّظام أن يُبدل ملفّات تنفيذيّة بنُسخ مُعدَّلة منها؛ سيُخبرك فحص نظام الملفّات بالملفّات المُعدًّل عليها إن وُجدت ممّا يُساعد في التّأكّد من تكامل بيئة الخادوم. 2- ما مدى صعوبة إعداد فحص الملفّات وأنظمة الكشف عن التّطفّل؟ قد يكون تثبيت نظام للكشف عن التّطفّل أو إجراء فحص للملفّات عمليّة إضافيّة تأخذ جهدًا لا بأس به. يتضمّن الإعداد الابتدائيّ إخبارَ نظام الكشف عن التّطفّل يكلّ التّغييرات غير القياسيّة الّتي أجريتها على الخادوم، وتحديدَ مسارات قد تُستثنى لإنشاء خطّ مرجعيّ للاعتماد عليه. تجعل أنظمة الكشف عن التّطفّل من عمليّات الإدارة اليوميّة أكثر تكرارًا وتعقّد من تحديث البرامج ونظام التّشغيل، حيث ستحتاج لإعادة التّحقّق من النّظام قبل تنفيذ التّحديثات ثمّ إعادة إنشاء الخطّ المرجعيّ بعد تنفيذ التّحديثات لرصد أي تغييرات على إصدارات البرامج. يجب أيضًا نقل تقارير الكشف إلى مكان آخر غير النّظام الّذي حدث فيه الكشف لمنع المتطفّلين من تعديلها للتّغطيّة على آثارهم. ستزيد أنظمة الكشف عن التّطفّل بلا شكّ من عبْء الإدارة، ولكنّ مقارنة حالة النّظام الحاليّة بأخرى تعرف أنّها جيّدة هيّ الطّريقة الوحيدة للتّأكّد من أنّ الملفّات لم يُعدَّل عليها من دون علمك. Tripwire وAide من أكثر أنظمة الكشف عن التّطفّل انتشارًا. بيئات تنفيذ Execution environments معزولة يُحيل مفهوم “بيئة التّنفيذ المعزولة” إلى أيّ طريقة تشغيل تعمل بموجبها العناصر في مساحات عمل مخصَّصة لها. يُمكن أن تُعدّ بيئة تنفيذ معزولة بتشغيل عناصر التّطبيقات في خواديم خاصّة بها، أو بإعداد الخدمات للعمل في بيئات chroot أو حاويّات Containers. يعتمد مستوى العزل إلى حدّ بعيد على متطلّبات تطبيقاتك وواقع بنيتك التّحتيّة. 1- كيف يُحسّن عزل بيئات التّنفيذ من الأمان؟ يزيد عزل العمليّات في بيئات تنفيذ مستقلّة من قدرتك على تحديد المشاكل الأمنيّة الّتي يُمكن أن تتعرّض لها. يحُدّ الفصل بين العناصر المستقلّة في البنية التّحتيّة من وصول المخترقين إلى بقيّة العناصر في البنية التّحتيّة. 2- ما مدى صعوبة عزل بيئات التّنفيذ؟ تتوقّف صعوبة - أو سهولة - عزل التّطبيقات على طريقة الفصل الّتي تختارها. يُمكن عبر تحزيم التّطبيقات في حاويّات مستقلّة، الحصول بسرعة على مستوى من عزل التّطبيقات؛ ولكن يجب الانتباه إلى أنّ Docker لا يتعامل مع إعداد الحاويّات على أنّه ميزة أمنيّة. قد يوفّر إعداد بيئة Chroot لكلّ عنصُر مستوى من العزل هو الآخر، لكنّ هذه الطّريقة ليست مضمونةً بالكامل لعزل التّطبيقات؛ إذ توجد دائمًا وسيلة لكسر بيئات Chroot. يوفّر نقل العناصر إلى أجهزة مُخصَّصة أفضل مستوى من العزل، كما أنّه الوسيلة الأسهل في كثير من الأحيان؛ ولكنّه في المقابل الخيّار الأغلى نظرًا لثمن الأجهزة الإضافيّة. خاتمة قدّمنا في هذا الدّليل بعض التّحسينات الممكنة، وليس كلّها، من أجل الرّفع من مستوى الأمان في البنية التّحتيّة. تقلّ فعاليّة التّدابير الأمنيّة كلّ ما طال الانتظار في إجرائها. لا يجوز النّظر إلى التّدابير الأمنيّة على أنّها ملحقات، ويجب تنفيذها من البداية إلى جانب الخدمات والتّطبيقات. ترجمة بتصرّف لمقال 7 Security Measures to Protect your Servers.

أنماط حماية سامبا هنالك مستويان أمنيان متوفران لبروتوكول الشبكة «نظام ملفات الإنترنت الشائع» (Common Internet Filesystem اختصارًا CIFS) هما user-level و share-level؛ نمط الحماية المستخدم في سامبا يسمح بمرونة زائدة، موفرًا أربع طرق لاستخدام الحماية من مستوى user-level وطريقة لاستخدام share-level: النمط security=user: يتطلب من العملاء توفير اسم مستخدم وكلمة مرور للاتصال إلى المشاركات؛ حسابات المستخدمين في سامبا منفصلة عن حسابات مستخدمي النظام، لكن الحزمة libpam-smbpass ستُزامن مستخدمي النظام وكلمات مرورهم مع قاعدة بيانات مستخدمي سامبا. النمط security=domain: هذا النمط يسمح لخادوم سامبا بأن يَظهر لعملاء ويندوز كالمتحكم الرئيسي بالنطاق (Primary Domain Controller اختصارًا PDC)، أو متحكم الاحتياطي بالنطاق (Backup Domain Controller اختصارًا BDC)، أو خادوم عضو في النطاق (Domain Member Server اختصارًا DMS)، وسنشرح ذلك في الدرس القادم. النمط security=ADS: السماح لخادوم سامبا بالانضمام إلى نطاق Active Directory كعضو أصيل (native member). النمط security=server: هذا النمط تُرِك قبل أن يتمكن سامبا من أن يصبح خادومًا عضوًا، وبسبب بعض المشاكل الأمنية، فلا يجب أن يُستخدَم؛ راجع قسم «Server Security» من دليل سامبا لمزيدٍ من التفاصيل. النمط security=share: يسمح لجميع العملاء بالاتصال إلى المشاركات دون توفير اسم مستخدم وكلمة مرور. يعتمد اختيارك لنمط الحماية بالبيئة التي تعمل فيها وما الذي تريد من خادوم سامبا أن يُنجزه. النمط Security = User سيعيد هذا القسم ضبط خادوم سامبا لمشاركة الملفات والطباعة من القسمين السابقين، كي يتطلب الاستيثاق. أولًا، ثبِّت الحزمة libpam-smbpass التي ستزامن مستخدمي النظام إلى قاعدة بيانات مستخدمي سامبا: sudo apt-get install libpam-smbpass ملاحظة: لو اخترت مهمة «Samba Server» أثناء التثبيت، فستكون الحزمة libpam-smbpass مثبَّتةً مسبقًا. عدِّل الملف ‎/etc/samba/smb.conf، وعدِّل ما يلي في قسم [share]: guest ok = no في النهاية، أعد تشغيل سامبا لكي تأخذ الإعدادات الجديدة مفعولها: sudo restart smbd sudo restart nmbd سيُطلَب منك الآن إدخال اسم مستخدم وكلمة مرور عند الاتصال إلى المجلدات المشاركة أو الطابعات. ملاحظة: إذا اخترت ربط قرص شبكي للمشاركة، فعليك تفعيل الحقل «Reconnect at Logon»؛ مما يجعله يطلب اسم المستخدم وكلمة المرور مرةً واحدةً فقط، على الأقل إلى أن تُغيَّر كلمة المرور. تأمين المشاركة هنالك عدِّة خيارات متوفرة لزيادة الحماية لمشاركات المجلدات المنفصلة؛ وباستخدام مثال «[share]»، فسيشرح هذا القسم بعض الخيارات الشائعة. المجموعات تُعرِّف المجموعات تشكيلةً من الحواسيب أو المستخدمين الذي يملكون وصولًا متكررًا إلى مورد شبكي معين؛ على سبيل المثال، إذا عُرِّفت المجموعة qa وكانت تحتوي على المستخدمين freda، و danika، و rob؛ ومجموعة ثانية هي support تحتوي على المستخدمين danika، و jeremy، و vincent؛ وضُبِط مورد شبكي معيّن للسماح بالوصول إلى المجموعة qa، والذي بدوره سيمنح المستخدمين freda، و danika، و rob وصولًا لكن ليس jeremy أو vincent؛ ولما كان المستخدم danika ينتمي إلى كلي المجموعتين qa و support؛ فسيتمكن من الوصول إلى الموارد التي يُسمَح لكلا المجموعتين بالوصول إليها، بينما كل المستخدمين الباقيين سيقيدون بالموارد التي تسمح بوصول مجموعتهم إليها. يبحث سامبا عن المجموعات في النظام المحلي المُعرَّفة في ‎/etc/group ليحدد أي مستخدم ينتمي إلى أي مجموعة؛ للمزيد من المعلومات حول إضافة أو إزالة المستخدمين من المجموعات، راجع القسم «إضافة وحذف المستخدمين» من درس إدارة المستخدمين. عند تعريف المجموعات في ملف ضبط سامبا،‏ ‎/etc/samba/smb.conf؛ فإن الصيغة المتعارف عليها هي بدء اسم المجموعة بالرمز «@»؛ على سبيل المثال، إذا أردت تعريف مجموعة مسماة sysadmin في قسم محدد من ملف ‎/‎etc/samba/smb.conf، فعليك إدخال اسم المجموعة ‎@sysadmin. أذونات الملف تُعرِّف أذونات الملف الحقوق المحددة التي يملكها حاسوب أو مستخدم على مجلد أو ملف أو مجموعة ملفات؛ يمكن تعريف هذه الأذونات بتعديل الملف ‎/etc/samba/smb.conf وتحديد الأذونات لمشاركة ملف معيّن. على سبيل المثال، لو عَرَّفتَ مشاركة سامبا اسمها share وأردت إعطاء أذونات «للقراءة فقط» لمجموعة المستخدم qa؛ لكنك تريد السماح بالكتابة لمجموعة اسمها sysadmin ومستخدم اسمه vincent، فعليك تعديل الملف ‎/etc/samba/smb.conf وإضافة القيود الآتية تحت قيد [share]: read list = @qa write list = @sysadmin, vincent طريقة أخرى لضبط الأذونات في سامبا هي التصريح عن أذونات «إدارية» لمورد معيّن مُشارَك؛ حيث يمكن للمستخدمين الذي يملكون أذونات إدارية قراءة أو كتابة أو تعديل أيّة معلومات موجودة في المورد الذي أُعطي ذاك المستخدم أذوناتٍ إدارية خاصة عليه. على سبيل المثال، إذا أردت إعطاء المستخدم melissa أذوناتٍ إدارية للمشاركة share، فعليك تعديل الملف ‎/etc/samba/smb.conf وإضافة الأسطر الآتية تحت القيد [share]: admin users = melissa بعد تعديل الملف ‎/etc/samba/smb.conf، أعد تشغيل سامبا كي تأخذ التعديلات مجراها: sudo restart smbd sudo restart nmbd ملاحظة: لكي تعمل «read list» و «write list»، لا يجب أن يكون نمط حماية المستخدم في سامبا مضبوطًا إلى security = share. ضُبِط الآن سامبا ليحدد أيّة مجموعات تملك الوصول إلى مجلد مُشارَك، يجب الآن تحديث أذونات نظام الملفات. نظام أذونات لينُكس التقليدي لا يترابط جيدًا مع قوائم التحكم بالوصول في ويندوز (NT (Windows NT Access Control Lists اختصارًا ACLs؛ لحسن الحظ، توجد POSIX ACLs في خواديم أوبنتو موفرةً تحكمًا أفضل؛ على سبيل المثال، للسماح باستخدام ACLs على ‎/srv بنظام ملفات EXT3، فعدِّل الملف ‎/etc/fstab وأضف الخيار acl كما يلي: UUID=66bcdd2e-8861-4fb0-b7e4-e61c569fe17d /srv ext3 noatime,relatime,acl 0 1 ثم أعد وصل القسم: sudo mount -v -o remount /srv ملاحظة: تفترض الأوامر السابقة أن ‎/srv على قسمٍ مختلف؛ إذا كان ‎/srv، أو أي مسار آخر تختار مشاركته، هو جزء من قسم الجذر /، فربما عليك إعادة إقلاع النظام. لمطابقة ضبط سامبا، فستُعطى المجموعة sysadmin أذونات القراءة والكتابة والتنفيذ إلى ‎/srv/samba ‎/share، وستُعطى المجموعة qa إذنَيّ القراءة والتنفيذ؛ وستُملَك الملفات من المستخدم melissa. أدخِل الأوامر الآتية في الطرفية: sudo chown -R melissa /srv/samba/share/ sudo chgrp -R sysadmin /srv/samba/share/ sudo setfacl -R -m g:qa:rx /srv/samba/share/ ملاحظة: الأمر setfacl السابق يعطي أذونات التنفيذ إلى جميع الملفات في المجلد ‎/‎srv/samba/share، ربما يكون أو لا يكون هذا ما تريده. الآن من عميل ويندوز، يجب أن تلاحظ تطبيق الأذونات الجديدة للملف؛ راجع صفحات دليل acl و setfacl لمزيد من المعلومات حول POSIX ACLs. ملف ضبط سامبا لبرمجية AppArmor يأتي أوبنتو مع وحدة الحماية AppArmor، الذي يوفر تحكمًا مقيّدًا للوصول؛ ملف الضبط الافتراضي الخاص ببرمجية AppArmor لخدمة سامبا يجب أن يلائم ضبطك، للمزيد من التفاصيل حول استخدام AppArmor راجع درس AppArmor. هنالك ملفات ضبط افتراضية لكلي ‎/usr/sbin/smbd و ‎/usr/sbin/nmbd (الملفات الثنائية لعفريت سامبا) كجزءٍ من حزمة apparmor-profiles؛ أدخِل الأمر الآتي من الطرفية لتثبيت الحزمة: sudo apt-get install apparmor-profiles apparmor-utils افتراضيًا، تكون ملفات الضبط لعفريتي smbd و nmbd في وضع «البناء» مما يسمح لخدمة سامبا بالعمل دون تعديل ملف الضبط، وستُسجَّل الأخطاء فقط؛ لجعل ملف ضبط smbd في وضع «الإجبار»، ولكي يعمل سامبا كما يجب، فيجب أن يُعدَّل ملف الضبط لتضمين المجلدات التي تمت مشاركتها. عدِّل ملف ‎/etc/apparmor.d/usr.sbin.smbd مضيفًا معلومات [share]: /srv/samba/share/ r, /srv/samba/share/** rwkix, ضع الملف في وضع «الإجبار» وأعد تحميله: sudo aa-enforce /usr/sbin/smbd cat /etc/apparmor.d/usr.sbin.smbd | sudo apparmor_parser -r يجب أن تكون قادرًا على قراءة وكتابة وتنفيذ الملفات في المجلد المُشارَك كالمعتاد، لكن smbd يملك الآن حق الوصول إلى الملفات والمجلدات المضبوطة فقط؛ تأكد من إضافة القيود لكل مجلد تضبط مشاركته في سامبا؛ وستسجل أيضًا أيّة أخطاء إلى ‎/var/log/syslog. مصادر الفصل الثامن عشر من «Samba HOWTO Collection» مخصصٌ للحماية. للمزيد من المعلومات حول Samba و ACLs، راجع الصفحة «Samba ACLs». راجع أيضًا صفحة ويكي أوبنتو «Samba». ترجمة -وبتصرف- للمقال Ubuntu Server Guide: Securing File and Printer.

يعد توفير الخدمات وإتاحة التطبيقات والموارد للمستخدمين الأهداف الأساسية لتجهيز الخواديم وإعدادها؛ إلا أن أي خادوم موصول بشبكة الإنترنت سيتعرض لا محالة لمستخدمين سيئي النيات يأملون استغلال الثغرات الأمنية للحصول على صلاحيات الدخول. توجد الجدران النارية Firewalls بهدف حجب المنافذ Ports غير المستخدمة؛ إلا أن السؤال يُطرح عن ما يجب فعله للخدمات التي تريد الوصول إليها دون أن تكون معروضة للجميع، تريد استخدامها عند الحاجة ومنع الوصول إليها في الأوقات الأخرى. الطرق على المنافذ Port knocking هو إحدى وسائل إخفاء الخدمات العاملة على جهازك؛ فتعمل على جعل الجدار الناري يحمي الخدمات إلى أن تطلب منه فتح منفذ عبر إرسال متتالية محدَّدة من البيانات. سنتحدث في هذا الدليل عن كيفية إعداد آلية للطرق على المنافذ من أجل إخفاء خدمة SSH باستخدام حزمة knockd على أوبنتو 14.04. ملحوظة: يغطي هذا الشرح الإصدار الرابع من بروتوكول IP. يفصل لينكس بين تأميني الإصدار الرابع والإصدار السادس. على سبيل المثال، لا تنطبق قواعد iptables إلا على حزم البيانات المنقولة عبر عناوين الإصدار الرابع، غير أنه يوجد مكافئ لها بالنسبة لعناوين الإصدار الرابع وهو ip6tables. إذا كان الخادوم لديك معدا لاستخدام عناوين الإصدار السادس فلا تنس تأمين كل من واجهات Interfaces كل من الإصدارين باستخدام الأدوات المناسبة. كيف يعمل الطرق على المنافذ؟تتمثل فكرة الطرق على المنفذ في إعداد خدمة لمراقبة سجلات Logs الجدار الناري أو واجهات Interfaces الشبكة بحثا عن محاولات اتصال. تغير الخدمةُ قواعدَ الجدار الناري، إذا جرت محاولات اتصال معرَّفة مسبقا (تعرف بالطرْقات Knocks)، من أجل السماح بالاتصالات عبر منفذ معيَّن. تسمح هذه الطريقة بالإبقاء على الخدمات مخفية إلى الوقت الذي تريد استخدمها فيه. لا يناسب هذا الإعداد خواديم الويب التي يُسمَح عادة لجميع الاتصالات بالوصول إليها؛ إلا أنها مفيدة للخدمات الموجهة فقط لمستخدمين معروفين وبصلاحيات محددة، على سبيل المثال خدمة SSH. لا ينبغي جعل الطرق على المنافذ التدبير الوحيد لتأمين الخدمات، رغم أن متتالية الطرق يمكن أن تكون معقدة جدا. تنفذ الخدمات عادة طرق تأمين واستيثاق خاصة بها تُعرَض للمستخدم بعد إرساله متتالية الطرق الصحيحة. يضيف الطرق على المنافذ، في هذا الإطار، طبقة جديدة يجب أن يمر بها المستخدم قبل أن يرى طريقة الاستيثاق المعتادة. يوفر الطرق على المنافذ ميزة أخرى مفيدة هي أنه لا يُصدِر أي ردود على محاولات الطرق. إذا حاول متسلل فحص المنافذ فسيرى أنها مغلقة وإن إحاول تخمين متتالية الطرق فيجب عليه التحقق بعد كل تخمين لمعرفة إن كان المنفذ فُتِح أم لا؛ الأمر الذي سيكون كافيا في أغلب الحالات ليمنع المهاجمين من الدخول ويصرف أنظارهم عن إعادة المحاولة. سنستخدم خلال هذا الشرح الجدار الناري المدمج افتراضيا مع أوبنتو (iptables) ونثبت برنامج knockd لتوفير وظيفة الطرق على المنافذ. إعداد IPTables لمنع أغلب الاتصالاتنحتاج، قبل أن نبدأ في إعداد آلية للطرق على المنافذ، إلى ضبط قاعدي للجدار الناري. سنمنع كل الاتصالات تقريبا. يأتي جدار IPTables الناري مضمنا في أوبنتو إلا أنه لا توجد افتراضيا أي قاعدة مما يعني أنه يُسمَح لجميع الاتصالات بالمرور. يمكنك تعلم كيفية إعداد جدار ناري باستخدام IPTables على Ubuntu 14.04 . نبدأ بالسماح بالاتصال عبر الجهاز المحلي. يعني هذا القبول بالبيانات المرسَلة من الخادوم نفسه وهو ما يسمح للخدمات العاملة على الخادوم بالتواصل في ما بينها. sudo iptables -A INPUT -i lo -j ACCEPTيضيف الأمر أعلاه قاعدة إلى سلسلة INPUT التي تتعامل مع جميع الاتصالات القادمة إلى الخادوم. تطلب القاعدة التي أضفناها من iptables قبول جميع البيانات القادمة من الواجهة المحلية lo التي تستخدم للاتصالات الداخلية. الخطوة التالية هي السماح لكل الاتصالات الجارية بالاستمرار؛ لذا ننفذ الأمر: sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPTتطلب القاعدة الموجودة في الأمر أعلاه من iptables السماح للاتصالات الجارية والبيانات المتعلقة بها بالمرور. هذه القاعدة مهمة ليمكننا مواصلة الاتصال بالخادوم عن بعد باستخدام SSH حتى لا نفقد الاتصال به عند بدء حظر الاتصالات. ثم نضيف قواعد للسماح بالخدمات الموجهة للعموم، أي تلك التي لا يوجد شرط على مستخدميها مثل خادوم الويب (إن وُجد) الذي يعمل عادة على المنفذ رقم 80: sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPTاحذر أن تضيف قواعد للخدمات التي ستستخدم الطرق على المنافذ للوصول إليها. ستكون إضافةُ هذه القواعد مهمةَ خدمة الطرق التي ستعدل قواعد الجدار الناري حسب الطلب. لهذا السبب لن نضيف خادوم SSH إلى إعداد iptables. حتى هذه اللحظة لم نضف سوى قواعد تقبل الاتصال ولم نضف أي قواعد لحظر الاتصالات. وهو ما يعني أن الجدار الناري لا زال يقبل جميع الاتصالات؛ بعضها مذكور صراحة، وهي تلك التي أضفناها. سنمنع الآن جميع الاتصالات، ما عدا تلك التي حددناها في الأوامر السابقة: sudo iptables -A INPUT -j DROPيعني هذا أن جميع محاولات الاتصال التي لا توافق إحدى القواعد المذكورة سابقا ستُحظَر. تمكن معاينة القواعد بتنفيذ الأمر: sudo iptables -Sالنتيجة: -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT -A INPUT -j DROPلاحظ أنه لا توجد حتى الآن قاعدة في إعدادات الجدار الناري تسمح باتصالات SSH. أنهينا الآن قواعد الجدار الناري، بقي أن نجعلها دائمة حتى لا يعاد تعيينها عند إعادة تشغيل الخادوم. نستخدم أداة iptables-persistent لهذا الغرض. نفذ الأمر التالي لتثبيتها: sudo apt-get install iptables-persistentثم شغل الخدمة بعد انتهاء التثبيت: sudo service iptables-persistent startتثبيت خدمة Knockdيدعى البرنامج الذي سنستخدمه لتمكين آلية للطرق عبر المنافذ knockd. ثبته بتنفيذ الأمر التالي: sudo apt-get install knockdلا يشغَّل البرنامج مباشرة بعد ثبيته وذلك حتى لا يحظُر بيانات كثيفة على الفور. يجب أن تضبط الخدمة وتفعلها يدويا. إعداد Knockd لاستخدام الطرق على المنافذيوجد ملف إعداد يجب تحريره لإعداد الخدمة: sudo nano /etc/knockd.confيجب أن يظهر لديك ملف بمحتوى شبيه بالتالي: [options] UseSyslog [openSSH] sequence = 7000,8000,9000 seq_timeout = 5 command = /sbin/iptables -A INPUT -s %IP% -p tcp --dport 22 -j ACCEPT tcpflags = syn [closeSSH] sequence = 9000,8000,7000 seq_timeout = 5 command = /sbin/iptables -D INPUT -s %IP% -p tcp --dport 22 -j ACCEPT tcpflags = synفي المقطع [options] توجد تعليمة باسم UseSyslog تخبر خدمة knockd أن عليها استخدام الوسائل الاعتيادية لحفظ السجلات. ينتج عن هذه التعليمة إدراج السجلات ضمن المجلد var/log/messages/. إذا أردت حفظ السجلات في مكان مغاير فيمكنك ذلك باستخدام التعليمة التالية بدلا من UseSyslog (حيث path/to/log/file/ مسار ملف السجلات): LogFile = /path/to/log/fileثم يأتي مقطعان يُستخدَمان لتجميع قواعد تُطابِق جميعها حدثا واحدا. لا يؤثر اسم المقطع على عمله إلا أنه يفيد لإعطاء نبذة لمن يفتح الملف عن عمل المقطع. يوجد في ملف الإعداد الافتراضي مقطع يفتح منفذ SSH وآخر لغلق نفس المنفذ. المعطى الذي يعيّن نمط الطرق هو التالي: sequence = 7000,8000,9000يعني النمط أعلاه أن مجموعة القواعد هذه ستبحث ما إذا كان نفس عنوان IP طلب الاتصال على المنفذ رقم 7000 متبوعا مباشرة بالمنفذ 8000 ثم أخيرا المنفذ 9000. سنغير متتالية الطرق لتصبح على النحو التالي: sequence = 2022,3022,4022يوجد معطيان آخران في المجموعة يراقبان النشاط: seq_timeout = 5 tcpflags = synيحدد المعطى الأول مدة زمنية يجب أن تكتمل فيها متتالية طلبات الاتصال المعرفة في المعطى السابق. أما المعطى الثاني فيحدد خيارا يجب أن يتواجد في حزم tcp حتى تكون صالحة (يستخدم هذا الخيار لمعرفة الطريقة التي يجب بها التعامل مع الحزم وحالتها). يشيع استخدام القيمة syn للتفريق بين الحزم التي نريدها وتلك التي تنشئها برامج مثل SSH في الخلفية. ثم نجد الأمر: command = /sbin/iptables -A INPUT -s %IP% -p tcp --dport 22 -j ACCEPTيجب أن تتعرف على قاعدة من قواعد iptables. يمكن إذن تفسير المقطع بأنه عند إرسال متتالية الطرق في الوقت المحدد فسينفذ الأمر أعلاه من أجل السماح باتصالات SSH. إذا تفطنت لإعدادات iptables فسترى أن القاعدة الجديدة تستخدم الخيار A- لإلحاق القاعدة بنهاية سلسلة INPUT؛ وهو ما يعني أنها ستكون بعد القاعدة التي تحظر كافة الاتصالات. سنحتاج للتعديل على الأمر وإبدال القاعدة بأخرى تُدرَج في بداية الملف؛ لذا سنستخدم الخيار I- ونعلم القاعدة على أنها القاعدة رقم 1: command = /sbin/iptables -I INPUT 1 -s %IP% -p tcp --dport 22 -j ACCEPTستُضاف قاعدة جديدة للسماح بقبول اتصالات SSH من المسخدِم الذي أرسل متتالية الطرق. الجزء %IP% الموجود في القاعدة سيُبدَل بعنوان IP الذي أتت منه متتالية الطرق. المقطع الأخير يؤدي عملا مشابها بمتتالية مغايرة وأمر يعمد إلى حذف قاعدة فتح اتصالات SSH من iptables. سنستخدم المتتالية 4022,3022,2022 لإنهاء الاتصال الذي أنشأناه وغلق المنفذ المرتبط به (أي المنفذ رقم 22). يجب تغيير المتتاليات الموجودة افتراضيا في المقاطع وإبدالها بأخرى عشوائية. ترك المتتالية الموجودة افتراضيا في ملف الإعداد يجعل من تنفيذ آلية طرق المنافذ هذه بلا فائدة (الجميع يعرف المتتالية الافتراضية). أغلق الملف (CTRl + X) ثم احفظه (CTRL +O). تشغيل خدمة Knockdيمكننا الآن بعد أن أنهينا إعداد knockd للحصول على مجموعة قواعد صالحة اختبارُ الإعداد بتشغيل الخدمة. تذكر أن الإعداد الافتراضي صالح إلا أنه لن يكون آمنا إلا إذا غيرت متتالية الطرق الافتراضية لكل مقطع. يجب التعديل على ملف آخر لتفعيل الخدمة: sudo nano /etc/default/knockdنغير قيمة الخيار START_KNOCKD لتصبح 1: START_KNOCKD=1أغلق الملف (CTRl + X) ثم احفظه (CTRL +O). يمكننا الآن تشغيل الخدمة، لذا ننفذ الأمر: sudo service knockd startيشغل الأمر خدمة knockd ويسمح بتغيير قواعد الجدار الناري عند الطرق على المنافذ حسب المتتالية المعرَّفة في ملف الإعداد. اختبار الطرق على المنافذسنرى الآن ما إذا كان بإمكاننا التعديل على قواعد iptables بالطرق على المنافذ المعرفة في ملف الإعداد. أبق - احترازا - على اتصالك الجاري بالخادوم نشطا وافتح نافذة جديدة للطرفية. توجد الكثير من الأدوات للاستخدام في طرق المنافذ؛ ومن أشهرها nmap، netcat وعميل آخر صُمِّم خصيصا للطرق واسمه knock. سنستخدم أداة knock ولكن قبل ذلك فلنتأكد أولا من أن منفذ SSH مغلق فعليا. ssh root@server_ip_addressيجب أن تكون النتيجة على النحو التالي: ssh: connect to host server_ip_address port 22: Operation timed outيعني هذا أن الخادوم لم يُجِب وأن المهلة الممنوحة للاتصال انقضت. يعود السبب إلى أن خدمة SSH محظورة على الخادوم حسب قواعد iptables. اضغط على زري CTRL وC للعودة إلى الطرفية إن طالت مدة محاولة الاتصال. أداة Knock لطرق المنافذأداة knock وسيلة سهلة للطرق على المنافذ يطورها نفس فريق knockd. تُضَمَّن هذه الأداة في حزمة knockd؛ لذا يمكن تثبيتها على الجهاز العميل مثل ما فعلنا على الخادوم: sudo apt-get install knockdيمكن أيضا تنزيل الأداة من الموقع الرسمي الذي توجد به إصدارات لكل من Windows وOS X؛ وكذلك لأندرويد وiOS. تُستخدَم أداة knock على النحو التالي: knock server_ip_address sequenceحيث sequence متتالية الطرق وserver_ip_address عنوان IP الخادوم. بالنسبة لمثالنا سيكون الاستخدام على النحو التالي: knock server_ip_address 2022 3022 4022ولإغلاق المنفذ نرسل المتتالية التي حددناها في ملف الإعداد: knock server_ip_address 4022 3022 2022إعداد Knockd لغلق الاتصالات تلقائياتأكدنا الآن من أن خدمة الطرق تعمل. سنغير الإعدادات لجعلها أكثر صلابة. أعد فتح ملف الإعداد على الخادوم sudo nano /etc/knockd.confيتيح knockd إمكانية تحديد مدة زمنية يُنفَّذ أمر محدد بعد انقضائها؛ نستفيد من هذه الميزة للاكتفاء بقاعدة واحدة لفتح وإغلاق منفذ SSH؛ مما يعني أننا لن نحتاج لإرسال متتالية الطرق حتى يغلَق المنفذ. يمكن حذف مقاطع openSSH وcloseSSH ضمن ملف الإعداد لأننا سنبدلها بمقطع وحيد نسميه SSH: [options] UseSyslog [SSH]سنعرِّف داخل مقطع SSH متتالية للطرق، خيار tcpflags ومهلة زمنية للانتظار ينبغي الطرق على المنافذ خلالها؛ مثل ما فعلنا مع المقطعين السابقين. سنضيف أيضا الأمر المستخدَم لفتح منفذ SSH: [options] UseSyslog [SSH] sequence = 5438,3428,3280,4479 tcpflags = syn seq_timeout = 15 start_command = /sbin/iptables -I INPUT 1 -s %IP% -p tcp --dport 22 -j ACCEPTاختر متتالية منافذ فريدة. حددنا في هذا المثال أربعة منافذ. تمكن زيادتها حسب رغبتك ولكن انتبه إلى أنه يجب طرق المنافذ خلال المدة الزمنية (بالثواني) المحدَّدة ضمن معطى seq_timeout. معطى start_command هو نفسه معطىcommand الذي رأيناه في الأمثلة السابقة؛ الفرق الوحيد هو أن الاسم أكثر إسهابا. يأتي الآن دور المعطيات الجديدة التي ستساعدنا على غلق المنفذ: [options] UseSyslog [SSH] sequence = 5438,3428,3280,4479 tcpflags = syn seq_timeout = 15 start_command = /sbin/iptables -I INPUT 1 -s %IP% -p tcp --dport 22 -j ACCEPT cmd_timeout = 10 stop_command = /sbin/iptables -D INPUT -s %IP% -p tcp --dport 22 -j ACCEPTيحدد معطى cmd_timeout الثواني التي ستنتظرها خدمة knockd قبل تنفيذ الأمر الموجود ضمن معطى stop_command. النتيجة هي أنه عند إرسال المتتالية الصحيحة فإن المنفذ سيُفتح لمدة 10 ثوان ثم يُغلق من جديد. احفظ الملف ثم أغلقه. أعد تشغيل الخدمة لاعتماد القواعد الجديدة: sudo service knockd restartيمكن استخدام الأمر التالي للاتصال ضمن الوقت المحدد: knock server_ip_address 5438 3428 3280 4479 && ssh root@server_ip_addressسيغلق المنفذ بعد 10 ثوان من الاتصال. خاتمةيُنظَر إلى الطرق على المنافذ على أنه مجرد إخفاء للخدمات بدل تأمينها؛ على الرغم من ذلك يبقى وسيلة رائعة لإضافة طبقة أمان جديدة ضد الهجمات العشوائية. يجب دائما تأمين خدماتك عبر الوسائل الأمنية المتاحة في النظام إلا أن إضافة مِصيدة مثل الطرق على المنافذ أمام التدابير الأمنية المعتادة يمكن أن يقلل بقدر ملحوظ هجمات القوة القاسية ومحاولات التسلل التي يتعرض لها خادومك. ترجمة - بتصرف - لمقال How To Use Port Knocking to Hide your SSH Daemon from Attackers on Ubuntu.

هناك العديد من لغات قواعد البيانات SQL التي تعمل على أنظمة اللينكس واليونكس، ومن أشهر لغات قواعد البيانات العلائقية التي تعمل في بيئات الخوادم هما MySQL وMariaDB. ومع ذلك، مثل أغلب البرامج، هذه الأدوات يمكن أن تكون الاحتياجات الأمنية إذا تم تكوينها بشكل غير صحيح، هذا الشرح التعليمي سوف يرشدك لبعض الخطوات الأساسية التي يمكن اتخاذها لتأمين قاعدة البيانات الخاصة بك سواء MariaDB أو MySQL، والتأكد من أنها ليست بابًا مفتوحًا إلى VPS الخاص بك. من أجل البساطة والوضوح، سوف نستخدم MySQL على خادوم Ubuntu كمثال، ومع أن هذه التقنيات يمكن تطبيقها على توزيعات لينكس الأخرى، ويمكن استخدامها مع MariaDB كذلك. الإعداد الأوليMySQL يمنحك فرصة لاتخاذ الخطوة الأولى نحو تحقيق الأمن أثناء التثبيت، وسوف نطلب منكم وضع كلمة سر root (الجذر). $ sudo apt-get install mysql-server Configuring mysql-server-5.5 While not mandatory, it is highly recommended that you set a password for the MySQL administrative "root" user. If this field is left blank, the password will not be changed. New password for the MySQL "root" user:يمكنك دائما تعيين كلمة سر root في وقت لاحق، ولكن ليس هناك سبب لتخطي هذه الخطوة، لذلك يجب تأمين حساب المسؤول الخاص بك من البداية. بمجرد اكتمال التثبيت، يجب علينا تشغيل عدد قليل من النصوص المدرجة. أولاً، سوف نستخدم "mysql_install_db" وهو سكريبت نصي لإنشاء تصميم قواعد البيانات الخاصة بنا. $ sudo mysql_install_dbبعد ذلك، قم بتشغيل السكريبت الذي يسمى "mysql_secure_installation"، وسيرشدنا لبعض الإجراءات التي من شأنها إزالة بعض الافتراضات التي تشكل خطرا على استخدامها في بيئة الإنتاج. $ sudo mysql_secure_installationأولاً سوف يطلب منك إدخال كلمة السر الجذر وستقوم بإدخالها أثناء التثبيت، وبعد ذلك مباشرة ، سوف يطلب منك سلسلة من الأسئلة، بدءا من إذا كنت ترغب في تغيير كلمة سر الجذر. هذه هي فرصة أخرى لتغيير كلمة المرور الخاصة بك إلى أي شيء آمن إذا لم تكن قد فعلت ذلك بالفعل. يجب أن تكون الإجابة "Y" (نعم) لجميع الأسئلة المتبقية. سيؤدي ذلك إلى إزالة قدرة أي شخص لتسجيل الدخول إلى MySQL افتراضيا، وتعطيل تسجيل الدخول عن بعد على حساب المسؤول، وإزالة بعض قواعد بيانات الاختبار غير الآمنة، وتحديث قاعدة البيانات التي تعمل حاليا لاعتماد هذه التغيرات. اعتبارات أمنيةالقاعدة البسيطة لزيادة حماية MySQL (ومعظم الأنظمة الأخرى) هو إعطاء صلاحيات النفاذ فقط عند الضرورة. أحيانا لكي تكون بياناتك آمنة يجب أن توزان بين الراحة والأمان. في هذا الدليل، سوف نميل إلى الجانب الأمني، لذا فإن استخدامك الخاص لقاعدة البيانات يمكن أن يدفعك لإنتقاء أحد هذه الخيارات. زيادة الأمن من خلال ملف My.cnfملف الإعدادت الرئيسية في MySQL هو ملف يسمى "my.cnf" الموجود في "/etc/mysql/" هذا الامتداد على أوبونتو وامتداد "/etc/" على بعض الخواديم الأخرى. سوف نقوم بتغيير بعض الإعدادات في هذا الملف لتأمين MySQL الخاصة بنا. فتح الملف مع صلاحيات الجذر، تغيير مسار الامتداد حسب الحاجة إذا كنت تتبع هذا الشرح التعليمي على نظام مختلف: $ sudo nano /etc/mysql/my.cnfالإعداد الأولي التي يجب علينا أن نتحقق منه "وضع عنوان IP" ضمن قسم "[mysqld]". ويجب تعيين هذا الإعداد على جهاز الشبكة المحلي loopback ، وهو "127.0.0.1". $ bind-address = 127.0.0.1هذا يجعل من أن MySQL لا تقبل الاتصالات من أي مكان باستثناء الجهاز المحلي. إذا كنت بحاجة للوصول إلى قاعدة البيانات من جهاز آخر، خذ بالاعتبار الاتصال عن طريق SSH للقيام بالاستعلام وادارة قاعدة البيانات الخاصة بك محليا وإرسال النتائج من خلال قناة SSH. الفجوة التالية التي سوف نعدلها، هي وظيفة تتيح لك الوصول إلى نظام الملفات من داخل MySQL، يمكن أن يكون لها تداعيات أمنية خطيرة ويجب ايقافها إلا إذا كنت في حاجة شديدة لها. في نفس المقطع من الملف، سوف نقوم بإضافة التوجيه لتعطيل هذه القدرة على تحميل الملفات المحلية: local-infile=0إذا كان لدينا مساحة كافية ولا تعمل على قاعدة بيانات ضخمة، فإنه يمكن أن يكون مفيدا لتسجيل معلومات إضافية لمراقبة أي نشاط مثير للشبهة. تسجيل معلومات أكثر من اللازم يضعف الأداء، لذلك قم بوزن أي شيء تحتاجه بعناية. يمكنك وضع تسجيل الأحداث المتغيرة داخل القسم نفسه "[mysqld]" التي قمنا بالإضافة فيها: log=/var/log/mysql-logfileتأكد من أن سجل MySQL يعمل، سجل الأخطاء، وسجل MySQL ليس سهل القراءة: $ sudo ls -l /var/log/mysql* -rw-r----- 1 mysql adm 0 Jul 23 18:06 /var/log/mysql.err -rw-r----- 1 mysql adm 0 Jul 23 18:06 /var/log/mysql.log /var/log/mysql: total 28 -rw-rw---- 1 mysql adm 20694 Jul 23 19:17 error.logتأمين MySQL من الداخلهناك عدد من الخطوات التي يمكنك اتخاذها أثناء استخدام MySQL لتحسين الوضع الأمني. سوف نقوم بإدخال الأوامر في هذا القسم في بداخل واجهة MySQL ، لذلك نحن بحاجة إلى تسجيل الدخول. $ mysql -u root -pسيطلب منك إدخال كلمة سر الجذر التي قمت بإعدادها في وقت سابق. تأمين كلمات السر والمستخدمين المرتبطينأولاً، تأكد من وجود مستخدمين بدون كلمة مرور أو المضيف المرتبط في MySQL: SELECT User,Host,Password FROM mysql.user; +------------------+-----------+-------------------------------------------+ | user | host | password | +------------------+-----------+-------------------------------------------+ | root | localhost | *DE06E242B88EFB1FE4B5083587C260BACB2A6158 | | demo-user | % | | | root | 127.0.0.1 | *DE06E242B88EFB1FE4B5083587C260BACB2A6158 | | root | ::1 | *DE06E242B88EFB1FE4B5083587C260BACB2A6158 | | debian-sys-maint | localhost | *ECE81E38F064E50419F3074004A8352B6A683390 | +------------------+-----------+-------------------------------------------+ 5 rows in set (0.00 sec)كما ترون في مثالنا هذا "المستخدم التجريبي " ليس لديه كلمة مرور، وهو ساري المفعول بغض النظر عن ما هو عليه في المضيف، ويعتبر هذا آمن جدا. يمكننا وضع كلمة سر للمستخدم مع هذا الأمر Change "كلمة المرور الجديدة" أدخل كلمة المرور التي ترغب بها. UPDATE mysql.user SET Password=PASSWORD('newPassWord') WHERE User=""demo-user";إذاً علينا التحقق من جدول المستخدم مرة أخرى، وسوف نرى أن المستخدم التجريبي لديه الآن كلمة سر: SELECT User,Host,Password FROM mysql.user;+------------------+-----------+-------------------------------------------+ | user | host | password | +------------------+-----------+-------------------------------------------+ | root | localhost | *DE06E242B88EFB1FE4B5083587C260BACB2A6158 | | demo-user | % | *D8DECEC305209EEFEC43008E1D420E1AA06B19E0 | | root | 127.0.0.1 | *DE06E242B88EFB1FE4B5083587C260BACB2A6158 | | root | ::1 | *DE06E242B88EFB1FE4B5083587C260BACB2A6158 | | debian-sys-maint | localhost | *ECE81E38F064E50419F3074004A8352B6A683390 | +------------------+-----------+-------------------------------------------+ 5 rows in set (0.00 sec)إذا ما نظرت هذا الحقل"host"، سترى أن لا يزال لدينا "٪"، هي عبارة عن بطاقة بديلة وهذا يعني أي مضيف. وليس هذا ما نريده، دعونا نغيرها إلى " localhost". UPDATE mysql.user SET Host='localhost' WHERE User="demo-user";إذا تحققنا مرة أخرى، يمكننا أن نرى أن جدول المستخدم لديه الآن الحقول المناسبة. SELECT User,Host,Password FROM mysql.user;إذا كان لدينا جدول يحتوي على مستخدمين فارغين (لا يجب في هذه المرحلة أن يكونوا "mysql_secure_installation", سنغطي هذه الناحية بأي حال من الأحوال لاحقا)، وينبغي علينا إزالتهم. للقيام بذلك، يمكننا استخدام الأمور التالي لحذف المستخدمين الفارغين من جدول الوصول: DELETE FROM mysql.user WHERE User="";بعد أن يتم تعديل جدول المستخدم، نحن بحاجة إلى إدخال الأمر التالي لتنفيذ صلاحيات جديدة: FLUSH PRIVILEGES;إنشاء مستخدمين محددين لتطبيقات معينة طريقة تشغيل العمليات داخل لينكس تكون معزولة لكل مستخدم على حدى، وتستخدم قاعدة بيانات MySQL نفس طريقة العزل. كل تطبيق يستخدم MySQL يجب أن يمتلك مستخدم خاص به ولديه صلاحيات محدودة ويستطيع الوصول إلى قواعد البيانات التي يحتاج لتشغيلها فقط. عندما نقوم بإعداد تطبيق جديد لاستخدام MySQL، يجب أن ننشئ قواعد البيانات التي يحتاجها هذا التطبيق: create database testDB; Query OK, 1 row affected (0.00 sec)بعد ذلك، يجب علينا إنشاء مستخدم لإدارة قاعدة البيانات، ومنحه الصلاحيات التي يحتاجها فقط، وهذه تختلف من تطبيق لآخر، وبعض الاستخدامات تحتاج لصلاحيات مفتوحة أكثر من غيرها. لإنشاء مستخدم جديد، استخدم الأمر التالي: CREATE USER 'demo-user'@'localhost' IDENTIFIED BY 'password';يمكننا منح المستخدم الجديد صلاحيات على الجدول الجديد بالأمر التالي. انظر الشرح التعليمي حول كيفية إنشاء مستخدم ومنح صلاحيات جديدة في MySQL لمعرفة المزيد عن الصلاحيات المحددة: GRANT SELECT,UPDATE,DELETE ON testDB.* TO 'demo-user'@'localhost';وكمثال على ذلك، إذا كنا بحاجة إلى وقت لاحق لإلغاء الصلاحيات من الحساب، يمكن أن نستخدم الأمر التالي: REVOKE UPDATE ON testDB.* FROM 'demo-user'@'localhost';إذا كنا بحاجة إلى كافة الصلاحيات على قاعدة بيانات معينة، يمكننا تحديد ذلك بما يلي: GRANT ALL ON testDB.* TO 'demo-user'@'localhost';لإظهار الصلاحيات الحالية للمستخدم، علينا أولا أن ننفذ الصلاحيات حددناه باستخدام أمر "flush privileges"، ثم بعد ذلك يمكننا الاستعلام عن الصلاحيات التي بحوزة المستخدم. FLUSH PRIVILEGES; show grants for 'demo-user'@'localhost'; Grants for demo-user@localhost GRANT USAGE ON *.* TO 'demo-user'@'localhost' IDENTIFIED BY PASSWORD '*2470C0C06DEE42FD1618BB99005ADCA2EC9D1E19' GRANT SELECT, UPDATE, DELETE ON `testDB`.* TO 'demo-user'@'localhost' 2 rows in set (0.00 sec)دائما امسح الصلاحيات عندما تنتهي من إجراء التغييرات. تغيير المستخدم الجذرخطوة إضافية واحدة وهي، ربما تريد تغيير اسم الجذر(root login name )، فإذا كان الهاكر يحاول أن يقوم بتسجيل الدخول باسم الروت في MySQL ، فسوف يحتاج إلى تنفيذ خطوة إضافية هي العثور على اسم المستخدم. تستطيع تغيير اسم المستخدم روت باستخدام الأمر التالي: rename user 'root'@'localhost' to 'newAdminUser'@'localhost';يمكننا أن نرى التغيير باستخدام نفس الاستعلام الذي استخدمناه لقاعدة بيانات المستخدم: select user,host,password from mysql.user;مرة أخرى، يجب علينا مسح الصلاحيات التغيرات التي حدثت: FLUSH PRIVILEGES;تذكر أنه سوف تسجل دخول إلى MySQL مثل اسم مستخدم تم إنشاؤه حديثا عندما ترغب في أداء المهام الإدارية: mysql -u newAdminUser -pبأي حال من الأحوال هذه قائمة شاملة من الاجراءات الأمنية لقواعد البيانات MySQL, MariaDB، وقد أصبح لديك مقدمة جيدة لأنواع القرارات التي ستتخذها عندما تريد تأمين قواعد البيانات الخاصة بك. يمكن الاطلاع على مزيد من المعلومات حول الإعدادت والأمن في قواعد بيانات المواقع MySQL وMariaDB إضافة الى صفحات المختصين، ويمكن للتطبيقات التي اخترت استخدامها أن تقدم المشورة الأمنية. ترجمة -وبتصرّف- للمقال: How To Secure MySQL and MariaDB Databases in a Linux VPS.