MauiBot – analiza zachowania bota

Pewnego dnia patrząc w logi serwera WWW zauważyłem sporą aktywność bota identyfikującego się jako:

MauiBot (crawler.feedback+dc@gmail.com)

Z zapałem crawlował labirynt dla botów, w User Agent nie było zazwyczaj obecnego URLa, żeby poczytać, co to za wynalazek, więc uruchomiłem wyszukiwarkę. Szybko udało mi się ustalić, że to bad bot, działający z chmury Amazonu (AWS) i nawet są reguły dla nginx do blokowania ruchu od niego.

Na początek parę znalezionych linków:

Wygląda, że bot pojawił się w marcu tego roku, czyli jest dość świeży. Wygląda też, że potrafi spowodować trochę problemów, przynajmniej na shared hostingach i/lub stronach słabo zoptymalizowanych.

Dokładniejszych informacji nie ma, więc postanowiłem poobserwować zwyczaje bota na własną rękę.

Wygląda, że 25 lipca ok. 1:20 trafił na moją stronę domową i zaczął podążać za kolejnymi linkami. Korzystał z IP 54.237.208.52, nie dało się obserwować opisywanego w niektórych miejscach wykonywania requestów grupami po 4-8 co 30 sekund. Wykonywał między 100 a 250 requestów na godzinę.

Tego samego dnia ok. 20:40 zmienił IP na 54.87.252.55 i… zaczął wszystko od początku. 26 lipca około 1:20 skończyły się requesty dotyczące blogów, pozostały tylko dotyczące wypasania botów.  W tym momencie intensywność crawlowania znacząco wzrosła – między 1600 a 2100 requestów na godzinę. Daje się też zauważyć grupowanie requestów, choć wygląda ono nieco inaczej niż w opisywanych w sieci przypadkach – 3-4 requesty co 5-6 sekund. Być może każdy wątek dla danej ścieżki wykonuje 4 requesty co 30 sekund.

Zaczynam też obserwować spadek liczby zapytań na godzinę. 26 lipca o godzinie 7 było 1500 requestów, następnie systematycznie z godziny na godzinę spada do 900 requestów o 19 i 550 o godzinie 5 następnego dnia. O godzinie 19 27 lipca jest już tylko 340 requestów, a o godzinie 9 28 lipca już tylko 250 zapytań na godzinę.

W tym momencie zaczynam eksperymentować. Po pierwsze dodaję przed linkami z parametrami i za nimi linki z inną ścieżką, ale również prowadzące do labiryntu. Bot natychmiast za nimi podąża, najwyraźniej dokładając nowe wątki/procesy, bo liczba requestów wzrasta do ponad 700/h, przy czym liczba do bazowego powoli spada do ok. 200/h.

31 lipca liczba requestów to ok. 150/h. Podstawiam linka do labiryntu ale w innej domenie, ale MauiBot ignoruje tego linka. Trochę zbyt długo zwlekałem z analizą, obecnie bot reaguje bardzo powoli, więc publikuję teraz, a kolejne obserwacje pojawią się wkrótce, jako aktualizacja tego wpisu.

UPDATE

Aby sprawdzić, czy pomija ze względu na inną domenę, czy w ogóle przestał, dołożyłem kolejnego linka, tym razem w crawlowanej dotychczas domenie. Podążył za nim, a liczba requstów wzrosła do ok. 210/h. Podobnie bot podążył za URLem w tej samej domenie po podaniu pełnej ścieżki zamiast względnej, używanej wszędzie dotychczas.

Wygląda na to, że odwiedzone URLe są zapamiętywane – bot nie wrócił do początkowego indeksu, mimo podanie osobnego linka w odwiedzonej już ścieżce.

Aby sprawdzić, jak sobie radzi z forkowaniem i jak to wpływ na ilość requestów, wysłałem go w dziewięć kolejnych, niezależnych miejsc.

Mail RBL checker (Python)

