DDoS dayanıklılığı için hangi MPM'i çalıştırmalıyım?

Neredeyse her durumda event. prefork bağlantı başına bir süreç çalıştırır, dolayısıyla birkaç bin yavaş bağlantı süreç havuzunu tüketir. Klasik Slowloris sonucu budur. prefork daha çok eski mod_php gibi iş parçacığına güvenli olmayan modüller için vardır. event ve worker ise iş parçacığı ve keep-alive bağlantılarını devralan ayrı bir dinleyici kullanır, böylece yavaş bir bağlantı koca bir süreç değil tek bir yuva harcar. prefork'ta yalnızca mod_php yüzünden kaldıysanız, PHP'yi PHP-FPM'e taşımak event'e geçmenizi sağlar ve buradaki en büyük kazançtır.

mod_reqtimeout Slowloris'e karşı tek başına yeter mi?

event üstünde neredeyse yeter, prefork'ta yardımcı olur ama MPM sizi yine sınırlar. RequestReadTimeout bir istemcinin istek satırını ve başlıklarını göndermesine tanınan süreyi sınırlar, böylece başlığı damla damla gönderen bir bağlantı açık tutulmak yerine sürede düşer. Doğrudan Slowloris cevabı budur. Ancak prefork'ta tutulan her bağlantı süre dolana kadar koca bir süreçtir, o yüzden süre kısa olmalı ve süreç havuzu yine tavandır. event üstünde aynı süre çok daha etkilidir, çünkü askıda kalan bağlantının maliyeti baştan düşüktür.

mod_evasive mi mod_qos mu gerekir?

İkisi farklı biçimleri çözer ve çoğu site ikisini birlikte çalıştırır. mod_evasive kısa bir pencerede kaynak başına sayfa ve site isteklerini sayar, eşiği aşan kaynağı geçici olarak engeller. Bu bir istek seli savunmasıdır. mod_qos kaynak başına ve toplam eşzamanlı bağlantıyı sınırlar, yük altında bilinen iyi trafiği önceliklendirebilir. Bu bir bağlantı yoğunluğu ve adalet savunmasıdır. mod_evasive daha hızlı kurulur, mod_qos daha yeteneklidir ve ayarı daha çok emek ister. İkisi de alttaki doğru MPM ve mod_reqtimeout'un yerini tutmaz.

RequestReadTimeout değerlerini kaça ayarlamalıyım?

Bayt geldikçe daralan, onlu saniyeler düzeyinde bir başlık süresiyle ve daha kısa bir gövde süresiyle başlayın, sonra 408 oranını okuyun. Kademeli biçim, yani veri geldikçe daralan daha uzun bir başlangıç payı, kötü bir hattaki yavaş ama gerçek istemciyi tek tek bayt gönderen Slowloris istemcisinden ayırır. Fazla sıkı ayarlarsanız kötü bağlantıdaki mobil kullanıcıları kesersiniz, fazla gevşek ayarlarsanız yavaş saldırılar hayatta kalır. Temel ölçülerinize göre 408 oranı hangi yöne gideceğinizi söyler.

Saldırı sırasında Apache'yi nasıl gözlerim?

ExtendedStatus açık mod_status ile. Skor tablosu her işçinin durumunu gösterir: okuma (R), gönderme (W), keep-alive (K), kapatma (C). Bir Slowloris saldırısı R durumunda takılı bir işçi duvarı olarak görünür, istek seli ise W durumunda doymuş işçiler olarak. server-status'u localhost'a kısıtlayın, meşgul ve boş işçi sayısını izleyin, meşgul sayıyı MaxRequestWorkers tavanına karşı izleme sistemine bağlayın. Meşgul sayı tavana yaklaştığında darboğaz havuzdur.

Teknik derinlik

Apache DDoS Sıkılaştırma: MPM Seçimi, mod_reqtimeout ve Kaynak Başına Sınır

Son güncelleme: Ağustos 2026 · MPM seçimi, mod_reqtimeout, mod_qos ve mod_evasive · Okuma süresi ~20 dk

Bir atölyede gelen her iş koca bir tezgahı ve işçisini kaplar; amber bir iş seli her tezgahı dolu ama atıl bırakır, yandaki paylaşımlı hızlı hatta ise akış sürer.

