Stille Helfer unter Beschuss

Bereits Ende der 80er Jahre beschrieb RFC 1067 ein unscheinbares Protokoll, das seither Einzug in eine unüberschaubare Zahl von netzwerkfähigen Geräten gehalten hat: SNMP. Trotz seiner Verbreitung wirkt das Simple Network Management Protocol meist im Verborgenen - wenn es nicht gerade durch Sicherheitslücken wie die jüngst in einem CERT-Advisory veröffentlichten ins Scheinwerferlicht gerät.

1

25.02.2002, 00:00 Uhr

Lesezeit: 9 Min.

c't Magazin

Von

Peter Eckel

SNMP dient vor allem zwei Einsatzzwecken: Der Konfiguration und Überwachung von netzwerkfähigen Geräten. Dabei ist dieser Begriff recht weit gefasst: Neben Netzwerkkomponenten wie Switches, Routern und Computersystemen lassen sich durch die Erweiterbarkeit des Protokolls auch weniger netzwerktypische Gerätschaften wie USVs, Klimaanlagen oder in Zukunft vielleicht auch Kaffeemaschinen mit SNMP verwalten.

Das Protokoll definiert dazu die Kommunikation zwischen so genannten Managern und Agenten. Der Manager ist die Arbeitskonsole des Administrators, während die Agenten direkt auf den Systemen und Netzwerkkomponenten laufen, die überwacht oder konfiguriert werden sollen. Der Agent kann dabei auch als Master-Agent fungieren, der über verschiedene Protokolle wie AgentX oder SMUX seinerseits mit Unter-Agenten verbunden ist. Diese Unteragenten kommunizieren dann über ihn mit dem Manager.

SNMP spezifiziert die Kommunikation zwischen dem ‘Manager’ und seinen Agenten.

Ganze Rechenzentren und weltweit operierende Firmen vertrauen auf SNMP zur Wartung und vor allem Überwachung ihrer Netzwerkkomponenten, ihrer Server und ihrer Infrastruktur. Produkte wie Tivoli, HP OpenView Network Node Manager, MicroMuse Netcool, BMC Patrol Enterprise Manager oder Proxima Centauri - um nur einige zu nennen - verarbeiten neben anderen Informationen SNMP-Traps und rufen Informationen von SNMP-Agenten ab, um einen Überblick über den Betriebszustand der Systeme zu erhalten und gegebenenfalls korrigierend eingreifen zu können. Zentrale Konsolen, die Traps von Tausenden von Agenten verarbeiten, sind dabei durchaus keine Seltenheit.

Dabei treten mitunter auch eigenwillige Probleme auf. So macht etwa die Einschränkung auf 32-Bit-Zähler bei SNMPv1 bei Netzwerkinterfaces mit hoher Bandbreite die Abfrage der empfangenen oder gesendeten Bytes zu einem Wettlauf gegen die Zeit: Bei einem voll ausgelasteten Gigabit-Ethernet-Interface liegt zwischen zwei Zählerüberläufen nicht einmal eine Minute. Solche Schwierigkeiten können sich schnell zu echten Problemen entwickeln, wenn beispielsweise eine Abrechnung von EDV-Dienstleistungen auf der Basis so gemessenen Datenvolumens erfolgt.

Doch auch in Heimnetzwerken kommt mittlerweile hinter den Kulissen SNMP zum Einsatz. Die Konfigurationswerkzeuge für ISDN-Router oder Funk-LAN-Access-Points sind häufig nichts anderes als einfach gestrickte SNMP-Manager.

Von der Kaffeemaschine zum Rechenzentrum

Eine Stärke von SNMP sind seine flexiblen Strukturen, die es erlauben, völlig unterschiedliche Geräte zu verwalten. Dazu definiert jedes Gerät seine Fähigkeiten in einer Management Information Base (MIB). Dabei handelt es sich um hierarchisch strukturierte Beschreibungen der Informationen, die ein Agent übermitteln oder die die Managementsoftware über diesen Agenten übertragen kann, um Konfigurationsänderungen durchzuführen.

