WebLogic DDoS Hardening: Work Managers, Message Timeouts and Overload Protection

This guide hardens Oracle WebLogic Server itself against the work- and connection-exhausting part of a DDoS attack. WebLogic changes the approach from the other application servers in one important way: there is no fixed thread pool to cap. WebLogic self-tunes a single pool, so the defence is not a maxThreads number but a set of Work Manager constraints, message timeouts, and Overload Protection actions that decide what the server does when it runs out of a resource.

As with Tomcat and JBoss, WebLogic is an application server and belongs behind a hardened front layer — Oracle HTTP Server or another proxy. The controls below are the second line. Every setting comes with its MBean, its WLST command and the counter that shows it working.

Appliance	Attack shape	WebLogic control	Where it lives
Slow-header / slow-body	Complete Message Timeout; Idle Connection Timeout	WebServer / Server MBean
Connection flood	Accept Backlog; Maximum Open Sockets	Server MBean
Work saturation	Work Manager max-threads-constraint, capacity	self-tuning work managers
Large-request abuse	Max Post Size, Max Message Size, Post Timeout	WebServer MBean
Server overload	Overload Protection: shared capacity, panic action	Overload MBean

WebLogic self-tunes its thread pool, so the defence is constraints and overload actions, not a maxThreads cap. As with Tomcat and JBoss, a hardened front layer comes first; these are the second line. None of it helps once the attack fills the circuit.

0. Baseline first: read the thread and connection metrics

WebLogic exposes runtime state through MBeans, readable in WLST. Record a normal week’s thread pool, queue and connection numbers:

# WLST — connect and read the self-tuning pool and the server channel
connect('weblogic', 'password', 't3://localhost:7001')
serverRuntime()

# Self-tuning thread pool: executing, idle, queue length, throughput
cd('/ThreadPoolRuntime/ThreadPoolRuntime')
ls()   # ExecuteThreadTotalCount, HoggingThreadCount, PendingUserRequestCount, Throughput

# Open sockets on the default channel
cd('/ServerChannelRuntimes')

PendingUserRequestCount and HoggingThreadCount against a normal-week baseline, and the open socket count, are what every value below is set against.

1. The front layer comes first

Confirm WebLogic’s listen address is internal, with Oracle HTTP Server or a proxy in front:

# The listen address should be an internal interface, not a public one
ss -ltnp | grep 7001

If it is public, bind it internally and terminate the internet connection at the front layer, which the nginx and Apache guides cover (Oracle HTTP Server is an Apache derivative, so that guide applies closely).

2. Message and connection timeouts

Complete Message Timeout is the primary Slowloris defence. Set it and the connection limits through WLST:

edit()
startEdit()

# Slowloris: max time to receive a complete request message (seconds)
cd('/Servers/myserver')
cmo.setCompleteMessageTimeout(60)

# Idle connection timeout (seconds) — close a connection that opens and sits idle
cmo.setIdleConnectionTimeout(30)

# Connection backlog and the open-socket ceiling
cmo.setAcceptBacklog(300)
cmo.setMaxOpenSockCount(8192)

save()
activate()

Complete Message Timeout is a server default with a per-Web-Server override; on an older domain it is often at a permissive value, and lowering it to the low tens of seconds is the single most effective slow-request mitigation here.

3. Work Manager constraints: bounding the work, not the pool

Because the pool self-tunes, you constrain classes of work. A capacity constraint is the one that bounds how much a request flood can queue before WebLogic rejects with a 503:

edit()
startEdit()

# A max-threads constraint caps threads for a class of work
cd('/SelfTuning/mydomain')
cmo.createMaxThreadsConstraint('MaxThreadsForApp')
cd('/SelfTuning/mydomain/MaxThreadsConstraints/MaxThreadsForApp')
cmo.setCount(128)

# A capacity constraint bounds total queued + running before rejection (503)
cd('/SelfTuning/mydomain')
cmo.createCapacity('AppCapacity')
cd('/SelfTuning/mydomain/Capacities/AppCapacity')
cmo.setCount(4096)

