See artikkel on neljas osa artiklisarjast „Kuidas kontrollida oma võrgu infrastruktuuri“. Kõiki artiklisarja teemasid ja linke saab leida siin.

Uues esimeses osas selles peatükis oleme käsitlenud mõningaid andmekeskuse võrgu turvalisuse aspekte. See osa keskendub „Interneti-juurdepääs“ segmendile.

Interneti juurdepääs

Turvalisuse teema on kindlasti üks kõige keerulisemaid teemasid andmeedastuse maailmas. Nagu ka eelnevates osades, ei pretendeeri ma sügavusele ja täielikkusele, vaid käsitlen siin piisavalt lihtsaid, kuid minu arvates olulisi küsimusi, millele vastused aitavad loodetavasti tõsta teie võrgu turvalisuse taset.

Selle segmendi auditil pöörake tähelepanu järgmistele aspektidele:

disain
BGP seadistused
DOS/DDOS kaitse
liikluse filtreerimine tulemüüri kaudu

Kujundus

Kuna näidiseks selle segmendi kujundamiseks ettevõtte võrgu jaoks soovitaksin juhend Cisco tooteid seadistuste osas, SAFE mudel tööraames..

Muidugi võib mõni muu tarnija lahendus tunduda teile atraktiivsem (vt. Gartnery kvadrant 2018. aastal,), kuid kutsub teid mitte järgima seda kujundust üksikasjalikult, pean siiski oluliseks mõista selle aluseks olevaid põhimõtteid ja ideid.

Note
SAFE-s on „Kaugrakenduse“ segment osa „Interneti-juurdepääsust“. Kuid selle artiklisarja raames käsitleme seda eraldi.

Selle segmendi standardne seadmete komplekt ettevõtte võrgus (enterprise network) sisaldab

piirimarsruutereid (border routers),
tulemüüre.

Märkus 1
Käesolevas artiklisarjas, kui ma räägin tulemüüri kohta, mõistan ma sellega NGFW-d..

Märkus 2
Ma ei käsitle erinevaid L2/L1 või Overlay L2 over L3 lahendusi, mis on vajalikud L1/L2 ühenduvuse tagamiseks, vaid keskendun ainult L3 taseme ja kõrgemale. Osaliselt on L1/L2 küsimusi käsitletud peatükis „Puhastamine ja dokumenteerimine.«.

Kui te ei leidnud sellelt segmendilt tulemüüri, siis ei tasu teha järeldusi.

Alustame, nagu ka eelmises osas, küsimusest, kas tulemüüri kasutamine on antud juhul vajalik?

Võin öelda, et see tundub olema kõige põhjendatum koht tulemüüri kasutamiseks ja keerukate liikluse filtreerimise algoritmide rakendamiseks. Eelnevas osas 1 mainisime 4 tegurit, mis võivad takistada tulemüüride kasutamist andmekeskuse segmendis. Kuid siinkohal ei ole need enam nii olulised.

Näide 1. Viivitus
Internetis pole mõtet rääkida viivitustest isegi 1 millisekundi ulatuses. Seetõttu ei saa selle segmendi viivitus olla tegur, mis piirab tulemüüride kasutamist.

Näide 2. Tõhusus
Mõnel juhul võib see tegur siiski olla oluline. Seetõttu peate võib-olla osa liiklusest (näiteks koormuse tasakaalustajate liiklus) suunama tulemüürist mööda.

Näide 3. Usaldusväärsus
Seda tegurit tuleb endiselt arvesse võtta, kuid arvestades interneti usaldamatust, ei ole selle tähendus selle segmendi jaoks nii oluline kui andmekeskuses.
Oletame, et teie teenus töötab http/https peal (lühikeste sessioonidega). Sel juhul saate kasutada kahte sõltumatut seadmekast (ilma HA-ta) ja kui ühe seadme puhul esineb probleeme, saate suunata kogu liikluse teisele seadmele.
Või võite kasutada tulemüüre läbipaistvas režiimis ja kui need riknevad, suunate liikluse tulemüüridest mööda, kuni probleem on lahendatud.

Seetõttu on see tõenäoliselt ainult hind võib olla see tegur, mis paneb teid loobuma tulemüüride kasutamisest selles segmendis.

Oluline!
On isu ühendada see tulemüür andmekeskuse tulemüüriga (kasutada ühte tulemüüri nende segmentide jaoks). Lahendus on põhimõtteliselt võimalik, kuid sellega tuleb arvestada, et kuna "Internet Access" tulemüür seisab tegelikult teie kaitse esirinnas ja "võtab endale" vähemalt osa kahjulikust liiklusest, tuleb arvesse võtta seda, et selle tulemüüri väljalangemise risk on suurenenud. See tähendab, et kui kasutate samu seadmeid nende kahe segmendi jaoks, siis vähendate oma andmekeskuse segmentide kättesaadavust oluliselt.

