Ez a cikk a "Hogyan kontrolláljuk a hálózati infrastruktúrát" ciklusciklus negyedik része. A ciklus összes cikkének tartalmát és hivatkozásait itt találja. itt.

A első részben Ebben a fejezetben áttekintettük a "Data Center" szegmens hálózati biztonságának egyes aspektusait. Ez a rész az "Internet Access" szegmensre összpontosít.

Internet hozzáférés

A biztonság témája kétségtelenül az egyik legbonyolultabb téma az adatátviteli hálózatok világában. Mint az előző esetekben, ebben az esetben sem a mélységre és teljeskörűségre törekszem, de itt figyelembe veszek néhány elég egyszerű, de szerintem fontos kérdést, melyekre adott válaszok remélhetőleg segítenek növelni a hálózata biztonságát.

A szegmens auditálásakor vegye figyelembe a következő szempontokat:

design
BGP beállítások
DOS/DDOS védelem
forgalom szűrése a tűzfalon

Tervezés

Mint a szegmens tervezésének példáját a vállalati hálózat számára, ajánlanám a kézikönyvet a Cisco termékét a SAFE modelltől.

Nyilvánvaló, hogy más gyártók megoldása vonzóbbnak tűnhet Önnek (lásd a Gartner 2018-as quadrants), de anélkül, hogy arra bátorítanám Önt, hogy a dizájn részleteit kövesse, azért hasznosnak tartom, hogy megértsük az alapelveket és ötleteket, amelyek mögött állnak.

Megjegyzés
A SAFE szegmens "Remote Access" része az "Internet Access"-nak. De ebben a cikkciklusban külön fogjuk megvizsgálni.

A szegmensben a vállalati hálózathoz (enterprise network) standard hardver készletként a következők tartoznak:

határrouterek (border routers)
tűzfalak

Megjegyzés 1
Ebben a cikkciklusban, amikor a tűzfalakról beszélek, a NGFW-ra gondolok..

Megjegyzés 2
Kihagyom a különböző L2/L1 vagy L2 over L3 megoldások vizsgálatát, amelyek szükségesek az L1/L2 kapcsolódás biztosításához, és csak az L3 és annál magasabb szintű kérdésekkel foglalkozom. Részben az L1/L2 kérdéseket a "Tisztítás és dokumentáció" című fejezetben már érintettük.«.

Ha nem találja a tűzfalat ebben a szegmensben, ne sietjen a következtetések levonásával.

Kezdjük mint az előzőben, a kérdéssel, hogy szükséges-e a tűzfal használata ebben a szegmensben az Ön esetében? az előző részbenElmondhatom, hogy úgy tűnik, ez a legindokoltabb hely a tűzfalak használatára és bonyolult forgalomszűrési algoritmusok alkalmazására. A

korábbi cikkben említettük a 4 tényezőt, amelyek megakadályozhatják a tűzfalak használatát az adatközpont szegmensben. De itt már nem olyan jelentősek. az 1. részben említettünk 4 tényezőt, amelyek megakadályozhatják a tűzfalak használatát az adatközponti szegmensben. De itt már nem olyan lényegesek.

Példa 1. Késleltetés
Ami az internetet illeti, nincs értelme még 1 millisekundumos késésekről is beszélni. Ezért a késés ezen a területen nem lehet az a tényező, amely a tűzfalak használatát korlátozza.

Példa 2. Teljesítmény
Bizonyos esetekben ez a tényező továbbra is jelentős lehet. Ezért előfordulhat, hogy a forgalom egy részét (például a terheléselosztók forgalmát) a tűzfalak megkerülésére kell irányítani.

