Jak usprawnić sieć w domu? cz. 5

Wpis, który chronologicznie powinien pojawić się jako drugi, ponieważ dotyczy stanu wyjściowego, czyli WiFi. Oczywiście sprzęt to opisywany niedawno TP-Link WR841 z OpenWrt. Banana Pi wpięte do portu LAN, czyli na 100 Mbps, ale głównym ogranicznikiem jest sieć bezprzewodowa. Jasności dodam, że są to wyniki sprzed optymalizacji, ale o poprawianiu WiFi napiszę innym razem. Warto też zaznaczyć, że wyniki jako jedyne są przeprowadzane na środowisku nieizolowanym, „produkcyjnym”, tj. z podłączonymi innymi urządzeniami. O ile nie powinny specjalnie rzutować na wynik, bo nie korzystały intensywnie, to na pewno wpływały w jakiś sposób ujemnie.

1.
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-60.04  sec   125 MBytes  17.5 Mbits/sec  10.997 ms  1908/16040 (12%)  
[  4] Sent 16040 datagrams

2.
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-60.00  sec  67.7 MBytes  9.46 Mbits/sec  186             sender
[  4]   0.00-60.00  sec  67.6 MBytes  9.45 Mbits/sec                  receiver

3.
— 192.168.0.139 ping statistics —
600 packets transmitted, 598 received, 0% packet loss, time 61057ms
rtt min/avg/max/mdev = 0.766/2.303/42.995/4.036 ms

4.
— 192.168.0.139 ping statistics —
600 packets transmitted, 596 received, 0% packet loss, time 60280ms
rtt min/avg/max/mdev = 1.918/3.953/42.202/3.747 ms

5.
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-3600.04 sec  6.27 GBytes  15.0 Mbits/sec  4.305 ms  71880/822270 (8.7%)
[  4] Sent 822270 datagrams
[…]
9.
Inea Orange

Jak widać stan wyjściowy nie był imponujący. Rzekłbym nawet, że zaskakująco słabe wyniki. Widać też, że brakuje części testów – przyznaję, że nie miałem ani cierpliwości, ani warunków. Ponieważ ustawienia lekko się zmieniły w międzyczasie, zostawię z brakiem, żeby nie fałszować. Zaskakuje słaby wynik transmisji w teście syntetycznym, w szczególności w porównaniu z testem do internetu.

Jak usprawnić sieć w domu? cz. 2

W poprzedniej części było o genezie cyklu, sposobach pomiaru i najlepszym możliwym połączeniu, czyli bezpośrednio skrętką. Ze względu na zainteresowanie paru osób wynikami testów PLC, przeskakuję WiFi i przechodzę do wyników testów PLC.

Na testy dostałem TL-PA4010P kit. Z tego co widzę, w wyszukiwarce znajduje zarówno, że jest to AV500 jak i AV600, ale na opakowaniu było AV600, więc link jest prawdopodobnie prawidłowy. Do podłączenia podszedłem zupełnie laicko – z tego miejsca w mieszkaniu internet ma trafić do tamtego – zupełnie nie wnikałem w to jakie są fazy i czy po drodze są listwy.

Błąd. Zalecane jest wpięcie w ten sam obwód i bezpośrednio do gniazdka, z pominięciem listew zasilających. W związku z tym wykonałem kilka testów, w tym wpisie zajmę się tylko wynikami pierwszej, najgorszej topologii – jeden kontroler bezpośrednio w gniazdku, drugi za listwą z włącznikiem i wpiętej w nią listwą zwykłą. Od razu podaję link do wskazówek jak najlepiej podłączyć PLC. Wyniki z optymalnego połączenia są lepsze i będą w kolejnym wpisie, ten to bardziej „jakoś wpiąłem i tak działało”.

Na wstępie miałem małe rozczarowanie, które rozwiewa dopiero lektura powyższego linka. AV600 oznacza 600 Mbps. I jakkolwiek przypuszczałem, że będzie to 300 upload, 300 download, to aby taki wynik osiągnąć, trzeba by mieć w urządzeniu port 1 GE. Tymczasem jak widać są tam porty 100 Mbps i taką prędkość linkowania się z urządzeniami osiągałem. Nie jest to dla mnie wielki problem, bo mój router także ma porty 100 Mbps, ale jeśli ktoś liczy na szybkie połączenie z NAS itp., to może się zawieść.

Samo podłączenie jest proste – sprowadza się do włożenia urządzeń w gniazdka, wpięcia ethernetu i naciśnięciu przycisku do parowania.

Wyniki z testu w niekomfortowych warunkach:

1.
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-60.00  sec   547 MBytes  76.5 Mbits/sec  1.195 ms  0/70059 (0%) 
[  4] Sent 70059 datagrams

2.
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-60.00  sec   418 MBytes  58.4 Mbits/sec    0             sender
[  4]   0.00-60.00  sec   417 MBytes  58.3 Mbits/sec                  receiver

3.
--- 192.168.10.126 ping statistics ---
600 packets transmitted, 600 received, 0% packet loss, time 60299ms
rtt min/avg/max/mdev = 3.310/3.657/13.757/0.965 ms
4.
--- 192.168.10.126 ping statistics ---
600 packets transmitted, 600 received, 0% packet loss, time 60338ms
rtt min/avg/max/mdev = 21.582/24.445/35.531/2.837 ms

5.
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-3600.00 sec  32.6 GBytes  77.9 Mbits/sec  1.447 ms  5136/4278660 (0.12%) 
[  4] Sent 4278660 datagrams

6.
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-3600.00 sec  24.6 GBytes  58.6 Mbits/sec    0             sender
[  4]   0.00-3600.00 sec  24.5 GBytes  58.6 Mbits/sec                  receiver

7.
--- 192.168.10.126 ping statistics ---
36000 packets transmitted, 36000 received, 0% packet loss, time 3625078ms
rtt min/avg/max/mdev = 2.759/4.280/16.010/1.247 ms

8.
--- 192.168.10.126 ping statistics ---
36000 packets transmitted, 36000 received, 0% packet loss, time 3618568ms
rtt min/avg/max/mdev = 22.662/24.105/106.475/2.133 ms, pipe 2

9.
Inea Orange

Jak widać nawet w tych niekomfortowych warunkach zestaw radził sobie przyzwoicie. Brak strat pakietów, niskie i stabilne opóźnienia. Widać wzrost czasu odpowiedzi w zależności od wielkości pakietu i jak sprawdziłem empirycznie pojawia się on przy rozmiarze pakietu między 900 a 1000 i jest to jedyna istotna różnica w stosunku do zwykłęgo ethernetu.

Niezła szybkość transmisji danych między urządzeniami nie wzbudziła mojej czujności; to, że coś chyba jest nie w porządku zacząłem podejrzewać dopiero po ostatnim teście, po podłączeniu jednego z końców kabla do routera. Dane z internetu pobierały się zwyczajnie wolno i… nie miało to pokrycia w testach syntetycznych. W tym momencie uprzedzę fakty i od razu napiszę, że przy zalecanym połączeniu wyniki w ostatnim teście były identyczne jak na kablu. Ale to już w kolejnym wpisie.

