فصل 11. خدمات الشبكة: Postfix،‏ Apache،‏ NFS،‏ Samba،‏ Squid،‏ LDAP،‏ SIP،‏ XMPP،‏ TURN

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

تتطلب العديد من الخدمات الشبكية تقنية تشفير حتى تعمل بشكل آمن وموثوق، خصوصاً عند استخدامها عبر الإنترنت العمومي. تستخدم شهادات X.509 (التي يشار إليها أيضاً باسم شهادات SSL أو شهادات TLS) عادة لهذا الغرض. يمكن تشارك شهادة النطاق الواحدة عادة بين عدة خدمات من الخدمات التي سنناقشها في هذا الفصل.

11.1. مخدم البريد الإلكتروني

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

بدائل مخدم Exim4

تستخدم دبيان مخدم Exim4 كمخدم افتراضي للبريد الإلكتروني (لذلك يرفق Exim4 مع التثبيت الأولي). الإعدادات متوفرة في حزمة منفصلة، هي exim4-config، وهي تخصص آلياً اعتماداً على إجابات مجموعة من أسئلة Debconf تشبه كثيراً الأسئلة التي تطرحها الحزمة postfix.

إما أن تكون الإعدادات في ملف مفرد (/etc/exim4/exim4.conf.template) أو منفصلة في عدد من ملفات الضبط المخزنة في المجلد /etc/exim4/conf.d/. في كلا الحالتين، يستخدم update-exim4.conf الملفات كقالب لتوليد الملف /var/lib/exim4/config.autogenerated. يستخدم Exim4 الملف الأخير. بفضل هذه الآلية، يمكن حقن القيم المأخوذة من إعدادات debconf للمخدم Exim —المخزَّنة في /etc/exim4/update-exim4.conf.conf— في ملف إعداد Exim، حتى عندما يُعدِّل مدير النظام أو الحزم الأخرى على إعدادات Exim الافتراضية.

صيغة إعدادات Exim4 لها خصوصياتها وتحتاج زمناً لتعلمها؛ لكن إذا فهمت هذه الخصوصيات، فإن Exim4 هو مخدم بريد إلكتروني مكتمل وقوي جداً، كما تشهد عشرات صفحات الوثائق.

→ http://www.exim.org/docs.html

11.1.1. تثبيت Postfix

تتضمن الحزمة postfix خدمة SMTP الرئيسية. أما الحزم الأخرى (مثل postfix-ldap وpostfix-pgsql) فهي تضيف وظائف زائدة إلى Postfix، منها الوصول إلى قواعد معطيات جهات الاتصال. عليك تثبيتها فقط إذا كنت تعرف أنك تحتاجها.

تطرح Debconf عدة أسئلة أثناء تثبيت الحزمة. تسمح الإجابات بتوليد نسخة أولية من ملف الإعداد /etc/postfix/main.cf.

يستفسر السؤال الأول عن نوع الإعداد. هناك إجابتين فقط من الإجابات المقترحة تناسب حالة المخدمات المتصلة بالإنترنت، هما ”Internet site“ و ”Internet with smarthost“. الأول مناسب للمخدمات التي تستقبل البريد الوارد وترسل البريد الصادر مباشرة إلى متلقيه، ولذلك فهو يناسب حالة شركة فلكوت تماماً. أما الثاني فيلائم المخدمات التي تستقبل البريد الوارد بشكل طبيعي، لكنها ترسل البريد الصادر عبر مخدم SMTP وسيط —”المضيف الذكي smarthost“— بدلاً من إرسالها مباشرة إلى المخدم المتلقي. يناسب هذا الخيار كثيراً الأفراد الذين يملكون عناوين IP ديناميكية، لأن العديد من مخدمات البريد الإلكتروني ترفض الرسائل الواردة من هذه العناوين. في هذه الحالة، سيكون المضيف الذكي عادة مخدم SMTP تابع لمزود خدمة الإنترنت، ويكون مُعدّاً بحيث يستقبل دوماً البريد الوارد من زبائن المزود وتوجيهها بشكل مناسب. هذا الإعداد (مع المضيف الذكي) يناسب أيضاً المخدمات التي لا تتصل بالإنترنت دائماً، حتى تتفادى إدارة رتل من الرسائل غير المسلّمة التي يجب إعادة محاولة إرسالها لاحقاً.

يهتم السؤال الثاني بالاسم الكامل للجهاز، الذي سيستخدم لتوليد عناوين البريد الإلكتروني اعتماداً على اسم المستخدم المحلي (هذا هو الجزء الذي يوضع خلف علامة ”@“). في حالة فلكوت، يجب أن تكون الإجابة mail.falcot.com. هذا هو السؤال الوحيد الذي يطرح افتراضياً، لكن الإعداد الناتج ليس كاملاً كفاية بالنسبة لحاجات فلكوت، لذلك استدعى مديرو النظم الأمر dpkg-reconfigure postfix حتى يتمكنوا من تخصيص المزيد من المتغيرات.

