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.

FireHOL – brak aktualizacji

Przy okazji wpisu o antyspamie na WordPress pisałem o wykorzystaniu list z doskonałego projektu FireHOL do blokowania ruchu. Działało świetnie, działać przestało. Przynajmniej częściowo. W repozytorium na Githubie widać bowiem, że ostatnia aktualizacja jest sprzed dwóch miesięcy.

Sprawdzając dokładniej trafimy na issue Github lists no longer being updated. Listy budowane są przy pomocy crona. 23 marca miała miejsce zmiana klucza SSH używanego przez Github. Tego samego dnia przestało się aktualizować repo FireHol. Przypadek?

I tak sobie radośnie aktualizacje leżą od blisko dwóch miesięcy. To może nie być po prostu dłuższy urlop…

W każdym razie, jeśli ktoś korzysta z powyższych list i zależy mu na aktualizacjach, to polecam przepiąć się na wersję bezpośrednio ze strony projektu. Dostępnej pod linkiem download local copy dla każdej z list. Te są aktualizowane.

I tak to się w tym IT/security kręci…

UPDATE: To nie jest tak, że powstał ten wpis i over. Założyłem kolejne issue, na wypadek gdyby autor przeoczył wcześniejsze. Napisałem też maila. Póki co cisza.

WordPress antyspam

Po raz kolejny musiałem zająć się problemem spamu w komentarzach na blogu. Przesiadka na hCaptcha pomogła na dłuższy czas, ale pod koniec lipca zabezpieczenie przestało działać[1]. Chwilę po tym, jak pojawiły się pierwsze komentarze, które przeszły hCaptcha, ruszyła lawina. Może raczej lawinka, bo 1-2 spamy dziennie to niewiele. Tak czy inaczej, wygląda, albo że spamerzy, że spamerzy szybko się uczą, albo mają bazę, który blog jaką ma captchę[2], albo hCaptcha istotnie się pogorszyła, albo ilość prób wzrosła na tyle, że coś się zaczęło przebijać[3]. A może wręcz znaleziono sposób na jej omijanie? Tematyka i języki różne, bez ładu i składu. Jedyne co pamiętam, to że zaczęło się od Azji, konkretnie pierwsze spamy wysłane w tej serii do mojego WordPressa były po… wietnamsku.

Garść statystyk

Zamieściłem statystyki poprzednio, więc zrobię to i teraz. Pomiędzy 20.06.2021 a 23.07.2022 zupełny brak spamu. W okresie od 23.07.2022 do 08.11.2022 73 sztuki. W 108 dni średnio 0,67 spamu na dobę. OK, to nie 1-2 dziennie, ale nadal sporo.

CAPTCHA

Moją pierwszą reakcją było zwiększenie trudności w panelu hCaptcha. Z najniższej na średnią. Niestety, nie zauważyłem spodziewanego efektu. Rozważam jeszcze powrót do reCAPTCHA. Jeśli spamerzy faktycznie mają bazę z typem zabezpieczeń na danym blogu, to taka zmiana może nieco popsuć szyki. Niemniej, skoro kiedyś nie dawała rady, to czemu teraz miałaby pomóc? Inna opcja to zwiększenie trudności do maksimum. Tylko to utrudni też życie zwykłym czytelnikom, a tego nie chcę.

Blokowanie IP

Zauważyłem, że IP z których zamieszczany jest spam w komentarzach, są raczej wątpliwej reputacji. Zatem kolejnym krokiem, połączonym z migracją hostingu, było zablokowanie na iptables z wykorzystaniem ipset tych IP, które są listowane w wybranych listach projektu firehol. Nieco pomogło na spam, zdecydowanie nie całkowicie. Ale i tak gorąco polecam to rozwiązanie, bo ilość ruchu z tych IP jest całkiem spora[4]. Niczego pozytywnego ze strony botnetów, open proxy itp. wynalazków się nie spodziewam, więc czemu nie zablokować?

Wtyczki

Skoro wycinanie IP nie pomogło, to pora sięgnąć po broń ostateczną. Tu jest WordPress, tu się instaluje wtyczki! Wtyczek obiecujących rozwiązanie spamu w komentarzach jest dla WordPressa sporo.

Akismet

Ponieważ kolejny raz polecono Akismet w komentarzach wpisu, więc zacząłem od niego. Pamiętam, że kiedyś już się przymierzałem do tego rozwiązania i odrzuciłem je. Po pierwsze, wymaga założenia osobnego konta. To mógł być wtedy wystarczający powód do odrzucenia. Po drugie, Akismet jest płatny. Tzn. teoretycznie jest pay what you want, ale nie da się zapłacić $0, jeśli ma się jakiekolwiek reklamy na blogu. Zaś what you want to minimum $1 miesięcznie. Tak się składa, że na niektórych stronach mam reklamy. Przynoszą grosze, ale są, a zakładanie konta, podawanie karty kredytowej to trochę za dużo, żeby przetestować rozwiązanie. Poza tym, skończyło by się tak, że wyświetlam reklamy, aby zapłacić za wtyczkę blokującą spam. Za którą muszę płacić, bo mam reklamy.

Antispam Bee

Kolejna popularna wtyczka antyspamowa dla WordPressa to Antispam Bee. Jest darmowa, wygląda sensownie, ma sporo więc dostała szansę. Trochę zdziwiło mnie działanie. Po włączeniu chciałem przetestować, wysłałem komentarz i… bez zmian, trafił od razu do moderacji, bez żadnych oznaczeń. Aż zwątpiłem, czy wtyczka działa przed moderacją, czy po. Jednak pierwszy spam pokazał, że wtyczka działa. Przed moderacją, a wykryty spam już nie niepokoi moderatora. Gdybym nie włączył powiadomień mailem, to bym nie zauważył. Znaczy pełen automat. Potrzeba trochę czasu, by ocenić skuteczność, ale wygląda obiecująco.

[1] Być może ma to jakiś związek ze zmianą hostingu, która koreluje czasowo. Tylko to mogłoby tłumaczyć jedynie znalezienie bloga, nie działanie zabezpieczeń.
[2] Tylko wtedy szkoda, że chyba nie ma w tej bazie pola „ręczna moderacja komentarzy, odpuść sobie”.
[3] Już po napisaniu tego wpisu zrobiłem szybką analizę i faktycznie, z ruchu wytypowanego jako boty zamieszczające spam, 95% dostaje HTTP status code 400. Pozostałe 5% dostaje 200.
[4] Aktualnie korzystam z dwóch list: stopforumspam oraz blocklist.net.ua. Kompromis między ilością IP (ok. 300 tys.), a efektem. Może się zmieniać, bo dodanie kolejnej listy jest trywialne.