WebLogic DDoS Sıkılaştırma: Work Manager, Mesaj Zaman Aşımları ve Overload Protection

Bu rehber Oracle WebLogic Server’ın kendisini bir DDoS saldırısının iş ve bağlantı tüketen kısmına karşı sertleştirir. WebLogic yaklaşımı diğer uygulama sunucularından önemli bir noktada değiştirir: sınırlanacak sabit bir iş parçacığı havuzu yoktur. WebLogic tek bir havuzu kendi ayarlar, bu yüzden savunma bir maxThreads sayısı değildir; bir dizi Work Manager kısıtı, mesaj zaman aşımı ve sunucu bir kaynağı tükettiğinde ne yapacağına karar veren Overload Protection eylemidir.

Tomcat ve JBoss’ta olduğu gibi WebLogic bir uygulama sunucusudur ve sertleştirilmiş bir ön katmanın (Oracle HTTP Server ya da başka bir proxy) arkasında durur. Aşağıdaki kontroller ikinci hattır. Her ayar, MBean’i, WLST komutu ve çalıştığını gösteren sayacıyla verilir.

Cihaz	Saldırı biçimi	WebLogic kontrolü	Nerede durur
Yavaş başlık / yavaş gövde	Complete Message Timeout; Idle Connection Timeout	WebServer / Server MBean
Bağlantı seli	Accept Backlog; Maximum Open Sockets	Server MBean
İş doygunluğu	Work Manager max-threads-constraint, capacity	self-tuning work managers
Büyük istek istismarı	Max Post Size, Max Message Size, Post Timeout	WebServer MBean
Sunucu aşırı yükü	Overload Protection: shared capacity, panic action	Overload MBean

WebLogic havuzunu kendi ayarlar, bu yüzden savunma bir maxThreads sınırı değil, kısıtlar ve aşırı yük eylemleridir. Tomcat ve JBoss'ta olduğu gibi önce sertleştirilmiş bir ön katman gelir; bunlar ikinci hattır. Saldırı hattı doldurduğunda hiçbiri işe yaramaz.

0. Önce temel ölçüler: iş parçacığı ve bağlantı sayaçları

WebLogic çalışma durumunu MBean’ler üzerinden açar; bunlar WLST içinde okunur. Normal bir haftanın havuz, kuyruk ve bağlantı rakamlarını kaydedin:

# WLST — bağlan ve kendi kendini ayarlayan havuzu, sunucu kanalını oku
connect('weblogic', 'password', 't3://localhost:7001')
serverRuntime()

# Kendi kendini ayarlayan havuz: çalışan, boşta, kuyruk uzunluğu, throughput
cd('/ThreadPoolRuntime/ThreadPoolRuntime')
ls()   # ExecuteThreadTotalCount, HoggingThreadCount, PendingUserRequestCount, Throughput

# Varsayılan kanaldaki açık soketler
cd('/ServerChannelRuntimes')

PendingUserRequestCount ve HoggingThreadCount, normal bir hafta temel değerine karşı, açık soket sayısıyla birlikte, aşağıdaki her değerin ölçüldüğü temel ölçülerdir.

1. Önce ön katman

WebLogic’in dinleme adresinin iç olduğunu, önünde Oracle HTTP Server ya da bir proxy bulunduğunu doğrulayın:

# Dinleme adresi genel değil, iç bir arayüz olmalı
ss -ltnp | grep 7001

Genel bir arayüzdeyse iç adrese bağlayın ve internet bağlantısını ön katmanda sonlandırın. nginx ve Apache rehberleri bu katmanı ele alır. Oracle HTTP Server bir Apache türevidir, dolayısıyla Apache rehberi yakından uygulanır.

2. Mesaj ve bağlantı zaman aşımları

Complete Message Timeout birincil Slowloris savunmasıdır. Onu ve bağlantı sınırlarını WLST ile ayarlayın:

edit()
startEdit()

# Slowloris: tam bir istek mesajını almak için azami süre (saniye)
cd('/Servers/myserver')
cmo.setCompleteMessageTimeout(60)

# Boşta bağlantı zaman aşımı (saniye) — açılıp boşta kalan bağlantıyı kapatır
cmo.setIdleConnectionTimeout(30)

# Bağlantı backlog'u ve açık soket tavanı
cmo.setAcceptBacklog(300)
cmo.setMaxOpenSockCount(8192)

save()
activate()

Complete Message Timeout, Web Server düzeyinde ezilebilen bir sunucu varsayılanıdır. Eski bir domain’de çoğu zaman gevşek bir değerdedir. Onu birkaç on saniyeye çekmek buradaki en etkili yavaş istek önlemidir.

3. Work Manager kısıtları: havuzu değil işi sınırlamak

Havuz kendi kendini ayarladığı için iş sınıflarını kısıtlarsınız. Bir istek selinin WebLogic 503 döndürmeden önce ne kadar kuyruğa girebileceğini sınırlayan şey capacity kısıtıdır:

edit()
startEdit()

# max-threads kısıtı bir iş sınıfı için iş parçacığını sınırlar
cd('/SelfTuning/mydomain')
cmo.createMaxThreadsConstraint('MaxThreadsForApp')
cd('/SelfTuning/mydomain/MaxThreadsConstraints/MaxThreadsForApp')
cmo.setCount(128)

