O

statnio Larry Seltzer wykonał prosty test w korzystaniu z otwartych sieci WiFi (tych, które nie oferują żadnego szyfrowania i najczęściej udostępniane są za darmo w restauracjach typu KFC, McDonalds, hotelach itd.). Polegał on na zbadaniu, czy rzeczywiście korzystanie z takich sieci nawet za pomocą wirtualnych sieci prywatnych zapewnia dobry stopień bezpieczeństwa.

Każda osoba, która choć trochę interesuje się bezpieczeństwem lub została przeszkolona w własnej firmie z zasad obsługi sprzętu odnośnie bezpieczeństwa danych wie, że najczęstszym problemem są otwarte sieci WiFi, które oprócz umilania czasu w kawiarni, czy hotelu nie oferują żadnego szyfrowania ruchu. Pozwala to innym uczestnikom w sieci podglądać krążące dane, czy przejmować sesje innych użytkowników. Niestety mimo możliwości zaszyfrowania całego ruchu w tego typu sieciach istnieje pewna luka w konfiguracji systemów, która jest nie doceniana przez wiele osób.

Wielcy gracze tacy, jak Twitter, Google, Facebook itd. przyjęli szyfrowanie SSL w celu szeroko pojętej ochrony swoich użytkowników. Dla jeszcze większej prywatności wiele użytkowników korporacyjnych lub ceniących swoją prywatność stosuje wirtualne sieci prywatne (VPN). Mniej więcej polega to na tym, że nasz komputer lub inne urządzenie obsługujące ten rodzaj komunikacji łączy się z serwerem usługi VPN i nawiązuje szyfrowany tunel dla całego ruchu w Internecie. Serwery usługi VPN następnie przekazują cały ruch do i z miejsca przeznaczenia. Jest to znacznie lepsze rozwiązanie, niż SSL (nie dostępny jeszcze na wszystkich stronach) ponieważ cały ruch z naszego urządzenia jest szyfrowany. Nawet, jeśli punkt dostępowy WiFi, do którego się podłączyliśmy został przejęty i służy do szkodliwych celów – to na nim również nie będzie widać naszego ruchu sieciowego w jawnej postaci. Czy na pewno?

Istnieje luka w konfiguracji i całym procesie połączenia się z usługą VPN. VPN nie może nawiązać szyfrowanego połączenia dopóki sam nie będzie w stanie komunikować się z Internetem. W większości przypadków zanim samo urządzenie zdobędzie połączenie do Internetu w otwartej sieci WiFi użytkownik musi otworzyć przeglądarkę i tam spełnić określone wymagania dostawcy – np. zalogować się, zaakceptować regulamin korzystania z publicznego Internetu itd. i dopiero później uruchomić tunel VPN. Jak można się domyśleć powstaje luka czasowa pomiędzy tymi dwoma czynnościami, która może doprowadzić do jawnego wycieku danych. Jakich? To zależy z jakiego oprogramowania korzystamy na urządzeniu i jak jest ono skonfigurowane. Jeśli nasz klient poczty korzysta z czystego protokołu IMAP bez szyfrowania StartTLS i w dodatku łączy się automatycznie do serwera w celu pobrania poczty, co określony czas lub, jak tylko dostępne jest połączenie z Internetem – to bardzo prawdopodobne, że wyśle dane dostępowe niebezpiecznym połączeniem. To samo może tyczyć się komunikatorów, kalendarzy itd.

“Good developers know how things work. Great developers know why things work.”

Czy tej sytuacji można w jakiś sposób zaradzić? Oczywiście. Pierwszym krokiem jest samodzielne sprawdzenie, co wycieka z naszego komputera przy podłączeniu do Internetu. Wystarczy w zaufanej sieci WiFi przed podłączeniem do Internetu użyć programu typu Wireshark i przekonaniu się, czy uda się nam podsłuchać jakieś jawne dane. W przypadku powodzenia należy zmienić konfigurację danego programu, aby od razu korzystał z szyfrowanej komunikacji z zdalnym serwerem lub nie przesyłał danych / uruchamiał się dopóki nie zostanie nawiązane bezpieczne połączenie VPN. Drugim jest wykorzystanie wbudowanej lub zewnętrznej, programowej zapory ogniowej w celu ograniczenia całego ruchu przychodzącego lub wychodzącego tylko dla połączenia VPN. Dla publicznych sieci możemy zostawić jedynie ruch przeglądarki, która na pewno przyda nam się do uzyskania połączenia z Internetem w publicznych sieciach WiFi. Ostatnim i najbezpieczniejszym rozwiązaniem jest nie korzystanie z tego typu sieci.

Więcej informacji: Even with a VPN, open Wi-Fi exposes users