Site icon bintorosoft.com

20.2 Passwort- oder Banner-Änderungen auf vielen Geräten automatisieren

bintorosoft@gmail.com

Passwort- oder Banner-Änderungen auf vielen Geräten zu automatisieren gehört zu den praxisnahesten Anwendungsfällen der Netzwerkautomatisierung, weil hier ein klarer betrieblicher Bedarf auf eine stark wiederkehrende Aufgabe trifft. Kaum ein Netzwerk bleibt dauerhaft unverändert: rechtliche Hinweise im Login-Banner werden aktualisiert, interne Sicherheitsrichtlinien ändern sich, lokale Zugangsdaten müssen rotiert werden oder Standardtexte sollen auf allen Routern und Switches vereinheitlicht werden. Genau an dieser Stelle zeigt Automatisierung ihren Nutzen besonders deutlich. Eine Aufgabe, die auf einem einzelnen Gerät banal wirkt, wird auf dutzenden oder hunderten Systemen schnell zeitaufwendig, fehleranfällig und schwer nachzuvollziehen. Für Network Engineers ist dieses Thema zudem besonders lehrreich, weil es mehrere Kernbereiche moderner Netzwerkarbeit verbindet: Standardisierung, Inventardaten, kontrollierte Rollouts, Verifikation, Versionsverwaltung und den bewussten Umgang mit sicherheitsrelevanten Änderungen. Gerade deshalb sollten Passwort- oder Banner-Anpassungen nicht als bloßes Massensenden von Befehlen verstanden werden, sondern als strukturierter und prüfbarer Change-Prozess.

Warum sich gerade diese Änderungen gut für Automatisierung eignen

Wiederkehrende Standardaufgaben mit hoher Reichweite

Automatisierung lohnt sich besonders dort, wo Aufgaben standardisierbar sind und regelmäßig wiederkehren. Genau das trifft auf Banner- und Passwort-nahe Änderungen oft zu. Der Text eines Login-Banners ist in der Regel für ganze Gerätegruppen identisch oder unterscheidet sich nur geringfügig. Auch lokale Zugangsdaten oder standardisierte Secret-Werte werden häufig nicht auf einem einzelnen Gerät, sondern auf vielen Systemen gleichzeitig angepasst.

Damit ist der Anwendungsfall ideal für Automatisierung: wenig inhaltliche Varianz, aber hoher manueller Aufwand ohne Tooling.

Manuelle Umsetzung erzeugt schnell Drift und Fehler

Wenn Änderungen auf vielen Geräten per Hand durchgeführt werden, entstehen typische Probleme. Einige Systeme werden vergessen, auf anderen bleibt der alte Zustand teilweise bestehen, und auf wieder anderen weicht der Text minimal vom Standard ab. Solche Unterschiede sind nicht nur unschön, sondern können betriebliche und sicherheitsrelevante Folgen haben.

Automatisierung reduziert diese Risiken, wenn sie sauber vorbereitet und kontrolliert ausgeführt wird.

Warum Banner-Änderungen meist der sicherere Einstieg sind

Banner beeinflussen nicht direkt den Zugriffsweg

Für erste schreibende Automatisierungsprojekte sind Banner-Änderungen besonders gut geeignet, weil sie zwar Konfiguration verändern, aber in der Regel nicht direkt den Managementzugang blockieren. Ein falsch formulierter Bannertext ist ärgerlich, führt aber meist nicht dazu, dass sich ein Team aussperrt. Genau deshalb sind Banner im Lab und in frühen produktionsnahen Automatisierungsprojekten oft der beste Startpunkt.

Gerade in Lernumgebungen ist dieser geringe operative Druck ein großer Vorteil.

Banner lassen sich sehr gut standardisieren

Ein Banner ist meist ein klar definierter Textblock. Dadurch eignet er sich hervorragend für eine zentrale Definition im Template oder in einer festen Standardkonfiguration. Ein kleines Beispiel für einen typischen CLI-Block ist:

conf t
banner motd ^Zugriff nur fuer autorisierte Benutzer. Alle Aktivitaeten werden protokolliert.^
end
write memory

Weil dieser Text oft auf vielen Geräten identisch sein soll, entsteht mit Automatisierung sofort ein klarer Mehrwert.