save()
activate()

The capacity constraint is the DDoS-relevant one: it is the bound that turns an unbounded queue under a flood into a clean rejection, protecting the work that is already running.

4. Overload Protection: failing predictably

Overload Protection decides what WebLogic does when it runs out of a resource, so it sheds load instead of hanging:

edit()
startEdit()

cd('/Servers/myserver/OverloadProtection/myserver')
# Total queued requests across the server before rejecting new ones
cmo.setSharedCapacityForWorkManagers(65536)
# Stuck-thread handling: how long a thread may run before it counts as stuck
cd('/Servers/myserver')
cmo.setStuckThreadMaxTime(600)
cmo.setStuckThreadTimerInterval(60)
# Action when the failure threshold is reached
cd('/Servers/myserver/OverloadProtection/myserver')
cmo.setFailureAction('force-shutdown')   # or 'administrative' to quarantine
cmo.setPanicAction('system-exit')        # on OOM, exit cleanly for a supervisor to restart

save()
activate()

Under a DDoS that pushes the server toward exhaustion, this is the difference between “the server hangs and is rebooted by hand” and “the server sheds load with 503s and stays managed” — a bounded incident instead of an outage.

5. Request-size limits

Close the oversized-request surface on the Web Server MBean:

edit()
startEdit()
cd('/Servers/myserver/WebServer/myserver')
cmo.setMaxPostSize(10485760)       # 10 MB
cmo.setMaxPostTimeoutSecs(30)      # time allowed to read a POST body
cmo.setPostTimeoutSecs(30)
save()
activate()

MaxPostSize and the post timeouts close the class of attack that opens a request and sends a body slowly or hugely; the default unlimited post size is the wrong choice on any internet-adjacent domain.

6. Client IP behind the front layer

With Oracle HTTP Server or a proxy in front, WebLogic must use the WebLogic plug-in’s forwarded headers (WLProxyPassThrough / the plug-in’s WL-Proxy-Client-IP) so logs and rules see the real client rather than the proxy. Confirm the plug-in is configured to pass the client address and that WebLogic is set to trust it; otherwise every request is attributed to the proxy — the recurring proxy-IP failure across this series.

The signals to wire into monitoring

# In WLST serverRuntime(), from ThreadPoolRuntime:
#   1. PendingUserRequestCount — queued work (a flood signature)
#   2. HoggingThreadCount — threads held too long (slow-request or stuck)
#   3. ExecuteThreadTotalCount vs throughput — pool saturation
#   4. Open socket count vs MaxOpenSockCount
cd('/ThreadPoolRuntime/ThreadPoolRuntime')
cmo.getPendingUserRequestCount()
cmo.getHoggingThreadCount()

A climbing PendingUserRequestCount with a rising HoggingThreadCount is the signature that the request rate has outgrown what WebLogic can process — the point at which the front layer or an upstream tier has to absorb the excess.

The honest limit of WebLogic hardening

Everything here defends the application tier, behind a front layer that should catch most of it first. Two cases sit outside it.

The first is circuit saturation: volume that fills the pipe reaches neither the front layer nor WebLogic.

The second is the OS layer beneath the servers, covered in the Linux and Windows guides. WebLogic hardening assumes both the front layer and the OS layer are in place. Above the circuit, the answer is the network tier.

Order of application

1. Confirm the listen address is internal; put Oracle HTTP Server or a proxy in front.
2. Record the baseline: pending requests, hogging threads, open sockets.
3. Set Complete Message Timeout and the connection limits through WLST.
4. Add a capacity constraint to bound queued work.
5. Configure Overload Protection so the server sheds load instead of hanging.
6. Set the post-size and post-timeout limits; confirm the plug-in passes the client IP.
7. Wire the runtime metrics into monitoring.

Step 1 is, once more, the decision that most changes the outcome. The WebLogic controls are the second line, valuable only behind the first line they stand behind.