Der dargestellte Prozess orientiert sich dabei an den Inhalten der CompTIA Network+ Zertifizierung.

Problem identifizieren

Zunächst muss das eigentliche Problem möglichst eindeutig identifiziert und eingegrenzt werden.

Dazu gehören insbesondere:

• Informationen zum Problem sammeln
• Betroffene Benutzer, Systeme und Netzwerkbereiche bestimmen
• Symptome und Fehlermeldungen erfassen
• Feststellen, seit wann das Problem besteht
• Kürzlich durchgeführte Änderungen berücksichtigen
• Problem nach Möglichkeit reproduzieren
• Logs, Monitoring und vorhandene Dokumentation einbeziehen

Bei der Aufnahme einer Netzwerkstörung helfen gezielte Fragen dabei, das Fehlerbild schnell einzugrenzen.

Ziel dieses Schrittes ist eine möglichst klare Beschreibung des Fehlerbildes.

Theorie zur wahrscheinlichen Ursache entwickeln

Auf Basis der gesammelten Informationen werden mögliche Ursachen abgeleitet.

Dabei sollte zunächst mit den einfachsten und wahrscheinlichsten Ursachen begonnen werden. Anschließend kann die Analyse schrittweise auf komplexere Zusammenhänge ausgeweitet werden.

Zur strukturierten Eingrenzung kann beispielsweise das OSI-Modell verwendet werden. Je nach Fehlerbild kann dabei Bottom-Up, Top-Down oder gezielt auf einzelnen Layern gearbeitet werden.

Neben den genannten Methoden, die sich am OSI-Modell orientieren, gibt es jedoch auch weitere Verfahren.

Theorie testen

Die vermutete Ursache wird anschließend durch geeignete Tests überprüft.

Wird die Theorie bestätigt, kann mit der Planung der Lösung begonnen werden.

Wird sie nicht bestätigt, muss eine neue mögliche Ursache entwickelt und getestet werden.

Maßnahmenplan erstellen

Nach der Identifikation der Ursache wird ein Plan zur Behebung des Problems erstellt.

Dabei sollten insbesondere berücksichtigt werden:

• Erforderliche Änderungen
• Mögliche Auswirkungen
• Abhängigkeiten
• Notwendige Freigaben
• Wartungsfenster
• Backup der Konfiguration
• Rollback-Möglichkeit

Die eigentliche Änderung sollte erst erfolgen, wenn klar ist, wie das Problem behoben und die Änderung gegebenenfalls rückgängig gemacht werden kann.

Lösung implementieren oder eskalieren

Die geplante Maßnahme wird umgesetzt.

Kann die Fehlerursache nicht im eigenen Verantwortungsbereich behoben werden, erfolgt eine Eskalation an die zuständige Stelle.

Bei einer Eskalation sollten die bisher gewonnenen Informationen und Testergebnisse vollständig weitergegeben werden.

Funktionalität überprüfen

Nach Umsetzung der Maßnahme wird überprüft, ob das ursprüngliche Problem tatsächlich behoben wurde.

Dabei sollte nicht nur das ursprüngliche Fehlerbild getestet werden. Es muss ebenfalls sichergestellt werden, dass durch die Änderung keine anderen Funktionen beeinträchtigt wurden.

Zusätzlich sollte geprüft werden, ob präventive Maßnahmen sinnvoll sind, um ein erneutes Auftreten des Problems zu verhindern.

Ergebnisse dokumentieren

Abschließend wird der gesamte Vorgang dokumentiert.

Dazu gehören:

• Fehlerbild
• Ursache
• Durchgeführte Analyse
• Umgesetzte Maßnahme
• Ergebnis
• Gegebenenfalls präventive Maßnahmen

Die Dokumentation erleichtert die Bearbeitung zukünftiger Störungen und ermöglicht den Aufbau einer Wissensdatenbank für wiederkehrende Fehlerbilder.

Der Troubleshooting-Prozess im Überblick

Eine strukturierte Netzwerk-Fehlerbehebung folgt damit einem einfachen Grundprinzip:

Insbesondere die Trennung zwischen Analyse, Hypothese, Test und eigentlicher Änderung verhindert vorschnelle Eingriffe und sorgt dafür, dass Netzwerkprobleme nachvollziehbar und reproduzierbar bearbeitet werden.

Quellen