Warum Passwort-Änderungen deutlich sensibler sind

Passwortänderungen wirken direkt auf Sicherheit und Betrieb

Im Gegensatz zu Bannern betreffen Passwort-Änderungen unmittelbar die Authentifizierung. Genau das macht sie technisch und organisatorisch kritischer. Ein Fehler bei einer Passwortrotation kann den Zugriff auf Geräte erschweren oder im schlimmsten Fall verhindern. Deshalb müssen solche Änderungen deutlich vorsichtiger geplant und verifiziert werden.

Automatisierung ist hier besonders nützlich, aber nur dann, wenn sie diszipliniert eingesetzt wird.

Lokale Konten und zentrale AAA-Logik klar trennen

Bevor eine Passwortänderung automatisiert wird, muss klar sein, welche Authentifizierungslogik betroffen ist. Ein lokales Benutzerkonto auf dem Gerät ist etwas völlig anderes als ein zentral über TACACS+ oder RADIUS authentifizierter Zugriff. Für sichere und verständliche Automatisierungsprojekte sollte zunächst nur mit lokalen Lab- oder Testkonten gearbeitet werden.

Gerade im Lab ist diese Trennung didaktisch sehr wichtig.

Den Ziel-Change sauber definieren

Ohne klaren Soll-Zustand gibt es keine gute Automatisierung

Der wichtigste Vorbereitungsschritt ist nicht die Wahl des Tools, sondern die Definition des Zielzustands. Gute Netzwerkautomatisierung setzt klare Standards um, sie ersetzt sie nicht. Deshalb muss vor dem ersten Skriptlauf eindeutig feststehen, was geändert werden soll.

Je präziser diese Fragen beantwortet sind, desto robuster wird die Umsetzung.

Den Ausgangszustand bewusst prüfen

Vor einer Massenänderung sollte immer klar sein, welcher Zustand auf den Zielgeräten aktuell vorhanden ist. Das hilft, die Differenz zwischen Ist und Soll sichtbar zu machen und die spätere Verifikation sinnvoll zu gestalten.

Typische Pre-Checks können so aussehen:

show running-config | include banner
show running-config | include username
show running-config | include secret

Gerade bei Passwort-Änderungen ist diese Vorprüfung unverzichtbar.

Geräteauswahl und Inventardaten sauber vorbereiten

Die Zielgruppe darf nicht erraten werden

Ein häufiger Fehler bei Massenänderungen ist eine unklare oder zu breite Zielgeräteauswahl. Deshalb sollte der Rollout immer auf einer expliziten und gepflegten Inventarquelle basieren. Auch für kleine Umgebungen reicht dafür oft schon eine saubere YAML-Datei.

Ein einfaches Beispiel:

devices:
  - hostname: R1
    host: 192.0.2.101
    role: router
    device_type: cisco_ios
  - hostname: SW1
    host: 192.0.2.102
    role: switch
    device_type: cisco_ios

Diese Struktur schafft Klarheit darüber, welche Geräte überhaupt adressiert werden.

Rollen und Plattformen bewusst unterscheiden

Nicht jede Änderung gilt automatisch für jedes Gerät. In manchen Umgebungen sollen Banner auf allen Systemen identisch sein, während lokale Benutzer nur auf bestimmten Gerätetypen oder Testumgebungen angepasst werden. Genau deshalb sollte das Inventar nicht nur IP-Adressen, sondern auch Rolleninformationen enthalten.

Je sauberer diese Struktur im Inventar abgebildet ist, desto geringer ist das Risiko falscher Rollouts.

Mit einem kontrollierten Ein-Gerät-Test beginnen

Nie mit einem Vollrollout starten

Auch wenn die Änderung inhaltlich klein wirkt, sollte sie nie sofort auf alle Geräte verteilt werden. Gerade bei Passwort-Änderungen ist das besonders riskant. Der erste Test muss immer auf einem einzelnen, bewusst ausgewählten Gerät erfolgen. Danach sollte eine kleine Pilotgruppe folgen, bevor die gesamte Zielgruppe angepasst wird.

Diese Reihenfolge ist eine der wichtigsten Best Practices für jede schreibende Netzwerkautomatisierung.

Banner-Änderung auf einem Gerät per Skript testen

