Alternatywy dla Fail2Ban na nowoczesnych serwerach z systemem Linux

Przed wyborem narzędzia należy sprawdzić powierzchnię ataku

A Alternatywa dla Fail2Ban można go sensownie wybrać dopiero wtedy, gdy znane są usługi, do których faktycznie można uzyskać dostęp. SSH, SMTP, IMAP i aplikacja HTTP mają różne procedury logowania, źródła logów i charakterystykę szkód. Z kolei publicznie dostępna usługa bazodanowa z reguły nie powinna wymagać ochrony za pomocą listy blokowanych adresów internetowych: jej dostęp sieciowy powinien być ograniczony do niezbędnych aplikacji i zaufanych sieci.

W przypadku przyjęć administracyjnych Ograniczenie dostępu a silne uwierzytelnianie ma pierwszeństwo przed automatycznymi blokadami adresów IP. Usługa SSH za VPN, hostem bastionowym lub stałymi sieciami administracyjnymi oferuje atakującym znacznie mniejszą powierzchnię ataku niż port otwarty na całym świecie. Aktualne aktualizacje zabezpieczeń, oddzielne konta z uprawnieniami oraz starannie dobrane hasła logowania zmniejszają ryzyko, którego sama lista blokowanych adresów nie jest w stanie wyeliminować.

Jeśli dostęp do SSH jest celowo udostępniony publicznie, limity i blokady oparte na logach mogą ograniczyć liczbę powtarzających się prób wprowadzenia hasła. Stanowią one jednak jedynie środek uzupełniający: osoby znajdujące się za wspólną bramą NAT mogą korzystać z tego samego adresu źródłowego, podczas gdy ataki rozproszone wykorzystują wiele adresów. W przypadku usług pocztowych dodatkowe znaczenie ma to, które protokoły są faktycznie dostępne dla użytkowników zewnętrznych oraz które nieudane próby logowania są rejestrowane.

W przypadku aplikacji internetowych należy rozróżnić dostępność serwera proxy odwrotnego od dostępności wewnętrznych usług zaplecza. Publiczny serwer Nginx może przyjmować żądania HTTP bez konieczności udostępniania z Internetu bazy danych, pamięci podręcznej czy interfejsu administracyjnego. To Cel ochronny Nie chodzi więc o ogólne „blokowanie adresów IP“, lecz o ograniczanie nieuprawnionego dostępu w poszczególnych usługach, zapewnienie legalnego korzystania z nich oraz unikanie niepotrzebnego udostępniania.

Przed każdą zmianą osoby odpowiedzialne powinny ustalić, jakie ścieżki dostępu są potrzebne w sytuacji awaryjnej oraz które sieci źródłowe mają regularny dostęp. Taka analiza zapobiega sytuacji, w której zbyt restrykcyjna reguła zapory sieciowej zablokuje dostęp administratora lub zautomatyzowaną konserwację. Dopiero wtedy można zdecydować, czy odpowiednia będzie analiza logów, ograniczenie połączeń czy też koncepcja wielopoziomowa.

Blokada nie odpowiada zresztą na pytanie, czy dana usługa w ogóle musi być publiczna. Odwracając tę kolejność, zajmujemy się podejrzanymi połączeniami, mimo że podstawowa ekspozycja pozostaje niezmieniona. Szczególnie w przypadku rzadko używanych interfejsów administracyjnych prywatna ścieżka dostępu jest często skuteczniejsza i łatwiejsza w obsłudze niż coraz bardziej złożone reguły rozpoznawania.

Cztery podejścia zamiast alternatywy dla Fail2Ban

Zamiast szukać jednego rozwiązania zastępczego, warto rozdzielić procesy wykrywania i reagowania. CrowdSec przetwarza konfigurowalne źródła logów za pomocą parserów i scenariuszy w celu oceny sekwencji zdarzeń i generowania decyzji. Silnik bezpieczeństwa nie wdraża tych decyzji samodzielnie; w tym celu konieczne jest podłączenie i uruchomienie oddzielnego komponentu naprawczego.

