OpenBSD 7.7 كقاعدةٍ متينةٍ لجدارٍ ناري: pf.conf و sysctl.conf يقفان في صفّك

يشتهر OpenBSD منذ سنواتٍ بروحِه الأمنية غير القابلة للمساومة: افتراضاتٌ معقولة، شيفرةٌ نظيفة، وعبارة «secure by default» بوصفها التزامًا عمليًا لا شعارًا دعائيًا. إذا كنت تريد جدارًا ناريًا موثوق السلوك يسهل تفسيره في التشغيل اليومي، فـOpenBSD يوفّر أساسًا قويًا. وفي الوقت نفسه، ورغم أن الافتراضات القوية رائعة، فإن بضع ضبطياتٍ مقصودة كفيلةٌ برفع مستوى الأمان وقابلية التنبؤ بشكلٍ واضح—من دون تحويل نظامك إلى مختبرٍ هشّ.
يهدف هذا المقال إلى تقديم خطّ أساسٍ عملي يحمي بثقة الشبكات الصغيرة، ومختبرات المنزل، وبيئات الشركات الصغيرة والمتوسطة، مع الحفاظ على القراءة السلسة وسهولة الصيانة.

بدل القوائم التي لا تنتهي و«نصائح الضبط» الاعتباطية، ستجد هنا قراراتٍ مبرّرة مع أسبابٍ واضحة: لماذا نفعّل خيارًا معيّنًا، أيّ مخاطر يعالجها، وما الآثار الجانبية التي ينبغي تذكّرها. الهدف ليس تغطية كل سيناريو هجومٍ نظري؛ بل منحك نقطة انطلاقٍ موثوقة: قواعد رشيقة، استثناءات قليلة، وسلوك واضح.

هذا الدليل يتّبع خطًّا واضحًا: اسمح صراحةً، واحجب ما عدا ذلك. من الخارج إلى الداخل لا يُسمَح إلا بما يحتاجه الموجِّه نفسه؛ ومن الداخل إلى الخارج لا يمرّ إلا ما تريد أنت مروره فعلًا. نبقي DNS مرئيًا وقابلًا للتحكّم. لا نعطي DoH وDoT وDoQ وQUIC أي مخارج صامتة حتى لا تظهر «قنواتٌ غير مرئية». تُربَط الحالات (states) عن قصد بواجهات الشبكة ليبقى الاتصال حيث نشأ. هذا يجعل النظام قابلًا للتنبؤ ويجعل استكشاف الأخطاء محتمَلًا. ولأن الشفافية أثمن من عشرة حِيَل، تحمل كلّ المسارات الحرِجة وسومًا (labels): سترى أثناء التشغيل فورًا ما الذي يمرّ، وما الذي يُمنَع، وأين تحتاج إلى تشديدٍ أكثر.

ولإبقاء الأمور ملموسة، نقدّم اثنين من ملفات pf لتختار بينهما: نسخة موجِّه فقط (router‑only) لسيناريوهات LAN↔الإنترنت الكلاسيكية، ونسخة موجِّه+DMZ (router+DMZ) عندما تريد عزل الخدمات. نحن نفرض على عملائك استخدام DNS إلى 1.1.1.1 (وممكن 1.0.0.1 كبديل اختياري). هذا ليس تدقيقًا لفظيًا، بل قرارٌ معماري واعٍ: تستعيد بذلك الرؤية والتحكّم. إن أراد تطبيقٌ ما شيئًا آخر فسوف يظهر للعيان، وعندها تقرّر بوعي إن كنت ستمنح استثناءً وأين.

يُكمل sysctl.conf هذه الذهنية على مستوى النواة. يأتي OpenBSD بكثيرٍ من الافتراضات القوية، لكن بعض المفاتيح تمنح مكاسب ملموسة في الصلابة: إعداد malloc متين يجعل أخطاء الذاكرة الكلاسيكية تفشل أبكر وبصوتٍ أعلى؛ تعطيل SMT/Hyper‑Threading عندما لا يعود نفعٌ يُذكر أمام مخاطر قنواتٍ جانبية؛ W^X يُنهي العمليات بدل تركها تعمل في مناطق رمادية خطرة؛ تعطيل إعادة التوجيه والأنفاق غير الضرورية؛ خيارات TCP حديثة وحدود معدّلة لمعدّلات الإرسال تخفّف «ضجيج الشبكة» من دون كسر الوظائف الشرعية. ليست هذه «حِيَلًا» لافتة للنظر، بل نظافة منهجية: تقليل سطح الهجوم، تقليل المفاجآت، وسلوك أكثر ثباتًا تحت الضغط.

