Dziennik zmian NightShiftWP

Filtr języka przepuszcza wiadomość, gdy rozpozna w niej polszczyznę. Problem w tym, że sprawdzał całą zawartość formularza - razem z tekstami, które napisałeś Ty, a nie osoba pisząca: nazwami usług na liście wyboru, treścią zgody RODO, klauzulą w stopce.

Skutek był taki, że wystarczyła jedna lista rozwijana z polskim słowem, by dowolna obcojęzyczna wiadomość przechodziła przez ten formularz. Jeden element strony wyłączał filtr na całej witrynie.

Od tej wersji teksty należące do formularza są pomijane przy ocenie języka. Nadal są w pełni sprawdzane przez pozostałe zabezpieczenia - ukrycie spamu w polu wyboru nic nie daje. Zmienia się wyłącznie to, co może świadczyć o języku piszącego.

Poprawka objęła cztery witryny, na których zjawisko wystąpiło. Sprawdziliśmy ją wcześniej na prawdziwych wiadomościach - zarówno tych spamowych, jak i na zapytaniach od klientów, które muszą przechodzić bez przeszkód.

Zmieniamy domyślny adres ukrytego logowania z /logowania na /entry.

Wtyczka będzie też wyraźniej informować o samej zmianie - tak, by nie było wątpliwości, że od tej pory panel otwiera się pod innym adresem niż dotychczas.

Filtr antyspamowy odczytuje treść z pól formularza, które zna. Gdy trafiał na formularz o nietypowych nazwach pól, nie miał czego sprawdzić - i takie zgłoszenie przechodziło, nie zostawiając żadnego śladu w zestawieniu. W raporcie wyglądało to jak cisza, choć wiadomość doszła.

Wykryliśmy to, gdy bot wysłał formularz z podmienionymi nazwami pól. Wiadomość dotarła do skrzynki, a w statystykach nie było po niej nic.

Od tej wersji każde takie zgłoszenie jest odnotowywane. Zapisujemy wyłącznie nazwy pól, nigdy ich zawartości - to ma służyć diagnostyce, a nie gromadzeniu danych osób piszących przez formularz.

Zamówienia w sklepie i logowanie są z tego wyłączone, bo tam brak treści jest zjawiskiem normalnym, a nie podejrzanym.

Na tym etapie obserwujemy, jeszcze nie blokujemy. Zebrane dane pokażą, jakich pól używają boty - i dopiero wtedy dołożymy blokadę, żeby nie odciąć przy okazji prawdziwych zapytań.

Dwie nowe reguły z ostatnich wydań - blokada po adresie strony w treści oraz rozpoznawanie losowych ciągów znaków - działały poprawnie, ale w zestawieniu zapisywały się jako „powód nieokreślony". Wiadomości były zatrzymywane, tylko raport tego nie pokazywał.

Od tej wersji każde zablokowane zgłoszenie ma w zestawieniu właściwy powód. Nic to nie zmienia w samej ochronie - zmienia to, ile z niej widać.

Zdarza się, że aktualizacja jakiejś wtyczki nie przechodzi - bo autor wypuścił wadliwe wydanie, wygasła licencja albo zabrakło uprawnień do katalogu. Do tej pory witryna próbowała ponownie każdej nocy, bez końca: pobranie paczki, kopia zapasowa, rozpakowanie, sprawdzenie i cofnięcie zmian. Codziennie ten sam cykl i codziennie ten sam wynik.

Od tej wersji witryna liczy nieudane próby. Po trzeciej z rzędu odpuszcza tę jedną wtyczkę i zgłasza ją w panelu jako wymagającą uwagi. Pozostałe aktualizują się normalnie - wstrzymanie dotyczy wyłącznie tej, z którą jest problem.

Gdy autor wtyczki wyda kolejną wersję, wstrzymanie znika samo i witryna próbuje ponownie. Zwykle właśnie tak kończą się takie problemy.

Państwa własne ustawienia pozostają nietknięte. Jeśli któraś wtyczka została świadomie wyłączona z automatycznych aktualizacji, żaden mechanizm tego nie cofnie - decyzja człowieka ma zawsze pierwszeństwo.

Filtr języka sprawdzał całą treść formularza razem z odnośnikami. Boty rozsyłające fałszywe „wizytówki firmy" doklejają adres Państwa witryny do swojego linku - i jeśli w ustawieniach filtra znalazł się kiedyś ten adres, każda taka wiadomość przechodziła bez zatrzymania.