Na koniec słowo o zużyciu energii, ponieważ są to urządzenia aktywne. Podłączyłem urządzenie do watomierza. Bez podłączonego komputera pokazał 1,5W, po podłączeniu komputera i podczas transmisji danych 2,2-2,3W. Jeśli wyłączymy komputer, PLC po paru minutach przechodzi w stan uśpienia i pobiera wówczas 0,8W.

Jak usprawnić sieć w domu? cz. 1

Wstęp

Wpis jest wstępem do serii mini testów, które przeprowadziłem lub przeprowadzę w najbliższym czasie. Chodzi o rozwiązanie kwestii dostępu urządzeń w domu do internetu i zapewnienia ich łączności pomiędzy sobą. Powodem było moje WiFi, które choć doprowadzone aktualnie do zadowalającej używalności, niekoniecznie było optymalne zarówno jeśli chodzi o stabilność połączenia, jak i oferowane przepływności czy opóźnienia. Na rynku istnieje kilka rozwiązań, które mają za zadanie pomóc w dostarczeniu sieci, niedawny wpis o PLC przypomniał mi, że kiedyś interesowałem się bardziej tematem, a technika poszła naprzód.

Szybkie pytanie na wewnętrznym forum firmowym czy komuś nie zalega parka PLC spotkała się z pozytywnym odzewem (uroki pracy w większej firmie, z otwartymi geekami – ciekaw jestem czego nie dałoby się znaleźć… ;-)) i okazało się, że nie tylko zalega chwilowo, ale są różnego typu, stąd pomysł na porównanie i podzielenie się wnioskami.

Nie ma to być test uniwersalny ani profesjonalny – robię go przede wszystkim dla siebie i w dostępnym mi środowisku (a np. typ ścian czy otoczenie może mieć kolosalne znaczenie dla WiFi, podobnie wygląda kwestia sieci elektrycznej dla PLC), mam jednak nadzieję, że uda się wyciągnąć jakieś wnioski ogólne i może komuś pomoże w wyborze rozwiązania.

O ile nie napisano inaczej, wykorzystywany jest firmware dostarczony z urządzeniami. Systemy nie są specjalnie tuningowane – ot, linuksowy default. Z oczywistych względów trudno mi wypowiadać się na temat stabilności poszczególnych rozwiązań w dłuższym okresie czasu.

Topologia sieci

Topologia sieci jest następująca: modem ISP (kablówka) w przedpokoju, podłączony ethernetem do routera. Router (obecnie TL-841) z wgranym OpenWRT/LEDE dostarcza internet reszcie urządzeń po WiFi. Przedpokój to w miarę centralny punkt w mieszkaniu, odległość od urządzeń końcowych (laptopy, smartfony) ok. 7 metrów, część urządzeń pracuje w 802.11n, część w 802.11g i tak zostanie – modernizacja czy wymiana końcówek są nieopłacalne.

Dla jasności: to działa od lat i w zasadzie wystarcza, jeśli chodzi o przepływność. Wystarczało i na 802.11g, gdy transfery (do mojego laptopa) wynosiły 15-18 Mbps (wg speedtest.net). Po zmianie routera na nowszy jest lepiej – 30 Mbps. Nadal jest to gorzej niż to, co oferuje operator (60 Mbps), ale w zupełności wystarcza do transferów „z zewnątrz”. Zobaczymy jednak, czy są jakieś alternatywy i czego się spodziewać.

Ani mieszkanie w kamienicy, ani dość zaszumiony eter na 2,4 GHz, nie pomagają w dobrym działaniu WiFi, więc nieco gorzej wygląda sytuacja, jeśli chodzi o stabilność. Rzadko, bo rzadko, ale zdarzały się problemy (straty do routera, wzrost czasów odpowiedzi). Zwykle, w czasach gdy korzystałem z oryginalnego firmware producenta, wystarczał restart routera lub sprawdzenie jak wygląda sytuacja w eterze przy pomocy WiFi Analyzera i zmiana kanału na wskazany jako najlepszy (czyli najmniej używany).

Swoją drogą zmiana kanału na nieużywany jest najprostszym sposobem na poprawę zasięgu czy jakości WiFi, więc jeśli ktoś szuka odpowiedzi na pytanie jak poprawić sygnał WiFi, to zdecydowanie polecam zacząć od tego.

Pomiary

Wykonywane są cztery testy wewnętrzne, oraz ogólny test przy pomocy speedtest.net (beta, czyli bez Flash). Testy wewnętrzne wykonywane były w dwóch wariantach: krótkim (w założeniu ok. 60s) i długim (ok. 3600s).

  1. iperf3 -u -b 0 -t 60 -c 192.168.10.126
  2. iperf3 -t 60 -c 192.168.10.126
  3. ping -i 0.1 -c 600 192.168.10.126
  4. ping -s 1500 -i 0.1 -c 600 192.168.10.126
  5. iperf3 -u -b 0 -t 3600 -c 192.168.10.126
  6. iperf3 -t 3600 -c 192.168.10.126
  7. ping -i 0.1 -c 36000 192.168.10.126
  8. ping -s 1500 -i 0.1 -c 36000 192.168.10.126
  9. speedtest.net

Jak widać jest to pomiar przepływności przy użyciu pakietów UDP, TCP oraz pomiar opóźnień przy pomocy ping ze standardową oraz maksymalną (MTU 1500) wielkością pakietu. Ostatni test to „realne” połączenie z internetem. Wykorzystywane serwery mojego ISP oraz Orange, który często był wskazywany jako najlepszy.

Za klienta służy mój laptop z Debianem, za sondę posłużyło Banana Pi (jedyny SoC z gigabitowym portem, który miałem pod ręką). W obu systemach wykorzystany iperf3. Pomiar nie był jedyną czynnością wykonywaną przez laptopa, ale – poza testami WiFi – był wykorzystany osobny interfejs, a obciążenie było typowe, bez ekstremów.

Dodatkowo mogą pojawić się uwagi, jeśli coś nieplanowanego podczas testów rzuci mi się w oczy.

Wyniki bazowe

Na wstępie spiąłem oba urządzenie kablem „na krótko” i uruchomiłem testy. Synchronizacja oczywiście 1 Gbps.

1.
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-60.00  sec  6.07 GBytes   869 Mbits/sec  0.136 ms  592341/795464 (74%)
2.
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-60.00  sec  5.47 GBytes   784 Mbits/sec  138             sender
[  4]   0.00-60.00  sec  5.47 GBytes   783 Mbits/sec                  receiver
3.
--- 192.168.10.126 ping statistics ---
600 packets transmitted, 600 received, 0% packet loss, time 62319ms
rtt min/avg/max/mdev = 0.291/0.372/0.549/0.031 ms
4.
--- 192.168.10.126 ping statistics ---
600 packets transmitted, 600 received, 0% packet loss, time 62290ms
rtt min/avg/max/mdev = 0.427/0.549/24.612/0.996 ms

