من يقوم بالحدّ من المعدّل، Dynamic IP Restrictions أم قاعدة جدار حماية؟

Dynamic IP Restrictions لكل ما يفهم HTTP. قاعدة جدار حماية Windows تحجب عنواناً بالجملة؛ أمّا DIPR فيعدّ الطلبات والاتصالات المتزامنة لكل مصدر عبر نافذة، ويعيد رمز حالة قابلاً للتهيئة متى تجاوز المصدر العتبة. وهذا ما تريده أمام فيضان طلبات يبدو كأنه HTTP عادي. وهو المقابل المدمج في IIS لتوجيه limit_req في nginx. ثبّت خدمة دور IP and Domain Restrictions، ثم اضبط DenyByRequestRate وDenyByConcurrentRequests، واختر رمز رفض 429 كي يقرأه العملاء والسجلات بشكل صحيح.

ما الذي يوقفه Request Filtering فعلاً؟

سطح الطلبات الضخمة، بثمن زهيد وباكراً. يحدّ requestLimits من طول المحتوى وطول عنوان URL وطول سلسلة الاستعلام وحجم الترويسة المفردة، فالطلب المبني لاستنزاف الذاكرة أو محلّل يُرفَض بترشيح على مستوى http.sys قبل أن يعالجه عامل. لن يوقف فيضاناً من طلبات بحجم عادي، فتلك مهمة Dynamic IP Restrictions، لكنه يغلق صنف الهجوم الذي يرسل طلباً واحداً ضخماً، وتشغيله لا يكلّف شيئاً.

كيف يرتبط طابور مجمّع التطبيقات بطابور http.sys؟

هما طابوران متتاليان. أولاً يقبل مشغّل النواة http.sys الاتصالات ويصفّ الطلبات؛ ولمجمّع التطبيقات بعدها queueLength خاصة به للطلبات المنتظرة عاملاً. تحت فيضان يمتلئ http.sys أولاً ويبدأ الرفض بالرمز 503 قبل أن تُشغَّل عمليات عمّال IIS أصلاً، ولهذا قد يعيد موقع 503 بينما يبدو العامل خاملاً. يتناول دليل Windows جانب http.sys؛ وهنا تحدّ طابور المجمّع وتضبط rapid-fail protection كي لا يدخل عامل ينهار في حلقة إعادة تشغيل تحت الحمل.

ما هي rapid-fail protection ولماذا تهمّ في هجوم؟

تمنع IIS من إعادة تشغيل عملية عامل بلا نهاية حين يفشل التطبيق. تحت DDoS يدفع تطبيقاً إلى أعطال متكرّرة، فإن عاملاً يُعاد تشغيله كل بضع ثوانٍ يستهلك المعالج على بدء التشغيل ولا يخدم الحركة إطلاقاً. تُخرج rapid-fail protection المجمّع من الخدمة بعد عدد محدّد من الأعطال في فترة وتعيد 503، وهو عطل أنظف من حلقة إعادة تشغيل، لأنه يفشل على نحو متوقّع بدل أن يتخبّط. اضبط عدد الأعطال والفترة كي لا يُطلقهما عطل عابر حقيقي بينما يُطلقهما هجوم.

من أين يأتي عنوان العميل خلف ARR أو موازِن حمل؟

من ترويسة X-Forwarded-For، ويجب أن يُطلَب من Dynamic IP Restrictions قراءتها وإلا نُسب كل طلب إلى الوسيط. يعرض IIS ذلك خيار "Proxy Mode" داخل Dynamic IP Restrictions، وهو يجعله يقيّم عنوان العميل المُمرَّر بدل عنوان الاتصال. وبدونه يتشارك عنوان وسيط واحد دلو معدّل واحداً ويصبح الحدّ بلا معنى، وهو نمط الفشل نفسه في nginx المفهرَس على العنوان الخطأ.

هل تُوقف هذه الإعدادات هجوماً حجمياً؟

لا. إن ملأ الهجوم الوصلة أمام الخادم فلا http.sys ولا IIS يستقبل الطلبات ولا ينطبق أي إعداد. كل ما هنا يدافع عن استنزاف معدّل الطلبات والاتصالات عند حافة التطبيق. أمّا الحجم فوق سعة الوصلة فمشكلة طبقة الشبكة ولا يُحلّ في web.config.

تحليل تقني معمّق

