Ataki DDoS od kuchni

— Adam Haertle —

Chciałem zacząć od tego, by opowiedzieć wam coś o atakach DDoS. Pewnie większość z was to zna i nie muszę tłumaczyć aspektów technicznych, natomiast nie wiem czy wszyscy z was widzieli ten film, który idealnie obrazuje istotę ataków DDoS. Pokazuje on w jaki sposób tak naprawdę obrona przed atakami DDoS może być skomplikowana w zależności od tego jak duża jest skala tego ataku. Pewnie widzicie co piątą klatkę tego filmu, ale mam nadzieję że zobrazował wam on dobrze to, z czym tak naprawdę obrońcy przed atakami DDoS muszą się mierzyć. Gdybyście kiedyś musieli swojemu zarządowi wytłumaczyć na czym taki atak polega, to myślę że ten film jest najlepiej spędzonymi dziesięcioma sekundami na takie wyjaśnienia.

Dlaczego w ogóle o atakach DDoS rozmawiamy? One są od lat i nigdzie się nie wybierają. Różne firmy próbują liczyć statystyki, czasem im to wychodzi lepiej, czasem gorzej. Tu są dane z poprzednich dwóch lat i jak widać słupki do wzrostów, są dobre. Więc jeżeli tylko sprzedajecie usługi anty-DDoS, to takie wykresy są zawsze fajne, ponieważ te ataki mają tylko jeden kierunek – one rosną i zawsze będą rosnąć. Rośnie przepustowość i dostępność łączy. Jeszcze parę lat temu ataki o przepustowości czterobitowej leżały pewnie w zakresie możliwości dużych krajów, natomiast dzisiaj każdy nastolatek z botnetem jest w stanie takie przepustowości osiągnąć. Mamy w domach łącza po 100, 200, 500 Mbps. Przejęcie nad nimi kontroli i połączenie kilku tysięcy komputerów w zupełności wystarcza żeby zalać ruchem jeden serwis. Także pęd dostawców Internetu do świadczenia coraz większej prędkości, ma ten efekt uboczny, że coraz większa prędkość świadczona jest też autorom ataków DDoS.

Swego czasu, myślę że przez ostatnie 5-6 lat, dostawcy usług anty-DDoS regularnie publikowali raporty wskazujące na maksymalne przepustowości jakie zaobserwowali i faktycznie były te lata gdzie było to coś w rodzaju pojedynku – „a my widzieliśmy 50 giga”, „a my 80”, „a my 100”, „a my 200”… i tak naprawdę kiedy próbowałem przygotować slajdy do tych prezentacji i znaleźć najnowsze rekordy – bo wiadomo że rekordy są fajne, medialne i ładnie będą na slajdach wyglądać – to tak naprawdę taki ostatni imponujący rekord jaki znalazłem, pochodzi z lutego 2018 roku i dotyczył ataku na GitHuba, który poinformował, że przepustowość przekroczyła ponad terabit na sekundę. To dla mnie dosyć ciekawe, że przez ostatni rok nikt nie ogłosił większego sukcesu.

Czy to znaczy że nie było większych DDoS-ów? Wątpię. Czy to znaczy, że nie będzie już większych DDoS-ów? Też wątpię. Być może chodzi o to, że firma, która nie ma się czym pochwalić albo ich działy marketingu uznały, że nie ma sensu pobijać tych rekordów bo mówimy już o przepustowościach, które wykroczyły poza wyobraźnię większości inżynierów sieci, projektujących swoje rozwiązania. Bo kto na taki ruch się domyślnie przygotowuje? Biznesowo obsłużenie terabita na sekundę nie wydaje się być uzasadnione jeżeli nie jesteśmy jakimś usługodawcą typu YouTube czy Vimeo. Był potem jeszcze jeden atak sięgający koło 1.7 terabita i to dosłownie miesiąc później, natomiast tutaj nie mamy informacji o ofierze, ani o tym kto w ten sposób został zaatakowany. Także jedyne co możemy powiedzieć, to że liczba i skala tych ataków rośnie. I tu takie statystyki, które też byłem w stanie znaleźć – w pierwszej połowie 2017 roku jeden z dostawców usług anty-DDoS, zaobserwował 7 ataków większych niż 300 Gbps, zaś w pierwszej połowie 2018 roku było już 47 takich ataków. Nie zdziwiłbym się, gdyby w pierwszej połowie 2019 roku było ich ponad 100, a faktycznie ta skala rośnie.

Kto jest najczęstszym celem tych ataków? To zależy od skali. Te „najgrubsze” ataki dotykają oczywiście największe firmy i takim klasycznym celem ataku w ostatnich latach są głównie dostawcy gier online. Kiedyś wszyscy graliśmy offline w swoim pokoju, trzeba było zapraszać kolegów z komputerami, joystickami, a jeszcze lepiej z monitorami, żeby przyszli i się podłączyli i tego nikt nie DDoS-ował (chyba że ktoś się potknął o plątaninę kabli). Dzisiaj natomiast mamy gry online, w związku z czym to właśnie dostawcy gier są celami tego rodzaju ataków. Oczywiście tam gdzie są ataki, tam są i ofiary i jest ktoś, kto chce na nich zarobić. Kogo najbardziej boli atak DDoS? Pewnie kogoś, kto świadczy usługi w Internecie, a takim usługodawcą są głównie firmy hostingowi, które również odczuwają tego rodzaju ataki. W Polsce też mieliśmy taki kwartał gdzie przestępcy – nie wiemy czy krajowi czy zagraniczni – starali się zmusić firmy hostingowe do płacenia całkiem sowitych okupów, a jednym z przykładów jest atak na firmę Nazwa.pl z czerwca 2018 roku. Najpierw był atak o małej skali, pół godziny później nastąpił drugi, większy, który faktycznie mocno dotknął klientów. Kilka dni później pojawił się komunikat na ten temat. Faktycznie, nazwa komunikatu „Nazwa.pl powstrzymuje atak DDoS”, jest dosyć charakterystyczna, ponieważ atak DDoS można powstrzymać po prostu go przyjmując, czyli bierzemy ten cały ruch i go przyjmujemy, nasze serwisy nie działają, ale mówimy że go powstrzymaliśmy bo nie poszedł nigdzie indziej – to my go powstrzymaliśmy, bo my go przyjęliśmy. Powstrzymali więc go tak, że przestały działać usługi klientów, więc duża praca działu PR.

