Jak łatwo jest wykryć VPN?

Wirtualne sieci prywatne (VPN) rozwiązują wiele problemów związanych z prywatnością. Ponieważ VPN zwykle szyfruje ruch między Twoim komputerem a dostawcą VPN, obserwatorowi bardzo trudno jest zobaczyć Twój ruch i zobaczyć, co zamierzasz. Jest jednak wiele osób, które chcą ukryć fakt, że w ogóle korzystają z VPN; na przykład osoby w krajach, które zakazują VPN lub inne sytuacje, w których korzystanie z VPN nie jest ogólnie dozwolone lub blokowane za pomocą środków technicznych. W tym artykule skupiamy się na rodzaju danych, które obserwator może zbierać z przechwytywania pakietów sieciowych i jak te dane mogą zostać wykorzystane do wykrycia użycia VPN.


Tło problemu

Palącym pytaniem jest „dlaczego”? Kogo to obchodzi, jeśli ktoś odkryje, że korzystasz z VPN? Jeśli ruch i tak jest mocno zaszyfrowany, w czym problem?

To prawda, że ​​w wielu sytuacjach i w wielu krajach nie ma znaczenia, czy obserwator wykryje użycie VPN. Istnieje jednak wiele krajów, które zakazują korzystania z VPN, dlatego ważne jest, aby użytkownicy VPN w tych krajach wiedzieli, jak można je wykryć.

Aby ustalić, czy VPN jest używany, obserwator musi mieć dostęp do routera, przez który przechodzi ruch docelowy. W przypadku atakowanej ofiary osoba atakująca może wydać ogromne zasoby na określenie sposobu przejęcia routera, z którego korzysta konkretna ofiara. W przypadku inwigilacji państwa narodowego skuteczne wykrycie wymagałoby kontroli wielu routerów. Kiedy połączysz te dwie rzeczy - organizację, która dba o to, czy używasz i VPN i również ma zdolność kontrolowania dużej liczby routerów - co zwykle wskazuje na podmiot zagrożenia na poziomie krajowym.

Pamiętaj, że ten artykuł dotyczy sposobów, w jakie obserwatorzy mogą odkryć użycie VPN. Nie musi to oznaczać, że dane zaszyfrowane w tunelu VPN są łatwiejsze do wykorzystania.

Metodologia testowania

Bez dostępu do zasobów na poziomie stanu moja platforma testowa i metodologia są nieco mniejsze. Utworzyłem małą sieć wewnętrzną za pomocą trzech maszyn wirtualnych (VM) z VirtualBox. Topologia sieci jest taka:

Konfiguracja sieci testowej VPN

Zainstalowałem oprogramowanie do wykrywania pakietów na maszynie wirtualnej routera OpenWRT, a następnie przetestowałem różne konfiguracje VPN na dwóch pozostałych maszynach wirtualnych. Oprogramowanie do wykrywania pakietów, tcpdump, pozwoliło mi przechwycić ruch sieciowy maszyn wirtualnych do analizy. W bardziej realistycznej konfiguracji oprogramowanie do przechwytywania pakietów prawdopodobnie byłoby zainstalowane w routerach w Internecie lub przynajmniej w sieci dostawcy usług internetowych. Strategiczne umieszczenie oprogramowania analitycznego wymagałoby pewnej wiedzy na temat punktów zainteresowania konwergencji w Internecie, w których prawdopodobnie będzie płynąć docelowy ruch. W mojej sieci testowej wiem ze 100% pewnością, że cały ruch do i z moich maszyn wirtualnych będzie przechodził przez ten router OpenWRT. Dlatego jest to dla mnie najlepsze miejsce do umieszczenia narzędzi do zbierania.

Nietechniczne źródła wskaźników VPN

Nie wszystkie źródła danych wskazujące na użycie VPN mają charakter techniczny. Podczas gdy niektóre są bardzo techniczne, takie jak analiza pakietów, niektóre są bardzo nietechniczne, takie jak błąd ludzki i codzienna rutyna.

