Problem z system load average

[Toxik 0]

Witam,

 

od razu zacznę że jestem laikiem jeśli chodzi o dedyki. Zmuszony byłem przejść na dedyka z hostingu współdzielonego ze względu na ilość stron i ruch jaki generowały. Przeniosłem się w marcu i wszystko było ok, ale od kilku dni dostaję monity z Direct Admina :

 

Warning: The system load average is [wstaw wartość od 10 do 110(sic!)]

 

Po podglądnięciu linka z wiadomości 1 proces ma straszne zużycie procesora:

 

 

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

10895 [nazwa_resellera] 20 0 4112m 145m 932 S 233.6 1.9 9964:32 /usr/bin/host

 

Próbowałem szukać co to za komenda ale raz nic nie znalazłem a dwa, trochę boję się że coś zrobię nie tak.

 

Czy ktoś z forumowiczów spotkał się już z takim przypadkiem? Mam dostęp do całego serwera i mogę wyciągnąć co jest potrzebne tylko napiszcie proszę gdzie szukać.

 

Mam coraz częstsze sygnały że strony się wolno ładują.

Edytowano Czerwiec 13, 2016 przez Toxik (zobacz historię edycji)

[Gość]

To prawdopodobnie atak przez xmlrpc na wordpress'y, które masz na serwerze. Odpytywane jest za sprawą tego ataku mnóstwo domen i stąd problem.

 

Polecam zabezpieczyć wordpressy/strony, puścić je przez cloudflare i przede wszystkim znaleźć kogoś kto zerknie na to i poprawi co ewentualnie jest do poprawienia (na pewno coś jest).

Edytowano Czerwiec 13, 2016 przez Gość (zobacz historię edycji)

[Toxik 0]

Bardzo dziękuję za poradę!!! Naprawdę!! Super!

 

Faktycznie na serwerze u tego resellera były 3 konta na których stał Wordpress... żadne ważne strony... w sumie to zapomniane...

 

Włączyłem SSH i top - proces młóci procka...

Zaktualizowałem 3 Wordpressy...

Nie ma procesu... X)

 

Aktualnie system load average wynosi: 1.37, 1.55, 7.40

Tak więc bardzo dziękuję za nakierowanie i przypomnienie. Poważniejszym zabezpieczeniem tych Wordpressów zajmę się na spokojnie.

[Gość]

Przede wszystkim ogranicz dostęp do xmlrpc.

[SoundPlayer 10]

Mam chyba ten sam problem.

Strona co chwile pada a serwer aż czerwony.

W logach widzę IP które w ciągu 1 sekundy szuka 5 wpisów za pomocą wyszukiwarki.

Obecnie strona przekierowywuję do pliku instalacyjnego.

Czytałem też że WP wykonuje zadania Cron przy każdym wejściu na stronę więc to zmieniłem aby wykonywał co godzinę.

Fakt trochę pomogło na obciążenie lecz strona póki co leży i pokazuje plik install. ;/

[tb3.pl 11]

Mam chyba ten sam problem.

Strona co chwile pada a serwer aż czerwony.

W logach widzę IP które w ciągu 1 sekundy szuka 5 wpisów za pomocą wyszukiwarki.

Obecnie strona przekierowywuję do pliku instalacyjnego.

Czytałem też że WP wykonuje zadania Cron przy każdym wejściu na stronę więc to zmieniłem aby wykonywał co godzinę.

Fakt trochę pomogło na obciążenie lecz strona póki co leży i pokazuje plik install. ;/

 

Z przeciążenia nie powinien przekierowywać na install.php,

albo WP nie jest zainstalowany albo się wysypał - brakuje pliku konfiguracyjnego,

masz serwer dedykowany / vps / współdzielony?

[SoundPlayer 10]

Współdzielony. Plik Wp-config jest

[Toxik 0]

Niestety problem nadal występuje... nawet wywaliłem Wordpressy z serwera...

 

Rano dostałem maila z info o system load average > 10

Spakowałem wordpressy i usunąłem pliki żeby się przekonać czy coś to da ( chwilowy brak czasu na optymalizacje ).

Proces o tym samym id

 

10895 [nazwa_resellera] 20 0 4112m 145m 932 S 233.6 1.9 9964:32 /usr/bin/host

 

od rana szaleje i %CPU potrafi osiągać nawet 350

Jeszcze jakieś sugestie co może być przyczyną? Ten reseller ma już tylko strony na Prestashop... nic innego...

[hemi 20]

Atak na xmlrpc.php a atak przy użyciu /usr/bin/hosts to dwie różne rzeczy raczej niezwiązane ze sobą. Użycie ataku z hosts jest troche bardziej skomplikowane niż wykorzystanie podatności w xmlrpc.php bo wymaga zuploadowania na konto ofiary odpowiednio spreparowanych skryptów natomiast atak na xmlrpc wymaga tylko odpowiednio spreparowanych nagłówków i danych POST wysyłanych do serwera www.

 

Sugerowałbym przeskanować wszystkie pliki tego resellera. Prawdopodobnie któraś wtyczka jest dziurawa oraz atakujący był w stanie zuploadować jakieś malware.

Tutaj masz opis prawdopodobnego scenariusza: http://serverfault.com/questions/705217/usr-bin-host-executed-by-hacked-php-script

 

Może być tak, że żaden antywirus nie wykryje malware (sygnatury tego typu skryptów ciągle się zmieniają) tak więc prawdopodobnie trzeba będzie przeszukać pliki także pod kątem ostatnio modyfikowanych/dodanych plików w katalogu użytkownika.

[Misiek08 285]

Jeżeli atakujący nie dostał się za daleko to powinny pomóc access.log'i. Poszukaj w co jest "uderzany" ten użytkownik lub jaki IP odpytuje najczęściej. Powinieneś znaleźć gdzie leży syf.