إبقاء VPS متصلًا أثناء هجمات DDoS

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

الفيضانات الحجمية تستهدف نطاقك الترددي. تضخيم UDP — عبر DNS وNTP وmemcached، ومؤخرًا أي شيء يجيب عن سؤال صغير بإجابة كبيرة — يتيح للمهاجم تحويل 1 Gbps من سعته إلى 50 Gbps موجّهة إليك. الهدف هو الرابط، لا الخادم. ومعالجك سيظل خاملاً طوال الوقت.

هجمات البروتوكول والحالة تستهدف جدولاً محدود السعة في نواتك. فيضان SYN يحاول استنفاد طابور القبول؛ وفيضان الحزم الصغيرة العام يحاول استنفاد تتبّع الاتصالات. كلاهما يُقاس بالحزم في الثانية، لا بالبتات في الثانية، وكلاهما قادر على قتل جهاز على رابط خامل بنسبة 97%. هذا هو الصنف الذي يُسقط الخوادم الصغيرة، والصنف الذي تتجاهله معظم الأدلة.

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

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

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

لذا فإن الأسئلة المفيدة الوحيدة هي ما يفعله مزوّدك تلقائيًا وأين تقع عتباته. عتباتنا منشورة لا موعودة: ما دون 10 Gbps يُمتَص دون أثر مرئي، ومن 10 إلى 100 Gbps تتم تنقيته لدى مزوّد العبور وقد تلاحظ ارتفاعًا طفيفًا في زمن الاستجابة، وفوق 100 Gbps يُعلَن عن البادئة (prefix) على مسار تنقية مخصص — يرتفع زمن الاستجابة بشكل أوضح، وتبقى الخدمة قابلة للوصول. سحب توجيه العنوان (null-routing) مطروح فقط للهجمات المستمرة التي تهدد نقطة الحضور (PoP) بأكملها، ونُخبرك خلال دقائق إن حدث ذلك. لا شيء لتشتريه ولا شيء لتُفعّله.

هناك أمران يستحقان المعرفة عن التنقية، نادرًا ما يتطوع البائعون بذكرهما. الأول أنك محمي بحكم الجوار لا بدفاعاتك وحدها: هجوم على عميل يشارك معك نطاق /20 في المنبع يُمتَص قبل أن يصل إلى بادئة أي أحد — فيضان بلغ نحو 340 Gbps استهدف نطاقًا مجاورًا في باريس مرّ دون أثر يُذكر على نطاقنا، وهذه بالضبط النتيجة التي لا يلاحظها أحد. الثاني أن أنظمة التنقية استدلالية (heuristics) وقد تُخطئ أحيانًا: على الشبكة نفسها، أمضى نظام تنقية مرة تسع دقائق يُصدر إعادات ضبط TCP (resets) ضد اتصالات مشروعة أثناء تصفيته هجومًا على جار. كلا الحادثتين موثّقتان في سجل الحوادث العام. إن ماتت جلساتك بطريقة تشبه إعادة ضبط نشطة لا مهلة زمنية منتهية أثناء هجوم على طرف آخر، فذلك عطل حقيقي يستحق الإبلاغ عنه بدلاً من تصحيحه محليًا لمدة ساعة.

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

# 1. bits vs packets  — which axis is saturated?
sar -n DEV 1 5            # or: ifstat -i eth0 1

# 2. socket states     — SYN-RECV piling up means a SYN flood
ss -s
ss -tan state syn-recv | wc -l

# 3. kernel drop counters (these are the ones that matter)
nstat -az | grep -E 'ListenDrops|ListenOverflows|SyncookiesSent|TCPReqQFullDrop'
dmesg -T | tail -20       # look for: nf_conntrack: table full, dropping packet

# 4. connection tracking headroom
cat /proc/sys/net/netfilter/nf_conntrack_count
cat /proc/sys/net/netfilter/nf_conntrack_max

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

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