Niezamierzony ruch sieciowy

Większość użytkowników VPN ma oprogramowanie klienckie, które należy uruchomić, aby ustanowić VPN. Bardzo trudno jest zapewnić, aby żaden ruch nie był przesyłany przez Internet przed ustanowieniem VPN podczas uruchamiania komputera. Nawet te sieci VPN z przełącznikami „zabicia” mogą nie być w stanie nic zrobić z ruchem przechodzącym podczas uruchamiania systemu.

vypr-vpn-autoconnect-mode

vypr-vpn-killswitch-mode

Aby to przetestować, ustawiłem opcje automatycznego łączenia i zabijania przełącznika VyprVPN na maszynie wirtualnej z systemem Windows. Następnie zamknąłem komputer z systemem Windows, rozpocząłem przechwytywanie pakietów na routerze OpenWRT i uruchomiłem komputer z systemem Windows. Te dwie sekwencje wygenerowały wiele interesujących pakietów.

Po pierwsze, możemy zobaczyć wiele sygnałów ping do podobnego zakresu adresów IP. Nie pogrupowałem celowo tych pakietów - w ten sposób zostały one wysłane organicznie:

vypr-vpn-windows-boot-ICMP-pack

To sugeruje, że coś próbuje wyliczyć serwery. Bardzo częstą przyczyną tego typu ruchu w scenariuszu VPN jest klient VPN, który próbuje ustalić najszybszy serwer. Jednym ze sposobów na to jest wysłanie pakietu ICMP (znanego jako ping) do zestawu serwerów, aby zobaczyć, które z nich najszybciej wracają.

Widzimy z pierwszego zrzutu ekranu, że 209,99.63.34 zwrócił się najszybciej w 99 milisekundach. W dalszej części przechwytywania pakietów nagle widzimy, że większość ruchu od tego momentu jest szyfrowana i jest przeznaczona na 209,99.63.34

vypr-vpn-windows-boot-QUIC-pakiety

Następnym elementem układanki jest ustalenie, jakie są adresy IP. Korzystając z IP WHOIS, który podaje zarejestrowanego właściciela adresu IP, możemy zobaczyć, że wszystkie z wyjątkiem tych adresów IP należą do YHC Corporation i rozwiązują problemy z serwerami w centrum danych Foundry Data:

209.99.108.46
Nazwa organizacji: YHC Corporation
OrgTechEmail: [email protected]
209.99.109.167
Nazwa organizacji: YHC Corporation
OrgTechEmail: [email protected]
209.99.113.70
Nazwa organizacji: YHC Corporation
OrgTechEmail: [email protected]
209–99–115–97
209,99.117.82
Nazwa organizacji: YHC Corporation
OrgTechEmail: [email protected]
209,99.21.36
Nazwa organizacji: YHC Corporation
OrgTechEmail: [email protected]
OrgTechEmail: [email protected]
209,99.22.46
Nazwa organizacji: YHC Corporation
OrgTechEmail: [email protected]
209,99.60.34
Nazwa organizacji: YHC Corporation
OrgTechEmail: [email protected]
209,99.61.42
Nazwa organizacji: YHC Corporation
OrgTechEmail: [email protected]
209,99.62.34
Nazwa organizacji: YHC Corporation
OrgTechEmail: [email protected]
Nazwa organizacji: Powerhouse Management, Inc.
OrgTechEmail: [email protected]
209,99.63.34
Nazwa organizacji: YHC Corporation
OrgTechEmail: [email protected]
209,99.63.34
Nazwa organizacji: YHC Corporation
OrgTechEmail: [email protected]
209,99.67.41
Nazwa organizacji: YHC Corporation
OrgTechEmail: [email protected]
209,99.72.70
Nazwa organizacji: YHC Corporation
OrgTechEmail: [email protected]
209,99.75.70
Nazwa organizacji: YHC Corporation
OrgTechEmail: [email protected]
209,99.93.34
Nazwa organizacji: YHC Corporation
OrgTechEmail: [email protected]
209,99.94.37
Nazwa organizacji: YHC Corporation
OrgTechEmail: [email protected]
209,99.95.40
Nazwa organizacji: YHC Corporation
OrgTechEmail: [email protected]

