Hoe om beheer oor jou netwerkinfrastruktuur te neem. Hoofstuk drie. Netwerk sekuriteit. Deel twee

Hierdie artikel is die vierde in die reeks "Hoe om beheer oor jou netwerkinfrastruktuur te neem." Die inhoud van alle artikels in die reeks en skakels kan gevind word hier.

В die eerste deel In hierdie hoofstuk het ons na sommige aspekte van netwerksekuriteit in die Datasentrum-segment gekyk. Hierdie deel sal gewy word aan die segment "Internettoegang".

Hoe om beheer oor jou netwerkinfrastruktuur te neem. Hoofstuk drie. Netwerk sekuriteit. Deel twee

toegang tot die internet

Die onderwerp van sekuriteit is ongetwyfeld een van die mees komplekse onderwerpe in die wêreld van datanetwerke. Soos in vorige gevalle, sonder om aanspraak te maak op diepte en volledigheid, sal ek hier redelik eenvoudig oorweeg, maar na my mening belangrike vrae, waarvan die antwoorde, ek hoop, sal help om die vlak van sekuriteit van u netwerk te verhoog.

Wanneer u hierdie segment oudit, let op die volgende aspekte:

  • ontwerp
  • BGP instellings
  • DOS/DDOS-beskerming
  • verkeersfiltrering op die firewall

Design

As 'n voorbeeld van die ontwerp van hierdie segment vir 'n ondernemingsnetwerk, sal ek aanbeveel leierskap van Cisco binne VEILIGE modelle.

Natuurlik sal die oplossing van ander verskaffers dalk vir jou aantrekliker lyk (sien. Gartner Kwadrant 2018), maar sonder om jou aan te moedig om hierdie ontwerp in detail te volg, vind ek dit steeds nuttig om die beginsels en idees daaragter te verstaan.

opmerking

In SAFE is die "Remote Access"-segment deel van die "Internet Access"-segment. Maar in hierdie reeks artikels sal ons dit afsonderlik oorweeg.

Die standaard stel toerusting in hierdie segment vir 'n onderneming netwerk is

  • grens routers
  • brandmure

Opmerking 1

In hierdie reeks artikels, as ek oor firewalls praat, bedoel ek NGFW.

Opmerking 2

Ek laat oorweging van verskeie soorte L2/L1 of oorlê L2 oor L3-oplossings wat nodig is om L1/L2-konnektiwiteit te verseker, weg en beperk myself net tot kwessies op die L3-vlak en hoër. Gedeeltelik is T1/T2-kwessies in die hoofstuk bespreek "Skoonmaak en Dokumentasie«.

As jy nie 'n firewall in hierdie segment gevind het nie, moet jy nie haastig maak om gevolgtrekkings te maak nie.

Kom ons doen dieselfde as in vorige deelKom ons begin met die vraag: is dit in jou geval nodig om 'n firewall in hierdie segment te gebruik?

Ek kan sê dat dit blykbaar die mees geregverdigde plek is om firewalls te gebruik en komplekse verkeersfilteralgoritmes toe te pas. IN deel 1 Ons het 4 faktore genoem wat kan inmeng met die gebruik van firewalls in die datasentrumsegment. Maar hier is hulle nie meer so betekenisvol nie.

Voorbeeld 1. Vertraag

Wat die internet betref, is daar geen sin om van vertragings van selfs sowat 1 millisekonde te praat nie. Daarom kan die vertraging in hierdie segment nie 'n faktor wees wat die gebruik van die firewall beperk nie.

Voorbeeld 2. produktiwiteit

In sommige gevalle kan hierdie faktor steeds beduidend wees. Daarom moet jy dalk sekere verkeer (byvoorbeeld verkeer van lasbalanseerders) toelaat om die brandmuur te omseil.

Voorbeeld 3. Betroubaarheid

Hierdie faktor moet nog in ag geneem word, maar steeds, gegewe die onbetroubaarheid van die internet self, is die belangrikheid daarvan vir hierdie segment nie so belangrik soos vir die datasentrum nie.

