Читаем Защита от хакеров корпоративных сетей полностью

Когда сервер получает данные, которые он принимает за очередную копию пакета, он посылает еще одно уведомление. Посылка очередного уведомления означает, что сервер уже получил эти данные ранее и продолжил свою работу дальше. При получении неожиданного внеочередного уведомления следует ответить пакетом уведомления ACK с ожидаемым последовательным номером. Поэтому когда сервер посылает истинному клиенту неожиданное для него уведомление (то есть ответ на «незаконное» уведомление само по себе незаконно), клиент делает то же, что и сервер в аналогичной ситуации: отвечает пакетом уведомления ACK с ожидаемым последовательным номером. В результате наступает перегрузка сети уведомлениями ACK (ACK storm).

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

Во-вторых, может произойти ситуация, когда после посылки нужных злоумышленнику команд он может сбросить соединение. RST-пакет, который злоумышленник посылает клиенту и/или серверу, вынуждает их прекратить отправку уведомлений ACK и фактически полностью закрыть соединение. С точки зрения пользователя, находящегося перед монитором клиента, он увидит какое-то сообщение об «аварийном завершении соединения». Увидев подобное сообщение, большинство людей не станут долго задумываться над ним и просто откроют новое окно соединения. Зачастую некоторые клиенты Telnet стирают содержимое экрана при сбросе соединения или после получения окна диалога, сообщающего о сбросе соединения. Другими словами, подведя курсор к кнопке «OK», они щелкают по кнопке мыши. Подобное поведение пользователей на руку злоумышленнику. Ему становится легче избежать обнаружения, поскольку обычно единственной подсказкой легитимному пользователю о проблемах в сети является любой подозрительный вывод данных на экран.

В-третьих, в некоторых случаях возможна повторная синхронизация клиента и сервера, для того чтобы клиент мог возобновить свою обычную деятельность. Тем не менее этот способ является проблематичным и зависит от ряда факторов. Основная идея способа состоит том, что переданное истинным клиентом количество данных должно каким-то образом сравняться с количеством данных, переданных сервером и злоумышленником. Например, если легитимный клиент во время сеанса отправил 100 байт данных, а затем вмешался злоумышленник, перехватил соединение и послал серверу от имени клиента еще 10 символов, то сервер полагает, что клиент переслал 110 байт. Программа вмешавшегося злоумышленника также считает, что отослано 110 байт. В случае, если злоумышленник собирается и далее отсылать данные, то удерживает канал. Но истинный клиент все еще полагает, что отослано только 100 байт. Тогда, когда злоумышленник захочет повторно синхронизировать сервер и легитимного клиента, он должен каким-либо способом заставить клиента догнать сервер. Злоумышленник не может вернуть сервер вспять к 100 байтам. Его действия могут привести только к увеличению сервером количества принятых данных. Итак, по мере того как клиент посылает данные, злоумышленник фабрикует уведомления на них от сервера. Клиент увеличивает свой внутренний счетчик размера пересланных данных до 110, а затем злоумышленник освобождает соединение. С этого момента сервер и клиент опять синхронизированы, и истинный клиент опять может передавать данные.

Безусловно, сложность реализации протокола TCP отзывается по-разному в различных операционных системах. Во время тестирования автором программы Hunt (см. соответствующий пункт в этой главе) он обнаружил, что определенная комбинация операционных систем клиента и сервера не вызывает десинхронизации. При подсоединении с помощью Telnet к древней машине NextOS (да, те черные кубы, которые сделал Стив Джобс (Steve Jobs) после ухода из Apple) клиента с установленной Red Hat 6.2 программа Hunt может вставлять команды, но это сможет сделать и клиент. По завершении работы не было необходимости в повторной синхронизации, поскольку, во-первых, клиент никогда не был десинхронизирован. Такой же тест, но с использованием еще одной операционной системы Red Hat 6.2 в качестве сервера Telnet породил ожидаемый результат: истинный клиент мог видеть введенные команды, но не мог их выдавать.

Представляется, что проблема шторма уведомлений (перегрузки сети уведомлениями ACK) – следствие проблемы синхронизации, по крайней мере в данном случае. На комбинации NextOS/Linux перегрузки сети не наблюдалось, но они были при комбинации Linux/Linux.

<p>Исследование атак типа MITM в зашифрованных соединениях</p>
Перейти на страницу:
Нет соединения с сервером, попробуйте зайти чуть позже