تصليب IIS ضد هجمات DDoS: Dynamic IP Restrictions وRequest Filtering وطابور المجمّع

آخر تحديث: أغسطس 2026 · Dynamic IP Restrictions وRequest Filtering وطابور مجمّع التطبيقات · زمن القراءة ~17 دقيقة

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

يدافع IIS فوق طابور النواة http.sys، عند طبقة التطبيق. الآليات الحاملة هي Dynamic IP Restrictions وRequest Filtering وطابور مجمّع التطبيقات: حدّ معدّل وتزامن لكل مصدر، وحدّ لحجم الطلب، وطابور محدود، وrapid-fail protection. يُضبَط في web.config أو appcmd، ويُتحقَّق منه بعدّادات Web Service، ويُقاس على أساسك أنت.

يصلّب هذا الدليل IIS نفسه ضد الجزء المستنزِف للطلبات والاتصالات من هجوم DDoS، دون أي جهاز أمامه. يقع IIS على طبقة فوق http.sys — طابور طلبات النواة الذي يتناوله دليل تصليب Windows Server — ويدافع عند طبقة التطبيق: حدود لكل مصدر، وحدود لحجم الطلب، وطابور عمّال محدود يفشل على نحو متوقّع بدل أن يتخبّط.

كل إعداد يأتي مرةً مقطعَ web.config ومرةً أمر appcmd أو PowerShell، مع عدّاد الأداء الذي يُظهر عمله.

أشكال الهجوم وآليات IIS التي تجيب عنها

الجهاز	شكل الهجوم	آلية IIS
فيضان طلبات من مصادر قليلة	Dynamic IP Restrictions: DenyByRequestRate	\Web Service\Total Requests؛ DIPR يسجّل 429
اتصالات كثيرة لكل مصدر	Dynamic IP Restrictions: maxConnections	\Web Service\Current Connections
رأس بطيء (Slowloris)	http.sys headerWaitTimeout؛ connectionTimeout	عدّادات HTTP Service Request Queues
إساءة الطلبات الضخمة	Request Filtering: requestLimits	404.13 / 404.14 / 404.15 في السجل
استنزاف العمّال / حلقة الأعطال	App pool queueLength؛ rapid-fail protection	\W3SVC_W3WP\Requests / Sec؛ نسبة 503

يقع IIS فوق http.sys، طابور النواة الذي يتناوله دليل Windows. هذه الآليات تدافع عن التطبيق، ولا ينفع شيء منها متى ملأ الهجوم الوصلة أمام الخادم.

0. الأساس أولاً: اقرأ عدّادات Web Service

حالة IIS تعيش في مجموعتَي عدّادات الأداء Web Service وW3SVC_W3WP. سجّل أسبوعاً عادياً.

# الاتصالات الحالية ومعدّل الطلبات عبر كل المواقع
Get-Counter '\Web Service(_Total)\Current Connections',
            '\Web Service(_Total)\Total Method Requests/sec' -SampleInterval 5 -MaxSamples 3

# معدّل الطلبات لكل عامل وطابور http.sys
Get-Counter '\W3SVC_W3WP(*)\Requests / Sec',
            '\HTTP Service Request Queues(*)\CurrentQueueSize'

# عدد الطلبات لكل عميل من سجل IIS (اضبط ترتيب الحقل بحسب صيغة سجلك)
Import-Csv -Delimiter ' ' C:\inetpub\logs\LogFiles\W3SVC1\*.log -Header (1..20) |
  Group-Object 'H10' | Sort-Object Count -Descending | Select-Object -First 10

قيمة Current Connections ومعدّل الطلبات لكل عميل هما الأساس الذي تُقاس عليه كل عتبة أدناه.

1. Dynamic IP Restrictions: المعدّل والتزامن لكل مصدر

Dynamic IP Restrictions (DIPR) هو دفاع IIS ضد فيضان الطلبات، والمقابل المدمج لتوجيه limit_req في nginx. يتطلّب خدمة دور IP and Domain Restrictions، ثم حدّ معدّل وحدّ تزامن.

<!-- web.config أو applicationHost.config -->
<system.webServer>
  <security>
    <dynamicIpSecurity enableLoggingOnlyMode="true">
      <!-- التزامن: أقصى طلبات متزامنة لكل مصدر -->
      <denyByConcurrentRequests enabled="true" maxConcurrentRequests="20" />
      <!-- المعدّل: أقصى طلبات لكل مصدر في نافذة زمنية (ملّي ثانية) -->
      <denyByRequestRate enabled="true" maxRequests="100" requestIntervalInMilliseconds="2000" />
    </dynamicIpSecurity>
  </security>
