Ky kjo artikull është e katërta në serinë e artikujve "Si të marrim nën kontroll infrastrukturën rrjetësore". Përmbajtjen e gjithë serisë së artikujve dhe lidhjet mund t'i gjeni këtu.

Në pjesën e parë në këtë kapitull ne shqyrtuam disa aspekte të sigurisë rrjetësore të segmentit "Qendra e të Dhënave". Ky pjesë do të jetë e përkushtuar segmentit "Qasje në Internet".

Qasja në Internet

Tema e sigurisë padyshim që është një nga temat më të komplikuara në botën e rrjetave të transmetimit të të dhënave. Si në rastet e mëparshme, pa pretenduar për thellësi dhe plotësi, do të shqyrtoj këtu disa pyetje mjaft të thjeshta, por, sipas mendimit tim, të rëndësishme, përgjigjet e të cilave shpresoj se do të ndihmojnë në rritjen e nivelit të sigurisë së rrjetit tuaj.

Gjatë auditi të këtij segmenti, kushtoni vëmendje aspekteve të mëposhtme:

i instaluesit është futur. Po ashtu, është disponueshme mundësia për të instaluar driverin pronësor për kartat grafike Nvidia gjatë instalimit të sistemit operativ dhe dy mënyra për ndarjen e disqeve: plotësisht manuale dhe automatike me enkriptimin e plotë të të gjitha pjesëve.
konfigurimit të BGP
Mbrojtja DOS/DDOS
filtrimin e trafikut në firewall

Dizajni

Si një shembull të dizajnit të këtij segmenti për rrjetin e ndërmarrjes, do të rekomandoja manual nga Cisco në kuadër të modelit SAFE.

Natyrisht, mund të duket se zgjidhjet e ofruesve të tjerë janë më tërheqëse për ju (shih katrori i Gartner për 2018), por, pa ju inkurajuar të ndiqni këtë dizajn në detaje, unë gjithashtu e mendoj të dobishëm të kuptoni parimet dhe idetë që qëndrojnë në themel të tij.

Vërejtje
Në segmentin SAFE, "Qasja e Largët" është një pjesë e "Qasjes në Internet". Por në këtë seri artikujsh do ta shqyrtojmë atë veçmas.

Grupi standard i pajisjeve në këtë segment për rrjetin e ndërmarrjes (enterprise network) janë

routerat kufitarë (border routers)
firewall-et

Shënim 1
Në këtë seri artikujsh, kur flas për firewall, nënkuptoj NGFW.

Shënim 2
Unë nuk diskutoj për lloje të ndryshme të zgjidhjeve L2/L1 ose L2 mbi L3 të nevojshme për të siguruar lidhshmëri L1/L2 dhe kufizohem vetëm me çështjet e nivelit L3 dhe lart. Pjesërisht, çështjet L1/L2 janë shqyrtuar në kapitullin "Pastrimi dhe dokumentimi«.

Nëse nuk e keni identifikuar një firewall në këtë segment, mos u nxito për të nxjerrë përfundime.

Le të fillojmë, si në pjesën e kaluar, me pyetjen, a është e nevojshme përdorimi i një firewall në këtë segment në rastin tuaj?

Mund të them se, duket se kjo është vendi më i arsyeshëm për përdorimin e firewall-eve dhe për aplikimin e algoritmeve komplekse të filtrimit të trafikut. Në pjesa 1 ne përmendëm 4 faktorë që mund të pengojnë përdorimin e firewall-eve në segmentin e qendrës së të dhënave. Por këtu ata nuk janë më kaq thelbësorë.

Shembulli 1. Vonesa
Në lidhje me internetin, nuk ka kuptim të flitet për vonesa edhe prej 1 milisekunde. Prandaj, vonesa në këtë segment nuk mund të jetë një faktor që kufizon përdorimin e firewall-it.

Shembulli 2. Performanca
Në disa raste, ky faktor ende mund të jetë thelbësor. Prandaj, ndoshta do të duhet të drejtoni një pjesë të trafikut (për shembull, trafikun e balancuesve të ngarkesës) përmes një mënyre bypass, përveç firewall-it.

