Ungewöhnlichen Bandbreitenverbrauch bis zum Prozess verfolgen

Das Netzwerk wird langsam, und der erste Vorschlag lautet: mehr Bandbreite kaufen. Doch eine außerplanmäßige Sicherung, Cloud-Synchronisierung, interne Schleife oder wiederholte Übertragung kann die Ursache sein. Vor einer Erweiterung müssen wir klären, wo die Belastung beginnt, wohin sie fließt und welche Tätigkeit sie verursacht.

Dieser Beitrag führt vom Netzwerküberblick bis zu einem einzelnen Prozess. Vorgehen und Entscheidungskriterien sind redaktionelle Empfehlungen; Fähigkeiten und Grenzen der Werkzeuge wurden mit Primärdokumentation abgeglichen. Keines der Beispiele behauptet, auf dem tatsächlichen Netzwerk des Lesers getestet worden zu sein.

Zuerst festlegen, was ungewöhnlich bedeutet

Hoher Verkehr ist nicht automatisch ungewöhnlich. Eine erwartete Sicherungsspitze unterscheidet sich von dauerhaftem Senden in einer sonst ruhigen Zeit. Erfassen Sie Beginn, Dauer, Richtung, betroffenen Bereich und Auswirkungen auf Nutzer. Vergleichen Sie ähnliche Tage und Uhrzeiten, nicht nur die ruhigen Minuten unmittelbar vor dem Vorfall.

Unterscheiden Sie Übertragungsrate und Datenmenge. Mbps bezeichnet eine Rate, GB ein Volumen. In dezimalen Einheiten entsprechen 1 MB/s genau 8 Mbps. Die nutzbare Dienstkapazität kann unter der ausgehandelten Portgeschwindigkeit liegen. Vergleichen Sie bei Vollduplex jede Richtung mit ihrer eigenen Kapazität; die Summe aus Ein- und Ausgang beweist keine Sättigung einer bestimmten Richtung.

Für jede Frage das passende Werkzeug

1. Schnittstellen mit PRTG oder Zabbix überwachen

Beginnen Sie mit WAN, Standortverbindungen, Uplinks und den für den betroffenen Dienst relevanten Schnittstellen. Ein- und Ausgang beziehen sich auf die jeweilige Schnittstelle. In PRTG ist der SNMP-Traffic-Sensor ein Ausgangspunkt; in Zabbix verwenden Sie eine geeignete Gerätevorlage und prüfen die Ausgabeeinheit des Items.

Ein roher kumulativer Octet-Zähler muss über seine zeitliche Änderung in eine Rate umgerechnet werden. In Zabbix dienen dazu Change per second und die passende Einheitenumrechnung. Wenden Sie diese Umrechnung nicht erneut auf ein Item an, dessen Vorlage bereits bit/s liefert. Für einen Rohzähler gilt:

bit/s = (counter_now - counter_previous) * 8 / elapsed_seconds

Verwenden Sie unterstützte 64-bit-Zähler. Lange Abfrageintervalle können kurze Spitzen im Mittelwert verstecken; sehr kurze Intervalle verursachen ebenfalls Überwachungsaufwand. Wir empfehlen, beide Richtungen mit Fehlern, Verwerfungen und Paketrate aufzuzeichnen. Eine pauschale Schwelle ersetzt nicht die Ausgangsbasis der jeweiligen Verbindung.

PRTG / SNMP · Zabbix / SNMP · Zabbix / Preprocessing

2. Geräte und Ziele mit NetFlow finden

Eine Schnittstellengrafik zeigt den belasteten Ort, meist aber nicht den Verbraucher. Unterstützt das Gerät NetFlow oder IPFIX, exportieren Sie Daten von einem geeigneten Beobachtungspunkt an einen kompatiblen Collector. Sortieren Sie Quellen und Ziele im Vorfallszeitraum nach Bytes und prüfen Sie dann die Richtung. Sitzungs- oder Paketzahlen allein messen kein übertragenes Volumen.

Dokumentieren Sie Exporter, beobachtete Schnittstelle, Position vor oder nach NAT, Sampling und Zeitbezug des Collectors. Bei Stichproben müssen Collector und Exporter übereinstimmend eingestellt sein; Ergebnisse sind entsprechend als Schätzungen zu lesen. Derselbe Flow an mehreren Stellen bedeutet nicht mehrfach erzeugte Daten. Das ungeprüfte Addieren aller Beobachtungen kann doppelt zählen.

Unser praktischer Vorschlag: Ordnen Sie führende Verbraucher Geräteverantwortlichen, DHCP/IPAM-Daten und Dienstrollen zu. Eine öffentliche NAT-Adresse oder ein Proxy kann mehrere Nutzer vertreten. Flow-Daten liefern gewöhnlich keine entschlüsselten Anfrageinhalte. Für die Zuordnung zu einer konkreten Tätigkeit benötigen Sie zusätzlich Anwendungs- oder Endpunktbelege.

