Piszki Lab

Analiza przypadku w języku przodków…

Migracja do CloudFlare i inne aspekty bezpieczeństwa WordPressa

| 0 comments

Po przeczytaniu kilku artykułów, i zgodnie z radą Wojcieha, postanowiłem migrować mojego WordPressa do CloudFlare. Czemu używam sformułowania “migracja”? Czym tak naprawdę jest Content Delivery Network? CDN jest czymś w rodzaju globalnego proxy, dodatkowo rozproszonego po świecie. Synchronizując naszą wtyczkę W3 Total Cache z CloudFlare (CDN), tak naprawdę przygotowujemy statyczne strony które są przekazywane na serwery CloudFlare i stamtąd serwowane końcowym użytkownikom bloga. Stąd słowo “migracja”, chodź oczywiście jest to sformułowanie na wyrost, obowiązuje ciągle czas wygasania strony tymczasowej, zgodny z ustawieniami w naszym WordPressie. Zaletą tego rozwiązania jest przyśpieszenie ładowania strony www jako takiej i odciążenie serwera głównego (co dla mojego NASa ma gigantyczne znaczenie). Dodatkowo CloudFlare zapewnia (w darmowej wersji) pewien minimalny poziom bezpieczeństwa. Dodają oni automatycznie kody captcha do strony gdy pobierający ją adres znajduje się na liście znanych botnetów, spamerów, etc.

A jak wygląda konfiguracja całości? Należy być przygotowanym na pełną rekonfigurację swojego serwera DNS. CloudFlare obsłuży tylko domeny wyższego rzędu (*.*) i wymaga przeniesienia rekordów na własne serwery DNS. W trakcie konfiguracji rekordów wybieramy które adresy idą “przez” CloudFlare a które “pomimo”. Można to też w każdej chwili zmienić, czyli włączyć lub wyłączyć dostęp do naszej strony poprzez CDN!

cloudflare1

Konfiguracja wtyczki W3 Total Cache jest bardzo prosta, sprowadza się do podania loginu i przydzielonego nam API Key. Ważną informacją jest też to, że CloudFlare integruje się z Google Analitics i Google Webmaster Tools. Dzięki czemu nadal będzie naliczana pełna statystyka odwiedzin naszej strony a samo Google będzie traktowało naszą stronę i cache w CDN jako jedno. Można też włączyć “integrację” naszej usługi ze stroną blitz.io (o której wspominałem w pierwszej części cyklu), co de facto, daje nam nowe konto z możliwością wykonania kolejnych 10 darmowych testów. I teraz pytanie, czy to rzeczywiście działa?

cr1

Jak widać działa całkiem dobrze, dodatkowo mamy wgląd w ciekawą statystykę, widzimy ile procent ruchu to aktywność botów wyszukiwarek. Takiej statystyki nie wyciągniemy z webmaster tools, wyszukiwarek w których się zarejestrowaliśmy!

cr2

A teraz kwestie bezpieczeństwa. Ostatnio ze zdziwieniem zauważyłem próby ataku typu brute force na stronę wp-login. Jako że strona ta nie idzie z cache, jej każdorazowe odczytanie powoduje spore obciążenie DS213J. Jeśli chcemy uchronić się przed takimi atakami (za darmo), możemy zainstalować dwa pluginy do WordPressa. Jeden to BruteProtect a drugi to Limit Login Attempts. BruteProtect to jedna z wielu sieci zbierająca i integrująca informacje na temat znanych adresów IP z których następują ataki. Takie adresy są automatycznie blokowane. Limit Login Attempts to proste rozwiązanie które wrzuca do lokalnej black listy adresy IP z których nastąpiły próby logowania. Ilość prób, czasy przebywania na black liście są w pełni konfigurowalne. Ma też jedną ważną cechę, potrafi powiadomić administratora serwisu, że coś się dzieje!

bp

Jeśli mimo to męczą nas ataki, a jesteśmy np. jedynym użytkownikiem serwisu i nie przewidujemy rejestrowania się nowych użytkowników, możemy zastosować blokadę ostateczną. Do definicji wirtualnego serwera Apache2 (jeśli używacie Ngixa to zajrzyjcie tu) dodajemy następujące wpisy (/usr/syno/etc/httpd-vhost.conf-user):

<Files wp-login.php>
AuthUserFile /usr/syno/apache/passwd/pass
AuthName AB
AuthType Basic
require user ppisz
</Files>

Następnie zakładamy pliczek /usr/syno/apache/passwd/pass (Synology rekomenduje przechowywanie pliku poza katalogiem głównym strony www), zawierający login i hash hasła. Wejście na tak zabezpieczoną stronę spowoduje wyświetlenie stosownego komunikatu:

ar

Co ważne, parser PHP nie bierze w tym udziału, dzięki czemu nie powoduje spadku wydajności całej maszyny. Należy tylko pamiętać, że plik httpd-vhost.conf-user jest w Synology generowany automatycznie, wszelkie zmiany z poziomu interfejsu w wirtualnych hostach spowodują jego nadpisanie. I to w zasadzie tyle w tym momencie, jeśli coś wiecie więcej to chętnie wysłucham każdej rady! Uśmiech

Edit 2014.04.15:

Kolejnym problemem który napotkałem, to masowe zakładanie kont na blogu (mimo włączonej captchy) przez spam-userów. Wstaję sobie rano i widzę emaila, że na blogu założono dwa nowe konta, poleciały komentarze. Na szczęście wspaniała wtyczka, Akismet, czuwa i blokuje spam. Ale jak pozbyć się spam userów? Odpowiedzią na to okazała się kolejna wtyczka: SABRE. Cudowne narzędzie, wprowadza kolejne restrykcje przy zakładaniu konta, bardziej inteligentna captcha oraz sprawdzanie czy dany IP nie jest na liście znanych boot-netów. Od jej uruchomienia nie pojawił się ani jeden nowy spam-user i mogłem włączyć komentowanie wpisów dla nie zalogowanych użytkowników! Super :)

I kolejny mini problem który nazywa się semalt.com, mam pod opieką taką małą wizytówkę lokalnej firmy, gro wejść to „miejscowi”. Plust gigantyczny ruch ze strony (podono analitycznej) semalt.com. Na szczęście można się z semalt.com wypisać na dwa sposoby :)

Oceń ten artykuł:
[Głosów:2    Średnia:5/5]

Dodaj komentarz

Required fields are marked *.


.

Podobał się wpis? Wesprzyj Piszki Lab, kliknij w reklamę! :-)

.