TAMA, autorski anty-DDoS

Ataki DDoS (czyli odmowa dostępu do usług) są już nierozłączną częścią Internetu, bez względu czy jako użytkownicy sobie z tego zdajemy sprawę, czy nie. Zasada działania tego typu ataku polega na wysyceniu określonych zasobów po stronie serwera świadczącego usługę. Jeśli nie działa jakaś usługa, lub strona w sieci, to może znaczyć, że stała się ona celem właśnie takiego ataku. Jak łatwo się domyśleć, radzenie sobie z tego typu zagrożeniem stało się chlebem powszednim wszystkich usługodawców w Internecie.

Batalia o dostępność usług jest prowadzona wszelkimi metodami. Od manualnego i ordynarnego blokowania celu ataku (i ratowania postronnych ofiar), po zautomatyzowane, wysublimowane i wielostopniowe procesy filtrowania. Oczywiście czym wygodniejsze (mniej angażujące i ingerujące) rozwiązanie tym bardziej kosztowne, a specyfiką ataków DDoS jest przepaść między kosztem jego organizacji, a środkami jakie trzeba zaangażować, aby się ochronić. Charakterystyka rozproszonej (“distibuted”) sieci źródeł ataku dodatkowo powoduje, że w zasadzie tylko operatorzy telekomunikacyjni (dostawcy Internetu) są w stanie skutecznie organizować obronę. EXATEL w tych działaniach nie jest odosobniony i poszedł nawet o krok dalej.

 

Podejście EXATEL

Techniki ataków cały czas ewoluują, a w związku z tym konieczne jest aktualizowanie zabezpieczeń. EXATEL zdecydował się zbudować autorskie rozwiązanie TAMA jako odpowiedź na potrzebę bezpośredniego wpływu na rozwój systemu ochrony DDoS w zależności od realnych (a zarazem zróżnicowanych) wymagań klientów podlegających atakom.

Dzięki temu, że mamy możliwość ciągłej analizy charakterystyki ruchu w sieci, jeśli wykryjemy nietypowe zdarzenie (i zakwalifikujemy je jako szkodliwe) – możemy natychmiastowo reagować i sprawnie filtrować złośliwy ruch z sieci. Dzięki temu umożliwiamy normalne działanie atakowanego serwisu.

Czym jest TAMA?

TAMA to skalowalne i wydajne rozwiązanie programistyczne chroniące sieć przed atakami typu DDoS (ang. Distributed Denial of Service). EXATEL zbudował rozwiązanie w modelu usługowym (ang. as a service). Ochrona przed wolumetrycznymi atakami DDoS jest oparta na platformie centralnej.

TAMA składa się z kilku elementów:

  • Aperture monitoruje ruch sieciowy z routerów brzegowych agreguje informacje statystyczne i przekazuje do Kontrolera.
  • Kontroler integruje informacje z sond w postaci “aktualnego stanu o monitorowanej sieci”, zapisuje je do bazy analitycznej, podejmuje decyzje o wykryciu, podtrzymaniu i zamknięciu alarmu, uruchamia i zatrzymuje automatyczne mitygacje.
  • GlaDDoS to jednostka filtrująca. Jest skalowalny. Przepustowość na jednym GlaDDoSie zależy od ustawień polityki mitygacji oraz od parametrów serwera, na którym został uruchomiony. Dla osiągnięcia jak najlepszej wydajności, nasze jednostki filtrujące są rozproszone geograficznie.
  • Chell to konsola zarządzająca, pozwala administratorom i operatorom dbać o bezpieczeństwo sieci naszych klientów.
  • Portal klienta to dodatkowy element, za pośrednictwem którego nasi klienci mogą obserwować alarmy i mitygacje wyzwolone dla swoich obiektów oraz monitorować ruch w swojej sieci.

Na czym polega innowacyjność produktu?

  • Architektura rozwiązania oparta o ogólnodostępny sprzęt w architekturze x86 – bez drogich układów FPGA i ASIC
  • Osiągnięcie przepustowości rzędu 100 Gb/s – dzięki wykorzystaniu efektywnych technik skalowania (pionowego i poziomego)
  • Autorskie mechanizmy i techniki zawierające elementy uczenia maszynowego
  • Możliwość pracy w trybie multi-tenancy (równoczesna ochrona wielu klientów z różnymi politykami) oraz ochrony łącz niezależnie od działania dostawcy
  • Opracowanie szybkiego i elastycznego silnika decyzyjnego do identyfikacji i neutralizacji zagrożeń

Obejrzyj film i sprawdź jak działa TAMA

