Dziś częstym rodzajem ataku jest atak typu brutal force polegający na wpisywaniu słownikowych haseł. Atak jest niebezpieczny, gdy mamy większą ilość użytkowników. Poza tym rzadziej zdarza się atak typu DDOS. Na te dwa rodzaje ataków pomoże fail2ban.
Pobieramy pakiet z internetu, domyślnie ustawiony jest tylko na obronę SSH. Kopiujemy plik jail.conf -> jail.local. Teraz oba pliki są identyczne (program najpierw ładuje pierwszy, a potem nadpisuje ustawienia drugim). Zmieniamy plik .local, w .conf nie grzebiemy, bo przy pierwszej aktualizacji fail2ban nadpisze go swoimi ustawieniami.
Edytujemy plik,
1 2 3 | ignoreip = 127.0.0.1/8 192.168.1.0/24 bantime = 600 maxretry = 3 |
Tu wpisujemy nasze adresy IP, z których nikt się przecież nie włamie, adresy w sieci lokalnej i (ważne) 127.0.0.1.
Następnie w każdej sekcji poniżej, jeśli chcemy ją włączyć, zmieniamy na:
1 2 | enabled = true port = 3333 |
port – to port na którym działa usługa – zmieniamy, jeśli np. nasze SSH działa na innym porcie niż 22.
Standardowo nie ma ochrony phpMyAdmin, ale można ją „dorobić”, w pliku konfiguracyjnym dodajemy:
1 2 3 4 5 6 7 8 | [apache-myadmin] enabled = true filter = apache-myadmin port = http,https logpath = /var/log/apache2/error.log action = iptables-multiport[name=apache-myadmin, port="http,https", protocol=tcp] maxretry = 2 bantime = 84600 |
Błędy w wyrażeniach regularnych
Wyrażenia regularne są dopasowane do innych typów serwera niż Debian Wheezy, niektóre trzeba skorygować, m.in. dla ataków brutal force na .htpasswd – plik /etc/fail2ban/filter.d/apache-auth-conf, dopisujemy (druga linia z poniższych) zgodnie z wpisami do /var/log/apache2/error.log:
1 2 | failregex = ^%(_apache_error_client)s user .* (authentication failure|not found|password mismatch)\s*$ ^\[.*\] \[error\] \[client <HOST>\] user .* (authentication failure|not found|password mismatch).*$ |
<HOST> to adres banowanego hosta, musi wystąpić.
PhpMyAdmin
W katalogu filter.d tworzymy plik apache-myadmin.conf o zawartości:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 | [definition] failregex = \[client <HOST>\] File does not exist:.*(?i)admin.* \[client <HOST>\] File does not exist:.*(?i)manager.* \[client <HOST>\] File does not exist:.*(?i)setup.* \[client <HOST>\] File does not exist:.*(?i)mysql.* \[client <HOST>\] File does not exist:.*(?i)sqlweb.* \[client <HOST>\] File does not exist:.*(?i)webdb.* \[client <HOST>\] File does not exist:.*(?i)pma.* \[client <HOST>\] File does not exist:.*(?i)vtigercrm.* ^<HOST>.*GET.*(?i)admin.* ^<HOST>.*GET.*(?i)manager.* ^<HOST>.*GET.*(?i)setup.* ^<HOST>.*GET.*(?i)mysql.* ^<HOST>.*GET.*(?i)sqlweb.* ^<HOST>.*GET.*(?i)webdb.* ^<HOST>.*GET.*(?i)pma.* ^<HOST>.*GET.*(?i)vtigercrm.* ignoreregex = |
Restartujemy server: service fail2ban restart
OwnCloud – zabezpieczenie chmury
Chmurę też można zabezpieczyć przed atakami brutal force, robimy to tak:
W pliku OwnCloud (/var/www/owncloud/config/config.php) aby włączyć logowanie dopisujemy:
1 2 3 4 | 'logtimezone' => 'Europe/Warsaw', 'logfile' => '/var/log/owncloud/owncloud.log', 'loglevel' => '2', 'log_authfailip' => true, |
UWAGA! Właścicielem pliku z logami (katalogu /var/log/owncloud) musi być ten uruchamiający apache2, czyli www-data.
Tworzymy filter /etc/fail2ban/filter.d/apache-owncloud.conf:
1 2 3 4 5 6 7 | [Definition] failregex={"app":"core","message":"Login failed: user '.*' , wrong password, IP:<HOST>","level":2,"time":".*"} {"app":"core","message":"Login failed: '.*' \(Remote IP: '<HOST>', X-Forwarded-For: '.*'\)","level":2,"time":".*"} {"reqId":".*","remoteAddr":"<HOST>","app":"core","message":"Login failed: .*","level":2,"time":".*"} ignoreregex= |
a w pliku /etc/fail2ban/jail.local dopisujemy
1 2 3 4 5 | [apache-owncloud] enabled = true filter = apache-owncloud port = https logpath = /var/log/owncloud/owncloud.log |
Zrobione, przy ustawionych domyślnych 3 próbach logowania, czwarta zakończy się banem.