Apache'nin ilk DDoS kararı MPM seçimidir. prefork bağlantı başına bir süreç harcar ve Slowloris'e açıktır; event harcamaz ve çok daha dayanıklıdır. Doğru MPM üstünde mod_reqtimeout yavaş istek saldırılarını kapatır, mod_qos kaynak başına bağlantıyı sınırlar, mod_evasive istek selini engeller. Her biri sayaçlı bir direktiftir ve temel ölçülerinize göre boyutlanır.

Bu rehber, önünde herhangi bir cihaz olmadan, bir DDoS saldırısının bağlantı ve istek tüketen kısmına karşı Apache httpd’nin kendisini sertleştirir. nginx’in aksine Apache’nin dayanıklılığı hazır gelmez. Onu önce çoğu rehberin atladığı bir seçim belirler: Çoklu İşleme Modülü (MPM). Bunu yanlış seçerseniz alttaki modül ayarları sizi kurtaramaz. Doğru seçerseniz modüller işini yapar.

Her direktif modülü, değeri ve işlediğini gösteren sayaçla birlikte gelir. Değerler kendi trafiğinize göre başlangıç noktalarıdır.

Saldırı biçimleri ve karşılık veren Apache mekanizmaları

Cihaz	Saldırı biçimi	Apache mekanizması
Yavaş başlık / yavaş gövde (Slowloris)	mod_reqtimeout RequestReadTimeout; event MPM	erişim kaydında 408 oranı; server-status skor tablosu
Kaynak başına çok bağlantı	mod_qos QS_SrvMaxConnPerIP	server-status meşgul işçiler; mod_qos konsolu
Az kaynaktan istek seli	mod_evasive DOSPageCount / DOSSiteCount	403 oranı; mod_evasive kayıt/e-posta kancası
İşçi tükenmesi	MaxRequestWorkers, ThreadsPerChild (event MPM)	server-status: meşgul ve boş işçi sayısı
Büyük istek istismarı	LimitRequestBody, LimitRequestFields, LimitRequestLine	erişim kaydında 413 / 400 oranı

İlk satır gerisini belirler. prefork üstünde Slowloris süreçleri diğer hiçbir sınır devreye girmeden tüketir, bu yüzden MPM seçimi modül ayarından önce gelir. Saldırı Apache'nin önündeki hattı doldurduğunda ise bunların hiçbiri işe yaramaz.

0. Önce temel ölçüler: skor tablosunu açın

Apache’nin canlı durumu mod_status skor tablosudur. Onu localhost’a kısıtlı biçimde açın ve genişletilmiş durumu etkinleştirin.

ExtendedStatus On
<Location "/server-status">
    SetHandler server-status
    Require ip 127.0.0.1
</Location>

# İşçi skor tablosu: duruma göre sayılar
curl -s http://127.0.0.1/server-status?auto | grep -E 'BusyWorkers|IdleWorkers|Total Accesses'

# Erişim kaydından istemci başına istek sayısı, normal bir hafta
awk '{print $1}' /var/log/apache2/access.log | sort | uniq -c | sort -rn | head

MaxRequestWorkers tavanına karşı BusyWorkers ve kayıttan gelen istemci başına oran, aşağıdaki her eşiğin ölçüldüğü temel ölçülerdir.

1. MPM: her şeyden önce gelen karar

Dayanıklı bir Apache ile açık bir Apache’yi ayıran bölüm burasıdır. Hangi MPM’in etkin olduğuna bakın.

apachectl -V | grep -i 'Server MPM'
# ya da
apache2ctl -M | grep mpm

prefork yazıyorsa, iş parçacığına güvenli olmayan bir modül zorlamadıkça değiştirilecek ilk şey budur. prefork bağlantı başına bir süreç çalıştırır, dolayısıyla bir Slowloris saldırısı birkaç bin yavaş bağlantıyla süreç havuzunu tüketir. event iş parçacığı ve keep-alive ile sönümlenen bağlantıları devralan ayrı bir dinleyici kullanır, böylece yavaş bir bağlantı bir süreç değil bir iş parçacığı yuvası harcar.

Bir sunucunun prefork’ta takılı kalmasının olağan sebebi mod_php’dir. PHP’yi PHP-FPM’e taşımak event çalıştırmanızın önünü açar ve buradaki en büyük dayanıklılık kazancıdır.