Od tej wersji odnośniki i adresy e-mail nie biorą udziału w rozpoznawaniu języka. Liczy się to, co nadawca naprawdę napisał, a nie to, co wkleił w link.

Lista niebezpiecznych adresów chroniła dotąd wyłącznie połączenia wychodzące z witryny. Formularza kontaktowego nie dotyczyła w ogóle - wiadomość z odnośnikiem do znanej strony spamerskiej trafiała do skrzynki tak samo jak każda inna.

Teraz ta sama lista filtruje również treść formularzy. Rozpoznawany jest sam adres w odnośniku, nigdy domena z adresu nadawcy - ta bywa podszyta pod zwykłego dostawcę poczty i blokowanie jej odcięłoby prawdziwych klientów.

Część kampanii spamowych nie powtarza żadnego stałego słowa - wysyła losowe ciągi znaków, za każdym razem inne. Żadna lista zakazanych zwrotów ich nie zatrzyma, bo nie ma czego wpisać na listę.

Doszedł więc rodzaj reguły opisujący kształt wiadomości, a nie jej treść. Pierwszy taki wzorzec rozpoznaje właśnie losowe ciągi znaków w polach formularza.

Skuteczność sprawdziliśmy na 1046 rzeczywistych zgłoszeniach z witryn klientów: zatrzymuje 80 wiadomości, w tym wszystkie, które wcześniej przechodziły - i ani jednego prawdziwego zapytania.

Wewnętrzny znacznik „trwa aktualizacja" potrafił zablokować się na stałe po czyszczeniu pamięci podręcznej. Skutek był podstępny: witryna przestawała się aktualizować, nie zgłaszając żadnego błędu - w kokpicie wyglądało to jak aktualizacja, która trwa i nigdy się nie kończy.

Teraz znacznik niesie godzinę startu, więc kolejny przebieg rozpoznaje porzuconą blokadę i przejmuje ją. Dodatkowo przy każdej aktualizacji wtyczka sama usuwa takie zablokowane znaczniki pozostawione przez starsze wersje.

Przeinstalowanie wtyczki nadaje witrynie nowy identyfikator. Panel rozpoznawał ją po adresie i zachowywał stary, przez co dalej widział licencję, ale przestawał dostawać cokolwiek innego: numer wersji, wynik kontroli, nocną konserwację.

Cisza była kompletna i niczym nieoznaczona. Aktywacja licencji odświeża teraz identyfikator, więc kontakt wraca sam.

Z listy zadań jednorazowych usunięte zostały „Gutenberg + Divi" oraz „Optymalizacja NightShiftWP". Przestały być potrzebne.

Baza była odczytywana w sposób, który przy każdej kolejnej porcji danych kazał jej przewijać wszystko od początku - im dalej w tabelę, tym wolniej. Na sklepie z ćwierć milionem wierszy nocny zrzut potrafił mielić bazę ponad osiem minut.

Teraz konserwacja czyta bazę dokładnie tak samo, jak robi to kopia uruchamiana ręcznie - ta sama baza schodzi w kilka sekund. Mniej obciążenia serwera w nocy, szybciej gotowa kopia.

Pliki dzienników błędów (debug.log, error_log) nie trafiają już do kopii. To zapisy diagnostyczne, a nie treść witryny - nie ma w nich wpisów, ustawień ani danych klientów, a po odtworzeniu witryny powstają od nowa.

Potrafią za to urosnąć bardziej niż cała reszta strony: rekordzista zajmował 233 MB przy 649 MB całej paczki i to on blokował wykonanie kopii.

Dzienniki, w których wtyczki zapisują rzeczy naprawdę potrzebne - jak historia płatności - zostają w kopii nietknięte.

Wyczyszczenie pamięci podręcznej potrafiło zostawić w witrynie znacznik „konserwacja w toku", którego nic już nie zdejmowało. Każdy kolejny nocny przebieg odbijał się od niego i kończył, zanim cokolwiek zrobił - bez aktualizacji, bez kopii, bez raportu. Witryna wyglądała na zdrową, a od tygodnia nic się na niej nie działo.

Znacznik ma teraz własny zegar. Jeśli poprzedni przebieg nie dokończył pracy, kolejny przejmuje go po godzinie i rusza dalej, a w raporcie widać wyraźnie, że poprzednia noc się nie powiodła.

