JBoss AS'nin eski connector'ı WildFly'nin Undertow'u ile aynı mı?

Hayır, ve bu ayrım hangi ayarların geçerli olduğunu belirler. Eski JBoss AS (5/6) Tomcat türevi bir connector taşıyan JBossWeb'i kullanıyordu; JBoss EAP 7+ ve WildFly bunu XNIO üzerine kurulu non-blocking bir web sunucusu olan Undertow ile değiştirdi. Modern bir EAP ya da WildFly üzerindeyseniz her şey Tomcat tarzı bir connector'da değil, management CLI ile Undertow alt sisteminde yapılandırılır. Hâlâ JBossWeb üzerindeyseniz Tomcat sıkılaştırma rehberi gerçeğinize daha yakındır ve daha değerli hamle, ömrünü tamamlamış bir sunucudan çıkmaktır.

DDoS açısından Undertow'un iş parçacığı modeli Tomcat'ten nasıl farklıdır?

Undertow, IO iş parçacıklarını worker iş parçacıklarından ayırır. Küçük bir IO iş parçacığı havuzu non-blocking olay döngüsünü çalıştırır ve hiç bloklanmaz; worker havuzu ise servlet çağrısı gibi bloklanan istekleri işler. Yavaş bağlantı bir worker'ı meşgul etmek yerine IO iş parçacıklarınca bir buffer olarak taşınır ve Undertow yavaş bağlantı saldırılarına bu sayede tasarım gereği direnir. Pratik ayar, io-threads değerini çekirdek sayısına, task-max-threads değerini ise uygulamanın ve heap'in kaldırdığına göre boyutlamaktır. İkisini karıştırmayın: IO iş parçacığını şişirmek bloklanan işteki bir darboğaza çare olmaz, tersi de öyle.

Undertow'da yavaş istek saldırısını hangi zaman aşımı durdurur?

İki tanesi birlikte çalışır. request-parse-timeout, Undertow'un istek başlıklarını ayrıştırmak için harcayacağı süreyi sınırlar; no-request-timeout ise boşta duran bir bağlantının istek göndermeden ne kadar açık kalacağını sınırlar. Başlıkları damla damla gönderen bir Slowloris istemcisini request-parse-timeout yakalar; bağlantıyı açıp hiçbir şey göndermeyeni no-request-timeout yakalar. İkisi de öntanımlı olarak ayarlı gelmez, bu yüzden açığa çıkmış bir dinleyicide her ikisi de açıkça, on saniyeler mertebesinde yapılandırılmalıdır.

Bunları standalone.xml'de mi yoksa CLI ile mi ayarlamalıyım?

CLI ile, ve yapılandırmayı ona yazdırın. standalone.xml'i elle düzenlemek işe yarar ama hataya açıktır ve sunucu bir domain controller ya da OpenShift gibi bir operatör tarafından yönetiliyorsa kaybolur. Bu rehberdeki jboss-cli.sh komutları fikri sabittir, öznitelik adlarını doğrular ve çalışan bir sunucuya yeniden başlatma yerine reload ile uygulanır. XML'i elle düzenlemek, desteklenen bir cmdlet varken bir Windows ayarını registry'den yazmanın JBoss karşılığıdır.

Undertow sertleştirildiyse JBoss'un yine de bir ön katmana ihtiyacı var mı?

Evet, Tomcat'le aynı gerekçelerle. Undertow yeteneklidir ve internete bloklayan bir connector'dan daha güvenli bakabilir, ama standart üretim tasarımı yine de TLS'i sonlandırmayı, oran sınırlamayı ve yavaş bağlantıları düşürmeyi ayrı bir ön katmana bırakır ve temiz istekleri Undertow'a özel bir ağ üzerinden iletir. Buradaki Undertow limitleri o ön katmanın arkasındaki ikinci hattır. Değerli olmalarının nedeni, bir ön katmanın iç ağda atlanabilmesi ya da yakalayamadığı bir saldırıyı iletebilmesidir. Ama ön katmanın yerini tutmazlar.

