Modul 5: SNMP Steilkurs 03.12.2012 15:09:28 M. Leischner Sicherheit in Netzen Folie 1
Grundlegende Netzmanagementkonzepte (technische Sicht) MIB MIB MO Netzressource Netzressource Manager- System Kommando Notification / Event Management- Agent Netzressource Management- Protokoll proprietäre Schnittstelle System, Netzkomponente 03.12.2012 15:09:28 M. Leischner Sicherheit in Netzen Folie 2
Submodul 5.1: SNMP-Grundlagen 03.12.2012 15:09:29 M. Leischner Sicherheit in Netzen Folie 3
SNMP-Managementprotokoll basiert auf ASN.1 Normierung ASN.1 - Abstract Syntax Notation One: ITU-T X.680 / ISO 8824-1 (1997) BER - Basic Encoding Rules of ASN.1: ITU-T X.690 / ISO 8825-1 (1997) Einsatzbeispiel: X.400 Message Handling System / X.500 Directory Services Secure Electronic Transaction (SET) Telecommunications Management Network (TMN) Simple Network Transfer Protocol (SNMP) Definition der Structure of Management Information (SMI), der MIB und MOs Syntaktische Struktur der SNMP-PDUs 03.12.2012 15:09:29 M. Leischner Sicherheit in Netzen Folie 4
Abstract Syntax Notation 1 (ASN.1) MIB Management Information Mapping ASN.1 Anwendung Abstract Syntax Anwendung lokale Syntax BER BER lokale Syntax System A Kodierer Transfer Syntax Kodierer System B 03.12.2012 15:09:29 M. Leischner Sicherheit in Netzen Folie 5
Beispiele von ASN.1 Typ-Definitionen Counter ::= INTEGER IpAddress ::= OCTET STRING Months ::= ENUMERATED {january (1), february (2), march (3), april (4), may (5), june (6), july (7), august (8), september (9), october (10), november (11), december (12)} 03.12.2012 15:09:29 M. Leischner Sicherheit in Netzen Folie 6
Basic Encoding Rules (BER) Prinzip: TLV-Kodierung Beispiel Kodierung von INTEGER-Wert 5: Tag: 0 0 0 0 0 0 1 0 Klasse zusammengesetzt (1) Tag-Nummer Length: es gibt eine Kurz und Langform (hier Kurzform) 0 0 0 0 0 0 0 1 Falls der Wert eines Tags größer als 30 ist, dann werden im ersten Okett die letzten 5 Bit 1 auf "1" gesetzt. In den nachfolgenden Oktetts ist das MSB dann auf "1" gesetzt, wenn noch weitere Oktett folgen Value: 2-Komplementdarstellung 0 0 0 0 0 1 0 1 215 h 03.12.2012 15:09:29 M. Leischner Sicherheit in Netzen Folie 7
Beispiel DayOfYear ::= [APPLICATION 17] IMPLICIT INTEGER Typ-Definition today DayOfYear ::= 128 Wertzuweisung 51 02 00 80 BER-Kodierung 0 1 0 1 0 0 0 1 APPLICATION einfach 17 03.12.2012 15:09:29 M. Leischner Sicherheit in Netzen Folie 8
Object Identifier Tree (OID tree) Alle Managed Objects werden über den Object Identifier Tree (OID tree) identifiziert. ( hängen im OID-tree ) Beispiel: sysdescr: 1.3.6.1.2.1.1.1 <root> ccitt(0) iso(1) standard(0) org(3) dod (6) internet (1) directory (1) mgmt (2) mib (1) system (1) sysdescr (1) experimental (3) private (4) enterprises (1) SNI (231) snmpv2 (6) joint-iso-ccitt(2) 03.12.2012 15:09:29 M. Leischner Sicherheit in Netzen Folie 9
SNMP-Tabellen Grundprinizip: Tabelle wird (followed religiously) als dreistufige Struktur im OID Tree aufgebaut: <name>table (t) Name der Tabelle <name>entry (1) Steht als Verzweigpunkt für die Spalten der Tabelle <nameabbr><desccol> (i) Spaltenobjekt internet (1) directory (1) mgmt (2) mib (1) system (1) sysdescr (1) interfaces (2) ifnumber (1) iftable (2) ifentry (1) ifindex (1) ifdesc (2) iftype (3) ifmtu (4) ifspeed (5) 03.12.2012 15:09:29 M. Leischner Sicherheit in Netzen Folie 10
ifnumber (1) interfaces (mib-2 2) iftable (2) Bespiel: Betriebszustand des Interfaces Nr. 5 ifoperstatus.5 1.3.6.1.2.1.2.2.1.8.5 ifindex (1) ifdescr (2) iftype (3) ifmtu (4) ifspeed (5) ifphysaddress (6) ifadminstatus (7) ifoperstatus (8) iflastchange (9) ifinoctets (10) ifinucastpkts (11) ifentry (1) ifspecific (22) ifoutqlen (21) ifouterrors (20) ifoutdiscards (19) ifoutnucastpkts (18) ifoutucastpkts (17) ifoutoctets (16) ifunknownprotos (15) ifinerrors (14) ifindiscards (13) ifinnucastpkts (12) Legend: INDEX in bold nach: Minhua Wang (http://www.homepages.dsu.edu/wangm/) 03.12.2012 15:09:29 M. Leischner Sicherheit in Netzen Folie 11
Beispiel: Verbindungsstatus einer TCP-Verbindung TcpConnEntry ::= SEQUENCE { tcpconnstate INTEGER, tcpconnlocaladdress IpAddress, tcpconnlocalport INTEGER (0..65535), tcpconnremaddress IpAddress, tcpconnremport INTEGER (0..65535) } OID von tcpconnstate: 1.3.6.1.2.6.13.1.1 03.12.2012 15:09:29 M. Leischner Sicherheit in Netzen Folie 12
Identifikation von Instanzen von Managed Objects (am Beispiel des Verbindungsstatus einer TCP-Verbindung) Struktur des Suffix: INDEX { tcpconnlocaladdress, tcpconnlocalport, tcpconnremaddress, tcpconnremport } Somit ergibt sich als Identifier der entsprechenden Obiektinstanz: tcpconnstate.iplocal.portlocal.ipdest.portdest 1.3.6.1.2.6.13.1.1.194.23.86.23.2045.194.23.86.15.80 OID OCTET STRING INT OCTET STRING INT 03.12.2012 15:09:29 M. Leischner Sicherheit in Netzen Folie 13
Submodul 5.2: SNMP- Zugriffsprotokoll 03.12.2012 15:09:29 M. Leischner Sicherheit in Netzen Folie 14
Das SNMP-Zugriffsprotokoll Zielsetzung: Einfachheit ( > geringe Entwicklungskosten, auf kleinen Komponenten leicht implementierbar, einfache Agentensoftware möglich) Diese Zielsetzung geht auf Kosten von: Funktionalität, Performance, Sicherheit Die Grundprobleme: Sicherheit differenzierte Rechtevergabe Bildung von Managementsichten komplexe MS / MA Beziehung werden in SNMP angegangen durch SNMP Verwaltungsbeziehungen (Administrative Relationships) 03.12.2012 15:09:29 M. Leischner Sicherheit in Netzen Folie 15
Charakterisierung des SNMP-Zugriffprotokolls Das SNMP-Protokoll ist ein symmetrisches (Request / Response gleich aufgebaut, > Manager und Agent PE gleich) asynchrones (jederzeit Senden möglich, keine Synchronisation) Request / Response Protokoll 03.12.2012 15:09:29 M. Leischner Sicherheit in Netzen Folie 16
SNMP Manager Management application Application manages objects SNMP Agent SNMP managed objects GetRequest GetNextRequest SetRequest IP GetResponse Layer 1 & 2 Trap Central MIB SNMP Messages Networ k GetRequest GetNextRequest 58000 162 161 UDP SetRequest UDP IP GetResponse Trap Layer 1 & 2 61150 nach Prof. John A. Copeland, Stallings, bzw. Dr. Andreas Steffen, 2000-2002 Zürcher Hochschule Winterthur, Kommunikationssysteme (KSy) 03.12.2012 15:09:29 M. Leischner Sicherheit in Netzen Folie 17
Arbeitsweise der Grundoperationen GetRequest PDU-Tag=0 errorstatus=0 errorindex=0 Variablewert=NULL GetResponse PDU-Tag=1 Liefert Variablenwert zu vorausgegangenem GetRequest, GetNextRequest oder SetRequest im positiven Fall, Fehlermeldung im negativen Fall (Variablen-Binding unverändert) GetNextRequest PDU-Tag=2 Liefert lexikographisch im OID-Tree folgende Objektinstanz. SetRequest PDU-Tag=3 Setzt Variablen auf angebene Werte. Fehlermeldung (z.b. read-only) im negativen Fall (Variablen-Binding unverändert) M. Leischner Sicherheit in Netzen Folie 18
Events Außergewöhnliche Ereignisse der Ressource (Events) lösen im SNMP- Agenten eine Meldung an das Managersystem aus. Diese Meldungen werden als Traps (im Falle von SNMPv1) bzw. Notifications (im Falle von SNMPv2) bezeichnet. Ein Event enthält eine Fehlernummer (und bei Bedarf weitere Informationen). Im Rahmen von SNMP wird als Managementkonzept das sogenannte "trap directed polling"-modell verwendet (Polling der benötigten Information nach einem Hinweis durch einen Trap). Die Traps bzw. Notifications werden in SNMP nicht bestätigt. Insgesamt wird der Eventmechanismus von SNMP als sehr unzureichend beurteilt. M. Leischner Sicherheit in Netzen Folie 19
Submodul 5.3: Sicherheit in SNMPv1 M. Leischner Sicherheit in Netzen Folie 20
Begriffsbildungen Community Eine SNMP community ist eine Beziehung zwischen einem SNMP Agent und einer Menge von SNMP Managern. Verschiedene Agents können denselben Community-Namen benutzen. SNMP MIB view Teilmenge von MOs auf einem bestimmten Netzelement (gebildet aus verschiedenen MIBs und aus verschiedenen Subtrees). Das Setzen von MIB views muss explizit in einer Komponente unterstützt werden, sonst sind alle MOs im MIB view. Access Mode r-o oder r-w M. Leischner Sicherheit in Netzen Folie 21
SNMP agent Set of SNMP managers SNMP MIB view SNMP access mode SNMP community (community name) SNMP community profile SNMP access policy Beispiel ("red", (MIB-view-System-2, r-o)) M. Leischner Sicherheit in Netzen Folie 22
Sicherheit in SNMPv1 Theorie: Übergabe des Community Names + Userdaten an lokalen Authentifizierungsdienst Praxis: Nachsehen, ob Community Name in Liste der gültigen Community Names, dann Zuordnung von Community Profile M. Leischner Sicherheit in Netzen Folie 23
Submodul 5.4: SNMPv3 M. Leischner Sicherheit in Netzen Folie 24
Modul 7: SNMPv3 M. Leischner Sicherheit in Netzen Folie 25
SNMP-Versionen Party-Based SNMP Version 2 (SNMPv2p) User-Based SNMP Version 2 (SNMPv2u) SNMP Version 3 1988 1989 1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 Start SNMP Working Group SNMPv1 Secure SNMP Community- Based SNMP Version 2 (SNMPv2c) M. Leischner Sicherheit in Netzen Folie 26
SNMPv1 1990 Wesentliche RFCs: RFC 1155 Structure and Identification of Management Information for TCP/IP-based internets RFC 1156 Management Information Base for Network Management of TCP/IP-based internets RFC 1157 A Simple Network Management Protocol 3 Kommandos: GET, GETNEXT, SET sowie die unaufgeforderte Nachricht TRAP Vorteile: einfache Konfiguration und Bedienung einfache Implementierung geringer Ressourcenanforderungen an den Client Nachteile: primitive Sicherheitsmechanismen (einfacher Passwortschutz, unverschlüsselte Übertragung) nur 32-bit Counter (nicht ausreichend für Bandbreitenüberwachungen bei Gigabit- Verbindungen ) ineffiziente Abfrage von Tabellen nur Trap-Directed Polling M. Leischner Sicherheit in Netzen Folie 27
Secure SNMP 1992 Wesentliche RFCs: RFC 1351 SNMP Administrative Model RFC 1352 SNMP Security Protocols RFC 1353 Definitions of Managed Objects for Administration of SNMP Parties Behandlung der Sachziele Authentifizierung (Challenge-Response) Vertraulichkeit der Daten (Verschlüsselung mittels DES) Datenintegrität (MD5-Prüfsumme über SNMP-Nachricht) Zugriffskontrolle (Access Control) Secure SNMP wurde nicht eingeführt, sondern durch SNMPv2 abgelöst M. Leischner Sicherheit in Netzen Folie 28
Party-Based SNMP Version 2 (SNMPv2p) 1993 Wesentliche RFCs: RFC 1441 Introduction to version 2 of the Internet-standard Network Management Framework RFC 1445 Administrative Model for version 2 of the Simple Network Management Protocol (SNMPv2) RFC 1446 Security Protocols for version 2 of the Simple Network Management Protocol (SNMPv2) RFC 1447 Party MIB for version 2 of the Simple Network Management Protocol (SNMPv2) Party-Based Security Model: Sicherheit wird an eine logische Einheit (Party) gebunden basiert auf DES-Algorithmus sehr komplex (widerspricht der SNMP-Philosophie) Neue Protokolloperationen: Effizienteres Abfragen von Tabellen durch GetBulk-Befehl (Ersatz für Tabellendurchlauf mit getnext) Version wird nicht mehr verwendet M. Leischner Sicherheit in Netzen Folie 29
Community-Based SNMP Version 2 (SNMPv2c) 1996 Definiert in RFCs: RFC 1901 Introduction to Community-based SNMPv2 RFC 1905 Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2) RFC 1906 Transport Mappings for version 2 of the Simple Network Management Protocol (SNMPv2) Community-Based Security Model: Sicherheitsmechanismen aus der Version 1 verwenden! Neue Protokolloperationen: Effizienteres Abfragen von Tabellen durch GetBulk-Befehl (Ersatz fur Tabellendurchlauf mit getnext) Unterstützung für 64-bit Counter (ermöglicht Monitoring von High-Speed Devices ) erweiterte Fehlersignalisierung Inform-Operation für die Kommunikation zwischen verschiedenen Managern M. Leischner Sicherheit in Netzen Folie 30
User-Based SNMP Version 2 (SNMPv2u) 1996 Wesentliche RFCs: RFC 1909 An Administrative Infrastructure for SNMPv2 RFC 1910 User-based Security Model for SNMPv2 User-Based Security Model: Sicherheit wird an einen Benutzernamen gebunden relativ leicht zu handhabendes Sicherheitsmodell Diese Version kann mit Community-Based SNMP Version 2 (SNMPv2c) kombiniert werden SNMPv2c + SNMPv2u = SNMPv2 Insgesamt Chaos im Sicherheitsmodell von SNMPv2 M. Leischner Sicherheit in Netzen Folie 31
SNMPv3 2002 Motivation: mangelnde Behandlung von Sicherheitsaspekten in SNMP v1 und v2 kein einheitliches Gesamtmodell Ziele: Weiterverwendung bewährte Konzepte aus in SNMP v1 und v2 ( Kompatibilität) Entwurf einer modularen Architektur ( Baukasten ) Trotz Zusatzfunktionen, möglichst große Einfachheit ( Keep SNMP as simple as possible. - RFC 3411) Folgende Sicherheitsanforderungen sollen erfüllt werden: Zugriffskontrolle (Access Control) Authentifizierung Datenintegrität Vertraulichkeit der Daten bei Bedarf Verhinderung von Replayattacken ( Pünktlichkeitsmodul ) Folgende Bedrohungen werden nicht behandelt: Denial of Service Verkehrsanalyse M. Leischner Sicherheit in Netzen Folie 32
SNMPv3 - RFCs 2002 RFC 3410, "Introduction and Applicability Statements for Internet Standard," gibt einen Überblick über SNMPv3 RFC 3411, "An Architecture for Describing SNMP Management Frameworks," beschreibt Gesamtarchitektur mit Schwerpunkt auf Sicherheit und Adminstration. RFC 3412, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)" beschreibt mögliche Message Processing Modelle und den Dispatcher RFC 3413, "Simple Network Management Protocol (SNMP) Applications," beschreibt fünf Typen von SNMP-Applikationen RFC 3414, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)," beschreibt das Sicherheitsmodell RFC 3415, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP), beschreibt das VACM M. Leischner Sicherheit in Netzen Folie 33
Architektur SNMPv3-Manager (nach RFC3411) SNMP Entity COMMAND GENERATOR applications NOTIFICATION RECEIVER applications NOTIFICATION ORIGINATOR applications SNMP Applications Dispatcher Message Processing Subsystem Security Subsystem PDU Dispatcher v1mp Community-based Security Model Message Dispatcher Transport Mapping v2mp v3mp othermp User-based Security Model Other Security Model SNMP Engine UDP IPX other Network M. Leischner Sicherheit in Netzen Folie 34
Architektur von SNMPv3 SNMP-Architektur: Menge von verteilten, interagierenden SNMP-Entities Eine SNMP-Entity kann ein Manager-System, ein Agent-System oder eine Kombination aus beiden sein. Beispiel: SNMP Mid-level Manager SNMP Proxy Forwarder Jede SNMP-Entity besteht aus eine Sammlung von Modulen, die interagieren, um den gewünschten Service zu erbringen. Die modulare Struktur von SNMPv3 bringt eine Reihe von Vorteilen: die Koexistenz von Standards und die Migration wird unterstützt Zeitersparnis bei der Umsetzung und Anpassung auf Zielgeräte Weniger Komplexität durch Entkopplung Das Security Subsystem behandelt Authentisierung, Datenintegrität und Vertraulichkeit, aber nicht die Autorisierung. Hierfür gibt es ein eigenes Subsystem (Access Control Subsystem) M. Leischner Sicherheit in Netzen Folie 35
Architektur SNMPv3-Manager (nach RFC3411) MIB instrumentation SNMP Entity SNMP Applications COMMAND RESPONDER applications Access Control Subsystem View-based ACCESS CONTROL NOTIFICATION ORIGINATOR applications PROXY FORWARDER applications other ACM Dispatcher Message Processing Subsystem Security Subsystem PDU Dispatcher v1mp Community-based Security Model Message Dispatcher Transport Mapping v2mp v3mp othermp User-based Security Model Other Security Model SNMP Engine UDP IPX other Network M. Leischner Sicherheit in Netzen Folie 36
Literatur und Quellen ALLES zu SNMP (Wiki, MIBs, RFCs, Tutorials, Software, Literaturhinweise) finden Sie auf: http://www.simpleweb.org/ M. Leischner Sicherheit in Netzen Folie 37
Multiple-Choice-Test zu SNMPv3 Frage 1: Aus welchen Komponenten besteht eine SNMP-Entity? a: SNMP-Engine und Applications. b: SNMP-Framework und Applications. c: Sicherheitsprotokoll und Administration. Frage 2: Welche Applikationen laufen auf einem Manager? a: Proxy forwarder & Notification Originator. b: Command Generator & Notification Receiver. c: Command Generator& Command Responder. Frage 3: Wofür ist der Dispatcher unter anderem zuständig? a: Er erstellt Kommandos. b: Er wendet das Sicherheitsmodell auf die Nachrichten an. c: Er leitet Anfragen der Applications an das Message Processing Subsystem weiter. M. Leischner Sicherheit in Netzen Folie 38