Sperrliste und Reputation — InfraGuard-Handbuch

Überblick — was der Bildschirm leistet

Sperrliste und Reputation (/security/blocklist) erzählt die Geschichte der Bedrohungsbereiche, die Kitsune ML und Suricata IDS automatisch gesperrt haben, und gibt Betreibern eine Steuerkonsole, um Bereiche von Hand zu sperren (hinzufügen) · aufzuheben · erneut zu sperren.

Die Quelltabelle ist blacklist_info auf der Verbindung legacy_glory (rund 8.000–9.000 Zeilen). Die Sperreinheit ist keine einzelne IP, sondern ein /24-Bereich (c_class, z. B. 203.0.113.0/24).
In diese Tabelle schreiben die Erkennungs-Collectors (kts_tx.js · srct_tx.js) sowie diese Betreiberoberfläche; der Dienst sync_black (sync_black.mjs) liest sie und setzt die Sperren als ipset/iptables-DROP-Regeln auf jedem Host durch. Hinzufügen und Aufheben sind hier also die Steuerungsebene — das tatsächliche Verwerfen der Pakete übernimmt sync_black.
Das Quell-Tag im Feld reason ([Kitsune ...] · [Suricata Auto-Block] · [Manual] ...) und die Belegzahlen (score · port · ja3 · hits …) werden zu einer lesbaren Bezeichnung dafür geparst, „warum der Bereich aufgefallen ist“ (das Parsen ist sprachunabhängig).

Eine „Sperre“ umfasst immer einen kompletten /24-Bereich. Auch wenn Sie eine einzelne IP eingeben, bleiben nur die ersten drei Oktette erhalten und der Eintrag wird auf x.y.z.0/24 normalisiert. Falschmeldungen werden über die Whitelist ausgenommen, nicht durch eine engere Sperre.

Wann Sie ihn nutzen

Um auf einen Blick zu sehen, was die automatische Verteidigung gerade sperrt und in welchem Umfang (Anzahl aktiver Sperren · Beitrag je Engine · Herkunftsländer).
Um eine in Bedrohungen, Erkennungen oder einem IP-Untersuchungsfenster entdeckte bösartige IP manuell zu sperren (per ?add= verlinkt und vorbefüllt).
Um einen versehentlich gesperrten Bereich aufzuheben oder einen aufgehobenen Bereich, der wieder aktiv wurde, erneut zu sperren.
Um die repräsentative IP eines gesperrten Bereichs mit der AbuseIPDB-Reputation abzugleichen.

Aufbau

Kennzahlen im Kopfbereich

Berechnet von summary() mit einem 30-Sekunden-Cache (infr:sec:blocklist:summary).

Kennzahl	Bedeutung	Berechnung
Aktive Sperren	Derzeit durchgesetzte /24-Bereiche	`COUNT(*) WHERE is_use=1`
Geschützte Adressen (Untertitel)	Von aktiven Sperren abgedeckte Adressen	`active × 256` (/24 ≈ 256)
Heute gesperrt	Neue Sperren in den letzten 24 Std.	`is_use=1 AND created_at >= today 00:00`
Quote der automatischen Verteidigung	Anteil, den KI/IDS automatisch erledigt haben	`(kitsune + suricata) / active × 100`
Beobachtete Länder	Verschiedene Länder unter den aktiven Bereichen	`COUNT(DISTINCT country) WHERE is_use=1`
Aufgehoben	Derzeit aufgehoben (wartet auf erneute Sperre)	`COUNT(*) WHERE is_use=0`

Beitrag der Verteidigungs-Engines

Die aktiven Sperren werden nach Quell-Tag in einen Anteilsbalken und Kacheln aufgeschlüsselt. Die Zuordnung erfolgt über LIKE-Abgleich auf reason.

Engine	Abgleichsregel	Bedeutung
Kitsune ML	`reason LIKE '%Kitsune%'`	Anomalieerkennung mit Ensemble-Autoencoder
Suricata IDS	`reason LIKE '%Suricata%'`	Automatische Sperre bei Scan oder Protokollverstoß
Manuell	`reason LIKE '%Manual%'` oder `%수동%`	Vom Betreiber festgelegte Sperre
Sonstiges	Alles, was oben nicht zutrifft	`active − (kitsune+suricata+manual)`, mindestens 0

Herkunft der Bedrohungen

blockByCountry(12) verdichtet die aktiven Bereiche zu den Top-12-Ländern (GROUP BY country ORDER BY COUNT DESC) und zeigt sie als Flaggen-Emoji mit Rangbalken. Ein Klick auf einen Balken filtert die Liste auf dieses Land.

