Site icon bintorosoft.com

11.8 Sicherheitsaspekte bei NETCONF und RESTCONF verstehen

bintorosoft@gmail.com

It engineer overseeing network rack servers in a large-scale data center. Generative AI

NETCONF und RESTCONF eröffnen leistungsfähige Möglichkeiten für die moderne Netzwerkautomatisierung, weil sie Konfigurations- und Statusdaten strukturiert, modellgetrieben und API-fähig bereitstellen. Genau diese Stärke bringt jedoch auch besondere Sicherheitsanforderungen mit sich. Sobald Netzwerkgeräte nicht nur manuell per CLI, sondern zusätzlich über standardisierte Management-Protokolle angesprochen werden, erweitert sich die Angriffsfläche. Authentifizierung, Autorisierung, Transportverschlüsselung, Zugriffskontrolle, Protokollhärtung und sichere Betriebsprozesse werden damit zu zentralen Themen. Für Network Engineers reicht es deshalb nicht aus, NETCONF und RESTCONF nur funktional zu verstehen. Ebenso wichtig ist das Verständnis dafür, wie diese Protokolle sicher aktiviert, geschützt, überwacht und in das bestehende Security- und Change-Management eingebettet werden.

Warum Sicherheit bei NETCONF und RESTCONF besonders wichtig ist

Management-Zugänge sind immer hochkritisch

NETCONF und RESTCONF sind keine gewöhnlichen Anwendungsprotokolle. Sie greifen direkt auf Management-Funktionen von Routern, Switches, Firewalls oder Wireless-Komponenten zu. Wer über diese Schnittstellen autorisierten Zugriff erhält, kann Konfigurationen lesen, ändern, löschen oder Betriebszustände auswerten. Damit gehören diese Protokolle zu den sensibelsten Diensten im gesamten Netzwerk.

Aus Angreifersicht sind Management-APIs deshalb besonders attraktiv. Aus Betreiberperspektive müssen sie mindestens denselben Schutz erhalten wie SSH, AAA oder Out-of-Band-Management.

Mehr Automatisierung bedeutet mehr systematische Reichweite

Ein weiterer Punkt ist die Skalierung. Ein kompromittierter lokaler CLI-Zugang betrifft oft zunächst nur ein einzelnes Gerät. Eine kompromittierte Automatisierungsinstanz oder ein zu weit berechtigter API-Account kann dagegen Änderungen auf viele Geräte gleichzeitig auslösen. Dadurch steigt nicht nur der Komfort für Administratoren, sondern auch das potenzielle Schadensausmaß bei Fehlkonfiguration, Missbrauch oder Credential-Leak.

Grundlegende Sicherheitsunterschiede zwischen NETCONF und RESTCONF

NETCONF arbeitet typischerweise über SSH

NETCONF wird in der Praxis meist über SSH transportiert. Das ist sicherheitstechnisch ein Vorteil, weil SSH in Netzwerkumgebungen etabliert ist und bewährte Mechanismen für Authentifizierung, Verschlüsselung und Sitzungsaufbau bietet. Wird NETCONF aktiviert, baut es auf diesen SSH-Schutzmechanismen auf.

Typische Cisco-Grundaktivierung:

conf t
netconf-yang
end

Zusätzlich relevant für das Management-Umfeld:

ip domain-name example.local
crypto key generate rsa modulus 2048
ip ssh version 2

Damit ist NETCONF jedoch noch nicht automatisch sicher. Es nutzt zwar SSH als Transport, muss aber trotzdem sauber in AAA, Zugriffskontrolle und Monitoring eingebunden werden.

RESTCONF arbeitet typischerweise über HTTPS

RESTCONF wird üblicherweise über HTTPS bereitgestellt. Dadurch greifen die Sicherheitsanforderungen klassischer Web-APIs: TLS-Konfiguration, Zertifikatsmanagement, HTTP-Methodenkontrolle, Rollenmodell und Schutz gegen unsichere Webserver-Konfigurationen. RESTCONF ist damit oft stärker in allgemeine API- und Websecurity-Fragestellungen eingebettet.

Typische Cisco-Aktivierung:

conf t
ip http secure-server
restconf
end

Die Aktivierung von ip http secure-server macht deutlich: RESTCONF ist eng an den HTTPS-Dienst des Geräts gekoppelt. Dadurch wird die Qualität der TLS- und Zertifikatskonfiguration unmittelbar sicherheitsrelevant.

Schutz des Management-Zugangs als erste Verteidigungslinie

