3.7 Angriffsanalyse entlang der OSI-Schichten mit einfachem Fallbeispiel

Die Angriffsanalyse entlang der OSI-Schichten ist eine der hilfreichsten Methoden, um Sicherheitsvorfälle technisch sauber zu verstehen. Viele Einsteiger sehen einen Angriff zunächst als einzelnes Ereignis, etwa als verdächtige Verbindung, kompromittierten Host oder ungewöhnlichen Login. In der Praxis besteht ein Vorfall jedoch oft aus mehreren Schritten, die auf unterschiedlichen Schichten der Netzwerkkommunikation stattfinden. Genau hier bietet das OSI-Modell einen großen Vorteil. Es zerlegt Kommunikation in sieben logisch getrennte Ebenen und macht dadurch sichtbar, wo ein Angreifer ansetzt, welche Protokolle betroffen sind, welche Schutzmaßnahmen hätten greifen können und wie ein Vorfall systematisch untersucht werden sollte. Für CCNA, Cybersecurity Operations und allgemeine Netzwerkpraxis ist diese Denkweise besonders wertvoll, weil sie aus einem unübersichtlichen Sicherheitsereignis eine nachvollziehbare technische Kette macht. Ein einfaches Fallbeispiel hilft dabei, diese Logik praxisnah zu verstehen.

Warum die OSI-basierte Angriffsanalyse so nützlich ist

Ein Angriff betrifft selten nur eine einzige Ebene

Ein typischer Sicherheitsvorfall beginnt nicht immer direkt mit einer offensichtlichen Kompromittierung. Oft startet er auf einer Schicht und nutzt danach Schwächen auf weiteren Ebenen aus. Ein Angreifer kann sich physisch Zugang verschaffen, anschließend ein lokales Netzsegment ausnutzen, dann IP-basierte Erreichbarkeit testen, offene Ports identifizieren und schließlich eine Anwendung angreifen. Wer nur auf die letzte sichtbare Aktion schaut, übersieht häufig den eigentlichen Weg des Angriffs.

• physischer Zugang kann der erste Schritt sein
• lokale Netzwerkmanipulation kann Sichtbarkeit verändern
• Routing und Segmentierung beeinflussen die Reichweite
• offene Ports schaffen die Angriffsoberfläche
• Anwendungen bilden oft das eigentliche Endziel

Das OSI-Modell bringt Ordnung in komplexe Vorfälle

Das OSI-Modell hilft dabei, Angriffe nicht nur nach Werkzeugen oder Symptomen zu betrachten, sondern nach technischen Funktionen. So lässt sich bei einem Vorfall gezielt fragen:

• Auf welcher Schicht begann der Angriff?
• Welche weiteren Schichten wurden später ausgenutzt?
• Welche Datenquellen sind für jede Phase relevant?
• Wo hätte man den Angriff früher erkennen oder stoppen können?

Gerade im Incident Handling ist das ein großer Vorteil, weil Analyse, Dokumentation und Gegenmaßnahmen deutlich strukturierter werden.

Das Fallbeispiel: Ein kompromittierter Besucheranschluss im Unternehmensnetz

Ausgangssituation im Unternehmen

In einem mittelgroßen Unternehmen gibt es ein lokales Campus-Netz mit Benutzer-VLANs, einem Servernetz, einem Gastbereich und zentralem Internetzugang über Firewall und Router. Ein ungenutzter Netzwerkport in einem Besprechungsraum ist aktiv, aber nicht sauber deaktiviert oder einem streng isolierten Gastnetz zugeordnet. Ein Angreifer verbindet dort ein eigenes Gerät und beginnt mit ersten Erkundungen.

Die vereinfachte Umgebung sieht so aus:

• Access-Switch mit mehreren VLANs
• Benutzer-VLAN für Mitarbeitergeräte
• Server-VLAN mit internen Diensten
• Layer-3-Gateway für Inter-VLAN-Routing
• Firewall zum Internet und für definierte Zonenübergänge

