Коллектив авторов - Защита от хакеров корпоративных сетей

Хост, который только что получил пакет злоумышленника, собирается отметить пакет как полученный, подтвердить его посылкой уведомления (ACK-пакета) и в большинстве случаев сдвинуть пакет в потоке данных дальше. Когда хост получит второй пакет с теми же самыми последовательными номерами, он предположит, что получил дублирующий пакет. Дублирующие пакеты не редкость. Поэтому установленное на хостах программное обеспечение протокола TCP написано таким образом, чтобы игнорировать любые пакеты с данными, похожими на уже полученные. При этом оно не заботится о точном соответствии данных в полученных пакетах, как должно быть в случае с истинными дубликатами.

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

Когда сервер получает данные, которые он принимает за очередную копию пакета, он посылает еще одно уведомление. Посылка очередного уведомления означает, что сервер уже получил эти данные ранее и продолжил свою работу дальше. При получении неожиданного внеочередного уведомления следует ответить пакетом уведомления 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.

Как было показано в главе 10, широкое использование шифрования является одним из самых легких способов усиления защиты от многих атак злоумышленника. Решения этой проблемы предусмотрены на всех уровнях модели OSI Международной организации по стандартизации ISO, начиная с шифрующих сетевых интерфейсных плат на уровне канала передачи данных и до многочисленных технологий шифрования на прикладном уровне. Прикладной уровень – верхний уровень модели OSI, обеспечивающий такие коммуникационные услуги, как электронная почта, пересылка файлов и другие. Большинство из протоколов, традиционно используемых для перехвата сессии, могут быть заменены протоколом SSH2, функциональные возможности которого позволяют заменить Telnet, FTP, rlogin и rcp. Вдобавок с помощью SSH2 можно туннелировать другие протоколы, например HTTP или X Windows. Отчасти протокол SSH1 также решает эти проблемы, но этот пункт наравне с главой 13 объясняет, почему SSH2 лучше.