</system.webServer>

# نفسه عبر appcmd
appcmd set config /section:system.webServer/security/dynamicIpSecurity `
  /denyByRequestRate.enabled:true /denyByRequestRate.maxRequests:100 `
  /denyByRequestRate.requestIntervalInMilliseconds:2000

# ارفض بالرمز 429 كي تقرأه السجلات والعملاء صحيحاً (الافتراضي 403)
appcmd set config /section:system.webServer/security/dynamicIpSecurity `
  /denyAction:"TooManyRequests"

لاحظ enableLoggingOnlyMode="true" أعلاه — هذا هو التشغيل التجريبي في IIS. يكتب في السجل ما كان سيحجبه دون أن يحجب، تماماً كتوجيه limit_req_dry_run في nginx. أبقِه مفعّلاً أسبوعاً ممثِّلاً، وتأكّد أن المصادر التي كان سيرفضها ليست حركتك الحقيقية، ثم اضبطه على false كي يُنفَّذ.

# تأكيد ما كان سيحجبه وضع التسجيل فقط
Get-Counter '\Web Service(_Total)\Total Requests'
# أحداث DIPR تظهر في سجل IIS برمز الرفض الذي هيّأته

2. Proxy Mode: عنوان العميل خلف ARR أو موازِن حمل

يُفهرَس DIPR على عنوان الاتصال. وخلف وسيط يكون هذا عنوان الوسيط ما لم تفعّل proxy mode لقراءة X-Forwarded-For.

<dynamicIpSecurity>
  <denyByRequestRate enabled="true" maxRequests="100" requestIntervalInMilliseconds="2000" />
  <!-- قيّم عنوان العميل المُمرَّر لا اتصال الوسيط -->
  <proxyMode enabled="true" />
</dynamicIpSecurity>

بدون proxy mode يتشارك كل طلب دلو وسيط واحداً ولا يحمي الحدّ شيئاً، وهو نمط الفشل نفسه في real_ip سيّئ الضبط في nginx.

3. Request Filtering: سطح الطلبات الضخمة

يحدّ Request Filtering أبعاد الطلب على مستوى أدنى من التطبيق، فيرفض طلباً ضخماً قبل أن يحلّله عامل.

<system.webServer>
  <security>
    <requestFiltering>
      <requestLimits maxAllowedContentLength="10485760"  <!-- 10 MB -->
                     maxUrl="4096"
                     maxQueryString="2048">
        <headerLimits>
          <add header="Content-type" sizeLimit="100" />
        </headerLimits>
      </requestLimits>
    </requestFiltering>
  </security>
</system.webServer>

appcmd set config /section:requestFiltering `
  /requestLimits.maxAllowedContentLength:10485760 /requestLimits.maxUrl:4096

تظهر حالات الرفض في السجل رموزاً فرعية: 404.13 (طول المحتوى)، 404.14 (عنوان URL)، 404.15 (سلسلة الاستعلام). راقبها قياساً على أساسك.

Select-String -Path C:\inetpub\logs\LogFiles\W3SVC1\*.log -Pattern ' 404 1[345] ' | Measure-Object

4. طابور مجمّع التطبيقات وrapid-fail protection

لمجمّع التطبيقات طابور طلباته الخاص ومعالجته الخاصة للأعطال. حدّ الطابور كي يفشل الفيضان على نحو متوقّع، واضبط rapid-fail كي لا يدخل تطبيق ينهار في حلقة إعادة تشغيل.

# طول الطابور: عدد الطلبات المسموح لها بانتظار عامل قبل 503
Set-ItemProperty "IIS:\AppPools\DefaultAppPool" -Name queueLength -Value 4000

# Rapid-fail: أخرِج المجمّع من الخدمة بعد N عطل في فترة، لا تتخبّط
Set-ItemProperty "IIS:\AppPools\DefaultAppPool" -Name failure.rapidFailProtection -Value $true
Set-ItemProperty "IIS:\AppPools\DefaultAppPool" -Name failure.rapidFailProtectionMaxCrashes -Value 5
Set-ItemProperty "IIS:\AppPools\DefaultAppPool" -Name failure.rapidFailProtectionInterval -Value "00:05:00"

