Artikulu hau "Nola hartu zure sareko azpiegituraren kontrola" serieko laugarrena da. Serieko artikulu guztien edukia eta estekak aurki daitezke Hemen.

В Lehenengo zatia Kapitulu honetan, datu-zentroko sareko segurtasunaren alderdi batzuk aztertu ditugu. Atal hau "Interneterako sarbidea" segmentuari eskainiko zaio.

Internet sarbidea

Segurtasunaren gaia datu-sareen munduko gairik konplexuenetako bat da, zalantzarik gabe. Aurreko kasuetan bezala, sakontasuna eta osotasuna aldarrikatu gabe, nahiko sinpleak aztertuko ditut hemen, baina, nire ustez, galdera garrantzitsuak, zeinen erantzunak, espero dut, zure sarearen segurtasun maila igotzen lagunduko dutela.

Segmentu hau ikuskatzean, arreta jarri alderdi hauei:

• diseinua
• BGP ezarpenak
• DOS/DDOS babesa
• trafikoaren iragazketa suebakian

Diseinua

Segmentu honen diseinuaren adibide gisa enpresa-sare baterako, gomendatuko nuke lidergoa Ciscoren barruan SEGURU ereduak.

Jakina, agian beste saltzaileen irtenbidea erakargarriagoa irudituko zaizu (ikus. Gartner Quadrant 2018), baina diseinu hau zehatz-mehatz jarraitzera animatu gabe, atzean dauden printzipioak eta ideiak ulertzeko baliagarria iruditzen zait oraindik.

komentarioen

SAFE-n, "Urrutiko sarbidea" segmentua "Interneterako sarbidea" segmentuaren parte da. Baina artikulu sorta honetan bereizita aztertuko dugu.

Enpresa-sare baterako segmentu honetako ekipamendu-multzo estandarra da

• mugako bideratzaileak
• suebakiak

1. oharra

Artikulu sorta honetan, suebakiei buruz hitz egiten dudanean, esan nahi dut NGFW.

2. oharra

L2/L1 mota desberdinak kontuan hartzea baztertzen dut edo L2/L3 konektibitatea ziurtatzeko beharrezkoak diren L1 L2 gainjartzen ditut L3/L1 konektibitatea bermatzeko eta L2 maila eta goragoko gaietara soilik mugatzen naiz. Partzialki, LXNUMX/LXNUMX gaiak eztabaidatu ziren " kapituluanGarbiketa eta Dokumentazioa".

Segmentu honetan suebakirik aurkitu ez baduzu, ez duzu ondoriorik atera behar.

Egin dezagun berdina aurreko zatiaHas gaitezen galderarekin: beharrezkoa al da segmentu honetan suebaki bat erabiltzea zure kasuan?

Esan dezaket hori dela leku justifikatuena suebakiak erabiltzeko eta trafikoa iragazteko algoritmo konplexuak aplikatzeko. IN 1 piezak Datu zentroen segmentuan suebakien erabilera oztopatu dezaketen 4 faktore aipatu ditugu. Baina hemen jada ez dira hain esanguratsuak.

Adibidea 1. atzerapenik

Interneti dagokionez, milisegundo bateko atzerapenez hitz egiteak ez du balio. Beraz, segmentu honen atzerapena ezin da izan suebakiaren erabilera mugatzen duen faktore bat.

Adibidea 2. produktibitatea

Zenbait kasutan faktore hau oraindik esanguratsua izan daiteke. Hori dela eta, baliteke trafiko batzuk (adibidez, karga-orekatzaileen trafikoa) suebakia saihesteko baimena eman behar izatea.

Adibidea 3. Fidagarritasuna

Faktore hori oraindik kontuan hartu behar da, baina hala ere, Interneten beraren fidagarritasuna kontuan hartuta, segmentu honetarako duen garrantzia ez da datu-zentroarentzat bezain esanguratsua.

Beraz, demagun zure zerbitzua http/https-ren gainean bizi dela (saio laburrekin). Kasu honetan, bi kutxa independente erabil ditzakezu (HA gabe) eta horietako batekin bideratze-arazoren bat badago, trafiko guztia bigarrenera transferitu.