Der Vorfall entwickelt sich nicht durch einen einzelnen spektakulären Exploit, sondern durch mehrere kleine Schwächen entlang verschiedener OSI-Schichten.

Warum dieses Beispiel realistisch ist

Viele Sicherheitsvorfälle in Unternehmen entstehen nicht durch maximal komplexe High-End-Angriffe, sondern durch Verkettungen aus Nachlässigkeit, Sichtbarkeitslücken und unzureichender Segmentierung. Genau deshalb eignet sich dieses Fallbeispiel so gut: Es zeigt, wie mehrere kleine Fehler über verschiedene Schichten zusammenwirken können.

Layer 1 – Physical: Der physische Zugang als erster Fehler

Was auf der physischen Schicht passiert

Der erste sicherheitsrelevante Schritt ist rein physisch. Der Angreifer kann sein Gerät an einen aktiven Port im Besprechungsraum anschließen. Damit ist noch kein System kompromittiert, aber die physische Eintrittsschwelle ins Netz ist überwunden. Auf Layer 1 geht es also nicht um IP, Ports oder Anwendungen, sondern um Medienzugang und Infrastrukturkontrolle.

Typische Layer-1-Fehler in diesem Beispiel:

• ungenutzter Port bleibt aktiv
• Port ist nicht administrativ deaktiviert
• Besprechungsraumanschlüsse sind nicht logisch getrennt
• physischer Zugang zum Netz ist zu einfach

Wie man den Fehler analysiert

Aus Sicherheitssicht ist die Frage auf Layer 1 nicht, ob der Link technisch funktioniert, sondern ob er überhaupt hätte verfügbar sein dürfen. Ein Port, der physisch aktiv ist, kann bereits der Beginn eines Vorfalls sein. Wichtige Prüfungen wären:

show interfaces status
show interfaces
show logging

Diese Befehle helfen dabei, aktive Ports, Interface-Zustände und Ereignisse rund um Link-Up/Link-Down sichtbar zu machen. Die eigentliche Sicherheitslücke ist hier jedoch organisatorisch und infrastrukturell: fehlende Portkontrolle.

Layer 2 – Data Link: Lokale Netzsicht und Segmentierungsfehler

Der Angreifer landet im falschen VLAN

Nach dem physischen Anschluss erhält das Gerät Zugang auf Layer 2. Im schlechten Design ist der Port versehentlich dem internen Benutzer-VLAN zugeordnet und nicht einem streng isolierten Gast-VLAN. Dadurch befindet sich der Angreifer direkt in derselben Broadcast-Domain wie interne Geräte. Er kann ARP-Broadcasts sehen, lokale MAC-Kommunikation beobachten und erste Netzsicht gewinnen.

Typische Layer-2-Probleme in diesem Schritt:

• Port im falschen VLAN
• kein isoliertes Gastsegment
• fehlende Port Security
• zu viel lokales Vertrauen im gleichen Layer-2-Bereich

Welche Analyse hier wichtig ist

Jetzt wird der Vorfall sicherheitsrelevant, weil der Angreifer lokale Informationen sammeln kann. Auf dieser Ebene wäre zu prüfen:

show vlan brief
show mac address-table
show interfaces trunk
show port-security interface gigabitEthernet0/10

Die entscheidende Sicherheitsfrage lautet: Warum konnte ein fremdes Gerät überhaupt in ein produktives VLAN gelangen? Genau hier zeigt sich, dass Segmentierung eine Kernfunktion von Netzwerksicherheit ist.

Layer 3 – Network: Reichweite durch Routing und IP-Struktur

Der Angreifer prüft erreichbare Netze

Nachdem das Gerät lokal eingebunden ist, betrachtet der Angreifer die IP-Konfiguration und testet, welche Ziele im lokalen Netz und darüber hinaus erreichbar sind. Dabei zeigt sich, dass nicht nur lokale Hosts sichtbar sind, sondern über das Default Gateway auch mehrere andere interne Netze erreichbar bleiben. Das ist ein klassischer Layer-3-Sicherheitsfehler: Segmentierung ist vorhanden, aber Routing- und Policy-Grenzen sind zu offen.

