Aufgrund seiner weiten Verbreitung wird SNMP von vielen Administratoren täglich genutzt. In der Konsequenz ist jedes Problem mit SNMP von größter Bedeutung. Dieser Artikel untersucht SNMP-Sicherheitslücken und liefert Lösungsansätze.
Viele Hersteller von Servern, Software und Netzwerkzubehör haben SNMP (Simple Network Management Protocol) in ihren Produkten implementiert, um ein Mittel zur Fernsteuerung und Fernüberwachung von Systemen zu bieten, die an Netzwerke angeschlossen sind - darunter auch das größte Netzwerk überhaupt - das Internet. SNMP ist eines der am weitesten verbreitetsten IT-Tools und viele Administratoren verwenden es tagtäglich. In der Konsequenz ist jedes Problem mit SNMP für Sicherheitsprofis von größter Bedeutung.
Einzelheiten der Verwundbarkeit
Obwohl SNMP schon seit geraumer Zeit eingesetzt wird, hat CERT erst kürzlich ein Gutachten (CA-2002-03[1]) veröffentlicht, das zwei der wichtigsten Sicherheitslöcher aufzeigt, die vor kurzem von der finnischen Oulo University Secure Programming Group (OUSPG) entdeckt wurden. Diese Entdeckung geschah im Rahmen des an dieser Universität laufenden Protokolltest-Projekts (PROTOS - Security Testing of Protocol Implementations[2]).
Das Problem besteht nicht nur aus einem einzelnen kleinen Bug, sondern aus einer Reihe von größeren Sicherheitslücken in mehreren Bereichen der als SNMPv1 bekannten ersten Version von SNMP. Dies ist ein altes Protokoll und es gibt auch neuere Versionen. Aber leider implementieren die meisten Hersteller die erste Version, wodurch es sich hier um eine sehr weit verbreitete Bedrohung handelt.
Die erste Sicherheitslücke (VU#107186[3]) bezieht sich auf den Umgang von SNMP mit Ereignismeldungen (Trap-Messages). SNMP-Trap-Messages werden benutzt, um Fehlermeldungen weiterzuleiten, und die OUSPG beschreibt eine Reihe von Problemen damit, wie SNMP solche Meldungen dekodiert und verarbeitet.
Das zweite Problem (VU#854306[4]) findet sich in den Manager-to-Agent Request-Messages. Bis es hierfür Patches gibt, besteht der einzige Weg, Systeme mit SNMP zu schützen, leider nur darin, diese Funktion vorübergehend zu deaktivieren.
Bedrohungsgrad: Mittel
Das sich aus diesem Fehler ergebende Zerstörungspotenzial ist beträchtlich und kann zu Denial-of-Service (DoS) Ereignissen führen oder dazu, dass Angreifer in die Lage versetzt werden, jeden beliebigen Code auf dem angegriffenen System auszuführen. Es ist jedoch allgemein bekannt, dass SNMP ein unsicheres Protokoll ist, dass nie dafür geschaffen wurde, zwischen vertraulichen Systemen (Trusted Systems) zum Einsatz zu kommen. Deshalb wird diese Sicherheitslücke, obgleich sie relativ leicht auszunutzen ist, sich möglicherweise nicht zu einem großen Problem auswachsen.
Administratoren, die sich bereits mit den SNMP-Schwächen beschäftigt und sich um Lösungen bemüht haben, werden möglicherweise von diesem Fehler gar nicht betroffen sein. Wer sich jedoch für das Internet-basierte Netzwerkmanagement auf SNMP verlässt und sich bisher entweder nicht über SNMPs Sicherheitsmängel bewusst war oder sich noch nicht um Gegenmaßnahmen bemüht hat, sollte sofort entsprechende Schritte einleiten.
Da die UDP-Ports 161 und 162 von SNMP normalerweise von einer gut eingestellten Firewall geschlossen werden, sind die meisten von einer Firewall geschützten Systeme nur gegenüber internen Attacken verwundbar, wenn diese auf den angesprochenen Sicherheitslücken basieren.
Anwendbarkeit
Diese Bedrohung betrifft annähernd 200 Systeme verschiedener Hersteller. Um den SNMP-Problemen bei seinen Systemen gegenüberzutreten hat Microsoft MS02-006[5] veröffentlicht. Obwohl alle Windows-Versionen (mit Ausnahme von ME) mit SNMP als optionaler Komponente ausgeliefert werden, ist es jedoch nicht standardmäßig in jeder Version implementiert. Dadurch wird die Bedrohung für Windows-Systeme beträchtlich reduziert.
Trotzdem wird SNMP aber häufig eingesetzt und jedes Netzwerk, das SNMP verwendet, ist potenziell verwundbar. An der UNIX-Front hat FreeBSD SNMP nicht in sein Basispaket implementiert, die Installationen sind also nicht verwundbar, außer man hat auch die Ports Collection von FreeBSD installiert. IBM berichtete, dass Tests an seinem AIX-System bewiesen hätten, dass seine Version von SNMP nicht verwundbar wäre.
Für weitere Informationen über spezifische Software und Hardware können Sie von verschiedenen Herstellern bereitgestellte Informationen im CERT Bulletin Appendix[6] finden.
Abhilfe
Microsoft empfiehlt betroffenen Anwendern, den SNMP-Service zeitweise zu deaktivieren. Diese Maßnahme sollte, solange keine spezifischen Patches zur Verfügung stehen, besser auch bei anderer SNMP-Software und -Equipment angewandt werden. Seien Sie jedoch gewarnt, dass die Deaktivierung von SNMP in Fällen, in denen es implementiert ist und andere Programme darauf zurückgreifen, zu negativen Auswirkungen führen kann.
Von großer Bedeutung ist der CERT-Bericht[1]. Dort heißt es: "Einige der betroffenen Produkte wiesen, selbst wenn SNMP bereits deaktiviert war, unerwartetes Verhalten oder Denial-of-Service-Konditionen auf, wenn sie der OUSPG-Testsuite ausgesetzt wurden. In diesen Fällen sollte die Deaktivierung von SNMP von der Anwendung entsprechender Filter begleitet werden."
"Bei SNMP kann die Eingangsfilterung (Ingress Filtering) der folgenden Ports vermeiden, dass Angreifer von außerhalb des Netzwerks verwundbare Ressourcen des lokalen Netzwerks angreifen, welche nicht ausdrücklich autorisiert sind, öffentliche SNMP-Dienste anzubieten.
snmp 161/udp # Simple Network Management Protocol (SNMP)
snmp 162/udp # SNMP System Management Messages"
CERT empfiehlt außerdem die Filterung der folgenden Dienste, obgleich bei der Verwendung dieser Ports Angriffe weniger wahrscheinlich sind:
smux 199/tcp # SNMP Unix Multiplexer
smux 199/udp # SNMP Unix Multiplexer
synoptics-relay 391/tcp # SynOptics SNMP Relay Port
synoptics-relay 391/udp # SynOptics SNMP Relay Port
agentx 705/tcp # AgentX
snmp-tcp-port 1993/tcp # cisco SNMP TCP port
snmp-tcp-port 1993/udp # cisco SNMP TCP port
Wie CERT in CA-2002-03[1] feststellt: "Der SNMP-Dämon kann sich an allen IP-Interfaces des Geräte festsetzen." Dies kann von Bedeutung sein, wenn es darum geht, wie man die Filterung implementiert. Pakete, die an andere Adressen als das normale Netzwerk-Interface gerichtet sind, könnten Firewalls umgehen.
SNMP-Hintergrund
SNMP lässt sich am besten als eine Sprache verstehen, die verwendet wird, um Router, Server, Switches und selbst Drucker - im Grunde genommen jedes von einem Netzwerk verwaltete Gerät - aus der Ferne zu verwalten.
Um zu verstehen, wie verwundbar SNMP sein kann, hilft es, zu wissen, dass sein Ursprung in den 1980er Jahren liegt, und es als ein Internetprotokoll entwickelt wurde. Damals wurden TCP/IP-Netzwerke in der Unternehmenswelt gerade populär, und die Verwaltung von Unternehmensnetzwerken begann zu einem wichtigen Thema zu werden. SNMP wurde entwickelt, als der Zugang zum Internet noch sehr beschränkt war. Als im Jahre 1990 RFC 1157[7] veröffentlicht wurde, gewann SNMP schnell an Popularität. Keine der ersten beiden SNMP-Versionen enthielt irgendwelche echten Sicherheits-Features.
Obgleich die ersten beiden SNMP-Versionen nicht sicher waren, wurden doch auch sichere Versionen entwickelt. Leider implementierte fast niemand eine dieser frühen sicheren Versionen.
SNMPv1 wurde von RFC 1157[7] definiert und ersetzte RFC 1067[8] und RFC 1098[9]. Sicherheit, so wie es jetzt ist, basiert auf wohlbekannten Community-Namen. Wie in RFC 1351[10], RFC 1352[11] und RFC 1353[12] dargestellt fügte SNMP-Sec Protokollsicherheit in SNMPv1 ein. Es wurde allerdings nie wirklich implementiert.
Secure Party-basiertes SNMP, oder SNMPv2p, wird in RFC 1441 beschrieben. Diese Version enthält eine ganze Reihe von Veränderungen, die über bloße zusätzliche Sicherheitsmaßnahmen hinausgehen.
Weitere Informationen über SNMPv3 finden Sie auf der IETF-Website[13]. Nach jahrelanger Arbeit sollte SNMPv3 in Kürze als ein RFC veröffentlicht werden. In Zusammenhang mit SNMPv3 habe ich RFC 2104[14] erwähnt gesehen, allerdings ist dies nur ein Hinweis zur Message-Authentifizierung und kein Standard oder ein Dokument zu SNMP.
Zusammenfassung
Alle Administratoren müssen eindringlich vor diesen neuen SNMP-Fehlern gewarnt werden, denn wahrscheinlich haben alle Administratoren wenigstens einige Server oder Netzwerkteile, auf denen SNMP läuft. Sollten diese Systeme nicht durch Firewalls oder andere Sicherheitsvorkehrungen geschützt sein, sind sie definitiv dem Risiko eines Hacker-Angriffs ausgesetzt.
URLs in diesem Artikel:
[1] = http:/
[2] = http:/
[3] = http:/
[4] = http:/
[5] = http:/
[6] = http:/
[7] = http:/
[8] = http:/
[9] = http:/
[10] = http:/
[11] = http:/
[12] = http:/
[13] = http:/
[14] = http:/