Dus, kom ons neem aan dat jou diens bo-op http/https leef (met kort sessies). In hierdie geval kan jy twee onafhanklike bokse (sonder HA) gebruik en as daar 'n roeteprobleem met een van hulle is, dra alle verkeer oor na die tweede.

Of jy kan firewalls in deursigtige modus gebruik en, as hulle misluk, verkeer toelaat om die firewall te omseil terwyl die probleem opgelos word.

Daarom, heel waarskynlik net die prys kan die faktor wees wat jou sal dwing om die gebruik van firewalls in hierdie segment te laat vaar.

Belangrik!

Daar is 'n versoeking om hierdie firewall met die datasentrum-firewall te kombineer (gebruik een firewall vir hierdie segmente). Die oplossing is in beginsel moontlik, maar jy moet dit verstaan ​​omdat 'n Internettoegang-firewall is eintlik aan die voorpunt van jou verdediging en "vat" ten minste sommige van die kwaadwillige verkeer aan, dan moet jy natuurlik die verhoogde risiko dat hierdie firewall gedeaktiveer sal word, in ag neem. Dit wil sê, deur dieselfde toestelle in hierdie twee segmente te gebruik, sal jy die beskikbaarheid van jou datasentrumsegment aansienlik verminder.

Soos altyd moet u verstaan ​​dat die ontwerp van hierdie segment, afhangende van die diens wat die maatskappy lewer, baie kan verskil. Soos altyd, kan jy verskillende benaderings kies, afhangende van jou vereistes.

Voorbeeld

As jy 'n inhoudverskaffer is, met 'n CDN-netwerk (sien bv. reeks artikels), dan wil jy dalk nie infrastruktuur oor dosyne of selfs honderde teenwoordigheidspunte skep deur afsonderlike toestelle te gebruik om verkeer te stuur en te filter nie. Dit sal duur wees, en dit kan eenvoudig onnodig wees.

Vir BGP hoef jy nie noodwendig toegewyde routers te hê nie, jy kan oopbronnutsgoed soos kwagga. So miskien is al wat jy nodig het 'n bediener of verskeie bedieners, 'n skakelaar en BGP.

In hierdie geval kan jou bediener of verskeie bedieners die rol van nie net 'n CDN-bediener speel nie, maar ook 'n router. Natuurlik is daar nog baie besonderhede (soos hoe om balansering te verseker), maar dit is uitvoerbaar, en dit is 'n benadering wat ons suksesvol vir een van ons vennote gebruik het.

Jy kan verskeie datasentrums hê met volle beskerming (brandmure, DDOS-beskermingsdienste wat deur jou internetverskaffers verskaf word) en dosyne of honderde “vereenvoudigde” teenwoordigheidspunte met slegs L2-skakelaars en bedieners.

Maar wat van die beskerming in hierdie geval?

Kom ons kyk byvoorbeeld na die onlangs gewilde DNS-versterking DDOS-aanval. Die gevaar daarvan lê in die feit dat 'n groot hoeveelheid verkeer gegenereer word, wat eenvoudig 100% van al jou opskakels "verstop".

Wat het ons in die geval van ons ontwerp.

  • as jy AnyCast gebruik, dan word die verkeer tussen jou punte van teenwoordigheid versprei. As jou totale bandwydte terabit is, dan beskerm dit op sigself eintlik (daar was egter onlangs verskeie aanvalle met kwaadwillige verkeer in die orde van terabits) jou teen "oorloop" opskakels
  • As sommige opskakels egter verstop raak, verwyder jy eenvoudig hierdie webwerf uit diens (hou op om die voorvoegsel te adverteer)
  • jy kan ook die deel van die verkeer wat vanaf jou "volle" (en gevolglik beskermde) datasentrums gestuur word, verhoog, en sodoende 'n beduidende deel van kwaadwillige verkeer van onbeskermde teenwoordigheidspunte verwyder

En nog 'n klein nota oor hierdie voorbeeld. As jy genoeg verkeer deur IX'e stuur, verminder dit ook jou kwesbaarheid vir sulke aanvalle

Die opstel van BGP

Daar is twee onderwerpe hier.

  • Konnektiwiteit
  • Die opstel van BGP

