How would you implement a rate-limit rule for SSH to protect against brute-force attempts?

How would you implement a rate-limit rule for SSH to protect against brute-force attempts?

• A. /ip firewall filter add chain=input protocol=tcp port=22 connection-limit=3,32 action=drop
• B. /ip firewall filter add chain=input protocol=tcp port=22 action=drop
• C. /ip firewall filter add chain=input protocol=tcp port=22 connection-limit=10,60 action=accept
• D. /ip firewall filter add chain=input protocol=tcp port=80 connection-limit=3,32 action=drop

Answer: (A)

Rate-limiting SSH by source IP helps curb brute-force attempts by capping how many concurrent connections one source can make to the SSH port. The rule matches SSH traffic (TCP, port 22) on input and applies a per-source connection limit of 3 with a burst allowance of 32, dropping any additional connections beyond that threshold. This means legitimate users who typically have a single or a few SSH sessions aren’t blocked, while an attacker trying many rapid login attempts from one IP will see extra attempts rejected, slowing or stopping the brute-force flood. The other options don’t fit: dropping SSH unconditionally would block legitimate access; allowing beyond a limit (action=accept) doesn’t actually enforce a cap and won’t stop excess attempts; and applying a rate-limit to port 80 targets HTTP, not SSH.

Rate-limiting SSH by source IP helps curb brute-force attempts by capping how many concurrent connections one source can make to the SSH port. The rule matches SSH traffic (TCP, port 22) on input and applies a per-source connection limit of 3 with a burst allowance of 32, dropping any additional connections beyond that threshold. This means legitimate users who typically have a single or a few SSH sessions aren’t blocked, while an attacker trying many rapid login attempts from one IP will see extra attempts rejected, slowing or stopping the brute-force flood.

The other options don’t fit: dropping SSH unconditionally would block legitimate access; allowing beyond a limit (action=accept) doesn’t actually enforce a cap and won’t stop excess attempts; and applying a rate-limit to port 80 targets HTTP, not SSH.