لا يشمل نطاق هذا المقال الهجمات الموجّهة عالية التخصيص أو نُصُب IDS/IPS كاملة. إن أردت مراقبةً متعددة الطبقات، أو فحصًا عميقًا للبروتوكولات، أو خلاصات استخبارات تهديدات، فلن تُعيقك هذه التهيئة؛ بل هي الأساس الذي تبني عليه تلك اللبنات لاحقًا بهدوء. كما أننا نتجاهل عمدًا سياسات multi‑WAN المعقّدة، ومشاهد تحويل المنافذ المتشعبة، وشبكات overlay الغريبة. كل ذلك ممكن، لكن ليس من دون تشويش وضوح خط الأساس.

اختيارنا للقراءة السلسة يعني أيضًا تفضيل الآلية المفهومة على السحر. NAT ثابت حيث تفيد الثباتَ بروتوكولات الوقت الحقيقي، وديناميكي حيث لا فرق. نحجب QUIC كي لا يختبئ DNS داخل تدفّقات TLS. IPv6 محجوب افتراضيًا تفاديًا لـ«IPv6 نصف المفتوح» (يفضله العملاء بينما الجدار لا يضبطه). ستجد لاحقًا خطواتٍ نظيفة لتفعيل IPv6 بصورة صحيحة إن احتجته. وحيثما يفيد ذلك، نضع وسومًا على الحالات الحدّية—ليس لتلوين السجلات، بل للحصول على إجابات: من حاول التحدّث DoT؟ أيُّ مضيفين اصطدموا بقاعدة anti‑rebind؟ ما الذي يثير حظر الخروج (egress)؟

لِمَن هذا؟ لك إذا كنت ترى الإدارة حِرفة وتفضّل استثمار ساعةٍ في قاعدةٍ نظيفة على مطاردة آثارٍ جانبية لثلاثة أسابيع. لك إذا أردت فهم شبكتك بدل أن تفاجئك سماحياتٌ افتراضية. ولك أيضًا إذا كنت «بين كرسيَّين»: لست كبيرًا بما يكفي لطاقم SOC/Blue‑Team، لكنك أرفع مطلبًا من «موجّهٍ من المتجر». خطّ الأساس هذا ليس خدعة، بل معيارٌ معقول—صغيرٌ بما يكفي لإتقانه، وثابتٌ بما يكفي للاحتفاظ به طويلًا.

نموذج التهديد: ما الذي ندافع ضده—وما الذي لا

هذا الخطّ موجّهٌ لبيئات لا تملك فريقًا أزرق مخصّصًا لكنها تريد معايير موثوقة. يحميك من الأشياء المعتادة التي تضرب حدّك يوميًا: عمليات مسحٍ واسعة، واستغلالاتٍ انتهازية، وسوء استخدام البروتوكولات («DNS فوق كل شيء»)، والإعدادات الخاطئة، وسياسات خروج (egress) مُفرِطة السماح تسهّل تسريب البيانات. يعزل خواديم اختيارية داخل DMZ ويمنع الحركة الجانبية إلى LAN. ولسنا هنا معنيين بالهجمات الموجّهة جدًا أو رُقَع IDS/IPS كاملة—يمكنك إضافتها لاحقًا على هذا الأساس.

مبادئ التصميم: سطح هجومٍ صغير ومسؤوليات واضحة

تتّبع التهيئة خطوطًا إرشادية تفيدك كذلك في التعديلات المستقبلية:

الفشل يؤدي للإغلاق (Fail‑closed). ما لم يُسمَح به صراحةً فهو محجوب—دخولًا وخروجًا. بهذه الطريقة تكتشف مبكرًا في اختبارك ما يحتاجه التطبيق فعليًا وتحافظ على زمام التحكّم.

حالاتٌ حتمية (Deterministic states). يجعل if-bound الاتصال مرتبطًا بواجهة نشأ عليها. على موجِّهات single‑WAN يضع هذا نهايةً لمطاردة «حالات طافية» سحرية ويسهّل الاستقصاء.