Bu ayarlar hacimsel bir saldırıyı durdurur mu?

Hayır. Saldırı sunucuların önündeki hattı doldurursa istekler ne ön katmana ne Undertow'a ulaşır ve hiçbir öznitelik geçerli olmaz. Buradaki her şey uygulama katmanındaki bağlantı ve iş parçacığı tükenmesine karşıdır. Hat kapasitesinin üzerindeki hacim şebeke tarafının sorunudur ve Undertow alt sisteminde çözülmez.

Teknik derinlik

JBoss / WildFly DDoS Sıkılaştırma: Undertow Dinleyici Limitleri ve IO İş Parçacıkları

Son güncelleme: Ağustos 2026 · Undertow dinleyici limitleri, IO thread'leri ve ön katman · Okuma süresi ~16 dk

Dış duvarın arkasında, kendi sınırlı kapısı olan bir iç kale: dış duvar delinse bile iç kale kendi kabullerini ölçüyor ve küçük, sakin bir çekirdeği ayakta tutuyor.

JBoss EAP ve WildFly'da DDoS yüzeyi Tomcat connector'ı değil Undertow'dur. Taşıyıcı öznitelikler max-connections, istek zaman aşımları ve IO/worker iş parçacığı ayrımıdır, hepsi management CLI ile ayarlanır. Undertow non-blocking çalışır, yani yavaş bağlantı bir worker'a değil bir buffer'a mal olur. Yine de uygulama sunucusu açık internete değil, sertleştirilmiş bir ön katmanın arkasına konur.

Bu rehber JBoss EAP ve WildFly’nin kendisini, bir DDoS saldırısının bağlantı ve iş parçacığı tüketen kısmına karşı sertleştirir. Önce önemli bir ayrım: modern bir EAP ya da WildFly’da web sunucusu eski JBossWeb connector’ı değil Undertow’dur ve her şey Undertow alt sisteminde, management CLI ile yapılandırılır. Hâlâ JBossWeb taşıyan JBoss AS 5/6 üzerindeyseniz Tomcat rehberi yapılandırmanıza daha yakındır. Daha büyük mesele ise şudur: ömrünü tamamlamış bir sunucu, başlı başına bir açıklıktır.

Tomcat’te olduğu gibi JBoss da bir uygulama sunucusudur ve sertleştirilmiş bir ön katmanın arkasına konur. Aşağıdaki Undertow limitleri o katmanın arkasındaki ikinci hattır. Her öznitelik, jboss-cli.sh komutu ve çalıştığını gösteren sayacıyla birlikte verilir.

Saldırı biçimleri ve karşılık gelen Undertow öznitelikleri

Cihaz	Saldırı biçimi	Undertow özniteliği
Yavaş başlık / yavaş gövde	no-request-timeout, request-parse-timeout	/subsystem=undertow/server=/http-listener=
Bağlantı seli	max-connections; tcp-backlog	http-listener + socket-binding
Thread / IO tükenmesi	io-threads, task-max-threads (worker)	/subsystem=io/worker=default
Büyük istek istismarı	max-header-size, max-parameters, max-post-size	/subsystem=undertow/server=/http-listener=
Doğrudan maruz kalma	Dinleyiciyi içeriden bağla; ön katman sonlandırsın	socket-binding arayüzü

Tomcat gibi JBoss da bir uygulama sunucusudur. Standart tasarım önüne sertleştirilmiş bir katman koyar ve buradaki Undertow limitleri o katmanın arkasındaki ikinci hattır. Saldırı hattı doldurduğunda hiçbiri işe yaramaz.

0. Önce temel ölçüler: dinleyici ve worker metriklerini okuyun

Undertow ve IO alt sistemi çalışma anı metriklerini CLI üzerinden sunar. İstatistikleri açın ve normal bir hafta boyunca okuyun:

# Undertow istatistiklerini aç
/subsystem=undertow:write-attribute(name=statistics-enabled,value=true)

