Si të merrni kontrollin e infrastrukturës së rrjetit tuaj. Kapitulli i tretë. Siguria e rrjetit. Pjesa e dyte

Ky artikull është i katërti në serinë "Si të merrni kontrollin e infrastrukturës së rrjetit tuaj". Përmbajtja e të gjithë artikujve në seri dhe lidhjet mund të gjenden këtu.

В Pjesa e parë Në këtë kapitull, ne shikuam disa aspekte të sigurisë së rrjetit në segmentin e Qendrës së të Dhënave. Kjo pjesë do t'i kushtohet segmentit "Qasja në Internet".

Si të merrni kontrollin e infrastrukturës së rrjetit tuaj. Kapitulli i tretë. Siguria e rrjetit. Pjesa e dyte

Hyrje në internet

Tema e sigurisë është padyshim një nga temat më komplekse në botën e rrjeteve të të dhënave. Ashtu si në rastet e mëparshme, pa pretenduar thellësi dhe plotësi, do t'i konsideroj këtu mjaft të thjeshta, por, për mendimin tim, pyetje të rëndësishme, përgjigjet për të cilat, shpresoj, do të ndihmojnë në ngritjen e nivelit të sigurisë së rrjetit tuaj.

Kur auditoni këtë segment, kushtojini vëmendje aspekteve të mëposhtme:

  • dizajn
  • Cilësimet e BGP
  • Mbrojtja DOS/DDOS
  • filtrimi i trafikut në murin e zjarrit

Dizajn

Si shembull i projektimit të këtij segmenti për një rrjet ndërmarrjesh, unë do të rekomandoja udhëheqja nga Cisco brenda Modele SAFE.

Sigurisht, ndoshta zgjidhja e shitësve të tjerë do t'ju duket më tërheqëse (shih. Gartner Quadrant 2018), por pa ju inkurajuar që ta ndiqni këtë dizajn në detaje, më duket ende e dobishme të kuptoj parimet dhe idetë pas tij.

vërejtje

Në SAFE, segmenti "Remote Access" është pjesë e segmentit "Internet Access". Por në këtë seri artikujsh do ta shqyrtojmë veçmas.

Seti standard i pajisjeve në këtë segment për një rrjet ndërmarrjesh është

  • ruterat kufitare
  • muret e zjarrit

Vërejtje 1

Në këtë seri artikujsh, kur flas për muret e zjarrit, dua të them NGFW.

Vërejtje 2

Lëshoj shqyrtimin e llojeve të ndryshme të zgjidhjeve L2/L1 ose mbivendosjes L2 mbi L3 të nevojshme për të siguruar lidhjen L1/L2 dhe kufizohem vetëm në çështjet në nivelin L3 dhe më lart. Pjesërisht, çështjet L1/L2 u diskutuan në kapitullin "Pastrimi dhe Dokumentacioni".

Nëse nuk keni gjetur një mur zjarri në këtë segment, atëherë nuk duhet të nxitoni në përfundime.

Le të bëjmë të njëjtën gjë si në pjesa e mëparshmeLe të fillojmë me pyetjen: a është e nevojshme të përdorni një mur zjarri në këtë segment në rastin tuaj?

Mund të them se ky duket se është vendi më i justifikuar për të përdorur muret e zjarrit dhe për të aplikuar algoritme komplekse të filtrimit të trafikut. NË Pjesa 1 Ne përmendëm 4 faktorë që mund të ndërhyjnë në përdorimin e mureve të zjarrit në segmentin e qendrës së të dhënave. Por këtu ato nuk janë më aq domethënëse.

Shembull 1. vonesë

Për sa i përket internetit, nuk ka kuptim të flasim për vonesa qoftë edhe rreth 1 milisekondë. Prandaj, vonesa në këtë segment nuk mund të jetë një faktor që kufizon përdorimin e murit të zjarrit.

Shembull 2. prodhimtari

Në disa raste ky faktor mund të jetë ende i rëndësishëm. Prandaj, mund t'ju duhet të lejoni që një pjesë e trafikut (për shembull, trafiku nga balancuesit e ngarkesës) të anashkalojë murin e zjarrit.

Shembull 3. Seriozitet

Ky faktor ende duhet të merret parasysh, por megjithatë, duke pasur parasysh mosbesueshmërinë e vetë Internetit, rëndësia e tij për këtë segment nuk është aq e rëndësishme sa për qendrën e të dhënave.

