Ten artykuł jest czwartym w cyklu artykułów „Jak przejąć kontrolę nad infrastrukturą sieciową”. Zawartość wszystkich artykułów z cyklu oraz linki można znaleźć tutaj.

W pierwszej części W tej części przyjrzeliśmy się niektórym aspektom bezpieczeństwa sieci segmentu „Data Center”. Ta część będzie poświęcona segmentowi „Internet Access”.

Dostęp do internetu

Temat bezpieczeństwa niewątpliwie jest jednym z najbardziej złożonych tematów w świecie sieci transmisji danych. Jak w poprzednich przypadkach, nie aspirując do dogłębności i pełności, przedstawię tutaj dość proste, ale, moim zdaniem, ważne kwestie, na które mam nadzieję, odpowiedzi pomogą podnieść poziom zabezpieczeń twojej sieci.

Podczas audytu tego segmentu zwróć uwagę na następujące aspekty:

projekt
ustawienia BGP
Ochrona przed DOS/DDOS
filtracja ruchu na zaporze

Projekt

Jako przykład projektu tego segmentu dla sieci przedsiębiorstwa polecam przewodnik od Cisco w ramach modelu SAFE.

Oczywiście, możliwe, że rozwiązania innych dostawców wydadzą ci się bardziej atrakcyjne (zob. kwadrant Gartnera z 2018 roku), ale, nie namawiając was do ścisłego podążania za tym projektem, uważam za użyteczne zrozumienie zasad i idei leżących u jego podstaw.

Uwagi
W segmencie SAFE „Remote Access” jest częścią „Internet Access”. Jednak w tym cyklu artykułów będziemy rozpatrywać go osobno.

Standardowym zestawem sprzętu w tym segmencie dla sieci przedsiębiorstwa (enterprise network) są

routery brzegowe (border routers)
zapory sieciowe (firewall)

Uwaga 1
W tym cyklu artykułów, gdy mówię o zaporach, mam na myśli NGFW.

Uwaga 2
Pomijam rozważania różnego rodzaju rozwiązań L2/L1 lub nadbudowanych L2 nad L3 niezbędnych do zapewnienia łączności L1/L2 i ograniczam się tylko do kwestii poziomu L3 i wyżej. Częściowo kwestie L1/L2 zostały omówione w rozdziale „Czyszczenie i dokumentowanie«.

Jeśli nie znalazłeś zapory w tym segmencie, nie spiesz się z wnioskami.

Zacznijmy, jak w poprzedniej części, od pytania, czy w twoim przypadku konieczne jest stosowanie zapory w tym segmencie?

Mogę powiedzieć, że wydaje się to najbardziej uzasadnionym miejscem do wykorzystania zapór i zastosowania skomplikowanych algorytmów filtracji ruchu. W części 1 wspomnieliśmy o 4 czynnikach, które mogą utrudnić użycie zapór w segmencie centrum danych. Jednak tutaj nie są one już tak istotne.

Przykład 1. Opóźnienie
Mówiąc o internecie, nie ma sensu wspominać o opóźnieniach rzędu 1 milisekundy. Dlatego opóźnienie w tej dziedzinie nie może być czynnikiem ograniczającym wykorzystanie zapory ogniowej.

Przykład 2. Wydajność
W niektórych sytuacjach ten czynnik może wciąż być istotny. Dlatego część ruchu (na przykład ruch z ładowarek równoważących) będziesz musiał puścić omijając zaporę ogniową.

Przykład 3. Niezawodność
Ten czynnik wciąż trzeba brać pod uwagę, ale biorąc pod uwagę zawodność samego internetu, jego znaczenie dla tego segmentu nie jest tak istotne, jak dla centrum danych.
Załóżmy, że twój serwis działa na http/https (z krótkimi sesjami). W takim przypadku możesz użyć dwóch niezależnych skrzynek (bez HA) i w przypadku problemów z jedną z nich przekierować cały ruch na drugą.
Możesz także używać zapór ogniowych w trybie przezroczystym i w przypadku ich awarii w czasie rozwiązywania problemu puścić ruch omijając zapory.

Dlatego najprawdopodobniej to tylko cena może być tym czynnikiem, który skłoni cię do porzucenia użycia zapór ogniowych w tym segmencie.

WAŻNE!
Pojawia się pokusa połączenia tej zapory ogniowej z zaporą centrum danych (używanie jednej zapory dla tych segmentów). Rozwiązanie to w zasadzie jest możliwe, ale trzeba zrozumieć, że ponieważ zapora 'Dostęp do Internetu' w rzeczywistości znajduje się na przedniej linii twojej obrony i 'bierze na siebie' przynajmniej część złośliwego ruchu, należy oczywiście brać pod uwagę zwiększone ryzyko, że ta zapora mogłaby ulec awarii. Innymi słowy, korzystając z tych samych urządzeń w obu tych segmentach, znacznie obniżysz dostępność twojego segmentu centrum danych.

