Укрепление WebLogic против DDoS: Work Manager, тайм-ауты сообщений и Overload Protection

Это руководство укрепляет сам Oracle WebLogic Server против той части DDoS-атаки, что исчерпывает работу и соединения. WebLogic меняет подход по сравнению с другими серверами приложений в одном важном отношении: ограничивать нечего — нет фиксированного пула потоков. WebLogic самонастраивает единый пул, поэтому защита — это не число maxThreads, а набор ограничений Work Manager, тайм-аутов сообщений и действий Overload Protection, решающих, что делает сервер при исчерпании ресурса.

Как и Tomcat и JBoss, WebLogic — сервер приложений и стоит за укреплённым фронтовым слоем (Oracle HTTP Server или другой прокси). Контроли ниже — вторая линия. Каждая настройка приводится с её MBean, командой WLST и счётчиком, показывающим её работу.

Устройство	Форма атаки	Контроль WebLogic	Где он живёт
Медленный заголовок / медленное тело	Complete Message Timeout; Idle Connection Timeout	WebServer / Server MBean
Наводнение соединениями	Accept Backlog; Maximum Open Sockets	Server MBean
Насыщение работой	Work Manager max-threads-constraint, capacity	self-tuning work managers
Злоупотребление большими запросами	Max Post Size, Max Message Size, Post Timeout	WebServer MBean
Перегрузка сервера	Overload Protection: shared capacity, panic action	Overload MBean

WebLogic сам настраивает пул потоков, поэтому защита — это ограничения и действия при перегрузке, а не предел maxThreads. Как и с Tomcat и JBoss, сначала идёт укреплённый фронтовой слой; это вторая линия. Ничего из этого не помогает, когда атака заполняет канал.

0. Сначала базовые значения: счётчики потоков и соединений

WebLogic раскрывает состояние выполнения через MBean, читаемые в WLST. Запишите за обычную неделю числа пула, очереди и соединений:

# WLST — подключиться и прочитать самонастраивающийся пул и канал сервера
connect('weblogic', 'password', 't3://localhost:7001')
serverRuntime()

# Самонастраивающийся пул: выполняется, простаивает, длина очереди, throughput
cd('/ThreadPoolRuntime/ThreadPoolRuntime')
ls()   # ExecuteThreadTotalCount, HoggingThreadCount, PendingUserRequestCount, Throughput

# Открытые сокеты на канале по умолчанию
cd('/ServerChannelRuntimes')

PendingUserRequestCount и HoggingThreadCount относительно базы обычной недели, вместе с числом открытых сокетов, — это те значения, относительно которых задаётся всё ниже.

1. Сначала фронтовой слой

Убедитесь, что адрес прослушивания WebLogic внутренний, а перед ним стоит Oracle HTTP Server или прокси:

# Адрес прослушивания должен быть внутренним интерфейсом, а не публичным
ss -ltnp | grep 7001

Если он публичный, привяжите его к внутреннему адресу и завершайте интернет-соединение на фронтовом слое, который разбирают руководства по nginx и Apache. Oracle HTTP Server — производная Apache, поэтому руководство по Apache применимо близко.

2. Тайм-ауты сообщений и соединений

Complete Message Timeout — основная защита от Slowloris. Задайте его и ограничения соединений через WLST:

edit()
startEdit()

# Slowloris: максимальное время на получение полного сообщения запроса (секунды)
cd('/Servers/myserver')
cmo.setCompleteMessageTimeout(60)

# Тайм-аут простоя соединения (секунды) — закрывает открытое и простаивающее соединение
cmo.setIdleConnectionTimeout(30)

# Backlog соединений и потолок открытых сокетов
cmo.setAcceptBacklog(300)
cmo.setMaxOpenSockCount(8192)

save()
activate()

Complete Message Timeout — серверное значение по умолчанию с переопределением на уровне Web Server. На старом домене оно часто установлено на разрешительное значение, и снижение его до нескольких десятков секунд — самое эффективное средство против медленных запросов здесь.

3. Ограничения Work Manager: ограничивать работу, а не пул

Поскольку пул самонастраивается, вы ограничиваете классы работы. Ограничение capacity — то, что связывает, сколько наводнение запросов может поставить в очередь, прежде чем WebLogic отклонит с 503:

edit()
startEdit()

# Ограничение max-threads ограничивает потоки для класса работы
cd('/SelfTuning/mydomain')
cmo.createMaxThreadsConstraint('MaxThreadsForApp')
cd('/SelfTuning/mydomain/MaxThreadsConstraints/MaxThreadsForApp')
cmo.setCount(128)

