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 =