Forum Debian Users Gang

Ok, na przyszłość dam dla skrypta xmlrpc.php taki myk:

# To w Nginxie
return 301 https://www.google.com/?q=xmlrpc.php;

i niech sobie Googleboot poczyta conieco. :D

EDIT:
Co Wam przypomina, co Wam przypomina, widok, znajomy ten:
https://niebezpiecznik.pl/post/trwaja-ataki-ddos-wy … zyty-w-ataku/

:D

Ostatnio edytowany przez Jacekalex (2016-02-03 18:33:56)

Wordpress i joomla to kopalnia błędów i dziur.

2665

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

Tak. Najlepiej zmienić wp-login na coś innego, są pluginy do tego.

Ostatnio edytowany przez mati75 (2016-02-09 21:25:05)

Z tą zmianą nazwy to mogą być problemy przy aktualizacji wordpressa. Lepiej ten plik, jak i cały panel admina schować w taki sam sposób jak ten plik xmlrpc. Zostawić tylko furtkę dla poszczególnych osób, a całą resztę przekierować na stronę główną. xD

ethanak napisał(-a):

może ktoś ma jakiś prosty sposób na zrobienie tego na Apaczu/Nginksie?

nginx da się łatwo z geoip powiązać.

tudzież wystawić przed apacza haproxy/varnisha. Zaglądnąć do mana i ustawić reqlimit - nie trzeba ci wtedy fw do tego zaprzęgać (bo jak tak zaczniesz na pałę blokować poszczególne ipki to w niedługim czasie fw się rozrośnie do kosmicznych rozmiarów i strona zacznie mulić bo system będzie wykorzystywał znaczną część zasobów do sprawdzania reguł). Nie wyważać otwartych drzwi. HAProxy ładnie terminuje SSLe, do tego może rzeźbić w nagłówkach/ciastkach etc jak ktoś potrzebuje, a varnish da kopa i to dużo większego jak opcache + memcached razem wzięte ;)

Skomplikowana sprawa stawianie za VPNem . Znacie jakieś tutoriale w tym temacie ?? Chyba to mnie jeszcze przerasta.

Dziekuje za odpowiedz ponizej :)

Ostatnio edytowany przez Gregorov (2016-02-10 22:14:02)

Jeśli masz wordpressa i własny serwer vps lub dedyka polecam 3 wtyczki do instalacji i konfiguracji

1. All In One Wp Security - łata ewentualne, potencjalne dziury w WP, blokuje także xmlrpc
2. W3 Total Cache - praktycznie wszystko w jednym co może wpłynąć na poprawę szybkości ładowania strony jak cache, gzip, kompresja html, js, css itp.
3. WP Fail2Ban - blokuje potencjalnych hakierów naszego WP

Do tego można jeszcze dołożyć Antispam Bee do walki ze spamerami, którzy zarzynają nam serwer oraz CloudFlare będący swoistym serwerem CDN ale posiadający dodatkowo wiele ciekawych funkcji, także za free.

Teraz trochę odnośnie waszych propozycji, jak Varnish, NgiNX, APC itp. to niestety nie zawsze wdrożenie ich będzie najlepszą możliwością i niestety nie zawsze jest to możliwe.

Po cholerę komu Varnish na przykład jak 99% jego stron łączy się po https (mamy darmowego Lets n Crypt przeciez oraz Http/2 który wymaga połączeń szyfrowanych)? Nie masz stron szyfrowanych? a pewny jesteś że za kilka miesięcy nie będziesz ich miał? Tym bardziej że wiele instytucji ciśnie w tym kierunku jak np. Google? Varnish niestety nie obsługuje połączeń szyfrowanych (przez ssl).

Nginx szybszy niż Apache?, hmm być może, tylko że mój Apache po tuningu z wykorzystaniem PHP-FPM wcale nie jest mniej wydajny niż NGiX, a jak zauważyłem czasem szybszy, więc da się go odpowiednio dopieścić, testowane na żywym działającym serwerze. Zresztą Apache to nie tylko .htaccess, którego brak czasem utrudnia życie, szczególnie na serwerach firmowych gdzie nikogo nie obchodzi, że coś może być ciężkie do wdrożenia bo brak .htaccess :) Do tego dla Apache mamy takie przydatne często moduły jak mod-qos, mod-evasive, mod-spamhause itp.

