Denne artikel er den fjerde i serien "Sådan får du kontrol over netværksinfrastrukturen". Indholdet af alle artikler i serien og links kan findes her.

I første del I dette kapitel har vi set på nogle aspekter af netværkssikkerheden i segmentet "Data Center". Denne del vil fokusere på segmentet "Internet Access".

Internetadgang

Sikkerhedsemnet er uden tvivl et af de mest komplekse emner i verden af datatransmission. Ligesom i de foregående tilfælde vil jeg her se på nogle ganske enkle, men efter min mening vigtige spørgsmål, hvis svar forhåbentlig vil hjælpe med at hæve sikkerhedsniveauet for dit netværk.

Ved revision af dette segment skal du være opmærksom på følgende aspekter:

design
BGP-indstillinger
DOS/DDOS-beskyttelse
trafikfiltrering på firewallen

Design

Som et eksempel på design af dette segment for en virksomhedsnetværk vil jeg anbefale vejledning fra Cisco i rammerne af SAFE-modellen.

Selvfølgelig kan løsninger fra andre leverandører virke mere tiltalende for dig (se Gartner-kvadrant for 2018), men uden at opfordre dig til at følge dette design i detaljer mener jeg, det er nyttigt at forstå principperne og idéerne bag det.

Bemærkning
I SAFE-segmentet "Remote Access" er en del af "Internet Access". Men i denne serie af artikler vil vi se på det separat.

Det standardudstyr, der findes i dette segment for et virksomhedsnetværk, er

grænseroutere
firewalls

Bemærkning 1
I denne serie af artikler, når jeg taler om firewalls, mener jeg NGFW.

Bemærkning 2
Jeg udelader diskussionen om forskellige former for L2/L1 eller overlay L2 over L3-løsninger, der er nødvendige for at sikre L1/L2 sammenkobling og begrænser mig til spørgsmål på L3-niveau og derover. Til en vis grad blev L1/L2-spørgsmålene behandlet i kapitlet "Rengøring og dokumentation«.

Hvis du ikke har fundet en firewall i dette segment, skal du ikke skynde dig med konklusionerne.

Lad os, ligesom i den foregående del, starte med spørgsmålet om, hvorvidt det er nødvendigt at bruge en firewall i dette segment i dit tilfælde?

Jeg kan sige, at det ser ud til at være det mest berettigede sted at bruge firewalls og anvende komplekse trafikfiltreringsalgoritmer. I del 1 Vi nævnte fire faktorer, der kan hindre brugen af firewalls i datacentersegmentet. Men her er de ikke så væsentlige.

Eksempel 1. Forsinkelse
Når det kommer til internettet, giver det ikke mening at tale om forsinkelser, selv i størrelsesordenen én millisekund. Derfor kan forsinkelse i dette segment ikke være en faktor, der begrænser brugen af firewallen.

Eksempel 2. Ydeevne
I nogle tilfælde kan denne faktor stadig være væsentlig. Derfor må du muligvis lade en del trafik (f.eks. trafik fra load balancere) gå udenom firewallen.

Eksempel 3. Pålidelighed
Denne faktor skal stadig tages i betragtning, men med tanke på internettets ustabilitet er dens betydning for dette segment ikke så stor som for datacenteret.
Så lad os antage, at din service kører over http/https (med korte sessioner). I dette tilfælde kan du bruge to uafhængige bokse (uden HA), og hvis der opstår problemer med den ene af dem, kan trafikken routedes over til den anden.
Eller du kan bruge firewalls i transparent tilstand, og ved en nedbrud kan du i mellemtiden lede trafikken udenom firewalls.

Derfor er det sandsynligvis kun pris der kan være den faktor, der får dig til at fravælge brugen af firewalls i dette segment.

Vigtigt!
Der er en fristelse til at kombinere denne firewall med datacenterets firewall (bruge én firewall til disse segmenter). En sådan løsning er i princippet mulig, men det er vigtigt at forstå, at eftersom "Internet Access" firewallen faktisk står i frontlinjen af dit forsvar, og "tager imod", i det mindste, en del af den skadelige trafik, skal man være opmærksom på den øgede risiko for, at denne firewall kan gå ned. Det vil sige, at ved at bruge de samme enheder i begge disse segmenter, vil du væsentligt reducere tilgængeligheden af dit datacentersegment.

