Migracja z Aero2 na a2mobile

The world’s changing. Music’s changing. Even internet is changing.

Tak to się jakoś pomału kręci z tymi zmianami i mam pomysł na notkę z obserwacjami nt. zmian szybkości komputerów i (bardziej) łącz, ale to innym razem. Internet u rodziców miał się dobrze (via modem GSM i Raspberry Pi robiące za router), tylko pakiety Aero2 schodziły ciut szybciej, niż przewidywałem. Znaczy chyba raz zdarzyło się, by zeszły więcej niż dwa w miesiącu, ale dwa na miesiąc IIRC schodziły regularnie.

Do tego doszedł średni panel (klikasz „dodaj do koszyka” i jak nie pamiętasz, że dodawanie trwa, to możesz dodać kolejny raz, nim pierwszy „zaskoczy”), zaliczyli wyciek danych klientów no i – last but not least – pojawiły się inne oferty na rynku. W szczególności ciekawie wyglądała oferta a2mobile, gdzie za 10 zł na miesiąc mamy internet bez limitu transferu. Tj. innego niż prędkość łącza, a ta spada wraz ze zużyciem transferu, czyli klasyczny lejek. Do 5 GB transferu jest bez limitu prędkości, do 10 GB jest limit 3 Mbps (modem bez LTE, w praktyce właśnie w tych okolicach łącze działa), do 15 GB jest limit 1 Mbps, a potem 512 kbps. Zakładam, że poniżej 10 GB nie spadnie. 😉

Głównym wyzwaniem okazało się… zdobycie startera. Nie chciałem zamawiać kurierem, w FAQ pisali, że startery są do kupienia w sklepach Żabka. Właściwsze byłoby sformułowanie bywają, bo kupić udało mi się jakoś przy czwartym podejściu. Po czym musiałem zaliczyć wizytę na poczcie w celu rejestracji, więc chyba lepiej wziąć tego kuriera, zakładam, że umie on potwierdzić dane kupującego.

Konfiguracja wvdial jest w zasadzie analogiczna do tej od Aero2, zmienia się jedynie APN oraz wypadają user i hasło, czyli finalnie sekcja w wvdial.conf wygląda tak:

[Dialer a2mobile]
Modem = /dev/ttyUSB0
Init1 = AT+CGDCONT=1,"IP","a2mobile.pl"
Phone = *99#
Stupid mode = yes
Username = "blank"
Password = "blank"
Dial Attempts = 0
Auto DNS = "off"

Wrzucam, bo podobne wpisy były, nie znalazłem gotowca w sieci dla a2mobile, ale tak naprawdę wszystko jest do siebie podobne i łatwo zmienić konfigurację, jeśli ma się skonfigurowany APN na telefonie z Androidem… Kiedyś jeszcze była konfiguracja wvdial dla Orange.

OpenWrt na TP-Link WR841-N

Wczoraj nietypowo, bo ostatniego dnia roku zrobiłem jedną z rzeczy, które chodziły za mną od pewnego czasu, mianowicie wgrałem OpenWrt na domowy router. Ten sam, który kupiłem jakieś półtora roku temu. Późno, ale… jakoś nie miałem weny, a firmware producenta (aktualizowany kilka razy) w zasadzie działał.

Przynajmniej tak mi się wydawało. Jakiś czas temu przestała mi działać strona IKEA. Zarówno na komputerze, jak i telefonie. Oczywiście przyjąłem, że to wina ISP, bo strona zaczynała działać, jeśli korzystałem z netu przez GSM, zarówno na smartfonie, jak i na komputerze podłączonym do niego. A nie działała na żadnym z trzech różnych sprzętów i z tego co pamiętam nawet na ping nie odpowiadała.

Któregoś razu stwierdziłem, że sytuacja jest męcząca, więc sprawdzę o co chodzi dokładnie, czy to problem z routingiem, czy co. Ku mojemu zdziwieniu po odpaleniu sniffera okazało się, że jest komunikacja, nawet dwustronna. Tyle, że mocno szczątkowa. Uniewinniłem więc w myślach ISP i zacząłem męczyć IKEA, że może blokują moje IP z jakiegoś powodu.

Rozmowy były trudne, bo z jednej strony wyraźnie czułem, że się nie rozumiemy (no nie trawię tekstów od osób niezbyt technicznych „to musi być problem z przeglądarką”, jak piszę, że na trzech różnych OS sprawdzam i że na innym łączu działa), z drugiej trochę rozumiem, skoro problem nie był po ich stronie. W każdym razie udało mi się uzyskać zapewnienie, że nie blokują.

