Bundesamt für Sicherheit in der Informationstechnik

M 4.204 Sichere Administration von Routern und Switches

Verantwortlich für Initiierung: IT-Sicherheitsbeauftragter, Leiter IT

Verantwortlich für Umsetzung: Administrator

Es gibt unterschiedliche Zugriffsmöglichkeiten, um Router und Switches zu administrieren. Abhängig von der genutzten Zugriffsart müssen eine Reihe von Sicherheitsvorkehrungen getroffen werden. Bei größeren Netzen ist es empfehlenswert, Router und Switches in ein zentrales Netzmanagement-System einzubinden, da sonst eine sichere und effiziente Administration praktisch nicht gewährleistet werden kann.

Die zur Administration verwendeten Methoden sollten in der Sicherheitsrichtlinie festgelegt werden, und die Administration darf nur entsprechend der Sicherheitsrichtlinie durchgeführt werden. Alle nicht verwendeten Administrationsschnittstellen sollten deaktiviert werden. Im folgenden werden einige Punkte beschrieben, die bei der Administration beachtet werden sollten.

Zusätzlich sollte wenn möglich der Administrationszugriff durch die Einrichtung von Access Control Lists ( ACL s) eingeschränkt werden (siehe auch M 5.111 Einrichtung von Access Control Lists auf Routern ).

Remote-Administration

Eine Vielzahl von aktiven Netzkomponenten bietet die Möglichkeit der Remote-Administration mit Hilfe des Dienstes Telnet. Die Nutzung von Telnet birgt allerdings die Gefahr des Ausspähens von Authentisierungsdaten, da sämtliche Daten im Klartext übertragen werden und somit der Datenverkehr inklusive des Benutzernamens und Passwortes mitgelesen werden kann (siehe auch G 2.87 Verwendung unsicherer Protokolle in öffentlichen Netzen ). Oft wird zur Remote-Administration auch SNMP verwendet. Die Varianten SNMPv1 und SNMPv2 bieten ebenfalls keine ausreichenden Möglichkeiten zur Absicherung der Kommunikation. Erst SNMPv3 bietet Sicherheitsmechanismen, die einen Einsatz auch außerhalb abgeschotteter Administrationsnetze erlauben.

Bei Remote-Zugriff auf Routern und Switches muss in jedem Fall eine Absicherung der Kommunikation erfolgen. Dies kann beispielsweise durch die Nutzung des Dienstes SSH anstatt Telnet (siehe M 5.64 Secure Shell ) oder durch die Schaffung eigener LAN-Segmente, die ausschließlich für Administrationszwecke genutzt werden, erreicht werden (siehe Abschnitt Administrationsnetz).

Eine ungesicherte Remote-Administration über externe (unsichere) Netze hinweg darf in keinem Fall erfolgen. Dies muss bereits bei der Festlegung der Sicherheitsrichtlinie berücksichtigt werden. Auch im internen Netz sollten soweit möglich keine unsicheren Protokolle verwendet werden.

Webserver

Viele Geräte bieten die Möglichkeit, Administrationsarbeiten mit Hilfe des Dienstes HTTP über ein Browser-Interface durchzuführen. Auf dem Router bzw. dem Switch ist in diesem Fall ein HTTP-Server gestartet, der Zugriff erfolgt von beliebigen Clients über Web-Browser.

Die Standardeinstellungen für den Zugriff auf das Web-Interface sind nicht bei allen Herstellern einheitlich. Idealerweise sollte der Zugriff in der Grundeinstellung deaktiviert sein, es ist aber auch möglich, dass dieser Dienst ungeschützt ohne Eingabe von Benutzerinformationen verwendet werden kann. Dies ist bei der Inbetriebnahme der Geräte zu prüfen, gegebenenfalls muss die Konfiguration entsprechend geändert werden.

Wie bei der Nutzung des Dienstes TELNET wird auch beim HTTP der Benutzername und das Passwort im Klartext übertragen. Zudem sind eine Reihe von Exploits bekannt, die Schwachstellen der HTTP-Server der unterschiedlichen Hersteller ausnutzen. Daher wird von der Nutzung des HTTP-Dienstes für Administrationszwecke dringend abgeraten. Der HTTP-Server sollte nach Möglichkeit bei der Erstkonfiguration des Systems deaktiviert werden, sofern der Zugriff nicht über ein gesondertes Management-Netz erfolgt.

Manche Geräte bieten zusätzlich zum Zugriff über HTTP auch die Möglichkeit, über HTTPS auf das Web-Interface zuzugreifen. Sofern diese Möglichkeit besteht, sollte HTTPS in jedem Fall der Vorzug vor HTTP gegeben werden.

Bei der Nutzung des Web-Interfaces muss außerdem beachtet werden, dass oft nicht alle Konfigurationseinstellungen auf diesem Weg zugänglich sind.

Administrationsnetz (Out-of-Band-Management)

