IP-Verbindungen — InfraGuard-Handbuch

Überblick — was der Bildschirm leistet

IP-Verbindungen ist der zweite Bildschirm von Infrastruktur ▸ Konnektivität und Traffic (die host view). Während Port-Verbindungen sich um „Port → Server“ dreht, dreht sich dieser Bildschirm um „Server (Host) → entfernte Gegenstellen-IP“. Jede Serverkarte listet die IPs auf, die aktuell mit diesem Server verbunden sind, sortiert nach Verbindungsstärke, und zeigt für jede IP einen Sitzungsstärkepunkt je überwachtem Port. Ziel ist es, auf einen Blick zu erkennen, welche IP welchen Server auf welchem Port trifft — und wie stark.

Ein Klick auf eine Gegenstellen-IP öffnet das gemeinsam genutzte IP-Untersuchungs-Pop-up, in dem Sie die Verbindungsaufschlüsselung dieser IP (welcher Server / Port / TCP-Zustand / wie viele Sitzungen), eine Sparkline der aggregierten Verbindungshistorie, die Geo-/ASN-/ISP-Anreicherung, einen externen Reputationslink und einen Sperr-Deeplink in die Sperrliste untersuchen können — alles an einem Ort.

Routen: /infra/traffic/ips (Seite) · /infra/traffic/ips/live (Polling-JSON) · /infra/traffic/ip-detail (Untersuchungs-JSON)
Controller: App\Http\Controllers\Infra\TrafficController@ips
Builder: App\Services\Traffic\SessionQueryService::ipsData() + ipDetail()
Quellabfragen: App\Repositories\TrafficRepository (Alt-Verbindung legacy_glory, nur lesend)
Quelltabellen: traffic_session_ct (dazu die Rollups traffic_session_ct_5min/_1hour/_1day und die Anreicherung ip_info_loop)

Sämtliche Daten werden nur lesend aus der alten Traffic-Datenbank (legacy_glory) gelesen. Dieser Bildschirm schreibt niemals etwas — schreibende Aktionen wie das Sperren werden per Deeplink aus dem Pop-up an den Bildschirm Sperrliste übergeben, wo der Schreibvorgang stattfindet.

Wann Sie ihn verwenden

Einen Server erkennen, der eine auffällig hohe Zahl entfernter Gegenstellen anzieht (Scans, Botnetze, Crawler-Fluten).
Muster lateraler Ausbreitung aufspüren, bei denen eine einzelne IP mehrere Server oder Ports gleichzeitig trifft.
Eine über einen IDS- oder Firewall-Alarm aufgetauchte IP aus der Traffic-Perspektive zurückverfolgen (welcher Server, welcher Port und welcher Zustand tatsächlich Sitzungen hatten).
Verbindungsvolumen, Historie, Geolokalisierung und Reputation einer IP prüfen, bevor Sie über eine Sperre entscheiden.
Eine Quell-IP näher untersuchen, die aus dem SRC-Kreis von Port-Verbindungen kommt.

Aufbau

Kopfbereich · Timer

Oben rechts befinden sich der Timer-Umschalter (1 Min. / 5 Min. / 1 Stunde), der das Anzeigefenster festlegt, der Zeitstempel des letzten Snapshots und eine Schaltfläche zum manuellen Aktualisieren. Der Timer ist die Länge des Abfragefensters, verankert am letzten Snapshot.

Timer	Abfragefenster
`1` (Standard)	Nur die eine Minute des letzten Snapshots
`5`	Letzte 5 Minuten ab dem letzten Snapshot
`60`	Letzte 60 Minuten ab dem letzten Snapshot

Der gewählte Timer wird über Besuche hinweg in localStorage['infr:timer:traffic-ips'] gespeichert. Zulässig sind nur 1/5/60; alles andere wird auf 1 zurückgesetzt.

Stärkelegende + Server-Chips

Stärkelegende: Die Punktfarbe kodiert den Bereich der Sitzungszahl je Port — 1–9 (good) · 10–49 (warn) · 50+ (crit).
Server-Chips: ein Filter dafür, welche Server (Hosts) angezeigt werden. Standardmäßig sind alle ausgewählt, und der Chip-Filter gilt nur für die Sitzung (er wird nicht im localStorage abgelegt) — ein neuer Besuch kehrt also zur vollständigen Auswahl zurück. Der Chip [All] schaltet zwischen „alles auswählen“ und „Auswahl leeren“ um.

Server-(Host-)Karten

