Global Connection Limits

The Global Connection Limits control how USP manages incoming connections, authenticated sessions, and API request rates. These settings help maintain stable performance, protect against abusive or malicious traffic, and prevent resource exhaustion under high load or targeted attacks.

The limits described in this page apply to three scopes:

• Users: Administrators accessing the UDMG Admin UI, UDMG REST API, or Observability API, including attack attempts that use valid User credentials.
• Accounts: Partners authenticating to UDMG Endpoints for file transfer operations, including attack attempts that use Accounts credentials.
• IP-Based Protections: Source IP-level controls that monitor authentication behavior and can restrict or block any client at that IP, whether requests are legitimate, use invalid usernames, or attempt to impersonate existing Users or Accounts.

Some limits are configured at the node level in the USP Server Configuration File or USP Manager Configuration File, while others are managed through the USP REST API.

Users

The security measures in this section apply to administrative access. They define limits for Users interacting with the USP Admin UI and USP REST API, ensuring fair resource usage and consistent performance across all connected administrators.

Rate Limit

The Rate Limit configurations define the maximum number of API requests that a USP Manager instance allows per minute for the USP REST API. It helps control request throughput and protects the system from excessive or abusive API usage.

Rate limit counters are maintained per USP node and are not shared across a cluster.

These limits are defined in the web block of the USP Manager Configuration File:

/opt/udmg/etc/usp-manager.hcl

web {
    # Rate Limit Configuration.
    rate_limit {
        # Global limit for all endpoints in requests per minute (default: 5000).
        global = "5000"
    }
}

When the number of requests exceeds the configured limit, additional attempts are rejected with an HTTP 429 Too Many Requests response.

Maximum Concurrent User Sessions

The Maximum Concurrent User Sessions setting limits how many simultaneous authenticated sessions each User can maintain in the USP Admin UI and USP REST API.

A session corresponds to an active access token issued for that User (for example, a login in a browser or on a device). When the number of active sessions reaches the configured limit, additional login attempts are rejected until one of the existing sessions ends.

This mechanism applies uniformly to all administrative authentication methods:

• Standard Password (local Users)
• LDAP
• OIDC
• SAML

Default value is 0 concurrent sessions per User, which means there is no limit.

To change this limit, set the userMaxConcurrentSessions parameter making a PATCH request to the USP Manager API. For example:

curl -X PATCH "https://<USP_MANAGER_HOST>:<PORT>/v1/admin/security" \
  -H "Authorization: Bearer <admin-access-token>" \
  -H "Content-Type: application/json" \
  -d '{
    "userMaxConcurrentSessions": 5
  }'

User Lockout Policy

USP includes a built-in protection to prevent brute-force attacks against the USP Admin UI and the USP REST API. This mechanism tracks failed authentication attempts with valid usernames and temporarily locks a User if too many failures occur within a defined time window.

The setting is configured through the USP REST API. For example:

curl -X PATCH "http://<USP_MANAGER_HOST>:<PORT>/v1/system/security" \
    -H "Authorization: Bearer <ACCESS_TOKEN>" \
    -H "Content-Type: application/json" \
    -d '{
        "userAuthBlockConfig": {
            "limit": 5,
            "window": "30s",
            "duration": "1m"
        }

Property	Description	Default Value
limit	The maximum number of failed login attempts allowed for a valid User before a lockout is triggered.	0
window	The time window in which those failed attempts are counted. After the window expires, the counter resets.	0s
duration	The duration for which the User remains locked after exceeding the limit. During this period, all authentication attempts for the User are rejected.	0s

info

• If any of the three fields is set to 0, the blocking mechanism is disabled.
• Configuration is validated to ensure either all three fields are set or all are zero.

info

Incorrect password attempts for a valid username indicate attempts to guess the password of an existing User. Each failed login increments that User's lockout counter. When the counter reaches the configured limit, that User is temporarily locked and all further login attempts are rejected for the duration of the lockout.

When IP Ban is also enabled, each incorrect password attempt contributes to:

• The User's lockout counter, and
• The originating IP's failure counter (used to detect multi-vector attacks).

This combined behavior helps protect against attackers who mix techniques (for example, alternating between username enumeration and password guessing) from the same source IP.

Accounts

The parameters in this section apply to transfer scenarios. They define limits for Accounts interacting with USP Endpoints, ensuring fair resource usage and consistent performance across all connected partners.

Rate Limit

The Rate Limit configurations define the maximum number of API requests that a USP Server instance allows per minute. It helps control request throughput and protects the system from excessive or abusive usage.

Rate limit counters are maintained per USP Server node and are not shared across a cluster.

These limits are defined in the web block of the USP Server Configuration File:

/opt/udmg/etc/usp-server.hcl

web {
    # Rate Limit Configuration.
    rate_limit {
        # Global limit for all endpoints in requests per minute (default: 5000).
        global = "5000"
    }
}

When the number of requests exceeds the configured limit, additional attempts are rejected with an HTTP 429 Too Many Requests response.

Account Lockout Policy

USP includes a built-in protection to prevent brute-force attacks against the USP Server Listeners. This mechanism tracks failed authentication attempts with valid Accounts and temporarily locks an User if too many failures occur within a defined time window.

The setting is configured through the USP REST API. For example:

curl -X PATCH "http://<USP_MANAGER_HOST>:<PORT>/v1/system/security" \
    -H "Authorization: Bearer <ACCESS_TOKEN>" \
    -H "Content-Type: application/json" \
    -d '{
        "accountAuthBlockConfig": {
            "limit": 5,
            "window": "30s",
            "duration": "1m"
        }