Som altid skal man forstå, at designet af dette segment kan variere betydeligt alt efter den service, som virksomheden tilbyder. Du kan altid vælge forskellige tilgange afhængigt af kravene.

Eksempel
Hvis du er en indholdudbyder med et CDN (se f.eks. en serie artikler), så du kanske inte vill oprette hundrevis eller endda tusindvis af punkter for infrastruktur ved hjælp af separate enheder til routing og trafikfiltrering. Det vil være dyrt, og det kan også være overflødigt.
For BGP er det slet ikke nødvendigt at have dedikerede routere, du kan bruge open-source værktøjer, som for eksempel, Quagga. Derfor er det muligt, at alt hvad du behøver, er en server eller flere servere, en switch og BGP.
I dette tilfælde kan din server eller flere servere fungere som både CDN-server og router. Naturligvis er der mange detaljer (for eksempel hvordan man sikrer balance), men det er gennemførligt, og denne tilgang har vi med succes anvendt for en af vores partnere.
Du kan have flere datacentre med fuld beskyttelse (firewalls, DDoS-beskyttelsestjenester leveret af dine internetudbydere) og titusinder eller hundreder af 'forenklede' tilstedeværelsespunkter kun med L2 switches og servere.
Men hvad med beskyttelsen i dette tilfælde?
Lad os tage et kig på for eksempel den populære DNS Amplification DDoS angreb. Dens fare ligger i, at der genereres en stor mængde trafik, som simpelthen "tilstopper" alle dine uplinks 100%.
Hvad har vi i tilfælde af vores design.

hvis du bruger AnyCast, så fordeles trafikken mellem dine tilstedeværelsespunkter. Hvis den samlede båndbredde er flere terabits, så forhindrer det i sig selv (der har dog været nogle angreb med ondsindet trafik op til en terabit på det seneste) dig i at "overløbe" dine uplinks.

hvis nogle uplinks alligevel "bliver tilstoppet", kan du simpelthen tage dette site ud af driften (stoppe med at annoncere præfikset).

du kan også øge andelen af trafik, der leveres fra dine "fuldgyldige" (og dermed beskyttede) datacentre, således at du fjerner en væsentlig del af den ondsindede trafik fra ubeskyttede tilstedeværelsespunkter.
Og en lille bemærkning til dette eksempel. Hvis du leverer en tilstrækkelig mængde trafik gennem IX'er, så reducerer det også din udsathed for sådanne angreb.

BGP opsætning

Her er der to emner.

Konnektivitet
BGP opsætning

Om konnektivitet har vi allerede talt lidt del 1Essensen er, at trafikken til dine kunder skal følge den mest optimale rute. Selvom, optimalitet ikke altid kun handler om forsinkelse, er lave forsinkelser som regel det primære mål for optimalitet. For nogle virksomheder er dette vigtigere, mens det for andre er mindre vigtigt. Det afhænger af den service, du leverer.

Eksempel 1
Hvis du er en børs, og dine kunder har brug for tidsintervaller på under millisekunder, så er det klart, at internettet slet ikke kan komme på tale.

Eksempel 2
Hvis du er et gamingfirma, og for dig er titusinde millisekunder vigtigt, så er sammenhængen naturligvis meget vigtig for dig.

Eksempel 3
Det er også vigtigt at forstå, at hastigheden af dataoverførsel inden for en enkelt TCP-session også afhænger af RTT (Round Trip Time) på grund af karakteristikaene ved TCP-protokollen. CDN-netværk er opbygget delvist for at løse dette problem ved at bringe indholdsdistributionsserverne tættere på indholdets forbruger.

Undersøgelsen af sammenhæng er et separat interessant emne, der fortjener en særskilt artikel eller en serie artikler, og kræver en god forståelse af, hvordan internettet 'er bygget'.

Nyttige ressourcer:

ripe.net
bgp.he.net

