Dit artikel is het derde in een reeks artikelen ‘Hoe u de controle over uw netwerkinfrastructuur overneemt’. De inhoud van alle artikelen in de serie en links zijn te vinden hier.

Het heeft geen zin om te praten over het volledig elimineren van veiligheidsrisico's. In principe kunnen we ze niet tot nul terugbrengen. We moeten ook begrijpen dat naarmate we ernaar streven het netwerk steeds veiliger te maken, onze oplossingen steeds duurder worden. U moet een afweging maken tussen kosten, complexiteit en beveiliging die zinvol is voor uw netwerk.

Uiteraard is het beveiligingsontwerp organisch geïntegreerd in de algemene architectuur en hebben de gebruikte beveiligingsoplossingen invloed op de schaalbaarheid, betrouwbaarheid, beheersbaarheid, ... van de netwerkinfrastructuur, waarmee ook rekening moet worden gehouden.

Maar laat me je eraan herinneren dat we het nu niet hebben over het creëren van een netwerk. Volgens onze begincondities we hebben het ontwerp al gekozen, de apparatuur geselecteerd en de infrastructuur gecreëerd, en in dit stadium moeten we, indien mogelijk, “leven” en oplossingen vinden in de context van de eerder gekozen aanpak.

Onze taak is nu om de risico's die verband houden met de beveiliging op netwerkniveau te identificeren en deze tot een redelijk niveau terug te brengen.

Netwerkbeveiligingsaudit

Als uw organisatie ISO 27k-processen heeft geïmplementeerd, moeten beveiligingsaudits en netwerkwijzigingen naadloos passen in de algehele processen binnen deze aanpak. Maar deze standaarden gaan nog steeds niet over specifieke oplossingen, niet over configuratie, niet over ontwerp... Er zijn geen duidelijk advies, geen standaarden die in detail dicteren hoe uw netwerk eruit zou moeten zien, dit is de complexiteit en schoonheid van deze taak.

Ik zou verschillende mogelijke netwerkbeveiligingsaudits willen benadrukken:

• audit van apparatuurconfiguratie (verharding)
• audit van het beveiligingsontwerp
• toegangscontrole
• procesaudit

Audit van apparatuurconfiguratie (verharding)

Het lijkt erop dat dit in de meeste gevallen het beste startpunt is voor het controleren en verbeteren van de beveiliging van uw netwerk. IMHO, dit is een goede demonstratie van de wet van Pareto (20% van de inspanning levert 80% van het resultaat op, en de resterende 80% van de inspanning levert slechts 20% van het resultaat op).

Het komt erop neer dat we meestal aanbevelingen krijgen van leveranciers met betrekking tot ‘best practices’ voor beveiliging bij het configureren van apparatuur. Dit wordt “verharding” genoemd.

Vaak kunt u op basis van deze aanbevelingen ook een vragenlijst vinden (of er zelf een maken) waarmee u kunt bepalen in hoeverre de configuratie van uw apparatuur voldoet aan deze ‘best practices’ en, in overeenstemming met het resultaat, wijzigingen kunt aanbrengen in uw netwerk. . Hiermee kunt u de beveiligingsrisico's vrij eenvoudig en vrijwel kosteloos aanzienlijk verminderen.

Verschillende voorbeelden voor sommige Cisco-besturingssystemen.

Cisco IOS-configuratieverharding
Cisco IOS-XR-configuratieverharding
Cisco NX-OS-configuratieverharding
Cisco Baseline-beveiligingscontrolelijst

Op basis van deze documenten kan voor elk type apparatuur een lijst met configuratievereisten worden opgesteld. Voor een Cisco N7K VDC kunnen deze vereisten er bijvoorbeeld uitzien zo.

Op deze manier kunnen configuratiebestanden worden aangemaakt voor verschillende soorten actieve apparatuur in uw netwerkinfrastructuur. Vervolgens kunt u handmatig of geautomatiseerd deze configuratiebestanden “uploaden”. Hoe dit proces te automatiseren zal in detail worden besproken in een andere reeks artikelen over orkestratie en automatisering.

Audit van het beveiligingsontwerp

Normaal gesproken bevat een bedrijfsnetwerk de volgende segmenten in een of andere vorm:

• DC (Publieke diensten DMZ en intranetdatacenter)
• Internettoegang
• VPN voor externe toegang
• WAN-rand
• Tak
• Campus (Kantoor)
• Kern

Titels overgenomen van Cisco VEILIG model, maar het is uiteraard niet nodig om precies aan deze namen en aan dit model te hechten. Toch wil ik het hebben over de essentie en niet verzanden in formaliteiten.

Voor elk van deze segmenten zullen de beveiligingsvereisten, risico's en dus ook de oplossingen verschillend zijn.