Ons het reeds 'n bietjie oor konnektiwiteit in deel 1. Die punt is om te verseker dat verkeer na jou kliënte die optimale pad volg. Alhoewel optimaliteit nie altyd net oor latensie gaan nie, is lae latensie gewoonlik die hoofaanwyser van optimaliteit. Vir sommige maatskappye is dit belangriker, vir ander is dit minder. Dit hang alles af van die diens wat u lewer.

Voorbeeld 1

As jy 'n uitruil is, en tydintervalle van minder as millisekondes is belangrik vir jou kliënte, dan kan daar natuurlik glad nie sprake wees van enige soort internet nie.

Voorbeeld 2

As jy 'n speletjiemaatskappy is en tientalle millisekondes vir jou belangrik is, dan is konnektiwiteit natuurlik vir jou baie belangrik.

Voorbeeld 3

U moet ook verstaan ​​dat, as gevolg van die eienskappe van die TCP-protokol, die data-oordragtempo binne een TCP-sessie ook afhang van RTT (Round Trip Time). CDN-netwerke word ook gebou om hierdie probleem op te los deur inhoudverspreidingsbedieners nader aan die verbruiker van hierdie inhoud te skuif.

Die studie van konnektiwiteit is 'n interessante onderwerp op sy eie, waardig van sy eie artikel of reeks artikels, en vereis 'n goeie begrip van hoe die internet "werk".

Nuttige hulpbronne:

ryp.net
bgp.he.net

Voorbeeld

Ek gee net een klein voorbeeld.

Kom ons neem aan dat jou datasentrum in Moskou geleë is, en jy het 'n enkele opskakel - Rostelecom (AS12389). In hierdie geval (enkelhuis) het jy nie BGP nodig nie, en jy gebruik heel waarskynlik die adrespoel van Rostelecom as publieke adresse.

Kom ons neem aan dat jy 'n sekere diens lewer, en jy het 'n voldoende aantal kliënte uit die Oekraïne, en hulle kla oor lang vertragings. Tydens jou navorsing het jy uitgevind dat die IP-adresse van sommige van hulle in die 37.52.0.0/21-rooster is.

Deur 'n traceroute te hardloop, het jy gesien dat die verkeer deur AS1299 (Telia) gaan, en deur 'n ping te hardloop, het jy 'n gemiddelde RTT van 70 - 80 millisekondes gekry. Jy kan dit ook sien by kykglas Rostelecom.

