M Security

Instalacja i aktywacja

M Security wymaga WordPressa 6.5 lub nowszego oraz PHP 8.1 lub nowszego. Przed aktywacją nie trzeba niczego przygotowywać: wtyczka ma działające ustawienia domyślne i zaczyna chronić wp-login.php w chwili włączenia, także na witrynach z wtyczką trybu konserwacji.

1. Wgraj wtyczkę do /wp-content/plugins/m-security/ albo zainstaluj plik zip przez Plugins, Add New, Upload Plugin.
2. Aktywuj ją. Powstają trzy tabele w bazie (wp_msc_log, wp_msc_lockouts, wp_msc_cloud), zapisywane są ustawienia domyślne i planowane jest codzienne zadanie porządkowe.
3. Adres, z którego przyszło żądanie aktywacji, trafia automatycznie na listę „Allowlist”.
4. Otwórz „M Security” w menu administracyjnym. Najpierw otwiera się karta „Statistics”, pusta do czasu pojawienia się ruchu.

Co działa od razu po aktywacji

Większość zabezpieczeń jest włączona od razu, a te, które potrafią zablokować adres na stałe, są wyłączone. Kilka ustawień domyślnych zmienia zachowanie witryny wobec prawdziwych odwiedzających i integracji, więc przeczytaj listę, zanim opuścisz ten ekran.

• Ograniczanie logowań jest włączone: 4 nieudane próby, potem 20 minut blokady, a przy powtórkach czas się podwaja aż do limitu 24 godzin.
• Zablokowani klienci zamiast formularza logowania dostają pustą stronę 403, komunikaty błędów są ogólne, a resetowanie hasła jest ograniczane.
• XML-RPC jest wyłączone. Jetpack, aplikacje mobilne WordPressa i narzędzia do zdalnej publikacji przestaną działać, dopóki go nie włączysz z powrotem.
• Skanowanie nazw użytkowników jest blokowane: niezalogowany odwiedzający, który otworzy dowolny adres z ?author=, dostaje puste 403. To jedyna reguła hartowania, która odrzuca zwykłe żądania stron witryny; zabezpieczenia komentarzy, rejestracji i formularzy działają na własnych ścieżkach wysyłki.
• Lista użytkowników w REST jest ukryta przed anonimowymi, wersja WordPressa nie jest pokazywana, dane autora znikają z oEmbed, a użytkownicy z mapy witryny.
• Zabezpieczenia komentarzy i rejestracji są włączone: niewidoczny honeypot, minimum 4 sekundy przed wysłaniem, sprawdzenie JavaScriptu, lista domen jednorazowych i weryfikacja rekordu MX.
• Ochrona formularzy na stronie jest włączona: niewielki skrypt dokłada niewidoczny honeypot do każdego formularza POST na stronie, a zgłoszenia z Contact Form 7, WPForms i Gravity Forms są oznaczane jako spam, gdy zadziała zabezpieczenie.
• Pole „Instant-ban usernames” jest puste, więc dopóki go nie wypełnisz, nic nie zostanie zablokowane na stałe.
• Reguły krajowe nic nie robią: „Allowed countries” jest puste, a baza GeoIP nie jest zainstalowana.
• Wspólny kanał zagrożeń jest wyłączony. Nic nie jest pobierane ani wysyłane.
• Hasła aplikacji pozostają włączone.
• Każde zdarzenie jest zapisywane w dzienniku i przechowywane 30 dni, adresy IP w pełnej postaci.

Gdzie znajdziesz ekrany

M Security dodaje jedną pozycję menu najwyższego poziomu z ikoną tarczy, w dolnej części menu wp-admin, pod adresem admin.php?page=m-security. Każdy ekran i każde działanie wymaga uprawnienia manage_options, więc widzą je wyłącznie administratorzy. Na większości witryn interfejs jest po angielsku, dlatego etykiety poniżej podano dokładnie tak, jak widać je na ekranie.

• „Statistics”: co zostało zablokowane w ciągu ostatnich 7 lub 30 dni, wykres rysowany jako osadzony SVG, najaktywniejsze kraje, udział wspólnego kanału i ustawienia cotygodniowego e-maila.
• „Login protection”: liczba prób, czas blokad i lista nazw do natychmiastowego bana.
• „Country rules”: lista dozwolonych krajów, kanały, których dotyczy, baza GeoIP i ustawienia proxy.
• „Spam”: zabezpieczenia komentarzy, rejestracji i formularzy.
• „Hardening”: XML-RPC, blokowanie skanowania nazw, hasła aplikacji i dwa opcjonalne wyzwalacze banów.
• „Access lists”: „Allowlist”, „Denylist” oraz panel „Permanently banned IPs”.
• „Cloud”: opcjonalny wspólny kanał zagrożeń i karta jego stanu.
• „Logs & privacy”: dziennik zdarzeń z filtrami, eksport CSV, tryb przechowywania IP i czas retencji.
• Karta „Status & tools” na pasku bocznym jest na każdej zakładce: liczby z ostatnich 24 godzin, liczba adresów zablokowanych na stałe, Twój adres IP i kraj, stan GeoIP oraz przycisk „Add my IP to the allowlist”, a w karcie poniżej, „Active lockouts”, każdy wiersz ma odnośnik „Release”.
• Na kokpicie WordPressa pojawia się też widżet M Security z tym samym wykresem zablokowanych ataków dla 7 i 30 dni.

Ustawienia „Login protection” i wartości domyślne

Ta karta steruje licznikami ataków siłowych (brute force). Nieudane próby liczone są per adres IP i per nazwa użytkownika w wp-login.php, XML-RPC i hasłach aplikacji, a blokada zapada za każdym razem, gdy licznik osiąga wielokrotność limitu prób. Adresy z „Allowlist” nie są liczone ani blokowane. To zwolnienie obejmuje liczniki, ale nie listę nazw wabików, którą opisuje rozdział 15.

