EXATELLERS to rozmowy o technologii, biznesie i trendach w obszarze telekomunikacji i cyberbezpieczeństwa. W tym podcaście rozmawiamy o tym jak w EXATEL łączymy telekomunikację z innowacjami i dlaczego prowadzimy działania R&D tworząc własne rozwiązania. Ja nazywam się Sylwia Buźniak, jestem Senior HR Business Partnerem i do tego programu będę zapraszać ekspertów EXATEL, aby poznać kulisy ich pracy i zrozumieć, które technologie są kluczowe dla rozwoju biznesu. Zapraszam.

Sylwia: Dzień dobry w dzisiejszym odcinku podcastu moim i Państwa gościem jest Maciej Kobus, ekspert ds. bezpieczeństwa defensywnego w EXATEL. Maciej pracuje od kilkudziesięciu lat w EXATEL. Na początek Maćku opowiedz nam trochę o swoim doświadczeniu w dziedzinie cyberbezpieczeństwa i o tym, co skłoniło cię do pracy m.in. nad usługą anty-DDoS.

Maciej: Witaj Sylwio. Dziękuję za to przedstawienie i za te kilkadziesiąt lat doświadczenia w EXATEL. Może cyberbezpieczeństwo nie ma kilkudziesięciu lat, ale ja swoją karierę w firmie zawsze wiązałem z siecią, bo to nasz taki rdzeń biznesu EXATEL, a wcześniej Telbank. Zawsze byłem związany z siecią – czy siecią rozległą, czy też siecią LAN. Swoje doświadczenie zbierałem przez lata, począwszy od administracji siecią, przez zarządzanie systemami bezpieczeństwa, które wtedy jeszcze nie były elementem składowym Departamentu Cyberbezpieczeństwa. Od kilku lat swoje umiejętności, rozwijam właśnie w ramach Departamentu Cyberbezpieczeństwa EXATEL, obsługuję system przeciwdziałania atakom DDoS, administruję systemami WAF-owymi. I w zasadzie to jest core mojej obecnej odpowiedzialności.

Sylwia: Usługa anty-DDoS EXATEL to TAMA, nasz autorski system. Czy mógłbyś powiedzieć jakie są główne zadania osoby odpowiedzialnej za obsługę ataków DDoS? Jakie umiejętności i narzędzia są niezbędne do pracy na Twoim stanowisku?

Maciej: Umiejętności to przede wszystkim znajomość narzędzi, które się posiada do obsługi tych ataków. Tutaj mówimy o platformie TAMA, która jest naszym autorskim rozwiązaniem. Swoje doświadczenie zdobywałem też na platformach komercyjnych. Więc jak najbardziej narzędzie, którym odpieramy ataki, musi być znane administratorowi czy też osobie, która obsługuje incydent. Musi być znane zarówno w konfiguracji, jak i w reakcji. Trzeba wiedzieć czym skutkują poszczególne mechanizmy, które wdrażamy na usługach klientów. Ewentualnie we własnym zakresie trzeba je testować. Poza tym, że są to jakieś przełączniki i suwaczki, to warto też – znając aplikację, która Cię chroni – odtworzyć atak we własnym zakresie i przetestować jak to faktycznie – zarówno od strony użytkownika końcowego, jak i właściciela aplikacji – wygląda. Czyli z jednej strony jakie jest oddziaływanie na użytkownika, a z drugiej jakie jest oddziaływanie platformy na cały system który chronimy. Oczywiście bardzo ważną kwestią jest znajomość technologii sieciowych. Cieszę się, że miałem możliwość pracy przy różnych systemach i przy sieci, co pozwoliło mi dość dobrze zorientować się w jakim to środowisku pracuję i jakie są standardowe zachowania użytkowników i sieci, tak żeby łatwiej mi było rozpoznać te sytuacje, które związane są z potencjalnym atakiem czy jakimś wrogim działaniem na rzecz klienta.

