Atak DDos na Wordpressa - jak się bronić?

[kacperq]

Cześć. Od rana moja strona jest DDoSowana. Hostingodawca zablokował kilka adresów IP, ale nic to nie dało. Strona działa tak wolno, że szkoda słów. Do tego dziś rano wykorzystanie CPU przekroczyło 90%, a ja sam musiałem nieco dopłacić. Czekam na weryfikację domeny w Cloudflare, ale obawiam się, że i to niewiele pomoże... Ktoś ma jakiś pomysł?

 

Strona stoi na Wordpressie, a on sam jest odpowiednio zabezpieczony. Do tego korzystam jeszcze z wtyczki Wordfence, która... nie zablokowała nic. Strona raz ładuje się w dwie sekundy, żeby chwile później ładować się w 30.

Edytowane 25 Lutego 2019 przez kacperq

[Fizyda]

Nie da się DDoS'ować WordPressa, ale to szczegół. Użycie CF w tym momencie i tak nic nie da bo napastnik zna adres IP Twojego serwera. Więc albo musisz też zmienić IP serwera lub serwer, albo nie ma sensu bawić się w CF.

 

Z DDoS i DoS można próbować się bronić tylko na poziomie serwera, zabawa na poziomie skryptu jest bezsensowna i mało efektywna. Sprawdziłbym czy przypadkiem problemu nie stanowią jednak wtyczki zabezpieczające. Bo nie wiem czemu ma służyć używanie wtyczek pokroju wordfance gdy nie masz wiedzy jak z nich korzystać i jak je skonfigurować. Poza tym jak znam życie to nie jest jedyna wtyczka do "zabezpieczenia" wordpressa.

 

Najlepszym zabezpieczeniem WP jest myślenie i używanie jak najmniejszej liczby wtyczek. Czyli coś zupełnie odwrotnego niż stosują i polecają domorośli pseudo webmasterzy i "programiści" WordPressa, a w szczególności "programiści" Divi...

Edytowane 25 Lutego 2019 przez Fizyda

[kacperq]

To jest jedyna wtyczka zabezpieczająca Wordpressa w moim wypadku. Zainstalowałem ją tylko dla firewalla, bo wszystkie blokady itd. robię w .htaccess. Ale z tego co widzę jest zbędna, wiec zaraz wyleci. Nie bardzo wiem jak zmienić IP serwera, a zmiana samego serwera nie wchodzi póki co w grę. Może można wykupić jakieś dodatkowe usługi czy coś, co utrudni ataki? Z tego co widzę to niektóre firmy hostingowe mają jakieś pakiety "anty ddos".

[Fizyda]

16 minut temu, kacperq napisał:

Może można wykupić jakieś dodatkowe usługi czy coś, co utrudni ataki? Z tego co widzę to niektóre firmy hostingowe mają jakieś pakiety "anty ddos".

 

Jeśli jest w ofercie firmy to może i można. Jednak nie da się w 100% zabezpieczyć przed DDoS. Każdą usługę da się zablokować dysponując odpowiednio wielkim bot netem. Jest to bardzo nierówna walka i często łatwiej walczyć z nią przez namierzenie osoby która takie ataki realizuje, a w tedy walczyć z nią prawem. Zazwyczaj są to zazdrośni znajomi bądź konkurencja która używa darmowego stressera do obciążenia Twojego serwera.

Inna droga to zwiększanie zasobów serwera - skalowanie w dół dopóki się da, a następnie w szerz poprzez rozbudowę infrastruktury sieciowej z której zbudowany jest Twój serwis.

[Matix8981]

Pamiętaj, że wtyczki nic nie dadzą, zabezpieczenia jest tworzy na podłożu serwerowym nie programowym, programowy ma jedynie służyć jako ostatni filtr niż jako pierwszy który pełni największą funkcje.

Można się spytać u jakiej firmy masz usługę hostingową?

Edytowane 25 Lutego 2019 przez Matix8981