5.
[ ID] Interval           Transfer     Bandwidth       Jitter    Lost/Total Datagrams
[  4]   0.00-3600.00 sec   374 GBytes   893 Mbits/sec  0.220 ms  36944269/49033499 (75%)
6.
[ ID] Interval           Transfer     Bandwidth       Retr
[  4]   0.00-3600.00 sec   349 GBytes   833 Mbits/sec  8735             sender
[  4]   0.00-3600.00 sec   349 GBytes   833 Mbits/sec                  receiver
7.
--- 192.168.10.126 ping statistics ---
36000 packets transmitted, 36000 received, 0% packet loss, time 3745436ms
rtt min/avg/max/mdev = 0.278/0.369/40.914/0.398 ms

8.
--- 192.168.10.126 ping statistics ---
36000 packets transmitted, 36000 received, 0% packet loss, time 3745111ms
rtt min/avg/max/mdev = 0.260/0.500/2.861/0.046 ms

9.
Inea Orange [1]

Jak widać bez większych niespodzianek – osiągnięte wyniki wynikają raczej z ograniczenia samego Banana Pi. Mimo to widać, że jest szybko, czasy odpowiedzi niskie i jest stabilnie.

[1] W przypadku pomiaru łącz topologia była nieco inna – laptop wpięty po kablu do portu routera (port 100 Mbps). W zasadzie dokładniej byloby wpiąć go bezpośrednio w modem kablowy, ale router jest stałym elementem zestawu w pozostałych topologiach… Dostawca internetu (Inea) deklaruje 60/10 Mbps.

Termometr na USB

Dawno temu byłem zafascynowany prostym układem DS18S20, który działa za pośrednictwem 1-wire i umożliwia dokładny odczyt temperatury przez komputer. Schematów podłączenia przez RS-232 była masa, koszt układu niewielki. Jedyne co powstrzymywało mnie wtedy przed uruchomieniem to… brak realnej potrzeby.

Potem sytuacja się zmieniła – port szeregowy zaczął w komputerach zanikać, a mnie coraz bardziej interesowała
temperatura z wbudowanych czujników (płyta główna, dyski), a nie temperatura otoczenia. Były co prawda schematy jak to podłączyć przez USB, ale w stosunku do pierwowzoru rósł i poziom skomplikowania, i koszt.

Niedawno pojawiła się potrzeba (no dobra, powiedzmy, że potrzeba, bardziej pretekst), więc odświeżyłem temat.
Okazało się, że istnieją tanie moduły PL2303HX USB UART, a także nieco nowsza wersja cyfrowych termometrów, oznaczona symbolem DS18B20. Różnica między wersjami w sumie pomijalna, z perspektywy tego wpisu. Każda z tych rzeczy to ok. 6 zł z dostawą (Allegro), a podłączenie jest jeszcze prostsze i nie
wymaga żadnych dodatkowych elementów, jak widać na schemacie.

Do odczytu temperatury służy digitemp. Opis użycia (zaczerpnięty stąd).

Instalacja pakietu:

apt-get install digitemp

Skanowanie układów:

digitemp_DS9097 -i -s /dev/ttyUSB0

Odczyt wartości:

digitemp_DS9097 -a

Bardziej zależało mi na sprawdzeniu, czy taka prosta wersja faktycznie będzie działać – w wielu miejscach podawane są bardziej skomplikowane schematy. Faktycznie, działa. Rozwiązanie zlutowane na krótko, bez żadnego przewodu ma jednak tę wadę, że moduł PL2303HX grzeje się na tyle, że wpływa na odczyt temperatury. Myślę, że ok. 10 cm kabla załatwi temat, ale gdyby ktoś był zainteresowany to można pomyśleć od razu o kupnie nieznacznie droższej wersji wodoodpornej, z przewodem. Mi akurat zależało żeby kabel się nie pałętał, ale wersję z kablem można zawsze skrócić…

Oczywiście gdyby ktoś chciał całkiem nowocześnie, to teraz czujniki temperatury montuje się do ESP8266 i odczytuje po WiFi. Tyle, że w moim wypadku to niewygodne – problem z zasilaniem, a dane i tak mają trafić do pełnoprawnego komputera, ew. do SoC z Linuksem.

Gdyby ktoś bał się, że blog skręca całkiem w tematy elektroniczne – bez obaw, będzie najwyżej parę wpisów i raczej w ramach wspomnienia o czymś, niż jako podstawowa tematyka.

Pierwsze pomiary

Wygląda, że w końcu mogę napisać, że powstało coś działającego. Nie jest to oczywiście pełna funkcjonalność, ale same pomiary są skończone. Nie twierdzę, że to ostateczna wersja, w szczególności muszę się przyjrzeć logowaniu, ale to jest ten moment, kiedy mogę pobawić się wartościami z konfiguracji i zobaczyć, jak wpływają na działanie w realnych warunkach.

Jak to wygląda? Otóż tak na szybko, uruchamiając modem GSM w sieci Virgin Mobile (3G) zarejestrowany do T-Mobile (roaming):

INFO:__main__:Route default got score 24.1516556059 on interface wlan0
INFO:__main__:Route default got score 89.6018913814 on interface enx582c80xxxxxx
INFO:__main__:Route default got score 23.7111227853 on interface wlan0
INFO:__main__:Route default got score 64.5852940423 on interface enx582c80xxxxxx
INFO:__main__:Route default got score 24.101962362 on interface wlan0
INFO:__main__:Route default got score 63.8392652784 on interface enx582c80xxxxxx
INFO:__main__:Route default got score 23.9711829594 on interface wlan0
INFO:__main__:Route default got score 78.0421457793 on interface enx582c80xxxxxx
INFO:__main__:Route default got score 66.7648989057 on interface wlan0
INFO:__main__:Route default got score 62.6970052719 on interface enx582c80xxxxxx

Widać, że w ostatnim pomiarze domowe WiFi (lub operator, ale stawiam na WiFi) dało się we znaki i wypadło gorzej, niż modem GSM. Różnica jest jednak minimalna i do zmiany routingu by nie doszło, nawet na domyślnych wartościach.

Wyniki po zalogowaniu natywnie, czyli do Play:

INFO:__main__:Route default got score 23.7996305738 on interface wlan0
INFO:__main__:Route default got score 307.032244546 on interface enx582c80xxxxxx
INFO:__main__:Route default got score 24.561555045 on interface wlan0
INFO:__main__:Route default got score 267.205837795 on interface enx582c80xxxxxx
INFO:__main__:Route default got score 24.0223884583 on interface wlan0
INFO:__main__:Route default got score 268.849682808 on interface enx582c80xxxxxx
INFO:__main__:Route default got score 23.7405095782 on interface wlan0
INFO:__main__:Route default got score 275.927570888 on interface enx582c80xxxxxx
INFO:__main__:Route default got score 38.6582265223 on interface wlan0
INFO:__main__:Route default got score 287.999381338 on interface enx582c80xxxxxx