Logicznym następnym krokiem byłoby zeskanowanie tych adresów IP w celu sprawdzenia, jakie usługi są uruchomione. Nie podam szczegółowych informacji, jak to zrobić, ale moje testy pokazują, że domyślne banery połączeń wyświetlane przez większość serwerów zostały usunięte z serwerów VyprVPN, więc nie ma oczywistych informacji, że te adresy IP obsługują serwer VPN.

Niewiele można zrobić z zachowaniem komputera przed uruchomieniem. Dlatego jeśli chcesz zaciemnić ten typ sekwencji konfiguracji, musisz uruchomić VPN „przed” komputerem. Jednym ze sposobów jest uruchomienie klienta VPN na routerze zamiast klienta na komputerze. Nadal będziesz uruchamiać te same sekwencje uruchamiania po ponownym uruchomieniu routera, ale zwykle jest to rzadziej niż na komputerze.

Brak niezaszyfrowanych pakietów

Jak wspomniałem powyżej, po zakończeniu pingowania przechwytywanie pakietów pokazuje zaszyfrowany ruch do najszybszego adresu IP. Jeśli obserwator widzi tylko zaszyfrowane pakiety, a nie pojedynczy niezaszyfrowany pakiet, może to oznaczać, że używana jest sieć VPN. Podczas gdy świat szybko przesuwa się w kierunku szyfrowania jak największej ilości danych w Internecie, wciąż istnieją pewne żądania, które zwykle nie są szyfrowane. Należą do nich zapytania DNS, zapytania NNTP (serwer czasu) i rozproszenie innych żądań protokołu, takich jak FTP i Telnet, które są czasami używane w niektórych naszych aplikacjach, ale w ogóle nie obsługują szyfrowania.

Wycieki z niechlujstwa ludzkiego bezpieczeństwa operacyjnego (OpSec)

Wiele pozornie istotnych danych można uzyskać od celu za pomocą pozornie trywialnych informacji. Wiele osób spędza dużo czasu i wysiłku na łagodzeniu tego, co postrzegają jako „ważne”, tylko po to, by zidentyfikować je poprzez trywialne informacje, o których nie pomyśleli. Niektóre przykłady obejmują długą pamięć Internetu, która ujawniła, że ​​administratorem poczty Hillary Clinton był najprawdopodobniej facet o imieniu Paul Combetta; Dread Pirate Roberts, AKA Ross Ulbricht, rzekomy mistrz nielegalnego rynku internetowego Silk Road, został oskarżony w dużej mierze z powodu danych na jego laptopie, które zostały mu fizycznie zabrane podczas rozproszenia w bibliotece publicznej.

Mniej dramatycznie obserwatorzy często wykorzystują takie rzeczy, jak cykle aktywności, aby określić strefę czasową celu lub obecność znaków specjalnych w wiadomości, aby zidentyfikować układ języka odpowiadający krajowi celu. Nie ma pełnej listy rzeczy, które należy wziąć pod uwagę przy rozważaniu bezpieczeństwa operacyjnego, ponieważ wymyślanie nowych sposobów porównywania danych jest głównie ćwiczeniem wyobraźni i zasobów.

Istnieją jednak pewne szczególne rzeczy związane z przechwytywaniem pakietów, które mogą identyfikować użycie VPN.

Znaki ostrzegawcze z metadanych pakietu

Ponowne klucze PFS są przewidywalne

