Den här artikeln är den tredje i en serie artiklar "Hur du tar kontroll över din nätverksinfrastruktur." Innehållet i alla artiklar i serien och länkar finns här.

Det är ingen idé att prata om att helt eliminera säkerhetsrisker. Vi kan i princip inte reducera dem till noll. Vi måste också förstå att när vi strävar efter att göra nätverket säkrare och säkrare, så blir våra lösningar dyrare och dyrare. Du måste hitta en avvägning mellan kostnad, komplexitet och säkerhet som är vettig för ditt nätverk.

Självklart är säkerhetsdesign organiskt integrerad i den övergripande arkitekturen och de säkerhetslösningar som används påverkar skalbarheten, tillförlitligheten, hanterbarheten, ... hos nätverksinfrastrukturen, vilket också bör beaktas.

Men låt mig påminna om att nu pratar vi inte om att skapa ett nätverk. Enligt vår initiala förhållanden vi har redan valt design, valt utrustning och skapat infrastrukturen, och i detta skede bör vi om möjligt "leva" och hitta lösningar inom ramen för det tidigare valda tillvägagångssättet.

Vår uppgift är nu att identifiera riskerna förknippade med säkerhet på nätverksnivå och reducera dem till en rimlig nivå.

Granskning av nätverkssäkerhet

Om din organisation har implementerat ISO 27k-processer, bör säkerhetsrevisioner och nätverksförändringar passa sömlöst in i de övergripande processerna inom detta tillvägagångssätt. Men dessa standarder handlar fortfarande inte om specifika lösningar, inte om konfiguration, inte om design... Det finns inga tydliga råd, inga standarder som i detalj dikterar hur ditt nätverk ska se ut, det här är komplexiteten och skönheten i denna uppgift.

Jag skulle lyfta fram flera möjliga nätverkssäkerhetsrevisioner:

• granskning av utrustningskonfiguration (härdning)
• revision av säkerhetsdesign
• åtkomstrevision
• processrevision

Granskning av utrustningskonfiguration (härdning)

Det verkar som om detta i de flesta fall är den bästa utgångspunkten för att granska och förbättra säkerheten i ditt nätverk. IMHO, detta är en bra demonstration av Paretos lag (20 % av ansträngningen ger 80 % av resultatet, och de återstående 80 % av ansträngningen ger bara 20 % av resultatet).

Summan av kardemumman är att vi vanligtvis har rekommendationer från leverantörer angående "bästa praxis" för säkerhet vid konfigurering av utrustning. Detta kallas "härdning".

Du kan också ofta hitta ett frågeformulär (eller skapa ett själv) baserat på dessa rekommendationer, som hjälper dig att avgöra hur väl konfigurationen av din utrustning överensstämmer med dessa "bästa praxis" och, i enlighet med resultatet, göra ändringar i ditt nätverk . Detta gör att du kan minska säkerhetsriskerna avsevärt ganska enkelt, praktiskt taget utan kostnad.

Flera exempel för vissa Cisco-operativsystem.

Cisco IOS-konfigurationshärdning
Cisco IOS-XR-konfigurationshärdning
Cisco NX-OS-konfigurationshärdning
Cisco Baseline Security Checklista

Baserat på dessa dokument kan en lista över konfigurationskrav för varje typ av utrustning skapas. Till exempel, för en Cisco N7K VDC kan dessa krav se ut så.

På så sätt kan konfigurationsfiler skapas för olika typer av aktiv utrustning i din nätverksinfrastruktur. Därefter, manuellt eller med hjälp av automatisering, kan du "ladda upp" dessa konfigurationsfiler. Hur man automatiserar denna process kommer att diskuteras i detalj i en annan serie artiklar om orkestrering och automatisering.

Revision av säkerhetsdesign

Vanligtvis innehåller ett företagsnätverk följande segment i en eller annan form:

• DC (Offentliga tjänster DMZ och Intranet datacenter)
• Tillgång till Internet
• Fjärråtkomst VPN
• WAN-kant
• Branch
• Campus (kontor)
• Kärna

Titlar hämtade från Cisco SAFE modell, men det är naturligtvis inte nödvändigt att vara knuten till dessa namn och till denna modell. Ändå vill jag prata om essensen och inte fastna i formaliteter.

För vart och ett av dessa segment kommer säkerhetskraven, riskerna och därmed lösningarna att vara olika.

