Enterprise-LAN-Hardening-Checkliste: Pflicht-Controls (L2 Edition)

Eine Enterprise-LAN-Hardening-Checkliste auf Layer 2 ist in vielen Organisationen der schnellste Hebel, um typische Angriffs- und Störszenarien im Campus- oder Office-Netz spürbar zu reduzieren. Während Firewalls, WAFs und EDR oft im Fokus stehen, entstehen im täglichen Betrieb viele sicherheitsrelevante Vorfälle direkt „am Rand“: Rogue Switches, Rogue DHCP-Server, ARP-Spoofing/MITM, MAC-Flooding, VLAN-Fehlzuweisungen oder simple Layer-2-Loops durch falsches Patchen. Genau dort greifen L2-Controls – und genau dort können Fehlkonfigurationen auch große Ausfälle verursachen. Deshalb ist ein solides Hardening nicht nur eine Liste von Features, sondern ein setzbarer Standard aus Pflichtmaßnahmen, Betriebsregeln, Validierung und Monitoring. Diese L2 Edition richtet sich an ein breites Publikum: Einsteiger bekommen klare Orientierung, Fortgeschrittene finden praxisnahe Checks, und Profis erhalten eine strukturierte Basis, die audit- und rollout-tauglich ist. Ziel ist ein LAN, das Angriffe erschwert, Fehlverhalten schnell sichtbar macht und gleichzeitig produktionssicher bleibt.

Scope und Grundprinzipien der L2-Härtung

Layer-2-Hardening bezieht sich auf Maßnahmen innerhalb von Broadcast-Domains und Switch-Fabrics: Access-Ports, Trunks, VLANs, Spanning Tree, L2-Security-Features, Management-Zugänge und Telemetrie. In Enterprise-Umgebungen gilt als Leitprinzip: Default-deny am Edge, klare Trust-Grenzen und beobachtbare Enforcement-Mechanismen. Dabei sollten Sie konsequent zwischen Edge-Ports (Endgeräte) und Infrastruktur-Ports (Uplinks, Switch-to-Switch, AP-Uplinks, Server-Uplinks) unterscheiden. Viele Outages entstehen, weil Controls auf Infrastruktur-Ports aktiv sind, die als „Edge“ behandelt wurden, oder weil Trust-Ports nicht sauber definiert sind.

• Edge-First: Kontrollen zuerst an Endgeräteports ausrollen, Uplinks bewusst ausnehmen bzw. als trusted definieren.
• Stufenweises Enforcement: Wo möglich erst Monitor/Log, dann Restrict, erst zum Schluss Drop/Shutdown.
• Rollback als Pflicht: Jede Maßnahme braucht einen getesteten Rückweg in Minuten (nicht Stunden).
• Visibility ist Teil des Controls: Ein Control ohne Logs/Counters ist operativ kaum nutzbar.

Pflicht-Control 1: Port-Rollen, Trust-Boundaries und saubere Interface-Standards

Bevor Sie einzelne Features aktivieren, definieren Sie standardisierte Port-Profile. Ein Access-Port für Benutzerarbeitsplätze braucht andere Defaults als ein AP-Uplink oder ein Switch-Uplink. Diese Standardisierung ist die Basis, damit spätere L2-Controls nicht zufällig ausrollen.

• Port-Typen: User-Edge, Voice+Data, IoT/OT, AP-Uplink, Switch-Uplink, Server-Uplink.
• Allowed VLANs: Trunks minimal halten; „VLAN all“ ist ein Anti-Pattern.
• Native VLAN: Klar definiert und möglichst ungenutzt; Trunk-Native nicht mit produktiven VLANs mischen.
• Deaktivierte Ports: Unused Ports administrativ down und in Quarantine-VLAN (ohne L3-Gateway) oder „blackhole VLAN“.
• Beschriftung/Description: Switchport-Beschreibung mit Standort/Endgerät/Owner erleichtert IR.

Pflicht-Control 2: 802.1X / NAC (Minimum-Baseline für Identity am Port)

802.1X (oder ein NAC-Äquivalent) ist eines der wirksamsten Enterprise-L2-Controls, weil es das „Einstecken reicht“ Modell aufbricht. Selbst wenn Sie nicht sofort „Closed Mode“ fahren, ist ein stufenweiser Einstieg möglich: zunächst Monitor, dann Low Impact Enforcement (z. B. Guest/Remediation VLAN), später segmentierte Policies.

• Startpunkt: 802.1X im „Monitor“-Modus mit Logging und Inventarisierung unbekannter Devices.
• MAB-Fallback: Für Drucker/IoT/Legacy, aber nur mit klaren Regeln (MAC-Listen sind pflegeintensiv).
• Critical Auth: Definieren, was bei RADIUS/NAC-Ausfall passiert (Fail-open vs. Fail-closed je Porttyp).
• Guest/Contractor: Separater Onboarding-Pfad; keine „Sonderports“ ohne Kontrolle.