Zapisz się na symulację ataku DDoS

To dzięki temu rozwiązaniu zapewnisz swojej organizacji:

Gwarancję
i jakość działania

Dowiedz się więcej
  • System stworzony przez polskiego operatora telekomunikacyjnego, Spółkę Skarbu Państwa
  • Ochrona klasy operatorskiej – chronimy nawet przed atakami większymi niż pasmo klienta
  • Architektura HA zapewniająca ciągłość działania
  • Zakres ochrony dopasowany do przepustowości sieci Klienta

Elastyczność
i skalowalność

Dowiedz się więcej
  • Dostosowanie konfiguracji do indywidualnych wymagań klienta
  • Możliwość ochrony na dowolnym łączu, niezależnie od dostawcy
  • Możliwość równoległej ochrony z rozwiązaniami klienckimi
  • Integracja z systemami bezpieczeństwa klienta (np. SIEM)
  • Możliwość filtrowania ruchu sięgającego warstwy 7, z wykorzystaniem wyrażeń regularnych na payload pakietu, zdefiniowanych lub tworzonych zgodnie z potrzebami klienta

Pełna kontrola

Dowiedz się więcej
  • Opcja automatycznego i ręcznego reagowania na ataki
  • Tworzenie wykluczeń w procesie detekcji
  • Możliwość zarządzania sesjami podczas mitygacji. Możliwa konfiguracja dopuszczalnej liczby otwartych sesji per źródło, minimalna liczba pakietów oraz minimalny rozmiar pakietów
  • Możliwość definiowania różnych czasów wyzwolenia alarmów dla poszczególnych metod detekcji
  • Portal Klienta – dostęp do aktualnych statystyk usługi, możliwość generowania raportów

Oszczędności

Dowiedz się więcej
  • Najlepszy stosunek jakości do ceny na rynku
  • Obsługa w trybie 24/7 przez EXATEL (bez konieczności poświęcania zasobów po stronie klienta)
  • Możliwość bezpłatnego przetestowania usługi

Sprawdź możliwe warianty anty-DDoS TAMA

Warianty/pakiety usługi TAMA

BASIC

STANDARD

ADVANCED

PREMIUM

Ochrona na łączach EXATEL

+

+

+

+

Podstawowa metoda ochrony przed atakami

Blackholing

Filtrowanie

Filtrowanie

Filtrowanie

Raporty

Miesięczne

Każdorazowo

Każdorazowo

Każdorazowo

Definiowanie wielkości ruchu mierzonej w pps i bps dla poszczególnych adresów IP, przekroczenie której spowoduje automatyczne uruchomienie mitygacji

+

+

+

+

Każdorazowa informacja o wykryciu ataku

+

+

+

Definiowanie obiektów, list wykorzystywanych portów, protokołów

+

+

+

Definiowanie własnych białych i czarnych list portów i protokołów

+

+

+

Możliwość określenia, które z obiektów wykorzystują komunikację UDP

+

+

+

Możliwość określenia, czy podczas ataku adresy źródłowe powinny zostać ograniczone do terytorium RP

+

+

+

Dostęp do portalu ze statystykami

+

+

+

Obsługa do pięciu zmian konfiguracji w miesiącu

+

+

+

Wsparcie analityków SOC EXATEL

+

+

Definiowanie wielkości ruchu (pps i bps) dla poszczególnych obiektów, przekroczenie której spowoduje detekcję alarmu na poziomie wysokim

+

+

Tworzenie rozwiązań antyDDoS dostosowanych do nietypowych wymagań klienta (np. ochrona łącza innego niż EXATEL operatora)

+

Czym jest ARFA?

ARFA jest Kontynuacją projektu TAMA tj. zestaw dodatkowych modułów, w które zostanie wyposażone rozwiązanie TAMA anty-DDoS.

Dzięki ARFA możliwe będzie przeciwdziałanie:

  • nowym atakom wolumetrycznych (dzięki dodaniu nowych technik w obszarze detekcji i mitygacji ataków DDoS)
  • atakom na zasoby serwera usługi (w tym atakom na fragmentację)
  • atakom na warstwę aplikacyjną
  • atakom BGP hijacking

logo NCBR Logo Politechnika Śląska

Projekt współfinansowany przez Narodowe Centrum Badań i Rozwoju w ramach programu CyberSecIdent „Cyberbezpieczeństwo i e-Tożsamość”. Wartość dofinansowania projektu wynosi 8,1 mln PLN.

Fuzzing w projekcie TAMA

