Whitelist (Sperrausnahme)

Überblick — was diese Seite leistet

Die Seite Whitelist verwaltet IPs und Bereiche, die von der automatischen Sperr-Pipeline von InfraGuard ausgenommen werden sollen. Alles, was hier eingetragen ist, bildet die „Ausnahmeliste“, welche die Erkennungs-Collectors unmittelbar vor dem Sperren heranziehen — damit vertrauenswürdige Quellen (CDNs, Partner-APIs, Büroleitungen) nicht wegen eines Fehlalarms gesperrt werden.

Der zentrale Begriff ist der Ablauf:

• expires_at ist NULL → dauerhafte Ausnahme (läuft nie ab). Für stets vertrauenswürdige Quellen wie CDNs und Büroleitungen.
• expires_at ist ein Datum → befristete Ausnahme (verfällt nach diesem Zeitpunkt automatisch). Für kurze Untersuchungsfenster oder automatische Unbedenklichkeitsurteile.

Ausnahmen stammen aus drei Quellen:

Die Tabelle infr_whitelist liegt auf der Verbindung legacy_glory (derselben Datenbank wie blacklist_info und die suricata_*-Tabellen), nicht auf der Anwendungsdatenbank. Dadurch kann der Node-Collector srct_tx diese Tabelle unmittelbar vor dem Sperren direkt lesen und harmlose IPs direkt hineinschreiben.

Wann verwenden

• Fehlalarme verhindern: Tragen Sie vorab normalen Verkehr ein (Überwachungs-Bots, Partner-Crawler, Zahlungs-Rückrufe), der die Scan- oder Raten-Heuristiken auslösen könnte.
• Befristete Ausnahme während einer Untersuchung: Geben Sie einem Bereich ein Ablaufdatum, um ihn für einige Tage auszunehmen.
• CDN/Büro immer vertrauen: Nehmen Sie die Frontend-IPs von Cloudflare/Google/AWS/Akamai oder eine feste Büro-IP dauerhaft aus.
• Automatische Urteile prüfen: Sehen Sie sich die von srct_tx erzeugten auto-Einträge an, verlängern oder löschen Sie sie.
• Heben Sie in der Sperrliste eine versehentlich gesperrte IP auf und verhindern Sie, dass sie erneut gesperrt wird (indem Sie eine Ausnahme eintragen).

Aufbau

Kennzahlen oben (5)

Berechnet von WhitelistService::summary() mit 30 Sekunden Cache. Aktiv = is_active = 1 UND (expires_at IS NULL ODER expires_at > now).

Liste der Ausnahmen

Eine filterbare Tabelle (25 Zeilen pro Seite). Sortiert wird dauerhaft zuerst (expires_at IS NULL DESC) → Ablauf aufsteigend → id absteigend.

Filter: Status (aktiv · abgelaufen · alle), Quelle (manuell · automatisch · Standard · alle) und Suche (IP · CIDR · Name). Die Liste ruft alle 30 Sekunden Aktualisierungen ab.

Dialog zum manuellen Hinzufügen

Die Schaltfläche [Add manually] (Manuell hinzufügen) öffnet einen Dialog. Eingaben: IP oder CIDR, Name (optional) und Ablaufdatum/-zeit (optional; leer = dauerhaft).

Verwendung

1. Eine manuelle Ausnahme hinzufügen

1. Klicken Sie auf [Add manually] (Manuell hinzufügen).
2. Geben Sie eine IP oder ein CIDR ein. Eine einzelne IP wird auf /32 normalisiert, ein Bereich auf seine Netzadresse (siehe die Normalisierungsregeln weiter unten).
3. Geben Sie optional einen Namen und ein Ablaufdatum mit Uhrzeit an. Lassen Sie den Ablauf leer, um eine dauerhafte Ausnahme zu erhalten.
4. Klicken Sie auf [Add] (Hinzufügen). Existiert derselbe cidr bereits, wird er reaktiviert (is_active=1), und Ablauf sowie Name werden aktualisiert.

2. Normalisierungsregeln (normalizeCidr)

WhitelistService::normalizeCidr() schreibt die Eingabe in eine kanonische Form um (sprachunabhängig und identisch mit der Vergleichskonvention von srct_tx).

