Halucynacje Antispam Bee

Uważni czytelnicy mogą pamiętać, że na blogu stosuję kilka metod zwalczania spamu w komentarzach. W kolejności od najbardziej ręcznych do najbardziej automatycznych będą to: ręczna moderacja, wtyczka Antispam Bee, hCaptcha oraz wycinanie IP znanych z nadużyć na poziomie iptables. Dziś będzie o wtyczce.

Wtyczka Antispam Bee radziła sobie nieźle. Wśród sporej ilości opcji, dotyczących tego jak rozpoznawać spam i co z nim dalej robić, posiada ona też możliwość generowania statystyk blokad spamu widocznych w dashboardzie WordPressa. Oczywiście korzystam, bo dzięki temu czytelnemu zestawieniu widzę, co w spamie piszczy bez konieczności wchodzenia w komentarze.

Do tej pory wyglądało to tak, że zerkałem na statystyki na wykresie, jeśli pojawiał się wzrost, to wchodziłem w komentarze i patrzyłem na IP z którego przyszedł spam i ogólnie zastanawiałem się, czy może trzeba coś ulepszyć. Oczywiście jeśli miałem wenę, bo blokady przez iptables, captchę czy wtyczkę Antispam Bee są totalnie bezobsługowe. Znaczy normalnie nie muszę w ogóle dotykać spamu, jedyne co robię, to zatwierdzam prawdziwe komentarze[1]. No i było tak, że jak wtyczka zgłosiła 2 zablokowane, to te 2 były w spamie w komentarzach. W każdym razie tak mi się wydawało – nie zauważyłem rozbieżności.

Problem

Po niedawnych zmianach w blokadach IP na poziomie iptables, ilość blokowanych spamów była stabilna i rekordowo niska – 1-2 próby dziennie. Jednak w pewnym momencie zobaczyłem coś takiego:

Statysytki Antispam Bee 22.03 – 06.05

Wzrost zaczął się 22 kwietnia i jest całkiem spory. Największa ilość widoczna na wykresie to 15 spamów. Postanowiłem poszukać, cóż to za IP i… spotkała mnie niespodzianka. Ostatni spam widoczny w komentarzach jest właśnie z 22 kwietnia. Po tej dacie nie mam żadnego komentarza uznanego za spam w bazie. A wtyczka Antispam Bee radośnie zgłasza.

Szukałem bezpośrednio w bazie, ale nie udało mi się znaleźć ani komentarzy uznanych za spam, ani miejsca przechowywania statystyk. Ostatecznie w ramach testu wyłączyłem wtyczkę na kilka dni i… przyszedł jeden spam do ręcznej moderacji. Przez kilka dni.

Rozwiązanie

Zastanawiałem się, co tu się stało i… chyba znalazłem rozwiązanie. Wszystko wskazuje na to, że wtyczka Antispam Bee jednak nie pozazdrościła AI i nie halucynuje. Ani nie próbuje pokazać, jaka jest przydatna uciekając się do przedstawiania fałszywych wartości. Chodzi o kolejność działania blokad. Antispam Bee działa przed czy też obok hCaptcha. Komenatrz, aby trafił do bazy WordPressa, musi mieć poprawnie rozwiązaną captchę. Jej brak nie przeszkadza jednak Antispam Bee w rozpoznaniu spamu i uwzględnieniu go w statystykach. Czyli ten wzrost to faktycznie próby wysyłki spamu z IP, które nie są na listach, ale nieudolne, nie uwzględniające tego, że na blogu jest captcha.

Wygląda, że trzeba się będzie przeprosić z wierszem poleceń przy wyszukiwaniu IP do blokowania, przynajmniej chwilowo. Stosowne polecenie:

egrep "POST.*wp-comments-post.php" access.log | grep " 400 " | awk '{print $1}' | sort | uniq -c | sort -n

Wtyczkę Antispam Bee polecam nadal. Jeśli ktoś jest ciekaw, czemu nie korzystam z Akismet, to odpowiedź znajdzie w tym wpisie.

[1] Tak się teraz zastanawiam, że działa to tak dobrze, że w zasadzie mógłbym wyłączyć moderację w ogóle. Z drugiej strony już przywykłem, a komentarzy nie ma zbyt wiele, więc żaden problem.