Ponieważ ruch VPN jest zwykle szyfrowany, na ogół jest ukryty przed wścibskimi oczami. Szyfrowanie działa, ponieważ bardzo trudno jest „za pomocą siły” zaszyfrowanych danych, aby ujawnić ich czysty tekst. W rzeczywistości zerwanie szyfrowania jest tak trudne, że projekty nadzoru na dużą skalę czasami po prostu zbierają wszystkie dane, w nadziei, że będą w stanie przerwać szyfrowanie w przyszłości, gdy wzrośnie moc komputera lub będą w stanie uzyskać klucze które były używane do szyfrowania danych. Perfect Forward Secrecy (PFS) to metoda, której można użyć, aby zapobiec drugiemu scenariuszowi.

Perfect Forward Secrecy ponownie generuje klucze szyfrujące używane do okresowego szyfrowania ruchu VPN. Po wygenerowaniu nowej pary kluczy poprzednia para jest niszczona. Oznacza to, że żadnych zebranych zaszyfrowanych pakietów nie można odszyfrować w późniejszym terminie, ponieważ klucz użyty do ich zaszyfrowania już nie istnieje.

OpenVPN obsługuje PFS. Podczas przechwytywania danych dla tego artykułu, obniżyłem kluczową szybkość cyklu do 10 sekund, aby uchwycić ten proces. Odkryłem, że kiedy miała miejsce regeneracja klucza, wygenerowano następującą sekwencję pakietów:

09: 01: 48.461276 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, długość 94
09: 01: 54.749114 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, długość 65
09: 01: 58.895381 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, długość 86
09: 01: 58.951091 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, długość 94
09: 01: 58.951614 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, długość 259
09: 01: 59.007916 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, długość 94
09: 01: 59.008027 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, długość 94
09: 01: 59.008265 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, długość 94
09: 01: 59.008300 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, długość 94
09: 01: 59.062927 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, długość 256
09: 01: 59.106521 IP 192.168.1.204.openvpn > 104.254.92.61.openvpn: UDP, długość 575

Godną uwagi cechą tej sekwencji jest to, że rozmiary pakietów są identyczne za każdym razem, gdy miała miejsce regeneracja klucza. Dlatego za każdym razem, gdy widziałem sekwencję pakietów o tych rozmiarach podczas przechwytywania pakietów, wiedziałem, że następują cykliczne zmiany klucza:

94
65
86
94
259
94
94
94
94
256
575

Prawdopodobnie każdy powtarzający się proces teoretycznie wygenerowałby powtarzalną sekwencję pakietów takich jak ten, ale nadal można go wykorzystać jako wskaźnik, że PFS może być w grze. W połączeniu z innymi danymi ta informacja może być wystarczająca do potwierdzenia połączenia VPN.

Wszystkie pakiety przeznaczone do tego samego adresu IP

Podczas normalnego korzystania z Internetu ludzie i komputery żądają danych z wielu różnych witryn. Każda z tych witryn ma inny adres IP. Podczas korzystania z VPN każdy pojedynczy pakiet jest kierowany do serwera VPN. Serwer VPN odrywa warstwę szyfrującą VPN z każdego pakietu, aby odsłonić prawdziwy pakiet, a następnie wysyła go w drodze do miejsca docelowego. Serwer VPN robi to samo z odpowiedziami. Odbiera pakiety odpowiedzi, otacza je warstwą szyfrowania, a następnie wysyła pakiet do komputera użytkownika.

Przechwytywanie pakietów pokazujące, że komputer wysyła 100% swojego ruchu do jednego adresu IP, jest dobrym wskaźnikiem, że używana jest sieć VPN lub serwer proxy.

Psiphon to narzędzie służące do obejścia cenzury internetowej. Ma ciekawą funkcję, która może do pewnego stopnia z tym walczyć. Ma tryb podzielonego tunelu, który zasadniczo wykorzystuje tunel Psiphon tylko do ruchu opuszczającego twój kraj.

Comparitech-psiphon-splittunnel-mode

