تتضمن نواة لينُكس النظام الفرعي Netfilter الذي يُستخدَم لتعديل أو تحديد مصير البيانات الشبكية الداخلة أو الخارجة من الخادوم، تَستخدم جميع الجدر النارية في لينُكس هذا النظام لترشيح الرزم الشبكية.

نظام ترشيح الرزم الخاص بالنواة لن يكون مفيدًا لمدراء الأنظمة دون واجهة لإدارته، وهذا هو الغرض من iptables؛ فعندما تصل رزمة شبكية إلى خادومك، فستتوجه إلى النظام الفرعي Netfilter للموافقة أو التعديل أو الرفض بناءً على القواعد الموفَّرة لها من المستخدم عبر iptables؛ ولهذا سيكون iptables هو كل ما تحتاج لإدارة الجدار الناري إن كان مألوفًا لديك، لكن العديد من الواجهات المتوفرة له ستُبسِّط العملية.

الجدار الناري ufw‏

أداة ضبط الجدار الناري الافتراضية في أوبنتو هي ufw، التي طُوِّرَت لتسهيل ضبط جدار iptables الناري، توفر ufw واجهة «صديقة» للمستخدم لإنشاء جدار ناري لعناوين IPv4 أو IPv6.

إن ufw معطَّل افتراضيًّا. من صفحة دليل man ufw:

«لم يطوَّر ufw لتوفير وظيفة جدار ناري كاملة عبر واجهته السطرية، لكنه يوفر طريقةً سهلةً لإضافة أو حذف القواعد؛ ويستخدم حاليًا استخدامًا رئيسيًا للجدر النارية المعتمدة على المضيف (host-based firewalls).»

هذه بعض أمثلة استخدام 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.

تنفيذ جدار الحماية هو خطوة هامة في تأمين الخادوم الخاص بك. جزء كبير من عملية التنفيذ هو اتخاذ قرارات بشأن القواعد والسياسات التي تفرض قيودا على حركة مرور البيانات. يسمح لك الجدار الناري أن يكون لك دور في بنية إطار العمل الذي يتم فيه تطبيق القواعد الخاصة بك.

في هذا الدليل سوف نبني جدار حماية ليكون أساسا للمزيد من القواعد المعقدة. وسيركز هذا الجدار الناري في المقام الأول على تقديم افتراضات معقولة ووضع إطار سهل التمدد. سيكون تطبيق هذا الدليل على أوبنتو 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.

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.

من المرغوب عادةً عند الانتقال من خادوم إلى آخر أن تُنقَل قواعد الجدار الناري iptables كجزءٍ من العملية؛ سيشرح هذا الدرس لك كيف تنسخ بسهولة القواعد المُفعّلة لجدار iptables من خادوم إلى آخر.

المتطلبات المسبقة

يتطلب هذا الدرس وجود خادومَين؛ سنشير إلى الخادوم المصدر (الذي توجد فيه قواعد iptables) بالخادوم A، والخادوم الوجهة (الذي ستُنقَل إليه القواعد) بالخادوم B.
ستحتاج إلى امتيازات الجذر على كلي الخادومين.

عرض قواعد Iptables الموجودة

قبل نقل قواعد iptables، لننظر إليها أولًا؛ يمكنك فعل ذلك عبر تطبيق هذا الأمر على الخادوم A:

sudo iptables -S

مثالٌ عن ناتج الأمر السابق:

-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -s 15.15.15.51/32 -j DROP

ستُستخدَم القواعد الناتجة في المثال السابق لشرح عملية نقل الجدار الناري.

تصدير قواعد Iptables

يكتب الأمر iptables-save قواعد iptables الحالية إلى stdout (مجرى الخرج القياسي)؛ مما يمنحنا طريقةً سهلةً لتصدير قواعد الجدار الناري إلى ملف، وذلك عبر إعادة توجيه stdout إلى ملف.
استخدم الأمر iptables-save على الخادوم A -الذي تريد نقل القواعد منه- لتصدير القواعد الحالية إلى ملف باسم «iptables-export» كما يلي:

cd ~
sudo iptables-save > iptables-export

هذا سيُنشئ الملف iptables-export في مجلد المنزل (home) الخاص بمستخدمك؛ يمكن أن يُستخدَم هذا الملف على خادومٍ آخر لتحميل قواعد الجدار الناري إلى iptables.

عرض محتويات الملف (خطوة اختيارية)

لنلقِ نظرةً سريعةً على محتويات الملف؛ سنستخدم الأمر cat لإظهار الملف على الطرفية:

cat iptables-export

سيكون ناتج الأمر السابق شبيهًا بما يلي:

# Generated by iptables-save v1.4.21 on Tue Sep  1 17:32:29 2015
*filter
:INPUT ACCEPT [135:10578]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [8364:1557108]
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -s 15.15.15.51/32 -j DROP
COMMIT
# Completed on Tue Sep  1 17:32:29 2015

كما لاحظت، يحتوي الملف على ضبط قواعد iptables المُفعّلة؛ نحن جاهزون الآن لنسخ هذا الملف إلى الوجهة، التي هي الخادوم B.

نسخ القواعد المصدرة إلى الخادوم الوجهة

سنحتاج إلى نسخ ملف القواعد إلى الخادوم الوجهة (الخادوم B)؛ أسهل طريقة لفعل ذلك هي استخدام scp أو نسخ محتويات الملف ثم لصقها في ملفٍ جديد على الخادوم B. سنشرح كيفية استخدام الأمر scp لنسخ الملف عبر الشبكة إلى مجلد ‎/tmp.
نفِّذ أمر scp الآتي على الخادوم A؛ تأكد أنك قد استبدلت الأجزاء المعلّمة ببيانات دخولك إلى الخادوم وعنوان IP له:

scp iptables-export *user*@*server_b_ip_address*:/tmp

سيُنسَخ الملف إلى مجلد ‎/tmp في الخادوم B بعد الاستيثاق (authentication)؛ الحظ أن محتويات المجلد ‎/tmp ستُحذَف عند إعادة الإقلاع، لذا يمكنك نسخ ذاك الملف إلى مكانٍ آخر إن أردت الاحتفاظ به.

استيراد قواعد Iptables

بعد نسخ القواعد المُصدَّرة إلى الخادوم الوجهة، فيمكننا الآن تحميلها إلى iptables؛ لكن -وبالاعتماد على بيئتك- ربما تحتاج إلى تحديث القواعد في الملف ووضع عناوين ومجالات IP جديدة، وربما تريد أيضًا أن تعدِّل أسماء البطاقات الشبكيّة؛ إذا أردت أن تعدِّل القواعد قبل تحميلها، فعليك تعديل الملف ‎/tmp/iptables-export الآن.
بعد أن تكون جاهزًا لتحميل القواعد من ملف iptables-export إلى iptables، فاستخدم الأمر iptables-restore لفعل ذلك.
على الخادوم الوجهة (الخادوم B)، نفِّذ هذا الأمر لتحميل قواعد الجدار الناري:

sudo iptables-restore < /tmp/iptables-export

سيحمِّل الأمر السابق القواعد إلى ipables، يمكنك التحقق من تحميلها بوساطة الأمر sudo iptables -S.

حفظ القواعد

تكون قواعد Iptables مؤقتةً، لذلك يجب أخذ الحيطة عند التعامل معها للحفاظ عليها حتى بعد إعادة الإقلاع؛ سيكون عليك تنفيذ هذه الخطوة على الخادوم B. سنشرح كيفية حفظ القواعد على توزيعتَي أوبنتو و CentOS.

توزيعة أوبنتو

إن أسهل طريقة لحفظ قواعد Iptables في أوبنتو لكي تبقى بعد إعادة الإقلاع هي استخدام حزمة iptables-persistent؛ يمكنك تثبيتها باستخدام الأمر apt-get:

sudo apt-get install iptables-persistent

ستُسأل أثناء التثبيت إذا ما كنتَ تريد حفظ قواعد الجدار الناري الحالية؛ اختر yes إذا أردت حفظها.
إذا حدَّثتَ قواعد جدارك الناري في المستقبل، وأردت حفظ التعديلات، فنفِّذ هذا الأمر:

sudo invoke-rc.d iptables-persistent save

توزيعة CentOS 6 وما قبلها

على توزيعة CentOS 6 وما قبلها (حيث تستخدم CentOS 7 افتراضيًا جدار FirewallD الناري)، يمكنك استخدام سكربت init الخاص بتطبيق iptables لحفظ القواعد:

sudo service iptables save

سيحفظ الأمر السابق قواعد iptables الحالية إلى الملف ‎/etc/sysconfig/iptables، الذي يحمَّل بوساطة iptables عند الإقلاع.

الخلاصة

تهانينا، لقد أتممت نقل قواعد جدارك الناري من خادومك الأصلي إلى خادومك الجديد.

ترجمة -وبتصرف- للمقال: How To Migrate Iptables Firewall Rules to a New Server لصاحبه: Mitchell Anicas.

إن UFW هو أداةٌ لضبط iptables موجودٌ افتراضيًا في أوبنتو؛ يوفِّر هذا الدرس مرجعًا سريعًا لأوامر UFW التي ستُنشِئ قواعد جدار iptables الناري لحالات الاستخدام الشائعة، وهذا يتضمن أمثلةً عن استخدام UFW للسماح وحجب مختلف الخدمات عبر المنفذ، والبطاقة الشبكيّة، وعنوان IP المصدر.

كيف تستخدم هذا الدرس

• إذا كنت قد بدأت لتوِّك باستخدام UFW لضبط جدارك الناري، فراجع الدرس تمهيد إلى UFW.
• تفترض أغلبية القواعد المشروحة هنا أنك تستخدم مجموعة قواعد UFW الافتراضية؛ التي تكون مضبوطةً للسماح بالاتصالات الصادرة وحجب الاتصالات الواردة، لذا عليك أن تنتقي البيانات التي تريد تمريرها
• استعمل الأمثلة الموجودة في الأقسام المتتالية الملائمة لما تودّ تحقيقه؛ لا تعتمد أغلبية الأقسام في هذا الدرس على بعضها بعضًا، لذا يمكنك استخدام الأمثلة الآتية استخدامًا مستقلًا
• انسخ والصق الأمثلة عن الأوامر الموجودة في هذا الدرس، مستبدلًا قيمك بالقيم المُعلَّمة بالأحمر

تذكر أنك تستطيع أن تتحقق من مجموعة قواعد UFW الحالية عبر الأمر sudo ufw status أو sudo ufw status verbose.

حجب عنوان IP

نفِّذ الأمر الآتي لحجب جميع الاتصالات الشبكية التي تُنشَأ من عنوان IP معيّن، مثلًا 15.15.15.51:

sudo ufw deny from 15.15.15.51

يُحدِّد التعبير from 15.15.15.51 في المثال السابق عنوان IP مصدري (source IP) هو «15.15.15.51»؛ يمكنك تحديد شبكة فرعية مثل 15.15.15.0/24 إن أردت ذلك. يمكن تحديد عنوان IP مصدري في أيّة قاعدة من قواعد الجدار الناري، بما في ذلك قاعدة allow.

حجب الاتصالات إلى بطاقة شبكية معينة

استعمل هذا الأمر لحجب جميع الاتصالات من عنوان IP محدد (على سبيل المثال، 15.15.15.51) إلى بطاقة شبكيّة معيّنة، مثل eth0:

sudo ufw deny in on eth0 from 15.15.15.51

يشبه هذا الأمرُ الأمرَ السابق، لكن مع زيادة التعبير in on eth0. يمكن تحديد البطاقة الشبكية في أيّة قاعدة من قواعد الجدار الناري، وهذه طريقةٌ ممتازةٌ لتحديد الدور الذي تلعبه بطاقة شبكية معيّنة.

خدمة SSH

إذا كنتَ تستخدم خادومًا سحابيًا، فربما تريد السماح لاتصالات SSH الواردة (المنفذ 22) لذا يمكنك الاتصال وإدارة خادومك؛ يشرح هذا القسم كيف تَضبط جدارك الناري بمختلف القواعد المتعلقة بخدمة SSH.

السماح لاتصالات SSH

تستطيع استخدام الأمر الآتي للسماح باتصالات SSH الواردة:

sudo ufw allow ssh

صيغةٌ بديلةٌ عن الصيغةِ السابقة هي تحديد رقم المنفذ بدلًا من اسم خدمة SSH:

sudo ufw allow 22

السماح لاتصالات SSH الواردة من عنوان IP معين أو شبكة فرعية

للسماح باتصالات SSH الواردة من عنوان IP معيّن أو شبكة فرعية، فعليك تحديد المصدر؛ على سبيل المثال، إذا أردت السماح لكامل الشبكة الفرعية 15.15.15.0/24، فنفِّذ هذا الأمر:

sudo ufw allow from 15.15.15.0/24  to any port 22

السماح لاتصالات Rsync الواردة من عنوان IP معين أو شبكة فرعية

يمكن أن يُستخدَم Rsync (الذي يعمل على المنفذ 873) لنقل الملفات من حاسوبٍ إلى آخر.
للسماح باتصالات rsync الواردة من عنوان IP معيّن أو شبكة فرعية، فحدد عنوان IP المصدري والمنفذ الوجهة؛ على سبيل المثال، إذا أردت السماح لكامل الشبكة الفرعية 15.15.15.0/24 باستخدام rsync على خادومك، فنفِّذ الأمر الآتي:

sudo ufw allow from 15.15.15.0/24 to any port 873

خادم الويب

