WPS prawie tak słaby jak WEP.

Wygląda, że WPS (włączony domyślnie w wielu routerach) jest w tej chwili porównywalnie słaby, jak WEP. Niezależnie od użytego WPA/WPA2 możliwe jest – przy włączonym WPS – stosunkowo szybkie poznanie hasła do sieci WiFi ofiary, dodatkowo są gotowe narzędzia do tego celu (np. reaver-wps spaczkowany niedawno dla Debiana). Spodziewać się można niebawem aktualizacji firmware’ów dla routerów z dodaniem/wydłużeniem czasu dla funkcji lock down, ale to nie jest rozwiązanie, tylko drobne utrudnienie. Do szczegółów, w tym czasu brute force na WPS odsyłam do krótkiego, ale treściwego pdf ze strony.

Jak sprawdzić, czy sieć obsługuje WPS (czyli czy dana sieć jest podatna)? Najprościej (na Linuksie) przy pomocy wpa_supplicantPrzemek w komentarzach na tej stronie opisał jak, a wygląda, że da się prościej i wystarczy (Debian Squeeze z wicd jako helperem do WiFi):

wpa_cli scan
wpa_cli scan_results | grep WPS

Jeśli okaże się, że mamy włączonego WPS, a go nie potrzebujemy, to wypadałoby zmienić hasło do sieci WiFi oraz poszukać, czy WPS nie da się wyłączyć. Często (zwykle?) się da, przynajmniej na Linksysach.

Jak sprawdzić IP komentującego?

Ostatni wpis traktujący o tym jak sprawdzić IP komputera zaowocował sporą ilością zapytań o to, jak sprawdzić IP komentującego na blogu albo forum. Sprawa może być utrudniona, bo adres IP bywa uznawany za daną osobową, a poza tym dobra praktyką jest ukrywanie przynajmniej części adresu przed osobami postronnymi. Zasadniczo wyróżnić można dwa przypadki:

Sprawdzanie IP komentarza przez osoby postronne

Wariant gorszy, bo dostęp jest bardzo ograniczony. W tym wariancie mamy trzy przypadki:

  • Komentarz zamieszczony jest z zarejestrowanego konta – w takim przypadku adres IP ukryty jest całkowicie. Niewiele można zrobić, ale – patrząc z drugiej strony – wiemy dokładnie, kto (jaki nick) zamieścił dany komentarz, co zwykle lepiej określa osobę, niż adres IP.
  • Jeśli komentarz dodawany jest bez logowania do serwisu, wygwiazdkowany. Również niewiele można zrobić, chyba, że ukrywanie części adresu jest zrobione bez głowy, np. schowana jest dokładnie jedna cyfra. Także schowanie jednego bloku adresu IP (np. wyświetlone 100.101.102.*) może pomóc w określeniu, kto dany komentarz zamieścił.
  • Komentarz z widoczną nazwą hosta. Z niewiadomych przyczyn (zapewne chodzi o głęboką wiedzę w temacie, szerokie spojrzenie i konsekwencję) urzędnicy nie uznają – w przeciwieństwie do adresu IP – nazwy hosta za daną osobową, przez co pojawia się ona w wielu serwisach/forach zamiast IP komentującego, więc możemy zobaczyć np. adaa194.neoplus.adsl.tpnet.pl. Sprawdzenie IP w takim przypadku to zwykłe uruchomienie polecenia ping adaa194.neoplus.adsl.tpnet.pl (tak, ping nie jest do tego, ale jest dostępny na wszystkich systemach, popularny, jednolity…). Jeśli ktoś woli wersję online lub nie wie, jak dobrać się do wiersza poleceń w systemie, to pomoże strona hostname IP lookup

Sprawdzanie IP komentarza przez właściciela serwisu

Wariant lepszy, bo obok wszystkich środków dostępnych w poprzednim przypadku, możemy:

  • Sprawdzić IP po zalogowaniu do systemu. Wiele systemów udostępnia w takim wypadku wprost IP komentującego właścicielowi bloga.
  • Sprawdzić IP przy blokowaniu komentarzy z danego IP. Nawet jeśli adresy IP komentujących nie są widoczne wprost, to często pojawiają się podczas blokowania możliwości komentowania, czy to wprost, czy w linku do blokowania, czy wreszcie na liście adresów zablokowanych (blokujemy możliwość komentowania autorowi komentarza na moment, patrzymy jaki adres, odblokowujemy).
  • Sprawdzić IP w systemie statystyk, jeśli korzystamy z takiego na stronie. Szczególnie przydatne przy niewielkim ruchu – łatwo wtedy skorelować dane wejście odnotowane w statystykach z czasem zamieszczenia komentarza. Na pewno ładnie widać to w stat4u, z którego korzystam.

