Droga pakietu
Ścieżka danych prowadzi przez sieć datacenter i MCFilter. Równolegle pracuje warstwa obserwacyjno-sterująca: FlowAnalyzer patrzy na telemetrię ruchu i decyduje, jakie reguły trafią do sieci oraz do filtrów.
Ruch przychodzi z sieci publicznej. Razem z ruchem prawidłowym trafia tu również ruch ataku.
Pierwsza warstwa ochrony. Tutaj kończy drogę ruch wolumetryczny, zanim obciąży dalszą część ścieżki.
Ruch odrzuconyNasz silnik filtracyjny. Obejmuje egzekwowanie reguł L3/L4 przez EdgeRule oraz filtrowanie L7 przez FilterAPP.
Do infrastruktury dociera już przefiltrowany ruch.
Usługa otrzymuje ruch zgodny z oczekiwanym protokołem. Minecraft jest tu tylko jednym z przykładów.
Control plane — detekcja i decyzje
Analizuje przepływy sieciowe i wykrywa anomalie L3/L4. Nie jest kolejnym urządzeniem na ścieżce pakietu — pracuje obok niej.
Dystrybuuje reguły mitygacji w warstwie routingu.
Cykl mitygacji
Każde zdarzenie przechodzi tę samą ścieżkę. Detekcja jest oddzielona od egzekwowania, dzięki czemu reguła trafia dokładnie tam, gdzie działa atak.
FlowAnalyzer zbiera telemetrię przepływów i buduje obraz normalnego ruchu.
Zmiana charakterystyki ruchu zostaje zaklasyfikowana jako anomalia albo znany wzorzec ataku.
Dobieramy mechanizm mitygacji do warstwy, w której faktycznie działa atak.
Reguła trafia do BGP FlowSpec, do EdgeRule albo do filtra protokołu w FilterAPP.
Ruch zgodny z protokołem jedzie dalej do chronionej usługi.
Architektura ochrony
MCFilter spina ochronę sieciową, filtrowanie świadome protokołu oraz rozwijaną warstwę analizy anomalii. To nie są trzy osobne produkty, tylko trzy poziomy tej samej ścieżki decyzyjnej.
Ochrona sieciowa i transportowa. Detekcja przepływów, reguły dystrybuowane do sieci oraz mechanizmy chroniące przed spoofingiem, refleksją i zalewem połączeń.
Filtry znają budowę konkretnych protokołów, więc potrafią odróżnić ruch usługi od ruchu, który tylko udaje jej format.
Rozwijamy warstwę analizy anomalii, której zadaniem jest wskazywanie wzorców ruchu odbiegających od ustalonej normy. To warstwa badawcza — pracuje obok mechanizmów L3/L4 i L7, a nie zamiast nich.
FilterAPP
FilterAPP rozpoznaje ruch konkretnych usług. Każdy filtr może pracować w trybie obserwacji, przepuszczać wyłącznie ruch zgodny z protokołem albo blokować dopasowany ruch. Filtr może też korzystać z rate limitera.
Tryby pracy filtra
Filtr klasyfikuje ruch, ale go nie odrzuca.
Przechodzi wyłącznie ruch zgodny z protokołem.
Dopasowany ruch zostaje odrzucony.
Zestaw filtrów rozwijamy razem z protokołami, które obsługujemy.
EdgeRule
EdgeRule opisuje ruch tak, jak wygląda on w sieci: skąd przychodzi, dokąd idzie i jak zbudowany jest pakiet. Do tego dobierasz akcję albo przekazujesz ruch do filtra protokołu.
Z czego składa się reguła
Source
Destination
Packet
Action
Dispatch
Reguły mają priorytet — niższa wartość oznacza wyższe pierwszeństwo.
Powyższa reguła jest wyłącznie ilustracją możliwości silnika, a użyty adres pochodzi z zakresu dokumentacyjnego RFC 5737. Nie publikujemy produkcyjnych konfiguracji, progów detekcji ani sygnatur ataków.
Analiza ruchu
Telemetria przepływów jest podstawą decyzji o mitygacji. Obok mechanizmów opartych na znanych wzorcach rozwijamy analizę anomalii, która ma wskazywać ruch odbiegający od ustalonej normy.
FlowAnalyzer buduje obraz normalnego ruchu i porównuje z nim bieżące przepływy. Odchylenie od tego obrazu uruchamia decyzję o mitygacji.
Przepływy w czasie
Wykryta anomalia
Rozkład protokołów
Ruch — telemetria — detekcja — decyzja o mitygacji
Warstwa rozwijana pod kątem zero-day. Jej zadaniem jest wskazywanie skupisk ruchu, które nie pasują do ustalonej normy ani do znanych sygnatur — nie zastępuje mechanizmów L3/L4 i L7.
Wykresy w tej sekcji są schematyczne i nie przedstawiają danych produkcyjnych.
Tryby ochrony
W modelu always-on ruch cały czas przechodzi przez warstwę ochronną. W modelu on-demand ruch jest kierowany do warstwy filtracji dopiero po wykryciu ataku, co zmienia ścieżkę ruchu oraz moment uruchomienia ochrony.
Ruch stale przechodzi przez warstwę filtracji.
Ścieżka ruchu zmienia się dopiero po detekcji ataku.
Wdrożenie
Technologia filtracji nie musi działać wyłącznie w naszej sieci. Dla wdrożeń biznesowych MCFilter może zostać uruchomiony bezpośrednio w infrastrukturze klienta.
Ruch trafia do naszej sieci, przechodzi przez scrubbing i MCFilter, a do usługi dociera już przefiltrowany. Utrzymanie warstwy filtracji jest po naszej stronie.
Stack filtracyjny uruchamiamy w infrastrukturze klienta, więc ruch nie musi opuszczać jego sieci. Zakres wdrożenia i integrację ustalamy indywidualnie.
FAQ
Nie znalazłeś interesującej Cię odpowiedzi?
Skontaktuj się