Shembulli 3. Besueshmëria
Ky faktor ende duhet të merret parasysh, por duke marrë parasysh pabesueshmërinë e vetë internetit, rangu i tij në këtë segment nuk është aq i rëndësishëm sa për qendrën e të dhënave.
Kështu, le të supozojmë se shërbimi juaj ekziston mbi http/https (me seanca të shkurtra). Në këtë rast, mund të përdorni dy kutia të pavarura (pa HA) dhe në rast të ndonjë problemi me njërën prej tyre, të redirigjoni të gjithë trafikun në të dytën.
Ose mund të përdorni firewall-et në modalitetin transparent dhe, në rast se ato dalin jashtë funksionit, përkohësisht të lejoni trafikun të kalojë përmes firewall-eve.

Prandaj, ndoshta është vetëm çmimi ai faktor që do t'ju detyrojë të heqni dorë nga përdorimi i firewall-eve në këtë segment.

Ë rëndësishme!
Ka një tundim të kombinohet ky firewall me firewall-in e qendrës së të dhënave (të përdoret një firewall për këto segmente). Një zgjidhje, në parim, është e mundur, por, megjithatë, duhet të kuptohet se, duke qenë se "Access-i në Internet" firewall-i është faktikisht në vijën e parë të mbrojtjes tuaj dhe "merr përsipër", të paktën, një pjesë të trafikut të dëmshëm, është e qartë se duhet të merret parasysh rreziku i rritur që ky firewall mund të dështojë. Pra, duke përdorur të njëjtat pajisje në këto dy segmente, do ta ulni në mënyrë të konsiderueshme disponueshmërinë e segmentit të qendrës së të dhënave.

Si zakonisht, është e rëndësishme të kuptohet se në varësi të shërbimit që kompania ofron, dizajni i këtij segmenti mund të ndryshojë shumë. Ju, si zakonisht, mund të zgjidhni qasje të ndryshme në varësi të kërkesave.

Shembulli
Nëse jeni një ofrues përmbajtjeje me një rrjet CDN (shihni, për shembull, serinë e artikujve), atëherë mund të mos dëshironit të krijonit në dhjetëra, madje qindra pikë pranimi infrastrukture duke përdorur pajisje të ndryshme për ruterizimin dhe filtrimin e trafikut. Kjo do të ishte e shtrenjtë dhe madje mund të ishte e tepruar.
Për BGP nuk është aspak e nevojshme të keni router të dedikuar, mund të përdorni mjete open-source, për shembull, Quagga. Kështu, ndoshta gjithçka që ju nevojitet është një server ose disa servera, një switch dhe BGP.
Në këtë rast, serveri juaj ose disa servera mund të luajnë rolin jo vetëm të një serveri CDN, por gjithashtu edhe të një routeri. Sigurisht, ka akoma shumë detaje (për shembull, si të sigurohet balancimi), por kjo është e realizueshme, dhe këtë qasje e kemi zbatuar me sukses për një nga partnerët tanë.
Ju mund të keni disa qendra të të dhënave me mbrojtje të plotë (firewall, shërbime të mbrojtjes nga DDOS, ofruar nga ofruesit tuaj të internetit) dhe dhjetëra ose qindra pika të pranishme "të thjeshta" vetëm me switches L2 dhe servera.
Por si qëndron mbrojtja në këtë rast?
Le të shqyrtojmë, për shembull, sulmin e njohur kohët e fundit DNS Amplification DDOS. Rreziku i tij qëndron në faktin se prodhohet një sasi e madhe trafiku, e cila thjesht "bllokon" 100% të të gjitha uplink-ëve tuaj.
Çfarë kemi në rastin e dizajnit tonë.

nëse përdorni AnyCast, atëherë trafiku shpërndahet midis pikave tuaja të pranishme. Nëse bandwidth-a totale është terabita, atëherë kjo në vetvete (edhe pse kohët e fundit kishte disa sulme me trafik të dëmshëm që arrinin deri në terabita) ju mbron nga "mbingarkesa" e uplink-ëve.

nëse ndonjë uplink është "bllokuar", atëherë thjesht e hiqni këtë platformë nga shërbimi (ndaloni të shpallni prefix-in).

