Dit artikel is het vierde in een serie artikelen getiteld 'Hoe je netwerkstructuur onder controle te krijgen'. Inhoud van alle artikelen in de reeks en links zijn te vinden hier.

In het eerste deel In dit hoofdstuk hebben we enkele aspecten van de netwerkbeveiliging van het segment 'Data Center' besproken. Dit deel is gewijd aan het segment 'Internet Access'.

Internettoegang

Het onderwerp beveiliging is ongetwijfeld een van de meest complexe onderwerpen in de wereld van dataverkeer netwerken. Net als in de voorgaande gevallen, zonder te pretenderen diepgaand en volledig te zijn, zal ik hier vrij eenvoudige, maar naar mijn mening belangrijke vragen bespreken waarvoor de antwoorden hopelijk helpen om het beveiligingsniveau van uw netwerk te verhogen.

Bij het auditen van dit segment moet je op de volgende aspecten letten:

ontwerp
BGP-instellingen
DOS/DDOS-bescherming
verkeersfiltering op de firewall

Ontwerp

Als voorbeeld van het ontwerp van dit segment voor een bedrijfsnetwerk zou ik aanbevelen handboek van Cisco in het kader van het SAFE-model.

Natuurlijk kan het zijn dat oplossingen van andere leveranciers aantrekkelijker voor je lijken (zie de Gartner-kwadrant van 2018), maar zonder je aan te sporen om deze ontwerpdetails te volgen, denk ik toch dat het nuttig is om de principes en ideeën die eraan ten grondslag liggen te begrijpen.

Opmerking
In SAFE is het segment 'Remote Access' een deel van 'Internet Access'. Maar in deze artikelenreeks zullen we het afzonderlijk bespreken.

De standaarduitrusting in dit segment voor een bedrijfsnetwerk bestaat uit

grensrouters
firewalls

Opmerking 1
In deze artikelenreeks, wanneer ik het heb over firewalls, bedoel ik NGFW.

Opmerking 2
Ik laat de bespreking van L2/L1 of overlay L2 over L3-oplossingen, die nodig zijn voor L1/L2-connectiviteit, achterwege en beperk me tot de vragen op L3-niveau en hoger. Onderdeel van de L1/L2-zaken zijn besproken in het hoofdstuk 'Schoonmaken en documenteren«.

Als je geen firewall in dit segment hebt gevonden, wees dan niet te snel met conclusies.

Laten we, net als in de vorig deel, beginnen met de vraag of het gebruik van een firewall in dit segment in jouw geval noodzakelijk is.

Ik kan zeggen dat het er op lijkt dat dit de meest rechtvaardige plek is om firewalls en complexe algoritmen voor verkeersfiltering te gebruiken. In deel 1 hebben we 4 factoren genoemd die het gebruik van firewalls in het datacentersegment kunnen belemmeren. Maar hier zijn ze al minder significant.

Example 1. Vertraging
Als het gaat om internet, heeft het geen zin om te spreken over vertragingen van zelfs 1 milliseconde. Daarom kan vertraging in dit segment geen factor zijn die het gebruik van een firewall beperkt.

Example 2. Prestaties
In sommige gevallen kan deze factor nog steeds aanzienlijk zijn. Daarom zult u mogelijk een deel van het verkeer (bijvoorbeeld verkeer van load balancers) om de firewall heen moeten leiden.

Example 3. Betrouwbaarheid
Deze factor moet nog steeds in overweging worden genomen, maar gezien de onbetrouwbaarheid van het internet zelf is de betekenis ervan voor dit segment niet zo belangrijk als voor het datacentrum.
Stel dat uw dienst draait op http/https (met korte sessies). In dat geval kunt u twee onafhankelijke bakken gebruiken (zonder HA), en bij een probleem met een van hen kunt u al het verkeer naar de tweede omleiden.
Of u kunt firewalls in transparante modus gebruiken en, wanneer ze tijdelijk uitvallen, verkeer om de firewalls heen laten stromen.

Daarom is het eerder juist alleen price kan de factor zijn die u ervan weerhoudt firewalls in dit segment te gebruiken.

Belangrijk!
Er is de verleiding om deze firewall te combineren met de firewall van het datacentrum (één firewall voor deze segmenten te gebruiken). Dit is in principe mogelijk, maar men moet begrijpen dat, omdat de 'Internet Access' firewall feitelijk aan de frontlinie van uw verdediging staat en 'tenminste een deel van het schadelijke verkeer op zich neemt', er natuurlijk een verhoogd risico is dat deze firewall uitvalt. Dus door dezelfde apparaten in deze twee segmenten te gebruiken, verkleint u aanzienlijk de beschikbaarheid van uw datacentrumsegment.