Oczywiście Nazwa.pl nie jest jedynym dostawcą tego typu usług w Polsce. Mamy również bardzo dużą firmę Home.pl, która z natury swojego biznesu gdzieś zaraz obok serwisu Nazwa.pl wśród ofiar tego ataku się pojawiła. Już we wrześniu mieliśmy sytuację gdzie także Home.pl został wyłączony. Czyli mówimy tutaj tak naprawdę o atakach takiej skali, że najwięksi dostawcy usług hostingowych, mają problem z obsłużeniem tego wyzwania, mimo iż w zasadzie można powiedzieć, że w 2018 roku powinni być już solidnie przygotowani do obsługi tego rodzaju incydentów i powinni mieć zbudowaną infrastrukturę, gotowe rozwiązania zapobiegające skutkom tego typu awarii. Okazuje się jednak, że gdy przyjdzie ktoś z dostatecznie dużą przepustowością, to również jest w stanie położyć bardzo duże, profesjonalnie działające firmy. W pewnym momencie Home.pl poszedł dosyć daleko w zakresie otwartości komunikacji – co jest bardzo pozytywnym sygnałem, że takie inicjatywy się zdarzają. Ewidentnie ktoś chciał się podzielić szczegółami, była rozpiska jakie były etapy tego ataku, o której godzinie, co się wydarzyło, jakie były skutki. Niestety tego posta już nie znajdziecie na profilu tej firmy, ponieważ ktoś inny uznał że te dane poszły za daleko i post został usunięty. Na szczęście udało się zachować zrzut ekranu. Naprawdę nie ma nic wstydliwego w tym, że byliśmy ofiarą ataku i myślę że kiedyś polskie firmy dojrzeją do tego etapu gdzie będą w stanie powiedzieć szczerze co się stało i jak taki incydent obsłużyły. Uwaga zupełnie na marginesie uwaga – dzielenie się tego typu informacjami na pewno nie jest pożądane przez działy PR lub działy prawne, natomiast dla działów IT jest to bezcenna wiedza, ponieważ atakowani z reguły jesteśmy razem, a bronimy się osobno. I to jest smutne, ale może niech to będzie tematem jakiegoś osobnego webinaru w przyszłości.

Jakie są skutki ataku na dużą firmę hostingową? Okazuje się, że odczuwają to klienci i to czasem boleśnie. SkyCash, którego pewnie kojarzycie, który obsługuje wiele różnych systemów płatności – za parkingi, bilety i inne usługi finansowe – korzystał z usług jednego z tych dostawców i musiał niestety ogłosić, że jego usługi są niedostępne dla klientów. Co to oznaczało? Jak ktoś jechał pociągiem i chciał kupić bilet tak jak zawsze, to nie mógł. Ktoś inny parkował samochód i nie mógł zapłacić za ten parking. To są bardzo niekomfortowe sytuacje dla klientów i można powiedzieć że po firmie dostarczającej usługi hostingowe, spodziewalibyśmy się że te usługi będą jednak działały całą dobę, cały rok, bo kiedy to się nie dzieje to klienci w zależności od profilu działalności, mogą mieć naprawdę poważne problemy, bo muszą teraz kaskadować ten komunikat o awarii swoim klientom i tak naprawdę są bezradni i mogą ewentualnie dzwonić do swojego opiekuna klienta, płakać w słuchawkę, ale to nie spowoduje szybszego przywrócenia dostępności usług. Ci atakujący z reguły wracają i próbują szczęścia, czasem z większym, czasem z mniejszym efektem, także Home.pl również kilka tygodni później ogłosił, że był kolejny atak. Natomiast ewidentnie uczymy się na atakach i to jest ten pozytywny wniosek, że firmy które zostały już skutecznie z-DDoS-owane, budują w ten sposób swoją wiedzą i doświadczenie i w przypadku kolejnych ataków, radzą sobie z nimi dużo lepiej i skuteczniej. Widać było, że kolejny atak faktycznie został odpowiednio zaadresowany i te skutki były mniejsze.

Co ciekawe w Polsce mieliśmy trochę interesujących incydentów związanych z DDoS-ami spoza sektora hostingowego. W maju 2016 roku mieliśmy bardzo ciekawy atak na polskie banki. Kilka banków otrzymało w prezencie ruch powyżej 50 Gbps. Większość poradziła sobie całkiem dobrze, niektórzy średnio, ale potem zaczęły sobie radzić lepiej, w każdym razie klienci atakowanych banków w większości nie odczuli tego, choć było to wyraźnie widać na systemach monitoringu przepustowości u dostawców tych banków, ponieważ tych 15 Gbps to był ruch, który faktycznie dostawca może zauważyć i może go to trochę zaboleć jeżeli nie jest odpowiednio przygotowany. Co ciekawe był to ruch bardzo wielosektorowy, bo był to zarówno atak wolumetryczny, jak i na poszczególne protokoły. Było to dosyć ciekawe, ponieważ wyglądało jak zbieranina wszystkich możliwych botnetów, które są do wynajęcia na rynku i zostały napuszczone na poszczególne polskie instytucje sektora finansowego. Fajne jest to, że przestępcy podszyli się pod niejakich Kadyrovtsów, czyli grupę czeczeńskich partyzantów. Oczywiście zakładamy, że sprawcy nie mieli nic wspólnego z Czeczenią prócz nazwy grupy, którą sobie przyjęli, natomiast tego rodzaju ataki mają miejsce okresowo. Wcześniej były np. ataki na dostawców bezpiecznej poczty, takich jak ProtonMail czy ich konkurencja Tutanota, i ta sama grupa czy też tak samo się identyfikująca, zaczęła potem atakować banki. Czyli ktoś wynajął sobie botnety, a następnie szukał celów tych ataków.

Co ciekawe podobnie podpisujące się grupy do tej pory atakują chociażby polskie centra handlowe, tyle że piszą, że w którymś z nich podłożyły bombę i żądają okupu w bitcoinach. Model biznesowy jest bardzo podobny, te ataki są mniej lub bardziej fikcyjne, a w przypadku bomb całkowicie fikcyjne. W przypadku DDoS-ów faktycznie one następowały, natomiast ich skala nie była wystarczająca aby infrastrukturze banków zagrozić.
Polski akcent też był bardzo ciekawy, gdy w 2015 roku wyciekły dane z jednego z serwerów dostawców usług DDoS, ponieważ jest to tak, że jeżeli chcecie wysłać do kogoś za dużo ruchu, to nie musicie robić tego sami, są dostawcy. Wszystko jest „as a service”, więc mamy dzisiaj również DDoS as a service. Jest cały ekosystem tego rodzaju dostawców. Jak ktoś już ma botnet, to chce go jak najlepiej zmonetyzować i jedną z wyobrażalnych metod monetyzacji takiej kontroli nad tysiącami komputerów wśród urządzeń na całym świecie, jest wykorzystanie ich do ataku DDoS. To był serwer grupy, która nazywała się Lizard Squad, a przynajmniej taką nazwę sobie przyjęli i faktycznie baza uczestników tej zabawy wyciekła i filtrując po domenach adresów e-mail, można było również znaleźć użytkowników, którzy mieli coś wspólnego z Polską. Rzut oka na ich hasła faktycznie wskazuje, że to nie tylko były e-maile w polskich domenach, ale także ci użytkownicy mogli mieć coś istotnego z Polską wspólnego. Oni nie przeprowadzili zbyt wielu ataków, natomiast na liście danych, które wyciekły, były także cele ataków i wśród nich nie było zbyt wielu polskich serwisów: jakiś sklep obuwniczy online lub jakieś mniejsze firmy, natomiast z ciekawszych rzeczy było kilkanaście serwerów w firmie HosTeam. Miałem wtedy okazję rozmawiać z szefem tej firmy i przekazał mi on informację, że te serwery obsługiwały gry online – głównie to była Tibia albo Minecraft – więc ewidentnie ktoś się uwziął na graczy i za pomocą tego botnetu DDoS-ował polskie serwery, na których stały serwery gier.