Edo suebakiak modu gardenean erabil ditzakezu eta, huts egiten badute, trafikoari suebakia saihesteko baimena eman arazoa konpontzen den bitartean.

Hori dela eta, ziurrenik besterik ez prezioa izan daiteke segmentu honetan suebakien erabilera alde batera utztzera behartuko zaituen faktorea.

Garrantzitsua da!

Suebaki hau datu-zentroko suebakiarekin konbinatzeko tentazioa dago (erabili suebaki bat segmentu hauetarako). Irtenbidea, printzipioz, posible da, baina hori ulertu behar duzu zeren Interneterako sarbidearen suebaki bat zure defentsan abangoardian dago eta trafiko gaiztoaren zati bat gutxienez "hartzen" du; orduan, noski, kontutan izan behar duzu suebaki hau desgaitzeko arrisku handiagoa dela. Hau da, bi segmentu hauetan gailu berdinak erabiliz, zure datu-zentroko segmentuaren erabilgarritasuna nabarmen murriztuko duzu.

Beti bezala, ulertu behar duzu konpainiak eskaintzen duen zerbitzuaren arabera, segmentu honen diseinua asko alda daitekeela. Beti bezala, planteamendu desberdinak aukeratu ditzakezu zure eskakizunen arabera.

Adibidea

Eduki hornitzailea bazara, CDN sare batekin (ikus, adibidez, artikulu sorta), orduan agian ez duzu azpiegiturarik sortu nahi dozenaka edo ehunka presentzia puntutan trafikoa bideratzeko eta iragazteko gailu bereiziak erabiliz. Garestia izango da, eta agian alferrikakoa izango da.

BGPrako ez duzu zertan bideratzaile dedikatuak izan behar, kode irekiko tresnak erabil ditzakezu Quagga. Beraz, beharbada zerbitzari bat edo hainbat zerbitzari, switch bat eta BGP da behar duzun guztia.

Kasu honetan, zure zerbitzariak edo hainbat zerbitzariek CDN zerbitzari baten eginkizuna ez ezik, bideratzaile batena ere izan dezakete. Jakina, oraindik xehetasun asko daude (esaterako, oreka nola bermatu), baina egingarria da, eta gure bazkideetako batek arrakastaz erabili dugun ikuspegia da.

Babes osoa duten hainbat datu-zentro izan ditzakezu (suebakiak, zure Interneteko hornitzaileek emandako DDOS babes zerbitzuak) eta dozenaka edo ehunka presentzia "sinplifikatu" puntu L2 etengailu eta zerbitzariekin soilik.

Baina zer gertatzen da kasu honetan babesarekin?

Ikus ditzagun, adibidez, duela gutxi ezagunak DNS Anplifikazioa DDOS erasoa. Bere arriskua trafiko-kopuru handia sortzean datza, eta horrek zure esteka guztien % 100 "blokeatzen" besterik ez du.

Zer daukagu ​​gure diseinuaren kasuan.

• AnyCast erabiltzen baduzu, trafikoa zure presentzia puntuen artean banatuko da. Zure banda-zabalera osoa terabit-a bada, horrek berez (hala ere, duela gutxi terabit-en ordenako trafiko gaiztoekin hainbat eraso izan dira) goranzko esteketatik babesten zaitu.
• Hala ere, gorako esteka batzuk trabatu egiten badira, gune hau zerbitzutik kendu besterik ez duzu (utzi aurrizkia iragartzeari)
• zure datu-zentro "osoetatik" (eta, horren ondorioz, babestutakoak) bidalitako trafikoaren zatia ere handi dezakezu, horrela babestu gabeko presentzia-puntuetatik trafiko gaiztoaren zati garrantzitsu bat kenduz.

Eta beste ohar txiki bat adibide honi. IX-en bidez trafiko nahikoa bidaltzen baduzu, honek eraso horien aurrean ahultasuna ere murrizten du

BGP konfiguratzen

Bi gai daude hemen.

• Konektibitatea
• BGP konfiguratzen

Konektagarritasunari buruz hitz egin dugu dagoeneko 1 piezak. Kontua da zure bezeroentzako trafikoak bide optimoa jarraitzen duela ziurtatzea. Optimutasuna beti latentzia soilik ez den arren, latentzia baxua izan ohi da optimotasunaren adierazle nagusia. Enpresa batzuentzat hori garrantzitsuagoa da, beste batzuentzat gutxiago. Guztia ematen duzun zerbitzuaren araberakoa da.