Taki podział sprawdza się, gdy ta sama funkcja rozpoznawania ma działać w różnych miejscach. Komponent zapory sieciowej może stosować reguły dotyczące połączeń sieciowych, podczas gdy komponenty serwerów WWW lub serwerów proxy odwrotnych zajmują się ruchem HTTP. Wiąże się to jednak również z większymi wymaganiami: pozyskiwanie logów, parsery, lokalne API, uprawnienia oraz konkretne egzekwowanie muszą być zaplanowane jako spójny łańcuch.

SSHGuard jest przeznaczony do bardziej konkretnych przypadków. Narzędzie to agreguje logi systemowe i może blokować źródła, które wielokrotnie wzbudzają podejrzenia, za pośrednictwem zapór sieciowych; jego przeznaczeniem jest ochrona przed atakami typu brute force na SSH i inne usługi. Dlatego też nadaje się ono raczej do wykrywania konkretnych błędów uwierzytelniania niż do kompleksowej analizy zapytań internetowych.

Natywne Ograniczanie przepustowości w nftables stosuje inne podejście. Dynamiczne zestawy i liczniki mogą ograniczać liczbę nowych połączeń TCP na adres źródłowy oraz zarządzać wpisami, których czas wygasł. Hamuje to szybkie serie połączeń przed uwierzytelnieniem, nie wymaga analizatora logów, a jednocześnie nie ocenia, czy logowanie zakończyło się niepowodzeniem, czy też żądanie HTTP miało złośliwy charakter.

Ważny jest tutaj kierunek reguły: nftables rozróżnia reguły, które akceptują ruch do określonej szybkości, od wyrażeń z over, które odrzucają ruch przekraczający określony próg. Limit musi zatem być dostosowany do usługi, przewidywanego zachowania użytkowników oraz wspólnie wykorzystywanych adresów źródłowych. Nie jest to wiarygodna klasyfikacja każdej podejrzanej tożsamości.

W przypadku pojedynczego serwera z niewielką liczbą jasno określonych usług wystarczająca może być uproszczona ochrona logów lub umiarkowane ograniczenie liczby połączeń. W przypadku wielu hostów, scentralizowanych źródeł logów lub konieczności stosowania różnych punktów egzekwowania zaleca się raczej architekturę modułową. Żadna z tych opcji nie zastępuje poprawek, silnego logowania ani restrykcyjnych uprawnień sieciowych.

Wybór odpowiedniej alternatywy dla Fail2Ban zależy zatem od tego, jakie sygnały są dostępne i gdzie powinna nastąpić reakcja. Wzorce logów są przydatne w przypadku powtarzających się błędów logowania; reguły pakietowe ograniczają częstotliwość połączeń. Obie metody wykrywają jedynie to, do czego zostały zaprojektowane ich źródła danych i reguły.

Wyraźne rozdzielenie zapory sieciowej i ochrony protokołu HTTP

Serwer Nginx lub odwrotny serwer proxy łączy dwa poziomy ochrony, których nie należy mylić. Blokada zapory sieciowej odrzuca lub zezwala na połączenia z określonego adresu źródłowego i może tym samym dotyczyć jednocześnie protokołów SSH, SMTP lub dostępu do sieci WWW. Nie ocenia ona jednak poszczególnych ścieżek HTTP, nagłówków ani treści żądań; informacje te znajdują się na poziomie aplikacji.

W CrowdSec są Wykrywanie i egzekwowanie odrębne zadania. Procesor logów analizuje dane logów oraz żądania HTTP z kompatybilnych serwerów WWW. AppSec stanowi część tego procesora logów i filtruje takie żądania HTTP. Z kolei komponenty naprawcze są odpowiedzialne za wdrażanie decyzji na wybranym poziomie, na przykład na zaporze sieciowej, serwerze WWW lub serwerze proxy odwrotnym.

