FTP servers, especially those serving many users or exposed to the internet, can become targets for abuse. A common attack vector is a brute-force login attempt, where an attacker tries thousands of username/password combinations. Another is a denial-of-service (DoS) attack, where a malicious actor floods the server with connection requests, consuming resources and preventing legitimate users from accessing the service. To mitigate these risks, you can limit the number of concurrent FTP connections a single user can establish, and also limit the number of connections originating from a single IP address. This article will show you how to configure these limits.

Let’s look at vsftpd, a popular and secure FTP daemon.

Limiting Connections Per User

vsftpd allows you to set a maximum number of concurrent connections for any given user. This is controlled by the max_per_ip and max_clients directives.

max_clients: This directive sets the global maximum number of concurrent connections to the FTP server. If this limit is reached, no new clients can connect, regardless of their IP or user.

max_per_ip: This directive sets the maximum number of concurrent connections allowed from a single IP address. This is useful for preventing a single user (or a botnet) from hogging all available connections from one source.

Here’s how you’d configure them in /etc/vsftpd.conf:

# Set the global maximum number of concurrent connections
max_clients=50

# Set the maximum number of concurrent connections per IP address
max_per_ip=5

After modifying /etc/vsftpd.conf, you need to restart the vsftpd service for the changes to take effect:

sudo systemctl restart vsftpd

Why this works: When a client attempts to connect, vsftpd checks if the total number of active connections (max_clients) has been reached. If not, it then checks how many connections are already active from the client’s IP address against max_per_ip. If either limit is exceeded, the connection is refused. This prevents a single IP from overwhelming the server and also ensures that even if multiple IPs are connecting, the total number of active sessions remains manageable.

Limiting Connections Per User (Advanced with Virtual Users)

For more granular control, especially when dealing with virtual users (users who don’t have corresponding system accounts), you might need a more sophisticated approach. vsftpd can be configured to enforce limits based on user login. This is often achieved by combining the max_per_ip directive with user_sub_token and local_root directives, or by using PAM (Pluggable Authentication Modules).

However, the most direct way vsftpd handles per-user limits is actually through max_per_ip in conjunction with how it handles anonymous vs. authenticated users. For authenticated users, max_per_ip applies to the IP address they are connecting from. If you want strict per-user limits distinct from per-IP limits, you might need to implement this at the PAM level or through a custom script that monitors vsftpd logs and dynamically adjusts limits (though this is complex).

A more common scenario is limiting connections from a specific IP, which max_per_ip handles well. If you have multiple users connecting from the same IP (e.g., an office network), max_per_ip will limit all of them.

Practical Application and Troubleshooting

Let’s say you’re experiencing slow FTP performance or seeing connection errors like 421 Too many connections or 421 Service not available, remote server has closed connection.

Diagnosis:

  1. Check current connections: You can see active connections using netstat or ss:

    sudo ss -tnp | grep :21 | grep ESTAB
    

    This command shows established TCP connections to port 21 (the FTP control port).

  2. Check vsftpd logs: The logs often contain specific error messages. For vsftpd, the log file is typically /var/log/vsftpd.log.

    sudo tail -f /var/log/vsftpd.log
    

    Look for messages indicating connection refusals due to limits.

Common Causes and Fixes:

  • Cause 1: Too many concurrent connections from a single IP address.

    • Diagnosis: Observe the netstat/ss output and the vsftpd logs. You’ll see many connections originating from the same IP.
    • Fix: Increase max_per_ip in /etc/vsftpd.conf. If you previously had max_per_ip=2, try max_per_ip=5.
    • Why it works: This directly tells vsftpd to allow more sessions from a single source, assuming that source is legitimate and requires more connections.
  • Cause 2: Global connection limit reached.

    • Diagnosis: The vsftpd logs might show general connection refusal messages, and the ss output shows a high number of total connections, approaching the max_clients limit.
    • Fix: Increase max_clients in /etc/vsftpd.conf. If max_clients was 30 and you’re hitting it, try max_clients=75.
    • Why it works: This raises the overall ceiling for concurrent FTP sessions the server will accept.
  • Cause 3: Incorrect configuration of max_per_ip or max_clients.

    • Diagnosis: You’ve made changes but they don’t seem to be applied.
    • Fix: Ensure you have restarted vsftpd after every configuration change: sudo systemctl restart vsftpd. Also, double-check the syntax in /etc/vsftpd.conf for typos.
    • Why it works: Services need to be reloaded or restarted to pick up new configuration files.
  • Cause 4: Firewall blocking connections.

    • Diagnosis: Users report being unable to connect at all, or connections dropping immediately, but vsftpd logs show no specific errors related to connection limits.
    • Fix: Ensure your firewall (e.g., ufw, firewalld, iptables) allows incoming connections on the FTP control port (21) and data ports (passive mode ports, typically a range specified in vsftpd.conf with pasv_min_port and pasv_max_port).
      • For ufw: sudo ufw allow 21/tcp and sudo ufw allow 40000:50000/tcp (if using passive ports 40000-50000).
    • Why it works: Firewalls act as gatekeepers. If they don’t permit traffic to the FTP ports, vsftpd will never see the connection requests.
  • Cause 5: System resource exhaustion (CPU/Memory/Network).

    • Diagnosis: Even with generous connection limits, performance degrades significantly, and vsftpd might report general errors or the system becomes unresponsive. Use top, htop, vmstat, iostat to monitor system resources.
    • Fix: Increase server resources (CPU, RAM), optimize vsftpd settings (e.g., listen_ipv4=YES, listen_ipv6=NO if only using IPv4), or consider load balancing if applicable.
    • Why it works: vsftpd itself consumes system resources. If the server is under heavy load from other services or a massive number of legitimate connections, even the configured limits might not be enough to maintain stability.
  • Cause 6: Incorrect user configuration for virtual users.

    • Diagnosis: If you’re using virtual users and specific limits are expected per user but not being enforced, it might be a misconfiguration in how virtual users are mapped or authenticated.
    • Fix: Review your virtual user setup, PAM configuration, or any custom scripts involved. Ensure that the max_per_ip directive is being applied correctly in your virtual user context, or that per-user limits are handled by the underlying authentication mechanism.
    • Why it works: The authentication layer is responsible for identifying the user and applying policies. If this layer is misconfigured, connection limits might not be enforced as intended.

By adjusting max_clients and max_per_ip, you can effectively deter many common FTP abuse scenarios. Remember to restart vsftpd after making any changes to /etc/vsftpd.conf.

The next common issue you’ll encounter is ensuring secure data transfer, which leads to understanding FTPS (FTP over SSL/TLS).

Want structured learning?

Take the full Ftp course →