Ky kjo artikull është e katërta në serinë e artikujve "Si ta marrim nën kontroll infrastrukturën rrjetore". Përmbajtja e të gjithë artikujve të serisë dhe lidhjet mund të gjenden këtu.

Në pjesës së parë në këtë kapitull, ne shqyrtuam disa aspekte të sigurisë rrjetore të segmentit "Data Center". Kjo pjesë do të përqendrohet në segmentin "Internet Access".

Qasja në Internet

Tema e sigurisë padyshim është një nga temat më të komplikuara të botës së rrjeteve 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 që në mendimin tim janë të rëndësishme, përgjigjet e të cilave shpresoj të ndihmojnë në përmirësimin e nivelit të mbrojtjes së rrjetit tuaj.

Kur auditoj këtë segment, vini re aspektet e mëposhtme:

dizajn
konfigurimet BGP
mbrojtja DOS/DDOS
filtrimi i trafikut në firewall

Dizajni

Si një shembull të dizajnit të këtij segmenti për rrjetin e një ndërmarrjeje, do t'ju rekomandoja një udhëzues nga Cisco brenda modelit SAFE.

Sigurisht, ndoshta zgjidhjet e tjera të ofruesve do t'ju duken më tërheqëse (shihni kadarin e Gartner-it për 2018), por, pa ju kërkuar të ndiqni detajet e këtij dizajni, mendoj se është e dobishme të kuptoni parimet dhe idetë që qëndrojnë pas tij.

Vërejtje
Në SAFE, segmenti "Remote Access" është një pjesë e "Internet Access". 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 është

routerat kufitarë (border routers)
firewall-et

Kujtesë 1
Në këtë seri artikujsh, kur flas për firewall-et, kam parasysh NGFW.

Kujtesë 2
Unë po e shmang shqyrtimin e ndryshimeve të ndryshme L2/L1 ose zgjidhjet e mbulueshme L2 mbi L3 të nevojshme për të siguruar lidhshmërinë L1/L2 dhe do të përqendrohem vetëm në çështjet e nivelit L3 dhe më lart. Pjesërisht çështjet L1/L2 janë trajtuar në kapitullin "Pastrimi dhe dokumentimi«.

Nëse nuk keni gjetur një firewall në këtë segment, atëherë mos u nxito në përfundime.

Të shohim, siç bëmë në pjesën e mëparshme, të fillojmë me pyetjen, a është e nevojshme përdorimi i një firewall-i në këtë segment në rastin tuaj?

Mund të them se, duket, ky ë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ë aq thelbësorë.

Shembulli 1. Vonesa
Në atë që ka të bëjë me internetin, s'ka ndonjë sens për të folur për vonesa edhe rreth 1 milisekondë. 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ë i rëndësishëm. Prandaj, ndoshta një pjesë e trafikut (p.sh., trafiku i balancuesve të ngarkesës) do të duhet ta kaloni nëpër anashkalimin e firewall-it.

Shembulli 3. Besueshmëria
Ky faktor ende duhet marrë në konsideratë, por megjithatë, duke marrë parasysh pasigurinë e vet internetit, rëndësia e tij për këtë segment nuk është aq e madhe sa për qendrën e të dhënave.
Kështu, supozoni që shërbimi juaj ekziston përmes http/https (me sesione të shkurtra). Në këtë rast, mund të përdorni dy kutitë të pavarura (pa HA) dhe në rast problemi me njërën prej tyre përcillni gjithë trafikun në të dytën përmes rrugës.
Ose mund të përdorni firewall-et në modin transparent dhe, kur dalin jashtë funksionit për një periudhë për të zgjidhur problemin, të lejoni trafikun të kalojë përmes anashkalimit firewall-eve.

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

E rëndësishme!
Shfaqet tundimi për të bashkuar këtë firewall me atë të qendrës së të dhënave (përdor një firewall për këto segmente). Një zgjidhje, në parim, e mundshme, por është me rëndësi të kuptohet se, pasi firewall-i "Internet Access" në fakt gjëndet në vijën e parë të mbrojtjes suaj dhe "merr" mbi vete, të paktën, një pjesë të trafikut të dëmshëm, sigurisht, duhet të merret parasysh rreziku në rritje se ky firewall mund të dalë jashtë shërbimit. DMë thënë, duke përdorur të njëjtat pajisje në këto dy segmente, do të ulnim dukshëm disponueshmërinë e segmentit tuaj të qendrës së të dhënave.

Si zakonisht, duhet të kuptoni se në varësi të shërbimit që kompania ofron, dizajni i këtij segmenti mund të ndryshojë ndjeshëm. Mundohuni të zgjidhni qasje të ndryshme në varësi të kërkesave.