تستمع خوادم الويب -مثل أباتشي و Nginx- للطلبيات على المنفذين 80 و 443 لاتصالات HTTP و HTTPS على التوالي وبالترتيب. إذا كانت السياسة الافتراضية للاتصالات الواردة هي الحجب أو التجاهل، فربما تريد إنشاء قواعد تسمح لخادومك بالرد على تلك الطلبيات.

السماح لجميع اتصالات HTTP الواردة

استخدم الأمر الآتي للسماح لجميع اتصالات HTTP (المنفذ 80) الواردة:

sudo ufw allow http

صيغةٌ بديلةٌ عن الصيغةِ السابقة هي تحديد رقم المنفذ بدلًا من اسم خدمة HTTP:

sudo ufw allow 80

السماح لجميع اتصالات HTTPS الواردة

استخدم الأمر الآتي للسماح لجميع اتصالات HTTPS (المنفذ 443) الواردة:

sudo ufw allow https

صيغةٌ بديلةٌ عن الصيغةِ السابقة هي تحديد رقم المنفذ بدلًا من اسم خدمة HTTPS:

sudo ufw allow 443

السماح لجميع اتصالات HTTP و HTTPS الواردة

إذا أردت السماح لاتصالات HTTP و HTTPS معًا، فيمكنك إنشاء قاعدة وحيدة تسمح لكلي المنفذين؛ وذلك بتنفيذ الأمر الآتي:

sudo ufw allow proto tcp from any to any port 80,443

الحظ أنك ستحتاج إلى تحديد البروتوكول (باستخدام proto tcp) عند تحديد عدِّة منافذ.

قواعد بيانات MySQL

تستمع MySQL إلى اتصالات العميل على المنفذ 3306؛ إذا كان سيُستخدَم خادم قواعد بيانات MySQL من عميلٍ على خادوم بعيد؛ فتأكد أنك تسمح بمرور تلك البيانات الشبكية.

السماح لاتصالات MySQL الواردة من عنوان IP معين أو شبكة فرعية

للسماح باتصالات MySQL الواردة من عنوان IP معيّن أو شبكة فرعية، فحدِّد المصدر؛ على سبيل المثال، تستطيع تنفيذ هذا الأمر إذا أردت السماح للشبكة الفرعية 15.15.15.0/24:

sudo ufw allow from 15.15.15.0/24 to any port 3306

السماح لاتصالات MySQL الواردة إلى بطاقة شبكية معينة

استخدم الأمر الآتي للسماح لاتصالات MySQL لبطاقة شبكيّة معيّنة -لنفترض أنّك تملك بطاقة شبكيّة خاصة باسم eth1-:

sudo ufw allow in on eth1 to any port 3306

قواعد بيانات PostgreSQL

تستمع PostgreSQL إلى اتصالات العميل على المنفذ 5432 إذا كان سيُستخدَم خادم قواعد بيانات PostgreSQL من عميلٍ على خادوم بعيد؛ فتأكد أنك تسمح بمرور تلك البيانات الشبكية.

السماح لاتصالات PostgreSQL الواردة من عنوان IP معين أو شبكة فرعية

للسماح باتصالات PostgreSQL الواردة من عنوان IP معيّن أو شبكة فرعية، فحدِّد المصدر؛ على سبيل المثال، تستطيع تنفيذ هذا الأمر إذا أردت السماح للشبكة الفرعية 15.15.15.0/24:

sudo ufw allow from 15.15.15.0/24 to any port 5432

السماح لاتصالات PostgreSQL الواردة إلى بطاقة شبكية معينة

استخدم الأمر الآتي للسماح لاتصالات PostgreSQL لبطاقة شبكيّة معيّنة -لنفترض أنّك تملك بطاقة شبكيّة خاصة باسم eth1-:

sudo ufw allow in on eth1 to any port 5432

خدمة البريد

تستمع خوادم البريد مثل Sendmail و Postfix إلى تشكيلة واسعة من المنافذ بناءً على البروتوكولات المستخدمة لتوصيل البريد؛ إذا كنت تُشغِّل خادوم بريدٍ إلكتروني، فحدِّد البروتوكولات التي تستخدمها واسمح للاتصالات الموافقة لها. سنستعرض أيضًا مثالًا عن إنشاء قاعدة لحجب بريد SMTP الصادر.

حجب بريد SMTP الصادر

ربما تريد أن تحجب بريد SMTP الصادر إذا لم يكن من المفترض لخادومك أن يُرسِل بريدًا إلكترونيًّا؛ استخدم الأمر الآتي لحجب بريد SMTP الصادر (الذي يستخدم المنفذ 25):

sudo ufw deny 25

يضبط الأمر السابق خادومك لتجاهل كل البيانات المُرسَلة على المنفذ 25؛ إذا أردت أن تحجب خدمةً أخرى عبر رقم منفذها، فضع رقم المنفذ الخاص بها بدلًا من 25.

السماح لجميع اتصالات SMTP الواردة

للسماح لخادومك بالرد على اتصالات SMTP على المنفذ 25، فعليك تنفيذ الأمر الآتي:

sudo ufw allow 25

ملاحظة: من الشائع لخوادم SMTP أن تستخدم المنفذ 587 للبريد الصادر.

السماح لجميع اتصالات IMAP الواردة

للسماح لخادومك بالرد على اتصالات IMAP على المنفذ 143، فعليك تنفيذ الأمر الآتي:

sudo ufw allow 143

السماح لجميع اتصالات IMAPS الواردة

للسماح لخادومك بالرد على اتصالات IMAPS على المنفذ 993، فعليك تنفيذ الأمر الآتي:

sudo ufw allow 993

السماح لجميع اتصالات POP3 الواردة

للسماح لخادومك بالرد على اتصالات POP3 على المنفذ 110، فعليك تنفيذ الأمر الآتي:

sudo ufw allow 110

السماح لجميع اتصالات POP3S الواردة

للسماح لخادومك بالرد على اتصالات POP3S على المنفذ 995، فعليك تنفيذ الأمر الآتي:

sudo ufw allow 995

الخلاصة

يجب أن يكون قد غطى هذا الدرس الكثير من الأوامر شائعة الاستخدام عند استعمال UFW لضبط الجدار الناري؛ وبالطبع إن UFW هو أداةٌ مرنةٌ جدًا، لذلك تستطيع دمج مختلف الخيارات مع الأوامر السابقة لملائمة متطلبات خادومك إن لم تكن تلك الأوامر مبيّنةً هنا.

ترجمة -وبتصرف- للمقال: UFW Essentials: Common Firewall Rules and Commands لصاحبه: Mitchell Anicas.

Iptables هو برمجية جدار ناري مضمَّنة افتراضيًّا في أغلبية توزيعات لينُكس. يوفِّر هذا الدرس مرجعًا سريعًا لأوامر iptables التي ستُنشِئ قواعدًا لحالات الاستخدام الشائعة، وهذا يتضمن أمثلةً عن استخدام iptables للسماح وحجب مختلف الخدمات عبر المنفذ، والبطاقة الشبكيّة، وعنوان IP المصدر.

كيف تستخدم هذا الدرس

• إذا كنت قد بدأت لتوِّك باستخدام iptables لضبط جدارك الناري، فراجع الدرس تمهيد إلى iptables.
• تفترض أغلبية القواعد المشروحة هنا أنَّ iptables مضبوطٌ لتجاهل الاتصالات الواردة عبر السياسة الافتراضية، لذا عليك أن تنتقي البيانات التي تريد تمريرها.
• استعمل الأمثلة الموجودة في الأقسام المتتالية الملائمة لما تودّ تحقيقه؛ لا تعتمد أغلبية الأقسام في هذا الدرس على بعضها بعضًا، لذا يمكنك استخدام الأمثلة الآتية استخدامًا مستقلًا.
• انسخ والصق الأمثلة عن الأوامر الموجودة في هذا الدرس، مستبدلًا قيمك بالقيم المُعلَّمة بالأحمر.

أبقِ في بالك أنَّ ترتيب القواعد مهم؛ تستخدم جميع أوامر iptables الآتية الخيار ‎-A الذي يُلحِق (append) القاعدة الجديدة إلى نهاية سلسلة، إذا أردت وضعها في مكانٍ آخر، فيمكنك استخدام الخيار ‎-I الذي يسمح لك بتحديد موقع القاعدة الجديدة (أو ببساطة وضعها في بداية السلسلة [chain] إن لم تُحدِّد رقمًا للقاعدة).

ملاحظة: احذر عند العمل مع الجدر النارية أن تمنع نفسك من الدخول إلى خادومك عبر حجب اتصالات SSH (المنفذ 22 افتراضيًّا)؛ إذا فقدت القدرة على الوصول إلى خادومك بسبب ضبط جدارك الناري، فستحتاج إلى الدخول عبر !طرفية محلية! لتقويم الخلل. بعد أن تسجل دخولك عبر الطرفية المحلية، يمكنك تعديل قواعد جدارك الناري للسماح بالوصول إلى خدمة SSH (أو السماح بعبور جميع بيانات التراسل الشبكي)؛ إذا كانت قواعد جدارك الناري المحفوظة تسمح بالوصول عبر SSH، فستتمكن عبر إعادة تشغيل الخادوم من الاتصال مجددًا عبر SSH.

تذكَّر أنك تستطيع التحقق من مجموعة قواعد iptables الحالية بالأمرَين sudo iptables -S و sudo iptables -L.
لنلقِ نظرةً على أوامر iptables.

حفظ القواعد

تكون قواعد iptables مؤقتة، مما يعني أنه من الضروري حفظها يدويًا لكي تبقى بعد إعادة الإقلاع.

توزيعة أوبنتو

أسهل طريقة لحفظ قواعد iptables في أوبنتو كي تبقى حتى لو أُعيد الإقلاع هي استخدام الحزمة iptables-persistent؛ ثبِّتها عبر apt-get كما يلي:

sudo apt-get install iptables-persistent

ستُسأل أثناء التثبيت إذا ما كنت تريد حفظ قواعد جدارك الناري الحالية.
إذا حدَّثت قواعد جدارك الناري وأردت حفظ التغييرات، فنفِّذ الأمر الآتي:

sudo invoke-rc.d iptables-persistent save

توزيعة CentOS 6 وما قبلها

يمكنك استخدام سكربت init لجدار iptables لحفظ القواعد في توزيعة CentOS 6 وما قبلها (تَستخدم توزيعة CentOS 7 جدار FirewallD افتراضيًّا):

sudo service iptables save

سيحفظ الأمر السابق قواعد iptables الحالية إلى ملف ‎/etc/sysconfig/iptables.

قواعد مفيدة عموما

يتضمن هذا القسم تشكيلةً من أوامر iptables التي ستُنشِئ قواعدًا مفيدةً في أغلبية الخواديم.

السماح بالاتصالات إلى بطاقة Loopback

بطاقة «loopback» (التي يُشار إليها أيضًا بالاسم lo) هي البطاقة التي يستخدمها الحاسوب لإجراء اتصالات شبكيّة مع نفسه؛ على سبيل المثال، إذا شغَّلت ping localhost أو ping 127.0.0.1، فإن خادومك سيجري عملية ping لنفسه باستخدام بطاقة loopback؛ يمكن الاستفادة أيضًا من بطاقة loopback إذا ضَبطتَ تطبيقك للاتصال إلى خادوم قواعد بيانات ذي العنوان «localhost»؛ ولهذا عليك أن تتأكد أنَّ جدارك الناري يسمح بمرور لهذه الاتصالات.
لقبول مرور جميع بيانات التراسل الشبكي على بطاقة loopback، فعليك تنفيذ هذين الأمرين:

sudo iptables -A INPUT -i lo -j ACCEPT
sudo iptables -A OUTPUT -o lo -j ACCEPT

السماح للاتصالات الواردة المنشأة والمتعلقة

يجب عادةً أن تمر بيانات التراسل الشبكي باتجاهين (صادرة وواردة) لكي تعمل الاتصالات الشبكية عملًا صحيحًا؛ من الاعتيادي إنشاء قاعدة في الجدار الناري للسماح بالاتصالات الواردة المُنشَأة (established) والمتعلقة (related)، مما يمكِّن الخادوم من استقبال البيانات المُرجَعة من اتصالات صادرة بدأها الخادوم نفسه؛ سيكون الأمر كما يلي:

sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

السماح بمرور البيانات للاتصالات الصادرة المنشأة

ربما تود السماح للبيانات الصادرة لجميع الاتصالات المُنشَأة، التي تكون عادةً الرد على الاتصالات الواردة المسموح لها؛ الأمر الذي يفعل بذلك هو:

sudo iptables -A OUTPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT

التمرير من الشبكة الداخلية إلى الخارجية

على فرض أنَّ eth0 هي شبكتك الخارجية، و eth1 هي شبكتك الداخلية، فإن الأمر الآتي سيسمح بتمرير البيانات من الشبكة الداخلية إلى الخارجية:

sudo iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT

تجاهل الرزم الشبكية غير الصالحة

تُعلَّم بعض الرزم الشبكية على أنها «غير صالحة» (invalid)؛ قد يكون مفيدًا في بعض الأخيان تسجيل هذا النوع من الرزم لكن يكون عادةً من المقبول تجاهلها. يمكنك فعل ذلك بوساطة هذا الأمر:

sudo iptables -A INPUT -m conntrack --ctstate INVALID -j DROP

حجب عنوان IP

استعمل الأمر الآتي لحجب الاتصالات الشبكية التي تنحدر من عنوان IP معيّن، ولنقل أنه 15.15.15.51 مثلًا:

sudo iptables -A INPUT -s 15.15.15.51 -j DROP