• „Limit login attempts”: włączone.
• „Allowed retries”: 4, zakres od 1 do 20.
• „Lockout duration (minutes)”: 20, zakres od 1 do 1440.
• „Escalate repeat lockouts”: włączone. Każda kolejna blokada trwa dwa razy dłużej.
• „Maximum lockout (hours)”: 24, zakres od 1 do 168.
• „Reset counters after (hours)”: 12, zakres od 1 do 168.
• „Lock by username too”: włączone. Atakowana nazwa użytkownika zostaje zablokowana ze wszystkich adresów, więc napastnik zmieniający adresy potrafi zablokować prawdziwe konto.
• „Serve locked-out bots a blank page”: włączone.
• „Generic login errors”: włączone, więc formularz nigdy nie zdradza, czy błędna była nazwa, czy hasło.
• „Throttle password resets”: włączone. Liczona jest każda prośba o reset, nie tylko nieudana, i trafia na ten sam licznik per IP, z którego korzysta strona logowania. Przy domyślnym limicie prób czwarte żądanie oznacza 20 minut blokady również na stronie logowania.
• „Log successful logins”: włączone.
• „Notification email”: puste, czyli używany jest adres administratora witryny.
• „Email after N lockouts”: 0, co wyłącza powiadomienia. Zakres od 0 do 100.
• „Ban IPs that use those usernames”: włączone, ale bezczynne, dopóki lista poniżej jest pusta. Po wyłączeniu próba nadal jest odrzucana pustym 403 i zapisywana w dzienniku, po prostu nie zostaje zapamiętany ban.
• „Instant-ban usernames”: puste. To jedyny mechanizm banowania uzbrojony od razu, gdy tylko wpiszesz do niego cokolwiek.

Reguły krajowe i baza GeoIP

Reguły krajowe nie działają, dopóki nie zostaną spełnione dwa warunki: pole „Allowed countries” zawiera co najmniej jeden kod ISO 3166-1 alfa-2, a w witrynie zainstalowana jest prawidłowa baza .mmdb w formacie MaxMind. Strona logowania zawsze przepuszcza w razie wątpliwości, więc odwiedzający o nieustalonym kraju nie zostanie tam zablokowany, a adresy prywatne i zarezerwowane są wszędzie wyłączone spod tych reguł.

• „Allowed countries”: puste. Kody oddzielane przecinkami, na przykład LT, DE, US. Wyczyszczenie tego pola wyłącza wszystkie reguły krajowe.
• „Apply to login page”: włączone. „Apply to registration”: włączone. „Apply to comments”: włączone. „Apply to third-party forms”: wyłączone.
• „Strict mode for registration/comments”: wyłączone. Po włączeniu nieustalony kraj blokuje rejestrację i komentarze, a przy włączonej opcji „Apply to third-party forms” blokuje też zgłoszenia z Contact Form 7, WPForms i Gravity Forms. Etykieta nie wspomina o formularzach. Strona logowania nadal przepuszcza.
• „GeoIP database source”: domyślnie „Manual upload (.mmdb file)”. Opcja „MaxMind GeoLite2 (account required, auto-updates twice weekly)” wymaga identyfikatora konta i klucza licencyjnego, a „DB-IP Country Lite (no account, auto-updates monthly)” nie wymaga konta.
• „MaxMind account ID” i „MaxMind license key”: puste.
• „Client IP header”: „None”, czyli używany jest adres łączący się z serwerem. Pozostałe opcje to CF-Connecting-IP, X-Forwarded-For, X-Real-IP i True-Client-IP.
• „Trusted proxy addresses”: puste. Wybrany nagłówek jest respektowany tylko dla żądań faktycznie przychodzących z tych adresów, więc nie da się go podrobić.
• Karta „GeoIP database” pod formularzem daje przyciski „Upload .mmdb” oraz „Download / refresh now”, a ekran ostrzega, gdy aktywna baza ma więcej niż 35 dni. Przycisk „Download / refresh now” robi cokolwiek tylko wtedy, gdy źródłem jest MaxMind albo DB-IP, patrz rozdział 19.

Ochrona przed spamem

Karta „Spam” korzysta wyłącznie z niewidocznych testów: bez CAPTCHA i bez usług zewnętrznych. To, ile kosztuje trafienie w honeypot, zależy od miejsca. Komentarz zostaje odrzucony bezwarunkowo pustym 403. Rejestracja kończy się komunikatem „Registration could not be completed.” Zgłoszenie z Contact Form 7 lub Gravity Forms zostaje tylko oznaczone jako spam, a co dzieje się dalej, należy już do tych wtyczek: Contact Form 7 odpowiada nadawcy własnym ogólnym komunikatem o błędzie, Gravity Forms przyjmuje zgłoszenie i odkłada wpis do folderu „Spam”, a WPForms pokazuje „Your submission could not be processed.” Testy czasu i JavaScriptu są miękkimi sygnałami, które kierują komentarz do kolejki spamu. Użytkownicy z prawem moderowania komentarzy oraz adresy z „Allowlist” pomijają wszystkie te testy.

• „Comment honeypot”: włączone. Bot, który wypełni niewidoczne pole, dostaje pustą stronę.
• „Minimum seconds before submit”: 4, zakres od 0 do 60. Szybsze komentarze trafiają do kolejki spamu. 0 wyłącza test.
• „Require JavaScript for comments”: włączone. Komentarze z przeglądarek bez JavaScriptu trafiają do kolejki spamu.
• „Protect front-end forms”: włączone. Skrypt dokłada niewidoczny honeypot do każdego formularza z method=post na stronie, nie tylko do tych należących do wtyczki.
• „Form plugin integrations”: włączone. Zgłoszenia z Contact Form 7, WPForms i Gravity Forms są oznaczane jako spam, gdy zadziała zabezpieczenie.
• „Registration honeypot & timing”: włączone. Formularz rejestracji ma sztywne minimum 4 sekund, niezależne od ustawienia dla komentarzy, a jedynym sposobem jego wyłączenia jest odznaczenie tego pola.
• Ukryty znacznik czasu, na którym opiera się test czasu, jest podpisany i akceptowany tylko od minimalnego wieku do 4 tygodni. Powyżej 4 tygodni zostaje odrzucony, co ma znaczenie na stronach z pamięci podręcznej, patrz rozdział 17.
• „Block disposable email domains”: włączone, na podstawie dołączonej listy dostawców jednorazowych adresów.
• „Verify email domain (MX record)”: włączone. Wyniki są buforowane przez 24 godziny, a test jest pomijany, gdy serwer w ogóle nie potrafi wykonywać zapytań DNS.
• „First-comment moderation”: ten przełącznik zapisuje opcję rdzenia WordPressa comment_previously_approved, a nie ustawienie wtyczki, więc przetrwa jej usunięcie.

Hartowanie („Hardening”)