Nagu tavaliselt, tuleb mõista, et sõltuvalt teenusest, mida ettevõte pakub, võib selle segmendi disain oluliselt erineda. Nagu tavaliselt, saate valida erinevaid lähenemisviise sõltuvalt nõudmistest.

Näide
Kui olete sisu pakkuja, kellel on CDN-võrk (vt näiteks, artiklite seeriat), siis ei pruugi te soovida luua infrastruktuuri sadadesse, kui mitte kümnetesse, kohaloleku punktidesse, kasutades eraldi seadmeid liikluse suunamiseks ja filtreerimiseks. See on kallis ja võib olla lihtsalt liialdust.
BGP jaoks ei ole teil kindlasti vaja pühendatud ruutereid, võite kasutada open-source tööriistu, näiteks Quagga. Seetõttu võib-olla on kõik, mis teil vaja on, server või mitu serverit, lüliti ja BGP.
Sel juhul võivad teie server või mitu serverit mängida mitte ainult CDN serveri, vaid ka ruuteri rolli. Loomulikult on siin palju detaile (näiteks, kuidas tagada tasakaalustus), kuid see on teostatav ja sellist lähenemist oleme edukalt rakendanud ühe meie partneri jaoks.
Võite omada mitmeid andmekeskusi täis kaitsega (tulekahju seina, DDoS kaitse teenuseid, mida pakuvad teie interneti teenusepakkujad) ja kümneid või sadu „lihtsustatud” kohaloleku punkte ainult L2 lülititega ja serveritega.
Aga mis on kaitse selles olukorras?
Vaadake näiteks viimase ajal populaarsust kogunud DNS Amplification DDoS rünnakut. Selle oht seisneb selles, et genereeritakse suur hulk liiklust, mis lihtsalt „tühjendab“ 100% kõik teie uplinkid.
Mida me meie disainis näeme.

kui kasutate AnyCast'i, siis jagatakse liiklus teie kohaloleku punktide vahel. Kui teie koguarv on terabitti, siis see iseenesest (kuigi viimase ajal on olnud mitmeid rünnakuid pahatahtliku liiklusega, mis on suureuselt terabitti) kaitseb teid uplinkide „ülekoormamise“ eest.

kui siiski mõned uplinkid on „täis“, siis lihtsalt eemaldage see ala teenindusest (lõpetage prefiksi tutvustamine).

Te saate samuti suurendada liikluse osa, mille edastate oma “täisfunktsionaalsetest” (ja seega kaitstud) andmekeskustest, seeläbi eemaldades märkimisväärse osa pahatahtlikust liiklusest kaitsetuks kohaloleku punktidest.
Ja veel üks väike märkuse selle näite kohta. Kui edastate piisavalt liiklust läbi IX-de, siis see vähendab ka teie haavatavust sarnaste rünnakute suhtes.

BGP konfiguratsioon

Siin on kaks teemat.

Ühenduvus
BGP konfiguratsioon

Üh connectivity osas oleme juba natuke rääkinud osas 1. Peamine on see, et liiklus teie klientideni kulgeks optimaalsel teel. Kuigi optimaalsus ei tähenda alati ainult latentsust, on madal latentsus tavaliselt peamine optimaalsuse näitaja. Mõne jaoks on see olulisem, teistele vähem. Kõik sõltub teenusest, mida te pakute.

Näide 1
Kui olete börs ja teie klientidele on olulised aja intervalid, mis on vähem kui millisekund, siis ei saa üldse rääkida interneti kasutamisest.

Näide 2
Kui olete mänguettevõte ja teie jaoks on olulised kümned millisekundid, siis on ühenduvus teie jaoks muidugi väga oluline.

Näide 3
Samuti tuleb mõista, et TCP protokolli omaduste tõttu sõltub andmeedastuse kiirus ühes TCP seansis ka RTT-st (Round Trip Time). CDN-võrgud on loodud ka selle probleemi lahendamiseks, viies sisu edastamise serverid lähemale sisu tarbijale.

Ühenduvuse uurimine on eraldi huvitav teema, mis väärib eraldi artiklit või artiklite seeriat ja nõuab head arusaamist sellest, kuidas internet "töötleb".

Kasulikud ressursid:

ripe.net
bgp.he.net