Pra, le të supozojmë se shërbimi juaj jeton në krye të http/https (me seanca të shkurtra). Në këtë rast, ju mund të përdorni dy kuti të pavarura (pa HA) dhe nëse ka një problem rrugëtimi me njërën prej tyre, transferoni të gjithë trafikun në të dytin.

Ose mund të përdorni muret e zjarrit në modalitetin transparent dhe, nëse dështojnë, lejoni trafikun të anashkalojë murin e zjarrit ndërsa zgjidh problemin.

Prandaj, ka shumë të ngjarë vetëm çmim mund të jetë faktori që do t'ju detyrojë të braktisni përdorimin e mureve të zjarrit në këtë segment.

Rëndësishme!

Ekziston një tundim për të kombinuar këtë mur zjarri me murin e zjarrit të qendrës së të dhënave (përdorni një mur zjarri për këto segmente). Zgjidhja është, në parim, e mundur, por ju duhet ta kuptoni këtë sepse Një mur zjarri i aksesit në Internet është në të vërtetë në ballë të mbrojtjes suaj dhe "merr" të paktën një pjesë të trafikut keqdashës, atëherë, sigurisht, duhet të merrni parasysh rrezikun e rritur që ky mur zjarri të çaktivizohet. Kjo do të thotë, duke përdorur të njëjtat pajisje në këto dy segmente, ju do të reduktoni ndjeshëm disponueshmërinë e segmentit tuaj të qendrës së të dhënave.

Si gjithmonë, duhet të kuptoni se në varësi të shërbimit që ofron kompania, dizajni i këtij segmenti mund të ndryshojë shumë. Si gjithmonë, ju mund të zgjidhni qasje të ndryshme në varësi të kërkesave tuaja.

Shembull

Nëse jeni një ofrues i përmbajtjes, me një rrjet CDN (shih, për shembull, seri artikujsh), atëherë mund të mos dëshironi të krijoni infrastrukturë në dhjetëra apo edhe qindra pika pranie duke përdorur pajisje të veçanta për drejtimin dhe filtrimin e trafikut. Do të jetë e shtrenjtë dhe mund të jetë thjesht e panevojshme.

Për BGP nuk duhet domosdoshmërisht të keni ruterë të dedikuar, mund të përdorni mjete me burim të hapur si p.sh. Kuagga. Pra, ndoshta gjithçka që ju nevojitet është një server ose disa serverë, një ndërprerës dhe BGP.

Në këtë rast, serveri juaj ose disa serverë mund të luajnë rolin jo vetëm të një serveri CDN, por edhe të një ruteri. Sigurisht, ka ende shumë detaje (si për shembull si të sigurohet balancimi), por është e realizueshme dhe është një qasje që e kemi përdorur me sukses për një nga partnerët tanë.

Ju mund të keni disa qendra të dhënash me mbrojtje të plotë (firewall, shërbime mbrojtëse DDOS të ofruara nga ofruesit tuaj të internetit) dhe dhjetëra ose qindra pika të "thjeshtuara" të pranisë vetëm me ndërprerës dhe serverë L2.

Por ç'të themi për mbrojtjen në këtë rast?

Le të shohim, për shembull, të njohurit kohët e fundit Sulmi DDOS i Amplifikimit DNS. Rreziku i tij qëndron në faktin se gjenerohet një sasi e madhe trafiku, e cila thjesht "bllokon" 100% të të gjitha lidhjeve tuaja.

Çfarë kemi ne në rastin e dizajnit tonë.

  • nëse përdorni AnyCast, atëherë trafiku shpërndahet midis pikave tuaja të pranisë. Nëse gjerësia juaj totale e brezit është terabit, atëherë kjo në vetvete në të vërtetë (megjithatë, kohët e fundit ka pasur disa sulme me trafik keqdashës në rendin e terabitëve) ju mbron nga lidhjet "mbushëse"
  • Nëse, megjithatë, disa lidhje ngjitëse bllokohen, atëherë thjesht e hiqni këtë sajt nga shërbimi (ndaloni reklamimin e prefiksit)
  • ju gjithashtu mund të rrisni pjesën e trafikut të dërguar nga qendrat tuaja të të dhënave "të plota" (dhe, në përputhje me rrethanat, të mbrojtura), duke hequr kështu një pjesë të konsiderueshme të trafikut me qëllim të keq nga pikat e pambrojtura të pranisë