Zoals gewoonlijk is het belangrijk te begrijpen dat, afhankelijk van de dienst die het bedrijf levert, het ontwerp van dit segment sterk kan variëren. U kunt, zoals gewoonlijk, verschillende benaderingen kiezen afhankelijk van de vereisten.

Voorbeeld
Als u een contentprovider bent met een CDN-netwerk (zie bijvoorbeeld, een serie artikelen), dan wilt u misschien niet tientallen of zelfs honderden punten van aanwezigheid creëren met aparte apparaten voor routering en filtering van verkeer. Dit zou duur zijn en kan bovendien gewoon overbodig zijn.
Voor BGP is het helemaal niet nodig om dedicated routers te hebben; je kunt open-source tools gebruiken, zoals Quagga. Daarom heb je mogelijk alleen een server of meerdere servers, een switch en BGP nodig.
In dit geval kunnen je server of meerdere servers niet alleen als CDN-server fungeren, maar ook als router. Uiteraard zijn er hier veel details (zoals hoe je load balancing kunt realiseren), maar het is haalbaar en deze aanpak hebben we succesvol toegepast voor een van onze partners.
Je kunt meerdere datacenters hebben met volledige beveiliging (firewalls, DDoS-beschermingsdiensten die door je internetproviders worden aangeboden) en tientallen of honderden 'eenvoudige' presence points met alleen L2 switches en servers.
En hoe zit het met de beveiliging in dit geval?
Laten we bijvoorbeeld een populaire aanval bekijken die de laatste tijd veel aandacht heeft gekregen, DNS Amplification DDoS-aanval. Het gevaar ervan ligt in het feit dat er een grote hoeveelheid verkeer wordt gegenereerd, dat je uplinks voor 100% 'verstoppen'.
Wat hebben we in ons ontwerp?

Als je AnyCast gebruikt, wordt het verkeer verdeeld over je presence points. Als je totale bandbreedte terabytes is, dan beschermt dit je feitelijk (hoewel er de laatste tijd verschillende aanvallen zijn geweest met kwaadaardig verkeer van ongeveer een terabyte) tegen het 'vervallen' van je uplinks.

Als sommige uplinks toch 'verstoppen', breng je gewoon dit platform buiten dienst (stop met het aankondigen van het prefix).

Je kunt ook het aandeel van het verkeer dat je vanuit je 'volledige' (en dus beveiligde) datacenters retourneert, verhogen, waardoor een aanzienlijk deel van het kwaadaardige verkeer van onbeschermde presence points wordt verwijderd.
En nog een kleine opmerking bij dit voorbeeld. Als je een voldoende hoeveelheid verkeer via IX's retourneert, vermindert dat ook je blootstelling aan dergelijke aanvallen.

BGP-configuratie

Hier zijn twee onderwerpen.

Connectiviteit
BGP-configuratie

Over connectiviteit hebben we al een beetje gesproken in deel 1. Het komt erop neer dat verkeer naar je klanten op de optimale route moet verlopen. Hoewel optimaliteit niet altijd alleen over latentie gaat, is een lage latentie meestal de belangrijkste indicator van optimaliteit. Voor sommige bedrijven is dit belangrijker, voor andere minder. Het hangt allemaal af van de service die je aanbiedt.

Voorbeeld 1
Als u een beurs bent en als de tijdsintervallen voor uw klanten minder dan een milliseconde belangrijk zijn, dan is duidelijk dat er helemaal geen sprake kan zijn van internet.

Voorbeeld 2
Als u een gamebedrijf bent en als tientallen milliseconden belangrijk voor u zijn, dan is connectiviteit uiteraard erg belangrijk voor u.

Voorbeeld 3
Het is ook belangrijk te begrijpen dat, vanwege de eigenschappen van het TCP-protocol, de snelheid van gegevensoverdracht binnen één TCP-sessie ook afhankelijk is van de RTT (Round Trip Time). CDN-netwerken worden onder andere gebouwd om dit probleem op te lossen door de content delivery-servers dichter bij de eindgebruiker te plaatsen.

De studie van connectiviteit is een apart interessant onderwerp, dat een aparte artikel of reeks artikelen waard is en vereist een goed begrip van hoe het internet 'is ingericht'.

Nuttige bronnen:

ripe.net
bgp.he.net