Typische Layer-3-Probleme im Beispiel:

• Benutzer-VLAN darf zu viele interne Ziele erreichen
• fehlende oder zu breite ACLs
• unzureichende Trennung von Benutzer- und Serversegmenten
• unnötige Ost-West-Erreichbarkeit im internen Netz

Welche Fragen ein Analyst stellen sollte

Auf dieser Schicht wäre zu analysieren:

• Welche Netze sind vom kompromittierten Segment aus erreichbar?
• Welche Route oder welches Gateway ermöglicht den Zugriff?
• Wo fehlen Filterregeln zwischen Zonen?

Hilfreiche Prüfungen auf Cisco-Seite wären:

show ip interface brief
show ip route
show access-lists
ping 10.10.20.10
traceroute 10.10.30.10

Diese Befehle zeigen, ob Inter-VLAN-Routing existiert, welche Ziele grundsätzlich erreichbar sind und ob Layer-3-Filterung vorhanden ist.

Layer 4 – Transport: Offene Ports und Dienstsichtbarkeit

Jetzt beginnt die eigentliche Angriffsoberfläche sichtbar zu werden

Nachdem der Angreifer weiß, welche Hosts erreichbar sind, prüft er, welche Dienste auf diesen Systemen lauschen. Genau hier wird Layer 4 relevant. Es geht nun nicht mehr nur darum, ob ein Host erreichbar ist, sondern welche TCP- oder UDP-Ports offen sind und damit potenzielle Angriffsfläche bieten.

Typische Beobachtungen in diesem Schritt:

• ein Server antwortet auf TCP 22
• ein alter Verwaltungsdienst ist auf TCP 23 offen
• eine interne Webanwendung läuft auf TCP 443
• ein Dateidienst reagiert in einem internen Segment

Aus Sicherheitssicht ist das ein kritischer Punkt, weil offene Ports die praktische Angriffsoberfläche definieren.

Welche Fehler hier typisch sind

Layer-4-Sicherheitsfehler bestehen oft nicht darin, dass „ein Port offen ist“, sondern dass der Port aus einem falschen Netz oder für zu viele Quellen offen ist. Typische Probleme sind:

• Verwaltungsdienste aus Benutzersegmenten erreichbar
• Telnet statt SSH aktiviert
• zu breite Freigabe für TCP- oder UDP-Dienste
• fehlende Netzwerksegmentierung vor empfindlichen Services

Einfach prüfbare sicherheitsrelevante Konfigurationen sind etwa:

show access-lists
show ip ssh
show running-config

Hier wird sichtbar, ob Managementzugänge sauber geschützt oder unnötig offen sind.

Layer 5 – Session: Missbrauch bestehender Kommunikationsbeziehungen

Der Angreifer nutzt gültige oder schwach geschützte Sitzungen

Im nächsten Schritt geht es nicht mehr nur um Erreichbarkeit, sondern um die Art, wie Sitzungen verwaltet werden. Angenommen, ein interner Webdienst oder ein Verwaltungsportal hält Sitzungen zu lange offen oder trennt Benutzerkontexte unzureichend. Dann kann ein Angreifer mit bereits vorhandenen oder schwach geschützten Sitzungsinformationen arbeiten.

Typische Layer-5-Fehler im Fallbeispiel:

• fehlende Session-Timeouts
• unsichere Wiederverwendung von Sitzungskennungen
• schwache Bindung von Sessions an Benutzerkontext oder Client
• fehlende Re-Authentifizierung bei sensiblen Aktionen

Warum dieser Schritt oft übersehen wird

Viele Teams konzentrieren sich stark auf Routing, Ports und Anwendungen, übersehen aber die Sitzungslogik dazwischen. Genau dort können Angreifer häufig ansetzen, wenn technische Erreichbarkeit bereits gegeben ist. Die Kommunikationsbeziehung selbst wird dann zum Angriffspunkt.

Layer 6 – Presentation: Schwache Absicherung der Datenrepräsentation

Verschlüsselung und Darstellung sind Teil der Sicherheitskette