Laten we ze allemaal afzonderlijk bekijken en kijken naar de problemen die u kunt tegenkomen vanuit het oogpunt van beveiligingsontwerp. Natuurlijk herhaal ik nogmaals dat dit artikel op geen enkele manier pretendeert volledig te zijn, wat niet gemakkelijk (zo niet onmogelijk) te bereiken is in dit werkelijk diepgaande en veelzijdige onderwerp, maar het weerspiegelt mijn persoonlijke ervaring.

Er bestaat geen perfecte oplossing (althans nog niet). Het is altijd een compromis. Maar het is belangrijk dat de beslissing om de ene of de andere aanpak te gebruiken bewust wordt genomen, met inzicht in zowel de voor- als nadelen ervan.

Data Center

Het meest kritische segment vanuit veiligheidsoogpunt.
En zoals gewoonlijk is er ook hier geen universele oplossing. Het hangt allemaal sterk af van de netwerkvereisten.

Is een firewall nodig of niet?

Het lijkt erop dat het antwoord voor de hand ligt, maar alles is niet zo duidelijk als het lijkt. En uw keuze kan niet alleen worden beïnvloed prijs.

Voorbeeld 1. Vertragingen.

Als een lage latentie een essentiële vereiste is tussen sommige netwerksegmenten, wat bijvoorbeeld het geval is bij een uitwisseling, dan zullen we geen firewalls tussen deze segmenten kunnen gebruiken. Het is moeilijk om studies te vinden over de latentie in firewalls, maar weinig switchmodellen kunnen een latentie van minder dan of in de orde van 1 mksec bieden, dus ik denk dat als microseconden belangrijk voor je zijn, firewalls niets voor jou zijn.

Voorbeeld 2. Prestaties.

De doorvoer van de beste L3-switches is doorgaans een orde van grootte hoger dan de doorvoer van de krachtigste firewalls. Daarom zult u bij verkeer met een hoge intensiteit hoogstwaarschijnlijk ook moeten toestaan ​​dat dit verkeer de firewalls omzeilt.

Voorbeeld 3. Betrouwbaarheid.

Firewalls, vooral moderne NGFW (Next-Generation FW), zijn complexe apparaten. Ze zijn veel complexer dan L3/L2-schakelaars. Ze bieden een groot aantal services en configuratiemogelijkheden, dus het is niet verrassend dat hun betrouwbaarheid veel lager is. Als servicecontinuïteit van cruciaal belang is voor het netwerk, moet u wellicht kiezen wat tot een betere beschikbaarheid zal leiden: beveiliging met een firewall of de eenvoud van een netwerk dat is gebouwd op switches (of verschillende soorten fabrics) met behulp van reguliere ACL's.

In het geval van de bovenstaande voorbeelden zult u hoogstwaarschijnlijk (zoals gewoonlijk) een compromis moeten vinden. Kijk naar de volgende oplossingen:

• als u besluit geen firewalls in het datacenter te gebruiken, moet u nadenken over hoe u de toegang rond de perimeter zoveel mogelijk kunt beperken. U kunt bijvoorbeeld alleen de noodzakelijke poorten vanaf internet openen (voor clientverkeer) en administratieve toegang tot het datacenter alleen vanaf jumphosts. Voer op jumphosts alle noodzakelijke controles uit (authenticatie/autorisatie, antivirus, loggen, ...)
• u kunt een logische partitie van het datacenternetwerk in segmenten gebruiken, vergelijkbaar met het schema beschreven in PSEFABRIC voorbeeld p002. In dit geval moet de routering zo worden geconfigureerd dat vertragingsgevoelig of hoogintensief verkeer “binnen” één segment gaat (in het geval van p002, VRF) en niet door de firewall gaat. Verkeer tussen verschillende segmenten blijft door de firewall gaan. U kunt ook routelekken tussen VRF's gebruiken om te voorkomen dat verkeer via de firewall wordt omgeleid
• U kunt ook een firewall in transparante modus gebruiken en alleen voor die VLAN's waar deze factoren (latency/prestaties) niet significant zijn. Maar u moet de beperkingen die aan het gebruik van deze mod zijn verbonden, voor elke leverancier zorgvuldig bestuderen
• Misschien wilt u overwegen een serviceketenarchitectuur te gebruiken. Hierdoor kan alleen het noodzakelijke verkeer door de firewall gaan. Ziet er in theorie mooi uit, maar ik heb deze oplossing nog nooit in productie gezien. We hebben de serviceketen voor Cisco ACI/Juniper SRX/F5 LTM ongeveer drie jaar geleden getest, maar destijds leek deze oplossing ons 'ruw'.

Beveiligingsniveau

Nu moet u de vraag beantwoorden welke tools u wilt gebruiken om verkeer te filteren. Hier zijn enkele van de functies die gewoonlijk aanwezig zijn in NGFW (bijvoorbeeld hier):

