WordPress - optymalizacja i bezpieczeństwo

[Lokator 137]

Jakie Waszym zdaniem są najlepsze wtyczki odpowiadające za optymalizacje i bezpieczeństwo Wordpressa?

[PapaSmerf 497]

1. Optymalizacja -> im mniej wtyczek, tym lepiej - spora część wtyczek, to po prostu gówno jakich mało, pod kątem jakości kodu (sam WP też jest nielepszy)

2. Bezpieczeństwo -> jw. Wytnij sobie niepotrzebne żądania po stronie serwera, ogranicz dostęp do katalogu /wp-admin/ i już. Żadnych wtyczek nie potrzebujesz.

[bybunny 540]

Jakie Waszym zdaniem są najlepsze wtyczki odpowiadające za optymalizacje i bezpieczeństwo Wordpressa?

 

Hej!

 

Bardzo ogólnie zadałeś pytanie więc kwestia optymalizacji stron opartych na WordPress ,którą poruszyłeś rozpatrywana pod tak dużym kontem nie wyznaczy jasnego kierunku.

 

Bezpieczeństwo natomiast jest łatwiejszym zagadnieniem pod względem odpowiedzi i głównie ma wpływ kilka podstawowych elementów:

 

1. Usługa hostingowa i sposób w jaki jest zabezpieczona

2. Narzędzia dostarczone przez usługodawcę do obsługi WordPress

3. Źródło elementów wykorzystanych na stronie - skórki, moduły

4. Dbałość o aktualizacje

 

To główne cztery elementy na które warto zawsze zwracać uwagę.

 

[Lokator 137]

Wymieniliście podstawowe zasady, i bardzo się z tego cieszę, ale chodziło mi o konkretne wtyczki.

Różnie ludzie piszą, różne mają opinie - chciałbym poznać Wasze opinie odnośnie konkretnych wtyczek.

 

Jakie macie z nimi doświadczenia, które są Waszym zdaniem najlepsze - priorytet: bezpieczeństwo, szybkość funkcjonowania, oszczędność zasobów serwera.

[bybunny 540]

Wymieniliście podstawowe zasady, i bardzo się z tego cieszę, ale chodziło mi o konkretne wtyczki.

Różnie ludzie piszą, różne mają opinie - chciałbym poznać Wasze opinie odnośnie konkretnych wtyczek.

 

Jakie macie z nimi doświadczenia, które są Waszym zdaniem najlepsze - priorytet: bezpieczeństwo, szybkość funkcjonowania, oszczędność zasobów serwera.

 

Podaj konkretne wtyczki jakie ciebie interesują to na pewno znajdzie się kilka osób ,które miały z nimi coś do czynienia i opisze swoje spostrzeżenia. Inaczej rozpatrywanie takiego zagadnienia jak bezpieczeństwo i optymalizacja biorąc pod uwagę ilość elementów odpowiedzialnych za nie jest po prostu niemożliwa i zasługuje co najmniej na treść pokaźnej książki lub odpowiednika w postaci odpowiedzi na samej stronie wordpress.org.

 

[PapaSmerf 497]

Wymieniliście podstawowe zasady, i bardzo się z tego cieszę, ale chodziło mi o konkretne wtyczki.

Różnie ludzie piszą, różne mają opinie - chciałbym poznać Wasze opinie odnośnie konkretnych wtyczek.

 

Jakie macie z nimi doświadczenia, które są Waszym zdaniem najlepsze - priorytet: bezpieczeństwo, szybkość funkcjonowania, oszczędność zasobów serwera.

 

To nie są podstawowe zasady, to są dobre praktyki.

 

Pomyśl... co Ci wytnie niechciane requesty szybciej: konfiguracja po stronie serwera, czy PHP? Co bardziej zabezpieczy dostęp do /wp-admin? Regułka na serwerze czy PHP?

 

Wordpress sam w sobie nie jest ani wolny, ale też nie szybki. Im więcej napakujesz zbędnych wtyczek, tym wszystko będzie:

a) wolniejsze

b) mniej bezpieczne.

 

Instaluj tylko to, co jest Ci niezbędne i wycinaj wszelkie niepotrzebne requesty do WP - nic innego nie potrzebujesz.

[Lokator 137]

Źle to ująłem, poprawiłeś mnie - dobre praktyki.

 

Dzięki za podpowiedzi ; )

[Pan Kot 1535]