Możemy też oczywiście sprawdzić IP połączenia, z którego zamieszczono komentarz w logach serwera WWW, jeśli działa na naszym hostingu lub mamy dostęp do logów.

HTH i łącznie z poprzednim wpisem wyczerpuje temat ustalania adresu IP.

Praca na desktopie z małą ilością RAM po raz trzeci – zram.

W poprzednich wpisach było parę przemyśleń i sugestii poprawy komfortu pracy na desktopie wyposażonym w niewielką ilość pamięci RAM, bez finalnego rozwiązania choć z paroma trickami poprawiającymi pracę, więc pora na podejście trzecie do tematu, inspirowane przez kumpla z IRC, który sprzedał mi „newsa” o zram.

Od pewnego czasu (okolice kernela 2.6.37, jeśli dobrze widzę) w kernelu Linuksa obecny jest moduł zram, pozwalający na tworzenie kompresowanych urządzeń blokowych w pamięci RAM. Wykorzystać to można podobnie jak compcache, czyli do tworzenia kompresowanego obszaru pamięci, używanego przez system przed przeniesieniem danych na swap na dysku. Idea jest prosta – swap na dysku jest tragicznie wolny i obciąża I/O, procesor zwykle się trochę nudzi, zresztą nie będzie miał dużo więcej pracy, a ilość wolnej pamięci się zwiększy.

Ogólnie zram jest ideowym spadkobiercą compcache, ale wygląda mi na prostszy i ideowo, i w użyciu. No i jest obecny w kernelu. Idea działania jest prosta: tworzymy swap z wyższym priorytetem, niż swap na dysku, na urządzeniu blokowym umieszczonym w kompresowanym obszarze pamięci. Początkowo dane tradycyjnie są w RAM, w przypadku, gdy system musi korzystać z przestrzeni wymiany, umieszcza je najpierw na swapie w RAM, a dopiero później – tradycyjnie – na swapie na dysku.

Prosty skrypt realizujący powyższe:

#!/bin/bash
modprobe zram
echo $((200*1024*1024)) > /sys/block/zram0/disksize # 200 MB
mkswap /dev/zram0
swapon -p 60 /dev/zram0

Kolejno: załadowanie modułu zram (można korzystać z parametrów), określenie rozmiaru dysku dla urządzenia /dev/zram0 na 200 MB (i jest to rozmiar swap, będący jednocześnie maksymalną wielkością zużytej pamięci, nie rozmiarem przeznaczonej pamięci na swap!), utworzenie swapu na urządzeniu  /dev/zram0, włączenie utworzonego swap z priorytetem 60.

Podobno efekty są świetne – zaczynam testy u siebie, wstępnie nie wygląda źle, na pewno niebawem podzielę się wrażeniami (jako update do tego wpisu) po dłuższym teście. Jeśli chodzi o rozmiar swap dla modułu zram, to zacząłbym od 10-20% całości RAM (u mnie 200 MB przy 1 GB RAM). Z tego co zauważyłem, skompresowane dane zajmują w praktyce ok. 40-50% oryginalnych.

Parę przydatnych poleceń diagnostycznych:

  • cat /sys/block/zram0/compr_data_size – rozmiar danych po kompresji
  • cat /sys/block/zram0/orig_data_size – rozmiar nieskompresowanych danych
  • cat /sys/block/zram0/mem_used_total – całkowita ilość zużytej pamięci
  • swapon -s – rozmiar i wykorzystanie poszczególnych swap (inna jednostka!)

Linki w temacie, które zdecydowanie warto przejrzeć, jeśli ktoś jest bardziej zainteresowany:

Szczególnie ostatni wpis zawiera fajny, uwzględniający ilość procesorów skrypt startowy. Można rozważyć użycie po przeanalizowaniu. IMHO dla 1-2 procesorów trochę kosmiczne wartości będą, uzależnianie wielkości swap od ilości procesorów też jest średnie, ale poprawienie to nic trudnego. Za to obsługą utworzonego urządzenia blokowego zajmie się w tamtym wariancie więcej, niż jeden procesor. Z drugiej strony kto ma więcej niż dwa rdzenie i mało RAM?

Miałem obawy co do działania hibernacji (z użyciem pm-utils, z uswsusp miałem problem…) w takiej konfiguracji. Niepotrzebnie, bo wygląda, że działa OK – zapewne hibernacja jest na tyle inteligentna, że rozpoznaje, czy ma do czynienia z fizycznym urządzeniem blokowym.

Oczywiście swap to nie jedyne możliwe zastosowanie modułu zram – więcej przykładów w linku do wiki Gentoo.