Dit artikel is de derde in een serie artikelen over "Hoe je je netwerk infrastructuur onder controle krijgt". De inhoud van alle artikelen in de serie en de links zijn te vinden hier.

Het heeft geen zin om te spreken over de volledige eliminatie van securityrisico's. We kunnen ze in principe niet tot nul verlagen. Ook moet men begrijpen dat naarmate we proberen het netwerk steeds veiliger te maken, onze oplossingen steeds duurder worden. Het is noodzakelijk om een redelijke compromis tussen prijs, complexiteit en veiligheid voor jouw netwerk te vinden.

Natuurlijk is het beveiligingsontwerp organisch ingebed in de algemene architectuur, en de gebruikte securityoplossingen beïnvloeden de schaalbaarheid, betrouwbaarheid, beheersbaarheid, ... van de netwerk infrastructuur, wat ook in overweging moet worden genomen.

Maar, ik herinner je eraan dat we op dit moment niet spreken over het creëren van een netwerk. In overeenstemming met onze aanvangsvoorwaarden is het ontwerp al gekozen, is de apparatuur geselecteerd en is de infrastructuur opgezet, en op dit punt moeten we, waar mogelijk, ‘leven’ en oplossingen vinden binnen de context van de eerder gekozen aanpak.

Onze taak nu is om de risico's in verband met beveiliging op netwerkniveau te identificeren en ze tot een redelijk niveau te verlagen.

Netwerkbeveiligingsaudits

Als in jouw organisatie de ISO 27k-processen zijn geïmplementeerd, moeten de audits van de beveiliging en netwerkveranderingen organisch worden geïntegreerd in de algemene processen binnen deze aanpak. Maar deze normen gaan nog steeds niet over specifieke oplossingen, niet over configuratie, niet over ontwerp... Er zijn geen eenduidige adviezen, er zijn geen normen die gedetailleerd voorschrijven hoe jouw netwerk eruit moet zien; dit is de complexiteit en schoonheid van deze taak.

Ik zou enkele mogelijke netwerkbeveiligingsaudits kunnen onderscheiden:

audit van de apparatuurconfiguratie (hardening)
audit van het securityontwerp
audit van toegangen
audit van processen

Audit van de apparatuurconfiguratie (hardening)

Het lijkt erop dat dit in de meeste gevallen het beste startpunt is voor de audit en verbetering van de veiligheid van jouw netwerk. IMHO, dit is een goede demonstratie van de Pareto-wet (20% inspanning levert 80% resultaat op, en de overige 80% inspanning levert slechts 20% resultaat op).

Het punt is dat we meestal aanbevelingen van leveranciers hebben met betrekking tot de "best practices" voor beveiliging bij het configureren van apparatuur. Dit wordt "hardening" genoemd.

Het is ook vaak mogelijk om een vragenlijst (of zelf te maken) op basis van deze aanbevelingen die u helpt bepalen in hoeverre de configuratie van uw apparatuur overeenkomt met deze 'beste praktijken' en op basis van de resultaten wijzigingen in uw netwerk aan te brengen. Dit stelt u in staat om de beveiligingsrisico's aanzienlijk te verlagen, eigenlijk zonder kosten.

Enkele voorbeelden voor verschillende Cisco-besturingssystemen.
Cisco IOS Configuratie Versterking
Cisco IOS-XR Configuratie Versterking
Cisco NX-OS Configuratie Versterking
Cisco Baseline Beveiligingscontrolelijst
Op basis van deze documenten kan een lijst van configuratievereisten voor elk type apparatuur worden opgesteld. Bijvoorbeeld, voor Cisco N7K VDC kunnen deze vereisten er als volgt uitzien zo.

Op deze manier kunnen configuratiebestanden worden aangemaakt voor verschillende soorten actieve apparatuur in uw netwerkstructuur. Vervolgens kunt u deze configuratiebestanden handmatig of met behulp van automatisering 'uploaden'. Hoe dit proces te automatiseren zal in een andere serie artikelen, gewijd aan orkestratie en automatisering, uitgebreid worden behandeld.

Audit van het beveiligingsontwerp

Gewoonlijk zijn in het netwerk van een onderneming de volgende segmenten op de een of andere manier aanwezig:

DC (Public services DMZ en Intranet datacenter)
Internettoegang
Remote access VPN
WAN rand
Filiaal
Campus (Kantoor)
Core

