Tag: WWW

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

Wylogowanie z serwisu a zmiana IP – co robić?

The background: jest sobie pewien serwis AKA aplikacja WWW. Z pewnych względów (bezpieczeństwo) zmiana IP użytkownika powoduje wylogowanie z aplikacji. Do tego – z innych względów – nie bardzo jest wola, by inwestować w zmianę takiego zachowania tejże aplikacji.

The problem: kolejny popularny operator (Plus) zmienił(?) działanie swojej sieci tak, że klientom często zmienia się IP w trakcie połączenia z Internetem, co skutkuje wylogowaniem z serwisu. Mam pewne podejrzenia, że może to dotyczyć tylko niektórych taryf, ale nie to jest przedmiotem rozważań. Wylogowuje i już.

The question: jak można w prosty sposób (dla laika) obejść problem od strony użytkownika aplikacji? Jedno rozwiązanie już znam – użycie Opery i turbo mode. Niby fajne, bo Opera jest darmowa, ale… nie jest to open source i nie każdy ma możliwość instalacji oprogramowania. Pewnie dowolne tunelowanie ruchu przeglądarki załatwi sprawę, ale dla laika to zbyt skomplikowane. Być może pomogłoby proxy, ale nie znalazłem informacji na stronach Plusa o tym, żeby coś takiego udostępniał. No i problem dotyczy nie tylko Plusa… Pomysły?

Opublikowane w

Automatyczne wykrywanie spamu na Blox.

Trochę z rozpędu po ostatnim spojrzeniu na beznadziejną captchę na Blox, trochę zażenowany brakiem działania administratorów Blox w tak wydawałoby się prostej sprawie, trochę chcąc odkurzyć stare skrypty i znajomość Perla, trochę ze względu na zainteresowaniem tematem spamu, a w końcu trochę dla zabawy, postanowiłem zrobić przymiarkę do automatycznego wykrywania spamu na Blox. Chodzi o określanie, czy dany blog służy wyłącznie spamowaniu, oczywiście automatycznie, a co za tym idzie nie ze stuprocentową pewnością.

Administratorzy zapowiedzieli, że captcha zostanie poprawiona w kwietniu (trzymam za słowo i liczę na to, zapewne nie tylko ja), więc spamblogów nie powinno od tej pory przybywać. Zatem postanowiłem skupić się nie na liście nowozałożonych blogów, tylko na liście nowych wpisów, czyli aktywnych spamblogach. Co prawda pierwotny plan zakładał przeiterowanie się po wszystkich blogach i określenie prawdopodobieństwa, czy jest to spamblog, ale nie znalazłem niestety listy wszystkich blogów na Blox. Owszem, można próbować robić rzeźbę pod tytułem „przeiterujmy się po tagach”, ale nadal nie daje to gwarancji uzyskania listy wszystkich blogów – wystarczy, że ktoś nie taguje i system nie dotrze do jego bloga, więc stanęło na tym, że obserwuję listę nowych wpisów i stamtąd biorę dane. Przy okazji oceniam nie tyle cały blog, co poszczególne wpisy, co może być przydatne.

Podejście pierwsze – pobierz i oceń. Na samym początku stwierdziłem, że będę pobierał wpis do oceny i oceniał na podstawie arbitralnych kryteriów. Pomysł szybko upadł – zmiany w algorytmie oceniania powodowały niekompatybilność z poprzednimi danymi, a zmiany były konieczne – wychodziły coraz to nowe kryteria i ich wagi. Wersjonowanie algorytmu przy ocenie nie pomagało, bo dane były tracone. OK, nie jest to wszystko aż tak proste, jak się wydawało na początku.

Podejście drugie – pobierz i zapisz jak najwięcej cech wyróżniających dla danego wpisu/bloga, a potem pomyśli się nad algorytmem. No niestety, zapisywanie dużej ilości danych może być ciekawe, szczególnie, że potem można sięgnąć do wiedzy ze studiów i określić poziomy istotności poszczególnych parametrów (albo popytać kumpla o gotowca, może jeszcze ma…). Wytrenuje się AI na próbce kontrolnej, a potem AI sama zrobi resztę. Brzmi fajnie, ale trochę overkill, poza tym, mało odporne na dołożenie kolejnych parametrów, gdyby przyszło mi do głowy ich wyciąganie.

Podejście trzecie, aktualne,kompromisowe – pobierz i zapisz istotne (wybrane arbitralnie przeze mnie) cechy wyróżniające dany wpis. Osobny skrypt ma algorytm procentowy, każda cecha może przyjmować wartości 0-100% prawdopodobieństwa bycia spamem. Następnie w zależności od ilości cech wylicz prawdopodobieństwo dla całego wpisu przy pomocy średniej ważonej. Rezultaty są dość interesujące.

Tutaj lista blogów (praktycznie nikt nie korzystał, więc wywaliłem), które sklasyfikowałem jako spamerskie z prawdopodobieństwem 80% i więcej. Format prawdopodobieństwo bycia spamem (%), spacja, link do bloga. Nie widzę (szybko patrząc) żadnego false positive, a wy? Aktualnie jest takich blogów 375 na 2404 wszystkich sprawdzonych blogów. Jasne, nie jest to cud techniki, ale przy dodaniu pewnych prostych whitelist myślę, że można spokojnie blokować automatem wszystkie blogi z prawdopodobieństwem od 70% w górę.

Szczegółów badanych cech oraz algorytmu nie chcę na razie opisywać, bo po co spamerzy mają się bronić? Jak będzie utrudnione zakładanie nowych blogów, to pomyślę o tym. Na razie cały czas zbierają się dane… Gdyby byli chętni do przeglądania wyniku w celu wychwytywania false positive’ów (wpisujcie miasta, które przeglądają ;-)), to mogę pomyśleć o wystawianiu listy spamów automatem co jakiś czas.

Całość napisana oczywiście w Perlu, główny moduł zbierający z użyciem WWW::Mechanize (genialna sprawa do crawlerów).

UPDATE: Drobny update statystyk z dnia 27.04.2012 – 13481 unikatowe blogi (wcześniej chyba były unikatowe wpisy, ale mniejsza), w tym 1094 do natychmiastowego wycięcia (80% i więcej). Dla porządku 70% i więcej to 2438 sztuki. Listy nie zamieszczam, bo zainteresowanie było znikome. A captcha nadal nie została poprawiona, choć koniec kwietnia…