Ĉi tiu artikolo estas la kvara en la serio "Kiel Preni Kontrolon de Via Reta Infrastrukturo". La enhavo de ĉiuj artikoloj en la serio kaj ligiloj troveblas .
В En ĉi tiu ĉapitro, ni rigardis kelkajn aspektojn de reto-sekureco en la Datuma Centro-segmento. Ĉi tiu parto estos dediĉita al la segmento "Interreta Aliro".
interreta atingo
La temo de sekureco estas sendube unu el la plej kompleksaj temoj en la mondo de datumretoj. Kiel en antaŭaj kazoj, sen pretendi profundon kaj kompletecon, mi konsideros ĉi tie sufiĉe simplajn, sed, laŭ mi, gravajn demandojn, kies respondoj, mi esperas, helpos altigi la nivelon de sekureco de via reto.
Kiam vi revizias ĉi tiun segmenton, atentu la jenajn aspektojn:
- dezajno
- BGP-agordoj
- DOS/DDOS-protekto
- trafiko filtrado sur la fajroŝirmilo
Dezajno
Kiel ekzemplo de la dezajno de ĉi tiu segmento por entreprena reto, mi rekomendus de Cisco interne .
Kompreneble, eble la solvo de aliaj vendistoj ŝajnos al vi pli alloga (vidu. ), sed sen kuraĝigi vin sekvi ĉi tiun dezajnon detale, mi ankoraŭ trovas ĝin utila kompreni la principojn kaj ideojn malantaŭ ĝi.
Noto
En SAFE, la "Remote Access" segmento estas parto de la "Interreta Aliro" segmento. Sed en ĉi tiu serio de artikoloj ni konsideros ĝin aparte.
La norma aro de ekipaĵo en ĉi tiu segmento por entreprena reto estas
- landlimaj enkursigiloj
- fajroŝirmiloj
Rimarko 1
En ĉi tiu serio de artikoloj, kiam mi parolas pri fajroŝirmiloj, mi volas diri .
Rimarko 2
Mi preterlasas konsideron de diversaj specoj de L2/L1 aŭ supermetas L2 super L3-solvojn necesajn por certigi L1/L2-konektecon kaj limigi min nur al aferoj ĉe la L3-nivelo kaj pli. Parte, L1/L2-temoj estis diskutitaj en la ĉapitro "".
Se vi ne trovis fajroŝirmilon en ĉi tiu segmento, tiam vi ne rapidu al konkludoj.
Ni faru la samon kiel en Ni komencu per la demando: ĉu necesas uzi fajroŝirmilon en ĉi tiu segmento en via kazo?
Mi povas diri, ke ĉi tio ŝajnas esti la plej pravigita loko por uzi fajroŝirmilojn kaj apliki kompleksajn trafikajn filtrajn algoritmojn. EN Ni menciis 4-faktorojn, kiuj povas malhelpi la uzon de fajroŝirmiloj en la datumcentra segmento. Sed ĉi tie ili ne plu estas tiel signifaj.
Ekzemplo 1. Prokrasto
Koncerne la Interreton, ne utilas paroli pri prokrastoj eĉ de ĉirkaŭ 1 milisekundo. Tial, la prokrasto en ĉi tiu segmento ne povas esti faktoro limiganta la uzon de la fajroŝirmilo.
Ekzemplo 2. Produkteco
En iuj kazoj ĉi tiu faktoro ankoraŭ povas esti grava. Tial, vi eble devos permesi iom da trafiko (ekzemple, trafiko de ŝarĝbalanciloj) preteriri la fajroŝirmilon.
Ekzemplo 3. Fidindeco
Ĉi tiu faktoro ankoraŭ devas esti konsiderata, sed tamen, pro la nefidindeco de la interreto mem, ĝia graveco por ĉi tiu segmento ne estas tiel signifa kiel por la datumcentro.
Do, ni supozu, ke via servo vivas super http/https (kun mallongaj sesioj). En ĉi tiu kazo, vi povas uzi du sendependajn skatolojn (sen HA) kaj se estas problemo pri vojigo kun unu el ili, translokigu la tutan trafikon al la dua.
Aŭ vi povas uzi fajroŝirmilojn en travidebla reĝimo kaj, se ili malsukcesas, permesi al trafiko preteriri la fajroŝirmilon dum solvante la problemon.
Tial, plej verŝajne nur la prezo povas esti la faktoro, kiu devigos vin forlasi la uzon de fajroŝirmiloj en ĉi tiu segmento.
Grava!
Estas tento kombini ĉi tiun fajroŝirmilon kun la datumcentra fajroŝirmilo (uzu unu fajroŝirmilon por ĉi tiuj segmentoj). La solvo estas principe ebla, sed vi devas kompreni tion ĉar Interreta Alira fajroŝirmilo estas fakte ĉe la avangardo de via defendo kaj "akceptas" almenaŭ iom da el la malica trafiko, tiam, kompreneble, vi devas konsideri la pli grandan riskon, ke ĉi tiu fajroŝirmilo estos malŝaltita. Tio estas, uzante la samajn aparatojn en ĉi tiuj du segmentoj, vi signife reduktos la haveblecon de via datumcentra segmento.
Kiel ĉiam, vi devas kompreni, ke depende de la servo, kiun la kompanio provizas, la dezajno de ĉi tiu segmento povas multe varii. Kiel ĉiam, vi povas elekti malsamajn alirojn depende de viaj postuloj.
Ekzemplo:
Se vi estas enhavprovizanto, kun CDN-reto (vidu, ekzemple, ), tiam vi eble ne volas krei infrastrukturon tra dekoj aŭ eĉ centoj da ĉeestpunktoj uzante apartajn aparatojn por vojigi kaj filtri trafikon. Ĝi estos multekosta, kaj ĝi povas simple esti nenecesa.
Por BGP vi ne nepre devas havi dediĉitajn enkursigilojn, vi povas uzi malfermfontajn ilojn kiel . Do eble ĉio, kion vi bezonas, estas servilo aŭ pluraj serviloj, ŝaltilo kaj BGP.
En ĉi tiu kazo, via servilo aŭ pluraj serviloj povas ludi la rolon de ne nur CDN-servilo, sed ankaŭ enkursigilo. Kompreneble, estas ankoraŭ multaj detaloj (kiel ekzemple kiel certigi ekvilibron), sed ĝi estas farebla, kaj ĝi estas aliro, kiun ni sukcese uzis por unu el niaj partneroj.
Vi povas havi plurajn datumcentrojn kun plena protekto (fajroŝirmiloj, DDOS-protektservoj provizitaj de viaj interretaj provizantoj) kaj dekduojn aŭ centojn da "simpligitaj" punktoj de ĉeesto kun nur L2-ŝaltiloj kaj serviloj.
Sed kio pri la protekto en ĉi tiu kazo?
Ni rigardu, ekzemple, la lastatempe popularajn . Ĝia danĝero kuŝas en la fakto, ke granda kvanto da trafiko estas generita, kiu simple "ŝtopiĝas" 100% de ĉiuj viaj suprenligoj.
Kion ni havas en la kazo de nia dezajno.
- se vi uzas AnyCast, tiam la trafiko estas distribuita inter viaj punktoj de ĉeesto. Se via tuta bendolarĝo estas terabitoj, tiam ĉi tio en si mem fakte (tamen, lastatempe okazis pluraj atakoj kun malica trafiko en la ordo de terabitoj) protektas vin kontraŭ "superfluaj" suprenligoj.
- Se tamen iuj suprenligiloj ŝtopiĝas, tiam vi simple forigas ĉi tiun retejon de servo (ĉesu reklami la prefikson)
- vi ankaŭ povas pliigi la parton de trafiko sendita de viaj "plenaj" (kaj, sekve, protektitaj) datumcentroj, tiel forigante signifan parton de malica trafiko de neprotektitaj punktoj de ĉeesto.
Kaj unu pli malgranda noto al ĉi tiu ekzemplo. Se vi sendas sufiĉe da trafiko tra IX-oj, tiam ĉi tio ankaŭ reduktas vian vundeblecon al tiaj atakoj
Agordo de BGP
Estas du temoj ĉi tie.
- Konektebleco
- Agordo de BGP
Ni jam iomete parolis pri konektebleco en . La punkto estas certigi, ke trafiko al viaj klientoj sekvas la optimuman vojon. Kvankam optimumeco ne ĉiam temas nur pri latenteco, malalta latenco estas kutime la ĉefa indikilo de optimumo. Por iuj kompanioj tio estas pli grava, por aliaj malpli. Ĉio dependas de la servo, kiun vi provizas.
ekzemple 1
Se vi estas interŝanĝo, kaj tempointervaloj de malpli ol milisekundoj estas gravaj por viaj klientoj, tiam, kompreneble, oni tute ne povas paroli pri ia ajn Interreto.
ekzemple 2
Se vi estas videoluda kompanio kaj dekoj da milisekundoj estas gravaj por vi, tiam, kompreneble, konektebleco estas tre grava por vi.
ekzemple 3
Vi ankaŭ devas kompreni, ke pro la propraĵoj de la TCP-protokolo, la transdono de datumoj ene de unu TCP-sesio ankaŭ dependas de RTT (Round Trip Time). CDN-retoj ankaŭ estas konstruitaj por solvi ĉi tiun problemon movante enhavajn distribuservilojn pli proksime al la konsumanto de ĉi tiu enhavo.
La studo de konektebleco estas interesa temo en si mem, inda je sia propra artikolo aŭ serio de artikoloj, kaj postulas bonan komprenon pri kiel interreto "funkcias".
Utilaj rimedoj:
Ekzemplo:
Mi donos nur unu malgrandan ekzemplon.
Ni supozu, ke via datumcentro situas en Moskvo, kaj vi havas ununuran suprenligon - Rostelecom (AS12389). En ĉi tiu kazo (single homed) vi ne bezonas BGP, kaj vi plej verŝajne uzas la adresgrupon de Rostelecom kiel publikajn adresojn.
Ni supozu, ke vi provizas certan servon, kaj vi havas sufiĉan nombron da klientoj el Ukrainio, kaj ili plendas pri longaj prokrastoj. Dum via esplorado, vi eksciis, ke la IP-adresoj de iuj el ili estas en la 37.52.0.0/21 krado.
Kurante traceroute, vi vidis, ke la trafiko trapasas AS1299 (Telia), kaj rulante ping, vi ricevis averaĝan RTT de 70 - 80 milisekundoj. Vi ankaŭ povas vidi ĉi tion ĉe .
Uzante la whois ilo (sur ripe.net aŭ loka ilo), vi povas facile determini ke bloko 37.52.0.0/21 apartenas al AS6849 (Ukrtelecom).
Poste, irante al vi vidas, ke AS6849 havas neniun rilaton kun AS12389 (ili estas nek klientoj nek suprenligoj unu al la alia, nek ili havas peering). Sed se vi rigardas por AS6849, vi vidos, ekzemple, AS29226 (Mastertel) kaj AS31133 (Megafon).
Post kiam vi trovas la spegulon de ĉi tiuj provizantoj, vi povas kompari la vojon kaj RTT. Ekzemple, por Mastertel RTT estos ĉirkaŭ 30 milisekundoj.
Do, se la diferenco inter 80 kaj 30 milisekundoj estas grava por via servo, tiam eble vi devas pensi pri konektebleco, akiri vian AS-numeron, vian adresaron de RIPE kaj konekti pliajn suprenligojn kaj/aŭ krei punktojn de ĉeesto sur IX-oj.
Kiam vi uzas BGP, vi ne nur havas la ŝancon plibonigi konekteblecon, sed vi ankaŭ redunde konservas vian interretan konekton.
enhavas rekomendojn por agordi BGP. Malgraŭ la fakto, ke ĉi tiuj rekomendoj estis evoluigitaj surbaze de la "plej bona praktiko" de provizantoj, tamen (se viaj BGP-agordoj ne estas tute bazaj) ili sendube estas utilaj kaj fakte devus esti parto de la hardado, kiun ni diskutis en .
DOS/DDOS-protekto
Nun DOS/DDOS-atakoj fariĝis ĉiutaga realaĵo por multaj kompanioj. Fakte, oni sufiĉe ofte atakas vin en unu aŭ alia formo. La fakto, ke vi ankoraŭ ne rimarkis tion, signifas nur, ke celita atako ankoraŭ ne estis organizita kontraŭ vi, kaj ke la protektaj iloj, kiujn vi uzas, eĉ eble sen scii ĝin (diversaj enkonstruitaj protektoj de operaciumoj), sufiĉas por certigu, ke degenero de la servo provizita estas minimumigita por vi kaj viaj klientoj.
Estas interretaj rimedoj, kiuj, surbaze de ekipaĵaj protokoloj, desegnas belajn atakmapojn en reala tempo.
vi povas trovi ligilojn al ili.
Mia aminda de CheckPoint.
Protekto kontraŭ DDOS/DOS estas kutime tavoligita. Por kompreni kial, vi devas kompreni kiajn tipojn de DOS/DDOS-atakoj ekzistas (vidu, ekzemple, aŭ )
Tio estas, ni havas tri specojn de atakoj:
- volumetraj atakoj
- protokolaj atakoj
- aplikaj atakoj
Se vi povas protekti vin kontraŭ la lastaj du specoj de atakoj uzante, ekzemple, fajroŝirmilojn, tiam vi ne povas protekti vin kontraŭ atakoj celantaj "superforti" viajn suprenligojn (kompreneble, se via tuta kapablo de interretaj kanaloj ne estas kalkulita en terabitoj, aŭ pli bone ankoraŭ, en dekoj da terabit).
Tial, la unua defendlinio estas protekto kontraŭ "volumetriaj" atakoj, kaj via provizanto aŭ provizantoj devas provizi ĉi tiun protekton al vi. Se vi ankoraŭ ne rimarkis tion, tiam vi estas nur bonŝanca nuntempe.
Ekzemplo:
Ni diru, ke vi havas plurajn suprenligojn, sed nur unu el la provizantoj povas provizi al vi ĉi tiun protekton. Sed se la tuta trafiko pasas tra unu provizanto, do kio pri la konektebleco, kiun ni mallonge diskutis iom pli frue?
En ĉi tiu kazo, vi devos parte oferi konekteblecon dum la atako. Sed
- ĉi tio estas nur por la daŭro de la atako. En la okazo de atako, vi povas permane aŭ aŭtomate reagordi BGP, por ke trafiko iru nur tra la provizanto, kiu provizas al vi la "ombrelon". Post kiam la atako estas finita, vi povas revenigi la vojigon al ĝia antaŭa stato
- Ne necesas transdoni la tutan trafikon. Se, ekzemple, vi vidas, ke ne estas atakoj per iuj suprenligiloj aŭ peering (aŭ la trafiko ne estas grava), vi povas daŭre reklami prefiksojn kun konkurencivaj atributoj al ĉi tiuj BGP-najbaroj.
Vi ankaŭ povas delegi protekton kontraŭ "protokolaj atakoj" kaj "aplikataj atakoj" al viaj partneroj.
tie vi povas legi bonan studon (). Vere, la artikolo estas dujara, sed ĝi donos al vi ideon pri la aliroj pri kiel vi povas protekti vin kontraŭ DDOS-atakoj.
Principe, vi povas limigi vin al ĉi tio, tute subkontraktante vian protekton. Estas avantaĝoj al ĉi tiu decido, sed ankaŭ estas evidenta malavantaĝo. La fakto estas, ke ni povas paroli (denove, depende de tio, kion faras via kompanio) pri la postvivado de la komerco. Kaj fidu tiajn aferojn al triaj...
Tial, ni rigardu kiel organizi la duan kaj trian defendliniojn (kiel aldono al protekto de la provizanto).
Do, la dua defendlinio estas filtrado kaj trafikaj limigiloj (policistoj) ĉe la enirejo al via reto.
ekzemple 1
Ni supozu, ke vi kovris vin per ombrelo kontraŭ DDOS kun la helpo de unu el la provizantoj. Ni supozu, ke ĉi tiu provizanto uzas Arbor por filtri trafikon kaj filtrilojn ĉe la rando de sia reto.
La larĝa de bando, kiun Arbor povas "procezi" estas limigita, kaj la provizanto, kompreneble, ne povas konstante pasi la trafikon de ĉiuj siaj partneroj, kiuj ordigas ĉi tiun servon per filtra ekipaĵo. Tial, en normalaj kondiĉoj, trafiko ne estas filtrita.
Ni supozu, ke estas SYN-inundatako. Eĉ se vi mendis servon, kiu aŭtomate ŝanĝas trafikon al filtrado en kazo de atako, tio ne okazas tuj. Dum minuto aŭ pli vi restas sub atako. Kaj ĉi tio povas konduki al fiasko de via ekipaĵo aŭ degenero de la servo. En ĉi tiu kazo, limigi trafikon ĉe la rando-vojigo, kvankam ĝi kondukos al la fakto, ke iuj TCP-sesioj ne estos establitaj dum ĉi tiu tempo, savos vian infrastrukturon de pli grandskalaj problemoj.
ekzemple 2
Nenormale granda nombro da SYN-pakaĵoj eble ne nur estas la rezulto de SYN-inundatako. Ni supozu, ke vi provizas servon, en kiu vi povas samtempe havi ĉirkaŭ 100 mil TCP-konektojn (al unu datumcentro).
Ni diru, ke kiel rezulto de mallongdaŭra problemo kun unu el viaj ĉefaj provizantoj, duono de viaj sesioj estas piedbatitaj. Se via aplikaĵo estas desegnita tiel ke, sen pripensi dufoje, ĝi tuj (aŭ post iom da tempo-intervalo kiu estas la sama por ĉiuj sesioj) provas reestabli la konekton, tiam vi ricevos almenaŭ 50 mil SYN-pakojn proksimume. samtempe.
Se, ekzemple, vi devas ruli ssl/tls manpremadon aldone al ĉi tiuj sesioj, kio implikas interŝanĝi atestojn, tiam el la vidpunkto de malplenigo de rimedoj por via ŝarĝbalancilo, ĉi tio estos multe pli forta "DDOS" ol simpla. SYN inundo. Ŝajnus, ke ekvilibristoj devus trakti tiajn eventojn, sed... bedaŭrinde, ni estas antaŭ tia problemo.
Kaj, kompreneble, policisto sur la randa enkursigilo savos vian ekipaĵon ankaŭ en ĉi tiu kazo.
La tria nivelo de protekto kontraŭ DDOS/DOS estas viaj fajroŝirmilaj agordoj.
Ĉi tie vi povas ĉesigi ambaŭ atakojn de la dua kaj tria tipoj. Ĝenerale, ĉio, kio atingas la fajroŝirmilon, povas esti filtrita ĉi tie.
Konsilo
Provu doni al la fajroŝirmilo kiel eble plej malmulte da laboro, filtrante kiel eble plej multe sur la unuaj du defendlinioj. Kaj tial.
Ĉu iam okazis al vi, ke hazarde, generante trafikon por kontroli, ekzemple, kiom rezistas la operaciumo de viaj serviloj al DDOS-atakoj, vi "mortigis" vian fajroŝirmilon, ŝarĝante ĝin al 100 procentoj, kun trafiko je normala intenseco. ? Se ne, ĉu eble simple ĉar vi ne provis?
Ĝenerale, fajroŝirmilo, kiel mi diris, estas kompleksa afero, kaj ĝi bone funkcias kun konataj vundeblecoj kaj testitaj solvoj, sed se vi sendas ion nekutima, nur iom da rubo aŭ pakaĵetoj kun malĝustaj kaplinioj, tiam vi estas kun iuj, ne Kun. tia malgranda probableco (surbaze de mia sperto), vi povas stupefi eĉ altnivelan ekipaĵon. Tial, en la etapo 2, uzante regulajn ACL-ojn (ĉe la L3/L4-nivelo), nur permesu trafikon en vian reton, kiu devus eniri tien.
Filtri trafikon sur la fajroŝirmilo
Ni daŭrigu la konversacion pri la fajroŝirmilo. Vi devas kompreni, ke DOS/DDOS-atakoj estas nur unu speco de ciberatako.
Krom DOS/DDOS-protekto, ni ankaŭ povas havi ion kiel la jena listo de funkcioj:
- aplikaĵa fajroŝirmilo
- minaco-preventado (antiviruso, kontraŭ-spiono kaj vundebleco)
- URL-filtrado
- filtrado de datumoj (filtrado de enhavo)
- dosierblokado (dosiertipoj blokado)
Dependas de vi decidi kion vi bezonas el ĉi tiu listo.
Daŭrigi
fonto: www.habr.com