Adibidez 1

Trukea bazara, eta milisegundo baino gutxiagoko denbora tarteak garrantzitsuak badira zure bezeroentzat, orduan, noski, ezin da inolako Internetez hitz egin.

Adibidez 2

Joko-enpresa bat bazara eta hamar milisegundo garrantzitsuak badira zuretzat, orduan, noski, konektibitatea oso garrantzitsua da zuretzat.

Adibidez 3

Gainera, ulertu behar duzu, TCP protokoloaren propietateak direla eta, TCP saio bateko datu-transferentzia-tasa ere RTT (Itzulitako Denbora) araberakoa dela. Arazo hau konpontzeko CDN sareak ere eraikitzen ari dira, edukia banatzeko zerbitzariak eduki horien kontsumitzaileengana hurbilduz.

Konektibitatearen azterketa gai interesgarria da berez, bere artikulu edo artikulu sorta bat merezi duena, eta Internetek nola "funtzionatzen duen" ondo ulertzea eskatzen du.

Baliabide erabilgarriak:

heldua.net
bgp.he.net

Adibidea

Adibide txiki bat jarriko dut.

Demagun zure datu-zentroa Moskun dagoela eta gorako lotura bakarra duzula - Rostelecom (AS12389). Kasu honetan (etxebizitza bakarrekoa) ez duzu BGPrik behar, eta ziurrenik Rostelecom-en helbide multzoa helbide publiko gisa erabiliko duzu.

Demagun zerbitzu jakin bat ematen duzula, eta Ukrainako bezero kopuru nahikoa duzula, eta atzerapen luzeengatik kexatzen dira. Ikerketan zehar, jakin duzu horietako batzuen IP helbideak 37.52.0.0/21 sarean daudela.

Traceroute bat exekutatuta, trafikoa AS1299tik (Telia) pasatzen ari zela ikusi zenuen, eta ping bat abiaraziz, 70 - 80 milisegundoko batez besteko RTT bat lortu zenuen. Hemen ere ikus dezakezu Begirada Rostelecom.

Whois utilitatea erabiliz (ripe.net-en edo tokiko erabilgarritasun batean), erraz zehaztu dezakezu 37.52.0.0/21 blokea AS6849 (Ukrtelecom) dela.

Jarraian, bertara joanez bgp.he.net ikusten duzu AS6849-k ez duela harremanik AS12389-rekin (ez dira ez bezeroak, ez elkarren arteko gorako loturak, ezta peering-a ere). Baina begiratuz gero parekideen zerrenda AS6849rako, adibidez, AS29226 (Mastertel) eta AS31133 (Megafon) ikusiko dituzu.

Hornitzaile horien ispilua aurkitu ondoren, bidea eta RTT aldera ditzakezu. Adibidez, Mastertel-entzat RTT 30 milisegundo ingurukoa izango da.

Beraz, 80 eta 30 milisegundoen arteko aldea nabarmena bada zure zerbitzurako, agian konektibitatean pentsatu behar duzu, zure AS zenbakia, zure helbide biltegia RIPE-tik lortu eta gorako esteka gehigarriak konektatu eta/edo presentzia puntuak sortu IXetan.

BGP erabiltzen duzunean, konektagarritasuna hobetzeko aukera ez ezik, Interneterako konexioa modu erredundantean mantentzen duzu.

Dokumentu hau BGP konfiguratzeko gomendioak ditu. Gomendio hauek hornitzaileen "praktika onen"etan oinarrituta garatu diren arren, oraindik (zure BGP ezarpenak oso oinarrizkoak ez badira) erabilgarriak dira, dudarik gabe, eta, hain zuzen ere, eztabaidatu dugun gogorketaren parte izan beharko lukete. Lehenengo zatia.

DOS/DDOS babesa