Management nie ungeschützt im Produktionsnetz exponieren

Eine der wichtigsten Sicherheitsregeln ist, NETCONF und RESTCONF niemals unkontrolliert aus breiten Produktions- oder Benutzersegmenten erreichbar zu machen. Management-Protokolle gehören in dedizierte Management-Netze, Out-of-Band-Segmente oder klar definierte Admin-Zonen. Ein Gerät, dessen NETCONF- oder RESTCONF-Endpunkt aus beliebigen Netzbereichen erreichbar ist, erhöht die Angriffsfläche unnötig.

Typische CLI-Maßnahmen für restriktiven Zugriff können je nach Plattform so aussehen:

ip access-list standard MGMT-API-ACL
 permit 10.20.30.0 0.0.0.255
 deny any

In der Praxis wird diese Zugriffsbeschränkung durch Interface-ACLs, Control-Plane-Policies oder vorgeschaltete Firewalls ergänzt.

SSH- und HTTPS-Zugriff konsequent absichern

Da NETCONF meist über SSH und RESTCONF über HTTPS arbeitet, muss die Sicherheit dieser zugrunde liegenden Protokolle aktiv gehärtet werden. Unsichere oder veraltete Einstellungen auf Transportebene schwächen unmittelbar auch die API-Sicherheit.

Beispielhafte SSH-Härtung:

ip ssh version 2
line vty 0 4
 transport input ssh
 exec-timeout 10 0
 login local

Für RESTCONF ist zusätzlich wichtig, dass kein unsicherer HTTP-Zugang parallel offen bleibt, wenn dies nicht zwingend benötigt wird.

Authentifizierung und Autorisierung richtig umsetzen

AAA als Pflichtbestandteil für API-Zugriffe

NETCONF und RESTCONF sollten niemals auf lokal zusammengeklickten Minimal-Accounts ohne zentrales Berechtigungskonzept basieren. Beide Protokolle müssen in ein sauberes AAA-Modell eingebettet sein, idealerweise mit TACACS+ oder RADIUS und klaren Rollen. Gerade bei Automatisierung ist nachvollziehbar zu steuern, wer lesen darf, wer schreiben darf und welche Aktionen erlaubt sind.

CLI-Beispiel für AAA-Grundlogik:

aaa new-model
aaa authentication login default group tacacs+ local
aaa authorization exec default group tacacs+ local

Je nach Plattform und AAA-Design können weitere Autorisierungsebenen relevant sein, etwa Command Authorization oder API-bezogene Rollenprofile.

Service-Accounts nicht mit Vollrechten ausstatten

Ein häufiger Fehler in Automatisierungsprojekten ist der Einsatz überprivilegierter Service-Accounts. Ein Account, der für einfache Read-Only-Compliance-Scans verwendet wird, darf keine produktiven Write-Rechte auf allen Geräten besitzen. Ebenso sollte ein Automatisierungsaccount für Syslog- oder NTP-Anpassungen nicht automatisch vollständige Administratorrechte für alle Konfigurationsbereiche erhalten.

Je feiner die Trennung zwischen Rollen und Aufgaben, desto geringer das Risiko bei kompromittierten Zugangsdaten.

Schutz sensibler Zugangsdaten und Tokens

Credentials niemals im Klartext in Skripten speichern

NETCONF- und RESTCONF-Automatisierung wird oft über Python-Skripte, Playbooks, Pipelines oder Plattformen angesteuert. Genau dort entsteht ein kritischer Sicherheitsbereich: die sichere Verwaltung von Zugangsdaten. API- oder SSH-Credentials im Klartext in Skripten, Git-Repositories oder lokalen Config-Dateien sind ein gravierendes Risiko.

Das gilt auch dann, wenn die Automatisierung nur in einem internen Netz betrieben wird. Interne Leaks sind in der Praxis ebenso gefährlich wie externe Angriffe.

Zertifikate und Schlüssel sicher behandeln

Bei RESTCONF spielt zusätzlich das Zertifikatsmanagement eine zentrale Rolle. Unsichere Zertifikatsprüfung, selbstsignierte Zertifikate ohne Vertrauenskette oder dauerhaft ignorierte TLS-Warnungen schaffen eine unnötige Angriffsfläche für Man-in-the-Middle-Szenarien.

Gerade in Dev- oder Lab-Umgebungen entsteht oft schlechte Gewohnheit, Zertifikatsvalidierung dauerhaft zu umgehen. In produktiven Netzen ist das nicht akzeptabel.