أحد الأسئلة الإضافية يطلب جميع أسماء النطاقات المرتبطة بهذا الجهاز. تتضمن القائمة الافتراضية الاسم الكامل بالإضافة لبضعة مرادفات للاسم localhost. لكن يجب إضافة النطاق الرئيسي falcot.com يدوياً. بصورة عامة، يجب إجابة هذا السؤال بإعطاءه جميع أسماء النطاقات التي سيعمل هذا المخدم معها كمخدم MX؛ بكلمات أخرى، جميع أسماء النطاقات التي يبين مخدم DNS أنها تستطيع استقبال البريد الإلكتروني. ينتهي المطاف بهذه المعلومات في المتغير mydestination في الملف /etc/postfix/main.cf (ملف الإعداد الرئيسي لمخدم Postfix).

شكل 11.1. دور السجل MX (سجل DNS) أثناء إرسال البريد

في بعض الحالات، قد يسأل التثبيت أيضاً عن الشبكات التي يجب السماح لها بإرسال البريد عبر الجهاز. في الإعداد الافتراضي، يقبل Postfix الرسائل الإلكترونية التي ترد من الجهاز نفسه فقط؛ لذلك نحتاج إضافة الشبكة المحلية عادة. أضاف مديرو النظم في شركة فلكوت 192.168.0.0/16 إلى الإجابة الافتراضية. إذا لم يطرح عليك هذا السؤال، فالمتغير الموافق له في ملف الإعداد هو mynetworks، كما هو واضح في المثال أدناه.

كما يمكن أيضاً توصيل البريد المحلي عبر procmail. تسمح هذه الأداة للمستخدمين بترتيب بريدهم الوارد وفق القواعد المخزنة في ملف ~/.procmailrc الخاص بكل مستخدم.

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

مثال 11.1. ملف /etc/postfix/main.cf الأولي

# See /usr/share/postfix/main.cf.dist for a commented, more complete version


# Debian specific:  Specifying a file name will cause the first
# line of that file to be used as the name.  The Debian default
# is /etc/mailname.
#myorigin = /etc/mailname

smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no

# appending .domain is the MUA's job.
append_dot_mydomain = no

# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h

readme_directory = no

# TLS parameters
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache

# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for
# information on enabling SSL in the smtp client.

smtpd_relay_restrictions = permit_mynetworks permit_sasl_authenticated defer_unauth_destination
myhostname = mail.falcot.com
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = mail.falcot.com, falcot.com, localhost.localdomain, localhost
relayhost = 
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 192.168.0.0/16
mailbox_command = procmail -a "$EXTENSION"
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
inet_protocols = all

أمن شهادات زيت الثعبان

الشهادات التي تدعى شهادات زيت الثعبان (snake oil)، مثل ”دواء“ زيت الثعبان الذي كان يبيعه المشعوذون عديمو الضمير في الأيام الخالية، ليس لها أي قيمة على الإطلاق: فلا يمكنك الاعتماد عليها للتحقق من هوية المخدم لأنها تولَّد آلياً ومُوقّعة ذاتياً (self-signed). لكنها تفيد في زيادة خصوصية التبادلات على أي حال.

بصورة عامة، يجب استخدام هذه الشهادات لأغراض الاختبار فقط، أما الخدمات النظامية فيجب أن تستخدم شهادات حقيقية؛ التي تُولَّد حسب الطريقة المبيّنة في قسم 10.2.1.1, “البنية التحتية للمفاتيح العامة: easy-rsa”.

11.1.2. إعداد النطاقات الظاهرية

يستطيع مخدم البريد استقبال الرسائل الإلكترونية المرسلة إلى نطاقات أخرى بالإضافة إلى النطاق الرئيسي؛ تُعرَف هذه النطاقات باسم النطاقات الظاهرية (Virtual Domains). في معظم الحالات التي يحدث فيها هذا، لا تكون الرسائل موجهة في النهاية إلى المستخدمين المحليين. يُقدِّم Postfix ميزتين تفيدان في إدارة النطاقات الظاهرية.

11.1.2.1. النطاقات الظاهرية للأسماء المستعارة

لا يحوي نطاق الأسماء المستعارة الظاهري إلا أسماء مستعارة (aliases) فقط، أي عناوين تستخدم لتوجيه الرسائل إلى عناوين أخرى فقط.

تُنشّط هذه النطاقات بإضافة أسمائها إلى المتغير virtual_alias_domains، والإشارة إلى ملف مقابلة الأسماء في المتغير virtual_alias_maps.

مثال 11.2. السطور التي ستضاف إلى الملف /etc/postfix/main.cf

virtual_alias_domains = falcotsbrand.com
virtual_alias_maps = hash:/etc/postfix/virtual

يُعرِّف الملف /etc/postfix/virtual التقابلات بصيغة بسيطة نوعاً ما: كل سطر يحوي حقلين تفصلهما مسافة بيضاء؛ الحقل الأول هو الاسم المستعار، أما الحقل الثاني فيحوي قائمة بالعناوين البريدية التي يشير إليها ذلك الاسم. تغطي الصيغة الخاصة @domain.com جميع الأسماء المستعارة المتبقية في النطاق.