Olśnienia doznałem jak włączyłem stronę IKEA w sumie przypadkowo i odruchowo na jeszcze innym, stareńkim komputerze w domu i… zadziałała. Zacząłem szukać różnic i znalazłem. Stareńki sprzęt łączył się po 802.11g, wszystkie nowsze po 802.11n. Oczywiście nie powinno mieć to żadnego znaczenia, ale… miało.

Winę za to ponosił prawdopodobnie firmware routera (zresztą jakaś beta – taki był najnowszy). Od tego czasu oficjalnie uznawałem, że muszę zaktualizować do OpenWrt.

Aktualizacja bardzo prosta i przyjemna – wystarczy przeczytać instrukcję dla odpowiedniej wersji hardware (v9) i wgrać odpowiedni firmware. Klikalne GUI, w sumie wszystko działa na pierwszy rzut oka, przynajmniej z podstawowych funkcji. Wydajność OK na pierwszy rzut oka. Jak zwykle polecam i zastanawiam się, czemu tak późno się zdecydowałem.

UPDATE: Ostatecznie, za sprawą komentarzy i wizyty na IRC na kanale traktującym o OpenWrt korzystam z LEDE. Może będzie o tym notka, ale w skrócie: nowszy soft i równie łatwa instalacja.

Internet bez kabla

Raspberry Pi radzi sobie w połączeniu z modemem Huawei 3131 (stara wersja) zaskakująco dobrze jako router do Aero2 (wariant płatny). Przesiadka z Banana Pi nie była całkiem bezproblemowa – internet w domu co prawda działał, ale straciłem zdalny dostęp przy pomocy autossh. Diagnostyka była prosta – okazało się, że nie wystarczy skopiować skrypty i crony, warto jeszcze sprawdzić, czy autossh jest w ogóle zainstalowane…

Prawdopodobnie przez brak nawiązanego połączenia SSH zmienia się IP i przesyłanych (a w zasadzie zliczanych) jest więcej danych podczas okresowego (co 5 minut) wywoływania wget w ramach namiastki dyndns. Znaczy zamiast jednego pakietu 3GB po 5 zł sztuka miesięcznie schodzą dwa. Można kupić więcej od razu, więc żaden problem, zresztą i tak raczej się zdziwiłem, że na początku mieścili się w jednym.

Internet z GSM działa przyzwoicie. Nie zauważyłem ani specjalnych lagów, ani spowolnienia. Co prawda może to być kwestia porównywania ze starym pakietem, ale póki co skłaniam się ku teorii, że jestem w stanie przesiąść się w domu całkowicie na internet bezprzewodowy, po GSM. Przynajmniej technologicznie, bo ceny wyższych pakietów jeszcze nie zachwycają. Poza tym, LTE działa podobno jeszcze lepiej…

Pozostało dołożenie drugiego modemu z internetem od innego operatora, uruchomienie abcc do wybierania aktualnie lepszego (i działającego) łącza i… tyle. No, muszę przerobić jeszcze wywoływanie autossh, bo zrobiłem proste @reboot w cronie, co słabo się sprawdza w przypadku zerwania sesji – raz się jednak pakiet Aero2 skończył i trzeba było doładować, a jak się nie zrobi tego od razu, to się zapomina.

Oczywiście można kombinować jeszcze z wyniesieniem modemów GSM w lepsze miejsce, podpięciem anten itp. ale… po co komplikować, skoro działa? Z drugiej strony byłby pretekst do zabawy z antenami i potestowania wpływu siły sygnału GSM na prędkość działania internetu.

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.

Porządki

Od jakiegoś czasu noszę się – niezbyt intensywnie, ale jednak – z zamiarem zmiany dostawcy internetu u rodziców, czyli rezygnacji ze starego, wolnego łącza ADSL, ale taniego w wartościach bezwzględnych, będącego zaszłością na rzecz czegoś nowego, szybszego i przede wszystkim tańszego. Bo 1 Mbps ssie coraz bardziej. Klasyczne radiówki-osiedlówki odpadały zawsze w przedbiegach. Prędkość OK, ale za dobrze znam realia, więc wiem, że ze stabilnością może być… różnie, a na prędkości aż tak mi nie zależy. Do tego dochodzi jednak konieczność montażu anteny i to, plus brak istotnych różnic w cenie przeważa szalę. Żeby był sens cokolwiek zmieniać, to cena musiałaby spaść do jakichś 25 zł/m-c.