Voorbeeld
Ik zal slechts één klein voorbeeld geven.
Stel dat uw datacenter zich in Moskou bevindt en dat u slechts één uplink heeft - Rostelecom (AS12389). In dit geval (single homed) heeft u geen BGP nodig, en als publieke adressen gebruikt u hoogstwaarschijnlijk een IP-pool van Rostelecom.
Stel dat u een bepaalde service aanbiedt en dat u voldoende klanten uit Oekraïne heeft, en zij klagen over hoge latenties. Bij onderzoek ontdekte u dat de IP-adressen van sommige van hen zich in het netwerk 37.52.0.0/21 bevinden.
Na het uitvoeren van een traceroute zag u dat het verkeer via AS1299 (Telia) ging, en na het uitvoeren van een ping kreeg u een gemiddelde RTT van 70 - 80 milliseconden. U kunt dit ook zien op de looking glass van Rostelecom.
Met de whois-tool (op de site ripe.net of met een lokale tool) kunt u gemakkelijk vaststellen dat het blok 37.52.0.0/21 toebehoort aan AS6849 (Ukrtelecom).
Vervolgens, door naar bgp.he.net te gaan, ziet u dat AS6849 geen relaties heeft met AS12389 (ze zijn geen klanten of uplinks van elkaar, en er is ook geen peering). Maar als u naar de peeringlijst voor AS6849 kijkt, ziet u bijvoorbeeld AS29226 (Mastertel) en AS31133 (Megafon).
Door de looking glass van deze providers te vinden, kunt u het pad en de RTT vergelijken. Voor Mastertel bijvoorbeeld zou de RTT al ongeveer 30 milliseconden zijn.
Dus als het verschil tussen 80 en 30 milliseconden aanzienlijk is voor uw service, moet u misschien nadenken over connectiviteit, een AS-nummer in RIPE aanvragen, uw IP-pool verkrijgen en aanvullende uplinks aansluiten of aanwezigheidspunten op IX'en creëren.

Met BGP heeft u niet alleen de mogelijkheid om de connectiviteit te verbeteren, maar reserveert u ook uw internetverbinding.

Dit document bevat aanbevelingen voor de configuratie van BGP. Hoewel deze aanbevelingen zijn gebaseerd op de 'best practices' van providers, zijn ze, zelfs als uw BGP-instellingen niet al te eenvoudig zijn, beslist nuttig en zouden ze daadwerkelijk deel moeten uitmaken van de hardening die we bespraken in het eerste deel.

DOS/DDOS-bescherming

DOS/DDOS-aanvallen zijn tegenwoordig een alledaagse realiteit voor veel bedrijven. In feite wordt u in een bepaalde vorm behoorlijk vaak aangevallen. Het feit dat u dit nog niet opmerkt, betekent alleen dat er tot nu toe geen gerichte aanval tegen u is georganiseerd en dat de beveiligingsmaatregelen die u gebruikt, zelfs zonder dat u zich daar bewust van bent (verschillende ingebouwde beveiligingen van besturingssystemen), voldoende zijn om de degradatie van de geleverde service voor u en uw klanten te minimaliseren.

Er zijn internetbronnen die op basis van logs van apparatuur in real-time mooie aanvalskaarten tekenen.

Hier U kunt de links naar hen vinden.

Mijn favoriete kaart van CheckPoint.

Bescherming tegen DDOS/DOS is meestal gelaagd. Om te begrijpen waarom, moet men de verschillende types DOS/DDOS-aanvallen kennen (zie bijvoorbeeld, hier of hier)

Dat wil zeggen, we hebben drie soorten aanvallen:

volumetrische aanvallen
protocol aanvallen
applicatie aanvallen

Als u zich tegen de laatste twee soorten aanvallen zelf kunt beschermen met bijvoorbeeld firewalls, dan kunt u zich niet tegen aanvallen beschermen die gericht zijn op het 'overbelasten' van uw uplinks (tenzij uw totale capaciteit van internetverbindingen in terabits wordt gemeten, bij voorkeur tientallen terabits).

Daarom is de eerste lijn van verdediging de bescherming tegen 'volumetrische' aanvallen en deze bescherming moet worden geboden door uw provider of providers. Als u zich dit nog niet heeft gerealiseerd, heeft u gewoon geluk gehad.

Voorbeeld
Stel dat u meerdere uplinks heeft, maar dat slechts één van de providers u deze bescherming kan bieden. Maar als al het verkeer via één provider gaat, hoe zit het dan met de connectiviteit die we eerder kort hebben besproken?
Tijdens de aanval zult u in dit geval gedeeltelijk concessies moeten doen aan de connectiviteit. Maar

dit is alleen tijdelijk tijdens een aanval. U kunt tijdens een aanval handmatig of automatisch BGP opnieuw configureren, zodat het verkeer alleen via de provider gaat die u een 'paraplu' biedt. Na de aanval kunt u de routing naar de oorspronkelijke staat terugbrengen.

