TCP a inne protokoły
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