Inna bardzo ciekawa historia z atakami DDoS i wątkiem polskim, wiąże się z kasynem ClubWorld. W 2013 roku to kasyno było celem ataków DDoS i tak naprawdę celem wymuszenia. Autorami tego wymuszenia byli dwaj Polacy. Wiemy o tym, dlatego że samo kasyno miało siedzibę w Manchesterze, a w ramach brytyjskiego prawa tożsamości sprawców przestępstw – nawet podejrzanych – są ujawniane wraz z ich wizerunkami. Mogliśmy więc poznać imiona i nazwiska oraz zdjęcia sprawców, którzy zostali zatrzymani. Byli to dwaj biznesmeni, przedsiębiorcy ze Szczecina, członkowie zarządu jednej ze szczecińskich firm IT, którzy postanowili dorobić sobie szantażując właściciela jednego z brytyjskich kasyn online, wartego kilkanaście milionów funtów. Zaproponowali temu właścicielowi przeniesienie połowy udziałów w kasynie na ich spółkę, w zamian za rezygnację z ataków DDoS. Aby udowodnić swoją determinację, przeprowadzili skuteczne ataki DDoS wyłączające to kasyno. Co ciekawe panowie byli na tyle nierozsądni, że umówili się ze swoją ofiarą na spotkanie w hotelu, a ofiara była na tyle przytomna, że o tym spotkaniu poinformowała brytyjskie organy ścigania, w związku z czym spotkanie zostało zarejestrowane na video. Jak poszukacie na YouTube, to możecie znaleźć film z tego spotkania, oczywiście jego wycięte fragmenty, gdzie nasi biznesmeni siedzący po prawej stronie, twardo negocjują z biznesmenem brytyjskim przejęcie udziałów w biznesie, który zbudował. Panowie nie wiedzieli, że spotkanie jest nagrywane i że przy wyjściu spotkają brytyjskie organy ścigania. Skutkiem tej niewiedzy był wyrok w wysokości ponad pięciu lat więzienia. Został on wydany pod koniec 2013 roku więc wygląda na to, że jeżeli panowie odsiedzieli swoje zasłużone wyroki, to są już na wolności. Ciekawe jest to, że szantażyści udali się na spotkanie w hotelu. Co mieli w głowie? Prawdopodobnie jeden z portali sugerował, że wcześniej przeprowadzili udane podobno operacje i stąd było ich przekonanie o bezkarności i wpadka z szantażowaniem kasyna, które na szczęście źle się skończyło.

W Polsce ogólnie tych incydentów było dosyć sporo. 8 kwietnia 2015 roku doszło do ataku DDoS na serwery policja.pl i za atakiem stała rzekomo jakaś Polska Cyberarmia. Co ciekawe atak był faktycznie skuteczny i udało się serwis policja.pl wyłączyć. Natomiast tu trzeba przyznać że policja w tamtym ataku wykazała się dosyć dobrą, szybką i skuteczną reakcją, ponieważ już następnego dnia sprawca tego ataku został zatrzymany – co ciekawe ukrywał się na strychu domu swoich rodziców. Skuteczna akcja policji, pokazująca że faktycznie da się pewne rzeczy zrobić, natomiast po paru tygodniach w areszcie, sprawca został wypuszczony, ponieważ kolejne jego wpisy na Twitterze wyglądały tak, że szukał pomocy (niewiadomo za bardzo jakiej), natomiast zrobiła się mała afera, że policja poddaje opresjom działaczy Anonymous. Jak ktoś DDoS-uje serwer policji, to może, a raczej powinien liczyć się z tym, że policja z-DDoS-uje jego wolność osobistą i sprawa nie zostanie tak zostawiona.

Kolejna historia, z 2014 roku, jest dosyć ciekawa, ponieważ serwery OVH atakowały serwery OVH. Jak zaatakować firmę, która ma całkiem niezłe systemy anty-DDoS dla ruchu zewnętrznego? Przejąć kontrolę nad serwerami w sieci wewnętrznej i z-DDoS-ować sieć wewnętrzną. Co ciekawe w jaki sposób ten DDoS został zmitygowany. Na samym dole tego wpisu z bloga firmy, można wyczytać, że po prostu jedna serwerownia została odcięta od drugiej i ruch poszedł siecią publiczną, dzięki czemu udało się odetkać sieć wewnętrzną. Jest to jakieś rozwiązanie – jak dostajecie DDoS w sieci wewnętrznej, to wypuście go na zewnątrz, niech inni się martwią. Działa? Działa i jest skuteczne. Jak przykład pokazuje, można w ten sposób ruch w sieci wewnętrznej odetkać.

Bardzo ciekawe wydarzenie miało miejsce w 2016 roku, mianowicie GitHub przestał działać. Wielu z was zna pewnie ów serwis, część z was również korzysta z niego na co dzień. Niedziałający GitHub jest problemem dla wielu zespołów programistów na całym świecie. Nie tylko GitHub, ale również Shopify padło ofiarą tego ataku i tak naprawdę dopiero następnego dnia okazało się, że atak nie dotyczył GitHuba, Shopify, Spotify czy innych serwisów, które tego dnia przestały działać, tylko ich dostawcy usług DNS. To bardzo interesujące, ponieważ jeżeli okazuje się, że serwis, który atakujecie ma dobrą ochronę anty-DDoS, to być może właśnie jego słabym elementem jest jego dostawca usług DNS. Jeżeli ktoś nie korzysta z usług kilku dostawców na raz, to może się okazać, że wyłączenie tego dostawcy usług DNS, wyłącza dany serwis bo żaden klient nie jest w stanie dotrzeć do jego serwera gdy nazwa domenowa nie zostaje rozwiązana na adres IP. Więc ten atak miał dosyć spory zasięg i skutki. Co ciekawe, jednym z serwisów, który był klientem DNS-a i oparł się temu atakowi, był PornHub, który korzystał z usług sześciu różnych dostawców DNS. Jak widać gdy ma się poważne biznesy, to bardziej dba się o ciągłość działania.