Tak się zdarzyło w ostatnim czasie, że w paru miejscach pojawiły się problemy z dostarczaniem maili. Prawdopodobna przyczyna niedocierania poczty była ta sama – obecność IP serwera pocztowego na RBL. Przypomniały mi się stare czasy i walka z wypisywaniem IP z RBL oraz różne metody zapobiegania dostawania się na RBLe.

Zanim jednak zaczniemy cokolwiek robić, trzeba wiedzieć, że jesteśmy na RBLu, czyli monitorować obecność IP serwera pocztowego na RBL. Do szybkich, ręcznych, doraźnych sprawdzeń pojedynczych IP polecam stronę Multi-RBL Check, nie rozwiązuje to jednak tematu ciągłego, automatycznego monitoringu obecności IP na RBLach, np. przy pomocy Zabbiksa.

Sam monitoring jest trywialny – wystarczy odpytywać przy pomocy DNS, warto to jednak jakoś „opakować”. Napisałem to ze dwa razy w życiu (IIRC oba w Perlu), napiszę więc i trzeci, tym razem w Pythonie. Oczywiście podobnych rozwiązań na GitHubie jest wiele, ale w każdym coś mi nie pasowało – albo język, albo rozbudowane zależności, albo sposób przekazywnia informacji. To ostatnie to w sumie detal, łatwo można przefiltrować informacje przy pomocy grep lub awk.

W każdym razie, wczoraj opublikowałem mail-rbl-monitor. Zdecydowanie nie jest skończony, a struktura wynika z przygotowania pod przyszłe funkcje. Znaczy sprawdzanie listy IP pobieranej z pliku.

Wkrótce temat pokrewny, ale nieco trudniejszy – monitoring reputacji IP serwerów pocztowych.

5 powodów do udziału w DSP2017

Nie jestem programistą i nie jest to blog programistyczny[1]. Czemu więc dołączyłem do konkursu Daj Się Poznać 2017?

  • Po pierwsze, uważam, że to świetna inicjatywa, dobra zabawa i doskonały motywator.
  • Po drugie, zawsze lubiłem konkursy programistyczne typu Potyczki Alogrytmiczne.
  • Po trzecie, uważam, że administrator powinien znać przynajmniej podstawy programowania, nawet jeśli nie udziela się programistycznie w większych projektach. Zresztą, devops (modne słowo) way to konfiguracja jako kod i bez przynajmniej podstaw jest… ciężko. Jeśli w ogóle się da. 😉
  • Po czwarte, ostatnio spodobał mi się Python i jest okazja, żeby poćwiczyć.
  • Po piąte, mam pomysł na mały projekt, który trafił do szuflady (czytaj: na dysk) i DSP2017 jest świetną okazją, żeby go zmaterializować. Jak to ładnie ktoś ujął „wizja bez implementacji to halucynacja”.

Największy problem sprawiła mi… platforma bloga czyli sam Blox. Wymogiem uczestnictwa w DSP2017 jest podanie kanału RSS, na którym będą pojawiały się wpisy konkursowe. I tylko one. Niestety, nic takiego tu nie istnieje, przynajmniej nie w nowym szablonie. Zgłosiłem to na forum, mają sprawdzać, ale złudzeń nie mam – muszę radzić sobie sam. Jest plan, szczegóły jutro.

Konkursem zainteresowałem się bliżej 28. lutego i powyższy problem sprawił, że pierwotnie odpuściłem, na szczęście zapisy do DSP2017 zostały przedłużone do 12. marca, więc podobnie jak ja macie jeszcze szansę zdążyć się zarejestrować.

Do całości podchodzę luźno – ma to być głównie motywator do materializacji projektu i okazja do poćwiczenia Pythona. Biorąc pod uwagę ilość wpisów na blogu, głównym problemem mogą być same dwa wpisy tygodniowo, a szczególnie ten drugi, niekoniecznie związany z projektem. A jeszcze trzeba sam projekt realizować… Niemniej, trzeba próbować. 🙂

[1] Mam nadzieję, że to wyznanie nie spowoduje dyskwalifikacji. Postaram się spełnić wymagania konkursowe.

Autossh