Nun wird relevant, wie Daten dargestellt, kodiert oder verschlüsselt werden. Angenommen, eine interne Verwaltungsanwendung nutzt veraltete kryptografische Parameter oder akzeptiert problematische Zertifikatszustände. Dann liegt das Problem nicht in der Erreichbarkeit, sondern in der Art, wie Daten geschützt werden.

Typische Layer-6-Fehler im Beispiel:

• veraltete oder schwache Verschlüsselung
• unsaubere Zertifikatsprüfung
• mangelhafte Aushandlung sicherer Parameter
• unsichere Datenrepräsentation oder Formatbehandlung

Warum diese Ebene sicherheitskritisch ist

Ein Dienst kann aus Netzwerksicht korrekt funktionieren und dennoch auf dieser Ebene unsicher sein. Das ist besonders tückisch, weil Konnektivität allein dann einen falschen Eindruck von Sicherheit vermittelt. Die Analyse muss also immer weitergehen als bis zur bloßen Erreichbarkeit.

Layer 7 – Application: Die eigentliche Kompromittierung

Die Anwendung wird zum Endziel des Angriffs

Im letzten Schritt nutzt der Angreifer eine Schwäche in einer internen Webanwendung aus, die aus dem falsch segmentierten Netz erreichbar ist. Vielleicht fehlt eine saubere Eingabevalidierung, vielleicht gibt es schwache Authentifizierung oder unsichere API-Endpunkte. Die tatsächliche Kompromittierung findet also auf Layer 7 statt, wurde aber durch Fehler auf mehreren unteren Schichten vorbereitet.

Typische Layer-7-Probleme in diesem Beispiel:

• unzureichende Eingabevalidierung
• schwache Authentifizierung
• unsaubere Rollen- oder Rechteprüfung
• fehlender Schutz interner Admin-Funktionen
• unsichere API-Endpunkte

Warum Layer 7 oft nur das sichtbare Ende des Problems ist

In vielen Vorfällen wird der Anwendungsexploit als „der Angriff“ wahrgenommen. Tatsächlich war er aber oft nur der letzte Schritt einer Kette. Ohne den offenen physischen Zugang, das falsche VLAN, die zu breite Layer-3-Erreichbarkeit und die offenen Ports wäre die Anwendung möglicherweise nie erreichbar gewesen. Genau deshalb ist OSI-basierte Analyse so wertvoll: Sie verhindert zu enge Schuldzuweisungen und zeigt die gesamte Angriffskette.

Was wir aus dem Fallbeispiel pro Schicht lernen

Ein Angriff ist oft eine Verkettung kleiner Schwächen

Das wichtigste Ergebnis dieses Fallbeispiels ist, dass Sicherheitsvorfälle häufig nicht durch einen einzelnen „großen Fehler“ entstehen, sondern durch mehrere kleine Schwächen auf unterschiedlichen Ebenen. Jede einzelne Schwäche mag isoliert betrachtet klein wirken. Zusammengenommen ergeben sie jedoch einen realen Angriffsweg.

• Layer 1: Port physisch verfügbar
• Layer 2: falsches VLAN und fehlende Portkontrolle
• Layer 3: zu offene Routing- und Segmentierungsgrenzen
• Layer 4: unnötig erreichbare Dienste
• Layer 5: schwache Sitzungslogik
• Layer 6: unzureichende Schutzparameter
• Layer 7: ausnutzbare Anwendungsschwäche

Frühe Schichten sind oft die beste Stelle für Prävention

Ein weiterer wichtiger Punkt ist, dass viele Vorfälle leichter und früher hätten gestoppt werden können, wenn auf unteren Schichten sauberer gearbeitet worden wäre. Ein deaktivierter Port, ein korrektes Gast-VLAN oder strengere Inter-VLAN-Policies hätten die spätere Kompromittierung möglicherweise vollständig verhindert. Sicherheit ist daher nicht nur eine Frage der Anwendung, sondern der gesamten Kommunikationskette.

Wie man eine solche Analyse praktisch durchführt