# HTTP dinleyicideki aktif bağlantılar ve işlenen istekler
/subsystem=undertow/server=default-server/http-listener=default:read-resource(include-runtime=true)

# Worker havuzu: meşgul iş parçacığı sayısı, çekirdek/azami değere karşı
/subsystem=io/worker=default:read-resource(include-runtime=true)

Dinleyicinin aktif bağlantı sayısı ve worker’ın meşgul iş parçacığı sayısı, aşağıdaki her değerin karşısında ayarlandığı temel ölçülerdir.

1. Önce ön katman gelir

Undertow’un açık bir arayüzde doğrudan maruz kalmadığını doğrulayın:

# http socket-binding, açık bir arayüzde değil dahili bir arayüzde olmalı
/socket-binding-group=standard-sockets/socket-binding=http:read-resource(include-runtime=true)
ss -ltnp | grep 8080

Açıksa dahili olarak bağlayın ve internet bağlantısını sertleştirilmiş bir ön katman sonlandırsın. O katmanı nginx ve Apache rehberleri ele alır. Ön katman; TLS’i, oran sınırlamayı ve yavaş bağlantıların düşürülmesini bir uygulama sunucusundan daha iyi taşır.

2. Dinleyici bağlantı ve zaman aşımı limitleri

http-listener, bağlantı tavanını ve yavaş istek saldırılarına yanıt veren iki zaman aşımını taşır. Bunları CLI ile ayarlayın:

# Dinleyicideki eşzamanlı bağlantıyı sınırla
/subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=max-connections,value=8192)

# Slowloris: istek başlıklarını ayrıştırmak için verilen süre
/subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=request-parse-timeout,value=30000)

# İstek göndermeden boşta duran bağlantı
/subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=no-request-timeout,value=30000)

# Yeniden başlatma değil, reload ile uygula
reload

İki zaman aşımı da öntanımlı olarak ayarlı gelmez, bu yüzden açığa çıkmış her dinleyicide ikisi de açıkça yapılandırılmalıdır. request-parse-timeout başlıkları damlatan istemciyi yakalar; no-request-timeout bağlantıyı açıp hiçbir şey göndermeyeni yakalar.

3. IO / worker iş parçacığı ayrımı

Undertow, non-blocking IO iş parçacıklarını bloklanan worker havuzundan ayırır. İkisini bağımsız boyutlayın ve karıştırmayın:

# IO iş parçacıkları olay döngüsünü çalıştırır; çekirdek sayısına göre boyutlayın (yaygın kural: çekirdek ya da çekirdek*2)
/subsystem=io/worker=default:write-attribute(name=io-threads,value=8)

# Worker havuzu bloklanan işi (servlet) işler; heap/uygulamanın kaldırdığına göre boyutlayın
/subsystem=io/worker=default:write-attribute(name=task-max-threads,value=128)

reload

io-threads değerini şişirmek bloklanan işteki bir darboğaza çare olmaz; task-max-threads değerini heap’in kaldırdığının üstüne çıkarmak ise bir tükenmeyi bellek tükenmesiyle takas eder. Yavaş bağlantı IO iş parçacıklarınca bir buffer olarak taşınır ve Undertow Slowloris’e bu yüzden tasarım gereği direnir. Yukarıdaki zaman aşımları, o neredeyse-bağışıklığı fiili düşürmeye çevirir.

4. İstek boyutu limitleri

Dinleyicideki büyük istek yüzeyini kapatın:

/subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=max-header-size,value=8192)
/subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=max-parameters,value=1000)
/subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=max-headers,value=100)
/subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=max-cookies,value=50)
/subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=max-post-size,value=10485760)
reload

max-parameters ve max-headers bellek dışında da önemlidir: sınırsız bir sayı, ayrıştırmada işlemci yakmanın ve tarihsel olarak hash çarpışması saldırısı tetiklemenin ucuz bir yoludur. Öntanımlı değerler geniştir; açığa çıkmış bir dinleyicide bunları sıkılaştırmanın meşru bir maliyeti yoktur.