Shembuj
Nëse jeni një ofrues përmbajtjeje, me një rrjet CDN (shihni, për shembull, serinë e artikujve), atëherë ndoshta nuk do të dëshironit të krijoni infrastruktura me dhjetëra, madje qindra pikë prese përmes përdorimit të pajisjeve të veçanta për ruterimin dhe filtrimin e trafikut. Kjo do të ishte e shtrenjtë dhe ndoshta e tepruar.
Për BGP, nuk keni nevojë për ruterë të dedikuar, mund të përdorni mjete open-source, për shembull, Quagga. Prandaj, ndoshta, gjithçka që ju nevojitet është një server ose disa serverë, një switches dhe BGP.
Në këtë rast, serveri juaj ose disa serverë mund të luajnë rolin e serverit CDN, por gjithashtu edhe të ruterit. Sigurisht, ka ende shumë detaje (p.sh., si të sigurohet balancimi), por kjo është e realizueshme, dhe ky qasje e kemi zbatuar me sukses për një nga partnerët tanë.
Mund të keni disa qendra të dhënash me mbrojtje të plotë (firewalls, shërbime mbrojtjeje nga DDOS, të ofruara nga ofruesit tuaj të internetit) dhe dhjetëra ose qindra pika "të thjeshta" të pranishme vetëm me switches L2 dhe serverë.
E si është mbrojtja në këtë rast?
Le të shqyrtojmë, për shembull, sulmin e njohur së fundmi DNS Amplification DDOS.. Rreziku i tij është se gjenerohet një sasi e madhe trafiku, e cila thjesht "mbush" 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 të pranishme. Nëse gjerësi e përgjithshme e bandës është terabita, atëherë kjo vetë (pavarësisht, në fakt, së fundmi ka pasur disa sulme me trafik të dëmshëm të rrethit të terabit) ju mbron nga "mbingarkesa" e uplink-ëve.

nëse ndonjë uplink është "bllokuar", thjesht e largoni këtë site nga shërbimi (ndaloni njoftimin e prefix-it).

Po ashtu, mund të rritni ndarjen e trafikut që del nga qendrat tuaja "të plota" (dhe për rrjedhojë, të mbrojtura), kështu që largoni një sasi të konsiderueshme të trafikut të dëmshëm nga pikat e pranishme të pambrojtura.
Dhe një vërejtje të vogël për këtë shembull. Nëse një sasi e mjaftueshme e trafikut dërgohet përmes IX-eve, kjo gjithashtu zvogëlon ndjeshmërinë tuaj ndaj sulmeve të tilla.

Konfigurimi BGP

Këtu ka dy tema.

Lidhshmëri
Konfigurimi BGP

Kemi folur pak për lidhshmërinë në pjesa 1. Qëllimi është që trafiku për klientët tuaj të kalojë në rrugën 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ë tjerat - më pak. Varet nga shërbimi që ofroni.

Shembulli 1
Nëse jeni një bursë dhe për klientët tuaj janë të rëndësishme intervalet e kohës më pak se milisekondat, atëherë, është e qartë, nuk ka asnjë bisedë për internetin.

Shembulli 2
Nëse jeni një kompani lojrash dhe për ju janë të rëndësishme dhjetëra milisekonda, atëherë, sigurisht, lidhshmëria është shumë e rëndësishme për ju.

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

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

Burime të dobishme:

ripe.net
bgp.he.net

Shembuj
Do të jap vetëm një shembull të vogël.
Supozoni se qendra juaj e të dhënave është në Moskë, dhe keni një uplink të vetëm - Rostelecom (AS12389). Në këtë rast (single homed) BGP nuk ju nevojitet, dhe si adresat publike, ka shumë të ngjarë të përdorni grupe adresash nga Rostelecom.
Supozoni se ofroni një shërbim të caktuar, dhe keni një numër të mjaftueshëm klientësh nga Ukraina, dhe ata ankohen për vonesa të mëdha. Në hetimin keni zbuluar se adresat IP të disa prej tyre ndodhen 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 70 - 80 milisekonda. Këtë mund ta shihni gjithashtu në dritaren e shikimit të Rostelecom..
Me mjetin whois (në faqen ripe.net ose mjetin lokal) lehtësisht mund të përcaktoni se blloku 37.52.0.0/21 i përket AS6849 (Ukrtelecom).
Më pas, duke hyrë në bgp.he.net shihni se AS6849 nuk ka marrëdhënie me AS12389 (ata nuk janë as klientë, as uplink për njëri-tjetrin, as nuk kanë peering). Por nëse shikoni në listën e peering-ëve për AS6849, atëherë do të shihni, për shembull, AS29226 (Mastertel) dhe AS31133 (Megafon).
Duke gjetur dritaren e shikimit të këtyre ofruesve, mund të krahasoni rrugën dhe RTT. Për shembull, për Mastertel RTT do të jetë rreth 30 milisekonda.
Kështu që, nëse diferenca mes 80 dhe 30 milisekondave është e rëndësishme për shërbimin tuaj, atëherë ndoshta duhet të mendoni për lidhshmërinë, të merrni një numër AS në RIPE, grupin tuaj të adresave dhe të lidhni uplink të tjerë dhe/ose të krijoni pika të pranishme në IX.