Jak zapowiedziałem w notce o porządkach, przepiąłem się z łącza ADSL na komórkę. Decyzję przyspieszyła wydatnie awaria ADSL, polegająca na tym, że transfery liczone są w pojedynczych kB, a mimo obiecującego początkowego kontaktu, awaria nadal trwa… Przy czym po tym jak odesłałem parametry łącza, które chcieli, to przestali się odzywać, mimo dwóch kontaktów mailowych z mojej strony.

Nie obyło się bez zawirowań i ledwo działający dostęp ADSL ratował mi tyłek, ale może o tym w innej notce. W tej chwili sytuacja wygląda tak, że cały ruch leci przez modem GSM wpięty do routera na Banana Pi. Jeśli chodzi o dostawcę łącza, to poszedłem na łatwiznę i jest to Aero2. W zeszłym miesiącu zużyłem (tj. bardziej rodzice) niecałe 2GB z 3GB pakietu. Czyli przewidywany koszt łącza to 5-10 zł/m-c. Wyższe pingi nie są problemem, zresztą różnica w stosunku do BSA jest niewielka. Prędkość to jakieś 3/1 Mbps[1], więc też lepiej, niż było.

Problemem okazał się dostęp do routera, który chciałbym zachować. Znalazłem autossh, o którym wspominałem w komentarzach do notki o porządkach, ale uruchomienie zajęło znacznie więcej czasu, mimo prostych instrukcji. Oczywiście wszystko przez moje niezrozumienie tematu, albo raczej wcześniejsze wyobrażenia. Liczyłem, że po zestawieniu tunelu, łącząc się do zdalnego hosta na określonym porcie, zostanę automagicznie przekierowany do hosta za NAT, z którego jest zestawiony tunel.

Tak jednak nie jest. Autossh słucha na zdalnym hoście wyłącznie na adresie lokalnym (127.0.0.1) i zdebugowanie tego zajęło mi dłuższą chwilę, więc może oszczędzę tym wpisem komuś szukania. Korzystając z instrukcji dostępnych w sieci faktycznie połączymy się do hosta za NAT, ale tylko z maszyny do której jest zestawiony tunel. Można wystawić ten dostęp na świat, ale wymaga to dodatkowego przekierowania portu, czy to przy pomocy iptables, czy programu redir.

Ostatecznie wypracowałem następujący schemat. Połączenie zestawione z hosta za NAT przy pomocy autossh (uruchamiane przy starcie systemu, logowanie po kluczach bez hasła):

autossh -f -M 5122 -N -R 8888:127.0.0.1:22 user@host

Jeśli chcę się dostać do routera (hosta za NAT) to na hoście docelowym uruchamiam przekierowanie portów:

redir --lport=8888 --laddr=IP_PUBLICZNE --cport=8888 --caddr=127.0.0.1

W tym momencie łącząc się na port 8888 maszyny z publicznym IP, de facto łączę się do routera za NAT:

ssh -p 8888 user_za_nat@host

Oczywiście analogicznie mogę także zestawiać tunele SSH itp., które umożliwią mi wyjście w świat przez modem GSM.

Czemu redir, a nie iptables? Nie potrzebuję dostępu do tej maszyny cały czas, więc wolę uruchomić na chwilę przekierowanie, niż wystawiać router na świat, chociaż po docelowym zabezpieczeniu pewnie się to zmieni.

[1] Tzn. 3/1Mbps wykazał speedtest, ale może być lepiej, zwł. download – później zauważyłem, że konfigurując router ustawiłem limitowanie pasma na 3 Mbps dla pojedynczej końcówki za NAT.

KVM i task blocked for more than 120 seconds – solved

Sprawę miałem opisać już jakiś czas temu i zapomniałem, a jest szansa, że komuś się przyda. Był sobie serwer, na którym działało trochę VPSów. Wszystkie KVM, wszystkie z systemem plików ext4 i obrazem dysku qcow2. Czyli standard. Sprzęt nie pierwszej młodości, ale działały względnie stabilnie. Poza jedną, w sumie najbardziej obciążoną, bo działał w niej jeden z serwerów Zabbixa, niespecjalnie obciążony w porównaniu z innymi, w których jednak żaden nie działał w KVM.