W celu zapewnienia ochrony przed atakami typu SQL injection, cross-site scripting lub innymi szkodliwymi treściami w żądaniach sam komponent zapory sieciowej nie wystarczy. Konieczne jest kompatybilne połączenie z serwerem WWW oraz odpowiednia konfiguracja zabezpieczeń aplikacji (AppSec) z odpowiednimi regułami. Działania naprawcze należy oddzielić od tego pod względem technicznym: realizują one decyzje w wybranym punkcie egzekwowania.

Oba poziomy mogą być przydatne równolegle. Blokada obejmująca całą sieć ogranicza dalszy ruch wychodzący z danego źródła, podczas gdy Sprawdzanie HTTP ocenia i filtruje serwery WWW zgodne z żądaniami AppSec. Nie oznacza to jednak, że blokada adresu IP automatycznie chroni przed atakami typu SQL injection lub cross-site scripting: bez sprawdzania żądań zapora sieciowa nie rozpoznaje ani parametrów, ani danych użytkowych.

Z drugiej strony, środki oparte na zabezpieczeniach aplikacji (AppSec) i adresach IP również mają swoje ograniczenia. Powolne próby poniżej progów, duża liczba zmieniających się adresów źródłowych lub legalni użytkownicy korzystający z tego samego adresu NAT utrudniają podejmowanie decyzji na podstawie źródłowego adresu IP. Reguły powinny zatem uwzględniać fałszywe alarmy i nie traktować dostępu do standardowych formularzy, interfejsów API oraz zautomatyzowanych integracji jako ataku w sposób ogólny.

W celu ułatwienia planowania warto przedstawić krótkie uogólnienie: Poziom zapory sieciowej kieruje ruchem sieciowym na podstawie adresów, portów i cech połączeń. AppSec przetwarza i filtruje żądania HTTP z kompatybilnych serwerów WWW w ramach modułu Log Processor. Komponenty naprawcze celowo wdrażają decyzje na wybranym poziomie.

Ponadto publiczny system internetowy wymaga wyraźnego rozdzielenia kompetencji. Serwer proxy odwrotny może łączyć się wyłącznie z niezbędnymi serwerami zaplecza, a punkty końcowe służące do zarządzania nie powinny pozostawać publicznie dostępne wyłącznie z powodu obecności filtra umieszczonego przed nimi. W ten sposób segmentacja sieci, bezpieczne logowanie i ukierunkowane reguły wzajemnie się uzupełniają, nie przypisując żadnej pojedynczej technice blokującej większego efektu ochronnego, niż jest ona w stanie zapewnić.

Porównanie typowych serwerów z systemem Linux

Nie da się sensownie wybrać alternatywy dla Fail2Ban wyłącznie na podstawie liczby możliwych blokad. Decydujące znaczenie mają sygnały, które są analizowane, oraz miejsce, w którym są one egzekwowane. CrowdSec oddziela swój silnik zabezpieczeń od komponentu, który wdraża decyzje w zaporze sieciowej, serwerze proxy lub serwerze WWW. Natomiast SSHGuard analizuje logi systemowe pod kątem powtarzających się prób ataków; nftables może ograniczać nowe połączenia bezpośrednio w ścieżce pakietów.

Tabela nie przedstawia rankingu. W przypadku pojedynczej usługi, w której występują wyraźne nieudane próby logowania, uproszczona analiza logów to coś innego niż ograniczenie liczby połączeń w przypadku ataków typu „flood”. W przypadku serwera proxy odwrotnego dodatkowym czynnikiem jest to, czy żądania HTTP mają być filtrowane przez AppSec na kompatybilnym połączeniu. To punkt egzekucji musi być dostosowana do obiektu chronionego: reguła zapory sieciowej nie ocenia treści żądania, podczas gdy komponenty naprawcze wdrażają decyzje na odpowiednim, wybranym poziomie.

