Ochrona przed DDoS
Powodzie są pochłaniane na skraju sieci, ataki na warstwie sieciowej są filtrowane powyżej, a wszystko, co dociera do serwera, jest izolowane we własnej klatce na poziomie jądra danej witryny. Kilka warstw, z których każda pełni inne zadanie, dzięki czemu atak wymierzony w jedną witrynę nie powoduje awarii sąsiednich. Oto model obrony, który stworzyliśmy dla platformy hostującej ponad 650 000 witryn na całym świecie, a jego wersja bazowa działa w każdym planie. Dostępność: ograniczanie przepustowości baz danych dla poszczególnych witryn jest w fazie aktywnego rozwoju i nie jest jeszcze dostępne. Wszystko inne, co opisano tutaj, działa już dziś.
Atak wolumetryczny, atak na warstwę 7 oraz atak polegający na wyczerpaniu powolnych połączeń to trzy różne problemy. Radzimy sobie z każdym z nich tam, gdzie jest to najtańsze i najszybsze – przed flotą, na brzegu sieci oraz wewnątrz klatki.
Ochrona przed atakami DDoS na poziomie dostawcy filtruje ataki warstwy sieciowej przed naszą flotą workerów, zanim ten ruch zdąży zużyć port, kartę sieciową lub cykl procesora na maszynie, na której działa Twoja strona. W przypadku zaawansowanych i korporacyjnych profili ryzyka rozwiązania Cloudflare Magic Transit oraz Spectrum rozszerzają tę samą filtrację na ruch niebędący ruchem HTTP.
Zarządzana sieć brzegowa znajduje się przed każdą witryną. Pochłania ona wolumetryczne ataki typu HTTP flood, uruchamia WAF warstwy 7, stosuje ograniczenia liczby żądań dla każdej witryny oraz wykorzystuje zarządzanie botami i zarządzane wyzwania w celu oddzielenia prawdziwych użytkowników od ruchu zautomatyzowanego — a wszystko to zanim żądanie dotrze do źródła.
LiteSpeed Enterprise stosuje ograniczenia połączeń i żądań za pomocą limitów połączeń na adres IP, Imunify360 uruchamia zapory sieciowe z ochroną przed atakami brute-force i filtrowaniem reputacji adresów IP, a limity procesów wejściowych CloudLinux LVE ograniczają liczbę jednocześnie obsługiwanych żądań, jakie pojedyncza witryna może otworzyć.
LVE ogranicza procesor, pamięć RAM, operacje wejścia-wyjścia (IO), operacje IOPS, procesy oraz procesy wejściowe (entry-processes) dla każdej strony indywidualnie. Atak, który przedostanie się przez wyższe warstwy, jest dławiony we wnętrzu "klatki" docelowej strony, dzięki czemu wywoływane przez niego obciążenie pozostaje w obrębie tej strony, zamiast rozprzestrzeniać się na cały serwer.
Większość awarii hostingowych podczas ataku nie jest spowodowana dotarciem ataku do celu. Wynikają one z tego, że zużycie zasobów przez cel pozbawia zasobów wszystko inne na serwerze. To jest właśnie tryb awaryjny, który ta architektura ma na celu wyeliminować.
Najtańszym do obsłużenia zapytaniem jest to, które nigdy nie dotyka PHP ani MySQL. Nasza dwuwarstwowa pamięć podręczna sprawia, że na większość zgłoszeń zalewających warstwę aplikacji odpowiadają statyczne bajty, a nie praca wykonywana przez Twoje źródło.
Mititygacja to nie zgłoszenie do wsparcia. Sygnały zasilają silnik zasad, który przypisuje każdy z nich do działania egzekucyjnego, powiadomienia klienta oraz — tam, gdzie to możliwe — automatycznego usuwania skutków awarii, przy czym każde przejście jest rejestrowane.
Gdy uruchamia się sygnał DDoS, silnik polityk stosuje mitygację Cloudflare oraz ograniczenia częstotliwości zapytań dla poszczególnych witryn, a także może dynamicznie zaostrzać limity LVE dla danej witryny. Gdy sygnał mija, limity ponownie się luzują. Stopniowo, odwracalnie i rejestrowane na każdym kroku.
Jeśli atak zagraża źródłu, witryna przechodzi w stan „ograniczenia” (throttled) – obowiązują wtedy surowsze limity LVE i ograniczenia szybkości, ale witryna nadal działa i obsługuje ruch. Stan ten odzyskuje sprawność automatycznie po ustąpieniu presji; nie jest to zawieszenie.
Poniżej silnika polityk LVE natywnie i automatycznie ogranicza zużycie procesora, operacji We/Wy oraz procesów dla każdej witryny. Jest to stale włączona pierwsza linia obrony, działająca niezależnie od tego, czy cokolwiek zdążyło już zaklasyfikować ruch jako atak.
Każda zmiana egzekwowania przepisów rejestruje swój powód, informuje, czy była automatyczna, czy zainicjowana przez personel, oraz zawiera dowody, na których się opiera. Zostajesz powiadomiony o tym, co się zmieniło i jak to rozwiązać, a od każdej akcji przysługuje odwołanie.
Podstawowa ochrona nie jest opcjonalna, ponieważ zaatakowana lub zhakowana strona zagraża sąsiednim witrynom, reputacji naszego serwera oraz naszym zakresom adresów IP. Silniejsza ochrona jest dostępna dla stron, których profil ryzyka tego wymaga.
Wzrost ruchu to często tylko objaw. Ten sam strumień danych, który obsługuje nagłe napływy, wyłapuje również naruszenia bezpieczeństwa, które je powodują, dzięki czemu incydent zostaje poprawnie zakwalifikowany, zamiast zostać po prostu zignorowany.
Celem projektowym jest izolacja. Każda witryna działa we własnej klatce CloudLinux LVE z ograniczeniami procesora, pamięci RAM, operacji we/wy, IOPS, procesów i procesów wejściowych (entry-processes), we własnym widoku systemu plików CageFS oraz z dławieniem baz danych dla poszczególnych witryn za pomocą MySQL Governor. Zaatakowana witryna jest dławiona na poziomie swojego własnego limitu, zamiast obciążać całą maszynę, a limity połączeń na adres IP w LiteSpeed ograniczają zasoby serwera WWW, jakie może ona zajść. Izolacja jest zaprojektowana na poziomie jądra, a nie konfigurowana indywidualnie dla każdego klienta.
Podstawa jest zawarta w każdym planie: izolacja LVE i CageFS, throttling połączeń i żądań LiteSpeed, zapora sieciowa, proaktywny WAF i skanowanie złośliwego oprogramowania, z absorpcją na brzegu sieci Cloudflare i filtrowaniem sieciowym na poziomie dostawcy przed całą flotą. Uwzględniamy to, ponieważ ochrona naszej własnej floty nie może być opcjonalna. Zaawansowane zarządzanie botami, wyższe poziomy DDoS, ulepszone reguły WAF i dedykowane reguły zapory sieciowej to dodatki dla stron, które ich potrzebują.
Bycie celem ataku DDoS oznacza mitygację ze strony Cloudflare plus limitowanie częstotliwości zapytań dla każdej strony oraz – tylko wtedy, gdy atak zagraża serwerowi źródłowemu – stan „przykręcony” (throttled): surowsze limity LVE, podczas gdy strona nadal działa i obsługuje ruch. Stan przykręcenia ustępuje automatycznie po ustąpieniu presji. Zawieszenie jest zarezerwowane dla braku płatności lub potwierdzonego nadużycia, a nawet wtedy strona wyświetla dedykowaną, wyjaśniającą powód stronę zastępczą zamiast uszkodzonej.
Nie dotyczy to żadnych elementów serwowanych z pamięci podręcznej. LSCache obsługuje żądania stron z pamięci podręcznej bez wywoływania PHP lub MySQL, a pamięć podręczna obiektów Redis dla każdej witryny odciąża odczyty dla autentycznie dynamicznych stron. To, co pozostaje, jest ograniczone przez limity procesów LVE i procesów wejściowych Twojej witryny oraz przez ograniczanie przepustowości bazy danych dla każdej witryny za pomocą narzędzia MySQL Governor, dzięki czemu obciążenie bazy danych z jednej witryny nie przeniesie się na serwer. Koszyk, kasa, strona mojego konta i strony sesji domyślnie pozostają w pamięci podręcznej, więc zabezpieczanie nigdy nie przerywa transakcji.
Tak, na warstwie sieciowej. Ochrona przed atakami DDoS na poziomie dostawcy filtruje ataki L3/4 przed naszą siecią niezależnie od protokołu, a w przypadku zaawansowanych wymagań lub planów enterprise rozwiązania Cloudflare Magic Transit oraz Spectrum rozszerzają mitygację klasy brzegowej na ruch inny niż HTTP.
Każda zmiana statusu egzekwowania zasad jest rejestrowana wraz z jej powodem, informacją, czy nastąpiła automatycznie, czy została zainicjowana przez personel, oraz dowodami, na których się opiera. Otrzymujesz powiadomienie o tym, co się zmieniło i co to rozwiązuje, każda akcja podlega odwołaniu, a działania uprzywilejowane są rejestrowane w dzienniku audytu na potrzeby Twojej własnej ścieżki zgodności. Sygnały są agregowane w jednym biurze nadużyć zamiast być rozproszone między różnymi narzędziami.
Tak. Hosting Footprint-Free rozpoczyna się od 14-dniowego okresu próbnego bez konieczności podawania karty, obejmującego do 5 stron – bez danych płatności i bez zobowiązań. Plany są objęte 30-dniową gwarancją zwrotu pieniędzy bez żadnych ale, darmowymi migracjami i brakiem uzależnienia od jednego dostawcy.
Filtrowanie ruchu sieciowego, absorpcja na brzegu sieci, ograniczenia przepustowości serwera i izolacja poszczególnych witryn działają od momentu wdrożenia – niczego nie trzeba konfigurować ani włączać w trakcie incydentu. Rozpocznij 14-dniowy okres próbny bez podawania karty, poparty 30-gwarancją zwrotu pieniędzy i darmowymi migracjami.
Rozpocznij za darmo