Låt oss titta på var och en av dem separat för de problem som du kan stöta på ur säkerhetsdesignsynpunkt. Naturligtvis upprepar jag igen att den här artikeln inte på något sätt låtsas vara komplett, vilket inte är lätt (om inte omöjligt) att uppnå i detta verkligt djupa och mångfacetterade ämne, men den speglar min personliga erfarenhet.

Det finns ingen perfekt lösning (åtminstone inte än). Det är alltid en kompromiss. Men det är viktigt att beslutet att använda ett eller annat tillvägagångssätt görs medvetet, med förståelse för både dess för- och nackdelar.

Data Center

Det mest kritiska segmentet ur säkerhetssynpunkt.
Och här finns som vanligt ingen universallösning heller. Allt beror mycket på nätverkskraven.

Är en brandvägg nödvändig eller inte?

Det verkar som att svaret är uppenbart, men allt är inte riktigt så klart som det kan verka. Och ditt val kan inte bara påverkas pris.

Exempel 1. Förseningar.

Om låg latens är ett väsentligt krav mellan vissa nätverkssegment, vilket till exempel är sant i fallet med ett utbyte, så kommer vi inte att kunna använda brandväggar mellan dessa segment. Det är svårt att hitta studier om latens i brandväggar, men få switchmodeller kan ge latens på mindre än eller i storleksordningen 1 mksec, så jag tror att om mikrosekunder är viktiga för dig så är brandväggar inte något för dig.

Exempel 2. Prestanda.

Genomströmningen av topp L3-switchar är vanligtvis en storleksordning högre än genomströmningen för de mest kraftfulla brandväggarna. Därför, i fallet med högintensiv trafik, måste du också med största sannolikhet tillåta denna trafik att kringgå brandväggar.

Exempel 3. Tillförlitlighet.

Brandväggar, särskilt moderna NGFW (Next-Generation FW) är komplexa enheter. De är mycket mer komplexa än L3/L2-switchar. De tillhandahåller ett stort antal tjänster och konfigurationsalternativ, så det är inte förvånande att deras tillförlitlighet är mycket lägre. Om tjänstekontinuitet är avgörande för nätverket kan du behöva välja vad som leder till bättre tillgänglighet - säkerhet med en brandvägg eller enkelheten hos ett nätverk byggt på switchar (eller olika typer av tyger) som använder vanliga ACL:er.

När det gäller ovanstående exempel kommer du med största sannolikhet (som vanligt) att behöva hitta en kompromiss. Titta på följande lösningar:

• om du bestämmer dig för att inte använda brandväggar inuti datacentret måste du tänka på hur du kan begränsa åtkomsten runt omkretsen så mycket som möjligt. Till exempel kan du endast öppna de nödvändiga portarna från Internet (för klienttrafik) och administrativ åtkomst till datacentret endast från hoppvärdar. På hoppvärdar, utför alla nödvändiga kontroller (autentisering/auktorisering, antivirus, loggning, ...)
• du kan använda en logisk partition av datacenternätverket i segment, liknande det schema som beskrivs i PSEFABRIC exempel p002. I det här fallet måste routing konfigureras på ett sådant sätt att fördröjningskänslig eller högintensiv trafik går "inom" ett segment (i fallet med p002, VRF) och inte går genom brandväggen. Trafiken mellan olika segment kommer att fortsätta att gå genom brandväggen. Du kan också använda ruttläckage mellan VRF:er för att undvika att omdirigera trafik genom brandväggen
• Du kan också använda en brandvägg i transparent läge och endast för de VLAN där dessa faktorer (latens/prestanda) inte är signifikanta. Men du måste noggrant studera begränsningarna i samband med användningen av denna mod för varje leverantör
• du kanske vill överväga att använda en servicekedjearkitektur. Detta tillåter endast nödvändig trafik att passera genom brandväggen. Ser bra ut i teorin, men jag har aldrig sett den här lösningen i produktion. Vi testade servicekedjan för Cisco ACI/Juniper SRX/F5 LTM för cirka 3 år sedan, men på den tiden verkade den här lösningen "rå" för oss.

Skyddsnivå

Nu måste du svara på frågan om vilka verktyg du vill använda för att filtrera trafik. Här är några av funktionerna som vanligtvis finns i NGFW (till exempel, här):