Jak zwykle, trzeba zrozumieć, że w zależności od usługi, którą firma świadczy, projekt tego segmentu może się znacznie różnić. Jak zwykle, możesz wybrać różne podejścia w zależności od wymagań.

Przykład
Jeśli jesteś dostawcą treści, z siecią CDN (patrz, na przykład, seria artykułów), to możesz nie chcieć tworzyć w dziesiątkach, a nawet setkach punktów obecności infrastruktury z wykorzystaniem oddzielnych urządzeń do routingu i filtrowania ruchu. Będzie to kosztowne, a poza tym może być po prostu zbyteczne.
W przypadku BGP nie musisz mieć dedykowanych routerów, możesz korzystać z narzędzi open-source, takich jak Quagga. Dlatego być może wszystko, czego potrzebujesz, to serwer lub kilka serwerów, przełącznik i BGP.
W takim przypadku twój serwer lub kilka serwerów mogą pełnić rolę nie tylko serwera CDN, ale także routera. Oczywiście, istnieje wiele szczegółów (takich jak zapewnienie równoważenia obciążenia), ale to jest wykonalne, a to podejście z powodzeniem zastosowaliśmy u jednego z naszych partnerów.
Możesz mieć kilka centrów danych z pełnym zabezpieczeniem (zapory sieciowe, usługi ochrony przed atakami DDOS oferowane przez twoich dostawców internetowych) i dziesiątki lub setki 'uproszczonych' punktów obecności tylko z przełącznikami L2 i serwerami.
A co z zabezpieczeniem w tym przypadku?
Przyjrzyjmy się na przykład popularnemu ostatnio ataku DDoS amplifikacji DNS. Jego niebezpieczeństwo polega na tym, że generowana jest ogromna ilość ruchu, który po prostu 'zapcha' w 100% wszystkie twoje uplinki.
Co mamy w przypadku naszego projektu.

jeśli używasz AnyCast, to ruch rozkłada się pomiędzy twoimi punktami obecności. Jeśli suma pasma szerokiego wynosi terabity, to samo w sobie (choć w ostatnim czasie miało miejsce kilka ataków z złośliwym ruchem sięgającym terabita) chroni cię przed 'przepełnieniem' uplinków.

jeśli jednak jakieś uplinki 'zaplątały się', to po prostu wyłączasz tę lokalizację z eksploatacji (przestajesz ogłaszać prefiks).

możesz także zwiększyć udział ruchu, który jest przekazywany z twoich “pełnowartościowych” (a tym samym zabezpieczonych) centrów danych, w ten sposób eliminując znaczną część złośliwego ruchu z niechronionych punktów obecności.
I jeszcze mała uwaga do tego przykładu. Jeśli odpowiednią ilość ruchu przesyłasz przez IX-y, to również zmniejsza to twoją podatność na takie ataki.

Konfiguracja BGP

Są dwie tematy.

Łączność
Konfiguracja BGP

O łączności już trochę rozmawialiśmy w części 1. Chodzi o to, aby ruch do twoich klientów szedł optymalną trasą. Chociaż optymalność — to nie zawsze tylko kwestia opóźnienia, ale zazwyczaj niskie opóźnienie jest głównym wskaźnikiem optymalności. Dla niektórych firm jest to ważniejsze, dla innych — mniej. Wszystko zależy od usługi, którą świadczysz.

Przykład 1
Jeśli jesteś giełdą, a dla twoich klientów ważne są opóźnienia poniżej milisekundy, to oczywiste, że nie ma mowy o internecie w ogóle.

Przykład 2
Jeśli jesteś firmą gamingową i dla ciebie ważne są setki milisekund, to oczywiście łączność ma dla ciebie ogromne znaczenie.

Przykład 3
Należy również zrozumieć, że ze względu na właściwości protokołu TCP prędkość transferu danych w ramach jednej sesji TCP zależy również od RTT (Round Trip Time). Sieci CDN powstają również w celu rozwiązania tego problemu, przenosząc serwery dostarczania treści bliżej konsumenta tych treści.

Badanie łączności to osobny interesujący temat, zasługujący na osobny artykuł lub serię artykułów i wymaga dobrego zrozumienia, jak „działa” internet.

Przydatne zasoby:

ripe.net
bgp.he.net