Potem pojawił się internet od operatorów GSM. Początkowo drogi, ale ceny już spadły, transfery i opóźniania są niższe, niż na obecnym rozwiązaniu. Jedynym problemem, który pozostał, są pakiety ruchu. Na routerze mam odpalonych trochę własnych gratów (backupy, wykrywanie spamu na Blox itp. itd.), do tego dochodzi ruch generowany przez komputery. Z logów pppd wynika, że wysyłane dane to 50-100 MB/dobę, a pobierane to 500-1000 MB. Gdyby któryś operator dawał 30 czy 50 GB w pakiecie za grosze, to nie byłoby problemu, ale niczego takiego nie znalazłem (TBH nie szukałem jakoś intensywnie).

Zatem do tej pory głównym blokerem było ustalenie, co generuje transfer. O ile ustalenie, czy ruch powstał lokalnie, czy pochodzi z końcówek nie jest problemem (wystarczy sprawdzić liczniki na interfejsach), o tyle totalnie odbiłem się od możliwości ustalenia, które procesy generują ruch sieciowy w Linuksie. Tzn. problemu nie ma, jeśli są to działające cały czas demony, ale jeśli mamy – jak w tym przypadku – wiele skryptów uruchamianych z crona, w dodatku korzystających z zewnętrznych poleceń to jest… ciężko. Wyszło mi, że można albo zrobić wrapper, podpiąć go pod wszystkie skrypty i zliczać ruch przy wywołaniu, albo – jeśli uruchomione procesy działają dłużej – uruchamianie z crona skryptu, który sprawdzi dane dla aktualnie uruchomionych procesów w /proc. Tak czy inaczej, trochę za dużo pracy w stosunku do potencjalnego zysku, bo ostateczne i tak nie wszystkie skrypty chcę wynieść na obcą infrastrukturę.

Dziś siadłem, rzuciłem okiem w crona i odpowiedziałem sobie na zajebiście ważne pytanie: co jest tak naprawdę niezbędne? Zbieranie danych o Blox i spamie – z tego nic się nie urodzi. Backupy blogów – przeniesienie w inne miejsce jest trywialne. Więc nie będę zliczał ruchu, tylko wyłączę rzeczy, które raczej generują spory transfer, a które były kiedyś fajne i zajmujące, ale są już nieprzydatne i działają z rozpędu. Za tydzień zaś po prostu sprawdzę, ile jest wygenerowanego ruchu i jak to się ma do pakietów danych w GSM.

I tu pytanie do czytelników. Jakie rozwiązania (operatorzy, pakiety) do transmisji danych po GSM polecacie? Warunki brzegowe: cena oraz brak abonamentu (dokładniej: lojalki). Na razie na oku mam:

  • Aero2 z pakietami 30 GB za 30 zł (to na wypasie, starczyłoby i teraz, ale jak mówiłem, bez sensu zmiana cenowo) oraz 3 GB za 5 zł (brzmi bdb i jest spora szansa, że po porządkach dwa czy trzy takie wystarczą w zupełności)
  • Virgin Mobile z pakietami 3 GB za 15 zł oraz 10 GB za 25 zł (gdybym mieścił się w odpowiednio dwóch i jednym pakiecie). Niby drożej, ale jest szansa, że opędzę wszystko na kodach USSD plus dochodzi normalny numer głosowy, co może nie być głupie.

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.

Jak zrobić router GSM na Linuksie?

Niedawno miałem awarię netu. Stwierdziłem, że warto przy tej okazji poćwiczyć awaryjne udostępnianie sieci na Linuksie. Oczywiście zrobienie routera z komputera z Linuksem to kwestia paru poleceń, ale stwierdziłem, przećwiczyć udostępnianie sieci po wifi.

Istnieje pakiet hostapd, który ułatwia zamianę komputera z Linuksem w access point. Instalacja pakietu hostapd:

apt-get install hostapd

Jakość pakietu nie zachwyca, ale jest niezły tutorial do hostapd. Skrypt init nie zadziała (należy go uzupełnić o ścieżkę do pliku – zmienna DAEMON_CONF), podobnie sam pakiet nie dostarcza – jak to zwykle ma miejsce w przypadku pakietów Debiana – pliku konfiguracyjnego umieszczonego w katalogu /etc. Przykładowy plik konfiguracyjny dla hostapd znajdziemy jednak w /usr/share/doc/hostapd/examples.

