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

В den första delen I det här kapitlet tittade vi på några aspekter av nätverkssäkerhet i datacentersegmentet. Den här delen kommer att ägnas åt segmentet "Internet Access".

Tillgång till Internet

Ämnet säkerhet är utan tvekan ett av de mest komplexa ämnena i världen av datanätverk. Som i tidigare fall, utan att hävda djup och fullständighet, kommer jag att överväga här ganska enkla, men enligt min mening viktiga frågor, vars svar, jag hoppas, kommer att bidra till att höja säkerhetsnivån i ditt nätverk.

När du granskar detta segment, var uppmärksam på följande aspekter:

• utformning
• BGP-inställningar
• DOS/DDOS-skydd
• trafikfiltrering på brandväggen

Design

Som ett exempel på utformningen av detta segment för ett företagsnätverk skulle jag rekommendera ledning från Cisco inom säkra modeller.

Naturligtvis kanske lösningen från andra leverantörer kommer att verka mer attraktiv för dig (se. Gartner Quadrant 2018), men utan att uppmuntra dig att följa denna design i detalj, tycker jag ändå att det är användbart att förstå principerna och idéerna bakom den.

anmärkning

I SAFE är segmentet "Remote Access" en del av segmentet "Internet Access". Men i den här artikelserien kommer vi att överväga det separat.

Standarduppsättningen av utrustning i detta segment för ett företagsnätverk är

• gränsroutrar
• brandväggar

Anteckning 1

I den här artikelserien, när jag pratar om brandväggar, menar jag NGFW.

Anteckning 2

Jag utelämnar övervägande av olika typer av L2/L1 eller överlägg L2 över L3-lösningar som är nödvändiga för att säkerställa L1/L2-anslutning och begränsar mig bara till problem på L3-nivå och högre. Delvis diskuterades L1/L2-frågor i kapitlet "Städning och dokumentation".

Om du inte har hittat en brandvägg i det här segmentet bör du inte skynda dig att dra slutsatser.

Låt oss göra samma sak som i föregående delLåt oss börja med frågan: är det nödvändigt att använda en brandvägg i detta segment i ditt fall?

Jag kan säga att detta verkar vara den mest motiverade platsen att använda brandväggar och att tillämpa komplexa trafikfiltreringsalgoritmer. I delar av 1 Vi nämnde 4 faktorer som kan störa användningen av brandväggar i datacentersegmentet. Men här är de inte längre så betydelsefulla.

Exempel 1. Fördröjning

Vad gäller Internet är det ingen idé att tala om förseningar på ens cirka 1 millisekund. Därför kan fördröjningen i detta segment inte vara en faktor som begränsar användningen av brandväggen.

Exempel 2. Производительность

I vissa fall kan denna faktor fortfarande vara betydande. Därför kan du behöva tillåta en del trafik (till exempel trafik från lastbalanserare) att kringgå brandväggen.

Exempel 3. Надежность

Denna faktor måste fortfarande tas med i beräkningen, men ändå, med tanke på Internets opålitlighet, är dess betydelse för detta segment inte lika stor som för datacentret.

Så låt oss anta att din tjänst lever ovanpå http/https (med korta sessioner). I det här fallet kan du använda två oberoende boxar (utan HA) och om det finns ett routingproblem med en av dem, överför all trafik till den andra.

Eller så kan du använda brandväggar i transparent läge och, om de misslyckas, tillåta trafik att kringgå brandväggen medan du löser problemet.

Därför mest troligt bara pris kan vara den faktor som kommer att tvinga dig att överge användningen av brandväggar i detta segment.

Viktigt!

Det finns en frestelse att kombinera denna brandvägg med datacentrets brandvägg (använd en brandvägg för dessa segment). Lösningen är i princip möjlig, men det måste du förstå pga En Internet Access-brandvägg är faktiskt i framkant av ditt försvar och "tar på" åtminstone en del av den skadliga trafiken, då måste du naturligtvis ta hänsyn till den ökade risken att denna brandvägg kommer att inaktiveras. Det vill säga, genom att använda samma enheter i dessa två segment kommer du att avsevärt minska tillgängligheten för ditt datacentersegment.

