Spam o grze na giełdzie – wzorzec, sprawdź logi

Od pewnego czasu dostaję sporo spamu dotyczącego gry na giełdzie. Polsko brzmiące From, w treści zwykle niemieccy uczeni, gra na giełdzie, sztuczna inteligencja oraz całą dobę. W różnych wariantach. Do tego link do strony.

Z tego co mi się obiło o ekran, nie tylko ja to dostaję, a z tego co widzę po skrzynkach – filtry nadawców sobie nie radzą. Poza tym, myślałem, że się skończyło, ale widzę, że nadchodzi kolejna fala.

Zgłaszałem do SpamCopa (nie bez trudności) i akurat w tej kwestii dostałem kilka odpowiedzi z podziękowaniami za zwrócenie uwagi na problem, poza tym, jest charakterystyczny ciąg w URLu, więc wygląda na działanie jakiegoś niezbyt znanego robaka.

Mianowicie wszystkie(? albo prawie wszystkie) URLe, do których odsyłają maile ze spamem zawierają ciąg:

.php?b=2

Zapewne jeśli prowadzi serwer WWW, to warto grepnąć logi pod tym kątem. Kod 200 będzie oznaczał, że prawdopodobnie strona jest zainfekowana.

Zatem prośba do adminów WWW o sprawdzenie logów pod tym kątem, a do adminów poczty o próbę uwzględnienia tego w regułach antyspamowych.

PS Jakby przyjrzeć się bliżej, to pewnie nawet okaże się, że problem dotyczy tylko starej wersji któregoś CMSa, ale tego nie chce mi się już analizować.

Bezpieczniejsze i wydajne łącze mobilne

Nieco ponad pół roku temu opisałem możliwe sposoby przyspieszania łącza internetowego. Znowu jestem na urlopie, bez dostępu do „normalnego” łącza i korzystam z Aero2. Jak pisałem, najbardziej, ze względu na łatwość uruchomienia, przynajmniej w środowisku Linux, odpowiada mi wariant z socks proxy i ssh.

Poza tym, mignęła mi ostatnio – zupełnie nie pamiętam przy jakiej okazji, ale niezwiązana z tym tematem – informacja o polipo, czyli cache’ującym serwerze proxy, pomyślanym o użytku osobistym, domowym lub małych grupach użytkowników. W stosunku do pełnoprawnego proxy WWW, czyli popularnego squida ma parę ciekawych cech: jest lekki i szybki, prosty w konfiguracji, może robić za mostek między sieciami IPv4 i IPv6, umie socks proxy, posiada pewne opcje umożliwiające łatwe filtrowanie reklam i zwiększanie prywatności.

W kombinacji z tunelem SSH z którego korzystam, polipo będzie pełnił rolę cache oraz translatora socks proxy na zwykłe proxy WWW. O ile większość przeglądarek jakoś obsługuje socks proxy, o tyle chyba tylko w Firefoksie można to po prostu wyklikać, pozostałe wymagają zabawy z wierszem poleceń w celu uruchomienia obsługi. Poza tym, mając proxy WWW w systemie można je wykorzystać nie tylko do przeglądarek, ale do wszystkich programów, które umożliwiają ustawienie proxy HTTP.

Czyli całe rozwiązanie składa się więc z dwóch elementów: tunelu SSH, zapewniającego szyfrowanie przesyłanych danych (bezpieczeństwo) oraz kompresję (wydajność), oraz polipo zapewniającego cache plików (wydajność). Ponieważ moje łącze mobilne jest wolne (Aero2; DOWN/UP 512/256 kbps), zdecydowałem się umieścić serwer proxy na laptopie, przed tunelem SSH (patrząc od strony przeglądarki). Wydaje mi się, że tak będzie wydajniej – część zapytań nie trafi w ogóle do tunelu. Możliwa jest też konfiguracja z proxy uruchomionym na serwerze terminującym tunel – patrz linki na końcu wpisu. Topologia rozwiązania wygląda zatem następująco:

Internet - serwer - tunel SSH - polipo - przeglądarka

Serwer to maszyna z Linuksem (może być VPS dowolnego typu), serwerem SSH i przyzwoitym (optymalnie: lepszym od naszego mobilnego łączem).

Uruchomienie tunelu:

ssh -CND 9000 user@serwer

Konfiguracja serwera polipo (bardzo podstawowa, dostępnych jest znacznie więcej opcji, ale ich opis wykracza poza tematykę tego wpisu; cat /etc/polipo/config):

logSyslog = true
logFile = /var/log/polipo/polipo.log
socksParentProxy = 127.0.0.1:9000
socksProxyType = socks5

Następnie ustawiamy w przeglądarce WWW jako HTTP proxy: adres 127.0.0.1 i port 8123 (domyślny port na którym słucha polipo). Gotowe.

Uwaga dotycząca bezpieczeństwa: z uwagi na to, że w ww. rozwiązaniu szyfrowany jest tylko ruch HTTP, i tylko ten przechodzący przez proxy, należałoby pewnie ograniczyć dostęp dla pozostałego ruchu wychodzącego na firewallu. Jeszcze lepszym rozwiązaniem pod względem bezpieczeństwa, z uwagi na ew. spoofing DNS i uniezależnienie się od DNSów dostawców sieci, byłby VPN. Ale w tym przypadku nie to jest priorytetem, poza tym, korzystam z lokalnego serwera DNS.

Linki:

  1. Opis konfiguracji Aero2, wvdial i modemu Huawei E3131.
  2. Alternatywna konfiguracja z polipo uruchomionym na serwerze.

PUM

Jakiś czas temu zacząłem korzystać z Uptime Monitor. Przyznaję, że jestem zadowolony, do pełni szczęścia brakowało mi czegoś, co wystawi moje uptime’y na WWW. Tzn. jest sporo fajnych narzędzi, rysujących ładnie i live, tzn. z autoodświeżaniem, ale… nie byłem przekonany do pomysłu publikacji kluczy API. Tym bardziej, że w niektórych przypadkach udostępnienie klucza wiąże się z z podaniem danych hosta, loginu i hasła do htpasswd itp.

Wolałbym mieć możliwość ukrycia nazwy/IP i ogólnie nie podawania zbyt wielu informacji, zwł. klucza API. Zauważyłem też, że nie ma (a przynajmniej nie znalazłem) nic do obsługi Uptime Monitora w Perlu. Stwierdziłem, że generowanie statycznego HTML (docelowo) z crona jest zupełnie wystarczające, a ew. autoodświeżanie prosto można załatwić JSem czy IIRC nawet polem META w HTML (koła nie odkrywam, „konkurencja” też tak robi.

I w ten sposób powstał PUM czyli Perl Uptime Monitor. 😉 Jest możliwość nadpisania nazwy, jest możliwość generowania uptime dla danego okresu (ilość dni wstecz). Brakuje opakowania wyniku w HTML (wyniki na STDOUT póki co…), ale to wkrótce… W sumie nie ma problemu z pobraniem danych do wykresu czasu odpowiedz, ale nie planuję póki co. Zachęcam do forkowania i zgłaszania pull requestów, ew. pomysłów w komentarzach.