Autorem tekstu jest Michał Krzywkowski Programista w zespole TAMA w EXATEL   Fuzzing w projekcie TAMA  W projekcie TAMA, oprócz używania narzędzi do statycznej analizy kodu oraz testowania z użyciem sanitizers, jednym ze sposobów w jaki zwiększamy bezpieczeństwo...

Pierwotna informatyka w systemie TAMA

Autorem artykułu jest Tomasz Fortuna Programista TAMA w EXATEL   Ars numerandi Optymalizowanie kodu i wyciąganie z dostępnego sprzętu możliwie jak najwięcej towarzyszyło nam od pierwszych dni informatyki. Wtedy, wynikało w głównej mierze z konieczności –...

Praca w projekcie TAMA EXATEL

Marek Makowski EXATEL

Marek Makowski
Główny Inżynier ds. Zaawansowanych
Usług Bezpieczeństwa

Każdy dzień w EXATEL to dla mnie intensywny rozwój i wychodzenie z własnej strefy komfortu. Przykłady? Udział w projektach badawczo-rozwojowych i współpraca ze świetnymi naukowcami to możliwość pracy na detalach rozwiązań cyberbezpieczeństwa.  Ale moja codzienność to także biznes. Biorę udział w komercjalizacji tworzonych „od zera” i rozwijanych w Polsce technologii. Oznacza to, że mam realny wpływ na to, jak te rozwiązania będą wyglądały. To wyzwania dające dużo satysfakcji. Trudno o lepsze środowisko do samorozwoju.

Marcin Skwarek
Starszy Programista

W pracy na stanowisku programisty ważne są dla mnie 3 rzeczy – z kim pracuję, nad czym pracuję i po co to robię. Cenię sobie współpracę z ludźmi, którym się po prostu chce, widzieli już dużo systemów i z wieloma pracowali, ale stale się uczą i szukają nowych rozwiązań. Dlatego właśnie pracuję nad projektami badawczo-rozwojowymi w EXATEL. Ludzie, wyzwania, odpowiedzialność oraz możliwość wpływu na kształt projektu – to wszystko daje mi satysfakcję w codziennej pracy.

Praca w EXATEL

 

EXATEL oferuje znacznie więcej niż tylko stabilną pracę. Jako spółka technologiczna mamy kontakt z najnowocześniejszymi technologiami i metodykami pracy. Jesteśmy ambitną firmą, tworzymy nowe rozwiązania, nigdy nie brakuje nam wyzwań i ciekawych problemów. Nasz zespół to grupa pasjonatów o niebywałym poziomie kreatywności i chęci tworzenia nowych rozwiązań, zamiast odtwórczej pracy.

Q&A

Jaki jest stos technologiczny w projekcie TAMA?

Projekt jest zbudowany kilku komponentów:

  • aperture – sonda w C++17
  • gladdos – scrubber w C++17 i dpdk
  • chell – konfiguracja systemu, interfejs operatora i administratora; składa się z backendu w python/flask i frontendu w angular – używamy aktualnych wersji
  • kontroler – składa się z detektora i workerów kolejki, odpowiada też za zbieranie statystyk

Korzystamy ze dystrybucji Debian Stable i pakietów dostarczanych wraz z nim.

Używamy baz danych NoSQL: redis i elasticsearch. Wszystkie komponenty sa uruchomione w kontenerach dockerowych i zarzadzane przez docker-compose w środowiskach przedprodukcyjnych i docker-swarm na produkcji

Jak wygląda automatyzacja testów?

Do automatyzacji testów używamy Jenkinsa, który po otrzymaniu notyfikacji od bitbucketa odpala serie testów dla każdego z komponentów systemu.

Jedne z bardziej skomplikowanych testów to testy integracyjne mechanizmów filtra GlaDDoS. Uruchamiają automatycznie filtr na wirtualnych lokalnych interfejsach TAP, podłączają się do nich za pomocą pythona i używają Scapy do generowania pakietów i obserwacji reakcji GlaDDoS na wysłany ruch.

Jak wydajnie przechowywać listy IPv4 i IPv6?

Zarówno w filtrze GlaDDoS, jak i w sondzie Aperture mamy potrzebę wyciągania informacji typu “jaka konfiguracja aplikuje się dla danego adresu IP”. Często dodatkowo niezbędne jest wykorzystanie “Longest Prefix Match”: tj. konfiguracja dla 1.2.0.0/24 ma mniejszy priorytet niż 1.2.3.0/28 jeśli pytamy o 1.2.3.1, ale aplikuje się do zapytania o 1.2.4.4. Czasem chcemy znać wszystkie aplikujące się konfigurację  (czyli dla 1.2.3.1 zarówno 1.2.3.0/28 jak i 1.2.0.0/24).