• stateful brandvägg (standard)
• applikationsbrandvägg
• hotförebyggande (antivirus, antispionprogram och sårbarhet)
• URL -filtrering
• datafiltrering (innehållsfiltrering)
• filblockering (filtypsblockering)
• dos skydd

Och allt är inte heller klart. Det verkar som att ju högre skyddsnivå desto bättre. Men du måste också tänka på det

• Ju fler av ovanstående brandväggsfunktioner du använder, desto dyrare blir det naturligtvis (licenser, tilläggsmoduler)
• användningen av vissa algoritmer kan avsevärt minska brandväggens genomströmning och även öka förseningarna, se t.ex här
• precis som alla komplexa lösningar kan användningen av komplexa skyddsmetoder minska tillförlitligheten hos din lösning, till exempel när jag använder applikationsbrandvägg, stötte jag på blockering av några ganska vanliga fungerande applikationer (dns, smb)

Som alltid måste du hitta den bästa lösningen för ditt nätverk.

Det är omöjligt att definitivt svara på frågan om vilka skyddsfunktioner som kan krävas. För det första eftersom det naturligtvis beror på vilken data du överför eller lagrar och försöker skydda. För det andra, i verkligheten är valet av säkerhetsverktyg ofta en fråga om tro och tillit till leverantören. Du känner inte till algoritmerna, du vet inte hur effektiva de är och du kan inte testa dem fullt ut.

Därför kan en bra lösning i kritiska segment vara att använda erbjudanden från olika företag. Du kan till exempel aktivera antivirus på brandväggen, men även använda antivirusskydd (från annan tillverkare) lokalt på värdarna.

Segmentering

Vi talar om den logiska segmenteringen av datacenternätverket. Till exempel är partitionering i VLAN och subnät också logisk segmentering, men vi kommer inte att överväga det på grund av dess självklarhet. Intressant segmentering med hänsyn till sådana enheter som FW-säkerhetszoner, VRF:er (och deras analoger i förhållande till olika leverantörer), logiska enheter (PA VSYS, Cisco N7K VDC, Cisco ACI Tenant, ...), ...

Ett exempel på sådan logisk segmentering och den för närvarande efterfrågade datacenterdesignen ges i p002 i PSEFABRIC-projektet.

Efter att ha definierat de logiska delarna av ditt nätverk kan du sedan beskriva hur trafiken rör sig mellan olika segment, på vilka enheter filtrering kommer att utföras och med vilka medel.

Om ditt nätverk inte har en tydlig logisk partition och reglerna för att tillämpa säkerhetspolicyer för olika dataflöden inte är formaliserade, betyder det att när du öppnar den eller den åtkomsten tvingas du lösa detta problem, och med stor sannolikhet kommer att lösa det olika varje gång.

Ofta baseras segmenteringen endast på FW-säkerhetszoner. Då måste du svara på följande frågor:

• vilka säkerhetszoner behöver du
• vilken skyddsnivå vill du tillämpa för var och en av dessa zoner
• kommer trafik inom zonen att tillåtas som standard?
• Om inte, vilka policyer för trafikfiltrering kommer att tillämpas inom varje zon
• vilka trafikfiltreringspolicyer som kommer att tillämpas för varje par av zoner (källa/destination)

TCAM

Ett vanligt problem är otillräckligt TCAM (Ternary Content Addressable Memory), både för routing och för åtkomster. IMHO, detta är en av de viktigaste frågorna när du väljer utrustning, så du måste behandla detta problem med lämplig grad av omsorg.

Exempel 1. Vidarebefordrantabell TCAM.

Låt oss ta en titt Palo Alto 7k brandvägg
Vi ser att IPv4-vidarebefordrantabellstorlek* = 32K
Dessutom är detta antal rutter gemensamt för alla VSYS.

Låt oss anta att du enligt din design bestämmer dig för att använda 4 VSYS.
Var och en av dessa VSYS är ansluten via BGP till två MPLS PE i molnet som du använder som en BB. Således byter 4 VSYS alla specifika rutter med varandra och har en vidarebefordringstabell med ungefär samma uppsättningar av rutter (men olika NHs). Därför att varje VSYS har 2 BGP-sessioner (med samma inställningar), sedan har varje rutt som tas emot via MPLS 2 NH och följaktligen 2 FIB-poster i vidarebefordringstabellen. Om vi ​​antar att detta är den enda brandväggen i datacentret och den måste känna till alla rutter, kommer detta att innebära att det totala antalet rutter i vårt datacenter inte kan vara mer än 32K/(4 * 2) = 4K.