# أعِد التدوير على جدول لا على عدد طلبات ثابت، لتفادي إعادة تدوير وسط الهجوم
Set-ItemProperty "IIS:\AppPools\DefaultAppPool" -Name recycling.periodicRestart.requests -Value 0

# تحديد المعالج: حدّ المجمّع أو اخنقه بدل ترك موقع واحد يجوّع الجهاز
Set-ItemProperty "IIS:\AppPools\DefaultAppPool" -Name cpu.limit -Value 80000   # 80%
Set-ItemProperty "IIS:\AppPools\DefaultAppPool" -Name cpu.action -Value Throttle

# حالات 503 من طابور ممتلئ أو مجمّع خارج الخدمة
Get-Counter '\W3SVC_W3WP(*)\Total HTTP Requests Served'
Select-String -Path C:\inetpub\logs\LogFiles\W3SVC1\*.log -Pattern ' 503 ' | Measure-Object

نسبة 503 المرتفعة بينما يبدو العمّال خاملين تعني أن الطابور أو http.sys يرفض فوق العامل، وهي علامة أن معدّل الطلبات فاق ما يُسمَح للمجمّع بامتصاصه.

5. مهل الاتصال

مهلة الاتصال ومهلة انتظار الرأس في http.sys تطردان الاتصالات البطيئة. ومهلة انتظار الرأس هي دفاع Slowloris المواجِه لـ IIS، وتُضبَط على طبقة http.sys.