• ciscopress.com – Structured Troubleshooting Approaches

Der Beitrag Methodik zur systematischen Netzwerk-Fehlerbehebung erschien zuerst auf Maximilian Krieg.

Kurze Zeit später folgten weitere Nachrichten. Empfänger fragten, warum sie diese E-Mail erhalten hatten, andere wollten aus dem Verteiler entfernt werden. Aus einer einzelnen Nachricht entwickelte sich innerhalb kurzer Zeit ein sogenannter E-Mail-Sturm.

In diesem Artikel beschreibe ich anhand dieses Beispiels, wie sich ein E-Mail-Sturm erkennen lässt, wie er entsteht und welche Maßnahmen helfen, ohne selbst zur weiteren Eskalation beizutragen.

Die initiale E-Mail

Beim Blick auf die E-Mail-Header fällt auf, dass die Nachricht nicht direkt vom Autohändler an mich, sondern an eine Mail-Gruppe gesendet wurde.

Eine genauere Analyse der Header, beispielsweise mit dem Email Header Analyzer von MXToolbox, zeigt, dass die Nachricht technisch korrekt zugestellt wurde und zunächst keine direkten Anzeichen für Phishing oder Schadsoftware enthält.

Obwohl die E-Mail inhaltlich nicht nach klassischem Spam aussieht, gibt es einige Auffälligkeiten:

• Ich erhielt eine Antwort auf eine Anfrage, die ich nie versendet hatte.
• Empfänger-, Absender- und Reply-To-Adresse passten nicht zum Inhalt.
• Die Nachricht wurde über eine mir unbekannte Google Group beziehungsweise Mailingliste versendet.

Anhand der Received-Header lässt sich nachvollziehen, welchen Weg die Nachricht vom ursprünglichen Absender bis in das eigene Postfach genommen hat.

In E-Mail-Header-Analysetools werden die einzelnen Übergabepunkte (Hops) häufig tabellarisch dargestellt. Zusätzlich können beispielsweise die beteiligten Mailserver und deren IP-Adressen auf bekannte Blacklist-Einträge geprüft werden.

In diesem Fall führte der Weg unter anderem über Microsoft 365, Hornet Security und Google bis zum empfangenden Mailserver.

Interessanter sind jedoch die Header, die Informationen über die verwendete Mailingliste enthalten:

Damit war klar, dass die Nachricht über eine Google Group beziehungsweise Mailingliste verteilt wurde.

Der E-Mail-Sturm beginnt

Kurze Zeit nach der ersten Nachricht trafen weitere E-Mails ein. Zahlreiche Empfänger reagierten auf die ursprüngliche Nachricht beispielsweise mit:

„Warum bekomme ich diese E-Mail?“

„Bitte nehmen Sie mich aus dem Verteiler.“

„Bitte nicht mehr an alle antworten!“

Genau diese Antworten wurden jedoch erneut über die Mailingliste verteilt und erreichten damit wiederum deren Teilnehmer.

Aus der ursprünglich einzelnen Nachricht entwickelte sich so innerhalb kurzer Zeit ein klassischer E-Mail-Sturm.

Was ist ein E-Mail-Sturm?

Ein E-Mail-Sturm (engl. Mail Storm, Reply Storm oder Reply-All Storm) entsteht, wenn eine Nachricht an einen großen Verteiler oder eine Mailingliste versendet wird und zahlreiche Empfänger darauf antworten. Dabei erfolgt die Antwort beispielsweise über eine entsprechend konfigurierte Reply-To-Adresse oder durch die Funktion „Allen antworten“.

Wird die Antwort anschließend wieder an alle Mitglieder des Verteilers zugestellt, erhalten sämtliche Teilnehmer diese Nachricht. Antworten darauf wiederum weitere Empfänger, entsteht ein sich selbst verstärkender Effekt.

Aus einer einzelnen Nachricht können dadurch innerhalb kurzer Zeit dutzende, hunderte oder sogar tausende E-Mails entstehen.

Ursachen und Symptome

In den meisten Fällen entsteht ein E-Mail-Sturm unbeabsichtigt.

Häufige Ursachen sind:

• Versehentliches Antworten an alle Empfänger
• Fehlkonfigurierte Mailinglisten oder Verteiler
• Import alter oder ungepflegter Verteilerlisten
• Organisatorische Fehler bei der Nutzung von Verteilergruppen
• Absichtlicher Missbrauch zur Störung oder Belästigung