تقشُّف الخروج (Egress minimalism). من الداخل إلى الخارج يمرّ فقط اللازم فعلًا: الويب الكلاسيكي، إرسال البريد (submission)، نطاقات UDP محدّدة لـVoIP/WebRTC—وDNS فقط إلى الوجهة التي تحدّدها.

الشفافية بدل التخمين. نحجب QUIC وكذلك DoH/DoT/DoQ. نعم، هذا غير مريح لبعض التطبيقات. لكنّك تنال مقابل ذلك وضوحًا: DNS هو DNS، وTLS هو TLS. من يحتاج «DNS ظلّيًا» سيلفت الانتباه.

افتراضاتٌ متينة. scrubbing، حدّ MSS، معرفات IP عشوائية، مرشّحات bogons، Anti‑spoofing، نظافة أعلام TCP، وحدود منطقية لـICMP وRST. لا شيء من هذا مبهر منفردًا—لكن معًا هي نظافة صلبة.

IPv6 عن قصد. IPv6 مُعطّل افتراضيًا. إن أردته ستجد لاحقًا مسارًا نظيفًا لتفعيله. نتجنّب بإصرار «IPv6 نصف المفتوح».

‎sysctl.conf — روافع أمانٍ على مستوى النواة تستحق العناء

يُقدّم OpenBSD افتراضاتٍ ممتازة، لكن قليلًا من الإعدادات يرفع بشكلٍ بيّن الأمان وقابلية التنبؤ. إليك الأهم—من دون قوائم لا تنتهي، مع أسبابٍ واضحة:

تحصين الذاكرة (vm.malloc_conf=CFGJRS). Guard pages، وأنماط junk، وred‑zones، وcanaries تصعّب استغلال أخطاء الذاكرة الكلاسيكية وتجعل العمليات تفشل «بصوتٍ عالٍ» بدل أن تفسد في الخفاء. الكلفة البسيطة تستحق ذلك في معظم سيناريوهات الموجِّه.

المعالج/العتاد: إطفاء SMT وإغلاق aperture. يخفّض hw.smt=0 مخاطر القنوات الجانبية (Hyper‑Threading)؛ وعلى الموجِّهات يكون الأثر على الأداء ضئيلًا غالبًا. يُغلِق machdep.allowaperture=0 طرق /dev/mem المختصرة؛ وهذا مثالي لعُدَّةٍ بلا شاشة. إن احتجت X11/KMS فأنت تعرف ما تفعل—وإلا فـدعها مغلقة.

التوجيه والبروتوكولات: تفعيل IPv4 وتعطيل IPv6 عن قصد. يحوّل net.inet.ip.forwarding=1 عقدتك إلى موجّه IPv4. يمنع net.inet6.ip6.forwarding=0 التوجيه «العرضي» لـIPv6. كما نعطّل أنفاقًا غير لازمة (IP‑in‑IP وGRE وESP/AH وEtherIP). كلما قلّت ماكينة التشفير/التغليف قلّ سطح الهجوم والمفاجآت.

تفكيك ألغامٍ تراثية. تعطيل البثّ الموجّه (directed broadcast) وتجاهل إعادة التوجيه (IPv4/IPv6). تُعدّ إعادة توجيه ICMP فخًا كلاسيكيًا؛ إن أردت تغيير المسارات فافعل ذلك صراحةً في التوجيه أو PF لا بطرقٍ ملتوية.

ICMP بعينٍ واعية. لا نردّ على broadcast echo، ولا على timestamp/netmask؛ وتُقيَّد حزم الخطأ بمعدّلٍ منطقي. هذا يُخمِد ضجيج DDoS من دون كسر وظائفٍ شرعية. ICMP ليس عدوًا، لكنه يحتاج حواجز حماية.

تحصين UDP/TCP بلا شعوذة. Checksums UDP إلزامية؛ وحجوم مخدّمات socket معقولة تمنع خسائر مزعجة. في TCP نُبقي على الميزات الحديثة (window scaling وtimestamps وSACK) لتثبيت الأداء. نفعّل ECN؛ نادرًا ما يسبّب مشاكل اليوم ويفيد تحت الضغط. حدود SYN cache/bucket وحدود معدّل RST تمتص موجات المسح المعتادة.

الطوابير وBPF وW^X. طابور if أطول يقلّل الإسقاطات عند الذروات. حواجز BPF أكبر هديةٌ لك أثناء التصحيح. يفرض kern.wxabort=1 سياسة W^X: الذاكرة إمّا قابلة للكتابة أو للتنفيذ، لا كليهما. المخالفة تُنهي العملية—fail‑closed كما نريد. ويظلّ تشفير swap مفعّلًا كي لا تسقط البقايا الحساسة على القرص نصًّا صريحًا.