Deur die whois-nutsprogram (op ripe.net of 'n plaaslike nutsprogram) te gebruik, kan jy maklik bepaal dat blok 37.52.0.0/21 aan AS6849 (Ukrtelecom) behoort.

Volgende, deur te gaan na bgp.he.net jy sien dat AS6849 geen verhouding met AS12389 het nie (hulle is nie kliënte of skakels na mekaar nie, en het ook nie peering nie). Maar as jy kyk na lys van eweknieë vir AS6849, sal jy byvoorbeeld AS29226 (Mastertel) en AS31133 (Megafon) sien.

Sodra jy die kykglas van hierdie verskaffers gevind het, kan jy die pad en RTT vergelyk. Byvoorbeeld, vir Mastertel sal RTT ongeveer 30 millisekondes wees.

Dus, as die verskil tussen 80 en 30 millisekondes betekenisvol is vir jou diens, moet jy dalk aan konnektiwiteit dink, jou AS-nommer, jou adrespoel van RIPE kry en bykomende opskakels koppel en/of teenwoordigheidspunte op IX'e skep.

Wanneer jy BGP gebruik, het jy nie net die geleentheid om konneksie te verbeter nie, maar jy behou ook jou internetverbinding oorbodig.

Hierdie dokument bevat aanbevelings vir die opstel van BGP. Ten spyte van die feit dat hierdie aanbevelings ontwikkel is op grond van die "beste praktyk" van verskaffers, is dit nietemin (as jou BGP-instellings nie heeltemal basies is nie) ongetwyfeld nuttig en behoort in werklikheid deel te wees van die verharding wat ons bespreek het in die eerste deel.

DOS/DDOS-beskerming

Nou het DOS/DDOS-aanvalle 'n alledaagse werklikheid geword vir baie maatskappye. Trouens, jy word baie dikwels in een of ander vorm aangeval. Die feit dat jy dit nog nie opgemerk het nie, beteken net dat 'n geteikende aanval nog nie teen jou georganiseer is nie, en dat die beskermingsinstrumente wat jy gebruik, selfs dalk sonder dat jy dit weet (verskeie ingeboude beskermings van bedryfstelsels), voldoende is om verseker dat agteruitgang van die diens wat gelewer word vir jou en jou kliënte tot die minimum beperk word.

Daar is internetbronne wat, gebaseer op toerustinglogboeke, pragtige aanvalskaarte in reële tyd teken.

Hier jy kan skakels na hulle vind.

My gunsteling kaart vanaf CheckPoint.

Beskerming teen DDOS/DOS is gewoonlik gelaagde. Om te verstaan ​​hoekom, moet jy verstaan ​​watter tipe DOS/DDOS-aanvalle bestaan ​​(sien bv. hier of hier)

Dit wil sê, ons het drie tipes aanvalle:

  • volumetriese aanvalle
  • protokol aanvalle
  • toepassing aanvalle

As jy jouself kan beskerm teen die laaste twee tipes aanvalle deur byvoorbeeld firewalls te gebruik, dan kan jy nie jouself beskerm teen aanvalle wat daarop gemik is om jou opskakels te “oorweldig” nie (natuurlik, as jou totale kapasiteit van internetkanale nie in terabit bereken word nie, of beter nog, in tien terabit).

Daarom is die eerste verdedigingslinie beskerming teen “volumetriese” aanvalle, en jou verskaffer of verskaffers moet hierdie beskerming aan jou verskaf. As jy dit nog nie besef het nie, dan is jy vir eers net gelukkig.

Voorbeeld

Kom ons sê jy het verskeie opskakels, maar net een van die verskaffers kan jou hierdie beskerming bied. Maar as alle verkeer deur een verskaffer gaan, wat dan van die verbinding wat ons 'n bietjie vroeër kortliks bespreek het?

In hierdie geval sal u konnektiwiteit gedeeltelik tydens die aanval moet opoffer. Maar

  • dit is slegs vir die duur van die aanval. In die geval van 'n aanval, kan jy BGP handmatig of outomaties herkonfigureer sodat verkeer slegs deur die verskaffer gaan wat jou van die "sambreel" voorsien. Nadat die aanval verby is, kan jy die roete na sy vorige toestand terugstuur
  • Dit is nie nodig om alle verkeer oor te dra nie. As jy byvoorbeeld sien dat daar geen aanvalle deur sommige opskakels of peerings is nie (of die verkeer is nie beduidend nie), kan jy voortgaan om voorvoegsels met mededingende eienskappe teenoor hierdie BGP-bure te adverteer.

U kan ook beskerming teen "protokolaanvalle" en "toepassingsaanvalle" aan u vennote delegeer.
Hier hier jy kan 'n goeie studie lees (vertaling). Die artikel is weliswaar twee jaar oud, maar dit sal jou 'n idee gee van die benaderings oor hoe jy jouself teen DDOS-aanvalle kan beskerm.

In beginsel kan jy jouself hiertoe beperk en jou beskerming heeltemal uitkontrakteer. Daar is voordele aan hierdie besluit, maar daar is ook 'n ooglopende nadeel. Die feit is dat ons kan praat (weereens, afhangend van wat jou maatskappy doen) oor die voortbestaan ​​van die besigheid. En vertrou sulke goed aan derde partye...

Kom ons kyk dus na hoe om die tweede en derde verdedigingslinie te organiseer (as 'n toevoeging tot die beskerming van die verskaffer).

Dus, die tweede verdedigingslinie is filtering en verkeersbeperkers (polisiers) by die ingang van jou netwerk.

Voorbeeld 1

Kom ons neem aan dat jy jouself met 'n sambreel teen DDOS bedek het met die hulp van een van die verskaffers. Kom ons neem aan dat hierdie verskaffer Arbor gebruik om verkeer en filters aan die rand van sy netwerk te filter.

Die bandwydte wat Arbor kan “verwerk” is beperk, en die verskaffer kan natuurlik nie voortdurend die verkeer van al sy vennote wat hierdie diens bestel deur filtertoerusting, deurlaat nie. Onder normale toestande word verkeer dus nie gefiltreer nie.

Kom ons neem aan daar is 'n SYN-vloedaanval. Selfs as jy 'n diens bestel het wat verkeer outomaties oorskakel na filter in die geval van 'n aanval, gebeur dit nie onmiddellik nie. Vir 'n minuut of langer bly jy onder aanval. En dit kan lei tot mislukking van jou toerusting of verswakking van die diens. In hierdie geval sal die beperking van verkeer by die randroetering, alhoewel dit daartoe sal lei dat sommige TCP-sessies nie gedurende hierdie tyd tot stand gebring sal word nie, u infrastruktuur van groterskaalse probleme red.

Voorbeeld 2

'n Abnormaal groot aantal SYN-pakkies is dalk nie net die gevolg van 'n SYN-vloedaanval nie. Kom ons neem aan dat u 'n diens lewer waarin u gelyktydig ongeveer 100 duisend TCP-verbindings (na een datasentrum) kan hê.

Kom ons sê as gevolg van 'n korttermynprobleem met een van jou hoofverskaffers, word die helfte van jou sessies afgeskop. As jou toepassing so ontwerp is dat dit, sonder om twee keer te dink, dit onmiddellik (of na 'n tydsinterval wat dieselfde is vir alle sessies) probeer om die verbinding te herstel, dan sal jy minstens 50 duisend SYN-pakkies ontvang gelyktydig.

As jy byvoorbeeld ssl/tls-handdruk bo-op hierdie sessies moet laat loop, wat die uitruil van sertifikate behels, dan sal dit uit die oogpunt van die uitputting van hulpbronne vir jou load balancer 'n baie sterker "DDOS" wees as 'n eenvoudige SYN vloed. Dit wil voorkom asof balanseerders sulke gebeure moet hanteer, maar... ongelukkig sit ons met so 'n probleem.

En natuurlik sal 'n polisiebeampte op die randroeteerder jou toerusting ook in hierdie geval red.

Die derde vlak van beskerming teen DDOS/DOS is jou firewall-instellings.

Hier kan jy beide aanvalle van die tweede en derde tipe stop. Oor die algemeen kan alles wat die firewall bereik hier gefiltreer word.

Advies

Probeer om die firewall so min as moontlik werk te gee, en filter soveel as moontlik op die eerste twee verdedigingslyne. En dit is hoekom.

Het dit al ooit met jou gebeur dat jy toevallig, terwyl jy verkeer genereer om byvoorbeeld te kyk hoe bestand die bedryfstelsel van jou bedieners teen DDOS-aanvalle is, jy jou firewall “gedood” het, dit tot 100 persent gelaai het, met verkeer teen normale intensiteit ? Indien nie, is dit dalk bloot omdat jy nie probeer het nie?

Oor die algemeen is 'n firewall, soos ek gesê het, 'n komplekse ding, en dit werk goed met bekende kwesbaarhede en beproefde oplossings, maar as jy iets ongewoons stuur, net 'n paar vullis of pakkies met verkeerde opskrifte, dan is jy met sommige, nie Met so 'n klein waarskynlikheid (gebaseer op my ervaring), kan jy selfs top-end toerusting bedwelm. Daarom, op stadium 2, deur gebruik te maak van gereelde ACL's (op die L3/L4-vlak), laat slegs verkeer in jou netwerk toe wat daar moet ingaan.

Filtreer verkeer op die firewall

Kom ons gaan voort met die gesprek oor die firewall. U moet verstaan ​​dat DOS/DDOS-aanvalle net een tipe kuberaanval is.

Benewens DOS/DDOS-beskerming, kan ons ook iets soos die volgende lys kenmerke hê:

  • aansoek firewalling
  • bedreigingsvoorkoming (antivirus, anti-spioenware en kwesbaarheid)
  • URL-filter
  • datafiltrering (inhoudfiltrering)
  • lêer blokkering (lêer tipes blokkering)

Dit is aan jou om uit hierdie lys te besluit wat jy nodig het.

Voortgesit moet word

Bron: will.com

Voeg 'n opmerking