Ten dzień planowałem od inspiracji nad nowym projektem. Chciałem poprzeglądać strony różnych firm mających podobny charakter do projektu, który niebawem będę tworzył dla Klientki. Projekt ciekawe się zapowiada bo profil jej klientów pochodzi z USA oraz Kanady. A tu bach, otrzymałem dwa strzały z samego rana.

Włam na stronę firmową

Na dzień dobry, otrzymałem powiadomienie, że na jednej ze stron której jestem administratorem przybył nowy użytkownik z uprawnieniami administratora. Szybko zweryfikowałem jego maila, lecz nic się nie dowiedziałem. Zadzwoniłem do właściciela strony i dopytałem czy kogoś dodawali do strony jako administratora. Oczywiście właściciele zaskoczeni całą sytuacją i nic nie wiedzą o tym użytkowniku. Więc pierwszym moim krokiem było usunięcie tego niechcianego użytkownika oraz analiza luki w stronie.

Przeanalizowałem skąd mógł się dostać do strony i wyszło na to, że jakiś bot złamał prawdopodobnie moje hasło, które wstyd się przyznać nie było aktualizowane od 2021 roku, bo właśnie wtedy projekt został utworzony lub klienta.

Dokonaliśmy aktualizacji haseł i następnie zainstalowałem dwie wtyczki. 

Limit Login Attempts Reloaded do blokowaniu wielu prób logowania w jednej chwili. 

oraz

WPS Hide Login służy do zmiany adresu logowania. WordPress ma to do siebie, że standardowa instalacja zawsze ma ten sam adres logowania do panelu administratora, czyli domena/wp-admin/. Dzięki tej wtyczce możemy zmienić adres do logowania, przez co ograniczymy próbę łamania haseł za pomocą ataku brute force.

Mając te dwie wtyczki, nie powinny się wydarzyć żadne niepożądane autoryzacje na stronie. 

Problemy lubią chodzić parami

Ostatnio, coś mam dziwną passę do podwójnych pożarów. Jak już się dowiedziałeś na jednej stronie pojawił się nieproszony gość, który został szybko wyproszony. Lecz to na dzień dzisiejszy nie było jedno moje zmartwienie. W nowym projekcie sklepu, który ostatnio zrealizowaliśmy wszystko sie wysypało i sypało błędem 503 że serwer przeciążony itd. 

W pierwsze kolejności poszła analiza wtyczkę, które zawierały się w projekcie WordPress. Pomyślałem, że może to mieć coś wspólnego z pamięcią podręczną (LiteSpeed Cache) lub optymalizacją grafik (Converter for Media). Zostały wyłączone i dalej nic. Następnie zabrałem się za wyłączenie po kolei wszystkich wtyczek, które nie były niezbędne do funkcjonowania strony, aż stanęło na Elementorze, na którym jest budowana cała szata graficzna. Po jego wyłączeniu był pewien progres ale strona dalej nie działa prawidłowo. Włączała się ale bez modułu sklepu i dedykowanej szaty graficznej, a przy kategoriach produktów w sklepie wciąż pojawiał się błąd. 

W między czasie również sprawdziłem czy to może szablon WordPress coś nam się naprzykrza. Więc wróciłem do potomnego, no i oczywiście dalej bez zmian. 

Następnie moje kroki skierowane zostały na serwer, gdzie zauważyłem przeładowanie serwera. Zalogowałem się do FTP i znalazłem sporo plików w folderze tmp o nazwie zaczynającej się od magick, które ważyły każdy ponad pół giga. 

Wykasowałem je a one po kilku minutach ponownie się przywracały. Podpytałem na czacie w CyberFolks, czy spotkali się z podobnym problem i czy coś mogą pomóc? Jedynie co mogli zrobić to tylko podpowiedzieli, że te pliki pochodzą ze wtyczki ImageMagick. Sprawdziłem WordPressa i nie znalazłem tej wtyczki. Sprawdziłem inne instalacje pomimo tego, że one i tak między sobą odseparowane i wciąż nie znalazłem tej wtyczki. Jak się później okazało generowała to wtyczka Converter for Media i jej konwerter Imagick.

Zrobiłem przerwę na obiad i po obiedzie ponownie wróciłem do analizy problemu. Myśląc intesywnie cały czas podejrzewałem, że taki problem pojawia się często podczas aktualizacji komponetów. Więc w kolejnym kroku sprawdziłem wersję PHP dla strony, która była 8.1. Nie taka młoda ale wciąż aktualna dla wielu wtyczek. postanowiłem ją podnieść do najwyższej wersji 8.4. Woilà!

Po 2,5h kamień z serca spadł. Sklep wrócił do żywych!  🙂 Wszystko zaczęło szybko działać i ładować się elegancko 🙂