ثم تحقق من أن الحركة ليست حقيقية ببساطة. راقب سجل الوصول بأمر tail -f لعشر ثوانٍ: مسار واحد تُكرره آلاف العناوين المختلفة بلا محيل (referrer) هو هجوم؛ أما تنوّع في مسارات عادية من متصفحات عادية فهو جمهور حقيقي، وتحديد معدله سيُنجز عمل المهاجم نيابة عنه.

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

هناك طبقتان هنا وهما ليستا الشيء نفسه. مرشّح الحافة (edge filter) اختياري، يُضبط لكل خادم على حدة، بحالة (stateful) وبسياسة إسقاط افتراضية، ويعمل على المضيف الفعلي (hypervisor) — الحركة التي ترفضها هناك لا تصل إلى بطاقة الشبكة الافتراضية لديك إطلاقًا، فلا تكلّفك معالجًا ولا ذاكرة ولا إدخالاً في جدول الحالة. أما جدار حماية الخادم الافتراضي — مجموعة قواعد nftables لديك — فهو ملكك بالكامل ولا نلمسه أبدًا. النمط الذي ينجو من مواجهة هجوم فعلي هو التعبير عن الحقيقة الخشنة والثابتة للطبقة 4 عند الحافة («هذا الجهاز يخدم المنافذ 80 و443 وSSH من هذه العناوين، ولا شيء غير ذلك موجود») والإبقاء على مجموعة قواعد الخادم الافتراضي للعمل الدقيق الذي يتغيّر مع تطبيقك. كلاهما موصوف في وثائق جدار الحماية.

ثم ضيّق ما تبقى. تقييد SSH بالعناوين التي تُدير منها فعليًا ليس رفاهية تحصين هنا — بل يُزيل فئة كاملة من هجمات استنفاد الاتصالات عن جهازك. قاعدة بيانات مرتبطة بـ 127.0.0.1 أو بعنوان WireGuard لا يمكن إغراقها من الإنترنت إطلاقًا. وإن كنت تخدم مستوى تحكّم داخليًا بحتًا، ضعه خلف واجهة WireGuard بدلاً من منفذ عام بكلمة مرور.

فيضان SYN يستغل المصافحة (handshake): يُرسل المهاجم دفقًا من طلبات الاتصال ولا يُكملها أبدًا، ويشغل كل طلب منها فتحة في طابور SYN الخاص بالنواة إلى أن تنتهي مهلته. املأ الطابور وتُسقَط المصافحات المشروعة — خدمتك تعمل، وتستمع، وغير قابلة للوصول إليها.

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

# /etc/sysctl.d/99-flood.conf
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 8192
net.core.somaxconn = 8192
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_abort_on_overflow = 0

sysctl --system

tcp_synack_retries = 2 أهم مما تبدو عليه: القيمة الافتراضية خمسة تعني أن مصافحة مزوّرة تشغل النواة لنحو ثلاث دقائق، بينما يُنزل الرقم اثنان ذلك إلى نحو سبع ثوانٍ. رفع somaxconn نصف المهمة فقط — فعمق الطابور هو أصغر قيمة بين تلك القيمة وما طلبه التطبيق، لذا يحتاج nginx إلى listen 443 ssl backlog=8192; وإعادة تحميل قبل أن يكون لإعداد النواة أي معنى. هذه هي الحالة الكلاسيكية لإعداد sysctl يبدو أنه طُبّق بينما لا يفعل شيئًا.

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

table inet filter {
  chain input {
    type filter hook input priority filter; policy drop;
    ct state established,related accept
    iif lo accept
    tcp dport { 80, 443 } ct state new synproxy mss 1460 wscale 7 timestamp sack-perm
    tcp dport { 80, 443 } accept
    ip protocol icmp icmp type echo-request limit rate 5/second accept
  }
}

اختبر synproxy على جهاز لا يزال بإمكانك الوصول إليه عبر وحدة التحكم (console) قبل أن تعتمد عليه؛ فإن أُسيء ضبطه، فهو وسيلة ممتازة لإغلاق جدار الحماية في وجهك أنت على خادمك. بالنسبة لمعظم الناس، تكفي كتلة sysctl أعلاه، والترتيب الصادق هو: ملفات تعريف SYN أولاً، ثم الطابور (backlog)، ثم synproxy فقط إن قِستَ أن الأولين لم يكونا كافيين.