# mpm_event ayarı — toplam kapasite = ServerLimit * ThreadsPerChild
<IfModule mpm_event_module>
    StartServers            4
    ServerLimit             16
    ThreadsPerChild         64
    MaxRequestWorkers       1024      # ServerLimit * ThreadsPerChild
    MaxConnectionsPerChild  10000     # bellek artışını sınırlamak için geri dönüştür
</IfModule>

# Çalışan MPM'i ve tavanı doğrula
apachectl -V | grep -i mpm
curl -s http://127.0.0.1/server-status?auto | grep -E 'BusyWorkers|IdleWorkers'

MaxRequestWorkers eşzamanlı istek sayısının sert tavanıdır. Onu belleğinizin kaldırdığı değere kurun, daha yükseğe değil, çünkü yük altında belleği aşmak kendi başına bir kesintidir.

2. mod_reqtimeout: doğrudan Slowloris cevabı

mod_reqtimeout bir istemcinin isteğini göndermesine tanınan süreyi sınırlar. Kademeli biçim, bayt geldikçe daralan cömert bir başlangıç penceresi verir ve yavaş ama gerçek bir istemciyi tek tek bayt gönderen bir saldırgandan ayırır.

<IfModule mod_reqtimeout_module>
    # başlık: 20s başlangıç, saniyede en az 500 baytta 40s'ye uzayan
    # gövde:  20s, saniyede en az 500 baytta uzayan
    RequestReadTimeout header=20-40,MinRate=500 body=20,MinRate=500
</IfModule>

# Düşürülen yavaş istekler erişim kaydında 408 olarak görünür
awk '$9==408' /var/log/apache2/access.log | wc -l

Bir olay sırasında yükselen 408 oranı, sürenin işini yaptığının işaretidir. Normal trafikte meşru mobil istemciler 408’lerde görünmeye başlıyorsa başlık penceresi fazla dardır. En üst değeri ve MinRate’i birlikte genişletin.

3. mod_qos: kaynak başına ve toplam bağlantı

mod_qos bağlantı yoğunluğu ve adalet katmanıdır. nginx’in limit_conn direktifinin en yakın Apache karşılığıdır.

<IfModule mod_qos_module>
    QS_SrvMaxConn            2048     # toplam eşzamanlı bağlantı
    QS_SrvMaxConnPerIP       50       # kaynak adres başına
    QS_SrvMaxConnClose       70%      # bu yükün üstünde keep-alive'ı kapat, yuvaları boşalt
    QS_SrvMinDataRate        150 1200 # asgari bayt/s, yük altında yükselen — ikinci Slowloris kesimi
</IfModule>

QS_SrvMaxConnClose ince ve yararlıdır. Havuzun verilen kesrinin üstünde Apache keep-alive’a saygı göstermeyi bırakır, böylece bağlantılar daha hızlı boşalır. QS_SrvMinDataRate sunucu doldukça yükselen bir asgari çıktı dayatır ve en yavaş bağlantıları tam da yuvaların kıt olduğu anda atar.

# mod_qos kendi sayaçlarını gösterir
curl -s 'http://127.0.0.1/server-status?auto' | grep -i qos

4. mod_evasive: istek seli engeli

mod_evasive kısa bir pencerede kaynak başına istekleri sayar ve eşiği aşan kaynağı geçici olarak engeller.

<IfModule mod_evasive20_module>
    DOSHashTableSize    3097
    DOSPageCount        5        # aynı sayfa, kaynak başına, aralık başına
    DOSSiteCount        50       # sitedeki herhangi bir sayfa, kaynak başına, aralık başına
    DOSPageInterval     1        # saniye
    DOSSiteInterval     1
    DOSBlockingPeriod   30       # engelleme süresi, saniye
    DOSLogDir           /var/log/apache2/evasive
</IfModule>

# Engellenen kaynaklar kayda yazılır ve 403 döner
awk '$9==403' /var/log/apache2/access.log | wc -l
ls /var/log/apache2/evasive/    # o an engelli her kaynak için bir kilit dosyası

DOSBlockingPeriod’u başta kısa tutun. Uzun bir engel artı bir yanlış pozitif, gerçek bir kullanıcıyı tüm süre boyunca dışarıda bırakır. Buradaki her sınır gibi, güvenmeden önce neyi yakaladığını izleyin.

5. İstek boyutu ve alan sınırları

Bağlantı sayısından bağımsız olarak belleği tüketebilen büyük istek yüzeyini kapatın.