Ein einfaches Python-Beispiel mit Netmiko für eine Banner-Änderung könnte so aussehen:

from netmiko import ConnectHandler

device = {
    "device_type": "cisco_ios",
    "host": "192.0.2.101",
    "username": "admin",
    "password": "MeinPasswort123"
}

commands = [
    "banner motd ^Zugriff nur fuer autorisierte Benutzer. Alle Aktivitaeten werden protokolliert.^"
]

with ConnectHandler(**device) as conn:
    output = conn.send_config_set(commands)
    print(output)

Dieses Skript ist bewusst klein gehalten und eignet sich gut als erster schreibender Test im Lab oder in einer kontrollierten Pilotumgebung.

Passwortänderungen vorsichtig automatisieren

Mit lokalen Testkonten arbeiten

Für praktische Übungen und erste kontrollierte Rollouts sollten Passwortänderungen nur auf klar definierten lokalen Testkonten erfolgen. Damit bleibt das Risiko beherrschbar und die Wirkung lässt sich direkt nachvollziehen.

Ein einfacher lokaler Benutzer-Change kann zum Beispiel so aussehen:

conf t
username admin privilege 15 secret NeuesLabPasswort123
end
write memory

Wichtig ist, dass dieser Change nur dort eingesetzt wird, wo er explizit vorgesehen ist und nicht mit zentralen AAA-Mechanismen verwechselt wird.

Nach der Änderung den tatsächlichen Login testen

Bei Passwortänderungen reicht es nicht aus, nur die Running-Config zu prüfen. Die funktionale Verifikation ist mindestens genauso wichtig wie die technische Sichtbarkeit der Konfigurationszeile. Nach dem Change sollte aktiv getestet werden, ob der neue Zugang tatsächlich funktioniert.

Genau diese Verifikation unterscheidet einen sicheren Prozess von einer riskanten Massenänderung.

Templates einsetzen, wenn Änderungen variabel werden

Feste Befehlslisten reichen nicht immer aus

Solange Bannertext oder Zugangsdaten auf allen Zielgeräten identisch sind, reicht oft eine feste Befehlsliste. Sobald Werte aber je nach Rolle, Standort oder Umgebung variieren, ist ein Template deutlich sauberer. Gerade dann wird Templating zum logischen nächsten Schritt.

Ein einfaches Jinja2-Template für einen Banner könnte so aussehen:

banner motd ^{{ banner_text }}^

Oder für einen lokalen Benutzer:

username {{ username }} privilege 15 secret {{ secret_value }}

So bleibt die Konfigurationslogik standardisiert, während die eigentlichen Werte aus einer Datenquelle kommen.

Gerenderte Konfiguration zuerst prüfen

Bevor ein Template auf Geräte ausgerollt wird, sollte die generierte Ausgabe immer erst gerendert und manuell geprüft werden. Gerade bei Bannern mit Sonderzeichen oder Passwort-bezogenen Änderungen ist das besonders wichtig.

Diese Vorprüfung reduziert Fehler erheblich und sollte zum Standard werden.

Pre-Checks und Post-Checks fest in den Ablauf einbauen

Vor dem Change prüfen

Auch bei kleinen Standardänderungen sollten bewusste Pre-Checks durchgeführt werden. Sie helfen, den aktuellen Zustand zu erfassen und später Änderungen sauber zu verifizieren.

Typische Pre-Checks:

show running-config | include banner
show running-config | include username
show running-config | include secret

Diese Prüfungen sind schnell durchgeführt und fachlich äußerst wertvoll.

Nach dem Change prüfen

Nach dem Rollout müssen die Änderungen sowohl technisch als auch funktional überprüft werden. Bei Bannern ist die Konfigurationsprüfung meist ausreichend. Bei Passwortänderungen muss zusätzlich die tatsächliche Zugänglichkeit geprüft werden.

Typische Post-Checks:

show running-config | include banner
show running-config | include username

Diese Kombination aus CLI-Prüfung und Zugriffstest macht den Prozess belastbar.

Fehlerbehandlung und sichere Durchführung

Teilfehlschläge sichtbar machen

