Protocol de management SNMP

Internet - o rețea gigant. Acest lucru ridică întrebarea, deoarece își păstrează integritatea și funcționalitatea acestuia, fără nici un control? Dacă luăm în considerare eterogenitatea calculatoare, routere, și software-ul utilizat în rețea, existența Internetului a prezentat un miracol simplu. Deci, cum îndrăznești să-problemele de guvernare pe Internet? O parte din această întrebare a fost deja răspuns - rețeaua rămâne operațională datorită regulamentului de protocol rigid. „Puterea de rezervă“ prevăzute în protocoalele propriu-zise. Funcțiile de diagnosticare sunt atribuite, așa cum sa menționat mai sus, pe protocolul ICMP. Având în vedere importanța funcțiilor de control pentru aceste scopuri create două dintre SNMP (Simple Network Management Protocol, RFC-1157, -1215, -1187, -1089, std-15 a fost dezvoltat în 1988) și CMOT (servicii comune de gestionare a informațiilor și protocolul TCP / IP, RFC-1095, în ultimii ani, utilizarea acestui protocol este limitat). De obicei, aplicația de control afectează lanțul de rețea SNMP-UDP-IP Ethernet. Cel mai important obiectiv al controlului este de obicei un port extern de rețea (gateway) sau un router de rețea. Fiecare obiect gestionat este atribuit un identificator unic.

Tabelul 4.4.13.1 comenzi SNMP

Obține valoarea variabilei sau informații despre starea elementului de rețea specificat;

Ia valoarea unei variabile fără a cunoaște numele exact al acesteia (următorul identificatorul logic la arborele MIB);

Atribuirea unei variabile o valoare. Folosit pentru a descrie o acțiune care trebuie să fie făcut;

Răspunsul la GET-solicitare, GET_next_request și SET-cerere. Acesta conține, de asemenea, informații despre starea (coduri de eroare, precum și alte date);

Informații despre TRAP conținute în codul special.

Pentru tipul de TRAP 0-4 câmp cod special, ar trebui să fie zero. câmpul Timestamp conține numărul de centiseconds (număr de căpușe) din momentul inițializării obiectului control. Deoarece o întrerupere se emite obiect coldstart prin intermediul a 200 ms după inițializare.

În ultimii ani, o ideologie pe scară largă distribuite interfață de protocol DPI (Distributed Protocol Interface). Pentru transportul SNMP- interogări pot fi utilizate nu numai UDP, dar TCP-protocol. Acest lucru face posibilă utilizarea SNMP-protocol nu numai în rețelele locale. Formatele SNMP-DPI-interogări (versiunea 2.0) sunt descrise în RFC-1592. antet EXEMPLU snmp-solicitare (imagine câmp formează o singură matrice Fig .. 4.4.13.3):

pavilion Golf = 0x30 este un semn ASN.1-antet. Codurile Ln - este un câmp de lungime, începând cu octetul care urmează lungimea codului, până la sfârșitul mesajului de cerere (n - numărul de lungimea câmpului), dacă nu se specifică altfel. Deoarece L1 lungime de pachete de --query variind de la T1 până la sfârșitul pachetului, și L3 - câmp de lungime parola. Subcâmp Tn - câmp de tip în urma solicitării acestora de subcâmp. Deoarece T1 = 2 înseamnă că câmpul se caracterizează printr-un număr întreg, T2 = 4 indică faptul că ceea ce urmează este parola (câmpul comunității în exemplul de mai sus = public). Cifrele de mai jos cifrele indică valorile tipice ale subcâmpuri. Cod 0xA - un semn GET-cerere, urmat câmp de cod PDU (= 0-4, vezi Tabelul 4.4.13.1 ..) Block Subcâmpurile cerere ID este utilizat în aceleași scopuri ca și ceilalți identificatori - pentru a determina perechile solicitare-răspuns . De fapt, cererea de identificare poate avea unul sau doi octeți, care este determinat de Liz. CO - stare de eroare (PS = 0 - nici o eroare); TM - tip MIB-variabilă (în exemplul = 0x2B); IO - cod de eroare. Codul Digital afișajelor MIB-variabilă secvența de subrubrici digitale care caracterizează variabil, de exemplu: 1.3.6.1.2.1.5 variabilă (în termeni simbolici iso.org.dod.internet.mgmt.mib.icmp) se caracterizează printr-o secvență de cod 0x2B 0x06 0x01 0x02 0x01 0x05 0x00.

Componentele procesor SNMP enumerate în tabelul 4.4.13.5 (vezi RFC 2571 și -2573)

Tabelul 4.4.13.5. componente procesor SNMP

Acesta permite suport simultan pentru mai multe versiuni de SNMP-un mesaj procesor SNMP. Această componentă este responsabilă pentru primirea unităților de date de protocol (PDU), pentru transmiterea PDU subsistemului de prelucrare a mesajului, pentru transmiterea și primirea de mesaje de rețea SNMP-