Tej jednej zdarzał się zaliczyć zwis, z komunikatami:

kernel: INFO: task XXX blocked for more than 120 seconds.kernel: "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.

Wymagany był reboot wirtualki. Dotyczyło to różnych tasków, a całość działa się losowo – potrafiło działać przez kilka tygodni, a potrafiło wywalić się co parę dni, co nie ułatwiało diagnostyki. Początkowo działo się to na tyle rzadko, że sprawa została zignorowana, ale w miarę wzrostu obciążenia maszyny fizycznej, problem się nasilał. Objaw był taki, że operacje wymagające zapisu na dysk nie wykonywały się (czyli monitoring zdychał). Zacząłem szukać przyczyn – pierwotnie podejrzenie padło na coś, co wykonuje się z crona, bo sporo procesów crona wisiało, ale przejrzenie skryptów pokazało, że niespecjalnie mogą one być przyczyną

Wyglądało, jakby momentami coś nie wyrabiało się dostępem do dysków w momentach większego obciążenia. Z tym, że znowu – widać było, że nie jest to deterministyczne. Ponieważ maszyny jak wspomniałem starawe, to podejrzenie padło na sprzęt – problemy z dostępem do dysków potrafią robić cuda. SMART pokazywał, że wszystko OK, ale sprawdzić nie zawadzi… Przeniesienie wirtualki na inną, mniej obciążoną maszynę fizyczną nie przyniosło rezultatów – wieszało się nadal, chociaż rzadziej.

Oczywiście wyłączenie komunikatu, które jest w nim wspomniane, nie rozwiązuje problemu. W międzyczasie trafiłem na opis rozwiązania problemu, czyli zmniejszenie vm.dirty_ratio oraz vm.dirty_backgroud_ratio. Tylko że… to nie pomogło. Nie pomogło także zwiększenie kernel.hung_task_timeout_secs początkowo do 180, potem do 300 sekund. Było trochę lepiej, ale problem nadal występował. Pół żartem, pół serio zacząłem się zastanawiać nad automatycznym rebootem po wystąpieniu problemu (zawsze to krótsza przerwa), ale to brzydkie obejście, nie rozwiązanie. Tym bardziej, że w miarę wzrostu obciążenia i VPSa, i maszyny fizycznej na której on działał, problem zaczął występować częściej – góra co parę dni. Paradoksalnie, dobrze się stało, bo i motywacja większa, i sprawdzanie efektu wprowadzonych zmian łatwiejsze.

Z braku opisów w sieci, pomocy znajomych adminów i innych pomysłów zacząłem sprawdzać po kolei wszystko. Od fsck systemu plików, przez nowsze wersje kernela, zarówno na maszynie fizycznej, jak i na wirtualce – a nuż coś poprawili. Bez rezultatu. Ostatecznie postanowiłem zmienić format dysku wirtualki z qcow2 na raw i… trafiony, zatopiony – wirtualka zaczęła działać stabilnie.

Dla pewności wróciłem jeszcze z raw z powrotem na qcow2, na wypadek, gdyby chodziło o jakieś błędy, których nie wykrywało narzędzie do sprawdzania qcow2, ale… problem natychmiast wrócił. Gwoli ścisłości: ww. tuning dotyczący parametrów kernela z serii vm.dirty został zachowany.

Ubuntu 14.04 LTS, apt-dater i restart usług

Jakiś czas temu zachwalałem apt-dater jako narzędzie do aktualizacji większej ilości systemów. Jak pisałem w późniejszych uwagach, apt-dater nieźle integruje się z programem needrestart. Tyle teorii…

Niestety, o ile na Debianie Jessie wyglądało to naprawdę dobrze i sprawdzenie przez checkrestart (inne polecenie realizujące podobne zadanie) dawało spójne wyniki z needrestart, o tyle na Ubuntu 14.04 LTS needrestart pokazywał często, że do restartu nic nie ma, o tyle checkrestart był zupełnie innego zdania... I – co gorsza – miał rację.