Typischerweise erkennt man einen laufenden E-Mail-Sturm daran, dass innerhalb kurzer Zeit zahlreiche Nachrichten mit ähnlichem Inhalt eintreffen. Das eigentliche Problem besteht darin, dass viele Empfänger versuchen, das Problem durch eine Antwort zu lösen.

Die Aufforderung

„Bitte entfernen Sie mich aus diesem Verteiler.“

klingt zunächst sinnvoll. Wird sie jedoch wieder an den gesamten Verteiler gesendet, erhalten alle Teilnehmer eine weitere Nachricht.

Dadurch verstärken die Empfänger den E-Mail-Sturm unbeabsichtigt selbst.

Eskalation durch automatische Systeme

Besonders problematisch wird ein E-Mail-Sturm, wenn neben menschlichen Empfängern auch automatisierte Systeme auf die Nachrichten reagieren.

Dazu gehören beispielsweise:

• Automatische Abwesenheitsnotizen
• Ticketsysteme
• Monitoring- und Alarmierungssysteme
• Weitere Mailinglisten oder Verteiler
• Automatisierte Workflows und Benachrichtigungssysteme

Antwortet beispielsweise ein Ticketsystem automatisch auf jede eingehende E-Mail und wird diese Antwort wiederum an die Mailingliste verteilt, kann dadurch eine weitere automatische Reaktion ausgelöst werden.

Im ungünstigsten Fall entstehen Schleifen zwischen mehreren Systemen.

Je größer der Verteiler und je mehr automatisierte Systeme beteiligt sind, desto schneller kann sich ein einzelner Fehler zu einer erheblichen Nachrichtenflut entwickeln.

Die Folgen reichen von überfüllten Postfächern über stark belastete Helpdesks bis hin zu einer zusätzlichen Belastung der beteiligten Mail-Infrastruktur.

Böswillig ausgelöste E-Mail-Stürme

Während die meisten E-Mail-Stürme unbeabsichtigt entstehen, können solche Situationen auch gezielt provoziert werden.

In meinem Fall sprach einiges für einen absichtlichen Missbrauch. Die betroffene E-Mail-Adresse wurde von mir nur auf einer einzelnen Plattform verwendet, bei der es in der Vergangenheit zu einem Datenleck gekommen war.

Mögliche Ziele eines absichtlich erzeugten E-Mail-Sturms sind beispielsweise:

• Gezielte Belästigung von Personen oder Organisationen
• Störung des normalen E-Mail-Verkehrs
• Belastung von Postfächern, Mailservern oder Helpdesks
• Überprüfung, welche E-Mail-Adressen tatsächlich aktiv verwendet werden

Gerade der letzte Punkt ist interessant: Antworten Empfänger auf die Nachrichten oder führen andere Aktionen aus, können Angreifer unter Umständen Rückschlüsse darauf ziehen, welche Adressen noch aktiv genutzt werden.

Wie sollte man auf einen E-Mail-Sturm reagieren?

Sobald ein E-Mail-Sturm erkannt wurde, sollte man vor allem vermeiden, selbst zu seiner weiteren Eskalation beizutragen.

Die wichtigste Regel lautet daher:

Nicht auf „Allen antworten“ klicken.

Auch eine gut gemeinte Nachricht mit der Bitte, aus dem Verteiler entfernt zu werden, kann den Sturm weiter verstärken.

Stattdessen kommen unter anderem folgende Maßnahmen infrage:

• Mailingliste beziehungsweise Absender blockieren
• Filterregeln für die betroffenen Nachrichten erstellen
• Nachricht als Spam melden
• Administrator der Mailingliste kontaktieren
• Sich direkt aus der Mailingliste austragen

Welche Maßnahme sinnvoll ist, hängt von der Ursache des E-Mail-Sturms ab.

Bei einer legitimen, aber fehlerhaft konfigurierten Unternehmens-Mailingliste kann beispielsweise die Kontaktaufnahme mit dem Administrator sinnvoll sein.

Handelt es sich dagegen um eine absichtlich missbrauchte Mailingliste, ist dies möglicherweise nicht zielführend.

In meinem Fall entschied ich mich deshalb dafür, mich direkt aus der verwendeten Mailingliste auszutragen.

