Auto-Block-Pipeline

Überblick — was diese Funktion leistet

Auto-Block ist die Hintergrund-Pipeline von InfraGuard, die angreifende IPs ohne menschliches Zutun erkennt, prüft und sperrt. Es handelt sich nicht um eine Seite, sondern um einen Ablauf über Collectors, den Scheduler und das Kernel-ipset hinweg. Dieser Artikel dokumentiert diese Gesamtstruktur.

Die Pipeline besitzt zwei voneinander unabhängige Sperrwege, die an einem einzigen Durchsetzungspunkt (ipset) zusammenlaufen.

Beide Wege führen unmittelbar vor dem Sperren eine Whitelist- und eine Unschuldsprüfung durch. Nur bestätigter Missbrauch übersteht sie; Kandidaten, die wahrscheinlich Fehlalarme sind, werden entlastet. Weg ② (Scheduler) ist standardmäßig deaktiviert und muss von einem Administrator aktiviert werden.

Wann verwenden

• Schalten Sie die automatische Abwehr ein, wenn Botnetze, Scanner und Brute-Force-Sondierungen fortwährend eintreffen und manuelles Sperren nicht mehr Schritt hält.
• Wenn Erkennungen ▸ JA3 Botnetze zeigt, die ihren Fingerabdruck rotieren, passen Sie den Schwellenwert so an, dass sie automatisch erfasst werden.
• Wenn eine Quelle in Bedrohungen wiederholt einen IDS-Alarm einer bestimmten Schwere (rot/orange) auslöst und Sie sie automatisch sperren möchten.
• Wenn Sie die in Sperrliste und Reputation auflaufenden Sperrgründe prüfen und übermäßige Sperren über die Whitelist entlasten.

Aufbau

Auto-Block hat keine eigene Seite. Seine Steuer- und Beobachtungspunkte sind:

• Konfiguration — Betriebsrichtlinie ▸ Reiter Sicherheitseinstellungen ▸ Karte Auto-Block (Hauptschalter, Modus, Umfang, Auslöser, Unschuld).
• Beobachtung der Ergebnisse — Sperrliste und Reputation (/24-Sperren des Collectors + /32-Sperren des Schedulers, Gründe, Freigabe).
• Entlastung — Whitelist (manuelle bzw. automatisch entlastete IPs und CIDRs, mit Ablauf).
• Auslöserquellen — Bedrohungen (IDS-Schwere), Erkennungen (JA3-Rotation).

Verwendung

1. Weg ② Auto-Block des Schedulers — aktivieren und abstimmen

Die Voreinstellung ist AUS (autoblock_on=0). Legen Sie den Hauptschalter unter Betriebsrichtlinie ▸ Sicherheitseinstellungen um und passen Sie anschließend die Richtlinie an.

Modus

Umfang

Auslöser (ODER — für einen Kandidaten genügt einer)

① IDS-Regelsatzschwere   suricata_alert_ct
   WHERE alert_ts >= NOW() - INTERVAL {window_min} MINUTE
     AND severity <= {sev_max}          -- crit=1, warn=2 (Suricata: 1=kritisch … 3=niedrig)
   GROUP BY src_ip HAVING COUNT(*) >= {sev_count}

② Botnetz mit JA3-Rotation   suricata_tls_ct
   WHERE event_ts >= NOW() - INTERVAL {ja3_window_min} MINUTE
     AND ja3_hash IS NOT NULL
   GROUP BY src_ip HAVING COUNT(DISTINCT ja3_hash) >= {ja3_rotation}

Die Zeitstempelspalte des Schwere-Auslösers ist alert_ts, während der JA3-Auslöser event_ts verwendet (sie unterscheiden sich je Tabelle). Behalten Sie beim Abstimmen der Schwellenwerte im Blick, auf welche Spalte das jeweilige Zeitfenster filtert.

Richtlinien-Standardwerte (OpsPolicy::autoBlock())

Abstimmung der JA3-Rotation (gemessen): Reale JA3-Rotationstäter erreichen typischerweise einen Höchstwert von etwa 32 verschiedenen JA3 je /32-Sitzung (Rechenzentrums- bzw. Cloud-Bots, ohne GREASE = stabil und sperrbar). Deshalb erfasst der Standardwert ja3_rotation=50 überhaupt nichts. Damit er tatsächlich auslöst, senken Sie ihn auf etwa 15–20. Führen Sie zuerst --dry aus, um die Anzahl der Kandidaten zu sehen.

2. Prüfreihenfolge für Kandidaten (AutoBlockService::run)

Jede erfasste Kandidaten-IP muss diese Hürden der Reihe nach überwinden, bevor sie tatsächlich gesperrt wird.