Jeśli chodzi o bezpieczeństwo od strony Linuxa, czyli VPS/Dedyk, to jest to przede wszystkim to co opisałem w poradniku dot. bezpieczeństwa na debianie.

 

Poza tym, stricte hostingowe rzeczy:

1. Nginx. Nic lepiej nie handluje DoSów na ogromną skalę czy skomplikowanych requestów. Odpowiednio skonfigurowany jest w stanie wycinać requesty zanim w ogóle dotrą one do PHP, niczego szybszego nie ma, oprócz kernelowych regułek iptables.

2. PHP-FPM. Każdy pool musi działać z uprawnieniami użytkownika, najlepiej w chroocie, ale jeśli nie jest to możliwe to w dużej części przypadków wystarczy dobrze skonfigurowany open_basedir. Warto również wyłączyć wszystkie phpkowe funkcje, których nie potrzebujesz, czym ich masz mniej tym lepiej, honorowe przykłady to exec() oraz system().

3. Access. Warto zauważyć, że po zastosowaniu się do powyższych przykładów możemy ograniczyć chmody ze standardowych na 600 dla plików PHP oraz 711 dla folderów. Jeśli nie potrzebujemy ich modyfikować, jeszcze lepiej ustawić je na 400 oraz 511. Dzięki temu tylko php-fpm działający z aktualnego użytkownika będzie w stanie przeczytać pliki .php, a nginx nawet jeśli jakimś cudem wskutek złej konfiguracji spróbuje zwrócić ten plik userowi, to nie będzie w stanie go odczytać. Zabezpieczenie przed zapisem dodatkowo cię chroni przed ew. robakami, które będą chciały coś dopisać do skryptów .php. Przydaje się jeśli nie zamierzasz pozwalać na modyfikację pliku z poziomu usera.

4. Limity. Nginx ma świetny limit requestów na IP, limit_conn_zone, wystarczy się zainteresować i większość DoSów będzie skutecznie odbijała się od nginxa, nawet nie budząc php. Co więcej, to świetnie działa z modułem nginxowym odpowiedzialnym za translację adresów IP CloudFlare na realne adresy IP, przez co nie wytniemy przypadkowo CFa, a konkretnego użytkownika, który nam spamuje stronę.

5. CloudFlare. Oferuje masę opcji zabezpieczających, przez co większość ataków odbije się od ich infrastruktury, a nie od naszego nginxa.

6. Anty-bruteforce. Zawsze do każdych zasobów przeznaczonych tylko dla admina (np. /phpmyadmin, /wp-admin) dokładam najprostszy basic_auth na poziomie nginxa. A to dlatego, że fail2ban obsługuje nginxowy http auth, przez co jesteśmy w stanie wyciąć wszelkie próby bruteforce'a po pierwsze, przed php, po drugie, w sposób efektywny (nginx loguje złe próby, fail2ban je wykrywa i odcina IP na poziomie kernela). Jest to o wiele bardziej efektywne niż jakiś pseudo plugin do WP realizujący podobną funkcję, i nie obciąża już i tak wolnego i zajętego PHP-FPM.

7. Quota. Możesz mieć sytuację, w której twoi użytkownicy mogą np. wrzucać pliki na serwer (avatary chociażby). Jeśli nie chcesz zajechać sobie całego dysku to warto się zainteresować albo natywną quotą, która istnieje we wszystkich popularnych filesystemach, albo podmontowaniem pod konkretne foldery chociażby fizycznego pliku. Tą metodę również opisałem w poradniku, chociaż zwyczajna quota działa po prostu lepiej, szybciej, i nie zajmuje miejsca, więc plikową quotę polecam tylko w ekstremalnych przypadkach, i najlepiej dla niewielkiego miejsca.

Edytowano Marzec 21, 2015 przez Archi (zobacz historię edycji)

[Gość Spoofy]

Jak dla mnie to można dużo podziałać z "optymalizacją" z poziomu php'a. Pod względem bezpieczeństwa również.

Archi - fail2ban jako prymitywny parser logów nie sprawdza się tak dobrze jak np. porządny IPS który będzie robić to lepiej - również na poziomie kernel'a (nfqueue). Parsowanie logów zostawiłbym np. ossec'owi który wyłapuje regułki modsec'a i podejmuje konkretną akcję (nie zawsze zwykłe wycięcie na ipt). Co do "chmodów" (czyt. uprawnień) to jak już jest tam coś "gmerane" to ustawiłbym inny umask.

Lokator - Na pw poszło kilka wskazówek.

Pozdrawiam.