Orain DOS/DDOS erasoak eguneroko errealitate bihurtu dira enpresa askorentzat. Izan ere, sarritan erasotzen zaituzte era batean edo bestean. Honetaz oraindik ohartu ez izanak esan nahi du oraindik ez dela zure aurka zuzendutako erasorik antolatu, eta erabiltzen dituzun babes-neurriek, agian jakin gabe ere (sistema eragileen hainbat babes barne), nahikoak direla. ziurtatu zure eta zure bezeroentzako emandako zerbitzuaren degradazioa minimizatzen dela.

Badira Interneteko baliabideak, ekipoen erregistroetan oinarrituta, eraso-mapa ederrak marrazten dituztenak denbora errealean.

Hemen haietarako estekak aurki ditzakezu.

Nire gogokoena mapa CheckPoint-etik.

DDOS/DOS-en aurkako babesa geruzetan egon ohi da. Zergatik ulertzeko, zer DOS/DDOS eraso mota dauden ulertu behar duzu (ikus, adibidez, Hemen edo Hemen)

Hau da, hiru eraso mota ditugu:

• eraso bolumetrikoak
• protokolo erasoak
• aplikazioen erasoak

Azken bi eraso-motetatik babestu ahal baduzu, adibidez, suebakiak erabiliz, orduan ezin duzu zure gorako estekak "gainditzea" helburu duten erasoetatik babestu (noski, Interneteko kanalen guztizko ahalmena terabitetan kalkulatzen ez bada, edo hobeto esanda, hamar terabitetan).

Hori dela eta, lehen defentsa-lerroa eraso "bolumetrikoen" aurkako babesa da, eta zure hornitzaileak edo hornitzaileek babes hori eman behar dizute. Oraindik ez bazara honetaz konturatu, orduan zortea besterik ez duzu oraingoz.

Adibidea

Demagun goranzko hainbat esteka dituzula, baina hornitzaileetako batek bakarrik eman diezazuke babes hori. Baina trafiko guztia hornitzaile batetik igarotzen bada, zer gertatzen da lehenago laburki eztabaidatu dugun konektibitateaz?

Kasu honetan, konexioa neurri batean sakrifikatu beharko duzu erasoan zehar. Baina

• hau erasoak irauten duen bitartean bakarrik da. Erasoren bat gertatuz gero, eskuz edo automatikoki birkonfigura dezakezu BGP, trafikoa "aterkia" ematen dizun hornitzailetik soilik igaro dadin. Erasoa amaitu ondoren, bideraketa aurreko egoerara itzul dezakezu
• Ez da beharrezkoa trafiko guztia transferitzea. Esaterako, goranzko lotura edo peering batzuen bidez erasorik ez dagoela ikusten baduzu (edo trafikoa ez da esanguratsua), BGP auzokide horiei lehiakortasun-atributuak dituzten aurrizkiak iragartzen jarrai dezakezu.

"Protokolo-erasoetatik" eta "aplikazio-erasoetatik" babesa ere delega diezaiekezu zure bazkideei.
Hemen Hemen azterketa on bat irakur dezakezu (itzulpen). Egia esan, artikuluak bi urte ditu, baina DDOS erasoetatik babestu dezakezun planteamenduen ideia bat emango dizu.

Printzipioz, horretara muga zaitezke, zure babesa guztiz azpikontratatuz. Erabaki honek abantailak ditu, baina desabantaila nabaria ere bada. Kontua da (berriro, zure enpresak egiten duenaren arabera) hitz egin dezakegula negozioaren biziraupenaz. Eta fidatu horrelako gauzak hirugarrenei...

Beraz, ikus dezagun nola antolatu bigarren eta hirugarren defentsa-lerroak (hornitzailearen babeserako gehigarri gisa).

Beraz, bigarren defentsa-lerroa zure sarearen sarreran iragaztea eta trafiko-mugatzaileak (poliziak) dira.

Adibidez 1

Demagun hornitzaileetako baten laguntzarekin DDOSen aurkako aterki batekin estali duzula. Demagun hornitzaile honek Arbor erabiltzen duela trafikoa eta iragazkiak bere sarearen ertzean iragazteko.

Arbor-ek "prozesatu" dezakeen banda-zabalera mugatua da, eta hornitzaileak, noski, ezin du etengabe zerbitzu hau agintzen duten bazkide guztien trafikoa iragazteko ekipoen bidez pasa. Horregatik, baldintza normaletan, trafikoa ez da iragazten.