Kopia potrafiła przewrócić się na jednym wielkim pliku: pakowanie wciągało go w całości do pamięci, proces ginął w połowie, a witryna zostawała bez żadnej kopii - i tak każdej nocy.

Pliki są teraz pakowane strumieniowo, prosto z dysku, więc ich rozmiar przestał mieć znaczenie. A gdyby mimo wszystko coś się nie udało, komunikat mówi wprost który plik i dlaczego, zamiast urywać się w pół słowa.

Jeśli w witrynie mieszka inna wtyczka do kopii zapasowych - Duplicator, UpdraftPlus, WPvivid, BackWPup, All-in-One WP Migration - jej archiwa są teraz pomijane.

Pakowanie kopii do kopii tylko podwaja wagę paczki i wydłuża całą operację. Na jednej z witryn takie zapomniane archiwum ważyło samo kilkaset megabajtów.

Nocny przebieg potrafił tylko oznaczyć dostępną aktualizację i liczyć na to, że WordPress zainstaluje ją sam - a ten mechanizm jest u nas świadomie wyłączony. Efekt: witryna tygodniami stała na starszej wersji, mimo że raport co noc wyglądał poprawnie.

Teraz wtyczka instaluje własną aktualizację sama, bez pośredników.

Zamiast wgrywać wszystko naraz, wtyczka wykonuje jedną aktualizację na dobę i trzyma się stałej kolejności: najpierw NightShiftWP, potem WordPress, potem motyw, na końcu wtyczki.

Jedna zmiana na noc oznacza, że gdy coś zacznie się zachowywać dziwnie, od razu wiadomo, po czym.

Dotąd trzeba było ręcznie zaznaczyć każdą wtyczkę, która ma się aktualizować - o świeżo zainstalowanej łatwo było zapomnieć i cicho zostawała w tyle.

Teraz jest odwrotnie: aktualizujemy wszystko, a odznaczasz tylko te pojedyncze, które mają zostać nietknięte - na przykład płatne wtyczki z wygasłą licencją.

Przy włączonym trybie blokady witryna miała odcięty kontakt z repozytorium WordPressa również w czasie własnego przebiegu konserwacyjnego - aktualizacje nie miały skąd pobrać plików.

Blokada obowiązuje teraz normalnie, ale na czas nocnej konserwacji wtyczka ma drogę wolną.

Włączona blokada rejestracji pilnuje teraz również roli administratora. Nowe konto nie dostanie najwyższych uprawnień - niezależnie od tego, czy nadaje je ktoś z kokpitu, czy złośliwy skrypt działający w tle.

To jeden z najczęstszych scenariuszy włamania: obok Twoich kont pojawia się cichy administrator, który zostaje w witrynie nawet po usunięciu zainfekowanych plików. Ta droga jest teraz zamknięta.

Konta, które już są administratorami, działają bez zmian - blokada dotyczy wyłącznie nadawania tej roli od nowa. Gdy sam potrzebujesz dodać administratora, wystarczy na chwilę wyłączyć to zadanie w sekcji Once.

Dotychczasowa blokada zamykała zakładanie kont wszystkim - także klientom sklepu, więc w witrynach z WooCommerce nie dało się jej używać.

Doszedł drugi wariant, przeznaczony dla sklepów: klienci normalnie zakładają konta w sekcji Moje konto i przy składaniu zamówienia, a pozostałe drogi rejestracji zostają zamknięte - razem z dodawaniem użytkowników z kokpitu.

Oba warianty wykluczają się wzajemnie: dla wizytówki wybierasz blokadę pełną, dla sklepu tę nową. Znajdziesz je w sekcji Once.

NightShiftWP nie wyłącza się już podczas własnej aktualizacji. Wcześniej mechanizm auto-aktualizacji traktował ją jak każdą inną wtyczkę i odłączał na czas podmiany plików - proces potrafił przerwać się w połowie i zostawić ochronę wyłączoną.

Od teraz aktualizacją NightShiftWP zajmuje się wyłącznie jej własny mechanizm, który nie przerywa działania ochrony. Na liście wtyczek w ustawieniach auto-aktualizacji NightShiftWP jest oznaczona etykietą Self-update zamiast przełącznika.

Po samodzielnej aktualizacji wtyczka od razu działa na nowej wersji. Wcześniej serwer mógł jeszcze przez jakiś czas trzymać w pamięci podręcznej poprzednią wersję - przez co panel pokazywał nieaktualny numer, a wtyczka potrafiła instalować tę samą aktualizację ponownie.