# Ограничение capacity связывает сумму «в очереди + в работе» до отклонения (503)
cd('/SelfTuning/mydomain')
cmo.createCapacity('AppCapacity')
cd('/SelfTuning/mydomain/Capacities/AppCapacity')
cmo.setCount(4096)

save()
activate()

Именно ограничение capacity относится к DDoS. Оно превращает неограниченную очередь под наводнением в чистое отклонение и защищает уже выполняемую работу.

4. Overload Protection: предсказуемый отказ

Overload Protection решает, что делает WebLogic при исчерпании ресурса, чтобы он сбрасывал нагрузку, а не зависал:

edit()
startEdit()

cd('/Servers/myserver/OverloadProtection/myserver')
# Общее число запросов в очереди по серверу до отклонения новых
cmo.setSharedCapacityForWorkManagers(65536)
# Обработка зависших потоков: сколько поток может работать, прежде чем считаться зависшим
cd('/Servers/myserver')
cmo.setStuckThreadMaxTime(600)
cmo.setStuckThreadTimerInterval(60)
# Действие при достижении порога отказа
cd('/Servers/myserver/OverloadProtection/myserver')
cmo.setFailureAction('force-shutdown')   # или 'administrative' для карантина
cmo.setPanicAction('system-exit')        # при нехватке памяти — чистый выход, супервизор перезапустит

save()
activate()

Под DDoS, толкающим сервер к исчерпанию, это разница между «сервер завис, и его перезагружают вручную» и «сервер сбрасывает нагрузку с 503 и остаётся управляемым»: ограниченный инцидент вместо отказа.

5. Ограничения размера запроса

Закройте поверхность больших запросов на MBean Web Server:

edit()
startEdit()
cd('/Servers/myserver/WebServer/myserver')
cmo.setMaxPostSize(10485760)       # 10 МБ
cmo.setMaxPostTimeoutSecs(30)      # время, отпущенное на чтение тела POST
cmo.setPostTimeoutSecs(30)
save()
activate()

MaxPostSize и тайм-ауты POST закрывают класс атаки, открывающей запрос и отправляющей тело медленно или огромным. Неограниченный размер POST по умолчанию — неверный выбор для любого домена, соседнего с интернетом.

6. IP клиента за фронтовым слоем

Когда впереди Oracle HTTP Server или прокси, WebLogic должен использовать переданные плагином WebLogic заголовки (WLProxyPassThrough и значение WL-Proxy-Client-IP плагина), чтобы логи и правила видели реального клиента, а не прокси. Убедитесь, что плагин настроен передавать адрес клиента и что WebLogic настроен ему доверять. Иначе каждый запрос приписывается прокси — повторяющийся сбой с IP прокси во всей этой серии.

Сигналы для мониторинга

# В WLST serverRuntime(), из ThreadPoolRuntime:
#   1. PendingUserRequestCount — работа в очереди (сигнатура наводнения)
#   2. HoggingThreadCount — потоки, удерживаемые слишком долго (медленный запрос или зависание)
#   3. ExecuteThreadTotalCount против throughput — насыщение пула
#   4. Число открытых сокетов против MaxOpenSockCount
cd('/ThreadPoolRuntime/ThreadPoolRuntime')
cmo.getPendingUserRequestCount()
cmo.getHoggingThreadCount()

Растущий PendingUserRequestCount с растущим HoggingThreadCount — сигнатура того, что частота запросов переросла то, что WebLogic способен обработать. Это точка, где фронтовой слой или вышестоящий уровень должен поглотить избыток.

Честный предел укрепления WebLogic

Всё здесь защищает прикладной уровень за фронтовым слоем, который должен ловить большую часть первым. Два случая лежат вне этого.

Первый — заполнение канала: объём, заполняющий трубу, не доходит ни до фронтового слоя, ни до WebLogic.

Второй — уровень ОС под серверами, разобранный в руководствах по Linux и Windows. Укрепление WebLogic предполагает, что и фронтовой слой, и уровень ОС уже на месте. Выше канала ответ — сетевой уровень.

Порядок применения

1. Убедитесь, что адрес прослушивания внутренний; поставьте перед ним Oracle HTTP Server или прокси.
2. Запишите базу: запросы в очереди, зависшие потоки, открытые сокеты.
3. Задайте Complete Message Timeout и ограничения соединений через WLST.
4. Добавьте ограничение capacity, чтобы связать работу в очереди.
5. Настройте Overload Protection, чтобы сервер сбрасывал нагрузку, а не зависал.
6. Задайте ограничения размера и тайм-аутов POST; убедитесь, что плагин передаёт IP клиента.
7. Подключите счётчики выполнения к мониторингу.

Первый шаг снова — решение, сильнее всего меняющее исход. Контроли WebLogic — вторая линия, ценная лишь за первой линией, за которой они стоят.