Również centralne zarządzanie nie jest celem samym w sobie. Pozwala ono ujednolicić procesy podejmowania decyzji i analizę logów na wielu hostach, wymaga jednak solidnej koncepcji zarządzania dostępem i planu awaryjnego. W przypadku małego, odizolowanego serwera taka dodatkowa architektura może w niektórych okolicznościach generować więcej nakładu pracy związanego z konserwacją niż przynosi korzyści w zakresie bezpieczeństwa. Z drugiej strony identyczne usługi działające na wielu hostach mogą odnieść korzyści z celowo zaplanowanej, scentralizowanej instalacji CrowdSec.

Dokładne sprawdzenie i klasyfikacja konfiguracji

Przed aktywacją należy najpierw ustalić, jakie komunikaty faktycznie docierają do usługi. W przypadku rozwiązania opartego na logach sprawdź źródło logów, parser oraz konkretny format zdarzeń SSH, pocztowych lub proxy. W przypadku CrowdSec samo wykrycie aktywności nie wystarczy: zarejestrowany i dostępny komponent naprawczy musi przekazywać decyzje do przeznaczonego do tego celu połączenia z zaporą sieciową lub serwerem proxy.

Poniższe polecenia służą wyłącznie do sprawdzania stanu systemu Linux, na którym odpowiednie narzędzia mogą już być zainstalowane. Nie zmieniają one żadnych reguł ani nie instalują żadnych pakietów. Pomagają one sprawdzić aktualny zestaw reguł, zarejestrowane komponenty CrowdSec oraz pakiety kandydackie dostępne dla systemów Debian lub Ubuntu.

nft list ruleset
sudo cscli bouncers list
apt-cache policy crowdsec

Z wyświetlonego wyniku nie wynika jeszcze żadna ochrona. Sprawdź w nftables, czy odpowiedni łańcuch wejściowy (input chain) zawiera oczekiwany hook oraz odpowiednią domyślną politykę, a także czy przewidziano reguły dla istniejących połączeń, pętli zwrotnej (loopback), adresów IPv4 i IPv6 oraz rzeczywistego portu usługi. Zarejestrowany komponent może być ponadto skonfigurowany dla niewłaściwego punktu egzekwowania. Nawet widoczny pakiet kandydujący nie daje pewności, czy jego wersja, konfiguracja i parser są zgodne z dystrybucją oraz z daną usługą.

Wartości progowe, okresy blokady i wyjątki nie powinny być bez weryfikacji przenoszone z przykładów do środowiska produkcyjnego. W przeciwnym razie zwłaszcza wspólne adresy NAT, połączenia mobilne i zautomatyzowane zadania mogą powodować fałszywe alarmy. Do analizy zdarzeń sieciowych i zachowania systemu można dodatkowo Śledzenie eBPF do monitorowania systemu Linux pomaga; nie zastępuje jednak ani sprawdzenia łańcucha logów, ani merytorycznej decyzji o zablokowaniu.

Odpowiedni wybór dla czterech scenariuszy eksploatacyjnych

Pojedynczy serwer VPS z dostępem SSH na całym świecie ma ściśle określone wymagania w zakresie ochrony. SSHGuard może zgłaszać do zaplecza zapory sieciowej powtarzające się nieudane próby połączenia, które są rozpoznawalne w odpowiednich logach. Umiarkowany limit w nftables może dodatkowo ograniczyć liczbę nowych połączeń, ale nie uwzględnia błędów logowania. Priorytetem są ograniczone ścieżki administracyjne i silne uwierzytelnianie; blokada adresów IP pozostaje jedynie uzupełnieniem.

W przypadku serwera pocztowego protokoły SMTP, IMAP i Submission wykorzystują różne ścieżki uwierzytelniania i rejestrowania. Proste reagowanie oparte na logach ma sens tylko wtedy, gdy wszystkie istotne komunikaty są w pełni rejestrowane. CrowdSec staje się opcją, gdy konieczne jest scalenie procesów decyzyjnych lub analizy logów z wielu systemów. Bez takiej potrzeby architektura scentralizowana byłaby nieproporcjonalna w porównaniu z jasno wyodrębnionym rozwiązaniem lokalnym.

