Denna artikel är den fjärde i serien "Hur man får nätverksinfrastrukturen under kontroll". Innehållet i alla artiklar i serien och länkar kan hittas här.

I första delen i denna del har vi tittat på vissa aspekter av nätverkssäkerhet för "Data Center"-segmentet. Denna del kommer att handla om segmentet "Internet Access".

Internetåtkomst

Säkerhet är utan tvekan ett av de mest komplexa ämnena inom datanätverk. Som i de tidigare fallen ska jag, utan att påstå att jag täcker allt, här diskutera några relativt enkla, men efter min mening viktiga frågor, vars svar jag hoppas kommer att bidra till att höja säkerhetsnivån i ditt nätverk.

Vid revision av detta segment, var uppmärksam på följande aspekter:

design
BGP-inställningar
DOS/DDOS-skydd
trafikfiltering på brandväggen

Design

Som exempel på design av detta segment för företagsnätverket skulle jag rekommendera en guide från Cisco inom SAFE-modellen.

Självklart kan lösningar från andra leverantörer verka mer tilltalande för dig (se Gartners kvadrant för 2018), men utan att uppmana dig att följa detta design i detalj, anser jag det ändå vara nyttigt att förstå de principer och idéer som ligger till grund för det.

Anmärkning
I SAFE-segmentet är "Remote Access" en del av "Internet Access". Men i denna artikelserie kommer vi att titta på det separat.

Den standardutrustning som används i detta segment för företagsnätverk är

gränsrutrar (border routers)
brandväggar

Anmärkning 1
I denna artikelserie, när jag talar om brandväggar, menar jag NGFW.

Anmärkning 2
Jag undviker att diskutera olika typer av L2/L1 eller överlagda L2 över L3-lösningar som krävs för L1/L2-anslutning och begränsar mig till frågor på L3-nivå och uppåt. Delvis har L1/L2-frågor behandlats i kapitlet "Rensning och dokumentation«.

Om du inte har upptäckt någon brandvägg i detta segment bör du inte skynda dig till slutsatser.

Låt oss, precis som i den föregående delen, börja med frågan om det är nödvändigt att använda brandvägg i detta segment i ditt fall?

Jag kan säga att det verkar vara den mest motiverade platsen för att använda brandväggar och för att tillämpa komplexa trafikfiltreringsalgoritmer. I del 1 nämnde vi 4 faktorer som kan hindra användningen av brandväggar i datacentersegmentet. Men här är de redan inte så avgörande.

Exempel 1. Fördröjning
När det gäller internet finns det ingen mening med att prata om fördröjningar på ens 1 millisekund. Därför kan fördröjning i detta segment inte vara en faktor som begränsar användningen av brandväggen.

Exempel 2. Performance
I vissa fall kan denna faktor fortfarande vara betydande. Därför kan det vara nödvändigt att släppa en del av trafiken (till exempel trafik från lastbalanserare) förbi brandväggen.

Exempel 3. Pålitlighet
Denna faktor måste fortfarande beaktas, men med tanke på den opålitlighet som internet självständigt innebär, är dess betydelse för detta segment inte så stort som för datacentret.
Låt oss anta att din tjänst körs över http/https (med korta sessioner). I så fall kan du använda två oberoende enheter (utan HA) och vid problem med en av dem ruttar du om hela trafiken till den andra.
Eller så kan du använda brandväggar i transparent läge och vid deras sammanslagning leda trafiken förbi brandväggarna medan du löser problemet.

Så, det handlar nog egentligen bara om pris kan vara den faktor som får dig att avstå från att använda brandväggar i detta segment.

Viktigt!
Det finns en frestelse att kombinera denna brandvägg med datacenterbrandväggen (använda en enda brandvägg för dessa segment). Lösningen är i princip möjlig, men man måste förstå att eftersom "Internet Access"-brandväggen faktiskt står i frontlinjen av ditt försvar och "tar emot" åtminstone en del av den skadliga trafiken, så måste man ta hänsyn till den ökade risken att denna brandvägg kan sluta fungera. Det vill säga, genom att använda samma enheter i dessa två segment minskar du väsentligt tillgängligheten för datacentersegmentet.