Duke përdorur BGP, ju jo vetëm që përmirësoni lidhshmërinë, por gjithashtu rezervoni lidhjen tuaj me internetin.

Ky dokument përmban rekomandime për konfigurimin e BGP. Edhe pse këto rekomandime janë formuluar mbi bazën e "praktikave më të mira" të ofruesve, ato janë padyshim të dobishme dhe në fakt duhet të jenë një pjesë e hardening-ut që kemi diskutuar në pjesës së parë.

mbrojtja DOS/DDOS

Tani sulmet DOS/DDOS janë bërë një realitet i përditshëm për shumë kompani. Në të vërtetë, në një formë apo në një tjetër, ju sulmoheni mjaft shpesh. Ajo që nuk e vëreni aktualisht tregon se ende nuk është organizuar një sulm i drejtuar ndaj jush, dhe se ato mjete mbrojtëse që ju përdorni, madje duke mos e dyshuar këtë (mbrojtje të ndryshme të integruara në sistemet operative), janë të mjaftueshme për të minimizuar degradimin e shërbimit që ofroni për ju dhe klientët tuaj.

Ekzistojnë burime në internet që, mbi bazën e logëve nga pajisjet, vizatojnë harta të bukura të sulmeve në kohë reale.

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

Më e preferuara ime harta nga CheckPoint.

Mbrojtja nga DDOS/DOS zakonisht është e përbërë nga disa nivele. Për të kuptuar pse, duhet të kuptoni se çfarë lloj sulmesh DOS/DDOS ekzistojnë (shihni për shembuj, këtu ose këtu)

Pra, kemi tre lloje sulmesh:

sulme volumetrike
sulme protokollesh
sulme aplikimesh

Nëse për dy llojet e fundit të sulmeve keni mundësi të mbroheni vetë duke përdorur, për shembull, firewall-e, nga sulmet e orientuara në "mbushjen" e uplink-eve tuaj nuk do të mbroheni dot vetë (sigurisht, nëse kapaciteti juaj i përgjithshëm i kanaleve të internetit nuk arrin terabitë, dhe preferohet, dhjetëra terabitë).

Prandaj, linja e parë e mbrojtjes është mbrojtja ndaj sulmeve "volumetrike" dhe këtë mbrojtje duhet t'jua ofrojë ofruesi juaj ose ofruesit. Nëse nuk e keni kuptuar këtë, atëherë thjesht keni qenë me fat deri tani.

Shembuj
Supozoni se keni disa uplink-e, por vetëm një nga ofruesit mund t'ju ofrojë këtë mbrojtje. Por nëse e gjithë trafiku kalon përmes një ofruesi, atëherë si do të ruhet lidhshmëria që kemi diskutuar shkurtimisht më parë?
Në kohën e sulmit, do t'ju duhet të sakrifikoni disi lidhshmërinë. Por

kjo është vetëm përsa kohë që po ndodh sulmi. Në rast sulmi, mund të rregulloni manualisht ose automatikisht BGP-në, në mënyrë që trafiku të kalojë vetëm përmes ofruesit që ju ofron "zhurmat". Pas përfundimit të sulmit, mund të ktheheni në gjendjen e mëparshme të rrugëzimit.

nuk është e nevojshme të transferoni të gjithë trafikun. Nëse, për shembull, vini re se përmes disa uplink-eve ose peering-ut nuk po ndodhin sulme (ose trafiku është i papërfillshëm), mund të vazhdoni të njoftoni prefikse me atribute konkurruese ndaj këtyre fqinjve BGP.

Mbrojtjen nga "sulmet e protokollit" dhe "sulmet aplikimesh" mund ta delegoni gjithashtu partnerëve tuaj.
Këtu është këtu mund të lexoni një studim të mirë (përkthim). Megjithatë, artikulli është dy vjet i vjetër, por do t'ju japë një ide mbi qasjet, si mund të mbroheni nga sulmet DDOS.