Näide
Toon vaid ühe väikese näite.
Oletame, et teie andmekeskus asub Moskvas ja teil on ainus ühisling – Rostelecom (AS12389). Sellisel juhul (single homed) ei ole BGP teile vajalik ja avalike aadressidena kasutate tõenäoliselt Rostelecomi aadressipooli.
Oletame, et pakute mingit teenust ja teil on piisavalt kliente Ukrainast, kes kurdavad suurte viivituste üle. Uurimisel leiate, et mõnede nende IP-aadressid asuvad võrgus 37.52.0.0/21.
Traceroute'i käivitamisel näete, et liiklus läheb läbi AS1299 (Telia) ning ping-testiga saate keskmise RTT 70 – 80 millisekundit. Seda võite näha ka Rostelecomi looking glass'il.
Whois utiliidiga (ripe.net veebilehel või kohalikku utiliiti kasutades) saate lihtsalt kindlaks teha, et plokk 37.52.0.0/21 kuulub AS6849-le (Ukrtelecom).
Seejärel, kui sisenete bgp.he.net , näete, et AS6849-l ei ole suhteid AS12389-ga (nad ei ole üksteise kliendid ega ühislülitid, neil ei ole ka peer'imisi). Aga kui vaatate peeride nimekirja , näete näiteks AS29226 (Mastertel) ja AS31133 (Megafon).
Leides nende teenusepakkujate looking glass'id, saate võrrelda teed ja RTT-d. Näiteks, Masterteli puhul on RTT juba umbes 30 millisekundit.
Seega, kui vahe 80 ja 30 millisekundi vahel on teie teenuse jaoks oluline, siis võib-olla peaksite mõtlema ühenduvusele, saama RIpest oma AS numbri, oma aadressipooli ja ühendama lisauplinkid ning/või looma kohaloleku punkte IX-ides.

BGP kasutamisel mitte ainult ei paranda te oma ühenduvust, vaid ka reserveerite oma internetiühenduse.

Käesolev dokument sisaldab soovitusi BGP seadistamiseks. Kuigi need soovitused on välja töötatud «best practice» põhimõtteid järgides, on need kindlasti kasulikud ja tegelikult peaksid olema osa tugevdamisest, millest me rääkisime esimeses osas.

DOS/DDOS kaitse

Praegu on DOS/DDOS rünnakud saanud paljude ettevõtete igapäevaeluks. Tegelikult rünnatakse teid teatud määral üsna sageli. Et te seda ei märka, tähendab vaid seda, et teie vastu pole korraldatud sihipärast rünnakut ja et need kaitsevahendid, mida te kasutate, isegi kui te ei tea sellest (erinevad operatsioonisüsteemide sisseehitatud kaitsed), on piisavad, et teenuse halvenemine oleks teie ja teie klientide jaoks minimaalne.

On olemas internetiressursse, mis kasutavad seadmete logisid, et reaalajas luua kauneid rünnakute kaarte.

Siin neid on võimalik leida linkidena.

Minu lemmik kaart CheckPointilt.

DDOS/DOS kaitse on tavaliselt kihiline. Et mõista, miks, tuleb mõista, milliseid DOS/DDOS rünnakute tüüpe on olemas (näiteks vt siin või siin)

Seega on meil kolm rünnaku tüüpi:

maht-rünnakud
protokolli rünnakud
rakenduse rünnakud

Kui te saate end kaht viimase tüübi rünnakute eest kaitsta kasutades näiteks tulemüüre, siis maht-rünnakute vastu ei saa te end kaitsta (muidugi, kui teie internetiühenduse kogumaht ei ole mitu terabitti, parem, kümneid terabitte).

Seega, esimene kaitseliin – kaitse «maht» rünnakute eest ja sellele kaitsele peaksid teie teenusepakkujad tagama. Kui te seda veel ei ole aru saanud, siis praegu lihtsalt vedas.

Näide
Oletame, et teil on mitu ülekannet, kuid ainult üks teenusepakkuja saab teile seda kaitset pakkuda. Kuid kui kogu liiklus läheb läbi ühe teenusepakkuja, siis kuidas jääb ühenduvus, millest me lühidalt varem rääkisime?
Rünnaku ajal peate osaliselt ühenduvusest loobuma.

see see on ajutine. Rünnaku korral saate käsitsi või automaatselt BGP-d ümber seadistada, suunates liikluse ainult selle teenusepakkuja kaudu, kes annab teile "katuse". Rünnaku lõppedes saate suunata marsruudi tagasi algsesse olekusse.

ei ole vajalik kogu liiklust suunata. Kui näiteks märkate, et mingite ülekannete või peer-ühenduste kaudu ei toimu rünnakut (või liiklus ei ole oluline), võite jätkata prefiksite reklaamimist konkurentsivõimeliste atribuutidega nende BGP naabrite suunas.

Teatud 'protokolli rünnakute' ja 'rakenduse rünnakute' kaitse saate usaldada partnerite hoolde.
Siin siin võite lugeda head uuringut (tõlge). Kuigi artikkel on kahe aasta vanune, annab see teile ülevaate lähenemistest, kuidas saate end DDOS rünnakute eest kaitsta.

Põhimõtteliselt võite sellega piirduda, usaldades oma kaitse täielikult välistele teenustele. Sellel lahendusel on oma eelised, kuid ka ilmne puudus. Asi on selles, et see võib tähendada (taas, sõltuvalt sellest, millega teie ettevõte tegeleb) äri ellujäämist. Ja selliste asjaolude usaldamine kolmandatele organisatsioonidele...

Seetõttu vaatame, kuidas korraldada teist ja kolmandat kaitseliini (kaitse teenusepakkujast lisaks).

Teine kaitseliin on liikluse filtreerimine ja piirajad (policers) teie võrku sisenedes.

Näide 1
Oletame, et olete DDOS-ilt 'katuse alla' saanud ühe teenusepakkuja abil. Oletame, et see teenusepakkuja kasutab liikluse filtreerimiseks Arborit ja filtreid oma võrgu piiril.
Arbori poolt 'töödeldav' ribalaius on piiratud ja teenusepakkuja ei saa loomulikult pidevalt lasta liiklusel, mis tuleb kõigilt nende partneritelt, kes on seda teenust tellinud, läbi filtreerimisvarustuse. Seetõttu ei filtreerita tavatingimustes liiklust.
Oletame, et käib SYN flood rünnak. Isegi kui olete tellinud teenuse, kus rünnaku korral suunatakse liiklus automaatselt filtreerimisele, ei toimu see kohe. Ühe minuti või rohkemaga jääte rünnaku alla. Ja see võib põhjustada teie seadmete talitlushäireid või teenuse halvenemist. Sellisel juhul piiramine piiripunkti marsruutimises, kuigi see toob kaasa, et mõned TCP sessioonid ei pruugi selle aja jooksul luua, päästab teie infrastruktuuri suurematest probleemidest.

Näide 2
Ebanormaalselt suur SYN-pakkide arv ei pruugi olla ainult SYN flood rünnaku tulemus. Oletame, et pakute teenust, kus teil võib olla samal ajal umbes 100 000 TCP ühendust (ühes andmekeskuses).
Oletame, et ühe teie peamise teenusepakkuja ajutise probleemi tõttu olete kaotanud poole sessioonidest. Kui teie rakendus on üles ehitatud nii, et see, „mõtlemata“, kohe (või mingi tagasihoidlikult ühtlane ajavahemik sessioonide jaoks) püüab ühendust taastada, siis saate umbes samaaegselt vähemalt 50 000 SYN-pakki.
Kui aga nende sessioonide kohal peaks töötama ssl/tls kätetõmbamine, mis eeldab sertifikaatide vahetamist, siis teie koormuse tasakaalustaja ressursside ebaefektiivne kasutamine on palju tõsisem "DDOS" kui lihtne SYN flood. Tundub, et koormuse tasakaalustajad peaksid selliseid sündmusi käsitlema, kuid... kahjuks oleme sellise probleemiga tõeliselt silmitsi seisnud.
Ja loomulikult päästab policer teie seadmed piiripunkti marsruuteris ka sel juhul.

Kolmas kaitsetase DDOS/DOS-i vastu on teie tulemüüri seaded.

Siin saate peatada nii teise kui kolmanda tüüpi rünnakud. Üldiselt võib kõik, mis jõuab tulemüüri, siin filtreerida.

Soovitus
Püüdke anda tulemüürile võimalikult vähe tööd, filtreerides võimalikult palju juba kahes esimeses kaitsejoonis. Ja see on põhjus.
Kas suuga on juhtunud, et juhuslikult genereerides liiklust, et kontrollida, kui hästi su serverite operatsioonisüsteem suudab DDOS-rünnakutele vastu seista, olete “tapanud” oma tulemüür, laadides seda 100 protsendi ulatuses tavalise intensiivsusega liiklusega? Kui ei, siis võib-olla lihtsalt seetõttu, et te ei ole proovinud?
Üldiselt on tulemüür, nagu ma juba mainisin — keeruline asi, ja see töötab hästi tuntud haavatavustega ja testitud lahendustega, kuid kui saadate midagi ebatavalist, lihtsalt mingit prügi või pakette vale päisega, siis on teil teatud, mitte just väike (minu kogemuse põhjal) tõenäosus, et võite isegi tipptasemel seadmed segadusse ajada. Seega, etapi 2 puhul laske tavaliste ACL-de (L3/L4 tasemel) kaudu teie võrku ainult see liiklus, mis peaks sinna sisse pääsema.