Példa 3. Megbízhatóság
Ezt a tényezőt továbbra is figyelembe kell venni, de figyelembe véve az internet megbízhatatlanságát, ennek jelentősége nem olyan hangsúlyos, mint az adatközpont esetében.
Tegyük fel, hogy a szolgáltatása http/https felett működik (rövid session-ökkel). Ebben az esetben két független boxot (HA nélkül) használhat, és ha az egyiknél problémák lépnek fel, akkor az összes forgalmat a másikra irányíthatja.
Vagy tűzfalakat használhat átlátható módban, és ha ezek meghibásodnak, akkor a probléma megoldásáig a forgalmat a tűzfalakon kívül irányíthatja.

Ezért valószínűleg éppen csak ár ez lehet az a tényező, amely miatt el kellene vetnie a tűzfalak használatát ezen a területen.

Fontos!
Kísértés támad arra, hogy ezt a tűzfalat az adatközpont tűzfalával kombinálja (egy tűzfalat használjon ezekhez a szegmensekhez). A döntés alapvetően lehetséges, de figyelembe kell venni, hogy mivel a "Internet Access" tűzfal valójában a védelem első vonalában áll, és "átvesz" legalább egy részét a káros forgalomnak, természetesen figyelembe kell venni a fokozott kockázatot, hogy ez a tűzfal meghibásodik. Tehát, ha ugyanazokat az eszközöket használja e két területen, jelentősen csökkenti az adatközpont szegmens elérhetőségét.

Mint mindig, fontos megérteni, hogy a szolgáltatástól függően, amit a cég nyújt, ennek a szegmensnek a tervezése jelentősen eltérhet. Mint általában, különböző megközelítéseket választhat a követelmények függvényében.

támadásra
Ha Ön tartalomszolgáltató, CDN-nel (lásd például, cikkek sorozatát), lehet, hogy nem szeretne több tucat, esetleg akár több száz jelenlét-pontra infrastruktúrát létrehozni külön eszközökkel a forgalom terelésére és szűrésére. Ez drága lenne, és egyszerűen felesleges is lehet.
A BGP-hez nem feltétlenül szükséges dedikált routerek, használhat open-source eszközöket is, mint például Quagga. Így lehet, hogy mindössze egy szerverre vagy néhány szerverre, valamint egy switchre és a BGP-re van szüksége.
Ebben az esetben a szervere(i) nemcsak CDN-szerverként funkcionálhatnak, hanem routerként is. Természetesen sok részlet van itt (például a terheléselosztás biztosítása), de ez megvalósítható, és ezt a megközelítést sikeresen alkalmaztuk egyik partnerünknél.
Több adatközpontja is lehet teljes védelmmel (tűzfalak, DDoS elleni védelmi szolgáltatások, amelyeket az internetszolgáltatók nyújtanak) és tucatnyi vagy akár száznyi "egyszerűsített" jelenlét ponttal, csupán L2 switch-ekkel és szerverekkel.
De mi a helyzet a védelemmel ebben az esetben?
Nézzük például a közelmúltban népszerűvé vált DNS Amplification DDoS támadást. A veszély az, hogy hatalmas mennyiségű forgalmat generál, amely egyszerűen 100%-ban "elárasztja" az összes uplinket.
Mi történik a mi dizájnunk esetében?

Ha Anycast-ot használ, akkor a forgalom eloszlik a jelenlét-pontjai között. Ha az összesített sávszélessége terabiteket tesz ki, akkor ez önmagában gyakorlatilag (bár mostanában volt néhány terabit nagyságú ártalmas forgalmú támadás) megvéd az "uplinkek" "túlcsordulásától".

Ha azonban bármely uplink "el van torlódva", akkor egyszerűen kivonja ezt a helyet a forgalomból (megszünteti a prefix hirdetését).

A forgalom arányát is növelheti, amely a "teljes" (és ezért védett) adatközpontjaiból származik, ezzel jelentős részét eltávolítva a nem védett jelenlét-pontok ártalmas forgalmának.
És még egy kis megjegyzés ehhez a példához. Ha elegendő forgalmat bocsát ki IX-eken keresztül, az szintén csökkenti az ilyen támadásoknak való kitettségét.