مثال 11.3. مثال عن الملف /etc/postfix/virtual

webmaster@falcotsbrand.com  jean@falcot.com
contact@falcotsbrand.com    laure@falcot.com, sophie@falcot.com
# The alias below is generic and covers all addresses within 
# the falcotsbrand.com domain not otherwise covered by this file.
# These addresses forward email to the same user name in the
# falcot.com domain.
@falcotsbrand.com           @falcot.com

11.1.2.2. نطاقات صناديق البريد الظاهرية

تُخزَّن الرسائل المرسلة إلى نطاقات صناديق البريد الظاهرية في صناديق بريدية غير مرتبطة بأي مستخدم محلي للنظام.

لتفعيل نطاق صناديق بريد ظاهري يجب إضافة اسم هذا النطاق إلى المتغير virtual_mailbox_domains، والإشارة إلى ملف تقابل الصناديق البريدية في المتغير virtual_mailbox_maps. أما المتغير virtual_mailbox_base فيحوي المجلد الذي تخزن الصناديق البريدية فيه.

يشير المتغير virtual_uid_maps (أو المتغير virtual_gid_maps) إلى الملف الذي يحوي التقابلات بين العنوان البريدي ومستخدم النظام (أو المجموعة) الذي ”يملك“ هذا الصندوق البريدي. لمنح ملكية جميع الصناديق البريدية إلى مستخدم واحد أو مجموعة، يمكن استخدام الصيغة static:5000 التي تسند قيمة UID/GID ثابتة (القيمة 5000 هنا).

مثال 11.4. السطور التي ستضاف إلى الملف /etc/postfix/main.cf

virtual_mailbox_domains = falcot.org
virtual_mailbox_maps = hash:/etc/postfix/vmailbox
virtual_mailbox_base = /var/mail/vhosts

صيغة الملف /etc/postfix/vmailbox بسيطة جداً أيضاً: حقلين تفصلهما مسافة بيضاء. الحقل الأول هو عنوان بريد إلكتروني ضمن أحد النطاقات الظاهرية، والثاني موقع صندوق البريد المرتبط معه (نسبةً إلى المجلد المحدّد في virtual_mailbox_base). إذا انتهى اسم صندوق البريد بشرطة مائلة امامية (/)، ستخزّن الرسائل الإلكترونية في صيغة maildir؛ وإلا سوف تستخدم صيغة mbox التقليدية بدلاً منها. تَستخدِم صيغة maildir مجلداً كاملاً لتخزين صندوق البريد، وكل رسالة مفردة تُخزَّن في ملف منفصل. أما في صيغة mbox، فيخزن صندوق البريد كله في ملف واحد، وكل سطر يبدأ بالصيغة ”From “ (كلمة From تليها مسافة) تشير إلى بداية رسالة جديدة.

مثال 11.5. الملف /etc/postfix/vmailbox

# Jean's email is stored as maildir, with
# one file per email in a dedicated directory
jean@falcot.org falcot.org/jean/
# Sophie's email is stored in a traditional "mbox" file,
# with all mails concatenated into one single file
sophie@falcot.org falcot.org/sophie

11.1.3. قيود الاستقبال والإرسال

تتطلب الأعداد المتزايدة من الرسائل غير المرغوبة (spam) زيادة التشديدات على السائل التي يجب أن يقبلها مخدم البريد. يعرض هذا القسم بعض الاستراتيجيات المضمنة في Postfix.

ثقافة مشكلة الرسائل الدعائية

الرسائل الدعائية أو ”spam“ هو مصطلح عام يستخدم للإشارة إلى كل الرسائل التجاريو غير المرغوبة (تدعى أيضاً UCE، أي unsolicited commercial emails) التي تُغرق صناديق البريد؛ ويدعى الأشخاص عديمو الضمير الذين يرسلونها باسم spammers. لا يهتم هؤلاء إلا قليلاً بالإزعاج الذي يسببونه، لأن كلفة إرسال الرسائل الإلكترونية منخفضة جداً، ويكفي جذب نسبة صغيرة جداً من مستقبلي رسائل هذه العروض حتى تجني العملية الدعائية أموالاً تفوق كلفتها. العملية مؤتمتة في معظمها، وأي عنوان بريد ينشر علناً (مثلاً، في منتدى، أو في أرشيف قائمة بريدية، أو على مدونة، وغيرها) ستكتشفها روبوتات الرسائل الدعائية، وستتعرض لسيل لا ينقطع من الرسائل غير المرغوبة.

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

11.1.3.1. تقييد الوصول حسب عناوين IP

يتحكم المتغير smtpd_client_restrictions بالأجهزة التي يسمح لها بالتواصل مع مخدم البريد الإلكتروني.

مثال 11.6. القيود المفروضة اعتماداً على عنوان العميل

smtpd_client_restrictions = permit_mynetworks,
    warn_if_reject reject_unknown_client,
    check_client_access hash:/etc/postfix/access_clientip,
    reject_rbl_client sbl-xbl.spamhaus.org,
    reject_rbl_client list.dsbl.org

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