# مهلة اتصال الموقع (خمول)
Set-WebConfigurationProperty -Filter system.applicationHost/sites/siteDefaults/limits `
  -Name connectionTimeout -Value "00:01:00"

# مهلة انتظار الرأس في http.sys — السجل، معاملات خدمة HTTP
# (على مستوى نظام التشغيل في دليل Windows؛ هذا هو المفتاح المتعلّق بـ IIS)

الإشارات التي تُربط بالمراقبة

Get-Counter @(
  '\Web Service(_Total)\Current Connections',
  '\Web Service(_Total)\Total Method Requests/sec',
  '\HTTP Service Request Queues(_Total)\CurrentQueueSize',
  '\HTTP Service Request Queues(_Total)\RejectedRequests',
  '\W3SVC_W3WP(_Total)\Requests / Sec'
) -SampleInterval 5 -MaxSamples 1

ارتفاع Current Connections مع معدّل طلبات مستوٍ هجومُ احتجاز اتصالات. وارتفاع RejectedRequests هو http.sys يطرح الحمل قبل IIS. ونسبة 503 مع عمّال خاملين طابورُ المجمّع ممتلئ. كلٌّ يشير إلى حدّ مختلف.

الحدّ الصادق لتصليب IIS

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

الأولى امتلاء الوصلة: الحجم الذي يملأ الأنبوب لا يصل إلى http.sys أصلاً، فضلاً عن IIS.

تحت الوصلة لحدود IIS نصيب؛ وفوقها لا معنى لأي إعداد.

والثانية الطبقة تحت IIS: مكدّس TCP في Windows، وWFP، وطابور http.sys، الذي يمرّ به الطلب قبل أن يراه عامل، ويتناوله دليل تصليب Windows Server. ويفترض تصليب IIS أن تلك الطبقة قائمة. وفوق الوصلة يكون الجواب طبقة الشبكة، ويُبقي IIS حافة التطبيق قائمة حتى ذلك الحين.

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

سجّل الأساس (القسم 0): الاتصالات، معدّل الطلبات، طابور http.sys.
ثبّت IP and Domain Restrictions؛ أضِف معدّل DIPR وتزامنه في وضع التسجيل فقط.
فعّل proxy mode إن وُجد وسيط أمامك، قبل أن تثق بالحدود.
راقب وضع التسجيل فقط أسبوعاً؛ ثم فعّل التنفيذ.
أضِف حدود Request Filtering.
حدّ طابور المجمّع واضبط rapid-fail protection وتحديد المعالج.
اربط العدّادات بالمراقبة.

الخطوة الثالثة تسبق التنفيذ للسبب نفسه في nginx: حدٌّ لكل مصدر مفهرَس على عنوان الوسيط لا يحمي شيئاً بينما يبدو حمايةً.

أسئلة متكررة

من يقوم بالحدّ من المعدّل، Dynamic IP Restrictions أم قاعدة جدار حماية؟: Dynamic IP Restrictions لكل ما يفهم HTTP. قاعدة جدار حماية Windows تحجب عنواناً بالجملة؛ أمّا DIPR فيعدّ الطلبات والاتصالات المتزامنة لكل مصدر عبر نافذة، ويعيد رمز حالة قابلاً للتهيئة متى تجاوز المصدر العتبة. وهذا ما تريده أمام فيضان طلبات يبدو كأنه HTTP عادي. وهو المقابل المدمج في IIS لتوجيه limit_req في nginx. ثبّت خدمة دور IP and Domain Restrictions، ثم اضبط DenyByRequestRate وDenyByConcurrentRequests، واختر رمز رفض 429 كي يقرأه العملاء والسجلات بشكل صحيح.
ما الذي يوقفه Request Filtering فعلاً؟: سطح الطلبات الضخمة، بثمن زهيد وباكراً. يحدّ requestLimits من طول المحتوى وطول عنوان URL وطول سلسلة الاستعلام وحجم الترويسة المفردة، فالطلب المبني لاستنزاف الذاكرة أو محلّل يُرفَض بترشيح على مستوى http.sys قبل أن يعالجه عامل. لن يوقف فيضاناً من طلبات بحجم عادي، فتلك مهمة Dynamic IP Restrictions، لكنه يغلق صنف الهجوم الذي يرسل طلباً واحداً ضخماً، وتشغيله لا يكلّف شيئاً.
كيف يرتبط طابور مجمّع التطبيقات بطابور http.sys؟: هما طابوران متتاليان. أولاً يقبل مشغّل النواة http.sys الاتصالات ويصفّ الطلبات؛ ولمجمّع التطبيقات بعدها queueLength خاصة به للطلبات المنتظرة عاملاً. تحت فيضان يمتلئ http.sys أولاً ويبدأ الرفض بالرمز 503 قبل أن تُشغَّل عمليات عمّال IIS أصلاً، ولهذا قد يعيد موقع 503 بينما يبدو العامل خاملاً. يتناول دليل Windows جانب http.sys؛ وهنا تحدّ طابور المجمّع وتضبط rapid-fail protection كي لا يدخل عامل ينهار في حلقة إعادة تشغيل تحت الحمل.
ما هي rapid-fail protection ولماذا تهمّ في هجوم؟: تمنع IIS من إعادة تشغيل عملية عامل بلا نهاية حين يفشل التطبيق. تحت DDoS يدفع تطبيقاً إلى أعطال متكرّرة، فإن عاملاً يُعاد تشغيله كل بضع ثوانٍ يستهلك المعالج على بدء التشغيل ولا يخدم الحركة إطلاقاً. تُخرج rapid-fail protection المجمّع من الخدمة بعد عدد محدّد من الأعطال في فترة وتعيد 503، وهو عطل أنظف من حلقة إعادة تشغيل، لأنه يفشل على نحو متوقّع بدل أن يتخبّط. اضبط عدد الأعطال والفترة كي لا يُطلقهما عطل عابر حقيقي بينما يُطلقهما هجوم.
من أين يأتي عنوان العميل خلف ARR أو موازِن حمل؟: من ترويسة X-Forwarded-For، ويجب أن يُطلَب من Dynamic IP Restrictions قراءتها وإلا نُسب كل طلب إلى الوسيط. يعرض IIS ذلك خيار "Proxy Mode" داخل Dynamic IP Restrictions، وهو يجعله يقيّم عنوان العميل المُمرَّر بدل عنوان الاتصال. وبدونه يتشارك عنوان وسيط واحد دلو معدّل واحداً ويصبح الحدّ بلا معنى، وهو نمط الفشل نفسه في nginx المفهرَس على العنوان الخطأ.
هل تُوقف هذه الإعدادات هجوماً حجمياً؟: لا. إن ملأ الهجوم الوصلة أمام الخادم فلا http.sys ولا IIS يستقبل الطلبات ولا ينطبق أي إعداد. كل ما هنا يدافع عن استنزاف معدّل الطلبات والاتصالات عند حافة التطبيق. أمّا الحجم فوق سعة الوصلة فمشكلة طبقة الشبكة ولا يُحلّ في web.config.

النشر: أغسطس 2026

يُحدَّث هذا الدليل كلما طرح المصنّعون طرازات وشروط ترخيص جديدة. كيف نقارن بين المصنّعين