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

MongoDB عبارة عن قاعدة بيانات NoSQL مستندات مجانية ومفتوحة المصدر تُستخدم غالبا في تطبيقات الويب الحديثة. في هذا المقال سنُثبِّت MongnDB، ونُدير خدماتها، ونحميها، ونُفعل الوصول البعيد لها. المتطلبات تحتاج لتطبيق هذا الدرس إلى خادم أوبونتو مُعَد باتباع مقال الإعداد الأولي، ويحتوي على مستخدم sudo غير مسؤول وجدار حماية. الجزء الأول: تثبيت MongoDB خطوة 1 - تثبيت MongoDB حزمة مخزن أوبونتو الرسمي يحتوي على نسخة مُحدثه من MongoDB، ما يعني أنه بإمكاننا تثبيت حزماتِه المهمة باستخدام apt. بداية حدِّث قائمة الحُزم كي تحصل على أحدث الاصدارات: $ sudo apt update الآن ثبّت حزمة MongoDB: $ sudo apt install -y mongodb يُثبّت هذا الأمر عدة حُزم تحتوي على أحدث إصدار من MongoDB بالاضافة إلى أدوات إدارة مساعدة لخادم MongoDB. يبدأ خادم قاعدة البيانات بالعمل تلقائيا بعد التثبيت. تاليًا، نتحقق ما إن كان الخادم بعمل بصورة صحيحة. خطوة 2 - التحقق من الخدمة وقاعدة البيانات قامت عملية تثبيت MongoDB بتشغيله تلقائيا، لكن لنتأكد من بدء الخدمة ومن صحة عمل قاعدة البيانات. أولا تحقق من حالة الخدمة: $ sudo systemctl status mongodb سترى هذه المخرجات: ● mongodb.service - An object/document-oriented database Loaded: loaded (/lib/systemd/system/mongodb.service; enabled; vendor preset: enabled) Active: active (running) since Sat 2018-05-26 07:48:04 UTC; 2min 17s ago Docs: man:mongod(1) Main PID: 2312 (mongod) Tasks: 23 (limit: 1153) CGroup: /system.slice/mongodb.service └─2312 /usr/bin/mongod --unixSocketPrefix=/run/mongodb --config /etc/mongodb.conf يصرِّح systemd أنَّ خادم MongoDB يعمل. يمكننا التحقق أكثر عن طريق الاتصال بخادم قاعدة البيانات وتنفيذ أمر للفحص .نفّذ الأمر التالي: $ mongo --eval 'db.runCommand({ connectionStatus: 1 })' المخرجات: MongoDB shell version v3.6.3 connecting to: mongodb://127.0.0.1:27017 MongoDB server version: 3.6.3 { "authInfo" : { "authenticatedUsers" : [ ], "authenticatedUserRoles" : [ ] }, "ok" : 1 } القيمة 1 للحقل ok تعني أن الخادم يعمل بطريقة صحيحة. بعد ذلك، سنتطرق إلى كيفية إدارة حالة الخادم. خطوة 3 - إدارة خدمة MongoDB تُثبت MongoDB كخدمة ضمن النظام، ما يعني أنه يُمكنك إدارتها باستخدام أوامر systemd القياسية مثل باقي خدمات النظام على أوبونتو. لتتأكد من حالة الخدمة نفذ الأمر: $ sudo systemctl status mongodb يمكنك إيقاف الخادم في أي وقت من خلال الأمر: $ sudo systemctl stop mongodb لبدء الخادم عندما يكون متوقفًا عن العمل: $ sudo systemctl start mongodb يمكن إعادة تشغيل الخادم باستخدام أمر واحد: $ sudo systemctl restart mongodb MongoDB مُعد لِلبدء تلقائيا مع بدء الخادم، لإيقاف البدء التلقائي: $ sudo systemctl disable mongodb لتفعيل الميزة مجددا: $ sudo systemctl enable mongodb تاليًا، إعداد جدار الحماية لعملية تثبيت MongoDB. خطوة 4 - إعداد جار الحماية (اختياري) بافتراض أنك اتبعت مقال الإعداد الأولي لخادم أوبونتو لِتفعيل جدار الحماية، فإن خادم MongoDB لا يمكن أن يُوصل من خلال الإنترنت. في حال كنت تنوي استخدام خادم MongoDB محليا مع التطبيقات على نفس الخادم فقط فهذا الإعداد هو الأمثل. لكن إن كنت تريد أن تتصل بخادم قاعدة بيانات MongoDB من خلال الانترنت فيجب أن تسمح للاتصالات الخارجية في ufw. للسماح بالوصول من أي مكان إلى MongoDB على المنفذ الافتراضي 27017 يمكنك استخدام sudo ufw allow 27017. لكن تفعيل وصول الإنترنت إلى خادم MongoDB في التثبيت الافتراضي يعطي دخول غير محدود بضوابط لِخادم قاعدة البيانات وبياناته. في معظم الحالات يجب الوصول إلى MongoDB من أماكن موثوقة معينة فقط، مثل خادم آخر يستضيف تطبيقا مًا. للقيام بذلك، يمكنك السماح بالوصول إلى منفذ MongoDB الافتراضي مع تحديد عنوان بروتوكول الإنترنت للخادم الآخر الذي سيتمكن من الوصول إلى خادم MongoDB مباشرة: $ sudo ufw allow from your_other_server_ip/32 to any port 27017 يمكنك التحقق من التغييرات في جدار الحماية باستخدام ufw: $ sudo ufw status يجب أن ترى أن حركة المرور للمنفذ 27017 متاحة في المخرجات "output": Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere 27017 ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6) 27017 (v6) ALLOW Anywhere (v6) إن كنت قد قمت بتحديد عنوان بروتوكول إنترنت معين للاتصال بخادم MongoDB، فستراه بدلا من كلمة Anywhere في المخرجات. للمزيد من إعدادات جدار الحماية المتقدمة لحد الوصول إلى خدمات UFW الأساسية: قواعد وأوامر جدار الحماية الشائعة. على الرغم من أنَّ المنفذ مفتوح، إلا أن MongoDB يسمع فقط للعنوان المحلي 127.0.0.1. للسماح بالوصول من بعد، أضف عنوان بروتوكول الخادم العام و القابل للتوجيه إلى ملف mongod.conf. افتح ملف ضبط MongoDB: $ sudo nano /etc/mongodb.conf أضف عنوان بروتوكول الانترنت الخاص بالخادم إلى قيمة bindIP: ... logappend=true bind_ip = 127.0.0.1,your_server_ip #port = 27017 ... لا تنسَ وضع فاصلة بين عناوين بروتوكول الإنترنت الموجودة والعنوان الذي أضفته الآن. احفظ الملف واغلقه، ثم أعد تشغيل MongoDB: $ sudo systemctl restart mongodb الجزء الثاني: تأمين MongoDB كانت الاصدارات السابقة ل MongoDB مُعرَّضة للاختراق لأنَّها لا تتطلب أي مصادقة للتفاعل مع قاعدة البيانات. يمكن لأي مستخدم إنشاء وحذف قواعد بيانات وقراءة محتواها والكتابة فيها تلقائيا. أعدَّت أيضا هذه الاصدارات برنامج MongoDB خفي يسمع لجميع الواجهات تلقائيًا، مما يعني أن السكربتات التلقائية يمكن أن تكتشف حالات MongoDB الغير محمية بجدار حماية، وإن لم تكُن المصادقة مفعلة، يمكن لهذه السكربتات الحصول على وصول كامل إلى MongoDB. خُفِّفَت الحالة في الاصدار ‎3.x وبعض الاصدارات السابقة المُقدَّمة من بعض مديري الحُزم لأن البرنامج الخفي أصبح الآن مرتبط ب 127.0.0.1، لذلك سيقبل الاتصالات على حزمة يونكس فقط. أي أنه أصبح غير مفتوحًا للإنترنت. لأن المصادقة ما زالت مُعَطَّلة افتراضيا، فإن لدى أي مستخدم على النظام المحلي وصول كامل لقاعدة البيانات. سنُنشِئ مستخدمًا مسؤولًا لتأمين ذلك، ونُفَعِّل المصادقة ونتحقق من ذلك. خطوة 1 - إضافة مستخدم مسؤول سنتَّصِل بسطر أوامر Mongo لإضافة مستخدم: $ mongo تُحذِّر المُخرجات عندما نستخدم سطر أوامر Mongo من أن التحكم بالوصول معطل لقاعدة البيانات وأن وصول القراءة والكتابة للبيانات والإعدادت غير مقيدة. مخرجات تنفيذ الأمرالسابق هي: MongoDB shell version v3.4.2 connecting to: mongodb://127.0.0.1:27017 MongoDB server version: 3.4.2 Welcome to the MongoDB shell. For interactive help, type "help". For more comprehensive documentation, see http://docs.mongodb.org/ Questions? Try the support group http://groups.google.com/group/mongodb-user Server has startup warnings: 2017-02-21T19:10:42.446+0000 I STORAGE [initandlisten] 2017-02-21T19:10:42.446+0000 I STORAGE [initandlisten] ** WARNING: Using the XFS filesystem is strongly recommended with the WiredTiger storage engine 2017-02-21T19:10:42.446+0000 I STORAGE [initandlisten] ** See http://dochub.mongodb.org/core/prodnotes-filesystem 2017-02-21T19:10:42.534+0000 I CONTROL [initandlisten] 2017-02-21T19:10:42.534+0000 I CONTROL [initandlisten] ** WARNING: Access control is not enabled for the database. 2017-02-21T19:10:42.534+0000 I CONTROL [initandlisten] ** Read and write access to data and configuration is unrestricted. 2017-02-21T19:10:42.534+0000 I CONTROL [initandlisten] > يمكنك اختيار الاسم الذي تريده للمستخدم المسؤول لأنَّ الصلاحيات تأتي من إعطاء الدور userAdminAnyDatabase. تُحدد قاعدة البيانات admin أين تُخَزَّن بيانات الاعتماد. يمكنك الاطلاع أكثر عن المصادقة في جزء مصادقة أمنية MongoDB. حدد اسم مستخدم وتأكد من اختيار كلمة مرور آمنة واستبدِلهما في الأمر التالي: > use admin > db.createUser( > { > user: "AdminSammy", > pwd: "AdminSammy'sSecurePassword", > roles: [ { role: "userAdminAnyDatabase", db: "admin" } ] > } > ) عند بدء أمر db.createUser، فإن سطر الأوامر سيضع ثلاث نقاط قبل كل سطر حتى انتهاء الأمر. بعد ذلك، يظهر رد بأن المستخدم قد أُنشِئ كالتالي: المخرجات: > use admin switched to db admin > db.createUser( ... { ... user: "AdminSammy", ... pwd: "AdminSammy'sSecurePassword", ... roles: [ { role: "userAdminAnyDatabase", db: "admin" } ] ... } ... ) Successfully added user: { "user" : "AdminSammy", "roles" : [ { "role" : "userAdminAnyDatabase", "db" : "admin" } ] } اكتب "exit" ثم اضغط على ENTER أو اضغط على CTRL+C للخروج. سَيُتاح الآن للمستخدم إدخال بيانات الاعتماد، لكن لن يُطلَب هذا من المستخدام حتى تفعيل المصادقة وإعادة تشغيل برنامج MongoDB الخفي. خطوة 2 - تفعيل المصادقة المصادقة مفعلة في ملف mongod.conf. عند تفعيلها وإعادة تشغيل mongod، سيظل المستخدمون قادرون على الاتصال ب Mongo بدون مصادقة، لكن سيُطلَب منهم اسم مستخدم وكلمة مرور قبل أي تفاعل. لنفتح ملف الإعداد: $ sudo nano /etc/mongod.conf في الجزء ‎#security، ستُزيل التعليق من أمام security لتفعيل المقطع. ثم سنُضيف إعداد المصادقة. يجب أن تبدو الأسطر كما في الأسفل بعد إلغاء تعليقها: الملف mongodb.conf: . . . security: authorization: "enabled" . . . لاحظ أنَّ سطر "Security" لا يحوي مسافة في بدايته، بينما سطر "authorization" يجب أن يبدأ بِمسافتين. نُعيد تشغيل البرنامج الخفي بعد حفظ الملف وإغلاقه: $ sudo systemctl restart mongod إن أخطأنا في ملف الإعداد فلن يبدأ البرنامج الخفي بالعمل. ولأن systemctl لا تعرض أي مخرجات فَسنستخدم خيار status للتحقق من ذلك: $ sudo systemctl status mongod إن ظهر Active: active (running)‎ في المخرجات وانتهى بشيء كما يلي، فإن أمر restart قد نُفِّذ بنجاح: المخرجات: Jan 23 19:15:42 MongoHost systemd[1]: Started High-performance, schema-free document-oriented database. بعد التأكد من أن البرنامج الخفي يعمل، لنُجَرِّب المصادقة. خطوة 3 - التحقق من منع المستخدمين غير المخولين أولا، نحاول الاتصال بدون معلومات اعتماد للتحقق من أن الدخول ممنوع: $ mongo تم حل جميع التحذيرات بعد تفعيل المصادقة. المخرجات: MongoDB shell version v3.4.2 connecting to: mongodb://127.0.0.1:27017 MongoDB server version: 3.4.2 اتصلنا بقاعدة بيانات test. سَنتأكد من أن الوصول ممنوع باستخدام الأمر show dbs: > show dbs المخرجات: 2017-02-21T19:20:42.919+0000 E QUERY [thread1] Error: listDatabases failed:{ "ok" : 0, "errmsg" : "not authorized on admin to execute command { listDatabases: 1.0 }", "code" : 13, "codeName" : "Unauthorized" . . . لن نتمكن من إنشاء مستخدمين أو تنفيذ أوامر بصلاحيات مشابهة بدون مصادقة. نُغلِق سطر الأوامر للمتابعة: > exit ثانيًا، نتحقق من أن المستخدم المسؤول الذي أنشأناه يمكنه الوصول. خطوة 4 - التحقق من إمكانية وصول المستخدم المسؤول سَنَتَّصِل باستخدام المستخدم المسؤول الذي أنشأناه باستخدام الخيار ‎-u لتزويد اسم المستخدم والخيار ‎-p ليطلب كلمة مرور. سنحتاج أيضا إلى تزويد اسم قاعدة البيانات التي خُزِّنَت فيها بيانات اعتماد المستخدم باستخدام الخيار ‎--authenticationDatabase. $ mongo -u AdminSammy -p --authenticationDatabase admin سيُطلب منَّا كلمة المرور، لذلك ندخلها. سننتقل إلى سطر الأوامر عند ادخال كلمة المرور الصحيحة حيث يمكننا تنفيذ الأمر show dbs: المخرجات MongoDB shell version v3.4.2 Enter password: connecting to: mongodb://127.0.0.1:27017 MongoDB server version: 3.4.2 > يجب أن نرى قاعدة البيانات بدلًا من رفض الوصول: > show dbs المخرجات: admin 0.000GB local 0.000GB للخروج، أدخل exit أو اضغط CTRL+C. خاتمة ثبَّتنا الآن MongoDB وإجرينا عمليات التهيئة والحماية المطلوبة وتحققنا من عملها. يمكنك الآن بدء استعمالها وأنت مطمئن القلب ومرتاح البال. يمكنك العثور على المزيد من الدروس المتعمقة في كيفية إعداد واستخدام MongoDB في هذه المقالات من أكاديمية حسوب. يُعد التوثيق الرسمي ل MongoDB أيضا مصدر ممتاز للخيارات التي يقدمها MongoDB. كما يمكنك الاطلاع على توثيق MongoDB لتتعلم أكثر عن المصادقة، والتحكم بالوصول وفقا للدور، والمستخدمون والأدوار. ترجمة -وبتصرف- للمقال How to Install MongoDB on Ubuntu 18.04 لصاحبه الكاتب Mateusz Papiernik.

