أخفِ عنوان IP مصدرك: وكيل عكسي خارجي يصمد

ما الذي يمنحك إخفاء المصدر فعليًا

ثلاثة أشياء، وتستحق الدقة في وصفها. أولاً، يتوقف الفيضان عن الوصول إلى الجهاز غير القادر على استيعابه: فلأي VPS واحد وصلة صعود محدودة السعة، وحين يكون العنوان الذي يبتلع الحزم حافةً (edge) مصمَّمة لهذا الغرض بدلاً من الجهاز الذي يحمل قاعدة بياناتك، يتحوّل الهجوم الحجمي (volumetric) إلى مشكلة هندسية يتحمّلها طرف آخر. ثانيًا، يتوقف التطبيق عن أن يكون قابلاً للوصول مباشرة متجاوزًا دفاعاته الخاصة — فتحديد المعدل، وقواعد الروبوتات، وجدار حماية تطبيقات الويب (WAF)، والحجب الجغرافي، كلها يتجاوزها بسهولة أي شخص يستطيع الاتصال بالمصدر مباشرة، ومعظم من ينشرونها لا يتحققون أبدًا مما إذا كان ذلك لا يزال ممكنًا. ثالثًا، يتوقف العنوان الذي يقدّم محتواك عن أن يكون العنوان الذي يحمل بياناتك، وهذا هو الفصل الذي يجعل شكوى إساءة الاستخدام، أو المسح، أو الفحص الموجَّه، تحطّ في مكان رخيص وقابل للاستبدال.

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

كل الطرق التي يتسرّب منها عنوان IP للمصدر

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

• سجلّ DNS التاريخي. ما زالت جهات جمع DNS السلبي (passive DNS) تسجّل سجل A الخاص بك منذ زمن طويل قبل أن تنتقل خلف وكيل. العنوان الذي استخدمته العام الماضي بحث مجاني، دائم، وقابل للبحث عنه.
• شفافية الشهادات. تُنشر كل شهادة موثوقة علنًا في سجلات عامة بوضع الإلحاق فقط، مع كل اسم مضيف تغطيه. شهادة صادرة لـorigin.example.com تُعلن ذلك الاسم للعالم، ويتكفّل سجل A الخاص بها بالباقي.
• نطاقات فرعية لم تُنقَل قط. mail، وftp، وwebmail، وcpanel، وdev، وstaging، وvpn، وmonitor — انتقل النطاق الرئيسي خلف الـ CDN، وبقيت هذه مشيرة إلى الجهاز نفسه.
• البريد. سجل MX على المصدر يفضح العنوان مباشرة؛ وكذلك تفعل ترويسة Received: في بريد أرسله تطبيقك، وهو ما يستطيع أي شخص إطلاقه عبر نموذج إعادة تعيين كلمة مرور.
• الطلبات الصادرة. الـ webhooks، وجلب الصور الرمزية، وسحب RSS، ومعاينات الروابط، وفحوصات التحديث، واستدعاءات OAuth. كل واحدة منها تكشف عنوان المصدر لمن يشغّل الطرف البعيد — وميزة معاينة الروابط تتيح للمهاجم اختيار ذلك الطرف البعيد بنفسه.
• الإجابة على العنوان المجرّد. إن كان المصدر لا يزال يقدّم موقعك لطلب بلا ترويسة Host مطابقة، فإن الماسحات على مستوى الإنترنت تكون قد فهرسته بالفعل: قيمة تجزئة الأيقونة (favicon)، وعنوان الصفحة، وبصمة الشهادة، وترتيب ترويسات HTTP، كلها قابلة للبحث.
• سجلّ IPv6 الذي نسيته. انتقل سجل A إلى الوكيل؛ وسجل AAAA ما زال يشير إلى البيت.
• التطبيق يتحدّث عن نفسه. روابط مطلقة في إعداد نظام إدارة محتوى، وتحويلات إلى اسم مضيف داخلي، وتتبّعات مكدس، وترويسات Server، وخرائط مصدر (source maps)، ونقطة نهاية حالة غير محمية بمصادقة.

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

شكلان للحافة: CDN، أو جهاز تملكه أنت

