Tag: skrypt

Opublikowane w

Jak zrobić kuku spamerowi?

Jak wielu innych ludzi, darzę spamerów czystym i płomiennym uczuciem. Jakiś czas temu popełniłem automat do wykrywania spamu na Blox. W zasadzie, to tych skryptów jest kilka i raczej dane zbierają się „na kiedyś”, niż działa to produkcyjnie, ale czasem coś tam podeślę do blokowania. Niemniej, nie jest to pełny automat.

Jeśli chodzi o pocztę, to nie jest u mnie ze spamem źle. Łącznie na wszystkie konta dostaję jakieś małe pojedyncze sztuki dziennie. Część odsiewają dostawcy poczty, przytłaczającą większość tych nielicznych, które przejdą oznacza Thunderbird.

Dodatkowo, jeśli już coś do mnie dotrze, to zwykle trafia na Spamcopa (polecam zarejestrowanie się). Roboty z tym tyle, co kliknięcie Forward i linka w mailu, więc niewiele, a powiadamiane są wszystkie powiązane abuse. Polecam rejestrację. Czasem nawet odpiszą, że zablokowali (i to niekoniecznie nadawcę, bo potrafią reagować także właściciele domen/hostingów na których znajduje się „reklamowana” strona. Tak czy inaczej, o ile nie zadziała to pewnie na spam o niebieskich pastylkach wysyłanych z botnetów (ale liczę, że to odpada na etapie dostawcy poczty, zresztą mało tego typu dociera do mnie), to działa[1] na byznesmenów wysyłających zapytania o możliwość wysłania oferty handlowej do adresatów z baz pozyskanych z ogólnodostępnych źródeł. Znaczy, tłumacząc na polski: na spamerów wysyłających spam, bo (polskie) prawo prawem, ale o tym, czy wiadomość była zamówiona decyduje jednak odbiorca.

Niedawno, podczas szukania rozwiązań antyspamowych trafiłem na ciekawą stronę Email Labirynth, która generuje losowe adresy email w celu zaśmiecenia baz danych harvesterom, a w konsekwencji spamerom. Czyli po pierwsze stracą czas zbierając te adresy, po drugie stracą czas wysyłając maile na nieistniejące adresy, a po trzecie jest spora szansa, że dzięki takim wysyłkom trafią na RBLe. Nie jestem przekonany o skuteczności, ale spróbować IMO nie zaszkodzi. Sceptykom twierdzącym, że spamerzy nie mogą być aż tak głupi od razu mówię, że nie tylko mogą, ale są. Może nie wszyscy, ale większość. No i zwykle mają słabe automaty, a nadzór ludzki kosztuje.

W każdym razie powyższe rozwiązanie ma IMO kilka wad:

  • Brak spamtrapa na każdej stronie. IMHO na każdej(?) stronie wśród generowanych maili powinien być także spamtrap w celu automatycznego zgłaszania IP korzystających z harvestowanych adresów email do abuse/RBLi.
  • Stały adres strony. Wystarczy szczątkowa inteligencja, by nie harvestować tam adresów email.
  • W pełni losowe loginy. Trochę wada, trochę zaleta. W każdym razie wyglądają mało naturalnie i przy odrobinie wysiłku można je odsiać.
  • Brak lokalizacji. Wiadomo, że spamerzy celują z niektórymi produktami raczej w określone grupy klientów, np. klientów z Polski. Dane z ww. strony zdecydowanie nie wyglądają na bazę polskich klientów email.

Koniec końców postanowiłem zrobić swoje rozwiązanie realizujące podobny cel (oczywiście Perl). Na razie mam opracowane częściowe rozwiązanie[2] dla dwóch ostatnich punktów. Punkt drugi też będzie rozwiązany, bo zamierzam opublikować gotowca, którego każdy będzie mógł podpiąć na swojej stronie.

Ponieważ pewnie trochę czasu będę miał dopiero w przyszły weekend, liczę do tego czasu na uwagi dot. sensowności i ew. innych funkcjonalności.

[1] Działa, znam trochę środowisko hostingowe. Przyzwoite hostingi nie przepadają za wysyłającymi spam do zaśmieconych baz adresów email, a z tego co wiem w polskich firmach hostingowych abuse raczej działa.

[2] Jak dam sobie na luz z perfekcjonizmem, to pewnie uznam je za docelowe, przynajmniej w pierwszej wersji.

UPDATE: No i uruchomiłem. Póki co wersja testowa karmnika z adresami email wisi tu.

Opublikowane w

Własna namiastka dyndns

Po ostatniej akcji Microsoftu z przejęciem i zablokowaniem domen należących do No-IP miałem przez moment umiarkowany problem z dostępem do jednej z moich maszyn, bo nie znałem IP. Nic krytycznego i szybko rozwiązałem, ale stwierdziłem, że warto by się zabezpieczyć na przyszłość. Początkowo chciałem uruchomić po prostu innego dostawcę dyndns, z inną domeną, co dałoby całkiem niezłą – jak mi się wydaje – redundancję w tym względzie, ale prowizorycznie uruchomiłem coś innego, własnego i znacznie prostszego. W komentarzu do poprzedniego wpisu padło pytanie co dokładnie zrobiłem, więc opisuję.

Tak się składa, że mam serwer dedykowany ze stałym IP (nie jest konieczne zamiast tego można skorzystać z domeny), na którym stoi serwer WWW (lighttpd). Na wszystkich maszynkach potrzebujących dyndns mam dostęp do crona (zresztą, korzystałem z crona już przy zwykłym koncie dyndns, patrz update wpisu). Rozwiązanie jest proste: klient wywołuje okresowo unikatowy URL na moim serwerze, serwer okresowo parsuje log w poszukiwaniu tego unikatowego ciągu znaków i zapisuje IP z którego nastąpiło odwołanie w określonym pliku.

Poniżej wklejki ze wszystkimi onelinerami (gotowiec dla lighttpd, w przypadku innego serwera WWW trzeba dostosować):

# po stronie klienta*/5 * * * * /usr/bin/wget -4 -q -O /dev/null http://mojadomena.com/losowyciagznakow4346456543324645 > /dev/null
 # po stronie serwera*/5 * * * * /usr/bin/awk '/losowyciagznakow4346456543324645/ {ip=$1} END {print ip}' /var/log/lighttpd/access.log > /var/www/dyndns_host1.txt
 # pobranie IPwget -O - http://mojadomena.com/dyndns_host1.txt

Po namyśle, rozwiązanie nawet lepsze niż drugi dostawca dyndns. Mniej kont, prostsza konfiguracja, mając stałe IP na upartego można całkowicie uniezależnić się od DNSów, jeśli ktoś odczuwa potrzebę.

Oczywiście nie od razu tak to wyglądało, w szczególności po stronie serwera był grep, awk, tail w użyciu. Ale skoro da się wszystko załatwić awk (a nie tylko wyświetlanie określonej kolumny, chyba najczęstsze zastosowanie awk…), to czemu nie? Tu polecam zbiór przydatnych onelinerów w awk.

UPDATE: IPv6 się popularyzuje. Okazało się, że mój skrypt nie działa poprawnie, bo łączenie między maszynami następuje po IPv6. Dodany parametr -4 do wget w celu naprawy tego problemu.

Opublikowane w

Piwik, czyli fajne darmowe statystyki na stronę

O statystykach dla stron Piwik usłyszałem dawno temu. Idea wolnego odpowiednika Google Analytics[1] bardzo mi się spodobała, ale do instalacji nie doszło. Powód prozaiczny – nie miałem maszyny 24/7 działającej na sensownym łączu i posiadającą sensowną moc obliczeniową. Sensowną, tj. taką, żeby instalacja MySQL nie wydawała mi się zabójstwem na maszyny. Niedawno o statystykach przypomniał mi wpis ryśka, a obecne na blogu statystyki stat4u są coraz bardziej niewystarczające, głównie ze względu na brak aktualizacji od dłuższego czasu (ostatnia zmiana kilkadziesiąt miesięcy temu). Szczególnie, że chciałem się pobawić w referral fun.

Postanowiłem zaryzykować i zainstalować Piwika na Dockstarze. Co prawda miałem wrażenie, że 128 MB RAM i dysk 2,5″ 5400 RPM, na dodatek w kieszeni USB to nie jest to, co MySQL lubi najbardziej, ale spróbować można. Instalacja Piwika na lighttpd jest prosta i nie ma czego tak naprawdę opisywać. Ku mojemu zdziwieniu MySQL zajął tylko ok. 10% pamięci, a statystyki się zbierały.

Niestety, kliknięcie czegokolwiek w dashboardzie było męczarnią – skrypty PHP na serwerze mieliył po procku (niby 1,2 GHz, ale ARM, poza tym jakieś drobiazgi do łapania spamerów na Blox tam działają) nieprzyzwoicie intensywnie i nieprzyzwoicie długo. Znaczy dziesiątki sekund. Ale to co zobaczyłem było bardzo obiecujące, więc wrzuciłem Piwika na tymczasowego VPSa, który zasadniczo się nudzi (hell yeah, spojrzałem i prawie drugi rok mija darmowego testu, ale to offtopic, więc spuśćmy zasłonę miłosierdzia).

Po prostu rewelacja. Piwik pokazuje wiele rzeczy, których w stat4u nie ma (o statystykach wbudowanych w Blox nie wspominam, bo trudno to nazwać statystyką). Skąd ktoś przyszedł, gdzie poszedł, ile czasu spędził na stronie, rozbicia na systemy operacyjne, wykorzystywane pluginy, aktywność, powracający użytkownicy. I do tego wszystko estetycznie podane. Niby nic kluczowego się nie dowiedziałem, ale zdecydowanie bardziej mi się to podoba. I mam nad wszystkim kontrolę. Próbka jest mała, ale już mogę stwierdzić, że stat4u ma parę błędów (pewnie skutek braku aktualizacji).

Z drobnych poprawek, które warto wykonać: mimo, że to nie high traffic site, warto doinstalować APC, jest szybciej. Być może spróbuję wrócić na Dockstara z doinstalowanym APC, ale może nic z tego nie wyjść – może PHP wisiał na zapytaniach do baz – mało czasu miałem, nie wnikałem. Poza tym, wolałbym to jednak mieć na czymś porządniejszym, niż ADSL.

W każdym razie, w ramach popularyzacji tego oprogramowania, jeśli ktoś chciałby zobaczyć jak Piwik wygląda na jego własnych realnych danych, a nie ma warunków/ochoty na stawianie go samodzielnie, to może podpiąć na swojej stronie na dłuższą chwilę[2] u mnie (free, no strings attached). Chętnych zapraszam do kontaktu mailowego. Warunki są trzy. Pierwszy: nie więcej niż powiedzmy 10k UU miesięcznie (nie apteka) ze względu na wydajność maszyny. Drugi: best effort, czyli nie gwarantuję działania systemu, mogą być przerwy, nie gwarantuję przywrócenia z backupu itp. Oczywiście można dawać znać jak coś nie będzie działać i postaram się poprawić (bo mam tam własne niekrytyczne zabawki), ale wiecie jak jest. Na ten moment uptime system to 4 m-ce. Trzeci: zastrzegam sobie prawo do absolutnie subiektywnego wyboru chętnych (zwł. znajomi (jeśli się pojawią – nie jest to warunek konieczny) mają pierwszeństwo, podobnie jak nietechniczni/nieadmini – zakładam, że techniczni jakby chcieli, to by sami sobie postawili), wyłączenia usługi w dowolnym momencie wybranym serwisom itp. Jasne, postaram się uprzedzić wcześniej. Jeśli są jakieś wątpliwości co do warunków/coś pominąłem – proszę o pytania w komentarzach.

[1] Google Analytics odpada. I tak za dużo wiedzą, więc staram się unikać produktów ze stajni Google.

[2] VPS będzie działał jeszcze jakiś miesiąc. Potem, jeśli wszystko pójdzie dobrze, planuję przeniesienie się (z gratami) na jakieś 3 m-ce na testowego dedyka, a potem… Albo będzie działać na Dockstarze, albo przedłużę dedyka, albo zawinę zabawki.