هذه المجموعة من sysctl متعمّدٌ بساطتُها. تنقل الأداء من «يعمل غالبًا» إلى «يتصرّف بثباتٍ حتى تحت الضغط». حمّلها نظيفًا عبر sysctl -f، وافحص بعض العدّادات (sysctl -n net.inet6.icmp6.errppslimit، وnetstat -m، وpfctl -s memory). وإن عدّلت ميزانيات mbuf/cluster فاذكر أن تعدّل حدود PF مثل set limit frags.

‎pf.conf: قواعد يمكنك شرحها

يوفّر pf إمكاناتٍ لا تنتهي. يأخذ خطّ الأساس هذا قدر ما يلزم فقط لتأسيس معايير متينة—لا أكثر ولا أقل.

الماكرو والجداول والوسوم—نصف النجاح هو البنية. ابدأ بتحديدٍ واضح للواجهات والشبكات: WAN وLAN و—في نسخة DMZ—‏DMZ. أضِف جداول لـbogons وabusers وscanners وقائمة مراقبة (watchlist) لنهايات DoH مشبوهة. ليست هذه للزينة: بـpersist تبقى عبر إعادة التحميل، ومع overload تدخل المصادر الصاخبة تلقائيًا. الوسوم المتّسقة على القواعد تمنحك رؤية تشغيلية ممتازة من دون pcap ثقيل: يخبرك pfctl -vvsr أو systat pf أين «ينبض» المرور.

خيارات عامة—سلوك متوقّع. set block-policy drop والتحسين «aggressive» افتراضات محافظة معقولة. يربط set state-policy if-bound الاتصالات بواجهة الدخول. نحدّد الحدود للحالات والتجزئة والعُقد المصدرية، ونفعّل المهل الزمنية التكيفية، وsyncookies بشكلٍ تكيفي—وتفيد حين تعلو الأمواج. يعرض loginterface إحصاء WAN؛ ويمنع set skip on lo0 «إطلاق النار على القدم».
في pf يكون IPv6 محجوبًا افتراضيًا، انسجامًا مع sysctl، لدرء «IPv6 نصف المفتوح». إذا أردته، فافتحه عن قصدٍ وبوضوح.

ICMP داخِل WAN: مفتوحٌ بقدرٍ يكفي للصحة. على واجهة WAN نسمح echo و«unreachable»—بحالاتٍ تتبُّعية وحدّ معدّل. هذا يقوّي التشخيص (كيف ستكشف مشاكل MTU/المسار خلاف ذلك؟) ويحمي من فيضانات ping. أما البقية—وخاصةً إعادة التوجيه—فمطفأة.

Scrubbing: شظايا أقل، إحباط أقل. ننظّف في الاتجاهين: معرفات IP عشوائية، وTTL أدنى محافظ، وMSS=1440 (قيمة سليمة ميدانيًا)، وإعادة تجميع TCP. يمنع ذلك الشظايا المشبوهة من سدّ الحالات ويقلّل تعثّر PMTU. وعندها نادرًا ما تحتاج إلى لمس MSS عبر sysctl.

NAT: ساكن حيث يهم الزمن الحقيقي؛ ديناميكي حيث لا يهم. تمنح UDP منافذ ثابتة—ذهبٌ لبرامج VoIP/WebRTC والألعاب والعديد من بروتوكولات الزمن الحقيقي. أما الباقي فيمضي عبر نطاق ephemeral مرتفع ليسهُل إسناد الخروج في الالتقاطات وتجنّب التصادم. ينطبق NAT على كل شيء ما عدا أهداف إدارةٍ محدّدة صراحةً—لا مسارات مفاجِئة.

Anti‑spoofing وbogons و«منفذ صفر». يراقب antispoof كل الواجهات ذات الصلة. ما يأتي إلى WAN بمسار مصدرٍ مكسور يُرفَض مبكرًا. نحجب bogons دخولًا وخروجًا؛ فالمرور من 10/8 أو 127/8 نحو الإنترنت غالبًا علامةٌ على مشكلةٍ أخرى. كما ننظّف المنفذ 0 وأعلام TCP غير المعقولة—ليست علوم صواريخ، لكنها توفر عناء مع ماسحاتٍ «مبدعة».