Cisco / NetFlow · IPFIX · PRTG / Sampling

3. FortiGate-Verkehr mit FortiView untersuchen

Wählen Sie in FortiView zunächst Zeitraum, Gerät oder VDOM und den betreffenden Verkehrsweg. Folgen Sie Quellen, Zielen, Anwendungen und Regeln, soweit Version und Funktionen dies unterstützen. Sortieren nach Bytes beantwortet eine Volumenfrage; Sortieren nach Bandbreite eine Ratenfrage.

Prüfen Sie bei einer leeren Grafik zuerst Protokollierungsabdeckung und Datenquelle. Historische Ansichten hängen von tatsächlich vorhandenen Protokollen und deren Speicherort ab. Fehlende Daten beweisen keinen fehlenden Verkehr. Was diese Firewall nicht passiert hat, liegt außerhalb ihrer Sicht. Bewerten Sie Anwendungserkennungen anhand der verfügbaren Sichtbarkeit.

Ein Anwendungsname oder Zielland rechtfertigt allein keine Sperre. Wir empfehlen, starke Quellen über Regel und Ziel bis zum Dienstverantwortlichen zu verfolgen und die Folgen einer Begrenzung für notwendige Arbeit zu prüfen. Menüs unterscheiden sich zwischen FortiOS-Versionen; dieser Abschnitt fordert keine Konfigurationsänderung an einer produktiven Firewall.

FortiView / Monitors · FortiView / Logging · FortiOS / Log settings

4. Übertragungsverhalten mit Wireshark analysieren

Sind Gerät und Weg bekannt, die Ursache aber noch unklar, erstellen Sie einen kurzen, eng begrenzten Mitschnitt. Der Beobachtungspunkt muss den Verkehr tatsächlich sehen. Im geswitchten Ethernet zeigt der Promiscuous Mode eines normalen Rechners nicht sämtliche Unicasts anderer Geräte. Nutzen Sie einen geeigneten Ort oder autorisiertes SPAN beziehungsweise TAP. Dieser Capture-Filter verwendet eine Dokumentationsadresse:

host 192.0.2.25

Ersetzen Sie die Beispieladresse durch einen autorisierten Endpunkt. Prüfen Sie unter Statistics die Conversations nach Bytes und Richtung und vergleichen Sie denselben Zeitraum in I/O Graphs. Bits über ein Intervall von 1 Sekunde erleichtern die Rateninterpretation. Die folgenden Zeilen sind getrennte Display-Filter, nicht der vorherige Capture-Filter:

ip.addr == 192.0.2.25
tcp.analysis.retransmission

Mitgeschnittene Bytes sind nicht automatisch Anwendungsnutzdaten oder WAN-Zählerwerte. Capture-Verluste, SPAN-Duplikate und Beobachtungsort können die Auswertung verzerren; eine Retransmission-Markierung allein beweist keinen Pfadfehler. Für Flussgrößen und Muster müssen TLS-Inhalte normalerweise nicht entschlüsselt werden. Begrenzen Sie Umfang, Dauer und Zugriffsrechte des Mitschnitts.

Wireshark / Capture · Conversations · I/O Graphs · Display filters · TCP analysis · Switched Ethernet

5. Den Windows-Prozess mit Resource Monitor finden

Ist die Quelle ein Windows-Rechner, öffnen Sie Resource Monitor und wählen Network. Sortieren Sie Prozesse mit Netzwerkaktivität nach Total, Send oder Receive, wählen Sie den Prozess und prüfen Sie zugehörige Ziele. B/sec sind Byte-Raten und nicht unmittelbar mit den Mbps der Verbindung vergleichbar.

Erfassen Sie Prozessname, PID, Beobachtungszeit und Ziel. Das PowerShell-Beispiel verbindet eine Beispiel-PID mit aktuellen TCP-Verbindungen; ersetzen Sie 4321. Es misst weder die Bandbreite jedes Prozesses noch erfasst es den gesamten UDP-Verkehr:

$trafficProcessId = 4321
Get-Process -Id $trafficProcessId
Get-NetTCPConnection -OwningProcess $trafficProcessId |
    Select-Object LocalAddress, LocalPort, RemoteAddress, RemotePort, State

Resource Monitor beschreibt diesen Rechner, nicht den gesamten Internetverbrauch der Organisation; auch lokaler LAN-Verkehr kann erscheinen. TCPView ergänzt Endpunkte und zugehörige Prozesse. Identifizieren Sie Dienst und Aufgabe, bevor Sie etwas beenden. Namen wie System oder svchost allein beweisen keine Schadsoftware und rechtfertigen keinen Abbruch.

Microsoft / Resource Monitor · Microsoft / TCPView · Get-NetTCPConnection

6. Schleifen und Broadcasts von Downloads unterscheiden