W przypadku Nginx lub Traefik, umieszczonych przed aplikacją internetową, narzędzie przeznaczone wyłącznie do obsługi SSH nie wystarczy. W tym przypadku rozróżnienie polega na wielopoziomowe zabezpieczenie Dostęp do sieci w ramach kontroli HTTP: CrowdSec AppSec stanowi część modułu Log Processor i może filtrować żądania pochodzące z kompatybilnych serwerów WWW. Natomiast komponenty naprawcze wdrażają podjęte decyzje na wybranym poziomie, na przykład na serwerze WWW lub serwerze proxy odwrotnym. Oba zadania muszą być odpowiednio zintegrowane i sprawdzane oddzielnie.

Mała flota korzystająca z centralnych dzienników lub Kubernetes może czerpać korzyści z centralnego lokalnego interfejsu API lub scentralizowanych dzienników. Nie oznacza to jednak automatycznego uproszczenia eksploatacji: należy zaplanować uprawnienia, dostępność interfejsów, segmentację oraz awarię komponentu centralnego. Aspekty przetwarzania pakietów i rozkładu obciążenia w większych sieciach Linuxowych omówiono również w artykule poświęconym Skalowanie po stronie odbiorczej w sieciach serwerów z systemem Linux. W przypadku niewielkiej liczby hostów, które nie korzystają ze wspólnego procesu operacyjnego, rozwiązanie lokalne jest często bardziej przejrzyste.

Monitorowanie logiki blokującej podczas pracy

Logika blokowania jest zrozumiała tylko wtedy, gdy kontrolujesz osobno trzy etapy: pobieranie danych z logów, decyzję wynikającą z tych danych oraz jej techniczną realizację. W przypadku CrowdSec silnik bezpieczeństwa odczytuje skonfigurowane źródła logów i generuje decyzje na podstawie parserów i scenariuszy; jednak za samą blokadę odpowiada oddzielny komponent naprawczy.

Najpierw sprawdź, czy oczekiwane komunikaty w ogóle docierają. W przypadku usługi SSH istotne są nieudane próby logowania, w przypadku serwera pocztowego – odpowiednie protokoły uwierzytelniania, a w przypadku serwera proxy – jego logi dostępu lub logi bezpieczeństwa. Same widoczne zdarzenia nie świadczą jeszcze o skuteczności zabezpieczeń: dopiero łańcuch obejmujący wpis w dzienniku, rozpoznaną sekwencję, decyzję i skuteczną regułę pozwala na postawienie wiarygodnej diagnozy.

Następnie należy osobno sprawdzić decyzje i zarejestrowany komponent. Jeśli CrowdSec wykryje podejrzane zdarzenia, ale żaden komponent naprawczy nie jest podłączony lub nie działa, decyzje te nie będą miały żadnych skutków. Oficjalna dokumentacja błędów wskazuje właśnie ten schemat jako przyczynę sytuacji, w której silnik bezpieczeństwa działa, ale nie dochodzi do blokady. Wykrycie nie oznacza blokady.

W przypadku ochrony sieciowej dochodzi jeszcze jedna kontrola. AppSec stanowi część procesora logów i filtruje żądania HTTP z kompatybilnych serwerów WWW. Komponenty naprawcze wdrażają decyzje na wybranym poziomie, na przykład na serwerze WWW lub serwerze proxy odwrotnym. W trakcie działania należy zatem zachować możliwość rozróżnienia, czy odrzucenie wynika z kontroli HTTP, czy też z decyzji już wdrożonej, aby umożliwić ukierunkowaną analizę błędów i fałszywych alarmów.

Fałszywe alarmy mają szczególnie poważne konsekwencje, gdy wiele uprawnionych osób korzysta z tego samego adresu publicznego. Bramki NAT, sieci komórkowe i systemy CI mogą agregować liczne uzasadnione próby logowania pod jednym adresem IP źródłowym. Dlatego należy dobierać progi, czasy blokady i wyjątki w oparciu o rzeczywiste ścieżki dostępu oraz zapewnić przejrzystość decyzji wraz z uzasadnieniem i czasem trwania, zamiast traktować długą listę zablokowanych użytkowników jako sukces.

