15.3.3Ack-буря

Одна из проблем IP Hijacking заключается в том, что любой пакет, высланный в момент, когда сессия находится в десинхронизированном состоянии вызывает так называемую ACK-бурю. Например, пакет выслан сервером, и для клиента он является неприемлимым, поэтому тот отвечает ACK-пакетом. В ответ на этот неприемлемый уже для сервера пакет клиент вновь получает ответ... И так до бесконечности.

Есть несколько путей определения ACK – бури и защиты от нее. Например, можно реализовать TCP/IP-стэк, который будет контролировать переход в десинхронизированное состояние, обмениваясь информацией о sequence number/acknowledge number. Однако в данном случае мы не застрахованы от злоумышленника, меняющего и эти значения.

Поэтому более надежным способом является анализ загруженности сети, отслеживание возникающие ACK-бури. Это можно реализовать при помощи конкретных средств контроля сети.

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

Стопроцентную защиту от данной атаки обеспечивает, как всегда, шифрование TCP/IP. Это исключает возможность модификации сетевого потока.

Следует заметить, что метод также не срабатывает на некоторых конкретных реализациях TCP/IP. Так, несмотря на rfc (документы, в которыох описаны сетевые протоколы, логика работы сети), который требует молчаливого закрытия сессии в ответ на RST-пакет, некоторые системы генерируют встречный RST-пакет. Это делает невозможным раннюю десинхронизацию.