To niezależne przełączniki, każdy można wyłączyć osobno. Sześć z nich jest domyślnie włączonych: pięć nie zmienia niczego, co widzi zwykły odwiedzający, a szósty, blokada skanowania nazw autorów, odrzuca adresy na stronie. Dwa wyzwalacze banów na dole są wyłączone i to właśnie nad nimi warto się zastanowić dwa razy.

• „Disable XML-RPC”: włączone. xmlrpc.php odpowiada pustym 403, zanim uruchomi się serwer XML-RPC, a nagłówek X-Pingback znika. Wyłącz to, jeśli używasz Jetpacka lub aplikacji mobilnych WordPressa.
• „Hide REST user listing”: włączone dla niezalogowanych odwiedzających.
• „Block author enumeration scans”: włączone. Każde żądanie na stronie z ?author= od niezalogowanego kończy się pustym 403, na dowolnym adresie. Obecność na liście „Allowlist” nie chroni przed tą odmową.
• „Hide WordPress version”: włączone. „Strip author from oEmbed”: włączone. „Remove users from sitemaps”: włączone.
• „Disable application passwords”: wyłączone. Włączenie całkowicie usuwa ścieżkę logowania hasłem aplikacji, co psuje oparte na niej integracje REST.
• „Ban IPs that probe XML-RPC”: wyłączone. Po włączeniu każde żądanie do xmlrpc.php przy wyłączonym XML-RPC kończy się stałym banem tego adresu.
• „Ban IPs that scan for usernames”: wyłączone. Po włączeniu każde żądanie niezalogowanego z ?author= kończy się stałym banem. Wymaga pozostawienia włączonej opcji „Block author enumeration scans”.
• „File editor”: wiersz wyłącznie informacyjny. Pokazuje, czy w wp-config.php zdefiniowano DISALLOW_FILE_EDIT, i sugeruje dodanie tej stałej.

„Access lists”: lista dozwolonych, lista blokowanych i stałe bany

Na tej karcie sąsiadują trzy różne rzeczy, a ich mylenie jest najczęstszym źródłem pytań do wsparcia. „Allowlist” przeważa nad prawie wszystkim innym we wtyczce, poza dwoma wyjątkami wymienionymi niżej. „Denylist” służy wyłącznie do wpisów ręcznych. Bany automatyczne trzymane są osobno, we własnym panelu.

• „Allowlist”: pusta poza adresem zapisanym przy aktywacji. Jeden adres IP lub zakres CIDR na wiersz. Te adresy nigdy nie są limitowane, filtrowane według kraju, banowane ani zgłaszane do wspólnego kanału.
• Dwa wyjątki: adres z „Allowlist”, którym ktoś spróbuje zalogować się nazwą z listy „Instant-ban usernames” albo z którego niezalogowany otworzy adres z ?author=, i tak dostaje puste 403. Lista chroni przed banem, ale nie przed odmową. Oba przypadki opisuje rozdział 15.
• „Denylist”: pusta. Jeden adres IP lub zakres CIDR na wiersz, wyłącznie wpisy ręczne. Te adresy dostają puste 403 na stronie logowania, nie mogą się rejestrować ani komentować, a ich zgłoszenia z Contact Form 7, WPForms i Gravity Forms są oznaczane jako spam. Dodanie wpisu kolejkuje go także do wspólnej czarnej listy, jeśli raportowanie jest włączone.
• „Permanently banned IPs”: panel pod formularzem z adresami zbanowanymi automatycznie przez nazwę wabik, sondowanie XML-RPC lub skanowanie nazw. Każdy wiersz ma odnośnik „Unban”, a niżej jest przycisk „Clear all bans”. Widocznych jest 100 najnowszych, przechowywanych do 50000 banów, najstarsze usuwane są pierwsze.
• Bany automatyczne nigdy nie pojawiają się w polu „Denylist”. Pasek boczny pokazuje ich liczbę i prowadzi do tego panelu.

Wspólny kanał zagrożeń (karta „Cloud”)

To jedyny moduł komunikujący się z usługą zdalną i pozostaje wyłączony, dopóki go nie włączysz. Po włączeniu zadanie w tle pobiera kanał M Blacklist do lokalnej tabeli, a sprawdzenia przy logowaniu i rejestracji czytają tę lokalną kopię, więc wyświetlenie strony nigdy nie czeka na sieć. Komentarze nie są tym objęte: zabezpieczenie komentarzy w ogóle nie sięga do wspólnego kanału. Gdy usługa jest wolna, nieosiągalna lub źle skonfigurowana, moduł przepuszcza: sprawdzenia odpowiadają „brak na liście”, a Twoje własne reguły działają dalej.

• „Use the shared threat feed”: wyłączone. Dopóki to nie jest włączone, reszta poniżej nie ma znaczenia.
• „Service URL”: https://black.majevski.com. Niepoprawna wartość wraca do tego adresu domyślnego, zamiast po cichu wyłączać moduł.
• „API key”: puste. Potrzebny tylko do wysyłania zgłoszeń, bo czytanie kanału jest anonimowe. Klucz musi odpowiadać formatowi usługi, inaczej jest ignorowany.
• „Block addresses from the shared feed”: włączone, obowiązuje na wp-login.php, przy rejestracji, w XML-RPC i przy logowaniu hasłem aplikacji.
• „Contribute my blocks”: włączone, ale bez poprawnego klucza API nic nie jest kolejkowane ani wysyłane.
• „Report permanent bans to the shared blacklist”: włączone i również zależne od klucza oraz od aktywnego współdzielenia.
• „Check registration emails”: włączone, ale to nie jest samodzielny przełącznik. Sprawdzenie działa tylko wtedy, gdy włączone jest także „Block addresses from the shared feed”, więc wyłączenie tamtej opcji po cichu wyłącza i weryfikację adresów. Gdy działa, zapytanie k-anonimowe wysyła tylko pierwsze pięć znaków skrótu adresu, buforuje odpowiedź na 24 godziny, przerywa po 3 sekundach i przepuszcza w razie błędu.
• „Sync every (hours)”: 6, zakres od 1 do 168.
• Karta „Threat feed status” pokazuje liczbę wpisów w lokalnej kopii, zgłoszenia czekające na wysyłkę, ostatnią synchronizację i ostatni błąd opisany zwykłym językiem, a także przyciski „Test connection”, „Sync now” i „Share existing bans & denylist”.

Statystyki, widżet kokpitu i cotygodniowy e-mail