Rozwiązania sprzętowe tego problemu to często dość droga pamięć typu TCAM – my jednak tworzymy rozwiązanie czysto software’owe. Często stosowany algorytm rozwiązujący ten problem to LCTrie – my używamy prostego algorytmu TriTrie, który w praktyce dla małych zbiorów danych działa szybciej od znalezionej implementacji referencyjnej LCTrie i daje się łatwo rozszerzać, dzięki czemu działa dla:

  • IPv4 oraz IPv6,
  • Zarówno longest-prefix-match jak i “all match”,
  • Zarówno małe dane konfiguracyjne (tysiące wpisów) jak i GeoIP (pokrywające całą przestrzeń IPv4).

TriTrie jest statycznie generowana i po wygenerowaniu nie jest modyfikowana. Tam gdzie potrzebujemy trzymać dynamiczną listę adresów, a kod musi być wydajny i nie używać locków (czyli np. nie można alokować pamięci) używamy bloomfiltrów – w których dodanie adresu IP sprowadza się do ustawienia niektórych bitów na wartość 1. Bloomfiltry mogą przy odczycie powodować błędy typu false positive, więc nie wszędzie da się je stosować. Nie można z nich za to usuwać dodanych adresów, więc co jakiś czas są “rotowane” i wymieniane na nowe, czyste.

Jak dokumentujecie wasz kod?

1. Skomentowany kod (doxygen)
a. Wyjaśnienie intencji działania metody, czy klasy lub fragmentu kodu, jesli to konieczne. Pozwala na łatwiejsze zrozumienie co autor miał na myśli i weryfikację, czy aby na pewno tak to działa. Przy wprowadzaniu zmian pozwala upewnić się, że nie psujemy zamierzonego zachowania.

2. Dokumentacja systemu w repozytorium (sphinx)
a. architektura
b. koncepcja działania
c. podział na komponenty
d. główne interfejsy
e. dokumentacja techniczna działania filtrów (jakie rodzaje ataków wykrywamy i w jaki sposób)
f. model sieci GlaDDoS – jak zachowuje się jako urządzenie sieciowe
g. dokumentacja administratora
h. dokumentacja ról i uprawnień w systemie

3. Changelog – opis zmian w stosunku do poprzedniej wersji:
a. Jaki jest biznesowy sens zmian?
b. Release notes: jakie zmiany trzeba wykonać ręcznie przy wdrożeniu (np. związane z migracją modelu danych).
c. Jakie są zmiany techniczne, istotne z punktu widzenia zespołu?

4. Dokumenty analityczne, operacyjne, systemowe (confluence)
a. Jakie są zmiany funkcjonalne lub wizualne, odczuwalne przez użytkowników?
b. Dokumentacja użytkownika

5. Tablica zadań w JIRA

Czemu nie korzystacie z najpopularniejszych obecnie rozwiązań chmurowych?

Jest kilka powodów. Pierwszy i najważniejszy jest taki, że jako operator infrastruktury krytycznej odpowiadamy za niezawodność usług dla najważniejszych instytucji w państwie. Jednocześnie jest to ogromna odpowiedzialność, ale dzięki temu mamy infrastrukturę, wiedzę i doświadczenie, jak taką niezawodność i wysoką dostępność zapewnić. Dlatego podstawowa zaleta chmury nie jest dla nas tak kluczowa, jak dla firm, które taką infrastrukturą nie dysponują.

Utrzymujemy na potrzeby własne i klienckie kilkaset systemów, z których znakomita większość jest zwirtualizowana, co pozwala nam na elastyczne skalowanie zasobów i obniżenie kosztów funkcjonowania – czyli druga ogromna zaleta chmury, po szczegółowym przeliczeniu, w praktyce okazuje się równie dobrze się sprawdzać w naszym modelu.

Ostatni, ale równie ważny aspekt, to kontrola nad danymi. Kiedy umieszczamy nasze dane w chmurze – czyli po prostu na cudzym komputerze – musimy zaufać, że właściciel infrastruktury chmurowej w odpowiedni sposób o nasze dane dba, zabezpiecza je przed utratą lub ujawnieniem, ani nie czerpie z nich innych korzyści. Kiedy nasze dane składujemy na naszych własnych zasobach, ten problem bierzemy na siebie. Jednocześnie jest to nasza usługa, którą oferujemy klientom chcącym nam zaufać.