الحجب افتراضيًا: الكنس الكبير. بعد النظافة يأتي القطع الحاد: block all. من هنا تبدأ الاستثناءات الواعية فقط.

الدخول عبر WAN: فقط ما يحتاجه الموجِّه نفسه. نسمح بدخول DHCP إن تطلّبه المُزوِّد upstream. ثم basta. DMZ عامة قابلة للوصول من الإنترنت ليست غاية هذا الخط؛ إن احتجتها فعرّف تحويلات منافذ—وباقتصاد.

QUIC: يبقى HTTP/3 في الخارج. نحجب UDP 80/443 على WAN؛ فيختنق QUIC. لِمَ الصرامة؟ لأن QUIC نفقٌ مريح—حتى لتنويعات DoH وحِيَل «كل شيء في تدفّق واحد». إن احتجت لاحقًا HTTP/3 لهدفٍ محدّد (وأنت تعرف لماذا) فافتح استثناءً جراحيًا. يُقدّم خط الأساس الشفافية على السرعة.

رؤية لـDoH/DoT/DoQ—بحدود واضحة. DoT (853/TCP) وDoQ (784/UDP) محجوبان خروجًا ومُسجّلان دخولًا. داخل LAN/DMZ نُوسِم اتصالات TLS إلى مُضيفي DoH معروفين—من دون تغيير السياسة إلا إن اخترت النسخة الصارمة. الفكرة: ترى متى يحاول العملاء DNSً مخفيًا.

وصولٌ إداري إلى الجدار: ضيّق ومع تخفيض السرعة. نسمح SSH من LAN إلى الجدار مع state ونظافة أعلام وحدّ معدّلٍ لطيف. لمسارات إدارةٍ upstream (مثل واجهة مودم/موجّه) نمنح تمريرات مركّزة؛ حدود المعدّل تُلطّف الرشّ والنقرات الخاطئة. تُبقي الوسوم هذه المسارات واضحة.

سياسة DNS بلا محلّلٍ محلّي: الإلزام لا التمنّي. النقطة المحورية: عملاء LAN (وDMZ إن وُجدت) لا يُسمَح لهم إلا بـ1.1.1.1، و1.0.0.1 اختياريًا على المنفذ 53/TCP+UDP. أي شيءٍ آخر نحو 53 محجوبٌ ومُسجّل. هذه ليست رفاهيةً—بل جوهر الرؤية. سترى فورًا محاولات استعمال محلّلات أخرى—أو DoH/DoT/DoQ التي تُحجَب على حدة. ويمكنك تبديل المُحلِّل الخارجي متى شئت؛ الآلية ثابتة.

DMZ: لا أبواب جانبية ولا طرق مختصرة. في نسخة DMZ لا تواصل داخل DMZ، ولا عودة إلى LAN؛ وتُفتَح فقط ممرّات خروج محدّدة للخدمات المقيمة هناك (ويب كلاسيكي، إرسال بريد، نطاقات UDP لـVoIP/WebRTC). الوصول من DMZ إلى أي واجهة إدارةٍ upstream ممنوع؛ كي لا يمسّ خادمٌ مخترق شبكتك الإدارية. كل ما عدا ذلك محجوبٌ ومُسجّل لتجد بسرعة «البرغي المفقود».

تخفيف مخاطر الخروج: أغلق الكلاسيكيات أوّلًا. إلى الخارج نحجب المشتبه بهم المعتادين: ‏SMB/NetBIOS وRPC/NFS وTFTP وSNMP وRDP/VNC/WinRM وSMTP الانتهازي. لكلٍّ مكانه داخل الشبكة أو على مساراتٍ محدّدة؛ أما الإنترنت فـلا افتراضيًا. إن احتجت استثناءً فعرّفه بوعي—ومع وسم.

الجدار نفسه: يخرج، لكن مرئيًا. نسمح للجدار بالوصول إلى الإنترنت—بحالاتٍ وحدودٍ ووسوم—للتحديثات والحِزم والتشخيص. لا تُفرِط: هذه العلبة موجّهٌ وحارس، لا طرف تصفّح.

