ProHoster > Blogs > Administrācija > Kā pārņemt kontroli pār savu tÄ«kla infrastruktÅ«ru. TreŔā nodaļa. TÄ«kla droŔība. Pirmā daļa

Kā pārņemt kontroli pār savu tÄ«kla infrastruktÅ«ru. TreŔā nodaļa. TÄ«kla droŔība. Pirmā daļa

Å is ir treÅ”ais raksts rakstu sērijā ā€œKā kontrolēt tÄ«kla infrastruktÅ«ruā€. Visu sērijas rakstu saturu un saites var atrast Å”eit.

Kā pārņemt kontroli pār savu tÄ«kla infrastruktÅ«ru. TreŔā nodaļa. TÄ«kla droŔība. Pirmā daļa

Nav jēgas runāt par pilnÄ«gu droŔības risku novērÅ”anu. Principā mēs nevaram tos samazināt lÄ«dz nullei. Mums arÄ« jāsaprot, ka, cenÅ”oties padarÄ«t tÄ«klu arvien droŔāku, mÅ«su risinājumi kļūst arvien dārgāki. Jums ir jāatrod kompromiss starp izmaksām, sarežģītÄ«bu un droŔību, kas atbilst jÅ«su tÄ«klam.

Protams, droŔības dizains ir organiski integrēts kopējā arhitektÅ«rā, un izmantotie droŔības risinājumi ietekmē tÄ«kla infrastruktÅ«ras mērogojamÄ«bu, uzticamÄ«bu, vadāmÄ«bu, ..., kas arÄ« bÅ«tu jāņem vērā.

Bet atgādināŔu, ka tagad mēs nerunājam par tÄ«kla izveidi. Saskaņā ar mÅ«su sākotnējie nosacÄ«jumi mēs jau esam izvēlējuÅ”ies dizainu, izvēlējuÅ”ies aprÄ«kojumu un izveidojuÅ”i infrastruktÅ«ru, un Å”ajā posmā, ja iespējams, vajadzētu ā€œdzÄ«votā€ un meklēt risinājumus iepriekÅ” izvēlētās pieejas kontekstā.

MÅ«su uzdevums Å”obrÄ«d ir identificēt ar droŔību saistÄ«tos riskus tÄ«kla lÄ«menÄ« un samazināt tos lÄ«dz saprātÄ«gam lÄ«menim.

Tīkla droŔības audits

Ja jÅ«su organizācija ir ieviesusi ISO 27k procesus, tad droŔības auditiem un tÄ«kla izmaiņām ir nemanāmi jāiekļaujas vispārējos procesos Ŕīs pieejas ietvaros. Bet Å”ie standarti joprojām nav par konkrētiem risinājumiem, ne par konfigurāciju, ne par dizainu... Nav skaidru padomu, nav standartu, kas detalizēti diktētu, kādam jābÅ«t jÅ«su tÄ«klam, tāda ir Ŕī uzdevuma sarežģītÄ«ba un skaistums.

Es izcelÅ”u vairākus iespējamos tÄ«kla droŔības auditus:

  • iekārtu konfigurācijas audits (rÅ«dÄ«Å”ana)
  • droŔības dizaina audits
  • piekļuves audits
  • procesa audits

Iekārtas konfigurācijas audits (rūdīŔana)

Å Ä·iet, ka vairumā gadÄ«jumu tas ir labākais sākumpunkts tÄ«kla auditÄ“Å”anai un droŔības uzlaboÅ”anai. IMHO, Å”is ir labs Pareto likuma demonstrējums (20% piepÅ«les rada 80% no rezultāta, bet atlikuÅ”ie 80% piepÅ«les rada tikai 20% no rezultāta).

BÅ«tÄ«ba ir tāda, ka mums parasti ir ieteikumi no pārdevējiem par droŔības ā€œlabāko praksiā€, konfigurējot aprÄ«kojumu. To sauc par "sacietÄ“Å”anu".