Om vi ​​nu antar att vi har 2 datacenter (med samma design) och vi vill använda VLAN "sträckta" mellan datacenter (till exempel för vMotion), måste vi använda värdrutter för att lösa routingproblemet . Men detta betyder att för 2 datacenter kommer vi inte att ha fler än 4096 möjliga värdar och, naturligtvis, kan detta inte vara tillräckligt.

Exempel 2. ACL TCAM.

Om du planerar att filtrera trafik på L3-switchar (eller andra lösningar som använder L3-switchar, till exempel Cisco ACI), bör du vara uppmärksam på TCAM ACL när du väljer utrustning.

Anta att du vill kontrollera åtkomsten på SVI-gränssnitten i Cisco Catalyst 4500. Sedan, som kan ses av den här artikeln, för att kontrollera utgående (såväl som inkommande) trafik på gränssnitt kan du endast använda 4096 TCAM-linjer. Vilket när du använder TCAM3 ger dig cirka 4000 tusen ACE (ACL-linjer).

Om du står inför problemet med otillräcklig TCAM, måste du först och främst överväga möjligheten till optimering. Så, i händelse av problem med storleken på vidarebefordringstabellen, måste du överväga möjligheten att samla rutter. Vid problem med TCAM-storleken för åtkomster, granska åtkomster, ta bort inaktuella och överlappande poster och eventuellt revidera proceduren för att öppna åtkomster (kommer att diskuteras i detalj i kapitlet om granskning av åtkomster).

Hög tillgänglighet

Frågan är: ska jag använda HA för brandväggar eller installera två oberoende boxar "parallellt" och, om en av dem misslyckas, dirigera trafik genom den andra?

Det verkar som att svaret är uppenbart - använd HA. Anledningen till att denna fråga fortfarande uppstår är att den teoretiska och reklammässiga 99 och flera decimaler av tillgänglighet i praktiken tyvärr visar sig vara långt ifrån så rosa. HA är logiskt sett en ganska komplex sak, och på olika utrustningar och med olika leverantörer (det fanns inga undantag) fångade vi problem och buggar och servicestopp.

Använder du HA får du möjlighet att stänga av enskilda noder, växla mellan dem utan att stoppa tjänsten, vilket är viktigt till exempel när du gör uppgraderingar, men samtidigt har du en långt ifrån noll sannolikhet att båda noderna kommer att gå sönder samtidigt, och även att nästa uppgradering inte kommer att gå så smidigt som leverantören lovar (det här problemet kan undvikas om du har möjlighet att testa uppgraderingen på laboratorieutrustning).

Om du inte använder HA är dina risker mycket lägre ur synvinkeln av dubbelfel (eftersom du har 2 oberoende brandväggar), men eftersom... sessioner inte synkroniseras, så varje gång du byter mellan dessa brandväggar kommer du att förlora trafik. Du kan naturligtvis använda tillståndslös brandvägg, men då är poängen med att använda en brandvägg i stort sett förlorad.

Därför, om du som ett resultat av granskningen har upptäckt ensamma brandväggar, och du funderar på att öka tillförlitligheten i ditt nätverk, så är HA naturligtvis en av de rekommenderade lösningarna, men du bör också ta hänsyn till nackdelarna i samband med detta med detta tillvägagångssätt och kanske specifikt för ditt nätverk, skulle en annan lösning vara mer lämplig.

Hanterbarhet

I princip handlar HA också om styrbarhet. Istället för att konfigurera 2 boxar separat och ta itu med problemet med att hålla konfigurationerna synkroniserade, hanterar du dem ungefär som om du hade en enhet.

Men kanske har du många datacenter och många brandväggar, då dyker den här frågan upp på en ny nivå. Och frågan handlar inte bara om konfiguration, utan också om

• backup-konfigurationer
• uppdateringar
• uppgraderingar
• övervakning
• skogsavverkning

Och allt detta kan lösas med centraliserade ledningssystem.

Så, till exempel, om du använder Palo Alto-brandväggar, då Visa är en sådan lösning.

Att fortsätta

Källa: will.com