Anti‑rebind وLAN→DMZ والتنظيف الكبير. بين LAN وDMZ لا نسمح إلا بمساراتٍ صريحة (مثل العملاء إلى خدمةٍ في DMZ)، ويبقى الرجوع مغلقًا. تمنع قواعد anti‑rebind بلوغ أهدافٍ داخلية محمية بخدع DNS عبر الجدار. وفي غير ذلك، يقول PF «لا» بوضوح—وبـreturn حيث يفيد فشلٌ سريع في التشخيص.

موجّه فقط أم موجّه+DMZ: أيّهما يناسبك؟

إن أردت وصل LAN بالإنترنت فقط، فنسخة موجّه فقط مثالية: مضغوطة وواضحة ومتحصّنة. تنال Anti‑spoofing ومرشّحات bogons وسياسة خروج صارمة وفرض DNS نحو 1.1.1.1/1.0.0.1، والتحكّم في DoH/DoT/DoQ/QUIC، وSSH إداريًا من LAN إلى الجدار، وافتراضات مرتّبة لـscrub والحالات والحدود.

ما إن تستضيف خدمات—حتى لو كانت داخلية فقط—تصير موجّه+DMZ منطقيّة. تحتوي DMZ الأعطال وتقلّل احتمال أن يصبحَ خدمةٌ مخترقة منصّة قفزٍ إلى LAN. الاتصالات داخل DMZ مغلقة؛ والخروج بنمط قائمة بيضاء وأشدّ ضيقًا من LAN. DNS صارمٌ بنفس القدر؛ وNTP يظلّ مغلقًا حتى تحتاجه حقًا.

تشغيل IPv6 بالطريقة الصحيحة

يحجب خط الأساس IPv6 كي لا يبقى شيء «نصف مفتوح». إن احتجت IPv6 ففعّله بصورةٍ متعمّدة ومتّسقة: توجيهٌ عبر sysctl، وقواعد inet6 مناظرة في pf، وخطة خروجٍ نظيفة (نعم، فرض DNS هنا أيضًا—لكن لـv6)، وقرارات واضحة حول RA/DHCPv6. اعكس أفكار v4 الجيدة: Anti‑spoofing، الحجب افتراضيًا، إدارة QUIC/DoH/DoQ، واستثناءات مرئية—لا أكثر ولا أقل. النصيحة الأهم: لا «تُهرّب» v6 بصمت. إن أردته فـافعلْه جيدًا؛ وإلا فليس بعد.

التشغيل والتشخيص والجنائيات: قِس ولا تُخمِّن

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

الوسوم. تحمل كل قاعدة مهمة وسمًا وصفيًا. في pfctl -vvsr سترى المسارات المستخدمة والمحجوبة وأين يحدث الاصطدام. يكفي هذا غالبًا لتضييق المشكلة.

الجداول. بـpfctl -t <table> -T show تقرأ مدخلات abusers/scanners. يملأ overload هذه الجداول تلقائيًا عندما يفتح العملاء اتصالاتٍ مفرطة. ليست عقوبةً؛ بل حزام أمان.

أقل قدرٍ من pcap. ‏tcpdump صديقك—لكن استخدمه لهدف. لضبط DNS/DoH تكفي لمحاتٌ قصيرة مثل:
tcpdump -n -e -ttt -i $wan 'port 53 or port 853 or (udp and port 784)'
هذه جنائياتٌ بخطة، لا «Wireshark حتى تدمع العينان».

طَقس اختبارٍ صحي. عند تغيير القواعد اسمح بالتحقق دون تحميل: ‏pfctl -nf /etc/pf.conf. ثم pfctl -f—وإن وقع خللٌ دلّتك الوسوم والجداول على التصحيح. للتحقق من فرض DNS: يجب أن ينجح drill @1.1.1.1 openbsd.org وأن يُحجَب drill @9.9.9.9 openbsd.org. ولـQUIC تحقّق أن curl -I --http3 https://example.com لا يسير عبر UDP وأنه يعود إلى HTTP/2. ولـDoT/DoQ: يجب أن تفشل المحاولات إلى ‎1.1.1.1:853 وUDP 784، وأن ترى عُدّادات الحجب على القواعد الموسومة.

تلميح لتعديلات الخروج. عندما تفتح شيئًا، وسِمْه مؤقّتًا بوسمٍ واضح جدًا وبعد أسبوعٍ تحقّق: هل استُخدِم حقًا؟ إن لا، فأزِله. هكذا يبقى خطّك رشيقًا.

أداء بلا أساطير

