Control-Plane, Data-Plane, Management-Plane: Hardening-Ansatz in der Praxis

Ein praxistaugliches Router-Hardening trennt konsequent drei Ebenen: Management-Plane (Zugriff auf das Gerät), Control-Plane (Routing/Steuerprotokolle und CPU-Traffic) und Data-Plane (Transit-Traffic durch den Router). Viele Sicherheitsprobleme entstehen, weil diese Ebenen vermischt werden: Management ist aus dem ganzen Netz erreichbar, Control-Plane wird von Scans/Floods überlastet, oder Data-Plane-Policies sind unübersichtlich. Der folgende Ansatz zeigt, wie du die drei Planes sauber strukturierst und mit Cisco-IOS-Mitteln umsetzt.

Die drei Planes kurz und klar definiert

Die Ebenen unterscheiden sich danach, ob der Router Ziel eines Pakets ist oder es nur weiterleitet. Genau diese Unterscheidung bestimmt, welche Schutzmechanismen greifen.

• Management-Plane: Admin-Zugriffe (SSH, SNMP, Syslog, NTP, API/Netconf)
• Control-Plane: Steuerverkehr zur CPU (OSPF/BGP, ICMP an Router-IP, ARP/ND)
• Data-Plane: Nutztraffic, der geroutet/geschaltet wird (Transit)

Merker

$\text{Router als Ziel} \to \text{Management/Control}, \text{Router als Transit} \to \text{Data}$

Hardening-Strategie: Layering statt „eine große ACL“

In der Praxis funktioniert ein „Defense in Depth“-Modell am besten: Du begrenzt zuerst, wer überhaupt an Management und Control-Plane herankommt. Danach definierst du Data-Plane-Policies (Segmentierung). So bleibt jede Ebene verständlich und auditierbar.

• Management: strengste Regeln, kleinster Scope
• Control: nur notwendige Protokolle, Rate-Limits
• Data: Zonen/ACLs nach Business-Need, nicht nach „alles blocken“

Management-Plane Hardening: Zugriff minimieren und absichern

Management sollte nur aus einem dedizierten Admin-Netz erreichbar sein, ausschließlich über sichere Protokolle und möglichst zentral authentifiziert. Ziel ist: kein Management aus User-/Guest-/Internet-Zonen.

• SSH-only, Telnet aus
• VTY ACL (access-class) auf Admin-Netze
• AAA (TACACS+/RADIUS) + lokaler Break-Glass-User
• Timeouts, Retries und Brute-Force-Block
• SNMP bevorzugt v3, Zugriff per ACL

Beispiel: SSHv2 + VTY ACL + Timeout

ip ssh version 2
ip ssh time-out 60
ip ssh authentication-retries 2
ip access-list standard VTY_MGMT

permit 10.255.0.0 0.0.255.255

deny any
line vty 0 15

login local

transport input ssh

access-class VTY_MGMT in

exec-timeout 10 0

Beispiel: SNMPv3 mit ACL

ip access-list standard SNMP_MGMT
 permit 10.255.0.20
 deny any
snmp-server group NMS v3 priv access SNMP_MGMT

snmp-server user nmsuser NMS v3 auth sha Str0ngAuthP@ss priv aes 128 Str0ngPrivP@ss

Control-Plane Hardening: CoPP/CPPr und Protokollhygiene

Die Control-Plane ist die CPU. Wenn sie überlastet wird, leiden Routing, Management und manchmal indirekt Forwarding. Ziel ist: nur legitimen Control-Traffic zulassen und Floods/Scans begrenzen.

• CoPP/CPPr: klassifizieren und rate-limitieren
• Routing-Protokolle nur von erwarteten Peers erlauben
• ICMP zur Router-IP begrenzen (nicht vollständig blocken)
• Control-Plane-Logs/Counter überwachen

Beispiel: CoPP-Prinzip (vereinfacht)

class-map match-any CM_CP_SSH
 match protocol ssh
class-map match-any CM_CP_ICMP

match protocol icmp
policy-map PM_COPP

class CM_CP_SSH

police 64000 conform-action transmit exceed-action drop

class CM_CP_ICMP

police 32000 conform-action transmit exceed-action drop

class class-default

police 16000 conform-action transmit exceed-action drop
control-plane

service-policy input PM_COPP

Control-Plane Verifikation

show policy-map control-plane
show processes cpu sorted

Data-Plane Hardening: Segmentierung und klare Policy-Grenzen