Eksempel
Jeg vil kun give et lille eksempel.
Antag, at dit datacenter ligger i Moskva, og du har en enkelt uplink – Rostelecom (AS12389). I dette tilfælde (single homed) har du ikke brug for BGP, og som offentlige adresser bruger du sandsynligvis IP-poolen fra Rostelecom.
Antag, at du tilbyder en eller anden service, og du har et tilstrækkeligt antal kunder fra Ukraine, og de klager over store forsinkelser. Ved undersøgelsen fandt du ud af, at IP-adresserne til nogle af dem ligger i netværket 37.52.0.0/21.
Efter at have udført traceroute så du, at trafikken gik gennem AS1299 (Telia), og efter at have udført ping fik du en gennemsnitlig RTT på 70 — 80 millisekunder. Du kan også se dette på Rostelecoms looking glass.
Med værktøjet whois (på websiden ripe.net eller en lokal applikation) kan du nemt afgøre, at blokken 37.52.0.0/21 tilhører AS6849 (Ukrtelecom).
Derudover, ved at gå til bgp.he.net ser du, at AS6849 ikke har relationer med AS12389 (de er hverken kunder eller uplinks for hinanden, og de har heller ikke peering). Men hvis du ser på listen over peers for AS6849, ser du for eksempel AS29226 (Mastertel) og AS31133 (Megafon).
Ved at finde looking glass for disse udbydere kan du sammenligne ruten og RTT. For Mastertel vil RTT for eksempel være på cirka 30 millisekunder.
Så hvis forskellen mellem 80 og 30 millisekunder er væsentlig for din service, bør du måske overveje forbindelsen, få dit AS-nummer fra RIPE, din adressepulje og tilslutte yderligere uplinks eller etablere tilstedeværelsespunkter på IX'er.

Ved brug af BGP har du ikke kun mulighed for at forbedre forbindelsen, men du sikrer også din internetforbindelse.

Dette dokument indeholder anbefalinger til konfiguration af BGP. Selvom disse anbefalinger er udviklet baseret på 'best practices' fra udbydere, er de, hvis dine BGP-indstillinger ikke er helt fundamentale, bestemt nyttige og bør faktisk være en del af det hardening, vi diskuterede i første del.

DOS/DDOS-beskyttelse

I dag er DOS/DDOS-angreb blevet en dagligdags realitet for mange virksomheder. Faktisk bliver du ofte angrebet på en eller anden måde. At du ikke bemærker det, siger blot, at der endnu ikke har været en målrettet angreb mod dig, og at de beskyttelsesforanstaltninger, du bruger, muligvis, uden at du engang er klar over det (forskellige indbyggede beskyttelser i operativsystemer), er tilstrækkelige til at minimere nedgangen i den ydelse, du tilbyder, for dig og dine kunder.

Der eksisterer internetressourcer, der baseret på logs fra udstyr i realtid tegner flotte angrebskort.

Her kan du finde links til dem.

Mit yndlings- kort fra CheckPoint.

Beskyttelse mod DDOS/DOS er typisk lagdelt. For at forstå hvorfor, skal man forstå, hvilke typer af DOS/DDOS-angreb der findes (se f.eks. her eller her)

Det vil sige, vi har tre typer angreb:

volumetriske angreb
protokolangreb
applikationsangreb

Hvis du kan beskytte dig mod de sidste to typer angreb selv ved hjælp af f.eks. firewalls, kan du ikke beskytte dig mod angreb, der er rettet mod at 'overbelaste' dine uplinks (naturligvis, hvis din samlede kapacitet af internetforbindelser ikke måles i terabitter, helst endda i titusinde terabitter).

Derfor er den første beskyttelseslinje at beskytte mod 'volumetriske' angreb, og denne beskyttelse bør din udbyder eller udbydere sørge for. Hvis du ikke har indset dette endnu, er du blot heldig.

Eksempel
Lad os antage, at du har flere uplinks, men kun én af udbyderne kan give dig denne beskyttelse. Men hvis al trafik går gennem én udbyder, hvordan er det så med forbindelsen, som vi kort diskuterede tidligere?
I tilfælde af et angreb må du delvist opgive forbindelsen. Men

det er kun under angrebet. Du kan i tilfælde af et angreb manuelt eller automatisk omkonfigurere BGP, så trafikken kun går gennem den udbyder, der giver dig "paraplyen". Efter angrebet kan du returnere routing til den tidligere tilstand.

det er ikke nødvendigt at dirigere al trafik. Hvis du for eksempel ser, at der ikke er et angreb (eller trafikken er ubetydelig) gennem nogle uplinks eller peering, kan du fortsætte med at annoncere præfikser med konkurrerende attributter mod disse BGP-naboer.