# capacity kısıtı reddetmeden (503) önce kuyruk + çalışan toplamını sınırlar
cd('/SelfTuning/mydomain')
cmo.createCapacity('AppCapacity')
cd('/SelfTuning/mydomain/Capacities/AppCapacity')
cmo.setCount(4096)

save()
activate()

DDoS ile ilgili olan capacity kısıtıdır. Bir sel altındaki sınırsız kuyruğu temiz bir reddetmeye çevirir ve zaten çalışan işi korur.

4. Overload Protection: öngörülebilir başarısızlık

Overload Protection, WebLogic bir kaynağı tükettiğinde ne yapacağına karar verir; böylece sunucu asılmak yerine yükü atar:

edit()
startEdit()

cd('/Servers/myserver/OverloadProtection/myserver')
# Yeni istekler reddedilmeden önce sunucu genelindeki toplam kuyruk
cmo.setSharedCapacityForWorkManagers(65536)
# Takılı iş parçacığı ele alımı: bir parçacık ne kadar çalışınca takılı sayılır
cd('/Servers/myserver')
cmo.setStuckThreadMaxTime(600)
cmo.setStuckThreadTimerInterval(60)
# Başarısızlık eşiğine ulaşınca alınacak eylem
cd('/Servers/myserver/OverloadProtection/myserver')
cmo.setFailureAction('force-shutdown')   # ya da karantina için 'administrative'
cmo.setPanicAction('system-exit')        # bellek yetersizliğinde temiz çıkış, denetleyici yeniden başlatır

save()
activate()

Sunucuyu tükenmeye iten bir DDoS altında bu, “sunucu asılır ve elle yeniden başlatılır” ile “sunucu yükü 503 ile atar ve yönetilebilir kalır” arasındaki farktır. Biri kesinti, diğeri sınırlı bir olaydır.

5. İstek boyutu sınırları

Web Server MBean’inde büyük istek yüzeyini kapatın:

edit()
startEdit()
cd('/Servers/myserver/WebServer/myserver')
cmo.setMaxPostSize(10485760)       # 10 MB
cmo.setMaxPostTimeoutSecs(30)      # bir POST gövdesini okumak için izin verilen süre
cmo.setPostTimeoutSecs(30)
save()
activate()

MaxPostSize ve post zaman aşımları, bir isteği açıp gövdeyi yavaş ya da devasa gönderen saldırı sınıfını kapatır. Varsayılan sınırsız post boyutu, internete komşu her domain için yanlış seçimdir.

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

Önde Oracle HTTP Server ya da bir proxy varken, WebLogic’in WebLogic eklentisinin ilettiği başlıkları (WLProxyPassThrough ile eklentinin WL-Proxy-Client-IP değeri) kullanması gerekir; böylece log’lar ve kurallar proxy’yi değil gerçek istemciyi görür. Eklentinin istemci adresini ilettiğini ve WebLogic’in buna güvenmeye ayarlandığını doğrulayın. Aksi hâlde her istek proxy’ye atfedilir. Bu, seri boyunca tekrarlayan proxy-IP hatasıdır.

İzlemeye bağlanacak sinyaller

# WLST serverRuntime() içinde, ThreadPoolRuntime'dan:
#   1. PendingUserRequestCount — kuyruğa alınan iş (sel imzası)
#   2. HoggingThreadCount — fazla tutulan iş parçacıkları (yavaş istek ya da takılı)
#   3. ExecuteThreadTotalCount ile throughput karşılaştırması — havuz doygunluğu
#   4. Açık soket sayısı ile MaxOpenSockCount karşılaştırması
cd('/ThreadPoolRuntime/ThreadPoolRuntime')
cmo.getPendingUserRequestCount()
cmo.getHoggingThreadCount()

Yükselen bir PendingUserRequestCount ile artan bir HoggingThreadCount, istek hızının WebLogic’in işleyebileceğini aştığının imzasıdır. Bu, ön katmanın ya da bir üst katmanın fazlayı emmesi gereken noktadır.

Bu katmanın dürüst sınırı

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

Birincisi hat doluluğu: hattı dolduran hacim ne ön katmana ne de WebLogic’e ulaşır.

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

Uygulama sırası

1. Dinleme adresinin iç olduğunu doğrulayın; önüne Oracle HTTP Server ya da bir proxy koyun.
2. Temel ölçüleri kaydedin: bekleyen istekler, fazla tutulan iş parçacıkları, açık soketler.
3. Complete Message Timeout ve bağlantı sınırlarını WLST ile ayarlayın.
4. Kuyruğa alınan işi sınırlamak için bir capacity kısıtı ekleyin.
5. Sunucunun asılmak yerine yükü atması için Overload Protection’ı yapılandırın.
6. Post boyutu ve post zaman aşımı sınırlarını koyun; eklentinin istemci IP’sini ilettiğini doğrulayın.
7. Çalışma zamanı sayaçlarını izlemeye bağlayın.

Birinci adım, sonucu yine en çok değiştiren karardır. WebLogic kontrolleri ikinci hattır ve ancak arkasında durdukları ilk hat kadar değerlidir.