Sylwia: Ponieważ ataki DDoS mogą być bardzo rozległe i wpływać na różne części infrastruktury sieciowej, powinniśmy mieć możliwość wzięcia pod uwagę kluczowych aspektów przy zarządzaniu atakiem. O jakich kluczowych aspektach możemy mówić?

Maciej: Będę mówił z perspektywy osoby, która chciałaby skutecznie ten atak odeprzeć, czyli przede wszystkim w możliwie jak najkrótszym czasie zorientować się zarówno jaki to jest rodzaj ataku, jakie potencjalne usługi klienta mogą zostać tym dotknięte i czy tak naprawdę działania, które już podjęliśmy, są skuteczne. A jeśli nie są skuteczne, to czy jesteśmy w posiadaniu informacji, które pozwolą nam ewentualnie dopracować lub poprawić polityki filtrujące do tego stopnia, żeby uzyskać efekt skutecznego odparcia ataku. Jak najbardziej, zbieranie informacji już w momencie wystąpienia incydentu jest bardzo kluczowe. Część informacji zbieramy na etapie konfiguracji usługi, ale to nigdy nie jest taka wiedza, która pozwoli nam w każdej sytuacji odeprzeć atak standardowymi mechanizmami. Część informacji po prostu jest niezbędna do zebrania na etapie obsługi incydentu.

Sylwia: W związku z tym że zbieracie te informacje – Ty jako osoba od strony administratora, od strony operacyjnej, działająca z systemem anty-DDoS – zastanawia mnie na ile wnioski z ataków mają wpływ na rozwój systemu? Na ile Twoja praca ma wpływ na to w jakich kierunkach TAMA dalej będzie rozwijana?

Maciej: Widzę tutaj takie dwa obszary. Pierwszy to informacje, które wynikają stricte z tego w jaki sposób atakujący przeprowadził dany atak. To są takie nasze informacje, które możemy wykorzystać przy kolejnych incydentach. Jeśli atakujący wykorzystał jakąś farmę serwerów i jest duże ryzyko, że wykorzysta je potencjalnie po raz kolejny, to możemy z tego zbudować pewną bazę do przefiltrowania takiego ruchu przy kolejnym incydencie. To jest najprostszy przykład, ale dosyć szeroki zakres tzw. odcisku palca, czyli tego w jaki sposób się zachował atakujący, bądź jakiej infrastruktury użył. Wszystko po to, by przygotować się na kolejny ewentualny incydent i bogatsi o tę wiedzę, mieć przygotowane zestawy filtrów czy mechanizmów, które stosujemy w systemie TAMA. Druga kwestia to optymalizacja naszego działania. Zebraliśmy jakieś informacje, które chcielibyśmy użyć przy kolejnych incydentach, ale nie da się w prosty sposób ich zaimplementować, bo wymagają np. wdrożenia nowego mechanizmu ochrony przed atakiem, bądź rozwoju jakiegoś, który już jest.

Sylwia: Czyli rozwoju jakiegoś feature’a? Wtedy właśnie w grę wchodzi development.

Maciej: Tak, dokładnie. I w tym momencie mamy krótką ścieżkę do naszego zespołu deweloperskiego z którym omawiamy nasze wymagania co do feature’ów, które byśmy widzieli w kolejnych wersjach systemu TAMA. I jesteśmy w stanie w krótkim czasie wdrożyć działające mechanizmy, które z powodzeniem stosujemy przy odpieraniu kolejnych ataków.

Sylwia: Czy istnieją różnice między reakcją na atak DDoS w czasie rzeczywistym, a analizą i uczeniem się na podstawie przeszłych ataków? Jak to wygląda z Twojej perspektywy?

