See artikkel on neljas osa artiklite seeriast 'Kuidas võtta oma võrgu infrastruktuuri kontrolli alla'. Kõigi seeria artiklite sisu ja lingid leiate siit.

V esimeses osas selles peatükis käsitlesime mõningaid andmekeskuse võrgu turvalisuse aspekte. See osa keskendub 'Internet Access' sektorile.

Internet access

Turvalisuse teema on kindlasti üks keerulisemaid teemasid andmeside maailmas. Nagu varasemateski osa, ei pretendeeri ma sügavusele ja täielikkusele, kuid käsitlen siin üsna lihtsaid, kuid minu arvates olulisi küsimusi, millele antud vastused aitavad tõsta teie võrgu kaitsetaset.

Selle sektori auditi käigus pöörake tähelepanu järgmistele aspektidele:

disain
BGP seaded
DOS/DDOS kaitse
liikluse filtreerimine tulemüüris

Disain

Disaini näitena soovitan ettevõtte võrgu jaoks juhend Cisco poolt, raamistikus SAFE mudel.

Loomulikult võib mõne teise tootja lahendus teile tunduda atraktiivsem (vt. Gartneri kvadrant 2018), kuid kuigi ma ei kutsu teid üles järgima seda disaini üksikasju, pean siiski kasulikuks mõista selle aluseks olevaid põhimõtteid ja ideid.

Märkus
SAFE segmendis on «Remote Access» osa «Internet Access'ist». Kuid sel korral käsitleme seda eraldi.

Selle segmendi standardvarustus ettevõtte (enterprise network) jaoks sisaldab

piirimaršrutajad (border routers)
tulemüürid

Märkus 1
Käesolevas artiklite tsüklis, kui ma räägin tulemüüridest, mõistan ma sellega NGFW.

Märkus 2
Jätan kõrvale mitmesuguste L2/L1 või L2 over L3 lahenduste käsitlemise, mis on vajalik L1/L2 ühenduse tagamiseks, ja piirdun ainult L3 taseme ja kõrgemate küsimustega. Teatud määral on L1/L2 küsimusi käsitletud peatükis «Puhastamine ja dokumenteerimine«.

Kui te ei leia selle segmendi tulemüüri, siis ärge kiirustage järelduste tegemisega.

Alustame nagu eelmisel osal, küsimusest, kas tulemüüri kasutamine on teie jaoks selles segmendis vajalik?

Võin öelda, et see tundub olevat kõige õigustatud koht tulemüüride kasutamiseks ja keerukate liiklusfiltreerimise algoritmide rakendamiseks. Osas 1 mainisime 4 tegurit, mis võivad tulemüüride kasutamist andmekeskuse segmendis tõkestada. Siin ei ole need aga enam nii olulised. Näide 1.

Näide 1. Viivitus
Internetis ei ole mõtet rääkida isegi 1 millisekundi viivitustest. Seetõttu ei saa viivitus selle valdkonna osas olla tegur, mis piirab tulemüüri kasutamist.