Wszystkie wyniki dla przykładowego pliku konfiguracyjnego z repo, z dostosowaną nazwą interfejsu (jest interfejs modemu zamiast eth0) i zmienionym poziomem logowania na INFO. Wywołanie w pętli 5 razy:

for i in {1..5}; do python abcc.py --config local_test.yaml; done

Przyznaję, że jestem zaskoczony wynikami – wydawać by się mogło, że natywnie będzie działać lepiej, a tu niespodzianka. Muszę jeszcze dokładniej potestować na różnych urządzeniach, dotychczas miałem wrażenie, że w roamingu jest gorzej. Ale to już temat na inny, niezwiązany z DSP2017, wpis.

Przy okazji, to drugie wywołanie wykonuje się 71 sekund, czyli około 14 sekund na jeden pełen przebieg, a ilość przesłanych podczas badania danych (odczyt z ifconfig) to:

RX packets 11342  bytes 7440400 (7.0 MiB)
TX packets 9789  bytes 1133957 (1.0 MiB)
RX packets 11640  bytes 7475184 (7.1 MiB)
TX packets 10087  bytes 1169257 (1.1 MiB)

Czyli jakieś 7kB RX i 7 kB TX per pomiar. Czyli jakieś 10 MB/dobę, przy założeniu, że będzie wywoływane co minutę, 27/7. Czyli mniej więcej mieści się w limicie bezpłatnego pakietu Freemium w Virgin Mobile. 🙂

Jak zabezpieczyć domową sieć Wi-Fi?

Ciągle słychać o błędach w urządzeniach Wi-Fi, ale zwykły użytkownik nie ma wielkiego pola manewru – z routera Wi-Fi korzystać będzie, może co najwyżej liczyć na aktualizację oprogramowania przez producenta. Postanowiłem popełnić krótki praktyczny poradnik o tym, jak łatwo zabezpieczyć sieć Wi-Fi w domu czy SOHO. Zakładam, że konfigurowany będzie dowolny router Wi-Fi, nie określonego producenta. Nie będę podawał konkretnych zakładek/nazw, bo na różnych routerach różnie się opcje nazywają. Efektem jest przyzwoicie zabezpieczony sprzęt w domu, zmniejszający także szansę na wykorzystanie luk w oprogramowaniu – w większości przypadków konieczny jest dostęp do urządzania przez atakującego.

Podstawy

Wymienione poniżej czynności są absolutną podstawą, a efektem jest przyzwoicie zabezpieczona sieć.

  1. Zmiana hasła administracyjnego do urządzenia – warunek absolutnie konieczny. Bez tego możliwe są ataki na urządzenie przy pomocy dowolnej strony odwiedzanej z przeglądarki w sieci domowej.
  2. Wyłączenie zarządzania na porcie WAN – po co ułatwiać włamania z zewnątrz?
  3. Włączenie szyfrowania WPA2 lub WPA + AES – brak szyfrowania czy WEP nie są żadnym zabezpieczeniem, któryś z tych dwóch powinien być obecny nawet w starych sprzętach.
  4. Wyłączenie WPS – dodawanie urządzeń przy pomocy PINu może być kuszącym ułatwieniem, ale drastycznie ułatwia włamanie do sieci.
  5. Aktualizacja firmware do urządzenia do najnowszej wersji – to, że urządzenie jest nowe i prosto ze sklepu nie oznacza, że ma wgrane nowe oprogramowanie. Warto sprawdzić, czy producent nie wydał nowszej wersji oprogramowania, często poprawiane są różne błędy dotyczące stabilności i bezpieczeństwa.
  6. Ustawienie silnego hasła do Wi-Fi – patrz rozdział o hasłach.
  7. Okresowe przeglądy – patrz rozdział o przeglądach.

Dodatki

Poniższe czynności są opcjonalne, ich skuteczność jest niewielka, dyskusyjna, albo niekoniecznie są proste czy w ogóle możliwe do wykonania.

  1. Wyłączenie zarządzania routerem przez Wi-Fi – jeśli komputer jest podłączony po kablu, nie jest to żadne utrudnienie, w innym przypadku średnio wygodne, ale podnosi nieco bezpieczeństwo, zwłaszcza jeśli wpuszczamy do swojej sieci różne obce urządzenia po Wi-Fi. Zabezpiecza przed ominięciem uwierzytelniania w przypadku błędów oprogramowania.
  2. Zmniejszenie mocy Wi-Fi – brak zasięgu oznacza brak możliwości zaatakowania sieci bezprzewodowej. Ale napastnik może mieć porządną antenę kierunkową… Tak czy inaczej, nie ma sensu zakłócać urządzeń sąsiadom – jeśli mamy przyzwoity sygnał to zwiększanie mocy nie poprawi parametrów naszej sieci.
  3. Wydzielenie osobnej sieci dla gości – czy to poprzez wirtualny access point, obecny w niektórych sprzętach, czy poprzez osobne urządzenie.
  4. Ukrycie widoczności sieci – moim zdaniem złudne zabezpieczenie. Atakujący i tak jest w stanie taką sieć wykryć, a może to utrudniać dołączanie urządzeń czy wybór najlepszego kanału.
  5. Ograniczenie dostępu na podstawie MAC adresu – kolejne złudne zabezpieczenie, bo MAC adresy można zmieniać. Niemniej trochę pomaga, bo nie każdy umie zmienić i nie każdy sprzęt/sterownik pozwala w prosty sposób na zmianę MAC. Wiąże się z koniecznością każdorazowego logowania na router i dopisywania MAC przy wpuszczaniu nowego urządzenia do sieci, więc niezbyt wygodne.

Hasła

Hasła powinny być możliwie długie (myślę, że w dzisiejszych czasach 14-16 znaków to rozsądne minimum), zawierać cyfry, wielkie i małe litery. Z uwagi na wpisywanie hasła do Wi-Fi na urządzeniach mobilnych, warto wziąć pod uwagę wygodę wpisywania, zwłaszcza, jeśli wpisujemy je często, na różnych urządzeniach. Znaki specjalne zwiększają bezpieczeństwo haseł, ale uważam, że lepiej (wygodniej i porównywalnie pod względem bezpieczeństwa) mieć hasło o kilka znaków dłuższe, niż ze znakami specjalnymi.

Przeglądy okresowe

Raz na jakiś czas – czy to kwartał, czy co pół roku – warto sprawdzić czy jest dostępne nowsze oprogramowanie dla routera, zmienić hasło do Wi-Fi. Jeśli korzystamy z kontroli dostępu na poziomie MAC adresu – warto od razu zweryfikować listę i usunąć zbędne urządzenia.

Uruchomienie karty Wi-Fi Mediatek MT7601U na Banana Pi

Jakiś czas temu kupiłem małe, tanie karty USB Wi-Fi w Chinach. Stwierdziłem, że przydadzą się do niewyposażonych we wbudowane karty płytek z ARM, czy nawet żeby któryś komputer podpiąć na szybko do sieci Wi-Fi w standardzie N. Karty przetestowałem na szybko na laptopie i wszystko było fajnie, ale… uruchomienie ich wymagało rzeźby i dokompilowania modułu. Dla jasności: chodzi o karty, które sprzedawane są jako Mediatek MT7601U USB bgn WiFi dongle.