هذا التصميم ليس «على حدّ الشفرة»؛ بل مُعايَرٌ من أجل الاستقرار. إليك بعض النتائج المهمة:

قد يجعل حجب QUIC بعض المواقع أبطأ قليلًا. هذا تبادلٌ مقصود: الوضوح قبل السرعة. إن كانت لك أسبابٌ وجيهة للسماح بـHTTP/3 فافعل ذلك جراحيًا (أهداف في جدول، وسم، وانتهى).

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

‏منافذ NAT الثابتة لِـUDP هديةٌ لبروتوكولات الوقت الحقيقي. من اصطاد مشاكل WebRTC يعلم أنّها تساوي الذهب. لا تكلف شيئًا تقريبًا—سوى إدراك أن «عشوائية منفذ UDP» ليست ميزة أمان.

حجوم if‑queue وBPF buffers واقعية: فسحةٌ لتحمّل الذروات وجلسات تصحيح لا تختنق عند 4KB. إن أردت بلوغ أقصى إنتاجيةٍ حقًا، قِس ثم عدّل—لا العكس.

فِخاخ شائعة—وكيف تجتازها بأناقة

«تطبيقي لا يعمل إلا مع DoH!» إذن أنت بحاجة لاستثناء أو—أفضل—تقييمٍ صادق. DoH ليس شرًّا بذاته، لكنه يُضعف التحكّم في شبكات المنزل/الشركة. يمكنك السماح لمضيفين محدّدين ضمن جدول؛ أبقه استثناءً واعيًا لا فتحًا شاملًا.

«المكالمات الفيديوية تتقطّع». تحقّق أولًا أن نطاقات UDP لمزوّدك (Zoom/Teams/WebRTC) مغطّاة. منافذ UDP الثابتة تساعد، لكن من دون ممرّ خروجٍ مناسب لا جدوى. عدّل بدقة لا بعشوائية.

«عميل البريد لا يرسل مباشرة». صحيح: المنفذ 25 خروجًا محجوب. يجب إرسال البريد عبر submission (465/587) إلى مزوّدك/خادمك—لا مباشرةً إلى الإنترنت. إن لزم، اسمح بمنافذ submission—مع وسم.

«IPv6 تعطّل فجأة». في هذا الخط، v6 محجوب. إن فضّله العملاء والجدار لا يوجّهه ستظهر مهلاتٌ زمنية. إمّا تفعل v6 جيدًا (مع قواعده) أو تُعلِم العملاء عبر RA/ND بأن v6 غير متاحٍ بعد.

«غرائب بعد تعديل قاعدة». تذكّر الحالات (states). تبقى القديمة موجودة افتراضيًا. عند تغيير سياسةٍ جوهرية (مثل منفذ خروج جديد)، اقتل الحالات المعنية (pfctl -k ...) أو، عند الحاجة، افرغها جميعًا (pfctl -F state). بعدها يعود العالم متّسقًا.

لماذا هذا الخط «آمن»—وما معنى الأمان هنا

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

يُصغّر كلّ تعرّضٍ دخولي،

يجعل الخروج استثناءً لا قاعدة،

يفرض ويُبقي مرئيًا DNS،

يحجب المسارات المموّهة (QUIC/DoH/DoT/DoQ)،

يعطّل «وظائف» زائفة (إعادة التوجيه/البث)،

يطبّق افتراضات TCP/ICMP متينة،

يجعل إدارة الحالات حتمية،

ويزوّدك بأدواتٍ لـمراقبة الاستخدام يوميًا.

وفي الوقت نفسه تبقى التهيئة قابلة للصيانة. ليست «آمنة» لأنها 3000 سطر؛ بل لأنك تستطيع شرح كل سطر.

الانتقال: كيف تتقدّم

إن كنت قادمًا من تهيئة pf قائمة، فتقدّم على مراحل:

ابدأ بـsysctl. حمّل التحصينات التي لا تسقط الخدمات. راقب السجلات لضجيج ICMP/RST غير المألوف.

اختبر سياسة pf بجانبها. استخدم pfctl -nf ومختبرًا/نافذة صيانة. عند التفعيل الأول، احرص على وصول SSH من LAN إلى الجدار—لا شيء أسوأ من إغلاق الباب على نفسك.

شدّد الخروج. فعّل فرض DNS وراقب. ثم أغلق تدريجيًا الخدمات الكلاسيكية عالية المخاطر. أسبوع أو اثنان من المراقبة يساعدان في كشف النقاط العمياء.

