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

إن UFW، أو Uncomplicated Firewall (الجدار الناري غير المعقَّد)، هو واجهة للجدار الناري iptables الذي يجنح لتبسيط عملية ضبط جدار ناري؛ وعلى الرغم من أنَّ iptables هو أداةٌ قويةٌ ومرنة، لكن قد يكون من الصعب على المبتدئين أن يتعلموا استخدامه ليضبطوا جدارًا ناريًا ضبطًا سليمًا. إذا كنت تطمح إلى أن تبدأ بتأمين شبكتك، ولكنك لست متأكدًا من أيّ أداةٍ ستختار، فربما يكون UFW هو الخيار المناسب لك. سيريك هذا الدرس كيفية ضبط جدارٍ ناريٍ في أوبنتو 14.04 بوساطة UFW. المتطلبات المسبقةقبل أن تبدأ في تطبيق هذا الدرس، يجب أن تملك حسابَ مستخدمٍ ليس جذرًا لكنه يستطيع الحصول على امتيازات الجذر عبر الأمر sudo. يمكنك تعلم كيف يتم ذلك عبر تطبيق الخطوات من 1 إلى 3 على الأقل في درس الإعداد الابتدائي لخادوم أوبنتو 14.04. يكون UFW مُثبَّتًا افتراضيًا في أوبنتو؛ إذا ألغي تثبيته لسببٍ ما، فيمكنك إعادة تثبيته باستخدام الأمر: sudo apt-get install ufw استخدام IPv6 مع UFWإذا كان IPv6 مفعّلًا على خادومك، فتأكد أن UFW مضبوطٌ لدعم IPv6 كي تستطيع إدارة قواعد الجدار الناري الخاصة بعناوين IPv6 بالإضافة إلى IPv4؛ ولفعل ذلك، عدِّل ضبط UFW بمحررك النصي المفضّل؛ سنستخدم nano هنا: sudo nano /etc/default/ufw تأكد من أن قيمة «IPV6» مساويةٌ للقيمة «yes»؛ إذ يجب أن يبدو الملف كما يلي: /etc/default/ufw excerpt … IPV6=yes … احفظ واخرج، اضغط Ctrl-X للخروج من الملف، ثم Y لحفظ التعديلات التي أجريتها، ثم اضغط Enter لتأكيد اسم الملف. عندما يفعَّل UFW، فسيُضبَط لكتابة قواعد جدار ناري لعناوين IPv4 و IPv6. كُتِبَ هذا الدرس مع أخذ IPv4 بعين الاعتبار، لكنه قابل للتطبيق على IPv6 طالما كنت مفعِّلًا إياه. التحقق من حالة وقواعد UFWفي أي وقتٍ تريد، تستطيع التحقق من حالة UFW باستخدام هذا الأمر: sudo ufw status verbose افتراضيًا، يكون UFW معطّلًا لذلك سيظهر عندك شيءٌ شبيهٌ بما يلي: Status: inactive إذا كان UFW مفعّلًا، فسيخبرك الناتج ذلك، وسيُظهِر أيّة قواعد قد ضُبِطَت؛ على سبيل المثال، إذا ضُبِطَ الجدار الناري للسماح بالاتصالات من أيّ مكانٍ إلى SSH (المنفذ 22)، فسيكون الناتج شيئًا شبيهًا بما يلي: Status: active Logging: on (low) Default: deny (incoming), allow (outgoing), disabled (routed) New profiles: skip To Action From -- ------ ---- 22/tcp ALLOW IN Anywhereيمكنك استخدام الأمر status في أي وقتٍ إذا أردت أن تعرف كيف ضَبَطَ UFW الجدارَ الناري. قبل تفعيل UFW، ربما تريد أن تتأكد أن جدارك الناري مضبوطٌ للسماح لك بالاتصال عبر SSH. لنبدأ بضبط السياسات الافتراضية (default policies). ضبط السياسات الافتراضيةإذا كنت قد بدأت لتوِّك مع جدارك الناري، فإن أولى القواعد التي عليك تعريفها هي السياسات الافتراضية؛ تتحكم هذه القواعد بطريقة معالجة البيانات الشبكية التي لم تُطابَق بدقّة مع أيّة قواعد أخرى؛ افتراضيًا، UFW مضبوطٌ لمنع جميع الاتصالات الواردة والسماح لكل الاتصالات الصادرة. هذا يعني أن أي شخصٍ يحاول أن يصل إلى خادومك السحابي لن يستطيع الاتصال، بينما يستطيع أيُ تطبيقٍ على خادومك أن يصل إلى «العالم الخارجي». لنرجع الضبط الافتراضي لقواعد UFW لكي نتأكد أنك تستطيع الإكمال مع هذا الدرس؛ استخدم الأمرين الآتيين لإعادة ضبط القيم الافتراضية المُستخدَمة من UFW: sudo ufw default deny incoming sudo ufw default allow outgoing وكما توقّعتَ، يعيد الأمران السابقان ضبط UFW إلى القيم الافتراضية بمنع الاتصالات الواردة والسماح للاتصالات الصادرة؛ قد تكون هذه القيم الافتراضية كافيةً للحواسيب الشخصية لكن تحتاج الخواديم إلى الرد على الطلبيات (requests) القادمة من المستخدمين الخارجيين؛ سنلقي نظرةً على ذلك لاحقًا. السماح لاتصالات SSHإذا فعّلنا جدار UFW الآن، فسيحجب جميع الاتصالات الواردة؛ هذا يعني أننا سنحتاج إلى إنشاء قواعد تسمح (وبدقّة) للاتصالات الشرعيّة (مثل اتصالات SSH أو HTTP) إذا أردنا أن يجيب خادومنا إلى ذاك النوع من الطلبيات؛ إذا كنت تستخدم خادومًا سحابيًا، فربما تريد السماح لاتصالات SSH الواردة كي تستطيع الاتصال وإدارة خادومك عن بُعد. لضبط خادومك للسماح باتصالات SSH، فاستخدم أمر UFW الآتي: sudo ufw allow ssh ينُشِئ الأمر السابق قواعد جدار ناري تسمح لجميع الاتصالات على المنفذ 22، الذي هو المنفذ الذي يستمع إليه «عفريت» (daemon)‏‏ ‏SSH؛ يعلم UFW ما هو «ssh» (بالإضافة إلى عدد كبير من أسماء الخدمات الأخرى) ولذلك لأنه مذكورٌ كخدمةٍ تَستخدمُ المنفذ 22 في ملف ‎/etc/services. نستطيع كتابة قاعدة مكافئة للقاعدة السابقة بتحديد المنفذ بدلًا من اسم الخدمة؛ على سبيل المثال، سيعمل هذا الأمر عمل الأمر السابق تمامًا: sudo ufw allow 22 إذا ضبطتَ عفريت SSH ليستخدم منفذًا آخر، فربما عليك تحديد المنفذ الملائم؛ على سبيل المثال، إذا كان يستمع خادم SSH إلى المنفذ 2222، فيمكنك استخدام الأمر الآتي للسماح للاتصالات على ذاك المنفذ: sudo ufw allow 2222 الآن، وبعد أن ضبطتَ جدارك الناري للسماح لاتصالات SSH القادمة، فعلينا تفعيله. تفعيل UFWاستخدم الأمر الآتي لتفعيل UFW: sudo ufw enable سيظهر لك تحذيرٌ يقول: «قد يقطع هذا الأمر اتصالات SSH الموجودة»؛ لكننا قد ضبطنا مسبقًا قاعدةً تسمح لاتصالات SSH، لذلك لا بأس من الإكمال، أجب بكتابة y. قد فعَّلتَ الجدار الناري الآن، تستطيع تنفيذ الأمر: sudo ufw status verbose لمعرفة القواعد المضبوطة. السماح لبقية الاتصالاتعليك الآن السماح لبقية الاتصالات التي يجب على خادومك الإجابة عليها؛ الاتصالات التي ستَسمح لها تتعلق باحتياجاتك. ولحسن الحظ، لقد تعلمت كيف تكتب قواعدًا تسمح للاتصالات بناءً على اسم الخدمة أو المنفذ (حيث فعلنا ذلك لخدمة SSH على المنفذ 22)؛ سنريك عدّة أمثلة لخدماتٍ شائعةٍ جدًا ربما تريد أن تسمح لها في جدارك الناري. إذا كانت لديك أيّة خدمات أخرى تريد السماح لاتصالاتها الواردة، فاتّبِع تلك الصيغة. خدمة HTTP – المنفذ 80يمكن السماح لاتصالات HTTP التي تستخدمها خوادم الويب غير المشفَّرة (unencrypted) بالأمر الآتي: sudo ufw allow http أو إذا كنت تفضِّل استخدام رقم المنفذ (80)، فنفِّذ هذا الأمر: sudo ufw allow 80 خدمة HTTPS – المنفذ 443يمكن السماح لاتصالات HTTPS التي تستخدمها خوادم الويب المشفَّرة (encrypted) بالأمر الآتي: sudo ufw allow https أو إذا كنت تفضِّل استخدام رقم المنفذ (443)، فنفِّذ هذا الأمر: sudo ufw allow 443 خدمة FTP – المنفذ 21يمكن السماح لاتصالات FTP التي تُستخدَم لنقل الملفات دون تشفير (والتي لا يجدر بك استخدامها على أيّة حال) بالأمر الآتي: sudo ufw allow ftp أو إذا كنت تفضِّل استخدام رقم المنفذ (21)، فنفِّذ هذا الأمر: sudo ufw allow 21/tcp السماح لمجالات منافذ معيّنةيمكنك تحديد مجالات منافذ عبر UFW؛ حيث تَستخدِم بعض التطبيقات عدِّة منافذ، بدلًا من منفذٍ واحد. على سبيل المثال، للسماح لاتصالات X11، التي تستخدم المنافذ 6000-6007، فاستخدم هذين الأمرين: sudo ufw allow 6000:6007/tcp sudo ufw allow 6000:6007/udp عند تحديد مجالات للمنافذ مع UFW، فيجب عليك تحديد البروتوكول (tcp أو udp) الذي تُطبَّق عليه القاعدة؛ لم نذكر ذلك من قبل لأنه عدم تحديد البروتوكول يسمح ببساطة بالاتصالات لكلي البروتوكولَين، وهذا مقبولٌ في أغلبية الحالات. السماح لعناوين IP محددةعند العمل مع UFW، تستطيع تحديد عناوين IP؛ على سبيل المثال، إذا أردت السماح للاتصالات من عنوان IP محدد، مثل عنوان IP للعمل أو المنزل الذي هو 15.15.15.51، فعليك استخدام الكلمة «from» ثم عنوان IP: sudo ufw allow from 15.15.15.51 تستطيع تحديد منفذ معيّن يُسمَح لعنوان IP بالاتصال إليه عبر كتابة «to any port» متبوعةً برقم المنفذ؛ على سبيل المثال، إذا أردت السماح لعنوان 15.15.15.51 بالاتصال إلى المنفذ 22 (SSH)، فاستخدم هذا الأمر: sudo ufw allow from 15.15.15.51 to any port 22 السماح للشبكات الفرعيةإذا أردت السماح لشبكة فرعية من عناوين IP، فيمكنك استخدام «ترميز CIDR»‏ (CIDR notation) لتحديد شبكة فرعية؛ فعلى سبيل المثال، إذا أردت السماح لجميع عناوين IP التي تتراوح بين 15.15.15.1 إلى 15.15.15.254 فيمكنك استخدام هذا الأمر: sudo ufw allow from 15.15.15.0/24وبشكلٍ مشابه، تستطيع أيضًا تحديد منفذ يُسمَح للشبكة الفرعية 15.15.15.0/24 بالاتصال إليه؛ سنستخدم أيضًا المنفذ 22 (SSH) كمثال: sudo ufw allow from 15.15.15.0/24 to any port 22 السماح بالاتصالات إلى بطاقة شبكية محددةإذا أردت إنشاء قاعدة جدار ناري تُطبَّق فقط على بطاقةٍ شبكيّةٍ محددة، فيمكنك فعل ذلك عبر كتابة «allow in on» متبوعةً باسم البطاقة الشبكيّة. ربما تريد أن تبحث عن بطاقاتك الشبكيّة قبل الإكمال؛ استخدم هذا الأمر لفعل ذلك: ip addr الناتج: … 2: eth0: حجب الاتصالاتإذا لم تعدِّل السياسة الافتراضية للاتصالات الواردة، فإن UFW مضبوطٌ ليحجب كل الاتصالات الواردة؛ عمومًا، هذا يُبسِّط عملية إنشاء سياسة جدار ناري آمنة وذلك بتطلّب إنشاء قواعد تحدد بدقة المنافذ وعناوين IP التي يسمح لها «بالعبور»؛ لكن في بعض الأحيان، تريد أن تحجب اتصالاتٍ معينة بناءً على عنوان IP المصدري أو الشبكة الفرعية، ربما لأنك تعلم أن خادومك يتعرض للهجوم من هناك. وأيضًا لو حوّلت سياسة التعامل الافتراضية مع الاتصالات الواردة إلى «السماح» (والذي ليس مستحسنًا لصالح الأمان)، فعليك إنشاء قيود «حجب» لأي خدمة أو عناوين IP لا تريد السماح بمرور الاتصالات إليها. يمكنك استخدام الأوامر المشروحة آنفًا لكتابة قيود الحجب، لكن مع استبدال «deny» بالكلمة «allow». على سبيل المثال، لحجب اتصالات HTTP، فعليك استخدام الأمر: sudo ufw deny http أو إذا أردت حجب جميع الاتصالات من 15.15.15.51 فيمكنك استخدام هذا الأمر: sudo ufw deny from 15.15.15.51 إذا أردت مساعدةً في كتابة قواعد الحجب، فانظر إلى قواعد السماح السابقة وعدِّلها بما يلائمها. لنلقِ الآن نظرةً على طريقة حذف القواعد. حذف القواعدمعرفة كيفية حذف قواعد الجدار الناري بنفس أهمية معرفة كيفية إنشائها؛ هنالك طريقتان لتحديد أيّة قواعد لتحذف: عبر رقم القاعدة أو عبر القاعدة نفسها (بشكلٍ شبيه لطريقة تحديد القاعدة عندما أُنشِئت). سنبدأ بطريقة الحذف عبر رقم القاعدة لأنها أسهل، مقارنةً بكتابة القواعد نفسها، خصوصًا إن كنتَ حديث العهد بالتعامل مع UFW. عبر رقم القاعدةإذا كنت تستخدم رقم القاعدة لحذف قواعد الجدار الناري، فإن أول شيء تريد فعله هو الحصول على قائمة بقواعد جدارك الناري؛ يملك أمر UFW status خيارًا لعرض الأرقام بجوار قواعدها، كما هو مبيّن هنا: sudo ufw status numbered الناتج: Status: active To Action From -- ------ ---- [ 1] 22 ALLOW IN 15.15.15.0/24 [ 2] 80 ALLOW IN Anywhereإذا قررت أنك تريد حذف القاعدة 2، التي تسمح بالاتصالات إلى المنفذ 80 (HTTP)، فيمكنك ذلك عبر تمرير رقمها إلى أمر UFW delete كما يلي: sudo ufw delete 2 ما سبق سيُظهِر محثًا (prompt) ليطلب موافقتك، ثم سيحذف القاعدة 2 التي تسمح باتصالات HTTP. الحظ أنك إن كنت قد فعَّلت IPv6، فعليك أن تحذف قاعدة IPv6 المناظرة لها. عبر القاعدة نفسهاالبديل عن تحديد رقم القاعدة هو تحديد القاعدة نفسها؛ على سبيل المثال، إذا أردت حذف قاعدة «allow http»، فيمكنك كتابة الأمر كما يلي: sudo ufw delete allow http يمكنك أيضًا تحديد القاعدة مستعملًا «allow 80»، بدلًا من اسم الخدمة: sudo ufw delete allow 80 ستَحذُف هذه الطريقة قواعد IPv4 و IPv6 إن كانت موجودةً. كيفية تعطيل UFW (خطوة اختيارية)إذا قررت أنّك لا تريد استعمال UFW لأي سببٍ كان، فيمكنك تعطيله عبر هذا الأمر: sudo ufw disable ستُعطَّل أيّة قواعد أنشَأتها باستخدام UFW، يمكنك بأي وقتٍ تنفيذ: sudo ufw enable إذا احتجت لتفعيله لاحقًا. إعادة ضبط قواعد UFW (خطوة اختيارية)إذا كانت لديك قواعد UFW مضبوطة، لكنك قررت أن تبدأ من الصفر، فيمكنك استخدام الأمر reset: sudo ufw reset سيُعطِِّل الأمر السابق UFW ويحذف أيّة قواعد عرَّفتَها سابقًا. أبقِ في بالك أن السياسات الافتراضية لن يُعاد ضبطها إلى إعداداتها الافتراضية إذا كنت قد عدَّلتها. الخلاصةيجب أن يكون قد ضُبِطَ جدارك الناري للسماح (على الأقل) لاتصالات SSH؛ تأكد أن تسمح لأيّة اتصالات واردة أخرى لخادومك بينما تقيّد أيّة اتصالات غير ضرورية، كي يكون خادومك آمنًا ويعمل عملًا صحيحًا. ترجمة -وبتصرّف- للمقال How To Set Up a Firewall with UFW on Ubuntu 14.04 لصاحبه Mitchell Anicas.

برمجية Jenkins هي خدمة أتمتة مفتوحة المصدر الغرض منها هو أتمتة المهام التقنية المتكررة التي تتعلق بدمج وتوفير البرمجيات. برمجية Jenkins مكتوبة بلغة Java ويمكن تثبيتها من حزم أوبنتو أو بتنزيل وتشغيل ملف WAR (الذي هو مجموعة من الملفات التي تُنشِئ تطبيق ويب كامل ليعمل على خادومك). سنُثبِّت Jenkins في هذا الدرس بإضافة مستودع حزم دبيان الخاص بها، ثم بتثبيت الحزم اللازمة عبر الأداة apt-get من ذاك المستودع. المتطلبات المسبقة سنحتاج إلى خادوم أوبنتو 16.04 فيه حساب مستخدم ليس جذرًا وفيه جدار ناري وذلك باتباع التعليمات الواردة في درس «الإعداد الابتدائي لخادوم أوبنتو 14.04](https://academy.hsoub.com/devops/servers/الإعداد-الابتدائي-لخادوم-أوبنتو-1404-r4/)»، ننصح باستعمال 1 غيغابايت من ذاكرة RAM على الأقل؛ راجع صفحة Choosing the Right Hardware for Masters لمزيدٍ من المعلومات حول العتاد اللازم لتثبيت Jenkins. يمكنك المتابعة مع هذا الدرس بعد إعداد الخادوم. الخطوة الأولى: تثبيت Jenkins الإصدار المتوافر في مستودعات أوبنتو الرسمية يكون قديمًا ومتأخرًا عن الإصدار الحالي لمشروع Jenkins؛ وللاستفادة من آخر التحديثات والميزات فسنستخدم الحزم المُصانة من قِبل مشروع Jenkins نفسه. علينا أولًا إضافة مفتاح المستودع إلى النظام: wget -q -O - https://pkg.jenkins.io/debian/jenkins-ci.org.key | sudo apt-key add - بعد إتمام إضافة المفتاح بنجاح فستظهر كلمة OK في الطرفية؛ ثم سنضيف بعد ذلك عنوان مستودع دبيان إلى ملف sources.list الموجود في الخادوم: echo deb http://pkg.jenkins.io/debian-stable binary/ | sudo tee /etc/apt/sources.list.d/jenkins.list بعد تنفيذ الخطوتين السابقتين، علينا تحديث فهرس الحزم عبر الأمر: sudo apt-get update ثم نثبّت Jenkins مع اعتمادياته كلها، بما فيها بيئة تشغيل Java: sudo apt-get install jenkins يمكننا الآن تشغيل خادوم Jenkins بعد تثبيته مع اعتمادياته. الخطوة الثانية: بدء تشغيل خادوم Jenkins سنستخدم الأداة systemctl لتشغيل Jenkins: sudo systemctl start jenkins ولعدم إظهار الأمر systemctl لأية مخرجات، فسنستخدم الخيار status لعرض حالة الخدمة للتأكد أنها قد بدأت دون مشاكل: sudo systemctl status jenkins إذا جرى كل شيءٍ على ما يرام، فيجب أن تشير المخرجات أنَّ الخدمة تعمل حاليًا وستُشغَّل تلقائيًا عند الإقلاع: ● jenkins.service - LSB: Start Jenkins at boot time Loaded: loaded (/etc/init.d/jenkins; bad; vendor preset: enabled) Active:active (exited) since Thu 2017-04-20 16:51:13 UTC; 2min 7s ago Docs: man:systemd-sysv-generator(8) بعد تشغيل خادوم Jenkins، علينا الآن تعديل قواعد الجدار الناري للسماح بالوصول إلى خدمة Jenkins من متصفح الويب لإكمال ضبطه المبدئي. الخطوة الثالثة: فتح المنفذ في الجدار الناري يعمل خادوم Jenkins افتراضيًا على المنفذ 8080، لذا سنفتحه باستخدام ufw: sudo ufw allow 8080 يمكننا رؤية القاعدة الجديدة بالتحقق من حالة جدار UFW الناري: sudo ufw status يجب أن نلاحظ أنَّ التراسل الشبكي إلى المنفذ 8080 متاحٌ من كل الشبكات: Status: active To Action From -- ------ ---- OpenSSH ALLOW Anywhere 8080 ALLOW Anywhere OpenSSH (v6) ALLOW Anywhere (v6) 8080 (v6) ALLOW Anywhere (v6) بعد أن ثبتنا Jenkins وضبطنا الجدار الناري للسماح بالوصول إليه من جميع الشبكات، فسنكمل في الخطوة التالية الضبط المبدئي له. الخطوة الرابعة: ضبط خدمة Jenkins علينا لضبط خدمة Jenkins أن نزور صفحته على المنفذ الافتراضي 8080 مستعملين اسم نطاق الخادوم أو عنوان IP الخاص به كما يلي: http://ip_address_or_domain_name:8080. سنستعمل الأمر cat في نافذة الطرفية لعرض كلمة المرور: sudo cat /var/lib/jenkins/secrets/initialAdminPassword انسخ كلمة المرور المكومة من 32 محرفًا ورقمًا من الطرفية وألصقها في حقل «Administrator password» ثم اضغط على زر «Continue»، ثم ستظهر لك صفحة تعرض خيارين لتثبيت الإضافات المقترحة أو تحديد إضافات معيّنة. اضغط على خيار «Install suggested plugins» الذي سيبدأ عملية التنزيل مباشرةً: بعد إكمال التثبيت سيُطلَب منك ضبط أوّل حساب مستخدم، وصحيح أنَّ من الممكن تخطي هذه الخطوة والإكمال باستعمال المستخدم admin مع كملة المرور المبدئية التي استعملناها أعلاه، لكن من الأفضل إنشاء مستخدم جديد. ملاحظة: الاتصالات المنشأة إلى خادوم Jenkins غير مشفرة، لذا ستُرسَل البيانات النصية كما هي دون أي تشفير، لذا أنصحك باتباع ما ورد في هذا الدرس لإعداد تشفير SSL مع خادوم Jenkins، مما يحمي بيانات المستخدم والمعلومات التي ترسَل عبر واجهة الويب. بعد ضبط أوّل حساب للمدير فستُعرَض لك صفحة فيها «Jenkins is ready!‎»: اضغط على زر «Start using Jenkins» للانتقال إلى لوحة التحكم الرئيسية لخادوم Jenkins: تهانينا، لقد ثبتنا خادوم Jenkins بنجاح. الخلاصة ثبتنا في هذا الدرس برمجية Jenkins من الحزم التي يوفرها المشروع، ثم بدأنا الخدمة وفتحنا منفذًا في الجدار الناري، وأنشأنا حسابًا جديدًا للمدير؛ وتستطيع الآن أن تستكشف Jenkins. ترجمة –وبتصرّف– للمقال How To Install Jenkins on Ubuntu 16.04لصاحبته Melissa Anderson

بعد إعداد أقل قدر ممكن من الضبط للخادوم الجديد الضبط المبدئي لخادوم CentOS 7، هنالك بعض الخطوات الإضافية التي يُنصَح إجراؤها في أغلبية الحالات، وسنكمل ذلك في هذا الدرس بضبط بعض الأمور الاختيارية. المتطلبات المسبقة وأهداف هذا الدرس قبل أن تبدأ بهذا الدرس، عليك أن تتبع الخطوات المذكورة في درسنا السابق الضبط المبدئي لخادوم CentOS 7، من المهم أن تعد حسابات المستخدمين، وتمنحهم امتيازات الجذر باستخدام الأمر sudo، وتحاول تأمين خدمة SSH. يمكنك المتابعة مع هذا الدرس بعد إكمال الدرس السابق، الذي سنُركِّز فيه على ضبط بعض المكونات الاختيارية والمهمة؛ مثل ضبط الجدار الناري وملف التبديل (swap file) وضبط مزامنة الوقت والتاريخ عبر بروتوكول NTP. ضبط جدار ناري بسيط توفر الجدران النارية حمايةً أساسيةً للخواديم، وهذه التطبيقات مسؤولة عن منع الوصول إلى جميع المنافذ الشبكية على خادومك باستثناء المنافذ (أو الخدمات) التي سمحتَ لها. تأتي توزيعة CentOS مع جدارٍ ناريٍ باسم firewalld، وتستعمل أداةٌ باسم firewall-cmd لضبط سياسات الجدار الناري. سنتبع منهجية لسياسات الجدار الناري ألا وهي إغلاق جميع المنافذ إلا التي نملك سببًا وجيهًا لإبقائها مفتوحةً. لخدمة firewalld القدرة على إجراء تعديلات دون قطع الاتصالات الحالية، لذا يمكننا تشغيلها قبل أن نضيف الاستثناءات التي نريدها: sudo systemctl start firewalld لاحظ أنَّ الخدمة أصبحت تعمل الآن في الخلفية، ويمكننا استعمال الأداة firewall-cmd للحصول على معلوماتٍ عن سياسات الجدار الناري أو ضبطها. لدى برمجية firewalld مفهوم هو «المناطق» (zones) لتسمية مدى ثقتك بالأجهزة الأخرى الموجودة على شبكة ما، وهذه التسمية ستمنحنا القدرة على إسناد قواعد مختلفة بناءً على مدى «ثقتنا» بالشبكة. سنُعدِّل في درسنا هذا السياسات التابعة للمنطقة الافتراضية، وعندما نُعيد تحميل خدمة الجدار الناري، فستُطبَّق سياسات هذه المنطقة على جميع البطاقات الشبكية. يمكننا البدء بإضافة استثناءات للخدمات المسموح لها بإجراء اتصالات خارجية؛ وأهمها خدمة SSH، لأننا نريد أن نبقى قادرين على الاتصال البعيد إلى الخادوم. إذا لم تُعدِّل المنفذ الذي تستمع عليه خدمة SSH، فيمكنك السماح لاتصالات SSH بكتابة الأمر الآتي: sudo firewall-cmd --permanent --add-service=ssh أما إذا غيّرتَ منفذ SSH على خادومك، فعليك التصريح عن المنفذ الجديد يدويًا، وعليك أن تُحدِّد ما هو البروتوكول الذي تستعمله تلك الخدمة. نفِّذ الأمر الآتي إذا غيرتَ المنفذ الذي تستمع عليه خدمة SSH: sudo firewall-cmd --permanent --remove-service=ssh sudo firewall-cmd --permanent --add-port=4444/tcp هذا هو الحد الأدنى من الضبط لإبقاء الوصول إلى الخادوم البعيد ممكنًا، وإذا كنتَ تخطط لتشغيل خدمات أخرى على النظام، فعليك فتح منافذ لها في الجدار الناري. فلو كنتَ تشغِّل خادوم ويب تقليدي وأردت السماح للاتصالات المتعلقة به في الجدار الناري: sudo firewall-cmd --permanent --add-service=http إذا كنتَ تخطط لتشغيل خادوم ويب مع تشفير الاتصال عبر SSL/TLS، فعليك السماح لخدمة https أيضًا: sudo firewall-cmd --permanent --add-service=https وإذا احتجتَ إلى خدمة SMTP للبريد الإلكتروني، فنفِّذ الأمر: sudo firewall-cmd --permanent --add-service=smtp لرؤية الخدمات الأخرى التي يمكن السماح لها بتحديد اسمها، فنفِّذ: sudo firewall-cmd --get-services بعد أن تنتهي من ضبط الجدار الناري، يمكنك عرض قائمة بجميع الاستثناء الموجودة في سياسة الجدار الناري عبر الأمر الآتي: sudo firewall-cmd --permanent --list-all وعندما تكون جاهزًا لتطبيق هذه التعديلات، فأعد تحميل الجدار الناري: sudo firewall-cmd --reload وبعد أن تجرب وتتأكد من عمل كل الخدمات، فيجدر بك تفعيل الجدار الناري عند الإقلاع: sudo systemctl enable firewalld تذكر أنَّ عليك فتح منفذ في الجدار الناري عند تثبيت وضبط أيّة خدمات جديدة لاحقًا. ضبط المنطقة الزمنية ومزامنة الوقت والتاريخ الخطوة التالية هي تعديل المنطقة الزمنية وضبط مزامنة الوقت عبر بروتوكول NTP (اختصار للعبارة Network Time Protocol). أوّل خطوة هي التأكد من صحة المنطقة الزمنية المضبوطة في خادومك، والخطوة الثانية هي ضبط النظام ليزامن ساعته مع شبكة من خواديم NTP للحصول على الوقت والتاريخ بدقة، وهذا سيساعد في منع بعض المشاكل التي تحدث بسبب عدم تزامن الساعة. ضبط المنطقة الزمنية أوّل خطوة هي ضبط المنطقة الزمنية للخادوم، وهذه الخطوة سهلة جدًا ويمكن إجراؤها باستعمال الأمر timedatectl. علينا أولًا أن نعرض قائمة بالمناطق الزمنية المتوافرة بتنفيذ الأمر: sudo timedatectl list-timezones سيُنتِج الأمر السابق قائمةً بالمناطق الزمنية المتوافرة لخادومك، وعندما تجد المنطقة الزمنية الصحيحة فيمكنك ضبطها بتنفيذ الأمر: sudo timedatectl set-timezone region/timezone فمثلًا لو كان خادومك موجودًا في الساحل الشرقي للولايات المتحدة الأميركية، فيمكنك تنفيذ: sudo timedatectl set-timezone America/New_York يمكنك التأكد أنَّ نظامك قد حُدِّث ليستعمل المنطقة الزمنية التي ضبطتَها بالأمر: sudo timedatectl ضبط مزامنة الوقت عبر بروتوكول NTP علينا الآن ضبط المزامنة بعد أن ضبطنا المنطقة الزمنية، وهذا يسمح للحاسوب بمزامنة الوقت والتاريخ، مما يمنع حدوث بعض المشاكل التي يتسبب بها الاختلاف في الوقت بين الخواديم. سنستخدم خدمة باسم ntp لمزامنة الوقت، والتي يمكن تثبيتها من مستودعات CentOS: sudo yum install ntp ثم عليك بدء الخدمة لهذه الجلسة، ثم تفعيل تشغيل الخدمة عند الإقلاع: sudo systemctl start ntpd sudo systemctl enable ntpd سيُصحِّح خادومك ساعته تلقائيًا لتتوافق مع الخواديم العالمية. إنشاء ملف تبديل إضافة مساحة للتبديل (swap) إلى خادوم لينكس ستُمكِّن النظام من نقل المعلومات التي لا يتم الوصول إليها كثيرًا من ذاكرة الوصول العشوائي (RAM) إلى مكانٍ ما على القرص الصلب؛ وصحيحٌ أنَّ الوصول إلى البيانات المخزنة على القرص أبطأ بكثير بقارنة بالوصول إليها من ذاكرة الوصول العشوائي مباشرةً، لكن قد تستفيد من ذاكرة التبديل في حال نفدت المساحة المتاحة في ذاكرة RAM مما يمنع انهيار الخدمات التي يشغلها خادومك، يجدر بالذكر أنَّ استعمال مساحة التبديل مفيدٌ جدًا خصوصًا إذا كان خادومك يستضيف قواعد بيانات. لا توجد قواعد لتحديد المساحة التخزينية المثلى لذاكرة التبديل، لكنها عمومًا تساوي مقدار ذاكرة RAM في نظامك أو ضعفيها… احجز المساحة التي ترغب في استخدامها لذاكرة التبديل باستخدام الأداة fallocate، فلو أردنا إنشاء ملف للتبديل بمساحة 4 غيغابايت في مجلد ‎/swapfile سنُنفِّذ الأمر: sudo fallocate -l 4G /swapfile علينا بعد إنشاء الملف أن نمنع المستخدمين أو العمليات في النظام من الوصول إلى تلك الذاكرة وقراءة محتوياتها: sudo chmod 600 /swapfile بعد ضبط الأذونات السليمة للملف، فيمكننا أن نطلب من النظام أن يُهّيئ الملف ليعمل كذاكرة تبديل بالأمر: sudo mkswap /swapfile ثم سنطلب من النظام استخدام ملف التبديل الذي أنشأناه آنفًا: sudo swapon /swapfile أصبح نظامنا يستعمل ملف التبديل لحين إعادة إقلاعه، لذا سنحتاج إلى تعديل نظام الملفات لكي يفعل النظام ذلك تلقائيًا عند الإقلاع، وذلك بإضافة سطر جديد إلى ملف ‎/etc/fstab: sudo sh -c 'echo "/swapfile none swap sw 0 0" >> /etc/fstab' يجب أن يستعمل نظامك هذا الملف كذاكرة تبديل عند كل إقلاع. الخلاصة عند هذه المرحلة يجب أن تكون قد ضبطت خادومك ضبطًا أساسيًا، ومن المرجح أن تكون عندك فكرة لما ستفعله لاحقًا، أنصحك بالاطلاع على المقالات الموجودة في قسم DevOps في أكاديمية حسوب. ترجمة –وبتصرّف– للمقال Additional Recommended Steps for New CentOS 7 Serversلصاحبه Justin Ellingwood

iptables عبارة عن جدار ناري firewall يلعب دورًا أساسيًّا في أمان الشبكات لمعظم أنظمة لينِكس، وبينما تقوم العديد من دروس iptables بتعليمنا كيفيّة إنشاء قواعد الجدار النّاري لتأمين خادومنا، يُركِّز هذا الدرس على ناحية مختلفة من إدارة الجدار النّاري: سرد listing وحذف القواعد rules. سنشرح في هذا الدّرس كيفيّة القيام بمهام iptables التالية: سرد القواعد list rules مسح عدادات Packet وByte حذف القواعد إفراغ السلاسل Flush chains (حذف جميع القواعد في السلسلة) إفراغ السلاسل والجداول، حذف السلاسل، وقبول أي حركة مرور البيانات traffic ملاحظة: احذر عند التعامل مع الجدار النّاري من حظر نفسك عن خادومك عن طريق حظر حركة مرور بيانات SSH (المنفذ 22 افتراضيًّا)، وإن فقدت النفاذ إليه بسبب إعدادات الجدار النّاري فربّما تحتاج للاتصال إليه عن طريق الـ console لإصلاح نفاذنا إليه، حيث تستطيع بعدها تغيير إعدادات الجدار النّاري للسماح بنفاذ SSH (أو أي حركة مرور بيانات traffic)، وإن كانت قواعد الجدار النّاري المحفوظة لديك تسمح بنفاذ SSH فمن الطرق الأخرى هي إعادة تشغيل خادومك. المتطلبات الأساسية ينبغي قبل أن تبدأ باتّباع هذا الدّرس أن تمتلك على خادومك حساب superuser غير جذري non-root مُنفصِل (مُستخدِم مع صلاحيّات sudo)، إن أردت إعداده اتبع الدّرس التّالي: الإعداد الابتدائي لخادوم أوبنتو 14.04. فلنقم بإلقاء نظرة على كيفيّة سرد list القواعد أولًا. توجد طريقتان مختلفتان لعرض قواعد iptables النشيطة active: إمّا في جدول أو على شكل قائمة من مواصفات القواعد، تُزوِّدنا هاتان الطريقتان بنفس المعلومات تقريبًا في صيغ مختلفة. سرد القواعد بحسب المواصفات Specification لسرد جميع قواعد iptables النشيطة بحسب المواصفات نقوم بتنفيذ الأمر iptables مع الخيار S-: sudo iptables -S -P INPUT DROP -P FORWARD DROP -P OUTPUT ACCEPT -N ICMP -N TCP -N UDP -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -m conntrack --ctstate INVALID -j DROP -A INPUT -p udp -m conntrack --ctstate NEW -j UDP -A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j TCP -A INPUT -p icmp -m conntrack --ctstate NEW -j ICMP -A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable -A INPUT -p tcp -j REJECT --reject-with tcp-reset -A INPUT -j REJECT --reject-with icmp-proto-unreachable -A TCP -p tcp -m tcp --dport 22 -j ACCEPT يبدو الخرْج Output كما نرى مُشابِهًا للأوامر التي اعتدنا على إنشائها ولكن بدون أن يسبقها الأمر iptables، يبدو هذا أيضًا مُشابِهًا لملفّات إعدادات قواعد iptables إن قمت سابقًا باستخدام iptables-persistent أو iptables save. سرد سلسلة محددة إن أردنا تحديد الخَرْج إلى سلسلة مُحدّدة (مثل INPUT، OUTPUT، TCP، إلخ..) فبإمكاننا تحديد اسم السلسلة مباشرة بعد الخيار S-، على سبيل المثال لإظهار كافّة مواصفات القواعد في سلسلة TCP نقوم بتنفيذ الأمر التالي: sudo iptables -S TCP -N TCP -A TCP -p tcp -m tcp --dport 22 -j ACCEPT فلنقم بإلقاء نظرة على الطريقة البديلة لعرض قواعد iptables النشيطة كجدول من القواعد. سرد القواعد كجداول يُمكِن أن يكون عرض قواعد iptables في طريقة عرض الجدول مفيدًا لمقارنة القواعد المختلفة مع بعضها. لإخراج كافّة قواعد iptables النشيطة في جدول نقوم بتنفيذ الأمر iptables مع الخيار L-: sudo iptables -L سيقوم هذا بإخراج جميع القواعد الحاليّة مُرتّبة بحسب السلسلة. إن أردنا تحديد الخَرْج إلى سلسلة مُحدّدة (مثل INPUT، OUTPUT، TCP، إلخ..) فبإمكاننا تحديد اسم السلسلة مباشرة بعد الخيار L-. دعونا نلقي نظرة على مثال عن سلسلة الدّخل INPUT: sudo iptables -L INPUT Chain INPUT (policy DROP) target prot opt source destination ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED ACCEPT all -- anywhere anywhere DROP all -- anywhere anywhere ctstate INVALID UDP udp -- anywhere anywhere ctstate NEW TCP tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,ACK/SYN ctstate NEW ICMP icmp -- anywhere anywhere ctstate NEW REJECT udp -- anywhere anywhere reject-with icmp-port-unreachable REJECT tcp -- anywhere anywhere reject-with tcp-reset REJECT all -- anywhere anywhere reject-with icmp-proto-unreachable يُشير السّطر الأول من الخَرْج إلى اسم السلسلة (في هذه الحالة INPUT) متبوعًا بسياسته policy الافتراضيّة (DROP). يتكوّن السّطر التالي من ترويسة كل عمود في الجدول متبوعة بقواعد السلسلة، فلنقم بالمرور على دلالة كل ترويسة: target: إن كانت الرزمة packet تُطابِق القاعدة يُحدِّد الهدف target ما ينبغي فعله معها، يُمكن على سبيل المثال أن يتم قبول، إسقاط drop، تسجيل، أو إرسال الرزمة إلى سلسلة أخرى لتتم مقارنتها مع قواعد أخرى prot: الميفاق protocol، مثل tcp، udp، icmp، أو all opt: يُشير هذا العمود إلى خيارات عنوان IP ونادرًا ما يتم استخدامه source: عنوان IP المصدر أو الشبكة الفرعية subnet لحركة مرور البيانات traffic، أو anywhere destination: عنوان IP الوجهة destination أو الشبكة الفرعية subnet لحركة مرور البيانات traffic، أو anywhere يُشير العمود الأخير الذي لا يملك عنوان إلى خيارات options القاعدة، والتي هي أي جزء من القاعدة لم يتم الإشارة إليه في الأعمدة السابقة، يُمكن لها أن تكون أي شيء من منافذ ports المصدر والوجهة، وحتى حالة اتصال الرزمة. إظهار تعداد الرزم Packet Counts والحجم الكلي Aggregate Size من الممكن أيضًا عند سرد قواعد iptables أن نظهر عدد الرُّزَم packets والحجم الكلّي لها بالبايت، والذي يُقابل كل قاعدة مُحدّدة، يكون هذا مُفيدًا عادةً عندما نحاول أخذ فكرة تقريبيّة عن القواعد التي تُطابِق الرُّزَم، ولفعل هذا نستخدم ببساطة الخيارين L- وv- معًا. فلنلقِ نظرة على سبيل المثال على سلسلة الدّخل INPUT مرّة أخرى مع الخيار v-: sudo iptables -L INPUT -v Chain INPUT (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 284K 42M ACCEPT all -- any any anywhere anywhere ctstate RELATED,ESTABLISHED 0 0 ACCEPT all -- lo any anywhere anywhere 0 0 DROP all -- any any anywhere anywhere ctstate INVALID 396 63275 UDP udp -- any any anywhere anywhere ctstate NEW 17067 1005K TCP tcp -- any any anywhere anywhere tcp flags:FIN,SYN,RST,ACK/SYN ctstate NEW 2410 154K ICMP icmp -- any any anywhere anywhere ctstate NEW 396 63275 REJECT udp -- any any anywhere anywhere reject-with icmp-port-unreachable 2916 179K REJECT all -- any any anywhere anywhere reject-with icmp-proto-unreachable 0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:ssh ctstate NEW,ESTABLISHED نلاحظ أنّ القائمة تحتوي الآن على عمودين إضافيين وهما pkts وbytes. الآن وقد عرفنا كيفيّة سرد قواعد الجدار النّاري النشيطة بطرق متعدّدة، فلنلقِ نظرة على كيفيّة تصفير reset عدادات الرُّزم والبايتات. تصفير تعداد الرزم Packet Counts والحجم الكلي Aggregate Size إن أردنا مسح أو تصفير عدادات الرُّزَم والبايتات لقواعدنا نستخدم الخيار Z-، يتم أيضًا تصفيرها عند حدوث إعادة تشغيل، وهذا مفيد لمعرفة إن كان خادومنا يتلقّى حركة مرور بيانات جديدة تتوافق مع قواعدنا الحاليّة. لمسح العدادات لجميع السلاسل والقواعد نستخدم الخيار Z-: sudo iptables -Z ولمسح العدادات لجميع القواعد في سلسلة مُحدّدة نستخدم الخيار Z- مع تحديد السلسلة المطلوبة، على سبيل المثال لمسح عدادات سلسلة الدّخل INPUT نكتب هذا الأمر: sudo iptables -Z INPUT إن أردنا مسح العدادات من أجل قاعدة مُحدّدة نُحدِّد اسم السلسلة ورقم القاعدة، على سبيل المثال لتصفير العدادات للقاعدة الأولى في سلسلة الدّخل INPUT نقوم بتنفيذ الأمر التالي: sudo iptables -Z INPUT 1 الآن وقد عرفنا كيفيّة تصفير عدادات الرُّزَم والبايتات في iptables فلنلقِ نظرة على طريقتي حذفهما. حذف القاعدة بحسب المواصفات Specification إنّ إحدى طرق حذف قواعد iptables هي عن طريق مواصفات القاعدة، ولفعل هذا نستطيع تنفيذ الأمر iptables مع الخيار D- متبوعًا بمواصفات القاعدة، إن أردنا استخدام هذه الطريقة لحذف القواعد فبإمكاننا استخدام خَرْج سرد القواعد (iptables –S) من أجل المساعدة. إن أردنا على سبيل المثال حذف القاعدة التي تقوم بإسقاط (drop) الرُّزَم الخاطئة القادمة فبإمكاننا تنفيذ هذا الأمر: sudo iptables -D INPUT -m conntrack --ctstate INVALID -j DROP نلاحظ أنّه يجب علينا استبعاد الخيار A- والذي يُستخدَم للإشارة إلى موقع القاعدة في وقت إنشائها. حذف القاعدة بحسب السلسلة والرقم الطريقة الأخرى لحذف قواعد iptables هي عن طريق سلسلتها chain ورقم سطرها line number، ولتحديد هذا الرقم نقوم بسرد القواعد في صيغة جدول مع إضافة الخيار line-numbers--: sudo iptables -L --line-numbers Chain INPUT (policy DROP) num target prot opt source destination 1 ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED 2 ACCEPT all -- anywhere anywhere 3 DROP all -- anywhere anywhere ctstate INVALID 4 UDP udp -- anywhere anywhere ctstate NEW 5 TCP tcp -- anywhere anywhere tcp flags:FIN,SYN,RST,ACK/SYN ctstate NEW 6 ICMP icmp -- anywhere anywhere ctstate NEW 7 REJECT udp -- anywhere anywhere reject-with icmp-port-unreachable 8 REJECT tcp -- anywhere anywhere reject-with tcp-reset 9 REJECT all -- anywhere anywhere reject-with icmp-proto-unreachable 10 ACCEPT tcp -- anywhere anywhere tcp dpt:ssh ctstate NEW,ESTABLISHED ... يُضيف هذا الخيار رقم السطر لكل قاعدة مع الإشارة إليه بالترويسة num. بعد أن نعرف ما هي القاعدة التي نريد حذفها نتأكد من سلسلة ورقم سطر هذه القاعدة ثم نقوم بتنفيذ الأمر iptables –D متبوعًا بسلسلة ورقم القاعدة. على سبيل المثال إن أردنا حذف قاعدة input التي تُسقِط الرُّزَم الخاطئة نستطيع أن نرى أنّها القاعدة 3 من السلسلة INPUT لذا نقوم بتنفيذ الأمر التالي: sudo iptables -D INPUT 3 الآن وقد عرفنا كيفيّة حذف قواعد الجدار النّاري المفردة فلننتقل إلى كيفيّة إفراغ flush سلاسل القواعد. إفراغ السلاسل تُزوّدنا iptables بطريقة لحذف كافّة القواعد في سلسلة، أي إفراغ flush السلسلة، يُغطّي هذا القسم الطرق المتعدّدة لفعل هذا. ملاحظة: انتبه، فقد تحظر نفسك عن خادومك عبر SSH عن طريق إفراغ سلسلة تمتلك سياسة افتراضيّة drop أو deny، إن فعلت ذلك فربّما تحتاج للاتصال بخادومك عبر الـ console لإصلاح النفاذ إليه. 1- إفراغ سلسلة مفردة لإفراغ سلسلة مُحدّدة، والذي يقوم بحذف كافّة القواعد في هذه السلسلة، فبإمكاننا استخدام الخيار F- (أو الخيار flush-- المُكافِئ له) مع اسم السلسلة التي نريد إفراغها. على سبيل المثال لحذف جميع القواعد في سلسلة الدّخل INPUT نقوم بتنفيذ هذا الأمر: sudo iptables -F INPUT 2- إفراغ كافة السلاسل لإفراغ كافّة السلاسل، والذي يقوم بحذف كامل قواعد الجدار النّاري لدينا، فبإمكاننا استخدام الخيار F- (أو الخيار flush-- المُكافِئ له): sudo iptables -F إفراغ جميع القواعد، حذف كامل السلاسل، وقبول أي حركة مرور بيانات traffic سنشاهد في هذا القسم كيفيّة إفراغ كامل قواعد الجدار النّاري لدينا، الجداول، والسلاسل، والسماح بأي حركة مرور بيانات traffic على الشبكة. ملاحظة: سيقوم هذا بتعطيل الجدار النّاري لديك بشكل كامل، ينبغي فقط أن تتبع هذا القسم إن أردت البدء من جديد في إعداد الجدار النّاري لديك. نُعيّن في البداية السياسات الافتراضيّة لكل سلسلة مُضمَّنة إلى ACCEPT، السبب الأساسي لفعل هذا هو التأكد من عدم حظر أنفسنا عن خادومنا عبر SSH: sudo iptables -P INPUT ACCEPT sudo iptables -P FORWARD ACCEPT sudo iptables -P OUTPUT ACCEPT نقوم بعدها بإفراغ الجداول nat وmangle، إفراغ كامل السلاسل (F-)، وحذف كافّة السلاسل غير الافتراضيّة (X-): sudo iptables -t nat -F sudo iptables -t mangle -F sudo iptables -F sudo iptables -X سيسمح الآن جدارنا النّاري بكافة حركة مرور البيانات traffic على الشبكة، وإن قمنا بسرد قواعدنا الآن سنشاهد أنّه لا توجد أي قاعدة، وأنّه فقط بقيت لنا السلاسل الثلاث الافتراضية (INPUT، FORWARD، وOUTPUT). الخاتمة ينبغي بعد قراءة هذا هذا الدّرس أن تتكوّن لديك صورة واضحة حول كيفيّة سرد وحذف قواعد جدار iptables النّاري لديك. تذكّر أنّ أي تغيير لـ iptables عبر الأمر iptables هو تغيير عابر، ويجب حفظه ليبقى بشكل دائم بعد إعادة تشغيل الخادوم، وقد تم شرح هذا في قسم حفظ القواعد من درس قواعد وأوامر شائعة للجدار النّاري. ترجمة -وبتصرّف- لـ How To List and Delete Iptables Firewall Rules لصاحبه Mitchell Anicas.

NAT، أو نقل عنوان الشبكة network address translation، عبارة عن مصطلح عام لإدارة الرُّزَم packets من أجل إعادة توجيهها إلى عنوان بديل، وهو يُستخدم عادةً للسماح لحركة مرور البيانات traffic بتجاوز حدود الشبكة، يمتلك المُضيف host الذي يُطبِّق NAT نفاذًا إلى شبكتين أو أكثر بشكل نموذجي وهو مُعَد لنقل حركة مرور البيانات بينها. إعادة توجيه المنافذ Port forwarding هو عمليّة إعادة توجيه الطلبات لمنفذ مُعيَّن إلى مُضيف آخر، شبكة، أو منفذ. وبينما تقوم هذه العمليّة بتعديل وجهة الرُّزَم أثناء نقلها، فهي تُعتبَر نوع من عمليّات NAT. سنشرح في هذا الدرس كيفيّة استخدام iptables لإعادة توجيه المنافذ إلى مضيفين خلف جدار ناري باستخدام تقنيات NAT، يكون هذا مفيدًا في حال قمنا بإعداد شبكة خاصّة Private Network ولا زلنا نريد السماح لبعض حركة مرور البيانات بالمرور عبر جهاز مُحدّد كبوّابة gateway، سنستخدم مُضيفين اثنين يعملان على نظام Ubuntu لتوضيح هذا. المتطلبات الأساسية والأهداف لمتابعة هذا الدّرس تحتاج إلى مُضيفين اثنين يعملان على نظام Ubuntu في نفس مركز البيانات مع تمكين الشبكات الخاصّة private networking، نحتاج إلى إعداد حساب مُستخدِم غير جذري non-root مع صلاحيّات sudo على كل من هذين الجهازين، تستطيع معرفة كيفيّة إعداد مُستخدِم مع صلاحيّات sudo باتّباع درس الإعداد الأولي لخادوم Ubuntu. سيعمل المُضيف الأول كجدار ناري ومُوجِّه router لأجل الشبكة الخاصّة، ولأغراض توضيحيّة سيكون المُضيف الثاني مُعدًّا مع خادوم ويب قابل للوصول فقط باستخدام واجهته الخاصّة، سنقوم بإعداد جهاز الجدار الناري ليُعيد توجيه الطلبات التي يتلقّاها على واجهته العامّة إلى خادوم الويب حيث ستصل إلى واجهته الخاصّة. تفاصيل المضيف نحتاج قبل البدء أن نعرف الواجهات والعناوين التي يتم استخدامها من قِبَل كلا الخادمين لدينا. العثور على تفاصيل شبكتنا للحصول على تفاصيل أنظمتنا نبدأ بإيجاد واجهات شبكاتنا Network Interfaces، نستطيع العثور على الواجهات والعناوين المرتبطة بها على أجهزتنا بكتابة: ip -4 addr show scope global 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 inet 198.51.100.45/18 brd 45.55.191.255 scope global eth0 valid_lft forever preferred_lft forever 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 inet 192.168.1.5/16 brd 10.132.255.255 scope global eth1 valid_lft forever preferred_lft forever يُظهِر الخَرْج output السّابق واجهتين (eth0 و eth1) والعناوين المُخصّصة لكل منهما (192.51.100.45 و 192.168.1.5 على الترتيب)، ولمعرفة أيّ الواجهتين هي الواجهة العامّة نكتب: ip route show | grep default default via 111.111.111.111 dev eth0 تكون الواجهة الظاهرة أمامنا (eth0 في هذا المثال) هي الواجهة المُتصلة إلى بوّابتنا الافتراضيّة، وهي بكل تأكيد واجهتنا العامّة. قم بإيجاد هذه القيم على كل جهاز لديك واستخدمها للمتابعة مع هذا الدّرس بشكل صحيح. عينة بيانات من أجل هذا الدرس لكي نجعل متابعة هذا الدّرس أسهل سنستخدم العناوين الوهميّة وتعيينات الواجهة التالية، قم بوضع القيم الخاص بك بدلًا من هذه القيم: تفاصيل شبكة خادوم الويب: عنوان IP العام Public IP Address: 203.0.113.2 عنوان IP الخاص Private IP Address: 192.0.2.2 الواجهة العامّة Public Interface: eth0 الواجهة الخاصّة Private Interface: eth1 تفاصيل شبكة الجدار الناري: عنوان IP العام Public IP Address: 203.0.113.15 عنوان IP الخاص Private IP Address: 192.0.2.15 الواجهة العامّة Public Interface: eth0 الواجهة الخاصّة Private Interface: eth1 إعداد خادوم الويب سنبدأ بإعداد مُضيف خادوم الويب، نقوم بتسجيل الدخول كمستخدم sudo للبدء. تثبيت Nginx الخطوة الأولى التي سنقوم بها هي تثبيت Nginx على مُضيف خادوم الويب لدينا وقفله بحيث يستمع فقط إلى واجهته الخاصّة، يجعلنا هذا متأكدين من أنّ خادوم الويب لن يكون متوفّرًا إلّا إذا ضبطنا إعادة توجيه المنافذ بشكل صحيح. نبدأ بتحديث الذاكرة المؤقتة للحزم المحليّة local package cache باستخدام الأمر apt لتنزيل وتثبيت Nginx: webserver $ sudo apt-get update webserver $ sudo apt-get install nginx تقييد Nginx إلى الشبكة الخاصة بعد تثبيت Nginx نقوم بفتح ملف إعدادات كتلة block الخادوم الافتراضيّة للتأكد من أنّه يستمع فقط إلى واجهته الخاصّة، نفتح الملف عن طريق الأمر التالي: webserver $ sudo nano /etc/nginx/sites-enabled/default نبحث بداخله عن الأمر التوجيهي listen، ينبغي أن نجده في سطرين متتاليين في أعلى ملف الإعدادات: etc/nginx/sites-enabled/default/ server { listen 80 default_server; listen [::]:80 default_server ipv6only=on; . . . } نقوم عند الأمر التوجيهي listen الأول بإضافة عنوان IP الخاص لخادوم الويب لدينا مع نقطتين قبل 80 لنُخبِر Nginx أن يستمع فقط إلى واجهته الخاصّة، سنوضّح في هذا الدّرس إعادة توجيه IPv4 فقط، لذا نستطيع إزالة الأمر التوجيهي listen الثاني المُعَد من أجل IPv6. سنقوم في مثالنا بتعديل الأمر التوجيهي listen بحيث يبدو كما يلي: etc/nginx/sites-enabled/default/ server { listen 192.0.2.2:80 default_server; . . . } عند الانتهاء نحفظ الملف ونغلقه، نختبر الملف بحثًا عن أخطاء الصياغة syntax بكتابة ما يلي: webserver $ sudo nginx -t إن لم تظهر أيّة أخطاء نُعيد تشغيل خادوم Nginx لتمكين الإعدادات الجديدة: webserver $ sudo service nginx restart التحقق من تقييد الشبكة Network Restriction من المُفيد عند هذه النقطة التحقّق من مستوى النفاذ الذي نملكه لخادوم الويب لدينا. إن قمنا بمحاولة النفاذ لخادوم الويب عبر واجهته الخاصّة من خلال خادوم الجدار الناري firewall ينبغي أن ينجح هذا: firewall $ curl --connect-timeout 5 192.0.2.2 <!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> <style> body { width: 35em; margin: 0 auto; font-family: Tahoma, Verdana, Arial, sans-serif; } </style> </head> <body> <h1>Welcome to nginx!</h1> . . . أمّا إن قمنا باستخدام الواجهة العامّة سنجد أنّنا لن نستطيع الاتصال: firewall $ curl --connect-timeout 5 203.0.113.2 curl: (7) Failed to connect to 203.0.113.2 port 80: Connection refused وهو بالضبط ما نتوقّع حدوثه. إعداد الجدار الناري لإعادة توجيه المنفذ 80 نستطيع الآن العمل على تنفيذ إعادة توجيه المنافذ على جهاز الجدار الناري. تمكين إعادة التوجيه في النواة Kernel الأمر الأول الذي يجب فعله هو تمكين إعادة التوجيه على مستوى النّواة، تكون إعادة التوجيه غير مُشغَّلة في مُعظم الأنظمة. ولتشغيل إعادة توجيه المنافذ لأجل هذه الجلسة فقط نكتب: firewall $ echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward ولتشغيل إعادة توجيه المنافذ بشكل دائم ينبغي علينا تحرير الملف etc/sysctl.conf/، نفتح الملف بصلاحيّات sudo بكتابة: firewall $ sudo nano /etc/sysctl.conf نبحث بداخله عن السطر التالي ونقوم بإزالة التعليق uncomment عنه: etc/sysctl.conf/ net.ipv4.ip_forward=1 عند الانتهاء نحفظ الملف ونغلقه، نقوم بتطبيق الإعدادات في هذا الملف بكتابة ما يلي: firewall $ sudo sysctl -p firewall $ sudo sysctl --system إعداد الجدار الناري الأساسي سنستخدم الجدار الناري الموجود في هذا الدّرس كإطار عمل أساسي من أجل القواعد، قم بتنفيذ التعليمات في درس كيفية إعداد جدارٍ ناريّ باستخدام iptables، وبعد الانتهاء يجب أن تكون قد: قمت بتثبيت iptables-persistent حفظت مجموعة القواعد الافتراضيّة في etc/iptables/rules.v4/ تعلّمت كيفيّة إضافة أو ضبط القواعد عن طريق تحرير ملف القواعد أو باستخدام الأمر iptables بعد أن تقوم بإعداد الجدار الناري الأساسي أكمل الخطوات التالية لكي تستطيع ضبطه من أجل إعادة توجيه المنافذ. إضافة قواعد إعادة التوجيه نريد أن نضبط جدارنا الناري بحيث تتم إعادة توجيه حركة مرور البيانات traffic المُتدفّقة لواجهتنا العامّة (eth0) إلى واجهتنا الخاصّة (eth1). يمتلك جدارنا الناري الأساسي السلسلة FORWARD مُعدّة افتراضيًّا لكي تستبعد DROP حركة مرور البيانات، نحتاج لإضافة قواعد تسمح لنا بإعادة توجيه الاتصالات لخادوم الويب لدينا، ولأغراض أمنية سنقوم بتحديد هذا بشكل مُحكَم بحيث يتم فقط السماح للاتصالات التي نرغب بإعادة توجيهها. سنقبل في السلسلة FORWARD الاتصالات الجديدة المتجهة للمنفذ 80 والقادمة من واجهتنا العامة مُغادرةً إلى واجهتنا الخاصة، يتم تحديد الاتصالات الجديدة بواسطة اللاحقة conntrack ويتم تمثيلها بشكل خاص بواسطة رُزمة TCP SYN: firewall $ sudo iptables -A FORWARD -i eth0 -o eth1 -p tcp --syn --dport 80 -m conntrack --ctstate NEW -j ACCEPT سيسمح هذا للرزمة الأولى المعنيّة بإنشاء الاتصال بالعبور من خلال الجدار الناري، نحتاج أيضًا للسماح بأي حركة مرور بيانات لاحقة في كلا الاتجاهين والتي تنتج عن هذا الاتصال، نكتب ما يلي للسماح بحركة مرور البيانات التي تُنشئ هذا الاتصال ESTABLISHED والمتعلّقة به RLEATED بين واجهاتنا الخاصّة والعامة: firewall $ iptables -A FORWARD -i eth0 -o eth1 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT firewall $ iptables -A FORWARD -i eth1 -o eth0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT بإمكاننا إعادة التحقّق من أنّ سياساتنا على السلسلة FORWARD هي الاستبعاد DROP بكتابة ما يلي: firewall $ sudo iptables -P FORWARD DROP عند هذه النقطة سمحنا بحركة مرور بيانات مُحدّدة بين واجهاتنا الخاصّة والعامّة بالمرور من خلال الجدار الناري لدينا، ومع ذلك لم نقم بضبط القواعد التي تُخبِر iptables فعليًّا كيف يقوم بنقل وتوجيه حركة مرور البيانات. إضافة قواعد NAT لتوجيه الرزم بشكل صحيح سنضيف الآن القواعد التي تُخبِر iptables كيف يقوم بتوجيه حركة مرور بياناتنا، نحتاج لتنفيذ عمليتين منفصلتين من أجل أن يقوم iptables بتغيير الرُّزَم بشكل صحيح بحيث يتمكّن العملاء من التواصل مع خادوم الويب. تحدث العمليّة الأولى التي تُدعى DNAT في السلسلة PREROUTING من جدول nat، وهي عمليّة تقوم بتبديل عنوان وجهة الرُّزَم لتمكينها من التوجه بشكل صحيح عندما تمر بين الشبكات، سيتصل العملاء على الشبكة العامّة إلى خادوم الجدار الناري لدينا بدون أن يعلموا عن بُنية الشبكة الخاصّة لدينا، نحتاج لتبديل عنوان الوجهة لكل رُزمة بحيث تعلم عند إرسالها خارج شبكتنا الخاصّة كيف تصل بشكل صحيح إلى خادوم الويب. بما أنّنا نقوم فقط بإعداد إعادة توجيه المنافذ ولا نقوم بعمل NAT على كل رُزمة تصطدم بجدارنا الناري فيجب علينا أن نُطابِق المنفذ 80 في قاعدتنا، سنقوم بمطابقة الرُّزَم التي تستهدف المنفذ 80 إلى عنوان IP الخاص لخادوم الويب لدينا (192.0.2.2 في مثالنا): firewall $ sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to-destination 192.0.2.2 يهتم هذا بنصف الحل، فينبغي الآن أن يتم توجيه الرُّزَم بشكل صحيح إلى خادوم الويب لدينا، ومع ذلك فإنّ الرُّزَم لا تزال تملك العنوان الأصلي للعميل كعنوان مصدر، وسيحاول الخادوم إرسال الرد مباشرة إلى ذلك العنوان، ممّا يجعل من المستحيل تأسيس اتصال TCP قانوني. نحتاج من أجل ضبط التوجيه المناسب أن نقوم بتعديل عنوان المصدر للرُزَم عندما تغادر الجدار الناري في طريقها إلى خادوم الويب، يجب علينا تعديل عنوان المصدر وتغييره إلى عنوان IP الخاص لخادوم الجدار الناري لدينا (في مثالنا 192.0.2.15)، سيتم عندها إرسال الرّد إلى الجدار الناري والذي يستطيع إعادة توجيهه إلى العميل كما هو متوقّع. ولتمكين هذه الوظيفة سنضيف قاعدة إلى سلسلة POSTROUTING من جدول nat، والتي يتم تقييمها مباشرة قبل إرسال الرُّزَم على الشبكة، سنطابق الرُّزَم الموجّهة إلى خادوم الويب عن طريق عنوان IP والمنفذ: firewall $ sudo iptables -t nat -A POSTROUTING -o eth1 -p tcp --dport 80 -d 192.0.2.2 -j SNAT --to-source 192.0.2.15 حالما يتم إعداد هذه القاعدة ينبغي أن يصبح خادوم الويب لدينا قابل للنفاذ عن طريق توجيه متصفّح الويب لدينا إلى العنوان العام لجهاز الخادوم الناري: curl 203.0.113.15 <!DOCTYPE html> <html> <head> <title>Welcome to nginx!</title> <style> body { width: 35em; margin: 0 auto; font-family: Tahoma, Verdana, Arial, sans-serif; } </style> </head> <body> <h1>Welcome to nginx!</h1> . . . اكتمل هنا إعداد إعادة توجيه المنافذ. ضبط مجموعة القواعد الدائمة نستطيع الآن بعد أن قمنا بإعداد إعادة توجيه المنافذ أن نحفظه في مجموعة قواعد دائمة. إن لم تكن تهتم بفقدان التعليقات الموجودة في مجموعة القواعد الحالية لديك فاستخدم الخدمة iptables-persistent لحفظ قواعدك: firewall $ sudo service iptables-persistent save إن كنت ترغب بالحفاظ على التعليقات في ملفّك، فقم بفتحه وتحريره يدويًّا: firewall $ sudo nano /etc/iptables/rules.v4 سنحتاج إلى ضبط الإعدادات في الجدول filter من أجل قواعد السلسلة FORWARD التي تمّت إضافتها، يجب علينا أيضًا ضبط القسم الذي يقوم بإعداد الجدول nat كي نستطيع إضافة القواعد PREROUTING و POSTROUTING، سيبدو هذا في مثالنا مُشابِهًا لما يلي: etc/iptables/rules.v4/ *filter # Allow all outgoing, but drop incoming and forwarding packets by default :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT ACCEPT [0:0] # Custom per-protocol chains :UDP - [0:0] :TCP - [0:0] :ICMP - [0:0] # Acceptable UDP traffic # Acceptable TCP traffic -A TCP -p tcp --dport 22 -j ACCEPT # Acceptable ICMP traffic # Boilerplate acceptance policy -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT -A INPUT -i lo -j ACCEPT # Drop invalid packets -A INPUT -m conntrack --ctstate INVALID -j DROP # Pass traffic to protocol-specific chains ## Only allow new connections (established and related should already be handled) ## For TCP, additionally only allow new SYN packets since that is the only valid ## method for establishing a new TCP connection -A INPUT -p udp -m conntrack --ctstate NEW -j UDP -A INPUT -p tcp --syn -m conntrack --ctstate NEW -j TCP -A INPUT -p icmp -m conntrack --ctstate NEW -j ICMP # Reject anything that's fallen through to this point ## Try to be protocol-specific w/ rejection message -A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable -A INPUT -p tcp -j REJECT --reject-with tcp-reset -A INPUT -j REJECT --reject-with icmp-proto-unreachable # Rules to forward port 80 to our web server # Web server network details: # * Public IP Address: 203.0.113.2 # * Private IP Address: 192.0.2.2 # * Public Interface: eth0 # * Private Interface: eth1 # # Firewall network details: # # * Public IP Address: 203.0.113.15 # * Private IP Address: 192.0.2.15 # * Public Interface: eth0 # * Private Interface: eth1 -A FORWARD -i eth0 -o eth1 -p tcp --syn --dport 80 -m conntrack --ctstate NEW -j ACCEPT -A FORWARD -i eth0 -o eth1 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT -A FORWARD -i eth1 -o eth0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT # End of Forward filtering rules # Commit the changes COMMIT *raw :PREROUTING ACCEPT [0:0] :OUTPUT ACCEPT [0:0] COMMIT *nat :PREROUTING ACCEPT [0:0] :INPUT ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] # Rules to translate requests for port 80 of the public interface # so that we can forward correctly to the web server using the # private interface. # Web server network details: # * Public IP Address: 203.0.113.2 # * Private IP Address: 192.0.2.2 # * Public Interface: eth0 # * Private Interface: eth1 # # Firewall network details: # # * Public IP Address: 203.0.113.15 # * Private IP Address: 192.0.2.15 # * Public Interface: eth0 # * Private Interface: eth1 -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to-destination 192.0.2.2 -A POSTROUTING -d 192.0.2.2 -o eth1 -p tcp --dport 80 -j SNAT --to-source 192.0.2.15 # End of NAT translations for web server traffic COMMIT *security :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] COMMIT *mangle :PREROUTING ACCEPT [0:0] :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] COMMIT قم بحفظ الملف وأغلقه بعد إضافة ما سبق وضبط القيم لكي تنطبق على بيئة شبكتك الخاصّة. نختبر صياغة ملف القواعد لدينا بكتابة: firewall $ sudo iptables-restore -t < /etc/iptables/rules.v4 إن لم يتم اكتشاف أيّة أخطاء نقوم بتحميل مجموعة القواعد: firewall $ sudo service iptables-persistent reload نختبر أنّ خادوم الويب لدينا لا يزال قابل للنفاذ من خلال عنوان IP العالم للجدار النّاري: firewall $ curl 203.0.113.15 ينبغي لهذا أن يعمل كما عمل سابقًا. الخاتمة ينبغي الآن أن نكون متآلفين مع إعادة توجيه المنافذ على خادوم لينِكس باستخدام iptables، تتضمّن العملية السماح بإعادة التوجيه على مستوى النّواة، إعداد النفاذ للسماح بإعادة التوجيه لحركة مرور البيانات لمنافذ مُحدّدة بين واجهتين على نظام الجدار النّاري، وضبط قواعد NAT بحيث يُمكِن توجيه الرُّزَم بشكل صحيح، ربّما تبدو هذه عمليّة صعبة، ولكنّها تُوضّح أيضًا مرونة إطار عمل ترشيح الرُّزَم netfilter وجدار iptables النّاري، يُمكِن استخدام هذا لتمويه بُنية الشبكة الخاصّة لدينا مع السمّاح بحركة مرور البيانات للخدمات بالمرور بشكل حر عبر بوّابة جهاز الجدار النّاري. ترجمة -وبتصرّف- لـ How To Forward Ports through a Linux Gateway with Iptables لصاحبه Justin Ellingwood.

تنفيذ جدار الحماية هو خطوة هامة في تأمين الخادوم الخاص بك. جزء كبير من عملية التنفيذ هو اتخاذ قرارات بشأن القواعد والسياسات التي تفرض قيودا على حركة مرور البيانات. يسمح لك الجدار الناري أن يكون لك دور في بنية إطار العمل الذي يتم فيه تطبيق القواعد الخاصة بك. في هذا الدليل سوف نبني جدار حماية ليكون أساسا للمزيد من القواعد المعقدة. وسيركز هذا الجدار الناري في المقام الأول على تقديم افتراضات معقولة ووضع إطار سهل التمدد. سيكون تطبيق هذا الدليل على أوبنتو 14.04. المتطلبات الأساسية قبل أن تبدأ يجب أن تكون لك فكرة قاعدية حول سياسات جدار الحماية التي ترغب في تنفيذها. يمكنك اتباع هذا الدليل للحصول على فكرة أفضل عن بعض الأشياء التي يجب أن تنظر فيها. سوف تحتاج إلى أن يكون لك حق الوصول إلى خادوم أوبنتو 14.04 بمستخدم عادٍ يكون له صلاحيات الجذر. تثبيت خدمة جدار الحماية الثابتة لكي نبدأ نحتاج إلى تثبيت الحزمة iptables-persistent إذا لم تكن قد فعلت ذلك من قبل. سيسمح هذا لنا بحفظ مجموعات القواعد ويجعل تنفيذها تلقائيا عند تشغيل النظام: sudo apt-get update sudo apt-get install iptables-persistent أثناء التثبيت سوف تُسأل عما إذا كنت تريد حفظ القواعد الحالية الخاصة بك، أجب بنعم. سوف نقوم بتحرير ملفات القواعد المولدة لاحقا. ملاحظة حول IPv6 قبل أن نبدأ يجب أن نتحدث بإيجاز عن عناوين IPv4 و IPv6. تعالج أوامر iptables فقط المرور عبر IPv4. وأما حركة المرور عبر IPv6 فيتم باستخدام أداة منفصلة تسمى ip6tables. يتم تخزين القواعد في جداول وسلاسل منفصلة. بالنسبة لـ iptables-persistent فتتم كتابة قواعد IPv4 في الملف etc/iptables/rules.v4/ وقواعد IPv6 في الملف etc/iptables/rules.v6/. يفترض هذا المقال أنك لا تستخدم البروتوكول IPv6 على الخادوم الخاص بك. إذا كان الأمر كذلك فالأكثر أمانا هو منع الوصول عبره تماما، وذلك ما سنقوم به في هذه الدليل. تنفيذ السياسات الأساسية لجدار الحماية (الطريق الأسرع) من أجل تنفيذ تلك السياسات على جدار الحماية في أسرع وقت ممكن سوف ندلك على ملف إعدادات يحتوي تلك السياسات، ثم ما عليك بعدُ إلا بالنسخ واللصق. بعد ذلك سوف نشرح الاستراتيجية العامة ونبين لك كيف يمكن تنفيذ هذه القواعد باستخدام أوامر iptables بدلا من تعديل الملف. لتنفيذ سياسات جدار الحماية وإطار العمل الخاص به سوف نقوم بتحرير الملفين etc/iptables/rules.v4/ و etc/iptables/rules.v6/. افتح أولا الملف rules.v4 في محرر النص المفضل لديك بصلاحيات الجذر: sudo nano /etc/iptables/rules.v4 سترى داخل هذا الملف مثل هذه الأسطر: # Generated by iptables-save v1.4.21 on Tue Jul 28 13:29:56 2015 *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] COMMIT # Completed on Tue Jul 28 13:29:56 2015 اُمحُ هذا المحتوى واستبدله بالمحتوى التالي: *filter # Allow all outgoing, but drop incoming and forwarding packets by default :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT ACCEPT [0:0] # Custom per-protocol chains :UDP - [0:0] :TCP - [0:0] :ICMP - [0:0] # Acceptable UDP traffic # Acceptable TCP traffic -A TCP -p tcp --dport 22 -j ACCEPT # Acceptable ICMP traffic # Boilerplate acceptance policy -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT -A INPUT -i lo -j ACCEPT # Drop invalid packets -A INPUT -m conntrack --ctstate INVALID -j DROP # Pass traffic to protocol-specific chains ## Only allow new connections (established and related should already be handled) ## For TCP, additionally only allow new SYN packets since that is the only valid ## method for establishing a new TCP connection -A INPUT -p udp -m conntrack --ctstate NEW -j UDP -A INPUT -p tcp --syn -m conntrack --ctstate NEW -j TCP -A INPUT -p icmp -m conntrack --ctstate NEW -j ICMP # Reject anything that's fallen through to this point ## Try to be protocol-specific w/ rejection message -A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable -A INPUT -p tcp -j REJECT --reject-with tcp-reset -A INPUT -j REJECT --reject-with icmp-proto-unreachable # Commit the changes COMMIT *raw :PREROUTING ACCEPT [0:0] :OUTPUT ACCEPT [0:0] COMMIT *nat :PREROUTING ACCEPT [0:0] :INPUT ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] COMMIT *security :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] COMMIT *mangle :PREROUTING ACCEPT [0:0] :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] COMMIT احفظ ثم أغلق الملف. يمكنك اختبار الملف من أجل اكتشاف الأخطاء التي يمكن أن تكون في التركيب بالأمر التالي: sudo iptables-restore -t /etc/iptables/rules.v4 يجب عليك إصلاح أي خطأ يظهر لك قبل المتابعة. بعد ذلك افتح الملف etc/iptables/rules.v6/ من أجل تعديل قواعد IPv6: sudo nano /etc/iptables/rules.v6 يمكننا أن نمنع كل الحزم التي تستخدم البروتوكول IPv6 باستبدال محتوى الملف بالإعدادات التالية: *filter :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT DROP [0:0] COMMIT *raw :PREROUTING DROP [0:0] :OUTPUT DROP [0:0] COMMIT *nat :PREROUTING DROP [0:0] :INPUT DROP [0:0] :OUTPUT DROP [0:0] :POSTROUTING DROP [0:0] COMMIT *security :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT DROP [0:0] COMMIT *mangle :PREROUTING DROP [0:0] :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT DROP [0:0] :POSTROUTING DROP [0:0] COMMIT احفظ ثم أغلق الملف. من أجل اختبار الملف ومعرفة إن كان فيه أخطاء نستعمل الأمر ip6tables-restore مع الخاصية t-: sudo ip6tables-restore -t /etc/iptables/rules.v6 إذا لم نجد أي خطأ في الملفين السابقين فلْنطبق تلك القواعد بتنفيذ الأمر: sudo service iptables-persistent reload سيقوم هذا الأمر بتنفيذ السياسات التي يتضمنها الملفان فورا. يمكنك التأكد من ذلك بسرد قواعد iptables الحالية بالأمرين: sudo iptables -S sudo ip6tables -S سوف يعاد تطبيق هذه القواعد في كل إقلاعٍ للنظام. تأكد أنه يمكنك الولوج عبر المنفذ 22 وأن كل المنافذ الأخرى محجوبة. شرح لاستراتيجيتنا العامة في الجدار الناري لقد أنشانا في جدار الحماية القاعدي الذي قمنا ببنائه مع القواعد السابقة أنشأنا إطارَ عمل قابلا للتمدد يمكّنك من إضافة قواعد جديدة أو حذفها بسهولة. أما حركة المرور التي تستخدم العنوان IPv4 فقد عالجناها في السلسلة INPUT داخل الجدول filter table ( تعالج هذه السلسلة كل الحزم التي تصل إلى خادومنا) فسمحنا بخروج الحزم من خادومنا ومنعنا إعادة توجيهها -إذ كان ذلك مناسبا فقط في حال كان الخادوم يعمل موجها router لخوادم أخرى- وقبِلنا الحزم على الجداول الأخرى بما أن نظرنا محصور في filter table في هذا الدليل. عموما تقوم القواعد التي طبقناها على الجدار الناري بمنع الحزم من الوصول إلى خادومنا افتراضيا ، سيكون علينا أن نضع استثناءات من أجل الحزم التي نريدها أن لا تدخل في سياسة الحجب. في السلسلة INPUT الرئيسة أضفنا بعض القواعد العامة لحركة المرور التي نثق بها. ما نريده الآن هو حجب كل الحزم التي نعتبرها غير صالحة ونسمح للحزم على واجهة الاسترجاع المحلية local loopback interface والبيانات المرتبطة باتصال مؤسس established connection. بعد ذلك نقوم بمسك البيانات حسب البروتوكول الذي تستخدمه ونمزجها بسلاسل البروتوكول المخصص protocol-specific. تهدف هذه السلاسل إلى التعامل مع القواعد المتعلقة بها والسماح لحركة المرور الصادرة والقادمة إلى الخدمات المعينة. في هذا المثال الخدمة الوحيدة التي قمنا بربطها في سلسلتنا ذات البروتوكول TCP هي SSH. إذا كنا نعرض خدمة أخرى كخادوم (HTTP(S يمكننا إضافة استثناءات لها أيضا. كل حركةٍ للمرور لا تتناسب مع القواعد العامة أو قواعد الخدمات في البروتوكول المحدد protocol-specific سوف تتم معالجتها بالقواعد الموجودة في آخر سلسلة INPUT. لقد جعلنا السياسة الافتراضية للجدار الناري هي الإسقاط DROP، وذلك سيحجب الحزم التي لا تتصف بمعايير السماح حسب قواعدنا. تمنع هذه القواعد في نهاية السلسلة INPUT الحزم وترسل رسالة إلى العميل تحاكي ما يرسله الخادوم في حالِ لم تكن الخدمة متوفرة على ذلك المنفذ. وأما العنوان IPv6 فإن حركة المرور سوف تُحجَب كلها لأن خادومنا لا يستخدمه، ولأنه من الآمن فعل ذلك لكي لا نتورط في حركة المرور بشكل عام. تحديث nameservers (اختياري) يمكن لحركة المرور المحجوبة على العنوان IPv6 أن تتداخل وطريقةُ تعامل الخادوم مع الأشياء في الأنترنت. مثلا يمكن لذلك أن يؤثر في استخدام الأمر APT. إذا ظهر لك خطأ مثل هذا في حال نفذت الأمر apt-get update: Err http://security.ubuntu.com trusty-security InRelease Err http://security.ubuntu.com trusty-security Release.gpg Could not resolve 'security.ubuntu.com' . . . فينبغي عليك أن تتبع هذه الطريقة لكي تجعل APT يعمل مرة أخرى. أولا اضبط nameservers الخاصة بخادومك إلى nameservers الخارجية، سنستخدم في حالتنا nameservers الخاصة بغوغل. افتح الملف etc/network/interfaces/ من أجل تعديله بالأمر: sudo nano /etc/network/interfaces ثم عدل السطر الذي أوله dns-nameservers على الطريقة التالية: . . . iface eth0 inet6 static address 2604:A880:0800:0010:0000:0000:00B2:0001 netmask 64 gateway 2604:A880:0800:0010:0000:0000:0000:0001 autoconf 0 dns-nameservers 8.8.8.8 8.8.4.4 حدّث إعدادات الشبكة بالأمر: sudo ifdown eth0 && sudo ifup eth0 الناتج المتوقع هو: RTNETLINK answers: No such process Waiting for DAD... Done بعد ذلك أنشئ قاعدة جديدة من أجل إرغام حركة المرور أن تستخدم العنوان IPv4 متى كان ذلك ممكنا. أنشئ هذا الملف الجديد: sudo nano /etc/apt/apt.conf.d/99force-ipv4 ثم أضف هذا السطر إليه: Acquire::ForceIPv4 "true"; احفظ ثم أغلق، ينبغي أن تكون الآن قادرا على استخدام ATP. تنفيذ الجدار الناري باستخدام أوامر IPTables لقد تبين لك كيف قمنا بتنفيذ الجدار الناري وسياساته وعرفت كيف تعمل، في المرحلة القادمة سنقوم بتطبيق تلك السياسات باستخدام أوامر iptables وسنحصل في الأخير على ما حصلنا عليه فيما سبق. ولكن سيكون إضافة تلك السياسات واحدة تلو الأخرى لأن iptables يطبق كل قاعدة في وقت تنفيذ الأمر ، لذلك فإن ترتيب القواعد مهم جدا (سوف ندع القواعد التي تحجب إلى النهاية). إعادة ضبط الجدار الناري سنبدأ بإعادة ضبط الجدار الناري لكي نستطيع بناء السياسات من سطر الأوامر . يمكنك إلغاء القواعد السابقة بالأمر: sudo service iptables-persistent flush تأكد أن الجدار الناري أعيد ضبطه بالأمر: sudo iptables -S سترى أن القواعد في الجدول filter table قد اختفت وأن السياسات الافتراضية قد أُعدت للوضع ACCEPT في كل السلاسل: -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT إنشاء سلاسل البروتوكول المخصص سنبدأ بإنشاء سلاسل البروتوكول المخصص protocol-specific. ستُستعمل هذه السلاسل للتحكم في القواعد التي تُنشِئ استثناءات في سياسات الحجب فتجعل خدماتنا ظاهرة في الشبكة. سوف ننشئ واحدة من أجل البروتوكول UDP ، واحدة للبروتوكول TCP وواحدة للبروتوكول ICMP: sudo iptables -N UDP sudo iptables -N TCP sudo iptables -N ICMP يمكننا الذهاب قدما فنضيف استثناء للخدمة SSH التي تستخدم البروتوكول TCP. سيكون ذلك بقبول حركة المرور على المنفذ 22 الخاص بالخدمة SSH: sudo iptables -A TCP -p tcp --dport 22 -j ACCEPT إذا كنت تريد إضافة استثناءات لخدمات أخرى تستخدم البروتوكول TCP فما عليك سوى تكرار الأمر السابق مع تغيير رقم المنفذ الذي تستخدمه الخدمة. إنشاء قواعد للأغراض العامة للحجب والقبول في السلسلة INPUT -حيث تفلتر كل الحزم القادمة- نحتاج إلى إضافة قواعد للأغراض العامة. تشكل تلك القواعد حجر الأساس للجدار الناري وتتبع المنطق السليم إذ تقبل حركة المرور الأقل خطورة (حركة المرور المحلية أو التي تأكدنا من موثوقية مصدرها) وتحجب تلك الموصوفة بأنها غير صالحة. أولا سننشئ استثناء لكي نقبل كل الحزم التي هي جزء من اتصال مؤسَّس established connection أو لها علاقة باتصال مؤسس: sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT تستخدم هذه القاعدة الملحق conntrack الذي يقدم سياقا يحتاج إليه iptables لمعالجة حزم الاتصالات الكبيرة بدل استخدامه للبيانات المنفصلة. TCP هو بروتوكول اتصال ، لذلك فإن كونه اتصالا مؤسَّسا لا غبار عليه. وأما UDP والبروتوكولات عديمة الاتصال فالاتصال المؤسس يشير إلى الحزم التي ترى جوابها (مصدر الحزمة هو نفسه الهدف المقصود والعكس بالعكس ). وأما الاتصالات ذات الصلة فتشير إلى اتصال جديد يُربط مع اتصال مؤسس. المثال الكلاسيكي هنا هو اتصال نقل البيانات ftp، حيث يربط هذا الاتصال الجديد بالاتصال المؤسس سابقا وهو FTP control connection. نريد أيضا أن نسمح لحركة المرور التي نشأت على واجهة الاسترجاع المحلية local loopback interface. هذه الحزم وُلّدت من قبل الخادوم ومتجهة إلى الخادوم نفسه. يتم استخدامها من قبل الخدمات على جهاز النظام للتواصل مع بعضها البعض: sudo iptables -A INPUT -i lo -j ACCEPT وأخيرا نريد حجب كل الحزم غير الصالحة. تكون الحزم غير صالحة للعديد من الأسباب. منها التي تكون وجهتها اتصالات أو عناوين أو منافذ غير موجودة، أو ببساطة لم يَحسُن تهيئتها. في كل الأحوال سوف نمنع أمثال هذه الحزم لأنه لا سبيل إلى معالجتها أو لأنها مغلفة لشيفرات خبيثة: sudo iptables -A INPUT -m conntrack --ctstate INVALID -j DROP إنشاء الانتقال السريع إلى سلاسل البروتوكول المخصص حتى الآن لقد أنشأنا بعض القواعد العامة في سلسلة INPUT وبعض القواعد للخدمات المقبولة في سلاسل البروتوكول المخصص. ومع ذلك فالبيانات القادمة إلى السلسلة INPUT ليس لديها وسيلة للوصول إلى تلك السلاسل. نحن بحاجة إلى توجيه حركة البيانات في سلسلة INPUT إلى سلاسل البروتوكول المخصص التي تناسبها. يمكننا البحث عن نوع البروتوكول لكي نعرف أي سلسلة تناسب هذه الحزمة. ويجب التأكد من أن الحزمة تمثل اتصالا جديدا (يفترض أنه تم بالفعل التعامل مع أي اتصال مؤسس أو له علاقة به). بالنسبة لحزم TCP سوف نقوم بإضافة شرط إضافي وهو أن تكون الحزمة SYN، والذي هو النوع الوحيد الصالح لبدء اتصال TCP: sudo iptables -A INPUT -p udp -m conntrack --ctstate NEW -j UDP sudo iptables -A INPUT -p tcp --syn -m conntrack --ctstate NEW -j TCP sudo iptables -A INPUT -p icmp -m conntrack --ctstate NEW -j ICMP رفض كل حركة المرور الأخرى إذا كانت الحزمة التي تم تمريرها الى سلسلة البروتوكول المخصص لم تعثر على أية قواعد فسيتم إعادة التحكم بها إلى السلسة INPUT. ما يصل إلى هذا النقطة ينبغي أن لا يسمح به جدار الحماية. سوف نحجب حركة المرور باستخدام الهدف REJECT الذي يرسل رسالة رد إلى العميل. و يتيح هذا لنا تحديد الرسائل الصادرة حتى نتمكن من محاكاة الرد كما لو كان العميل حاول إرسال الحزم إلى المنافذ المغلقة. يكون الرد حسب البروتوكول الذي يتم استخدامه من قبل العميل. محاولة الوصول إلى منفذ UDP المغلق يؤدي إلى رسالة ICMP مضمونها "لا يمكن الوصول إلى المنفذ” ، يمكننا محاكاة ذلك بتنفيذ الأمر: sudo iptables -A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable محاولة إنشاء اتصال TCP على منفذ مغلق سيؤدي إلى جواب TCP RST: sudo iptables -A INPUT -p tcp -j REJECT --reject-with tcp-reset وأما جميع الحزم الأخرى فيمكننا إرسال رسالة ICMP "تعذر الوصول إلى البروتوكول" للإشارة إلى أن الخادوم لا يرد على حزم من هذا النوع: sudo iptables -A INPUT -j REJECT --reject-with icmp-proto-unreachable ضبط السياسات الافتراضية آخر ثلاث قواعد أضفناها ينبغي أن تتعامل مع جميع ما تبقى من حركة البيانات في السلسلة INPUT. ومع ذلك ينبغي لنا أن ننشئ السياسات الافتراضية للإسقاطـ DROP كإجراء احترازي. وينبغي أيضا أن تُحدد هذه السياسة في سلسلة FORWARD إذا لم يتم استخدام هذا الخادوم جهازَ توجيه إلى أجهرة أخرى: sudo iptables -P INPUT DROP sudo iptables -P FORWARD DROP تحذير مع إعدادك لسياسات الجدار الناري إلى DROP يكون استعمالك للأمر sudo iptables -F لغرض مسح iptables مسقطا لاتصال SSH الحالي ، الأحسن من ذلك أن تقوم بمسحه بالأمر sudo iptables-persistent flush، لأن ذلك سيعيد ضبط الجدار النار إلى الحال الفتراضي. ولكى نجعل سياسة IPv6 هي إسقاط كل حركةٍ للمرور يمكننا تنفيذ الأوامر التالية: sudo ip6tables -P INPUT DROP sudo ip6tables -P FORWARD DROP sudo ip6tables -P OUTPUT DROP ينبغي لهذه الأوامر أن تكرر القواعد التي أعددناها سابقا بشكل موثوق. حفظ قواعد IPTables في هذه المرحلة يجب فحص قواعد جدار الحماية للتأكد من أنها تمنع حركة المرور التي تريد منعها وتسمح لما تريد السماح له. عندما تكون متأكدا من أن الجدار الناري والقواعد يعملان بشكل صحيح يمكنك حفظ تلك القواعد ليتم تطبيقها عند كل إقلاع للنظام. يمكنك حفظ قواعد كل من IPv4 و IPv6 بتنفيذ الأمر: sudo service iptables-persistent save سيقوم هذا الأمر بالكاتبة فوق الملفين etc/iptables/rules.v4/ و etc/iptables/rules.v6/ بالسياسات التي نفذتها من خلال سطر الأوامر. الخلاصة باتباعك هذا الدليل -سواء من خلال وضع قواعد جدار الحماية مباشرة في ملفات الإعدادات أو يدويا باستخدام سطر الأوامر - قمتَ بإنشاء منطلق جيد لإعدادات الجدار الناري. يبقى عليك أن تضيف قواعد خاصة بك لتسمح بالوصول إلى خدماتك الأخرى على الخادوم. يسمح لك إطار العمل الذي أسسناه في هذا الدليل بأن تعدل كيفما تشاء ، وأيضا يجعل السياسات الموجودة أكثر وضوحا. ترجمة -وبتصرّف- للمقال How To Implement a Basic Firewall Template with Iptables on Ubuntu 14.04 لصاحبه Justin Ellingwood.

ينصبّ الاهتمام عند إعداد بنية تحتيّة 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.

إعداد جدارٍ ناريّ قوي هو خطوةٌ أساسية يجب فعلها بهدف تأمين أيّ نظام تشغيلٍ حديث. تأتي معظم توزيعات لينكس بأدواتٍ مختلفة يمكننا استخدامها لضبط جداراتنا الناريّة. في هذا الدرس، سنتحدّث عن جدار iptables الناريّ. Iptables هو عبارة عن جدارٍ ناريّ عادي موجود في معظم توزيعات لينكس افتراضيًا (برنامجٌ آخر يدعى nftables سيبدأ قريبًا باستبداله). هو في الواقع عبارة عن واجهةٍ أمامية لخطّافات netfilter على مستوى النواة (kernel-level netfilter hooks) يمكنه التعامل مع مكدّس شبكة لينكس (Linux network stack). يعمل iptables عن طريق مطابقة كلّ حزمة (packet) تمرّ عبر الشبكة بمجموعة من القواعد (rules) التي تجعله يقرر ما يجب فعله. ملاحظة: يغطّي هذا الدرس أساسيات الحماية لـIPv4. في نظام لينكس، هناك فرق بين طرق الحماية لـIPv4 و IPv6. كمثال فإنّ iptables يقوم فقط بالتحكّم في قواعد جدار الحماية لعناوين IPv4 إلّا أنّه يمتلك برنامجًا خارجيًا يدعى ip6tables يمكن استخدامه للتحكّم في قواعد جدار الحماية لعناوين IPv6. إذا كان خادومك الافتراضي الخاصّ مُعدًّا ليستخدم IPv6، فرجاءً تذكّر حماية كلّ من واجهتيّ الشبكة IPv4 و IPv6 باستخدام الأدوات المناسبة. للمزيد من المعلومات عن أدوات IPv6، راجع هذا الدرس: كيفية ضبط بعض الأدوات لاستخدام IPv6 على نظام لينكس. أوامر iptables الأساسية الآن وبعد أن صار لديك المفاهيم الأساسية حول iptables، فإنّه يجب علينا تغطية الأوامر الأساسية التي سيتم استعمالها لتشكيل مجموعات قواعد iptables أكبر بالإضافة إلى إدارة واجهة iptables بشكلٍ عام. أولًا، يجب عليك أن تنتبه إلى أنّ أوامر iptables يجب أن يتم تشغيلها بصلاحيات الجذر (root privileges). هذا يعني أنّه يجب عليك الولوج إلى النظام باسم المستخدم root، استخدم su أو sudo -i للولوج إلى صدفة المستخدم الجذر، أو يمكنك ببساطة وضع sudo قبل جميع الأوامر التي ستطبّقها. سنستخدم sudo في هذا الدرس بما أنّها طريقة شائعة الاستخدام على نظام Ubuntu. نقطة جيدة للبداية بها هي كيفية سرد قواعد iptables المُستخدمة حاليًا. يمكنك فعل هذا باستخدام الخيار -L : $ sudo iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination كما يمكنك أن ترى، لدينا ثلاث سلاسل (chains) هنا. يمكننا أيضًا أن نرى السياسة المتّبعة في كلّ سلسلة (كل سلسلة افتراضيًا تمتلك سياسة ACCEPT للاتصالات المارّة منها). يمكننا أيضًا رؤية بعض ترويسات العواميد في ناتج الأمر السابق، إلّا أنّنا فعليًا لا نرى أيّ قواعد مطبّقة. هذا بسبب أنّ Ubuntu لا تأتي مع مجموعةٍ افتراضية من قواعد iptables. يمكننا رؤية الخرج بصيغةٍ تعكس الأوامر الضرورية لتفعيل كلّ قاعدة وسياستها عبر استخدام الخيار -S : $ sudo iptables -S -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT لإعادة إنتاج الإعدادات وتطبيقها من جديد، سيجب علينا فقط كتابة الأمر sudo iptables متبوعًا بكلّ واحدٍ من السطور الظاهرة في الخرج. (اعتمادًا على الإعدادات، قد يكون الأمر أكثر تعقيدًا في حال كنّا متّصلين عن بعد إلى الخادوم حيث أننا لا نريد إضافة قواعد iptables معيّنة تمنع جميع الاتصالات الواردة إليها مثلًا دون استثناء اتّصالنا الحالي لكي لا ينقطع فجأة ولكي يبقى متّصلًا). إذا كان لديك قواعد بالفعل لديك في iptables وكنتَ ترغب بإتلافها والبدء من جديد، فيمكنك فعل ذلك عبر تطبيق: $ sudo iptables -F مرةً أخرى، سياسة قبول الاتصالات أو رفضها مهمّة هنا، لأنّه وبينما يتم حذف جميع القواعد الأخرى من السلاسل الخاصّة بك، فإنّ السياسة الافتراضية لن تتغيّر باستخدام هذا الأمر. هذا يعني أنّه في حال كنت متّصلًا عن بعد بخادومك، فإنّه يجب عليك التأكّد من أنّ السياسة الافتراضية لسلسلتيّ INPUT و OUTPUT هي ACCEPT بالتزامن مع قيامك بإتلاف قواعدك السابقة. يمكنك فعل ذلك عبر تطبيق الأوامر التاليّة: $ sudo iptables -P INPUT ACCEPT $ sudo iptables -P OUTPUT ACCEPT $ sudo iptables -F يمكنك تغيير سياسة الحظر أو الترك (drop) مجددًا إلى DROP بعد أن تقوم بإعداد القواعد التي تسمح ببقاء اتّصالك الحالي. سنفصّل كيفيّة ذلك بعد قليل. إنشاء قاعدتك الأولى سنبدأ ببناء سياسة جدار الحماية الخاصّ بن حول قبول أو رفض الاتصالات. كما قلنا أعلاه، فإنّنا سنعمل مع سلسلة INPUT بما أنّها المصدر الرئيسي لتدفّق الزوار القادم إلى خادومنا. سنبدأ مع القاعدة التي تحدّثنا عنها مسبقًا من قبل بالأعلى: القاعدة التي تسمح لنا بشكل خاص بمتابعة اتّصال SSH الحالي. القاعدة الكاملة التي نحتاج إليها هي هذه: $ sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT قد يبدو هذا معقّدا للغاية لك في الوهلة الأولى، إلّا أنّ معظم مكوّنات الأمر السابق ستكون ذات معنى بالنسبة لك عندما تفهمها: -A INPUT: يقوم الخيار -A بإضافة قاعدةٍ ما إلى نهاية السلسلة المطلوبة. هذا هو الجزء الذي يقوم بإخبار iptables بأنّنا نريد إضافة قاعدةٍ جديدة إلى سلسلة معيّنة، والسلسلة التي نريدها في مثالنا حاليًا هي سلسلة INPUT. -m conntrack: يمتلك iptables عدّة وظائف داخليّة، ولكنّه أيضًا يمتلك مجموعةً من الامتدادات والوحدات التي تقوم بتوفير مزايا إضافيّة. إنّنا نقوم في هذا الجزء من الأمر بإخبار iptables بأنّنا نريد الحصول على إذن بالوصول إلى الوظيفة التي يتم توفيرها عبر الوحدة المسماة "conntrack”. تعطينا هذه الوحدة وصولًا إلى الأوامر التي يمكن أن يتم استخدامها بناءً على علاقة حزمة البيانات الداخلة بالاتّصال السابق. --ctstate: هذا واحدٌ من الأوامر التي أصبحت متوفّرة بعد أن تم استدعاء وحدة "conntrack”. يسمح لنا هذا الأمر بمطابقة حزم البيانات بناءً على ماهيّة ارتباطها بحزم البيانات التي رأيناها من قبل. إننا نقوم بتمرير قيمة ESTABLISHED للسماح بمرور حزم البيانات الداخلة التي هي جزء من اتّصالٍ عاملٍ حاليًا فقط. ونقوم بتمرير قيمة RELATED للسماح بمرور حزم البيانات المرتبطة باتّصالٍ مُنشَئٍ بالفعل. هذا الجزء من القاعدة هو الجزء الذي يتطابق مع جلسة SSH الحالية الخاصّة بنا. -j ACCEPT: يقوم هذا الخيار بتحديد هدف مطابقة حزم البيانات. هنا، نقوم بإخبار iptables أنّ حزم البيانات التي تطابق القاعدة السابقة يجب أن يتم السماح لها بالمرور. قمنا بوضع هذه القاعدة في البداية لأننا أردنا أن نتأكّد أنّ اتصالنا الحالي مطابق، مقبول وخارج إطار السلسلة قبل تنفيذ أيّ قواعد DROP. يمكننا الآن رؤية حالة التغييرات التي قمنا بها عن طريق: $ sudo iptables -L Chain INPUT (policy ACCEPT) target prot opt source destination ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination الآن وبعد أن صرتَ تعرف الصياغة العامّة لقواعد iptables، فلنتابع عبر استعراض المزيد من الحالات التي سنحتاج فيها إلى قبول الاتّصالات. قبول الاتّصالات المهمّة الأخرى أخبرنا iptables أن يبقي أيّ اتصالاتٍ مفتوحة على وضعها الحالي بالإضافة إلى السماح بالاتصالات الجديدة المرتبطة بتلك الاتصالات. على كلّ حال، نحتاج إلى إنشاء بعض القواعد الضرورية لتحديد متى نريد قبول اتّصالاتٍ جديدة لا تطابق هذه المعايير التي طبّقناها. نريد إبقاء منفذين اثنين مفتوحين بالتحديد. نريد إبقاء منفذ اتّصال SSH الخاصّ بنا مفتوحًا (سنفترض في هذا الدرس أنّ المنفذ الافتراضي له هو المنفذ 22. إذا كنتَ غيّرت هذا المنفذ على خادومك من إعدادات SSH فقم بتعديل قيمته هنا). سنقوم أيضًا بافتراض أنّ هذا الحاسوب يقوم أيضًا بتشغيل خادوم ويب يعمل على المنفذ 80. إذا لم يكن هذا هو نفس الوضع بالنسبة لك فلن تحتاج تطبيق القاعدة التالية. السطران اللذان سنستعملهما لتطبيق هذه القواعد هما: sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT كما يمكنك أن ترى، هذه القواعد مشابهة جدًا لقاعدتنا الأولى التي كتبناها، ولكنها ربما تكون أكثر بساطةً. الخيارات الجديدة هي: -p tcp: يقوم هذا الخيار بمطابقة حزم البيانات في حال كان البروتوكول المستخدم هو TCP. هذا البروتوكول هو بروتوكولٌ مستخدم بواسطة معظم التطبيقات لأنّه يسمح بتواصلٌ مرن وقوي بين المستخدم والتطبيق. --dport: يكون هذا الخيار متوفّرًا للاستخدام فقط في حال كان الخيار -p tcp موجودًا في الأمر. إنّه يقوم أيضًا بتحديد رقم المنفذ الذي يجب مطابقة حزم البيانات عبره. تقوم القاعدة الأولى بمطابقة حزم البيانات المارّة عبر بروتوكول TCP بالمنفذ 22، بينما تقوم الثانية بمطابقتها عبر المنفذ 80. هناك قاعدة ACCEPT أخرى يجب علينا التأكّد من أنّ خادومنا يقبلها بشكل صحيح. غالبًا، تتواصل الخدمات (services) مع بعضها البعض على الحاسوب عبر إرسال حزم بياناتٍ فيما بينها، وهي تقوم بذلك عبر الاستفادة من واجهة شبكةٍ زائفة تدعى loopback device ، والتي تقوم بتوجيه التدفّق إلى نفسها عوضًا عن الأجهزة الأخرى. لذا إذا كانت واحدة من الخدمات تريد التواصل مع خدمةٍ أخرى تستمع إلى المنفذ 4555، فإنّه بمقدورها إرسال حزمة بيانات إلى المنفذ 4555 على الشبكة الزائفة loopback device. نريد أن يتم السماح بهذا النوع من السلوك بين الخدمات لأنّه ضروري للعديد من برامج نظام التشغيل. القاعدة التي نحتاج تطبيقها هي هذه: $ sudo iptables -I INPUT 1 -i lo -j ACCEPT يبدو هذا الأمر مختلفًا قليلًا عن الأوامر السابقة. فلنشرح ما يفعله: -I INPUT 1: يقوم الخيار -I بإخبار iptables بإدراج قاعدةٍ جديدة. هذا الخيار مختلف عن الخيار -A والذي يقوم بإضافة القاعدة الجديدة إلى نهاية قواعد iptables. يحتاج الخيار -I إلى اسم السلسلة والمكان الذي تريد إدراج القاعدة الجديدة فيه. في حالتنا، فإننا نقوم بإضافة هذه القاعدة كأول قاعدة في سلسلة INPUT. هذا سيدفع بقية القواعد إلى الأسفل بدرجةٍ واحدة تلقائيًا. نحتاج لهذه القاعدة أن تكون بالأعلى لأنّها أساسية ولا يجب أن يتم التأثير عليها عبر قواعد فرعيّة أخرى. -i lo: يقوم هذا المكوّن من القاعدة بمطابقة ما إذا كانت الواجهة التي تستخدمها حزمة البيانات هي واجهة "lo”. واجهة "lo” هي عبارة عن اسمٍ آخر لـloopback device. هذا يعني أنّ أيّ حزمةِ بياناتٍ تستعمل تلك الواجهة الشبكيّة للتواصل (حزم البيانات الناتجة في خادومنا، إلى خادومنا) يجب أن يتم قبولها من طرف iptables. لرؤية قواعدنا الحاليّة، يجب أن نستخدم الخيار -a . هذا بسبب أنّ الخيار -L لا يتضمّن بعض المعلومات، مثل اسم الواجهة المرتبطة بالقواعد، والذي يعتبر جزءًا مهمًّا في القاعدة التي قمنا بإضافتها: $ 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 22 -j ACCEPT -A INPUT -p tcp -m tcp --dport 80 -j ACCEPT تضمين قاعدة حظر (Drop) نمتلك الآن 4 قواعد منفصلة تقبل الاتصالات بناءً على معايير معيّنة. وبالرغم من ذلك، فإنّا خادومنا حاليًا لا يحظر وصول أيّ شيء إليه. إذا دخلت حزمة بياناتٍ إلى سلسلة INPUT ولم تكن مطابقة لأيٍّ من القواعد الأربعة التي أدخلناها، فإنّه سيتم تحويلها إلى السياسة الافتراضية للتعامل مع حزم البيانات، والتي هي حاليًا "قبول حزم البيانات جميعها"، ونحتاج لتغيير هذا الأمر. هناك طريقتان يمكننا فعل ذلك بهما، مع بعض الاختلافات الجوهرية. الطريقة الأولى التي يمكننا من خلالها القيام بهذا هي عن طريق تعديل السياسة الافتراضية لسلسلة INPUT. يمكننا القيام بذلك عبر كتابة: $ sudo iptables -P INPUT DROP ستقوم القاعدة السابقة بالتقاط أيّ حزم بياناتٍ تفشل بالمرور عبر سلسلة INPUT الخاصّة بنا ويمنع وصولها إلى الخادوم. هذا ما ندعوه بسياسة المنع الافتراضيّة (default drop policy)، من مساوئ هذه الطريقة هي أنّ قاعدة الـDROP هذه يتم إلغاؤها في حال تم مسح قواعد iptables (حيث أنّها قاعدة هي الأخرى وبالتالي سيتم مسحها معها). قد تكون هذه الطريقة أكثر أمنًا، ولكنك قد تواجه عواقب وخيمة في حال لم يكن لديك طريقةٌ أخرى للوصول إلى خادومك. في DigitalOcean، يمكنك الولوج عبر لوحة التحكّم إلى خادومك والوصول إلى طرفيّة ويب تمكّنك من التحكّم به إذا حصل هذا. طرفيّة الويب هذه تعرّف نفسها على أنّها اتصال وهمي محلّي ولذلك فإنّ قواعد iptables لا تؤثّر عليها. قد تودّ لخادومك أن يقوم بحظر جميع الاتصالات في حال مسح جميع القواعد. قد يمنع هذا من ترك خادومك مفتوحًا للجميع. وهذا يعني أيضًا أنّه بمقدورك بسهولة إضافة القواعد إلى نهاية أيّ سلسلة تريدها بينما تحظر حزم البيانات التي لا تريدها بسهولة. إذا قمتَ بتغيير السياسة الافتراضيّة لسلسلة INPUT، فإنّه يمكنك إرجاعها عبر تطبيق: $ sudo iptables -P INPUT ACCEPT الآن، يمكنك إضافة قاعدة إلى نهاية السلسلة والتي ستقوم بحظر أيّ حزم بياناتٍ متبقية: $ sudo iptables -A INPUT -j DROP النتائج تحت شروطٍ تشغيلية عادية ستكون بالضبط هي نفس سياسة الحظر الافتراضيّة. تعمل هذه القاعدة عبر مطابقة كلّ حزمة بياناتٍ متبقية تصل إليها. يمنع هذا حزمةَ البيانات من الوصول إلى الخادوم في حال فشلت بتجاوز القواعد السابقة التي قمنا بإنشائها. بشكلٍ عام، يتم استخدام هذه القاعدة لجعل السياسة الافتراضيّة في التعامل مع الاتصالات تقبل التدفّق الواصل إليها. بهذه الطريقة، في حال كان هناك أيّ مشاكل وتم مسح جميع القواعد، فإنّك ستبقى قادرًا على الوصول إلى الآلة عبر الشبكة. بالطبع، هذا يعني أيضًا أنّ أيّ قاعدةٍ إضافية تودّ إضافتها إلى نهاية السلسلة يجب أن تكون قبل قاعدة الحظر أو الـdrop. يمكنك فعل هذا عبر حذف قاعدة الحظر مؤقتًا عبر: $ sudo iptables -D INPUT -j DROP $ sudo iptables -A INPUT new_rule_here $ sudo iptables -A INPUT -j DROP أو، يمكنك إدراج القواعد التي تحتاجها في نهاية السلسلة (ولكن قبل قاعدة الـdrop) عبر تحديد رقم السطر. لإدراج قاعدةٍ في السطر رقم 4، يمكنك كتابة: $ sudo iptables -I INPUT 4 new_rule_here إذا كنتَ تواجه مشاكل في معرفة إلى أيّ سطرٍ تنتمي أيّ قاعدة، فيمكنك إخبار iptables بأن يقوم بسرد السطور المتوفّرة عبر: $ sudo iptables -L –line-numbers Chain INPUT (policy DROP) num target prot opt source destination 1 ACCEPT all -- anywhere anywhere 2 ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED 3 ACCEPT tcp -- anywhere anywhere tcp dpt:ssh 4 ACCEPT tcp -- anywhere anywhere tcp dpt:http Chain FORWARD (policy ACCEPT) num target prot opt source destination Chain OUTPUT (policy ACCEPT) num target prot opt source destination يمكن لهذا أن يكون مفيدًا للتأكّد من أنّك تضيف القاعدة إلى مكانها الصحيح. حفظ إعدادات iptables الخاصّة بك افتراضيًا، تكون القواعد التي تضيفها إلى iptables غير دائمة. هذا يعني أنّك عندما تقوم بإعادة تشغيل خادومك، فإنّ جميع قواعد iptables ستختفي. هذه المشكلة في الواقع هي ميّزة لبعض المستخدمين لأنّها تعطيهم فرصةً للعودة إلى التحكّم بالخادوم في حال قاموا بحبس أنفسهم خارجها عن طريق الخطأ في تطبيق القواعد. وعلى كلّ حال، معظم المستخدمين سيودّون أن يكون هناك طريقة تلقائية لحفظ القواعد التي أنشؤوها وتحميلها تلقائيًا عند إقلاع الخادوم. هناك عدّة طرق لفعل هذا، لكنّ أسهلها هو باستخدام حزمة iptables-presistent، يمكنك تحميل هذه الحزمة من مستودعات Ubuntu الافتراضيّة: $ sudo apt-get update $ sudo apt-get install iptables-persistent أثناء التثبيت، سيتم سؤالك عمّا إذا كنتَ تحبّ حفظ قواعد iptables الحاليّة ليتم تحميلها تلقائيًا. إذا كنتَ مسرورًا مع إعداداتك الحاليّة (واختبرت قدرتك على الوصول إلى اتصالات SSH جديدة مستقلة) فإنّه يمكنك الموافقة على ذلك. سيتم سؤالك أيضًا عمّا إذا كنتَ تريد حفظ قواعد IPv6 التي قمتَ بإعدادها، يتم إعداد هذه القواعد عبر أداة منفصلة تدعى ip6tables والتي تتحكم بحزم بيانات IPv6 بنفس الطريقة. بمجرّد اكتمال التثبيت، ستتوفر خدمة جديدة لديك تدعى iptables-presistent وهي مُعدّة ليتم تشغيلها عند الإقلاع. ستقوم هذه الخدمة بتحميل قواعد iptables الحاليّة وتطبيقها من جديد في كلّ مرّة يتم إعادة تشغيل النظام فيها. الخاتمة يجب أن تكون الآن قد امتلكت نقطة بداية جيّدة للبدء في تطوير جدارٍ ناري يلبي احتياجاتك. هناك العديد من أدوات الجدران الناريّة الأخرى التي يمكنك استخدامها والتي قد تكون أسهل، ولكن iptables أداةٌ جيّدة لتعلّمها، ذلك لأنّها توفّر بنية netfilter تحتية جيّدة للاستعمال ولأنّها متوفّرة افتراضيًا في العديد من أنظمة التشغيل. ترجمة -وبتصرّف- للمقال: How To Set Up a Firewall Using IPTables on Ubuntu 14.04.

سنتطرق في هذا الدّرس إلى كيفية تطبيق حماية أساسيّة لخادوم Redis. على الرغم من هذا، عليك تذكر بأن Redis قد صُمّم أساسا للاستخدام من طرف مستخدمين موثوقين على بيئة موثوقة، بدون أي مميزات أمنيّة خاصة به. لفهم هذه النّقطة أكثر إليك اقتباسا من الموقع الرسمي لـredis: بشكل عام، Redis ليس مُحسّنا لحماية قصوى بل لأداء عالي وبساطة فائقة. الأداء والبساطة بلا حماية بمثابة وصفة لكارثة. حتى مميّزات الحماية القليلة لدى Redis ليست ممتازة، وتشمل كلمة مرور بسيطة غير مُشفّرة، إعادة تسميّة الأوامر وتعطيلها. وتفتقر إلى نظام حقيقي للتحكم بالولوج. على الرغم من هذا، فإن ضبط هذه الخصائص الأمنيّة يبقى خطوة كبيرة إلى الأمام وأفضل من ترك قاعدة بياناتك بدون حماية. ستقرأ في هذا الدّرس كيفيّة ضبط الخصائص الأمنيّة القليلة التي يمتلكها Redis، وبعض الخصائص الأمنية الأخرى للنظام ما سيزيد من نسبة الحماية لخادوم Redis مُستقل على Ubuntu 14.04. ننوّه إلى أن هذا الدرس لا يتحدث عن حالات وجود كل من خادوم Redis وتطبيقات العملاء على استضافات مختلفة أو مراكز بيانات مختلفة. أو الحالات التي يجب على الاتصال بـ Redis أن يقطع شبكات غير آمنة أو غير موثوقة تتطلب نوعا مختلفا من الإعداد، مثل ضبط SSL proxy أو VPN بين خواديم Redis ، إضافة إلى الخطوات المذكورة هنا. المتطلبات ستحتاج في هذا الدّرس: خادوم Ubuntu مع مستخدم sudo مُضَاف، انظر درس الإعداد الابتدائي لخادوم أوبنتو 14.04 جدار ناري iptables معدّ باستخدام الدرس كيف تنفذ نموذجا للجدار الناري باستعمال Iptables إلى غاية خطوة "تحديث nameservers" (إذا لم تقم بإعداد جزء الخادوم nameserver فالـAPT لن يعمل). Redis مُثبت وقيد التنفيذ باستعمال الخطوات في الموضحة في الدرس كيفية تنصيب واستخدام Redis على أوبنتو. الخطوة الأولى، التأكد من أن Redis قيد التشغيل أولاً ادخل إلى الخادوم باستعمال SSH: ssh username@server-ip-address username: اسم المستخدم server-ip-address: عنوان IP الخاص بالخادوم للتأكد من أنّ Redis قيد التنفيذ، استعمل سطر الأوامر الخاص ب Redis .يُستعمل الأمر redis-cli للوصول إلى سطر أوامر Redis. redis-cli إذا سبق وأن أعددت كلمة مرور لـ Redis، فيجب عليك الاستيثاق بالأمر auth بعد الاتّصال: auth كلمة_المرور المخرج سيكون كلمة OK اختبر خادوم قاعدة البيانات: ping الرّد: PONG اُخرج: quit الخطوة الثانية، حماية الخادوم بـاستخدام Iptables إذا اتّبعت المُتطلّبات من أجل ضبط Iptables، فلك كامل الحريّة في تخطّي هذه الخطوة، أو يُمكنك القيام بذلك الآن. Redis مجرّد تطبيق يُنفّذ على خادومك، ولأنه لا يملك أي خصائص أمنيّة خاصة، فإنّ أول خطوة لحمايته حقيقة تكمن في حماية الخادوم الذي يُشغل منه. في حالة خادوم موجّه للعامة كخادومك Ubuntu 14.04، فإن ضبط جدار ناريّ كما هو مبيّن في درس Iptables يُعتبر الخطوة الأولى لذلك. اتّبع ذلك الرّابط واضبط جدارا ناريّا الآن. إذا طبّقت أحكام الجدار النّاري باستعمال ذلك الدّرس، فلن تحتاج لإضافة قاعدة أخرى لـ Redis، افتراضيّاً، إن أي مرور traffic يُمنَع إلّا عند السّماح له صراحةً. وبما أن خادوم Redis افتراضيّا يستمع على واجهة الاسترجاع (loopback (127.0.0.1 أو localhost، فلا يجب القلق حول المرور عبر المنفذ الافتراضي. إذا كنت تحتاج للسّماح لعنوان IP للوصول خصّيصا لـ Redis، يُمكنك التحقق من العنوان الذي يستمع منه Redis، وعلى أي منفذ باستخدام أمر grep لمُخرجات الأمر netstat. العمود الرّابع 127.0.0.1:6379 يطلعنا على عنوان IP والمنفذ المرتبطين بـ Redis: sudo netstat -plunt | grep -i redis المخرجات: tcp 0 0 127.0.0.1:6379 0.0.0.0:* LISTEN 8562/redis-server 1 تأكّد من أن هذا العنوان مسموح له في الجدار النّاري. للمزيد من المعلومات عن كيفيّة إضافة الأحكام، اطّلع رجاء على درس أساسيّات Iptables. الخطوة الثالثة، الربط إلى المضيف المحلي localhost افتراضيًّا، يُمكن الوصول إلى خادوم Redis من المضيف المحليّ، على أي حال، إذا اتّبعت درس ضبط Redis على خادوم متبوع/سيّد فقد حدّثت ملفّ الإعدادات للسّماح للاتّصالات من أي مكان. وهذا ليس آمنا كالربط إلى المُضيف المحليّ. افتح ملفّ إعدادات Redis للتّعديل: sudo nano /etc/redis/redis.conf ابحث عن هذا السّطر وتأكّد من أنه ليس على شكل تعليق (احذف الرّمز # إذا كان موجودا): bind 127.0.0.1 سنستمرّ في استعمال هذا الملفّ، لذلك أبقه مفتوحا الآن. الخطوة الرابعة، ضبط كلمة مرور لـ Redis إذا ثبتت Redis باتّباع درس كيف تضبط خواديم Redis متعددة على أوبنتو 14.04 فيجب عليك أن تكون قد ضبطت كلمة مرور مُسبقا، يُمكنك أن تضع كلمة مرور أكثر أمانا باتّباع هذا القسم الآن، وهذه الخطوات تعرض كيفية وضع كلمة مرور لخادوم قاعدة البيانات. ضبط كلمة مرور لـ Redis يفعّل إحدى ميزتي الحماية المُضمّنة في Redis، وهو الأمر auth، الذي يطلُب من العملاء الاستيثاق للوصول إلى قاعدة البيانات. تُضبَطُ كلمة المرور مُباشرة في ملف الإعدادات etc/redis/redis.conf/ الذي يجب أن تكون قد فتحته منذ الخطوة الماضيّة. اذهب عن قسم SECURITY وابحث عن سطر مُعلّق بالرمز # كالتّالي: # requirepass foobared أزل التّعليق عن السّطر بحذف الرمز #، وغيّر foobared إلى كلمة مرور قويّة وطويلة. عوضاً عن الإتيان بكلمة مرور من عندك، يمكنك استعمال أداة مثل apg و pwgen لتوليد واحدة. إذا لم تكن ترغب بتثبيت أداة فقط لتوليد كلمة مرور، يُمكنك استخدام السطر التّالي. لتوليد كلمة مرور مُختلفة عن هذا المثال غير القيمة بداخل علامتي التنصيص: echo "hsoub-academy" | sha256sum المُخرج سيبدو كالتّالي: e118c2b8fa805fbd0a6af458ab7df9fea14881b87c2e793b4a2192cda30bf8d5 لكنّ كلمة المرور المولّدة لن تكون منطوقة، وهي قويّة وطويلة وهو تماما المطلوب لحماية Redis. بعد نسخ ولصق مُخرج هذا الأمر كقيمة جديدة لـ requirepass، يجب أن تكون كالتّالي: requirepass 960c3dac4fa81b4204779fd16ad7c954f95942876b9c4fb1a255667a9dbe389d إذا كنت تُفضّلُ كلمة مرور أقصر، استخدم مُخرج الأمر التالي عوضا عنها. غيّر القيمة بين علامتي التنصيص لكي لا تولّد نفس كلمة المرور: echo "hsoub-academy" | sha1sum المخرج سيكون أقصر هذه المرّة: 773a12cfe8616ff740258f8843c567f32227ac0f بعد ضبط كلمة المرور، احفظ الملفّ وأعد تشغيل Redis : sudo service redis-server restart لاختبار عمل كلمة المرور، حاول الوصول إلى سطر أوامر Redis : redis-cli السطر التالي يعرض سلسلة من الأوامر المُستعملة لاختبار ما إذا كانت كلمة المرور تعمل أو لا، الأمر الأول يُحاول إعطاء قيمة لمفتاح قبل القيام بالاستيثاق: set key1 10 الأمر لن يعمل، لذلك فإنك سترى خطأ في المخرجات: (error) NOAUTH Authentication required. الأمر الثاني يقوم بالاستيثاق بكلمة المرور التي وضعناها في ملفّ إعدادات Redis. auth your_redis_password سيُوافق Redis في الحال: OK بعد هذا، تنجح إعادة تنفيذ الأمر السّابق. set key1 10 المُخرج: OK الأمر get key1 يطلب من Redis قيمة المفتاح الجديد: get key1 المُخرج: “10” الأمر الأخير يقوم بإنهاء سطر الأوامر redis-cli. ويمكنك أيضاً استخدام exit: quit تالياّ، سننظر إلى إعادة تسميّة أوامر Redis. الخطوة الخامسة، إعادة تسمية الأوامر الخطرة الخاصيّة الأمنيّة الأخرى المبنيّة داخل Redis تُخوّل لك إعادة تسميّة أو تعطيل أوامر معيّنة والتّي تُعتبر أوامر خطيرة. عند تشغيل مستخدمين غير مُخولين لأوامر معينّة فقد تُستخدم هذه الأوامر لإعادة ضبط، أو تدمير أو حذف بياناتك. ومثل كلمة مرور الاستيثاق،فإن إعادة تسمية الأوامر أو تعطيلها تتم في نفس قسم SECURITY من الملفّ etc/redis/redis.conf/. بعض الأوامر المعروف أنها خطيرة هي: FLUSHDB, FLUSHALL, KEYS, PEXPIRE, DEL, CONFIG, SHUTDOWN, BGREWRITEAOF, BGSAVE, SAVE, SPOP, SREM, RENAME و DEBUG وهذه القائمة ليست شاملة، لكنّ إعادة تسميّتها أو تعطيلها كلّها يُعتبر نقطة بداية جيّدة. تعطيل أو إعادة تسميّة أمر يعتمد على مدى استعمالك للأمر، فمثلاً إذا كنت تعلم أنّك لن تستعمل أبدا أمرا يُمكن أن يُستَغلّ سلبيّاً، فمن المستحسن أن تُعطّله، عدا ذلك فمن الأفضل إعادة التّسميّة. لتشغيل أو تعطيل أمر ما، افتح ملفّ الإعدادات للتحرير مرة أخرى: sudo nano /etc/redis/redis.conf هذه بعض الأمثلة فقط. ويجب عليك أن تعيد تسميّة أو تعطّل الأوامر بما يُناسبك. يُمكنك التحقق من الأوامر بنفسك وتحديد إمكانيّة سوء استعملها على redis.io/commands. لتعطيل أو إيقاف أمر ما، فقط أعد تسميّتها إلى قيمة فارغة كما هو مبيّن أسفله: # It is also possible to completely kill a command by renaming it into # an empty string: # rename-command FLUSHDB "" rename-command FLUSHALL "" rename-command DEBUG "" وعند إعادة تسميّة أمر ما، عيّن اسما آخر كقيمة، كما في الأمثلة أسفله. الأوامر المعاد تسميّتها يجب أن تكون صعبة التخمين، وفي نفس الوقت سهلة التذكر بالنسبة لك.ولا تجعلها صعبة عليك. rename-command CONFIG "" rename-command SHUTDOWN SHUTDOWN_MENOT rename-command CONFIG ASC12_CONFIG بعد إعادة التّسميّة، طبّق التعديلات بإعادة تشغيل Redis: sudo service redis-server restart لاختبار الأمر الجديد، ادخل إلى سطر أوامر Redis: redis-cli بعد ذلك، على افتراض بأنّك قمت بإعادة تسميّة الأمر CONFIG إلى ASC12_CONFIG، المُخرج التّالي يوضح كيفيّة التأكد من أنّ الأمر الجديد يعمل. بعد الاستيثاق: auth your_redis_password المُخرج: OK يجب أن تكون مُحاولة استخدام الأمر config باسمه الأصلي فاشلة، لأنّنا بالطبع قمنا بإعادة تسميّتها: config get requirepass المُخرج": (error) ERR unknown command 'config' مناداة الأمر باسمه الجديد سيعمل (وهو غير حسّاس لحالة الأحرف): asc12_config get requirepass المُخرج: 1) "requirepass" 2) "your_redis_password" أخيرا، يمكنك الخروج من redis-cli: exit ملاحظة: إذا كنت تستخدم مسبقا سطر الأوامر Redis ثم أعدت تشغيل Redis، سيتوجب عليك إعادة الاستيثاق. إن لم تقوم بذلك، ستحصل على هذا الخطأ عند كتابة أمر ما: NOAUTH Authentication required. على الرغم من إعادة تسميّتك للأوامر، فهناك جملة تحذيريّة في آخر قسم SECURITY على ملفّ etc/redis/redis.conf/ تقول: هذا يعني أنّه إذا لم يكن الأمر المعاد تسميّته داخل ملفّ AOF، أو إذا كان موجودا لكنّ ملفّ AOF لم يُحَلْ إلى التّوابع، فلا يجب أن يكون هناك أي مُشكلة. لذلك تذكّر عند محاولة تغيير أسماء الأوامر، أفضل وقت لإعادة تسميّة أمر هو عند عدم استخدام AOF، أو مباشرة بعد التثبيت أي قبل نشر التطبيق المُستعمِل لـ Redis. عندما تستخدم AOF وعند التّعامل مع نظام تابع-متبوع، ضع في بالك هذه الإجابة من صفحة المسائل في المشروع على Github. الاقتباس التّالي هو جواب على سؤال الكاتب: لذلك فإن أفضل طريقة للتعامل مع إعادة التسمية في حالات كهذه هي أن تتأكّد من أنّ إعادة تسميّة الأوامر مطبّقة في جميع الخوادم في أنظمة تابع-متبوع. الخطوة السادسة، ضبط مجلد البيانات وصلاحيات المستخدم للملفات في هذه الخطوة، سوف نعرض بعض تعديلات المالك والصلاحيّات التّي يُمكنك القيّام لها لزيّادة حماية Redis. يتمثّل هذا في التأكد من أنّ المُستخدم الذي يحتاج إلى الوصول إلى Redis فقط يملك صلاحيّات قراءة البيانات. هذا المُستخدم افتراضيّا هو المُستخدم redis. يُمكنك التحقق من هذا باستخدام أداة grep مع الأمر ls لرؤية معلومات عن المُجلّد الأب لمجلّد بيانات Redis. الأمر والمُخرجات أسفله. ls -l /var/lib | grep redis المُخرج: drwxr-xr-x 2 redis redis 4096 Aug 6 09:32 redis يُمكنك ملاحظة بأن مجلّد بيانات Redis مملوك من طرف المُستخدم Redis، مع وصول ثانوي للمجموعة redis. وهذا أمر جيّد. الأمر السيئ هو صلاحيّات الوصول إلى المُجلّد، أي 755. للتأكد من أن المُستخدم redis هو فقط من يمتلك حقّ الوصول إلى المجلد ومُحتوياته، غيّر الصلاحية إلى 700: sudo chmod 700 /var/lib/redis الصلاحيّة الأخرى التّي عليك تغييرها هي الخاصّة بملفّ إعدادات Redis. يمتلك افتراضيّا صلاحيّة 644 ومملوك للمُستخدم الجذر root، مع مالك ثانوي يتمثّل في مجموعة الجذر root group: ls -l /etc/redis/redis.conf المُخرج: -rw-r--r-- 1 root root 30176 Jan 14 2014 /etc/redis/redis.conf هذه الصّلاحيّة (644) تعني مقروء من الكل، والتي تعتبر فكرة سيّئة لأن ذلك الملف يحتوي على كلمة المرور غير المُشفرة التّي وضعناها في الخطوة الرّابعة. نحتاج إلى تغيير المالك والصّلاحيّات. يجبُ أن تكون مملوكة للمُستخدم redis مع مجموعة الجذر كمالك ثانوي، لفعل ذلك، شغّل الأمر التّالي: sudo chown redis:root /etc/redis/redis.conf بعد ذلك غيّر المالك لكي يتمكّن مالك الملفّ فقط من قراءته أو/و الكتابة عليه: sudo chmod 600 /etc/redis/redis.conf يُمكنك التحقّق من المالك الجديد والصّلاحيّات باستخدام الأمر: ls -l /etc/redis/redis.conf المُخرج: total 40 -rw------- 1 redis root 29716 Sep 22 18:32 /etc/redis/redis.conf في الأخير، أعد تشغيل Redis: sudo service redis-server restart خاتمة تذكّر بأنه عند دخول أي شخص إلى خادومك، فمن السّهل التحايل على خصائص Redis الأمنيّة التي قمنا بضبطها. لذلك فإنّ أكثر خاصيّة أمنيّة هي التي تجعل من تجاوز هذا الحاجز صعبا قدر المُستطاع. أي خاصيّة الجدار النّاري. للتّقدّم بحماية خادومك إلى المستوى التّالي، فعليك ضبط نظام كشف تطفّل مثل OSSEC. إذا كنت تريد حماية تواصل Redis عبر شبكات غير آمنة فعليك توظيف SSL proxy، كما هو منصوح به من مطوّري Redis على دليل حمايةRedis الرسمي. وضبط SSL proxy لحماية تواصل Redis فهو موضوع آخر. لم نتطرّق إلى قائمة شاملة من أوامر Redis بقسم إعادة التّسميّة، لكنّك تستطيع إلقاء نظرة على مجموعة الأوامر بنفسك وتحديد إمكانيّة سوء استعملها على redis.io/commands. ترجمة -بتصرّف- للمقال How To Secure Your Redis Installation on Ubuntu 14.04 لصاحبه finid.

استخدام الجدار الناري (firewall) يعتمد كثيرًا على السياسة (policy) التي ستتبعها في تصفية تدفّقات البيانات (data traffics) بنفس درجة اعتماده على تعلّمك للأوامر الأساسية وطريقة الاستخدام. بعض الجدران النارية مثل ـiptables تمتلك القدرة على فرض سياسات معيّنة يتم تحديدها من قبل مدير النظام، ولكن كواحدٍ من هؤلاء، يجب أن تعرف أفضل السياسات المناسبة لتطبيقها على البيئة الخاصّة بك. بينما تركّز دروسٌ أخرى على الأوامر اللازمة للحصول على جدار ناري فعّال، في هذا الدرس، سنناقش بعض الأمور التي يجب عليك فعلها عندما تقوم بتشغيل جدار ناري. ستؤثّر هذه الخيارات على الطريقة التي يتصرّف بها جدارك الناري، وعلى المدى الذي يجب إحكام إقفال خادومك إليه، بالإضافة إلى طريقة استجابته لمختلف الشروط التي قد تطرأ من حينٍ إلى آخر. سنستخدم iptables في درس اليوم، إلّا أنّ معظم ما سنتكلّم عنه سينطبق على أيّ أداة بغضّ النظر عن نوعها. اختيار السياسة الافتراضية عند بناء جدارٍ ناريّ فإن السياسة الافتراضية هي واحدة من الأشياء الأساسية التي يجب عليك التفكير فيها. تحدد السياسة الافتراضية ما يجب أن يحصل لتدفّقات البيانات في حال عدم مطابقتها لأيّ قاعدة (rule). يمكن افتراضيًا للجدار الناري أن يقبل أيّ تدفّق لا يطابق القواعد المعيّنة أو أن يرفضه. القبول افتراضيا مقابل الرفض افتراضيا سياسة "Accept" (قبول) الإفتراضية تعني أنّه سيتم السماح لأيّ تدفّق غير مطابق للقواعد المعيّنة مسبقًا بالمرور إلى الخادوم. لا ينصح باستخدام هذه السياسة افتراضيًا لأنّ هذا يعني أنّك ستقوم بعمل قائمة سوداء لمنع ما تريد منعه من الوصول إلى خادومك. القوائم السوداء صعبة الإدارة لأنّه يجب عليك متابعة وحظر جميع أنواع التدفّقات التي لا تريدها في خادومك. يمكن أن يؤدي هذا إلى الكثير من وجع الرأس بالإضافة إلى مشاكل تقنية في حال حصول غلطة بسيطة في القائمة السوداء مثلًا، لذلك هو أمرٌ غير مستحسن. الحلّ البديل هو "drop" (ترك) التدفّق افتراضيًا. هذا يعني أنّه لن يتم السماح لأيّ تدفّق لا يطابق القواعد المعيّنة مسبقًا بالوصول إلى الخادوم (أو الخروج منه)، وهو أمرٌ مشابه للقوائم البيضاء وقوائم تحكّم الوصول (Access Control List) حيث يجب السماح بشكلٍ استثنائي وخاصّ بأن يتم تشغيل وتنفيذ كلّ خدمة متوفّرة على حدى، والذي قد يحتاج الكثير من الوقت والجهد في البداية، ولكنّ هذا يعني أنّ السياسة الافتراضية الخاصّة بك ستكون أكثر أمانًا وستعرف بالضبط نوع تدفّق البيانات الداخل إلى خادومك. عليك الاختيار بين التوجّه نحو الخيار الأكثر أمانًا أو السماح للخدمات بالتحرّك بشكلٍ أكثر حرّية خارج الصندوق. صحيحٌ أنّ خيار استخدام سياسة "Accept" (قبول) افتراضيًا مع الجدار الناري قد يكون أفضل ما تفكّر به للوهلة الأولى، ولكن - في غالب الأحيان - من الأفضل في الواقع أن تستخدم سياسة "منع" افتراضيًا للجدار الناري. سياسة "drop" افتراضيا مقابل قاعدة "drop" نهائية الخيار السابق باستخدام سياسة "drop" (ترك) افتراضيًا يقود إلى قرارٍ مهم آخر. في iptables والجدران النارية المشابهة الأخرى، يمكن أن يتم تعيين السياسة الافتراضية باستخدام خصائص داخلية للجدار الناري، أو تضمينها عبر إضافة قاعدة "drop" (ترك) شاملة في نهاية قائمة قواعد الجدار الناري. الفرق بين هذين الطريقتين هو فيما سيحصل في حال تمّ مسح (flush) قواعد الجدار الناري. إذا كانت السياسة الافتراضية الداخلية في الجدار الناري الخاصّ بك معيّنة على "drop" (ترك) التدفّق وحصل يومًا ما وأن تمّ مسح قواعد الجدار الناري أو حذف بعضٍ منها عن طريق الخطأ مثلًا، فإنّ جميع الخدمات التي تشغّلها على الخادوم ستصبح غير قابلة للوصول. هذه غالبًا فكرة جيّدة عند ضبط الخدمات غير الحساسة على خادومك لكي لا يتم السماح للبرامج والأدوات الخبيثة بالمرور إذا اختفت القواعد فجأة. لكنّ الجانب المظلم في هذا التوجّه هو أنّ خدماتك ستصبح فورًا غير متوفّرة لمستخدميك إلى حين أن تقوم بإعادة تعيين قواعد الوصول مجددًا. يمكن أحيانًا أن تقوم بقفل الباب على نفسك وأنت في خارج الخادوم، الأمر سيّئ خاصّة إذا لم تكن تقدر على الوصول "فيزيائيا" إلى الخادوم أو وسيلةً أخرى للاتصال به (خواديم DigitalOcean قابلة للوصول دومًا بغضّ النظر عن إعدادات الشبكة عبر استخدام زرّ "Console Access" الموجود في قسم "Access" من لوحة التحكّم الخاصّة بالخادوم). إذا كنت أنت من يريد إعادة تعيين القواعد ومسحها بشكلٍ مقصود، فيمكنك ببساطة تجنّب هذه المشكلة عبر تغيير السياسة الافتراضية إلى "Accept" (قبول) مباشرةً قبل إعادة تعيين ومسح القواعد. الخيار البديل لما سبق هو تعيين السياسة الافتراضية الخاصّة بك إلى "Accept" (قبول) مع تضمين قاعدة "drop" (ترك) في النهاية مع القواعد الأخرى. يمكنك إضافة قاعدة عادية في نهاية قائمة القواعد الخاصّة بك تقوم بمطابقة ومنع كلّ التدفّق الباقي الغير مُطابق. في هذه الحالة، إذا تمّ إعادة تعيين قواعد الجدار الناري الخاصّة بك، فإنّ خدماتك ستكون قابلة الوصول ولكن غير محمية. اعتمادًا على خياراتك للوصول المحلّي أو البديل، يمكن أن يكون هذا شرًّا ضروريًا لكي تضمن أنّك قادر على الوصول إلى خادومك مجددًا في حال مُسحت قواعد الجدار الناري. إذا قررت استخدام هذا الخيار، فيجب أن تضمن أنّ قاعدة "drop" (ترك) التدفّق الغير مطابق هي دومًا آخر قاعدة في قائمة قواعد الجدار الناري. ترك التدفق مقابل رفضه هناك بضع طرق مختلفة لمنع حزمة بيانات (packet) من المرور إلى الوجهة التي تريدها. الاختيار المختلف لواحدٍ من هذه الطرق سيؤثر على الطريقة التي يقوم المستخدمون من خلالها بمحاولة الاتصال بالخادوم وسرعة إدراكهم أنّه لن يتم خدمة طلبهم الذي أرسلوه مسبقًا. الطريقة الأولى التي يمكن من خلالها منع حِزَم البيانات هي عبر "drop" (ترك) التدفّق. يمكن أن يتم استخدام الـ "ترك (drop)" كسياسة افتراضية أو ضمن قواعد الجدار الناري. عندما يتم ترك حزمة بيانات، يقوم iptables ببساطة برميها بعيدًا، حيث لا يقوم بإرسال أيّ رد إلى العميل الذي يحاول الاتصال ولا يقوم حتّى بإرجاع ردّ أنّه قد استلم الطلب بنجاح أم لا. هذا يعني أنّ العملاء لن يعرفوا ما إذا كان الخادوم قد وصله طلبهم أساسًا أم لا. لمحاولات الاتصال عبر بروتوكول TCP، سيتم الحفاظ على الاتصال إلى حين انقضاء مهلته (timeout). بما أنّ بروتوكول UDP هو بروتوكول غير اعتمادي على الاتصال (connectionless)، فإنّ عدم توفّر الردّ للعملاء يصبح أكثر إيهامًا. في الواقع، غالبًا ما يكون عدم تلقّي ردّ في هذه الحالة دليلًا على أنّ حزمة البيانات قد قُبلت. إذا كان عميل UDP يهتم بالجهة التي يرسل الحِزَم إليها، فسيقوم بإرسالها مجددًا لكي يتحقق مما إذا تمّ قبولها أو فقدانها أو رفضها. قد يزيد هذا من الوقت الذي يجب على البرمجيات والشفرات الخبيثة استغراقه للحصول على معلوماتٍ صحيحة عن حالة المنافذ في خادومك، لكنّه قد يسبب أيضًا مشكلة للتدفّق العادي. الخيار البديل هنا هو ببساطة رفض حزم البيانات التي لا تريدها بشكلٍ استثنائي. ICMP أو بروتوكول رسائل التحكّم بالإنترنت (Internet Control Message Protocol) هو عبارة عن بروتوكول وصفي (meta-protocol) يستعمل عبر الإنترنت لإرسال الحالة ومعلومات مواجهة الأعطال ورسائل الخطأ بين المضيفين (hosts) ضمن قناة لا تعتمد على اتصالات البروتوكولات التقليدية مثل TCP وUDP. عندما تقوم بـ "رفض" شيءٍ ما، فإنّ التدفّق سيتم منعه وسيتم إعادة حزمة ICMP إلى المُرسِل لإعلامه أنّ البيانات التي أرسلها قد تمّ استلامها إلّا أنّه قد تمّ رفضها. يمكن لرسالة الحالة أن تشير إلى السبب أيضًا. توجد العديد من العواقب لهذا، بافتراض أنّ تدفّق ICMP قادر على الرجوع إلى العميل، فإنّه سيتم إخطاره مباشرةً أنّ التدفّق الخاص به محظور. للعملاء العاديين، سيعني هذا أنّه يجب عليهم الاتصال بمدير الخادوم للاستفسار عن السبب أو التحقق من خيارات اتصالاتهم للتأكّد من أنّهم يتصلون عبر المنفذ الصحيح. أمّا بالنسبة للمستخدمين السيئين والذين يحاولون اختراق الخادوم، فإنّ هذا يعني أنّه يمكنهم إكمال عمليات بحثهم عن المنافذ المفتوحة والمغلقة والمُرشّحة في وقتٍ أقصر. هناك الكثير من الأمور التي يجب أخذها بعين الاعتبار عندما تقرر قبول أو رفض تدفّق البيانات. من بينها معرفة أنّ غالب تدفّق البيانات الخبيث الذي يتم إرساله بواسطة المخترقين يتم إرساله في الواقع عبر سكربتات وبرامج مؤتمتة، وبما أنّها ليست حساسة للوقت، فإنّ ترك التدفّق العادي لن يكون مفضلًا حيث أنّه سيؤثر على المستخدمين العاديين للخادوم. يمكنك قراءة المزيد عن هذا من هنا. جدول المقارنة بين ترك الطلب ورفضه يظهر الجدول أدناه كيفية حماية خادوم بواسطة جدارٍ ناريّ، حيث سيقوم بالاستجابة إلى طلباتٍ مختلفة بناءًا على السياسة التي يتم تطبيقها على منافذ معيّنة. يحدد العمود الأول نوع حزمة البيانات التي يتم إرسالها بواسطة العميل، بينما في الثاني، نقوم بذكر أمر nmap الذي سنستخدمه لاختبار كلّ سيناريو. يحدد العمود الثالث سياسة المنفذ المتبّعة على المنفذ، بينما الرابع يحدد الرد الذي سيتم إرجاعه إلى من طرف الخادوم. والخامس، هو ما يمكن للعميل أن يفهمه بناءًا على الرد الذي تلقاه. ترجمة -وبتصرّف- لـلمقال: How To Choose an Effective Firewall Policy to Secure your Servers لصاحبه Justin Ellingwood.

نعود إليكم في الجزء الثاني من درس "كيف تختار سياسة فعّالة للجدار الناري لتأمين خواديمك" لنتحدث عن المزيد من الأمور والنصائح التي يجب أخذها بعين الاعتبار عند إعداد الجدار الناري الخاصّ بخادومك لأوّل مرّة. سياسات ICMP هناك آراءٌ مختلفة حول ما إذا كان يجب قبول حِزَم بيانات ICMP القادمة إلى خادومك أم لا. ICMP هو بروتوكول يستعمل لعدة أشياء، وغالبًا ما يتم إرساله مجددًا، كما رأينا سابقًا، لإعطاء معلومات عن حالة الطلبات التي تستخدم بروتوكولات أخرى. ربّما أبرز مهامه هو إرسال واستقبال نبضات الشبكة (network pings) لفحص قابلية الاتصال بالأجهزة المضيفة البعيدة. هناك عدة استخدامات غير شائغة أخرى لبروتوكول ICMP ولكنها ما تزال مفيدة. يتم تمييز حزم ICMP عبر "النوع (type)" وبعدها عبر "الشفرة (code)"، حيث يقوم النوع بتحديد معنى الرسالة العام، كمثال، Type 3 يعني أنّ الوجهة غير قابلة للوصول، بينما يتم استخدام "الشفرة" لإعطاء المزيد من المعلومات عن “النوع”. كمثال، "ICMP Type 3 Code 3" يعني أنّ المنفذ الذي تحاول الاتصال من خلاله بوجهتك غير متوفّر، بينما "ICMP Type 3 Code 0" تعني أنّ شبكة الوجهة التي تحاول الاتصال بها غير متوفّرة بالمرّة. الأنواع التي يمكن دوما حجبها هناك بعض الأنواع (Types) لبروتوكول ICMP تكون مهملة طوال الوقت، لذا يجب غالبًا حجبها. من بين هذه الأنواع: ICMP source quench (النوع 4 و code 0) Alternate host (النوع 6) الأنواع 1, 2, 7 و 15 محفوظة للاستخدام المستقبلي أو المتقدّم وليست مهمّة. الأنواع التي يمكن حجبها اعتمادا على إعدادات الشبكة تكون بعض أنواع ICMP مفيدة في إعدادات شبكةٍ معيّنة، ولكن يجب حجبها في بيئةٍ أخرى. كمثال، رسائل إعادة توجيه ICMP (النوع 5 أو type 5) يمكن أن تكون مفيدة في التقاط تصميم الشبكات السيء. يتم إرسال إعادة توجيه ICMP عندما يكون هناك طريقٌ أفضل متوفّر أمام العميل. لذا إذا استقبل الموجّه (router) حزمة بيانات يجب توجيهها إلى مضيفٍ آخر على نفس الشبكة، فإنّه يقوم بإرسال رسالة إعادة توجيه عبر بروتوكول ICMP لإخبار العميل بأن يقوم بإرسال الحِزَم إلى المضيف الآخر في المستقبل. سيفيدك هذا إذا كنت تثق بشبكتك المحلية وكنت تريد التقاط أماكن عدم الكفاءة (inefficiencies) في جداول التوجيه (routing tables) أثناء الإعداد الأوّلي (إصلاح التوجيه الخاصّ بك هو حلٌّ أفضل على المستوى البعيد). لكن على شبكة غير موثوقة، يمكن لمستخدم سيء أن يقوم بإرسال رسائل إعادة التوجيه عبر برتوكول ICMP للتلاعب بجداول التوجيه الموجودة على أجهزة المضيفين (hosts). من أنواع ICMP الأخرى المفيدة في بعض الشبكات والمؤذية في أخرى هي حِزَم ما يعرف بـICMP router advertisement (النوع 9 أو type 9) وrouter solicitation (النوع 10 أو type 10). يتم استخدام حزم الإعلان (advertisement) والحثّ (solicitation) كجزء من IRDP (ICMP Internet Router Discovery Protocol)، وهو نظام يسمح للمضيفين - بعد الإقلاع أو الانضمام لشبكة ما - بأن بكتشفوا تلقائيًا الموجّهات (routers) المتوفّرة. من الأفضل في معظم الحالات للمضيف أن يمتلك طرق (routes) ثابتة مُعدّة خصيصًا للبوابات التي سيستعملها. يجب أن يتم قبول هذه الحزم في نفس حالات حزم التوجيه من ICMP. في الواقع، بما أنّ المضيف لن يعرف الطرق الأكثر تفضيلًا لنقل التدفّق من بين جميع الطرق المكتشفة، فإنّ رسائل إعادة التوجيه غالبًا ما تكون مطلوبة مباشرةً بعد الاكتشاف. إذا كنت لا تشغل خدمة تقوم بإرسال حزم حثّ التوجيه (router solicitation) أو خدمة تقوم بتعديل الطرق بناءًا على حزم الإعلان (advertisement packets) مثل rdisc، فيمكنك حظر هذه الحزم بأمان. الأنواع التي من الآمن السماح لها ستجد أنواع ICMP الآمنة عادةً أدناه، لكن ربّما تريد تعطيلها إذا كنت تريد أن تكون في أمانٍ أكثر. Type 8 — Echo request: هذه هي طلبات النبضات (ping requests) الموجّهة إلى خادومك. من الآمن السماح لها بالعمل على خادومك عادةً (منع هذه الحزم لن يخفي خادومك، هناك عدة طرق أخرى أمام المستخدمين ليعرفوا ما إذا كان خادومك يعمل حاليًا أم لا)، ولكن يمكنك منعها أو تحديد عناوين مصدر هذه الحزم وتقليلها إذا كنت تريد ذلك. Type 13 — Timestamp request: يمكن استخدام هذه الحزم بواسطة العملاء لجمع معلومات مواجهة الأعطال. يمكن استخدامها أيضًا في بعض تقنيات التقاط بصمات نظام التشغيل، لذا يمكنك منعها إن أردت. يمكن السماح للأنواع التالية عمومًا دون الحاجة إلى قواعد (rules) خاصّة عبر إعداد جدارك الناري ليسمح بالردود على الطلبات التي قام بإرسالها (عبر استخدام وحدة conntrack للسماح بتدفّق ESATABLISHED وRELATED). Type 0 — Echo replies: وهي عبارة عن الردود على طلبات النبضات (pings requests). Type 3 — Destination Unreachable: حِزَم بيانات الوجهة الغير متوفّرة العادية هي عبارة عن ردود طلبات تمّ إنشاؤها بواسطة خادومك، وهي تعني أنّه لم يتم توصيل حِزَم البيانات بشكلٍ صحيح. Type 11 — Time exceeded: هذا عبارة عن خطأ يتم إرجاعه في حال موت الحِزَم المُنشأة بواسطة خادومك قبل وصولها وجهتها بسبب تعدّيها لقيمة TTL الخاصّة بها. Type 12 — Parameter problem: يعني هذا أنّ حزمةً صادرة من خادومك قد تعرضت للتلف في طريقها. Type 14 — Timestamp responses: هي عبارة عن الردود على عمليات الاستعلام عن المنطقة الزمنية التي يتم تنفيذها بواسطة خادومك. حجب تدفّق ICMP بأكمله ما يزال أمرًا مستحسنًا من قبل العديد من خبراء الحماية، ولكن العديد من الناس الآن ينصحون باستخدام سياسات ICMP ذكية بدلًا من منعه بالكامل. تحديد الاتصال وتحديد التردد في بعض الخدمات وأنماط التدفّقات (traffic patterns)، ربّما تود السماح بالوصول من قبل جهاز العميل طالما أنّه لا يسيء استخدام هذا الوصول. هناك طريقتان لتقييد استخدام الموارد: تقييد الاتصال (connection limiting) وتقييد التردد أو المعدل (rate limiting). تقييد الاتصال يمكن أن يتم تفعيل تقييد الاتصال عبر استخدام امتدادات مثل connlimit للتحقق من عدد الاتصالات النشطة التي قام جهاز العميل بفتحها. يمكن أن يتم استخدام هذا لتقييد عدد الاتصالات المسموحة في وقتٍ واحد. إذا كنت تخطط لاستخدام تقييد الاتصال، فيجب عليك اتخاذ بعض القرارات بخصوص هذا بغض النظر عن طريقة تطبيقك له. هذه القرارات هي: هل سيكون التقييد بناءًا على العنوان، الشبكة أم على أمورٍ عامّة أخرى؟ هل سيكون التقييد لخدمة معينة فقط أم على الخادوم بأكمله؟ يمكن تقييد الاتصالات بناءًا على أجهزة الاستضافة أو شبكة معيّنة عبر استخدام بادئة شبكة ما (network prefix). يمكنك أيضًا تعيين حدٍّ أقصى لعدد الاتصالات المسموح بها لخدمة معيّنة أو للخادوم بأكمله. لا تنسى أيضًا أنّه بمقدورك استخدام جميع هذه الطرق أو بعضٍ منها لتحصل على خليط معقّد من السياسات المستعملة للتحكم في الاتصالات التي تريدها. تقييد التردد يسمح لك تحديد التردد أو تحديد المعدل (rate limiting) بإنشاء قواعد (rules) تقوم بإدارة تردد أو معدل التدفّق الذي سيقبله خادومك. هناك عدد من الامتدادات المختلفة التي يمكن استخدامها لتقييد التردد مثل limit، hashlimit وrecent. اختيار الأنسبة من هذه الامتدادات يعتمد على الطريقة التي تريد تقييد التردد خلالها. سيتسبب الامتداد limit للقاعدة في السؤال بأن يتم مطابقتها إلى حين الوصول إلى الحد الأقصى، بعدها سيتم ترك أيّ حزم بيانات إضافية أخرى. إذا قمت باستخدام حد مثل “5/ثانية/، فإنّ القاعدة ستقوم بالسماح بمطابقة 5 حزم في الثانية الواحدة، بعدها، لن تسمح لأيّ حزم بأن تقوم بعملية المطابقة. هذا جيّد لتحديد الحدّ الأعلى العام لخدمة معيّنة من الحزم. لكنّ امتداد hashlimit يعتبر أكثر مرونةً، حيث يسمح لك بتحديد بعض القيم التي سيستخدمها iptables لتحقيق عملية المطابقة كذلك. مثلًا، يمكن لـhashlimit أن يتحقق من عنوان المصدر ومنفذه، عنوان الوجهة ومنفذها أو حتّى تشكيلة من هذه القيم الأربعة لمطابقة كل مُدخَلة (entry). يمكنه أيضًا أن يقوم بالتحديد بناءًا على عدد الحزم أو البايتات المتلقاة، وهو ما يوفّر تحديدًا أكثر مرونة على مستتوى العميل أو مستوى الخدمات. يقوم امتداد recent ديناميكيًا بإضافة عنوان IP العميل إلى قائمة بيضاء أو يتحقق من وجوده في قائمة سوداء عند مطابقة القاعدة. يسمح لك هذا باستخدام منطق أكثر تعقيدًا لإنشاء قواعد متعددة للحصول على نتيجة مبهرة. يمتلك أيضًا القدرة على تحديد العدد والوقت كالامتدادات الأخرى، ولكنه قادر أيضًا على إعادة تعيين مدى الوقت (timerange) في حال رؤية المزيد من تدفّق البيانات، حيث يجبر العميل على وقف التدفّق في حال وصوله إلى الحد الأقصى. اختيار واحدٍ من هؤلاء لتستعمله على خادومك يعتمد بشكلٍ كامل على السياسة التي تريد تطبيقها في خادومك. الإدارة كوحدة متكاملة مقابل الإدارة كسلسلة جميع سياسة iptables مرسّخة في توسيع السلاسل المبنية فيه أساسًا (built-in chains). في الجدران النارية البسيطة، يكون هذا على شكل تغيير السياسة الافتراضية للسلاسل وإضافة القواعد. في الجدران النارية الأكثر تعقيدًا، غالبًا ما يكون من الجيد توسيع إطار عمل الإدارة عبر إضافة المزيد من السلاسل. السلاسل المكوّنة من طرف المستخدمين (User-created chains) مقيّدة بطبيعتها إلى السلسلة التي تستدعيها. السلاسل المكوّنة من طرف المستخدمين لا تملك أيّ سياسة افتراضية، لذا إذا لم تنجح حزمة بيانات ما في المرور عبر سلسلة مكوّنة من طرف المستخدم، فإنّها ستعود إلى السلسلة وتتابع المطابقة. مع أخذ هذا في عين الاعتبار، تصبح السلاسل المكوّنة بواسطة المستخدم مفيدة جدًا في الأغراض التنظيمية، جعل شروط مطابقة القواعد أكثر وضوحًا ولتحسين قابلية القراءة عبر تقسيم شروط المطابقة. إذا كنت تكرر عمليّة معينة لعددٍ كبير من القواعد، فحينها قد يكون من المفيد إنشاء "jump rule" مع العملية أو المطابقة والشروط المطلوبة المشتركة في سلسلة جديدة، يمكنك إضافة مجموعة من القواعد دون المطابقة المشتركة ضمن تلك السلسلة. بغضّ النظر عن التنظيم البسيط، يمكن لهذا أن يفيدك بشكلٍ أكبر. مثلًا، الاستخدام الذكي للسلاسل لمجموعات متشابهة من القواعد يعني أنّ إضافة القواعد في الموقع الصحيح سيكون أسهل وأقل تعرّضًا للأخطاء. ويمكن أن يكون أسهل كذلك في عرض وفهم أجزاء السياسة التي تهتم بها عبر تحديد السلسلة. الاختيار ما بين تضمين جميع قواعدك في واحدةٍ من السلاسل الموجودة بالفعل في الجدار الناري أو عبر إنشاء وتعديل سلاسل جديدة يعتمد بشكلٍ رئيسي لمدى التعقيد والبساطة والأهداف التي تسعى إلى تحقيقها على خادومك. خاتمة الآن، يفترض أنك تمتلك معرفة جيدة حول بعض القرارات التي يجب عليك اتخاذها عند تصميم سياسات الجدار الناري لخواديمك. بشكلٍ عام، الوقت الذي ستستغرقه في إعداد الجدار الناري لأوّل مرّة سيسهل مهام الإدارة عليك لاحقًا. صحيحٌ أنّ العملية ستحتاج الكثير من الوقت والخبرة والتجارب للحصول على أفضل سياسة تلائم خواديمك، ولكن القيام بهذا سيوفّر لك تحكمًا أكبر في حمايتها. إذا كنت تريد معرفة المزيد عن الجدران النارية و iptables بالتحديد، فيمكنك التحقق من المقالات التالية: كيف يعمل جدار iptables الناري. إعداد جدار ناري باستخدام iptables على Ubuntu 14.04. إعداد جدار ناري باستخدام UFW على Ubuntu 14.04. ترجمة -وبتصرّف- لـلمقال: How To Choose an Effective Firewall Policy to Secure your Servers لصاحبه Justin Ellingwood.

تتضمن نواة لينُكس النظام الفرعي Netfilter الذي يُستخدَم لتعديل أو تحديد مصير البيانات الشبكية الداخلة أو الخارجة من الخادوم، تَستخدم جميع الجدر النارية في لينُكس هذا النظام لترشيح الرزم الشبكية. نظام ترشيح الرزم الخاص بالنواة لن يكون مفيدًا لمدراء الأنظمة دون واجهة لإدارته، وهذا هو الغرض من iptables؛ فعندما تصل رزمة شبكية إلى خادومك، فستتوجه إلى النظام الفرعي Netfilter للموافقة أو التعديل أو الرفض بناءً على القواعد الموفَّرة لها من المستخدم عبر iptables؛ ولهذا سيكون iptables هو كل ما تحتاج لإدارة الجدار الناري إن كان مألوفًا لديك، لكن العديد من الواجهات المتوفرة له ستُبسِّط العملية. الجدار الناري ufw‏أداة ضبط الجدار الناري الافتراضية في أوبنتو هي ufw، التي طُوِّرَت لتسهيل ضبط جدار iptables الناري، توفر ufw واجهة «صديقة» للمستخدم لإنشاء جدار ناري لعناوين IPv4 أو IPv6. إن ufw معطَّل افتراضيًّا. من صفحة دليل man ufw: هذه بعض أمثلة استخدام ufw: أولًا، يجب أن نفعِّل ufw، أدخِل الأمر الآتي في الطرفية: sudo ufw enableلفتح منفذ ما (ssh في هذا المثال): sudo ufw allow 22وبشكلٍ مشابه، لإغلاق منفذ مفتوح: sudo ufw deny 22لحذف قاعدة، استخدم الكلمة delete متبوعةً بالقاعدة: sudo ufw delete deny 22من الممكن أيضًا السماح بالوصول من مضيفين أو شبكات محددة لمنفذٍ ما؛ يسمح المثال الآتي بالوصول لمنفذ ssh من المضيف 192.168.0.2 لأي عنوان IP في هذا المضيف: sudo ufw allow proto tcp from 192.168.0.2 to any port 22يمكن استخدام 192.168.0.0/24 بدلًا من 192.168.0.2 للسماح بالوصول عبر ssh لكامل الشبكة الفرعية. إضافة الخيار ‎--dry-run لأمر ufw سيجعله يخرج القواعد الناتجة، لكنه لن يطبقها؛ على سبيل المثال، ما يلي هو ما سيحدث لو فتحنا منفذ HTTP: sudo ufw --dry-run allow http*filter :ufw-user-input - [0:0] :ufw-user-output - [0:0] :ufw-user-forward - [0:0] :ufw-user-limit - [0:0] :ufw-user-limit-accept - [0:0] ### RULES ### ### tuple ### allow tcp 80 0.0.0.0/0 any 0.0.0.0/0 -A ufw-user-input -p tcp --dport 80 -j ACCEPT ### END RULES ### -A ufw-user-input -j RETURN -A ufw-user-output -j RETURN -A ufw-user-forward -j RETURN -A ufw-user-limit -m limit --limit 3/minute -j LOG --log-prefix "[UFW LIMIT]: " -A ufw-user-limit -j REJECT -A ufw-user-limit-accept -j ACCEPT COMMIT Rules updatedيمكن تعطيل ufw بالأمر: sudo ufw disableأدخل الأمر لمعرفة حالة الجدار الناري: sudo ufw statusلمعلومات تفصيلية عن حالة الجدار الناري، استخدم: sudo ufw status verboseلعرض أرقام بجوار القواعد (لحذفها مثلًا) فاستخدم الكلمة المحجوزة numbered: sudo ufw status numberedملاحظة: إن كان المنفذ الذي تريد فتحه أو إغلاقه معرفًا في ‎/etc/services، فيمكنك استخدام اسم المنفذ بدلًا من رقمه؛ حيث استبدل 22 بالكلمة ssh في الأمثلة السابقة. هذه مجرد مقدمة سريعة عن استخدام ufw، رجاءً راجع صفحة دليل ufw لمزيد من المعلومات. دمج التطبيقات مع ufwتستطيع التطبيقات التي تفتح منافذ أن تُضمِّن ملف ufw الذي يبيّن أيّة منافذ يحتاج التطبيق لفتحها لكي يعمل عملًا تامًا؛ هذه الملفات موجودة في ‎/etc/ufw/applications.d ويمكن أن تُعدَّل إذا تغيَّرت المنافذ الافتراضية. استخدم الأمر الآتي في الطرفية لعرض التطبيقات التي ثبتت أحد تلك الملفات: sudo ufw app listوبشكل شبيه للسماح بالاتصالات إلى منفذ معين، فيُفعَّل استخدام ملف ضبط أحد التطبيقات بالأمر: sudo ufw allow Sambaيمكن استخدام التعبير المُوسَّع كالآتي: ufw allow from 192.168.0.0/24 to any app Sambaاستبدل «Samba» و 192.168.0.0/24 باسم التطبيق ومجال IP لشبكتك. ملاحظة: لا توجد هنالك حاجة لتحديد البروتوكول للبرنامج الذي ستُفعِّله، لأن هذه المعلومات مفصَّلة بالملف الخاص به، لاحظ أن اسم التطبيق يستبدل رقم المنفذ. لعرض معلومات حول المنافذ والبروتوكولات (...إلخ.) المُعرَّفة لتطبيقٍ ما، فأدخِل الأمر: sudo ufw app info Sambaليس لكل التطبيقات التي تتطلب فتح منفذ شبكي ملف ufw خاص؛ إذا كتبت ذاك الملف لتطبيق ما، وأردت أن يُضمَّن هذا الملف مع الحزمة، فرجاءً بلِّغ عن علة في تلك الحزمة على Lanuchpad: ubuntu-bug nameofpackageتنكر IPالغاية من تنكر IP‏ (IP Masquerading) هو السماح للأجهزة التي تملك IP خاص غير قابل للتوجيه في شبكتك بالوصول إلى الإنترنت عبر الجهاز الذي يقوم بالتنكر؛ يجب أن تُعالَج البيانات الشبكية من شبكتك الخاصة إلى الإنترنت لكي توجَّه الردود إلى الجهاز الذي قام بالطلب، ويجب أن تُعدِّل النواة قيمة عنوان IP المصدر لكل رزمة شبكية لكي تصبح قابلة للتوجيه إلى الخادوم، بدلًا من عنوان IP الخاص (private IP) الذي قام بالطلب، الذي يكون مستحيلًا عبر الإنترنت؛ يستخدم لينُكس تعقب الاتصال (conntrack) لكي يتعقب أيّة اتصالات تتعلق بأيّة أجهزة وإعادة توجيه كل رزمة مُعادة وفقًا لذلك؛ أي أن البيانات الشبكية الخارجة من شبكتك المحلية هي «مُتنكِّرة» ﻷنها تنشأ من البوابة (خادومك)؛ يُشار إلى هذه العملية في توثيق مايكروسوفت باسم «مشاركة اتصال الإنترنت» (Internet Connection Sharing). تنكر ufwيمكن أن يجرى تنكر IP بقواعد ufw مخصصة؛ هذا ممكن لأن السند الخلفي للأداة ufw هو iptables-restore مع ملفات القواعد المخزنة في ‎/etc/ufw/*.rules؛ هذه الملفات هي مكان ممتاز لإضافة قواعد iptables بدون ufw، وللقواعد التي تتعلق تعلقًا كبيرًا بالبوابات الشبكية أو الجسور. تُقسَّم القواعد إلى ملفين مختلفين، القواعد التي يجب أن تُنَفَّذ قبل القواعد السطرية التابعة للأداة ufw، والقواعد التي تُنفَّذ بعدها. أولًا، يجب أن يُفعَّل تمرير الرزم في ufw، يجب أن يُعدَّل ملفي إعدادات؛ غيِّر قيمة DEFAULT_FORWARD_POLICY إلى "ACCEPT" في ملف ‎/etc/default/ufw: DEFAULT_FORWARD_POLICY="ACCEPT"ثم عدِّل الملف ‎/etc/ufw/sysctl.conf وأزل التعليق عن: net/ipv4/ip_forward=1وبشكل مشابه، لتمرير IPv6 أزل التعليق عن: net/ipv6/conf/default/forwarding=1سنضيف الآن القواعد إلى ملف ‎/etc/ufw/before.rules؛ القواعد الافتراضية تضبط جدول filter فقط، ويجب ضبط جدول nat لتفعيل التنكر؛ أضف ما يلي إلى أعلى الملف بعد تعليقات الترويسة مباشرةً: # nat Table rules *nat :POSTROUTING ACCEPT [0:0] # Forward traffic from eth1 through eth0. -A POSTROUTING -s 192.168.0.0/24 -o eth0 -j MASQUERADE # don't delete the 'COMMIT' line or these nat table rules won't be processed COMMITليست التعليقات ضروريةً، لكنها من المستحسن توثيق ملفات الضبط؛ وعند تعديل أي من ملفات «القواعد» في ‎/etc/ufw، فتأكد من أن هذين السطرين موجودان في نهاية الملف لكل جدول عدَّلته: # don't delete the 'COMMIT' line or these nat table rules won't be processed COMMITيجب أن تتوفر عبارة COMMIT في نهاية كل جدول، وقد ظهر في الأمثلة السابقة جدولا nat و filter فقط، لكنك تستطيع إضافة القواعد لجدولَيّ raw و mangle. ملاحظة: استبدل-في المثال السابق- eth0 و eth1 و 192.168.0.0/24 بالبطاقات ومجال IP الملائمين. في النهاية، عطِّل وأعد تفعيل ufw لتطبيق التغيرات: sudo ufw disable && sudo ufw enableيجب أن يُفعَّل تنكر IP الآن، تستطيع إضافة أية قواعد FORWARD إضافية إلى ملف ‎/etc/ufw/before.rules؛ من المستحسن إضافة هذه القواعد في سلسلة ufw-before-forward. تنكر iptablesيمكن أن يُستخدَم iptables لتفعيل التنكر. وبشكل شبيه للأداة ufw، أول خطوة هي تفعيل تمرير IPv4 بتعديل ملف ‎/etc/sysctl.conf وإزالة التعليق عن السطر الآتي: net.ipv4.ip_forward=1إذا أردت تفعيل تمرير IPv6، فأزل التعليق عن: net.ipv6.conf.default.forwarding=1تاليًا، نفِّذ الأمر sysctl لتفعيل الإعدادات الجديدة في ملف الضبط: sudo sysctl -pيمكن أن يُفعَّل تنكر IP بقاعدة iptables واحدة، التي يمكن أن تختلف اختلافًا بسيطًا بناءً على ضبط شبكتك: sudo iptables -t nat -A POSTROUTING -s 192.168.0.0/16 -o ppp0 -j MASQUERADEيفترض الأمر السابق أن مجال شبكتك الخاصة هو 192.168.0.0/16 وأن الجهاز الذي يمتلك اتصالًا بالإنترنت هو ppp0، نستطيع تقسيم الأمر السابق كما يلي: ‎-t nat: القاعدة ستذهب لجدول nat.‎-A POSTROUTING: ستُضاف القاعدة (‎-A) إلى سلسلة POSTROUTING.‎-s 192.168.0.0/16: تطبَّق القاعدة على البيانات الآتية من مجال العناوين المحدد.‎-o ppp0: القاعدة تُطبَّق على البيانات المقرر توجيهها عبر الجهاز الشبكي المحدد.‎-j MASQUERADE: ستقفز (jump) البيانات المُطابِقة لهذه القاعدة إلى هدف MASQUERADE لكي تُعالَج كما هو مشروح في الأعلى.أيضًا، كل سلسلة في جدول filter (الجدول الافتراضي، ومكان حدوث أغلبية ترشيح الرزم الشبكية) تكون سياستها الافتراضية هي ACCEPT؛ لكن إن كنت تُنشِئ جدارًا ناريًا بالإضافة إلى بوابة، فربما تحتاج إلى ضبط السياسات إلى DROP أو REJECT؛ وفي هذه الحالة تحتاج البيانات المتنكرة إلى السماح لها في سلسلة FORWARD لكي تعمل القاعدة السابقة: sudo iptables -A FORWARD -s 192.168.0.0/16 -o ppp0 -j ACCEPT sudo iptables -A FORWARD -d 192.168.0.0/16 -m state \ --state ESTABLISHED,RELATED -i ppp0 -j ACCEPTستسمح الأوامر السابقة لجميع الاتصالات من شبكتك المحلية إلى الإنترنت، ولعودة البيانات المتعلقة بهذه الاتصالات إلى الجهاز الذي طلبها. إذا أردت تفعيل التنكر عند الإقلاع -الذي تريد تفعيله في غالب الأحيان- فعدِّل ملف ‎/etc/rc.local وأضف الأوامر السابقة؛ على سبيل المثال، أضف الأمر السابق دون ترشيح: iptables -t nat -A POSTROUTING -s 192.168.0.0/16 -o ppp0 -j MASQUERADEالسجلات Logsسجلات الجدار الناري مهمة جدًا للتعرف على الهجمات، واستكشاف أخطاء قواعد الجدار الناري، وملاحظة النشاط غير الطبيعي في شبكتك؛ يجب أن تضمِّن قواعد للتسجيل في جدارك الناري لكي تولَّد السجلات، ويجب أن تأتي قواعد السجلات قبل قواعد الإنهاء (القواعد التي تحدد مصير الرزمة، مثل ACCEPT، أو DROP، أو REJECT). إذا كنت تستخدم ufw، فبإمكانك تفعيل التسجيل بإدخال الأمر الآتي في الطرفية: sudo ufw logging onلكي توقف التسجيل في ufw، فببساطة بدل on بالكلمة off في الأمر السابق. إذا كنت تستخدم iptables بدلًا من ufw، فأدخل الأمر: sudo iptables -A INPUT -m state --state NEW -p tcp --dport 80 \ -j LOG --log-prefix "NEW_HTTP_CONN: "طلبيةٌ على المنفذ 80 من الجهاز المحلي ستولدُ سجلًا في dmesg الذي يبدو كما يلي (سطرٌ واحدٌ فقط قُسِّمَ إلى عدِّة أقسام): [4304885.870000] NEW_HTTP_CONN: IN=lo OUT= MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=127.0.0.1 DST=127.0.0.1 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=58288 DF PROTO=TCP SPT=53981 DPT=80 WINDOW=32767 RES=0x00 SYN URGP=0سيظهر السجل السابق في ملف ‎/var/log/massages، و ‎/var/log/syslog، و ‎/var/log/kern.log؛ يمكن تعديل هذا السلوك بتعديل ‎/etc/syslog.conf تعديلًا ملائمًا أو بتثبيت وضبط ulogd وباستخدام الهدف ULOG بدلًا من LOG، العفريت ulogd هو خادوم في مجال المستخدم (userspace server) الذي يستمع إلى تعليمات التسجيل من النواة وخصوصًا للجدر النارية، ويمكنك التسجيل إلى أي ملف تريد، وحتى إلى قواعد بيانات PostgreSQL أو MySQL؛ يمكن تسهيل فهم سجلات الجدار الناري باستخدام أداة تحليل سجلات مثل logwatch، أو fwanalog، أو fwlogwatch، أو lire. أدوات أخرىهنالك أدوات عديد متوفرة لتساعدك في بناء جدار ناري كامل دون أن تكون لديك المعرفة الجيدة باستخدام iptables؛ للميالين للبرامج الرسومية: برنامج fwbulider1 هو قوي جدًا وسيكون مألوفًا للمدراء الذين تعاملوا مع أدوات تجارية لإدارة الجدر النارية، مثل Checkpoint FireWall-1. إذا كنت تُفضّل أداةً من سطر الأوامر مع ملفات ضبط نصيّة: الأداة Shorewall2 هي أداة قوية جدًا لتساعدك في ضبط جدار ناري متقدم لأي شبكة. مصادرصفحة ويكي أوبنتو «Ubuntu Firewall التي تحتوي على معلومات عن تطوير ufw.أيضًا، صفحة دليل ufw تحتوي معلومات مفيدة جدًا: man ufw.راجع الصفحة «packet-filtering-HOWTO» للمزيد من المعلومات حول استخدام iptables.صفحة «nat-HOWTO» تحتوي تفاصيل إضافية عن التنكر.صفحة ويكي أوبنتو «IPTables HowTo» هي مصدر رائع للمعلومات.ترجمة -وبتصرف- للمقال Ubuntu Server Guide: Firewall.

هذا الدّرس هو جزء من سلسلة دروس حول نشر تطبيقات PHP باستخدام Ansible على Ubuntu، تحدّثنا في الجزئين السّابقين عن تثبيت Ansible وإعداده ومن ثم عن إعداد Laravel وNginx. سنغطّي في هذا الدّرس إعداد مفاتيح SSH لتدعم أدوات نشر وتوزيع الشيفرة، وإعداد الجدار الناري للنظام، هدفنا في النهاية هو الحصول على خادوم يعمل عليه تطبيق PHP بشكل كامل مع الإعدادات المذكورة آنفًا. المتطلبات الأساسيةيبدأ هذا الدّرس مباشرة من حيث انتهى الجزء السّابق من هذه السلسلة، ونحتاج كافّة الملفّات والإعدادات التي تم الحصول عليها في ذلك الجزء، إن لم تقم بإكمال أول قسمين من هذه السلسلة فنرجو أن تفعل ذلك قبل متابعة هذا الدّرس. الخطوة الأولى – تبديل مستودع التطبيقسنقوم في هذه الخطوة بتحديث مستودع Git إلى مثال عن مستودع مُخصَّص قليلًا. بما أنّ تثبيت Laravel الافتراضي لا يتطلّب الميّزات المتقدمة التي سنقوم بإعدادها في هذا الدّرس فسنقوم بتبديل المستودع الموجود حاليًّا إلى مثال عن مستودع مع إضافة شيفرة للتنقيح debugging code فقط من أجل أن نظهر متى يعمل كل شيء، يُوجد المستودع الذي سنستخدمه على الرابط https://github.com/do-community/do-ansible-adv-php. نقوم بتغيير الدليل إلى ansible-php: cd ~/ansible-php/ نفتح playbook الموجودة حاليًّا من أجل تحريرها: nano php.yml نقوم بإيجاد وتحديث المهمّة “Clone git repository” بحيث تبدو كما يلي: Updated Ansible task - name: Clone git repository git: > dest=/var/www/laravel repo=https://github.com/do-community/do-ansible-adv-php update=yes version=example sudo: yes sudo_user: www-data register: cloned نحفظ ونشغل الـ playbook: ansible-playbook php.yml --ask-sudo-pass وبعد أن يتم تشغيلها نزور خادومنا في متصفح الويب لدينا (على الرابط http://your_server-ip بعد وضع عنوان خادومك)، ينبغي أن نشاهد رسالة تقول لم يتم العثور على التعريف "could not find driver". يعني هذا أنّنا نجحنا في استبدال المستودع الافتراضي بمثال مستودعنا، ولكن لا يستطيع التطبيق الاتصال بقاعدة البيانات، وهو ما نتوقع مشاهدته هنا، وسنقوم بتثبيت وإعداد قاعدة البيانات لاحقًا في هذا الدّرس. الخطوة الثانية – إعداد مفاتيح SSH من أجل النشرسنقوم في هذه الخطوة بإعداد مفاتيح SSH والتي يُمكن استخدامها من أجل نشر شيفرة التطبيق. ومع أنّ Ansible رائعة من أجل المحافظة على الإعدادات وإعداد الخواديم والتطبيقات، فيتم عادةً استخدام أدوات مثل Envoy و Rocketeer من أجل دفع تغييرات الشيفرة إلى الخادوم وتنفيذ أوامر التطبيق عن بُعد، تتطلّب أغلب هذه الأدوات اتصال SSH يتمكن من النفاذ إلى تثبيت التطبيق بشكل مباشر، يعني هذا في حالتنا أنّنا نحتاج إلى إعداد مفاتيح SSH من أجل المستخدم www-data. سنحتاج إلى ملف مفتاح عام من أجل المستخدم الذي نرغب بدفع الشيفرة منه، يُوجد هذا الملف بشكل نموذج في المسار ssh/id_rsa.pub./~، ننسخ هذا الملف إلى الدليل ansible-php: cp ~/.ssh/id_rsa.pub ~/ansible-php/deploykey.pubبإمكاننا استخدام الوحدة authorized_key لـ Ansible من أجل تثبيت مفتاحنا العام داخل var/www/.ssh/authorized_keys/ والذي سيسمح لأدوات النشر بالاتصال والنفاذ إلى تطبيقنا، تحتاج الإعدادات فقط إلى معرفة مكان المفتاح، باستخدام lookup، وإلى معرفة المستخدم الذي سيتم تثبيت المفتاح لأجله (www-data في حالتنا). New Ansible task - name: Copy public key into /var/www authorized_key: user=www-data key="{{ lookup('file', 'deploykey.pub') }}" نحتاج أيضًا لإعداد صدفة shell المستخدم www-data كي نستطيع فعليًّا تسجيل الدخول، وإلّا سيسمح SSH بالاتصال ولكن لن يتم عرض صدفة shell للمستخدم، يُمكن عمل هذا باستخدام الوحدة user وتعيين الصدفة إلى /bin/bash (أو الصدفة المفضلة لديك): New Ansible task - name: Set www-data user shell user: name=www-data shell=/bin/bash نفتح الآن الـ playbook لتحريرها من أجل إضافة المهام الجديدة: nano php.yml نضيف المهام السابقة إلى الـ playbook التي تُدعى php.yml، يجب أن تبدو نهاية الملف متطابقة مع التالي: Updated php.yml . . . - name: Configure nginx template: src=nginx.conf dest=/etc/nginx/sites-available/default notify: - restart php5-fpm - restart nginx - name: Copy public key into /var/www authorized_key: user=www-data key="{{ lookup('file', 'deploykey.pub') }}" - name: Set www-data user shell user: name=www-data shell=/bin/bash handlers: . . . نقوم بحفظ وتشغيل الـ playbook: ansible-playbook php.yml --ask-sudo-pass عندما تنتهي Ansible من ذلك ينبغي أن نكون قادرين على الدخول باستخدام SSH عن طريق المستخدم www-data: ssh www-data@your_server_ip إن استطعنا تسجيل الدخول بنجاح فهي تعمل بشكل صحيح، بإمكاننا الآن تسجيل الخروج عن طريق إدخال logout أو ضغط CTRL+D. لن نحتاج إلى استخدام هذا الاتصال في أي خطوات لاحقة، ولكن يبقى مفيدًا إن قمنا بإعداد أدوات أخرى، كما أشرنا سابقًا، أو من أجل التنقيح العام general debugging وصيانة التطبيق كما هو مطلوب. الخطوة الثالثة – إعداد الجدار الناريسنقوم في هذه الخطوة بإعداد الجدار الناري على الخادوم للسماح فقط بالاتصالات من أجل HTTP وSSH. يأتي Ubuntu مع جدار ناري يُدعى UFW (الجدار الناري غير المعقد Uncomplicated Firewall) مُثبَّت عليه بشكل افتراضي، وتدعمه Ansible بالوحدة ufw، يمتلك عدد من الميزات القوية وتمّ تصميمه ليكون بسيطًا قدر الإمكان وهو ملائم بشكل مثالي لخواديم الويب المحتواة ذاتيًّا والتي تحتاج فقط إلى عدة منافذ مفتوحة، نرغب في حالتنا بأن يكون المنفذ 80 (من أجل HTTP) والمنفذ 22 (من أجل SSH) مفتوحًا، وربّما قد تريد المنفذ 443 مفتوحًا من أجل HTTPS. تمتلك الوحدة ufw عددًا من الخيارات المختلفة تقوم بتنفيذ مهام مختلفة، وهذه المهام التي نريد تنفيذها هي: تمكين UFW ورفض كامل حركة مرور البيانات traffic القادمة افتراضيًّا.فتح منفذ SSH ولكن مع تحديده لمنع هجمات القوة القاسية brute force attacks.فتح منفذ HTTP.يُمكِن فعل هذا باستخدام المهام التالية على الترتيب: New Ansible tasks - name: Enable UFW ufw: direction=incoming policy=deny state=enabled - name: UFW limit SSH ufw: rule=limit port=ssh - name: UFW open HTTP ufw: rule=allow port=http </code>نفتح الملف php.yml من أجل تحريره: nano php.ymlنضيف المهام السابقة إلى الـ playbook، ينبغي أن تتطابق نهاية الملف مع التالي: Updated php.yml . . . - name: Copy public key into /var/www authorized_key: user=www-data key="{{ lookup('file', 'deploykey.pub') }}" - name: Set www-data user shell user: name=www-data shell=/bin/bash - name: Enable UFW ufw: direction=incoming policy=deny state=enabled - name: UFW limit SSH ufw: rule=limit port=ssh - name: UFW open HTTP ufw: rule=allow port=http handlers: . . . نقوم بحفظ وتشغيل الـ playbook: ansible-playbook php.yml --ask-sudo-pass بعد أن يتم هذا بنجاح يجب أن نكون قادرين على الاتصال عبر SSH (باستخدام Ansible) أو HTTP إلى خادومنا، ستكون المنافذ الأخرى مقفلة الآن. نستطيع التحقّق من حالة UFW في أي وقت عن طريق تنفيذ هذا الأمر: ansible php --sudo --ask-sudo-pass -m shell -a "ufw status verbose" وبتقسيم أمر Ansible السابق من أجل فهمه نجد: ansible: تقوم بتنفيذ مهمّة Ansible خام بدون playbook.php: تقوم بتنفيذ المهمّة على المضيفين في هذه المجموعة.--sudo: تنفّذ الأمر كـ sudo.--ask-sudo-pass: تقوم بالحث prompt من أجل كلمة سر sudo.-m shell: تقوم بتشغيل وحدة الصدفة shell.-a "ufw status verbose“: الخيارات التي يجب تمريرها إلى الوحدة، وبما أنّها أمر shell نقوم بتمرير الأمر الخام raw (أي ufw status verbose) مباشرة بدون أي خيارات key=value.يجب أن يُعيد شيئًا مشابهًا لهذا: UFW status output your_server_ip | success | rc=0 >> Status: active Logging: on (low) Default: deny (incoming), allow (outgoing), disabled (routed) New profiles: skip To Action From -- ------ ---- 22 LIMIT IN Anywhere 80 ALLOW IN Anywhere 22 (v6) LIMIT IN Anywhere (v6) 80 (v6) ALLOW IN Anywhere (v6) ترجمة -وبتصرّف- لـ How To Deploy an Advanced PHP Application Using Ansible on Ubuntu 14.04 لصاحبه Stephen Rees-Carter.

من المهم عند العمل على خادوم ويب تنفيذ تدابير أمنيّة لحماية موقعنا ومستخدمينا، إنّ حماية مواقع الإنترنت والتّطبيقات لدينا باستخدام سياسات الجّدار النّاري firewall policies وتقييد الوصول إلى بعض المناطق باستخدام استيثاق كلمة السّر password authentication هو نقطة بدء رائعة لتأمين النظام لدينا، ومع ذلك من المُرجَّح أن يجذب أي طلب لكلمة السّر مُتاح للعوام محاولات القوة القاسية brute force من قبل المستخدمين والروبوتات bots الخبيثين. يتمكّن إعداد fail2ban من المساعدة في الحد من هذه المشكلة، فعندما يفشل المستخدمون بالاستيثاق إلى خدمة ما بشكلٍ متكرّر (أو الانخراط في أي نشاط مشبوه آخر) تستطيع fail2ban أن تصدر حظرًا مؤقّتًا على عنوان IP المُهاجِم عن طريق التّعديل بشكل ديناميكي على سياسة الجّدار النّاري التي تعمل حاليًّا. تعمل كل "jail" تابعة لـ fail2ban عن طريق تفحّص السّجلّات المكتوبة من قبل خدمة ما بحثًا عن أنماط patterns تُشير إلى محاولات فاشلة بالاستيثاق. من السّهل إعداد fail2ban لكي تراقب سجلّات Apache باستخدام مُرشِّحات filters الإعداد المُضمَّنة. سنشرح في هذا الدّرس كيفيّة تثبيت fail2ban وإعدادها لمراقبة سجلّات Apache بحثًا عن محاولات التّسلّل، سنستخدم خادوم Ubuntu من أجل هذا. المتطلبات الأساسيةينبغي قبل أن نبدأ أن نمتلك خادوم Ubuntu مع إعداد حساب غير جذري non-root، ويجب أن يكون هذا الحساب مُعدًّا بامتيازات sudo من أجل إصدار أوامر إداريّة administrative commands. لكي تتعلّم كيفيّة إعداد مستخدم بامتيازات sudo اتبع دليلنا للإعداد الأولي لخادوم Ubuntu 14.04. تثبيت Apache وإعداد استيثاق كلمة السرإن كنتَ مهتمًّا بحماية خادوم Apache باستخدام fail2ban فمن الغالب أنك تملك مسبقًا خادومًا مُعدًّا وقيد التشغيل، وإن لم تكن كذلك تستطيع تثبيت Apache من خلال مستودعات Ubuntu الافتراضيّة باستخدام apt. فلنقم بتحديث دليل الحِزَم المحلّي وتثبيت Apache بكتابة ما يلي: sudo apt-get update sudo apt-get install apache2إنّ خدمة fail2ban مفيدة من أجل حماية نقاط تسجيل الدخول، ومن أجل أن يكون هذا مفيدًا لتثبيت Apache يجب تنفيذ استيثاق كلمة السّر على الأقل لمجموعة فرعيّة من المحتوى على الخادوم، تستطيع اتباع هذا الدّليل لإعداد حماية كلمة السّر من أجل خادوم Apache لديك. تثبيت Fail2Banبعد أن أصبح خادوم Apache لدينا قيد التّشغيل وتمّ تمكين استيثاق كلمة السّر عليه نستطيع المضي قدمًا وتثبيت fail2ban (نقوم هنا بإدراج إعادة جلب للمستودع مرّة أخرى في حال قمتَ بالفعل بتثبيت Apache في الخطوات السّابقة): sudo apt-get update sudo apt-get install fail2banسيقوم هذا بتثبيت برمجيّة fail2ban، والتي هي مُعدَّة افتراضيًّا لكي تحظر فقط محاولات تسجيل دخول SSH الفاشلة، نحتاج إلى تمكين بعض القواعد التي تقوم بإعدادها لكي تتفحّص سجلّات Apache لدينا بحثًا عن أنماط تشير إلى نشاط خبيث. ضبط الإعدادات العامة داخل Fail2Banنحتاج لكي نبدأ إلى ضبط ملف الإعدادات الذي تستخدمه fail2ban لتحديد سجلّات التطبيقات التي يجب أن تراقبها والإجراءات التي يجب أن يتمّ اتخاذها عند إيجاد مُدخلات مُخالِفة، ومن الموارد الرئيسيّة التي يتم تزويدنا بها لهذا الأمر نجد الملف etc/fail2ban/jail.conf/. ولإجراء التعديلات نحتاج إلى نسخ هذا الملف إلى etc/fail2ban/jail.local/، وهذا يمنع الكتابة فوق التغييرات التي أجريناها إن قام تحديث الحِزمة package بتزويدنا بملف جديد افتراضي: sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.localنقوم بفتح الملف الجديد المنسوخ حتى نستطيع إعداد مراقبة سجلّات Apache لدينا: sudo nano /etc/fail2ban/jail.local تغيير الإعدادات الافتراضيةينبغي أن نبدأ بتقييم المجموعة الافتراضيّة داخل الملف لنرى إن كانت تُلائِم احتياجاتنا، نستطيع إيجاد هذه المجموعة تحت قسم [DEFAULT] داخل الملف. تقوم هذه العناصر بتعيين السّياسة policy العامّة وبإمكاننا تجاوز أي منها في jails مُحدّدة. ومن أوائل العناصر التي يجب أن ننظر إليها هي قائمة العُمَلاء Clients التي لا تخضع لسياسات fail2ban، ويتم تعيينها باستخدام الأمر التّوجيهي ignoreip، من الجّيد أحيانًا إضافة عنوان IP الخاص بنا أو بشبكتنا إلى قائمة الاستثناءات لتجنّب حظر أنفسنا، على الرّغم من أنّ هذا أقل من أن يكون مشكلة مع تسجيلات الدّخول إلى خادوم الويب إن كان بإمكاننا المحافظة على النفاذ للـ Shell، حيث أنّنا دائمًا نستطيع إلغاء الحظر يدويًّا. نستطيع إضافة عناوين IP أو شبكات إضافيّة بفصلها بمسافة Space إلى القائمة الحاليّة: etc/fail2ban/jail.local/ [DEFAULT] . . . ignoreip = 127.0.0.1/8 your_home_IPومن العناصر الأخرى التي قد نرغب بضبطها نجد bantime والذي يتحكّم بعدد الثّواني التي سيتم خلالها حظر العضو المُخالِف، من المثالي تعيينه إلى مدّة طويلة كافية لتكون مُدمِّرة لجهود المستخدم الخبيث، وفي نفس الوقت قصيرة بما فيه الكفاية لتسمح للمستخدمين الشرعيّين لتصحيح أخطائهم، يتم تعيين هذه القيمة افتراضيًّا إلى 600 ثانية (10 دقائق)، قم بزيادتها أو إنقاصها على النحو الذي تراه مناسبًا: etc/fail2ban/jail.local/ [DEFAULT] . . . bantime = 3600يُحدّد العنصران التّاليان نطاق أسطر السّجلّات المستخدمة لتحديد العميل المُخالِف، يُحدِّد findtime المدّة الزمنية مُقدّرةً بالثواني ويُشير الأمر التّوجيهي maxretry إلى عدد المحاولات التي يتم التسامح معها خلال تلك المدّة، فإن قام العميل بعدد محاولات أكثر من maxretry خلال المدّة الزمنيّة المُحدّدة بواسطة findtime فسيتمّ حظره: etc/fail2ban/jail.local/ [DEFAULT] . . . findtime = 3600 # These lines combine to ban clients that fail maxretry = 6 # to authenticate 6 times within a half hour.إعداد تنبيهات البريد الإلكتروني (اختياري)نستطيع تمكين تنبيهات البريد الإلكتروني إن كُنّا نرغب باستقبال بريد كلّما حدث حظر، ويتوجب علينا أولًا لفعل هذا أن نقوم بإعداد MTA على خادومنا بحيث يستطيع إرسال بريد إلكتروني، لتتعلّم كيفيّة استخدام Postfix من أجل هذه المهمّة اتبع هذا الدّليل. ويتوجّب علينا بعد الانتهاء من إعداد MTA أن نقوم بضبط بعض الإعدادات الإضافيّة داخل القسم [DEFAULT] من الملف etc/fail2ban/jail.local/. نبدأ بإعداد الأمر التّوجيهي mta، فإن قمنا بإعداد Postfix -كما هو واضح في الدّرس التعليمي المذكور بالأعلى- نُغيّر هذه القيمة إلى “mail”: etc/fail2ban/jail.local/ [DEFAULT] . . . mta = mailيجب أن نختار عنوان البريد الإلكتروني الذي سيتم إرسال التنبيهات إليه ونكتبه داخل الأمر التّوجيهي destemail، بإمكاننا استخدام الأمر التّوجيهي sendername لتعديل حقل المُرسِل Sender في تنبيهات البريد الإلكتروني: etc/fail2ban/jail.local/ [DEFAULT] . . . destemail = youraccount@email.com sendername = Fail2BanAlertsإنّ الإجراء action -بحسب تعبير fail2ban- هو العمليّة التي تتلو فشل العميل بالاستيثاق مرات كثيرة، الإجراء الافتراضي (يُدعى _action) هو ببساطة حظر عنوان الـ IP من المنفذ port قيد الطلب، ويوجد على أيّة حال إجراءان آخران مُعدّان مُسبقًا يُمكن استخدامهما إن كنّا نملك إعداد بريد إلكتروني. نستطيع استخدام الإجراء action_mw لحظر العميل وإرسال تنبيه بريد إلكتروني إلى الحساب المضبوط لدينا مع تقرير “whois” حول عنوان المُخالِف، بإمكاننا أيضًا استخدام الإجراء action_mwl والذي يقوم بنفس العمل ولكن يقوم بتضمين سطور سجلّات المُخالِف والتي قامت بإطلاق عمليّة الحظر: etc/fail2ban/jail.local/ [DEFAULT] . . . action = %(action_mwl)sإعداد Fail2Ban لمراقبة سجلات Apacheبعد أن قمنا بضبط بعض إعدادات fail2ban العامّة في مكانها الصحيح نستطيع التركيز على تمكين بعض jails المرتبطة بـ Apache والتي ستراقب سجلّات خادوم الويب لدينا بحثًا عن أنماط سلوك مُعيّن. تتميّز كل jails داخل ملف الإعدادات بترويسة header تحتوي اسم الـ jail بين قوسين مربّعين (كل قسم يشير إلى إعدادات jail مُحدّدة ما عدا القسم [DEFAULT])، وافتراضيًّا نجد ssh] jail] هي الوحيدة المُمكّنة. لتمكين مراقبة السّجلّات بحثًا عن محاولات تسجيل دخول Apache سنقوم بتمكين [jail [apache، نُعدّل الأمر التّوجيهي enabled داخل هذا القسم بحيث يصبح true: etc/fail2ban/jail.local/ [apache] enabled = true port = http,https filter = apache-auth logpath = /var/log/apache*/*error.log maxretry = 6 . . .إن كان خادوم Apache يقوم بالكتابة إلى موقع السّجلّات الافتراضي (var/log/apache/error.log/) تكون jail مُعدّة مُسبقًا للبحث في المكان المناسب، وإن كُنّا نقوم بوضع السّجلّات في مكان آخر نُعدِّل مسار السّجل logpath حسب الحاجة، لا تتردد في ضبط الأمر التّوجيهي maxretry أو إضافة قيمة findtime لهذه الـ jail إن كنت ترغب في وضع قيود أخرى لهذه الـ jail تحديدًا: etc/fail2ban/jail.local/ [apache] enabled = true port = http,https filter = apache-auth logpath = /var/log/apache/custom_log_location.log maxretry = 3 findtime = 600 . . .تهتم jail السابقة بأمر حظر فشل الاستيثاق الأساسي، توجد أيضًا بعض jails التي تستحق تمكينها (إنّ jail التي تُدعى [apache-multiport] هي jail تراثيّة legacy لا نحتاج إليها). تُستَخدم jail التي تُدعى [apache-noscript] لحظر العُملاء الذين يبحثون عن تنفيذ واستغلال scripts على الموقع، إن لم نكن نستخدم PHP أو أيّة لغة برمجة أخرى بالتزامن مع خادوم الويب لدينا فبإمكاننا تمكين هذه الـ jail لحظر هؤلاء العملاء الذين يطلبون هذا النوع من الموارد: etc/fail2ban/jail.local/ [apache-noscript] enabled = true . . .تُستخدَم jail التي تُدعى [apache-overflows] لحظر العملاء الذين يحاولون طلب روابط URLs طويلة غير معتادة ومثيرة للشك، والتي تكون عادةً إشارة لمحاولات استغلال Apache عن طريق محاولة تحريض حدوث buffer overflow. بإمكاننا تمكين هذه الـ jail إن أردنا منع هذا النوع من الهجمات: etc/fail2ban/jail.local/ [apache-overflows] enabled = true . . .نستطيع القيام بفحوصات إضافيّة للتحقّق عن طريق نسخ ولصق المدخلة entry التي تُدعى [apache-overflows] وتعديلها قليلًا، فعلى سبيل المثال بإمكاننا نسخ ولصق هذا القسم وتعديل اسم الـ jail والمُرشِّح filter إلى apache-badbots لإيقاف بعض نماذج طلبات الروبوتات bots الخبيثة المعروفة: etc/fail2ban/jail.local/ [apache-overflows] enabled = true port = http,https filter = apache-overflows logpath = /var/log/apache*/*error.log maxretry = 2 [apache-badbots] enabled = true port = http,https filter = apache-badbots logpath = /var/log/apache*/*error.log maxretry = 2إن لم نكن نستخدم Apache لتزويدنا بالنفاذ إلى محتوى الويب داخل دليل المستخدمين الرئيسي فبإمكاننا نسخ ولصق ما سبق مرةً أخرى وتغيير أسماء الـ jail والمُرشِّح إلى apache-nohome: etc/fail2ban/jail.local/ [apache-overflows] enabled = true port = http,https filter = apache-overflows logpath = /var/log/apache*/*error.log maxretry = 2 [apache-badbots] enabled = true port = http,https filter = apache-badbots logpath = /var/log/apache*/*error.log maxretry = 2 [apache-nohome] enabled = true port = http,https filter = apache-nohome logpath = /var/log/apache*/*error.log maxretry = 2وأخيرًا إن كُنّا نستخدم Apache مع PHP فقد نرغب بتمكين jail التي تُدعى [php-url-fopen] والتي تقوم بحجب محاولات استخدام سلوك PHP مُحدَّد لأغراض خبيثة، من المحتمل أن يتوجّب علينا تغيير الأمر التّوجيهي logpath لكي يشير إلى مسار السّجلّات الصحيح (المسار الافتراضي على Ubuntu هو var/log/apache2/access.log/)، نستطيع استخدام نموذج مشابه للنموذج الذي يوافق سجل الأخطاء في jails الأخرى: etc/fail2ban/jail.local/ [php-url-fopen] enabled = true port = http,https filter = php-url-fopen logpath = /var/www/apache*/*access.logعندما ننتهي من التّعديلات التي نحتاجها نقوم بحفظ وإغلاق الملف. تنفيذ Apache Jails لدينالكي يتم تنفيذ تغييراتنا على الإعدادات نحتاج إلى إعادة تشغيل خدمة fail2ban، نستطيع فعل ذلك بكتابة ما يلي: sudo service fail2ban restartينبغي أن يتم إعادة تشغيل الخدمة وتنفيذ سياسات الحظر المختلفة التي قمنا بإعدادها. الحصول على معلومات حول Jails التي تم تمكينهانستطيع رؤية جميع jails التي تمّ تمكينها لدينا باستخدام الأمر fail2ban-client: sudo fail2ban-client statusينبغي أن نشاهد قائمة بكامل jails التي قمنا بتمكينها: Status |- Number of jail: 7 `- Jail list: php-url-fopen, apache-overflows, apache-noscript, ssh, apache-badbots, apache-nohome, apacheنستطيع أن نرى قيام fail2ban بتعديل قواعد الجّدار النّاري لدينا لإنشاء إطار عمل لمنع العملاء، وحتى بدون قواعد الجّدار النّاري السابقة سيكون لدينا الآن إطار عمل مُمكّن يسمح لـ fail2ban بحظر العملاء انتقائيًّا عن طريق إضافتهم إلى سلاسل chains مبنيّة لهذا الغرض: sudo iptables -S-P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT -N fail2ban-apache -N fail2ban-apache-badbots -N fail2ban-apache-nohome -N fail2ban-apache-noscript -N fail2ban-apache-overflows -N fail2ban-php-url-fopen -N fail2ban-ssh -A INPUT -p tcp -m multiport --dports 80,443 -j fail2ban-apache-nohome -A INPUT -p tcp -m multiport --dports 80,443 -j fail2ban-apache-badbots -A INPUT -p tcp -m multiport --dports 80,443 -j fail2ban-php-url-fopen -A INPUT -p tcp -m multiport --dports 80,443 -j fail2ban-apache-overflows -A INPUT -p tcp -m multiport --dports 80,443 -j fail2ban-apache-noscript -A INPUT -p tcp -m multiport --dports 80,443 -j fail2ban-apache -A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh -A fail2ban-apache -j RETURN -A fail2ban-apache-badbots -j RETURN -A fail2ban-apache-nohome -j RETURN -A fail2ban-apache-noscript -j RETURN -A fail2ban-apache-overflows -j RETURN -A fail2ban-php-url-fopen -j RETURN -A fail2ban-ssh -j RETURNوإن أردنا رؤية تفاصيل حظر مُطبَّق من قبل أي jail فمن الأسهل ربّما استخدام الأمر fail2ban-client مرة أخرى: sudo fail2ban-client status apacheStatus for the jail: apache |- filter | |- File list: /var/log/apache2/error.log | |- Currently failed: 0 | `- Total failed: 0 `- action |- Currently banned: 0 | `- IP list: `- Total banned: 0اختبار سياسات Fail2Banمن الهام اختبار سياسات fail2ban لكي نتأكّد من أنها تقوم بحظر نقل البيانات كما هو متوقّع، على سبيل المثال نستطيع إعطاء بيانات خاطئة في مُحث prompt استيثاق Apache عدّة مرات، وبعد أن نتجاوز الحدّ ينبغي أن يتم حظرنا وألا نكون قادرين على الوصول للموقع، وإن قمنا بإعداد تنبيهات البريد الإلكتروني فيجب أن نرى رسائل حول الحظر في البريد الإلكتروني الذي قمنا باختياره لاستقبال التّنبيهات. عندما ننظر إلى الحالة باستخدام الأمر fail2ban-client سنشاهد أنّ عنوان IP الخاص بنا يتم حظره من الموقع: sudo fail2ban-client status apacheStatus for the jail: apache |- filter | |- File list: /var/log/apache2/error.log | |- Currently failed: 0 | `- Total failed: 12 `- action |- Currently banned: 1 | `- IP list: 111.111.111.111 `- Total banned: 1وعندما نكون مقتنعين بأنّ قواعدنا تعمل بشكل صحيح نستطيع فك الحظر يدويًّا عن عنوان IP الخاص بنا عن طريق الأمر fail2ban-client بكتابة ما يلي: sudo fail2ban-client set apache unbanip 111.111.111.111ينبغي أن نكون الآن قادرين على محاولة الاستيثاق مرة أخرى. الخاتمةإنّ إعداد fail2ban لحماية خادوم Apache لدينا هو عمليّة سهلة إلى حدٍّ ما في أبسط الحالات، توفّر fail2ban على أيّة حال قدرًا كبيرًا من المرونة لبناء سياسات تُلائِم احتياجاتنا الأمنيّة، وبإلقاء نظرة على المتغيّرات والأنماط داخل الملف etc/fail2ban/jail.local/ والملفات التي يعتمد عليها داخل الدّليل etc/fail2ban/filter.d/ والدّليل etc/fail2ban/action.d/ نجد العديد من الأجزاء التي يمكننا تطويعها tweak وتغييرها لكي تلبّي احتياجاتنا، إنّ تعلّم أساسيّات كيفيّة حماية خادومنا باستخدام fail2ban يزوّدنا بقدرٍ كبير من الأمان وبأقل جهد. إن كنت ترغب في تعلّم المزيد حول fail2ban قم بزيارة الروابط التالية: كيف تعمل Fail2Ban لحماية الخدمات على خادوم لينِكسكيفيّة حماية SSH باستخدام Fail2Ban على Ubuntu 14.04كيفيّة حماية خادوم Nginx باستخدام Fail2Banعلى Ubuntu 14.04ترجمة -وبتصرّف- للمقال How To Protect an Apache Server with Fail2Ban on Ubuntu 14.04 لصاحبه Justin Ellingwood.

من المهم عند العمل على خادوم ويب تنفيذ تدابير أمنيّة لحماية موقعنا ومستخدمينا، إنّ حماية مواقع الإنترنت والتّطبيقات لدينا باستخدام سياسات الجّدار النّاري firewall policies وتقييد الوصول إلى بعض المناطق باستخدام استيثاق كلمة السّر password authentication هو نقطة بدء رائعة لتأمين النظام لدينا، ومع ذلك من المُرجَّح أن يجذب أي طلب لكلمة السّر مُتاح للعوام محاولات القوة القاسية brute force من قبل المستخدمين والروبوتات bots الخبيثين. يتمكّن إعداد fail2ban من المساعدة في الحد من هذه المشكلة، فعندما يفشل المستخدمون بالاستيثاق إلى خدمة ما بشكلٍ متكرّر (أو الانخراط في أي نشاط مشبوه آخر) تستطيع fail2ban أن تصدر حظرًا مؤقّتًا على عنوان IP المُهاجِم عن طريق التّعديل بشكل ديناميكي على سياسة الجّدار النّاري التي تعمل حاليًّا. تعمل كل "jail" تابعة لـ fail2ban عن طريق تفحّص السّجلّات المكتوبة من قبل خدمة ما بحثًا عن أنماط patterns تُشير إلى محاولات فاشلة بالاستيثاق. من السّهل إلى حدٍّ ما إعداد fail2ban لكي تراقب سجلّات Nginx باستخدام البعض من مُرشّحات filters الإعداد المُضمَّنة والبعض الآخر الذي سنقوم بكتابته بأنفسنا. سنشرح في هذا الدّرس كيفيّة تثبيت fail2ban وإعدادها لمراقبة سجلّات Nginx بحثًا عن محاولات التّسلّل، سنستخدم خادوم Ubuntu من أجل هذا. المتطلبات الأساسيةينبغي قبل أن نبدأ أن نمتلك خادوم Ubuntu مع إعداد حساب غير جذري non-root، ويجب أن يكون هذا الحساب مُعدًّا بامتيازات sudo من أجل إصدار أوامر إداريّة administrative commands. لكي تتعلّم كيفيّة إعداد مستخدم بامتيازات sudo اتبع دليلنا للإعداد الأولي لخادوم Ubuntu 14.04. تثبيت Nginx وإعداد استيثاق كلمة السرإن كنتَ مهتمًّا بحماية خادوم Nginx باستخدام fail2ban فمن الغالب أنك تملك مسبقًا خادومًا مُعدًّا وقيد التشغيل، وإن لم تكن كذلك تستطيع تثبيت Nginx من خلال مستودعات Ubuntu الافتراضيّة باستخدام apt. فلنقم بتحديث دليل الحِزَم المحلّي وتثبيت Nginx بكتابة ما يلي: sudo apt-get update sudo apt-get install nginxإنّ خدمة fail2ban مفيدة من أجل حماية نقاط تسجيل الدخول، ومن أجل أن يكون هذا مفيدًا لتثبيت Nginx يجب تنفيذ استيثاق كلمة السّر على الأقل لمجموعة فرعيّة من المحتوى على الخادوم، تستطيع اتباع هذا الدّليل لإعداد حماية كلمة السّر من أجل خادوم Nginx لديك. تثبيت Fail2Banبعد أن أصبح خادوم Nginx لدينا قيد التّشغيل وتمّ تمكين استيثاق كلمة السّر عليه نستطيع المضي قدمًا وتثبيت fail2ban (نقوم هنا بإدراج إعادة جلب للمستودع مرّة أخرى في حال قمتَ بالفعل بتثبيت Nginx في الخطوات السّابقة): sudo apt-get update sudo apt-get install fail2banسيقوم هذا بتثبيت برمجيّة fail2ban، والتي هي مُعدَّة افتراضيًّا لكي تحظر فقط محاولات تسجيل دخول SSH الفاشلة، نحتاج إلى تمكين بعض القواعد التي تقوم بإعدادها لكي تتفحّص سجلّات Nginx لدينا بحثًا عن أنماط تشير إلى نشاط خبيث. ضبط الإعدادات العامة داخل Fail2Banنحتاج لكي نبدأ إلى ضبط ملف الإعدادات الذي تستخدمه fail2ban لتحديد سجلّات التطبيقات التي يجب أن تراقبها والإجراءات التي يجب أن يتمّ اتخاذها عند إيجاد مُدخلات مُخالِفة، ومن الموارد الرئيسيّة التي يتم تزويدنا بها لهذا الأمر نجد الملف etc/fail2ban/jail.conf/. ولإجراء التعديلات نحتاج إلى نسخ هذا الملف إلى etc/fail2ban/jail.local/، وهذا يمنع الكتابة فوق التغييرات التي أجريناها إن قام تحديث الحِزمة package بتزويدنا بملف جديد افتراضي: sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.localنقوم بفتح الملف الجديد المنسوخ حتى نستطيع إعداد مراقبة سجلّات Nginx لدينا: sudo nano /etc/fail2ban/jail.localتغيير الإعدادات الافتراضيةينبغي أن نبدأ بتقييم المجموعة الافتراضيّة داخل الملف لنرى إن كانت تُلائِم احتياجاتنا، نستطيع إيجاد هذه المجموعة تحت قسم [DEFAULT] داخل الملف. تقوم هذه العناصر بتعيين السّياسة policy العامّة وبإمكاننا تجاوز أي منها في jails مُحدّدة. ومن أوائل العناصر التي يجب أن ننظر إليها هي قائمة العُمَلاء Clients التي لا تخضع لسياسات fail2ban، ويتم تعيينها باستخدام الأمر التّوجيهي ignoreip، من الجّيد أحيانًا إضافة عنوان IP الخاص بنا أو بشبكتنا إلى قائمة الاستثناءات لتجنّب حظر أنفسنا، على الرّغم من أنّ هذا أقل من أن يكون مشكلة مع تسجيلات الدّخول إلى خادوم الويب إن كان بإمكاننا المحافظة على النفاذ للـ Shell، حيث أنّنا دائمًا نستطيع إلغاء الحظر يدويًّا. نستطيع إضافة عناوين IP أو شبكات إضافيّة بفصلها بمسافة Space إلى القائمة الحاليّة: etc/fail2ban/jail.local/ [DEFAULT] . . . ignoreip = 127.0.0.1/8 your_home_IPومن العناصر الأخرى التي قد نرغب بضبطها نجد bantime والذي يتحكّم بعدد الثّواني التي سيتم خلالها حظر العضو المُخالِف، من المثالي تعيينه إلى مدّة طويلة كافية لتكون مُدمِّرة لجهود المستخدم الخبيث، وفي نفس الوقت قصيرة بما فيه الكفاية لتسمح للمستخدمين الشرعيّين لتصحيح أخطائهم، يتم تعيين هذه القيمة افتراضيًّا إلى 600 ثانية (10 دقائق)، قم بزيادتها أو إنقاصها على النحو الذي تراه مناسبًا: etc/fail2ban/jail.local/ [DEFAULT] . . . bantime = 3600يُحدّد العنصران التّاليان نطاق أسطر السّجلّات المستخدمة لتحديد العميل المُخالِف، يُحدِّد findtime المدّة الزمنية مُقدّرةً بالثواني ويُشير الأمر التّوجيهي maxretry إلى عدد المحاولات التي يتم التسامح معها خلال تلك المدّة، فإن قام العميل بعدد محاولات أكثر من maxretry خلال المدّة الزمنيّة المُحدّدة بواسطة findtime فسيتمّ حظره: etc/fail2ban/jail.local/ [DEFAULT] . . . findtime = 3600 # These lines combine to ban clients that fail maxretry = 6 # to authenticate 6 times within a half hourإعداد تنبيهات البريد الإلكتروني (اختياري)نستطيع تمكين تنبيهات البريد الإلكتروني إن كُنّا نرغب باستقبال بريد كلّما حدث حظر، ويتوجب علينا أولًا لفعل هذا أن نقوم بإعداد MTA على خادومنا بحيث يستطيع إرسال بريد إلكتروني، لتتعلّم كيفيّة استخدام Postfix من أجل هذه المهمّة اتبع هذا الدّليل. ويتوجّب علينا بعد الانتهاء من إعداد MTA أن نقوم بضبط بعض الإعدادات الإضافيّة داخل القسم [DEFAULT] من الملف etc/fail2ban/jail.local/. نبدأ بإعداد الأمر التّوجيهي mta، فإن قمنا بإعداد Postfix -كما هو واضح في الدّرس التعليمي المذكور بالأعلى- نُغيّر هذه القيمة إلى “mail”: etc/fail2ban/jail.local/ [DEFAULT] . . . mta = mailيجب أن نختار عنوان البريد الإلكتروني الذي سيتم إرسال التنبيهات إليه ونكتبه داخل الأمر التّوجيهي destemail، بإمكاننا استخدام الأمر التّوجيهي sendername لتعديل حقل المُرسِل Sender في تنبيهات البريد الإلكتروني: etc/fail2ban/jail.local/ [DEFAULT] . . . destemail = youraccount@email.com sendername = Fail2BanAlertsإنّ الإجراء action -بحسب تعبير fail2ban- هو العمليّة التي تتلو فشل العميل بالاستيثاق مرات كثيرة، الإجراء الافتراضي (يُدعى action_) هو ببساطة حظر عنوان الـ IP من المنفذ port قيد الطلب، ويوجد على أيّة حال إجراءان آخران مُعدّان مُسبقًا يُمكن استخدامهما إن كنّا نملك إعداد بريد إلكتروني. نستطيع استخدام الإجراء action_mw لحظر العميل وإرسال تنبيه بريد إلكتروني إلى الحساب المضبوط لدينا مع تقرير “whois” حول عنوان المُخالِف، بإمكاننا أيضًا استخدام الإجراء action_mwl والذي يقوم بنفس العمل ولكن يقوم بتضمين سطور سجلّات المُخالِف والتي قامت بإطلاق عمليّة الحظر: etc/fail2ban/jail.local/ [DEFAULT] . . . action = %(action_mwl)s إعداد Fail2Ban لمراقبة سجلات Nginxبعد أن قمنا بضبط بعض إعدادات fail2ban العامّة في مكانها الصحيح نستطيع التركيز على تمكين بعض jails المرتبطة بـ Nginx والتي ستراقب سجلّات خادوم الويب لدينا بحثًا عن أنماط سلوك مُعيّن. تتميّز كل jails داخل ملف الإعدادات بترويسة header تحتوي اسم الـ jail بين قوسين مربّعين (كل قسم يشير إلى إعدادات jail مُحدّدة ما عدا القسم [DEFAULT])، وافتراضيًّا نجد ssh] jail] هي الوحيدة المُمكّنة. لتمكين مراقبة السّجلّات بحثًا عن محاولات تسجيل دخول Nginx سنقوم بتمكين [jail [nginx-http-auth، نُعدّل الأمر التّوجيهي enabled داخل هذا القسم بحيث يصبح true: etc/fail2ban/jail.local/ [nginx-http-auth] enabled = true filter = nginx-http-auth port = http,https logpath = /var/log/nginx/error.log . . .إنّ jail السّابقة هي jail الوحيدة الخاصّة بـ Nginx التي يتم تضمينها مع حزمة fail2ban الخاصّة بـ Ubuntu. نستطيع على أيّة حال إنشاء jails الخاصّة بنا لإضافة وظائف إضافيّة، نجد في هذا الرابط بعض من تفاصيل تنفيذ jails الإضافيّة هنا وهنا. بإمكاننا إنشاء nginx-noscript] jail] لحظر العملاء الذين يبحثون عن تنفيذ واستغلال Script على الموقع، إن لم نكن نستخدم PHP أو أي لغة برمجة أخرى بالتزامن مع خادوم الويب لدينا فبإمكاننا إضافة هذه الـ jail لحظر من يطلب هذا النوع من الموارد: etc/fail2ban/jail.local/ [nginx-noscript] enabled = true port = http,https filter = nginx-noscript logpath = /var/log/nginx/access.log maxretry = 6 . . .نستطيع إضافة قسم يُدعى [nginx-badbots] لإيقاف بعض أنماط طلبات الروبوتات الخبيثة المعروفة: etc/fail2ban/jail.local/ [nginx-badbots] enabled = true port = http,https filter = nginx-badbots logpath = /var/log/nginx/access.log maxretry = 2وإن لم نكن نستخدم Nginx لتزويدنا بالنفاذ إلى محتوى الويب داخل الدّليل الرئيسي Home directory للمستخدم فبإمكاننا حظر المستخدمين الذين يطلبون هذه الموارد بإضافة nginx-nohome] jail]: etc/fail2ban/jail.local/ [nginx-nohome] enabled = true port = http,https filter = nginx-nohome logpath = /var/log/nginx/access.log maxretry = 2ينبغي علينا حظر العملاء الذين يحاولون استخدام خادوم Nginx لدينا كوسيط مفتوح open proxy، نستطيع إضافة nginx-noproxy] jail] لتتناسب مع هذه الطلبات: etc/fail2ban/jail.local/ [nginx-noproxy] enabled = true port = http,https filter = nginx-noproxy logpath = /var/log/nginx/access.log maxretry = 2بعد أن ننتهي من التعديلات التي نرغب بها نحفظ الملف ونغلقه، يتوجّب علينا الآن إضافة المُرشّحات filters من أجل jails التي قمنا بإنشائها. إضافة المرشحات من أجل Nginx Jails الإضافيةلقد قمنا بتحديث الملف etc/fail2ban/jail.local/ ببعض مواصفات jail الإضافيّة لتتناسب مع حظر مدى كبير من السّلوك السّيء، نحتاج لإنشاء ملفات ترشيح filter من أجل jails التي أنشأناها، حيث تُحدّد هذه الملفات الأنماط التي سنبحث عنها داخل سجلّات Nginx. فلنبدأ بالانتقال إلى دليل المُرشّحات filters: cd /etc/fail2ban/filter.dنريد فعليًّا أن نبدأ بضبط مُرشِّح الاستيثاق المزوّد مُسبقًا مع Nginx لكي يتناسب مع أنماط فشل تسجيل الدّخول الموجودة في السّجلّات، نفتح الملف لتحريره: sudo nano nginx-http-auth.confنُضيف نمط جديد تحت التّخصيص failregex، حيث يتناسب هذا النّمط مع الأسطر التي توافق عدم إدخال المستخدم لاسم مستخدم أو كلمة سر: etc/fail2ban/filter.d/nginx-http-auth.conf/ [Definition] failregex = ^ \[error\] \d+#\d+: \*\d+ user "\S+":? (password mismatch|was not found in ".*"), client: <HOST>, server: \S+, request: "\S+ \S+ HTTP/\d+\.\d+", host: "\S+"\s*$ ^ \[error\] \d+#\d+: \*\d+ no user/password was provided for basic authentication, client: <HOST>, server: \S+, request: "\S+ \S+ HTTP/\d+\.\d+", host: "\S+"\s*$ ignoreregex =بعد الانتهاء نقوم بحفظ وإغلاق الملف. بعد ذلك نستطيع نسخ الملف apache-badbots.conf لاستخدامه مع Nginx، بإمكاننا استخدام الملف كما هو ولكن سنقوم بنسخه إلى اسم آخر من أجل التوضيح، يتطابق هذا مع مرجعيّة المُرشّح التي قمنا بها داخل إعدادات jail: sudo cp apache-badbots.conf nginx-badbots.confننشئ بعد ذلك مُرشّح من أجل nginx-noscript] jail]: sudo nano nginx-noscript.confنلصق التعريف التالي بداخله، ونترك لك الخيار في ضبط اللواحق في الـ Script لكي تزيل ملفّات لغات البرمجة التي يستخدمها الخادوم لديك بشكل شرعي أو لكي تضيف لواحق أخرى: etc/fail2ban/filter.d/nginx-noscript.conf/ [Definition] failregex = ^<HOST> -.*GET.*(\.php|\.asp|\.exe|\.pl|\.cgi|\.scgi) ignoreregex =نقوم بحفظ الملف وإغلاقه. ننشئ بعد ذلك مُرشّحًا من أجل nginx-nohome] jail]: sudo nano nginx-nohome.confنضع معلومات المرشّح التالية في الملف: etc/fail2ban/filter.d/nginx-nohome.conf/ [Definition] failregex = ^<HOST> -.*GET .*/~.* ignoreregex =بعد الانتهاء نقوم بحفظ وإغلاق الملف. بإمكاننا أخيرًا إنشاء المرشّح من أجل nginx-noproxy] jail]: sudo nano nginx-noproxy.confيتوافق تعريف المرشّح مع محاولات استخدام خادومنا كوسيط proxy: etc/fail2ban/filter.d/nginx-noproxy.conf/ [Definition] failregex = ^<HOST> -.*GET http.* ignoreregex =بعد الانتهاء نقوم بحفظ وإغلاق الملف. تفعيل Nginx Jails لدينالكي يتم تنفيذ تغييراتنا على الإعدادات نحتاج إلى إعادة تشغيل خدمة fail2ban، نستطيع فعل ذلك بكتابة ما يلي: sudo service fail2ban restartينبغي أن يتم إعادة تشغيل الخدمة وتنفيذ سياسات الحظر المختلفة التي قمنا بإعدادها. الحصول على معلومات حول Jails التي تم تمكينهانستطيع رؤية جميع jails التي تمّ تمكينها لدينا باستخدام الأمر fail2ban-client: sudo fail2ban-client statusينبغي أن نشاهد قائمة بكامل jails التي قمنا بتمكينها: Status |- Number of jail: 6 `- Jail list: nginx-noproxy, nginx-noscript, nginx-nohome, nginx-http-auth, nginx-badbots, sshنستطيع النظر إلى iptables لكي نرى أنّ fail2ban قامت بتعديل قواعد الجّدار النّاري لدينا لإنشاء إطار عمل لمنع العملاء، وحتى بدون قواعد الجّدار النّاري السابقة سيكون لدينا الآن إطار عمل مُمكّن يسمح لـ fail2ban بحظر العملاء انتقائيًّا عن طريق إضافتهم إلى سلاسل chains مبنيّة لهذا الغرض: sudo iptables -S-P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT -N fail2ban-nginx-badbots -N fail2ban-nginx-http-auth -N fail2ban-nginx-nohome -N fail2ban-nginx-noproxy -N fail2ban-nginx-noscript -N fail2ban-ssh -A INPUT -p tcp -m multiport --dports 80,443 -j fail2ban-nginx-noproxy -A INPUT -p tcp -m multiport --dports 80,443 -j fail2ban-nginx-nohome -A INPUT -p tcp -m multiport --dports 80,443 -j fail2ban-nginx-badbots -A INPUT -p tcp -m multiport --dports 80,443 -j fail2ban-nginx-noscript -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-badbots -j RETURN -A fail2ban-nginx-http-auth -j RETURN -A fail2ban-nginx-nohome -j RETURN -A fail2ban-nginx-noproxy -j RETURN -A fail2ban-nginx-noscript -j RETURN -A fail2ban-ssh -j RETURNوإن أردنا رؤية تفاصيل حظر مُطبَّق من قبل أي jail فمن الأسهل ربّما استخدام الأمر fail2ban-client مرة أخرى: sudo fail2ban-client status nginx-http-authStatus for the jail: nginx-http-auth |- filter | |- File list: /var/log/nginx/error.log | |- Currently failed: 0 | `- Total failed: 0 `- action |- Currently banned: 0 | `- IP list: `- Total banned: 0اختبار سياسات Fail2Banمن الهام اختبار سياسات fail2ban لكي نتأكّد من أنها تقوم بحظر نقل البيانات كما هو متوقّع، على سبيل المثال نستطيع إعطاء بيانات خاطئة في مُحث prompt استيثاق Nginx عدّة مرات، وبعد أن نتجاوز الحدّ ينبغي أن يتم حظرنا وألا نكون قادرين على الوصول للموقع، وإن قمنا بإعداد تنبيهات البريد الإلكتروني فيجب أن نرى رسائل حول الحظر في البريد الإلكتروني الذي قمنا باختياره لاستقبال التّنبيهات. عندما ننظر إلى الحالة باستخدام الأمر fail2ban-client سنشاهد أنّ عنوان IP الخاص بنا يتم حظره من الموقع: sudo fail2ban-client status nginx-http-auth Status for the jail: nginx-http-auth |- filter | |- File list: /var/log/nginx/error.log | |- Currently failed: 0 | `- Total failed: 12 `- action |- Currently banned: 1 | `- IP list: 111.111.111.111 `- Total banned: 1وعندما نكون مقتنعين بأنّ قواعدنا تعمل بشكل صحيح نستطيع فك الحظر يدويًّا عن عنوان IP الخاص بنا عن طريق الأمر fail2ban-client بكتابة ما يلي: sudo fail2ban-client set nginx-http-auth unbanip 111.111.111.111 نبغي أن نكون الآن قادرين على محاولة الاستيثاق مرة أخرى. الخاتمةإنّ إعداد fail2ban لحماية خادوم Nginx لدينا هو عمليّة سهلة إلى حدٍّ ما في أبسط الحالات، توفّر fail2ban على أيّة حال قدرًا كبيرًا من المرونة لبناء سياسات تُلائِم احتياجاتنا الأمنيّة، وبإلقاء نظرة على المتغيّرات والأنماط داخل الملف etc/fail2ban/jail.local/ والملفات التي يعتمد عليها داخل الدّليل etc/fail2ban/filter.d/ والدّليل etc/fail2ban/action.d/ نجد العديد من الأجزاء التي يمكننا تطويعها tweak وتغييرها لكي تلبّي احتياجاتنا، إنّ تعلّم أساسيّات كيفيّة حماية خادومنا باستخدام fail2ban يزوّدنا بقدرٍ كبير من الأمان وبأقل جهد. إن كنت ترغب في تعلّم المزيد حول fail2ban قم بزيارة الروابط التالية: كيف تعمل Fail2Ban لحماية الخدمات على خادوم لينِكس.كيفيّة حماية SSH باستخدام Fail2Ban على Ubuntu 14.04.ترجمة -وبتصرّف- لـ How To Protect an Nginx Server with Fail2Ban on Ubuntu 14.04 لصاحبه Justin Ellingwood.

من المرغوب عادةً عند الانتقال من خادوم إلى آخر أن تُنقَل قواعد الجدار الناري iptables كجزءٍ من العملية؛ سيشرح هذا الدرس لك كيف تنسخ بسهولة القواعد المُفعّلة لجدار iptables من خادوم إلى آخر. المتطلبات المسبقةيتطلب هذا الدرس وجود خادومَين؛ سنشير إلى الخادوم المصدر (الذي توجد فيه قواعد iptables) بالخادوم A، والخادوم الوجهة (الذي ستُنقَل إليه القواعد) بالخادوم B. ستحتاج إلى امتيازات الجذر على كلي الخادومين. عرض قواعد Iptables الموجودةقبل نقل قواعد iptables، لننظر إليها أولًا؛ يمكنك فعل ذلك عبر تطبيق هذا الأمر على الخادوم A: sudo iptables -Sمثالٌ عن ناتج الأمر السابق: -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT 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 -s 15.15.15.51/32 -j DROPستُستخدَم القواعد الناتجة في المثال السابق لشرح عملية نقل الجدار الناري. تصدير قواعد Iptablesيكتب الأمر iptables-save قواعد iptables الحالية إلى stdout (مجرى الخرج القياسي)؛ مما يمنحنا طريقةً سهلةً لتصدير قواعد الجدار الناري إلى ملف، وذلك عبر إعادة توجيه stdout إلى ملف. استخدم الأمر iptables-save على الخادوم A -الذي تريد نقل القواعد منه- لتصدير القواعد الحالية إلى ملف باسم «iptables-export» كما يلي: cd ~ sudo iptables-save > iptables-exportهذا سيُنشئ الملف iptables-export في مجلد المنزل (home) الخاص بمستخدمك؛ يمكن أن يُستخدَم هذا الملف على خادومٍ آخر لتحميل قواعد الجدار الناري إلى iptables. عرض محتويات الملف (خطوة اختيارية)لنلقِ نظرةً سريعةً على محتويات الملف؛ سنستخدم الأمر cat لإظهار الملف على الطرفية: cat iptables-exportسيكون ناتج الأمر السابق شبيهًا بما يلي: # Generated by iptables-save v1.4.21 on Tue Sep 1 17:32:29 2015 *filter :INPUT ACCEPT [135:10578] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [8364:1557108] -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 -s 15.15.15.51/32 -j DROP COMMIT # Completed on Tue Sep 1 17:32:29 2015كما لاحظت، يحتوي الملف على ضبط قواعد iptables المُفعّلة؛ نحن جاهزون الآن لنسخ هذا الملف إلى الوجهة، التي هي الخادوم B. نسخ القواعد المصدرة إلى الخادوم الوجهةسنحتاج إلى نسخ ملف القواعد إلى الخادوم الوجهة (الخادوم B)؛ أسهل طريقة لفعل ذلك هي استخدام scp أو نسخ محتويات الملف ثم لصقها في ملفٍ جديد على الخادوم B. سنشرح كيفية استخدام الأمر scp لنسخ الملف عبر الشبكة إلى مجلد ‎/tmp. نفِّذ أمر scp الآتي على الخادوم A؛ تأكد أنك قد استبدلت الأجزاء المعلّمة ببيانات دخولك إلى الخادوم وعنوان IP له: scp iptables-export *user*@*server_b_ip_address*:/tmpسيُنسَخ الملف إلى مجلد ‎/tmp في الخادوم B بعد الاستيثاق (authentication)؛ الحظ أن محتويات المجلد ‎/tmp ستُحذَف عند إعادة الإقلاع، لذا يمكنك نسخ ذاك الملف إلى مكانٍ آخر إن أردت الاحتفاظ به. استيراد قواعد Iptablesبعد نسخ القواعد المُصدَّرة إلى الخادوم الوجهة، فيمكننا الآن تحميلها إلى iptables؛ لكن -وبالاعتماد على بيئتك- ربما تحتاج إلى تحديث القواعد في الملف ووضع عناوين ومجالات IP جديدة، وربما تريد أيضًا أن تعدِّل أسماء البطاقات الشبكيّة؛ إذا أردت أن تعدِّل القواعد قبل تحميلها، فعليك تعديل الملف ‎/tmp/iptables-export الآن. بعد أن تكون جاهزًا لتحميل القواعد من ملف iptables-export إلى iptables، فاستخدم الأمر iptables-restore لفعل ذلك. على الخادوم الوجهة (الخادوم B)، نفِّذ هذا الأمر لتحميل قواعد الجدار الناري: sudo iptables-restore < /tmp/iptables-exportسيحمِّل الأمر السابق القواعد إلى ipables، يمكنك التحقق من تحميلها بوساطة الأمر sudo iptables -S. حفظ القواعدتكون قواعد Iptables مؤقتةً، لذلك يجب أخذ الحيطة عند التعامل معها للحفاظ عليها حتى بعد إعادة الإقلاع؛ سيكون عليك تنفيذ هذه الخطوة على الخادوم B. سنشرح كيفية حفظ القواعد على توزيعتَي أوبنتو و CentOS. توزيعة أوبنتوإن أسهل طريقة لحفظ قواعد Iptables في أوبنتو لكي تبقى بعد إعادة الإقلاع هي استخدام حزمة iptables-persistent؛ يمكنك تثبيتها باستخدام الأمر apt-get: sudo apt-get install iptables-persistentستُسأل أثناء التثبيت إذا ما كنتَ تريد حفظ قواعد الجدار الناري الحالية؛ اختر yes إذا أردت حفظها. إذا حدَّثتَ قواعد جدارك الناري في المستقبل، وأردت حفظ التعديلات، فنفِّذ هذا الأمر: sudo invoke-rc.d iptables-persistent saveتوزيعة CentOS 6 وما قبلهاعلى توزيعة CentOS 6 وما قبلها (حيث تستخدم CentOS 7 افتراضيًا جدار FirewallD الناري)، يمكنك استخدام سكربت init الخاص بتطبيق iptables لحفظ القواعد: sudo service iptables saveسيحفظ الأمر السابق قواعد iptables الحالية إلى الملف ‎/etc/sysconfig/iptables، الذي يحمَّل بوساطة iptables عند الإقلاع. الخلاصةتهانينا، لقد أتممت نقل قواعد جدارك الناري من خادومك الأصلي إلى خادومك الجديد. ترجمة -وبتصرف- للمقال: How To Migrate Iptables Firewall Rules to a New Server لصاحبه: Mitchell Anicas.

إن UFW هو أداةٌ لضبط iptables موجودٌ افتراضيًا في أوبنتو؛ يوفِّر هذا الدرس مرجعًا سريعًا لأوامر UFW التي ستُنشِئ قواعد جدار iptables الناري لحالات الاستخدام الشائعة، وهذا يتضمن أمثلةً عن استخدام UFW للسماح وحجب مختلف الخدمات عبر المنفذ، والبطاقة الشبكيّة، وعنوان IP المصدر. كيف تستخدم هذا الدرسإذا كنت قد بدأت لتوِّك باستخدام UFW لضبط جدارك الناري، فراجع الدرس تمهيد إلى UFW.تفترض أغلبية القواعد المشروحة هنا أنك تستخدم مجموعة قواعد UFW الافتراضية؛ التي تكون مضبوطةً للسماح بالاتصالات الصادرة وحجب الاتصالات الواردة، لذا عليك أن تنتقي البيانات التي تريد تمريرهااستعمل الأمثلة الموجودة في الأقسام المتتالية الملائمة لما تودّ تحقيقه؛ لا تعتمد أغلبية الأقسام في هذا الدرس على بعضها بعضًا، لذا يمكنك استخدام الأمثلة الآتية استخدامًا مستقلًاانسخ والصق الأمثلة عن الأوامر الموجودة في هذا الدرس، مستبدلًا قيمك بالقيم المُعلَّمة بالأحمرتذكر أنك تستطيع أن تتحقق من مجموعة قواعد UFW الحالية عبر الأمر sudo ufw status أو sudo ufw status verbose. حجب عنوان IPنفِّذ الأمر الآتي لحجب جميع الاتصالات الشبكية التي تُنشَأ من عنوان IP معيّن، مثلًا 15.15.15.51: sudo ufw deny from 15.15.15.51يُحدِّد التعبير from 15.15.15.51 في المثال السابق عنوان IP مصدري (source IP) هو «15.15.15.51»؛ يمكنك تحديد شبكة فرعية مثل 15.15.15.0/24 إن أردت ذلك. يمكن تحديد عنوان IP مصدري في أيّة قاعدة من قواعد الجدار الناري، بما في ذلك قاعدة allow. حجب الاتصالات إلى بطاقة شبكية معينةاستعمل هذا الأمر لحجب جميع الاتصالات من عنوان IP محدد (على سبيل المثال، 15.15.15.51) إلى بطاقة شبكيّة معيّنة، مثل eth0: sudo ufw deny in on eth0 from 15.15.15.51يشبه هذا الأمرُ الأمرَ السابق، لكن مع زيادة التعبير in on eth0. يمكن تحديد البطاقة الشبكية في أيّة قاعدة من قواعد الجدار الناري، وهذه طريقةٌ ممتازةٌ لتحديد الدور الذي تلعبه بطاقة شبكية معيّنة. خدمة SSHإذا كنتَ تستخدم خادومًا سحابيًا، فربما تريد السماح لاتصالات SSH الواردة (المنفذ 22) لذا يمكنك الاتصال وإدارة خادومك؛ يشرح هذا القسم كيف تَضبط جدارك الناري بمختلف القواعد المتعلقة بخدمة SSH. السماح لاتصالات SSHتستطيع استخدام الأمر الآتي للسماح باتصالات SSH الواردة: sudo ufw allow sshصيغةٌ بديلةٌ عن الصيغةِ السابقة هي تحديد رقم المنفذ بدلًا من اسم خدمة SSH: sudo ufw allow 22السماح لاتصالات SSH الواردة من عنوان IP معين أو شبكة فرعيةللسماح باتصالات SSH الواردة من عنوان IP معيّن أو شبكة فرعية، فعليك تحديد المصدر؛ على سبيل المثال، إذا أردت السماح لكامل الشبكة الفرعية 15.15.15.0/24، فنفِّذ هذا الأمر: sudo ufw allow from 15.15.15.0/24 to any port 22السماح لاتصالات Rsync الواردة من عنوان IP معين أو شبكة فرعيةيمكن أن يُستخدَم Rsync (الذي يعمل على المنفذ 873) لنقل الملفات من حاسوبٍ إلى آخر. للسماح باتصالات rsync الواردة من عنوان IP معيّن أو شبكة فرعية، فحدد عنوان IP المصدري والمنفذ الوجهة؛ على سبيل المثال، إذا أردت السماح لكامل الشبكة الفرعية 15.15.15.0/24 باستخدام rsync على خادومك، فنفِّذ الأمر الآتي: sudo ufw allow from 15.15.15.0/24 to any port 873خادم الويبتستمع خوادم الويب -مثل أباتشي و Nginx- للطلبيات على المنفذين 80 و 443 لاتصالات HTTP و HTTPS على التوالي وبالترتيب. إذا كانت السياسة الافتراضية للاتصالات الواردة هي الحجب أو التجاهل، فربما تريد إنشاء قواعد تسمح لخادومك بالرد على تلك الطلبيات. السماح لجميع اتصالات HTTP الواردةاستخدم الأمر الآتي للسماح لجميع اتصالات HTTP (المنفذ 80) الواردة: sudo ufw allow httpصيغةٌ بديلةٌ عن الصيغةِ السابقة هي تحديد رقم المنفذ بدلًا من اسم خدمة HTTP: sudo ufw allow 80السماح لجميع اتصالات HTTPS الواردةاستخدم الأمر الآتي للسماح لجميع اتصالات HTTPS (المنفذ 443) الواردة: sudo ufw allow httpsصيغةٌ بديلةٌ عن الصيغةِ السابقة هي تحديد رقم المنفذ بدلًا من اسم خدمة HTTPS: sudo ufw allow 443السماح لجميع اتصالات HTTP و HTTPS الواردةإذا أردت السماح لاتصالات HTTP و HTTPS معًا، فيمكنك إنشاء قاعدة وحيدة تسمح لكلي المنفذين؛ وذلك بتنفيذ الأمر الآتي: sudo ufw allow proto tcp from any to any port 80,443الحظ أنك ستحتاج إلى تحديد البروتوكول (باستخدام proto tcp) عند تحديد عدِّة منافذ. قواعد بيانات MySQLتستمع MySQL إلى اتصالات العميل على المنفذ 3306؛ إذا كان سيُستخدَم خادم قواعد بيانات MySQL من عميلٍ على خادوم بعيد؛ فتأكد أنك تسمح بمرور تلك البيانات الشبكية. السماح لاتصالات MySQL الواردة من عنوان IP معين أو شبكة فرعيةللسماح باتصالات MySQL الواردة من عنوان IP معيّن أو شبكة فرعية، فحدِّد المصدر؛ على سبيل المثال، تستطيع تنفيذ هذا الأمر إذا أردت السماح للشبكة الفرعية 15.15.15.0/24: sudo ufw allow from 15.15.15.0/24 to any port 3306السماح لاتصالات MySQL الواردة إلى بطاقة شبكية معينةاستخدم الأمر الآتي للسماح لاتصالات MySQL لبطاقة شبكيّة معيّنة -لنفترض أنّك تملك بطاقة شبكيّة خاصة باسم eth1-: sudo ufw allow in on eth1 to any port 3306قواعد بيانات PostgreSQLتستمع PostgreSQL إلى اتصالات العميل على المنفذ 5432 إذا كان سيُستخدَم خادم قواعد بيانات PostgreSQL من عميلٍ على خادوم بعيد؛ فتأكد أنك تسمح بمرور تلك البيانات الشبكية. السماح لاتصالات PostgreSQL الواردة من عنوان IP معين أو شبكة فرعيةللسماح باتصالات PostgreSQL الواردة من عنوان IP معيّن أو شبكة فرعية، فحدِّد المصدر؛ على سبيل المثال، تستطيع تنفيذ هذا الأمر إذا أردت السماح للشبكة الفرعية 15.15.15.0/24: sudo ufw allow from 15.15.15.0/24 to any port 5432السماح لاتصالات PostgreSQL الواردة إلى بطاقة شبكية معينةاستخدم الأمر الآتي للسماح لاتصالات PostgreSQL لبطاقة شبكيّة معيّنة -لنفترض أنّك تملك بطاقة شبكيّة خاصة باسم eth1-: sudo ufw allow in on eth1 to any port 5432خدمة البريدتستمع خوادم البريد مثل Sendmail و Postfix إلى تشكيلة واسعة من المنافذ بناءً على البروتوكولات المستخدمة لتوصيل البريد؛ إذا كنت تُشغِّل خادوم بريدٍ إلكتروني، فحدِّد البروتوكولات التي تستخدمها واسمح للاتصالات الموافقة لها. سنستعرض أيضًا مثالًا عن إنشاء قاعدة لحجب بريد SMTP الصادر. حجب بريد SMTP الصادرربما تريد أن تحجب بريد SMTP الصادر إذا لم يكن من المفترض لخادومك أن يُرسِل بريدًا إلكترونيًّا؛ استخدم الأمر الآتي لحجب بريد SMTP الصادر (الذي يستخدم المنفذ 25): sudo ufw deny 25يضبط الأمر السابق خادومك لتجاهل كل البيانات المُرسَلة على المنفذ 25؛ إذا أردت أن تحجب خدمةً أخرى عبر رقم منفذها، فضع رقم المنفذ الخاص بها بدلًا من 25. السماح لجميع اتصالات SMTP الواردةللسماح لخادومك بالرد على اتصالات SMTP على المنفذ 25، فعليك تنفيذ الأمر الآتي: sudo ufw allow 25ملاحظة: من الشائع لخوادم SMTP أن تستخدم المنفذ 587 للبريد الصادر. السماح لجميع اتصالات IMAP الواردةللسماح لخادومك بالرد على اتصالات IMAP على المنفذ 143، فعليك تنفيذ الأمر الآتي: sudo ufw allow 143السماح لجميع اتصالات IMAPS الواردةللسماح لخادومك بالرد على اتصالات IMAPS على المنفذ 993، فعليك تنفيذ الأمر الآتي: sudo ufw allow 993السماح لجميع اتصالات POP3 الواردةللسماح لخادومك بالرد على اتصالات POP3 على المنفذ 110، فعليك تنفيذ الأمر الآتي: sudo ufw allow 110السماح لجميع اتصالات POP3S الواردةللسماح لخادومك بالرد على اتصالات POP3S على المنفذ 995، فعليك تنفيذ الأمر الآتي: sudo ufw allow 995الخلاصةيجب أن يكون قد غطى هذا الدرس الكثير من الأوامر شائعة الاستخدام عند استعمال UFW لضبط الجدار الناري؛ وبالطبع إن UFW هو أداةٌ مرنةٌ جدًا، لذلك تستطيع دمج مختلف الخيارات مع الأوامر السابقة لملائمة متطلبات خادومك إن لم تكن تلك الأوامر مبيّنةً هنا. ترجمة -وبتصرف- للمقال: UFW Essentials: Common Firewall Rules and Commands لصاحبه: Mitchell Anicas.

Iptables هو برمجية جدار ناري مضمَّنة افتراضيًّا في أغلبية توزيعات لينُكس. يوفِّر هذا الدرس مرجعًا سريعًا لأوامر iptables التي ستُنشِئ قواعدًا لحالات الاستخدام الشائعة، وهذا يتضمن أمثلةً عن استخدام iptables للسماح وحجب مختلف الخدمات عبر المنفذ، والبطاقة الشبكيّة، وعنوان IP المصدر. كيف تستخدم هذا الدرسإذا كنت قد بدأت لتوِّك باستخدام iptables لضبط جدارك الناري، فراجع الدرس تمهيد إلى iptables.تفترض أغلبية القواعد المشروحة هنا أنَّ iptables مضبوطٌ لتجاهل الاتصالات الواردة عبر السياسة الافتراضية، لذا عليك أن تنتقي البيانات التي تريد تمريرها.استعمل الأمثلة الموجودة في الأقسام المتتالية الملائمة لما تودّ تحقيقه؛ لا تعتمد أغلبية الأقسام في هذا الدرس على بعضها بعضًا، لذا يمكنك استخدام الأمثلة الآتية استخدامًا مستقلًا.انسخ والصق الأمثلة عن الأوامر الموجودة في هذا الدرس، مستبدلًا قيمك بالقيم المُعلَّمة بالأحمر.أبقِ في بالك أنَّ ترتيب القواعد مهم؛ تستخدم جميع أوامر iptables الآتية الخيار ‎-A الذي يُلحِق (append) القاعدة الجديدة إلى نهاية سلسلة، إذا أردت وضعها في مكانٍ آخر، فيمكنك استخدام الخيار ‎-I الذي يسمح لك بتحديد موقع القاعدة الجديدة (أو ببساطة وضعها في بداية السلسلة [chain] إن لم تُحدِّد رقمًا للقاعدة). ملاحظة: احذر عند العمل مع الجدر النارية أن تمنع نفسك من الدخول إلى خادومك عبر حجب اتصالات SSH (المنفذ 22 افتراضيًّا)؛ إذا فقدت القدرة على الوصول إلى خادومك بسبب ضبط جدارك الناري، فستحتاج إلى الدخول عبر !طرفية محلية! لتقويم الخلل. بعد أن تسجل دخولك عبر الطرفية المحلية، يمكنك تعديل قواعد جدارك الناري للسماح بالوصول إلى خدمة SSH (أو السماح بعبور جميع بيانات التراسل الشبكي)؛ إذا كانت قواعد جدارك الناري المحفوظة تسمح بالوصول عبر SSH، فستتمكن عبر إعادة تشغيل الخادوم من الاتصال مجددًا عبر SSH. تذكَّر أنك تستطيع التحقق من مجموعة قواعد iptables الحالية بالأمرَين sudo iptables -S و sudo iptables -L. لنلقِ نظرةً على أوامر iptables. حفظ القواعدتكون قواعد iptables مؤقتة، مما يعني أنه من الضروري حفظها يدويًا لكي تبقى بعد إعادة الإقلاع. توزيعة أوبنتوأسهل طريقة لحفظ قواعد iptables في أوبنتو كي تبقى حتى لو أُعيد الإقلاع هي استخدام الحزمة iptables-persistent؛ ثبِّتها عبر apt-get كما يلي: sudo apt-get install iptables-persistentستُسأل أثناء التثبيت إذا ما كنت تريد حفظ قواعد جدارك الناري الحالية. إذا حدَّثت قواعد جدارك الناري وأردت حفظ التغييرات، فنفِّذ الأمر الآتي: sudo invoke-rc.d iptables-persistent saveتوزيعة CentOS 6 وما قبلهايمكنك استخدام سكربت init لجدار iptables لحفظ القواعد في توزيعة CentOS 6 وما قبلها (تَستخدم توزيعة CentOS 7 جدار FirewallD افتراضيًّا): sudo service iptables saveسيحفظ الأمر السابق قواعد iptables الحالية إلى ملف ‎/etc/sysconfig/iptables. قواعد مفيدة عمومايتضمن هذا القسم تشكيلةً من أوامر iptables التي ستُنشِئ قواعدًا مفيدةً في أغلبية الخواديم. السماح بالاتصالات إلى بطاقة Loopbackبطاقة «loopback» (التي يُشار إليها أيضًا بالاسم lo) هي البطاقة التي يستخدمها الحاسوب لإجراء اتصالات شبكيّة مع نفسه؛ على سبيل المثال، إذا شغَّلت ping localhost أو ping 127.0.0.1، فإن خادومك سيجري عملية ping لنفسه باستخدام بطاقة loopback؛ يمكن الاستفادة أيضًا من بطاقة loopback إذا ضَبطتَ تطبيقك للاتصال إلى خادوم قواعد بيانات ذي العنوان «localhost»؛ ولهذا عليك أن تتأكد أنَّ جدارك الناري يسمح بمرور لهذه الاتصالات. لقبول مرور جميع بيانات التراسل الشبكي على بطاقة loopback، فعليك تنفيذ هذين الأمرين: sudo iptables -A INPUT -i lo -j ACCEPT sudo iptables -A OUTPUT -o lo -j ACCEPTالسماح للاتصالات الواردة المنشأة والمتعلقةيجب عادةً أن تمر بيانات التراسل الشبكي باتجاهين (صادرة وواردة) لكي تعمل الاتصالات الشبكية عملًا صحيحًا؛ من الاعتيادي إنشاء قاعدة في الجدار الناري للسماح بالاتصالات الواردة المُنشَأة (established) والمتعلقة (related)، مما يمكِّن الخادوم من استقبال البيانات المُرجَعة من اتصالات صادرة بدأها الخادوم نفسه؛ سيكون الأمر كما يلي: sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPTالسماح بمرور البيانات للاتصالات الصادرة المنشأةربما تود السماح للبيانات الصادرة لجميع الاتصالات المُنشَأة، التي تكون عادةً الرد على الاتصالات الواردة المسموح لها؛ الأمر الذي يفعل بذلك هو: sudo iptables -A OUTPUT -m conntrack --ctstate ESTABLISHED -j ACCEPTالتمرير من الشبكة الداخلية إلى الخارجيةعلى فرض أنَّ eth0 هي شبكتك الخارجية، و eth1 هي شبكتك الداخلية، فإن الأمر الآتي سيسمح بتمرير البيانات من الشبكة الداخلية إلى الخارجية: sudo iptables -A FORWARD -i eth1 -o eth0 -j ACCEPTتجاهل الرزم الشبكية غير الصالحةتُعلَّم بعض الرزم الشبكية على أنها «غير صالحة» (invalid)؛ قد يكون مفيدًا في بعض الأخيان تسجيل هذا النوع من الرزم لكن يكون عادةً من المقبول تجاهلها. يمكنك فعل ذلك بوساطة هذا الأمر: sudo iptables -A INPUT -m conntrack --ctstate INVALID -j DROPحجب عنوان IPاستعمل الأمر الآتي لحجب الاتصالات الشبكية التي تنحدر من عنوان IP معيّن، ولنقل أنه 15.15.15.51 مثلًا: sudo iptables -A INPUT -s 15.15.15.51 -j DROPيُحدِّد التعبير ‎-s 15.15.15.51 عنوان IP المصدري على أنه «15.15.15.51»، يمكن أن يُحدَّد عنوان IP المصدري في أيّة قاعدة من قواعد الجدار الناري، بما في ذلك قواعد السماح (allow). إذا كنت تريد «رفض» (reject) الاتصال بدلًا من تجاهله (أي سيكون الرد على الاتصال هو خطأ «connection refused») فبدِّل «DROP» إلى «REJECT» كما يلي: sudo iptables -A INPUT -s 15.15.15.51 -j REJECTحجب الاتصالات إلى بطاقة شبكيةلحجب جميع الاتصالات من عنوان IP معيّن (15.15.15.51 مثلًا)، إلى بطاقة شبكيّة معيّنة (eth0 مثلًا) فاستخدم هذا الأمر: iptables -A INPUT -i eth0 -s 15.15.15.51 -j DROPيشبه هذا الأمر كثيرًا الأمرَ في الفقرة السابقة، لكنه يزيد عنه بالتعبير ‎-i eth0؛ يمكن تحديد البطاقة الشبكية في أيّة قاعدة من قواعد الجدار الناري، وهذه طريقةٌ رائعةٌ لجعل قاعدةٍ ما محدودةً إلى شبكةٍ معيّنةٍ فقط. خدمة SSHإذا كنتَ تستخدم خادومًا سحابيًا، فربما تريد السماح لاتصالات SSH الواردة (المنفذ 22) لذا يمكنك الاتصال وإدارة خادومك؛ يشرح هذا القسم كيف تضبط جدارك الناري بمختلف القواعد المتعلقة بخدمة SSH. السماح لاتصالات SSHتستطيع استخدام الأمرين الآتيين للسماح لجميع اتصالات SSH الواردة: sudo iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT sudo iptables -A OUTPUT -p tcp --sport 22 -m conntrack --ctstate ESTABLISHED -j ACCEPTالأمر الثاني (الذي يسمح بمرور بيانات التراسل الشبكي لاتصالات SSH المُنشَأة) مطلوبٌ فقط إذا لم تكن سياسة OUTPUT مضبوطةً إلى ACCEPT. السماح لاتصالات SSH الواردة من عنوان IP معين أو شبكة فرعيةللسماح باتصالات SSH الواردة من عنوان IP معيّن أو شبكة فرعية، فعليك تحديد المصدر؛ على سبيل المثال، إذا أردت السماح لكامل الشبكة الفرعية 15.15.15.0/24، فنفِّذ هذين الأمرين: sudo iptables -A INPUT -p tcp -s 15.15.15.0/24 --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT sudo iptables -A OUTPUT -p tcp --sport 22 -m conntrack --ctstate ESTABLISHED -j ACCEPTالأمر الثاني (الذي يسمح بمرور بيانات التراسل الشبكي لاتصالات SSH المُنشَأة) مطلوبٌ فقط إذا لم تكن سياسة OUTPUT مضبوطةً إلى ACCEPT. السماح لاتصالات SSH الصادرةإذا لم تكن سياسة OUTPUT في جدارك الناري مضبوطةً إلى ACCEPT، فربما تريد السماح لاتصالات SSH الصادرة (أي أن يبدأ خادومك اتصال SSH إلى خادومٍ آخر) بتنفيذ هذين الأمرين: sudo iptables -A OUTPUT -p tcp --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT sudo iptables -A INPUT -p tcp --sport 22 -m conntrack --ctstate ESTABLISHED -j ACCEPTالسماح لاتصالات Rsync الواردة من عنوان IP معين أو شبكة فرعيةيمكن أن يُستخدَم Rsync (الذي يعمل على المنفذ 873) لنقل الملفات من حاسوبٍ إلى آخر. للسماح باتصالات rsync الواردة من عنوان IP معيّن أو شبكة فرعية، فحدِّد عنوان IP المصدري والمنفذ الوجهة؛ على سبيل المثال، إذا أردت السماح لكامل الشبكة الفرعية 15.15.15.0/24 باستخدام rsync على خادومك، فنفِّذ الأمرين الآتيين: sudo iptables -A INPUT -p tcp -s 15.15.15.0/24 --dport 873 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT sudo iptables -A OUTPUT -p tcp --sport 873 -m conntrack --ctstate ESTABLISHED -j ACCEPTالأمر الثاني (الذي يسمح بمرور بيانات التراسل الشبكي لاتصالات rsync المُنشَأة) مطلوبٌ فقط إذا لم تكن سياسة OUTPUT مضبوطةً إلى ACCEPT. خادم الويبتستمع خوادم الويب -مثل أباتشي و Nginx- للطلبيات على المنفذين 80 و 443 لاتصالات HTTP و HTTPS على التوالي وبالترتيب. إذا كانت السياسة الافتراضية للاتصالات الواردة هي الحجب أو التجاهل، فربما تريد إنشاء قواعد تسمح لخادومك بالرد على تلك الطلبيات. السماح لجميع اتصالات HTTP الواردةاستخدم الأمرين الآتيين للسماح لجميع اتصالات HTTP (المنفذ 80) الواردة: sudo iptables -A INPUT -p tcp --dport 80 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT sudo iptables -A OUTPUT -p tcp --sport 80 -m conntrack --ctstate ESTABLISHED -j ACCEPTالأمر الثاني (الذي يسمح بمرور بيانات التراسل الشبكي لاتصالات HTTP المُنشَأة) مطلوبٌ فقط إذا لم تكن سياسة OUTPUT مضبوطةً إلى ACCEPT. السماح لجميع اتصالات HTTPS الواردةاستخدم الأمرين الآتيين للسماح لجميع اتصالات HTTPS (المنفذ 443) الواردة: sudo iptables -A INPUT -p tcp --dport 443 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT sudo iptables -A OUTPUT -p tcp --sport 443 -m conntrack --ctstate ESTABLISHED -j ACCEPTالأمر الثاني (الذي يسمح بمرور بيانات التراسل الشبكي لاتصالات !HTTPS! المُنشَأة) مطلوبٌ فقط إذا لم تكن سياسة OUTPUT مضبوطةً إلى ACCEPT. السماح لجميع اتصالات HTTP و HTTPS الواردةإذا أردت السماح لجميع اتصالات HTTP و HTTPS الواردة معًا، فيمكنك استخدام الوحدة (module) ‏«mulitport» لإنشاء قاعدة تسمح بمرور البيانات على كلي المنفذين؛ وذلك عبر الأمرين الآتيين: sudo iptables -A INPUT -p tcp -m multiport --sports 80,443 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT sudo iptables -A OUTPUT -p tcp -m multiport --sports 80,443 -m conntrack --ctstate ESTABLISHED -j ACCEPTالأمر الثاني (الذي يسمح بمرور بيانات التراسل الشبكي لاتصالات HTTP و HTTPS المُنشَأة) مطلوبٌ فقط إذا لم تكن سياسة OUTPUT مضبوطةً إلى ACCEPT. قواعد بيانات MySQLتستمع MySQL إلى اتصالات العميل على المنفذ 3306؛ إذا كان سيُستخدَم خادم قواعد بيانات MySQL من عميل على خادوم بعيد؛ فتأكد أنك تسمح بمرور تلك البيانات الشبكية. السماح لاتصالات MySQL الواردة من عنوان IP معين أو شبكة فرعيةللسماح باتصالات MySQL الواردة من عنوان IP معيّن أو شبكة فرعية، فحدِّد المصدر؛ على سبيل المثال، تستطيع تنفيذ هذين الأمرين إذا أردت السماح للشبكة الفرعية 15.15.15.0/24: sudo iptables -A INPUT -p tcp -s 15.15.15.0/24 --dport 3306 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT sudo iptables -A OUTPUT -p tcp --sport 3306 -m conntrack --ctstate ESTABLISHED -j ACCEPTالأمر الثاني (الذي يسمح بمرور بيانات التراسل الشبكي لاتصالات MySQL المُنشَأة) مطلوبٌ فقط إذا لم تكن سياسة OUTPUT مضبوطةً إلى ACCEPT. السماح لاتصالات MySQL الواردة إلى بطاقة شبكية معينةاستخدم الأمر الآتي للسماح لاتصالات MySQL لبطاقة شبكيّة معيّنة -لنفترض أنّك تملك بطاقة شبكيّة خاصة باسم eth1-: sudo iptables -A INPUT -i eth1 -p tcp --dport 3306 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT sudo iptables -A OUTPUT -o eth1 -p tcp --sport 3306 -m conntrack --ctstate ESTABLISHED -j ACCEPTالأمر الثاني (الذي يسمح بمرور بيانات التراسل الشبكي لاتصالات MySQL المُنشَأة) مطلوبٌ فقط إذا لم تكن سياسة OUTPUT مضبوطةً إلى ACCEPT. قواعد بيانات PostgreSQLتستمع PostgreSQL إلى اتصالات العميل على المنفذ 5432 إذا كان سيُستخدَم خادم قواعد بيانات PostgreSQL من عميل على خادومٍ بعيد؛ فتأكد أنك تسمح بمرور تلك البيانات الشبكية. السماح لاتصالات PostgreSQL الواردة من عنوان IP معين أو شبكة فرعيةللسماح باتصالات PostgreSQL الواردة من عنوان IP معيّن أو شبكة فرعية، فحدِّد المصدر؛ على سبيل المثال، تستطيع تنفيذ هذين الأمرين إذا أردت السماح للشبكة الفرعية 15.15.15.0/24: sudo iptables -A INPUT -p tcp -s 15.15.15.0/24 --dport 5432 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT sudo iptables -A OUTPUT -p tcp --sport 5432 -m conntrack --ctstate ESTABLISHED -j ACCEPTالأمر الثاني (الذي يسمح بمرور بيانات التراسل الشبكي لاتصالات PostgreSQL المُنشَأة) مطلوبٌ فقط إذا لم تكن سياسة OUTPUT مضبوطةً إلى ACCEPT. السماح لاتصالات PostgreSQL الواردة إلى بطاقة شبكية معينةاستخدم الأمر الآتي للسماح لاتصالات PostgreSQL لبطاقة شبكيّة معيّنة -لنفترض أنّك تملك بطاقة شبكيّة خاصة باسم eth1: sudo iptables -A INPUT -i eth1 -p tcp --dport 5432 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT sudo iptables -A OUTPUT -o eth1 -p tcp --sport 5432 -m conntrack --ctstate ESTABLISHED -j ACCEPTالأمر الثاني (الذي يسمح بمرور بيانات التراسل الشبكي لاتصالات PostgreSQL المُنشَأة) مطلوبٌ فقط إذا لم تكن سياسة OUTPUT مضبوطةً إلى ACCEPT. خدمة البريدتستمع خوادم البريد مثل Sendmail و Postfix إلى تشكيلة واسعة من المنافذ بناءً على البروتوكولات المستخدمة لتوصيل البريد؛ إذا كنت تُشغِّل خادوم بريدٍ إلكتروني، فحدِّد البروتوكولات التي تستخدمها واسمح للاتصالات الموافقة لها. سنستعرض أيضًا مثالًا عن إنشاء قاعدة لحجب بريد SMTP الصادر. حجب بريد SMTP الصادرربما تريد أن تحجب بريد SMTP الصادر إذا لم يكن من المفترض لخادومك أن يرسل بريدًا إلكترونيًّا؛ استخدم الأمر الآتي لحجب بريد SMTP الصادر (الذي يستخدم المنفذ 25): sudo iptables -A OUTPUT -p tcp --dport 25 -j REJECTيضبط الأمر السابق خادومك لتجاهل كل البيانات المُرسَلة على المنفذ 25؛ إذا أردت أن تحجب خدمةً أخرى عبر رقم منفذها، فضع رقم المنفذ الخاص بها بدلًا من 25. السماح لجميع اتصالات SMTP الواردةللسماح لخادومك بالرد على اتصالات SMTP على المنفذ 25، فعليك تنفيذ الأمرين الآتيين: sudo iptables -A INPUT -p tcp --dport 25 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT sudo iptables -A OUTPUT -p tcp --sport 25 -m conntrack --ctstate ESTABLISHED -j ACCEPTالأمر الثاني (الذي يسمح بمرور بيانات التراسل الشبكي لاتصالات SMTP المُنشَأة) مطلوبٌ فقط إذا لم تكن سياسة OUTPUT مضبوطةً إلى ACCEPT. ملاحظة: من الشائع لخوادم SMTP أن تستخدم المنفذ 587 للبريد الصادر. السماح لجميع اتصالات IMAP الواردةللسماح لخادومك بالرد على اتصالات IMAP على المنفذ 143، فعليك تنفيذ الأمرين الآتيين: sudo iptables -A INPUT -p tcp --dport 143 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT sudo iptables -A OUTPUT -p tcp --sport 143 -m conntrack --ctstate ESTABLISHED -j ACCEPTالأمر الثاني (الذي يسمح بمرور بيانات التراسل الشبكي لاتصالات IMAP المُنشَأة) مطلوبٌ فقط إذا لم تكن سياسة OUTPUT مضبوطةً إلى ACCEPT. السماح لجميع اتصالات IMAPS الواردةللسماح لخادومك بالرد على اتصالات IMAPS على المنفذ 993، فعليك تنفيذ الأمرين الآتيين: sudo iptables -A INPUT -p tcp --dport 993 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT sudo iptables -A OUTPUT -p tcp --sport 993 -m conntrack --ctstate ESTABLISHED -j ACCEPTالأمر الثاني (الذي يسمح بمرور بيانات التراسل الشبكي لاتصالات IMAPS المُنشَأة) مطلوبٌ فقط إذا لم تكن سياسة OUTPUT مضبوطةً إلى ACCEPT. السماح لجميع اتصالات POP3 الواردةللسماح لخادومك بالرد على اتصالات POP3 على المنفذ 110، فعليك تنفيذ الأمرين الآتيين: sudo iptables -A INPUT -i -p tcp --dport 110 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT sudo iptables -A OUTPUT -p tcp --sport 110 -m conntrack --ctstate ESTABLISHED -j ACCEPTالأمر الثاني (الذي يسمح بمرور بيانات التراسل الشبكي لاتصالات POP3 المُنشَأة) مطلوبٌ فقط إذا لم تكن سياسة OUTPUT مضبوطةً إلى ACCEPT. السماح لجميع اتصالات POP3S الواردةللسماح لخادومك بالرد على اتصالات POP3S على المنفذ 995، فعليك تنفيذ الأمرين الآتيين: sudo iptables -A INPUT -p tcp --dport 995 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT sudo iptables -A OUTPUT -p tcp --sport 995 -m conntrack --ctstate ESTABLISHED -j ACCEPTالأمر الثاني (الذي يسمح بمرور بيانات التراسل الشبكي لاتصالات POP3S المُنشَأة) مطلوبٌ فقط إذا لم تكن سياسة OUTPUT مضبوطةً إلى ACCEPT. الخلاصةيجب أن يكون قد غطى هذا الدرس الكثير من الأوامر شائعة الاستخدام عند استعمال iptables لضبط الجدار الناري؛ وبالطبع iptables هو أداةٌ مرنةٌ جدًا، لذلك تستطيع دمج مختلف الخيارات مع الأوامر السابقة لملائمة متطلبات خادومك إن لم تكن تلك الأوامر مبيّنةً هنا. ترجمة -وبتصرف- للمقال: Iptables Essentials: Common Firewall Rules and Commands لصاحبه: Mitchell Anicas.

نشر مختلف مكونات تطبيقك على عدِّة عقد (nodes) هو طريقةٌ شائعةٌ لتخفيف الحِمل (load) والبدء في التوسع أفقيًا (scaling horizontally)؛ مثالٌ اعتياديٌ عن ذلك هو ضبط قاعدة بيانات على خادوم منفصل عن تطبيقك؛ وعلى الرغم من العدد الكبير من المحاسن الناتجة عن هذا الإعداد، لكن الاتصال عبر الشبكة ينضوي على مخاطر أمنية. سنشرح في هذا الدرس كيف نعد جدار ناري بسيط على كل خادوم من خواديمك عند استخدامك للضبط الموزَّع (distributed setup)؛ سنضبط السياسة لكي تسمح بمرور البيانات بين المكونات (components)، وتمنع في الوقت ذاته مرور أيّة بيانات أخرى. سنستخدم في هذا الدليل خادومَي أوبنتو 14.04؛ واحدٌ سيحتوي على نسخة من وردبريس مُخدَّمة بوساطة nginx، والآخر يستضيف قاعدة بيانات MySQL للتطبيق. وعلى الرغم من أننا سنستخدم هذا الإعداد كمثال، لكنك تستطيع تعديل التقنيات التي سنستخدمها لكي تلائم متطلبات خادومك. المتطلبات المسبقةللبدء، عليك أن تحصل على خادومَي Ubuntu؛ وتضيف مستخدمًا عاديًا بامتيازات الجذر عبر الأمر sudo على كلي الخادومَين؛ يمكنك اتباع درس الضبط المبدئي لخادوم أوبنتو 14.04 لكي تتعلم كيف تفعل ذلك بشكلٍ صحيح. ضبط جدار ناري بسيطسنبدأ بضبط أساسي للجدار الناري على كل خادوم من خواديمنا. السياسة التي سنتبعها تأخذ منحى «الأمان أولًا»، أي أننا سنمنع كل شيء عدا بيانات التراسل التابعة لخدمة SSH ثم سنفتح «فجوات» في الجدار الناري خاصة بتطبيقنا. يوفر الجدار الناري المضبوط في هذا الدرس إعدادًا أساسيًا لما سنحتاج؛ ثبِّت الحزمة iptables-persistent ثم الصق القواعد الأساسية في ملف ‎/etc/iptables/rules.v4: sudo apt-get update sudo apt-get install iptables-persistent sudo nano /etc/iptables/rules.v4محتويات الملف: etc/iptables/rules.v4/ *filter # Allow all outgoing, but drop incoming and forwarding packets by default :INPUT DROP [0:0] :FORWARD DROP [0:0] :OUTPUT ACCEPT [0:0] # Custom per-protocol chains :UDP - [0:0] :TCP - [0:0] :ICMP - [0:0] # Acceptable UDP traffic # Acceptable TCP traffic -A TCP -p tcp --dport 22 -j ACCEPT # Acceptable ICMP traffic # Boilerplate acceptance policy -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT -A INPUT -i lo -j ACCEPT # Drop invalid packets -A INPUT -m conntrack --ctstate INVALID -j DROP # Pass traffic to protocol-specific chains ## Only allow new connections (established and related should already be handled) ## For TCP, additionally only allow new SYN packets since that is the only valid ## method for establishing a new TCP connection -A INPUT -p udp -m conntrack --ctstate NEW -j UDP -A INPUT -p tcp --syn -m conntrack --ctstate NEW -j TCP -A INPUT -p icmp -m conntrack --ctstate NEW -j ICMP # Reject anything that's fallen through to this point ## Try to be protocol-specific w/ rejection message -A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable -A INPUT -p tcp -j REJECT --reject-with tcp-reset -A INPUT -j REJECT --reject-with icmp-proto-unreachable # Commit the changes COMMIT *raw :PREROUTING ACCEPT [0:0] :OUTPUT ACCEPT [0:0] COMMIT *nat :PREROUTING ACCEPT [0:0] :INPUT ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] COMMIT *security :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] COMMIT *mangle :PREROUTING ACCEPT [0:0] :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] COMMITإذا كنتَ تجري هذه التعديلات على «بيئة حيّة» فلا تعيد تحميل قواعد الجدار الناري! تحميل القواعد الأساسية المذكورة هنا سيؤدي مباشرةً إلى قطع الاتصال بين تطبيقك وخادوم قواعد البيانات؛ سنحتاج إلى تعديل القواعد لكي تعكس احتياجاتنا لكي يعمل التطبيق قبل إعادة التحميل. معرفة المنافذ التي تستخدمها الخدمات التي تشغلهالكي نستطيع إضافة استثناءات للسماح بالاتصالات بين مختلف مكونات التطبيق، فسنحتاج إلى معرفة المنافذ الشبكية المُستخدَمة؛ يمكنك معرفة المنافذ الشبكية الصحيحة بتفحص ملفات الضبط، لكن طريقة اكتشاف المنافذ غير مرتبطة بالتطبيقات هي التحقق من الخدمات التي «تستمع» إلى الاتصالات على كل جهاز. يمكننا استخدام الأداة netstat لمعرفة ذلك؛ ولمّا كان تطبيقنا يتواصل عبر IPv4 فقط، فسنضيف الوسيط ‎-4 لكنك تستطيع إزالته إذا كنت تستخدم IPv6 أيضًا؛ الوسائط الأخرى اللازمة لمعرفة الخدمات التي تعمل هي ‎-plunt. على خادوم الويب، سنرى شيئًا شبيهًا بما يلي: sudo netstat -4pluntالناتج: 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 1058/sshd tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 4187/nginx يُظهِر أول عمود عنوان IP والمنفذ للخدمة التي تستمع إليه (الموجود اسمها في آخر السطر)؛ عنوان 0.0.0.0 الخاص يعني أن الخدمة المعنية تستمع إلى جميع العناوين المتاحة (جميع البطاقات الشبكية). وعلى خادوم قواعد البيانات، يجب أن نشاهد شيئًا شبيهًا بما يلي: sudo netstat -4pluntالناتج: 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 1097/sshd tcp 0 0 192.0.2.30:3306 0.0.0.0:* LISTEN 3112/mysqldيمكنك قراءة الأعمدة السابقة بنفس الطريقة. يمثّل عنوان 192.0.2.30 في المثال السابق عنوان IP الخاص لخادوم قواعد البيانات؛ وعند إعداد التطبيق، لقد حصرنا استخدام MySQL إلى البطاقة الخاصة فقط لأسبابٍ أمنية. الحظ القيم التي ستجدها في هذه الخطوة، هذه هي التفاصيل الشبكية التي سنحتاج لها لكي نعدِّل ضبطنا للجدار الناري. في مثالنا التوضيحي، سنلاحظ أنه علينا التأكد من أن هذه المنافذ متاحة على خادوم الويب: المنفذ 80 على جميع العناوينالمنفذ 22 على جميع العناوين (وذلك موجودٌ في قواعد الجدار الناري)وعلينا التأكد من أن هذه المنافذ متاحةٌ على خادوم قواعد البيانات: المنفذ 3306 على العنوان 192.0.2.30 (أو البطاقة الشبكية المرتبطة معه)المنفذ 22 على جميع العناوين (وذلك موجودٌ في قواعد الجدار الناري)تعديل قواعد الجدار الناري لخادوم الويبلدينا الآن معلومات المنافذ التي نحتاج إليها لتعديل مجموعة قواعد الجدار الناري لخادوم الويب الخاص بنا؛ افتح ملف القواعد في محررك النصي بامتيازات الجذر (عبر sudo): sudo nano /etc/iptables/rules.v4سنحتاج إلى السماح بمرور بيانات التراسل الشبكي على المنفذ 80 في خادوم الويب؛ ولمّا كان الخادوم يستمع إلى الاتصالات على جميع العناوين المتوفرة، فإننا لن نقيّد القاعدة ببطاقة شبكية أو عنوان معيّن. سيستخدم زوار موقعنا بروتوكول TCP للاتصال؛ إطار العمل الذي أنشأناه لجدارنا الناري فيه سلسلة خاصة باسم TCP لوضع استثناءات لتطبيقات TCP؛ يمكننا إضافة المنفذ 80 إلى السلسلة، مباشرةً بعد الاستثناء الخاص بمنفذ SSH: /etc/iptables/rules.v4 *filter . . . # Acceptable TCP traffic -A TCP -p tcp --dport 22 -j ACCEPT -A TCP -p tcp --dport 80 -j ACCEPT . . .سيبدأ خادوم الويب اتصالًا مع خادوم قواعد البيانات؛ ليست الاتصالات الشبكية الخارجة من خادومنا مقيدةً في جدارنا الناري ويُسمَح للاتصالات الواردة المرتبطة مع اتصالات مُنشَأة مسبقًا، لذلك لن نحتاج إلى فتح أيّة منافذ إضافية في هذا الخادوم للسماح بهذا الاتصال. احفظ وأغلق الملف عندما تنتهي من تعديله، يجب أن يملك خادوم الويب الآن سياسة جدارٍ ناريٍ تسمح بمرور البيانات الشرعية وتحجب في الوقت نفسه أي شيءٍ آخر. اختبر ملف القواعد للكشف عن الأخطاء البنيوية (syntax errors): sudo iptables-restore -t < /etc/iptables/rules.v4إذا لم تظهر أيّة أخطاء، فأعد تحميل الجدار الناري لتطبيق مجموعة القواعد الجديدة: sudo service iptables-persistent reloadتعديل قواعد الجدار الناري لخادوم قواعد البياناتيجب علينا السماح بالوصول إلى المنفذ 3306 على عنوان IP الخاص بخادوم قواعد البيانات، الذي هو 192.0.2.30، يمكننا وضع قيود على الوصول لهذا العنوان تحديدًا، أو يمكننا وضع القيود للبيانات القادمة إلى البطاقة الشبكية المرتبطة مع هذا العنوان. لمعرفة البطاقة الشبكية المرتبطة مع هذا العنوان، فنفِّذ الأمر: ip -4 addr show scope globalالناتج: 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 inet 203.0.113.5/24 brd 104.236.113.255 scope global eth0 valid_lft forever preferred_lft forever 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 inet 192.0.2.30/24 brd 192.0.2.255 scope global eth1 valid_lft forever preferred_lft foreverما سبق يظهر أنّ البطاقة eth1 هي البطاقة الشبكيّة المرتبطة مع ذاك العنوان. ومن ثم علينا أن نعدِّل قواعد الجدار الناري في خادوم قواعد البيانات. افتح ملف القواعد بامتيازات الجذر (عبر sudo) في خادوم قواعد البيانات: sudo nano /etc/iptables/rules.v4مرةً أخرى، سنضيف قاعدةً إلى سلسلة TCP لتشكيل استثناء للاتصال بين خادومَي الويب وقواعد البيانات. إذا أردت تقييد الوصول بناءً على العنوان، فيمكنك إضافة قاعدة مثل هذه: /etc/iptables/rules.v4 *filter . . . # Acceptable TCP traffic -A TCP -p tcp --dport 22 -j ACCEPT -A TCP -p tcp --dport 3306 -d 192.0.2.30 -j ACCEPT . . .إذا كنت تفضِّل أن تسمح بالاستثناء بناءً على البطاقة الشبكية التي تستضيف العنوان، فيمكنك إضافة قاعدة شبيهة بالقاعدة السابقة بدلًا منها: /etc/iptables/rules.v4 *filter . . . # Acceptable TCP traffic -A TCP -p tcp --dport 22 -j ACCEPT -A TCP -p tcp --dport 3306 -i eth1 -j ACCEPT . . .احفظ وأغلق الملف عندما تنتهي من تعديله. اختبر ملف القواعد للكشف عن الأخطاء البنيوية: sudo iptables-restore -t < /etc/iptables/rules.v4عندما تكون جاهزًا، فأعد تحميل قواعد الجدار الناري: sudo service iptables-persistent reloadيجب أن يكون كلا الخادومَين محميًا الآن دون تقييد تدفق البيانات بينهما. الخلاصةيجب أن يكون إعداد جدارٍ ناريٍ سليم جزءًا من خطة نشر التطبيق؛ وعلى الرغم من أننا شرحنا هذا الضبط مستخدمين خادومَين يشغِّلان Nginx وMySQL لكي تعمل نسخة من وردبريس، لكن التقنيات المشروحة في هذا الدرس قابلةٌ للتطبيق بغض النظر عن الخدمات المُشغَّلة. ترجمة -وبتصرف- للمقال: How To Set Up an Iptables Firewall to Protect Traffic Between your Servers لصاحبه: Justin Ellingwood.

الجدار الناري هو نظامٌ يوفِّر حمايةً للشبكة عبر ترشيح البيانات المُرسَلة والمُستقبَلة عبر الشبكة بناءً على قواعد حدّدها المستخدم. عمومًا، الهدف من الجدار الناري هو تقليل أو إزالة وجود الاتصالات الشبكية غير المرغوب فيها والسماح في الوقت نفسه للاتصالات «الشرعية» أن تُنقَل بحريّة؛ تُوفِّر الجدر النارية طبقةً أساسيةً من الحماية التي -عندما تُدمَج مع غيرها- تمنع المهاجمين من الوصول إلى خادومك بطرقٍ خبيثة. يناقش هذا الدّرس كيف تعمل الجدر النارية، مع التركيز على برمجيات الجدر النارية «ذات الحالة» (stateful)، مثل iptable و FirewallD، لأنها تتعلق بالخواديم السحابية؛ سنبدأ بشرح موجز عن رزم TCP الشبكية والأنواع المختلفة للجدر النارية، ثم سنناقش تنوع المواضيع التي تتعلق بالجدر النارية ذات الحالة؛ في النهاية، سنوفر روابط لمقالاتٍ أخرى ستساعدك في إعداد جدار ناري على خادومك. رزم TCP الشبكية قبل نقاش مختلف أنواع الجدر النارية، لنأخذ نظرةً سريعةً على شكل بيانات التراسل الشبكي لبروتوكول التحكم في النقل (Transport Control Protocol اختصارًا TCP). تنتقل بيانات TCP الشبكية عبر الشبكة في «رزم» (packets)، التي تمثِّل حاويات تتألف من ترويسة الرزمة (packet header) –التي تحتوي على معلومات التحكم مثل عناوين المصدر والوجهة، ومعلومات تسلسل الرزم– والبيانات (التي تعرف أيضًا بالمصطلح «الحمولة» [payload])؛ وبينما تساعد بيانات التحكم في كل رزمة على التأكد من أن البيانات المرتبطة معها ستصل وصولًا صحيحًا، لكن العناصر التي تحتويها تُوفِّر للجدر النارية طرقًا مختلفة لمطابقة الرزم الشبكية على قواعد الجدار الناري. من المهم الملاحظة أنه من الضروري لاستقبال صحيح لرزم TCP قادمة أن يُرسِل المُستقبِل رزمًا تحتوي على إشعار بالاستلام إلى المُرسِل؛ يمكن أن يستخدم دمج معلومات التحكم في الرزم المُستقبَلة والمُرسَلة لتحديد حالة الاتصال (مثلًا، جديد [new]، مُنشَأ [established]، متعلق [related]) بين المُرسِل والمُستقبِل. دورة علوم الحاسوب دورة تدريبية متكاملة تضعك على بوابة الاحتراف في تعلم أساسيات البرمجة وعلوم الحاسوب اشترك الآن أنواع الجدر النارية لنناقش بسرعة الأنواع الثلاثة الأساسية للجدر النارية للشبكة: ترشيح الرزم (packet filtering) أو عديمة الحالة [stateless])، ذات الحالة (stateful)، وطبقة التطبيقات (application layer). ترشيح الرزم، أو الجدر عديمة الحالة، تعمل عبر تفصّح كل الرزم الشبكية على حدة؛ وبالتالي، ستكون غير مدركة لحالة الاتصال ويمكنها فقط أن تسمح أو تمنع مرور الرزم بناءً على ترويسات كل رزمة بشكل منفرد. الجدر ذات الحالة قادرة على تحديد حالة الاتصال للرزم، مما يجعل تلك الجدر أكثر مرونةً من الجدر عديمة الحالة. إنها تعمل عبر جمع الرزم الشبكية المترابطة إلى أن تستطيع تحديد حالة الاتصال قبل أن تطبَّق أيّة قواعد للجدار الناري على بيانات التراسل الشبكي. جدر التطبيقات (Application firewalls) تذهب خطوةً إضافيةً إلى الأمام عبر تحليل البيانات التي قد أُرسِلَت، مما يسمح بمطابقة بيانات التراسل الشبكي على قواعد الجدار الناري التي تكون مخصصة لخدمات أو تطبيقات معينة. تسمى هذه الجدر أيضًا باسم «الجدر النارية الوسيطة» (proxy-based firewalls). بالإضافة إلى برمجية الجدار الناري، المتوفرة في جميع أنظمة التشغيل الحديثة، يمكن توفير وظيفة الجدار الناري عبر أجهزة عتادية، مثل الموجهات (routers) أو أجهزة جدر نارية خاصة. مرةً أخرى، سنركِّز في نقاشنا على الجدر النارية ذات الحالة التي تعمل على الخواديم التي عليها حمايتها. قواعد الجدار الناري كما ذُكِر في الأعلى، البيانات الشبكية التي تعبر جدارًا ناريًا ستُطابَق على قواعدٍ لتحديد إذا كان يُسمَح لها بالمرور أم لا؛ طريقة سهلة لشرح كيف تبدو قواعد الجدار الناري هي عرض بعض الأمثلة، لنفعل ذلك الآن. لنفترض أن لديك خادومًا بهذه القائمة من قواعد الجدار الناري التي تنطبق على البيانات القادمة: السماح للبيانات الشبكية القادمة من اتصالات جديدة أو مُنشَأة مسبقًا إلى البطاقة الشبكية العامة على المنفذين 80 و 443 (بيانات HTTP و HTTPS للويب). تجاهل البيانات القادمة من عناوين IP للموظفين غير التقنيين في مكتبك إلى المنفذ 22 (خدمة SSH). السماح للبيانات الشبكية القادمة من اتصالات جديدة أو مُنشَأة مسبقًا من مجال عناوين IP لمكتبك إلى البطاقة الشبكية الخاصة على المنفذ 22 (خدمة SSH). الحظ أنَّ أول كلمة في كل مثال من الأمثلة الثلاثة السابقة هي إما كلمة «السماح» (accept) أو «رفض» (reject) أو «تجاهل» (drop). هذا يُحدِّد ما سيفعله الجدار الناري في حال طابقت البيانات الشبكية تلك القاعدة. «السماح» تعني أنه يمكن للبيانات الشبكية المرور، و«الرفض» تعني منع مرور البيانات الشبكية ولكن إرسال خطأ «unreachable»، بينما «التجاهل» تعني منع مرور البيانات الشبكية وعدم إرسال رد؛ يحتوي ما تبقى من كل قاعدة على الشرط الذي يجب أن تُطابَق عليه كل رزمة شبكية. وكما يبدو، فإن البيانات الشبكية ستُطابَق على قائمة بقواعد الجدار الناري بتسلسل (chain) من أول قاعدة إلى آخر قاعدة. وخصوصًا عندما تُطابَق قاعدة، فسينفَّذ الحدث المُطابِق لها على البيانات الشبكية؛ في مثالنا السابق، إذا حاول محاسب في المكتب إنشاء اتصال SSH إلى الخادوم، فسيُرفَض اتصاله بناءً على القاعدة رقم 2، حتى قبل التحقق من القاعدة رقم 3؛ لكن مديرًا للنظام سيتمكَّن من إنشاء الاتصال لأنه سيُطابِق القاعدة رقم 3 فقط. السياسة الافتراضية (Default Policy) من الطبيعي لسلسلة من قواعد الجدار الناري ألا تغطي بدقة كل حالة ممكنة؛ فلهذا السبب، يجب تحديد سياسة افتراضية لسلاسل قواعد الجدار الناري، التي تحتوي على ما سيُفعَل بالبيانات الشبكية فقط (قبول، أو رفض، أو تجاهل). افترض أننا ضبطنا السياسة الافتراضية للمثال السابق إلى «تجاهل»؛ فإذا حاول حاسوب خارج مكتبك إنشاء اتصال SSH إلى خادومك، فسيتم تجاهل البيانات الشبكية التي أرسلها لأنها لا تطابق أيّ من القواعد السابقة. أما لو ضُبِطَت السياسة الافتراضية إلى «السماح»، فإن أي شخص –ما عدا موظفي المكتب غير التقنيين– سيتمكن من إنشاء اتصال لأي خدمة مفتوحة على خادومك؛ هذا مثالٌ عن أن جدارًا ناريًا مضبوطٌ ضبطًا سيئًا سيمنع جزءًا من الموظفين فقط. البيانات الشبكية الداخلة والخارجة لمّا كانت تُفصَل البيانات الشبكية –من وجهة نظر الخادوم– إلى بيانات داخلة أو خارجة، فإن الجدار الناري يبقي مجموعةً منفصلةً من القواعد لكل حالة؛ البيانات التي أصلها من مكانٍ آخر –أي البيانات الداخلة– تُعامَل معاملةً مختلفةً عن البيانات الخارجة من الخادوم؛ من الطبيعي أن يسمح الخادوم بأغلبية البيانات الخارجة لأن الخادوم عادةً «يثق بنفسه». ومع ذلك، يمكن استخدام مجموعة قواعد للبيانات الخارجة لمنع الاتصالات غير المرغوبة في حال أُخترِق الخادوم من مهاجم أو عبر ملف تنفيذي خبيث. لكي نعظِّم الاستفادة الأمنية من الجدار الناري، فيجب عليك تحديد جميع الطرق التي تريد للأنظمة الأخرى أن تتعامل مع خادومك فيها؛ وذلك بإنشاء قواعد تسمع لتلك الحالات بدقة، ثم تتجاهل بقية البيانات الشبكية. أبقِ في بالك أنَّ قواعد البيانات الخارجة يجب أن تكون صحيحة للسماح للخادوم بإرسال إشعارات استلام لأي اتصالات داخلة مسموحٌ لها؛ تذكر أيضًا أنه ولما كان على الخادوم أن يبدأ اتصالات شبكية خاصة به لمختلف الأسباب (مثل تنزيل التحديثات، أو الاتصال إلى قاعدة بيانات)، فمن الضروري تضمين تلك الحالات في مجموعة القواعد للبيانات الخارجة. كتابة قواعد البيانات الخارجة افترض أن مثالنا عن الجدار الناري مضبوط لتجاهل البيانات الشبكية الخارجة افتراضيًا، هذا يعني أنَّ قواعد السماح للبيانات الداخلة ستكون عديمة الفائدة دون قواعد البيانات الشبكية الخارجة المُكمِّلة لها. لملائمة المثال عن قواعد البيانات الداخلة في الجدار الناري (القاعدتين 1 و 3)، من قسم «قواعد الجدار الناري» السابق، وللسماح بالاتصالات الملائمة بناءً على هذه العناوين والمنافذ؛ فعلينا استخدام هذه القواعد للاتصالات الخارجة: السماح بالبيانات الشبكية الخارجة المُنشَأة على البطاقة الشبكية العامة على المنفذ 80 و 443 (HTTP و HTTPS). السماح بالبيانات الشبكية الخارجة المُنشَأة على البطاقة الشبكية الخاصة على المنفذ 22 (SSH). الحظ أننا لم نحتج إلى كتابة قاعدة محددة للبيانات القادمة التي أُهمِلَت (القاعدة رقم 2) لأن الخادوم لا يحتاج إلى إنشاء أو إرسال إشعار إلى ذاك الاتصال. برمجيات وأدوات الجدار الناري بعد أن تعلّمنا كيف تعمل الجدر النارية، فلنلقي نظرة على حزم برمجية شائعة تساعدنا على ضبط جدار ناري فعّال؛ وعلى الرغم من أنَّ هنالك العديد من الحزم المتعلقة بالجدر النارية، إلا أنَّ هذه هي أكثرها فعاليةً وشيوعًا. Iptables إن Iptables هو الجدار الناري القياسي الموجود في أغلبية توزيعات لينكس افتراضيًا (بديل عصري له يسمى nftables بدأ باستبداله)؛ هو في الواقع واجهة أمامية (front-end) لنظام netfilter الخاص بالنواة الذي يمكنه تعديل الاتصالات الشبكية في لينُكس؛ حيث يعمل بمطابقة كل رزمة شبكية تمرّ عبر بطاقة شبكية على مجموعة من القواعد لتحديد ما الذي يجب فعله. لتعلم المزيد من المعلومات حول استخدام iptables كجدار ناري، رجاءً راجع هذه الروابط: كيفية إعداد جدار ناري باستخدام iptables على Ubuntu 14.04 فهم إعدادات "الطرق على المنافذ" على أوبنتو باستخدام IPTables كيف تضبط "الطرق على المنافذ" على أوبنتو باستخدام IPTables UFW إن UFW، الذي يرمز إلى «Uncomplicated Firwall» (الجدار الناري غير المعقّد)، هو واجهة إلى iptables مجهزٌ لتبسيط عملية ضبط جدار ناري. FirewallD FirewallD هو حلّ كامل لضبط الجدار الناري متوفرٌ افتراضيًا على خواديم CentOS 7؛ يجدر بالذكر أن FirewallD يستخدم iptables لضبط netfilter. Fail2ban إن Fail2ban هو برمجية لمنع التطفل يمكنها ضبط جدارك الناري تلقائيًا لحجب محاولات تسجيل الدخول باستخدام «القوة القاسية» (brute force) وهجمات الحرمان من الخدمة المُوزَّعة (DDoS). للمزيد من المعلومات حول Fail2ban، راجع هذه الروابط: كيف يعمل Fail2ban على زيادة حماية خادومك كيفية حماية SSH باستخدام Fail2Ban على Ubuntu كيف يعالج Fail2ban ملفات الضبط لتنفيذ الحظر الخلاصة أصبحت تعرف الآن كيف تعمل الجدر النارية، يجب عليك أخذ إنشاء جدار ناري بعين الاعتبار لتحسين مستوى حماية خادومك بالاستعانة بأحد الدروس سابقة الذكر.ش ترجمة -وبتصرّف- للمقال What is a Firewall and How Does It Work?‎ لصاحبه Mitchell Anicas. حقوق الصورة البارزة: Designed by Freepik.

قدمنا في الجزء الأول من هذا الدليل الخطة التي نعمل على إعدادها من أجل ضبط آلية للطرق على المنافذ تعتمد حصرا على جدار iptables الناري. نستكمل في هذا الجزء ما بدأناه بتنفذ الآلية المشروحة في الجزء السابق. إعداد إطار عمل نظامي للجدار النارينبدأ بوضع إطار أساسي للاتصالات في الخادوم. ستتولى سلسلة INPUT التعامل مع جميع الاتصالات القادمة. سنزيل جميع قواعد الجدار الناري المطبقة حاليا من أجل بدء الإعداد من الصفر. لكن قبل ذلك يجب أن نتأكد من أن السياسات الافتراضية مضبوطة على ACCEPT للاستمرار في الاتصال الجاري: sudo iptables -P INPUT ACCEPT sudo iptables -P FORWARD ACCEPT sudo iptables -P OUTPUT ACCEPT sudo iptables -Fبهذه الطريقة نبدأ مع جدار ناري مفتوح تماما. قبل تقييد الاتصالات ننفذ أوامر إضافة السلاسل الجديدة: sudo iptables -N KNOCKING sudo iptables -N GATE1 sudo iptables -N GATE2 sudo iptables -N GATE3 sudo iptables -N PASSEDنتوفر الآن على ثماني سلاسل. سنستخدمها كلَّها ما عدا سلسلتيْ OUTPUT وFORWARD اللتان لا تعنياننا هنا. نبدأ بالتعامل مع الاتصالات التي لا تحتاج للطرق على المنافذ لفتحها، فنضيف قاعدة إلى سلسلة INPUT للسماح للاتصالات الجارية كافةً بالاستمرار: sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPTوأخرى لقبول جميع الاتصالات من الجهاز المحلي: sudo iptables -A INPUT -i lo -j ACCEPTإذا كانت لديك خدمات موجَّهة للعموم، مثل خادوم ويب، فأضف قاعدة على النحو التالي حتى يمكن الاتصال بها: sudo iptables -A INPUT -p protocol --dport port -j ACCEPTمثال لقاعدة تتيح الوصول إلى خادوم الويب: sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPTأنهينا الآن إعداد قواعد الاتصالات المسموح بها. نمرّر جميع الاتصالات التي لا تنطبق عليها إحدى القواعد السابقة إلى سلسلة KNOCKING من أجل التنفيذ الفعلي لآلية الطرْق: sudo iptables -A INPUT -j KNOCKINGإعداد البوابة الأولىسنُلحِق “البوابات” بعد اكتمال إعدادها بسلسلة KNOCKING لتمرير حركة البيانات عبر الاختبارات المشروحة في الجزء الأول من هذا الدليل. لكن قبل ذلك يجب وضع أساس كل اختبار على انفراد. نبدأ بتعريف أول اختبار طرْق. عندما يحاول عميل الاتصال فإننا ننظر في المنفذ الذي يرسل إليه الطلب؛ إن كان يوافق المنفذ الأول لدينا في متتالية الطرْق نشير إلى أن العميل تجاوز الاختبار الأول بنجاح؛ وإلا نتجاهل الطلب. نضع علامة على العميل عند محاولة الاتصال بالمنفذ الصحيح: sudo iptables -A GATE1 -p tcp --dport 1111 -m recent --name AUTH1 --set -j DROPيؤدي السطر أعلاه مهام عدة؛ يضيف قاعدة جديدة إلى سلسلة GATE1. شروط تنفيذ القاعدة هي أن يكون البروتوكول المستخدَم هو tcp والمنفذ المطلوب هو1111، أي المنفذ اﻷول في سلسلة الطرق. عند تحقق الشروط نستدعي وِحدة recent (باستخدام خيار m-) ونضع علامة AUTH1 (باستخدام name AUTH1 --set--). ستُستعمَل هذه العلامة عند اختبار إصابة المنفذ الثاني. أخيرا، وبعد تعيين العلامة، نتجاهل الحزمة لكي لا يعرف العميل مالذي يحدث. ثم نتجاهل جميع حزم البيانات الأخرى، لأن أي معلومة تُرسَل إلى هذه السلسلة تبحث فقط عن موافقة أول حزمة: sudo iptables -A GATE1 -j DROP أنجزنا الآن ما يتعلق بالمنفذ الأول من متتالية الطرْق: إما أن توافق الحزمة المنفذ المطلوب أو تُتَجاهَل. إذا وافقت المنفذ توضع عليها علامة AUTH1. إعداد البوابة الثانيةتُضبط البوابة الثانية بطريقة مشابهة إلا أنها أكثر تعقيدا. أول ما يجب الانتباه إليه هو أن قرار توجيه محاولات الاتصال إلى هذه السلسلة سيكون ضمن السلسلة الأم KNOCKING. لن تحتاج سلسلة GATE2 إلى التأكد من مطابقة محاولة الاتصال للبوابة الأولى، لأن هذا الاختبار جرى سلفا. مع ذلك يجب أن تحذف أي علامات قد تكون وُضعت على العميل قبل البدء في التعامل مع محاولة الاتصال. عدم إزالة العلامات السابقة قد ينتج عنه وضع علامات عدة على عنوان العميل ممّا قد يؤدي إلى نجاح الطرق على المنفذ بمجرد فحص المنافذ ثلاث مرات. طبعا هذا أمر لا نرغب فيه. نستخدم وحدة recent مرة أخرى لحذف الاسم (العلامة): sudo iptables -A GATE2 -m recent --name AUTH1 --removeلا تتخذ القاعدة أعلاه أي قرارات أو إعادة توجيه؛ كل ما تفعله هو حذف العلامة الحالية (وهي تلك التي سمحت بتوجيه الاتصال إلى هذه السلسلة) وتوجيه البيانات إلى القاعدة الموالية. يصبح العنوان - بعد تجاوز القاعدة الأولى من السلسلة - خاليا من أي علامات. نتحقق من المنفذ الذي يطلبه العنوان ومن مطابقته للمنفذ الثاني في متتالية الطرْق (2222): sudo iptables -A GATE2 -p tcp --dport 2222 -m recent --name AUTH2 --set -j DROPنفس ما فعلناه مع البوابة الأولى. نضع علامة AUTH2 للإشارة إلى أن عنوان الطلب تجاوز الاختبار الثاني إذا كان العميل يحاول الاتصال عبر المنفذ المطلوب، ثم نتجاهل الحزمة لكي لا يعرف العميل مالذي نفعله. قد تبدو القاعدة التالية غريبة لأول وهلة: sudo iptables -A GATE2 -j GATE1قد تظن أن تجاهل الحزمة بعد وضع علامة AUTH2 هو - منطقيا - الخطوة التالية. إلا أن فعل ذلك سيجعلنا في وضع حرج أثناء حالة خاصة. لو كانت لدينا قاعدة drop all هنا وكانت الحزمة المرسلة في هذه الأثناء توافق المنفذ الأول في سلسلة الطرْق، فلن تسجَّل على أنها بداية لمتتالية الطرق. نفرض على سبيل المثال أن العميل أرسل - عن طريق الخطأ - محاولتي اتصال إلى المنفذ الأول. في هذه الحالة لن يعُدّ الجدار الناري محاولة الاتصال الثانية صحيحة لأنه سيرى المتتالية كما يلي: محاولة اتصال عبر المنفذ الأول. سيحسب الجدار الناري أن الاختبار الأول تُجووِز بنجاح.محاولة الاتصال عبر المنفذ الأول. فشل في الاختبار الثاني. يُعاد تعيين المتتالية.محاولة الاتصال عبر المنفذ الثاني. فشل في الاختبار الأول (يطبَّق الاختبار الأول لأن المتتالية أعيد تعيينها في الخطوة السابقة). يُعاد تعيين المتتالية.محاولة الاتصال عبر المنفذ الثالث. فشل في الاختبار الأول (يُطبق الاختبار الأول لأن المتتالية أعيد تعيينها في الخطوة السابقة). يُعاد تعيين المتتالية.نجد أن العميل في الافتراض السابق أرسل المتتالية الصحيحة، إلا أن الجدار الناري لم يعتمدها لأنه حصل تشويش لديه في أي قاعدة يجب عليه أن يطبق. يجب إذن على العميل، إذا أخطأ، إرسال طلب وهمي من أجل إعادة تعيين السلسلة، قبل البدء في إرسال المتتالية. لتجنب الوقوع في هذه الحالة لن نتجاهل الحزمة بل سنوجّهها - بدلا من ذلك - إلى سلسلة GATE1 التي أعددناها سابقا. نرسل جميع حزم البيانات التي لم تُصِب المنفذ الثاني إلى البوابة الأولى من جديد: sudo iptables -A GATE2 -j GATE1نكون هنا أمام خيارين: إما أن يكون الطلب موجَّها إلى المنفذ الأول، هنا نبدأ من جديد في المتتالية؛ وإلا فإن الجدار الناري سيتجاهل الطلب حسب العادة. أي أننا تجنبنا الوقوع في الحالة المعروضة آنفا. إعداد البوابة الثالثةننفذ البوابة الثالثة بنفس طريقة تنفيذ البوابة الثانية تماما. نمسح أولا جميع العلامات التي وُضعت على العنوان مثل ما فعلنا في إعداد البوابة الثانية ولنفس الأسباب: sudo iptables -A GATE3 -m recent --name AUTH2 --removeثم نختبر هل أصابت محاولة الاتصال المنفذ الثالث في متتالية الطرق، فإن فعلت نضع علامة AUTH3 التي تشير إلى أن العميل نجح في طرق المنافذ المطلوبة حسب المرجو؛ ثم نتجاهل - مثل ما هي العادة - الحزمة: sudo iptables -A GATE3 -p tcp --dport 3333 -m recent --name AUTH3 --set -j DROPإن لم تفلح محاولة الاتصال في إصابة المنفذ المطلوب نعيد توجيهها إلى البوابة الأولى لترى هل أصابت المنفذ الأول في المتتالية لبدء المسار من جديد: sudo iptables -A GATE3 -j GATE1بالوصول إلى هذه النقطة يكون العملاء الذي نجحوا في طرق المنافذ المطلوبة حسب الترتيب المفروض قد حصلوا على علامة AUTH3 التي تمكننا من فتح خدمة SSH لهم ضمن سلسلة PASSED. إعداد سلسلة PASSEDتُستخدَم هذه السلسلة لفتح منفذ SSH لمدة ثلاثين ثانية للعميل الذي نجح في طرق المتتالية الصحيحة. لن يُفتَح منفذ SSH إلا إذا كانت محاولة الاتصال الموالية من العميل تطلب السماح لها بعبوره. تفرض هذه القاعدة على من يحاول عشوائيا طرق المنافذ تجربة الاتصال بSSH بعد كل محاولة، الأمر الذي يصعِّب من معرفة متتالية الطرق. نبدأ - حسب العادة - بإعادة تعيين العلامات: sudo iptables -A PASSED -m recent --name AUTH3 --removeنقبل الاتصال عبر SSH من المستخدمين الذين وصلوا إلى هذه السلسلة: sudo iptables -A PASSED -p tcp --dport 22 -j ACCEPTبالنسبة للمستخدمين الذي لم يحاولوا الاتصال عبر SSH فإننا نعيدهم إلى البوابة الأولى: sudo iptables -A PASSED -j GATE1أكملنا الآن إعداد جميع السلاسل المتفرعة عن سلسلة KNOCKING. بقي إعداد السلسلة العامة التي ستمرر حركة البيانات إلى السلاسل الفرعية. إعداد سلسلة KNOCKINGيمكننا الآن بعد إعداد السلاسل الفرعية منفردةً إلحاقها بالسلسلة العامة KNOCKING وبالتالي تنفيذ خطة عملنا. نبدأ أولا بتوجيه اتصالات العملاء الذين نجحوا في اختبارات الطرْق مباشرة إلى سلسلة PASSED. تمكننا إضافة خيارات هنا. سنقيد الفترة الزمنية التي يمكن للعميل الاتصال فيها بخدمة SSH بعد تجاوزه لاختبارات الطرق، ولتكن ثلاثين ثانية. بعد هذه المهلة لن يكون بمقدوره الاتصال ويجب عليه إرسال متتالية الطرق مرة أخرى. sudo iptables -A KNOCKING -m recent --rcheck --seconds 30 --name AUTH3 -j PASSEDثم نختبر العلامات الأخرى بدءا بالأكثر تقييدا. تمكننا إضافة عشر ثوان لتحديد مهلة لانتهاء صلاحية الطَّرْقات؛ يعني هذا أنه يتوجب على العملاء ألايفصلوا بين كل طرْقتين بأكثر من عشر ثوان. sudo iptables -A KNOCKING -m recent --rcheck --seconds 10 --name AUTH2 -j GATE3 sudo iptables -A KNOCKING -m recent --rcheck --seconds 10 --name AUTH1 -j GATE2نعيد توجيه جميع محاولات الاتصال التي لم توافق أيا من القواعد السابقة إلى البوابة الأولى: sudo iptables -A KNOCKING -j GATE1بهذا تأخذ جميع سلاسل الجدار الناري مكانها. تُلحَق سلسلة KNOCKING كاملة مع السلاسل التابعة لها بسلسلة INPUT الاعتيادية. أعددنا لآن آلية الطرق. حان الوقت لاختبارها. اختبار الطرق على المنافذتوجد الكثير من الأدوات التي يمكن استخدامها لإنشاء حزم بيانات تستخدم بروتوكول TCP المطلوبة في إعدادات الطرْق على المنافذ. سنستخدم أداة nmap نظرا لوجودها افتراضيا على أغلب توزيعات لينكس. يستخدم nmap افتراضيا حزم بيانات TCP. لذا يجب أن نطلب منه تجاهل استكشاف المستضيف الموجود في سلوكه الابتدائي لكي لا يتداخل مع الطرْقات. إضافة لذلك نريد أن تنتهي مهلة محاولة الاتصال بعد ثانية واحدة فقط لنتابع مع الطرقة الموالية. ستبدو كل طرْقة، من هذا المنطلق، على النحو التالي. في المثال أول منفذ نريد طرْقه: nmap -Pn --host_timeout 201 --max-retries 0 -p 1111 your_serverأي أن متتالية الطرق ستصبح على النحو التالي: nmap -Pn --host_timeout 201 --max-retries 0 -p 1111 your_server nmap -Pn --host_timeout 201 --max-retries 0 -p 2222 your_server nmap -Pn --host_timeout 201 --max-retries 0 -p 3333 your_serverستكون لدينا بعدها ثلاثون ثانية للاتصال بخدمة SSH. يمكننا الاستفادة من أساسيات في برمجة Bash لجعل الأمور آليةً أكثر. سنستخدم حلقة for لتنفيذ الأوامر السابقة ضمن حلقة تكرارية ثم تشغيل عميل SSH للاتصال بالخادوم: for x in 1111 2222 3333; do nmap -Pn --host_timeout 201 --max-retries 0 -p $x your_server && sleep 1; done && ssh user@your_serverما نفعله هنا هو الطرْق على المنفذ الأول، انتظار ثانية واحدة، الطرْق على الثاني، وهكذا إلى أن تكتمل المتتالية. ثم نحاول بعدها الاتصال بخدمة SSH على الخادوم. ننشئ ملفا للسكربت لجعل الأمر أكثر أناقة وأيسر للاستخدام. نسمي الملف knock_client: nano knock_clientونضع فيه المحتوى التالي: #!/bin/bah ports="1111# 2222 3333" host="your_server" for x in $ports do nmap -Pn --host_timeout 201 --max-retries 0 -p $x $host sleep 1 done ssh user@${host}احفظ الملف (CTRL + O) ثم أغلقه (CTRL + X). نجعل الملف قابلا للتنفيذ: chmod 755 knock_clientنحاول الاتصال بالخادوم بتنفيذ الأمر: ./knock_clientيمكن الآن، إذا جرى كل شيء على ما يرام، الاتصال بالخادوم عن طريق SSH. بقيت خطوة أخيرة بعد التحقق من عمل الخطة التي نفذناها حسب المُراد. نجعل قواعد الجدار الناري دائمة (لا يُعاد تعيينها بعد إعادة تشغيل الخادوم) بتنزيل وتثبيت حزمة iptables-persistent على الخادوم: sudo apt-get install iptables-persistentوتشغيل خدمة iptables-persistent: sudo service iptables-persistent startخاتمةيكون لديك باكتمال هذا الدليل نظام عملي للطرق على المنافذ يعتمد فقط على الوظائف الموجودة في جدار iptables الناري. توجد مزايا لاعتماد iptables حصرا في هذا الإطار. أولا، ينتشر استخدام iptables ويشيع خضوعه لفحوص بحثا عن ثغرات أمنية قد تمثل خطرا على مستخدميه. يعني هذا أنه ما دامت القواعد التي أنشأتها تؤدي العمل الذي تظن أنها تؤديه فأنت في مأمن. ميزة أخرى لهذا الإعداد في مقابل خدمة منفصلة للطرق على المنافذ هي أنه لا مجال أن تفشل خدمة تنفيذ الطرق في تغيير قواعد الجدار الناري وتدع المنفذ مفتوحا. ترجمة - بتصرف - لمقال How To Configure Port Knocking Using Only IPTables on an Ubuntu VPS. حقوق الصورة البارزة: Shield vector designed by Freepik.

تتعرض الخواديم المتصلة بشبكة الإنترنت لأنواع كثيرة من الهجمات ومحاولات الاختراق التي يقف خلفها متسخدمون خبثاء، سكربتات وبرامج تعمل آليا. قد يكون تأمين الخادوم ضد الهجمات دون التأثير على وصول المستخدمين إلى الخدمات والموارد المتاحة لهم قرارا مؤثرا. تعد أنواع من الخدمات والموارد لتكون مرئية للعموم ومتاحة للجميع على الإنترنت، مثل خادوم الويب؛ إلا أن أنواعا أخرى من الخدمات لا يستخدمها إلا مدير النظام أو أفراد محددون وهي غير موجهة لتكون موردا يتاح للجميع الوصول إليه. يعرَّف الطرق على المنافذ Port kcnocking بأنه وسيلة لحماية العمليات Processes التي ينطبق عليها الوصف الأخير. يعمل الطرق على المنافذ على إخفاء المنافذ المرتبطة بإجراء مّا خلف الجدار الناري إلى أن تُنقل متتالية محدَّدة ومعرَّفة سلفا من حزم البيانات عبر الشبكة؛ حينها تعيد خدمة الطرْق على المنافذ ضبط الجدار الناري من أجل السماح بالوصول إلى التطبيق المحمي. تحدثنا في دروس سابقة عن كيفية تفعيل آلية للطرق على المنافذ عبر خدمة خاصة بهذا الغرض (knockd أو fwknop). سنشرح في هذا الدليل المكون من جزأين طريقة بديلة لإعداد الطرق على المنافذ. لا تعتمد هذه الطريقة على برنامج إضافي لتغيير قواعد الجدار الناري؛ بل تستعين بوِحدة لتتبع الحالة State-tracking module موجودة في جدار iptables الناري، تسمى recent. نفترض في هذا الدليل معرفة أساسيات التعامل مع iptables. ستكون الإعدادات على خادوم خاص افتراضي يعمل بتوزيعة أوبنتو 14.04. يجب أن لا تكون هناك تغييرات كبيرة بالنسبة لبقية توزيعات لينكس. ملحوظة: يغطي هذا الشرح الإصدار الرابع من بروتوكول IP. يفصل لينكس بين تأميني الإصدار الرابع والإصدار السادس. على سبيل المثال، لا تنطبق قواعد iptables إلا على حزم البيانات المنقولة عبر عناوين الإصدار الرابع، غير أنه يوجد مكافئ لها بالنسبة لعناوين الإصدار الرابع وهو ip6tables. نظرة عامة على الطرق على المنافذ في IPTablesأولا، وقبل البدء في ضبط الإعدادات، سنصف كيفية عمل وِحدة recent وكيف تسمح لنا بإنشاء نظام للطرْق على المنفذ. يتيح iptables إمكانية تحميل الوحدات عبر خيار m-. يمكن لوِحدة recent تتبع حالات الاتصال، وهو ما سنستغله لجعل محاولات الاتصال بمنفذ هدف (SSH على سبيل المثال) تمر عبر متتالية من المنافذ حسب ما إذا كان المستخدم أصاب المنفذ المطلوب سابقا في المتتالية. سنحظُر - لأغراض هذا الدرس - الوصول إلى خدمة SSH من الإنترنت، ممثَّلة بالواجهة eth0. ثم نعيد ضبط الجدار الناري ديناميكيا للسماح باتصالات SSH من الجهاز الذي نستخدمه مباشرة بعد الطرْق حسب المتتالية المتفق عليها؛ وهي: 111122223333يجب ألا تستخدم هذه القيم في الإعدادت الحقيقية، لسهولة تخمينها. لكي يُستوثَق من المستخدم بطريقة صحيحة وبالتالي يجعل iptables يعرِض خدمة SSh لعنوان IP الذي يتصل منه فإن عليه طرق منافذ المتتالية بالترتيب، دون أن يرسل أي بيانات أخرى بينها. إن نفذنا هذه الآلية بنجاح فسنحصل على نظام للطرق على المنافذ. خطة إعداد IPTablesسنستخدم بضعة سلاسل IPTables من أجل تطبيق الآلية المشروحة في الفقرة السابقة. أولا؛ نسمح بجميع حركة البيانات التي لا نريد إخضاعها للطرق على المنافذ. يتعلق الأمر بكل الموارد العمومية، مثل خادوم الويب، والاتصالات الجارية أو تلك القادمة من الواجهة المحلية. بعدها مباشرة نوجّه كل الاتصالات التي لا تنطبق عليها القاعدة السابقة إلى سلسلة جديدة تحوي القواعد الأساسية للجدار الناري. من المهم جدا اتباع هذه الطريقة عند تطبيق مجموعة قواعد عريضة ومتحفّظة؛ إذ أنها تتيح وسيلة سهلة لتفعيل ميزة بتمرير الاتصالات إلى السلسلة الجديدة أو تعطيلها بجعلها تتجنبها. سنسمي هذه السلسلة KNOCKING. سنستخدم أيضا سلاسل أخرى. تسمح وحدة recent بتصنيف الاتصالات وبالتالي التحقق ما إذا كان اتصال مّا يطابق تصنيفا معرفا مسبقا. سنعتمد على خاصية تصنيف الاتصالات لوضع علامات على عناوين IP التي أرسَلت طرقة إلى الوجهة (المنفَذ) الأولى؛ ونضيف قاعدة تبحث عن أول عنوان معلَّم وتتحقق من أن حزمة البيانات الثانية أُرسلت إلى الوجهة المطلوبة. إذا كان الأمر كذلك فسننشئ علامة جديدة للدلالة على أننا حصلنا على إجابتين صحيحتين لحد الساعة؛ وإلا فستُلغى الحزمة ويُعاد تعيين العلامة. تعمل السلاسل الموالية بنفس طريقة التحقق من العلامة المطلوبة وتمريرها إن استمرت على المسار المطلوب، أي متتالية الطرق. في النهاية وبعد الحصول على الحزم المطلوبة بالترتيب، تُعرض خدمة SSH برهةً قصيرة لعنوان IP الذي طَرَق بمتتالية صحيحة؛ ثم تُخفى من جديد تلقائيا. يمكن النظر إلى قواعد الطرْق هذه على أنها ثلاث بوابات للدخول إلى الخدمة، بوابة لكل قاعدة. يعني هذا أن أي عنوان IP سيكون في إحدى حالات أربع: الحالة الابتدائية: تبقى جميع عناوين IP في الحالة الابتدائية إلى أن ترسل حزمةً إلى أول وِجهة طرق. لن توجد قاعدة للتعامل مع هذه العناوين ضمن وحدة recent. نستخدم هذه الحالة للتدليل على العملاء الذين لم توضع علامات على عناوينهم بعد. الحالة auth1: توضع علامة auth1 على العناوين أرسلت حزمة إلى أول منفذ ضمن متتالية الطرق. تحدد الحزمة الموالية ما إذا كان العنوان سيُعاد للحالة الابتدائية أو يتقدم إلى الحالة auth2. الحالة auth2: يعني وجود عنوان في هذه الحالة أنه أصاب الهدفيْن الأول والثاني على التوالي. على منوال قاعدة الانتقال السابقة، تحدد الحزمة الموالية من العميل ما إذا كان العنوان سيُعاد للحالة الابتدائية أو يتقدم إلى الحالة auth3. الحالة auth3: العناوين المعلَّمة بauth3 هي تلك التي أصابت المنافذ الثلاثة على الترتيب وضمن الوقت المخصَّص. إذا حاول عميل يوجد في الحالة auth3 الاتصال بالخدمة الآن في الوقت المحدّد فسيُسمَح له بالوصول إليها؛ أما إذا أرسل بيانات مغايرة لتلك المستخدمة في الاتصال بالخدمة فسيرجع إلى الحالة الابتدائية. ستُنشأ لكل واحدة من هذه الحالات سلسلة Chain ضمن قواعد الجدار الناري، إضافة إلى كونها علامات تضبطها وحدة recent. تُلخَّص السلاسل على النحو التالي: GATE1: تحدد هل يجب نقل العميل من الحالة الابتدائية إلى auth1. GATE2: تحدد هل يجب نقل عنوان من الحالة auth1 إلى auth2 أم تجب إعادة تعيينه وإرجاعه إلى الحالة الابتدائية. GATE2: تحدد هل يجب نقل عنوان من الحالة auth2 إلى auth3 من أجل السماح له بالاتصال عن طريق SSH؛ أم تجب إعادة تعيينه وإرجاعه إلى الحالة الابتدائية. PASSED: تستخدَم هذه السلسلة لفتح منفذ SSH خلال مدة قصيرة للعملاء الذين نجحوا في إرسال الطرْقات. إذا أرسل عميل تنطبق عليه هذه السلسلة بيانات غير موجهة للاتصال بSSH فسيُتجاهل وبالتالي يعاد تعيين حالته إلى الحالة الابتدائية. من الواضح أن لدينا نقاط قرار عدة. يجب تجاهل كل محاولات الاتصال من سلسلة KNOCKING والسلاسل المتفرعة عنها (باستثناء الاتصالات القادمة إلى خدمة SSH من عملاء نجحوا في الطرْق)؛ وذلك بغض النظر هل وافقت المنفذ الصحيح أم لا. آلية وضع العلامات أعلاه هي وسيلة داخلية في الجدار الناري لتتبع محاولات الاتصال، وليست معروضة للعميل. هذا الأمر ضروري لنجاح تنفيذ الطرق على المنافذ. يجب ألا يتلقى من يحاول الاتصال أي رد كما لا يجوز أن يعرف الحالة التي يوجد فيها، بل لا يجوز أصلا أن يعرف وجود آلية على الخادوم للطرق على المنافذ. في الجزء الثاني من هذا الدليل سنشرح كيفية العمل على تنفيذ خطة العمل هذه. ترجمة - بتصرف - لمقال How To Configure Port Knocking Using Only IPTables on an Ubuntu VPS. حقوق الصورة البارزة: Shield vector designed by Freepik.