Eine Karte je ausgewähltem Server. Die Kopfzeile zeigt den Hostnamen und die Anzahl der Gegenstellen, der Rumpf ist eine Tabelle.

Zeile (Gegenstelle) = eine entfernte IP. Spalten: Remote IP · Total (Sitzungen insgesamt) · danach ein Stärkepunkt je überwachtem Port (die ersten 8 überwachten Ports).
Die Gegenstellen sind nach der Gesamtzahl der Verbindungen (Sitzungen) absteigend sortiert, und je Server werden bis zu 100 Gegenstellen angezeigt.
Die Stärkepunkte kodieren farblich, wie viele Sitzungen diese Gegenstelle auf dem jeweiligen Port hält (siehe Tabelle).
Ein Klick auf eine Zeile öffnet das Untersuchungs-Pop-up für diese IP.

Die Karten lassen sich am Griff per Drag-and-drop umsortieren (die Reihenfolge wird in infr:order:traffic-ips gespeichert), werden per Row-Span-Masonry neu umbrochen und in Seiten zu je 20 dargestellt.

Farben des Port-Stärkepunkts

Sitzungen	Token	Farbe	Bedeutung
`0`	none	blass	Auf diesem Port nicht verbunden
`1–9`	good	grün	Geringe Stärke
`10–49`	warn	bernstein	Mittlere Stärke
`50+`	crit	rot	Hohe Stärke

IP-Untersuchungs-Pop-up

Gesteuert wird es vom gemeinsamen Mixin mixins/ip_detail.js und dem Partial infra/partials/ip-detail-modal.blade.php. Es hat zwei Modi.

sources-Modus — die Liste der Quell-IPs in einem Fenster (Server, Port). Erreichbar über den SRC-Kreis auf Port-Verbindungen.
investigate-Modus (der Standardeinstieg dieses Bildschirms) — eine Tiefenanalyse einer einzelnen IP. Erreichbar durch Klick auf eine Gegenstellenzeile.

Was der investigate-Modus zeigt:

Bereich	Inhalt	Quelle
Zusammenfassungs-KPI	Sitzungen insgesamt · Anzahl Server · Anzahl Ports · erstmals/zuletzt gesehen	`ipSeenSpan()` (MIN/MAX(created_at) über die gesamte Aufbewahrung)
Geo	Land · Stadt · ASN · ISP	`ip_info_loop` (`ipEnrichment()`)
Verbindungshistorie	Sparkline je Granularität (5min / 1hour / 1day)	Rollup-Tabellen (`ipHistory()`)
Verbindungsaufschlüsselung	Sitzungen je Server × Port × TCP-Zustand · entfernte Ports · erstmals/zuletzt	`traffic_session_ct` (`ipBreakdown()`)

Aktionen in der Fußzeile des Pop-ups (investigate): IP kopieren · IP anzeigen (erneute Untersuchung auf dieser Seite über ?src_ip=) · Reputation ↗ (externes AbuseIPDB, neuer Tab) · IP sperren (Deeplink zur Sperrliste über ?add=).

Die Schaltfläche Reputation ↗ im Pop-up ist ein schlichter Link, der das externe abuseipdb.com/check/… in einem neuen Tab öffnet. Das In-App-Reputations-Pop-up, das eine Vertrauensanzeige und die Meldungshistorie innerhalb der Konsole darstellt, ist eine Funktion der Sicherheitsbildschirme — siehe IP-Reputation.

Anwendung

Grundlegender Ablauf

Legen Sie das Fenster (1/5/60 Min.) mit dem Timer fest. Je kürzer, desto näher an „gerade jetzt verbunden“.
Schränken Sie mit den Server-Chips auf die Server ein, die Sie interessieren (standardmäßig alle).
Suchen Sie auf einer Serverkarte nach Gegenstellen mit einem roten Stärkepunkt (50 Sitzungen oder mehr) oder nach Gegenstellen, die sich über mehrere Ports erstrecken.
Klicken Sie auf die Zeile der verdächtigen Gegenstelle, um das Untersuchungs-Pop-up zu öffnen.
Nutzen Sie im Pop-up die Verbindungsaufschlüsselung, um zu sehen, welchen Server/Port/Zustand die IP getroffen hat, die Historie, um die Beharrlichkeit einzuschätzen (einmalig oder wiederkehrend), und Geo/ASN für die Herkunft.
Prüfen Sie bei Bedarf die externe Meldungshistorie über Reputation ↗ und übergeben Sie die IP, falls sie bösartig ist, mit IP sperren an die Sperrliste.

