Tämä artikkeli on neljäs sarjassa "Kuinka ottaa verkkoinfrastruktuurisi hallintaan". Sarjan kaikkien artikkeleiden sisältö ja linkit löytyvät täällä.

В ensimmäinen osa Tässä luvussa tarkastelimme joitain verkkoturvallisuuden näkökohtia Data Center -segmentissä. Tämä osa on omistettu "Internet Access" -segmentille.

Internet-yhteys

Turvallisuusaihe on epäilemättä yksi monimutkaisimmista aiheista tietoverkkojen maailmassa. Kuten aiemmissa tapauksissa, vaatimatta syvyyttä ja täydellisyyttä, tarkastelen tässä melko yksinkertaisia, mutta mielestäni tärkeitä kysymyksiä, joiden vastaukset toivottavasti auttavat nostamaan verkkosi turvallisuustasoa.

Kun tarkastat tätä segmenttiä, kiinnitä huomiota seuraaviin seikkoihin:

• suunnittelu
• BGP-asetukset
• DOS/DDOS-suojaus
• liikenteen suodatus palomuurissa

Suunnittelu

Suosittelen esimerkkinä tämän segmentin suunnittelusta yritysverkostoa varten руководство Cisco sisällä TURVALLISTA mallia.

Tietenkin muiden myyjien ratkaisu näyttää sinulle houkuttelevammalta (katso. Gartner Quadrant 2018), mutta rohkaisematta sinua noudattamaan tätä mallia yksityiskohtaisesti, mielestäni on silti hyödyllistä ymmärtää sen taustalla olevat periaatteet ja ideat.

huomautus

SAFE:ssa "Etäkäyttö" -segmentti on osa "Internet Access" -segmenttiä. Mutta tässä artikkelisarjassa tarkastelemme sitä erikseen.

Tämän segmentin vakiovarusteet yritysverkossa ovat

• rajareitittimet
• palomuurit

Huomautus 1

Tässä artikkelisarjassa, kun puhun palomuurista, tarkoitan NGFW.

Huomautus 2

Jätän huomioimatta erilaisia ​​L2/L1- tai päällekkäisiä L2- ja L3-ratkaisuja, jotka ovat välttämättömiä L1/L2-liitettävyyden varmistamiseksi, ja rajoitan vain L3-tason ja sitä korkeamman tason ongelmiin. Osittain L1/L2-asioita käsiteltiin luvussa "Puhdistus ja dokumentointi".

Jos et ole löytänyt palomuuria tästä segmentistä, sinun ei pitäisi kiirehtiä johtopäätöksiä.

Tehdään samoin kuin kohdassa edellinen osaAloitetaan kysymyksellä: onko sinun tapauksessasi tarpeen käyttää palomuuria tässä segmentissä?

Voin sanoa, että tämä näyttää olevan oikeutetuin paikka käyttää palomuureja ja soveltaa monimutkaisia ​​liikenteen suodatusalgoritmeja. SISÄÄN osat 1 Mainitsimme 4 tekijää, jotka voivat häiritä palomuurien käyttöä datakeskussegmentissä. Mutta täällä ne eivät ole enää niin merkittäviä.

Esimerkki 1. viive

Mitä tulee Internetiin, on turha puhua edes noin 1 millisekunnin viiveistä. Siksi tämän segmentin viive ei voi olla palomuurin käyttöä rajoittava tekijä.

Esimerkki 2. Suorituskyky

Joissakin tapauksissa tämä tekijä voi silti olla merkittävä. Tästä syystä saatat joutua sallimaan osan liikenteestä (esimerkiksi kuormantasainten liikenteen) ohittamaan palomuurin.

Esimerkki 3. Luotettavuus

Tämä tekijä on vielä otettava huomioon, mutta Internetin itsensä epäluotettavuuden vuoksi sen merkitys tälle segmentille ei ole yhtä merkittävä kuin datakeskuksen kannalta.

Oletetaan siis, että palvelusi toimii http/https:n päällä (lyhyillä istunnoilla). Tässä tapauksessa voit käyttää kahta erillistä laatikkoa (ilman HA:ta) ja jos toisessa on reititysongelma, siirrä kaikki liikenne toiseen.

Tai voit käyttää palomuuria läpinäkyvässä tilassa ja antaa liikenteen ohittaa palomuurin, jos ne epäonnistuvat, kun ongelma ratkaistaan.