يُحدِّد التعبير ‎-s 15.15.15.51 عنوان IP المصدري على أنه «15.15.15.51»، يمكن أن يُحدَّد عنوان IP المصدري في أيّة قاعدة من قواعد الجدار الناري، بما في ذلك قواعد السماح (allow).
إذا كنت تريد «رفض» (reject) الاتصال بدلًا من تجاهله (أي سيكون الرد على الاتصال هو خطأ «connection refused») فبدِّل «DROP» إلى «REJECT» كما يلي:

sudo iptables -A INPUT -s 15.15.15.51 -j REJECT

حجب الاتصالات إلى بطاقة شبكية

لحجب جميع الاتصالات من عنوان IP معيّن (15.15.15.51 مثلًا)، إلى بطاقة شبكيّة معيّنة (eth0 مثلًا) فاستخدم هذا الأمر:

iptables -A INPUT -i eth0 -s 15.15.15.51 -j DROP

يشبه هذا الأمر كثيرًا الأمرَ في الفقرة السابقة، لكنه يزيد عنه بالتعبير ‎-i eth0؛ يمكن تحديد البطاقة الشبكية في أيّة قاعدة من قواعد الجدار الناري، وهذه طريقةٌ رائعةٌ لجعل قاعدةٍ ما محدودةً إلى شبكةٍ معيّنةٍ فقط.

خدمة SSH

إذا كنتَ تستخدم خادومًا سحابيًا، فربما تريد السماح لاتصالات SSH الواردة (المنفذ 22) لذا يمكنك الاتصال وإدارة خادومك؛ يشرح هذا القسم كيف تضبط جدارك الناري بمختلف القواعد المتعلقة بخدمة SSH.

السماح لاتصالات SSH

تستطيع استخدام الأمرين الآتيين للسماح لجميع اتصالات SSH الواردة:

sudo iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
sudo iptables -A OUTPUT -p tcp --sport 22 -m conntrack --ctstate ESTABLISHED -j ACCEPT

الأمر الثاني (الذي يسمح بمرور بيانات التراسل الشبكي لاتصالات SSH المُنشَأة) مطلوبٌ فقط إذا لم تكن سياسة OUTPUT مضبوطةً إلى ACCEPT.

السماح لاتصالات SSH الواردة من عنوان IP معين أو شبكة فرعية

للسماح باتصالات SSH الواردة من عنوان IP معيّن أو شبكة فرعية، فعليك تحديد المصدر؛ على سبيل المثال، إذا أردت السماح لكامل الشبكة الفرعية 15.15.15.0/24، فنفِّذ هذين الأمرين:

sudo iptables -A INPUT -p tcp -s 15.15.15.0/24 --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
sudo iptables -A OUTPUT -p tcp --sport 22 -m conntrack --ctstate ESTABLISHED -j ACCEPT

الأمر الثاني (الذي يسمح بمرور بيانات التراسل الشبكي لاتصالات SSH المُنشَأة) مطلوبٌ فقط إذا لم تكن سياسة OUTPUT مضبوطةً إلى ACCEPT.

السماح لاتصالات SSH الصادرة

إذا لم تكن سياسة OUTPUT في جدارك الناري مضبوطةً إلى ACCEPT، فربما تريد السماح لاتصالات SSH الصادرة (أي أن يبدأ خادومك اتصال SSH إلى خادومٍ آخر) بتنفيذ هذين الأمرين:

sudo iptables -A OUTPUT -p tcp --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
sudo iptables -A INPUT -p tcp --sport 22 -m conntrack --ctstate ESTABLISHED -j ACCEPT

السماح لاتصالات Rsync الواردة من عنوان IP معين أو شبكة فرعية

يمكن أن يُستخدَم Rsync (الذي يعمل على المنفذ 873) لنقل الملفات من حاسوبٍ إلى آخر.
للسماح باتصالات rsync الواردة من عنوان IP معيّن أو شبكة فرعية، فحدِّد عنوان IP المصدري والمنفذ الوجهة؛ على سبيل المثال، إذا أردت السماح لكامل الشبكة الفرعية 15.15.15.0/24 باستخدام rsync على خادومك، فنفِّذ الأمرين الآتيين:

sudo iptables -A INPUT -p tcp -s 15.15.15.0/24 --dport 873 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
sudo iptables -A OUTPUT -p tcp --sport 873 -m conntrack --ctstate ESTABLISHED -j ACCEPT

الأمر الثاني (الذي يسمح بمرور بيانات التراسل الشبكي لاتصالات rsync المُنشَأة) مطلوبٌ فقط إذا لم تكن سياسة OUTPUT مضبوطةً إلى ACCEPT.

خادم الويب

تستمع خوادم الويب -مثل أباتشي و Nginx- للطلبيات على المنفذين 80 و 443 لاتصالات HTTP و HTTPS على التوالي وبالترتيب. إذا كانت السياسة الافتراضية للاتصالات الواردة هي الحجب أو التجاهل، فربما تريد إنشاء قواعد تسمح لخادومك بالرد على تلك الطلبيات.

السماح لجميع اتصالات HTTP الواردة

استخدم الأمرين الآتيين للسماح لجميع اتصالات HTTP (المنفذ 80) الواردة:

sudo iptables -A INPUT -p tcp --dport 80 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
sudo iptables -A OUTPUT -p tcp --sport 80 -m conntrack --ctstate ESTABLISHED -j ACCEPT

الأمر الثاني (الذي يسمح بمرور بيانات التراسل الشبكي لاتصالات HTTP المُنشَأة) مطلوبٌ فقط إذا لم تكن سياسة OUTPUT مضبوطةً إلى ACCEPT.

السماح لجميع اتصالات HTTPS الواردة

استخدم الأمرين الآتيين للسماح لجميع اتصالات HTTPS (المنفذ 443) الواردة:

sudo iptables -A INPUT -p tcp --dport 443 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
sudo iptables -A OUTPUT -p tcp --sport 443 -m conntrack --ctstate ESTABLISHED -j ACCEPT

الأمر الثاني (الذي يسمح بمرور بيانات التراسل الشبكي لاتصالات !HTTPS! المُنشَأة) مطلوبٌ فقط إذا لم تكن سياسة OUTPUT مضبوطةً إلى ACCEPT.

السماح لجميع اتصالات HTTP و HTTPS الواردة

إذا أردت السماح لجميع اتصالات HTTP و HTTPS الواردة معًا، فيمكنك استخدام الوحدة (module) ‏«mulitport» لإنشاء قاعدة تسمح بمرور البيانات على كلي المنفذين؛ وذلك عبر الأمرين الآتيين:

sudo iptables -A INPUT -p tcp -m multiport --sports 80,443 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
sudo iptables -A OUTPUT -p tcp -m multiport --sports 80,443 -m conntrack --ctstate ESTABLISHED -j ACCEPT

الأمر الثاني (الذي يسمح بمرور بيانات التراسل الشبكي لاتصالات HTTP و HTTPS المُنشَأة) مطلوبٌ فقط إذا لم تكن سياسة OUTPUT مضبوطةً إلى ACCEPT.

قواعد بيانات MySQL

تستمع MySQL إلى اتصالات العميل على المنفذ 3306؛ إذا كان سيُستخدَم خادم قواعد بيانات MySQL من عميل على خادوم بعيد؛ فتأكد أنك تسمح بمرور تلك البيانات الشبكية.

السماح لاتصالات MySQL الواردة من عنوان IP معين أو شبكة فرعية

للسماح باتصالات MySQL الواردة من عنوان IP معيّن أو شبكة فرعية، فحدِّد المصدر؛ على سبيل المثال، تستطيع تنفيذ هذين الأمرين إذا أردت السماح للشبكة الفرعية 15.15.15.0/24:

sudo iptables -A INPUT -p tcp -s 15.15.15.0/24 --dport 3306 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
sudo iptables -A OUTPUT -p tcp --sport 3306 -m conntrack --ctstate ESTABLISHED -j ACCEPT

الأمر الثاني (الذي يسمح بمرور بيانات التراسل الشبكي لاتصالات MySQL المُنشَأة) مطلوبٌ فقط إذا لم تكن سياسة OUTPUT مضبوطةً إلى ACCEPT.

السماح لاتصالات MySQL الواردة إلى بطاقة شبكية معينة

استخدم الأمر الآتي للسماح لاتصالات MySQL لبطاقة شبكيّة معيّنة -لنفترض أنّك تملك بطاقة شبكيّة خاصة باسم eth1-:

sudo iptables -A INPUT -i eth1 -p tcp --dport 3306 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
sudo iptables -A OUTPUT -o eth1 -p tcp --sport 3306 -m conntrack --ctstate ESTABLISHED -j ACCEPT

الأمر الثاني (الذي يسمح بمرور بيانات التراسل الشبكي لاتصالات MySQL المُنشَأة) مطلوبٌ فقط إذا لم تكن سياسة OUTPUT مضبوطةً إلى ACCEPT.

قواعد بيانات PostgreSQL

تستمع PostgreSQL إلى اتصالات العميل على المنفذ 5432 إذا كان سيُستخدَم خادم قواعد بيانات PostgreSQL من عميل على خادومٍ بعيد؛ فتأكد أنك تسمح بمرور تلك البيانات الشبكية.

السماح لاتصالات PostgreSQL الواردة من عنوان IP معين أو شبكة فرعية

للسماح باتصالات PostgreSQL الواردة من عنوان IP معيّن أو شبكة فرعية، فحدِّد المصدر؛ على سبيل المثال، تستطيع تنفيذ هذين الأمرين إذا أردت السماح للشبكة الفرعية 15.15.15.0/24:

sudo iptables -A INPUT -p tcp -s 15.15.15.0/24 --dport 5432 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
sudo iptables -A OUTPUT -p tcp --sport 5432 -m conntrack --ctstate ESTABLISHED -j ACCEPT

الأمر الثاني (الذي يسمح بمرور بيانات التراسل الشبكي لاتصالات PostgreSQL المُنشَأة) مطلوبٌ فقط إذا لم تكن سياسة OUTPUT مضبوطةً إلى ACCEPT.

السماح لاتصالات PostgreSQL الواردة إلى بطاقة شبكية معينة

استخدم الأمر الآتي للسماح لاتصالات PostgreSQL لبطاقة شبكيّة معيّنة -لنفترض أنّك تملك بطاقة شبكيّة خاصة باسم eth1:

sudo iptables -A INPUT -i eth1 -p tcp --dport 5432 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
sudo iptables -A OUTPUT -o eth1 -p tcp --sport 5432 -m conntrack --ctstate ESTABLISHED -j ACCEPT

الأمر الثاني (الذي يسمح بمرور بيانات التراسل الشبكي لاتصالات PostgreSQL المُنشَأة) مطلوبٌ فقط إذا لم تكن سياسة OUTPUT مضبوطةً إلى ACCEPT.

خدمة البريد

تستمع خوادم البريد مثل Sendmail و Postfix إلى تشكيلة واسعة من المنافذ بناءً على البروتوكولات المستخدمة لتوصيل البريد؛ إذا كنت تُشغِّل خادوم بريدٍ إلكتروني، فحدِّد البروتوكولات التي تستخدمها واسمح للاتصالات الموافقة لها. سنستعرض أيضًا مثالًا عن إنشاء قاعدة لحجب بريد SMTP الصادر.

حجب بريد SMTP الصادر

ربما تريد أن تحجب بريد SMTP الصادر إذا لم يكن من المفترض لخادومك أن يرسل بريدًا إلكترونيًّا؛ استخدم الأمر الآتي لحجب بريد SMTP الصادر (الذي يستخدم المنفذ 25):

sudo iptables -A OUTPUT -p tcp --dport 25 -j REJECT

يضبط الأمر السابق خادومك لتجاهل كل البيانات المُرسَلة على المنفذ 25؛ إذا أردت أن تحجب خدمةً أخرى عبر رقم منفذها، فضع رقم المنفذ الخاص بها بدلًا من 25.

السماح لجميع اتصالات SMTP الواردة

للسماح لخادومك بالرد على اتصالات SMTP على المنفذ 25، فعليك تنفيذ الأمرين الآتيين:

sudo iptables -A INPUT -p tcp --dport 25 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
sudo iptables -A OUTPUT -p tcp --sport 25 -m conntrack --ctstate ESTABLISHED -j ACCEPT

الأمر الثاني (الذي يسمح بمرور بيانات التراسل الشبكي لاتصالات SMTP المُنشَأة) مطلوبٌ فقط إذا لم تكن سياسة OUTPUT مضبوطةً إلى ACCEPT.

ملاحظة: من الشائع لخوادم SMTP أن تستخدم المنفذ 587 للبريد الصادر.

السماح لجميع اتصالات IMAP الواردة

للسماح لخادومك بالرد على اتصالات IMAP على المنفذ 143، فعليك تنفيذ الأمرين الآتيين:

sudo iptables -A INPUT -p tcp --dport 143 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
sudo iptables -A OUTPUT -p tcp --sport 143 -m conntrack --ctstate ESTABLISHED -j ACCEPT

الأمر الثاني (الذي يسمح بمرور بيانات التراسل الشبكي لاتصالات IMAP المُنشَأة) مطلوبٌ فقط إذا لم تكن سياسة OUTPUT مضبوطةً إلى ACCEPT.

السماح لجميع اتصالات IMAPS الواردة

للسماح لخادومك بالرد على اتصالات IMAPS على المنفذ 993، فعليك تنفيذ الأمرين الآتيين:

sudo iptables -A INPUT -p tcp --dport 993 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
sudo iptables -A OUTPUT -p tcp --sport 993 -m conntrack --ctstate ESTABLISHED -j ACCEPT