Dhe një shënim tjetër i vogël për këtë shembull. Nëse dërgoni trafik të mjaftueshëm përmes IX-ve, atëherë kjo gjithashtu zvogëlon cenueshmërinë tuaj ndaj sulmeve të tilla

Vendosja e BGP

Këtu ka dy tema.

  • Lidhshmëria
  • Vendosja e BGP

Ne kemi folur tashmë pak për lidhjen në Pjesa 1. Çështja është të siguroheni që trafiku për klientët tuaj të ndjekë rrugën optimale. Megjithëse optimaliteti nuk ka të bëjë gjithmonë vetëm me vonesën, vonesa e ulët është zakonisht treguesi kryesor i optimalitetit. Për disa kompani kjo është më e rëndësishme, për të tjera është më pak. E gjitha varet nga shërbimi që ofroni.

1 Shembull

Nëse jeni shkëmbyes dhe intervalet kohore më pak se milisekonda janë të rëndësishme për klientët tuaj, atëherë, sigurisht, nuk mund të flitet fare për asnjë lloj interneti.

2 Shembull

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

3 Shembull

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

Studimi i lidhjes është një temë interesante në vetvete, e denjë për artikullin ose serinë e tij të artikujve dhe kërkon një kuptim të mirë të mënyrës se si "funksionon" interneti.

Burime të dobishme:

pjekur.net
bgp.he.net

Shembull

Unë do të jap vetëm një shembull të vogël.

Le të supozojmë se qendra juaj e të dhënave ndodhet në Moskë, dhe ju keni një lidhje të vetme - Rostelecom (AS12389). Në këtë rast (me një shtëpi të vetme) nuk keni nevojë për BGP, dhe ka shumë të ngjarë të përdorni grupin e adresave nga Rostelecom si adresa publike.

Le të supozojmë se ju 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ë gjata. Gjatë kërkimit tuaj, ju zbuluat se adresat IP të disa prej tyre janë në rrjetin 37.52.0.0/21.

Duke drejtuar një traceroute, ju pa që trafiku po kalonte përmes AS1299 (Telia), dhe duke ekzekutuar një ping, ju morët një RTT mesatare prej 70 - 80 milisekonda. Ju gjithashtu mund ta shihni këtë në qelqi Rostelecom.

Duke përdorur mjetin whois (në ripe.net ose një shërbim lokal), mund të përcaktoni lehtësisht se blloku 37.52.0.0/21 i përket AS6849 (Ukrtelecom).

Më pas, duke shkuar në bgp.he.net ju shikoni që AS6849 nuk ka asnjë lidhje me AS12389 (ata nuk janë as klientë, as lidhje me njëri-tjetrin, as nuk kanë peering). Por nëse shikoni lista e bashkëmoshatarëve për AS6849, do të shihni, për shembull, AS29226 (Mastertel) dhe AS31133 (Megafon).

Pasi të gjeni xhamat e kërkimit të këtyre ofruesve, mund të krahasoni shtegun dhe RTT. Për shembull, për Mastertel RTT do të jetë rreth 30 milisekonda.

Pra, nëse ndryshimi midis 80 dhe 30 milisekondave është i rëndësishëm për shërbimin tuaj, atëherë ndoshta duhet të mendoni për lidhjen, të merrni numrin tuaj AS, grupin e adresave nga RIPE dhe të lidhni lidhje shtesë dhe/ose të krijoni pika prezence në IX.

Kur përdorni BGP, ju jo vetëm që keni mundësinë të përmirësoni lidhjen, por gjithashtu ruani në mënyrë të tepërt lidhjen tuaj në internet.

Ky dokument përmban rekomandime për konfigurimin e BGP. Pavarësisht nga fakti se këto rekomandime u zhvilluan bazuar në "praktikën më të mirë" të ofruesve, megjithatë (nëse cilësimet tuaja BGP nuk janë mjaft themelore) ato janë padyshim të dobishme dhe në fakt duhet të jenë pjesë e forcimit që diskutuam në Pjesa e parë.

Mbrojtja DOS/DDOS

Tani sulmet DOS/DDOS janë bërë një realitet i përditshëm për shumë kompani. Në fakt, ju sulmoheni mjaft shpesh në një formë ose në një tjetër. Fakti që nuk e keni vënë re ende këtë do të thotë vetëm se një sulm i synuar ende nuk është organizuar kundër jush dhe se masat mbrojtëse që përdorni, edhe ndoshta pa e ditur (mbrojtje të ndryshme të integruara të sistemeve operative), të mjaftueshme për të sigurohuni që degradimi i shërbimit të ofruar të minimizohet për ju dhe klientët tuaj.

