تصليب خادم Linux ضد DDoS: كل إعدادات sysctl وconntrack وnftables

يجيب هذا الدليل عن سؤال واحد: كيف نصلّب خادم Linux نفسه، دون أي جهاز أمامه، ضد الجزء المستنزِف للحالة من هجوم DDoS. لا نتحدث عن أي طبقة حماية وسيطة. حديثنا عن إعدادات نواة الخادم نفسها.

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

الجهاز	المورد	العَرَض	أمر التحقق
طابور SYN / accept	الاتصالات الجديدة تسقط بصمت عند انتهاء المهلة	nstat -az | grep -i listen
جدول conntrack	dmesg: 'nf_conntrack: table full, dropping packet'	conntrack -C; conntrack -S
واصفات الملفات	accept() تُعيد EMFILE؛ المنفذ يستمع لكنه لا يقبل أحداً	cat /proc/<pid>/limits; cat /proc/net/sockstat
TIME_WAIT / المقابس اليتيمة	تنفد المنافذ العابرة أو الذاكرة؛ 'Out of socket memory' في السجل	ss -tan state time-wait | wc -l; cat /proc/net/sockstat
مخازن المقابس	حركة المرور الشرعية تسقط تحت الحِمل	netstat -s | grep -i prune; cat /proc/net/softnet_stat

الصفوف الخمسة كلها موضوع هذه المقالة، وكلها تُقاس على المضيف. أمّا إشباع المعالج بعدد الحزم (softirq) فطبقة منفصلة، يتناولها دليل مكدّس الشبكة.

0. خطّ الأساس أولاً: لا تضبط ما لم تقِسه

قبل التصليب، سجّل أرقام أسبوع عادي. كل عتبة أدناه تُختار قياساً عليها.

# Snapshot of sockets (established, syn-recv, time-wait breakdown)
ss -s

# Socket counters: tcp inuse / orphan / tw, tcp mem
cat /proc/net/sockstat

# conntrack occupancy and ceiling
cat /proc/sys/net/netfilter/nf_conntrack_count
cat /proc/sys/net/netfilter/nf_conntrack_max

# Cumulative TCP events — handshake, queue drops
nstat -az | grep -Ei 'syn|listen|drop|overflow'

# To watch over time
watch -n1 'cat /proc/net/sockstat; echo; nstat | grep -Ei "listen|syncookie"'

مخرَج هذه الأوامر الخمسة هو خطّ أساسك. بعد أسبوع تشغّل الأوامر نفسها وترى ما تغيّر. وعلّة العتبة المنسوخة أنها تتخطّى هذه الخطوة.

1. جانب SYN: هناك طابوران لا طابور واحد

تحتفظ النواة بطابورين لكل مقبس مُصغٍ. الطابور نصف المفتوح يحمل الاتصالات التي لم تكتمل مصافحتها (SYN_RECV)؛ وحجمه tcp_max_syn_backlog. طابور accept يحمل المصافحات المكتملة بانتظار accept()؛ وسقفه الأصغرُ من somaxconn وقيمة backlog التي يمرّرها التطبيق لـ listen().

بسبب هذا الانقسام، رفع sysctl وحده لا يغيّر شيئاً غالباً: إن كان التطبيق يُصغي بـ backlog قيمته 128، فما كتبته إلى النواة لا يهمّ.

# /etc/sysctl.d/90-ddos.conf — طبقة SYN
net.ipv4.tcp_syncookies = 1          # كوكي عند فيض الطابور؛ القيمة الافتراضية الحديثة
net.ipv4.tcp_max_syn_backlog = 8192  # حجم الطابور نصف المفتوح
net.core.somaxconn = 8192            # سقف طابور accept
net.ipv4.tcp_synack_retries = 2      # يقصّر عمر SYN_RECV غير المُجاب
net.ipv4.tcp_syn_retries = 3         # للاتصالات الصادرة؛ جانب العميل

ارفع backlog التطبيق في الوقت نفسه، وإلا فـ somaxconn وحده لا يفعل شيئاً:

# nginx: listen backlog يُحاذى مع somaxconn
listen 443 ssl backlog=8192;

التحقق. اقرأ المقابس في حالة SYN_RECV وسقطات الطابور:

# How many connections are half-open right now?
ss -tan state syn-recv | wc -l

# Accept queue occupancy: Recv-Q is the current backlog, Send-Q the ceiling
ss -ltn

# Queue overflow counters — if these leave zero, the accept chain is narrow
nstat -az | grep -E 'TcpExtListenDrops|TcpExtListenOverflows'

# Did SYN cookies actually engage?
nstat -az | grep -i syncookie

إن كان SyncookiesSent أكبر من صفر، فطابورك فاض مرة واحدة على الأقل؛ وهذه إشارة إلى رفع الـ backlog أو إشراك طبقة عليا. وبينما تكون كوكيز SYN فعّالة وطوابع TCP الزمنية مغلقة، يُفقَد تحجيم النافذة وSACK لتلك الاتصالات. لذلك لا تعتمد على الكوكي، بل استهدف طابوراً لا يفيض أصلاً.

tcp_abort_on_overflow يرسل RST بدل الإسقاط الصامت عند فيض طابور accept. القيمة الافتراضية (0) إسقاط صامت، وهي عادةً الصحيحة: تترك للعميل مجالاً لإعادة المحاولة. وإن كان خلفك موازِن حِمل بمنطق إعادة محاولة خاص به، فالقيمة 1 إشارة أصدق:

sysctl -w net.ipv4.tcp_abort_on_overflow=1   # فقط عند وجود سبب

2. conntrack: ما إن يمتلئ الجدول، لا يدخل تدفّق جديد

يحتفظ تتبّع اتصالات netfilter بمُدخَل لكل تدفّق. حين يمتلئ الجدول، تُسقط النواة حزمة التدفّق الجديد. والعَرَض ماكر: الجلسات القائمة تحيا، وكل جديد يبقى في الخارج، والرسم البياني يقول «الحركة طبيعية».

# Current occupancy and ceiling
conntrack -C
cat /proc/sys/net/netfilter/nf_conntrack_max

# How many flows in which state? (a SYN_SENT flood shows up here)
conntrack -L 2>/dev/null | awk '{print $4}' | sort | uniq -c | sort -rn

# Have drops started?
dmesg | grep -i 'nf_conntrack: table full'
conntrack -S | grep -Eo 'drop=[0-9]+'

هناك ثلاثة مقابض. الحجم، والعمر، وعدم التتبّع أصلاً.

# /etc/sysctl.d/90-ddos.conf — conntrack
net.netfilter.nf_conntrack_max = 1048576
net.netfilter.nf_conntrack_tcp_timeout_established = 3600   # الافتراضي 432000 (5 أيام)
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 30        # نظّف نصف المفتوح بسرعة
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 30
net.netfilter.nf_conntrack_tcp_loose = 0                    # لا تتبّع التدفّقات أحادية الاتجاه

حجم جدول التجزئة (buckets) يُضبط من معامل الوحدة، لا من sysctl؛ وإبقاؤه ثُمنَ السقف على الأقل يقلّل التصادمات:

echo 262144 > /sys/module/nf_conntrack/parameters/hashsize
# دائم: في /etc/modprobe.d/nf_conntrack.conf
#   options nf_conntrack hashsize=262144

المقبض الثالث يُبقي الحركة عديمة الحالة عالية الحجم خارج الجدول تماماً. سلسلة raw في nftables:

table inet raw {
  chain prerouting {
    type filter hook prerouting priority raw; policy accept;
    udp dport 53 notrack
    tcp dport 53 notrack
  }
}

خدمة عديمة الحالة مثل DNS المرجعي تصير بهذه القاعدة منيعة على فيض conntrack. والثمن واضح: قواعد ct state لا تنطبق على تلك الحركة.

عتبة الإنذار: أوصِل إلى المراقبة إشغالاً عند سبعين بالمئة من السقف.

awk -v max="$(cat /proc/sys/net/netfilter/nf_conntrack_max)" \
    -v cur="$(cat /proc/sys/net/netfilter/nf_conntrack_count)" \
    'BEGIN{ printf "conntrack %d/%d = %.0f%%\n", cur, max, 100*cur/max }'

3. واصفات الملفات: تفوز أقصر حلقة في السلسلة