Som vanligt är det viktigt att förstå att beroende på den tjänst som företaget tillhandahåller, kan designen av detta segment variera kraftigt. Du kan, som vanligt, välja olika angreppssätt beroende på kraven.

Exempel
Om du är en innehållsleverantör med ett CDN-nätverk (se till exempel, artikelsamling), så kanske du inte vill skapa infrastruktur med tiotals, om inte hundratals punkter av närvaro med hjälp av separata enheter för att styra och filtrera trafiken. Detta skulle bli dyrt och kan helt enkelt vara överflödigt.
För BGP behöver du inte nödvändigtvis ha dedikerade routrar, du kan använda open-source verktyg, till exempel, Quagga. Därför kan allt du behöver vara en server eller flera servrar, en switch och BGP.
I det här fallet kan din server eller flera servrar fungera som både CDN-server och router. Det finns förstås många detaljer här (till exempel hur du säkerställer lastbalansering), men det är genomförbart, och denna metod har vi framgångsrikt tillämpat för en av våra partners.
Du kan ha flera datacenter med fullständig skydd (brandväggar, DDoS-skyddstjänster som tillhandahålls av dina internetleverantörer) och tiotals eller hundratals "förenklade" närvaro punkter med endast L2-switchar och servrar.
Men hur är det med säkerheten i det här fallet?
Låt oss titta på ett exempel som har blivit populärt på senare tid, DNS Amplification DDoS-attack. Dess fara ligger i att en stor mängd trafik genereras som helt enkelt "blockerar" alla dina uppströmslänkar till 100%.
Vad har vi i vårt design?

om du använder AnyCast, då fördelas trafiken mellan dina närvaropunkter. Om den totala bandbredden är terabitar, skyddar detta sig självt (även om det på senare tid har skett flera attacker med skadlig trafik på över terabit) mot "översvämning" av uppströmslänkar.

om några uppströmslänkar fortfarande "blockeras", kan du helt enkelt ta denna plats ur drift (sluta annonsera prefixet).

du kan också öka andelen trafik som skickas från dina "fullständiga" (och därmed skyddade) datacenter och på så sätt ta bort en betydande del av skadlig trafik från oskyddade närvaropunkter.
Och en liten kommentar till detta exempel. Om en tillräcklig mängd trafik passerar genom IX:er, minskar detta också din sårbarhet för sådana attacker.

BGP-inställning

Här är två ämnen.

Anslutning
BGP-inställning

Vi har redan pratat lite om anslutning i del 1. Poängen är att trafiken till dina kunder ska gå den optimala vägen. Även om optimalitet inte alltid bara handlar om fördröjning, är det vanligtvis den låga fördröjningen som är det viktigaste måttet på optimalitet. För vissa företag är detta viktigare, för andra mindre. Allt beror på den tjänst som du tillhandahåller.

Exempel 1
Om du är en börs och för dina kunder är tidsintervall mindre än millisekunder viktiga, är det tydligt att internet överhuvudtaget inte är ett alternativ.

Exempel 2
Om du är ett spelbolag och för dig är tiotals millisekunder viktiga, är kopplingen förstås mycket viktig för dig.

Exempel 3
Man måste också förstå att på grund av TCP-protokollets egenskaper beror hastigheten för datatransfer inom en TCP-session också på RTT (Round Trip Time). CDN-nätverk byggs bland annat för att lösa detta problem genom att placera innehållsleveransservrar närmare konsumenten av detta innehåll.

Undersökningen av kopplingskvalitet är ett separat intressant ämne som förtjänar en egen artikel eller artikelserie och kräver en god förståelse för hur internet är "uppbyggt".

Nyttiga resurser:

ripe.net
bgp.he.net