Aby zobaczyć, jak to wygląda na poziomie pakietu, uruchomiłem Psiphon i przetestowałem dwie witryny. Jestem w Kanadzie i oto próbka ruchu przeznaczona dla naszego własnego rejestratora domen .CA. W takim przypadku moje miejsce docelowe jest wyraźnie widoczne w przechwytywaniu pakietów.

8: 30: 14.213668 IP 192.168.1.210.58787 > www.cira.ca.https: Flagi [.], ack 1026833, win 64240, długość 0
08: 30: 14.229178 IP www.cira.ca.https > 192.168.1.210.58787: Flagi [.], Seq 1026833: 1028293, ack 715, win 5094, długość 1460
08: 30: 14.229427 IP www.cira.ca.https > 192.168.1.210.58787: Flagi [.], Seq 1028293: 1031213, ack 715, win 5094, długość 2920
08: 30: 14.229781 IP 192.168.1.210.58787 > www.cira.ca.https: Flagi [.], ack 1031213, win 64240, długość 0

Następnie odwiedziłem stronę internetową firmy Comparitech, która znajduje się w Stanach Zjednoczonych:

8: 29: 48.028789 IP li832-56.members.linode.com.ssh > 192.168.1.210.58659: Flagi [P.], seq 107809: 108277, ack 19080, win 1392, długość 468
08: 29: 48.029101 IP 192.168.1.210.58659 > li832-56.members.linode.com.ssh: Flagi [.], ack 108277, win 856, długość 0
08: 29: 48.029306 IP 192.168.1.210.58659 > li832-56.members.linode.com.ssh: Flagi [P.], seq 19080: 19132, ack 108277, win 856, długość 52
08: 29: 48.108658 IP li832-56.members.linode.com.ssh > 192.168.1.210.58659: Flagi [.], Ack 19132, wygrana 1392, długość 0

Zwróć uwagę, w jaki sposób ruch przeznaczony dla Stanów Zjednoczonych jest wysyłany na serwer Linode zamiast do porównywarki.com. Linode jest bardzo dużą firmą serwerową i nie jest niczym niezwykłym, aby zobaczyć ruch przeznaczony dla serwera Linode. Psiphon dodatkowo zaciemnia ten ruch, używając tunelu SSH, aby ukryć wszelkie ślady VPN. Również odwrotny DNS (rDNS) dla serwera Psiphon w Linode nie zdradza jego powiązania z Psiphon; rDNS pokazuje po prostu, że Linode jest właścicielem adresu IP, co jest oczekiwane. Więcej informacji na temat rDNS znajduje się w dalszej części tego artykułu.

Niespójności w systemie operacyjnym i pakietowych danych daktyloskopijnych

Chociaż sieci TCP są niezależne od systemu operacyjnego, różne systemy operacyjne tworzą pakiety o różnych wartościach. Na przykład domyślna wartość czasu wygaśnięcia pakietu (TTL) różni się w pakietach utworzonych w różnych systemach. Większość systemów Windows domyślnie ustawia pakiet TTL na 128, podczas gdy większość systemów Linux ustawia go na 64. Ponieważ TTL jest widoczną częścią przechwyconego pakietu, możliwe jest określenie, który system operacyjny najprawdopodobniej utworzył ten pakiet. Istnieją również inne znaki ostrzegawcze w konstrukcji pakietów, takie jak długość i maksymalny rozmiar segmentu (MSS), które również różnią się w zależności od systemu operacyjnego.

Poniższy fragment kodu jest częścią pakietu wygenerowanego z systemu Windows. Zanotuj TTL 127 wartość w ostatnim wierszu jest ustawiona na 127. Jest tak, ponieważ TTL jest wyrażone w liczbie „skoków”. Za każdym razem, gdy pakiet przechodzi przez urządzenie takie jak router, jego TTL jest zmniejszane o jeden. W tym przypadku TTL zaczął się od 128, ale odkąd przechwyciłem go na routerze - po jednym przeskoku - jest teraz 127. Jednak nadal mogę stwierdzić, że nigdy nie był to 64, więc prawdopodobnie jest to pakiet utworzony w systemie Windows.