Für technische Hintergründe zu EAP/802.1X ist die Übersicht der IEEE-Standards sowie praxisnahe Hersteller-Guides hilfreich; als allgemeiner Einstieg eignet sich z. B. der Überblick zu Network Access Control Konzepten.

Pflicht-Control 3: DHCP Snooping als Fundament gegen Rogue DHCP

DHCP Snooping schützt Clients vor falschen IP-Konfigurationen und Rogue DHCP-Servern und ist gleichzeitig Grundlage für weitere Controls. In Enterprise-LANs sollte DHCP Snooping als Standard in Access-VLANs betrachtet werden – mit sauber gepflegten Trusted Ports (Uplinks Richtung DHCP/Relay).

• Trusted/Untrusted: Standard: Access-Ports untrusted; nur definierte Uplinks/Relay-Pfade trusted.
• VLAN-Scoping: Snooping nur in VLANs aktivieren, in denen DHCP wirklich genutzt wird.
• Rate Limits: Untrusted Ports begrenzen, um DHCP-Floods zu dämpfen, aber nicht so niedrig, dass Boot-Stürme ausfallen.
• Option 82: Wenn genutzt, End-to-End testen (DHCP-Server/Relay müssen es akzeptieren).
• Binding-Table: Größe, Aging und Persistenz prüfen, sonst drohen unerklärliche Drops.

Zum Protokoll- und Rollenverständnis von DHCP ist die Orientierung über den RFC Editor nützlich, um Client/Server/Relay-Modelle sauber zu trennen.

Pflicht-Control 4: Dynamic ARP Inspection (DAI) gegen ARP-Spoofing/MITM

DAI validiert ARP-Pakete und verhindert so viele lokale MITM-Szenarien. In der Praxis ist DAI ein „High Value“-Control, aber nur produktionssicher, wenn Sie mit statischen Hosts, Sonderfällen und korrekten Trust-Ports umgehen können.

• Abhängigkeit: DAI nutzt häufig DHCP Snooping Bindings – ohne stabile Bindings wird DAI fragil.
• Statische IPs: Müssen über statische Bindings oder ARP-ACLs abgebildet werden.
• Trust-Ports: Infrastrukturpfade (Uplinks, SVI/Gateway-Umfeld je Plattform) korrekt als trusted definieren.
• Validation-Checks: Source/Destination MAC Validation vorsichtig aktivieren und per Pilot testen.
• Monitoring: DAI Drops, Top Talkers, Violation-Logs und Counters müssen sichtbar sein.

Pflicht-Control 5: IP Source Guard (wo sinnvoll) – Spoofing am Edge begrenzen

IP Source Guard blockiert Traffic mit unpassender Quell-IP/MAC am Access-Port. In Enterprise-LANs ist es besonders dort wirksam, wo viele ungemanagte Endgeräte sind oder wo eine saubere DHCP-basierte Adressierung erzwungen werden soll. Gleichzeitig ist es kein universelles Allheilmittel, weil Multi-IP-Hosts, Dual-Stack und Spezialgeräte schnell Ausnahmen brauchen.

• Einsatzgebiet: User-Edge, IoT-Edge, nicht für Server-Uplinks ohne klares Binding-Modell.
• Ausnahmen: Multi-IP/Virtualisierung/Bridging sauber inventarisieren.
• Stufenweise: Erst Logging/Counter, dann restriktive Policies.

Pflicht-Control 6: Port Security (mit produktionsgerechtem Tuning)

Port Security ist ein Klassiker – und eine häufige Outage-Ursache. In Enterprise-Umgebungen gilt: Port Security ist dann sinnvoll, wenn Sie reale Nutzungsprofile kennen (Docking, VoIP, APs, Mini-Switches) und die Violation-Aktion zur Betriebsrealität passt.

• MAC-Limit pro Port: Nicht pauschal 1; Voice+Data benötigt meist 2–3, AP-Uplinks deutlich mehr.
• Violation-Mode: „Restrict“ oder „Protect“ ist oft sicherer als „Shutdown“ (geringerer Kollateralschaden).
• Sticky MAC: Nur einsetzen, wenn Sie den Lifecycle (Gerätetausch) operativ abdecken können.
• Automatisierte Recovery: Wenn Ports errdisabled werden können, ist ein klarer Entsperrprozess Pflicht.

Pflicht-Control 7: Storm Control und Broadcast/Multicast-Hygiene

Storm Control schützt Switches und Segmente vor Broadcast- oder Multicast-Stürmen, kann aber auch unabsichtlich Service Discovery, VoIP oder Video beeinträchtigen. Pflicht ist deshalb: Baseline messen, Schwellenwerte ableiten und im Pilot beobachten.