203.0.113.10        → 203.0.113.10/32     (eine einzelne IP wird zu /32)
203.0.113.0/24      → 203.0.113.0/24      (unverändert)
203.0.113.55/24     → 203.0.113.0/24      (Host-Bits maskiert → Netzadresse)
10.0.0.5/8          → 10.0.0.0/8
999.1.1.1           → (ungültig → null, 422 invalid_ip)

• Nur IPv4. Präfixlänge 0–32.
• Vor dem Speichern prüft der Controller vorab mit dem regulären Ausdruck ^\d{1,3}\.\d{1,3}\.\d{1,3}(\.\d{1,3})?(/\d{1,2})?$, und der Service schließt mit filter_var(... FILTER_FLAG_IPV4) + ip2long ab.

Beim Hinzufügen eines /24-Bereichs dürfen die Host-Bits stehen bleiben — 203.0.113.55/24 wird automatisch als 203.0.113.0/24 (seine Netzadresse) gespeichert.

3. Ablauf eingeben

• Leer → dauerhaft (expires_at = NULL).
• YYYY-MM-DD oder YYYY-MM-DD HH:MM → wird mit Carbon::parse ausgewertet.
• Auch ein Auswertungsfehler führt zu dauerhaft (parseExpiry → null).

4. Entfernen

Die Entfernen-Aktion in einer Listenzeile ruft nach einer Bestätigung remove auf. Die Zeile wird hart gelöscht (nicht weich). Selbst ein CDN-Eintrag mit Quelle seed lässt sich entfernen, kann aber beim nächsten Seeder-Lauf neu angelegt werden.

5. Automatische Unbedenklichkeit von srct_tx (Quelle auto) — wie sie gefüllt wird

Der Collector srct_tx prüft die Unbedenklichkeit unmittelbar vor dem Sperren einer IP mit Scan- oder Ratenauffälligkeit nach einem sehr strengen Verfahren und hinterlässt hier nur dann einen auto-Eintrag, wenn das Urteil eindeutig ist.

1. Whitelist-Filter — ist die IP bereits in infr_whitelist (samt der im Code hinterlegten CDN-Liste) vorhanden, wird sie sofort ausgenommen und übersprungen.
2. Reputationsabfrage nur für Kandidaten mit „nur E“ — nur IPs, die das fehlalarmanfällige Signal „kurzer Scan allein“ (Heuristik E) tragen und keines der harten Signale (A/A2/B/C/D), werden gegen AbuseIPDB geprüft (Schlüssel im Rundlauf · 6 h Cache · Obergrenze je Durchlauf).
3. Urteil vollständiger Unbedenklichkeit — gilt abuse_score=0 UND reports=0 UND kein Tor (oder in der Whitelist mit Punktzahl 0), so wird automatisch eine 30-Tage-Ausnahme (ip/32) in infr_whitelist(source=auto) eingetragen und die Sperre übersprungen.

Die automatische Unbedenklichkeit gibt es nur bei srct_tx. kts_tx (Kitsune ML) liest und filtert die Whitelist lediglich — es führt weder Reputationsabfragen noch automatische Einträge durch.

6. cidrList() — für die Codeerzeugung wiederverwendet

WhitelistService::cidrList() liefert die entdoppelten aktiven, nicht abgelaufenen CIDRs (30 Sekunden Cache). Diese Liste wird als Quelle für die Konstante CDN_WHITELIST_CIDRS eingespeist, wenn die Seite Regeln und Schwellenwerte die Skripte srct_tx/kts_tx erzeugt — so fließen die in der Oberfläche verwalteten Ausnahmen in den tatsächlichen Collector-Code ein.

Datenquellen

Tabelle infr_whitelist (Verbindung: legacy_glory, Migration 000734)

Indizes: (is_active, expires_at), source.

infr_whitelist wird auf der Datenbank legacy_glory (GLORY) angelegt. Ist legacy_glory nicht als mysql/mariadb konfiguriert, sind Migration und Seeder so abgesichert, dass sie nichts tun — die Seite wird gerendert, aber die Kennzahlen lesen 0. In echten Installationen muss die GLORY-Verbindung eingetragen sein.

Seeder InfrWhitelistSeeder (source=seed, dauerhaft)

Übernimmt die zuvor fest kodierten CDN-/OFFICE-Bereiche (idempotent über firstOrCreate). Enthält Frontend-Bereiche von Cloudflare, Google, Meta, AWS und Akamai sowie eine feste OFFICE-IP.