ju gjithashtu mund të rritni pjesën e trafikut që jepni nga qendrat tuaja të të dhënave "të plota" (dhe, për pasojë, të mbrojtura), duke larguar kështu një pjesë të rëndësishme të trafikut të dëmshëm nga pikat e pranishme të pambrojtura.
Dhe një vërejtje e vogël për këtë shembull. Nëse një sasi e mjaftueshme e trafikut kalon nëpër IX, kjo gjithashtu zvogëlon ndjeshmërinë tuaj ndaj sulmeve të tilla.

Konfigurimi i BGP

Këtu ka dy tema.

Lidhshmëria
Konfigurimi i BGP

Për lidhshmërinë kemi folur pak më parë në pjesa 1. Thelbi është që trafiku për klientët tuaj të kalojë në rrugën më optimale. Megjithatë, optimaliteti nuk është gjithmonë vetëm për vonesën, por zakonisht vonesa e ulët është treguesi kryesor i optimalitetit. Për disa kompani, kjo është më e rëndësishme, për të tjera - më pak. Varet nga shërbimi që ofroni.

Shembulli 1
Nëse jeni një exchange, dhe intervalet e kohës më pak se mili-sekonda janë të rëndësishme për klientët tuaj, atëherë, padyshim, nuk ka asnjë fjalë për internetin në përgjithësi.

Shembulli 2
Nëse jeni një kompani lojërash, dhe janë të rëndësishme dhjetra mili-sekonda për ju, atëherë, sigurisht, lidhshmëria është shumë e rëndësishme.

Shembulli 3
Po ashtu, duhet të kuptoni se, për shkak të vetive të protokollit TCP, shpejtësia e transferimit të të dhënave brenda një seance TCP varet gjithashtu nga RTT (Round Trip Time). Rrjetet CDN ndërtohen gjithashtu për të zgjidhur këtë problem, duke e sjellë serverët e shpërndarjes së përmbajtjes më afër konsumatorit të kësaj përmbajtjeje.

Hulumtimi i lidhshmërisë është një temë interesante e veçantë, e cila meriton një artikull të veçantë ose një seri artikujsh dhe kërkon një kuptim të mirë se si është "ndërtuar" interneti.

Burimet e dobishme:

ripe.net
bgp.he.net

Shembulli
Do të jap vetëm një shembull të vogël.
Supozoni se qendra juaj e të dhënave ndodhet në Moskë, dhe keni një uplink të vetëm – Rostelecom (AS12389). Në këtë rast (single homed) BGP ju nevojitet, dhe si adresat publike do të përdorni, me siguri, një grup adresash nga Rostelecom.
Supozoni se ofroni një shërbim, dhe keni një numër të mjaftueshëm klientësh nga Ukraina, dhe ata ankojnë për vonesa të mëdha. Gjatë hulumtimit, keni zbuluar se adresat IP të disa prej tyre janë në rrjetin 37.52.0.0/21.
Duke kryer traceroute, keni parë se trafiku kalon përmes AS1299 (Telia), dhe duke kryer ping, keni marrë një RTT mesatar prej 70 — 80 mili-sekonda. Mund ta shihni këtë gjithashtu në looking glass të Rostelecom.
Me utilitarin whois (në faqen e ripe.net ose utilitarin lokal) lehtësisht mund të përcaktoni se blloku 37.52.0.0/21 i përket AS6849 (Ukrtelecom).
Më tej, duke hyrë në bgp.he.net shihni se AS6849 nuk ka marrëdhënie me AS12389 (ata nuk janë as klientë, as uplinks për njëri-tjetrin, as nuk kanë peering). Por nëse shikoni në listën e peer-ëve për AS6849, do të shihni, për shembull, AS29226 (Mastertel) dhe AS31133 (Megafon).
Duke gjetur looking glass të këtyre ofruesve, mund të krahasoni rrugën dhe RTT. Për shembull, për Mastertel RTT do të jetë rreth 30 mili-sekonda.
Pra, nëse ndryshimi midis 80 dhe 30 mili-sekondave është thelbësor për shërbimin tuaj, atëherë ndoshta duhet të mendoni për lidhshmërinë, të merrni në RIPE numrin tuaj AS, grupin tuaj të adresave dhe të lidheni me uplink të tjera dhe\/ose të krijoni pika prezence në IX.

Duke përdorimit të BGP, jo vetëm që keni mundësinë të përmirësoni lidhshmërinë, por gjithashtu rezervoni lidhjen tuaj me internetin.