أدخل DMZ (إن لزم). انقل الخدمات، وأبقِ intra‑DMZ وDMZ→LAN مغلقتين. افتح فقط مسارات الخروج الضرورية للغاية. راقب ثم صقِل.

احسم IPv6 بوعي. إما أن تفعّله كما ينبغي—أو تبقيه مطفأً وتُعلن ذلك للعملاء.

كل مرحلة ترفع الأمان من دون «انفجارٍ كبير» محفوف بالمخاطر.

ما يسهل توسيعه لاحقًا

خط الأساس هذا أساسٌ لا قفص. من التوسعات المألوفة:

استثناءات جراحية لـQUIC/DoH عندما تملك أسبابًا مُتحقّقة—دائمًا عبر جداول ووسوم.

‏VPN موقع↔موقع بأصغر سطح هجوم؛ افتراضات sysctl لا تعرقل إن سمحت بالبروتوكولات صراحة.

المراقبة/التنبيه. عدّادات pf و‏systat pf جيدة للمترِكات الأساسية. ولأكثر من ذلك أرسِل سجلات pf إلى نظامٍ مركزي.

IPv6، معكوسًا بالكامل لمنطق v4—لا كجسمٍ غريب.

الترقيات والصيانة

يفي OpenBSD بوعوده—لكن اقرأ ملاحظات الإصدار عند كل ترقية، خصوصًا حول صياغة pf وافتراضات النواة. تجعل الوسوم والجداول والماكرو الواضحة التحقّق بين الإصدارات سريعًا. حافظ على انضباط توثيق كل استثناء: لماذا وُجد، من يحتاجه، ومتى راجعته آخر مرّة. الاستثناءات ليست خطيئة؛ الاستثناءات غير الموثّقة دينٌ تقني.

الخلاصة: الوضوح هو أفضل تحصين

يطارد هذا الخط هدفًا بسيطًا: الوضوح قبل التعقيد. ستحصل على جدارٍ ناري OpenBSD قابلٍ للتنبؤ يوميًا، بسطح هجومٍ صغير، يُريك—بفضل الوسوم والجداول والافتراضات المعقولة—ما يحدث فعلًا. نفضّل القرارات الصريحة على الآثار الجانبية الضمنية: سياسة خروج صارمة، وفرض DNS نحو محلّلاتٍ محدّدة، ومنع القنوات الصامتة عبر QUIC أو DoH/DoT/DoQ، وحالات حتمية، وروافع نواة متينة. النتيجة ليست تمرينًا أكاديميًا، بل نقطة انطلاقٍ صلبة تبني فوقها باطمئنان.

من المهم أن هذا الخط يفترض عن عمد عدم وجود محلّلٍ محلّي ولا خدمة NTP محلّية. يستهدف إعداداتٍ تريد الاستقرار بسرعة من دون بنيةٍ إضافية. إن أردت لاحقًا تحكّمًا محليًا أكبر فستضيفه بسلاسة—والهيكل جاهزٌ لذلك من دون التخلي عن الجوهر.

كي لا تبحث طويلًا: ستجد أدناه المقترحات الكاملة للتهيئة—ملفّا pf.conf بالنسختين (‏من دون DMZ للموجّه فقط و‏مع DMZ بعزلٍ صارم)، إضافةً إلى sysctl.conf المتحصّن. هذا المقال يشرح القرارات؛ والملفات أدناه تطبّقها حرفيًا. إن اتبعت تسلسل «تحقّق → حمّل → قِس» ستبلغ نتيجةً قابلةً للتكرار سريعًا.

من المهم أيضًا الصدق بشأن النطاق: لا تركّز هذه القاعدة على هجماتٍ موجّهةٍ عالية التخصيص ولا على سيناريوهات IDS/IPS كاملة. هذا لا يعني الاستغناء عنها—بل العكس. لقد صيغ الأساس بحيث يمكنك إضافتها بمنهجية. وقد أثبتت ثلاثة مسارات توسعةٍ فاعليتها عمليًا.

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

تحميل ‎sysctl.conf: https://www.protectstar.com/download/blog/sysctl.txt
تحميل ‎pf.conf (مع DMZ): https://www.protectstar.com/download/blog/pf.conf_withDMZ.txt
تحميل ‎pf.conf (من دون DMZ): https://www.protectstar.com/download/blog/pf.conf_noDMZ.txt