Siksi todennäköisesti vain hinta voi olla se tekijä, joka pakottaa sinut luopumaan palomuurien käytöstä tässä segmentissä.

Tärkeää!

On houkutus yhdistää tämä palomuuri tietokeskuksen palomuuriin (käytä yhtä palomuuria näille segmenteille). Ratkaisu on periaatteessa mahdollinen, mutta sinun on ymmärrettävä se, koska Internet-käytön palomuuri on itse asiassa puolustuksesi eturintamassa ja "ottaa haltuunsa" ainakin osan haitallisesta liikenteestä, joten sinun on tietysti otettava huomioon lisääntynyt riski, että tämä palomuuri poistetaan käytöstä. Eli käyttämällä samoja laitteita näissä kahdessa segmentissä heikennät merkittävästi datakeskussegmentin saatavuutta.

Kuten aina, sinun on ymmärrettävä, että yrityksen tarjoamasta palvelusta riippuen tämän segmentin suunnittelu voi vaihdella suuresti. Kuten aina, voit valita erilaisia ​​lähestymistapoja tarpeidesi mukaan.

Esimerkki

Jos olet sisällöntuottaja, jolla on CDN-verkko (katso esim. artikkelisarja), et ehkä halua luoda infrastruktuuria kymmeniin tai jopa satoihin läsnäolopisteisiin käyttämällä erillisiä laitteita liikenteen reitittämiseen ja suodattamiseen. Se tulee kalliiksi, ja se voi olla yksinkertaisesti tarpeetonta.

BGP:tä varten sinulla ei välttämättä tarvitse olla omia reitittimiä, voit käyttää avoimen lähdekoodin työkaluja, kuten quagga. Joten ehkä tarvitset vain palvelimen tai useita palvelimia, kytkimen ja BGP:n.

Tässä tapauksessa palvelimesi tai useat palvelimet voivat toimia paitsi CDN-palvelimena myös reitittimenä. Tietysti on vielä paljon yksityiskohtia (kuten tasapainon varmistaminen), mutta se on toteutettavissa, ja se on lähestymistapa, jota olemme menestyksekkäästi käyttäneet yhdelle kumppanillemme.

Sinulla voi olla useita tietokeskuksia, joissa on täydellinen suojaus (palomuurit, Internet-palveluntarjoajien tarjoamat DDOS-suojauspalvelut) ja kymmeniä tai satoja "yksinkertaistettuja" läsnäolopisteitä, joissa on vain L2-kytkimet ja -palvelimet.

Mutta entä suoja tässä tapauksessa?

Katsotaanpa esimerkiksi viime aikoina suosittuja DNS-vahvistus DDOS-hyökkäys. Sen vaara piilee siinä, että syntyy suuri määrä liikennettä, joka yksinkertaisesti "tukkii" 100 % kaikista uplinkeistäsi.

Mitä meillä on suunnittelumme tapauksessa.

• jos käytät AnyCastia, liikenne jaetaan läsnäolopisteesi kesken. Jos kokonaiskaistanleveytesi on terabittiä, tämä itse asiassa (mutta viime aikoina on tehty useita terabitin luokkaa olevia haitallisen liikenteen hyökkäyksiä) suojaa sinua "ylivuodelta" uplinkeiltä
• Jos jotkin uplinkit kuitenkin tukkeutuvat, poistat tämän sivuston palvelusta (lopeta etuliitteen mainostaminen)
• voit myös kasvattaa "täydellisistä" (ja vastaavasti suojatuista) datakeskuksistasi lähetettävän liikenteen osuutta, mikä poistaa merkittävän osan haitallisesta liikenteestä suojaamattomista paikoista.

Ja vielä yksi pieni huomautus tähän esimerkkiin. Jos lähetät tarpeeksi liikennettä IX:iden kautta, tämä vähentää myös haavoittuvuuttasi tällaisille hyökkäyksille

BGP:n asetukset

Tässä on kaksi aihetta.

• Yhteydet
• BGP:n asetukset

Olemme jo puhuneet hieman liitettävyydestä osat 1. Tarkoituksena on varmistaa, että liikenne asiakkaisiisi seuraa optimaalista reittiä. Vaikka optimaalisuus ei aina tarkoita vain latenssia, alhainen latenssi on yleensä optimiteetin pääindikaattori. Joillekin yrityksille tämä on tärkeämpää, toisille vähemmän. Kaikki riippuu tarjoamastasi palvelusta.

Esimerkki 1