Dafür musste ich nicht auf eine der Nachrichten des E-Mail-Sturms antworten. Stattdessen konnte der in der Nachricht vorhandene List-Unsubscribe-Header verwendet werden.

Wie dieser Header funktioniert und wie man sich damit manuell aus einer Mailingliste oder einem Newsletter austragen kann, beschreibe ich im folgenden Artikel Mit List-Unsubscribe aus Newslettern und Mailinglisten austragen.

Quellen

• wikipedia.org – Email storm
• mxtoolbox.com – Email Header Analyzer, RFC822 Parser

Der Beitrag Erkennung und Vermeidung eines E-Mail-Sturms erschien zuerst auf Maximilian Krieg.

Auflistung aller NetTCPIP-Cmdlets

Die folgenden Cmdlets decken zahlreiche Aufgaben rund um die TCP/IP-Konfiguration ab, darunter das Auslesen und Verwalten von IP-Adressen, Routingtabellen, Netzwerkinterfaces, TCP- und UDP-Einstellungen sowie Diagnose- und Verbindungsprüfungen. Sie eignen sich für Administratoren im täglichen Betrieb als auch für Troubleshooting- und Automatisierungsaufgaben.

Zur besseren Orientierung sind alle Cmdlets alphabetisch nach dem jeweiligen Verb am Anfang des Befehls sortiert, beispielsweise Get, Set, New, Remove oder Test. Dadurch lassen sich passende Befehle schnell finden und logisch nach ihrer Funktion einordnen.

Vergleich PowerShell zu klassischer CMD

Bei der Durchsicht und Ausführung der Befehle ist mir dabei aufgefallen, dass viele PowerShell-Befehle ähnliche Informationen liefern wie die klassischen Netzwerkbefehle aus der Windows-Eingabeaufforderung CMD. Die folgende Tabelle liefert daher eine Gegenüberstellung zwischen klassischen Netzwerkbefehlen und den entsprechenden PowerShell-Cmdlets.

Quelle

• NetTCPIP Module | Microsoft Learn

Der Beitrag PowerShell – NetTCPIP-Cmdlets erschien zuerst auf Maximilian Krieg.

Gerade bei Remote-Analysen oder komplexeren Netzwerkproblemen ist die PowerShell oft deutlich praktischer als die grafische Oberfläche. In diesem Beitrag zeige ich, wie sich Get-NetAdapter sinnvoll einsetzen lässt und welche Informationen bei der Fehlersuche besonders hilfreich sind.

Abfrage der Netzwerkadapter

Zunächst beziehen wir die Interface-Informationen der vorhandenen Netzwerkadapter. Besonders interessant ist dabei der Interface-Index, da dieser von vielen weiteren PowerShell-Netzwerkbefehlen zur eindeutigen Identifikation des Adapters verwendet wird. In dem konkreten Fall haben wir jedoch mit dem Interface-Namen gearbeitet.

PS C:\Windows\System32> Get-NetAdapter