Som alltid måste du förstå att beroende på vilken tjänst som företaget tillhandahåller kan utformningen av detta segment variera mycket. Som alltid kan du välja olika tillvägagångssätt beroende på dina krav.

Exempel

Om du är en innehållsleverantör med ett CDN-nätverk (se t.ex. serie artiklar), då kanske du inte vill skapa infrastruktur över dussintals eller till och med hundratals närvaropunkter med hjälp av separata enheter för att dirigera och filtrera trafik. Det blir dyrt, och det kan helt enkelt vara onödigt.

För BGP behöver du inte nödvändigtvis ha dedikerade routrar, du kan använda open source-verktyg som Quagga. Så kanske allt du behöver är en server eller flera servrar, en switch och BGP.

I det här fallet kan din server eller flera servrar spela rollen som inte bara en CDN-server utan också en router. Naturligtvis finns det fortfarande många detaljer (som hur man säkerställer balansering), men det är genomförbart, och det är ett tillvägagångssätt som vi framgångsrikt har använt för en av våra partners.

Du kan ha flera datacenter med fullt skydd (brandväggar, DDOS-skyddstjänster från dina internetleverantörer) och dussintals eller hundratals "förenklade" närvaropunkter med endast L2-switchar och servrar.

Men hur är det med skyddet i det här fallet?

Låt oss titta på till exempel det nyligen populära DNS-förstärkning DDOS-attack. Dess fara ligger i det faktum att en stor mängd trafik genereras, vilket helt enkelt "täpper till" 100% av alla dina upplänkar.

Vad har vi när det gäller vår design.

• om du använder AnyCast så fördelas trafiken mellan dina närvaropunkter. Om din totala bandbredd är terabit, så skyddar detta i sig självt (men nyligen har det förekommit flera attacker med skadlig trafik i storleksordningen terabit) dig från att "överflöda" upplänkar
• Om vissa upplänkar däremot blir igensatta tar du helt enkelt bort den här webbplatsen från tjänst (sluta annonsera prefixet)
• du kan också öka andelen trafik som skickas från dina "fullständiga" (och följaktligen skyddade) datacenter och på så sätt ta bort en betydande del av skadlig trafik från oskyddade närvaropunkter

Och ytterligare en liten anmärkning till detta exempel. Om du skickar tillräckligt med trafik genom IX:er minskar detta också din sårbarhet för sådana attacker

Konfigurera BGP

Det finns två ämnen här.

• Anslutningsmöjligheter
• Konfigurera BGP

Vi har redan pratat lite om anslutning i delar av 1. Poängen är att se till att trafiken till dina kunder följer den optimala vägen. Även om optimalitet inte alltid bara handlar om latens, är låg latens vanligtvis den främsta indikatorn på optimalitet. För vissa företag är detta viktigare, för andra mindre. Allt beror på vilken tjänst du tillhandahåller.

exempel 1

Om du är ett utbyte och tidsintervall på mindre än millisekunder är viktiga för dina kunder, så kan det naturligtvis inte vara tal om någon form av Internet alls.

exempel 2

Om du är ett spelbolag och tiotals millisekunder är viktiga för dig, så är uppkoppling såklart väldigt viktig för dig.

exempel 3

Du måste också förstå att, på grund av egenskaperna hos TCP-protokollet, beror dataöverföringshastigheten inom en TCP-session också på RTT (Round Trip Time). CDN-nätverk byggs också för att lösa detta problem genom att flytta innehållsdistributionsservrar närmare konsumenten av detta innehåll.

Studiet av anslutning är ett intressant ämne i sig, värdigt en egen artikel eller serie av artiklar, och kräver en god förståelse för hur Internet "fungerar".

Användbara resurser:

ripe.net
bgp.he.net

Exempel

Jag ska bara ge ett litet exempel.

Låt oss anta att ditt datacenter ligger i Moskva och att du har en enda upplänk - Rostelecom (AS12389). I det här fallet (single homed) behöver du inte BGP, och du använder med största sannolikhet adresspoolen från Rostelecom som publika adresser.

Låt oss anta att du tillhandahåller en viss tjänst, och att du har ett tillräckligt antal kunder från Ukraina, och de klagar på långa förseningar. Under din efterforskning fick du reda på att IP-adresserna för vissa av dem finns i rutnätet 37.52.0.0/21.