Beskyttelse mod "protocol angreb" og "application angreb" kan du også overlade til partnere.
Her er her kan du læse en god undersøgelse (oversættelse). Sandt nok er artiklen to år gammel, men det vil give dig en forståelse af tilgange, hvordan du kan beskytte dig mod DDOS-angreb.

I princippet kan du begrænse dig til dette og helt outsource din beskyttelse. Der er fordele ved denne løsning, men der er også en åbenlys ulempe. Sagen er, at det kan handle om (igen afhængigt af, hvad din virksomhed beskæftiger sig med) virksomhedens overlevelse. Og at stole på sådanne ting hos tredjepartsorganisationer…

Derfor lad os se på, hvordan man organiserer det andet og tredje forsvarslag (som supplement til beskyttelsen fra udbyderen).

Så det andet forsvarslag er filtrering og trafikbegrænsere (policers) ved indgangen til dit netværk.

Eksempel 1
Lad os antage, at du har "lukket dig inde" fra DDOS med hjælp fra en af udbyderne. Lad os antage, at denne udbyder bruger Arbor til trafikfiltrering og filtre på grænsen af sit netværk.
Båndbredden, som Arbor kan "behandle", er begrænset, og udbyderen kan selvfølgelig ikke konstant lede trafikken fra alle sine partnere, der har bestilt denne service, gennem det filtrerende udstyr. Derfor bliver trafik ikke filtreret under normale forhold.
Antag at et SYN flood angreb. Selvom du har bestilt en service, hvor trafikken automatisk omdirigeres til filtrering i tilfælde af et angreb, sker det ikke øjeblikkeligt. I løbet af et minut eller mere vil du være under angreb. Dette kan føre til, at dit udstyr svigter eller din service degraderes. I dette tilfælde, selvom begrænsning af trafikken ved grænserouteringen vil medføre, at nogle TCP-sessioner ikke vil blive etableret i denne periode, vil det redde din infrastruktur fra mere omfattende problemer.

Eksempel 2
Et unormalt stort antal SYN-pakker kan ikke kun være et resultat af et SYN flood angreb. Lad os antage, at du tilbyder en service, hvor du samtidig kan have op til 100.000 TCP-forbindelser (til et datacenter).
Lad os antage, at halvdelen af sessionerne er blevet 'sparket ud' som følge af et kortvarigt problem med en af dine hovedudbydere. Hvis din applikation er konstrueret sådan, at den uden videre straks (eller efter en ensartet tidsperiode for alle sessioner) forsøger at genoprette forbindelsen, vil du i det mindste modtage ca. 50.000 SYN-pakker samtidig.
Hvis der oven på disse sessioner eksempelvis skal køre en SSL/TLS handshake, som indebærer udveksling af certifikater, vil det fra dit belastningsfordeleres synspunkt være en meget større 'DDoS' end et simpelt SYN flood. Det synes, at belastningsfordelere skal kunne håndtere sådanne hændelser, men... desværre har vi mødt dette problem i fuld skala.
Og selvfølgelig vil en policer på grænserouteren redde dit udstyr i dette tilfælde.

Det tredje beskyttelsesniveau mod DDoS/DOS er indstillingerne i din firewall.

Her kan du stoppe både angreb af anden og tredje type. Generelt kan alt, der når firewall'en, filtreres her.

Råd
Forsøg at give din firewall så lidt arbejde som muligt ved at filtrere så meget som muligt på de første to forsvarslinjer. Og her er hvorfor.
Har du nogensinde oplevet, at du ved et uheld, mens du genererede trafik for at teste, hvor modstandsdygtig dit serversystems operativsystem er over for DDoS-angreb, 'dræbte' din firewall ved at belaste den med 100 procent normal trafikintensitet? Hvis ikke, så måske fordi du ikke har prøvet?
Generelt er firewallen, som jeg allerede har nævnt, en kompleks størrelse, og den fungerer godt med kendte sårbarheder og testede løsninger. Men hvis du sender noget usædvanligt, bare noget skrald eller pakker med forkerte overskrifter, kan du med en vis, ikke ubetydelig (baseret på min erfaring) sandsynlighed kunne forvirre selv det mest avancerede udstyr. Derfor, på trin 2, lad kun den trafik ind i dit netværk, der skal være der, ved hjælp af almindelige ACL'er (på L3/L4-niveau).