het is niet noodzakelijk om al het verkeer om te leiden. Als u bijvoorbeeld ziet dat er via bepaalde uplinks of peering geen aanval is (of het verkeer niet significant is), kunt u doorgaan met het aankondigen van prefixes met concurrerende attributen naar deze BGP-buren.

De bescherming tegen 'protocolaanvallen' en 'toepassingsaanvallen' kunt u ook uitbesteden aan partners.
Hier is hier u kunt een goed onderzoek lezen (vertaling). Het is waar dat het artikel twee jaar oud is, maar het zal u een idee geven van de benaderingen die u kunt gebruiken om uzelf tegen DDoS-aanvallen te beschermen.

In principe kunt u zich hiermee tevredenstellen door uw bescherming volledig uit te besteden. Dit heeft zijn voordelen, maar er is ook een duidelijk nadeel. Het gaat erom (afhankelijk van wat uw bedrijf doet) over het voortbestaan van uw bedrijf. En deze zaken aan externe organisaties toevertrouwen...

Laten we daarom eens kijken hoe we een tweede en derde verdedigingslinie kunnen organiseren (als aanvulling op de bescherming van de provider).

Dus, de tweede verdedigingslinie bestaat uit filtering en verkeersbeperkingen (policers) aan de ingang van uw netwerk.

Voorbeeld 1
Laten we aannemen dat u 'onder een paraplu' van DDoS-bescherming bent gegaan met behulp van een van de providers. Laten we aannemen dat deze provider Arbor gebruikt voor verkeersfiltering en filters aan de grens van zijn netwerk.
De capaciteit die Arbor kan 'verwerken' is beperkt, en de provider kan natuurlijk niet voortdurend al het verkeer van zijn partners, die deze dienst hebben besteld, door het filterapparaat laten gaan. Daarom wordt verkeer onder normale omstandigheden niet gefilterd.
Laten we aannemen dat er een SYN flood-aanval plaatsvindt. Zelfs als u een dienst heeft besteld die het verkeer automatisch filtert bij een aanval, gebeurt dit niet meteen. Gedurende een minuut of langer blijft u onder aanval. Dit kan leiden tot falen van uw apparatuur of degradatie van de service. In dit geval zal het beperken van het verkeer op de grensroutering, hoewel het zal resulteren in het niet kunnen opzetten van enkele TCP-sessies gedurende deze tijd, uw infrastructuur beschermen tegen grotere problemen.

Voorbeeld 2
Een abnormaal groot aantal SYN-pakketten kan niet alleen een resultaat zijn van een SYN flood-aanval. Laten we aannemen dat u een service levert waarbij u tegelijkertijd ongeveer 100.000 TCP-verbindingen (in één datacenter) kunt hebben.
Stel dat als gevolg van een kortdurend probleem met een van uw belangrijkste aanbieders de helft van de sessies 'gekickt' wordt. Als uw applicatie zo is opgebouwd dat het, 'zonder veel nadenken', onmiddellijk (of na een vaste tijdsinterval voor alle sessies) probeert de verbinding opnieuw op te zetten, dan ontvangt u op ongeveer hetzelfde moment minimaal 50.000 SYN-pakketten.
Als bovenop deze sessies bijvoorbeeld een ssl/tls handshake moet plaatsvinden, wat de uitwisseling van certificaten inhoudt, is dit vanuit het perspectief van middelenuitputting voor uw load balancer een veel sterkere 'DDoS' dan een eenvoudige SYN flood. Het lijkt erop dat load balancers dergelijke gebeurtenissen moeten kunnen verwerken, maar... helaas zijn we met dit probleem volledig geconfronteerd.
En natuurlijk zal een policer op de grensrouter uw apparatuur ook in dit geval redden.

De derde verdedigingslijn tegen DDoS/DOS zijn de instellingen van uw firewall.

Hier kunt u zowel aanvallen van de tweede als de derde soort beperken. In het algemeen kan alles wat de firewall bereikt, hier gefilterd worden.

Tip
Probeer uw firewall zo min mogelijk werk te geven door zo veel mogelijk op de eerste twee verdedigingslinies te filteren. En dat is waarom.
Is it ever the case that while generating traffic to test, for instance, how resilient your server's operating system is to DDOS attacks, you inadvertently 'overloaded' your firewall, pushing it to 100% capacity with traffic of normal intensity? If not, maybe it's just because you haven't tried?
In general, a firewall, as I mentioned before, is a complex thing. It works well with known vulnerabilities and tested solutions, but if you send something unusual, just some junk or packets with incorrect headers, there's a significant (based on my experience) probability that you can confuse even high-end equipment. Therefore, at stage 2, using regular ACLs (at L3/L4 level), allow only the traffic that should enter your network.