تمنحك شبكة CDN تجارية سعة Anycast لا يستطيع أي خادم منفرد مجاراتها، في عشرات المدن، وغالبًا على مستوى مجاني. المقايضة هي أن TLS يُنهى على بنية تحتية لا تتحكم فيها: فمشغّل الشبكة يرى نصّك الصريح، ويعرف الحساب الذي يعود إليه، ويمكن إرغامه على التصرف بناءً على تلك المعرفة، أو أن يقرر صباحًا ببساطة أن محتواك غير مرحَّب به. توجد أيضًا مشكلة أدقّ خاصة بالواجهات المشتركة — فإن كان جدار حماية مصدرك يسمح بنطاقات العناوين المنشورة لتلك الشبكة، فإن أي شخص آخر يملك حسابًا على تلك الشبكة يصبح داخل قائمة السماح لديك ويستطيع توجيه اسم مضيفه الخاص نحو مصدرك. هذا تجاوز حقيقي لا نظري، وهو بالضبط سبب وجود سحب المصدر الموثَّق (authenticated origin pull).

الحافة التي تُشغّلها بنفسك هي المقايضة المعاكسة. لا أحد سواك يحمل المفتاح الخاص، ويقع الجهاز في ولاية قضائية اخترتها أنت عمدًا، ويكلّف $8.00/شهريًا لأصغر خطة — وهو فعليًا خطأ تقريب لا يُذكر أمام ما يحميه. ما لا تحصل عليه هو Anycast: فيضان بسعة 200 غيغابت في الثانية سيُشبع وصلة صعود الحافة مهما كان إعداد nginx لديك أنيقًا، لذا لا بد أن يأتي الاستيعاب على مستوى الشبكة من مكان ما. في حالتنا، ذلك هو تخفيف 1.5 Tbps من التخفيف من جهة المنبع (upstream) أمام كل جهاز في الأسطول، وهو ما يجعل تشغيل حافة خاصة بك أمرًا قابلاً للحياة بدلاً من أن يكون نقطة انهيار وحيدة. يتركّب الشكلان أيضًا معًا: CDN في الأمام من أجل المدى والحجم، وعقدتك الخاصة خلفه من أجل الجزء الذي ترفض تسليمه. اختر بناءً على أي فشل تفضّل أن تُضطر لتفسيره.

النفق هو الجزء الذي يُخطئ فيه الناس

الإعداد الشائع هو مصدر يستمع على 0.0.0.0:443 مع جدار حماية يضع عناوين الوكيل في قائمة سماح. هذا يعمل، وهو الحلقة الأضعف في التصميم. قوائم السماح تنجرف — تتغيّر النطاقات المنشورة ولا يُطبَّق التحديث أبدًا؛ وهي مشتركة، فعلى CDN عام تقبل كل عميل آخر أيضًا؛ وتفشل بانفتاح (fail open) في الاتجاه الذي يهمّ تحديدًا، لأن المصدر يظل مستمعًا عامًا حيًّا طوال الوقت، بانتظار خطأ إعداد واحد أو أمر ufw disable واحد أثناء جلسة تصحيح أخطاء.

النسخة التي تصمد تعكس ذلك: المصدر ليس لديه أي مستمع عام على الإطلاق. يُنشأ نفق WireGuard بين الحافة والمصدر، ويرتبط خادم الويب بعنوان النفق فقط، وتحمل الواجهة العامة سياسة رفض افتراضي على عائلتي IP كلتيهما دون أي استثناء للمنفذ 80 أو 443. عندئذٍ لا تكون إمكانية الوصول قاعدة قد ينسى أحدهم تجديدها — بل تصبح غياب مسار بالكامل. WireGuard هو الأداة الصحيحة هنا لأنه وحدة نواة (kernel module) بمساحة هجوم ضئيلة، وهو صامت أمام الماسحات غير المصادَق عليها (فالحزمة غير المصادَق عليها لا تحصل على أي رد، لذا لا يبدو منفذ UDP وكأنه موجود أصلاً)، وتكلفته بضع ميكروثوانٍ فقط لكل حزمة. إن لم يسبق لك إعداد واحد من قبل، فإن دليل WireGuard يغطي الأساسيات؛ وهنا لا نحتاج سوى رابط نقطة إلى نقطة بين نظيرين اثنين.

