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ą danych1.
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 www2. 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.
- 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, /webadmin, itp. [↩]
- W przypadku fail2ban jednak blokada dotyczy całego serwera, a nie tylko dostepu do www [↩]
Dodaj komentarz