Po podłączeniu w wyniku lsusb widać:

Bus 002 Device 002: ID 148f:7601 Ralink Technology, Corp.

 

a wymagany driver dla tej karty to mt7601u. W momencie podłączania karty USB w dmesg pojawia się:

[ 1075.027898] usb 2-1: new high-speed USB device number 2 using ehci-platform
[ 1075.189356] usb 2-1: New USB device found, idVendor=148f, idProduct=7601
[ 1075.196330] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1075.203764] usb 2-1: Product: 802.11 n WLAN
[ 1075.208160] usb 2-1: Manufacturer: MediaTek

 

Dziś potrzebowałem uruchomić Banana Pi pod kontrolą dystrybucji Bananian z tą kartą, wetknąłem ją w lapka, żeby odświeżyć sobie budowanie modułu i… miło mnie zaskoczył – działało od kopa. Stwierdziłem, że może zasługa nowszego kernela (4.5), ale prawdopodobnie nie – brakujący firmware jest dostarczany w Debianie w pakiecie firmware-misc-nonfree. Niedostępnym w Jessie, ale nie jest to wielki problem. Poniżej krótka instrukcja, co zrobić, żeby zadziałało (dla Bananiana 16.04 (released 2016-04-23)). Być może zadziała także na starszym kernelu, ale nie testowałem. Zgodnie z tym, co piszą na GitHubie projektu, driver jest dołączony do mainline kernela, i opisany poniżej sposób powinen działać dla kerneli od 4.2 w górę.

Instalacja kernela z linii 4.x na Banana Pi (niezalecana w FAQ Bananiana, ale…):

wajig install linux-image-4.4-bananian

 

Następnie reboot, by Banana Pi działało z nowym kernelem. Kolejnym krokiem jest pobranie pakietu z firmware dla karty:

wget http://ftp.de.debian.org/debian/pool/non-free/f/firmware-nonfree/firmware-misc-nonfree_20160110-1_all.deb

 

Usunięcie pakietów, które konfliktują z ww. pakietem (oczywiście wajig; wykonać dla wszystkich pakietów, które zgłoszą konflikt):

wajig remove firmware-ralink

 

Ostatnim krokiem jest instalacja pobranej paczki:

wajig install firmware-misc-nonfree_20160110-1_all.deb

 

Od tej pory karta USB Mediatek powinna po prostu działać po włożeniu do USB. Oczywiście należy połączyć się jeszcze z siecią bezprzewodową, ja polecam do tego wicd i wygodny konsolowy wicd-curses. Zadziała także dla Debiana w wersji stable (Jessie) – w zasadzie Bananian różni się tylko kernelem.

UPDATE Dobrzy ludzie słusznie donoszą, że firmware-misc-nonfree jest w repozytorium backports, więc instalacja jest prostsza – wystarczy dodać stosowne repozytorium do źródeł. Przyznaję, że nie sprawdzałem, bo jakoś mi się błędnie zakodowało, że ani armel, ani armhf nie są dostępne w backports.

Internet rzeczy nadchodzi

Internet rzeczy jest coraz bliżej. Coraz więcej sprzętów posiada interfejsy sieciowe, przez które można nimi zarządzać, przez które mogą one wymieniać dane i… przez które można się włamać. Rozmawiałem ostatnio z ludźmi bardziej siedzącymi w temacie i wygląda to źle. Sprzęt jest słaby (w sensie mocy obliczeniowej), przez co ograniczone są implementacje bezpiecznych protokołów. Brakuje jednego wspólnego standardu zarządzania – generalnie co produkt/producent, to autorski system komunikacji, co gorsza, rzeczy są wystawiane bezpośrednio do internetu, bez ograniczenia do wydzielonej sieci lokalnej[1].

Czasem mam wrażenie, że twórcy zbyt skupili się na aspekcie elektronicznym, a zupełnie pominęli część może nie tyle programistyczną, co sieciową. Rozumiem, że SNMP nie jest jakoś bardzo powszechne w świadomości, a możliwość ustawiania danych przy jego jest jeszcze mniej znana, ale IMO nadaje się do IoT idealnie. Zresztą, nawet ustandaryzowany JSON byłby OK, a pewnie bardziej strawny dla programistów.

Gdyby już istniał standard wymiany danych, to można by zrezygnować z wystawiania rzeczy na świat. Nie mam złudzeń, sytuacja z aktualizacją rzeczy będzie wyglądać jeszcze gorzej, niż w przypadku istniejących urządzeń, a przecież z routerami czy kamerami IP już w tej chwili jest dramat. O ile o aktualizacji oprogramowania w kamerze czy routerze jeszcze ktoś pomyśli, to co z lodówką, głowicą grzejnika czy żarówką? Jakoś wątpię, by były aktualizowane, nawet, jeśli producent przewidzi taką możliwość.

Mam wizję, że rolę bramy dostępowej, czyli centrum, które uwierzytelnia użytkownika i łączy się z rzeczami pełniłby router. Po pierwsze, i tak jest na brzegu sieci, więc warto by go zabezpieczyć, zaktualizować. Po drugie, z racji miejsca ma najlepsze połączenie z zewnętrznym światem. Po trzecie, routery są/bywają stosunkowo mocnym sprzętem, szczególnie w porównaniu z rzeczami, a nawet niekoniecznie ustępują słabszym desktopom. No i zawsze można jakąś płytkę z procesorem ARM wykorzystać. Do tego parowanie certyfikatów brama-rzecz przy pierwszym uruchomieniu i jest względnie bezpiecznie, oczywiście przy wyłączeniu możliwości komunikacji z innymi hostami po parowaniu i zabezpieczeniu (aktualizowaniu) bramy.

Na koniec taka refleksja, chociaż może to tylko moje odchylenie – czy naprawdę potrzebujemy wszystkiego zautomatyzowanego i podłączonego do internetu? Rozumiem proste timery załączające urządzenia np. do grzania wody czy czy termostaty elektroniczne do sterowania ogrzewaniem, ale czy włączanie żarówek przez internet jest tak naprawdę potrzebne? Albo czy lodówka musi informować, że mleko/piwo się skończyło?

W przypadku ogrzewania z jednej strony pewnie wystarczy automatyzacja na poziomie „w dni powszednie włączaj ogrzewanie o 6:30, w weekendy o 8:00”, z drugiej jednak, przy synchronizacji ze smartfonem, można by ustawić, żeby ogrzewanie załączało się zawsze pół godziny przed budzikiem, po prostu. No i zależy, czy mieszkanie, czy dom. IMO w domu sterowanie żaluzjami i trochę bardziej zaawansowana automatyka mogą mieć sens i ekonomiczny (konkretne oszczędności), i nie widać na pierwszy rzut oka, gdzie się światło świeci. W każdym razie ja wolę jednak bardziej manualne sterowanie i do IoT się nie spieszę.