Exempel
Jag ger bara ett litet exempel.
Anta att ditt datacenter ligger i Moskva, och du har en enda uplink – Rostelekom (AS12389). I det här fallet (single homed) behöver du inte BGP, och som offentliga adresser använder du troligen en adresspool från Rostelekom.
Anta att du tillhandahåller en viss tjänst och har ett tillräckligt antal kunder från Ukraina som klagar på stora fördröjningar. Vid undersökning fann du att IP-adresserna för några av dem ligger i nätverket 37.52.0.0/21.
Genom att utföra en traceroute såg du att trafiken går genom AS1299 (Telia), och genom att utföra en ping fick du ett genomsnittligt RTT på 70 – 80 millisekunder. Du kan också se detta på Rostelekoms looking glass.
Medverktyget whois (på ripe.net eller med ett lokalt verktyg) kan du lätt fastställa att blocket 37.52.0.0/21 tillhör AS6849 (Ukrtelecom).
Vidare, genom att gå till bgp.he.net ser du att AS6849 inte har något förhållande till AS12389 (de är varken kunder eller uppkopplingar till varandra, och de har inte heller något peering). Men om du tittar på listan över peers för AS6849 ser du till exempel AS29226 (Mastertel) och AS31133 (Megafon).
Genom att hitta looking glass hos dessa leverantörer kan du jämföra vägen och RTT. Till exempel, för Mastertel kommer RTT att vara omkring 30 millisekunder.
Så om skillnaden mellan 80 och 30 millisekunder är betydande för din tjänst, kanske du behöver tänka på kopplingen, få ditt AS-nummer i RIPE, din adresspool och ansluta ytterligare uplinks och/eller skapa närvaro på IX.

Genom att använda BGP har du inte bara möjlighet att förbättra din anslutning, utan även att säkerhetskopiera din internetanslutning.

Detta dokument innehåller rekommendationer för konfiguration av BGP. Även om dessa rekommendationer har utarbetats utifrån "best practices" från leverantörer, är de ändå utan tvekan användbara och bör faktiskt vara en del av den härdningsprocess som vi diskuterade i första delen.

DOS/DDOS-skydd

Idag har DOS/DDOS-attacker blivit en vardaglig verklighet för många företag. I själva verket attackeras du ganska ofta, även om du kanske inte märker det. Det faktum att du fortfarande inte har upptäckt det, tyder bara på att en riktad attack mot dig inte har organiserats än, och att de skyddsåtgärder du använder, även om du kanske inte är medveten om det (olika inbyggda skydd i operativsystem), är tillräckliga för att minimera degraderingen av den tjänst som du och dina kunder använder.

Det finns internetresurser som, baserat på loggar från utrustningen, i realtid skapar vackra kartor över attacker.

Här Du kan hitta länkar till dem.

Min favorit karta från CheckPoint.

Skydd mot DDOS/DOS är vanligtvis i flera lager. För att förstå varför måste man veta vilka typer av DOS/DDOS-attacker som finns (se till exempel, här eller här)

Det finns alltså tre typer av attacker:

volymetriska attacker
protokollattacker
applikationsattacker

Om du kan skydda dig mot de senaste två typerna av attacker på egen hand med hjälp av till exempel brandväggar, så kan du inte skydda dig mot attacker som syftar till att "överbelasta" dina uplinks (naturligtvis om din totala kapacitet för internetkanaler inte uppgår till terabitar, helst fler terabitar).

Därför är det viktigt att det första skyddet är mot "volymetriska" attacker och detta skydd bör tillhandahållas av din leverantör eller leverantörer. Om du inte har förstått detta ännu, så har du helt enkelt haft tur hittills.

Exempel
Anta att du har flera uplinks, men bara en av leverantörerna kan ge dig detta skydd. Men om all trafik går genom en leverantör, hur ska då sammanlänkningen som vi kort diskuterade tidigare fungera?
Under attacken kommer du delvis att behöva offra sammanlänkningen.

Det är endast under attacken. Du kan manuellt eller automatiskt omkonfigurera BGP i händelse av en attack så att trafiken endast går genom den leverantör som ger dig "paraplyet". Efter attacken kan du återställa routingen till sitt ursprungliga tillstånd.

Det är inte nödvändigt att översätta all trafik. Om du till exempel ser att det inte är några attacker (eller att trafiken inte är av stor betydelse) genom vissa uppkopplingar eller peers, kan du fortsätta annonsera prefix med konkurrerande attribut mot dessa BGP-grannar.