تقبل التعليمة التوجيهية permit_mynetworks المستخدمة كقاعدة أولى كل الرسائل الإلكترونية التي ترد من جهاز من الشبكة المحلية (المحددة في متغير الإعداد mynetworks).

أما التعليمة التوجيهية الثانية فترفض في الحالة الطبيعية الرسائل التي ترد من الأجهزة التي لا تملك إعدادات DNS صحيحة بالكامل. هذه الإعدادات الصحيحة بالكامل تعني أن استبيان عنوان IP يعطي اسماً، وأن استبيان الاسم يعطي بدوره عنوان IP نفسه. هذا القيد صارم جداً غالباً، لأن معظم مخدمات البريد الإلكتروني لا تملك DNS عكسي لعناوين IP الخاصة بها. ولهذا السبب سبق مديرو النظم في فلكوت التعليمة reject_unknown_client بالخيار warn_if_reject: يؤدي هذا الخيار لاستبدال عملية الرفض بتحذير بسيط يُسجَّل في السجلات. يستطيع بعدها مديرو النظم متابعة عدد الرسائل التي كانت سترفض لو كانت القاعدة نشطة فعلاً، واتخاذ قرار لاحق بعد حسن اطلاع لتفعيل هذا القيد أو عدم تفعيله.

تلميح جداول access

تتضمن معايير التقييد جداول يستطيع تعديلها مدير النظام تحوي مجموعاغت من المرسلين، وعناوين IP، وأسماء الأجهزة المحظورة أو المسموحة. يمكن إنشاء هذه الجداول اعتماداً على نسخة غير مضغوطة من الملف /usr/share/doc/postfix-doc/examples/access.gz. هذا القالب يشرح نفسه بالتعليقات التي يحويها، أي أن كل جدول يشرح الصيغة الخاصة به.

يسرد الجدول /etc/postfix/access_clientip عناوين IP والشبكات؛ أما /etc/postfix/access_helo فيسرد أسماء النطاقات؛ ويحوي /etc/postfix/access_sender العناوين البريدية للمرسلين. يجب تحويل هذه الملفات إلى جداول تهشير (صيغة محسنة للوصول السريع) بعد كل تعديل باستخدام الأمر postmap /etc/postfix/file.

تسمح التعليمة الثالثة لمدير النظام بإعداد قائمة سوداء وقائمة بيضاء لمخدمات البريد الإلكتروني، تُخزَّن في الملف /etc/postfix/access_clientip. تعتبر المخدمات في القائمة البيضاء موثوقة، وبالتالي لا تمر الرسائل الواردة منها عبر قواعد الترشيح التالية.

ترفض آخر قاعدتين أي رسائل ترد من مخدم مذكور في إحدى القوائم السوداء المحددة. RBL هو اختصار Remote Black List؛ هناك كثير من هذه القوائم، لكن كلها تذكر المخدمات ذات الإعدادات السيئة التي تسمح بترحيل الرسائل الدعائية، بالإضافة إلى مرحلات البريد غير المتوقعة مثل الأجهزة المصابة بالديدان أو الفيروسات.

تلميح القوائم البيضاء وقوائم RBL

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

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

11.1.3.2. التحقق من صحة أوامر `EHLO` أو `HELO`

كل عملية تبادل SMTP تبدأ بأمر HELO (أو EHLO)، يتبعه اسم مخدم البريد المرسل؛ قد يكون التحقق من سلامة هذا الاسم مفيداً.

مثال 11.7. القيود المفروضة على الاسم المُعلَن في EHLO

smtpd_helo_restrictions = permit_mynetworks,
    reject_invalid_hostname,
    check_helo_access hash:/etc/postfix/access_helo,
    reject_non_fqdn_hostname,
    warn_if_reject reject_unknown_hostname

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

ترفض القاعدة reject_invalid_hostname الرسائل الإلكترونية عندما يعلن EHLO اسم مضيف صيغته غير صحيحة. وترفض القاعدة reject_non_fqdn_hostname الرسائل عندما لا يكون اسم المضيف المذكور اسم نطاق كامل التوصيف (fully-qualified، أي يتضمن اسم النطاق بالإضافة لاسم المضيف). ترفض القاعدة reject_unknown_hostname الرسائل إذا لم يكن الاسم المعلن مذكوراً في DNS. بما أن هذه القاعدة الأخيرة تؤدي لعمليات رفض كثيرة جداً لسوء الحظ، فقد حوّل مديرو النظم تأثيرها إلى مجرد تحذير باستخدام الخيار warn_if_reject كخطوة أولى؛ وقد يقررون إزالة هذا الخيار في مرحلة لاحقة، بعد فحص نتائج هذه القاعدة.

استخدام permit_mynetworks كقاعدة أولى له أثر جانبي ملفت: فالقواعد التالية ستُطبَّق فقط على المضيفات خارج الشبكة المحلية. يسمح هذا بحظر جميع المضيفات التي تعلن أنها جزء من falcot.com، عبر إضافة السطر falcot.com REJECT You're not in our network! مثلاً إلى الملف /etc/postfix/access_helo.