Feingranulare Zugriffskontrolle auf Netzwerkgeräten

Read-Only und Read-Write sauber trennen

Ein wichtiges Sicherheitsprinzip besteht darin, Auslese- und Änderungszugriffe voneinander zu trennen. Viele Anwendungsfälle wie Inventarisierung, Reporting oder Compliance benötigen nur Leserechte. Diese Prozesse sollten nicht mit Konten laufen, die komplette Konfigurationsänderungen durchführen dürfen.

Dieses Prinzip reduziert das Risiko bei kompromittierten Konten und macht Audits nachvollziehbarer.

Geräte- und Bereichsgrenzen berücksichtigen

Nicht jede Automatisierung muss auf alle Geräte zugreifen. Ebenso muss nicht jeder Account alle Konfigurationsbereiche ändern dürfen. In reifen Umgebungen werden Rechte zusätzlich nach Gerätetyp, Standort, Rolle oder Funktionsbereich eingeschränkt.

Je präziser die Segmentierung, desto besser lässt sich die Angriffsoberfläche begrenzen.

Absicherung von RESTCONF-spezifischen Risiken

HTTPS-Dienst nicht wie einen normalen Webserver behandeln

RESTCONF basiert auf HTTPS, was manche Teams dazu verleitet, den Dienst eher als komfortable Zusatzfunktion denn als kritischen Management-Endpunkt zu betrachten. Tatsächlich ist ein aktivierter RESTCONF-Endpunkt eine hochprivilegierte API-Schnittstelle. Deshalb muss die Aktivierung des HTTPS-Dienstes mit derselben Sorgfalt behandelt werden wie der Aufbau eines SSH-basierten Admin-Zugangs.

Ein Gerät, das RESTCONF nutzt, sollte keinen unnötigen Web-Funktionsumfang bereitstellen, der über die Management-Anforderung hinausgeht.

API-Aufrufe gegen Missbrauch schützen

RESTCONF folgt einem API-nahen Modell mit URI-Pfaden und HTTP-Methoden. Daraus ergibt sich die Notwendigkeit, Missbrauch sauber zu begrenzen. Besonders relevant sind falsch berechtigte Clients, ungewollte Schreiboperationen und unkontrollierte Integrationen aus Drittsystemen.

Je stärker RESTCONF in Plattformen oder Self-Service-Prozesse eingebunden wird, desto wichtiger werden Freigabelogik und Rollenmodell.

Absicherung von NETCONF-spezifischen Risiken

NETCONF-Sitzungen wie privilegierte SSH-Zugriffe behandeln

NETCONF nutzt typischerweise SSH und sollte sicherheitstechnisch wie ein hochprivilegierter SSH-Zugang behandelt werden. Es genügt nicht, SSH nur allgemein zu aktivieren. Auch NETCONF-spezifische Sitzungen müssen nachvollziehbar, begrenzt und auditiert sein.

Zur Sichtbarkeit können je nach Plattform Befehle wie diese helfen:

show netconf-yang sessions
show users
show aaa sessions

Dadurch wird sichtbar, welche Management-Sitzungen aktiv sind und ob NETCONF-Verbindungen nachvollziehbar erscheinen.

Candidate- und Commit-Mechanismen sicher in Change-Prozesse einbetten

NETCONF bietet mit Candidate, Validate und Commit mächtige Funktionen für kontrollierte Änderungen. Diese Mechanismen erhöhen die technische Sicherheit, ersetzen aber kein sauberes Freigabe- und Berechtigungsmodell. Wer committen darf, besitzt potenziell große operative Macht. Deshalb müssen technische Möglichkeiten immer mit organisatorischer Kontrolle kombiniert werden.

Gerade in produktiven Netzen ist nicht nur entscheidend, ob ein Commit technisch möglich ist, sondern ob er kontrolliert, autorisiert und nachvollziehbar ausgelöst wurde.

Logging, Monitoring und Auditierbarkeit

API- und Management-Zugriffe lückenlos protokollieren

Ein zentrales Sicherheitselement für NETCONF und RESTCONF ist die Nachvollziehbarkeit. Jede Session, jede Änderung und jeder fehlgeschlagene Zugriff sollte möglichst protokolliert werden. Nur so lassen sich Vorfälle analysieren, Fehlbedienungen zuordnen und unautorisierte Aktivitäten erkennen.

Typische CLI-Grundlagen:

logging host 10.20.20.20
logging host 10.20.20.21
service timestamps log datetime msec