5. TCP backlog

socket-binding backlog değeri, kabul edilmeyi bekleyen bağlantıların işletim sistemi düzeyindeki kuyruğudur ve Tomcat’in acceptCount değerinin Undertow karşılığıdır:

/socket-binding-group=standard-sockets/socket-binding=http:write-attribute(name=backlog,value=200)
reload

Backlog’u kısa tutun, büyük değil. Büyük bir backlog yalnızca worker havuzunu koruyan reddi geciktirir.

6. Ön katmanın arkasında istemci IP’si

Bir ön katman varken, proxy-address-forwarding etkinleştirilmezse her log kaydı ve her adres kuralı istemciyi değil ön katmanı kaydeder:

# Dinleyicide forwarded-for işlemesini aç
/subsystem=undertow/server=default-server/http-listener=default:write-attribute(name=proxy-address-forwarding,value=true)
reload

Bu olmadan her istek ön katmana atfedilir. Bu, seri boyunca tekrarlayan proxy-IP hatasıdır.

İzlemeye bağlanacak sayaçlar

# 1. Dinleyicideki aktif bağlantılar (read-resource include-runtime), max-connections'a karşı
# 2. Worker meşgul iş parçacıkları, task-max-threads'e karşı (/subsystem=io/worker=default)
# 3. request-parse-timeout ve no-request-timeout sayıları (dinleyici çalışma anı istatistikleri)
# 4. Dinleyici istatistiklerinden hata/işleme sayıları
/subsystem=undertow/server=default-server/http-listener=default:read-resource(include-runtime=true,recursive=true)

Aktif bağlantıların max-connections değerine dayanması ve worker havuzunun meşgul olması, istek hızının Undertow’un soğurabileceğini aştığının işaretidir. O nokta, fazlayı ön katmanın ya da bir üst katmanın alması gereken noktadır.

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

Buradaki her şey, çoğunu ilkin yakalaması gereken bir ön katmanın arkasında, uygulama katmanını savunur. İki durum bunun dışında kalır.

Birincisi hat doluluğudur: hattı dolduran hacim ne ön katmana ne Undertow’a ulaşır.

Hat kapasitesinin altında Undertow limitlerinin payı vardır; üstünde hiçbir özniteliğin anlamı kalmaz.

İkincisi sunucuların altındaki işletim sistemi katmanıdır ve Linux ile Windows rehberlerinde ele alınır. JBoss sıkılaştırması hem ön katmanın hem işletim sistemi katmanının yerinde olduğunu varsayar. Hattın üstünde cevap şebeke katmanındadır.

Uygulama sırası

Dinleyicinin dahili bağlandığını doğrulayın; önüne sertleştirilmiş bir katman koyun.
Undertow istatistiklerini açın; temel ölçüleri kaydedin.
max-connections ve iki istek zaman aşımını CLI ile ayarlayın.
io-threads’i çekirdeğe, task-max-threads’i heap’e göre boyutlayın.
proxy-address-forwarding’i açın, log’lar ve kurallar gerçek istemciyi görsün.
İstek boyutu limitlerini ve kısa bir backlog ayarlayın.
Çalışma anı metriklerini izlemeye bağlayın.

Sonucu en çok değiştiren adım yine birincisidir. Undertow limitleri ikinci hattır ve ikinci hat, ancak arkasında durduğu ilk hat kadar işe yarar.

Sık sorulan sorular