Przykład
Podam tylko jeden mały przykład.
Załóżmy, że twoje centrum danych znajduje się w Moskwie, a ty masz tylko jedno połączenie uplinkowe – Rostelecom (AS12389). W tym przypadku (single homed) BGP nie jest ci potrzebny i jako publiczne adresy prawdopodobnie używasz puli adresowej od Rostelecomu.
Załóżmy, że świadczysz jakiś serwis i masz wystarczającą liczbę klientów z Ukrainy, którzy skarżą się na dużą latencję. Podczas badania odkryłeś, że adresy IP niektórych z nich znajdują się w zakresie 37.52.0.0/21.
Wykonując traceroute, zauważyłeś, że ruch przechodzi przez AS1299 (Telia), a wykonując ping, otrzymałeś średni RTT 70 – 80 milisekund. Możesz zobaczyć to również na looking glass Rostelecomu.
Dzięki narzędziu whois (na stronie ripe.net lub lokalnemu narzędziu) łatwo możesz ustalić, że blok 37.52.0.0/21 należy do AS6849 (Ukrtelecom).
Następnie, wchodząc na bgp.he.net widzi, że AS6849 nie ma relacji z AS12389 (nie są ani klientami, ani uplinkami dla siebie, nie mają również peeringu). Ale jeśli spojrzysz na listę peerów dla AS6849, zobaczysz na przykład AS29226 (Mastertel) i AS31133 (Megafon).
Znajdując looking glass tych dostawców, możesz porównać ścieżkę i RTT. Na przykład, dla Mastertel RTT wyniesie już około 30 milisekund.
Tak więc, jeśli różnica między 80 a 30 milisekundami jest istotna dla twojego serwisu, to być może powinieneś zastanowić się nad łącznością, uzyskać w RIPE swój numer AS, swoją pulę adresów i podłączyć dodatkowe uplinki lub stworzyć punkty obecności w IX-ach.

Korzystając z BGP, nie tylko masz możliwość poprawy łączności, ale także rezerwujesz swoje połączenie z Internetem.

Ten dokument zawiera zalecenia dotyczące konfiguracji BGP. Mimo że te zalecenia zostały opracowane w oparciu o «best practice» dostawców, są zdecydowanie przydatne, a wręcz powinny być częścią hardeningu, o którym mówiliśmy w pierwszej części.

Ochrona przed DOS/DDOS

Obecnie ataki DOS/DDOS stały się codziennością dla wielu firm. W rzeczywistości, w tak czy inaczej są one dość często wymierzane w was, nawet jeśli ich nie zauważacie. To, że obecnie nie dostrzegacie ataku, jedynie wskazuje na to, że nie została jeszcze zorganizowana ukierunkowana akcja przeciwko wam, a środki ochrony, z których korzystacie, nawet nieświadomi tego (różne wbudowane zabezpieczenia system operacyjnych), wystarczają, aby minimalizować degradowanie świadczonych usług dla was i waszych klientów.

Istnieją zasoby internetowe, które na podstawie logów z urządzeń w czasie rzeczywistym rysują piękne mapy ataków.

Tutaj można znaleźć linki do nich.

Moja ulubiona mapa od CheckPoint.

Ochrona przed DDOS/DOS zazwyczaj jest zróżnicowana. Aby zrozumieć dlaczego, trzeba wiedzieć, jakie typy ataków DOS/DDOS istnieją (patrz na przykład, tutaj lub tutaj)

Mamy trzy typy ataków:

ataki wolumetryczne
ataki protokołów
ataki aplikacji

Jeśli względem ostatnich dwóch typów ataków możesz bronić się samodzielnie, na przykład za pomocą firewalli, to przed atakami skierowanymi na «przepełnianie» twoich uplinków nie obronisz się samodzielnie (oczywiście jeśli twoja całkowita przepustowość łączy internetowych nie przekracza terabitów, a najlepiej dziesiątek terabitów).

Dlatego pierwszą linią obrony jest ochrona przed «wolumetrycznymi» atakami, a tę ochronę powinien zapewnić ci dostawca lub dostawcy. Jeśli tego jeszcze nie zdajesz sobie sprawy, to po prostu masz szczęście.

Przykład
Załóżmy, że masz kilka uplinków, ale tylko jeden z dostawców może zapewnić ci tę ochronę. Ale jeśli cały ruch będzie przechodził przez jednego dostawcę, to jak ma się to do łączności, którą krótko omówiliśmy wcześniej?
W czasie ataku w tym przypadku będziesz musiał częściowo poświęcić łączność. Ale

to tylko podczas ataku. Możecie w przypadku ataku ręcznie lub automatycznie skonfigurować BGP w taki sposób, aby ruch kierował się tylko przez dostawcę, który zapewnia wam "parasolkę". Po zakończeniu ataku możecie przywrócić routing do poprzedniego stanu.

nie ma potrzeby przekierowywania całego ruchu. Jeśli na przykład widzicie, że przez niektóre uplinki lub peering nie ma ataku (lub ruch nie jest znaczący), możecie nadal ogłaszać prefiksy z konkurencyjnymi atrybutami w stronę tych sąsiadów BGP.