BGP beállítása

Két téma van itt.

Összeköttetés
BGP beállítása

A kapcsolódásról már egy kicsit beszéltünk a az 1. részben. A lényeg az, hogy a forgalom optimális úton menjen az ügyfeleihez. Bár az optimalitás nem mindig csak a késleltetésről szól, de általában a kis késleltetés a fő mutatója az optimalitásnak. Néhány cégnek ez fontosabb, másoknak kevésbé. Mindez attól függ, hogy milyen szolgáltatást nyújt.

1. példa
Ha Ön egy tőzsde, és ügyfelei számára fontosak a milliszekundumos időközök, akkor nyilvánvaló, hogy az internetről szó sem lehet.

Példa 2
Ha Ön egy játékcég, és az Ön számára fontosak a tizedmásodperces időközök, akkor természetesen a kapcsolat stabilitása kiemelten fontos Önnek.

3. példa
Fontos megérteni, hogy a TCP protokoll sajátosságai miatt az adatok átvitelének sebessége egy TCP szesszió keretein belül szintén függ a RTT-től (Round Trip Time). A CDN hálózatok többek között ezt a problémát is megoldják, azáltal, hogy a tartalom elosztó szervereket közelebb hozzák a tartalmat fogyasztóhoz.

A kapcsolat stabilitásának vizsgálata egy külön érdekes téma, amely önálló cikket vagy cikk sorozatot érdemel, és jó megértést igényel arról, hogy az internet hogyan "működik".

Hasznos források:

ripe.net
bgp.he.net

támadásra
Csak egy kis példát említek.
Tegyük fel, hogy az Ön adatközpontja Moszkvában található, és van egyetlen uplinkje – a Rosztelkom (AS12389). Ebben az esetben (single homed) a BGP-re nincs szükség, és valószínű, hogy a nyilvános IP-címeket a Rosztelkomtól kapja.
Tegyük fel, hogy egy szolgáltatást nyújt, és van elegendő számú ügyfele Ukrajnából, akik nagy késleltetésre panaszkodnak. A vizsgálat során kiderítette, hogy néhányuk IP címe a 37.52.0.0/21 tartományban található.
Traceroute végrehajtásával látta, hogy a forgalom az AS1299 (Telia) hálózaton keresztül halad, és ping végrehajtásával 70–80 milliszekundumos átlagos RTT-t kapott. Ezt látja például a Rosztelkom looking glass-án.
A whois segédprogrammal (a ripe.net weboldalon vagy helyi segédprogrammal) könnyen megállapíthatja, hogy a 37.52.0.0/21 tartomány az AS6849-hez (Ukrtelecom) tartozik.
Ezután, ha belép az bgp.he.net oldalra, látja, hogy az AS6849-nek nincsenek kapcsolatai az AS12389-cel (nem ügyfelei, és nem uplinkek egymásnak, és nincs peeringjük sem). De ha megnézi a peer lista az AS6849 számára, akkor például látni fogja az AS29226-ot (Mastertel) és az AS31133-t (Megafon).
Ezektől a szolgáltatóktól looking glass-t találva összehasonlíthatja az útvonalat és az RTT-t. Például a Mastertel esetében az RTT körülbelül 30 milliszekundum lesz.
Tehát ha a különbség a 80 és 30 milliszekundum között lényeges az Ön szolgáltatása számára, akkor valószínűleg érdemes elgondolkodnia a kapcsolat stabilitásáról, megkapnia a RIPE-től az AS számát, a címtartományát, és további uplinkeket csatlakoztatnia és/vagy IX-eken pontokat létrehoznia.

A BGP használatával nemcsak a kapcsolatok javításának lehetőségét kapja, hanem az internetkapcsolata biztonságát is garantálja.

