How-to

Install premium blocklists¶

This guide shows you how to install and manage premium blocklists after enrolling with the Community Console. Install one blocklist per 24 hours so you can attribute any false-positive wave to a specific source.

Important

CrowdSec v1.6.4 has no cscli blocklists subcommand — that family ships with CrowdSec v2. Premium blocklist management on the kup6s engine is done entirely through the CrowdSec web console at https://app.crowdsec.net. The local cscli is only used to inspect resulting decisions.

Prerequisites¶

The engine must be enrolled — see enroll-community-console.

List available blocklists¶

Browse all blocklists offered to your account in the web console:

Log in to app.crowdsec.net.
Select your engine (kup6s-lapi) in the sidebar.
Open the blocklists tab.

The view shows name, description, size in IPs, update frequency, and a per-list toggle.

Recommended starter set¶

Install these two on consecutive days.

Day 1: `firehol_proxies`¶

Known open proxy servers. Focused scope, low false-positive rate.

In the blocklists tab, toggle crowdsecurity/firehol_proxies on.

The local engine pulls the new configuration on the next sync (within a few minutes). Confirm decisions arrive:

kubectl exec -n crowdsec deploy/crowdsec-lapi -- cscli decisions list --origin lists --scenario crowdsecurity/firehol_proxies

Observe for one or two days. The Grafana dashboard “CrowdSec Overview” shows the decision count climbing.

Day 2 or 3: `firehol_voipbl`¶

SIP and VoIP brute-force sources. Relevant for mail-port brute-forcing (SMTP-AUTH) once a TCP-side bouncer is deployed. Currently the bouncer only enforces on HTTP — this blocklist primarily adds visibility.

In the blocklists tab, toggle crowdsecurity/firehol_voipbl on.

Confirm decisions arrive:

kubectl exec -n crowdsec deploy/crowdsec-lapi -- cscli decisions list --origin lists --scenario crowdsecurity/firehol_voipbl

Blocklists to avoid initially¶

Do not install these without per-app analysis:

crowdsecurity/firehol_anonymous — may block Tor exit nodes and VPN providers, which is a privacy anti-pattern for public-facing sites
Aggressive catch-all lists without a clear scope

These can be revisited in Phase 4 for specific endpoints (admin panels, login pages) where Tor/VPN access has no legitimate use.

Disable a blocklist after a false-positive wave¶

If a blocklist causes user complaints or 4xx spikes, toggle it off in the same web console blocklists tab.

The local engine drops the source on the next sync. The plugin stops applying new decisions from this blocklist within a few minutes. Existing decisions from this source remain in the cache until their TTL expires (typically 7 days).

To force-remove all decisions from a specific blocklist via cscli:

kubectl exec -n crowdsec deploy/crowdsec-lapi -- cscli decisions delete \
  --origin lists --scenario crowdsecurity/firehol_voipbl

Inspect a blocklist¶

The web console blocklists tab shows metadata, IP count, and a sample of entries per list. There is no local cscli equivalent in v1.6.4.

To inspect what the engine actually applies, list local decisions filtered by the blocklist scenario:

kubectl exec -n crowdsec deploy/crowdsec-lapi -- cscli decisions list \
  --origin lists --scenario crowdsecurity/firehol_proxies

Re-evaluate after seven days¶

After seven days running with the selected blocklists:

Lists with many hits and no complaints — keep.
Lists with few hits and no complaints — keep (no harm done).
Lists that triggered user complaints — disable and document.

Record the decision and any disabled blocklists in the memory file project_kup6s_waf_phase2_live.md.