Feed der jüngsten Verteidigungsaktivität

blockFeed(16) zeigt die 16 neuesten Zeilen unabhängig vom Status (ORDER BY created_at DESC, id DESC) in einem 4×4-Raster — ein Live-Eindruck davon, was gerade aufgefallen ist.

Filterbare Sperrliste

40 Karten pro Seite (PER_PAGE=40, ORDER BY created_at DESC, id DESC). Jede Karte zeigt Bereich · Land · Quellabzeichen · Beleg-Chip (Verhalten + Schlüsselzahl) · Sperrzeitpunkt · Status, dazu die Zeilenaktionen [Reputation] · [Details] · [Aufheben]/[Erneut sperren]. Gehört ein Bereich zu einem registrierten internen Netz, erhält er ein Internal-Abzeichen und seine Reputationsschaltfläche wird ausgeblendet (internal_scope.js).

Filter:

Status — active (Vorgabe) · released · all
Quelle — kitsune · suricata · manual (leer = alle)
Land — exakte Übereinstimmung (höchstens 64 Zeichen)
Suche (q) — nur CIDR-Präfix (regulärer Ausdruck ^[0-9.]{0,20}$, z. B. 211. → c_class LIKE '211.%')

Verwendung

Die Begründung lesen

Der Beleg-Chip jeder Karte wählt aus der Zeichenkette reason genau den Regelsatz mit dem höchsten Gewicht und zeigt ihn als Bezeichnung samt repräsentativer Zahl. Unter den srct-Heuristikkategorien wird die oberste nach dieser Gewichtsreihenfolge bestimmt:

Kategoriemarker	Gewicht	behavior-Schlüssel	Bezeichnung	Repräsentative Zahl (Detail)
`[A2:...]`	6	brute	Brute Force gegen die Administration	`hits=N` → `N hits`
`[A:...]`	5	scanner	Scan verwundbarer Pfade	`hits=N` → `N hits`
`[D:...]`	4	ja3	JA3-Fingerabdruck eines Botnetzes	`ja3=N` → `ja3×N`
`[B:...]`	3	bot_ua	Zugriff durch schädlichen Bot	`hits=N` → `N hits`
`[C:...]`	2	err_flood	4xx-Fehlerflut	`err_rate=NN%`
`[E:...]`	1	short_scan	TCP-Portscan	`port=N` oder `N scan`

Ist die Quelle Kitsune oder enthält reason ein score=, wird der Eintrag noch vor jeder Kategorie als ml_anomaly (Anomalie des maschinellen Lernens) eingestuft und zeigt top= (die Komponente mit dem größten Fehler) sowie score. Manuelles und Sonstiges fallen auf manual / auto zurück.

Weitere aus reason gewonnene Fakten: score=, top=, port=, short_scan_sessions=, bytes=. Beispiele für Begründungen:

[Kitsune v2.2] anomaly top=TLS score=0.83
[Suricata Auto-Block] [A:URL] hits=42 port=443
[Manual] repeated login abuse (uid=5)

Eine manuelle Sperre hinzufügen

[Manuelle Sperre] in der Listenkopfzeile öffnet das Dialogfenster zum Anlegen. (Kommen Sie aus Bedrohungen oder einer IP-Untersuchung, ist die IP aus ?add=203.0.113.10 vorbefüllt.)
Geben Sie eine IP oder ein CIDR ein. Eine einzelne IP wird auf /24 erweitert (203.0.113.10 → 203.0.113.0/24).
Geben Sie optional einen Grund ein (höchstens 160 Zeichen) und klicken Sie auf [Sperren].
Verhalten des Servers:
- Die Eingabe wird über cclassCidr() auf x.y.z.0/24 normalisiert (alles, was kein IPv4 ist, wird als invalid_cidr abgelehnt).
- Bei einer vollständigen IPv4 wird das Land aus ip_info_loop angereichert (sonst bleibt der vorhandene Wert / Unknown).
- Existiert (server_index=0, c_class) bereits, wird der Eintrag auf is_use=1 aktualisiert (reaktiviert); andernfalls wird eine neue Zeile eingefügt. Der Grund lautet "[Manual] <note> (uid=N)".
- Der Zusammenfassungs-Cache wird geleert und die aktualisierte Liste samt Zusammenfassung zurückgegeben.

Die Sperre erreicht blacklist_info sofort, das tatsächliche Firewall-DROP wird aber erst wirksam, wenn der Dienst sync_black auf dem jeweiligen Host sie das nächste Mal nach ipset/iptables synchronisiert. Läuft dieser Stapellauf nicht, wird die Sperre an der Firewall nicht durchgesetzt.

