Dit artikel is it tredde yn in searje artikels "Hoe kinne jo kontrôle nimme oer jo netwurkynfrastruktuer." De ynhâld fan alle artikels yn 'e searje en keppelings is te finen .
D'r is gjin punt om te praten oer it folslein eliminearjen fan feiligensrisiko's. Yn prinsipe kinne wy se net ferminderje nei nul. Wy moatte ek begripe dat as wy stribje om it netwurk hieltyd feiliger te meitsjen, ús oplossingen hieltyd djoerder wurde. Jo moatte in ôfwikseling fine tusken kosten, kompleksiteit en feiligens dy't sin makket foar jo netwurk.
Fansels is befeiligingsûntwerp organysk yntegrearre yn 'e algemiene arsjitektuer en de brûkte befeiligingsoplossingen beynfloedzje de skalberens, betrouberens, behearberens, ... fan' e netwurkynfrastruktuer, wêrmei't ek rekken holden wurde moat.
Mar lit my jo herinnerje dat wy no net prate oer it meitsjen fan in netwurk. Neffens ús wy hawwe it ûntwerp al keazen, de apparatuer selektearre en de ynfrastruktuer makke, en op dit poadium, as it mooglik is, moatte wy "libje" en oplossingen fine yn 'e kontekst fan' e earder keazen oanpak.
Us taak is no om de risiko's te identifisearjen dy't ferbûn binne mei feiligens op netwurknivo en ferminderje se nei in ridlik nivo.
Netwurk feiligens audit
As jo organisaasje ISO 27k-prosessen hat ymplementearre, dan moatte feiligenskontrôles en netwurkferoarings naadloos passe yn 'e algemiene prosessen binnen dizze oanpak. Mar dizze noarmen binne noch altyd net oer spesifike oplossingen, net oer konfiguraasje, net oer ûntwerp ... D'r binne gjin dúdlik advys, gjin noarmen dy't yn detail diktearje hoe't jo netwurk wêze moat, dit is de kompleksiteit en skientme fan dizze taak.
Ik soe ferskate mooglike kontrôles foar netwurkfeiligens markearje:
- kontrôle fan apparatuerkonfiguraasje (ferharding)
- feiligens design audit
- tagong audit
- proses audit
Equipment konfiguraasje audit (ferharding)
It liket derop dat dit yn 'e measte gefallen it bêste begjinpunt is foar it kontrolearjen en ferbetterjen fan de feiligens fan jo netwurk. IMHO, dit is in goede demonstraasje fan Pareto syn wet (20% fan ynspannings produsearret 80% fan it resultaat, en de oerbleaune 80% fan ynspannings produsearret allinnich 20% fan it resultaat).
De ûnderste rigel is dat wy meastal oanbefellings hawwe fan ferkeapers oangeande "bêste praktiken" foar feiligens by it konfigurearjen fan apparatuer. Dit wurdt "ferharding" neamd.
Jo kinne ek faaks in fragelist fine (of sels ien meitsje) basearre op dizze oanbefellings, dy't jo helpe kinne bepale hoe goed de konfiguraasje fan jo apparatuer foldocht oan dizze "bêste praktiken" en, yn oerienstimming mei it resultaat, wizigingen oanmeitsje yn jo netwurk . Hjirmei kinne jo befeiligingsrisiko's frij maklik ferminderje, frijwol sûnder kosten.
Ferskate foarbylden foar guon Cisco bestjoeringssystemen.
Op grûn fan dizze dokuminten kin in list mei konfiguraasjeeasken foar elk type apparatuer oanmakke wurde. Bygelyks, foar in Cisco N7K VDC kin dizze easken lykje .
Op dizze manier kinne konfiguraasjebestannen makke wurde foar ferskate soarten aktive apparatuer yn jo netwurkynfrastruktuer. Folgjende, mei de hân of mei help fan automatisearring, kinne jo dizze konfiguraasjebestannen "uploade". Hoe dit proses te automatisearjen sil yn detail besprutsen wurde yn in oare searje artikels oer orkestraasje en automatisearring.
Feiligens design audit
Typysk befettet in bedriuwsnetwurk de folgjende segminten yn ien of oare foarm:
- DC (Iepenbiere tsjinsten DMZ en Intranet datacenter)
- ynternet tagong
- VPN op ôfstân tagong
- WAN edge
- Tûke
- Kampus (kantoar)
- Kearn
Titels nommen út model, mar it is fansels net nedich om krekt oan dizze nammen en oan dit model hechte te wurden. Dochs wol ik it oer de essinsje ha en net yn formaliteiten delkomme.
Foar elk fan dizze segminten sille feiligenseasken, risiko's en, sadwaande, oplossingen oars wêze.
Litte wy elk fan har apart besjen foar de problemen dy't jo kinne tsjinkomme út in eachpunt fan feiligensûntwerp. Fansels, ik werhelje nochris dat dit artikel op gjin inkelde manier docht pretend te wêzen folslein, dat is net maklik (as net ûnmooglik) te berikken yn dit echt djippe en mannichfâldige ûnderwerp, mar it wjerspegelet myn persoanlike ûnderfining.
D'r is gjin perfekte oplossing (alteast noch net). It is altyd in kompromis. Mar it is wichtich dat it beslút om ien of oare oanpak te brûken bewust makke, mei in begryp fan sawol de foar- as neidielen.
Datasintrum
De meast krityske segmint út in feiligens eachpunt.
En, lykas gewoanlik, is hjir ek gjin universele oplossing. It hinget allegear sterk ôf fan 'e netwurkeasken.
Is in firewall nedich of net?
It soe lykje dat it antwurd fanselssprekkend is, mar alles is net sa dúdlik as it liket. En jo kar kin net allinich beynfloede wurde de priis.
Foarbyld 1. Fertragingen.
As lege latency in essensjele eask is tusken guon netwurksegminten, wat bygelyks wier is yn it gefal fan in útwikseling, dan sille wy gjin firewalls kinne brûke tusken dizze segminten. It is dreech om stúdzjes te finen oer latency yn firewalls, mar in pear switchmodellen kinne latency leverje fan minder as of yn 'e oarder fan 1 mksec, dus ik tink dat as mikrosekonden wichtich binne foar jo, dan binne firewalls net foar jo.
Foarbyld 2. Optreden.
De trochstreaming fan top L3-skeakels is meastal in folchoarder fan grutte heger as de trochfier fan 'e machtichste brânmuorre. Dêrom, yn it gefal fan ferkear mei hege yntinsiteit, sille jo ek nei alle gedachten ek moatte tastean dit ferkear te omgean firewalls.
Foarbyld 3. Reliabiliteit
Firewalls, benammen moderne NGFW (Next-Generation FW) binne komplekse apparaten. Se binne folle komplekser as L3 / L2 switches. Se jouwe in grut oantal tsjinsten en konfiguraasje opsjes, dus it is net ferrassend dat harren betrouberens is folle leger. As tsjinstkontinuïteit kritysk is foar it netwurk, dan moatte jo miskien kieze wat sil liede ta bettere beskikberens - feiligens mei in firewall of de ienfâld fan in netwurk boud op skeakels (as ferskate soarten stoffen) mei reguliere ACL's.
Yn it gefal fan boppesteande foarbylden sille jo wierskynlik (lykas gewoanlik) in kompromis fine moatte. Sjoch nei de folgjende oplossingen:
- as jo beslute om gjin firewalls yn it datasintrum te brûken, dan moatte jo tinke oer hoe't jo tagong om 'e perimeter safolle mooglik beheine kinne. Jo kinne bygelyks allinich de nedige havens fan it ynternet iepenje (foar kliïntferkear) en bestjoerlike tagong ta it datasintrum allinich fan springhosts. Fier op spronghosts alle nedige kontrôles út (autentikaasje / autorisaasje, antivirus, logging, ...)
- jo kinne in logyske dieling fan it datacenternetwurk brûke yn segminten, fergelykber mei it skema beskreaun yn PSEFABRIC . Yn dit gefal moat routing op sa'n manier konfigureare wurde dat fertragingsgefoelige of hege yntinsiteit ferkear "binnen" ien segmint giet (yn it gefal fan p002, VRF) en net troch de brânmuorre giet. Ferkear tusken ferskate segminten sil trochgean troch de brânmuorre. Jo kinne ek gebrûk meitsje fan rûte lekkage tusken VRF's om foar te kommen dat it ferkear troch de brânmuorre trochferwiisd wurdt
- Jo kinne ek brûke in brânmuorre yn transparante modus en allinnich foar dy VLANs dêr't dizze faktoaren (latency / prestaasjes) binne net wichtich. Mar jo moatte soarchfâldich studearje de beheinings ferbûn mei it brûken fan dizze mod foar eltse ferkeaper
- jo kinne miskien beskôgje it brûken fan in tsjinstketen-arsjitektuer. Dit sil allinich needsaaklik ferkear troch de firewall passe. Sjocht der moai yn teory, mar ik haw nea sjoen dizze oplossing yn produksje. Wy hifke de tsjinst keatling foar Cisco ACI / Juniper SRX / F5 LTM oer 3 jierren lyn, mar op dat stuit like dizze oplossing "crude" foar ús.
Beskermingsnivo
No moatte jo de fraach beantwurdzje fan hokker ark jo wolle brûke om ferkear te filterjen. Hjir binne guon fan 'e funksjes dy't normaal oanwêzich binne yn NGFW (bygelyks, ):
- stateful firewalling (standert)
- applikaasje firewalling
- bedrigingsprevinsje (antivirus, anty-spyware, en kwetsberens)
- URL-filtering
- gegevensfiltering (ynhâldfiltering)
- bestân blokkearje (bestânstypen blokkearje)
- dos beskerming
En net alles is ek dúdlik. It soe lykje dat hoe heger it nivo fan beskerming, hoe better. Mar dêr moatte jo ek rekken mei hâlde
- Hoe mear fan 'e boppesteande firewallfunksjes jo brûke, hoe djoerder sil it fansels wêze (lisinsjes, ekstra modules)
- it brûken fan guon algoritmen kin gâns ferminderje brânmuorre trochstreaming en ek fergrutsje fertraging, sjoch bygelyks
- lykas elke komplekse oplossing, kin it brûken fan komplekse beskermingsmetoaden de betrouberens fan jo oplossing ferminderje, bygelyks by it brûken fan applikaasje-firewalling, tsjinkaam ik blokkearjen fan guon frij standert wurkjende applikaasjes (dns, smb)
Lykas altyd moatte jo de bêste oplossing fine foar jo netwurk.
It is ûnmooglik om de fraach definityf te beantwurdzjen fan hokker beskermingsfunksjes nedich binne. As earste, om't it fansels hinget fan 'e gegevens dy't jo ferstjoere of opslaan en besykje te beskermjen. Twads, yn 'e realiteit, is de kar fan befeiligingsynstruminten faak in kwestje fan leauwen en fertrouwen yn' e ferkeaper. Jo kenne de algoritmen net, jo witte net hoe effektyf se binne, en jo kinne se net folslein testen.
Dêrom, yn krityske segminten, kin in goede oplossing wêze om oanbiedingen fan ferskate bedriuwen te brûken. Jo kinne bygelyks antivirus ynskeakelje op 'e firewall, mar ek antyvirusbeskerming (fan in oare fabrikant) lokaal op' e hosts brûke.
Segmentaasje
Wy prate oer de logyske segmintaasje fan it datacenternetwurk. Bygelyks, partitioning yn VLANs en subnets is ek logyske segmentation, mar wy sille net beskôgje it fanwege syn fanselssprekkend. Nijsgjirrige segmentaasje mei rekken hâldend mei sokke entiteiten as FW-befeiligingssônes, VRF's (en har analogen yn relaasje ta ferskate leveransiers), logyske apparaten (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant, ...), ...
In foarbyld fan sa'n logyske segmintaasje en it op it stuit yn fraach ûntwerp fan datasintrum wurdt jûn yn .
Nei't jo de logyske dielen fan jo netwurk hawwe definieare, kinne jo dan beskriuwe hoe't ferkear beweecht tusken ferskate segminten, op hokker apparaten filterjen sil wurde útfierd en mei hokker middels.
As jo netwurk gjin dúdlike logyske dieling hat en de regels foar it tapassen fan befeiligingsbelied foar ferskate gegevensstreamen net formalisearre binne, betsjut dit dat as jo dizze of dy tagong iepenje, jo twongen binne dit probleem op te lossen, en mei in hege kâns jo sil it elke kear oars oplosse.
Faak is segmentaasje allinich basearre op FW-feiligenssônes. Dan moatte jo de folgjende fragen beantwurdzje:
- hokker feiligens sônes hawwe jo nedich
- hokker nivo fan beskerming wolle jo tapasse op elk fan dizze sônes
- sil intra-zone ferkear wurde tastien standert?
- sa net, hokker ferkearsfilteringsbelied sil tapast wurde binnen elke sône
- hokker ferkearsfilteringsbelied sil tapast wurde foar elk pear sônes (boarne / bestimming)
TCAM
In mienskiplik probleem is net genôch TCAM (Ternary Content Addressable Memory), sawol foar routing as foar tagongen. IMHO, dit is ien fan 'e wichtichste problemen by it kiezen fan apparatuer, dus jo moatte dit probleem behannelje mei de passende graad fan soarch.
Foarbyld 1. Forwarding Table TCAM.
Litte wy ris efkes sjen brânmuorre
Wy sjogge dat IPv4 trochstjoertabelgrutte * = 32K
Boppedat, dit oantal rûtes is mienskiplik foar alle VSYSs.Litte wy oannimme dat jo neffens jo ûntwerp beslute om 4 VSYS te brûken.
Elk fan dizze VSYS's is fia BGP ferbûn mei twa MPLS PE's fan 'e wolk dy't jo as BB brûke. Sa, 4 VSYS útwikselje alle spesifike rûtes mei elkoar en hawwe in trochstjoere tafel mei likernôch deselde sets fan rûtes (mar ferskillende NHs). Omdat elk VSYS hat 2 BGP-sesjes (mei deselde ynstellings), dan hat elke rûte ûntfongen fia MPLS 2 NH en, neffens, 2 FIB-yngongen yn 'e Forwarding Table. As wy oannimme dat dit de ienige firewall yn it datasintrum is en it moat witte oer alle rûtes, dan sil dit betsjutte dat it totale oantal rûtes yn ús datasintrum net mear wêze kin as 32K / (4 * 2) = 4K.No, as wy oannimme dat wy 2 datasintra hawwe (mei itselde ûntwerp), en wy wolle brûke VLAN's "útrekkene" tusken datasintra (bygelyks foar vMotion), dan moatte wy om it routingprobleem op te lossen, hostrûtes brûke . Mar dit betsjut dat wy foar 2 datasintra net mear dan 4096 mooglike hosts sille hawwe en, fansels, dit kin net genôch wêze.
Foarbyld 2. ACL TCAM.
As jo it ferkear filterje op L3-skeakels (of oare oplossingen dy't L3-skeakels brûke, bygelyks Cisco ACI), dan moatte jo by it kiezen fan apparatuer omtinken jaan oan de TCAM ACL.
Stel dat jo tagong wolle kontrolearje op 'e SVI-ynterfaces fan' e Cisco Catalyst 4500. Dan, lykas te sjen is út , om útgeande (lykas ynkommende) ferkear op ynterfaces te kontrolearjen, kinne jo allinich 4096 TCAM-rigels brûke. Wat by it brûken fan TCAM3 jo sawat 4000 tûzen ACE's (ACL-rigels) sil jaan.
As jo konfrontearre wurde mei it probleem fan ûnfoldwaande TCAM, dan, earst fan alle, fansels, moatte jo beskôgje de mooglikheid fan optimalisaasje. Dus, yn gefal fan in probleem mei de grutte fan 'e Forwarding Table, moatte jo de mooglikheid beskôgje om rûtes te aggregearjen. Yn gefal fan in probleem mei de TCAM grutte foar tagongen, audit tagong, fuortsmite ferâldere en oerlappende records, en mooglik herzien de proseduere foar it iepenjen fan tagongen (sil wurde besprutsen yn detail yn it haadstik oer auditing tagongen).
Heech beskikber
De fraach is: moat ik HA brûke foar firewalls of twa ûnôfhinklike doazen "parallel" ynstallearje en, as ien fan har mislearret, ferkear troch de twadde rûte?
It soe lykje dat it antwurd fanselssprekkend is - brûk HA. De reden wêrom't dizze fraach noch opkomt, is dat spitigernôch de teoretyske en reklame 99 en ferskate desimale persintaazjes fan berikberens yn 'e praktyk lang net sa rooskleurich blike te wêzen. HA is logysk nochal in kompleks ding, en op ferskillende apparatuer, en mei ferskillende vendors (der wiene gjin útsûnderingen), wy fongen problemen en bugs en tsjinst stopt.
As jo HA brûke, sille jo de mooglikheid hawwe om yndividuele knopen út te skeakeljen, tusken har te wikseljen sûnder de tsjinst te stopjen, wat wichtich is, bygelyks by it meitsjen fan upgrades, mar tagelyk hawwe jo in kâns dat beide knopen net nul binne. sil brekke tagelyk, en ek dat de folgjende de fernijing sil net gean sa soepel as de ferkeaper belooft (dit probleem kin foarkommen wurde as jo hawwe de mooglikheid om te testen de fernijing op laboratoarium apparatuer).
As jo gjin HA brûke, dan binne jo risiko's út it eachpunt fan dûbele mislearring folle leger (om't jo 2 ûnôfhinklike firewalls hawwe), mar sûnt ... sesjes wurde net syngronisearre, dan sille jo elke kear as jo wikselje tusken dizze firewalls ferkear ferlieze. Jo kinne fansels steatleaze firewalling brûke, mar dan is it punt fan it brûken fan in firewall foar in grut part ferlern.
Dêrom, as jo as gefolch fan 'e kontrôle iensume firewalls ûntdutsen hawwe, en jo tinke oan it fergrutsjen fan de betrouberens fan jo netwurk, dan is HA, fansels, ien fan' e oanbefellende oplossingen, mar jo moatte ek rekken hâlde mei de neidielen dy't ferbûn binne mei dizze oanpak en, miskien, spesifyk foar jo netwurk, soe in oare oplossing geskikter wêze.
Behearberens
Yn prinsipe giet HA ek om kontrolearberens. Yn stee fan it konfigurearjen fan 2 doazen apart en omgean mei it probleem fan it hâlden fan de konfiguraasjes yn syngronisaasje, jo beheare se folle as hiene jo ien apparaat.
Mar miskien hawwe jo in protte datasintra en in protte firewalls, dan komt dizze fraach op in nij nivo. En de fraach is net allinnich oer konfiguraasje, mar ek oer
- reservekopy konfiguraasjes
- updates
- upgrades
- tafersjoch
- logging
En dit alles kin wurde oplost troch sintralisearre behearsystemen.
Dus, bygelyks, as jo Palo Alto firewalls brûke, dan is sa'n oplossing.
To continue.
Boarne: www.habr.com