Предположим, что крэкер может предсказать, какой порядковый номер (S-SYN по схеме) будет выслан сервером. Это возможно сделать на основе знаний о конкретной реализации TCP/IP. Например, в 4.3BSD значение порядкового номера, которое будет использовано при установке следующего значения, каждую секунду увеличивается на 125000. Таким образом, послав один пакет серверу, крэкер получит ответ и сможет (возможно, с нескольких попыткок и с поправкой на скорость соединения) предсказать порядковый номер для следующего соединения.

Если реализация TCP/IP использует специальный алгоритм для определения порядкового номера, то он может быть выяснен с помощью посылки нескольких десятков пакетов серверу и анализа его ответов.

Итак, предположим, что система A доверяет системе B, так, что пользователь системы B может сделать "rlogin A"[20] и оказаться на A, не вводя пароля. Предположим, что крэкер расположен на системе C. Система A выступает в роли сервера, системы B и C - в роли клиентов.

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

После этого крэкер может попробовать притвориться системой B, для того, что бы получить доступ к системе A (хотя бы кратковременный).

Крэкер высылает несколько IP-пакетов, инициирующих соединение, системе A, для выяснения текущего состояния порядкового номера сервера.

Крэкер высылает IP-пакет, в котором в качестве обратного адреса указан уже адрес системы B.

Система A отвечает пакетом с порядковым номером, который направляется системе B. Однако система B никогда не получит его (она выведена из строя), как, впрочем, и крэкер. Но он на основе предыдущего анализа догадывается, какой порядковый номер был выслан системе B

Крэкер подтверждает "получение" пакета от A, выслав от имени B пакет с предполагаемым S-ACK (заметим, что если системы располагаются в одном сегменте, крэкеру для выяснения порядкового номера достаточно перехватить пакет, посланный системой A). После этого, если крэкеру повезло и порядковый номер сервера был угадан верно, соединение считается установленным.

Теперь крэкер может выслать очередной фальшивый IP-пакет, который будет уже содержать данные. Например, если атака была направлена на rsh, он может содержать команды создания файла .rhosts или отправки /etc/passwd крэкеру по электронной почте.

Представим это в виде схемы:

Рис. 6 IP-spoofing

Детектирование и защита

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

В случае использования более интеллектуальных средств контроля за сетью администратор может отслеживать (в автоматическом режиме) пакеты от систем, которые находятся в недоступном состоянии. Впрочем, что мешает крэкеру имитировать работу системы B ответом на ICMP-пакеты?

Какие способы существуют для защиты от IP-spoofing? Во-первых, можно усложнить или сделать невозможным угадывание порядкового номера (ключевой элемент атаки). Например, можно увеличить скорость изменения порядкового номера на сервере или выбирать коэффициент увеличения порядкового номера случайно (желательно, используя для генерации случайных чисел криптографически стойкий алгоритм).

Если сеть использует межсетевой экран firewall (или другой фильтр IP-пакетов), следует добавить ему правила, по которым все пакеты, пришедшие извне и имеющие обратными адресами из нашего адресного пространства, не должны пропускаться внутрь сети. Кроме того, следует минимизировать доверие машин друг другу. В идеале не должны существовать способа, напрямую попасть на соседнюю машину сети, получив права суперпользователя на одной из них. Конечно, это не спасет от использования сервисов, не требующих авторизации, например, IRC – чат (крэкер может притвориться произвольной машиной Internet и передать набор команд для входа на канал IRC, выдачи произвольных сообщений и т.д.).

Шифрование TCP/IP-потока решает в общем случае проблему IP-спуфинга (при условии, что используются криптографически стойкие алгоритмы).

Для того, чтобы уменьший число таких атак, рекомендуется также настроить firewall для фильтрации пакетов, посланных нашей сетью наружу, но имеющих адреса, не принадлежащие нашему адресному пространству. Это защитит мир от атак из внутренней сети, кроме того, детектирование подобных пакетов будет означать нарушение внутренней безопасности и может помочь администратору в работе.

6.2.2 IP Hijacking – Нападение на IP

Если в предыдущем случае крэкер инициировал новое соединение, то в данном случае он перехватывает весь сетевой поток, модифицируя его и фильтруя произвольным образом. Метод является комбинацией 'подслушивания' и IP-спуфинга.

Описание

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

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

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

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

Есть два способа рассинхронизировать соединение

§ Ранняя десинхронизация

Соединение десинхронизируется на стадии его установки.

Крэкер прослушивает сегмент сети, по которому будут проходить пакеты интересующей его сессии

Дождавшись пакета S-SYN от сервера, крэкер высылает серверу пакет типа RST (сброс), конечно, с корректным порядковым номером, и, немедленно, вслед за ним фальшивый C-SYN-пакет от имени клиента

Сервер сбрасывает первую сессию и открывает новую, на том же порту, но уже с новым порядковым номером, после чего посылает клиенту новый S-SYN-пакет.

Клиент игнорирует S-SYN-пакет, однако крэкер, прослушивающий линию, высылает серверу S-ACK-пакет от имени клиента.

Итак, клиент и сервер находятся в установленом состоянии ESTABLISHED (установлено), однако сессия десинхронизирована.