بالرّغم من أنّ الاتصال إلى الخادوم عبر SSH آمن جدًّا، فإنّ SSH daemon (وهو عمليّة تعمل في خلفيّة النّظام بشكل دائم) بحدّ ذاتها هي خدمة يجب تعريضها إلى الإنترنت لتعمل بشكل صحيح، ويأتي هذا مع بعض المخاطر الكامنة ويخلق ناقلات للهجوم لأي مهاجمين مُحتَملين. إنّ أي خدمة مُعرّضة إلى الشّبكة هي هدف مُحتمل بهذه الطريقة، فإذا ألقينا انتباهنا إلى سجلّات التطبيق لهذه الخدمات سنجد محاولات مُنظّمة ومتكرّرة لتسجيل الدخول والتي تُمثّل هجمات بالقوّة القاسية Brute force attacks عن طريق مستخدمين أو روبوتات bots على حدٍّ سواء. يُمكن الحد من هذه المشكلة عن طريق خدمة تُدعى fail2ban والتي تقوم بإنشاء قواعد تستطيع تبديل إعدادات جدار حماية iptables بناءً على عدد معرّف مُسبقًا من محاولات تسجيل الدخول غير النّاجحة، يسمح هذا لخادومنا بالاستجابة لمحاولات النّفاذ غير الشّرعية من دون أي تدخّل منّا. سنغطّي في هذا الدّرس كيفيّة تثبيت واستخدام fail2ban على خادوم Ubuntu. تثبيت Fail2Ban على Ubuntuإنّ عمليّة التثبيت لهذه الأداة بسيطة لأنّ فريق تحزيم Ubuntu يُحافِظ على الحِزمة Package في المستودعات الافتراضيّة default repositories. نحتاج في البداية لتحديث دليل الحِزَم المحلّي local package index لدينا، وبعدها نستطيع استخدام apt لتنزيل وتثبيت الحِزمة: sudo apt-get update sudo apt-get install fail2banإنّ عملية التثبيت بديهيّة كما نرى، نستطيع الآن البدء بإعداد الأداة لاستخدامنا الشّخصي. إعداد Fail2Ban مع إعدادات الخدمة الخاصة بناتحتفظ خدمة fail2ban بملفّات إعداداتها في الدّليل etc/fail2ban/، يوجد ملف مع إعدادات افتراضيّة يُدعى jail.conf. ولأنّه يُمكن أن يتم تعديل هذا الملف عن طريق ترقية الحِزَم لذلك لا ينبغي علينا تحرير هذا الملف في مكانه، بل من الأفضل أن نقوم بنسخه حتى نستطيع القيام بتغييراتنا بأمان. نحتاج لنسخه إلى ملف يُدعى jail.local حتى يستطيع fail2ban إيجاده: sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.localحالما يتم نسخ الملف بإمكاننا فتحه للتحرير لنرى كيف يعمل كل شيء: sudo nano /etc/fail2ban/jail.localيوجد في هذا الملف القليل من الإعدادات التي قد نرغب بضبطها، يتم تطبيق هذه الإعدادات الموجودة تحت قسم [DEFAULT] على جميع الخدمات المُمَكَّنة enabled من أجل fail2ban الذي لا يتم تجاوزه في القسم الخاص بالخدمة: ignoreip = 127.0.0.1/8نستطيع ضبط مصدر العناوين التي يتجاهلها fail2ban عن طريق إضافة قيمة إلى المُعامِل parameter ignoreip. يتم ضبطه افتراضيًّا بأن لا يقوم بمنع أي نقل للبيانات traffic قادم من الجهاز المحلّي، نستطيع إضافة المزيد من العناوين التي نريد تجاهلها عن طريق إلحاقها بنهاية هذا المُعامِل مع الفصل بينها بفراغ Space. bantime = 600يقوم المُعامِل bantime بتعيين المُدّة الزمنيّة التي سيتم خلالها حظر العميل عندما يفشل بالاستيثاق authenticate بشكلٍ صحيح، يتم قياس هذا المُعامِل بالثّواني، وقيمته الافتراضيّة هي 600 ثانية أي 10 دقائق. findtime = 600 maxretry = 3ومن المُعامِلات التي نرغب أن نلقي لها انتباهًا نجد المُعامِلَين findtime و maxretry، وهما يعملان معًا لتأسيس الشّروط التي نستطيع بناءً عليها اعتبار عميل ما مستخدمًا غير قانونيٍ يجب علينا حظره. يقوم المُتغيّر maxretry بتعيين عدد المحاولات التي يجب خلالها أن يقوم العميل بالاستيثاق خلال فترة زمنيّة مُعرّفة بـ findtime وذلك قبل أن يتمّ حظره، تقوم الإعدادات الافتراضيّة لخدمة fail2ban بحظر العميل الذي يقوم بثلاث محاولات غير ناجحة لتسجيل الدخول خلال فترة 10 دقائق. destemail = root@localhost sendername = Fail2Ban mta = sendmailومن بعض الإعدادات الأخرى التي قد نرغب بتعديلها نجد الإعدادات destemail، sendername، و mta إن أردنا ضبط تنبيهات alerts البريد الإلكتروني، يقوم المُعامِل destemail بتعيين عنوان البريد الإلكتروني الذي سيستقبل رسائل الحظر، يقوم المُعامِل sendername بتعيين قيمة الحقل From في البريد الإلكتروني، يُحدّد المُعامِل mta خدمة البريد الإلكتروني التي سيتم استخدامها لإرسال البريد. action = $(action_)sيضبط هذا المُعامل الإجراءات التي يتّخذها fail2ban عندما يريد إقامة حظر، إنّ القيمة _action مُعرَّفة في الملف قبل هذا المُعامِل بقليل، الإجراء الافتراضي هو ببساطة أن يتم ضبط الجّدار النّاري firewall لكي يرفض نقل البيانات من المُضيف Host المُهاجِم حتى تنتهي مُدّة الحظر. إن أردنا ضبط تنبيهات البريد الإلكتروني نستطيع تغيير القيمة من _action إلى action_mw، وإن كُنّا نرغب أن يقوم البريد الإلكتروني بتضمين سطور السّجلات المُتعلّقة بذلك نستطيع تغييرها إلى action_mwl، يجب أن نتأكّد من أنّه يتم ضبط إعدادات البريد المُناسبة إن اخترنا استخدام تنبيهات البريد. 1. إعدادات Jail الفرديةلقد وصلنا أخيرًا إلى الجزء من ملف الإعدادات الذي يتعامل مع الخدمات الفرديّة، والتي يتم تحديدها في القسم headers مثل [SSH]. نستطيع تمكين كل واحد من هذه الأقسام عن طريق تعديل أو إضافة السّطر enabled وتعيينه إلى true: enabled = trueنجد بشكل افتراضي أنّ خدمة SSH مُمكّنة وباقي الخدمات مُعطّلة. تعمل هذه الأقسام عن طريق استخدام القيم الافتراضيّة التي عرّفناها مُسبقًا، وإن أردنا تجاوز override أي قيم نستطيع فعل ذلك في قسم الخدمات، أمّا إن أردنا استخدام القيم الافتراضيّة فلا داعي لإضافة أي شيء. ومن الإعدادات الأخرى التي يُمكن تعيينها هنا هي filter والذي يستخدم ليحدّد إذا ما كان السطر في ملف السّجل يشير إلى استيثاق فاشل، وlogpath الذي يُخبِر fail2ban أين توجد السّجلات لتلك الخدمة بالتحديد. إنّ قيمة filter هي في الواقع إشارة reference إلى ملف يتوضّع في الدّليل etc/fail2ban/filter.d/ مع إزالة لاحقته conf.، يحتوي هذا الملف على التّعابير النمطيّة regular expressions التي تُحدّد إذا ما كان السّطر في ملف السّجل سيّئًا، لن نقوم بالتّحدث بالتفصيل عن هذا الملف في هذا الدّرس، لأنّه مُعقّد إلى حدٍ ما، والإعدادات المُعرّفة مُسبقًا تتوافق مع السطور المُلائمة لها بشكل جيّد. بإمكاننا على أيّة حال أن نرى أنواع المُرشّحات filters المتوفرة من خلال النّظر إلى هذا الدّليل: ls /etc/fail2ban/filter.dعندما نجد ملفًّا مرتبطًا بالخدمة التي نستخدمها ينبغي أن نفتحه باستخدام مُحرّر نصوص. مُعظم هذه الملفّات تحتوي على تعليقات للشرح بشكل جيّد ويجب أن نكون قادرين على الأقل أن نعرف ما هو نوع الشّروط التي تم تصميم الـ script من أجل الحماية ضدّها، تملك أغلب هذه المُرشّحات أقسام (مُعطّلة) مناسبة في ملف jail.local والتي نستطيع تمكينها عند الرغبة بذلك. فلنفترض على سبيل المثال أنّنا نقوم بتخديم موقع باستخدام nginx وأدركنا أنّ قسم منه محمي بكلمة مرور يتعرّض لمحاولات تسجيل دخول، نستطيع إخبار fail2ban أن يستخدم الملف nginx-http-auth.conf لكي يفحص هذا الشّرط من خلال الملف var/log/nginx/error.log/. هذا الشّرط مُعَد مُسبقًا في الواقع ضمن قسم يُدعى [nginx-http-auth] في الملف etc/fail2ban/jail.local/، نحتاج فقط إلى قلب المُعامِل enabled إلى true لحماية الخدمة الخاصّة بنا: [nginx-http-auth] enabled = true filter = nginx-http-auth port = http,https logpath = /var/log/nginx/error.logإن قمنا بتفعيلها نحتاج إلى إعادة تشغيل خدمة fail2ban للتأكّد من أنّ قواعدنا مبنيّة بشكل صحيح. وضع كل ذلك معاالآن وقد فهمنا الفكرة الأساسيّة من وراء fail2ban، فلنقم بتشغيل إعداد أساسي. سنقوم بإعداد سياسة حظر تلقائي من أجل SSH وNginx تمامًا كما وصفنا سابقًا، نريد من fail2ban أن يقوم بإرسال بريد إلكتروني لنا عندما يتم حظر عنوان IP. فلنقم في البداية بتثبيت جميع البرمجيّات المتعلقّة بذلك. إن كُنّا لا نملك nginx يجب علينا تثبيته، لأنّنا سنقوم بمراقبة سجلّاته، سنحتاج أيضًا sendmail لكي يرسل التّنبيهات إلينا، سنقوم بتثبيت iptables-persistent لكي يسمح للخادوم بإعداد قواعد الجّدار النّاري تلقائيًّا عند الإقلاع boot، نستطيع الحصول على كل هذا من مستودعات Ubuntu الافتراضيّة: sudo apt-get update sudo apt-get install nginx sendmail iptables-persistent 1. إنشاء جدار ناري أساسيينبغي علينا بعد الانتهاء من كل هذا إنشاء جدار ناري افتراضي، تستطيع تعلّم كيفيّة إعداد iptables للجدار الناري على Ubuntu من هنا، سنقوم في هذا الدّرس فقط بإنشاء جدار ناري أساسي. سنخبر الجّدار النّاري بالسّماح للاتصالات التي تمّ تأسيسها، نقل البيانات traffic الذي يتم توليده من قبل الخادوم نفسه، مقدار نقل البيانات من أجل SSH لدينا، ومنافذ ports خادوم الوِب، وسنقوم باستبعاد أي نقل بيانات آخر، نستطيع إعداد هذا الجّدار النّاري الأساسي عن طريق كتابة: sudo iptables -A INPUT -i lo -j ACCEPT sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT sudo iptables -A INPUT -j DROPستقوم هذه الأوامر بتنفيذ السّياسة السّابقة، وبإمكاننا رؤية قواعد الجّدار النّاري الحاليّة عن طريق كتابة: sudo iptables -S -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT -N fail2ban-ssh -A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh -A INPUT -i lo -j ACCEPT -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT -A INPUT -j DROP -A fail2ban-ssh -j RETURN حصلنا هنا على سياستنا الافتراضيّة لكل واحدة من السلاسل لدينا، ومن ثمّ القواعد الخمس التي أنشأناها للتو، إنّ الأسطر التي تحتوي على: -N fail2ban-ssh و -A INPUT -p tcp -m multiport --dports 22 -j fail2ban-sshو -A fail2ban-ssh -j RETURN هي عبارة عن البُنية الافتراضيّة المُعدّة من قبل fail2ban حيث أنّه يقوم مُسبقًا بتنفيذ سياسات حظر SSH بشكل افتراضي. 2. ضبط إعدادات Fail2banنحتاج الآن لضبط إعدادات fail2ban باختيار الإعدادات التي نرغب بها، فلنقم بفتح الملف jail.local: sudo nano /etc/fail2ban/jail.localنستطيع هنا تعيين زمن للحظر أشد طولًا، فلنقم بتغيير الإعداد bantime الموجود تحت الترويسة الافتراضيّة بحيث تقوم خدمتنا بحظر العملاء لمدة نصف ساعة: bantime = 1800نحتاج أيضًا لضبط معلومات تنبيهات البريد الإلكتروني، نقوم في البداية بإيجاد المُعامِل destemail ونضع بداخله عنوان البريد الإلكتروني الذي نرغب باستخدامه لجمع هذه الرسائل: destemail = admin@example.comنستطيع تعيين sendername إلى قيمة أخرى إن أردنا ذلك، على الرغم من أنّه من المفيد أن يكون لها قيمة يُمكن تصفيتها بسهولة باستخدام خدمة البريد الإلكتروني الخاصّة بنا، وإلّا امتلأ صندوق الوارد بالتنبيهات إن كانت هناك الكثير من محاولات الاختراق من أماكن متعدّدة. بالانتقال للأسفل نحتاج لضبط المُعامِل action إلى أحد الإجراءات التي ترسل لنا بريد إلكتروني، الخيارات محصورة بين action_mw والذي يُنشِئ الحظر ومن ثمّ يرسل لنا بريدًا إلكترونيًّا يحتوي على تقرير whois حول المُضيف المخالف، أو action_mwl والذي يقوم بما سبق ولكن يرسل لنا أيضًا سطور السجل المتعلّقة بذلك. سوف نختار action_mwl لأنّ سطور السّجلات ستساعدنا على استكشاف الأخطاء وجمع المزيد من المعلومات إن كانت توجد مشاكل: action = %(action_mwl)sوبالانتقال إلى قسم SSH لدينا، إن أردنا ضبط عدد المحاولات غير الناجحة التي ينبغي أن نسمح بها قبل إنشاء حظر نستطيع تعديل الإدخال maxretry، وإن كُنّا نستخدم منفذ غير 22 سنحتاج لضبط المُعامِل port بشكلٍ مُناسِب، وكما قلنا سابقًا فإنّ هذه الخدمة مُمكّنة مُسبقًا لذلك لا حاجة لتعديل ذلك. فلنبحث بعد ذلك عن القسم nginx-http-auth ونُغيّر المُعامِل enabled ليصبح true: [nginx-http-auth] enabled = true . . .هذا هو كل ما ينبغي علينا فعله في هذا القسم ما لم يكن يعمل خادوم الوِب لدينا على منافذ غير معياريّة أو قمنا بنقل المسار الافتراضي لسجلّات الأخطاء. 3. إعادة تشغيل خدمة Fail2banبعد الانتهاء مما سبق نقوم بحفظ وإغلاق الملف. نقوم الآن ببدء تشغيل أو إعادة تشغيل خدمة fail2ban، من الأفضل أحيانًا إيقاف تشغيل الخدمة بشكلٍ تام ومن ثم تشغيلها مرة أخرى: sudo service fail2ban stopنستطيع الآن إعادة تشغيلها بكتابة ما يلي: sudo service fail2ban startقد تستغرق بضع لحظات لكي يتم ملء جميع قواعد الجّدار النّاري لدينا، على أيّة حال نستطيع بعد ذلك التأكّد من القواعد الجديدة بكتابة: sudo iptables -S -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT -N fail2ban-nginx-http-auth -N fail2ban-ssh -A INPUT -p tcp -m multiport --dports 80,443 -j fail2ban-nginx-http-auth -A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh -A INPUT -i lo -j ACCEPT -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT -A INPUT -j DROP -A fail2ban-nginx-http-auth -j RETURN -A fail2ban-ssh -j RETURNإن الأسطر التي قامت بإنشائها سياسات fail2ban لدينا هي: -N fail2ban-nginx-http-auth -N fail2ban-ssh -A INPUT -p tcp -m multiport --dports 80,443 -j fail2ban-nginx-http-auth -A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh -A fail2ban-nginx-http-auth -j RETURN -A fail2ban-ssh -j RETURN تقوم هذه الأسطر الآن بتوجيه نقل البيانات إلى سلاسل جديدة وفارغة تقريبًا ومن ثمّ تسمح لنقل البيانات بالتدفق والعودة إلى سلسلة الدّخل INPUT. على أيّة حال هذه السلاسل الجديدة هي حيث يتم إضافة قواعد الحظر الجّديدة. 4. اختبار سياسات الحظرنستطيع اختبار القواعد من خادوم آخر -خادوم لا نحتاج له للدخول إلى خادوم fail2ban- عن طريق جعل هذا الخادوم الثاني ينحظر. بعد الدخول إلى الخادوم الثاني نقوم بمحاولة الدخول عن طريق SSH إلى خادوم fail2ban، نستطيع على سبيل المثال محاولة الاتصال باستخدام اسم غير موجود: ssh blah@fail2ban_server_IPفلنقم بإدخال أحرف عشوائيّة في النّافذة التي تطلب منّا كلمة مرور، ومن ثمّ نعيد هذه الخطوة عدّة مرات، سيقوم خادوم fail2ban في نقطة ما بإيقاف الاستجابة مع رسالة تم رفض الإذن Permission denied، وهذا يشير إلى أنه تم حظر الخادوم الثاني من قبل خادوم fail2ban. نستطيع على خادوم fail2ban مشاهدة القواعد الجديدة عن طريق التّحقق مرة أخرى من iptables لدينا: sudo iptables -S -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT -N fail2ban-nginx-http-auth -N fail2ban-ssh -A INPUT -p tcp -m multiport --dports 80,443 -j fail2ban-nginx-http-auth -A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh -A INPUT -i lo -j ACCEPT -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -p tcp -m tcp --dport 22 -j ACCEPT -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT -A INPUT -j DROP -A fail2ban-nginx-http-auth -j RETURN -A fail2ban-ssh -s 11.111.111.11/32 -j REJECT --reject-with icmp-port-unreachable -A fail2ban-ssh -j RETURNوكما نرى في السّطر: -A fail2ban-ssh -s 11.111.111.11/32 -j REJECT --reject-with icmp-port-unreachableنملك الآن قاعدة جديدة في إعداداتنا ترفض نقل البيانات القادمة من عنوان IP خادومنا الثاني عبر منفذ SSH، ينبغي أيضًا أن نكون قد حصلنا على بريد إلكتروني حول هذا الحظر في الحساب الذي قمنا بإعداده. خاتمةينبغي أن نكون قادرين الآن على إعداد بعض سياسات الحظر الأساسيّة لخدماتنا، من السّهل جدًّا إعداد Fail2ban وهو طريقة رائعة لحماية أي نوع من الخدمات تستخدم الاستيثاق. إن أردت تعلّم المزيد حول كيفيّة عمل fail2ban بإمكانك تفحّص هذا الدّرس التعليمي حول كيفيّة عمل قواعد وملفّات fail2ban. ترجمة -وبتصرّف- للمقال How To Protect SSH with Fail2Ban on Ubuntu 14.04 لصاحبه Justin Ellingwood. حقوق الصورة البارزة: Designed by Freepik.