الأمر الثاني (الذي يسمح بمرور بيانات التراسل الشبكي لاتصالات IMAPS المُنشَأة) مطلوبٌ فقط إذا لم تكن سياسة OUTPUT مضبوطةً إلى ACCEPT.

السماح لجميع اتصالات POP3 الواردة

للسماح لخادومك بالرد على اتصالات POP3 على المنفذ 110، فعليك تنفيذ الأمرين الآتيين:

sudo iptables -A INPUT -i -p tcp --dport 110 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
sudo iptables -A OUTPUT -p tcp --sport 110 -m conntrack --ctstate ESTABLISHED -j ACCEPT

الأمر الثاني (الذي يسمح بمرور بيانات التراسل الشبكي لاتصالات POP3 المُنشَأة) مطلوبٌ فقط إذا لم تكن سياسة OUTPUT مضبوطةً إلى ACCEPT.

السماح لجميع اتصالات POP3S الواردة

للسماح لخادومك بالرد على اتصالات POP3S على المنفذ 995، فعليك تنفيذ الأمرين الآتيين:

sudo iptables -A INPUT -p tcp --dport 995 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
sudo iptables -A OUTPUT -p tcp --sport 995 -m conntrack --ctstate ESTABLISHED -j ACCEPT

الأمر الثاني (الذي يسمح بمرور بيانات التراسل الشبكي لاتصالات POP3S المُنشَأة) مطلوبٌ فقط إذا لم تكن سياسة OUTPUT مضبوطةً إلى ACCEPT.

الخلاصة

يجب أن يكون قد غطى هذا الدرس الكثير من الأوامر شائعة الاستخدام عند استعمال iptables لضبط الجدار الناري؛ وبالطبع iptables هو أداةٌ مرنةٌ جدًا، لذلك تستطيع دمج مختلف الخيارات مع الأوامر السابقة لملائمة متطلبات خادومك إن لم تكن تلك الأوامر مبيّنةً هنا.

ترجمة -وبتصرف- للمقال: Iptables Essentials: Common Firewall Rules and Commands لصاحبه: Mitchell Anicas.

نشر مختلف مكونات تطبيقك على عدِّة عقد (nodes) هو طريقةٌ شائعةٌ لتخفيف الحِمل (load) والبدء في التوسع أفقيًا (scaling horizontally)؛ مثالٌ اعتياديٌ عن ذلك هو ضبط قاعدة بيانات على خادوم منفصل عن تطبيقك؛ وعلى الرغم من العدد الكبير من المحاسن الناتجة عن هذا الإعداد، لكن الاتصال عبر الشبكة ينضوي على مخاطر أمنية.

سنشرح في هذا الدرس كيف نعد جدار ناري بسيط على كل خادوم من خواديمك عند استخدامك للضبط الموزَّع (distributed setup)؛ سنضبط السياسة لكي تسمح بمرور البيانات بين المكونات (components)، وتمنع في الوقت ذاته مرور أيّة بيانات أخرى.

سنستخدم في هذا الدليل خادومَي أوبنتو 14.04؛ واحدٌ سيحتوي على نسخة من وردبريس مُخدَّمة بوساطة nginx، والآخر يستضيف قاعدة بيانات MySQL للتطبيق. وعلى الرغم من أننا سنستخدم هذا الإعداد كمثال، لكنك تستطيع تعديل التقنيات التي سنستخدمها لكي تلائم متطلبات خادومك.

المتطلبات المسبقة

للبدء، عليك أن تحصل على خادومَي Ubuntu؛ وتضيف مستخدمًا عاديًا بامتيازات الجذر عبر الأمر sudo على كلي الخادومَين؛ يمكنك اتباع درس الضبط المبدئي لخادوم أوبنتو 14.04 لكي تتعلم كيف تفعل ذلك بشكلٍ صحيح.

ضبط جدار ناري بسيط

سنبدأ بضبط أساسي للجدار الناري على كل خادوم من خواديمنا. السياسة التي سنتبعها تأخذ منحى «الأمان أولًا»، أي أننا سنمنع كل شيء عدا بيانات التراسل التابعة لخدمة SSH ثم سنفتح «فجوات» في الجدار الناري خاصة بتطبيقنا.

يوفر الجدار الناري المضبوط في هذا الدرس إعدادًا أساسيًا لما سنحتاج؛ ثبِّت الحزمة iptables-persistent ثم الصق القواعد الأساسية في ملف ‎/etc/iptables/rules.v4:

sudo apt-get update
sudo apt-get install iptables-persistent
sudo nano /etc/iptables/rules.v4

محتويات الملف: etc/iptables/rules.v4/

*filter
# Allow all outgoing, but drop incoming and forwarding packets by default
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]

# Custom per-protocol chains
:UDP - [0:0]
:TCP - [0:0]
:ICMP - [0:0]

# Acceptable UDP traffic

# Acceptable TCP traffic
-A TCP -p tcp --dport 22 -j ACCEPT

# Acceptable ICMP traffic

# Boilerplate acceptance policy
-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A INPUT -i lo -j ACCEPT

# Drop invalid packets
-A INPUT -m conntrack --ctstate INVALID -j DROP

# Pass traffic to protocol-specific chains
## Only allow new connections (established and related should already be handled)
## For TCP, additionally only allow new SYN packets since that is the only valid
## method for establishing a new TCP connection
-A INPUT -p udp -m conntrack --ctstate NEW -j UDP
-A INPUT -p tcp --syn -m conntrack --ctstate NEW -j TCP
-A INPUT -p icmp -m conntrack --ctstate NEW -j ICMP

# Reject anything that's fallen through to this point
## Try to be protocol-specific w/ rejection message
-A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable
-A INPUT -p tcp -j REJECT --reject-with tcp-reset
-A INPUT -j REJECT --reject-with icmp-proto-unreachable

# Commit the changes
COMMIT

*raw
:PREROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT

*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT

*security
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT

*mangle
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT

إذا كنتَ تجري هذه التعديلات على «بيئة حيّة» فلا تعيد تحميل قواعد الجدار الناري! تحميل القواعد الأساسية المذكورة هنا سيؤدي مباشرةً إلى قطع الاتصال بين تطبيقك وخادوم قواعد البيانات؛ سنحتاج إلى تعديل القواعد لكي تعكس احتياجاتنا لكي يعمل التطبيق قبل إعادة التحميل.

معرفة المنافذ التي تستخدمها الخدمات التي تشغلها

لكي نستطيع إضافة استثناءات للسماح بالاتصالات بين مختلف مكونات التطبيق، فسنحتاج إلى معرفة المنافذ الشبكية المُستخدَمة؛ يمكنك معرفة المنافذ الشبكية الصحيحة بتفحص ملفات الضبط، لكن طريقة اكتشاف المنافذ غير مرتبطة بالتطبيقات هي التحقق من الخدمات التي «تستمع» إلى الاتصالات على كل جهاز.

يمكننا استخدام الأداة netstat لمعرفة ذلك؛ ولمّا كان تطبيقنا يتواصل عبر IPv4 فقط، فسنضيف الوسيط ‎-4 لكنك تستطيع إزالته إذا كنت تستخدم IPv6 أيضًا؛ الوسائط الأخرى اللازمة لمعرفة الخدمات التي تعمل هي ‎-plunt.

على خادوم الويب، سنرى شيئًا شبيهًا بما يلي:

sudo netstat -4plunt

الناتج:

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 1058/sshd
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 4187/nginx

يُظهِر أول عمود عنوان IP والمنفذ للخدمة التي تستمع إليه (الموجود اسمها في آخر السطر)؛ عنوان 0.0.0.0 الخاص يعني أن الخدمة المعنية تستمع إلى جميع العناوين المتاحة (جميع البطاقات الشبكية).
وعلى خادوم قواعد البيانات، يجب أن نشاهد شيئًا شبيهًا بما يلي:

sudo netstat -4plunt

الناتج:

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      1097/sshd
tcp        0      0 192.0.2.30:3306         0.0.0.0:*               LISTEN      3112/mysqld

يمكنك قراءة الأعمدة السابقة بنفس الطريقة. يمثّل عنوان 192.0.2.30 في المثال السابق عنوان IP الخاص لخادوم قواعد البيانات؛ وعند إعداد التطبيق، لقد حصرنا استخدام MySQL إلى البطاقة الخاصة فقط لأسبابٍ أمنية.

الحظ القيم التي ستجدها في هذه الخطوة، هذه هي التفاصيل الشبكية التي سنحتاج لها لكي نعدِّل ضبطنا للجدار الناري.

في مثالنا التوضيحي، سنلاحظ أنه علينا التأكد من أن هذه المنافذ متاحة على خادوم الويب:

• المنفذ 80 على جميع العناوين
• المنفذ 22 على جميع العناوين (وذلك موجودٌ في قواعد الجدار الناري)

وعلينا التأكد من أن هذه المنافذ متاحةٌ على خادوم قواعد البيانات:

• المنفذ 3306 على العنوان 192.0.2.30 (أو البطاقة الشبكية المرتبطة معه)
• المنفذ 22 على جميع العناوين (وذلك موجودٌ في قواعد الجدار الناري)

تعديل قواعد الجدار الناري لخادوم الويب

لدينا الآن معلومات المنافذ التي نحتاج إليها لتعديل مجموعة قواعد الجدار الناري لخادوم الويب الخاص بنا؛ افتح ملف القواعد في محررك النصي بامتيازات الجذر (عبر sudo):

sudo nano /etc/iptables/rules.v4

سنحتاج إلى السماح بمرور بيانات التراسل الشبكي على المنفذ 80 في خادوم الويب؛ ولمّا كان الخادوم يستمع إلى الاتصالات على جميع العناوين المتوفرة، فإننا لن نقيّد القاعدة ببطاقة شبكية أو عنوان معيّن.

سيستخدم زوار موقعنا بروتوكول TCP للاتصال؛ إطار العمل الذي أنشأناه لجدارنا الناري فيه سلسلة خاصة باسم TCP لوضع استثناءات لتطبيقات TCP؛ يمكننا إضافة المنفذ 80 إلى السلسلة، مباشرةً بعد الاستثناء الخاص بمنفذ SSH:

/etc/iptables/rules.v4

*filter
. . .

# Acceptable TCP traffic
-A TCP -p tcp --dport 22 -j ACCEPT
-A TCP -p tcp --dport 80 -j ACCEPT

. . .

سيبدأ خادوم الويب اتصالًا مع خادوم قواعد البيانات؛ ليست الاتصالات الشبكية الخارجة من خادومنا مقيدةً في جدارنا الناري ويُسمَح للاتصالات الواردة المرتبطة مع اتصالات مُنشَأة مسبقًا، لذلك لن نحتاج إلى فتح أيّة منافذ إضافية في هذا الخادوم للسماح بهذا الاتصال.

احفظ وأغلق الملف عندما تنتهي من تعديله، يجب أن يملك خادوم الويب الآن سياسة جدارٍ ناريٍ تسمح بمرور البيانات الشرعية وتحجب في الوقت نفسه أي شيءٍ آخر.

اختبر ملف القواعد للكشف عن الأخطاء البنيوية (syntax errors):

sudo iptables-restore -t < /etc/iptables/rules.v4

إذا لم تظهر أيّة أخطاء، فأعد تحميل الجدار الناري لتطبيق مجموعة القواعد الجديدة:

sudo service iptables-persistent reload

تعديل قواعد الجدار الناري لخادوم قواعد البيانات

يجب علينا السماح بالوصول إلى المنفذ 3306 على عنوان IP الخاص بخادوم قواعد البيانات، الذي هو 192.0.2.30، يمكننا وضع قيود على الوصول لهذا العنوان تحديدًا، أو يمكننا وضع القيود للبيانات القادمة إلى البطاقة الشبكية المرتبطة مع هذا العنوان.

لمعرفة البطاقة الشبكية المرتبطة مع هذا العنوان، فنفِّذ الأمر:

ip -4 addr show scope global

الناتج:

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
inet 203.0.113.5/24 brd 104.236.113.255 scope global eth0
   valid_lft forever preferred_lft forever
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
inet 192.0.2.30/24 brd 192.0.2.255 scope global eth1
   valid_lft forever preferred_lft forever

ما سبق يظهر أنّ البطاقة eth1 هي البطاقة الشبكيّة المرتبطة مع ذاك العنوان.

ومن ثم علينا أن نعدِّل قواعد الجدار الناري في خادوم قواعد البيانات. افتح ملف القواعد بامتيازات الجذر (عبر sudo) في خادوم قواعد البيانات:

sudo nano /etc/iptables/rules.v4

مرةً أخرى، سنضيف قاعدةً إلى سلسلة TCP لتشكيل استثناء للاتصال بين خادومَي الويب وقواعد البيانات.

إذا أردت تقييد الوصول بناءً على العنوان، فيمكنك إضافة قاعدة مثل هذه:

/etc/iptables/rules.v4

 *filter
. . .

# Acceptable TCP traffic
-A TCP -p tcp --dport 22 -j ACCEPT
-A TCP -p tcp --dport 3306 -d 192.0.2.30 -j ACCEPT

. . .

إذا كنت تفضِّل أن تسمح بالاستثناء بناءً على البطاقة الشبكية التي تستضيف العنوان، فيمكنك إضافة قاعدة شبيهة بالقاعدة السابقة بدلًا منها:

/etc/iptables/rules.v4

*filter
. . .

# Acceptable TCP traffic
-A TCP -p tcp --dport 22 -j ACCEPT
-A TCP -p tcp --dport 3306 -i eth1 -j ACCEPT