1. Ausschluss interner bzw. eigener Netze — übersprungen, wenn SecurityScope::isInternal($ip) zutrifft (skipped_internal). Diese Entscheidung vereinigt die IPs registrierter Instanzen (/24-Präfix + exakte IP) mit der Whitelist internal_networks aus der Betriebsrichtlinie. Bereits in der Abfragestufe wird excludePrefixes() per NOT LIKE vorab ausgeschlossen.
2. Entlastung durch die Whitelist — übersprungen, wenn infr_whitelist einen aktiven, nicht abgelaufenen /32- oder /24-Eintrag enthält (skipped_wl).
3. Unschuldsveto — gilt ausschließlich für reine JA3-Kandidaten ohne hartes Signal (Schwere-Auslöser). Innerhalb des Budgets reputation_cap wird die AbuseIPDB-Reputation abgefragt; ist die IP makellos (Missbrauchswert 0 UND Meldungen 0 UND kein Tor), wird sie für innocent_days automatisch auf die Whitelist gesetzt (infr_whitelist(source=auto)), statt gesperrt zu werden (innocent). Schwere-Kandidaten überspringen diese Hürde und werden unmittelbar gesperrt.
4. Auflösung des server_index — global→[0], per_server→Auflösung der Ziel-dest_ip über ServerIndexResolver::byIp (Rückfall [0]).
5. Schreiben — Upsert in infr_block über InfrBlock::updateOrCreate([server_index, cidr], …) mit source='schedule', is_active=true, reason='[InfraGuard Auto] …'.

Kandidaten erfassen (ODER) → interne ausschließen → Whitelist → (nur JA3) Unschuldsveto → server_index → infr_block schreiben

isSpotless() liefert false (also: vorsichtshalber sperren), wenn die Reputationsabfrage fehlschlägt, nicht konfiguriert ist oder unaufgelöst bleibt. Die Entlastung durch Unschuld ist eine konservative Hürde, die nur greift, wenn eine IP eindeutig sauber ist.

3. Scheduler und Befehl

infr:auto-block ist ein einmalig ausgeführter Befehl, der einmal auswertet und sich dann beendet — kein Daemon. Der Scheduler taktet jede Minute, das wirksame Intervall ist jedoch autoblock_interval_min.

# Die Sperre prüfen (sofort wirkungslos, wenn die Richtlinie AUS ist), dann einmal auswerten und schreiben
php artisan infr:auto-block

# Nur Kandidaten zählen, ohne Schreibvorgänge (zum Abstimmen/Prüfen)
php artisan infr:auto-block --dry

# Einen Lauf erzwingen und dabei die Richtlinienprüfung (ein + Intervall) umgehen
php artisan infr:auto-block --force

# Ausgabe unterdrücken, wenn nichts gesperrt wurde (für die Planung)
php artisan infr:auto-block --quiet-if-ok

Registrierung im Zeitplan (routes/console.php):

Schedule::command('infr:auto-block --quiet-if-ok')
    ->everyMinute()
    ->withoutOverlapping(2)
    ->onOneServer()
    ->when($is_leader);   // Leader-Gating — nur ein Knoten in der gesamten Flotte

Logik der Prüfung:

• autoblock_on=0 → der Befehl meldet sofort „übersprungen“ (standardmäßig AUS, sicher).
• Seit dem letzten Lauf ist das Intervall noch nicht verstrichen → überspringen.
• --force und --dry umgehen die Prüfung.

Beispielausgabe:

infr:auto-block — Kandidaten 12 (sev 3 · ja3 9) · gesperrt 7 · wl-skip 1 · internal-skip 2 · innocent 2

4. Weg ① Auto-Block des Collectors (Node)

Die Node-Collectors auf jedem Host verarbeiten Suricata-Ereignisse und sperren direkt mit /24-Granularität in blacklist_info. Dieser Weg ist vom Scheduler (Weg ②) unabhängig und läuft immer.

Die fünf Bedrohungskategorien von srct_tx:

(A) [HTTP] URL-Scanner          .env / .git / wp-login und weitere URLs mit Scanner-Signatur
(B) [HTTP] Bot-User-Agent       curl / python-requests / sqlmap und weitere Werkzeugsignaturen
(C) [HTTP] Brute-Force-Sondierung  viele 4xx-Antworten in kurzem Fenster (Pfad-Brute-Force)
(D) [TLS]  JA3-Anomalie         viele JA3, fehlender SNI und weitere Botnetz-Fingerabdrücke
(E) [FLOW] TCP-Flag-Anomalie    viele kurze Scan-Sitzungen (Portscan)

Auch srct_tx führt unmittelbar vor dem Sperren eine Whitelist-Filterung + eine automatische Entlastung durch: Nur E-only-Kandidaten (kurzer Scan allein) erhalten eine AbuseIPDB-Reputationsabfrage, und sind sie eindeutig sauber (0 Meldungen · Missbrauchswert 0 · kein Tor), werden sie als 30-tägige Ausnahme eingetragen (infr_whitelist(source=auto)) und die Sperre entfällt. Liegt irgendein hartes Signal (A/A2/B/C/D) vor, wird unmittelbar gesperrt. Seine Konstanten und Schwellenwerte werden unter Regeln und Schwellenwerte verwaltet.

5. Weg ③ Durchsetzung — sync_black → ipset

infr_sync_black.mjs läuft periodisch auf jedem Host und synchronisiert beide Listen in das Kernel-ipset blacklist.

# Je Host mit dessen server_index ausführen (erfordert root)
node infr_sync_black.mjs sv=4