[#Gremsonkowy#]

29 minut temu, kacperq napisał:

To jest jedyna wtyczka zabezpieczająca Wordpressa w moim wypadku. Zainstalowałem ją tylko dla firewalla, bo wszystkie blokady itd. robię w .htaccess. Ale z tego co widzę jest zbędna, wiec zaraz wyleci. Nie bardzo wiem jak zmienić IP serwera, a zmiana samego serwera nie wchodzi póki co w grę. Może można wykupić jakieś dodatkowe usługi czy coś, co utrudni ataki? Z tego co widzę to niektóre firmy hostingowe mają jakieś pakiety "anty ddos".

Zacznijmy od tego co jest wąskim gardłem czy aby czasem nie webserver? W takim wypadku jakiekolwiek wtyczki do WP nic nie zdziałają bo co z tego że one coś sobie tam blokują skoro sam apache2 nie jest już w stanie obsłużyć większej ilości połączeń. Dlatego jeśli posiadasz serwer VPS/Dedyk po pierwsze zobacz /var/log/apache2/access.log co dokładnie z czego i gdzie leci, po 2 zastanów się nad ustawieniem proxy korzystając z NGINX przed tym apache.

 

[Mion]

8 godzin temu, #Gremsonkowy# napisał:

po 2 zastanów się nad ustawieniem proxy korzystając z NGINX przed tym apache.

Co z tego jak proxy NGINEX'a będzie wywoływało żądania HTTP do apache > PHP, więc w wypadku ataku, to nic nie da.  Atak musi być blokowany warstwę wyżej zanim nadmierna ilość żądań HTTP "dojdzie" do samego serwera. To samo tyczy wtyczek zwłaszcza jeśli będą oparte o bazę danych

[Tomek]

Jak dokładnie wygląda atak? Jak wygląda access log strony?

Większość ataków na wordpressa które u nas widzimy to odwołania np. do pliku xmlrpc.php, admin-ajax.php, czy też wysyłany jest jakiś POST na podstronę.

Wówczas można dopisać odpowiednie regułki do .htaccess i próbować coś wyblokować. Jeśli ten ruch nie spowoduje odpalenia procesów PHP na koncie to obciążenie będzie znikome (chyba, że wówczas coś innego w infrastrukturze dostawcy nie wytrzyma).

Fakt, czasami można zablokować kawałek normalnego ruchu w ten sposób. Ale lepiej zablokować 1% użytkowników i mieć sprawnie działającą stronę, niż aby 100% użytkowników nie mogło wejść

[#Gremsonkowy#]

Godzinę temu, Mion napisał:

Co z tego jak proxy NGINEX'a będzie wywoływało żądania HTTP do apache > PHP, więc w wypadku ataku, to nic nie da.  Atak musi być blokowany warstwę wyżej zanim nadmierna ilość żądań HTTP "dojdzie" do samego serwera. To samo tyczy wtyczek zwłaszcza jeśli będą oparte o bazę danych

Jeśli postawi po prostu NGINX to jak najbardziej na wiele się to nie zda aczkolwiek takie rozwiązanie daje już możliwość cięcia req przed apache'm czy chociażby można zastosować gotowe rozwiązanie o nazwie vDDoS. Co do blokowania "wyżej" to na dobrą sprawę jedyne co możesz robić to limity per Source adres (możesz to również limitowac per konkretne żądanie) a cała resztę typu weryfikacja chociażby przez JS'a musisz już ogarniać z samego proxy. Reasumując według mnie w przypadku protokołu http nie ma sensu ciąć tego wcześniej niż proxy to nie jest atak L4 z którym przeciętny serwer z rurką 1gbps by sobie sam nie poradził .

[home_pl]

Ochrona przed DDOS przez wtyczkę - nie, to nie przejdzie Warto zweryfikować możliwości od strony infrastruktury lub samego serwera np. poprzez zmianę IP (serwera, a nie Cloudflare). Pamiętam, że ktoś kiedy na FB w grupie sysopów opisywał zabawny motyw, w którym ochrona przez DDOS polegała na podmianie kodu i pobieranie przez atakującego jakiegoś skryptu, który rozpakowywał się do 10 TB (czy jakoś tak - mogę się mylić :)) pustego pliku.  W skrócie - atakujący sam się orał, ale działało to tylko w konkretnych przypadkach. J.w. duża liczba ataków wywołana jest podatnością plików xmlrpc.php oraz admin-ajax.php i odwołaniami do nich.

[szmigieldesign]

Główny problem z DDoS ma związek z pierwszą literką, czyli Distributed. Zakładając szczęśliwy scenariusz, że faktycznie atak przeprowadzony jest na wspomniane w komentarzach xmlrpc czy admin-ajax to i tak bardzo dużą liczbę zapytań zamierzasz filtrować przez Apache lub PHP, co negatywnie wpłynie na wydajność. Jeżeli atakowany jest Twój serwis (np. wspomniane pliki w domenie) to Cloudflare może pomóc. Jeżeli atakowany jest serwer przez IP, wtedy najlepiej zadziałają dedykowane narzędzia zainstalowane (bądź nie) po stronie hostingu.

W przypadku WordPress, Wordfence przydaje się głównie do raportów przesyłanych na e-mail (co jest przydatne w szczególności kiedy potrzebujesz mieć kontrolę nad wieloma serwisami), do porównywania plików WordPress (motywów i wtyczek) z wersjami znajdującymi się w repozytorium oraz do szybkiego i łatwego wdrożenia pomocnych mechanizmów bezpieczeństwa (ograniczenie prób logowania, zapobieganie wykonywania kodu w /wp-content/uploads/ etc.). Wordfence posiada WAF, ale jest to mechanizm działający z poziomu PHP (czyli nie będący królem wydajności), wymaga wstępnej konfiguracji (która nie jest wykonywana samoczynnie po instalacji) i w wersji darmowej posiada reguły opóźnione o 30 dni względem daty publikacji.

 

Jeżeli hosting nie pomoże, możesz rozważyć subskrypcję usługi od Sucuri. Różnica w stosunku do Wordfence polega na tym, że ruch kierowany jest przez firewall zewnętrzny, a filtry nie są uruchamiane na poziomie Twojego hostingu. Obawiam się jednak, że w przypadku ataków na IP nie filtrowanych skutecznie przez hosting, rezultat będzie podobny jak dotychczas.

[Mion]

12 godzin temu, kacperq napisał:

Strona stoi na Wordpressie, a on sam jest odpowiednio zabezpieczony

Cache Masz wdrożone ? Jeśli nie to zainstaluj. Co prawda sam cache nie ma wpływu na atak o ile taki jest, ale przy zwiększonym ruchu znacznie odciąża zasoby serwera po przez redukcję zapytań SQL i "kosztownych" operacji PHP, których w WP nie brakuje

[nnd.newbie]

W mojej opinii Cloudflare mógłby pomóc  o ile masz wsparcie ze strony hostingu.  Po uruchomieniu Cloudflare cały ruch powinien iść przez Cloudflare. Wtedy najlepiej zmienić IP swojej usługi.  Jak masz współdzielony IP to chyba czas dokupić własny adres. Cloudflare publikuje listy IP z których korzysta. Hosting powinien whitelistować ip cloudflare i zablokować cały ruch WWW (80/443) z innych IP. W tym momencie nawet jak twój IP zostanie skompromitowany to ruch spoza Clouflare powinien zostać zablokowany na firewallu. Myślę, że hosting powinien Ci pójść na rękę bo w ich interesie też jest ograniczanie DoSa. 

 

Teraz cała nadzieja w Cloudflare, a tam:

1) Już powinno odciążyć trochę Twoją stronę bo Cloudflare będzie serwował zawartość statyczną

