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

واحدة من أكبر المشاكل مع البريد الإلكتروني اليوم هي مشكلة البريد غير المرغوب فيه (Unsolicited Bulk Email أو اختصارًا UBE) المعروف أيضًا بالبريد العشوائي (SPAM)؛ قد تحتوي هذه الرسائل أيضًا على فيروسات أو أشكالٍ أخرى من البرمجيات الخبيثة؛ ووفقًا لبعض التقارير، تشغل هذه الرسائل حيزًا كبيرًا من البريد الإلكتروني المُرسَل عبر الإنترنت. سيشرح هذا القسم طريقة دمج Amavisd-new، و Spamassassin، و ClamAV مع عميل نقل البريد Postfix؛ يمكن أيضًا التحقق من البريد عبر تمريره خلال مرشحات خارجية؛ هذه المرشحات يمكنها في بعض الأحيان تحديد إذا ما كانت الرسالةُ عشوائيةً دون الحاجة إلى معالجتها ببرمجيات تستهلك الموارد؛ أشهر هذه المرشحات هي opendkim و python-policyd-spf. Amavisd-new هو برنامج مُغلِّف (wrapper) يستطيع استدعاء أي عدد من برامج ترشيح المحتوى لاستكشاف الرسائل العشوائية، وللتصدي للفيروسات ...إلخ. يستخدم Spamassassin آلياتٍ عدِّة لترشيح البريد اعتمادًا على محتوى الرسالة. ClamAV هو مضاد فيروسات مفتوح المصدر. يوفر opendkim ما يسمىMilter (أي Sendmail Mail Filter) إلى المعيار القياسي DKIM (أي DomainKeys Identified Mail). يُفعِّل python-policyd-spf تحقق SPF (اختصار للعبارة Sender Policy Framework) مع Postfix. هذه هي آلية جمع القطع السابقة: تُقبَل رسالة البريد الإلكتروني من Postfix. تُمرَّر الرسالة إلى أي مرشحات خارجية مثل opendkim و python-policyd-spf في هذه الحالة. ثم يُعالِج Amavisd-new الرسالة. ثم يُستخدَم ClamAV لفحص الرسالة؛ إذا حوت الرسالة على فيروس، فسيرفضها Postfix. ستُحلَّل الرسائل «النظيفة» من Spamassassin للتحقق إذا كانت الرسالة هي رسالة عشوائية؛ ثم يضيف Spamassassin أسطر X-Header ليسمح للبرمجية Amavisd-new بإكمال معالجة الرسالة. على سبيل المثال، إذا كان «رصيد العشوائية» لرسالة ما أكبر من خمسين بالمئة، فيمكن أن تُزال الرسالة تلقائيًا من الطابور (queue) حتى دون إعلام المتلقي؛ طريقة أخرى للتعامل مع هذه الرسائل هي إيصالهم لعميل مستخدم البريد (MUA) والسماح للمستخدم بأن يتعامل مع الرسالة بما يراه مناسبًا. التثبيت راجع درس Postfix لمعلوماتٍ تفصيلية عن تثبيت Postfix. أدخل الأمرين الآتيين في سطر الأوامر لتثبيت بقية البرمجيات: sudo apt-get install amavisd-new spamassassin clamav-daemon sudo apt-get install opendkim postfix-policyd-spf-python هنالك بعض الحزم الأخرى التي يمكن أن تُدمَج مع Spamassassin لاكتشاف أفضل للرسائل العشوائية: sudo apt-get install pyzor razor بالإضافة إلى برمجيات الترشيح الرئيسية، سنحتاج إلى أدوات الضغط لنعالج بعض مرفقات البريد: sudo apt-get install arj cabextract cpio lha nomarch pax rar unrar unzip zip ملاحظة: إذا لم يُعثَر على بعض الحزم السابقة، فتأكد من تفعيل مستودع multiverse في ملف ‎/etc/apt/sources.list. إذا أجريتَ تعديلاتٍ على ذاك الملف، فتأكد من تحديث فهرس الحزم بتنفيذ الأمر sudo apt-get update قبل محاولة التثبيت مرةً أخرى. الضبط علينا الآن ضبط كل شيء مع بعضه بعضًا لترشيح البريد. ClamAV السلوك الافتراضي لبرمجية ClamAV تناسب احتياجاتنا؛ للمزيد من خيارات الضبط الخاصة ببرمجية ClamAV، راجع ملفات الضبط في ‎/etc/clamav. أضف المستخدم clamav إلى المجموعة amavis لكي يملك Amavisd-new الوصول الملائم لتفحص الملفات: sudo adduser clamav amavis sudo adduser amavis clamav Spamassassin يعثر Spamassassin تلقائيًا على المكونات الإضافية ويستخدمها إن توفرت؛ هذا يعني أنه لا حاجة لضبط pyzor و razor. عدِّل ملف الضبط ‎/etc/default/spamassassin لتفعيل عفريت Spamassassin، عدِّل قيمة ENABLED=0 إلى: ENABLED=1 ثم ابدأ تشغيل العفريت: sudo service spamassassin start Amavisd-new أولًا، فعِّل استكشاف الرسائل العشوائية ومضاد الفيروسات في Amavisd-new بتعديل الملف ‎/etc/amavis‎/conf.d/15-content_filter_mode: use strict; # You can modify this file to re-enable SPAM checking through spamassassin # and to re-enable antivirus checking. # # Default antivirus checking mode # Uncomment the two lines below to enable it # @bypass_virus_checks_maps = ( \%bypass_virus_checks, \@bypass_virus_checks_acl, \$bypass_virus_checks_re); # # Default SPAM checking mode # Uncomment the two lines below to enable it # @bypass_spam_checks_maps = ( \%bypass_spam_checks, \@bypass_spam_checks_acl, \$bypass_spam_checks_re); 1; # insure a defined return قد تكون إعادة معالجة الرسائل العشوائية فكرةً سيئةً لأن العنوان المُعاد مزيفٌ غالبًا؛ ربما ترغب بتعديل الملف ‎/etc/amavis/conf.d/20-debian_defaults لتضبط ‎$final_spam_destiny إلى D_DISCARD بدلًا من D_BOUNCE، كما يلي: $final_spam_destiny = D_DISCARD; وربما ترغب بتعديل قيمة الخيارات الآتية لتعليم (flag) المزيد من الرسائل كرسائل عشوائية: $sa_tag_level_deflt = -999; # add spam info headers if at, or above that level $sa_tag2_level_deflt = 6.0; # add 'spam detected' headers at that level $sa_kill_level_deflt = 21.0; # triggers spam evasive actions $sa_dsn_cutoff_level = 4; # spam level beyond which a DSN is not sent إذا كان اسم المضيف للخادوم (hostname) مختلفًا عن سجل MX للنطاق، فربما تحتاج إلى أن تضبط الخيار ‎$myhostname يدويًا؛ وإذا كان الخادوم يستلم البريد لأكثر من نطاق، فيجب تخصيص الخيار ‎@local_domains_acl أيضًا، وذلك بتعديل الملف ‎/etc/amavis/conf.d/50-user: $myhostname = 'mail.example.com'; @local_domains_acl = ( "example.com", "example.org" ); إذا أردت تغطية أكثر من نطاق، فعليك استخدام ما يلي في ‎/etc/amavis/conf.d/50-user: @local_domains_acl = qw(.); يجب إعادة تشغيل Amavisd-new بعد الضبط: sudo service amavis restart DKIM Whitelist يمكن ضبط Amavisd-new ليضيف عناوين من نطاقات معينة مع مفاتيح نطاق (Domain Keys) صالحة إلى القائمة البيضاء (Whitelist)؛ هنالك بعض النطاقات المضبوطة مسبقًا في ‎/etc/amavis/conf.d/40-policy_banks: هذه بعض الأمثلة لضبط القائمة البيضاء لنطاق: التعليمة ‎'example.com' => 'WHITELIST',‎: ستضيف أي عنوان من النطاق "example.com" إلى القائمة البيضاء. التعليمة ‎'‎.example.com' => 'WHITELIST‎'‎,‎: ستضيف أي عنوان من أي نطاق فرعي للنطاق "example.com" ويملك توقيع صالح (valid signature) إلى القائمة البيضاء. التعليمة ‎'‎.example.com/@example.com' => 'WHITELIST',‎: إضافة أي عنوان من النطاقات الفرعية للنطاق "example.com" الذي يستخدم توقيع النطاق الأب "example.com". التعليمة ‎'‎./@example.com' => 'WHITELIST',‎: يضيف العناوين من توقيع صالح من "example.com" هذا يستخدم عادةً لمجوعات النقاش التي توقَّع رسائلها. يمكن أن يملك نطاقٌ واحد أكثر من ضبط للقائمة البيضاء؛ عليك إعادة تشغيل amavisd-new بعد تعديل الملف: sudo service amavis restart ملاحظة: في هذا السياق؛ عندما يُضاف النطاق إلى القائمة البيضاء، فإن الرسالة لن تحصل على أي فحص من الفيروسات أو الرسائل العشوائية؛ ربما يكون أو لا يكون هذا هو السلوك الذي ترغبه لهذا النطاق. Postfix أدخل ما يلي في مِحَث الطرفية لدمج Postfix: sudo postconf -e 'content_filter = smtp-amavis:[127.0.0.1]:10024' ثم عدِّل الملف ‎/etc/postfix/master.cf وأضف الأسطر الآتية إلى نهاية الملف: smtp-amavis unix - - - - 2 smtp -o smtp_data_done_timeout=1200 -o smtp_send_xforward_command=yes -o disable_dns_lookups=yes -o max_use=20 127.0.0.1:10025 inet n - - - - smtpd -o content_filter= -o local_recipient_maps= -o relay_recipient_maps= -o smtpd_restriction_classes= -o smtpd_delay_reject=no -o smtpd_client_restrictions=permit_mynetworks,reject -o smtpd_helo_restrictions= -o smtpd_sender_restrictions= -o smtpd_recipient_restrictions=permit_mynetworks,reject -o smtpd_data_restrictions=reject_unauth_pipelining -o smtpd_end_of_data_restrictions= -o mynetworks=127.0.0.0/8 -o smtpd_error_sleep_time=0 -o smtpd_soft_error_limit=1001 -o smtpd_hard_error_limit=1000 -o smtpd_client_connection_count_limit=0 -o smtpd_client_connection_rate_limit=0 -o receive_override_options=no_header_body_checks,no_unknown_recipient_checks,no_milters أيضًا أضف السطرين الآتيين مباشرةً بعد خدمة النقل «pickup»: -o content_filter= -o receive_override_options=no_header_body_checks هذا سيمنع الرسائل المُولَّدة للتبليغ عن الرسائل العشوائية من تصنيفها كرسائل عشوائية؛ أعد الآن تشغيل Postfix: sudo service postfix restart يجب الآن أن يكون ترشيح المحتوى والعثور على الفيروسات مُفعَّلًا. الاختبار أولًا، اختبر أن Amavisd-new SMTP يستمع: telnet localhost 10024 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 [127.0.0.1] ESMTP amavisd-new service ready ^] وفي ترويسة (header) الرسائل التي تُمرَّر عبر مُرشِّح المحتوى، يجب أن تُشاهِد: X-Spam-Level: X-Virus-Scanned: Debian amavisd-new at example.com X-Spam-Status: No, hits=-2.3 tagged_above=-1000.0 required=5.0 tests=AWL, BAYES_00 X-Spam-Level: ملاحظة: قد تختلف النتائج المعروضة عمَّا سيظهر عندك، لكن من المهم وجود القيدين X-Virus-Scanned و X-Spam-Status. استكشاف الأخطاء أفضل طريقة لمعرفة سبب حدوث مشكلة ما هي مراجعة ملفات السجل. لتعليماتٍ عن التسجيل في Postfix راجع الدرس الخاص به. يستخدم Amavisd-new البرمجية Syslog لإرسال الرسائل إلى ‎/var/log/mail.log؛ يمكن زيادة مقدار التفاصيل بإضافة الخيار ‎$log_level إلى ملف ‎/etc/amavis/conf.d/50-user، وضبط القيمة من 1 إلى 5: $log_level = 2; ملاحظة: عند زيادة درجة الإسهاب لسجل Amavisd-new، فسيزداد ناتج سجل Spamassassin أيضًا. يمكن زيادة مستوى التسجيل لبرمجية ClamAV بتعديل الملف ‎/etc/clamav/clamd.conf وضبط الخيار الآتي: LogVerbose true افتراضيًا، سيُرسِل ClamAV رسائل السجل إلى ‎/var/log/clamav/clamav.log. ملاحظة: بعد تغيير إعدادات التسجيل للبرمجيات، تذكر أن تعيد تشغيل الخدمة لكي تأخذ الإعدادات الجديدة مفعولها؛ أيضًا تذكر أن تعيد القيمة الافتراضية بعد أن تحل المشكلة. مصادر للمزيد من المصادر حول ترشيح البريد، راجع الوصلات الآتية: توثيق Amavisd-new. توثيق ClamAV وويكي ClamAV. ويكي Spamassassin. صفحة Pyzor الرئيسية. صفحة Razor الرئيسية. DKIM.org Postfix Amavis New أيضًا، تستطيع أن تسأل أسئلتك في قناة ‎#ubuntu-sever على خادوم freenode. ترجمة -وبتصرف- للمقال Ubuntu Server Guide: Mail Filtering.

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