Die Wirksamkeit dieser Maßnahmen steigt erheblich, wenn Logs zentral gesammelt, korreliert und alarmiert werden.

Monitoring auf Management-Schnittstellen erweitern

Nicht nur produktive Datenpfade, auch Management-Schnittstellen sollten aktiv überwacht werden. Auffällige Login-Muster, ungewöhnliche Session-Zahlen, unerwartete Schreibzugriffe oder Änderungen außerhalb genehmigter Zeitfenster können Indikatoren für Missbrauch oder Fehlkonfiguration sein.

Management-Security endet nicht bei ACL und Passwort, sondern umfasst auch detektive Kontrollen.

Härtung der Geräte und Dienste

Nur benötigte Dienste aktivieren

Ein oft unterschätzter Sicherheitsgrundsatz lautet: Aktivieren Sie nur, was wirklich genutzt wird. Wenn NETCONF oder RESTCONF auf bestimmten Geräten nicht benötigt werden, sollten die Dienste dort deaktiviert bleiben. Jede unnötig aktive Management-Funktion vergrößert die Angriffsfläche.

Das betrifft auch Altlasten wie Telnet oder ungesicherte Legacy-Managementprotokolle, die parallel zu modernen Schnittstellen nicht weiter offen bleiben dürfen.

Geräte regelmäßig patchen und Softwarestände bewerten

Wie bei jedem Managementdienst hängt die Sicherheit auch von der Softwarequalität der Plattform ab. Schwachstellen in SSH, HTTP-Stacks, API-Implementierungen oder YANG/NETCONF/RESTCONF-Komponenten können direkt ausnutzbar sein. Deshalb sind regelmäßige Softwarepflege und Schwachstellenbewertung essenziell.

Ein sicher konfigurierter, aber verwundbarer Softwarestand bleibt ein Risiko.

Sichere Betriebsprozesse für Automatisierung

Change-Management und Freigaben nicht umgehen

API-basierte Automatisierung darf nicht dazu führen, dass produktive Änderungen informell und außerhalb geregelter Prozesse erfolgen. Gerade weil NETCONF und RESTCONF technisch so effizient sind, besteht die Gefahr, dass Changes ohne ausreichende Prüfung angestoßen werden. Sicherheit bedeutet daher auch, Automatisierung sauber in bestehende Change- und Freigabelogik einzubetten.

Technische Kontrolle und organisatorische Governance müssen zusammenarbeiten.

Test, Staging und Produktion trennen

API- und Automatisierungslogik sollte nie direkt und ungeprüft in der Produktion entstehen. Saubere Umgebungsgrenzen sind ein wichtiger Sicherheitsfaktor. Skripte, Playbooks oder Plattformintegrationen sollten zunächst in Test- oder Staging-Umgebungen gegen repräsentative Geräte validiert werden.

So werden Fehlkonfigurationen und Sicherheitsprobleme deutlich früher sichtbar.

Typische Sicherheitsfehler in der Praxis

RESTCONF oder NETCONF einfach „mit aktivieren“

Ein häufiger Fehler ist die unkritische Aktivierung moderner Management-Protokolle, weil sie für Automatisierung nützlich erscheinen. Ohne begleitende ACLs, AAA, Logging, Zertifikate und Rollenmodell entsteht daraus jedoch schnell eine unnötige Schwachstelle.

Gleiche Konten für Mensch und Automatisierung

Ebenfalls problematisch ist die Nutzung derselben privilegierten Konten für manuelle Administration und Automatisierung. Dadurch sinkt die Nachvollziehbarkeit und das Risiko breiter Kompromittierung steigt.

Fehlende Trennung zwischen Read und Write

Viele Umgebungen geben aus Bequemlichkeit identische Rechte für Read-Only-Scans und produktive Write-Prozesse. Das widerspricht dem Prinzip minimaler Rechte und vergrößert das Schadenspotenzial bei kompromittierten Tools oder Credentials.

Best Practices für sichere NETCONF- und RESTCONF-Nutzung

Wer diese Sicherheitsaspekte konsequent berücksichtigt, macht aus NETCONF und RESTCONF keine zusätzliche Schwachstelle, sondern gut kontrollierte Werkzeuge für einen sicheren, modernen und automatisierten Netzwerkbetrieb. Gerade weil diese Protokolle so leistungsfähig sind, müssen sie mit derselben Sorgfalt geschützt werden wie jeder andere hochprivilegierte Management-Zugang im Netzwerk.

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:

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

Exit mobile version