08: 08: 51.657495 IP (tos 0x0, tl 64, id 32150, przesunięcie 0, flagi [DF], proto UDP (17), długość 177)
google-public-dns-a.google.com.domain > 192.168.2.139.59414: 40501 3/0/0 cdn-3.convertexperiments.com. CNAME cdn-3.convertexperiments.com.edgekey.net., Cdn-3.convertexperiments.com.edgekey.net. CNAME e5289.g.akamaiedge.net., E5289.g.akamaiedge.net. A 104.94.35.212 (149)
08: 08: 51.659278 IP (tos 0x0, tll 127, id 3890, przesunięcie 0, flagi [DF], proto TCP (6), długość 52)

Pakiet przechwycony z maszyny Linux ma TTL 63 po pierwszym skoku. Wynika to z faktu, że większość maszyn z systemem Linux ustawia wartość początkową pakietu TTL na 64.

08: 15: 55.913493 IP (tos 0x0, tl 63, id 41443, przesunięcie 0, flagi [DF], proto UDP (17), długość 56)
192.168.2.139.48635 > resolver1.ihgip.net.domain: 47200+ A? google.com. (28)

No i co z tego? Dlaczego ważne jest, aby wiedzieć, jaki system operacyjny utworzył pakiet?

Jeśli obserwator ma specjalistyczną wiedzę o celu, może mieć duże znaczenie. Jeśli wiadomo, że cel korzysta z systemu Windows - być może jako członek dużej organizacji, która używa systemu Windows przez cały czas - ale pakiety przechwycone z tego celu wskazują, że prawdopodobnie zostały utworzone na komputerze z systemem Linux, jest to dobry wskaźnik, że VPN lub proxy niektórych rodzaj jest w użyciu. Warto zauważyć, że praktycznie wszystkie serwery VPN działają na systemach Linux lub Unix.

Możliwe jest dostosowanie parametrów pakietu w większości systemów, ale bardzo niewiele osób korzysta z tej długości.

Niewystarczające techniki zaciemniania od dostawców VPN

Analiza sieci to coś więcej niż tylko zbieranie pakietów. Pewną rolę mogą odgrywać procesy pomocnicze, takie jak DNS. Wielu użytkowników VPN jest świadomych DNS, ponieważ wysyłanie zapytań DNS w sposób wyraźny jest dla obserwatora jednym ze sposobów ustalenia, gdzie odwiedzasz lub zamierzasz odwiedzić. Jednak mniej użytkowników wie o odwrotnym DNS (rDNS). Podobnie jak DNS kojarzy nazwę domeny z adresem IP, rDNS kojarzy adres IP z nazwą hosta, a nazwa hosta zwykle identyfikuje właściciela adresu IP. Ponadto większość bibliotek programistycznych i systemów operacyjnych jest dostarczana z niektórymi wersjami standardowych funkcji gethostnameby * (), które rozszerzają zdolność systemu do kojarzenia adresów IP i nazw hostów.

Odwrotny DNS nie jest tak krytyczny jak „normalny” DNS, ponieważ rDNS nie odgrywa żadnej roli w kierowaniu ruchem. Jest on raczej stosowany przede wszystkim jako sposób identyfikacji własności intelektualnej. Tylko właściciel adresu IP może powiązać z nim rekord rDNS. Dlatego sprawdzenie rekordu rDNS adresu IP daje wystarczającą pewność, kto jest jego właścicielem, a przynajmniej, kogo właściciel chce, abyś myślał, że jest jego właścicielem. Zauważ, że rDNS nie jest wymagany i wiele adresów IP w ogóle nie ma wpisów rDNS.

Spójrzmy na przykład domeny facebook.com. DNS Rekord dostarczony przez standardowe zapytanie DNS pokazuje ten adres IP:

$ dig + short facebook.com
31.13.67.35