[1] Co też nie do końca jest rozwiązaniem, ponieważ przy domyślnych danych (IP, login, hasło) atakujący jest w stanie wykonać atak z lokalnej przeglądarki użytkownika – wystarczy prosty JS…

Bity na godzinę…

Ostatnio czytam książkę Myśl jak Sherlock Holmes. Głupio tak coś więcej o książce pisać, bo w połowie jestem, ale… Uczucia bardzo mieszane, bo ma ambicję być poradnikiem pełną gębą, a mnie śmieszy traktowanie Dr Watsona i Sherlocka Holmesa jako postaci rzeczywistych, a nie jedynie literackich, ale momentami ciekawa. Bardziej jako ładnie ubrane anegdotki i ciekawostki, niż „poważny” poradnik.

No i w pewnym momencie taki kwiatek:

Bity na godzinę

Wi-fi: 802,11 b/g (bity na godzinę)

Zawsze się zastanawiałem, o co chodzi z tym b/g i w końcu jest odpowiedź! 🙂 I pozostało zadać pytanie: ile jest tak naprawdę w cytowanym tekście, będącym podpisem zdjęcia, błędów?

UPDATE: Jestem na finiszu i muszę powiedzieć, że książka jest ciekawa, spostrzeżenia trafne. Nadal, Sherlock Holmes jest IMO bardziej ilustracją, mającą zaciekawić czytelnika i nie brałbym tego w 100% na poważnie, ale warto przeczytać.

Zmiana routera (TP-Link WR841-N)

Od dłuższego czasu myślałem o tym, by zmienić router. Problem w tym, że Linksys WRT54GL, którego miałem, działał. Do tego miał wrzucone OpenWrt, więc był bezpieczniejszy i wygodniejszy, niż większość dostępnego sprzętu. Koniec końców zracjonalizowałem sobie, że 802.11n jest odporniejsze na zakłócenia (a trochę problem z zasięgiem/zakłóceniami owszem, był), szybsze (osiągnięcie maksymalnej prędkości netu możliwe było tylko teoretycznie)i w ogóle lepsze. I jest sporo modeli, które pozwalają na wgranie OpenWrt.

Trochę poczytałem, trochę poklikałem TP-Linka u kumpla (na firmware producenta), popatrzyłem na ceny… I kupiłem  TL-WR841N (wyszło mi, że umie OpenWrt, niedrogi, wrażenie u kumpla – bdb) w markecie na jakiejś pseudopromocji. Nie pamiętam dokładnie ile zapłaciłem, ale jakoś 60-80 zł[1]. I leżał. Z kwartał. Bo nie chciało mi się wymienić routera, skoro stary działał…

Ostatnio zauważyłem, że pojawiają problemy z siecią okresowo. Pingi do routera rzędu 1000ms. Potem działało normalnie. Kanał ustawiony optymalnie, przynajmniej na tyle, na ile się dało. Stwierdziłem, że pora przetestować router.

Router TL-WR841N

Źródło: http://www.tp-link.com/en/products/details/cat-9_TL-WR841N.html

Pierwsze co mi się rzuciło w oczy, to informacja o licencji GPL wydrukowana na świstku papieru (po angielsku) i polska instrukcja. Miłe i sprawia dobre wrażenie. W instrukcji dla tych, którzy nie korzystają z dołączonej płyty CD zauważyłem ciekawą rzecz. Aby podłączyć się do routera polecają nie wpisanie adresu typu http://192.168.0.1 tylko… http://tplinklogin.net Tak, domena nie istnieje i IMHO jest to bug security. Scenariusz, gdzie użytkownik łączy się z netem przy pomocy takiego routera (domyślne login i hasło to admin/admin), wchodzi na stronę i dostaje malware w postaci JS, który przejmie kontrolę nad routerem nie jest wcale trudny do wyobrażenia. Co prawda podobno TP-Linki w swoim DNS mają zaszytą tę domenę i same rozwiążą to zapytanie, jeśli tylko komputer pobiera zarówno adres IP, jak i konfigurację DNS z DHCP, ale… po co?

Oczywiście połączyłem się po IP, bo taka wersja też działa. Przy tym mam inną konfigurację i serwer cache DNS mam bezpośrednio na komputerze. Dalej było z górki. Przeklikałem wstępnie konfigurację (wyłączenie WDS, ustawienie preferencji WiFi), pobrałem najnowszy firmware producenta (na OpenWrt przyjdzie jeszcze czas…)  i wrzuciłem go na urządzenie. Wszystko zadziałało elegancko (ba, pierwszy firmware był nawet po polsku). Sympatycznie wygląda opcja, której włączenie pozwala routerowi samodzielnie wybierać kanał. Włączyłem, zobaczę jak to się w praktyce będzie sprawdzać. Inna miła rzecz to obsługa kilku dostawców dyndns, w tym no-ip.com, z którego korzystam. Nie skonfigurowałem, ale czuję, że może to być ten punkt, który pozwoli mi na długie nie wgrywanie OpenWrt. Wstępny test prędkości i… zamiast 15-18Mbps które widziałem do tej pory jest ~30Mbps.

Oczywiście nie wszystko mogło działać poprawnie. Windows na jednym z kompów stwierdził, że adres IP z DCHP owszem, pobierze, ale już sieć nie działała, nawet router się nie pingował. Karta to Atheros AR5007EG
 (a/b/g, niestety nie ma n). Spróbowałem na szybko uruchomić „pchełkę” Mediateka na USB, ale wyszło jeszcze gorzej. Sieć co prawda ruszyła, ale przy restarcie nie chciał się uruchomić system – krzyczał o błąd w DLL. Możliwe, że przedobrzyłem z ustawieniami programu pomocniczego do karty pozwalając mu włączyć sieć przed zalogowaniem użytkownika. Parę prób zmian konfiguracji na routerze (szerokość kanału itp.) nie pomogło. Włączenie trybu bez n – też nie. W końcu stwierdziłem, że trzeba ustalić, czy problem jest z samą kartą, czy systemem/sterownikiem. Uruchomienie Linuksa i… karta jak najbardziej działa.

Szybkie przeszukanie sieci i znalazłem zalecenie, by zaktualizować sterownik. I faktycznie. Problem rozwiązało pobranie najnowszych sterowników do Atherosa (a wydawało mi się, że mam względnie nowe…). Po aktualizacji sterownika karty wszystko ruszyło od kopa. O stabilności TP-Linka nic nie piszę, bo działa raptem kilkadziesiąt godzin. Póki co, jestem zadowolony.

[1] Linksys kosztował w momencie kupna IIRC 180 zł, choć nie był najtańszym sprzętem z *Wrt. Fajny spadek cen, wzrost możliwości i poszanowania GPL daje się zaobserwować.