Die MIB definiert, welche Parameter ein Manager setzen und welche er nur auslesen kann, ob eine Information im Textformat vorliegt oder ein Zahlenwert ist und einiges mehr. Auch Tabellenformate sind definierbar, um beispielsweise eine Liste der Interfaces eines Routers oder Switches mit ihren Auslastungsdaten abrufen zu können. Was für den einen Interfaces, Routing-Tabellen und Collisions sind, sind für den anderen Kaffeepulver, Wasserstand und Brühtemperatur. Dem SNMP ist der Inhalt der übertragenen Information gleichgültig.

Zäher Urahn mit Sicherheitslücken

In der ursprünglichen Version 1 des SNMP-Protokolls, kurz SNMPv1, ist lediglich eine sehr rudimentäre Form der Kontrolle von Zugriffsberechtigungen vorgesehen. Den ‘get’- und ‘set’-Anforderungen wird eine Zeichenkette beigefügt, die so genannte Community, die eine Art Passwort darstellt: Stimmt sie mit der im Agenten hinterlegten Community überein, erlaubt dieser den Zugriff.

In der einfachsten (und weit verbreiteten) Form gibt es zwei Communities: ‘read-only’, die nur lesenden Zugriff erlaubt, und ‘read-write’, die auch die Konfiguration von Parametern zulässt. Die bis heute noch von vielen Herstellern und leider auch Netzwerkadministratoren gepflegte Unsitte, die Standardvorgaben ‘public’ und ‘private’ für die beiden Communities zu verwenden, öffnet unerwünschten Konfigurationseingriffen Tür und Tor.

Um die Sicherheit von SNMPv1 ist es schlecht bestellt: Alle Daten gehen im Klartext übers Netz.

Doch auch spezielle Community-Namen bieten keinen ernsthaften Schutz, denn SNMPv1 überträgt sie - wie auch die Daten - im Klartext. So lässt sich mit einem Netzwerksniffer schnell ein Community-String erlauschen, der dann Zugriff auf wichtige Netzwerkkomponenten erlaubt.

Als zusätzliches Sicherheits-Feature lassen sich bei neueren Agenten Zugriffslisten (Access Control Lists, ACLs) definieren, sodass nur die dort festgelegten Rechner bestimmte Operationen durchführen dürfen. Doch IP-Adressen lassen sich fälschen, sodass sicherheitsbewusste Administratoren oft separate, virtuelle Netze (VLANs) verwenden, die ausschließlich der Administration dienen. Da es auch Methoden gibt, solche VLANs zu kompromittieren, bleiben all diese Ansätze letztlich Flickschusterei.

Erschwerend kommt hinzu, dass man mitunter SNMP-Agenten betreibt, ohne es überhaupt zu wissen. Viele Hardwarekomponenten wie druckerinterne Print-Server und Softwarepakete besitzen SNMP-Funktionen, die in der Standardeinstellung aktiv sind, ohne dass bei der Installation explizit darauf hingewiesen wird. Wer sein Netzwerk mit einem Portscanner auf Adressen mit geöffneten UDP- und TCP-Ports 161 und 162 absucht, dürfte manche Überraschung erleben. Wie so oft, ist hier jedoch ‘keine Nachrichten’ nicht zwangsläufig mit ‘gute Nachrichten’ gleichzusetzen - ‘wilde’ SNMP-Agenten nutzen gerne nicht standardisierte Ports. Eine (keineswegs vollständige) Aufzählung findet sich in [1]. Generell sollte sicherheitsbewusste Administratoren jeder Port misstrauisch machen, dessen Nutzung ihm unklar ist.

Zerstrittene Erben