Żeby nie przedłużać, poniżej cały plik konfiguracyjny, którego ostatecznie użyłem:

interface=wlan0country_code=PLssid=NAZWA_SIECIhw_mode=gchannel=6wpa=2wpa_passphrase=TAJNE_HASLOwpa_key_mgmt=WPA-PSKwpa_pairwise=TKIPrsn_pairwise=CCMPauth_algs=1macaddr_acl=0

Jak widać, są lekkie różnice w stosunku do tutoriala. Brakujące ustawienie zmiennej w skrypcie startowym znalazłem później, więc ostatecznie uruchamiałem hostapd z ręki, bez demonizacji (w ramach debugu, zresztą).

Oczywiście sama konfiguracja hostapd nie wystarczy. Trzeba mieć jeszcze skonfigurowane „przyjście” netu. W moim przypadku internet był dostarczony z modemu GSM (tutaj opis konfiguracji Aero2 na modemie Huawei E3131). Użycie modemu LTE pozwoli oczywiście zrobić router LTE na Linuksie. Przyda się również serwer DHCP i konfiguracja DNS. Obie rzeczy może załatwić dość dokładnie opisany kiedyś dnsmasq, ale tak naprawdę dla przydzielania adresów IP systemom łączącym się z naszym routerem GSM wystarczą dla ww. konfiguracji dwie linie w /etc/dnsmasq.conf:

interface=wlan0dhcp-range=192.168.1.100,192.168.1.200,255.255.255.0,1h

Należy też dodać adres IP na interfejsie wlan0, włączyć forward pakietów dla IPv4 oraz uruchomić NAT. Wersja „ręczna” ww. czynności (dla mojej konfiguracji, interfejsy mogą się zmieniać) to:

ip a a 192.168.10.1/24 dev wlan0
ip link set wlan0 up
service dnsmasq restart
echo "1" > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

Po tym wszystkim, inne komputery powinny móc się połączyć z naszym linuksowym routerem GSM, dostać adres IP oraz posiadać dostęp do internetu za jego pośrednictwem. W przypadku problemów warto sprawdzić kolejno: otrzymanie adresu IP, ping do routera (192.168.10.1), ping do świata po IP, ping do świata pod domenie (w zasadzie: resolvowanie DNS).

Na rynku jest sporo sprzętów, które pozwolą na budowę mocnego routera GSM na Linuksie (przykładowo Banana Pi, Orange Pi czy nieśmiertelne Raspberry Pi). Oczywiście jeśli miałby być to sam router, to nie bardzo widzę sens ekonomiczny, bo zestaw modem+płytka+karta wifi+zasilacz pewnie będzie kosztował więcej, niż tani router LTE (no chyba, że ktoś akurat – jak ja – ma ww. graty pod ręką 😉 ), ale w przeciwieństwie do taniego routera GSM można tu uruchomić dodatkowe funkcjonalności typu NAS, VPN czy serwer WWW. Ten ostatni to może niekoniecznie na łączu GSM…

Mam nadzieję, że opis się przyda. Gdybym o czymś zapomniał, albo coś nie działało, proszę o uwagi.

PS. Oczywiście mam świadomość, że udostępnienie internetu z GSM potrafi w trzech kliknięciach zrobić chyba każdy smartfon z Androidem i w przypadkach awaryjnych jest to najszybsza droga. I tak, użyłem Aero2 i pakietu testowego bez captcha. Niskie opóźnienia pozytywnie zaskakują.

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…

SLA 99.5% – so what?

SLA na poziomie 99,5% robi wrażenie, prawda? Przy okazji dyskusji pod wpisem u Boniego poleciało 99.5% jako synonim jakości (czegoś tam). Co z kolei skłoniło mnie do sprawdzenia, jak to się ma do danych dotyczących dostępności łącza, które wystawiam przy pomocy PUM. No i w skrócie: 99,5% dostępności w skali miesiąca to żaden wyczyn.

Na początek disclaimer: nie jest to wyraźnie napisane w FAQ, ale z tego co się dowiedziałem od autorów/supportu, Uptime Robot w wersji darmowej nie zlicza (poprawnie?) uptime dla okresu powyżej jednego miesiąca. Co niestety nie przeszkadza mu zwracać jakichś wartości dla okresów powyżej 30 dni.

The Free Plan can return uptime ratios back to 1 month due to the limit of the logs kept. The Pro Plan supports back to 1 year. And, the alltimeuptimeratio variable in the API currently returns 1-month uptime (and it’ll be removed from the APIv2).