LimitRequestBody      10485760    # 10 MB
LimitRequestFields    100         # en fazla başlık sayısı
LimitRequestFieldSize 8190        # en fazla başlık boyutu
LimitRequestLine      8190        # en fazla istek satırı uzunluğu
Timeout               60          # genel G/Ç süresi, varsayılan 300'den düşük
KeepAliveTimeout      5           # kısa keep-alive boşta kalma
MaxKeepAliveRequests  100

# Büyük istekler: 413 (gövde) ve 400 (başlık/satır)
awk '$9==413 || $9==400' /var/log/apache2/access.log | wc -l

Genel Timeout varsayılanı olan 300 saniye, halka açık bir sunucu için fazla cömerttir. Onu düşürmek tek başına sessiz ama gerçek bir Slowloris hafifletmesidir.

6. Vekil arkasında istemci IP’sini doğru almak

Her kaynak başına sınır, yani mod_qos ve mod_evasive, istemci adresine göre anahtarlanır. Bir vekil arkasında bu, mod_remoteip ile düzeltilmedikçe vekilin adresidir.

<IfModule mod_remoteip_module>
    RemoteIPHeader X-Forwarded-For
    RemoteIPTrustedProxy 10.0.0.0/8 172.16.0.0/12
</IfModule>
# Vekili değil gerçek istemciyi kaydet
LogFormat "%a %l %u %t \"%r\" %>s %b" combined_realip

# Bu 1 dönerse her istek vekile atfediliyor ve kaynak başına sınırlar anlamsızdır
awk '{print $1}' /var/log/apache2/access.log | sort -u | wc -l

İzlemeye bağlanacak sinyaller

# 1. Meşgul işçiler / tavan — havuz doygunluğu
curl -s http://127.0.0.1/server-status?auto | awk -F': ' '/BusyWorkers/{print $2}'
# 2. 408 oranı — yavaş istek sürelerinin devreye girmesi
awk '$9==408' /var/log/apache2/access.log | wc -l
# 3. 403 oranı — mod_evasive engelleri
awk '$9==403' /var/log/apache2/access.log | wc -l
# 4. Skor tablosunda R duvarı — Slowloris imzası
curl -s http://127.0.0.1/server-status | grep -o 'R' | wc -l

R (okuma) durumunda takılı bir işçi duvarı, yanılmaz Slowloris imzasıdır. W (yazma) durumunda doymuş işçiler ise istek selidir. İkisi skor tablosunda farklı görünür ve farklı sınırlar gerektirir.

Apache sıkılaştırmasının dürüst sınırı

Buradaki her şey uygulama kenarındaki bağlantı durumu ve istek hızı tükenmesine karşıdır. İki durum bunun dışında kalır.

Birincisi hat doluluğudur. Hattı dolduran hacim Apache’ye hiç ulaşmaz ve hiçbir MPM ya da modül bunu değiştirmez.

Hat kapasitesinin altında Apache'nin sınırlarının payı vardır; üstünde hiçbir direktifin anlamı kalmaz.

İkincisi Apache’nin altındaki çekirdek katmanıdır: SYN kuyrukları, conntrack, dosya tanıtıcıları. Bir istek httpd onu görmeden önce bu katmandan geçer ve Linux sıkılaştırma rehberi bunu ele alır. Apache sıkılaştırması o katmanın yerinde olduğunu varsayar. Hattın üstünde cevap şebeke katmanıdır. Apache o zamana kadar uygulama kenarını ayakta tutar.

Uygulama sırası

mod_status’u açın; bir haftalık temel ölçüleri kaydedin.
MPM’e bakın. prefork ise PHP’yi PHP-FPM’e taşıyıp event’e geçin, her şeyden önce.
event MPM kapasitesini belleğin kaldırdığı değere kurun.
mod_reqtimeout ekleyin; 408 oranını izleyin.
Bir vekil varsa, kaynak başına sınırlardan önce mod_remoteip’i düzeltin.
mod_qos ve mod_evasive ekleyin; güvenene kadar engelleme sürelerini kısa tutun.
Dört sinyali izlemeye bağlayın.

İkinci adım isteğe bağlı değildir ve yeri değişmez. prefork üstünde, altındaki her sınır, Slowloris’in zaten tüketebildiği bir sunucuya uygulanır.

Sık sorulan sorular

