Connection Limit Protection

Home · Start Here · Reference Map

At a glance

• CONNLIMIT caps concurrent new TCP connections per source IP and port.
• Useful for reducing abusive connection spikes and basic DoS pressure.
• Requires working kernel/netfilter xt_connlimit support.

Related guide: Security-Features-Guide

What CONNLIMIT does

CONNLIMIT tells CSF to enforce per-IP connection ceilings for specific TCP ports.

It is best used as a guardrail for internet-facing services (for example SSH, HTTP/S, admin panels) where one source should not open an excessive number of concurrent new sessions.

Requirements and scope

• Netfilter xt_connlimit module must be available and functional.
• Applies to TCP only.
• Counts new SYN traffic (new connection attempts), not every historical session.

Validate support before enabling:

perl /etc/csf/csftest.pl

Syntax

CONNLIMIT is a comma-separated list of:

port;limit

Example configurations

Web server (shared hosting)

CONNLIMIT = "22;5,80;50,443;50,2083;10,2087;10"

• SSH: max 5 concurrent new connections per IP
• HTTP/HTTPS: max 50 (accommodates browsers opening many parallel connections)
• cPanel ports: max 10

Mail server

CONNLIMIT = "22;5,25;20,110;15,143;15,993;15,995;15"

• SMTP: max 20 (some legitimate senders open multiple connections)
• POP3/IMAP: max 15 each

Database server (restricted access)

CONNLIMIT = "22;3,3306;10"

• SSH: max 3 (very restricted)
• MySQL: max 10 per source IP

Interaction with CT_LIMIT

CONNLIMIT and CT_LIMIT (Connection Tracking) are complementary but different:

Feature	CONNLIMIT	CT_LIMIT
Scope	Per-port, per-IP	Total connections per IP across all ports
Mechanism	iptables xt_connlimit match	LFD-managed conntrack counting
Action	Silently drops excess SYN packets	Temporary IP block via LFD
Logging	No explicit log (kernel-level drop)	LFD logs the block event
Granularity	Port-level control	Server-wide threshold

Recommendation: use CONNLIMIT for per-service protection and CT_LIMIT as a global safety net. If both are configured, CONNLIMIT fires first (at the iptables level) before CT_LIMIT (at the LFD daemon level).

Tuning workflow

1. Start permissive — set limits higher than your expected peak per-IP concurrency:

CONNLIMIT = "22;10,80;100,443;100"

2. Monitor baseline traffic to understand normal connection patterns:

# Count concurrent connections per source IP on port 80
ss -tn state established '( dport = :80 )' | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20

3. Tighten gradually — reduce limits based on observed baselines, leaving headroom for legitimate bursts.

4. Watch for false positives — check logs and user reports after each adjustment:

# CONNLIMIT drops are silent in lfd.log but visible in kernel logs:
dmesg | grep -i connlimit

5. Account for NAT/proxy sources — if users arrive through a shared proxy or NAT gateway, their connections appear from one IP. Set higher limits for ports likely affected.

Validation commands

Confirm CONNLIMIT rules are active

iptables -S | grep connlimit

Check current connection counts per IP

# Concurrent connections to port 443 by source IP
ss -tn state established '( dport = :443 )' | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -10

Monitor LFD for related activity

tail -n 100 /var/log/lfd.log

Common pitfalls

• Using it as a rate limiter: this is a concurrency control, not request-per-second limiting. For rate limiting, see PORTFLOOD.
• Applying to UDP services: unsupported — CONNLIMIT works with TCP only.
• Over-tight values: can block legitimate traffic bursts (especially web and mail workloads behind NAT/CDN).
• Skipping capability checks: always verify module support with csftest.pl first.
• Confusing with CT_LIMIT: CONNLIMIT silently drops at the iptables level; CT_LIMIT triggers an LFD temp block with logging.

See also

• Port Flood Protection — rate-based (per-second) protection
• Performance and Scale Tuning — tuning connection-related settings at scale
• Troubleshooting Decision Trees — diagnosing false-positive blocks

Last reviewed: 2026-02-27

---

← Previous: Port Knocking · Next: Port/IP address Redirection