Die Data-Plane ist der Transit-Traffic. Hier geht es um Segmentierung: welche Netze dürfen miteinander sprechen, welche Ports sind nötig, und wo setzt du Policies sinnvoll an. Best Practice ist, Policies an Zonen-/Grenzstellen zu setzen (z. B. User → Server, Inside → Outside).

• Least Privilege zwischen VLANs/Subnetzen
• Default-Deny an kritischen Grenzen (z. B. Internet Edge inbound)
• NAT und Security getrennt denken (NAT ist keine Firewall)
• Zonen-Firewall (ZBF) bei komplexen Policies

Beispiel: Inbound Outside-ACL (Default-Deny)

ip access-list extended OUTSIDE_IN
 permit udp host 198.51.100.2 host 203.0.113.2 eq 500
 permit udp host 198.51.100.2 host 203.0.113.2 eq 4500
 permit esp host 198.51.100.2 host 203.0.113.2
 deny ip any any log
interface gigabitEthernet0/1

ip access-group OUTSIDE_IN in

Beispiel: uRPF gegen Source-IP-Spoofing (wo passend)

interface gigabitEthernet0/1
 ip verify unicast source reachable-via rx

Praktisches Pattern: Management über Loopback und dediziertes VRF/Netz

In größeren Netzen wird Management oft über eine Loopback-IP und ein separates Management-Netz (oder Management-VRF) geführt. Das erleichtert ACLs, Logging-Quellen und verhindert, dass User-VLANs „zufällig“ Management erreichen.

• Loopback0 als stabile Management-Source
• Syslog/SNMP/NTP Source-Interface konsistent
• ACLs erlauben nur NMS/Jump Hosts

Beispiel: Syslog mit Source-Interface

service timestamps log datetime msec localtime
logging host 10.255.0.20
logging source-interface loopback0
logging trap warnings

Typische Pitfalls: Wo Hardening in der Praxis scheitert

Diese Fehler tauchen regelmäßig in Audits und Incidents auf, weil sie oft „aus Bequemlichkeit“ passieren oder weil Planes vermischt werden.

• Management aus allen VLANs erreichbar (keine VTY ACL, kein Mgmt-Netz)
• Telnet/SNMPv2c ohne ACL (Credentials im Klartext)
• Keine CoPP: ICMP/Scan-Floods legen CPU lahm
• ACL-Spaghetti: unklare Regeln, Lockouts, schweres Troubleshooting
• NAT als Security missverstanden (offene Services ohne Outside-ACL)

Verifikation: So prüfst du jede Plane schnell

Eine Hardening-Änderung ist nur so gut wie ihre Verifikation. Prüfe gezielt Management-Zugänge, Control-Plane-Counters und Data-Plane-Policies.

Management-Plane prüfen

show ip ssh
show running-config | section line vty
show access-lists VTY_MGMT
show snmp user

Control-Plane prüfen

show policy-map control-plane
show processes cpu sorted

Data-Plane prüfen

show ip access-lists
show ip nat translations
show ip route

Konfiguration speichern

Router# copy running-config startup-config

Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab (CCNA)

Hallo! Ich bin ein CCNA-Network Engineer und unterstütze Sie bei Cisco Router- und Switch-Konfigurationen – inklusive eines vollständigen Cisco Packet-Tracer-Labs (.pkt). Ideal für Lern-/Übungsszenarien, Validierung oder eine saubere Demo-Topologie.

Was ich (je nach Paket) umsetze

• Switching: VLANs, Trunking (802.1Q), Port-Zuweisung, STP-Basics (PortFast/BPDU Guard wo sinnvoll)

• Routing: Default/Static Routing oder OSPF, Inter-VLAN Routing (Router-on-a-Stick)

• Services: DHCP (Pools/Scopes), NAT/PAT für Internet-Simulation

• Optional Security: Basic ACLs und SSH-Hardening

• Test & Verifikation: Ping/Traceroute + wichtige Show-Commands (mit erwarteten Ergebnissen)

Sie erhalten

• ✅ Packet Tracer .pkt Datei

• ✅ Saubere Konfigurations-Notizen pro Gerät

• ✅ Verifikations-Checkliste + erwartete Outputs

• ✅ Kurze Dokumentation (wie die Topologie funktioniert)

Bitte schreiben Sie mir vor der Bestellung, damit wir Scope, Packet-Tracer-Version, Geräteanzahl und Deadline klären.

Konfiguriere Cisco Router & Switches | Cisco Packet-Tracer-Labs. Finden Sie mich auf Fiverr.