. . .

احفظ وأغلق الملف عندما تنتهي من تعديله.

اختبر ملف القواعد للكشف عن الأخطاء البنيوية:

sudo iptables-restore -t < /etc/iptables/rules.v4

عندما تكون جاهزًا، فأعد تحميل قواعد الجدار الناري:

sudo service iptables-persistent reload

يجب أن يكون كلا الخادومَين محميًا الآن دون تقييد تدفق البيانات بينهما.

الخلاصة

يجب أن يكون إعداد جدارٍ ناريٍ سليم جزءًا من خطة نشر التطبيق؛ وعلى الرغم من أننا شرحنا هذا الضبط مستخدمين خادومَين يشغِّلان Nginx وMySQL لكي تعمل نسخة من وردبريس، لكن التقنيات المشروحة في هذا الدرس قابلةٌ للتطبيق بغض النظر عن الخدمات المُشغَّلة.

ترجمة -وبتصرف- للمقال: How To Set Up an Iptables Firewall to Protect Traffic Between your Servers لصاحبه: Justin Ellingwood.

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

يناقش هذا الدّرس كيف تعمل الجدر النارية، مع التركيز على برمجيات الجدر النارية «ذات الحالة» (stateful)، مثل iptable و FirewallD، لأنها تتعلق بالخواديم السحابية؛ سنبدأ بشرح موجز عن رزم TCP الشبكية والأنواع المختلفة للجدر النارية، ثم سنناقش تنوع المواضيع التي تتعلق بالجدر النارية ذات الحالة؛ في النهاية، سنوفر روابط لمقالاتٍ أخرى ستساعدك في إعداد جدار ناري على خادومك.

رزم TCP الشبكية

قبل نقاش مختلف أنواع الجدر النارية، لنأخذ نظرةً سريعةً على شكل بيانات التراسل الشبكي لبروتوكول التحكم في النقل (Transport Control Protocol اختصارًا TCP).

تنتقل بيانات TCP الشبكية عبر الشبكة في «رزم» (packets)، التي تمثِّل حاويات تتألف من ترويسة الرزمة (packet header) –التي تحتوي على معلومات التحكم مثل عناوين المصدر والوجهة، ومعلومات تسلسل الرزم– والبيانات (التي تعرف أيضًا بالمصطلح «الحمولة» [payload])؛ وبينما تساعد بيانات التحكم في كل رزمة على التأكد من أن البيانات المرتبطة معها ستصل وصولًا صحيحًا، لكن العناصر التي تحتويها تُوفِّر للجدر النارية طرقًا مختلفة لمطابقة الرزم الشبكية على قواعد الجدار الناري.

من المهم الملاحظة أنه من الضروري لاستقبال صحيح لرزم TCP قادمة أن يُرسِل المُستقبِل رزمًا تحتوي على إشعار بالاستلام إلى المُرسِل؛ يمكن أن يستخدم دمج معلومات التحكم في الرزم المُستقبَلة والمُرسَلة لتحديد حالة الاتصال (مثلًا، جديد [new]، مُنشَأ [established]، متعلق [related]) بين المُرسِل والمُستقبِل.

دورة علوم الحاسوب

دورة تدريبية متكاملة تضعك على بوابة الاحتراف في تعلم أساسيات البرمجة وعلوم الحاسوب

اشترك الآن

أنواع الجدر النارية

لنناقش بسرعة الأنواع الثلاثة الأساسية للجدر النارية للشبكة: ترشيح الرزم (packet filtering) أو عديمة الحالة [stateless])، ذات الحالة (stateful)، وطبقة التطبيقات (application layer).

• ترشيح الرزم، أو الجدر عديمة الحالة، تعمل عبر تفصّح كل الرزم الشبكية على حدة؛ وبالتالي، ستكون غير مدركة لحالة الاتصال ويمكنها فقط أن تسمح أو تمنع مرور الرزم بناءً على ترويسات كل رزمة بشكل منفرد.
• الجدر ذات الحالة قادرة على تحديد حالة الاتصال للرزم، مما يجعل تلك الجدر أكثر مرونةً من الجدر عديمة الحالة. إنها تعمل عبر جمع الرزم الشبكية المترابطة إلى أن تستطيع تحديد حالة الاتصال قبل أن تطبَّق أيّة قواعد للجدار الناري على بيانات التراسل الشبكي.
• جدر التطبيقات (Application firewalls) تذهب خطوةً إضافيةً إلى الأمام عبر تحليل البيانات التي قد أُرسِلَت، مما يسمح بمطابقة بيانات التراسل الشبكي على قواعد الجدار الناري التي تكون مخصصة لخدمات أو تطبيقات معينة. تسمى هذه الجدر أيضًا باسم «الجدر النارية الوسيطة» (proxy-based firewalls).

بالإضافة إلى برمجية الجدار الناري، المتوفرة في جميع أنظمة التشغيل الحديثة، يمكن توفير وظيفة الجدار الناري عبر أجهزة عتادية، مثل الموجهات (routers) أو أجهزة جدر نارية خاصة. مرةً أخرى، سنركِّز في نقاشنا على الجدر النارية ذات الحالة التي تعمل على الخواديم التي عليها حمايتها.

قواعد الجدار الناري

كما ذُكِر في الأعلى، البيانات الشبكية التي تعبر جدارًا ناريًا ستُطابَق على قواعدٍ لتحديد إذا كان يُسمَح لها بالمرور أم لا؛ طريقة سهلة لشرح كيف تبدو قواعد الجدار الناري هي عرض بعض الأمثلة، لنفعل ذلك الآن.

لنفترض أن لديك خادومًا بهذه القائمة من قواعد الجدار الناري التي تنطبق على البيانات القادمة:

1. السماح للبيانات الشبكية القادمة من اتصالات جديدة أو مُنشَأة مسبقًا إلى البطاقة الشبكية العامة على المنفذين 80 و 443 (بيانات HTTP و HTTPS للويب).
2. تجاهل البيانات القادمة من عناوين IP للموظفين غير التقنيين في مكتبك إلى المنفذ 22 (خدمة SSH).
3. السماح للبيانات الشبكية القادمة من اتصالات جديدة أو مُنشَأة مسبقًا من مجال عناوين IP لمكتبك إلى البطاقة الشبكية الخاصة على المنفذ 22 (خدمة SSH).

الحظ أنَّ أول كلمة في كل مثال من الأمثلة الثلاثة السابقة هي إما كلمة «السماح» (accept) أو «رفض» (reject) أو «تجاهل» (drop). هذا يُحدِّد ما سيفعله الجدار الناري في حال طابقت البيانات الشبكية تلك القاعدة. «السماح» تعني أنه يمكن للبيانات الشبكية المرور، و«الرفض» تعني منع مرور البيانات الشبكية ولكن إرسال خطأ «unreachable»، بينما «التجاهل» تعني منع مرور البيانات الشبكية وعدم إرسال رد؛ يحتوي ما تبقى من كل قاعدة على الشرط الذي يجب أن تُطابَق عليه كل رزمة شبكية.

وكما يبدو، فإن البيانات الشبكية ستُطابَق على قائمة بقواعد الجدار الناري بتسلسل (chain) من أول قاعدة إلى آخر قاعدة. وخصوصًا عندما تُطابَق قاعدة، فسينفَّذ الحدث المُطابِق لها على البيانات الشبكية؛ في مثالنا السابق، إذا حاول محاسب في المكتب إنشاء اتصال SSH إلى الخادوم، فسيُرفَض اتصاله بناءً على القاعدة رقم 2، حتى قبل التحقق من القاعدة رقم 3؛ لكن مديرًا للنظام سيتمكَّن من إنشاء الاتصال لأنه سيُطابِق القاعدة رقم 3 فقط.

السياسة الافتراضية (Default Policy)

من الطبيعي لسلسلة من قواعد الجدار الناري ألا تغطي بدقة كل حالة ممكنة؛ فلهذا السبب، يجب تحديد سياسة افتراضية لسلاسل قواعد الجدار الناري، التي تحتوي على ما سيُفعَل بالبيانات الشبكية فقط (قبول، أو رفض، أو تجاهل).

افترض أننا ضبطنا السياسة الافتراضية للمثال السابق إلى «تجاهل»؛ فإذا حاول حاسوب خارج مكتبك إنشاء اتصال SSH إلى خادومك، فسيتم تجاهل البيانات الشبكية التي أرسلها لأنها لا تطابق أيّ من القواعد السابقة.

أما لو ضُبِطَت السياسة الافتراضية إلى «السماح»، فإن أي شخص –ما عدا موظفي المكتب غير التقنيين– سيتمكن من إنشاء اتصال لأي خدمة مفتوحة على خادومك؛ هذا مثالٌ عن أن جدارًا ناريًا مضبوطٌ ضبطًا سيئًا سيمنع جزءًا من الموظفين فقط.

البيانات الشبكية الداخلة والخارجة

لمّا كانت تُفصَل البيانات الشبكية –من وجهة نظر الخادوم– إلى بيانات داخلة أو خارجة، فإن الجدار الناري يبقي مجموعةً منفصلةً من القواعد لكل حالة؛ البيانات التي أصلها من مكانٍ آخر –أي البيانات الداخلة– تُعامَل معاملةً مختلفةً عن البيانات الخارجة من الخادوم؛ من الطبيعي أن يسمح الخادوم بأغلبية البيانات الخارجة لأن الخادوم عادةً «يثق بنفسه». ومع ذلك، يمكن استخدام مجموعة قواعد للبيانات الخارجة لمنع الاتصالات غير المرغوبة في حال أُخترِق الخادوم من مهاجم أو عبر ملف تنفيذي خبيث.

لكي نعظِّم الاستفادة الأمنية من الجدار الناري، فيجب عليك تحديد جميع الطرق التي تريد للأنظمة الأخرى أن تتعامل مع خادومك فيها؛ وذلك بإنشاء قواعد تسمع لتلك الحالات بدقة، ثم تتجاهل بقية البيانات الشبكية. أبقِ في بالك أنَّ قواعد البيانات الخارجة يجب أن تكون صحيحة للسماح للخادوم بإرسال إشعارات استلام لأي اتصالات داخلة مسموحٌ لها؛ تذكر أيضًا أنه ولما كان على الخادوم أن يبدأ اتصالات شبكية خاصة به لمختلف الأسباب (مثل تنزيل التحديثات، أو الاتصال إلى قاعدة بيانات)، فمن الضروري تضمين تلك الحالات في مجموعة القواعد للبيانات الخارجة.

كتابة قواعد البيانات الخارجة

افترض أن مثالنا عن الجدار الناري مضبوط لتجاهل البيانات الشبكية الخارجة افتراضيًا، هذا يعني أنَّ قواعد السماح للبيانات الداخلة ستكون عديمة الفائدة دون قواعد البيانات الشبكية الخارجة المُكمِّلة لها.

لملائمة المثال عن قواعد البيانات الداخلة في الجدار الناري (القاعدتين 1 و 3)، من قسم «قواعد الجدار الناري» السابق، وللسماح بالاتصالات الملائمة بناءً على هذه العناوين والمنافذ؛ فعلينا استخدام هذه القواعد للاتصالات الخارجة:

1. السماح بالبيانات الشبكية الخارجة المُنشَأة على البطاقة الشبكية العامة على المنفذ 80 و 443 (HTTP و HTTPS).
2. السماح بالبيانات الشبكية الخارجة المُنشَأة على البطاقة الشبكية الخاصة على المنفذ 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.

بالرّغم من أنّ الاتصال إلى الخادوم عبر SSH آمن جدًّا، فإنّ SSH daemon (وهو عمليّة تعمل في خلفيّة النّظام بشكل دائم) بحدّ ذاتها هي خدمة يجب تعريضها إلى الإنترنت لتعمل بشكل صحيح، ويأتي هذا مع بعض المخاطر الكامنة ويخلق ناقلات للهجوم لأي مهاجمين مُحتَملين.

إنّ أي خدمة مُعرّضة إلى الشّبكة هي هدف مُحتمل بهذه الطريقة، فإذا ألقينا انتباهنا إلى سجلّات التطبيق لهذه الخدمات سنجد محاولات مُنظّمة ومتكرّرة لتسجيل الدخول والتي تُمثّل هجمات بالقوّة القاسية Brute force attacks عن طريق مستخدمين أو روبوتات bots على حدٍّ سواء.

يُمكن الحد من هذه المشكلة عن طريق خدمة تُدعى fail2ban والتي تقوم بإنشاء قواعد تستطيع تبديل إعدادات جدار حماية iptables بناءً على عدد معرّف مُسبقًا من محاولات تسجيل الدخول غير النّاجحة، يسمح هذا لخادومنا بالاستجابة لمحاولات النّفاذ غير الشّرعية من دون أي تدخّل منّا.

سنغطّي في هذا الدّرس كيفيّة تثبيت واستخدام fail2ban على خادوم Ubuntu.

تثبيت Fail2Ban على Ubuntu

إنّ عمليّة التثبيت لهذه الأداة بسيطة لأنّ فريق تحزيم Ubuntu يُحافِظ على الحِزمة Package في المستودعات الافتراضيّة default repositories.

نحتاج في البداية لتحديث دليل الحِزَم المحلّي local package index لدينا، وبعدها نستطيع استخدام apt لتنزيل وتثبيت الحِزمة:

sudo apt-get update

sudo apt-get install fail2ban

إنّ عملية التثبيت بديهيّة كما نرى، نستطيع الآن البدء بإعداد الأداة لاستخدامنا الشّخصي.

إعداد Fail2Ban مع إعدادات الخدمة الخاصة بنا