قاعدة واحدة قبل أن تبدأ، وهي التي ستنقذ عصرك: أبقِ جلسة SSH ثانية مفتوحة طوال الوقت. إغلاق SSH خلف نفق ما زلت تعيد إعداده هو بالضبط كيف يفقد الناس أجهزتهم، وعلى مضيف لا توجد فيه هوية مسجَّلة، لا يوجد سلّم دعم فني تتسلّقه ولا جلسة طرفية (console) يمنحك إياها أحد — طريق العودة هو إعادة النشر والاستعادة، وهو أمر سريع إن كانت نسخك الاحتياطية حديثة، ونهائي إن لم تكن كذلك.

الشهادات، والسجل الذي ينشر أسماء مضيفيك

شفافية الشهادات شيء جيد فعلاً، وقادر مع ذلك على تدمير أسبوعك بكل سرور. كل شهادة تصدرها جهة إصدار شهادات (CA) عامة تُرفع إلى سجلات بوضع إلحاق فقط يستطيع أي شخص البحث فيها، ويحتوي القيد على كل اسم مذكور في الشهادة. أصدِر واحدة لـorigin.example.com أو direct.example.com وتكون قد نشرت، بشكل دائم وبصيغة منظَّمة، اسم المضيف بالضبط الذي كنت تحاول عدم الإعلان عنه. والأسوأ أن عادة وضع أسماء مضيفي staging والإدارة في قائمة SAN نفسها تحوّل عملية تجديد واحدة غير حذرة إلى خريطة كاملة لبنيتك التحتية.

الانضباط المطلوب بسيط. الشهادات العامة تعيش على الحافة فقط، ولا تغطي سوى الأسماء التي يستخدمها الجمهور فعليًا. أما المصدر فيحصل على شهادة موقَّعة ذاتيًا أو شهادة من جهة إصدار شهادات خاصة صغيرة، مثبَّتة في إعداد الوكيل عبر proxy_ssl_trusted_certificate — فلا شيء على رابط لا يتحدث عبره سوى وكيلك الخاص يحتاج إلى أن يكون موثوقًا علنًا، وإصدار شهادة عامة له لا يمنحك شيئًا سوى قيد في سجل. إن احتجت إلى نطاقات فرعية عامة كثيرة، فإن شهادة Wildcard واحدة تنشر اسمًا واحدًا بدلاً من ثلاثين. وحوِّل ACME إلى تحدي DNS-01: فتحدي HTTP-01 يتطلب شيئًا يجيب على المنفذ 80 من أجل اسم المضيف الجاري التحقق منه، وهو بالضبط المستمع العام الذي أزلته للتو. وأخيرًا، تقبَّل عدم التناظر — فالسجلات بوضع إلحاق فقط، لذا لا يمكن سحب اسم مضيف سبق نشره. وإن كان ذلك الاسم يشير إلى المصدر، فإن المصدر يحتاج إلى عنوان جديد.

البريد، والخدمات الأخرى التي تجيب على العنوان الخطأ

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

ثم افحص بشكل شامل كل ما تبقى مما ينصت بهدوء. عملاء المراقبة، ولوحات تحكم الحاويات، ومنافذ قواعد بيانات فُتحت «مؤقتًا»، ونقطة مقاييس (metrics) على المنفذ 9100، ولوحة تحكم على منفذ مرتفع، وخدمة SSH على الواجهة العامة. كل واحدة منها خدمة تجيب على العنوان الذي تحاول إبقاءه خاصًا، والماسحات تجد المنافذ المرتفعة بسهولة إيجادها للمنخفضة. التدقيق أمر واحد — ss -tulpn — والمُخرَج الصحيح قائمة لا يرتبط فيها شيء بعنوان عام. الخطوة الثالثة أدناه هي ما يجعل ذلك صحيحًا ويُبقيه كذلك.

الخروج: الاتصالات التي يبدؤها مصدرك