Näide 2. Tootlikkus
Mõnel juhul võib see tegur ikkagi olla oluline. Seetõttu peate võib-olla osa liiklust (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 ebakindlust, ei ole selle tähtsus antud valdkonnas nii suur kui andmekeskuses.
Oletame, et teie teenus töötab http/https pinnal (lühikeste seanssidega). Sellisel juhul saate kasutada kahte sõltumatut seadet (ilma HA-ta) ja juhuks, kui ühel neist tekivad marsruutimise probleemid, suunata kogu liiklus teisele.
Või võite kasutada tulemüüre läbipaistvas režiimis ja kui need peaksid rikki minema, suunata liiklus probleemi lahendamise ajaks mööda tulemüüre.

Seetõttu võib just see hind olla see tegur, mis sunnib teid loobuma tulemüüride rakendamisest selles valdkonnas.

Oluline!
On the one hand, it might be tempting to combine this firewall with the data center firewall (using one firewall for these segments). The solution is theoretically possible, but it’s important to understand that since the 'Internet Access' firewall is essentially at the forefront of your defense and is dealing with at least some portion of malicious traffic, there is, of course, an increased risk that this firewall could be compromised. In other words, using the same devices in both of these segments will significantly reduce the availability of your data center segment.

As always, it’s important to understand that depending on the service the company provides, the design of this segment can vary significantly. You can choose different approaches based on the requirements.

Näide
If you are a content provider with a CDN network (see, for example, a series of articles), you may not want to create infrastructure with dozens, or even hundreds, of points of presence using separate devices for traffic routing and filtering. This would be expensive and may simply be excessive.
BGP jaoks ei ole teil tingimata vaja pühendatud ruutereid, võite kasutada avatud lähtekoodiga tööriistu, näiteks Quagga. Seetõttu võib-olla on kõik, mida vajate, server või mitu serverit, lüliti ja BGP.
Sel juhul võivad teie server või mitmed serverid toimida mitte ainult CDN-serverina, vaid ka ruuteri rollis. Muidugi on siin veel palju detaile (näiteks, kuidas tagada koormuse tasandamine), kuid see on teostatav ning seda lähenemist oleme edukalt rakendanud ühe meie partneri jaoks.
Teil võivad olla mitu andmekeskust täieliku kaitsega (tulekahjusüütajad, DDoS-i kaitseteenused, mida pakuvad teie interneti pakkujad) ja kümneid või sadu "lihtsustatud" kohaloleku punkte, vaid L2 lülitite ja serveritega.
Aga kuidas on kaitse antud juhul?
Vaatame näiteks viimasel ajal populaarsust kogunud DNS Amplification DDoS rünnakut. Selle oht seisneb selles, et genereeritakse suur hulk liiklust, mis lihtsalt "täpib" 100% kõik teie ülestõusud.
Mida me meie disaini puhul näeme.

kui kasutate AnyCast'i, siis jaotatakse liiklus teie kohalolekupunktide vahel. Kui teie kogurbalanss on terabittides, siis see iseenesest kaitseb teid "ülevoolu" eest, kuigi viimasel ajal on olnud mitmeid terabittide suurusi pahatahtliku liiklusega rünnakuid.

kui mõni uplink ikkagi "tükib", siis lihtsalt eemaldage see koht teenusest (lõpetage prefiksi kuulutamine).

võite samuti suurendada liikluse osakaalu, mis tuleb teie "täistöövõimega" (ja seetõttu kaitstud) andmekeskustest, selle kaudu eemaldades suure osa pahatahtlikust liiklusest kaitsmata kohalolekupunktidest.
Ja veel üks tähelepanek selle näite juurde. Kui edastate piisavalt liiklust IX-ide kaudu, siis see vähendab ka teie haavatavust taolistele rünnakutele.

BGP seadistamine

Siin on kaks teemat.

Ühenduvus
BGP seadistamine

Konnektiivsusest oleme juba natuke rääkinud. mainisime 4 tegurit, mis võivad tulemüüride kasutamist andmekeskuse segmendis tõkestada. Siin ei ole need aga enam nii olulised.. Oluline on, et liiklus teie klientidele liiguks optimaalsel teel. Kuigi optimaalsus ei tähenda alati ainult viivitust, on madal viivitus sageli peamine näitaja optimaalsuse osas. Mõnes ettevõttes on see olulisem, teistes vähem. Kõik sõltub teenusest, mida pakute.

Näide 1
Kui olete börs ja teie klientide jaoks on olulised ajaintervallid, mis on vähem kui millisekund, siis on selge, et ei saa rääkida üldse internetist.

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

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

Ühenduvuse uurimine on eraldi huvitav teema, mis väärib eraldi artiklit või artiklite seeriat ning nõuab head arusaamist, kuidas internet on 'konstrukteeritud'.

Kasulikud ressursid:

ripe.net
bgp.he.net

Näide
Toon vaid ühe väikese näite.
Oletame, et teie andmekeskus asub Moskvasse ja teil on ainult üks ülekandeühendus – Rostelecom (AS12389). Sellisel juhul (üksik ühendus) ei ole BGP vajalik ning avalike aadressidena kasutate tõenäoliselt Rostelecomi aadressipooli.
Oletame, et pakute mingit teenust ning teil on piisavalt kliente Ukrainast, kes kurdavad suurte viivituste üle. Uurimise käigus selgitate, et osade nende IP-aadressid asuvad vahemikus 37.52.0.0/21.
Traceroute'i teostades näete, et liiklus läheb läbi AS1299 (Telia), ning ping'i teostades saate keskmiseks RTT-ks 70–80 millisekundit. Seda saate näha ka Rostelecomi looking glass'il..
Whois utiliidiga (ripe.net-i leheküljel või kohaliku utiliidi abil) saate hõlpsasti määrata, et plokk 37.52.0.0/21 kuulub AS6849 (Ukrtelecom).
Seejärel, kui minge lehele bgp.he.net näete, et AS6849-l pole suhteid AS12389-ga (nad ei ole üksteise kliendid ega ülekanded ning neil pole ka peer'ingut). Kuid kui vaatate AS6849 peer'ide 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 umbes 30 millisekundit.
Nii et, kui 80 ja 30 millisekundi vahe on teie teenuse jaoks oluline, siis peaksite võib-olla mõtlema ühenduvusele, saama RIPE'lt oma AS-i numbri, oma aadresside basseini ning lisama täiendavad uplinkid ja/või looma IX-ides kohaloleku punkte.

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

See dokument sisaldab soovitusi BGP seadistamiseks. Kuigi need soovitused on välja töötatud teenuse pakkujate parimate praktikate põhjal, on need ikkagi (kui teie BGP seadistused ei ole liiga elemetaarsed) kindlasti kasulikud ja peaksid tegelikult olema osa tugevdamisest, millest me rääkisime. esimeses osas.

DOS/DDOS kaitse

Praegu on DOS/DDOS rünnakud saanud paljude ettevõtete igapäevaseks reaalsuseks. Tegelikult rünnatakse teid mingil kujul üsna sageli. See, et te seda praegu ei märka, viitab vaid sellele, et suunatud rünnak pole veel teie vastu toimunud, ja need kaitsevahendid, mida te kasutate, isegi ilma teadmiseta (näiteks erinevad operatsioonisüsteemide sisseehitatud kaitsed), on piisavad, et teenuse halvenemine teie ja teie klientide jaoks oleks võimalikult vähe märgatav.

On olemas veebiallikaid, mis põhinevad seadmete logidel, ja mis reaalajas joonistavad rünnakute ilusaid kaarte.

Siit nendele on võimalik leida linke.

Minu lemmik kaart CheckPointilt.

DDOS/DOS kaitse on tavaliselt kihiline. Selle põhjuse mõistmiseks on oluline teada, millised DOS/DDOS rünnakute tüübid eksisteerivad (vt näiteks, siit või siit)

See tähendab, et meil on kolm tüüpi rünnakuid:

volumetrilised rünnakud
protokolli rünnakud
rakenduse rünnakud

Kui te saate viimaste kahe tüübi rünnakute eest ise kaitsta, kasutades näiteks tulemüüre, siis te ei suuda kaitsta ennast rünnakute eest, mis on suunatud teie uplink'idele (kui teie internetikanalite kogumaht ei ole tühjakäigul terabittides, veel parem, kümnetes terabittides).

Seetõttu on esimene kaitseliin kaitse «volumetriliste» rünnakute eest, ja selle kaitse peab tagama teie teenusepakkuja või teenusepakkujad. Kui te pole seda veel mõistnud, siis praegu teil lihtsalt vedanud.

Näide
Oletame, et teil on mitu uplinki, kuid ainult üks teenusepakkuja suudab teile seda kaitset pakkuda. Aga kui kogu liiklus läheb läbi ühe teenusepakkuja, siis kust jääb meeldetuletus, millest me varem lühidalt rääkisime?
Rünnaku ajal peate selle juures osaliselt ohverdama ühenduvuse. Kuid

see kehtib ainult rünnaku ajal. Rünnaku korral saate käsitsi või automaatselt BGP-d ümber seadistada, nii et liiklus läheks ainult läbi teenusepakkuja, kes annab teile «varju». Rünnaku lõppedes saate suunamise tagasi algsesse seisundisse.

Ei ole vajalik kogu liiklust tõlkida. Kui näiteks näete, et mõnedest uplinkidest või peer'idest rünnakuid ei tule (või liiklus ei ole märkimisväärne), saate jätkata prefixide reklaamimist konkurentsivõimeliste atribuutidega nende BGP naabrite suunal.

«Protokollirünnakute» ja «rakendusrünnakute» kaitse võite samuti usaldada partneritele.
Siin on siit võite lugeda head uuringut (tõlge). Tõsi, artikkel on kaheaastane, kuid see annab teile ülevaate lähenemistest, kuidas saate DDOS rünnakute eest kaitsta.

Põhimõtteliselt võite sellega piirduda, usaldades kogu oma kaitse out-source'ile. Sellel lahendusel on plussid, kuid on ka ilmselge miinus. Asi on selles, et see võib (taas sõltuvalt sellest, millega teie ettevõte tegeleb) tähendada äri ellujäämist. Ja selliseid asju kolmandatele organisatsioonidele usaldada...

Seega vaatame, kuidas korraldada teist ja kolmandat kaitseliini (kaitse täiendamiseks teenusepakkuja poolt).

Nii et teine kaitseliin on filtratsioon ja liikluse piirajad (policers) teie võrku sisenemisel.

Näide 1
Oletame, et olete DDoS-i eest kaitstud mõne teenusepakkuja kaudu. Oletame, et see teenusepakkuja kasutab liikluse filtreerimiseks Arbori ning filtreerimist oma võrgu piiridel.
Arbori „näitus” on piiratud, ja teenusepakkuja ei saa loomulikult pidevalt suunata kogu oma partnerite liiklust läbi filtreerimisseadmete, kes on tellinud sellise teenuse. Seega tavatingimustes liiklust ei filtreerita.
Oletame, et toimub SYN flood rünne. Isegi kui olete tellinud teenuse, mille korral rünne aeg-ajalt liiklus automaatselt filtreerimisele suunatakse, ei toimu see kohe. Ühe minuti või rohkemate minutite jooksul olete endiselt rünnaku all. See võib põhjustada teie seadmete rikke või teenuse halvenemist. Sel juhul piiratud liiklus piirmarsruutimise kaudu, kuigi see tähendab, et mõned TCP sessioonid ei saa selle aja jooksul luua, päästab teie infrastruktuuri suurematest probleemidest.

Näide 2
Anomaalne suur hulk SYN-pakette ei pruugi olla mitte ainult SYN flooding rünnaku tagajärg. Oletame, et pakute teenust, kus teil võib olla korraga umbes 100 000 TCP-ühendust (ühes andmekeskuses).
Oletame, et ühe teie peamise teenusepakkuja lühiajalise probleemi tõttu katkestati pooled sessioonidest. Kui teie rakendus on üles ehitatud nii, et see „ei mõtle kaua”, vaid kohe (või mõne ühetaolise ajavahemiku jooksul kõigi sessioonide vahel) üritab ühendust taastada, siis saate umbes samal ajal vähemalt 50 000 SYN-paketti.
Kui nende sessioonide peal peab näiteks toimuma SSL/TLS handshake, mis eeldab sertifikaatide vahetamist, siis ressursi ammendamise seisukohalt teie koormuse tasakaalustajale on see palju tõhusam „DDoS” kui lihtne SYN flooding. Tundub, et koormuse tasakaalustajad peaksid selliseid olukordi haldama, kuid... kahjuks oleme sellise probleemiga silmitsi seisnud.
Ja loomulikult päästab policer piiri marsruuteris teie seadmed ka sel juhul.

Kolmas kaitsetase DDOS/DOS rünnakute vastu on teie tulemüüri seaded.

Siin saate peatada nii teise kui ka kolmanda tüübi rünnakud. Üldiselt on kõik, mis jõuab tulemüüri, filtreeritav siin.

Nõuanne
Püüdke anda tulemüürile võimalikult vähe tööd, filtreerides esimeses kahes kaitseliinis võimalikult palju. Ja siin on põhjus.
Kas olete kunagi kogenud, et juhuslikult genereerides liiklust, et kontrollida, kui vastupidav on teie serverite operatsioonisüsteem DDOS rünnakute suhtes, olete "tapnud" oma tulemüüri, laadides seda 100 protsendi ulatuses tavalise intensiivsusega liiklusega? Kui ei, siis võib-olla lihtsalt sellepärast, et te pole proovinud?
Üldiselt on tulemüür, nagu ma juba ütlesin, keeruline asi. See töötab hästi tuntud haavatavustega ja testitud lahendustega, kuid kui saadate midagi ebatavalist, lihtsalt mõne jama või vale päisega pakettide, siis on teil mõningane, mitte just väike (minu kogemuse kohaselt) tõenäosus segadusse ajada isegi tipptasemel seadmeid. Seetõttu laske 2. etapis tavaliste ACL-ide (L3/L4 tasemel) abil teie võrku ainult seda liikumist, mis tõeliselt sinna sobib.