De namen zijn ontleend aan Cisco SAFE modellen, maar het is natuurlijk niet noodzakelijk om alleen aan deze namen en dit model te koppelen. Het is belangrijk om het op de essentie te hebben en niet vast te zitten in formaliteiten.

Voor elk van deze segmenten zullen de beveiligingseisen, risico's en daarmee samenhangende oplossingen verschillen.

Laten we elk van hen afzonderlijk bekijken op mogelijke problemen waarmee u kunt worden geconfronteerd vanuit het perspectief van beveiligingsontwerp. Uiteraard herhaal ik dat dit artikel op geen enkele manier pretendeert volledig te zijn; het is immers niet eenvoudig (of zelfs mogelijk) om dat te bereiken in dit werkelijk diepgaande en veelzijdige onderwerp, maar het weerspiegelt mijn persoonlijke ervaring.

Er is geen perfecte oplossing (in elk geval nu niet). Het is altijd een compromis. Maar het is belangrijk dat de beslissing om een bepaalde aanpak toe te passen bewust is genomen, met begrip van zowel de voordelen als de nadelen ervan.

Datacenter

Het meest kritiek segment vanuit beveiligingsperspectief.
En, zoals gebruikelijk, is er hier ook geen universele oplossing. Het hangt allemaal sterk af van de netwerkvereisten.

Is a firewall needed or not?

At first glance, the answer seems obvious, but everything is not as clear-cut as it may appear. Your choice may be influenced not only by price.

Example 1. Delays.
If low latency between certain segments of a network is a crucial requirement, which is true, for instance, in the case of an exchange, then we cannot use firewalls between these segments. It is difficult to find research on delays in firewalls, but only a few models of switches can provide delays of less than or around 1 μs, so I think that if microseconds are critical for you, then firewalls are not for you.

Example 2. Performance.
The throughput of top-level L3 switches is usually an order of magnitude higher than the throughput of the most powerful firewalls. Therefore, in the case of high-intensity traffic, you will likely need to route this traffic around firewalls.

Example 3. Reliability.
Firewalls, especially modern NGFWs (Next-Generation Firewalls), are complicated devices. They are significantly more complex than L3/L2 switches. They offer a large number of services and configuration options, so it is not surprising that their reliability is considerably lower. If continuity of service is critical for the network, you may have to choose what leads to better availability — security with a firewall or the simplicity of a network built on switches (or various types of fabrics) using standard ACLs.

In the case of the above examples, you will likely (as usual) need to find a compromise. Consider the following solutions:

if you decide not to use firewalls inside the data center, you need to think about how to maximize perimeter access restrictions. For example, you can allow only the necessary ports from the Internet (for client traffic) and administrative access to the data center only from jump hosts. Conduct all necessary checks (authentication/authorization, antivirus, logging, ...) on the jump hosts.
you can use logical segmentation of the data center network into segments, similar to the scheme described in PSEFABRIC example p002De routing moet zodanig zijn ingesteld dat latentiegevoelige of intensieve verkeer binnen één segment (in het geval van p002, de VRF) blijft en niet via de firewall gaat. Verkeer tussen verschillende segmenten zal echter nog steeds via de firewall gaan. Route leaking tussen VRF's kan ook worden gebruikt om ongewenste omleidingen via de firewall te voorkomen.
U kunt ook de firewall in transparante modus gebruiken, maar alleen voor die VLAN's waar deze factoren (latentie/prestaties) niet significant zijn. Het is echter belangrijk om de beperkingen die met deze modus gepaard gaan, voor elke leverancier zorgvuldig te bestuderen.
U kunt overwegen om een service chain-architectuur toe te passen. Dit stelt u in staat om alleen noodzakelijk verkeer via de firewall te leiden. Theoretisch klinkt het mooi, maar ik heb dit soort oplossing nog nooit in de productie gezien. Ongeveer drie jaar geleden hebben we service chain getest voor Cisco ACI/Juniper SRX/F5 LTM, maar op dat moment leek deze oplossing 'onderontwikkeld'.

Beschermingsniveau

U moet nu de vraag beantwoorden welke tools u wilt gebruiken voor verkeersfiltering. Hier zijn enkele mogelijkheden die doorgaans aanwezig zijn in NGFW (bijvoorbeeld: here):

stateful firewalling (standaard)
application firewalling
dreigingspreventie (antivirus, anti-spyware en kwetsbaarheid)
URL-filtering
gegevensfiltering (inhoudsfiltering)
bestand blokkering (blokkeren van bestandstypen)
dos-bescherming