Ka burime të internetit që, bazuar në regjistrat e pajisjeve, vizatojnë harta të bukura sulmesh në kohë reale.

Këtu ju mund të gjeni lidhje me to.

My favorite hartë nga CheckPoint.

Mbrojtja kundër DDOS/DOS zakonisht është e shtresuar. Për të kuptuar pse, ju duhet të kuptoni se çfarë lloje të sulmeve DOS/DDOS ekzistojnë (shih, për shembull, këtu ose këtu)

Kjo do të thotë, ne kemi tre lloje sulmesh:

  • sulmet volumetrike
  • sulmet e protokollit
  • sulmet e aplikacionit

Nëse mund të mbroheni nga dy llojet e fundit të sulmeve duke përdorur, për shembull, muret e zjarrit, atëherë nuk mund të mbroheni nga sulmet që synojnë "mbushjen" e lidhjeve tuaja (sigurisht, nëse kapaciteti juaj total i kanaleve të internetit nuk llogaritet në terabit, ose më mirë akoma, në dhjetëra terabit).

Prandaj, linja e parë e mbrojtjes është mbrojtja kundër sulmeve "volumetrike" dhe ofruesi ose ofruesit tuaj duhet t'ju ofrojnë këtë mbrojtje. Nëse nuk e keni kuptuar ende këtë, atëherë për momentin jeni thjesht me fat.

Shembull

Le të themi se keni disa lidhje, por vetëm një nga ofruesit mund t'ju ofrojë këtë mbrojtje. Por nëse i gjithë trafiku kalon përmes një ofruesi, atëherë ç'të themi për lidhjen që diskutuam shkurtimisht pak më herët?

Në këtë rast, do t'ju duhet të sakrifikoni pjesërisht lidhjen gjatë sulmit. Por

  • kjo është vetëm për kohëzgjatjen e sulmit. Në rast sulmi, ju mund ta rikonfiguroni manualisht ose automatikisht BGP në mënyrë që trafiku të kalojë vetëm përmes ofruesit që ju ofron "ombrellën". Pas përfundimit të sulmit, ju mund ta ktheni rrugën në gjendjen e mëparshme
  • Nuk është e nevojshme të transferoni të gjithë trafikun. Nëse, për shembull, shihni se nuk ka sulme përmes disa lidhjeve ose lidhjeve (ose trafiku nuk është i rëndësishëm), mund të vazhdoni të reklamoni parashtesa me atribute konkurruese ndaj këtyre fqinjëve BGP.

Ju gjithashtu mund të delegoni mbrojtjen nga "sulmet e protokollit" dhe "sulmet e aplikacionit" te partnerët tuaj.
Këtu këtu ju mund të lexoni një studim të mirë (përkthim). Vërtetë, artikulli është dy vjeç, por do t'ju japë një ide për qasjet se si mund të mbroheni nga sulmet DDOS.

Në parim, ju mund të kufizoni veten në këtë, duke kontraktuar plotësisht mbrojtjen tuaj. Ky vendim ka avantazhe, por ka edhe një disavantazh të dukshëm. Fakti është se ne mund të flasim (përsëri, në varësi të asaj që bën kompania juaj) për mbijetesën e biznesit. Dhe besojuni gjëra të tilla palëve të treta...

Prandaj, le të shohim se si të organizojmë linjën e dytë dhe të tretë të mbrojtjes (si një shtesë për mbrojtjen nga ofruesi).

Pra, linja e dytë e mbrojtjes është filtrimi dhe kufizuesit e trafikut (policët) në hyrje të rrjetit tuaj.

1 Shembull

Le të supozojmë se e keni mbuluar veten me një ombrellë kundër DDOS me ndihmën e një prej ofruesve. Le të supozojmë se ky ofrues përdor Arbor për të filtruar trafikun dhe filtrat në skajin e rrjetit të tij.

Gjerësia e brezit që Arbor mund të "përpunojë" është e kufizuar dhe ofruesi, natyrisht, nuk mund të kalojë vazhdimisht trafikun e të gjithë partnerëve të tij që e porosisin këtë shërbim përmes pajisjeve të filtrimit. Prandaj, në kushte normale, trafiku nuk filtrohet.

