تصليب Windows Server ضد DDoS: ما الذي يبقى للضبط وما الذي يتولّاه النظام أصلاً

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

أنفع ما يُعرَف عن تصليب Windows ضد DDoS هو ما لا يُفعَل. مفاتيح التسجيل SynAttackProtect وTcpMaxHalfOpen وTcpMaxHalfOpenRetried وقيمة TcpWindowSize المثبّتة، التي تملأ الأدلة القديمة، إمّا أُزيلت بعد Windows Server 2003 أو تجاوزها الضبط التلقائي. ضبطها في أحسن الأحوال لا يفعل شيئاً. وتثبيت حجم النافذة يكسر فعلياً ضبط المكدّس لكل اتصال.

الجهاز	نصيحة قديمة (لا تتّبعها)	لماذا بطلت	ما البديل
SynAttackProtect	اضبط SynAttackProtect=2 في التسجيل	أُزيل بعد Server 2003؛ حماية SYN تلقائية	تحقّق بـ netstat؛ حُدّ المعدّل في WFP عند الحاجة
TcpMaxHalfOpen	حُدّ الاتصالات نصف المفتوحة في التسجيل	المكدّس لم يعد يقرأ هذه القيمة	راقب بـ Get-NetTCPConnection -State SynReceived
نافذة استقبال TCP	ثبّت TcpWindowSize	منذ Vista/2008 يحدّد الضبط التلقائي الحجم لكل اتصال	قالب Set-NetTCPSetting، لا قيمة مثبّتة
حدود الاتصالات	اعتمد على افتراض النظام	الافتراض سخيّ؛ لا شيء يحدّ بحسب المصدر	مرشّح WFP أو قاعدة جدار حماية بحسب عنوان المصدر

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

0. القيم الأساسية أولاً: اقرأ العدّادات قبل أن تغيّر شيئاً

يُظهر Windows حالته عبر عدّادات الأداء وأوامر Get-Net* لا عبر /proc. سجّل أسبوعاً عادياً من هذه:

# عدد الاتصالات بحسب حالة TCP (صف SynReceived هو backlog نصف المفتوح لديك)
Get-NetTCPConnection | Group-Object -Property State | Sort-Object Count -Descending

# عدّادات مكدّس TCP: القطع، وإعادة التعيين، والاتصالات الفاشلة
Get-Counter '\TCPv4\*' -SampleInterval 5 -MaxSamples 3

# القالب النشط للاتصال ومستوى الضبط التلقائي فيه
Get-NetTCPSetting -SettingName Internet | Format-List *

# حالة RSS البطاقة وعدد الطوابير
Get-NetAdapterRss | Format-Table Name, Enabled, NumberOfReceiveQueues

احفظ هذا الخرج. كل حكم أدناه نسبيّ إليه. «عدد SynReceived مرتفع» لا يعني شيئاً إلا قياساً على رقم أسبوع عادي.

1. مكدّس TCP: قوالب لا مفاتيح تسجيل

لا يعرض Windows Server الحديث قيم TCP العددية القديمة في التسجيل بوصفها سطح الضبط. بل يطبّق قالباً لكل نوع اتصال، وأنت تعدّل القالب. القوالب هي Internet وDatacenter وDatacenter Custom وInternet Custom وCompat.

# اعرض كل إعداد يطبّقه القالب النشط
Get-NetTCPSetting -SettingName Internet

# نافذة استقبال الضبط التلقائي — اتركها على 'normal' ما لم يكن لديك سبب مقيس
Set-NetTCPSetting -SettingName InternetCustom -AutoTuningLevelLocal Normal

# تأكّد أن الضبط التلقائي غير معطَّل بنصّ تصليب قديم (اكتشاف شائع)
Get-NetTCPSetting | Format-Table SettingName, AutoTuningLevelLocal
netsh int tcp show global

أشيع مشكلة حقيقية على خادم Windows مُدقَّق ليست تعديلاً ناقصاً. إنها نصّ تصليب قديم عطّل الضبط التلقائي بأمر netsh int tcp set global autotuninglevel=disabled. ذلك السطر الواحد يُبقي نافذة الاستقبال على قيمة صغيرة ثابتة ويخنق كل اتصال شرعي. وإعادة تفعيله عادةً أكبر تحسين منفرد:

netsh int tcp set global autotuninglevel=normal

حماية فيضان SYN نفسها تلقائية، ولا يمكن تحسينها تحسيناً ذا معنى من التسجيل على نظام مدعوم. لا تضبطها، بل تتحقّق من أنها تتحمّل:

# الاتصالات نصف المفتوحة الآن
(Get-NetTCPConnection -State SynReceived).Count

