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

سنتعرف في هذا المقال من سلسلة المقالات حول التعامل مع ويندوز 10 على جدار الحماية Firewall الخاص بويندوز 10 ، حيث سنتعلّم التعامل معه بشكل أساسيّ، ثم نبحر في بعض التفاصيل حول كيفيّة ضبطه، ومن ثمّ التحكّم بوصول التطبيقات المثبتة على ويندوز 10 إلى الانترنت. ما هو جدار الحماية؟ جدار الحماية Firewall ببساطة عبارة عن برمجيّة تعمل على إدارة حركة الاتصالات الشبكيّة الصادرة من، والواردة إلى الحاسوب. حيث تسمح بمرور أو منع هذه الاتصالات بالاستناد إلى قواعد محدّدة معرّفة سابقًا. كما قد يكون الجدار الناري عبارة عن جهاز مستقل بذاته يشكل همزة وصل بين الشبكة الداخلية لإحدى الشركات وبين شبكة الانترنت. يحتوي ويندوز 10 كما هو الحال مع الإصدارات السابقة، على برمجيّة جدار حماية مضمّنة فيه يمكن الوصول إليها وإعدادها. توجد في الواقع العديد من البرمجيّات الأخرى التي من الممكن أن تلعب مثل هذا الدور. وخاصّة برمجيّات مكافحة الفيروسات التي تتضمّن في الكثير من الأحيان برمجيّة جدار الحماية. سنتحدّث في هذا المقال عن برمجيّة جدار الحماية الخاص بويندوز 10. إعداد جدار الحماية الخاص بويندوز 10 انقر زر ابدأ، ثم انتقل إلى لوحة التحكم. ستظهر لك نافذة شبيهة بما يلي: انقر النظام والأمان كما يظهر في الشكل السابق لتحصل على الشكل التالي: يظهر من الشكل السابق بند "جدار حماية Windows"، انقره للوصول إلى النافذة الرئيسيّة لتطبيق جدار الحماية كما في الشكل التالي: يظهر من هذا الشكل وجود نوعين من الشبكات التي يقوم جدار حماية ويندوز بمراقبتها. سبب وجود أكثر من شبكة يساعد على جعل العمل على ويندوز 10 أيسر. هناك نوعين من الشبكات كما هو واضح من الشكل السابق: النوع الأول هو "شبكات خاصة" والتي تشتمل على الشبكات المنزليّة، وشبكات العمل والتي تُعتبر بيئة عمل آمنة، فقد يرغب المرء بمشاركة الملفات والصور بين أجهزة الحاسوب المتصلة على نفس الشبكة، أو الوصول إلى الطابعة اللاسلكية مثلًا، وغيرها من الأجهزة التي يمكن وصلها على الشبكة. فمن الممكن في هذه الحالة تعطيل جدار الحماية على هذا النوع من الشبكات، وذلك لجعل تنفيذ مثل هذه العمليّات أسهل بكثير، ودون الحاجة إلى ضبط الكثير من الاعدادات، كون أنّ مثل هذه الشبكات تكون آمنة على المستوى الشخصي. أمّا النوع الثاني فهو "شبكات عامة أو شبكات الضيوف" وهو نوع غير آمن بالضرورة، حيث نحتاج في هذه الحالة إلى تفعيل جدار الحماية للوقاية من الأخطار الكامنة. يتيح لنا التصنيف السابق أن نجعل عمليّة الحماية انتقائيّة بحسب نوع الشبكة. فبالنسبة إلى النوع الأوّل يمكننا تعطيل جدار الحماية بكل بساطة، أمّا بالنسبة إلى النوع الثاني، فيمكننا إبقاء حالة التشغيل له، وسيتذكّر ويندوز 10 مثل هذه الخيارات دومًا بالنسبة لكل شبكة، مما يغنينا عن تشغيل أو إيقاف جدار الحماية بالنسبة لكل نوع. لإيقاف تشغيل جدار الحماية بالنسبة للشبكات الخاصة انقر على الرابط "تشغيل جدار الحماية Windows أو إيقاف تشغيله" الموجود في الجهة اليمنى من النافذة التي تظهر في الشكل السابق لتظهر لك النافذة التالية: انقر على خيار "إيقاف تشغيل جدار حماية Windows (غير مستحسن)" الخاص بإعدادات الشبكات الخاصة. ثم انقر زر "موافق". إنشاء قواعد للتحكم بوصول التطبيقات إلى الانترنت يمكن التحكّم بوصول تطبيق مُحدّد موجود على الحاسوب إلى الانترنت، أو حتى إلى الشبكة الخارجية، وذلك عن طريق الإعدادات المتقدّمة الموجودة في الجهة اليمنى من النافذة الرئيسية الخاصة بإعدادات جدار الحماية. عند نقر "إعدادات متقدّمة" ستحصل على شكل شبيه بما يلي: انقر Outbound Rules للتحكم بقواعد الاتصالات الصادرة. ستعرض النافذة جميع القواعد المتوفرة كما في الشكل التالي: انقر الخيار New Rule الموجود ضمن العمود الأيمن من النافذة في الشكل السابق، لتحصل على شكل شبيه بما يلي: يتم من خلال هذه النافذة تحديد النوع الذي ستطبّق عليه هذه القاعدة. فيما إذا كان برنامج عادي Program أو منفذ Port أو قاعدة معرفة مسبقًا Predefined أو قاعدة مخصّصة Custom. سنترك الخيار الافتراضي وهو Program. انقر بعد ذلك الزر Next. ستظهر لك نافذة تسمح لك بتحديد البرنامج الذي سيتم تطبيق هذه القاعدة عليه. انقر زر Browse لتحديد مسار الملف البرمجي المطلوب كما في الشكل التالي: اختر مسار البرنامج الذي ترغب بمنعه من الوصول إلى الانترنت. بالنسبة إلي سأختار برنامج المفكرة المحلق بالويندوز على سبيل المثال. انقر بعدها على Next. ستظهر نافذة تطلب منك تحديد نوع القاعدة فيما إذا كانت قاعدة منع للاتصال أم قاعدة سماح للاتصال أم قاعدة سماح بالاتصال في حال كان الاتصال آمنًا secured. وهذا يعني أنّ نفس الخطوات ستجري تمامًا إذا أردنا السماح لتطبيق ما بالاتصال بالانترنت وليس منعه. سنختار بالطبع منع التطبيق من الاتصال بالانترنت “Block the connection” في مثالنا هذا. انقر زر Next للمتابعة حيث ستحصل على الشبكات التي سيتم تطبيق هذه القاعدة عليها. اترك الاختيارات الافتراضية كما هي، ثم انقر زر Next مجددًا. بقي أمر أخير قبل إنشاء القاعدة وهو تحديد اسم لها Name، مع إضافة بعض الوصف ضمن الحقل Description. بالنسبة إلي سأختار الاسم Block Notepad Application. اضغط زر Finish ليتم انشاء القاعدة ومن ثمّ إدراجها ضمن مجموعة القواعد التي لديك. الخلاصة تعرّفنا في هذا المقال على كيفيّة التعامل مع جدار الحماية الخاص بويندوز. ذلك التطبيق المهم الذي يُستخدم للحماية من الأخطار التي تهدّد الخصوصيّة والأمن للمستخدم. تعلّمنا كيفيّة ضبطه بالشكل الملاءم للشبكة التي نتصل من خلالها، كما تعلّمنا كيفيّة منع تطبيق مُحدّد من الاتصال بالانترنت حسب قواعد rules خاصّة. هناك الكثير مما يمكن قوله حول جدران الحماية، ولكن سنكتفي بما أوردناه في هذا المقال.