هذا هو الجدول الذي يُوقع حتى ذوي الخبرة. جدار الحماية ذو الحالة يجب أن يتذكر كل تدفق رآه، وتلك الذاكرة هي nf_conntrack، جدول تجزئة (hash table) بحجم ثابت يُحدَّد عند الإقلاع. وبمجرد امتلائه، تُسقط النواة الاتصالات الجديدة — كلها، المهاجم والعميل على حد سواء — وتُسجّل سطرًا واحدًا في dmesg لا يراقبه أحد:

nf_conntrack: table full, dropping packet

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

# /etc/sysctl.d/99-conntrack.conf
net.netfilter.nf_conntrack_max = 262144
net.netfilter.nf_conntrack_buckets = 65536
net.netfilter.nf_conntrack_tcp_timeout_established = 3600
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 20
net.netfilter.nf_conntrack_udp_timeout = 20

المهلات الزمنية (timeouts) تُفيد أكثر من الحجم. العمر الافتراضي لتدفق TCP قائم هو خمسة أيام، ما يعني أن خادمًا يعمل منذ أسبوع لا يزال يحتفظ بحالة اتصالات انتهت يوم الثلاثاء؛ ساعة واحدة كافية تمامًا لأي شيء ليس جلسة SSH خاملة، ويُبقي net.ipv4.tcp_keepalive_time = 600 تلك الجلسات حيّة بشكل سليم بدلاً من مصادفة عرضية. احسب نحو 300 بايت من ذاكرة النواة لكل إدخال عند التحجيم: 262,144 إدخالاً يعادل نحو 80 ميغابايت، وهذا مقبول على جهاز بذاكرة 4 غيغابايت وغير مقبول إن ضبطته على عشرة ملايين لأن أحد المنتديات قال ذلك.

إن كنت تُشغّل شيئًا عديم الحالة فعليًا وعالي الحجم — خادم DNS موثوق (authoritative)، أو خادم ألعاب عامًا، أو مُرحّل Tor — فالجواب الأفضل هو التوقف عن تتبعه بالكامل. تتبّع الاتصالات لخدمة لا تملك اتصالات ذات معنى هو تكلفة صِرفة:

table ip raw {
  chain prerouting {
    type filter hook prerouting priority raw; policy accept;
    udp dport 51820 notrack
    tcp dport 9001 notrack
  }
}

تذكّر أن هذه الحركة تتجاوز حينها قواعد ct state established لديك، لذا فهي تحتاج قواعد قبول صريحة في سلسلة التصفية. هذه هي المقايضة: تتخلى عن خاصية الحالة لذلك المنفذ وتحصل في المقابل على جدول لا يمكن ملؤه.

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

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

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

proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=app:64m max_size=2g inactive=60m;

server {
  location / {
    proxy_cache app;
    proxy_cache_valid 200 301 302 10m;
    proxy_cache_lock on;              # one origin request per key, not a thousand
    proxy_cache_lock_timeout 5s;
    proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
    proxy_cache_background_update on; # serve stale, refresh behind it
    add_header X-Cache $upstream_cache_status always;
    proxy_pass http://127.0.0.1:8080;
  }
}

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

ثم حدّد معدل المسارات المكلفة تحديدًا، بسخاء، وبطريقة تفشل بوضوح:

limit_req_zone $binary_remote_addr zone=general:16m rate=20r/s;
limit_req_zone $binary_remote_addr zone=costly:16m  rate=2r/s;
limit_conn_zone $binary_remote_addr zone=conn:16m;
limit_req_status 429;
limit_conn_status 429;