تحتفظ خدمة fail2ban بملفّات إعداداتها في الدّليل etc/fail2ban/، يوجد ملف مع إعدادات افتراضيّة يُدعى jail.conf.

ولأنّه يُمكن أن يتم تعديل هذا الملف عن طريق ترقية الحِزَم لذلك لا ينبغي علينا تحرير هذا الملف في مكانه، بل من الأفضل أن نقوم بنسخه حتى نستطيع القيام بتغييراتنا بأمان.

نحتاج لنسخه إلى ملف يُدعى jail.local حتى يستطيع fail2ban إيجاده:

sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

حالما يتم نسخ الملف بإمكاننا فتحه للتحرير لنرى كيف يعمل كل شيء:

sudo nano /etc/fail2ban/jail.local

يوجد في هذا الملف القليل من الإعدادات التي قد نرغب بضبطها، يتم تطبيق هذه الإعدادات الموجودة تحت قسم [DEFAULT] على جميع الخدمات المُمَكَّنة enabled من أجل fail2ban الذي لا يتم تجاوزه في القسم الخاص بالخدمة:

ignoreip = 127.0.0.1/8

نستطيع ضبط مصدر العناوين التي يتجاهلها fail2ban عن طريق إضافة قيمة إلى المُعامِل parameter ignoreip.

يتم ضبطه افتراضيًّا بأن لا يقوم بمنع أي نقل للبيانات traffic قادم من الجهاز المحلّي، نستطيع إضافة المزيد من العناوين التي نريد تجاهلها عن طريق إلحاقها بنهاية هذا المُعامِل مع الفصل بينها بفراغ Space.

bantime = 600

يقوم المُعامِل bantime بتعيين المُدّة الزمنيّة التي سيتم خلالها حظر العميل عندما يفشل بالاستيثاق authenticate بشكلٍ صحيح، يتم قياس هذا المُعامِل بالثّواني، وقيمته الافتراضيّة هي 600 ثانية أي 10 دقائق.

findtime = 600

maxretry = 3

ومن المُعامِلات التي نرغب أن نلقي لها انتباهًا نجد المُعامِلَين findtime و maxretry، وهما يعملان معًا لتأسيس الشّروط التي نستطيع بناءً عليها اعتبار عميل ما مستخدمًا غير قانونيٍ يجب علينا حظره.

يقوم المُتغيّر maxretry بتعيين عدد المحاولات التي يجب خلالها أن يقوم العميل بالاستيثاق خلال فترة زمنيّة مُعرّفة بـ findtime وذلك قبل أن يتمّ حظره، تقوم الإعدادات الافتراضيّة لخدمة fail2ban بحظر العميل الذي يقوم بثلاث محاولات غير ناجحة لتسجيل الدخول خلال فترة 10 دقائق.

destemail = root@localhost

sendername = Fail2Ban

mta = sendmail

ومن بعض الإعدادات الأخرى التي قد نرغب بتعديلها نجد الإعدادات destemail، sendername، و mta إن أردنا ضبط تنبيهات alerts البريد الإلكتروني، يقوم المُعامِل destemail بتعيين عنوان البريد الإلكتروني الذي سيستقبل رسائل الحظر، يقوم المُعامِل sendername بتعيين قيمة الحقل From في البريد الإلكتروني، يُحدّد المُعامِل mta خدمة البريد الإلكتروني التي سيتم استخدامها لإرسال البريد.

action = $(action_)s

يضبط هذا المُعامل الإجراءات التي يتّخذها fail2ban عندما يريد إقامة حظر، إنّ القيمة _action مُعرَّفة في الملف قبل هذا المُعامِل بقليل، الإجراء الافتراضي هو ببساطة أن يتم ضبط الجّدار النّاري firewall لكي يرفض نقل البيانات من المُضيف Host المُهاجِم حتى تنتهي مُدّة الحظر.

إن أردنا ضبط تنبيهات البريد الإلكتروني نستطيع تغيير القيمة من _action إلى action_mw، وإن كُنّا نرغب أن يقوم البريد الإلكتروني بتضمين سطور السّجلات المُتعلّقة بذلك نستطيع تغييرها إلى action_mwl، يجب أن نتأكّد من أنّه يتم ضبط إعدادات البريد المُناسبة إن اخترنا استخدام تنبيهات البريد.

1. إعدادات Jail الفردية

لقد وصلنا أخيرًا إلى الجزء من ملف الإعدادات الذي يتعامل مع الخدمات الفرديّة، والتي يتم تحديدها في القسم headers مثل [SSH].

نستطيع تمكين كل واحد من هذه الأقسام عن طريق تعديل أو إضافة السّطر enabled وتعيينه إلى true:

enabled = true

نجد بشكل افتراضي أنّ خدمة SSH مُمكّنة وباقي الخدمات مُعطّلة.

تعمل هذه الأقسام عن طريق استخدام القيم الافتراضيّة التي عرّفناها مُسبقًا، وإن أردنا تجاوز override أي قيم نستطيع فعل ذلك في قسم الخدمات، أمّا إن أردنا استخدام القيم الافتراضيّة فلا داعي لإضافة أي شيء.

ومن الإعدادات الأخرى التي يُمكن تعيينها هنا هي filter والذي يستخدم ليحدّد إذا ما كان السطر في ملف السّجل يشير إلى استيثاق فاشل، وlogpath الذي يُخبِر fail2ban أين توجد السّجلات لتلك الخدمة بالتحديد.

إنّ قيمة filter هي في الواقع إشارة reference إلى ملف يتوضّع في الدّليل etc/fail2ban/filter.d/ مع إزالة لاحقته conf.، يحتوي هذا الملف على التّعابير النمطيّة regular expressions التي تُحدّد إذا ما كان السّطر في ملف السّجل سيّئًا، لن نقوم بالتّحدث بالتفصيل عن هذا الملف في هذا الدّرس، لأنّه مُعقّد إلى حدٍ ما، والإعدادات المُعرّفة مُسبقًا تتوافق مع السطور المُلائمة لها بشكل جيّد.

بإمكاننا على أيّة حال أن نرى أنواع المُرشّحات filters المتوفرة من خلال النّظر إلى هذا الدّليل:

ls /etc/fail2ban/filter.d

عندما نجد ملفًّا مرتبطًا بالخدمة التي نستخدمها ينبغي أن نفتحه باستخدام مُحرّر نصوص.

مُعظم هذه الملفّات تحتوي على تعليقات للشرح بشكل جيّد ويجب أن نكون قادرين على الأقل أن نعرف ما هو نوع الشّروط التي تم تصميم الـ script من أجل الحماية ضدّها، تملك أغلب هذه المُرشّحات أقسام (مُعطّلة) مناسبة في ملف jail.local والتي نستطيع تمكينها عند الرغبة بذلك.

فلنفترض على سبيل المثال أنّنا نقوم بتخديم موقع باستخدام nginx وأدركنا أنّ قسم منه محمي بكلمة مرور يتعرّض لمحاولات تسجيل دخول، نستطيع إخبار fail2ban أن يستخدم الملف nginx-http-auth.conf لكي يفحص هذا الشّرط من خلال الملف var/log/nginx/error.log/.

هذا الشّرط مُعَد مُسبقًا في الواقع ضمن قسم يُدعى [nginx-http-auth] في الملف etc/fail2ban/jail.local/، نحتاج فقط إلى قلب المُعامِل enabled إلى true لحماية الخدمة الخاصّة بنا:

[nginx-http-auth]

enabled = true

filter = nginx-http-auth

port = http,https

logpath = /var/log/nginx/error.log

إن قمنا بتفعيلها نحتاج إلى إعادة تشغيل خدمة fail2ban للتأكّد من أنّ قواعدنا مبنيّة بشكل صحيح.

وضع كل ذلك معا

الآن وقد فهمنا الفكرة الأساسيّة من وراء fail2ban، فلنقم بتشغيل إعداد أساسي.

سنقوم بإعداد سياسة حظر تلقائي من أجل SSH وNginx تمامًا كما وصفنا سابقًا، نريد من fail2ban أن يقوم بإرسال بريد إلكتروني لنا عندما يتم حظر عنوان IP.

فلنقم في البداية بتثبيت جميع البرمجيّات المتعلقّة بذلك.

إن كُنّا لا نملك nginx يجب علينا تثبيته، لأنّنا سنقوم بمراقبة سجلّاته، سنحتاج أيضًا sendmail لكي يرسل التّنبيهات إلينا، سنقوم بتثبيت iptables-persistent لكي يسمح للخادوم بإعداد قواعد الجّدار النّاري تلقائيًّا عند الإقلاع boot، نستطيع الحصول على كل هذا من مستودعات Ubuntu الافتراضيّة:

sudo apt-get update

sudo apt-get install nginx sendmail iptables-persistent

1. إنشاء جدار ناري أساسي

ينبغي علينا بعد الانتهاء من كل هذا إنشاء جدار ناري افتراضي، تستطيع تعلّم كيفيّة إعداد iptables للجدار الناري على Ubuntu من هنا، سنقوم في هذا الدّرس فقط بإنشاء جدار ناري أساسي.

سنخبر الجّدار النّاري بالسّماح للاتصالات التي تمّ تأسيسها، نقل البيانات traffic الذي يتم توليده من قبل الخادوم نفسه، مقدار نقل البيانات من أجل SSH لدينا، ومنافذ ports خادوم الوِب، وسنقوم باستبعاد أي نقل بيانات آخر، نستطيع إعداد هذا الجّدار النّاري الأساسي عن طريق كتابة:

sudo iptables -A INPUT -i lo -j ACCEPT

sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT

sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT

sudo iptables -A INPUT -j DROP

ستقوم هذه الأوامر بتنفيذ السّياسة السّابقة، وبإمكاننا رؤية قواعد الجّدار النّاري الحاليّة عن طريق كتابة:

sudo iptables -S

-P INPUT ACCEPT

-P FORWARD ACCEPT

-P OUTPUT ACCEPT

-N fail2ban-ssh

-A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh

-A INPUT -i lo -j ACCEPT

-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT

-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT

-A INPUT -j DROP

-A fail2ban-ssh -j RETURN

حصلنا هنا على سياستنا الافتراضيّة لكل واحدة من السلاسل لدينا، ومن ثمّ القواعد الخمس التي أنشأناها للتو، إنّ الأسطر التي تحتوي على:

-N fail2ban-ssh 

و

-A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh

و

-A fail2ban-ssh -j RETURN 

هي عبارة عن البُنية الافتراضيّة المُعدّة من قبل fail2ban حيث أنّه يقوم مُسبقًا بتنفيذ سياسات حظر SSH بشكل افتراضي.

2. ضبط إعدادات Fail2ban

نحتاج الآن لضبط إعدادات fail2ban باختيار الإعدادات التي نرغب بها، فلنقم بفتح الملف jail.local:

sudo nano /etc/fail2ban/jail.local

نستطيع هنا تعيين زمن للحظر أشد طولًا، فلنقم بتغيير الإعداد bantime الموجود تحت الترويسة الافتراضيّة بحيث تقوم خدمتنا بحظر العملاء لمدة نصف ساعة:

bantime = 1800

نحتاج أيضًا لضبط معلومات تنبيهات البريد الإلكتروني، نقوم في البداية بإيجاد المُعامِل destemail ونضع بداخله عنوان البريد الإلكتروني الذي نرغب باستخدامه لجمع هذه الرسائل:

destemail = admin@example.com

نستطيع تعيين sendername إلى قيمة أخرى إن أردنا ذلك، على الرغم من أنّه من المفيد أن يكون لها قيمة يُمكن تصفيتها بسهولة باستخدام خدمة البريد الإلكتروني الخاصّة بنا، وإلّا امتلأ صندوق الوارد بالتنبيهات إن كانت هناك الكثير من محاولات الاختراق من أماكن متعدّدة.

بالانتقال للأسفل نحتاج لضبط المُعامِل action إلى أحد الإجراءات التي ترسل لنا بريد إلكتروني، الخيارات محصورة بين action_mw والذي يُنشِئ الحظر ومن ثمّ يرسل لنا بريدًا إلكترونيًّا يحتوي على تقرير whois حول المُضيف المخالف، أو action_mwl والذي يقوم بما سبق ولكن يرسل لنا أيضًا سطور السجل المتعلّقة بذلك.

سوف نختار action_mwl لأنّ سطور السّجلات ستساعدنا على استكشاف الأخطاء وجمع المزيد من المعلومات إن كانت توجد مشاكل:

action = %(action_mwl)s

وبالانتقال إلى قسم SSH لدينا، إن أردنا ضبط عدد المحاولات غير الناجحة التي ينبغي أن نسمح بها قبل إنشاء حظر نستطيع تعديل الإدخال maxretry، وإن كُنّا نستخدم منفذ غير 22 سنحتاج لضبط المُعامِل port بشكلٍ مُناسِب، وكما قلنا سابقًا فإنّ هذه الخدمة مُمكّنة مُسبقًا لذلك لا حاجة لتعديل ذلك.

فلنبحث بعد ذلك عن القسم nginx-http-auth ونُغيّر المُعامِل enabled ليصبح true:

[nginx-http-auth]


enabled = true

. . .

هذا هو كل ما ينبغي علينا فعله في هذا القسم ما لم يكن يعمل خادوم الوِب لدينا على منافذ غير معياريّة أو قمنا بنقل المسار الافتراضي لسجلّات الأخطاء.

3. إعادة تشغيل خدمة Fail2ban

بعد الانتهاء مما سبق نقوم بحفظ وإغلاق الملف.