Genom att köra en traceroute såg man att trafiken gick genom AS1299 (Telia), och genom att köra en ping fick man en genomsnittlig RTT på 70 - 80 millisekunder. Du kan också se detta på utseende glas Rostelecom.

Med hjälp av whois-verktyget (på ripe.net eller ett lokalt verktyg) kan du enkelt fastställa att block 37.52.0.0/21 tillhör AS6849 (Ukrtelecom).

Nästa, genom att gå till bgp.he.net du ser att AS6849 inte har något samband med AS12389 (de är varken klienter eller upplänkar till varandra, och de har inte heller peering). Men om man tittar på lista över kamrater för AS6849 ser du till exempel AS29226 (Mastertel) och AS31133 (Megafon).

När du har hittat utseendet på dessa leverantörer kan du jämföra sökvägen och RTT. Till exempel, för Mastertel kommer RTT att vara cirka 30 millisekunder.

Så om skillnaden mellan 80 och 30 millisekunder är betydande för din tjänst, så kanske du behöver tänka på anslutning, skaffa ditt AS-nummer, din adresspool från RIPE och ansluta ytterligare upplänkar och/eller skapa närvaropunkter på IX:er.

När du använder BGP har du inte bara möjlighet att förbättra uppkopplingen, utan du underhåller även din Internetanslutning i redundant form.

Det här dokumentet innehåller rekommendationer för att konfigurera BGP. Trots det faktum att dessa rekommendationer utvecklades baserat på leverantörernas "bästa praxis" är de trots allt (om dina BGP-inställningar inte är helt grundläggande) utan tvekan användbara och borde faktiskt vara en del av den härdning som vi diskuterade i den första delen.

DOS/DDOS-skydd

Nu har DOS/DDOS-attacker blivit en vardag för många företag. I själva verket blir du attackerad ganska ofta i en eller annan form. Det faktum att du ännu inte har märkt detta betyder bara att en riktad attack ännu inte har organiserats mot dig, och att de skyddsåtgärder som du använder, även kanske utan att veta om det (olika inbyggda skydd av operativsystem), tillräckliga för att se till att försämringen av den tillhandahållna tjänsten minimeras för dig och dina kunder.

Det finns internetresurser som, baserat på utrustningsloggar, ritar vackra attackkartor i realtid.

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

Min favorit karta från CheckPoint.

Skydd mot DDOS/DOS är vanligtvis skiktat. För att förstå varför måste du förstå vilka typer av DOS/DDOS-attacker som finns (se t.ex. här eller här)

Det vill säga, vi har tre typer av attacker:

• volymetriska attacker
• protokollsattacker
• applikationsattacker

Om du kan skydda dig mot de två sista typerna av attacker med till exempel brandväggar, så kan du inte skydda dig från attacker som syftar till att "överväldiga" dina upplänkar (naturligtvis om din totala kapacitet för internetkanaler inte beräknas i terabit, eller ännu bättre, i tiotals terabit).

Därför är den första försvarslinjen skydd mot "volymetriska" attacker, och din leverantör eller leverantörer måste tillhandahålla detta skydd till dig. Om du inte har insett detta än, så har du bara tur för nu.

Exempel

Låt oss säga att du har flera upplänkar, men bara en av leverantörerna kan ge dig detta skydd. Men om all trafik går via en leverantör, hur är det då med anslutningen som vi kort diskuterade lite tidigare?

I det här fallet måste du delvis offra anslutningen under attacken. Men

• detta är bara under attackens varaktighet. I händelse av en attack kan du manuellt eller automatiskt konfigurera om BGP så att trafiken endast går via leverantören som ger dig "paraplyet". När attacken är över kan du återställa routingen till dess tidigare tillstånd
• Det är inte nödvändigt att överföra all trafik. Om du till exempel ser att det inte sker några attacker genom vissa upplänkar eller peeringar (eller om trafiken inte är betydande) kan du fortsätta att annonsera prefix med konkurrenskraftiga attribut gentemot dessa BGP-grannar.

Du kan också delegera skydd från "protokollattacker" och "applikationsattacker" till dina partners.
Här här du kan läsa en bra studie (översättning). Det är sant att artikeln är två år gammal, men den kommer att ge dig en uppfattning om hur du kan skydda dig mot DDOS-attacker.