Memcache? No niestety ale jak do tej pory w PHP7 jest bida z nim, a który to sam w sobie jest szybszy i zabiera mniej zasobów niż taki PHP5.6 chociażby i warto na niego przejść w wielu przypadkach. Mamy za to w standardzie OPcache w PHP7 :)

Jak dla mnie to Varnish, NgiNX, Memcache (Xcache, APCitp.) to jedynie opcja, a nie konieczność, na którą warto tylko czasem, w specyficznych warunkach przejść. Często poznanie dokładnej struktury swojego serwera i optymalizacja tego co da się zoptymalizować bez wpływu na komfort korzystania z jego zasobów przynosi zamierzone rezultaty samo w sobie.

Zresztą znam strony, których czas ładowania się jest 2 razy dłuższy niż moich stron mimo, że stoją dokładnie na tym samym skrypcie (WP) mają 3 x mniej działających pluginów, stoją na dedyku (moje na VPS), mają jako serwer właśnie NgiNX (moje są serwowane przez Apache) i wiele więcej co wbrew obiegowym opiniom powinno działać na ich korzyść. Jak widać sama zmiana oprogramowania na często polecane, nie jest cudownym lekiem na ból d..py jakim jest brak zasobów serwera www :]

Tak na marginesie to mod-pagespeed, o którym ktoś tu już wspomniał także polecam jednak z jednym ale ... że dostosujesz jego konfiguracje do własnego serwera i specyfiki stron. Opcje konfiguracyjne s bardzo dobrze opisane na stronach Google. Malo kto pewnie wie ale moduł ten pozwala np. na włączenie tzw. Lazy Load dla grafiki, Minify dla html, css, JS, remove Query String i wiele więcej. Niektóre z tych opcji warto włączyć, a które są standardowo wyłączone, jednak jak wspominałem zależy to ściśle od specyfiki naszego serwera, a także stron jakie są tam hostowane.

Jasne że można, tak samo można kombinować z Revers Proxy, czyli NgiNX + Apache (jeden jako serwer właściwy, a drugi jako odwrotne proxy) ale to już pewna kombinacja - zmiana portów w configach, ewentualne kombinacje z panelami www, które takie zmienione porty powinny obsłuzyć itp. Osobiście jestem za jak najprostszymi rozwiązaniami, bo fajnie jak wszystko działa, a gorzej jak zaczyna się pi..ć np. po którejś pięknej aktualizacji pakietów na naszym serwerze lub taki cache się wysypie i zacznie serwować śmieci zamiast stron.

Taką sytuację miałem ostatnio po aktualizacji apache właśnie, gdzie nadpisała mi cały plik konfiguracyjny do standardowego, bez pytania i przestało wyświetlać mi strony :] Po przywróceniu pliku wszystko wróciło do normy ale nie zawsze problem jest szybki do namierzenia i prosty do rozwiązania niestety. Kto z was robi kopie jakichkolwiek plików konfiguracyjnych na serwerze? Kto robi wszystkich usług? bo wczoraj był to Apache, jutro może być NgiNX, Varnish lub cokolwiek innego z konfigami systemowymi włącznie. Dołóż do tego siłę wyższą w postaci szefa w firmie, którego najczęściej nic nie obchodzi poza tym że ma działać i to już w tej chwili i ciśnienie jakie to u ciebie wywoła :p Czym więcej dodatkowych kombinacji tym potem trudniej to wszystko przywrócić do poprawnego działania jednym słowem.

Tak jeszcze odnośnie samego Varnisha i Nginx to są sytuacje w których faktycznie znajdą zastosowanie i nie zaprzeczam temu ?(sam czasami korzystam) ale trochę mnie drażni podawanie tej konfiguracji zawsze na tzw. ból du...y jako lek na cale zło. Tutaj taki dość ciekawy test znaleziony w internecie http://blog.cyryl.net/2011/03/apache-vs-nginx-porownanie-wydajnosci/

dziwnym trafem także większość testów opiewających NgiNX robione jest w oparciu o PHP-FPM w porównaniu z Apache 2.2 i mod_php i w oparciu o dane statyczne. Przecież to jawny wał jest :) Dlaczego nie zrobić testu w oparciu o php-fpm jednego i drugiego serwera i to zarówno o dane dynamiczne jak i statyczne właśnie, zarówno dla małych serwerów VPS jak i wielkich serwerów dedykowanych, no ale tutaj już korzyści nie wypadają tak różowo prawda? Tym bardziej, że większość obecnie serwowanych danych to jednak dane dynamiczne :)