Zabezpieczanie serwerów Linux: iptables vs fail2ban

Chciałbym wybrać mózg społeczności w kwestii bezpieczeństwa serwera linux, szczególnie w odniesieniu do ataków brute-force i używania fail2ban w porównaniu do niestandardowych iptables .

Istnieje kilka podobnych pytań, ale żadne z nich nie odnosi się do tematu w sposób zadowalający. Krótko mówiąc, staram się znaleźć najlepsze rozwiązanie w celu zabezpieczenia serwerów linuxowych narażonych na działanie Internetu (uruchamiających zwykłe usługi, ssh, web, mail) przed atakami siłowymi.

Mam przyzwoite podejście do bezpieczeństwa serwera, tj. Blokowania ssh poprzez niedozwolone logowanie się do konta root lub hasła, zmianę domyślnego portu, upewnianie się, że oprogramowanie jest aktualne, sprawdzanie plików dziennika, zezwalanie tylko niektórym hostom na dostęp do serwera i korzystanie z bezpieczeństwa narzędzia do audytu, takie jak Lynis ( https://cisofy.com/lynis/ ), w celu zapewnienia ogólnej zgodności z bezpieczeństwem, więc to pytanie niekoniecznie dotyczy tego, chociaż wkład i porady są zawsze mile widziane .

Moje pytanie brzmi, które rozwiązanie powinienem zastosować (fail2ban lub iptables) i jak mam je skonfigurować, czy też powinienem użyć obu kombinacji, aby zabezpieczyć się przed atakami siłowymi?

Jest ciekawa odpowiedź na ten temat ( Denyhosts vs fail2ban vs iptables - najlepszy sposób, aby zapobiec logowaniu przy użyciu siły brute? ). Najciekawsza odpowiedź dla mnie osobiście brzmiała ( https://serverfault.com/a/128964 ) i że routing iptables występuje w jądrze w przeciwieństwie do fail2ban, który wykorzystuje narzędzia trybu użytkownika do analizowania plików dziennika. Fail2ban używa oczywiście iptables, ale nadal musi analizować pliki dziennika i dopasowywać wzorzec, dopóki nie wykona akcji.

Czy to ma sens, aby używać iptables i ograniczania szybkości ( https://www.rackaid.com/blog/how-to-block-ssh-brute-force-attacks/ ), aby usunąć żądania z adresu IP na pewien okres czasu, który powoduje zbyt wiele prób połączenia w określonym czasie, niezależnie od protokołu, z którym próbował się połączyć? Jeśli tak, to jest kilka interesujących przemyśleń na temat używania drop vs odrzucania dla tych pakietów tutaj ( http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject ), jakieś przemyślenia na ten temat?

Fail2ban pozwala na niestandardową konfigurację w postaci możliwości napisania niestandardowych „ reguł ” dla usług, które mogą nie zostać rozwiązane w konfiguracji domyślnej. Jest łatwy w instalacji i konfiguracji i jest mocny, ale to może być przesadą, jeśli wszystko staram się osiągnąć to „ bloku ” IP z serwera, jeżeli dokonają 2 nieudanych prób dostępu na dowolnym / protokołu serwisowego nad x ilość czasu?

Celem jest tutaj otwieranie codziennych raportów dziennika i nie trzeba przewijać stron o nieudanych połączeniach z serwerem.

Dzięki za poświęcenie czasu.

powinienem używać fail2ban lub iptables?

Jako dodatek do zapory ogniowej używasz fail2ban , aby rozszerzyć istniejące reguły zapory na żądanie o reguły blokujące określone adresy IP systemów, które wykonują niepożądane działania w innych usługach publicznych. Współpracują ze sobą.

Uproszczone: zapora sieciowa widzi tylko połączenia sieciowe i pakiety i może rozumieć zawarte w nich wzorce, ale nie ma wglądu na poziomie aplikacji, aby odróżnić żądane i prawidłowe żądania od złośliwych, zniekształconych i niepożądanych żądań. Na przykład twoja zapora ogniowa nie może odróżnić kilku żądań interfejsu API HTTP od wielu niepoprawnych prób logowania spowodowanych zgadywaniem hasła metodą brute force na stronie administratora Wordpress. Obie zapory są tylko połączeniami TCP z portem 80 lub 443.

Fail2ban to ogólne i rozszerzalne podejście zapewniające wgląd w poziom zapory ogniowej na poziomie aplikacji, choć w pewnym stopniu pośrednio.
Często aplikacje rejestrują i rejestrują złośliwe, zniekształcone i niepożądane żądania jako takie, ale rzadko mają natywną zdolność zapobiegania dalszemu nadużyciom. Mimo że jest on nieco oddzielony, Fail2ban może następnie reagować na te zarejestrowane złośliwe zdarzenia i ograniczyć szkody oraz zapobiec dalszemu nadużyciom, zazwyczaj poprzez dynamiczną rekonfigurację zapory ogniowej w celu odmowy dalszego dostępu. Innymi słowy, Fail2ban zapewnia istniejącym aplikacjom, bez ich modyfikowania, środki do zwalczania nadużyć.

Inną metodą zapewnienia zaporom wglądu na poziomie aplikacji byłby system wykrywania / zapobiegania włamaniom .

Na przykład serwer WWW jest powszechną usługą publiczną, a w zaporze sieciowej porty TCP 80 i 443 są otwarte dla całego Internetu.
Zazwyczaj nie masz żadnych ograniczeń prędkości na portach HTTP / HTTPS, ponieważ wielu prawidłowych użytkowników może mieć jedno źródło, gdy są na przykład za bramą NAT lub proxy sieci.

Kiedy wykryjesz niepożądane i / lub złośliwe działania w stosunku do twojego serwera, używasz fail2ban do automatyzacji blokowania takiego przestępcy (albo całkowicie go zablokuj, albo tylko przez zablokowanie dostępu do portów 80 i 443).

Z drugiej strony dostęp SSH nie jest usługą publiczną, ale jeśli nie jesteś w stanie ograniczyć dostępu SSH w swojej zaporze ogniowej tylko do zakresów adresów IP z białej listy, ograniczające szybkość połączenia przychodzące są jednym ze sposobów spowolnienia brutalnego wymusza ataki. Ale twoja zapora ogniowa nadal nie potrafi rozróżnić między bobem użytkownika, który zalogował się 5 razy, ponieważ uruchomił odpowiadające podręczniki, a 5 nieudanymi próbami zalogowania się jako root przez bota.

powinienem używać fail2ban lub iptables?

Jest to trochę podobne do pytania „czy powinienem użyć pasa bezpieczeństwa czy samochodu?”.

Po pierwsze, pamiętaj, że fail2ban to tak naprawdę narzędzie do automatycznego wykrywania powtarzających się wpisów w plikach tekstowych i wykonywania niektórych poleceń, gdy osiągną określony próg.

Często używamy go do blokowania hostów, które naruszają niektóre zasady, o czym świadczą powtarzające się wpisy dziennika wskazujące na naruszenie zasad, ale nie jest to jedyna rzecz, do której możesz tego użyć.

Państwo może używać fail2ban dodać (i usuwać) iptables reguły na żądanie. Możesz także dodawać i usuwać reguły iptables ręcznie lub użyć fail2ban, aby zrobić coś zupełnie innego w odpowiedzi. To wszystko o tym, jak to skonfigurować.

Powinieneś mieć ogólne zapory ogniowe niezależnie od tego, czy korzystasz z fail2ban, czy nie. Takie zapory ogniowe mogłyby na przykład blokować (przychodzący lub wychodzący) ruch, o którym wiesz, że nigdy nie będzie uzasadniony. Na przykład, czy ten serwer bazy danych naprawdę musi obsługiwać połączenia przychodzące na porcie 25 z całego Internetu?

Co więcej, posiadanie przez fail2ban odpowiedzi na naruszenia zasad poprzez odcięcie na chwilę obrażających adresów IP nie zrobi wiele, aby zabezpieczyć serwer sam w sobie (dobry exploit musi tylko raz przejść przez zaporę ogniową), ale będzie obniżyć poziom hałasu w systemie, w tym między innymi w dziennikach systemu. Najprostszym sposobem na to jest uruchomienie iptables w trybie fail2ban w celu skonfigurowania jądra, aby na jakiś czas upuszczało pakiety. Jeśli możesz zmienić konfigurację zapory obwodowej zamiast zapory hosta, to tylko tym lepiej.

Innymi słowy, w zakresie, w jakim można je łatwo oddzielić od siebie, potrzebujesz obu.

czy może to być przesada, jeśli wszystko, co próbuję osiągnąć, to „zablokować” adres IP z serwera, jeśli wykonają 2 nieudane próby dostępu do dowolnej usługi / protokołu w określonym czasie?

To jest dokładnie przypadek użycia fail2ban przeznaczony do rozwiązania. Używanie narzędzia zgodnie z jego przeznaczeniem prawie nigdy nie jest przesadą.

Celem jest tutaj otwieranie codziennych raportów dziennika i nie trzeba przewijać stron o nieudanych połączeniach z serwerem.

Na bok, niezwiązany bezpośrednio z pytaniem: za każdym razem, gdy filtrujesz dzienniki w celu przejrzenia, zastanów się, co zrobisz z konkretnym wpisem. Jeśli wszystko, co zamierzasz zrobić z wpisem, to powiedzieć „meh” i przejść dalej, prawdopodobnie prawdopodobnie chcesz go odfiltrować. Pamiętaj, aby zapisać pełne dzienniki do przeglądu, jeśli zajdzie taka potrzeba, ale wrzucaj do zwykłego przepływu pracy monitorowania rzeczy, z którymi faktycznie zamierzasz coś zrobić, gdy się pojawi. Jeśli skonfigurujesz fail2ban do blokowania hosta po kilku nieudanych próbach połączenia, są całkiem spore szanse, że nie będziesz musiał sprawdzać ich ręcznie i możesz usunąć je z powiadomień monitorowania. Jeśli legalny użytkownik skarży się na utratę dostępu, po prostu wyciągnij pełne logi i spójrz.

Kilka lat temu rozwiązałem to samo pytanie. Postanowiłem użyć iptables z najnowszym modułem ze względu na wydajność i łatwą konfigurację. Musiałem chronić wiele wirtualnych kontenerów na hostach. Pamiętaj tylko, aby nie otwierać żadnego wektora DOS z twoimi regułami. Użyj także ipset, aby dopasować listy sieciowe lub listy ip w regułach. Używam go do białych list. Wszystkie sieci jednego kraju na jednej liście doskonale nadają się do dostrajania. I bardzo łatwo jest chronić inną usługę z tym samym zestawem reguł tylko poprzez dodanie jednego dodatkowego portu do dopasowania. Więc nie lubię zmieniać się z fail2ban, ale może ktoś o innych potrzebach będzie zadowolony z fail2ban.

Oto próbka:

  #
  # SSH tracking sample
  #
  #################################################################################
  iptables -X IN_SSH
  iptables -N IN_SSH
  iptables -A IN_SSH -m set --match-set net_blacklist src -p tcp -j REJECT
  iptables -A IN_SSH -m set --match-set net_whitelist src -p tcp --match limit --limit 5/second -j LOG --log-prefix whitelist_de_prefix
  iptables -A IN_SSH -m set --match-set net_whitelist src -p tcp -j ACCEPT
  # filter update
  iptables -A IN_SSH -m recent --name sshbf --set --rsource
  # connlimit
  iptables -A IN_SSH -m connlimit --connlimit-above 4 --match limit --limit 5/second -j LOG --log-prefix ssh_connlimit_per_ip_above_4
  iptables -A IN_SSH -m connlimit --connlimit-above 4 -j REJECT
  # filter
  iptables -A IN_SSH -m recent --name sshbf --rttl --rcheck --hitcount 13 --seconds 60 --match limit --limit 5/second -j LOG --log-prefix ssh_filtered_13in60sec
  iptables -A IN_SSH -m recent --name sshbf --rttl --rcheck --hitcount 13 --seconds 60 -j REJECT
  iptables -A IN_SSH -j ACCEPT

iptables -A FORWARD -p tcp --dport ssh --syn --jump IN_SSH
# iptables -A INPUT -p tcp --dport ssh --syn --jump IN_SSH

Dane wyjściowe komunikatów logowania można połączyć z fail2ban. Możesz go również użyć do reguł INPUT.