• stateful firewalling (standaard)
• firewalling van toepassingen
• preventie van bedreigingen (antivirus, anti-spyware en kwetsbaarheid)
• URL-filtering
• gegevensfiltering (inhoudsfiltering)
• bestandsblokkering (blokkering van bestandstypen)
• dos bescherming

En ook niet alles is duidelijk. Het lijkt erop dat hoe hoger het beschermingsniveau, hoe beter. Maar dat moet je ook overwegen

• Hoe meer van bovenstaande firewallfuncties u gebruikt, hoe duurder het uiteraard wordt (licenties, extra modules)
• het gebruik van sommige algoritmen kan de doorvoer van de firewall aanzienlijk verminderen en ook de vertragingen vergroten, zie bijvoorbeeld hier
• Zoals bij elke complexe oplossing kan het gebruik van complexe beveiligingsmethoden de betrouwbaarheid van uw oplossing verminderen. Bij het gebruik van applicatiefirewalls kwam ik bijvoorbeeld het blokkeren tegen van een aantal vrij standaard werkende applicaties (dns, smb)

Zoals altijd moet u de beste oplossing voor uw netwerk vinden.

Het is onmogelijk om definitief een antwoord te geven op de vraag welke beveiligingsfuncties nodig kunnen zijn. Ten eerste omdat het natuurlijk afhangt van de gegevens die u verzendt of opslaat en probeert te beschermen. Ten tweede is de keuze van beveiligingstools in werkelijkheid vaak een kwestie van geloof en vertrouwen in de leverancier. Je kent de algoritmen niet, je weet niet hoe effectief ze zijn, en je kunt ze niet volledig testen.

Daarom kan het in kritieke segmenten een goede oplossing zijn om aanbiedingen van verschillende bedrijven te gebruiken. U kunt bijvoorbeeld antivirus op de firewall inschakelen, maar ook lokaal op de hosts antivirusbescherming (van een andere fabrikant) gebruiken.

Segmentatie

We hebben het over de logische segmentatie van het datacenternetwerk. Het opsplitsen in VLAN's en subnetten is bijvoorbeeld ook een logische segmentatie, maar we zullen dit vanwege de voor de hand liggend niet in overweging nemen. Interessante segmentatie waarbij rekening wordt gehouden met entiteiten als FW-beveiligingszones, VRF's (en hun analogen in relatie tot verschillende leveranciers), logische apparaten (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant, ...), ...

Een voorbeeld van een dergelijke logische segmentatie en het momenteel veelgevraagde datacenterontwerp wordt gegeven in p002 van het PSEFABRIC-project.

Nadat u de logische delen van uw netwerk heeft gedefinieerd, kunt u beschrijven hoe het verkeer zich tussen verschillende segmenten beweegt, op welke apparaten er wordt gefilterd en op welke manier.

Als uw netwerk geen duidelijke logische partitie heeft en de regels voor het toepassen van beveiligingsbeleid voor verschillende gegevensstromen niet geformaliseerd zijn, betekent dit dat wanneer u deze of gene toegang opent, u gedwongen wordt dit probleem op te lossen, en met grote waarschijnlijkheid zult u zal het elke keer anders oplossen.

Vaak is segmentatie alleen gebaseerd op FW-beveiligingszones. Dan moet u de volgende vragen beantwoorden:

• welke beveiligingszones heb je nodig
• welk beschermingsniveau wilt u toepassen op elk van deze zones?
• Zal verkeer binnen een zone standaard worden toegestaan?
• Zo niet, welk verkeersfilterbeleid wordt er binnen elke zone toegepast?
• welk verkeersfilterbeleid wordt toegepast voor elk paar zones (bron/bestemming)

TCAM

Een veelvoorkomend probleem is onvoldoende TCAM (Ternary Content Addressable Memory), zowel voor routering als voor toegang. IMHO, dit is een van de belangrijkste kwesties bij het kiezen van apparatuur, dus u moet dit probleem met de juiste mate van zorg behandelen.

Voorbeeld 1. Doorstuurtabel TCAM.

Laten we overwegen Palo Alto 7k firewall
We zien dat de grootte van de IPv4-doorstuurtabel* = 32K
Bovendien is dit aantal routes gemeenschappelijk voor alle VSYS's.

