If you run internet-facing web applications like osTicket and WordPress, automated credential-stuffing bots will eventually find your login endpoints. To stop bursts of "Excessive login attempts" alerts hitting a login portal (/scp/login.php), investigate the server logs, confirm zero breaches occurred, and implement a multi-layered defense using UFW and CrowdSec.
Here is the full incident breakdown and the exact steps to implement this automated security setup on an Ubuntu Linux server.
1. Immediate Mitigation via Linux Firewall
When dealing with an active brute-force flood from a persistent IP address, the fastest remediation is to drop all incoming packets at the firewall before the web server expends resources processing the requests:
sudo ufw insert 1 deny from 66.232.121.113 to any
sudo ufw reloadWhy insert 1 matters: Firewalls evaluate rules sequentially from top to bottom and exit on the first match. Using insert 1 places the rule at the very top of the rule chain, ensuring the traffic is dropped before any broader allow 80/tcp or allow 443/tcp web rules can accept it.
2. Post-Incident Forensics: Confirming Zero Breach
Before moving forward, verify whether the attacking IP has compromised the system by inspecting the Apache access logs and system authentication logs:
sudo grep -rn '66.232.121.113' /var/log/apache2/
sudo grep '66.232.121.113' /var/log/auth.logThe logs can confirm the following:
- Repeated Login Loops: Every single request from the IP was exclusively cycling between
GET /scp/login.phpandPOST /scp/login.php. - No Dashboard Traversal: If an authentication attempt had succeeded, osTicket would have issued a redirect to an internal page (such as
/scp/index.phpor/scp/tickets.php) followed by static resource requests. No internal endpoints were ever requested. - No Shell Access:
/var/log/auth.logshowed zero inbound SSH connections, confirming no external access to the underlying OS.
3. Long-Term Automated Defense with CrowdSec
Manually blocking individual IP addresses does not scale. To automate threat mitigation across osTicket, WordPress, and SSH, we installed CrowdSec along with its iptables firewall remediation bouncer.
Step A: Install CrowdSec & the Firewall Bouncer
Add the official repository and install the engine and bouncer:
# 1. Add repository and install security engine
curl -s https://install.crowdsec.net | sudo sh
sudo apt update
sudo apt install -y crowdsec
# 2. Install the iptables/firewall remediation component
sudo apt install -y crowdsec-firewall-bouncer-iptablesStep B: Enable WordPress Threat Scenarios
To guard against WordPress user enumeration, credential attacks on wp-login.php, and wp-config.php probes, install the official collection:
sudo cscli collections install crowdsecurity/wordpress
sudo systemctl reload crowdsecStep C: Create a Custom osTicket Brute-Force Scenario
While CrowdSec includes generic HTTP protection rules, osTicket's login behavior is best served by a dedicated scenario that monitors repeated rapid POST requests targeting /login.php.
Create /etc/crowdsec/scenarios/osticket-bf.yaml:
sudo tee /etc/crowdsec/scenarios/osticket-bf.yaml > /dev/null << 'EOF'
type: leaky
name: local/osticket-bf
description: "Detect brute-force attempts on osTicket agent and client logins"
filter: "evt.Meta.log_type in ['apache2_access', 'http_access-log'] && evt.Parsed.request contains '/login.php' && evt.Parsed.verb == 'POST'"
groupby: "evt.Meta.source_ip"
capacity: 5
leakspeed: "10s"
blackhole: "5m"
labels:
service: http
type: bruteforce
remediation: true
EOFReload the agent and verify the new scenario is registered:
sudo systemctl reload crowdsec
sudo cscli scenarios list | grep osticket4. Operational Health & Management Commands
With this pipeline active, CrowdSec automatically monitors Apache access logs, parses incoming events, and instructs the firewall bouncer to drop malicious traffic dynamically. Useful operational commands include:
- Check Live Parser & Bouncer Metrics:
sudo cscli metrics - View Active Bans:
sudo cscli decisions list - View Triggered Alerts:
sudo cscli alerts list - Manually Ban an IP:
sudo cscli decisions add --ip <IP> --duration 720h --reason "brute force" - Remove a False Positive Ban:
sudo cscli decisions delete --ip <IP>