TCP a inne protokoły

Ponieważ TCP jest protokołem połączeniowym, łatwo w nim pośredniczyć narzut związany z użyciem serwera proxy występuje tylko raz, a potem wystarczy kontynuować to połączenie. W UDP nie ma pojęcia połączenia każdy pakiet jest oddzielną transakcją, wymagającą podjęcia oddzielnej decyzji przez serwer proxy. Łatwiej zatem pośredniczyć w ruchu TCP (choć istnieją serwery proxy dla UDP). Podobnie, trudno pośredniczyć w ruchu ICMP, ponieważ każdy pakiet jest oddzielną transakcją. Pośredniczenie w ICMP jest trudniejsze niż w TCP, ale nie niemożliwe istnieją serwery proxy dla ICMP.

Sytuacja wygląda podobnie z punktu widzenia filtrów pakietów. Dość łatwo przepuścić TCP przez firewall i kontrolować kierunek, w którym są nawiązywane połączenia możesz filtrować pakiety według bitu ACK, aby pozwolić na nawiązywanie połączeń tylko wewnętrznym klientom, przepuszczając zarazem odpowiedzi. W przypadku UDP i ICMP nie jest to tak łatwe. Jeśli użyjesz stanowych filtrów pakietów, możesz przepuszczać pakiety, które wydają się odpowiedziami, ale nigdy nie masz pewności, czy pakiet rzeczywiście jest odpowiedzią na wcześniejszy,

i możesz oczekiwać odpowiedzi na pakiety, które ich nie wymagają. Jedno połączenie na sesję. Firewall może łatwo przechwytywać wstępne połączenia od klienta do serwera, ale trudniej mu przechwycić połączenia zwrotne. Jeśli posługujesz się serwerem proxy, obie strony konwersacji muszą wiedzieć o obecności serwera albo serwer musi umieć interpretować i modyfikować protokół, aby połączenia zwrotne były nawiązywane poprawnie i jednoznacznie. Jeśli posługujesz się zwykłym filtrowaniem pakietów, połączenia przychodzące muszą być dozwolone przez cały czas, co często umożliwia napastnikom dostęp do portów używanych przez inne protokoły. Stanowe filtry pakietów, podobnie jak serwery proxy, muszą umieć interpretować protokół i ustalać, dokąd zmierza połączenie zwrotne, aby otworzyć dla niego lukę.

Na przykład w zwykłym trybie FTP klient otwiera połączenie kontrolne z serwerem. Kiedy należy przesłać dane: 1. Klient wybiera losowo port o numerze powyżej 123 i przygotowuje go na przyjęcie połączenia.

-2. Klient wysyła serwerowi polecenie PORT, zawierające adres komputera i numer portu, w którym klient czeka na połączenie.

-3. Serwer otwiera nowe połączenie z tym portem.

-Aby serwer proxy zadziałał poprawnie, musi:

-1. Przechwycić polecenie PORT, wysyłane przez klienta do serwera.

-2. Przygotować nowy port na przyjęcie połączenia.

-3. Połączyć się z klientem przez wybrany port.

-4. Wysłać do serwera FTP zastępcze polecenie PORT (z numerem portu w serwerze proxy).

-5. Przyjąć połączenie od serwera FTP i przekazywać dane między nim a klientem.

Serwer proxy nie może po prostu odczytywać po drodze polecenia PORT, ponieważ ten port może być już zajęty. Filtr pakietów musi albo dopuścić wszystkie połączenia przychodzące z portami o numerach powyżej 123, albo przechwytywać polecenie PORT i tworzyć tymczasową regułę dla tego portu. Podobne problemy powstają w każdym protokole, który wymaga połączeń zwrotnych.

Jeśli protokół wymaga czegoś więcej niż połączenia wychodzącego i zwrotnego, sytuacja jest jeszcze gorsza. Przykładem może być usługa talk rozdział 19, „Usługi konferencyjne czasu rzeczywistego” zawiera opis zagmatwanej sieci połączeń w tej usłudze, której praktycznie nie da się przepuścić przez firewall (sprawę pogarsza to, że usługa talk opiera się w części na UDP, ale jeśli nawet korzystałaby tylko z TCP, i tak byłaby sennym koszmarem konstruktorów firewalli).

Leave a reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>