Ky dokument përmban rekomandime për konfigurimin e BGP. Megjithëse këto rekomandime janë hartuar mbi bazën e "praktikave më të mira" të ofruesve, ato janë padyshim të dobishme dhe realisht duhet të jenë pjesë e hardening-ut që diskutuam në pjesën e parë.

Mbrojtja DOS/DDOS

Aktualisht, sulmet DOS/DDOS janë bërë një realitet i zakonshëm për shumë kompani. Në të vërtetë, në një formë ose në një tjetër, ju sulmoheni mjaft shpesh. Ajo që nuk e vini re deri tani thotë vetëm se ende nuk është organizuar një sulm i drejtpërdrejtë kundër jush, dhe se mjetet e mbrojtjes që përdorni, madje ndoshta pa e kuptuar (mbrojtjet e ndryshme të integruara në sistemet operative), janë mjaft të mjaftueshme për të minimizuar degradimin e shërbimit të ofruar për ju dhe klientët tuaj.

Ekzistojnë burime në internet, të cilat, mbi bazën e logeve nga pajisjet, në kohë reale krijojnë harta të bukura të sulmeve.

Këtu mund të gjeni linke për to.

Më e preferuara ime hartë nga CheckPoint.

Mbrojtja nga DDOS/DOS zakonisht është në nivele të shumta. Për të kuptuar pse, duhet të kuptoni cilat lloje sulmesh DOS/DDOS ekzistojnë (shih, për shembull, këtu ose këtu)

Pra, ne kemi tre lloje sulmesh:

sulme volumetrike
sulme protokollesh
sulme aplikacionesh

Nëse nga dy llojet e fundit të sulmeve mund të mbroni veten me përdorimin e, për shembull, firewalleve, nga sulmet që kanë për objektiv "mbushjen" e lidhjeve tuaja, nuk mund të mbroni veten (sigurisht, nëse kapaciteti total i kanaleve tuaja të internetit nuk është matës nga terabitë, e më mirë, nga dhjetëra terabitë).

Prandaj, linja e parë e mbrojtjes është mbrojtja nga sulmet "volumetrike" dhe kjo mbrojtje duhet t'ju sigurojë ofruesi juaj ose ofruesit. Nëse këtë ende nuk e keni kuptuar, atëherë thjesht ju ka bërë fat.

Shembulli
Supozoni se keni disa lidhje, por vetëm një nga ofruesit mund t'ju sigurojë këtë mbrojtje. Por nëse gjithë trafiku do të kalonte përmes një ofruesi, si mund të lidhet, që e diskutuam pak më parë?
Në kohën e sulmit do t'ju duhet në këtë rast të sakrifikoni pjesërisht lidhshmërinë.

ky është vetëm për kohëzgjatjen e sulmit. Ju mund ta rikonfiguroni BGP në mënyrë manuale ose automatike gjatë një sulmi, në mënyrë që trafiku të kalojë vetëm përmes ofruesit që ju ofron "mbulesën". Pas përfundimit të sulmit, mund ta ktheni ruterin në gjendjen e mëparshme.

nuk është e nevojshme të transferoni të gjithë trafikun. Nëse përshembull, shihni se përmes disa uplink-ë ose peering nuk ka sulm (ose trafiku është i parëndësishëm), mund të vazhdoni të njoftoni prefiksat me atributet konkurruese drejt këtyre fqinjëve BGP.

Mbrojtjen nga "protocol attacks" dhe "application attacks" gjithashtu mund ta delegoni te partnerët tuaj.
Ja këtu ju mund të lexoni një studim të mirë (përkthim). Në të vërtetë, artikulli është dyvjeçar, por do t'ju japë një pasqyrë të qasjeve se si mund të mbroheni nga sulmet DDOS.

Në parim, mund të kufizoheni vetëm në këtë, duke i besuar plotësisht mbrojtjen tuaj në outsourcing. Ka përfitime në këtë zgjidhje, por ka edhe një mangësi të dukshme. Bëhet fjalë (përsëri, në varësi të asaj që bën kompania juaj) për mbijetesën e biznesit. Dhe të besosh në këto gjëra organizatave të huaja...

Prandaj, le të shqyrtojmë se si të organizojmë linjat e dyta dhe të treta të mbrojtjes (si një plotësim të mbrojtjes nga ofruesi).