Zmiany należy najpierw przetestować na zanonimizowanych historycznych logach lub w środowisku testowym. Pozwala to sprawdzić, czy parsery rozpoznają przewidziane wzorce oraz czy mechanizm naprawczy reaguje zgodnie z oczekiwaniami, nie narażając przy tym uprawnień administracyjnych. SSHGuard przetwarza logi systemowe i może komunikować się z różnymi modułami zapory sieciowej; dlatego też źródło logów i moduł zapory należy rozpatrywać łącznie w zainstalowanym środowisku.

Kontrolowany przebieg testu nie zastępuje testu ataku na systemie produkcyjnym. Należy dokumentować przewidywane zdarzenia, zaobserwowane decyzje oraz wynikające z nich skutki działania reguł; następnie należy usunąć dane testowe lub pozwolić, aby wpisy o ograniczonym czasie ważności wygasły w sposób naturalny. Dzięki temu można zweryfikować skuteczność zabezpieczeń i ewentualne szkody uboczne bez celowego wywoływania rzeczywistych blokad dla użytkowników produkcyjnych.

Wykrywanie błędów w logach i regułach

Zawsze rozpoczynaj diagnostykę od źródła logów, a następnie przechodź dalej w kierunku wdrożenia. Jeśli brakuje odpowiednich komunikatów, ani parser logów, ani logika scenariuszy, ani logika blokowania nie będą w stanie reagować w sposób niezawodny. Dlatego przed zmianą wartości progowych lub podejrzewaniem reguł zapory sieciowej sprawdź usługę, moduł odczytu logów oraz rzeczywisty format.

W przypadku CrowdSec sytuacja jest jednoznaczna, gdy zdarzenia lub decyzje są widoczne, ale dostęp pozostaje nadal możliwy: silnik nie egzekwuje decyzji automatycznie. Należy sprawdzić, czy odpowiedni komponent naprawczy jest zarejestrowany, dostępny i faktycznie podłączony do zapory sieciowej, serwera WWW lub serwera proxy. Bez tego komponentu żadna reguła blokowania nie zostanie zastosowana.

W przypadku SSHGuard przyczyna często leży właśnie w tym. Narzędzie to agreguje logi systemowe, jednak nieodpowiedni moduł odczytu logów lub format usługi odbiegający od oczekiwanego wzorca nie zapewniają użytecznych wyników. Przykładowa konfiguracja w repozytorium przedstawia możliwe dane wejściowe i opcje, pochodzi jednak z gałęzi rozwojowej; należy ją porównać z dokumentacją pakietu i zainstalowaną wersją, zamiast przejmować ją bez zmian.

W przypadku nftables sprawdzasz dodatkowo, czy reguła w odpowiednim łańcuchu znajduje się w oczekiwanym haku, obejmuje rzeczywisty port usługi i dotyczy wymaganych rodzin protokołów. Przykładowy zestaw reguł rozdziela IPv4 i IPv6 za pomocą oddzielnych łańcuchów, zezwalając na nawiązane i powiązane połączenia oraz ruch pętli zwrotnej przed zezwoleniem na porty. Ochrona sformułowana wyłącznie dla IPv4 nie obejmuje IPv6; podobnie zbyt wąskie ograniczenie częstotliwości może wpłynąć na uprawnione połączenia równoległe.

Ein Meter ogranicza nowe połączenia na podstawie zdefiniowanej szybkości dla każdego źródła i może zarządzać dynamicznymi wpisami w zestawach z limitem czasu. Nie uwzględnia to jednak nieudanych prób logowania. Jeśli atak nie przekracza tej częstotliwości, brak trafienia niekoniecznie oznacza wadę reguły, ale może wynikać z ograniczeń wybranego podejścia. Haczyk, łańcuch i punkt pomiarowy muszą być zgodne z oczekiwanym efektem.