2) Są tam mechanizmy antyDDosowe które można wzmocnić na czas ataku np. żeby każdy request odczekał jakiś czas przed puszczeniem dalej, albo Captcha dla podejrzanych IP.

 

A docelowo jeśli tak często borykasz się z Dddosami to przenieść się na hosting gdzie mają wdrożoną jakąś ochronę. Koledzy z forum pewnie pomogą z propozycjami.

Edytowane 26 Lutego 2019 przez nnd.newbie

[Kapitan_Bomba]

Cytuj

 

Jak dokładnie wygląda atak? Jak wygląda access log strony?

Większość ataków na wordpressa które u nas widzimy to odwołania np. do pliku xmlrpc.php, admin-ajax.php, czy też wysyłany jest jakiś POST na podstronę.

 

Jedyna sensowna odpowiedź w tym temacie. Reszta chyba nigdy WordPressa na oczy nie widziała ;)

[psz]

Polecam lekturę:  https://support.cloudflare.com/hc/en-us/articles/200170196-I-am-under-DDoS-attack-what-do-I-do-

[Spoofy]

Problem polega na tym, że czym innym jest L4 a czym innym L7 i atak aplikacyjny, uwalający np. wykonywanie PHP. Proxy przez Nginx'a jest świetnym rozwiązaniem na 80% przypadków tego typu, aczkolwiek warto poprosić autora tematu o wycinek access log'a.

 

Btw. O tym też pisał CloudFlare

[psz]

Zgadzam się, że jest różnica między L4 (ochrona przed którym powinna być w standardzie każdego porządnego hostingu).

 

Natomiast co do L7 to CF ma szereg rozwiązań:

- rate limiting (1 darmowa reguła)

- Blokowanie po User-Agent (10 darmowych reguł), co ciekawe, skuteczne na głupie boty

- IP Access Rules, można sobie np. Chiny czy Ukraińskie hostingi przyblokować

- Firewall Rules (5 reguł za darmo), blokowanie po składni przypominającej Wireshark/tcpdump

- Cloudflare Access (5 userów za darmo), można sobie ustawić np. /wp-admin za logowaniem

- WAF (płatne)

 

Dostępnych rozwiązań jest cała masa. Jedynym warunkiem jest, żeby atakujący nie znał adresu IP serwera, więc rotacja w hostingu wskazana.