Në parim, mund ta shpërndani mbrojtjen tuaj gjithashtu në atribuimin e mbrojtjes së jashtme. Ky zgjidhje ka përfitime, por ka dhe një disavantazh të qartë. Fakti është se mund të përfshijë (sërish, në varësi të asaj që bën kompania juaj) mbijetesën e biznesit. Dhe besimi ndaj këtyre gjërave tek organizata të jashtme...

Prandaj, le të shqyrtojmë se si të organizojmë linjën e dytë dhe të tretë të mbrojtjes (si një shtesë ndaj mbrojtjes nga ofruesi).

Prandaj, linja e dytë e mbrojtjes është filtrimi dhe kufizuesit e trafikut (policers) në hyrje në rrjetin tuaj.

Shembulli 1
Supozoni se jeni "mbuluar me zhura" nga DDOS nga një nga ofruesit. Supozoni se ky ofrues përdor Arbor për filtrimin e trafikut dhe filtrat në kufirin e rrjetit të tij.
Gjerësia e bandës që Arbor mund të "procesojë" është e kufizuar, dhe sigurisht ofruesi nuk mund ta kalojë vazhdimisht trafikun e të gjithë partnerëve të tij që kanë porositur këtë shërbim përmes pajisjeve filtrimi. Prandaj, në kushte normale, trafiku nuk filtrohet.
Supozoni se po ndodh një sulm SYN flood. Edhe nëse keni porositur një shërbim, në të cilin 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 degradimin e shërbimit. Në këtë rast, kufizimi i trafikut në rrugëzimin kufitar, edhe pse do të bëjë që disa seancat TCP gjatë këtij koha të mos krijohen, do të shpëtojë infrastrukturën tuaj nga probleme më të mëdha.

Shembulli 2
Një numër anormal i madh i paketave SYN nuk mund të jetë vetëm rezultat i një sulmi SYN flood. Le të supozomë se ofroni një shërbim, ku keni njëkohësisht deri në 100 mijë lidhje TCP (në një qendër të dhënash).
Supozoni se që, si rezultat i një problemi të përkohshëm me një nga ofruesit tuaj kryesorë, ju është “ndaluar” gjysma e seancave. Nëse aplikacioni juaj është i ndërtuar në një mënyrë që, "pa menduar shumë", menjëherë (ose në një interval kohor të njëjtë për të gjitha seancat) përpiqet të ristabilizojë lidhjen, atëherë do të merrni përgjithësisht të paktën 50 mijë paketa SYN në të njëjtën kohë.
Nëse mbi këto seanca, për shembull, duhet të funksionojë një ssl/tls handshake, që parashikon shkëmbimin e certifikatave, atëherë nga pikëpamja e shfrytëzimit të burimeve për balancuesin tuaj të ngarkesës, kjo do të ishte një "DDOS" shumë më e fortë se një fluks i zakonshëm SYN. Duke u dukur, balancuesit duhet të trajtojnë këto ngjarje, por... për fat të keq, ne jemi përballur drejtpërdrejt me një problem të tillë.
Dhe, sigurisht, policeri në ruterin 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 nivelit të dytë ashtu edhe ato të tretë. Në përgjithësi, çdo gjë që arrin tek firewall-i mund të filtroni këtu.

Këshillë
Përpiquni t'i jepni firewall-it sa më pak punë, duke filtruar sa më shumë në dy linjat e para të mbrojtjes. Dhe ja pse.
A keni pasur ndonjëherë ndodhi të tillë, ku rastësisht, duke gjeneruar trafik për të provuar, për shembull, sa e qëndrueshme është sistemi operativ i serverëve tuaj ndaj sulmeve DDOS, ju "ndalonit" firewall-in tuaj, duke e ngarkuar atë në 100 për qind, me një trafik të zakonshëm? Nëse jo, ndoshta thjesht sepse nuk e keni provuar?
Në përgjithësi, firewall-i, siç kam thënë më parë, është një thesar kompleks, dhe ai funksionon mirë me vulnerabilitete të njohura dhe zgjidhje të provuara, por nëse dërgoni diçka të pazakontë, thjesht ndonjë mbeturinë ose paketa me tituj të papërshtatshëm, atëherë me ndonjë probabilitet jo të vogël (duke u mbështetur në përvojën time) mund të bllokoni dhe pajisjet më të avancuara. Prandaj, në fazën 2, me ndihmën e ACL-ve të zakonshme (në nivelin L3/L4), lejoni në rrjetin tuaj vetëm atë trafik që duhet të hyjë aty.