Historien-Granularität wechseln

Ein Wechsel der Granularität im Historienbereich des Pop-ups wechselt die verwendete Rollup-Tabelle. Die Standardgranularität ist stündlich (1hour) — das beste Verhältnis aus Dichte und Geschwindigkeit.

5min    → traffic_session_ct_5min   · einzelne IP · Fenster von −6h ab dem letzten Snapshot
1hour   → traffic_session_ct_1hour  · einzelne IP · Fenster von −3d ab dem letzten Snapshot   (Standard)
1day    → traffic_session_ct_1day   · /24-Block   · Fenster von −120d ab dem letzten Snapshot

Die Tageshistorie (1day) wird nach dem /24-Block der IP (die ersten 3 Oktette, 256 IPs) aggregiert, nicht nach der einzelnen IP — weil der Rollup-Collector _1day nach C-Klasse ablegt. Das Pop-up zeigt daher eine CIDR-Bereichsbezeichnung wie 211.224.128.0/24 an, um den Bereich ausdrücklich zu benennen. 5min und 1hour verwenden die einzelne IP unverändert.

Deeplinks

?src_ip=203.0.113.10 — öffnet beim Laden der Seite automatisch das Untersuchungs-Pop-up für diese IP (genutzt, wenn Sie von einem anderen Bildschirm oder aus einem Alarm kommen).
?alias=… / ?servers=… / ?server=… — wendet den Server-Chip-Filter vorab an (durch Komma oder Leerzeichen getrennt, Abgleich ohne Beachtung der Groß-/Kleinschreibung). Gilt nur für diesen Besuch und wird nicht gespeichert.

/infra/traffic/ips?src_ip=203.0.113.10
/infra/traffic/ips?servers=glory,blue

Polling

Die Seite fragt /infra/traffic/ips/live alle 30 Sekunden zur automatischen Aktualisierung ab (kein Reverb — der Collector schreibt außerhalb von Laravel in die Datenbank, daher ist Polling die sinnvolle Wahl). Waren beim Aktualisieren alle ausgewählt, werden neu auftauchende Server automatisch einbezogen und verschwundene aus der Auswahl entfernt.

Datenquellen

Verankerung des Fensters

Das Anzeigefenster ist am letzten Snapshot der Daten (MAX(snapshot_ts)) verankert, nicht am now() der Anwendung. Die Speicheruhr des Collectors kann bis zu rund 9 Stunden hinter der Anwendungsuhr zurückliegen, sodass ein auf now() gestütztes Fenster außerhalb der Daten läge und leer bliebe.

Abfrage der Host-Sicht (`ipPeers`)

-- TrafficRepository::ipPeers (parametergebunden)
SELECT server_name, remote_ip, local_port, SUM(session_count) AS total_sessions
  FROM traffic_session_ct
 WHERE snapshot_ts BETWEEN :min AND :max
   AND local_port IN (:ports)          -- OpsPolicy::monitoredPorts()
 GROUP BY server_name, remote_ip, local_port;

Die monitored ports sind nicht fest verdrahtet — sie stammen aus infra_monitored_ports (CSV) in der Betriebsrichtlinie. Das Ergebnis von ipsData() wird 20 Sekunden lang zwischengespeichert (Schlüssel infr:traffic:ips:v1:{timer}:{ports}).

Abfragen des Untersuchungs-Pop-ups

Methode	Tabelle	Aufgabe
`ipSeenSpan()`	`traffic_session_ct`	`MIN/MAX(created_at)` = tatsächliche Beobachtungsspanne (Aufbewahrung etwa 8 h), `MAX(snapshot_ts)` = der jüngste Batch dieser IP selbst (Anker der Aufschlüsselung)
`ipBreakdown()`	`traffic_session_ct`	Sitzungssummen je Server×Port×Zustand · entfernte Ports · erstmals/zuletzt (LIMIT 200)
`ipHistory()`	3 Rollups	Sitzungshistorie je Granularität (LIMIT 400)
`ipEnrichment()`	`ip_info_loop`	Land · Stadt · ASN · ISP (liefert bei Fehlen fehlertolerant null)

Die Verbindungsaufschlüsselung ist am jüngsten Snapshot-Batch der IP selbst verankert, nicht am global letzten Fenster. Das ist Absicht: So zeigt auch eine IP, die gerade nicht verbunden ist, uns aber in der Vergangenheit getroffen hat, weiterhin ihre Verteilung — rekonstruiert aus ihrem zuletzt beobachteten Zeitpunkt.

