Hoe u de controle over uw netwerkinfrastructuur kunt overnemen. Hoofdstuk drie. Netwerk veiligheid. Deel twee

Dit artikel is het vierde in de serie ‘Hoe u de controle over uw netwerkinfrastructuur overneemt’. De inhoud van alle artikelen in de serie en links zijn te vinden hier.

В het eerste deel In dit hoofdstuk hebben we gekeken naar enkele aspecten van netwerkbeveiliging in het datacentersegment. Dit deel zal gewijd zijn aan het segment “Internettoegang”.

Hoe u de controle over uw netwerkinfrastructuur kunt overnemen. Hoofdstuk drie. Netwerk veiligheid. Deel twee

Internettoegang

Het onderwerp beveiliging is ongetwijfeld een van de meest complexe onderwerpen in de wereld van datanetwerken. Net als in eerdere gevallen zal ik, zonder aanspraak te maken op diepgang en volledigheid, hier vrij eenvoudige, maar naar mijn mening belangrijke vragen beschouwen, waarvan de antwoorden, naar ik hoop, zullen helpen het beveiligingsniveau van uw netwerk te verhogen.

Let bij de audit van dit segment op de volgende aspecten:

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

ontwerp

Als voorbeeld van het ontwerp van dit segment voor een bedrijfsnetwerk zou ik aanraden руководство van Cisco binnenin VEILIGE modellen.

Natuurlijk zal de oplossing van andere leveranciers u misschien aantrekkelijker lijken (zie. Gartner Kwadrant 2018), maar zonder je aan te moedigen dit ontwerp in detail te volgen, vind ik het toch nuttig om de principes en ideeën erachter te begrijpen.

opmerking

In SAFE maakt het segment "Toegang op afstand" deel uit van het segment "Internettoegang". Maar in deze serie artikelen zullen we het afzonderlijk bekijken.

De standaarduitrusting in dit segment voor een bedrijfsnetwerk is

  • grens routers
  • firewalls

Opmerking 1

Als ik het in deze serie artikelen over firewalls heb, bedoel ik dat NGFW.

Opmerking 2

Ik laat de overweging achterwege van verschillende soorten L2/L1- of overlay-L2-over-L3-oplossingen die nodig zijn om L1/L2-connectiviteit te garanderen en beperk me alleen tot problemen op L3-niveau en hoger. Gedeeltelijk werden L1/L2-kwesties besproken in het hoofdstuk “Reiniging en documentatie".

Als u in dit segment geen firewall heeft gevonden, moet u niet overhaast conclusies trekken.

Laten we hetzelfde doen als in vorig deelLaten we beginnen met de vraag: is het in jouw geval nodig om in dit segment een firewall te gebruiken?

Ik kan zeggen dat dit de meest gerechtvaardigde plek lijkt om firewalls te gebruiken en complexe verkeersfilteralgoritmen toe te passen. IN delen van 1 We noemden 4 factoren die het gebruik van firewalls in het datacentersegment kunnen verstoren. Maar hier zijn ze niet meer zo belangrijk.

Voorbeeld 1. Vertraging

Wat het internet betreft, heeft het geen zin om te praten over vertragingen van zelfs maar één milliseconde. Daarom kan de vertraging in dit segment geen factor zijn die het gebruik van de firewall beperkt.

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

In sommige gevallen kan deze factor nog steeds significant zijn. Daarom moet u mogelijk toestaan ​​dat bepaald verkeer (bijvoorbeeld verkeer van load balancers) de firewall passeert.

Voorbeeld 3. Betrouwbaarheid

Met deze factor moet nog steeds rekening worden gehouden, maar gezien de onbetrouwbaarheid van internet zelf is het belang ervan voor dit segment niet zo groot als voor het datacenter.

Laten we er dus van uitgaan dat uw service bovenop http/https staat (met korte sessies). In dit geval kunt u twee onafhankelijke boxen gebruiken (zonder HA) en als er een routeringsprobleem is met een van deze, breng dan al het verkeer over naar de tweede.