Teraz po każdej aktualizacji pamięć podręczna odświeża się automatycznie, bez żadnych działań z Twojej strony.

Tworzenie kopii zapasowej bardzo dużych witryn (wielogigabajtowych) przestało przerywać się przy długich operacjach. Backup działa teraz małymi krokami z żywym paskiem postępu - nie wyrzuca już do strony głównej w połowie i zawsze kończy pełną, spójną kopią.

Naprawiliśmy też dwie rzeczy, które potrafiły zablokować proces: pasek postępu utykający na kilku procentach przy dużych tabelach bazy oraz przerwanie backupu, gdy w jego trakcie zniknął tymczasowy plik pamięci podręcznej (cache). Teraz takie pliki są pomijane, a kopia powstaje do końca.

Pracujemy nad automatyczną blokadą adresu IP po kilku nieudanych próbach logowania. Typowy scenariusz ataku botów - setki prób zgadywania hasła - zostaje odcięty sam, bez Twojej interwencji.

Adres wraca do gry po krótkim czasie, więc przypadkowa pomyłka w haśle nie zablokuje Cię na stałe.

Szykujemy dwuetapową weryfikację logowania - obok hasła drugi, jednorazowy kod. Nawet jeśli ktoś pozna Twoje hasło, bez drugiego składnika nie wejdzie do panelu.

Dodatkowa warstwa ochrony konta administratora, w parze z blokadą ataków na logowanie.

Planujemy codzienny skan treści pod kątem wstrzykniętych linków i ukrytych sekcji - reklam kasyn, spamu SEO i przekierowań, które malware potrafi doklejać niewidocznie do stron i wpisów.

Wczesne wykrycie takiej infekcji pozwala zareagować, zanim zaszkodzi pozycji strony w wyszukiwarce.

Domykamy pełną polską wersję interfejsu wtyczki - wszystkie ekrany, komunikaty i podpowiedzi po polsku.

W kroku diagnostyki (wersja darmowa) pokażemy czytelne zestawienie funkcji premium - żeby od razu było wiadomo, co dodatkowo chroni stronę po przejściu na wersję pełną.

Dla witryn na starszych serwerach z PHP 7.4 rozważamy osobną, nieoficjalną wersję wtyczki. Główna linia działa na PHP 8.4+, ale część stron wciąż stoi na starszym hostingu.

Wariant 7.4 byłby wydaniem pomocniczym, z ograniczonym wsparciem - rekomendujemy aktualizację PHP tam, gdzie to możliwe.

Gdy wyłączysz auto-aktualizację dla konkretnej wtyczki (np. płatnej, której licencja wygasła i tak nie da się jej zaktualizować automatycznie), taka wtyczka nie jest już liczona jako błąd ani jako zaległa aktualizacja w panelu.

Wcześniej odznaczona wtyczka potrafiła zostawić czerwony licznik błędu albo żółty licznik oczekujących - mimo że świadomie pominąłeś jej aktualizację. Teraz panel pokazuje wyłącznie to, czym auto-aktualizacja faktycznie się zajmuje.

Od teraz Pipeline priorytetowo wymusza aktualizację WordPressa - rdzeń systemu jest sprawdzany w pierwszej kolejności przy każdym przebiegu. Dzięki temu witryna nie zostaje na przestarzałej wersji, nawet jeśli aktualizacja wcześniej się nie zainstalowała.

Zwykły napis NightShiftWP w panelu wtyczki zastąpiliśmy prawdziwym, graficznym logo. Drobna rzecz, ale panel od razu wygląda schludniej i bardziej rozpoznawalnie.

Przesuń suwak poniżej, żeby porównać dawny i nowy nagłówek.

Przed Po

Tryb blokady chroni witrynę przed niechcianymi zmianami. Uprościliśmy go do jednego, przejrzystego mechanizmu - zamiast dwóch trybów, które łatwo było pomylić. Efekt: mniej ustawień i bardziej przewidywalna ochrona.

Zmiana przenosi się sama na już działających stronach, bez potrzeby ponownej konfiguracji.

Nowa opcja pozwala wstrzymać zakładanie kont na stronie. Po włączeniu nikt nie zarejestruje się samodzielnie - prosty sposób na odcięcie fali spamowych i botowych rejestracji, które bywają furtką do przejęcia witryny.

Opcję można w każdej chwili włączyć i wyłączyć, zależnie od tego, czy strona akurat przyjmuje nowych użytkowników.