11.1.3.3. القبول أو الرفض اعتماداً على المرسِل المُعلَن

لكل رسالة هناك مرسل، يُعلِن عنه الأمر MAIL FROM من بروتوكول SMTP؛ يمكن التحقق من هذه المعلومات أيضاً بأساليب عديدة.

مثال 11.8. التحقق من المرسل

smtpd_sender_restrictions = 
    check_sender_access hash:/etc/postfix/access_sender,
    reject_unknown_sender_domain, reject_unlisted_sender,
    reject_non_fqdn_sender

يربط الجدول /etc/postfix/access_sender بعض المعاملات الخاصة ببعض المرسلين. هذا يعني إضافة بعض المرسلين إلى قائمة بيضاء أو سوداء عادة.

تتطلب القاعدة reject_unknown_sender_domain أن يكون نطاق المرسل سليماً، لأنه لازم للعناوين الصحيحة. ترفض القاعدة reject_unlisted_sender المرسلين المحليين إذا لم يكن العنوان موجوداً؛ هذا يمنع إرسال الرسائل الإلكنرونية من عنوان غير صحيح في النطاق falcot.com، ولن تُقبَل الرسائل المنبعثة من joe.bloggs@falcot.com مثلاً إلا إذا كان هذا العنوان موجوداً فعلاً.

أخيراً، ترفض القاعدة reject_non_fqdn_sender الرسائل الإلكترونية التي تدّعي أنها ترد من عناوين ليس لها اسم نطاق كامل التوصيف. عملياً، هذا يعني رفض الرسائل الواردة من user@machine: ولذلك يجب إعلان العنوان على أنه user@machine.example.com أو user@example.com.

11.1.3.4. القبول أو الرفض اعتماداً على المستقبل

لكل رسالة مستقبل واحد على الأقل، يعلن عنه الأمر RCPT TO في بروتوكول SMTP. يضمن التحقق من هذه العناوين أيضاً شرعية الرسالة، حتى لو كانت أقل أهمية من التحقق من عنوان المرسل.

مثال 11.9. التحقق من المستقبل

smtpd_recipient_restrictions = permit_mynetworks, 
    reject_unauth_destination, reject_unlisted_recipient, 
    reject_non_fqdn_recipient

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

ترفض القاعدة reject_unlisted_recipient الرسائل المرسلة إلى مستخدمين محليين لا وجود لهم، وهذا منطقي. أخيراً، ترفض القاعدة reject_non_fqdn_recipient العناوين ذات التوصيف غير الكامل؛ هذا يمنع إرسال رسالة إلى jean أو jean@machine، بل يجب استخدام العنوان الكامل بدلاً من ذلك، مثل jean@machine.falcot.com أو jean@falcot.com.

11.1.3.5. القيود المتعلقة بالأمر `DATA`

يُرسَل الأمر DATA التابع لبروتوكول SMTP قبل إرسال محتويات الرسالة. لا يقدّم هذا الأمر أي معلومات بحد ذاته، فيما عدا الإعلان عما سيرد تالياً. لكن لا يزال إخضاعه للفحوصات ممكناً.

مثال 11.10. التحقق من DATA

smtpd_data_restrictions = reject_unauth_pipelining

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

11.1.3.6. تطبيق القيود

رغم أن الأوامر السابقة تتحقق من المعلومات في المراحل المختلفة من عملية تبادل SMTP، إلا أن Postfix يرسل الرفض الفعلي كردٍّ على الأمر RCPT TO.

هذا يعني أنه حتى لو رفضت الرسالة نتيجة أمر EHLO خاطئ، سيعلم Postfix من هو المرسل ومن المستقبل عند إعلان الرفض. ويستطيع عندها تسجيل رسالة أوضح في السجلات وهذا غير ممكن إذا قوطعت عملية التبادل منذ البداية. بالإضافة لذلك، لا يتوقع بعض عملاء SMTP إخفاق عملية التبادل عند أوامر SMTP الأولية، وسيقل تشوش هذه العملاء عند استلام الرفض في وقت متأخر.

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

11.1.3.7. الترشيح اعتماداً على محتويات الرسالة

لن يكتمل نظام التقييد والتحقق دون طريقو لتطبيق الفحوضات على محتويات الرسائل. يفرق Postfix بين الفحوصات المطبّقة على ترويسات البريد الإلكتروني من تلك التي تطبق على متن (body) الرسالة.

مثال 11.11. تفعيل المرشحات التي تعتمد على المحتوى

header_checks = regexp:/etc/postfix/header_checks
body_checks = regexp:/etc/postfix/body_checks

يحوي كل ملف قائمة من التعابير المنتظمة (تعرف عادة باسم regexps أو regexes) والإجراءات المرتبطة معها التي تنشط عند مطابقة ترويسات الرسالة (أو متنها) للتعبير المنتظم:

مثال 11.12. مثال عن الملف /etc/postfix/header_checks