المصدر الذي لا يقبل شيئًا يمكنه مع ذلك أن يفضح نفسه، لأنه لا يستقبل الاتصالات فحسب — بل يفتحها أيضًا. مرايا الحزم، وNTP، وwebhook إلى معالج دفعات، وواجهة برمجية لروبوت، وصورة تُجلَب من أجل معاينة رابط، وفحص ترخيص، وجلسة SMTP صادرة، وGit remote، ومُبلِّغ أخطاء. بالنسبة للطرف البعيد لكل واحدة من هذه، عنوان المصدر العام هو ببساطة عنوان مصدر ذلك الاتصال. غالبًا ما يكون هذا غير ضار، لأنك اخترت الطرف البعيد وأنت تثق به. المشكلة في الحفنة من نقاط النهاية التي يختارها المهاجم: يلصق رابطًا في أي شيء يعرض معاينة، أو يسجّل webhook، أو يجد ثغرة تزوير طلب من جانب الخادم (SSRF) في أداة استيراد صور، فيتصل المصدر بمضيف يراقبه المهاجم بعد أن يحلّل عنوانه. تلك عملية كشف هوية تستغرق دقيقتين دون أي استغلال فعلي.

هناك إجابتان يمكن الدفاع عنهما. الإجابة الصارمة توجّه كل حركة الخروج عبر النفق وتترك الحافة تترجم عنوانها (NAT)، بحيث يصبح عنوان مصدر حركة المصدر الصادرة هو عنوان الحافة نفسها — إعداد واحد في تهيئة النظير، إضافة إلى التوجيه وقاعدة تخفٍّ (masquerade) في الطرف الآخر. يتكفّل wg-quick بحلقة التوجيه نيابة عنك: فمع مسار 0.0.0.0/0 يثبّت قاعدة fwmark تجعل حزم النفق نفسها تصل إلى نقطة النهاية مباشرة رغم ذلك، وهذا هو الجزء الذي يكسره الناس حين يكتبون المسارات يدويًا. الإجابة العملية تُبقي على الخروج المباشر لحركة المرور التي تتحكم فيها، وتضع وكيلاً أمام أي شيء يجلب رابطًا يوفّره المستخدم. غير القابل للدفاع عنه هو ألا تعرف أيًّا من الاثنين لديك. قرّر ذلك عمدًا، ثم تحقّق منه بطلب إلى مضيف تملكه وبإلقاء نظرة على عنوان المصدر في سجلاته.

ما تكلفته، وكيف تُثبت أنه يعمل

البند في الميزانية هو VPS إضافي واحد. أصغر خطة بسعر $8.00/شهريًا تُنهي TLS وتقوم بالوكالة (proxying) لموقع صغير دون أن تشعر بالحمل — فالوكيل العكسي في معظمه مجرد نسخ بين مقابس (sockets)، وخطة بواقع 2 vCPU و4 غيغابايت من الذاكرة تكفي بارتياح إلى ما بعد النقطة التي يصبح فيها المصدر خلفه عنق الزجاجة. ضعه في منطقة مختلفة عن المصدر كي لا يصل أمر قانوني واحد أو مشكلة في منشأة واحدة إلى كليهما، وتذكّر زمن الاستجابة: القفزة الإضافية تضيف ميلي ثوانٍ حقيقية، فوضع حافة في أمستردام أمام مصدر في كوالالمبور قرار تصميم، لا حادثة عرضية. الأزواج داخل القارة نفسها تكلّف عادة بضع ميلي ثوانٍ فقط، وإعادة استخدام جلسة TLS التي تكسبها عند الحافة كثيرًا ما تعوّض ذلك في تحميل صفحة حقيقي.

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

خطوة بخطوة