UPDATE Jeszcze o jednej sympatycznej cesze nowego sprzętu zapomniałem – mały apetyt na prąd. Kiedyś mierzyłem, ile prądu bierze Linksys i wahało się to od 2,5W (sam zasilacz, duży, transformatorowy jeszcze), przez 6,9W (router idle, 2 komputery podłączone) do 7,5W przy transferze danych między dwoma komputerami po WiFi). Nowy router nie był dokładnie testowany, ale po włączeniu routera i jednego komputera watomierz pokazał 2,5W, czyli tyle, ile poprzednio sam zasilacz. Myślę, że mogę przyjąć, że jest to 5W mniej, czyli 3,6 kWh w skali miesiąca. Czyli ok. 2 zł oszczędności. Czyli na samym prądzie nowy sprzęt zwraca się w jakieś 3 lata.

Monitoring w pracy

Nadzór w pracy istnieje od zawsze. Jakby nie było, jest to jedna z funkcji kadry kierowniczej. Zastanawiałem się ostatnio, jak to wygląda obecnie, co się zmieniło. O tym, że coraz więcej zakładów ma zamontowane kamery powszechnie wiadomo. Zresztą rejestratory video staniały i spowszedniały na tyle, że spora część znajomych ma je zamontowane w samochodach czy na rowerach. Opinie na ich temat w miejscach pracy są różne, część pracowników jest (była?) zdecydowanie niechętna, ale IMO tak naprawdę wszystko zależy, jak są wykorzystywane i umieszczone. Pracuję w miejscu, gdzie są kamery i raz mi osobiście jako pracownikowi się przydały.

Sprawa trywialna, coś z laptopem i dyskiem było. Kumpel przyniósł czyjegoś służbowego lapka, ja wyjąłem z niego dysk, podłączyłem do kieszeni, IIRC zrobiłem diagnostykę, wkręciłem dysk z powrotem, oddaję lapka. No i przychodzi kumpel, pokazuje zdjętą zaślepkę, pusto, i pyta „a gdzie dysk?”. Szukamy. Tak całkiem pewien, że go wsadziłem z powrotem to nie byłem, bo raczej odruchowo działałem, więc sprawdzam biurko, szuflady. Jak się tak rozglądam, to jestem coraz bardziej przekonany, że włożyłem z powrotem. Kumpel upiera się, że dostał ode mnie, otworzył i było pusto. Zgrzyt.

No to wzięliśmy nagranie z rejestratora. I widać jak wyjmuję, podłączam do kieszeni, wkładam z powrotem, przykręcam. Kumpel obraca lapka tak, jak jest na kamerze i pokazuje pustą dziurę po lewej. Patrzymy w monitor, wkręcam po prawej. WTF? Patrzymy na lapka i w śmiech. Ano tak, laptop był 17″ i miał dwa sloty na dysk, ale to zupełnie nie przyszło nam do głowy.

Tak czy inaczej, nagrania z kamer są dość dokładne (no dobrze, zależy od kamery i ustawień jeszcze), ale raczej trudno je analizować automatycznie. Forma strawna dla komputera to raczej osoba, timestamp, określenie miejsca. Oczywiście da się zrobić, bo pozycjonować można choćby smartfona (i aktywnie, przy pomocy aplikacji na smartfonie, i pasywnie, z wifi), no ale nie każdy pracownik w zakładzie musi mieć smartfona, włączonego, z wifi itd.

Niedawno dostałem namiar na stronę https://www.autoid.pl/ czyli dostawcy systemów do automatycznego… praktycznie wszystkiego – identyfikacji osób, przedmiotów, pojazdów itp. i dostałem odpowiedź na moje pytanie, jak można w sposób łatwo przetwarzalny komputerowo monitorować miejsce przebywania pracownika w firmie. Technologia opiera się na RDIF, które mogą służyć nie tylko do jako karty dostępu do drzwi (de facto standard w firmach, kto nie ma karty?), ale w wersji „dalekiego zasięgu” (do 12 m)  mogą być odczytywane bez przykładania do czytnika. Wygląda na prostsze i tańsze od smartfona u pracownika, prawda?

Producent podpowiada nawet sposoby umieszczenia – zaszycie w ubraniu roboczym, oraz jako karta. No i w tym momencie można automatycznie sprawdzić… wszystko. Na przykład to, czy dany pracownik pracuje na swoim stanowisku, czy siedzi i flirtuje z sekretarką. Z których pomieszczeń korzysta. Albo jak często wychodzi do toalety.

Uczucia, podobnie jak w przypadku kamer mam mieszane. Oczywiście wyobrażam sobie nadużycia ze strony pracodawcy z wykorzystaniem tego typu technologii, ale… nie dajmy się zwariować. Równie dobrze może wykorzystywać tego typu rozwiązania do optymalizacji rozmieszczenia narzędzi/pomieszczeń… Tworzący prawo będą mieli kolejny trudny orzech do zgryzienia.

Czyli klasyczne: narzędzia nie determinują wykorzystania. Pozostało życzyć wszystkim normalnych AKA ludzkich pracodawców, którzy rozsądnie korzystają z narzędzi. I pracowników, których nie trzeba kontrolować na każdym kroku.

PLNOG 11

Jedenasta edycja PLNOG zapisze mi się w pamięci jako PLNOG na którym z jednej strony wyjątkowo drażniły mnie prezentacje marketingowe (jakoś miałem pecha może, że trafiłem na więcej, niż zwykle? a może bardziej drażniące były?), a z drugiej strony jako ten na którym było sporo rzeczy związanych z sieciową społecznością. Może parę słów o tych bardziej pozytywnych sprawach…

Po pierwsze, wykłady ISOC – fajny pomysł. Trochę szkoda, że tak izolowane miejscowo były. Na listę mailową ISOC Polska zapisałem się już wcześniej, teraz miałem okazję zobaczyć na żywo. Niestety nie porozmawiałem z nikim na żywo. Po cichu mam nadzieję, że będzie okazja na kolejnym PLNOG.

Przy okazji panelu o DDoSach, Łukasz Bromirski wrócił do pomysłu zjednoczenia ISP w walce z DDoSami. I od razu rzucił się do działania tworząc listę operatorów bezpieczeństwa. Dodatkowo publicznie zapowiedział dokończenie projektu BGP blackholing. Trzymam kciuki. Padło też stwierdzenie, że w sumie mało komu zależy, by DDoSów nie było: jest to okazja do sprzedania większego pasma, dedykowanego sprzętu czy serwisu, który je neutralizuje. Oraz – chyba najważniejsze, że problem DDoSów mogą rozwiązać dostawcy łącza (często: użytkownikom końcowym), ale dla nich to tylko koszt. Z kolei ofiarami i „płatnikami” są głównie duże firmy. A zarabiają pośrednicy.

