Ochrona przed DDoS
Ataki typu flood są neutralizowane na brzegu sieci, ataki na warstwę sieciową filtrowane na wcześniejszym etapie, a wszystko, co dotrze do serwera, zostaje odizolowane wewnątrz klatki na poziomie jądra należącej do danej witryny. Kilka warstw realizujących różne zadania sprawia, że atak wymierzony w jedną witrynę nie skutkuje awarią pozostałych. To model ochrony stworzony przez nas dla platformy obsługującej ponad 700 000 witryn na całym świecie, a jego podstawowa wersja działa w każdym planie. Dostępność: ograniczanie przepustowości bazy danych dla poszczególnych witryn jest w trakcie aktywnego rozwoju i nie jest jeszcze dostępne. Wszystkie pozostałe opisane tu funkcje działają już teraz.
Atak wolumetryczny, atak typu flood na warstwę aplikacji (L7) oraz powolny atak wyczerpujący połączenia to trzy różne problemy. Każdy z nich obsługujemy tam, gdzie jest to najtańsze i najszybsze — przed całą flotą (upstream), na brzegu sieci (edge) oraz wewnątrz klatki.
Ochrona przed atakami DDoS na poziomie dostawcy filtruje przeciążenia warstwy sieciowej przed naszą flotą maszyn roboczych, zanim ruch ten wykorzysta port, kartę sieciową (NIC) lub cykl procesora na maszynie, na której działa Państwa witryna. W przypadku zaawansowanych i korporacyjnych profilów ryzyka rozwiązania Cloudflare Magic Transit oraz Spectrum rozszerzają to samo filtrowanie na ruch inny niż HTTP.
Przed każdą witryną znajduje się zarządzana sieć brzegowa. Pochłania ona wolumetryczne ataki HTTP flood, uruchamia WAF warstwy L7, stosuje limity zapytań dla poszczególnych witryn oraz wykorzystuje zarządzanie botami i zarządzane wyzwania, aby oddzielić prawdziwych użytkowników od ruchu zautomatyzowanego — wszystko to zanim żądanie dotrze do serwera źródłowego.
LiteSpeed Enterprise stosuje dławienie połączeń i żądań z limitami połączeń na adres IP, Imunify360 obsługuje zaporę sieciową z ochroną przed atakami brute-force i filtrowaniem reputacji IP, a limity procesów wejściowych LVE w CloudLinux ograniczają liczbę jednoczesnych żądań, jakie pojedyncza witryna może utrzymywać.
LVE ogranicza procesor, pamięć RAM, operacje wejścia/wyjścia (IO), IOPS, procesy oraz procesy wejściowe indywidualnie dla każdej witryny. Przeciążenie, które przedostanie się przez wyższe warstwy, jest dławione wewnątrz izolowanego środowiska (tzw. klatki) samej witryny docelowej, dzięki czemu wygenerowane obciążenie pozostaje w obrębie tej witryny i nie rozprzestrzenia się na cały serwer.
Większość awarii hostingu podczas ataku nie jest spowodowana dotarciem ataku do celu. Wynikają one z faktu, że zużycie zasobów przez cel pozbawia zasobów wszystko inne na serwerze. Jest to tryb awarii, do którego wyeliminowania zaprojektowano tę architekturę.
Najmniej kosztowne w obsłudze jest żądanie, które w ogóle nie dociera do PHP ani MySQL. Nasza dwuwarstwowa pamięć podręczna sprawia, że znaczna część przeciążenia na poziomie aplikacji jest obsługiwana za pomocą bajtów statycznych, bez obciążania Państwa serwera źródłowego.
Mitygacja to nie zgłoszenie do pomocy technicznej. Sygnały zasilają silnik reguł, który przypisuje każdy z nich do działania egzekucyjnego, powiadomienia klienta oraz — o ile to możliwe — automatycznej naprawy, przy czym każde przejście jest rejestrowane w dzienniku.
Gdy pojawi się sygnał DDoS, silnik reguł stosuje mitygację Cloudflare oraz limity zapytań dla danej witryny, a także może dynamicznie zaostrzyć limity LVE tej witryny. Gdy sygnał ustąpi, limity zostają ponownie złagodzone. Stopniowe, odwracalne i rejestrowane na każdym kroku.
Jeśli atak zagraża serwerowi źródłowemu, witryna przechodzi w stan „dławienia” (throttled) — z zaostrzonymi limitami LVE i ograniczeniem liczby żądań, przy czym witryna nadal działa i obsługuje ruch. Stan dławienia ustępuje automatycznie, gdy obciążenie minie; nie jest to zawieszenie usługi.
Poniżej silnika reguł LVE natywnie i automatycznie ogranicza zużycie procesora, operacji wejścia/wyjścia (IO) oraz procesów dla każdej witryny. Jest to stale aktywna pierwsza linia obrony, działająca niezależnie od tego, czy ruch został już sklasyfikowany jako atak.
Każde przejście egzekwowania rejestruje swoją przyczynę, informację o tym, czy zostało zainicjowane automatycznie, czy przez personel, oraz dowody na jego poparcie. Zostaną Państwo powiadomieni o tym, co uległo zmianie i jak to rozwiązać, a od każdego działania przysługuje odwołanie.
Ochrona podstawowa nie jest opcjonalna, ponieważ zaatakowana lub naruszona witryna zagraża swoim sąsiadom, reputacji naszych serwerów oraz naszym zakresom adresów IP. W przypadku witryn, których profil ryzyka tego wymaga, dostępna jest silniejsza ochrona.
Gwałtowny wzrost ruchu jest często tylko objawem. Ten sam potok sygnałów, który obsługuje zalewy zapytań, wykrywa również naruszenia bezpieczeństwa, które je wywołują, dzięki czemu incydent jest prawidłowo klasyfikowany, a nie tylko pochłaniany.
Celem projektu jest izolacja. Każda witryna działa w ramach własnej klatki CloudLinux LVE z ograniczonymi zasobami CPU, RAM, IO, IOPS, procesami i procesami wejściowymi, własnym widokiem systemu plików CageFS oraz dławieniem bazy danych dla poszczególnych witryn za pośrednictwem MySQL Governor. Zaatakowana witryna jest ograniczana do własnego pułapu, zamiast obciążać całą maszynę, a limity połączeń LiteSpeed na adres IP ograniczają zakres zasobów serwera WWW, jakie może ona zająć. Izolacja została zaprojektowana na poziomie jądra, a nie konfigurowana dla każdego klienta z osobna.
Linia bazowa jest zawarta w każdym planie: izolacja LVE i CageFS, ograniczanie połączeń i żądań w LiteSpeed, zapora sieciowa, proaktywny WAF oraz skanowanie w poszukiwaniu złośliwego oprogramowania, wraz z absorpcją na krawędzi Cloudflare i filtrowaniem sieciowym na poziomie dostawcy przed całą flotą. Dołączamy to, ponieważ nie możemy pozostawić ochrony naszej własnej floty jako opcjonalnej. Zaawansowane zarządzanie botami, wyższe poziomy ochrony przed DDoS, ulepszone reguły WAF oraz dedykowane reguły zapory sieciowej są dodatkami dla witryn, które ich potrzebują.
Bycie celem ataku DDoS oznacza mitygację Cloudflare oraz limitowanie zapytań na poziomie witryny, a także — tylko wtedy, gdy atak zagraża serwerowi źródłowemu — stan „throttled”: bardziej rygorystyczne limity LVE przy zachowaniu ciągłości działania i obsługi witryny. Stan ograniczenia ustępuje automatycznie po ustaniu obciążenia. Zawieszenie jest zarezerwowane dla braku płatności lub potwierdzonych nadużyć, a nawet wtedy witryna wyświetla markową stronę informacyjną z podaniem przyczyny zamiast błędu.
Nie dotyczy to niczego, co jest serwowane z pamięci podręcznej. LSCache obsługuje żądania dotyczące stron z pamięci podręcznej bez wywoływania PHP lub MySQL, a pamięć podręczna obiektów Redis dla poszczególnych witryn odciąża operacje odczytu w przypadku stron prawdziwie dynamicznych. To, co pozostaje, jest ograniczone przez limity procesów LVE i procesów wejściowych Państwa witryny oraz przez dławienie bazy danych dla poszczególnych witryn w MySQL Governor, dzięki czemu obciążenie bazy danych z jednej witryny nie może przenieść się na serwer. Strony koszyka, kasy, mojego konta i sesji domyślnie pozostają niebuforowane, dzięki czemu optymalizacja zabezpieczeń nigdy nie przerywa transakcji.
Tak, na poziomie warstwy sieciowej. Ochrona przed atakami DDoS na poziomie dostawcy odfiltrowuje zalewy L3/4 przed naszą infrastrukturą, niezależnie od protokołu, a w przypadku zaawansowanych lub korporacyjnych wymagań Cloudflare Magic Transit i Spectrum rozszerzają mitygację klasy brzegowej na ruch inny niż HTTP.
Każda zmiana stanu egzekwowania jest rejestrowana wraz z jej przyczyną, informacją, czy została zainicjowana automatycznie, czy przez personel, oraz dowodami. Są Państwo powiadamiani o tym, co uległo zmianie i co rozwiązuje problem, każde działanie podlega odwołaniu, a operacje uprzywilejowane są rejestrowane w dzienniku audytu na potrzeby Państwa własnej ścieżki zgodności. Sygnały są gromadzone w jednym Abuse Desk, zamiast być rozproszone po różnych narzędziach.
Tak. Hosting Footprint-Free rozpoczyna się od 14-dniowego okresu próbnego bez konieczności podawania danych karty, obejmującego do 5 stron — bez danych płatniczych, bez zobowiązań. Plany są objęte 30-dniową bezwarunkową gwarancją zwrotu pieniędzy, darmowymi migracjami i brakiem uzależnienia od dostawcy.
Filtrowanie sieciowe, absorpcja na krawędzi sieci, dławienie serwerów i izolacja poszczególnych witryn działają od momentu wdrożenia — bez konieczności jakiejkolwiek konfiguracji i bez włączania czegokolwiek w trakcie incydentu. Zacznij od 14-dniowego okresu próbnego bez konieczności podawania karty, objętego 30-dniową gwarancją zwrotu pieniędzy oraz bezpłatnymi migracjami.
Rozpocznij za darmo