Eine Ablösung von SNMPv1 ist also längst überfällig. Schon 1996 beschrieben zwei RFCs Erweiterungen für SNMPv2. RFC 1909 definiert Ausschnitte aus dem Objektbaum, so genannte ‘Views’, für die nur bestimmte Communities Lese- oder Schreibrechte besitzen. Der etwa zeitgleich publizierte RFC 1910 verbessert die Authentifizierung durch den Einsatz von Verschlüsselungsverfahren - dumm nur, dass die beiden Vorschläge zueinander nicht kompatibel sind. Als Kompromiss entstand ein um die zwischen den Arbeitsgruppen strittigen Elemente bereinigter und SNMPv2* genannter dritter Vorschlag, der unter anderem die Verschlüsselung der übertragenen Daten vorsieht. Angesichts dieser Wirrungen um SNMPv2 übten sich die meisten Hersteller bei der Implementierung in vornehmer Zurückhaltung.

So folgte die in RFC 2571 beschriebene SNMPv3-Architektur, die sich den oben beschriebenen Problemen detailliert widmet. Authentifizierung, Sicherstellen der Integrität von SNMP-Nachrichten und Schutz vor Replay-Attacken sind einige der Themen, mit denen sich dieser Entwurf befasst. Der Preis der Sicherheit liegt auf der Hand: Der Verwaltungsaufwand für eine SNMPv3-Installation ist ungleich höher als der für SNMPv1. Weil außerdem viele Management-Tools SNMPv3 noch nicht unterstützen, kommt meist noch der Urahn zum Einsatz.

Angriff aus dem Abseits

Wer nun denkt, mit den beschriebenen Sicherheitslücken habe er genug Probleme, der hat die Rechnung leider ohne den Wirt gemacht. Nachdem sich eine Gruppe von Sicherheitsspezialisten der Universität von Oulu in Finnland über das LDAP-Protokoll hergemacht hatte, haben sie sich nun auch SNMP vorgenommen - mit verheerendem Ergebnis.

Die Tester malträtieren SNMP-Agenten und -Manager mit ungültigen SNMP-Paketen: Überlange Community-Namen, undefinierte oder extrem große Einträge in die Felder für den Nachrichtentyp, ASCII-Zeichenketten mit Sonderzeichen oder ohne Inhalt stellten die Robustheit der SNMP-Implementierungen auf die Probe.

Eine große Anzahl von SNMP-Agenten erwies sich als anfällig gegen diese Angriffsversuche. Die Symptome reichen von einfachen Abstürzen der Agenten über Denial-of-Service-Symptome bis hin zur Ausführung beliebigen Codes durch die Systeme, auf denen die Agenten laufen. Diese Probleme sind gleichermaßen über sämtliche Welten verteilt: Unternehmensweite Netzwerkmanagement-Software gehört ebenso zu den Opfern wie die SNMP-Agenten unter Windows und verschiedenen kommerziellen und freien Unix-Versionen, Netzwerk-Switches ebenso wie Printserver. Teilweise ist für erfolgreiche Angriffe nicht einmal ein gültiger Community-String erforderlich. Viele Hersteller haben bereits mit Patches reagiert oder liefern zumindest Beschreibungen, wie man die Probleme umgehen kann [1].

Selbsterfahrung

Mit einem Netzwerk-Sniffer und Protokoll-Analyzer wie Ethereal kann man eine Menge über die Arbeitsweise von SNMP lernen. Das Tool ‘versteht’ SNMP und zeigt die einzelnen Elemente der Kommunikation zwischen Master und Agent an.

Wer sich näher mit SNMP beschäftigen möchte, kann sich aus dem Netz das net-snmp-Toolkit herunterladen (siehe Soft-Link). Auf der Website finden sich sowohl Quellcode als auch fertig übersetzte Versionen für Unix und Windows. Das Toolkit besteht aus einer Sammlung von SNMP-Werkzeugen mit einem eigenen Agenten, Werkzeugen zum Erzeugen und Empfangen von SNMP-Traps, zur Abfrage von Variablen und zum Übersetzen von MIBs. Beim Experimentieren mit einem solchen Toolkit erhält man am ehesten einen Eindruck von den Möglichkeiten, aber auch von den Schwachpunkten von SNMP. (ju)