Chyba najciekawsza (IMVHO) inicjatywa, która pojawiła się na PLNOG 11: wifi community Polska, czyli projekt zrzeszający dostawców Internetu, którzy będą oferować bezpłatny dostęp do Internetu użytkownikom, którzy mają usługę u któregokolwiek z nich. Taka trochę wymiana klientów lub pożyczanie infrastruktury[1]. Rozwiązanie podobne do fon.com, z którego w Polsce korzysta Netia, ale ma działać tylko w naszym kraju (za to pewnie z lepszym pokryciem). Celowane głównie – ale nie tylko – w kablówki, bo ich sprzęt spełnia wymogi (rozgłaszanie 2 różnych SSID). Dla ISP uczestniczących w projekcie da możliwość pochwalenia się łączem i ma być dodatkowym atutem przyciągającym klientów. Dla klientów – możliwość skorzystania z bezpłatnego łącza wifi w różnych lokalizacjach (publiczne, ale nie tylko) i – przy odpowiednim pokryciu – może to być jakaś alternatywa dla dostępu typowo mobilnego, szczególnie w miastach. Na razie pomysł na etapie koncepcji, ale podstawy OK, ma to ręce i nogi technicznie. Pewne sprawy proceduralne trzeba będzie dopracować.

[1] Bardziej zainteresowanych odsyłam do filmu z wykładu/prezentacji, jak tylko się pojawią. Tam jest dokładne tłumaczenie co to ma być, po co, na jakich zasadach i szczegóły techniczne.

Ryzyko prowadzenia węzła Tora.

Oczywiście wpis jest inspirowany tymi dwoma wpisami. Mocno rozbieżne w wymowie są. Pierwszy bardziej w tonie „jak oni mogli?!”, drugi z kolei mocno zorientowany na ryzyko. Jak dla mnie sprawa jest prosta: prowadząc wyjściowy węzeł Tora[1] należy mieć świadomość, że służby mogą wpaść z wizytą. W końcu jest prawie pewne, że prędzej czy później dojdzie do jakiegoś przestępstwa z IP przydzielonego w danym momencie do węzła wyjściowego. A policja lubi się popisywać i w prosty sposób podbijać sobie statystykę. Był powód do kipiszu? No był…

Zresztą, w Polsce też były podobne akcje, tyle, że z tego co mi wiadomo nie trafiły do mediów. Jedna z osób narzekała na wizytę policji i konfiskatę komputerów (lub dysków) w celu zabezpieczenia dowodów. Zresztą z tego co kojarzę bardzo szybko były zwrócone. No i prowadzący wyjściowy węzeł nie miał narkotyków itp.

Trochę też nie rozumiem o co ten hałas, w końcu w FAQ Tora jest napisane, czego można się spodziewać prowadząc węzeł. Co prawda dałbym głowę, że jest tam wspomniane o możliwości wizyt policji (a nie jest), więc pewnie miesza mi się z prezentacją dotyczącą Tora na MeetBSD sprzed paru lat. W każdym razie należy założyć, że takie wizyty są możliwe, chociaż widzę, że nie są częste. Pozytywne jest to co piszą, że policja zaczyna być świadoma istnienia węzłów i przed wizytą (czy to rozmową, czy wjazdem), zaczyna sprawdzać, czy faktycznie chodzi o węzeł, czy o końcowego użytkownika.

Co nie oznacza, że prowadzenie węzłów pośredniczących (relay nodes, bridge nodes) też wiąże się z ryzykiem. Tu żaden ruch nie wychodzi na zewnątrz sieci Tor. Służby nie bardzo mają powód czy pretekst do wizyty. Nawet maila nie wyślą (sprawdzone empirycznie, różne węzły, parę lat). I w sumie jeśli chcą faktycznie łapać przestępców, to mogliby współpracować z prowadzącymi węzły. Bo przy odpowiedniej wiedzy i współpracy policji na skalę międzynarodową osoby korzystające z Tora (końcowi użytkownicy) są jak najbardziej możliwe do namierzenia. Zresztą, zdaje się były publikacje naukowe na ten temat.

W każdym razie głównie trzeba czytać i rozumieć, co się robi i jak to działa. Za bardziej ryzykowne osobiście uważam posiadanie niezabezpieczonej lub słabo zabezpieczonej sieci wifi. Ktoś może jej użyć do równie nielegalnych celów, a wtedy nie ma żadnych przesłanek by uważać, że czynności dokonał ktoś inny, niż użytkownik danego adresu IP.

[1] To tylko jeden z typów węzłów, służący jako ostatni pośrednik między siecią Tor a zwykłym Internetem.

PS Nagonka na Tora ma miejsce nie po raz pierwszy a tu krótki opis jak łatwo skonfigurować bridge node.

Android na tablecie – spotkanie drugie.

Poprzednio opisywałem tablet Go Clever A73 i wspominałem o problemach z baterią. Tablet w ramach reklamacji trafił do Biedronki, gdzie został zakupiony, a tam od ręki został wymieniony na nowy. Fajnie. Mniej fajne jest to, że drugi egzemplarz ma identyczny problem, po opisaniu na Blipie usłyszałem, że komuś to samo zrobił to samo. Stawiam zatem na błąd w samym Androidzie, szczególnie, że do samego czasu działania nie mam większych zastrzeżeń. Nie sprawdzałem dokładnie, ale grając w jakieś gry łącznie na pewno ponad 2h jest.

Tym bardziej, że błędów tego typu jest jakby więcej – ostatnio jakaś gra pytała się, czy włączyć dźwięk. Dałem wyłącz i od tej pory cały system nie ma dźwięku. W ustawieniach jest mute i nie mogę zmienić. Czyżby kolejny bug? Zastanawiam się teraz, jak włączyć ten dźwięk… Pomogło wyłączenie tabletu, a następnie włączenie odtwarzacza muzyki. Co ciekawe, przed wyłączeniem nie reagował na włączanie aplikacji z dźwiękiem.

Zacząłem doceniać chmurę – co prawda nie mam pełnej synchronizacji włączonej, nawet rzekłbym, że wszystko mam wyłączone, ale sklep Play (fatalna nazwa i będzie się z operatorem komórkowym mylić…) pamiętał aplikacje, które miałem zainstalowane i były pod ręką. W sumie miłe, szczególnie jeśli weźmie się pod uwagę mało intuicyjne wyszukiwanie. Gdyby któryś producent zrobił tego typu integrację z jasnym podziałem, które dane mają być w chmurze, a które lokalnie, to pewnie się przekonam. Póki co, coraz bliżej mi do wrzucenia w chmurę danych poddanych szyfrowaniu, najlepiej dwukrotnemu, różnymi aplikacjami i algorytmami. Tyle, że to raczej typowe dane, a nie same ustawienia, i nie z tableta, a z komputera.

Poza tym, tablet Go Clever A73 faktycznie ma słabe WiFi. W niewielkim mieszkaniu odejście od AP na kilka metrów powoduje zauważalne zmiany sygnału, podobnie zmiana położenia urządzenia, jeśli jest w dalszej odległości. Wszystko odkryte dzięki aplikacji Wifi Analyzer (wymyślna nazwa, prawda? ;-)), która pokazuje poziom sygnału w czasie, pomaga wybrać kanał, na którym należy skonfigurować router itp. Bardzo fajny programik, ciekawe czy jest jakiś odpowiednik na Linuksa? Przy okazji okazało się, że sąsiedzi mają za router jakiegoś smoka, prawdopodobnie rozkręconego na full, który w całym moim mieszkaniu ma praktycznie równy sygnał, momentami silniejszy od mojego routera.