نقوم الآن ببدء تشغيل أو إعادة تشغيل خدمة fail2ban، من الأفضل أحيانًا إيقاف تشغيل الخدمة بشكلٍ تام ومن ثم تشغيلها مرة أخرى:

sudo service fail2ban stop

نستطيع الآن إعادة تشغيلها بكتابة ما يلي:

sudo service fail2ban start

قد تستغرق بضع لحظات لكي يتم ملء جميع قواعد الجّدار النّاري لدينا، على أيّة حال نستطيع بعد ذلك التأكّد من القواعد الجديدة بكتابة:

sudo iptables -S



-P INPUT ACCEPT

-P FORWARD ACCEPT

-P OUTPUT ACCEPT

-N fail2ban-nginx-http-auth

-N fail2ban-ssh

-A INPUT -p tcp -m multiport --dports 80,443 -j fail2ban-nginx-http-auth

-A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh

-A INPUT -i lo -j ACCEPT

-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT

-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT

-A INPUT -j DROP

-A fail2ban-nginx-http-auth -j RETURN

-A fail2ban-ssh -j RETURN

إن الأسطر التي قامت بإنشائها سياسات fail2ban لدينا هي:

• -N fail2ban-nginx-http-auth
  

• -N fail2ban-ssh
  

• -A INPUT -p tcp -m multiport --dports 80,443 -j fail2ban-nginx-http-auth
  

• -A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh
  

• -A fail2ban-nginx-http-auth -j RETURN
  

• -A fail2ban-ssh -j RETURN
  

تقوم هذه الأسطر الآن بتوجيه نقل البيانات إلى سلاسل جديدة وفارغة تقريبًا ومن ثمّ تسمح لنقل البيانات بالتدفق والعودة إلى سلسلة الدّخل INPUT.

على أيّة حال هذه السلاسل الجديدة هي حيث يتم إضافة قواعد الحظر الجّديدة.

4. اختبار سياسات الحظر

نستطيع اختبار القواعد من خادوم آخر -خادوم لا نحتاج له للدخول إلى خادوم fail2ban- عن طريق جعل هذا الخادوم الثاني ينحظر.

بعد الدخول إلى الخادوم الثاني نقوم بمحاولة الدخول عن طريق SSH إلى خادوم fail2ban، نستطيع على سبيل المثال محاولة الاتصال باستخدام اسم غير موجود:

ssh blah@fail2ban_server_IP

فلنقم بإدخال أحرف عشوائيّة في النّافذة التي تطلب منّا كلمة مرور، ومن ثمّ نعيد هذه الخطوة عدّة مرات، سيقوم خادوم fail2ban في نقطة ما بإيقاف الاستجابة مع رسالة تم رفض الإذن Permission denied، وهذا يشير إلى أنه تم حظر الخادوم الثاني من قبل خادوم fail2ban.

نستطيع على خادوم fail2ban مشاهدة القواعد الجديدة عن طريق التّحقق مرة أخرى من iptables لدينا:

sudo iptables -S



-P INPUT ACCEPT

-P FORWARD ACCEPT

-P OUTPUT ACCEPT

-N fail2ban-nginx-http-auth

-N fail2ban-ssh

-A INPUT -p tcp -m multiport --dports 80,443 -j fail2ban-nginx-http-auth

-A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh

-A INPUT -i lo -j ACCEPT

-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT

-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT

-A INPUT -j DROP

-A fail2ban-nginx-http-auth -j RETURN

-A fail2ban-ssh -s 11.111.111.11/32 -j REJECT --reject-with icmp-port-unreachable

-A fail2ban-ssh -j RETURN

وكما نرى في السّطر:

 -A fail2ban-ssh -s 11.111.111.11/32 -j REJECT --reject-with icmp-port-unreachable

نملك الآن قاعدة جديدة في إعداداتنا ترفض نقل البيانات القادمة من عنوان IP خادومنا الثاني عبر منفذ SSH، ينبغي أيضًا أن نكون قد حصلنا على بريد إلكتروني حول هذا الحظر في الحساب الذي قمنا بإعداده.

خاتمة

ينبغي أن نكون قادرين الآن على إعداد بعض سياسات الحظر الأساسيّة لخدماتنا، من السّهل جدًّا إعداد Fail2ban وهو طريقة رائعة لحماية أي نوع من الخدمات تستخدم الاستيثاق.

إن أردت تعلّم المزيد حول كيفيّة عمل fail2ban بإمكانك تفحّص هذا الدّرس التعليمي حول كيفيّة عمل قواعد وملفّات fail2ban.

ترجمة -وبتصرّف- للمقال How To Protect SSH with Fail2Ban on Ubuntu 14.04 لصاحبه Justin Ellingwood.

حقوق الصورة البارزة: Designed by Freepik.

قدمنا في الجزء الأول من هذا الدليل الخطة التي نعمل على إعدادها من أجل ضبط آلية للطرق على المنافذ تعتمد حصرا على جدار 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 من الجهاز الذي نستخدمه مباشرة بعد الطرْق حسب المتتالية المتفق عليها؛ وهي:

• 1111
• 2222
• 3333

يجب ألا تستخدم هذه القيم في الإعدادت الحقيقية، لسهولة تخمينها.

لكي يُستوثَق من المستخدم بطريقة صحيحة وبالتالي يجعل 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.

إعداد جدارٍ ناريّ قوي هو خطوةٌ أساسية يجب فعلها بهدف تأمين أيّ نظام تشغيلٍ حديث. تأتي معظم توزيعات لينكس بأدواتٍ مختلفة يمكننا استخدامها لضبط جداراتنا الناريّة. في هذا الدرس، سنتحدّث عن جدار iptables الناريّ.

Iptables هو عبارة عن جدارٍ ناريّ عادي موجود في معظم توزيعات لينكس افتراضيًا (برنامجٌ آخر يدعى nftables سيبدأ قريبًا باستبداله). هو في الواقع عبارة عن واجهةٍ أمامية لخطّافات netfilter على مستوى النواة (kernel-level netfilter hooks) يمكنه التعامل مع مكدّس شبكة لينكس (Linux network stack). يعمل iptables عن طريق مطابقة كلّ حزمة (packet) تمرّ عبر الشبكة بمجموعة من القواعد (rules) التي تجعله يقرر ما يجب فعله.

ملاحظة: يغطّي هذا الدرس أساسيات الحماية لـIPv4. في نظام لينكس، هناك فرق بين طرق الحماية لـIPv4 و IPv6. كمثال فإنّ iptables يقوم فقط بالتحكّم في قواعد جدار الحماية لعناوين IPv4 إلّا أنّه يمتلك برنامجًا خارجيًا يدعى ip6tables يمكن استخدامه للتحكّم في قواعد جدار الحماية لعناوين IPv6.

إذا كان خادومك الافتراضي الخاصّ مُعدًّا ليستخدم IPv6، فرجاءً تذكّر حماية كلّ من واجهتيّ الشبكة IPv4 و IPv6 باستخدام الأدوات المناسبة. للمزيد من المعلومات عن أدوات IPv6، راجع هذا الدرس: كيفية ضبط بعض الأدوات لاستخدام IPv6 على نظام لينكس.

أوامر iptables الأساسية

الآن وبعد أن صار لديك المفاهيم الأساسية حول iptables، فإنّه يجب علينا تغطية الأوامر الأساسية التي سيتم استعمالها لتشكيل مجموعات قواعد iptables أكبر بالإضافة إلى إدارة واجهة iptables بشكلٍ عام.

أولًا، يجب عليك أن تنتبه إلى أنّ أوامر iptables يجب أن يتم تشغيلها بصلاحيات الجذر (root privileges). هذا يعني أنّه يجب عليك الولوج إلى النظام باسم المستخدم root، استخدم su أو sudo -i للولوج إلى صدفة المستخدم الجذر، أو يمكنك ببساطة وضع sudo قبل جميع الأوامر التي ستطبّقها. سنستخدم sudo في هذا الدرس بما أنّها طريقة شائعة الاستخدام على نظام Ubuntu.

نقطة جيدة للبداية بها هي كيفية سرد قواعد iptables المُستخدمة حاليًا. يمكنك فعل هذا باستخدام الخيار -L :

$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination 
Chain FORWARD (policy ACCEPT)
target prot opt source destination 
Chain OUTPUT (policy ACCEPT)
target prot opt source destination

كما يمكنك أن ترى، لدينا ثلاث سلاسل (chains) هنا. يمكننا أيضًا أن نرى السياسة المتّبعة في كلّ سلسلة (كل سلسلة افتراضيًا تمتلك سياسة ACCEPT للاتصالات المارّة منها). يمكننا أيضًا رؤية بعض ترويسات العواميد في ناتج الأمر السابق، إلّا أنّنا فعليًا لا نرى أيّ قواعد مطبّقة. هذا بسبب أنّ Ubuntu لا تأتي مع مجموعةٍ افتراضية من قواعد iptables.

يمكننا رؤية الخرج بصيغةٍ تعكس الأوامر الضرورية لتفعيل كلّ قاعدة وسياستها عبر استخدام الخيار -S :

$ sudo iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT

لإعادة إنتاج الإعدادات وتطبيقها من جديد، سيجب علينا فقط كتابة الأمر sudo iptables متبوعًا بكلّ واحدٍ من السطور الظاهرة في الخرج. (اعتمادًا على الإعدادات، قد يكون الأمر أكثر تعقيدًا في حال كنّا متّصلين عن بعد إلى الخادوم حيث أننا لا نريد إضافة قواعد iptables معيّنة تمنع جميع الاتصالات الواردة إليها مثلًا دون استثناء اتّصالنا الحالي لكي لا ينقطع فجأة ولكي يبقى متّصلًا).

إذا كان لديك قواعد بالفعل لديك في iptables وكنتَ ترغب بإتلافها والبدء من جديد، فيمكنك فعل ذلك عبر تطبيق:

$ sudo iptables -F

مرةً أخرى، سياسة قبول الاتصالات أو رفضها مهمّة هنا، لأنّه وبينما يتم حذف جميع القواعد الأخرى من السلاسل الخاصّة بك، فإنّ السياسة الافتراضية لن تتغيّر باستخدام هذا الأمر. هذا يعني أنّه في حال كنت متّصلًا عن بعد بخادومك، فإنّه يجب عليك التأكّد من أنّ السياسة الافتراضية لسلسلتيّ INPUT و OUTPUT هي ACCEPT بالتزامن مع قيامك بإتلاف قواعدك السابقة. يمكنك فعل ذلك عبر تطبيق الأوامر التاليّة:

$ sudo iptables -P INPUT ACCEPT
$ sudo iptables -P OUTPUT ACCEPT
$ sudo iptables -F

يمكنك تغيير سياسة الحظر أو الترك (drop) مجددًا إلى DROP بعد أن تقوم بإعداد القواعد التي تسمح ببقاء اتّصالك الحالي. سنفصّل كيفيّة ذلك بعد قليل.

إنشاء قاعدتك الأولى

سنبدأ ببناء سياسة جدار الحماية الخاصّ بن حول قبول أو رفض الاتصالات. كما قلنا أعلاه، فإنّنا سنعمل مع سلسلة INPUT بما أنّها المصدر الرئيسي لتدفّق الزوار القادم إلى خادومنا. سنبدأ مع القاعدة التي تحدّثنا عنها مسبقًا من قبل بالأعلى: القاعدة التي تسمح لنا بشكل خاص بمتابعة اتّصال SSH الحالي.

القاعدة الكاملة التي نحتاج إليها هي هذه:

$ sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

قد يبدو هذا معقّدا للغاية لك في الوهلة الأولى، إلّا أنّ معظم مكوّنات الأمر السابق ستكون ذات معنى بالنسبة لك عندما تفهمها:

• -A INPUT: يقوم الخيار -A بإضافة قاعدةٍ ما إلى نهاية السلسلة المطلوبة. هذا هو الجزء الذي يقوم بإخبار iptables بأنّنا نريد إضافة قاعدةٍ جديدة إلى سلسلة معيّنة، والسلسلة التي نريدها في مثالنا حاليًا هي سلسلة INPUT.

• -m conntrack: يمتلك iptables عدّة وظائف داخليّة، ولكنّه أيضًا يمتلك مجموعةً من الامتدادات والوحدات التي تقوم بتوفير مزايا إضافيّة. إنّنا نقوم في هذا الجزء من الأمر بإخبار iptables بأنّنا نريد الحصول على إذن بالوصول إلى الوظيفة التي يتم توفيرها عبر الوحدة المسماة "conntrack”. تعطينا هذه الوحدة وصولًا إلى الأوامر التي يمكن أن يتم استخدامها بناءً على علاقة حزمة البيانات الداخلة بالاتّصال السابق.

• --ctstate: هذا واحدٌ من الأوامر التي أصبحت متوفّرة بعد أن تم استدعاء وحدة "conntrack”. يسمح لنا هذا الأمر بمطابقة حزم البيانات بناءً على ماهيّة ارتباطها بحزم البيانات التي رأيناها من قبل. إننا نقوم بتمرير قيمة ESTABLISHED للسماح بمرور حزم البيانات الداخلة التي هي جزء من اتّصالٍ عاملٍ حاليًا فقط. ونقوم بتمرير قيمة RELATED للسماح بمرور حزم البيانات المرتبطة باتّصالٍ مُنشَئٍ بالفعل. هذا الجزء من القاعدة هو الجزء الذي يتطابق مع جلسة SSH الحالية الخاصّة بنا.

• -j ACCEPT: يقوم هذا الخيار بتحديد هدف مطابقة حزم البيانات. هنا، نقوم بإخبار iptables أنّ حزم البيانات التي تطابق القاعدة السابقة يجب أن يتم السماح لها بالمرور.