Maciej: To troszeczkę nawiązanie do poprzedniego pytania. Jak najbardziej, część działań jest tylko tu i teraz, tzn. przygotowujemy się na odparcie konkretnego ataku, który np. nie był nam wcześniej znany. Jednocześnie w trakcie obsługi takiego incydentu gromadzimy pewne dane, tak jak np. źródłowe adresy IP, które mogą nam posłużyć przy kolejnych atakach jako mechanizm filtrujący. Aczkolwiek czas życia tych danych – takich jak właśnie adresy IP – jest dosyć krótki, bo dochodzi tutaj do kompromitacji tych źródeł. I czy to my, czy operator wcześniej, czy właściciel infrastruktury zadziała w ten sposób, że po prostu te adresy będą kolejny raz nieużyteczne. Aczkolwiek są oczywiście pewne trendy czy nowe sposoby przeprowadzania ataków. Możemy dać jako przykład bardzo popularne ataki odbite, czyli tak zwane UDP reflection attacks. Atakujący podszywając się pod adres docelowy, odpytuje usługi w intrenecie, które albo zostały nieodpowiednio zabezpieczone, albo jest to nieświadomość administratora, który zostawił pewne usługi otwarte w sieci internet. Te usługi z całego świata zaczynają odpowiadać do adresu IP ofiary, wysycając tym samym łącze. To są ataki, które są proste w odpieraniu, aczkolwiek one cały czas żyją. Co jakiś czas pojawia się nowe źródło, nowy amplifikator, nowa usługa od której można się w internecie „odbić”. Są to dla nas użyteczne informacje w tym sensie, że rozwijamy listę naszych znanych amplifikatorów i to już ma jakieś powiedzmy zastosowanie w dłuższej perspektywie czasu. Więc jak najbardziej taka analiza retro z tego co się wydarzyło w konkretnym incydencie, czy pojawiło się coś czego wcześniej nie obserwowaliśmy i czy jest szansa, że w ogóle będzie miało to jakiekolwiek zastosowanie w przyszłości. W przypadku nowych źródeł ataków odbitych, są u nas uzupełniane w systemie jako element konfiguracji. I tutaj oczywiście bez udziału zespołu deweloperskiego, bo mamy to tak elastycznie przygotowane, że sami to dopisujemy w trakcie codziennej pracy.

Sylwia: A czy możesz podzielić się przykładem szczególnie trudnego ataku DDoS, który udało się z powodzeniem zażegnać? Jakie były kluczowe czynniki sukcesu?

Maciej: Czy szczególnie trudnego to może nie do końca, ale mam dość ciekawy przypadek z ostatnich miesięcy. Atak realizowany w protokole DNS, czyli znane serwery nazw, tj. tak naprawdę element pośredniczący w komunikacji użytkownika z docelowym serwerem, informujący gdzie, na jakim adresie IP znajduje się konkretna usługa, której szukamy. Atakujący ukrywał się w ten sposób, że odpytywał otwarte w sieci internet serwery DNS, które właśnie miały zwrócić mu potencjalnie informacje o tym gdzie, pod jakim adresem IP znajduje się konkretny serwer. Atakujący w zapytaniu wykorzystał poprawną domenę klienta i dzięki temu, że pośredniczył przez wiele otwartych serwerów, to w zasadzie jego źródłowy adres IP był dla nas oczywiście nieznany, bo my otrzymywaliśmy zapytania tych serwerów pośredniczących, czyli tak naprawdę w imieniu atakującego serwery odpytywały naszego klienta o hosty w istniejącej domenie. Skutkowało to tym, że w zasadzie nie można było przefiltrować tych zapytań bazując na ich ilości per źródłowe IP, ani filtrując domenę o którą pyta. Próbowaliśmy również zastosować tutaj metodę wyłapania tych hostów w domenie o które dopytuje atakujący. Okazało się, że jest to słownik, który sięgał blisko miliona pozycji, więc zastosowanie tutaj filtracji blokującej konkretne zapytania, nie wchodziło w grę. Atakujący ze względu na to, że te serwery pośredniczące, jak już im się uda uzyskać taką odpowiedź, sobie je cache’ują. Żeby nie doszło do cache’owania takiej odpowiedzi, atakujący pytał tylko o hosty, które nie istnieją w tej domenie. To zabezpieczało atakującego przed tym, żeby te serwery pośredniczące nie cache’owały tej odpowiedzi. W zasadzie rozwiązaniem było uzyskanie tak naprawdę informacji od klienta, jakie posiada rekordy w swoich domenach i przesunięcie tego na naszą platformę filtrującą. Dzięki temu, że dopuszczaliśmy tylko te zapytania, na które finalnie klient mógłby uzyskać odpowiedź, uzyskaliśmy efekt odwrócony, to znaczy nie widzieliśmy tego co jest złe – widzieliśmy tylko co jest dobre i na tej podstawie przepuszczaliśmy po prostu te konkretne zapytania. Atakujący oczywiście nie pytał o te poprawne hosty, bo to by skutkowało tym, że one na tych pośredniczących serwerach cache’owały i efekt zalania pakietami serwera DNS klienta byłby nieskuteczny.