Wprowadzaj zmiany pojedynczo i po każdym kroku ponownie sprawdzaj wpis w dzienniku, decyzję oraz jej wdrożenie. Przed wprowadzeniem zmian w zaporze sieciowej zapewnij niezależny dostęp awaryjny, na przykład poprzez konsolę, serwer bastionowy lub oddzielną sieć administracyjną. Zapobiegnie to sytuacji, w której nieprawidłowo umieszczona reguła lub błędny wpis IPv6 odetnie jedyny dostęp do serwera.

Decyzja w zależności od ryzyka i nakładu pracy

Odpowiednią alternatywę dla Fail2Ban należy wybrać na podstawie dostępnej powierzchni ataku, a nie na podstawie ogólnego rankingu. Należy ustalić, które usługi są publicznie dostępne, czy obsługują logowanie, które logi są niezawodnie dostępne oraz kto na stałe zarządza konfiguracją. Usługa bazodanowa bez publicznego dostępu nie wymaga internetowej listy blokowanych adresów; jej udostępnienie w sieci pozostaje ważniejszą decyzją dotyczącą bezpieczeństwa.

W przypadku niewielkiego, pojedynczego serwera, na którym powtarzają się błędy logowania przez SSH lub pocztę, SSHGuard może stanowić proste rozwiązanie oparte na logach. Projekt ten ma na celu ochronę przed atakami typu brute force na SSH i inne usługi, wykorzystując w tym celu logi systemowe oraz zaplecze zapory sieciowej. Konkretny zakres logów oraz parametry blokowania muszą jednak być dostosowane do zainstalowanej dystrybucji i formatu usługi.

Jeśli chodzi przede wszystkim o ograniczanie nowych, szybkich połączeń, umiarkowane ograniczenie szybkości w nftables stanowi bezpośrednie uzupełnienie. Liczniki mogą ograniczać liczbę połączeń na adres źródłowy; reguły z over Odrzuca ruch przekraczający ustaloną wartość. Dzieje się to przed zalogowaniem, ale nie dostarcza żadnych informacji semantycznych na temat tego, czy logowanie nie powiodło się, czy też żądanie HTTP miało złośliwy charakter.

CrowdSec sprawdza się w sytuacjach, gdy konieczna jest koordynacja analizy logów i egzekwowania zasad na wielu poziomach lub na wielu hostach. Jego architektura oddziela silnik od komponentów naprawczych; możliwe są warianty rozproszone z centralnym interfejsem API lub scentralizowanymi logami. Ta zaleta wiąże się z dodatkowymi wymaganiami dotyczącymi uprawnień, dostępności, segmentacji oraz planu na wypadek awarii. Sprawność operacyjna jest zatem jednym z kryteriów wyboru, obok zakresu funkcji.

W przypadku publicznych aplikacji internetowych blokada zapory sieciowej nie wystarcza do oceny poszczególnych żądań HTTP. W tym celu potrzebne jest kompatybilne połączenie z AppSec z odpowiednimi regułami. AppSec stanowi część procesora logów i filtruje żądania HTTP pochodzące z kompatybilnych serwerów internetowych; komponenty naprawcze wdrażają decyzje w wybranym punkcie egzekwowania. Kluczowe znaczenie ma to, czy ochrona dotyczy połączeń, zdarzeń uwierzytelniania czy treści HTTP.

Środki oparte na adresach IP mają ograniczoną skuteczność: botnety rozpraszają próby ataku na wiele źródeł, powolne ataki mogą nie przekraczać ustalonego progu, a w przypadku blokady adresy współużytkowane mogą dotknąć osób postronnych. Środki te ograniczają zautomatyzowany ruch zakłócający, ale nie zastępują terminowego instalowania poprawek, ograniczonego dostępu administracyjnego ani silnego uwierzytelniania. Szczególnie w przypadku protokołu SSH logowanie oparte na kluczach i ograniczona dostępność mają pierwszeństwo przed coraz bardziej agresywnymi progami blokowania.