En ook is het niet allemaal zo eenduidig. Het lijkt logisch dat naarmate het beschermingsniveau stijgt, de beveiliging beter wordt. Maar u moet ook in overweging nemen dat

hoe meer van de bovengenoemde firewallfuncties u gebruikt, hoe hoger de kosten zullen zijn (licenties, aanvullende modules).
Het gebruik van sommige algoritmen kan de doorvoersnelheid van de firewall aanzienlijk verlagen en ook de latentie verhogen, zie bijvoorbeeld here
zoals bij elke complexe oplossing, kan het gebruik van geavanceerde beveiligingsmethoden de betrouwbaarheid van uw oplossing verlagen, bijvoorbeeld bij het gebruik van application firewalling heb ik situaties meegemaakt waarin sommige standaardapplicaties (dns, smb) werden geblokkeerd.

U moet, zoals altijd, de optimale oplossing voor uw netwerk vinden.

Het is moeilijk om eenduidig te antwoorden op de vraag welke beveiligingsfuncties nodig zijn. Ten eerste hangt het natuurlijk af van de gegevens die je verzendt of opslaat en probeert te beschermen. Ten tweede is de keuze van beveiligingsmiddelen vaak een kwestie van vertrouwen in de leverancier. Je kent de algoritmes niet, weet niet hoe effectief ze zijn en kunt ze niet volledig testen.

In kritische segmenten kan het gebruik van oplossingen van verschillende bedrijven een goed idee zijn. Bijvoorbeeld, je kunt antivirussoftware op de firewall inschakelen, maar ook lokale antivirusbescherming (van een andere leverancier) op de hosts gebruiken.

Segmentatie

Het gaat om logische segmentatie van het datacenter netwerk. Bijvoorbeeld, het opdelen in VLAN's en subnetten is ook logische segmentatie, maar we zullen dat niet beschouwen vanwege de voor de hand liggende aard ervan. Interessant is de segmentatie rekening houdend met entiteiten zoals FW beveiligingszones, VRF (en hun equivalenten voor verschillende leveranciers), logische apparaten (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant, ...), ...

Een voorbeeld van een dergelijke logische segmentatie en het momenteel gewilde ontwerp van een datacenter wordt gegeven in p002 van het PSEFABRIC project.

Nadat je de logische delen van je netwerk hebt gedefinieerd, kun je beschrijven hoe het verkeer tussen de verschillende segmenten beweegt, op welke apparaten filtering zal plaatsvinden en met welke middelen.

Als je netwerk geen duidelijke logische onderverdeling heeft en de regels voor het toepassen van beveiligingsbeleid voor verschillende datastromen niet zijn geformaliseerd, betekent dit dat je deze taak opnieuw moet oplossen bij het openen van een bepaalde toegang, en met grote waarschijnlijkheid elke keer op een andere manier.

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

Welke beveiligingszones heb je nodig?
Welches niveau van beveiliging wil je toepassen op elk van deze zones?
Zal intra-zone verkeer standaard zijn toegestaan?
Zo niet, welke verkeersfilteringsbeleid zullen intern binnen elke zone toegepast worden?
Welke verkeersfilteringsbeleid zullen toegepast worden voor elk paar zones (bron/bestemming)?

TCAM

Het probleem van onvoldoende TCAM (Ternary Content Addressable Memory) komt vaak voor, zowel voor routering als voor toegang. IMHO is dit een van de belangrijkste vragen bij de keuze van hardware, daarom moet deze kwestie met de nodige zorgvuldigheid worden behandeld.