• Baseline: Broadcast-/Multicast-Raten pro VLAN und Tageszeit erfassen.
• Thresholds: Nicht „aus Bauchgefühl“, sondern mit Puffer für Bursts (Boot storms, Topology changes).
• Unknown Unicast: Vorsicht in Netzen mit asymmetrischem MAC-Learning oder mit Overlay/Virtualisierung.
• Alarmierung: Storm-Events sollten Tickets/Alerts erzeugen, nicht nur still droppen.

Ein nützliches Konzept ist die Ableitung eines Thresholds aus Baseline und Varianz:

$T=B+k\times \sigma$

• B: typische Baseline
• σ: Streuung (Burst-Charakteristik)
• k: Sicherheitsfaktor (z. B. 3–5)

Pflicht-Control 8: Spanning Tree Hardening (Edge schützen, Loops verhindern)

Spanning Tree (STP) ist weiterhin relevant, selbst in Netzen mit modernen Fabrics, weil Access-Edge und Fehlverkabelung Loops verursachen können. STP-Hardening soll verhindern, dass Edge-Geräte die Root-Rolle beeinflussen oder dass Loops unkontrolliert eskalieren.

• PortFast/Edge: Nur auf echten Endgeräteports aktivieren.
• BPDU Guard: Auf Edge-Ports, damit ein angeschlossener Switch nicht unbemerkt STP spricht.
• Root Guard: Dort, wo Root niemals „von außen“ kommen darf (z. B. Access-Uplinks).
• Loop Guard: Schutz gegen unidirektionale Link-Probleme, die STP-Blocking aushebeln können.
• Topology Change Monitoring: TCN-Spikes sind oft ein Frühindikator für Loop-/Patch-Probleme.

Pflicht-Control 9: VLAN-Trunk-Hardening und VLAN-Segmentierungsregeln

Viele Layer-2-Incidents entstehen nicht durch „Hacker“, sondern durch VLAN-Fehlzuweisungen und zu großzügige Trunks. Eine harte VLAN-Policy reduziert Blast Radius und verhindert Nebenwege.

• Allowed VLANs restriktiv: Nur notwendige VLANs auf jedem Trunk.
• Native VLAN standardisieren: Idealerweise ein ungenutztes VLAN als Native; keine User-VLANs als Native.
• DTP deaktivieren: Dynamisches Trunking vermeiden, Trunks explizit konfigurieren.
• VLAN-Tagging prüfen: Regelmäßige Validierung, dass Tagging auf beiden Seiten konsistent ist.

Pflicht-Control 10: IPv6-L2-Schutz (RA Guard/ND-Policies) – wenn Dual Stack aktiv ist

Wenn IPv6 im LAN verfügbar ist, brauchen Sie einen Mindestschutz gegen Rogue Router Advertisements und ND-Manipulation. In Dual-Stack-Umgebungen fällt IPv6-Problematik oft erst auf, wenn einzelne Apps „komisch“ reagieren. Deshalb gehört IPv6-Hardening in die Pflichtliste – oder IPv6 muss bewusst deaktiviert/unterbunden werden, wenn es nicht betrieben wird.

• RA Guard: Edge-Ports gegen unerwartete RAs schützen (Herstellerverhalten vorher testen).
• Trusted Ports: Nur definierte Infrastrukturports dürfen legitime RAs/ND-Events auslösen.
• Monitoring: Alerts auf neue Router im Segment, RA-Frequenz, ND-Storms.

Für Neighbor Discovery als Grundlage lohnt der Blick in RFC 4861.

Pflicht-Control 11: Layer-2-Telemetrie und Alarme (ohne Blindflug kein Hardening)

Ein L2-Control ist nur so gut wie die Fähigkeit, dessen Wirkung zu sehen. Für Enterprise-LANs sollte ein Minimalset an Metriken und Logs als Pflicht gelten – idealerweise zentral gesammelt (SIEM/Logging) und im NOC sichtbar.

• Errdisable/Port-Violation Events: Port Security, BPDU Guard, UDLD/Link-Mechanismen (plattformabhängig).
• DHCP Snooping Drops: Drops pro VLAN/Port, Binding-Table-Status, Rate-Limit-Events.
• DAI Drops: Invalid ARP, Rate-Limit, Trust-Fehler, Top Offenders.
• STP Events: Topology Changes, Root Changes, Port Role Changes.
• MAC-Flapping: MAC Moves zwischen Ports sind häufig ein Rogue-Switch- oder Loop-Indiz.
• Storm Control Hits: Broadcast/Multicast/Unknown-Unicast Drosselung.