Przyczyną okazała się różnica w wersji needrestart. W Jessie jest to 1.2, w Ubuntu 14.04 LTS – 0.5. Ponieważ to skrypt perlowy, to dałem szansę i wrzuciłem wersję z Debiana (stable). Instaluje się czysto, działa bardzo dobrze – w połączeniu z apt-dater wykrywa więcej usług do restartu i także tu wyniki needrestart są teraz spójne z checkrestart.

Nawiasem, checkrestart w Jessie ma problem z mysql i zawsze pokazuje, że należy go zrestartować. Jest na to zgłoszony bug. Ale to tak nawiasem, kto korzysta, ten wie, zresztą można dopisać mysql do wyjątków w konfigu.

Panoptykon narzeka na ministerstwa i blokowanie Tora

Fundacja Panoptykon po raz kolejny narzeka na blokowanie przez ministerstwa IP, na którym mają uruchomiony węzeł Tor (relay-node). Sytuacja skłoniła mnie do wpisu, bo mam wrażenie, że zachodzi grube niezrozumienie tematu. Z obu stron…

Logo projektu Tor

Źródło: https://media.torproject.org/image/official-images/2011-tor-logo-flat.svg

 

Czy warto blokować ruch z sieci Tor?

To zależy. Ruch z sieci Tor pozwala na łatwe uzyskanie stosunkowo wysokiej anonimowości w sieci. Z jednej strony jest to wykorzystywane do anonimowej komunikacji przez zwykłych ludzi, z drugiej jest wykorzystywane do nadużyć i wandalizmu. Ze znanych serwisów wymienionych w FAQ – Wikipedia blokuje edycję artykułów z sieci Tor, podobnie Slashdot. Oczywiście takich serwisów jest o wiele więcej. Po prostu stosunek sygnał/szum jest w przypadku sieci Tor wyjątkowo niski.

Są też inne, poważniejsze powody do blokowania. O ile sieć Tor ma raczej słabą przepustowość i nie nadaje się do ataków wolumetrycznych, to zdecydowanie ułatwia łatwe, anonimowe ataki na aplikację, SQLi itp. Czyli raj dla script kiddies. I dokładnie taki jest oficjalny powód podany przez rzecznika ABW cytowany na Niebezpieczniku.

Jak blokować ruch z sieci Tor?

Autorzy projektu Tor podkreślają, że wezły sieci Tor mają indywidualne polityki, ale.. Patrząc z punktu widzenia administratora serwisu docelowego i ekonomii działania: sieć Tor to jakieś ułamki promila ruchu, w dodatku często ruchu niepożądanego. Jeśli ktoś zdecyduje się już blokować ruch z sieci Tor, to raczej nie będzie bawił się w polityki poszczególnych węzłów, tylko zablokuje wszystkie. Czy to na poszczególnych maszynach, czy to na centralnym firewallu, czy wręcz null-route’ując na routerach ruch kierowany do węzłów Tor (co uniemożliwi komunikację TCP). Ostatnia metoda jest i prosta w implementacji, i prosta w utrzymaniu (centralne miejsce do zarządzania), i wydajna.

Z których węzłów ruch blokować?

Tu jest pies pogrzebany. Fundacja Panoptykon nie prowadzi exit node, czyli nie przekazuje ruchu z sieci Tor do „normalnego internetu”. Niestety, oficjalne narzędzia udostępniane przez projekt Tor IMO nie są zbyt przyjazne administratorom (szczególnie tym, którzy są mniej świadomi zasad działania Tora lub którzy nie mają czasu). Blokowanie wszystkich węzłów Tora widziałem spotkałem, zarówno jako użytkownik końcowy (tak, relay node w domu, ruch z normalnego IP i komunikat o niewpuszczaniu z sieci Tor w serwisie), jak i administrator. Przede wszystkim brakuje oficjalnej listy węzłów wyjściowych łatwej do przetwarzania, czyli zawierającej same IP. Przypominam, że pisałem we wpisie o blokowaniu węzłów Tor, że udostępniam taką listę. Tylko exit nodes, tylko adresy IP.

Podsumowując, obie strony są winne:

Dziwią mnie żale ze strony Panoptykonu, gdy sytuacja jest typowa i opisana w FAQ Tora:

You might also find that your Tor relay’s IP is blocked from accessing some Internet sites/services. This might happen regardless of your exit policy, because some groups don’t seem to know or care that Tor has exit policies. (If you have a spare IP not used for other activities, you might consider running your Tor relay on it.)

Jak widać, projekt Tor zaleca prowadzenie węzłów na oddzielnych IP, nieużywanych do innych usług. Tak, wiem, sekcja dotyczy węzłów wyjściowych, ale idę o zakład, że pomysłodawca/admin w Panoptykonie nie czytał. Poza tym, zdrowy rozsądek zaleca analizę możliwych konsekwencji przed uruchomieniem usługi i stosowanie oddzielnych IP w tym przypadku.

Dziwi mnie też implementacja blokowania Tora na rządowych serwerach, wskazująca na niezrozumienie tematu. Oczywiście nie mam złudzeń co do korzystania przez nich np. z mojej listy (sam bym tego na ich miejscu nie zrobił), ale samodzielna implementacja to nie rocket science… Plus, niezrozumienie tematu może prowadzić do fałszywego poczucia bezpieczeństwa – tak naprawdę nie sposób zablokować 100% ruchu z sieci Tor, przynajmniej nie w oparciu o adresy IP.

Chef i cookbooki bez metadata.rb

W firmie korzystamy z Chefa, niby robi swoją robotę, ale nie przepadam za nim z różnych względów. Jedna z rzeczy, która mnie drażni, to wersjonowanie i niekompatybilność (bardziej: pozorna kompatybilność) pomiędzy wersjami. W Debianie Jessie, którego mam na desktopie jest chef w wersji 11, który generalnie działał. Na serwerach mamy Chefa 12.

Ostatnio instaluję cookbook nodejs:

knife cookbook site install nodejs
Installing nodejs to /home/rozie/chef-repo/cookbooks
Checking out the master branch.
Pristine copy branch (chef-vendor-nodejs) exists, switching to it.
Downloading nodejs from the cookbooks site at version 2.4.2 to /home/rozie/chef-repo/cookbooks/nodejs.tar.gz
Cookbook saved: /home/rozie/chef-repo/cookbooks/nodejs.tar.gz
Removing pre-existing version.
Uncompressing nodejs version 2.4.2.
removing downloaded tarball
No changes made to nodejs
Checking out the master branch.
ERROR: IOError: Cannot open or read /home/rozie/chef-repo/cookbooks/nodejs/metadata.rb!

Zacząłem szukać i widywać różne dziwne rozwiązania na nieistniejące metadata.rb, przez chwilę przyszło mi dogenerowanie „brakującego” pliku na podstawie obecnego metadata.json, ale… coś mnie tknęło i postanowiłem najpierw spróbować z nowszym Chefem u siebie na lapku.

Ależ oczywiście, że instalacja Chefa w wersji 12 rozwiązała problem.

Korzystając z apt-dater – parę uwag

Od pewnego czasu korzystam z opisywanego kiedyś narzędzia apt-dater do aktualizacji hostów w środowiskach większych, niż kilka własnych testowych maszyn. Garść praktycznych uwag nt. używania w takich środowiskach.

  1. W okolicy wersji 1.0 zmienił się format pliku (teraz jest XML), przez co linkowany wyżej opis jest nieaktualny. Zmian wymagał też skrypt generujący konfigurację apt-datera na podstawie danych z Chefa.
  2. Warto podzielić hosty na grupy – raz, że łatwiej decydować, gdzie wykonujemy aktualizację w danym momencie, dwa, że każdy host to osobne procesy w momencie działań więc… może być tego za dużo, jeśli zaczniemy aktualizować listę pakietów wszędzie jednocześnie (tak, mam skonfigurowane limits na workstacji, tak walnąłem w limity, jak leciałem hurtem).
  3. Sama aktualizacja to nie wszystko, trzeba jeszcze zrestartować procesy korzystające ze starych bibliotek. Kiedyś był checkrestart, teraz jest bardziej popularny –  i nieźle współpracujący z apt-daterneedrestart.
  4. Niezależnie od podziału na grupy, można ad hoc zaznaczyć hosty do wykonania operacji (polecenie tag). Sposób niezbyt intuicyjny, bo najpierw zaznaczamy hosty [t], następnie zatwierdzamy je do wykonania [;], a na końcu wybieramy polecenie do wykonania.
  5. Apt-dater przyspiesza pracę, ale nie udało mi się (i nie tylko mi), uniknąć podłączania do każdej sesji po zakończeniu aktualizacji i zamykania jej. Nawet, jeśli cała aktualizacja przeszła pomyślnie, bez interaktywnych pytań i nie ma nic do restartu. Gdyby się komuś udało – proszę o komentarz.
  6. Odpowiednio ustawione hold lub apt_preferences to podstawa, jeśli ma się jakieś dziwne (czytaj: 3rd party) pakiety, których autorzy niezupełnie umieją paczkować Debian way.