Sylwia: A w jaki sposób współpracujesz z innymi zespołami w organizacji – np. administratorami sieci czy zespołami odpowiedzialnymi za bezpieczeństwo informacji – aby zapewnić kompleksową ochronę przed atakami DDoS?

Maciek: To jest ciekawe pytanie, bo pozwala troszeczkę powiedzieć o tym, że to nie jest tylko Departament Cyberbezpieczeństwa jeśli chodzi o ataki DDoS, bo to jest silna integracja z siecią IP.  I tutaj faktycznie dochodzą administratorzy, którzy zarówno na poziomie uruchamiania poszczególnych usług, czy powiedzmy zmian w architekturze platformy TAMA zawsze uczestniczą i ta świadomość po ich stronie też jak najbardziej jest. Oni są troszeczkę odbiorcami tej usługi, bo my świadcząc ją, jesteśmy też w stanie reagować na pewne rzeczy, które oni obserwują – czy to są np. jakieś przeciążenia z sieci. Jesteśmy w stanie po prostu pewne informacje w ramach analizy, którą prowadzimy na bieżąco, przekazywać i wspierać przy jakichś konkretnych sytuacjach (nie incydentach), które wymagają wyjaśnienia. Incydenty raczej są już u nas na poziomie Departamentu Cyberbezpieczeństwa. Oczywiście Zespół Architektury Sieci ma trochę szersze spojrzenie na to jak tą sieć rozwijać, ze względu na to że występują ataki, które mogą wpływać na obciążenie naszych zewnętrznych połączeń. Więc tutaj analiza, którą Zespół Architektury Sieci prowadzi, jak tą sieć rozwijać, jak podłączać ewentualne kolejne elementy tej całej układanki. Nazywam to układanką, bo chodzi o elementy składowe platformy TAMA. I oczywiście zespół deweloperski, który jest dla nas bardzo dużym wsparciem, bo w zasadzie każdy nasz pomysł na uruchomienie jakiegoś nowego mechanizmu, to tak naprawdę jest podniesienie komfortu naszej pracy. Często jest tak, że my wymyślamy coś, z czym by nam się łatwiej pracowało i dzięki temu właśnie, że mamy własny zespół developerski, to jesteśmy w stanie takie rzeczy w pewnym skończonym czasie wprowadzać na produkcję. Mając rozwiązanie pudełkowe czy konkretnego dużego gracza na rynku platform DDoS-owych, na pewno nie byłoby łatwo, żeby uzyskiwać takie ulepszenia, czy to UX-owe czy też funkcjonalne. My mamy tę możliwość, że mamy cały zespół developerski u nas na pokładzie i bardzo sobie chwalimy tę współpracę.

Sylwia: Jesteś inżynierem trzeciej, ostatniej linii SOC. Od kogo dostajesz informacje o ataku DDoS? Czy L1 i L2 biorą w tej ścieżce informacyjnej swój udział?