# crontab (alle 5 Min., flock verhindert Überschneidungen)
*/5 * * * * /usr/bin/flock -n /var/run/sync_black.lock \
  /usr/bin/node /root/server_monitor/infr_sync_black.mjs sv=4 \
  >> /var/log/sync_black.log 2>&1

Verhalten:

1. Aus blacklist_info (/24) + infr_block (/32) laden, wobei server_index IN (0, <sv>) AND is_active/is_use=1 gilt.
2. Balanced-Deduplizierung — jede /32 überspringen, deren übergeordnete /24 sie bereits abdeckt.
3. Das Kernel-ipset auf hash:net zwingen (bei abweichendem Typ neu anlegen), in ein temporäres Set laden und dann atomar tauschen (ohne Ausfallzeit).
4. Sicherstellen, dass iptables -I INPUT -m set --match-set blacklist src -j DROP vorhanden ist (idempotent).
5. Sicherheitsnetz — private (RFC1918), Loopback- und eigene Netzpräfixe (HOME_NET_PREFIX) werden niemals in das ipset geladen, selbst wenn sie in die Datenbank gelangen.

sync_black benötigt root sowie die Kernel-Werkzeuge ipset/iptables, und das ipset blacklist muss auf dem Zielhost bereits vorhanden sein:

ipset create blacklist hash:net family inet hashsize 8192 maxelem 65536
iptables -I INPUT -m set --match-set blacklist src -j DROP

Datenquellen

Alle Quell- und Protokolltabellen liegen auf der Verbindung legacy_glory (der von Collectors und Durchsetzungsskripten gemeinsam genutzten Datenbank).

Schema von infr_block (Zusammenfassung)

Zugriff

Auto-Block besitzt keine Benutzeroberfläche zur Ausführung. Die einschlägigen Berechtigungsprüfungen sind (Stufen: demo=1 · staff=5 · admin=10):

Die vom Scheduler verwendeten Zugangsdaten sind niemals fest im Code hinterlegt — sie sind nach infr_collector / .env ausgelagert. Ebenso werden die Datenbank-Zugangsdaten von sync_black und die Präfixe des eigenen Netzes über Umgebungsvariablen oder die Mashup-Ersetzung unter Inventar ▸ Werkzeuge eingespeist (keine feste Hinterlegung).

Fehlerbehebung und FAQ

Ich habe es eingeschaltet, aber es wird nichts gesperrt.

• Prüfen Sie die Anzahl der Kandidaten mit --dry: php artisan infr:auto-block --dry.
• Der JA3-Schwellenwert ist vermutlich zu hoch (Standard 50). Reale Täter liegen bei etwa 32; senken Sie ihn daher auf 15–20.
• Schwere-Auslöser: autoblock_severity=crit erfasst nur sev≤1 (rot). Um Orange einzuschließen, setzen Sie warn (sev≤2).
• Sind alle Kandidaten internal-skip/wl-skip, prüfen Sie die interne Whitelist der Betriebsrichtlinie oder die Whitelist.

Die Sperren erreichen die tatsächliche Firewall nicht.

• Ein Eintrag in infr_block wird erst durchgesetzt, wenn sync_black läuft. Prüfen Sie den Cron des Zielhosts, das Argument sv=<server_index> und ob das ipset blacklist existiert.
• Im Umfang balanced wird eine /32, die bereits von einer übergeordneten /24 abgedeckt ist, absichtlich dedupliziert und nicht separat geladen (das ist normal).

Eine unbeteiligte IP wurde gesperrt.

• Tragen Sie sie als /32 oder /24 in die Whitelist ein; ab dem nächsten Durchlauf ist sie ausgenommen (geben Sie die vorhandene infr_block-Zeile über die Sperrliste frei).
• Die automatische Entlastung gilt ausschließlich für reine JA3-Kandidaten. IPs, die der Schwere-Auslöser erfasst hat, werden unabhängig von ihrer Reputation gesperrt und benötigen daher eine manuelle Ausnahme.

Der Modus ist per_server, doch die Einträge landen global (server_index=0).

• Lässt sich die Ziel-dest_ip nicht über infr_server_index auflösen, greift sicherheitshalber der Rückfall auf [0]. Überprüfen Sie die IP-Zuordnung von Collectors und Instanzen.

Der Scheduler läuft auf mehreren Servern gleichzeitig.

• Das Leader-Gating ->onOneServer()->when($is_leader) stellt sicher, dass nur ein Knoten ihn ausführt. Prüfen Sie den Zustand des Leader-Locks im Observability-Dashboard.

Verwandte Themen

• Betriebsrichtlinie — Hauptschalter, Auslöser und Umfang des Auto-Blocks (Reiter Sicherheitseinstellungen)
• Sperrliste und Reputation — Ergebnisliste des Auto-Blocks, Gründe, Freigabe
• Whitelist — ausgenommene IPs/CIDRs, automatische Ausnahme durch Unschuld
• Erkennungen ▸ JA3 — Quelle des JA3-Rotationsauslösers
• Bedrohungen — Quelle des IDS-Schwere-Auslösers
• IP-Reputation (AbuseIPDB) — Reputationsabfrage für das Unschuldsveto