Aufheben / Erneut sperren

[Aufheben] setzt is_use=0, sodass sync_black den Eintrag aus ipset entfernt (die Zeile bleibt bestehen). Die Aktion läuft nach einem Bestätigungsdialog.
[Erneut sperren] setzt einen aufgehobenen Bereich wieder auf is_use=1.
Beide liefern not_found, wenn die Zielzeile nicht existiert.

Abfrageintervall

security-blocklist.js ruft /security/blocklist/live alle 30 Sekunden auf, um Zusammenfassung und aktuelle Seite zu aktualisieren.

Datenquellen

Position	Quelle	Hinweise
Sperrregister	`blacklist_info` (legacy_glory)	`id, server_index, c_class, country, reason, is_use, created_at, updated_at` · UNIQUE(server_index, c_class)
Länderanreicherung	`ip_info_loop` (legacy_glory)	Länderabfrage für vollständige IPv4 beim Hinzufügen
Prüfung auf internes Netz	`SecurityScope::internalMatchers()`	IPs registrierter Instanzen + Whitelist der Betriebsrichtlinie → `Internal`-Abzeichen
Durchsetzung an der Firewall	Dienst `sync_black`	`blacklist_info` → ipset/iptables-DROP
Zufuhr automatischer Sperren	`kts_tx.js` · `srct_tx.js`	schreiben die Quell-Tags und Belegzeichenketten in reason
Audit-Protokoll	`infr_audit_log`	`sec.block_add` · `sec.block_release` · `sec.block_readd`

Das Rückgrat des Lesens ist App\Repositories\SecurityRepository; Erzählung und Schreibvorgänge orchestriert App\Services\Security\BlocklistService. Zugangsdaten stammen ausschließlich aus config('database.connections.legacy_glory') — niemals fest im Code.

Zugriff

Die Seite ansehen — Sie müssen zum Rollenbereich Sicherheit gehören (sitemap min_req=2). Auf der ausgerollten Levelskala sehen staff (5) und admin (10) die Sicherheitsbildschirme; demo (1) liegt außerhalb des Sicherheitsbereichs.
Schreibvorgänge (hinzufügen/aufheben/erneut sperren) — der Server erzwingt infr_user_level >= 2 (canWrite). Darunter kommt 403 forbidden zurück. demo (1) kann also nicht schreiben; staff und admin können es.
Jeder Schreibvorgang wird in InfrAuditLog festgehalten und ist im Audit-Protokoll nachvollziehbar (Akteur, Ziel-CIDR, Reaktivierungsflag usw. im meta).

Da es sich um destruktive Sicherheitsaktionen handelt, zeigt die Oberfläche vor der Ausführung einen Bestätigungsdialog (Step-up). Prüfen Sie das CIDR doppelt, damit Sie nicht versehentlich einen großen Bereich sperren.

Fehlersuche und FAQ

Ich habe gesperrt, doch die Angriffe gehen weiter. Dieser Bildschirm aktualisiert nur das Register. Prüfen Sie, ob sync_black auf dem Zielhost läuft und ipset tatsächlich aktualisiert wurde. Außerdem gelten Sperren je /24 — Angriffe aus anderen Bereichen brauchen eigene Sperren.
[Manuelle Sperre] liefert 403. Ihr Anmeldelevel liegt unter 2. Versuchen Sie es erneut mit einem staff- oder admin-Konto (siehe RBAC-Level).
Die Eingabe wird als „keine gültige IP/CIDR“ abgelehnt. Akzeptiert werden nur a.b.c / a.b.c.d / a.b.c.d/nn. IPv6 und Hostnamen werden nicht unterstützt.
Das Land zeigt Unknown. Für diese IP gibt es keine Anreicherung aus ip_info_loop, oder Sie haben nur ein CIDR eingegeben. Das Hinzufügen einer vollständigen IPv4 kann das Land ergänzen.
Kennzahlen oder Liste ändern sich nicht. Die Zusammenfassung wird 30 Sekunden zwischengespeichert. Nach einem Schreibvorgang wird sie sofort geleert, aber von Collectors ausgelöste Änderungen können bis zu 30 Sekunden nachlaufen.
Ich habe versehentlich einen legitimen Bereich gesperrt. Heben Sie die Sperre sofort auf, und falls die Falschmeldung beim erneuten Sperren wiederkehrt, nehmen Sie den Bereich in die Whitelist auf, damit srct_tx ihn unmittelbar vor dem Sperren ausnimmt.