Maciej: Tak, oczywiście. Zespół monitorujący to jest ta pierwsza linia (L1). Nie zawsze jest tak, że każda informacja musi płynąć z systemu. Takim źródłem potencjalnej informacji może być też klient. Mówimy tutaj o standardowej usłudze TAMA, która opiera się na przepływach sieciowych, więc jakieś ataki, które występują na poziomie, którego my nie jesteśmy w stanie zauważyć ze względu na swój charakter. Tu takim źródłem informacji może być właśnie klient. Na podstawie tego co klient zaobserwował, jesteśmy w stanie zarejestrować incydent i przeprowadzić jakąś dogłębną analizę z której finalnie może się okazać, że gdzieś jakąś śrubkę trzeba dokręcić i jak najbardziej to realizujemy. Są sytuacje szczególnej potrzeby, kiedy ta ścieżka potrafi się skrócić do komunikacji z klientem. Mówimy tutaj naprawdę o sytuacjach gdzie mamy klientów z różnego sektora, więc zdarzały się takie sytuacje, gdzie ta ścieżka była skrócona do kontaktu z klientem.

Sylwia: Ale na co dzień generalnie system TAMA i monitoring w czasie rzeczywistym prowadzi L1, tak?

Maciej: Tak, jak najbardziej. Jest to dla nas też codzienna praca. Czyli oczywiście do porannej kawy uruchamiamy system po to, żeby się zorientować co tam nowego się „urodziło”, czy wszystko działa, kogo zaatakowali, jaka jest skuteczność mitygacji, czy nie trzeba troszeczkę tych suwaczków poprzesuwać w lewo albo w prawo, żeby ta skuteczność mitygacji lub detekcji była lepsza.

Sylwia: Co firmy mogą zrobić aby przygotować się na ewentualny atak DDoS? Jakie są najlepsze praktyki w zakresie przygotowań do takiego scenariusza?

Maciej: Przede wszystkim trzeba zadbać o to, żeby tę ochronę mieć. To nie jest wcale takie oczywiste, że ktoś kto kupuje usługi dostępu do internetu, kupuje to w pakiecie z usługą ochrony przed DDoS. Posiadanie tej usługi to jest jedno. Dalej świadomość jak ona działa i dobór właściwego wariantu. Bo to też nie jest tak, że w każdym wariancie ta usługa w ten sam sposób funkcjonuje. To jest raczej dopasowane do biznesu (jaki prowadzi konkretny klient) i skali. Więc tutaj wpasowanie się w ten wariant też jest bardzo istotne. Również wybór tego operatora, żeby to był nasz taki partner w tej sytuacji, która może nas dotknąć. Nie będę kolejny raz zachwalał jak bardzo jesteśmy elastyczni, ale tak to u nas wygląda. Klient może się do nas zgłosić w trakcie incydentu, który wydaje się że wymaga jakiegoś bardzo konkretnego, precyzyjnego działania, które jest niestandardowe i  jesteśmy w stanie obsłużyć zgłoszenie na linii trzeciej (L3) czy nawet wdrożyć zaangażowanie dewelopmentu żeby jakieś rozwiązanie wdrożyć. Oczywiście to nie są kwestie godzin jeśli mówimy o dewelopmencie, ale w jakimś tam powiedzmy skończonym czasie. Klienci są też czasami źródłem takich informacji, które później przekładają się na zadania w dewelopmencie.

Sylwia: Czyli generalnie słuchamy też potrzeb klientów.

Maciej: Tak. Bardziej skupiłem się tutaj tylko na kwestii związanej z łączem internetowym, ale też ważne jest po stronie klienta żeby przeprowadzić audyt swoich urządzeń, które stoją na brzegu sieci. Bo też często się z tym spotykamy, że klienci mają pewne mechanizmy – na Firewallu czy na Load Balancerze, na urządzeniach, które stoją jako pierwsze po stronie klienta – wspierające ochronę przed DoS czy DDoS i tak naprawdę z nich nie korzystają. Nie mówię, że to jest niezbędne do tego żebyśmy my mogli działać, bo oczywiście my działamy na poziomie sieci. Działamy troszeczkę o ten krok wcześniej, ale klient przygotowując odpowiednio swoje urządzenia, jest w stanie albo ograniczyć działanie tego ataku do konkretnej usługi, która została zaatakowana – tworząc tam logiczne limity dla poszczególnych usług, które świadczy w sieci Internet – bądź zastosować konkretne mechanizmy, które realizują coś podobnego jak my. Oczywiście robi to na dużo mniejszym poziomie, bo dosłownie do kilku tysięcy pakietów jest w stanie, ale to jest też czas, który jest bardzo ważny. My działamy w reakcji na poziomie sieci więc trzeba liczyć się z jakimiś sekundami czy minutami kiedy my podejmiemy tę reakcję, a klient już mógłby tutaj kawałek tej pracy po swojej stronie zrobić, która by skutkowała tym, że mielibyśmy taką kompletność tego całego działania.