Edytowano Marzec 21, 2015 przez Spoofy (zobacz historię edycji)

[Vasthi 74]

@Archi to co napisałeś to bardzo dobry poradnik tylko na poziomie systemu/administratora a on potrzebuje pewnie optymalizacji wp ponieważ pewnie jego serwerownia męczy że za bardzo obciążą serwer. To chyba że jest właścicielem jakiegoś VPS/Dedyka to Twoje rady są jak najbardziej na miejscu.

 

Wracając do tematu to ja bym polecił jakiś dobry cache i właściwie tyle możesz zrobić po stronie samego wp.

[Lokator 137]

Dziękuje wszystkim użytkownikom za wsparcie i wskazówki : )

[Pan Kot 1535]

Jak dla mnie to można dużo podziałać z "optymalizacją" z poziomu php'a. Pod względem bezpieczeństwa również.

 

Archi - fail2ban jako prymitywny parser logów nie sprawdza się tak dobrze jak np. porządny IPS który będzie robić to lepiej - również na poziomie kernel'a (nfqueue). Parsowanie logów zostawiłbym np. ossec'owi który wyłapuje regułki modsec'a i podejmuje konkretną akcję (nie zawsze zwykłe wycięcie na ipt). Co do "chmodów" (czyt. uprawnień) to jak już jest tam coś "gmerane" to ustawiłbym inny umask.

 

Lokator - Na pw poszło kilka wskazówek.

 

Pozdrawiam.

 

Fail2ban sprawdza się ZNAKOMICIE, jeśli umie się z niego korzystać i pisać dobre regułki. Jeśli ktoś instaluje i nawet nie zainteresuje się tym co oferuje, tylko jedzie na defaultach po apt-get install to powinien mocno się zastanowić co on w ogóle robi. Nie znalazłem żadnego dobrego parsera logów nginxa, a apache'a tak nie znoszę za jego mułowatość, że nigdzie go już nawet nie używam. Umask nie zawsze się sprawdzi - przykładowo w sprawie ww. avatarów - chcemy, żeby były writable, ale nie chcemy żeby writable były skrypty php wordpressa. Widzisz problem?

 

Po stronie kernela od zawsze polecam, i będę polecał grsecurity. Niczego lepszego nikt nie wymyślił, a kernel to pierwsza rzecz, która handluje wszystkie nadlatujące requesty, więc takie jak rzeczy jak grsecowy blackholing jest w stanie porządnie obronić się przed DDoSem nie zajeżdzając CPU na 100%. IPS/IDSy fajnie wyglądają na papierku, ale od strony praktycznej już nieco gorzej wypadają. Jeśli chcesz to zrobić dobrze to nie możesz się ograniczać do tego co oferuje skrypt PHP, ani IPSa, który nie umie odczytać wszystkich usług, z których korzystasz, tylko instalujesz fail2bana, piszesz porządne regułki, i wszystko działa 200% lepiej niż jakikolwiek IPS.

 

@Archi to co napisałeś to bardzo dobry poradnik tylko na poziomie systemu/administratora a on potrzebuje pewnie optymalizacji wp ponieważ pewnie jego serwerownia męczy że za bardzo obciążą serwer. To chyba że jest właścicielem jakiegoś VPS/Dedyka to Twoje rady są jak najbardziej na miejscu.

 

Wracając do tematu to ja bym polecił jakiś dobry cache i właściwie tyle możesz zrobić po stronie samego wp.

 

No właśnie - "właściwie tyle". Basic auth na /wp-admin to podstawa, a jeśli ktoś myśli poważnie o bezpieczeństwie/optymalizacji swoich zabawek to raczej z góry zakładam, że robi to na VPSie, bo na sharedzie to można co najwyżej maila do supportu wysłać i wręczyć kopertę z dolarami.

Edytowano Marzec 25, 2015 przez Archi (zobacz historię edycji)

[Gość Spoofy]

 

Fail2ban sprawdza się ZNAKOMICIE, jeśli umie się z niego korzystać i pisać dobre regułki. Jeśli ktoś instaluje i nawet nie zainteresuje się tym co oferuje, tylko jedzie na defaultach po apt-get install to powinien mocno się zastanowić co on w ogóle robi. Nie znalazłem żadnego dobrego parsera logów nginxa, a apache'a tak nie znoszę za jego mułowatość, że nigdzie go już nawet nie używam. Umask nie zawsze się sprawdzi - przykładowo w sprawie ww. avatarów - chcemy, żeby były writable, ale nie chcemy żeby writable były skrypty php wordpressa. Widzisz problem?

 

