Osoby posiadające swoje własne serwery pewnie nie raz zwróciły uwagę na plik error_log serwera www (apache, httpd) oraz informacje w nim zawarte, jak np.:

[Sun Oct 09 14:19:27 2011] [error] [client PEWNE_IP] File does not exist: /PEWIEN_KATALOG/phpMyadmin
[Sun Oct 09 14:19:28 2011] [error] [client PEWNE_IP] File does not exist: /PEWIEN_KATALOG/phpMyAdmin
[Sun Oct 09 14:19:28 2011] [error] [client PEWNE_IP] File does not exist: /PEWIEN_KATALOG/phpmyAdmin
[Sun Oct 09 14:19:28 2011] [error] [client PEWNE_IP] File does not exist: /PEWIEN_KATALOG/phpmyadmin2
[Sun Oct 09 14:19:28 2011] [error] [client PEWNE_IP] File does not exist: /PEWIEN_KATALOG/2phpmyadmin
[Sun Oct 09 14:19:29 2011] [error] [client PEWNE_IP] File does not exist: /PEWIEN_KATALOG/phpmy
[Sun Oct 09 14:19:29 2011] [error] [client PEWNE_IP] File does not exist: /PEWIEN_KATALOG/phppma
[Sun Oct 09 14:19:29 2011] [error] [client PEWNE_IP] File does not exist: /PEWIEN_KATALOG/myadmin
[Sun Oct 09 14:19:29 2011] [error] [client PEWNE_IP] File does not exist: /PEWIEN_KATALOG/MyAdmin
[Sun Oct 09 14:19:30 2011] [error] [client PEWNE_IP] File does not exist: /PEWIEN_KATALOG/program

Z powyższych informacji można wywnioskować iż ktoś z PEWNEGO_IP próbował uzyskać dostęp do plików/katalogów, których nie ma na serwerze. Przeważnie są to jakieś boty, które przeszukują nasz serwer pod kątem panelu zarządzania bazą danych ^[1]Przeważnie, ale są również inne przypadki. Ja w większości miałem do czynienia z poszukiwaniem ścieżki do phpMyAdmina. Poza tymi zapytaniami również popularne są /admin, /administrator, … Continue reading.

Jak zatem bronić się przed tego typu atakami na nasz serwer i jego zasoby? Logicznym rozwiązaniem wydaje się dodanie reguły do zapory systemowej i zablokowanie delikwenta. Jednakże nie jesteśmy zalogowani 24/h na naszym serwerze i nie monitorujemy ciągle logów. Wypadałoby zatem w jakiś sposób zautomatyzować tę czynność.

Fail2ban vs mod_security/modsec

W internecie udało mi się znaleźć, a właściwie utwierdziłem się w przekonaniu iż najpopularniejszymi rozwiązaniami jest instalacja programu fail2ban, lub modułu dla Apache/httpd występującego w internecie pod dwoma nazwami: mod_security oraz modsec (odwołujące się do tego samego programu/modułu).

Funkcjonowanie tych dwóch rozwiązań nieco się różni, lecz efekt z punktu widzenia użytkownika, czy też administratora jest taki sam: blokada dostępu danej osoby do serwera www ^[2]W przypadku fail2ban jednak blokada dotyczy całego serwera, a nie tylko dostepu do www. Polecono mi skorzystanie z modsec, jednakże podczas korzystania z tego rozwiązania miałem kilka problemów z funkcjonowaniem skryptów na moim serwerze. Nie działały mi np. podglądy wpisów na blogu, czy dodawanie i usuwanie modułu z PIWIKa. Przyznaję się jednak bez bicia, że korzystałem z domyślnych ustawień oraz filtrów. Zapewne moduł ten blokował sposób przesyłania danych przez skrypty (post, get?).

Zainteresowałem się więc fail2ban, którego działanie jest nieco inne. W przeciwieństwie bowiem do modsec, program ten nie analizuje ruchu serwera apache/httpd, tylko pobiera dane z logów i blokuje {{IP}}. Jeśli np. dany adres w przeciągu x sekund wykonał akcję pasującą do zdefiniowanego filtru y razy wówczas zostaje zablokowany w zaporze przez zdefiniowany okres czasu. Teoretycznie dzięki temu powinienem uzyskać zbliżoną funkcjonalność (blokowanie niepożądanych akcji) przy równoczesnym zachowaniu funkcjonalności skryptów – praktycznie… tak też się stało.

Instalacja fail2ban

Program możemy zainstalować bezpośrednio ze źródeł, korzystając z gotowej paczki, bądź z repozytoriów. Ja jestem leniwy i jeśli jest to tylko możliwe to korzystam z repozytoriów. W przypadku CentOSa paczka z fail2ban znajduje się w repozytoriach EPEL.

Po dodaniu repozytoriów przechodzimy do instalacji:

yum install fail2ban

Program do poprawnego działania wymaga: gamin, shorewall, iptables oraz tcpwrapper. Nie zdziwcie się więc, że doinstaluje zależności.

Konfiguracja fail2ban

Program od razu po instalacji nie zadziała i to mogę Wam zagwarantować. Po pierwsze nie będzie prawdopodobnie uruchomiony, a po drugie nie będzie skonfigurowany by filtrował ruch/logi. Domyślnie (jeśli mnie pamięć nie myli) wszystkie reguły są wyłączone.

Przechodzimy do folderu z konfiguracją programu i otwieramy pierwszy plik, z konfiguracją globalną (dosłownie kilka linijek):

cd /etc/fail2ban/ && nano fail2ban.conf

W pliku zamieniamy logtarget = SYSLOG na logtarget = /var/log/fail2ban.log – chyba, że chcemy by program logował zdarzenia do syslogu (u mnie było to /var/log/messages).

Następnie modyfikacja pliku jail.conf:

#podajemy IP, które są ignorowane przez program
#każde IP oddzielamy spacją
ignoreip = 127.0.0.1
 
#definiujemy czas, na jaki IP zostanie zablokowane
bantime = 600
 
#poniższych nie musimy zmieniać
backend = auto
maxretry = 3
findtime = 600
#definiujemy reguły
[ssh-iptables]
enabled  = true
filter   = sshd
action   = iptables[name=SSH, port=ssh, protocol=tcp]
           sendmail-whois[name=SSH, dest=twój@mail]
logpath  = /var/log/secure
maxretry = 3
 
[httpd-auth-iptables]
enabled  = true
filter   = apache-auth
action   = iptables[name=httpd-auth, port=80, protocol=tcp]
           sendmail-whois[name=httpd-auth, dest=twój@mail]
logpath  = /var/log/httpd/error_log
maxretry = 6
 
[httpd-noscript-iptables]
enabled  = true
filter   = apache-noscript
action   = iptables[name=httpd-noscript, port=80, protocol=tcp]
           sendmail-whois[name=httpd-noscript, dest=twój@mail]
logpath  = /var/log/httpd/error_log
maxretry = 6

Teraz pozostaje nam uruchomić tylko usługę i dodać ją do autostartu. Pracę programu i podjęte akcje możemy obserwować w pliku logu: /var/log/fail2ban.log, oraz w regułach iptables: iptables -L

service fail2ban start
mv /etc/rc3.d/K08fail2ban /etc/rc3.d/S08fail2ban #sposób zaczerpnięty z www.tbaumi.de/blog/?p=635 - nie sprawdzany, sam korzystam z webmina

Teraz jeśli tylko ktoś zostanie zablokowany otrzymamy o tym informację na naszego maila.