Ez a dokumentum ajánlásokat tartalmaz a BGP beállítására. Bár ezek az ajánlások a szolgáltatók „legjobb gyakorlatának” alapján készültek, mégis (ha a BGP-beállításai nem teljesen alapvetőek) mindenképpen hasznosak, és gyakorlatilag a hardening részét kell képezniük, amelyet a(z) első részben.

DOS/DDOS védelem

Jelenleg a DOS/DDOS támadások mindennapi valósággá váltak sok cég számára. Valójában, valamilyen formában gyakran megtámadják Önt. Az, hogy eddig nem észlelte ezt, csupán annyit jelent, hogy eddig nem történt dirigált támadás Ön ellen, és hogy a használt védelmi eszközök, akár észre sem véve (különböző operációs rendszerek beépített védelmei), elégségesek ahhoz, hogy a szolgáltatások degradációja minimális legyen az Ön és az ügyfelei számára.

Vannak olyan internetes források, amelyek az eszközök naplóin alapulva, valós időben szép támadás-térképeket készítenek.

Itt ezekre található linkek.

A kedvencem térkép a CheckPoint-tól.

A DDOS/DOS védekezés általában rétegezett. Ahhoz, hogy megértsük, miért, meg kell értenünk, hogy milyen típusú DOS/DDOS támadások léteznek (lásd például, itt vagy itt)

Tehát három támadástípusunk van:

volumetrikus támadások
protokoll támadások
alkalmazás támadások

Ha az utolsó két támadástípust önállóan védheti, például tűzfalak használatával, akkor a „túlterhelés” támadásokkal szemben nem tudja megvédeni magát (nyilvánvalóan, ha az internetkapacitása nem terabitokban mérhető, hanem lehetőleg tucatnyi terabitban).

Ezért az első védelmi vonal a volumetrikus támadások elleni védelem, amelyet az Ön szolgáltatójának vagy szolgáltatóinak kell biztosítaniuk. Ha ezt még nem ismerte fel, akkor egyszerűen szerencsés.

támadásra
Tegyük fel, hogy van néhány uplinkje, de csak az egyik szolgáltató tudja biztosítani Önnek ezt a védelmet. De ha az összes forgalom egyetlen szolgáltatón keresztül halad, akkor mi lesz a kapcsolatokkal, amelyeket korábban röviden megvitatottunk?
A támadás ideje alatt ebben az esetben részben fel kell áldoznia a kapcsolatok integritását. De

Ez csak a támadás idejére vonatkozik. Támadás esetén manuálisan vagy automatikusan újra konfigurálhatja a BGPe-t, így a forgalom csak azon szolgáltatón keresztül halad, amely "ernyőt" biztosít önnek. A támadás után a routing visszaállítható az eredeti állapotába.

Nem szükséges az összes forgalmat átkonfigurálni. Ha például látja, hogy bizonyos uplinkeken vagy peeringeken nincs támadás (vagy a forgalom nem jelentős), folytathatja a prefixek versenyképes attribútumokkal történő hirdetését ezek felé a BGP szomszédok felé.

A "protocol attacks" és "application attacks" elleni védelmet szintén átadhatja partnereinek.
Íme itt Jó kutatást olvashat (fordítás). Igaz, hogy a cikk két évvel ezelőtti, de ez betekintést ad abba, hogyan védheti meg magát a DDOS támadások ellen.

Alapvetően ezen is korlátozhatja magát, teljesen kiszervezve a védelmét. Ennek a megoldásnak vannak előnyei, de nyilvánvaló hátrányai is. A helyzet az, hogy az iparágtól függően életben maradása a vállalkozásának is múlhat ezen. És ilyen kérdésekkel külső szervezetekre bízni...

Ezért nézzük meg, hogyan lehet szervezni a második és harmadik védelmi vonalat (a szolgáltató védelme mellett).

Tehát a második védelmi vonal a forgalom szűrése és a limitálók (policers) a hálózatába való belépéskor.