Pamatojoties uz Å”iem ieteikumiem, jÅ«s bieži varat arÄ« atrast anketu (vai izveidot to pats), kas palÄ«dzēs noteikt, cik labi jÅ«su aprÄ«kojuma konfigurācija atbilst Å”iem "labākajiem piemēriem", un atbilstoÅ”i rezultātiem veikt izmaiņas tÄ«klā. . Tas ļaus jums ievērojami samazināt droŔības riskus diezgan vienkārÅ”i, praktiski bez maksas.

Vairāki piemēri dažām Cisco operētājsistēmām.

Cisco IOS konfigurācijas sacietÄ“Å”ana
Cisco IOS-XR konfigurācijas sacietÄ“Å”ana
Cisco NX-OS konfigurācijas sacietÄ“Å”ana
Cisco Baseline droŔības kontrolsaraksts

Pamatojoties uz Å”iem dokumentiem, var izveidot konfigurācijas prasÄ«bu sarakstu katram aprÄ«kojuma veidam. Piemēram, Cisco N7K VDC Ŕīs prasÄ«bas varētu izskatÄ«ties Ŕādi tā.

Tādā veidā var izveidot konfigurācijas failus dažāda veida aktÄ«vajām iekārtām jÅ«su tÄ«kla infrastruktÅ«rā. Pēc tam manuāli vai izmantojot automatizāciju varat ā€œaugÅ”upielādētā€ Å”os konfigurācijas failus. Kā automatizēt Å”o procesu, tas tiks detalizēti apspriests citā rakstu sērijā par orÄ·estrÄ“Å”anu un automatizāciju.

DroŔības dizaina audits

Parasti uzņēmuma tÄ«kls vienā vai otrā veidā satur Ŕādus segmentus:

  • DC (sabiedrisko pakalpojumu DMZ un iekÅ”tÄ«kla datu centrs)
  • Interneta pieslēgums
  • Attālās piekļuves VPN
  • WAN mala
  • Filiāle
  • Campus (birojs)
  • Kodols

Nosaukumi ņemti no Cisco SAFE modeli, bet tas, protams, nav jāpiesaista tieÅ”i Å”iem nosaukumiem un Å”im modelim. Tomēr es vēlos runāt par bÅ«tÄ«bu un neieslÄ«gt formalitātēs.

Katram no Ŕiem segmentiem droŔības prasības, riski un attiecīgi risinājumi būs atŔķirīgi.

ApskatÄ«sim katru no tiem atseviŔķi, lai noskaidrotu problēmas, ar kurām jÅ«s varat saskarties no droŔības dizaina viedokļa. Protams, vēlreiz atkārtoju, ka Å”is raksts nekādā gadÄ«jumā nepretendē uz pilnÄ«gu, ko Å”ajā patiesi dziļajā un daudzpusÄ«gajā tēmā nav viegli (ja ne neiespējami) panākt, taču tas atspoguļo manu personÄ«go pieredzi.

Ideāla risinājuma nav (vismaz pagaidām). Tas vienmēr ir kompromiss. Taču ir svarÄ«gi, lai lēmums par vienas vai citas pieejas izmantoÅ”anu tiktu pieņemts apzināti, saprotot gan tās plusus, gan mÄ«nusus.

Datu centrs

Viskritiskākais segments no droŔības viedokļa.
Un, kā parasti, arÄ« Å”eit nav universāla risinājuma. Tas viss lielā mērā ir atkarÄ«gs no tÄ«kla prasÄ«bām.

Vai ir nepiecieÅ”ams ugunsmÅ«ris vai nē?

Å Ä·iet, ka atbilde ir acÄ«mredzama, taču viss nav tik skaidrs, kā varētu Ŕķist. Un jÅ«su izvēli var ietekmēt ne tikai cena.

Piemērs 1. KavÄ“Å”anās.

Ja zems latentums ir bÅ«tiska prasÄ«ba starp dažiem tÄ«kla segmentiem, kas, piemēram, ir taisnÄ«ba apmaiņas gadÄ«jumā, tad mēs nevarēsim izmantot ugunsmÅ«rus starp Å”iem segmentiem. Ir grÅ«ti atrast pētÄ«jumus par ugunsmÅ«ru latentumu, taču daži slēdžu modeļi var nodroÅ”ināt latentumu, kas ir mazāks par 1 mksec vai aptuveni XNUMX sekundē, tāpēc es domāju, ka, ja jums ir svarÄ«gas mikrosekundes, tad ugunsmÅ«ri nav paredzēti jums.

