Forum Debian Users Gang

w przypadku apacza masz kilka razy pokazaną tą samą pamięć (ot, takie uroki fork/thread).
mod_status włączony? co pokazuje?
w logach apacza nie widać jakichś zbyt długich zapytań?
nikt nie zrobił kuku przez dziurawego wordpressa/drupala/joomlę?

Zamiast Apacha radziłbym Nginxa z PHP-FPM, i do tego wszystkie procesy obciąć troszkę przez cgroup na twardo, i być może przez softlimit (pakiet daemontools) na miękko.

Ostatnio edytowany przez Jacekalex (2016-02-02 19:49:52)

nginx jako proxy dla apache zrobić.

ethanak napisał(-a):

w przypadku apacza masz kilka razy pokazaną tą samą pamięć (ot, takie uroki fork/thread).
mod_status włączony? co pokazuje?
w logach apacza nie widać jakichś zbyt długich zapytań?
nikt nie zrobił kuku przez dziurawego wordpressa/drupala/joomlę?

Dziękuję wszystkim za odpowiedzi . Przeglądając logi z apache error faktycznie dużo jest zapytań z wordpressa. Przeanalizuję to gdyż wcześniej było o połowę mniej ramu zużytego.

A można to gdzieś w logach odczytać ?? Teraz po wyłączeniu prawie wszystkich wtyczek dalej zarzyna ram .
W logach jest między inymi taki wpis co pare sekund

Ostatnio edytowany przez Gregorov (2016-02-02 23:06:39)

zablokuj ip 185.130.5.209 na firewallu, boty odowłuja sie do xmlrpc.php a pózniej radze poszukać wtyczki która to zabezpieczy albo w pliku .htaccess

woitekd napisał(-a):

zablokuj ip 185.130.5.209 na firewallu, boty odowłuja sie do xmlrpc.php a pózniej radze poszukać wtyczki która to zabezpieczy albo w pliku .htaccess

Przy miliionach dynamicznych adresów IP, banować po adresach?

Przyjemnej zabawy, możesz tak banować do usranej śmierci, aż w htacces albo w firewallu będziesz miał  2 mln wpisów z samego Orange. :D

Ostatnio edytowany przez Jacekalex (2016-02-02 23:21:11)

mati75 napisał(-a):

Ustaw allow dla tego pliku tylko z IP serwera i 127.0.0.1. Dla reszty: deny from all.

dla htaccess:

Kod:

<Files "xmlrpc.php">
Order Allow,Deny
Allow from 127.0.0.1
Allow from X.X.X.X
Deny from all
</Files>

Dziękuję Ci bardzo bo coś pomogło i nagle po zablokowaniu jak mówiłeś ram zużyty 300 mb :) (yupi) ... nie wiem jak mam dziękować człowiek ciągle się uczy :)

teraz wyglada tak:



może warto zblokować ten ip ??

Ostatnio edytowany przez Gregorov (2016-02-02 23:49:24)

Jacekalex napisał(-a):

Używasz modułu Xmlrpc do Wordpressa?

Jeśli nie, to zablokuj dostęp do  skrypta /xmlrpc.php na poziomie Apache lub Nginxa (jeśli połączenie idzie przez Nginxa) - żeby zwracał odpowiedź 403 lub 404 najlepiej, natychmiast, bo to na 99.9% próba włamania do WP.

Ja tylko dodam, że by nie stosować 404, bo google bardzo nie lubi tego kodu. xD

No i te nowsze apacze mają nieco inna składnie, przykładowo:

<Files "xmlrpc.php">
        Require all denied
        Require ip 127. 192.168.
</Files>

Jak dobrze pamiętam to dzięki temu modułowi można wykonywać ataki na inne serwry. Kiedyś pisali chyba o tym na nie bezpieczniku.

2657

Ostatnio edytowany przez uzytkownikubunt (2016-12-01 01:33:18)

Jacekalex napisał(-a):

Ja tylko dodam, że by nie stosować 404, bo google bardzo nie lubi tego kodu. xD

A co ma google do interfejsu komunikacyjnego xmlrpc w WP?

No google weryfikuje strukturę strony. W nagłówku masz info o tym pliku, no i jak ten twój WP zwróci 404, to google da mu w łeb i obniży rating strony. No bo co to za serwis gdzie brakuje plików? xD Tak czy inaczej w WP można te mechanizmy powyłączać, tak by nie były uwzględniane w nagłówku. Plików też raczej bym nie usuwał (czy nie dawał 404) tylko odmawiał dostępu. Ten ktoś i tak nie uzyska dostępu do tego pliku, a po co dodatkowo drażnić googla? xD