Ochrona usług przed atakami brute force z fail2ban’em

Bardzo często konfigurując usługi dostępne publicznie poświęca się sporo czasu na maksymalne zwiększenie bezpieczeństwa przez “dopieszczanie” konfiguracji (certyfikaty z mocnym szyfrowaniem, ochronę pewnych stron hasłem, dostęp do SSH tylko kluczami, itd.) ale całkowicie pomija się przygotowanie systemu aktywnie monitorującego błędne próby autoryzacji. Oczywiście nie można umniejszać wagi pierwszego z wymienionych etapów ale zdecydowanie nie powinno pomijać się też tego drugiego. Przecież każdy admin chciałby wiedzieć gdy ktoś próbuje włamać się na jego serwer (FTP, HTTP, SSH, itp.) – tylko ilu z Nas zadaje sobie trud by uruchomić taki system?

Wielu z nas uważa że przygotowanie takiego mechanizmu jest zbyt pracochłonne, trudne, nie teraz, nie mam czasu, itd…. Zapominamy przy tym że gotowy system zostanie oddany w ręce użyszkodników a Ci na pewno będą z niego korzystać wbrew wszelkim zasadom bezpieczeństwa 😉

Na przykład taki Roman z loginem romek ustawi hasło do poczty abc123 – wirusy i boty zamiast próbować łamać hasło jednego usera bardzo często próbują wbić się na popularne loginy wykorzystując proste hasła – zaskakujące jak często się im to udaje. A później Roman ma pretensje do admina że jego znajomi dostali po 10000 maili z wirusami…

Tymczasem w wielu przypadkach wystarczy fail2ban w praktycznie podstawowej konfiguracji by ochronić typowe usługi przed:

  • atakami brute force jak w powyższym przykładnie (SSH, Apache, vsftpd, proftpd, Postfix, SASL Auth, etc),
  • atakiem pocztowego bot netu (blokowanie hostów generujących dużą ilość błędów),
  • złymi crawler’ami czy narzędziami skanującymi strony WWW,
  • ataki flood na Bind DNS.

Narzędzie napisane jest w Perl’u i działa jako demon zapisując dane z syslog’a w małych paczkach i okresowo uruchamiając testy sprawdzające – wpływa to korzystnie na wydajność (bo nie musi analizować całodniowych logów jak prymitywniejsze narzędzia). Modułowa konfiguracja pozwala łatwo dodać filtry (wykrywające niezdefiniowane w standardzie zdarzenia) lub akcje (np. zamiast wycinać spam bota przez iptables można go wrzucić do naszego prywatnego RBL’a). W innym poście podałem przykład dodania reguł dla dovecot’a.

Pomimo iż narzędzie wydaje się zbytnio nie obciążać systemu to raczej nie odważyłbym się go zainstalować na mocno obciążonym serwerze, gdzie generują się miliony linii logów dziennie. W takiej sytuacji potrzebne jest inne rozwiązanie.

Instalacja

W moim przypadku na Debianie leci to typowo:

apt-get install fail2ban

Aplikację można też dość łatwo zainstalować ze źródeł – zalezności nie ma zbyt dużo.

Konfiguracja

Gdy już zainstalujemy fail2ban’a otwieramy główny plik konfiguracyjny /etc/fail2ban/jail.conf. Idąc od początku warto zainteresować się opcjami:

# poniżej należy umieścić listę adresów IP, sieci CIDR, z których
# chcemy ignorować zagrożenia
ignoreip = 127.0.0.1 10.3.4.0/24

# domyślny czas BAN'a - można nadpisać w konfiguracji danej usługi
bantime  = 36000

# domyślna ilość wykrytych akcji, po których zostanie dojdzie
# do BAN'a
maxretry = 3

# adres osoby, która ma być informowana o nałożeniu/zdjęciu BAN'a
destemail = moj@mail.pl

# domyślna akcja, predefiniowane są 3 możliwości:
# action_    - tylko BAN
# action_mw  - BAN i powiadomienie mailem z danymi WHOIS
# action_mwl - jak wyżej plus linie z loga
action = %(action_mwl)s

Dalej w konfigu znajdują się przygotowane definicje poszczególnych usług i ich konfiguracja, np. SSH:

[ssh]
enabled = true
port    = ssh
filter  = sshd
logpath  = /var/log/auth.log
maxretry = 5
bantime = 3600

[ssh-ddos]
enabled = true
port    = ssh
filter  = sshd-ddos
logpath  = /var/log/auth.log
maxretry = 6

Jak wspominałem wcześniej w danym bloku można wpisać inne niż domyślne wartości dla opcji bantime i maxretry. Opcja filter wskazuje na nazwę pliku z definicją filtru, np: /etc/fail2ban/filter.d/sshd.conf. W tej lokalizacji możemy dodawać też własne filtry, trzeba tylko znać wyrażenia regularne. W opcji port możemy zmienić port, na którym działa usługa (by banowanie działało), korzystając przy tym z nazw dostępnych w pliku /etc/services lub bezpośrednio wpisując numer portu.

Domyślnie nie jest włączona ochrona żadnej z usług. By ją włączyć należy zmienić w stosownym bloku:

enabled = false

na:

enabled = true

i przeładować fail2ban’a:

invoke-rc.d fail2ban restart

I na początek wystarczy. W kilku banalnych krokach uruchomiliśmy system monitorujący logi i blokujący próby włamań.

Oczywiście włączając ochronę danej usługi dobrze zapoznać się z regułami zapisanymi w danym filtrze – by nie być zaskoczonym gdy sypnie mailami 😉

Wyłączenie powiadamiania o starcie fail2ban’a

Jeżeli włączymy powiadamianie mailem o banach jako gratis fail2ban będzie powiadamiać nas mailem o właczeniu i wyłączeniu ochrony dla każdej z usług – na wypadek gdyby ktoś bez naszej wiedzy zechciał go wyłączyć. Dla wielu może to być irytujące zachowanie.

By wyłączyć powiadomienia trzeba w pliku akcji – u mnie w: /etc/fail2ban/action.d/mail-whois-lines.conf wyczyścić opcje actionstart i actionstop by wyglądały jak poniżej:

actionstop =
actioncheck =

Leave a Reply

Your email address will not be published. Required fields are marked *