Schichtweise statt symptomorientiert arbeiten

In der Praxis sollte ein Analyst einen Vorfall nicht nur anhand des sichtbarsten Symptoms beurteilen. Besser ist ein schichtweises Vorgehen:

• Gab es ungewollten physischen Zugang?
• War die lokale Segmentierung korrekt?
• Welche Layer-3-Pfade waren erreichbar?
• Welche Dienste waren offen?
• Wie waren Sitzungen und Verschlüsselung umgesetzt?
• Welche Anwendung wurde letztlich getroffen?

Diese Struktur macht Analyse und Dokumentation deutlich präziser.

Hilfreiche Cisco-Befehle entlang der Schichten

Für viele Teile dieser Analyse sind auf Cisco-Geräten bereits einfache Prüfungen sehr hilfreich:

show interfaces
show interfaces status
show vlan brief
show interfaces trunk
show mac address-table
show arp
show ip interface brief
show ip route
show access-lists
show logging

Mit diesen Befehlen lassen sich physische Zustände, lokale Segmentierung, Routingpfade, Filterregeln und Ereignisse sichtbar machen. Ergänzt durch Anwendungslogs und Security-Events ergibt sich daraus ein sehr brauchbares Gesamtbild des Vorfalls.

Warum diese Methode für CCNA und Cybersecurity so wichtig ist

Sie verbindet Netzwerkgrundlagen mit echter Sicherheitsanalyse

Die Angriffsanalyse entlang der OSI-Schichten zeigt sehr deutlich, warum Netzwerkwissen in der Cybersecurity unverzichtbar ist. Wer nur Anwendungsfehler betrachtet, übersieht oft die Infrastruktur. Wer nur Routing betrachtet, übersieht die Anwendung. Erst das Zusammenspiel aller Ebenen ergibt ein realistisches Bild.

Sie verbessert auch die Verteidigungsstrategie

Wer Vorfälle schichtweise analysiert, plant auch bessere Gegenmaßnahmen. Dann wird klar, dass Sicherheit nicht nur aus Firewalls oder einem Webfilter besteht, sondern aus physischer Kontrolle, Segmentierung, Routinggrenzen, Diensthärtung, sauberer Sitzungsverwaltung und sicherer Anwendungsgestaltung. Genau diese mehrschichtige Sicht macht aus isolierten Kontrollen eine belastbare Sicherheitsarchitektur.

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab/GNS3

Ich biete professionelle Unterstützung im Bereich Netzwerkkonfiguration und Network Automation für private Anforderungen, Studienprojekte, Lernlabore, kleine Unternehmen sowie technische Projekte. Ich unterstütze Sie bei der Konfiguration von Routern und Switches, der Erstellung praxisnaher Topologien in Cisco Packet Tracer, dem Aufbau und Troubleshooting von GNS3- und EVE-NG-Labs sowie bei der Automatisierung von Netzwerkaufgaben mit Netmiko, Paramiko, NAPALM und Ansible. Kontaktieren Sie mich jetzt – klicken Sie hier.

Meine Leistungen umfassen:

• Professionelle Konfiguration von Routern und Switches

• Einrichtung von VLANs, Trunks, Routing, DHCP, NAT, ACLs und weiteren Netzwerkfunktionen

• Erstellung von Topologien und Simulationen in Cisco Packet Tracer

• Aufbau, Analyse und Fehlerbehebung von Netzwerk-Labs in GNS3 und EVE-NG

• Automatisierung von Netzwerkkonfigurationen mit Python, Netmiko, Paramiko, NAPALM und Ansible

• Erstellung von Skripten für wiederkehrende Netzwerkaufgaben

• Dokumentation der Konfigurationen und Bereitstellung nachvollziehbarer Lösungswege

• Konfigurations-Backups, Optimierung bestehender Setups und technisches Troubleshooting

Benötigen Sie Unterstützung bei Ihrem Netzwerkprojekt, Ihrer Simulation oder Ihrer Network-Automation-Lösung? Kontaktieren Sie mich jetzt – klicken Sie hier.