W przypadku DDoS-ów mamy jeszcze inną ciekawą historię, gdzie tak naprawdę domyślne hasła sprawiły że problem się pojawił, ponieważ DynDNS został zaatakowany m.in. z użyciem Botnetu Mirai, który oparty był o kamery. Jeżeli zastanawiacie się kiedy powstanie botnet oparty o tostery, to obawiam się że nie powstanie nigdy, bez względu na to jak wiele tosterów zostanie podłączonych do Internetu. Dlaczego powstają botnety oparte o kamery, routery i dekodery, a nie o tostery, telewizory i lodówki? Nie z braku tosterów, telewizorów i lodówek podłączonych do Internetu, tylko ze względu na architekturę sieciową tych rozwiązań, bo jeżeli podłączacie toster do Internetu, to on raczej z Internetu nie będzie dostępny. On ma dostępny Internet, ale w drugą stronę nie, bo stoi sobie gdzieś za NAT-em, natomiast urządzenia które są przeroutowane do Internetu publicznego ze strony Internetu publicznego, to te do których chcecie się łączyć siedząc poza domem – np. w pracy chcecie zobaczyć kamerę, która jest w domu, dlatego to właśnie kamery, routery i nagrywarki systemów bezpieczeństwa video są najczęściej zaciągane do botnetów, ponieważ to są one dostępne dla połączeń z zewnątrz i taki właśnie był przykład Botnetu Mirai, który korzystał z podatności lub domyślnych haseł wielu tego rodzaju urządzeń i został wykorzystany m.in. do ataku na DynDNS.

To mapa awarii Internetu. W Stanach jak widzicie połowa Ameryki nie miała dostępu do niektórych usług internetowych, a przyczyna tego ataku – wyłączającego GitHuba, Shopify, Spotify i w niektórych rejonach świata także Facebooka – była dosyć prozaiczna: ktoś się z kimś pokłócił na jakiejś grze online i sprawcy nie mogąc wyłączyć serwera gry, który stał schowany za dobrą usługą anty-DDoS, wyłączyli usługę DNS tego serwera i w ten sposób wyłączyli serwer gry. Także nie denerwujcie graczy, bo mogą wyłączyć wam Internet.

Najbardziej znanym incydentem związanym z DDoS-ami w Polsce i na świecie i jednym z niewielu incydentów w Polsce, który zyskał zainteresowanie światowych mediów, jest słynny przypadek Polskich Linii Lotniczych LOT, które padły – tak przynajmniej na początku komunikowały – ofiarą ataku informatycznego, który spowodował anulowanie bodajże 10 czy 11 lotów. Co o tym ataku wiemy i co on ma wspólnego z DDoS? Po pierwsze już kilka chwil po pojawieniu się problemów, Polskie Linie Lotniczne wydały komunikat, że stały się przedmiotem ataku teleinformatycznego na naziemne systemy IT. Dla wszystkich osób zajmujących się bezpieczeństwem informacji, była to dosyć ciekawa wiadomość. W jaki sposób atak na naziemne systemy IT może wyłączyć możliwość startowania samolotów? Okazało się, że załogi samolotów nie mogą pobierać planów lotu i jest jakieś zatkanie sieci. W jaki sposób ktoś może zatkać sieć LOT-u? To było ciekawe. Analizujemy kolejne komunikaty i czytamy, że LOT stał się obiektem ataku na swoją sieć i mówimy o ataku zmasowanym, więc automatycznie kojarzy nam się to z atakiem DDoS i dowiadujemy się też, że LOT korzysta ze światowej klasy systemów i zabezpieczeń, dlatego też problem ten może dotyczyć całej branży lotniczej. Robi się naprawdę poważnie i nic dziwnego, że CNN mówi o tym w swoim głównym wydaniu wiadomości. Także domyślamy się, że ktoś z Internetu z-DDoS-ował sieć LOT-u i ten incydent właśnie na tym polega. Analizujemy temat dalej, pojawiają się kolejne informacje i w pewnym momencie czytamy, że to ludzkie błędy, a nie atak hakerów mogły uziemić LOT. Byliśmy ofiarą ataku, a jednak to były ludzkie błędy, to ciekawe. I to chodzi o błędy popełnione przez zewnętrzną firmę. Robi się interesująco. Czytamy więc dalej. Okazuje się, że spółka prosi prokuraturę o poszukiwanie włamywaczy. Więc mamy ludzkie błędy firmy zewnętrznej, a z drugiej strony mamy włamywaczy i jeszcze szef IT rezygnuje z pracy przy okazji. Jak zatem wygląda to naprawdę?

Wiele miesięcy później, publicznie pojawia się informacja, która w świecie bezpieczeństwa krążyła już od jakiegoś czasu, która mówi paradoksalnie, że systemy LOT-u nie były celem hakera, lecz jego narzędziem. Co to oznacza? To oznacza, że nie Internet DDoS-ował LOT, tylko LOT DDoS-ował Internet. Jak to w ogóle możliwe? Okazuje się, że rekonfiguracja firewalla w spółce, czy też jego wymiana bez przeniesienia pełnej konfiguracji, spowodowała, że serwer DNS firmy stał się dostępny publicznie. Szybko go jakiś chiński botnet zidentyfikował jako tzw. open resolvera, czyli serwer który umożliwia przeprowadzenie jednego z ataków DDoS i okazało się, że ten serwer został użyty do ataku DDoS na pewne podmioty zagraniczne. Faktycznie, łącza LOT-u były zatkane, natomiast były one zatkane ruchem wychodzącym, a nie przychodzącym. Problem był jakby podobnej kategorii, kierunek był jakby ten sam, tylko zwrot inny. Więc komunikat do tej pory gdzieś krąży w mediach, że to LOT był ofiarą, ale był też poniekąd współsprawcą i faktycznie pojawiła się informacja, nawet oficjalna, prokuratury, że system LOT-u został wykorzystany do działań wymierzonych przeciwko serwerom innych podmiotów. Jaki jest skutek tego, że na początku komunikacja była zupełnie odwrotna? Tutaj głęboki ukłon dla działu PR który o to zadbał. Więc do tej pory na prezentacjach międzynarodowych poświęconych bezpieczeństwu infrastruktury krytycznej, ten atak rzekomo na LOT, jest pokazywany jako jeden z najważniejszych ataków w historii.

Niewiele tych ataków jest udokumentowanych, więc każdy się do slajdów przydaje i na jednej prezentacji mogliśmy wyczytać, że LOT został zhakowany, a na innej że był jakiś atak w sieci wewnętrznej. Ciekawe to było, natomiast jakby dementi nigdzie w opinii publicznej się nie pojawiło, że nie mieliśmy do czynienia ani z hakowaniem, ani z DDoS-em, tylko tak naprawdę był to problem konfiguracyjny – pewne reguły firewalla nie zostały przeniesione na jego nową instancję. Dlaczego? Pewnie po prostu ktoś to wykonywał za niewielkie pieniądze i udało się, ale tak trochę nie do końca.