W każdym razie apt-dater bardzo ułatwia i przyspiesza pracę. Generalnie polecam.

NLNOG RING – zdiagnozuj sobie sieć

Odwieczny problem administratorów sieci to mogę sprawdzić trasę od siebie do danego hosta, ale jak wygląda w drugą stronę? Próbą rozwiązania tego zagadnienia były looking glass, pozwalające na wykonanie od określonego operatora ping czy traceroute. Czasem potrzeba jednak czegoś więcej – sprawdzenia resolvowania DNS, zbadanie stabilności transferu itp. Ogólnie przydałby się shell.

Projekt NLNOG RING jest odpowiedzią na to zapotrzebowanie. Opiera się na prostej zasadzie wzajemności: udostępniamy maszynę wirtualną (administrowaną przez opiekunów projektu) dla projektu, w zamian otrzymujemy dostęp do pozostałych maszyn projektu, w różnych częściach świata i – co ważniejsze – w wielu różnych ASN.

Wymagania co do maszyny są naprawdę niewielkie – 1 GB RAM, 20 GB dysku, 1 core 64bit procesora, adresy IPv4 oraz IPv6. Musi stać w naszym AS i na naszej adresacji. Myślę, że w tej chwili większość operatorów, nawet niewielkich sieci radiowych jest w stanie sprostać. Pozostałe wymagania stawiane organizacji (usługa jest kierowana do firm) to m.in.: bycie operatorem sieciowym, własne ASN, prefiksy IPv4 i IPv6, zgoda organizacji na uczestnictwo w projekcie.

Możliwe jest zarówno połączenie po SSH do wybranej maszyny, jak i wykonywanie, przy pomocy dostępnych narzędzi, operacji na wszystkich maszynach projektu jednocześnie. Generalnie potrafi bardzo pomóc w diagnostyce.

Projekt działa od wielu lat, ale dziś dowiedziałem się, że nawet w środowisku sieciowym niekoniecznie jest znany, więc uważam, że warto przypomnieć o jego istnieniu. Teoretycznie istnieje ryzyko nadużyć, ale użytkownikami są administratorzy sieci, polityka to zero tolerancji dla nadużyć i nie kojarzę jakichkolwiek problemów związanych z udostępnianiem maszyny. Korzystałem, polecam.

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ć.

Automatyczny wybór najlepszego mirrora w Debianie

Co prawda pisałem o tym blisko trzy lata temu, ale warto przypomnieć, że jest nowa metoda wyboru najlepszego mirrora pakietów deb w Debianie. Okazja tym lepsza, że z http.debian.net awansowało na httpredir.debian.org. Czyli jest pełnoprawną, oficjalną częścią Debiana. Jest też możliwość wyboru tego repozytorium podczas instalacji, przynajmniej od wersji Jessie.

Wiele się nie zmieniło, więc po szczegóły odsyłam do starego opisu albo na stronę projektu. Ze zmian: pojawił się adres IPv6, debootstrap też nie ma od jakiegoś czasu problemów z redirectorem. Ja korzystałem przez te trzy lata na różnych systemach (także produkcyjnych) i nie zauważyłem większych problemów, przynajmniej w wersji podstawowej, bo z niszami typu debootstrap czy apt-p2p kiedyś problemy były. Polecam.