/^X-Mailer: GOTO Sarbacane/ REJECT I fight spam (GOTO Sarbacane)
/^Subject: *Your email contains VIRUSES/ DISCARD virus notification

أساسيات التعابير المنتظمة

يشير المصطلح ”تعبير منتظم“ (regular expression، ويختصر إلى regexp أو regex) إلى صيغة تدوين عامة لتمثيل محتويات أو بنية سلسلة من المحارف. تسمح بعض المحارف الخاصة بتعريف بدائل (مثلاً، foo|bar تطابق إما ”foo“ أو ”bar“)، أو مجموعات من المحارف المسموحة (مثلاً، [0-9] تعني أي رقم، و . (نقطة) تعني أي محرف)، أو كميات (تطابق s? إما s أو السلسلة الفارغة، أي ورود الحرف s مرة واحدة أو عدم وروده أبداً؛ أما s+ فيطابق ورود s مرة واحدة أو أي عدد من المرات؛ وهكذا). تسمح الأقواس بتجميع نتائج البحث.

تختلف صيغة كتابة هذه التعابير بين الأدوات التي تستخدمها، لكن المزايا الأساسية متشابهة.

→ http://en.wikipedia.org/wiki/Regular_expression

يتحقق الأول من الترويسة التي تذكر برنامج البريد الإلكتروني؛ فإذا وجدت العبارة GOTO Sarbacane (برنامج لإرسال البريد بالكميات)، سوف ترفض الرسالة. يتحكم التعبير الثاني بموضوع الرسالة؛ فإذا كان يذكر تحذيراً من فيروس، يمكننا ألا نرفض الرسالة ولكن نحذفها مباشرة بدلاً من ذلك.

استخدام هذه المرشحات سيف ذو حدين، لأنه يسهل بناء قواعد عامة جداً وخسارة رسائل مشروعة نتيجة لذلك. في هذه الحالات، لن نخسر الرسائل وحسب، بل سيحصل مرسلوا هذه الرسائل على رسائل أخطاء غير مرغوبة (ومزعجة غالباً).

11.1.4. إعداد القوائم الرمادية

“القوائم الرمادية“ (Greylisting) هي تقنية ترشيح تعتمد على رفض الرسالة في البداية مع الرد برمز خطأ مؤقت، وقبولها إذا أعيدت محاولة إرسالها ثانية بعد بعض الوقت. هذه التقنية فعالة خصوصاً لترشيح الرسائل الدعائية التي ترسلها العديد من الجهزة المصابة بالديدان والفيروسات، لأن هذه البرمجيات نادراً ما تتصرف كعميل SMTP كامل؛ فهي لا تتحقق من رمز الخطأ وتحاول إعادة إرسال الرسائل التي فشل إرسالها لاحقاً، خصوصاً وأن معظم العناوين المحصودة غير صحيحة أصلاً وإعادة محاولة الإرسال لا تعني إلا خسارة الوقت.

لا يدعم Postfix القوائم الرمادية داخلياً، لكن هناك ميزة تسمح بتوكيل برنامج خارجي لاتخاذ قرار قبول أو رفض رسالة معينة. هناك برنامج كهذا في الحزمة postgrey، مصمم ليرتبط مع خدمة توكيل سياسة القبول.

بعد تثبيت postgrey، سوف يعمل كخدمة وينصت للمنفذ 10023. يمكن عندها ضبط Postfix لاستخدامه، بإضافة المتغير check_policy_service كقيد إضافي:

smtpd_recipient_restrictions = permit_mynetworks,
    [...]
    check_policy_service inet:127.0.0.1:10023

في كل مرة يصل فيها Postfix لهذه القاعدة، سيتصل بخدمة postgrey ويرسل لها معلومات تخص الرسالة المعنية. ينظر Postgrey بدوره إلى ثلاثية (عنوان IP، المرسل، المستقبل) ويتحقق من رؤيته لهذه الثلاثية نفسها مؤخراً عبر قاعدة بياناته. إذا حدث ذلك، يرد Postgrey بأن الرسالة يجب أن تُقبَل؛ وإلا فإنه يرد بأن الرسالة يجب رفضها مؤقتاً، وتُسجَّل الثلاثية في قاعدة البيانات.

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

ممارسة عملية عيوب القوائم الرمادية

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

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

لتخفيف هذه الأضرار، يدير Postgrey قائمة بيضاء بهذه المواقع، ويقبل الرسائل التي ترد منها فوراً. يمكن ملائمة هذه القائمة مع الاحتياجات المحلية بسهولة، إذ أنها مخزنة في الملف /etc/postgrey/whitelist_clients.

التعمق أكثر الاستخدام الانتقائي للقوائم الرمادية باستخدام milter-greylist

يمكن تخفيف أضرار القوائم الرمادية باستخدامها فقط على مجموعة جزئية من العملاء الذي اعتبروا كمصدر للرسائل الدعائية مسبقاً (لأنهم مذكورون في قائمة DNS سوداء). هذا غير ممكن في postgrey ولكن يمكن استخدام milter-greylist بهذه الطريقة.