Kështu, linja e dytë e mbrojtjes është filtrimi dhe kufizuesit e trafikut (policers) në hyrje të rrjetit tuaj.

Shembulli 1
Supozoni se ju "i keni mbyllur vetes" nga DDOS me ndihmën e një nga ofruesit. Supozoni se ky ofrues përdor Arbor për filtrimin e trafikut dhe filtrat në kufirin e rrjetit të tij.
Banda që Arbor mund të "trajtojë" është e kufizuar, dhe ofruesi natyrisht nuk mund të lejojë vazhdimisht kalimin e trafikut të të gjithë partnerëve të tij që kanë kërkuar këtë shërbim përmes pajisjeve filtruar. Prandaj, në kushte normale, trafiku nuk filtrohet.
Supozoni se po një sulm SYN flood. Edhe nëse keni porositur një shërbim, ku në rast sulmi trafiku automatikisht kalon në filtrimin, kjo nuk ndodh menjëherë. Gjatë një minute ose më shumë, ju mbeteni nën sulm. Dhe kjo mund të çojë në dështimin e pajisjeve tuaja ose të degradimin e shërbimit. Në këtë rast, kufizimi i trafikut në rrugëtimin kufitar, megjithatë, do të çojë në faktin se disa seanca TCP gjatë kësaj kohe nuk do të krijohen, por do ta shpëtojë infrastrukturën tuaj nga probleme më të mëdha.

Shembulli 2
Një numër anormalisht i madh i paketimeve SYN nuk mund të jetë vetëm rezultat i një sulmi SYN flood. Le të supozojmë se po ofroni një shërbim, ku mund të keni njëkohësisht rreth 100,000 lidhje TCP (në një qendër të dhënash).
Supozoni se si rezultat i një problemi të shkurtër me një nga ofruesit tuaj kryesorë, ju "u keni ndarë" gjysmën e seancave. Nëse aplikacioni juaj është i strukturuar në atë mënyrë që ai, "pa menduar shumë", menjëherë (ose pas një intervali të njëjtë për të gjitha seancat) përpiqet të ristabilizojë lidhjen, atëherë ju do të merrni në rreth një herë të paktën 50,000 paketime SYN.
Nëse, mbi këto seanca, duhet të funksionojë, për shembull, një shkëmbim ssl/tls, që supozon ndërrimin e certifikatave, atëherë nga këndvështrimi i shterimit të burimeve për balancuesin tuaj të ngarkesës, kjo do të jetë një "DDOS" shumë më e fortë se një thjesht sulm SYN flood. Duket se balancuesit duhet të përballojnë këto ngjarje, por... fatkeqësisht, ne kemi hasur në mënyrë të plotë një problem të tillë.
Dhe, sigurisht, policeri në rrugëtimin kufitar do të shpëtojë pajisjet tuaja në këtë rast.

Niveli i tretë i mbrojtjes nga DDOS/DOS – është konfigurimi i firewall-it tuaj.

Këtu mund të ndaloni si sulmet e dyta, ashtu edhe të treta. Në përgjithësi, gjithçka që arrin në firewall mund të filtrohet këtu.

Këshillë
Provoni t'i jepni firewall-it sa më pak punë të jetë e mundur, duke filtruar sa më shumë në dy linjat e para të mbrojtjes. Dhe kjo është arsyeja.
A ka ndodhur ndonjëherë që, duke gjeneruar trafik për të testuar, për shembull, sa e qëndrueshme është sistemi juaj operativ ndaj sulmeve DDOS, keni "vrarë" firewall-in tuaj duke e ngarkuar atë me 100 për qind, me trafik të zakonshëm? Nëse jo, ndoshta sepse nuk e keni provuar?
Në përgjithësi, firewall-i, siç e thashë më parë, është një gjë komplekse dhe funksionon mirë me dobësitë e njohura dhe zgjidhjet e testuara, por nëse dërgoni diçka të pazakontë, thjesht ndonjë gjë të rastit ose paketa me kokat e gabuara, me një mundësi të konsiderueshme (sipas përvojës time) mund të ngatërroheni madje edhe me pajisje shumë të avancuara. Prandaj, në fazën 2, me anë të ACL-ve të zakonshme (në nivelin L3/L4), lëshoni në rrjetin tuaj vetëm atë trafik që duhet të hyjë atje.