JBoss AS'nin eski connector'ı WildFly'nin Undertow'u ile aynı mı?: Hayır, ve bu ayrım hangi ayarların geçerli olduğunu belirler. Eski JBoss AS (5/6) Tomcat türevi bir connector taşıyan JBossWeb'i kullanıyordu; JBoss EAP 7+ ve WildFly bunu XNIO üzerine kurulu non-blocking bir web sunucusu olan Undertow ile değiştirdi. Modern bir EAP ya da WildFly üzerindeyseniz her şey Tomcat tarzı bir connector'da değil, management CLI ile Undertow alt sisteminde yapılandırılır. Hâlâ JBossWeb üzerindeyseniz Tomcat sıkılaştırma rehberi gerçeğinize daha yakındır ve daha değerli hamle, ömrünü tamamlamış bir sunucudan çıkmaktır.
DDoS açısından Undertow'un iş parçacığı modeli Tomcat'ten nasıl farklıdır?: Undertow, IO iş parçacıklarını worker iş parçacıklarından ayırır. Küçük bir IO iş parçacığı havuzu non-blocking olay döngüsünü çalıştırır ve hiç bloklanmaz; worker havuzu ise servlet çağrısı gibi bloklanan istekleri işler. Yavaş bağlantı bir worker'ı meşgul etmek yerine IO iş parçacıklarınca bir buffer olarak taşınır ve Undertow yavaş bağlantı saldırılarına bu sayede tasarım gereği direnir. Pratik ayar, io-threads değerini çekirdek sayısına, task-max-threads değerini ise uygulamanın ve heap'in kaldırdığına göre boyutlamaktır. İkisini karıştırmayın: IO iş parçacığını şişirmek bloklanan işteki bir darboğaza çare olmaz, tersi de öyle.
Undertow'da yavaş istek saldırısını hangi zaman aşımı durdurur?: İki tanesi birlikte çalışır. request-parse-timeout, Undertow'un istek başlıklarını ayrıştırmak için harcayacağı süreyi sınırlar; no-request-timeout ise boşta duran bir bağlantının istek göndermeden ne kadar açık kalacağını sınırlar. Başlıkları damla damla gönderen bir Slowloris istemcisini request-parse-timeout yakalar; bağlantıyı açıp hiçbir şey göndermeyeni no-request-timeout yakalar. İkisi de öntanımlı olarak ayarlı gelmez, bu yüzden açığa çıkmış bir dinleyicide her ikisi de açıkça, on saniyeler mertebesinde yapılandırılmalıdır.
Bunları standalone.xml'de mi yoksa CLI ile mi ayarlamalıyım?: CLI ile, ve yapılandırmayı ona yazdırın. standalone.xml'i elle düzenlemek işe yarar ama hataya açıktır ve sunucu bir domain controller ya da OpenShift gibi bir operatör tarafından yönetiliyorsa kaybolur. Bu rehberdeki jboss-cli.sh komutları fikri sabittir, öznitelik adlarını doğrular ve çalışan bir sunucuya yeniden başlatma yerine reload ile uygulanır. XML'i elle düzenlemek, desteklenen bir cmdlet varken bir Windows ayarını registry'den yazmanın JBoss karşılığıdır.
Undertow sertleştirildiyse JBoss'un yine de bir ön katmana ihtiyacı var mı?: Evet, Tomcat'le aynı gerekçelerle. Undertow yeteneklidir ve internete bloklayan bir connector'dan daha güvenli bakabilir, ama standart üretim tasarımı yine de TLS'i sonlandırmayı, oran sınırlamayı ve yavaş bağlantıları düşürmeyi ayrı bir ön katmana bırakır ve temiz istekleri Undertow'a özel bir ağ üzerinden iletir. Buradaki Undertow limitleri o ön katmanın arkasındaki ikinci hattır. Değerli olmalarının nedeni, bir ön katmanın iç ağda atlanabilmesi ya da yakalayamadığı bir saldırıyı iletebilmesidir. Ama ön katmanın yerini tutmazlar.
Bu ayarlar hacimsel bir saldırıyı durdurur mu?: Hayır. Saldırı sunucuların önündeki hattı doldurursa istekler ne ön katmana ne Undertow'a ulaşır ve hiçbir öznitelik geçerli olmaz. Buradaki her şey uygulama katmanındaki bağlantı ve iş parçacığı tükenmesine karşıdır. Hat kapasitesinin üzerindeki hacim şebeke tarafının sorunudur ve Undertow alt sisteminde çö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