Piemērs 2. Veiktspēja.

Augstāko L3 slēdžu caurlaidspēja parasti ir par vienu pakāpi augstāka nekā jaudÄ«gāko ugunsmÅ«ru caurlaidspēja. Tāpēc augstas intensitātes trafika gadÄ«jumā jums arÄ«, visticamāk, bÅ«s jāļauj Å”ai trafikai apiet ugunsmÅ«rus.

Piemērs 3. Uzticamību.

UgunsmÅ«ri, Ä«paÅ”i mÅ«sdienu NGFW (Next-Generation FW) ir sarežģītas ierÄ«ces. Tie ir daudz sarežģītāki nekā L3/L2 slēdži. Tie nodroÅ”ina lielu skaitu pakalpojumu un konfigurācijas iespēju, tāpēc nav pārsteidzoÅ”i, ka to uzticamÄ«ba ir daudz zemāka. Ja pakalpojuma nepārtrauktÄ«ba ir ļoti svarÄ«ga tÄ«klam, jums var nākties izvēlēties, kas nodroÅ”inās labāku pieejamÄ«bu - droŔība ar ugunsmÅ«ri vai tÄ«kla vienkārŔība, kas veidota uz slēdžiem (vai dažāda veida audumiem), izmantojot parastos ACL.

IepriekÅ” minēto piemēru gadÄ«jumā jums, visticamāk, (kā parasti) bÅ«s jāmeklē kompromiss. Apskatiet Ŕādus risinājumus:

  • ja nolemjat neizmantot ugunsmÅ«rus datu centra iekÅ”ienē, tad jādomā, kā pēc iespējas ierobežot piekļuvi pa perimetru. Piemēram, jÅ«s varat atvērt tikai nepiecieÅ”amos portus no interneta (klienta trafikam) un administratÄ«vo piekļuvi datu centram tikai no jump hosts. Veiciet visas nepiecieÅ”amās pārbaudes (autentifikācija/autorizācija, antivÄ«russ, reÄ£istrÄ“Å”ana utt.)
  • varat izmantot datu centra tÄ«kla loÄ£isko nodalÄ«jumu segmentos, lÄ«dzÄ«gi kā PSEFABRIC aprakstÄ«tā shēma piemērs p002. Å ajā gadÄ«jumā marÅ”rutÄ“Å”ana ir jākonfigurē tā, lai aizkaves jutÄ«ga vai augstas intensitātes trafika nonāktu viena segmenta ietvaros (p002 gadÄ«jumā VRF) un neizietu cauri ugunsmÅ«rim. Satiksme starp dažādiem segmentiem turpinās iet caur ugunsmÅ«ri. Varat arÄ« izmantot marÅ”ruta noplÅ«di starp VRF, lai izvairÄ«tos no trafika novirzÄ«Å”anas caur ugunsmÅ«ri
  • Varat arÄ« izmantot ugunsmÅ«ri caurspÄ«dÄ«gā režīmā un tikai tiem VLAN, kur Å”ie faktori (latence/performance) nav nozÄ«mÄ«gi. Bet jums rÅ«pÄ«gi jāizpēta ierobežojumi, kas saistÄ«ti ar Ŕī moda izmantoÅ”anu katram pārdevējam
  • iespējams, vēlēsities apsvērt pakalpojumu ķēdes arhitektÅ«ras izmantoÅ”anu. Tas ļaus tikai nepiecieÅ”amajai satiksmei iziet cauri ugunsmÅ«rim. Teorētiski izskatās jauki, bet es nekad neesmu redzējis Å”o risinājumu ražoÅ”anā. Mēs testējām Cisco ACI/Juniper SRX/F5 LTM servisa ķēdi pirms aptuveni 3 gadiem, taču toreiz Å”is risinājums mums Ŕķita ā€œneapstrādātsā€.

Aizsardzības līmenis

