Dlaczego manipulowanie TTL IP jest niebezpieczne?

51

Czytałem stronę podręcznika iptables (lekkie czytanie na dobranoc) i natknąłem się na cel „TTL”, ale ostrzega:

Ustawienie lub zwiększenie pola TTL może być bardzo niebezpieczne

i

Nigdy nie ustawiaj ani nie zwiększaj wartości pakietów opuszczających sieć lokalną!

Widzę, jak być może zmniejszanie lub obniżanie TTL może powodować upuszczanie pakietów przed dotarciem do miejsca docelowego, ale jaki efekt może mieć zwiększanie?

Robbie Mckennie
źródło

Odpowiedzi:

67

TTL ulega zmniejszeniu, gdy przechodzi przez router. To gwarantuje, że jeśli pakiet będzie krążył w kółko, w końcu umrze.

Pole TTL pakietu IP v4 to pole 8-bitowe (255 miejsc po przecinku). Tak więc ustawienie go wysoko na początku nie jest wielkim problemem, ponieważ nie może być tak duże w dobrze uformowanym pakiecie (chociaż niektóre rzeczy mogą akceptować zniekształcone pakiety IP).

Jeśli jednak coś to zwiększa, a krok inkrementacji jest częścią pętli , pakiet może nadal krążyć w kółko, nigdy nie osiągając zera. Z biegiem czasu (może to być bardzo krótki lub stopniowy wyciek) pakiety mogą gromadzić się w systemie zawierającym tę pętlę, powodując jej przeciążenie.

Kyle Brandt
źródło
20

Zasadniczo TTL na pakietach utrzymuje rozsądny routing. Jeśli pakiet miałby mieć bardzo duży czas TTL i z jakiegoś powodu zostałby złapany w trasę kołową, może to spowodować mnóstwo ruchu (zwane „burzą pakietów”) i zakłócać normalne operacje. Zbyt niski TTL spowoduje utratę łączności, ponieważ stracisz pakiet, zanim dotrze on do miejsca docelowego.

Nathan C.
źródło
Chodzi tu bardziej o wygaśnięcie TTL, ale zawiera nieco więcej szczegółów na temat tego, co mówisz: cisco.com/web/about/security/intelligence/ttl-expiry.html
NickW
5

Wydaje się, że brakuje jednej odpowiedzi, która byłaby czysto akademicka (z uwagi na to, ile przeskoków wydaje się być wymaganych w Internecie): jeśli pakiet normalnie nie osiągnąłby miejsca docelowego z powodu upływu czasu TTL, to zwiększając go pozwoli pakietowi dotrzeć do miejsca docelowego, ale nie wpłynie na zwrot pakietów i wygasną przed dotarciem do sieci.

AKTUALIZACJA: Według tej strony w Wikipedii :

Teoretycznie w IPv4 czas do życia jest mierzony w sekundach, chociaż każdy host, który przechodzi przez datagram, musi skrócić TTL o co najmniej jedną jednostkę. W praktyce pole TTL jest zmniejszane o jeden na każdym skoku. Aby odzwierciedlić tę praktykę, zmieniono nazwę pola na limit przeskoków w IPv6.

AKTUALIZACJA 2: Gdy ktoś zaktualizował mój post i odniósł się do Wikipedii, pomyślałem, że najlepiej będzie odwoływać się do samego RFC - http://www.ietf.org/rfc/rfc791.txt - Po prostu znajdź tam TTL i robi to całkiem dobra robota, tłumacząc to:

To pole wskazuje maksymalny czas, w którym datagram może pozostać w systemie internetowym ... każdy moduł przetwarzający datagram musi zmniejszyć TTL o co najmniej jeden, nawet jeśli przetworzy datagram w mniej niż sekundę
Matthew Steeples
źródło
2
Jednak - jeśli zwiększyłeś pakiety, które powstały w sieci do wartości, które miałyby, gdyby pochodziły z routera, wówczas pakiety zwrotne dotrą do routera (a następnie możesz je zwiększyć, wysyłając je dalej do klienta w sieć lokalna)
Random832
Podoba mi się nowatorski pogląd na to podejście i otrzymuję za to moją opinię. Jednak początkowo TTL miał być zmniejszany raz na każdą sekundę pakietu spędzonego w sieci, a także na każdy przeskok. Ta definicja historyczna jest obecnie w dużej mierze ignorowana - jednak nigdy nie można zakładać, że ścieżka między dwoma węzłami jest symetryczna - lub nawet taka sama między transmisją jednego pakietu do drugiego.
PP.
Prawdziwe. Możesz uzyskać bardzo dziwne wyniki za pomocą tracert czasami, jeśli pakiet x podąża inną drogą niż pakiet y! Dziękuję również za informację o czasie śledzenia, nie wiedziałem o tym (chociaż jeśli pakiety nie są oznaczone znacznikiem czasu, można je było zmniejszyć tylko wtedy, gdy trzymał je router, prawda?)
Matthew Steeples
@PP. Czy masz odniesienie do twierdzenia, że ​​wartość TTL pierwotnie miała być zmniejszana raz na sekundę? Bez precyzyjnie zsynchronizowanych zegarów, które z pewnością nie były powszechne we wczesnych dniach Internetu (nie mówiąc już o tym, że wiele hostów obsługiwało tylko czas lokalny), nie widzę, jak można to zrobić w wiarygodny sposób.
CVn
3
@ MichaelKjörling Jest zdefiniowany jako taki w RFC 791, która definiuje IPv4.
Michael Hampton
3

Znam tylko jeden program, który mógłby użyć wyższej wartości TTL, i to jest traceroute. Jak sama nazwa wskazuje, śledzi trasę do hosta docelowego, modyfikując wartość TTL. Standardowy maksymalny skok wynosi 20, ale możesz go zwiększyć.

ott--
źródło
2
(Większość implementacji) traceroute opiera się również na komunikatach ICMP Przekroczony czas, aby stwierdzić, czy pakiet osiągnął miejsce docelowe, czy nie. Nawiasem mówiąc, komunikaty o przekroczeniu czasu są jednym z powodów, dla których bezpośrednie blokowanie ICMP jest bardzo złym pomysłem.
CVn
0

Każdy router, który obsługuje pakiet, zmniejsza wartość TTL, dopóki pakiet nie osiągnie miejsca docelowego lub TTL osiągnie zero, i umrze.

Jak powiedzieli inni, zwiększenie TTL może spowodować, że pakiety nigdy nie umrą, jeśli wystąpi cykl ujemny. Ogólnie rzecz biorąc, jeśli wartość TTL nie jest wystarczająco duża, logika wypróbowania większego TTL powinna być prawdopodobnie obsługiwana przez klientów końcowych.

Jeśli masz pewność, że router nie jest w cyklu (topologia drzewiasta), teoretycznie możesz bezpiecznie zwiększyć wartość TTL. To powiedziawszy, dopuszczenie większej liczby przeskoków niż jest to standardowe, może zwiększyć prawdopodobieństwo zatoru w sieci zewnętrznej. Jeśli masz długi łańcuch routerów między siecią wewnętrzną i zewnętrzną, o ile nie ma cyklu, może pomóc większa wartość TTL. To powiedziawszy, może być dość łatwe dla kogoś, kto doda przewagę do sieci i utworzy cykl, więc rozpoczęcie od większej wartości TTL, w której pakiet powstał w pierwszej kolejności, jest znacznie bezpieczniejsze.

ronalchn
źródło