Als allgemeiner Rahmen für Incident Handling, Evidence und Rollen ist NIST SP 800-61 eine etablierte Referenz, die sich gut für Runbooks und Response-Prozesse eignet.

Pflicht-Control 12: Betriebs- und Rollout-Disziplin (damit Hardening nicht selbst zum Outage wird)

In der Realität scheitert L2-Hardening selten am Feature – sondern am Rollout. Ein minimaler, aber strikter Prozess ist deshalb Teil der Checkliste. Das ist besonders wichtig, weil L2-Controls häufig in Serie ausgerollt werden (z. B. DHCP Snooping → DAI → IP Source Guard).

• Pre-Check: Topologie klar? Trusted Ports dokumentiert? Statische IPs inventarisiert? VoIP/IoT berücksichtigt?
• Pilot: Kleines VLAN oder kleiner Standort; vorher definierte Erfolgskriterien (z. B. DHCP Success Rate, Drop Counter).
• Change Window: Planbar, mit Kommunikationsweg und On-Call-Bereitschaft.
• Rollback: Automatisierbar oder als „Copy/Paste“-Runbook; getestet, nicht nur „theoretisch“.
• Ausnahmen mit Ablaufdatum: Jede Ausnahme braucht Owner, Begründung und Review-Termin.

Praktische Mini-Checkliste: L2-Pflicht-Controls nach Porttyp

Um die Umsetzung zu vereinfachen, hilft eine porttypbasierte Sicht. Die konkrete Syntax ist herstellerabhängig, die Logik bleibt gleich.

• User-Edge: 802.1X/MAB, DHCP Snooping (untrusted), DAI (untrusted), optional IP Source Guard, Port Security (tuned), BPDU Guard, Storm Control.
• Voice+Data: Wie User-Edge, aber MAC-Limits/Policies an VoIP anpassen; DHCP-Optionen und Multicast berücksichtigen.
• IoT/OT: NAC-Strategie (Profiling), restriktive VLAN-Zuordnung, Snooping/DAI sorgfältig testen (statische IPs häufig), Port Security konservativ.
• AP-Uplink: Trunk-Hardening (allowed VLANs), kein Edge-STP-Guard wie BPDU Guard, dafür klare Root/Loop-Guards je Design; DHCP Snooping meist trusted Richtung Client-VLANs abhängig vom Pfad.
• Switch-Uplink: Striktes Trunking, STP-Design-Regeln, keine Edge-Controls; Trust-Definitionen konsistent.

Weiterführende Quellen (Outbound Links)

Für Protokollgrundlagen und Standards bieten die folgenden Quellen einen stabilen Einstieg: Der RFC Editor für Netzwerkprotokolle, RFC 826 (ARP) für ARP-Grundlagen, RFC 4861 (IPv6 Neighbor Discovery) für ND/RA, sowie NIST SP 800-61 für Incident-Response-Struktur, die sich gut mit L2-Runbooks und NOC/SecOps-Prozessen verbinden lässt.

Cisco Netzwerkdesign, CCNA Support & Packet Tracer Projekte

Cisco Networking • CCNA • Packet Tracer • Network Configuration

Ich biete professionelle Unterstützung im Bereich Cisco Computer Networking, einschließlich CCNA-relevanter Konfigurationen, Netzwerkdesign und komplexer Packet-Tracer-Projekte. Die Lösungen werden praxisnah, strukturiert und nach aktuellen Netzwerkstandards umgesetzt.

Diese Dienstleistung eignet sich für Unternehmen, IT-Teams, Studierende sowie angehende CCNA-Kandidaten, die fundierte Netzwerkstrukturen planen oder bestehende Infrastrukturen optimieren möchten. Finden Sie mich auf Fiverr.

Leistungsumfang:

• Netzwerkdesign & Topologie-Planung

• Router- & Switch-Konfiguration (Cisco IOS)

• VLAN, Inter-VLAN Routing

• OSPF, RIP, EIGRP (Grundlagen & Implementierung)

• NAT, ACL, DHCP, DNS-Konfiguration

• Troubleshooting & Netzwerkoptimierung

• Packet Tracer Projektentwicklung & Dokumentation

• CCNA Lern- & Praxisunterstützung

Lieferumfang:

• Konfigurationsdateien

• Packet-Tracer-Dateien (.pkt)

• Netzwerkdokumentation

• Schritt-für-Schritt-Erklärungen (auf Wunsch)

Arbeitsweise:Strukturiert • Praxisorientiert • Zuverlässig • Technisch fundiert

CTA:
Benötigen Sie professionelle Unterstützung im Cisco Networking oder für ein CCNA-Projekt?
Kontaktieren Sie mich gerne für eine Projektanfrage oder ein unverbindliches Gespräch. Finden Sie mich auf Fiverr.