Karta „Statistics” otwiera się jako pierwsza i pokazuje, co wtyczka faktycznie zatrzymała w ciągu ostatnich 7 lub 30 dni: zablokowane ataki, zablokowane logowania, zablokowany spam, nieudane hasła i liczbę różnych adresów, wraz z wykresem rysowanym jako osadzony SVG, który nie potrzebuje JavaScriptu ani żądań na zewnątrz. Gdy przechowywanie IP jest ustawione na skrócone, ostatnia liczba dotyczy sieci, a nie adresów, i etykieta zmienia się odpowiednio. Niżej widać kraje pochodzenia ruchu oraz, przy włączonym wspólnym kanale, jaką część pracy wykonał.

• „Send a weekly summary”: wyłączone. Po włączeniu wiadomość wychodzi w każdy poniedziałek o 08:00 czasu witryny i porównuje tydzień z poprzednim.
• „Send to”: puste, czyli używany jest adres administratora witryny widoczny w podpowiedzi pola.
• „Send a test report now” wysyła natychmiast na powyższy adres, niezależnie od tego, czy harmonogram tygodniowy jest włączony. To najszybszy sposób, by sprawdzić, czy witryna w ogóle wysyła pocztę.
• Widżet na kokpicie WordPressa pokazuje ten sam wykres dla 7 i 30 dni i widzą go tylko użytkownicy z uprawnieniem manage_options.

Dziennik i ustawienia prywatności

Każda próba logowania, blokada, odrzucenie i werdykt spamowy trafiają do tabeli dziennika ze znacznikiem czasu, adresem, krajem, kanałem, wynikiem i kodem reguły. Karta „Logs & privacy” pozwala tę tabelę filtrować, przeszukiwać, eksportować do CSV i czyścić. Codzienne zadanie usuwa wpisy starsze niż okres retencji, a twardy limit 100000 wierszy nie pozwala zalewowi ruchu zapełnić bazy.

• „IP address storage”: „Full” (domyślnie), „Truncated” lub „Hashed”. Tryb skrócony zostawia /24 dla IPv4 i /64 dla IPv6, a tryb skrótu zapisuje wartość z solą. W obu trybach innych niż pełny odnośniki szybkiego dodania do listy dozwolonych lub blokowanych nie mogą działać.
• „Keep log entries (days)”: 30, zakres od 1 do 365.
• „Keep data on uninstall”: wyłączone.
• „Export CSV” wysyła do 100000 wierszy, a wartości zaczynające się znakiem formuły są zabezpieczane, by arkusz ich nie wykonał.
• „Clear log” opróżnia tabelę, a więc i ekran statystyk. Tego nie da się cofnąć.
• Codzienne porządkowanie nie rusza stałych banów. Mają datę ważności 2099-12-31 23:59:59, więc usuwa je tylko „Unban”, „Clear all bans” albo ręczna operacja w bazie. Wiersze dziennika, które je tłumaczą, kasowane są jednak w zwykłym cyklu retencji.

Pierwsza konfiguracja, po kolei

Konfiguruj wtyczkę w tej kolejności. Każdy krok zakłada wykonanie poprzedniego, a układ celowo przesuwa wszystko, czym można sobie zablokować dostęp, za krok, który przed tym chroni.

1. Jeśli witryna stoi za Cloudflare, load balancerem lub innym proxy, otwórz najpierw „Country rules”, ustaw „Client IP header” i wpisz zakresy proxy w „Trusted proxy addresses”. Zapisz.
2. Spójrz na pasek boczny. Adres przy „Your IP” musi być Twoim prawdziwym adresem. Jeśli widzisz przycisk „Add my IP to the allowlist”, kliknij go.
3. Otwórz „Access lists” i przeczytaj „Allowlist” wiersz po wierszu. Usuń wpis dodany przy aktywacji, jeśli jest to adres proxy, a nie Twój. Na koniec na liście ma być Twój prawdziwy adres i nic, co wygląda na węzeł CDN lub load balancera.
4. Otwórz „Hardening”. Zdecyduj w sprawie XML-RPC: zostaw wyłączone, chyba że używasz Jetpacka albo aplikacji mobilnych. Oba wyzwalacze banów na razie zostaw wyłączone.
5. Otwórz „Login protection”. W razie potrzeby zmień liczbę prób i czas blokady, a pole „Instant-ban usernames” na razie zostaw puste.
6. W wp-admin otwórz „Users” i spisz wszystkie prawdziwe nazwy kont. Dopiero potem wróć do „Login protection” i dodaj nazwy wabiki, których na tej liście nie ma.
7. Reguły krajowe ustaw tylko wtedy, gdy są potrzebne: najpierw zainstaluj bazę GeoIP, sprawdź, czy pasek boczny poprawnie pokazuje Twój kraj, i dopiero wtedy wypełnij „Allowed countries”.
8. Otwórz „Logs & privacy” i wybierz tryb przechowywania IP oraz okres retencji zgodne z Twoją polityką prywatności.
9. Opcjonalnie włącz raport tygodniowy na karcie „Statistics” i kliknij „Send a test report now”, żeby potwierdzić, że poczta działa.
10. Kartę „Cloud” zostaw na koniec i tylko jeśli chcesz wspólnego kanału. Włącz go, kliknij „Test connection”, potem „Sync now” i sprawdź kartę stanu.
11. Wróć do dziennika po tygodniu. Dopiero wtedy zdecyduj, czy wyzwalacze banów za XML-RPC i skanowanie nazw mają dla tej witryny sens.

Wyłącznik awaryjny: MSC_DISABLE

Jedna linia w wp-config.php całkowicie wyłącza wtyczkę. Stała jest odczytywana na samym początku głównego pliku wtyczki, zanim cokolwiek innego się załaduje, więc dopóki ta linia tam jest, nie ma zapory, banów, blokad, reguł krajowych ani ekranów administracyjnych. Nic nie jest kasowane: ustawienia, bany i dziennik pozostają bez zmian, a usunięcie linii wszystko przywraca. To droga ratunkowa działająca nawet wtedy, gdy wp-login.php jest zupełnie nieosiągalny.

1. Otwórz wp-config.php przez FTP, SFTP albo menedżer plików hostingu.
2. Dodaj poniższą linię gdziekolwiek powyżej komentarza mówiącego, że dalej nie należy już edytować.
3. Odśwież wp-login.php i zaloguj się normalnie.
4. Usuń przyczynę: odbanuj adres, zdejmij blokadę, wyczyść listę nazw wabików albo opróżnij „Allowed countries”.
5. Skasuj linię z wp-config.php i odśwież witrynę, żeby potwierdzić, że ochrona znów działa.