Jos olet vaihto, ja alle millisekuntien aikavälit ovat tärkeitä asiakkaillesi, niin minkäänlaisesta Internetistä ei tietenkään voi puhua ollenkaan.

Esimerkki 2

Jos olet peliyhtiö ja kymmenet millisekunnit ovat sinulle tärkeitä, niin tietysti liitettävyys on sinulle erittäin tärkeää.

Esimerkki 3

Sinun on myös ymmärrettävä, että TCP-protokollan ominaisuuksien vuoksi tiedonsiirtonopeus yhden TCP-istunnon aikana riippuu myös RTT:stä (Round Trip Time). CDN-verkkoja rakennetaan myös tämän ongelman ratkaisemiseksi siirtämällä sisällönjakelupalvelimia lähemmäksi tämän sisällön kuluttajaa.

Yhteyden tutkiminen on sinänsä mielenkiintoinen aihe, joka ansaitsee oman artikkelinsa tai artikkelisarjansa ja vaatii hyvää ymmärrystä Internetin "toimimisesta".

Hyödyllisiä resursseja:

ripe.net
bgp.he.net

Esimerkki

Annan vain yhden pienen esimerkin.

Oletetaan, että datakeskuksesi sijaitsee Moskovassa ja sinulla on yksi uplink - Rostelecom (AS12389). Tässä tapauksessa (single homed) et tarvitse BGP:tä, ja käytät todennäköisesti Rostelecomin osoitevalikoimaa julkisina osoitteina.

Oletetaan, että tarjoat tietyn palvelun ja sinulla on riittävä määrä asiakkaita Ukrainasta ja he valittavat pitkistä viivästyksistä. Tutkimuksen aikana huomasit, että joidenkin IP-osoitteet ovat 37.52.0.0/21-ruudukossa.

Suorittamalla jäljitysreitin huomasit liikenteen kulkevan AS1299:n (Telia) kautta, ja suorittamalla pingin sait keskimääräiseksi RTT:ksi 70 - 80 millisekuntia. Voit nähdä tämän myös osoitteessa näköinen lasi Rostelecom.

Käyttämällä whois-apuohjelmaa (ripe.netissä tai paikallisessa apuohjelmassa) voit helposti määrittää, että lohko 37.52.0.0/21 kuuluu AS6849:lle (Ukrtelecom).

Seuraavaksi menemällä kohtaan bgp.he.net näet, että AS6849:llä ei ole suhdetta AS12389:ään (ne eivät ole asiakkaita tai uplinkkejä toisiinsa, eivätkä heillä ole peeringiä). Mutta jos katsoo lista vertaisista AS6849:lle näet esimerkiksi AS29226 (Mastertel) ja AS31133 (Megafon).

Kun löydät näiden palveluntarjoajien näkölasin, voit verrata polkua ja RTT:tä. Esimerkiksi Mastertelille RTT on noin 30 millisekuntia.

Joten jos ero 80 ja 30 millisekunnin välillä on merkittävä palvelusi kannalta, sinun on ehkä harkittava liitettävyyttä, hankittava AS-numerosi, osoitevarastosi RIPE:ltä ja yhdistettävä lisälinkkejä ja/tai luotava läsnäolopisteitä IX:issä.

Kun käytät BGP:tä, sinulla ei ole vain mahdollisuus parantaa yhteyksiä, vaan myös ylläpidät tarpeettomasti Internet-yhteyttäsi.

Tämä asiakirja sisältää suosituksia BGP:n määrittämiseksi. Huolimatta siitä, että nämä suositukset on kehitetty palveluntarjoajien "parhaiden käytäntöjen" perusteella, niistä huolimatta (jos BGP-asetuksesi eivät ole aivan perusasetukset) ne ovat epäilemättä hyödyllisiä ja niiden pitäisi itse asiassa olla osa kovettumista, josta keskustelimme ensimmäinen osa.

DOS/DDOS-suojaus

Nyt DOS/DDOS-hyökkäyksistä on tullut arkipäivää monille yrityksille. Itse asiassa sinua vastaan ​​hyökätään melko usein tavalla tai toisella. Se, että et ole vielä huomannut tätä, tarkoittaa vain sitä, että sinua vastaan ​​ei ole vielä järjestetty kohdennettua hyökkäystä ja että käyttämäsi suojaustyökalut, jopa tietämättäsi (erilaiset käyttöjärjestelmien sisäänrakennetut suojaukset), riittävät varmistaa, että tarjotun palvelun heikkeneminen on mahdollisimman pieni sinulle ja asiakkaillesi.