Tagad jums ir jāatbild uz jautājumu, kādus rÄ«kus vēlaties izmantot trafika filtrÄ“Å”anai. Å eit ir dažas no funkcijām, kas parasti ir pieejamas NGFW (piemēram, Å”eit):

  • stāvokļu ugunsmÅ«ris (noklusējums)
  • lietojumprogrammu ugunsmÅ«ris
  • draudu novērÅ”ana (antivÄ«russ, pretspiegprogrammatÅ«ra un ievainojamÄ«ba)
  • URL filtrÄ“Å”ana
  • datu filtrÄ“Å”ana (satura filtrÄ“Å”ana)
  • failu bloÄ·Ä“Å”ana (failu tipu bloÄ·Ä“Å”ana)
  • dos aizsardzÄ«bu

Un arī ne viss ir skaidrs. Šķiet, jo augstāks aizsardzības līmenis, jo labāk. Bet jums tas arī jāņem vērā

  • Jo vairāk no iepriekÅ” minētajām ugunsmÅ«ra funkcijām jÅ«s izmantojat, jo dārgākas tas, protams, bÅ«s (licences, papildu moduļi)
  • dažu algoritmu izmantoÅ”ana var ievērojami samazināt ugunsmÅ«ra caurlaidspēju un arÄ« palielināt aizkavi, skatiet, piemēram Å”eit
  • tāpat kā jebkurÅ” sarežģīts risinājums, arÄ« sarežģītu aizsardzÄ«bas metožu izmantoÅ”ana var samazināt jÅ«su risinājuma uzticamÄ«bu, piemēram, izmantojot lietojumprogrammu ugunsmÅ«ri, es saskāros ar dažu diezgan standarta darba programmu (dns, smb) bloÄ·Ä“Å”anu.

Kā vienmēr, jums ir jāatrod savam tīklam labākais risinājums.

Nav iespējams viennozÄ«mÄ«gi atbildēt uz jautājumu, kādas aizsardzÄ«bas funkcijas var bÅ«t nepiecieÅ”amas. Pirmkārt, tāpēc, ka tas, protams, ir atkarÄ«gs no datiem, ko pārsÅ«tāt vai glabājat un mēģināt aizsargāt. Otrkārt, patiesÄ«bā bieži vien droŔības rÄ«ku izvēle ir ticÄ«bas un uzticÄ«bas pārdevējam jautājums. JÅ«s nezināt algoritmus, nezināt, cik tie ir efektÄ«vi, un nevarat tos pilnÄ«bā pārbaudÄ«t.

Tāpēc kritiskos segmentos labs risinājums var bÅ«t dažādu uzņēmumu piedāvājumu izmantoÅ”ana. Piemēram, varat iespējot pretvÄ«rusu ugunsmÅ«rÄ«, bet arÄ« izmantot pretvÄ«rusu aizsardzÄ«bu (no cita ražotāja) lokāli saimniekdatoros.

Segmentācija

Mēs runājam par datu centru tÄ«kla loÄ£isko segmentāciju. Piemēram, sadalÄ«Å”ana VLAN un apakÅ”tÄ«klos arÄ« ir loÄ£iska segmentācija, taču mēs to neuzskatÄ«sim tās acÄ«mredzamÄ«bas dēļ. Interesanta segmentācija, ņemot vērā tādas entÄ«tijas kā FW droŔības zonas, VRF (un to analogi saistÄ«bā ar dažādiem piegādātājiem), loÄ£iskās ierÄ«ces (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant, ...), ...

Šādas loÄ£iskās segmentācijas un Å”obrÄ«d pieprasÄ«tā datu centra dizaina piemērs ir dots PSEFABRIC projekta p002.

Kad esat definējis tÄ«kla loÄ£iskās daļas, varat aprakstÄ«t, kā trafiks pārvietojas starp dažādiem segmentiem, kurās ierÄ«cēs tiks veikta filtrÄ“Å”ana un ar kādiem lÄ«dzekļiem.

Ja jÅ«su tÄ«klam nav skaidra loÄ£iskā nodalÄ«juma un droŔības politiku piemēroÅ”anas noteikumi dažādām datu plÅ«smām nav formalizēti, tas nozÄ«mē, ka, atverot Å”o vai citu piekļuvi, jÅ«s esat spiests atrisināt Å”o problēmu un ar lielu varbÅ«tÄ«bu katru reizi atrisinās savādāk.

