عبد اللطيف ايمش

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

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

سنرى في هذا الدرس كيفية تثبيت وإعداد Mailpile، الذي هو عميل ويب سريع وآمن وجميل للبريد للإلكتروني، على نظام أوبنتو Ubuntu 14.04. عميل ويب للبريد الإلكتروني مثل Mailpile هو طريقةٌ ممتازةٌ للتأكد أنك تستطيع الوصول إلى بريدك من أي مكان دون الفوضى التي تحدث عند ضبط عميل بريد قياسي؛ Mailpile هو مجرد عميل بريد، مما يعني أنه يدير حسابات البريد الموجودة مسبقًا فقط. ستحصل، في نهاية هذا الدرس، على خدمة سحابية تعمل عملًا تامًا تشغِّل Mailpile مع خادم Nginx كخادم وسيط عكسي (reverse proxy). ابقِ في ذهنك خلال قراءتك لهذا الدرس أن Mailpile ما يزال تجريبيًّا (في مرحلة beta)، الذي يعني أنك ربما تواجه عللًا وصعوباتٍ أخرى في الطريق... لا يحتفظ Mailpile بمعلوماتك بين الجلسات (أي أن عليك إعادة إدخال معلومات حسابك في كل مرة تعيد فيها تشغيل Mailpile). ولا يحتوي أيضًا على طريقة سهلة لتشغيله كخدمة (service)؛ افتراضيًا، يمكنه أن يعمل فقط كسكربت تفاعلي في جلسة SSH؛ لكننا ضمّنا سكربت Upstart يستخدم Screen لتشغيله في الخلفية، لذلك يمكنك ترك عميل الويب للبريد يعمل إلى أن تشاء إغلاقه؛ لكن ذلك ليس طريقةً مستحسنةً للتشغيل في بيئة إنتاجية. المتطلبات المسبقةسنحتاج إلى بضعة أشياء قبل البدء: خادوم (Droplet) يعمل بنظام أوبنتو 14.04، من المستحسن أن يكون لديك 512 ميغابايت من ذاكرة الوصول العشوائي على الأقل لكي يستطيع Mailpile إدارة عدِّة صناديق بريد إلكتروني؛ إذا كنت تتوقع استخدامه من أكثر من مستخدمَين، فربما تريد زيادة الحجم.مستخدم يملك امتيازات الجذر (root)، راجع هذا الدرس لتعليمات حول إعداد مستخدم يملك امتيازات الجذر عبر sudo في أوبنتو 14.04شهادة SSL لإبقاء بريدك آمنًا؛ يمكنك شراء واحدة من Namecheap أو سلطة شهادات (certificate authority) أخرى؛ إذا لم تكن تريد إنفاق المال، فيمكنك إنشاء شهادتك لاستخدامها مع Nginx أو يمكنك الحصول على واحدة من StartSSL.اسم نطاق.إذا كنت تملك نطاقًا، فأنشِئ سجل A للإشارة إلى خادومك (على سبيل المثال mailpile.example.com).الحظ أماكن وجود شهادة SSL الخاصة بك والمفاتيح؛ إذا اتبعت الدرس التعليمي لإنشاء شهادات لاستخدامها مع Nginx، فسيكونوا موجودين في: /etc/nginx/ssl/nginx.crt و /etc/nginx/ssl/nginx.keyهذا كل ما في الأمر، إذا كان لديك كل شيء جاهزًا، فأكمل إلى الخطوة الأولى. الخطوة الأولى – تنزيل Mailpileسنُحضِّر في هذا القسم بيئة العمل لتثبيت Mailpile. علينا أولًا تسجيل الدخول إلى خادومنا، تأكد أنك سجلت دخولك بمستخدم لديه امتيازات الجذر عبر sudo. علينا بادئ الأمر تثبيت Git، سنستخدم Git لنسخ كود Mailpile المصدري من GitHub. حدِّث فهرس حزم مستودعات أوبنتو: sudo apt-get updateثبِّت Git: sudo apt-get install gitالآن بعد تثبيت Git، لنغيّر مجلد العمل الحالي إلى مكانٍ آخر لكي نجري أعمالنا فيه؛ في هذه الحالة، سنستخدم المجلد ‎/var: cd /varانسخ (clone) كود Mailpile: sudo git clone https://github.com/mailpile/Mailpile.gitستحتاج إلى استخدام sudo للسماح للأمر Git بإنشاء مجلد داخل ‎/var، الذي هو مجلد نظام. كاد أن يصبح نظامك جاهزًا لتشغيل Mailpile، انتقل الآن إلى الخطوة الثانية لاستعرض المزيد من المتطلبات. الخطوة الثانية – ضبط متطلبات Mailpileسنثبت ونضبط في هذا القسم متطلبات Mailpile. أولًا، لنثبت pip؛ إن pip هو مدير حزم لبايثون: sudo apt-get -y install python-pipسيسمح pip لنا بتثبيت متطلبات Mailpile بطريقة أسهل؛ سترى كيف يتم ذلك خلال دقيقة، لكن علينا أولًا تثبيت المزيد من الأشياء. علينا الآن تثبيت lxml؛ إن lxml هو من متطلبات Mailpile الذي يُثبَّت عادةً بواسطة pip، لكننا وجدنا أنه يسبب فشل التثبيت لأسبابٍ غير معروفة؛ وبسبب ذلك، سنُثبِّته عبر apt-get: sudo apt-get install python-lxmlيجب تثبيت بعض الحزم الأخرى يدويًا أيضًا، بما في ذلك GnuPG و OpenSSL؛ ستجعل هذه الحزم البيئة أكثر أمانًا لبريدنا. يمكن أن تكون بعض الحزم مثبتةً افتراضيًا، لكننا سنتأكد من ذلك على أيّة حال تحسبًا لعدم وجودها: sudo apt-get install gnupg openssl libssl-devبدِّل الآن مجل العمل الحالي إلى مجلد Mailpile: cd /var/Mailpileإننا جاهزون الآن لاستغلال إمكانيات pip لتثبيت بقية المتطلبات. يحتوي Mailpile على ملف باسم requirements.txt، الذي هو قائمة بمتطلباته؛ يملك pip القدرة على قراءة تلك القائمة وتثبيت كل واحدٍ فيها تلقائيًّا؛ لنفعل ذلك إذًا: sudo pip install -r /var/Mailpile/requirements.txtلقد إنتهينا، لقد ثبتنا جميع المتطلبات، وأصبح Mailpile جاهزًا للاستخدام، لكن قبل أن نشغِّله، علينا إجراء بعض الخطوات الإضافية لتزيد من الأمان. الخطوة الثالثة – ضبط وسيط عكسي عبر Nginxسنضبط Nginx في هذا القسم كوسيط عكسي لخدمة Mailpile؛ وهذا ما سيجعل Mailpile أكثر أمانًا، سامحًا لنا باستخدام شهادة SSL، وبتسهيل الوصول إلى عميل الويب للبريد. باستخدام Nginx –بدلًا من الوصول إلى Mailpile بزيارة http://example.com:33411– فستستطيع استخدام https://mailpile.example.com، لنبدأ! علينا أولًا تثبيت Nginx لأننا سنستخدمه لإنجاز معظم الأعمال؛ لذلك لنحصل على Nginx قبل أي شي: sudo apt-get install nginxالآن، وبعد أن ثبّتنا Nginx، يمكننا ضبط خادم الوسيط العكسي؛ لنعدل ضبط Nginx لتوجيه النطاق الفرعي إلى Mailpile. ربما تريد أن تحذف ملف ضبط Nginx الافتراضي، لأنه مليئ بأشياءٍ لا نحتاجها؛ لكن أولًا، لنُنشِئ نسخةً احتياطيةً؛ أنشِئ أولًا المجلد: sudo mkdir /home/backupثم خذ نسخةً احتياطيةً: sudo cp -b /etc/nginx/sites-enabled/default /home/backupيمكنك الآن حذف الملف بحرية دون عواقب وخيمة: sudo rm /etc/nginx/sites-available/defaultلنتأكد من أن الملف قد حُذِف: ls /etc/nginx/sites-available/إذا ثبَّتتَ Nginx الآن، فيجب ألّا يعيد الأمر السابق أيّة مخرجات. لننشِئ الآن ملفًا جديدًا: sudo nano /etc/nginx/sites-available/defaultحان الآن الوقت لضبط الوسيط العكسي؛ لنبدأ بالقسم الأول. أضف ما يلي إلى بداية الملف (سنشرح ماذا يفعل بعد ثوانٍ): /etc/nginx/sites-available/default server { listen 80; return 301 https://$host$request_uri; }ما سبق يخبر Nginx أن يعيد توجيه الطلبيات التي تأتي إليه إلى HTTPS؛ لكنه في الواقع يعيد التوجيه إلى شيءٍ غير موجودٍ بعد؛ لننشِئ ذلك: /etc/nginx/sites-available/default server { listen 443; server_name mailpile.example.com; ssl_certificate /etc/nginx/ssl/nginx.crt; ssl_certificate_key /etc/nginx/ssl/nginx.key; ssl on; ssl_session_cache builtin:1000 shared:SSL:10m; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4; ssl_prefer_server_ciphers on; access_log /var/log/nginx/mailpile.access.log; تأكد من أن الشهادة والمفتاح موجودان في ‎/etc/nginx/ssl/nginx.crt و ‎/etc/nginx/ssl/nginx.key؛ عدا ذلك، فحَدِّث المسارات بعد ssl_certificate و ssl_certificate_key لمطابقة مسارات الشهادة والمفتاح. ما أدخلناه في الأعلى يخبر Nginx أن يستمع إلى المنفذ 443 (المنفذ المستعمل للوصول إلى مواقع الويب عبر SSL، على النقيض من المنفذ 80)، ويستخدم شهادة SSL الخاصة بنا، ويشغِّل SSL. يجب علينا الآن أن نخدِّم شيئًا ما لعنوان HTTPS URL الذي أعدنا التوجيه إليه وفعّلنا SSL عليه؛ وهذا ما سنفعله في الخطوة الآتية. أضف ما يلي إلى الكتلتين النصيتين السابقتين: /etc/nginx/sites-available/default location / { proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; # Fix the "It appears that your reverse proxy set up is broken" error. proxy_pass http://localhost:33411; proxy_read_timeout 90; proxy_redirect http://localhost:33411 https://webmail.example.com; } }بعد أن تنتهي من ذلك، يجب أن يبدو ملف الضبط كما يلي: /etc/nginx/sites-available/default server { listen 80; return 301 https://$host$request_uri; } server { listen 443; server_name mailpile.example.com; ssl_certificate /etc/nginx/ssl/nginx.crt; ssl_certificate_key /etc/nginx/ssl/nginx.key; ssl on; ssl_session_cache builtin:1000 shared:SSL:10m; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4; ssl_prefer_server_ciphers on; access_log /var/log/nginx/mailpile.access.log; location / { proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; # Fix the "It appears that your reverse proxy set up is broken" error. proxy_pass http://localhost:33411; proxy_read_timeout 90; proxy_redirect http://localhost:33411 https://webmail.example.com; } }إذا لم تستبدل الموقع الافتراضي، لكنك أنشَأت «server block file» باسمٍ مختلف، فيمكنك تفعيله كما يلي: sudo ln -s /etc/nginx/sites-available/mailpile.example.com /etc/nginx/sites-enabled/يجب أن يكون الموقع الافتراضي مفعلًا افتراضيًّا. الآن أعد تشغيل Nginx لإعادة تحميل الضبط: sudo service nginx restartهذا كل ما في الأمر؛ يمكن الوصول إلى Mailpile الآن عبر https://mailpile.example.com؛ ربما عليك قبول تحذير SSL إذا استخدمتَ شهادةً موقعةً ذاتيًا (self-singed certificate). ولو حاولت أيضًا الوصول عبر http://mailpile.example.com فستحوَّل تلقائيًّا إلى نسخة SSL من الموقع. لم نشغِّل Mailpile بعد، لذلك إذا زرت هذه العناوين الآن، فستشاهد الخطأ «502 Bad Gateway»، أكثر سبب شائع لهذا الخطأ هو أن تطبيق Mailpile لا يعمل. انتقل الآن إلى الخطوة الرابعة لتشغيل Mailpile. الخطوة الرابعة – ضبط وتشغيل Mailpileسنشغل في هذا القسم Mailpile، ونضبطه ليعمل مع الخادم الوسيط. لنتأكد أننا في المجلد الصحيح: cd /var/Mailpileلتشغيل Mailpile، أدخِل الأمر: ./mpتستطيع الآن البدء في استكشاف Mailpile عبر الواجهة السطرية أو واجهة الويب. تحذير: لن يحفظ Mailpile الضبط الذي أجريته عندما يتوقف عن العمل؛ لذلك قبل أن تقضي وقتًا في ضبطه؛ ربما تريد أن تنجز الخطوة الإضافية لتشغيله كخدمة تعمل في الخلفية. أصبح Mailpile يعمل الآن، ويمكنك الوصول إليه عبر https://mailpile.example.com، وحتى يمكنه إعادة التوجيه إلى HTTPS مُستخدِمًا شهادة SSL الخاصة بك. تهانينا! يمكنك استخدام Ctrl+C ثم كتابة quit للخروج من Mailpile. خطوة اختيارية – اجعل Mailpile يعمل كخدمة مع Upstartللتأكد من أن Mailpile يعمل دائمًا وجاهزٌ للتعامل مع بريدك؛ يمكنك تحويل Mailpile إلى خدمة باستخدام Upstart. لمّا كان Mailpile ما يزال تجريبيًّا، فإنه لم يصبح على شكل خدمة بعد؛ حيث يتطلب وجود سطر أوامر تفاعلي، لذلك لا تستطيع أن تشغل سكربت بايثون مباشرةً. سكربت Upstart الآتي هو طريقة ملتوية لتشغيل تطبيق بايثون كخدمة عبر Screen: sudo nano /etc/init/mailpile.conf /etc/init/mailpile.conf description "Mailpile Webmail Client" author "Sharon Campbell" start on filesystem or runlevel [2345] stop on shutdown script echo $$ > /var/run/mailpile.pid exec /usr/bin/screen -dmS mailpile_init /var/Mailpile/mp end script pre-start script echo "[`date`] Mailpile Starting" >> /var/log/mailpile.log end script pre-stop script rm /var/run/mailpile.pid echo "[`date`] Mailpile Stopping" >> /var/log/mailpile.log end scriptسيبدأ السكربت السابق Mailpile ويبقى يعمل ما دامت جلسة Screen تعمل؛ لا يمكن للسكربت أن يوقِف جلسة Screen إيقافًا سَلِسًا، لذلك عليك إيقاف جلسة Screen يدويًا إذا أردت إيقاف تشغيل Mailpile. مستخدمًا هذا السكربت، يمكنك تشغيل Mailpile عبر: sudo start mailpileمما يؤدي إلى إنشاء جلسة Screen باسم 12345‎.mailpile_init مملوكة من المستخدم الجذر (root). لكن لن تعمل أوامر Upstart الأخرى؛ عليك إنهاء جلسة Screen يدويًا، ولو انهارت الخدمة أو توقفت، فعليك أن تعيد تشغيلها من جديد وتضبط جميع خصائصها. الخطوة الخامسة – التعامل مع Mailpileيوضح هذا القسم كيفية استخدام Mailpile من واجهة الويب، عبر https://mailpile.example.com. هذه هي الشاشة التي ستشاهدها عندما تشغِّل Mailpile لأول مرة. اختر اللغة من القائمة المنسدلة.اضغط على زر «Begin».أنشِئ كلمة مرور جديدة، وأدخلها مرتين.اضغط على زر «Start using Mailpile».في شاشة الدخول: رجاءً أدخِل كلمة المرور التي أنشأتها منذ قليل. أضف حسابًا عبر زر «‎+ Add Account». من هنا، ستحتاج إلى إدخال بيانات حساب البريد الذي تملكه؛ عليك إدخال عنوان البريد الإلكتروني وكلمة المرور لذاك الحساب؛ ثم سيحاول Mailpile أن يتصل إلى حسابك بهذه المعلومات، الأمر الذي قد يستغرق بضع دقائق. يمكنك إدخال بيانات «Sending Mail» و «Receiving Mail» يدويًا، إذا لم يتمكن Mailpile من تحديدها تلقائيًا. تنويه: إن Gmail يحجب Mailpile من استخدام حسابك في Gmail؛ لذلك لن تستطيع إضافة حساب Gmail إلى Mailpile – ليس بسهولة على الأقل. بعد أن تُسجِّل دخولك، فستظهر لك هذه الشاشة: حاول إرسال واستقبال رسالة بريدية تجريبيّة إلى الحساب الذي أضفته إلى Mailpile من حساب بريد إلكتروني آخر؛ إذا نجح ذلك، فاعلم أن Mailpile يعمل مع حساب بريدك الإلكتروني بنجاح. ميزات Mailpile أخرىيوفِّر Mailpile أيضًا تشكيلةً واسعةً من خيارات التشفير: الخلاصةلكي تبدأ مشوارك مع Mailpile، فراجع الأسئلة الشائعة له. للمزيد من خيارات الضبط، نفِّذ الأمر help من سطر أوامر Mailpile. تهانينا، لقد حصلت على عميل ويب للبريد الإلكتروني الخاص بك، الذي يعمل على خادوم أوبنتو 14.04؛ ويعمل تمامًا مع SSL ويعيد التوجيه تلقائيًا إلى نسخة HTTPS من موقعك. يمكنك الآن ضبط حسابات بريدك الإلكتروني وإدارة جهات الاتصال، والبريد، والتصنيفات، والمزيد من واجهة Mailpile الجميلة. استمتع! ترجمة -وبتصرّف- للمقال How To Install Mailpile on Ubuntu 14.04‎ لصاحبه Kellan.

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