Internetissä on resursseja, jotka piirtävät laitteistolokien perusteella kauniita hyökkäyskarttoja reaaliajassa.

Täällä löydät linkkejä niihin.

Oma suosikki kartta CheckPointista.

DDOS/DOS-suojaus on yleensä kerrostettu. Ymmärtääksesi miksi, sinun on ymmärrettävä, minkä tyyppisiä DOS/DDOS-hyökkäyksiä on olemassa (katso esim. täällä tai täällä)

Eli meillä on kolmenlaisia ​​hyökkäyksiä:

• Volumetriset hyökkäykset
• protokollahyökkäykset
• sovellushyökkäykset

Jos pystyt suojautumaan kahdelta viimeiseltä hyökkäykseltä esimerkiksi palomuurien avulla, et voi suojautua hyökkäyksiltä, ​​joiden tarkoituksena on "kuormittaa" uplinkit (tietenkin, jos Internet-kanavien kokonaiskapasiteettia ei lasketa terabiteinä, tai vielä parempaa, kymmenissä terabiteissä).

Siksi ensimmäinen puolustuslinja on suojaus "volumetrisia" hyökkäyksiä vastaan, ja palveluntarjoajasi tai palveluntarjoajien on tarjottava tämä suoja sinulle. Jos et ole vielä tajunnut tätä, olet nyt onnekas.

Esimerkki

Oletetaan, että sinulla on useita uplinkkejä, mutta vain yksi palveluntarjoajista voi tarjota sinulle tämän suojan. Mutta jos kaikki liikenne kulkee yhden palveluntarjoajan kautta, entä sitten yhteydet, joista keskustelimme lyhyesti hieman aiemmin?

Tässä tapauksessa joudut osittain uhraamaan yhteyden hyökkäyksen aikana. Mutta

• tämä on vain hyökkäyksen ajan. Hyökkäyksen sattuessa voit määrittää BGP:n manuaalisesti tai automaattisesti uudelleen niin, että liikenne kulkee vain sen palveluntarjoajan kautta, joka tarjoaa sinulle "sateenvarjon". Kun hyökkäys on ohi, voit palauttaa reitityksen aiempaan tilaan
• Kaikkea liikennettä ei tarvitse siirtää. Jos esimerkiksi huomaat, että joidenkin uplinkkien tai peering-yhteyksien kautta ei ole hyökkäyksiä (tai liikenne ei ole merkittävää), voit jatkaa kilpailevien attribuuttien etuliiteiden mainostamista näitä BGP-naapureita kohtaan.

Voit myös delegoida suojauksen "protokollahyökkäyksiä" ja "sovellushyökkäyksiä" vastaan ​​kumppaneille.
Täällä täällä voit lukea hyvän tutkimuksen (käännös). Totta, artikkeli on kaksi vuotta vanha, mutta se antaa sinulle käsityksen lähestymistavoista, kuinka voit suojautua DDOS-hyökkäyksiltä.

Periaatteessa voit rajoittaa itsesi tähän ulkoistamalla suojauksesi kokonaan. Tällä päätöksellä on etuja, mutta siinä on myös ilmeinen haitta. Tosiasia on, että voimme puhua (jälleen riippuen siitä, mitä yrityksesi tekee) yrityksen selviytymisestä. Ja luota sellaisiin kolmansiin osapuoliin...

Siksi tarkastellaan, kuinka järjestää toinen ja kolmas puolustuslinja (lisäksi palveluntarjoajan suojaan).

Joten toinen puolustuslinja on suodatus ja liikenteenrajoittimet (poliisit) verkkosi sisäänkäynnissä.

Esimerkki 1

Oletetaan, että olet suojannut itsesi sateenvarjolla DDOS:ää vastaan ​​jonkin palveluntarjoajan avulla. Oletetaan, että tämä palveluntarjoaja käyttää Arboria liikenteen suodattamiseen ja suodattimia verkkonsa reunalla.

Kaistanleveys, jonka Arbor voi "käsitellä", on rajoitettu, eikä palveluntarjoaja tietenkään voi jatkuvasti siirtää kaikkien tämän palvelun tilaavien kumppaneidensa liikennettä suodatuslaitteiden läpi. Siksi normaalioloissa liikennettä ei suodateta.

