Por que a violação do TTL de IP é perigosa?

Question

Eu tenho lido a página de manual do iptables (leitura leve na hora de dormir) e me deparei com o alvo 'TTL', mas ele avisa:

Setting or incrementing the TTL field can potentially be very dangerous

e

Don't ever set or increment the value on packets that leave your local network!

Eu posso ver como, talvez, decrementar ou configurar o TTL inferior poderia fazer com que os pacotes fossem descartados antes de chegar ao destino, mas que efeito poderia ter o incremento?

    

Answer 1

O TTL é diminuído quando passa por um roteador. Isso garante que, se o pacote estiver circulando em círculos, acabará morrendo.

O campo TTL de um pacote IP v4 é um campo de 8 bits (255 decimal). Então, defini-lo alto no início não é um grande negócio, uma vez que não pode ser realmente tão grande em um pacote bem formado (Embora, algumas coisas podem aceitar pacotes IP malformados).

No entanto, se algo o incrementa, e o passo de incremento é parte do loop , o pacote pode continuar em círculos sem chegar a zero. Com o tempo (pode ser muito curto ou um vazamento gradual), os pacotes podem se acumular no sistema contendo esse loop, fazendo com que ele sobrecarregue.

    

Answer 2

O TTL nos pacotes mantém o roteamento são, basicamente. Se um pacote tivesse um TTL muito grande e fosse capturado em uma rota circular por algum motivo, ele poderia causar uma tonelada de tráfego (chamada de "tempestade de pacotes") e interferir nas operações normais. Um TTL muito baixo resultaria em perda de conectividade se você perdesse o pacote antes de chegar ao destino.

    

Answer 3

Há um ponto que as respostas parecem ter perdido, mas que seria puramente acadêmico (por causa de quantos saltos parecem ser necessários na internet): se um pacote normalmente falha em alcançar seu destino por causa de um TTL que expira, em seguida, o aumento permitiria que o pacote atingisse seu destino, mas não afetaria os pacotes sendo retornados e eles expirariam antes de chegar à sua rede.

UPDATE: De acordo com esta página na Wikipedia :

In theory, under IPv4, time to live is measured in seconds, although every host that passes the datagram must reduce the TTL by at least one unit. In practice, the TTL field is reduced by one on every hop. To reflect this practice, the field is renamed hop limit in IPv6.

UPDATE 2: Como alguém atualizou meu post e referenciou a Wikipedia, achei que seria melhor fazer referência ao próprio RFC - link - Basta procurar por TTL e faz um bom trabalho explicando isso:

This field indicates the maximum time the datagram is allowed to remain in the internet system... every module that processes a datagram must decrease the TTL by at least one even if it process the datagram in less than a second

    

Answer 4

Eu conheço apenas um programa, que poderia usar um valor de TTL mais alto, e isso é traceroute . Como o nome diz, rastreia a rota para um host de destino, modificando o valor do TTL. O máximo de saltos padrão é 20, mas você pode aumentar isso.

    

Answer 5

Cada roteador que manipula um pacote diminui o valor do TTL, até que o pacote atinja seu destino, ou o TTL chega a zero e morre.

Como outros já disseram, aumentar o TTL pode resultar em pacotes que nunca morrem, se houver um ciclo negativo. Geralmente, se um valor de TTL não for grande o suficiente, a lógica para tentar um TTL maior provavelmente deve ser tratada pelos clientes de ponta a ponta.

Se você tiver certeza de que um roteador não está em um ciclo (topologia em forma de árvore), você poderia, em teoria, aumentar com segurança o valor do TTL. Dito isto, permitir mais saltos do que o padrão poderia tornar o congestionamento mais provável na rede externa. Se você tiver uma longa cadeia de roteadores entre a rede interna e externa, desde que não haja ciclo, um valor TTL maior pode ajudar. Dito isto, pode ser muito fácil para alguém adicionar uma borda à rede e criar um ciclo, portanto, começar com um valor TTL maior no qual o pacote foi originado, em primeiro lugar, é muito mais seguro.