cPanel, Bloker IP i WordPress

[Krystek]

Znajomemu, który ma konto na hostingu i kilka zainstalowanych domen z WordPressami, ktoś włamał się na te WordPressy i zainstalował w nich szkodliwe skrypty. Poprosił mnie, bym pomógł mu popsrzątać po włamywaczach. Administratorzy hostingu powiadomili o włamie i zablokowali dostęp do zarażonych plików, a ich lista była dostępna w wynikach skanera Immunify360. Pousuwałem ręcznie wskazane pliki, zaktualizowałem WordPressy, wtyczki i szablony, włączyłem automatyczną aktualizację wtyczek (WordPress od najnowszej wersji 5.5 pozwala na ustawienie zautomatyzowanych aktualizacji dodatków). Poblokowałem również w Blokerze IP adresy IP, z których w dniu ataku pochodził największy ruch. Były to głównie adresy zagranicznych serwerowni, które wyciąłem bez żalu, bo to zwykły użytkownik ma zaglądać na stronę, a nie host w serwerowni.

 

Jako, że tam są WordPressy, które mają pliki.htaccess to po dodaniu blokowanego IP w Blokerze IP cPanelu taki adres pojawia się w sekcji deny wpisów pliku .htaccess. Pytanie, czy jest możliwość - dysponując cPanelem - zablokować ruch do stron z konkretnych IP nie tylko na poziomie plików .htaccess? Bo w logach FTP dla konta jednej z podpiętych domen był ruch z farmy botów. Wyciąłem ten adres blokerem cPanelu, ale po FTP nadal można się z tego adresu dobijać do serwera? Hasło do tego konta oczywiście zmieniłem, chociaż nie ja to konto zakładałem - w ogóle nie miałem go skonfigurowanego w żadnym programie FTP. Czy na koncie hostingowych nie da się wyciąć ruchu z IP? Czy już trzeba do tego VPS-a?

 

I ostatnie pytanie w kwestii bezpieczeństwa stron na hostingu to tam jest folder domowy /home/nazwakontahostingowego folder /public_html oraz foldery poszczególnych domen, na których są WordPressy. Czyli tak:

 

/home/nazwakontahostingowego/public_html/domena.1/

/home/nazwakontahostingowego/public_html/domena.2/

/home/nazwakontahostingowego/public_html/domena.3/

 

itd.

 

Czy jest możliwe, że jeśli ktoś włamie się na WordPressa w folderze /domena1 to jest w stanie dostać się poziom wyżej, do folderu /public_html/ i atakować inne strony na serwerze? Bo w wyniku włamu ucierpiały takze strony, na których nie ma WP - są tylko folderu z index.php albo index.html.

 

I jeszcze jedno. Wśród tych stron na WordPressie są takie, które już nie będą w przyszłości aktualizowane o nowe materiały (teksty, zdjęcia, pliki). Czy jeśli zablokuję dodatkowo dostęp do folderu /wp-admin/ za pomocą .htpasswd i zastosuję regułkę z tej strony, by działał poprawnie panel admina to czy to nie zepsuje automatycznych aktualizacji WP?

 

[proserwer.pl]

Witaj, tak blokada .htaccess działa tylko dla ruchu na stronie (do serwera www), nie wpływa na FTP. Szersza blokada możliwa tylko do wykonania przez administratora. Generalnie nie ma sensu tego blokować po Twojej stronie, jest tego zbyt wiele. Ważniejsza jest odpowiednia aktualizacja i konfiguracja wordpressa. Co do katalogów to jak najbardziej infekcja może się rozejść po wszystkich plikach na Twoim hostingu.

[Krystek]

Dzięki. No to tak, jak myślałem. FTP-a nie da się zablokować. A szkoda, bo po klasach IP, które brużdzą - czyli hostingownie - bym poblokował to i owo, żeby odbijali się od serwera w ogóle. Co do WordPressa to na każdej jego instalacji jest jeszcze zaintalowany dodatek All In One WP Security & Firewall [link], który przede wszystkim blokuje 90% szkodliwego ruchu. Mam w nim ustawione, że po 3-ch próbach logowania na panel admina WP z błędnym loginem i/lub hasłem, adres IP z którego była taka próba jest blokowany na 48h. Mailem dostaję powiadomienia o próbie logowania z adresem IP oraz nazwą loginu admina, której próbowano użyć do zalogowania. Poza tym jest tam w tym dodatku włączona opcja sprawdzania wywołań 404 dla strony WP w domenie, więc m ożna prześledzić jakie IP próbują wywoływać nieistniejące skrypty albo odwołują się do katalogów, do których nie powinny. Je też można dodać do blacklisty - automatycznie lub ręcznie. Powtarzające się adresy albo takie, które atakują kilka razy z rzędu dodaję do listy blokowanych. Jest tam wiele jeszcze innych opcji, które pomagają walczyć z próbami włamań (np. firewall, który blokuje fałszywe boty, dodawanie captacha na stronie logowania, zmiana adresu strony logowania).

 