في تلك الحالة، يصبح استخدام القوائم السوداء الصارمة حلاً منطقياً، بما فيها القوائم التي تذكر جميع عناوين IP الديناميكة التابعة لعملاء ISP ما (مثل pbl.spamhaus.org أو dul.dnsbl.sorbs.net)، لأن قوائم DNS السوداء لن تسبب رفضاً قاطعاً.

بما أن milter-greylist يستخدم واجهة milter القياسية الخاصة ببرنامج Sendmail، يقتصر إعداد Postfix لاستخدامه على ”smtpd_milters = unix:/var/run/milter-greylist/milter-greylist.sock“. تشرح صفحة الدليل greylist.conf(5)‎ الملف /etc/milter-greylist/greylist.conf والطرق العديدة لإعداد milter-greylist. ستحتاج أيضاً لتحرير الملف /etc/default/milter-greylist لتفعيل الخدمة.

11.1.5. تخصيص المرشحات حسب المستقبل

عرض قسم 11.1.3, “قيود الاستقبال والإرسال” وقسم 11.1.4, “إعداد القوائم الرمادية” عدة قيود متاحة للاستخدام. لكل منها فائدته في الحد من كمية الرسائل الدعائية المستقبلة، لكن لكل منها عيوبه أيضاً. ولذلك يتزايد انتشار تخصيص مجموعة المرشحات اعتماداً على المستقبل أكثر فأكثر. في شركة فلكوت، تنفع القوائم الرمادية معظم المستخدمين، لكنها تعيق عمل بعض المستخدمين الذين يحتاجون وصول رسائلهم بتأخير قصير (مثل خدمة الدعم الفني). كما تعاني خدمة التجارة أحياناً من مشاكل في استلام ردود بعض المزودين الآسيويين لأنهم مذكورين في القوائم السوداء؛ وقد طلبت هذه الخدمة عنواناً دون ترشيح حتى يتمكنون من التواصل معهم.

يقدم Postfix ميزة تخصيص للمرشحات عبر مفهوم ”فئات التقييد restriction class“. يصرح عن الفئات في المتغير smtpd_restriction_classes، وتُعرَّف بنفس أسلوب smtpd_recipient_restrictions. بعدها تحدد التعليمة check_recipient_access جدولاً يقابل بين المستقبل المحدد ومجموعة القيود المناسبة.

مثال 11.13. تعريف فئات التقييد في main.cf

smtpd_restriction_classes = greylisting, aggressive, permissive

greylisting = check_policy_service inet:127.0.0.1:10023
aggressive = reject_rbl_client sbl-xbl.spamhaus.org,
        check_policy_service inet:127.0.0.1:10023
permissive = permit

smtpd_recipient_restrictions = permit_mynetworks,
        reject_unauth_destination,
        check_recipient_access hash:/etc/postfix/recipient_access

مثال 11.14. الملف /etc/postfix/recipient_access

# Unfiltered addresses
postmaster@falcot.com  permissive
support@falcot.com     permissive
sales-asia@falcot.com  permissive

# Aggressive filtering for some privileged users
joe@falcot.com         aggressive

# Special rule for the mailing-list manager
sympa@falcot.com       reject_unverified_sender

# Greylisting by default
falcot.com             greylisting

11.1.6. التكامل مع مضاد فيروسات

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

اختار مديرو النظم في شركة فلكوت clamav كمضاد فيروسات مجاني. الحزمة الرئيسية هي clamav، لكنهم ثبّتوا أيضاً حزماً إضافية مثل arj، وunzoo، وunrar وlha، لأن مضاد الفيروسات يحتاجها حتى يتمكن من تحليل المرفقات المضغوطة بإحدى هذه الصيغ.

يتولى clamav-milter مهمة الوصل ما بين مضاد الفيروسات وبين مخدم البريد الإلكتروني. الملتر (milter، اختصار mail filter) هو برنامج ترشيح مصمم خصيصاً للتواصل مع مخدمات البريد الإلكتروني. يستخدم الملتر واجهة برمجية تطبيقات (API أو application programming interface) تعطي أداءً أفضل بكثير من المرشحات الخارجية. قدم Sendmail الملاتر أول مرة، لكن سرعان ما لحق Postfix به.

فور تثبيت الحزمة clamav-milter، يجب إعادة ضبط الملتر ليعمل على منفذ TCP بدلاً من استخدام المقبس الشبكي المسمّى الافتراضي. يمكن تنفيذ ذلك باستخدام dpkg-reconfigure clamav-milter. عند طلب ”Communication interface with Sendmail“، أجب عليه بإدخال ”inet:10002@127.0.0.1“.

ملاحظة منفذ TCP حقيقي أو مقبس مسمّى

سبب استعمالنا لمنفذ TCP حقيقي بدلاً من مقبس شبكي مسمّى هو أن خدمات Postfix تعمل تحت جذر مختلف (chrooted) غالباً ولا يمكنها الوصول للمجلد الذي يحوي المقبس المسمّى. يمكنك أيضاً أن تختار استخدام مقبس مسمّى لكن مع اختيار موقع ضمن الجذر المغيّر إليه (وهو /var/spool/postfix/).