قمنا بوضع هذه القاعدة في البداية لأننا أردنا أن نتأكّد أنّ اتصالنا الحالي مطابق، مقبول وخارج إطار السلسلة قبل تنفيذ أيّ قواعد DROP.

يمكننا الآن رؤية حالة التغييرات التي قمنا بها عن طريق:

$ sudo iptables -L

Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

الآن وبعد أن صرتَ تعرف الصياغة العامّة لقواعد iptables، فلنتابع عبر استعراض المزيد من الحالات التي سنحتاج فيها إلى قبول الاتّصالات.

قبول الاتّصالات المهمّة الأخرى

أخبرنا iptables أن يبقي أيّ اتصالاتٍ مفتوحة على وضعها الحالي بالإضافة إلى السماح بالاتصالات الجديدة المرتبطة بتلك الاتصالات. على كلّ حال، نحتاج إلى إنشاء بعض القواعد الضرورية لتحديد متى نريد قبول اتّصالاتٍ جديدة لا تطابق هذه المعايير التي طبّقناها.

نريد إبقاء منفذين اثنين مفتوحين بالتحديد. نريد إبقاء منفذ اتّصال SSH الخاصّ بنا مفتوحًا (سنفترض في هذا الدرس أنّ المنفذ الافتراضي له هو المنفذ 22. إذا كنتَ غيّرت هذا المنفذ على خادومك من إعدادات SSH فقم بتعديل قيمته هنا). سنقوم أيضًا بافتراض أنّ هذا الحاسوب يقوم أيضًا بتشغيل خادوم ويب يعمل على المنفذ 80. إذا لم يكن هذا هو نفس الوضع بالنسبة لك فلن تحتاج تطبيق القاعدة التالية.

السطران اللذان سنستعملهما لتطبيق هذه القواعد هما:

sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT

كما يمكنك أن ترى، هذه القواعد مشابهة جدًا لقاعدتنا الأولى التي كتبناها، ولكنها ربما تكون أكثر بساطةً. الخيارات الجديدة هي:

• -p tcp: يقوم هذا الخيار بمطابقة حزم البيانات في حال كان البروتوكول المستخدم هو TCP. هذا البروتوكول هو بروتوكولٌ مستخدم بواسطة معظم التطبيقات لأنّه يسمح بتواصلٌ مرن وقوي بين المستخدم والتطبيق.

• --dport: يكون هذا الخيار متوفّرًا للاستخدام فقط في حال كان الخيار -p tcp موجودًا في الأمر. إنّه يقوم أيضًا بتحديد رقم المنفذ الذي يجب مطابقة حزم البيانات عبره. تقوم القاعدة الأولى بمطابقة حزم البيانات المارّة عبر بروتوكول TCP بالمنفذ 22، بينما تقوم الثانية بمطابقتها عبر المنفذ 80.

هناك قاعدة ACCEPT أخرى يجب علينا التأكّد من أنّ خادومنا يقبلها بشكل صحيح. غالبًا، تتواصل الخدمات (services) مع بعضها البعض على الحاسوب عبر إرسال حزم بياناتٍ فيما بينها، وهي تقوم بذلك عبر الاستفادة من واجهة شبكةٍ زائفة تدعى loopback device ، والتي تقوم بتوجيه التدفّق إلى نفسها عوضًا عن الأجهزة الأخرى.

لذا إذا كانت واحدة من الخدمات تريد التواصل مع خدمةٍ أخرى تستمع إلى المنفذ 4555، فإنّه بمقدورها إرسال حزمة بيانات إلى المنفذ 4555 على الشبكة الزائفة loopback device. نريد أن يتم السماح بهذا النوع من السلوك بين الخدمات لأنّه ضروري للعديد من برامج نظام التشغيل.

القاعدة التي نحتاج تطبيقها هي هذه:

$ sudo iptables -I INPUT 1 -i lo -j ACCEPT

يبدو هذا الأمر مختلفًا قليلًا عن الأوامر السابقة. فلنشرح ما يفعله:

• -I INPUT 1: يقوم الخيار -I بإخبار iptables بإدراج قاعدةٍ جديدة. هذا الخيار مختلف عن الخيار -A والذي يقوم بإضافة القاعدة الجديدة إلى نهاية قواعد iptables. يحتاج الخيار -I إلى اسم السلسلة والمكان الذي تريد إدراج القاعدة الجديدة فيه.

في حالتنا، فإننا نقوم بإضافة هذه القاعدة كأول قاعدة في سلسلة INPUT. هذا سيدفع بقية القواعد إلى الأسفل بدرجةٍ واحدة تلقائيًا. نحتاج لهذه القاعدة أن تكون بالأعلى لأنّها أساسية ولا يجب أن يتم التأثير عليها عبر قواعد فرعيّة أخرى.

• -i lo: يقوم هذا المكوّن من القاعدة بمطابقة ما إذا كانت الواجهة التي تستخدمها حزمة البيانات هي واجهة "lo”. واجهة "lo” هي عبارة عن اسمٍ آخر لـloopback device. هذا يعني أنّ أيّ حزمةِ بياناتٍ تستعمل تلك الواجهة الشبكيّة للتواصل (حزم البيانات الناتجة في خادومنا، إلى خادومنا) يجب أن يتم قبولها من طرف iptables.

لرؤية قواعدنا الحاليّة، يجب أن نستخدم الخيار -a . هذا بسبب أنّ الخيار -L لا يتضمّن بعض المعلومات، مثل اسم الواجهة المرتبطة بالقواعد، والذي يعتبر جزءًا مهمًّا في القاعدة التي قمنا بإضافتها:

$ sudo iptables -S

-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT

تضمين قاعدة حظر (Drop)

نمتلك الآن 4 قواعد منفصلة تقبل الاتصالات بناءً على معايير معيّنة. وبالرغم من ذلك، فإنّا خادومنا حاليًا لا يحظر وصول أيّ شيء إليه.

إذا دخلت حزمة بياناتٍ إلى سلسلة INPUT ولم تكن مطابقة لأيٍّ من القواعد الأربعة التي أدخلناها، فإنّه سيتم تحويلها إلى السياسة الافتراضية للتعامل مع حزم البيانات، والتي هي حاليًا "قبول حزم البيانات جميعها"، ونحتاج لتغيير هذا الأمر.

هناك طريقتان يمكننا فعل ذلك بهما، مع بعض الاختلافات الجوهرية.

الطريقة الأولى التي يمكننا من خلالها القيام بهذا هي عن طريق تعديل السياسة الافتراضية لسلسلة INPUT. يمكننا القيام بذلك عبر كتابة:

$ sudo iptables -P INPUT DROP

ستقوم القاعدة السابقة بالتقاط أيّ حزم بياناتٍ تفشل بالمرور عبر سلسلة INPUT الخاصّة بنا ويمنع وصولها إلى الخادوم. هذا ما ندعوه بسياسة المنع الافتراضيّة (default drop policy)، من مساوئ هذه الطريقة هي أنّ قاعدة الـDROP هذه يتم إلغاؤها في حال تم مسح قواعد iptables (حيث أنّها قاعدة هي الأخرى وبالتالي سيتم مسحها معها).

قد تكون هذه الطريقة أكثر أمنًا، ولكنك قد تواجه عواقب وخيمة في حال لم يكن لديك طريقةٌ أخرى للوصول إلى خادومك. في DigitalOcean، يمكنك الولوج عبر لوحة التحكّم إلى خادومك والوصول إلى طرفيّة ويب تمكّنك من التحكّم به إذا حصل هذا. طرفيّة الويب هذه تعرّف نفسها على أنّها اتصال وهمي محلّي ولذلك فإنّ قواعد iptables لا تؤثّر عليها.

قد تودّ لخادومك أن يقوم بحظر جميع الاتصالات في حال مسح جميع القواعد. قد يمنع هذا من ترك خادومك مفتوحًا للجميع. وهذا يعني أيضًا أنّه بمقدورك بسهولة إضافة القواعد إلى نهاية أيّ سلسلة تريدها بينما تحظر حزم البيانات التي لا تريدها بسهولة.

إذا قمتَ بتغيير السياسة الافتراضيّة لسلسلة INPUT، فإنّه يمكنك إرجاعها عبر تطبيق:

$ sudo iptables -P INPUT ACCEPT

الآن، يمكنك إضافة قاعدة إلى نهاية السلسلة والتي ستقوم بحظر أيّ حزم بياناتٍ متبقية:

$ sudo iptables -A INPUT -j DROP

النتائج تحت شروطٍ تشغيلية عادية ستكون بالضبط هي نفس سياسة الحظر الافتراضيّة. تعمل هذه القاعدة عبر مطابقة كلّ حزمة بياناتٍ متبقية تصل إليها. يمنع هذا حزمةَ البيانات من الوصول إلى الخادوم في حال فشلت بتجاوز القواعد السابقة التي قمنا بإنشائها.

بشكلٍ عام، يتم استخدام هذه القاعدة لجعل السياسة الافتراضيّة في التعامل مع الاتصالات تقبل التدفّق الواصل إليها. بهذه الطريقة، في حال كان هناك أيّ مشاكل وتم مسح جميع القواعد، فإنّك ستبقى قادرًا على الوصول إلى الآلة عبر الشبكة.

بالطبع، هذا يعني أيضًا أنّ أيّ قاعدةٍ إضافية تودّ إضافتها إلى نهاية السلسلة يجب أن تكون قبل قاعدة الحظر أو الـdrop. يمكنك فعل هذا عبر حذف قاعدة الحظر مؤقتًا عبر:

$ sudo iptables -D INPUT -j DROP
$ sudo iptables -A INPUT new_rule_here
$ sudo iptables -A INPUT -j DROP

أو، يمكنك إدراج القواعد التي تحتاجها في نهاية السلسلة (ولكن قبل قاعدة الـdrop) عبر تحديد رقم السطر. لإدراج قاعدةٍ في السطر رقم 4، يمكنك كتابة:

$ sudo iptables -I INPUT 4 new_rule_here

إذا كنتَ تواجه مشاكل في معرفة إلى أيّ سطرٍ تنتمي أيّ قاعدة، فيمكنك إخبار iptables بأن يقوم بسرد السطور المتوفّرة عبر:

$ sudo iptables -L –line-numbers
Chain INPUT (policy DROP)
num target prot opt source destination
1 ACCEPT all -- anywhere anywhere
2 ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
3 ACCEPT tcp -- anywhere anywhere tcp dpt:ssh
4 ACCEPT tcp -- anywhere anywhere tcp dpt:http

Chain FORWARD (policy ACCEPT)
num target prot opt source destination

Chain OUTPUT (policy ACCEPT)
num target prot opt source destination

يمكن لهذا أن يكون مفيدًا للتأكّد من أنّك تضيف القاعدة إلى مكانها الصحيح.

حفظ إعدادات iptables الخاصّة بك

افتراضيًا، تكون القواعد التي تضيفها إلى iptables غير دائمة. هذا يعني أنّك عندما تقوم بإعادة تشغيل خادومك، فإنّ جميع قواعد iptables ستختفي.

هذه المشكلة في الواقع هي ميّزة لبعض المستخدمين لأنّها تعطيهم فرصةً للعودة إلى التحكّم بالخادوم في حال قاموا بحبس أنفسهم خارجها عن طريق الخطأ في تطبيق القواعد. وعلى كلّ حال، معظم المستخدمين سيودّون أن يكون هناك طريقة تلقائية لحفظ القواعد التي أنشؤوها وتحميلها تلقائيًا عند إقلاع الخادوم.

هناك عدّة طرق لفعل هذا، لكنّ أسهلها هو باستخدام حزمة iptables-presistent، يمكنك تحميل هذه الحزمة من مستودعات Ubuntu الافتراضيّة:

$ sudo apt-get update
$ sudo apt-get install iptables-persistent

أثناء التثبيت، سيتم سؤالك عمّا إذا كنتَ تحبّ حفظ قواعد iptables الحاليّة ليتم تحميلها تلقائيًا. إذا كنتَ مسرورًا مع إعداداتك الحاليّة (واختبرت قدرتك على الوصول إلى اتصالات SSH جديدة مستقلة) فإنّه يمكنك الموافقة على ذلك.

سيتم سؤالك أيضًا عمّا إذا كنتَ تريد حفظ قواعد IPv6 التي قمتَ بإعدادها، يتم إعداد هذه القواعد عبر أداة منفصلة تدعى ip6tables والتي تتحكم بحزم بيانات IPv6 بنفس الطريقة.

بمجرّد اكتمال التثبيت، ستتوفر خدمة جديدة لديك تدعى iptables-presistent وهي مُعدّة ليتم تشغيلها عند الإقلاع. ستقوم هذه الخدمة بتحميل قواعد iptables الحاليّة وتطبيقها من جديد في كلّ مرّة يتم إعادة تشغيل النظام فيها.

الخاتمة

يجب أن تكون الآن قد امتلكت نقطة بداية جيّدة للبدء في تطوير جدارٍ ناري يلبي احتياجاتك. هناك العديد من أدوات الجدران الناريّة الأخرى التي يمكنك استخدامها والتي قد تكون أسهل، ولكن iptables أداةٌ جيّدة لتعلّمها، ذلك لأنّها توفّر بنية netfilter تحتية جيّدة للاستعمال ولأنّها متوفّرة افتراضيًا في العديد من أنظمة التشغيل.

ترجمة -وبتصرّف- للمقال: How To Set Up a Firewall Using IPTables on Ubuntu 14.04.