Ale akurat w tym przypadku próbuję ustalić, czy to atak na jednego WordPressa rozlał się po całym serwerze, czy może wyciekło hasło dostępowe FTP do folderu głównego domeny. Dla dostępu przez FTP/SSH będę generował klucz SSL, by logować z autoryzacją poprzez certyfikat, więc może to wyeliminuje wykradanie haseł przez malware (o ile u kogoś - korzystających z tego serwera i dostępu FTP do niego - wyciekło).

[l3szcz]

Niech zgadnę, malware, który jest zahashowany (w index.php etc.)?
Nie musiało wyciekać hasło FTP. Atakujący wykorzystał lukę w Wordpress, a bardziej w jakimś z Twoich pluginów / templatce i wrzucił webshella. 

Nic to nie da, że zmienisz hasła dostępu FTP czy SSH. Oni po prostu atakują całość jak leci przez dziury samego CMS. 

[Krystek]

No, to nie moje pluginy Miałem posprzątać po włamaniu. Też obstawiam dziury w dodatkach, bo Immunify360 część plików instalacji WP naprawił (wykasował złośliwy kod), a część podrzuconych plików zapisał na liście do usunięcia. Te wgrane pliki pousuwałem. WordPressy zaktualizowałem i włączyłem automatyczną aktualizację dodatków.

 

Ale zauważyłem też jedną rzecz związaną z cPanelem i blokowaniem po IP w Blokerze IP cPanelu: w logach cPanlu sprawdzam wpisy w sekcji Logi błędów. Tam mam odwołania z IP do nieistniejących zasobów i mogę sprawdzić, czy z danego adresu nie było wejść na różne domeny na tym serwerze. Wtedy wiem, że takie IP jest podejrzane, bo wie o różnych innych domenach. Takie IP dodaję w Blokerze IP i najczęściej jest tak, że przy kolejnej próbie sondowania strony taki adres dostaje 403 od serwera. Ale wydaje mi się, że było kilka adresów, które dodałem w Blokerze IP cPanelu, a nie zostały zablokowane przez serwer. Bo sprawdzałem potem czy te adresy były wpisane na listę blokowanych i były. Tak, jakby taa blokada razł działała, a innym razem nie. Możliwe to?

[l3szcz]

Tak, możliwe, że czasem filtry po prostu nie łapią

[Kapitan_Bomba]

Blokowanie pojedynczych adresów IP to jak stawianie ogrodzenia z samych słupków Prędzej zajedziesz apache/iptables niż w jakikolwiek sposób zabezpieczysz w ten sposób serwer. Toksycznych adresów IP (zmieniających się, oczywiście) jest kilkaset tysięcy, a już przy nastu tysiącach iptables zaczyna mieć problemy przy dużym ruchu.

[Krystek]

Nie dodaję do blokady adresów typu Neostrada. Dodaję albo klasy albo powtarzające się adresy, które najpierw sprawdzam pod kątem zjadliwości w serwisie AbuseIPDB, czyli głównie hostingownie z atakującymi maszynami (Hetzner, OVH, Digital Ocean, Microsoft i kilka innych, które się często przewijają).

[l3szcz]

FW ich po prostu pewnie nie chwyta, mimo wszystko. 
Ja bym całą mitygację zrobił przez .htaccess, na przykład blokując konkretny wpis (powiązanie IP + userAgenta), np.:

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} ^.*(JakisBot).*$ [NC]
RewriteRule .* - [F,L]
RewriteCond %{HTTP_USER_AGENT} ^-?$
RewriteRule ^ - [F]

(wzięte z https://www.siteground.com/kb/htaccess-block-user-agent/)

No i oczywiście adresy IP. 

 

[Krystek]

Blokadę przez plik .htaccess robi i serwer - dodając reguły z cPanelu, i wtyczka All in One WP Security. Dodaje np. reguły próbujące wyeliminować boty, proxy, ataki na konkretne pliki konfiguracyjne WordPressa, listowanie folderów, przekierowania z podejrzanych stron i ataki na popularne moduły, pliki, katalogi. Tu jest nieco opisane - https://www.tipsandtricks-hq.com/wordpress-security-and-firewall-plugin | https://www.tipsandtricks-hq.com/adding-firewalls-to-your-wordpress-site-6974

Nie mogę już zatwierdzić edycji poprzedniego komentarza,  więc dodaję kolejny: dodałem w załączniku do tego postu z komentarzem plik .htaccess wygenerowany przez wtyczkę All in One WP Security. W niej są wstawione prawie wszystkie reguły, które zostały dodane przez włączenie odpowiednich opcji w panelu administracyjnym wtyczki w WP adminie. Prawie wszystkie opcje bezpieczeństwa powłączałem dla strony, z której pochodzi ten plik .htaccess.

WP_All_in_One_Security-htaccess.txt

Edytowane 26 Sierpnia 2020 przez Krystek