Of u kunt firewalls in transparante modus gebruiken en, als deze falen, het verkeer de firewall laten omzeilen terwijl u het probleem oplost.

Daarom waarschijnlijk gewoon prijs kan de factor zijn die u zal dwingen het gebruik van firewalls in dit segment op te geven.

Belangrijk!

De verleiding is groot om deze firewall te combineren met de datacenterfirewall (gebruik voor deze segmenten één firewall). De oplossing is in principe mogelijk, maar je moet dat begrijpen omdat Een firewall voor internettoegang vormt feitelijk de voorhoede van uw verdediging en ‘neemt’ op zijn minst een deel van het kwaadaardige verkeer over. Vervolgens moet u uiteraard rekening houden met het verhoogde risico dat deze firewall wordt uitgeschakeld. Dat wil zeggen: door dezelfde apparaten in deze twee segmenten te gebruiken, vermindert u de beschikbaarheid van uw datacentersegment aanzienlijk.

Zoals altijd moet u begrijpen dat, afhankelijk van de service die het bedrijf biedt, het ontwerp van dit segment sterk kan variëren. Zoals altijd kunt u verschillende benaderingen kiezen, afhankelijk van uw vereisten.

Voorbeeld

Als u een contentprovider bent, met een CDN-netwerk (zie bijvoorbeeld serie artikelen), dan wilt u misschien geen infrastructuur creëren over tientallen of zelfs honderden aanwezigheidspunten met behulp van afzonderlijke apparaten voor het routeren en filteren van verkeer. Het zal duur zijn, en misschien is het gewoon niet nodig.

Voor BGP hoef je niet per se over speciale routers te beschikken, je kunt open-source tools gebruiken zoals quagga. Het enige dat u dus nodig heeft, is misschien een server of meerdere servers, een switch en BGP.

In dit geval kunnen uw server of meerdere servers niet alleen de rol spelen van een CDN-server, maar ook van een router. Natuurlijk zijn er nog veel details (zoals hoe we voor evenwicht kunnen zorgen), maar het is haalbaar en het is een aanpak die we met succes hebben toegepast voor een van onze partners.

U kunt beschikken over verschillende datacenters met volledige bescherming (firewalls, DDOS-beveiligingsdiensten geleverd door uw internetproviders) en tientallen of honderden “vereenvoudigde” points of presence met alleen L2-switches en servers.

Maar hoe zit het in dit geval met de bescherming?

Laten we bijvoorbeeld eens kijken naar de recentelijk populaire DNS-versterking DDOS-aanval. Het gevaar schuilt in het feit dat er een grote hoeveelheid verkeer wordt gegenereerd, waardoor simpelweg 100% van al uw uplinks wordt ‘verstoppen’.

Wat hebben we in het geval van ons ontwerp.

  • Maakt u gebruik van AnyCast, dan wordt het verkeer verdeeld tussen uw Points of Presence. Als uw totale bandbreedte terabits bedraagt, beschermt dit op zichzelf (de laatste tijd zijn er echter verschillende aanvallen geweest met kwaadaardig verkeer in de orde van terabits) u tegen “overlopende” uplinks
  • Als sommige uplinks echter verstopt raken, verwijdert u eenvoudigweg deze site uit de dienst (stop met het adverteren van het voorvoegsel)
  • u kunt ook het aandeel verkeer vergroten dat vanuit uw ‘volledige’ (en dienovereenkomstig beschermde) datacenters wordt verzonden, waardoor een aanzienlijk deel van het kwaadaardige verkeer van onbeschermde aanwezigheidspunten wordt verwijderd

En nog een kleine opmerking bij dit voorbeeld. Als u voldoende verkeer via IX's verzendt, vermindert dit ook uw kwetsbaarheid voor dergelijke aanvallen

BGP instellen

Er zijn hier twee onderwerpen.

  • Connectiviteit
  • BGP instellen

We hebben het al een beetje gehad over connectiviteit in delen van 1. Het gaat erom ervoor te zorgen dat het verkeer naar uw klanten het optimale pad volgt. Hoewel optimaliteit niet altijd alleen maar over latentie gaat, is lage latentie meestal de belangrijkste indicator voor optimaliteit. Voor sommige bedrijven is dit belangrijker, voor andere minder. Het hangt allemaal af van de service die u levert.