Um den Risiken bei der Remote-Administration entgegen zu wirken, bieten einige Geräte die Möglichkeit, einen eigenen logischen Port (Management-Interface) zur Administration zu konfigurieren. Bei Switches sollte dieser Port einem VLAN zugeordnet werden, welches ausschließlich für administrative Zwecke verwendet wird (Out-of-Band-Management) und dem ausschließlich Management-Interfaces angehören. Das Management-Netz sollte komplett von anderen Teilen des Netzes getrennt werden. Dadurch werden Schwachstellen wie unverschlüsselt übertragene Anmeldeinformationen bei den für administrative Aufgaben zur Anwendung kommenden Protokollen wie TELNET oder die veralteten SNMP-Varianten kompensiert.

Access Control Lists (ACLs) sind so zu konfigurieren, dass der Zugriff auf das Management-Interface nur der Management-Station erlaubt ist. Alle nicht benötigten Dienste sind für das Management-Interface zu deaktivieren.

Netzmanagement-Systeme

Aktive Netzkomponenten werden normalerweise in ein zentrales Netzmanagement-System eingebunden. Zusätzlich zum vorigen Abschnitt müssen in diesem Fall die Sicherheitsmaßnahmen, die im Baustein B 4.2 Netz- und Systemmanagement beschrieben sind, beachtet werden.

Zentraler Authentisierungsserver

An Stelle lokal auf dem Gerät zu konfigurierender Zugriffs- und Rechtekontrolle kann dies auch über einen zentralen Server erfolgen. Bei großen Umgebungen mit einer hohen Anzahl von aktiven Netzkomponenten ist die lokale Konfiguration nur bedingt praktikabel. Der Aufwand für die Administration und für viele parallel zu pflegende Berechtigungen ist dann sehr hoch.

Auf dem zentralen Server werden dabei einheitlich alle Zugriffe und Berechtigungen verwaltet. Die sensitiven Daten sind nicht mehr auf den Geräten selbst gespeichert und müssen nicht einzeln gepflegt werden. Stattdessen sind alle Informationen verschlüsselt in einer Datenbank abgelegt und lassen sich übersichtlich verwalten. Ein solcher Server bietet zudem erweiterte Möglichkeiten zur Protokollierung, beispielsweise können Anzahl und Zeitpunkt von Einwahl- oder Zugriffsvorgängen und übertragene Datenmengen dokumentiert werden. Beispiele hierfür sind RADIUS und TACACS+ (Terminal Access Controller Access Control System). Die Authentisierung sollte in komplexen Netzen mit einer Vielzahl von aktiven Netzkomponenten durch einen zentralen Authentisierungsserver abgesichert werden.

Für den Fall, dass kein Authentisierungsserver genutzt werden kann (beispielsweise beim Ausfall des Servers oder bei Netzproblemen), sollte trotzdem ein lokaler Zugriff konfiguriert sein. Dieser ist durch ein nur für diesen Zweck zu nutzendes Passwort abzusichern.

Für lokale Zugänge, die nicht eigens für den Fall eingerichtet wurden, dass der Authentisierungsserver nicht zur Verfügung steht, sollten der Authentisierungsserver nach Möglichkeit genutzt werden, da ansonsten die Benutzer, die sich lokal anmelden, die zentrale Autorisierung und Überwachung umgehen.

Berechtigungsverwaltung für Benutzerkonten und Systemkommandos

Die Berechtigungsverwaltung kann je nach Hersteller auf unterschiedlichen Ebenen und mit unterschiedlichen Graden der Granularität erfolgen. Bei der Berechtigungsverwaltung von Systemkommandos können Kommandos, die nur bestimmten Nutzern oder Gruppen zugänglich sein sollen, in einer Berechtigungsstufe zusammengefasst bzw. dieser zugeordnet werden. Dies ist beispielsweise vom Hersteller Cisco bereits für zwei Stufen vorkonfiguriert:

  1. Die Zuordnung von Systemkommandos zu Berechtigungsstufen.
  2. Die Zuordnung von Benutzerkonten zu Berechtigungsstufen.

Der Zugriff auf eine Berechtigungsstufe wird durch ein Passwort abgesichert. Ein Nutzer muss für den Zugriff auf ein entsprechend abgesichertes Systemkommando zunächst in die Berechtigungsstufe wechseln und das zugehörige Passwort eingeben. Dann ist er in der Lage, alle dieser Stufe zugeordneten Kommandos auszuführen. Die Berechtigungsvergabe für Benutzerkonten erfolgt, indem der Nutzer einer Berechtigungsstufe zugeordnet wird. Generell sollte gelten, dass jedem Nutzer nur die minimal notwendigen Berechtigungen zugeteilt werden. Somit lassen sich analog der folgenden Beispiele unterschiedliche Rollen definieren:

  • Ein Read-Only Account dient dazu, die Einstellungen des Geräts einzusehen. Änderungen der Konfiguration sind nicht möglich.
  • Der Read-Write Account erlaubt die Änderung und Betrachtung der meisten Einstellungen des Geräts, Sicherheits- und Passwort-Einstellungen gehören nicht dazu.
  • Der Read-Write-All Account ist für die umfassende Kontrolle inklusive Sicherheitseinstellungen, Zugriffspassworte und Web-basierte Managementzugriffe vorgesehen.
  • Zudem sind spezielle Accounts für die Verwaltung von Layer-2- und Layer-3-Funktionen möglich.