Voorbeeld 1. Forwarding Table TCAM.
Laten we kijken naar Palo Alto 7k firewall.
We zien dat de IPv4 forwarding table size* = 32K
Dit aantal routes is echter het totaal voor alle VSYS'en.
Stel dat u volgens uw ontwerp heeft besloten om 4 VSYS'en te gebruiken.
Elke van deze VSYS'en is via BGP verbonden met twee PE MPLS-clouds, die u als BB gebruikt. Zo ruilen 4 VSYS'en alle specifieke routes met elkaar uit en hebben ze een forwarding table met ongeveer dezelfde set routes (maar verschillende NH). Aangezien elke VSYS 2 BGP-sessies heeft (met dezelfde instellingen), heeft elke route die via MPLS wordt verkregen 2 NH en dus 2 FIB-records in de Forwarding Table. Als we aannemen dat dit de enige firewall in het datacenter is en deze op de hoogte moet zijn van alle routes, betekent dit dat het totale aantal routes in ons datacenter niet meer kan zijn dan 32K/(4 * 2) = 4K.
Nu, als we aannemen dat we 2 datacenters hebben (met hetzelfde ontwerp) en we VLAN's willen gebruiken die "uitgerekt" zijn tussen de datacenters (bijvoorbeeld voor vMotion), dan moeten we hostroutes gebruiken om het routeringsprobleem op te lossen. Maar dit betekent dat we in 2 datacenters niet meer dan 4096 mogelijke hosts hebben en dat kan natuurlijk onvoldoende zijn.

Voorbeeld 2. ACL TCAM.
Als u van plan bent om verkeer te filteren op L3-switches (of andere oplossingen die L3-switches gebruiken, zoals Cisco ACI), moet u bij de keuze van hardware letten op ACL TCAM.
Stel dat u de toegang op SVI-interfaces van Cisco Catalyst 4500 wilt controleren. Dan, zoals blijkt uit dit artikel, voor het controleren van uitgaand (net zoals binnenkomend) verkeer op de interfaces kunt u slechts 4096 regels TCAM gebruiken. Wat bij het gebruik van TCAM3 u ongeveer 4000 ACE (regels ACL) zal opleveren.

Als je te maken hebt met een probleem van onvoldoende TCAM, moet je in de eerste plaats kijken naar de mogelijkheid van optimalisatie. In het geval van een probleem met de grootte van de Forwarding Table, moet je overwegen om routes te aggregeren. Als er problemen zijn met de grootte van de TCAM voor toegang, voer dan een audit van de toegang uit, verwijder verouderde en overlappende vermeldingen, en overweeg misschien de procedure voor het openen van toegang te herzien (dit wordt uitvoerig behandeld in het hoofdstuk dat aan de audit van toegang is gewijd).

Hoge Beschikbaarheid

De vraag is of je HA voor firewalls moet gebruiken of twee onafhankelijke apparaten 'parallel' moet plaatsen en, bij het uitvallen van een van hen, het verkeer via de andere moet routeren?

Schijnbaar is het antwoord duidelijk: gebruik HA. De reden waarom deze vraag echter opkomt, is dat, helaas, de theoretische en reclame 99 en enkele negens achter de komma van beschikbaarheid in de praktijk vaak niet zo rooskleurig blijken te zijn. HA is logisch gezien vrij complex, en met verschillende apparatuur en verschillende leveranciers (er waren geen uitzonderingen) hebben we problemen, fouten en serviceonderbrekingen ondervonden.

Als je HA gebruikt, heb je de mogelijkheid om afzonderlijke nodes uit te schakelen en tussen hen over te schakelen zonder de service te onderbreken, wat belangrijk is, bijvoorbeeld bij upgrades. Maar je hebt een ver van nul kans dat beide nodes tegelijkertijd falen, en dat de volgende upgrade niet zo soepel verloopt als de leverancier belooft (dit probleem kan worden vermeden als je de upgrade op laboratoriumapparatuur kunt testen).

Als je geen HA gebruikt, zijn je risico's wat betreft dubbele uitval aanzienlijk lager (aangezien je 2 onafhankelijke firewalls hebt), maar omdat de sessies niet zijn gesynchroniseerd, verlies je telkens je verkeer als je tussen deze firewalls schakelt. Je kunt natuurlijk stateless firewalling gebruiken, maar dan verliest het gebruik van een firewall veel van zijn nut.

Als u tijdens de audit alleenstaande firewalls hebt ontdekt en u overweegt om de betrouwbaarheid van uw netwerk te vergroten, dan is HA zeker een van de aanbevolen oplossingen. U moet echter ook de nadelen van deze aanpak in overweging nemen en mogelijk is er voor uw netwerk een andere oplossing geschikter.

Beheerbaarheid

Over het algemeen gaat HA ook over beheersbaarheid. In plaats van twee apparaten afzonderlijk te configureren en het probleem van configuratiesynchronisatie op te lossen, beheert u ze grotendeels alsof u één apparaat hebt.

Maar misschien heeft u veel datacenters en veel firewalls, dan komt deze kwestie op een nieuw niveau. En het gaat niet alleen om configuratie, maar ook om