WordPress i kłopoty z cache – rozwiązanie

Od pewnego czasu na blogu występuje problem. Objawia się on tym, że niektóre wpisy nie wyświetlają się w całości, są jakby obcięte. Zauważyłem to parę dni temu, ale wtedy uznałem za jednorazowy wybryk i machnąłem ręką. Po części zwaliłem sprawę na cache, bo jego wyczyszczenie pomogło. Po głowie jako przyczyna chodziło mi też coś w stylu DDoS, który po publikacji artykułu na blogu uprawiają serwery Mastodon. I zupełnie nie miałem czasu na analizę.

Jednak dotarły do mnie sygnały (dzięki!) o tym, że sprawa się powtarza, postanowiłem przyjrzeć się bliżej. Dziś wszedłem z telefonu na ten sam wpis i… problem wystąpił ponownie. Z racji pory dnia ruch powinien być niewielki, więc warunki do diagnostyki powinny sprzyjać.

Trzy słowa o setupie

Blog jest dumnie wspierany przez WordPress, wykorzystywany jest nginx oraz php-fpm 8.2. Do tego dość intensywnie korzystam z wtyczek do WordPress. W szczególności do różnych optymalizacji i cache, co raczej nie ułatwi diagnostyki. Dużo elementów ruchomych, ingerencja w treść serwowanej występuje w wielu miejscach.

Wspomniałem o pluginie do cache jako jednym z podejrzanych. Konfiguracja Cache Enabler wygląda następująco:

Konfiguracja Cache Enabler
Screenshot konfiguracii Cache Enabler

Objawy i logi

Obcięty wpis wygląda tak:

Ucięty wpis na blogu
Screenshot uciętego wpisu

Cache był wygenerowany o 07:48 i pokrywa się to z czasem wejścia z telefonu widocznym w access.log.

drwxr-xr-x 2 www-data www-data 4096 Sep 24 07:48 pentagram-cerberus-p6361-rzut-okiem-na-bezpieczenstwo

W logu php-fpm nic specjalnego. Chwilę wcześniej widać raczej nie mogące mieć wpływu

[24-Sep-2023 07:44:23] WARNING: [pool www] seems busy (you may need to increase pm.start_servers, or pm.min/max_spare_servers), spawning 8 children, there are 1 idle, and 10 total children
[24-Sep-2023 07:44:27] WARNING: [pool www] child 20688 exited on signal 9 (SIGKILL) after 33847.200506 seconds from start
[24-Sep-2023 07:44:27] NOTICE: [pool www] child 25769 started

Diagnostyka

Problem występował na różnych przeglądarkach, także w trybie prywatnym. Zarówno na desktopie, jak i mobile. Sprawdzenie wersji zapisanej w cache pokazało, że jest ona błędna. Dobry znak, bo raczej można wykluczyć wpływ JSów. Były one podejrzane, bo wprawne oko dostrzeże, że polecenie curl przechodzi w pewnym momencie w kod źródłowy strony związany ze skryptem od statystyk Matomo.

Udało mi się ustalić, że wyczyszczenie cache pomaga, ale… tylko na pierwsze wyświetlenie. Kolejne wyświetlenia są już błędne. Sam problem występował niezależnie od obsługi JS. Czy to Firefox, czy links2, czy lynx – pierwsze wyświetlenie było poprawne, kolejne błędne.

Na pierwszy ogień poszły więc ustawienia wtyczki robiącej cache. W Minify HTML in cached pages including inline CSS and JavaScript wyłączyłem miniaturyzację CSS i JS. Nie pomogło.

Natomiast zupełne wyłączenie tej opcji jak najbardziej pomogło. Winnym okazała się zatem jedna z opcji wtyczki Cache Enabler w wersji 1.8.13. Takie tam ryzyka optymalizacji. Zgłosiłem problem na GitHub i zobaczymy co będzie dalej.

Rzuciłem jeszcze okiem na przyczynę. Prawdopodobnie chodzi o niepoprawne, zachłanne parsowanie komentarzy. Obcięcie następuje po pierwszym znaku *.
Gecko/20100101 Firefox/60.0' -H $'Accept: */*' -H $'Accept-Language: en-US,en;q=0.5'
natomiast linia bezpośrednio przed tym, co się zaczyna pojawiać, wygląda tak:
/* tracker methods like "setCustomDimension" should be called before "trackPageView" */