Jeżeli byście mnie spytali o atak DDoS, którego się najbardziej przestraszyłem, to był to atak z 30 listopada 2015 roku, przeprowadzony na sieć serwerów DNS obsługujących 13 głównych serwerów DNS, które zapewniają nam tak naprawdę działanie Internetu. Każdy z nich ma po kilkadziesiąt węzłów. Działają w takiej architekturze, że kiedyś to było 13 serwerów, a teraz to jest 13 razy kilkadziesiąt serwerów żeby zapewnić ciągłość ruchu. I oczywiście te root serwery mają zapewniony system monitoringu dostępny publicznie. Jeżeli zobaczycie dane z 30 listopada 2015 roku, to zimny dreszcz przechodzi po plecach, bo mimo iż było tam po kilkadziesiąt serwerów stojących za każdą z tych trzynastu maszyn, to ktoś się postarał i dla co najmniej połowy z nich wygenerował tyle ruchu, że wszystkie z tych kilkudziesięciu serwerów przestały odpowiadać na zapytania. Na szczęście ta architektura jest tak rozproszona, że pozostałe serwery przejęły ten ruch i nie udało się wyłączyć dostępu do serwerów DNS. Ale sam fakt, że ktoś był w stanie pokazać, zademonstrować, że połowę tych serwerów Root DNS – mimo ich całkowicie rozproszonej architektury – jest w stanie wyłączyć, pokazuje że mógł to być jakiś test organizacji, kraju czy kogokolwiek kto za tym stał, kto chciał sprawdzić czy da się w ogóle wyłączyć Internet wszystkim, na całym świecie. Więc taką karteczkę z adresami IP najważniejszych serwerów to może dobrze gdzieś trzymać w szufladzie, na wypadek gdyby ten eksperyment miał mieć jakiś ciąg dalszy.

Gdybyście kiedyś chcieli przetestować swoją sieć – oczywiście nie zachęcamy do testowania cudzych – to możecie bez żadnego problemu takie usługi kupić sobie online. Serwisy które pokazuję już nie działają, ale zostały zastąpione przez wiele innych. Są to profesjonalnie stworzone strony z opisami wszystkich zalet tych produktów. Niejeden marketingowiec mógłby się od nich uczyć. Anonimowość, różne protokoły, zróżnicowanie usług. Nawet są bardzo ładne strony z opisami jak te ataki DDoS można przeprowadzić albo w warstwie czwartej, albo w warstwie siódmej – do wyboru do koloru. Te firmy czy podmioty – bo nie wiem czy firmy za tym jakieś stoją – które to oferują, udają że te narzędzia służą do testowania własnej infrastruktury, a tak naprawdę oczywiście używane są przez przestępców i potem organy ścigania zatrzymują sprawców, natomiast trochę to trwa. Często można tam sobie taką darmową usługę testową zakupić, są nawet rabaty na Black Friday. Jest to jakby normalny biznes, który udaje że jest legalny, natomiast oczywiście jest wykorzystywany do działań daleko wykraczających poza tę strefę legalną. Pewnie te przepustowości, które ogłaszają w swoich prospektach marketingowych typu terabit na sekundę, są mocno fikcyjne, natomiast gdybyście wpadli na pomysł połączenia kilku rodzajów tego typu usług żeby bardziej skutecznie przetestować swoją infrastrukturę, to chciałem powiedzieć, że model biznesowy tego rodzaju firmy raczej do tego nie zachęca, ponieważ nie są to sami dostawcy usług DDoS – są to resellerzy i oni prawdopodobnie bazują na jednym i tym samym botnecie, który sprzedaje im te usługi, a oni je z marżą odsprzedają dalej. Czyli ktoś kto ma botnet nie bawi się w marketing, sprzedaż i reklamę, tylko odsprzedaje takie usługi hurtowo, ze znaczącym rabatem, a potem różne podmioty dbające o stronę marketingowo-sprzedażową, pakują te usługi pod różnymi logo i oferują swoim klientom. Czyli jak kupicie usługi od trzech różnych podmiotów, to może okazać się, że cały czas ten sam botnet będzie ten ruch wysyłał. Pakiety są różne jak widzicie, nawet od 15$ miesięcznie można sobie wykupić 5 minut DDoS-a z przepustowością do 250Gbps, czyli całkiem przyzwoicie, choć nie spodziewam się, że ta przepustowość zostanie faktycznie wyświadczona klientowi, ponieważ będąc klientem tego typu usługi macie ograniczone możliwości pomiaru skuteczności, chyba że atakujecie rzeczywiście swój własny adres IP. Niektórzy oferują dużo większe przepustowości, inni mniejsze.

Tak jak wspominałem, są to usługi trialowe, można sobie to przetestować czy to działa czy niekoniecznie, natomiast najbardziej mnie rozbawia kiedy wchodzę na stronę firmy oferującej usługi DDoS i okazuje się, że korzysta ona z usług firmy anty-DDoS żeby ich strona mogła działać. Dlaczego? Wyobraźcie sobie, że działacie w biznesie sprzedawania usług DDoS i kto jest waszym konkurentem? Inne firmy oferujące usługi DDoS? Ciekawe do czego będą ich używać? Więc jest to dziki rynek i faktycznie te firmy robią sobie nawzajem różne psikusy. Śmiesznie wygląda strona DDoS-era schowana za usługą anty-DDoS.

Dziękuję za wysłuchanie mojej części i przekazuję głos Teodorowi, który opowie wam o jednym z rozwiązań anty-DDoS.

— Teodor Buchner —

Bardzo dziękuję za wprowadzenie. Masa ciekawych slajdów i bardzo dużo się nauczyłem. Nauczyłem się np. żeby na negocjacje handlowe przychodzić z kolegą – jeden ubrany w czarną koszulę, a drugi w białą. Zakładam, że bawili się w dobrego i złego policjanta.

— Adam Haertle —

Tak, na tym filmie jeden faktycznie mówił, a drugi nie bardzo.

— Teodor Buchner —

Rzeczywiście ciekawa jest perspektywa DDoS w 2019 roku, bo te ataki się rozwinęły i widać że handlowo mają cały czas rację bytu. Chciałem się Ciebie o jedną rzecz spytać – z doświadczenia ataków, których dokumentację widziałeś – czy te botnety występują pod swoimi własnymi adresami IP?

— Adam Haertle —

Są różne strategie i faktycznie mamy tu zarówno do czynienia z atakami DDoS z adresów IP faktycznych sprawców, ale mamy też do czynienia oczywiście z fałszowaniem adresu źródłowego żeby ukryć tożsamość sprawcy. Jeśli tylko mogą, to najchętniej korzystają z protokołów bezstanowych, umożliwiających ukrycie adresu źródłowego.

— Teodor Buchner —

Bo to jest ciekawy wątek. Jeżeli mam botnet, który ma 35 tysięcy hostów i chciałbym go zmonetyzować na jak największą liczbę różnych sposobów, to czy rzeczywiście najlepszym sposobem będzie ogłoszenie wszystkich adresów IP należących do tego botnetu? Bo jeżeli ktoś sobie taki atak DDoS pozbiera, posiedzi i przegrupuje po source IP, to teoretycznie paru administratorów może mieć zepsute święta. Siedzę tu gdzie siedzę i mówię z perspektywy operatora telekomunikacyjnego. Myślę, że społeczność operatorów telekomunikacyjnych na świecie, powinna się uderzyć w piersi, ponieważ istnieją dobre praktyki dotyczące czyszczenia ruchu wychodzącego, i każdy z operatorów który obsługuje jakiś system autonomiczny ma takie narzędzia i powinien sprawdzać czy ruch, który wypuszcza, jest ruchem z adresu który on sam ogłasza albo który przez niego przechodzi, albo które sam generuje. Praktyka jaka jest to oczywiście sami widzimy i w związku z tym jest to aspekt, który dodaje tym przestępstwom skuteczności, dlatego że mogą korzystać z sfałszowanych adresów, nie muszą podawać swoich adresów jako adresów źródłowych, tylko wystarczy że podadzą dowolny adres z przestrzeni IPv4 i operator jest zadowolony i przepuszcza taki ruch bo przecież jeszcze na nim zarabia i wszystko działa, z wyjątkiem serwisu ofiary.

