IIS Sıkılaştırma: İstek Sınırları, Kuyruklar ve Yavaş İstemciler

IIS’te bir isteğin geçtiği yol üç katmandan oluşur ve sıkılaştırma yazılarının çoğu yalnızca en üsttekinden söz eder.

İstek önce çekirdek modundaki HTTP.sys sürücüsüne düşer. Oradan ilgili uygulama havuzunun istek kuyruğuna aktarılır. Ancak bundan sonra site ve uygulama düzeyindeki modüller devreye girer.

Yük altında ilk dolan yer genellikle en alttaki katmandır ve IIS Yöneticisi ekranından bakan biri bunu göremez. Kuyruk dolduğunda dönen 503 Service Unavailable yanıtı uygulamadan değil, ona hiç ulaşmamış bir istekten gelir.

Dinamik IP Kısıtlama

IIS’in kaynak başına sınır koyabilen tek yerleşik aracı budur ve varsayılan kurulumda gelmez. Sunucu Yöneticisi üzerinden “IP and Domain Restrictions” rolü eklenerek kurulur.

<system.webServer>
  <security>
    <dynamicIpSecurity enableLoggingOnlyMode="true">
      <denyByConcurrentRequests enabled="true" maxConcurrentRequests="20" />
      <denyByRequestRate enabled="true" maxRequests="60" requestIntervalInMilliseconds="2000" />
    </dynamicIpSecurity>
  </security>
</system.webServer>

enableLoggingOnlyMode="true" satırı en önemlisidir. Sınırı önce reddetmeden çalıştırın. Bir hafta boyunca hangi isteklerin eşiği aştığını kaydedin; içinde tanıdığınız kullanıcılar varsa eşik dardır. Yanlış pozitif ölçülmediği sürece görünmez kalır ve saldırı anında öğrenilir.

İki sınır farklı şeyleri ölçer. denyByConcurrentRequests aynı anda kaç isteğin açık olduğuna bakar ve yavaş istemcilere karşı işe yarar. denyByRequestRate belirli bir zaman aralığındaki istek sayısını sayar ve hızlı sele karşı.

Vekil Arkasında

<dynamicIpSecurity enableProxyMode="true" ... />

enableProxyMode, kaynak adresi X-Forwarded-For başlığından okur. Bu ayar olmadan yük dengeleyici arkasındaki bir kurulumda bütün trafik tek adresten geliyor gibi görünür ve ilk yoğunlukta kendi dengeleyicinizi engellersiniz.

Karşılığında bir risk gelir: başlık istemci tarafından uydurulabilir. Bu yüzden vekil kipi yalnızca önünüzde gerçekten güvenilir bir katman varsa ve o katman başlığı kendisi yazıyorsa açılır.

Yavaş İstemciler

Yavaş istek saldırısı bağlantıyı açar ve veriyi damla damla gönderir. IIS tarafındaki savunma iki ayarda toplanır.

<system.applicationHost>
  <webLimits
    connectionTimeout="00:00:30"
    headerWaitTimeout="00:00:15"
    minBytesPerSecond="500" />
</system.applicationHost>

minBytesPerSecond bunların en etkilisidir: yanıt gönderilirken istemcinin bu hızın altına düşmesi bağlantıyı kapatır. Varsayılan değeri düşüktür ve yavaş okuma saldırılarına yer bırakır. Yükseltirken gerçekten yavaş bağlantılardan gelen kullanıcılarınızı düşünün — mobil ağdan büyük dosya indiren biri de bu eşiğe takılabilir.

headerWaitTimeout, başlıkların tamamının ne kadar sürede gelmesi gerektiğini söyler. Klasik yavaş başlık saldırısının hedefi tam olarak bu süredir.

İstek Filtreleme

İşlenmeden reddedilen istek, en ucuz reddedilen istektir. İstek filtreleme modülü bunu HTTP.sys’e yakın bir noktada yapar.

<security>
  <requestFiltering>
    <requestLimits maxAllowedContentLength="10485760"
                   maxUrl="2048"
                   maxQueryString="1024" />
    <verbs allowUnlisted="false">
      <add verb="GET"  allowed="true" />
      <add verb="POST" allowed="true" />
      <add verb="HEAD" allowed="true" />
    </verbs>
  </requestFiltering>
</security>

Değerler uygulamanızın gerçek ihtiyacına göre daraltılır. Dosya yüklemesi olmayan bir uygulamada içerik uzunluğu tavanının on megabayt olmasının bir sebebi yoktur; bir megabayt hem yeterlidir hem saldırı yüzeyini küçültür.

Yöntem listesini kapatmak da benzer bir kazanç sağlar. Kullanılmayan HTTP yöntemleri hiç işlenmez.

Uygulama Havuzu

%windir%\system32\inetsrv\appcmd set apppool "SiteAppPool" ^
  /queueLength:5000 ^
  /failure.rapidFailProtection:true ^
  /failure.rapidFailProtectionMaxCrashes:5 ^
  /processModel.pingingEnabled:true

queueLength, HTTP.sys’in bu havuz için tutacağı istek sayısıdır ve varsayılanı çoğu kurulumda 1000’dir. Dolduğunda gelen istekler 503 alır.

Yükseltmek her zaman doğru değildir. Kuyruğu büyütmek, uygulamanın yetişemediği durumda isteklerin daha uzun beklemesi demektir; kullanıcı açısından bu, hızlı bir hata yerine uzun bir donma olur. Doğru değer, uygulamanın gerçekten toparlayabileceği kadar bekleyeni tutan değerdir.

Hızlı hata koruması ise ayrı bir denge kurar. Art arda çöken bir havuzu durdurmak, sağlıksız bir uygulamayı sürekli yeniden başlatmaktan iyidir — ama eşik çok düşükse geçici bir dalgalanma siteyi tamamen kapatır.

Ne İzlenmeli

Sayaç	Nerede	Ne söyler
HTTP Service Request Queues \ CurrentQueueSize	Perfmon	Çekirdek kuyruğunun doluluğu
HTTP Service Request Queues \ RejectedRequests	Perfmon	Kuyruk taşması nedeniyle reddedilen
Web Service \ Current Connections	Perfmon	Eşzamanlı bağlantı
W3SVC_W3WP \ Requests / Sec	Perfmon	İstek hızı, temel ölçülerle karşılaştırılır
sc-status 503 oranı	IIS logu	Uygulamaya ulaşmadan reddedilen istek

Son satır önemlidir: IIS loglarındaki 503 yanıtlarının oranı, uygulamanın değil kuyruğun sorunlu olduğunu gösteren en hızlı işarettir.

Sıralama

IIS ayarları, işletim sistemi tarafındaki kaynak sınırlarının üstüne oturur. Dinamik port aralığı, zaman aşımları ve TCP tarafı Windows Server sıkılaştırma rehberindedir; ikisi birlikte yapılandırılmadığında biri diğerinin darboğazına takılır.

Ve buradaki hiçbir ayar hacimsel saldırıyı karşılamaz. Erişim hattı dolduğunda istekler IIS’e hiç ulaşmaz.