voorbeeld 1

Als u een uitwisselingsorganisatie bent en tijdsintervallen van minder dan milliseconden belangrijk zijn voor uw klanten, dan kan er uiteraard helemaal geen sprake zijn van enige vorm van internet.

voorbeeld 2

Als je een gamingbedrijf bent en tientallen milliseconden belangrijk voor je zijn, dan is connectiviteit natuurlijk erg belangrijk voor je.

voorbeeld 3

U moet ook begrijpen dat, vanwege de eigenschappen van het TCP-protocol, de gegevensoverdrachtsnelheid binnen één TCP-sessie ook afhankelijk is van RTT (Round Trip Time). Er worden ook CDN-netwerken gebouwd om dit probleem op te lossen door de distributieservers voor inhoud dichter bij de consument van deze inhoud te brengen.

De studie van connectiviteit is op zichzelf een interessant onderwerp, een eigen artikel of serie artikelen waard, en vereist een goed begrip van hoe het internet ‘werkt’.

Nuttige bronnen:

ripe.net
bgp.he.net

Voorbeeld

Ik zal slechts één klein voorbeeld geven.

Laten we aannemen dat uw datacenter zich in Moskou bevindt en dat u één enkele uplink heeft: Rostelecom (AS12389). In dit geval (single homed) heeft u geen BGP nodig en gebruikt u hoogstwaarschijnlijk de adrespool van Rostelecom als openbare adressen.

Laten we aannemen dat u een bepaalde service levert en dat u voldoende klanten uit Oekraïne heeft, en zij klagen over lange vertragingen. Tijdens je onderzoek kwam je erachter dat de IP-adressen van sommige van hen zich in het 37.52.0.0/21-raster bevinden.

Door een traceroute uit te voeren, zag je dat het verkeer via AS1299 (Telia) liep, en door een ping uit te voeren, kreeg je een gemiddelde RTT van 70 - 80 milliseconden. Dit kun je ook zien op kijkglas Rostelecom.

Met behulp van het whois-hulpprogramma (op rip.net of een lokaal hulpprogramma) kunt u eenvoudig vaststellen dat blok 37.52.0.0/21 tot AS6849 (Ukrtelecom) behoort.

Vervolgens door naar te gaan bgp.he.net je ziet dat AS6849 geen relatie heeft met AS12389 (ze zijn geen clients, noch uplinks naar elkaar, en ze hebben ook geen peering). Maar als je kijkt lijst van soortgenoten voor AS6849 zie je bijvoorbeeld AS29226 (Mastertel) en AS31133 (Megafon).

Zodra u het kijkglas van deze aanbieders heeft gevonden, kunt u het pad en de RTT vergelijken. Voor Mastertel zal RTT bijvoorbeeld ongeveer 30 milliseconden zijn.

Dus als het verschil tussen 80 en 30 milliseconden aanzienlijk is voor uw dienst, dan moet u misschien nadenken over connectiviteit, uw AS-nummer en uw adrespool van RIPE verkrijgen en extra uplinks aansluiten en/of aanwezigheidspunten op IX's creëren.

Wanneer u BGP gebruikt, heeft u niet alleen de mogelijkheid om de connectiviteit te verbeteren, maar onderhoudt u ook redundant uw internetverbinding.

Dit document bevat aanbevelingen voor het configureren van BGP. Ondanks het feit dat deze aanbevelingen zijn ontwikkeld op basis van de “best practice” van providers, zijn ze toch (als uw BGP-instellingen niet helemaal basaal zijn) ongetwijfeld nuttig en zouden ze in feite deel moeten uitmaken van de verharding die we hebben besproken in het eerste deel.

DOS/DDOS-bescherming