W praktyce sami jesteśmy dostawcą usług chmurowych i stale poszerzamy zakres naszej wiedzy oraz ofertę produktową.

Skąd pojawiają się wymagania i pomysły na nowe funkcjonalności?

Bazujemy na wiedzy eksperckiej osób pracujących w naszym dziale cyberbezpieczeństwa, operatorów SOC, którzy zajmują się bezpośrednio obsługą ataków i bezpieczeństwem sieci naszych klientów.

Śledzimy na bieżąco najnowsze trendy i technologie wykorzystywane w branży cyberbezpieczeństwa.

Współpracujemy również z konsultantami z wyższych uczelni technicznych i studentami w ramach prac badawczych.

Czy macie dobrego SCRUMA ? Czy sprawdził się w waszym projekcie ?

Wykorzystanie metodyk zwinnych pozwala nam na ciągły rozwój produktu i implementację nowych funkcjonalności oraz zbieranie uwag i propozycji od użytkowników końcowych produktu. Dzięki codziennym spotkaniom tzw. daily możemy na bieżąco rozwiązywać problemy i każdy członek zespołu ma możliwość zapoznać się z postępem prac w projekcie. Po każdym wykonanym sprincie projekt posiada nowe funkcjonalności, które są wykorzystywane w pracy operatorów lub klientów. Zgodnie z metodami zwinnymi każdy zakończony sprint jest analizowany przez zespół pod kątem ewentualnych usprawnień w procesie prac nad produktem.

Metoda zwinna zarządzania projektem sprawdziła się bardzo dobrze w trakcie pracy nad systemem TAMA.

Jak komunikujecie się w zespole ? Mumble, Zoom, Rocket chat, signal. Czemu nie slack?

Nie slack, bo nie można sobie go zainstalować on premise i nie jest szyfrowany end-to-end. Używamy różnych narzędzi stosownie do potrzeb.
Signal – do szybkiej komunikacji “podręcznej”, powiadomień. Cloud – ale szyfrowany end-to-end i open source.
Mumble – Virtual presence, trochę jak radio. Zwykle cały zespół jest dostępny “na nasłuchu” w pokojach, w taki sposób, że można bez kłopotu porozmawiać lub “zawołać”, podobnie jak robilibyśmy w biurze.
Rocket chat – wszelka komunikacja pisemna, “na bieżąco”. Pokoje tematyczne i boty, które powiadamiają nas o istotnych zdarzeniach, jak np. zepsuty (lub naprawiony) build, wyniki testów wydajnościowych. Jest to podręczne i zebrane w jednym miejscu, dzięki czemu usprawnia pracę.
Zoom – to jak chcemy się pooglądać albo trzeba wyświetlić ekran. Mamy własny serwer on-premise, co trochę poprawia samopoczucie.

Jak testujecie waszą aplikację ? W jaki sposób dbacie o jakość kodu?

Do kontroli wersji używamy Git ze zdalnym serwerem BitBucket. Zadania organizujemy w JIRA, a dokumentację piszemy na Confluence oraz bezpośrednio w kodzie (sphinx).

Aplikacja jest testowana na wielu poziomach, każdy z komponentów ma swoje testy jednostkowe oraz testy funkcjonalne.

Do CI używamy Jenkinsa i w zalezności od platformy dodatkowe narzędzia:

  • linting (pylint, tslint, pycodestyle)
  • formatting (clang-format, cmake-format, prettier, robot-tidy)
  • analiza statyczna (SonarQube)
  • testy jednostkowe (GTest, pytest, jasmine)
  • testy integracyjne (selenium, RobotFramework, scapy)
  • fuzzing
  • testy wydajnościowe (pktgen)

Jeśli kod nie przejdzie testów, to nie może zostać zmergowany do mastera – nie bedzie mozna wydać takiej wersji. Stosujemy quality gate’y:

  • Pokrycie kodu testami musi przekraczać 85% linii
  • Liczba błędów lintera nie może wzrosnąć

Poprawne wyniki testów pozwalają na deploy wersji na środowisko testowe. Proces jest wyzwalany on-demand i odbywa się automatycznie, przy użyciu sparametryzowanego joba na Jenkinsie.

Na koniec procesu wydawania wersji nasi testerzy przeprowadzają testy ręczne aplikacji. Organizujemy scenariusze testowe w JIRA korzystając z wtyczki Zephyr.

Projekt współfinansowany przez Narodowe Centrum Badań i Rozwoju w ramach programu CyberSecIdent „Cyberbezpieczeństwo i e-Tożsamość”.