define( 'MSC_DISABLE', true );

Wszystkie sposoby, na jakie ta wtyczka może zablokować Ci dostęp

Przeczytaj ten rozdział, zanim cokolwiek zmienisz na kartach „Login protection”, „Country rules” lub „Hardening”. Dwa uspokajające przekonania są prawdziwe tylko częściowo, więc na nich nie polegaj. Zapora działa na wp-login.php i xmlrpc.php, ale blokada skanowania nazw autorów jest podpięta do akcji init i odrzuca każdy adres na stronie z ?author= od niezalogowanego, jakikolwiek by był. Wyjątek dla ważnego ciasteczka logowania istnieje zaś tylko w kontroli kraju na wp-login.php: kontrole „Denylist” i stałych banów go nie mają, więc otwarta sesja wp-admin nie gwarantuje, że wrócisz na stronę logowania. Wpisanie własnego adresu na „Allowlist” pozostaje najbardziej użyteczną rzeczą, jaką możesz zrobić; czego ta lista nie obejmuje, opisuje rozdział 15.

• Nazwa wabik, która jest też prawdziwym kontem. Pierwsza próba logowania tą nazwą banuje na stałe adres, z którego padła, i zwraca puste 403, tak samo przez wp-login.php, XML-RPC i hasła aplikacji. Naprawa: „Access lists”, „Permanently banned IPs”, „Unban”, a potem usunięcie nazwy z listy.
• Cztery prośby o reset hasła. „Throttle password resets” liczy każde wysłanie formularza „Lost your password?”, nie tylko nieudane, i dokłada je do tego samego licznika per IP, z którego korzysta strona logowania. Przy domyślnym limicie 4 prób czwarte żądanie oznacza 20 minut blokady, a strona logowania odpowiada wtedy pustym 403. Wystarczy jeden użytkownik klikający cztery razy albo czterech współpracowników za jednym adresem biurowym. Naprawa: pasek boczny, „Active lockouts”, „Release”; albo przeczekanie; albo MSC_DISABLE.
• Dwa wyzwalacze banów w „Hardening”. Przy włączonych wystarczy jedno żądanie do xmlrpc.php albo jedno żądanie niezalogowanego z ?author=, by adres został zbanowany na stałe. Naprawa: ten sam panel plus wyłączenie wyzwalacza.
• Wpis na „Denylist” lub zakres CIDR obejmujący Twój własny adres. Naprawa: usuń wiersz albo dodaj swój adres do „Allowlist”, która przeważa wszędzie tam, gdzie w ogóle jest sprawdzana.
• Reguły krajowe nieobejmujące kraju, w którym faktycznie jesteś. Wystarczy wyjazd, węzeł wyjściowy VPN, sieć komórkowa zarejestrowana za granicą albo nieaktualna baza GeoIP. Naprawa: opróżnij „Allowed countries” albo odznacz „Apply to login page”.
• „Lock by username too” pozwala napastnikowi z wieloma adresami zablokować prawdziwą nazwę konta ze wszystkich miejsc. Naprawa: pasek boczny, „Active lockouts”, „Release”, albo wyłączenie tej opcji.
• Źle skonfigurowane proxy. Gdy „Client IP header” jest wybrany błędnie albo zakresy proxy nie są wpisane, wszyscy odwiedzający rozpoznawani są jako jeden adres, więc blokada jednego napastnika dotyka całej publiczności. Naprawa: popraw dwa pola proxy na karcie „Country rules”.
• „Disable application passwords”, a także kontrole banów, kraju i wspólnego kanału na ścieżce haseł aplikacji, po cichu psują integracje logujące się tą drogą. Dostają odmowę bez żadnego wyjaśnienia.
• Włączony wspólny kanał zagrożeń może odrzucić na Twojej stronie logowania adres, którego sam nigdy nie blokowałeś. Naprawa: dodaj adres do „Allowlist” albo wyłącz „Block addresses from the shared feed”.

Czego nie obejmuje „Allowlist”

Na prawie każdej ścieżce „Allowlist” jest sprawdzana pierwsza i żądanie zostaje przepuszczone: tak działa zapora na wp-login.php, filtr authenticate, ścieżka haseł aplikacji, zabezpieczenie komentarzy, zabezpieczenie rejestracji i adaptery formularzy. Dwie ścieżki tak nie robią, a obie kończą się całkowicie pustą stroną bez komunikatu błędu, bez informacji o blokadzie i w większości przypadków bez wiersza dziennika, który by to tłumaczył. Trzecia, xmlrpc.php, jest odrzucana, zanim „Allowlist” w ogóle zostanie sprawdzona, choć odrzucana jest tak samo dla każdego adresu. To najbardziej prawdopodobne zgłoszenie do wsparcia, jakie ta wtyczka wygeneruje, więc przeczytaj to, zanim uznasz witrynę za zepsutą.

• Lista nazw wabików. Gdy ktoś zaloguje się nazwą z „Instant-ban usernames”, wtyczka prosi o bana, ban zostaje odrzucony, bo adres jest na „Allowlist”, i nie powstaje żaden wiersz dziennika; żądanie i tak kończy się pustym 403. Administrator z „Allowlist”, który wpisze nazwę wabik, nie widzi więc niczego: ani błędu, ani bana, ani wpisu w dzienniku. Jeśli strona logowania robi się pusta, a Twój adres jest na „Allowlist”, wpisałeś nazwę z listy wabików. Zaloguj się prawdziwą nazwą konta.
• Blokada skanowania nazw autorów. Żądanie niezalogowanego na dowolny adres z ?author= kończy się pustym 403 niezależnie od tego, czy adres jest na „Allowlist”. Przy włączonym „Ban IPs that scan for usernames” taki adres zostaje odrzucony, ale nie zbanowany, i znów nie powstaje wiersz dziennika. Najpierw się zaloguj albo usuń parametr ?author= z adresu.
• xmlrpc.php, sprawdzany jeszcze przed „Allowlist” i niebędący od niej wyjątkiem: dopóki „Disable XML-RPC” jest włączone, ten plik odpowiada pustym 403 każdemu, z listy czy spoza niej. „Allowlist” zmienia tylko to, co zostaje w dzienniku. Przy włączonym również „Ban IPs that probe XML-RPC” adres z listy zostaje odrzucony, ale nie zbanowany, i nie powstaje żaden wiersz dziennika, podczas gdy to samo żądanie przy wyłączonym wyzwalaczu jest zapisywane. Brak wiersza w dzienniku nie dowodzi więc, że żądania nie było.
• Przed czym „Allowlist” chroni niezawodnie: przed licznikami logowań, przed blokadą, przed kontrolami kraju, przed kontrolami „Denylist” i stałych banów na każdej ścieżce, która ją sprawdza, przed zabezpieczeniami komentarzy i rejestracji, przed adapterami formularzy, przed zgłoszeniem do wspólnej czarnej listy oraz przed banem z któregokolwiek z trzech wyzwalaczy.
• Jeśli musisz mieć pewność, że adres jest zwolniony ze wszystkiego, jedynym pełnym wyłącznikiem jest MSC_DISABLE w wp-config.php.