Le të supozojmë se ka një sulm të përmbytjes SYN. Edhe nëse keni porositur një shërbim që kalon automatikisht trafikun në filtrim në rast sulmi, kjo nuk ndodh menjëherë. Për një minutë 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ë drejtimin e skajit, megjithëse do të çojë në faktin se disa sesione TCP nuk do të krijohen gjatë kësaj kohe, do të shpëtojë infrastrukturën tuaj nga problemet në shkallë më të gjerë.

2 Shembull

Një numër anormalisht i madh paketash SYN mund të jetë jo vetëm rezultat i një sulmi të përmbytjes SYN. Le të supozojmë se ju ofroni një shërbim në të cilin mund të keni në të njëjtën kohë rreth 100 mijë lidhje TCP (në një qendër të dhënash).

Le të themi se si rezultat i një problemi afatshkurtër me një nga ofruesit tuaj kryesorë, gjysma e seancave tuaja janë ndërprerë. Nëse aplikacioni juaj është krijuar në atë mënyrë që, pa u menduar dy herë, ai menjëherë (ose pas një intervali kohor që është i njëjtë për të gjitha seancat) përpiqet të rivendosë lidhjen, atëherë do të merrni të paktën 50 mijë pako SYN afërsisht njëkohësisht.

Nëse, për shembull, duhet të ekzekutoni shtrëngimin e duarve ssl/tls në krye të këtyre seancave, që përfshin shkëmbimin e certifikatave, atëherë nga pikëpamja e shterimit të burimeve për balancuesin tuaj të ngarkesës, ky do të jetë një "DDOS" shumë më i fortë se një i thjeshtë SYN përmbytje. Duket se balancuesit duhet të merren me ngjarje të tilla, por... për fat të keq, ne jemi përballur me një problem të tillë.

Dhe, sigurisht, një polic në ruterin e skajit do të kursejë pajisjet tuaja edhe në këtë rast.

Niveli i tretë i mbrojtjes kundër DDOS/DOS janë cilësimet e murit tuaj të zjarrit.

Këtu mund të ndaloni të dy sulmet e tipit të dytë dhe të tretë. Në përgjithësi, gjithçka që arrin në murin e zjarrit mund të filtrohet këtu.

Совет

Përpiquni t'i jepni murit të zjarrit sa më pak të jetë e mundur, duke filtruar sa më shumë që të jetë e mundur në dy linjat e para të mbrojtjes. Dhe kjo është arsyeja pse.

A ju ka ndodhur ndonjëherë që rastësisht, ndërsa krijoni trafik për të kontrolluar, për shembull, se sa rezistent është sistemi operativ i serverëve tuaj ndaj sulmeve DDOS, të "vrisni" firewall-in tuaj, duke e ngarkuar atë në 100 për qind, me trafik me intensitet normal ? Nëse jo, ndoshta është thjesht sepse nuk e keni provuar?

Në përgjithësi, një mur zjarri, siç thashë, është një gjë komplekse dhe funksionon mirë me dobësi të njohura dhe zgjidhje të testuara, por nëse dërgoni diçka të pazakontë, vetëm disa mbeturina ose pako me tituj të pasaktë, atëherë jeni me disa, jo me një probabilitet kaq i vogël (bazuar në përvojën time), ju mund të trullosni edhe pajisjet e nivelit të lartë. Prandaj, në fazën 2, duke përdorur ACL-të e rregullta (në nivelin L3/L4), lejoni vetëm trafikun në rrjetin tuaj që duhet të hyjë atje.

Filtrimi i trafikut në murin e zjarrit

Le të vazhdojmë bisedën për murin e zjarrit. Ju duhet të kuptoni se sulmet DOS/DDOS janë vetëm një lloj sulmi kibernetik.

Përveç mbrojtjes DOS/DDOS, ne gjithashtu mund të kemi diçka si lista e mëposhtme e veçorive:

  • muri i zjarrit i aplikacionit
  • parandalimi i kërcënimeve (antivirus, anti-spyware dhe cenueshmëria)
  • Filtrimi i URL-ve
  • filtrimi i të dhënave (filtrimi i përmbajtjes)
  • bllokimi i skedarëve (bllokimi i llojeve të skedarëve)

Varet nga ju që të vendosni se çfarë ju nevojitet nga kjo listë.

Për të vazhduar

Burimi: www.habr.com

Shto një koment