Sylwia: A czy istnieją konkretne narzędzia lub strategie, które szczególnie polecałbyś firmom, aby poprawić ich ogólną ochronę sieciową?

Maciej: Tak, myślę że np. decentralizacja albo w ogóle wynoszenie usług na odrębne łącza. Często atakujący, którzy chcą osiągnąć jakiś efekt wizerunkowy, nie przykładają się do tego ataku w części rekonesansu, żeby wyszukać jakieś elementy w które jeśli się uderzy, to one faktycznie spowodują załamanie biznesu. Raczej czepiają się takich rzeczy, które będą wizerunkowe, czyli np. pierwsza witryna klienta czy właśnie serwer DNS. Jeśli się uda ten kawałek infrastruktury położyć, to jest to powiedzmy zauważalne i cel został osiągnięty. Wiadomo, że dla wielu instytucji biznes w internecie to nie tylko kwestia wizerunkowa – czyli czy jakaś witryna nam się wyświetli czy nie. Jest jakieś partnerstwo, są jakieś interfejsy API, są jakieś połączenia w sieci internet, które można w pewnym stopniu odseparować od tej infrastruktury na której się świadczy daną usługę informacyjną. To nie jest super krytyczne z perspektywy biznesu, ale może być krytyczne z perspektywy wizerunkowej. Ale to też wszystko zależy od biznesu i trzeba by tak naprawdę wyważyć, co dla konkretnego klienta jest bardziej istotne i czy w ogóle ma taką możliwość żeby dokonać jakiejś separacji. To też może być sposób na to, żeby zachować ciągłość działania nawet w sytuacji, gdy powiedzmy ta nasza witryna nie wyświetla się w sekundę.

Sylwia: Tutaj sprawdzi się pewnie powiedzenie, że lepiej zapobiegać niż leczyć. Ciężko zapobiegać czemuś, co się jeszcze nie wydarzyło. Dopiero ta sytuacja kiedy ten wizerunek zostanie jakoś nadszarpnięty albo go utracimy, to wtedy zaczynamy sobie zdawać sprawę. Więc lepiej do tego nie dopuścić niż potem to prostować.

Maciej: Kwestia czasu też jest bardzo istotna, bo mieliśmy przypadki takie, że wdrażaliśmy usługę klientowi, który był w trakcie ataku. I nawet udało nam się skutecznie odeprzeć ten atak, nie mając tych informacji które zazwyczaj zbieramy na etapie uruchomienia usługi. Bardziej chodziło więc o to, żeby funkcjonalnie dowieźć elementy konfiguracji związane z tym żeby w ogóle ten atak obsłużyć. Ale ten atak był już nam znany, więc mechanizmy filtrujące już mieliśmy. Sam proces uruchomienia, jeśli odbywa się w warunkach komfortowych, gdzie mamy tydzień czy miesiąc na uruchomienie usługi, versus godziny które dzielą nas od informacji, że klient potrzebuje pomocy i finalnie uruchomienie oraz obsługa ataku. Im wcześniej, tym lepiej.

Sylwia: To tylko pokazuje jakimi ekspertami jesteście i jak elastycznie działacie. I tym optymistycznym akcentem dziękuję za rozmowę i mam nadzieję, że do usłyszenia w jakimś kolejnym odcinku.

Maciej: Dziękuję bardzo.