Wspólne adresy, CGNAT i roboty

Ban dotyczy adresu, nie osoby. W biurach, szkołach, hotelach i u większości operatorów komórkowych za jednym publicznym adresem siedzi wiele osób, a CGNAT potrafi zmieścić tam tysiące. Jeśli jedna z nich uruchomi skaner albo jeden znudzony odwiedzający spróbuje nazwy wabika, wszyscy za tym adresem tracą stronę logowania (puste 403), formularz komentarzy (puste 403), rejestrację (ogólny błąd) i każde zgłoszenie z Contact Form 7, WPForms i Gravity Forms, oznaczane jako spam: Contact Form 7 i WPForms odpowiadają ogólnym komunikatem o błędzie, a Gravity Forms pokazuje zwykłe potwierdzenie, odkładając wpis do folderu „Spam”. To właśnie formularz kontaktowy firma zauważa najpóźniej i na nim traci pieniądze. To samo dotyczy robotów wyszukiwarek, gdy włączony jest ban za skanowanie nazw, a którakolwiek podstrona linkuje do adresu z ?author=.

• Zanim dodasz typowe wabiki, zastanów się, kto dzieli adresy z Twoimi odwiedzającymi. Najgorszy przypadek to witryna B2B, której klienci siedzą za firmowym NAT.
• Przeglądaj „Permanently banned IPs”, póki istnieją jeszcze wiersze dziennika, które doprowadziły do każdego bana. Bany nigdy nie wygasają, a dziennik jest czyszczony po okresie retencji, domyślnie po 30 dniach. Potem panel jest listą adresów, których nic nie tłumaczy. Jeśli którykolwiek wyzwalacz banów w „Hardening” jest włączony, przeglądaj panel co tydzień albo zwiększ „Keep log entries (days)”.
• Aby uratować wspólny adres: „Access lists”, „Permanently banned IPs”, „Unban”, a potem dodaj ten adres lub zakres do „Allowlist”, żeby się nie powtórzyło.
• „Clear all bans” usuwa naraz wszystkie bany automatyczne i jest najszybszym wyjściem, gdy lista wymknęła się spod kontroli.

Jak prawdziwi odwiedzający są odprawiani bez słowa

Te awarie nie blokują dostępu Tobie, więc nikt ich nie zgłasza; kosztują za to zapytania, rejestracje i komentarze. Każda ma konkretną przyczynę i konkretny przełącznik.

• Zapytania znikają bez śladu. Przy włączonym „Protect front-end forms” skrypt dokłada niewidoczne pole tekstowe do każdego formularza z method=post na stronie, w tym do zamówienia, wyszukiwarki i formularzy należących do innych wtyczek. Autouzupełnianie przeglądarki i menedżery haseł wypełniają ukryte pola tekstowe. Gdy włączone jest też „Form plugin integrations”, wypełnione pole oznacza zgłoszenie z Contact Form 7 lub Gravity Forms jako spam: Contact Form 7 odpowiada nadawcy własnym ogólnym komunikatem o błędzie, a Gravity Forms przyjmuje zgłoszenie, pokazuje zwykłe potwierdzenie i odkłada wpis do folderu „Spam”, do którego nikt nie zagląda. Naprawa: odznacz „Protect front-end forms” albo „Form plugin integrations”.
• Rejestracja przestaje działać na mocno buforowanej witrynie. Podpisany znacznik czasu w formularzu jest akceptowany tylko wtedy, gdy jest starszy niż minimalny wiek i młodszy niż 4 tygodnie. Strona rejestracji trzymana w pamięci podręcznej pełnych stron lub w CDN dłużej niż 28 dni kończy się dla każdego odwiedzającego komunikatem „Registration could not be completed.”, a formularz komentarzy w tym samym stanie kieruje każdy komentarz do kolejki spamu. Naprawa: wyczyść cache, wyłącz strony rejestracji i komentarzy z buforowania pełnych stron albo ustaw „Minimum seconds before submit” na 0 dla komentarzy. Własne minimum 4 sekund formularza rejestracji da się wyłączyć tylko przez odznaczenie „Registration honeypot & timing”.
• Zalogowani członkowie dostają pustą stronę przy komentowaniu. Zabezpieczenie komentarzy zwalnia wyłącznie użytkowników z prawem moderowania. Zalogowany subskrybent, klient lub członek komentujący spoza „Allowed countries” dostaje puste 403 w trakcie sesji, mimo ważnego ciasteczka logowania. Naprawa: odznacz „Apply to comments” albo dodaj zakres do „Allowlist”.
• Jeden zbanowany wspólny adres zabija także formularz kontaktowy. Kontrola stałego bana działa na komentarzach, przy rejestracji i przy każdym zgłoszeniu z formularza zewnętrznego, nie tylko na stronie logowania. Naprawa: odbanuj adres, dodaj zakres do „Allowlist”, a potem sprawdź wpisy lub dziennik wtyczki formularzy, żeby zobaczyć, co przepadło.
• Komentarze kilku czytelników zawsze lądują w spamie. Tak działa „Require JavaScript for comments” wobec każdej przeglądarki bez JavaScriptu.

Odzyskiwanie bez wp-admin: baza danych i WP-CLI

Mając dostęp do powłoki albo bazy danych, ekrany administracyjne nie są w ogóle potrzebne. Bany i blokady leżą w jednej tabeli wp_msc_lockouts, gdzie wiersz z kind = 2 to ban stały, a każdy inny wiersz z przyszłą wartością locked_until to blokada czasowa. Stałe bany mają umowną datę ważności 2099-12-31 23:59:59, więc nieuważnie napisanemu zapytaniu wyglądają jak aktywne blokady. Ustawienia są w jednej opcji msc_settings. Prefiks wp_ zamień na ten, którego naprawdę używa dana instalacja. Wtyczka nie dostarcza własnych poleceń WP-CLI, więc poniższe linie to zwykłe polecenia rdzenia.