Bieži vien segmentācija balstās tikai uz FW droŔības zonām. Tad jums ir jāatbild uz Ŕādiem jautājumiem:

  • kādas droŔības zonas jums ir vajadzÄ«gas
  • kādu aizsardzÄ«bas lÄ«meni vēlaties piemērot katrai no Ŕīm zonām
  • vai zonas iekŔējā satiksme bÅ«s atļauta pēc noklusējuma?
  • ja nē, kādas trafika filtrÄ“Å”anas politikas tiks piemērotas katrā zonā
  • kādas trafika filtrÄ“Å”anas politikas tiks piemērotas katram zonu pārim (avots/galamērÄ·is)

CAGR

Bieži sastopama problēma ir nepietiekama TCAM (Ternary Content Addressable Memory) gan marÅ”rutÄ“Å”anai, gan piekļuvei. IMHO, tas ir viens no svarÄ«gākajiem jautājumiem, izvēloties aprÄ«kojumu, tāpēc jums ir jāizturas pret Å”o problēmu ar atbilstoÅ”u rÅ«pÄ«bu.

Piemērs 1. PārsÅ«tÄ«Å”anas tabula TCAM.

Apskatīsim Palo Alto 7k ugunsmūris
Mēs redzam, ka IPv4 pārsÅ«tÄ«Å”anas tabulas izmērs* = 32K
Turklāt Ŕis marŔrutu skaits ir kopīgs visiem VSYS.

Pieņemsim, ka atbilstoÅ”i jÅ«su dizainam jÅ«s nolemjat izmantot 4 VSYS.
Katrs no Å”iem VSYS ir savienots, izmantojot BGP, ar diviem mākoņa MPLS PE, kurus izmantojat kā BB. Tādējādi 4 VSYS apmainās ar visiem konkrētajiem marÅ”rutiem savā starpā, un tiem ir pārsÅ«tÄ«Å”anas tabula ar aptuveni vienādām marÅ”rutu kopām (bet dažādiem NH). Jo katrā VSYS ir 2 BGP sesijas (ar vienādiem iestatÄ«jumiem), tad katram marÅ”rutam, kas saņemts caur MPLS, ir 2 NH un attiecÄ«gi 2 FIB ieraksti PārsÅ«tÄ«Å”anas tabulā. Ja pieņemam, ka Å”is ir vienÄ«gais ugunsmÅ«ris datu centrā un tam ir jāzina par visiem marÅ”rutiem, tad tas nozÄ«mēs, ka kopējais marÅ”rutu skaits mÅ«su datu centrā nevar bÅ«t lielāks par 32K/(4 * 2) = 4K.

Tagad, ja pieņemam, ka mums ir 2 datu centri (ar vienādu dizainu), un mēs vēlamies izmantot VLAN, kas ir ā€œizstieptsā€ starp datu centriem (piemēram, vMotion), tad, lai atrisinātu marÅ”rutÄ“Å”anas problēmu, mums ir jāizmanto resursdatora marÅ”ruti. . Bet tas nozÄ«mē, ka 2 datu centriem mums bÅ«s ne vairāk kā 4096 iespējamie saimnieki, un, protams, ar to var nepietikt.

2. piemērs. ACL TCAM.

Ja plānojat filtrēt trafiku uz L3 slēdžiem (vai citiem risinājumiem, kas izmanto L3 slēdžus, piemēram, Cisco ACI), tad, izvēloties aprÄ«kojumu, jāpievērÅ” uzmanÄ«ba TCAM ACL.

Pieņemsim, ka vēlaties kontrolēt piekļuvi Cisco Catalyst 4500 SVI saskarnēm. Pēc tam, kā redzams no no Ŕī raksta, lai kontrolētu izejoÅ”o (kā arÄ« ienākoÅ”o) trafiku saskarnēs, varat izmantot tikai 4096 TCAM lÄ«nijas. Kas, izmantojot TCAM3, dos jums aptuveni 4000 tÅ«kstoÅ”us ACE (ACL lÄ«nijas).

