Почему подделка TTL IP опасна?

51

Я читал справочную страницу iptables (легкое чтение перед сном) и наткнулся на цель 'TTL', но она предупреждает:

Установка или увеличение поля TTL может быть очень опасным

а также

Никогда не устанавливайте и не увеличивайте значение пакетов, которые покидают вашу локальную сеть!

Я могу видеть, как, возможно, уменьшение или установка TTL ниже может привести к тому, что пакеты будут отброшены до достижения пункта назначения, но какой эффект может иметь увеличение?

— Робби Маккенни
источник

67

TTL уменьшается при прохождении через маршрутизатор. Это гарантирует, что если пакет будет путешествовать по кругу, он в конечном итоге умрет.

Поле TTL пакета IP v4 является 8-битным полем (десятичное число 255). Так что, установив его в начале, это не имеет большого значения, так как он не может быть настолько большим в правильно сформированном пакете (хотя некоторые вещи могут принимать неправильно сформированные IP-пакеты).

Однако, если что-то увеличивает его, и шаг увеличения является частью цикла , пакет может продолжать идти по кругу, не достигая нуля. Со временем (может быть очень коротким или постепенной утечкой) пакеты могут накапливаться в системе, содержащей этот цикл, вызывая его перегрузку.

— Кайл Брандт
источник

20

TTL на пакетах поддерживает маршрутизацию в разумных пределах. Если пакет должен иметь очень большой TTL и по какой-то причине был пойман по кольцевому маршруту, это может вызвать тонну трафика (так называемый «шторм пакетов») и помешать нормальной работе. Слишком низкий TTL приведет к потере соединения, так как вы потеряете пакет до того, как он достигнет пункта назначения.

— Натан С
источник

Это больше об истечении срока действия ТТЛ, но в нем более подробно говорится о том, что вы говорите: cisco.com/web/about/security/intelligence/ttl-expiry.html

— NickW

5

Есть один момент, в котором ответы, по-видимому, пропущены, но который носит чисто академический характер (из-за того, что, по всей видимости, требуется много переходов в Интернете): если пакет обычно не достигает своего места назначения из-за истекающего TTL, то его увеличение позволил бы пакету достигнуть его назначения, но не затронул бы возвращаемые пакеты, и они истекут прежде, чем достигнуть вашей сети.

ОБНОВЛЕНИЕ: Согласно этой странице в Википедии :

Теоретически, в IPv4 время жизни измеряется в секундах, хотя каждый хост, проходящий дейтаграмму, должен уменьшить TTL как минимум на одну единицу. На практике поле TTL уменьшается на единицу при каждом переходе. Чтобы отразить эту практику, поле переименовано в предел прыжка в IPv6.

ОБНОВЛЕНИЕ 2: Когда кто-то обновил мой пост и сослался на Википедию, я подумал, что лучше всего сослаться на сам RFC - http://www.ietf.org/rfc/rfc791.txt - Просто найдите там TTL, и он вполне хорошая работа объяснить это:

В этом поле указывается максимальное время, в течение которого дейтаграмме разрешено оставаться в интернет-системе ... каждый модуль, обрабатывающий дейтаграмму, должен уменьшить TTL как минимум на единицу, даже если он обрабатывает дейтаграмму менее чем за секунду

— Мэтью Стиплз
источник

2

Однако - если вы увеличили количество пакетов, отправленных в вашей сети, до значения, которое они имели бы, если бы они исходили от вашего маршрутизатора, тогда возвращаемые пакеты достигнут вашего маршрутизатора (и затем вы можете увеличить их при отправке клиенту в локальная сеть)

— Random832

Мне действительно нравится новый взгляд на подход, и вы получите мое одобрение за это. Однако первоначально предполагалось, что TTL будет уменьшаться один раз за каждую секунду, которую пакет провел в сети, а также за каждый переход. Это историческое определение в значительной степени игнорируется в настоящее время - однако никогда нельзя предполагать, что путь между двумя узлами является симметричным - или даже одинаковым от одной передачи пакета к другому.

— пп.

Правда. Иногда вы можете получить очень странные результаты, используя tracert, если пакет x использует другой маршрут, чем пакет y! Также спасибо за информацию о времени отслеживания, я не знал, что (хотя, если пакеты не помечены как метки времени, это может быть уменьшено, только если маршрутизатор удерживает их, не может ли это?)

— Мэтью Стиплз,

@PP. Есть ли у вас ссылка на утверждение, что изначально предполагалось, что значение TTL будет уменьшаться раз в секунду? Без высокоточных синхронизированных часов, которые, конечно, не были обычным явлением в первые дни Интернета (не говоря уже о том, что многие хосты обрабатывали только местное время), я не понимаю, как это можно было бы надежно сделать.

— CVn

3

@ MichaelKjörling Это определено как таковое в RFC 791, который определяет IPv4.

— Майкл Хэмптон

3

Я знаю только одну программу, которая могла бы использовать более высокое значение TTL, и это traceroute. Как следует из названия, он отслеживает маршрут к хосту назначения, изменяя значение TTL. Стандартное максимальное количество прыжков - 20, но вы можете увеличить его.

— ott--
источник

2

(Большинство реализаций) traceroute также полагаются на сообщения ICMP Time Exceeded, чтобы сообщить, достиг ли пакет своего места назначения или нет. Кроме того, сообщения Time Exceeded являются одной из причин, по которой прямая блокировка ICMP является очень плохой идеей.

— CVn

0

Каждый маршрутизатор, который обрабатывает пакет, уменьшает значение TTL до тех пор, пока пакет не достигнет своего пункта назначения или пока TTL не достигнет нуля и не умрет.

Как уже говорили другие, увеличение TTL может привести к пакетам, которые никогда не умрут, если есть отрицательный цикл. Как правило, если значение TTL недостаточно велико, логика, чтобы попробовать больший TTL, вероятно, должна обрабатываться сквозными клиентами.

Если вы уверены, что маршрутизатор не находится в цикле (древовидная топология), теоретически вы можете безопасно увеличить значение TTL. Сказав это, разрешение большего количества переходов, чем стандартно, может повысить вероятность перегрузки во внешней сети. Если у вас есть длинная цепочка маршрутизаторов между внутренней и внешней сетью, пока нет цикла, может помочь большее значение TTL. Сказав это, для кого-то может быть довольно просто добавить ребро в сеть и создать цикл, поэтому начинать с большего значения TTL, когда пакет был создан в первую очередь, гораздо безопаснее.

— ronalchn
источник