1. 01

   انشر الحافة وامنحها مهمّة واحدة بالضبط

   انشر VPS ثانيًا في منطقة ليست المنطقة التي يعيش فيها المصدر، وعامله كجهاز أحادي الغرض: إنهاء TLS، ووكيل عكسي، ولا شيء غير ذلك. بلا قاعدة بيانات، وبلا شيفرة تطبيق، وبلا أي سكربتات shell سيفتقدها أحد. نفّذ عليه قائمة تحقق الساعة الأولى — SSH بالمفتاح فقط، وجدار حماية برفض افتراضي على عائلتي IP كلتيهما، وتحديثات أمنية دون إشراف — ثم افتح ثلاثة منافذ بالضبط.

   ssh root@198.51.100.20
   apt update && apt full-upgrade -y
   hostnamectl set-hostname edge-01
   apt install -y nginx wireguard-tools ufw unattended-upgrades
   
   ufw default deny incoming && ufw default allow outgoing
   ufw limit 22/tcp
   ufw allow 80,443/tcp
   ufw allow 51820/udp
   ufw --force enable

2. 02

   شغّل النفق قبل أن تلمس DNS

   نظيران فقط، ورابط واحد. ولّد زوج مفاتيح على كل جهاز، وامنح النفق شبكته الفرعية الصغيرة الخاصة به — سينتهي الأمر بالمصدر قابلاً للوصول إليه عند 10.66.0.2 ولا مكان آخر. يتصل المصدر خارجًا بالحافة (فهو الطرف الذي لن يملك أي منفذ مفتوح)، لذا يحمل Endpoint ونبضة إبقاء اتصال (keepalive)؛ أما الحافة فتكتفي بالاستماع فقط.

   # on both machines
   umask 077; wg genkey | tee privkey | wg pubkey > pubkey
   
   # edge-01 — /etc/wireguard/wg0.conf
   [Interface]
   Address = 10.66.0.1/24
   ListenPort = 51820
   PrivateKey = <edge-privkey>
   
   [Peer]
   PublicKey = <origin-pubkey>
   AllowedIPs = 10.66.0.2/32
   
   # origin-01 — /etc/wireguard/wg0.conf
   [Interface]
   Address = 10.66.0.2/24
   PrivateKey = <origin-privkey>
   
   [Peer]
   PublicKey = <edge-pubkey>
   Endpoint = 198.51.100.20:51820
   AllowedIPs = 10.66.0.1/32
   PersistentKeepalive = 25

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

   systemctl enable --now wg-quick@wg0
   wg show          # expect a recent handshake and non-zero transfer
   ping -c3 10.66.0.1   # from the origin

3. 03

   اجعل المصدر غير قابل للوصول من الإنترنت العام

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

   # /etc/nginx/sites-available/app  — listen on the tunnel only
   listen 10.66.0.2:8080;
   
   ufw --force reset
   ufw default deny incoming
   ufw default allow outgoing
   ufw allow in on wg0 to any port 8080 proto tcp
   ufw allow in on wg0 to any port 22 proto tcp
   ufw allow from 198.51.100.20 to any port 51820 proto udp
   ufw --force enable
   
   # the audit: nothing may be bound to a public address
   ss -tulpn | grep -Ev '10\.66\.0\.2|127\.0\.0|\[::1\]'

   إن طبع ذلك الأمر الأخير اسم خدمة، فهذا تسرّب — أصلِح عنوان الربط بدلاً من إضافة قاعدة جدار حماية حوله. يُسمح لمستمعين اثنين بالبقاء: WireGuard على المنفذ 51820، وsshd إن لم تكن قد نقلته بعد إلى النفق.

4. 04

   أنهِ TLS عند الحافة ووكّل عبر النفق

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

   # edge-01 — /etc/nginx/sites-available/example.com
   server {
       listen 443 ssl;
       http2 on;
       server_name example.com www.example.com;
   
       ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
       ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
       add_header Strict-Transport-Security "max-age=63072000" always;
   
       location / {
           proxy_pass http://10.66.0.2:8080;
           proxy_set_header Host              $host;
           proxy_set_header X-Real-IP         $remote_addr;
           proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
           proxy_set_header X-Forwarded-Proto $scheme;
           proxy_http_version 1.1;
       }
   }
   
   # anything that is not a known hostname gets nothing at all
   server {
       listen 80 default_server;
       listen 443 ssl default_server;
       ssl_reject_handshake on;
       return 444;
   }