Ein Rollout auf viele Geräte wird nicht immer auf allen Systemen identisch funktionieren. Deshalb muss ein Skript oder Playbook Fehler sichtbar behandeln, statt sie stillschweigend zu übergehen. Besonders wichtig sind typische Verbindungs- und Authentifizierungsfehler.

Ein einfaches Python-Muster kann so aussehen:

from netmiko.exceptions import NetMikoTimeoutException, NetMikoAuthenticationException

try:
    with ConnectHandler(**device) as conn:
        output = conn.send_config_set(commands)
except NetMikoAuthenticationException:
    print(f"Authentifizierung fehlgeschlagen bei {device['hostname']}")
except NetMikoTimeoutException:
    print(f"Timeout bei {device['hostname']}")

Gerade bei Massenänderungen ist Transparenz über erfolgreiche und fehlgeschlagene Geräte entscheidend.

Mit Zugangsdaten diszipliniert umgehen

Bei Passwortänderungen ist der Umgang mit Secrets selbst ein kritischer Teil des Projekts. Auch im Lab sollte man sich daran gewöhnen, sensible Werte nicht unkontrolliert in mehreren Dateien, Screenshots oder ungeschützten Notizen zu verteilen.

Diese Disziplin im Lab erleichtert später sichere Praxis im echten Betrieb.

Typische Fehler bei solchen Massenänderungen

Zu viele Änderungen in einem Rollout bündeln

Ein häufiger Fehler ist, Banner, Passwörter, NTP, Logging und weitere Standards gleichzeitig in einem Change zu kombinieren. Für kontrollierte Automatisierung ist es besser, Änderungen thematisch klein zu halten. Ein Banner-Change und eine Passwortrotation sollten nicht ohne guten Grund in einem identischen Massenprozess vermischt werden.

Geräteauswahl nicht sauber prüfen

Wenn das Inventar unklar oder die Zielgruppe falsch gefiltert ist, kann der Rollout Geräte treffen, die gar nicht betroffen sein sollten. Gerade deshalb muss die Auswahl immer bewusst geprüft werden.

Nur auf Skriptausgabe statt auf Gerätezustand vertrauen

Ein erfolgreicher Skriptlauf ist kein Ersatz für den tatsächlichen Zustand auf dem Gerät. Bei Bannern und erst recht bei Passwortänderungen ist der reale Gerätezustand immer maßgeblich.

Keinen Rückweg einplanen

Auch kleine Standardchanges sollten mit einer Rückfalloption gedacht werden. Wenn ein Bannertext falsch gesetzt wurde oder ein Testzugang unerwartet problematisch ist, muss klar sein, wie der Zustand korrigiert werden kann.

Versionsverwaltung und nachvollziehbare Änderungspflege

Auch kleine Rollout-Projekte versionieren

Skripte, Templates, Inventardaten und Standardtexte sollten versioniert werden. Dadurch bleibt nachvollziehbar, wann welcher Bannertext oder welche Rollout-Logik eingeführt wurde.

Ein einfacher Git-Start kann so aussehen:

git init
git add .
git commit -m "Initialer Rollout fuer Banner- oder Passwort-Aenderungen"

Gerade bei sicherheitsrelevanten Änderungen ist diese Nachvollziehbarkeit sehr wertvoll.

Änderungen in kleinen Schritten entwickeln

Ein robuster Prozess entsteht nicht durch einen einzigen großen Wurf, sondern durch kleine, klar prüfbare Entwicklungsschritte.

Diese schrittweise Entwicklung ist im Lab und im Betrieb gleichermaßen sinnvoll.

Best Practices für automatisierte Passwort- oder Banner-Änderungen auf vielen Geräten

Passwort- oder Banner-Änderungen auf vielen Geräten zu automatisieren ist damit weit mehr als ein einfaches CLI-Massenkommando. Es ist ein sehr praxisnaher Standard-Change, an dem sich zentrale Prinzipien moderner Netzwerkautomatisierung besonders gut zeigen: klare Standards, kontrollierte Zielauswahl, schrittweise Rollouts, saubere Verifikation und sicherer Umgang mit sensiblen Änderungen. Gerade deshalb eignet sich dieses Thema hervorragend, um den Übergang von manueller Gerätekonfiguration hin zu strukturierten, wiederholbaren und verantwortungsvoll automatisierten Netzwerkprozessen zu verstehen.

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