Ochronę przed "atakami protokołów" i "atakami aplikacji" możecie również powierzyć partnerom.
Oto tutaj możecie przeczytać dobre badanie (tłumaczenie). Prawda, że artykuł ma dwa lata, ale da to wam wyobrażenie o podejściu do tego, jak możecie zabezpieczyć się przed atakami DDoS.

W zasadzie możecie na tym poprzestać, w pełni oddając swoją ochronę w outsourcing. To rozwiązanie ma swoje zalety, ale ma też oczywistą wadę. Chodzi o to, że może to dotyczyć (znowu w zależności od tego, czym zajmuje się wasza firma) przetrwania biznesu. I powierzenie takich spraw zewnętrznym organizacjom…

Dlatego przyjrzyjmy się, jak zorganizować drugą i trzecią linię obrony (jako uzupełnienie ochrony od dostawcy).

Tak więc, drugą linią obrony jest filtrowanie i ograniczniki ruchu (policery) na wejściu do waszej sieci.

Przykład 1
Załóżmy, że "zamknęliście się pod parasolką" przed DDoS za pomocą jednego z dostawców. Załóżmy, że ten dostawca używa Arbor do filtrowania ruchu i filtrów na granicy swojej sieci.
Pasmo, które może "przetwarzać" Arbor jest ograniczone, a dostawca oczywiście nie może stale przepuszczać ruchu wszystkich swoich partnerów, którzy zamówili tę usługę, przez sprzęt filtrujący. Dlatego w normalnych warunkach ruch nie jest filtrowany.
Załóżmy, że dochodzi do ataku SYN flood. Nawet jeśli zamówiłeś usługę, w ramach której podczas ataku ruch jest automatycznie kierowany na filtrację, nie dzieje się to natychmiast. Przez minutę lub dłużej pozostajesz pod atakiem. Może to prowadzić do awarii sprzętu lub degradacji usługi. W takim przypadku ograniczenie ruchu na granicznej routingu, choć spowoduje, że niektóre sesje TCP nie zostaną ustanowione w tym czasie, uratuje Twoją infrastrukturę przed większymi problemami.

Przykład 2
Nienormalnie duża liczba pakietów SYN może być nie tylko wynikiem ataku SYN flood. Załóżmy, że świadczysz usługę, w ramach której jednocześnie może być około 100 tysięcy połączeń TCP (w jednym centrum danych).
Załóżmy, że w wyniku krótkotrwałego problemu z jednym z Twoich głównych dostawców została „wywalona” połowa sesji. Jeśli Twoja aplikacja jest zaprojektowana w taki sposób, że „bez namysłu” od razu (lub po jakimś jednakowym dla wszystkich sesji okresie czasu) stara się ponownie ustanowić połączenie, wówczas mniej więcej jednocześnie otrzymasz co najmniej 50 tysięcy pakietów SYN.
Jeśli na tych sesjach powinien funkcjonować ssl/tls handshake, co zakłada wymianę certyfikatów, z punktu widzenia wyczerpania zasobów Twojego balancera obciążenia będzie to znacznie silniejszy „DDoS” niż prosty SYN flood. Wydawałoby się, że balancery powinny radzić sobie z takimi zdarzeniami, ale… niestety, natknęliśmy się na ten problem w pełni.
I oczywiście policer na granicznym routerze uratuje Twój sprzęt także w tym przypadku.

Trzecim poziomem ochrony przed DDoS/DOS są ustawienia Twojego zapory sieciowej.

Tutaj możesz zablokować zarówno ataki drugiego, jak i trzeciego rodzaju. Ogólnie rzecz biorąc, wszystko, co dotrze do zapory, można będzie tutaj przefiltrować.

Rada
Postaraj się dać zaporze jak najmniej pracy, filtrując jak najwięcej na pierwszych dwóch liniach obrony. I oto dlaczego.
Czy zdarzyło się Wam, że przypadkowo, generując ruch, aby na przykład sprawdzić, jak odporna jest system operacyjny Waszych serwerów na ataki DDOS, „zabijaliście” swój firewall, obciążając go w 100 procentach przy tym ruchem o zwykłej intensywności? Jeśli nie, to może dlatego, że po prostu tego nie próbowaliście?
Ogólnie rzecz biorąc, firewall, jak już wspomniałem, jest skomplikowanym narzędziem i dobrze działa z znanymi lukami i przetestowanymi rozwiązaniami, ale jeśli wyślesz coś nietypowego, po prostu jakiś śmieć lub pakiety z niepoprawnymi nagłówkami, to z pewną, dość znaczną (na podstawie mojego doświadczenia) prawdopodobnością możesz zdezorientować nawet najnowsze urządzenia. Dlatego na etapie 2 za pomocą zwykłych ACL (na poziomie L3/L4) wpuszczaj do swojej sieci tylko ten ruch, który powinien tam wchodzić.