server {
  limit_req  zone=general burst=40 nodelay;
  limit_conn conn 24;

  location /search { limit_req zone=costly burst=5 nodelay; proxy_pass http://127.0.0.1:8080; }
  location /login  { limit_req zone=costly burst=3 nodelay; proxy_pass http://127.0.0.1:8080; }
}

burst بلا nodelay يُصفّف الطلبات الزائدة في طابور بدلاً من رفضها، وهذا يعني تحت الهجوم أن nginx يُبقي بأدب آلاف الاتصالات مفتوحة نيابة عنك — فتكون قد حوّلت فيضان طلبات إلى فيضان اتصالات. استخدم nodelay، وأعد 429 فورًا، ودع العميل يتعامل مع الأمر. وخلف أي وكيل (proxy)، تذكّر أن $binary_remote_addr هو عنوان الوكيل نفسه ما لم تكن قد ضبطت set_real_ip_from وreal_ip_header بشكل صحيح؛ فحد معدل مبني على عنوان واجهتك الأمامية سيُقفل الباب أمام كل مستخدم دفعة واحدة أول مرة يُفعَّل فيها.

هجمات نمط Slowloris — اتصالات كثيرة، كل واحد منها يُرسل طلبًا بايتًا واحدًا في كل مرة — بالكاد تُزعج نموذج الأحداث في nginx، لكن يستحق الأمر تشديد المهلات الزمنية على أي حال: client_header_timeout 8s; client_body_timeout 8s; send_timeout 10s; reset_timedout_connection on;. مع limit_conn، هذا هو الدفاع بأكمله.

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

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

إن أردت حظرًا ديناميكيًا، نفّذه في مستوى البيانات حيث يكون البحث تجزئة (hash) وتنتهي الصلاحية تلقائيًا. مجموعة nftables الديناميكية بتعقيد O(1) بصرف النظر عن الحجم، وتنسى من تلقاء نفسها:

table inet filter {
  set flooders {
    type ipv4_addr
    flags dynamic, timeout
    timeout 10m
    size 65535
  }

  chain input {
    type filter hook input priority filter; policy drop;
    ct state established,related accept
    iif lo accept
    ip saddr @flooders drop
    tcp dport { 80, 443 } ct state new add @flooders { ip saddr limit rate over 50/second burst 100 packets } drop
    tcp dport { 80, 443 } accept
  }
}

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

كل هجوم حجمي كبير يُغذّى بخوادم لم يكن مُشغّلوها يعلمون أنهم يشاركون فيه. الآلية هي خدمة UDP تُجيب عن طلب صغير مُزوَّر بردٍّ كبير: مُحلِّل DNS مفتوح يُعيد 50 ضعف ما طُلب منه، وNTP وmemcached سيّئا الضبط أسوأ من ذلك، وأي بروتوكول يستجيب قبل أن يتحقق من هوية طالبه هو مرشّح لذلك.

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

# bind a recursive resolver to localhost, never 0.0.0.0
# unbound: interface: 127.0.0.1  +  access-control: 0.0.0.0/0 refuse

# what is actually listening on a public address?
ss -ulpn
ss -tlpn

# from another machine, confirm you do not answer strangers
dig @your.server.ip example.com +short          # must time out
ntpq -c rv your.server.ip                        # must fail

إن كنت تُشغّل خدمة UDP عامة عن قصد — خادم ألعاب، أو خادم أسماء موثوقًا (authoritative)، أو نقطة نهاية WireGuard — فالقاعدة هي نفسها في كل مكان: حدِّد معدل الاستجابة، لا الطلب أبدًا. يُطبّق كل من bind وknot تحديد معدل الاستجابة؛ استخدمه، لأنه الفارق بين خدمة مستخدميك وشحن هجوم شخص آخر.

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

عناوين الأصل لا تتسرب تقريبًا عبر هجمات ذكية. بل تتسرب عبر التاريخ والإهمال، في قائمة قصيرة ومعروفة جيدًا. سجلات DNS القديمة هي المتهم المعتاد: أرشيفات DNS السلبية (passive-DNS) تتذكر سجل A الذي كان لديك قبل أن تضع واجهة أمامية، إلى الأبد. سجلات شفافية الشهادات عامة ودائمة، لذا فإن شهادة صدرت لاسم مضيف كان يشير مباشرة إلى الأصل هي سجل موقّع ومؤرَّخ لمكان إقامتك السابق. البريد الصادر يطبع عنوان الخادم المُرسِل في ترويسات كل رسالة. وأما الأمر الهادئ: خادم الويب لديك وهو يستجيب على IP العاري، ما يتيح لأي شخص يمسح فضاء العناوين بحثًا عن HTML موقعك أن يجدك عبر المحتوى خلال بعد ظهر واحد.

ذلك الأخير إصلاحه سطران ولا يفعله أحد تقريبًا. اجعل الخادم الافتراضي (default server) يرفض كل ما لم يصل باسم مضيف تخدمه:

server {
  listen 80 default_server;
  listen 443 ssl default_server;
  ssl_reject_handshake on;      # nginx 1.19.4+: no certificate, no fingerprint
  return 444;                   # close without a response
}

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

البديل الذي يحافظ على الخاصية التي دفعت ثمنها هو أن تكون واجهتك الأمامية أنت بنفسك. خادم بخمسة دولارات في منطقة ثانية يُشغّل nginx كوكيل عكسي، مع ضبط مرشّح الحافة للأصل على قبول الحركة من ذلك العنوان الواحد فقط ولا شيء غيره، يمنحك عنوانًا تضحويًا يمكنك إعادة ترقيمه خلال خمس دقائق ومستوى تحكّم لا يستجيب إلا لك. إنها البنية نفسها، ناقص الطرف الثالث. وحيثما يستطيع الجمهور استخدامها، تُزيل خدمة onion على Tor عنوان IP من المعادلة كليًا — لا يوجد عنوان لإغراقه، رغم أن خدمات onion لها سطح هجومها الخاص عند نقاط التقديم (introduction points)، ولهذا يشحن Tor الحديث دفاعًا بإثبات العمل (proof-of-work) لهذا الغرض بالتحديد.

عاجلاً أم آجلاً سيقترح أحدهم حظر دولة كاملة. هذا أسلوب فظ، وصحيح أحيانًا، ووسيلة لتشعر بأنك تفعل شيئًا في معظم الأحيان.

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

الحظر حسب رقم النظام المستقل (ASN) أدق. حركة الهجوم التي تنشأ من حفنة من مزوّدي الاستضافة — نطاقات VPS رخيصة مُستأجرة بالساعة — يمكن إسقاطها حسب البادئة بإصابات جانبية أقل بكثير من حظر دولة كاملة، لأن المستخدمين العاديين لا يتصفحون من مركز بيانات. ونطاقات مراكز البيانات هي أيضًا، بشكل ملائم، من حيث يأتي الكشط (scraping) وحشو بيانات الاعتماد.

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

# in an attack: what do these requests have in common?
awk '{print $1}'  /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20   # addresses
awk -F'"' '{print $6}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20   # user agents
awk '{print $7}'  /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20   # paths

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

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

ما يجعلها سريعة يُقرَّر مسبقًا. أبقِ مدة صلاحية DNS (TTL) عند 300 ثانية كوضع دائم — التكلفة ضئيلة والفائدة أنك تستطيع الانتقال خلال خمس دقائق بدلاً من يوم كامل. أبقِ نشرك قابلاً للتكرار، لأن الخادم الذي يمكنك إعادة بنائه هو خادم يمكنك نقله؛ فإن كانت إعادة البناء تعني تذكّر ما فعلته في مارس، فليس لديك خطة، بل رهينة. احتفظ بـنسخة احتياطية قابلة للاستعادة في منطقة مختلفة، واعرف من تمرين فعلي كم يستغرق الاستعادة من الوقت.

عندئذ تكون الخطوة الفعلية قصيرة: انشر في منطقة أخرى، استعِد، تحقق من العنوان الجديد بتجاوز اسم المضيف (hostname override) قبل أن تلمس DNS، بدّل السجل، وأبقِ الخادم القديم يعمل مدة كافية ليلحق به آخر المُحلِّلات (resolvers). يغطي دليل الانتقال ترتيب الخطوات بشكل صحيح، وهو نفس الترتيب سواء كنت تنتقل من أجل الأداء أو لأن أحدهم غاضب.

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

ملاحظتان ختاميتان صادقتان، لأن بقية هذه الصفحة متفائلة بحكم بنائها.

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

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