Nu zijn DOS/DDOS-aanvallen voor veel bedrijven een dagelijkse realiteit geworden. Sterker nog, je wordt vrij vaak aangevallen, in een of andere vorm. Het feit dat u dit nog niet heeft opgemerkt, betekent alleen maar dat er nog geen gerichte aanval tegen u is georganiseerd, en dat de beschermingsmaatregelen die u gebruikt, misschien zelfs zonder het te weten (diverse ingebouwde beveiligingen van besturingssystemen), voldoende zijn om ervoor te zorgen dat de verslechtering van de dienstverlening voor u en uw klanten tot een minimum wordt beperkt.

Er zijn internetbronnen die, op basis van apparatuurlogboeken, in realtime prachtige aanvalskaarten tekenen.

Hier u kunt links ernaar vinden.

Mijn favoriet kaart van CheckPoint.

Bescherming tegen DDOS/DOS is meestal gelaagd. Om te begrijpen waarom, moet je begrijpen welke soorten DOS/DDOS-aanvallen er bestaan ​​(zie bijvoorbeeld hier of hier)

Dat wil zeggen, we hebben drie soorten aanvallen:

  • volumetrische aanvallen
  • protocol aanvallen
  • applicatie-aanvallen

Als u uzelf tegen de laatste twee soorten aanvallen kunt beschermen door bijvoorbeeld firewalls te gebruiken, dan kunt u uzelf niet beschermen tegen aanvallen die erop gericht zijn uw uplinks te ‘overweldigen’ (uiteraard, als uw totale capaciteit aan internetkanalen niet in terabits wordt berekend, of beter nog, in tientallen terabit).

Daarom is de eerste verdedigingslinie bescherming tegen ‘volumetrische’ aanvallen, en uw provider(s) moeten u deze bescherming bieden. Als je dit nog niet beseft, dan heb je voorlopig gewoon geluk.

Voorbeeld

Stel dat u meerdere uplinks heeft, maar slechts één van de providers kan u deze bescherming bieden. Maar als al het verkeer via één provider gaat, hoe zit het dan met de connectiviteit die we eerder kort bespraken?

In dit geval zul je tijdens de aanval de connectiviteit gedeeltelijk moeten opofferen. Maar

  • dit is alleen voor de duur van de aanval. Bij een aanval kun je BGP handmatig of automatisch opnieuw configureren, zodat het verkeer alleen via de provider loopt die je de ‘paraplu’ ter beschikking stelt. Nadat de aanval voorbij is, kunt u de routing terugbrengen naar de vorige staat
  • Het is niet nodig om al het verkeer over te dragen. Als u bijvoorbeeld ziet dat er geen aanvallen plaatsvinden via sommige uplinks of peerings (of dat het verkeer niet significant is), kunt u doorgaan met het adverteren van voorvoegsels met concurrerende kenmerken richting deze BGP-buren.

U kunt de bescherming tegen “protocolaanvallen” en “applicatieaanvallen” ook delegeren aan uw partners.
Hier hier je kunt een goede studie lezen (vertaling). Het is waar dat het artikel twee jaar oud is, maar het geeft je een idee van de aanpak om jezelf te beschermen tegen DDOS-aanvallen.

In principe kunt u zich hiertoe beperken en uw bescherming volledig uitbesteden. Er zijn voordelen aan deze beslissing verbonden, maar er is ook een duidelijk nadeel. Feit is dat we (opnieuw, afhankelijk van wat uw bedrijf doet) kunnen praten over het voortbestaan ​​van het bedrijf. En zulke dingen aan derden toevertrouwen...

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

De tweede verdedigingslinie bestaat dus uit filtering en verkeersbegrenzers (politie) bij de ingang van uw netwerk.

voorbeeld 1

Stel dat je jezelf met behulp van een van de aanbieders met een paraplu hebt ingedekt tegen DDOS. Laten we aannemen dat deze provider Arbor gebruikt om verkeer en filters aan de rand van zijn netwerk te filteren.

De bandbreedte die Arbor kan ‘verwerken’ is beperkt, en de provider kan uiteraard niet voortdurend het verkeer van al zijn partners die deze dienst bestellen via filterapparatuur doorgeven. Onder normale omstandigheden wordt het verkeer daarom niet gefilterd.