Ein Benutzer ist somit nach seiner Anmeldung am Gerät automatisch einer Berechtigungsstufe zugeordnet, alternativ muss er nach der Anmeldung dediziert die zu nutzende Berechtigungsstufe und das zugehörige Passwort eingeben. Für sicherheitskritische Rollen sollte stets eine Absicherung des Zugriffs über einen zentrale Authentisierungsserver eingerichtet werden.

Die Möglichkeiten der Zuordnung von Berechtigungen zu Benutzern und Rollen können sogar so weit gehen, dass für jeden einzelnen Befehl Berechtigungen vergeben werden können, die jedes Mal vor der Ausführung über den Autorisierungsserver überprüft werden.

Bei der Erstellung des Rechte- und Rollenkonzepts für die Administration der aktiven Netzkomponenten müssen die Möglichkeiten der einzelnen Systeme in Betracht gezogen werden. Wie fein die Berechtigungsstufen im Einzelfall unterschieden werden, sollte unter Berücksichtigung von Einsatzzweck und Schutzbedarf festgelegt werden. Als Faustregel kann dabei gelten: "So fein wie nötig, so einfach wie möglich." Zu grobe Unterteilungen bieten keine angemessene Sicherheit, andererseits können zu feine Unterteilungen die Effizienz der Arbeit beeinträchtigen und bringen die Gefahr von Fehlern mit sich.

Passwortverschlüsselung

Router und Switches sollten die Möglichkeit unterstützen, Passwörter verschlüsselt in Konfigurationsdateien abzulegen (siehe auch M 2.280 Kriterien für die Beschaffung und geeignete Auswahl von Routern und Switches ). Beispielsweise kann dies bei Cisco-Geräten mit dem Befehl enable secret erreicht werden.

Die Verschlüsselung von Passwörtern ist insbesondere dann wichtig, wenn Konfigurationsdateien über das Netz übertragen oder in zentralen Servern gespeichert werden.

Wenn das Gerät die Passwortverschlüsselung unterstützt, sollte diese Funktion unbedingt genutzt werden. Dabei sollte das Verschlüsselungsverfahren berücksichtigt werden, da einige Geräte unterschiedliche Verfahren unterstützen. Insbesondere bei älteren Betriebssystemen werden noch schwache Verschlüsselungsverfahren angewendet, die eventuell aus Gründen der Kompatibilität auch in neueren Versionen noch unterstützt werden. Hier sollte bei einer Migration auf ein neues Gerät oder eine neue Betriebssystemversion geprüft werden, ob die neuere Version stärkere Verschlüsselungsverfahren unterstützt.

Zudem bestehen für alle Geräte Prozeduren, die es zwar nicht ermöglichen, verschlüsselte Passworte wieder lesbar zu machen, die aber das Rücksetzen von Passwörtern durchführen.

Einige Dienste können nicht durch eine Passwort-Verschlüsselung abgesichert werden. Hierzu gehören SNMPv1 und SNMPv2, RADIUS und TACACS+. Die Passwörter der letztgenannten Dienste sollten somit immer einmalig sein, für keinen weiteren Dienst verwendet und regelmäßig geändert werden. SNMPv1 und SNMPv2 sollten allenfalls in Verbindung mit Out-of-Band-Management (siehe oben: Administrationsnetz) genutzt werden und möglichst durch SNMPv3 ersetzt werden.

Session-Timeouts

Sämtliche Zugriffsarten können durch die Vergabe von Passwörtern geschützt werden. Diese Absicherung kann jedoch wirkungslos werden, wenn Sessions unbeaufsichtigt sind, beispielsweise wenn ein angemeldeter Administrator seinen Rechner verlässt und dabei vergisst, die Session zu beenden oder die Bildschirmsperre zu aktivieren. Aus diesem Grund ist es empfehlenswert, Time-Outs einzurichten, um Verbindungen nach einem definierten Zeitraum ohne Nutzeraktivität zu beenden oder zu sperren. Dabei sollte eine Timeout-Zeit von 10 Minuten nicht überschritten werden.

Prüffragen:

  • Sind die Router und Switches in ein zentrales Netzwerkmanagement-System eingebunden?

  • Ist die Kommunikation für Remote-Zugriffe auf Router und Switches entsprechend abgesichert?

  • Sind ACL s definiert, die den Zugriff auf das Management-Interface der Router und Switches nur von einer Management-Station erlaubt?

Stand: 13. EL Stand 2013