Ja jÅ«s saskaraties ar nepietiekama TCAM problēmu, vispirms, protams, ir jāapsver optimizācijas iespēja. Tātad, ja rodas problēmas ar pārsÅ«tÄ«Å”anas tabulas lielumu, jums jāapsver iespēja apkopot marÅ”rutus. Ja rodas problēma ar piekļuves TCAM lielumu, pārbaudiet piekļuves, noņemiet novecojuÅ”os un pārklājoÅ”os ierakstus un, iespējams, pārskatiet pieeju atvērÅ”anas procedÅ«ru (sÄ«kāk tiks apspriests sadaļā par piekļuves auditÄ“Å”anu).

Augsta pieejamība

Jautājums ir: vai man izmantot HA ugunsmÅ«riem vai uzstādÄ«t divas neatkarÄ«gas kastes ā€œparalēliā€ un, ja viena no tām neizdodas, trafiku novirzÄ«t caur otro?

Å Ä·iet, ka atbilde ir acÄ«mredzama - izmantojiet HA. Iemesls, kāpēc Å”is jautājums joprojām rodas, ir tas, ka diemžēl teorētiskā un reklāmas 99 pieejamÄ«ba un vairākas decimāldaļas praktiski nav tik rožainas. HA loÄ£iski ir diezgan sarežģīta lieta, un uz dažādām iekārtām un ar dažādiem pārdevējiem (nebija izņēmumu) mēs pieķērām problēmas un kļūdas un servisa pārtraukumus.

Ja izmantosiet HA, jums bÅ«s iespēja izslēgt atseviŔķus mezglus, pārslēgties starp tiem, neapturot pakalpojumu, kas ir svarÄ«gi, piemēram, veicot jauninājumus, bet tajā paŔā laikā jums ir tālu no nulles varbÅ«tÄ«bas, ka abi mezgli salÅ«zÄ«s tajā paŔā laikā, un arÄ« to, ka nākamajā jaunināŔana nenotiks tik gludi, kā sola pārdevējs (Å”o problēmu var izvairÄ«ties, ja ir iespēja pārbaudÄ«t jauninājumu uz laboratorijas aprÄ«kojuma).

Ja neizmantojat HA, tad no dubulto atteices viedokļa jÅ«su riski ir daudz mazāki (tā kā jums ir 2 neatkarÄ«gi ugunsmÅ«ri), bet kopÅ”... sesijas netiek sinhronizētas, tad katru reizi, pārslēdzoties starp Å”iem ugunsmÅ«riem, jÅ«s zaudēsit trafiku. Protams, jÅ«s varat izmantot bezvalsts ugunsmÅ«ri, taču tad ugunsmÅ«ra izmantoÅ”anas jēga lielā mērā tiek zaudēta.

Tāpēc, ja audita rezultātā esat atklājuÅ”i vientuļus ugunsmÅ«rus un domājat par sava tÄ«kla uzticamÄ«bas palielināŔanu, tad HA, protams, ir viens no ieteicamajiem risinājumiem, taču jāņem vērā arÄ« ar to saistÄ«tie trÅ«kumi izmantojot Å”o pieeju un, iespējams, tieÅ”i jÅ«su tÄ«klam piemērotāks bÅ«tu cits risinājums.

Vadāmība

Principā HA ir arÄ« vadāmÄ«ba. Tā vietā, lai atseviŔķi konfigurētu 2 lodziņus un risinātu problēmu, kas saistÄ«ta ar konfigurāciju sinhronizÄ“Å”anu, jÅ«s tās pārvaldāt tā, it kā jums bÅ«tu viena ierÄ«ce.

Bet varbūt jums ir daudz datu centru un daudz ugunsmūru, tad Ŕis jautājums rodas jaunā līmenī. Un jautājums ir ne tikai par konfigurāciju, bet arī par

  • rezerves konfigurācijas
  • atjauninājumus
  • jauninājumiem
  • uzraudzÄ«bu
  • mežizstrāde

Un to visu var atrisināt ar centralizētām vadības sistēmām.

Tātad, piemēram, ja izmantojat Palo Alto ugunsmÅ«rus, tad ApskatÄ«t ir Ŕāds risinājums.

Turpināsim.

Avots: www.habr.com

Pievieno komentāru