Po stronie kernela od zawsze polecam, i będę polecał grsecurity. Niczego lepszego nikt nie wymyślił, a kernel to pierwsza rzecz, która handluje wszystkie nadlatujące requesty, więc takie jak rzeczy jak grsecowy blackholing jest w stanie porządnie obronić się przed DDoSem nie zajeżdzając CPU na 100%. IPS/IDSy fajnie wyglądają na papierku, ale od strony praktycznej już nieco gorzej wypadają. Jeśli chcesz to zrobić dobrze to nie możesz się ograniczać do tego co oferuje skrypt PHP, ani IPSa, który nie umie odczytać wszystkich usług, z których korzystasz, tylko instalujesz fail2bana, piszesz porządne regułki, i wszystko działa 200% lepiej niż jakikolwiek IPS.

 

 

No właśnie - "właściwie tyle". Basic auth na /wp-admin to podstawa, a jeśli ktoś myśli poważnie o bezpieczeństwie/optymalizacji swoich zabawek to raczej z góry zakładam, że robi to na VPSie, bo na sharedzie to można co najwyżej maila do supportu wysłać i wręczyć kopertę z dolarami.

 

Czy Ty uważasz że oceniam "pochopnie" dane narzędzie nie zagłębiając się w jego konfigurację? Sensowna dyskusja nie miałaby sensu...

 

Fail2ban to zwykły parser logów i niezależnie od tego w jaki sposób napiszesz sobie "regułki" do niego - on tylko będzie dalej czytać logi i orać dysk zupełnie niepotrzebnie. Jeżeli chcesz blokować dane requesty to ustawiasz to albo po stronie serwera www (zanim to zaloguje i biedny parser wyczyta to z logów) albo np. po stronie IPS'a. Jeżeli chodzi o "malware detection" to istnieje pierdyliard lepszych narzędzi. Zarówno apache, nginx jak i litespeed wspierają mod'sec'a - i po tej stronie należy pisać regułki jeżeli myślimy o jakiejkolwiek wydajności czy chociażby blokowaniu bruteforce'a. Często przy dużym ruchu fail2ban zadziała o wiele za późno zanim przeora logi.

 

Grsec to podstawa i tego nie musisz przytaczać za każdym razem kiedy mowa o bezpieczeństwie, lecz są tam też opcje do np. blokowania "wyjścia" z chroot'a które średnio się przydają w dzisiejszych czasach.

Niewiem z jakich IPS'ów korzystałeś ale jeżeli twierdzisz że fail2ban jest lepszy no to niestety śmiem wątpić w Twoją wiedzę na ten temat, gdyż ich wydajność i skuteczność jest nieporównywalnie większa niż fail2ban. Tym bardziej stwierdzenie że IPS "nie umie odczytać wszystkich usług z których korzystasz" świadczy o tym że zwyczajnie ich nie konfigurowałeś odpowiednio, tak jak swojego fail2bana. Jeżeli szukasz lepszego parser'a logów to polecam zgłębić ten temat.

 

A niektóre działają nawet out-of-the-box, bez dogłębnej konfiguracji ;-)

[nolimits 0]

Witam

 

Podczepię się pod temat.

 

Czy skórki z themeforest czy industrialthemes.com są bezpieczne ? Czy kupując takie kombajny (np te dla magazynów) mogę czuć sie bezpiecznie ? Czy potrzeba do tego mocnego serwera ? Na pierwszy rzut oka multum opcji przeraża.

 

Czy aby te wszystkie bajery działały to muszę instalować multum - nie wiadomo jakich wtyczek ??

 

Wydaję mi się że to wszystko wcale nie wpływa na szybkość działania strony a tym bardziej na optymalizację i bezpieczenstwo

 

 

Jakie są wasze doświadczenia ?

 

Ps zapytam przy okazji. Czy linki w stopce na tym forum są dofollow ?

[protoplasta 25]

Kupowalem tam skiny od wielu osob, ostatnio biore od jednego wydawcy i kazdy nowy skin zre zasoby coraz bardziej, przez nich musialem dedyka kupic, ale sie tlumacza ze wedlug ich nowszy skin jest szybszy niz stary. Wiec to wszystko zalezy od tworcy.

Edytowano Marzec 28, 2015 przez protoplasta (zobacz historię edycji)

[PapaSmerf 497]

@nolimits - z WP na serwerze nigdy nie możesz czuć się bezpiecznie.