I jak widać z powyższego, All uptime to tak naprawdę, w przypadku planu darmowego, uptime dla poprzedniego miesiąca.

Spójrzmy na the domek. Komputer Linuksem (OK, Seagate Dockstar robiący za router, więc trochę embedded w porównaniu z typowym PC, czyli bardziej niezawodny), za to z dyskiem w kieszeni USB, bez jakiegokolwiek podtrzymania prądu przy pomocy UPS. Łącze przez wiekowy modem USB, 3rd party dostawca over linia TPSAOrange (BSA).

Aby było weselej: połączenie resetowane raz dziennie, skrypt podnoszący/sprawdzający uruchamiany co 4 minuty , a PPPoE trochę wstaje…

I cała ta rzeźba, łącznie z przerwami po stronie 3rd party usługodawcy, Orange, dostawcy monitoringu (czyli Uptime Robot), zwłoką przy odświeżaniu dyndns (monitoring jest po domenie) i problemami w globalnym internecie daje radę. Generalnie, bo oczywiście są miesiące, że nie da.

99.5% my ass… 😉

[1] Nie pamiętam już, czemu tak, zdaje się, że musiał mieć chwilę na sprawdzenie albo ubicie pppd, albo nie chciało mi się pisać obsługi lockfile’a, bo parę minut przerwy w nocy i tak jest pomijalne w tym zastosowaniu…

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.

Własny DNS cache jako lekarstwo na problemy z siecią

Jest powiedzenie, że nowe to dobrze zapomniane stare. Tak jest w przypadku DNS i ataków różnej maści. Niedawno głośno było o DDoSach z użyciem DNS amplification, potem o podmianie DNS (głównie na routerach, nie jak kiedyś na komputerach, ale cel ten sam), a od niedawna popularne stało się generowanie dużej ilości zapytań do serwerów DNS rekursywnych ISP (AFAIK też ostatecznie rodzaj DDoSu). Na tyle dużej, że niektórzy operatorzy mieli/mają problemy z obsłużeniem żądań pochodzących od swoich klientów na swoich serwerach cache’ujących.

Z różnych pokątnych źródeł (Facebook, IRC) wiem, że pierwszego dnia, gdy się to zaczęło, były problemy z dostępem do Internetu w sieciach należących do Inei i Multimedii. Nie znam przyczyny, ale biorąc pod uwagę, że jeszcze jednemu providerowi „kończyły się” maszyny obsługujące rekursywne DNS i że w przypadku Multimedii pomagała zmiana w systemie na np. serwery DNS Google, przypuszczam, że chodzi właśnie o niewydolność serwerów DNS dostarczanych użytkownikom tych sieci przez ISP.

Rozwiązanie jest dość proste – wystarczy uruchomić swój serwer DNS rekursywny lub forwarder na desktopie czy routerze w swojej sieci, by sieć zaczęła działać lepiej i być mniej zależna (lub nawet niezależna) od DNSów naszego ISP. Ja na swoich desktopach (oczywiście Linux) od dłuższego czasu mam uruchomionego unbound (pokłosie benchmarków DNS) – jest lekki i bezproblemowy. W obecnej sytuacji mamy podwójną korzyść z własnego cache: po pierwsze, jak zwykle odpowiedzi udzielane będą nieco szybciej[1], po drugie, uniezależniamy się od serwerów naszego ISP, który w związku z niewesołą sytuacją w sieci może mieć problemy z działaniem w ogóle.

Z kolei w przypadku sieci lokalnych i routerów sprzętowych działających pod kontrolą OpenWrt lub podobnego systemu warto zwrócić uwagę na mały i zgrabny dnsmasq, którego konfigurację opisywałem kiedyś dość dokładnie.

Niezależnie od wyboru, koniecznie pamiętajmy o zabezpieczeniu czyli poprawnej konfiguracji naszego serwera DNS. Obsługujmy zapytania rekursywne tylko z naszej zaufanej sieci (np. LAN). W przeciwnym razie nasz serwer może zostać wykorzystany do DDoS poprzez DNS amplification. Ograniczać można na wiele sposobów w zależności od użytego serwera i możliwości: firewall, ograniczenie nasłuchiwania do konkretnego interfejsu lub definicje obsługiwanych prefiksów w konfiguracji samego serwera.