Docker.io Debian Jessie HOWTO

Parę dni temu pojawiła się nowa wersja Debiana o nazwie Jessie. O upgrade i drobnych i niedrobnych perypetiach napiszę innym razem, dziś krótkie rozwiązanie problemu, który pojawia się dość często na IRCu. Chodzi o to, że pakiet docker.io nie jest dostępny w Jessie. A ludzie chcą dockera używać. Widzę trzy rozwiązania:

1. Pobranie pakietu docker.io w wersji dla Debiana unstable.

Rozwiązanie najprostsze, ale potencjalnie najbardziej problematyczne. Wchodzimy na https://packages.debian.org/sid/docker.io wybieramy architekturę, następnie mirror, pobieramy paczkę deb (akualnie jest to docker.io_1.3.3~dfsg1-2_amd64.deb). Instalujemy ją w systemie, mniej lub bardziej ręcznie spełniając zależności.

2. Dodanie repozytoriów unstable w systemie oraz odpowiedni pinning pakietów.

Po pierwsze czytamy dokładnie i ze zrozumieniem jak działa pinning pakietów (man apt_preferences), żeby nagle nie zaktualizowało systemu do unstable, albo nie pomieszało pakietów ze stable i unstable przy spełnianiu zależności. Następnie dodajemy wpisy dla unstable w sources.list. Aktualizujemy listę pakietów i docker.io powinien być dostępny do instalacji.

3. Samodzielnie robimy backport pakietu docker.io dla Jessie.

Wersja najdoskonalsza, bo nie robi bałaganu związanego z mieszaniem wersji stable i unstable w systemie. Po pierwsze zaopatrujemy się w debianowe źródła pakietu. Można dodać wpisy deb-src dla unstable w sources.list, zaktualizować listę pakietów. Następnie:

cd /usr/srcwajig source docker.iocd docker.io-1.3.3~dfsg1/wajig builddepends docker.iodpkg-buildpackage
cd ..
wajig install docker.io_1.3.3~dfsg1-2_amd64.deb

W tym momencie powinniśmy mieć zainstalowanego dockera w systemie. Nie sprawdzałem, czy działa, ale zarówno metoda druga jak i trzecia powodują, że pakiet instaluje się czysto, więc raczej będzie działać. Przykłady dla wersji 1.3.3, być może z czasem może się coś zmienić.

Nie zablokujesz Tora…

Krótkie przypomnienie: około pół roku temu pisałem, jak zablokować węzły wyjściowe Tora. Lista węzłów wyjściowych (exit nodes) Tora jest publiczna, więc wygląda, że mamy sielankę.

Logo Tor

Źródło: https://media.torproject.org/image/official-images/2011-tor-logo-flat.svg

Tymczasem dziś podczas rozmowy w gronie administratorów padło stwierdzenie od osoby, która badała ruch w sieci Tor, że podczas swoich eksperymentów zarejestrowała ruch z węzłów wyjściowych, których nie było na liście. Metodyka badania prosta jak budowa cepa: wyślij znane żądanie przez Tora do swojego hosta, zapisz IP z którego nadeszło połączenie, porównaj z listą exit nodes.

I wtedy mnie olśniło. Dla pewności zapytałem jeszcze na kanale IRC poświęconym Torowi czy nie ma jakiejś weryfikacji i… jak najbardziej jest to wykonalne. Po prostu jako exit node listowany jest IP, który jest podłączony do sieci Tor. Wystarczy więc, że maszyna ma więcej niż jedno IP lub przekierowuje ruch na inną maszynę (choćby iptables) i… połączenia Tor będą widoczne z nielistowanego adresu. Co więcej, może się on zmieniać w czasie…

Usłyszałem nawet znamienne zdanie na kanale: założę się, że są exit node’y, które po prostu wysyłają ruch przez VPN.  I to by było tyle w temacie prostych, błędnych odpowiedzi na pozornie proste pytania…