5. 05

   أعِد للمصدر عنوان IP الحقيقي للعميل

   خلف الوكيل، يصل كل طلب من 10.66.0.1. إن تُرك الأمر على حاله، تصبح سجلات الوصول لديك عديمة الفائدة، ويكبح تحديد المعدل لكل عنوان IP النفقَ بدلاً من المهاجم، وينتهي الأمر بأن يحظر fail2ban الحافةَ نفسها ويُسقط الموقع بالكامل — وهي طريقة شائعة فعلاً للتسبب في انقطاع أثناء التحصين. ثِق بترويسة إعادة التوجيه، لكن فقط من عنوان النفق، لا من العالم الخارجي أبدًا.

   # origin-01 — /etc/nginx/conf.d/realip.conf
   set_real_ip_from 10.66.0.1;
   real_ip_header   X-Forwarded-For;
   real_ip_recursive off;

   افعل المكافئ في التطبيق نفسه — ProxyFix في Flask، وTRUSTED_PROXIES في Laravel، وset_real_ip_from إضافة إلى قائمة الوكلاء الموثوقين الخاصة بالإطار نفسه — وضع تحديد المعدل على الحافة، حيث يوجد عنوان العميل الحقيقي أصلاً:

   # edge-01 — /etc/nginx/nginx.conf (http block)
   limit_req_zone $binary_remote_addr zone=front:10m rate=20r/s;
   # then, inside the location block
   limit_req zone=front burst=40 nodelay;

6. 06

   انقل البريد وحركة الخروج بعيدًا عن عنوان المصدر

   وجّه MX نحو جهاز يُسمح له بأن يُعثر عليه، وأرسِل البريد الصادر عبر مُرحِّل (relay) بدلاً من إرساله مباشرة من المصدر، وحوّل تجديد الشهادات إلى تحدي DNS-01 كي لا يضطر أي شيء للإجابة على المنفذ 80. ثم قرّر ما سيحدث لبقية حركة المرور الصادرة. لتوجيهها جميعًا عبر الحافة، وسِّع AllowedIPs الخاص بالمصدر ودع الحافة تقوم بالتخفّي (masquerade) — إذ يثبّت wg-quick قاعدة fwmark التي تُبقي النفق نفسه قابلاً للوصول، فلا تحتاج إلى كتابة مسار لنقطة النهاية يدويًا.

   # origin-01 — /etc/wireguard/wg0.conf, in [Peer]
   AllowedIPs = 0.0.0.0/0, ::/0
   
   # edge-01 — forward and NAT the tunnel
   echo 'net.ipv4.ip_forward=1' > /etc/sysctl.d/99-fwd.conf && sysctl --system
   ufw route allow in on wg0 out on eth0
   # in /etc/ufw/before.rules, above the *filter block:
   # *nat
   # :POSTROUTING ACCEPT [0:0]
   # -A POSTROUTING -s 10.66.0.0/24 -o eth0 -j MASQUERADE
   # COMMIT
   systemctl restart ufw && wg-quick down wg0 && wg-quick up wg0

   ثم تحقّق من ذلك من المصدر: يجب أن يعيد curl -s https://ifconfig.co عنوان الحافة، لا عنوانها هي.

7. 07

   طارِد مصدرك الخاص، ثم دوِّن دليل التشغيل

   هاجمه بالطريقة نفسها التي سيهاجمه بها شخص آخر. الأمر الأول هو المهم — إن كان المصدر ما زال يقدّم موقعك عند مخاطبته مباشرة، فإن شيئًا مما سبق لم يعمل بعد.

   # does the origin answer for your hostname?
   curl -sk --resolve example.com:443:203.0.113.10 https://example.com/ \
        -o /dev/null -w '%{http_code}\n'      # want: a timeout, not 200
   
   # every hostname you have ever certified, from the public logs
   curl -s 'https://crt.sh/?q=%25.example.com&output=json' \
     | grep -o '"name_value":"[^"]*"' | sort -u
   
   # records that never moved
   dig +short example.com A; dig +short example.com AAAA; dig +short example.com MX
   for h in www mail ftp webmail cpanel dev staging vpn monitor origin direct; do
     printf '%-9s %s\n' "$h" "$(dig +short $h.example.com | tr '\n' ' ')"
   done

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