تناسب إعدادات ClamAV القياسية معظم الحالات، لكن لا يزال تخصيص بعض البارامترات المهمة ممكناً عبر dpkg-reconfigure clamav-base.

الخطوة الأخيرة هي أن نطلب من Postfix استخدام المرشح الجديد؛ لتحقيق ذلك، يكفي إضافة التعليمة التالية إلى /etc/postfix/main.cf:

# Virus check with clamav-milter
smtpd_milters = inet:[127.0.0.1]:10002

إذا سبب مضاد الفيروسات مشاكل، يمكن تعليق هذا السطر، وبعدها تنفيذ service postfix reload حتى يؤخذ هذا التغيير بعين الاعتبار.

ممارسة عملية اختبار مضاد الفيروسات

فور إعداد مضاد الفيروسات، يجب اختبار سلامة سلوكه. أبسط طريقة هي إرسال رسالة اختبار وإرفاق الملف eicar.com (أو eicar.com.zip) بها، يمكن تنزيل هذا الملف من الإنترنت:

→ http://www.eicar.org/86-0-Intended-use.html

هذا الملف ليس فيروساً حقيقياً، لكنه ملف اختبار تعتبره جميع برامج مكافحة الفيروسات في السوق فيروساً لاستخدامه في اختبار صحة عملية التثبيت.

ستمر جميع الرسائل التي يعالجها Postfix الآن عبر مرشح مكافحة الفيروسات.

11.1.7. SMTP مع مصادقة

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

تعتمد مصادقة SMTP في Postfix على SASL‏ (Simple Authentication and Security Layer). هذا يتطلب تثبيت الحزمتين libsasl2-modules وsasl2-bin، ثم تسجيل كلمة سر في قاعدة بيانات SASL لكل مستخدم يحتاج المصادقة مع مخدم SMTP. هذا يتم بوساطة الأمر saslpasswd2، الذي يأخذ عدة بارامترات. يحدد الخيار -u نطاق المصادقة، الذي يجب أن يطابق المتغير smtpd_sasl_local_domain في إعدادات Postfix. يسمح الخيار -cبإنشاء مستخدم، ويسمح -f بتحديد الملف الذي تريد استخدامه لتخزين قاعدة بيانات SASL إذا كنت تريد تخزينها في مكان مختلف عن المكان الافتراضي (/etc/sasldb2).

# saslpasswd2 -u `postconf -h myhostname` -f /var/spool/postfix/etc/sasldb2 -c jean
[... type jean's password twice ...]

لاحظ أن قاعدة بيانات SASL قد أنشئت في مجلد Postfix. لضمان التوافق، سوف نجعل /etc/sasldb2 أيضاً رابطاً رمزياً يشير إلى قاعدة البيانات التي يستخدمها Postfix، باستخدام الأمر ln -sf /var/spool/postfix/etc/sasldb2 /etc/sasldb2.

نحتاج الآن إعداد Postfix بحيث يستخدم SASL. أولاً يجب إضافة المستخدم postfix إلى المجموعة sasl، حتى يستطيع الوصول لقاعدة البيانات التي يملكها حساب SASL. كما نحتاج لبضعة بارامترات جديدة لتفعيل SASL، ويجب ضبط المتغير smtpd_recipient_restrictions للسماح للعملاء الذين صادقوا هويتهم باستخدام SASL بإرسال البريد الإلكتروني دون قيود.

مثال 11.15. تفعيل SASL في /etc/postfix/main.cf

# Enable SASL authentication
smtpd_sasl_auth_enable = yes
# Define the SASL authentication domain to use
smtpd_sasl_local_domain = $myhostname
[...]
# Adding permit_sasl_authenticated before reject_unauth_destination
# allows relaying mail sent by SASL-authenticated users
smtpd_recipient_restrictions = permit_mynetworks,
    permit_sasl_authenticated,
    reject_unauth_destination,
[...]

إضافة عميل SMTP مع مصادقة

تستطيع معظم عملاء البريد الإلكتروني المصادقة مع مخدم SMTP قبل إرسال الرسائل الصادرة، ولاستخدام تلك الميزة يكفي ضبط المتغيرات المناسبة. إذا كان العميل المستخدم لا يدعم هذه الميزة، فالحل هو استخدام مخدم Postfix محلي وضبطه بحيث يرحل البريد الإلكتروني إلى مخدم SMTP البعيد. في تلك الحالة، يصبح مخدم Posfix المحلي نفسه عميلاً يجري عملية المصادقة باستخدام SASL. إليك المتغيرات اللازمة:

smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
relay_host = [mail.falcot.com]

يجب أن يحوي الملف /etc/postfix/sasl_passwd اسم المستخدم وكلمة السر التي ستستخدم عند المصادقة مع المخدم mail.falcot.com. هذا مثال:

[mail.falcot.com]   joe:LyinIsji

كما هو حال جميع جداول التقابلات في Postfix، يجب تحويل هذا الملف إلى /etc/postfix/sasl_passwd.db باستخدام الأمر postmap.