php artisan db:seed --class=InfrWhitelistSeeder

Modell · Service

• Modell: App\Models\Infr\InfrWhitelist (protected $connection = 'legacy_glory').
• Service: App\Services\Security\WhitelistService — summary() (Kennzahlen, 30 s Cache), page() (Filtern/Blättern), add()/remove() (Schreibzugriffe), cidrList() (Quelle für die Codeerzeugung) und normalizeCidr() (statische SOT).
• Controller: App\Http\Controllers\Security\WhitelistController — index · live · add · remove.

Zugriff

Stufenschema: demo=1 · staff=5 · admin=10. Staff und Admin können also sowohl lesen als auch schreiben; ein fehlgeschlagener Schreibzugriff liefert 403 forbidden (Hinweis „Nicht erlaubt (Stufe 2 oder höher)“).

Jeder Schreibzugriff wird in InfrAuditLog festgehalten:

• Hinzufügen → sec.whitelist_add (target=ip, meta enthält id · reactivated).
• Entfernen → sec.whitelist_remove (target=ip, meta enthält id).

Die vollständige Stufen- und Rollenrichtlinie finden Sie unter Zugriffsstufen, das Nachvollziehen von Schreibzugriffen unter Audit-Protokoll.

Fehlerbehebung und FAQ

Alle Kennzahlen stehen auf 0 und die Liste ist leer

Die Verbindung legacy_glory ist nicht konfiguriert, oder die Tabelle infr_whitelist existiert noch nicht. Prüfen Sie die Einstellungen der GLORY-Datenbank und führen Sie Migration und Seeder aus. Bei Datenbankfehlern liefert der Service ohne Absturz leere Werte.

„Keine gültige IP / CIDR“ (422)

Die Eingabe ist kein IPv4, oder die Präfixlänge liegt außerhalb von 0–32. IPv6 wird nicht unterstützt. Beispiele: 203.0.113.10, 203.0.113.0/24.

Ich habe ein /24 eingegeben, aber der gespeicherte Bereich weicht ab

Das ist so vorgesehen. Die Host-Bits werden auf die Netzadresse maskiert (203.0.113.55/24 → 203.0.113.0/24).

Entsteht ein Duplikat, wenn ich dieselbe IP erneut hinzufüge?

Nein. cidr ist eindeutig, daher wird der vorhandene Eintrag reaktiviert und sein Ablauf sowie sein Name werden aktualisiert (Antwort reactivated: true). War der vorhandene Eintrag seed, bleibt die Quelle seed.

Warum erscheinen auto-Einträge / kann ich sie entfernen?

srct_tx hat eine als eindeutig harmlos beurteilte IP automatisch als 30-Tage-Ausnahme eingetragen. Sie können sie entfernen; wird diese IP jedoch erneut fälschlich markiert, kann sie erneut eingetragen werden.

Verschwinden abgelaufene Einträge von selbst?

Die Zeile bleibt bestehen, fällt aber aus den Zählungen für „aktiv“ heraus, sobald ihr Ablauf überschritten ist. Stellen Sie den Statusfilter auf abgelaufen/alle, um sie zu sehen. Vollständig beseitigen Sie sie mit Entfernen.

Ich habe eine IP ausgenommen, sie wird aber weiterhin gesperrt

Prüfen Sie: (1) ob der normalisierte Bereich die IP des Verkehrs tatsächlich abdeckt (z. B. /32 gegenüber /24), (2) den Cache von cidrList() (30 s) und ob das Collector-Skript neu erzeugt wurde, (3) ob in blacklist_info bereits ein Sperreintrag besteht. Bestehende Sperren müssen über die Sperrliste aufgehoben werden.

Verwandte Themen

• Sperrliste und Reputation — Verwaltung der Sperrliste (das Gegenteil der Ausnahme)
• Auto-Block — automatisches Sperren durch den Scheduler (Veto durch Whitelist/Unbedenklichkeit)
• Bedrohungen — IDS-Bedrohungstriage, IP-Detailansicht
• Regeln und Schwellenwerte — Konstanten von srct_tx/kts_tx + Einspeisung von cidrList
• IP-Reputation — AbuseIPDB-Abfrage in der Anwendung
• Audit-Protokoll — Prüfung der Schreibvorgänge