Laten we aannemen dat er een SYN flood-aanval plaatsvindt. Zelfs als je een dienst hebt besteld die bij een aanval automatisch het verkeer overschakelt naar filtering, gebeurt dit niet meteen. Een minuut of langer blijf je aangevallen. En dit kan leiden tot uitval van uw apparatuur of verslechtering van de dienstverlening. In dit geval zal het beperken van het verkeer op de edge-routering, hoewel dit ertoe zal leiden dat sommige TCP-sessies gedurende deze periode niet tot stand zullen komen, uw infrastructuur redden van grootschaliger problemen.

voorbeeld 2

Een abnormaal groot aantal SYN-pakketten kan niet alleen het resultaat zijn van een SYN-flood-aanval. Laten we aannemen dat u een dienst levert waarbij u tegelijkertijd ongeveer 100 TCP-verbindingen kunt hebben (naar één datacenter).

Laten we zeggen dat als gevolg van een kortdurend probleem met een van uw belangrijkste providers, de helft van uw sessies wordt stopgezet. Als uw applicatie zo is ontworpen dat deze, zonder er twee keer over na te denken, onmiddellijk (of na een tijdsinterval dat voor alle sessies hetzelfde is) probeert de verbinding te herstellen, dan ontvangt u ongeveer 50 SYN-pakketten tegelijkertijd.

Als u bijvoorbeeld ssl/tls-handshake moet uitvoeren bovenop deze sessies, waarbij certificaten moeten worden uitgewisseld, dan zal dit, vanuit het oogpunt van het uitputten van de bronnen voor uw load balancer, een veel sterkere “DDOS” zijn dan een eenvoudige SYN-overstroming. Het lijkt erop dat balancers dergelijke gebeurtenissen moeten aanpakken, maar... helaas worden we met een dergelijk probleem geconfronteerd.

En natuurlijk zal een politieagent op de edge-router ook in dit geval uw apparatuur redden.

Het derde beschermingsniveau tegen DDOS/DOS zijn uw firewallinstellingen.

Hier kun je zowel aanvallen van het tweede als het derde type stoppen. Over het algemeen kan alles wat de firewall bereikt hier worden gefilterd.

raad

Probeer de firewall zo min mogelijk werk te geven en zoveel mogelijk uit de eerste twee verdedigingslinies te filteren. En dat is waarom.

Is het u ooit overkomen dat u, terwijl u verkeer genereerde om bijvoorbeeld te controleren hoe resistent het besturingssysteem van uw servers is tegen DDOS-aanvallen, bij toeval uw firewall “doodde” en deze op 100 procent laadde, met verkeer op normale intensiteit? ? Als dat niet het geval is, komt het misschien gewoon omdat je het nog niet hebt geprobeerd?

Over het algemeen is een firewall, zoals ik al zei, een complex iets, en het werkt goed met bekende kwetsbaarheden en geteste oplossingen, maar als je iets ongewoons verzendt, alleen maar wat rommel of pakketten met onjuiste headers, dan ben je met sommige, niet met Met zo'n kleine kans (gebaseerd op mijn ervaring) kun je zelfs topapparatuur verdoven. Daarom moet u in fase 2, met behulp van gewone ACL's (op L3/L4-niveau), alleen verkeer naar uw netwerk toelaten dat daar zou moeten binnenkomen.

Verkeer op de firewall filteren

Laten we het gesprek over de firewall voortzetten. U moet begrijpen dat DOS/DDOS-aanvallen slechts één type cyberaanval zijn.

Naast DOS/DDOS-bescherming kunnen we ook zoiets als de volgende lijst met functies hebben:

  • firewalling van toepassingen
  • preventie van bedreigingen (antivirus, anti-spyware en kwetsbaarheid)
  • URL-filtering
  • gegevensfiltering (inhoudsfiltering)
  • bestandsblokkering (blokkering van bestandstypen)

Het is aan jou om te beslissen wat je uit deze lijst nodig hebt.

Wordt vervolgd

Bron: www.habr.com

Voeg een reactie