1. példa
Tegyük fel, hogy "ernyővel" zárta le a DDOS-t az egyik szolgáltató segítségével. Tegyük fel, hogy ez a szolgáltató Arbor-t használ a forgalom szűrésére és szűrőkre a saját hálózatának határán.
A sávszélesség, amelyet az Arbor "feldolgozni" tud, korlátozott, és a szolgáltató természetesen nem tudja folyamatosan engedni, hogy minden partnerének, aki ezt a szolgáltatást megrendelte, a forgalma átjusson a szűrőberendezéseken. Ezért normál körülmények között a forgalmat nem szűrik.
Tegyük fel, hogy SYN flood támadás zajlik. Még ha megrendelte is azt a szolgáltatást, amely esetén a támadás alatt a forgalmat automatikusan szűrésre irányítják, ez nem történik meg azonnal. Egy perc vagy több időt is igénybe vehet, amíg a támadás alatt marad. Ez akár a berendezései meghibásodásához vagy a szolgáltatás degradációjához is vezethet. Ebben az esetben a határon lévő forgalom korlátozása, bár bizonyos TCP kapcsolatok ezen idő alatt nem fognak létrejönni, megvédheti infrastruktúráját a nagyobb problémáktól.

Példa 2
Anomálisan nagy számú SYN csomag nemcsak SYN flood támadás eredménye lehet. Tegyük fel, hogy olyan szolgáltatást nyújt, amely esetében egyszerre körülbelül 100 ezer TCP kapcsolat lehet (egy adatközpontban).
Tegyük fel, hogy egy rövid ideig tartó probléma miatt az egyik fő szolgáltatójával a kapcsolatok fele „kiesett”. Ha az alkalmazása úgy van kialakítva, hogy azonnal (vagy minden kapcsolat számára azonos időintervallum után) próbálja meg újra létrehozni a kapcsolatot, akkor körülbelül egy időben legalább 50 ezer SYN csomagot fog kapni.
Ha ezen kapcsolatok felett ssl/tls kézfogás kell, ami tanúsítványok cseréjét jelenti, akkor a források kimerülése szempontjából a terheléselosztójának ez sokkal erősebb „DDoS” probléma lesz, mint egy egyszerű SYN flood. Úgy tűnhet, hogy a terheléselosztóknak kezelniük kellene az ilyen eseményeket, de... sajnos, ezzel a problémával teljes mértékben szembesültünk.
És természetesen a policer a határon lévő routeren meg fogja menteni az Ön berendezését ebben az esetben is.

A DDoS/DOS ellenállás harmadik szintje a tűzfala beállításai.

Itt a második és harmadik típusú támadásokat is kezelheti. Általánosságban véve, ami a tűzfalgig eljut, azt itt lehet szűrni.

Tipp
Próbálja meg a tűzfalnak a lehető legkevesebb munkát adni, és szűrje meg a lehető legtöbbet az első két védelmi vonalon. És ez az oka.
Előfordult már veled, hogy véletlenül a forgalom generálása közben, például a szervereid operációs rendszerének DDOS támadásokkal szembeni ellenálló képességét tesztelve "megölöd" a tűzfaladat, 100%-os terheltségig feltöltve azt, miközben normál intenzitású forgalmat használsz? Ha nem, lehet, hogy csak azért, mert még nem próbáltad ki?
Általában a tűzfal, ahogy már mondtam – bonyolult dolog, és jól működik a jól ismert sebezhetőségekkel és tesztelt megoldásokkal, de ha valami szokatlant küldesz, csak valami szemét vagy hibás fejlécekkel rendelkező csomagokat, akkor egy bizonyos, nem túl kicsi (tapasztalataim szerint) valószínűséggel megzavarhatod a csúcsberendezéseket is. Ezért a 2. lépésnél az általános ACL-ek (L3/L4 szinten) segítségével csak azon forgalmat engedd be a hálózatodba, amelyiknek be kell lépnie.