Social, czyli gra Elona

Kolejna „awaria” Twittera. Lub też skutek niefrasobliwego zarządzania, zależy jak spojrzeć. Co tym razem? Ludzie się skarżą, że nie mogą czytać postów. Dlaczego? Bo wprowadzono zmiany…

Główne zmiany to limit przeglądanych tweetów, w pierwszej wersji wynoszący 600 dla kont niezweryfikowanych. Czytaj: kont darmowych. Jeszcze mniej dla kont świeżych. Płacący dostają dziesięć razy więcej. Nie jest to jednak jedyna zmiana. Aktualnie nie można przeglądać wpisów na Twitterze, jeśli nie jest się zalogowanym. Oficjalny powód zmian? Scrapowanie treści. Znaczy czytanie. Ktoś umieścił coś w sieci, inni czytają, a właścicielowi platformy się to nie podoba.

Przypuszczam, że gdyby czytający płacili, problemu by nie było i właścicielowi by się podobało. Wydaje mi się bowiem, że Twitter dla Elona to taka zabawka, która służy do zabawy w grę „ile pieniędzy można wycisnąć z platformy”. I zupełnie nie mają znaczenia inne aspekty, typu wolność słowa, użyteczność platformy, czy liczba użytkowników.

Oczywiście zaczęło się wieszczenie „trzeciego końca Twittera”. Ludzie komentują kolejny wzrost rejestracji kont na Mastodonie. Przypuszczam, że sprawa za moment rozejdzie się po kościach. Elon pokręci gałeczką, z 600 zrobi się 1000, albo i trochę więcej. Jak poprzednio, część użytkowników odejdzie, część uzna, że warto zapłacić.

Uważam, że na Twitterze zmierzamy wprost, szybciej lub wolniej, do modelu z regularnym paywallem. Model znany i w Polsce choćby w wykonaniu Agory. Jakieś szczątkowe dostępy za darmo, a jak chcesz czytać, to płać. Jedyna różnica jest taka, że Agora płaci autorom, a na Twitterze ludzie będą płacili za dostęp do treści tworzonych przez znajomych. Niemożliwe? Nic podobnego, przecież to nie rewolucja, tylko klasyczne gotowanie żaby.

Powiedzmy sobie wprost, Mastodon jest w tym równaniu pomijalny. Liczba zarejestrowanych kont to 10 mln na koniec marca, obecnie ok. 13 mln. Zarejestrowanych, nie aktywnych. Zresztą, miałem o tym notkę. Dla porównania, Twitter to jakieś 400 mln, z czego połowa korzysta codziennie. Przypuszczam, że dodatkowy milion czy dwa założonych kont na Mastodonie jest zupełnie pomijalny. Zwłaszcza, jeśli po zmianach wzrośnie nieco ilość zweryfikowanych kont na Twitterze, a użytkownicy nie przeniosą się, usuwając konta na Twitterze, tylko założą obok.

Zresztą Mastodon ma swoje problemy. Jeden to UX, drugi to… brak wsparcia dla fediwersum u „dużych”. Pamiętacie jak na początku Tumblr zapowiadał, że zaraz wprowadzi wsparcie dla fediwersum? „Zaraz” trwa już osiem miesięcy, a temat ucichł. Spiskowa teoria mówi, że Automattic, czyli właściciel WordPress.com i Tumblr wcale nie przejął wtyczki activypub po to, by ją rozwijać, a tylko po to, by kontrolować, żeby się nie rozwinęła. Bo wolne, zintegrowane ze sobą social media ktoś mógł uznać za zagrożenie dla ww. platform blogowych. Zresztą pewnie słusznie.

Na koniec cebulowa porada dla użytkowników Twittera. Jeśli korzystacie z tego portalu w przeglądarce, to okazuje się, że wtyczka uBlock origin nie tylko blokuje reklamy na Twitterze, ale też pozwala obejść limity. Nie liczyłem oczywiście czytanych tweetów, ale wczoraj korzystałem dość intensywnie i żadnych blokad nie zauważyłem. Przez moment mignął mi komunikat o limicie, ale ledwo go zauważyłem, bo zniknął i posty się wczytały.