snmpd unterstützt das in RFC 2575 definierte View-Based Access Control Model (VACM), um festzulegen, wer Informationen suchen oder ändern darf. Zu diesem Zweck gibt es für snmpd bezüglich Zugangskontrolle verschiedene Anweisungen.
Klassische Zugangskontrolle
Die einfachsten Anforderungen an die Zugangskontrolle können über die Anweisungen rouser/rwuser (für SNMPv3) oder rocommunity/rwcommunity (für SNMPv1 oder SNMPv2c) festgelegt werden.
rouser [-s SECMODEL] USER [noauth|auth|priv [OID | -V VIEW [CONTEXT]]]rwuser [-s SECMODEL] USER [noauth|auth|priv [OID | -V VIEW [CONTEXT]]]
Spezifiziert einen SNMPv3-Benutzer und gibt ihm das Zugriffsrecht read-only (GET und GETNEXT) bzw. read-write (GET, GETNEXT und SET).
Standardmäßig ermöglicht dies authentifizierten (inkl. verschlüsselten) SNMPv3-Anforderungen, mittels Standard-Kontext auf den kompletten OID-Baum zuzugreifen .
Alternativ kann noauth (minimaler Security-Level, erlaubt nicht-authentifizierte Anforderungen) oder priv (erzwingt Verschlüsselung) angegeben werden. Der Parameter OID schränkt den Zugriff für diesen Benutzer ein auf den Teilbaum, der zur angegebenen OID gehört bzw. auf den benannten VIEW. Zusätzlich kann ein Kontext oder mit <context>* ein Kontext-Präfix angegeben werden. Wird keine Kontext-Feld angegeben, dann lässt die Anweisung alle Kontexte zu, die möglich sind.
rocommunity COMMUNITY [SOURCE [OID | -V VIEW [CONTEXT]]]
rwcommunity COMMUNITY [SOURCE [OID | -V VIEW [CONTEXT]]]
Spezifiziert eine SNMPv1- oder SNMPv2c-Community und gibt dieser das Zugriffsrecht read-only (GET und GETNEXT) bzw. read-write (GET, GETNEXT und SET).Standardmäßig ermöglicht dies den Zugriff auf den kompletten OID-Baum, unabhängig davon, von wo aus sie gesendet wurden.
Mit dem SOURCE-Parameter kann man den Zugriff auf Anforderungen einschränken, die vom angegebenen System (oder Systemen) kommen; Details siehe com2sec.
Der Parameter OID schränkt den Zugriff für diese Community ein auf den Teilbaum, der zur angegebenen OID gehört bzw. auf den benannten VIEW. Kontexte sind typischerweise für Community-basierte SNMP-Versionen weniger relevant, aber das Verhalten ist hier dasselbe.
rocommunity6 COMMUNITY [SOURCE [OID | -V VIEW [CONTEXT]]]
rwcommunity6 COMMUNITY [SOURCE [OID | -V VIEW [CONTEXT]]]
sind Anweisungen für empfangene Anforderungen über IPv6 (falls der Agent derartige Transport-Domänen unterstützt). Die Parameter OURCE, OID, VIEW und CONTEXT werden genauso interpretiert wie bei IPv4.
Für eine bestimmten SNMPv3-Benutzer (bzw. für eine Community) sollte nur eine Anweisung angegeben werden. Es ist nicht sinnvoll, für einen und denselben SNMPv3-Benutzer (bzw. Community) sowohl eine rouser als auch eine rwuser Anweisung anzugeben. Die Anweisung rwuser umfasst alle Rechte von rouser (ebenso wie das Zulassen der SET-Unterstützung). Dasselbe gilt für Community-basierte Anweisungen.Für komplexere Zugriffsanforderungen (z.B. Zugriff auf zwei oder mehr verschiedene OID-Teilbäume oder unterschiedliche Views für GET- und SET-Anforderungen) sollte man einen der anderen Zugangskontroll-Mechanismen nutzen. Bitte beachten Sie, dass falls mehreren verschiedenen Communitys oder SNMPv3-Benutzern derselbe Zugriffs-Level gewährt werden soll, es effizienter ist, die Haupt-Anweisungen der VACM-Konfiguration zu verwenden (siehe unten).
VACM Konfiguration
Die volle Flexibilität der VACM-Konfiguration wird in Form der vier Anweisungen
com2sec,group, view und access bereit gestellt. Damit lassen sich zugrunde liegenden VACM-Tabellen direkt konfigurieren.
com2sec [-Cn CONTEXT] SECNAME SOURCE COMMUNITY
com2sec6 [-Cn CONTEXT] SECNAME SOURCE COMMUNITY
Bilden einen SNMPv1 oder SNMPv2c Community String auf einen Security-Namen ab, entweder von einem bestimmten Bereich von Source-Adressen oder global (Standard)Eine beschränkte Source (SOURCE) kann entweder ein bestimmter Hostname (oder Adresse) sein oder ein Subnetz sein; dargestellt als IP-Maske (z.B.
10.10.10.0/255.255.255.0), IP/BITS (z.B. 10.10.10.0/24) oder IPv6-Äquivalente.
Derselbe Community-String kann in mehreren verschiedenen Anweisungen
angegeben werden (wahrscheinlich mit verschiedenen Source-Parametern), wobei die erste Source/Community-Kombination, die zu einer eintreffenden Anforderungen passt, ausgewählt wird. Verschiedene Source/Community-Kombinationen können also auf denselben Security-Namen abgebildet werden.
Falls mit -Cn ein CONTEXT angegeben wird, dann wird der Community-String auf einen Security-Namen im benannten SNMPv3-Kontext abgebildet. Andernfalls wird der Standard-Kontext ("") verwendet.
com2secunix [-Cn CONTEXT] SECNAME SOCKPATH COMMUNITY
ist die Unix-Domänen-Version von com2sec.
group GROUP {v1|v2c|usm|tsm|ksm} SECNAME
Bildet einen Security-Namen (im angegebenen Security-Modell) auf eine benannte Gruppe ab. Derselbe Gruppenname kann in mehrere group-Anweisungen angegeben und ermöglichen es damit, dass eine einzige Zugriffseinstellung für mehrere Benutzer und/oder Community Strings gilt.
Bitte beachten Sie, dass die Gruppen für die beiden Security-basierten Modelle getrennt eingerichtet werden müssen: eine singlecom2sec-Anweisung (oder äquivalent) wird typischerweise von zwei group-Anweisungen begleitet.
view VNAME TYPE OID [MASK]
Definiert einen benannten "View" - eine Untermenge des gesamten OID-Baums. Dies wird meist ein einzelner Teilbaum sein, aber es können mehrere view-Anweisungen mit demselben View-Namen (VIEW) angegeben werden, um eine komplexere Menge von OIDs zu definieren. TYPE ist entweder included oder excluded, womit man wiederum einen komplexeren View definieren kann (z.B. indem man bestimmte sensitive Objekte von einem ansonsten zugreifbaren Teilbaum ausschließt).
MASK ist eine Liste hexadezimaler Oktette (optional durch '.' oder ':' getrennt) mit den gesetzten Bits, die angeben, gegen welche Sub-Identifier im View OID geprüft wird. Wird MASK nicht angegeben, dann muss die OID standardmäßig genau passen (alle Bits gesetzt), wodurch ein einfacher OID-Teilbaum definiert wird.
Beispiele
view iso1 included .iso 0xf0 view iso2 included .iso view iso3 included .iso.org.dod.mgmt 0xf0
Diese Anweisungen definieren alle denselben View, der den gesamten Teilbaum iso(1) umfasst (wobei das dritten Beispiel die Sub-Identifier ignoriert, die nicht durch die Maske abgedeckt werden).
Noch besser ist es, die Maske für die Definition eines Views zu verwenden, der eine bestimmte Reihe (oder Reihen) in einer Tabelle abdeckt, indem gegen den entsprechenden Tabellenindex-Wert geprüft, aber der Spalten-Sub-Identifier weggelassen wird:
view ifRow4 included .1.3.6.1.2.1.2.2.1.0.4 0xff:a0
Bitte beachten Sie, dass in einer Maske mit mehr als 8 Bits einzelne Oktette per ':' getrennt werden müssen.
access GROUP CONTEXT {any|v1|v2c|usm|tsm|ksm} LEVEL PREFX READ WRITE NOTIFY
Bildet eine Gruppe von Benutzern/Communitys (mit bestimmtem Security-Modell und minimalem Security-Level sowie einem spezifischem Kontext) auf einen von drei Views ab, abhängig von der Anforderung, die bearbeitet wird.
LEVEL ist einer der Werte noauth, auth, oder priv. PREFX gibt an, wie CONTEXT zum Kontext der Anforderung passen muss, entweder exakt oder per Präfix.
READ, WRITE und NOTIFY geben den View an, der für GET*-, SET- und TRAP-/INFORM-Anforderungen verwendet werden soll (obwohl der NOTIFY View aktuell nicht verwendet wird). Für den Zugriff über v1- oder v2c muss LEVEL den Wert noauth haben.
Typed-View Konfiguration
Die letzte Anweisungsgruppe erweitert den VACM-Ansatz in Richtung flexiblerer Mechanismen, was sich für weitere Zugangskontroll-Mechanismen verwenden lässt. Dies wird eher für die Definition verschiedener unterschiedlicher View-Typen benutzt, als für die festen drei Views des Standard-VACM-Mechanismus. Soweit es den Haupt-Agenten von SNMP betrifft, sind es die zwei Haupt-Viewtypen read und write, die den Werten READ und WRITE der Haupt-Anweisung access entsprechen.
authcommunity TYPES COMMUNITY [SOURCE [OID | -V VIEW [CONTEXT]]]
ist eine Alternative zu den Anweisungen rocommunity/rwcommunity. TYPES hat normalerweise den Wert read oder read/write.
Die VIEW-Spezifikation kann entweder ein OID-Teilbaum (wie zuvor) oder - für größerer Flexibilität - ein benannter View sein (definiert mit der view-Anweisung). Wird diese weggelassen, dann wird der Zugriff auf den gesamten OID-Baum erlaubt.
Wird CONTEXT angegeben, dann wird der SNMPv3-Zugriff innerhalb dieses Kontexts definiert. Andernfalls gilt der Standard-Kontext ("").
authuser TYPES [-s MODEL] USER [LEVEL [OID | -V VIEW [CONTEXT]]]
ist eine Alternative zu den Anweisungen rouser/rwuser. Die Parameter TYPES, OID, VIEW und CONTEXT haben dieselbe Bedeutung wie bei authcommunity
authgroup TYPES [-s MODEL] GROUP [LEVEL [OID | -V VIEW [CONTEXT]]]
ist ein "Begleiter" der Anweisung authuser, der den Zugriff auf eine bestimmte Gruppe angibt, die wie üblich mit der group-Anweisung definiert ist. Sowohl authuser als auch authgroup sind Standard für authentifizierte Anforderungen. LEVEL kann auch bei noauth oder priv angegeben werden, um nicht-authentifizierte Anforderungen bzw. Verschlüsselung zu ermöglichen.
Sowohl die authuser als auch authgroup Anweisung sind die Voreinstellung, um den Zugriff für SNMPv3/USM zu definieren. Um ein alternatives Security-Modell anzugeben, verwenden Sie die Option -s (es werden dieselben Werte für den Zugriff verwendet wie oben).
authaccess TYPES [-s MODEL] GROUP VIEW [LEVEL [CONTEXT]]
konfiguriert ebenfalls den Zugriff auf eine bestimmte Gruppe durch Angabe von Name und Typ des Views, der verwendet werden soll. Die Parameter MODEL und LEVEL werden genauso interpretiert wie bei authgroup. Falls CONTEXT angegeben wird, dann wird der Zugriff innerhalb dieses SNMPv3-Kontexts konfiguriert (bzw. im Kontext mit einem Präfix wenn CONTEXT mit einem '*' endet). Andernfalls gilt der Standard-Kontext ("").
setaccess GROUP CONTEXT MODEL LEVEL PREFIX VIEW TYPES
ist das direkte Äquivalent zur ursprünglichen access-Anweisung mit den
entsprechenden View-Typen wie read oder read/write. Alle anderen Parameter werden genauso interpretiert wie bei access.