Teraz użyjmy zwrotnego zapytania DNS lub funkcji gethostnamebyaddr (), aby zobaczyć, kto jest właścicielem tego adresu IP:

Host $ - 31.13.67.35
35.67.13.31.in-addr.arpa wskaźnik nazwy domeny edge-star-mini-shv-01-mia3.facebook.com

Z tego wynika, że ​​Facebook faktycznie jest właścicielem tego adresu IP. Jednak większość witryn nie posiada własnych adresów IP; są dzierżawione i należą do dowolnych organizacji lub być może należą do mniej oczywistych podmiotów. Amazon jest przykładem dużego dostawcy komputerów, z którego korzysta wiele firm. Zapytanie rDNS o adres IP wielu usług internetowych po prostu pokazuje, że Amazon jest właścicielem adresu IP, a zatem informacje te są mało przydatne w ustalaniu, kto obsługuje adres IP. Innym przykładem jest Google. Google jest nieco bardziej subtelny we wpisach rDNS, ale nadal zachowuje informacje o własności. Oto jak odwrotny DNS szuka adresu IP Google:

$ dig + short google.com
216,58.207,46

host - 216.58.207.46
46.207.58.216.in-addr.arpa wskaźnik nazwy domeny fra16s24-in-f14.1e100.net.

Google jest właścicielem domeny 1e100.net, więc możemy zobaczyć, że ten adres IP faktycznie należy do Google.

W świecie sieci VPN narzędzia do rozpoznawania adresów mogą potencjalnie służyć do sprawdzania, czy adres IP, do którego przeznaczony jest ruch, należy do sieci VPN. Na przykład domyślna komenda tcpdump na routerze OpenWRT spróbuje rozpoznać adresy IP, które widzi w pakietach TCP. Wydaje się, że do tego służy przede wszystkim gethostbyaddress (), dlatego czasami można sprawdzić, gdzie są przeznaczone pakiety. Domyślne przechwytywanie tcpdump sesji IPVanish ilustruje to:

08: 23: 14.485768 IP 216-151-184-30.ipvanish.com.3074 > 192.168.1.210.51061: UDP, długość 1441
08: 23: 14.485847 IP 216-151-184-30.ipvanish.com.3074 > 192.168.1.210.51061: UDP, długość 1441
08: 23: 14.486144 IP 216-151-184-30.ipvanish.com.3074 > 192.168.1.210.51061: UDP, długość 1441
08: 23: 14.486186 IP 216-151-184-30.ipvanish.com.3074 > 192.168.1.210.51061: UDP, długość 385

Klient IPVanish dla systemu Windows oferuje trzy konfiguracje: standardowe połączenie OpenVPN, połączenie OpenVPN za pomocą HTTPS oraz zaciemnione połączenie.

ipvanish-vpn-openvpn-mode

Powyższe pakiety zostały przechwycone podczas sesji przy użyciu zaciemnionego ustawienia połączenia OpenVPN, ale WireShark nadal jest w stanie podać informacje o miejscu docelowym.

W podsumowaniu

Określając użycie VPN, jest bardzo mało „srebrnych kul”. Zwykle potrzeba wielu technik lub obserwacji, aby skompilować wystarczającą liczbę wskaźników wskazujących, że VPN jest w użyciu, a nawet wtedy może być trudno być w 100% pewnym. Firmy, które są szczególnie zainteresowane niedozwoleniem korzystania z VPN, takie jak Netflix i inne usługi przesyłania strumieniowego, mają zespoły zajmujące się wyłącznie tym problemem. W innych przypadkach wiele krajów Europy Wschodniej i Bliskiego Wschodu zakazuje korzystania z VPN i ma podobne zespoły, które wyłapują użytkowników VPN.

Brayan Jackson
Brayan Jackson Administrator
Sorry! The Author has not filled his profile.
follow me

Add a Comment

Your email address will not be published. Required fields are marked *

+ 60 = 68