1. Zanim cokolwiek skasujesz, sprawdź, co jest zbanowane, żeby wiedzieć, co cofasz.
2. Usuń bany stałe albo, jeśli nie możesz edytować wp-config.php, po prostu dezaktywuj wtyczkę.
3. Jeśli nie masz ani dostępu do plików, ani do powłoki, zmiana nazwy katalogu wp-content/plugins/m-security w menedżerze plików hostingu jest ostatecznością, a nie odpowiednikiem dezaktywacji. WordPress przy następnym otwarciu panelu wyłącza wtyczkę, której plik zniknął, ale hak dezaktywacji nigdy się nie uruchamia, więc msc_purge, msc_geo_update, msc_cloud_sync i msc_weekly_report pozostają zaplanowane dla wtyczki, której już nie ma. Czystszą drogą jest MSC_DISABLE w wp-config.php, bo zostawia stan wtyczki spójny.
4. Zaloguj się, popraw ustawienie, które to spowodowało, i włącz wtyczkę z powrotem albo przywróć nazwę katalogu. Jeśli zmieniałeś nazwę katalogu, zapisz potem po razie karty „Country rules” i „Cloud”, żeby zadania GeoIP i wspólnego kanału wróciły na miejsce; codzienne porządkowanie, a przy włączonym raporcie tygodniowym także jego wysyłka, odtwarzają się same przy następnym otwarciu panelu.

wp db query "SELECT subject, kind, locked_until FROM wp_msc_lockouts ORDER BY first_fail DESC LIMIT 50;"
wp db query "DELETE FROM wp_msc_lockouts WHERE kind = 2;"
wp db query "DELETE FROM wp_msc_lockouts WHERE kind != 2 AND locked_until IS NOT NULL;"
wp option patch update msc_settings ip_allowlist "203.0.113.10"
wp plugin deactivate m-security

Rozwiązywanie problemów

Oto rzeczy, które naprawdę się psują, i to, na co spojrzeć najpierw. Większość z nich to nie usterki, tylko dwa różne mechanizmy brane za jeden.

• Tysiące zablokowanych żądań, ale ani jednego bana. Blokowanie odrzuca pojedyncze żądanie, a ban zapisuje adres na stałe. Bana tworzy tylko lista nazw wabików i opcjonalnie dwa wyzwalacze z „Hardening”.
• Znanego bana nie ma w polu „Denylist”. I nie będzie: bany automatyczne trzymane są osobno i widnieją w panelu „Permanently banned IPs”.
• Reguły krajowe wyglądają na nieaktywne. Sprawdź, czy baza GeoIP jest zainstalowana, czy pasek boczny pokazuje kraj Twojego adresu i czy „Allowed countries” nie jest puste. Przy nieznanym kraju strona logowania zawsze przepuszcza.
• Wszystkie wiersze dziennika pokazują ten sam adres. Witryna stoi za proxy, a „Client IP header” i „Trusted proxy addresses” nie są skonfigurowane.
• Komentarze nagle w całej witrynie trafiają do spamu. Nazwa pola honeypot, podpisany znacznik czasu i token JavaScriptu wywodzą się z soli uwierzytelniającej witryny, więc jej wymiana unieważnia strony wciąż serwowane z pamięci podręcznej. Wyczyść cache. Jeśli sole nie były wymieniane, sprawdź wiek pamięci podręcznej: strona starsza niż 4 tygodnie sama z siebie nie przechodzi testu znacznika czasu.
• Komentarze kilku czytelników zawsze lądują w spamie. Tak działa „Require JavaScript for comments” wobec każdej przeglądarki bez JavaScriptu.
• Rejestracje odrzucane jako niedoręczalne. Test MX odpytał DNS i nie dostał dla domeny ani rekordu MX, ani A. Przepuszcza tylko wtedy, gdy serwer w ogóle nie potrafi odpytywać DNS.
• Synchronizacja wspólnego kanału kończy się sukcesem, ale w usłudze nie ma Twoich wpisów. Czytanie kanału jest anonimowe, więc pobranie udaje się nawet wtedy, gdy wysyłka nie działa: sprawdź liczbę zgłoszeń w kolejce, czy domena jest zweryfikowana i czy klucz ma zakres zapisu. Liczbę zgłoszeń w kolejce pokazuje karta stanu, a „Test connection” raportuje pozostałe dwie rzeczy.
• Komunikat mówi, że baza GeoIP ma ponad 35 dni. Przy domyślnym źródle „Manual upload (.mmdb file)” przycisk „Download / refresh now” nie jest w stanie niczego odświeżyć: nie ma skąd pobierać, więc nie robi nic. Dopóki nie jest zapamiętany wcześniejszy błąd pobierania, zgłasza przy tym „GeoIP database refreshed.” Jeśli przed powrotem do źródła ręcznego nie powiodła się próba MaxMind lub DB-IP, ten sam przycisk zgłasza „GeoIP refresh failed. Check the source settings.” Żaden z tych komunikatów nie oznacza, że plik dotarł. Wgraj nowy plik .mmdb albo najpierw zmień źródło na „DB-IP Country Lite” lub „MaxMind GeoLite2” i dopiero wtedy kliknij przycisk.
• Raport tygodniowy nigdy nie przychodzi. Kliknij „Send a test report now”: wiadomość wychodzi natychmiast i pokazuje, czy witryna w ogóle wysyła pocztę. Wysyłka planowa zależy dodatkowo od działającego WP-Cron.
• Statystyki wyglądają na puste albo krótsze, niż powinny. Domyślna retencja to 30 dni, a „Clear log” kasuje liczby razem z dziennikiem.

Prywatność: co jest przechowywane i co opuszcza witrynę

Przy ustawieniach domyślnych z serwera nie wychodzi nic. Wtyczka rejestruje w WordPressie eksporter i kasownik danych osobowych, oba powiązane z nazwą konta w wierszach dziennika, a adresy IP można przechowywać w pełnej, skróconej lub zahaszowanej postaci i są usuwane automatycznie po upływie retencji.