I princip kan du begränsa dig till detta, helt outsourca ditt skydd. Det finns fördelar med detta beslut, men det finns också en uppenbar nackdel. Faktum är att vi kan prata (igen, beroende på vad ditt företag gör) om verksamhetens överlevnad. Och lita på sådana saker till tredje part...

Låt oss därför titta på hur man organiserar den andra och tredje försvarslinjen (som ett tillägg till skyddet från leverantören).

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

exempel 1

Låt oss anta att du har täckt dig med ett paraply mot DDOS med hjälp av en av leverantörerna. Låt oss anta att den här leverantören använder Arbor för att filtrera trafik och filter i kanten av sitt nätverk.

Bandbredden som Arbor kan "bearbeta" är begränsad, och leverantören kan naturligtvis inte ständigt passera trafiken från alla sina partners som beställer denna tjänst genom filtreringsutrustning. Därför filtreras inte trafiken under normala förhållanden.

Låt oss anta att det finns en SYN översvämningsattack. Även om du beställt en tjänst som automatiskt byter trafik till filtrering vid en attack, sker detta inte direkt. I en minut eller mer förblir du under attack. Och detta kan leda till fel på din utrustning eller försämring av tjänsten. I det här fallet kommer en begränsning av trafiken vid kantens routing, även om det kommer att leda till att vissa TCP-sessioner inte kommer att etableras under denna tid, att rädda din infrastruktur från problem i större skala.

exempel 2

Ett onormalt stort antal SYN-paket kan inte bara vara resultatet av en SYN-översvämningsattack. Låt oss anta att du tillhandahåller en tjänst där du samtidigt kan ha cirka 100 tusen TCP-anslutningar (till ett datacenter).

Låt oss säga att som ett resultat av ett kortvarigt problem med en av dina huvudleverantörer, sparkas hälften av dina sessioner. Om din applikation är utformad på ett sådant sätt att den, utan att tänka två gånger, omedelbart (eller efter ett visst tidsintervall som är lika för alla sessioner) försöker återupprätta anslutningen, kommer du att få minst 50 tusen SYN-paket ungefär samtidigt.

Om du till exempel måste köra ssl/tls-handskakning ovanpå dessa sessioner, vilket innebär utbyte av certifikat, så kommer detta att vara en mycket starkare "DDOS" än en enkel ur synvinkel att tömma resurser för din lastbalanserare. SYN översvämning. Det verkar som att balansörer borde hantera sådana händelser, men... tyvärr står vi inför ett sådant problem.

Och, naturligtvis, kommer en polis på kanten-routern att rädda din utrustning även i detta fall.

Den tredje nivån av skydd mot DDOS/DOS är dina brandväggsinställningar.

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

rådet

Försök att ge brandväggen så lite arbete som möjligt, filtrera bort så mycket som möjligt på de två första försvarslinjerna. Och det är varför.

Har det någonsin hänt dig att du av en slump, medan du genererade trafik för att till exempel kontrollera hur motståndskraftigt operativsystemet på dina servrar är mot DDOS-attacker, "dödade" din brandvägg, laddade den till 100 procent, med trafik med normal intensitet ? Om inte, kanske det helt enkelt beror på att du inte har provat?

Generellt sett är en brandvägg, som sagt, en komplex sak, och den fungerar bra med kända sårbarheter och testade lösningar, men om du skickar något ovanligt, bara lite skräp eller paket med felaktiga rubriker, så är du med några, inte med Med så liten sannolikhet (baserat på min erfarenhet) kan du bedöva till och med förstklassig utrustning. Därför, i steg 2, med vanliga ACL:er (på L3/L4-nivå), tillåt därför endast trafik till ditt nätverk som ska komma in där.

Filtrera trafik på brandväggen

Låt oss fortsätta samtalet om brandväggen. Du måste förstå att DOS/DDOS-attacker bara är en typ av cyberattacker.

Förutom DOS/DDOS-skydd kan vi också ha något i stil med följande lista med funktioner:

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

Det är upp till dig att bestämma vad du behöver från den här listan.

Fortsättning

Källa: will.com