كل اتصال مفتوح واصفُ ملف. حين تنفد، تُعيد accept() رمز EMFILE؛ الخدمة تعمل، والمنفذ يستمع، لكنه لا يقبل أحداً. وهجمات الاتصال البطيء تستهدف هذا بالضبط.

الحدّ سلسلة، وتحكم أدنى حلقة فيها:

# System-wide ceiling
cat /proc/sys/fs/file-max
# Per-process absolute ceiling
cat /proc/sys/fs/nr_open
# How many descriptors are open now / what is the ceiling?
cat /proc/sys/fs/file-nr

# /etc/sysctl.d/90-ddos.conf — على مستوى النظام
fs.file-max = 2097152
fs.nr_open = 1048576

عنق الزجاجة الحقيقي هو دائماً تقريباً حدّ وحدة الخدمة، لأنه يبقى منخفضاً في معظم التوزيعات. والحلّ الدائم حقنة systemd؛ لا تصارع ulimit، فهو يصف صَدَفتك لا الخدمة:

# /etc/systemd/system/nginx.service.d/limits.conf
[Service]
LimitNOFILE=262144

systemctl daemon-reload
systemctl restart nginx

# الحدّ الحقيقي للخدمة (لا حدّ الصَّدَفة):
systemctl show nginx -p LimitNOFILE
cat /proc/$(pgrep -o nginx)/limits | grep 'open files'

# إجمالي استخدام المقابس:
cat /proc/net/sockstat   # sockets: used ...; TCP: inuse ...

4. TIME_WAIT والمقابس اليتيمة: الاستنزاف الصامت

فيض اتصالات قصيرة العمر يستنزف موردين عبر تراكم TIME_WAIT والمقابس اليتيمة: نطاق المنافذ العابرة وذاكرة مقابس TCP. والعَرَض سطر TCP: out of memory أو Out of socket memory في dmesg.

# State distribution
ss -tan state time-wait | wc -l
ss -tan state fin-wait-1 | wc -l

# Orphan / tw counts and tcp mem pressure
cat /proc/net/sockstat
# tcp_mem: low pressure high  (third number is the hard ceiling in pages)
cat /proc/sys/net/ipv4/tcp_mem

# /etc/sysctl.d/90-ddos.conf — TIME_WAIT / orphan
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_max_tw_buckets = 1440000
net.ipv4.tcp_max_orphans = 262144
net.ipv4.tcp_tw_reuse = 1            # آمن للاتصالات الصادرة
net.ipv4.ip_local_port_range = 1024 65535

tcp_tw_reuse آمن للاتصالات الصادرة فقط، وبينما الطوابع الزمنية مفعّلة؛ لا تستخدم القديم tcp_tw_recycle، فهو يكسر العملاء خلف NAT وأُزيل من النوى الحديثة أصلاً. وحين يُتجاوَز tcp_max_orphans، تغلق النواة الفائض بـ RST وتكتب too many orphaned sockets في dmesg؛ وهذا سلوك دفاعي، فاحفظ الحدّ فوق حِملك الشرعي.

5. مخازن المقابس وطابور الاستقبال

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

# /etc/sysctl.d/90-ddos.conf — buffers and receive queue
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.netdev_max_backlog = 16384      # طابور NIC ← النواة
net.core.netdev_budget = 600             # عدد الحزم المعالَجة لكل softirq
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

التحقق — هل أسقط مسار الاستقبال حزماً، هل نفد ميزان softirq:

# softnet_stat: col 1 processed, col 2 DROPPED, col 3 left by budget/time-limit
cat /proc/net/softnet_stat

# TCP-side prune / collapse (a sign of buffer pressure)
netstat -s | grep -Ei 'prune|collapse|out of'
nstat -az | grep -Ei 'TcpExtTCPRcvQDrop|PruneCalled'

إن ارتفع العمود الثاني في softnet_stat فارفع netdev_max_backlog؛ وإن ارتفع الثالث فارفع netdev_budget. والارتفاع المزمن في العمود الثالث هو أيضاً العلامة المبكّرة على أن عدد الحزم بدأ يُشبع المعالج. تلك الحدّ هي تخوم هذه المقالة، وتنتقل إلى دليل ضبط مكدّس الشبكة.

6. تزييف المصدر وICMP وسطح التوجيه

مجموعة صغيرة لكنها ضرورية. ضد عناوين المصدر المزيّفة وسطح الانعكاس:

# /etc/sysctl.d/90-ddos.conf — anti-spoof and ICMP
net.ipv4.conf.all.rp_filter = 1              # فلترة المسار العكسي (صارمة)
net.ipv4.conf.default.rp_filter = 1
net.ipv4.icmp_echo_ignore_broadcasts = 1     # أغلق سطح smurf
net.ipv4.icmp_ratelimit = 1000
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.tcp_timestamps = 1                  # لازم لـ tw_reuse وPAWS

rp_filter=1 (الوضع الصارم) صحيح فقط على خادم بوصلة واحدة. وعلى آلة ذات توجيه غير متناظر تستقبل الحركة عبر أكثر من مسار، يُسقط الوضع الصارم حزماً شرعية؛ وهناك تختار 2 (الوضع المرن). والوضع الخطأ قد يسبّب انقطاعاً بلا هجوم أصلاً؛ فلا تضع 1 دون معرفة أي وضع تحتاج:

# Effective rp_filter per interface (the max of 'all' and the interface applies)
for i in /proc/sys/net/ipv4/conf/*/rp_filter; do echo "$i = $(cat $i)"; done

# How many packets did rp_filter drop?
nstat -az | grep -i 'IPReversePathFilter'

7. تحديد المعدّل لكل مصدر عبر nftables

توسيع الطوابير هو النصف السلبي. والنصف الفاعل يحدّ حصة المصدر الواحد، داخل النواة. ومجموعة nftables الديناميكية تفعل ذلك لكل عنوان مصدر:

table inet filter {
  set flood4 { type ipv4_addr; flags dynamic; timeout 60s; }
  set flood6 { type ipv6_addr; flags dynamic; timeout 60s; }

  chain input {
    type filter hook input priority filter; policy accept;

    ct state established,related accept
    ct state invalid drop                 # أسقِط التدفّقات النصفية/التالفة

    # معدّل الاتصالات الجديدة لكل مصدر — IPv4 وIPv6 منفصلان
    tcp dport { 80, 443 } ct state new \
      add @flood4 { ip  saddr limit rate over 30/second } drop
    tcp dport { 80, 443 } ct state new \
      add @flood6 { ip6 saddr limit rate over 30/second } drop
  }
}

التحقق — أي المصادر بلغت الحدّ، وكم حزمة أسقطت القاعدة:

# Sources that hit the limit and entered the set
nft list set inet filter flood4

# Rule counters (if you add 'counter' to the rule)
nft list ruleset | grep -A2 flood

# How much did ct state invalid drop — a counted rule example
nft add rule inet filter input ct state invalid counter drop

إن تجاوزت مجموعة IPv6، غاب نصف الدفاع. والعتبة تأتي من قياسك أنت: لحشد شرعي خلف NAT قد تكون 30 قليلة جداً، ولواجهة برمجية مؤسسية قد تكون كثيرة. شغّل القاعدة بـ counter بدل drop الأسبوع الأول، وانظر من يقع، ثم انتقل إلى drop بعد أن تتأكد أنها لا تقطع حركة شرعية.

هناك أيضاً synproxy — تتولّى النواة المصافحة، ولا يبلغ الخدمةَ خلفها إلا الاتصالات المكتملة — لكن تفاعله مع التوجيه غير المتناظر وإعدادات conntrack دقيق؛ فلا تضعه في الإنتاج دون تحقّق في مختبر.

الحدّ الصادق لتحديد المعدّل لكل مصدر: يعمل ضد فيض من عناوين قليلة. أمّا فيض موزّع على آلاف العناوين، يبقى كل منها تحت العتبة لكل عنوان، فيمكنه ملء وصلتك في المجموع، وهذه القاعدة لا تراه. تناولنا صورة المنطق نفسه على مقياس البادئة في دليل القصف السجّادي.

8. سلوك الاتصال على مستوى التطبيق

الاتصال الذي يمرّ طابور النواة يبلغ التطبيق، حيث يحمل اتصالٌ منتظِر مورداً أيضاً. هذه المقالة عن النواة، لكن معامِلَي sysctl يؤثّران في سلوك التطبيق مباشرةً:

net.ipv4.tcp_keepalive_time = 300     # اكتشِف اتصالاً ميتاً باكراً
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_keepalive_probes = 3

هجمات الاتصال البطيء (فتح اتصال وتقطير البيانات) لا تُحلّ كلياً على مستوى النواة؛ والدفاع الحقيقي هو مهلات خادم الويب نفسه. نتناول ذلك لكل خادم: دليلا تصليب nginx و تصليب Apache يعطيان تلك المهلات توجيهاً بتوجيه.

الملف الكامل والتحميل دفعةً واحدة

الأقسام مجتمعةً:

sudo tee /etc/sysctl.d/90-ddos.conf >/dev/null <<'EOF'
# --- SYN ---
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 8192
net.core.somaxconn = 8192
net.ipv4.tcp_synack_retries = 2
# --- conntrack ---
net.netfilter.nf_conntrack_max = 1048576
net.netfilter.nf_conntrack_tcp_timeout_established = 3600
net.netfilter.nf_conntrack_tcp_timeout_syn_recv = 30
# --- file descriptors ---
fs.file-max = 2097152
fs.nr_open = 1048576
# --- TIME_WAIT / orphan ---
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_max_tw_buckets = 1440000
net.ipv4.tcp_max_orphans = 262144
net.ipv4.tcp_tw_reuse = 1
# --- buffers ---
net.core.netdev_max_backlog = 16384
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
# --- anti-spoof / ICMP ---
net.ipv4.conf.all.rp_filter = 1
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.tcp_timestamps = 1
EOF

sudo sysctl --system
# verify it applied
sudo sysctl -a 2>/dev/null | grep -E 'somaxconn|syncookies|conntrack_max|file-max|rp_filter'

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

العدّادات التي تُوصَل إلى المراقبة

التصليب لا يُحسّ، بل يُقرأ. أوصِل هذه الإشارات الست إلى نظام الإنذار:

# 1. SYN queue drops
nstat -az | grep -E 'ListenDrops|ListenOverflows'
# 2. SYN cookie use (an overflow indicator)
nstat -az | grep -i syncookiessent
# 3. conntrack occupancy ratio (>70% warn)
cat /proc/sys/net/netfilter/nf_conntrack_count
# 4. file descriptor use
cat /proc/sys/fs/file-nr
# 5. receive-path drops
awk '{s+=$2} END{print "softnet drops:", s}' /proc/net/softnet_stat
# 6. socket memory pressure
grep -E 'TCP:' /proc/net/sockstat

هذه الأسطر الستة تجيب، في أقل من دقيقة أثناء هجوم، عن سؤال «هل يضيق المضيف أم تمتلئ الوصلة».

الحدّ الصادق لهذه الطبقة

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

الأولى إشباع الوصلة. الحجم فوق وصلة وصولك لا يبلغ النواة أصلاً؛ وsysctl لا يُسقط حزمة لا يراها. فوق هذه الحدّ لم يعد الموضوع الخادم بل معمارية الشبكة.

الثانية معدّل الحزم. قبل امتلاء الوصلة، يستطيع عدد الحزم في الثانية أن يُشبع قدرة النواة على معالجة المقاطعات؛ والعَرَض هو العمود الثالث في softnet_stat وذهاب المعالج إلى softirq. إعدادات تلك الطبقة — توزيع المقاطعات، وطوابير المشغّل، وRSS/RPS، ومسار الاستقبال — عالمٌ منفصل، يتناوله أمراً بأمر دليل ضبط مكدّس الشبكة.

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

ترتيب التطبيق

1. سجّل خطّ الأساس (القسم 0). يكلّف أسبوع صبر؛ وهو أغلى خطوة.
2. اكتب 90-ddos.conf، وحمّله بـ sysctl --system، وتحقّق بـ grep.
3. حاذِ backlog التطبيق (listen ... backlog=) مع somaxconn.
4. أضِف حقنة LimitNOFILE إلى وحدات الخدمة، وتحقّق بـ systemctl show.
5. اضبط حجم/عمر conntrack؛ وأخرِج الخدمات عديمة الحالة من الجدول بـ notrack.
6. شغّل تحديد معدّل nftables في وضع counter أسبوعاً، ثم انتقل إلى drop.
7. أوصِل العدّادات الستة إلى المراقبة كإنذارات.

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