[nolimits 0]

Kupowalem tam skiny od wielu osob, ostatnio biore od jednego wydawcy i kazdy nowy skin zre zasoby coraz bardziej, przez nich musialem dedyka kupic, ale sie tlumacza ze wedlug ich nowszy skin jest szybszy niz stary. Wiec to wszystko zalezy od tworcy.

 

od kogo kupujesz?

 

Możesz podać przykłady tych stron tutaj albo na pw ?

 

Duży ruch masz na tych stronach że dedyka trzeba brać ?

[bybunny 540]

Kupowalem tam skiny od wielu osob, ostatnio biore od jednego wydawcy i kazdy nowy skin zre zasoby coraz bardziej, przez nich musialem dedyka kupic, ale sie tlumacza ze wedlug ich nowszy skin jest szybszy niz stary. Wiec to wszystko zalezy od tworcy.

 

....zmień "wydawcę" ,oddaj dedyka , kup zwyczajny hosting

w temacie bezpieczeństwa: http://sixwishlist.com/wordpress-security/

Edytowano Marzec 28, 2015 przez SiXwishlist (zobacz historię edycji)

[protoplasta 25]

IndustrialThemes, adresu podawac nie bede bo nie ma po co, z cache to jakos dziala ale w3 tutaj nie starcza. Hostingu zwyklego brac nie bede bo nie uciagnie takiego ruchu jaki mam na stronie, styl wczesniej wszystko smigalo ladnie na jakims tanim vpsie, ktory bez problemow uciagal 1k osob online, a teraz strona na tym stylu nawet na czystym wp kilka sekund sie laduje. Czasami jak sie cache wywali to load rosnie do ponad 23 i jest smiesznie a tak to nie przekracza 2. Szkoda ze nie ma czegos takiego jak okres testowy, a tak to wyda sie hajs i sie mecz. Jak ktos bedzie robil rownie dobre style to zmienie wydawce. Z reguly te kombajny szybko chodza ale jak widac nie wszystkie.

[Vasthi 74]

Może masz jakoś źle skonfigurowany serwer webowy lub jakiś plugin mieli PHP. Spróbuj przejść na nginxa lub chociaż zrobić proxy dla Apache.

[protoplasta 25]

Mam nginxa i wiem co robie, po prostu styl jest dupnie zrobiony.

[blfr 225]

Przyjrzyj się temu stylowi. Dlaczego jest dupny?

 

Bardzo wiele małych plików? Może da się je połączyć?

 

Może napiszesz o swoich problem z wydajnością autorowi i się trochę podciągnie?

 

A w ogóle, podaj adres tego bloga.

[protoplasta 25]

Jest dupny poniewaz za kazdym razem meczy baze dziwnymi zapytaniami i czasami robia sie petle ale po wylaczeniu niektorych opcji jest nieco lepiej. Czasami w kilka minut transfer wewnetrzny miedzy php a mysql potrafi osiagnac 50gb. Autorowi z tego powodu tak trulem dupe ze ma mnie chyba dosc a i tak do niczego nie doszlismy. Nie mam po co podawac bo z zewnatrz nic nie widac.

[blfr 225]

Theme męczy bazę? To może zastosuj cache dla cięższych stron?

[bybunny 540]

Jest dupny poniewaz za kazdym razem meczy baze dziwnymi zapytaniami i czasami robia sie petle ale po wylaczeniu niektorych opcji jest nieco lepiej. Czasami w kilka minut transfer wewnetrzny miedzy php a mysql potrafi osiagnac 50gb. Autorowi z tego powodu tak trulem dupe ze ma mnie chyba dosc a i tak do niczego nie doszlismy. Nie mam po co podawac bo z zewnatrz nic nie widac.

 

Theme męczy bazę? To może zastosuj cache dla cięższych stron?

 

Dobre pytanie a na 100% problem leży w modułach które są wykorzystywane by mieć wodotryski na stronie. Theme to pliki to nakładka więc sorry ale warto się zastanowić co powoduje takie obciążenie. Samo theme przy odpowiednim dopalaczu po stronie serwera zostanie wywołane w 1s w całości . Począwszy od najprostszych zabawek jak PageSpeed w formie modułu a skończywszy na bardziej obszernych tematach pod cache. Twierdze że to co napisałeś jest po prostu bzdurą a pokazanie strony w formie adresu to potwierdzi bo od razu będzie widać ilość modułów i wyskakujących elementów + jak znam życie całą masę śmieci.