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ę. 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. Wolę więc 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.