IP-Reputationsabfrage (AbuseIPDB)

Überblick — was die Funktion leistet

Die IP-Reputationsabfrage ist eine gemeinsam genutzte Funktion: Klicken Sie irgendwo im Bereich Sicherheit auf eine verdächtige Quell-IP (src_ip), und der Server ruft stellvertretend für Sie die Bedrohungsdaten von AbuseIPDB ab, dargestellt in einem Pop-up innerhalb der Anwendung. Sie verlassen die Konsole nie — Sie beurteilen „wie einschlägig ist diese IP“ genau dort, wo Sie gerade triagieren.

Wesentliche Merkmale:

• Reine Abfrage (nur lesend). Diese Funktion ruft ausschließlich /api/v2/check von AbuseIPDB auf. Sie meldet oder veröffentlicht die IP nicht nach außen — die ausgehende Meldung (internationale Zusammenarbeit) ist eine eigene, zurückgestellte Reaktionsphase.
• Missbrauchs-Konfidenz-Anzeige von 0–100 sowie Anzahl der Meldungen, unterschiedliche Meldende, Verwendungsart, Provider, Land, Domain, Tor-/Whitelist-Kennzeichen und die jüngste Meldehistorie — alles normalisiert.
• Round-Robin über mehrere Schlüssel. Der in Reputations-API hinterlegte AbuseIPDB-Schlüsselpool wird der Reihe nach verbraucht; bei einem 429 (Kontingent erschöpft) oder einem 401/403 (Problem mit dem Schlüssel) wechselt der Dienst automatisch zum nächsten Schlüssel (Kontingent-Bündelung).
• 1-Stunden-Cache je IP. Um das Kontingent von 1000 Anfragen/Tag im kostenlosen Tarif zu schonen, liefern wiederholte Abfragen derselben IP innerhalb einer Stunde das zwischengespeicherte Ergebnis.
• Gemeinsames Mixin. Bedrohungen, Erkennungen, Sicherheitsübersicht und Sperrliste verwenden alle dieselbe Pop-up-Komponente wieder.

Die Live-Schaltfläche dieses Artikels öffnet den Bereich Sicherheit (/security). Die Reputationsabfrage ist keine eigenständige Seite — sie ist ein gemeinsames Pop-up, das erscheint, wenn Sie auf einem Sicherheitsbildschirm auf das Schild-Lupe-Symbol (.infr-ipsym) neben einer IP oder auf die Schaltfläche [Reputation prüfen] klicken.

Wann Sie sie einsetzen

• Beim Triagieren der schwerwiegendsten Angreifer-IPs in Bedrohungen — ist sie wirklich bösartig oder ein bekannter Scanner bzw. ein bekanntes Botnetz?
• Um zu begründen, ob eine JA3-Auffälligkeit oder eine Kitsune-Anomalie-IP in Erkennungen eine echte Bedrohung darstellt.
• Zum Gegenprüfen der externen Reputation eines Ziels, bevor Sie es in Sperrliste und Reputation sperren oder freigeben.
• Zum schnellen Sichten der IP-Reputation aus den Panels der Top-Bedrohungs-IPs bzw. der JA3-Auffälligkeiten in der Sicherheitsübersicht.

Aufbau

Das Pop-up (security/partials/abuse-modal.blade.php) wird je nach Abfrageergebnis in einem von drei Zuständen dargestellt.

Erfolg — Reputationskarte

Konfidenzwert → Bewertungston

Zustände „nicht konfiguriert“ / Fehlschlag

• Kein Schlüssel konfiguriert: Schlüssel-Warnsymbol + Hinweis. Nutzen Sie die Schaltfläche [AbuseIPDB öffnen] in der Fußzeile, um direkt auf der externen Seite nachzusehen.
• Abfrage fehlgeschlagen: Kontingent erschöpft, Netzwerkfehler usw. Versuchen Sie es in Kürze erneut oder weichen Sie auf den externen Link aus.

Aktionsschaltflächen in der Fußzeile

Vorgehen

1. Klicken Sie auf einem Sicherheitsbildschirm (Bedrohungen, Erkennungen, Übersicht, Sperrliste) auf das Schild-Lupe-Symbol oder die Schaltfläche [Reputation prüfen] neben einer IP.
2. Das Pop-up öffnet sich mit einem Ladeindikator, und das Frontend fordert die Abfrage beim Server an:

GET /security/ip-reputation?ip=203.0.113.10

3. Der Server validiert die IP streng (filter_var FILTER_VALIDATE_IP), fragt anschließend über AbuseIpdbService ab und liefert normalisiertes JSON zurück.
4. Sehen Sie sich Anzeige, Kennzahlen und aktuelle Meldungen an. Über die Schaltflächen in der Fußzeile kopieren, verfolgen oder sperren Sie nach Bedarf.

Antwortschema (normalisiert)

Bei Erfolg liefert der Server das JSON, das vom Pop-up verarbeitet wird:

{
  "ok": true,
  "configured": true,
  "ip": "203.0.113.10",
  "score": 84,
  "reports": 128,
  "distinct_users": 41,
  "country": "CN",
  "usage": "Data Center/Web Hosting/Transit",
  "isp": "Example Hosting Ltd",
  "domain": "example-host.net",
  "is_tor": false,
  "is_whitelisted": false,
  "last_reported": "2026-08-12T22:14:07+00:00",
  "recent": [
    { "at": "2026-08-12T22:14:07+00:00", "country": "US", "categories": [18, 22], "comment": "SSH brute-force" }
  ],
  "checked_at": "2026-08-13 09:31:20",
  "external_url": "https://www.abuseipdb.com/check/203.0.113.10"
}

Bei kontrolliertem Fehlschlag:

{ "ok": false, "configured": false, "external_url": "https://www.abuseipdb.com/check/203.0.113.10" }

Meldekategorien (1–23)

recent[].categories ist ein Array numerischer IDs. Das Pop-up stellt die Bezeichnungen über die Sprachtabelle security.abuse.cat dar.

Datenquellen

Diese Funktion legt keine neue Tabelle an. Sie kommt allein mit einem externen API-Aufruf + einer Schlüsselregistrierung + einem Cache aus.

Ablauf von Schlüsselrotation / Failover

check(ip)
  ├ cache hit? → return
  └ miss → iterate providers.rotated()
        key#1 → 200? → normalize·cache·return
              → 429/401/403 → fail over to next key (secret never printed)
        key#2 → …
        all fail → { ok:false, error:"http_429"|"unreachable" }

Registrieren Sie mehrere Schlüssel des kostenlosen Tarifs, dann bündeln sich deren Kontingente. Wenn ein Schlüssel sein Tageskontingent aufgebraucht hat und 429 zurückgibt, rückt der Dienst automatisch zum nächsten vor — Teams mit hoher Ermittlungslast sollten 2–3 Schlüssel in Reputations-API registrieren.

Zugriff

• Abfrage-Endpunkt GET /security/ip-reputation: Da es sich um eine reine Abfrage handelt, gibt es weder eine Step-up-Bestätigung noch einen Audit-Eintrag. Der Endpunkt liegt hinter dem Menübereich Sicherheit (min_req 2), sodass ihn faktisch das Sicherheitspersonal (staff=5) und höher erreicht. Er veröffentlicht nichts nach außen und ist damit keine destruktive Aktion.
• Ungültige IP: Schlägt die Prüfung durch filter_var fehl, kommt HTTP 422 {"ok":false,"message":"invalid_ip"} zurück.
• Schlüsselverwaltung Reputations-API: CRUD, Live-Test und das Ziehen der Priorität über infr_reputation_provider sind ausschließlich Administratoren vorbehalten (admin=10, level≥5) und werden auditiert. Schlüssel werden verschlüsselt gespeichert und können beim Bearbeiten nur ersetzt oder gelöscht werden.
• Kein Geheimnisabfluss: API-Schlüssel gelangen nie in Antworten oder Fehlerinhalte (Fehler werden nur als Zeichenkette http_STATUS festgehalten).

Fehlerbehebung und FAQ

Das Pop-up meldet „API-Schlüssel nicht konfiguriert“

In infr_reputation_provider ist kein Schlüssel registriert und .env ABUSEIPDB_KEY ist leer. Legen Sie in Reputations-API einen AbuseIPDB-Schlüssel an oder setzen Sie ABUSEIPDB_KEY=YOUR_KEY in der .env. Nutzen Sie bis dahin die Schaltfläche [AbuseIPDB öffnen], um auf der externen Seite nachzusehen.

„Abfrage fehlgeschlagen“ erscheint immer wieder

• 429 (Kontingent erschöpft): Möglicherweise haben Sie die 1000 Anfragen/Tag des kostenlosen Tarifs aufgebraucht. Registrieren Sie zusätzliche Schlüssel, um Kontingent zu bündeln, oder versuchen Sie es am nächsten Tag erneut.
• 401/403 (Problem mit dem Schlüssel): Der Schlüssel ist abgelaufen, vertippt oder inaktiv. Prüfen Sie ihn mit [Live-Test] in Reputations-API.
• Netzwerk (unreachable): Vergewissern Sie sich, dass ausgehende Verbindungen zu api.abuseipdb.com (443) vom Konsolen-Host aus nicht blockiert sind.

Eine gerade gesperrte IP zeigt weiterhin einen niedrigen Wert

Ergebnisse werden pro IP für 1 Stunde zwischengespeichert (infr:sec:abuse:{ip}). Wenn Sie einen frischen Wert benötigen, fragen Sie nach spätestens einer Stunde erneut ab. Der Cache existiert, um Ihr kostenloses Kontingent zu schonen.

Kann ich die IP von hier aus an AbuseIPDB melden?

Nein. Diese Funktion dient ausschließlich der Abfrage. Das Einreichen von Meldungen (internationale Zusammenarbeit) ist eine eigene, zurückgestellte Reaktionsphase — hier wird nichts nach außen veröffentlicht.

Ich sehe nur 6 aktuelle Meldungen

Der Normalisierungsschritt behält nur die 6 jüngsten (MAX_REPORTS=6). Die vollständige Historie sehen Sie über [AbuseIPDB öffnen] auf der externen Seite.

Es ist eine IP aus der Whitelist bzw. dem internen Netz, aber die Abfrageschaltfläche fehlt

Sicherheitsbildschirme kennzeichnen die IPs registrierter Instanzen (Ihr eigenes Netz) mit einem Internal-Badge und blenden die Reputationsschaltfläche aus (SecurityScope) — das verhindert Verwirrung, wenn die Richtungslabels von Suricata unseren eigenen Server als „Quelle“ ausweisen. Die Definitionen des internen Netzes werden in Betriebsrichtlinie verwaltet.

Verwandte Themen

• Verwaltung der Reputations-API — AbuseIPDB-Registrierung mehrerer Schlüssel, Round-Robin, Live-Test
• Bedrohungen — IP-Reputation während der Triage von IDS-Bedrohungsentitäten prüfen
• Erkennungen · JA3 — Reputation von JA3-Auffälligkeiten bzw. Anomalie-IPs verifizieren
• Sperrliste und Reputation — Sperrliste + Reputationsabgleich + Deep-Link zum Sperren
• Sicherheitsübersicht — Abwehr-Funnel und Top-Bedrohungs-IPs
• Whitelist — Sperrbefreiung und automatische Unschulds-Whitelist durch srct