DDoS dayanıklılığı için hangi MPM'i çalıştırmalıyım?: Neredeyse her durumda event. prefork bağlantı başına bir süreç çalıştırır, dolayısıyla birkaç bin yavaş bağlantı süreç havuzunu tüketir. Klasik Slowloris sonucu budur. prefork daha çok eski mod_php gibi iş parçacığına güvenli olmayan modüller için vardır. event ve worker ise iş parçacığı ve keep-alive bağlantılarını devralan ayrı bir dinleyici kullanır, böylece yavaş bir bağlantı koca bir süreç değil tek bir yuva harcar. prefork'ta yalnızca mod_php yüzünden kaldıysanız, PHP'yi PHP-FPM'e taşımak event'e geçmenizi sağlar ve buradaki en büyük kazançtır.
mod_reqtimeout Slowloris'e karşı tek başına yeter mi?: event üstünde neredeyse yeter, prefork'ta yardımcı olur ama MPM sizi yine sınırlar. RequestReadTimeout bir istemcinin istek satırını ve başlıklarını göndermesine tanınan süreyi sınırlar, böylece başlığı damla damla gönderen bir bağlantı açık tutulmak yerine sürede düşer. Doğrudan Slowloris cevabı budur. Ancak prefork'ta tutulan her bağlantı süre dolana kadar koca bir süreçtir, o yüzden süre kısa olmalı ve süreç havuzu yine tavandır. event üstünde aynı süre çok daha etkilidir, çünkü askıda kalan bağlantının maliyeti baştan düşüktür.
mod_evasive mi mod_qos mu gerekir?: İkisi farklı biçimleri çözer ve çoğu site ikisini birlikte çalıştırır. mod_evasive kısa bir pencerede kaynak başına sayfa ve site isteklerini sayar, eşiği aşan kaynağı geçici olarak engeller. Bu bir istek seli savunmasıdır. mod_qos kaynak başına ve toplam eşzamanlı bağlantıyı sınırlar, yük altında bilinen iyi trafiği önceliklendirebilir. Bu bir bağlantı yoğunluğu ve adalet savunmasıdır. mod_evasive daha hızlı kurulur, mod_qos daha yeteneklidir ve ayarı daha çok emek ister. İkisi de alttaki doğru MPM ve mod_reqtimeout'un yerini tutmaz.
RequestReadTimeout değerlerini kaça ayarlamalıyım?: Bayt geldikçe daralan, onlu saniyeler düzeyinde bir başlık süresiyle ve daha kısa bir gövde süresiyle başlayın, sonra 408 oranını okuyun. Kademeli biçim, yani veri geldikçe daralan daha uzun bir başlangıç payı, kötü bir hattaki yavaş ama gerçek istemciyi tek tek bayt gönderen Slowloris istemcisinden ayırır. Fazla sıkı ayarlarsanız kötü bağlantıdaki mobil kullanıcıları kesersiniz, fazla gevşek ayarlarsanız yavaş saldırılar hayatta kalır. Temel ölçülerinize göre 408 oranı hangi yöne gideceğinizi söyler.
Saldırı sırasında Apache'yi nasıl gözlerim?: ExtendedStatus açık mod_status ile. Skor tablosu her işçinin durumunu gösterir: okuma (R), gönderme (W), keep-alive (K), kapatma (C). Bir Slowloris saldırısı R durumunda takılı bir işçi duvarı olarak görünür, istek seli ise W durumunda doymuş işçiler olarak. server-status'u localhost'a kısıtlayın, meşgul ve boş işçi sayısını izleyin, meşgul sayıyı MaxRequestWorkers tavanına karşı izleme sistemine bağlayın. Meşgul sayı tavana yaklaştığında darboğaz havuzdur.
Bu ayarlar hacimsel bir saldırıyı durdurur mu?: Hayır. Saldırı sunucunun önündeki hattı doldurursa Apache istekleri hiç almaz ve hiçbir MPM ya da modül ayarı geçerli olmaz. Buradaki her şey uygulama kenarındaki bağlantı durumu ve istek hızı tükenmesine karşıdır. Hat kapasitesinin üzerindeki hacim şebeke katmanının sorunudur ve httpd.conf içinde çözülmez.

Yayım: Ağustos 2026

Bu rehber, üreticiler yeni modeller ve fiyatlandırma açıkladıkça güncellenir. Üreticileri nasıl karşılaştırıyoruz