Global Connection Limits

The Global Connection Limits control how UDMG 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 and protections described in this page operate on 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 UDMG Server Configuration File, while others are managed at the Domain level through the UDMG REST API.

Users

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

Rate Limits

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

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

These limits are defined in the api block and in the observability.api block of the UDMG Server Configuration File:

/opt/udmg/etc/udmg-server.hcl
api {
    # Rate limit for UDMG REST API.
    rate_limit = 5000
}

observability {
    api {
        # Rate limit for the Observability API.
        rate_limit = 5000
    }
}

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

The Allow Concurrent User Login setting controls whether a User may maintain multiple simultaneous authenticated sessions across different devices or browsers.

When this setting is disabled, only one active session is permitted per User. If the same User logs in from a new device or browser, UDMG immediately terminates the previous session and replaces it with the new one.

This behavior enhances security by ensuring that User credentials cannot be used concurrently from multiple locations, but it may disrupt legitimate multi-device usage.

This option is configured in the api block of the UDMG Server Configuration File:

/opt/udmg/etc/udmg-server.hcl
api {
    # When false, only one session is allowed per User.
    # Default: true
    allow_concurrent_user_login = true
}

User Lockout Policy

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

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

rest /api/v1/domains/${DOMAIN_UUID}/config/authSecurityConfig -X POST -d @- 
{
  "userFailedAttemptsLimit": 5,
  "userFailedAttemptsWindow": 600,
  "userFailedAttemptsLockTime": 1800
}

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

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 the UDMG Endpoints, ensuring fair resource usage and consistent performance across all connected partners.

Account Sessions Limit

The Maximum Concurrent Sessions setting defines the maximum number of concurrently open authenticated sessions per Account across all protocol listeners.

This limit is enforced per UDMG Server node and applies globally across all listener types, including SFTP, FTPS/FTP, AS2, and HTTP (WTC). Once the limit is reached, any new session attempts are rejected until an existing session closes.

This setting is configured through the UDMG REST API using the following request:

rest /api/v1/domains/${DOMAIN_UUID}/config/maxConcurrentAccountSessions -X PUT -d @-
{
   "value": 10
}

Maximum Concurrent Connections

This limit applies globally across all protocol listeners (SFTP, FTPS/FTP, AS2, HTTP/WTC) and is enforced independently by each UDMG Server node.

This limit is configured in the protocol block of the UDMG Server Configuration File:

/opt/udmg/etc/udmg-server.hcl
protocol {
    # Default: 120
    max_connections = 120
}

Account Lockout Policy

UDMG includes a built-in protection to prevent brute-force attacks against partner-facing authentication mechanisms. This mechanism tracks failed authentication attempts for valid Accounts and temporarily locks an Account if too many failures occur within a defined time window.

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

rest /api/v1/domains/${DOMAIN_UUID}/config/authSecurityConfig -X POST -d @- 
{
  "accountFailedAttemptsLimit": 5,
  "accountFailedAttemptsWindow": 600,
  "accountFailedAttemptsLockTime": 1800
}

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

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.

Maximum Public Connections (WTC)

The Maximum Public Connections configuration defines the maximum number of concurrent connections or downloads for all Shared Public Links.

The counters are maintained per UDMG node and are not shared across a cluster. They are also subordinate to the Maximum Concurrent Connections (across all protocols).

This limit is configured in the wtc block of the UDMG Server Configuration File:

/opt/udmg/etc/udmg-server.hcl
wtc {
    # Default: 1000
    max_public_connections = 1000 
}

When the number of requests exceeds the configured limit, additional attempts are rejected.

Timeout for Idle Sessions

The Timeout for Idle Sessions defines how long an unauthenticated protocol session may remain open before UDMG automatically terminates it.

This protects the system from idle or stalled connection attacks, where a client opens a TCP connection to the server (SFTP or FTP/S) 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 UDMG Server node.

This limit is configured in the protocol block of the Configuration File:

/opt/udmg/etc/udmg-server.hcl
protocol {
    # Default: 3600s
    session_idle_timeout = 3600s
}

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

warning

The Web Transfer Client (WTC) enforces a fixed idle timeout of 15 minutes.

To avoid inconsistent behavior, configure protocol.session_idle_timeout to a value below 15 minutes. If it is set to 15 minutes or more, WTC sessions may behave unexpectedly when they become idle.

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

UDMG 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 settings are configured through the UDMG REST API. For example:

rest /api/v1/domains/${DOMAIN_UUID}/config/authSecurityConfig -X POST -d @- 
{
  "ipInvalidUsernameLimit": 5,
  "ipInvalidUsernameWindow": 600,
  "ipInvalidUsernameLockTime": 1800
}

Property	Description	Default Value
`ipInvalidUsernameLimit`	The maximum number of failed login attempts allowed for a single IP address before a lockout is triggered.	`0`
`ipInvalidUsernameWindow`	The time window (in seconds) in which those failed login attempts are counted. After the window expires, the counter resets.	`0`
`ipInvalidUsernameLockTime`	The duration (in seconds) for which the IP remains blocked after exceeding the limit. During this period, all authentication attempts from that IP are rejected.	`0`

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.

Users​

Rate Limits​

Allow Concurrent User Login​

User Lockout Policy​

Accounts​

Account Sessions Limit​

Maximum Concurrent Connections​

Account Lockout Policy​

Maximum Public Connections (WTC)​

Timeout for Idle Sessions​

IP-Based Protections​

IP Ban​

Operational Caveats and Best Practices​

Avoid IP-Based Ban in Environments with Shared IPs​

Tune IP-Based Ban and Lockout Policies Thresholds Independently​

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

Document Your Organization's Policy​