Name                      InterfaceDescription                    ifIndex Status       MacAddress             LinkSpeed
----                      --------------------                    ------- ------       ----------             ---------
WLAN                      Intel(R) Wi-Fi 6 AX203                       11 Up           XX-XX-XX-A5-A8-XX       1.2 Gbps
Bluetooth-Netzwerkverb... Bluetooth Device (Personal Area Netw...      10 Disconnected XX-XX-XX-XX-XX-XX         3 Mbps
Ethernet                  Realtek PCIe GbE Family Controller            3 Disconnected XX-XX-XX-XX-XX-X          0 bps

Abfrage-Skript mit Variable

Das Interface, welches wir uns genauer anschauen möchten, trägt in diesem Beispiel den Namen WLAN. Daher setzen wir den entsprechenden Interface-Namen in der PowerShell-Variable ein und führen anschließend die folgenden Befehle aus. Damit lassen sich unter anderem Adapterstatus, IP-Konfiguration, DNS-Server, erweiterte Adaptereigenschaften sowie aktive Netzwerkbindungen auslesen.

PS C:\Windows\System32> 

$if = "WLAN"

Get-NetAdapter -Name $if
Get-NetIPConfiguration -InterfaceAlias $if
Get-NetIPAddress -InterfaceAlias $if
Get-NetAdapterAdvancedProperty -Name $if
Get-DnsClientServerAddress -InterfaceAlias $if
Get-NetAdapterBinding -Name $if
Get-NetConnectionProfile -InterfaceAlias $if
Get-NetAdapterStatistics -Name $if
Get-NetIPInterface -InterfaceAlias $if
Get-NetRoute -InterfaceAlias $if
Get-NetNeighbor -InterfaceAlias $if

Remove-Variable if

Durch die Verwendung einer gemeinsamen Interface-Variable lassen sich die Befehle außerdem einfach wiederverwenden und flexibel auf andere Netzwerkadapter anwenden.

Beschreibung der Cmdlets

Die folgende Tabelle beschreibt nochmals, welche Informationen die jeweiligen Befehle liefern. Dabei überschneiden sich einige Ausgaben bewusst, da bestimmte Informationen von mehreren Cmdlets bereitgestellt werden oder unterschiedlich detailliert dargestellt sind.

Viele der gezeigten Befehle liefern bereits ohne zusätzliche Tools wertvolle Informationen für die Fehlersuche und ermöglichen eine schnelle erste Einschätzung der Netzwerksituation.

Der Beitrag PowerShell – NIC-Konfiguration auslesen erschien zuerst auf Maximilian Krieg.

Fortinet FortiGate

Die FortiGate-Firewall ist ein Next Generation Firewall (NGWF), die von Fortinet entwickelt wurde. Sie bietet umfassenden Schutz für Netzwerke, indem sie den Datenverkehr überwacht, analysiert und steuert.

Allgemein

• Network Interface Card NIC commands
• How to clear interface counters from CLI

FortiOS 6.4

• FortiOS v6.4 Cheatsheet | Tech Blog (boll.ch)
• FortiOS v6.4 CLI reference | Fortinet Document Library

FortiOS 7.0

• FortiOS v7.0 Cheatsheet | Tech Blog (boll.ch)
• FortiOS v7.0 CLI reference | Fortinet Document Library

FortiOS 7.2

• FortiOS v7.2 Cheatsheet | Tech Blog (boll.ch)
• FortiOS v7.2 CLI reference | Fortinet Document Library

FortiOS 7.4

• FortiOS v7.4 Cheatsheet | Tech Blog (boll.ch)
• FortiOS v7.4 CLI reference | Fortinet Document Library
• FortiOS v7.4 CLI troubleshooting cheat sheet | Fortinet Document Library

FortiOS 7.6

• FortiOS v7.6 CheatSheet | Tech Blog (boll.ch)
• FortiOS v7.6 CLI reference | Fortinet Document Library

Fortinet FortiAnalyzer

Der FortiAnalyzer ist eine leistungsstarke Plattform für Protokollverwaltung, Analysen und Berichterstattung. Er bietet Organisationen eine einzige Konsole zur Verwaltung, Automatisierung, Orchestrierung und Reaktion.

FortiAnalyzer 6.4

• FortiAnalyzer v6.4 Cheatsheet | Tech Blog (boll.ch)
• FortiAnalyzer v6.4 | Fortinet Document Library

FortiAnalyzer 7.0

• FortiAnalyzer v7.0 Cheatsheet | Tech Blog (boll.ch)
• FortiAnalyzer v7.0 CLI reference | Fortinet Document Library

FortiAnalyzer 7.2

• FortiAnalyzer v7.2 CLI reference | Fortinet Document Library

FortiAnalyzer 7.4

• FortiAnalyzer v7.4 CLI reference | Fortinet Document Library

Fortinet FortiManager

Der FortiManager ist eine zentrale Plattform zur Verwaltung von Fortinet-Geräten und Richtlinien in verschiedenen Umgebungen. Er ermöglicht die zentrale Administration von unter anderem FortiGate-Firewalls, FortiAnalyzer, FortiSwitches, FortiAPs und FortiExtender-Geräten.

FortiManager 6.4

• FortiManager v6.4 CLI reference | Fortinet Document Library

FortiManager 7.0

• FortiManager v7.0 Cheatsheet | Tech Blog (boll.ch)
• FortiManager v7.0 CLI reference | Fortinet Document Library

FortiManager 7.2

• FortiManager v7.2 CLI reference | Fortinet Document Library

FortiManager 7.4

• FortiManager v7.4 CLI reference | Fortinet Document Library

Der Beitrag Fortinet – Cheatsheets für CLI-Befehle erschien zuerst auf Maximilian Krieg.