IP-blocked recovery

Your IP got blocked by the BOA firewall layer. The block is time-limited: the web-abuse layer issues 15-minute temp bans (csf -td <ip> 900 -p 80 / -p 443 from guest-fire.sh) and the IDS/SSH-scanner layer bans for 900 s on port 22 (FTP equivalently on 21). Repeated offence escalates to a persistent csf.deny entry. Many cases self-resolve inside the window. The procedures below cover detection, removal from another path, console-only recovery, and the proactive allowlist — plus the two ban-pipeline subtleties that change how removal actually propagates.

Is your IP blocked?

From a different network (phone hotspot, another host):

ssh root@server.example.com
# "Connection refused" / no response = blocked; a password prompt = not blocked

From the blocked IP itself, both of these time out at the firewall if blocked:

ssh root@server.example.com
curl -I https://server.example.com/

You still have access from another path

You hold several paths (home, work, VPN); one is blocked. Use another to clear it:

# As root on the BOA host
csf -dr 192.0.2.42        # remove from deny list (192.0.2.42 = the blocked IP)
csf -a  192.0.2.42        # allow to prevent re-block

Persistent allow (survives reboot):

echo "192.0.2.42 # operator home IP" >> /etc/csf/csf.allow
csf -r

Web-abuse bans are mirrored into Nginx

csf -dr clears the CSF-layer ban, but web-abuse bans are also mirrored into an Nginx deny set, so removal there can lag. nginx_deny.sh maintains /data/conf/nginx_banned_ips.conf from two CSF sources — csf.tempban rows on ports 80/443 (the 15-min web temp bans) and csf.deny lines commented Brute force Web Server — and the per-site vhosts key a $is_banned geo map off it, returning 444 as a first guard. SSH/FTP bans are not mirrored (those aren't proxied, so the CSF network-layer ban already bites). Consequence: clearing a web-abuse block needs the CSF removal to propagate into the Nginx set on the next nginx_deny.sh regen — the set self-expires once CSF drops the matching tempban/deny row. The full lifecycle is in Ban pipeline.

An IPv6 web-abuse block is not in CSF at all (CSF is IPv4-only): it lives in the nginx-native store /var/xdrago/monitor/log/web6.tempban and the geo file /data/conf/nginx_banned_ips.conf6, maintained by nginx_deny6.sh. It self-expires on its own TTL; to clear one immediately, remove the IP's line from web6.tempban and run nginx_deny6.sh (or run clearwebbans, which releases both families).

You only have a provider web console / KVM

If SSH is gone but the provider panel gives console access:

  1. Log in via console.
  2. As root: 
    csf -tf                                # flush all temp blocks
csf -a $(curl -s ifconfig.me)          # allow current public IP
  3. Reconnect via SSH from the now-allowed IP.

Locked out completely

  1. Wait it out. Temp blocks expire after ~15 minutes. If you cycled through block→retry many times you may be escalated to a csf.deny entry — see (2).
  2. Provider VNC/KVM console. Reaches the host terminal directly (bypasses the network firewall); then csf -tf + csf -a <your-ip>.
  3. Rebuild from snapshot. Last resort if no console and no reachability.

Proactive allowlisting

# /etc/csf/csf.allow — one IP per line, comments after #
echo "192.0.2.42   # home"     >> /etc/csf/csf.allow
echo "198.51.100.7 # office"   >> /etc/csf/csf.allow
echo "203.0.113.0/24 # vpn"    >> /etc/csf/csf.allow
csf -r

The allowlist permits packet flow but does not exempt from LFD login-failure tracking: bad-password attempts from a whitelisted IP still get blocked. It allows the initial packets — it is not a get-out-of-jail card.

What triggered it

Trigger Layer
Repeated SSH bad-password attempts LFD
Port scanning from your IP SYNPROXY / IDS
Many 404s in a short window, admin-URL crawling Nginx Abuse Guard
High request volume read as DoS loadguard
An automated tool (CI runner, monitor) firing too fast mixed

Inspect:

grep '192.0.2.42' /var/log/csf.log
grep '192.0.2.42' /var/log/lfd.log
grep '192.0.2.42' /var/log/auth.log
grep '192.0.2.42' /var/log/nginx/access.log | wc -l

The IDS never bans an IP with a recent successful login

The SSH IDS (hackcheck.sh) skips any IP that has an Accepted line in the recent auth.log baseline window — even if other scanner patterns matched from that same IP (since 5.9.3) — and never bans an IP listed in csf.allow or csf.ignore (since 5.9.5). This is the hackcheck/IDS layer only: it does not override CSF's own LFD login-failure tracking, so repeated bad-password attempts can still be blocked by LFD. A genuine successful login marks your IP trusted for the IDS pass — which is what makes the "keep a session open" tip concrete.

Keep a control session open during risky work

If you keep an active SSH session open, CSF treats the IP as currently in good standing and is less aggressive about new connections from it. Not a formal exemption — a practical window. When deploying or running mass tasks, keep a control session in another window.

Related