Property	Description	Default Value
limit	The maximum number of failed login attempts allowed for a valid Account before a lockout is triggered.	0
window	The time window in which those failed attempts are counted. After the window expires, the counter resets.	0s
duration	The duration for which the Account remains locked after exceeding the limit. During this period, all authentication attempts for the Account are rejected.	0s

info

• If any of the three fields is set to 0, the blocking mechanism is disabled.
• Configuration is validated to ensure either all three fields are set or all are zero.

info

Incorrect password attempts for a valid username indicate attempts to guess the password of an existing Account. Each failed login increments that Account's lockout counter. When the counter reaches the configured limit, that Account is temporarily locked and all further login attempts are rejected for the duration of the lockout.

When IP Ban is also enabled, each incorrect password attempt contributes to:

• The Account's lockout counter, and
• The originating IP's failure counter (used to detect multi-vector attacks).

This combined behavior helps protect against attackers who mix techniques (for example, alternating between username enumeration and password guessing) from the same source IP.

Timeout TTL for Idle Connections

The Timeout TTL for Idle Connections defines how long an unauthenticated protocol session may remain open before USP Server automatically terminates it.

This protects the system from idle or stalled connection attacks, where a client opens a TCP connection to the server (FTP, FTPS, FTPES, or SFTP) and then remain idle, never responding to authentication prompts. Such stalled sessions can consume socket and thread resources, reducing availability for legitimate partners.

This timeout applies to all protocol listeners and is enforced per USP Server node.

This limit is configured in the connection block of the USP Server Configuration File:

/opt/udmg/etc/usp-server.hcl

connection {
    # Default: 60s
    idle_timeout = 60s
}

When a session exceeds this timeout without completing authentication or sending data, USP Server closes the connection automatically.

Maximum Concurrent Connections

This limit applies globally across all protocol listeners (SFTP, FTP(S), HTTP(S)) and is enforced independently by each USP Server node.

This limit is configured in the connection block of the USP Server Configuration File:

/opt/udmg/etc/usp-server.hcl

protocol {
    # Default: 0 (no limit)
    max_connections = 120
}

When the number of concurrent connections reaches this limit, additional connection attempts are rejected until existing connections close.

Default value is 0, which means there is no limit.

IP-Based Protections

Unlike User and Account lockout policies, IP-based protections evaluate the behavior of the source IP itself rather than the identity being used.

IP Ban

USP also enforces protections against repeated authentication attempts coming from the same IP address.

This mechanism tracks failed login attempts with invalid and valid usernames (for Accounts and Users), and temporarily blocks the offending IP if too many failures occur within a defined time window.

This helps prevent automated username-guessing attacks and reduces the risk of large-scale credential probing.

The setting is configured through the USP REST API. For example:

curl -X PATCH "http://<USP_MANAGER_HOST>:<PORT>/v1/system/security" \
    -H "Authorization: Bearer <ACCESS_TOKEN>" \
    -H "Content-Type: application/json" \
    -d '{
        "addressAuthBlockConfig": {
            "limit": 5,
            "window": "30s",
            "duration": "1m"
        }

Property	Description	Default Value
limit	The maximum number of failed login attempts allowed for an IP before a lockout is triggered.	0
window	The time window in which those failed attempts are counted. After the window expires, the counter resets.	0s
duration	The duration for which the IP remains locked after exceeding the limit. During this period, all authentication attempts for the IP are rejected.	0s

info

• If any of the three fields is set to 0, the blocking mechanism is disabled.
• Configuration is validated to ensure either all three fields are set or all are zero.

tip

Because IP Ban depends on uniquely attributing requests to an originating IP, this limit should only be enabled in environments without shared IPs, NAT, load balancer address masking, or VPN concentrators. If multiple legitimate Users or Accounts appear to originate from the same IP, turning on this feature may unintentionally block all of them.

Operational Caveats and Best Practices

Avoid IP-Based Ban in Environments with Shared IPs

Use IP Ban only in environments where most source IP addresses represent a single client or system.

In networks that rely on NAT, proxies, VPN concentrators, or other large shared egress points, many different Users and Accounts can appear to originate from the same public IP. In these cases, enabling IP-based bans can cause a single misbehaving client to trigger a ban that unintentionally blocks legitimate traffic for other users behind the same IP.

Tune IP-Based Ban and Lockout Policies Thresholds Independently

Use different thresholds for:

• Username-enumeration controls in IP Ban.
• Incorrect-password protections in User Lockout Policy and Account Lockout Policy.

A low threshold (for example, 3 invalid usernames) is reasonable for detecting username enumeration, while incorrect-password thresholds should be tuned with normal user error rates in mind.

When both features are enabled, it is generally recommended to configure the invalid-username limit lower than the User/Account lockout limits, so enumeration attempts are detected and blocked earlier than typical password-entry mistakes.

Monitor Audit Logs When IP-Based Ban and Lockout Policies Are Enabled

When IP Ban, User Lockout Policy, and Account Lockout Policy are all enabled, invalid usernames and incorrect passwords both contribute to IP bans.

Administrators should periodically review login failure, ban, and lockout events in the audit logs to confirm that thresholds and behavior match expectations.

Document Your Organization's Policy

Internal security administrators should document:

• Whether source IP uniqueness can be guaranteed in environments where IP Ban is enabled.
• Which thresholds are configured for User Lockout Policy, Account Lockout Policy, and IP Ban.
• How IP bans and User/Account lockouts are monitored and remediated operationally.

This documentation helps ensure consistent configuration and incident handling over time.