Demagun SYN uholde-eraso bat dagoela. Eraso bat gertatuz gero trafikoa iragazkira automatikoki aldatzen duen zerbitzu bat eskatu baduzu ere, hori ez da berehala gertatzen. Minutu bat edo gehiago erasopean jarraitzen duzu. Eta horrek zure ekipamenduaren hutsegitea edo zerbitzua hondatzea ekar dezake. Kasu honetan, trafikoa ertzeko bideratzean mugatzeak, nahiz eta denbora horretan TCP saio batzuk ezarriko ez diren, zure azpiegitura eskala handiagoko arazoetatik salbatuko du.

Adibidez 2

Baliteke SYN pakete kopuru handi bat ez izatea SYN flod eraso baten ondorioa soilik. Demagun zerbitzu bat eskaintzen duzula eta aldi berean 100 mila TCP konexio inguru izan ditzakezula (datu zentro batera).

Demagun zure hornitzaile nagusietako batekin epe laburreko arazo baten ondorioz, zure saioen erdiak bota egiten direla. Zure aplikazioa honela diseinatuta badago, bi aldiz pentsatu gabe, berehala (edo saio guztietan berdina den denbora tarte baten ondoren) konexioa berrezartzen saiatzen bada, orduan gutxienez 50 mila SYN pakete jasoko dituzu gutxi gorabehera. aldi berean.

Adibidez, ssl/tls handshake exekutatu behar baduzu saio hauen gainean, ziurtagiriak trukatzea dakar, orduan zure karga-orekatzailearen baliabideak agortzearen ikuspuntutik, hau "DDOS" sinple bat baino askoz indartsuagoa izango da. SYN uholdea. Badirudi balantzatzaileek horrelako gertaerak kudeatu behar dituztela, baina... zoritxarrez, horrelako arazo baten aurrean gaude.

Eta, noski, ertzeko bideratzaileko polizia batek zure ekipoak gordeko ditu kasu honetan ere.

DDOS/DOSen aurkako hirugarren babes-maila zure suebakiaren ezarpenak dira.

Hemen bigarren eta hirugarren motako erasoak geldi ditzakezu. Oro har, suebakira iristen den guztia hemen iragazi daiteke.

Aldundiak

Saiatu suebakiari ahalik eta lan gutxien ematen, lehen bi defentsa-lerroetan ahalik eta gehien iragazten. Eta horregatik.

Inoiz gertatu zaizu kasualitatez, zure zerbitzarietako sistema eragileak DDOS erasoekiko nola erresistentea den egiaztatzeko trafikoa sortzen duzun bitartean, zure suebakia "hil" duzula, ehuneko 100ean kargatuz, trafikoa intentsitate normalarekin. ? Hala ez bada, agian probatu ez zarelako izango da?

Oro har, suebaki bat, esan bezala, gauza konplexua da, eta ondo funtzionatzen du ahultasun ezagunekin eta probatutako soluzioekin, baina ezohiko zerbait bidaltzen baduzu, zabor batzuk edo goiburu okerrak dituzten pakete batzuk besterik ez, orduan batzuekin zaude, ez Honekin. halako probabilitate txikia (nire esperientzian oinarrituta), goi-mailako ekipoak ere harritu ditzakezu. Hori dela eta, 2. fasean, ACL arruntak erabiliz (L3/L4 mailan), bertan sartu behar den trafikoa soilik baimendu zure sarera.

Suebakian trafikoa iragaztea

Jarrai dezagun suebakiari buruzko elkarrizketarekin. Ulertu behar duzu DOS/DDOS erasoak ziber-eraso mota bat besterik ez direla.

DOS/DDOS babesaz gain, funtzio zerrenda hau bezalako zerbait ere izan dezakegu:

• aplikazioen suebakia
• mehatxuen prebentzioa (birusen aurkakoa, espioiaren aurkakoa eta ahultasuna)
• URL iragaztea
• datuen iragazketa (edukiaren iragazketa)
• fitxategiak blokeatzea (fitxategi motak blokeatzea)

Zure esku dago zerrenda honetatik zer behar duzun erabakitzea.

Jarraitu ahal izateko

Iturria: www.habr.com