# محاولات الاتصال الفاشلة وإعادات التعيين، من عدّادات المكدّس
Get-Counter '\TCPv4\Connection Failures','\TCPv4\Connections Reset'

إن تسلّق عدد SynReceived نحو عشرات الآلاف أثناء حدث، فالجواب ليس مفتاح تسجيل. الجواب حدٌّ بحسب المصدر في طبقة WFP أو في طبقة عليا، كما يلي.

2. Windows Filtering Platform: حيث يعيش الحدّ بحسب المصدر

يفعل Linux الحدّ بحسب المصدر بمجموعة nftables ديناميكية. المكافئ في Windows يعيش داخل Windows Filtering Platform، ووجهه المتاح لأكثر المشغّلين قاعدة جدار حماية. لا يوجد عنصر مدمج بصيغة «N اتصالاً في الثانية لكل مصدر» بنظافة عنصر nftables. لذا فالنمط العملي حجبٌ محدود النطاق يقوده الرصد، مع قواعد أمان اتصال تضيّق السطح المكشوف.

# احجب مصدراً خبيثاً بعينه (ما يستدعيه مستجيب آلي)
New-NetFirewallRule -DisplayName "DDoS-block-203.0.113.0/24" -Direction Inbound `
  -RemoteAddress 203.0.113.0/24 -Action Block

# قصّ خدمة على العناوين التي يجدر أن تبلغها فقط — أكبر تقليص منفرد
# لسطح الهجوم، ولا يحتاج أي منطق معدّل
New-NetFirewallRule -DisplayName "RDP-restrict" -Direction Inbound -Protocol TCP `
  -LocalPort 3389 -RemoteAddress 10.0.0.0/8 -Action Allow

# افحص ما هو مفعّل فعلاً
Get-NetFirewallRule -Enabled True -Direction Inbound |
  Where-Object Action -eq Allow | Format-Table DisplayName, Profile

الحدّ الصادق هو التالي. جدار حماية Windows وحده لا يحدّ معدّل الاتصالات الجديدة بحسب المصدر كما تفعل مجموعة nftables. وحيث يلزم ذلك، يأتي الحلّ من مشغّل callout في WFP، أو طبقة طرف ثالث، أو — الجواب الحقيقي المعتاد على أي مقياس — الطبقة الشبكية أمام المضيف. أقوى إسهام لجدار الحماية في الصمود ضد DDoS ليس حدّ المعدّل. إنه تقليص السطح، أي ضمان أن كل منفذ مُصغٍ لا يُبلَغ إلا من حيث ينبغي.

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

Get-NetIPsecRule | Format-Table DisplayName, Enabled, Profile

3. http.sys: طابور طلبات النواة أمام IIS

لأي حمل HTTP، أول طابور يضربه فيضان الطلبات ليس IIS. إنه http.sys، مشغّل وضع النواة الذي يقبل طلبات HTTP ويصفّها قبل أن تراها عملية عامل. معاملاته تعيش تحت خدمة HTTP، وطابوره مورد منفصل عن كل ما يهيّئه IIS.

# طوابير طلبات النواة وعمقها
Get-Counter '\HTTP Service Request Queues(*)\CurrentQueueSize'
Get-Counter '\HTTP Service Request Queues(*)\RejectedRequests'

السلوكات الأساسية للفهم هي طول طابور الطلبات، ومهلة الاتصال، ومهلة انتظار الترويسة. وتُترك غالباً على الافتراض ما لم يُثبت عدّاد خلاف ذلك. مهلة انتظار الترويسة هي دفاع مستوى http.sys ضد هجمات الترويسة البطيئة (فتح اتصال وإرسال الترويسات بايتاً بايتاً). يُسقط المشغّل اتصالاً لم يُكمل ترويساته ضمن المهلة، قبل أن يخصّص IIS له عاملاً أصلاً.

إعدادات جانب IIS — طول طابور مجمّع التطبيقات، وقيود IP الديناميكية، وترشيح الطلبات — طبقة منفصلة لها دليل تصليب IIS الخاص بها. والمهمّ هنا أن http.sys هو الطابور تحت IIS. قد يبقى موقع قائماً بينما العامل مشبع لأن http.sys يمتصّ؛ أو يسقط بينما يبدو العامل خاملاً لأن http.sys يرفض.

4. Receive Side Scaling: دفاع معدّل الحزم