Oletetaan, että kyseessä on SYN-tulvahyökkäys. Vaikka tilasit palvelun, joka vaihtaa liikenteen automaattisesti suodatukseen hyökkäyksen sattuessa, tämä ei tapahdu hetkessä. Minuutin tai kauemmin olet hyökkäyksen kohteena. Ja tämä voi johtaa laitteesi epäonnistumiseen tai palvelun heikkenemiseen. Tässä tapauksessa liikenteen rajoittaminen reunareitityksessä, vaikka se johtaakin siihen, että joitakin TCP-istuntoja ei muodosteta tänä aikana, säästää infrastruktuurisi suuremmilta ongelmilta.

Esimerkki 2

Epätavallisen suuri määrä SYN-paketteja ei välttämättä ole pelkästään SYN-tulvahyökkäyksen tulos. Oletetaan, että tarjoat palvelun, jossa sinulla voi olla samanaikaisesti noin 100 tuhatta TCP-yhteyttä (yhteen datakeskukseen).

Oletetaan, että puolet istunnoistasi potkitaan lyhyen aikavälin ongelman seurauksena jonkin pääpalveluntarjoajan kanssa. Jos sovelluksesi on suunniteltu siten, että se yrittää kahta kertaa miettimättä välittömästi (tai jonkin ajan kuluttua, joka on sama kaikille istunnoille) muodostaa yhteyden uudelleen, niin saat noin 50 tuhatta SYN-pakettia samanaikaisesti.

Jos sinun on esimerkiksi suoritettava ssl/tls-kättely näiden istuntojen päällä, mikä tarkoittaa varmenteiden vaihtoa, niin kuormituksen tasapainottajan resurssien kulumisen kannalta tämä on paljon vahvempi "DDOS" kuin yksinkertainen. SYN-tulva. Vaikuttaa siltä, ​​että tasapainottajien pitäisi käsitellä tällaisia ​​​​tapahtumia, mutta... valitettavasti olemme tällaisen ongelman edessä.

Ja tietysti poliisi reunareitittimessä säästää laitteesi tässäkin tapauksessa.

Kolmas suojaustaso DDOS/DOS:ia vastaan ​​ovat palomuurin asetukset.

Täällä voit pysäyttää sekä toisen että kolmannen tyypin hyökkäykset. Yleensä kaikki, mikä tulee palomuuriin, voidaan suodattaa täällä.

neuvosto

Yritä antaa palomuurille mahdollisimman vähän työtä ja suodattaa mahdollisimman paljon kahdelta ensimmäiseltä puolustuslinjalta. Ja siksi.

Onko sinulle koskaan käynyt niin, että kun olet vahingossa generoiessasi liikennettä tarkistaaksesi, kuinka vastustuskykyinen palvelintesi käyttöjärjestelmä on DDOS-hyökkäyksille, "tappasit" palomuurisi lataamalla sen 100-prosenttisesti, liikenteellä normaalilla intensiteetillä ? Jos ei, ehkä se johtuu yksinkertaisesti siitä, ettet ole kokeillut?

Yleensä palomuuri, kuten sanoin, on monimutkainen asia, ja se toimii hyvin tunnettujen haavoittuvuuksien ja testattujen ratkaisujen kanssa, mutta jos lähetät jotain epätavallista, vain roskaa tai paketteja, joissa on virheelliset otsikot, olet joidenkin kanssa, et niin pienellä todennäköisyydellä (kokemukseni perusteella), voit järkyttää jopa huippuluokan laitteita. Siksi vaiheessa 2, käyttämällä tavallisia ACL-luetteloita (L3/L4-tasolla), salli verkkoosi vain liikenne, jonka pitäisi tulla sinne.

Liikenteen suodatus palomuurin kautta

Jatketaanpa keskustelua palomuurista. Sinun on ymmärrettävä, että DOS/DDOS-hyökkäykset ovat vain yksi kyberhyökkäystyyppi.

DOS/DDOS-suojauksen lisäksi meillä voi olla myös jotain seuraavanlaista ominaisuuksien luetteloa:

• sovellusten palomuuri
• uhkien esto (virustorjunta, vakoiluohjelmien torjunta ja haavoittuvuus)
• URL-suodatus
• tietojen suodatus (sisällön suodatus)
• tiedostojen esto (tiedostotyyppien esto)

Sinun on päätettävä, mitä tarvitset tästä luettelosta.

Jatkuu

Lähde: will.com