Skydd mot "protokollattacker" och "applikationsattacker" kan du också överlåta åt partner.
Här är här Du kan läsa en bra studie (översättning). Visserligen är artikeln två år gammal, men den ger dig en bra inblick i de metoder du kan använda för att skydda dig mot DDOS-attacker.

I princip kan du nöja dig med detta och helt outsourca ditt skydd. Det finns fördelar med denna lösning, men också en uppenbar nackdel. Eftersom det, beroende på vad ditt företag sysslar med, kan handla om företagets överlevnad. Att överlåta sådana frågor till externa organisationer...

Därför, låt oss titta på hur vi kan organisera ett andra och tredje försvarslinje (som ett komplement till skyddet från leverantören).

Så den andra försvarslinjen är filtrering och trafikbegränsare (policers) vid ingången till ditt nätverk.

Exempel 1
Anta att du har "stängt dig under paraplyet" mot DDOS med hjälp av en av leverantörerna. Anta att denna leverantör använder Arbor för trafikfiltrering och filter vid gränsen till sitt nätverk.
Bandbredden som Arbor kan "behandla" är begränsad, och leverantören kan självklart inte alltid släppa igenom all trafik från sina partners som beställt denna tjänst genom filtreringsutrustningen. Därför filtreras trafiken vanligtvis inte.
Anta att det pågår en SYN flood-attack. Även om du har beställt en tjänst där trafiken automatiskt omdirigeras till filtrering vid en attack, sker detta inte omedelbart. Under en minut eller längre förblir du under attack. Detta kan leda till att din utrustning slås ut eller att tjänsten degraderas. I det här fallet kommer trafikbegränsning på gränsrutten, även om det innebär att vissa TCP-sessioner under denna tid inte kommer att inrättas, att rädda din infrastruktur från mer omfattande problem.

Exempel 2
Ett onormalt stort antal SYN-paket kan vara mer än bara resultatet av en SYN flood-attack. Låt oss anta att du tillhandahåller en tjänst där du samtidigt kan ha cirka 100 000 TCP-anslutningar (i ett datacenter).
Anta att hälften av sessionerna har "sparkats ut" på grund av ett kortvarigt problem med en av dina huvudleverantörer. Om din applikation är utformad på ett sätt som gör att den direkt (eller efter en gemensam tid för alla sessioner) försöker återetablera anslutningen, kommer du cirka samtidigt att få minst 50 000 SYN-paket.
Om ssl/tls-handshaket som kräver certifikatutbyte också måste köras ovanpå dessa sessioner, kommer det ur perspektivet av resursutnyttjande för din lastbalanserare att bli en mycket mer allvarlig "DDoS" än en enkel SYN flood. Det skulle verka som att lastbalanserarna borde hantera sådana händelser, men tyvärr har vi stött på detta problem i full skala.
Och givetvis kommer en policer på gränsrutern att skydda din utrustning i detta fall.

Det tredje skyddsnivån mot DDoS/DOS är inställningarna för din brandvägg.

Här kan du stoppa både attacker av andra och tredje typen. Generellt kan allt som når brandväggen filtreras här.

Tips
Försök att ge brandväggen så lite arbete som möjligt genom att filtrera så mycket som möjligt på de första två försvarslinjerna. Och här är varför.
Har du någonsin upplevt att du av misstag, när du genererar trafik för att kontrollera till exempel hur väl ditt servers operativsystem står emot DDOS-attacker, "dödat" din brandvägg genom att belasta den till 100 procent, med trafik av normal intensitet? Om inte, kanske det bara beror på att du inte har provat?
Som jag redan nämnt är brandväggen en komplex sak, och den fungerar bra mot kända sårbarheter och testade lösningar, men om du skickar något ovanligt, bara skräppaket eller paket med felaktiga rubriker, kan du, med en viss sannolikhet (baserat på min erfarenhet), få även den bästa utrustningen att få problem. Så på steg 2, med vanliga ACL (på L3/L4-nivå), släpp endast den trafik som bör ha tillgång till ditt nätverk.