قبل أن تمتلئ الوصلة، قد يثبّت معدّل حزم مرتفع نواة معالج واحدة عند مئة بالمئة على معالجة المقاطعات بينما تخمل البقية. الحلّ في Windows هو Receive Side Scaling الذي يوزّع معالجة الحزم الواردة على الأنوية. على البطاقات المادية يكون مفعّلاً عادةً. وعلى الافتراضية يكون كثيراً معطَّلاً أو ناقص الطوابير في الافتراض، وفي ذلك الافتراض بالذات تخسر آلة Windows الافتراضية بصمت أمام هجوم معدّل حزم دون نطاقها الاسمي بكثير.

# هل RSS مفعّل، وكم طابوراً؟
Get-NetAdapterRss -Name * | Format-Table Name, Enabled, NumberOfReceiveQueues, MaxProcessors

# فعّل وأعطِ طوابير كافية (بحسب الأنوية المتاحة)
Enable-NetAdapterRss -Name "Ethernet"
Set-NetAdapterRss -Name "Ethernet" -NumberOfReceiveQueues 8

# راقب حمل المقاطعات لكل معالج أثناء اختبار — نواة ساخنة واحدة تعني أن RSS لا يوزّع
Get-Counter '\Processor(*)\% Interrupt Time' -SampleInterval 2 -MaxSamples 5

# قد يفيد Receive Segment Coalescing سعة التمرير لكنه يضرّ الأحمال الحسّاسة للتأخير؛ قِس
Get-NetAdapterRsc | Format-Table Name, IPv4Enabled, IPv6Enabled

نواة ساخنة واحدة تحت الحمل، والبقية خاملة، هي توقيع أن RSS لا يؤدّي عمله. وهذا هو المكافئ الدقيق في Windows لتسلّق العمود الثالث في softnet_stat بـ Linux.

5. سلوك الاتصال في طبقة التطبيق

عنصران على مستوى المضيف يدعمان أي خادم وِب فوقهما. يكشف TCP keep-alive الاتصالات الميتة ويستعيدها، ويحكم مدى المنافذ الديناميكية كم اتصالاً صادراً أو عابراً يستطيع المضيف أن يديمه:

# مدى المنافذ العابرة — وسّعه إن كان المضيف يجري اتصالات صادرة كثيرة
netsh int ipv4 show dynamicport tcp
netsh int ipv4 set dynamicport tcp start=1024 num=64511

# TCP keep-alive إعداد مكدّس لكل اتصال؛ القالب يحمله
Get-NetTCPSetting -SettingName Internet | Select-Object SettingName, *KeepAlive*

هجمات الاتصال البطيء يجيب عنها في النهاية لا النظام، بل مهل خادم الوِب نفسه. وهي لـ IIS في دليل IIS، ولـ nginx أو Apache على Windows في دليليهما.

العدّادات التي تُربط بالمراقبة

تصليب Windows، كـ Linux، يُقرأ من العدّادات لا يُحسّ. اربط هذه بنظام المراقبة:

# قراءة صحّة واحدة يستطيع مستجيب استدعاءها
Get-Counter @(
  '\TCPv4\Connection Failures',
  '\TCPv4\Connections Reset',
  '\HTTP Service Request Queues(_Total)\CurrentQueueSize',
  '\HTTP Service Request Queues(_Total)\RejectedRequests',
  '\Processor(_Total)\% Interrupt Time'
) -SampleInterval 5 -MaxSamples 1

# backlog نصف المفتوح رقماً واحداً
(Get-NetTCPConnection -State SynReceived).Count

تجيب هذه أثناء الهجوم عن السؤال نفسه الذي تجيب عنه عدّادات Linux. أيضيق المضيف أم تمتلئ الوصلة؟

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

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

الأولى إشباع الوصلة. الحجم فوق وصلة الوصول لا يبلغ مكدّس Windows أصلاً، ولا قالب ولا قاعدة جدار حماية ولا طابور RSS يغيّر ذلك.

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

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

1. سجّل القيم الأساسية (القسم 0): الاتصالات بحسب الحالة، وعدّادات TCP، والقالب، وحالة RSS.
2. تأكّد أن الضبط التلقائي غير معطَّل بنصّ قديم؛ فعّله إن كان كذلك. هذا أشيع مكسب منفرد.
3. قلّص سطح جدار الحماية: كل منفذ مُصغٍ لا يُبلَغ إلا من حيث ينبغي.
4. تحقّق أن RSS مفعّل وله طوابير كافية، خصوصاً على البطاقات الافتراضية.
5. اترك http.sys وقالب TCP على الافتراض ما لم يُثبت عدّاد اختناقاً بعينه.
6. اربط العدّادات بالمراقبة إنذاراتٍ.

انتبه لما يغيب عن هذه القائمة: قسم تسجيل طويل. على Windows Server مدعوم، ذلك القسم علامة دليل كُتب قبل عشرين عاماً.