Vorbehalt zu den Rollup-Indizes (performancekritisch)

ipHistory() gibt stets direction IN ('inbound','outbound') an.

-- _1day nutzt den zusammengesetzten Index t_ip(direction, remote_ip).
-- Ohne explizite direction wird nur der created_at-Bereich gescannt → mehr als 12 s.
-- Mit ihr greift der Index → etwa 20 ms (gemessen am 2026-08-06).
SELECT created_at, SUM(session_count) AS sessions
  FROM traffic_session_ct_1day
 WHERE direction IN ('inbound','outbound')
   AND remote_ip = :cclass_key           -- die Tagesebene nutzt den /24-Schlüssel aus den ersten 3 Oktetten
   AND created_at >= :since
 GROUP BY created_at
 ORDER BY created_at
 LIMIT 400;

Die Rollups sind riesig (_5min ≈ 209M · _1hour ≈ 112M · _1day ≈ 24M), daher sind ein enges created_at >=-Fenster plus LIMIT zwingend. Die Ergebnisse des Pop-ups sind durch Caches geschützt: investigate 25 s, sources 20 s.

Zugriff

Dieser Bildschirm gehört zum Rollenbereich Infrastruktur (mindestens user_level 1) — er ist nur lesend, sodass jeder angemeldete Benutzer (demo=1) ihn ansehen kann.
Die Seite, /live und /ip-detail liegen allesamt unter infr.auth (Anmeldung), ohne zusätzliche Stufenprüfung.
Hier wird nichts geschrieben. Die Aktion IP sperren im Pop-up ist ein Deeplink zum Bildschirm Sperrliste; die eigentliche Sperre (ein Schreibvorgang in blacklist_info) wird dort mit user_level ≥ 2 und einem Auditprotokoll ausgeführt.

Fehlerbehebung und FAQ

Die Karten sind leer und es erscheint nur „keine Gegenstellen in diesem Fenster“. Das bedeutet, dass der letzte Snapshot keine Verbindungen auf den überwachten Ports enthält. (1) Weiten Sie den Timer auf 5 oder 60 aus, (2) vergewissern Sie sich, dass die tatsächlichen Dienstports in infra_monitored_ports der Betriebsrichtlinie eingetragen sind, und (3) prüfen Sie, ob aktuelle Snapshots in traffic_session_ct landen (Collector check_ct.js).

Alles ist leer und es gibt keinen Snapshot-Zeitstempel. Wahrscheinlich ist die Verbindung legacy_glory gestört oder traffic_session_ct selbst leer. Prüfen Sie die Zugangsdaten der Datenbank legacy_glory in .env und ob der Traffic-Collector läuft. Schlägt die Abfrage fehl, trägt die Antwort error:true.

Nur die Tageshistorie zeigt „keine Tages-Rollup-Historie für diesen /24-Block“. Die Tagesaggregation kann einen Tag hinterherhinken und wird nach dem /24-Block indiziert. Prüfen Sie zuerst die Granularitäten 5min und stündlich. Existiert für den Block noch kein Rollup, ist das erwartungsgemäß.

Ich habe auf eine IP geklickt, aber die Verbindungsaufschlüsselung ist leer. Diese IP hat im jüngsten Snapshot keine Sitzungen, wohl aber frühere Beobachtungen. Nutzen Sie „erstmals/zuletzt gesehen“ im Zusammenfassungs-KPI und die Verbindungshistorie, um die frühere Aktivität zu bestätigen (die Aufschlüsselung wird aus dem letzten Snapshot-Batch der IP rekonstruiert).

Das „Reputation ↗“ im Pop-up öffnet einen neuen Tab, statt die Daten eingebettet anzuzeigen. Das ist so vorgesehen. Dieses Traffic-Pop-up verwendet einen externen AbuseIPDB-Link. Um Vertrauensanzeige und Meldungshistorie innerhalb der Konsole zu sehen, nutzen Sie das In-App-Reputations-Pop-up der Sicherheitsbildschirme.

Wodurch werden die Farben der Stärkepunkte bestimmt? Durch den Bereich der Sitzungszahl je Port — 1–9 grün · 10–49 bernstein · 50+ rot · 0 ergibt einen blassen Punkt. Als Spalten werden nur die ersten 8 überwachten Ports angezeigt.