إن 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.

يُوفّر التّحكّم بخادوم لينكس الخاصّ بك فرصةً لتجربة أشياء جديدة والاستفادة من صلابة ومرونة هذه المنصّة الرّائعة. مع ذلك يجب على مسؤولي خواديم لينكس الانتباه إلى أنّ ميزات المنصّة لا تُغني عن التّدابير اللّازم اتّخاذها عند التّعامل مع حاسوب متّصل بالشّبكة، من أجل تأمينه وحمايته. تندرج العديدُ من الموضوعات الأمنيّة في الفئة العامة المسمّاة “أمان لينكس”، كما توجد العديد من الآراء حول مستوى الأمان المناسِب لخاودم لينكس. الفكرة الأساسيّة الّتي يجب العمل عليها هي تقرير نوعيّة الإجراءات الأمنيّة المطلوبة لحماية نظامك. قبل ذلك، ولكي تتّخذ القرارات المناسبة؛ يجب أن تعيَ الأخطار الموجودة والمقايضات الممكنة ثمّ تحدّد نقطة التّوازن بين قابليّة الاستخدام والأمان. يهدف هذا المقال إلى مساعدتك في اتّخاذ قراراتك عبر عرض بعض الإجراءات الأمنيّة الأكثر شيوعًا في البيئات الّتي تستخدم خواديم لينكس. يُرجى الانتباه إلى أنّ هذه القائمة غير شاملة ولا تتطرّق للإعدادات المنصوح بها؛ لكنّها ستُحيل إلى روابط توفّر موارد أكثر وتناقش مدى أهميّة بعض العناصر في نُظُم مختلفة. استخدام الجدران النّاريّة Firewalls لمنع الوصول ضبط وإعداد جدار ناريّ إحدى الخطوات الأسهل الّتي ينبغي تطبيقها في عمليّة تأمين الخادوم. تعمل الجدارن النّارية كحاجز بين شبكة الإنترنت وخادومك الخاصّ؛ حيثُ تُراقب حركة البيانات من وإلى الخادوم، ثمّ تقرّر السّماح لها بالمرور أو منعها. تعتمد الجدران النّاريّة في قراراتها (السّماح بمرور بيانات أو منعها) على قواعد يضبطها مدير النّظام. في العادة، يستعمل الخادوم بضع منافذ Ports للخدمات المُرخَّصة بينما تبقى بقيّة المنافِذ غير مستعملة ويجب أن توضع وراء جدار ناريّ يمنع جميع الطّلبات الموّجهة عبر هذه المنافذ من الوصول. تسمح لك الجدران النّاريّة بتجاهل البيانات الّتي لا تنتظر توجيهها إليك، وفي بعض الحالات تقييد الوصول إلى الخدمات الفعليّة الموجودة في النّظام. تُوفّر قواعد الجدران النّاريّة المعدّة بطريقة صحيحة أساسًا جيّدًا لتأمين الشّبكة. نستعرض في الفقرات التّاليّة بعض برامج الجدران النّاريّة. 1- UFW يهدف UFW (اختصار ل Uncomplicated FireWall، أي جدار ناريّ غير معقّد) إلى توفير حماية جيّدة دون الاعتماد على صيّاغة معقَّدة للقواعد كما تفعل بقيّة الحلول. UFW هو في الواقع، مثله مثل أغلب الجدران النّاريّة على لينكس، برنامج للتّحكّم في الجدار النّاري المُضمَّن في نواة لينكس، والمسمَّى Netfilter. يُعدّ UFW حلًّا سهلًا لغير المعتادين على استخدام الجدران النّاريّة على لينكس؛ وهو عمومًا حلّ جيّد. يُمكن الحصول على معلومات أكثر عن UFW، ومعرفة كيفيّة تفعيله وضبطه عبر اتّباع هذا الرّابط. 2- IPTables ربّما يكون IPTables الجدار النّاري الأكثر شهرة في لينكس. IPTables هو الآخر وسيلة لإدارة Netfilter. يتوفّر برنامج IPTables منذ زمن بعيد، وتعرَّض للكثير من التّدقيق خلال هذه الفترة للتّأكّد من أمانه. توجد نسخة مخصّصة للإصدار 6 من عناوين IP، تُسمّى IP6Tables. ستلاقي على الأرجح إعدادات تتضمّن IPTables أثناء إدارة خواديم لينكس. قد تكون صيّاغة القواعد صعبة الفهم من الوهلة الأولى، إلّا أنّ IPTables يبقى أداةً قويّة يُمكن إعدادها عن طريق مجموعة قواعد مرنة جدًّا. يشرح هذا الدّرس إعداد بعض قواعد IPTables على توزيعتيْ أوبنتو ودبيان؛ في ما تجد في الرّابط التّالي شرحًا لاستخدام IPTables على توزيعات CentOS، وFedora و RHEL. 3- IP6Tables يُستخدَم IPTables للتّعامل مع قواعد تتضمّن عناوين IP من الإصدار الرّابع IPv4؛ إذا كان الإصدار السّادس IPv6 مفعّلًا على خادومك فيجب أن تنتبه أيضًا إلى إصدار IPTables المكافئ: IP6Tables. يحتفظ الجدار النّاري المضمَّن في نواة لينكس، Netfilter، بجداول منفصلة لكلّ من البيانات المنقولة عبر IPv6 وIPv4. من هذا المنطلق، تتحدّد القواعد المطبَّقة على حزمة بيانات بإصدار IP المستخدَم. يعني هذا، بالنّسبة لمدير النّظام، أنّه يتوجّب إعداد مجموعة قواعد جديدة خاصّة بالإصدار 6 من عناوين IP، عندما يكون مفعَّلًا. تتشارك قواعد IP6Tables نفس الصّيّاغة مع قواعد IPTables؛ وهو ما يعني أنّ إضافتها لين يُشكّل مشكلًا كبيرًا. ينبغي فقط الانتباه إلى أنّ القواعد يجب أن تُطابق البيانات المُمرَّرة عبر IPv6 حتى تعمل بالطّريقة المطلوبة. 4- NFTables يُعدّ IPTables المعيار Standard في عالم الجدران النّاريّة على بيئات لينكس منذ بعض الوقت، على الرّغم من ذلك أُضيف مؤخَّرًا جدار ناريّ جديد يُدعى NFTables إلى نواة لينكس. يقف خلف الجدار الجديد نفس الفريق الّذي يُطوِّر IPTables. ويهدف - على الأمد الطّويل - إلى الحلول محلّ IPTables. يُحاول جدار NFTables مراعاة صيّاغة أكثر قابليّة للقراءة من صيّاغة IPTables، ويدعم قواعد تتعامل مع كلا الإصداريْن IPv4 وIPv6 في نفس الأداة. يُتوقَّع أن يكون NFTables حاضرًا على معظم أو كلّ توزيعات لينكس في الأمد القريب، لذا يُستحسَن محاولة التّعوّد على استخدامه. استخدام SSH للولوج الآمن عن بعد ستحتاج لطريقة للدّخول عن بعد، إن لم تكن لديك فرصة الوصول المباشر إلى الخادوم. الإجراء المتبَّع في هذه الحالة للدّخول بشكل آمن هو استخدام بروتكول معروف يُسمَّى SSH (اختصار لSecure SHell). يُوفّر SSH التّعميّة من طرف إلى طرف End-to-end encryption، إمكانيّة تمرير بيانات غير مؤمَّتة عبر اتّصال آمن، إعادة توجيه الخادوم X (واجهة المستخدِم الرّسوميّة عبر الشّبكة)، وأكثر. بالمختصر إذا أردت الاتّصال عن بعد بخادومك فيجب أن يكون SSH خيّارك الأوّل. على الرّغم من أنّ بروتوكول SSH نفسه آمن جدًّا وتعرَّض للكثير من التّدقيقات الأمنيّة، إلّا أنّ خيّارات الإعداد يُمكن أن تُعزّز أو - على العكس - تقوِّض أمان الخدمة. سنناقش هذا الأمر أدناه. 1- كلمة السّرّ في مقابل مفاتيح SSH لتسجيل الدّخول يُتيح SSH العديد من طرق الاستيثاق Authentication؛ أشهر طريقتيْن هما كلمة السّرّ ومفتاح SSH. كلمة السّرّ، من بين الخيّارين أعلاه، هي الأيسَر للمستخدم ولكنّها في نفس الوقت الأقلّ أمانًا. يسمح الاستيثاق عن طريق كلمة السّرّ لمحاولي التّسلّل باستمرار تخمين كلمة السّر إلى أن يُعثَر على الكلمة المُناسبة. تُسمّى آليّة الاختراق هذه بهجمات القوّة القاسيّة Brute force attack ويُمكن تشغيلها آليًّا بيُسر عن طريق بعض الأدوات البرمجيّة. على الجانب الآخر، تعمل مفاتيح SSH على توليد زوج من المفاتيح، عموميّ وسرّي. يُنشَأ مفتاح عموميّ Public key ليُستعمَل في تحديد هويّة المستخدِم، ويُمكن تشاركه دون مشاكل. لا يُمكن استعمال المفتاح العموميّ لأغراض أخرى غير تعريف مستخدِم، والسّماح بالولوج بمفتاح سرّي Private key موافق للمفتاح العموميّ المستعمَل. ينبغي أن لا يُنشَر المفتاح السّريّ، حيث يُستخدَم في التحقّق من المفتاح العموميّ المُصاحِب له. المبدأ هوّ أن تُضيف مفتاح SSH العموميّ الخاصّ بك إلى الخادوم وسيُسمح لك بالولوج باستعمال المفتاح السّري المُصاحِب للمفتاح العموميّ المُضاف إلى الخادوم. هذه المفاتيح على درجة من التّعقيد تجعل استخدام هجمات القوّة القاسيّة لتخمينها غير عمليّ. إضافةً لذلك، يمكن تحديد عبارة سرّ Passphrase طويلة إلى المفتاح السّرّيّ وهو ما يعني أمانًا أكبر. راجع هذا الدّرس لمعرفة المزيد حول الاتّصال عن طريق على خادوم أوبنتو SSH. الرّابط التّالي يشرح كيفيّة توليد مفاتيح SSH على خادومك. 2- إعداد fail2ban لحظر عناوين IP الخبيثة تُساعد أداة fail2ban في تأمين إعدادات SSH، ومن ثَمَّ الأمان العامّ للخادوم. تعمل fail2ban على مراقبة السّجلّات Logs لتحديد إمكانيّة أن يكون من يُحاول الاتّصال عبر SSH غيرَ مصرَّح له بالدّخول؛ في هذه الحالة يعمل fail2ban على حظر حركة البيانات القادمة من عنوان IP المُستخدَم. يسمح إعداد إستراتيجيّة صحيحة لاستخدام fail2ban بتحديد الأجهزة الّتي تحاول باستمرار - دون نجاح - الولوج إلى الخادوم، وإضافة قواعد للجدار النّاريّ لتجاهل حركة البيانات القادمة من هذه الأجهزة لفترة من الوقت. تُستعمل هذه الطّريقة دائمًا لعرقلة هجمات القوّة القاسيّة، إذ أنّ المهاجِم سيحتاج عندما يُحظَر، للانتظار بعض الوقت قبل معاودة الكرّة. يكفي هذا الأمر عادةً لإحباط من يحاول الدّخول عبر هذه الهجمات. يُمكن التّعرّف في الرّابط على كيفيّة ضبط fail2ban على أوبنتو. توجد أيضًا أدلّة مشابهة لكل من Debian وCentOS. ضبط نظام للكشف عن التّطفّل Intrusion Detection System لكشف عمليّات الدّخول غير المرخَّصة يجب الانتباه إلى وجوب إعداد آليّة لكشف الاستخدام غير المرخَّص. يُمكن أن تعدّ تدابير وقائيّة لكنك تحتاج أيضًا إلى معرفة هل نجحت هذه التّدابير أم لا. تعمل أنظمة الكشف عن التّطفّل، IDS، على تجميع معطيات عن الإعدادات والملفّات عندما يكون النّظام في وضعيّة يُعرف بأنّها جيّدة؛ ثمّ يُجري النّظام مقارنات بالمعطيات المُسجّلة لرصد تغييرات على الملفّات أو الإعدادات. سنرصد في ما يلي بعض أنظمة الكشف عن التّطفّل. 1- Tripwire يُعدّ Tripwire أحد أنظمة الكشف عن التّطفّل الأكثر شهرة. يُنشئ Tripwire قاعدة بيانات بملفّات النّظام ويحمي ملفّات الإعداد والملفّات التّنفيذيّة بمجموعة من المفاتيح. تُشعِر عمليّاتُ تشغيل Tripwire التّاليّةُ لتعيين تفاصيل الإعداد وتحديد الاستثناءات بأيّ تحريف يحصُل للملفّات الّتي يُراقبها. يُقدّم Tripwire نموذجًا مرِنًا لإعداد السّيّاسات يسمح بتشكيل خواصّه لتتلاءم مع بيئة العمل. يُمكن بعدها ضبط Cron ليُشغّل Tripwire دوريًّا؛ بل ويُمكن إعداد إشعارات تُرسَل عبر البريد الإلكترونيّ عند وجود أنشطة غير طبيعيّة. اقرأ المزيد عن إعداد Tripwire. 2- Aide برنامج Aide هو خيّار آخر لأنظمة الكشف عن التّطفّل. يُشبه Aide في عمله Tripwire؛ حيثُ ينشئ قاعدة بيانات ثمّ يقارن الوضعيّة الحاليّة للنّظام مع قيّم محفوظة أثناء وجود النّظام في وضعيّة جيّدة. عند ملاحظة أي اختلاف يُمكن للبرنامج إشعار مسؤول النّظام. يوفّر كلّ من Aide وTripwire حلولًا متشابهة لنفس المشكل. راجع التّوثيق Documentation وجرّب الاثنين ثم اختر ما يُناسبك. اقرأ الدّليل التّالي لمعرفة كيف تستخدم Aide لكشف التّطفّل. ### 3- Psad يختلف برنامج Psad عن البرنامجيْن السّابقيْن من حيث إنّه يهتمّ بجزء مختلف من النّظام. بدلًا من مراقبة ملفّات النّظام، فإن Psad يُراقب سجلّات الجدار النّاريّ لمحاولة رصد النّشاطات غير الطّبيعيّة. على سبيل المثال، إذا وُجد من يبحث عن ثغرات Vulnerabilities في النّظام عن طريق فحص المنافذ Ports فإنّ Psad يُمكن أن يرصُد هذا النّشاط ويغيّر قواعد الجدار النّاريّ ديناميكيًّا لحظر المستخدِم المعنيّ. يُمكن لهذا البرنامج تسجيل مستويات عديدة للتّهديدات ثمّ يعتمد في تجاوبه مع التّهديدات على خطورة المشكل الّذي يواجهه. توجد أيضًا إمكانيّة إرسال بريد لمدير النّظام. اقرأ الدّرس التّالي للمزيد حول استخدام برنامج Psad. ### 4- Bro برنامج Bro هو وسلة أخرى لضبط نظام كشف عن التّطفّل يعتمد على حركة البيانات في الشّبكة. Bro هو في الأصل إطار عمل Framework لمراقبة الشّبكة؛ يُمكن استخدامه كنظام للكشف عن التّطفّل أو لأغراض أخرى مثل تجميع إحصائيّات عن الاستخدام، التّحرّي عن المشاكل أو التّعرّف على أنماط Patterns معيَّنة. يُقسًّم نظام Bro إلى طبقتيْن. الطّبقة الأولى تُراقب النّشاطات وتُولّد أحداثا Events. أمّا الطّبقة الثّانيّة فتشغّل الأحداث المُولَّدة تبعًا لسيّاسات تُملي ما يتوجّب عمله. يُمكن لهذه الطّبقة إرسال تحذيرات، تنفيذ أوامر، مجرّد تسجيل الحالة أو إجراءات أخرى. يشرح الدّليل التّالي كيفيّة استخدام Bro لكشف التّطفّل. ### 5- RKHunter لا يعدّ برنامج RKHunter - تقنيًّا - برنامجًا للكشف عن التّطفّل، إلّا أنّه يعمل بنفس المبادئ الّتي تستخدمها أنظمة الكشف عن التّطفّل المعتمدة على مراقبة ملفّات النّظام، مثل Tripwire وAide. يهدف RKHunter في الأساس إلى كشف برامج Rootkits (برامج تُساعد المهاجمين في إخفاء ما ينفّذونه من عمليّات على النّظام) والبرمجيّات الخبيثة Malwares المعروفة. على الرّغم من ندرة الفيروسات على لينكس إلّا أنّ البرمجيّات الخبيثة وبرامج Rootkits موجودة ويُمكن أن تُصيب الخادوم وتُعطي إمكانيّة ولوج مستمرّ لمستغلّي الثّغرات. يُنزّل RKHunter قائمة بالثّغرات المعروفة ويتأكّد من عدم وجودها على النّظام؛ كما أنّه يحذّر مدير النّظام في حال كشف إعدادات غير آمنة في بعض التّطبيقات الشّائعة. يوجد في الرّابط التّالي دليل لاستخدام RKHunter على أوبنتو. General Security Advice تُساعد الأدوات المذكورة أعلاه في تأمين أجزاء من نظامك، إلّا أنّ الأمان لا يأتي فقط من إعداد أداة ثمّ نسيانها. يظهر الأمان في بعض العقليّات؛ ويمكن أن يتحقّق عبر الاجتهاد، التّدقيق والانخراط في عمليّة التّأمين. توجد بعض القواعد الّتي يُساعد اتّباعها في وضعك على الطّريق الصّحيح للاستخدام الآمن لنظامك. 1- انتبه إلى التّحديثات وحدّث الخادوم بانتظام يُعثر على الثّغرات طول الوقت وفي كلّ أنواع البرامج الّتي يمكن أن تكون لديك على الخادوم. يؤدّي مطوّرو التّوزيعات على العموم عملًا جيّدًا في الاطّلاع على آخر الثّغرات الأمنيّة والحرص على إرسال تحديثاتها إلى المستودعات Repositories؛ إلّا أنّ توفّر التّحديثات الأمنيّة في المستودَع لا يعني أنّ الخادوم آمن ما لم تُنزّلها وتثبّتها عليه. على الرّغم من أن الخواديم تستفيد من إصدارات مجرَّبَة جيّدًا، إلّا أنّ التّرقيعات الأمنيّة يجب أن تُعدَّ حرِجة ويجب تثبيتها فور صدورها. تُوفّر العديد من التّوزيعات قوائم بريديّة خاصّة بالأخبار الأمنيّة ومستودعات أمنيّة منفصِلة لتنزيل التّرقيعات الأمنيّة. 2- كن حذِرًا عند تنزيل برامج من خارج القنوات الرّسميّة يلتصق الكثير من المستخدمين بالبرامج المتوفّرة في المستودعات الرّسميّة لتوزيعاتهم، كما أنّ أغلب التّوزيعات تُوفّر حزمًا Packages موَقَّعة Signed. يُمكن عمومًا للمستخدمين الوثوق في مطوّري التّوزيعات والتّركيز على التّهديدات الأمنيّة في البرامج المُتحصَّل عليها من خارج المستودعات الرّسميّة للتّوزيعة. يُمكن أن تثق في الحزم القادمة من التّوزيعة الّتي تستخدمها أو من مواقع ويب رسميّة، لكن انتبه إلى إمكانيّة وجود خطر أمنيّ، إلّا إذا كنت تدقّق كل جزء من البرامج بنفسك. يرى الكثيرون أنّ مستوى الخطر هذا مقبول. على العكس من ذلك، يمكن للبرامج المتحصَّل عليها من مستودعات عشوائيّة أو من مستودعات PPA (اختصار لPersonal Package Archives، أرشيف حزم شخصية) يُشرف عليها أشخاص أو منظَّمات غير معروفة، يمكن أن تكون خطرًا محدِقا. لا توجد قاعدة عامّة، ولكن يمكن عدّ أغلب البرامج المتوفّرة في المستودعات غير الرّسميّة آمنة؛ لكن يجب الحذر والانتباه إلى وجود خطر في كلّ مرة تثق في طرف ثالث. تأكّد من قدرتك على شرح السّبب الّذي يجعلك تثق في مصدر البرنامج. في النّهاية الخطر على أمان نظامك مشكل أكبر من عدم توفّر بعض وسائل الرّاحة في التّعامل مع النّظام. 3- اعرف خدماتك وعرّف حدود استخدامها على الرّغم من أنّ الهدف الأساسيّ من تشغيل خادوم هو توفير خدمات، إلّا أنّه يجب تحديد الخدمات المُشغّلة على الجهاز وعدم تشغيل خدمات لا تحتاجها. انظُر إلى كلّ خدمة مُفَعَّلة على أنّها ناقل للخطر؛ وحاول التّخلّص من كلّ ناقل خطر حسب استطاعتك بحيث لا تؤثّر على الوظائف الّتي تُريد توفيرها عبر الخادوم. يعني هذا أنّك يجب أن تُعطّل خادوم العرض X إذا لم توجد شاشة متّصلة بالخادوم ولم تكن تشغِّل أي برامج رسوميّة (برامج الويب لا تدخل في هذا التّصنيف). يُمكن اتّخاذ إجراءات مشابهة في مجالات أخرى؛ لا تستخدمُ طابعة؟ عطِّل خدمة lp. لا تشارك الملفّات مع وندوز؟ عطِّل خدمة samba. توجد طرق عديدة لمعرفة الخدمات المُشغَّلة على جهازك. يعرض المقال التّالي لطريقة إنشاء قائمة بالخدمات المُفَعَّلة. 4- لا تستخدم FTP، استعِض عنه بSFTP. قد تكون هذه النّقطة من أكثر الأمور صعوبة للتّطبيق على كثير من المستخدمين؛ لكن بروتوكول FTP غير آمن منذ بداياته. كلّ معلومات الاستيثاق تُرسل في نصوص صِرفة (غير معمّاة) Plain-text، وهو ما يعني أنّ باستطاعة كلّ من يراقب الاتّصال بين الجهاز المحلّي وبين الخادوم معرفة بيانات الاستيثاق. توجد حالات قليلة يُمكن أن يكون فيها استخدام FTP مبرَّرا. إذا كنت تشغّل مرآة تنزيل عموميّة، مجهولة وللقراءة فقط؛ فFTP ربّما يكون خيّارًا مناسِبا. يُمكن أيضًا استخدام FTP عند نقل ملفّات بين حاسوبيْن موجوديْن في شبكتيْن محميتْن بجدار ناريّ، وتثق في أن الشّبكتيْن آمنتان. يجب أن تستخدم في أغلب الحالات الأخرى بديلًا آمنًا. تأتي حزمة SSH ببروتكول بديل يُسمَّى SFTP، يُستخدَم بنفس طريقة استخدام FTP ويوفّر نفس درجة الأمان الّتي يُوفّرها بروتوكول SSH. يشرح درس كيف تستخدِم SFTP لنقل الملفّات بأمان إلى خادوم بعيد طريقة التّعامل مع SFTP. 5- اضبُط سيّاسات حسّاسة لأمان المستخدمين توجد عدّة خطوات يُمكن تطبيقها لتأمين النّظام عند إدارة المستخدِمين. الاقتراح الأوّل هو تعطيل دخول المستخدِم الجذر Root user. يُعدّ حساب المستخدِم الجذر مقصِدًا جذّابًا لمحاولات التّسلّل نظرًا لوجوده على كلّ الأنظمة المتوافقة مع معيار POSIX، وللامتيّازات اللّامحدودة الّتي يتمتّع بها في النّظام. تبدو فكرة تعطيل دخول المستخدم Root، بعد إعداد الوصول عن طريق sudo أو إذا كنت مرتاحًا مع أمر su، تبدو فكرةً جيّدة. لا يوافق الكثيرون على هذه الفكرة؛ جرّب جدوائيّتها بالنّسبة لك. توجد إمكانيّة تعطيل الدّخول عن بعد لحساب root ضمن إعدادات SSH، كما يُمكن تعطيل الدخول للحساب الجذر محلّيًا. يُمكن أيضًا إضافة تقييدات على الحساب ضمن ملف الإعداد etc/securetty/، أو ضبط برنامج Shell للمستخدم الجذر بحيث يُشير إلى برنامج آخر ممّا ينتج عنه تعطيل وصول root إلى Shell. خيّار آخر يتمثّل في إعداد قواعد PAM (أو Pluggable Authentication Modules، وهي طبقة لتمكين الاستيثاق بين خدمات مختلفة على الأنظمة الشّبيهة بيونكس) لتقييد ولوج المستخدم الجذر. توفّر RedHat مقالًا رائعًا حول كيفيّة تعطيل دخول المستخدم الجذر. يتوجّب أيضًا العمل على تنفيذ سيّاسة أمنيّة يُنشَأ بموجبها حساب وحيد لكلّ مستخدم أو خدمة، ثمّ يُعطى الأذون Permissions الدّنيا اللّازمة لعمله. امنع الوصول إلى كلّ ما لا تحتاج الوصول إليه ولا تعطِ للمستخدمين امتيّازات لا يحتاجون إليها. هذه السّيّاسة مهمّة جدًّا، ففي حالة اختراق مستخدِم أو خِدمة فلن يؤدّي ذلك إلى تأثير الدومينو الّذي يسمح لمهاجمٍ بالحصول على صلاحيّات واسعة في النّظام. تُساعد طريقة التّقسيم هذه في عزل المشاكل الأمنيّة، بحيث لا يتسبّب مشكل أمنيّ لدى حساب واحد في تعريض كامل النّظام للخطر. يجب كذلك التّأكّد من تعطيل حسابات المستخدمين عندما تنقضي الحاجة إليها؛ مثلًا، عند إلغاء تثبيت برنامج. 6- انتبِه لإعداد الأذون تمثّل صلاحيّات الملفّات مصدرًا كبيرًا للجزع لدى كثير من المستخدمين؛ فقد يكون من الصّعب العثور على نقطة توازن بحيث يُمكن للمستخدِم أداء عمله دون أن يعرّض نفسه أو النّظام للخطر. يحتاج هذا الأمر إلى الانتباه والتّفكير في كلّ سيناريو ممكن. يجب التّفكير في سيّاسة أمنيّة تضبُط umask (الخاصّيّة الّتي تحدّد الأذون الافتراضيّة للملفّات والمجلّدات الجديدة) بما يُناسِب؛ الأمر الّذي يُشكّل خطوة كبيرة على الطّريق الصّحيح. المقال التّالي يتطرّق لكيفيّة ضبط umask. القاعدة العامّة هي ألّا تضبط إذن الكتابة على أي ملفّ إلّا إذا كان ذلك ضروريًّا، خصوصًا إذا أمكن الوصول للملفّ عبر الإنترنت، لما قد ينتُج عنه من عواقب. إضافةً لذلك، يجب ألّا تُعدّل على بت SGID أو SUID، إلّا إذا كنت تدرك جيّدًا ما تفعل. تحقّق أيضًا من أنّ كلّ الملفّات لديها مالِك ومجموعة. يتغيّر إعداد الأذون كثيرًا حسب الحاجة، ولكن يجب دائمًا محاولة العثور على طريقة لتلبيّة الحاجة بأقل أذون ممكن. ينبغي الانتباه إلى سهولة الخطأ في إعداد الأذون، ووجود العديد من النّصائح الخاطئة حولها على الإنترنت. كيف تؤمِّن برنامجًا تستخدمه لا يكفي حجم هذا المقال للتّطرّق لخصوصيّات تأمين كلّ نوع من البرامج أو الخدمات، إلّا أنّه توجد العديد من الدّروس والأدلّة المتاحة على الشّبكة. يجب أن تقرأ النّصائح الأمنيّة لكلّ برنامج تريد إعداده للعمل على جهازك. بالنّسبة لبرامج الخادوم الشّهيرة مثل خواديم الويب ونُظُم إدارة قواعد البيانات، توجد مواقع ويب وقواعد بيانات كاملة مخصَّصة للأمان. على العموم، يجب أن تقرأ حول تأمين كلّ خدمة قبل إعدادها وتشغيلها. خاتمة يجب أن تكون لديك الآن معرفة جيّدة بالإجراءات الأمنيّة الممكن إعدادها على خادوم لينكس. حاولنا في هذا الدّليل التّعرّض للعديد من المجالات ذات الأهميّة الكبيرة، ولكن في نهاية المطاف ستحتاج اتّخاذ قرارات بنفسك. يتوجب عليك، بوصفك مديرًا للنّظام؛ تحمّل مسؤوليّاتك في تأمين الخادوم. تأمين الخادوم ليس إجراءً يُؤدّى مرةً واحدة، لكنّه عملّية مستمرّة تتضمّن فحص النّظام باستمرار، إعداد الحلول، التحقّق من السّجلاّت والتّنبيهات، إعادة تعريف الاحتيّاجات، …إلخ. اليقظة واستمرار تقويم ومراقبة الإجراءات المتَّبعة أمور ضروريّة للحفاظ على الأمن. ترجمة بتصرّف لمقال An Introduction to Securing your Linux VPS لصاحبه Justin Ellingwood.

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.

استخدام الجدار الناري (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.

من المرغوب عادةً عند الانتقال من خادوم إلى آخر أن تُنقَل قواعد الجدار الناري 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.

الجدار الناري هو نظامٌ يوفِّر حمايةً للشبكة عبر ترشيح البيانات المُرسَلة والمُستقبَلة عبر الشبكة بناءً على قواعد حدّدها المستخدم. عمومًا، الهدف من الجدار الناري هو تقليل أو إزالة وجود الاتصالات الشبكية غير المرغوب فيها والسماح في الوقت نفسه للاتصالات «الشرعية» أن تُنقَل بحريّة؛ تُوفِّر الجدر النارية طبقةً أساسيةً من الحماية التي -عندما تُدمَج مع غيرها- تمنع المهاجمين من الوصول إلى خادومك بطرقٍ خبيثة. يناقش هذا الدّرس كيف تعمل الجدر النارية، مع التركيز على برمجيات الجدر النارية «ذات الحالة» (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.