Configure request throttling for IBM Controller Disclosure Management to protect
against brute force attacks and denial-of-service (DoS) conditions by setting rate limit
variables in the server.env file.
Before you begin, ensure that:
- IBM Controller Disclosure Management Server is installed.
- You have administrator access to the server file system.
- The server.env file is located at
<install-dir>/wlp/usr/servers/ibmdm/server.env.
About this task
Rate limiting controls how many requests a single IP address can make within a defined
time window. IBM Controller Disclosure Management applies separate rate limits to
authentication endpoints and API endpoints. You can tune each limit independently based
on your deployment size and security requirements.
Important: Rate limiting must be enabled in all production deployments.
Disabling rate limiting removes protection against brute force password attacks and
DoS conditions.
-
Open the server.env file in a text editor with administrator
privileges.
-
Enable rate limiting globally by setting the following variable:
RATE_LIMIT_ENABLED=true
Warning: Set this value to true in all production
environments. Setting it to false disables all rate limit
protection.
-
Set the authentication endpoint rate limit to control the maximum number of login
attempts per IP address per minute:
RATE_LIMIT_AUTH_RPM=10
This variable limits login attempts to prevent brute force password attacks.
Choose a value appropriate for your security level:
Table 1. Recommended values for RATE_LIMIT_AUTH_RPM
| Security level |
Value |
Notes |
| High security (banking/finance) |
5 |
1 attempt every 12 seconds |
| Standard security (recommended) |
10 |
1 attempt every 6 seconds (default) |
| Relaxed (development/testing only) |
20 |
1 attempt every 3 seconds. Do not use in production. |
-
Set the API endpoint rate limit to control the maximum number of API requests per
IP address per minute:
RATE_LIMIT_API_RPM=600
Choose a value that reflects your expected usage pattern:
Table 2. Recommended values for RATE_LIMIT_API_RPM
| Usage pattern |
Value |
Throughput |
| Light usage (small teams) |
300 |
5 requests/second |
| Standard usage (recommended) |
600 |
10 requests/second (default) |
| Heavy usage (dashboards/reports) |
1200 |
20 requests/second |
| Very heavy usage (API integrations) |
3600 |
60 requests/second |
-
Set the rate limit cache size to define the maximum number of unique IP addresses
tracked simultaneously:
RATE_LIMIT_CACHE_MAX_SIZE=10000
Use the following formula to estimate the value for your deployment:
users × 3 (office, home, mobile) × 1.5 (safety margin).
Table 3. Recommended values for RATE_LIMIT_CACHE_MAX_SIZE
| Deployment size |
Value |
| Small (fewer than 50 users) |
1000 |
| Medium (50–500 users) |
5000 |
| Large (500–5000 users) |
10000 |
| Enterprise (more than 5000 users) |
50000 |
-
Set the cache expiry time to define how long inactive IP addresses are retained in
the cache (in minutes):
RATE_LIMIT_CACHE_EXPIRE_MINUTES=10
Note: Longer retention improves detection of slow-rate attacks but
increases memory usage. The recommended default is 10 minutes.
-
Save server.env and restart the IBM Controller Disclosure
Management service for the changes to take effect.
Rate limiting is active. Authentication and API endpoints are now protected against
brute force and DoS attacks according to the configured thresholds.
What to do next
After enabling rate limiting, review the following quick-configuration profiles for
common deployment scenarios. To apply a profile, replace the individual variable values
in server.env with the corresponding values from the table.
Table 4. Quick-configuration profiles
| Profile |
RATE_LIMIT_AUTH_RPM |
RATE_LIMIT_API_RPM |
RATE_LIMIT_CACHE_MAX_SIZE |
RATE_LIMIT_CACHE_EXPIRE_MINUTES |
| Development (relaxed limits) |
20 |
1000 |
10000 |
30 |
| Small business (fewer than 50 users) |
10 |
300 |
1000 |
10 |
| Enterprise (more than 500 users, heavy usage) |
10 |
1200 |
50000 |
15 |
| Maximum security |
5 |
300 |
10000 |
10 |