Denne artikel er den fjerde i serien "Sådan tager du kontrol over din netværksinfrastruktur." Indholdet af alle artikler i serien og links kan findes .
В I dette kapitel har vi set på nogle aspekter af netværkssikkerhed i datacentersegmentet. Denne del vil blive afsat til segmentet "Internetadgang".
Internetadgang
Emnet sikkerhed er uden tvivl et af de mest komplekse emner i verden af datanetværk. Som i tidligere sager, uden at hævde dybde og fuldstændighed, vil jeg her overveje ganske enkle, men efter min mening vigtige spørgsmål, hvis svar, jeg håber, vil hjælpe med at hæve sikkerhedsniveauet for dit netværk.
Når du reviderer 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å designet af dette segment til et virksomhedsnetværk vil jeg anbefale fra Cisco indenfor .
Selvfølgelig vil løsningen fra andre leverandører måske virke mere attraktiv for dig (se. ), men uden at opfordre dig til at følge dette design i detaljer, finder jeg det stadig nyttigt at forstå principperne og ideerne bag det.
bemærkning
I SAFE er "Remote Access"-segmentet en del af "Internet Access"-segmentet. Men i denne serie af artikler vil vi overveje det separat.
Standardsættet af udstyr i dette segment til et virksomhedsnetværk er
- grænse routere
- firewalls
Note 1
I denne serie af artikler, når jeg taler om firewalls, mener jeg .
Note 2
Jeg undlader at overveje forskellige slags L2/L1 eller overlejring af L2 over L3-løsninger, der er nødvendige for at sikre L1/L2-forbindelse og begrænser mig kun til problemer på L3-niveau og derover. Delvist blev L1/L2-spørgsmål diskuteret i kapitlet "".
Hvis du ikke har fundet en firewall i dette segment, så skal du ikke skynde dig til konklusioner.
Lad os gøre det samme som i Lad os starte med spørgsmålet: er det nødvendigt at bruge en firewall i dette segment i dit tilfælde?
Jeg kan sige, at dette synes at være det mest berettigede sted at bruge firewalls og at anvende komplekse trafikfiltreringsalgoritmer. I Vi nævnte 4 faktorer, der kan forstyrre brugen af firewalls i datacentersegmentet. Men her er de ikke længere så betydningsfulde.
Eksempel 1. forsinkelse
For så vidt angår internettet, nytter det ikke noget at tale om forsinkelser på selv omkring 1 millisekund. Derfor kan forsinkelsen i dette segment ikke være en faktor, der begrænser brugen af firewallen.
Eksempel 2. Ydelse
I nogle tilfælde kan denne faktor stadig være væsentlig. Derfor skal du muligvis tillade noget trafik (f.eks. trafik fra belastningsbalancere) for at omgå firewallen.
Eksempel 3. Pålidelighed
Denne faktor skal stadig tages i betragtning, men i betragtning af selve internettets upålidelighed er dets betydning for dette segment ikke så stor som for datacentret.
Så lad os antage, at din tjeneste lever oven på http/https (med korte sessioner). I dette tilfælde kan du bruge to uafhængige bokse (uden HA), og hvis der er et routingproblem med en af dem, skal du overføre al trafik til den anden.
Eller du kan bruge firewalls i transparent tilstand og, hvis de fejler, tillade trafik at omgå firewallen, mens du løser problemet.
Derfor højst sandsynligt bare pris kan være den faktor, der vil tvinge dig til at opgive brugen af firewalls i dette segment.
Vigtigt!
Der er en fristelse til at kombinere denne firewall med datacentrets firewall (brug én firewall til disse segmenter). Løsningen er i princippet mulig, men det skal du forstå pga En internetadgangsfirewall er faktisk på forkant med dit forsvar og "tager på" i det mindste noget af den ondsindede trafik, så skal du selvfølgelig tage højde for den øgede risiko for, at denne firewall bliver deaktiveret. Det vil sige, at du ved at bruge de samme enheder i disse to segmenter reducerer tilgængeligheden af dit datacentersegment markant.
Som altid skal du forstå, at afhængigt af den service, virksomheden leverer, kan designet af dette segment variere meget. Som altid kan du vælge forskellige tilgange afhængigt af dine krav.
Eksempel
Hvis du er en indholdsudbyder med et CDN-netværk (se f.eks. ), så ønsker du måske ikke at skabe infrastruktur på tværs af snesevis eller endda hundredvis af tilstedeværelsespunkter ved hjælp af separate enheder til routing og filtrering af trafik. Det bliver dyrt, og det kan simpelthen være unødvendigt.
For BGP behøver du ikke nødvendigvis at have dedikerede routere, du kan bruge open source værktøjer som f.eks. . Så måske er alt hvad du behøver, en server eller flere servere, en switch og BGP.
I dette tilfælde kan din server eller flere servere spille rollen som ikke kun en CDN-server, men også en router. Selvfølgelig er der stadig mange detaljer (såsom hvordan man sikrer balancering), men det kan lade sig gøre, og det er en tilgang, vi med succes har brugt for en af vores partnere.
Du kan have flere datacentre med fuld beskyttelse (firewalls, DDOS-beskyttelsestjenester leveret af dine internetudbydere) og snesevis eller hundredvis af "forenklede" tilstedeværelsespunkter med kun L2-switche og servere.
Men hvad med beskyttelsen i dette tilfælde?
Lad os for eksempel se på det nyligt populære . Dens fare ligger i, at der genereres en stor mængde trafik, som simpelthen "tilstopper" 100% af alle dine uplinks.
Hvad har vi i tilfælde af vores design.
- hvis du bruger AnyCast, fordeles trafikken mellem dine tilstedeværelsespunkter. Hvis din samlede båndbredde er terabit, så beskytter dette i sig selv faktisk (men for nylig har der været adskillige angreb med ondsindet trafik i størrelsesordenen terabit) dig mod "overfyldte" uplinks
- Hvis nogle uplinks imidlertid bliver tilstoppede, fjerner du blot dette websted fra tjeneste (stop med at annoncere for præfikset)
- du kan også øge andelen af trafik sendt fra dine "fulde" (og følgelig beskyttede) datacentre og dermed fjerne en betydelig del af ondsindet trafik fra ubeskyttede tilstedeværelsespunkter
Og endnu en lille bemærkning til dette eksempel. Hvis du sender nok trafik gennem IX'er, reducerer dette også din sårbarhed over for sådanne angreb
Opsætning af BGP
Der er to emner her.
- Forbindelse
- Opsætning af BGP
Vi har allerede talt lidt om tilslutning i . Pointen er at sikre, at trafikken til dine kunder følger den optimale vej. Selvom optimalitet ikke altid kun handler om latens, er lav latens normalt den vigtigste indikator for optimalitet. For nogle virksomheder er dette vigtigere, for andre er det mindre. Det hele afhænger af den service, du leverer.
Eksempel 1
Hvis du er en børs, og tidsintervaller på mindre end millisekunder er vigtige for dine kunder, så kan der selvfølgelig ikke være tale om nogen form for internet overhovedet.
Eksempel 2
Hvis du er et spilfirma, og titusvis af millisekunder er vigtige for dig, så er forbindelsen selvfølgelig meget vigtig for dig.
Eksempel 3
Du skal også forstå, at på grund af egenskaberne ved TCP-protokollen afhænger dataoverførselshastigheden inden for en TCP-session også af RTT (Round Trip Time). CDN-netværk bliver også bygget til at løse dette problem ved at flytte indholdsdistributionsservere tættere på forbrugeren af dette indhold.
Studiet af tilslutning er et interessant emne i sig selv, værdig til sin egen artikel eller serie af artikler og kræver en god forståelse af, hvordan internettet "virker".
Nyttige ressourcer:
Eksempel
Jeg vil kun give et lille eksempel.
Lad os antage, at dit datacenter er placeret i Moskva, og du har et enkelt uplink - Rostelecom (AS12389). I dette tilfælde (single homed) behøver du ikke BGP, og du bruger højst sandsynligt adressepuljen fra Rostelecom som offentlige adresser.
Lad os antage, at du leverer en bestemt service, og du har et tilstrækkeligt antal kunder fra Ukraine, og de klager over lange forsinkelser. Under din research fandt du ud af, at IP-adresserne på nogle af dem er i 37.52.0.0/21-gitteret.
Ved at køre en traceroute så man, at trafikken gik gennem AS1299 (Telia), og ved at køre et ping fik man en gennemsnitlig RTT på 70 - 80 millisekunder. Du kan også se dette på .
Ved at bruge whois-værktøjet (på ripe.net eller et lokalt hjælpeprogram), kan du nemt bestemme, at blok 37.52.0.0/21 tilhører AS6849 (Ukrtelecom).
Dernæst ved at gå til du ser, at AS6849 ikke har noget forhold til AS12389 (de er hverken klienter eller uplinks til hinanden, og de har heller ikke peering). Men hvis man ser på for AS6849 vil du for eksempel se AS29226 (Mastertel) og AS31133 (Megafon).
Når du har fundet disse udbyderes udseende, kan du sammenligne stien og RTT. For eksempel vil RTT for Mastertel være omkring 30 millisekunder.
Så hvis forskellen mellem 80 og 30 millisekunder er væsentlig for din tjeneste, så skal du måske tænke på tilslutning, få dit AS-nummer, din adressepulje fra RIPE og forbinde yderligere uplinks og/eller oprette tilstedeværelsespunkter på IX'er.
Når du bruger BGP, har du ikke kun mulighed for at forbedre forbindelsen, men du vedligeholder også redundant din internetforbindelse.
indeholder anbefalinger til konfiguration af BGP. På trods af at disse anbefalinger blev udviklet på baggrund af udbydernes "bedste praksis", er de ikke desto mindre (hvis dine BGP-indstillinger ikke er helt grundlæggende) utvivlsomt nyttige og burde faktisk være en del af den hærdning, som vi diskuterede i .
DOS/DDOS beskyttelse
Nu er DOS/DDOS-angreb blevet en hverdagsrealitet for mange virksomheder. Faktisk bliver du angrebet ret ofte i en eller anden form. Det faktum, at du endnu ikke har bemærket dette, betyder kun, at der endnu ikke er organiseret et målrettet angreb mod dig, og at de beskyttelsesforanstaltninger, du bruger, måske endda uden at vide det (diverse indbyggede beskyttelser af operativsystemer), er tilstrækkelige til at sikre, at forringelse af den leverede service minimeres for dig og dine kunder.
Der er internetressourcer, der baseret på udstyrslogfiler tegner smukke angrebskort i realtid.
du kan finde links til dem.
Min favorit fra CheckPoint.
Beskyttelse mod DDOS/DOS er normalt lagdelt. For at forstå hvorfor, skal du forstå, hvilke typer DOS/DDOS-angreb der findes (se f.eks. eller )
Det vil sige, vi har tre typer angreb:
- volumetriske angreb
- protokol angreb
- applikationsangreb
Hvis du kan beskytte dig mod de sidste to typer angreb ved hjælp af for eksempel firewalls, så kan du ikke beskytte dig selv mod angreb, der har til formål at "overvælde" dine uplinks (selvfølgelig, hvis din samlede kapacitet af internetkanaler ikke er beregnet i terabit, eller endnu bedre, i tiere terabit).
Derfor er den første forsvarslinje beskyttelse mod "volumetriske" angreb, og din udbyder eller udbydere skal give dig denne beskyttelse. Hvis du ikke har indset dette endnu, så er du bare heldig for nu.
Eksempel
Lad os sige, at du har flere uplinks, men kun én af udbyderne kan give dig denne beskyttelse. Men hvis al trafik går gennem én udbyder, hvad så med den forbindelse, som vi kort diskuterede lidt tidligere?
I dette tilfælde skal du delvist ofre forbindelsen under angrebet. Men
- dette er kun for angrebets varighed. I tilfælde af et angreb kan du manuelt eller automatisk omkonfigurere BGP, så trafikken kun går gennem den udbyder, der giver dig "paraplyen". Når angrebet er overstået, kan du returnere routingen til dens tidligere tilstand
- Det er ikke nødvendigt at overføre al trafik. Hvis du for eksempel ser, at der ikke er nogen angreb gennem nogle uplinks eller peeringer (eller trafikken ikke er signifikant), kan du fortsætte med at annoncere præfikser med konkurrenceegenskaber over for disse BGP-naboer.
Du kan også uddelegere beskyttelse mod "protokolangreb" og "applikationsangreb" til dine partnere.
her du kan læse en god undersøgelse (). Sandt nok er artiklen to år gammel, men den vil give dig en ide om tilgangene til, hvordan du kan beskytte dig selv mod DDOS-angreb.
I princippet kan du begrænse dig til dette, og helt outsource din beskyttelse. Der er fordele ved denne beslutning, men der er også en åbenlys ulempe. Faktum er, at vi kan tale (igen, alt efter hvad din virksomhed laver) om virksomhedens overlevelse. Og stol på sådanne ting til tredjeparter...
Lad os derfor se på, hvordan man organiserer anden og tredje forsvarslinje (som en tilføjelse til beskyttelse fra udbyderen).
Så den anden forsvarslinje er filtrering og trafikbegrænsere (politifolk) ved indgangen til dit netværk.
Eksempel 1
Lad os antage, at du har dækket dig selv med en paraply mod DDOS med hjælp fra en af udbyderne. Lad os antage, at denne udbyder bruger Arbor til at filtrere trafik og filtre i kanten af sit netværk.
Båndbredden som Arbor kan "behandle" er begrænset, og udbyderen kan naturligvis ikke konstant passere trafikken fra alle sine partnere, som bestiller denne service gennem filtreringsudstyr. Derfor filtreres trafikken ikke under normale forhold.
Lad os antage, at der er et SYN-oversvømmelsesangreb. Selvom du har bestilt en tjeneste, der automatisk skifter trafik til filtrering i tilfælde af et angreb, sker dette ikke med det samme. I et minut eller mere forbliver du under angreb. Og dette kan føre til fejl i dit udstyr eller forringelse af tjenesten. I dette tilfælde vil begrænsning af trafikken ved kantrutingen, selvom det vil føre til, at nogle TCP-sessioner ikke vil blive etableret i løbet af denne tid, redde din infrastruktur fra problemer i større skala.
Eksempel 2
Et unormalt stort antal SYN-pakker kan ikke kun være resultatet af et SYN-oversvømmelsesangreb. Lad os antage, at du leverer en tjeneste, hvor du samtidigt kan have omkring 100 tusinde TCP-forbindelser (til ét datacenter).
Lad os sige, at som et resultat af et kortvarigt problem med en af dine hovedudbydere, bliver halvdelen af dine sessioner sparket. Hvis din applikation er designet på en sådan måde, at den uden at tænke to gange, straks (eller efter et tidsinterval, der er ens for alle sessioner) forsøger at genetablere forbindelsen, vil du modtage mindst 50 tusinde SYN-pakker ca. samtidigt.
Hvis du f.eks. skal køre ssl/tls-håndtryk oven på disse sessioner, hvilket involverer udveksling af certifikater, så vil dette ud fra et synspunkt om at udtømme ressourcer til din load balancer være en meget stærkere "DDOS" end en simpel SYN oversvømmelse. Det ser ud til, at balancere burde håndtere sådanne begivenheder, men... desværre står vi over for et sådant problem.
Og selvfølgelig vil en politibetjent på kanten router også redde dit udstyr i dette tilfælde.
Det tredje niveau af beskyttelse mod DDOS/DOS er dine firewallindstillinger.
Her kan du stoppe både angreb af anden og tredje type. Generelt kan alt, der når firewallen, filtreres her.
Rådet
Prøv at give firewallen så lidt arbejde som muligt, og filtrer så meget som muligt fra de to første forsvarslinjer. Og det er derfor.
Er det nogensinde sket for dig, at du ved en tilfældighed, mens du genererede trafik for at kontrollere, for eksempel, hvor modstandsdygtigt operativsystemet på dine servere er over for DDOS-angreb, "dræbte" din firewall og indlæste den til 100 procent med trafik ved normal intensitet ? Hvis ikke, er det måske simpelthen fordi du ikke har prøvet?
Generelt er en firewall som sagt en kompleks ting, 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, så er du med nogle, ikke med sådan en lille sandsynlighed (baseret på min erfaring), kan du fordumme selv top-end udstyr. Derfor, på trin 2, ved brug af almindelige ACL'er (på L3/L4-niveau), tillad kun trafik ind i dit netværk, som skulle komme ind der.
Filtrering af trafik på firewallen
Lad os fortsætte samtalen om firewallen. Du skal forstå, at DOS/DDOS-angreb kun er én type cyberangreb.
Ud over DOS/DDOS-beskyttelse kan vi også have noget i stil med følgende liste over funktioner:
- applikations firewalling
- trusselforebyggelse (antivirus, anti-spyware og sårbarhed)
- URL-filtrering
- datafiltrering (indholdsfiltrering)
- filblokering (blokering af filtyper)
Det er op til dig at beslutte, hvad du har brug for fra denne liste.
Fortsættes
Kilde: www.habr.com