Ist das LAN stark beeinträchtigt, ohne dass WAN-Verbrauch die Symptome erklärt, untersuchen Sie Layer-2-Verhalten. Vergleichen Sie eingehende Paket-, Broadcast- und Multicast-Raten betroffener Ports mit der Topologie. Interner Verkehr erreicht die Internet-Firewall möglicherweise nie.

Topologieänderungen und MAC-Wechsel sind Hinweise, kein Beweis für den Ursprung einer Schleife. Wir empfehlen, unerwartet hohen Eingangsraten zu folgen und jüngste physische Verbindungen zu prüfen. Trennen Sie keinen unbekannten Uplink blind; begrenzen Sie nur einen bestätigten Abschnitt mit Rückfallplan.

Cisco / Layer-2 loops

7. Verbrauch mit Sicherungen und Updates abgleichen

Vergleichen Sie den Verkehrsstart mit Sicherungen, Replikation, Cloud-Synchronisierung, Softwareverteilung und Windows Update. Auch erlaubte Übertragungen können den Hauptdienst beeinträchtigen, wenn Zeitpunkt oder Bandbreitenzuweisung ungeeignet sind.

Für Delivery Optimization helfen Windows-eigene Berichte und Diagnosewerkzeuge; der Name eines gemeinsam genutzten Dienstes belegt noch keine konkrete Tätigkeit. Unser Vorschlag: den Auftrag mit seinem Verantwortlichen bestätigen und eine gezielte Zeit- oder Ratenanpassung testen, statt Sicherungen oder Sicherheitsupdates dauerhaft abzuschalten.

Microsoft / Delivery Optimization

8. Anwendungsprotokolle mit Netzwerkbelegen verknüpfen

Gehört ein Webdienst oder eine API zu den Hauptverbrauchern, vergleichen Sie Anfragezeiten, Pfade, Status und Antwortgrößen in Zugriffs- oder Anwendungsprotokollen. In NGINX beziehen sich Variablen wie $body_bytes_sent auf den Antwortinhalt. Anfragezahlen allein erklären kein Byte-Volumen.

Wir empfehlen, nur notwendige Metadaten zu sammeln und nach wiederholten Downloads, dauernden Wiederholungsversuchen oder unerwartet großen Antworten zu suchen. Ohne Berücksichtigung von Kompression und Messpunkt sind Anwendungsgrößen nicht mit Leitungsvolumen gleichzusetzen. Vor der Einstufung als Angriff sollten Verantwortlichenaussagen und echte Anfragemuster mit Flow-Daten übereinstimmen.

NGINX / Access logs · NGINX / Variables

Ein hypothetischer Vorfall: Gespräche stocken, Downloads funktionieren

Angenommen, der Dienstanschluss bietet 100 Mbps, der ausgehende Verkehr nähert sich 90 Mbps und Gespräche leiden, während Downloads noch akzeptabel sind. Prüfen Sie zuerst Ausgangsrichtung und deren Kapazität. Eine höhere ausgehandelte Portgeschwindigkeit hebt das Dienstlimit nicht auf.

In diesem Lehrbeispiel liegt der Beispielrechner 192.0.2.25 in den Flow-Daten weit oben. FortiView bestätigt passenden Verkehr im selben Zeitraum. Auf dem Rechner stimmen Sicherungsprozess und Auftragsprotokoll zeitlich mit dem Vorfall überein. Mit Zustimmung des Verantwortlichen begrenzen wir diesen Transfer vorübergehend und testen Gespräche sowie Ausgangsgrafik erneut. Eine Verbesserung ist ein hilfreicher Beleg; Wiederholbarkeit und parallele Tätigkeiten müssen für eine belastbare Schlussfolgerung trotzdem geprüft werden.

Ein praktischer Ablauf im Störungsfall

1. Zeit, Zeitzone, betroffenen Bereich und messbare Nutzerauswirkung festhalten.
2. Belastete Schnittstelle und Richtung anhand von Rate, Ausgangsbasis und Fehlern bestimmen.
3. Denselben Zeitraum in Flow- und Firewall-Daten verfolgen und den Geräteverantwortlichen ermitteln.
4. Bei Bedarf Endpunktbelege oder einen begrenzten Mitschnitt erfassen und eine rücknehmbare Änderung vornehmen.
5. Echte Nutzerfunktion und Erholung der Grafiken bestätigen sowie Verantwortung und Vorbeugung festlegen.

Fazit: Der größte Verbraucher ist nicht automatisch schuld

Unsere Empfehlung: nicht der größten Zahl folgen, sondern eine Beweiskette aus Schnittstelle, Gerät, Ziel, Prozess und tatsächlicher Tätigkeit aufbauen. Sie trennt erlaubte, aber ungünstig geplante Arbeit von unerwarteten Übertragungen, Netzwerkfehlern und verdächtigem Verhalten.

Weiterführender Beitrag

Gesunde Server, wartende Nutzer: Warum mittlere Latenz nicht ausreicht