Mesaj Subsistemul de manipulare

Responsabil pentru pregătirea mesajelor pentru trimiterea și regăsirea datelor din mesajul de intrare

Acesta oferă servicii ce asigură o securitate: autentificare și mesajele de securitate de la interceptarea și distorsiuni. Aceasta a permis punerea în aplicare a mai multor modele de securitate

Subsistemul control acces

Initiaza cere SNMP-Get, GetNext, GetBulk sau Set, concepute pentru sistemele locale care pot fi utilizate de către aplicații pentru verificarea drepturilor de acces.

SNMP-cerere percepe Get, GetNext, GetBulk sau Set, destinate pentru sistemul local, este indicat faptul că cererea primită în contextEngeneID egală cu valoarea corespunzătoare din SNMP procesor. aplicație handler de comandă efectuează o operațiune de protocol corespunzător, generează un mesaj de răspuns și trimite-l la expeditorul cererii.

Ascultă mesajul de notificare, și generează mesajul de răspuns atunci când mesajul vine de la PDU Inform

Fig. 4.4.13.5 prezintă formatul mesajului SNMPv3 care implementează modelul de securitate UBM (User-securitate pe bază de model).

Primele cinci câmpuri sunt generate de către expeditor în cadrul modelului de procesare a mesajului și procesat de către receptor. Următoarele șase câmpuri transporta parametrii de securitate. Următoarea PDU (câmp bloc de date) și cu contextEngeneID contextName.

• msgVersion (SNMPv3) = 3
• msgid - un identificator unic utilizat de SNMP-entități pentru a stabili o corespondență între cererea și răspunsul. Valoarea msgid se află în intervalul 0 - (31 Feb. -1)
• msgMaxSize - specifică dimensiunea maximă a mesajului în octeți, care este susținută de către expeditor. Semnificația ei se situează în intervalul 484 - (31 februarie -1) și egală cu dimensiunea maximă a segmentului care poate fi percepută de către expeditor.
• msgFlags - string 1-octetului care conține trei steaguri în biții cei mai puțin semnificativi: reportableFlag, privFlag, authFlag. Dacă reportableFlag = 1, ar trebui să fie trimis un mesaj cu PDU de rapoarte; când steagul = 0, raportul ar trebui să nu fie trimise. Flag reportableFlag = 1 este setat în toate mesajele au cererea expeditorului (Get Set) sau Inform. Steagul este setat la zero, în răspunsurile sau mesaje de notificări Trap Report. Steaguri privFlag și authFlag stabilite de către expeditor pentru a indica nivelul de securitate pentru acest mesaj. Pentru privFlag este utilizat = 1 criptare, iar pentru authFlag = 0 - autentificare. Valorile de pavilion valide pentru orice combinație, în plus privFlag = 1 AND authFlag = 0 (autentificare fără criptare).
• msgSecurityModel - identificator cu o valoare în intervalul 0 - (31 februarie -1), care indică modelul de securitate utilizat în formarea acestui mesaj. Rezervat pentru valorile SNMPv1,2 1 și 3 - în SNMPv3.

Atunci când un mesaj de ieșire este trimis, procesorul mesaj în USM, USM completează în setările de securitate din antetul mesajului. Când mesajul de intrare este transmis la handler mesajului în USM, manipulate setările de securitate conținute în antetul mesajului. Parametrii de securitate includ:

mecanism de autentificare SNMPv3 presupune că mesajul primit este, de fapt trimis la principal, al cărui identificator este conținută în antetul mesajului, și nu a fost modificat de-a lungul drum. Pentru a implementa autentificarea, fiecare dintre principiile implicate în schimbul trebuie să aibă o cheie de autentificare secretă comună tuturor participanților (determinat pe faza de configurare a sistemului). Într-un mesaj trimis de expeditor trebuie să includă un cod care este o funcție de conținutul mesajului și o cheie secretă. Unul dintre principiile este verificarea mesajelor în timp util USM (a se vedea mai sus), ceea ce face puțin probabilă atacul folosind copii ale mesajului.

Sistemul de configurare permite agentului pentru diferite niveluri de acces pentru diferite SNMP MIB-manageri. Acest lucru se face de către unii agenți pentru a restricționa accesul la anumite părți ale MIB, precum și prin restrângerea listei de operațiuni permise pentru o anumită parte a MIB. O astfel de schemă de control al accesului numit VACM (View-Based Access Control model). În timpul analizelor de control al accesului context (vacmContextTable), precum și masa de vacmSecurityToGroupTable specializate, vacmTreeFamilyTable și vacmAccessTable.

SNMP-protocol este un exemplu de un sistem de control, în care pentru a obține rezultatul dorit nu comanda este eliberată, iar informațiile sunt schimbate, este luat aceeași decizie „in situ“, în conformitate cu datele primite. Subsistemul de autentificare integrate, securitatea informațiilor și de control al accesului.

Tabelul 4.4.13.6. RFC-documente prin intermediul SNMP