Ślepy Tor?

Gdy połączyć fakt przesyłania certyfikatu w nieszyfrowanej formie z polem Common Name wskazującym na nieistniejącą domenę, widać, że identyfikacja ruchu, który jest związany z ruchem "chronionym" przez protokół Tor, jest prosta. Nawet jeśli serwer korzysta z samodzielnie podpisanego certyfikatu, zazwyczaj pola wypełniane są wartościami takimi jak adres IP albo pole to pozostawia się puste.

Zachowanie polegające na losowym wypełnianiu pól w certyfikacie jest unikatem w skali Internetu, zatem umożliwia otagowanie ruchu związanego z Torem za pomocą prostych narzędzi inspekcji pakietów.

Selektywne blokowanie

Typowy algorytm oznaczania ruchu związanego z Torem polega na poszukiwaniu początków negocjacji połączenia SSL, pobraniu informacji o certyfikacie serwera, sprawdzenie kilku innych warunków, które mają odsiać certyfikaty samodzielnie podpisane, a następnie próbie rozwiązania domeny wpisanej w pole Common Name. Jeśli proces ten się nie powiedzie, pakiety będą oznaczane jako ruch związany z Torem. Warto wiedzieć, że wszystkie certyfikaty serwerów sieci Tor zaczynają się od www i kończą na .net, co sprawia, że analizy statystyczne, które przez całe lata były stosowane przy zwalczaniu spamu, mogą sprawnie posłużyć do analizy i oznaczania ruchu związanego z siecią Tor. Będzie można go zablokować, analizować statystycznie, a także wyciągać konsekwencje prawne w krajach, w których stosowanie takich technologii jest prawnie zabronione.

SSL na czarnej liście

Tor nie jest jedynym ruchem, który powinien znaleźć się na czarnej liście w firmach. Specjaliści do spraw bezpieczeństwa uważają, że aby podwyższyć bezpieczeństwo sieci firmowej, należy wdrożyć politykę dopuszczającą jedynie uzasadniony ruch SSL. Chociaż podejście to jest radykalne, umożliwia zablokowanie większości niepożądanego ruchu generowanego przez złośliwe oprogramowanie.

Minusem tak restrykcyjnej polityki jest konieczność wprowadzania na listę dozwolonych serwisów tych stron i zasobów Internetu, które są związane z pracą w organizacji. Należy pamiętać, że blokowanie i analiza ruchu nie polega na przypisaniu ruchu do konkretnego portu TCP/UDP, ale wymaga analizy ruchu i rozpoznawania protokołów. Zatem ruch SSL odbywający się na porcie HTTP albo przenoszony w danych wewnątrz sesji HTTP (są takie rozwiązania, które udają pobieranie obrazów, a naprawdę przenoszą ruch SSL) również powinien być rozpoznany i zablokowany. Obecnie wszystkie rozwiązania IPS potrafią taki ruch rozpoznać na podstawie zawartości, a nie portu źródłowego i docelowego.


TOP 200