Laten we aannemen dat u, op basis van uw ontwerp, besluit 4 VSYS te gebruiken.
Elk van deze VSYS's is via BGP verbonden met twee MPLS PE's van de cloud die je als BB gebruikt. Zo wisselen 4 VSYS alle specifieke routes met elkaar uit en hebben ze een doorstuurtabel met ongeveer dezelfde sets routes (maar verschillende NH's). Omdat elke VSYS heeft 2 BGP-sessies (met dezelfde instellingen), vervolgens heeft elke via MPLS ontvangen route 2 NH en dienovereenkomstig 2 FIB-vermeldingen in de doorstuurtabel. Als we ervan uitgaan dat dit de enige firewall in het datacenter is en alle routes moet kennen, betekent dit dat het totale aantal routes in ons datacenter niet meer dan 32K/(4 * 2) = 4K mag zijn.

Als we nu aannemen dat we twee datacenters hebben (met hetzelfde ontwerp) en we VLAN's willen gebruiken die zijn "uitgerekt" tussen datacenters (bijvoorbeeld voor vMotion), dan moeten we om het routeringsprobleem op te lossen hostroutes gebruiken . Maar dit betekent dat we voor 2 datacenters niet meer dan 2 mogelijke hosts zullen hebben, en dit is natuurlijk misschien niet genoeg.

Voorbeeld 2. ACL TCAM.

Als u van plan bent verkeer op L3-switches te filteren (of andere oplossingen die L3-switches gebruiken, bijvoorbeeld Cisco ACI), moet u bij het kiezen van apparatuur letten op de TCAM ACL.

Stel dat u de toegang op de SVI-interfaces van de Cisco Catalyst 4500 wilt controleren. Dan kunt u, zoals blijkt uit dit artikel, om uitgaand (en inkomend) verkeer op interfaces te controleren, kunt u slechts 4096 TCAM-lijnen gebruiken. Wat u bij gebruik van TCAM3 ongeveer 4000 ACE's (ACL-lijnen) oplevert.

Als u wordt geconfronteerd met het probleem van onvoldoende TCAM, moet u natuurlijk allereerst de mogelijkheid van optimalisatie overwegen. Dus als er een probleem is met de grootte van de doorstuurtabel, moet u de mogelijkheid overwegen om routes te aggregeren. In het geval van een probleem met de TCAM-grootte voor toegang, controleer dan de toegang, verwijder verouderde en overlappende records en herzie eventueel de procedure voor het openen van toegang (zal in detail worden besproken in het hoofdstuk over het controleren van toegang).

Hoge beschikbaarheid

De vraag is: moet ik HA gebruiken voor firewalls of moet ik twee onafhankelijke boxen “parallel” installeren en, als een van de twee faalt, het verkeer via de tweede routeren?

Het lijkt erop dat het antwoord voor de hand ligt: ​​gebruik HA. De reden waarom deze vraag nog steeds rijst is dat de theoretische en reclame-99 en enkele decimale percentages van toegankelijkheid in de praktijk helaas verre van zo rooskleurig blijken te zijn. HA is logischerwijs een behoorlijk complex iets, en op verschillende apparatuur en bij verschillende leveranciers (er waren geen uitzonderingen) kwamen we problemen, bugs en servicestops tegen.

Als u HA gebruikt, heeft u de mogelijkheid om afzonderlijke knooppunten uit te schakelen en ertussen te schakelen zonder de service te stoppen, wat bijvoorbeeld belangrijk is bij het uitvoeren van upgrades, maar tegelijkertijd is de kans verre van nul dat beide knooppunten tegelijkertijd kapot zal gaan, en ook dat de upgrade de volgende keer niet zo soepel zal verlopen als de leverancier belooft (dit probleem kan worden vermeden als u de mogelijkheid heeft om de upgrade op laboratoriumapparatuur te testen).

Als je geen HA gebruikt, dan zijn je risico's vanuit het oogpunt van dubbele mislukking veel lager (aangezien je 2 onafhankelijke firewalls hebt), maar aangezien... sessies niet gesynchroniseerd zijn, verliest u elke keer dat u tussen deze firewalls schakelt verkeer. Je kunt uiteraard gebruik maken van stateless firewalling, maar dan gaat het nut van het gebruik van een firewall grotendeels verloren.

Daarom, als u als resultaat van de audit eenzame firewalls heeft ontdekt en u overweegt de betrouwbaarheid van uw netwerk te vergroten, dan is HA uiteraard een van de aanbevolen oplossingen, maar u moet ook rekening houden met de daaraan verbonden nadelen. Met deze aanpak en misschien specifiek voor uw netwerk zou een andere oplossing geschikter zijn.

Beheersbaarheid

HA gaat in principe ook over beheersbaarheid. In plaats van twee boxen afzonderlijk te configureren en het probleem op te lossen van het gesynchroniseerd houden van de configuraties, beheert u ze alsof u één apparaat heeft.

Maar misschien heb je veel datacenters en veel firewalls, dan rijst deze vraag op een nieuw niveau. En de vraag gaat niet alleen over de configuratie, maar ook over

• back-upconfiguraties
• updates
• upgrades
• toezicht houden
• loggen

En dit alles kan worden opgelost door gecentraliseerde beheersystemen.

Dus als u bijvoorbeeld Palo Alto-firewalls gebruikt, dan Panorama is zo’n oplossing.

Worden voortgezet.

Bron: www.habr.com