Rzeczywiście udało nam się jakiś wkład wytworzyć w ochronę anty-DDoS. Oczywiście nie jesteśmy na tym rynku pierwsi i tych rozwiązań już trochę poza Polską było, ale również w Polsce. Natomiast z naszego głębokiego przeświadczenia wynika, że gdzieś tam operator telekomunikacyjny jest odpowiedzialny za swoje łącze i za swoich klientów i w ramach tej odpowiedzialności jeżeli ma potencjał do rozwijania narzędzi, to powinien to robić. Myśmy się rzeczywiście postarali gdzieś w tej konkurencji wystąpić. I teraz chciałbym dwa słowa o tym powiedzieć w kontekście, który wprowadził Adam. Rozwiązanie, które niedawno udało nam się skończyć, to rozwiązanie programistyczne chroniące sieci operatorskie przed atakami typu DDoS. Co jest ciekawe w tym tytule, to moim zdaniem to, że jest to rozwiązanie programistyczne, tzn. udało nam się zbudować rozwiązanie w całości na technologiach software’owych. Kto raz w życiu widział VHDL, to wie że programowanie układów FPGA nie należy do przyjemności. Dużo lepszy jest pod tym względem C++ i dużo łatwiej znaleźć ludzi, którzy taki kod zbudują, przetestują, poszukają w nim podatności i ludzi, którzy będą w końcu ten kod utrzymywać. I nam się rzeczywiście taki zespół profesjonalistów udało zbudować, który ramię w ramię z naszym Security Operations Center zabrał się właśnie za tworzenie takiego rozwiązania.

Tutaj macie mniej więcej strukturę takiego systemu i w jaki sposób on działa. Więc mamy tutaj dwa elementy – mamy sondę ruchu, która działa na protokołach pomiarowych i agreguje dane pochodzące z routerów. Atak DDoS przypomina atak trolla z dużą maczugą, w związku z tym trudno go przeoczyć. Mimo że dane o ruchu, które są udostępniane przez routery brzegowe, są samplowane, tzn. my widzimy statystyki dotyczące cotysięcznego pakietu, to okazuje się, że do ataków wolumetrycznych jest to ilość wiedzy która całkowicie wystarcza. Oczywiście były pewne pułapki w samej agregacji tego, dlatego że informacja z routerów spływa w porcjach, w związku z tym było wyzwaniem żeby te porcje w jakiś sensowny sposób skleić w taki pojedynczy parametr, który opisywałby stan danego łącza, ale to się na szczęście udało zrobić i w związku z tym mamy sondę, która potrafi nam wykryć, że rzeczywiście coś jest nie tak i jeżeli mamy sygnał z tej sondy, to możemy sobie wewnętrznie taki ruch przełączyć na jednostkę czyszczącą. Mamy operatora, który może albo takie decyzje podejmować albo może takie decyzje podejmować również automat, w zależności od tego jak system jest skonfigurowany. System ma tę zaletę, że się dobrze skaluje bo jest w zasadzie zbudowany na standardowym sprzęcie IT. Tak jak mówiłem FPGA nie wymaga, więc tutaj mamy bardzo niską technologiczną barierę wejścia. Jest to dosyć prosty język, o ile C++ można nazwać prostym językiem, ale jeżeli nie C++ nazwiemy prostym językiem to już naprawdę nie wiem który język. Pythona też użyliśmy, jeżeli chodzi o proste języki.

Tu są dane o projekcie. Generowaliśmy ten projekt z partnerem, uczelnią techniczną, w związku z czym korzystaliśmy wzajemnie ze swoich kompetencji. Są to dane publicznie dostępne więc niczym się tu nadmiernie nie chwalę. Architektura rozwiązania oparta jest o x86. Tutaj dochodzimy do ciekawego zagadnienia z perspektywy IT, mianowicie ogarnięcie łącze 10 gigabitów i wyżej. Ci którzy się tym kiedykolwiek zajmowali lub próbowali taki ruch analizować, to wiedzą że czasu na analizę pojedynczego pakietu jest bardzo mało, w związku z czym trzeba to zrobić wydajnie. Jeżeli wydajnie, to pewnie wielowątkowo, w związku z czym rzeczywiście zrobiliśmy rozwiązanie wielowątkowe na poziomie modułu czyszczącego i ze wszystkimi radościami związanymi z wieloma wątkami, czyli synchronizacja wątków, dostępy do współdzielonych zasobów itd. Tematów było sporo. Myślę że gdybyśmy któregoś dnia postanowili opowiedzieć o tym wszystkim, to by się z tego sesja naukowa zrobiła, bo tych problemów technicznych do rozwiązania było po drodze rzeczywiście dużo.

W zasadzie ta część ponad techniczna, obsługowa, jest dosyć rutynowa, bo tu w zasadzie jest system webowy do zarządzania konfiguracjami, klientami czy wszystkim czym da się zarządzić z konsoli operatora. Natomiast rzeczywiście niestandardowe rozwiązania są na dole i z tego jesteśmy zadowoleni, że to się udało. Jest to materiał na którym można budować, dlatego że jeśli mamy już taką platformę zbudowaną, to tak naprawdę możemy jej próbować użyć w rozmaitych kontekstach. Mam nadzieję, że w ciągu najbliższych miesięcy usłyszycie od nas o tym w którą stronę postanowiliśmy się rozwijać, ale wyzwań nasz zespół ma nadal bardzo dużo. Myślę że jest to dobry prognostyk na przyszłość.

Rozmawiamy właściwie cały czas o atakach wolumetrycznych, a to nie wyczerpuje całości zagadnienia. Był kiedyś taki piękny atak Ping of Heath, chyba w czasach Windowsa 95. Był to atak pojedynczym pakietem, który potrafił wyłączyć cały system i on trochę ludziom otworzył oczy na taką rzeczywistość, że żeby wywołać niedostępność systemu, to wcale nie potrzeba dużej ilości pakietów. Myślę, że ci z was, którzy zajmowali się kiedykolwiek budową i utrzymaniem systemów informatycznych i oglądali np. logi z działania jakiegoś serwera aplikacyjnego i siedzącej pod nim bazy danych, to wiedzą że bywają takie sytuacje że klient wysłał całkowicie legalne zapytanie, a na bazie zabrakło jednego indeksu czy dwóch czy trzech, w związku z tym zapytanie się miele, aplikacja się muli, klient się denerwuje, aż w końcu sesja się zrywa i jak się zrywa to próbuje jeszcze raz, w związku z czym obciążenie na serwerze rośnie i mamy właściwie taki autoatak DDoS, tzn. taki, że twórca systemu z-DDoS-ował sam siebie, czyli zrobił taki system, którym można jednym dobrze skrojonym zapytaniem, zamulić cały system. Więc rzeczywiście taki atak DDoS nie jedno ma imię. Na różnych poziomach można taki atak generować.

