Tag: router

Opublikowane w

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.

Opublikowane w

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ć szybszy router GSM na Linuksie. Przyda się również serwer DHCP i konfiguracja DNS. Obie rzeczy może załatwić dość dokładnie opisany kiedyś dnsmasq. Ale 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ą zbudować mocny routera GSM na Linuksie. Choćby 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. W przypadkach awaryjnych jest to pewnie najszybsza droga. I tak, użyłem Aero2 i pakietu testowego bez captcha. Niskie opóźnienia pozytywnie zaskakują.

UPDATE: Istnieje coś takiego jak projekt RaspAP, o którym warto wspomnieć. Narzędzie umożliwia konfigurację access pointa WiFi w ładny (GUI) sposób. Wsparcie dla wielu języków, wygodny dostęp do wielu opcji.

Opublikowane w

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…