• Przechowywane lokalnie: tabele wp_msc_log, wp_msc_lockouts i wp_msc_cloud, opcje msc_settings, msc_geo_state, msc_db_version, msc_schema_rev, msc_cloud_queue, msc_cloud_state oraz msc_report_last_sent, a także transjenty z prefiksem msc_.
• Baza GeoIP leży w katalogu w wp-content/uploads o nazwie m-security- plus osiem znaków wyprowadzonych z soli witryny, chronionym własnymi plikami .htaccess i index.php.
• Żądania na zewnątrz idą tylko na Twoje życzenie: do MaxMind przy wybranym tym źródle, do DB-IP przy tamtym, oraz do usługi wspólnego kanału przy włączonym module „Cloud”.
• Przy włączonym współdzieleniu zgłoszenie zawiera adres IP albo skrót SHA-256 adresu e-mail plus kategorię, na przykład bruteforce lub spam. Nazwy użytkowników, treść komentarzy, zawartość formularzy i jawne adresy e-mail nigdy nie są kolejkowane ani wysyłane, adresy z „Allowlist” nie są zgłaszane nigdy, a własny adres i domena tej witryny również nie są raportowane nigdy.
• Sprawdzanie adresu e-mail przy rejestracji korzysta z k-anonimowości: witrynę opuszcza tylko pierwsze pięć znaków skrótu.
• Poczta wychodząca ogranicza się do opcjonalnego powiadomienia o blokadzie i opcjonalnego podsumowania tygodniowego, obu przez wp_mail.

Dezaktywacja i odinstalowanie

Dezaktywacja i usunięcie to tutaj dwie różne rzeczy. Dezaktywacja czyści jedynie zaplanowane zadania: ustawienia, dziennik, blokady i wszystkie stałe bany zostają w bazie i wracają w chwili ponownej aktywacji. Usunięcie z ekranu „Plugins” uruchamia procedurę sprzątającą.

• Usunięcie wtyczki kasuje trzy tabele, jej własne opcje i transjenty msc_, czyści cztery zaplanowane zadania i kasuje katalog GeoIP w uploads.
• Co zostaje: ustawienie rdzenia WordPressa comment_previously_approved w takim stanie, w jakim zostawiłeś je na karcie „Spam”, a także użytkownicy, komentarze i cała reszta należąca do WordPressa. Wtyczka niczego z tego nie rusza.
• Zaznaczenie „Keep data on uninstall” na karcie „Logs & privacy” przed usunięciem zostawia wszystko na miejscu, co jest pożądane przy przenosinach hostingu albo ponownej instalacji.
• W sieci multisite te trzy operacje zachowują się różnie. Odinstalowanie zawsze wykonuje się na każdej witrynie w sieci. Aktywacja i dezaktywacja obchodzą wszystkie witryny tylko wtedy, gdy wtyczka jest włączana lub wyłączana dla całej sieci; aktywacja na pojedynczej podwitrynie zakłada tabele i wpisuje adres na „Allowlist” wyłącznie na tej jednej witrynie, a pozostałych nie dotyka.

Statystyki i raporty

Od wersji 1.4.0 wtyczka pokazuje, co faktycznie zatrzymała. Widget „M Security — blocked attacks" w kokpicie WordPressa oraz karta Statistics (pierwsza karta ustawień) rysują wykresy zablokowanych logowań i spamu z ostatnich 7 lub 30 dni, wskazują najbardziej pracowity dzień, najczęstsze kraje źródłowe i udział wspólnego kanału zagrożeń. Opcjonalne cotygodniowe podsumowanie e-mail — domyślnie wyłączone, włączane na karcie Statistics — przychodzi w poniedziałki o 08:00 czasu witryny i porównuje tydzień z poprzednim; przycisk „send a test report now" pozwala sprawdzić, że dostarczanie działa.

Telemetria użycia i opinie

Od wersji 1.5.0 wtyczka wysyła zanonimizowaną migawkę użycia do black.majevski.com. Steruje się tym na karcie Cloud trzema stanami: Off (nic nigdy nie jest wysyłane i nie istnieje żadne zaplanowane wysłanie), Basic (numery wersji i które zabezpieczenia są włączone) oraz Full — domyślny — dodający te same liczniki, które wtyczka pokazuje Tobie. Nazwy użytkowników, adresy e-mail, adresy IP, adresy URL ani treści nigdy nie opuszczają witryny; podgląd „what will be sent" pokazuje dokładny JSON, a osobne pole wyboru decyduje, czy ujawniana jest domena witryny. Dane są przechowywane najwyżej 180 dni po tym, jak instalacja zamilknie. Strona „Send feedback" w menu M Security dostarcza zgłoszenia błędów i propozycje prosto do autora — działa nawet przy wyłączonej telemetrii, a diagnostykę dołącza tylko wtedy, gdy pozwala na to jej własne pole wyboru.

Czarna lista autorów komentarzy

Od wersji 1.7.0 ekran komentarzy ma akcję „Spam & blacklist" — pod każdym komentarzem i w menu działań masowych. Oznacza ona komentarz jako spam jak natywna akcja, trwale blokuje IP autora w Twojej witrynie i zgłasza IP oraz skrót SHA-256 adresu e-mail do wspólnej czarnej listy — jawny adres nigdy nie opuszcza witryny. Adresy prywatne i z listy dozwolonych nie są nigdy zgłaszane, adresy e-mail zarejestrowanych użytkowników Twojej witryny są pomijane, a akcja wymaga uprawnienia moderowania komentarzy. W drugą stronę: komentarze (i pingbacki) autorów ze wspólnej czarnej listy są odrzucane od razu, dopóki włączony jest przełącznik „Block comments from listed authors" na karcie Cloud. Jedno zgłoszenie nie umieszcza nikogo na liście globalnie: najpierw musi je potwierdzić inna witryna członkowska — to chroni wszystkich przed pomyłkami i nadużyciami.

Automatyczne aktualizacje

Wtyczka sprawdza majevski.com pod kątem nowych wydań i proponuje je przez zwykły ekran aktualizacji WordPressa — ten sam komunikat, lista zmian i instalacja jednym kliknięciem jak przy każdej innej wtyczce. Sprawdzenia są buforowane, nigdy nie spowalniają strony i są odporne na awarie: jeśli majevski.com jest nieosiągalny, witryna po prostu działa dalej i próbuje później. Pakiet aktualizacji jest przyjmowany wyłącznie z majevski.com przez HTTPS, a starsza wersja nigdy nie jest proponowana. Wersje starsze niż 1.6.0 nie znają jeszcze kanału aktualizacji, więc nie widzą nowych wydań — zainstaluj raz ręcznie 1.6.0 lub nowszą, a każde kolejne wydanie przyjdzie samo.