Taki najprostszy atak wolumetryczny to jest dokładnie taki atak trolla, natomiast możliwe są też ataki dużo bardziej wyrafinowane, czy takie ataki w warstwie siódmej po prostu na źle napisaną aplikację, którą jest łatwo położyć, stosunkowo niewielką ilością pakietów. Jest to taka liczba pakietów, która nie przejdzie pod poziomem peryskopu operatora. Operator ma w ogóle szansę tego nie zauważyć. I tego typu ataków było więcej, również na sam protokół TCP. Jak np. Slowloris, że może być pakiet i może być atak na warstwie siódmej i zanim się zdążyło zamknąć sesję http, to dokładamy do niej tuż pod koniec jeszcze jeden pakiet i zmuszamy serwer do tego żeby miał zaangażowane zasoby w obsługę cały czas tej sesji – nie pozwalamy jej umrzeć w spokoju. Ten sam manewr można zrobić na poziomie sesji TCP. Można też tak dorzucać po pakiecie i wtedy serwer też się w efekcie zatyka. Tutaj rzeczywiście widać znaczącą różnicę między TCP a UDP. Serwery TCP ze względu na to że są stanowe, że te połączenie jest cięższe do obsłużenia, jest je trochę łatwiej zatkać w związku z tym jest taki trend przesiadania się na połączenia bezstanowe, czyli przechodzenie z TCP na UDP, a obsługiwania retransmisji czy innych rzeczy takich związanych z ciągłością sesji na poziomie warstwy siódmej. I w tę stronę ten rynek internetowy idzie i to się gdzieś tam staramy śledzić i na te przejście powoli przygotowywać.

Więc jeżeli mówimy o kompleksowości rozwiązania TAMA, to cały czas mówimy przede wszystkim o atakach wolumetrycznych. Mamy natomiast na deskach kreślarskich rozłożony projekt rozszerzający zakres takiej ochrony, w związku z tym tu rzeczywiście staramy się nie zasypiać gruszek w popiele. Więc mamy skalowanie, wydajność, elastyczność i wiele różnych cech systemu rozproszonego, które w tym momencie dają nam taką biznesową wartość dodaną. I umówmy się – nie mamy dużo polskich rozwiązań, które doszłyby do wdrożenia, w związku z tym dołączyliśmy w zasadzie do pewnego elitarnego dosyć klubu i z tego się bardzo cieszymy, wierząc że będzie to rozwiązanie, które zadowoli nas i naszych klientów i pozwoli na rozwój tej platformy technologicznej w różnych kierunkach.

Starałeś się śledzić legendę dotyczącą ataków niewolumetrycznych? Czy one sobie znajdują gdzieś rację bytu w tym podziemnym świecie?

— Adam Haertle —

Wydaje mi się, że w świecie DDoS-ów mamy tak naprawdę do czynienia, jak słusznie zaobserwowałeś, z trollem. I od trolla trudno oczekiwać większego wyrafinowania. Jednak temu trollowi najprościej jest machnąć tą maczugą i te ataki wolumetryczne faktycznie są najpopularniejsze, ponieważ tam po prostu działa to na zasadzie „odpalamy i zapominamy”, a jest to na tyle uniwersalne że nie trzeba tego szczególnie dostosowywać do konkretnych ofiar. Ewentualnie to co trzeba dostosować to wolumeny i widać, że jeżeli mówimy o najczęstszych celach atakujących, typu serwery gier, to raczej nie spodziewamy się, że są to jakieś pojedynki profesorów kryptografii – chociaż może niesłusznie obrażam profesorów kryptografii czy też graczy – natomiast jeżeli ktoś bardzo chce, to faktycznie jest w stanie wyczerpać zasoby na innych warstwach, natomiast wymaga to faktycznie przygotowania, podejścia, analizy. Znamy przykłady chociażby banków, które nawet w Polsce w zeszłym roku jednego dnia przestały działać – było to bodajże 10 grudnia, dzień wypłat w wielu polskich firmach. Jednocześnie był to poniedziałek więc zakolejkowały się jakieś zakupy internetowe i okazało się, że systemy 4 czy 5 polskich banków padły pod atakiem DDoS wygenerowanym przez ich własne systemy lub klientów i faktycznie były to ataki na innych warstwach. W jednym banku wysiadł mechanizm wysyłania sms-ów, w innym nie podołały serwery WWW. Dzisiaj wystarczy zwykła promocja na Xiaomi i tak jak wczoraj widzieliśmy wyłącza każdy serwer, nawet bardzo dobrze przygotowany. Choć trzeba przyznać, że na Black Friday większość dostawców jednak podołało. Może promocje były za słabe. Jakby była lepsza promocja to i serwery by padły. Także widać że faktycznie te ataki na innych warstwach niż w modelu wolumetrycznym, są raczej spontanicznie generowane przez popyt. Bardzo rzadko mamy do czynienia z faktycznie atakującymi, którzy przeanalizowali infrastrukturę ofiary. Co więcej, przeanalizowanie faktycznie co działa, a co nie działa bez dostępu do systemów monitoringu jest trudne, bo DDoS-ujemy sobie kogoś na warstwie siódmej i nie wiemy czy już jesteśmy w połowie sukcesu czy w 90%, czy może oni właśnie dołożyli 16 nowych procesorów tak że jakoś podołają, więc myślę że z punktu widzenia atakującego dużo prościej jest po prostu zwiększać wolumen i patrzeć aż padnie, niż wnikać w wyższe warstwy protokołu. Spodziewam się, że faktycznie gdybym słyszał o jakimś ataku gdzie ktoś wyczerpywał zasoby gdzieś w backendzie, niewolumetrycznie na łączu, to raczej szukałbym sprawców wśród pracowników organizacji, którzy wiedzą gdzie są te słabe punkty i są w stanie je odpowiednio zaatakować.

— Teodor Buchner —

Jest rzeczywiście taki współczynnik cost effectiveness np. w atakach typu reflective gdzie mierzy się współczynnik wzmocnienia i ten atak zasadniczo polega na tym żeby wykorzystać usługę taką jak LOT, jako taki punkt odbicia, trampolinę do zaatakowania kogoś zupełnie innego i tam rzeczywiście liczy się stosunek ruchu wprowadzonego do ruchu wyjętego, bo przecież nie chodzi o to żeby atakujący generował sam terabajt na sekundę ruchu, który następnie zostanie przekazany gdzieś tam dalej, tylko żeby wziąć najlepiej kilobajt, a wygenerować terabajt.

— Adam Haertle —