[1] Nie zawsze jest to prawdą, liczy się nie tylko opóźnienie do serwera, ale także zawartość jego cache czy wydajność sprzętu, na którym działa. Pisałem kiedyś szerzej o wyborze serwera DNS.

0-day w Linksysie ma szerszy zasięg czyli problem z UPnP dla Broadcom..

Zgodnie z wcześniejszą zapowiedzią firma DefenseCode opublikowała szczegóły nt. niedawnego 0-day na routery Linksys. Okazuje się, że chodzi o implementację UPnP w firmware Broadcom i – jak można się spodziewać – w takiej sytuacji podatnych jest znacznie więcej routerów, różnych producentów. Na pewno podatność dotyczy Linksysa WRT54GL, WRT54G3G, prawdopodobnie WRT310N, poza tym, dotknięty potencjalnym błędem chip może występuje w urządzeniach urządzeniach wielu producentuów, m.in. Netgear, Asus, D-Link, Zyxel, TP-Link.

Padało pytanie, czy exploit działa z WAN czy z LAN. Z dokumentu wynika, że w wielu przypadkach działa spoza sieci lokalnej. Pojawia się stwierdzenie, że jedyna popularna implementacja UPnP, która nie posiada błędu, to MiniUPnP (tak, open source, tak, OpenWrt jest odporne). Pora na zmianę firmware’u, chociaż UPnP mam wyłączone. Ciekawe swoją drogą, czy wyłączenie UPnP eliminuje podatność.

UPDATE: Znalazłem dwa ciekawe, polskie serwisy nt. bezpieczeństwa, do których odsyłam zainteresowanych tematem bezpieczeństwa. W szczególności pierwszy pisze więcej o tym konkretnie zagadnieniu (wygląda, że wyłączenie UPnP pomaga), a tutaj znajdziecie istny pogrom domowych urządzeń sieciowych.

0-day w Linksysie załatany?

Widzę, że właśnie na stronach Linksysa pojawił się do pobrania nowy firmware, oznaczony Ver.4.30.16 (Build 4), z datą wydania 10.01.2013 (co ciekawe, jeszcze wczoraj go tam nie było). Prawdopodobnie chodzi o załatanie 0-day opisywanego ostatnio. Z release notes możemy wyczytać:

Firmware 4.30.16 (build 4)- Resolves XSS issue.

Pora na aktualizację.

UPDATE: W komentarzu lolo napisał, że takowego firmware’u nie ma. Jak nie ma, jak jest? pomyślałem (nawet zainstalowany), ale patrzę i faktycznie. Zamiast tego pojawił się Ver.4.30.16 (Build 2), który w release notes ma dokładnie taki sam opis. Jak będę przy kompie, gdzie mam pobrany Ver.4.30.16 (Build 4), to sprawdzę, czy są identyczne binarnie. Stay tuned.

Co prawda nadal nie sprawdziłem czy się różnią, ale proponowana wersja zależy od tego, czy pozwolimy się przekierować ze strony dla US, czy nie.

Zdalny 0-day na routery Linksysa.

Pierwotna informacja pojawiła się jakiś czas temu (dokładnie 9 stycznia), wczoraj widziałem wpis pochodny ale widzę, że żaden polski serwis newsowy nie kwapi się z publikacją, więc warto rozpropagować/ostrzec, tym bardziej, że exploit dotyczy potencjalnie 70 mln urządzeń na całym świecie, w tym dość popularnych WRT54GL i okolic. I – jak to 0-day – także najnowszego firmware’u. Co prawda piszą, że działa na 4.30.14, a najnowsza wersja to 4.30.15, ale data wydania wskazuje, że to firmware z 2011 roku.

Dokładne szczegóły nie są znane, działanie exploita można zobaczyć na filmie (poniżej). Na pewno, jak widać na filmie, działa z poziomu sieci lokalnej. Być może działa także zdalnie, ale zapewne warunkiem będzie włączone logowanie do routera po WAN. Szczegóły mają być zamieszczone w ciągu tygodnia na stronie firmy, która błąd znalazła.

Rozwiązania od producenta, czyli Cisco na ten moment nie ma. Dla wielu routerów można wgrać alternatywne oprogramowanie, czyli DD-WRT, OpenWrt lub Tomato, co wg mojej wiedzy rozwiązuje problem. Tak się zastanawiam, czy to nie pochodna błędu w DD-WRT o którym kiedyś pisałem. Wygląda podobnie.

UPDATE: Wygląda, że błąd w routerach Linksys został poprawiony.