Choć ostatnio w centrum uwagi znajduje się pcAnywhere, mianem dwóch głównych winowajców należy określić jednak dwa inne rozwiązania: pierwszym z nich jest Virtual Network Computing (VNC) - bardzo popularne rozwiązanie oparte na otwartym kodzie źródłowym i dostępne na wiele platform, drugim zaś Remote Desktop Protocol (RDP) autorstwa Microsoftu. Regularne skanowania portów przeprowadzane przez Insecure.com, zarządzającą projektem NMAP skatalogowały ponad 83 mln systemów z otwartymi portami typowymi dla VNC i ok. 230 mln systemów z nasłuchującą usługą RDP. Otwarte porty nie oznaczają jeszcze podatności na ataki, jednak z pewnością wskazują systemy, które mają spore szanse zainteresować atakujących.

Dla porównania, specjaliści firmy Rapid7 (znanej z popularnego narzędzia do testów penetracyjnych o nazwie Metasploit) znaleźli podczas przeprowadzonego ostatnio skanowania sieci internet ok. 7,7 mln systemów akceptujących żądania na portach używanych standardowo przez pcAnywhere, ale dalsze badania wykazały, że tylko ok. 1,8% z nich (co daje ok. 140 tys. systemów) faktycznie odpowiadało na żądania transmisji pcAnywhere, czyli mogłoby być potencjalnym celem ataku. Jeśli podobny procent maszyn akceptujących połączenia na portach VNC i RDP faktycznie oferuje na nich te usługi, daje to ponad milion systemów podatnych na ataki.

Zobacz również:

• Ataki na protokół RDP - czy powinniśmy się ich obawiać?

Według raportu Trustwave, znakomita większość skutecznie zaatakowanych serwerów obsługiwała punkty sprzedaży, czy wszelkie usługi takie jak hotele, restauracje itp. Tego rodzaju przedsiębiorstwa zwykle korzystają z usług zewnętrznych firm, które do zarządzania systemami wykorzystują usługi zdalnego dostępu. Niestety, jak się okazało, wiele z tych zewnętrznych firm IT nie zabezpiecza tych usług na tyle dobrze by nie mogły stać się celem skutecznego ataku.

Polecamy: Praktyczne porady dla administratorów na 2012 rok

Jak może wyglądać bezpieczny zdalny dostęp? Przed otwarciem takiej słabo zabezpieczonej usługi na świat warto zastanowić się czy nie da się tego uniknąć korzystając z niej (bez jej wystawiania na zewnątrz) po zestawieniu VPN, a jeśli to nie jest możliwe, można jeszcze rozważyć tunelowanie połączenia wewnątrz bezpiecznej sesji SSH.