Najlepsze z tych ataków typu odbitego generują współczynnik nawet kilkudziesięciokrotnego zwrotu, typu wysyłamy jedno zapytanie do serwera DNS, który ma kilkanaście bajtów, a w odpowiedzi dostajemy kilka kilobajtów. Takie ataki są poszukiwane przez atakujących i myślę, że jak popatrzymy na historyczne wykresy aktywności ataków DDoS, to mamy tak naprawdę wykresy zarówno tworzenia botnetów, jak i wykresy odkrywania kolejnych metod ataku, ponieważ są one wykrywane, są wykorzystywane, serwery są łatane – ostatnio to był Memcached, wcześniej DNS-y. Tych usług, które już były użyte w tego typu atakach jest co najmniej kilkadziesiąt i po prostu za każdym razem kolejne są łatane.

Pytania:

Co zrobicie jeśli pojawi się nowy typ ataków?

— Teodor Buchner —

W przypadku rozwiązań w zasadzie software’owych, takich jak nasze, to przygotowanie łatki i deployment. Jest to zasadniczo szybka operacja. Co to znaczy szybka? Pierwszą linią obrony jest konfigurowalność samego urządzenia i tam możemy już sporo zrobić jeśli chodzi o to w którą stronę potrafi ono rozszerzyć zakres ochrony. Także takie najprostsze ataki typu użycie nowego protokołu, jesteśmy w stanie obsłużyć konfiguracją. Jeżeli natomiast pojawi się atak, który wymaga większej precyzji w oddzielaniu ziarna od plew, to wtedy myślę że w ciągu 24 godzin.

— Adam Haertle —

Zdarzają się faktycznie ataki, które się powtarzają, wracają, natomiast wydaje mi się, że tutaj kwestia jest tego, że bardzo rzadko tak się zdarza, że ktoś jest atakowany czymś zupełnie nowym, czego nie było wcześniej. O ile nie mówimy faktycznie o tych atakach aplikacyjnych, targetowanych na konkretnego klienta, to najczęściej dowiadujemy się o pojawieniu nowego ataku z jakiegoś raportu dużej firmy zajmującej się ochroną anty-DDoS i następnego dnia już wszystkie firmy są na ten atak mniej lub bardziej przygotowane i zanim pojawią się kolejne ofiary, rozwiązania zabezpieczające już istnieją. Przestępcy i tak z tego korzystają, bo wiele firm nie korzysta z anty-DDoS-ów więc jakby ofiar nie brakuje, natomiast wiedza jak się chronić przed atakami rozszerza się dosyć szybko, więc myślę że możemy spokojnie przyjąć, że następnego dnia z reguły większość tych klientów jest już chroniona.

— Teodor Buchner —

To znaczy rzadko kiedy zdarza się żeby atakowany był serwis w firmie, który operuje na dokładnie tym porcie, w związku z tym jeżeli ktoś mnie atakuje protokołem dla Xboxa, to jest to coś co mogę zasadniczo wyciąć na łączu na różne sposoby.

Czy będzie implementacja z systemami SIEM?

Zasadniczo wyrzucamy logi w formacie, który nadaje się dla kolektora, w związku z tym dołożenie ich do SIEM-a to nie jest kwestia jakiegoś rocket science. Jest jakiś standard tych logów, w związku z tym integracja jest jak najbardziej możliwa.

EXATEL nie zajmował się dotąd wytwarzaniem rozwiązań dla branży security. Macie jakieś kompetencje w tym obszarze?

Jesteśmy obecni w tematyce security nie od dziś i z Security Operations Center zaczęliśmy budować już parę lat temu – to był jeden z pierwszych komercyjnych SOC-ów w Polsce – i ten SOC zajmował się jak najbardziej tworzeniem rozwiązań na własne, wewnętrzne potrzeby. W związku z tym wiele różnych pomysłów ujrzało tam światło dzienne za przyczyną różnych zdolnych osób, które przez ten SOC się przewinęły i my kontynuujemy pewną tradycję.

Kto właściwie napisał ten system: Wy czy Politechnika Warszawska?

To jest ciekawe zagadnienie: jaka jest dynamika rozwoju zagadnień security na polskich uczelniach. Jak tak obserwuję z perspektywy akademickiej, to ten rozwój teraz jakoś mocno przyspieszył, w związku z tym na pewno tych kompetencji będzie dużo więcej, natomiast dla takich tradycyjnych jednostek zajmujących się telekomunikacją to wejście w server security jest często nowym zagadnieniem, w związku z tym są to kompetencje, które żeśmy gdzieś tam wspólnie budowali.

Jest też pytanie o uczenie maszynowe. Tu przy obsłudze łącza o takiej przepustowości, jest niewiele czasu na podejmowanie decyzji, w związku z tym rozwiązania z obszaru uczenia maszynowego bardziej pasują do filozofii Deep Packet Inspection, czyli jeżeli mamy jakiś pakiet, który chcemy sobie głębiej obejrzeć, to mamy czas żeby go wpuścić w jakieś uczenie maszynowe, ale udało nam się użyć w kodzie perceptronu i to w zasadzie na ten moment wszystko co tam rzeczywiście działa z szeroko rozumianego uczenia maszynowego – natomiast widzimy oczywiście model użycia takich technik na dalszych etapach przetwarzania pakietów.

W jakich kierunkach chcecie rozwijać produkt?

Tutaj rzeczywiście wyzwaniem są ataki niewolumetryczne. Może ich znaczenie nie jest tak duże ze względu na to że nie są w takim stopniu wykorzystywane przez świat przestępczy ze względu na to, że nie mają takiej mocy obalającej jak pocisk kalibru 045, ale tym niemniej potrafią obciążyć systemy i ze względu na to warto mieć świadomość że tego typu atak nastąpił. Poza tym odkryliśmy ciekawą kopalnię wiedzy, jaką jest globalna tablica routingu z której wiele ciekawych rzeczy można się dopatrzeć, które mają pewne znaczenie dla ataków DDoS, np. protokół SSDP, taki protokół do rozpoznawania routerów, to jego np. częstym źródłem jest wiele niezabezpieczonych hostów, które można użyć do ataku typu odbitego przy pomocy protokołu SSDP na obszarze Republiki Południowej Afryki i taka informacja się np. przewinęła, że akurat tam jest dużo. Więc to są takie informacje, które można śledzić analizując globalną tablicę routingu, a wiele różnych ciekawych rzeczy też się tam dzieje więc być może jak nazbieramy więcej wiedzy to o tym powiemy.

A jak chcecie konkurować z rozwiązaniami w które inwestowano od 20 lat?

Chciałbym powiedzieć tak, że firma Cisco została założona przez dwóch studentów w garażu, w związku z tym każda firma, nawet bardzo duża, buduje swoje kompetencje od jakiegoś poziomu. Budujemy swoje kompetencje wychodząc od tego co wiemy jako operator telekomunikacyjny, będący na rynku od 20 lat i myślę, że pewną ilość wiedzy na temat dynamiki sieci i ich konfiguracji udało nam się zgromadzić, w związku z tym, jest to jakiś kapitał na którym można różne rzeczy budować.

— Adam Haertle —

Odpowiemy na te pytanie za 20 lat.