Ez a cikk a negyedik a „Hogyan veheti át az irányítást a hálózati infrastruktúrája felett” sorozatban. A sorozat összes cikkének tartalma és linkjei megtalálhatók .
В Ebben a fejezetben megvizsgáltuk a hálózati biztonság néhány szempontját az Adatközpont szegmensben. Ez a rész az „Internet-hozzáférés” szegmensnek lesz szentelve.
Internet elérhetőség
A biztonság témája kétségtelenül az egyik legösszetettebb téma az adathálózatok világában. A korábbi esetekhez hasonlóan, a mélység és a teljesség igénye nélkül, itt is meglehetősen egyszerű, de véleményem szerint fontos kérdéseket fogok megvizsgálni, amelyekre a válaszok, remélem, segítenek a hálózat biztonsági szintjének emelésében.
A szegmens auditálásakor ügyeljen a következő szempontokra:
- tervezés
- BGP beállítások
- DOS/DDOS védelem
- forgalomszűrés a tűzfalon
Tervezés
Példaként ajánlom ennek a szegmensnek a vállalati hálózathoz való tervezését belül a Cisco .
Természetesen más gyártók megoldása vonzóbbnak tűnik az Ön számára (lásd. ), de anélkül, hogy arra biztatnám, hogy kövesse ezt a tervet, továbbra is hasznosnak találom megérteni a mögötte rejlő elveket és ötleteket.
megjegyzés
A SAFE-ban a „Távoli elérés” szegmens az „Internet Access” szegmens része. De ebben a cikksorozatban ezt külön is megvizsgáljuk.
Ebben a szegmensben a vállalati hálózatok szabványos berendezései a következők
- határútválasztók
- tűzfalak
1. megjegyzés
Ebben a cikksorozatban, amikor a tűzfalakról beszélek, úgy értem .
2. megjegyzés
Kihagyom az L2/L1 kapcsolat biztosításához szükséges különféle L2/L3 vagy L1 over L2 megoldások figyelembevételét, és csak az L3 és magasabb szintű problémákra korlátozom magam. Részben az L1/L2 kérdéseket tárgyaltuk a „”.
Ha nem talált tűzfalat ebben a szegmensben, akkor ne siesse el a következtetéseket.
Tegyük ugyanazt, mint a benn Kezdjük a kérdéssel: szükséges-e az Ön esetében tűzfalat használni ebben a szegmensben?
Kijelenthetem, hogy ez tűnik a legindokoltabb helynek a tűzfalak használatára és az összetett forgalomszűrő algoritmusok alkalmazására. BAN BEN 4 olyan tényezőt említettünk, amelyek zavarhatják a tűzfalak használatát az adatközponti szegmensben. De itt már nem olyan jelentősek.
Példa 1. Késleltetés
Ami az internetet illeti, nincs értelme akár 1 ezredmásodperces késésekről is beszélni. Ezért a késleltetés ebben a szegmensben nem lehet a tűzfal használatát korlátozó tényező.
Példa 2. termelékenység
Egyes esetekben ez a tényező továbbra is jelentős lehet. Ezért előfordulhat, hogy engedélyeznie kell bizonyos forgalomnak (például a terheléselosztókból érkező forgalomnak), hogy megkerülje a tűzfalat.
Példa 3. Megbízhatóság
Ezt a tényezőt még mindig figyelembe kell venni, de magának az Internetnek a megbízhatatlansága miatt ennek a szegmensnek a jelentősége nem olyan jelentős, mint az adatközpont esetében.
Tehát tegyük fel, hogy a szolgáltatása a http/https mellett működik (rövid munkamenetekkel). Ebben az esetben használhat két független dobozt (HA nélkül), és ha az egyikkel probléma van az útválasztással, akkor az összes forgalmat a másodikba továbbíthatja.
Vagy használhatja a tűzfalakat átlátszó módban, és ha nem sikerül, engedélyezze a forgalomnak, hogy megkerülje a tűzfalat, miközben megoldja a problémát.
Ezért nagy valószínűséggel csak ár lehet az a tényező, amely arra kényszeríti Önt, hogy felhagyjon a tűzfalak használatával ebben a szegmensben.
Fontos!
Nagy a kísértés, hogy ezt a tűzfalat kombinálják az adatközpont tűzfalával (egy tűzfalat használjon ezekhez a szegmensekhez). A megoldás elvileg lehetséges, de ezt meg kell érteni, mert Az Internet-hozzáférési tűzfal valójában a védekezés élvonalában áll, és „átveszi” a rosszindulatú forgalom legalább egy részét, akkor természetesen számolnia kell a tűzfal letiltásának fokozott kockázatával. Azaz, ha ugyanazokat az eszközöket használja ebben a két szegmensben, jelentősen csökkenti az adatközponti szegmens elérhetőségét.
Mint mindig, meg kell értenie, hogy a vállalat által nyújtott szolgáltatástól függően ennek a szegmensnek a kialakítása nagymértékben változhat. Mint mindig, az Ön igényeitől függően különböző megközelítések közül választhat.
Példa
Ha Ön tartalomszolgáltató, CDN-hálózattal (lásd pl. ), akkor előfordulhat, hogy nem kíván infrastruktúrát létrehozni több tucat vagy akár több száz jelenléti ponton keresztül, külön eszközökkel a forgalom irányítására és szűrésére. Drága lesz, és lehet, hogy egyszerűen felesleges.
A BGP-hez nem feltétlenül kell dedikált útválasztókkal rendelkeznie, használhat nyílt forráskódú eszközöket, mint pl . Tehát talán csak egy szerverre vagy több szerverre, egy kapcsolóra és BGP-re van szüksége.
Ebben az esetben az Ön szervere vagy több szervere nemcsak CDN-szerver, hanem útválasztó szerepét is betöltheti. Természetesen még sok részlet van még (például az egyensúly biztosítása), de kivitelezhető, és ez egy olyan megközelítés, amelyet sikeresen alkalmaztunk egyik partnerünknél.
Több adatközpontja lehet teljes védelemmel (tűzfalak, internetszolgáltatók által biztosított DDOS védelmi szolgáltatások) és több tucat vagy száz „leegyszerűsített” jelenléti pont csak L2 kapcsolókkal és szerverekkel.
De mi a helyzet a védelemmel ebben az esetben?
Nézzük például a mostanában népszerű . Veszélye abban rejlik, hogy nagy mennyiségű forgalom generálódik, ami egyszerűen „eltömíti” az összes felfelé irányuló linkjét 100%-ban.
Mi van a tervezésünk esetében.
- ha AnyCast használ, akkor a forgalom megoszlik a jelenléti pontjai között. Ha a teljes sávszélessége terabit, akkor ez önmagában (a közelmúltban azonban több terabit nagyságrendű rosszindulatú forgalommal kapcsolatos támadás is történt) megvédi Önt a „túlcsordult” felfelé irányuló linkektől.
- Ha azonban néhány felfelé irányuló link eltömődik, akkor egyszerűen eltávolítja ezt a webhelyet a szolgáltatásból (hagyja abba az előtag hirdetését)
- növelheti a „teljes” (és ennek megfelelően védett) adatközpontjairól érkező forgalom arányát is, így a rosszindulatú forgalom jelentős része eltávolítható a nem védett jelenléti pontokról
És még egy apró megjegyzés ehhez a példához. Ha elegendő forgalmat küld az IX-eken keresztül, akkor ez is csökkenti az ilyen támadásokkal szembeni sebezhetőséget
BGP beállítása
Itt két téma van.
- Kapcsolódás
- BGP beállítása
A csatlakozásról már beszéltünk egy kicsit . A lényeg annak biztosítása, hogy ügyfelei felé irányuló forgalom az optimális utat kövesse. Bár az optimalitás nem mindig csak a késleltetésről szól, az alacsony késleltetés általában az optimálisság fő mutatója. Egyes cégek számára ez fontosabb, másoknak kevésbé. Minden az Ön által nyújtott szolgáltatástól függ.
Példa 1
Ha Ön egy csere, és ügyfelei számára fontosak az ezredmásodpercnél rövidebb időintervallumok, akkor természetesen szó sem lehet semmiféle internetről.
Példa 2
Ha Ön egy szerencsejáték-cég, és a több tíz ezredmásodperc fontos számodra, akkor természetesen a kapcsolat nagyon fontos számodra.
Példa 3
Azt is meg kell értenie, hogy a TCP-protokoll tulajdonságai miatt az egy TCP-munkameneten belüli adatátviteli sebesség az RTT-től (Round Trip Time) is függ. A probléma megoldására CDN-hálózatokat is építenek azáltal, hogy a tartalomelosztó szervereket közelebb helyezik a tartalom fogyasztóihoz.
Az összeköttetés tanulmányozása önmagában is érdekes téma, érdemes saját cikkre vagy cikksorozatra, és megköveteli az internet „működésének” alapos megértését.
Hasznos források:
Példa
Csak egy apró példát mondok.
Tegyük fel, hogy az adatközpont Moszkvában található, és egyetlen felfelé irányuló kapcsolata van - Rostelecom (AS12389). Ebben az esetben (egyházi) nincs szüksége BGP-re, és valószínűleg a Rostelecom címkészletét használja nyilvános címként.
Tegyük fel, hogy Ön egy bizonyos szolgáltatást nyújt, és elegendő számú ügyfele van Ukrajnából, és hosszú késésekre panaszkodnak. Kutatása során kiderült, hogy néhányuk IP-címe a 37.52.0.0/21 gridben található.
Egy nyomkövetési útvonal futtatásával látta, hogy a forgalom az AS1299-en (Telia) keresztül halad, és egy ping futtatásával 70-80 ezredmásodperces átlagos RTT-t kapott. Ezt a címen is megtekintheti .
A whois segédprogram segítségével (a ripe.net webhelyen vagy egy helyi segédprogramban) könnyen megállapíthatja, hogy a 37.52.0.0/21 blokk az AS6849-hez (Ukrtelecom) tartozik.
Következő, azáltal, hogy látod, hogy az AS6849-nek nincs kapcsolata az AS12389-cel (nem kliensek és nem is uplinkek egymáshoz, és nincs társviszonyuk). De ha megnézed Az AS6849 esetében például az AS29226 (Mastertel) és az AS31133 (Megafon) értékeket láthatja.
Miután megtalálta a szolgáltatók szemüvegét, összehasonlíthatja az útvonalat és az RTT-t. Például a Mastertel esetében az RTT körülbelül 30 ezredmásodperc lesz.
Tehát, ha a 80 és 30 ezredmásodperc közötti különbség jelentős a szolgáltatása szempontjából, akkor lehet, hogy gondolkodnia kell a csatlakozáson, meg kell szereznie AS-számát, címkészletét a RIPE-től, és további felfelé irányuló kapcsolatokat kell csatlakoztatnia és/vagy jelenléti pontokat kell létrehoznia az IX-eken.
Ha BGP-t használ, nemcsak a kapcsolat javítására nyílik lehetősége, hanem redundánsan karbantarthatja internetkapcsolatát is.
ajánlásokat tartalmaz a BGP beállításához. Annak ellenére, hogy ezeket az ajánlásokat a szolgáltatók „legjobb gyakorlata” alapján dolgozták ki, ennek ellenére (ha a BGP beállításai nem egészen alapszintűek) kétségtelenül hasznosak, és valójában részei kell legyenek annak a keményedésnek, amelyet a cikkben tárgyaltunk. .
DOS/DDOS védelem
Mára a DOS/DDOS támadások sok vállalat számára mindennapi valósággá váltak. Valójában elég gyakran támadnak ilyen vagy olyan formában. Az a tény, hogy ezt még nem vette észre, csak azt jelenti, hogy még nem szerveztek célzott támadást Ön ellen, és hogy az Ön által alkalmazott védelmi intézkedések, akár anélkül is, hogy tudta volna (az operációs rendszerek különféle beépített védelmei), elegendőek ahhoz, hogy biztosítsa, hogy a nyújtott szolgáltatás minőségromlása Ön és ügyfelei számára a lehető legkisebb legyen.
Vannak olyan internetes források, amelyek a felszerelési naplók alapján valós időben gyönyörű támadási térképeket rajzolnak.
linkeket találsz hozzájuk.
Kedvenceim a CheckPointból.
A DDOS/DOS elleni védelem általában réteges. Az okok megértéséhez meg kell értenie, hogy milyen típusú DOS/DDOS támadások léteznek (lásd pl. vagy )
Vagyis háromféle támadásunk van:
- volumetrikus támadások
- protokoll támadások
- alkalmazási támadások
Ha meg tudja magát védeni az utolsó két típusú támadástól például tűzfalak segítségével, akkor nem tudja magát megvédeni azoktól a támadásoktól, amelyek célja a felfelé irányuló linkek „túlterhelése” (természetesen, ha az internetes csatornák teljes kapacitását nem terabitben számoljuk, vagy ami még jobb, tíz terabitben).
Ezért az első védelmi vonal a „volumetrikus” támadások elleni védelem, és ezt a védelmet az Ön szolgáltatójának vagy szolgáltatóinak kell biztosítania Önnek. Ha ezt még nem vetted észre, akkor most csak szerencséd van.
Példa
Tegyük fel, hogy több uplinkje van, de csak az egyik szolgáltató tudja ezt a védelmet biztosítani. De ha az összes forgalom egy szolgáltatón keresztül megy, akkor mi a helyzet a kapcsolódási lehetőséggel, amelyet korábban röviden tárgyaltunk?
Ebben az esetben a támadás során részben fel kell áldoznia a kapcsolatot. De
- ez csak a támadás idejére vonatkozik. Támadás esetén manuálisan vagy automatikusan átkonfigurálhatja a BGP-t úgy, hogy a forgalom csak az „esernyőt” biztosító szolgáltatón keresztül menjen keresztül. A támadás befejezése után visszaállíthatja az útválasztást az előző állapotába
- Nem szükséges a teljes forgalmat átadni. Ha például azt látja, hogy nincsenek támadások egyes uplinkeken vagy társviszony-kapcsolatokon keresztül (vagy a forgalom nem jelentős), akkor továbbra is hirdethet kompetitív attribútumokat tartalmazó előtagokat ezeknek a BGP-szomszédokoknak.
A „protokolltámadások” és „alkalmazástámadások” elleni védelmet is átruházhatja partnereire.
Itt olvashatsz egy jó tanulmányt (). Igaz, a cikk két éves, de ötletet ad azokról a megközelítésekről, amelyekkel megvédheti magát a DDOS támadásoktól.
Elvileg erre korlátozhatja magát, teljesen kiszervezve a védelmét. Ennek a döntésnek vannak előnyei, de van egy nyilvánvaló hátránya is. A helyzet az, hogy beszélhetünk (ismét attól függően, hogy mit csinál a cége) a vállalkozás fennmaradásáról. És az ilyesmit harmadik félre bízza...
Ezért nézzük meg, hogyan kell megszervezni a második és harmadik védelmi vonalat (a szolgáltatótól való védelem kiegészítéseként).
Tehát a második védelmi vonal a szűrés és a forgalomkorlátozók (rendőrök) a hálózat bejáratánál.
Példa 1
Tételezzük fel, hogy az egyik szolgáltató segítségével esernyővel borítottad magad a DDOS ellen. Tegyük fel, hogy ez a szolgáltató az Arbort használja a forgalom szűrésére és a hálózata szélén lévő szűrőkre.
Az Arbor által „feldolgozható” sávszélesség korlátozott, és a szolgáltató természetesen nem tudja folyamatosan szűrőberendezésen átengedni minden szolgáltatást megrendelő partnerének forgalmát. Ezért normál körülmények között a forgalom nem szűrhető.
Tegyük fel, hogy SYN árvíztámadás történt. Még ha olyan szolgáltatást is rendelt, amely támadás esetén automatikusan szűrésre állítja át a forgalmat, ez nem történik meg azonnal. Egy percig vagy tovább támadás alatt maradsz. Ez pedig a berendezés meghibásodásához vagy a szolgáltatás romlásához vezethet. Ebben az esetben a forgalom korlátozása a szélső útválasztáson, bár ez azt a tényt eredményezi, hogy bizonyos TCP-munkamenetek nem jönnek létre ezalatt az idő alatt, megóvja infrastruktúráját a nagyobb léptékű problémáktól.
Példa 2
A szokatlanul nagy számú SYN-csomag nem csak egy SYN-áradás támadás eredménye lehet. Tegyük fel, hogy olyan szolgáltatást nyújt, amelyben egyidejűleg körülbelül 100 ezer TCP-kapcsolata lehet (egy adatközponthoz).
Tegyük fel, hogy az egyik fő szolgáltatójával kapcsolatos rövid távú probléma eredményeként a munkameneteinek fele megszakad. Ha az alkalmazás úgy van megtervezve, hogy kétszeri gondolkodás nélkül azonnal (vagy bizonyos, minden munkamenetre azonos időintervallum után) megpróbálja újra létrehozni a kapcsolatot, akkor körülbelül 50 ezer SYN csomagot fog kapni. egyidejűleg.
Ha például ssl/tls kézfogást kell futtatnia ezen munkamenetek tetején, ami tanúsítványcserével jár, akkor a terheléselosztó erőforrásainak kimerülése szempontjából ez sokkal erősebb „DDOS” lesz, mint egy egyszerű. SYN árvíz. Úgy tűnik, hogy az egyensúlyozóknak kezelniük kellene az ilyen eseményeket, de... sajnos ilyen problémával állunk szemben.
És természetesen ebben az esetben is egy rendőr a szélső útválasztón megmenti a felszerelését.
A DDOS/DOS elleni védelem harmadik szintje a tűzfal beállításai.
Itt leállíthatja a második és harmadik típusú támadásokat is. Általánosságban elmondható, hogy itt minden, ami eléri a tűzfalat, szűrhető.
Tanács
Próbáljon meg a lehető legkevesebb munkát adni a tűzfalnak, és a lehető legtöbbet szűrje ki az első két védelmi vonalon. És ezért.
Előfordult már veled, hogy véletlenül, miközben forgalmat generált, hogy ellenőrizze például, mennyire ellenálló a szerverei operációs rendszere a DDOS támadásokkal szemben, „megölte” a tűzfalát, 100 százalékig betöltve, normál intenzitású forgalom mellett ? Ha nem, lehet, hogy egyszerűen azért, mert nem próbáltad?
Általánosságban elmondható, hogy a tűzfal, mint mondtam, egy összetett dolog, jól működik az ismert sérülékenységekkel és a tesztelt megoldásokkal, de ha valami szokatlant küldesz, csak valami szemetet vagy rossz fejlécekkel ellátott csomagokat, akkor némelyikkel vagy, nem ilyen kis valószínűséggel (tapasztalataim alapján) még a csúcstechnikát is el lehet ámítani. Ezért a 2. szakaszban a szokásos ACL-ek használatával (L3/L4 szinten) csak olyan forgalmat engedjen be a hálózatba, amelynek oda be kell lépnie.
Forgalom szűrése a tűzfalon
Folytassuk a beszélgetést a tűzfalról. Meg kell értenie, hogy a DOS/DDOS támadások csak egyfajta kibertámadás.
A DOS/DDOS védelem mellett az alábbi szolgáltatások listája is lehet:
- alkalmazás tűzfal
- fenyegetésmegelőzés (vírusirtó, kémprogram-elhárító és sebezhetőség)
- URL-szűrés
- adatszűrés (tartalomszűrés)
- fájlblokkolás (fájltípusok blokkolása)
Ön dönti el, mire van szüksége ebből a listából.
Ahhoz, hogy továbbra is
Forrás: will.com